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!

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.

• 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.

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

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.

Case in point my simple Twitter to HTML program.  When I first wrote it, it was pretty much written from the point of view of where I was at, a old and functional programming Perl coder.

So what is the difference between the styles of functional programming and object oriented programming?  For me, this meant that I was basically writing a program with no classes defined with a top to bottom program flow.  There was a “main()” (if you are familiar with C programming) which basically ran a set of functions and then ended.

Ruby itself discourages you from doing this.  There isn’t (as far as I can tell) the concept of pre-defining functions, so you have to write functions that you use before you use them.  So if you have a line that calls “foo(x,y)” you have to make sure that you have foo() defined above that in the program.  and if foo() calls bar() then bar has to be defined above foo(), and so on.  Not fun if you want to make your source code readable and nicely laid out.

Once I let Ruby’s object oriented nature take over a bit though, and defined the functionality in a class, and then just created an instance of the class to do foo() and bar() operations, it didn’t matter in what order code was assigned in the file, because the entire class is parsed by the interpreter before anything is done to it^*.

^* I’m sure this isn’t 100% true from a compiler / systems design point of view, but for the end user that’s basically what it looks like.

So what else does this give you, or more specifically, force you to do? Well, lots or Rubyist type things.  This encourages you to…

• create your programs in terms of data types (“this is a thing”)
• group functionality together (“this thing does these operations”)
• create objects that function together or off of each other (“this thing is a sub or superset of this other thing”)
• ensure your methods play nicely (ie: method chaining)

As many have said before, you can write bad C code in any language, but I had to come to the realization that just because I was writing in Ruby didn’t mean that I didn’t have to change how I was programming to take the most advantage of it.

Not that every program needs to be “objectified”, that 10 liner to parse out some some text and insert it into a database probably doesn’t need to be split into 2 modules and get 100% code coverage, but then again, maybe you’ll re-use it again next week, or maybe it’ll turn into the central convert-everything utility program for your job, and if so, wouldn’t it be nice if it was OO and tested from the start, instead of having those “extra” bits of safety tacked on after it becomes apparent that it’s more than just a quick and dirty little hack?  (For me it’s happened way too often that I don’t realize this until way too late….)

• First is the Live Blogging a Rails 3 Upgrade.  I think I saw one of these somewhere before, maybe on RailsCasts, but the closer Rails 3 gets the more you’re going to want to see these so you’ll be that much more ready to do the upgrade yourself.  Now this is a post from February I realize, so it’s a couple of months old, but still looks great and is still very relevant.  Well worth the 25 minutes to watch TopFunky do his thing.
• Second on the list is an actual new post, entitled Am I The Only One To Use a Text Editor To Edit Files, listing out some requirements and what’s available for file navigation and searching in editors today.  In a twist ending that I’ll ruin for you here, the resulting list of features has morphed into a real application that works with a host of the favorite editors for the Mac.

Great stuff all around, both blog posts (as the Peepcode blog always are) look beautiful and are amazingly laid out with great graphics and typography.

• My idea for a memory capture (ie: put in memories of your past) is, I realized, essentially a blog with a better way of adding by date (fuzzy dates).  Really, just a blog.  Do I want to end up re-writing wordpress or movable type again, poorly?
• The ruby-idioms site that I spoke about a while ago appears to have been written already over at http://readmycode.org.  While I applaud the author for getting the site out in 24 hours, he also basically created what I wanted to.  Grrr…..

Now, that’s not to say that I don’t have passion for the projects, and definitely doesn’t mean I won’t still do them (nothing says you can’t create something if it exists already).  Shows the dangers of not committing and waiting, instead of getting stuff done NOW.

Guess it’s just a bummer to get to the realization that my fantastic ideas maybe aren’t that wonderful…. Bleah.

Anyway, keep on coding out there, got some ideas here for some hopefully interesting posts coming up next week as I get better and closer to upright!