John Resig, lead developer of jQuery, went down to the Googleplex and presented on JavaScript best practices, which he learned from developing the popular jQuery JavaScript library. The video of the presentation and the slides from the talk are available from John’s post on the experience.

For my own benefit I’ll recap some of John’s key points made in the presentation. In writing a general purpose JavaScript library you need to deal with browser specific bugs, have enough documentation in place, provide test cases, keep maintenance in mind, and have a solid API design.

In talking about API design, John said to fear adding methods. The more methods your library supports, the more code there is to maintain, support, test, and document. Instead of adding methods to your API you should embrace removing them where it makes sense. If you add/remove methods between releases be sure to provide an upgrade path, preferably through a plugin. For example, when moving from version 1.0 to 1.1 of a library you can provide a 1.1 plugin that eases the migration for 1.0 users.

John reminded the audience that a consistent API is paramount to designing a general purpose JavaScript library. A consistent API means following a naming convention for method names. The naming convention includes method signatures, for example follow a consistent position or order for parameter types. In addition to following a naming convention, you should be clear about behavior.

When developing a enterprise-grade JavaScript library you need to have a good grasp of JavaScript language tricks and features such as closures, encapsulation, local variables, and namespaces. John also recommended not to extend browser native objects because it is hard to get DOM extensions working across browsers. Also a new version of a given browser might introduce functionality or new methods that conflict with those your library adds to native objects.

A key point made by John, which I alluded to before, is to allow for extensibility by introducing a plugin architecture. If you allow end users to create their own extensions you will have less functionality to maintain yourself, you can always defer feature requests to the community. Since much of the functionality can be added as plugins, the core library will have a smaller footprint.

If you are counting on the support of a community of users, John stated the importance of having clear and concise documentation. Documentation is key in fostering a sense of a lively community. Provide documentation in a clear format (something like XML) and allow users to build their own API viewer. Encourage users to build and disseminate cheat sheets, API widgets and viewers, and translations of the documentation. Right from the start, provide enough documentation for the community to get started, such as tutorials on plugins.

Technorati Tags: jquery, javascript, library, best practices, api, googleplex, google, video, presentation

I’ve already gone over the basic UI features of the Shoes toolkit. Shoes is a nice little domain specific language for developing GUI applications in Ruby. Here I’ll go over some of the 2D graphics and animation capabilities in Shoes.

Shoes has a light weight 2D support where you can draw lines, rectangles, and circles. To create an application that draws a line we can execute the following bit of code.

To draw an oval insert the following code inside the shoes code block.

And to a simple rectangle, you can do so by using the rect method.

Shoes also supports the animate method which can be used, as it’s name applies, to repeatably call a block of code that animates some graphics. The animate method takes a parameter, the number of frames per second. For example, to draw a new image once a second we can call animate(1). To draw an image twice a second call animate(2). Here is a simple example of the animate method in action.

The above piece of code creates a text field and updates the value of the text field with the current time once a second. This way you can animate a simple text-based clock.

Here is another animation example. The following code draws a rectangle. The rectangle is moved twice a second to a random location within the application window. This code uses the fill and stroke methods, which accept arguments to define the fill and stroke color respectively. You can also use the strokewith method to set the width of the pen stroke. Also notice that the following example invokes the width and height methods which return the current width and height of the application window.

As you can see, it is easy to draw 2D graphics using Shoes.

Technorati Tags: ruby, shoes, gui, ui, _why, tutorial, 2d, graphics

Shoes is a cross-platform mini-gooey toolkit for the Ruby programming language written _Why. I installed Shoes on an Ubuntu box ran with it (bad pun intended).

Let’s move from puns to code. A simple Shoes application is wrapped around the following piece of code.

As you can see, a Shoes application is simply a Ruby block. You can pass in a hash or arguments with the values for the window’s default height and width. If you save the above piece of code as Appy.rb you can run it from the Shoes installation directory by running the following command.

./shoes Appy.rb

If you run the above application it simply opens a empty application window. An empty window is pretty much useless. An GUI application needs buttons and text fields to be of practical use. Lets add two buttons to our application that when pressed print out an informational bit of text to the console.

When working with soft gooeys the second thing one needs to learn after how to add a button is how to layout it out. As of this writing (Release 117), Shoes provides two layout managers, Stack and Flow. Stack lays out your components from top to bottom. The Flow layout container lays out UI widgets from left to right. Building on top of our Shoes application the following code layouts out the two buttons using the Stack cointainer with a 10 pixel margin.

To add a simple text field just call the text field with the default text value.

Here is how the above code renders.

I would be a bit more practical if we can update the text field based on some condition, say when a button is pressed. Since we need to reference the text field in the code block for each button we need to have a variable for it. Also, instead of printing text to the console, we will display it in the text field.

As you can see, you can get started writing Shoes GUI applications fairly quickly. But as mentioned earlier, Shoes is a mini-GUI toolkit that is still under development. _Why has mentioned that he intends to keep Shoes small. From what I can gather from sample applications and the online code repository Shoes provides additional widgets such as an edit_line, edit_box, and list_box. But I was not able to find any information regarding tabs, check boxes, radio boxes, or trees.

In the next installment of Running with Shoes, I’ll go over it’s 2D and animation capabilities.

Technorati Tags: ruby, shoes, gui, ui, _why, tutorial

There are many formats in which to write a technology book, such as those nutshell, cookbook, and dummy book formats. There are also a set of books that introduce you to a subject from a distance, those that provide a ton of nitty-gritty code snippets, and those that build a sample, yet trivial, application. I would classify Programming Flex 2, jointly produced by O’Reilly and the Adobe Developer Library, as a high-level introductory text for Flex 2 so that managers that have not written a line of code since Fortran can put it on their bookshelf. I feel that a better suited name for this book might have been ‘A Nice Review for Thinking About Programming Flex 2′ as it does not provide enough reference material to actually program a useful application. Programming Flex 2 is a nice overview of the programming environment for Flex but in my blunt opinion it does not give enough depth in any of the topics it tries to cover. The book breaks down the Flex 2 SDK into the following 19 chapters…

Introducing Flex

The introductory chapter on Flex 2 goes over how Flex runs on top of the ubiquitous Adobe Flash player. The author touts the market share of the Flash plugin which is thought to be installed in nearly 98% of all internet enabled machines.

The Flex platform is based on standards such as XML, HTTP, Web Services, and ECMAScript and leverages rich media support in Flash. The Flex Framework consists of libraries for UI controls such as buttons, text fields, menus, layout containers, data containers, effects, and more which are used to build interactive UI clients. You can program Flex 2 applications coding markup code by hand or break down and shell out close to $500 on Flex Builder 2, a Eclipse-based commercial-grade IDE.

Building Applications with the Flex Framework

This chapter provides a bit more detail into MXML, the markup used in Flex, and ActionScript. MXML is compiled into ActionScript which is then converted into a SWF Flash file. Flex 2 SDK comes with two compilers, mxmlc and compc, to build Flex applications. This chapter goes over the details on how to compile a Flex application using the command line and the mxmlc compiler.

MXML

With the obligatory introduction out of the way, this chapter introduces the MXML markup language used to write Flex applications. MXML is a markup language like XML or HTML, so proficient web developers and designer will pick it up right away.

Here is the take away from this chapter. There are two available root nodes for MXML documents, application and canvas. An application is made of components, such as buttons or text fields. There are several types of components, visual just as buttons and non-visual such as data. MXML supports events similar to the onclick events provided in HTML.
Read more »