Labnotes

Remembrance of Things Past. Hal Fulton remembers why Rails was such a success:

I maintain there is much to learn from the Rails phenomenon. Don’t repeat yourself; don’t put a burden on users; don’t design by committee (but do open-source when you release). Be passionate in your work and creative in your marketing. If you apply these principles to your projects, they will at least go more smoothly.

The interesting thing about this quote is not what it says, but where it shows up. A 4-page (16 ad units) article on CIO magazine. And this time it’s not the hypothetical “magazine for people who PowerPoint” that I use rhetorically, but the real free subscription one.

I buy therefore I am. From a presentation by Bret Sutter (via Ed Gibbs)

“We just bought a registry, we spent a lot of money.” I said, “Great how many services are you gonna put in that registry?” “Well we have three or four. And my point with those folks is, “You could keep up with that in an email or a wiki page. Why do you need a registry for three or four services.”

I think we should be seeing other people. I said it before, and I’ll say it again. Most of the complexity that is Java 2 Enterprisy Edition is fear of commitment exuberated by the shallow vendor dating pool. Cote over at RedMonk has the details:

Ultimately, Java is a culture that emphasizes knowing less rather than more. Anything you know and act on in your application is a dependency that can cost you time and money in the future. Better, the thinking goes, to deliver less and be able to sustain it over the long-haul than to deliver more and run out of code energy in long run.

Going green. Things I love about XML: a) that which it does very well, b) that which it did well before we knew any better, c) lessons learned from pushing the envelope. Now it’s time to start thinking green, save some trees and cut down on pollution.

IT Conservative on 10 years of global warming:

People talk about global warming and energy waste. They should calculate how much of that can be blamed on XML. I think people would be surprised. Hundreds of thousands of servers are at this very moment wasting their CPU cycles and bandwidth, and with that their energy, on parsing and generating XML documents. Haven’t we ruined enough with this already. Isn’t it time to come up with more efficient data representation format?

Injectionless. Big thanks to Jamis Buck for taking the time to rewrite Net::SSH/SFTP and get rid of the complexity injection:

I cringe whenever I remember those days, three years ago, when I was in the middle of a big Java project at BYU and was learning the ins-and-outs of dependency injection. For Java (and similarly constrained languages), DI is a technique that allows you to write modular code without tightly coupling the components. It seemed like a neat idea. So why do I cringe now?

Because I tried to bring that idea to Ruby, in the form of (first) Copland, and (later) Needle.

I have a bunch of that “looked good, back than” code lying around, so I feel the shame. Hopefully I would also get the time to sweep it under the 2.0 rug.

Pagerization — The most useful Greasemonkey script in my arsenal, Pagerization moves to the next page of search results by scrolling down. No need to hunt for the next page link. It does infinite scroll for Google searches, Blogger, YouTube and a few other sites.

Fullerscreen — Adds the full to Firefox’s full screen (F11). Great when working on a small screen — and 13″ by today’s standard is on the smaller side of small — or when you just don’t want too much information crowing your screen.

Locationbar² — Technically speaking, it tweaks the location bar URL to gray out the protocol, path separators and query parameters. Practically speaking, makes the page URL more obvious. Also allows you to Ctrl-click into a path.

Paragrasp — Highlights the paragraph you’re reading, with keyboard shortcuts to navigate forwards and backwards. Works great on dense text.

Searchbar Autosizer — The name says it all. Handy since there is no right size for the search bar.

Undo, redone. Aza Raskin reminds us to Never Use a Warning When you Mean Undo. The article got a lot of attention the past few days, which is great. It’s often a simple change that makes apps much easier to use. As a reminder, and for those who like the simplest thing that could possibly work, here’s my implementation of an Undo button for Rails.

“Industry” standard. Rob Weir teaches us how to stack a committee. Public demo courtesy of Microsoft Corp:

As you can see, at the start of the year, V1’s membership consisted of seven organizations, six of whom on Friday voted “Disapproval, with comments”, and one (Microsoft) who voted “Approval, with comments”. The membership spurt came at the very end, in the last month, when 16 new members joined V1. Of these 16 new members, 14 of them voted, “Approval, with comments” on Friday.

Me too. I realize, by the time this post hits your feed reader, you’ve seen this quote from Bill de hÓra ten times. Here’s no. 11:

