Ostatnio wpadła mi w ręce książka The Art of Unit Testing: with Examples in .NET autorstwa Roy’a Osherove’a. Muszę przyznać, że mam nieco mieszane uczucia po jej przeczytaniu.

Minusy:
Książka liczy około 280 stron, ale czytając ją miałem wrażenie, że ta liczba jest mocno naciągnięta – olbrzymie marginesy, bardzo szeroka czcionka, dużo niezagospodarowanego miejsca itp. Samym formatowaniem można by było zaoszczędzić przynajmniej kilkadziesiąt stron – ile drzew mogłoby wciąż rosnąć!

Pierwsze trzy rozdziały od biedy można polecić do przeczytania młodszym programistom – tym bardziej zaawansowanym wystarczy pobieżnie przerzucić te 140 stron wyłapując pojawiające się od czasu do czasu słowa-klucze.

W mojej opinii wybór Rhino Mocks też nie jest zbyt właściwy – może faktycznie jest on popularny, ale wydaje mi się, że zawdzięcza to temu, że jest chyba najdłużej na rynku. Niestety z tego samego powodu jego stosowanie jest bardzo uciążliwe. Dużo łatwiej jest mi wytłumaczyć pewne rzeczy juniorom na przykładzie młodszych i chyba przez to bardziej nowoczesnych frameworków.

Trochę bezsensowne moim zdaniem załączniki z długimi opisami różnych narzędzi – takie rzeczy szybko się dezaktualizują – dla mnie to kolejne 20 stron do „odciśnięcia”.

Plusy:
Pomimo tego, iż książka mówi o testowaniu, nie znajdziemy w niej nachalnej promocji TDD – są tam raptem 3 strony na ten temat, z których możemy dowiedzieć się jak TDD działa, jakie są plusy i minusy itp.

Autor wyjaśnia, co to znaczy pisać dobre testy jednostkowe (generalnie testy muszą być godne zaufania, łatwe w utrzymaniu oraz czytelne) oraz jak poznać te źle napisane. Z książki możemy dowiedzieć się również, że kod testów jest równie istotny, jak produkcyjny kod źródłowy. Opisane zostało także zarządzanie testami, wykorzystanie ciągłej integracji do automatycznego ich uruchamiania, ogromne znaczenie testów zwłaszcza podczas refaktoryzacji kodu itp.

Ostatnie rozdziały mówią o tym, jak wprowadzić pisanie testów do organizacji (autor porusza bardzo ciekawe tematy – np. jak radzić sobie z trudnymi ludźmi, jak stać się promotorem zmian, jak wybrać potencjalne miejsca, od których można zacząć itp.), a także jak pracować ze starym kodem.

Podsumowanie:
Widać, że autor ma olbrzymie doświadczenie i zna bardzo dobrze temat, o którym pisze. Jednak dla mnie ta książka powinna być przynajmniej o połowę cieńsza – jeżeli autor chciał mieć tyle stron, to powinien dodać kilka dodatkowych rozdziałów – np. rozwinąć myśl o wspomnianym tylko wykorzystaniu kontenerów IoC itp. Wydaje mi się, że warto tę książkę podsunąć do przeczytania młodszym programistom (oraz tym, którzy nie mieli do tej pory styczności z testami jednostkowymi) – dla nich ta książka będzie idealna. Dla tych, którzy już na co dzień piszą testy – dobrze jest ją przeczytać, aby uporządkować swoją wiedzę, ale wymienione wyżej minusy mogą w niektórych momentach spowodować lekką irytację podczas lektury.

Z mieszanymi uczuciami, ale jednak polecam dla każdego programisty C#.

