I have moved this blog to GitHub using Octopress, a framework built on top of Jekyll.
The Github/Octopress blog loads in 3.61 seconds compared 10.58 seconds for WordPress. I plan to install the Jekyll asset pipeline to further speed it up.
All the posts that I wrote here have been migrated successfully. For my own reference, this is how to commit to the blog repo:
$git add .
$git commit -am "commit message"
$git push origin source
Myles asked me to perform a kata a few weeks ago. After doing some research on sites like codingdojo.org and http://cyber-dojo.com/ (<- cool site, by the way) to find a kata, I decided to perform the Roman Numerals kata. Jordan wrote a good write-up on his experiences with this kata recently.
In the course of doing a screencast doing the kata, I have learned quite a bit. I discovered guard and guard-rspec, which run tests every time the files are saved. By default, guard expects .rb files in the lib/ directory and .spec files in the spec/ directory. When practicing kata, work on the .spec file so you don’t have to switch between different files.
Although my use of vim is improving, I decided not to use it in the kata. Although there are lots of choices, I am using the default Linux text editor. It is easy to use and I can quickly change color schemes (use a high contrast scheme that uses lots of color!). I do miss the vim shortcuts a lot, though.
As for screencasting software, there are a surprising number of options for Linux. I have been using Kazam (unrelated to the movie starring Shaq) although VLC has a feature where a song can be played when recording starts.
I will share the screen capture soon and what I used to help prepare.
As a follow-up to my last post on rebasing, there’s an important step before committing to master from a branch. You should initiate a pull request on master for your newly committed branch so that it can be reviewed before merging. The new branch should run on Travis-ci before being merged. Git doesn’t seem so magical now that I’m beginning to understand how to use it properly.
This past week we started rebasing our Git commits. I was not sure why this was necessary when Myles and Skim suggested this to us during the last IPM but now I do.
Basically, you create a new branch when working on a new feature. You test, develop and push when that feature is ready, then the new code is “replayed” on the existing master branch when you use the rebase command. This is better than using the merge command which can cause conflicts when parts of the code base are changed in both branches.
The main reason behind rebasing is that the master branch should be unblemished and should be a functioning version of the application at all times. This was an interesting process to learn and I recommend reading more about rebasing.
We have been making progress on our Rails application, implementing Oauth for authentication through Google and completing book check-out and return features. This is is Taka‘s description of what happened. Here is the guide we used. Next up will be to authenticate users with 8thlight.com email addresses. Here’s our site on Heroku – we’ve called it Kihon, which is a Japanese word meaning basics or fundamentals. It is a no-frills app at the moment as we have not done much with the design or UI.
I am getting more comfortable with Rails, although there is still a lot of magic happening behind the scenes. The MVC framework makes more sense now conceptually and that is something I will carry forward, even if I don’t use Rails in the future.
We have been using Github so I am getting better with git too. For testing we have been using Rspec for our formal tests and rails console and pry for our informal tests. Testing is hard but it’s important and necessary.
Myles asked me to perform a kata prior to 8th Light university next Friday so I have been preparing for that. I decided to do the Roman Numerals kata as I hadn’t done it before. I will post more on that soon. I also came across an interesting site called cyber-dojo.com where you can practice katas online.
I finished reading The Clean Coder, a book on professionalism for software engineers. Nathan has written a short review that I agree with. Uncle Bob reasons that you should work 40 hours a week on paid, professional work and spend 20 hours practicing your craft through personal projects, reading/writing, mentoring, meetups, etc. I think it is a good guideline although the time estimates (20 hours!) may be on the higher side. In any case, it provided food for thought and was a good read. It reminded me of Apprenticeship Patterns in the way that Uncle Bob walks us through the journey he has gone through in his career.
I also finished reading a book called How to Live on 24 Hours a Day. I read it based on positive reviews despite being published in 1910. I would describe it as motivational self-help book: practical rather than preachy. It was an interesting read and the author’s advice is much the same as Uncle Bob – including spending 90 minutes a weekday on productive work outside of the office, maximize your time while commuting, prepare for your day before reaching your desk and reflecting on the day’s work afterward. It is out of copyright so you can read it for free as an eBook. I read it on the Google Books app on my phone while on the train.
Tips for anyone new to software development, especially Ruby and/or Ruby on Rails.
- Get comfortable with using the command-line (Terminal)
- Learn how to use Vim. Especially if you will be collaborating with experienced developers. It will take you about a week to get used to it but it will improve your productivity.
- Figure out the basics of Git and Github. Everyone uses it and you will too
On my first day back at the office, Myles and Steve assigned Taka and I the task of building a web application for the office library using Ruby on Rails. We started with an Iteration Planning Meeting to plan the week’s iteration and the stories (features) we would be working on. This was the first time we had estimated the time frames for our stories (more on that later).
I was excited about having a real project to work but also a bit apprehensive as it had been over since I had done anything in Rails. But we dived in,pairing almost the entire week , and made good progress using books like Rails Tutorial, The Rspec Book and Rails Guides. Here’s what I’ve learned over the past week.
- Estimating stories uses the PERT model – each story has an optimistic, realistic and pessimistic element. The total estimated time is weighted towards the realistic time estimate so it’s best to thoroughly analyze the story considering what you know how to do and what you are doing for the first time (learning along the way). The optimistic and pessimistic elements have significantly less weight but they should be used to maintain a healthy range. Since Taka’s and my estimates are averaged together, our estimates are basically averaged twice. I think this is a positive thing. Our first week’s estimates were on the higher side – we finished most of the stories in less time than we had estimated.
- Ask the customer specifics before building features. We spent time testing and adding validation for a form that wasn’t specified in our story. While we learned about validation in the process, it wasn’t a good use of our time as the requirements for the form in another story.
- It’s good to work with a pair. We talk through our problems and our thought processes; this means that our code is analyzed twice on the fly. We maintain a good pace of work as well – I am less tired mentally so I don’t take as many breaks and resume quickly when I do. Since we have been working off Taka’s laptop, I am less distracted and get more work done. More importantly, we compensate for each other’s deficiencies and learn from each other. Our skills are consistently challenged too: I have been learning how to use vim through practice. I would not have willingly done this otherwise.
- I will try to keep a record of what we accomplished at the end of the day. For whatever reason, I forget what we have done from one day to the next and this is a good remedy.