The relative verbosity of programming languages isn’t the interesting thing; nor is typing doctrine. What’s interesting is the culture of frameworks and what different communities deem valuable. My sense of it is that on Java, too many web frameworks - think JSF, or Struts 1.x - consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal.

…

It’s hard to explain sometimes just how time-consuming it can be to get Web things done on some Java frameworks. This post will be a handy thing to point at next time I’m lost for words :)

The problem with baseball. Speaking of handy things to point out, Ron Jeffries‘ We Tried Baseball and It Didn’t Work is worth keeping on speedlink.

I is want.

Money quote. M Easter explains JRuby by drawing on the wisdom of the WS-* crowds:

Define JVM Tunneling to be the phenomenon where certain languages, by running on the JVM, encounter ultra-low resistance as a proposed addition to a project or organization. The most successful JVM tunnelers are languages that compile to bytecodes and whose installations require the addition of a single jar to the classpath.

Abstracted away. Apropos WS-* and friends, David Lorge Parnas on the distinction between abstractions and lies:

Dijkstra’s definition allows us to distinguish between an abstraction and a lie. When a model makes assumptions that are not true of a real object (such as infinite memory), these assumptions are often defended by saying “It is an abstraction.” Using Dijkstra’s definition, such models are not abstractions. Rather than represent several things equally well, they represent nothing at all. Because they embody unrealistic assumptions, one cannot trust the conclusions that might be drawn from them.

Money quote, the second. Dare Obasanjo on the practice behind the theory behind the abstraction we call SOAP:

It’s sad that as an industry we built a technology on an eXtensible Markup Language (XML) and our first instinct was to make it as inflexible as technology that is two decades old which was never meant to scale to a global network like the World Wide Web.

Cool by obfuscation. Supposedly NEPOMUK, some sort of semantic thingy something, will be part of KDE 4. What’s NEPOMUK, you ask?

NEPOMUK intends to realize and deploy a comprehensive solution – methods, data structures, and a set of tools – for extending the personal computer into a collaborative environment, which improves the state of art in online collaboration and personal data management and augments the intellect of people by providing and organizing information created by single or group efforts.

Exactly! Not that I know what any of this means. All these bigs words are semantically ambiguous. Which is exactly why I’m so impressed. That which I can’t understand must be the next big thing!

Not by car. Just a reminder, today is Ride to Work Day.

We has comments. Kent Newsome has some interesting thoughts in favor of comments:

Anyone who knows the first thing about blogging knows that to be successful a blog needs to create and nurture a sense of community. Comments are by far the best way to do that. … This is why even newspapers have comments.

We has also comments. As does Mathew Ingram:

The first is (obviously) that not everyone has a blog, or wants to have a blog. I have some persistent commenters whose opinions I value who don’t appear to have blogs at all — they blog by commenting. … The second problem is that not everything requires a blog post.

Here comment, tnxbye. And I agree with Reginald Braithwaite, comment on the post not all over the Web:

Those comments are on the Internet, but they aren’t on the web. The web is composed of pages with contextually relevant links between them. Social bookmarking applications subvert this basic structure. They are unravelling the web itself.

And it all starts with the writing. The 100% Easy-2-Read Standard has some good tips for keeping your blog, well … easy to read (via Engtech):

Initially it is more difficult to create a good layout with a big font size, but that difficulty will help you design a simpler clearer site. Cramming a site full of information is not difficult, making it simple and easy-to-use, is.

Similar words of wisdom from Jim Whimpey:

It’s more difficult to create good compact design than it is to create good spread out design. Ask anyone that’s had to stuff 100 products into an 8 page DL catalog.

I recommend reading both — not surprising they’re both easy to read posts — and using these ideas in your theme. There’s nothing inherently complex or CSS tricky about it. (You might notice a slight change to the Labnotes style that happened over the weekend. Now you know why)

Money quote. Andrew Wulf waiting for evolution to do away with the Dinosaurs:

Ask anyone building corporate IT applications how long everything takes, how much configuration you have to do, how difficult it is to meet constantly changing requirements. It’s like modern Java, .Net, C++ are the QWERTY keyboard; designed to slow us down so that we don’t tax the hardware.

