This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

Die dotnet Cologne ist seit über 3 Wochen ausgebucht, das Interesse war größer wie das Angebot. Dies ist natürlich schön und schlecht zugleich. Jedoch hat sich in der Zwischenzeit einiges getan, denn einige Teilnehmer haben abgesagt,  und die Sponsoren haben ihre Kontigente nicht komplett ausgeschöpft.

Wir hätten alles lassen können wie es ist, dies wäre  für uns am bequemsten gewesen. Doch dies nicht unser Naturell, wir wollen der Community ja was gutes tun. Also haben wir uns entschlossen die wieder verfügbaren Tickets in den Umlauf zu bringen, auch wenn es für uns wieder mehr Arbeit bedeutet!

Somit kann sich ab dem 27. April 2011 um 16 Uhr wieder jeder anmelden, die ersten 15 erhalten ein Ticket. Wer auf der Warteliste landet braucht sich keine Hoffnungen zu machen. Bezahlt werden muss der Betrag von 55€ sofort nach der Anmeldebestätigung. Das Geld muss bis zum 3. Mai auf unserem Konto sein, danach ist es einfach zu spät. Eine Bezahlung vor Ort ist nicht möglich!

Zur Anmeldeseite der dotnet Cologne 2011: http://dotnet-cologne.de/Anmeldung.ashx

Die dotnet Cologne 2011 ist eigentlich schon seit Anfang des Monats ausgebucht. Andererseits ist es bei mehr als 300 Anmeldungen nur natürlich, dass manche Interessenten aus dem einen oder anderen Grund doch nicht an der Veranstaltung teilnehmen können und damit ihr Platz frei wird. Auch gibt es Rückläufer von Freikarten für die Sponsoren.

So sind nun nach aktueller Rechnung insgesamt 15 Plätz frei, die wir natürlich noch belegen wollen.

Deshalb werden wir am 27.4.2011 um 16:00 noch einmal die Anmeldung freischalten.

Alle Teilnehmer, die dann einen der freien Plätze (zum Normalpreis von 55,-) ergattern, bitten wir um schnellstmögliche Überweisung. Wenn bis inkl. Dienstag 3. Mai kein Zahlungseingang festgestellt wurde, erfolgt eine automatische Abmeldung von der Veranstaltung. Es ist keine Bezahlung vor Ort möglich!

Die vom .NET-Stammtisch Konstanz-Kreuzlingen (DE / CH) veranstaltete .NET Community Konferenz mit dem Namen See# Party geht in die zweite Runde. 

Die Rückmeldungen und Stimmen aus der ganzen .NET Community von Deutschland und der Schweiz von der ersten Veranstaltung im letzten Jahr waren so positiv, das die Usergroup gestützt durch einen Schweizer-Verein (Usergroup), eine zweite Konferenz geplant hat, die dieses Jahr am 20. August stattfindet.

- Rückblick in Form von Bildern und Blogpost-Feedback zur See# Party 2010 um einen Eindruck zu bekommen

Für ganz frühe Frühbucher gehts hier lang!

Die Agenda mitsamt ihren Sprechern und Themen sollte für jeden von euch etwas beinhalten. (Der Inhalt kann sich noch ändern, dies ist eine Kopie. (Hier gehts zum Original).
Ich habe die aus meiner Sicht herausstechenden Themen hervorgehoben.

Weitere, nähere Infos gibt es unter dem Blogpost von Jürgen Gutsch zur See# Party 2011 oder auf der offiziellen Seite.

Wir sehen uns dort, zur vorzeitigen Anmeldung mit Frühbucherrabatt gehts hier lang.

Das Problem ist einfach umrissen: Man hat die Größe einer Datei oder (auch gern genommen) eine Größenbeschränkung in Bytes vorliegen und möchte diese dem Benutzer anzeigen. Aber nur die wenigsten Benutzer können mit der Größenangabe 1.048.576 Bytes etwas anfangen. Also möchte man die Größe dem Benutzer in ihm bekannten Größenangaben anzeigen - so wie man es von Windows kennt. Das .NET Framework selbst kennt meines Wissens eine solche Funktion nicht und daher ist es jedem Entwickler selbst überlassen, wie er diese Umrechnung vornimmt.

Auf meiner Suche nach einer Lösung für genau dieses Problem bin ich über einige Lösungsvorschläge bei stackoverflow gestolpert und einen davon fand ich extrem gut, so dass ich dem Problem und möglichen Lösungen diesen Blogpost widmen möchte.

1. Lösung: While-Loop

Dieser Ansatz wird gern genommen und liegt ja in der prozeduralen Denke auch auf der Hand: Man dividiert so lange durch 1024, bis eine Zahl übrig bleibt, die kleiner als 1024 ist. Hat man sich nun noch gemerkt, wie häufig man dies angewandt hat, so weiß man auch was man als Einheit dahinter schreiben muss.

var unit = new[] { "B", "KB", "MB", "GB", "TB", "PB" };
var index = 0;
var value = bytes;

while (value >= 1024)
{
 index++;
 value /= 1024;
}

var readable = string.Format("{0} {1}", value, unit[index]);

2. Lösung: Windows bemühen

Wie ich schon einleitend beschrieben habe, kann Windows diese Berechnung ja. Warum also nicht mit unmanaged Code auf die passende Windows-Funktion zugreifen? Die Shlwapi.dll stellt eine entsprechende Funktion bereit, mit der diese Formatierung vorgenommen werden kann.

[DllImport("Shlwapi.dll", CharSet = CharSet.Auto)]
public static extern long StrFormatByteSize(
 long fileSize,
 [MarshalAs(UnmanagedType.LPTStr)] StringBuilder buffer,
 int bufferSize);


var sb = new StringBuilder(11);
StrFormatByteSize(bytes, sb, sb.Capacity);
var readable = sb.ToString();

OK, es ist eine Möglichkeit, aber keine die ich präferieren würde.

3. Lösung: Mathematisch

Und nun zu der Lösung, auf die ich zugegebenermaßen nicht gekommen bin, die ich aber sehr charmant finde. Mit Hilfe nur weniger mathematischer Funktionen lässt sich die Schleife aus der Lösung 1 ersetzen. Durch eine geschickte Kombination von Logarithmus-, Potenz- und Rundungsfunktionen lässt sich sowohl der gerundete Wert als auch die anzuzeigende Einheit ermitteln.

var unit = new[] { "B", "KB", "MB", "GB", "TB", "PB" };
var index = Convert.ToInt32(
    Math.Floor(Math.Log(Math.Abs(bytes), 1024)));
var value = Math.Round(bytes / Math.Pow(1024, index), 2);
var readable = string.Format("{0} {1}", value,  unit[index]);

Einziger Wert für den diese Variante nicht funktioniert ist 0 Byte.

Wie ganz häufig, so gibt es auch hier viele Wege, die zum Ziel führen und es bleibt jedem selbst überlassen, welchen Weg er wählt.

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

Will man aus einer Liste von strings z.B. jeden dritten Eintrag (in diesem Fall beginnend mit dem ersten) erhalten und aus diesen Einträgen wieder eine List<T> erstellen, kann man dies mit LinQ leicht erledigen:

public class Given_a_list_of_9_entries_when_requesting_every_third_entry {
	static IList<string> _everyThirdEntry;
	static IList<string> _allEntries;
	static IList<string> _expectedEntries;

	Establish context
		= () =>
			{
			  	_allEntries = new List<string>
			  		        {
			  		           	"x1","y1","z1","x2","y2","z2","x3","y3","z3"
			  		        };
			  	_expectedEntries = new List<string>
			  		                {
			  		                   	"x1","x2","x3"
			  		                };
			};

	Because of
		= () =>
			{
			  	_everyThirdEntry =
			  		_allEntries.Where((entry, index) => index %3 == 0).ToList();
			};

	It should_return_every_third_entry_starting_on_first
		= () => {
			        _everyThirdEntry.ShouldEqual(_expectedEntries);
		};
}

Where besitzt eine Überladung, in der man Zugriff auf den Index des jeweiligen Elements bekommt, der Rest der Funktion sollte somit klar sein

Letzte Woche bin ich beim Kramen im Keller auf Fotos eines älteren Projektes gestoßen, zu welchem ich bisher noch nichts im Internet veröffentlicht habe:

Eine Büste der Hauptfigur aus dem Film "Species" in Originalgröße.

Hier also die Schritt-fü-Schritt "Anleitung" zum Bau einer solchen Büste. Sowohl die Fotos als auch die zur Verfügung stehenden Werkzeuge sind von 1996 - bitte daher die schlechte Qualität der eingecannten Fotos ignorieren ;-)

 
Basis und für die Stabilität der Büste ist eine Holzplatte. Auf dieser ist ein in Maßen bewegliches Gerüst aus Holz montiert. An das Gerüst werden später nach und nach die verschiedenen Teile der Büste montiert.

 
Die Zähne bestehen aus im Backofen gehärtetem Fimo in zwei Reihen (hier nur die innere zu sehen).
Ein Großteil der Kopf-Oberflächen entsteht aus Pappmaché und wird mit PU-Schaum unterfüttert, um dem ganzen mehr Stabilität zu verleihen.

 
Hier sind die Holz-Augen und inneren Fimo-Zähne bereits eingesetzt. Die ersten Formen sind per Pappmaché modelliert (beige Bereiche).

 
PU-Schaum ist die Basis für den Unterkiefer. Großflächig aufschäumen und anschließend mit dem Cuttermesser in Form schneiden.

Die Feinmodellierung des Unterkiefers geschieht wieder mit Pappmaché. Hier sieht man auch bereits die äußeren Zahnreihen.

Holzleisten für die Stabilität des Hinterkopfes sind am Gerüst angebracht.

 
Weitere Partien des Kopfes sind ausgearbeitet. Die "Haare" am Hinterkopf bestehen aus Elektro-Leerrohren

 
"Ohr-Hörner" sind aus Draht und Pappmaché gefertigt. Die "Haare" sind fertig modelliert. Schultern bestehen (wie der Unterkiefer) aus PU-Schaum und darüber Pappmaché.

Fertig modelliert - fehlt nur noch Farbe!

Nicht täuschen lassen: Pappmaché hört sich möglicherweise instabil an, ist aber ab einer Dicke von 1-2 Millimeteren hart wie Holz.
Und so ist die Büste auch bearbeitet: Die glatten Flächen wie z.B. Stirn werden nach dem Trocknen per Schmiergelpapier bearbeitet bis sie glatt sind.

 
Die Büste hat die erste Farbgrundierung erhalten. Die Augen sind bemalt und mit einer transparenten Silikonschicht überzogen, damit sie nicht mehr hölzern wirken.

Und fertig! Leider habe ich damals noch kein Air-Brush beherrscht - die Schatten und Konturen sind daher mit dem Pinsel gemalt und wirken daher etwas unnatürlich und zu hart.

Noch einmal das ganze von der Seite.

Happy Birthday

So auch von mir alles gute, zu deinem 5 Geburtstag.

Während dieser 5 Jahre hast Du schon einiges gelernt und deinem Vater oder so manch einem Gewinner der 7 Gewinnspielen, so manche Freude bereitet. Ok es waren auch schwierige Zeiten dabei aber darüber spricht man ja nicht. Im deinem letzten Kindergarten Jahr, wird noch so einiges passieren aber so wie dein bisheriges Leben gemeistert hast wirst du das auf jeden Fall auch schaffen.

@Jan so langsam musst Du als stolzer Papa, Dir darüber Gedanken machen, in welche Grundschule Du dein Kind einschulen möchtest.

Seit der Windows Azure SDK 1.3 steht ein vollständiger IIS 7.5 in den Web Rollen zur Verfügung. Somit lassen sich auch mehrere Webseiten in einer Web Rolle betreiben.

Hierzu ein kleines Beispiel...

Der Windows Azure Host

Wie gewohnt lege ich als Erstes ein neues Windows Azure Projekt an.

Als Nächstes füge ich eine ASP.NET Web Role hinzu, die später als Host für die Web Applikationen dienen soll. Deshalb bekommt die Rolle auch den Namen "MultiWebseitenDemo.Host".

Da die hinzugefügte Web Rolle nur ein Platzhalter ist, lösche ich alle Projektdateien und Verzeichnisse, mit Ausnahme der WebRole.cs Datei.

Die Web Applikationen

Im nächsten Schritt füge ich der Solution einige Web Projekte hinzu:

Ein ASP.NET MVC 2 Web Application Projekt mit dem Namen "StandardWebseite" ...

... ein ASP.NET Web Application Projekt mit dem Namen "MeineTestWebseite1" ...

... und ein Silverlight Application Projekt mit dem Namen "SilverlightImVirtualDirectory" ...

Nach dem Hinzufügen der Web Projekte, muss ggf. das Windows Azure Projekt wieder als Startprojekt gesetzt werden.

Einbinden der Web Applikationen

Zum Einbinden der Web Applikationen in das Windows Azure Projekt, muss die ServiceDefinition.csdef Datei editiert werden.

Dort befindet sich bereits ein Eintrag für die Web Rolle "MultiWebseitenDemo.Host".

Für das "StandardWebseite" und "MeineTestWebseite1" Projekt, lege jeweils ein <Site> Tag inkl. <Bindings>...</Bindings> an.
Im <Site> Tag wird jeweils das name und physicalDirectory Attribut gesetzt.

Wichtig:
Beim name Attribut darf nicht der Standardwert "Web" benutzt werden, da sonst der physicalPath ignoriert und der Pfad der "Host" Web Rolle benutzt wird.

Im <Binding> Tag, des "MeineTestWebseite1" Projektes, muss noch das hostHeader Attribut auf "www.MeineTestWebseite1.de" gesetzt werden. Somit können die Projekte später unterschiedlich adressiert werden.

Das "SilverlightImVirtualDirectory" Projekt soll in einem virtuellen Verzeichnis des "StandardWebseite" Projektes betrieben werden.
Hierzu habe ich, im Eintrag des "StandardWebseite" Projektes, ein <VirtualApplication> Tag mit dem name und physicalPath Attribut hinzugefügt. Der Wert des name Attributes, wird später als Name des virtuellen Verzeichnisses benutzt.  

Beispielapplikation testen

Um die Beispielapplikation testen zu können, muss noch ein Eintrag, für die "www.MeineTestWebseite1.de" URL, in die hosts Datei des Betriebssystems hinzugefügt werden.

Speichern und zurück zu Visual Studio ...

Nach einem Druck auf die F5-Taste, wird die Startseite des "StandardWebseite" Projektes angezeigt:

Wenn die URL mit "/Silverlight/" erweitert wird, kommt die Silverlight Applikation zum Vorschein:

Mit der, durch die hosts Datei umgebogenen, "www.MeineTestWebseite1.de" URL, wird das "MeineTestWebseite1" Projekt angezeigt:

Ein Blick in den IIS Manager zeigt, dass die Webseiten und das virtuelle Verzeichnis für jede VM Instanz (in diesem Fall die Instanz mit der ID 0) angelegt wurde.

Weitere Informationen:
Windows Azure Team Blog: New Full IIS Capabilities - Differences from Hosted Web Core

Download der Beispielanwendung: MultiWebseitenDemo.zip (431,63 kb)

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5) – this one
• REST using the WCF Web API – Post it! (Part 6) 

It’s about state

A fundamental element of the HTTP protocol is returning the state of the current request in the HTTP headers. When using classic Web or WCF Services there have been made efforts to represent state by sending exceptions over the wire etc.

When taking a close look at the HTTP status codes, you’ll see that you can represent every state a request or the server hosting that service (or resource in terms of REST) has by using these status codes.

WCF Web API of course supports using them.

In our next scenario we’ll request a specific contact and of course, we want to receive this contact from the response. In addition to that we also want to get “notified” if the contact does not exist or the id used in our request is plain wrong.

First, lets take a look back at our first method we already implemented to pull out a list of all contacts from our server:

[WebGet(UriTemplate = "")]
public List<contact> Get() {
	return _contactRepository.Get().Cast<contact>().ToList();
}

Now we’ll create a new resource called ContactResource containing a method Get being able to receive an id by which the requested contact is pulled out of our repository:

[WebGet(UriTemplate = "{id}")]
public Contact Get(int id) {
	return _contactRepository.Get(id) as Contact;
}

Despite the slightly different signature of the Get method we also modified the URI template to map the request parameter id to the methods id parameter.

To make the method return one of our contacts we also tell our configuration in the global.asax about our additional resource by adding the following line:

RouteTable.Routes.MapServiceRoute<contactresource>("contact", configuration);

Pointing our browser to

http://localhost:1413/contact/1

it returns one of our Microsoft guys:

Investigating this request/response in Fiddler turns out that the HTTP status code 200 for “OK” has been added automatically to our response:

HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Wed, 20 Apr 2011 19:41:23 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 91
Cache-Control: private
Content-Type: application/xml; charset=utf-8
Connection: Close

<?xml version="1.0" encoding="utf-8"?><Contact><Id>1</Id><Name>Glenn Block</Name></Contact>

Now lets see what happens if the contact we are requesting does not exist by simply using a not existing id:

HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Wed, 20 Apr 2011 19:48:50 GMT
X-AspNet-Version: 4.0.30319
Content-Length: 116
Cache-Control: private
Content-Type: application/xml; charset=utf-8
Connection: Close

