Dave Johnson

Wed Feb 6 - Ajax and Beer 2.0 - come get drunk and display your superhuman programming abilities.

Sat Feb 9 - Nitobi Hack Day - come get drunk and display your superhuman programming abilities. Hopefully all the Nitobians will be there and then some so we are expecting about 25 or 30.

We now return to your regular programming.

The second Nitobi Hack Day will be happening on Feb 9, 2008 from 10am to 6pm. You can come and start hacking at 9 things will officially start at 10am SHARP! Of course you can always come by later and if you don’t know anyone just ask for someone that works at Nitobi to show you the ropes. You can signup over at Upcoming.

The event is meant to bring hackers from around Vancouver to the Nitobi office and dedicate a day to building something amazing! That something can be hardware, software or whatever. The hacking is generally focused on Ajax (of course), social networking (Facebook apps anyone?), wireless (Joe and I got this covered), AIR / Flex, and web development in general - of course the hacking can still be robotics, Wii hacks or whatever you think is cool.

Nitobi will provide the foosball, beer, prizes (like books, shirts, software and an IPod Nano) and you provide the hax0r skillz.

Be there!

The builds are running and - as the press release suggests - it will be available today!

We have improved performance significantly in this build and added a few new features like drag-fill of selections.

I will be posting a screencast later today as well.

w00t!

I was reviewing some code today and came across something that seemed very strange. There is a method we use for removing all the child nodes of a parent node in an XML document and it looked like this:

Someone (probably me) was trying to save processing and store the child node collection length rather than re-calculate it every time through the loop. Seems good but one will notice that we are removing the child at the i’th index and so half way though deleting the child nodes we are going to try and delete the len/2+1 node but there will only be len/2 nodes in the collection (or something along those lines).

So I “fixed” it and made it look like this:

Now it would always remove the first element in the collection and iterate over the original collection length - done and done. Oh wait but no. So I go to test this in Firefox and low and behold it crashes like AAPL after MacWorld.

Then I finally get my act together and test both approaches in Internet Explorer and the latter approach - the expected solution - is the one that works. So Firefox is doing some strange things with the length of the child node collection.

I was just making some content for an Ajax video training series that Andre, Alexei and I are preparing for Prentice Hall as an extension of our book (Enterprise Ajax) and thought that I would just share this tidbit about CSS for those that have never really fully understood how it works but know enough to be dangerous.

CSS rules are applied using two approaches: inheritance and the cascade. So styles can be applied to certain elements through inheritance from styles of parent elements or by the battling of different styles based on cascade rules.

Cascade

The cascade is a bit more involved. There are three important aspects when the browser determines what styles get applied to what elements.

Origin

The first is the style origin. Styles can defined either by the web page author (Author), the person viewing the web page (User) or the application being used by the user to view the web page (UserAgent). The precedence rules for the origin are just that - Author, User, UserAgent - in order from highest precedence to lowest. Of course User specified styles can use the !important modifier on their styles to override Author styles.

Specificity

The second aspect of the cascade is specificity. The specificity is determined by how specific (go figure) the CSS selector rule is that matches a particular element. ID selectors are the most specific followed by selectors based on attribute values such as class names followed by selectors with element names in them - i.e. in order of precedence from highest to lowest we have #header {}, *.header {}, div {}. To get the specificity of a rule we count the number of ID selectors (call it “A”), the number of class or attribute selectors (call it “B”) and finally the number of tag names (call it “C”). Then we concatenate ABC and we come up with a final number like 321 and then compare all the rules for a style and highest number wins.

Order

Finally we have the style order. If we have multiple rules in the Author stylesheet for a page that all have the same specificity then the last defined style will win.

Inheritance

If the cascade does not result in a style being set, then inheritance may become important for the defining of an elements style.

Most CSS styles are not inherited. Background color, borders and the like are not inherited by default whereas line-height and fonts are. You can force a style to inherit by setting the value of the style to inherit as in background-color: inherit;. That’s really all there is to inheriting - just don’t get it mixed up with object oriented inheritance. If you feel like you want to do something along the lines of object oriented inheritance then remember that you can define multiple rules separated by commas such that those rules all use the same styles such as .header, .footer {font-face: arial;}.

For the entire story check out the official W3C site but hopefully this will help some people out there write more succinct and understandable stylesheets!

Brian has just informed me that there will be a second Ajax and Beer meetup at the Shebeen room!

So be there on Feb 6 (Wed) for some beer titillating Ajax conversation.

