March 2006 Archives
I am very pleased to announce Italy on Rails. The first Ruby on Rails conference in Europe. The event will be held in Rome, Italy in the fall (October or November) of 2006.
Currently there is a signup form for you to keep notified as more information develops. With Canada on Rails soon to sell out in Vancouver, BC and RailsConf sold out within a week, Italy on Rails is sure to be a very exciting event packed with hundreds of Rails enthusiasts.
I was thinking yesterday that Amazon is missing a key ingredient in their services. I want to be able to create my own store right on their site… not mine.
They have an API for uber geeks.
They have a store front for people who sell their own products.
They have a referral program.
I want a mix of the referral program and the store front without having to figure out the API. They do that for sellers now. Surely, the number of people who refer has to massively outweigh the amount of people selling their own products.
So, I create a store, mix in products that other people sell, make bundles too (CDs/books/gadgets of the month). For instance I could put together the Steve Mallett “Programming Books I dig” store.
A normal referrer could then also have a link to not just the typical banner ad thing, but a link to an entire store: “Steve’s Recommended Products”. You could do this with a bunch of seperate referrer links, but I think we all know how that would work out.
associate-o-matic may be a hack of this, but how many people have their own server & php/mysql expertise?
Amazon, Just add a 0.01% commision of all sales from these stores to my associates account. Thanks!
For those who have read Higher Order Perl, you might be interested in the work in progress which is James Edward Gray II’s Higher Order Ruby series.
James is doing his usual thing (being hardcore), and in the process has come up with 6 articles so far, many of them full of neat little tricks. Even if you haven’t read Higher Order Perl and are just looking for a little extra Ruby lovin’, this is a fine way to get some.
Being a former perl guy myself, it’s nice to see the way a lot of these things are handled so elegantly in ruby.
I was pleasantly surprised by the turnout (about twenty people) to the Toronto Rails Pub Nite. I had interesting discussions with people who noted that both the Ruby and the Rails communities are built on friendly shoulders: you don’t understand something, you ask a question and get a friendly answer. Someone else doesn’t understand something and asks a question, and you yourself are inclined to give a friendly answer now.
I’m looking forward to the next Pub Nite as a supplement to the regular Toronto Ruby User’s Group meetings on the first Sunday of every month. I’m not a Railser, but it’s good to see the community getting together this way.
Now that Ruby’s begun its march towards global domination, it’s appearing on increasing numbers of resumes. That puts most tech companies (including yours, I’d venture to guess) in a weird position, because they don’t know how to evaluate Ruby programmers. Not yet, anyway.
We’ve been here before, haven’t we? Remember back when CGI appeared on the scene, followed almost instantly by CGI.pm, and suddenly every company wanted people who knew Perl? Same thing with C++, Java, C#… a good litmus test for programming-language popularity is whether people bother putting it on their resumes. And for a while after a new one shows up, nobody can tell the wizards from the poseurs.
This is a key juncture for Ruby. If companies start hiring people with “Ruby” smeared all over their resumes, and those people go on to produce brilliant software and generally kick ass, then Ruby gets modded way up. If said Rubyists turn out to be (on average) a bunch of do-nothing kneebiters, Ruby loses big. Rubyists are out there right now, getting set up on blind dates with tech companies, and these first impressions don’t just matter for them; they matter for all of us.
What’s the worst-case scenario? Well, I used to have this friend who worked at a tech company we’ll call “FooCorp”. This is a true story: at FooCorp, the HR department decided to hire a lone cowboy programmer to write a new performance-evaluation tool for the company. The programmer they hired — who had no interaction with the rest of engineering — went ahead and decided to write it in Ruby. With much ado and fanfare, they rolled it out, and with even more ado, a thousand people spent hours entering in their performance reviews. And then, with a truly enormous amount of ado — I mean enough ado to fill several football stadiums — the shiny new Ruby-based perf tool went on a rampage and ate up everyone’s performance reviews. Forever.
Was that Ruby’s fault? Of course not. In fact I, er, that is, my friend met with the cowboy afterwards to figure out whether the disaster could be undone, and the cowboy announced: “WELL, YOU KNOW, WHEN THE SYSTEM GETS ENUFF CHAOS GOIN’ IN THERE, PRETTY MUCH ANYTHING COULD GO WRONG.” And I can’t say he was wrong, either.
Needless to say, Ruby got a bad rap at FooCorp for a little while.
I’d like the Ruby community to start thinking proactively about this problem. I don’t think I’ll come even close to solving it in this blog. Ruby is exceptionally easy to learn — far more so than Perl, C++, C#, Java, or even PHP. Oh hell, I’ll just say it: it’s easier to learn than Python. And that’s quite a feat. It means Ruby’s inevitably going to become a magnet for people who can’t program any other way. Tech companies need our help here. Let’s figure out some ways to differentiate the good eggs from the bad ones.
I’ll offer a few of my own ideas here, but obviously I can only barely scratch the surface in a single blog. I’ll start with some approaches that should work regardless of the language you’re testing for, and then talk about some Ruby-specific tests.
RubyConf ‘06 will be visiting Denver, Colorado. I’ve always wanted to visit, and now I thank Ruby Central for the opportunity.
One mustn’t look a gift horse in the mouth!
…two days of quality training in Rails, plus a half day of dedicated consultancy to suit your particular needs. Material covered will include:
- A tutorial on the Rails environment
- An introduction to the Ruby language, the language at the core of Rails
- A detailed tour of Rails, covering how to use the code generators, how to manually write controllers, models and views, and how to manage errors
- An overview of how to make use of the Rails AJAX toolkit, and use the built-in unit testing framework
Go get ‘em “all businesses in the counties of West Midlands, Warwickshire, Staffordshire, Shropshire, Herefordshire and Worcestershire.”
Thank Open Advantage enthusiastically!
Despite being complimentary: anticipating ’sold out’ notice in 3….2….1
Rails : putting CONSTANT in environment.rb - needs to be before Rails::Initializer.run for routes.rb to see it
I’m creating a CONSTANT value that I want my whole Rails app to see.
I put it in config/environment.rb, down at the bottom, just like it tells me to.
(”# Include your application configuration below”)
But - I wanted to access that CONSTANT from config/routes.rb
No luck. Wouldn’t see it. Very confused.
I moved the definition of that CONSTANT up at the top - before the Rails::Initializer.run line
Now it works.
I am eagerly awaiting the arrival of my first Mac. I actually purchased two new Macs, a new Mini as well as a MacBook pro. Both on the new Intel Dual Core architecture. And from what I can tell based on the order status, the Mini will be arriving first in a few days.
I have long awaited to get onto the Mac environment. This is in large part of the BSD/*nix architecture to run Lighttpd, Postgresql, and Subversion all seamlessly within the environment, very much identical to my production servers. Now, I must admit that it is indeed possible to run the same services on my current Toshiba Centrino laptop, but when I did give it a shot - to say it was slow would have been a compliment.
The benchmarks I have seen on the new dual core Intel’s running OSX compared to the older G4/G5 architecture, show a substantial performance improvement by at least 2 to 4 times.
So I have been doing some background research, keeping an eye out on things that come across my path that further assist my producitiy when I leap onto Mac environments, and I came across the TextMate Cheat Sheet, written by Sebastian Friedrich. The cheat sheet is a consise summary of the brand new features built in by default with the inclusion of syncPEOPLE on Rails 1.0 bundle.
Currently I have been using RadRails as my primary development environment, and have been very pleased with it so far. Kyle Shank, and the rest of the guys working on RadRails have done an excellent job, and I am very thankful for their contributions.
From what I hear, Kyle will be debuting some new features at the upcoming Canada on Rails conference as well. So whether TextMate wins my heart, or I remain faithful to RadRails, only time will tell. One thing is for certain, I am very much a fan of these Cheat Sheets that are being published for Rails developers.
There have been a rash of new versions of Ruby goodies released this week:
- ZenTest 3.0.0 - unit testing tools
- RubyScript2Exe 0.4.2 - a utility for transforming your Ruby script into a standalone executable, including the Ruby interpreter
- Mongrel 0.3.9 - an fast HTTP server for hosting Ruby applications
- AllInOneRuby 0.2.9 - a compressed executable Ruby interpreter with all necessary runtime libraries self-contained
- Nitro and Og 0.29.0 - A web application framework and database abstraction library
- rcov 0.2.0 - A simple code-coverage analysis tool for Ruby programs
This is fantastic stuff! If you’re a Ruby hacker, and you aren’t familiar with all of the projects above, you definitely should do yourself a favor and check them out.
Oh, yeah, in case you’re interested, the software is available from RubyForge.
Jamis Buck got a cease and desist letter about SwitchTower, his deployment management software. It seems that another company (I’m not linking to them, because I don’t want to give them the publicity) has used the name for teleconferencing software and thought application deployment was too close to their niche.
Last night Canada on Rails launched a new version of the website. With the re-design comes the much anticipated venue announcement.
On April 13-14th, the BCIT Downtown Campus will host a capacity of 300 attendees. And with over 50% of the seats already filled, we are expecting a sold out event.
For those that may not have heard, RailsConf sold out an impressive 550 tickets in 8 days. With the mometum growing at such an exponential pace, Ruby on Rails is carving out its niche, and proving that developers and orgnaizations as a whole are very much interested in exposing themselves to one of the most productive and elegant frameworks on the block.
So if you are one of the few that gets a chance to hear from the likes of David Hansson, Thomas Fuchs, David Astels, David Black, along with 12 other major speakers, I look forward to meeting you here in Vancouver, BC.
I keep hearing people say they couldn’t possibly use Ruby because it lacks automatic refactoring tools. And although it will eventually have some of them, there’s a class of automated refactorings that are automatable in Java but not in Ruby. This, people say, is a show-stopper.
What exactly is refactoring? I mean, it’s not a word in the dictionary.
Fowler tells us that it’s the art and science of turning smelly code into good code, in small, incremental steps. Provably correct, by construction. Algorithms for giving your code a makeover without breaking it in the process.
He gives us a nice taxonomy. He presents some good techniques, especially geared for Java programmers. Some are things we had already figured out and are habitual, and some of them are new.
Some of these “refactoring” techniques are automatable. And many of them are useful in languages other than Java. It seems Fowler and friends have stumbled on something real, something as big as OOP, almost. Or at least they were the first to market it and package it properly. Either way, we know about it now. Thank you, Fowler and friends!
Refactoring is one of the first programming books I’ve seen that talks about the almost mystical act of writing code. It takes the process, exposes all the insides, revels in it, walks you line by line through oh so many little decisions that affect code quality. These are things most people never talk about. They take them for granted. Most people talk about “architecture”. Refactoring talks about the idioms in the code we write every day. Real now-code, not planned someday-code.
It’s remarkable, really, that nobody talks about this. They leave all the so-called style choices to the programmer. Refactoring rubs our noses in the implications of our line-by-line style choices. Beautiful.
Refactoring caught my eye in the bookstore one day in 2002, years after it was published. I hadn’t read it because it was published by those UML weenies. I’ve just never been a fan. It has its uses in database modeling (maybe), but I’ve never found it useful in class modeling. And I’ve never cared for the Booch/Jacobsen/etc. crowd’s books.
Refactoring is right there, smack in the middle of that weenie series. Every time I see it, my eyes sweep across the cover without a second glance. You know the old saying!
But one wintery day in 2002, I’m in the bookstore, and I pick it up. No real reason. I’m curious. Don’t know why. Maybe I’d finally heard the word “refactoring” somewhere. What did it mean? It’s not a word in the dictionary.
“Factoring”, sure, that’s a dictionary word. You can factor numbers, or polynomials. Factoring I know. Don’t know why you’d re-do it, though. What’s “re”-factoring?
I open the book. It says local variables are the root of all evil. Perhaps not exactly those words, but it’s the first discussion I stumble across. Local variables!? I plop down in a squashy armchair, outraged, to read more. I want to know if this guy is actually insane, or merely an idiot.
On Tuesday, 2006.02.28 NYC.rb had it’s second anniversery.
Being a regular attendee of these meetings, I expected a massive celebration and indeed found one. I even managed to talk a few other guys from new_haven.rb to take the train ride into Manhattan for the event.
The meeting saw the attendance record being beaten at 28 attendees, and hosted three presentations.
Zed Shaw did a rather intense talk on performance measurements and how much programmers tend to suck at statistics. This was without a doubt an eye opener and was full of useful information. For me though, the most exciting part was trying to choke WEBrick with 40+ requests/sec.
Trotter Cashion talked about higher-order procedures which got me thinking about all sorts of neat and weird little use cases for them that you’ll probably see popping up left and right in my code in the near future (hopefully not to the excess). Trotter’s presentation slides are already online , if you’re interested in taking a look.
Finally, because the other presentations went way too well, they had that jerk who is working on that Ruby Reports thing talk a bit. ;) In all seriousness though, it was exciting to be able to show the NYC crowd what I’ve been working on and also get some feedback on some of the current functionality of Ruport. It became more of a code review and Q&A session than a presentation so to speak, but I will have a summary online of it in the near future for those interested. One cool thing is that Jim Menard from DataVision was there and we had a chance to talk a bit about some of the different features that might be worth stealing from each other’s software.
All in all, it was certainly a ton of fun. Special thanks go to Francis Hwang for starting the group and Matt Pelletier for hosting these meetings at his office. And of course, the whole group deserves a champions cheer for being a bunch of friendly, helpful, fun folks who make a $28.00 train ride from New Haven well worth the money.
Happy Birthday NYC.rb!