dambalah

Finally, my notes on the third day of Ajax World East 2008 in New York City.

Opening Keynote: RIA Adoption in 2008

Anthony Franco from effectiveui started the day with a very engaging keynote. He was easily the best speaker of the conference: great delivery, engaging, interesting…

I liked the way he described his company: “we make cool useful stuff for companies who pay us”. They are the ones behind the famous eBay desktop client which has gotten so much press and is always referred to as a good example of a Rich Internet Application (RIA) built on Adobe AIR.

He started by questioning the value of RIAs and the tunnel vision of the developer community, with the following statements:

• The Value of RIAs: Why would my mom care?
• You are talented web designers: my mom is not impressed.

Why should you care about his mom? Well, she could spending thousands online but nobody takes the time to talk to her.

He used Starbucks and Target as two examples of companies that manage to create great in-store user experiences but failed to re-create that same user-experience quality online. On the other hand, he used 37Signals as an example of a company that is seen as the gold standard of the Web 2.0 era and pointed that one of the reasons they are so succesful is because they own their product. They dictate the how, the where, the why. They are the audience since they use their own products. However, a lot of us are not the audience for the stuff we build. A development firm cannot dictate to a car insurance company how their customers must be buying car insurance because they have to worry about issues such as compliance, etc…

Anthony believes that Web 2.0 should be about Utility + Community + Engaging Experiences. However, he doesn’t believe we have achieved that very well. He used a quote from Chris Bernard to illustrate what he believes is happening currently in Web 2.0: “Web 1.0 = Bad Photoshop, Web 2.0 = Good Photoshop”. Anthony’s address was like a wake-up call to the IT & Web communities: “We are not talking to the audience, not talking to our customers. Shame on us.”

He then went on to address every player in that community and tell them that they are responsible for this. We all are. “It is your responsibility. Stop pointing the finger”:

• Designers:Lose the ego and listen to your customers
• Developers:You are not the smartest person in the room. Drop the religion and listen to your customers. Putting it in front of users even if the code is ugly means you will get more user feedback early.
• Product Managers:Stop Talking and Start Doing. Most great products are figured out along the way.
• Marketers: Scream Louder! your customers are counting on you to be their voice.
• CIOs and CTOs:The Technology does not matter to your customers. If they can’t use the applications you build.
• Customer Support:Don’t worry, your job is secure for a while.
• CFOs: Find the money
• CEOs: Watch your back. Give your team the latitude to fail in incremental ways. As long as they are failing in the right direction, you are doing the right job.

For each category of players, he used quotes that he has heard in the field that reflects the problem with this folks:

• Designer: “Good design intuition is more important than user interviews”
• Developer: “Flash is bad”, “Microsoft sucks”
• Marketers: “I don’t want to have to argue with my IT deparment”
• CIOs and CTOs: “We do not have the internal skills to build and maintain that”
• Customer Support: “Our site is a Frankeinstein”
• CEO: “We need to keep pace with our competitors”

He pointed out that 500 Large enterprises were asked in a recent survey: Are RIAs more important for you in 2008? Nearly 70% answered yes.

Wow! That was a great presentation. It was engaging. He made 30 minutes fly by like it was 5 minutes. He urged the audience to challenge him on his blog, so go join the discussion if you are interested.

Session 2: The Social Aggregator - Widgets Reshape the Social Web

I was surprised to see that Justin Thorp was the speaker since he wasn’t the listed speaker. Justin is someone I consider to be a leader of the DC Web community, for his involvment in putting together barcampDC and the Ning DC Technology Network. I had met him during Startup Weekend in DC so it was good to see a fellow DCist was there.

Justing started with a brief description of where the web has been, where we are now, and where he believes it will go. Back in the day, we had big portals such as Yahoo that were editor driven. It was costly to put together a site so only professionals did it. In a way, browsing the web was like reading a newspaper or magazine, where an editor selected what you should read about.

With Web 2.0, we have better publishing tools, offline apps are going online, more storage has helped user-generated content, websites are more community oriented, etc… At the end of the day, it’s really not about your web site. It’s about your content and functionality. How is your application going to bring pleasure to users?

He then went on to describe web widgets and how the ClearSpring platform can help you deploy a widget. The big problem with widgets is that there are no standards yet, so if you want to develop a widget, you will have to code one for iGoogle, one for NetVibes, one for Hi5, etc… The social aggregator market is fragmented and that makes widget development more difficult. With the Clearspring platform, you only have to write the widget once, embed it in a ClearSpring container, and deploy it on a long list of sites.

