Just got this email from the Cascadia Ruby Conference list:

Big news! We’ve opened registration. Early bird tickets are available
for $300 until Midnight, May 31, PDT. Regular registration will be $400,
and available until July 25th at Midnight PDT. After that you’ll be out
of luck. To register:

http://cascadiarubyconf.com/register

As a small aside, we know that some of you may think it’s strange to
open registration before the program is announced. Rest assured that
you’ll have at least six weeks to register after we’ve finalized the
program.

And finally, a related reminder: our CFP is open and we’re looking for
great talks. If you’re interested, head over to:

http://cascadiarubyconf.com/proposals

The CFP will remain open until May 15th and Midnight PDT. As always,
keep your eyes on our site and @cascadiaruby for updates.

If you don’t know what Cascadia is, you can check out the Cascadia Ruby Conf website and if you’re in the Vancouver/Seattle area, definitely sign up and join us!

Almost a year ago I had a grand idea to create a site that could become a canonical source for Ruby Idioms, and grabbed ruby-idioms.com, pointed it to this site, and proceeded to not be able to find the time do do much more than a skeleton rails site.

The renewal for the domain is coming up now and I have still not yet done anything with it, so maybe someone out there in the community can do better than me.

If you’re interested in doing the site, or getting the domain, please contact me at either @arcterex or by email at alan @ ufies.org. Hopefully the domain will do someone in the Ruby and Rails community some good!

So here’s a wacky idea on how Rails, Perl, Python, and everything else can be optimized to be so fast as it’d be almost instant.  Bear with me here….

1. First, you find some code, a framework, a program, whatever it is you’re into, and find a benchmark or test suite you can run on it.
2. Next, grab some sort of code metrics suite that can record the time it takes for your test suite to run through it.  Something like metric_fu, the built in benchmark module, New Relic RPM, or some other performance test system.
3. Run the benchmark and review the code metrics.  You will probably see a few “hot spots” where certain functions or operations take longer than others.
4. Here’s the tricky part, but in the grand scheme of things, just a minor detail.  Optimize the function, or the bit of the function that’s causing issues.  This could take a short time (unused code, recursive loops, something like that) or a long time (refactor, iterate, rinse, repeat).
5. Now run the benchmark again, find the next hotspot, and repeat the process until no more hotspots are found.
6. Now the code will run instantly, as you have optimized it down to zero.  Taking this method to it’s completely logical conclusion you could run another benchmark and find the next set of hotspots, or run it against the next module or part of the framework until you’ve optimized it all down to zero.

Congratulations, now Rails requests (obviously taking things like network latency into account, until you turn your now optimized optimizing brain to that problem) all run in 0.0 seconds.  You won!

^* Ok, so obviously (I hope) this is a post that is in jest, as at some point you will run up against issues that can’t be optimized, either because of latency you can’t avoid from disk loading, more database indexes vs loading from disk, the laws of physics, code complexity vs readability, etc.  It is however something though that I hope gave you a bit of a giggle (that’s maybe a stretch I admit) or a slight pause to think that maybe, just maybe this could (in some fashion) work for you for some situation.

Anyone in the Ruby community probably knows about Why The Lucky Stiff and his numerous contributions to Ruby and the Ruby community[0].  They’ll also know that a while back _Why decided to disappear, removing his code, sites, and closing down his various accounts.  In celebration of what he brought to us Today, August 19th is Why Day, in which people are encouraged to:

• See how far you can push some weird corner of Ruby (or some other language).
• Try that wild idea you’ve been sitting on because it’s too crazy.
• or others….

One thing I know you can do is to use Skype to call “coderpath” and leave a message about what you think of _Why and Why Day.   Call coderpath’s skype (you of course need Skype installed and a Skype account…).

If you’re looking for a reminder of what _Why brought to the community, you can check out whymirror on github, where most of _Why’s various projects have been restored and preserved.  Most special though (in my opinion anyway) are:

• TryRuby – running ruby in the browser, like IRB
• Why’s Poignant Guide To Ruby – The man, the book, the legend.

This is probably old news to everyone who reads this, but today I had a bit of an epiphany.  I was watching Charles Max Wood’s excellent Teach Me To Code Screen-cast and realized (after watching two parts of his “building a blog” series) that he wasn’t ever actually looking at the output of his coding, at least in the traditional sense.

The way I’ve coded since, well, forever has been like this.  I open up my editor window, and an output window.  When I was writing C code back in the dot com days this was another terminal with a “make && ./app” in it, and in my newer web application days, a browser window with my mouse hand on the reload button. After a bit of code was written, I’d either hit “up-arrow enter” for C code or reload the browser, and see what’s happened.

Watching the screen-cast I realize that Charles was doing the following (as far as I can tell, as I’m pretty new to the whole TDD thing):

• Writing a scenario or feature (using cucumber)
• Using that to generate tests (with rspec, I think)
• Running the test, watching it fail
• Writing the code to make the test pass
• Running the test, watching it pass
• Repeat…

Now the last four steps I do know about, those are standard TDD methodology, broken down into Red (write a failing test), Green (make it pass), Refactor (make the code better), but I was blown away with the realization that he wasn’t looking at the output of the code he was writing, but instead was letting the testing framework do the work, so instead of having to verify with your own eyes that the [insert web page you're interested in here] is showing properly, you have it checked programmatically, no browser needed (in fact, at the point in part two when the browser is needed, there’s that uncomfortable pause while FireFox groans and raises itself into a running state).

Is that what TDD is really about?  I’ve always imagined it as an augmentation to the previously-described way I used to code in that before I coded and reloaded the browser window you’d write the test, then the code, then the browser reload, then the test again to make sure it passed.

This is a whole new world that’s frankly thrown me for a loop, and into a fervor of reading up on cucumber.  I’m not sure how this will affect my code writing, but this makes the whole world of TDD a lot more interesting!  Course, I’ll have to re-watch the two episodes to make sure I truly grok the tools that he’s using.

Further Reading / Links

• Part 1 and Part 2 of the screencast in question
• Teach Me To Code Screencasts (TMTC hold two coveted places on my list of programmer podcasts)
• @teachmetocode and @charlesmaxwood on Twitter
• The #teachmetocode IRC channel on Freenode, come by and hang out and chat

You may have noticed that my ‘blog 6 days a week’ has lately been kinda lax lately, but I finally, finally, started work on Ruby-idioms.com.  Nothing out there public yet, but I’ve finally found the time and energy, and quite frankly, got through that old friend of mine, fear of getting stuff done instead of watching TV and reading RSS feeds, and actually got some code down on… uhm… an editor.

I figure that it’d be a good idea to start blogging the experience of building a site from scratch with Rails by a newbie (not that there aren’t a hundred of those already).  Read My Code was done in 24 hours, I figure a week or so, or heck, a day or two per feature, ought to be enough.

I started by breaking things into some steps:

1. Create the Idiom scaffold, model validation, etc
2. User authentication and login
3. User integration (edit your own Idioms)
4. Site layout, look and feel
5. Commenting
6. Tagging
7. More site layout stuff (I’m thinking this might be the hardest part for me, as I am a programmer and not a designer for a very good reason

That’s of course a bit over simplified, and I’m probably missing out something huge, but that’s the current attack plan.  All things are flexible of course.  My grand plan is to code one day, blog the results and anything interesting or challenging that I find. I’ll make sure I push things up to the GitHub project page as well.