That reminds me … we have to do Nitobi Hack Day 2.0 as well …

I think that people still finding new and interesting features of old browsers is a good sign that Ajax still has some gas left. Even more recently there are developments around charting, comet, sound and widgets. For those reasons I am not convinced that new “RIA” frameworks like Flex, Silverlight and JavaFX are the nirvana that will save us poor web application developers from the hell that is cross-browser JavaScript and DOM development. Even the very idea that Ajax is a cross-browser hell is really a misnomer in this day and age when there are so many different mature Ajax frameworks that take care of a lot of the cross-browser issues Ajax developers have to deal with on a daily basis - Ajax frameworks are to Ajax developers as the Flash player is to Flex developers. Most of the rest of this is to build on what Kevin Hoyt recently posted.

Where Have We Been

Over the past few years both Ajax and Flex have come a long way. Previous versions of Flex (and Flash before that) were nowhere near where Flex 2 / 3 Beta are at and one can achieve amazing things with Flex these days. The same can be said for Ajax. I think that both Flex and Ajax have been moving forward in step. In fact, Ajax has been around for a lot longer than Flex and was already creating real RIAs back in the late 90’s when Flash 3 was still only being used to make website intro’s. Certain frameworks, like Ext, make it simple to create applications with a desktop like feel using splitters, panels and common desktop UI widgets.

What is an RIA

I use the term RIA here with some reservation just because of the differing perceptions of what it really means - sort of like early perceptions of DHTML only being useful for annoying flashing text and simple animations. In terms of Ajax, one needs only look to today’s best of breed Ajax applications such as the Google online application suite including their great spreadsheet and mapping applications, which either don’t have equivalents in other RIA technologies or are simply better than their competitors; most people would choose Google Maps over the Flex based Yahoo! maps any day. Really, other than Buzzword, there are few popular Flex based RIAs (and even fewer that are actually available to the public) and frankly is there anything that much more amazing about Buzzword compared to a Google Doc? Google Doc even “feels” faster and more responsive to boot.

If RIA is about eliminating the page refresh or drag and drop then Ajax definitely has the right tools to create an RIA application. If RIA is about creating a “desktop like” experience then Ajax is definitely an RIA. If RIA is about improving the user experience and usability of network connect applications then Ajax is undoubtedly an RIA. One look at Google Mail and anyone can appreciate that it for the most part loads faster, searches faster, and generally performs far better than a desktop mail program like Outlook. Even in areas that Ajax may struggle, such as video or graphics, Ajax can take advantage of a wide variety of other technologies such as Flash, SVG or Canvas.

Flex Shortcomings

As with Ajax there are a lot of shortcomings to Flex applications. Dealing with the browser back button, search indexing, rendering HTML content are just a few of the problems that face Flex developers - some of them equally problematic for Ajax applications others not.

On the other hand, one of the biggest strengths of Ajax, which is often quoted as a weakness, is that it depends on the fragmentation of browsers and standards. As we know, overspecializing breeds in weakness. While Ajax may change rather slowly due to the glacial pace of browser advances and constant bickering over standards (something that is changing more rapidly now as the browser market becomes more competitive), at least the people doing the standards are less impacted from having budgets, managers and boards to report to - i.e. closed products like Flex are produced by companies that need to make money. Furthermore, any gaps in the technologies provided by the browser vendors are often filled in by the tireless work of Ajax framework developers.

And you know what the best part of being standards based is? You get included in all the coolest new technologies. Can the same be said of the de-facto standards? Well, Opera is doing ok

Development Process

Flex has a hard time fitting into conventional - and I dare say preferred - web development processes, which will keep it on the fringe for some time to come. The process that Flash and now Flex developers go through when building an application is that they have Flex builder to design their application and maybe write some ActionScript to access some web service endpoints on a server somewhere. Then the developer needs to build their web service endpoints using a different tool (likely Eclipse or Visual Studio). Everything is separated between the client and server only connected by the web service endpoints yet the client side development is still not strictly for a designer but a designer and an engineer need to work on the Flex application. One interesting thing about this approach to development is that it fits in well with the enterprise SOA sort of idea; the Flex app is only a consumer of enterprise services and does nothing on the server. This is one reason that Flex is becoming popular in applications for SAP and Salesforce I think. However, hat is not to say that Ajax has no place in enterprise applications. The one thing that I do really like about Flex development is the declarative approach which few Ajax frameworks have done, I digress.