public class WeakDelegate<TDelegate>
	where TDelegate : class {
	private readonly WeakReference _weakTarget;
	private readonly TDelegate _proxyDelegate;
	private Action<TDelegate> _cleanUp;

	public WeakDelegate( TDelegate @delegate, Action<TDelegate> cleanUp ) {
		var d = @delegate as Delegate;

		if( d == null )
			throw new ArgumentNullException( "delegate" );

		if( d.Target == null || d.Method == null || d.Method.IsStatic )
			throw new ArgumentException(
				"Can't create weak delegate to static method." );

		this._weakTarget = new WeakReference( d.Target );
		this._cleanUp = cleanUp;

		var targetType = d.Target.GetType();
		var returnType = d.Method.ReturnType;

		var lambdaArgs = d.Method.GetParameters()
			.Select( ( p, i ) =>
				Expression.Parameter( p.ParameterType, "a" + i ) )
			.ToArray();

		var targetVar = Expression.Variable( targetType, "target" );

		var getTargetCall = Expression.Invoke( (Expression)
			this.GetType()
			.GetMethod( "GetTargetBoundExpression",
				BindingFlags.Instance | BindingFlags.NonPublic )
			.MakeGenericMethod( targetType )
			.Invoke( this, new object[ 0 ] ) );

		var returnLabel = Expression.Label( returnType );
		var defaultReturn = Expression.Default( returnType );

		var lambda = Expression.Lambda<TDelegate>( Expression.Block(
			new[] { targetVar },
			new Expression[] {
				Expression.Assign( targetVar, getTargetCall ),
					Expression.IfThenElse(
						Expression.Equal( targetVar, Expression.Constant( null ) ),
						Expression.Return( returnLabel, defaultReturn ),
						Expression.Return( returnLabel,
							Expression.Call( targetVar, d.Method, lambdaArgs ) ) ),
					Expression.Label( returnLabel, defaultReturn )
				} ), lambdaArgs );

		this._proxyDelegate = lambda.Compile();
	}

	public static implicit operator TDelegate(
		WeakDelegate<TDelegate> weakDelegate ) {
		return weakDelegate != null ? weakDelegate._proxyDelegate : null;
	}

	private Expression GetTargetBoundExpression<TTarget>() {
		return (Expression<Func<TTarget>>) ( () => this.GetTarget<TTarget>() );
	}

	private TTarget GetTarget<TTarget>() {
		var target = (TTarget) this._weakTarget.Target;
		if( target != null )
			return target;

		if( this._cleanUp != null ) {
			this._cleanUp( this._proxyDelegate );
			this._cleanUp = null;
		}

		return target;
	}
}

In lines from 23 to 50 using types read from original delegate and expression trees I’m creating proxy TDelegate simmilar to the following metacode:

this._proxyDelegate = (a0...aN) => {
	var target = this.GetTarget<TTarget>();
	if( target == null )
		return default( TDelegateReturnType );
	else
		return target.OriginalDelegateMethod( a0...aN );
}

The implementation is sill quite fast – only 6-9 times slower than direct delegate invocation. It has a lower performance than WeakEventHandler<TEventHandler> described in one of my previous posts which is only 4-6 times slower.
There are also few drawbacks of my solution:

• after the target is garbage collected, the proxy delegate will return default value of the TDelegate‘s return type (I think that this can be solved somehow using for example cleanUp callback)
• cleaning up is not thread safe etc.

The source code with examples is here.

Środowisko .NET charakteryzuje się tym, że samo zarządza cyklem życia obiektów. Garbage collector potrafi wykryć, które obiekty nie są już potrzebne i usunąć je z pamięci. Oczywiście jest to bardzo duże uproszczenie całego mechanizmu – szczegóły jego działania są bardzo dobrze wyjaśnione w opisywanej przeze mnie wcześniej książce "CLR via C#, 3rd edition" w rozdziale 21 – Automatic Memory Management (Garbage Collection).

Oprócz automatycznego zarządzania pamięcią CLR umożliwia także ręczne monitorowanie oraz kontrolę cyklu życia obiektów za pomocą GC handle table. Dodawanie oraz usuwanie wpisów do tej tabeli umożliwiają metody struktury GCHandle. Mechanizm ten jest szczególnie przydatny, kiedy komunikujemy się lub współpracujemy w jakiś sposób z kodem niezarządzalnym, ale część właściwości można także wykorzystać, gdy pracujemy tylko z kodem zarządzalnym – konkretnie chodzi mi tutaj o słabe referencje.

