Windows 8 – Irrweg oder einfach ein Irrer Weg

Es ist nun eine Woche her (13.09.2011), das Microsoft in Anaheim / Florida auf der “BUILD Windows” das Geheimnis um Windows 8 gelüftet hat.

Nun liegen die Fakten um Windows 8 auf dem Tisch!

  • Doch stehen die Fakten mit der Präsentation von Windows 8 wirklich fest?
  • Was wurde uns eigentlich als Windows 8 verkauft?
  • Worüber freuen wir uns?
  • Worüber ist die eine oder andere Gruppe betrübt?

Um diese Fragen und die meine Wahrheit um Windows 8 zu klären,  müssen wir aber auch die jüngere Vergangenheit vor der Öffentlichen Präsentation von Windows mit einbeziehen.

Denn die eigentliche Geschichte um Windows 8 beginnt bereits einige Wochen vor der BUILD in Anaheim.

Was ist in den letzten Wochen wirklich geschehen:

In den Tagen und Wochen vor der BUILD wurde viel Spekuliert.
Teilweise wurden echte Schreckensszenarien vermittelt.
Leider wurde auch von, sonst sachlich und nüchtern berichtenden Kollegen, mit Meldungen wie den folgenden Schlagzeilen gemacht:

  • HMTL 5 und JavaScript werden zur Standard Sprache zur Entwicklung von Desktop Anwendungen
  • Silverlight wird als Technologie nicht mehr unterstützt
  • Die Zukunft um WPF ist ungewiss
  • .NET wird es nicht mehr geben oder aussterben und damit wird auch C# und VB verschwinden
  • HTML 5 und vor allem JS sind die “must be” Sprachen für jeden Entwickler, sonst ist für Ihn/Sie der Zug abgefahren.
  • …. und ganz vieles Mehr.

Unabhängig davon, ob und wie viel davon tatsächlich irgendeiner Wahrheit nahe kommt, haben all diese Überlegungen und Gerüchte darauf basiert, dass davon ausgegangen wurde,  dass mit Windows 8 direkt von einem Nachfolger des Windows 7 wie wir es Heute kennen, einem reinen Desktopbetriebssystem,  gesprochen wird.

Doch was haben wir auf der BUILD wirklich vorgestellt bekommen?

  • Eine zu groß geratene Ausgabe von Windows Phone WP7
  • Ein neues Tablet Betriebssystem
  • Der Nachfolger des Windows 7 Desktop Betriebssystems

Ein wenig von allem!

Präsentiert hat uns Microsoft natürlich “das Neue”, das was man direkt sieht, das was vollkommen anders ist wie bisher, das was dem aktuellen Trend entspricht, das was Hype verspricht, das was ….

Das was präsentiert wurde, war die “Metro Style Oberfläche”

win8 - metro

Und dieses neue, ist doch genau das, was uns entweder empört oder begeistert hat.

Je nachdem welcher Zielgruppe man angehört, findet man diese Neuerung als “vollkommen abgefahren”, “Super Innovativ”“vollkommen daneben” oder als “Weltuntergang”.

Und ich glaube es gibt mehr Zielgruppen als wir uns das momentan überhaupt vorstellen können.

Allerdings sind die Zielgruppen, die sich bisher mit Windows 8 beschäftigt haben und sich öffentlich darüber geäußert haben, doch eher die aus dem Umfeld derer, welche sich mit der Entwicklung von Software beschäftigen, und für all diese, oder besser gesagt für die meisten von diesen, bedeutet Neuerung und Veränderung natürlich erst einmal die Angst vor Verlust.

Angst vor Verlust, Angst davor dass Wissen das man sich Jahrelang angeeignet hat, nicht weiter verwenden zu können.

Und wenn ich mir das anschaue, was Microsoft uns auf der BUILD als WIN 8 präsentiert hat, dann habe ich als Entwickler von Business Anwendungen (Egal ob als Web Anwendung, Desktopanwendung oder im Backend als Server Anwendung) im ersten Moment auch diese Angst (ganz kurz) verspürt.

Doch als analytischer Mensch lässt man sich natürlich nicht von einem Schauer der einem über den Rücken läuft lähmen und man beginnt die Sache, in diesem Fall Windows 8, mit dem notwendigen Abstand und der notwendigen Sorgfalt von den verschiedensten Seiten zu betrachten.

Ich habe die letzte Woche genutzt um mir Windows 8 genauer anzuschauen und mir Gedanken über die Auswirkungen von Windows 8 auf meinen Job als Entwickler zu machen.

Nachfolgend hierzu meine Gedanken und Thesen.

Metro Style Apps

Metro Style Apps sind nur auf Geräten mit Touch Bedienung sinnvoll einzusetzen.

Microsoft hat als Vision, dass es in Zukunft nur noch Geräte mit Touch Interface geben wird, und daher auf jedem Gerät Metro Style Apps sinnvoll eingesetzt werden können. Dem möchte ich auch nicht wiedersprechen, doch denke ich nicht, dass wir diese Zukunft noch dieses Jahrzehnt erleben werden.

