(demnächst nicht mehr sharp genug?)

Für eingefleischte VB-Entwickler mag sich der Titel meines Blogeintrags nach einem ähnlichen "Horror" (bezogen auf die filmische Qualität) wie der Kinostreifen "Alien vs Predator" anhören (egal wer gewinnt, wir verlieren), speziell für C#-Entwickler hat ein solcher Vergleich durchaus seinen Reiz, gilt für manche das kommende F# bereits als das künftige C# (wenngleich das mit Sicherheit nicht passieren wird). Ich halte F# für viel zu kompliziert und anspruchsvoll für den Alltagsgebrauch, so dass es maximal für eine kleine Minderheit (Elite) an C#-Entwicklern eine echte Alternative sein dürfte. Das folgende kleine Beispiel habe ich aus einer ganz gut gemachten, wenngleich recht spärlichen Einführung in F# unter http://fsharp.net (es ist erstaunlich schwierig funktionierende und vor allem aussagekräftige Beispiele zu finden) gezogen  - es berechnet die Quadratzahlen der Zahlen von 1 bis 10:

let Quadrat x = x * x
let Zahlen = [1 .. 10]
let Quadratwurzeln = List.map Quadrat Zahlen
printfn "n^2 = %A"Quadratwurzeln

Ein Schleifenbefehl wird nicht benötigt, List.map wendet stattdessen die Funktion Quadrat auf alle Elemente der Liste Zahlen an (eigentlich gar nicht sooo kompliziert).

Dass auch C# 3.0 (und VB.NET 9.0) so etwas können, macht das folgende Beispiel deutlich:

Func<int, int> Quadrat = x => x * x;
var Zahlen = Enumerable.Range(1, 10);
var QuadratWurzeln = Zahlen.Select(Quadrat);
Console.WriteLine("n^2 = {0}", QuadratWurzeln.Aggregate("", (s, i) => s + " " + i));

Das ist nicht F#, sondern ganz normales C# 3.0 (in VB.NET würde es ähnlich aussehen). Fans funktionaler Ansätze bei der Programmierung müssen also nicht unbedingt auf F# warten. F# spielt seine wahren Vorzüge erst im Zusammenhang mit paralleler Programmierung und asynchroner Vorgänge aus. Themen, die Zukunft sicher deutlich wichtiger werden dürften. Einen ganz guten Überblick über F# gibt ein Wikipedia-Eintrag (Wikipedia hat anscheinend Probleme mit dem #) und ein recht umfangreiches Wiki.

PS: In dem obigen Beispiel produziert Enumerable.Range(1,10) eine Collection mit den Zahlen von 1 bis 10. Eine Alternative wäre natürlich ein Array:

int[] Zahlen = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };

PSPS: Eine der Köpfe hinter F# bei Microsoft, Don Syme, war übrigens vor ein paar Wochen in München auf dem F# night talk. Für Entwickler, die bereits mit F# arbeiten, war es mit Sicherheit hochinteressant, für meinen Geschmack war es ein "wenig" zu anspruchsvoll (und akademisch trocken).

 
(hier geht's lang zur möglichen Zukunft der Programmiersprachen)

(könnte in Zukunft eine wichtigere Rolle spielen - .NET unter Linux)

Nach meinem "StackOverflow-Moment" gab es vor kurzem einen ebenso erfreulichen "Ubuntu-Moment". Gehört hatte ich natürlich schon eine Menge über diese Linux-Variante und seinen "Erfinder", den südafrikanischen Millionär/Milliardär(?) und Hobby-Astronauten Mark Shuttleworth, aber die Gelegenheit es selber auszuprobieren ergab sich bislang nicht (warum auch? War ich doch mit Windows mehr als zufrieden<Ironie/>). Die Installation könnte einfacher nicht sein. Im Virtual PC hat es leider nicht geklappt, trotz "Reparaturhinweisen" in verschiedenen Blogs erschien nach der Auswahl der ISO-Datei, die ich von der Ubuntu-Webseite heruntergeladen hatte, ein Haufen (mir) unverständlicher (Fehler-) Meldungen. Mit der VirtualBox (einem freien Download von Sun, den ich bislang ebenfalls nur namentlich kannte) hat es auf Anhieb funktioniert. Die Installation dauerte wenige Minuten und erforderte lediglich das Anlegen bzw. die Auswahl eines Benutzerkontos. Kurz danach boote der Ubuntu-Desktop auf meinem Windows XP-Desktop in einem Fenster, der optisch durchaus ansprechend wirkt (und bezüglich des Motivs ein wenig an Windows 7 erinnert;). Die Netzwerkverbindung hat auf Anhieb funktioniert, sowohl ins Internet als auch ins lokale Netzwerk, was zumindest bei mir beim Virtual PC bislang eher die Ausnahme als die Regel war). Klar, dass ich natürlich zuerst die neuste Mono-Version (2.4) installiert habe, was ebenfalls eine Angelegenheit von wenigen Minuten war. Dank MonoDevelop, das sich in der Version 2.x enorm verbessert hat, gibt es (endlich) eine IDE, die der von SharpDevelop recht nahe kommt, und mit der man bereits erstaunlich komfortabel arbeiten kann (theoretisch gibt es auch einen VB.NET-Compiler, aber bei Mono ist natürlich C# die Sprache). Als ein paar Minuten später das Game of Life (eines meiner Lieblings "Hallo, Welt"-Programme) in einem Gtk#-Fenster lief war ich positiv beeindruckt (und richtig happy - ein Gefühl, das ich bei Windows länger nicht mehr erlebt hatte). Mein erster Ausflug in die Open Source-Welt hat damit überaus vielversprechend begonnen.

  
(der Boss demnächst wieder in Deutschland)

Manche Dinge sind so gut, dass man sie erst persönlich erlebt haben muss, um von einem Skeptiker zu einem überzeugten Anhänger zu werden (ein Bruce Springsteen-Konzert ist für einen solchen Moment immer noch sehr gut geeignet – ich bin sehr gespannt wie die Konzerte in München und Frankfurt werden – der Boss mit der E-Street Band am 3. Juli 2009 im Frankfurter Waldstadion weckt natürlich angenehme Erinnerungen an die legendäre BITSUSA-Tour –für Nicht-Insider – damit ist die Born in the USA –Tour, in diesem Fall aus dem Jahr 1985, gemeint - da dies noch Vor-Internet-Zeit war gibt es leider keine Konzertmitschnitte auf YouTube, was wahrscheinlich auch besser ist  - dafür gab es damals die legendären Bootlegger und folglich gäbe es das Konzert rein theoretisch auf CD - alleine der Blick auf die Setlist ist die Suche wert, das Konzert dauerte über 3 Stunden, was für den Boss damals ein eher durchschnittlicher Wert war).

Mir ging es vor kurzem so mit StackOverflow, einer Site, über die ich beim Googlen in den letzten Monaten natürlich immer wieder „gestolpert“ war, die mir bis dahin aber lediglich aufgrund ihrer etwas andersartigen Optik aufgefallen war (und die ich am Anfang aus welchen Gründen auch immer mit dem „Out of Coffee Exception“-Blog von Mathias Raake „verwechselt“ hatte). Nun, StackOverflow ist wirklich genial. Nachdem ich vor ein paar Tagen mit einem selbst gebauten Expression-Ausdruck nicht weiter kam beschloss ich es selber einmal zu probieren und stellt das Codeschnipsel, das nicht funktionieren wollte, online (natürlich hübsch formatiert, was sehr einfach ging). Ich hatte damit gerechnet, eventuell in ein paar Tagen eine Antwort zu erhalten, so wie es in vielen Newsgroups üblich, umso erfreuter war ich, dass ich praktisch unmittelbar eine Antwort erhielt mit einem Hinweis, der das kleine Problem löste (die Ursache war eine Art Flüchtigkeitsfehler, aber immerhin). Das Schöne an StackOverflow ist nicht nur die enorme Informationsdichte, das hohe fachliche Niveau (kein Problem erscheint zu speziell, um nicht in diesem Rahmen diskutiert werden zu können) und die moderne Optik, sondern auch der angenehme weil sachlich kurze Umgangston. Auch dass viele Teilnehmer mit Bild vertreten sind, dass keine Registrierung erforderlich ist (anmelden und identifizieren kann man sich u.a. mit seiner Google-ID), und dass es eine für alle Programmierthemen offene Plattform ist, machen StackOverflow sehr sympathisch. StackOverflow, das von einer kleinen Gruppe von Leuten anscheinend als eine Art Hobbyprojekt betrieben wird (einer der Gründer, Jarrod Dixon, war auf der letzten Mix-Konferenz beim Panel-Talk im Anschluss an die Developer Keynote anwesend und ging kurz auf die Entstehung von StackOverflow ein) ist auf eine gewisse Weise die Zukunft der technischen Newsgroups, die heute schon etwas ausgedünnt erscheinen und vielleicht auch der MSDN-Foren, die auf mich inzwischen relativ behäbig und vor allem schwer zugänglich wirken. Ich hoffe, dass der StackOverflow-Effekt noch lange anhält.

(StarTrek-Generations auf der Bühne
- von links: Richard Arnold, Nana Visitor, Nichelle Nichols, Connor Trinneer, John Billingsley und Robert Picardo)

Dieser Blog-Eintrag (nach länger Zeit der Abstinenz) hat zu mindestens indirekt etwas mit Programmierung zu tun, denn bekanntlich sind die meisten Entwickler mehr oder weniger StarTrek "afin" (wenn man sich permanent mit Themen beschäftigt, die erst in der Zukunft eine Rolle spielen, bleibt das nicht aus).

Am letzten Sonntag war ich wieder einmal auf der StarTrek FedCon, inzwischen der 17ten (eine fiel offenbar aus demselben Grund aus, weswegen der Nachfolger von Office 2003 "Office 14" heißt bzw. hieß), die sich nach wie vor (oder inzwischen wieder?) einer recht großen Beliebtheit erfreut (immerhin kamen laut Veranstalter Teilnehmer aus 31 Ländern - davon kann eine Entwicklerkonferenz inklusive der "Branchenriesen" wie PDC, Apple WDC, SAPhire oder JavaOne, nur träumen). Weder der Veranstaltungsort (Bonn) noch das Veranstaltungshotel (Maritim) gehören zu meinen Lieblingsorten/Hotels, doch wer seit Mai 1972 treuer StarTrek-Fan ist, den kann das natürlich nicht abschrecken. Inzwischen geht es auf einer FedCon längst nicht mehr um das StarTrek-Universum alleine, StarGate, Babylon 5 und vor allem Battlestar Galactica wurden gleichberechtigt in das Programm aufgenommen und sogar die Storm Troopers 501st Legion aus dem StarWars-Universum, zu dem es normalerweise erstaunlich wenige bis gar keine Anknüpfungspunkte mit dem StarTrek-Pendant gibt, waren vertreten (der Trend zu den inhaltlich fragwürdigen Fantasyreihen á la Buffy ist anscheinend wieder vorbei, wobei man an den zahlreichen Merchandising-Ständen natürlich alles kaufen kann was auch nur halbwegs in das Genre passt).

Der Reiz einer FedCon besteht darin, die Seriendarsteller aus nächster Nähe erleben zu können. Auf einem sog. Panel präsentieren sie sich ca. 1 Stunde den Fans und beantworten auf der Bühne Fragen, die ihnen von den Teilnehmern gestellt werden (geht man von den Detail- und Englischkenntnissen vieler Fragesteller aus könnte man den Eindruck gewinnen, dass der bzw. sehr oft auch die Fragestellerin gerade ihre Dissertation über den Schauspieler bzw. die Serie abgeschlossen hat, aber es dürften in erster Linie die Mitglieder diverser Fanclubs sein).

Die ganze FedCon ist in ein ausgeklügeltes System an "Berechtigungsstufen" unterteilt - abhängig davon, wieviel Geld man bereit ist auszugeben. Von der einfachen Tageskarte für 40€ bis zum Gold-Ticket, das nicht nur den Eintritt für alle drei Tage, sondern auch garantierte Sitzplätze in den vorderen Reihen und sämtliche Autogrammkarten umfasst, für stolze 499€ (!) reicht das Spektrum. Wer was darf entscheiden die Farbe des Armbändchens sowie ein entsprechender Stempel auf dem Eintrittskärtchen. Da ich erst gegen 13 Uhr eintraf, konnte ich zwar ein Halbtagsticket für 20€ erstehen, erhielt mit dem grauen Bändchen aber auch das "Least Privileged Security Tocken" - und das bedeutet konkret, Sitzplatz auf der Empore (und nicht unten im Saal), kein T-Shirt, keine (kostenlose) Verpflegung und natürlich keine Autogrammkarte. Dass diese so wichtig ist liegt daran, dass die anwesenden Stars ihre Autogramme nur gegen Gutschein vergeben, den man zuvor erwerben muss. Der Preis für einen Gutschein richtet sich nach der "Beliebtheit" des  Schauspielers und anderer Faktoren, die nicht öffentlich dokumentiert sind - für einen "unbekannten" Darsteller (jeder im StarTrek-Universum hat natürlich seine Fans) sind es 10€, für einen "Main Character" (etwa Nana Visitor bekannt aus DS9) 15€ und der Topstar (dieses Mal war es Edward James Olmos alias Commander Adama aus Battlestar Galactica alias Lt. Martin Castillo aus "der" 80er Jahre Kultserie Miami Vice) kostete stolze 40€. Für drei bis vier Autogramme (die optionalen Fotos, auf denen der Star dann eventuell ein "For Peter" setzt, kosten noch einmal ein paar Euro extra) gehen schon einmal 100€ drauf (generell scheint die Krise in diesem Sektor des Universums noch nicht angekommen zu sein, geht man nach den Besucherzahlen der FedCon und der Kauffreudigkeit der Teilnehmer).

Dies sind natürlich die auf solchen "Fan-Conventions" obligatorischen und nicht zu vermeidenden Rahmenbedingungen, auf wenn sie zunächst etwas befremdlich erscheinen mögen, an denen sich scheinbar auch niemand groß stört. Die Gelegenheit, jene Schauspieler, die man seit Jahren, eventuell Jahrzehnten, aus dem Fernsehen kennt einmal live erleben zu können und das begehrte Autogramm mit Widmung erhalten zu können wiegt das "Pay per Autogramm"-Prinzip für die meisten Teilnehmer auf und bedeutet für den Schauspieler eine attraktive Einnahmequelle weit über das Serienende hinaus (mir waren die 40€ für das Autogramm von Edward James Olmos, der Almosen sicher noch nicht nötig haben dürfte, allerdings deutlich überteuert).

Das absolute Highlight am Sonntagnachmittag war natürlich der Auftritt von Nichelle Nichols, alias Lt. Uhura, die sich nicht nur optisch in ähnlich bestechender Form präsentiert wie Tina Turner, und der man in keiner Sekunde anmerkt, dass sie den weiten Weg aus den USA eventuell nur aufgrund der Gage angetreten haben könnte. Auch wenn sie im Panel zusammen mit anderen Schauspielern der verschiedenen Star Trek-Epochen auf der Bühne stand (lediglich von den TNG-Schauspielern war leider niemand dabei) stand sie eindeutig im Mittelpunkt. Sie berichtete unter anderem wie sie zur Serie kam, von den schwierigen Anfängen (ihren Worten zufolge hat der Sender NBC die Serie von Anfang an "gehasst" und es war nur dem organisierten Druck der Zuschauer zu verdanken, dass sie nach der ersten Staffel nicht wieder eingestellt wurde). Sie wies (zurecht) darauf hin, wie positiv StarTrek und die Vision des Serienschöpfers Gene Roddenberry einer Welt, in der Kriege überwunden sind, die Rasse eines Menschen keine Rolle spielt (eine für die damalige Zeit gewagte und für das amerikanische Fernsehen sicher auch provokante Vision), die Entwicklung der Menschheit beeinflusst hat, und welches Geschenk es für sie war, an der Serie mitwirken zu dürfen und, z.B. als Botschafterin für die NASA, immer noch ein Teil der Bewegung zu sein (die Frage eines Zuschauers, warum in einer angeblich so friedvollen und zivilisierten Organisation wie der Sternenflotte militärische Ränge dominieren und die einzigen, die wirklich Entscheidungen treffen, "Militärs" seien, entgegnete sie, dass dies kein Widerspruch zur Vision sei und sich Gene Roddenberry damals lediglich der in der Marine üblichen Terminologie bedient habe, da die Enterprise nun einmal ein Schiff sei, und dass später von Paramount der "militärische" Aspekt stärker in den Vordergrund gerückt wurde - sie wies damit auch Richard Arnold (TNG-Consultant und angeblich lebende StarTrek-Enzyklopädie) sehr deutlich zurecht, der diesen puristischen Ansatz des verstorbenen StarTrek-Schöpfers indirekt ein wenig in Frage stellte).

Überaus humorvoll war ihre Schilderung des ersten "inter racial kisses"  im öffentlichen Fernsehen zwischen ihr und Captain Kirk, der damals in den USA im Jahre 1968 natürlich für Furore sorgte. Danach wollten die "Studiobosse" auch eine Variante der Szene ohne den Kuss, um später eventuell diese Szene verwenden zu können, doch als nach "mehren Dutzend" Kussszenen, die William Shatner anscheinend alle nicht intensiv genug waren, am Ende nur noch Zeit für eine Szene ohne Kuss blieb blinzelte Shatner im entscheidenden Augenblick in die Kamera, so dass die Einstellung unbrauchbar war und die Kussszene ausgetrahlt werden musste. Klar, dass sie am Ende mit Standing Ovations verabschiedet wurde.

Auch das Panel mit Michael Hogan (Saul Tigh) und Edward James Olmos aus Battlestar Galactica (die verschiedenen BSG-Schauspieler vermieden Referenzen auf die 4te Staffel, die bei uns anscheinend noch nicht ausgestrahlt wurde) war die Reise wert, doch es würde ein wenig zu weit führen auch darüber noch zu berichten, zumal die meisten Fragen und ihre Antworten recht speziell waren (witzig war die Antwort von Olmos auf die Frage, warum er denn bei Miami Vice nur einen "Schreibtischjob" hatte während Crockett und Tubbs regelmäßig ihren Ferrari zu Schrott fahren durften - er antwortete, dass er selber alle Freiheiten gehabt hatte die Rolle zu gestalten und freiwillig auf die Action verzichtete). Interessant war auch der Hinweis, wie Ideen und Kommentare aus Blogs und Diskussionsforen zur Battlestar-Serie von den Drehbuchschreibern aufgegriffen werden (etwa zu brisanten Themen wie Folter, das bei den späteren Folgen ein zentrales Thema ist) und wie dadurch die Serie immer besser und inhaltlich intensiver wurde (ein absolutes Highlight muss der 3 Stunden dauernde Abschluss der 4ten und offenbar letzten Staffel sein).

Alleine diese beiden Panels waren den Besuch am Sonntagnachmittag wert. Auch wenn das StarTrek-Merchandising-Universum offenbar nach wie vor stetig expandiert, der kommerzielle Aspekt bei dem Ganzen ein wenig zu sehr im Mittelpunkt steht, die überwiegende Zahl der Teilnehmer noch erstaunlich jung sind (klar, ab einem gewissen Alter und ab Erreichen einer gewissen intellektuellen Reife steht man natürlich über diesen Dingen) und man bei manchen der Fans das Gefühl nicht los wird, dass sie außerhalb ihrer "Sphäre" Menschen ohne ausgeprägte soziale Kontakte sein dürften, hat es Spaß gemacht, ein paar der "Helden" von früher wieder einmal live erleben zu können.

Ressourcen sind eine feine Sache, wenn man erst einmal den sprichwörtlichen Bogen raus hat. Mit .NET 2.0 und VS 2005 wurde der Umgang mit Ressourcen auf eine einheitlichere Grundlage gestellt und vor allem für die VB-Leute ein wenig vereinfacht. Dank des praktischen My-Namespaces könnte der Zugriff auf eine Projektressource (Ressourcen können auch direkt in die Assembly eingebettet werden - dieser Fall wird im Folgenden nicht betrachtet) einfacher kaum sein. Enthalten die Projektressourcen z.B. eine Bitmap mit dem Namen Bahamas.jpg, lädt der Befehl

PictureBox1.Image = My.Ressources.Bahamas

die Bitmap in eine PictureBox. Möchte man, wozu es im Allgemeinen keinen Grund geben dürfte, ohne den My-Namespace auskommen, muss man sich die Mühe machen und die ResourceManager-Klasse im Namespace System.Resources bemühen. Das folgende Beispiel geht davon aus, dass die Projektressourcendatei Resources.resx heißt (was im Allgemeinen der Fall ist) und eine Bitmap Bahamas.jpg enthält:

Imports System.Reflection
Imports System.Resources

Dim Ass As Assembly = Assembly.GetExecutingAssembly()
Dim ResMan As ResourceManager = New ResourceManager("WindowsApplication1.Resources", Ass)
Dim Im As Bitmap = ResMan.GetObject("Bahamas")
PictureBox1.Image = Im 

Etwas kniffliger wird es, wenn man die Namen aller Bitmaps einlesen möchte, um sie z.B. in einer ListBox zur Auswahl anzubieten.  Diese Möglichkeit bietet die ResourceManager-Klasse nicht. Ein Befehl wie

Using St As Stream = Ass.GetManifestResourceStream("WindowsApplication1.Resources.resources") 

liefert alle Ressourcen-Bitmaps in Gestalt eines zusammenhängenden Streams. Das "Zerlegen" in die einzelnen Ressourcen übernimmt die ResourceReader-Klasse, die einen (untypisierten) Enumerator liefert:

Using St As Stream = Ass.GetManifestResourceStream("WindowsApplication1.Resources.resources")
    Dim ResRd As New ResourceReader(St)
    Dim En As IEnumerator = ResRd.GetEnumerator
    While En.MoveNext
        ListBox1.Items.Add(En.Current.Key)
    End While
End Using 

Während die Key-Property für den Namen der Ressource steht, liefert die Value-Eigenschaft den Wert (z.B. als Bitmap).

Ist der Name der Ressource bekannt, kann der Zugriff auf die Ressource wieder über den ResourceManager erfolgen:

Dim Ass As Assembly = Assembly.GetExecutingAssembly()
Dim ResMan As ResourceManager = New ResourceManager("WindowsApplication1.Resources", Ass)
PictureBox1.Image = DirectCast(ResMan.GetObject(ListBox1.SelectedItem), Bitmap) 

Unter WPF sieht alles ein wenig anders aus, aber nur ein wenig. Auch wenn WPF ein eigenes Ressourcenkonzept mitbringt, lassen sich auch WinForms-Ressourcen ansprechen. Am Prinzip des Zugriffs ändert sich (natürlich) nichts. Ein wenig "trickreich" ist lediglich der Umstand, dass es bei WPF keine Bitmap-, sondern eine BitmapSource-Klasse gibt, die sich beide ein wenig voneinander unterscheiden. Eine direkte Konvertierung ist anscheinend nicht möglich, aber mit ein wenig "Interop-Zauberei" ist auch das kein Problem. 

Die folgende Funktion erwartet eine System.Drawing.Bitmap als Parameter und gibt ein BitmapSource-Objekt zurück:

Function GetBitmapSourceFromBitmap(ByVal Bm As Bitmap) As BitmapSource
    Return Im.Imaging.CreateBitmapSourceFromHBitmap(Bm.GetHbitmap(), IntPtr.Zero, Int32Rect.Empty, _
    System.Windows.Media.Imaging.BitmapSizeOptions.FromEmptyOptions())
End Function 

Viel Spaß mit den WinForms-Ressourcen, mit denen einiges möglich ist, und die ich daher ausgiebig nutzen würde. Nicht nur Bitmaps, auch Zeichenketten oder XML-Daten lassen sich als Ressourcen ablegen und stehen damit als Teil der Assembly zur Verfügung. Möchte man eine Anwendung mehrsprachig halten, kommen die sprachabhängigen Ressourcen zum Einsatz.  Hier gibt es einen guten Übersichtsartikel von Chris Sells, der zwar schon ein paar Jahre alt ist, aber das Thema gut zusammenfasst.

Letzte Woche fand, dieses Mal in relativer Nachbarschaft zum Darmstadter Hbf, die traditionelle Basta! Spring .NET-Entwicklerkonferenz statt. Traditionell, weil es die Basta! nun über 10 Jahren gibt (die ersten "Basic-Tage" fanden, soweit ich mich spontan erinnern kann, 1996 in Frankfurt statt). Die Spring-Variante der Basta! ist deutlich kleiner als die "große Herbst-Basta!, was in Hotel-Räumlichkeiten aber generell schwer zu beurteilen ist. Das Motto der Basta! lautete auch dieses Mal "Best Best Practices", was durchaus einen tieferen Sinn gibt, da es um die besten der Best Practices ging, die von praxis- und konferezerfahrenen Sprechern  den Teilnehmern vermittelt wurden. Ich war dieses Mal nur Dienstag und den halben Mittwoch dabei. Am Dienstagmorgen gab ich im Rahmen des Visual Basic Days (der erfreulich gut besucht war - was natürlich an der Themenauswahl und der sehr guten Sprecher lag) einen Überblick über das "moderne Visual Basic" (wobei ich wieder einmal feststellen musste, dass auch viele erfahrene Entwickler mit Grundlagen wie Predicate- und Action-Delegates nicht allzu viel anfangen wissen, was aber auch daran liegt, dass man sie in der Praxis relativ selten braucht - für mich sind sie die Vorläufer der Funktionsausdrücke (Lambdas), auf denen wiederum LINQ basiert). Am Abend ging es im Rahmen der Night School deutlich "intimer" zu - gerade einmal 6 Teilnehmer hatten sich eingefunden, die sich aber als wahre VB6-Entwickler entpuppten, so dass eine sehr interessante und kurzweilige Diskussionsrunde entstand, was neben den Vorträgen den Reiz einer Konferenz wie der Basta! ausmacht).  VB6 ist immer noch sehr populär. Das zeigen nicht nur die Aktivitäten auf Websites wie www.activevb.de, und die Leserbriefe, die ich hin und wieder bekomme, sondern belegen anscheinend auch Umfragen:

http://geekswithblogs.net/iupdateable/archive/2009/02/17/results-of-the-visual-basic-survey-part-1-language-and.aspx

Ich bin nicht sicher, ob das unbedingt ein Anlass zur Freude ist. Innovationen zu ignorieren ist am Ende kontraproduktiv, aber es zeigt sehr eindrucksvoll, dass die Lebenszeiten von Geschäftsanwendungen deutlich höher sind als es früher in den Raum gestellt wurde.

Die "großen Konferenzthemen", soweit ich das aufgrund meiner recht kurzen Anwesenheit auf der Konferenz beurteilen konnte, waren u.a. Entity Framework und natürlich C# in allen Variationen (durch Oliver Sturm wie immer bestens besetzt).

Eine der Fragen, die .NET-Entwickler derzeit beschäftigt ist WPF oder WinForms? Auch wenn aus meiner Sicht (passend zur Krise) zu viel mit dem "Angstfaktor" argumentiert wird (wird es sich durchsetzen, wird es die richtige Wahl sein und, das schwingt unausgesprochen natürlich immer mit, werde ich in der Lage sein WPF zu meistern?), ist es keine einfache Entscheidung. WPF wird sich durchsetzen, das alleine unterstreicht der Umstand, dass die nächste Visual Studio-Version auf WPF basieren wird und es inzwischen richtig interessante WPF-Anwendungen gibt.

Auf der einen Seite darf die Einarbeitungszeit nicht unterschätzt werden und der Umstand, dass es nicht bei jeder Sorte von Anwendungen seine Vorteile ausspielen kann. Da aber WPF mit hoher Wahrscheinlichkeit in der Zukunft der meisten Entwickler liegen wird, würde ich mich lieber früher als später damit beschäftigen. Wer noch in diesem Jahr ein Projekt ausliefern muss, für den kommt WPF sicher noch nicht in Frage. Wer dagegen in 1-2 Jahren etwas ausliefern muss, sollte (sofern es nicht den einen Grund gibt, der dagegen spricht) den sprichwörtlichen Sprung ins kalte Wasser wagen.

Hier noch etwas für die "Dinge, die man nicht ignorieren sollte"-Rubrik: http://www.silverlightshow.net/items/Building-a-Framework-for-Silverlight-Line-Of-Business-Applications.aspx

Der Termin für die Herbst-Basta! steht bereits fest ( 25. bis 29. September 2009 - dann wieder wie jedes Jahr in Mainz). Dieses Mal wird es sogar einen "VB-Double-Day" geben. Vielleicht gibt es ja einen speziellen "WPF für Visual Basic"-Tag.

PS: Die Folien zu einem "VB von 1 bis 10"-Vortrag gibt es hier. Es geht nicht nur um einen Überblick über das moderne Visual Basic, sondern auch um ein paar "Tipps on the run" (etwa, wie sich Konfigurationsdaten direkt auslesen lassen oder sich XML direkt in der Assembly unterbringen lässt) und eine Liste von Tools, die jeder kennen sollte.

 
(The hardest working man in Show Business demnächst wieder auf Tour)

So lautete vor vielen Jahren eine Artikelserie von Ralph Westphal, damals noch in der BasicPro (lange ist es her). Damals ging es um den bevorstehenden Wechsel vom vertrauten Visual Basic 6 auf das kommende VB.NET. Ein Wechsel, den ich heute deutlich kritischer sehe als damals, doch das ist und sollte natürlich heute kein Thema mehr sein. Damals fand ich den Titel der Serie etwas albern, doch im nachhinein gesehen war er gut gewählt, denn Visual Basic hat sich beim Sprung von VB 6 auf VB .NET tatsächlich radikal gewandelt und war kaum wiederzuerkennen ("not one line of code was reused" - was Matt Gertz aus dem VB-Team damals in einem Blog-Eintrag auch freimütig bekannte). Wie anders das moderne Visual Basic geworden ist macht vor allem LINQ deutlich. Wer bei LINQ noch an Datenbanken usw. denkt muss ein wenig den Blickwinkel neu justieren, denn LINQ betrifft alle Sprachbereiche. Das habe ich neulich wieder festgestellt, als ich einen Leserbrief mit der Frage erhielt, wie sich denn bei Visual Basic ein Array mit Werten initialisieren lässt (ein New Array ist bekanntlich nicht möglich, da die Array-Klasse eine abstrakte Basisklasse ist) und ich mir dacht, dass dies doch irgendwie mit LINQ lösbar sein müsste. Ein

Dim Personen(9) As Person

legt zwar ein Array mit 10 Feldern an, jedes Feld besitzt noch den Wert Nothing, das Array ist noch nicht initialisierty (in C# wäre das nicht anders). Was muss man also tun, wenn man ein Array mit 10 bereits initialisierten Feldern möchte und nicht jedes Objekt in geschweiften Klammern folgen lassen möchte, was aber einer gewissen Anzahl nicht mehr praktikabel ist? Klar, eine For-Schleife geht immer, doch ist mir diese Lösung inzwischen zu sehr "old school" (wer sich intensiver mit der PowerShell beschäftigt, so ich ich das in meinem "zweiten Leben" als PowerShell-Buchautor und Trainer tue, lernt die Vorzüge dynamischer Typisierung praktisch nebenbei kennen). Im Zeitalter funktionaler Sprachen muss es anders gehen. Kein Problem, LINQ hat auch in diesem Bereich etwas zu bieten:

Dim Personen(1000) As Person
Personen = (From P In Personen Select New Person() With {.Name = ZufallsName()}).ToArray

Function ZufallsName() As String
       Dim R As New Random(Now.Millisecond)
       ' Nur erforderlich, damit der Zufallszahlengenerator etwas zufälliger wird
       Threading.Thread.Sleep(5)
       Return New String() {"Achim", "Bert", "Chris", "Dieter", "Erik"}(R.Next(0, 5))
End Function

Im Mittelpunkt steht natürlich der Befehl

Personen = (From P In Personen Select New Person() With {.Name = ZufallsName()}).ToArray

Er legt für jedes Feld des Array Personen ein neues Person-Objekt an (damit es nicht so leer bleibt, wird seine Name-Eigenschaft über die ZufallsName-Funktion mit einem zufälligen Namen initialisiert - die kurze Verzögerung mit Sleep habe ich eingebaut, damit die Namen etwas zufälliger werden, was aber eher ein Problem der Random-Klasse ist) und gibt das auf diese Weise generierte Array der Variablen Personen erneut zu (ob das der effektivste Weg ist ein Array zu initialisieren sei einmal dahingestellt, aber ein Spontan-Benchmark mit der StopWatch-Klasse zeigt, dass diese Variante sogar ein wenig schneller ist als wenn das Array per For Next-Schleife initialisiert werden würde).

Ist das noch "unser" Visual Basic? Mit Sicherheit (zu mindestens bezogen auf jenes Visual Basic, das mit .NET eingeführt wurde), denn die obige Lösung ist kein Insider-Hack, sondern wurde mit regulären Sprachelementen umgesetzt, die seit Version 9.0 Teil der Sprache sind, und die daher jeder Entwickler nutzen sollte. Durch sie entwickelt sich Visual Basic in Richtung funktionaler Programmierung was generell eine gute Sache ist, da sich dadurch Abläufe deutlich effektiver umsetzen lassen als es mit der traditionellen prozeduralen Programmierung möglich ist. Das Schöne an diesen Neuerungen ist, dass niemand gezwungen ist es so zu machen. Doch Beispiele wie das obige Beispiel werden schnell dazu führen, dass sich dieser moderne Ansatz durchsetzt. LINQ besitzt ein enormes Potential, das nur darauf wartet genutzt zu werden.

Mehr "Visual Basic-Propaganda" gibt es auf der Basta! in zwei Wochen, wo ich im Rahmen des Visual Basic Days das neue Visual Basic vorstelle (und dabei gegen Oliver Sturm und seinen C# 3.0-Vortrag antreten muss, was natürlich eine echte Herausforderung ist - erfahrungsgemäß haben die C#-Leute auf den "Basic Tagen" seit einigen Jahren ein deutliches Übergewicht, was natürlich nicht einer gewissen Ironie entbehrt).

PS: Hier ein Eintrag für die Rubrik "Nichts bleibt so wie es ist". Bis vor kurzem galt es als eine Art Naturgesetz, dass Bruce Springsteen (ob solo oder mit seiner E-Street-Band) nie mit einer Vorgruppe auftritt . Und nun das (mit ihm sollte Frau Merkel als nächstes einmal telefonieren). Nicht nur, dass er nach knapp einem Jahr (!) nach seiner letzten großen Tour erneut auf große US- und Europa-Tournee geht, er spielt, früher undenkbar, erstmalig auch einige Festivals (ich hoffe inständigst, dass er nicht eines Tages bei Wetten,dass? auftritt). Das ist ähnlich schwer zu "verdauen" wie damals der Zwangsumstieg von VB6 nach .NET. Eines muss man ihm aber lasen, den inoffiziellen Titel "Hardest working men in Show Business" hat er sich redlich erarbeitet. Selbst James Brown hätte das sicher so gesehen.

(die kostenlosen Krypto Controls im Einsatz - irgendwie sehr nett, aber leider nicht vollständig)

Ich kann sie nicht mehr sehen, die typischen mausgrauen Windows Forms-Anwendungen mit den nüchternen Buttons, den langweiligen Labels und den minimalen (und oft versteckten) Möglichkeiten, die ein Form-Formular zu bieten hat und Controls wie MonthCalendar oder TabControl, die seit Jahren nicht mehr aktualisiert wurden. Als ich vor einigen Wochen eine etwas größere Anwendung (Tagebuch-Anwendung) starten wollte fiel mir nach kurzem Herumprobieren auf, das man die Optik im Jahre 2009 Niemanden mehr zumuten kann bzw. sollte. Natürlich gibt es "jede Menge" Alternativen und natürlich kann bzw. sollte man im Jahre 2009 WPF bevorzugen. Doch wenn eine Anwendung irgendwann einmal fertig sein soll, die Designer-Unterstützung im aktuellen Visual Studio 2008 immer noch "ein wenig bescheiden" ist und man nicht nach einem halben Jahr feststellen möchte, dass man besser noch einmal von vorne anfängt, weil man dann erst verstanden hat wie WPF wirklich eingesetzt werden muss, bleibt man bei einer bewährten Technik, die ja zudem gar nicht einmal so schlecht ist.

Per Zufall bin ich auf das Krypton Toolkit einer kleinen Softwarefirma mit dem Namen ComponentFactory gestoßen (hinter der, den Forumspostings zu urteilen, vermutlich mit einem gewissen Phil Wright auch nur eine Person steckt, wenngleich das nichts zur Sache tut). Ich hatte vor einiger Zeit die Krypton Icons erworben, die mir wirklich gut gefallen (es geht nichts über einen Satz hübscher Icons). Das Toolkit besteht aus insgesamt 38 Controls, die tatsächlich komplett kostenlos sind. Doch wie üblich gibt es auch kleinere "Besonderheiten", die erst bei näherer Betrachtung deutlich werden:

>Das Toolkit mit seinen Controls ist zwar kostenlos (den Quellcode gibt es für einen relativ geringen Betrag separat), es gibt es aber nur als Teil der Trial-Version der Krypton Suite, die noch weitere Komponenten umfasst (u.a. die inzwischen obligatorische Ribbon-Komponente). Folge: Man hat eine Toolbox mit einigen Komponenten, die nach 30 Tage nicht mehr eingesetzt werden dürfen, und die man wieder einzelnen entfernen muss. Damit kann man natürlich leben.

>Die stolze Zahl 38 darf nicht darüber hinweg täuschen, dass es nur ein halbes Dutzend wirklich neuer Controls sind (u.a. ein Bread Crump und ein hübscher Color Button zur Auswahl einer Farbe aus einer Farbpalette), der Rest sind "aufgehübschte" Versionen der Standard-Controls, die um die Möglichkeit erweitert wurden, mit dem Krypton Paletten-Control zusammenzuarbeiten, über die die "Formatierung" aller anderen Krypton-Controls im Detail festgelegt wird. Es fehlen z.B. wichtige Controls, wie MonthCalendar, DateTimePicker, ProgressBar oder TrackBar.

>Das Krypton Toolkit wird in einem eher gemächlichen Tempo weiterentwickelt (aktuell ist die Version 3.08). Das MonthCalendar-Control steht anscheinend als nächstes auf dem Programm, was auch einen guten Eindruck macht. Doch da alles kostenlos ist, kann man natürlich nicht erwarten, dass alles auf einmal passiert und sich bei Bugs auch nicht richtig beschweren. Auf die Bitte "can you design two controls (datetimepiker (like Microsoft) and messagebox) ?" antworte Phil ein wenig sarkastisch mit einem "Sure, I will add them today for you". Und wenn sich ein Entwickler beklagt, dass ein Fehler dringend behoben werden muss, da er seine Anwendung "morgen ausliefern" will lautet die Antwort, dass der Fehler mit dem nächsten Release behoben sein sollte, doch wann es genau veröffentlicht wird bleibt genauso offen wie die Frage, ob dies auch tatsächlich geschieht. Hier wäre ein Open Source-Ansatz sicher sinnvoller. Aber immerhin gibt es ein aktives Forum, in dem wichtige Fragen anscheinend auch gleich beantwortet werden.

Insgesamt sind die Controls aus dem Krypton Toolkit 3.08 eine nette Sache, auch wenn sie viele neue Eigenschaften und vor allem neue Sichtweise mitbringen, da ein KryptonLabel z.B. keine BackgroundColor-Eigenschaft besitzt, da diese an einer anderen Stelle über die Palette eingestellt wird. Mir ihrer Hilfe lässt sich eine Windows Forms-Oberfläche deutlich modernisieren und z.B. an das Look&Feel von Office 2003&2007 anpassen. Leider fehlen wichtige Controls, so dass ich sie nur eingeschränkt empfehlen kann. Das Mischen von Standard-Controls mit den Krypton-Controls sieht im Allgemeinen nicht gut aus. Das Toolkit wird weiterentwickelt, es sind einige spannende Controls im Gespräch (dabei merkt man erst einmal, wie veraltet die Windows Forms Controls heutzutage sind und wie es sich auswirkt, dass Microsoft die aktive Weiterentwicklung bereits mit .NET 2.0 und VS 2005 eingestellt hat), doch man muss Geduld haben und es gibt keine Garantie, dass ein bestimmtes Control tatsächlich im nächsten Release dabei ist (theoretisch könnte man sich die Controls auch selber bauen, das wäre doch etwas für Andreas M. - das werde ich ihm gleich einmal vorschlagen).

Kostenlos ist in diesem Fall also eine zweischneidige Angelegenheit, denn viele Entwickler wären nur zu gerne bereit einen angemessen Preis zu bezahlen, wenn sie dafür eine vollständigen Satz an Controls erhalten würden und echte Bugs in kurzer Zeit gefixt werden.

Als nächstes werde ich mir die Telerik RAD Controls for WinForms anschauen, die einen hervorragenden Eindruck machen, aber preislich leider in einer ganz anderen Liga spielen. Mein Wunsch-WinForms-Toolkit müsste deutlich preiswerter sein.