Sometimes I have difficulty focussing on tasks and getting things done. I think that this is part of being human. There are some times where I will concentrate on a task so fiercely that I will ignore other things, such as that bad smell coming from the laundry basket in the back corner of my room. Then there are the times where I’m as apathetic to the task as a teenager to homework. I’ve been asked by a couple of people how I stay so focussed.

What’s my secret?

I break everything down into tiny chunks so my tiny brain can understand that, in order for there to be “happy happy joy joy fun time” this one little task needs to be done. In the process of writing, I’ve broken the book down into individual stories, just as a real app would be broken down. Each chapter can (and so far, all of them do) contain many stories. So far the average is 4, but with only two “storied” chapters written, this is an unfair average. The purpose for breaking it down into stories is two fold:

1. As mentioned before, it demonstrates to the reader how a real application would be developed using BDD. Story by story.
2. It “forces” the user to concentrate on just getting one “puzzle piece” done at a time

There’s also the top-secret 3rd “fold”: It helps me focus when I’m writing. If I know that there’s writing to be done (and boy (and girl), there’s writing to be done!) and I’m going “groan more writing!” I have the willpower to convince myself that if I can write a well-done story tonight it is one more story closer to completion than if I had not. That is enough to convince me that I should probably do some writing. I don’t have to write the WHOLE chapter in this one sitting. Just this one story. Then I can take a break and give it a skim-through to see if there’s any glaring omissions and fix them. Then I may even be eager enough after that to take another break, perhaps to go to the toilet or grab some food or do that washing that’s creating that God-awful smell. Anything that let’s me just think about what I’m doing for a moment, that’s a good thing. That’s one less distraction that I’m going to have when I enter the zone. I’m not going to think “I should eat”, because I already have. Deal with the distractions, then get on with it.

With this “technique” applied three weekends ago (a long weekend in Aussie-land) I managed to write nearly 16,000 words. Two weekends ago was my brother’s birthday, which was fantastic to see him and the rest of the family again. Nothing got done that weekend besides awesome catch up. Then this weekend, I wrote another 14,000 words. Between these periods I’ve been doing some self-editing and editing based on the suggestion of Others Who Cannot Be Named. This has left the total word count at 29,101 as of tonight.

Tomorrow night is the Ruby on Rails Sydney meetup which I’ll be at so there’ll be no writing done then, but it’s extremely likely that I’ll be at the magical 30,000 word mark come headdown (the time when my head hits my pillow) on Wednesday. And then beyond that. Eventually though, there will come a time where I will get to release this to you guys. That’s when I feel I won’t be writing as much, just fixing up what’s already been written. We’ll see. Perhaps I’ll feel ultra-motivated and get to that mystical target I’ve set myself of 20,000 words in a weekend. It’s a nice sounding number.

So in order to be ultra-focussed I deal with all possible distractions before starting tasks. I’m finding this is an effective way of being able to stay focussed for long periods of time, and I’m curious if this works for you too. I know other people use techniques like timeboxing and Pomodoro.

What works for you?

From my time helping out in the #rubyonrails channel on Freenode, I have come across some awesome people whom I probably would have never met. Being able to talk with them is the major reason why I still hang out in there. Then there’s the coming and going of the people wishing to ask questions and listen to the answers provided by the people who are willing to give them, such as myself.

I don’t mind answering question after question when I have spare time (which I don’t anymore, so I cut back). Some of the questions are nearly identical such as “Has anybody used ?” or “Can somebody help me?” or “This is broken.” This is why I made the bot for the channel so that the people helping out do not have to repeat themselves. The bot provides many things, such as the commands !used, !ask and !elaborate for the responses to the respective questions above. I think it’s a great advantage having something like that in the channel and I can see that other people do too.

Sometimes though, we have to answer the questions ourselves. The channel bot does not have the knowledge we do, and is really only helpful for answering general questions or linking to helpful things like the guides. When we answer these questions, we (read: most of us) put our heart and soul into helping you become a better person. We give free advice to those who ask for it.

Many of these people are thankful, grateful, appreciative. I want to see these people become contributing members to the Rails community, so I help them. This is how I got started, and how I need them to get started too. In helping these people, perhaps I learn something new, or perhaps I don’t. It’s those little things you pick up along the way by helping out others which I think makes me a great programmer. The feeling you get when somebody says “Thanks” when you help them is awesome. If I didn’t need to eat, sleep or drink, I could probably live off this alone.

