Juixe Techknow

There is a bit of a flame war unfolding between Javanistas and Rubyists. I could trace this most recent scuffle to an article posted on JavaLobby by Daniel Spiewak about a little Java library called ActiveObjects. The aritcle is promoting this Java-based but Rails inspired Object Relational Mapping library. ActiveObjects is a Java implementation of the Active Record pattern made famous by Ruby on Rails and it’s use of convention over configuration. In touting the benefits of ActiveObjects, Daniel complains and grossly exaggerates that in Hibernate “you have to write more XML than code!”

Gavin King, the founder of Hibernate, responded that XML was soo 1999 and now they overuse annotations. Gavin wrote, “Hibernate Annotations has been around since early 2005 and there is no longer any good reason for people to define mappings in XML.”

Out of the blue and into the blogosphere, Obie Fernandez responded to Gavin’s ‘FUDdly’ remarks with his top 10 rant why Java sucks ass! Basically Obie resorts to fighting FUD with FUD. Obie goes ballistic on compilers, IDEs, frameworks, libraries, High School Musical 2, and Java developers themselves. Obie rants that most Java Programmers are morons. From his writing, it is clear that Obie idol worships DHH as the fucking second coming of the fifth generation computer language era. Obie’s top ten reasons why Java sucks include that the language makes money for vendors. From his Ruby rage you think he hopes to make Java vendor money by writing Ruby books.
Continue reading

I’ve been reading a lot of articles and viewing many presentations on JavaScript. One of the most prolific writer and presenter on the subject is Yahoo!’s Douglas Crockford. I’ve recently rediscovered Crockford’s classic article on The Elements of JavaScript Style (part 2). Between these two articles Crockford lists 12 key elements of JavaScript style.

• Avoid archaic constructions.
• Always use blocks in structured statements.
• Avoid assignment expressions.
• Use object augmentation.
• Use common libraries.
• Watch out for type coercion when using ==.
• Use the ?: operator to select one of two values.
• Don’t use the ?: operator to select one of two actions.
• Use the || operator to specify a default value.
• Never use implicit global variables.
• global variables are evil.
• Use inner functions to avoid global variables.

Do you want to learn JavaScript from the experts? You don’t have to pay over $1000 in conference fees to learn from the best JavaScript developers. Here is large collection of video and slide presentations given by Douglas Crockford, senior JavaScript Architect at Yahoo!, John Resig, lead developer or jQuery, and a great many other JavaScript developers.

Videos
The JavaScript Programming Language, part 2, 3, 4

JavaScript – The Good Stuff
An Inconvenient API – The Theory of the DOM, part 2, 3
Advanced JavaScript, part 2, 3
Software Quality
Advancing JavaScript with Libraries, part 2
Best Practices in JavaScript Library Design
High-Performance JavaScript – Why everything You’ve Been Taught is Wrong
Maintainable JavaScript

Slides
Building a JavaScript Library

Metaprogramming JavaScript Presentation
CSS + JavaScript tips
How To Bluff Your Way in DOM Scripting
The Behaviour Layer – Using JavaScript for Good, not Evil
JavaScript 2 and the Future of the Web
JavaScript Boot Camp Tutorial

Technorati Tags: javascript, learn, learning, conference, programming, crockford, yui, resig, jquery

Here the evolution of a JavaScript coder, taken from the Best Practices in JavaScript Library Design presentation by John Resig at Google HQ.

• “Everything is a reference!”
• “You can do OO code!”
• “Huh, so that’s how Object Prototypes work!”
• “Thank God for closures!”

Technorati Tags: javascript, coder, best practices, googleplex

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.

[source:ruby]
Shoes.app :width => 200, :height => 200 do
# line x1, y1, x2, y2
line 20, 40, 60, 80
end
[/source]

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

[source:ruby]
Shoes.app :width => 200, :height => 200 do
# oval center_x, center_y, width, height
oval 50, 100, 100, 50
end
[/source]

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

[source:ruby]
Shoes.app :width => 200, :height => 200 do
# rect top_x, top_y, with, height
rect 100, 100, 30, 10
end
[/source]

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.

[source:ruby]
text_field = nil
Shoes.app :width => 200, :height => 200 do
text_field = text Time.new.to_s
animate(1) do
text_field.replace Time.new.to_s
end
end
[/source]

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.

[source:ruby]
moving_box = nil
Shoes.app :width => 200, :height => 200 do
# fill red, green, blue, alpha
fill 1.0, 0.5, 1.0, 1.0
stroke 0.5, 0.5, 1.0, 1.0
strokewidth 5
moving_box = rect 10, 10, 20, 20

animate(2) do
x = (0..width-20).rand
y = (0..height-20).rand
moving_box.move x, y
end
end
[/source]

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

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