Justin used an interesting metaphor between a website being your movie theatre and widgets being DVDs. You can carry them everywhere you go. They adapt to your situation and therefore makes your product more suitable to the user’s lifestyle.

Why should a company build widgets?

• extend
• promote
• express
• share
• innovate

Some stats: 81% of all web users saw a widget in nov. 2007–> 148 million people

Someone from the audience made an interesting comment. She asked what happens to the person that brings in value by putting together a set of widgets on a page like iGoogle and sharing it. In a way, that person is a “Widget DJ”. How can that person be rewarded for this work? Should he/she be rewarded for doing it?

Session 3: Now Playing: Desktop Apps in the Browser!

This presentation was a sales pitch for nexaweb. They made it very interesting to listen to by role-playing. Coach Wei played the role of the CIO of a company that is defining their IT strategy while Bob Buffone was his chief architect, trying to go through the whole pletoria of tools, frameworks, languages to find the best solution. Bob finally arrived at the conclusion that NexaWeb made it so much easier to do plenty of things while keeping a consistent development environment. Their development environment seems compelling and I’m sure they will sell some products after this presentation since the audience seemed to enjoy it.

Session 4: DreamFace: The ultimate Framework for creating Personalized Web 2.0 Mashups

Olivier Poupeney, CEO of DreamFace Interactive, gave us a demo of his company’s product. DreamFace is a very cool application. My best description would be: a highly-configurable iGoogle on steroid for the enterprise with the ability to create your own workflows and enable widget interactions. An example of widget interaction (which you can’t currently do on iGoogle) that he demoed is clicking on a note widget automatically launches a YouTube search for the keyword in that note. Very cool stuff.

The interesting part is that during the widget session earlier, we briefly discussed the idea of using a widget aggregation portal as the main intranet portal for a company… and in the next session, Olivier demoed DreamFace, which is just that (and more).

Session 5: Digital Black Belt’s Gide to ASP.NET AJAX Security

Joe Stagner from Microsoft was the speaker for this great presentation on Ajax security. Even though the title pointed to ASP.NET but the talk could be applied to any other platform.

Joe does not agree with Douglas Crockford theme on yesterday’s keynote. He doesn’t think that the web is broken. He believes that JavaScript and AJAX is a fine set of tool, but that developers are the ones to blame for not being more careful about AJAX Security.

Joe started his talk with the main points that we should get out of his presentation:

• “To catch a bad guy, you have to start to think like a bad guy”
• Consider ALL input evil until proven otherwise
• Accept the power of JavaScript an HTML
• Understand the combinatorial attack
• completely buy into “Defense in Depth”

Security is crucial because in today’s web, we are not only defending our infrastructure (servers, databases) but also our customers. If our web application gets hacked, our customers gets hurt also.

Joe showed us a few tool that he uses that can help us in the quest to “think like a bad guy”: fiddler, webscarab, ViewStateDecoder, his own Password Cracker, etc… I’ve used fiddler before and it helps a lot when doing web development. Every developer should used a similar tool to monitor HTTP traffic. At work, I used HTTPWatch in IE and FireBug in Firefox. I highly recommend downloading both. HTTPWatch is not free but if you can afford a license, it’s definitely worth it. Joe was using IE8 and it ships with a DOM Browser and a debugger. That’s awesome! Debugging on IE was more difficult because they lacked a good alternative to FireBug, but it will now be included in the main distribution.

Here are few tips from Joe’s talk:

• If you are taking user input and adding it to the page, use Server.HTMLEncode (if you use .NET) on the server side to ensure your get rid of malicious input
• When you filter evil code, always use a white list, not a black list
• When you detect that a user was trying to launch an SQL Injection, record that user ID and IP Address
• There is no such thing as security through obscurity. However, it doesn’t hurt to make it more difficult for the bad guy. For example, give your password db column another name
• Just because you hash your password doesn’t mean a hacker who obtains the hash version can’t recover the password from it. With a brute force attach or a dictionary attack it can be trivial to obtain the password. Joe wrote a tool that does just that and promised to post the code for the tool on his blog.
• Book Recommendation: “Ajax Security” by Billy Hoffman
• To avoid SQL Injection attacks, use stored procedures or parametrized queries (all devs should know this by now, right?)

Joe also showed us a few attacks that are common. Some of them a quite clever:

• To embed a script on a page, crackers use “<script<script>>” instead of “<script”>. This way, if you are using a black list and replace “<script>” with “”, the resulting string is “<script>”.
• He showed us how damaging SQL injections can be
• A cracker can add an image to a web page with a height of 1px and a width of 100% with onMouseOver event caller, this way the user does not even see the image but keeps launching the events as his mouse goes over the image
• Evil javascript inserted on the page can read data from a user’s clipboard. Think about all the time people copy and paste their passwords!
• Javascript key loggers that sends all the keys you touch to a malicious server. Sometimes the cracker opens a new browser window which he places outside of the viewable screen area, so even if you close your browser, this new instance of the browser stays open and you don’t see it
• With javascript, a user can get your browser history by comparing the color of your links with a list of known urls. Pretty simple code to write but imagine how vulnerable you are if a cracker knows what websites you visit. He can now launch a phishing attack on you since he knows what emails you are likely to open

All this stuff is scary because as a big web user, I visit a lot of sites everyday and I don’t know if any of them have been attacked. Joe got me paranoid. I think I might start to leave fiddler running at all times on my machine so I can be sure no one is collecting info from my PC.

Session 6: Data And Syndicated Oriented Architecture

This talk was by Kurt Cagle from Burton Group. Kurt is a managing editor for xml.com.

This session was like attending a philosophy class where the topic of the day was XML and REST :-). A lot of acronyms and buzz words were thrown at us. The speaker obviously knows a whole lot about the subject but I feel like he could have made the talk more accessible and engaging.

In essence, Kurt talked about the emergence of REST. To quote him, “REST is XML++. It’s where XML is going”. If you have never heard of REST, I urge you to learn more about it as it will play a bigger role on the web in the near future.

Session 7: Using the DOJO toolkit to create AJAX powered forms

James Harmon from Object Training Group showed us how we can make HTML forms more user-friendly using the Dojo toolkit. It was a very focused talk. He didn’t cover too much but covered it slowly and in depth. It was a good introduction for people, like me, who have never used Dojo.

Dojo makes it really easy to create great HTML forms with validations, cool tool tips, better elements/widgets. They recently passed the 1.0 mark and the framework is quite stable now. Dojo has a partnership with AOL CDN so you can point your javascript include statement to the AOL CDN servers and leverage that infrastructure. Dojo is server-side agnostic but James think that Dojo is a good fit for Java shops.

James spent most of the presentation showing us code and demo-ing the form he enhanced with Dojo. You can download the powerpoint slides of his presentation here, as well as the source code.

Session 8: Open-Source AJAX Test Automation

Frank Cohen of PushToTest was the speaker for the last talk of the day. His talk was focused on the importance of testing and how one can automate AJAX testing.

Quote: “Testers don’t get all the cool tools that developers get.”

3 Steps for testing AJAX Apps:

1. Observe: understand what the business flows are that are occuring within an application, what protocols/data are being used.
2. Test:
   • a. Load Testing: do I have enough hardware? At what point will my system fail?
   • b. Functional Testing: combination of regression testing (it used to work and now it doesn’t) and integration testing (are all components working together correctly)
   • c. Monitoring
3. Correlate what is happening on the front end with what’s happening on the back-end.

We need to automate this process. It’s important to have a Quality Engineering Process (QEP). It’s no longer possible for companies that are using Ajax to do manual testing and expect to achieve certain level of SLA. You can’t achieve a QEP without developers, testers, and IT working together.

Frank then went on to introduce his Test Automation Platform.

Client Side:

• JavaScript Logging
• Firebug
• XPather
• DOM Inspector
• Selenium IDE

Server-Side:

• Glassbox
• PushToTest TestMaker
• PushToTest TestNode
• PushToTest Monitor (pttmonitor)

Summary

Another great day at AjaxWorld. Overall, it was a good conference. I really enjoyed the sessions and learned a lot. Now I have a lot of homework to do to try to learn more about all these cool technologies.

The conference was a a few weeks back and I never had a chance to post my review/notes on day 2 and 3 of the conference. I finally got to clean-up my notes so here they are. Better late than never!

Opening Keynote: Can we fix the Web?

Douglas Crockford was the opening keynote today. He is the creator of JSON. If you’ve never heard of him and you do AJAX development, I urge you to visit his site. In my opinion, it’s one of the best JavaScript resource on the Internet. In many ways, Douglas has made my life as a developer easier, in particular with JSON and JSMin. For these reasons, I was excited about his keynote and he did not dissapoint me.

Douglas believes that the number one problem of the web is security:

• an attacker that is able to run scripts on your page can request more scripts
• an attacker can make requests to your server
• an attacker can read the document and obtain sensitive information
• an attacker has control of the display so they can request more info from the user
• an attacker can send data anywhere in the world

Web applications are built using a set of languages such as JavaScript, HTML, CSS, etc.. This makes it more difficult to enforce security because text that is benign on one langague can be dangerous on another one.

The web standards require these vulnerabilities to be present. What are the causes of insecurity?

1. Javascript
   • All code run with the same authority
   • JavaScript is an insecure language and the ECMAScript4 proposal is even worse.
2. DOM
   • All nodes are linked to all other nodes on the network.
3. Cookies
   • Ambient authority leads to confusion and impersonation

Quote: “If there is a script from 2 or more sources, the application is not secure. Period.” This means that mashups are insecure by nature. The big problem is that advertising, the bread and butter of the web, is a mashup.

After showing the audience why the web is broken and insecure. Douglas started answering the question set in the title of his presentation: How can we fix the web? His strategy for fixing the web revolves around three points:

1. Safe JavaScript subsets
   • ADSafe defines a safe HTML/JavaScript subset. From their website:
     

     ADsafe makes it safe to put guest code (such as third party scripted advertising or widgets) on any web page. ADsafe defines a subset of JavaScript that is powerful enough to allow guest code to perform valuable interactions, while at the same time preventing malicious or accidental damage or intrusion. The ADsafe subset can be verified mechanically by tools like JSLint so that no human inspection is necessary to review guest code for safety. The ADsafe subset also enforces good coding practices, increasing the likelihood that guest code will run correctly.

     The ADsafe subset blocks a script from accessing any global variables or from directly accessing the Document Object Model or any of its elements. Instead, ADsafe gives the script access to an ADSAFE object that is provided by the page’s server, giving indirect access to the guest code’s DOM elements and other page services.

   • Google’s Caja is also a safe JavaScript subset, but use transformation rather than validation. Using Caja, web apps can safely allow third-party scripts on their pages.
2. Small browser improvements
   • JSONRequest should be built into the browsers for safe data interchange .
   • HTML provides no modules
3. Massive browser improvements: we need to replace JavaScript and the DOM. We could start with a subset of JavaScript such as ADSafe and add useful and secure features.

Douglas concluded by saying that if we don’t fix the web, the competition (SilverLight, Flash, JavaFX) will displace it. They are all superior technologies.

For more coverage of Crockford’s Keynote address, check out these articles: 1, 2

Session 2: Accelerate AJAX development with Appcelerator

Jeff Haynie from appcelerator started his talk with a long history of web development. In my opinion, I think he spent too long on this portion of his talk and I felt like he lost the audience after a while. We were all waiting for the punch-line but it took too long to come.

Jeff gave us a brief overview of appcelerator’s platform. Appcelerator is an open source software company that develops products and services for rapid rich Internet application (RIA) development on a service-oriented architecture (SOA). You can find out more about their product on their website at www.appcelerator.com or you can join their developer community at www.appcelerator.org.

Session 3: Introduction to YUI

Eric Miraglia from Yahoo gave us a great introduction to the YUI Library.

The main components of YUI are:

• YUI Core JavaScript
• YUI JavaScript Utilities
• YUI Controls/Widgets
• YII CSS Core
• YUI Tools
• YUI Theater

YUI Core javascript is very similar to Prototype or JQuery. It is broken down into three parts:

• The YAHOO Global Object: It provides a single global namespace within which all YUI Library code resides and must be included everywhere you use the YUI Library. It provides a set of functions that is used throughout the library.
• The Dom Collection comprises a family of convenience methods that simplify common DOM-scripting tasks, including element positioning and CSS style management, while normalizing for cross-browser inconsistencies. With the DOM Collection, you can:
  • Position elements on the page
  • Manipulate styles: add and remove styles
  • Change viewport size
  • Add and remove clasnames
• The YUI Event Utility facilitates the creation of event-driven applications in the browser by giving you a simplified interface for subscribing to DOM events and for examining properties of the browser’s Event object.

The YUI Core Javascript is only 31K Minified.

The YUI Javascript Utilities contains a set of libraries for animation (You can animate everything in the styles that have a value. That’s awesome!), browser history management (to deal with back button), connection management (for doing AJAX), cookies manipulation, JSON, etc… YUI uses a modular design. You only need to load what you need.

YUI Controls/Widgets is a set of controls or widgets that one can use on a web page. It includes controls for calendars, charts, color picker, Slider, etc… YUI contains one of the best collections of controls among JavaScript frameworks.

