-
January 30th, 2008
Ruby actors. I started playing with Ruby 1.9 to re-work message-passing processes to use fibers instead of continuations, and find a faster IPC implementation than DRb. Tony Arcieri did Revactor. So I’m checking that off my plate. Revactor does exactly what’s needed, has excellent documentation, and a promising roadmap that heads to the innards of Ruby.
myactor = Actor.spawn do
Actor.receive do |filter|
filter.when(:dog) { puts "I got a dog!" }
end
end
Also check out Pat Eyler’s interview with Tony Arcieri, with a longer example.
MemQueue. Speaking of distributed workload, this looks interesting:
Starling is a light-weight persistent queue server that speaks the MemCache protocol. It was built to drive Twitter’s backend, and is in production across Twitter’s cluster.
Catching up. Robert Hook commenting on WS-Enterprise, 2008:
Thus, I posit a problem from the Real World ™: the project timelines for non-trivial environments are longer than the period of introduction of The Next Great Thing To End All Things. There are lots of people out there building systems nodding and saying “Yep. REST is better than SOAP. Might look into that in a few years when we get this one finished”.
I think the lifespan of The Next Great Thing To End All Things is about two sale cycles, or four quarters. Though I might be wrong. It might be three.
Locked down. That’s the nature of the game. If you’re going to make progress, you’ll want to know what lies ahead, where to go next. The people who can point you there are the ones not locked-down to yesterday’s technology:
The SEs, most of whom worked only in Java and C++, kept looking at it and scratching their heads. They’d say, “Hey, you forgot to do this!” and I’d say, no, that happens right here. And they’d say something similar about another required action, and the answer was always the same: no, it’s in there. Basically, Ruby allowed me to hide a bunch of crufty, verbose, uninteresting but required boilerplate and focus only on service interactions. Waaay nicer than the equivalent Java and C++, for sure.
On a personal note, I’m currently locked down to yesterday’s technology. Fortunately, my Verizon contract expires in March, and I already planned on the Next Great Thing. It’s all about timing.
USDP. A lot has been said about writing code vs reading code. Oliver Steele nails it with The Programmer’s Food Pyramid.
Posted by Assaf
Filed in general
-
January 30th, 2008
Cross-pollinate. Andrew Chen on the rake-devel mailing list:
I just released FRUIT, a FORTRAN unit testing framework on
sourceforge. (https://sourceforge.net/projects/fortranxunit/)
The FORTRAN stuff was not exciting, but those 2 points are worth mentioning:
1. Rake is really a flexible build system. It can handle many things over make file, such as handling generated source codes. It is astonishing to compare the size of rakefile and makefile (about 30 lines vs. 500 lines). I used one technique of rake_base, so that all common tasks are defined in this file, and each rakefile includes it.
2. I implemented rSpec features in FORTRAN, that is pretty cool :-) So that someone who have to do FORTRAN can make TDD, and executable requirements!
Rails SDB. Martin Rehfeld adds another option for using Amazon’s SimpleDB from Rails. Much like DeHorrible, it’s a proxy service, and Martin shows you how to use it from ActiveResource. But DeHorrible is mainly “applying REST couldn’t be that hard, could it?” commentary/experiment, Martin’s code looks more like something you’ll want to use in real life.
SOA lives on. Through the mainframe. Or was it, mainframe lives on through SOA? You’ve got to wonder, who’s hanging on to whom for dear life.
Aguri. Two things binary radix trees can do. Search performance that depends on key size, not tree size. And lexicographic matching. Aguri starts there and adds heuristic to balance the tree into optimal search paths. Pretty nifty and I can think of a few use cases not specific to routing.
Halting poetry. The halting problem explained in poetry. Wonderful and funny and only lacking a sound track.
Picture, the bad usability calendar (via Zoli)
Posted by Assaf
Filed in general
-
January 28th, 2008
First, a quick announcement. We’re wrapping up Ruby In Practice and heading towards final review. Finally.
If you already bought the early access edition from Manning, you’ll get a new PDF with the remaining chapters. If you didn’t, Pat Eyler is running a blogging contest and giving away a free copy. The rules are simple: blog about your Ruby In Practice adventures, and let Pat know about it. I’d love to hear about your experience with Ruby.
With so many Ruby books on the shelf, we decided not to focus on the language itself, but cover the things you use Ruby for. Most of the topics we cover in Ruby In Practice deal with business applications. Yes, that dreaded enterprise stuff. But why not, when Ruby helps you do things simpler and better?
If you’re still sizing up Ruby for your next project, here’s a few things we get to cover in the book (and a couple we don’t).
HTTP and REST
Although some people confuse them, HTTP and REST are not one and the same,and we keep to that distinction.
We have one section dealing with HTTP and covering the basics: URI, open-uri, Net::HTTP, Mongrel. The REST part expands on it to deal with resources and representations, and does so using Rails 2.0 and ActiveResource.
One reason we picked Rails is the wonderfully pragmatic way it uses HTTP and REST. It’s a smart application of Web Architecture practices, one I can point to people and say “here, learn by example”. Even if Rails is not your cup of tea, I recommend looking at it inspiration and ideas. Other people’s experience, amplified.
SOAP
Wish I could say the same about SOAP. Let me summarize SOAP4R: it smells like Java code built on a Monday morning by an EJB coder.
To its defense, once you get SOAP4R working, it does what you expect it to do. It’s just not pretty, simple or fast about it. SOAP4R is WS-I compliant, so you can use it to interoperate with Java and .Net. In the book we show you how to use it effectively, but clearly SOAP4R is not going to win you over to the WS-* side. If anything, you’ll learn to appreciate the simplicity of REST even more.
There’s also ActionWebServices. Although it cleans up the SOAP4R API, it does so by using Ruby annotations and focusing on RPC-style services. If you are using SOAP, at least do it right with contract-first design and doc/literal messaging. We start the example with a WSDL service definition which we use to generate the client and server code, and SOAP4R was the best option we’ve got.
Two recent additions that appeared too late for inclusion in the book are WSF/Ruby (Axis/C with Ruby bindings) and using JRuby in combination with Axis/J.
Axis has killer support for SOAP, WSDL and various other WS-* specs, not to mention performance and stability. All good things, but right now both options mean working with the low-level APIs. It feels more like coding in C and not what you’d expect to find in Ruby.
For the motivated, here’s a cool project idea. Build a Ruby Goodness WS-* API that can use SOAP4R, WSF/Ruby or Axis/J as the underlying stack. I’d love to see something like that.
And speaking of Ruby Goodness APIs for enterprise messaging …
WebSphere MQ
WebSphere MQ is one software product that captures so well the essence of Enterprise computing. That thing has more knobs and switches than a Boeing 747 cockpit, legacy support going back to the ENIAC, and command line tools that only its mother can love. It comes with an Eclipse-based management tool full of usability mistakes that refuses to admin anything (on my machine, at least).
On the other hand, it’s WebSphere MQ. It has all the options you’ll ever need, broad platform support from PC up to the biggest meanest of mainframes, and everything can be managed from the command line, or scripted. So what’s
not to love?
I know what you’re thinking, WebSphere MQ and Ruby are the opposite extremes, putting both in the same room would be an hilarious blind-date gone bad. It so turns out the two have great chemistry.
J. Reid Morrison developed a beautiful Gem, literally, and in the span of a few hours working with it, RubyWMQ became my favorite add-on feature for WebSphere MQ.
RubyWMQ is a thin wrapper around the C client library. I always preferred working with the WMQ API over the complex abstraction that is JMS. Call WMQ::QueueManager.connect to establish a new connection, WMQ::Message.new to create a new message. No JNDI lookups, factories, sessions, just WMQ served straight up in all its glory.
Here’s the surprising part. Even though the entire thing is written as a C wrapper on top of a C API, it has all the right Ruby idioms that make it such a productive pleasure to use.
One example we get to cover in the book:
queue.each(:sync=>true) do |message|
puts message.descriptor[:msg_id]
puts message.data
end
Guess what happens when the processing block raises an exception? It moves to process the next available message, while letting WebSphere MQ deal with re-delivery, backout and dead-letter queuing of the failed message.
The simplest processing loop you’re going to write will buy you the reliability that WebSphere MQ is known for. No heavy-weight app servers, no XML inversions, just simple, intuitive code.
It gets better.
ActiveSalesForce
Knowing what a pain WebSphere MQ is, I set aside enough time for this exercise. Installing the beast took forever, but once I got to the Ruby part, everything just flowed and I ended up with time to spare. So I decided to up the stakes.
The WMQ example consisted of a small Ruby program that collects XML messages from various applications and stores them in the database. What would it take to create these records in SalesForce?
One line of code and one configuration change later, and I’m running the program with messages coming over WebSphere MQ and sales leads popping up in my SalesForce dashboard.
Couldn’t be simpler.
Wrap Up
When it comes to Ruby, REST support is ahead of the curve, SOAP support is as bad as most other languages, and nothing like what you can expect with Java/.Net.
You’re also going to be disappointed if you live for the rush of setting up an ESB that can JMS messages on one end and JCA on the other, coding for generic APIs, and writing XML configurations like there’s no tomorrow. Ruby favors simple steps to get the job done over big infrastructure purchases.
But how well do you know Ruby? Just a scripting langauge that can also serve Web pages? Think again. Ruby got skills, the little language can do serious heavy lifting. How many languages you know that can wire your message bus to online services with just a few lines of code?
Posted by Assaf
Filed in ruby
-
January 18th, 2008
Head over to Ryan Tomayko for an excellent summary of the debate over REST and IDL:
WSDL is basically every bad idea anyone ever had related to service documentation/description, schema, and/or discovery all rolled nicely into a document classified as a “recommendation”.
I picked on this particular sentence because to me it sums up the discussion in a nut shell. We do need an IDL, or maybe more than one, I’m not seeing evidence to the contrary. But we’ve all been burned by the horror that is WSDL, and the particular way people use it to do RPC over HTTP, that we’re cautious to try again.
Some took the lesson from WSDL that a service description language is only good for generating revenue from licensing ever more complex products. I took a different lesson.
That you start by solidifying the ideas of what you want to express, before deciding how to express it. Best practices should come before arguing RDF vs JSON and elements vs attributes.
The Atom Publishing Protocol specification is an IDL for a specific type of service. It happens to use a well known service definition language, called English, which unfortunately is not very tooling friendly. But it packs a lot of best practices. A good IDL would let you describe APP fully and precisely.
What we need is a few more Atoms, a big enough set we can use to distill ideas and decide what — not how — we need to capture in that IDL. Writing a language, or several languages, from that is an easy deal.
Otherwise, the temptation to create a language that has concise form in JSON but lacks important features, or is semantically rich in RDF but follows the wrong practices, or uses Microformats but only on Sundays, is too overwhelming. In all that syntax, it’s hard to see the semantics.
So far most of the suggestions I saw are turf wars in disguise, arguing for this syntax or that, but never for what it should describe. WADL so far looks like one of those best-for-my-platform choices, the constant mentioning of Microformats, which are not optimized for this task, is another danger sign.
It has to start somehow, but it better start with substance, not with style.
Posted by Assaf
Filed in general
-
January 18th, 2008
Buildr on JRuby. For a while it looked like Buildr managed to hit every JRuby bug and then some. Most tests would fail, and that would only happen on days JRuby actually managed to load Buildr and its dependencies. Well, that’s history now.
Thanks to Victor Hugo Borja, we got Buildr running on JRuby 1.1RC. All tests are green. Along the way we found three incompatibilities with MRI, all noted, recorded and monkey patched around. At least until 1.1 final comes out.
Beside the fact that it actually works, 1.1 feels way faster and much more polished. Way to go.
Accessible charts. Chris Heilmann describes an interesting technique for creating accessible charts using Google Charts. It’s a simple matter of using tables for the data, so screen readers can take advantage of it, and converting the tables to graphs for the visually enhanced user agents. Brilliant. (Via Ajaxian)
The easy FUD. Ryan Tomayko on the easy-fabreezy-web-services FUD:
I’ve never heard anyone from the REST camp claim that building distributed systems was “easy”. Ever. It’s exactly what has separated the two camps, in my opinion. There’s a clear distinction in overarching goals. The WS-* folks have historically been obsessed with making things easy, usually for an imaginary business analyst who is nowhere near as technically adept as they. The REST folks, on the other hand, seem much more interested in keeping the entire stack simple, and for everyone involved.
In my personal experience, WS-* has always been easy, for some value of “services”, but stretch it a bit and the beast turns unmanageable. REST doesn’t start easy, but keeps thing simpler for much longer. And in the end, simpler servers better.
30,000 and counting. It’s not too late to save XP. InfoWorld is running an online petition to keep the better Windows around for longer.
Now, I want an iPhone. New Gmail for iPhone.
Posted by Assaf
Filed in general
-
January 15th, 2008
There goes Apple ruining my streak of short-of-amazing Vaios ownership, with they’re slimmer, lighter and longer lasting creation. Only thing missing is a PCI Express and a decent operating system, but those too can be overcome.
Posted by Assaf
Filed in general
-
January 14th, 2008
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
PROCEDURE DIVISION.
MAIN.
DISPLAY 'Hello, world.'.
STOP RUN.
Yeah, I’m trolling Wikipedia for quotes. Sometimes I spend an hour or two browsing from one article to another with no particular goal in mind, just learning new things I didn’t know before. And occcasionally, I will end up reading articles about computing history, some of which feel relevant even today:
Critics have argued that COBOL’s syntax serves mainly to increase the size of programs, at the expense of developing the thinking process needed for software development. In his letter to an editor in 1975 titled “How do we tell truths that might hurt?”, computer scientist and Turing Award recipient Edsger Dijkstra remarked that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense”
I think it might be due to the fact that:
Older versions of COBOL lack local variables and so cannot truly support structured programming.
But then again, not everyone was happy with the continuing attempt to extend the language:
Others criticize the ad hoc incorporation of features on a language that was meant to be a short term solution to interoperability in 1959. Coupled with the perceived archaic syntax, they argue that it tries to fill a niche for which better tools have already been designed and developed.
But then again, perhaps it’s not a good idea to argue with success:
In 1997, the Gartner Group reported that 80% of the world’s business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually.
Posted by Assaf
Filed in general
-
January 13th, 2008
Reverse eval. ruby2ruby does have some interesting uses, like this one from Techno Weenie.
Apropos testing, Matthew Bass gives us a simple plugin for visualizing responses when running functional tests in Rails. It can print the response, and also display it in the browser.
So now you know the responses are correct, but do they take forever to complete? Derek Haynes on using Scout to get notified of slow responses.
And last, something I’m looking forward to use, Benjamin Francisoud’s NaturalSort.
jQuery for prez. I’ve heard a lot of good things about jQuery, but never found it compelling enough to jump the prototype.js ship. Well, damn you Chris, the jSkinny on jQuery has me changing my political affiliation.
Money quote. Mitch Kapor, on stepping away from Chandler:
That’s the job of the blogosphere, to be outrageously outspoken about everything. Bloggers are sometimes mistaken, but never in doubt.
I guess that makes me a blogospher :-)
Not yet determined. According to Accenture, users are calling the shots, and Accenture is calling this new phenomenon user-determined computing:
Today, home technology has outpaced enterprise technology, leaving employees frustrated by the inadequacy of the technology they use at work. As a result, employees are demanding more because of their ever-increasing familiarity and comfort level with technology. It’s an emerging phenomenon Accenture has called “user-determined computing.”
I haven’t determined if Accenture is responding to the reality in the field, and we should all brace ourselves for the First Annual UDC Conference, or just invented a new term to drive sales for its Web 2.0 product line. Source: Jeremy Wagstaff.
Public Service Announcement. The only thing more annoying than you blogging about Twitter, is you calling to tell me about SMS.
Above, Microsoft’s stay-at-home server is witty. Read the entire book here. (Via Laughing Squid)
Posted by Assaf
Filed in general
-
January 7th, 2008
The Mythical Bridge Engineer. Myth: All Engineers only ever work on bridges, and are selected from a small group of people inberd to have high ethics and no capacity for corner cutting. If only software developer could be like that.
Reality: Bridges are not immune to economic, political and eye-candy pressures. Selected quotes discussing just the east span of the Bay Bridge:
As with many expensive-to-solve potential problems, there was no political will to act.
This posed a serious conflict of interest, as members of the Engineering and Design Advisory Panel (EDAP) who were selecting the bridge design reviewed proposals by their own firm and rejected all proposals that did not have a representative on the EDAP.
Another qualified potential bidder did not bid due to a number of construction uncertainties owing to the innovative design … now expected to cost $6.2 billion (as of July 2005), up from a 1997 estimate of $1.1 billion (for a simple viaduct) and a March 2003 estimate of $2.6 billion that included a tower span.
While a number of proposals were submitted for a “signature” bridge, and the design chosen is considered by most critics to be acceptable from an aesthetic viewpoint, many questions have been raised by engineering experts as to its survivability under various scenarios - both natural and otherwise.
So yes to applying ethics to your job, but let’s not put bridge engineering on a pedestal. They’re not without their faults.
Apply in reverse. How to ruin a Rails project.
Better get working. Open-source project philosophy. Hopefully nothing you’re not already doing, but a good reminder nonetheless.
Valet service. As Nathan notes, the biggest problem with Scala seems to be the prominent lack of a valet service and books that read themselves. The original post concludes “I’m not at all convinced that the average software developer is able to grasp Scala.” That’s why we need to keep The Better COBOL around. Let’s not disrupt the natural order of the universe. People who know how to park their own cars already have several better languages to choose from.
Ruby 1.9. Faster than 1.8 on most things I tested against, but not without a catch: it’s not backwards compatible. On Buildr, a third of the Gems we depend on refuse to install out right and one caused havoc on Ruby Gems itself. And given that most that do install don’t even work, I can’t even run the test cases to figure out how long it will take to bring Buildr up to spec.
I’m in no particular rush, but it will be cool if we can get 1.9 usable by mid 2008. Meanwhile, James Edward Gray II has some good tips for upgrading from 1.8 to 1.9.
Picture of a Threadless T-shirt design (via ffffound!)
Posted by Assaf
Filed in general
-
January 4th, 2008
Less is better. I agree with every single point. Chasing C# and Ruby with rushed out features that don’t fit the essence of Java the language is not doing us any favors. Developers who need better languages are already one-foot out the door, towards languages that are better designed for their needs. Java just needs to focus on doing what Java does best …
C2EE. Rudolf Olah: “I didn’t realize it was a joke till the end. The EJB and off-shoring were the tip-offs.
Raganwald: “It’s a joke. Right?”
Sort of. It’s tongue-in-cheek criticism on the people who think Java is the one true programming language, that it doesn’t get any better than this, and of course, The Cult of the JVM.
But there’s truth behind it. Java is the better COBOL, that is its competitive advantage, and the sooner Java comes to embrace its role in the world, the better it will serve us all. It’s not glamorous, but like the electricity grid and water supply, it serves a purpose.
Unfortunately Java is Sun — or Sun is Java, either way, there’s a strong ego play that doesn’t believe languages have a purpose, and will rather let it die the death of a million features. COBOL has some big shoes to fit, and I’d rather see Java go there than cede to C#.
It cuts both ways. Nathan Weizenbaum, What I Learned From Java That Makes Me a Better Programmer When I Use Ruby.
DIS. Adding to my wishlist for 2008:
#3 Distributed issue tracking. Maintains all the issues in the source code repository, so you can review issues for a particular version/tag/branch, work on issues in separate branches, and edit issues locally, synchronizing them as part of a changeset.
Coupled with distributed version and documentation generated from source, it’s a killer development workflow.
WICD/CDF. Also on the wishlist:
#4 HTML documents. If HTML can do it, there’s no need for binary proprietary formats like ODF and OpenXML. Except it can’t, not without a lot of other supporting documents (images, styling, etc), so a compound document format is necessary. And while we’re at it, fixing print media in the browser means high quality printouts straight from the Web.
PDF is good, but less of PDF is even better.
Above, another find image from Scary Ideas (via ffffound!)
Posted by Assaf
Filed in general
« Older posts
|
|
Subscribe
