- ReSharper a C# 3.0: pierwsze wrażenia
-
Zainstalowałem niedawno 30-dniową wersję ReSharpera 4.0 i badam jak to narzędzie się sprawuje. Kiedyś używałem ReSharpera na codzień, ale zmieniłem pracę i narzędzie nie poszło za mną. Z powodu wydania wersji 4.0 postanowiłem zobaczyć jak daleko sprawy poszły do przodu.
Pierwsze wrażenie jest takie, że ReSharper bardzo gorąco zachęca do stosowania nowinek z C# 3.0. Na każdym kroku pojawia się zachęta do zamiany zwykłych deklaracji na te z użyciem słowa kluczowego var. Efekt jest taki, że po pierwszych dniach niepewności i wahania zaczynam się przestawiać i (nad) używać var. Dzisiaj natrafiłem na "gotcha" związane z odruchowym stosowaniem słowa kluczowego var: stare, niegeneryczne kolekcje rodem z C# pre-2.0. Zamiast zastanowić się chwilę nad tym po jakiego typu obiektach chcemy iterować, resharperowy live template i słowo kluczowe var wyprowadzają nas w maliny i zostawiają ze standardowym zestawem znanych metod, czyli ToString, Equals, GetHashCode i niczym więcej. Nadal trzeba się pilnować :(.
Drugą refaktoryzacją, z której zacząłem korzystać bardzo często jest zamiana sekwencji: utworzenie obiektu + seria przypisań do właściwości tego obiektu na nową składnię, na przykład:
var customer = new Customer();
customer.FirstName= "Marcin";
customer.LastName= "Hoppe";
zamienia się na:
var customer = new Customer {
FirstName= "Marcin",
LastName= "Hoppe"
};
Ostatnie: bardzo fajna jest refaktoryzacja z bezparametrowych anonimowych metod do wyrażeń lambda postaci
() => ...
Postaram się w niedalekiej przyszłości napisać coś więcej na temat tego, co mi się w nowym ReSharperze podoba (albo i nie).
- Nowa składnia asercji w NUnit 2.4
-
Podstawą każdego testu jednostkowego jest asercja, czyli polecenie sprawdzenia, czy testowany obiekt spełnia pewną własność. W wersjach NUnit wcześniejszych niż linia 2.4 podstawowym sposobem do wyrażenia asercji w kodzie testu było użycie statycznych metod klasy Assert z przestrzeni nazw NUnit.Framework. Na przykład:
[Test]
public void StringBuilderShouldGlueStringsTogether() {
StringBuilder builder = new StringBuilder();
builder.Append("NUnit ");
builder.Append("2.4.7");
Assert.AreEqual("NUnit 2.4.7", builder.ToString());
}
Podstawowym i najczęściej chyba używanym typem asercji jest sprawdzenie, czy dwie wartości są sobie równe (metoda Assert.AreEqual), tak jak w powyższym przykładzie. Klasa Assert dostarcza jeszcze wielu innych metod, które pozwalają w łatwy sposób sprawdzać własności obiektów. Na przykład:
[Test]
public void MathSinShouldReturnValuesGreaterOrEqualToMinusOne() {
// Nigdy nie powinniśmy losować wartości w testach!
Random generator = new Random();
double argument = generator.NextDouble();
double sin = Math.Sin(argument);
Assert.GreaterOrEqual(sin, -1.0);
}
Oprócz klasy Assert mamy do dyspozycji także bardziej wyspecjalizowane klasy:
Klasy te umożliwiają łatwe sprawdzanie bardziej wyszukanych własności, takich jak na przykład to, czy kolekcja zawiera jakiś element:
[Test]
public void CollectionShouldContainItsElements() {
int[] integers = new int[] { 1, 2, 3, 4, 5 };
CollectionAssert.Contains(integers, 3);
}
W wersji 2.4 biblioteki NUnit wprowadzono nowy sposób wyrażania asercji oparty o ograniczenia (ang. constraint model). W tym modelu do wyrażenia każdej asercji używamy jednej i tej samej metody Assert.That, a logika związana ze sprawdzeniem własności testowanego obiektu jest zaimplementowana w odpowiednim obiekcie, który przekazujemy jako jeden z parametrów metody Assert.That. Obiekty te noszą nazwę ograniczeń. Na przykład:
[Test]
public void StringBuilderShouldGlueStringsTogether() {
StringBuilder builder = new StringBuilder();
builder.Append("NUnit ");
builder.Append("2.4.7");
Assert.That(
builder.ToString(),
new EqualConstraint("NUnit 2.4.7"));
}
Obiekt klasy EqualConstraint (z przestrzeni nazw NUnit.Framework.Constraints) implementuje logikę zawartą poprzednio w kodzie metody Assert.AreEqual. W czym ten sposób wyrażania asercji jest lepszy od poprzedniego? Siła nowego modelu leży w klasach pomocniczych zawartch w przestrzeni nazw NUnit.Framework.SyntaxHelpers, które pozwalają w łatwy sposób tworzyć i łączyć obiekty implementujące ograniczenia. Klasy pomocnicze, o których tutaj mowa, stanowią fluent interface (opisany przez Martina Fowlera), co czyni API do tworzenia obiektów implementujących ograniczenia bardzo czytelnym i intuicyjnym w użyciu. Niech przykłady mówią same za siebie:
[Test]
public void StringBuilderShouldGlueStringsTogether() {
StringBuilder builder = new StringBuilder();
builder.Append("NUnit ");
builder.Append("2.4.7");
Assert.That(builder.ToString(), Is.EqualTo("NUnit 2.4.7"));
}
[Test]
public void MathSinShouldReturnValuesGreaterOrEqualToMinusOne() {
// Nigdy nie powinniśmy losować wartości w testach!
Random generator = new Random();
double argument = generator.NextDouble();
double sin = Math.Sin(argument);
Assert.That(sin, Is.GreaterThanOrEqualTo(-1.0));
}
[Test]
public void CollectionShouldContainItsElements() {
int[] integers = new int[] { 1, 2, 3, 4, 5 };
Assert.That(integers, Has.Member(3));
}
Miłego testowania!
- Doktryna jakości
-
Po dość długim okresie milczenia chciałbym je przerwać linkiem do dwuczęściowego artykułu, który ukazał się kilka lat temu na łamach PC Kuriera. Artykuł dotyczy systemowego zarządzania jakością (ang. total quality management) i wydał mi się nader ciekawy. Oto linki:
Doktryna jakości - pracowników traktuj jak partnerów, a nie jak podwładnych
Doktryna jakości w praktyce
Artykuły polecam z całego serca każdemu, kto sądzi, że w jego miejscu pracy nie wszystko działa tak, jak należy!
- Witaj F#!
-
Każda przygoda z nowym językiem programowania musi niezawodnie zacząć się od programu wypisującego na ekran jakiś napis. Zmęczony służbową podróżą, zakwaterowaniem w hotelu, dwudniowym szkoleniem i zauważalną niestety zmianą klimatu (pada!), postanowiłem zacząć poznawanie F# od skompletowania niezbędnych narzędzi i napisania mojej własnej wersji klasycznego programu.
Instalujemy kompilator
W chwili, w której piszę ten post F# ma na nadal status języka eksperymentalnego, co oznacza między innymi to, że jego kompilatora i narzędzi należy szukać na stronach Microsoft Research: http://research.microsoft.com/fsharp/fsharp.aspx. Na stronie języka znajdziemy:
- link do strony, z której można pobrać pakiet instalacyjny,
- spis zalet języka (niezwykle przydatny w internetowych wojnach religijnych na temat wyższości F# nad C#, Haskellem, Javą, asemblerem i innymi mniej lub bardziej egzotycznymi językami programowania),
- zestaw krótkich tutoriali, które pozwalają w ekspresowym tempie zabrać się do tworzenia prostych programów,
- podręczniki: języka, jego bibliotek oraz narzędzi, które przy pierwszym kontakcie nieco onieśmielają, ale wydają się być dobrym źródłem informacji,
- panel z nowościami z małego światka języka F#.
Ze strony http://research.microsoft.com/fsharp/release.aspx pobrałem plik InstallFSharp-1.9.3.14.msi z datą wydania 24 stycznia 2008 (mam więc okazję pobawić się całkiem świeżą zabawką). Instalacja wymaga od użytkownika jedynie zaakceptowania warunków licencji oraz wskazania folderu, do którego zostanie zainstalowany kompilator i reszta narzędzi. Instalator sam zatroszczy się także o zainstalowanie dodatków do Visual Studio, które uprzyjemnią pisanie aplikacji w F#.
Interaktywna powłoka
Wydaje mi się, że jeśli język programowania jest wyposażony w interaktywny interpreter, któremu można podawać pojedyncze polecenia i natychmiast obserwować efekt ich działania, to bardzo przyspiesza on pierwszy etap nauki języka, gdzie dużą rolę odgrywają eksperymenty i możliwość szybkiego przetestowania suchej wiedzy z książek i artykułów. Na myśl przychodzą mi tutaj przede wszystkim języki Python i Ruby, ale nie wolno zapomnieć o bardzo udanym środowisku PLT Scheme, które służy do nauki programowania w języku Scheme i jest środowiskiem rekomendowanym przez, moim zdaniem bardzo dobrą, książkę "How to Design Programs" (Scheme jest także używany w klasycznej książce "Structure and Interpretation of Computer Programs"). Interaktywny interpreter F# (będę też używał nazwy interaktywna powłoka) to program fsi.exe, który znajduje się w katalogu bin w folderze, który wskazano podczas instalacji. Rzecz jasna, warto ten folder dodać do ścieżki systemowej, żeby można było wygodnie uruchamiać powłokę z każdego miejsca w systemie Windows.
Po uruchomieniu programu fsi.exe czeka na nas krótka informacja o programie i wykaz najpotrzebniejszych poleceń konsoli, takich jak dodawanie referencji do zewnętrznych bibliotek, wczytywanie plików czy zamykanie powłoki. W bibliotekach języka F# jest kilka funkcji, które umożliwiają wyprowadzanie napisów na standardowe wyjście. Żeby nie komplikować sprawy, posłużę się funkcją, która wypisuje na wyjście podany napis oraz znak końca linii:
> print_endline "Witaj F#";;
Z tego prostego przykładu można natychmiast zauważyć, że w F# argumentów funkcji (i metod) nie ujmuje się w nawiasy. Wynik działania programu w moim środowisku przedstawia poniższy obrazek.
Jak widać, po wydaniu polecenia i zakończeniu go parą średników na ekranie pojawił się długo oczekiwany napis oraz mało zrozumiały dodatek:
Witaj F#!
val it : unit = ()
O tym, co oznaczają te hieroglify postaram się dokładnie opowiedzieć innym razem.
Samodzielny program
Interaktywna powłoka to jednak nie wszystko, na co stać F#. Programy napisane w F# można kompilować do takiego samego kodu IL, co programy napisane w językach C# i Visual Basic .NET. Kompilator, którego potrzebujemy to program fsc.exe znajdujący się w tym samym folderze, w którym znajduje się interpreter. Program, który wpisałem w po znaku zachęty interpretera mogę bez żadnych zmian skopiować do pliku hello_fsharp.fs i skompilować poleceniem:
C:\>fsc hello_fsharp.fs
a następnie uruchomić i uzyskać oczekiwany wynik:
C:\>hello_fsharp.exe
Witaj F#!
Jak widać, kompilacja jest prosta i przy pierwszym spotkaniu oszczędziła mi niespodzianek, krzyków i niezrozumiałych błędów. Oby tak dalej!
A może być tak skorzystać z .NET Framework?
Program, który napisałem korzysta z biblioteki standardowej F#. Na zakończenie chciałbym jednak pokazać, że F# jest pełnoprawnym członkiem .NET-owej rodziny i bez żadnych nakładów można w nim korzystać z bibliotek, które już znamy. Nic prostszego! Aby skorzystać ze znanej i lubianej klasy System.Console i jej metody WriteLine wystarczy napisać:
> System.Console.WriteLine "Witaj F#!";;
żeby w odpowiedzi dostać tę samą, co poprzednio odpowiedź interpretera:
Witaj F#!
val it : unit = ()
Prawda, że to proste? Mam nadzieję, że dalsza nauka będzie równie przyjemna!
- Najlepszy programista F# w Polsce
-
Zgaduję, że jeszcze nikt w Polsce nie tytułuje się najlepszym programistą F#. Moje noworoczne postanowienie: nauczyć się języka F# od absolutnych podstaw oraz doprowadzić swoją wiedzę i praktyczne doświadczenie do stanu uzasadniającego posługiwanie się powyższym tytułem. Aha, zapomniałbym o czymś ważnym: prowadzić najbardziej poczytny i obsypany największą liczbą nagród blog na temat programowania w F#.
Oczywiście żartuję, ale tylko trochę.
Dlaczego akurat F#?
Na pewno w jednym z nadchodzących postów napiszę coś na temat zalet programowania w językach funkcyjnych, ale w chwili obecnej czuję, że liczba dokumentów na ten temat w zupełności zaspokaja potrzeby naszej planety w tym zakresie. Czuję się jednak zobowiązany uzasadnić, dlaczego chcę się nauczyć właśnie języka F# i dlaczego uważam, że będzie to pożyteczne dla mojej dalszej kariery i umiejętności.
F# jest językiem programowania, który łączy kilka paradygmatów: programowanie funkcyjne, imperatywne oraz obiektowe. Bardzo podoba mi się podejście, gdzie programista ma dużą swobodę w wyborze metody rozwiązania danego problemu. Kolejne zalety F#, według marketingowej broszury, to pełna integracja z CLR (czyli my wołamy klasy z .NET Framework lub spadkowy kod napisany w C# i vice versa) i Visual Studio (gdzie mamy do swojej dospozycji znany i lubiany mechanizm IntelliSense). Do nauki z pewnością przyda się interaktywne środowisko, w którym można wpisywać kod i natychmiast go wykonywać (REPL, czyli Read Eval Print Loop): uwalnia nas to od potrzeby uruchamiania kompilatora tylko po to, żeby przetestować jednowierszowy fragment kodu. F# to ciekawa propozycja ze strony Microsoftu: w pełni wspierany przez korporację praktyczny język programowania spoza głównego nurtu (za który uważam C#, Javę, Visual Basic, C++ a także w coraz większym stopniu Pythona i Rubiego).
Oprócz nieskończonych zalet samego języka, F# wydaje się mieć także praktyczne zastosowania. Sam Microsoft przyznaje się do stosowania F# a w Internecie można znaleźć zeznania osób, które stosowały F# do wizualizacji, obliczeń numerycznych, weryfikacji układów scalonych i programów, eksploracji danych oraz wyceny instrumentów finansowych (zostawiłem na koniec, bo to mój mały konik).
Starzy, mądrzy programiści (to Ci piszący już tylko książki...) twierdzą, że uczenie się nowych języków programowania, zwłaszcza bardzo różniących się od tych, których używaliśmy do tej pory, jest dobrym i sprawdzonym domowym sposobem na podniesienie swoich umiejętności. Postanowiłem zweryfikować, czy jest w tym chociaż trochę prawdy.
Jak zamierzam się uczyć?
Naukę F# zamierzam prowadzić na trzech płaszczyznach. Mam zamiar czytać o F# wszystko, co wpadnie mi w ręce, pisać w F# mniejsze i większe programy oraz opisywać na tym blogu wszystko, czego nauczę się po drodze. Tę ostatnią czynność uważam za kluczową w całym procesie uczenia się. Próba wyłożenia osobie trzeciej (zwłaszcza nieznanej) zdobytej wiedzy zmusi mnie do głębszego przemyślenia tego, czego się nauczyłem, powiązania tego z posiadaną już wiedzą i do jasnego sformułowania nowo nabytej wiedzy. Mam nadzieję, że blog wraz z upływem czasu będzie miał coraz więcej czytelników, którzy będą krytycznie oceniać moje kolejne wystąpienia i bezlitośnie demaskować wszystkie błędy i przekłamania, które mi się przytrafią (podejrzewam, że trochę ich będzie, zwłaszcza na początku).
Ważnym elementem nauki są przykłady. Postaram się, żeby przykłady, które będę wykorzystwał do nauki były ciekawe i w miarę oryginalne. Gdyby przykłady były zbyt hermetyczne i niezrozumiałe, tupcie i krzyczcie głośno!
Kim ja w ogóle jestem?
Wiem, że powinienem się przedstawić na początku. Miałem jednak poczucie, że gdybym tak zrobił, bardzo dużo osób zbyt szybko zaczęło kojarzyć moje nazwisko z tytułem najlepszego programisty F# w Polsce :).
Do rzeczy: nazywam się Marcin Hoppe i na codzień jestem inżynierem oprogramowania w polskim oddziale największej północnoirlandzkiej firmy software'owej Kainos Software Ltd. Na codzień pracuję z technologiami ze stajni Microsoftu, ostatnio głównie z systemem SharePoint. Od niedawna jestem również magistrem inżynierem informatyki (skończyłem Politechnikę Gdańską).
Na końcu chciałbym podziękować Michałowi za energię, którą wkłada w ten portal oraz za to, że zaprosił mnie do uczestnictwa w przedsięwzięciu pod nazwą zine.net.