The YUI library also provides a set of CSS tools. It is less than 7K of CSS when you pack all of the files together. It it composed of four elements:

• Reset CSS: Neutralize differences in the browsers’ default stylesheets and provides a normalized fuoundation on which to build. Takes away all of the default presentation from the different browser implementations.
• Base CSS: provides baseline browser-neutral styling treatments for common HTML.
• Fonts CSS: foundation for typography and font-sizing.
• Grids CSS: for page layout. This is similar to the Blueprint CSS framework.

While the competition between JavaScript frameworks is intense, YUI has a lot to offer:

• Great documentation
• Yahoo will host the YUI files for you, on their CDN.
• Dedicated team working on YUI full time. Used by more than 400+ million users.
• One of the most comprehensive suite of controls/widgets
• CSS libraries to go with the JavaScrit libraries
• YUI Theater
• A great set of tools such a profiler, a Javascript Compressor, a testing framework…

Though I’ve never used the YUI library, it looks great and I would definitely consider using it on my next project.

Session 4: Enterprise Comet: Real-Time, or Real-Time Web 2.0?

Jonas Jacobi, co-founder of Kaazing, started by defining the term “real-time”. His web search brought up the following definitions of real-time:

• A system that responds to an external event within a short and predictable time frame
• …so rapidly that the interaction appears instantaneous
• An activity which occurs “while you wait”, rather than being delayd for processing at a later time.

He then proceeded to define the ‘real-time web’ and came up with the following:

• Web Clients instanteneously updated
• End-users receive updates simultaneously.

Finally, he came to the conclusion that what matters is when you notify the user.

Comet is a technique to establish a permanent connection from server to client over HTTP. Comet allows you to send messages from server to client. It’s a pushing mechanism, rather than the traditional pulling mechanism that we are used to on the web. It is client agnostic. It supports browser clients or desktop applications.

HTTP 1.1 uses 2 connections per domain. So if you tie one connection to Comet, then there is only one connection left for your application to work with. The solution is to use sub-domains to work around this limitation. This sub-domain technique is recommended by Steve Souders in “High Performance Web Sites” and Rails 2.0 makes it very easy to configure.

Some Comet use-cases:

• External Data Model Changes
  • Web stock ticker
  • Web chat and mail - new messages received
  • Web online games - multi-player poker
• Shared Data Model Changes: issue tracker updates
• Sports - a goal is scored

Jonas then went on to discuss scability issues with Comet. In particular, how do you send all these messages at the same time? The problem is that the server must copy messages across multiple-connections, possibly thousands.

Comet seems like an interesting technology and I look forward to see what will happen in that space.

Session 5: jMaki Webtop: an AJAX Mashup Framework

Arun Gupta who presented the day before on jMaki used this session to introduce us to the jMaki Webtop. He started with a short introduction of jMaki for those who did not attend his longer presentation on the subject the day before. Then, he proceeded to explain what jMaki Webtop is and showed us a demo.

jMaki webtop is a Mashup Framework that is:

• Simple and easy to use
• Runs in browser
• Evolution
• Extensible
• Manageable
• Persistent: with Google Gears
• Shared

In a few words, it’s kinda like a configurable iGoogle page. You can play with the demo that he showed us here.

Arun posted his slides on his blog, along with great reports of day 1 and day 2 of Ajax World.

Session 6: Real-World Enterprise Rails and AJAX: Top 10 lessons learned

Rode Cope is the CTO and Founder of OpenLogic, Inc. He used Rails to build osscensus.org, a global community effort to catalog the use of open-source software.

Rode Cope went through the 10 lessons that he learned while developing an enterprise Rails application with AJAX.

1) Use AJAX, but make it seamless

Good uses:

• Table Sorting
• Ordering rows in lists
• Data filtering: checkboxes, radio-button, dropdowns…
• Dynamic data loading: populate dropdowns, templates, flash-based graph data loading
• Modal dialog: “Don’t show this again”, Load content, update cookie via AJAX
• Adding elements to the page
• Edit in place

2) Don’t use AJAX if you don’t need it.

• Don’t shock the user
• AJAX is just another tool
• No drag and drop just because it’s cool
• Use client-side javascript when it makes sense: avoid server roundtrips if they don’t add value

3) Use just enough tools

• Don’t need a giant framework
• Firebug is your best friend with YSlow
• Tail the development log

4) Use Open Source

