What makes a language Dynamic?

I read an article the other day on coding horror that discusses size is the enemy of software development. One of the opinions from the article was:

If you’re starting a new project, consider using a dynamic language like Ruby, JavaScript, or Python. You may find you can write less code that means more. A lot of incredibly smart people like Steve present a compelling case that the grass really is greener on the dynamic side. At the very least, you’ll learn how the other half lives, and maybe remove some blinders you didn’t even know you were wearing.

I agree 100% with this statement. Where the confusion often comes in is what makes a dynamic language “dynamic”. Is it because of dynamic typing? Is it strong vs weak typing? What about the presence of a MOP?

A lot of the buzz around dynamic languages has been created by the Ruby community, particularly around the Rails application. As described in the previous quote, dynamic languages provide features that allow you to write less code that means more. What about Ruby on Rails allows developers to write less code? There is more provided there than dynamic typing alone can provide.

So what is the definition of a dynamic language? Graeme Rocher had a great session at grails exchange on “Dynamic Groovy – Meta Magic” where he addresses this issue in the introduction. He defines a dynamic language as a language with a Meta Object Protocol (MOP for short). A MOP is (definition from Meta Magic):

A mechanism that makes the semantics of a program extensible.

This definition is a bit vague but in a nutshell it allows classes to be dynamically modified at runtime. Typically these languages also provide language level ways to intercept method invocation and property access.

There are many languages that support dynamic typing like Visual Basic, BeanShell, Ruby, JavaScript and Groovy but not all of these have a MOP. According to Graeme the main languages that support a MOP are Groovy, Ruby, Small Talk and LISP.

I do agree that a dynamically typed language like JavaScript allows the programmer to write “less code that means more”. The point that I’m trying to make is that a language that is dynamically typed AND has a Meta Object Protocol allows the programmer to write even less code than one that just has dynamic typing.

The meta object protocol is what allows applications like Rails and Grails to create and extend domain classes at runtime.

For this reason, I would recommend that if you are starting a new project, consider using a dynamic language like Ruby or Groovy. A dynamically typed language with a Meta Object Protocol allows you to write less code that means more than a language with no Meta Object Protocol.

Groovy for Java Unit Testing

I listened to a great podcast the other day on “Groovy Programming for Java Guys“. It was a really good look into the groovy language and how it relates to Java software development. I’ve sent this to management to try and help them understand better this whole “Groovy” thing.

My team has been integrating groovy code into our legacy Java project slowly over the last little while. Recently I have added it into our build scripts so Groovy can live alongside Java as a first class citizen. More importantly, now Groovy can be used in our unit tests. The groovyc ant task allows for joint compiling of Java and Groovy sources. This task is available with the new Groovy 1.5 release at groovy.codehaus.org.


There are a lot of features that Groovy brings to unit testing Java code. A big one is using map coercion to create mock objects. Your Java code may use an interface or class that does some particular operation in production. You might not want to actually perform the operation in a unit test but verify that the operation was performed. Coercion allows us to create a mock object that acts as a particular class but has different functionality. For example, if you have a production class that sends an email:
class Mailer {
public void sendEmail() {
// Email sending code…

System.out.println(“email sent”);
}
}

You can simulate a Mailer by creating a map that maps method names to a closure. The as keyword coerces the map to act as the Mailer class.

def fakeMailClosure = {
println “fake email”
}
def testObject = [sendEmail: fakeMailClosure] as Mailer
testObject.sendEmail()

Just a few lines of groovy can create dummy objects that can be used to do whatever you want in a test environment. The testObject can even be passed into Java code where it is treated as a real Mailer.

Just like Taking out the Garbage (With Version Control)

I had a Mathematics teacher in High School who used to get very excited over factoring problems where you could simplify expressions by canceling out terms. He used to say it was just like “taking out the garbage”. Taking out the garbage was not usually a fun task but it is surprisingly satisfying to get rid of stuff that is not necessary and is just clutter. I run into this same sort of thing when developing software. I just love to “take out the garbage”.

Version Control software is essential to any project, no matter how small (That in itself is a topic for another day). Version Control software gives you the ability to take out the garbage all of the time without having to worry about losing something that is important. You can always go back to old versions of a file if you need them at a later point in time.

Delete Unused Classes

