Yesterday Google announced its new offering: Google App Engine . These are my random notes I did yesterday when I studied the new service.

Google didn’t go the same way as Amazon with its AWS . The former offers a form of shared hosting (think “distributed WebFaction ”), while the latter offers a virtualized environment (think “distributed SliceHost ”). So basically we are talking about more high-level approach to web applications, which is easy even for novices. On the other hand AWS is more flexible and more enterprise-y.

As you all know by now Dojo 1.1 was released in the wild . You can get a lot of useful links and info from James Burke’s post on Dojo 1.1 , but let me tell you why you should be excited:

1. Dojo 1.1 is the first official release, which contains dojox.lang.functional . It was available in the trunk for awhile, but now you can use it without deploying Dojo courtesy of AOL CDN . I am psyched about it!
2. Improvements in animation, animation helpers for dojox.gfx. A good examples of animation in action is dojo.moj.oe by Pete Higgins (internals were detailed in the blog post , and in the great Dojo Campus article ), an example for dojox.gfx animation is the career test . Finally we are getting to the point when we create attractive GUI cross-platform without plugins.
3. The Dojo API tool . As you know Dojo is essentially a federation of JavaScript modules. Every module can be a library on its own. Now we have a simple way to navigate them, read developer’s documentation without diving into the source, and understand the API. When comments will be added to it shortly, you can add your own notes, and ask pointed questions. Developers are getting an essential tool to see how their modules are documented, what questions are raised most frequently, and so on. This tool will help us to document Dojo even better. All in all Neil Roberts and Tom Trenka did a great job!
4. Numerous improvements and bug fixes — this is always good. The API is mainly unchanged, so the migration to Dojo 1.1 should be a no-brainer for most users.

I am pleased to see that social aspects of Dojo are getting attention: the redesigned Dojo web site , the Dojo API tool , Dojo Campus is always fun, Dojo forums are active, even the Dojo archive is now easy to navigate!

What makes JavaScript so different from other languages? Is it its dynamic nature? Its prototype-based funky inheritance? No. The most unusual thing for newcomers is how JavaScript programs handle the workflow. The program looks like a bowl of spaghetti. There is no start or end of the program. What we have here is a bunch of functions, which are called in response to some external events. In most cases we have no way to predict the order of these events. And we know that all callbacks are called from a single thread. Of course we know that it is not a nature of JavaScript but rather a limitation imposed by a specific container of JavaScript programs — web browsers. Majority of JavaScript code is written for browsers and now we have a perception problem. But let’s dig deeper to understand the problem better.

I just finished the first cut of the dojo.dnd 1.1 technical documentation . Let me use this post to remind you about the dojox.gfx 1.1 documentation . I hope I satisfied the curiosity of many developers, but the ultimate proof will be the number of simple questions on Dojo Forum . Let’s hope it will go down. And don’t forget that the Dojo Book has a DnD chapter too.

Both documents are hosted on Google Docs , and are “live” documents — as soon as I update the document it is updated for you too. I intend to update them on regular basis to track the current version.

Everybody knows that JavaScript is a multi-paradigm language, and it can be used to program functionally. Practically all functional idioms can be used directly: higher-order functions, recursion, closures, and so on. The recent resurgence of Functional Programming (FP) brings functional methodologies in the mainstream. FP fundamentals gave us a lot of powerful idioms: iterative functions, which can replace loops, list processing in general, function manipulations, and many other things, which helps us to keep our code small yet concise, more powerful, and more fun. Let’s take a look at how Dojo helps to leverage the functional paradigm in the Core, and in the extended DojoX package (dojox.lang.functional).

Introduction