Then you get the people who question your advice. Who state, adamantly, that your advice is wrong. Very, very, very rarely this is the case. It’s usually that they’ve come in with their own set opinion and that anybody else who says anything different is completely wrong. I do not understand these people. They come in asking what appears to be a legitimate question, but instead will argue with you for hours as to why their point is better, regardless of your experiences and issues with their point.

Listen to us. We’ve been there before. We know what’s best (99.999% of the time). If you think that you’re right, stop and think for a moment. What if the other person is right? Try to see it from their point of view. Imagine what it would be like to argue their point. Don’t come back with things like “NO THAT SUCKS”. Clearly elaborate on why it sucks in clear and concise points. Text is not limited and your time is not as precious as you think. The more valid points you have for your argument, the better it will be. Arguing with the longtimers in the channel is not the way to win friends and influence people. Admit you’re wrong if you are, and you’ll be a better person for it.

Stop assuming that your answer is the be-all-and-end-all of the topic. Why waste our time asking a question if you’re already set in your ways? Just go and implement it and then come to us later when it breaks for you and we will help you fix it for free. If 5 other people in the channel are opposing your idea and suggesting what they claim is a better solution, then they’re probably right. We only have your best interests in mind.

Please, listen to us. We want you to help you, help us, help you.

I mentioned yesterday that I was saving juicy topics for the book I’m writing, but this is just one that’s too good to miss from posting here too. Consider it (and the posts before it) a sample. The book is in a very similar vein.

Today we were working on our application at work which we refer to as three-point-oh. In three-point-oh, there were some features that were broken unrelated to the work we were currently doing on the donations branch which we had just merged into master. It was one of those issues where you could run the features that were breaking by themselves and they’d work just fine.

You know the type.

In our system we have an ActivityObserver which creates an Activity record every time someone performs any kind of CRUD action upon any observed class in our system. The catch is that User.current_user must be set for an activity record to be created, otherwise there’s no record of CRUD.

One of the observed classes was Contact. One of our features runs the db:seed task for its own setup (the very first line of the Background) and in this we set up a Contact record for the scenarios. Of course by it being the first line, we’re not going to have a currently logged in user, and therefore an Activity record is not going to be created.

But what happens if we run another scenario where we log in? Well, then User.current_user will be set to that user whom we log in with. Then, of course, Cucumber will perform its dutiful task once the scenario has finished running and clear the database, thereby eradicating all records, including the one that User.current_user is set to . What Cucumber does (and should) not do is destroy objects. When we ran the features in a group, if any of those features were logging in they would be setting User.current_user, then of course that related record would be being wiped when the scenario completed.

Then came the seeding feature. This is the feature that runs the db:seed task for itself and because User.current_user was set in a prior ran feature, it was creating Activity records for users that no longer exist. When the app then went to display these activities on the homepage, it would attempt access the avatar method on a user that no longer existed, thus giving us an undefined method avatar for nil:NilClass.

This was because between requests in test mode, classes are not reloaded. Therefore, User.current_user would not be unset. To unset it, we specify this in a file located at features/support/start.rb:

Before do
  User.current_user = nil
end

We could probably also use foreign key constraints to ensure that when we create an activity record that the user record we’re creating it for exists, but that’s information probably best kept for the book or another blog post.

Well, not really Week 3, but it’s the start of the third week since I announced it, so it’s the “official” 3rd week. I recorded another video last night. Much shorter than the last one (6’15) and it should give you a good insight into what I’m doing this week.

So I posted earlier that I’m writing a book on Rails 3 and I asked for suggestions. Thank you greatly to those who sent them in. Now I’m looking to put the final touches on the book and because I was slightly inebriated when I got home I decided to record something in Photo Booth rather than writing it down.

So here it is. If you’ve ever wanted to stare lovingly into my eyes and hear my soothing voice, here’s your chance.

Hopefully with your feedback by the end of next week I should have a good enough table of contents to start writing this epic.

Thanks for being with me so far!

It’s plugin / gem pimping time!

I started writing by_star back in November 2008 when Thomas Sinclair asked me if I could write a method that could find records for a given month. I was in my gem creating phase then so I created a gem called by_month and Thomas paid me for it (the sucker!).

Later on, I realised that by_month wasn’t good enough so I added a couple more finders to it. Then I added some more. Now you can find by all of these things:

• A given year
• A given month
• A given fortnight
• A given week
• A given weekend
• A given day
• The current weekend
• The current work week
• The Past
• The Future
• Between certain times
• As of a certain time
• Up to a certain time
• Before a specific record
• After a specific record

