Dave Ford's Programming Blog

GWT 2.1: data-binding and client-side JPA

2010-11-10T12:51:00.000-08:00

GWT 2.1 was finally released. And as usual, it's brilliant. I am generally annoyed by technology fan-boys, but each time they do a release i am amazed by how smart these guys are. There is an amazing amount of new and useful stuff.

One of things i particularly admire is that they tend to focus on the GWT core, that is, the kind of things that would be difficult for 3rd parties or developers to do themselves. Everything that is added to GWT is extremely well thought out.

There are two productivity enhancements that I miss from the days of server-side MVC (i.e. Struts, Grails, JSF, Wicket, etc.) are:

Data binding (i.e. bound controls)
JPA's EntityManager. A client-side entity manager would really be useful. Much of Hibernates beauty (like lazy loading) is lost in client-heavy GWT apps. You sometime end up having a PersonEntity (for JPA) and a PersonDto (for sending to GWT client) - yuck!

GWT 2.1 addresses both of these. Data Binding is addressed with the new Editor Framework. And the client-side JPA-like thing is addressed with their new Request Factory.

Google Wave is written in GWT

2009-06-11T16:36:00.000-07:00

In case you haven't checked out Google Wave yet, it's a cool communications application that demonstrates what is possible in browser based applications. It's by the same guys who wrote Google Maps. And it's written in GWT.

Here is a link to Google Wave:

http://wave.google.com/

SBT: Simple Build Tool

2009-05-25T08:51:00.000-07:00

I have been complaining about Ant and Maven for years. I don't use these tools because I like them. I use them because there haven't been many alternatives. But that is changing with a new tool called Simple Build Tool: SBT.

SBT is written in Scala (my favorite language of the week). But it can build Scala apps or Java apps. I don't have time to go into all that I like about it. But here are a few highlights:

The language used for build scripts is the same as the language being built: Scala
It is completely and easily extensible - using Scala. The key here is the easy part.
Great docs! The project is fairly new, but already the documentation is better than that from Ant or Maven
It is compatible with Maven repositories and POM files
It is compatible with Ivy
SBT eliminates most of the unnecessary boilerplate and noise code required with Ant and Maven
The project owner, Mark Harrah, is very talented and committed to this project
Support is excellent. Mark personally replies to all messages on Google Groups
Bugs and feature requests are addressed quickly
It's fast. Building my project in SBT is much faster then Maven - I'm not sure why, but it is.

For more info:

Project Home: http://code.google.com/p/simple-build-tool/
Google Groups: http://groups.google.com/group/simple-build-tool

Leaky Web Abstractions

2009-04-30T11:33:00.000-07:00

As a consultant and trainer, I have worked with web developers of every variety. Two things that I observe over and over again are:

1. Many web developers are so entrenched in the stacks upon stacks of frameworks needed (or not needed) to build web apps that (to their detriment) they loose track of the fundamental concepts that underlie all web apps.

2. The frameworks we use to build web apps are not good enough to allow us to learn only the abstractions provided by the framework while remaining blissfully ignorant of the web underpinnings. I believe this is called a leaky abstraction. This is not the case in more mature technologies. For example, I have been coding in Java for 10 years and not once have I needed to drop down to the byte-code level to solve a problem. I have been using Oracle for years and not once have I needed to know what goes on inside of Oracle once it receives my SQL. Nor have I ever needed to know the file format that Oracle uses behind the scenes.

But the abstractions we use to build web apps are much more leaky than Java and SQL. It's a very small set of problems that can be solved without understanding the web. True, I have seen successful apps created using slick .NET tools by people who know nothing about HTTP or client/server architecture. But just as often I see million dollar disasters that could have been prevented had the architects understood the web at a more fundamental level.

Summary:

As of 2009, you still need to understand the foundational technologies (HTTP, client-server, HTML, CSS, JavaScript, etc) of the web if you want to effectively architect web applications.
Our Web frameworks must, by necessity, not obscure what is going on under the covers too greatly.
Our Web frameworks must allow us to, on occasion, drop-down to the lower levels simply and elegantly. And then go back up to the high-level abstraction without missing a beat.

An example of number #3 is GWT. In GWT you can drop (from Java) down to the underlying JavaScript using GWT's JSNI (JavaScript Native Interface) mechanism. But unlike JNI (after which JSNI was probably named), JSNI is freakishly easy. So easy, that I now effortlessly blend Java and JavaScript in a single app all the time.

As a side note, this GWT feature has altered my perspective on the whole Static versus Dynamic language debate. If GWT can do it, I am convinced that the inventor of the NBL (Next Big Language) will able to seamlessly blend static and dynamic typing in single language.

Member Literals

2009-04-15T09:07:00.000-07:00