• Prototype,scriptaculous, jQuery
• Live Validation (for client side validation)
• TinyMCE
• Watir, FireWatir, Selenium
• Netbeans, Radrails

5) Don’t be afraid of JavaScript

• View Helpers: wrap AjaxRequest fo convenience, link_to_remote
• RJS
• Don’t be afraid of writing JavaScript by hand: avoid roundtrips to server

6) Watch out for JavaScript Conflicts

• run jQuery in no-conflict mode
• Live Validation wants to take over onSubmit, making it hard to implement your own custom submission logic
• Javascript Libraries are still Wild Wild West

7) Client-side validation is hard, but worth it

• Show/hide/populate fields dynamically
• Count characters remaining
• Default values in certain fields
• Live validation works well with Rails by supporting ActiveRecord validations

8 ) Cross-browser issues: not too bad

• Tooltips: some browsers truncate tooltips, some wrap them. Use library, custom javascript, or AJAX to enforce consistency
• CSS: may need special browser checks if you really care about width details, margin and padding defined differently in IE and FF

9) Security must be implemented in all layers

• Never ever trust any input: URL’s, hidden fields, form values, cookies, POST data, etc..
• No soft, chewy center: client-side validation is only there for user convenience, not for security.
• Check all roles in your controllers
• Implement all data security in your models
• View helpers simplify things: button_display_for_downloads(user)
• Consider promoting helpers to application level

10) Testing is crucial

• Typical Rails testing (unit,functional,integration) is not enough.
• AJAX tests: sleep then check for CSS class change
• Test events and scripts interations since libraries don’t always play nice
• Watir,FireWatir,Selenium: run tests in actual browser (IE/FF). Downside: not easy to integrate with Continuous Integration system
• Interactive testing with irb and FireWatir:

- Run tests interactively ot make sure XPath is correct
- Huge improvement in code-test-debug cycle

• Unit Testing javascript: jsUnit, jsTest

Session 7: Spice up User Experience with Silverlight RIA

Sue Googe is a big fan of Silverlight. She spent her 50 minutes praising the benefits of SilverLight and trying to convince the audience that we should all be using Silverlight. So much that I thought she worked for Microsoft

Why Silverlight?

• very rich UI framework built-in
• provide AJAX++ experience with little code
• deliver super quality media on the web
• Cross-browser / cross-platform
• Rapid development
• It’s free and open-souce
• Flash learning curve is high
• Has own media streaming, up to 720p

Sue showed a cool demo of the Silverlight Deep Zoom feature. She posted her slides on her blog.

Session 8: AJAX and Social Computing for the Enterprise

I’m still trying to find out whether I attended this session or not. I must be getting old

Session 9: Seam Remoting

Shane Bryzak’s talk was about Seam Remoting, which is an AJAX framework for JBoss Seam. I wasn’t planning to attend this talk at first but the OpenAjax Gadgets & Widgets talk was full by the time I got there. Since I heard good things about Seam in the past, I figured it wouldn’t hurt to learn what it is all about.

JBoss Seam is an Enterprise Java Framework:

• Provides a rich, contextual component model
• Simplified integration with various useful technologies such as BPM, drools, security, GWT, etc…
• Runs in many different environments: JBoss, Weblogic, Websphere, Tomcat
• Standards based, submitted as JSR-299 (Web Beans)
• Supports biection (inversion of control) for wiring components
• Seam components can be session beans, entity beans or POJOs
• JBOSS Tool plugin for Eclipse

How does it work?

Seam lets you make calls in JavaScript as if the class was defined in JavaScript. In your JavaScript, you will never make explicit ajax calls, you simply make a call to a function such as getStatus, as if you were on the server. Seam Remoting takes care of the plumbing and sends the request. The messages are sent using XML.

To define the Java classes and functions that you want accessible remotely, you simply have to annotate the calss with @Name(’nameofclass’) and annotate the functions that you want accessible remotely with @WebRemote.

Communication Protocol:

• is an XML-based protocol
• Loosely inspired by XML-RPC
• Supports object graph recursion
• Allows requests to be batched so you can queue up a number of requests and send them all at once.
• Support all the usual data types

Seam makes working with JMS easy. Shane went on to demo a Chat Room application using Seam with JMS. I was quite impressed. I like Seam’s approach to Ajax and I would be curious to know if there are other frameworks doing something similar.

Shane’s slide were really good and you do not need to be at the talk to benefit from them. Shane was nice enough to email me his slides and authorized me to post them here. You can download them here.

SYS-CON.TV Power Panel: The Business Value of RIAs