<?xml version="1.0" encoding="utf-8"?><Contact p1:nil="true" xmlns:p1="http://www.w3.org/2001/XMLSchema-instance" />

As you can see, we don’t get a contact but still receive HTTP status code 200 – which of course should be 404 instead for “Not Found” to fulfill the terminology of REST and HTTP. In addition we get a XML fragment we don’t want have to deal with.

But where to modify the HTTP status code now?

Fortunately this functionality is contained in the WCF Web API so we just need to modify the signature of our method a little bit and we’ll be able to modify the HTTP status inside our method:

[WebGet(UriTemplate = "{id}")]
public HttpResponseMessage<Contact> Get(int id) {
	Contact contact = null;
	contact = _contactRepository.Get(id) as Contact; 
	if(null == contact) {
		return new HttpResponseMessage<Contact>(HttpStatusCode.NotFound);
	}
	return new HttpResponseMessage<Contact>(contact);
}

WCF Web API introduces the HttpResponseMessage class which allows us to take control over the HTTP response being returned whereby we’re using a very small part of it in the sample above – more to come for sure.

Re-invoking our malformed request on

http://localhost:1413/contact/4

in Fiddler, it now returns the expected status code and there’s no XML fragment inside the response body:

HTTP/1.1 404 Not Found
Server: ASP.NET Development Server/10.0.0.0
Date: Wed, 20 Apr 2011 20:07:07 GMT
X-AspNet-Version: 4.0.30319
Cache-Control: private
Content-Length: 0
Connection: Close

When speaking of testing again there will be no annoyances. As HttpResponseMessage doesn’t have any dependencies requiring any test setup we can implement our test straight forward:

public class Given_a__contact_resource__when_requesting_a_not_existing_contact : WithSubject<ContactResource> {
	static HttpStatusCode _statusCode;

	Establish context
		= () =>
			The<IContactRepository>()
				.WhenToldTo(r => r.Get(4))
					.Return(null as IContact);

	Because of = () => { _statusCode = Subject.Get(4).StatusCode; };

	It should_return_status_code_404_not_found
		= () => {
			_statusCode.ShouldEqual(HttpStatusCode.NotFound);
		};
}

Put simply: Green ;-)

Having modified the status code of our response according the state of our request in according to REST terminology using native HTTP elements we have taken the next step to a RESTful architecture using the WCF Web API.

Next one will cover creating data on the server using WCF Web API.

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5) – this one
• REST using the WCF Web API – Post it! (Part 6) 

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

When it comes to mocking COM objects (using the Mock Framework of your choice) you may face the following exception:

System.TypeLoadException: Could not load type 'IModelDoc2Proxy52849244002f4ce4a339ed6a97d23841' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. The type is marked as eligible for type equivalence, but either it has generic parameters, or it is not a structure, COM imported interface, enumeration, or delegate.

If you're working with .NET Framework 4.0, it is likely that it is caused by the “Embed Interop Types” property of the Reference being set to “True” (which is the default):

Just another reason to set it to “False” by default.

Die deutschsprachige Anlaufstelle, wenn es um hilfreiche Snippets für die Entwicklung mit dem Microsoft .NET-Framework geht, feiert die Tage ihren 5. Geburtstag: Alles Gute! :-)

Aber eigentlich hat Jan vermutlich nur wieder einen Grund gesucht, um ein paar richtig tolle Preise unter die Leute zu werfen! Da gibt es dieses mal ein Visual Studio 2010 Professional, Office Professional Plus, zahlreiche Bücher oder ein Jahres-Abonnement der dotnetpro.

Mitmachen kann man ab sofort bis Mittwoch, 4. Mai. 2011 unter dotnet-snippets.de – keine Fragen, keine Rätsel, nur ein wenig kreativ soll man sein wenn man dotnet-snippets.de zum Geburtstag gratuliert; beispielsweise per Blog-Posting, einem Beitrag in einem Forum, …

Freuen wir uns also alle auf weitere 5 Jahre DNS!

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4) – this one
• REST using the WCF Web API – getting more RESTful responses (Part 5)
• REST using the WCF Web API – Post it! (Part 6)  

RESTless testing

Not only does REST become more and more important but also Test Driven Development (TDD) has become state of the art in professional software development.

A less common “sub type” of TDD is Behavior Driven Development (BDD) which is a agile software development technique that encourages collaboration between developers and non-developers.

BDD is focused on a better understanding of the software to be written by discussing with stakeholders in their natural language combined with the so called ubiquitous language of the stakeholders problem domain.

Yet there are a lot of BDD frameworks available for .NET . The one I like most of them is Machine.Specifications (short: MSpec) with the newish Machine.Fakes (short: MFakes) on top which allows a lean way of BDD by providing an integration layer between MSpec and different Mock/Fake/Substitute frameworks such as Rhino.Mocks or Moq and others. Thus Machine.Fakes simplifies the usage of these frameworks on top of MSpec.

To cut a long story short, lets write the first test.

As you may already suspect: Machine.Fakes is available on NuGet by adding a Package Library Reference to “Machine.Fakes.RhinoMocks”:

As you can see, there are also implementations available for FakeItEasy, Moq and NSubstitute.

Choosing “Machine.Fakes.RhinoMocks” installs all required dependencies to our project and we’re ready to enjoy the magic of Machine.Fakes.

As we haven’t tested the Get method of our ContactsResource until now, we’ll catch up on this.

Here’s the test code (we prefer to speak of “specifications” in MSpec):

public class Given_a__ContactsResource__when_requesting_all_contacts : WithSubject<ContactsResource> {
	static List<Contact> _actualContacts;

	Establish context = () => {
		With<TheMicrosoftGangContactList>();
		With(new FakeContactRepository(The<IList<IContact>>()));
	};

	Because of
		= () => {
				_actualContacts = Subject.Get();
			};

	It should_return_the_microsoft_gang 
		= () =>
		           {
		           	_actualContacts.Count.ShouldEqual(3);
		        };
}

The result of the specification being run in the ReSharper test runner:

Now let’s see what happened in detail.

BDD and thus MSpec follows the AAA syntax for unit tests which means that tests are run in the following order:

• Arrange
• Act
• Assert

Whereas in BDD we use the terms

• Given
• When
• Then

which are mapped to the following methods of MSpec:

• Establish (context)
• Because (of)
• It (should something)

The name of the test class is mapped to the name of the test inside the test runner and the name of the It-delegate is mapped to the assertion description inside the test runner. Also the underscores in class and delegate name have been replaced by white spaces in order to improve readability for non-developers.

As you can see, our class derives from WithSubject<ContactsResource> which allows us to work with so called BehaviorConfigs. BehaviorConfigs are classes you can implement to set up dependencies for our system under test (a.k.a. SUT, called Subject in Machine.Fakes terminology).

You can use an arbitrary number of BehaviorConfigs inside your test class.

Using the With<BehaviorConfig>() or With(new BehaviorConfig()) method inside the Establish delegate Machine.Fakes is told to use them.

The reasonable question at this point is: what’s the use?

As you may remember from the previous posting, our ContactsResource has a dependency on the IContactRepository which handles the CRUD operations on the database.

When it comes to testing our ContactsResource, we don’t want to setup a database having the proper test data ready every time we want to run our tests.

Besides that we don’t want to test our ContactRepository (which would be the case if it were the concrete implementation when testing the ContactsResource) – we just want to rely on a ContactRepository working properly instead.

The way to get rid of the concrete ContactRepository implementation is the usage of Mocks or Stubs and so the circle is complete.

Mocks/Stubs (or in terms of Machine.Fakes: Fakes) created the Machine.Fakes way are set up inside the BehaviorConfigs (or directly inside the Establish delegate method) to be reusable and keep the Establish method body short and clear.

In order to test our ContactsResource without having a dependency on a concrete ContactRepostory implementation we will use two Fakes:

• FakeContactRepository, which returns a concrete list of contacts when calling it’s Get method
• TheMicrosoftGangContactList which is the concrete list of three contacts being return form the Get method of the FakeContactRepository

Now lets take a look inside the TheMicrosoftGangContactList BehaviorConfig:

public class TheMicrosoftGangContactList {
	OnEstablish context =
		fakeAccessor
		=> {
			List<IContact> contacts =
			   	new List<IContact>()
			   		{
			   			new Contact()
			   				{
			   					Id = 1,
			   					Name = "Glenn Block"
			   				},
			   			new Contact()
			   				{
			   					Id = 2,
			   					Name = "Scott Hanselman"
			   				},
			   			new Contact()
			   				{
			   					Id = 3,
			   					Name = "Scott Guthrie"
			   				}
			   		};
			fakeAccessor.Configure(
			   	config => config
			   		        .For<IList<IContact>>()
			   		        .Use(() => contacts));
		};
}

Most of it is similar to the code from the previous parts of the post series.

The main improvement is the OnEstablish delegate whose parameter fakeAccessor is Configured to Use our list called contacts For any request on IList<IContact>. OnEstablish then is executed in the Establish delegate method of our test class later on.

This is the magic of BehaviorConfigs explained in about three words. Did you notice by the way, that you don’t have to implement anything to get this to work?

Yet, there’s another BehaviorConfig called FakeContactRepository which is passed into the test class by the second form of With by using parameters. In addition FakeContactRepository itself has a parameter of type IList<IContact>. At closer inspection you should notice that the call of IList<IContact> is surrounded by the The<>() method. The intention behind this method is to get a singleton mock for the given type in the context of our test class. By Configure-ing our IList<IContact> mock to return the contacts list in the TheMicrosoftGangContactList BehaviorConfig we’ll get back the contacts list now by calling The<IList<IContact>(). This is nice, isn’t it?

But there’s more to come: Machine.Fakes has to other methods allowing us to handle mock objects with ease:

• An<T> returns an arbitrary mock object which can be configured by our needs.
• Some<T>() with it’s overload Some<T>(int amount) allow us to create ILists of the required types where the latter gives us the ability to set the number of objects being held inside the list. Some<IContact>(3) could also be used instead of our TheMicrosoftGangContactList BehaviorConfig.

Both methods of course are available also inside BehaviorConfigs through the fakeAccessor.

At least, lets take a look at our FakeContactRepository implemenation:

public class FakeContactRepository {
	static IList<IContact> _contacts;

	public FakeContactRepository(IList<IContact> contacts) {
		_contacts = contacts;
	}

	OnEstablish context =
		fakeAccessor
		=> {
			IContactRepository repository = fakeAccessor.An<IContactRepository>();
			repository.WhenToldTo(r => r.Get())
			   	.Return(_contacts);
			fakeAccessor.Configure(
			   	config=>config.For<IContactRepository>().Use(()=>repository));
		};
}

This one looks very similar to the previous BehaviorConfig. Please notice the call of the WhenToldTo and the Return extension methods on the repository instance. These allow us to configure the behavior of the mock object (which means here: returning the list of contacts being passed into it before).

Of course there are more than these two methods – further details can be found in the extensive list of samples being include in the Machine.Fakes download.

This posting has been a little bit out of band concerning WCF Web API but hopefully not less interesting.

Now that we have set up our infrastructure in terms of IoC and testing we can continue the RESTful journey through the Microsoft WCF Web API in the next part of this series.

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4) – this one
• REST using the WCF Web API – getting more RESTful responses (Part 5)
• REST using the WCF Web API – Post it! (Part 6)  

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

Reporting Services cachen Reports um eine höhere Ausführungsgeschwindigkeit zu erreichen. Es gibt allerdings einige Szenarien wo dadurch nicht die gewünschten aktuellsten Daten im Report angezeigt werden, vor allem beim Entwickeln von neuen Reports. Deshalb kann es in diesen Fällen sinnvoll sein das Caching abzuschalten. Dazu geht man auf http://<SSRS Server>/reportserver, wechselt zu dem entsprechenden Report und ruft aus dem Dropdonw-Menü dn Punkt Verwalten auf (bei SQL Server 2008 R2, im SQL Server 2008 geht das über den Reiter “Eigenschaften”)

Im Bereich “Verarbeitungsoptionen” (Ausführung bei SQL Server 2008) kann dann die Option “Keine temporären Kopien dieses Berichts zwischenspeichern” ausgewählt werden.

Im ersten Teil dieser Blog Post Serie habe ich mich mit den Web Rollen in der Windows Azure Plattform beschäftigt.
In diesem Teil wird die bisherige Beispielapplikation mit einer Repository- sowie einer Kontext-Klasse für den Windows Azure Table Storage erweitert. Außerdem werden kleinere Anpassungen an den Datenmodellklassen durchgeführt, um die Arbeit mit den Objekten zu vereinfachen.

Was ist der Table Storage

Der Table Storage ist, aus meiner Sicht, die NoSQL Antwort von Microsoft für die Windows Azure Plattform. Man kann den Table Storage als ein sehr einfaches Objektdatenbanksystem sehen.
Im Original heißt es, dass flexible Entitäten bzw. schemalose Entitäten im Table Storage gespeichert werden können. Genauer gesagt, werden Name-Wert-Paare für jeden einfachen Datentyp, wie z.B. String, Integer, DateTime, Guid, etc., der zu Grunde liegenden Klasse, gespeichert.

Die zu speicherenden Entitäten müssen mindestens folgende drei Eigenschaften enthalten:

• PartitionKey (Typ: String, Max. Größe: 1 KB)
  Der PartitionKey dient zum separieren der Entitäten auf mehrere Server innerhalb des Table Storage Dienstes. (dazu später mehr).
• RowKey (Typ: String, Max. Größe: 1 KB)
  Der RowKey muss einen eindeutigen Wert innerhalb einer Partition enthalten und stellt, mit dem PartitionKey, einen zusammengesetzten Primärschlüssel für eine Entität dar.
• Timestamp (Typ: DateTime)
  Der Timestamp wird vom Table Storage verwaltet und enthält den Zeitpunkt der letzten Speicherung.

Hinweis:
Die Zeichen /, \, # und ? sind als Werte für den RowKey oder PartitionKey unzulässig.

Für die Nutzung des Table Storage, muss als Erstes ein Storage Account angelegt werden (dazu später mehr).

Danach können beliebig viele Tabellen angelegt werden.
Folgende Einschränkungen gibt es für Tabellen im Table Storage:

• Jede Tabelle innerhalb eines Storage Accounts muss einen eindeutigen Namen haben.
• Tabellenamen dürfen nur alphanumerische Zeichen enthalten.
• Tabellenamen dürfen nicht mit einem numerische Zeichen anfangen.
• Bei Tabellenamen wird die Groß-/Kleinschreibung nicht beachtet.
• Tabellenamen müssen mindestens 3, maximal 63 Zeichen lang sein.
• Maximal können 100 TB Daten pro Storage Account gespeichert werden.
  Der Speicherplatz wird gemeinsam für Tabellen, Blob's und Warteschlangen (Queues) genutzt.
• Maximal können 255 Name-Wert-Paare pro Entität gespeichert werden.
  Durch die 3 Pflichteigenschaften, bleiben somit 252 benutzerdefinierte Eigenschaften zu freien Verfügung.

Die PartitionKey Eigenschaft

Mit der PartitionKey Eigenschaft einer Datenmodellklasse, werden Entitäten einer Tabelle auf verschiedene Server des Table Storage Dienstes aufgeteilt. Dies dient zur besseren Skalierbarkeit des Table Storages. Allerdings hat man keine Kontrolle darüber, wie dies innerhalb der Windows Azure Plattform geschieht.

Man muss sich bereits beim Entwurf der Applikation Gedanken darüber machen, wie eine Partitionierung der Tabellen aussehen könnte.

Faustregel:

Man sollte die Partitionen anhand der gemeinsam abzufragenden Entitäten festlegen.

Bei der Blog Post Serien Beispielapplikation habe ich die Adressbücher anhand der Benutzer ID partitioniert (vorerst noch hart verdrahtet), sowie die Kontakte anhand der Adressbuch ID.

Das Storage Account

Um Tabellen im Table Storage anlegen zu können, benötigt man als erstes einen Storage Account.

Während der Softwareentwicklung, kann der Storage Emulator, der mit der Windows Azure SDK installiert wurde, genutzt werden.

In der Windows Azure Plattform muss dieses Storage Account über das Portal angelegt werden.
Nachdem man sich am Portal angemeldet hat, kann man über das Icon "New Storage Account" (oben links) ein neues Account anlegen

Im Dialog muss dann ein Name (nur Kleinschreibung erlaubt), sowie eine Region oder Affinity Group angegeben werden.

Eine Affinity Group ist eine vom Benutzer vordefinierte, benannte Region, in der sicher gestellt wird, dass Dienste in benachbarten Netzwerksegmenten angelegt werden. Dies soll eine schnelle Kommunikation zwischen den Diensten, die innerhalb einer Applikation verwendet werden, gewährleisten.

Nach kurzer Wartezeit, erscheint das neu angelegte Storage Account in der Liste.

Das Properties Panel (rechts) enthält Detailinformationen, wie z.B. die URL's für den Speicherplatzzugriff.

Mit einem Klick auf den View Button beim Primary oder Secondary Access Key, öffnet sich ein weiterer Dialog, in dem man die Speicherzugriffsschlüssel in den Zwischenspeicher kopieren kann.

Änderungen am Beispielprojekt

Nach dieser kleinen Übersicht der Grundzüge des Table Storages, auf zur Beispielapplikation...