W dużej ogólności obiekt A musi posiadać referencję do obiektu B, aby mógł na nim wołać metody:

Diagram 1. Mocna referencja z obiektu A do obiektu B.

W praktyce wygląda to następująco. Zamiast takiego kodu:

	class ClassB {
		public void Foo() { }
	}

	class ClassA
	{
		private ClassB _objectB;

		public ClassA( ClassB objectB ) {
			// mocna referencja z A do B
			_objectB = objectB;
		}

		public void CallB() {
			_objectB.Foo();
		}
	}

kod klasy A możemy napisać następująco z wykorzystaniem klasy WeakReference i jej właściwości Target:

	class ClassA {
		private WeakReference _weakObjectB;

		public ClassA( ClassB objectB ) {
			// słaba referencja z A do B
			_weakObjectB = new WeakReference( objectB );
		}

		public void CallB() {
			// pobierz referencję do obiektu B
			var objectB = _weakObjectB.Target as ClassB;
			if( objectB != null ) { // jeżeli obiekt B jest jeszcze w pamięci
				objectB.Foo(); // to możemy zawołać na nim metodę Foo
			}
		}
	}

I praktyczne zastosowanie

Opisany powyżej mechanizm można w praktyczny sposób wykorzystać podczas pracy z eventami. Spójrzmy na uproszczony model:

	class Producer {
		public event EventHandler<EventArgs> Event;

		public void Produce() {
			Console.WriteLine( "Producer.Produce - raising event" );
			if( this.Event != null ) {
				this.Event( this, EventArgs.Empty );
			}
		}
	}

	class Consumer {
		public Consumer( Producer producer ) {
			producer.Event += new EventHandler<EventArgs>( this.Consume );
		}

		private void Consume( object sender, EventArgs e ) {
			Console.WriteLine( "Consumer.Consume - consuming event" );
		}
	}

	static class SimpleWeakReferenceExample {
		public static void Run() {
			var producer = new Producer();
			var consumer = new Consumer( producer );

			producer.Produce();
			consumer = null; // konsument nie jest już nam potrzebny
			GC.Collect();
			// consumer i tak przeżyje,
			// ponieważ pośrednio referencję do niego trzyma consumer
			producer.Produce();
		}
	}

Obiekt klasy Producer jest producentem zdarzeń, na które zapisuje się obiekt klasy Consumer. Tworzy się nam taka oto struktura:

Diagram 2. Diagram obiektów dla przykładu Producent-Konsument.

Błędny WeakEventHandler z książki "CLR via C#, 3rd edition"

W książce "CLR via C#, 3rd edition" znajduje się przykładowa implementacja klasy WeakEventHandler bazująca na bardziej ogólnej klasie WeakDelegate<TDelegate>, niestety posiada ona bardzo poważny błąd logiczny, którego – o dziwo – nikt do tej pory nie zgłosił. Problem opisałem w poprzednim wpisie i zgłosiłem go do autora.

Podstawowe założenia do implementacji WeakEventHandler<TEventHandler>

Klasa ma umożliwiać tworzenie słabych event handlerów dla trzech typów delegatów:

• podstawowego, generycznego EventHandler<TEventArgs>
• niegenerycznego EventHandler
• dowolnego delegata, którego sygnatura jest zgodna z jednym z dwóch powyższych (ten scenariusz dodałem po dyskusji z Jeffrey’iem Richterem – ma zapewnić wsparcie dla starszego typu eventów obecnych w dużych ilościach zwłaszcza w WinForms)

Nasza struktura obiektów będzie wyglądać następująco:

Diagram 3. Wymagane połączenia obiektów.

Implementacja WeakEventHandler<TEventHandler>

Sporo eksperymentowałem z różnymi implementacjami, aż w końcu doszedłem do czegoś takiego:

public sealed class WeakEventHandler<TEventHandler>
	where TEventHandler : class
{
	private delegate void OpenEventHandler<TTarget, TEventArgs>
		( TTarget target, object sender, TEventArgs eventArgs )
		where TTarget : class
		where TEventArgs : EventArgs;

	private readonly WeakReference _weakTarget;
	private readonly Delegate _openEventHandler;
	private readonly Action<TEventHandler> _cleanUp;
	private readonly TEventHandler _proxyHandler;

	public WeakEventHandler(
		TEventHandler eventHandler, Action<TEventHandler> cleanUp ) {
		var d = eventHandler as Delegate;
		if( d == null || d.Target == null )
			throw new ArgumentException(
				"Can't make weak event handler to static method.", "d" );

		if( cleanUp == null )
			throw new ArgumentNullException( "cleanUp" );

		// store event handler target as a WeakReference
		_weakTarget = new WeakReference( d.Target );
		_cleanUp = cleanUp;

		// extract the types from the event handler
		var eventHandlerType = typeof( TEventHandler );
		var targetType = d.Target.GetType();
		var eventArgsType = eventHandlerType.IsGenericType
			? eventHandlerType.GetGenericArguments()[ 0 ]
			: eventHandlerType.GetMethod( "Invoke" )
				.GetParameters()[ 1 ].ParameterType;

		// create open event handler for fast calling of the real event handler
		Type openEventHandlerType = typeof( OpenEventHandler<,> )
			.MakeGenericType( eventHandlerType, targetType, eventArgsType );
		_openEventHandler = Delegate.CreateDelegate(
			openEventHandlerType, null, d.Method );

		// create proxy handler that points to our proxy method
		var proxyHandlerMethod =
			typeof( WeakEventHandler<TEventHandler> )
			.GetMethod(
				"ProxyHandler",
				BindingFlags.Instance | BindingFlags.NonPublic )
			.MakeGenericMethod( targetType, eventArgsType );
		_proxyHandler =
			Delegate.CreateDelegate( eventHandlerType, this, proxyHandlerMethod )
			as TEventHandler;
	}

	private void ProxyHandler<TTarget, TEventArgs>(
		object sender, TEventArgs e )
		where TTarget : class
		where TEventArgs : EventArgs
	{
		var target = _weakTarget.Target as TTarget;
		var openEventHandler = this._openEventHandler
			as OpenEventHandler<TTarget, TEventArgs>;

		// if target is still alive
		if( target != null || openEventHandler == null )
			openEventHandler( target, sender, e ); // call it
		else
			_cleanUp( _proxyHandler ); // else clean up
	}

	public static implicit operator TEventHandler(
		WeakEventHandler<TEventHandler> weakEventHandler ) {
		return weakEventHandler != null
			? weakEventHandler._proxyHandler
			: null;
	}
}

Implementacja spełnia postawione wcześniej założenia, co ważne – jest relatywnie szybka – około 4-6 razy wolniejsza, niż bezpośrednie wywołanie delegata. Musimy także podać delegat cleanUp, który umożliwi wyrejestrowanie się ze zdarzenia i posprzątanie, kiedy _target zostanie już usunięty. Wszystkie niezbędne dane są wydobywane z oryginalnego eventHandlera, następnie tworzone są: tzw. open event handler – delegat, który umożliwia późniejsze szybkie wołanie metody na konsumencie oraz proxy event handler – delegat, który wskazuje na generyczną metodę ProxyHandler.

Rozszerzenia

Aby ułatwić używanie ww. implementacji, można skorzystać z dodatkowych extension methods:

public static class WeakEventHandlerExtensions {
	// usage:
	// p.SomeEvent += new SomeEventHandler( c.HandleEvent )
	//                 .AsWeak( eh => p.SomeEvent -= c.HandleEvent );
	public static TEventHandler AsWeak<TEventHandler>(
		this TEventHandler eventHandler, Action<TEventHandler> cleanUp )
		where TEventHandler : class {
		return new WeakEventHandler<TEventHandler>( eventHandler, cleanUp );
	}

