As recommended by Yahoo on YSlow - tip #1: Make fewer HTTP request and tip #10: Minify javascript- we aim to implement these tips on all our projects with minimal head-ache. While these recommendations are truly useful, implementing them can be quite tedious and challenging. Consider having to maintain multiple min versions of the javascript and the files that links to them! So to alleviate the problem, we created a tool called low-tides (as part of open-tides) that helps automate the merging and minification of css and js files.

So what is the rationale behind the the tool?

  • Maintenance of minified js and css is a nightmare. Keeping separate js and css files for development and production can be very confusing. Some developers might change the production version without syncing with the development version. So eventually, changes to different files becomes a mess — Which one has the latest code?
  • Maintenance of html files that links to proper javascript and css is another problem. Since minified versions are likely to have different filename (e.g. basic-min.js), html codes that reference the scripts need to be changed. This leads to having multiple copies of html files… again.
  • Versioning of html, css, and js files introduce a whole new set of configuration items. Imagine bullets #1 and #2 getting multiplied across a number of version releases!
  • At the time of this writing, there are no tools available that can merge multiple javascripts. The development version of javascript needs to be logically separated while the production version needs to be merged (for lesser http request). Moreover, merging javascript is not straightforward. Some javascripts need to be pre-loaded while others can be postponed.

I suppose by now you get the picture. The solution we propose to this configuration problem is simple:  Always change from the development version and have a deployment script automatically create the production version. As such, files are always maintained from the development version - but the key to this approach is to ensure that the script for creating production versions is quick and easy-to-use.

Now here comes Low-tides. Low-tides is a Java-based program that automatically analyzes html files for javascript and css includes. It will merge includes that are in sequence into a single file and minify it. In summary, it automatically solves all the problems mentioned above.

You can download it here: http://code.google.com/p/open-tides/downloads/list

Usage instructions are available here: http://code.google.com/p/open-tides/wiki/LowTides

Has anyone ever tried looking at OSWorkflow recently? It is unfortunate that this OpenSymphony project has been shelved. However, I found value in this lightweight workflow tool — for one, being lightweight makes it simple and easy to work with, plus, integration with Spring and Hibernate is readily available.

However, since OSWorkflow stopped development, there had been no support for JPA-based applications anymore. Fortunate for those interested in making JPA work on OSWorkflow via Spring, I was able to tweak some of the OSWorkflow classes and integrate it with JPA Session.

The primary problem in integrating OSWorkflow with JPA is the Session. The original session used by OSWorkflow (SpringHibernateOSWorkflowStore) is a sessionFactory injected via Spring. Since JPA uses EntityManager, the sessionFactory and EntityManager are on different transactions.

The solution is to extend AbstractHibernateWorkflowStore and use session from EntityManager. Here’s the code:

public class JPAHibernateWorkflowStore extends AbstractHibernateWorkflowStore {
    @PersistenceContext
    private EntityManager em;

	@Override
	protected Object execute(InternalCallback action) throws StoreException {
        try {
    		return action.doInHibernate((Session)em.getDelegate());
        } catch (StoreException e) {
            throw new RuntimeException(e);
        }
	}

	public void init(Map arg0) throws StoreException {
		// TODO Auto-generated method stub
	}

	/**
	 * @param em the em to set
	 */
	public void setEntityManager(EntityManager em) {
		this.em = em;
	}
}

Afterwards, use JPAHibernateWorkflowStore instead of SpringHibernateWorkflowStore as your workflow store. You will also need to copy HibernateCurrentStep.hbm.xml, HibernateHistoryStep.hbm.xml and HibernateWorkflowEntry.hbm.xml (under com.opensymphony.workflow.spi.hibernate3) to META-INF (along with persistence.xml). This will ensure that hbm mappings are recognized by the EntityManager.

Well, that’s basically it. If you are having a hard time following my instructions, try getting the standard SpringHibernateWorkflowStore to work first. Afterwards, change implementation to JPA-based approach.

Ciao!



I created this basic DWR training and uploaded to Youtube. This video discuss about the basic setup of DWR and the sample is to perform an Ajax based validation.

Today, Jaycobb and I attended the Google Techtalk at AIM Conference Center. Like Jaycobb said, “it’s good to know that Google employees are human after all - and not androids”. Sure it was fun meeting Jay and Franklin, Google engineers from MountainView, but what catches my attention is that these 2 guys are Pinoys and they spent their “20% time” to fly here and share their Google experience - quite encouraging… this shows that Filipinos can really make it to world’s best. I hope they come back more often and share knowledge with us. I’m sure there are lots of local talents that are just waiting to be discovered - like us [ideyatech] and what we’re doing in the open-source area.

They talked about Google Gadgets, Summer of Codes, OpenSocial and Android, certainly lots of cool activities going on at Google. One insight I had from the talk is that “gadgets can be used to promote contents and to increase traffic”. Certainly worthwhile to do a couple of gadgets for our existing projects.

Here’s another picture taken during the chitchat after the seminar, from left: Franklin, Hans (syndeomedia), me and Jay.

