Maciej Aniserowicz

Zawieszająca się instalacja Windows 7 i jej związek z FDD

Procent — Mon, 09 Nov 2009 17:58:00 +0100

Wielki owóż nastąpił przewrót w życiu moim zawodowym (i chyba w sumie nie tylko), gdyż wreszcie, po 4 miesiącach zwlekania, stareńkiego XP zastąpiłem nowym 7. I poszło zadziwiająco zgrabnie, 2 dni konfiguracji i prawie (...) wszystko działa tak jak chcę! Wrażeń opisywać nie będę, ponieważ pewnie większość z was i tak zdanie ma już wyrobione.

Jeśli jednak ktoś ma jeszcze przyjemność instalacji Win 6.1 przed sobą, mała porada może okazać się wielce przydatna. Kłopoty moje pojawiły się dopiero przy trzeciej instalacji, na komputerze stacjonarnym. Dwie poprzednie, na różnych wiekowo laptopach (jak upgrade to pełną gębą, w całym domu:) ), przebiegły bezproblemowo. Problem objawiał się tym, że już samym początku, przy pierwszym ekranie (przed pojawieniem się list z wyborem wersji językowej) przez ok 10 minut oglądałem piękne błękitne tło. Po wybraniu języka - to samo - przynajmniej kwadrans oczekiwania na ekranie "Starting Setup" czy coś w ten deseń. Nie wiem ile by to trwało, bo przerwałem instalację (a raczej jej zaczątek) i wybrałem się na poszukiwanie rozwiązania.

Okazało się, że ta sytuacja może mieć wiele rozwiązań. Najczęstszym tego rozwiązaniem, z tego co wyczytałem, jest to samo co zadziałało u mnie: wyłączenie w BIOSie stacji dyskietek. Chociaż nie mam jej w maszynie zainstalowanej. I pewnie właśnie jej brak powodował głupienie instalatora.

Tak czy siak po tej operacji wszystko przebiegło pomyślnie. Bezsensowna pierdoła, ale krwi potrafi napsuć.

Aha, jeśli ktoś jest niezdecydowany - to po 2-3 dniach obcowania z nowym systemem powiedzieć mogę (jak i ponad 90% ludzi którzy mieli z tym systemem styczność?): naprawdę warto. Jest po prostu fajnie.

AutoMapper, NHibernate, lazy loading oraz problem select n+1

Procent — Fri, 06 Nov 2009 06:59:00 +0100

Ostatnio pisałem o AutoMapperze, a kiedyś wcześniej o NHibernate. Dzisiaj złączę te dwa narzędzia niczym Jasia i Małgosię, Tristana i Izoldę, Lecha i Jarosława, a z ich nawzajemnego obcowania narodzi się problem, który dość łatwo przegapić.

Wróćmy do przedstawionych ostatnio, banalnych klas:

  1:  public class User
  2:  {
  3:  	public virtual int Id { get; set; }
  4:  	public virtual string Name { get; set; }
  5:  	public virtual IList<Address> Addresses { get; set; }
  6:  
  7:  	public User()
  8:  	{
  9:  		Addresses = new List<Address>();
 10:  	}
 11:  }
 12:  
 13:  public class Address
 14:  {
 15:  	public virtual int Id { get; set; }
 16:  	public virtual string Street { get; set; }
 17:  	public virtual string City { get; set; }
 18:  	public virtual string Country { get; set; }
 19:  }

Ich mapowań z wykorzystaniem Fluent NHibernate:

  1:  public class UserMap : ClassMap<User>
  2:  {
  3:  	public UserMap()
  4:  	{
  5:  		Id(x => x.Id);
  6:  		Map(x => x.Name);
  7:  		HasMany(x => x.Addresses).Inverse().Cascade.All();
  8:  	}
  9:  }
 10:  
 11:  public class AddressMap : ClassMap<Address>
 12:  {
 13:  	public AddressMap()
 14:  	{
 15:  		Id(x => x.Id);
 16:  		Map(x => x.Street);
 17:  		Map(x => x.City);
 18:  		Map(x => x.Country);
 19:  	}
 20:  }

Reprezentacji DTO:

  1:  [DataContract]
  2:  public class UserDto
  3:  {
  4:  	[DataMember]
  5:  	public int Id { get; set; }
  6:  	[DataMember]
  7:  	public string Name { get; set; }
  8:  	[DataMember]
  9:  	public AddressDto[] Addresses { get; set; }
 10:  }
 11:  
 12:  [DataContract]
 13:  public class AddressDto
 14:  {
 15:  	[DataMember]
 16:  	public int Id { get; set; }
 17:  	[DataMember]
 18:  	public string Street { get; set; }
 19:  	[DataMember]
 20:  	public string City { get; set; }
 21:  	[DataMember]
 22:  	public string Country { get; set; }
 23:  }

Oraz konfiguracji AutoMappera:

  1:  Mapper.CreateMap<User, UserDto>();
  2:  Mapper.CreateMap<Address, AddressDto>();

Raczej nic nie powinno wymagać tu wyjaśnienia (o Fluent-NH zamierzam wkrótce napisać trochę więcej).

Teraz kontekst:

Jakiś klient żąda od nas listy wszystkich użytkowników do wyświetlenia... gdzieś tam. Potrzebuje jedynie nazwy użytkownika oraz jego ID, adresy go nie obchodzą. Zadowoleni pobieramy więc samych użytkowników bez adresów:

  1:  UserDto[] dtos = null;
  2:  using (var session = AppFacade.DataAccess.OpenSession())
  3:  {
  4:  	User[] users = session.Linq<User>().ToArray();
  5:  	dtos = Mapper.Map<User[], UserDto[]>(users);
  6:  }
  7:  //...

Ależ z nas optymalizatory! Nie potrzebujemy adresów, więc ich nie pobieramy! A przecież równie dobrze mogło to dotyczyć o wiele bardziej obciążających bazę i łącze danych. Za tak wyrafinowane rozwiązanie należy nam się browar. Czy aby na pewno?

Na wszelki wypadek podejrzymy wygenerowany przez NHibernate SQL:

U’la’la. Nie dość, że pobieramy z bazy adresy, to jeszcze wpadliśmy w pułapkę "select n+1". A przecież mapowanie NH nie mówiło nic o "eager loading". Oj, nie na browar zasłużyliśmy, a co najwyżej na klapsa. I to bez niespodzianki.

Wtrącenie: w teorii powinno się mieć osobny obiekt DTO dla każdej operacji... ale często można pójść na skróty i zdefiniować jeden wykorzystywany w kilku miejscach. Moim zdaniem nie ma w tym nic szczególnie zdrożnego, należy po prostu uważać i być świadomym tego co się robi. W tym przypadku poszedłem na skróty i zdefiniowałem UserDto zamiast np. UserDto i UserWithAddressesDto.

Powód takiego a nie innego zapytania jest prosty, wystarczy lekko zmodyfikować kod aby się domyślić:

  1:  User[] users;
  2:  using (var session = AppFacade.DataAccess.OpenSession())
  3:  {
  4:  	users = session.Linq<User>().ToArray();
  5:  }
  6:  UserDto[] dtos = Mapper.Map<User[], UserDto[]>(users);

Takie coś będzie skutkowało NHibernate.LazyInitializationException w linijce 6, czyli podczas mapowania. I... prawidłowo! AutoMapper chce dobrać się do kolekcji adresów i przepisać je do DTO. NHibernate próbuje w tym momencie załadować adresy z bazy, a że jesteśmy poza sesją – wyrzuca wyjątek. Poprzednio cały czas byliśmy w obszarze aktywności sesji i adresy były leniwie pobierane dla każdego użytkownika po kolei.

Ale samo przedstawienie problemu to tylko połowa fajności pisania postów, czas na rozwiązanie.

Napisałem klasę dziedziczącą z AutoMapper.ValueResolver, która będzie próbowała dostać się do wartości źródłowej tylko i wyłącznie wtedy, gdy ta zostanie uprzednio zainicjowana przez NHibernate. W przeciwnym wypadku w miejsce docelowe wpisany zostanie null. Oto i ona:

  1:  public class NHibernateResolver : ValueResolver<object, object>
  2:  {
  3:  	protected override object ResolveCore(object source)
  4:  	{
  5:  		if (NHibernateUtil.IsInitialized(source))
  6:  			return source;
  7:  		return null;
  8:  	}
  9:  }

Oczywiście trzeba odpowiednio poinstruować AutoMappera, aby wiedział że ma z tego mechanizmu skorzystać:

  1:  Mapper.CreateMap<User, UserDto>()
  2:  	.ForMember(dest => dest.Addresses,
  3:  	opts => opts.ResolveUsing<NHibernateResolver>().FromMember(src => src.Addresses));

I wszystko jest już jak być powinno, przyjemnie i "reużywalnie":

Wygraliśmy browar!

Tip: do testowania podobnych rzeczy wykorzystuje się klasę NHibernateUtil (zastosowaną zresztą w prezentowanym rozwiązaniu).

Co to jest AutoMapper i dlaczego warto go znać

Procent — Wed, 04 Nov 2009 06:28:00 +0100

W każdej aplikacji klient-serwer następuje komunikacja. Masło maślane - gdyby nie było komunikacji, nie byłoby aplikacji klient-serwer. Pomiędzy klientem i serwerem muszą być przesyłane jakieś dane. Szymon pisał jakiś czas temu o tym dlaczego warto wyrzucić ze swojej architektury DTOs, czyli Data Transfer Objects.

Ja natomiast przedstawię pokrótce narzędzie, które pozwoli bardzo efektywnie WYKORZYSTAĆ koncept DTOs. Dane tak czy siak przesłać w jedną i drugą stronę trzeba a nie zawsze opłaca się budowanie dwóch modeli domeny jak to sugeruje Szymon.

W dalszej części posta będę posługiwał się klasami:

  1:  public class User
  2:  {
  3:  	public int Id { get; set; }
  4:  	public string FirstName { get; set; }
  5:  	public string LastName { get; set; }
  6:  	public Address Address { get; set; }
  7:  
  8:  	public void Register()
  9:  	{
 10:  		//....
 11:  	}
 12:  
 13:  	// some more domain logic...
 14:  }
 15:  
 16:  public class Address
 17:  {
 18:  	public string Street { get; set; }
 19:  	public string City { get; set; }
 20:  	public string Country { get; set; }
 21:  }

