indiWiz.com

PyLucene, a Python implementation of the popular Java indexing and search software is now part of the Apache Foundation.

Google is hosting versions of popular OpenSource JavaScript libraries (as a CDN–Content Delivery Network). The list of libraries include Prototype, jQuery, Scriptaculous, YUI and others. These can be directly linked to the Google URL. The advantages:

• Bandwidth saving: these files need not be hosted in local webservers, saving local bandwidth.
• Effective client side caching: if a person visits 100 sites using Prototype library version 1.6.0.3, and if all these sites link to the Google CDN, then the script will be downloaded to the user’s system only once.

Now the common fear among people: what if the URL changes? What happens when newer version of the libraries come up? Google’s promise (from the site):

Google works directly with the key stake holders for each library effort and accepts the latest stable versions as they are released. Once we host a release of a given library, we are committed to hosting that release indefinitely.

So ready to jump start into JBoss RESTEasy? Dive!

Writing the JAX-RS Class

The first step, let us write a simple echo service using JAX-RS:

package testpackage;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.core.Response;

@Path("/echo")
public class Echo {
    @GET
    @Path("/{message}")
    public Response echoService(@PathParam("message") String message){
        return Response.status(200).entity(message).build();
    }
}

Adding the JBoss RESTEasy dependency to Maven project

If you are using Maven to build your projects, add the dependency for RESTEasy:

<dependency>
    <groupId>org.jboss.resteasy</groupId>
    <artifactId>resteasy-jaxrs</artifactId>
    <version>1.0.0.GA</version>
</dependency>

Also remember to add the JBoss repository to the pom.xml (RESTEasy is not available in Maven public repository):

<repository>
    <id>jboss</id>
    <url>http://repository.jboss.com/maven2/</url>
    <releases>
        <enabled>true</enabled>
    </releases>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
</repository>

Configuring web.xml

The bare minimum needed to have RESTEasy running is:

<web-app ...>
    ...
    <listener>
        <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class>
    </listener>

    <servlet>
        <servlet-name>Resteasy</servlet-name>
        <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class>
    </servlet>

    <servlet-mapping>
        <servlet-name>Resteasy</servlet-name>
        <url-pattern>/*</url-pattern>
    </servlet-mapping>
    ...
</web-app>

Above, we have just added the RESTEasy servlet and listener. Now we have to make it load our JAX-RS class. This can be done in two ways. One, just let RESTEasy scan the CLASSPATH to identify and load JAX-RS resources:

<web-app ...>
    ...
    <context-param>
        <param-name>resteasy.scan</param-name>
        <param-value>true</param-value>
    </context-param>
    ...
</web-app>

The other option is to specify the resources manually (use CSV format):

<web-app ...>
    ...
    <context-param>
        <param-name>resteasy.resources</param-name>
        <param-value>testpackage.Echo</param-value>
    </context-param>
    ...
</web-app>

After deploying this, you may access your application (if your are using default Tomcat/Jetty installation): http://localhost:8080/resteasytest/echo/hello,world (assumes your application is deployed as resteasytest.war)

I have seen this scenario many times: programmers fearing existing code, writing extra code just to accommodate new features without changing existing code. A similar attitude I see is, is manifest in projects dealing with big databases. People working in these projects don’t dare to question the design of the Database, and subject themselves to finishing the tasks at hand to fit around the existing DB design. This is fear. Fear of:

• Uncertainty. They know existing code works. Refactoring existing might break some functionality.
• Time. The time to refactor code cannot be correctly estimated.
• Work. Of course, this is additional work.

There may be other reasons (for example, greed. The programmer might want to gain a short-term acknowledgment of his speed of delivery). But the common occurrence is Fear. And we will try to understand the implication of this fear:

• Old code gets older.
• Additional code to manage deficiencies in old code need to be created.
• The application becomes monolithic and difficult to change.
• This creates additional fear of change.

The cost involved in maintaining such code is stupendous. And how do we avoid this cost? It is, from my experience, by following some good-old practices and tools:

• Unit tests: The importance of these cannot be exaggerated. When you have a Unit test suite covering your code, it is with more confidence you can refactor it, and more confidence with which change it.
• Each developer gets his own play area: Sharing resources during development is also costly. This is the reason I encourage each developer to have his own database setup and development environment (whenever possible). This isolates the developer, and his fear of breaking the shared environment is nullified (which affects other team member’s productivity). He is more free to innovate and bring in new thoughts.
• Developer’s own coding and commit space: I also encourage people to use distributed source control systems in place of things like svn. This allows the individual to have a independent commit space, where he can commit his work as and when he completes a unit of it, without worry of breaking someone’s build. Again, a source of greater freedom.

I have seen the most unlikely people innovate by following these simple practices. So what is your take on this?

One important parameter in learning a new language is the language’s approachability. I remember the difficulty I faced when learning Java. I was asked to know things like package, static function, etc. I was kept in the blank about these features till I reached the these trails in my learning. This is disappointing, and can intimidate learners from learning such language.

Haskell, just like Python (and other languages like Ruby, Perl, Groovy, etc.) provides a simple interactive shell called ghci. This allows one to immediately jump into Haskell, experimenting with its syntax without further ado.

I have been awaiting the GA release of RESTEasy for some time! Now we have an alternative to Glasssfish Jersey JAX-RS engine.

Today visited the Chennai Book Fair. And in pursuit of my New Year Resolution, I bought Real World Haskell book. I am running Mint Linux, and installed the GHC compiler thus:

$ sudo apt-get install ghc6
$ sudo apt-get install libghc6-mtl-dev

We are in the mid-January of 2009, and I have taken the decision to learn one of these languages this year:

1. Haskell
2. Erlang
3. Clojure

In the recent past I have been hearing some great stuff about these languages. Haskell and Erlang I have been attracted due to their powerful concurrency support. After reading Paul Graham‘s preface in On Lisp, I became attracted to Lisp (and Clojure). Haskell also has a JVM implementation, Jaskell. Coming from a Java background, I think this should be easy for me. Time will tell which one of these I will pick and learn!

Yahoo! still innovates When I searched for java.lang.String, Yahoo! presented me with links to various versions of this API neatly stacked one near to another for me to choose. Cool guys!

We faced a scenario which I have faced before: our application uses Hibernate and Oracle Database. And every time we run tests, we had to configure the database specific to that system. I was fed up by this, and explored the possibility of running our code against a test DB. We finalized on Derby.

So the next step was configuring hibernate.cfg.xml. We did this:

<hibernate-configuration>
    <session-factory>
        <property name="hibernate.connection.driver_class">org.apache.derby.jdbc.EmbeddedDriver</property>
        <property name="hibernate.connection.url">jdbc:derby:target/testdb;create=true</property>
        <property name="show_sql">true</property>
        <property name="dialect">org.hibernate.dialect.DerbyDialect</property>
        <property name="hbm2ddl.auto">create-drop</property>
    </session-factory>
</hibernate-configuration>

In the hibernate.connection.url property note the parameter create=true. This ensures when the JDBC layer establishes the connection, the Database will be created if it has not been created earlier. Another important parameter from testing perspective is: hbm2ddl.auto. The value set in this parameter is create-drop. This ensures if the tables that are mapped in *.hbm.xml files are not present in the Database, they will be created (during the creation of SessionFactory). And when the SessionFactory is closed, the tables will be dropped. Perfect for testing! Note that, if you want the database tables to persist, just give create instead of create-drop.

So where will the DB be created? This is specified in the hibernate.connection.url property. Note the string target/testdb. This is the folder where the DB will be created. Ensure that the relative folder target/ exists in this case (testdb will be automatically created because of the property create=true).

In some scenarios we might want to test the correctness of the application by manually verifying the database content. In such situation, as discussed previously, change the hbm2ddl.auto property to create. After that connect to that DB using the Derby command-line tool:

$ java -cp $JAVA_HOME/db/lib/derby.jar:$JAVA_HOME/db/lib/derbytools.jar \
   org.apache.derby.tools.ij

This will open the ij prompt. Connect to our DB using it:

ij> connect 'jdbc:derby:target/testdb';
ij> select * from __table__;

Isn’t it cool?

I am working currently in a portal project. From various datasources we collect information and publish as portlets. The current UI scenario requires us to use JavaScript libraries like prototype.js and jQuery. In both these libraries, $() has different meaning. So when we tie a particular portlet’s UI to prototype.js, and another to jQuery, we cannot effectively place both of them in the same page.

If HTML/XHTML provides some kind of script exclusion so that scripts placed inside a particular scope do not reveal their functions and variables globally across the page, it is going to be helpful. For example:

<script-package name="abc">
  <script src="prototype.js" type="text/javascript"/>

  <script type="text/javascript">
    // use prototype specific code
  </script>
</script-package>

<script-package name="xyz">
  <script src="jquery.js" type="text/javascript"/>

  <script type="text/javascript">
    // use jQuery specific code
  </script>
</script-package>

In the rare case when a script needs to access some variable defined in different package, it can use some namespace mechanism. Any ideas?