Tonight saw the Rumble offices packed to the rafters with new and experienced Ruby developers coming along to learn more about Ruby, or to help lend a hand to those that wanted to know more.
There were three talks tonight, one on Ruby on Rails. one on Git/Version Control and one on Ruby in general, I will briefly talk about each one in turn.
Ruby on Rails by Nicklas Persson
Nick opened the event and gave the first of the three talks on the subject of Ruby on Rails, after a whirlwind mention on the history/creators of Ruby/Ruby on Rails Nick spoke about why Rails is a useful tool and demonstrated how little effort it takes to get something up and running using some built in Ruby on Rails functionality.
Git/Github by Melissa Keizer
Next on the agenda was a talk/demo of how easy it is to get up and running with Git and Github. Melissa started by explaining some terminology and concepts associated with version control and then decided to give a live demo of setting up a repository on Github and working through some of the basic functionality. This was probably the most practically useful talk of the evening and hopefully conveyed how easy Git actually is for the standard stuff.
Ruby by Kieran Graham
The final talk of the evening was by Kieran on why Ruby is a fun and useful language to learn, he drew some excellent examples of how sensible Ruby seems when compared to languages like Objective C (and Brainfuck) his talk was very well received and I think instilled a sense of ‘doableness’ in folk who maybe are completely new to Ruby or programming in general.
The event had three great sponsors;
- BrewBot – Supplied beer for the event that they brewed especially for us called Ruby on Ales. Unfortunately I didn’t get to sample any of it but I am sure it was amazing.
- ShopKeep – Supplied the pizza and yet more beer! and also some chairs (but who needs chairs when there is pizza and beer!)
- Rumble Labs – Hosted the event and put on a good spread of snacks and yes, you guessed it, more beer!
It was so exciting to see so much interest in the community for Ruby and seeing that certainly gave me a passion top-up. Unfortunately I didn’t stay around to get chatting to too many folk after the talks but it was a great evening and I feel the Belfast Ruby community is stronger as a result.
Thanks to all the speakers and sponsors for making another awesome Ruby event, I look forward to the next one!
I wouldn’t recommend jumping between different branches too often when you are deploying, it is too easy to forget which branch you actually want to deploy and that could be disastrous, but on occasion it just makes sense.
The command you need to run would be something like this;
ey deploy -e demo -r my_awesome_branch
ey just calls engine yard,
deploy tells engine yard that we want to deploy something,
-e tells it what environment to deploy it to, and
-r is optional and stands for ref, this tells engine yard which branch, tag or SHA to deploy.
Sometimes in Git we will do a merge that will need manual intervention.
If you are merging your own stuff in with your own stuff then most of the time you are going to know which bit of code to keep or if to keep them both.
Things get interesting when either of the following two cases apply;
- You are merging in someone else’s code
- You can’t remember why you had written the code that is causing the issue.
Both of these cases can be solved by a using git’s blame.
git blame will show you a line by line breakdown of who wrote what line of code and as part of what commit and why this is useful for helping with merges is that it will;
- Let you know who you need to contact to discuss what needs to happen with this merge if it is non-obvious.
- Give you a commit hash that you can then query to find out the bigger picture and the context of the smaller change that is currently causing you issues.
git blame on a file simply call
git blame my_file_name.rb and the output will be the contents of the file with each line prepended with the commit hash, the commiter and the the date and time it was commited.
We are so used to applications on our phones and computers shouting at us every two seconds to update them to the latest version that we can become blind to new releases of software that don’t ram the fact they are updated down your throat.
Git is a fine example of this, like most command line tools it will happily sit on whichever version you happen to have installed way back when, and that is fine, except for if you installed Git a year or more ago you might be missing out on some new features and bug fixes.
To find out what version of Git you are running simply type
git --version into your command line, I am going to guess it is sitting at 1.7.x.
As of writing the most recent stable version is 220.127.116.11, if you want to see what the difference is between your version and the current version take a look at this Git Changelog.
How you installed Git will have some influence on how you update it, on OSx I think Git comes pre-installed so what I have had to do in the past is download the .dmg file from the Git website and install the latest version, making sure to add the install location of the new Git to my PATH variable so it is seen as the version of Git to use.
Git branches appear to be case insensitive, which isn’t a problem in and of itself, but if you clone a remote branch from github like this:
git checkout -b my_new_branch /origin/My_New_Branch
Git will see your new branch as
my_new_branch* and when you pull it will check
origin/My_New_Branch which is totally correct and sane, but if you do a push it seems to want to push to a new branch in github called
my_new_branch which will get super confusing if multiple people need to access this branch.
The ideal fix for this is prevention – just don’t create a new local branch with a different name to your remote branch, but let’s say you do?
Creating a new branch with the correct case will not work because git is case insensitive and will see both
My_New_Branch as the same thing, instead you need to rename your current branch using a middle step. Luckily like most things in git this is very straightforward;
git branch -m my_new_branch tmp_branch (will rename your lowercase branch to tmp_branch)
git branch -m tmp_branch My_New_Branch (will rename to your desired CamelCase branch!)
Now your pushes should go to the correct branch.
*Disclaimer – My_New_Branch is a terrible name for a branch, always be descriptive and imagine you are naming it for someone else who doesn’t know the project to read.