Zapraszam na 74. spotkanie KGD.NET już w najbliższą środę, 30 maja o godzinie 18.30. Będziemy mieli okazję posłuchać Sebastiana Bełczyka (CoffeeScript) oraz Mirka Jedynaka (continuous delivery). Zapraszam do zapoznania się ze szczegółami spotkania i rejestracji tutaj.

Wszystkich zainteresowanych tematyką Continous Delivery zapraszam na moją prezentację podczas 73. spotkania KGD.NET. Osoby, które nie mogą dotrzeć do Krakowa mogą, dzięki uprzejmości portalu VirtualStudy.pl oglądać sesję na żywo on-line. Strona spotkania na VS znajduje się tutaj.

Sesja jest wprowadzeniem w tematykę Continuous Delivery. W kilku słowach można powiedzieć iż CD jest to podejście do tworzenia oprogramowania kładące nacisk na traktowanie każdego commita jako potencjalnie wdrażalnego na środowisko produkcyjne. Każdy commit jest budowany, poddawany wielorakim testom (jednostkowym, integracyjnym, akceptacyjnym etc.), a ostatecznie wdrażany produkcyjnie.

Continuous delivery kładzie ogromny nacisk na automatyzację wszelkich czynności związanych nie tylko z budowaniem i instalacją aplikacji, ale także z przygotowaniem odpowiedniego środowiska.

Podczas sesji zaprezentuję konkretną implementację idei continuous delivery, którą zbudowałem wraz z moim zespołem w ramach ostatniego projektu. Jest to implementacja niskokosztowa (zero płatnych narzędzi) stworzona głównie w oparciu o PowerShell.

Zapraszam także na drugą (a właściwie w kolejności chronologicznej — pierwszą) sesję 73-go spotkania: Pogromcy mitów: Czy specjaliści od użyteczności i programiści mogą ze sobą zgodnie współpracować? Marcina Czyżowskiego.

December is traditionally a time of retrospective posts. Forgive me please but I simply can’t resist following this trend. I’d like to share with you my thought about books I read this year. Hope you’ll find it useful when deciding what to read next.

REST in practice

This was the first Kindle book I bought. After reading it I could say I love both the book and the device. I learnt quite a lot about the principles of REST. The hardest part was understanding why these hypermedia are so important but then came the moment of enlightenment. I can for sure recommend reading it.

CSS: The Missing Manual

I must admit I had quite high expectations that I will learn how HTML layouts work and how to efficiently position elements. It turned out to be a book about CSS syntax and very basic stuff I already knew.

Management 3.0

I wanted to learn a little bit about management for quite some time and suddenly this book came out. I simply love all the analogies (i.e. to bacteria) Jurgen uses in the book to explain how such complex systems as software developer teams work. Recommended to everybody, even if you don’t plan to become a manager.

Event Processing in Action

Another high expectation book and another disappointment. I expected a good book on event-driven architectures but actually EPiA is a book about taxonomy and nomenclature of event systems. Not much more than a bunch of definitions.

Dependency Injection in .NET

I bought it via Manning early access program and it was for sure not a waste of money. Although because I had some experience with DI before and have been up-to-date with blogs and tweets of Krzysztof Koźmic and Mark Seeman, there was not much new to me in the book. Still, I don’t regret the money and I can happily recommend the book, especially if you are new to DI.

The Pragmatic Programmer

A friend of mine recommended this book to me so I though I can give it a try. I had mixed feelings after reading it. I can’t recall a single thing that altered my thinking or opened my eyes to some new insight. For sure it is a solid book and at the time of writing it contained some cutting-edge stuff but after a few years these ideas have become mainstream and their understanding is expected even from novice developers.

JavaScript: The Good Parts

Another tentative one. I expected a lot more hardcore stuff in the book. It left me with a feeling that I know JavaScript (which is bullshit). If you happen to don’t know it at all (are there such people?) it may be a good book to start with.

