Eugene's Blog

I can't believe it's blog!

OOP in JS slides

Finally: my open source JavaScript project DCL is built on ideas described in this article. Available for node.js and modern browsers, it implements OOP with mixins and AOP at "class" and object level. Read documentation and background articles on, clone its code on, and follow @dcl_js.

Once again I was invited in ClubAjax to speak about JavaScript. This time I did a presentation based in part on my previous blog post OOP and JS. Slides and talk revisit OOP, mixins, AOP, chaining, and other related techniques I discussed in my blog. Of course, OOP deficiencies were discussed at length too. I suggest to look at slides and read the blog post – it will give you a better picture.

I feel that such basic programming techniques are essential for everyday work. Done right they provide a solid foundation for our projects. That’s why I intend to build the next generation of OOP, AOP, FP libraries building on existing proven technologies.

Direct link: OOP in JS.

OOP and JS

Finally: my open source JavaScript project DCL is built on ideas described in this article. Available for node.js and modern browsers, it implements OOP with mixins and AOP at "class" and object level. Read documentation and background articles on, clone its code on, and follow @dcl_js.

Almost any Java programmer, who starts to study JS groking its OOP facilities and a dynamic nature of JS, thinks that they can be greatly improved and starts its own OOP library/helpers. Majority of them left forgotten when their authors learn more and more details and patterns of JS, yet some grow to fruition and being marketed. This article is dedicated to such people.

The goal of this article is to go over common OOP techniques suitable for JS, their pitfalls, problems, and trade-offs.

Using Dojo Rich Editor with Django’s Admin

Many years ago I decided to replace plain text areas in Django’s Admin with rich text editor, so I can edit HTML on my blog using WYSIWYG. Six (yes, 6) years ago I looked around and selected TinyMCE. Over time it turned out that I was forced to upgrade TinyMCE and the link script I had because new browsers continue breaking my rich editor editing. Finally it stopped working again in all modern browsers, and I decided that enough is enough. It is time to replace it. This time I settled on Dojo’s Rich Editor hosted on Google CDN — simple, functional, less work to set up.

Exciting JavaScript Part II

This month I continued my presentation at ClubAJAX. Last time I did a survey of what is available in JavaScript, and concentrated on object-oriented (OOP) and aspect-oriented (AOP) techniques. This time I continued the survey, and talked about functional programming (FP), and domain-specific languages (DSL). And as promised I touched the code generation facilities too.

I suggest to read the first part before.


Direct link: Exciting JavaScript – Part II.


Today at dojo.connect I did a presentation “RAD CRUD”: rapid development of form-based applications. It continues my other presentation “CRUD with Dojo”, but it is more in depth, targets Dojo developers, and contains some advanced material.

Direct link: RAD CRUD.

Exciting JavaScript Part I

I was asked to talk about advanced JavaScript techniques at the last monthly meeting of ClubAJAX — monthly get-together of Dallas-area JavaScript programmers. Instead I ended up talking about leveraging cool JavaScript features to implement well-known programming techniques and paradigms: OOP, AOP, FP, and so on.

Unfortunately I couldn’t finish in time, so I did a tour of some language features, and talked about OOP and AOP. The rest (I plan to do FP, code generation, and DSL) will be covered later.

So I split my slides into two parts and today I publish the first part. In a month or so, when I deliver the second part, I’ll publish the rest.


Direct link: Exciting JavaScript – Part I.

CRUD with Dojo

My presentation at ClubAJAX got off to a rocky start: I was let in the building 40 minutes after I was supposed to start the presentation. Everybody waited patiently. Thank you guys! As promised I publish slides along with relevant links (I had to skip most of planned demos).

Here is my presentation on SlideShare: CRUD with Dojo. The original presentation can be seen on Google Docs: CRUD with Dojo.

Adding django-shorturls

Time to time I sync my blog software to the Django trunk and introduce small enhancements. Some of them visible to my readers, some of them are just for me. This time after reading Simon Willison’s post on rev=canonical I decided to add short URLs to my blog as well. This is a convention to provide custom short URLs managing the mapping on your own web site. In my opinion the idea is very cool.

