Jul 13 2006


Release is TOMORROW

So, here's the deal. We are going to release the alpha tomorrow. It will have almost all of the features described here (except the RESTful web services, which we are re-thinking based on changes in how Rails is dealing with XML requests). Only the gem will be available tomorrow.

Over the weekend, we'll be putting the Collaboa site up for public availability. Anybody will be allowed to browse the code and submit tickets, but the SVN repository will remain (now and forever) closed for writes. As of right now, if you want to submit a change, file it as a ticket or submit a patch via email (we'll publish a specific email account for that tomorrow).

We'll also be releasing better documentation next week, but for you early adopters, the blog posts here plus the inline documentation will have to suffice.

We might also be moving to a new domain, but if so, this site will remain up and forward over to the new site.

This is an alpha release; we expect there will be some^h^h^h^hLOTS of bugs, and some rough edges. We are releasing anyway because the best way to make Streamlined better is to get your feedback. So anybody who downloads it, please please please tell us about your experiences. Oh, and DON'T POINT IT AT YOUR ONE-AND-ONLY COPY OF YOUR PRODUCTION APP AND PULL THE TRIGGER. Early software releases should be treated like carpet cleaner; find an out of the way corner to test it and make sure it doesn't ruin the place. Make a copy of your app and use that to test, ok?

Jul 04 2006


Announcing Enterprise Ruby Studio

Justin and I will be delivering the Enterprise Ruby Studio for the Pragmatic Studio. First run is scheduled for Boston, MA, USA, Sept 11-13. You can find the outline, plus all the logistical details, here.

We're very excited to share our experiences with Ruby in the enterprise over the past few years: Rails, of course, and now Streamlined, but a lot of other things as well. Rinda and YAML are among our current favorites. We have found that Ruby has a rich set of libraries for common enterprise tasks. Equally importantly, it's the best mainstream language we know when you have to roll it yourself.

Jun 26 2006


Fixing MetaRails

Two of the examples in my MetaRails talk (given yesterday) are already out of date. Rick Olson pointed out that the "around advice" idiom has already been DRYed out a bit, and David told me that reloadable classes had been totally reworked.

I don't have time to update the slides today though -- for next 72 hours I am completely buried preparing and teaching a Java course. Don't feel sorry for me though, I get to talk about the cool parts.

Jun 25 2006


MetaRails Talk Online

The MetaRails talk is available online, and I'm on my way downstairs to present it at RailsConf 2006.

Jun 23 2006


RailsConf, Streamlined, and Getting Mentioned in the Keynote

Its always fun to be recognized, but it was a real treat to have Dave Thomas mention us during the opening keynote at RailsConf this week. I found him in the hallway later and thanked him for the kind words, and in classic Dave fashion, his response was: "No problem -- now live up to it." Dave, we hope we will.

The topic of Dave's keynote was the "3 Unsolved Problems" of Rails. His second problem was lack of good CRUD support, specifically anemic scaffolding. Its no secret that the scaffolding in Rails is what brings most people in, but is also the first thing left on the cutting room floor when people start really getting into it. We think this is a shame.

The idea of scaffolding isn't the problem; the implementation is. Companies with lots of internal projects with rapid deployment schedules (dare I say "enterprise") need a way to quit worrying about the same stuff every time they whip up a new app. Specifically, layout, relationship management, add/update/delete features, find and sort, etc. The stuff that dev teams waste thousands of hours recreating app after app, even on the same team for the same company.

We've been struggling with that problem both internally and with our customers, and we've taken the tools that we've been building over time and are going to release it as an open source addition to Rails. We're calling it Streamlined. The first public release will be at OSCON in July, but you can check out the blog now for features, futures, screenshots and technical details.

Jun 19 2006


RailsConf: see you there!

Stu and I will be at RailsConf this week. If anybody is there and wants to hook up and chat, here's a vague outline of where we'll be:

  • Thursday, we'll be helping out at the Guidebook and the InstallFest, then off to a party thrown by a Big Consulting Firm You've All Heard Of(tm).
  • Friday, we'll be attending sessions all day.
  • Saturday morning, I'm giving Ajax on Rails first thing in the morning.
  • Sunday, Stu's doing MetaRails around lunch time.

