Juixe Techknow

I recently picked up JavaScript: The Good Parts by Douglas Crockford. Douglas is a senior JavaScript architect at Yahoo! whose work with JavaScript has inspired JSON. In JavaScript: The Good Parts, he presents the best features of JavaScript that have made it ubiquitous while omitting those imperfections that have given the language its bad rap. The good parts include loose typing, object literals, object model, prototype inheritance, and closures. The bad parts are the global variables, DOM, browser incompatibility, lack of block scope, eval, lack of real arrays, and to many falsy values (0, NaN, “”, false, null, undefined).

Perhaps adhering to that famous proverb that says if you can’t say anything nice, don’t say anything at all, JavaScript: The Good Parts is a slim book and a quick read. JavaScript: The Good Parts is one tenth the size of JavaScript: The Definitive Guide. Even with its small shelf space footprint this good has plenty of good parts, such as the following…

Most programming languages contain good parts and bad parts. I discovered that I could be better programmer by using only the good parts and avoiding the bad parts.

How can you build something good out of bad parts?

JavaScript is a block of marble, and I chip away the features that are not beautiful until the language’s true nature reveals itself.

It turns out that strong typing does not eliminate the need for careful testing. And I have found in my work that the sorts of errors that strong type checking finds are no the errors I worry about.

Obsolete comments are worse than no comments.

Generally, the craft of programming is the factoring of a set of requirements into a set of functions and data structures.

Software is usually expected to be modified over the course of its productive life. The process of converting one correct program into a different correct program is extremely challenging.

It turns out that style matters in programming for the same reason that it matters in writing. It makes for better reading.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. … Features have a documentation cost. Every feature adds pages to the manual increasing training costs.

Features that offer value to a minority of users impose a cost on all users.

Douglas Crockford has numerous technical presentations for learning JavaScript and written Twelve Elements of JavaScript Style.

Technorati Tags: javascript, crockford, yahoo, yui, review

I many 10-5 developers not working directly with ajaxified web 2.0 applications I was not able to go to the Google I/O conference. I don’t feel so bad not going since Google has just released video recordings of over 70+ technical presentations from Google I/0. Most of the technical presentations are pushing Google’s APIs such as Android, Google App Engine, GWT, and Open Social.

As an aid for myself, and maybe other GWT developers, I have organized the pertinent GWT presentations as follows…

Surprisingly Rockin’ JavaScript and DOM Programming in GWT
You may already know about GWT’s nifty JavaScript Native Interface (JSNI), which allows you to define native Java methods with handwritten JavaScript. In GWT 1.5, there’s an even more powerful way to program close to the metal. You can now model arbitrary JavaScript types directly as Java classes (specifically, as subclasses of GWT’s JavaScriptObject class), yet there is no overhead in size or speed. You can code against any JavaScript object as if it were a regular old Java object. So, what does that buy you?

Continue reading

If you don’t understand Open Source licensing, don’t start an Open Source project. Keep your code! ExtJS, a JavaScript framework for building business forms, recently made big news, the bad kind, when it changed it’s license from LGPL to GPL. ExtJS started as an extension to the Yahoo! UI library.

ExtJS had been in my radar for a long time, but I never downloaded it, used it, wrote about it, or contributed to the community in any way because since its foundation the licensing of the library seemed awkward to me. If my memory serves me right, earlier releases of ExtJS had interesting clauses that prohibited you bundling ExtJS in frameworks. For me, I keep on using jQuery and YUI.

Open Source is not so much about the code, it is about the community and how that community interacts with other communities. Open Source is community building. In this Age of Meetoo, companies are sprung with VC money simply by cloning services and products of other companies. Look at all the ‘social viral video sharing’ sites are just imitations of YouTube. In this age, the real value of code does not lie in the source code, the value lies in the knowledge and expertize of the community. The same can be said of a service, the value lies in the user base.

The folks behind ExtJS feel that this license change to GPL adheres to the quid pro quo principle. This is true if all you want is code, but community evangelism is worth is worth more than its weight in code. Look at the spectacular growth and good will around jQuery. For every one line of code in jQuery, there is at least one plugin written by a third party. For every one line of code in Ruby on Rails, there is at least one coder-blogger-evangelist promoting the framework.

It is true that you can shoot yourself in the foot with just about any programming language, but with changing the license of an Open Source project you can shoot your whole community, execution style.