So if you’re ever doing anything in your application where you need to find by dates / times, why are you not using by_star? Here’s a good reason you should be using by_star:

Before by_star

 Post.all(:conditions => ["created_at >= ? AND created_at <= ?", "01/01/#{Time.now.year}".to_time, "31/01/#{Time.now.year}"])

After by_star

Post.by_month(1)

This is only a taste of the shiny things in by_star! Use it!

Again!

209.20.86.131 rubyonrails.org api.rubyonrails.org guides.rubyonrails.org gems.rubyonrails.org

And all should be well.

Seems to be broken for now. Follow these instructions if you want the guides:

git clone git://github.com/rails/rails.git
git checkout origin/2-3-stable -b 2-3-stable
cd rails/railties
rake generate_guides
open guides/output/index.html

Run gem server if you want access to the API documentation.

You’d think they would have sorted this out by now! This has happened, to my recollection, for the past 3-4 years. Hopefully now DHH renews it for a longer period than just a year.

If you read the entirety of my last post then you may have seen this:

Yup, you heard it here: I’m going to take on writing a book. This is why I want you all working on Rails and the community, because I simply will not have the time to sit in the IRC channel or on Stack Overflow to help you out anymore. Somebody else needs to step up and “be me” temporarily if I am to complete this book by the end of the year. I want your feedback on this! So contact me on twitter or e-mail me with ideas of what you think should go in a book about Rails.

I am going to be writing a book about Rails 3 and I have a general idea of what should go in it (tests first, deployment to heroku and document databases, to name a few things), but what would really make this book worthwhile to all is your opinion. I did mention that Twitter and email were fantastic ways to reach me, but really I’d rather a discussion for this, so I created a new UserVoice account for this. It’s called Rails 3 Book and I’d really like to hear from you about what you think should go in this book.

So far I have a very, very basic Table of Contents. It’s going to be a long process, but a very, very exciting one. I look forward to working with you on this book and I hope that you buy it when it comes out.

Imagine this scenario. You’re waiting at a checkout at your supermarket. It’s a pretty long line, compared to your past experiences.

Directly in front of you there’s a 22-year-old guy with medium-length hair, listening to God-knows-what on his earphones, dressed in casual gear. Probably middle class.

In front of him there’s another guy, about mid thirties, wearing a “business suit”; black pants, white top and tie. Probably upper class.

Then in front of him there’s a woman, probably around the same age as the man, but dressed like a hippie. She’s got a shirt that says “There’s no place like 127.0.0.1″. You fondly remember giggling quietly to yourself the first time you saw this shirt.

Then of course there’s the cashier. Unusually, it’s a guy with a ponytail who looks like the kind who you’d see attending computer and anime conventions.

The lady at the front of the queue puts her goods on the belt and the cashier processes them. Status quo. Then when the lady hands over the money, the cashier’s drawer breaks and falls out. Money goes everywhere. Coins roll in every which direction.

Now what the fuck do you do? Do you sit back and let the cashier run about collecting up his coins or do you help out?

Well, in this analogy, you sit back and let the cashier do it all. All of you in the queue do. Nobody helps the poor cashier.

You useless, pathetic bastards.

Now imagine this scenario wasn’t a checkout line. Imagine the people in the checkout line are actually people in an open source project’s community. Imagine, for a moment, that you’re waiting for The Next Big Release for this open source project. Imagine instead of the cashier’s drawer dropping out and throwing coins like shrapnel from a frag grenade, it’s actually tickets for this open source project. Do you know of a project like this?

I do.

It’s called Ruby on Rails. And it’s suffering because of your ignorance. It is at the moment in a place which I will steal the term “Development Hell” for and use. At current writing it has over 900 open tickets. Let me state that again because it is such a pertinent fact: There are over 900 tickets still open. So what the fuck are you going to do about it?

One little piece

It’s great that (at least in this Western world) we have things called weekends. We also have time where we are not working. Some of us have (a lot) more of it than others and generally waste it playing video games or watching TV. I’m fine with that, but there is a limit I feel before it turns from “relaxing” into “slacking off”. You have to realise that you are part of a world-wide community. You are using something developed by people world wide and it is time that you gave back.

I am sure that many of you reading this will think “I don’t know enough about Rails to do anything with any of the tickets.”

Bullshit. Fucking bullshit.

Take this ticket for instance. Guy experiences hassles with rake doc:rails on Ruby 1.9.2 and edge Rails. How do you go about fixing something like that? Well, here’s that god-damned clue you’ve been missing:

