1. REST this, REST that

    May 25th, 2007

    First the movie, now the book

    As previously noted, Leonard Richardson and Sam Ruby’s RESTful Web Services is out. If you’re not already on the RESTful (Rails) path, or any other “just works” alternative, might be a good idea to equate yourself with the principles of building simple, elegant solutions that do not require a house cards tooling to work (if and when).

    I have not read the book myself, but I did get to see an early draft (thanks Leonard), so I can echo Thomas Beck when he says:

    Every IT generation has its seminal tome that transcends time and connects the dots in a way that no book had before it. For the object oriented generation in the 1980s, it was the Gang of Four (GoF) book. For the application architecture generation in the 1990s, it was Fowler’s book on patterns (PoEAA). “RESTful Web Services” will be, in my opinion, that book for the 2000s Web services generation.

    I don’t think it’s about messaging and protocols and scaling. Neither about a lightweight alternative to WS-*. And definitely not about passing the REST Compatibility Toolkit and implementing Enterprise REST 2.0 Capabilities in your next product.

    It’s about simple, elegant design principles, starting from the bottom and building your way up.

    Wired

    Speaking of simple, and this will only take a few minutes, check out Hampton Catlin’s make_resourceful presentation (PDF). This will change the way you look at Rails. Whether you plan on using it or not, there’s a lot of inspiration in make_resourceful.

    Tired

    Also of interest, WSDL 2.0 is now a “proposed recommendation”, one step away from being a recommendation, which tool vendors fondly refer to as a standard (the W3C being an organization for the publication of recommendations, does not in itself issue standards, regardless of what your RFP requested that we implement in our product).

    Although I never found WSDL 1.1 lacking in this regard, WSDL 2.0 does indeed improve on it in four areas. It’s longer, more convoluted, incomprehensible to human beings, and obfuscated, although I do believe the later is a form of text-based DRM.

    Either way, it’s a shame because WSDL 2.0 … get this … seems to have well rounded support for describing PRS(*), from first look, it actually looks completed (at least fixes all problems in earlier drafts). I’m just wondering if it’s not a too much, too late.

    PRS: Predictable RESTful Service, a service implemented by honoring HTTP verbs and resource URIs, in such a way that all outputs can be predicted before any inputs are made, and all URIs can be decided before URIs are questioned, thereby making it toolable.

  2. If Java influenced WS-*, can REST influence Java?

    May 18th, 2007

    [assaf@casper work]$ whatis ruby
    ruby                 (1)  - Interpreted object-oriented scripting language
    ruby                (rpm) - An interpreter of object-oriented scripting language
    ruby-bdb            (rpm) - Sleepycat Berkeley DB and DB XML
    ruby-devel          (rpm) - A Ruby development environment
    ruby-docs           (rpm) - Manuals and FAQs for scripting language Ruby
    ruby-irb            (rpm) - The Interactive Ruby
    ruby-libs           (rpm) - Libraries necessary to run Ruby
    ruby-mode           (rpm) - Emacs Lisp ruby-mode for the scripting language Ruby
    ruby-mysql          (rpm) - A Ruby interface to MySQL
    ruby-postgres       (rpm) - A Ruby interface for the PostgreSQL database engine
    ruby-racc           (rpm) - LALR(1) Parser Generator
    ruby-rdoc           (rpm) - A tool to generate documentation from Ruby source files
    ruby-ri             (rpm) - Ruby interactive reference
    ruby-sqlite3        (rpm) - A Ruby interface for the SQLite database engine
    ruby-tcltk          (rpm) - Tcl/Tk interface for scripting language Ruby
    [assaf@casper work]$ whatis java
    [assaf@casper work]$

    One of my pet peeves about Java is he choice to separate itself and live in a bubble, isolated from the operating system. I got used to it over the years, but working on Buildr opened my eyes to the discrepancy. Lower common denominator, reinventing that which already exists, and layers upon layers of “value-added” infrastructure. I can see how that influenced later works.

    Bill de hÓra:

    REST isn’t even the real lesson; the real lesson is applying principled software design and architectural styles to problem spaces; it’s about getting off fads and hype cycles that infect the industry.

    If there’s a lesson there, I hope we’re going to apply it wider and wiser, to more fields than just our choice of firewall-piercing protocols.

  3. Off to Portland

    May 17th, 2007

    Packing up and heading to Portland … you know why … see you there Friday/Saturday.

    (Shoot an e-mail if you want to plan something, exchange phone numbers, etc)

  4. Virtual XP on Linux

    May 15th, 2007

    swim3.png

    When you use your computer as often as I do, you grow attached. Which is why I treat mine to the best. A comfy padded bag to carry it, quality products to clean it, fresh batteries to keep it energized, and of course, Linux.

    But once in a while we all have to make sacrifices. I’m doing interoperability testing, and have no choice but to run XP. The challange: convincing my pampered and spoiled PC to play along and boot Windows XP.

    Wanting the best, I decided to go with Parallels. I set it up for the wife on her Mac. A pleasure. In fact, the hardest part of getting Parallels to work on the Mac was paying for the license. No seriously, they need to do something about their order process. Still, it’s a blast to use. Sadly, it won’t install on Fedora 6.

    Sigh.

    Asking around, I found out a little gem called QEMU. Like most open source products, you manage it using command line tools and whatever little documentation you can find. Not a big deal, and a couple of hours later I have Windows running in a window under Linux.

    I used it for about a week until QEMU worn out its welcome. For starters, it’s slow. Sometimes painfully so. Couple of hours to install XP should give you an indication of things to come. Another sign: even when idling, it eats up 99% CPU and drains the batteries flat. And it can only run on one of the Duos.

    The SMB share worked fine for a while, then one day, decided to stop. Opening an SMB folder would freeze it up. Many a restarts later, I still couldn’t get it to work. Then there was the issue of losing the network routing each time I went offline. Every time I hibernate, I had to reboot Windows. Just like using the real thing.

    So I gave up and started looking for a better answer.

    Googling some more landed me with Xen. Xen is actually a separate kernel which VMs Linux itself. Booting into Xen felt a bit odd, with progress indicators all spinning at warp 9, and a dozen new network devices. I played with it for a while, couldn’t get the QEMU image to boot, and switched back to ye good ole kernel, only to discover that Xen dances to its own beat. My system clock was two hours off.

    In all fairness, Xen is more for virtualizing servers, not exactly what I was looking for.

    Next, I tried VMPlayer from VMWare. Officially, not supported on Fedora, unofficially, installs after running the vmware-any-to-any patch. Theory states that it can run the same XP image created by QEMU, but a few minutes of fiddling around with configuration files, and all I got was this lousy blue screen of death.

    Well, I didn’t expect much from an unofficial patch.

    By chance, I’m cleaning up some old bookmarks, and bump into an announcement trumping VMServer. Same VMWare, different product. And yes, I do feel stupid for missing it before. Since VMWare doesn’t officially support Fedora hosts, I set my aims on their free to use product, not realizing there’s two of them.

    Problem #1. The RPM doesn’t work, but somewhere I read that the TAR does. Problem #2, the vmware-any-to-any patch does little good, it installs but the server refuses to start. I Google for a patch that requires untarring, editing and re-tarring one of the modules. Half an hour later I get it to run, image created, XP installing.

    It doesn’t feel like QEMU at all. It’s fast. Feels as fast as running XP native, but without the social stigma. Tweak the settings and it’s taking advantage of both Cores, yet wastes no CPU idling. The network works, and doesn’t particularly mind that I go offline several times a day.

    So. Much. Better.

    SMB sharing works. It’s Windows slow, but it works. And you absolutely must install the VMWare tools on the guest OS. With this little helper, it grabs focus when I move the mouse over the window, releases it when I move the mouse away. Much more productive than Ctrl-Alting in and out. It can also shrink down the image size, useful as it turns out I pre-allocated twice the disk space I needed for my XP setup.

    What did I learn?

    .. Performance matters, you won’t enjoy using a slow virtual machine for any length of time.

    .. A checkbox feature and a working feature are not the same.

    .. The open source alternatives are not that bad for small stints, just not good enough for the long runs.

    .. “Unsupported” depends on your ability to Google a patch.

    .. The mouse focus grab/release feature is more important than I imagined.
    .. If I had to do it over again, I would start here.

    Next stop: booting OS/X.

  5. Rails Envy

    May 14th, 2007

    You can thank Gregg and Jason for this gem.

  6. The inevitable migration of framework coders

    May 13th, 2007

    This post spurred an e-mail exchange with Giles. If I get his conclusions right, he’s ranting about the imminent en masse immigartion of framework coders over to Rails. In his opinion, a problem with the Rails culture. In my opinion, an inevitable side effect of being widespread.

    You can tell a framework reached its tipping point when it’s talked about by skilled developers, but they’re outnumbered by framework coders.

    Framework coders. You’ve seen them before. You walk by their desk and admire the hefty collection of development books stack on their shelves. They cover just about every topic worth of attention, from SQL to XML, from building Web pages to RIA, from language to protocols. Yet one thing tells them apart. Each time you walk by their desk, you notice these books are stacked nicely on the shelve. There’s only one book on their desk lying flat open to some random page. The Framework Book.

    Framework coders are top to bottom problem solvers. When they have a problem to solve, they attack it by starting from the top of the stack. That framework book that’s open flat on their desk. Some framework start there before attacking their shelve for deeper answers. Some framework coders go so far as to place an embargo on all but The Framework Book.

    In some respects, framework coders are just like every one else. We all have an infinite capacity for learning and retaining information. Where they differ is in the way they make up for that humane deficiency.

    Let me tell you a secret. When I first started working with Ruby, all that meta-programming stuff just flew by me. I couldn’t understand exactly how class << self works, or how to use it properly. I didn’t even notice method_missing until way later. And to this day, I’m still confused on the difference between include and extend and how they affect constants.

    So when it came time to speed things up and invent a little DSL, I had to pay the Pickaxe book a second read. And a third read. And some frequent visits since then. And that’s not the only example. I still refer to the SQL docs, the HTTP spec, lookup the finer points of HTML. I can only remember so much.

    Of course, if I was a framework coder, none of that would happen. My first read through the Pickaxe book would be the last one. The week intensive learning of SQL would have been my last experience with it. What I learned once would carry me through the rest of my career, and I would never been the wiser.

    Framework coders are efficient developers. You can’t say they’re not. They optimize their time by getting the code to just work. A framework coder would be content writing this:

    Order.find(:all, :condition=>"closed").each { |order| order.destroy }

    Efficient coding, one statement to remove not just the orders, but cascade and eliminate all the related dependencies from the database. It’s also a very wasteful use of CPU and I/O, performing N statements (deletes) over M tables (relations). But to know that you need to understand the resulting SQL and how databases work. And it’s not in The Framework Book.

    Framework coders are bound by the framework. Truth be told, none of that would be a problem if the framework implemented an efficient cascading delete method. But frameworks are never perfect. The moment they get to do one thing for you, you’re already moving to bigger and more complex applications. A framework is never good enough, you always need more than it provides.

    It’s no wonder framework coders flock towards frameworks that promise the one efficiency they care about most: writing less code. And it’s no surprise Rails is a major attraction for framework coders that bring with them their lack of skills and bad practices. Just like any other framework before it, just like the framework that saved them from developing those skills, that promoted those bad practices.

    But there’s one point where I disagree with Giles. No framework will ever develop skills in those who refuse to learn and apply them. And no framework will promote the right choices in those who refuse to understand the consequences of their actions.

    Framework coders do not understand the affects of their code. A good framework can give you the tools necessary to write efficient SQL, to use SQL wisely, to produce clean HTML. But that same framework will also let you write disk thrashing SQL, worse than binary XML, and GeoCity quality HTML. Frameworks do not distinguish between good and bad.

    To choose one or the other, you need to understand the result of the choices you’re about to make. You need to describe the SQL, inspect the XML, qualify the HTML. You need to play judge to the results of your actions, you need to understand the bottom of the stack. It’s a dark place that framework coders refuse the enter. They just write code and hope for the best.

    Framework coders are forever bound by the framework, forever using it to random effect. Frameworks come and go, but the unskills of the framework coder endures. Being critical of framework coders, teaches us nothing new about the framework, the language or the platform. All that matters is whether or not the framework helps you manifest the skills you already have, and plan to keep on developing.

  7. WADL Poll

    May 10th, 2007

    WADL is:

    [A]mazing! Just what we need to make REST useful to the masses.

    [B]rilliant! Just what we need to make REST more WS-* like.

    [C]lever! Just what we need to productive REST.

    [D]elicious! Another way to outsource code to XML.

    [E]rr .. waht?

  8. And now for something totally different

    May 10th, 2007

    Nearly 1,000 copies of the Framingham State College student newspaper were stolen by students embarrassed by the journal’s front-page photo of them as bare-bellied FSC lacrosse fans attending a recent home game.According to Desmond McCarthy, an English professor and the paper’s faculty adviser, school members said some fans depicted in the photo believed they looked fat.

    MetroWest Daily News

    That’s the stupidest thing I’ve heard. Who can be that shallow? Haha.

    Yeah, I know. I did remove some code from SVN because I thought it looked fat and ugly, and I didn’t want the world looking at it. But that’s totally different. It’s not swiping. It’s refactoring!

  9. JavaFX: Pass. Maybe in 2.0.

    May 8th, 2007

    If I understand it correctly, JavaFX is Sun’s answer to Flash. I just can’t seem to remember what the question was.

    It’s not exactly Java and not exactly JavaScript, which is not a problem per se. But it doesn’t pick up the best traits of either one. It’s closer to JavaScript in capabilities, and it fixes some of the obvious flaws in JavaScript. Shame they didn’t fix JavaScript itself.

    Take for example the JavaFX object notation. From a distance, it looks just like JSON. Yes! Move closer. It’s just different enough, so you can’t send a JSON response to either JavaScript or JavaFX client. We don’t even know it’s useful yet, and already we need to write more server code.

    There’s something very simplistic about JavaFX. I’m thinking, if someone wanted to write the BASIC equivalent of Java, what would it look like? The BASIC I remember had very few basic types. It had functions, and separately it had operations, which it called GOSUBs. Uncanny. I guess, time to dust off my BASIC skills.

    JavaFX takes some ideas from other languages and implements them in a simplistic, pre-canned way. There’s list comprehension, but only for certain values of comprehension. Closures, but only over arrays. Which are not matrixes, and don’t double as hashes. There’s deffered work, but no way to control it.

    It’s as if someone wanted to create a simpler Java. But instead of working towards a language that makes software development simpler and easier, they dumbed the language down.

    There are some smart features, but they’re baked into the language. So it’s either enough for all your needs, or you need to look elsewhere. And that’s the problem. Pick it up, write your first 100-line application, see how easy it is, maybe even have fun. But for the next app, you might spend an unnecessary 100 lines just working around a built-in limit of the language.

    Perhaps there’s more to it. The triggers, the insert/update methods, the select statements; I’m guessing native XML and SQL support baked into the language in the future. Maybe it will grow up to be a real language. But right now, it looks like some fish and salty chips, but not enough rods.

    (It is open source, though, which keeps me from saying “no thank you, pass the BBQ sauce”. Let’s see what the community can make from it.)

  10. Patience, Buildr docs coming up

    May 7th, 2007

    Right now if you go to the Buildr web page, it redirects you to the RDocs. As Steve Ivy says:

    This reminds me of the bad old days when all Java code just shipped with the JavaDocs and that was “enough”. The API is not the documentation, folks. It’s a useful part of the documentation, but it’s not enough.

    I agree. RDocs are not acceptable documentations.

    RDocs are reference material, information you need after you know what you’re looking for, and just need to quickly find it.

    As part of developing the code, I also wrote a getting started guide for Buildr. It ended up reading like a WS-* spec. Bad. And it fell out of sync with the last set of changes to Buildr. Also bad.

    So I’m rewriting it from scratch. To be readable, usable and friendly.

    Except an official Buildr announcement later this week that will include usable documentation. One you can actually learn from. Hopefully, one you’ll enjoy reading from.