Graeme Roche, project leader of Grails, said, “What they have effectively done is built up a community, taking full advantage of the open source model by accepting user contributions and patches and then turned around and kicked their own community up the backside.”

Jack Slocum, the lead developer and founder of ExtJS, responded to all the criticism on his blog. Jack complains, “Shortly before 1.0 is released, there numerous Ext “clones” started popping up that were hacking Ext themes.” Other developer hacking, learning, promoting, evangelizing, and cloning is the great benefit of releasing an Open Source application, ExtJS itself was a ‘clone’ and a hack of Yahoo! UI.

What I find interesting of the whole event is that this is history repeating itself. This is not the first time nor will it be the last time that some organization has leverage a license for some perceived monetary benefit.

What follows is a pretty comprehensive list of articles that talk about the recent ExtJS license change.

• ExtJS: slightly odd license
• ExtJS: When open source is not open at all
• Ext Licensing: Oh, what a mess
• My response to Jack Slocum’s post on the GWT-Ext forum
• Ext JS and the fun with Open Source licenses
• Clean Licensing: Why You Should Care (If You Don’t Already)
• Choosing an OSS License and the Ext-JS saga
• Ext Discovers Step 2 of the Slashdot Business Model?
• Are You At Risk? Abrupt OS License Changes
• OpenEXT: The fork
• OpenEXT
• extjs – when open source kills community progress
• When people don’t understand GPL and LGPL – or – ExtJS is history
• More cluelessness from ExtJS lead developer Jack on the GPL issue
• Ext JS License change and personal attacks
• Ext 2.1 Released; License Changed from LGPL to GPL
• Ext JS… no thanks
• ExtJS, (L)GPL, Jack Slocum, Business and Ethics
• Ext JS: A reminder that you are not alone

Technorati Tags: extjs, yui, javascript, ajax, business model, license, gpl, lgpl, bsd

Last week I had the pleasure of attending the YouTube / Picasa Web API Hackathon at Googleplex. Google is always a great host and they provided food, t-shirts, and even raffled a pass to Google I/O.

The hackathon started out with presentations by folks on the Google Data (GData) team. All of Google application make their data available through the GData API. GData is available in different formats including RSS or Atom. Every data point of Google’s applications are made available through GData, for example YouTube user profiles, video data, play lists, subscriptions, and video views can be accessed via GData feeds. The GData API does allow application developers to read and write data to Google Applications, but write operations require authentication. For example, uploading a new video, modifying video metadata, or writing comments requires authentication. For web applications or services that need to be authenticated by GData API they need to use AuthSub. AuthSub redirects the end user to a Google site for the end user to log into Google and then Google forwards back to the requesting site with a valid authenticated token. The GData team strongly discourages (or disallows depending on who you ask) for third party application, services, or developer from collecting Google user credentials. Since AuthSub requires the user to login at a Google site, third-party applications don’t need to collect Google credentials.

As I mentioned earlier, GData can be delivered via RSS or Atom. Because YouTube and Picasa describe media files such as videos and images, those APIs also use Media RSS.

Geoff Stearns, Flash hacker on the YouTube team, talked about the YouTube Player API. The embeddable YouTube player can be customized and configured with parameters in the video url. Parameters include rel, autoplay, loop, border, and others. Rel is a boolean value that indicates if you want related videos to be displayed in the ‘genie menu’. Autoplay indicates is a boolean value that indicates if the video should play once loaded. In addition to player parameters, the YouTube player can be manipulated via JavaScript. The YouTube player can be made to play, pause, stop, mute/unmute, get/get volume, and seek ahead in the player. It is incredible easy to manipulate a video through the YouTube Player API, you can build your own video controls with JavaScript. Since the YouTube player can be manipulated entirely via JavaScipt, developer have an option to building their own video player with their own custom controls with the YouTube Chromeless Player.

Geoff has a kewl mashup example between YouTube JavaScript API and Google Maps. The mashup is a on board video of a race in San Francisco. As the video proceeds it updates the Google map as of the location of the camera, in essence you get a street view of the race and a aerial view of the race track.

Technorati Tags: google, googleplex, youtube, picasa, api, javascript, flash, video, youtube player, authsub, media rss, atom, gdata

I was reading over the descriptions for the currently scheduled sessions for JavaOne 2008. Here is a short list of the sessions that seem interesting to me in no particular order.