Streamlined Object Modeling

After hearing so many good things about the book on Domain-Driven Design group I simply had to read it. To my surprise I dint’t like it. I could not get rid of a feeling that authors promote some catch-it-all model they developed and claim it solves all problems (even probably hunger in Africa). The only thing I really liked was the modeling heuristic that objects that are active in real world tend to work better if modeled as passive in the domain model and vice-versa.

Working Effectively with Legacy Code

I bought this one because we started to rewrite some legacy code in my current project. I wanted to learn from the expert how to deal with such code. It turned out to be a good, solid book. I don’t remember any particular moments of enlightenment but for sure I learnt a lot.

Continuous Delivery

This is the last one. I’ve been reading it since Saturday and already read about 70%. Continuous Delivery is probably the best book I’ve read this year. Together with REST in Practice and Management 3.0, it totally changed the way I see software development as a process. Thanks Jez and Dave!

Looking into the new year…

There are several themes that dominate my Amazon wishlist for the next year:

• C# (need to refresh my knowledge)
• Lean (having heard a lot about Kanban I finally need to read some ‘classic’ books)
• Architecture (Pattern Oriented series in particular)

I would also like to read some ‘true classics’ like Extreme Programming Explained by Kent Beck. Life will show if this is doable…

Chciałbym zaprosić wszystkich na 69. spotkanie Krakowskiej Grupy Developerów .NET. Spotkanie odbędzie się jak zwykle w siedzibie ABB, przy ulicy Starowiślnej 13. Będzie także dostępne on-line dzięki uprzejmości portalu VirtualStudy. Na spotkaniu, jak zwykle, dwie sesje. Tym razem będą to:

Kanban – Usprawnienia bez wysiłku, którą zaprezentuje Paweł Brodziński, oraz

Software as a Service – jedna baza danych, wielu użytkowników, którą przedstawi Maksymilian Majer

Po spotkaniu zapraszamy wszystkich na wspólne piwo. Będzie to okazja, aby podyskutować z prelegentami na temat ich prezentacji w bardziej nieformalnych warunkach. Pierwsze dwie kolejki tym razem (to nie reguła) stawiają prelegenci!

Zapraszam do rejestracji na spotkanie tutaj.

Już za dwa dni, w środę 26 października odbędzie się 68. spotkanie KGD.NET. Dlaczego o tym tu pisze? Ponieważ spotkanie będzie, dzięki uprzejmości portalu VirtualStudy.pl, strumieniowane na żywo oraz nagrywane. Informację o spotkaniu na witrynie VS można znaleźć tutaj. Mieszkańców Krakowa i okolic oczywiście zachęcam na przyjścia osobiście (godzina 18.30, siedziba ABB przy Starowiślnej 13). Zarejestrować się można na stronie spotkania. Osoby, które się zarejestrują i przyjdą będą uczestniczyć w losowaniu nagród, m.in. voucherów Pluralsight, podręcznika .NET i innych.

Zapraszam serdecznie

PS. Po spotkaniu idziemy na piwo:)

W ubiegły piątek miałem przyjemność wystąpić na konferencji ABB Dev Day 2011 w Krakowie. Muszę przyznać, że była to jedna z najlepszych konferencji, na jakich byłem. Organizatorzy — Michał Śliwoń (@mihcall) i Rafał Legiędź (@rafek) – wykonali kawał świetnej roboty. Duże brawa dla nich.

Na tej konferencji pojawiłem się z prezentacją o (jakże by inaczej) CQRS. Więszość uczestników pewnie pamięta, ale na wszelki wypadek przypominam: rzuciłem wtedy wyzwanie zaimplementowania prostej aplikacji w ramach eksperymentalnej architektury CQREST (połączenie CQRS i REST, jak się łatwo domyśleć):

• dwa tygodnie
• prosty temat (koszyk z zakupami)
• trzy technologie: EventStore, WCF Web APIs oraz WCF Syndication APIs