Neue Referenzen

Um auf den Table Storage zugreifen zu können, benötigt das "Adressverwaltung.Data" Projekt zwei weitere Referenzen:

• Microsoft.WindowsAzure.StorageClient
• System.Data.Services.Client

Änderungen an den Datenmodellklassen

In den Datenmodellklassen der Beispielapplikation, habe ich kleinere Änderungen durchgeführt, damit sich diese problemlos im Table Storage speichern lassen.

Beide Klassen erben, von der abstrakten Klasse TableServiceEntity, die oben genannten Pflichteigenschaften RowKey, PartitionKey und Timestamp. Diese hätte man auch manuell hinzufügen können.

In den Konstruktoren der Klassen, wird der RowKey mit einer - neu generierten und in einen String umgewandelten - Guid bestückt.

Bei den Eigenschaften AdressbuchId und KontaktId wurde der Setter entfernt und der Getter wandelt den RowKey wieder in eine Guid um und gibt diese zurück.

Die Kontextklasse

Als nächstes habe ich eine Kontextklasse für das Datenmodell angelegt.
Diese leitet von der TableServiceContext Klasse ab und implementiert Eigenschaften zur Abfrage der Datenmodellklassen, sowie Add Methoden, der Datenmodellklassen.

Hinweis:
Mit Hilfe der WritingEntity und ReadingEntity Ereignisse, aus der TableServiceContext Klasse, lassen sich die Speicher- und Lesevorgänge anpassen. So können zum Beispiel einzelne Eigenschaften der Datenmodellklassen ignoriert bzw. ausgeschlossen werden.

Einen Konfigurationseintrag für die Web Rolle hinzufügen

Die Konfiguration der Windows Azure Rollen unterscheidet sich von dem, was man bisher verwendet hat.

Zum Beispiel gibt es weiterhin die web.config Datei in den Projektvorlagen für Web Rollen.
Wenn aber diese Web Rollen in der Windows Azure Plattform installiert wurden, und daraufhin mehreren Instanzen gestartet werden, kann diese nicht mehr als zentraler Ort für die Konfiguration der Applikation genutzt werden.

Hier kommt die ServiceConfiguration.csdef aus dem Windows Azure Projekt in Spiel.
Diese kann auch noch nach der Installation, innerhalb des Windows Azure Portals, editiert werden.

Für das einfache Ändern der Rollenkonfiguration, gibt es in Visual Studio 2010 einen Konfigurationsdialog.
Um in den Konfigurationsdialog zu gelangen, muss man einen Doppelklick auf die entsprechende Rolle im Verzeichnis Roles des Windows Azure Projekts machen:

Anschließend wechselt man auf das Settings Tab.
Dort sieht man eine Liste der Konfigurationseinstellungen. Standardmäßig ist hier der Connection String für das Windows Azure Diagnostics Plug-In voreingestellt.
Mit dem Add Settings Button kann man eine weitere Zeile hinzufügen.

Für die Beispielapplikation habe ich einen weiteren Connection String mit dem Namen AzureStorageConnectionString hinzugefügt.

Mit dem "..." Button öffnet sich der Dialog für die Connection String Konfiguration:

Da ich vorerst den Windows Azure Storage Emulator verwenden werde, konnte ich diesen Dialog, mit einem Klick auf den OK Button, wieder schließen.

Der Konfigurationseintrag innerhalb der Web Rolle

Um den Konfigurationseintrag für das Storage Account verwendet zu können, muss als erstes ein Setting Publisher hinzugefügt werden.
Dies kann man in den Web Rollen am Besten in der Global.asax im der Application_Start Methode unterbringen.

Anschließend kann man diesen, wie z.B. im statischen Konstruktor der Repository Klasse, nutzen, um ein Storage Account Objekt zu erzeugen.
Mit Hilfe der statischen Methode CreateTablesFromModel der CloudTableClient Klasse, können die Tabellen auf Basis der Kontextklasse erzeugt werden.

Die Table Storage Repository Klasse

Neben dem, im vorherigen Abschnitt erwähnten, statischen Konstruktor, möchte ich noch ein paar weitere "Highlights" des Table Storage Repository Klasse aufzeigen:

Der Standard Konstruktor erzeugt ein Objekt des Table Storage Kontext.
Hier wird bereits die Retry Policy auf 3 Versuche, in einem Abstand von 1 Sekunde, festgelegt.
Falls bei einer Anfrage des Table Storage Dienstes, nicht rechtzeitigt oder gar nicht geantwortet wird, wird diese Policy für Wiederholungen verwendet.

Mit LINQ können die Entitäten abgefragt werden.
Hier gibt es allerdings ein paar Besonderheiten:

• Bei einer normalen LINQ Abfrage werden maximal 1.000 Entitäten zurückgeliefert.
  Wenn allerdings alle Entitäten zurückgeliefert werden sollen, kann die Abfrage mittels AsTableServiceQuery in ein CloudTableQuery Objekt umgewandelt werden.
  Anschließend verwendet man die Execute oder BeginExecuteSegmented Methode, um eine Kette von Abfragen auszuführen, die alle Entitäten zurückliefert.
• Gängige Operationen, wie z.B. OrderBy, GroupBy, Join, Count, etc. werden vom Table Storage Dienst nicht unterstützt.
  Dies kann aber im Anschluss an eine ausgeführten Abfrage, wie z.B. mittels ToList oder Execute, im Arbeitsspeicher nachgeholt werden.

Das hinzufügen, aktualisieren oder löschen von Entitäten ist wiederum ähnlich, wie in anderen Diensten:

Speicherzugriffstransaktionen

Beim der Löschmethode der Adressbücher möchte ich noch auf eine weitere Besonderheit des Table Storages hinweisen: Die Speicherzugriffstransaktionen.

Jeder Zugriff auf den Table Storage kostet derzeit Geld und benötigt Zeit.

Um dies ein wenig effizienter zu gestallten, können diese Zugriffe in eine Transaktion zusammengefasst werden. Hierzu verwendet man beim der SaveChanges Methode die Option SaveChangesOptions.Batch.

Auch hier gibt es ein paar Einschränkungen:

• Maximal 4 MB Payload pro Batchanfrage
• Maximal 100 Operationen pro Batchanfrage
• Das selbe Objekt darf nicht mehrfach geändert werden
• Die Änderungen müssen in der selben Partition statt finden

Hier das Beispiel aus der Löschmethode der Adressbücher:

Kommende Themen

In den kommenden Blog Posts wird die Beispielanwendung u.a. mit einer Worker Role für die Bildverarbeitung erweitert. Des weiteren wird es Blog Posts zu Themen, wie z.B. Installation, einem SQL Azure Repository, dem Access Control Service und dem Windows Azure Content Distribution Network (CDN) geben.

Download der Beispielanwendung: ErsteSchritteMitWindowsAzure02.zip (275 kb)

Wer letzte Woche nicht gerade Urlaub auf Pluto gemacht hat, hat zumindest mitbekommen, dass das folgende Windows Phone Update namens “Mango” auf der MIX in Las Vegas erneut vorgestellt wurde.
Zur Keynote gab es zusätzlich einige Sessions, die das Thema vertieften. Diese Sessions sind mittlerweile online verfügbar und können kostenfrei heruntergeladen werden. Dazu bietet sich der kostenlose Sessiondownloader an. welcher hier genauer beschrieben wird. Mit diesem lassen sich diese Session ganz einfach zum späteren Anschauen herunterladen. Es lohnt sich auf jeden Fall! Also ran ans Downloaden!

This post is powered by www.Giza-Blog.de |
Visit:  Giza-Blog.de Facebook-Page | Follow Kay Giza on Twitter
Daily News on MSDN:  MSDN Aktuell
© Copyright 2006-2011 Kay Giza. All rights reserved. Legal

In der aktuellen Ausgabe der dotnetpro (5/2011) ist mein Artikel “Die Qual der Wahl: UI-Technologien im Vergleich” erschienen.

Aus dem Abstract:

Für UI-Entwickler wird die Lage zunehmend verwirrender: Da gibt es das gute alte Windows Forms, die Windows Presentation Foundation und Silverlight, und seit Neuestem entbrennt eine Diskussion über das kommende HTML5. Die spannende Frage ist nun: „Auf welche Technologie setze ich als Entwickler in Zukunft?“

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3) – this one
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5) 
• REST using the WCF Web API – Post it! (Part 6) 

Recap

In the previous posting I gave you a short introduction to the shiny new WCF Web API from Microsoft.

Of course the shown implementation is faraway from being a real world application sample – so let’s get started to move things forward.

When looking again at our ContactsResource there is at least one thing that (hopefully) won’t happen in real world code:

[ServiceContract]
public class ContactsResource {
	[WebGet(UriTemplate = "")]
	public List<Contact> Get() {
		return new List<Contact>()
			    {
			       	new Contact()
			       		{
			       			Id = 1,
			       			Name = "Glenn Block"
			       		},
			       	new Contact()
			       		{
			       			Id = 2,
			       			Name = "Scott Hanselman"
			       		},
			       	new Contact()
			       		{
			       			Id = 3,
			       			Name = "Scott Guthrie"
			       		}
			    };
	}
}

Moving forward

As you can see, our List of Contacts is instantiated by hand.

This for sure won’t happen in a real world application happen because it is likely that our contacts are stored in a database.

Thus it will also be likely, that we’ll have an Repository handling the CRUD-stuff against this database.

This will make our ContactsResource look like this:

[ServiceContract]
public class ContactsResource {
	[WebGet(UriTemplate = "")]
	public List<Contact> Get() {
		ContactRepository repository = new ContactRepository();
		return repository.Get();
	}
}

Whereas the ContactRepository looks like this:

public class ContactRepository {
	public List<Contact> Get() {
		return new List<Contact>()
		    {
		       	new Contact()
		       		{
		       			Id = 1,
		       			Name = "Glenn Block"
		       		},
		       	new Contact()
		       		{
		       			Id = 2,
		       			Name = "Scott Hanselman"
		       		},
		       	new Contact()
		       		{
		       			Id = 3,
		       			Name = "Scott Guthrie"
		       		}
		    };
	}
}

Ok, this is much better now.

Guess what:  It’s  faraway from that.

It’s not the fact, that we’re new’ing up the Contacts themselves in the Repository as I don’t want to code down the complete Repo for demo.

Instead we didn’t make an progress to the previous version as we’re now simply instantiating the ContactRepository instead of the List of contacts inside our ContactsResource.

In terms of testing we now have an dependency on the database by referencing to the concrete instance of our contacts repository.

Your CI server may have other database settings (or even worse: no database installed at all) than your local machine and your tests will fail miserably.

Poor boy!

In order to get rid of instantiating our repository inside our ContactsResource we will pass it to our constructor and further more, we’ll extract an interface called IContactRepository in order to be able to exchange the concrete implementation of our repository whenever we want to.

Doing it this way is a pattern called dependency injection.

Our updated code:

[ServiceContract]
public class ContactsResource {
	readonly IContactRepository _contactRepository;

	public ContactsResource(IContactRepository contactRepository) {
		_contactRepository = contactRepository;
	}

	[WebGet(UriTemplate = "")]
	public List<Contact> Get() {
		return _contactRepository.Get();
	}
}

public interface IContactRepository {
	List<Contact> Get();
}

public class ContactRepository : IContactRepository {
	public List<Contact> Get() {
		return new List<Contact>()
		    {
		       	new Contact()
		       		{
		       			Id = 1,
		       			Name = "Glenn Block"
		       		},
		       	new Contact()
		       		{
		       			Id = 2,
		       			Name = "Scott Hanselman"
		       		},
		       	new Contact()
		       		{
		       			Id = 3,
		       			Name = "Scott Guthrie"
		       		}
		    };
	}
}

Yet, there’s another problem: Who will instantiate our Repository?

In terms of our ASP.NET MVC application hosting the ContactsResource, this is done inside the Global.asax.cs file.

You may remember ContactResourceFactory:

public class ContactResourceFactory : IResourceFactory {
	public object GetInstance(Type serviceType, InstanceContext instanceContext, HttpRequestMessage request) {
		return new ContactsResource();
	}

	public void ReleaseInstance(InstanceContext instanceContext, object service) {
		throw new NotImplementedException();
	}
}

Using this our code won't compile now, because the instantiation of the ContactsResource is missing the IContactRepository instance.

How do we pass it in then?

One way could be – as already written – instantiate the dependency by ourselves inside the global.asax.cs.

When having only a few dependencies, this may be ok. But speaking of a real application you’ll have tons of them and you don’t want to take care of them the whole day.

But we’re fortunate. Lots of people ran into this before and solved it by creating so called IoC-Containers whose job is to create instances of our classes and handle dependencies between them.

My favorite IoC-Container is LightCore and of course, it is available through Nuget.

After adding the Library Package Reference to our project, we’ll update our code as follows – starting with the updated RegisterRoutes method in Global.asax.cs:

public static void RegisterRoutes(RouteCollection routes) {
	ContainerBuilder builder = new ContainerBuilder();
	builder.Register<IContactRepository, ContactRepository>();
	builder.Register<IResourceFactory, LightCoreResourceFactory>();
	IContainer container = builder.Build();

	var configuration = HttpHostConfiguration.Create()
		.SetResourceFactory(new LightCoreResourceFactory(container));
	RouteTable.Routes.MapServiceRoute<ContactsResource>("contacts", configuration);
}

The LightCore IoC container mainly consists of a class namely ContainerBuilder and an interface called IContainer and works this way:

A ContainerBuilder instance registers all dependencies by calling its Register method and passing in the interface name and the concrete type to be instantiated on application startup.

When registration is done, an IContainer is build by the ContainerBuilder calling its Build method.

The created container is passed into the LightCoreResourceFactory (formerly known as ContactResourceFactory).

The fact that we’re using the IoC container now, leads to a generic implementation of the LightCoreResourceFactory:

public class LightCoreResourceFactory : IResourceFactory {
	readonly IContainer _container;

	public LightCoreResourceFactory(IContainer container) {
		_container = container;
	}

	public object GetInstance(Type serviceType, InstanceContext instanceContext, HttpRequestMessage request) {
		return _container.Resolve(serviceType);
	}

	public void ReleaseInstance(InstanceContext instanceContext, object service) {
		throw new NotImplementedException();
	}
}

As you can see, there’s no reference to the ContactsResource or the ContactRepository at all inside the ResourceFactory.

Thus we don’t need  another Factory when adding further Resources.

In fact there’s more room for optimization as the SetResourceFactory method has an overload that allows us to inject the body of the GetInstance and ReleaseInstance methods directly which makes the creation of the LightCoreResourceFactory obsolete and leads us to the following configuration instantiation:

var configuration = HttpHostConfiguration.Create()
				.SetResourceFactory((serviceType, instanceContext, request) 
					=> container.Resolve(serviceType), null);

Did you notice that we didn’t really speak about the WCF Web API itself since the beginning of this post which simply highlights the fact that it does not get in way using this pattern – well done.

Speaking of done: we’ve finished another hands on lab on the WCF Web API – thanks for reading.

Next time we’ll make it more RESTful and add some tests in BDD style.

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3) – this one
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5) 
• REST using the WCF Web API – Post it! (Part 6) 

Developing Android apps with C# and.NET technologies?

What sounds strange is now possible with Mono for Android 1.0 (short: Monodroid), recently published by Novell. With Monodroid you can develop applications for Android-Smamtphones with Visual Studio 2010. Mono 1.0 is thereby fully integrated in Visual Studio 2010.  The corresponding APIs for the Dalvik engine have been adjusted for C#, also the JIT compiler is fully usable. In addition, the use of F# and IronJS and partly also IronPython and Ironruby with Monodroid should be possible.

From Windows Phone "Mango" Preview a good summary of the coming features for Windows Phone 7 with the “Mango” Update:

Assuming they actually hit this schedule, Microsoft will release a major update to Windows Phone, internally called Windows Phone 7.5 (though that could change) and codenamed "Mango," sometime in the final quarter of 2011. Mango will be made available for free to all current Windows Phone handset owners, but my suspicion is that the best experience will be had on a second generation of new devices that include additional capabilities not found in today's phone. Microsoft first officially unveiled Mango earlier this year, but they provided a lot more information about this release this month at its MIX'11 conference. So I'd like to highlight what we know about Mango so far, with the understanding that things will no doubt change going forward. Indeed, there are many consumer- and business-oriented features coming in Mango that Microsoft has yet to discuss publicly.

 

 

New minimum hardware specifications

One of Windows Phone's most heralded changes from its Windows Mobile predecessor was that the new system would have a much more tightly controlled hardware specification, which Microsoft said would prevent a proliferation of divergent devices that would be very hard to update. I'll pause while you consider the ensuing irony--Microsoft has had nothing but trouble updating the first generation of nearly identical Windows Phones--but it's a good idea regardless.

Oddly, the first generation of Windows Phone hardware allowed for two so-called chassis specifications, the Chassis-1 that we all know and love (800 x 480 touch screen and so on) and then a separate Chassis-2 spec that has never materialized into an actual shipping piece of hardware; this one was to have supported smaller 480 x 320 screens with a hardware keyboard and it was, put simply, Microsoft's version of a Blackberry.

The Chassis-2 spec is dead, and there won't be any phones released with those specifications. Instead, Microsoft is rallying around an updated version of the Chassis-1 spec for Mango. And the specs have changed just a bit since the first generation:

