JavaScript Motion Tween - A JavaScript Animation Engine

Tagged:  

Philippe Maegerman has created a JavaScript animation engine for motion tweening similar to what's available in Flash through Actionscript. The library includes the following classes:

  • Tween class
    Tween.js is the base animation class
  • ColorTween class
    ColorTween.js extends the Tween.js class, its purpose is to manage transitions between two colors.
  • OpacityTween class
    OpacityTween.js extends the Tween.js class, its purpose is to manage opacity transitions on visual objects.
  • TextTween class
    TextTween.js extends the Tween.js class, its purpose is to manage text effects.
  • Sequence class
    The sequence.js class allows you to chain Tweens, it means that the Tweens that have been added via the 'addChild()' method will be executed in the sequence they have been added.

His blog includes documentation as well as working examples and sample code displaying the functionality of the library, including the Webber 2.0 Dock Menu Tutorial.

Full source code is also made available for download on the site.

If you're looking for something a little more heavy duty that comes with features other than just animation, then you probably want to check out one of the major JavaScript Frameworks that include animation support:

Please share your comments and experiences with JavaScript animation, these frameworks, or another framework with animation support not listed here.

The Closures Controversy in Java

Tagged:  

I just finished viewing Joshua Bloch's talk at JavaPolis 2007 entitled "The Closures Controversy", where he critiques one of the leading proposals for adding closures to the Java language (BGGA, named as an acronym after its authors). The presentation is eye-opening, and it is thought-provoking to see two of Java's biggest lumunaries on opposite sides of the debate. Of course, Bloch himself is one of the authors of an alternative proposal for adding closures, CICE (Concise Instance Creation Expressions).

It's not Clarence Darrow in the "Scopes Monkey Trial", but it's the closest we programmers can get. I won't go into huge detail about the two proposals except to say that BGGA adds full support for functional types whereas CICE is a more concise way of expressing anonymous inner classes in Java (there are many places on the web to go into the details). The heart of the debate really boils down to Defensive Programming VS. (for lack of a better term) "Let the programmer do whatever he/she wants (and let the language support it)". The former position being more conservative and more pragmatic, the later a more libertarian view that experts (programmers) are smart and should be allowed to do whatever they want. Ironically, these two opposites are also embodied in many ways in differing philosophies in design between Java and its antecedent language, C++. Java was, after all, "C++ --", the language that made smart decisions to remove features from C++ that were considered dangerously error-prone: pointers, explicit memory deallocation, etc.

So clearly Bloch is in the defensive programming camp whereas Neal Gafter, the main proponent of BGGA, is on the other side. And, I have to admit, I am on Bloch's side as well, for many reasons.

  • BGGA is complex. Non-local returns, continues, and breaks have a great potential to confuse the average programmer. The syntax, when viewed in even moderately complex code, looks cryptic. Even if you get past the syntax and non-local oddities you have to acknowledge, as Bloch so eloquently pointed out, that new features tend to add somewhere between quadratic and exponential complexity to a language because of their interaction with existing features. This was the *gotcha* with generics, and I have no desire to see that repeated with closures.
  • Defensive programming is at the very heart of what Java is as a language. And, by and large, it is this philosophy which has made it so successful. Trying to make it into an "experts language", as C++ is, cuts against the grain of the spirit of the language. (As an aside, it is telling to note that Gafter himself was a member of the C++ Standards Committee.)
  • The Java camp is already losing programmers to newer languages like Ruby because it is "too complex". Do we really want to add more complexity to drive away more programmers from the language? Simplicity is beauty, and (as someone once said) the most important decisions in a language have to do with what features you should leave out.
  • There are already other languages that target the JVM (and hence at least theoretically can interact with existing Java code) which handle closures in a much more natural way: JRuby, Groovy, Scala. Static typing without type inference tends to make control structures like closures much more challenging, if not downright awkward. Both Ruby and Groovy are dynamically typed and Scala uses static type inference. Perhaps one of these languages is a more suitable vehicle for those who feel they really need closures.

Whatever the result of the debate, it is likely that closures in some form will land in the Java language in the not-too-distant future. Right now, BGGA seems to have the momentum, which is unfortunate. Neal Gafter may, in a very well-intentioned way, be leading Java down a path of bloated complexity from which it will never recover; and which will ultimately result in Java yielding its leading position to a new language that is far more agile.

John Resig Announces Plans for Second JavaScript Book

Tagged:  

On his blog yesterday, John Resig - creator of jQuery - announced plans to begin work on a new JavaScript book. His last book, titled Pro JavaScript Techniques, was a success and is available online at Amazon.