Web 2.0 brought on us an onslaught of new server-side web frameworks, and made it OK to put some code on the client side as well. Yes, I am talking about Ajax . While elements of Ajax were available (and used) for a long time now, 2005 was the crucial year for this relatively old technology fueled by proliferation of modern browsers with proper support of JavaScript and HTML DOM, which, in turn, gave a rise to numerous Ajax toolkits. As always new exciting technology polarizes people — you can find ardent supporters of Ajax and a booing horde of naysayers. The latter crowd points out real and imaginary problems with Ajax. Some problems are real enough but stem from a misuse of the technology. One of them is a performance of a web application. In this article I will show how to improve a performance of a web application with Ajax and how to optimize an Ajax web application. Specifically I will show how to optimize a Dojo -based high-performance web application. I will use Django and Apache as examples of a server environment.

This is the 2nd part of Setting up tools on Windows — notes mostly for myself. (No, I don’t run Django with MSSQL under IronPython . Yet.)

In this installment I add more stuff to Eclipse, and set up my apps under FastCGI on Linux-based shared host (I use DreamHost).

Eclipse

This section was updated on 9/30/2006.

I already set it up with PyDev and Subclipse. Now I want to add HTML/CSS editing. And I want to do AJAX.

Yes, another Google SoC is upon us. I signed up as a mentor with Dojo and Django . Both projects are on the leading edge of new wave of web-based applications doing extremely cool stuff. I anticipate that some smart students will bridge both projects, but individual projects are fine too.

What is Google SoC? Read the FAQ . Who can apply? Any student anywhere in the world can apply. You don’t have to be Comp. Sci. major to participate. Why should I apply? You will gain a real world experience with open source projects on the bleeding edge of modern technology. Your code will be used by high profile projects (it will look spiffy on your resume). You will meet new people who "do it" instead of "talk about it". And you will earn $4,500 USD and a cool T-shirt as a proof of your participation.

It looks like this is the last update before upcoming beta release. Besides some minor bug fixes, it sports improved firewall configuration widget:

• Compact representation of port ranges.
  • Example: tcp 9000-9100 ⇒ mycomp
• Port redirection.
  • Example: tcp 8080 ⇒ mycomp:80

While the former improves on existing functionality, the latter implements totally new feature. It allows mapping external ports to different ports of internal computers. Redirection of ranges is supported as well. As a matter of fact it was the most requested feature so far.

Have you been frustrated lately by speed of web applications? Typically they have a lot of art, and structured into a nice set of JavaScript and CSS files. They look beautiful, aren’t they? But do you have the patience to wait them load? And proceed from step to step?

Of course, it is possible to prepare a web application to high-demand life: merge all stylesheets, and JavaScript files, and compress the result, structure your GUI in such a way that it is possible to combine all small images in one, and so on. This is very tedious low-level work. There are some tools, which can take care of the problem. For example, Dojo compressor merges JavaScript files and transforms the code to minimize its size. There are some tools to “compress” CSS. But the task of general optimization of your web app is up to you. Otherwise you will have a lot of frustrated users.

Django -Dojo alliance was finally announced to the world by our very own Jacob Kaplan-Moss :

Starting with version 0.92 (which should be out in a few weeks, Murphy willing), Django is going to bundle Dojo with the toolkit. Specifically as part of Django’s admin interface (but available to user apps as well).

Read all about it in Jacob’s post .

I am overjoyed to see such cool high quality open source projects are working together. Clearly it will make it easy to create kick-ass highly interactive web applications in Django and it will advance Dojo positions as a premier AJAX toolkit. It is a rare win-win situation for everybody involved including users of both frameworks.

It looks like nbd was able to find the problem, which plagued many people (including me) with QoS. You can find details in this thread on OpenWrt forum. Instructions on how to install QoS package can be found in this FAQ entry . Give it a whirl and don’t forget to thank Felix Fietkau (nbd ).

QoS was the biggest feature on my "wanted" list. It means now I can produce an OpenWrt GUI (webui) module to deal with it. It coincides well with release of Dojo 0.2.2 . But most probably I’ll be using a snapshot because guys added so much new stuff to Dojo preparing for Dojo 0.3 (widget release). Given the stability of OpenWrt GUI Homunculus Alpha release , I may upgrade new release to Beta status.