Hope to see folks there! We're excited about seeing the community come together, and can't wait to see what happens in the hallways (that's where all the fun is, anyway).

Jun 08 2006


And on the Agile topic...

Reading through the comments on Cedric's post, I came across this beautiful gem by Hani:

"it's probably no coincedence that many/most agilists (at least,that I know of, they don't tend to be a closeted species) are consultant types; an environment where maintanability is not an issue, and the fact that it takes a long time to get acquainted is a *good* thing."

As a consultant, I can tell you this: if I write unmaintainable code, I don't get invited back next quarter. If I don't contribute right away, I don't get invited back next week. Generalizations like this are just silly. Maybe there are companies that just pay out consulting fees without bothering to examine the results, but if they're out there, could somebody please hook me up? We're looking for a cushy gig.

Jun 08 2006


Agile Straw Man Receives Thorough Beating

I don't know exactly what makes a programmer an Agilist, but the straw man just got a thorough beating.

It sounds like the presentation Cedric saw was over the top. That's too bad--I've seen some smart people do a good job demoing TDD with examples like the Stack example Cedric mentions. I even sneak it into talks myself sometimes. (Admittedly the examples are toys, but usually the presenter is able to go off script and explore more serious examples.) I hope the people at the presentation Cedric mentions get some other, more even-handed exposure to TDD.

Jun 06 2006


Relevance Review #10: Programming Ruby (the Pickaxe)

Full disclosure: I have written a book for Dave, and consider him a good friend.

Like a lot of technical folk of my generation, The Pragmatic Programmer is a shining city on a hill. After reading that book, I was never the same, as a programmer, and in some ways, as a person. Dave and Andy wrote a classic.

When moving from a general-purpose, philosophical book like PragProg to a more directly technical tome like Programming Ruby, you might think that something could get lost. The great conversational style, the ability to get to the heart of problems and not get lost in the wilderness of meaningless details, the brevity, might all fall away. As the wise man said, two out of three ain't bad. Coming in at 787 pages without counting the index, the book can be called many things, but brief is near the bottom of the list.

As for the rest, I can say that this book is one of the most engaging technical books you'll ever have the pleasure to read. The Pragmatic style, wit, and insight are all on dramatic display throughout the book. In fact, they pulled off one of the greatest tricks in the biz: they made this giant technical reference book almost feel narrative. No mean feat.

When I read a technical book, there are usually two important reactions I have to the text as I read through it. "Why in the world are they covering this?" and "How could they not talk about that?" The Pickaxe simply never makes me ask the first question; everything covered in the book is easily placed in context and never feels out of place or too esoteric to be useful. There are certainly times when I asked the latter question (and still do) but it is impossible to fully document any technology, let alone a 10-year-old language and community, in a single volume. It is therefore difficult to find this to be much of a problem.

The book is broken into three primary sections. The first is the narrative portion. This is what most people will read when they site down with the book the first time. It takes up at least half of the total space, and is laden with fact and opinion. I find myself turning to it time and again to remind myself of not just how a given piece of Ruby works, but how I ought to be using (or not using) it.

The second part of the book is the standard library guide. This collects into one place every method of every class that makes up the Ruby core. This is enormously useful in a world where very few of us have IDEs with code completion for Ruby. However, I almost never use the book for this purpose, using the online version of the previous edition instead, since that gives me online search and copy/paste.

The third part is the only really flawed portion of the book. It is a reference describing all of the non-core Ruby libraries. Each library gets a page which is often barely enough to tell you what it is for let alone how to use it. On the plus side, most of the pages have a piece of example code that lets you try to get started. I understand the underlying problem; if they'd done each library full justice, the book would be another 200 pages and only 8% of the readers would have reaped any benefit. However, if you are looking for an example of how to use OpenSSL with Ruby, the page in this section isn't terribly useful.

For my money, the Pickaxe goes down as one of the finest technical reference books ever published. Its combination of wit, wisdom, style and efficiency should (and do) serve as a model for how other technical books should be written. If you write (or want to write) Ruby code, it should be laying open on your desk at all times.

Jun 04 2006


Javawin (Prototype Windows) patch

We've been using Javawin for a few months now; its a great windowing toolkit in pure JavaScript. Its good enough that, while demoing it recently, somebody complained because the modal windows still let them click. On the desktop.

One of the library's great features is configurable open/close effects per window instance. You can choose any effect from the library for bringing your window into being and getting rid of it when you are done. The latter, though, has a problem.

If you call setDestoryOnClose() on a window, this means that the instance will be terminated whenever the window is closed (as opposed to left hanging around taking up memory). However, the way the code in the library is written, this means that your hide effect will never be invoked and the window simply disappears. Here is the fix.

Change setDestroyOnClose to this:

  setDestroyOnClose: function() {
        if(!this.hideEffectOptions) this.hideEffectOptions = {};
        Object.extend(this.hideEffectOptions, {afterFinish:  
        this.destroyOnClose = true;     

Change Windows.close to:

  close: function(id) {
        win = this.getWindow(id);
        // Asks delegate if exists
        if (win.getDelegate() && ! win.getDelegate().canClose(win))

         if (win) {
                this.notify("onClose", win);

(just take out the call to win.destroy).

Popular Tags