Get with,

sudo aptitude install git-core

Simple Commands,

git init                   ...init repository
git add .                  ...add everything in dir to repository
git commit -a -m 'update'  ...add + commit changes
git diff                   ...show changes since last commit

git add [file]             ...add file
git rm [file]              ...remove file
git mv [file]              ...move file

Mirror Git Repository

rsync -azvCL --delete --progress 
   -e "ssh -i /home/[user]/.ssh/[mykey]" .git/* 
[user]@[user].strongspace.com:/home/[user]/[project]/.git/

Example to go thru your User model and return all the signups by month / year, doing conditionals on them and grouping,

@users = User.find(
  :all, 
  :select => "MONTH(created_at) as month, YEAR(created_at) as year, COUNT(*) AS records",
  :conditions => ["admin = 0'"], 
  :group => "year, month")

You can use this in your view like,

<% for @user in @users %>
  <%=@user.month%>
  <%=@user.year%>
  <%=@user.records%> signups
<% end %>

Had a bit of a pain with Ruby’s handling of Date/Time values coming from a Date_Select form element, managed to solve it though.

The problem was that in my form…

<%=date_select(:date,'',:start_year => 1950,:include_blank => false, :default => { :year => '1970' })%>

…the value I got back from the submitted field,

params[:date]

became…

'(3i)4(1i)1953(2i)5'

Bit of a mess, obviously I was expecting something a little more legible like 1953-5-4 (yyyy-mm-dd), so I bashed my head against a brick wall trying to work it out, I could have made my life easier with some select_date blocks but I’m a guy how likes to ask ‘why’ so I perceviered.

Turns out in my travels you can do this to break it into a usable DateTime object..

Time.mktime(params[:date]['(1i)'],params[:date]['(2i)'],params[:date]['(3i)'])

Which will return something much more legible…

Sun May 19 00:00:00 +0100 1968

Or whip it into a method to do exactly what you want…

def convert_date(obj)
  return "#{obj['(1i)']}-#{obj['(2i)']}-#{obj['(2i)']}"
end

<%=convert_date(params[:date])%>

But wait, it doesn’t end there, you could use Date.new or Date.civil to parse it into a real date object like…

def convert_date(obj)
  return Date.new(obj['(1i)'].to_i,obj['(2i)'].to_i,obj['(3i)'].to_i)    
end

Which will return…

1967-03-19

Much nicer, just remember to use .to_i otherwise you’ll get…

comparison of String with 0 failed

Enjoy!

• Ruby Dates & Times Wiki

One thing that might muck up your beautifully designed AJAX popups is the user repeatedly hitting the tab key, simple way of stopping this is by inserting a onkeydown event for the keypress..

Trapping TAB

<input name='username' type='text' 
onkeydown='if(event.keyCode==9) { return false; }' />

Simple and effective, as soon as the user’s cursor gains focus for the username textbox if they then try to hit TAB within it it won’t do anything; effectively trapping the action dead.

Obviously if you’ve got two boxes (username + password), you’ll want to put this kind of trap on the password textfield otherwise the user won’t be able to tab to the next cell, but as a quick fix it works well.

Setting Focus

You can also set focus via…

$('username').focus();

To make a truly intelligent web application your gonna sooner or later have to play around with Sessions, which is basically a Cookie’s big brother.

Store in DB

Now Rails initally will store all it’s session data in a text file within the /tmp/sessions directory of your rails app, which is usually ok, but if you’re gonna build a production-ready app you’re gonna want to up the ante somewhat and store them in your DB.

This is simply done by opening up your environment.rb file and un-commenting the following line…

(within /config/environment.rb)
config.action_controller.session_store = :active_record_store

Then in the command-line generate a RAKE DB migration for your Session objects (so they’re stored in your db from now on).

rake db:sessions:create
rake db:migrate

Bingo, you now have a table within your database hooked up and ready to store your session data perfectly.

Storing Session Objects

Now that you’ve got your DB storing your session data, why don’t we start creating some session objects.

This is done by…

session[:order] = 'ASC'

Here, we’ve simply created a new session object, storing in it a text value of ‘ASC’; cool eh?

We can then check to see if our session is empty via…

if session[:order].blank?
   ..do stuff..

So if our session object contains nothing we can initialise it correctly.

Common Gotcha

Now one of the good things with switching sessions over to your db is that it’ll secure your app a little bit better and your performance will improve.

Plus if your building your app on your dev machine, then transfer it to your live box, but can’t find a reason why your sessions don’t work there it’s usually down to file permissions for the session file; by switching sessions over to a db you remove any future problem of this.

Good eh,