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

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's next? The next target is Dojo 1.2, which will see a lot of enhancements. In my crystal ball I can see myself diligently working on Charting with other volunteers. New graphics improvements and  new dojox.lang modules are planned too. While we are busy pushing for 1.2, the maintenance release (Dojo 1.1.1) is planned as well.

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 this 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.

If you found any mistakes, typos, omissions, or just unclear wording, please let me know. If you know a good trick to do with those packages, do not hesitate to share it on Dojo Campus as an article or a "cookie".

My next documentation goal is dojox.charting. Stay tuned!

F/OSS is a phenomenon of the modern life. But what makes it successful? Ben Laurie is convinced that Open Source Is Just Economics. I beg to differ. Yes, it does make sense for several companies to gang together and develop something jointly. And they did it for years without the open source. Not always successfully, but they did it. For example, IBM has cooperated with Microsoft on OS/2 back in the days, and there are more examples. What makes OSS so special? Ben's post has links to other possible reasons. But I think I know the answer: global meritocracy in informal communities— this is the mythical secret ingredient, which holds the whole system together.

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).

I published first day pictures from PyCon 2007. They are raw, unedited, I didn't put descriptions yet. You can recognize Django guys, people from multiple Python web frameworks, and, of course, the BDFL with OLPC. But why wait for pictures to be prepped? Dig in while they are raw and fresh:

Yes, this is Steve Holden sporting a Django t-shirt.

Update: I added pictures from the 2nd day.

Update #2: I added pictures from the 3rd day. Now I can go and put some names and descriptions like I did last year.

How long does it take to do a project? Software developers are asked this very question on regular basis. This is how every project begins. Why is it important? Because "time is money" and many software projects are priced mostly by time spent on the project. "We will take your project estimate in hours, multiply them by your rate in $/h, and we have our price." Ask any consultant or IT staffer about that. Let's look at estimates in the Real World^(tm).

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).

Today I converted three web sites to the latest Django's trunk formerly known as the magic-removal branch. It was a very positive experience in general. New Database API with lazy database queries (courtesy of QuerySet) rocks! Direct interaction with model classes allows doing a lot of things much simpler than it was before. A lot of small improvements, which makes a big difference like explicit template extensions (use whatever is appropriate for your content), more transparent new Admin inner class, natural overriding of model methods (no more _pre_save() and _post_save() hooks!), and, of course, no more pluralization guessing.

I encountered exactly three small problems during the conversion:

• RemovingTheMagic is a formidable encyclopedia of changes but it is difficult to use it as a cheatsheet for the conversion, because it is not organized by functional areas, and requires modifying files in several passes. I filed an enhancement ticket #1786.
• I had small problems modifying users and groups after the conversion. Instead of change screeens I started to get 404 pages without any helpful traces. I had to regenerate permission tables. An enhancement ticket #1787 shows how I did that.
• I found get_list_or_404() being less flexible than before. I used to pass in "__ne" and "order_by" kwargs, which I cannot do anymore, because they are not recognized as proper keywords. I had to do it manually with exclude() and order_by(), which was not a big deal because get_list_or_404() has a very small body.

In general the whole process was painless and left me completely satisfied with the outcome and code changes. Thanks to all contributors, who made it possible!

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.

We already started evaluating incoming proposals. You have to submit your proposal before 17:00 PDT on May 8, 2006.

Now some tips:

• You should "see" what you are going to do:
• Some sketch of general design will be very helpful.
• Outline of your timeline (conforming to SoC timeline) would be good too.
• It's okay, if you still need to fill the gaps in your vision of the project — both projects have vibrant communities, and mentors are here to guide you.
• We don't want you doing some insignificant work on remote outskirts of our projects. We know it is no fun. We want you to do something interesting, which can be immediately useful. So I suggest: try to resolve core problems, be bold and innovative.
• Try to see how you can improve the system, instead of how to use existing features. We will prefer core improvements over projects built using our frameworks. The former will benefit everybody, when the latter will be used by smaller group of people. Obviously we are interested in your code making the biggest positive impact.
• Aim high. Don't be afraid that the problem is bigger than SoC timeline. We can always scale it down, or stage it.
• If you came up with a small scope project, it is okay too. Try to bundle them until we have a proper chunk of work.
• If you need some ideas to get you started, don't fret: of course, we have suggestions. And we published them for Django, and for Dojo.

By popular demands I am publishing pictures of my JTAG, which I made to revive a wireless router some time ago. Just click on the picture below to see it in all ghetto-style glory with some explanations of my "design decisions".

You can see that it is very basic. It was made in ~3 minutes and costs ~$6 (the most expensive part was the cable — $3.99). It was assembled according to this diagram. You can find a full description of details here.

Let me give you one more definition of what computer programmers do: they design, build, and maintain complex systems. In many cases computer programs are more complex than "Hello, world!" examples. Way more complex. I am talking about the systems

• that have more branching possibilities than atoms in the universe.
  
• that cannot be verified using any formal methods in any practical timeframe.
  
• that cannot be tested with 100% code coverage in our lifetime.
  
• that cannot be completely understood in all details by their creators.
• that can handle real life requirements.

OpenWrt has officially terminated Sveasoft's license citing blatant violation of the GPL. For more details go to OpenWrt's forum: Unbelievable. It's getting quite hilarious. For example you can "learn" that the GPL is derived directly from "the economic and political theories of Karl Marx".

In general it is so sad to see such abuses. It is not hard to comply with the license. If you don't like it, don't use the GPL'd software in your product. It is as simple as that.

It is okay to use the GPL'd software in commercial products, but you have to offer the GPL'd sources, and if you modified them, you have to publish your modifications as well. If parts of your product are proprietary, isolated, and not based on the GPL'd code, keep them to yourself.

And don't forget to acknowledge the work of others even if the license doesn't force you to do it — it is the common courtesy, which should be followed by any reasonable human being.