One, mimo swej karłowatej postaci, reprezentują naszą logikę wykonywaną po stronie serwera. Zakładam, że nie chcielibyśmy przesyłać ich po kablu do klientów – koniec końców klasy te mają służyć wykonywaniu operacji na danych, a nie ich prezentacji.

Do przesyłania danych posłużymy się wspomnianymi wcześniej Data Transfer Objects, czyli na przykład:

  1:  [DataContract]
  2:  public class UserDto
  3:  {
  4:  	[DataMember]
  5:  	public int Id { get; set; }
  6:  	[DataMember]
  7:  	public string FirstName { get; set; }
  8:  	[DataMember]
  9:  	public string LastName { get; set; }
 10:  }

Zauważcie atrybuty WCF – one jasno określają cel powstania tej klasy, czyli reprezentację danych gotowych do transmisji GDZIEŚ.

Przyjrzyjmy się kilku sposobom tworzenia i wypełniania takich obiektów

1. Manualne muskanie właściwości, czyli "będę doktorem"

Niczego prostszego nie da się chyba wymyślić. Z drugiej strony: ciężko również wymyślić coś bardziej errorogennego (brudne myśli na bok!) i trudniejszego w utrzymaniu.

  1:  UserDto dto = new UserDto();
  2:  dto.Id = user.Id;
  3:  dto.FirstName = user.FirstName;
  4:  dto.LastName = user.LastName;

2. Generyczny przepisywacz wartości, czyli "no place to hide"

Pewnie wielu z was zdarzyło się pisać coś takiego. Ja pisałem to przynajmniej dwukrotnie. Działać... owszem działa. W ograniczonym zakresie, ale jednak.

Wyglądać może toto mniej więcej tak:

  1:  public static void CopyPropertiesTo(this object source, object target)
  2:  {
  3:  	Type sourceType = source.GetType();
  4:  	Type targetType = target.GetType();
  5:  
  6:  	foreach (var sourceProp in sourceType.GetProperties())
  7:  	{
  8:  		var targetProp = targetType.GetProperty(sourceProp.Name);
  9:  		if (targetProp != null)
 10:  		{
 11:  			targetProp.SetValue(target, sourceProp.GetValue(source, null), null);
 12:  		}
 13:  	}
 14:  }

A korzysta się z tego tak:

  1:  UserDto dto = new UserDto();
  2:  user.CopyPropertiesTo(dto);

Zdecydowanie lepiej niż ręczne przepisywanie, ale...

Co by się stało w obu tych przypadkach, gdybyśmy chcieli dodać coś takiego:

  1:  [DataContract]
  2:  public class UserDto
  3:  {
  4:  	//...
  5:  	//...
  6:  	[DataMember]
  7:  	public string AddressStreet { get; set; }
  8:  }

Generyczny przepisywacz leży i kwiczy jak Lach na Siczy.

Natomiast w przypadku pierwszym odpowiedź jest banalna – za każdym razem, gdy zmieni się coś w DTO - idziemy do odpowiedniego miejsca i dopisujemy odpowiednie instrukcje przypisania. Tak jak małpa w ZOO regularnie łazi do wiadra w którym co jakiś czas znajduje banana.

Bycie małpą nie może być fajne (chyba że jest to evil monkey), więc zobaczmy co oferuje zapowiadany...

3. AutoMapper

Po kolei:

Najpierw definiujemy mapowania, których będziemy potrzebować (jest to krok wymagany). Robimy to raz, przy starcie aplikacji, na przykład wraz z inicjalizacją NHibernatowej SessionFactory czy ASPNETMVCowych routów:

  1:  Mapper.CreateMap<User, UserDto>();

A potem mapujemy do woli:

  1:  var dto = Mapper.Map<User, UserDto>(user);

Należy zauważyć, że AutoMapper jest "inteligentny". Przedstawiony scenariusz z AddressStreet będzie obsłużony tak jak sobie tego życzę: odpowiednia nazwa właściwości zdecyduje o tym, że pobrana zostanie wartość Street ze składowej Address. Widzicie jakie daje to możliwości rozbudowy i modyfikacji definicji DTO bez ingerencji w mapowania?

Mało tego, ta jedna definicja pozwala na mapowanie również kolekcji danych obiektów:

  1:  var dtos = Mapper.Map<User[], UserDto[]>(users);

A jeśli chcemy ręcznie ingerować w jakieś mapowanie, na przykład zawrzeć w naszym obiekcie DTO coś takiego:

  1:  [DataContract]
  2:  public class UserDto
  3:  {
  4:  	//...
  5:  	//...
  6:  	[DataMember]
  7:  	public string FullName { get; set; }
  8:  }

to oczywiście AutoMapper nam na to pozwoli:

  1:  Mapper.CreateMap<User, UserDto>()
  2:  	.ForMember(dest => dest.FullName,
  3:  	opts => opts.MapFrom(src => src.FirstName + " " + src.LastName));

A gdy dojdziemy do wniosku, że wysyłanie gdziekolwiek ID użytkowników jest złym pomysłem i nie chcemy nigdy mieć tej wartości w DTO (z jakiegokolwiek powodu, a ostatnio dwukrotnie spotkałem się z takim podejściem) - nic prostszego:

  1:  Mapper.CreateMap<User, UserDto>()
  2:  	.ForMember(dest => dest.Id, opts => opts.Ignore())

Możemy też dodać instrukcję dającą nam 100% gwarancji, że AutoMapper będzie umiał wypełnić WSZYSTKIE wartości w naszych obiektach DTO. Gdybyśmy do UserDto dodali:

  1:  [DataContract]
  2:  public class UserDto
  3:  {
  4:  	//...
  5:  	//...
  6:  	[DataMember]
  7:  	public int Age { get; set; }
  8:  }

wówczas wartość ta zawsze byłaby pusta: w końcu w User nie mamy takiej właściwości. Wystarczy jednak jedna linijka po definiowaniu całej konfiguracji:

  1:  Mapper.AssertConfigurationIsValid();

i zawsze w podobnym przypadku prosto w nasze zdziwione twarze poleci wyjątek AutoMapperConfigurationException. Warto o tym wiedzieć.

Kilka uwag końcowych:

ręczne mapowanie jest GŁUPIE
ta prosta biblioteczka może wyeliminować masę GŁUPICH czynności i GŁUPIEGO kodu
nie dajmy się ponieść; z mapowaniem jest jak ze wszystkim innym i łatwo przesadzić, w szczególności należy pamiętać, że ten mechanizm powstał po to aby mapować domenę na DTO; stosowanie takich mapowań w innych sytuacjach może świadczyć o potrzebie ponownej analizy kodu źródłowego i ewentualnych zmian w przyjętych rozwiązaniach architektonicznych (bardzo enigmatycznie brzmiące zdanie, ale wbrew pozorom ma sens:) )

Zachęcam do samodzielnego ściągnięcia tego narzędzia (jedna dllka na CodePlex) i pobawienia się nim chwilę. Nie ma tu nic szczególnie skomplikowanego, ale nie zaszkodzi również zerknąć do minidokumentacji ("General features") oraz kodu źródłowego, a w szczególności do testów jednostkowych pełniących rolę sampli.

Moje środowisko pracy z MaxiVista

Procent — Mon, 02 Nov 2009 06:29:00 +0100

Minął ponad rok od kiedy zwiększyłem swój "obszar roboczy" ponad 2x: do 19" Benq dorzuciłem 24" Hyundai. Od kiedy zmieniłem miejsce pracy na domowe zacisze krok ten doceniam oczywiście o wiele bardziej niż wcześniej, gdy w domu programowałem jedynie hobbystycznie. I któregoś pięknego dnia zapaliła się w nienasyconej głowie lampka: "a może by tak... jeszcze więcej?".

No tak, łatwo powiedzieć. Trzeci monitor to, pomijając wydatek na sam ekran, kolejna karta graficzna (lub jakiś rozgałęziacz do aktualnie posiadanej...?). A i biurko pewnie też trzeba by było powiększyć. Wszystko to wydawało się dość ryzykownym posunięciem zważywszy na to, że nie miałem wcale pewności co do powodzenia tego eksperymentu. Przeskok z jednego na dwa monitory to zdecydowanie wyborna decyzja i wiedziałem o tym już wcześniej, ale czy tak samo będzie z trzecim ekranem?

Nie budując dłużej napięcia śmiało powiedzieć mogę: WARTO! Nie jest to co prawda tak drastyczny wzrost komfortu jak przejście z 1 na 2, ale i tak "freelancuje" się o niebo lepiej. Tym bardziej, że lista narzędzi, które mam odpalone podczas normalnej pracy non stop jest dość pokaźna: wirtualka z Visual Studio & company, Management Studio ("zdalnie" podłączone do bazy na wirtualce), Total Commander, Skype, X-Lite (niezbędne do testowania tworzonego systemu), OnTime (do zarządzania projektem), Excel (do lokalnego notowania postępów prac), Operę, Outlooka i okazjonalnie Gadu-Gadu. I zdarza się, że z wszystkiego tego korzystam jednocześnie – a wtedy i 5 monitorów nie byłoby wystarczające.

Ale do rzeczy... Nie, nie kupiłem zestawu karta graficzna + monitor + biurko. Aktualnie moje środowisko pracy wygląda tak:

Gdzie:

tutaj operuję na systemie hosta korzystając z aplikacji "pobocznych (Opera, Outlook, Skype etc..)"
to głównie ten pan kradnie mi dioptrię po dioptrii zawierając wirtualkę z projektem, nad którym aktualnie pracuję
nie nauczyłem się jeszcze w pełni efektywnie korzystać z trzeciego monitora, więc póki co jest to śmietnik na który wrzucam wszystko co powinno być na wierzchu, ale nie wymaga ciągłej obserwacji

Ale po co o tym piszę? Przecież nie żeby pochwalić się zdolnością gapienia się w trzy ekrany jednocześnie. Celem niniejszego posta jest przedstawienie niesamowitego kawałka softu: MaxiVista.

Jak można zauważyć mój trzeci ekran to nie dodatkowy monitor, a najzwyklejszy laptop. Tak jest: osobny komputer pełni rolę kolejnego powiększenia obszaru roboczego mojego pulpitu, pozwalającego na interakcję z programami działającymi na moim GŁÓWNYM sprzęcie. I pisząc NAJZWYKLEJSZY mam dokładnie to na myśli – może to być autentycznie COKOLWIEK z wifi lub dziurą na kabel sieciowy. Aktualnie w tym miejscu stoi 4 czy 5-letni Asus A6U, który nie powala możliwościami, ale dla MaxiVista to i tak za dużo! Z ciekawości przetestowałem ten program na stareńkiej Toshibie (10 lat?) z zainstalowanym Win98 (bo niczego nowszego nie "udźwignie") i... działa jak marzenie! Nieważne, że w środku komputera siedzi sprzęt warty 15zł. Ważne, że ma ekran i da się to coś podłączyć do sieci.