Processor. Whereas the original specification called for 1 GHz or faster ARMv7 Cortex/Scorpion (Snapdragon) or better processor, the new spec calls for second generation Qualcomm ARMv7 (MSM8x55 or MSM7x30) processors, running at 800 MHz or higher. So 1 GHz is no longer the baseline. That's because a new generation of processors with lower clock speeds is both cheaper to make and powerful enough to handle Windows Phone OS, according to Microsoft. But this represents the platform's first foray into the non-luxury end of the market, paving the way for comparatively low-end Windows Phone handsets. (This is something Nokia demanded, but this work was in progress some time ago.)

GPU. As with the first generation devices, Mango-era phones will ship with a DirectX 9-capable graphics processing unit, or GPU. But the Adreno 205 is replacing the earlier Adreno 200 part.

Gyroscope. Mango will support a hardware gyroscope, a feature that was not part of the first generation Windows Phone spec. And in an interesting and related move, no non-supported sensors will be allowed.

What hasn't changed? Most of the spec, actually. All Windows Phones will still ship with capacitive multi-touch screens with 4 or more contact points. A-GPS, accelerometer, compass, light, and proximity sensors. A 5 megapixel or better camera. 256 MB of RAM or more and 8 GB of Flash storage or more. (Most handsets do ship with 512 MB of RAM, Microsoft says, though 8 GB is sadly the default storage capacity.) And three hardware buttons, arrayed in the same layout: Back, Start, and Search. Most dramatically, perhaps, 800 x 480 is the only supported screen resolution for Windows Phone now.

Updated software architecture

With the initial version of Windows Phone 7, the underlying operating system was simply called Windows Phone 7. Now, it's being renamed to Windows Phone OS to obfuscate the versioning (since Mango is version 7.5) and make the branding more obvious. (That is, you have a Windows Phone device running Windows Phone OS.)

Where Windows Phone 7 was based on Silverlight 3 and XNA 3, Mango is based on Silverlight 4 and XNA 4 and supports, for the first time, integration between the two. (In WP7, Silverlight was generally just used for apps and XNA was generally just used for games. Now developers can mix and match.) Silverlight 4 brings improved user interface controls and a Clipboard API for third party copy and paste support, as well as some needed performance improvements.

Windows Phone 7 included Windows Live ID, Xbox LIVE, and Bing integration, and Mango extends those with better location and notification services. And dramatically better support for Asian languages should improve Windows Phone's popularity in international markets.

Multitasking of third party apps

One of the big misconceptions about Windows Phone 7 today involves multitasking. That is, Windows Phone 7 does support full multitasking capabilities, albeit only for those apps that come bundled with the OS. In Mango, multitasking is being opened up for third party apps, and as with Apple before it, Microsoft has come up with a scheme that should work well while preserving battery life and not making the user experience more complex.

At the heart of this system is a new software construct called an agent, so multitasking efficiently may require some app rewriting. This agent is essentially a subset of an app's core logic, and it can run separately from the app's UI, and thus still be running in memory when the user switches to a different app.

And regardless of agents, Mango will support new fast app resume functionality because apps can stay in memory unless that memory is needed for other apps. So switching back and forth between apps should always be faster.

Background tasks

There are a couple of Mango features related to the multitasking infrastructure. The first is background task support.

For example, in Windows Phone 7, only the built-in Zune software provided background audio playback support. Now, third party audio apps-Pandora, Last.FM, whatever--can keep playing in the background too, and utilize the same pop-up notification UI for media control.

Second, Mango will support background transfers for apps that need to perform downloads.

Push notifications

Also related to multitasking is the ability of third party apps to create alarms and reminders. So apps perform background file transfers, for example, could optionally display a toast notification or tile update at the end of the transfer so the user is aware of what happened.

Tiles

Windows Phone's live tiles are, perhaps, one of the platform's biggest differentiators. Instead of providing static icons, as on the iPhone, Windows Phone apps can provide big, expressive, and dynamic tiles that respond and react to notifications and other changes. In Mango, tiles are getting even more intelligent. Developers will be able to create multiple tiles for a single app, for example, and provide "in-app" tiles that are tied to a specific feature and not just to the app generally.

The example: A flight tracker app where you may want to pin one or more individual flights, each with its own notifications, right to your Home screen. Microsoft calls this feature "deep toast" because the original system notifications were called toast, because they appear like slices of toast out of a toaster.

Microsoft is also increasing the number of live tiles you can add to the Home screen from 15 to 30, and tiles can now flip to provide a secondary display on the "back" of the tile.

Internet Explorer 9

Windows Phone Mango will include a new version of the Internet Explorer 9 Mobile web browser that provides hardware acceleration and utilizes the renderer from the desktop version of IE 9. This should dramatically improve the browsing experience on Windows Phone, of course, and increase compatibility with existing sites. And if Microsoft's performance demos are to be believed, IE 9 Mobile will blow the mobile browsers on Android and iPhone out of the water.

Responding to user complaints, Microsoft has also streamlined the IE 9 user experience and now provides a combined app bar and address bar in landscape mode as well.

Twitter

Where Windows Phone 7 included Facebook account integration out of the box, Mango adds Twitter account integration as well. (This feature was originally scheduled for the initial release of the platform, but Microsoft and Twitter had a falling out that has since been resolved.) As with Facebook, Twitter account information will be integrated into the People hub.

New Extras

In the initial version of Windows Phone 7, Microsoft provided third party app access to the Music + Videos and Pictures hubs, via a hard to find "ghetto" area called Extras (or Marquee). In Mango, these capabilities continue in enhanced form, and Microsoft is letting third party apps also tie into Bing via the new Search Extras functionality. This will be exposed in a similar to manner as the existing functionality (i.e. in a hard to find Extras area with Bing search results). And third parties can create Search Extras in just four result type areas: Movies, Places, Events, and Products.

Database services

One of the weird developer-oriented limitations in the original shipping version of Windows Phone 7 was the lack of any on-device database support. This is changing in Mango, of course, with the addition of the SQL Compact Embedded (CE) database, which developers will access solely through LINQ, a way of abstracting database access. Put simply, the use of LINQ means that Microsoft can optimize the low-level database as needed and, if required in the future, actually swap it out for a better-performing replacement.

Additionally, Microsoft is also allowing third party apps to seamlessly access the People (contacts) and Calendar data stores as well.

Sensor and camera access for third party apps

While developers could target the accelerometer in the initial version of Windows Phone, Mango adds developer access to two new sensors, the compass and the gyroscope. Additionally, there is a fourth "virtual" sensor called the Motion sensor that uses the other three physical sensors on the device to calculate movement (or two if your phone doesn't have a gyroscope).

Microsoft is also providing raw Camera access to developers so it's possible that third parties will create full-featured camera apps to replace the terrible (and settings adverse) version that comes stock with Windows Phone.

Networking features

Microsoft is adding various new networking features to Mango, including sockets support and Connect Manager control for third party apps. Sockets is arguably the big deal here: It will allow applications like Skype to appear on Windows Phone for the first time.

Developer tools improvements

With over 1500 new APIs coming in Mango, developers are going to want to get up to speed with this upcoming release as quickly as possible. And on that note, beta versions of the Mango-era developer tools will ship in mid-May, Microsoft says. And they're coming with a lot of new features, many of which, of course, target new Mango features. The emulator will now emulate some sensors, like the accelerometer and location sensor, for example, and will add other enhancements like full media support. Developers will be able to target multiple hardware devices when building apps, for easier testing, and an improved profiler is being added to the free version of the tools too, so developers can figure out why their apps run so slow.

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2) – this one
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4) 
• REST using the WCF Web API – getting more RESTful responses (Part 5) 
• REST using the WCF Web API – Post it! (Part 6) 

As written in the first posting, RESTful Services become more and more important nowadays and Microsoft has started to make WCF a first class HTTP citizen by implementing the WCF Web API.

To get started using the Web API, create a new, empty “ASP.NET MVC 3 Web Application” project.

First of all you’ll have to get the latest bits which is through the kindness of NuGet almost a no-brainer.

Just add the Package reference to the “WebApi.All” package:

When finished installing, add a new class to your project called ContactsResource.

First aim of Web API: keep things simple – that’s what we’ll start with: a simple Resource returning a list of contacts.

Doing so is a straight forward implementation using Web API:

[ServiceContract]
public class ContactsResource {
	public List<contact> Get() {
		return new List<contact>()
			    {
			       	new Contact()
			       		{
			       			Id = 1,
			       			Name = "Glenn Block"
			       		},
			       	new Contact()
			       		{
			       			Id = 2,
			       			Name = "Scott Hanselman"
			       		},
			       	new Contact()
			       		{
			       			Id = 3,
			       			Name = "Scott Guthrie"
			       		}
			    };
	}
}

The Contact class itself is also pretty simple – no magic at all:

public class Contact {
	public int Id { get; set; }
	public string Name { get; set; }
}

To tell Web API which URI to map the contacts resource to, we need to define a URI template. This is done by adding an attribute to the Get()-method.

This attribute also tells Web API which HTTP method to map to the method – as we want to read the list, according to REST principles the HTTP method of choice is GET.

Thus our attributed method looks like this now:

[WebGet(UriTemplate = "")]
public List<Contact> Get() {

The reason why UriTemplate is an empty string, is that we want to access the list of contacts using the following URI:

http://localhost:3421/contacts

So the next consequential question should be: how does Web API know to call our Get method when the above URI is requested?

Simply put: by it’s configuration.

Despite it’s WCF background, configuration in Web API is no XML monster but instead a fancy fluent interface.

To get our basic implementation running, just add the following lines to your RegisterRoutes method in Globals.asax.cs:

var configuration =HttpHostConfiguration.Create()
	.SetResourceFactory(new ContactsResourceFactory());
RouteTable.Routes.MapServiceRoute<ContactsResource>("contacts", configuration);

The ContactsResourceFactory implements IResourceFactory having to methods:

public class ContactResourceFactory : IResourceFactory {
	public object GetInstance(Type serviceType, InstanceContext instanceContext, HttpRequestMessage request) {
		return new ContactsResource();
	}

	public void ReleaseInstance(InstanceContext instanceContext, object service) {
		throw new NotImplementedException();
	}
}

Starting up our web application and navigating to

http://localhost:3421/contacts

returns this XML:

As REST often is about JSON, Web API covers this also out of the box.

Just start up Fiddler and craft your own HTTP request accepting JSON and hit the Execute button:

Guess what!

We get some JSON back:

Seeing that we’ll finish our first small lap around the Microsoft WCF Web API.

But I’ll promise, there’s a lot more to come.

In the next postings we’ll refactor our example to be more RESTful and we’ll test our implementations the BDD way using machine.fakes / machine.specifications.

Furthermore we’ll wire things up using the LightCore IoC-Container.

Stay tuned!

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1)
• REST using the WCF Web API – Basics (Part2) – this one
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5)
• REST using the WCF Web API – Post it! (Part 6)  

In der seit kurzem verfügbaren Ausgabe 02/11 der Visual Studio 1 aus dem ppedv-Verlag ist, inzwischen zum dritten Mal, eine neue Kolumne zu finden: Best of .NET-Kicks!

Hier stellen wir alle zwei Monate die besten bei uns eingestellten Artikel kurz vor. Da es sich hier um eine redaktionelle Auswahl von uns handelt, sind wir natürlich auch immer wieder für Artikel-Vorschläge offen: Schreibt uns einfach mit Link zum DNK-Eintrag, warum ein bestimmter Beitrag es verdient hätte von uns im “Best of” vorgestellt zu werden. Vielleicht könnt ihr schon in der kommenden Ausgabe euren Beitrag mit einem kurzen Abstrakt lesen – schreibt uns einfach eine E-Mail an artikel (dot) vorschlag (at) live (dot) de

Anfang dieser Woche hat das ADO.NET Team die RTW (Release to Web) Version des Entity Frameworks 4.1 auf seinem Blog bekannt gegeben.

Die neuen Releases, die diese Woche verteilt werden, nehmen wohl kein Ende…

Was ist Neu?

• Die DbContext API
  Die DbContext API ist eine Abstraktion der ObjectContext Klasse sowie weiterer Typen, die in den vorherigen Versionen des Entity Frameworks eingeführt wurden. Mit der DbContext API ist jetzt auch der Einsatz des Code First Musters möglich, das mit der letzten Entity Framework Version doch nicht mitgeliefert wurde. Die DbContext API kann in Database First, Model First und Code First Mustern eingesetzt werden.
• Code First
  Eine Softwareentwicklung mit dem Code First Muster ist nun möglich und bietet eine Alternative zu Database First und Model First. Mit Code First wird als erstes ein Model aus C# bzw. VB.NET Klassen gebaut. Anschließend können diese Klassen mittels Data Annotations oder der Fluent API verfeinert werden. Zu guter Letzt können diese Klassen auf eine existierende Datenbank gemapped oder ein neues Datenbankschema generiert werden.

Weitere Informationen:
Link zum Blog Post des ADO.NET Teams

Downloads: ADO.NET Entity Framework 4.1 Installer Entity Framework 4.1 NuGet Paket

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1) – this one
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4) 
• REST using the WCF Web API – getting more RESTful responses (Part 5)
• REST using the WCF Web API – Post it! (Part 6)  

SOA?

(c) geek&poke

When speaking of SOA today, many developers still think about Web Services (which in case of .NET are ASP.NET Web Services or Windows Communication Foundation, briefly WCF) handling SOAP using XML and other standards to enable Remote Procedure Calls (read: calling functions on remote computers).

As remote computers may be part of foreign domains or even available on the internet the need for authentication and authorization came up fast and has been satisfied by introducing the WS-Security extension to SOAP.

Another need of course has been to have reliable messaging which lead to another extension called WS-Reliability.

In order to be able to describe schemas of SOAP messages WSDL had been introduced.

As you can see, there is a great effort to exchange data between two endpoints on the network.

And even worse: the list of extensions and format definitions is by far not complete, not to mention the problems arising in the wild.

And now: the REST

Despite having all these extensions you don’t feel sophisticated nor productive when using SOAP and I would state that SOA has not infiltrated IT business as buzzword-bingo scene wants to make us believe.

On the other hand, the internet grows furious day by day while reaching into all areas of our live.

Internet wouldn’t be that successful if it where slow, unreliable and hard to use and manage.

Internet as most users know it using the browser of their choice is based on the HTTP protocol which carries out the functions of the web based on operations being part of the HTTP specification.

Anyone being familiar with web development should know HTTP verbs (also called “methods”) like GET or POST.

But there are more verbs beneath them like the lesser known PUT or DELETE.

Furthermore HTTP uses so called Status Codes which tell the browser (e.g. with value 200 for “ok”) and sometimes also the user directly (e.g. 404 for “Page not found”) about the state of the current request being handled.

Based on these  and some other elements of the HTTP specification in 2000 Roy Fielding wrote his dissertation where he formed a new architecture for distributed applications using web technologies: Representational State Transfer, briefly REST.

I want to point out that by no means REST based architectures must be used in web applications only. They just re-use technologies being developed for the web.

There's a URI for That

The center of a REST based architecture are resources which can be accessed by an unambiguous URI like:

http://mybookstore.com/book/RESTInPractice

Hence the book “REST in Practice” is accessibly by every client (as the case may be after authentication) when knowing this URI.

In a REST architecture a list of all books could be found here:

http://mybookstore.com/books/

At this time we don’t know which format will be returned calling both URIs nor do we know which HTTP method to use.

But in the definition of REST architectures there’s a clear concept of this:

When getting data from a resource you should always use HTTP GET. This leads to the requirement that by no means the underlying data should be modified by this request so that this operation could be repeated arbitrary and always returns the same data (unless it will be modified by other methods being  designated for doing that).

The format the called method will return can be chosen by the client itself (as long as the resource provides multiple formats).

However, formats are not requested by accessing http://mybookstore.com/book/RESTInPractice/PDF as one may suppose.

It’s accomplished by setting the HTTP header instead.

To request the PDF of the aforementioned book by the already known URI, the accept-type in the HTTP header is set to “application/pdf”.

The URI of the book remains the same:

http://mybookstore.com/book/RESTInPractice

The header is evaluated by the server and if the PDF of the book is available, the resource delivers it in the response.

The fact that the PDF of the book is not available can also be indicated using HTTP:

By setting the status code in the HTTP header of our response to (e.g. 404 for the latter case) practically every state of a resource, request or at least the complete server hosting the resource can be represented.

Further details and sample implementations for .NET and JAVA based REST services and clients can be found in the “REST in Practice” book, which I would recommend to everyone playing around with REST.

Microsoft and REST

Of course there is a Microosft solution for REST based architectures. A few years ago Microsoft released the WCF Starter Kit. However I don’t see it in the hall of fame of Microsoft products.

As REST based architectures become more and more important nowadays and of course .NET developers also need to implement or at least use it, a few month ago Microsoft has started a new project called “WCF Web API” to ease implementing REST using WCF both on server and client side - which I find has become a really good implementation until now.

The latest bits are available at http://wcf.codeplex.com.

Glenn Block, the team lead of the new project has done a Session at Mix 2011 conference called  “WCF Web APIs: “There’s a URI for That” presenting the latest bits and samples.