• Attempt to duplicate it. People make mistakes, because they are people. Can you see what they did wrong? Is the bug still occurring in the latest (at this point in time, 2.3.5 & 3.0.0, yes, test both!)
• If something is broken, attempt to fix it. This continues onto my third point:
• Fix it! This is the most simplest, basic, elementary thing. You know the saying “If it ain’t broke, don’t fix it?” the reverse applies. Fix the ever-loving shit of it.
• Can’t fix it? Find somebody who can. They exist. There’s a great probability that the problem is not as unsolvable as certain other problems in this world.
• Can’t find somebody? You’re not looking hard enough. Ask in the IRC channels on irc.freenode.net. Ask in #carlhuda. Ask in #rubyonrails. Ask in #rails-contrib. Ask your friends. Post on the core mailing list. Six-degrees of separation means that you have the power to find somebody with the power to fix this issue.
• Is this ticket no longer valid? Assign it to somebody who can close it. I’m now one of these people. Assign it to me and I’ll look over it.

Another thing to look at is how long the ticket has been a problem for and if it still applies to the latest version of Rails. Take for example this ticket which has been a problem since the 9th of January last year, when Rails 2.2 was the latest version. It’s still a problem in Rails 3, and this means it needs to be fixed. If one guy is suffering, how many other people who have not seen that ticket are? We must go through and judge every ticket before a major release. If I was in charge of a release process, this is how I would run the show. When I release a major version of my project, I want a clean slate, well, at least no bugs. Admittedly there may be some people who miss out on feature requests, but that’s what future releases are for.

Pissing on the fire

I think the Bugmash events are freakin’ awesome. But they only “piss on the fire”. What we need is a concentrated stream (think Amazon River) to quell the beast of 900+ tickets. Donate some of your time to the Rails project. Spend a concerted amount of your spare time this week, and next week, and the week after that, going through the tickets and finding something you can help fix. Every little bit of effort helps.

The Rails core team has only so much effort it can apply in any given timeframe, how about applying some of your own to speed up the process of bringing us closer to a final Rails 3 release?

I ask you, not as a Ruby on Rails core member (clarification: I’m not, nor desire to ever be “core”), but as a fellow Rails guy: let’s keep this Rails beast alive and kicking. Take some time out of watching your porn and actually do something useful. Otherwise, you are just another leech hanging on the side and whining about “it’s been so long between releases”. Did you ever stop to think that: “maybe there’s something holding up the release?” or “maybe there’s something holding up the release that I can help with?”.

Give back to the community that has provided this wonderful framework for your benefit.

Please.

Extra Links

Dan Pickett also has similar advice on contributing back to Rails 3. He makes a good point that if you are able to demonstrate that you have contributed to Rails that it looks awesome on your CV / Resume.

Kristopher Murata writes from the point of view who hasn’t contributed all that much to Rails, but really wants to.

