For the past two months, we have been having our weekly T3 (Tuesday Tech Talk) sessions. It’s a 30-minute discussion about any technical topic the presenter would like to discuss. Presenters are randomly selected from the development group.

So far, we have received nothing but benefits from this activity. Here are some of its benefits and advantages:

1. The presenters get an opportunity to talk, express themselves and practice their presentation skills. More importantly, they steer away from the developer mindset for a while, get out of their shells, and think of good topics to discuss.
2. The attendees learn something new. Everybody seems to know something others don’t.
3. Everyone begins to understand the specialization and span of knowledge of their colleagues. In this way, it becomes easier to know who to ask regarding particular topics. Subsequently, the developers become experts and specialists in their own way.
4. This builds camaraderie within the team. Everyone relaxes and opens up their minds for new knowledge.
5. The topics discussed are usually not something we do or use in our daily routine at work. So, everyone gets to learn more than the usual stuff.
6. Everyone realizes the things that they do not know and starts to seek for more information about it.
7. The organization strengthens its corporate IQ as people share their ideas and knowledge with each other.
8. After a couple of sessions, everyone began appreciating the activity and now looks forward for new things to learn.

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.

In my recent project, I’ve evaluated several Ajax Frameworks to support my web 2.0 Java based application. There are a number of framework that supports Ajax functions and most of which are independent of the back-end programming language. But then, there are Java-based Ajax frameworks such as DWR that provides direct Ajax support in Java.

Anyway, here is a run-down of some generic Ajax toolset I’ve evaluated along with some of my personal comments:

• Dojo (http://dojotoolkit.org/) - Probably the most comprehensive Javascript toolset available. Dojo supports A LOT of functionalities ranging from fading animations to offline storage. Dojo has a good demo site that I find very useful especially when learning the functionalities. The demo site is directly associated to source code so you can immediately see the implementation details. I personally find the js validation useful and the fish-eye navigation is cool, too… Just be careful with the debug console as it breaks the page. I never use it, use FireBug instead.
• YUI (http://developer.yahoo.com/yui/) - Yahoo provides a quite stable set of Javascript utilities too. YUI seems to be a well-thought toolset as it presents only a limited set of functionalities that you can mix and match to create more complex functions. Naturally, this presents more programming work upfront and steeper learning curve. If you wanted more control on your scripts, YUI might be good for you.
• Script.aculo.us (http://script.aculo.us/) - Probably the most popular javascript toolset out there. The only thing I find complex here is the URL - a bit hard to type (where do I put the dots). This toolset is based on prototype which is the base javascript library used on Ruby on Rails. I personally prefer this over YUI as I find this easier to use.

I ended up using Dojo for my project for 2 reasons… more comprehensive functionality - meaning I don’t have to mix it with other tools or libraries. I am using FishEye Navigation.

Ciao!

<!– .style1 { font-family: “Courier New”, Courier, monospace; font-weight: bold; color: #0033CC; font-size: small; } .style3 {color: #0033CC; font-size: small; font-family: “Courier New”, Courier, monospace;} –>

After hearing all the buzz about Ajax, I decided to integrate my existing Struts application with Ajax. So, I surfed around looking for some good Ajax tools. Initially, I was looking at Prototype as it seems to be the most dominant Ajax platform. Then, I found Rico. Rico is an open-source JavaScript library for creating rich internet applications. This toolset contains a ton of great user-driven functionalities such as Ajax, drag-and-drop, cinematic effects, and many more.

Now I have to study Rico and learn how it can be integrated with my existing Struts application. The process for integrating with Rico is a bit tricky - the documentation lacking information. They only provide code snippets which will not work as it is. To get around with this, I extracted the actual codes from the demo and analyze the flow. It took a while to understand the flow because the codes contain other features that are not needed for the desired functionality. Anyway, I tried out the sample codes into an HTML. Once I got this working, I attached it to the jsp files. It didn’t take a long time to get it working in JSP since I had it previously working in HTML.

Tip #1: Always start with a working prototype in HTML.

In traditional Struts framework, after an action method perform its operation, it forwards to the next JSP to be displayed.

With an Ajax driven framework, the Struts action method forwards to a message.jsp instead. This jsp file displays the message to the user by updating a specific div section in the original page.

Let’s dissect the code a little more here, below are the steps to convert an existing Stuts application.

1.) Include prototype and rico javascript files in the jsp file.
2.) Register the action class and div component.
ajaxEngine.registerRequest( ‘add’, ” );
ajaxEngine.registerAjaxElement(’responseArea’);
3.) Put a div to display the message.

Tip#2: When debugging, you can always use the onSuccess, onTimeOut or onError methods in the Ajax call. (shown in the example above)

One problem I encountered was that the jsp response is not updating the specified div. This is because the response is populated to responseText instead of responseXML. To solve this, the jsp must be forced to return an XML content.

Tip #3: Response should be in XML form, put <%@page contentType=”text/xml”%> in your jsp.

Well, this is what I have so far. I’ll be posting other tips as I explore on this more…

At ideyatech, we have recently integrated an application with Google Maps to graphically display key locations. The process is quite simple. Google made Javascript APIs that can be easily integrated with existing codes. Amazingly, this nifty feature can be implemented with less than 15 lines of code.

The first step is to sign up for the API key. This generates a key string that will be included in your script to serve as your identity. Afterwards, update your page to include the necessary javascripts. This is generally an easy task for intermediate programmers. I’d rather not explain the code as Google made reasonable efforts to document the API. It took me about 15 mins to get the sample code running, a few hours to customize the page and integrate with our database. Viola!

One issue was upon us though, Google maps require latitude and longitude information about the locations. Our database contain only address information. What we need is a geo-coding functionality that can translate a physical address into long/lat. There are some open-source projects for geo-coding, but the best we have tested is Yahoo Maps. How ironic, we’re using Yahoo Maps for geo-coding which will be fed to Google maps for viewing.

The process of using Yahoo Maps API is quite simple too. First step is to sign-up for an application ID. Then construct a REST command to issue the query. The syntax is well documented, too. So, the solution is to provide a lat/long “lookup” button within your data entry screen. For usability, we applied Ajax codes to perform the on-the-fly lookup. Due to some security issues with the browser connecting directly to yahoo maps URL, we ended up calling our server which in turn makes the request to Yahoo URL. Here is the js script that makes the call and here is Java code snippet that process the request.

Now, the solution is complete. We have Google maps to display the graphical maps based on lat/long stored in the database and Yahoo geo-coding to translate a physical address to lat/long. This is what I call Web 2.0 integration.