Since using the WCF Web API for a while now, I’ll publish a series of blog posts on the WCF Web API here in the next days.

These will not only cover the Web API itself but also testing it using the BDD framework machine.specifications/machine.fakes  and wiring things up using the LightCore IoC container. Furthermore I will explain things like usage of HTTP methods like PUT and DELETE and will show off advantages of REST based architectures being implemented using WCF Web API.

Postings published on this series so far:

• Microsoft Web API – the REST is done by WCF (Part 1) – this one
• REST using the WCF Web API – Basics (Part2)
• REST using the WCF Web API – refactoring to IoC style (Part 3)
• REST using the WCF Web API – getting RESTful the BDD way (Part 4)
• REST using the WCF Web API – getting more RESTful responses (Part 5)
• REST using the WCF Web API – Post it! (Part 6) 

SOA – So Oder Anders?

(c) geek&poke

Wenn heute über SOA gesprochen wird, denken viele Entwickler nach wie vor an Web Services (im Falle von .NET sind dies entweder ASP.NET Web Services oder die Windows Communication Foundation, kurz WCF), welche SOAP mittels XML und anderen Standards realisiert und so Remote Procedure Calls (sprich Aufrufe von Funktionen auf fremden Rechnern) ermöglichen.

Da sich die fremden Systeme, auf denen die Dienste bereitgestellten werden, nicht selten in fremden Netzen oder gar im Internet befinden, bestand natürlich schnell der Bedarf für Authentifizierung und Authorisierung, welche z.B. mit der SOAP-Erweiterung WS-Security ermöglicht wurde.

Natürlich wollte man sich auch auf die zuverlässige Zustellung der SOAP-Nachrichten verlassen können und schuf eine weitere Erweiterung namens WS-Reliability.

Damit man die SOAP-Messages beschreiben konnte wurde WSDL ins Leben gerufen.

Wie man sieht, ein ziemlicher Aufwand, um Daten zwischen zwei Endpunkten im Netz austauschen zu können. 

Die Aufzählung der Erweiterungen und Formate ist dabei bei weitem nicht vollständig, ganz zu schweigen von den Problemen, die in der Praxis zu lösen sind.

Und jetzt: der REST

Trotz der o.g. Erweiterungen hat man mit SOAP nicht wirklich das Gefühl, elegant und effezient zu arbeiten und SOA, so behaupte ich, hat sich nicht in dem Maße durchgesetzt, wie es die Buzzword-Bingo-Szene aller Orten Glauben machen möchte.

Auf der anderen Seite gibt es seit Jahren das Internet, das sich rasent schnell verbreitet hat und praktisch in allen Bereiche unseres Lebens eindringt.

Nun wäre das Internet sicher nicht so erfolgreich gewesen, wenn es langsam, unzuverlässig und schwer zu bedienen gewesen wäre.

Das Internet, wie es die meißten Anwender im Browser Ihrer Wahl verwenden, basiert auf dem HTTP-Protokoll, das die Funktionen des Webs über die in der Spezifikation festgelegten HTTP-Operationen realisiert.

Wer sich mit Web-Entwicklung befasst, ist sicher bereits mit HTTP-Verben (oft auch Methoden genannt) wie GET oder POST konfrontiert gewesen.

Neben diesen beiden Verben gibt es noch andere, allerdings eher unbekannte Verben in der HTTP-Spezifikation wie z.B. PUT oder DELETE.

Außerdem arbeitet HTTP mit sogenannten Status-Codes, die den Browser (z.B. mit dem Wert 200 für OK) und manchmal auch den Anwender (z.B. 404 Seite nicht gefunden) direkt über den Status des aktuellen Requests informieren.

Basierend auf diesen und einigen weiteren Elementen der HTTP-Spezifikation verfasste Roy Fielding bereits im Jahr 2000 seine Dissertation, in welcher er eine neue Architektur für verteilte Anwendungen unter Verwendung von Webtechnologien beschrieb: Representational State Transfer, kurz REST.

Dabei sei hier bereits klargestellt, dass REST-basierte Architekturen nicht zwingend im Web verwendet werden müssen, sondern nur die hierfür entwickelten Technologien und Prinzipien anwenden.

There's a URI for That

Im Mittelpunkt einer REST-basierten Architektur stehen Ressourcen, welche jeweils über eine eindeutige URI angesprochen werden können, wie z.B.:

http://mybookstore.com/book/RESTInPractice

Damit ist das Buch “Rest in Practice” für jeglichen Client (ggf. nach Authentifizierung) verfügbar, sofern er diese URI kennt.

Eine Auflistung aller Bücher würde sich bei einer REST-Architektur z.B. hier finden:

http://mybookstore.com/books/

Dabei ist derzeit weder klar, welches Format sich hinter den beiden URIs verbirgt, noch welche HTTP-Methode verwendet wird, um die URI aufzurufen.

Auch hierzu gibt es klare Vorstellungen bei einer REST-Architektur:

Eine URI, unter der Daten gelesen werden können, sollte immer per GET aufgerufen werden. Dies bedingt allerdings auch, dass der Aufruf die zugrunde liegenden Daten niemals verändert, sodass das die Operation beliebig oft aufgerufen werden kann und immer die gleichen Daten liefert (sofern diese nicht durch andere, hierfür vorgesehene Methoden, geändert wurden).

Das zurückgegebene Format der aufgerufenen Methode kann der Client selbst bestimmen (sofern die Ressource mehrere Formate bereitstellt).

Dies geschieht allerdings nicht, wie vielleicht zunächst vermutet über http://mybookstore.com/book/RESTInPractice/PDF.

Vielmehr werden die HTTP-Header des Requests entsprechend konfiguriert.

Um nun das o.g. Buch im PDF-Format unter der bereits genannten URI anzufordern, wird der Accept-Type im HTTP Header auf “application/pdf” gesetzt.

Die URI für das Buch bleibt somit gleich:

http://mybookstore.com/book/RESTInPractice

Den Header wertet der Server entsprechend aus und die Ressource liefert, sofern das Buch als PDF zur Verfügung steht, dieses im Response als PDF aus.

Steht das Buch nicht als PDF zur Verfügung, kann dies ebenfalls mit HTTP-Boardmitteln im Reponse angezeigt werden:

Über den Status-Code im HTTP-Header (z.B. 404, wenn das Buch nicht gefunden wurden) des Response lassen sich praktisch alle Zustände einer Resource, des Requests oder gar des gesamten Servers, auf dem die Ressource gehostet wird, darstellen.

Weitere Details und konkrete Implementierunen für .NET und JAVA-basierte REST-Services und Clients finden sich in dem Buch “REST in Practice”, das ich jedem, der sich mit dem Thema befassen will oder muss (darf?), empfehlen kann.

Microsoft und REST

Natürlich gibt es auch von Microsoft einen Lösungsansatz für REST Architekturen. Bereits seit einigen Jahren existiert das WCF Starter Kit, welches allerdings nicht wirklich in die Ruhmeshallen von Microsoft gehört.

Da REST-Architekturen heutzutage immer wichtiger werden und natürlich auch .NET-Entwickler solche entwickeln wollen oder müssen, hat sich Microsoft nun mit der WCF Web API des Themas nochmals angenommen und wie ich finde, nun eine wirklich gelungene Implementierung auf Basis der WCF auf den Weg gebracht.

Der derzeitige Stand ist unter http://wcf.codeplex.com abrufbar.

Glenn Block, der Verantwortliche hinter dem Projekt, wird auf der Mix 2011 in der Session “WCF Web APIs: “There’s a URI for That” den aktuellen Entwicklungsstand mit Beispielen sowie weiteren Details zur Roadmap etc. präsentieren.

Da ich mich bereits seit einiger Zeit mit der Web API beschäftige, werde ich hier in den nächsten Tagen mehrere Postings zum Umgang mit der Web API bereitstellen.

Dabei kommen in den Beispielen neben der Web API auch das BDD-Framework machine.specifications/machine.fakes sowie der IoC-Container LightCore zum Einsatz. Es wird z.B. die Anpassung und testgetriebene Entwicklung der MIX-Beispiele gezeigt. Außerdem werden auch HTTP-Methoden wie PUT und DELETE behandelt und weitere Vorteile REST-basierter Architekturen vorgestellt.

Es ist wieder soweit! Wir haben für Sie noch einmal neue Trainingstermine zum Thema SharePoint 2010 geplant. Dieses Mal in umgekehrter Folge, das Briefing in Köln und das Camp in Unterschleißheim und hoffen, dass Sie es dadurch in Ihrem vollen Kalender unterbringen können.

Briefing zu neuen Geschäftspotentialen für Entscheider am 20.06.2011 25.05.2011 in Köln

• Potenziale für Partner durch SharePoint 2010 und Office 365
• Integration von SharePoint in Partnerlösungen
  • Grundlagen, Vertrieb und Integration mit Visio
• Integrationsszenarien SharePoint inhouse und Office 365 – Vorteile für Kunden
• Technische Abgrenzung: wo macht SharePoint in Partnerlösungen Sinn?
• SharePoint 2010 – eine durchgehende Entwicklerstory für Partner
  • Welches Know-How Ihre Entwickler aufbauen sollten
  • VS 2010, Sandboxed Solutions, Developer Dashboard, Office Integration/Entwicklung

Zum Briefing anmelden...

Entwickler-Camp für technischen Einstieg am 16.06.2011 23.05.2011 in Unterschleißheim

• Ein technischer Überblick über SharePoint 2010
• Die Neuerungen in SharePoint 2010 für Entwickler
  • Ribbons, Client Object Model, Silverlight, Workflows
• SharePoint 2010 in der Cloud mit Office 365
  • Die neue Plattform für SharePoint-Lösungen
• SharePoint 2010 – eine durchgehende Entwicklerstory für Partner
  • VS 2010, Sandboxed Solutions, Developer Dashboard, Office Integration/Entwicklung, Visio
• 1-2-3: SharePoint beim Partner
  • Ein Fahrplan für den Wissensaufbau: was sollte man wissen und wo informieren?

Zum Camp anmelden...

Update 27.04.2011: Termine wurden geändert.

Gerade wenn Mitarbeiter das Unternehmen wechseln kommt es immer mal wieder vor, dass noch verschiedene Files nicht eingecheckt oder exklusiv ausgescheckt sind.

Mit Hilfe von tf.exe kann man recht einfach vorhandene Workspaces auflisten und löschen, auch wenn die AD-Accounts der Besitzer des Workspaces nicht mehr existent sind.

Auflisten aller Workspaces eines Users

tf workspaces /collection: <<YOUR_TPC_URL>> /owner: <<DOMAIN>>\<<USERNAME>>

Entsprechend der Parameter werden alle Workspaces des angegebenen Users für die angegebene TeamProjectCollection aufgelistet.

Löschen eines Workspaces

tf workspace /delete /collection: <<YOUR_TPC_URL>> <<YOUR_WORKSPACE_NAME>>

Nach der obligatorischen Sicherheitsabfrage ob man denn wirklich den Workspace löschen möchte, wird die gewünschte Aktion ausgeführt.

WICHTIG: Das Löschen eines Workspaces kann nicht rückgängig gemacht werden!

Die DNUG Braunschweig trifft sich am 19.04.2011 um 19:00 im Restaurant Zucker (Tagungsraum). Uns kommt Nicolai Josuttis mit einem Vortrag über SOA besuchen.

Das 21. Jahrhundert ist das Jahrhundert der Globalisierung.
Dies gilt auch für die IT.
Systementwicklung wird immer öfter nur zu einem Teil eines sehr viel umfassenderen Ansatzes, nämlich der Wartung und Pflege von Systemlandschaften.

Für Systemlandschaften (also große Systeme, die wiederum aus kleineren Systemen mit unterschiedlichen Eigentümern bestehen) gelten aber andere Regeln als für Einzelsysteme.Und genau hier kommt SOA ins Spiel.
SOA bietet Konzepte wie lose Kopplung, hohe Interoperabilität und Service-Orientierung, die uns in die Lage versetzen, fachliche Anforderungen, die über mehrere Systeme verteilt sind, nachhaltig zu verwalten.Dabei wird zum Beispiel Heterogenität akzeptiert anstatt dieses "Problem" mit Harmonisierung zu bekämpfen (ein Kampf, den man nie gewinnen kann).

SOA ist also gar nicht tot, wie es Anfang 2009 durch die Presse geisterte. Es handelt sich vielmehr um eine Strategie, die ihre Zukunft noch vor sich hat. Allerdings ist diese Strategie weder einfach noch billig, weshalb man SOA nur dort einsetzen sollte, wo man es nicht vermeiden kann.

Aufgrund seiner Erfahrung bei der operativen Umsetzung von SOA in internationalen Firmen wird Nicolai Josuttis, Autor von "SOA in der Praxis", diese Sichtweise von SOA erläutern und anhand vieler konkreter Beispiele aus der Praxis untermauern.

