Auf zum 2. Tag der Basta! Hauptkonferenz – und damit dem ersten der beiden SharePoint Days. Heute gibt es keine morgendliche Keynote, sondern es geht gleich in die Sessions – für mich ist das als erstes Sehenswertes aus SharePoint 2010 mit Tom Wendel. Erstaunlich für mich, dass nur ca. ein Drittel der anwesenden Entwickler Sharepoint 2010 überhaupt schon gesehen hat. Dementsprechend “basic” fällt die Vorstellung der Neuerungen aus – weshalb ich hier auch auf eine detaillierte Auflistung verzichte. Trotzdem ein paar “Bruchstücke”, die mir nennenswert erscheinen:

• Obwohl Firefox 3.5 als First-Level-Browser für SharePoint 2010 unterstützt wird, funktionieren einige Features, die ActiveX verwenden (z. B. die Datenblattansicht für Listen oder die Office-Integration), nicht mit Firefox.
• Custom Actions (z.B. um einer Liste zusätzliche Menüeinträge incl. dahinterliegender Funktionialität  hinzuzufügen) müssen nicht mehr zwingend programmiert werden, sondern können (mit begrenztem Funktionsumfang) auch mittels SharePoint Designer erstellt werden.
• In Listen können sowohl auf Spalten- als auch auf Listenebene Validierungsregeln hinterlegt werden (“Spalte Geburtsdatum darf nicht in der Zukunft liegen”, “wenn bei Spalte X “Ja” ausgewählt ist, darf Spalte Y nicht leer sein”). Der Umfang der für die Regeln verfügbaren Funktionen ist herauszufinden – wahrscheinlich ähnlich Excel…
• Business Connectivity Services sind (anders als der BDC in MOSS 2007) Bestandteil der SharePoint Foundation.

Als nächstes schere ich mit ASP.NET 4.0 – Was ist neu? mit Holger Schwichtenberg (zumindest im strengen Sinne) aus der SharePoint-Schiene aus. Hier wird Schlag auf Schlag eine Vielzahl kleiner und größerer Verbesserungen präsentiert – nachfolgend eine Auswahl:

• Die web.config ist (im Standard) deutlich kleiner/übersichtlicher geworden.
• Auto-Start für Webanwendungen konfigurierbar (bei Start des Application Pools) -> Zeit für erstes Laden wird verkürzt. Es ist auch möglich, einen eigenen Autostart-Provider zu schreiben.
• Extensible Output Caching: Damit ist jetzt steuerbar, was mit dem @OutputCache passiert (muss nicht mehr zwingend im RAM gehalten werden, sondern z.B. im Dateisystem oder auch gemäß einem selbst erstellten OutputCache-Provider…)
• Query Extender Control: für das vereinfachte deklarative Filtern im Backend. Für weitere Infos gibt es hier einen Blogpost dazu.
• ClientIdMode-Property: Damit kann die ClientId eines Controls endlich gezielt beeinflusst werden (ClientIdMode=static bewirkt, dass die ClientId gleich der Id auf dem Server ist – auch wenn die Seite im SharePoint läuft… )
• Verbesserung beim Rendering von Menu Controls: anstelle von Tabellen werden jetzt <ul> und <li> Elemente verwendet
• ASP.NET AJAX 4.0 ist nicht Bestandteil von ASP.NET 4.0, sondern es ist die ASP.NET AJAX Library (verfügbar via Codeplex, aber voll supported durch Microsoft) erforderlich. Diese enthält
  • die MS AJAX Library
  • das AJAX Control Toolkit
• in Visual Studio 2010 wurde nicht nur die Intellisense-Unterstützung für JavaScript verbessert, sondern es gibt jetzt auch Code Snippets für JavaScript und HTML.

Nun geht es wieder zurück zu SharePoint: SharePoint 2010 – endlich richtig programmieren mit Jörg Krause. Den Einstieg mach eine coole Folie zur Evolution eines SharePoint-Entwicklers. Die einzelnen Entwicklungsstadien sind (sinngemäß):

1. Ablehnung (“Das geht doch überhaupt nicht!”)
2. Ärger (“Wieso gerade ich?”)
3. Geschäftstüchtigkeit (“Das ist mein Job, also werde ich ihn machen!”)
4. Depression (“Es geht nicht, es ist nicht hinzukriegen – es geht einfach nicht!”)
5. Akzeptanz (“Es geht, wenn es auch nicht einfach ist.”)

Es ist den anwesenden Entwicklern im Raum anzumerken, dass sie wissen, worüber hier gesprochen wird… Der Vortrag selbst behandelt viele Fragen, mit denen ein SharePoint-Entwickler sich im Laufe seines Entwicklerdaseins auseinandersetzen muss - hier sollen noch die Tools aufgelistet werden, die für die Entwicklung für SharePoint 2010 unverzichtbar sind:

• Visual Studio 2010
• SharePoint Designer 2010
• Fiddler
• IE Developer Bar (Anm.: ich würde Firebug fast noch vorziehen)
• Reflector
• SDK Tools: psconfig (Power Shell), stsadm, SPMetal

Das Ende der Mittagspause wird durch eine eingeschobene Keynote zu Windows Phones mit Frank Prengel ersetzt. Beeindruckend für mich ist die neue Erkenntnis von Microsoft : “… a phone is just not a PC”!

Und weiter geht es mit SharePoint: SharePoint Object Model – From SPFarm to SPListItem mit Jörg Krause. Auch hier wieder etliches schon Bekanntes, erfreulich die Arbeitserleichterungen mit SharePoint 2010 bzw. Visual Studio 2010:

• neue Templates in Visual Studio
• neue EventReceiver für Listen, Workflows und Webs
• F5 Debugging Experience

Last not least noch ein paar wichtige (und vor allem hilfreiche! ) Hilfsklassen, die jeder Entwickler benutzen sollte, anstatt “das Rad neu zu erfinden”

• SPUtility
• SPUrlUtility
• DateOptions
• SPHttpUtility
• (SPDiffUtility)

Nach dem Abendbrot kommt noch ein richtiges Bonbon in Form einer weiteren Keynote: Why Software sucks – and what you can do about it mit David S. Platt.

Eigentlich ist es ganz simpel, was der Nutzer will: “I just want it to work!”. Warum tun wir’s nicht einfach?!

Laut David gilt es genau ein, unumstößliches, Prinzip zu beachten: KNOW THY USER, FOR HE IS NOT THEE. Dies belegt er uns eindrucksvoll (und unter vielen Heiterkeitsausbrüchen) an diversen Beispielen. Und es ist ja wirklich wahr: der Durchschnittsnutzer von Software (speziell im Internet!) ist nun mal kein männlicher, zumeist studierter, Programmierer, welcher ein Auto ohne Automatikschaltung fährt.

Nachdem er uns einige abschreckende und auch gelungene Beispiele aus dem Leben gezeigt hat (hier sei nur so viel verraten: Google schneidet besser ab als Microsoft – aber es gibt auch noch Schlimmeres…), gibt David uns noch ein paar Tipps mit, um dem Problem beizukommen:

1. Add a virgin to the design team (“Blindness improves your vision”).
2. Break convention when needed.
3. Don’t let edgecases complicate the mainstream.
4. Instrument — carefully.
5. Allways ask: Is this individual design decision bringung us  closer to “just working” or farther?

So: Make it just work!