Often when you are refactoring a component or adding something you end up with a Class that was used before that is no longer relevant. Delete it. Remember that you can always get it back later if you need it again through your Version Control system. It does not matter how ‘useful’ this code was, how ‘nice’ it looks, how ‘cool’ it is. It may have been a useful utility that you might need again. You have to resist these urges to keep it around. Unless you know for a fact that you will use it again, you should get rid of it. It is not gone forever and you can get it back if you need it. This will help reduce the complexity of your code and consequently the readability.

Delete Unused Code, Don’t Comment It Out

I see a lot of developers who take a piece of code that is no longer used and comment out the entire section. Resist the urge to keep it inside the code. You can always get the code back through version control, so why do you want to keep a long comment block somewhere where it needs to be maintained? Another danger to this is that if you do want to use this code later on, you will likely end up removing comments around code that no longer compiles. Things change and this once working code may no longer work after you uncomment it.

The follow code is a good example of this. The line that was commented called a function that takes 2 parameters. Notice that the current version of the function takes only one. Code blocks that are commented out are not compiled so the code is not kept up to date with the rest of the code.

// We don’t need to do this anymore
// variable = someFunction(a, b)

someFunction(a) {

}

It is simply better to just delete the code block. If you need it at some point in time later, the version control software can resurrect your lost code.

Bug #12324 Add a heading here
Bug reference numbers are not necessary

I have seen lots of code with comments around a changed block indicating the change was for a particular bug. Before long, the code has a mess of comments all over the place indicating bugs that were fixed and where. This is another case where version control software can eliminate comments that unnecessarily clutter your code. This one does require a bit more discipline though.

Always indicate the bug number being fixed and a small when checking in code into Version Control. For example, you could add a comment like “Bug 12324: Added heading to section”. Then when you look through the Version Control log, you can easily see where changes were made and what they were made for.

If you are looking at a particular line of code and you need to know where it came from and why, you can use the “blame” feature. That will give you the person who last changed the line of code you are looking at along with the comment (which should include the bug number and fix description). For more information on this feature of version control systems, check out the “Who wrote this Crap?” (http://www.codinghorror.com/blog/archives/000992.html) article on Coding Horror.

Taking Out the Garbage

So next time you are confronted with “stuff” that is not longer used. Delete it and let your version control do the work of remembering it. This will keep your code much cleaner and easier to read. It is just like taking out the garbage.

Java WebDAV Clients

I have been looking into using WebDAV as the core of a new solution I am working on. I needed centralized, content management style, read and write access to documents from multiple servers. WebDAV interested me because users could easily access these documents using external tools.

The application I am working on is written in Java so I went searching for an open-source WebDAV server and client library. There were a number of options for WebDAV servers:

1) Slide – http://jakarta.apache.org/slide/
This project was one of the primary WebDAV implementations in Java but has been retired as of Nov 3, 2007.
2) JackRabbit – http://jackrabbit.apache.org/
JackRabbit is a JSR170 Java Content Repository. It also provides access to its content through WebDAV.
3) Tomcat – http://tomcat.apache.org/
Tomcat has a WebDAV servlet that can be used to read and write web application content.

Options for a WebDAV client were a little bit more limited. Jakarta Slide had been the primary WebDAV client which was used in may other open source projects. Since it had been retired, I was looking for alternatives. Here is a message posted on the slide mailing list that mentions JackRabbit as the most suitable alternative.

The Apache Jakarta PMC is sorry to announce the retirementof the
Jakarta Slide subproject. After it's last release inDecember 2004,
development activity was significantly reducedand came to a total
standstill this year. Without a minimumdeveloper community that
can release security fixes, we haveno choice but to retire Slide.
We'll keep at least one ofthe mailing lists open for a transition
period, so users candiscuss alternatives and migration away from
Slide. Furtheruse of the Slide codebase is discouraged.

One alternative to Slide is provided by the Apache Jackrabbit
project. Jackrabbit has a healthy, active developer communityand
provides, among others things:- a server-side content repository-
a WebDAV server component for access to the repository- a WebDAV
client componentPlease visit http://jackrabbit.apache.org/ for
more information.

We apologize for the inconveniences.

Roland Weber

The problem is that JackRabbit does not currently have a WebDAV client component. JackRabbit focuses on the Java Content Repository specification and provides WebDAV as a server option. The following post from the mailing list explains.

Re: Webdav Client Examples?

 