Może brzmię jak Klaudiusz z BigBradera reklamujący samoprasujące się gacie w TVSzopie, ale to jest naprawdę coś wartego uwagi. Minimalnym kosztem (najtańszy sprzęt + kilkadziesiąt $ za MaxiVista) możemy rozszerzyć środowisko pracy do tak wielkiej przestrzeni, że aż do przesady – bo program umożliwia podłączenie więcej niż jednego dodatkowego komputera! Ale chyba jeszcze nie dojrzałem do sprawdzenia jak to jest z 4 ekranami :) (ale spokojnie, mam czas... Jenna Jameson pewnie też nie od pierwszego dnia kariery wskoczyła w sam środek orgii).

Oprócz opisanego rozszerzenia pulpitu na inne komputery program zawiera dodatkowo o wiele więcej feature’ów. Nie bawiłem się jednak nimi, póki co jestem w trakcie "nacieszania się" tym jednym. A jeżeli w twoim domu wala się gdzieś jakiś zapomniany laptop, który w dzisiejszych czasach nie nadaje się już do niczego... ściągnij demko i przekonaj się sam, że nawet najstarszy trup może się jeszcze do czegoś przydać!

Niechaj NIESKOŃCZONA ROZDZIELCZOŚĆ ma was w swojej opiece, idźcie w pokoju.

P.S. Polecam dorzucić do tego darmowe narzędzie Winsplit Revolution – jest na tyle fajne, że może kiedyś doczeka się własnego posta?

PrincipalMock

Procent — Fri, 30 Oct 2009 09:01:00 +0100

Podczas pisania testów jednostkowych możemy natknąć się na problem uprawnień – co jeśli testowana metoda wymaga, aby użytkownik był zalogowany, miał określoną nazwę bądź był przypisany do konkretnej roli? Nie chcemy przecież, aby testy jednostkowe w jakiś sposób logowały się do naszej aplikacji. Rozwiązaniem jest pomocnicza klasa, którą napisałem z wykorzystaniem frameworka Moq:

  1:  public static class PrincipalMock
  2:  {
  3:  	public static IPrincipal Create(string name, params string[] roles)
  4:  	{
  5:  		var identity = new Mock<IIdentity>();
  6:  		identity.Setup(x => x.Name).Returns(name);
  7:  		identity.Setup(x => x.IsAuthenticated).Returns(!string.IsNullOrEmpty(name));
  8:  
  9:  		var principal = new Mock<IPrincipal>();
 10:  		principal.Setup(x => x.Identity).Returns(identity.Object);
 11:  		roles.ToList().ForEach(role => principal.Setup(x => x.IsInRole(role)).Returns(true));
 12:  
 13:  		return principal.Object;
 14:  	}
 15:  }

Jej wykorzystanie, na przykład w metodzie z atrybutem SetUp (w przypadku nUnit) wykonywanej przed każdym testem:

  1:  Thread.CurrentPrincipal = PrincipalMock.Create("username", "role1", "role2");

Zawód - programista. RAK kreatywności i satysfakcji.

Procent — Wed, 28 Oct 2009 08:23:00 +0100

Wielokrotnie zdarzało mi się, że budziłem się rano i na samą myśl o kolejnym dniu w pracy robiło mi się niedobrze. Czy też tak czasami macie? Pomimo całej świetności naszego zawodu, ogromnej gamy wyzwań i oczekujących na rozwiązanie pasjonujących problemów, bycie programistą może czasami dać się nieźle we znaki.

Post ten jest kierowany nie tyle do samych developerów, co do ludzi o "jeden stopień wyżej". Menadżerów? Team leaderów? Architektów? Zwał jak zwał. Poniżej zebrałem kilka rzeczy, którymi możecie naprawdę uprzykrzyć życie swoim "podwładnym" i z potencjalnie bardzo wartościowych członków zespołu uczynić bezmyślne małpy czekające na godzinę 16.00, aby zmyć się jak najprędzej do domu.

Bierz kasę, o nic nie pytaj, nic nie rób, czekaj na zadanie.

Zdarzyło mi się kiedyś pracować w firmie, w której nie musiałem robić NIC. Autentycznie! Przychodziłem do pracy i przez 8 godzin czytałem książki, oglądałem filmy, układałem pasjansa. Wszystko to w oczekiwaniu na COKOLWIEK do roboty. Wydawać się może: praca – marzenie? Nic bardziej mylnego! Mogę z czystym sumieniem powiedzieć, że była to najbardziej męcząca praca w moim życiu – a robiłem wiele rzeczy, w tym np. malowanie balkonów w USA jako zwykły "robol ze wschodu". Nie dość, że najbardziej męcząca, to jeszcze najbardziej irytująca. Chodziłem cały czas wściekły: czy po to studiowałem? czy po to uczyłem się na własną rękę? czy po to zdobywałem certyfikat, zarywałem noce, rezygnowałem z uciech studenckiego życia?

Oczywiście jakąś część tego czasu wykorzystałem niezwykle produktywnie: ile blogów się wtedy naczytałem, ile teorii wchłonąłem, ile rozwiązań mogłem "testowo" zaimplementować! Ale... co z tego? Z czasem przyszło zwykłe otępienie. Jaki jest tego cel? Kiedy mi się to przyda? Odpowiedź wydawała się banalnie prosta: NIGDY! Wysłany czasami bez sensu na spotkanie, o którego temacie nie miałem zielonego pojęcia, czy przydzielony do głupiego zadania które mógłby wykonać licealista z klasy humanistycznej, jedyne co mogłem zrobić to zżymać się w duchu i raz po raz narzekać: "CO JA TU ROBIĘ??". Szedłem do pracy, inkasowałem pensję, układałem pasjansa, czekałem na koniec dnia, szedłem do pracy, układałem pasjansa...

Aż mi teraz wstyd, że tyle czasu zmarnowałem na tego durnego pasjansa. Ale na swoje usprawiedliwienie powiedzieć mogę, że mniej zmotywowany do CZEGOKOLWIEK nie byłem ani nigdy wcześniej, ani nigdy później. Skończyło się oczywiście na rzuceniu papierami i auto-zwolnieniu, ale tych zmarnotrawionych godzin już nikt mi nie zwróci.

Kierowniku: przed zatrudnieniem programisty zastanów się, czy naprawdę go potrzebujesz.

Tutaj masz opis tego CO trzeba zrobić. A tutaj: dokładny opis JAK to zrobić. Mózg: OFF i do roboty!

Czy zdarzało wam się dostać do wykonania jakieś zadanie wraz z dokładnymi instrukcjami dotyczącymi implementacji? Nie chodzi mi o wskazówki typu "nie zajmowałeś się tym wcześniej, więc zajrzyj na taką i taką stronę, przeczytaj ten i ten artykuł", a o polecenie "zrób to dokładnie TAK!". W przypadkach ekstremalnych: "masz tu kod, który kiedyś napisałem i dopasuj go do aktualnego projektu". Za każdym razem, gdy miałem do czynienia z czymś podobnym, wyła we mnie z upokorzenia istota rozumna. Czy JA nie potrafię tego zrobić? Czy TY uważasz, że programista to namiastka xero, który zmieni nazwy zmiennych tak aby wszystko się kompilowało i tyle? Potencjalnie interesujące wyzwania mogą zostać w ten sposób całkowicie zmarnowane. Bezrozumne postępowanie zgodnie z wytycznymi krok po kroku nie może skończyć się dobrze. Normalne chyba jest, że programista w takiej sytuacji "weźmie co dane", wrzuci do projektu i basta. Zapędzony do roli pani piszącej na maszynie nie będzie wnikał czy każdy krok jest właściwy. "Consider it done!" i już. Nie chodzi o dokładną specyfikację, bo ta jest oczywiście jak najbardziej mile widziana – a o niskopoziomowe wytyczne dotyczące samego procesu tworzenia kodu.

A jeśli się okaże, że coś nie działa jak trzeba, że gdzieś kryje się błąd... czyja będzie wina i kto spędzi pół dnia w debuggerze...?

Oczywiście, czas może naglić. Nie można wynajdować koła od nowa po raz n-ty. Trzeba dzielić się wiedzą i doświadczeniem. Ale: z umiarem! Każdy ma prawo do chwili satysfakcji i zrobienia czegoś fajnego.

Wiem, że kiedyś sam popełniałem ten błąd i sam w taki sposób przydzielałem zadania. "Za wszystkie serdecznie żałuję".

Kierowniku: nie traktuj programisty jak debila - daj mu się wykazać. Nie tylko ty masz prawo do czerpania przyjemności z kodowania.

Czy ktoś ma inną propozycję? OK. A teraz robimy po mojemu.

Czy możecie wymyślić coś bardziej uwłaczającego niż zostanie poproszonym o wyrażenie swojego zdania, które następnie jest całkowicie olane? Pewnie tak. Ale uczucie towarzyszące przytoczonemu zjawisku również jest nie do pozazdroszczenia. Z zapałem zabierasz się do wymyślenia ciekawego rozwiązania, potencjalnie LEPSZEGO niż to zaproponowane przez "górę". Dumny z siebie prezentujesz efekt pracy (często wykonanej po godzinach, bo w firmie trzeba przecież KODOWAĆ) i czekasz na odrobinę uznania. Jeśli nie uznania, to dyskusji. Jeśli nie dyskusji, to wytknięcia błędów. Jeśli nie wytknięcia błędów, to choćby zauważenia włożonego wysiłku. A jedyne co słyszysz to: "ok, a teraz robimy po mojemu".

Krew człowieka zalewa.

Kierowniku: bądź otwarty na alternatywy; twoi podwładni mogą mieć dobre pomysły, czasami nawet lepsze od twoich. A jeśli są gorsze to wytłumacz dokładnie dlaczego, dzięki temu ich praca nie pójdzie na marne.

Płacimy ci za kodowanie. Więc KODUJ!

Przychodzisz do biura, odpalasz ulubionego bloga - może pojawiło się coś nowego? Może na jednym z obserwowanych portali umieszczono artykuł, który przedstawi techniki pozwalające na wydajniejszą, lepszą pracę?