The content of the book has not yet been solidified, but John has posted a question to the readers of his blog requesting some assistance. He's asking: "What are the greatest untold secrets of JavaScript programming that you wish were thoroughly debunked and explained?"

John already has some of his own answers to this question, and they are:

  • What is (function(){ })() and why is it so fundamentally important to modern JavaScript development?
  • What does with(){...} do and why is it so useful?
  • How can arguments.callee change how I work with JavaScript code?
  • How exactly do timers work and how can I best use them?
  • How do I identify and tackle memory leaks in web applications?
  • How do I write a cross browser way of...
    • Getting/setting attributes.
    • Injecting HTML strings.
    • Getting/setting computed css values.
    • Managing DOM events.
    • Writing a CSS selector engine.
    • Doing smooth animations.
  • How can I use verification tools (like JSLint) to my advantage - and write my own?
  • What's the best way to transmit JavaScript files?
  • How do I write my own JavaScript compressor (like Packer)?

If you have any suggestions for questions to be answered in John's new book or would like to give him a word of encouragement, you can leave him some feedback on his related blog post.

Get Insight into Digg's Bury System with Ajaxonomy's Bury Recorder

Tagged:  

If you have been using the popular service Digg you know that it is very easy to submit a story and to see it start to gain traction just to be buried into the dark abyss. What I find particularly frustrating is that you don't know how many people buried the story and the reason for the bury. If you have seen Digg Spy you have noticed that the application does show buries, but you can't just track data for a particular story.

After much frustration Ajaxonomy is now releasing a Bury Recorder application. How the application works is you take the story's URL (This is the URL of the page that the "more" link on the Digg upcoming/popular pages takes you or the page that clicking on the story title takes from your profile i.e. http://digg.com/[story]) and put it into the application and once you click "Watch for Buries" the application will start recording any buries that the story receives. This will allow you to see if your story had 100 diggs and 5 buries before it was permanently buried, or if it was more like 100 diggs and 300 buries. The idea is that you would submit a story and then have the recorder capture any buries from the time that you start the application watching for buries. You'll want to note that in this Beta 1.0 release, so currently you have to leave your machine on and the application open in order to make sure that it continues to capture buries.

Before I go a bit into the design and more information on using the application I wanted to say that the application is open source and can be changed and put on your server. If you do change it and/or put it on a different server then we just ask for a link back to us and credit us for the initial creation of the application. Also, if you do decide to put it on a server, let us know and we might link to your server as another option to elevate traffic concerns on our server.

So, now that I have you are excited you will want the link to the application. Click here to be taken to Bury Counter Application.

