Archiv für Dezember 2012

Das war unser IT-Jahr 2012 und so geht es weiter …

Freitag, 21. Dezember 2012

„Es wird noch größer, spektakulärer und noch viel effizienter…“ hört man oft zu Beginn des Jahres, vor allem, wenn man von High-Tech-Trends für das kommende Jahr spricht. Doch ist das wirklich so? Die Mitarbeiter von ProTechnology haben sich digital in einem Diskussionsforum zusammengefunden und das Jahr 2012 Revue passieren lassen: „Liebe Kollegen, war es denn noch größer, spektakulärer und effizienter als das Jahr zuvor?“ Die Meinungen sind gespalten – klar bei ProTechnology und in der Welt ist viel passiert und innoviert wurden, jedoch sagt die Kristallkugel für das Jahr 2013 noch viel mehr Effizienz voraus. Wer hätte das gedacht. Warum? Es wird noch mehr mobiles Internet, noch mehr Social Media, noch mehr Digitalisierung geben, nicht nur allein, weil Microsoft seine komplette Office-Welt umstellt. Das moderne, überall auffindbare Büro ist nicht mehr allzu weit von uns entfernt. Zunächst schauen wir aber zurück.

Für ProTechnology war es ein sehr gelungenes Jahr. Wir veröffentlichten viele neue Kunden-Success-Stories,  aber auch neue Mitarbeiter begrüßten wir im ProTechnology-Team. Erst kürzlich haben wir zwei Studenten der HTW im Rahmen des Deutschlandstipendiums im Team hinzugewonnen. Auf diesem Weg nochmal „Herzlich Willkommen“

Doch was gab es noch Neues?

Microsoft hat auf der diesjährigen SharePoint Conference 2012 die neue Version 2013 im Detail vorgestellt. 10.000 Besucher aus 85 Ländern sind dem Ruf gefolgt und ProTechnology war mittendrin. Neben deutlichen Verbesserungen im User Interface steht Social Collaboration im Vordergrund: Allem kann gefolgt und alles kann ge-liked werden.

Im viel kleineren Stil, aber mit gleicher Aufregung, war unser Vortrag einen Tag vor Nikolaus auf dem Mitteldeutschen Unternehmertag 2012. Auf großer Bühne präsentierten drei ProTechnology-Kollegen und Jörg Jasper von Microsoft alles zum Thema „Optimieren Sie Ihren Vertrieb und gewinnen Sie strukturiert, aber garantiert neue Bestandskunden“ Hier mal ein kleiner Eindruck:

Doch auch in unserem allgemeinen Arbeitsalltag hat sich Einiges getan: Die Software der ProTechnology wird nun nicht mehr per Turnschuhadministration verteilt, sondern durch SCCM 2012. Das ist auch ein wichtiger Schritt, vor allem, da wir zu Beginn des neuen Jahres zwei neue Standorte mit Stuttgart und Zwickau, hinzubekommen sowie die Büroräume in Dresden um zwei Etagen weiter ausgebaut werden, denn so langsam wird es eng in der dritten Etage der Antonstraße 3a. Apropos dritte Etage – der Blick aus unseren oberen Büroetagen ist, gerade zu Weihnachten, herrlich:

Windows 8 und Office 2013 setzen auf die Cloud. 2012 stand auch im Zeichen der Cloud und wir garantieren jedes weitere Jahr wird ein Cloud-Jahr sein, denn dieser Trend ist nicht nur eine Phase. Genau aus diesem Grund haben wir schon umgerüstet und ProTechnology ist fast vollständig in die Wolke transferiert: Wir migrierten in diesem Jahr unseren Lync-Server und den Team Foundation Server in die Cloud. Ob sich der Umzug dahin gelohnt hat, erfahren Sie hier.

Auch das moderne Office ist bei uns schon längst da: Alle Mitarbeiter arbeiten seit Wochen mit Windows 8, Office 2013 und Lync 2013. Was sagen die Kollegen dazu?

Ich finds knorke!           Viele neue praktische Features!              Es ist irgendwie… Neu :)           Neu und cool! Chic :)     Office 2013 und Windows 8 ein wenig design-arm, dafür praktischer geworden.     Ich bin schon app-süchtig.         Noch schneller, noch besser integiert. optimal für effizientes Arbeiten – privat und im Unternehmen :)

Ausblick