A tu nagle, niczym siarkowy podmuch z piekielnych otchłani, mroczny szept z tyłu: "czy nie masz przypadkiem kodu do napisania?". O nie, znowu mnie przyłapali!

I cały misterny plan w p... Nieważne co robisz – ważne, abyś miał Visual Studio na monitorze.

Czy to jest naprawdę wyznacznik wydajności i efektywności: stosunek czasu w którym VS ma focus do czasu spędzonego w pracy? Czy programista robi tylko to: programuje? Nie mówię o całodziennym śmiganiu po internecie i olewaniu zadań, bo oczywistym jest, że nie po to zatrudnia się developera. Ale czy kilka minut dziennie poświęconych na edukację, zorientowanie się w trendach i newsach, poszerzenie horyzontów jest takim marnowaniem czasu, że trzeba je tępić? Ja na ten przykład byłbym wniebowzięty, gdyby mój zespół był zainteresowany czymś więcej niż tylko zalepieniem zgłoszonych bugów czy dodaniem do rozwijanego projektu nowych funkcjonalności. Gdyby ludzie z własnej woli chcieli rozwijać swoje umiejętności, z dnia na dzień uczyć się czegoś nowego, stawać się coraz lepszymi w swoim fachu.

Kierowniku: promuj otwarcie, zaangażowanie i aktywność. Zwalczaj bierność i marazm.

Nowe podejście do problemu? A kim ty jesteś, aby podważać aktualną strategię?

Czujesz, że praca nad projektem nie jest tak efektywna jak mogłaby być. Proponujesz: "może zastanowimy się nad zastąpieniem ręcznego klepania procedur jakimś ORMem?". Albo: "nasz system przydzielania zadań bardzo spowalnia pracę, może warto zastanowić się nad alternatywą?". Albo: "mam doświadczenie z innymi systemami kontroli wersji niż SourceSafe, może chcesz żebym pokazał ci o ile lepszy jest Subversion czy Git?". Albo: "niektóre miejsca tego projektu naprawdę warto pokryć testami jednostkowymi".

A słyszysz wymowne i bezpardonowe: "to nie twoja działka".

Czy po kilku takich próbach nadal masz chęć udzielania się w jakikolwiek sposób, szukania lepszych rozwiązań, usprawniania pracy nad projektem? Wątpię.

Kierowniku: nie ukręcaj łba wszystkim propozycjom, które wychodzą "z dołu". Korzystaj z doświadczenia swojego zespołu.

Pewnie dałoby się takich scenariuszy opisać o wiele więcej. Pewnie mieliście do czynienia i z wymienionymi, i z innymi (jakimi? czekam na feedback). Pewnie każdy z nas w ten czy inny sposób został kiedyś stłamszony, "doprowadzony do porządku", każdemu z nas zostało pokazane jego miejsce... zgarbiony ludek nad klawiaturą.

Przedstawione sytuacje pochodzą z różnych źródeł: część z nich z własnego doświadczenia, część z opowieści. Jedną cechę mają wspólną: wszystkie są (o zgrozo!) autentyczne. Nie wiem jak idealnie powinno się prowadzić zespół programistów (póki co – nie muszę tego wiedzieć), ale... wiem, jak zdecydowanie NIE POWINNO się tego robić.

Rada na koniec: choćby spotkało cię to wszystko, nawet wszystko naraz jednego dnia: nie poddawaj się! Sam wielokrotnie zadawałem sobie pytanie: czy na tym właśnie polega zawód programisty? Czy nadzieje z nim związane pozostaną na zawsze tylko naiwnymi wyobrażeniami niemającymi nic wspólnego z rzeczywistością? A jednak... z czasem wszystko się układa – tyle że nie samo z siebie. Więc "szukajcie aż znajdziecie" i nie bójcie się zmian. Na marnowanie czasu w niewłaściwym miejscu po prostu szkoda życia programisty.

P.S. Ostatnio dostałem od ziomka ciekawy link: Grunt Programmer. Definicja:

victim of being treated as a Grunt Programmer is only allowed to write code; they're not allowed to think about design or user requirements -- that's someone else's job

Jeśli jesteś zaszufladkowany jako Grunt Programmer: zbierz się w sobie i zmień to. Za zakrętem naprawdę czeka coś o wiele lepszego!

Jak nie pisać testów jednostkowych

Procent — Mon, 26 Oct 2009 07:31:00 +0100

Testy jednostkowe pełnią dwie bardzo ważne role:

poprawiają design aplikacji
sprawdzają czy kod jest poprawny

Drugi aspekt można rozumieć dwojako... Spójrzmy na przykładową metodę kalkulatora:

  1:  public class Calculator
  2:  {
  3:  	public int Add(int first, int second)
  4:  	{
  5:  		return first + second;
  6:  	}
  7:  
  8:  	// more operations...
  9:  }

Jej przetestowanie nie powinno sprawiać nikomu problemu. Ale... czy na pewno?

Jestem przekonany, że jeszcze jakiś czas temu sam napisałbym test w taki sposób:

  1:  [Test]
  2:  public void Add_ReturnsSum()
  3:  {
  4:  	int firstArgument = 2;
  5:  	int secondArgument = 3;
  6:  
  7:  	int result = new Calculator().Add(firstArgument, secondArgument);
  8:  
  9:  	Assert.AreEqual(2 + 3, result);
 10:  }

Co nam testuje taki test? Ano to, czy kod w teście i metodzie testowanej jest taki sam. Bez sensu. Przy prostym dodawaniu wygląda to oczywiście banalnie i niewinnie, ale co w przypadku skomplikowanych algorytmów? Idąc tą drogą możemy bardzo łatwo wpaść w pułapkę kopiuj/wklej polegającą na bezmyślnym kodowaniu dwukrotnie tego samego – przyznam się, że ja kiedyś wpadłem. Czy test, który właśnie napisaliśmy, sprawdza poprawność wyniku zwracanego przez metodę Add()? Nie, on sprawdza czy wykonywane są te same operacje. Test ten powinien wyglądać tak:

  1:  [Test]
  2:  public void Add_ReturnsSum()
  3:  {
  4:  	int firstArgument = 2;
  5:  	int secondArgument = 3;
  6:  	int expectedResult = 5;
  7:  
  8:  	int result = new Calculator().Add(firstArgument, secondArgument);
  9:  
 10:  	Assert.AreEqual(expectedResult, result);
 11:  }

Czyli: dla danych argumentów metoda powinna zwrócić taki a nie inny wynik, obliczony przez nas niezależnie od samego programu. SPOSÓB obliczania tego wyniku nie powinien być przedmiotem badanym przez ten test jednostkowy.

Ciekawostka: na tej zasadzie działa PEX: generuje argumenty metody i zwracane przez nią wyniki, gdy jest wywołana z tymi argumentami.

NHibernate – jak zacząć?

Procent — Fri, 23 Oct 2009 06:29:00 +0100

Ostatnio miałem kolejne podejście do NHibernate. Tym razem zdecydowanie udane. W ciągu minionych kilku tygodni trzykrotnie prowadziłem też w "swoim środowisku" rozmowę na temat taki jak w poście – jak zacząć przygodę z NHibernate? Postanowiłem więc, że warto efekt takiej rozmowy opublikować szerszemu gronu.

1. Spróbuj

Stwierdzenie pierwsze: jeżeli kiedyś odbiłeś się od NH, jeżeli odrzucało cię XML-hell, jeżeli nienaturalny wydawał ci się sposób budowania zapytań, jeżeli nie łapałeś "o co chodzi" i dlaczego warto poświęcić trochę czasu na naukę NH – wiele z tego zmieniło się podczas ostatnich miesięcy. Zapomnij o niemiłych wspomnieniach i zacznij od zera, daj sobie i NH drugą szansę – będziesz naprawdę pozytywnie zaskoczony. Provider LINQ i mapowanie w C# to projekty, dzięki którym wg mnie NH dostało wielkiego pozytywnego kopa w kategorii "developer-friendly".

2. Co wrzucić do referencji?

Na samym początku pojawia się dylemat: no dobra, ale co tak naprawdę muszę ściągnąć, co dodać do referencji żeby zacząć zabawę? Odpowiedzi poniżej:

NHibernate w wersji 2.1: NHibernate-2.1.0.GA-bin.zip; plik zawiera instrukcje txt odnośnie tego co trzeba dołączyć do projektu, ale dla leniwych: do referencji trzeba dodać NHibernate.dll oraz jedną z bibliotek umożliwiających "lazy loading", twórcy NH założyli w domyślnej konfiguracji że użytkownik doda NHibernate.ByteCode.Castle.dll i nie widzę powodu aby robić inaczej
provider Linq 2 NHibernate w wersji 1.0: NHibernate.Linq-1.0.0.GA-bin.zip; tu z referencjami nie powinno być problemu gdyż całość to jedna dll :)
projekt Fluent NHibernate pozwalający na mapowanie w C#, mega-wypas: Fluent NHibernate 1.0RTM; referencja do FluentNHibernate.dll

3. Skąd czerpać wiedzę?

Często spotykam skargi, że o NHibernate jest materiałów jak na lekarstwo... Szczerze mówiąc to tego lekarstwa można by wyprodukować całkiem sporo. Kilka linków:

po pierwsze: oficjalna strona NHibernate to http://nhforge.org/, a nie pierwszy wynik z Google czyli https://www.hibernate.org/343.html; to faktycznie KIEDYŚ było oficjalne gniazdo NH, ale już nie jest
dokumentacja na oficjalnej stronie: http://nhforge.org/doc/nh/en/index.html, jest to właściwie cała książka i po prostu KOPALNIA wiedzy o NH; lektura obowiązkowa dla każdego nowicjusza, najlepiej od deski do deski; nie ma tam co prawda wzmianki o fluent-nh czy linq nh, bo projekty te powstały po napisaniu doca, ale i tak zawarte tam informacje po prostu TRZEBA znać
blog Ayende Rahien, jednego z głównych rozwijaczy NH (cały blog jest godny polecenia, ale w aktualnie omawianym kontekście: szczególnie wpisy traktujące o NHibernate)
cykl wpisów zatytułowanych The NHibernate FAQ – można to określić jako "demonstracja NH w praktyce z TDD"
oficjalna strona projektu Fluent NHibernate – tworzenie pierwszych najprostszych mapowań krok po kroku; zakres materiału dość niewielki, ale na początek bardzo przydatny
może to zabrzmi banalnie, ale... wujek Google posiada odpowiedzi na naprawdę masę pytań, chociaż często trzeba poszukać dokładnej niż jesteśmy do tego przyzwyczajeni; aha, polecam na koniec pytania doklejać instrukcję "-hibernate" co odfiltruje dyskusje dotyczące dżawowego pierwowzoru NH

