Mightyverse is looking for another engineer… if you or someone you know wants to come work with me coding on Rails for bit, here’s the info:

Mightyverse is building the world’s largest living language database to allow people to say anything in any language anywhere. We’re seeking a passionate, talented Ruby on Rails developer adept at understanding the scalability implications of design decisions and excited to work on a small team. We’re currently on Rails 2.0.2 and looking at upgrading to the latest, as well as adding some new features to our application. Everyone here works on a Mac… Windows is ok, if that’s what you’ve got, but you need to be completely self-sufficient in working out Windows-specific dev issues. This is a contract position for 3-4 months in San Francisco, CA.

Must Have:

  • Effective problem-solving skills
  • TDD/BDD
  • Ruby on Rails experience on a real, live, high traffic website
  • MySql DB fu
  • Stellar communication skills: in-person, skype, email, and you actually write docs
  • Experience with RESTful web services in both XML and JSON
  • Experience with localization and internationalization

Nice to Have:

  • Unix/Linux environment experience
  • Experience with ffmpeg for video transcoding
  • Ability to speak more than one language

Technologies we work with are:

  • Ruby on Rails
  • MySql
  • CSS / HTML / AJAX / OpenLaszlo / Flash
  • Cocoa, iPhone and other mobile platforms

Please forward this to your totally awesome engineer friends or send your resume to sarah _at_ mightyverse (dot) com with your name and the job title listed in the email subject line.

It has been a few weeks since I quit my full-time job and started off on my own. My immediate physical reaction was to come down with the worst flu I’ve had in years. It was a bit demoralizing to be sick for over two weeks… ugh. I also spent quite a bit of time hanging out with friends and family… it was not my intention to be immediately super-productive anyhow.

Toward the end of last week, I decided to get serious and start planning my time. Last September, I wrote about tangible time tracking and ordered some lego bricks. After my first week of lego project management, I thought I would share my process (which is a little different from Micheal Hunger’s original).

lego project management week 1 I planned 3 weeks of work with each day represented as 2×4 lego bricks (the column on the left in the picture). I found that I didn’t have enough of the skinny bricks to fell like I could comfortably “brainstorm” and I like the feel of the wider bricks. I also wanted to be able to see my plan in parallel with what I actually did. Over the last week, I added another column (on the right) for the work I actually did.

Every project has a color and I’m tracking volunteer, open source work, and the time I spend learning stuff, as well as paid projects. I’m not tracking time spent blogging and surfing the web, since I find that entertaining and I always want to do only as much as I feel like it. I also added bricks at the top right for other stuff that I need/want to do that didn’t fit into the 3 week plan, but that I might re-prioritize, spend additional hours on, or do in the following weeks. Weekends are represented as a (1×6) long gray thin strip.

I knew this past week was going to be a little crazy since I volunteered to run “yearbook club” at my son’s school (gray blocks), so I worked a bit on Sunday to get ahead of the week. I stacked those blocks at the beginning of Monday, since they were really part of my Monday plan. It was a good thing, since I ended up spending a crazy amount of time laying out the yearbook in the afternoons/evenings. I had originally not tracked the time, but then found myself puzzled that was so tired when I wasn’t doing much “work.” So, I added in the gray blocks for the time I actually did spend.

I also immediate went off plan and spent time on project yellow, but that was the right thing to do. It was great to see progress on that project with the blocks stacking up, since it was tangible recognition of why the “red” project wasn’t moving forward. The red represents the work I’m doing with Ruby on Rails, which I’ve actually divided into both red and white. Red represents work that is actually coding on the project, whereas, white is the learning and prep that I’m doing since I’m still learning Ruby and Rails. It was good to reflect that my learning-to-doing-ratio needs to be higher. I expect that to change over time, but I can easily see that this past week it was 8:5 and it may be unrealistic to even consider it as 1:1 next week.

Now that I’ve taken a snapshot of plan vs. reality, I took apart last week’s plan and stacked all of the project hours that I didn’t get done in my “future” pile and then rebuilt the plan for next week. I’m doing the lego visualization in addition to tracking on a spreadsheet. They serve two different purposes. I think it is important to track actual time spent with 15-minute increments, but planning and reflecting on time spent benefits from more of a “rough sketch.” I find planning with lego blocks gives me a good feel for what my week will be like and subsequently an effective “birds-eye view” of how I’m spending my time.

I just went through a fabulous tutorial by Daryn Holmes about routes. It is written for 2.0.2, but I found that nothing had changed for 2.2. I already had a good feel for how routes worked, but stepping through the details was very helpful.

Key points:

  • By default controllers render the view that has the same name of the action invoked.
  • index is the default action

Debugging Tips:
You can quickly see where a route ends up by typing this into irb:

>> rts = ActionController::Routing::Routes
>> rts.recognize_path("/")
=> {:controller=>"albums", :action=>"index"}

You can also go in the reverse direction to see what URL would be generated by a route. To see what URL an action will end up at:

>> rts.generate(:controller=>'albums',:action=>'index')
=> "/music"