Replace IRB with Pry (in your Gemfile) and Byebug with pry-byebug
.
gem 'pry-rails', group: [:development, :test]
gem 'pry-byebug', group: [:development, :test]
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
HTTP status code symbols for Rails | |
Thanks to Cody Fauser for this list of HTTP responce codes and their Ruby on Rails symbol mappings. | |
Status Code Symbol | |
1xx Informational | |
100 :continue | |
101 :switching_protocols | |
102 :processing |
# Simple example of aes-256-cbc encryption for Ruby/Rails to encrypt URL params (or any text) | |
require 'openssl' | |
require 'base64' | |
require 'uri' | |
plaintext = 'id=example_id&user_id=the_user_id&username=voxtrot&user_first_name=john&user_last_name=doe&user_image=http://i1.nyt.com/images/misc/nytlogo379x64.gif' | |
# |
Our Virtual Machines are provisioned using Vagrant from a Linux base box to run using VirutalBox. If the Hard Disk space runs out and you cannot remove files to free-up space, you can resize the Hard Disk using some VirtualBox and Linux commands.
The following steps assume you've got a set-up like mine, where:
A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.
I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.
I'd love comments and suggestions about any of these.
I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.
I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".
What this guide will cover: the code you will need in order to include Redis and Resque in your Rails app, and the process of creating a background job with Resque.
What this guide will not cover: installing Ruby, Rails, or Redis.
Note: As of this writing I am still using Ruby 1.9.3p374, Rails 3.2.13, Redis 2.6.11, and Resque 1.24.1. I use SQLite in development and Postgres in production.
Background jobs are frustrating if you've never dealt with them before. Over the past few weeks I've had to incorporate Redis and Resque into my projects in various ways and every bit of progress I made was very painful. There are many 'gotchas' when it comes to background workers, and documentation tends to be outdated or scattered at best.
In this episode, Jay McGavren shares some of his favorite tricks for working in the shell. No unreadable sed or awk scripts here. Just simple, solid tips you can use every day, including time savers with find, less, ssh, and command-line Ruby.
http://programmer.97things.oreilly.com/wiki/index.php/The_Unix_Tools_Are_Your_Friends
#!/bin/bash | |
# This has to be run from master | |
git checkout master | |
# Update our list of remotes | |
git fetch | |
git remote prune origin | |
# Remove local fully merged branches |