Entries Tagged 'rubyonrails' ↓

My first freelancing gig is with the folks at Unspace. Hampton convinced me to move to Toronto for a couple of weeks to work on CommunityLend. It’s an exciting project, check it out.

Email me if you are in Toronto and would like to meet up.

I had dismissed Heroku as a toy after getting my first invite, a glorified web-based Texmate to let you code rails applications.

After Ruby Inside mentioned their new API, I gave it another look and had to change my mind. It looks like they’re set to really nail the issue of rails deployment and scaling. A git mirror, with deployment and scaling - for free!

Should OpenId support in Rails ever get really worked out (see #10604), it will become trivially easy to code and deploy small applications. Ideally, a programmer’s time is spent on modeling the business domain and creating a simple UI - not on incidental complexity of project management overhead.

On a recent project to track my wine tastings, I have been using git along with a plain text file to keep track of bugs and to-dos. bugs.txt file got checked in to the git repo; it’s simple and It Just Works (TM).

If dealing with capistrano and server configuration was getting you down on your week-end projects, check out Heroku. For your next week-end app, it might just be the thing - and they promise to keep growing capacity so if your baby grows up you may be able to stay with them.

Aaah, never having to worry about deployment again.

At Montreal On Rails #7 one presenter had to use Marc-André’s computer to do his presentation and was surprised by the fact Textmate wasn’t showing the vendor/ folder.

If you freeze all your gems in vendor/ as we do, search becomes so slow as to be unusable. Here’s the pattern to use to avoid the vendor folder:

!.*/(\.[^/]*|CVS|vendor|log|_darcs|_MTN|\{arch\}|blib|.*~\.nib|
.*\.(framework|app|pbproj|pbxproj|xcode(proj)?|bundle))$


Plug that in Preferences-> Advanced -> Folder References -> Folder Pattern

The downside is that if you want to search for a file in vendor you have to open a new instance of textmate

We lived through crunch mode and the site is live. Since we’re no longer in stealth mode,  I can now tell people what I do. Well, after I kvetch a bit.
We found out the issue we were having had been reported 4 days ago as Bug #10926. We have only managed to replicate it in our production environment, but not in staging. The consequence for us was a 404 (page not found) error when logged in users tried applying for a job. While we did work around it, let’s say that error pretty much sucks for an app that’s supposed to help companies hire people.

It was a horrible type of bug to track down. The only difference we could see? More Mongrel instances, and a 64-bit version of the OS.

• Is it in Rails’ incredibly complex routing code?
• Our own subdomain support?
• Is Capistrano doing a clean restart and getting all the Mongrels running the same version?
• Is caching an issue?

Unable to replicate the bug on staging and given it only appears randomly (1/3 to 1/2 of the refreshes, both hard and soft),  it’s the kind of experience you want to avoid on launch day.Anyhow, the site is live and the inflow of bugs has slowed. We’re still madly fixing any issues as they get reported, and we’ll have refinements over the next few days before we tackle new functionality.

Overall this is a great success. I’m happy to be working with this ‘A team’, and will have more stuff to share as soon as things calm down.

I don’t usually worry about performance. Today, when a simple AJAX request sending back an empty body took 2 seconds to complete, I started digging.

Oddly, Firebug indicated over 2000 ms, while my log showed under a half-second. Since it’s on the same machine, there’s no way network issues can account for 1.5 seconds. I tried several avenues, and Marc-André suggested several possibilities before suggesting running it in production mode.

We were both suprised at the difference. Before / after:
Firebug: 1755 ms

Log: Completed in 0.47638 (2 reqs/sec) | Rendering: 0.00010 (0%) | DB: 0.15976 (33%) | 200 OK [http://standoutjobs.dev.com/****]

Firebug: 121 ms

Log: Completed in 0.11076 (9 reqs/sec) | Rendering: 0.00007 (0%) | DB: 0.06037 (54%) | 200 OK [http://standoutjobs.dev.com/****]]

A full order of magnitude! I’m used to logging and other debug overhead to have about a 10% performance hit, so this was very surprising.

If you’re like me, you have some personal web apps running in development mode. My first instinct was always to look at the logs, and see if there are some unnecessary requests being done, or anything that is taking far too much time. There’s also Marc-André’s tips for improving rails app performance. Still, those are a lot of work compared to the simple step of setting that production flag.

How do you create a rails project if you don’t know the schema in advance?

Jerome had a really unusual set of business requirements for his first rails project: customers that will each have their own dedicated server, and have to be able to specify their client list schema through a web-based interface.

That’s a pretty ambitious task for a first rails project, don’t you think? Here’s my take on the problem. If you have a simpler solution, please propose a refactoring.

At 1.4 seconds, the ITA puzzle solution I dreamed up while on codeine was already fast enough. Since the pain has subsided and I stopped taking the damned pain-killers, I thought I should go back, optimize and clean up. The code is now shorter, and runs about 10 times faster.

The new version is also on refactormycode, where you can critique and suggest changes.

If you want to see different approaches, there are other solutions and discussions of this puzzle in various places.

The optimizations I made were guided by ruby’s own profiler (invoking ruby with the -r profile flag ). The first time it ran, I felt a tinge of embarrassment, seeing that format_units was called 248,440 times, accounting for over 43% of the computation time.

$ruby -r profile ita.rb

  %   cumulative   self              self     total

 time   seconds   seconds    calls  ms/call  ms/call  name

 43.87    84.78     84.78   248440     0.34     0.50  NumberWriter#format_units

 17.99   119.55     34.77   134583     0.26     1.29  NumberWriter#write

...

Caching the 1,000 potential return values for that function in an array immediately brought the execution time down under a second. Optimization can really be that easy sometimes.

Most optimizations were done iteratively, taking whatever operation was taking the most time and trying to find ways to reduce its footprint. When code started getting messy and verbose, I re-factored and got another speed boost. Overall, the exercise was amazingly easy, taking less than 2 hours of total time without involving any complex code.

What astonishes me is that there is still low-hanging fruit for anyone that would want to make this even faster. Half the time is now spent sorting. A better profiler would definitely help, as the one available out of the box only breaks things down by function. However it’s clear that the profiler’s top 5 results could be mostly avoided if string representations of numbers and ranges didn’t have to be created to sort them alphabetically:

$ time ruby -r profile ita.rb

  %   cumulative   self              self     total

 time   seconds   seconds    calls  ms/call  ms/call  name

 31.13     4.84      4.84    64521     0.08     0.15  ITA::Number#<=>

  8.49     6.16      1.32        3   440.00  3676.67  Array#sort

  8.10     7.42      1.26    68831     0.02     0.03  ITA::Number#to_s

  6.43     8.42      1.00    61704     0.02     0.03  ITA::Range#to_s

  6.30     9.40      0.98     6178     0.16     0.33  ITA::NumberWriter#write

  5.14    10.20      0.80        4   200.00  2850.00  Array#each

  4.63    10.92      0.72    64521     0.01     0.01  String#<=>

I don’t feel the need to push this puzzle any further. If you do, go for it, and please share on refactormycode.

It’s on the company blog, and Marc-André blogged about a typical day here at the office. We need another Ruby developer - either a “Guru” or a “Devotee”. I wasn’t going to blog about it, having sent email / IMs to people to encourage them to apply for work here.

The answers I got were surprising. The main question was around compensation.

Here’s the scoop: pay is above average for Montreal. Plus benefits. Plus stock options. Plus working with an awesome language, a beautiful framework, under good working conditions (read Marc-André’s blog post!)

Now, here’s scoop #2. Marc-André and I will also be interviewing candidates. We have high standards: we are looking for other passionate people. We want people that enjoy coding and are continually learning.

If you don’t have passion, you shouldn’t bother applying. If you do, we expect you’ll have code to show us - although it might be Python, Erlang, Javascript or another cool language.

Marc-André’s presentation last night at Montreal on Rails rocked. He tackled the issue of making unit tests faster by mocking web services.

It was a timely presentation, with at least one RoR shop in the city feeling the pain of testing models that depend on those services. When tests run slow and are difficult to write, we obviously want to write fewer of them.

Ben and Fred at Standoutjobs got me to move from Quebec to Montreal to become a Ruby Guru. I will be guru #2 after the very talented Marc-André Cournoyer. Like him, I now have a standard-issue MacBook Pro with a second screen.

I was very reluctant to leave beautiful Quebec city. I had a great apartment downtown on St-Jean street and was looking forward to a summer chilling on terraces.

They have a convincing pitch, and the project is ambitious. Ben, Fred and Austin have all had previous business success. With such a track record, and by recruiting people like Marc-André, they are very likely to succeed. This should be fun, and a great learning opportunity.