Yesterday’s news, delivered today! An interesting analysis of cover stories from Business Weak, Fortune and Forbes. Not surprising, by the time editorial considers it newsworthy enough to make the cover, it’s no longer news. Caveat Lector.Sadly the article falls short of a full on analysis. So let me just draw some conclusions from my entirely non-scientific small-sample research: cover stories, negative and positive, are highly correlated to good looking glossy pictures.

Life, freedom and the pursuit of AdSense. From Kent Newsome’s must-read Declaration of Blogging Independence:

We hold these truths to be self-evidently pie in the sky, that all bloggers are created equal, that they are endowed by their Computers and iPhones with certain unalienable Rights, that among these are lots and lots of Links, Thoughtful Comments and the pursuit of AdSense Dollars.

I see CAPTCHA in your future. (Works better with eerie sountrack, so just imagine) Sterling Camden has an interesting take on what the Web would look like in a few years.

Leap frogging. The upcoming Compiz Fusion. It will be interesting to see Apple and that other big company from the north play catchup to Linux.

Web Crash 2007. (Via Coderspiel)

Nick Sieger, on testing your Rakefiles:

Perhaps someone out there will run with this idea and take up the challenge and write a Rakefile completely in a test-driven or behaviour-driven style. It’s always been a sore point for me with Make, Ant, Maven, and virtually every other build tool in existence that you have no other way of automatically verifying your build script is doing what you intended without manually running it and inspecting its output – it just feels so dirty!

I don’t know of many people who actually test their builds and automated tasks. But I do know someone who manages to break the builds every so often. Like that time I experimented and accidentally erases the LICENSE file, and then made a release with an empty license. Oops. Or that time I moved stuff around and ended releasing a WAR that passed the integration tests, but still missed some critical files. Or that time the other day … well, you get the point.

So I started thinking, what would it look like if I tested the build file. And I started with the simplest thing that could possibly work:

check do
  Zip::ZipFile.open(package(:jar)) do |jar|
    fail "No MANIFEST.MF" unless jar.entries.include?("META-INF/MANIFEST.MF")
    license = jar.read("META-INF/LICENSE")
    fail "Empty license" unless license =~ /Apache License/
    classes = jar.entries.select { |entry| entry.to_s =~ /org/apache/ode/utils/.*class/ }
    fail "No classes" if classes.empty?
  end
end

That one is more defensive than foresight, it checks for problems I ran into self inflicted before, to make sure they won’t happen again. But it’s a good start.

If you used Ruby for any length of time you’ll immediately recognize two key characteristics of this code. It tests stuff. And it’s crap. A month from now I’ll want to add something else and look at the code and wonder what the hell it does. It’s write only. And that’s not good enough for Ruby.

I’m a big fan of RSpec, so I decided to write the same thing using RSpec and see what it would look like:

check do
   describe package(:jar) do
    it "should contain MANIFEST.MF" do
      package(:jar).should contain("META-INF/MANIFEST.MF")
    end
    if "should contain an Apache license file" do
      package(:jar).file("META-INF/LICENSE").should contain(/Apache License/)
    end
    it "should contain classes" do
      package(:jar).should contain("org/apache/ode/utils/*.class")
    end
  end
end

Much. Better. Now at least I know what I’m testing. Because, hate it as we may, tests must be maintained.

But it’s longer, and a few tests like this will quickly turn any build file into a haystack. There’s some redundancy. When you work with RSpec you’re writing test cases outside the code, so you need to organize them into logical units: contexts. We don’t need that here. We already have a context that happens when we build something. We don’t need to isolate it, set it up, or tear it down. So let’s get rid of unnecessary describe:

check do
  it "should contain MANIFEST.MF" do
    package(:jar).should contain("META-INF/MANIFEST.MF")
  end
  if "should contain an Apache license file" do
    package(:jar).file("META-INF/LICENSE").should contain(/Apache License/)
  end
  it "should contain classes" do
    package(:jar).should contain("org/apache/ode/utils/*.class")
  end
end

So we got rid of the contexts but not entirely, we still have something like that, only it happens to be the object we’re testing. I call them subjects. And we write expectations against the subject. So let’s separate the descriptive part, where we decide on the subject and say what it should, and the code that complains if it doesn’t:

check package(:jar), "should contain MANIFEST.MF" do
  it.should contain("META-INF/MANIFEST.MF")