I am aware of the pro and cons of static and dynamic languages. I lean toward static because of my error-prone typing, IntelliJ addiction, identifier indecisiveness and unit-test laziness. All things being equal, I would rather have the compiler find my errors than write more tests (which will probably have errors and then I'll need to write a test for the test).

This is why I was excited about Scala. What I was hoping for from Scala's type system:

#1. Less intrusive than Java's type system (Scala succeeds here)

#2. Find more of my errors than Java does

For #2, Scala let me down in one area that is important to me (and i think many others). Can you find the typo in the code snippet below? If you can, then you are smarter than scala.

class Person{

var firstName:String;

var lastName:String;

//etc.

}

val rs = statement.executeQuery(

"select firstName,lastName from Person")

p.firstName = rs.getString("firstName")

p.lastName = rs.getString("lastName")

p.doSomeStuff();

val e = new XmlElement()

e.addTextElement("firtName",p.firstName)

e.addTextElement("lastName",p.lastName)

p.addPropertyChangeListener("firstName"){

txtFirstName.setText(p.firstName)

}

p.addPropertyChangeListener("lastName"){

txtLastName.setText(p.lastName)

}

I probably made 7 typos, but the one i was referring to was the "firtName" typo.

Q: Have you ever been burned by this type of error?

Q: Have you ever had the feeling that the compiler should be able help?

Q: Is it *that* hard for a compiler vendor to give a "member literal" syntax? Perhaps something like this:

e.addTextElement(Person#lastName,p.lastName)

I would actually pay money for a compiler that did that.

The only reasons i can think of that this feature does not seem to exist in Java and Scala:

1. I am the only one who wants the feature

2. Compiler writers include features that are very useful for compiler writers (Scala has a parser combinator). Kind of like the waiter who sets the thermostat for him, and doesn't notice that his customers are freezing.

3. It must be really hard to implement

By the way, I am aware that Hibernate, JAXB, Rails/Grails can address some the these issues. Also, I am aware of constants (static final), but it seems a bit silly to have code like this:

class Person{

String firstName;

public static final String FIRST_NAME = "firstName";

String lastName;

public static final String LAST_NAME = "lastName";

The Right Tool for the Job at Hand

2009-04-13T14:45:00.000-07:00

There is a recurring theme that i see in forums and mailing lists. Some guy posts a message like: "what's better, Flex or AJAX?" or "What's the best tool for making a pdf: iText, Jasper or FOP?" or "What language is more productive, Groovy or Scala?". A number of people chime in with their favorites. Then some bozo chimes in: "Dude, its really a dumb question, you are comparing apples to oranges. You just need to choose the *right tool for the job* at hand."

Let me tell you why i think this is mostly crap. This "best tool for the job" logic works great for some things, like a *shovel*. I can reasonably afford a snow shovel for my driveway and a different shovel (a spade) for my yard. Shovels are cheap and the learning curve is low. But compare that with cars. I want horsepower. I want planet-friendly. I want safety. I need to tote the kids around. But I can't afford a Porshe, a Prius, a Volvo and a mini-van. I need one vehicle that (comes close) to meeting all my needs. And then i will live with the decision for the next 5 years.

I view software tools (like frameworks, IDE's or languages) more like cars. Some of these tools take years to learn. The cost of learning a new language, migrating your old code, ditching your favorite IDE, etc. can be huge.

I once knew a guy who used MS Excel as his spreadsheet, database, word processor, desktop publishing and html tool. I tried to convince him to stick with Excel for number crunching but use more specialized tools for those other functions. But he was happy with his universal tool.

I kind of feel that way with programming languages. The other night, at our Java user group meeting we were trying to "position" Groovy versus Java or Groovy versus Scala. Some suggested that Groovy was good for web/database programming. While Scala was good for systems programming. Or some said Scala was suited towards mission critical tasks, where errors are too costly. But here is why I think this is mostly horse shit: Java, Groovy and Scala are all general purpose programing languages. 90% of their target use-cases is overlap. There might be a few things one is more suited to than the other. But all are powerful, advanced, general purpose programming languages - with steep learning curves.

I don't really want to know which of these tools is right for which job. I want to know which is best for most jobs. Having a different tool for every project (or sub-project) is really not appropriate when the tool takes 5 years to learn. Here are 2 extreme examples:

1. XSLT. XSLT is a special purpose language for transforming one XML document into another, usually a raw-data xml into a presentation (i.e. HTML) xml. The problem is this. The book I learned XSLT from is 1000 pages long. XSLT is HUGE! It's an interesting and powerful language. And I learned a lot about functional programming and pattern-matching thru XSLT, so I have no regrets. But 90% of XSLT has nothing specifically to do with transforming XML. 90% of XSLT's constructs would be (and are) useful in any application, xml-transforming or not. And transforming XML is a pretty small part of what I need to do on any given day. Anything you can do with XSLT, you can do (not quite as elegantly) using a general purpose language plus a library. For most application developers who need to transform XML, I think a general purpose language plus a library is the smartest approach.

2. Another example is JavaFX. JavaFX is a really cool new language for the JVM. It is marketed as a special-purpose programming language (aka external DSL) for rich clients (anything you would have used Swing for in the past, you could now use JavaFX). But here is the rub. JavaFX is *very* feature-rich. In many ways JavaFX is a *superset* of Java. So if it takes you two years to master Java, it might take 4 years to master JavaFX. And like XSLT, 90% of the new programming constructs you will learn in JavaFX are *not specific to creating Swing apps*. Most of the cool, new features introduced in JavaFX would be useful for *any* application.

I don't think the world needs any more languages or tools with the surface area of a general purpose language but only 5% of the applicability. At least not today - with so many general purpose languages offering rich internal DSL capabilities. If you are a person who is really pigeon-holed, and all you do is xml transforms all-day-every-day and you don't already know a general purpose language like Java, then perhaps things like XSLT (or JavaFX) have a place. Or if you can somehow organize your team into super specialized niches, then maybe this will work.

But I am a general purpose programmer. I might code a mobile app one week, a Web/Database app the next week and a parser the next. JavaScript, ActionScript, Java, Ruby, Python, Groovy, Scala and C# are all *general purpose* languages. 90% of the constructs provided by these languages apply to systems programming, transforms, web apps and database apps. I have never had a client that choses a new programming language for every job. It just isn't feasible. Even Google has standardized on only 4. And I don't really care that Groovy is a few hairs better for scripting. And Scala is a few hairs better for system programming (although, if Scala was 10 times faster for system's programming I might want to know that).

I have been searching for a Java replacement (as my default, general purpose language) for some time, watching new languages like Ruby, JavaFX, Boo, C# 4, Groovy, etc. I am trying to learn which language is most productive for the 90% crap that *all* programming languages do - and doesn't screw me over completely if I need something from the other 10%.

I think with the "internal DSL" functionality of most newer general purpose languages, it is perfectly reasonable to ask the question, "which is the best general purpose programming language?".

So if I start posting questions comparing various languages or frameworks please don't respond with the "right tool for the right job" lecture.

I *do* want to know the strengths and weaknesses of the various languages and platforms. But I have no intention of using a different general purpose programming language for every project or sub project I do.

Also, please don't get offended if I ask questions that may put your favorite tool in a bad light. It is nothing personal against you. I am just trying to learn.

Side note: One huge limiting factor in all of this is runtime environment. At present, there is no powerful, general purpose language that runs on every runtime platform. In fact, I was just about to jump head first into Python, in spite of the fact that it is 90% redundant (I am guessing) with languages I already know. Why? Because it runs on the Google App Engine. Luckily I procrastinated long enough, and the Google App Engine now runs Java.

Fail Fast Fail Nice

2009-04-11T18:00:00.000-07:00

You may be familiar with the term "fail fast" as it applies to software development. It basically states that errors should be reported sooner rather than later. So, for example, suppose an error occurs on line 30 (x has a null value when it shouldn't) but the error doesn't rear its head until line 246. This kind of thing can take hours to debug. A solution would be to place an assertion on line 31 like this:

if(x == null) throw new IllegalStateException("x should not be null");

A few corollaries to the fail-fast rule might be that compile errors are preferable to runtime errors. And errors caught in unit tests are better than errors caught in customer tests.

I would like to take the fail fast principal and expand it to "fail fast, fail nice" (FFFN). By nice, I mean this: the system has to give me a nice error message with enough information to quickly pinpoint and correct the problem. To me, FFFN is important. And not just in the code we write. But in the code we *use*: languages, libraries, frameworks, compilers, runtimes, IDE's, etc.

Let me give a few examples. A year or so ago, I decided to learn JavaFX. Being new, I made lots of mistakes. Every time I screwed up, JavaFX gave me the exact line number and column number of the error. And it gave a nice message telling me what i did wrong. In other words, right out of the gate, JavaFX seemed to succeed at FFFN. It was surprising to me because at this time JavaFX was brand new, not released yet, and mostly the brainchild of a single guy named Chris.

Consider JSF as another example. I had been using and teaching JSF for 3 years. In class, a student makes a mistake on his lab exercise. His app does not work. He just gets a blank screen. No stack trace. No error message. We turn up logging to its most verbose setting. Still nothing. In other words, the JSF implementation did not give us a *bad* error message. It gave us *no* error message. No clue. This kind of thing can takes hours to fix.

An other example would be GWT. If you make a mistake, GWT almost always tells you the exact line number with a friendly description. Compare this to JavaScript programming (without GWT). You often get the wrong line number. And a completely unhelpful error message (although Firebug can help a little).

Another example is Groovy. Every 6 months or so I get excited about Groovy. The clean, elegant syntax. Less need to repeat stuff (the DRY principal), closures, etc. I love Groovy. But then I loose my enthusiasm after a few mistakes take me into java stack trace hell. As of my last go around, Groovy scores high in most areas that are important to me. But it stills scores low in FFFN.

When developing with a low-FFFN tool (like JavaScript) you must drastically decrease your mean-time-between-testing.

What are your experiences? What technologies (languages, libraries, frameworks, compilers, runtimes, IDE's, etc) have you used that are particularly high-FFFN? Which tools have you used that are particularly low-FFFN? Is FFFN an important factor for you?

Is Spring Useful?

2009-04-03T08:38:00.000-07:00

I friend recently asked my take on Spring. I thought others might benefit from my response.

> What's your take on the pros and cons of Spring?
You know me, i always seem to have non-standard opinions on things. I can't help it :) I have been using Spring and IOC for a long time. I actually wrote my own (crappy) dependency injection framework before i knew about spring. I have also used used Pico. And lately Guice.

Regarding spring, I use it a lot (it's in the classpath of most projects i do). This is because there are a number of little gems in there. The jdbc stuff, the reflection/bean-util stuff, etc. But, on the whole, i think the *core* of what Spring does is useless (for me). Here is what i have learned that led me to this conclusion:

1. I realized that the IOC pattern is a great pattern, but its a *pattern*, more than a framework. You don't need a framework to do ioc. If you really think of it, the core premise of ioc (or dependeny injection as its also called) is this: Don't lookup dependencies from some kind of global scope. Instead, pass them in as parameters. By "global scope" what i really mean is: (registry | jndi | serviceHashMap | global-variable/singleton). If you really think of it, the ioc pattern is just a re-phrasing of what we have always been taught: prefer explicit argument passing over globals.

Also, in good oo design, one should think about things like "object life cycle" and things like: some objects are *users* of a service (aka object) while other objects (or object) is in charge of *creating* the service (or object). By the way, the *creator* is also the *injector*. This stuff needs to be planned out thoughtfully as part of a good oo design.

So my point here is that 80% of the ioc value comes from the ioc *pattern* (which is really just good oo practices) and *not* the ioc framework.

2. We learned that "autowire" has issues. The one area where an ioc framework can actually clean up your code is the "autowire" feature. But, the autowire feature, as it turns out, kills the dave fail-fast/fail-nice principle. In fact, the spring docs caution against the autowire feature.

3. You already know i am against random creation of crappy, unneeded "external" DSL's (http://www.martinfowler.com/bliki/DomainSpecificLanguage.html) (i.e. spring's xml file). There are a million reasons for this. The one good thing about java (the strong type checking) you loose. They now have an equivalent "internal" DSL (java based). But still, there has to be some real benefits (not imagined benefits) before one adds a disruptive framework to their project.

I kind of view the Spring/Java combo as the absolute worst of all worlds. You *don't* get all of the great benefits of a dynamic language like Ruby. And you *don't* get the benefits of type safety.

4. For most things that people use Spring for, I can show them cleaner better ways. Things like transactions, hibernate, dev/staging/production config, swappable impls, factories, etc.

So to summarize, Spring has a place in my toolset, but these days, it is more in the role of an apache commons type of thing. The core idea of what spring is, is mostly useless to me. There are very few use-cases that (for me) warrant the use of Spring (in its central role of ioc/aop container). One use-case would be if i needed a transaction layer that worked seamlessly with JTA (i.e. 2 phase commit) and non-jta environments. But i can't imaging needing that. You either need 2-phase commit or you don't.

If I ever decide to take up ioc frameworks again, it will probably be juice.

Form over Function on the Web

2009-01-20T06:11:00.001-08:00

In a perfect world, all web sites (and web apps) would look great and be easy to use. But web developers tend to not have unlimited resources. Thus we must prioritize. If you take 3 metrics:

1. Functionality/Content: What does the site or app do (or allow the user to do)
2. Usability: how easy and intuitive is it to use (for the target audience) without reading a bunch of docs
3. Visually appealing: how good does it look

Here are my observations on this subject:

1. There are many web sites and web apps that are ugly but freakishly popular because they offer functionality or content that people really want (craigs list, e-bay). I don't know of any freakishly popular web sites where the reverse is true.

2. As a user, I have often put up with ugly, counter-intuitive web sites because I really wanted the functionality or content.

3. All three of these metrics are fairly subjective

4. Many organizations that create web sites or web apps tend to lump metric #2 and #3 together. But they are really different skills. I don't think it is a valid assumption that someone who is good at making things look pretty is also good at making an application easy to use.

5. I have seen web sites that have spent extreme and disproportionate amounts of development effort on a feature that adds no functionality or usability gain. But it looks cool. This is fine in a world with unlimited resources. But in the real world it may be less appropriate.

Thus my preference (both as a user and developer) for prioritizing these 3 metrics is:

1. Functionality/Content
2. Usability
3. Visually appealing

There are always exceptions. For example, a web site for a graphic art company or a web site trying to promote their product's image/brand may prioritize differently.

Mac Usability Overrated

2008-12-24T13:27:00.000-08:00

A few years ago, I switched back to a Mac after a 15 year hiatus. Overall, it was a positive experience. And overall, I prefer the Mac OS X Leopard to Windows XP. I have no experience with Vista, so I can't comment on that. But given my general tendency of complaining and my annoyance of religiously fervent Mac fans, I feel I should share a few things that, in my opinion, represent poor usability design in the Mac.

Now there is no way to gauge how skewed my opinions are by the fifteen years of Windows experience. Sometimes people judge something as crappy just because it is new to them. As a teacher, I see this in my students. Most people taking my class are moving from an old technology to a new technology. And many of my students complain that the "new way" of doing things sucks and that their "old way" (in Cobalt, Fortran, PowerBuilder, etc) was much better. Sometimes, they are right. But sometimes, they just haven't gotten used to the "new way". Its probably impossible to separate "poor design" from "I'm just not used to it", but none-the-less, I'll try.

#1 Context Insensitive Menus
Most Mac applications have a global menu bar. And this is how you access most of the app's functionality. What's more, the menu is anchored to the top of the screen. Not the top of the document. Not the top of the panel - the top of the computer screen. This, in my opinion, isn't just different from what I am used to. It's a poor design. It violates the UI design Principal of Context. Most user actions apply to a specific context (i.e. object): a paragraph, the selected cells, the current document, etc. This is the fundamental concept of OO (an object is really just a context). Imagine you have a dual monitor setup. You have a graphics application running on the right screen. And you want to modify a rectangle. Where do look for a list of possible actions? The rectangle? No. The document? No. You look to a menu bar at the top of your left monitor. The only argument, in favor of this design is that it saves a bit of screen real estate. And old Mac people are used to it. But, overall, in my opinion it is just poor usability design.

#2 No Maximize Button
Mac windows do not have a maximize button. They have something kind-of (but not really) comparable: the Zoom Button. It is one of the 3 tiny circle buttons in the upper left corn of every Mac window. The zoom button attempts a "size to fit". Most UI programming toolkits have a function like this built-in. In Java Swing, it's called the pack() function. Basically, the window attempts to find the optimal size (not too big, not too small) based on the window's contents. The problem with this approach is that the algorithm is wrong most of the time. And it takes control away from the user. Often, when browsing with Safari, I just want the whole screen. Obviously, it's not a deal breaker. I can just drag the window bigger if needed. It's just a pain in the butt. By the way, many (non apple) vendors simply have their zoom buttons do a maximize. But Safari, Finder and iTunes do not.

#3 The Window Buttons
Most windows on my Mac have 3 buttons in the upper left corner (one of them is the Zoom button mentioned above). These buttons are just circles. There is no indication of what they do. If you hover your mouse over the button, then an image appears. But you get no tool tip telling you (in words) what the button does. This, in my opinion, is not just different from what I am used to. It's just poor usability design. Why not just have the image visible all the time? Why not have a tool tip? Perhaps some designer thought it looked prettier this way. I don't know.

I think Apple is great at creating interfaces that look great. But as far, as usability goes, I think they are probably good. Above average. But not great. At least not based on my Mac experience.

Composite Widgets and Blur Events

2008-12-23T07:53:00.001-08:00

It is a common need in web applications to create a single logical widget (aka UI component) that internally is composed of multiple native html elements. A few examples:

A DateWidget composed of 3 html SELECT elements (month, day and year)
A custom combobox composed of a textbox, a button (placed to the right of the textbox) and a popup (or more accurately a drop-down) div that contains a pick list and appears when the button is clicked or a letter is typed.
A DatePicker (same as custom combobox mentioned above, except the drop down is a calendar instead of a pick list)

Below is a problem with this kind of widget that i have not been able to easily solve:

Problem Definition
It is often desirable to have a single blur event that applies to the composite as a whole. Using the blur event for the internal html elements may be the wrong granularity for validation or change notifications. For example, suppose that for the above mentioned combobox, we chose to use the textbox's blur event (because the combobox as a whole has no blur event) for validation. Then imagine this scenario:

The user types 1 letter into the textbox
The popup appears
User clicks on the popup - perhaps to scroll the pick list or (in the case of the DatePicker) to scroll the month
Boom! The TextBox's change and blur events fire.
Our app, in response to the blur event, attempts to validate
Our validation function reads the value in the textbox and, detecting that it is only 1 character long, displays an error message.

This is clearly not the desired behavior.

Desired Behavior

Test #1:
Does the composite widget have its own blur event as distinct from those of its child widgets? And (more to the point) is there an obvious way to add a blur listener to the composite (again, as distinct from its child elements)?

Test #2:

Assuming we passed test #1, does the composite's blur event fire in a way that is logical for the composite as a whole:

Test 2a (comboBox with down-arrow trigger button):

Click into the textbox portion of the combobox
Type a few letters
Click the down-arrow-button (to reveal the drop down list). This should not fire the composite's blur event.

Test 2b (date picker with no trigger button):

The user types 1 letter into the textbox
This causes the popup calendar to appear
The popup contains a "Scroll Next Month" button. Click on that. This should not fire the composite's blur event.

Workarounds
This isn't a deal breaker issue for most applications. We can just hold off on validation until later, when the entire form is submitted. But none-the-less, many customers prefer field-level errors to appear sooner rather than later. This is, after all, one of reasons we have blur and change events.

Other Widget Libraries
I did a quick survey of composite widgets from various web widget libraries, to see if they handled blur events as desired (see "desired behavior" above). Here is what I found:

Library	Widget	Composite blur/change events	Demo Link
DOJO	dijit.form.FilteringSelect	Yes	TODO
jQuery	ui.datepicker	No	TODO
Spry	SuggestText ??	No	TODO
GWT 1.5	SuggestBox	No	TODO
GWT 1.6	SuggestBox	Maybe	TODO
GWT Incubator	DateBox	No	TODO

Possible Solutions

Timer solutions. TODO: elaborate
Global focus tracker. TODO: elaborate
Try to figure out what DOJO did (their solution was not easy for me to follow)

Event Bubbling
Note that what we are describing here is not the same as bubbling. Event bubbling refers to the fact that if a child element does not handle an event (or more specifically cancel the event) then that event bubbles up to the parent element. But a div containing 3 select elements (as in the date selector described above) would still fire 3 change events in either case:

Case #1: three select#changeListeners
Case #2: one div#changeListener.

This is not to say, that bubbling might not be used in the solution. But bubbling, in and of itself, is not the solution.

Objective
Come up with a solution that:

Provides the desired behavior described above
Is general enough to componentize (for example, in GWT, a generic parent class called BlurableComposite). Note: GWT has a class called FocusPanel, but I can't figure what it's purpose is and if it is designed to address the problem I am describing here.
If the solution is not general enough to express as a reusable class, then a solution general enough to express in the form of a design pattern/solution
Perhaps tie in the solution with GWT's new HasValue/HasValueChangeHandler (in 1.6 trunk)

JavaScript Virtual Properties

2008-12-19T14:57:00.000-08:00

Some programming languages have a particular feature that I find very useful. This feature allows a setter method to disguise itself as a variable assignment. For example, instead of:


person1.setAge(42);

You would do this:


person.age = 42;

Under the covers, it's actually not setting a variable (as it appears) but rather it's calling a setter method.

The same language feature allows a getter method to disguise itself as a variable read. For example, instead of:


print( person1.getAge() );

You would do this:


print( person1.age );

Again, under the covers, we are actually not setting a variable (as it appears) but rather we are calling a getter method.

Virtual Properties

The above described language feature does not have an industry standard name (that I know of). The old VB used to call it "property procedure". I've heard it called "getters and setters", but that is a confusing term because languages like Java have "getters and setters" but they do NOT have the above mentioned language feature. C# calls them properties. But this is also a confusing term. JavaScript and Java both use the term property to mean something different. Also, many people use the term property interchangeably with "field" or "instance variable". Ruby uses the term "attr_accessor".

But JavaScript (as of ECMAScript 4th edition) will soon be supporting this feature. And they use the term "Virtual Property" which makes the most sense to me. So that is what I will use. To be more specific, ECMAScript 4 defines three terms:

Value Property: A value property is the new name for what used to be called "property" (without the "value" prefix). Value properties are just plain old instance variables (aka fields). The reason for the new term is to distinguish a value property from a "virtual property".

Virtual Property: A virtual property is really a getter and/or setter method that (to the caller) appears to be an instance variable.

Property: The term "property" is now inclusive of both value properties and virtual properties. Thus, clients of the object just see "properties" there is no way they can tell whether they are accessing a virtual property (i.e. calling a setter or getter method) or accessing value property (i.e. a variable). The fact that the caller is hidden from these details is really the whole point of virtual properties.

Why Use Virtual Properties

You may be asking yourself, "why would I want to use this feature?" Well let me explain by reviewing setter/getter methods in general.

Most of the time, setter methods (the old kind of setters and the new "virtual property" style setters which I will show shortly) don't do much that is interesting. They usually, just turn around and set a variable:


function setAge(newValue){
    this._age = newValue;
}

But sometimes, the setter adds a bit of value beyond merely setting an instance variable. For example, validation:


function setAge(newValue){
    if(newValue) > 150) throw new Error("Too Old");
    this._age = newValue;
}

Or perhaps the setter may trigger some other action (or side effect):


function setAge(newValue){
    this._age = newValue;
 recalculateDateOfBirth();
}

And sometimes the setter has no corresponding underlying instance variable at all. For example, storing age and dateOfBirth is redundant. So you may have:


function setAge(newValue){
    this.dateOfBirth =  computeDateOfBirthFromAge(newValue);
}

But the vast majority of the time, setters just set a variable:


function setAge(newValue){
    this._age = newValue;
}

This results in a whole ton of boiler plate code for setter methods. The same is true of getter methods, some times they do something interesting like this:


function getArea(){
 return this._length * this._width;
}

But most of time they just do the same old boring thing, return the value of a variable:


function getLength(){
 return this._length;
}

Again, this results in a ton of boring, noisy, boiler plate code. In fact, most modern IDE's have a shortcut called "generate getters and setters".

So now, with virtual properties, any time you have a setter or getter that does nothing but set or get the value of an instance variable, just get rid of it. Instead allow direct access to the instance variable.

The payoff: all those boilerplate do-nothing getters and setters just go away!

How to Create a JavaScript Virtual Property

So now in JavaScript you have two new keywords: get and set. These are placed write after the word function like this:


function get age() { 
 return this._age 
} 

function set length(newValue) { 
 if(newValue > 150) throw new Error("Too Old"); 
 this._age = newValue
}

Browser Support

As it turns out Safari, FireFox and Opera all support virtual properties. And now (from what I have read), virtual properties will be supported in IE8.

More Info

Mozilla: Defining Getters and Setters
Cedric on gettersand setters
ECMAScript 4 Look for section titled: Property States

Safari DevelopMenu

2008-12-17T16:59:00.000-08:00

Just discovered something cool in Safari. Under Safari -> Preferences -> Advanced, there is a checkbox: "Show Develop Menu in Menu Bar". This adds a new menu item called "Develop" with all sorts of web developer tools.

One Language for Client and Server

2008-12-17T11:49:00.000-08:00

Some web developers categorize themselves as a "front-end" developer or a "back-end" developer. For large teams, this specialization is a nice luxury. But more often than not (I think) most developers end up playing both roles. I'm glad that I play both roles, because often it takes an intimate understanding of both, to create the best overall architecture. Often the most important part of an architecture is deciding what should be part of the the front-end and what should be part of the back-end and the communication protocol between the two. Thus, I proudly categorize myself as an end-to-end developer (or a front-back developer?).

Side-note #1: The terms front-end and back-end is not necessarily the same thing as client-side and server-side. But for this post, this is how I am using them.

So here is the problem with being an end-to-end developer. The predominate programming languages for front-ends are JavaScript and ActionScript. The predominant language for back-ends are: Java, C#, VB.NET, PHP, Ruby and Python. This means developers must learn at least two languages to do their job (lets ignore CSS, HTML and SQL for the moment). This is good for me personally, because I enjoy learning new languages and (as luck would have it) I already know most of the server-side and client-side languages. But most of my clients (corporate IT developers) must also spend time learning their own problem domain (insurance, medical, banking, or whatever). These people are not as geeky as me and don't enjoy learning new programming languages for sport. Many come from backgrounds where they used to create entire applications using only one language like VB, PowerBuilder or Oracle Forms. Thus, I ask the question, how much more productive can we be if we can use the same language end-to-end? I personally would like this.

Side-note #2: Sometimes additional, more special-purpose languages are a good thing. There is even a acronym to represent the concept: DSL - (Domain Specific Language). Examples of DSLs include things like HTML, CSS, SQL, XSLT and regular expressions. But when I speak of a single programming language for front-end and back-end, I am talking about general purpose languages. The predominant front-end and back-end languages mentioned above are general purpose programming languages.

So, if you would like a single end-to-end language for web development. Here are your options:

Compile your favorite server-side language-to-JavaScript

Find an Application Server that supports JavaScript

Use a server-side framework that generates all the JavaScript

Below are a few examples from each of these categories.

GWT: Google Web Toolkit

GWT compiles Java into JavaScript. Thus, you can use Java for the front-end and Java for the back-end. Think of JavaScript as the new byte-code. In both cases the Java part is really an illusion; at runtime the Java is gone and all that's left is JVM byte-code (server-side) or JavaScript (client-side). But once you are coding in Java on both sides, network (i.e. AJAX) programming becomes much easier; you can now send Java objects back and forth RPC-style.

Pyjamas

Pyjamas is similar to GWT except it compiles Python to JavaScript.

Other X-to-JavaScript Compilers

Java2Script

Ruby to JavaScript

Harmony Framework - PHP to JavaScript

ASP.NET and JScript

One can create ASP.NET pages using JavaScript. Thus, in principal, one can use JavaScript for both front-end and back-end development. The only problem is that JScript is a more modern version of JavaScript (more like ActionScript 3) thus client and server languages are not technically the same.

JSF AJAX

JSF (JavaServer Faces) when coupled with an AJAX JSF tag library like ICEFaces, allows one to create an entire AJAX application and not see a lick of JavaScript. Just as traditional server-side tags are expanded into HTML before being served to the browser, AJAX aware JSF tags are expanded to HTML + JavaScript. Thus you get most of the benefits of a rich JavaScript client, but you are only coding in one language: Java. The only problem with this is that, in reality, you are coding in all sorts of languages: JSP, JSF tags, EL (the Java Expression Language). Plus large chunks of the application ends up in JSF specific XML files (faces-config). This model is the least flexible of the solutions mentioned in this article.

Sun's Phobos

Phobos, like Jaxer, is a server-side JavaScript web application server. However, Phobos is based on the rhino JavaScript engine. Rhino itself is a pure Java application. This means it will be slower than C based JavaScript engines (like SpiderMonkey, TraceMonkey used in Jaxer). But it also means its very easy to make use of existing java code and libraries - a potentially huge benefit. Plus, Phobos takes the form of a standard Java WAR file. Meaning it can run on top of any Web Container that supports the Java Servlet 2.4 spec such as Tomcat, Jetty, IBM WebSphere, etc.

Jaxer

Jaxer is a server-side JavaScript application server. Technically speaking Jaxer takes the form of a web server plug-in. It currently runs on Apache 2.0 and Jetty (with plans to support IIS). It uses the SpiderMonkey JavaScript engine, the same one used by Firefox. They claim that "Jaxer performance is comparable to PHP and Rails". However, they will soon be switching to Firefox's newest JavaScript engine (TraceMonkey) which should prove much faster. One interesting point about Jaxer is that it's server-side programming model is essentially the same as the client-side programming model, namely DOM. Thus client and server not only use the same language, they also use the same API.

10Gen

10Gen (like Jaxer and Phobos) is a server-side, application server that supports JavaScript, Ruby and Python. There whole schtick is that the platform is "cloud-aware" from the get-go. In that since it's a bit like Google's app engine. You can use their platform as a "service" or you can run their software in your own cloud (i.e. on your own servers).

My Own Experience

I have dabbled with all of these technologies. But the ones I have the most experience with are GWT and JSF/ICEFaces. Presently, my favorite tool for web development is GWT. It doesn't have the most feature-rich widget library in the world. But that is because they focus their efforts on making the "core" as good as it can be, then leave some of the widgets to third party vendors (of which there are dozens). If you work with GWT you will become a better web developer. There is some serious "smarts" contained in GWT. And it will rub off on you. Things that took days in JSF take minutes in GWT (creating your own component, for example). GWT is a thin layer on top of DHTML. It doesn't try to hide anything and generally doesn't create a whole new abstraction layer. But I could go on all day about GWT, but that would be a subject for a different post. Here are a few links about the general philosophies behind GWT:

GWT Mission Statement
GWT Design Axioms

User Experience (UX)

2008-12-16T19:25:00.000-08:00

I am a developer. But I am also an avid user of web sites and web applications. And as a user, I happen to really like the applications put out by Google. In particular, I like how they keep things simple, clean and uncluttered. And they don't get side tracked adding features and frills that impress everyone except the actual user of the application.

Then I found this on Google's web site, Ten principles that contribute to a Googley user experience, that summarizes their design philosophies.

I also like the apps by 37signals, specifically: BaseCamp and Highrise. As luck would have it, 37signals also has a web site explaining their UX and development philosophies called Getting Real.

GWT apps are Small!

2008-12-04T11:19:00.000-08:00

I just wrote a small DOJO page that has nothing on it but a combobox with 10 hard coded entires. I ran it thru firebug and the total download size was: 268 kb. Then I ran the gwt app i am working on thru firebug ( a full app with multiple screens, dozens of widgets). The entire download size of the gwt app was 98 kb. To summarize:

268kb: DOJO app with one combobox
98kb: a complete gwt application

Google's 4 Approved Programming Languages

2008-01-31T07:27:00.000-08:00

I just learned today that within Google there are only 4 approved programming languages:

C++
Java
Python
JavaScript

Noticeably missing are C# and Ruby. Perhaps they figure that Ruby and C# occupy the same niche as Python and Java and are thus redundant and unnecessary.

Herding and Branding

2007-07-03T16:54:00.001-07:00

Marketing people have a concept they use known as "branding". As a capitalist and entrepreneur, I love the idea of branding. I'm impressed by anyone who can get otherwise intelligent people to pay $50 for a five dollar white underwear t-shirt by putting the name of their brand. That is really cool. I wish I could do that!

But with that said, as a consumer I find branding kind of insulting.

I suspect that Lexus, Toyota and Scion (all Toyota brands) do not represent 3 categories of car as much as they represent categories of marketing strategy. In other words, different people respond differently to different sales gimmicks. By creating 3 virtual car companies, Toyota can ensure that each person receives the exact sales message that works on them.

There is nothing inherently wrong with this kind of thing. Obviously it works on some people - maybe all people. But none the less, it's annoying to me - just as it's annoying when the used car salesman uses a cheap sales line on me.

IBM WebSphere
At one point WebSphere was a product (an app server). Then the marketing people at IBM thought: "How can we leverage the success of that product?" Their answer: Rename every other product to WebSphere. So IBM's IDE was renamed to WebSphere, IBM's messaging product was renamed to WebSphere, and so on. Yes. IBM really does think we are that stupid. Or perhaps their sales pitch isn't geared to the cats, but rather the cat herders. But in the end the word WebSphere, with so many meanings has no meaning at all. The whole WebSphere craziness just serves to confuse.

J2EE
I think the biggest culprit of branding craziness has to be Sun. I am a Java specialist. It's all I do. Yet, I have no idea what the current version of Java is. We started with 1.0, then 1.1, then 1.2, then 1.3, 1.4,1.5 and 1.6. But then there is also Java 5 and Java 6. And what the hell is Java 2 (as in J2SE and J2EE)?

JavaFX
So now Sun is at it again. JavaFX (Sun's cool new programming language) is not a language - it's a brand. That means JavaFX could refer to a programming language or a mobile phone but it could also refer to a banana.

JavaFX

2007-06-27T22:58:00.000-07:00

So JavaFX is my new favorite programming language. Thats right - JavaFX is a new programming language.

I think a lot of people might be getting the wrong idea about JavaFX because of the marketing hype. When I first heard about JavaFX, it was positioned as an alternative to Flash (or Flex). As a way to create (and deliver) Rich Internet Applications. But upon further inspection one realizes that, at its core, JavaFX is really a new language that runs on the JVM. I would say that comparing JavaFX to Groovy (or even Spring) would be more appropriate than comparing it to Flash.

[Correction: Technically speaking JavaFX is a brand - JavaFX Script is the name of the programming language.]

I'm low on time right now and can't go into many details, but let me say this: JavaFX is not just another language that runs on the JVM, its a very cool language. By cool, I mean that JavaFX has a number of innovative features that produce immediate and pronounced payoffs. For example:

1. Type-safe JSON
Any one who has used languages like Ruby or Groovy or even JavaScript knows that those languages don't need all those damn XML files that are part and parcel to modern Java frameworks.

Essentially, any language that has syntax for array literals PLUS map literals has built-in support for declarative, XML-ish constructs:

For example in JavaScript:


var company = {
  name: "Smart Soft",
  url: "www.smart-soft.com",
  people:[
    {firstName:"Dave",lastName: "Ford"},
    {firstName:"Michelle",lastName: "Goldstein"}]
}

Now JavaFX has this same feature - but with one distinct advantage: the map literals are not maps - they are typed Java objects. Here is how this would look in JavaFX:


var company = Company{
  name: "Smart Soft"
  url: "www.smart-soft.com"
  people:[
     Person{
         firstName:"Dave"
         lastName: "Ford"
     },
     Person{
         firstName:"Michelle"
         lastName: "Goldstein"}
  ]
}

This "typed" feature means that the IDE can give you auto-completion and find your errors sooner rather than later. Bottom line: integrated declarative-style programming + type-safe IDE auto-completion and early error detection = big productivity gains.

2. Language level support for bi-directional data binding. This is analogous to JSF's "value binding expressions" or Microsoft's "bound controls". The data binding feature supports MVC architectures in the most elegant manner I have seen yet. You simply declare that a particular UI text field is bound to some field in your model object. And then JavaFX keeps the model and view in synch automatically.

There is much more to JavaFX than I have mentioned, but this should give a you a basic feel.

Minimal JavaFX Demo

2007-06-27T11:28:00.001-07:00

Here are the absolute simplest steps to get a demo of JavaFX up an running:

Download the 3 JavaFX jar files:
javafxrt.jar Filters.jar swing-layout.jar

You can get them from here:

https://openjfx.dev.java.net/source/browse/openjfx/trunk/lib/

Create a text file called Hello.fx:


import javafx.ui.*;

Frame {
    content: Label {
        text: "Hello JavaFX"
    }
    visible: true
}

Add the 3 jars and Hello.fx to your classpath

Run the script like so:

java net.java.javafx.FXShell Hello

Note: The name Hello is resolved via the classpath (not the file system).

Here is how my folders looked:

~/DavesJavafxDemo/classes/Hello.fx ~/DavesJavafxDemo/lib/javafxrt.jar ~/DavesJavafxDemo/lib/Filters.jar ~/DavesJavafxDemo/lib/swing-layout.jar

Thus, my classpath must include the classes folder plus the 3 jar files:

~/DavesJavafxDemo/classes ~/DavesJavafxDemo/lib/javafxrt.jar ~/DavesJavafxDemo/lib/Filters.jar ~/DavesJavafxDemo/lib/swing-layout.jar

Here is the shell script I used:
```
cp=./lib/swing-layout.jar:./lib/Filter.jar:./lib/javafxrt.jar:./classes
java -classpath $cp net.java.javafx.FXShell Hello
```
Note: The way I have the paths specified, you must run this script from within DavesJavafxDemo folder.

On Windows, the shell script (runDemo.bat) would look like this:
```
set cp=.\lib\swing-layout.jar;.\lib\Filter.jar;.\lib\javafxrt.jar;.\classes
java -classpath %cp% net.java.javafx.FXShell Hello
```

Dynamic Language Benefits

2007-04-07T08:15:00.000-07:00

Here is a specific, concrete example demonstrating one of the benefits of a dynamic language (like JavaScript and Ruby) as compared to a static language like Java.

Suppose you want to do some ad hoc profiling (and you don't have a profiling tool handy). Here would be one way to do it in Java:


long t1 = System.currentTimeMillis();
slowMethod();
long t2 = System.currentTimeMillis();
long delta = t2 - t1;
System.out.println("slowMethod: " + delta);

And here would be the same thing in JavaScript:


executeAndTime(slowMethod);

This works because JavaScript treats functions as just-another-object. As such, the function can be passed around like any other object. In this example, slowMethod (an object of type function) is passed as an argument to the executeAndTime() function. Here is what executeAndTime looks like:


function executeAndTime(f){
    var t1 = new Date();
    f();
    var t2 = new Date();
    var delta = t2 - t1;
    document.write("Delta for [" + f.name + "]: " + delta + " millis");
}

What to Hide?

2007-01-25T07:48:00.000-08:00

In the world of computer programming, a lot of thought goes into deciding "what to hide" - in particular, what to hide from the computer programmer.

For example, at some point in history people wrote applications in machine language. Today machine language is hidden from the developer and we see something more human-friendly, like C or Java. The stuff that gets hidden is usually closer to the way machines communicate. The stuff that remains visible is closer to the way humans communicate. At least that's the idea.

The terms high-level and low-level are used to convey this concept. Low-level technologies are more machine-ish and ripe for hiding. High-level technologies are more human-friendly. The high-level technologies are often referred to as abstractions that encapsulate or hide the low-level technologies. Today's high-level technology often becomes tomorrow's low-level technology.

Char and Array

Two language constructs that I once used daily are the char and the array. Today, I use them only indirectly, preferring higher-level constructs like String and Collection. In other words, the char and the array are going the way of machine language: mostly hidden.

SQL

Sometimes it's not alway clear what should be hidden and what shouldn't. For example, many years ago a high-level language called SQL was invented for working with data. SQL is an abstraction designed for humans. SQL is, in no way, a reflection of how machines or hardware work. It was designed for humans. Yet still, SQL is gradually crossing over to the world of the hidden, joining the ranks of machine language, chars and arrays. If you have ever used JDO, EJB Entity Beans or Hibernate, then you know what I'm talking about.

JavaScript

The blogs are filled with developers singing the praises of dynamic languages (formerly known as scripting languages). The two most popular dynamic languages that I use are JavaScript and Ruby. Dynamic languages are often more terse, flexible and feature-rich than static languages. Static languages, like Java, do have their advantages though. They are typically more IDE'able and optimizable. The thing to note here is that both Java and JavaScript are pure abstractions. Both were invented to be human-friendly ways of programming computers. But if I had to pick one as being "lower-level", it would be Java.

So which is the preferred abstraction? Java or JavaScript? Not everyone agrees. But if you look at frameworks like the Google Web Toolkit (GWT) or ICEfaces you will see that JavaScript may be crossing over into the land of the hidden. With GWT, the human codes in Java, then the GWT compiler translates your Java into JavaScript. No human ever sees the JavaScript. Only the machine sees it. In this case the machine is the JavaScript enabled web browser.

Hiding Gone Wrong

The key point here is to choose your abstractions wisely. The stuff that's not hidden ultimately becomes a dependency. The goal is to encapsulate things that are complicated or volatile behind abstractions that are simple and stable. Here are a few examples where, in my opinion, the choice of "what to hide" is sometimes wrong:

Web Service Toolkits.
XML is simple and stable. HTTP is simple and stable. Web service toolkits (like Axis) that hide the XML are not simple or stable. They add unnecessary layers and complexity. For most developers that need to produce or consume web services, it makes more sense to work directly with XML. Tools like Axis have their place, but in my opinion, that place is a fairly small niche*.

O/R Mappers (like Hibernate)
SQL is simple, stable and extremely versatile. I can teach anyone SQL in a half day. Hibernate is not so simple. Contrary to what anyone tells you, it's a very sophisticated tool. If you don't know what your doing, it can easily cause more trouble than it saves you. Again, Hibernate does have its niche*. In fact, I love Hibernate. But do keep in mind that with Hibernate (and O/R mappers in general) you are encapsulating something really simple with something really complicated. So be sure you are clear on the benefits and drawbacks before moving forward.

* Note: if you take our Hibernate or Web Services workshop, we do cover these decision making criteria. That is: when does it make since to forgo Hibernate or Axis and work directly with the underlying technology (like SQL or XML)?

Amazon and Google use Table-Based Layouts

2006-11-13T09:54:00.000-08:00

This is my addition to the already over-blogged "table-based vs. CSS-based layout" debate. The older, tried-and-true technique for laying out web pages is to use HTML tables. A newer way is to use CSS Floats. Neither floats nor tables were ever intended to be used for page layout. I won't restate what's been stated but here are my 2 cents on the issue:

The benefits of float-based layouts are overstated.
The difficulty in using float based layouts are understated.
One of the benefits of float-based layouts is separation of content from layout. This benefit can be achieved in other ways, for example on the server-side, by using XSLT, sitemesh or portal technologies.
Amazon and Google use table-based layouts. That has to count for something.

[Update: 5/1/2009] : Today, amazon and Google's Blogger.com both use CSS based layouts

10 IDE Shortcuts Everyone Should Know

2006-11-10T08:42:00.000-08:00

Below are 10 IDE shortcuts that everyone should know but many don't. These are tricks that save me lots of time. I use them so often they are hard-wired into my brain. They work in IntelliJ and Eclipse and probably others.

1. Introduce Variable

IntelliJ calls it "Introduce Variable" (Ctrl Alt V)
Eclipse calls it "Extract Local Variable" (Alt Shift L)

Here is how it works. You type this:

new FooBanger();

Then, with your cursor positioned at the end of the line, press Ctrl Alt V. IntelliJ prompts for a variable name and then changes the code to this:

FooBanger fooBanger = new FooBanger();

Alternately, if you have a long expression like this:

x.getPerson().getCompany().getCEO().getLastName();

You can highlight an expression within the expression, for example:

Then press Ctrl Alt V. IntelliJ prompts for a variable name and changes your code to this:

Company c = x.getPerson().getCompany()
c.getCEO().getLastName();

2. Goto File

IntelliJ calls it "Goto File or Goto Class" (Ctrl Shift N or Ctrl N)
Eclipse calls it "Open Resource" (Alt Shift L)

A large part of what modern IDE's do falls under the heading of "Project Navigation", i.e. making it easy to quickly move from file to file within a large project. This and the next two tips deal with project navigation.

If you remember the name of a file but don't feel like navigating 8 folders deep to get to it, then use this trick. Press Ctrl N. Then type the first few letters of a file name. The IDE then takes you to that file. You don't have to remember what folder the file is in.

3. Hyperlink (Jump to File)

This works the same in IntelliJ and Eclipse. Hold down the control key, then hover your mouse over a class name. As your mouse moves over the class name, it turns into a hyperlink. Click the hyperlink to goto the highlighted file.

4. The Back Button

IntelliJ and Eclipse both have a browser style Back button which takes you to the previous file you were working on.

5. Delete Current Line

Eclipse: Ctrl D (D for delete)
IntelliJ: Ctrl Y (Y for yank)

6. Duplicate Current Line

Eclipse: Ctrl Alt Down
IntelliJ: Ctrl D (D for duplicate)

-----------
OK, so I stopped at 6. This blogging business is tiring.

Welcome

2005-07-06T17:15:00.000-07:00

Welcome to my new Blog. I have nothing to say at the moment. Actually, I have lots to say, but just too busy right now. But at least I've taken the first step: setting up the blog.