On the other hand, Ajax developers are used to using one tool for doing their server and client development whether it be Dreamweaver, Eclipse, or Visual Studio. Arguably the most popular Ajax frameworks, notably ASP.NET Ajax and Google Web Toolkit, actually combine both server and client development in one environment. In those environments Ajax developers are able to write server side code (binding to databases, interfacing with external web services, writing server side events, and so on) as well as client side code (CSS, JavaScript and HTML) all in one place. Even better, the server side code often encapsulates all the HTML, JavaScript and CSS required for an Ajax component like a tree or grid making Ajax development a painless and productive RIA endeavour.

Ajax developers also have so many choices between different Ajax frameworks that provide different widgets and various fundamental approaches to Ajax itself. Some are integrated with the server while others are completely client side. Whereas if a developer chooses Flex, they have really only got one option for their framework, their widgets, their tech support and their sanity.

Testing

Unit testing is all well and good but where is the functional test framework for Flex that is Selenium to Ajax? I concede that functional testing is more important for Ajax just because you may be trying to hit four or five different web browsers with your application but it is important for Flex development even beyond just checking for browser nuances.

Mashups

Finally, one of the biggest drawbacks of Flex, and strengths of Ajax as evidenced by the Web 2.0 craze, is the fact that Flex simply does not play nice in the world of the web. Sure you can access data across domains from Flex if the remote server has read permissions set in the crossdomain.xml file, however, in general Flex is not amenable to building mashup applications. There is no easy way to specify some Flex widget and have it dynamically included in another Flex application (probably due to what I say in the conclusion). On the other hand Ajax RIAs are free to use any of the many technologies at their disposal and mashup content from anywhere on the net - including Flex content. Ajax applications were popularized due to the early mashup - in particular maps based ones with Google Maps. Flex is a heavy (handed?), non-standard, monolithic approach to building RIAs that are conducive to keeping the application separate from others.

Conclusion

Ajax is made for the browser and the browser will continue to be the universal approach to accessing content over a network for some time to come. Not the least reason of which is the rule of least power. The web became popular for a reason and that reason is the ease with which content can be created. This is as true for HTML as it is for Ajax and is the main reason that Ajax is alive, kicking and will be around for a while despite new RIA technologies.

It feels like I have been sitting on half a dozen blog posts about AIR and JavaScript for a while now - and I will sit on them for a little longer still

Anyhow, things have been busy at Nitobi of late with starting new projects, deploying projects like Jiibe, hiring new people to fill in our Interaction Design and Information Architecture positions, speaking at GWT conferences (well Andre and Alexei did all the talking), and consulting on various projects.

Currently I am down in Portland for another few days where I am helping Nike implement our Ajax Grid in some of their B2B systems. Undoubtedly the best thing about Portland is the fact that there are so many breweries, pubs, and even, oh yes, brew pubs. So last Friday I hit North 45, Lucky Lab, Bridgeport and Rogue with a few of the very nice folks from Nike. I also started to make a Portland pub map - the traveling salesman problem really hits home once you start thinking about how to enjoy a few pubs most efficiently.

Needless to say it was a good time with great beer! Looking forward to coming back that’s for sure.

It seems like I never have time to blog about coding anymore - though I do have about half a dozen half baked posts just waiting to go up.

At any rate, Brian has just posted info about something that has long been missing from the Vancouver tech scene - a beer and Ajax geek meetup!

We are meeting Nov 11 at 7pm at the Shebeen room behind Irish Heather in Gastown. But check out Brian’s blog for all the details.

That is the name of the application that Jake, Chris and I made for the inaugural Nitobi Hack Day last Saturday.

Yes, we may have had the biggest team and yes some teams didn’t even stick around until the sweet, sweet beer but we came within a whisker of winning it all! Of course, how you split up a single iPod Nano amongst three people is anyone’s guess.

The idea behind the application was that we wanted a desktop app that would be running all the time and would bring in information from many different sources about music artists / bands that you like. In particular, I never know when new albums come out from bands that I like. The trick is that we use, in this case, your top tracks XML listing from Last.fm to determine what you like - ie what you listen to most is what you like. Then we use that info to look up different information about the bands. At the time of building the application we decided on two things to bring in; new releases and events. The original reason that we went with the AIR application was because I wanted to use my iTunes XML file. We found a problem with that early on - my iTunes XML files is >7MB and AIR has a tough time opening it. That is when we decided to go with Last.fm.

I will release the app shortly once I get some time to fix it up.

We were able to deal with the new AIR security model pretty easily and of course chromeless windows and all the great CSS3 support was much appreciated!