Nagrodą jest licencja na jeden z produktów JetBrains oraz oczywiście wieczna sława:) Jeśli ktoś się do tej pory wahał, czy warto, niech przestanie się wahać i weźmie się za kodowanie.

Zaczynając od przeszłości, w ostatnią środę, 23 marca, odbyło się 63. spotkanie Krakowskiej Grupy Developerów .NET. Na spotkanie przyszło rekordowo dużo (aż 57!) osób. Pierwszą z sesji prezentowałem ja, natomiast drugą — Tomek Wiśniewski.

W dniach 31 marca-1 kwietnia odbędzie się druga edycja konferencji Agile Central Europe (ACE). Są jeszcze wolne miejsca. Studenci mogą liczyć na spore zniżki. Możecie także zgłosić się do pomocy w organizacji konferencji otrzymując w zamian darmową wejściówkę.

2 kwietnia odbędzie się Krakowski Code Retreat. Niestety miejsc już nie ma, ale możecie się zapisać na listę rezerwową — może szczęście się do Was uśmiechnie.

9 kwietnia o godzinie 19.00 planowane jest specjalne spotkanie KGD.NET na którym prezentację poprowadzić Greg Young. W dniach 11-13 kwietnia Greg organizuje szkolenie w Krakowie. Koszt szkolenia to 2000 zł, co jest ceną dosyć atrakcyjną w porównaniu do 1500 funtów, które trzeba zapłacić za podobne szkolenie organizowane za pośrednictwem SkillsMatter.

Również 9 kwietnia w Katowicach odbywa się drugi śląski Code Camp. Konferencja kończy się na tyle wcześnie, że swobodnie zdążycie wrócić do Krakowa na spotkanie z Gregiem. Rejestracja na SCC jest bezpłatna.

12 kwietnia o godzinie 20.00 zapraszamy do Rogu Brackiej i Reformackiej na kolejne spotkanie OpenBeer.

W dniach 18-20 kwietnia Piotrek Włodek będzie zwiedzał Polskę (Poznań, Wrocław i Katowice) nauczając na temat Managed Extensibility Framework. Naprawdę warto zobaczyć Piotrka w akcji.

Wreszcie pod koniec miesiąca kwietnia (dokładny termin jeszcze nie jest znany) odbędzie się kolejne spotkanie KGD.NET.

Architektura trójwarstwowa jest chyba najlepiej znaną implementacją wzorca warstw w architekturze aplikacji. Z mojego doświadczenia wynika jednak, że znajomość ta zwykle jest bardzo powierzchowna i nie sięga wgłąb (warstw;-)). Porzućmy więc na chwilę CQRS, DDD i inne fajne akronimy i wróćmy “do korzeni”. Co to jest architektura trójwarstwowa?

Definicja

Sama jej nazwa w języku polskim jest problematyczna. Angielska terminologia rozróżnia dwa ich rodzaje: tiers to warstwy fizyczne, natomiast layers – logiczne. W czasach kiedy architektura trójwarstwowa stawała się popularna (zastępując dwuwarstwowy model klient-serwer z terminalem i mainframem) nie było niezbędne rozróżnianie warstw fizycznych i logicznych, ponieważ odpowiadały one sobie jeden-do-jeden. Dziś mamy zupełnie inną sytuację, której polska terminologia nie jest w stanie oddać.

Warstwy fizyczne

W ujęciu fizycznym większość aplikacji biznesowych wciąż składa się z trzech warstw: interfejsu użytkownika (przeglądarka internetowa, smart client), logiki biznesowej (serwer WWW) oraz bazy danych (serwer RDBMS). Rzadkim, aczkolwiek spotykanym, rozwiązaniem w przypadku aplikacji z interfejsem HTML jest rozdzielenie fizyczne serwera WWW oraz serwera aplikacyjnego.

Warstwy logiczne