In der Einleitung wurde es bereits erwähnt, es wird noch mehr mobiles Internet, noch mehr Social Media, noch mehr Digitalisierung geben, nicht nur allein, weil Microsoft seine komplette Office-Welt umstellt. Doch was kommt da 2013? Die großen vier Trends aus dem Vorjahr „Mobile IT, Cloud Computing, Big Data und Social Media“ sind zum Großteil auch die Prognosen für das Jahr 2013, denn diese Themen sind so einschneidend, dass sie noch über Jahre aktuell sind. Der Punkt “Mobile Apps und/oder HTML5“ kommt 2013 noch hinzu. Erwartet wird ein langfristiger Wandel hin zu dem neuen Web-Standard HTML5. Trotzdem dürften die bei Usern von mobilen Endgeräten so beliebten Apps nicht einfach verschwinden. Bei der Programmentwicklung müssen sich die Unternehmen in den nächsten Jahren verstärkt darauf konzentrieren, noch optimalere Anwendungen für die mit Berührung gesteuerten mobilen Endgeräte zu entwickeln. Auch die Apps müssen für eine größere Bandbreite von Endgeräten tauglich gemacht werden.

In diesem Sinn wünschen wir unseren Blog-Lesern, Freunden, Partner und Kunden eine besinnliche Weihnachtszeit und ein erfolgreiches, innovatives Jahr 2013.

Autor: Melanie Wolf

Lokalisierung aus der Datenbank in ASP.NET MVC

Mittwoch, 12. Dezember 2012

Es war einmal ein kleines Kind. Dieses lief seit einigen Monaten und erfreute sich großer Beliebtheit. Doch dieses Kind war nicht so einfach zu betreuen, wie der Herr Vater sich das vorstellte. Bei der Korrektur eines Sprachfehlers, musste man es ständig neu gebären, was auch die Frau Mutter nicht sehr erfreute. Also dachte sich der Herr Vater: “Es muss doch eine Möglichkeit geben, die Sprache des Kindes direkt in seinem Kopf zu korrigieren.”  So, oder so ähnlich, muss es wohl gewesen sein, als der Mensch lernte, seine Sprache in seinem Kopf zu speichern. Doch was ist, wenn das Kind ein Projekt ist? Ständig muss man die Anwendung neu deployen, obwohl man doch nur ein paar Texte und/oder Benennungen verändert hat. Oder man lagert Bereiche, welche sich häufiger ändern (könnten), einzeln in die Datenbank aus. Das klingt nicht nur unflexibel, es ist auch unflexibel. Gerade bei längeren Release-Zyklen oder ewig ladenden Azure-Instanzen wird so eine kleine Textänderung schnell zur Geduldsprobe. Also ab mit den Texten in die Datenbank… und zwar zackig!

Meist nutzt man Resourcendateien, um unterschiedliche Sprachen seiner Webanwendung bereitzustellen. So mancher hat dieses Problem sicherlich längst erkannt und greift die einzelnen Sprachelemente direkt aus der Datenbank ab, statt Resourcen zu verwenden. Doch was ist mit Fremdassemblies, die sich möglicherweise nur über Resourcen lokalisieren lassen? Hier kommt der Ansatz mit einer ResourceProviderFactory zum Zuge. Diese gibt einem die Freiheit, die angefragten Resourcenwerte bspw. aus einer Datenbank oder einem Service zu saugen. Ganz nebenbei lässt sich diese natürlich mit der manuellen Variante ansteuern, um ggf. mächtigere Abfragen zu tätigen. Doch bleiben wir beim Thema.

Schritt 1: Wie sieht so eine ResourceProviderFactory aus?

Bis dahin also noch nichts Spektakuläres. Die Factory erstellt in unserem einfachen Beispiel lediglich eine neue Klasse des ResourceProviders. Dieser enthält nun unsere Logik, um die entsprechenden Resourcen, möglichst geschickt, aus der Datenbank zu saugen. Dabei wird entweder lediglich der Klassenname bei globalen Resourcen oder der virtuelle Pfad bei lokalen Resourcen als ResourceSet übergeben, welches wir in unserem ResourceProvider halten werden. Je nach belieben kann dies für globale und lokale Resourcen in einzelne Klassen getrennt und/oder zusätzlich gefiltert werden.

Schritt 2: Der ResourceProvider verrichtet also das eigentliche Werk. Aber wie?

Dazu muss unser ResourceProvider lediglich die Interfaces “IResourceProvider” und “IImplicitResourceProvider” implementieren. Das sieht im Wesentlichen folgendermaßen aus:

Wie so oft, sagt sich das allerdings wesentlich einfacher, als es dann tatsächlich ist. Gleichermaßen sieht der entstandene Code viel komplexer aus, als er dann tatsächlich ist. Schwer, einfach, schwer, einfach, was denn nun? Angesichts des Gesamtkunstwerks, was uns schon bald erwartet, würde ich zu “Schw’einfach” tendieren. Aber sehen Sie selbst.

Zunächst implementieren wir die Methoden “GetObject” beider Interfaces. Auch hier machen wir kein großes Hexenwerk und verweisen auf eine allgemeingültige Methode “GetObjectInternal”. Lediglich die Methode “ConstructFullKey” zerlegt unseren ImplicitResourceKey, um den eigentlichen ResourceKey herauszufiltern.

Diese Methode “GetObjectInternal” hat eine einfache Aufgabe: Sie holt nun endlich unseren Text aus der Datenbank. Dies geschieht im Folgenden über einen “LocalizationService”, welcher dann direkt auf ein typisiertes DataSet zugreift. Für die Abfrage werden hier die drei Werte zur Identifikation eines Resourcevalues übergeben: Culture (bspw. “de-DE”), ResourceSet (bspw. “Errors” oder “/Views/Shared/Site.Master”) und ResourceKey (bspw. “SiteTitle”). Als Ergebnis dieser Methode erhält man den passenden String (bspw. “Startseite”).

Damit haben wir nun einen wichtigen Teil unserer Anwendung fertiggestellt. Doch aufmerksame Leser werden sicherlich bemerkt haben, dass wir noch nicht alles implementiert haben. Uns fehlt noch die Property “ResourceReader” und die Methode “GetImplicitResourceKeys”, welche eine ICollection zurückliefert. Zudem fällt im obigen Bild auf, dass die Methode “GetObjectInternal”, neben der Serviceanfrage in der Datenbank, zusätzlich eine Methode “GetResourceCache” anspricht.

Schritt 3: ResourceReader und ICollection? Das klingt verrückt.

Die nun angerichtete Verwirrung lässt sich ziemlich schnell wieder auflösen. Grundsätzlich unterscheidet man in diesem ganzen ResourceProvider zwischen zwei Varianten, um Resourcen abzuholen: Einen einzelnen Wert oder eine Auflistung von Werten eines bestimmten ResourceSets und/oder einer spezifischen Culture. Erstere haben wir in unserer Methode “GetObjectInternal” gebündelt abgehandelt. Zweitere werden wir nicht ganz so elegant bündeln, nutzen aber im Kern die gleiche Funktionalität. Doch genug des Vorgeplänkels und zurück in die Praxis.

Fangen wir mit der Methode “GetResourceCache” an. Diese holt uns nun die erwähnten Werte aus der Datenbank und sortiert sie fein säuberlich in unseren Cache. Dazu nutzt sie die übergebene Culture und das festgelegte ResourceSet. Wenn erledigt, gibt sie unseren Cache zurück, damit der Aufrufer damit arbeiten kann.

Und weil es gerade so spaßig ist, springen wir direkt zu der Methode “GetImplicitResourceKeys”. Der nun folgende Code mag durchaus Geschmackssache sein, sieht aber komplizierter aus, als er tatsächlich ist. Wir lesen lediglich unseren ResourceReader aus, filtern dabei nach unseren keyPrefix und trennen schlussendlich nur den ResourceKey unter Verwendung unseres keyPrefixes, um damit einen ImplicitResourceKey erstellen zu können. Zurückgegeben wird also letztlich nur eine ICollection von ImplicitResourceKeys. Nähere Infos dazu lassen sich im MSDN nachlesen.

Zu guter Letzt benötigen wir noch unseren ResourceReader, den wir bereits oft genug verwendet, aber bisher nicht implementiert haben. Groß angekündigt, aber weniger spektakulär: Unser herzallerliebster ResourceReader ist im Grunde nämlich nichts weiter, als ein kleiner Wrapper für unser ResourceCache-Dictionary. Dies sieht dann wie folgt aus.


Schritt 4: Und wie binde ich dieses Kunstwerk nun ein?

Das ist wohl mit Abstand der “schwierigste” Teil unseres Abenteuers. Man fügt einfach folgendes Schnipsel in seine web.config und schon kann sich gefreut werden. Kernbestandteil ist hier natürlich der Wert des Attributs “resourceProviderFactoryType” des Elements “globalization”.

