Eitan Suez's Home: Category Programming

"On the advent of new technologies"..or perhaps.."Breaking new ground"

Eitan — Wed, 19 Aug 2009 14:05:00 -0500

I remember around 2001 I was working on the user interface for a project (which I later open-sourced) for browsing javadocs that had been stuffed into a relational database. The UI was very advanced for its time, employing css, javascript and "dhtml" (as it was called in those days). I was quite satisfied with the end result, with one exception. The ui looked great. Most pages (for example a page presenting information about a class) were laid out as a tabbed pane. Most of the tabs were prepopulated with information from a single http query. But the last tab actually required a trip back to the server. It's a problem that bothered me, but that I didn't pursue a solution for. Had I done precisely that, I would have come to the conclusion that I needed an AJAX call, and would have likely started using and exploiting AJAX in user interfaces perhaps as early as 2001-2002. Instead, I just watched the phenomenon happen a few years later.

Separately, I recall when speaking on the NFJS conference circuit, developing a talk on CSS. At the time the state of things was not so rosy. This was before the days of the javascript frameworks. As I developed my materials, I'd created a site that I called the "CSS repertoire," (see http://u2d.com/css/ ) that exposed my thoughts and various UI design patterns that I'd collected. Most of those lessons I'd learned as early as 2001. In some of the essays on that site, I complained that the power of CSS selectors should be accessible from javascript, and should not be strictly the domain of styling; that it had broader applicability, and that it was a focal issue that needed to be addressed. I had little hope that the standards makers and browser makers would react to this need in a timely fashion (they have yet to do so), and believed that this gap should be filled by them. Again, rather than tackle the problem, I sat back and watched how others addressed this problem directly in javascript frameworks such as jquery, which today fill that gap.

What's the moral of the story, perhaps besides the fact that I'm a lazy bastard? Well, I think I can draw a number of related points here:

innovation comes out of tackling the problems one confronts when one comes up against an obstacle, something that the current technology does not address; these may be "last-mile" problems, not essential to the success of the project at hand;
one must be involved actively in projects and building the systems of today. it is out of this work that today's problems are identified, and present a path for building the technologies of tomorrow;
don't leave well-enough alone: one must have that sort of mind that's obsessed with perfection: "Yes, the system works well enough, but observe this flaw here. Why is this solution not satisfactory? What's the root problem? Why don't we have a solution for it? What's the required solution?" and finally.."Let's go for it!"

As a related example, I recall watching the now famous google wave video that came out of the google i/o conference 2009. This innovation precisely came out of this tenet of "don't leave well-enough alone." GMail is great. But they realized that it could be done better. They identified aspects of GMail such as modeling discussion threads, and asked themselves some very important questions, but mainly: "Can it be done better? Is there a simpler or more elegant solution?" etc.. And what they came up with and presented at google i/o did not disappoint.

I believe that there still remain many stones that have not been "turned over," so to speak; many opportunities for improving the state of the art in business applications development. What will I or you do differently this time to not become just a witness to the phenomenon, but to play an active role in making it happen?

MVC without leaks implies generic VC

Eitan — Mon, 01 May 2006 13:44:00 -0500

How many times have we heard or preached (or both) the important lesson of not having our business logic "leak" into the client tier. Each time we hear it, we nod our heads and say "how true," and get serious for a moment.

The idea of logic leaks applies to other aspects of development, not just the client tier. For example, the Hibernate project is very concerned about not leaking persistence issues to other application tiers.

As I was thinking about this notion of business logic leakage, a very interesting thought came to me. Say for example that we define a business object, maybe a Customer. Furthermore, let's say we define a number of fields on this object: name, date of birth, etc.. The minute we put down in our text editor the lines:

<caption>Name:</caption>
<input type="text" name="name" />

..is the minute we've crossed the line; we have violated the DRY principle. We have just leaked business logic into our view. From now on, if we rename the field, we must do it in two places: in the model and in the view.

Now, imagine being in the process of developing an application consisting of a dozen business objects, each with a half dozen fields. Model changes are going to occur. They're going to imply making changes in more than one place.

Given this, it's no wonder that resistance to change grows as a project gets larger. Yet business change is inevitable. People talk about the high cost of building software. It's no wonder the cost is high if we have to manually make each change twice. Not only is it more work but also error-prone. The essence of DRY is eliminating that duplication.