The following is a quick overview on how to use the application so that it will make it a bit less confusing to use (more than likely most people could figure it out, but this way if it looks like it isn't working you have somewhere to look).

Using the application is as easy as one two three, however there are two ways to use the application below is the first way of using the application.

  1. Open the application (once again the link to the application is here)
  2. Copy and paste the URL of the story into the text box (i.e. http://digg.com/[story])
  3. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

The other way to use the application is as easy as one two (yep, there is no three using this method). Before using the below steps you will need to create a bookmarklet which can be done by following the directions at the bottom of the application.

  1. Click on the bookmarklet from the story page on Digg (this has to be the page that you get when you click on the "more" link in Digg [or from your profile page it would be the page that clicking on the title of the story takes you] which is the page that you would use to get the URL for the first method)
  2. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

Now that you know how to use the application I will go a bit into how the application was created. This application gets the JSON Feed used by Digg Spy. It does this using Ajax (i.e. the XMLHTTPRequest object) which requires a server side proxy due to domain security restrictions. Due to the way that the JSON is returned from Digg Spy, it doesn't set a variable equal to the returned object, which force us to use the before mentioned server side proxy and an eval statement instead of using DOM manipulation. The application simply polls for updated data every 20 seconds which makes sure we don't miss any data and that it doesn't put too much strain on the server.

You can download the full source code for this Beta 1.0 release here.

This release has been tested in Firefox 2.0.0.11 and Internet Explorer 7. It should work in many more browsers, but has not yet been tested. If you try it in a different browser and either find bugs or the application works perfectly then we would appreciate if you contact us regarding your testing results.

Also, if you do any cool things with the application or if you have any cool ideas then feel free to blog about it on this blog. Just sign up for a free account and once you login click on "Create Content" => "Blog Entry" and then write your post. If the admins of this site feel that your post is an interesting one they will move it to the home page.

I hope that you find this application useful and that you keep checking for new version and improvements.

Java Tip of the Day: Using Interfaces

Tagged:  

Anyone who has ever programmed in Java is intimately familiar with using the interface, Java's purely abstract class and cleaner answer to C++'s concept of multiple inheritance. It's an old idea by now, and yet new ideas can somehow breathe life into old ones. And this is what has happened recently with interfaces.

The obvious use of interfaces is in abstracting behavior (i.e., methods) of objects and allowing implementing classes to implement this behavior. For example, take an interface for returning an SQL connection from different sources:

public interface ConnectionFactory() { 
     public Connection getConnection(); 
}

public class JndiConnectionFactory() { 
     public Connection getConnection()  { 
          // get DataSource from JNDI, return Connection 
     }
}

public class SingleConnectionFactory() {
     public Connection getConnection()  { 
          // create Connection using properties and return
     }
}

Here the ConnectionFactory interface is defined using two different implementations, one for container environments (JNDI) and the other when used in a non-container (stand-alone) environment (JDBC).

OK, this is old news. But there is another, more subtle, use of interfaces if you think about them as a replacement for multiple inheritance or as being somewhat akin to "aspects" in AOP: that interfaces are a way of layering behavior onto an object. Thought of this way, the style of defining monolithic interfaces with many methods becomes less desirable than defining many interfaces that define one or a few methods that describe a single aspect of an object's behavior.

Let me give two examples of this idea, one from the core language itself and the other my own.

First, the core language. When Java 5 was introduced, a few simple one-method common interfaces were also introduced. One of these was the java.lang.Iterable interface which defined the simple method public Iterator iterator(). Combined with the introduction of generics, this allowed the addition of a new "foreach" construct that looks like:

for(T obj : Iterable<T>) {
     //...logic here...
}

By isolating the simple behavior of returning an iterator, Java 5 was able to have any class that implements this be used in the new "foreach" loop (not just Collections). Joshua Bloch has also proposed an addition to Java 7 of having "resource blocks" where any object that implements a Closeable interface will be automatically closed at the end of the block.

The second example has to do with defining public and private APIs. What if, in the example above, I were using the ConnectionFactory in designing a framework that would be used as a library in other Java applications, and I wanted to define an internally used Connection that I did not want exposed to the client of the library? And that I also want to use the JndiConnectionFactory and SingleConnectionFactory implementations above with this internally-used Connection?

One approach might be to create two different ConnectionFactory objects, exposing one to the client and the other hidden internally to the framework. This is a perfectly reasonable approach, but let's say (for purposes of illustration) that this is cumbersome because of the framework design and you would rather have a single, centralized ConnectionFactory that defines another method, public Connection getInternalConnection(). This presents a problem because you really don't want to expose this private API method to the client (one of Java's limitations is that there aren't a lot of options for information hiding between classes: package private or protected).

A clever solution to this issue might be to define two separate interfaces, one that exposes a public API and the other that exposes a private API. This way you can have the various implementing classes implement both the public and private API, and you only hand out a reference to the public API to the client.

public interface InternalConnectionFactory {
     public Connection getInternalConnection();
}

public class JndiConnectionFactory 
     implements ConnectionFactory, InternalConnectionFactory { ... }

public class ConnectionFactoryWrapper implements ConnectionFactory {
     private ConnectionFactory wrappedFactory;
     public ConnectionFactoryWrapper(ConnectionFactory wrappedFactory) {
          this.wrappedFactory = wrappedFactory;
     }
     //delegate methods here
}

//etc...

// This class defines the way the client gets a connection factory...
public class AppContext {
     public ConnectionFactory getConnectionFactory() { 
          return new ConnectionFactoryWrapper(connFactoryImpl);
     }
}

The wrapper class here is used to protect the internal methods from being accessed by the client (could also use a dynamic proxy here). This promotes a cleaner, simpler public API without "polluting" it with methods meant to be only used internally by the framework.

OSGi and the upcoming Java Module System handle this need in a much more robust way, but using OSGi may not be practical for most programmers and use of JSR-277 may be very far away for most organizations which are just migrating to Java 5. Clever use of interfaces addresses this need in a simple and practical way.

Spellify 1.0 - An Automatic Text Field Spell Checker

Spellify is a script.aculo.us/prototype based spell checker for form fields that utilizes Google as its spell check engine. Last month, Spellify released version 1.0 - officially taking the application out of beta and bringing it to prime time.

Check out the short video below for a demo:

Homepage: spellify.com
Spell Check for Multiple Lines: spellify.com/extended.html

The Forms Demo:

Requirements
- PHP 4+ with CURL library installed (developed using PHP 4.4.6)
- script.aculo.us 1.8.0 (latest prototype.js, and effects.js required)

Browser Compatibility
IE7, FF2, IE6, Opera 9, Safari 3. May work in other browsers as well.

Visit the download page

Ajax Testing Tools

Tagged:  

Over at the Ajax Blog (ajaxwith.com) they have put together a good list of Ajax testing tools.

Below is an except from the post with a list of tools.

Here are the three websites you can use for testing your Ajax based program:

1. Squish (froglogic.com) – Specifically called Squish for Web, this program effectively recognizes HTML if they are properly coded. But what is more important for an Ajax based program is its ability to handle DOM. This (DOM) element is very important for Ajax as they usually deal with http-like commands and requests. Squish has the ability to analyze popular web browsers and we’re not only talking about IE and Mozilla. Firefox and Safari could easily be handled by Squish. Konqueror KDEs on different OS could also be analyzed by Squish. Remember that this is a multiplatform so Squish can analyze mixed and matched softwares on different browsers and IDEs. There are three downsides on this product though: first, it’s highly technical as these are all numbers; second, price which could easily reach US$ 2,500; and Ajax stress test could not be tested in this tool. The last factor is important since millions are now geared to use Ajax but hopefully, the next update of Squish could have this.
2. WAPT (loadtestingtool.com) – If you don’t have a stress testing test because you purchased Squish, this is the additional tool for you. WAPT is a tool dedicated in testing Ajax based websites for stress. As of this writing, the latest version is at 5.0 which are really effective for websites. Although this tool is not optimized for Vista yet, it can get really effective once it has been established. You’ll be able to see graphics on how fast your website can handle multiple visitors. This tool will also tell you how many visitors can be serviced your website seamlessly. You don’t even have to limit yourself to http sites; WAPT 5.0 was also optimized for secured (https) websites.
3. Charles Web Debugging Tool (xk72.com/charles) – Available for determining IE, Mozilla and Safari browser functions, you’ll be able to get more than just simple Ajax applications tested. The website will actually be simulated by this tool and see how Ajax will run when applied in a secured website. After this tool is ran through Charles the results will be shown in a tree format. If you want to have a good and easily understandable presentation of your website after it’s debugged this is your tool. Ajax stress could be tested by changing the configuration of the simulation. You don’t need to run in beta version if you want to test if it can handle great stress.

Click here to read the full post.

If you use any of the tools leave them in the comments, I would love to hear about your experience.

Ruby 1.9.0 Just Released

Tagged:  

I just found out that Ruby 1.9.0 (a development release) has just been released today. I haven't had a chance to look into it much yet, but below is where you can download the new release. However, you can view the change log here.

You can fetch it from:

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.bz2

407cc7d0032e19eb12216c0ebc7f17b3

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.tar.gz

b20cce98b284f7f75939c09d5c8e846d

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.0-0.zip

78b2a5f9a81c5f6775002c4fb24d2d75

I'll write more about the new release of Ruby as soon as I get a good chance to look at the new features, but until then check out the new release using the above links.

If you happen to know any thing about the new Release feel free to login to your Ajaxonomy account and leave a message or click on "Create Content" => "Blog Entry" and then write a post about it on this blog. If the post is an interesting one it will be moved to the home page.

Internet Explorer 8 Passes Acid2 Test

Tagged:  

Well, it's time for the devil to grab a warm jacket. According to the IEBlog, IE 8 passes the Acid2 test, an important and rigorous measurement of web standards compliance. Both IE 7 and Mozilla 2.0.x fail the Acid2 test.

This is what the Acid2 test looks like on Firefox 2.0.0.11:

It looks much worse on IE 7. Don't let the apparent simplicity of the Acid2 test fool you. It is a very complex page that extensively uses CSS positioning, CSS tables, overlapping content, and even illegal CSS that should be ignored. See an explanation for details.

The latest salvo in the new browser wars?

Update: Firefox 3 passed the Acid2 test as of the 12/08/2006 build (trunk).

Videobox 1.1

Tagged:  

If you are familiar with lightbox you know how useful a tool it is. While with lightbox you you can easily display images, with Videobox you can do the same thing only with videos.

Videobox was written using mootools and uses the swfobject to embed flash videos. Videobox works great for videos from YouTube, but also works with other services.

Click here to go to the official page on SourceForge. The page includes code directions and demos of the library.

Check out Videobox and let us know about any cool sites or applications that you build with Videobox.

Syndicate content