UPDATE (26.10.2009): na blogu Ayende pojawiła się informacja, że wraz z Robem Conery rozpoczął publikowanie webcastów o NHibernate. Nic tylko oglądać! LINK

4. Po co?

To pytanie jest niczym zlepek słów: "Co robisz, Szczepanie?"; zawiera pytanie i odpowiedź jednocześnie. Zostawiam was z tym rebusem:).

Z pewnością nie jest to mój ostatni wpis dotyczący NHibernate i Fluent NHibernate. Kilkukrotnie straciłem dobre kilka godzin próbując zrobić coś, co okazywało się banalne. Innymi razy nad ranem docierało do mnie, że podchodzę do problemu z całkowicie złej strony. W jeszcze innych sytuacjach odpowiedzi w Google naprawdę nie było i jedynie zerknięcie w źródła Fluent NH i ich testy jednostkowe okazywało się ostatnią deską ratunku. Tak więc do następnego razu, a póki co – gorąco radzę zaprzyjaźnić się z NHibernate, choćby hobbystyczne, dla własnej satysfakcji.

Jestem DEMONEM! by procentd

Procent — Sat, 10 Oct 2009 13:44:00 +0100

Ależ chwytny tytuł! I groźny. Ale zobaczmy:

demon (za Wikipedią) - proces, który pracuje w tle bez konieczności interakcji z użytkownikiem

Mniej więcej tak można określić moją egzystencję przez kilka ostatnich (i jeden przyszły) tygodni. Siedzę sobie w tle otoczony przez monitory i jedyną słuszną muzykę, pracuję, i wszelką interakcję z kimkolwiek ograniczam do minimum :). Nie będzie ogromną przesadą jeśli zasymyluję to małym kawałkiem kodu:

  1:  Procent me = Procent.Instance;
  2:  me.LifeMode = LifeMode.CrazyDeveloper;
  3:  
  4:  while(true)
  5:  {
  6:  	me.Swim();
  7:  	me.WriteSoftware();
  8:  	me.Sleep(TimeSpan.FromHours(4.5));
  9:  }

Ale... tak to jest, gdy pracuje się nad dwoma całkowicie różnymi projektami jednocześnie i żadnego nie traktuje jako "tego drugiego, mniej ważnego". Szczerze mówiąc decydując się na realizację równolegle dwóch projektów obawiałem się trochę powrotu do takiego trybu życia - mimo że jedynie na czas niedługi i ściśle określony. Byłem jednak ciekaw jak to będzie... Wspomnienia z ostatniego roku studiów, gdy trzeba było pisać magisterkę ORAZ tworzyć ITCore ORAZ jeszcze startować w Imagine Cup, są niezapomniane. Ale czy po ponad dwuletniej przerwie będę w stanie pobawić się w czasy, kiedy szalone programowanie przez 30 godzin non-stop nie było niczym szczególnie nadzwyczajnym? Nie to żebym był stary, ale... czy będzie się chciało?

Przyjmując drugi projekt postanowiłem, że sam siebie sprawdzę. Czy to całe moje gadanie o pasji, o poświęceniu, o pracy nad sobą i ciągłym rozwoju ma w ogóle jeszcze jakieś podstawy? I powiedzieć muszę, że jestem niesamowicie zadowolony. Okazało się, że mam jeszcze tą ISKRĘ (nie mylić z ikrą) i – mówiąc wprost – daję radę. Dawno nie czułem pełni radości płynącej z programowania i zaczynałem zapominać jak to jest. A teraz, mimo tego że zmęczenie daje się we znaki i powoli wyglądam końca krótszego projektu, znowu czuję się spełniony. Nie gryzie mnie już okropnie nieprzyjemny sumienia wyrzut "robisz ZA MAŁO!", jak miało to miejsce bardzo często przez minione kilkanaście miesięcy. Przypomniałem też sobie, z czego się bardzo cieszę, jak wiele można się nauczyć przez kilka tygodni ciężkiej pracy.

Stąd też między innymi brak ciekawej aktywności na blogu ostatnimi czasy. Ale już wkrótce się to zmieni. Jako zachętę rzucę kilka tematów, które pojawiły się na mojej liście "to blog about", więc nie usuwajcie mnie jeszcze z RSSów i ulubionych – ja żyję ;). W różnej kolejności i z różną intensywnością będę pisał między innymi o:

WCF – kilka sztuczek, kilka porad, kilka mechanizmów, które wydają się banalne, a nad którymi można spędzić dobre 2-3 noce zanim zaczną działać tak jak się tego oczekuje
NHibernate – w połączeniu z NHLinq, Fluent NHibernate, SQLite
testy jednostkowe – znowu trochę o mockach, trochę o NH, oraz o testowaniu "the BDD-way" ze SpecUnit (i dlaczego to jest fajne)
kontrola wersji – dlaczego SVN mnie dobija (czasami autentycznie dostaję przez niego szału, co objawia sie wykrzykiwaniem wulgaryzmów i uderzaniem w otaczające mnie przedmioty), dlaczego Git rozwiązuje stwarzane przez niego problemy, ale jednocześnie dlaczego nie przenoszę się na Gita w 100%

To oczywiście nie wszystko, ale tak czy siak pomysłów na posty więcej niż czasu na ich napisanie. Czyli jak zwykle. Czyli tak jak być powinno.

Dość weekendowych zwierzeń. Stay tuned.

Relacja z MTS 2009

Procent — Fri, 02 Oct 2009 01:12:00 +0100

29 i 30 września 2009 to dni spędzone w Pałacu imienia Józefa Stalina na konferencji Microsoft Technology Summit 2009. Tak jak rok temu postaram się przedstawić swoje wrażenia, więc zainteresowanych zapraszam do lektury a innych uczestników do dodawania swoich opinii w komentarzach.

Słowem wstępu...

Start rejestracji na konferencję niestety przegapiłem, ponieważ pomykałem wówczas po europejskich autostradach w ramach urlopowania się i harmonogram mogłem ułożyć dopiero po kilku dniach. Wszystkie najlepsze miejsca były więc już "rozebrane". Na szczęście jednak udało mi się wejść wszędzie tam gdzie chciałem, a nie tam gdzie byłem zapisany, i mogę się podzielić wrażeniami z tych najciekawszych sesji.

Ale wracając do samej rejestracji: przyznać muszę, że spoglądając na komplet oferowanych prelekcji byłem zawiedziony. Rok temu każdy "sesyjny slot" zawierał jakiś hit, który bardzo chciałem zobaczyć, a tym razem... Niestety tylko pięć lub sześć wystąpień faktycznie przykuło moją uwagę, a pozostałe to raczej wybór z przymusu niż autentyczne zainteresowanie tematem. Nie tego się spodziewałem, więc pierwsze "odczucia konferencyjne" – raczej negatywne.

Czas jednak i na pochwałę. Po wejściu do Pałacu Kultury przeżyłem mały szok. Nie wiem jak to możliwe, ale w jakiś magiczny sposób uniknięto organizacyjnego koszmaru sprzed roku. Wydawało się, jakby tym razem do PKiN zawitała zaledwie połowa uczestników. Nie potrafię dokładnie opisać czym to się objawiało, ale po prostu nie czuło się ścisku, tłoku i atmosfery spędu bydła. Chwała organizatorom za to, brawo!

I mała uwaga: nie robiłem notatek (w niektórych salach było ciemno, w innych siedziałem na podłodze), a ze strony konferencji nie można jeszcze ściągnąć prezentacji. Potocznie zatem mówiąc, jadę z pamięci.

0. Sesja generalna

Sam początek konferencji standardowo odbył się w Sali Kongresowej. Spodziewałem się drętwego spektaklu przepełnionego marketingowym bełkotem, a po wejściu zastałem na scenie zespół grający na żywo kawałki U2! Super pomysł na stworzenie luźnej atmosfery i rozpoczęcie takiego wydarzenia.

Po kilku utworach miejsce zespołu zajęli już po kolei "wysłannicy korporacji" przedstawiający nam różne treści. Zaczęło się od kilku zdań na temat kryzysu i sposobu Microsoft na walkę z nim (inwestycje w rozwój i badania przy jednoczesnym cięciu "kosztów operacyjnych"), następnie pokrótce przedstawiono plany firmy na najbliższe jak i dalsze lata. Plany na lata najbliższe chyba wszyscy znaliśmy i to te dalsze perspektywy głównie przykuwały uwagę. Trzeba przyznać, że wizja roku 2019 robiła niezłe wrażenie. Pokazany filmik wyglądał jak kawałek produkcji science-fiction, a zapewniono nas że prezentowane tam rozwiązania autentycznie istnieją w laboratoriach MS. Fajnie, zapowiada się ciekawa dekada:). Zainteresowanych odsyłam tutaj, gdzie można wspomniany filmik obejrzeć. Chociaż i już istniejący "futurystyczny" produkt, czyli Surface, prezentuje się niesamowicie imponująco, co mogliśmy zobaczyć na własne oczy.

Sesja generalna zdecydowanie bardziej ciekawa niż ta sprzed roku i właściwie tylko do jednego elementu można się przyczepić... Pokaz Windows 7 był po prostu żałosny. Ja osobiście wolałbym już jakiś fajny filmik niż drętwy "biurowy kabaret" z czerstwymi dialogami. I z tego co wiem, nie tylko ja. Ale to w sumie nieważne, bo i tak było lepiej niż wszyscy się spodziewali.

Mała dygresja: czy Microsoft mówiąc o Bing naprawdę nie zdaje sobie sprawy, że silnik ten nie dorasta jeszcze guglowi do pięt, czy tylko udają? :)

1. "Silverlight – przyszłość aplikacji biznesowych" Jakub Jałbrzykowski

Po tym dość pozytywnym zaskoczeniu nadszedł czas na najbardziej oczekiwany przeze mnie element konferencji. JJ wygrał rok temu konkurs Speaker Idol, dzięki czemu tym razem występował jako pełnoprawny prelegent z pełnowymiarową sesją… no i oczywiście byłem bardzo ciekaw jak mu się powiedzie. Dodatkowy czynnik podsycający atmosferę oczekiwania to mój obowiązek rzetelnego zrelacjonowania jego wystąpienia. Istniało pewne prawdopodobieństwo większe od zera, że sesja będzie do bani... A wtedy moja surowa ocena (a zdarzały się takie przy okazji moich relacji różnych sesji różnych prelegentów na różnych konferencjach) mogłaby na długo utkwić w naszej znajomości niczym gorzka drzazga niezgody. Na szczęście jednak aktualny stan rzeczy nie musi ulegać zmianie, gdyż nic takiego miejsca nie miało.

