Zum einen ein Streitgespräch mit Günter Wallraff, zu dessen Buch Aus der schönen neuen Welt (ebenfalls sehr empfehlenswert) und den zugehörigen Film, Schwarz auf Weiss. Auch die am Ende erwähnte Titanic-Satire dazu lesen!

Dann wäre da ein Artikel zur Sozialdebatte, auch wenn in der URL Armutsdebatte steht. Es sollte schwer fallen, dem uneingeschränkt zuzustimmen, aber als Denkanstoß sehr gut.

Wieder was ganz anderes: Der Bericht von Jemand, der wegen das Papstes aus der Kirche austreten will, und dies zunächst mit Pfarrern aus ganz Deutschland bei der Beichte bespricht.

“…or the terrorists win.”

Anyway, whenever someone pulled best practices out of his sleeve, I want to tell them “There are no best practices!”. But lacking good arguments to back me up in a discussion, I usually wouldn’t. Until now!

This article simply called No Best Practices does a good job of explaining why the idea of a best practice is wrong on several levels. For a start, practices depend on context:

There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice.

The author, James Bach, later suggests various alternatives:

Simple, honest alternatives are available:

• “Here’s what I would recommend for this situation.”
• “Here is a practice I find interesting.”
• “Here is my favorite practice for dealing with {x}.”
• “{Person X} attributes {practice Y} for his success. Maybe you’d like to learn about it.”

He even covers various responses to his arguments and his replies to them:

“This practice represents a consensus among industry leaders.”No it doesn’t. You’re just making that up. Industry leaders aren’t able to agree on anything much of substance. I know this because I am an industry leader (based on the fact that some people have said so), and other leaders more often disagree with me instead of obeying my commands. I am influential within a certain clique. The software testing industry is made up of many such tiny cliques, each with its own terminology and values.Whenever people tell you that there’s a consensus in the industry, what they probably mean is that there’s an apparent consensus among those people in the industry whom they happen to respect. The best practice for dealing with discordant voices is: just ignore them.

There is more good stuff in the comments, highlighting Jame’s focus on testing:

I would suggest that there is at least one practice which ALL Developers everywhere over the world need to follow all the time:

[James' Reply: I don't need to see your idea to know that it can't fulfill the claim you made, above. What does "all the time" mean? What does "all developers"? Have you really considered what ALL means?]

Test Early, Test Often. I know enough people that don’t test at all that this isn’t just a way of life, and they NEED to have it drilled into them.

Otherwise, good article.

[James' Reply: So, if I develop a sandwich, I need to test the sandwich? How much should I test it? It's a bit like Zeno's paradox, isn't it? I will never eat the sandwich because I am never done testing the sandwich.

As you come to understand testing, you come to understand the impossibility of complete testing, which leads then to the necessity of making tradeoff choices. These choices are very interesting! Telling someone they must test all the time does not help to highlight the choices that must be made.

Also, I have to mention the other big issue in your idea of a practice: "Test Early, Test Often" is not a practice. You have specified, intead, an amorphous family of potential practices. How early is early? How often is often? What is testing? I don't know what to do to follow your "practice". I don't know how to avoid screwing it up. If this is an acceptable statement of a practice, then why not simply say "Be Virtuous"? After all, virtue is a catch-all. If people just "did the right thing" they would obviously do the right testing at the right time.

We don't exhort people to be virtuous, because it is not helpful advice. I submit that test early, test often is also not helpful when offered as a commandment. It is more helpful when offered as a heuristic, which is not in any way the same as a best practice.]

My conclusion: Whenever you encouter a “best practice”, try to take it apart. What’s the context? Is it really a practice, oder just a goal? Is there anything specific of value, or just generic and ambigious rhetoric bubble?

Can you make your home absolutely safe? No; that’s the bad news. Can you do things to dramatically reduce the risk of having bad things happen to you and your family? Yes; that’s the good news. But the things you can do generally have more to do with protecting against accidents than protecting against attackers.

When people think of keeping their families safe, they mostly think of protecting them against intruders. They think of preventing the kinds of horrible things that make the front pages of newspapers. But those aren’t that real risks. Horrifying as those crimes are, they are not what kill most kids. The leading causes of death to children are automobile accidents, gun injuries, drowning, and suicide. The likelihood of each can be reduced greatly, and by means that everyone already knows. Buckle up your kids. Lock up your guns. Pay for swimming lessons and teach your kids to swim. Pay attention to your children’s state of mind. Don’t tolerate abuse.

Still scared of a creazed stalker breaking into your house and kidnapping your children? That’s okay, but make sure you know that the fear is in your mind and not based on the real risks. The best way to protect against intruders in your home is to turn on the bathroom light. Don’t beliebe me, believe the world’s smartest ex-burglar, Malcom X: “I can give you a very good tip if you want to keep burglars of your house. A light on for the burglars to see is the very best means of protection. One of the ideal things is to leave a bathroom light on all night. The bathroom is one please where somebody could be, for any length of time, at any time of the night, and he would be likely to hear the slightest strange sound. The burglar, knowing this, won’t try to enter. It’s also the cheapest possible protection. The kilowatts are a lot cheaper than your valuables.”

Or get a dog…
Now that’s a security trade-off.

Macht aber nichts, und vielleicht ändert sich das noch, da der Artikel jetzt auch online verfügbar ist. Der Artikel ansich ist derselbe, praktischerweise sind aber alle Verweise direkt als Links realisiert. Die Beispiele sind leicht in den eigenen Editor kopierbar, sogar der sonst nur auf der Heft-CD verfügbare Quellcode der kompletten Beispiele ist als Download am Ende verlinkt.

Das erwähnte Buch, “Learning jQuery : Better Interaction Design and Web Development with Simple JavaScript Techniques” ist mittlerweile erschienen und zusammen mit dem “jQuery Reference Guide” empfehlenswert.

Feedback zum Artikel, jQuery allgemein oder zu einem meiner jQuery-Plugins ist höchst willkommen!

Whether the motivation behind making their labors freely available is a matter of seeking recognition, resume building, free advertising for other services, bragging rights, or just plain old-fashioned altruism, we can gratefully take advantage of these tools. jQuery is one such tool.

I think altruism is very far away from the true motivation in most cases. Most free and open source software I can think of is done because someone needed it anyway. And instead of just writing that little tool you needed that one day, why not release it to the great public under some appropiate license? If the tool is worth its code its quite likely that someone else has use for it, too. And because they don’t have to pay anything and can read and modify the source code, its very easy for them to contribute back whatever they can. And using that feedback is again helping the initial author.

You can find good hints at the eat-your-own-dogfoot principle and where it was applied and where not in a lot of open source products. Consider the update manager in Eclipse. To start with, its hidden under the Help menu. You have to manually copy&paste links from update sites into it. And you always have to choose “search for new features to install” even if you want to look for updates, because looking for updates most likely never finishes and yields no result after bugging you 20 times for a mirror to choose from a list. That is the stuff the developers (of Eclipse) mostlikely themselves don’t use, and therefore don’t care about.

On the other hand, Eclipse’ Java Development Tools is state-of-the-art: I’m using it now for almost three years and yet I find new helpful features everyday. Its refactoring support alone is worth some gold. Ever wanted to introduce a new parameter in an interface method and its four implementations? Its something very ugly when doing by hand, with Eclipse its simple as hell: Refactor -> “Change method signature”, and you’re nearly done. Learned how to use that just today.

Eclipse is backed by a big corporation (IBM) and a daily growing list of both small and big eclipse foundation members. This isn’t the case on projects like jQuery. When asking John Resig about his motivation for releasing jQuery he answered:

I’d have to say Altruism + Recognition – resume building was a nice side effect, but I didn’t think about that

And he added:

I mean, I guess if you’re wondering why open source vs. “closed source” (license-restricted). I guess, technically one could get recognition from either, but I don’t like restrictive software. I’ve grown up using open source, and benefited so much from it. It just doesn’t make sense to me to release closed software. I don’t see how it could possibly benefit me, or help others.

So for me, restricted software just doesn’t feel right – whereas open source feels very good. Helping people and feeding back into the community is really what does it for me. Seeing it do well is a nice side effect – I mean, on my web site alone I’ve released over 70 pieces of open source software. A couple have done really well – only one really took off.

So I definitely wasn’t expecting recognition, but it was nice that it happened.

As always he has some good points to argument with. I spent and keep spending a lot of time working on my jQuery plugins because I know (at least now) that I will be most likely developing web applications in the next years (though so far they are all 100% corporate intranet applications, but still running in browsers). And its great to use features of your own plugins in your own project that someone else contributed. Even questions for support help a lot, because you know where you have to improve APIs and examples.

Releasing JavaScript code as opensource is somehow natural anyway. Reading JavaScript code in the source of other’s website has been done for years now, and giving the code a property license to motivate “readers” to give feedback and contribute has helped a ton to improve the overall quality of written JavaScript by several magnitudes.

Currently I’m investigating ways to leverage those plugins on the server-side too, which is especially interesting when considering the validation plugin. John’s work on implementing a browser environment in Rhino is amazing. It already is able to run the full jQuery test suite, and the possibilities for building web application frameworks based on jQuery are daunting.

I hope I can also opensource some of the framework code I’m developing at work some time in the feature. There is already some really nice JSF and Spring related code in our repository…

Of course the alternative to building your own framework is to use an existing one. This approach yields some important advantages, amonst them the “given enough eyeballs, all bugs are shallow” principle.

Lets see how well the validation plugin currently performs on the points listed in the article:

1. Use a form validation framework or a form validation library

Check.

2. Focus on solving the big validation problems

As soon as you start developing and implementing your validation, it is easy trying to address all potential validation that is needed for all types of input. My advice is to try to catch 75-85% of the potential user input errors in the front-end validation. Trying to catch all will lead to the following:

• Bloated code, your framework will grow too large
• More or less impossible to test client side validation as there are too many combinations of validation that can go wrong
• Business rules will move to the front-end.(More on how to avoid this by using Ajax later)

Well, bloated code is a problem I tried to address with lots of refactoring. The current codebase has 1446 lines (about half of it being inline documentation). A few weeks ago Dan G. Switzer took a look at the plugin and was able to provide excellent help on specific code-related problems within a few hours.

About testing: The current testsuite for the validation plugin runs 65 tests with over 350 assertions. jQuery’s testsuite runs about 500 assertions. I seems to have a good code coverage, as I added tests for all occuring issues whenever possible. Regression issues are quite likely to be catched by the testsuite, as well as it helps a lot while developing.

Testing against browser events and with AJAX is still a very difficult task, even with the AJAX support in jQuery’s testsuite.

About business rules moving to the front end: Thats more of a design and architectural problem. Avoiding that using AJAX gets supported with the upcoming 1.2 release.

3. Do Form Validation before form is submitted

The message here is to validate when the user inputs something, instead of waiting for the submit event. Pre 1.0 versions allowed you to specify a single event to check individual elements, eg. blur or keyup. That worked in some cases, and was disturbing in other cases, where the user clicked on an input and was welcomed with an annyoing error message. To address those issues, a more sophisticated system was released in 1.1. Basically the plugin waits with validation until the user blurs a field where he entered something incomplete. If the field is already marked invalid (eg. after an attempt to submit an invalid form), all elements are validated on keyup (textinputs) or click (checkbox, radio). The current implementation isn’t perfect yet, and of course feedback is appreciated.

4. Use Ajax Form Validation for business data input

A small teaser for the AJAX validation in 1.2:

$("#myform").validate({
  rules: {
    username: {
      required: true,
      minLength: 2,
      remote: "users.php"
    }
  },
  messages: {
    username: {
      required: "Enter your username",
      minLength: "At least 2 characters are necessary",
      remote: String.format("The name {0} is already in use")
    }
  }
});

The API allows you to use the same declarative style for remote validation as you are used to use for local validation. String.format creates another function that is later called with the value the user entered, resulting in something like “The name asdf is already in use” as the error message.

Check the AJAX validation preview for more details.

5. Do extensive testing of your javascript form validation

That is covered above.

6. Rewrite input data to valid formats

Now this is an interesting point. Basically the idea is to accept “20070515″ as a valid date, transforming it into “2007-05-15″ for validation. I haven’t seen any specific requests for a feature like this, so if anyone is interested, let me know. Meanwhile a good idea may be to use the masked input plugin to help and assist the user typing the correct format.

7. Attach javascript form validation late in the design process

That is a very good recommendation. jQuery helps a lot with this, due to its unobtrusive nature. Design your form without any JavaScript at all, and add it later, improving the user experience (UX) as much as possible.

8. Make the script i18n- and l10n-compatible

In other words: Avoid hard-coded strings, instead make it as easy as possible to replace them with the current locale.

The validation plugin allows you to translate all default messages by just overwriting them. Its easy to include a file after the plugin file that contains something like the following:

$.extend($.validator.messages, {
  required: "Eingabe nötig",
  email: "Bitte eine gültige E-Mail-Adresse eingeben",
  ...
});

That approach works quite well. You can gather other translation in the same file, for example labels for the datepicker.

To include the proper right translation file for the user’s locale is then a mere serverside issue.

Other problems, eg. different number or date formats, can be covered by writing custom methods, or overwriting the default ones (in $.validator.methods). Methods for german date and number formats are provided by default: date (default JavaScript Date format), dateISO (1990-01-01 or 1990/01/01), dateDE (01.01.1990 or 2.12.2012) and number (100,000.59) and numberDE (100.000,59) are available. Though currently none of those validates any ranges, eg. 0001-13-50 is also a valid iso date.

9. Add callback functions to validator framework

The most important callback function the validation plugin provides is the submitHandler. It is called when a valid form is submitted, allowing you to eg. submit the form via AJAX. Others are available like errorPlacement, to customize where error messages are inserted into the DOM, eg. for table layouts.

In 1.2 a callback for invalid forms gets added, called each time the user submits a form and it is invalid. So far the showErrors callback could be used for that, but that one gets also called each time is single element is validated. The new callback can then be used to update a message like “There are 6 issues in the form below”. Showing and hiding such a message can be handled using the existing errorContainer options.

10. Make your framework/library extensible

The most important point to extend the validation plugin with your own stuff is $.validator.addMethod. It allows you to add any validation method you need. By keeping your own custom methods inside your own files it is easy to update the plugin itself.

Its quite likely that the first approach to AJAX validation will evolve into $.validator.addRemoteMethod, providing all the necessary boilerplate code for remote AJAX methods, but allowing you use any required protocol. It won’t matter if you use get or post, send a single value or the whole form to the server, and if the server returns only true or false, or an error message to display, in whatever format you prefer or need to work with. Of course it would require a bit more work to implement the method, but provides a great flexibility. Your feedback on this is essential, as I avoid to randomly guess what you may need.

I hope this gives a good idea about the current status of the form validation and its progress and should help with the descision to use it or not.

Cross-posted on the jQuery blog

Nun könnte es enorm helfen, die zweite Frage zu klären, um dann auch die erste zu beantworten.

Im Laufe meiner Bewerbungen Anfang letzten Jahres ist mir einigermaßen klar geworden, welche Bereiche der IT es gibt. Ich unterscheide der Einfachheit halber zwischen zweien: Consulting und der ganze Rest.

Das erste Beispiel, das mir bei “dem ganzen Rest” immer einfällt, ist die IT-Abteilung von Firma XYZ. Firma XYZ ist eine Autoteilezulieferer, stellt also z.B. für Opel oder Mercedes Metall- und Plastikteile her, die später zum Zusammenbau eines kompletten PKWs verwendet werden. XYZ hat mehrere Hundert Mitarbeiter und braucht natürlich eine entsprechende Personalverwaltung. XYZ kauft natürlich Werkzeuge (gern auch mal im Tonnenbereich für ein Werkzeug) und alle möglichen Rohmaterialien ein. Benötigt also ein Warenwirtschaftssystem, z.B. SAP. All die Mitarbeiter, die mit SAP arbeiten, benötigen ihren eigenen PC, der gepflegt werden muss. Dafür gibt es zwar wieder Hilfsmittel, mit denen man zentral ein ganzes Netzwerk administrieren kann, z.B. über Nacht Rechner runterfahren und updaten, aber auch diese müssen installiert oder beherrscht werden.
Alles in allem also reichlich Arbeit, um eine komplette IT-Abteilung Tag und Nacht auf Trab zu halten. Da bei XYZ natürlich in drei Schichten gearbeitet wird, muss wahrscheinlich auch nachts noch jemand aus der IT zur Stelle sein, oder wenigtens auf Bereitschaft.

Ich selbst arbeite jetzt seit einem Jahr im Consulting-Bereich, und bin damit auch sehr zufrieden.

Nehmen wir mal Consulting-Firma LLK als Beispiel: Neben zwei Mitarbeitern kümmert sich auch einer der beiden Geschäfsführer um den Vertrieb, der Kunden und Projekte ranholt. Drei Projektleiter managen diese Projekte, schreiben Angebote und verteilen Projekte an die 20 Entwickler. Sieben der Entwickler arbeiten allerdings nicht in den Büros von LLK, sondern sitzen Vollzeit bei verschiedenen Kunden vor Ort. Einige zur reinen Entwicklung, andere mehr in beratender Funktion. Von den 20 Leuten sind auch vier Subcontractors, kurz Subco, auch bekannt als Freelancer oder freie Mitarbeiter. Diese arbeiten meist nur an einzelnen Projekten mit, bekommen nicht die Sicherheit einer Festanstellung, dafür aber aufgrund ihres projektbezogenen Expertenwissens potenziell bessere Bezahlung. Ansonsten gibt es noch Mitarbeiter, die sich um Administration und Buchhaltung kümmern.

Die ersten Projekte von LLK waren alle Maßanfertigungen: Ein Kunde benötigte eine bestimmte Anwendung, diese wurde für ihn entwickelt und gepflegt. Bis auf die Erfahrungen, die zwischen den Entwicklern ausgetauscht wurden, gab es keine Synergien mit anderen Projekten. Nach ein paar Jahren wurde ein bestimmter Typ von Anwendungen ausgemacht, den viele Kunden von LLK benötigen. Es enstand ein Produkt. Ein prominentes Beispiel für ein Produkt wäre z.B. Microsoft Word. Weitere Jahre später hat LLK eine ganze Reihe von Produkten entwickelt und daraus eine Produktlinie gemacht. So wurde auch aus MS Word oder Excel die Office Produktlinie. Oder aus diversen Einzelprodukten das Komplettpaket SAP.
Doch warum überhaupt Produkte? Es ist doch viel schwerer eine Anwendung zu entwickeln, mit denen viele Kunden zufrieden sind, als eine Anwendung zu schreiben, die auf die Wünsche eines einzelnen Kunden angefertigt wird. Mal abgesehen, das diese Ansicht bereits zweifelhaft ist, entscheidend ist der Kostenfaktor: Das Design und Entwickeln eines PKWs verursacht genauso Kosten wie die Produktion jeder einzelnen Instanz dieses Modells. Bei der Softwareentwicklung hingegen kostet die Duplizierung nichts. Eine einmal entwickelte Software kann beliebig oft verkauft werden, ohne nenneswerte Produktionskosten für jede einzelne Kopie. Dank Breitbandinternet wird heutzutage ohnehin häufig direkt über das Internet verkauft und verteilt, sei es eine Webanwendung als war-Datei oder PC-Spiele per Steam.

Was mich am Consulting reizt, sind die ständig wechselenden Herausforderungen. Heute entwickelt man noch J2EE-basierte Portlet-Webanwendungen, morgen auf Basis von Eclipse RCP, übermorgen muss es auf beidem laufen… Für kein Projekt steht genug Zeit zur Verfügung, um es richtig zu machen, doch macht man es falsch, ist man noch Monate mit Bugfixing beschäftigt. Und wenn man Fehlerquellen in Code suchen muss, den man ein paar Monate nicht angerührt hat, wird es noch wesentlich schwieriger.
Und auch wenn sich aus den einzelnen Anwendungen kein Produkt entwickeln lässt, so sind mit Sicherheit Gemeinsamkeiten vorhanden. Lohnt es sich, die Gemeinsamkeiten in ein firmeninternes Framework zu extrahieren? Findet man die Zeit, das auch entsprechend zu dokumentieren?

Mittlerweile bin ich mir sehr sicher, das man mit einem Prinzip sehr viele dieser Probleme erschlagen kann, auch wenn es enorm schwer sein kann, das immer durchzuziehen: Don’t repeat yourself, kurz, DRY. Wir haben zwei Webanwendungen, die jeweils im UI eine Datumsauswahl haben? Schreiben wir doch einen Datepicker und verwenden den in beiden.

Noch zuletzt ein Aspekt, der durchaus ein großen Einfluss auf die Beantwortung der ersten beiden Fragen haben kann: Der Standort. Im ganzen Oberbergischen habe ich nur eine Consulting-Firma gefunden, Firmen mit IT-Abteilungen gibt es hingegen reichlich. Im Kölner Raum gibt es hingegen einen ganzen Haufen an Consulting-Firmen, was zunächst einmal die Jobsuche deutlich vereinfacht. Nun ist das Wohnen in Köln allerdings auch deutlich teurer.

Hoffe, hiermit bei der Beantwortung der ein oder anderen Frage behilflich gewesen zu sein.

Gleichzeitig beschreibt er einige der Ideen, die HTML und CSS zugrundeliegen, und die auch heute noch aktuell und wichtig sind. Seine Betrachtungen der Browserlandschaft und der Standardisierungsprozesse sind hingegen eher historischer Natur, aber ebenfalls sehr interessant: Heutzutage hat man immer den Eindruck, es gibt die Standards und die Browser, die diese implementieren, und es gibt Microsoft mit seinem Internet Explorer. David Siegel erzählt hingegen, das es mal Microsoft war, das sich mit dem W3C um Standards bemüht hat um gegen Netscape’s Tag-Wuchereien, aus denen auch <blink> entstanden ist, vorzugehen.

Interessant auch folgender Satz, damals noch als Entschuldigung für Netscape’s Tag-Erfindungseifer: “Our customers demand interim, tag-based solutions.” Anstatt weiter HTML zu vergewaltigen, schreibt man heute eben mal ein XML Schema mit seinen eigenen Tags. Sind wir damit dem Ziel, Struktur und Inhalt und Präsentation zu trennen, irgendwie näher gekommen?

Ein Satz, der mir in letzter Zeit auch des öfteren begegnet ist, findet sich auch:

Within large organizations, the phrase used to describe this approach is “industry best practice.” Its purpose is to shield the pointy-haired boss from responsibility: if he chooses something that is “industry best practice,” and the company loses, he can’t be blamed. He didn’t choose, the industry did.

Sehr interessant sind ein paar Details zur Lisp, scheinbar die dynamische Programmiersprache schlechthin. Verdient auf jeden Fall etwas Aufmerksamkeit, wenn man sich über die Unterschiede zwischen “statischen” Sprachen wie C/C++/Java und “dynamischen” Sprachen wie Ruby/PHP/Javascript Gedanken macht.

Dass sich jemand nach “Borat” mal fragt, wie Kasachstan in Wirklichkeit ist, glaubt Perisat nicht. “Die Leute haben gelacht – von denen wird sich doch jetzt keiner näher mit Kasachstan beschäftigen.” Fast nie habe sie jemanden getroffen, der die kasachische Hauptstadt kenne (sie heißt Astana) – und das, obwohl Kasachstan das neungrößte Land der Welt sei, sagt Perisat.

Unfreiwillig bestätigt wurde diese Aussage dann auch direkt von den Autoren selbst, denn mittlerweile findet sich am Ende des Artikels folgender Hinweis:

Anmerkung der Redaktion: Zunächst wurde im Text als Hauptstadt Kasachstans Almaty genannt – seit 1997 ist aber Astana Hauptstadt. Wir bitten diesen Fehler zu entschuldigen.

Ich hätte es auch nicht gewusst