Bio:
Nicolai Josuttis (http://www.josuttis.de) ist seit vielen Jahren als unabhängiger technischer Projektleiter, Systemarchitekt, Berater und Autor international tätig. Er gilt als einer der weltweit führenden Experten für die operative Umsetzung von großen strategischen Projekten in unterschiedlichen Domänen (Finanzwesen, Telekommunikation, Verkehrstechnik, Automobilbau und Maschinenbau). Er ist ein bekannter Sprecher und Autor verschiedener Bücher zur praktischen Softwareentwicklung, darunter die Standardwerke "SOA in Practice" und "The C++ Standard Library", die in viele Sprachen übersetzt wurden.

Wie immer ist dieses Event kostenlos und jeder .NET Interessierte ist herzlich willkommen!

Weitere Informationen zur DNUG Braunschweig findest du hier.

Sie verwenden Visual SourceSafe oder eine andere Versionsverwaltung und wollen zu Team Foundation Server wechseln?

Wir unterstützen mit dem kostenlosen SourceSafe-zu-TFS-Migrationspaket plus kostenlosem Profi-Support am Telefon.

Mit dem kostenlosen VSS-zu-TFS-Migrationspaket erhalten Sie das komplette Rüstzeug, das Sie benötigen, um ihre bestehende Versionsverwaltung erfolgreich zu Team Foundation Server zu migrieren, inklusive Schritt-für-Schritt-Videoanleitung und kostenlosem Telefonsupport von den Team Foundation Server-Experten von AIT.

So geht's:

• Downloaden Sie das kostenlose VSS-zu-TFS-Migrationspaket
• Führen Sie die Schritt-für-Schritt-Anleitung durch, oder folgen Sie der Videoanleitung und migrieren Sie eigenständig
• Wenn Sie stecken bleiben oder mehr wissen wollen: Holen Sie sich Hilfe! Der kostenlose Telefonsupport der Team Foundation Server-Experten von AIT hilft Ihnen gerne weiter

Am 21.04.2011 um 18:00 Uhr findet das nächste Treffen der .NET Usergroup Karlsruhe (XING-Gruppe der .NET Usergroup Karlsruhe) statt.

Thema

Flexible Softwarearchitekturen mit Inversion of Control (IoC)

Details zum Thema

Flexible Softwarearchitekturen sind der Wunsch eines jeden Softwareentwicklers. Und erst Recht jedes Auftraggebers. Software muss heute schnell an die Bedürfnisse des Marktes angepasst werden können.

Alexander Groß zeigt in seinem Vortrag bei der .Net User Group Karlsruhe wie dies mit Inversion of Control (IoC) realisiert werden kann:
Flexible Softwarearchitekturen mit Inversion of Control (IoC)

• Grundlagen solider, wartbarer zukunftsfähiger Softwarearchitekturen
• Einführung in Castle Windsor und StructureMap
• Erweiterbarkeit des IoC-Containers mit Facilities, Installern und Registries
• Konfiguration des Containers mit XML, C# und Boo
• Komposition komplexer Architekturen
• Refactoring bestehenden Codes hin zu kleinteiligen Komponenten

Über den Sprecher

.NET developer and trainer by day, hobby chef by night. Loves sharp tools like Git and kitchen knives.

Teilnahme

Bitte meldet Euch wieder via XING an, die Location ist wieder DJK-Ost:

DJK-Ost
Friedrichstaler Allee 52
76131 Karlsruhe

Anfahrt: http://www.djk-ost.de/anfahrt.htm

Since using machine.fakes for a while, some ReSharper Templates (File and Live) arose from daily work.

You can download them from here: machine.fakes.resharpertemplates.zip (1.81 kb)

[19.04.2011] Updated the ZIP file due to bugs in namespace definition in file templates.

Die magischen Buchstaben, wenn es darum geht Anwendungen mit Benutzeroberflächen zu entwickeln, kennt wohl jeder: MVP.  Und wer sie nicht kennt, sollte sich schnellstmöglich damit vertraut machen! Es gibt viele schöne Beispiele hierzu, eines ist sicherlich auch das von Stefan Kölle. Woran es, meiner Meinung nach, aber wie die meisten Beispiele auch krankt, ist die Steuerung zwischen den einzelnen Views/Presenters.

Besonders deutlich wurde mir dieser Mangel, als ich vor Kurzem folgenden Quellcodeauszug sah:

public class MyClass
{
   ...
   public void ShowOtherForm()
   {
      using(MyPresenter presenter = new MyPresenter())
      {
         presenter.Initialize();
      }
   }
}

public class MyPresenter()
{
   public void Initialize()
   {
      ...
      this.View.Show();
   }
}

Don’t do this at home, kids!

Den Presenter direkt im Code zu erzeugen bereitet mir schon ein Gefühl von Unbehagen, aber den View dann auch noch im Initialize anzuzeigen – das bereitet mir Magenschmerzen. Auf der Suche nach eleganteren Lösungen ist mir aufgefallen, dass viele Beispiele gerade in diesem Kontext Ihre Schwächen haben. Aber wie kann eine Lösung hierzu sehen?

Meine Antwort lautet: ApplicationController. Martin Fowler hats und Microsoft hat es auch.

Der ApplicationController enthält die Logik, welche View anzuzeigen ist, die vorher über die verschiedenen Presenter verteilt war. Zum Einen wird so die Logik zentralisiert zum Anderen werden damit aber auch etwaige Quellcode Dopplungen aufgehoben.

Wenn nun zwei Presenter die gleiche View anzeigen sollen, erhalten diese Presenter nur noch eine Abhängigkeit zum ApplicationController und rufen darauf eine gemeinsame Methode auf. So wird der anwendungsweite Ablauf nur noch über eine zentrale Komponente kontrolliert.

Ich habe eine Weile darüber nachgedacht, wie ich das Kind am besten beim Namen nennen kann. Dabei entstand u.a. die Idee ViewNavigator, aber letztlich trifft es der Name ViewConductor am besten. Und so sieht mein erster Versuch eines ViewConductors aus.

public class ViewConductor : IViewConductor
{
   private readonly IMainView _mainView;
   private readonly IMainViewService _mainViewService;
   private readonly IPresenterFactory _presenterFactory;

   public ViewConductor(IMainView mainView, IMainViewService mainViewService, IPresenterFactory   presenterFactory)
   {
      _mainView = mainView;
      _mainViewService = mainViewService;
      _presenterFactory = presenterFactory;
   }

   public void OpenView<TPresenterType>() where TPresenterType : IPresenter
   {
      var presenter = this._presenterFactory.CreatePresenter<TPresenterType>();
      presenter.Activate();
   }

   public void ShowPersonDetails()
   {
      this.OpenView<IPersonDetailPresenter>();
   }
}

public class PersonDetailPresenter : IPersonDetailPresenter
{
   private IPersonService _personService;

   public PersonDetailPresenter(IPersonDetailView personDetailView, IPersonService personService)
   {
      this._personService = personService;
      this.View = personDetailView;
   }

   public IPersonDetailView View { get; private set; }

   public void Activate()
   {
      this.View.Presenter = this;
      this.View.Show();
   }
}

Ja, es ist die Anwendung eines MVP Patterns, aber müssen deshalb die Komponenten auch danach benannt werden? Ich nenne meinen Hund auch nicht Hund (oder Mr. Hund ). Ist es vielleicht nicht sinnvoller die einzelnen Komponenten nach ihrer Verwendung zu benennen? Aus meiner Sicht unterstützt das zudem ein Presenter-First Vorgehen, weil der Ablauf dadurch offensichtlicher wird.

Hier werde ich mit meinem nächsten Beitrag wieder ansetzen.

Kleingeräte bringen meist ihr eigenes, individuelles Ladegerät mit. Wer Handy, Nintendo, Netbook etc. aufladen möchte, hat schnell überall Kabel herumliegen. Mich hat das irgendwie genervt und sah auch nicht schön aus.

Die Lösung: Ein Podest, auf welches man die zu ladenden Geräte ablegen kann. Ladegeräte und Kabel können unsichtbar aber dennoch leicht zugänglich verstaut  werden.

Das Ganze ist mit relativ wenig Aufwand zusammen gebaut. Die Materialkosten betragen ca. 15-30 Euro.

Los gehts!

Hier das Rohmaterial: Eine Holzkiste aus dem Baumarkt und 1-2 Steckdosenleisten. Nicht im Bild: Eine Holzplatte und etwas schwarze Samt-Klebefolie.

Zuerst in den Boden der Kiste ein Loch für den 240 Volt Stecker der Mehrfachsteckdose und Lüftungsschlitze schneiden - entweder per Laubsäge, Dremel oder Lasercutter.

Ungefähr so sollte es dann ausgeschnitten aussehen.

In die Kiste werden nun die Steckdosenleisten geschraubt oder geklebt

Jetzt noch eine Anzahl Abstandshalter zurechtschneiden. Diese sollten so lang sein, dass sie (zuzüglich der Dicke der Holzplatte) etwa 1-2cm niedriger sind, als die obere Kante der Holzkiste (gemessen von innen).

Die Abstandshalter zusammenbauen...

...und in in die Kiste montieren.

Nun die Holzplatte mit der Samt-Klebefolie bekleben...

...und so ausschneiden, dass sie genau in die Holzkiste passt. An den Rändern vorher Aussparungen für die Kabel bohren.

Fertig!

 Zusammengebaut und im Einsatz sieht das dann so aus:

Die fertige Ladekiste mit Handy, Netbook und Tablet

Alternativ ohne Netbook und dafür mit Nintendo

Das folgenden Beispiel hat vermutlich (fast) jeder schon mal gesehen – so, oder so ähnlich zumindest, sieht eine landläufige Registrierung von Typen in einem IoC Container aus…

public TestRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   ForSingletonOf<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
   For<IMyView>().Use<MyDRYView>();
   For<IService>().Use<SuperService>();
   For<IRepository>().Use<WhatSoEverRepository>();
}

Es werden mehr oder viele Projekte angelegt, um eine saubere Trennung zwischen Schichten und Verantwortlichkeiten zu gewährleisten. Es dürfen alle Schichten nur über Kontrakte miteinander kommunizieren. Eine der typischen Abbildungen, die in diesem Zusammenhang häufig zu sehen ist, ist die schematische DIP Darstellung von Uncle Bob, die dem folgenden entspricht.

Jede Schicht kommuniziert mit der unterliegenden über Kontrakte, die Abhängigkeiten werden wasserfallartig nach unten durchgereicht. Was passiert aber durch eine solche Registrierung? Die Isolation der einzelnen Schichten wird dahin gehend konterkariert, dass wir eine Über-Topschicht haben, die ALLE unterliegenden kennt.

Die erste Frage, die sich mir stellt: Warum trenne ich dann überhaupt in verschiedene Projektdateien? Diese Trennung ist doch schließlich ohnehin nur eine logische, die durch die Aufteilung in verscheidene Projektdateien nur unterstützt werden soll. Interessant wird eine solche Trennung erst dann, wenn das Entwicklerteam groß genug ist, dass isoliert an verschiedenen Komponenten gearbeitet wird oder aber verteilt gearbeitet wird.

Ich aber habe diese Struktur nun schließlich gewählt, also warum dann nicht die Registrierung zumindest auf die Komponenten aufteilen. Jede Komponente registriert Typen der ihr untergeordneten Komponente. Es gilt ohnehin als best-practice die Registrierung inhaltlich auf verschiedene Teilregistrierungen aufzuteilen – warum dann nicht auch auf die Komponenten?

Die Mechanism-Schicht wird also sie Registrierung für die Utility-Schicht beinhalten, die Policy-Schicht enthält die Informationen über die Mechanism-Schicht. Aufgrund der auto-discovery Mechanismen der verschiedenen Container sollte dies damit keine großes Problem darstellen.

In Zukunft werden die Registrierungen dann anders aussehen - oder aber die Anzahl der Projekte einfach eingedampft.

public WebRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
      x.LookForRegistries();
   });

   ForSingletonOf<HttpContextBase>().Use(() => new HttpContextWrapper(HttpContext.Current));
   For<IMyView>().Use<MyDRYView>();
}

public ServiceRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   For<IService>().Use<SuperService>();
}

public DataRegistry()
{
   Scan(x =>
   {
      x.AssembliesFromApplicationBaseDirectory();
      x.TheCallingAssembly();
   });

   For<IRepository>().Use<WhatSoEverRepository>();
}

Eigentlich recht unüblich und daher überraschend veröffentlichte Microsoft eine Woche vor der MIX-Konferenz in Las Vegas eine Stellungsname in Sachen Silverlight und HTML5 auf dem Silverlight Team Blog und bestätigte eine dagegen weniger überraschende als vielmehr erwartete Ankündigung - die Silverlight 5 Beta wird auf der MIX veröffentlicht.

[1] http://team.silverlight.net/announcement/standards-based-web-plug-ins-and-silverlight/

Die Ausführung ist insofern zusätzlich lesenswert, da die Autoren Walid Abu-Hadba, Scott Guthrie und Soma Somasegar die führenden Köpfe hinter der Strategie von Microsoft in Sachen Evangelismus und die Entwicklung von Entwicklerwerkzeugen und -Technologien sind. Strategisch ist dieser Schritt nachvollziehbar - eine klare Kommunikation im Vorfeld einer öffentlich wirksamer Konferenz wie MIX ist die Lektion, die Microsoft schmerzlich mit der PDC-Konferenz im letzten Jahr gelernt hat. Eine nicht ausreichend erläuterte Aussage und schon hat man mit einer Masse an Deutungen im Netz und in der Presse zu kämpfen.

Aktueller Trend in der Software-Entwicklung erinnert mich an die alten Cross Media Publishing Zeiten am Anfang des Jahrhunderts, als die Fokussierung auf medienneutrale Speicherung und die Verteilung auf diversen Ausgabekanälen die Blütezeit der ECM/WCM Systeme ankündigte.

[2] http://de.wikipedia.org/wiki/Cross_Media_Publishing

Damals waren die Ausgabekanäle etwas anders definiert - hauptsächlich ging es um die Vereinheitlichung der Web- und Print-Ausgaben. Auch wir haben mit AxCMS.net schon immer die Strategie verfolgt im Frontend (Kundenprojekt) vollkommen unabhängig zu bleiben - ob Microsoft ASP.NET mit MVC oder Silverlight bereichert, oder nun die Kunden HTML5 wollen - die WCM-Engine soll es verwalten und ausgeben können. Dies ist die einzig sinnvolle Strategie ..

[3] http://de.AxCMS.net

Heute sind wir sowohl in der Technik- als auch in der Geschäftswelt einen ganz großen Schritt weiter und haben mit dem aktuellen Cross-Platform Trend eine neue Dimension der Komplexität erreicht. Einfacher wurde es nicht ..

Um die Vielzahl der heutigen Geräte in Desktop-, Mobil- und Embedded-Bereichen mit unterschiedlichen Betriebssystemen und Applikationen zu bedienen geht kein Weg an HTML in der Version 5 kombiniert mit JavaScript vorbei. Es ist insofern nur konsequent, dass Microsoft die verbesserte Unterstützung für die Entwicklung mit HTML5 ankündigt. Auch deshalb weil HTML5 entgegen oft in der Presse verlautbaren Aussagen noch weit von einem Standard entfernt ist. So dynamisch die Entwicklung der HTML5-Spezifikation und so unterschiedlich die Implementierungen in diversen Browsern sind, werden wir die déjà vu Gefühle aus den 90en Jahren nicht schnell loswerden können.

[4] http://de.wikipedia.org/wiki/HTML5

Nicht destotrotz ist es ein sehr wichtiger Trend, der inzwischen auch halbfertige HTML5-Spezifikation zu einem de facto Standard konsequent etabliert. Insbesondere auf mobilen Geräten, speziell auf den Smartphones setzt sich der Trend zu den sog. hybriden Applikationen fort. Hinter diesem Namen verbirgt sich die Strategie eine native mobile Applikation als Shell um einen HTML5-fähigen embedded/mobilen Browser (meistens basierend auf der WebKit-Engine) zu bauen. Die native Applikation übersetzt und übernimmt die Kommunikation mit dem Gerät, da Browser bekanntlich diese Rolle nicht ausführen kann.

Die initiale Erstellung einer solchen hybriden Applikation bietet auf der Kostenseite wenige Vorteile gegenüber der Entwicklung einer nativen Applikation. Unter dem Strich ist es sogar meistens aufwendiger und umständlicher, da vieles nur über einen Workaround möglich ist. Beispielsweise wenn die Applikation im Stand-By Modus beim ausgeschalteten Bildschirm im Hintergrund laufen und mit der Hardware kommunizieren muss. Allerdings wird hier die "Wiederverwendbarkeit" angepriesen, einmal entwickelte Applikation lässt sich auf diverse Plattformen mit sehr wenig Aufwand übertragen und noch einfacher Pflegen.

Grundsätzlich stimmt die Aussage schon. Natürlich erzählt man hier aber auch viele Märchen und gibt Versprechen, die nie eingehalten werden können. Jeder Entwickler, der mit JavaScript etwas umfangreicher gearbeitet hat, kann sicherlich ein paar Geschichten erzählen. Aber der Trend setzt sich unaufhaltsam fort. Eines bleibt den nativen Applikationen auch in diesem Fall vorbehalten - die derzeit viel gefragte User Experience. Eine hybride Applikation ist und bleibt eine Web Seite, mit allen Vor- und Nachteilen. Sowohl die Geschwindigkeit, die Unterstützung der Hardware (bspw. Multi-Touch) sowie die nahtlosen Übergänge zwischen den Zuständen zerstören die Begeisterung der Nutzer.

Was auf den mobilen Geräten gilt, gilt natürlich auch im Web. Eine Web-Seite mit HTML5 und Ajax, sogar hardware-beschleunigt bleibt eine Web-Seite mit allen Vor- und Nachteilen. Sie mögen auf einem Desktop PC weniger ausgeprägt sein, als auf einem Tablet PC, aber sie sind da – die Seite ist nie automatisch auf allen Browsern und allen Geräten lauffähig, noch ist die Entwicklung mit nur einem Werkzeug und Framework möglich. Von einer Offline-Fähigkeit gar nicht zu sprechen. Man kann nicht magisch mit den Fingern schnipseln ..

Die Videos können mit HTML5 abgespielt werden. Neue Entwicklungen wie Smooth / Adaptive Streaming und Mehrkanalton bleiben außen vor. So ist es mit fast allen Funktionen – die Cross-Platform Fähigkeit kauft man sich mit den Abstrichen im Funktionsumfang und einer fragmentierten Entwicklung.

Die HTML5-Spezifikation steht für viele für das standardisierte offene Web, in dem die Hürden überwunden und sowohl die Themen rund um User Experience als auch die fehlende Funktionalität gelöst werden. Eine Traumvorstellung. Leider aber auch nicht viel mehr als Wunschdenken im echten Leben, vor allem in den nächsten Jahren.

Es existiert keine goldene, immer richtige Vorgehensweise. Am Ende bleibt immer die Wahl der besten Vorgehensweise für das eigene Benutzerszenario. In manchen ist die Entwicklung mit Flash und Silverlight sinnvoll, in manchen reicht HTML5 in jedem Fall. Es ist aber in beiden Fällen wichtig, dass die Entwicklung mit vernünftigen Werkzeugen und Frameworks durchgeführt werden kann. Und das ist die spannendste Fragestellung im Moment.

Insofern: Silverlight ist nicht tot, Flash ist nicht tot, HTML4 ist nicht tot, HTML5 ist nicht die ultimative Lösung. Wir sind noch nicht fertig ..

Nobert Eder hat sich zu einem Streitgespräch Gedanken gemacht. Dabei hat er, so ich verstehe Wert auf Anforderungen gelegt.

Wer sich für den Inhalt interessiert und der Meinung ist nichts aus dem Kontext gerissenes lesen zu wollen, darf gerne seinen Post durchlesen.

Er sagt

• Die Anforderungen müssen bekannt, verständlich und vollständig sein.
• Die Bewertung wurde durch die Entwicklung durchgeführt. An dieser Bewertung ist nicht zu rütteln. Bei Engpässen der Ressourcen muss (und das sollte es ohnehin) mit Prioritäten gearbeitet werden.
• Die Bewertung der Entwicklung stellt die Diskussionsgrundlage zwischen Projektverantwortlichen und Kunden dar. An dieser Stelle kann über Prioritäten oder Änderung der Funktionalität diskutiert werden. Bei Änderungen ist eine erneute Bewertung durch die Entwicklung notwendig.

Wer sich mal Lektüre zu Anforderungsmanagement zur Seite genommen hat, der weiß, das hier noch eine ganze Menge mehr dazu gehört. Ich zitiere hier mal gerne Wikipedia:

• Korrekt
• Unzweideutig
• Vollständig
• Konsistent
• Bewertet nach Wichtigkeit und/oder Stabilität
• Verifizierbar
• Modifizierbar
• Verfolgbar (Traceable)

Richtig Anfordern

Hat Norbert an all das gedacht? Vielleicht hat er es. Aber ich konnte es nicht aus dem Text nicht explizit entnehmen.

Wie kann ich etwas verifizieren? Verifizieren heißt bei Software zu zeigen, dass man das richtige gemacht hat! Nur weil ich sage, ich kann ein Haus bauen und etwas hinstelle, heißt es noch lange nicht, das es ein Haus ist. Die Anforderungen müssen also überprüft werden können.

Beispiele für schlechte Anforderungen, die nicht verifizierbar sind:

• Das UI soll bunt sein
• Die Ergebnissdateien sollen verglichen werden
• Das Laden der Datei soll schnell sein