W ujęciu logicznym termin “architektura trójwarstwowa” nieco się zdewaluował. Istnieje obecnie wiele wzorców architektonicznych, które wywodzą się historycznie z architektury trójwarstwowej, ale mają z nią już niewiele wspólnego. Przyjrzyjmy się na początek najczęściej spotykanemu (i opisywanemu przez podręczniki Microsoft).

Przykład książkowy

Pierwszą warstwę stanowi interfejs ASP.NET WebForms. Poniżej niego znajduje się warstwa logiki biznesowej. Tradycyjnie (przed epoką LINQ to SQL) oficjalne diagramy Microsoft umieszczały na dole warstwę dostępu do danych zbudowaną w oparciu o ADO.NET. W ten sposób mieliśmy trzy warstwy logiczne. Warto zauważyć, że wszystkie one umieszczone są w jednej (środkowej) warstwie fizycznej. Tak było jednak do niedawna. Odkąd deweloperzy Microsoft mają do dyspozycji narzędzia ORM, nie ma już potrzeby samodzielnego budowania warstwy dostępu do danych. Cóż więc pozostaje? Warstwa interfejsu WebForms oraz warstwa logiki zawierająca także klasy reprezentujące encje biznesowe. Nie zmienia to jednak faktu, że opisana powyżej koncepcja jest najczęściej nazywana architekturą trójwarstwową. Dziwne, prawda? W których przyszło nam programować architektura trójwarstwowa jest terminem głównie marketingowym.

Przykład mniej książkowy — ActiveRecord

Aby nie opierać wszystkiego na przykładach produkowanych przez Microsoft, przyjrzyjmy się jeszcze dwóm innym wersjom architektury trójwarstwowej. Na początek wariant z wzorcem ActiveRecord. W tym wypadku także mamy do czynienia z dwoma warstwami: interfejsem i logiką biznesową. Specyfika wzorca ActiveRecord sprawia, że kwestie związane z persystencją są umieszczone tuż obok logiki aplikacji. Notka na marginesie: stosując stos technologiczny Microsoft wzorzec ActiveRecord polega na umieszczaniu logiki z klasach partial dla odpowiednich encji LINQ to SQL lub LINQ to Entities.

Przykład zupełnie nie książkowy — NHibernate

Drugi z przykładów spoza kręgu wpływów giganta z Redmond to aplikacja wykorzystująca NHibernate do dostępu do danych. W tym wypadku mamy do czynienia ze szczątkową wersją warstwy dostępu do danych zawierającą jedynie mapowania ORM. Mam pewne opory przed nazywaniem tego pełnoprawną warstwą. Powiedziałbym, że taka aplikacja jest dwuipółwarstwowa.

Architektura trójwarstwowa a MVC

MVC to jeden z najlepiej (obok Singletonu) znanych wzorców. Często natrafiam na pytania związane z relacją między MVC, a architekturą trójwarstwową. Jakiś czas temu zwykłem odpisywać, że koncepcje te nie mają ze sobą nic wspólnego, ponieważ MVC to wzorzec projektowy, a AT — architektoniczny. Czy jednak na pewno?

W dużych systemach z logiką biznesową zorganizowaną w formie modelu domeny rozróżnienie to ma sens. Stosuję wtedy MVC w logicznej warstwie interfejsu użytkownika. Warstwa logiki biznesowej to mój model domeny. W tym wypadku bardzo ważne jest zdanie sobie sprawy, że model z MVC to nie model domeny. Model z MVC to obiekty DTO przekazywane między warstwami GUI i logiki biznesowej.

Większość systemów nie jest jednak tak skomplikowana. Prosta aplikacja webowa zbudowana w oparciu o jakiś framework MVC (np. ASP.NET MVC) jest świetnym przykładem implementacji architektury trójwarstwowej (czyli tak naprawdę 2 lub 2,5 warstwowej). Widoki są częścią warstwy prezentacji, kontrolery i model — logiki biznesowej. Dostępu do danych istnieje zwykle jako peseudowarstwa na bazie mapera obiektowo-r. Tak więc MVC, będąc przede wszystkim użytecznym wzorcem budowy interfejsu użytkownika, może w niektórych wypadkach być także implementacją wzorca architektonicznego aplikacji trójwarstwowej