Ale dość prywaty, która nikogo nie obchodzi. Temat sesji i poziom 400 mogły nastawiać bardzo optymistycznie. Z Silverlight nie miałem póki co zbyt wiele do czynienia, ale z aplikacjami biznesowymi (cokolwiek przez to rozumieć) jak najbardziej. Spodziewałem się skupienia na pierwszej części tytułu, czyli fajerwerków oferowanych przez SL wraz z demonstracją "jak prosto się to robi". Pozytywnie się jednak zaskoczyłem, gdyż przez większość czasu Kuba skupiał się na aspekcie projektowania aplikacji i stosowania dobrych praktyk podczas tego procesu. Silverlight został przedstawiony mniej jako framework do tworzenia ładnych interfejsów a bardziej jako narzędzie, które umożliwia budowanie rozbudowanych aplikacji internetowych z wykorzystaniem jednej technologii (.NET) po obu stronach kabla, bez babrania się w HTML, JavaScript czy CSS. W takiej sytuacji nie mogło oczywiście zabraknąć wielu odniesień do Prisma, omówienia wzorca Model-View-ViewModel i zaprezentowania jakże użytecznej koncepcji Event Aggregatora. Mieliśmy również okazję wysłuchać osobistych refleksji prelegenta i jego doświadczeń z takimi pojęciami jak RIA Services czy dwustronną komunikacją klient-serwer-klient. Jak dorzucimy do tego wszystkiego kilka zabawnych dowcipów, masę demek, autentycznie przydatne przykłady i super pomysł z własnoręcznym stworzeniem całej grafiki do prezentacji (koślawe leworęczne rysunki rulezzz), to mamy sesję jakiej można oczekiwać po tak wielkiej konferencji.

Jeśli miałbym się do czegoś przyczepić... materiału było trochę za dużo jak na 80 minut. Poziom sesji został co prawda określony na 400, ale dorzucanie do tego wszystkiego JESZCZE Aspect Oriented Programming wraz z Post# to lekkie przegięcie. Zresztą na szersze omówienie tego ostatniego tematu zabrakło czasu.

Nie zgodziłbym się również z krótką wypowiedzią na temat JavaScript – moim zdaniem skreślanie i unikanie tego języka najczęściej spowodowane jest niezrozumieniem zasad panujących w świecie dynamicznego programowania i przy odpowiedniej edukacji prowadzącej do umiejętnego zastosowania całej jego potęgi JavaScript naprawdę daje się lubić.

Dodatkowo na slajdzie z wadami Silverlight zabrakło mi bardzo ważnego punktu wskazującego na niedoskonałe działanie SL w niektórych przeglądarkach (vide moja kochana Opera) oraz brak wsparcia dla systemów operacyjnych innych niż Windows. Co prawda wybierając technologię Microsoftu można się domyślać takich wad, ale ich jasne wskazanie moim zdaniem by się przydało. Tym bardziej, że konkurencyjne Flash i Adobe Air nie mają podobnych problemów.

Na koniec ciekawostka – była to podobno najbardziej oblegana sesja na całej konferencji. Nice...

Na koniec po końcu: Kuba prosił mnie o zamieszczenie prezentacji i demonstracji więc oto one: Jakub Jalbrzykowski - Silverlight - Przyszłosc aplikacji biznesowych.zip.

Ocena: 8/9 (za kawał porządnej roboty i sprawdzenie się w odpowiedzialnej roli prelegenta, który – o czym jestem przekonany – będzie od teraz jedną z głównych twarzy polskich konferencji poświęconych technologiom Microsoft)

2. "Nadciąga Azure - prawdziwa burza czy tylko lekkie zachmurzenie?" Daniel Celeda

Wstyd przyznać, ale słowo "Azure" kojarzyło mi się wcześniej jedynie z rysunkiem chmurki. Na sesję szedłem nie mając właściwie pojęcia co mogę usłyszeć, nie wiedziałem czego się spodziewać, nie zgadywałem nawet o czym tak naprawdę prelegent będzie opowiadał. Już na pierwszym slajdzie okazało sie, że bardzo dobrze trafiłem, gdyż docelowym słuchaczem miał być programista niemający zielonego pojęcia o Windows Azure. "OTO JESTEM", pomyślałem; "ucz mnie".

No i cóż... faktycznie zostałem nauczony. Wiem już co wchodzi w skład Azure (compute do wykonywania operacji, storage do składowania danych), wiem że mogę sobie w tajemniczą chmurę wrzucić bazę danych sql, że mogę tam sobie uruchomić swoje .NETowe usługi. Zobaczyłem (w zbyt nudnych i chyba niepotrzebnych szczegółach) jak widziane są tam dane i jakie operacje mogę na nich wykonać. Co najważniejsze, przedstawiono również argumenty PO CO tak naprawdę warto interesować się takimi rozwiązaniami.

I... to właściwie tyle. Moje jedyne oczekiwanie zostało zaspokojone: mam już pojęcie co to Azure. Normalna sesja jakich wiele, z momentami ciekawymi i momentami nudnymi. Teoretycznie mogłem dowiedzieć się tego samego ze strony What is the Windows Azure Platform?, ale nie żałuję że tą sesję wybrałem.

Ocena: 7/9 (tak sporo bo dowiedziałem się tego czego chciałem; nie więcej, bo w sumie bez rewelacji)

3. "Visual Studio 2010 - najciekawsze cechy w praktyce" Bartosz Pampuch

Wchodzenie do sali, w której prezentować ma Bartek, zawsze wiąże się z pewnym podekscytowaniem. Powód jest bardzo prosty: nigdy nie wiadomo czym tym razem nas zaskoczy. Nie inaczej było i tym razem. I, jak zwykle, zaserwowano nam coś niesamowitego. Na samym początku, zamiast standardowego "dzień dobry, nazywam się X i programuję w .necie" zaserwowano nam wbijający w ziemię, profesjonalny filmik prezentujący agendę prelekcji. To się nazywa prawdziwy efekt WOW.

Całość prezentacji nie odbiegała poziomem od niesamowitego wstępu. Bardzo szczegółowo zaprezentowano nam jedną z najważniejszych cech nowego Visuala, czyli historyczny debugger. Możliwości, jakie nam daje, przedstawiono na prawdziwych przykładach na które możemy natknąć się podczas normalnej pracy; żadnych tendencyjnych demek dla których nikt nigdy nie znajdzie zastosowania. Szacunek wzbudza praca, jaką Bartek wykonał eksperymentując z tym narzędziem. Samodzielne modyfikowanie wewnętrznych XMLi wykorzystywanych przez VS w celu zdefiniowania własnych zdarzeń raportowanych przez debugger to jest coś, czego nie zobaczy się na pierwszej lepszej sesji. Efekt naprawdę super – otrzymaliśmy narzędzie, które w okienku historii debuggowania wypisuje wszystkie zapytania SQL wysyłane do bazy przez aplikację. Bezcenne.

Oprócz historycznego debuggera mogliśmy obserwować mocno zaawansowane i niskopoziomowe rozważania o teorii i praktyce programowania współbieżnego. W pasjonujących szczegółach Bartek pokazał czym różni się nowy mechanizm zadań mający zastąpić dotychczasową interakcję z wątkami oraz jakie zalety wiążą się z zastosowaniem tego rozwiązania. Rzucił też nam kilka zadziwiających pułapek czyhających na programistę wkraczającego w krainę wielowątkowości, z których niewiele osób na sali zdawało sobie sprawę.

Następnie przeszliśmy do możliwości rozszerzania nowego Visuala, który w nowej wersji staje się wreszcie (między innymi dzięki zastosowaniu WPF i MEF) prawdziwie ŁATWO rozszerzalną platformą. Przykład stworzenia własnego panelu wyświetlanego w edytorze za pomocą kilku linijek kodu C# robił wrażenie (więcej o mechanizmie Adornments na blogu zespołu tworzącego edytor).

Na koniec krótkie demko pod tytułem "jak stworzyć własną stronę startową Visualu" i pasjonująca jazda po Visual Studio 2010 i okolicach dobiegła końca. No, prawie końca, ponieważ prawdziwe zakończenie to kolejny niesamowity filmik podsumowujący to co dopiero zobaczyliśmy.

Po raz kolejny Bartek udowodnił, że jest prawdziwym artystą jeśli chodzi o przygotowywanie prezentacji. Brawo!

Ocena: 9/9 (jak zwykle: za prezentację, podczas której każda sekunda była wykorzystana w 100%)

4. "Software Development Life Cycle z Team Foundation Server 2010" Tadeusz Golonka i Marcin Książek

Na wstępie zaznaczę, że z TFSem miałem do czynienia przy trzech projektach i mam nadzieję że nigdy więcej mnie to nie spotka. Na sesję poszedłem bardziej dla Tadeusza Golonki niż samego tematu, chociaż zerknięcie "co nowego się kroi w tym fe-obszarze" także było dość pociągające.

Wykład utwierdził mnie jedynie w moim "nielubieniu" TFSa. Właściwie ciężko mi napisać co wyniosłem z tej półtoragodzinnej prezentacji: przez cały czas skupiałem się bardziej na przekonaniu się do samego produktu niż zapamiętywaniu co się tam zmienia. No i niestety, nie wyszło. Nie było żadnych porywających momentów, więc trochę się nudziłem. Ożywiłem się w momencie demonstracji współpracy z repozytorium kodu, ponieważ ten aspekt współpracy z TFS był dla mnie najbardziej bolesny. Okropność! Z tego co zrozumiałem istnieje pewien scenariusz, w którym po kliknięciu na komunikat nieudanego buildu jesteśmy przenoszeni do pliku powodującego problemy, a po jego modyfikacji i wciśnięciu ctrl+s zostaje on automatycznie (sic!) wysyłany do repozytorium! To jest coś, czego zdecydowanie NIE OCZEKUJĘ od systemu kontroli wersji. A jeśli coś źle zrozumiałem to bardzo proszę kogoś o sprostowanie...