To be completely honest: while I like the idea I am not completely sold on its implementation. For example Mark Nottingham advocates a different way to provide the same information: rel=shorturl (via Simon’s post), and it sounds more logical to me. Oh, well. The first approach is easy to try: Simon coded it for Django, and Jacob Kaplan-Moss even created a full-fledged Django application out of it available both on github and on pypi — with this kind of availability I had no excuse not to try it. And rev=canonical can be used together with rel=shorturl, if I want to add it later, using the same universal django-shorturls application.

So after buying domain I armed myself with Simon’s article and Jacob’s git repository, and set to add it to my blog. And while everything about django-shorturls is super-simple I managed to hit the brick wall repeatedly in all possible ways (don’t judge me too harsh — I decided to do it at night not thinking clearly). Below you will find a list of gotchas for myself and others:

  1. While the application is called “django-shorturls”, when it is installed it is available as “shorturls”. Simple enough.
  2. While the application is available as “shorturls”, its template tag library is called “shorturl” (no s at the end). Somehow my fingers typed “shorturls” in all templates — probably my tired brain expected that the major piece of functionality is called exactly as the application itself. It looks like Jacob was confused like me and typed it both ways in examples of the readme file.
  3. The main tag is called “shorturl” logically enough. Probably that’s what gave the name for the template library.
  4. After coding everything up (literally 5 minutes + stupid gotchas above) I’ve noticed that in some places I am getting nothing instead of an expected URL value. I figured that something is wrong and Django famously silenced errors in templates. After frantic attempts to debug the problem I’ve noticed that I misspelled a name of my model in SHORTEN_MODELS settings. The stupid typo led to exceptions in the template tag, which was silenced, and no other diagnostics were given.
  5. Now everything works as expected per Jacob’s readme, yet no cigar — my blog generates URLs like this:, but it doesn’t process them. Instead it expects URLs like this: /short/dBh. WTF? There is nothing about it in the readme. But Jacob starts it by referencing Simon’s article, and if you read it to the end you would know that it requires a little help from a web server: a URL rewriting. Simon does it with nginx.
  6. I love nginx! In fact I use it to drive my web site. Finally I got lucky and can use his recipe directly! I copied Simon’s code and… it doesn’t work. The close inspection found the problem: django-shorturls expects incoming short URLs to be anchored at /short/, but Simon’s code rewrites to /shorter/. An easy fix when you know the problem.

While I am embarrassed to have so many mishaps with a simple application, I hope people will learn from my mistakes.

The last problem happened mostly because Simon’s code intimidated me: it uses some fancy proxy_pass, yet sets proxy_redirect to off. I don’t understand what it does, all proxy business feels slow. Most probably it targets a setup with multiple servers. I use just one physical server for everything, so I rewrote his fancy redirects “by the book”. Here are the relevant parts of nginx.conf:

# processing the "short" domain
server {
  listen 80;
  # both and versions are allowed
  location =/ {
    # the root is mapped to my main site
    rewrite (.*) permanent;
    return 444;
  location / {
    # the rest is rewritten as /short/
    rewrite (.*)$1 permanent;
    return 444;

# suppress in favor of
server {
  listen 80;
  rewrite ^/(.*)$$1 permanent;
  return 444;

# the main web site
server {
  listen 80;

  location / {
    # let's call Django using FastCGI
    root   html;
    index  index.html index.htm;

    include fastcgi_params;

    fastcgi_param PATH_INFO $fastcgi_script_name;
    fastcgi_pass_header Authorization;
    fastcgi_intercept_errors off;

  # the rest maps static resources

Now I am happy with the result. Want to try it out? Just grab the shortening bookmarklet from the original Simon’s post and run it on this page.

You should be aware of some restrictions: django-shorturls provides a two-way mapping using a numeric primary key of an underlying object. If your primary key is not a number, it will not work. Another restriction: your URL should match some unique object. It means that there is no easy way to give short URLs to lists of objects, different views of the same object, or any other derivatives.

In practice these restrictions are minor. For example, this blog fits the scheme almost perfectly, and I am happy to trade the unnecessary flexibility for the short and sweet code. But if you have a lot of web pages like described above, you should think about more sophisticated ways to map URLs to their shorter alternatives.