Metro Style Apps werden für mich, meinen Job und meine Kunden mit oder ohne Windows 8 (damit meine ich die nächsten 2 – 3 Jahre) noch nicht wirklich eine entscheidende Rolle spielen.

Metro Style Apps werden weder Heute noch Morgen (mal schauen was übermorgen geschieht und ob dann noch jemand von Metro Style Apps spricht) als Ersatz für Rich Client Desktop Anwendungen im Büro und Produktionsstätten geeignet sein.

Wenn solche Art von Apps überhaupt für Rich Client Anwendungen eingesetzt werden sollten, wird das sicherlich noch bis Ende des Jahrzehnts und darüber hinaus dauern.

Um es nicht später zu vergessen:

Einen Wunsch an Microsoft bezüglich Windows 8 und der Metro Style Oberfläche hätte ich aber schon:

Hallo Microsoft, lasst bei der Installation von Windows 8 per Option entscheiden, welchen Desktop man als Standard verwenden möchte, den Metro Style oder den Standard Desktop  (WIN 7 Like)

Und eines noch Microsoft, solltet Ihr auf die Idee kommen, die in der Windows 8 Preview vorhandenen Möglichkeit, durch Änderung eines Registry Eintrags ein “Windows 7 Like” Startmenü zu bekommen, aus dem Final Release von WIN 8 gänzlich zu entfernen, sage ich euch mit WIN 8 ein zweites VISTA voraus (auf  jeden Fall auf Desktop PCs)

win8 - api

WinRT

Mit der WinRT stellt Microsoft den zentralen Baustein für die neue Metro Style Oberfläche zur Verfügung.

WinRT wird nicht als zusätzlicher Framework sondern als integraler Bestandteil des Betriebssystems betrachtet.

Ob WinRT wirklich eine Lösung oder mehr ein Problem ist, wird sich im Laufe der Zeit zeigen.
Ich finde es, Stand Heute sehr gewagt mit WinRT auf eine Technik wie COM (auch wenn es ein objektorientierter modernerer Ansatz ist) zurückzugreifen, die man vor fast 10 Jahren, aus guten Gründen, durch die .NET Technologie abgelöst hatte.
Einzig die Tatsache dass es in WinRT außer den WinRT eigenen DLLs keine gemeinsamen Bibliotheken gibt lässt mich hoffen, dass es kein zweite DLL Hölle geben wird.

Wer in Manage Code C# oder VB Metro Style Apps schreiben will muss sich im klaren sein, dass man dabei starken Beschränkungen unterliegt, da die WinRT nur eine Teilmenge der .NET Klassen zur Verfügung stellt.

Dinge wie direkte Dateizugriffe, Zugriffe aufs Dateisystem oder auch zugriffe auf eine Datenbank wie SQL oder andere sind nicht direkt möglich.

Um Beispielsweise auf eine Datenbank zugreifen zu können muss man sich zuerst einen Web Service erstellen, den man dann über die WinRT aufrufen kann.

Damit die Metro Style Apps immer den Eindruck hervorrufen dass Sie auf Benutzereingaben sofort reagieren, wurde in der WinRT darauf geachtet, dass alle Aufrufe die im allgemeinen länger als 50 ms dauern Asynchron aufgerufen werden.