I... to tyle. Na koniec padło pytanie "jaka jest dolna granica liczebności zespołu programistów, dla której warto rozważyć wdrożenie TFS?" Odpowiedź "3" wydaje mi się mocno przesadzona. Pakowanie się w taką kobyłę przy projekcie innym niż jakiś naprawdę wielki system to jak dla mnie nieuzasadnione komplikowanie życia. Tym bardziej, że z TFS jest jak z MS Project: o ile ten drugi jest często wykorzystywany jedynie jako narzędzie do tworzenia diagramu Gantta, o tyle ten pierwszy to w wielu przypadkach tylko repozytorium kodu. Repozytorium kodu, które po poznaniu takich rozwiązań jak chociażby Git wydaje się po prostu nieużywalne.

Ocena: 6/9 (poprawna prezentacja produktu, jednak jak dla mnie – zbyt statyczna, zbyt nudna)

5. "Windows 7 dla deweloperów" Bartłomiej Zass

Drugi dzień postanowiłem rozpocząć kolejnym rzutem oka na Win7, tym razem z perspektywy programisty. Zeszłoroczny występ Bartka na Sali Kongresowej wspominam bardzo dobrze, więc spodziewałem się udanej powtórki. I szczerze mówiąc zaprezentowany materiał można określić jako imponujący. Sposób przekazywania wiedzy także nie pozostawiał nic do życzenia, wygląda na to że Bartek jest Microsoftową gwiazdą którą wypycha się na największe sale w celu pokazania najbardziej popularnych tematów. Co w tym przypadku było całkowicie uzasadnione.

Dla mnie, który Win7 właściwie nie zna, wystąpienie wypakowane było po brzegi prawie samymi nowościami. Można było dowiedzieć się jak dokładnie działa przesławne XP Mode i kiedy z tego korzystać, pokazano nam również zakres problemów które ten trick rozwiązuje oraz, co nawet ważniejsze, jakie wady posiada. Zobaczyliśmy nowości w procesie uzyskiwania dla aplikacji loga mówiącego o kompatybilności programu z nowym systemem operacyjnym. Budowa i możliwości nowego paska zadań oraz sposoby na integrację z nim również budziły żywe zainteresowanie – to jest naprawdę fajny i jakże potężny mechanizm! Dodatkiem do sesji była prezentacja kontrolki wstążki dla aplikacji .NET, pozwalającej na stworzenie "office-like" menu we własnych programach. Wspomniano również o zarządzanych wrapperach na natywne biblioteki Windows pozwalające na takie czynności jak chociażby monitorowanie stanu baterii w laptopie. Każdy z tematów poparty był krótkim demkiem, więc na własne oczy mogliśmy przekonać się "co autor miał na myśli".

Dzięki tej sesji z pewnością wkrótce zainstaluję Windows 7. Leży sobie na dysku już od sierpnia i chyba nadszedł czas, aby pożegnać sie z wysłużonym XP.

Ocena: 7/9 (całkowicie poprawne przedstawienie nowości czekających na nas w nowym systemie; rewelacji brak, ale pójść było warto)

6. "Usługi w świecie Microsoft: WCF, REST, .NET Service Bus, Workflow Services" Tomasz Kopacz

Przed sesją Tomasza Kopacza zawsze trzeba przygotować się na spory wysiłek intelektualny. Każde kolejne jego wystąpienie udowadnia, że w tej głowie mieści się po prostu cała encyklopedia wiedzy o technologiach Microsoft. I zawsze wiedza ta jest przed publicznością prezentowana w klarowny, profesjonalny sposób.

Jednak tego dnia z sali wyszedłem z mieszanymi uczuciami. Co prawda wystąpienie było niby takie jak zawsze: szalony galop przez technologie wspomniane w temacie, ale jednak coś mi tu nie grało. Przejechanie się po całym WCF, od podstaw konfiguracji po zaawansowane scenariusze rozszerzania platformy własnymi Message Inspectors, podczas 80 minut jest po prostu niewykonalne. A jak dorzucimy do tego kilka zdań o Azure, .NET Sevice Bus, przedstawienie koncepcji i implementacji REST to uzyskamy misz-masz, który, z niejasnych powodów, jakoś mi nie podpasował. Wydaje mi się że zdecydowanie lepiej byłoby odrzucić połowę agendy i bardziej skupić się na mniejszej ilości materiału niż lecieć na łeb na szyję. O tempie prezentacji świadczyć może mała anegdotka: gdy podczas jednej z miliarda demonstracji z VS wyskoczył niespodziewany wyjątek, z tyłu usłyszałem "nareszcie chwila przerwy".

Nie mogę powiedzieć że coś mi się szczególnie nie podobało czy że prelegent coś robił źle – cały czas słuchałem z zainteresowaniem. Wydaje mi się po prostu, że jeśli ktoś zagłębiał się w WCF to niewiele nowego wyniósł z sesji. A jeśli ktoś się w WCF NIE zagłębiał, to niewiele zrozumiał (teoria poparta konsultacjami ze znajomymi). WCF ma to do siebie, że przedstawienie stu demek jedno po drugim na niewiele się zdaje, tutaj trzeba w każdym scenariuszu zatrzymać się na nieco dłużej. I tego zabrakło.

Ocena: 6/9 (sam nie wierzę że TKopacz dostaje ode mnie tylko tyle, ale pomimo że prowadzenie sesji było takie jak zawsze, to jej PRZYDATNOŚĆ... już nie)

7. "Workflow Foundation 4.0" Marcin Najder

Praktyczne wykorzystanie Workflow Foundation ograniczało się w moim przypadku do budowania prostych przepływów w Sharepoint przy okazji ITCore. Słyszałem jednak o wielkich zmianach, jakie MS planuje wprowadzić w nowej wersji, więc z niecierpliwością czekałem na tą prezentację.

"Wielkie zmiany" przeszły moje oczekiwania, ponieważ dowiedziałem się, że całość zostaje zaorana i napisana od nowa. Wyłuszczono nam powody, dla których podjęta została taka a nie inna decyzja, oraz jej efekt: ogromny wzrost wydajności (10-100x!) spowodowany zmianą sposobu serializacji i wewnętrznej budowy przepływów. Oprócz tego dostarczony framework będzie lepiej zaprojektowany, łatwiejszy do wykorzystania przez programistów. Nie będzie już możliwości pójścia na skróty poprzez wrzucenie na diagram "Code activity", dwuklik i umieszczanie logiki w zboczonym pliku code-behind – i bardzo dobrze! Teraz po prostu będziemy tworzyli własne klasy umiejscowione odpowiednio w hierarchii WF. Definicja przepływu to teraz po prostu plik xaml, co znacznie uprości poruszanie się po tworzonym rozwiązaniu oraz zarządzanie nim. Designer także ulegnie poprawie, a to za sprawą zastosowania WPF w nowym Visual Studio.

Dowiedzieliśmy się też o kilku wadach takiego a nie innego kroku: z frameworku całkowicie wycięto "state workflow", w nowej wersji trzeba go będzie jakoś symulować przy pomocy standardowych sekwencyjnych przepływów. Skupiając się na ponownej implementacji istniejącej już funkcjonalności nie usprawniono mechanizmów znanych z przeszłości. Z pytań dobiegających z sali wyłapałem kilka powtarzających się kwestii, które nie zostaną w WF 4.0 ulepszone. Cofanie kroków przepływów, ubogie mechanizmy security, reakcja uruchomionych przepływów na podmianę definicji – to wszystko zostaje tak jak było z powodu "braku zasobów" po stronie MS.

Generalnie sesję uważam za udaną, dowiedziałem się wszystkiego czego oczekiwałem. Przede wszystkim: że praca z nowym WF będzie wygodniejsza. Jedyne co mnie raziło to prezentowane demka. Mieliśmy tu niestety do czynienia z banalnymi przykładami "wypisz linię na konsolę", "odczytaj linię z konsoli" i tak dalej. Bardziej zaawansowane demonstracje mogłyby sprawić, że całość prelekcji byłaby ciekawsza.

Ocena: 7/9 (właściwie dokładnie to czego się spodziewałem zaserwowane w poprawny sposób: co, jak, dlaczego i co z tego wynika)

8. "Czym zaskoczy Cię ASP.NET 4.0 w Visual Studio 2010?" Bartłomiej Zass

Na sam koniec wybrałem się ponownie do Sali Kongresowej na kolejny występ Bartka. Sam początek był dość zabawny: na slajdzie (nie wiem czy specjalnie czy nie) temat sesji brzmiał "Czym zaSSkoczy Cię..." co oczywiście kojarzyło się z nazwiskiem prelegenta. Agenda przedstawiała się interesująco: całe ASP.NET rozbito na mniejsze, odrębne części: WebForms, Ajax, MVC, Dynamic Data i każdą z nich omówiono osobno.

Zmiany wprowadzone w poprzedniej wersji ASP.NET nie zasługiwały moim zdaniem na miano "kolejnej wersji". Ot, nowe kontrolki. Okazało się że teraz jest niewiele lepiej: czy przejęcie kontroli nad generowanymi przez silnik ASP.NET identyfikatorami czy bardziej szczegółowe zarządzanie ViewState wystarcza do zwiększenia numeru wersji? Jak dla mnie – nie bardzo. Z drugiej strony może ta platforma jest już aż tak dojrzała, że nie ma tam nic innego do roboty? Fajnie prezentuje się nowa kontrolka do generowania wykresów, ale znowu: czy to taka wielka zmiana?

Po WebForms przyszedł czas na Ajaxa. Prezentowane tu funkcjonalności mogły robić wrażenie. Mamy .NET po stronie serwera, mamy Silverlight po stronie klienta, a teraz... mamy prawie-.NET w JavaScript? Trochę tak to wygląda. Databinding, framework do komunikacji z DataServices, ogromne biblioteki do tworzenia bogatych interfejsów użytkownika wraz z szablonami: to wszystko w JS. Nie powaliło mnie to na ziemię, raczej zmusiło do zastanowienia nad ewolucją programowania www jako takiego. Wykorzystanie JavaScript do budowania zaawansowanych mechanizmów interakcji z użytkownikiem i przekazywania jego intencji na serwer to jedno, ale przeniesienie tak ogromnej części funkcjonalności na stronę klienta w postaci kodu JS, z zostawieniem "głupiego" serwera, to coś nad czym trzeba się chyba głębiej zastanowić. A materiału do analizowania i "zastanawiania" jest naprawdę masa. Poza MS Ajax powiedziano co nieco o JQuery, jednak jakość tej części prezentacji pozostawiała wiele do życzenia. Odniosłem wrażenie, że prelegent nie bardzo wie o czym mówi i ogranicza się do cytowania materiałów ściągniętych naprędce z netu.