	// usage:
	// p.SomeEvent += new EventHandler( c.HandleEvent )
	//                 .AsWeak( eh => p.SomeEvent -= c.HandleEvent );
	public static EventHandler AsWeak(
		this EventHandler eventHandler, Action<EventHandler> cleanUp ) {
		return new WeakEventHandler<EventHandler>( eventHandler, cleanUp );
	}

	// usage:
	// p.SomeEvent += new EventHandler<SomeEventArgs>( c.HandleEvent )
	//                 .AsWeak( eh => p.SomeEvent -= c.HandleEvent );
	public static EventHandler<TEventArgs> AsWeak<TEventArgs>(
		this EventHandler<TEventArgs> eventHandler,
		Action<EventHandler<TEventArgs>> cleanUp )
		where TEventArgs : EventArgs {
		return new WeakEventHandler<EventHandler<TEventArgs>>(
			eventHandler, cleanUp );
	}
}

Użycie

// decision on event consumer side:
producer.Event += new EventHandler( this.HandleEvent )
	.AsWeak( eh => producer.Event -= eh );

// decision on event producer side
// caution, with this construction it's not possible
// to deregister from the event
public class EventProvider {
	private EventHandler<EventArgs> _event;
	public event EventHandler<EventArgs> Event {
		add {
			this._event += value.AsWeak( eh => this._event -= eh );
		}
		remove {
			this._event -= value;
		}
	}

	public void Raise() {
		this._event( this, EventArgs.Empty );
	}
}

Jak widać z załączonych przykładów, użycie klasy WeakEventHandler poprzez extension methods AsWeak jest bardzo proste. Ciekawostką jest możliwość wykorzystania rozszerzeń także po stronie producenta i stworzenie słabego eventa – Jeffrey Richter dostrzegł w tym kodzie błąd – a mianowicie nie jest możliwe wyrejestrowanie konsument z eventa. Aby tego dokonać, należałoby zmienić lekko implementację części remove oraz dodać metody pozwalające na porównanie obiektów WeakEventHandler<TEventHandler< z obiektami TEventHandler.

Implementację klasy wraz z rozszerzeniami oraz opisywanymi przykładami można pobrać tutaj.

The problem that Jeffry wanted to solve is as follows: the reference from the event producer to the event consumer should be weak, so in the case when the event consumer object has no other reason to live, it can be garbage collected. Jeffrey was trying to find a general solution for that and developed the abstract class WeakDelegate<TDelegate> that is holding a weak reference to the original delegate (I’ve removed some unnecessary code to make it clear):

	public abstract class WeakDelegate<TDelegate>
		where TDelegate : class /* MulticastDelegate */ {
		private WeakReference<TDelegate> m_weakDelegate;

		public WeakDelegate( TDelegate @delegate ) {
			var md = (MulticastDelegate) (Object) @delegate;
			if( md.Target == null )
				throw new ArgumentException(
					"Can't do a WeakDelegate to a static method." );

			// Save a WeakReference to the delegate
			m_weakDelegate = new WeakReference<TDelegate>( @delegate );
		}

		protected TDelegate GetRealDelegate() {
			// If the real delegate hasn't been GC'd yet, just return it
			TDelegate realDelegate = m_weakDelegate.Target;
			if( realDelegate != null ) return realDelegate;

			// The real delegate was GC'd,
			// we don't need our WeakReference to it anymore (it can be GC'd)
			m_weakDelegate.Dispose();
			return null;   // The real delegate was GC'd and can't be called
		}

		// All derived classes must return a delegate
		// to a private method matching the TDelegate type
		public abstract TDelegate GetDelegate();

		// Implicit conversion operator to convert
		// a WeakDelegate object to an actual delegate
		public static implicit operator TDelegate(
			WeakDelegate<TDelegate> @delegate ) {
			return @delegate.GetDelegate();
		}
	}

	// This class provides support
	// for the generic EventHandler<TEventArgs> delegate
	public sealed class WeakEventHandler<TEventArgs>
		: WeakDelegate<EventHandler<TEventArgs>>
		where TEventArgs : EventArgs {
		public WeakEventHandler( EventHandler<TEventArgs> @delegate )
			: base( @delegate ) { }

		public override EventHandler<TEventArgs> GetDelegate() {
			return Callback; }

		private void Callback( Object sender, TEventArgs e ) {
			// If the target hasn't been GC'd invoke it
			var eh = base.GetRealDelegate();
			if( eh != null ) eh( sender, e );
		}
	}