by Angela Schreiber Nov 20, 2007; 04:45am

Jukka Zitting wrote:
> Hi,
>
> On Nov 14, 2007 11:26 AM, ossi petz <ossipetz@…> wrote:
>> Has anyone made some examples on how to use HttpClient with the
>> Jackrabbit Webdav Client?

there is an example in the sandbox/spi/spi2dav project.

> Not really. The WebDAV support in Jackrabbit is more focused on
> server-side implementations than clients.

> The best there is for clients is a collection of WebDAV method classes
> in the jackrabbitwebdav component.

… which are only waiting for somebody having time to put them
together to a complete dav client :).

regards
angela

http://www.nabble.com/Webdav-Client-Examples--tf4803755.html#a13852979

When Apache retired the Slide project, they unknowingly retired the primary Java WebDAV client implementation. The folks in Apache must not have communicated with the JackRabbit team to ensure that it would be able to fill the hole that slide left. I continued my quest to find alternative WebDAV clients in Java.

Eclipse used to have a WebDAV client that was used for Team support. This was an extension available for Eclipse 3.2 and earlier called “WebDAV and FTP Support“. This project is no longer being maintained since 3.3 because of the new Eclipse FileSystem. The EFS (Eclipse FileSystem) was a new API for interacting with different file systems. The EFS implementation for WebDAV has not yet been completed. I stumbled upon a new project with Google’s Summer of Code to create an WebDAV EFS implementation. This is a note from that page.

