Glorf IT

Durch Smi (da muss ich immer an Kpt. Hook denken, sorry) fand ich einen den Link auf den interessanten Artikel im Sztywny Blog "Stiff asks, great programmers answer". Hier beantworten bekannte Entwickler ein paar nette Fragen:

• How did you learn programming?
• What do you think is the most important skill every programmer should posses?
• Do you think mathematics and/or physics are an important skill for a programmer?
• What do you think will be the next big thing in computer programming?
• What do you think makes some programmers 10 or 100 times more productive than others?
• What are your favourite tools?

Die Antworten zu den einzelnen Fragen würde ich am liebsten tagelang kommentieren. Ich will mich aber auf einen Aspekt beschränken, den Linus Torwald in der Antwort auf Frage 4 aufgebracht hat:

For example, I personally believe that „Visual Basic” did more for programming than „Object-Oriented Languages” did. Yet people laugh at VB and say it’s a bad language, and they’ve been talking about OO languages for decades.

And no, Visual Basic wasn’t a great language, but I think the easy DB interfaces in VB were fundmantally more important than object orientation is, for example.

Das ist es auch, was wir in der Firma immer wieder erleben. Es gibt zwei Arten ein erfolgreiches Produkt auf den Markt zu bringen: Entweder man erfüllt zeitnah die Wünsche der Kunden oder man trifft den Nerv der Zeit und schafft es im Idealfall mit einem völlig neuen Ding Maßstäbe zu setzen.

Im ersteren Fall hängt es davon ab, wie gut das Team eingespielt ist, wie einfach die Dinge umzusetzen sind und wie gut es der Projektleiter versteht die vielen tollen/dringenden/wichtigen Ideen, die im letzten Drittel des Projektes von allen Seiten noch mit umgesetzt werden sollen, zu machbare Ideen zu destilieren oder auf die zweite Stufe zu verschieben. Um schnell zu sein, war ein VB-Team bis .Net noch immer im Vorteil.
Im zweiten Fall ist eine tolle Anwendungsarchitektur schon von Vorteil… Alerdings erlebe ich es immer wieder, dass in die ganz tolen Architekturen so viele Anforderungen reindefiniert werden, dass sie zu ahren Molochen werden und dann viel zu lange bis zur Markteinführung brauchen. Aber vielleicht ist das ja bei anderen Firmen anders? 😉

Erst vor ein paar Tagen entdeckte ich, dass mir Microsoft einen ganz lange gehegten Wunsch erfüllt hat. Man kann mit SqlCmd Batches mit Variablen ausführen. Hier ein ganz primitives Beispiel:

use $(db);
select * from $(tab) where $(col)=$(val);

Bei der Ausführung mit SqlCmd kann man nun die konkrete Variablenwerte angeben:

sqlcmd.exe -S (local)\MYYUKON -E -i c:\mssqlclass2005\sql-batch_01.sql -v db=northwind tab=dbo.orders col=OrderID val=10250

Weil das bisher nicht ging, haben wir für unsere Anwendungen 1993 ein eigenes Batch-Program geschrieben, dass wir immer wieder auf die verschiedenen Versionen migriert haben. Als wir dann auf den SQL Server 2000 umgestiegen sind, wurde es völlig runderneuert. Mal schauen, ob wir es noch nach der geplanten Migration auf SQL Server 2005 brauchen…

Unser wichtigster Anwendungsfall: In Views und/oder Procedures unserer Anwendungen sind datenbankübergreifende Abfragen enthalten. Da aber erst bei der Installation (beim Kunden, wir schreiben Standardsoftware, also Massenware) der Name der Datenbanken festgelegt wird, können die Skripte erst um Schluss eingespielt werden. Da müssen die Skripte anstelle der Datenbanknamen variable Werte enthalten.