So, having provided a context, I can finally describe this small epiphany I have had in a short sentence:

*If we're going to have a model-view-controller system without business logic leaking into the view, then we must construct generic views and controllers.*

What does that mean? Take for example, the CRUD scaffold generators in Rails. The code duplication is still there but at least the duplication is automated. Admittedly not bad for a first pass.

The other interesting tidbit that sort of "falls out" of this small thought exercise is:

GUI is plumbing

I've been saying this for a couple of years now but it is still my hope that some day everyone will have good GUI plumbing for their software applications.

Stoked: Not Just for Surfers Anymore

Eitan — Mon, 01 May 2006 13:14:00 -0500

I sometimes enjoy describing feelings a software developer might experience, at certain moments during development. For example, a while back I blogged about "Grazie Signore" moments.

This past weekend I attended the Northern Virginia Software Symposium and was fortunate to have a little time to spend with my NFJS comrades. A most vivid comment that Justin Gehtland made during one discussion was how stoked he was about this software we were discussing.

It occurred to me on the plane ride back to Austin that the term "stoked" is normally used to describe the feeling one gets when surfing. Perhaps it's also applied in the context of extreme-sports related activity.

To my wonder, the term could be applied, and very aptly so, to moments that we, geek software developers, have in our work. That feeling arises when we do something that we think is extremely cool, that perhaps hasn't really been done in that particular way. For example, I sensed that feeling when reading a weblog I came across on java.net a while back, having to do with a very cool idea that occurred to one of the Wicket Framework developers. See Wicket + Swing == hmmm...interesting....

I believe that this feeling is the driving force behind the hordes of us out there, of any age, who spend their spare time coding, pursuing the creation of something that, to them, is so incredibly cool. So, just like surfers can't stop surfing and continually strive to be in that most special state of being stoked, so do software developers.

Always the web..

Eitan — Tue, 07 Mar 2006 20:27:00 -0600

I'm not sure where to begin on this one as too many thoughts are flooding me at the same time.

I recall doing web intensely in the mid 90's and being way ahead of the curve with things such as javascript. In the last couple of years, I have essentially dropped out of working the web, so to speak, focusing instead on the world of Java Swing.

Does anyone remember Netscape's effort to create the perfect platform for developing web applications? It was based on client-side javascript + server-side javascript. Of course, it went nowhere and I doubt many will remember this technology. Marketing-wise, everything they did was called live-something-or-other, as in livescript, liveconnect, and what not.

In hindsight, they were sooo close! Today javascript on the client side is more popular than mickey mouse. And on the server side, we're seeing ruby fulfill what netscape was trying to do with server-side javascript. In fact, when I think of it, that would have been even sweeter: a single language for doing both client and server side stuff. That would have made things a little less confusing.

Who would have thought it would take ten years?

Another 'who would have thought' moment: consider how slowly standards development efforts in the area of css has been. Over a year ago I was asking for the abilitiy to utilize css selectors in code, like we do in stylesheets. We were asking for missing features such as getElementsByClassName. Today, ajax and prototype.js give us all of that stuff, totally short-circuiting standards; a testament to the fact that with highly dynamic languages, you don't have to wait on the language makers any longer.

Focus pays off. I have always been too curious for my own good. Had I only stuck to the stupid javascript coding I was doing ten years ago, I could have been defining this ajax wave, instead of watching it go by. There you have it, a public confession.

QtRuby

Eitan — Wed, 15 Feb 2006 09:57:00 -0600

I just read the Pragmatic Friday on QtRuby: coding Qt client applications with Ruby.

On the good side:

I believe toolkits such as KDE to be much richer in terms of numbers and variety of widgets when compared to Swing. This could save a developer a terrific amount of time.

It's also terrific to see that one doesn't have to code in C++ to actually employ this library. So, a real Kudos for QtRuby.

Two observations:

the signal/slot mechanism really does not utilize the strengths of the ruby language.

in rails, you can say:
```
before_filter :method_name
```
and in ruby in general, one can do all kinds of neat things with code blocks besides.

in javascript, one connects a signal to a slot like this:
```
button.onclick = method_name
```
then why on earth should i choose to do this instead:
```
connect(button, SIGNAL("onclick()"), 
  some_other_obj_ref, SLOT("method_name()"))
```
???