Eclipse’s webdav client hasn’t been worked on for 2 years and has many shortcomings. The Jakarta Slide Webdav client (http://jakarta.apache.org/slide/webdav-client.html) is an actively maintained project.

I found it quite entertaining how Eclipse chose to use Slide as the client implementation because it was “actively maintained”. In reality the slide project had not been updated in years. It may be better than the old eclipse implementation, but it was far from actively maintained. I wonder what will happen with this project once they find out that Slide is no longer being developed.

I also found a few other projects that provide WebDAV access. These also use the slide client to provide their WebDAV functionality.

Maven Wagon – http://maven.apache.org/wagon/wagon-providers/wagon-webdav/
Apache Commons VFS – http://commons.apache.org/vfs/filesystems.html

After all of my investigation, it seems that Slide is still the best (or only) option for open source WebDAV clients even though the project is no longer being maintained.

I hope that the old slide client will eventually become an Apache Commons WebDAV client or maybe be incorporated into the HTTPClient project.

Grails is not Rails

I have been using Groovy for a little while now and am researching the possibility of using Grails for an upcoming project. At the time, I did not no much about Grails but I had dabbled with Rails a bit and got a feel for how it works.

The .NET community created a project called nant, the .NET port of ant. I’m also familiar with all of the various XUnit variants like JUnit for Java, NUnit for .NET, etc… I just figured Grails was a the Rails application for Ruby ported over to Groovy.

This was not the case at all. Both Rails and Grails are “coding by convention” web frameworks for the Ruby and Groovy languages respectively but they have very different design points. I was familiar with how ActiveRecord works in the Rails world and figured Grails would work the same. ActiveRecord takes a database schema and builds the Object model from the database. In Grails, Object Relational Mapping (GORM) instead using hibernate under the hood.

This article gives a really good summary of the differences in the design approach between Rails and Grails:

Ruby on Rails: RoR uses the bottom up approach where you define your model at the database schema level and RoR builds the model to match using naming conventions. You don’t even have to add the properties to your domain classes as RoR will add them based on the naming conventions of the db schema.

Grails: Grails uses the model-down approach where you define your model and it (or Hibernate technically) builds the schema for you. As I mentioned I don’t like this as a matter of taste since I don’t have as much control over the underlying model. To Grails’ credit, you can fine grain control the database schema by using Hibernate’s mapping, but what a pain.

http://thebull.macsimumweb.com/comparing-ruby-on-rails-to-grails

From Waterfall to Agile

I read a great article today on the future of software development. It gives a great summary of what is wrong with the waterfall method of development and how agile methodologies try solve this problem.

The problem was that the Waterfall Model was arrogant. The arrogance came from the fact that we believed that we could always engineer the perfect system on the first try. The second problem with it was that in nature, dynamic systems are not engineered, they evolve. It is the evolutionary idea that lead to the development of agile methods. (article)

Management is often slow to learn of new trends in software development. The fact that agile has been around since the nineties and many institutions still have not heard of it proves this point. I believe the best way to bring agile methodologies into an existing organization that uses the waterfall or another approach is to bring them in slowly. This is what we have done in my organization and it has been very successful. Here are some good starting points for change.

  1. Change how requirements are viewed. If you are handed a set of requirements for an entire product release, plan for them to change no matter how “final” you are told they are.
  2. Split the development cycle into iterations. At the end of each iteration reprioritize your tasks for the next iteration. 3-4 weeks is a good length for an iteration. Create a full release of your product at this point whether someone will actually use it or not. Hopefully you will have a QA team to test it at this point but it is important to create a fully working version of the product anyway.
  3. Leave the design of system components to the iteration they will be developed in.

Pretty soon you will find that your Waterfall approach is a lot more agile than it used to be. I encourage you to keep changing your approach as you find what works best for your organization.

Agile Dynamic Languages for Java

There has been a lot of buzz about Ruby in recent days, particularly around Ruby on Rails. I love these Ruby on Rails vs. X commercials that www.railsenvy.com has created. Rails provides a much better framework for the “web backed by a database” problem than anything I have seen in the pure Java world. Java has become a very bloated language and even the so-called “lightweight” frameworks are large and clunky. Rails is a great alternative for most people.

But not for everyone. I work mostly with Java based server applications that do not fit the “web backed by a database” type of project. These applications could benefit from the Ruby language itself, but not much from Rails. I have looked into using JRuby as a way to leverage the strengths of the Ruby language on the Java platform.

JRuby is a Ruby interpreter written 100% in Java and therefore runs on the JVM. It allows you to have the benefits of Ruby but still be able to use existing Java code. My main issue with this implementation is that it does not inter operate well with Java. Code written for JRuby typically use the Ruby libraries which work distinctly different from their Java counterparts. This makes it difficult to create a hybrid application where both Ruby and Java is used.

This is about the time I found the Groovy project. Groovy is “an agile dynamic language for the Java Platform” (http://groovy.codehaus.org). It is a powerful dynamic language that has many of the sought after features of other languages like Ruby and Python. The key difference here is that Java is a first class citizen in Groovy. The Groovy libraries are built on top of Java, extending and modifying the core API. Groovy makes creating a hybrid Groovy/Java application possible and easy.

For those coming from a Java background, Groovy is very easy to learn. The syntax is very similar to Java with a twist. Semicolons are not required, getters and setters are not required for properties, code closures are available and metaprogramming is possible. If you are looking for Rails, there is Grails which is a web framework for Groovy.

So if you long to wet your feet in an agile dynamic language like Ruby but are stuck with supporting legacy Java applications, I would recommend giving Groovy a try.

URL Based HTTP Authentication

I ran into a situation the other day where I needed to connect to a remote Web server from a server side application. This web server requires HTTP authentication. The user sets the Web Server location from a configuration file.

What I wanted to be able to do was have the user enter the URL in the following format:
http://user:password@server.com/somewhere

The plan was to use Java’s URL connection library to make my connection to the website. I figured that the default implementation of the URL authentication would allow the user name and password to be supplied as part of the URL. To my surprise, I was greeted with a “401 Unauthorized” message.

The way to provide HTTP based authentication in Java is using the java.net.Authenticator mechanism. Java 5 provides a new method on the Authenticator called getRequestingURL(). This allows access to the URL that requested the authentication. By using this method, an Authenticator can get access to the user name and password embedded in the URL.

So, I created a simple Authenticator that uses the Apache Commons HTTPClient to parse the URL and pull out the authentication information.

Here is the code:

public class HTTPAuthenticator extends Authenticator {
    protected PasswordAuthentication getPasswordAuthentication() {
       if (!getRequestingProtocol().equals("http") &&
               !getRequestingProtocol().equals("https")) {
           return null;
       }       URL url = getRequestingURL();
       try {
           // Get the Username and password from the URL
           HttpURL httpUrl = new HttpURL(url.toString());
           String username = httpUrl.getUser();
           char[] password = httpUrl.getRawPassword();
           if (username == null || password == null) {
               return null;
           }
           return new PasswordAuthentication(username, password);
       }
       catch (Exception e) {
           return null;
       }
    }
    public void init() {

        Authenticator.setDefault(this);

    }
}