Podsumowanie

Architektura trójwarstwowa jest prawdopodobnie najlepiej znanym wzorcem architektonicznym. Jest ona całkiem niezłą abstrakcją większości systemów. W końcu prawie każda aplikacja ma interfejs użytkownika, logikę biznesową i jakiś dostęp do danych. Niestety w dzisiejszych czasach termin ten przestał być użyteczny w komunikacji: jest on zbyt obszerny i rozmyty.

Niedawno miałem przyjemność uczestniczyć w pierwszym spotkaniu Krakowskim spotkaniu inicjatywy NoSQL Summer. Zainteresowała mnie, przede wszystkim, forma spotkań — dyskusje dotyczące przeczytanych “lektur obowiązkowych”. Skojarzyło mi się bardziej z dyskusyjnym klubem filmowym, niż typową technologiczną juzergrupą. Postanowiłem się więc wybrać. Nie żałowałem.

Organizacji krakowskich spotkań podjął się Adam Pohorecki. Dzięki temu organizacyjnie wszystko było zapięte na ostatni guzik. Miłym dodatkiem było piwo sponsorowane przez Lunar Logic.

Spotkanie przybrało ostatecznie formę wymiany doświadczeń dotyczących różnych baz nierelacyjnych. Oto garść zebranych przeze mnie naprędce wniosków:

Mamy do czynienia z prawdziwym wysypem baz nierelacyjnych. Chyba każdy szanujący się programista za punkt honoru ma napisanie swojej (zupełnie jak niegdyś z kontenerami Dependency Injection).