Greetings YCombinator people! Thanks for making this story one of your favourites (peaked at #4). I have commented on your comments left on YCombinator and I appreciate the time you have spent writing them. I look forward to keeping up the correspondence.

Greetings also to the Ruby sub-reddit crew. Thank you for making this your 3rd most popular post and your comments (no matter how critical, all comments are good)

As a person who hangs out in #rubyonrails on Freenode a little too much of his spare time, I eventually come across repeated questions. This is why I made the channel bot which runs on Summer.

One of the hardest frequently asked question is “When is Rails 3 due?”, the next being “When is Rails 2.3.6 due?”

To be honest I don’t know, and I’m pretty sure not even Rails Core knows precisely when it’s due. Sure, they’ll have some kind of idea of when they’d like it to be released but it’s a very similar idea to mine of wanting to be rich (i.e. right now). Ideas and realities are two entirely separate worlds.

On the 1st of April, Rails 3.0.0beta2 was announced by DHH. This announcement came very nearly two whole months after first Rails 3 beta announcement.

So why so long between releases? Well, lets go time traveling.

We travel back, back through time and its murk. We land spot bang in the middle of March 28, 2006. It’s on this day that a slightly-younger version of DHH announces Rails 1.1. Oh look it has RJS. How young and foolish we all were. By we, I mean you guys of course, this was at least 3 months before I even begun getting into Rails. So Rails 1.1 was born into the world on March 28th, 2006. Right then. What about the next significant version?

The next version would be Rails 1.2, let’s jump forward to the first Rails 1.2 Release Candidate on November 23rd, 2006. This is a distance of ~20,735,982 seconds (or in more sensible terms: 7 months and 27 days) between a major release (1.1) and a the next major release’s (1.2) release candidate. Ok, so when was the next release candidate?

That would be the second Rails 1.2 release candidate. Somewhere between these two releases I joined the Rails fray. The distance between releases? ~3,715,200 (or in more sensible terms: 1 month and 13 days). They really didn’t waste much time getting this out the door, and with so many changes too! Next!

So with the release candidates out of the way DHH announces Rails 1.2. This was a mere 17 days (~1,468,800 seconds in the “old money”) between release candidate and major release. 17 days (not a pattern) later, Rails 1.2.2 is announced. On Pi day in 2007, 36 days after Rails 1.2.2 is released, Rails 1.2.3 is released. Then nothing happens for a while.

During the 30th September, 2007 A Rails 2.0.0 Preview Release is announced. Surely the 2.0 release has to be close, right?

Between the 2.0 release postings, on the 5th of October, 2007, 6 months and 19 days after Rails 1.2.3 is released, Rails 1.2.4 comes out. Then a mere week later, Rails 1.2.5 is announced and released. Rails 2 work continued through these releases, as indicated by a Rails 2 release candidate announcement in the midst of November 2007. Rails 1.2.6 was announced 1 month and 12 days after Rails 1.2.5 was. This was to be the final version 1 release before Rails 2.

On December 7th, 2007, Rails 2.0 was released much to the joy of the Rails world. 10 days later Rails 2.0.2 comes out with “some new defaults and a few fixes”. Then nothing happens for a while, again.

Then Rails 2.1 came out, on the 1st of June, 2008, 5 months and 23 days later.

Some more patch releases were made after the Rails 2.1 release. The 3rd of September is when Rails 2.0.4, the first patch release is announced, 3 months and 2 days later. On the 19th October, 2008, another patch release Rails 2.0.5 is released. This is 1 month and 16 days since the previous patch release.

Rails 2.1.1 was released 3 months and 4 days after the Rails 2.1.0 announcement with “lots of bug fixes”. It seems they didn’t quite fix all the bugs as Rails 2.1.2 was released 1 month and 18 days later. The next minor release wasn’t far off, only 28 days, and that one was Rails 2.2.

It is important to note that it is around this point in time that the Merb + Rails merger is announced on the 23rd December, 2008. This merge would grow into what we will soon know as Rails 3.

The next minor release after that was the Rails 2.3 announcement, 3 months and 24 days later on the 16th March, 2009, the first release of 2009. The next announced release occurred on the 20th July, 2009: Rails 2.3.3. Some security fixes are announced, making Rails 2.3.4 a reality 1 month and 15 days after the Rails 2.3.3 announcement.

Then we get to the most recent stable version of Rails: Rails 2.3.5. This was released a total of 2 months and 26 days after Rails 2.3.4.

Now most recently, the Rails 3 betas. The first was announced on the 5th Feburary 2010, 2 months and 5 days after Rails 2.3.5 was released, which doesn’t mean much. What’s a more relevant statistic would be that it was released 1 year, 1 month and 14 days after the Rails + Merb merge was announced. The beta was a very large and sweeping change of just about everything in Rails, afterall, this is a major release. There is going to be some major differences.

Rails 3 beta 2, announced on April fools day, 1 month and 25 days after the first beta release. DHH says that this release is “hopefully our last stop before a release candidate” but again: nobody knows.

13 days after this, Rails 3 beta 3 is released and DHH says “we’re getting close to home now!”.

Once you know the release candidate goes out you’ll know there’ll be a huge hubbub of how momentous the ocassion is. I say everyone deserves a “huge round of applause” or whatever the internet equivalent is. The amount of work put in Rails 3 over the last year and a bit is tremendous. Then people can finally start (or continue, in some cases) migrating their plugins and gems over to Rails. Personally, I look forward to the day where I can begin a new Rails application using compatible versions of Cucumber and RSpec and the latest and greatest Rails 3 code.

This post is not intended to give a solid or even a vague guess at what the Rails 3 release date is going to be. If you want my personal opinion it’s going to be another 2 to 4 weeks (from April 5th, so April 15th-May 5th) before a release candidate. Pure, utter, guesswork based on observation. The regression tickets themselves do not seem overly complex and if they are the only thing in the way of a release candidate then I cannot see there being any major delay.

May 9th update: So I was wrong about the release candidate. It happens. Things get delayed. My new guess is that they’ll release+announce the release candidate at or near the beginning RailsConf. For now, I suggest that we all start developing our applications on it now, so that we can get something strong for the community.