Erste JavaScript Köln Veranstaltung

Am 13. Juli findet das erste offizielle Treffen der CgnJS statt, einer Gruppe JavaScript Begeisterter aus Köln und Umgebung. An diesem Abend wird es zwei Vorträge geben: Jens Arps mit ‘JS auf mobile devices’ und ich halte ‘Developing web applications with jQuery UI’.

Vorher und nachher gibt es viel Möglichkeit zum Kennenlernen und Austausch rund um JavaScript. Das Treffen beginnt um 19 Uhr und die Vorträge um 19:30 Uhr. Das ganze findet in den Räumen der Coworking Cologne statt (Deutz-Mülheimer Straße 129, 51063 Köln) – dort fand auch letzten Dienstag ein kurzfristig organisiertes Node.js Meetup statt, mit Ryan Dahl als Vortragenden. Ein paar Fotos dazu hab ich bei Picasa hochgeladen, inkl. einem 3-minütigem Video, einem Ausschnitt aus Ryans Vortrag:

Für Updates könnt ihr CgnJS bei Twitter verfolgen. Hoffe man sieht sich nächsten Dienstag!

Nachtrag: Es waren 24 Leute da, hier auf ein paar Fotos auch zu sehen. Mein Vortrag lief gut (etwa 17 Minuten vorgetragen, dann nochmal so lang Fragen beantwortet), der von Jens Arps zu Mobile JavaScript war sehr interessant und hochaktuell. Konnte ich auch daran merken, das letztes Jahr im November meinem jQuery UI Vortrag niemand nach Mobile gefragt hatte, gestern hingegen war da eine Menge Interesse. Nächster Termin ist dann am 10. August.

Git fu: Updating your GitHub fork

GitHub with their web interface makes it really easy to fork a project, but it leaves you alone when it comes to updating your fork with the changes in the original repository. Its actually really easy with a few steps:

git remote add original git://url-to-original-repo

This adds another remote repository. You can use git remote -v to see your existing remotes. There should be “origin” already, pointing to your GitHub fork. You can use whatever name you like for the new remote repository, above I’ve used “original”.

git fetch original

This loads all commits, including branches and tags, from the specified remote repository, using the alias defined above.

git merge original/master

This merges all changes from the original master branch in your current branch, eg. your local master branch.

git push

By default, push pushes everything to your “origin” repository. Which brings your repo up-to-date. That’s it!

Autocomplete is dead, long live Autocomplete!

I’m finally deprecating the jQuery autocomplete plugin, about four years after its creation (which was actually a merge of two forks of another plugin). jQuery UI 1.8 was released in March, bundling the brand new Autocomplete widget and a worthy successor of my standalone plugin. The API is way more simpler while much more capable, eg. its now trivial to work with JSON. And thanks to Themeroller-support, the result looks a lot better.

Today I’ve finally finished the Autocomplete Migration Guide, which explains how to migrate from ye olde plugin to the new jQuery UI Autocomplete widget. It covers the various options and their replacements, if any. In a lot of cases, we were able to get rid of the options by providing better defaults or by restructuring the API, with the source option being the most prominent example.

The next major jQuery UI release should include the new Tooltip widget, paving the way to shut down another plugin on this site.

The Emperor’s Old Clothes

The Emperor’s Old Clothes is the title of a lecture by Charles Antony Richard (C. A. R.) Hoare, published by Communications of the ACM in 1981. A not well-readable PDF version of the text (found via Simon Willison and Wikipedia) is available on archive.org. The lecture itself was delivered on Obtober 27, 1980.

Here are a few quotes from the lecture, with a few comments. At the end I’m also providing the actual title-giving story for easier enjoyment, as the PDF is really not that great to read – a shame considering the great content.

My first task was to implement for the new Elliot 803 computer, a library subroutine for a new fast method of internal sorting just invented by Shell. I greatly enjoyed the challenge of maximizing efficiency in the simple decimal-addressed machine code of those days. My boss and tutor, Pat Shackleton, was very pleased with my completed program. I then said timidly that I thought I had invented a sorting method that would usually run faster than SHELLSORT, without taking much extra store. He bet me sixpence that I had not. Although my method was very difficult to explain, he finally agreed that I had won my bet.

And thus was born the quicksort algorithm.

The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself. […] A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to–they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

Thats an interesting point of view, and something that can be applied elsewhere. For example, Bruce Schneier writes a lot about how the lack of consequences makes a lot of security or privacy failures possible. If companies aren’t liable when “loosing” their users data, they have not enough incentive to prevent that in the first place.

I was eventually persuaded of the need to design programming notations so as to maximize the number of errors which cannot be made, or if made, can be reliably detected at compile time. Perhaps this would make the text of programs longer. Never mind! Wouldn’t you be delighted if your Fairy Godmother offered to wave her wand over your program to remove all its errors and only made the condition that you should write out and key in your whole program three times! The way to shorten programs is to use procedures, not to omit vital declarative information.

Considering discussions of static vs. dynamic languages, the interesting point here would be to define “vital”. Its easy to argue that vital has different meaning based on the context.