• Poszczególne bazy nierelacyjne różnią się podejściem do replikacji/klastrowania.
• Najbardziej znany w Krakowie jest CouchDB.
• Temat NoSQL jest raczej obcy środowsiku .NET. Smutne.
• Częstym problemem z bazami nierelacyjnymi jest duży apetyt na przestrzeń dyskową.
• Bazy nierelacyjne są już od dawna wykorzystywane produkcyjnie, nawet w Krakowie.
• Transakcje obejmujące modyfikacje kilku dokumentów to ZŁO.
• API baz nierelacyjnych jest bardziej zbliżone do sposobu działania ich mechanizmów składowania danych
• Bazy nierelacyjne wymagają większej świadomości i wiedzy od dewelopera, ale w zamian oferują większe możliwości wpływania na zachowanie mechanizmu składowania danych (np. rozwiązywanie konfliktów.

Kolejne spotkanie z cyklu NoSQL Summer już w najbliższą środę w siedzibie Lunar Logic (Krasińskiego 17/5). Temat: map/reduce. Więcej informacji można uzyskać za pośrednictwem grupy google Kraków NoSQL Summer. W imieniu organizatorów, zapraszam.

Podczas 58. spotkania Krakowskiej Grupy Developerów .NET miałem przyjemność poprowadzić prezentację pt. “Domain Driven Design, czyli programowanie przez modelowanie”. Ponieważ zakładam, że nie wszyscy jesteście z Krakowa i uczestniczyliście w spotkaniu, pozwolę sobie opisać o czym mówiłem. Prezentację możecie obejrzeć lub ściągnąć (format pptx) stąd (via SlideShare), a przykłady w kodzie stąd.

Rozwiązywanie problemów

Na początku chciałbym skontrastować “klasyczne” podejście do rozwiązywania problemów z podejściem wykorzystującym model. Można to zilustrować następująco:

Podejście klasyczne

Podejście z wykorzystaniem modelu

W wersji klasycznej programista implementuje bezpośrednio wymagania, tak jak zostały one spisane przez analityka (zwykle w formie 10/100/miliona linii “The system shall…”). Dobrze, jeśli w ten proces wpleciona jest pętla sprzężenia zwrotnego, która sprawia, że implementacja pierwszych wymagań ma wpływ na dalszy przebieg procesu analizy.

W podejściu “Domain-Driven” tak naprawdę nie istnieją role analityka i programisty. Istnieje tylko jedna rola — modelarz. Modelarz zajmuje się budową modelu rzeczywistości użytecznego w rozwiązaniu konkretnego problemu. Współpracuje on bardzo blisko z ekspertami dziedzinowymi, przetwarzając posiadaną przez nich wiedzę na spójny, niesprzeczny, a co najważniejsze, wykonywalny, model. Dopiero na bazie tego modelu tworzone jest ostateczne rozwiązanie. Możemy odnaleźć dwie pętle sprzężenia zwrotnego: pierwsza dotyczy samego modelu (im więcej modelarz stworzył, tym lepiej rozumie problem), a druga modelu w kontekście aplikacji (im więcej wiemy, co ma robić aplikacja, tym lepiej wiemy, które aspekty należy dokładniej modelować).

Cechy modelu

Skoro już wiemy, do czego przydaje się model, warto się zastanowić jakie cechy powinien posiadać dobry model. Oto moja osobista lista w kategorii “model powinien być”:

Użyteczny

Nie ma sensu budowa idealnego modelu rzeczywistości, ponieważ byłby on tak samo skomplikowany jak ta rzeczywistość. Z punktu widzenia złożoności obliczeniowej jest to niewykonalne. Znane powiedzenie mówi, że wszystkie modele są błędne, ale niektóre są użyteczne. Model, który budujemy na potrzeby naszego systemu powinien odzwierciedlać tylko ten fragment rzeczywistości, w ramach którego działa ten system i tylko pod kątem czynności bezpośrednio związanych z jego funkcjonowaniem.

Hermetyczny

Model jest kodyfikacją pewnych reguł rządzących modelowanym wycinkiem rzeczywistości. Reguły te nie powinny wyciekać z modelu, co oznacza, że jego klienci (użytkownicy) nie powinni musieć o nich wiedzieć. Przykładem może być reguła, że w modelu programu HR pracownik może mieć w danym momencie co najwyżej jednego pracodawcę. To model, a nie klient, powinien zadbać o to, aby przy zmianie pracy pracownik został odłączony od poprzedniego pracodawcy.

Podatny na modyfikacje

Jest to sprzeczne z zasadą Open-Closed Principle (open for extensions, closed for modifications), jednak w przypadku modeli sprawdza się bardzo dobrze. Aby model był nadążał za szybko zmieniającą się rzeczywistością, sam także musi się zmieniać. Nie chcemy przecież, aby skostniały model aplikacji był dla organizacji jej używającej hamulcem rozwoju, prawda?

Zrozumiały

O sukcesie modelu i całego projektu decyduje, czy wszyscy jego interesariusze rozumieją przestrzeń problemu. Model powinien stanowić podstawę porozumienia i bazę dla wszędobylskiego języka (ubiquitous language) służącego do komunikacji między wykonawcami systemu (ludźmi technicznymi), a ekspertami dziedzinowymi. W dzisiejszych czasach języki programowania takie, jak C#, są na tyle elastyczne, że pisanie kodu (modelu) tak, aby był zrozumiały dla nieprogramistów nie stanowi już większego problemu.

Wydajnie implementowalny

Mimo, iż model nie powinien być zależny od jakiejkolwiek konkretnej technologii, powinien jednak być (w jakiejś technologii) wydajnie implementowalny. Nie chcemy być zależni od NHibernate czy innego ORM-a, jednak akceptowanie faktu, że model będzie przechowywany trwale w jakiejś relacyjnej bazie danych za pośrednictwem jakiegoś ORM-a pozwala zoptymalizować wiele kwestii. Nie ma sensu udawać niezależności od wszystkich aspektów technologii.