Ist schwarz und rot schon bunt? Oder rot, blau, gelb? Wie soll verglichen werden? Zeilengleichheit? Hashwert? Phonetische Übereinstimmung? Wie sind 2 Minuten schnell? sind 10 Sekunden schnell? Die Trennung von Technischem Inhalt und Beschreibung der Anforderung, sei es aus Benutzersicht, oder dem zu entwickelnden System, gehören erst einmal weg. Es sei denn, der Benutzer ist versiert und es gehört direkt zu seinen Anforderungen (z.B. einen MSSQL zu nutzen). Sie sind alleine deswegen schon getrennt zu betrachten, da Modifizierbarkeit sonst schwer fällt. Wenn sich Änderungen in der Infrastruktur ergeben, die Anforderungen aber nicht betroffen sind, was muss hier gemacht werden? Anpassungen an Dokumentation!

Ganzheit Betrachten

Anforderungen sind speziell im Kontext des Gesamtsystems zu betrachten! Für ein Echtzeitsystem können 5ms schon langsam sein. Messbar heißt im besten Fall also immer mit einer Einheit hinterlegt. Maßeinheiten sind in aller Regel genormt. Hier könnte ich jetzt zu geeigneten Messmitteln abschweifen. Wer sagt mir, das 20 cm wirklich diese Länge haben? Wenn ich auf die anderen Punkte tiefer eingehen würde, kämen wir zu folgendem Ergebnis:

Ohne ein ordentliches Werkzeug tut diese Handarbeit ganz schön weh! Die Versionierung der Anforderungen und der Dazugehörigen Dokumente gehört bei ISO konformem Arbeiten nämlich auch dazu! Ihr wollt gar nicht wissen, was für einen Ratenschwanz das alles nach sich zieht. Hoch lebe die Bürokratie. Schauen wir uns mal im groben an, was für Anforderungen alles so notwendig wird:

Über die Reihenfolge und den Tiefgang möchte ich mich hier gar nicht unterhalten, denn Möglichkeiten der Prozessoptimierung, also wann was sinnvoll ist, kommt auf das System, bzw. die Projektstruktur an. Und Software ist dabei eventuell nur ein kleiner Teil, wenn wir uns nicht nur in reinen Software Projekten befinden.

Reflektion Ermöglichen

Rückverfolgbarkeit über die Prozesskette hinweg ist eine Welt für sich.Spaß macht diese Art der Arbeit allerhöchstens dann, wenn einem die richtigen Werkzeuge die notwendige Infrastruktur abnehmen und ich mich auf den Inhalt konzentrieren kann, also den funktionalen Anteil dessen, was von mir gefordert wird! Und da ist es egal, ob ich Anforderungen schreibe, Design Files entwerfe, Projekt und Testpläne erstelle, oder einen Bericht zu dem Test ausfülle. Mal ehrlich. IDs pflegen über 100 von Dokumentationsseiten ist nichts, was für Menschenhand gedacht ist

Ihr denkt euch sicherlich, das schießt alles über das Ziel hinaus. Da mögt ihr für euch auch recht haben, denn es zwingt euch keiner. Wer diesen Prozess einer ISO konformen Arbeitsweise aber mal miterlebt, kann dann auch wirklich reflektieren, was hier eigentlich an Qualitätskontrollen vorgenommen werden und wozu diese gut sind.

Daraus schließe ich bezugnehmen auf die obige Auflistung von Anforderungen

1. Was nicht Korrekt beschrieben ist, kann nicht “richtiger” werden
2. Was zweideutig ist, kann falsch interpretiert werden
3. Was nicht vollständig ist, kann nicht zusammen gestellt werden
4. Was nicht konsistent ist, provoziert Fehlverhalten
5. Was nicht bewertet wird, kann nicht eingeordnet und terminiert werden
6. Was nicht beweisbar ist, kann nicht überprüft werden
7. Was nicht modifizierbar ist, kann nicht weiter entwickelt werden
8. Was nicht verfolgbar ist, kann nicht gefunden werden

Und vor allem vor jedem Auditor: Was nicht unterzeichnet auf Papier steht existiert nicht.

Wie können wir also ein System nach qualitativen Aspekten auf den Markt bringen wenn wir keine Differenzierte Betrachtung machen und technische Aspekte nur dort lassen, wo sie hingehören: In das System (Design)

Stellt euch also mal beim nächsten Hack-a-thon was ihr damit eigentlich erreichen wollt. Sind es rein funktionale Aspekte, oder gehen diese weit darüber hinaus, weil sie nicht nur meine Persönliche Befindlichkeit oder vorlieben spiegeln?

Am 18. April 2011 findet das 11. Treffen der SharePoint UserGroup SaarLorLux statt.

Zu Gast wird die Firma AvePoint sein, welche die Gelegenheit nutzen wird und Ihre Suite an SharePoint Tools vorstellt. Aktuell stehen noch zwei Themen zur Auswahl, unter denen gewählt werden kann

1. Migration mit DocAve: ein Fallbeispiel
Hier geht es um ein aktuelles Projekt von AvePoint, in dem ein großes Volumen von Daten von unterschiedlichsten Quellen (Livelink, SharePoint 2007, Fileshares, Exchange Public Folder, etc…) nach SharePoint 2010. Michael, der das Projekt betreut, wird seine Praktische Erfahrungen mit den Teilnehmern teilen.

2. Demo der DocAve Plattform
Michael wird einen kurzen Überblick über AvePoint Tools geben. Danach können die Teilnehmer je anch Interesse entscheiden welche Tools Sie gerne näher kennlernen würden. Vorteil ist, dass der Vortrag interaktiv ist und die Teilnehmer die Themen selber aussuchen können die für die relevant sind.

Beide Sessions werden von Michael Denzler gehalten.

Das Treffen findet wie immer in den Räumen der Firma DataOne statt. Los gehts um 18:00 Uhr.

Damit wir vorab etwas besser planen können, bitte ich euch um kurze Anmeldung auf der Xing Seite bzw hier über meinen Blog.

Die kostenlosen TechTalk-Veranstaltungen sind seit vielen Jahren bekannt als ein lebendiges Forum zum Wissensaustausch unter Entwicklern und bieten Gelegenheit, "Microsoft zum Anfassen" zu erleben. Microsoft-Experten vermitteln dabei in Vorträgen ihr Wissen und stehen für Diskussionen zur Verfügung.

Dieses Format bringen wir nun erstmals in die virtuelle Welt und laden Sie hiermit ein, bei der Premiere des TechTalk Online dabei zu sein!

Dieses Format bietet für Sie die Vorteile, die Veranstaltung von zu Hause oder vom Arbeitsplatz zu verfolgen und trotzdem live mit den Experten über die Themen im Live Chat zu diskutieren. Natürlich bietet dies für Sie auch die Gelegenheit, mit anderen Technologie-Enthusiasten zu den Themen wie Windows 7, SQL Server 2008 R2 und Windows Azure zu fachsimpeln.

An den folgenden Terminen werden wir den TechTalk Online ausstrahlen und der Live Chat wird Ihnen zur Verfügung stehen: 19. April, 28. April und 4. Mai – jeweils 14:00 bis 18:30 Uhr.

Sie können sich den TechTalk Online kostenfrei und ohne Registrierung anschauen. Sie können sich allerdings vorab registrieren, sich einen Platz sichern und erhalten zusätzlich folgende Vorteile:

• Sie können an unseren Live Chats teilnehmen und mit unseren Experten live diskutieren.
• Zugang zu einem Vortrag als "Sneak-Preview" ab dem 14. April
• Sie erhalten innerhalb des TechTalk Online Zugriff auf unsere virtuelle Konferenztasche, die einige Präsente für Sie bereithält.

Was Sie in der virtuellen Konferenztasche finden:

• Ein Azure Pass für satte 90 Tage! Normalerweise ist der Azure Pass auf 30 Tage begrenzt.
• Buchdownload für "Windows 7 für Entwickler – Crashkurs"
• Buchdownload für "Microsoft SQL Server 2008 - Überblick über Konfiguration, Administration, Programmierung"

Wir würden uns freuen, Sie bei dieser Premiere des TechTalk Online begrüßen zu dürfen und erwarten spannende Fragen und Diskussionen mit Ihnen!

Hier gelangen Sie zu allen Infos, Vorträgen und zur Registrierung.

Wie schon letzte Woche, stellt Thomas Mentzel wieder einige Fragen in seinem Blog, die es zu beantworten gilt.
Am heutigen SQL-Montag steht die Frage im Raum, was Datenbank-Indizes sind und welche Arten es gibt.
Da ich mir beim letzten Mal schon die SQL Frage geschnappt habe, werde ich heute wieder versuchen diese Frage zu beantworten.

Hinweis: Indizes können nicht komplett in einem kleinen Blogeintrag abgehandelt werden, deshalb ist es ratsam, das Thema in der MSDN zu vertiefen. Hier ist ein guter Einstiegspunkt.

Was sind Indizes?

Ein Index (Singular von Indizes) wird in einer Datenbank genutzt, um Abfragen und Sortiervorgänge zu beschleunigen. Mit Hilfe von Indizes kann die Menge an Daten reduziert werden, die von der Festplatte gelesen werden müssen, um das Abfrageergebnis zu ermitteln. Weiterhin können Indizes die Eindeutigkeit von Daten in einer Tabelle erzwingen.

Es wird im Wesentlichen zwischen Nonclustered Index und Clustered Index unterschieden.

Clustered Index (gruppierter Index)

Ein Clustered Index speichert die Zeilen der zugrunde liegenden Tabelle in sortierter Reihenfolge des Clustered Index Schlüssels. Dieser Schlüssel ist die Spalte die zur Indizierung ausgewählt wurde, wobei auch mehrere Spalten ausgewählt werden können. Pro Tabelle kann nur ein gruppierter Index gesetzt werden, da die Datenzeilen nur in einer Reihenfolge sortiert werden können.
Ein Beispiel: Wir haben eine Tabelle Kunde mit den Spalten ID und Kundenname. Es wurde ein Clustered Index auf die Spalte ID gesetzt.
Fragen wir den Kunden mit der ID 77 ab, geht dies extrem schnell. Suchen wir jedoch nach einem Kunden mit dem Namen ‚Meyer‘ dauert dies viel länger, da der SQL Server jeden Eintrag im Clustered Index durchgehen muss.
Wird in einer Tabelle eine Identity Spalte definiert, wird automatisch ein Clustered Index für diese Spalte erstellt!

Nonclustered Index (nicht gruppierter Index)

Ein Nonclustered Index enthält den Wert des indizierten Schlüssels und den Zeiger auf den Speicherort der restlichen Daten. Der Nonclustered Index ist mit dem Inhaltsverzeichnis eines Buches vergleichbar. Im Inhaltsverzeichnis steht der Wert (z.B. das Schlagwort) nach dem gesucht wird und die Seitennummer (der Zeiger) auf der die restlichen Informationen zu finden sind.
Nonclustered Indizes sind aus diesem Grund sehr gut für Abfragen geeignet, die nach genauen Übereinstimmungen suchen. Wenn in unserer Kundentabelle also ständig nach Kundennamen gesucht wird, wird ein Nonclustered Index auf die Spalte Kundenname von Vorteil sein.
Nonclustered Indizes können auf Tabellen mit Clustered Index angewendet werden, sowie auch auf Heap-Tabellen. Eine Heap-Tabelle ist eine Tabelle die nicht über einen Clustered Index verfügt. Pro Tabelle können mehrere (bis zu 999) Nonclustered Index erstellt werden.

Unique

Sowohl Clustered Indizes als auch Nonclustered Indizes können Unique (eindeutig) sein.
Ein Beispiel hierzu: Wir haben wieder unsere Kundentabelle mit der Spalte ID und der Spalte Kundenname. Auf diese Tabelle wird ein Nonclustered Index gesetzt der für die Spalte Name eindeutig sein soll.
Wenn versucht wird, zwei gleiche Namen einzufügen, gibt es folgende Fehlermeldung:

Cannot insert duplicate key row in object 'dbo.Kunden with unique index 'Index1'

Mit dieser Möglichkeit kann die Datenintegrität der Tabellendaten sichergestellt werden.

Weitere Indizes

Des Weiteren gibt es einige spezielle Indizes deren Bedeutung in der MSDN nachgelesen werden kann:

Index mit eingeschlossenen Spalten
Volltext
Räumlich (für den Geography-Datentyp)
Filtered (für fest definierte Teilmengen)
XML (für den Datentyp XML)

Eigentlich wollte ich ja in englisch schreiben, aber irgendwie ist das aufgrund meiner verschobenen Priorität der Zeitaufteilung eher ein Hemmnis als eine Motivation geworden. Deswegen werde ich wohl wieder in Deutsch schreiben und dafür versuchen wieder regelmäßig zu posten. Im Moment sind meine Lieblingsthemen WPF und F# und es ist gut möglich das ich darüber in nächster Zeit hier das zusammentrage was mir so im Alltag begegnet. Ich habe mir in letzter Zeit zu oft etwas vorgenommen und es dann auf Grund von anderen Priorität wieder mal verschoben. Deswegen werde ich einfach nur das Berichten, was gerade so passiert und in den Blog passt. IronPython kommt bei mir da auch immer wieder auf den Radar, da ich von Berufswegen mit Python unterwegs bin. Vielleicht schaffe ich hier auch mal etwas mehr beizutragen.

Anfangen will ich mit 3 kleinen F# Snippets, die ich auf fssnip.net gepostet habe:

• Ein CSV reader http://fssnip.net/3T
• Ein CSV writer http://fssnip.net/3U
• Ein Versuch die DLR komfortabler in F# zu nutzen http://fssnip.net/3O

Wobei ich bei letzterem feststellen musste, dass Tomas Petricek schon einen eleganteren Ansatz verfolgt hat. Demnach werde ich mir mal Call Sites und RuntimeBinder genauer ansehen um zu verstehen wie C# das implementiert hat. Vielleicht hilft es ja auch mal bei Mono zu spicken. Ich werde zu den snippets bei nächster Gelegenheit auch noch den Hintergrund und einige weitere Gedanken schreiben.

In diesem Sinne:

Gute Nacht und CU soon.

Von Zeit zu Zeit lese ich doch mal wieder meinen Google Reader durch. Und worauf bin ich gestoßen: Den Blog von meinem ehemaligen Kollegen Rene Drescher-Hackel. Kommentare und seine Meinung zu TDD.

Dann will ich mal meine Erfahrung zum Besten geben: Ich empfehle jedem, der Schwierigkeiten hat TDD oder BDD zu verstehen, sich den Vortrag von Gabriel Schenker anzuschauen!

http://vimeo.com/channels/noug#3443349

Schematisch, Schritt für Schritt, auf den Punkt! Wer danach immer noch Probleme hat es zu verstehen oder verstehen zu wollen ... Ich kenne Projekte, in den ist das nicht notwendig. Das heißt dann Forschung, oder Prototyp, oder Spielwiese. Ich schreibe in letzter Zeit viel Code auch ohne Tests. Das nenne ich dann Hacking und der produzierte Code ist effektiv und tut das was er soll. Aber eines ist er nicht: Aufgeräumt, leicht wartbar, Fehlerfrei, Erweiterbar. Ich schreibe zur Zeit wieder viel von diesem Code. Privat zum lernen! Um schnell etwas auszuprobieren, aber der Code fliegt dann auch genau so schnell wieder in den Müll oder in einem Spielzeugprojekt um die gesammelten Ergebnisse später in einer vernünftigen Architektur, d.h. bestimmten Prinzipien und Praktiken angemessen umzusetzen. Ich erwarte von keinem das er seine Zimmerpflanzen pflegt, aber einfach nur einmalig einen Topf zu nehmen und Erde drüber zu schütten reicht nicht um bestimmte Erwartungen zu erfüllen. Die Blume mag irgendwann blühen, vielleicht auch wachsen. Aber eines weiß ich gewiss: Wenn diese Pflanze keine besondere Aufmerksamkeit und Pflege bekommt wird sie wild, wuchert und ist alles andere als schön.

Funktional ist Code wohl immer, wenn er validier- und verifizierbar ist. Die Blume blüht, also ist sie eine. Wenn andere Aspekte als Funktionalität, wie Wartbarkeit, Fehleranalyse, Erweiterbarkeit .... zum Tragen kommen, frage ich mich immer wieder wer am Ende drauf zahlt! Qualität kostet, die Frage ist nur wann und wie viel? Und vor allem sind die Bauchschmerzen und der Stress auf Grund von Angst vor dem eigenen Code unbezahlbar. Was hab ich in meine Berufsjahren Code geschrieben den ich nie wieder freiwillig hätte anfassen wollen.

Wenn jemand von mir Code ohne Tests will mach ich das, nicht meine Verantwortung. Aber nur, nachdem ich auf die Risiken und Nebenwirkungen eindringlich hingewiesen habe. Qualität ist meiner Meinung nach nicht, wenn es funktioniert, sondern wenn bestimmte Merkmale gegeben sind.

