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!
GitGutter is one of my favourite Sublime Text plugins, and it is one of the first to be installed when I am setting up a new environment.
What is GitGutter?
GitGutter allows you to see what changes have happened since your last commit in git, it will let you easily see what lines have been added, removed or edited.
Why use GitGutter?
If you are a git user, having a view on what has changed as part of your next commit is incredibly useful – You can see at a glance in a file if you have removed something, which is handy if you make a change and walk away from your machine and need to get a feel for what you were doing.
Features of GitGutter
As well as visually showing you what lines have changed, you can also do the following with GitGutter;
- Jump between changes (super useful in a large file)
- Set it to only update once the file saves, or have it update live (I prefer live)
- Change the colour of how GitGutter is presented (I have no problems with the default)
My preferred way to install it is using the very popular Sublime Package Control, but you can also clone the code needed from the Github repository.
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 188.8.131.52, 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.