Programming Cats

A friend of mine Tarential on IRC wrote a great article on why to choose Ruby on Rails from a PHP programmers persepective. I admit that I know a lot of this stuff already, but there’s been a lot of stuff in the past 6 months or so, so it’s nice to have some of the new stuff explained in a simple and concise manner.

So, who am I to be teaching Ruby on Rails? Good question. I’m a(n ex) PHP developer who has spent the last three months, full time, learning the RoR technology stack and using it to build a browser based CRM application for a startup I co-founded. This hardly makes me an expert, but I have a very good idea of what seems new and strange coming to Rails from PHP land.

You can read the full article here: Why I Choose Rails: A Long-Time PHP Developer’s Opinion

Photo credit: the mad LOLscientist via photopin cc

The Ruby Source site has a nice look at all the new stuff in Ruby 2.0

With Ruby 2.0 set to be released on February 24th, exactly on the 20th anniversary of Ruby’s first debut, I decided to write this article to give you a quick rundown of some of the most interesting changes. And if you would like to experiment with this version before the official release, you can do so by following the instructions in this article.

via RubySource

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.