So our object diagram looks like below – can you spot the problem?

Object diagram

2. Object diagram after first garbage collection

To solve our problem we need something like this:

3. Object diagram with required references

Kilka lat temu Krzysztof Koźmic polecił mi do przeczytania drugie wydanie książki CLR via C# napisanej przez Jeffrey’a Richtera. Pamiętam, że zrobiłem to wtedy z wielką przyjemnością. Książka dotyczyła CLR w wersji 2.0, w międzyczasie pojawił się CLR w wersji 4.0, więc z niecierpliwością czekałem na kolejną jej edycję, która ukazała się nareszcie na początku 2010 roku.

Do tej pory przeczytałem ją już dwa razy od deski do deski i dodatkowo dosyć często wracam do niektórych rozdziałów odkrywając coraz to nowe szczegóły i ciekawostki. Mogę zdecydowanie stwierdzić, że jest to jedna z najlepszych spośród przeczytanych przeze mnie książek dotyczących .NET. Uważam ją za obowiązkową lekturę dla każdego, kto chce być poważnym i świadomym programistą C#, a nie jakimś tam zwykłym kodoklepaczem znającym jedynie składnię języka. Dzięki niej można dowiedzieć się, co tak naprawdę dzieje się pod spodem, jak są w praktyce realizowane przez środowisko .NET pewne koncepcje oraz dlaczego są one realizowane tak, a nie inaczej.

Autor w prosty i bardzo przystępny sposób za pomocą wielu praktycznych przykładów potrafi wyjaśnić nawet skomplikowane idee i problemy. Powszechnie książkę tę uważa się za przeznaczoną dla zaawansowanych programistów, ale ja osobiście nie podzielam tych opinii. Owszem – jeżeli ktoś już posiada mocne podstawy, to jest w stanie wydobyć z niej dużo więcej niż początkujący programista, jednakże każdy może w niej znaleźć coś odpowiedniego dla siebie i swojego poziomu wiedzy. Nie jest to książka do jednorazowego, szybkiego przeczytania – raczej powinna ona być cały czas do naszej dyspozycji gdzieś tam na półce.

Zdecydowanie polecam dla każdego programisty C#.

Miejsce

Ponieważ do dyspozycji miałem swoją domenę oraz miejsce na serwerze i chciałem je wykorzystać, nie szukałem serwisów umożliwiających założenie i prowadzenie blogu. Dla tych, którzy nie mają takiej możliwości, zapytanie w dowolnej wyszukiwarce zwróci wiele popularnych i darmowych systemów blogowych. Dla mnie osobiście jedną z najważniejszych zalet posiadania własnego serwisu jest możliwość dowolnego modyfikowania plików źródłowych i eksperymentowania ze skryptami, wtyczkami itp.

Platforma

Po moich niedługich poszukiwaniach na zdecydowanego lidera wśród darmowych systemów do blogowania wyrósł WordPress. Jest wolny i darmowy, ilość motywów oraz wtyczek jest ogromna, bardzo dużo osób go używa, więc nie ma problemu ze znalezieniem rozwiązań różnych problemów, no i posiada bardzo rozbudowany system pomocy dla kogoś lubiącego poszperać sobie trochę w kodzie PHP.

Przed instalacją na serwerze docelowym, dobrze jest pobawić się wcześniej systemem w domu. Samodzielna instalacja wymaganego do tego oprogramowania może i nie jest zbyt skomplikowana, ale na pewno zajmuje trochę czasu. Lepiej w tym celu wykorzystać jeden z gotowych pakietów WAMP (lub LAMP) – ja wybrałem EasyPHP, ponieważ posiada coś takiego jak moduły, czyli zestawy wstępnie skonfigurowanych, najpopularniejszych aplikacji webowych, m. in. aplikację WordPress.