on the other hand, i do really like the choice of metaphor used in qt: the metaphor of a signal. maybe it's because i have some kind of background in electrical engineering, but probably not. anyhow, i like it.
my initial feeling about qtruby is that the divide between the c++ world of qt and the ruby language is not transparent; one notices it. i wonder to what extent this might be an issue when developing a full-fledged system.

so what i'm trying to say is that i'm not certain if qt and ruby are exactly a *marriage made in heaven). i'm not sure what the "best" solution is.

I qualify these comments with 'initial feelings,' and what I mean to imply is that I could [very well indeed] be completely wrong about this.

full-featured, cross platform widget libraries are not exactly a dime a dozen, i understand. so yes, there's gtk and there's qt, and there's swing, and there's swt. but one can't magically say tomorrow, there'll be a ruby-native widget library. i know some swing, and now just a little tiny bit of qt. i don't know swt or gtk/glade at the moment.

so far, my scale gives more weight to java + swing over ruby + qt, even if ruby holds a few language gems that are absent in the java language. it's also nice to see that java has been narrowing the gap with its language improvements in v5; specifically: annotations and enumerations. i still believe that java needs:
1. a stronger, richer, cleaner, simpler metamodel (reflection), and
2. facilities in its syntax for making the use of that metamodel completely transparent, like it is in smalltalk

The Java+XML Conundrum

Eitan — Tue, 31 Jan 2006 07:43:00 -0600

One must applaud Bob Lee for saying what many of us never dared to: I don't get Spring. I think many of us for a long time did not grok Spring either but were afraid to say it. Everything has a reason to exist and Spring is no exception.

I believe today I grok Spring a little better than before, but I'm not sure. Below is a snapshot of my continously morphing hypothesis, as it stands today, on January 31 2006.

Spring solves a number of issues that derive from a not-as-natively-implemented feature of the Java language: closures. In smalltalk, ruby, and JavaScript, treating a method as an object is a much more common thing. And thus using a method as an object is much more commonplace. So things such as Spring's *Template classes are altogether unnecessary unless you're working in Java.
One of the end results of applying Spring to a project is a combination of Java and XML. You inevitably end up with two languages instead of one. Interestingly, this aspect of Spring is directly related to a blog I wrote recently (two weeks ago, to be exact): Skip the Compile.

There are concerns in Java that don't exist in other languages. One of them is the compile step. Removing that issue leads to Internal Domain Specific Languages, the very solution to the Java+XML conundrum.

So by attempting to grok Spring, I am coming to the conclusion that Spring is an artifact that attempts to make some of the pain of working with Java go away. It does a pretty good job in some respects (I consider the fact that we still have a bunch of XML a down-side). But when we look at other languages, specifically at Smalltalk, we see a much more elegant solution: these problems simply don't exist. Everything is written in-band. I advocate that it should be.

I like IntelliJ IDEA

eitan — Fri, 20 Jan 2006 17:05:26 -0600

As I was coding today, I started thinking to myself "I like IntelliJ IDEA."

I've been using this IDE for almost a year now. I recall what forced me to finally seriously use IDEA: I had been using Eclipse on MacOSX (don't!) when it finally died after Apple introduced Tiger. Man that feels like a long time ago. I am sooo at home on Ubuntu these days it's not even funny. Anyhow, Eclipse really rocks on Ubuntu. Netbeans does too. Still, IDEA is my preferred tool. I'm still not using it to the max but I really like the performance of IDEA on Java 5 on Ubuntu on my Medion laptop (Pentium M 730 I believe), the feel of things.

Anyone know of a good way to integrate XDoclet with IDEA? The question may be premature.

I just checked out JetBrains' web site and noticed they received the "Best IDE" award from the JDJ for 2005. Congratulations guys! Keep it up.

Code Blocks

eitan — Tue, 17 Jan 2006 17:28:33 -0600

I'm about to check out TestNG for the first time. I have the documentation printed in front of me and hope to take it for a spin shortly. So I read the TestNG web site's front page. I followed the three links from the front page to three blog entries by Cedric Beust that essentially describe issues he has with JUnit. Cedric's arguments are not convincing.

Here's is my understanding, let me know if I'm wrong:

One of the principal ideas in JUnit is to use the Method as as an analog to a generic block of code: in this case, a test. A method is a test. Don't think of a method as a method. Think of it as a test. Cedric is confused, and rightly so: JUnit test classes are not really classes in the way they were meant to be used by the language designers. He is confused that the class constructor is invoked once for every test that is run. That is, once per method. This is contrary to everything we've ever been taught about OO. Why is this so? Well, it's very simple. Imagine having to write a new class for every single test we wanted to run. It's tedious. It's overkill. The 1-1 mapping of method to test is much nicer. Furthermore, related tests can easily be grouped together in a class. JUnit does its magic behind the scenes, it uses reflection to introspect matching test methods and, in a sense, instruments them for testing. It invokes each in a specific context that ensures isolation from other tests, etc..

What I'm interested in though is in a generalization of JUnit. Grasping the essence of the pattern that JUnit employs is most important. The idea that one could, in general write a class with a bunch of methods and, separately, write a harness that does something else with each method, in a similar way, but where one can customize the context in which the block of code is run.

Take for example, the simple desire or need for someone to learn Hibernate. There's a lot of setup and tearndown that goes along with running all kinds of "tests" to learn the Hibernate API: obtaining a session, beginning a transaction, running the "test", commiting the transaction and "closing" the session. With a generalization of JUnit I would write tests that could be run in a slightly different context where each test method is called in a context that repeatedly does the mundane: opens the session, begins the transaction, calls the block of code, commits the transaction, closes the session, and on to the next test.

Then you can use some kind of flexible runner application to pick which tests you'd like to run. Actually, that's one of the features of IntelliJ IDEA that I really love: the ability to run a single test directly from the IDE, without having to fuss with ant or setting anything up.

What I'm wondering at the moment is whether that "Generalization of JUnit" I'm seeking (though it might be actually trivial to write) is not called "The Spring Framework." Spring employs this pattern over and over again in all kinds of circumstances. What I don't know at the moment is whether one can customize it. This pattern actually is native to smalltalk and ruby (and requires no "framework" to enable). That explains why Kent Beck used it when he wrote JUnit.

Open Sesame

eitan — Tue, 17 Jan 2006 16:38:59 -0600

One of the small little but valuable features I used to like on macosx (before switching to Ubuntu last Summer) was the command-line open command. You could just type open index.html and the file would pop up in the a web browser. I used it all the time.

I'm not "guru of the universe" and surely something like this exists for linux but for some reason thirty minutes searching the synaptic package manager did not yield anything.

So one day I finally decided to turn on my brain for a change and in five minutes hacked this:

  #!/usr/bin/ruby -w

  def suffix(file_name)
    file_name.split(".").last()
  end

  map = {
           "pdf" => "kpdf",
           "directory" => "nautilus",
           "html" => "epiphany",
           "htm" => "epiphany",
           "xls" => "gnumeric",
           "csv" => "gnumeric",
           "txt" => "kate",
           "gif" => "eog",
           "jpg" => "eog",
           "png" => "eog",
           "xml" => "gedit"
         }

  file_name = ARGV[0]
  key = (File.directory?(file_name)) ? "directory" : suffix(file_name)
  app_name = map[key]

  fork do
    puts "invoking #{app_name}..\n"
    exec "#{app_name} #{file_name}"
  end

I've been using it daily for a while now and I like it. Over time I've built myself a few other little utilities. A recent one is merge for merging data with an erb template. I use 'show' a lot. It breaks down a path-like structure into multiple line entries so one can actually read the foresaken string. I use it like this:

  eitan@ubuntu:~/bin$ show path
  PATH:
  /usr/local/bin
  /usr/local/sbin
  /sbin
  /usr/sbin
  /bin
  /usr/bin
  ...

.. or show classpath etc..

Another one that is a real time saver when the time comes to import a new project into subversion is svnize which will automatically restructure your project in the trunk/tags/branches hierarchy suitable for doing the import.

Smalltalk

eitan — Thu, 22 Dec 2005 09:11:58 -0600

What I love about smalltalk is that nothing is out of band. The number of concepts is so brilliantly minimal. By simply treating a block of code as an object, you can implement control structures and exception handling in the language. Code such as:

[#(1 2 4) at: 5] ifError: [:msg :obj | nil].

..is pure beauty (taken from pg 202, Squeak, A Quick Trip to ObjectLand).

It also makes me wonder why ruby is getting so much attention when in fact the things that make ruby great are essentially borrowed smalltalk features.