• BOF-5110: Extending Groovys Swing User Interface in Builder to Build Richer Applications
• BOF-5998: Meet the Java Posse
• BOF-6229: Cutting-Edge Productivity with RIFE and Web Continuations
• PAN-5435: The Script Bowl: A Rapid-Fire Comparison of Scripting Languages
• TS-4806: JRuby on Rails: Web Development Evolved
• TS-4868: From Java Technology to Ruby…and Back
• TS-4895: The NetBeans IDE Compared to the Eclipse Rich Client Platform
• TS-4982: Extending Swing: Creating Your Own Components
• TS-4986: JavaScript Programming Language: The Language Everybody Loves to Hate
• TS-5152: Overview of the JavaFX Script Programming Language
• TS-5165: Programming with Functional Objects in Scala
• TS-5416: JRuby: Why, What, How…Do it Now
• TS-5572: Groovy, the Red Pill: Metaprogramming-How to Blow the Mind of Developers on the Java Platform
• TS-5579: Closures Cookbook
• TS-5764: Grails in Depth
• TS-5793: Groovy and Grails: Changing the Landscape of Java Platform, Enterprise Edition (Java EE Platform) Patterns
• TS-6096: Nimbus: The New Face of Swing
• TS-6169: Spring Framework 2.5: New and Notable
• TS-6457: Choosing Your Java Technology-Based Web Framework: A Comparison
• TS-6490: JRuby on Rails Deployment: What They Didn’t Tell You
• TS-6609: The JavaFX Script Programming Language for Swing Developers
• TS-6611: Filthy-Rich Clients: Filthier, Richer, Clientier
• TS-6656: Extreme Graphical User Interface Makeover: Rock Stars
• TS-6929: Creating a Compelling User Experience

I have gone to JavaOne four out of the last five years and have compiled pretty complete conference notes for JavaOne 2007 and JavaOne 2006.

Technorati Tags: javaone, javaone 2008, java, jvm, groovy, jruby, javascript, swing, nimbus, jfx, netbeans, eclipse

Recently I wrote a tutorial on how to use XPCOM in FireFox to access the user’s disk drive. With XPCOM you can access core browser functionality and with the right permissions can even read files and data off the user’s disk drive, access the network, and much more. In this code walk through we will look at how to read the contents of a file saved on the users desktop using JavaScript code from FireFox.

Before we get started we need to define XPCOM contract id and interface used to access files on the client-side. To access user files, you need to enable the correct privileges and for that you negotiate with the browser Privilege Manager.

// Id and interface for file reference
var fileContractId = "@mozilla.org/file/local;1";
var fileInterface = Components.interfaces.nsILocalFile;

// Id and interface for input stream
var inputContractId = "@mozilla.org/network/file-input-stream;1";
var inputInterface = Components.interfaces.nsIFileInputStream;

// Id and interface for scriptable input stream
var sinputContractId = "@mozilla.org/scriptableinputstream;1";
var sinputInterface = Components.interfaces.nsIScriptableInputStream;

// Request proper security privileges
netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");

The XPCOM interfaces we will be using here is the local file which acts as a reference to the file. The file input stream and scriptable input stream will be used to read in the file data.

As noted in the previous XPCOM tutorial, you use the contract id and interfaces get objects that implement them. The next snippet of code will define the path of the file whose data will be read and it will crate the correct file and input file objects to do so.

// Path to file
var readFilePath = "/Users/juixe/Desktop/temp.txt";

// Get file reference
var fileClass = Components.classes[fileContractId];
var file = fileClass.createInstance(fileInterface);
file.initWithPath(readFilePath);

// Get input stream
var inputClass = Components.classes[inputContractId];
var inputStream = inputClass.createInstance(inputInterface);
inputStream.init(file,0x01,null, null);

Notice that to initialize the file input stream I passed in a file reference to the file and a few other parameters. There is some XPCOM documentation on XUL Planet descring these parameters but it is probably best to find sample code to see its usage in the field as I had some difficulty making heads or tails out the documentation.

To get access at the data in the temp file use the scriptable input stream such as the following code.

// Need scriptable input stream to get content
var sinputClass = Components.classes[sinputContractId];
var sinputStream = sinputClass.createInstance(sinputInterface);
sinputStream.init(inputStream);

// Print file data
document.write("File Data: "+sinputStream.read(sinputStream.available()));

Notice that the scriptable input stream was initialized with the input stream created earlier. To read the date in the temp file use read in as many bytes as you would like.

Once done with the input streams you can just close them.

sinputStream.close();
inputStream.close();