Motyw

Domyślny motyw dostarczany z WordPress nie jest szczególnie ładny, więc pierwszą rzeczą, którą chce się zrobić po instalacji, jest zmiana wyglądu. Po wybraniu Wygląd -> Zainstaluj motywy z panelu administracyjnego, mamy możliwość wyszukiwania skórek. Tutaj zaczęły się dla mnie pierwsze schody – paradoksalnie im więcej mam do wyboru, tym trudniej jest mi coś wybrać. Zasadniczo wiedziałem czego szukam – czegoś jasnego, wesołego i zielonego . Po przeglądnięciu setek i przetestowaniu kilkudziesięciu motywów zniechęcony zdecydowałem, że chyba łatwiej będzie zrobić własną skórkę – i tutaj mogę powiedzieć, że to był błąd. Wstępny projekt i rozplanowanie strony zrobiłem bardzo szybko, wgryzłem się mocno w dokumentację WordPress, wszystko zaczęło działać, jak chciałem, ale na tymczasowych elementach, więc zabrałem się za wygląd.

Miałem kilkuletnią przerwę w stosowaniu technologii webowych, nie wspominałem ich najlepiej, ale pomyślałem – mamy przecież CSS3, HTML5 itp., strony powstają na potęgę, na pewno ludzie definiujący te standardy po tylu latach wymyślili, jak ułatwić pracę programistom. Ale okazało się, że było to dla nich za trudne – prosta rzecz, jak np. pozycjonowanie elementów (centrowanie w poziomie lub pionie) bez stosowania magicznych sztuczek, wciąż nie jest możliwa, uzyskanie sensownego ułożenia sekcji za pomocą jedynych, boskich elementów div też jest problematyczne. Na takie przeszkody napotykałem nieustannie i posuwałem się do przodu bardzo powoli. Możliwe, że to kwestia braku wiedzy i doświadczenia, ale mimo wszystko na tle np. WPF czy Silverlight wypadło to bardzo blado.

Jeszcze raz przejrzałem istniejące motywy i zdecydowałem się na my theme with grass and dew, ale okazało się, że nie posiada ona polskiej wersji językowej, a wszystkie teksty angielskie są – jak to się tak ładnie mówi – zahardkodowane, więc musiałem przetłumaczyć je na polskie przeszukując wszystkie pliki php. Przy okazji zwiększyłem szerokość motywu i delikatnie dostosowałem style CSS. Problem prawdopodobnie pojawi się podczas aktualizacji motywu.

Wtyczki

Z wtyczkami eksperymentowałem przez pół dnia, na prawdę jest ich bardzo dużo. Na razie wybrałem następujące:

• Maintenance Mode – umożliwia włączenie trybu maintenance, w którym artykuły są dostępne tylko dla zalogowanych użytkowników, dla reszty świata widoczna jest informacja o trwającej nad stroną pracy. Sama wtyczka również nie posiada polskiego tłumaczenia, ale jego dodanie jest już dużo łatwiejsze, gdyż wykorzystano w niej system tłumaczeń stosowany w WordPress. Dodatkowo stworzyłem swoją własną stronę 503 i dodałem ją do motywu – jest ona wyświetlana w trakcie trybu utrzymaniowego.
• WP-PageNavi – wtyczka ułatwiająca nawigację po artykułach na blogu. Zamiast enigmatycznych odnośników „starsze-nowsze artykuły” wyświetlana jest ilość stron, bieżąca strona itp. Tutaj również trzeba było zaktualizować style CSS oraz ponownie zmodyfikować szablony motywu.
• SyntaxHighlighter Evolved – jedna z wielu przetestowanych przeze mnie wtyczek służących do osadzania kodu źródłowego w artykułach. Zaleta – posiada wsparcie dla F#, mam nadzieję, że jej działanie będzie można zobaczyć już w następnych wpisach.
• Sociable Polska Edycja – dzielenie się odnośnikami do artykułów to już praktycznie standard. Wtyczka posiada tę zaletę, że obsługuje polskie serwisy. Dodałem tylko obsługę develway.pl oraz dotnetomaniak.pl (zgłosiłem już do autora prośbę, aby je dodać w następnej wersji wtyczki) oraz zmodyfikowałem (a w zasadzie lekko doprecyzowałem) style CSS, ponieważ miałem konflikty ze stylami motywu.
• PHP Code Widget – domyślnie w WordPress jest widżet, który umożliwia osadzenie w bocznym menu dowolnego tekstu oraz kodu HTML, nie pozwala on jednak wstawić kodu PHP, a właśnie to umożliwia ta wtyczka.
• Contact Form 7 – umożliwia tworzenie formularzy w bardzo prosty sposób – ja wykorzystałem ją do zrobienia formularza kontaktowego.
• CF Internal Link Shortcode – umożliwia łatwe tworzenie odnośników do wewnętrznych stron lub artykułów.

