• Search

• Recently Written

  • Economy or Agony?
  • Darnit! Basecamp did it again!
  • Document Templates for Entrepreneurs
  • Evans Codeworks is Hiring!
  • The easy way to learn .NET
  • Cornell entrepreneurship on MySpace
  • Speed up Rails apps with RPM
  • Inbound marketing
  • Excellent screencasts available on .NET MVC
  • Entrepreneurship videos from Stanford

• Categories

  • .NET
  • Cornell
  • Entrepreneurship
  • Evans Codeworks
  • Fitness
  • Fun
  • Online marketing
  • Productivity
  • Programming
  • Puzzles
  • Ruby on Rails
  • Software Performance Tuning
  • Uncategorized
  • Web Development

• Archives

  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • December 2007
  • November 2007
  • October 2007
  • September 2007
  • August 2007

There a couple of ways to invoke javascript events via the onClick handler.

Approach #1

The one I see most often is this:

<a href="#" onClick="someFunction();">Click me. I know you want to.</a>

This is my least preferred. Why? Because depending on what the function actually does, there’s a good chance that what will happen is that someFunction will be called and the screen will then shift to the top of the document. This I find just annoying.

Approach #2

An improvement on that first case is this:

<a href="#" onClick="someFunction(); return false;">Click me. I know you want to.</a>

By returning false inside onClick you execute the javascript, but the screen won’t scroll to the top of the document. This is better. But, it’s still not perfect. The problem with this is that it doesn’t degrade well into browsers with javascript turned off. If javascript is disabled in the browser, clicking on the link will just pop the user to the top of the page and leave them there. This is unexpected and it’s not helpful to them in any way.

Approach #3

The best overall approach is this:

<a href="/javascript_required.html" onClick="someFunction(); return false;">Click me. I know you want to.</a>

In the event that the user has javascript disabled in their browser, they will be taken to a page (/javascript_required.html) where you can explain to them that they have javascript turned off and that it’s needed for certain functionality to work. In the event that their browser has javascript turned on, then they will see whatever behaviour you intend. It’s the perfect solution!

One note on these approaches: The second case is my preferred technique while developing and debugging applications. Without the "#" as the href, should your event handler throw an exception or otherwise run into trouble, your browser will just go to the url specified in the href attribute. If this takes you to another page you won’t get to see what went wrong. So, leave the href attribute as "#" while debugging. Switch it to something akin to "/javascript_required.html" when going to production.

Gojko Adzic posted yesterday about the waterfall trap for agile projects. In his post he makes the point that iterative development is not equivalent to incrememtal development.

Iterative implies that with each iteration the entire application will be the result. Each successive iteration will contain a greater level of detail than the iteration before it. And no iteration guarantees a “complete” or “finished” product.

In contrast, incremental development implies that each development cycle will yield only a portion of the total application. But what is produced is a more or less finished product.

This is where I do my bit about how frameworks are not right for every project.

Developers and managers tend to put their faith in a framework because they believe that the framework is a faster and/or cheaper way to obtain a certain set of functionality. That is to say that they feel that the framework is either a more “complete” solution than they could obtain by starting from scratch although it won’t necessarily save them any time, or they feel that the framework provides them with “enough functionality” to build what they need to build, and it will save them time.

Over time, a shop develops a body of expertise using a certain set of tools, or in this case, frameworks. And from then on they typically try to solve every problem with that same set of tools. A team becomes “a java shop”, or “cold fusion experts” or “ruby gurus”, etc.

An unspoken expectation from developers and managers is that the API for a framework will remain stable. They don’t want to have to go back and rewrite portions of their application because the framework changed.

This unspoken assumption is one of the things that makes frameworks a pain for some projects. This expectation of completeness means that frameworks are expected to be developed incrementally. It is expected that whatever is available is complete. And this means that frameworks are expected to be built in a non-agile way.

What’s important to remember here is that for each job you must use the right tool. Agile is new(er than waterfall). But that doesn’t mean that every other methodology is bad, or in some way inferior. Agile is great for some projects. Typically smaller projects are more appropriate for the agile methodology. But other projects are not right for (exclusively) agile methods. Larger projects really do benefit from things like frameworks when used appropriately.