Brad Neuberg wrote a good article , which compares two different approaches to AJAX: thick client (e.g., Dojo style) and thin client (e.g., Prototype style). While it does a good job contrasting two approaches, I want to underscore that the underlying problem is a clash of two cultures between "local application" developers, and "web site" developers.

There is no doubt that local applications create the most satisfying end-user experience. Their typical weakness is in restriction of underlying data to local installation, which makes any collaboration impossible. "Connected applications" can help to alleviate this problem, but networking is hard in general and many local app programmers try to avoid it. They don’t have proper culture to do it, existing network APIs are hard to combine with GUI, and so on. In general they don’t get it.

Update on 11/25/2007: today this article presents mostly historical interest. Since Dojo 0.2 a lot of versions were published and many things were changed. At the time of this writing Dojo is at ripe 1.0. I had to disable all Ajax action in examples because I don’t use Dojo 0.2 anymore.

What is Filtering? It is a selection of items using some criteria (filter). In this tutorial I am going to filter documents of my blog (made with Django , of course) matching titles against user-specified substring. Later on I’ll talk about generalization of this approach.

In case you missed it too: TinyMCE 2.0.1 is out.

I am getting a feeling that everybody is trying to roll out something for Xmas. Hmm. Maybe I should do it too.

Dojo 0.2.1 is out. This is a maintenance release, which doesn’t change API but fixes some pesky bugs. Go and get it.

Many programmers have DIY attitude. It is understandable: they want to do new exciting stuff themselves. In some cases it is perfectly reasonable: exotic functionality, special requirements, performance enhancements, and so on. Sometimes incorporating 3rd-party library makes overall API inconsistent, which is bad especially for programming tools, or big projects.

There is a fine line between DIY and NIH , when DIY part is used without rational explanations. Of course, in some cases NIH is reasonable too, e.g., high price of acquisition of required 3rd-party tools, or intellectual property concerns.

Three weeks ago we had a discussion about Ajax support in Django, which resulted in "Ajax and Django" wiki page. A short recap: it lists a vague goal, some general considerations, and possible strategies; it scratches the surface of existing implementations (mostly RoR), existing third-party toolkits (Mochikit/Dojo), and related RPC-style and REST-style services. No code was produced, no consensus was reached, but now it is a part of Django’s Version One roadmap .

Finally I released WebUI 0.1 (Homunculus) alpha — AJAX-based web interface for OpenWrt made with Dojo ! Highlights of this release: 5 more applets including firewall configurator and more network settings. Now proceed to install the package and to read release notes.

The package is here: webui-0.1-alpha.ipk . You can install it using following command in OpenWrt shell:

ipkg install http://lazutkin.com/download/webui-0.1-alpha.ipk

Release notes:

• WebUI can be installed side-by side with webif (comes standard with OpenWrt White Russian RC4). To access it use following URL: http://your_router/webui.html.
• Five more applets are added to this release:
  • System: provides a menu for existing applets.
  • Firewall configurator: simple management of DMZ and port forwarding.
  • Hosts configurator: manages a list of static hosts (used by DNS and by Firewall configurator).
  • Ethers configurator: manages a list of static assignment of IP by MACs.
  • WDS configurator: manages WDS connection settings.
• General clean up of user interface:
  • More information is moved to tooltips.
  • Help is provided by tooltips.
  • Context-specific references to OpenWrt documentation.
• Tested on following browsers:
  • Firefox: works.
  • IE6: works.
  • Opera 8.50: doesn’t work.
  • Konqueror: doesn’t work.
• I decided to proceed with release in spite of Konqueror and Opera problems. I hope it will be solved later. For now use Firefox.
• As always I appreciate your feedback: openwrt [@] lazutkin [.] com.

New TinyMCE 2.0RC4 is out. It fixes numerous bugs, which never bit me. Is it going to be the last RC before actual release? Who know. Grab it while it is hot!