BTW, thanks for Hans for pulling some strings to get us into the seminar.

We had fun at J2EE training today, JM talked about YUI, prototype, Script.aculo.us and Dojo. These javascript toolkits surely know their way around the javascript quirks that’s been perstering lots of developers with browser incompatibilities. I agree that these toolkits help a lot in making more stable javascript codes.

Some pictures taken from the training:

Some of our observations are:

  1. Lots of these toolkits do the same functionality (e.g. String utilities, Ajax calls, Animations). Is there any standard body that is defining the new sets of javascript features? So we all live in one common world of javascript coding? Or is it a battle of the best platform?
  2. Seems like we’re going back to the world of client-server days. As rich-interface becomes popular, will thin-clients begin to disappear? And what’s with Flex, Silverlight, JavaFX?
  3. When prototype popularized Object-Oriented approach, they made a good point about the power of Javascript… but still, the flexibility of javascript codes make it difficult to standardize. It’s more of a developer’s conscious effort to create cleaner code.

One neat thing I learned about prototype is that it has a method “Try.these{…}” where all the statements within will be evaluated until one actually works. Sounds useful when making your javascript methods work across multiple browser.

Today is the first day of our J2EE training. Everybody’s excited to become the first batch of the 3 months extensive training program. The training will cover open-source Java frameworks such as Spring, Struts, Hibernate, iBatis, etc. We will also cover newer technologies such as YUI, DWR. It’s going to be a tough but fun training for everyone. At the end of this training, we’ll get everyone at speed with the latest technologies on Java.

I’m happy that everyone in the team share the same passion on software development. With a little kick here and there, I’m sure we’ll get the core team in sync towards building creative software applications.

To give a preview of what’s up with Day 1, here’s a podcast on the introductory session. Unfortunatey, the audio isn’t good as I’ve placed the Macbook at the end of the room. I’ll try my Jabra tomorrow, see how that goes…

Although, the workstation didn’t arrive, the trainees were quite busy setting up the network. :)

When looking for a developer, would you consider the certifications he/she earned? Does the title MCSD, SCJP, SCEA matter? I’d like to say “no” because I’ve seen great programmers who are not certified and doesn’t value certifications. Moreover, I don’t want to discredit good programmers who doesn’t have this piece of paper.

But then again, why did I have to bother getting SCEA and PMP myself? Well, what really drives me is the “proof” that I am capable of passing the tests. These tests are developed, reviewed and improved by industry experts to measure individual skills and knowledge. I took the challenge because I believe I deserve that title.

While real world experience is good, you’ll only learn things that you do and you’ll never get the change to learn other things until you encounter it. When I took my certification, it is not like I just have to go to the testing center and pass it. It took me sometime to study, analyze and even memorize to prepare for a certification. This may not be something valuable at work, but it proves that I can understand the concepts well. More importantly, it shows that I’m disciplined and diligent to learn new things.

So does certification matter?

Yes. When choosing between 2 developers with same experience, I’d prefer someone who is certified. I’m also encouraging people to take their certifications.

Here’s a tip in Spring if you want certain URLs to redirect to specific JSP… For example:

http://www.ideyatech.com/magic/login.jspx -> acegi_login.jsp

http://www.ideyatech.com/magic/logout.jspx -> acegi_logout.jsp

Since Spring does not allow mapping directly to a jsp page. You need to create a controller to return the appropriate view. Alternatively, you can use URLFilenameViewController but then you’ll be limited to “prefix” and “postfix” append only. What if you wanted the mapping to be explicit as shown in example above?

My solution is to create a generic controller that will do the mapping. To do this, I’ve created a ViewMapController which behaves in almost exact the same manner with URLFilenameViewController except that mapping is explicitly specified with the filename.

In the example below, I’ve mapped /login.jspx to /jsp/acegi-login.jsp and /denied.jspx to /jsp/access-denied.jsp
STEP 1: Declare your mapping with SimpleUrlHandlerMapping

SimpleURLHandlerMapping

STEP 2: Declare your viewMapController with the view mapping. Declare your viewMapController with the view mapping.

SimpleURLHandlerMapping

STEP 3: Create the class ViewMapController.

public class ViewMapController extends AbstractController {
private Map viewMap;
private String defaultView;

@Override
protected ModelAndView handleRequestInternal(HttpServletRequest request,
HttpServletResponse response) throws Exception {
String uri = request.getRequestURI();
String key;
String viewName;

int idx = uri.lastIndexOf(”/”);
if (idx > 0)
key = uri.substring(idx+1);
else
key = uri;
if (viewMap.containsKey(key))
viewName = viewMap.get(key);
else
viewName = defaultView;
return new ModelAndView(viewName);
}

public void setViewMap(Map viewMap) {
this.viewMap = viewMap;
}

public void setDefaultView(String defaultView) {
this.defaultView = defaultView;
}
}

Note: the view will be resolved using your viewResolver. In this case, in order to resolve acegi-login to \jsp\acegi-login.jsp, I’ve declared the viewResolver as:

viewResolver

That’s all folks. You now have a more flexible way to map URLs directly to your JSP pages.