end
check package(:jar).file("META-INF/LICENSE"), "should contain an Apache license file" do
  it.should contain(/Apache License/)
end
check package(:jar), "should contain classes" do
  it.should contain("org/apache/ode/utils/*.class")
end

You might recognize that we moved away from RSpec, which is perfectly fine, we’re testing the build not running unit tests in isolation from the code. But we are using the ever so sleek should and should_not, and the niceness of expectations and custom matchers.

What about turning the entire build file upside down and make it behavior-driven? I think that would work. But the key to testing is saying the same thing twice, once to make it happen and once to prove that it works. Flipping it around would change the syntax but prove nothing. So we do want the duplicity of code that builds and expectations that match.

If you’re using Buildr 1.2, you just got this cool feature (documented here). If you’re using Rake, I can’t imagine it would be too hard to rip the code and use it elsewhere. And if anyone is interested in getting this into the next Rake release, please do!

Mandatory REST commentary. Bill de hÓra comments on REST and Web services in WSDL 2.0:

“REST mostly uses HTTP as the transport,” - I stopped reading right there

Well, I took a deep breath and skimmed it all the way to the end. And on a positive note, the rethorics are toned down. Turns one, you can no longer just flip a switch and get SOAP to become REST:

At the same time, you need to understand that HTTP binding doesn’t enable you to implement a full REST style system. This is often debated by a lot of people, and it all depends on how much you believe in what REST can deliver.

Progress. One IBM DeveloperWorks article at a time.

I understand the mechanics, but the concept … Forget what I just said. Check out this little gem from DeveloperWorks.

Wondering what all the cools kids are doing? (hint: it goes by the street name “JSON”) Feeling left out? Hanging on to your XML mixed content? Can’t let go of attributes? Well, behold the wonder! The 21st Century Amazing Invention the will rock your world! The Square Bracket!

Scroll down to listing 10 for a simple, elegant XHTML table done right. Now tell me you would prefer the square bracketed version from listing 11. If you’re feeling extra brave today, check out listing 17. Left me speechless.

There’s a real world out there. While we’re debating the relative merits of URI vs WS-EndpointReference and whether brackets should be angular or square, keep in mind. The real world is a scary place. From a public mailing list I will not mention:

is it possible to deploy webservice on WEBSERVER rather than application
server?? or is it possible to deploy webservices on http web server… ???

But it is changing. At least according to InfoWorld, reciting a recent Evans Data report:

A survey this spring of more than 400 developers and IT managers in North America found that the number of developers targeting Windows for their applications declined 12 percent from a year ago.

The targeting of Linux by developers increased by 34 percent to 11.8 percent. It had been 8.8 a year ago, according to the survey. Linux targeting is expected to reach 16 percent over the next year.

Courtesy note. I asked so you don’t have to. The outside tables are for patrons, so yes, you can sit there. Your latte will keep warm for five minutes. But I do recommend a lid. Your friend can sit with you. We don’t care if you talk loudly. But really, you don’t need to wave that iPhone in the air the entire conversation.

My reality is more distorted than yours. Did the FSF just accuse Apple of violating a non-existent license by shipping non-existent software:

The iPhone is leaving people questioning: Does it contain GPLed software? What impact will the GPLv3 have on the long-term prospects for devices like the iPhone that are built to keep their owners frustrated?

In theory, there is no difference … Raganwald’s latest take on software project management is another valuable read. It’s too good to pick a single quote, so I’ll just say this. While one of the theories looks closer to reality and a better chance of success, it all boils down to:

___ is reality, and you ignore it at your peril.

I plead ignorance. I never quite thought about it that way. But it is true. And sad. How we learn to ignore science:

They were, the implication went, ready to put away childish things, ready to go to the theatre and the art gallery, places where there was none of this ‘mad pinball pinging from one hands-on science exhibit to the next, pounding on knobs to make artificial earthquakes’. They had grown out of science.

Good vs Evil. It might very well be that:

• Many programmers have used very poor statically typed languages.
• Many programmers have used dynamically typed languages very poorly.

A comprehensive look at static and dynamic, at least compared to the flurry of Java-meets-Ruby posts crowding my feed reader. (Via Talk Like a Duck)

¿ʇı̣ əsnqɐ ʇ,uɐɔ noʎ ɟı̣ əpoɔı̣un sı̣ pooɓ ʇɐɥʍ