The day concluded with a panel of CTOs talking about who their biggest clients are, what kind of RIA applications they are building, what they believe to be the future of RIA, and other topics related to the business value of RIAs.

Summary

In summary, the second day of the conference was very good. My favorite talks were Douglas Crockford’s opening keynote, the introduction to YUI, the real-world Rails talk, and the presentation on Seam Remoting.

Technologies that I plan to learn a bit more about after this day are: SilverLight, YUI, Seam Framework, Watir, FireWatir, and jMaki.

I’m in New York City attending the Ajax World conference. It feels so great to be in New York. I love coming here.

Today was the first day of the conference and it only lasted half a day, with four 45 minutes sessions. There are a total of 6 tracks so there were a 24 sessions to choose from today. It’s not easy to make a selection since many of them sound very interesting. Nevertheless, I picked my sessions carefully and really enjoyed the ones I attended.

Session 1: Picking the Right Technology for Enterprise Rich Internet Applications

The first talk that I attended was from Yakov Fain, entitled “Picking the Right Technology for Enterprise Rich Internet Applications (RIA)”. Yakov’s talk was a survey of the top technologies to build RIAs. The main contenders in this area are:

• Ajax
• Microsoft Silverlight
• Adobe Flex/Flash
• Sun’s JavaFX

Yakov started by identifying the qualities that an RIA technology should share to be successful:

• seamless deployment on the client
• high penetration rate of the runtime environment
• web browser independence
• fast client-server communication protocols
• robust security

I found it rather ironic that during the first five minutes of the first session I am attending at Ajax World, the speaker said “Ajax is no good.” What Yakov meant when he said that Ajax is no good is that it is difficult to build Ajax applications due to cross-browser compatibilities. Javascript developers have to spend a lot of time writing code to deal with these issues (or use a framework such as Prototype or jQuery). Ajax’s communication protocol (HTTP) is also not the most efficient.

On the other hand, Silverlight/Flex/JavaFX all run in a Virtual Machine (VM) so the environment will be the same wherever the code is deployed, which makes it easier for the developers. Yakov believes that this is where the future lies: to have a small VM deployed on the client. The availability of the runtime is crucial for user adoption and this is why Adobe has the edge currently since Flash Player 9 is installed on more than 90% of PCs in the world.

The current trend is to have a declarative GUI programming language backed by another language, such as the following combinations: MXML/ActionScript, JavaFX/Java, XAML/C#. Yakov believes that Flex is the better technology today, that Microsoft will catch up next year with Silverlight and that Sun still has some work to do before JavaFX becomes stable and competitive.

There is an interesting competition between Microsoft and Adobe. Adobe already has a crowd of loyal designers that are used to their product and they are trying to get the developers to join them. On the other hand, Microsoft has a stable base of developers as customers, and needs to get designers to buy their products. They’ve released Microsoft Expression with that in mind.

Here is a rundown of the characteristics, pros and cons of each technology, as discussed by the speaker.

Ajax:

• Pros:
  • No deployment
  • 100+ frameworks
  • Free, open-source
• Cons:
  • Web browser dependency
  • 100+ frameworks (how do you choose one?)
  • Expensive and long development life cycle

JavaFX:

• Script and mobile
• uses Java Swing 2D APIs
• plugins for Netbeans and Eclipse exists
• Java 6 Update N will be released soon. It is a small VM to deploy in the browser.

Silverlight:

• Pros:
  • supports up to 720p-HD video through the web browser
  • Silverlight 2.0 runtime is 4.3 MB: fast installation
• Cons:
  • no protocols faster than HTTP

Adobe Flex:

• MXML: an XML-based declarative programming language for creating GUIs
• ActionScript 3.0: object oriented language similar to Java
• Flash Player 9: VM that runs swf files
• WebOrb: lets you serialize C# objects to send to Flex UI (so one can use Flex with .NET).

Yakov demonstrated a couple of RIAs that he developped with Flex and they were very impressive, particularly a financial analysis application.

Session 2: Performance tuning Ajax applications

Bob Buffone presented on improving the performance of your Ajax applications. The first half of his talk was very familiar to me, having read ‘High Performance Websites’ from Steve Souders. I highly recommend reading it if you are building web applications. Bob went over a few of the 14 rules for performance improvements mentioned in the book, in particular:

• Tips to reduce the number of HTTP requests
• Tips to reduce the size of HTTP responses (JS and CSS files)
  • minification with tools such as YUI ycompressor, dojo toolkit, jsmin, etc…
  • gzip can drastically reduce the file size.
  • coding style: he advocates changing the coding standards when writing Javascript to produce smaller files. For example, write single line if/for statements without {} since they are optional.

After that, Bob went on to cover lower-level optimizations in Javascript:

• DOM Parsing: do not write your own parser. Use the native parsers and use JSON over XML if you can because it is faster to parse.
• DOM Searching: be careful how you search the DOM. Most frameworks, such as prototype, have optimized code for DOM Searching so use them.
• DOM Creation:
  • the innerHTML way: it’s fast and the code stays small but it can get very messy. Also, javascript string concatenation is slow. That’s why in the YUI framework, instead of using JS concatenation, they create an Array of string which they later join. Bob said he benchmarked this and that the Array join technique is only faster in IE 6. In newer browsers, it no longer makes a difference.
  • Tail recursion: using createElement to create the DOM objects.

Bob then started covering other types of optimization and showed benchmarks for some of those. They can be found here.

Some members of the audience were not agreeing with him on these micro-optimizations and it started a discussion on premature optimization versus code readibility and maintainability. I agree with some of the members in the audience. While it is great to know some of these low-level optimizations, I do not think that one needs to apply them for every single line of code, before even knowing whether or not this will be a bottleneck or performance hog. If you are gonna call that line only once, why go through the trouble of optimizing it. If it happens that you will call it thousands of time, then you can always go back and make it faster.

Session 3: RIA Approach for Web 2.0 Development Using jMaki

I’ve been subscribing to Arun Gupta’s blog for a while now. I started following it because of his posts on Rails and JRuby but started learning more about NetBeans, Glassfish and Jmaki thanks to him. jMaki is a very cool idea and I hope that it keeps growing. The j in jMaki stands for javascript and the Maki from Makisushi. Essentially, jMaki is a set of wrappers around javascript libraries such as YUI, Dojo, EXT JS, Scripaculous, Google Maps, etc…It makes it really easy to use components from these libraries if you are using Netbeans or Eclipse. All it takes is a drag-and-drop to have a widget on your page such as a Google Map, a YUI table, an accordion, etc…

Everytime I see someone use NetBeans 6, I’m reminded of how cool this IDE is and I tell myself that it is about time I start using it. With jMaki plugin, Netbeans is even more powerful and you can create great mashups in an instant.

Arun’s presentation had a lot of demos. One of them was demonstrating how to use jMaki with Rails while others showed how to use jMaki with JSP pages.

You can learn more about jMaki by going to jMaki.com and by reading Arun’s blog. He has some good screencasts showing how to get started with jMaki.

Session 4: RIA Development on the Microsoft Stack using Flex.

For the last session of the day, I went to see Mike Grushin talk about his experience using Flex with a Microsoft .NET stack on the server. Mike decided to use Flex with Microsoft because he came from Microsoft and was familiar with their technologies.

Mike started by describing what he calls a rich experience:

• responsive, friendly, interactive
• asynchronous communication with server: less full page reloads
• synchronous (text, audio, video)
• attractive UI

Mike’s talk was similar to my first talk of the day. He had a comparison of the four main contenders in the space: Silverlight , JavaFX, Ajax, and Flex. He came to some of the same conclusions as Yakov. Today, the Flex world is the place to be. JavaFX doesn’t have enough momentum and is not ready yet. Pay attention to Microsoft Silverlight.

After this overview, Mike focused his talk on using Flex with .NET. First he compared the different ways that the UI can access server-side data with Flex:

• HTTPService for XML/Text
  • Plus:
    • No extra server components
    • Ability to monitor download progress
    • Asynchronous
  • Cons:
    • HTTP Overhead
    • XML Overhead
    • Serialization/Deserialization of objects
    • Duplicate model object on server and client
• WebService for SOAP messages
  • pretty much same pros and cons as HTTPService
• RemoteObject: AMF
  • faster. See comparison here
  • Flex Messaging
  • Flex Data Services

Mike blogs at blog.grushin.com and is a founder of feedbackfx.com.

Since Mike finished his talk a little early, I caught the end of the Silverlight presentation that a Microsoft employee was giving next door. It looked interesting and I look forward to learning more about Silverlight during the remainder of the conference.

The main lesson learned during the first day of the conference is that I really need to start looking at Flex and Silverlight. I’ve been focusing on learning and improving my Ajax skills but have paid very little attention to these other technologies. I will spend some time on them from now on. I particularly want to take a deeper look at WebORB.