Ich programmiere zur Zeit viel F# und Python Code ... und ehrlich, ich vermisse so etwas wie ReSharper. Global Search and Replace habe ich schon mit VC6 und Notepad gekonnt, oder grep. Naja, im Prinzip verstehe ich was Rene sagen will, dass es nicht sein kann, ein Werkzeug benutzen zu müssen. Und keiner muss, aber stellen wir doch mal folgendes in die Waagschale: Wenn es die Arbeit um den Faktor 2 oder 3 beschleunigt, und Fehler zu vermeiden hilft, denke ich ist es dies eine Überlegung, die in Erwägung zu ziehen ist. Die kosten sind schnell wieder durch Produktivität refinanziert und Refactoring macht dann auch noch Spaß, weil es keine Langweilige, Fehleranfällige Roulette Arbeit ist. Manuelle Schritte bedeuten immer eine potenzielle Fehlerquelle mehr. Das es auch ohne Werkzeug funktioniert, kann jeder selbst herausfinden, wenn er ein Paar Minuten darüber nachdenkt und reflektiert was zu einem guten Refactoring gehört und wie das früher so war. Wenn es so gute Werkzeuge wie ReSharper für alles gäbe... Im Übrigen ist die Softwarebranche nicht die einzige die sich an Methoden und Werkzeugen bedient, die ihre Arbeit Effektiver und Sicherer macht.

Es gibt eben Forschung und es gibt Entwicklung, und dann gibt es auch noch Produktion. Da gibt es auch noch einen Produktlebenszyklus von wie vielen Jahren? Wie lange soll ein Produkt vertrieben und gepflegt werden? Naja, nach 1,5 Jahren Erfahrung in Jena mit ISO 13485, Projekt- Anforderungs- und Risikomanagement kann ich meine Hände nur über dem Kopf zusammen schlagen, wenn ich nicht reproduzierbar Softwareeinheiten, -komponenten, -module automatisiert testen kann. Bei 30.000 Quellcodezeilen, oder vielleicht 100.000 mag das noch irgendwie funktionieren, aber ich würde dafür nie Verantwortung zeichnen.

Wer will, dem kann ich mal das ISO konforme Arbeiten etwas näher bringen, was für Fallstricke dort auf einen Warten und warum TDD ein Segen sein kann. Ich kann jeden Verstehen der für und wieder an TDD findet. Aber wirklich rationale und messbare Argumente habe ich in den letzten 7 Jahren Contra TDD/BDD nicht hören können.

Mein Lieblingsspruch der letzten 2 Jahre "Mit Automatisierten Tests werden Logische Fehler auch nicht sichtbar". Kommentar: Stimmt! Wenn ich überall dynamischen Code verwende z.B. Strings oder dynamische Typisierung wo es nur geht. Dynamische Abhängigkeiten haben ihren Sinn! Aber bitte überlege sich mal jeder wann und wo es sinnvoll ist und was es kostet in einem Produkt, das 10 Jahre auf der Werkbank liegt? Ralf Westphal hat dazu vor ziemlich genau einem Jahr einen schönen Post über Abhängigkeiten und ihre Zusammenhänge geschrieben: Abhängigkeiten bewusster wahrnehmen

Über den Sinn und Nutzen von TDD streite ich mich lange nicht mehr. Wer meint, mein Handwerk besser zu können darf es machen. Wer den nutzen nicht sieht, soll die Erfahrung machen was es kostet ein solches Produkt zu betreiben. Mehr als meine praktische Erfahrung kann ich nicht weiter geben. Wer keine Nutzen darin sieht, der wird TDD noch nicht brauchen. Aber ich bin mir sicher, jeder der entweder eine große Codebasis betreuen muss oder über 10 Jahren ein wachsendes Software Produkt betreut, wird die Eigenschaften, die einem TDD in sein Projekt einbringt als ein unbezahlbares Werkzeug erkennen. Wer die Notwendigkeit nicht sieht, braucht sie nicht – noch nicht.

Holt man sich FluentNHibernate via NuGet, erhält man unter Umständen folgende Fehlermeldung bei der Verwendung von NHibernate:

Could not load file or assembly 'NHibernate, Version=3.0.0.2001, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

In den Properties für die NHibernate-Assembly, die im Projekt verwendet wird, steht die Version 3.1.0.4000.

Um das Problem zu lösen, muss ein Assembly-Redirect in der app.config bzw. web.config eingerichtet werden.

Dies kann man per NuGet durch folgenden Befehl erledigen:

Add-BindingRedirect -ProjectName <projectname>

Update: Laut David Fowler ist es nach dem Update auf NuGet 1.2 nicht mehr notwendig, Add-BindingRedirect manuell aufzurufen, da sich NuGet selbst darum kümmert.

Im Rahmen des April Treffens der .NET UserGroup Saar wird Kevin Mees (http://www.codesomnia.de/) das MVVM Framework CaliburnMicro vorstellen. CaliburnMicro ist ein leichtgewichtiges MVVM Framework welches dank Convention over Configuration die Realisierung von alltäglichen Szenarien extrem beschleunigt. Anhand von praktischen Beispielen werden die einzelnen Bestandteile von CaliburnMicro vermittelt und erläutert.

Im Anschluss an den Vortrag sind alle Teilnehmer bei Snacks und Drinks zu Networking und Erfahrungsaustausch eingeladen.

Das Treffen findet wie jedes Mal in den Räumen der DataOne GmbH statt. Im Namen der gesamten UserGroup möchte ich DataOne nochmals für das Community Engagement danken!

Damit wir vorab etwas besser planen können, bitte ich um eine Anmeldung auf Xing, oder hier über meinen Blog.

Danke!

Javascript, wie etwa JQuery,  aus WebParts heraus zu rendern ist eine häufige Anforderung. Wie so etwas, beispielsweise mit Hilfe eines DelegateControls, gelöst werden kann, zeigt ein Artikel von Thorsten Hans.

Nun stand ich aber vor der Anforderung den WebPart in Sharepoint sowie eine WebForms Seite einzubinden. Grundsätzlich ist dies auch mit dem DelegateControl zu realisieren. Mein Vorgehen ist aber etwas Quellcode-zentrischer und ich möchte alles Renderverhalten in einem WebPart aus dem Quellcode heraus steuern.

Für Sharepoint gibt es hierfür die Klasse ScriptLink, in Web Projekten hingegen wird aber der ScriptManager verwendet. Um dennoch beide bedienen zu können habe ich einen Kontrakt IScriptRegistrar erstellt, der nur eine Methode RegisterScript beinhaltet.

public interface IScriptRegistrar
{
    void RegisterScript(IScriptRegistrationParameters registrationParameters);
}

Als Parameter wird eine Klasse erwartet, die die zur Registrierung des Skripts notwendigen Informationen beinhaltet. Der Kontrakt dazu sieht wie folgt aus.

public interface IScriptRegistrationParameters
{
    Page Page { get; set; }
    Type Type { get; set; }
    string Key { get; set; }
    string Url { get; set; }
    bool Localizable { get; set; }
}

In dem Sharepoint Projekt wird nun die konkrete Implementierung SharepointScriptRegistrar mit der Klasse ScriptLink hinzugefügt.

public class SharepointScriptRegistrar : IScriptRegistrar
{
    public void RegisterScript(IScriptRegistrationParameters registrationParameters)
    {
        ScriptLink.Register(
        registrationParameters.Page, 
        registrationParameters.Url, 
        registrationParameters.Localizable);
    }
}

Das Webprojekt dagegen erhält eine weitere Klasse WebScriptRegistrar, die das Skript mit Hilfe des ScriptManagers registriert.

public class WebScriptRegistrar : IScriptRegistrar
{
    public void RegisterScript(IScriptRegistrationParameters registrationParameters)
    {
        var scriptManager = registrationParameters.Page.ClientScript;
        scriptManager.RegisterClientScriptInclude(
        registrationParameters.Type,
        registrationParameters.Key,
        registrationParameters.Url);
    }
}

Der Aufruf des jeweiligen Registrars erfolgt kontextabhängig durch einen IoC Container. So halte ich das Wissen über die Implementierung aus dem WebPart raus und die Registrierung erfolgt nur in der Konfiguration des Containers. Als IoC Tool nutze ich in diesem Fall StructureMap.

So beschreibt der folgende Ein-Zeiler die Konfiguration innerhalb des Sharepoint Projekts.

For<IScriptRegistrar>().Use<SharepointScriptRegistrar>();

Die Registrierung für das Web Projekt sieht dem entsprechend angepaßt aus.

For<IScriptRegistrar>().Use<WebScriptRegistrar>();

Mit Hilfe eines ServiceLocators wird dann der registrierte IScriptRegistrar aus dem Container geholt und die Skriptregistrierung mit dem Aufruf RegisterScript ausgeführt.

var scriptRegistrar = ServiceLocator.Get<IScriptRegistrar>();
IScriptRegistrationParameters scriptRegistrationParameters = new ScriptRegistrationParameters
{
    Page = this.Page,
    Type = this.GetType(),
    Key = "javascript",
    Url = "necrtt/jsgantt.js",
    Localizable = false
};
scriptRegistrar.RegisterScript(scriptRegistrationParameters);

Falls es noch andere Ideen gibt, wie dieses Szenario auch umgesetzt werden könnte, bin ich immer daran interessiert…

“Herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2011 verleihen zu können! Diese Auszeichnung wird an herausragende, führende Mitglieder der technischen Communities verliehen, die ihre wertvollen praktischen Erfahrungen mit anderen Menschen teilen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema VSTO im vergangenen Jahr hoch ein.”

Gestern erreicht mich diese E-Mail mit der Mitteilung, dass ich erneut zum dritten Mal infolge zum Microsoft MVP für VSTO ausgezeichnet wurde. Da bleibt mir nur Danke(!!!) zu sagen. :-)

Es macht großen Spaß ein Teil der Community zu sein und ich freue mich schon auf die vielen Dinge, die dieses Jahr anstehen. Man sieht sich auf einen der nächsten Events!

Sehr geehrte(r) Thorsten Hans,
herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2011 verleihen zu können! Diese Auszeichnung wird an herausragende, führende Mitglieder der technischen Communities verliehen, die ihre wertvollen praktischen Erfahrungen mit anderen Menschen teilen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema SharePoint Server im vergangenen Jahr hoch ein.

Vielen Dank an die Community! Ohne euch ist sowas nicht machbar! Es ist wirklich eine Ehre diese Auszeichnung zu erhalten.

Angepasste TeamBuild Templates können zwar recht einfach aus manuell auf einem anderem TeamProjekt ausgewählt werden (Abbildung 1), allerdings bietet TFS aktuell keine Möglichkeit ein existierendes Template auf alle bestehenden TeamProjekte zu publizieren.

Über die ClientAPI von TFS2010 kann man sich allerdings recht einfach eine kleine Anwendung schreiben, die ein bestimmtes Teamplate von einem TeamProjekt auf alle weiteren TeamProjekte kopiert.

Vorerst müssen allerdings noch folgende Referenzen zum Projekt hinzugefügt werden

• Microsoft.TeamFoundation.Build.Client
• Microsoft.TeamFoundation.Client
• Microsoft.TeamFoundation.VersionControl.Client

internal class BuildTemplatePublisher

{

     public String SourceProjectName { get; set; }

     public String SourceTemplateName { get; set; }

     public String TeamProjectCollectionUrl { get; set; }

     private TfsTeamProjectCollection _teamProjectCollection;

     private VersionControlServer _versionControlServer;

     private IBuildServer _buildServer;

     private String _sourceTemplateServerPath;

     private void EnsureConnection()

     {

         if(_teamProjectCollection== null)

         {

             _teamProjectCollection = new TfsTeamProjectCollection(

               new Uri(TeamProjectCollectionUrl));

         }

          _teamProjectCollection.EnsureAuthenticated();

           if(_versionControlServer == null)

           {

               _versionControlServer = 

                    _teamProjectCollection.GetService<VersionControlServer>();

           }

           if(_buildServer == null)

           {

               _buildServer = 

                   _teamProjectCollection.GetService<IBuildServer>();

           }

       }

     private void EnsureSourceTemplateIsLocated()

     {

         EnsureConnection();

         if(_versionControlServer !=null)

         {

             var foundTemplates = _buildServer

                     .QueryProcessTemplates(this.SourceProjectName);

             var sourceTemplate = foundTemplates

                     .First(ft => ft.ServerPath.Contains(this.SourceTemplateName));

             if(sourceTemplate!=null)

             {

                 this._sourceTemplateServerPath = sourceTemplate.ServerPath;

              }

          }

          if (String.IsNullOrEmpty(this._sourceTemplateServerPath))

              throw new Exception("Source TeamBuild Template not found!");

      }

     private bool ContainsTemplate(String projectName)

     {

         EnsureSourceTemplateIsLocated();

         var allBuildTemplates = this._buildServer

            .QueryProcessTemplates(projectName);

         return allBuildTemplates

                .Any(buildTemplate => Equals(this._sourceTemplateServerPath, buildTemplate.ServerPath));

     }

     public void To(String projectName)

     {

         EnsureSourceTemplateIsLocated();

         if (!ContainsTemplate(projectName))

         {

             var newBuildTemplate = this._buildServer

                  .CreateProcessTemplate(projectName, this._sourceTemplateServerPath);

             newBuildTemplate.Save();

         }

     }

     public void ToAllProjects()

     {

         foreach (var project in this._versionControlServer.GetAllTeamProjects(true))

         {

             if(project.Name.Equals(this.SourceProjectName))

                 continue;

             To(project.Name);

         }

     }

}

Verwendet wird die Klasse BuildTemplatePublisher wie folgt:

var buildTemplatePublisher = new BuildTemplatePublisher()

  {  

     SourceProjectName = "Dev",

     SourceTemplateName = "DataOneSharePoint2010BuildTemplate.xaml",

     TeamProjectCollectionUrl = "https://<<TFS_URL>>/tfs/<<TPC>>"

   };

// Kopieren auf ein bestimmtes TeamProject

buildTemplatePublisher.To("Schufa - Antragsmanagement");

//Kopieren auf alle bestehenden TeamProjectes

buildTemplatePublisher.ToAllProjects();

In der TeamProjectCollectionUrl sind <<TFS_URL>> durch den URI zum TFS auszutauschen, <<TPC>> durch den Namen der TeamProjectCollection.

Hier gibts das gesamte Projekt nochmals zum Download. Im Download ist eine kleine KonsolenAnwendung erstellt, hierbei werden die Argumente die an die Konsolenanwendung angehangen wurden interpretiert

class Program

{

    static void Main(string[] args)

    {

        if(args.Length<3)

        {   

            PrintUsage();

            return;

        }

        var buildTemplatePublisher = new BuildTemplatePublisher()

                                            {

                                                SourceProjectName = args[1],

                                                SourceTemplateName = args[2],

                                                TeamProjectCollectionUrl = args[0]

                                            };

        if(args[3].Trim().Equals("*"))

        {

            buildTemplatePublisher.ToAllProjects();

        }

        else

        {

            buildTemplatePublisher.To(args[3]);

        }

    }

    static void PrintUsage()

    {

        Console.WriteLine("Usage:");

        Console.WriteLine(

          @"<tfsCollectionUrl> 

              <sourceTeamProjectName>

              <sourceTeamBuildTemplateName>

              <targetTeamProjectName> [Use * to publish template to all existing TeamProjects");

    }

}

Zum zweiten Mal veranstaltet der .NET-Stammtisch Konstanz-Kreuzlingen (dieses mal als Verein) die .NET-Community Konferenz See# Party

Unter dem Namen See# Party 2011 und mit dem Motto “3 Screens and a Cloud” werden auch dieses Jahr wieder super Vorträge von vielen bekannten Sprechern präsentiert. Die Agenda ist im Gegensatz zu letztem Jahr etwas anders aufgeteilt. So werden dieses Jahr 20 Sessions angeboten, statt 16 wie letztes Jahr.

Wieder gibt es letztes Jahr eine große Verlosung mit vielen Fachbüchern und einer ganzen Menge Software.

Dieses Jahr gibt es Ansporn für die ersten 25 Anmeldungen einen Rabatt um 15 CHF, bzw. 10 EUR. Es loht sich also schon die schnelle Anmeldung :-)

Anmeldung zur See# Party 2011

Kennenlernparty

Wer möchte kann sich gerne für die Kannenlernparty am Abend vorher in Konstanz registrieren, die wieder in der Hafenhalle stattfinden soll (Änderungen des Veranstaltungsortes werden per Twitter und auf der Website bekannt gegeben)

Die Registrierung hierfür benötigen wir um die Reservierung vornehmen zu können.

Abendveranstaltung

Eine Abendveranstaltung wie letztes Jahr ist vorerst nicht in der Agenda. Allerdings ist geplant, das wir je nach Sponsor-Situation kurzfristig eine Abendveranstaltung mit einem .NET-Coding-Dojo ins Leben rufen. Die Rahmenbedingungen dafür sind gesteckt, wir bekommen also auch eine Woche vor der See# Party eine Abendveranstaltung organisiert. :)

Wenn es soweit kommt, werden wir einen Rundmail an alle registrierten Teilnehmer schicken.

Vielen Dank

Das wir auch dieses Jahr wieder eine so große Veranstaltung auf die Beine stellen können, verdanken wir in erster Linie der .NET-Community selber, die uns beim letztes Jahr tatkräftig unterstützt hat und uns geradezu angespornt hat weiter zu machen.

Ein großes Dankeschön natürlich auch an die vielen Sponsoren die wir bisher gewonnen haben und natürlich an das restliche Team (Golo Roden, Tilo Schinke, Markus [Wilhelm] Schmid und Stefan Zybarth)