Podejrzewam, że wiele innych odkryję jeszcze po drodze.

Podsumowanie

Prace nad postawieniem strony trwały cały weekend, podczas których nauczyłem się wielu ciekawych rzeczy. Głównymi problemami, z jakimi się trzeba zmierzyć podczas samodzielnej instalacji, to brak tłumaczeń wielu tematów i wtyczek oraz brak wsparcia dla polskich serwisów w wielu wtyczkach. Dla kogoś, kto nie czuje się swobodnie w kodzie PHP lub nie ma czasu na takie zabawy, zdecydowanie łatwiejsze będzie założenie sobie bloga w jednym z istniejących serwisów.

Od dłuższego czasu brakowało mi miejsca, w którym mógłbym gromadzić swoje notatki, przemyślenia, recenzje książek, odnośniki do prezentacji, które obejrzałem i inne tego typu materiały. Zawsze bardzo dużo i intensywnie się uczyłem, i teraz poniekąd żałuję, że tego wcześniej w żaden sposób nie dokumentowałem, bo – jak mawia mój młodszy kolega – po dziewięćdziesiątce pamięć już nie ta i sporo ciekawych rzeczy uleciało. Teraz mam nadzieję, że się to zmieni na lepsze – ten blog będzie mi służył jako zewnętrzna pamięć oraz świadek moich poszukiwań ciekawych tematów i zagadnień.

Czego będą dotyczyły wpisy?
Sam jeszcze do końca nie wiem. Zamierzam nadrobić braki w wielu nieznanych mi zupełnie lub znanych bardzo pobieżnie obszarach wiedzy – głównie z zakresu .NET, ale nie tylko – chyba już nadszedł czas, aby przyglądnąć się innym technologiom, zwłaszcza webowym. Inwestuję także swój czas w poznawanie języka F# oraz ogólnie języków funkcyjnych. Ostatnio sporo energii poświęcam również zagadnieniom architektonicznym, SOA, DDD, CQRS i innym magicznym skrótom. Odkąd zakupiłem sobie grafitowy czytnik Kindle DX 9.7”, czytam jak szalony książkę za książką, więc jest szansa na trochę subiektywnych recenzji. Mój zbiór prezentacji z różnorakich konferencji mocno się rozrósł, odsetek tych, które zdołałem już obejrzeć, jest także dosyć wysoki – postaram się więc zamieścić opisy tych, które najbardziej mi się podobały. Jestem także w trakcie pisania całkiem interesującej aplikacji, w której mam szansę powalczyć z nowymi dla mnie zagadnieniami, więc podejrzewam, że będzie to całkiem ciekawe źródło wpisów. Myślę, że sporo interesujących rzeczy pojawi się również po drodze.

Kategorie oraz tagi wyglądają na razie bardzo ubogo, ale mam nadzieję, że będzie się to zmieniać z tygodnia na tydzień.

No to startujemy…