A lot of managers I think would say they use agile methods. They would promote them and advocate for them as a way of saying “I get it! Waterfall is bad. Agile is cool. Let’s be cool!” But it’s important to realize that while agile is good, so are other methodologies.

It’s important to not confuse terminology to make something seem like something else in an effort to be cool. It’s also important to resist drinking the cool-aid. If you’re doing something, and it’s working for you, experiment and explore alternatives. But ultimately, be honest with yourself and your team about what works best for you. And when you decide to fix something, just be sure to use the right tool.

I came across this post by Jason Hunter on The Innovators Dilemma from 2005. Jason Hunter is a big name in the J2EE/XML space if you don’t know who he is.

Here’s the nut of the article:

… you can listen to customers, provide them with what they want, but still lose out — because a cheaper, not-as-good but good-enough competitor comes in and eats your market.

Ruby on Rails is mentioned (remember, this is back in 2005) with all of the same knocks against it that I still hear today. “It doesn’t scale!”, “It’s over-hyped!”, etc. etc. These are totally bogus arguments. Whatever truth there was in those statements has been diminished by the fact that the tools today are much better than they were 2-3 years ago. Two prime examples of this are Mongrel and Capistrano, tools which address issues (scalability via clustering, and deployment to and management of that cluster) that are found in their most virulent forms in the Enterprise.

If I have a point to make on this subject, it’s this: Some decision makers in organizations that consider “enterprise” issues to be relevant to them are solving the wrong problem when choosing Java over more nimble tools like Python and Ruby. This pertains mainly, but not exclusively to organizations building web-apps.

The bottom line is that compiled languages !!SUCK!! for web development!!! The compilation time is a killer. The restarts are a killer. Yes, Java in particular has numerous frameworks which aim to ease the burden of the compiled nature of Java. But those frameworks just make for more stuff to learn, therefore complicating the development process. Any solace you may take in the fact that “our apps scale” (which is a farce in fact, because scalability never comes for free) should be immediately squelched, and in fact rendered completely insignificant by the fact that your app took 10 to 15 times as long to build.

When all you have is a hammer, every problem looks like a nail.

This has to be my favorite quote when it comes to “The Enterprise”. When you say that your problems are hard, that your software is complicated, that it’s under crushing load, etc., etc., it will be. If you step back and allow yourself to untangle “The Enterprise” you realize that it’s not one big, nasty property of your organization, or your business, or anything. What you really have is a lot of small tasks, problems, challenges, each of which needs a simple, flexible and manageable codebase to support or enable.

When you take that step back to refocus and adopt a different paradigm, the complexity of “Enterprise” becomes a very difficult pill to swallow. THERE ARE BETTER TOOLS!!! And the value proposition they offer is faster development cycles, shallower learning curves (though, yes, you do need to learn some new languages), and ultimately more satisfied customers.

I’ve read a number of posts/articles lately discussing the fact that Java is far more verbose than Ruby or Python. The single biggest contributor to this phenomenon is the Java Beans design pattern.

This hit me like a ton of bricks about two months ago during an email exchange with Andrew Myers, a professor at Cornell specializing in programming languages. I had asked him how hard it would be to use Polyglot to generate default get/set methods for Java classes as part of the compilation process. Professor Myers’ response was that if I’m using get/set methods to simple expose class attributes then I’m doing something wrong. This was so obvious. Why didn’t I think of it!?

I understand why get/set methods are preferred to simple public attributes. But in practice, 99.999% of the time writing get/set methods is just busy work. And javadoccing those get/set methods is such a ridiculous waste of time.

Mixing and matching get/set methods with public class attributes would make programming with those classes confusing. And sometimes (that 0.001% of the time) it is necessary to do something special in a get/set method that would be, let’s say, error prone to do any other way. So should we use the get/set technique all the time just because we’ll need it in that 0.001% of cases? H-E double hockey sticks NO! That’s exactly the kind of thing that makes Java more verbose, and therefore less productive than scripting languages like Python and Ruby.

Just because I know some of you out there are thinking it, NO. IDEs don’t make this a non-issue. That’s such a cop-out. It’s a fundamental short-coming of the language. It should be fixed/improved.

So, what would I suggest as an alternative? I like the Python technique of using Properties. It’s very flexible, terse and useful.

I would really love to see this feature in Java 7.