.NET (C# 5 und VB)

.NET ist also noch nicht tot.

Neben Metro Style und dem damit zusammenhängenden WinRT wurde auch am .NET Framework gearbeitet.

Das .NET Framework 4.5 wird zusammen mit Windows 8 ausgeliefert (gibt es aber auch für Windows 7).

Zusammen mit dem Framework gehen auch die Managed Code Sprachen C# und VB in die nächste Versionsrunde.

  • C# 5.0
  • Visual Basic 11.0

Die umfangreichste Erweiterung der Sprachen besteht wohl in der Implementierung der await und async Schlüsselwörter und der damit einhergehenden Vereinfachung der Asynchronen Programmierung.

Die Zukunft von .NET dürfte wohl für die nächsten Jahre zumindest für “echte” Desktop Anwendungen” sowie natürlich für Web und Backend Anwendungen, gesichert sein.

HMTL 5 und JavaScript

Weder HMTL 5 noch JavaScript, und auch nicht die Kombination der beiden Sprachen, sind eine Erfindung von Windows 8.

Jedoch wird diese Kombination sicherlich nicht nur für die Web Entwicklung immer interessanter und wer sich bis Heute nicht damit beschäftigt hat, ist sicherlich gut beraten sich mit diesem Thema in näherer Zukunft auch ein wenig auseinanderzusetzen.

Ganz sicher dann, wenn man nicht nur Backend Programmierung betreibt.

Silverlight

Meiner ganz persönlichen Meinung nach, sieht die Zukunft von Silverlight nicht so rosig aus. Ich denke dass Silverlight mittelfristig zu den Klassischen Verlierern zählen wird und weder weiter entwickelt noch auf ewig weiter unterstützt werden wird.

Rich Web Applikationen können mit anderen Technologien wie HTML 5 zusammen mit JS auf der Client Seite erstellt und zusätzlich noch durch MVC oder ähnliche Technologien (evtl. auch mal durch node.JS) Serverseitig unterstützt werden.

Wenn man sieht, dass der IE10 in der Metro Style Variante keine Add Ins und somit kein Silverlight und kein Flash mehr unterstützt, muss man nur 1 und 1 addieren um sich über die Zukunft on SL seine Gedanken machen zu können.

Mein Tipp: Wenn du merkst, dass du ein totes Pferd reitest, steig ab!

Resümee und Weisheiten

Die Suppe wird nie so heiß gegessen wie Sie gekocht wird.
.NET lebt auch nach Windows 8 weiter, wir müssen nicht alle sofort nur noch HTML 5 und JS Programme schreiben

Der Markt und die Akzeptanz regelt im allgemeinen ganz viel alleine (Siehe VISTA), also wenn Windows 8 letztendlich wirklich nur per Touch ordentlich zu bedienen sein wird, dann wird es vermutlich ein Tablet OS aber kein Nachfolger für Windows 7

Warten wir mal ab wie Windows 8 in der Final Release dann wirklich auf den Markt kommt.

Eines habe ich übrigens vergessen, und das ist der bisher positivste Aspekt des neuen Windows:

Windows 8 startet um ein vielfaches schneller als jede andere Windows Version die es bisher gab.

Abschließen möchte ich, auch wenn dies kein Bericht über ein Fußballspiel war, mit den Worten eines großen Deutschen Fußballers:

Nach dem Spiel ist vor dem Spiel!

Freuen wir uns schon mal auf die Gerüchte und Aufregung um Windows 9.

Python leicht zu durchschauen – These oder Wirklichkeit ?

Gestern Abend habe ich (als .NET Programmierer) mir einen Vortrag über Python, eine der neuen Hype Sprachen, angeschaut.

Hiefür vielen Dank an Rainer Schuster, der im Rahmen des wöchentlichen ONLINE Stammtisches der .NET Online Usergroup, diesen Vortrag gehalten hat.

Ich hatte mich mit dieser Programmiersprache bisher noch gar nicht auseinander gesetzt, so dass ich mir, nachdem ich mit den gestrigen Vortrag angesehen habe, heute noch ein wenig mehr Informationen besorgt habe um evtl. den Hype um diese Sprache besser verstehen zu können.

Vorweg, kann ich schon mal sagen, dass mir das nicht gelungen ist, und ich nicht verstehen kann, was an einer interpretierten Sprache ohne Verwendung von Klammern so viel besser sein soll, als bei anderen Sprachen die nicht interpretiert werden müssen, und Ihre Konstrukte mithilfe von Klammern darstellt.

Auf diesen Satz mit den Klammern komme ich weil unter anderem über Python folgendes Gesagt wird:

Leicht zu durchschauen

Python hat noch einen weiteren, für Anfänger interessanten Aspekt: Die Syntax der Sprache wird weniger von Klammern als von Zeilenumbrüchen und Tabulatoren bestimmt. Man erkennt schnell, wie das Programm aufgebaut ist und gewinnt auch bei Programmen anderer Entwickler schnell einen Überblick.

Was ist denn an diesem Quellcode leichter  zu verstehen:

for i in range (10):
 print i
 print "zähle noch
for i in range (10):
 print i
print "Hallo"

Als an diesem (Beipiel C# Code)

for (int i = 0; i < 10; i++)
{
    Console.Write(i);
    Console.Write(@"Zähle noch")
}
for (int i = 0; i < 10; i++
{
    Console.Write(i);
}
Console.Write(@"Hello World");

OK OK OK,

das ist nicht alles, Python ist (Hier Argumente von Python Jüngern):

  • Open Source
  • Auf einigen (vielen) Plattformen (darunter auch ein paar exotische) verfügbar
  • Von vornherein auf Objektorientierung ausgelegt (Welchen Vorteil das auch immer mit sich bringen soll)

Auf der anderen Seite muss man doch aber auch ganz klar sehen, wen Python als Platzhirsch ansieht:

Das sind PHP und Pearl, nicht gerade die klassischen .NET Sprachen

Ist Python also die Sprache der Zukunft für uns .NET Entwickler?

Ich denke nein.

Es wird zwar gesagt, man kann mit Python alle arten von Programmen schreiben kann, das wird wohl auch nicht falsch sein.

Aber möchte ich demnächst

  • Desktop Applikationen
  • Web Portale
  • Web Services
  • Windows Dienste
  •  WP7 Apps
  • Android Apps

mit Python entwickeln.

Ich denke, dass ich das nicht möchte. Mir graust sogar davor wenn mir jemand sagen würde er hätte vor mit Python (einem Interpretativen Sprache) einen Windows Dienst, einen Mail Server oder einen Web Service zu schreiben.

Ich bin mir nicht sicher und es lässt Platz für Spekulationen und vermutlich auch für heiße Diskussionen , aber ich denke, dass Python wohl eher im nicht Windows Umfeld seinen rechten Platz hat.

Ich möchte zum Schluss noch eines anmerken:

Auch wenn .NET in den nächsten Jahren an Gewicht verlieren, und das ganze mehr in Richtung HMTL 5, 6 oder 7 zusammen mit JavaSript oder was für einer, mehr oder weniger funktionalen oder prozeduralen Sprache schwenken könnte, werde ich als heutiger .NET Entwickler vermutlich eher in diesen heute noch nicht endgültig abzuzeichnenden Bereich, als zu Python wechseln.

Google+ – Wer will noch mal, wer hat noch nicht!

Google+ ist nun seit mehreren Wochen ONLINE und so gut wie aus dem Beta Stadium heraus.

Ich finde zwar, dass noch einige Dinge fehlen, aber für ernsthaften Gedankenaustausch, Problemlösung und Diskussionen aller Art, mit Kollegen Freunden und Gleichgesinnten, bietet Google+ aber auch jeden Fall die bisher beste Lösung an.

Nun hat Google seit eingen Tagen das Netzwerk etwas mehr geöffnet und jeder der bereits einen Google+ Account hat, kann 150 weitere Einladungen verschenken.

Entweder, indem man einen Invite an eine E-Mail Adresse sendet oder sei einigen Tagen neu, indem man einfach auf einen von Google freigegeben Link klickt.

Und genau diesen Link möchte ich hier interessierten zur Verfügung stellen.

Wer also noch keinen Google+ Account hat und gerne einen hätte, der kann sich diesen einfach durch anklicken des nachfolgenden Link erhalten.

Das sollte 150 mal funktionieren, wobei ich denke dass mittlerweile die meisten, wenigsten aus meinem Umfeld und somit auch die Leser dieses Blogs, bereits einen Google+ Account haben und daher dieser Link recht lange noch genügend Invites zur
Verfügung stellen sollte.

So hier nun der Link

Google+ Einladung hier klicken

Man sieht sich dann auf Google+

Mich findet man übrigens unter folgendem Link auf Google+

http://gplus.to/schelianhp

StyleCop – Manchmal muss man auch Regeln brechen – Rule Suppressions

Jemand, der wie ich, StyleCop zur Einhaltung und Durchsetzung von Coding Styles einsetzt, versucht im allgemeinen möglichst viele der vorgegebenen Regeln aktiviert zu lassen und beim schreiben von Source Code diese Regeln um und einzusetzen um einheitlichen Source Code zu produzieren.

Je nach Einsatzgebiet, globalen Vorgaben oder Absprachen der Entwicklerteams kann es natürlich vorkommen, dass einzelne Regeln generell deaktiviert werden.Dies sollte dann aber wirklich gut überlegt sein, und auch nicht ständig geändert werden und sozusagen zum eigenen Regelwerk werden.

Nun kann es aber trotz dem größten Willen alle aktiven Regeln einzuhalten, an der einen oder anderen Stelle dazu kommen , dass man Code schreibt, der in diesem speziellen Fall genau so gewünscht ist,  aber so wie er geschrieben wurde gegen eine Regel verstößt.

Wenn man ein Tool wie StyleCop einsetzt, dann ist dass Ziel das ein Projekt ohne StyleCop Warnungen durchläuft. Also ohne einen Bruch der Regeln. Wenn aber an einer bestimmten Stelle bewusst eine Regel gebrochen wird, dann sollte dies Möglich sein, sollte aber genau dokumentiert sein.

Um diesem Umstand gerecht zu werden, gibt es die Möglichkeit bestimmte Regeln auf verschiedenen Ebenen zu unterdrücken.

Mit Ebenen sind hier jede Art von Code Elementen gemeint wie:

  • Klassen
  • Methoden
  • Felder
  • Eigenschaften
  • usw.

Doch zuerst möchte ich mal ein solches Beispiel zeigen, bei dem StyleCop eine Warnmeldung ausgibt, ich aber den Code aus genau so und nicht anders schreiben möchte. Wir müssen an dieser Stelle nicht über den Code diskutieren, da er hier lediglich als Beispiel dienen soll.

Hier nun die gewollte Code Variante, die aber von StyleCop angemeckert wird:

string cmd = new StringBuilder("PORT ").
  Append((short)hostBytes[0]).Append(",").
  Append((short)hostBytes[1]).Append(",").
  Append((short)hostBytes[2]).Append(",").
  Append((short)hostBytes[3]).Append(",").
  Append((short)portBytes[0]).Append(",").
  Append((short)portBytes[1]).ToString();
 

StyleCop gibt bei diesem Code die nachfolgenden Meldungen aus:

StyleCop kommt hier nicht mit der Aufteilung der Methodenaufrufe auf mehrere Zeilen klar.

Ich möchte aber auf keinen Fall den folgenden Code in meinem Source Code haben, der würde zwar den Ansprüchen von StyleCop entsprechen aber nicht meinen.

string cmd = new StringBuilder("PORT ").Append((short)hostBytes[0]).Append(",").Append((short)hostBytes[1]).Append(",").Append((short)hostBytes[2]).Append(",").Append((short)hostBytes[3]).Append(",").Append((short)portBytes[0]).Append(",").Append((short)portBytes[1]).ToString();

Alternativ würde StyleCop auch mit dem nachfolgenden Code zufrieden sein. Doch den möchte ich auch nicht.

StringBuilder stringBuilder = new StringBuilder("PORT ");
stringBuilder.Append((short)hostBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[1]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[2]);
stringBuilder.Append(",");
stringBuilder.Append((short)hostBytes[3]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[0]);
stringBuilder.Append(",");
stringBuilder.Append((short)portBytes[1]);
stringBuilder.ToString();
string cmd = stringBuilder.ToString();

Wenn ich also dich den Code verwenden möchte den StyleCop angemeckert ohne das dadurch der Code angemeckert wird, muss ich StyleCop dazu bringen genau an dieser Stelle die Meldungen zu unterdrücken.

Hierzu verwenden wird aus dem NameSpace System.Diagnostics.CodeAnalysis ein Attribut mit dem Namen SuppressMessage und packen dieses Attribut an die Methode, Klasse oder was auch immer, um die StyleCop Regel genau an der gewünschten Stelle zu unterdrücken.

Nähere Informationen zur Verwendung der „Rule Suppression“ für StyleCop findet man hier auf der Codeplex Seite von StyleCop

Nun aber das Beispiel anhand einer Methode um die StyleCop Meldungen für diese Methode zu untedrücken.

[SuppressMessage("StyleCop.CSharp.SpacingRules", "SA1019:MemberAccessSymbolsMustBeSpacedCorrectly")]
internal static string TestRule(byte[] hostBytes)
{
    string cmd = new StringBuilder("PORT ").
        Append((short)hostBytes[0]).Append(",").
        Append((short)hostBytes[1]).Append(",").
        Append((short)hostBytes[2]).Append(",").
        Append((short)hostBytes[3]).Append(",").ToString();

    return cmd;
}

Wobei fogendes gilt:

Für die StyleCop Regeln kommen folgende Kategorien in betracht:

  • StyleCop.CSharp.DocumentationRules
  • StyleCop.CSharp.LayoutRules
  • StyleCop.CSharp.MaintainabilityRules
  • StyleCop.CSharp.NamingRules
  • StyleCop.CSharp.OrderingRules
  • StyleCop.CSharp.ReadabilityRules
  • StyleCop.CSharp.SpacingRules

Als Rule ID muss die jeweilige Rule ID bestehend aus der Nummer und dem Text ab besten aus dem Rules Konfigurations Bereich des SyteleCop Add In herause gelesen werden. (Siehe nachfolgende Abbildung)

DotNetNuke – Mehrsprachige Portale auch mit der Version 6 noch immer nicht wirklich realisierbar

Vorab die Kernaussage dieses Beitrags für all diejenigen die nicht meinen ganzen Frust und viele Einzelheiten zu dem Thema „Mehrsprachige Portale mit DotNetNuke“ lesen möchten.

Auch mit DotNetNuke 6.0 werden im Core Mehrsprachige Portale nicht umzusetzen sein.

Ich hatte gehofft einen solchen Artikel niemals schreiben zu müssen, aber nachdem auch nach 9 Jahren, die DotNetNuke Mannschaft es nicht geschafft hat, DotNetNuke mit echten Mehrsprachigen Funktionalitäten auszustatten, denke ich, dass wir es wirklich aufgeben können, auf eine durchgängige Corelösung zu warten.

Ich hatte die Hoffnung, dass im Zuge der großen Umstellung von VB zu C# nun endlich die weichen gestellt werden, aber leider wurde diese Hoffnung nicht erfüllt.

Nicht jetzt und nicht mit diesem Konzept, dass sicherlich nur von Englischen Muttersprachlern über dem großen Teich verstanden und verteidigt werden kann.

Ich möchte nur kurz das Prinzip des Konzepts erläutern (ausführlicher Lohnt sich wirklich nicht)

  • Start Konzept
    • Es werden alle Seiten und alle darauf vorhandene Module für jede installierte und aktivierte Sprache dupliziert.
  • Ende Konzept

OK, ein klein wenig mehr hat man sich dabei evtl. schon gedacht, aber ich sagte ja, ich wollte nur das Prinzip beschreiben, und viel mehr ist es auch nicht.

Soweit könnte man sich aber mit dem Grundkonzept abfinden, da dieses Konzept zumindest einen Vorteil hätte:

Vorhandene Modul (die Meisten jedenfalls) wären ohne spezielle Anpassung lokalisierbar.

Die Implementierung selbst übertrifft aber an Unübersichtlichkeit alles was ich bisher gesehen habe. das fängt schon damit an, das die Umstellung auf Content Lokalisierung eine Einbahnstrasse ist.

Wer einmal sein Portal auf Content Lokalisierung umgestellt hat, der hat es umgestellt und kann diese Einstellung nicht mehr zurücknehmen.
Hier hilft nur ein Backup, oder sehr aufwendige manuelle Anpassungen und Änderungen in der Datenbank, welche, ich würde mal vermuten „außer mir“ noch maximal eine Handvoll Deutsche DotNetNuke Entwickler vornehmen könnten. (Etwas Werbung darf auch mal sein 🙂 )

Hinzu kommt, dass das Handling dieser Funktionalitäten so „unintuitiv“ sind, dass man alleine um diese Funktionalität einem Kunden zu vermitteln mehr Schulungsaufwand benötigen würde, als für alle anderen Funktionen inklusive Systemadministration zusammen notwendig wären.

Erschwerend kommt aber noch hinzu, dass bei diesem Konzept nachfolgende Themen völlig unberücksichtigt sind:

  • DotNetNuke Host Listen
  • Benutzergruppen
  • Taxonomie
  • Suche

Wie über den Teich zu hören ist, sind die Herren Walker und Co. der Meinung, dass alles, so wie es ist gut ist, und wollen an diesem Konzept festhalten. Man hört einfach nicht auf den falschen Weg weiter zu gehen.

Aber es ist auch kein Wunder, wenn man sieht das bereits seit 2003 immer wieder Team Mitglieder oder dem Produkt nahe stehende Entwickler die sich für echte Belange von Mehrsprachigkeit eingesetzt (und auch ausgekannt) haben keine langfristigen Karten im Core DNN Spiel hatten.

Ich erinnere mich, dass bereits im Jahr 2003/2004 eine Version 1.x gab die für den Deutschen (Mehrsprachigen) Markt angepasst war. Personen die an dieser Version mitgearbeitet haben, wurden damals nicht gerade positiv übern Teich betrachtet.

Es liegt nicht daran, dass DotNetNuke Grundsätzlich nicht mit dem richtigen Konzept Mehrsprachig gemacht werden könnte.

Aber eben mit dem richtigen Konzept, den richtigen Leuten  (denen die etwas davon verstehen) und einer notwendigen Lobby um diese Änderungen durchsetzen zu können.

Leider sind die Herren und Schöpfer von DotNetNuke auf diesem Ohr über Jahre hinweg und ich behaupte auch Heute noch immer vollkommen Taub.

Wenn das Konzept der Lokalisierung von statischen Texten in ASP.NET Anwendungen nicht so einfach und vom Framework vorgegeben worden wäre, dann würden wir, so glaube ich wenigstens, Heute noch darauf warten DotNetNuke für nicht Englische Webseite nutzen zu können.

Zumindest ohne ein Unikat zu erstellen, dass dann nicht mehr aktualisierbar wäre.

Natürlich gibt es Drittanbieter Lösungen für Mehrsprachige Portale mit DNN, aber ich finde keine dieser Lösungen funktioniert zu 100% und außerdem gehört dieses Thema nicht in die Hände von Drittanbietermodulen sondern in den Core eine Produkts.

Wenn ich Heute wirklich ein Mehrsprachiges Portal aufbauen muss, dann verwende ich entweder nicht DNN oder falls es DNN sein muss (wegen zu verwendender vorhandener Module), dann nehme ich eine Child Portal Lösung (Für jede Sprache ein eigenes Child Portal), das ist übrigens sehr nahe am „neuen“ Konzept der Version 6.0.

Doch mit dieser Lösung sind wenigstens das Taxonomie und Suchprobleme gelöst.

BlogEngine.NET – Blog Software aktualisiert (Update 2.0.0.36 –> 2.0.0.69)

Wenn man sich den kleinen Versionssprung in der Überschrift ansieht „Version 2.0.0.36 auf 2.0.0.69“ dann würde man eigentlich denken, dass es sich dabei im ein marginales Update handelt.

Weit gefehlt, wenn man sieht,was dieses Update für Änderungen mit sich bringt:

  • Änderung des verwendeten NET Framework von 2.0 (NET Framework 3.5) auf 4.0
  • Einführung von Razor
  • Einführung einer Gallery Funktion für Themes (voll implementiert)
  • Einführung einer Gallery Funktion für Externsions und Widgets (zur Zeit nur Download soll aber später auch direkte Installation ermöglichen)
  • … Wer mehr Einzelheiten lesen möchte, kann dies in dem Detaillierten Beitrag von Klaus_b@.NET

Das Update selbst verlief ohne größere Probleme (siehe mein nachfolgendes Problem).

Ich hatte auf einem Server installiert, der noch keine MVC DLL Datein im Global Assembly Cache installiert hatte, und das hatte zur Folge, dass nach dem Update ein Fehler wegen der nicht vorhandenen DLL Dateien für die Verwendung von Razor aufgetreten ist.

Man kann diese Problem auf zwei verschiedene Arten lösen.

Man installiert MVC3 auf dem Server, insofern man vollen Zugriff auf den Server hat.

Man kopiert die notwendige DLL Dateien:

  • Microsoft.Web.Infrastructure.dll
  • System.Web.Helpers.dll
  • System.Web.Razor.dll
  • System.Web.WebPages.Deployment.dll
  • System.Web.WebPages.dll
  • System.Web.WebPages.Razor.dll

in das BIN Verzeichnis des BlogEngine Web Verzeichnisses.

Bevor ich es vergesse, das Update habe ich auf meine neuen Englischsprachigen Blog http://blog.schelian.com durchgeführt.

BlogEngine.NET – Twitter Widget einrichten (BlogEngine von 0 auf 100)

Die BlogEngine 2.0 enthält bereits ein Twitter Widget.



Nachfolgend sehen wir die notwendigen Einstellungen des Twitter Widget.

Hier muss man nun die  „Twitter Account URL“, die wie nachfolgend aufgebaut ist eingeben.

  • http://twitter.com/[TwitterUserName]

Als Beispiel nachfolgend meine „Twitter Account URL“

  • http://twitter.com/SchelianHP

Seine „Twitter Account URL“ dürfte den meisten bekannt sein, anders sieht es jedoch mit der sogenannten „Twitter RSS feed URL“ aus, die Daten für diese URL sind nicht ganz so einfach zu ermitteln.

Das generelle Format dieser URL lautet wie folgt.

  • http://twitter.com/statuses/user_timeline/[TwitterID].rss

Seine  TwitterID kennt vermutlich nicht jeder und kann leider auch nicht einfach auf der Twitter seite abgeufen werden. Neben vielen verschiedenen Möglichkeiten in Drittanbieter Modulen zu Twitter zu seiner TwitterID zu kommen, bevorzuge ich die einfachste Varianten.

Hierzu ruft man einfach die URL http://www.idfromuser.com/ auf.

Nun gibt man seinen Twitter Username in das Eingabefeld ein und betätigt den Button Get ID…

Und Schwups hier haben wir die benötigte ID.

Diese fügen wird dann an der richtigen Stelle in der URL ein, und dann sieht diese wie folgt aus (also mit meiner ID).

  • http://twitter.com/statuses/user_timeline/117727411.rss

Jetzt noch die Anzahl anzuzeigender Tweets und den Aktualisierungsintervall eingeben, fertig.

Das Widget ist sicherlich nicht der letzte Schrei wenn es um Darstellung geht, aber funktional …. einfach und perfekt.


Reihe: „BlogEngine von 0 auf 100“

Darius quatscht mit Christian über WebMatrix Razor und Co!

Die Überschrift hätte auch lauten können.

Bericht zum WebMatrix Web Camp in Bad Homburg am 22.03.2010.

Doch eine solch trockene Überschrift wäre dem Event nicht gerecht geworden.

Darius Parys, Microsoft Technical Evangelist (Sorry Darius ich konnte mir deine dir selbst gegebene Job Beschreibung nicht merken. 🙂 )hat mit Christian Wenz (Der Christian Wenz, der auch Bücher schreibt und nicht der Zahnarzt aus Rosenheim) in einem lockeren Gespräch WebMatrix präsentiert.

Mit Hilfe von WebMatrix (eigentlich mit Hilfe des Web PI) wurde demonstriert wie einfach es sein kann vorbereitete Open Source Web Anwendungen, das sind übrigens nicht nur ASP.NET Anwendungen, wie man auch in der Demo sehen konnte, auf einem Computer zu installieren, diese gegebenenfalls anzupassen und dann zu veröffentlichen (Publish zum Hoster).

Im Zuge dieser Demonstration wurde WordPress (Ja WordPress eine PHP/mySQL Anwendung) mit Hilfe des Web PI auf dem Notebook von Darius installiert. Nach erfolgreicher Installation wurde dann auch noch gezeigt hat, wie man mit WebMatrix ein WP Plugin schreiben kann. Auch das geht mit WebMatrix – Microsoft goes PHP :-).

Gezeigt wurde natürlich aber auch die Verwendung von Microsofts neuer Rasiermesser scharfen Template Sprach(engine) Razor. Diese neue Scriptsprache (darf ich das so nennen ?) von Microsoft soll es unter anderem Einsteigern erleichtern in die Programmierung von Web Anwendungen einzusteigen.

Über die genauen Feature, Möglichkeiten und Zielgruppen von WebMatrix hatte ich bereits in meinem Artikel WebMatrix ist Heute Web Matrix war Gestern geschrieben und deshalb kann ich hier auf eine Wiederholung verzichten.

Um noch einmal auf die Zielgruppe und Razor zurückzukommen.

Ich wage zu bezweifeln dass in Ermangelung der fehlenden Intellisense ein solches Tool gerade bei Anfängern gut ankommen wird. Hier wird Microsoft nachbessern müssen.

Neben WebMatrix haben Darius und Christian aber auch noch über Themen wie HTML 5 und jQuery gesprochen. Beides Themen die jeden Web Entwickler sicherlich und wenn nicht schon Heute, dann vor allem in der Zukunft sicherlich lange und ausführlich beschäftigen werden.

Die Diskussion um HTML 5 hat mich, in Bezug auf meine Meinung zum IE 9,  etwas nachdenklich werden lassen. Eventuell werde ich meine Meinung bezüglich des IE 9 noch einmal überdenken müssen und den IE nicht nur als reinen Browser, zum betrachten von Internetseiten, anzusehen.

Aber nun noch mal zurück zum Thema WebMatrix.

Ich persönlich sehe WebMatrix nicht nur als Werkzeug für Neulinge an, sondern auch als recht hilfreiches Tool zur Installation und Einrichtung von Produkten die über den Web PI installiert werden können.

Es war wirklich noch nie einfacher Web Anwendungen wie:

DotNetNukeBlogEngine.NETJoomlaDrupalWordPress

Auf einem lokalen Rechner zu installieren, anzupassen und dann mit einem Knopfdruck zu veröffentlichen.

An dieser Stelle möchte ich nicht verpassen mich bei den beiden Referenten für Ihren gut gelaunten und wie immer kompetenten Vortrag zu bedanken.

Ich kann für mich sagen, das war ein guter Tag, Danke!

Firefox 4 RC 2 – So etwas wie eine Vorpremiere zum Wochenende

Eigentlich soll am Dienstag den 22.03.2011 die endgültige Version von Firefox 4 auf den Markt kommen.
Überraschend erscheint Heute dann aber doch noch ein zweiter Release Kandidat. Mozilla veröffentlicht Heute den RC 2 Ihres neuen Firefox 4 Internet Browser.

Wer sich diese Version, die übrigens alle Funktionen der hoffentlich nächste Woche erscheinenden Finalen Version 4.0 enthalten soll, noch anschauen möchte, kann diese hier herunterladen.

Ene mene meck, und Du bist weg! – Internet Explorer 9 als erstes ausgeschieden

In den meisten Berichten wird über den IE 9 gesagt:

Der IE 9 ist der beste Internet Explorer den Microsoft jemals auf den Markt gebracht hat.

Und dem möchte ich auch nicht widersprechen.

Doch was ist, wenn man die Produkte der Mitbewerber ins Spiel bringt. Wie schneidet der IE gegen seine Konkurenten ab.

Und dabei meine ich nicht irgendwelche Benchmarks. sondern den „Allatagstauglichkeitstest“ und der subjektive Eindruck den der Browser bei mir hinterlässt.

Dazu ergeben sich für unter anderem folgende Fragen

  • Wie schnell startet der Browser
  • Sind die wichtigsten Plugins verfügbar (hier hat sicherlich jeder andere Ansprüche)
  • Wie schnell werden Seiten aufgebaut
  • Unterstützt der Browser die aktuellen Videoformate
  • Wie sieht es mit der Sicherheit (Hacking) aus
  • ….

Bevor ich in die Beantwortung der oben gestellten Fragen beginne, zuerst einmal die größte Enttäuschung vorweg.

Der IE 9 ist nicht mehr Windows XP tauglich (das hätte nicht sein müssen, wie es die Mitbewerber eindrucksvoll bewiesen haben).
Ich weiß XP ist alt und wird nicht mehr unterstützt, aber ich weiß auch , dass einige meiner Kunden und ich meine wirklich große International auftretende Firmen, noch immer komplett auf XP setzen. Ja sicher werden diese Firmen demnächst auch irgend wann mal umstellen (für MS hoffentlich auf eine Windows Version und nicht auf eine L…X Plattform). Übrigens muss ich teilweise in der Entwicklung auch immer noch auf XP zurückgreifen. Immer dann wenn ich an Projekten für die Kunden arbeite, die noch komplett auf XP setzen.

Dieser Punkt geht schon mal klar an die Mitbewerber, denn diese Produkte sind nicht nur für alle Windows Versionen sondern auch für Linux und Apple OS verfügbar

Nun aber zu den Antworten:

  • Wie schnell startet der Browser

Und hier habe ich gleich die nächste große Enttäuschung. MS stellt eine spezielle 64 BIT Version des IE zur Verfügung. Natürlich habe ich diese Version auf mein 64 BIT Windows 7 installiert. Das war voll Panne, das ist so langsam…..

Aber ich habe auf einem anderen Rechner mit WIN 7 32 BIT und habe dann auf diesem Rechner die 32 BIT Variante installiert und mit diesem Rechner alle anderen vergleiche vorgenommen.

Aber als Resumé muss ich leider sagen, der IE 9 braucht zum Starten viel länger als FF oder Chrome.

Wieder kein Punkt für den IE !

  • Sind die wichtigsten Plugins verfügbar

Das muss man nicht suchen, Plugins wie es die für FF und Chrome gibt, sind für den IE nicht wirklich verfügbar. Und wenn, dann sind diese auch noch  von den Mitbewerbern geschrieben, wie zum Beispiel WebM Support durch Google.

  • Wie schnell werden Seiten aufgebaut

In dieser Disziplin kann der IE auf jeden Fall mit seinen Mitbewerbern gleichziehen.

  • Unterstützt der Browser die aktuellen Videoformate

Indirekt schon siehe WebM Support, aber von Haus aus……

  • Wie sieht es mit der Sicherheit aus

Diese Frage wird sich sicherlich erst in naher Zukunft beantworten lassen

Nun das alle Fragen beantwortet sind, steht für mich fest, der IE 9 ist aus dem direkten Rennen raus.

Oder wie es in der Überschrift heißt:

Ene mene meck, und Du bist weg!

Und wie heißt es im Zählreim von F. H. Benary.

…., da blieben nur noch zwei (FF und Chrome)

Hier noch die Links zu zwei Interessante Artikeln zum IE 9

ZDNet schreibt (Englisch) Five Reasons not to “Upgrade” to Windows’ Internet Explorer 9

CHIP-Online schreibt Schlanker Browser, schöneres Web