Dalej nie było niestety lepiej. Kolejny poruszany element, czyli ASP.NET MVC, mnie zmiażdżył. Tutaj nie miałem wątpliwości: prezenter nie ma zielonego pojęcia o czym mówi. Przedstawienie ASP.NET MVC jako rozwiązania nadającego się jedynie do małych projektów do wykorzystania przez "zaawansowanych programistów chcących poświęcić więcej czasu" czy stwierdzenie "teraz jest w wersji preview, niebawem wyjdzie RTM" to tylko niektóre kwiatki. Ta część całkowicie zepsuła mi całą prezentację.

Na koniec posłuchaliśmy kilku słów o Dynamic Data – rozwiązaniu pozwalającym na błyskawiczne wygenerowanie stron do edycji danych na podstawie schematu bazy. Takie rozwiązania nie cieszą się moim wielkim zainteresowaniem, więc trwając w zniesmaczeniu spowodowanym poprzednim elementem cierpliwie czekałem na koniec sesji. Tym większa szkoda, że wszystkie dotychczasowe sesje Bartka wspominałem bardzo pozytywnie.

Ocena: 5/9 (było całkiem OK, gdyby nie kompletny brak przygotowania do niektórych części prezentacji)

Speaker Idol

Konkurs Speaker Idol zagościł chyba na stałe na MTS – i świetnie! Doskonały sposób na rozpoczęcie prelegenckiej kariery. W tym roku poziom był moim zdaniem jeszcze wyższy niż rok temu. Wszyscy finaliści (półfinału nie widziałem) zaprezentowali się bardzo profesjonalnie. Poruszane tematy były ciekawe, a pięciominutowe występy dowodziły, że chyba dla żadnego z uczestników prowadzenie sesji to nie pierwszyzna. Oglądając to widowisko byłem bardzo zadowolony ze swojej decyzji o niestartowaniu; czasami lepiej znać swoje miejsce i nie pchać się tam gdzie nie trzeba ;).

Przyjemnie słuchało sie też uwag jury, które przekazywało naprawdę trafne i słuszne spostrzeżenia. Zastosowanie się do ich uwag z pewnością może przyczynić się do jeszcze wyższego poziomu wystąpień ich adresatów.

Gratulacje dla zwycięzcy, Tomasza Wiśniewskiego! Powodzenia, mam nadzieję że uda mi się odwiedzić twoją sesję w przyszłym roku :).

Podsumowanie

Widać postęp organizacyjny w stosunku do zeszłorocznej edycji, za co zdecydowanie czapki z głów. Jednak to oferta merytoryczna jest najważniejsza, a moim zdaniem tutaj było trochę gorzej. Jak można zobaczyć wyżej, nie trafiłem na ewidentne wpadki (co niestety miało miejsce rok temu), ale niestety nie mogę też krzyknąć: rewelacja! Właściwie cała konferencja nie wywołała u mnie większych emocji... Ot, było i nie ma.

Zdecydowanie poprawić można moim zdaniem dwie rzeczy (oprócz agendy, ale to jak wiadomo subiektywne odczucia): po pierwsze półfinaliści Speaker Idol nie powinni być traktowani po macoszemu, jako "gadające głowy do kotleta". Sam chciałem to obejrzeć, ale po prostu na korytarzu nie bardzo są do tego warunki. A po drugie: to co dzieje się pod salami, ludzkie pojęcie przechodzi. Wiem że jakoś trzeba zapewnić pierwszeństwo wejścia uczestnikom pełnoprawnie zapisanym na daną sesję i dopiero później wpuszczać pozostałych, ale może da się to jakoś lepiej zorganizować? Sodoma i gomora panujące przed wejściem na większość sesji nie powinna mieć miejsca. A napływ nowych słuchaczy 5 minut po rozpoczęciu wykładu najzwyczajniej w świecie przeszkadza... Ale na szczęście nie ja muszę myśleć co zrobić aby było lepiej:).

Ocena MTS 2009: 7/9 (ogólnie spoko, ale bez rewelacji; jakbym zapłacił 1500 zł, ile wynosiła oficjalna cena wstępu, to bym nie był szczęśliwy, chociaż widać postęp w stosunku do wersji 2008)

Trzymajcie dzieci z dala od Xboxa!!!

Procent — Thu, 01 Oct 2009 10:23:00 +0100

Czego potrzeba do zostania perkusistą, jeśli nie masz warunków do nauki gry na prawdziwej perkusji? Oczywiście konsoli Xbox i gry Guitar Hero, poczynając od edycji World Tour. A jeśli nie masz ani gry, ani konsoli? Za grę robić może świetny kawałek open-source’owego napisanego w Pythonie softu pod nazwą Frets on Fire z modem FoFiX. Za konsolę: zwykły PC (z urządzeniem pozwalającym na używanie bezprzewodowych kontrolerów od Xboxa, czyli Xbox 360™ Wireless Gaming Receiver for Windows®). Do tego perkusja i jazda. Polecam, polecam i jeszcze raz polecam! Ostatnio nie mam niestety czasu żeby się tym odpowiednio (czyt.: dłużej niż 20 minut dziennie) delektować, ale tak czy siak zabawa jest mega-przednia.

Ale ja nie o tym... Wszystkie zakupione przeze mnie akcesoria do Xboxa (perkusji dzięki łaskawości takiego jednego celebryta kupować na razie nie musiałem:) ) posiadają instrukcję. Ja mam to do siebie, że zwykle czytam takie rzeczy i czasami naprawdę się opłaca. Tym razem opłaciło się, bo poniższe zdanie wprawiło mnie w dobry humor na dłuższy czas:

"If the Xbox console falls and hits someone, especially a small child, it could cause serious injury."

Jeeeea, to się nazywa ostrzeżenie. Powoli zbliżają się święta, przed kupnem takiego prezentu swoim pociechom (gdybym je miał) porządnie bym się zastanowił. A już na pewno nie stawiał go nigdzie wyżej niż podłoga. Normalnie "minister zdrowia i opieki społecznej ostrzega"...

[Spis treści] Cykl o mock objects i Rhino Mocks

Procent — Tue, 29 Sep 2009 07:36:00 +0100

Dobiegł końca pierwszy na tym blogu cykl (chociaż posty pojawiały się częściej niż "teoretycznie co 28 dni") technicznych postów rozprawiających się z jednym zagadnieniem krok po kroku. A konkretnie: pisaniem testów jednostkowych z wykorzystaniem "obiektów mockujących" dostarczanych przez mechanizm zaimplementowany w bibliotece Rhino Mocks.

Pomyślałem że dobrze będzie zebrać w jednym miejscu to co się wykluło od jego powstania do jego zakończenia, zatem poniżej spis postów poruszających tą tematykę:

Uwagi odnośnie całości jak zwykle mile widziane.

Przechwytywanie wartości parametrów z metod mock objects

Procent — Mon, 28 Sep 2009 08:35:00 +0100

Dzisiaj spojrzymy na sytuację, w której będziemy potrzebowali nie weryfikować, ale zapamiętać wartości przekazywane do mock objects w celu późniejszego ich wykorzystania. Scenariusz ten jest dość nietypowy, w moim przypadku SUT (System Under Test) rejestrował pewną operację w komponencie odpowiedzialnym za jej uruchomienie w odpowiednim momencie. wykonanie. Rejestracja odbywała się z wykorzystaniem wyrażeń lambda, więc przetesowanie rejestrowanej akcji w sposób "zwykły" nie było możliwe. Oto jak to wyglądało:

I jak przetestować faktyczne działanie zarejestrowanej akcji? O tak, z wykorzystaniem funkcjonalności "WhenCalled()":

Nie jest to zbyt czytelne i nagroda za design roku zdecydowanie mi się nie należy, więc przed zastosowaniem podobnej konstrukcji należy się porządnie zastanowić (następnym razem to zrobię, jak nic). Niemniej jednak – działa jak powinno.

Wkrocz na drogę do sukcesu - zarejestruj się na Imagine Cup 2010!

Procent — Mon, 21 Sep 2009 06:40:00 +0100

Sam się dziwię, że potrafię "skomponować", opublikować i autentycznie szczerze PODPISAĆ SIĘ pod tak ohydnie marketingowym tekstem. Ale... cóż, taka prawda. Nie jestem chyba w stanie wystarczająco dosadnie napisać jak bardzo zachęcam studentów do uczestnictwa w tym wydarzeniu. Sam z pewnością nie byłbym tu gdzie jestem teraz, gdybym kiedyś olał istnienie niesamowitych okazji, jakie daje konkurs Imagine Cup. Zaryzykuję nawet stwierdzenie, że decyzja o moim pierwszym starcie była najważniejszą (sic!) w mojej całej zawodowej karierze.

O konkursie pisałem już dwukrotnie (tutaj dlaczego warto w nim startować, a tutaj zrelacjonowałem ostatnie polskie finały).

W ciągu ostatnich pięciu lat uczestniczyłem w IC trzykrotnie - dwa razy jako uczestnik i raz jako widz. I za każdym razem było super. Dlatego, drogi studencie, łap okazję póki czas! Nie odkładaj tego na następny rok, nie wykręcaj się ciężką sesją i natłokiem zajęć. To jest po prostu ważniejsze niż studia i imprezy.

Zdecydowanym życzę powodzenia - z zainteresowaniem będę obserwował efekt waszej ciężkiej pracy na kolejnych finałach!

Tymczasowe wstrzymanie aplikacji ASP.NET

Procent — Mon, 14 Sep 2009 06:21:00 +0100

Krótka ciekawostka, pewnie znana większości: wrzucając do katalogu głównego aplikacji ASP.NET plik o nazwie app_offline.htm spowodujemy, że będzie on serwowany jako odpowiedź na wszystkie żądania do tej aplikacji. Zastosowań może mieć kilka, z których najbardziej oczywistym jest tymczasowe "zdjęcie" witryny podczas wgrywania nowej wersji czy rozwiązywania jakiegoś problemu: wypełniamy wówczas ten plik komunikatem o tymczasowej niedostępności i tyle, lepsze to niż standardowy komunikat o błędzie. Inny przykładowy scenariusz użycia to automatyczne przekierowanie użytkowników na inny adres – wystarczy w pliku zamieścić odpowiedni meta-tag (<meta http-equiv="refresh" content="5;url=http://example.com/" />).

Warto o tym wiedzieć, potrafi uprościć życie.