At last, there breezed into my office the most senior manager of all, a general manager of our parent company, Andrew St. Johnston. I was surprised that he had even heard of me. “You know what went wrong?” he shouted–he always shouted– “You let your programmers do things which you yourself do not understand.” I stared in astonishment. He was obviously out of touch with present day realities. How could one person ever understand the whole of a modem software product like the Elliott 503 Mark II software system?

I realized later that he was absolutely right; he had diagnosed the true cause of the problem and he had planted the seed of its later solution.

Now that is an intersting thought. Would you agree to that statement? Are you sure?

Keep in mind that the point is about understanding, not doing all the work by yourself. To be more concrete, this could mean that you should be able to look at all the code and understand every line of it. Or that you understand everything when one of the programmers explains to you what he just wrote.

Are you responsible for other programmers and would you pass these tests?

You know, you shouldn’t trust us intelligent programmers. We can think up such good arguments for convincing ourselves and each other of the utterly absurd.

I’d say that actually applies to most human beings. Think of how politicians can make up arguments for the stuff that they are convinced (or more likely, were convinced) is the right thing to do.

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. It also requires a willingness to accept objectives which are limited by physical, logical, and technological constraints, and to accept a compromise when conflicting objectives cannot be met. No committee will ever do this until it is too late.

Another essential point of view: Simplicity is key, and way harder to achieve. Break complex stuff down to the very basics, until nothing is left to remove (but no more), then build complex stuff based on that, instead of building complex stuff on other complex stuff.

When any new language design project is nearing completion, there is always a mad rush to get new features added before standardization. The rush is mad indeed, because it leads into a trap from which there is no escape. A feature which is omitted can always be added later, when its design and its implications are well understood. A feature which is included before it is fully understood can never be removed later.

What he says.

Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution.

Another argument for the importance of simple and powerful programming languages.

I knew that it would be impossible to write a wholly reliable compiler for a language of this complexity and impossible to write a wholly reliable program when the correctness of each part of the program depends on checking that every other part of the program has avoided all the traps and pitfalls of the language.

Something every programmer learns once working on a project above a certain complexity: You change on thing without having any idea on the impact on everything else. The less (inter-)dependencies the code has, the easier it is to determine the impact of changes. Also a major motivation for test-driven design…

Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way–and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.

The most important quote here bears repeating: The price of reliability is the pursuit of the utmost simplicity.

To have our best advice ignored is the common fate of all who take on the role of consultant, ever since Cassandra pointed out the dangers of bringing a wooden horse within the walls of Troy.

Nothing to add.

Now, the actual title-giving story that Hoare tells at the end of the lecture. Copied from the PDF linked above, © ACM 1981.

The Emperor’s Old Clothes

Many years ago, there was an Emperor who was so excessively fond of clothes that he spent all his money on dress. He did not trouble himself with soldiers, attend banquets, or give judgement in court. Of any other king or emperor one might say, “He is sitting in council,” but it was always said of him, “The emperor is sitting in his wardrobe.” And so he was. On one unfortunate occasion, he had been tricked into going forth naked to his chagrin and the glee of his subjects. He resolved never to leave his throne, and to avoid nakedness, he ordered that each of his many new suits of clothes should be simply draped on top of the old.

Time passed away merrily in the large town that was his capital. Ministers and courtiers, weavers and tailors, visitors and subjects, seamstresses and embroiderers, went in and out of the throne room about their various tasks, and they all exclaimed, “How magnificent is theattire of our Emperor.”

One day the Emperor’s oldest and most faithful Minister heard tell of a most distinguished tailor who taught at an ancient institute of higher stitchcraft, and who had developed a new art of abstract embroidery using stitches so refined that no one could tell whether they were actually there at all. “These must indeed be splendid stitches,” thought the minister. “If we can but engage this tailor to advise us, we will bring the adornment of our Emperor to such heights of ostentation that all the world will acknowledge him as the greatest Emperor there has ever been.”

So the honest old Minister engaged the master tailor at vast expense. The tailor was brought to the throne room where he made obeisance to the heap of fine clothes which now completely covered the throne. All the courtiers waited eagerly for his advice. Imagine their astonishment when his advice was not to add sophistication and more intricate embroidery to that which already existed, but rather to remove layers of the finery, and strive for simplicity and elegance in place of extravagant elaboration. “This tailor is not the expert that he claims,” they muttered. “His wits have been addled by long contemplation in his ivory tower and he no longer understands the sartorial needs of a modern Emperor.” The tailor argued loud and long for the good sense of his advice but could not make himself heard. Finally, he accepted his fee and returned to his ivory tower.

Never to this very day has the full truth of this story been told: That one fine morning, when the Emperor felt hot and bored, he extricated himself carefully from under his mountain of clothes and is now living happily as a swineherd in another story. The tailor is canonized as the patron saint of all consultants, because in spite of the enormous fees that he extracted, he was never able to convince his clients of his dawning realization that their clothes have no Emperor.

Flattr this