• 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

InnerWorkings is one of the best resources for learning .NET that I’ve come across. They have 500+ hours of training material, all hands-on development, not just reading or watching videos.

The process is very effective. You purchase and download a training course. You’re then presented with a programming challenge. You click a button in the InnerWorkings interface to open up Visual Studio with the basic project code. You then write the code needed to complete the challenge.

During the coding process you’re aided by a VS add-in which allows you to easily refresh yourself on the challenge. When you’re done, you click another button to submit your solution to be verified. Your solution either passes, in which case you’re done, or doesn’t pass, in which case you’re given the opportunity to correct your solution.

A couple of things are particularly nice about this.

1. You’re given a very clear task. Anything that helps you stay focused while learning a new environment is tremendously helpful. When everything is new I find it tremendously hard to stay on track. I constantly discover new and interesting things elsewhere while going through documentation that pulls my attention off the task at hand. “Guard rails” so to speak I find very helpful.
2. You’re given starter code to work with. This helps you in two ways. First, it shows you how to get started, teaching you some best-practices along the way. Second, it alleviates a lot of the tedious startup work involved in starting from scratch.

I’m looking forward to working through a few of the challenges.

Here are a few simple suggestions that will go a long way toward helping you write highly-performance systems.

Be smart: Performant systems are what you get when you avoid things that slow a system down. Computers are inherently fast. Just don’t get in their way. Know what things slow a system down and just avoid doing those things. Beyond that speed comes from applying common sense.

Stay Fresh: Keep your brain sharp by often taking breaks. Stop and take time to recharge your mental batteries when things start to seem complicated.

Use the right tools: Don’t use a sledgehammer to drive a nail. Don’t use “enterprise” technologies to build prototypes. Every tool has strengths and weaknesses. Effectively leveraging strength will make high performance possible.

Be careful with frameworks: Frameworks are good for abstracting repetitive tasks. They seldom offer speed and simplicity. Use them as needed. But don’t base your architecture or design on them.

Beyond these simple points it comes down to experience and knowing the ins and outs of the specific tools and technologies you’re using.

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.

I had a 36 minute-long revelation this past Monday while watching this screencast by Sean Kelly.

Sean spends 36 minutes developing two toy applications in each of 5 different frameworks (1 Java, 1 Ruby and 3 Python). The basic gist of the screencast is “why Java/J2EE sucks for web-app development”. I felt he made a tremendously compelling case.

Everything he covered felt very familiar to me. He presents the subject much better than I’ve yet been able to.

I’ve recommended this video to everyone I know doing development. I can’t recommend it strongly enough. It’s 36 minutes that might just help you get your development projects back on track.

Another thing I hate about Toplink. The mapping editor support within JDeveloper is not compatible with the standalone Mapping Workbench. They are built using different offline DB and Java class definitions.

Two tools built by Oracle. Both do the same thing as far as Toplink is concerned. They configure a datasource for Toplink interaction. Yet they use different foundation classes and output configuration files that are incompatible with one another? WTF? Not only that, but they aren’t even smart enough to recognize when this occurs. So when you open a file in one that you created in the other you just get this:

oracle.toplink.workbench.framework.OpenException: java.lang.NullPointerException
	at oracle.toplink.workbench.scplugin.SCPlugin.open(SCPlugin.java:113)
	at oracle.toplink.workbench.framework.internal.FrameworkApplication.open(FrameworkApplication.java:689)
	at oracle.toplink.workbench.framework.internal.FrameworkNodeManager.openCallback(FrameworkNodeManager.java:341)
	at oracle.toplink.workbench.framework.internal.RunnableProjectLoader.run2(RunnableProjectLoader.java:76)
	at oracle.toplink.workbench.framework.internal.RunnableProjectLoader.run(RunnableProjectLoader.java:63)
	at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
	at oracle.toplink.tools.sessionconfiguration.DTD2SessionConfigLoader.load(DTD2SessionConfigLoader.java:70)
	at oracle.toplink.tools.sessionconfiguration.XMLSessionConfigLoader.loadConfigsForMappingWorkbench(XMLSessionConfigLoader.java:146)
	at oracle.toplink.tools.sessionmanagement.SessionManager.getInternalMWConfigObjects(SessionManager.java:149)
	at oracle.toplink.workbench.scplugin.model.adapter.RootSCAdapter.load(RootSCAdapter.java:110)
	at oracle.toplink.workbench.scplugin.model.adapter.RootSCAdapter.(RootSCAdapter.java:69)
	at oracle.toplink.workbench.scplugin.model.adapter.TopLinkSessionsAdapter.(TopLinkSessionsAdapter.java:56)
	at oracle.toplink.workbench.scplugin.SCPlugin.open(SCPlugin.java:110)
	... 5 more

Way to go Oracle. Thanks for making your tools developer friendly.

So I’m off to download and install the 441MB JDeveloper package instead of the 28MB Toplink Workbench. Later.

I’m working on migrating an application from Weblogic 8 to Tomcat 6. The strict J2EE portions of the migration were cake. Weblogic has some conventions for storing classes and other resources shared among applications deployed to a server. Reverting these conventions to use something simpler and compatible with Tomcat (i.e. common/lib) was easy. Just about everything else was just a matter of getting my projects set up in Eclipse WebTools. I use MyEclipse for Kuali. So it took me a little bit of digging to figure out how to do everything in WebTools. But, all in all an easy process.

Then it came time to configure Toplink. What a nightmare. The docs are years old. And the docs don’t even cover Tomcat. They only cover OC4J, WebLogic, WebSphere. Not surprised by that, just disappointed given the popularity of Tomcat. The configuration files used by Toplink (sessions.xml and project.xml files) need reconfiguring. And the only (documented) way to reconfigure them is to use Toplink Workbench, which I don’t really feel like installing and using (the last thing I need right now is to add something else to the mix).

I searched the OTN forums for help on this. But the only things really mentioned there refer to JPA implementations, one of which this project doesn’t happen to be.

And my least favorite part about this is the exception messages I get from Toplink. They’re completely unhelpful. Here’s an example:
This exception indicates that there’s an error in the username/password combination:

Exception [TOPLINK-4002] (OracleAS TopLink - 10g (9.0.4) (Build 031126)): oracle.toplink.exceptions.DatabaseException
Exception Description: java.sql.SQLException: invalid arguments in call
Internal Exception: java.sql.SQLException: invalid arguments in call
Error Code: 17433

How intuitive is that!? And the best part is that the username/password combination is in both the project.xml and the sessions.xml. So I have to test 4+ combinations to figure out which one is wrong. *sigh*

So, overall I’m not very pleased with Toplink. I’ve used it in the past and thought it was OK. But compared to the relative simplicity of tweaking this sort of thing in Kuali, this is a real pain in the butt.

I’m considering recommending migrating from Toplink to JPA/Hibernate. Kuali’s headed that way. That might be overkill. I’m probably missing something simple. Without a good user community and any kind of helpful documentation it’s going to be a task getting on track.

So how about it Oracle? How about a screencast showing a Tomcat 6+Toplink configuration eh? If/when I figure this out I’ll have to put one together.

The Problem

Write a function to print all of the permutations of a string.

The Solution

See: StringUtil.permute(String)

Next Page →