Fazit

Ich hoffe, den meisten Lesern ist bis hierhin bereits klar geworden, welche Vorteile die Implementierung des ResourceProviders und der ResourceProviderFactory mit sich bringt. Es ist nun möglich, viele Stellen in gewohnter Weise zu lokalisieren. Selbst die guten alten meta:resourcekey-Angaben funktionieren damit. Zudem kann man, wie in diesem Beispiel, einen eigenen Service, den man vorher ggf. nur manuell angesprochen hat, zur Lokalisierung anbinden.

Trotz der ganzen Vorteile überkommt mich immer ein seltsames Gefühl, wenn ich mir den entstandenen Code anschaue. “Schw’einfach” trifft es, denn es ist schwer und einfach zugleich, was in meinem Fall aber hauptsächlich an der Verworrenheit der beiden Interfaces liegt. Aber es funktioniert, ist nützlich und kann mit ein wenig mehr Arbeit durchaus noch “sauberer” implementiert werden.

Zudem sollte noch erwähnt sein, dass die Auslagerung der Lokalisierung in die Datenbank, einen weiteren Vorteil mit sich bringt: Es kann problemlos eine Administrationsoberfläche (Web-/ Windowsanwendung) aufgesetzt werden. Mit dieser kann man sogar Resourceninhalte komfortabel mit HTML formatieren, was je nach Einbindung der Resource (<%: vs <%=) kodiert oder nicht kodiert wird. Auch denkbar wäre die Möglichkeit für vorhandene Benutzer, mit an der Übersetzung zu arbeiten.

Als kleiner Bonus zur Weihnachtszeit gibt es die gesamte Solution auch noch zum Download.
In diesem Sinne: Viel Spaß damit!

Quellen: MSDN
Autor: Dirk Sarodnick
Google+

Veröffentlichen einer Webseite – der nun einfache Weg mit Visual Studio 2012

Donnerstag, 06. Dezember 2012

Visual Studio 2012 stellt eine überaus gelungene Möglichkeit bereit, um Webseiten auf einem Webserver zu veröffentlichen. Wie genau die One-Click-Veröffentlichung mit Visual Studio vonstatten geht, vermittelt dieser MSDN Eintrag.

Der eine oder andere dürfte jedoch beim Versuch eine Veröffentlichung durchzuführen, folgenden Fehler bekommen haben:

In den meisten Umgebungen hält man sich einfach an die von Microsoft beschriebenen Schritte um einen Webserver für die Annahme von Web-Veröffentlichungen zu konfigurieren: der IIS ist schon da und Web Deploy 3.0 wird über den Web Platform Installer bereitgestellt. Dann stellt man aber fest, dass man noch den IIS Verwaltungsdienst benötigt, um zum Ziel zu kommen. Hier beginnt allerdings “der Hamster zu humpeln”, denn wenn die eben genannte Reihenfolge eingehalten wird, werden beim Installieren des Web Deploy-Paketes für den Betrieb notwendige Teile stillschweigend übersprungen.

Installiert man Web Deploy 3.0 mittels des hier erhältlichen MSI-Paketes, wird deutlicher wo das Problem liegt: das linke Bild veranschaulicht, dass der Dienst nicht installiert ist. Ist er installiert, wird das rechte Bild angezeigt:

Ist der IIS Verwaltungsdienst bei der Installation von Web Deploy 3.0 noch nicht vorhanden gewesen, bleibt einem nur die Option erneut zu installieren oder die installierten Funktionen von Web Deploy über die Systemsteuerung zu ändern. Zu prüfen ist jetzt noch, ob die beiden Dienste (Webbereitstellungs-Agent-Dienst und Webverwaltungsdienst) auch automatisch gestartet werden und laufen.

Übernehmen sollte der Web Platform Installer eigentlich auch die Freigabe des Ports 8172 in der Firewall. Ist diese Freigabe nicht vorhanden, klappt die Verbindung nicht.

Versucht man jetzt erneut die Veröffentlichung im Visual Studio sollte man in etwa folgendes Ergebnis bekommen:

Fazit: Um der Überschrift nun dennoch gerecht zu werden, haben wir ein kleines Powershell Script bereitgestellt, was die oben beschriebenen Schritte automatisch durchführt.

Autor: Kirsten Kluge
Quellen: MSDN Eintrag, Web Deploy 3.0, Web Platform Installer, msi-Paket