Binary Thoughts

Pięć praktyk usprawniających Code Review

Tue, 04 Sep 2018 07:30:00 -0500

Zwinność polega na ciągłej poprawie. Prowadzimy retrospektywy, poprawiamy cykl życia aplikacji, przyspieszamy dostarczanie nowych wersji aplikacji, sprawiamy, że nasza praca jest bardziej przejrzysta. Wreszcie poprawiamy jakość naszego kodu.

Najsłynniejszą praktyką poprawinia jakości kodu jest Code Review. Code Review jest procesem weryfikacji i ulepszania kodu. Proces przeglądania kodu ma istotny efekt uboczny - propaguje dobre rozwiązania i uczy zespół nowych technik programowania. Code Review ma wiele odmian. Możesz używać narzędzi do porównywania przyrostu kodu i współdzielenia komentarzy lub przejrzeć zmiany razem z autorem kodu i wprowadzić poprawki na żywo.

Będę się posługiwał głównie angielską nazwą Code Review - przegląd kodu i inne tłumaczenia rzadko funkcjonują w branży. Szkoda.

Pułapki Code Review

Kiepskie przeglądy kodu wpływają negatywnie na zespół i mogą prowadzić do obniżenia jakości oprogramowania. Dlaczego? Code Review jest narzędziem komunikacyjnym. Ludzie są podatni na emocje i popełniają błędy. Połącz kropki.

Jeżeli jesteś niechlujny, kod z biegiem czasu będzie zamieniał się w spaghetti. Jeżeli jesteś zbyt szczegółowy, wpadniesz w niekończącą się spiralę odrzucania zmian, obrażania się, a w konsekwencji zepsujesz integralność zespołu. W jaki sposób unikniesz tych problemów? Oto garść porad:

Ustal wasze cele przeglądów kodu i nadaj im priorytety.
Bądź dokładny.
Dawaj dobry przykład i motywuj innych.
Zautomatyzuj ile się da.
Integruj zmiany tak często, jak to tylko możliwe.

Ustal wasze cele przeglądów kodu i nadaj im priorytety

Przegląd kodu nie naprawi wszystkich wad w waszym kodzie. Musicie skupić się na najistotniejszych rzeczach. Jaka jest największa wartość z Code Review? Na to pytanie nie istnieje uniwersalna odpowiedź. Jest to zależne od rodzaju projektu, cyklu życia oprogramowania i składu zespołu. Przykładowo, jeśli pracujesz nad krytycznym oprogramowaniem sieciowym, twój zespół może bardziej cenić wykrywanie podatności niż zwiększanie czytelności kodu. Gdy uporządkujecie cele, możecie położyć nacisk na ich realizację. Lista celów może również podkreślać złe praktyki Code Review, które chcecie porzucić lub rzeczy, które są automatycznie weryfikowane przez narzędzia.

Porządkowanie celów możecie przeprowadzić następująco:

wypiszcie wszystkie cele i korzyści płynące z przeglądów kodu,
wypiszcie wszystkie sytuacje, których chcecie unikać podczas Code Review,
indywidualnie oceńcie istotność każdego z celów,
zapiszcie cele w widocznym miejscu, aby każdy miał do nich łatwy dostęp.

Uporządkowana lista może wyglądać następująco:

naprawienie wadliwej architektury,
naprawienie problemów wydajnościowych,
zweryfikowanie zmienionych API,
poprawienie czytelności kodu,
rozpowszechnienie dobrych praktyk i spójnych zasad pisania kodu,
poprawienie i uspójnienie nazw,
naprawienie błędów logiki aplikacji,
wyeliminowanie podatności,
poprawienie literówek,
poprawienie niespójności w stylu programowania,
~~pośmianie się z głupot napisanych w kodzie~~,
~~spędzenie czasu na czymś innym niż programowanie~~.

Do oceny wartości możecie skorzystać z arkusza kalkulacyjnego. Może to przybrać taką postać:

Przykładowy arkusz priorytetyzacji celów Code Review

Bądź dokładny

Gdy znajdziesz wadę w przeglądanym kodzie lub dokumentacji, możesz napisać krótki komentarz dla autora: “napraw to”. Możesz również opisać:

Co jest nie tak z daną zmianą?
Jak zmiana oddziałowuje na całą aplikację?
W jaki sposób możecie naprawić problem?

Które podejście jest lepsze? Ogólną zasadą jest udzielenie odpowiedzi na trzy powyższe pytania. Odpowiadając na pytania, w znaczący sposób podniesiesz komfort pracy z twoimi komentarzami. Ten komfort jest bardzo ważny, szczególnie jeżeli pracujesz w rozproszonym zespole i nie możecie w dowolnym momencie porozmawiać w cztery oczy.

Twoje skupienie jest ograniczone. Długie sesje przeglądania cudzych zmian sprawią, że będziesz mniej dokładny. Mógłbyś zapytać: ile linii kodu jestem w stanie przejrzeć w ciągu jednego dnia? Nie ma na to dobrej odpowiedzi. Projekt jest podzielony na funkcje, klasy, moduły, subaplikacje. Fragmenty projektu mają różną złożoność. Członkowie zespołu mają różne doświadczenia i w różny sposób się z nimi kooperuje.

Możecie ustalić limit przejglądanych linii kodu na dzień, jednakże utrudni to zobaczenie pełnego obrazu zmian. Przejrzyjcie cele, które ustaliliście i podejmijcie decyzję, czy limit ma zastosowanie w waszym projekcie. Jeżeli wielkość zmian przyprawia cię o zawroty głowy, spróbuj skupić się na pojedyńczym celu z góry listy, ukończ go i przejdź do kolejnego. Jeśli używacie mechanizmu Pull Request, może warto podzielić zmiany na kilka PRów?

Dawaj dobry przykład i motywuj innych

Przeglądanie kodu jest procesem komunikacyjnym. Ty komunikujesz potencjalne wady w kodzie i dokumentacji. Twój współpracownik komunikuje, czy zgadza się twoim punktem widzenia. Brzmi prosto? Niestety, Code Review może się zrobić bardzo nieprzyjemne, gdy emocje wezmą nad wami górę. Z emocjami związanych jest kilka problemów.

Po pierwsze, deweloperzy są często przywiązani do swoich metod pracy, rozwiązań i wprowadzonych zmian. Na pewno kojarzysz poniższy obrazek.

Jeżeli zaczniesz zmuszać współpracowników do wprowadzenia twoich poprawek, koledzy nastawią się defensywnie i w niedługim czasie będziecie się kłócili o marginalne rzeczy, np. spacje kontra tabulacje. Ty wiesz, że masz rację. Twój kolega wie, że ma rację. Oboje się mylicie. Jaki jest skutek takiej kłótni? Na pewno zmarnowany czas i większe napięcie między wami.

Drugim problemem jest fakt, że deweloperzy przeglądają kod jakby byli kompilatorami. Próbujesz znaleźć wszystkie potencjalne błędy i czekasz, aż autor zmian je naprawi. Pracując w ten sposób, będziesz czepiał się drobnych błędów. Nie zauważysz za to istotnych problemów, które uderzą ciebie i resztę zespołu po czasie.

Kolejny problem jest również związany z trybem żywego kompilatora. Jeżeli autor zmian nie wprowadzi wszystkich proponowanych przez ciebie poprawek, ty nie zaakceptujesz zmian. Komentarze w Code Review powinny sprawiać, że produkt staje się lepszy. Produkt staje się lepszy, jeśli zespół staje się lepszy. Nie naciskaj na kolegów zbyt mocno podczas proponowania alternatywnych rozwiązań. Jeśli będziesz za bardzo naciskał, szybko okaże się, że twoje komentarze są traktowane jako zbyt rygorystyczne i ignorowane. Jeśli tak się stanie, zmarnowałeś tylko swój swój czas.

Produktywne przeglądanie kodu oznacza usprawnianie procesu krok po kroku. Chcesz lepszych wrażeń podczas przeglądania kodu lub dostawania lepszego feedbacku do twojego kodu? Zacznij od poprawienia swojego podejścia. Jeżeli będziesz trzymał się poniższych zasad, będziesz szerzył pozytywne i profesjonalne podejście w swoim zespole. Zasady są proste:

Nie traktuj uwag do kodu osobiście.
Komplementuj dobre rozwiązania.
Stopniowo podnoś umiejętności i wiedzę swoich współpracowników.

Zautomatyzuj ile się da

Code Review wymaga bardzo dużego zaangażowania. Na szczęście istnieje wiele narzędzi, które ściągną część pracy z twoich barków. Wiele problemów z kodem zostanie wykrytych dzięki zastosowaniu analizatorów kodu. Niektóre analizatory pokazują niespójności w stylu kodu. Inne wykryją potencjalne podatności lub problemy wydajnościowe. Jeszcze inne znajdą literówki i słowa zabronione w dokumentacji twojego publicznego API.

Jeśli szukasz narzędzi dla stosu .NET/JavaScript, mam dla ciebie kilka propozycji:

StyleCop.Analyzers - narzędzie dla kodu C#, które wyszukuje problemów ze stylem kodu,
ESLint - narzędzie dla kodu JavaScript, które określa dopuszczalny styl kodu (np. wymusza brak średnika na końcu linii),
SonarQube - narzędzie ciągłej integracji wyszukujące popularne problemy z kodem (np. duplikacja, podatności) w różnych językach,
własny analizator .NET - możesz napisać własny analizator kodu .NET oparty o kompilator Roslyn, który będzie działał tak, jak StyleCop.Analyzers, ale będzie skupiał się na twoich specyficznych potrzebach.

Pamiętaj, że automatyzacja jest ma większą wartość, jeśli działa tak samo na każdej maszynie deweloperskiej oraz na serwerze CI.

Integruj zmiany tak często, jak to tylko możliwe

Jednym z większych problemów Code Review są zbyt duże zmiany do przejrzenia. Przeglądanie dwóch tygodni cudzej pracy nigdy nie należy do najprzyjemniejszych. Rozwiązanie na zbyt duże Pull Requesty jest proste - wystawiaj je częściej. Możesz wydzielić ze swojego zadania fragmenty, których zaimplementowanie nie wpłynie na działanie aplikacji (np. backend do strony, która jeszcze nie jest zrobiona). Możesz również używać feature toggle - zostawiasz daną funkcję aplikacji wyłączoną, dopóki nie będzie w pełni wykonana.

Integrowanie fragmentów zmian wymaga większego rygoru pracy. Programy mają to do siebie, że bardzo łatwo się psują od wprowadzanych zmian. Częste integrowanie zmian w kodzie będzie skuteczne, jeżeli będziesz posiadać dobre testy automatyczne. Najczęściej potrzebne są testy o różnym poziomie granularności - testy jednostkowe, testy integracyjne, testy akceptacyjne, czasem różnież testy end-to-end. Twój mainline (np. branch develop) powinien być utrzymywany w stanie gotowości do wydania. Nie oznacza to, że nie może zawierać kodu z zadań, które nie zostały zaakceptowane. Po prostu ten kod powinien być wykonywany na produkcji przed ukończeniem całości.

Wnioski

Istnieje wiele technik usprawniających Code Review. Pamiętaj jednak, że proces przeglądania kodu musi być dopasowany do potrzeb twojego produktu i do twojego zespołu. Nie zapominaj również, że Code Review jest procesem komunikacyjnym - im lepiej wyjaśnisz swój punkt widzenia, tym więcej wartości wyniknie z CR. W celu zmniejszenia zakresu konwersacji, zautomatyzuj weryfikację powtarzalnych rzeczy, na które się zgodziliście całym zespołem deweloperskim.

Efektywny Daily Scrum - nie marnuj kwadransu ze swojego poranka

Mon, 16 Jul 2018 03:00:00 -0500

Daily Scrum jest jednym z obowiązkowych wydarzeń w Scrumie. Jednocześnie to spotkanie jest najczęściej wykonywane ze względu na obowiązek - bez zrozumienia celu. Czy znasz poniższy scenariusz?

Wchodzisz rano do biura. Zaspany, z nienawiścią w oczach patrzysz na nich - ludzie z zespołu. Wybija godzina zero - stajecie w kółku i składacie raport. Marian nie zrobił tego, co zaplanował wczoraj, ale znalazł śmieszny fragment kodu. Zbyszek zapłakał nad swoim losem przy współpracy z innym działem. Janusz scrolluje kwejka na telefonie. Dalej nie pamiętasz, bo odpłynąłeś. Wybudzony przez Scrum Mastera bełkoczesz coś o tym, że będziesz kontynuować to, co wczoraj. Wszyscy kiwają głową. Kończycie po 20 minutach, rozchodzicie się do biurek. Nikt nie wie, co przyniesie następny dzień.

Jeżeli twoje wizyty w pracy wyglądają w ten sposób, to znak, że Ty i twoi koledzy marnujecie każdego dnia część swojego życia. Zobacz, jak przestać marnować cenny czas podczas Daily Scrum - zmień to spotkanie w najważniejszy punkt swojego dnia.

Daily Scrum vs Standup

Z jakiegoś powodu przyjęło się, że poranne spotkania nazywa się standupem. Każdy ma stać, bo pomaga to przyspieszyć spotkanie. Standup nie jest praktyką scruma - wywodzi się z metodyki Extreme Programming. Scrumowym odpowiednikiem jest Daily Scrum. Forma tego spotkania jest podobna. Nie ma jednak wymogu stania. Argumentowanie, że spotkanie powinno się odbywać na stojąco to próba wykonania magicznej sztuczki naprawiającej niedociągnięcia.

Do czego służy Daily Scrum?

Daily Scrum służy do ustalenia strategii na następne 24 godziny. Wydarzenie to daje możliwość inspekcji wykonanego postępu i adaptacji planu. Planowanie jednej doby pozwala na uszycie dużo dokładniejszego planu niż planowanie całego sprintu.

Spotkanie wymaga większej szczegółowości, a więc również większego zaangażowania. Każdy uczestnik musi pozostać przytomny przez całość spotkania. Z tego powodu spotkanie musi trwać maksymalnie 15 minut.

Daily Scrum wymaga skupienia, co wymusza rygorystyczne podejście. Spotkanie musi zawsze odbywać się o jednej porze. Najlepiej jest to zrobić na początku dnia, jednak nie jest to wymóg. Bardzo ważne jest pilnowanie godziny rozpoczęcia. Spóźnianie się powoduje marnowanie czasu reszty zespołu. Jeśli nie zdążyłeś na początek Daily, to straciłeś ty i straciła reszta zespołu. Nie pogarszaj stanu. Nie przeszkadzaj innym i nie snuj opowieści o spóźnionym tramwaju. Włącz się do planowania rzeczy, które nie były jeszcze omawiane.

Kto powinien uczestniczyć w Daily

Daily Scrum jest dla zespołu deweloperskiego. Nie, nie dla waszego przełożonego, Scrum Mastera, właściciela produktu czy Pana Kanapki. To wy musicie zadbać o utrzymanie poprawnej formy.

Obecność zespołu deweloperskiego jest obowiązkowa. Scrum Master ma jedynie zapewnić, że spotkanie się odbędzie. Pozostali aktorzy - właściciel produktu, klient, szef etc. mogą być gośćmi. To od was zależy, czy pozwolicie im na wzięcie udziału w spotkaniu.

Zmień swoje nawyki

Efektywne przeprowadzanie Daily zacznij od zmiany swoich nawyków:

przygotuj się do daily,
słuchaj innych,
mów zwięźle.

Gdy poprawisz swoje nastawienie, część członków zespołu deweloperskiego zacznie Cię naśladować. Pozostałych będziesz musiał przekonać do nowego podejścia. Nie możesz tego wymusić - wszyscy musicie rozumieć wartość i cel spotkania.

Przygotuj się do daily

Spotkanie będzie tym efektywniejsze, im lepiej będziecie do niego przygotowani. Poświęć pięć minut przed spotkaniem. Zbierz aktualny obraz sprintu. Sprawdź jeszcze raz nad czym aktualnie pracujecie. Zobacz w jakim stanie są wszystkie zadania. Przeczytaj komentarze, jeżeli istnieją. Dzięki temu będziesz znał kontekst tego, o czym mówią koledzy. Lepiej doradzisz lub pomożesz w spełnieniu celu. Wykryj potencjalne zatory - środowiska testowe i czas ludzi spoza zespołu są ograniczonymi zasobami. Przemyśl, co chcesz powiedzieć o zadaniach, które wykonujesz. Podsumuj stan w porównaniu do poprzedniej doby. Zbierz istotne problemy, z którymi zespół może Ci pomóc. Zaplanuj następny krok.

Scrum Guide definiuje trzy pomocnicze pytania, które pomogą ci w przygotowaniu się.

Przebieg spotkania jest ustalany przez Zespół Deweloperski. Może ono być przeprowadzane na wiele sposobów, jeśli tylko pozostaje poświęcone postępom prac w kierunku osiągnięcia Celu Sprintu. Niektóre Zespoły Deweloperskie wykorzystują pytania, inne prowadzą dyskusje. Oto przykład pytań, które mogą być wykorzystywane podczas tego spotkania:

Co zrobiłem wczoraj, co pomogło Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?

Co zrobię dzisiaj, co pomoże Zespołowi Deweloperskiemu przybliżyć się do osiągnięcia Celu Sprintu?

Czy widzę jakiekolwiek przeszkody mogące uniemożliwić mi lub Zespołowi Deweloperskiemu osiągnięcie Celu Sprintu?

Przykładowe pytania mają pomóc ci w uporządkowaniu wypowiedzi. Nie musisz, a nawet nie powinieneś mechanicznie udzielać na nie odpowiedzi.

Słuchaj innych

Celem spotkania jest ułożenie planu. Dokonanie tego jest możliwe tylko wtedy, jesli słuchasz innych. Twoim głównym zadaniem na Daily jest słuchanie. Telefon zostaw przy biurku. Tematy pozasprintowe odłóż na dalszy plan. Twoim głównym zadaniem jest słuchanie. Słuchanie jest twoim głównym zadaniem. Zadaniem twoim jest słuchanie. Powtórz sobie to jeszcze kilka razy. Byle nie na Daily, bo na Daily twoim głównym zadaniem jest słuchanie. Jutro kolega może wpaść pod autobus albo pojechać na wakacje. Bądź na to gotowy. Zapamiętaj, czym się zajmuje.

Słuchanie pozwoli ci na zaktualizowanie swojej wiedzy o aktualnym stanie sprintu oraz wykrycie nieprawidłowości i rozbieżności.

Mów tak zwięźle, jak to możliwe (ale nie zbyt zwięźle)

Zasadniczo powinieneś się odzywać tylko w trzech sytuacjach, gdy:

wykryjesz poważną nieprawidłowość,
jesteś w stanie pomóc w rozwiązaniu problemu,
omawiacie zadanie, nad którym pracujesz.

Przejęzyczenie się nie jest proważną nieprawidłowością. Poważną nieprawidłowością jest:

niespójność w jakiejkolwiek postaci,
oddalenie się lub brak dążenia od celu sprintu,
nieuzgodnione obniżenie jakości projektu,
naruszanie formy Daily Scruma.

Niespójność występuje, gdy zadanie lub komentarze mówią coś innego, a poprzedniego dnia plan zupełnie różnił się od aktualnie omawianego stanu. Oddalenie się od celu sprintu pojawia się przy refaktoryzowaniu czegoś “przy okazji” i prowadzeniu nieudokumentowanych prac. Obniżenie jakości projektu może być cichym zaciąganiem długu technicznego, brakiem testów, brakiem dokumentacji lub nieprawidłowym zaprojektowaniem funkcji systemu. Jeśli ktoś dąży do wysadzenia sprintu w powietrze - reaguj, zanim będzie za późno!

Jeśli już musisz coś powiedzieć - zastanów się, czy sam byś chciał to usłyszeć. Nie marnuj czasu innych. Twoja wczorajsza impreza i alkoholowy oddech powodują dekoncentrację. Daruj sobie opowiadanie o tym. Nie opowiadaj też o drobnicy. To, że wczoraj przez pół godziny nie umiałeś napisać kompilującego się kodu, nie interesuje nikogo poza tobą.

Jeśli rzecz nie dotyczy tylko ciebie, mów w liczbie mnogiej - mamy problem, zrobiliśmy postęp, powinni nas za to wywalić. Jesteście zespołem, nie działacie osobno.

Jak przeprowadzić Daily Scrum?

Ustalcie stałe miejsce i czas spotkania. Unikniecie w ten sposób niepotrzebnych pytań “Gdzie?” i “O której?”. Do efektywnego przeprowadzenia Daily Scruma musicie wybrać miejsce, w którym nikt wam nie będzie przeszkadzał. Jeżeli nieproszeni goście was prześladują, zamknij drzwi na klucz. Kwadrans nikogo nie zbawi, a twojemu zespołowi da spokój i izolację. Zamiast mówić kolejno o waszym prywatnym stanie prac, przejdźcie przez zadania. Przechodzenie po zadaniach sprawdza się dużo lepiej niż przechodzenie po ludziach - skupiacie się na celu sprintu i dostarczaniu wartości jako zespół. Zacznijcie od zadań najbliżej ukończenia - domknięcie aktualnych tematów jest ważniejsze od otwierania nowych.

Utrzymanie się w ramach czasowych jest bardzo istotne. Kwadrans to wbrew pozorom bardzo dużo czasu. Jeżeli omówiliście wszystko w mniej niż 15 minut - świetnie. Jeżeli zbliżacie się do końca kwadransu i jesteście dalej w połowie - delikatnie pospiesz innych.

Do czego prowadzi naruszanie formy Daily Scruma?

Jeżeli przychodzisz na daily scrum spóźniony, nieprzygotowany i opowiadasz o rzeczach niezwiązanych z realizacją celu sprintu, prowadzisz do zmniejszenia motywacji zespołu i wiary w sensowność tego spotkania. Taki sam efekt odniesiesz ignorując innych i przerywając im bez powodu. Konsekwencją powyższych zachowań jest trudność w połączeniu zadań, przejmowania pracy innych programistów oraz tworzeniu poprawnie zintegrowanego produktu. W efekcie w oprogramowaniu pojawiają się błędy, a klient staje się marudny. Nikt nie chce mieć marudnego klienta.

Podsumowanie

Jesteś zmęczony bezsensownym spotkaniem, które zmusza Cię do stania w kółku i spowiadaniu się na głos przed samym sobą? Zacznij od zrozumienia celu Daily Scruma. Przed każdym Daily poświęć pięć minut na przygotowanie się. Przygotowanie się pozwoli Ci lepiej wysłuchać resztę zespołu. Gdy będziesz mówił, sformułuj wypowiedź tak, żeby dawała zespołowi wartość. Pamiętaj, że najlepsze efekty daje zarażanie innych dobrym przykładem.

Czy Twój zespół praktykuje Daily Scrumy lub Standupy? Jakie reguły stosujecie? Podziel się w komentarzu.

Jak wygląda i dlaczego warto mieć zwinny zespół?

Mon, 09 Jul 2018 05:00:00 -0500

Zespół to grupa fachowców mająca wspólny cel. Jakie cechy sprawiają, że zespół pracuje wydajniej, a jego członkowie spełniają się zawodowo?

Ludzie są zwierzętami stadnymi. Potrzebują wzajemnej aprobaty oraz odnoszenia wspólnych zwycięstw. Żeby odnosić zwycięstwa, musimy być przygotowani na nowe sytuacje, np. skierowanie produktu do nowej grupy użytkowników. Zespół zawsze gotowy na nowe sytuacje jest zespołem zwinnym (agile team). Zwinny zespół lepiej radzi sobie w zmieniającej się rzeczywistości - rzeczywistości, która nas otacza.

Zwinny zespół posiada co najmniej trzy cechy:

współdzieli cel, sukcesy i porażki,
organizuje swoją pracę samodzielnie,
amortyzuje braki w składzie i zmiany personalne.

Wspólny cel, wspólne sukcesy, wspólne porażki

Podstawową cechą jakiegokolwiek zespołu jest posiadanie wspólnego celu. Cel jest kompasem projektu - określa dokąd idziecie. Posiadając cel, możecie dostosowywać zakres projektu, czas jego trwania lub jakość wykonania. Bez wspólnego celu podejmujecie losowe decyzje bez solidnych podstaw.

Każdy sukces zespołu i każda porażka jest waszym wspólnym mianownikiem. Żaden sukces nie jest indywidualny. Tak samo żadna porażka. Nie ukończyłeś zadania - ukończyliście je wspólnie. To nie kolega Zbyszek dostarczył klientowi zbugowaną fukcję - wszyscy daliście ciała. Każdy z was miał okazję sprawdzić kod i porozmawiać o problemach, więc nie szukajcie kozła ofiarnego. Jeżeli nie mieliście okazji - macie wspólny problem z kooperacją.

Jeżeli udało się wam sprostać trudnemu zadaniu, celebrujcie to. Wspólne wyjście po pracy na kilka głębszych na pewno skończy się historią opowiadaną (w różnych wersjach) przez następne kilka miesięcy. Tak właśnie powstają zgrane zespoły. Gdy nie wszystko poszło po waszej myśli, zastanówcie się wspólnie nad przyczynami. Co pięć głów to nie jedna. Gdy uda wam się zdefiniować przyczyny porażki, określcie akcje do podjęcia. W ten sposób nie sparzycie się drugi raz na tym samym.

Samodzielna organizacja pracy

Podążanie za pierwotnym planem rzadko kończy się dotarciem do celu. Im więcej czynników zewnętrznych wpływa na waszą pracę, tym większa szansa, że oddalicie się od osiągnięcia celu. Dlatego kluczowe jest reagowanie na zmiany zaraz po ich wykryciu, zanim ich skutki się zbyt rozrosną.

Zamiast czekać, aż ktoś zauważy i naprawi problem - zrób to sam. Opowiedz wszystkim o sytuacji, zaproponuj rozwiązanie, nakłoń ludzi do wyrażenia swojej opinii i wprowadź zmiany, jeżeli wszyscy tego chcecie. Podejście samodzielnego reagowania na zmiany nazywa się podejściem proaktywnym. Po przeciwnej stronie mamy podejście reaktywne - bierne oczekiwanie na bodziec, np. decyzję przełożonego.

Podejście proaktywne ma kilka zalet:

krócej czekasz na dostosowanie się zespołu lub produktu do sytuacji,
rozwiązując problem bezpośrednio u jego źródła, rozwiązujesz go dużo lepiej,
w zespole nie powstają napięcia związane z trwaniem w demotywującej sytuacji,
zarażasz zespół swoim podejściem, przez co wszyscy działacie coraz efektywniej.

Przykłady podejścia proaktywnego:

Widzisz, że infrastruktura projektu jest ciężka w zrozumieniu i droga w utrzymaniu. Słyszałeś już kilka razy podobne opinie członków zespołu i interesariuszy. Przygotowujesz kilka sposobów na usprawnienie infrastruktury - zaczynasz od najtańszych we wprowadzeniu i dających największe rezultaty. Określasz konsekwencje pozostania w obecnym stanie oraz konsekwencje poszczególnych rozwiązań. Rozmawiasz o nich z zespołem deweloperskim, przełożonym, klientem. Wspólnie ustalacie które działania chcecie podjąć w pierwszej kolejności.

W zespole znajduje się czarna owca - osoba, która torpeduje prace zespołu i nie angażuje się w dostarczanie wartości do projektu. Człowiek jest nowy w zespole i nikt nie chce na niego naciskać. Widzisz jednak, że rośnie napięcie wśród pozostałej części zespołu. Na najbliższej retrospektywie mówisz otwarcie o sytuacji i pytasz świeżaka, w jaki sposób reszta zespołu może mu pomóc. Szukasz rozwiązania, które zadowoli wszystkich - takie rozwiązanie bardzo często istnieje. Jeżeli jednak go nie ma, a czarna owca dalej psuje owoce waszej pracy, mówisz o całej sytuacji przełożonemu i wymagasz od niego podjęcia działań.

Jeżeli nie działasz proaktywnie, to działasz reaktywnie. Podchodząc biernie do problemów możesz spóźnić się z podjęciem akcji. Produkt przestanie pasować do rynku. Koszt utrzymania infrastruktury sprawi, że zarząd zamknie projekt. Czarna owca doprowadzi do fali zwolnień. W podejściu proaktywnym to ty kontrolujesz sytuację. W podejściu reaktywnym to sytuacja kontroluje ciebie.

Projekt - wspólna własność całego zespołu

Projekt jest waszą wspólną własnością. Cały kod i dokumentacja jest waszą wspólną własnością. Zadania i ich opisy są waszą wspólną włanością. Wszystkie artefakty wytarzane w projekcie (kod, dokumentacja, zadania, pomysły etc.) przechodzą przez kilka par rąk, zanim zostaną wdrożone. Nic nie jest dziełem pracy jednej osoby.

Wpólna własność projektu oznacza:

mniej nietrafionych pomysłów do zrealizowania,
większe zrozumienie celu,
lepiej doprecyzowane wymagania,
większa odporność zespołu na bus factor.

Wspólny kod

Aby kod był wspólną własnością całego zespołu, konieczne jest zrozumienie wymagań zadania oraz co najmniej wykonanie przeglądu kodu (code review). Programujecie w parach? Tym lepiej.

Jeżeli nie będziecie się wymieniać obszarami projektu i przeglądać kodu kolegów, bardzo szybko się okaże, że wytworzyliście silosy kompetencyjne. Oznacza to tyle, że jedna dziedzina projektu (lub fragment kodu) jest rozumiany i utrzymywany tylko przez jedną osobę. Takie podejście jest tykającą bombą. Eksploduje ona w momencie, gdy zabraknie eksperta kompetencyjnego - na przykład odejdzie z zespołu. Jeszcze gorzej będzie gdy okaże się, że pozostawiony fragment systemu jest kiepskiej jakości, niezrozumiały i nie nadaje się do utrzymania.

Wpólny kod oznacza również, że ludzie spoza zespołu deweloperskiego mogą go modyfikować. Mając jasno określone zasady akceptacji zadania, nic nie stoi na przeszkodzie, żeby właściciel produktu lub scrum master wprowadził zmiany. Programiści nie mają monopolu na programowanie - są do tego jedynie najlepiej przygotowani.

Wspólne zadania

Zadania, które implementujesz jako programista są waszą wspólną własnością. Każdy w zespole powinien wiedzieć jaki jest cel zadania - naczęściej wyraża się to za pomocą opowieści użytkownika (user story, US). Zadanie powinno określać wymagania potrzebne do uznania go za skończone - np. wyrażone w formie kryterów akceptacji (acceptance criteria, AC). Każdy członek zespołu powinien mieć możliwość negocjowania zmian w zadaniu - również w trakcie trwania sprintu. Negocjując zadania jesteście w stanie dostarczyć więcej przydatnych rzeczy. Jeżeli spełnicie cel, możecie uprościć szczegóły. Przykładem uproszczenia szczegółów jest zrealizowanie dużo łatwiejszej implementacji, która zmienia jedynie mało istotne kryteria akceptacji. Każda zmiana musi być uzgodniona z właścicielem produktu (product owner, PO) oraz zaakceptowana przez resztę zespołu. Właściciel produktu nie ma monopolu na tworzenie i spisywanie zadań - jest do tego jedynie najlepiej przygotowany.

Właściciel produktu ma za to monopol na ustalanie priorytetów, o czym warto pamiętać.

Fluktuacja członków zespołu

Projekty wymagające utrzymania spotykają się ze zmianami kadrowymi. Każda zmiana w składzie twojego zespołu spowoduje zaburzenia produktywności i powstanie nowych wyzwań. Nowe osoby trzeba przygotować do bycia członkiem zespołu - nauczyć kultury pracy i pokazać cel. Po starych współpracownikach trzeba wypełnić lukę kompetencyjną. Konieczna może być zmiana zasad, na jakich współpracujecie.

Podsumowanie

Siłą zwinnego zespołu jest zdolność do wspólnego rozwiązywania problemów. Silniejsi podciągają słabszych, słabsi uczą się od silniejszych. Silniejsi poszerzają zakres kompetencji, słabsi ulepszają swoje obecne umiejętności. Pytania słabszych napędzają myślenie silniejszych. Im jesteście lepsi jako zespół, tym lepiej organizujecie pracę i tym bardziej jesteście zadowoleni z jej efektów.

Podstawy pracy zespołowej

Sat, 26 May 2018 09:00:00 -0500

Programista ma znać się na programowaniu. Ale czy to wystarczy do rozwijania stabilnych projektów? Czy programista bez umiejętności miękkich jest wartościowy?

Nie.

Po pierwsze, bardzo rzadko zdarza się, aby projekt był rozwijany przez jednego jajogłowego, który w piwnicy wyprodukuje cały kod. Jeżeli pracujesz nad czymś większym niż kalkulator z 4 operacjami, prawdopodobnie robisz to we współpracy z innymi programistami. Od ustalania wspólnego technicznego kierunku projektu, aż po codzienne prace na repozytorium, wszystko wymaga dyscypliny i jedności wszystkich członków zespołu. Jedna czarna owca może skutecznie zabić motywację kolegów i korkować pracę.

Po drugie, projekty IT są tworzone dla biznesu. Za wszystkimi działaniami programistów stoją potrzeby i cele interesariuszy. Nawet w projektach kaskadowych (waterfall), na którymś etapie natkniesz się na kogoś niemówiącego językiem technicznym. Nie ma znaczenia, czy to będzie klient, czy kierownik projektu. Jeżeli nie umiesz wyjaśnić działań technicznych używając języka nietechnicznego, redukujesz swoją wartość do małpy klepiącej w klawiaturę.

Czym jest zespół?

Zespół jest zbiorem ludzi mających za zadanie zrealizowanie potrzeb interesariuszy. Nie muszą to być wyłącznie programiści. Właściciel produktu, menedżer projektu, scrum master lub ktokolwiek inny powiązany z celem projektu może być jego częścią. Ludzie w zespole znają się wzajemnie - wiedzą o mocnych i słabych stronach kolegów. Każdy w zespole pomaga innym, aby przybliżyć zespół do wspólnego celu. Członkowie zespołu wzajemnie uzupełniają swoje kwalifikacje. Zespół może ulegać zmianom w trakcie trwania projektu. Zmieniają się jakość i sposoby komunikacji.

Kilka rzeczy może wskazywać na to, że nie jesteś częścią zespołu:

należysz do kilku “zespołów” jednocześnie,
każdy w “zespole” pracuje nad innym projektem,
“zespół” nie ma wspólnego celu,
członkowie “zespołu” mają sztywno przydzielone zadania lub fragmenty projektu i nie wchodzą w silosy kompetencyjne innych.

Na twardo czy na miękko?

Zespoły są mniej lub bardziej zgrane. Mają mniej lub więcej wpływu na kształt projektu. Zwykle jest to związane z wybraną metodyką. Metodyki twarde (np. Waterfall, XPrince) faworyzują formalizację i sztywny podział prac. Najważniejsze jest zrobienie własnego kawałka. Resztą zajmą się inni. Z kolei metodyki miękkie (np. Scrum, Kanban) stawiają na współpracę grupy ludzi w celu wypracowania jak największej wartości.

Metodyki twarde są z pozoru prostsze we wdrożeniu. Sztywne powiązania między ludźmi, dedykowane osoby do tłumaczenia potrzeb biznesu na zadania programistyczne, niezmienny zakres i wizja projektu. Niestety, projekty mają się nijak do założeń metodyk twardych: zakres i wizja projektów nie są stałe. Czasem wynika to ze zmieniających się potrzeb rynku, czasem ze zbyt powierzchownej analizy przed podpisaniem kontraktu.

Metodyki miękkie stawiają na gotowość na zmianę, dzięki czemu są dostosowane do świata rzeczywistego. Wizja projektu jest płynna. Dużo łatwiej sprawdzić pomysł, zanim wejdziemy w niego z pełnym budżetem. Ciągła zmiana jest wyzwaniem i wymaga dużo częstszej i dokładniejszej komunikacji.

Oliwienie trybików

To nie jest tak, że powiecie sobie raz: mamy proces, teraz każdy może się zająć swoją robotą. Proces, podobnie jak kod, rozpada się z upływem czasu. Musicie go nieustannie naprawiać i dostosowywać do obecnych warunków.

Do poprawiania procesu przydatna jest retrospektywa. Jest to spotkanie, na którym omawiacie ostatnie problemy, ale także sukcesy. Dobra retrospektywa pozwala na podnoszenie jakości spotkań, dlatego powinniście ją wykonywać przy zachowaniu wzajemnego szacunku i przestrzegając dodatkowych zasad, np. ustrukturyzowanie spotkania, głosowanie na tematy, wyznaczanie ram czasowych na pojedynczy temat.

Jakość procesu zależy od tego, jak dobrze się rozumiecie. Im lepiej się znacie, tym lepiej się dogadujecie i wspieracie w realizacji projektu. Dlatego warto się czasem wyrwać po pracy i zrobić coś razem. Poza konwencjonalnym piwem w barze, masz szeroki wachlarz możliwości. Najlepiej sprawdzają się gry wymagające zgrania. Możecie pograć w planszówki lub postrzelać do siebie na paintballu albo laser tagu. Nakłoń innych do spróbowania czegoś nowego.

Podsumowanie

Nie ma znaczenia, czy robisz software na twardo, czy na miękko. Tylko rozmowa z ludźmi poprawi Twoje zrozumienie tego co i dlaczego robisz. Wraz z zespołem zdołacie wykonać rzeczy, na które w pojedynkę nie macie szans.

Czy czujesz się częścią zespołu?

Narzędzia programisty: Gulp

Mon, 28 Nov 2016 01:25:00 -0600

Ostatnio pisałem o automatyzacji. Jest to proces wymagający dobrania odpowiedniego narzędzia. Dzisiaj skupię się na jednym z nich - Gulp.

Gulp jest jednym z narzędzi służącym do automatyzacji. Strona projektu opisuje go jako streaming build system. W niektórych miejscach widnieje jako task runner. Zwał jak zwał. Wiele nazw na to samo. Gulp jest zwykle używany do automatyzowania webdevelopmentu. Prawdę mówiąc sam używam go do tego celu, jednak można go wykorzystać w dowolny inny sposób. Musisz mieć jedynie zbiór plików, na których chcesz operować oraz opis tego, co chcesz zrobić.

O tym dlaczego warto automatyzować pisałem w poprzednim poście.

Jak to działa?

Gulp jest narzędziem uruchamianym w środowisku node.js. Co prawda sens robienia aplikacji webowych w node jest mocno dyskusyjny, ale narzędzia na tej platformie są przemyślane. Gulp operuje na strumieniach. Oznacza to, że wszystkie stany pośrednie są przechowywane w pamięci, zamiast zapisywania np. tymczasowych plików na dysku. Gulp jest narzędziem konsolowym, jednak w świecie .NET zadania gulpa można go bez problemu uruchomić z poziomu Visual Studio (od wersji 2015). Gulpa można użyć do wielu zastosowań. Najpopularniejszymi z nich są:

weryfikacja poprawności składni (lintery),
transpilacja LESS/SASS -> CSS,
transpilacja TypeScript/ECMAScript* -> JavaScript,
minifikacja plików CSS/JavaScript/HTML,
zmiana rozmiarów obrazków i optymalizacja kompresji,
kopiowanie plików lub budowanie paczki przed deployem,
deployowanie,
czyszczenie zbudowanych plików.

Konfiguracja

Pracę z Gulpem rozpoczynamy od instalacji Node.js, npm i samego Gulpa. Node.js i npma najszybciej zainstalujemy za pomocą Chocolatey (Windows), Homebrew (macOS), apt-get (Linux) lub dowolnego innego managera pakietów.

# Windows
choco install nodejs.install

# macOS
brew install node

# Linux
# poradzicie sobie :-)

Następnie przechodzimy do instalacji samego Gulpa. Gulp musi być zainstalowany globalnie w systemie oraz w samym projekcie. Przechodzimy do katalogu projektu, który będziemy automatyzować i wykonujemy:

npm init
# wykonujemy wszystkie kroki
# poszczególne wartości nie będą miały na nic wpływu
# możemy dusić [ENTER] aż do wyjścia z polecenia

npm install -g gulp
npm install --save-dev gulp

Możemy teraz odpalić gulpa

$ gulp
[08:35:10] No gulpfile found

Oczywiście polecenie się posypało. Nie mamy jeszcze opisu żadnego zadania, które chcemy wykonywać. Opis ten umieszczamy w pliku gulpfile.js.

gulpfile.js

Czas na zrobienie pierwszego zadania! Załóżmy, że chcemy zbudować pliki LESS z katalogu /src/less/, zminifikować je i umieścić w dist/css/. Chcemy, aby właściwości CSS były prefixowane w celu zapewnienia wsparcia w przeglądarkach 2 wersje wstecz. Będziemy potrzebowali do tego kilku pluginów. Z konsoli/terminala wykonujemy:

npm install --save-dev gulp-autoprefixer gulp-clean-css gulp-cleancss gulp-concat gulp-less gulp-lesshint gulp-load-plugins through

Mamy wszystko, czego potrzebujemy. Teraz wystarczy dodać plik gulpfile.js:

var gulp = require('gulp'),
    autoprefixer = require('gulp-autoprefixer'),
    less = require('gulp-less'),
    concat = require('gulp-concat'),
    cleanCss = require('gulp-cleancss');

gulp.task('default', () => {
    return gulp.src('src/less/*.less')
        .pipe(less())
        .pipe(autoprefixer({
            browsers: ["last 2 version"]
        }))
        .pipe(concat('main.min.css'))
        .pipe(cleanCss())
        .pipe(gulp.dest('dist/css'));
});

Teraz wystarczy uruchomić zadanie. Zadanie default jest domyślnym zadaniem gulpa, więc nie musimy podawać jego nazwy. Jeżeli jednak chcemy to zrobić, wpisujemy w konsoli/terminalu:

$ gulp default
[09:20:55] Using gulpfile ~/Workspace/gulptest/gulpfile.js
[09:20:55] Starting 'default'...
[09:20:55] Finished 'default' after 19 ms

W ten sposób wygenerował nam się plik main.min.css w katalogu dist/css/.

Był to bardzo prosty przykład. Przyjrzyjmy się czemuś odrobinę bardziej skomplikowanemu.

Zależność zadań

Chcemy zbudować aplikację składającą się z plików LESS, TypeScript i HTML. Chcemy wykonać poszczególne zadania:

lintowanie (weryfikacja składni) plików LESS,
lintowanie (weryfikacja składni) plików TS,
budowanie plików LESS,
budowanie plików TS,
minifikacja zbudowanych plików CSS,
minifikacja zbudowanych plików JS,
minifikacja plików HTML.

Niektóre zadania są od siebie zależne.

Budowanie plików LESS nie ma sensu, dopóki nie przejdzie ich weryfikacja.

Należy przeanalizować, które z zadań mogą być zastosowane bez uruchamiania innych zadań. Zadania nie mogą przekazywać strumienia pomiędzy sobą. W celu przekazania danych pomiędzy zadaniami konieczne jest zapisanie plików na dysku, a następnie ich ponowne załadowanie.

Weryfikacja składni plików LESS ma sens jako osobne zadanie. Minifikacja plików LESS jest zawsze powiązana z ich budowaniem (możemy generować pliki .css i .min.css).

Żeby zauważyć zależności, najłatwiej będzie narysować skierowany pseudograf zadań:

Pseudograf zależności

Zadania, które muszą zostać wykonane przed rozpoczęciem bieżącego zadania podajemy jako drugi parametr funkcji gulp.task():

gulp.task('default', ['build']);

gulp.task('build', ['build:less', 'build:ts'], () => {
    log('Finished build');
});

Obserwowanie zmian w plikach

Pracując nad aplikacją zwykle potrzebujemy ją przebudować po zmianie w plikach źródłowych. Gulp oferuje możliwość śledzenia zmian na plikach, w związku z czym możemy wywołać callback. Warto jest także dodać zadanie budowania aplikacji jako zależność watcha.

gulp.task('watch', ['build'], () => {
    gulp.watch('src/less/*.less', ['build:less']);
    gulp.watch('src/ts/*.ts', ['build:ts']);
});

Ekstrakcja ścieżek i danych dostępowych

W pliku gulpfile.js znajduje się wiele różnych ścieżek. Część z nich służy do przeszukiwania plików źródłowych. Część jest ścieżką dla plików wynikowych. Do tego dochodzą różnego rodzaju dane dostępowe, np. hasła do ftp, klucze do chmury. Żeby zapanować nad tym chaosem, możemy wydzielić ścieżki i dane dostępowe do odrębnych plików. Osobiście ścieżki wyciągam do gulp.config.js, a dane dostępowe do secrets.json.

gulp.config.js

module.exports = function () {
    'use strict';

    const buildPath = './dist/';

    var config = {
        buildPath: buildPath,
        buildCssPath: buildPath + 'css/',

        lessBuildFiles: [
            './src/*.less'
        ],

        lessWatchFiles: [
            './src/**/*.less'
        ]
    };

    return config;
}

secrets.json

{
    "azureBlobStorage": {
        "account": "(...)",
        "key": "(...)",
        "container": "(...)"
    },

    "azureFtp":{
        "host": "(...)",
        "user": "(...)",
        "password": "(...)",
        "remotePath": "(...)"
    }
}

Po utworzeniu tych plików jesteśmy w stanie uzyskać do nich dostęp w gulpfile.js:

var config = require('./gulp.config.js')(),
    secrets = require('./secrets.json');

// (...)
return gulp.src(config.lessBuildFiles)
        .pipe(less())
        .pipe(autoprefixer({
            browsers: ["last 2 version"]
        }))
        .pipe(concat('main.min.css'))
        .pipe(cleanCss())
        .pipe(gulp.dest(config.buildCssPath));

Na deser zostało jeszcze zmniejszenie liczby upierdliwych require. Za pomocą gulp-load-plugins usuwamy wszystkie załączenia pluginów z nazwą gulp-*.

/* PRZED */
var gulp = require('gulp'),
    autoprefixer = require('gulp-autoprefixer'),
    less = require('gulp-less'),
    concat = require('gulp-concat'),
    cleanCss = require('gulp-cleancss');

    // (...)
    .pipe(cleanCss())

/* PO */
var gulp = require('gulp'),
    $ = require('gulp-load-plugins')();

    // (...)
    .pipe($.cleanCss())

Podsumowanie

W wyniku wszystkich wymienionych operacji dostaliśmy następujący gulpfile:

var gulp = require('gulp'),
    config = require('./gulp.config.js')(),
    secrets = require('./secrets.json'),
    $ = require('gulp-load-plugins')();

gulp.task('default', ['build']);
gulp.task('build', ['build:less']);

gulp.task('watch', ['build'], () => {
    gulp.watch(config.lessBuildFiles, ['build:less']);
});

gulp.task('build:less', () => {
    return gulp.src(config.lessBuildFiles)
        .pipe($.less())
        .pipe($.autoprefixer({
            browsers: ["last 2 version"]
        }))
        .pipe(concat('main.css'))
        .pipe($.cleanCss())
        .pipe(concat('main.min.css'))
        .pipe(gulp.dest(config.buildCssPath));
});

Nie jest to kod pasujący do każdej sytuacji, ale może stanowić podstawę do Twojego pierwszego skryptu automatyzującego.

Cały projekt umieściłem na Githubie. Możesz się nim pobawić, żeby poczuć w jaki sposób działa Gulp.

Automatyzacja: wprowadzenie

Thu, 20 Oct 2016 07:10:00 -0500

Cześć!

Dzisiejsze IT staje przed wyzwaniem automatyzacji powtarzalnych procesów. Nigdy nie zdarzyło Ci się budować projektu, kopiować paczki na serwer, a następnie ręcznie przeklikać, czy wszystko działa prawidłowo? Nigdy nie wkleiłeś produkcyjnych kluczy do kodu przed wrzuceniem aplikacji do sklepu? W takim razie ten wpis nie jest dla Ciebie, jednorożocu Ty! W przeciwnym wypadku, zapraszam.

Upierdliwe życie programisty

Pracowałem kiedyś nad dużym oprogramowaniem. Monolitem, takim pisanym przez 100 - 500 osób. Wiesz, kilkanaście środowisk, z czego 2 używane etc. Jak w każdym projekcie w 2010’s, mieliśmy serwer, który budował projekt. Jakaś mądra głowa pochyliła się nad tematem i stwierdziła, że musi być. W końcu automatyzacja to szybszy feedback i mniejsze koszty, bierzemy! Był tylko jeden problem - zbudowanie całego projektu trwało kilka godzin.

Dodatkowo, samo zbudowanie wszystkiego nie oznaczało, że oprogramowanie nadaje się do wdrożenia. W końcu moduł mógł się zbudować, ale nie być podpięty pod resztę projektu (sic!). Zamiast skupić się na rozwijaniu oprogramowania, każdy programista musiał kontrolować, czy konfiguracja jest poprawna. Drobne rzeczy są łatwe do przeoczenia. Z tego powodu soft często się wykładał z niejasnych przyczyn.

Mniejsza skala, te same problemy

Zejdźmy jednak w tej chwili na ziemię. Nie każdy projekt jest tak opasły. Co nie znaczy, że problemy są inne. Prześledźmy taki przypadek. Tworzysz projekt w kilka osób. Wdrożenia projektu może dokonać tylko przedstawiciel klienta. Polityka bezpieczeństwa albo inny korporacyjny szit, zdarza się. W związku z tym, wszystkie hasła muszą zostać podmienione przez osobę wykonującą deploy. Przy okazji, człowiek ten ulega pokusie “poprawienia” kilku rzeczy w konfiguracji, według swojego widzimisię. W ten sposób otrzymujesz niespójny i zmodyfikowany produkt, za który odpowiadasz.

Lokalne podwórko

Mam bloga na statycznym CMSie. Każda zmiana na stronie wiąże się ze zbudowaniem HTMLi, styli etc. Pliki wypycham w dwa miejsca: FTP z Azure Web App oraz Azure Blob Storage. Za każdym razem muszę mieć osobną paczkę do wrzucenia w każde z miejsc. Dodatkowo mam dwa różne pliki Web.config - jeden dla serwera testowego i drugi dla produkcji (produkcja ma HTTPS z HSTS). Ręczne dobranie plików, które dostaję z Jekylla, zbudowanie LESSów, podzielenie na FTP i Bloba i wrzucenie na serwer zajmuje jakieś 10 minut i nie mam pewności, że wszystko jest na miejscu.

Dlaczego automatyzować?

Wymienione sytuacje różnią się poziomem złożoności. Można jednak wyodrębnić z nich kilka powodów, dla których należy przeprowadzić automatyzację procesu:

rozwój oprogramowania wymaga coraz większej liczby ręcznie konfigurowanych elementów,
każdy nowy element jest kolejnym, możliwym do popełnienia, błędem… błędem który, prędzej czy później, wreszcie popełnisz,
ludzie są słabi w powtarzaniu czynności, w przeciwieństwie do komputerów,
skrypt automatyzujący jest dla projektu tym, czym testy uczące dla kodu,
automatyzacja może zastapić dokumentację konfigurowania projektu, która jest zwykle nieaktualna lub nikt jej nie czyta.

Czym automatyzować?

Możliwości automatyzacji są bardzo szerokie. Popularne są dedykowane narzędzia automatyzujące, budujące oraz task runnery. Tego typu narzędzia mogą polegać na uruchamianiu kolejnych komend z powłoki (jak ma to miejsce w Make), lub stosować dedykowane API (Grunt.js, Gulp.js, MSBuild). Mogą operować na kolejnych artefaktach w systemie plików lub przetwarzać wszystko w pamięci za pomocą strumieni.

Innymi możliwościami są:

skrypty powłoki systemowej, (bash, pliki bat),
skrypty lub programy napisane w dowolnych językach programowania (C#, Python, Ruby),
oprogramowanie uruchamiające skrypty cyklicznie (cron).

Metoda jest w rzeczywistości dowolna. Liczy się łatwość osiągnięcia celu, łatwość uruchomienia skryptu/programu oraz łatwość utrzymywania przez zespół. Zupełnie jak z każdym innym programem.

Kiedy i jak automatyzować?

O automatyzacji należy zacząć myśleć w momencie, gdy jakaś powtarzalna czynność staje się uciążliwa lub wymaga przypominania sobie całego procesu. Takie sytuacje są powszechne. Pamiętaj jednak, że program automatyzujący jest tak samo podatny na błędy, jak każdy inny software. Zbędna automatyzacja może skończyć się w następujący sposób:

xkcd: Automation

Jeśli jednak automatyzacja się opłaci, należy przetestować skrypt przed wykorzystaniem go w systemie produkcyjnym. Jak to zrobić? Przede wszystkim, należy odseparować konfigurację (ścieżki do katalogów, hasła, klucze) od właściwego kodu. Następnie trzeba zmodyfikować konfigurację w taki sposób, aby nie łączyła się w żaden sposób z produkcją lub nie narobiła bałaganu w przypadku jakiegoś babola.

CSS - zapanuj nad stajnią Augiasza

Tue, 31 May 2016 16:30:00 -0500

Siemano! Obejrzałem najnowszy odcinek GoT, więc czas na kreatywną pracę z tekstem!

Ostatnio w pracy dużo siedzę przy front-endzie. Co prawda I don’t speak JavaScript, ale front-end to nie tylko skrypty. Osobiście dużo więcej frajdy sprawia mi pisanie deklaratywnie w HTMLu i CSSach. Bardzo długo do tematu programowania w HTMLu podchodziłem drwiąco. Musicie jednak wiedzieć, że opisanie wyglądu i zachowania strony to nie lada wyczyn. Podział strony na sensowne częsci w HTMLu jest względnie prosty (w końcu wstawiamy tam dane, helloooo). Dużym problemem są za to style, które nakładają się na siebie w często mało oczywisty sposób. W dzisiejszym wpisie przybliżę więc temat podziału CSSów na moduły.

CSS, czyli jak bardzo przegrałeś

W ramach przypomnienia jak w ogóle wygląda CSS, zapisałem przykładową regułę:

selector {
    property: value;
    another-property: value2;
}

Selektory odpowiadają za wybór elementów, na które zostaną nałożone style. Możliwy jest wybór elementów strony przy pomocy tagów HTML, id lub klas. Możliwe jest również łączenie selektorów w celu uszczegółowienia tego, co ma zostać ostylowane, np. można ostylować wszystkie elementy p, będące potomkami elementu article:

article p {
    background-color: pink;
}

Właściwości (ang. property) i wartości (ang. value) odpowiadają za zmianę wyglądu lub zachowania wybranych elementów. W powyższym przykładzie, wszystkie elementy p, będące potomkami article będą miały różowe tło.

Albo nie wszystkie… Pisiont na pisiont. CSS jest wyposażony w mechanizm rozwiązywania konfliktów wg. specyficzności (ang. specificity). Wygrywa selektor najsilniejszy, a więc taki, którego specyficzność jest najwyższa. Specyficzność zależy od rodzaju selektora, jego złożoności i prawdopodobnie od promieniowania kosmicznego oraz liczby Yeti w promieniu 6 mil. Chociaż co do dwóch pierwszych nie jestem pewien. Reguła kciuka jest następująca: im bardziej zakręcony selektor, tym wyższa specyficzność. Prosty przykład wrzuciłem na JSFiddle:

Problem z CSSem zaczyna się w momencie, w którym struktura strony staje się skomplikowana i należy zdecydować, od którego elementu drzewa będziemy zaczynali selektor.

Jak wyznaczyć korzeń selektora?

Problem da się zauważyć już w podlinkowanym wcześniej przykładzie. Zacząłem selektor od elementu article. Czy na pewno był on wymagany? Albo był, albo nie był. Wszystko zależy tak naprawdę od kontekstu. Podejmując decyzję o korzeniu hierarchii selektora, zadaję sobie następujące pytania:

Czy elementy p wystąpią w przyszłości poza artykułem?
Czy elementy p poza artykułem powinny mieć nałożone te same style?
Czy wszystkie elementy p w artykule powinny mieć nadany określony styl? (Może warto uszczegółowić selektor?)
Czy article jest odrębnym komponentem?

Ogólna zasada jest następująca: wybierz najmniej szczegółowy selektor, który spełni wszystkie wymagania. Stosując zbyt skomplikowane selektory prosisz się o problemy ze specyficznością w przypadku nadpisywania stylu.

LESS, czyli zagnieżdżenia, zmienne i funkcje w stylach

Skoro już jesteśmy przy skomplikowanych selektorach, chciałbym pokazać Ci jedno z narzędzi ułatwiających pracę z bardzo złożonymi arkuszami stylów. Jest nim LESS. LESS jest nadzbiorem języka CSS. Oznacza to tyle, że każdy CSS jest poprawnym kodem LESS, dzięki czemu możesz stopniowo przepisywać style na LESS.

Zagnieżdżenia

LESS pozwala na zagnieżdżanie selektorów. Oznacza to, że przykładowy CSS można przepisać na poniższą postać:

article {
    p {
        color: pink;

        &.black-as-hell {
            color: black;
        }
    }

    *:last-child {
        color: green;
     }
}

Każdy poziom zagnieżdżenia oznacza kolejną składową selektora. Jeżeli chcemy uzyskać składową selektora złożoną np. z taga i klasy, należy skorzystać z operatora &.

Zmienne

Bardzo często projekt strony przewiduje wykorzystywanie jednego koloru w wielu miejscach. To samo może dotyczyć np. marginesów oraz czcionek. W takiej sytuacji LESS oferuje nam zmienne.

@paragraph-color: pink;
@alternative-paragraph-color: black;
@last-element-color: green;

article {
    p {
        color: @paragraph-color;

        &.black-as-hell {
            color: @alternative-paragraph-color;
        }
    }

    *:last-child {
        color: @last-element-color;
     }
}

Ważne jest, aby nazwy zmiennych powiązane były ze znaczeniem elementów, do których będą wykorzystywane. Nazwanie zmiennej @black nie da nam żadnego zysku – zmodyfikowanie jej zawartości zmusi nas do zmiany jej nazwy.

Mixiny i funkcje

Język LESS oferuje możliwość definiowania parametryzowanych reguł. Taka reguła nosi nazwę mixin.

.apply-color(@color) {
    color: @color;
}

Mixiny mają raczej ograniczone zastosowania, jednak są sytuacje, w których znacznie ułatwiają życie. Przykładem może być nadanie elementowi clearfixa:

.clearfix() {
    zoom: 1;

    &:before,
    &:after {
        content: "";
        display: table;
    }

    &:after {
        clear:  both;
    }
}

.floating-elements-container {
    .clearfix();
}

LESS oferuje również zbiór wbudowanych funkcji, pozwalających na manipulowanie wartościami. Możliwe jest np. przyciemnienie koloru, nadanie przezroczystości lub wybranie mniejszej wartości (funkcja min).

Podział stylów na wiele plików

Została nam najistotniejsza część naszej wędrówki przez krainę LESSa. Mając odpowiednio wydzielone moduły, wyodrębnione zmienne i mixiny, jesteśmy w stanie podzielić style na wiele plików. Osobiście stosuję następujące zasady:

zmienne trafiają do variables.less,
mixiny trafiają do mixins.less,
każdy moduł trafia do osobnego pliku i załącza referencje do zmiennych i mixinów (za pomocą @import (reference) “variables.less”),
jeżeli aplikacja posiada dużo stylów dla urządzeń mobilnych, trafiają one do osobnych plików, np. nazwa-modulu.lg.less, nazwa-modulu.md.less etc.
jeżeli style mobilne stanowią nie więcej niż 50 linii kodu, umieszczam je w plikach opisanych szerokością ekranu, np. lg.less, md.less.

Wady i alternatywy

Język LESS zawiera jeden haczyk - przeglądarki go nie interpretują. W związku z tym, należy zbudować go do CSSa po stronie serwera. Obecnie nie stanowi to dużego problemu. Web Essentials dla Visual Studio posiada narzędzie do budowania LESSa. Takie możliwości posiadają również pluginy do Gulpa i Grunta.

Istnieje jedna realna alternatywa dla LESSa, a mianowicie język SASS. Oba języki posiadają porównywalne możliwości. Osobiście korzystam z LESSa, ponieważ był on dużo popularniejszy w świecie .NET gdy zaczynałem swoją przygodę z web developmentem. Siła nawyku :-)

Używasz LESSa w swoich projektach? A może masz inny sposób radzenia sobie z chaosem w arkuszach stylów? Podziel się w komentarzach!

F#: wyrażenia

Sat, 30 Apr 2016 12:00:00 -0500

Szalom!

Witam się po hebrajsku, bo jedna z Wróżek-korektorek stwierdziła, że “hej” jest pedalskie. Ale do rzeczy. W kolejnym odcinku traktującym o języku F# chciałem się skupić na jednej z postawowych koncepcji programowania funkcyjnego, a mianowicie:

Funkcje są wyrażeniami

Wyrażenia

Czym jest owo wyrażenie? Mówiąc w skrócie, jest to funkcja, która nie zapisuje żadnych zmiennych pośrednich i zwraca wartość. Najprościej będzie mi to wyjaśnić na przykładzie.

To nie jest wyrażenie:

public void ComputeHsvColor(int red, int green, int blue)
{
    var hue = ComputeHue(red, green, blue);
    var saturation = ComputeSaturation(red, green, blue);
    var value = ComputeValue(red, green, blue);
    
    this.HsvColor = String.Format("{0}{1}{2}", hue, saturation, value);
}

To za to jest wyrażeniem:

public string ComputeHsvColor(int red, int green, int blue)
{
    return String.Format("{0}{1}{2}",
        ComputeHue(red, green, blue),
        ComputeSaturation(red, green, blue),
        ComputeValue(red, green, blue));
}

Prawdziwy bałagan, prawda? Składnia nie powala, ale zajmiemy się nią później. W tej chwili ważne jest to, że uzyskaliśmy wyrażenie. Wyrażenie w C# najprościej rozpoznać po tym, że ciało funkcji zaczyna się od słowa kluczowego return.

Co nam to właściwie dało? Brak utrzymywania stanu na zewnątrz fukcji powoduje, że są one od siebie odizolowane. W konsekwencji funkcje można łatwo zamieniać między sobą i organizować w bardziej złożone fragmenty aplikacji. Jeżeli mieliście doświadczenie z testami jednostkowymi, to możecie dostrzec kolejny istotny benefit. Odizolowany kod jest bardzo prosty w przetestowaniu.

Ok, ok. Testy to jedno, a czytelność kodu to drugie. Zajmijmy się więc tym zagadnieniem. F# oferuje kilka ciekawych rozwiązań, dzięki którym łatwiej zrozumiecie działanie wyrażeń.

Operacje na wyrażeniach w F#

F# posiada szeroki wachlarz lukrów składniowych, ułatwiających pracę z wyrażeniami. Z punktu widzenia dzisiejszego wpisu, szczególnie przydatne są trzy konstrukcje:

dopasowywanie wzorców za pomocą match .. with,
operator forward pipe,
operator forward composition.

Dopasowywanie wzorców

Dopasowywanie wzorców (ang. pattern matching) w F# realizuje się za pomocą operatora match .. with. Jest to taki switch na sterydach. W głowach doświadczonych programistów języków obiektowych powinna zapalić się czerwona lampka. Switch jest przecież brzydkim zapachem w kodzie, a jego wystąpienie oznacza zwykle brak lub źle zastosowane wzorce projektowe. W F# jest jednak inaczej.

let someFunction someArgument someDiffrentArgument =
    match someArgument with
    | arg when arg < 0 -> computeAnotherPartOfCode()
    | arg when arg % 2 == 0 -> doSomething(arg / 2)
    | 7 -> doSomething(someDiffrentArgument)
    | arg -> doSomethingElse(arg)
    | _ -> launchRocket()

Istotny jest fakt, że każde z dopasowań musi zwracać ten sam typ danych. Jeżeli funkcja zawiera jedynie dopasowywanie wzorców, można zastosować jeszcze krótszą składnię. Pierwszy parametr przekazany do funkcji jest wtedy obiektem dopasowywania:

let someFunction someDiffrentArgument = function
    | arg when arg < 0 -> computeAnotherPartOfCode()
    | arg when arg % 2 = 0 -> doSomething(arg / 2)
    | 7 -> doSomething(someDiffrentArgument)
    | arg -> doSomethingElse(arg)
    | _ -> launchRocket()

W językach funkcyjnych powszechnie stosowane są listy ze wskaźnikami na następny element (ang. linked list) oraz krotki (ang. tuple). Dopasowania w F# pozwalają na czytelny zapis operacji na powyższych typach.

Listę można podzielić na n pierwszych elementów oraz ogon:

let rec processListValues = function
    | head :: tail when head = 1 -> head
    | head :: second :: tail when second = 1 -> head + second
    | head :: tail -> processListValues tail
    | [] -> 0

Możliwe jest również dopasowywanie do elementów w krotkach:

let processTuple = function
    | (a, b) when a + b = 0 -> a - b
    | (a, b) -> a + b

Ok, świetnie. Znamy kolejną konstrukcję w kolejnym dziwnym języku programowania. Co w niej takiego niezwykłego? Otóż dopasowywanie wzorców:

nie pozwala na pominięcie jakiejkolwiek wartości z możliwego zbioru wejść,
wymusza zwrócenie obiektu,
pozwala na operowanie na jakimkolwiek obiekcie

Pominięcie wartości i modyfikowanie stanu zmiennych zamiast zwrócenia obiektu są powszechnymi problemami konstrukcji switch. To samo dotyczy dopasowań - F# nie jest ograniczony do stałych.

Forward pipe

Ile razy zdarzyło wam się widzieć taki kod podobny do poniższego?

int cookedSmurfs = Cook(ConcoctMixture(SmurfsLocator.GetSmurfs().Where(s => s.Name != "Smurfette").ToList())).CountSmurfs();

Kolejne zagnieżdżenia wywołań niesamowicie utrudniają analizę kodu. Możemy oczywiście podzelić powyższy kod na mniejsze zmienne:

IEnumerable<Smurf> allSmurfs = SmurfsLocator.GetSmurfs();
IEnumerable<Smurf> tastySmurfs = allSmurfs.Where(s => s.Name != "Smurfette").ToList();
IMixture baseMixture = ConcoctMixture(tastySmurfs);
ICookedMixture cookedMixture = Cook(baseMixture);
int cookedSmurfs = cookedMixture.CountSmurfs();

Spoiler: CountSmurfs ma następującą postać:

public int CountSmurfs()
{
    // all Smurfs escaped soooo... f/u Gargamel
    return 0;
}

Wracając do tematu: F# pozwala na jeszcze prostsze połączenie wielu operacji. Wszystko to odbywa się dzięki operatorowi forward pipe. Operator ten przekazuje wynik operacji jako ostani argument do następnej fukcji:

let cookedSmurfs =
    getSmurfs()
    |> (smurfs -> smurfs.Where(s => s.Name != "Smurfette").ToList())
    |> concoctMixture
    |> cook
    |> countSmurfs

Wygląda dużo prościej i czytelniej, prawda?

Forward composition

Operator forward pipe pozwala na przekazywanie argumentów do kolejnych fukcji. A co jeżeli chcielibyśmy zapisać fukcję jako zbiór kolejnych operacji, nie nazywając zmiennych wejściowych? Z pomocą przychodzi, oczywiście, operator forward composition:

let countCookedSmurfs =
    >> (smurfs -> smurfs.Where(s => s.Name != "Smurfette").ToList())
    >> concoctMixture
    >> cook
    >> countSmurfs

let cookedSmurfs = countCookedSmurfs (getSmurfs())

Operatory forward pipe i composition różnią się tak naprawdę jedynie początkowym przekazaniem parametru. W przypadku forward pipe parametr przychodzi ze środka funkcji, natomiast w composition - z zewnątrz.

Podsumowanie

Wyrażenia same w sobie mogą powodować trudności w analizowaniu działania programu. Na szczęście składnia F# powoduje zwiększenie przejrzystości całego tego bałaganu. Moim zdaniem wyrażenia plus dedykowana składnia dają w wyniku dużo przejrzystszy kod, niż chociażby w przypadku ce-płotka. A co Wy o tym myślicie?

Materiały dodatkowe

F# for fun and profit - Expressions vs. Statements

Dylematy programisty: var

Wed, 30 Mar 2016 14:10:00 -0500

Zawód programisty wiąże się z nieustannym wybieraniem pomiędzy złym, a gorszym. Nie inaczej jest ze słowem kluczowym var.

Czym jest var?

Słowo kluczowe var służy do inferencji typów na poziomie kompilacji C# do CIL. Inferencja polega na ustaleniu typu zmiennej na podstawie przypisywanej wartości. Var ma swoje korzenie w języku F#, gdzie inferencja jest jeszcze bardziej rozbudowana. Nie jest to w żadnym wypadku typ dynamiczny. Słowo kluczowe var można stosować jedynie wewnatrz metody - nie ma możliwości definiowania w ten sposób typów wejściowych i wyjściowych (w przeciwieństwie do F#), czy też typów pól w klasie.

Ponieważ mój .NET trochę zardzewiał (a rdza słabo schodzi, bo nie piję coli ani nie smaruję się WD-40), byłem przekonany, że każdy developer C# używa go wszędzie gdzie się da. Okazało się, że istnieje spore grono wyznawców podawania typów wprost.

Dlaczego warto używać var?

Słowo kluczowe var, a co za tym idzie - ograniczona inferencja typów, nie zostały wprowadzone bez powodu. Do głównych zalet należą:

zmiana przypisania wartości nie wymusza zmiany typu zmiennej,
zapis jest krótszy i czytelniejszy, szczególnie w przypadku rozbudowanych typów ogólnych (less is more),
wymusza przypisywanie wartości do zmiennej w miejscu jej deklaracji,
uwalnia od polegania na implementacji na rzecz interfejsu (np. w kolekcjach).

var sheepsCount = 1;
var repository = new ExtendedComplicatedImportantRepository<ModelOne, ModelTwo>();
var element = Elements.Where(e => e.Important.Equals(true));

Dodatkowo var jest jedyną możliwością w przypadku tworzenia instancji typów anonimowych.

var v = new { Amount = 108, Message = "Hello" };

W jakich sytuacjach var jest utrudnieniem?

Stosowanie słowa var w każdej sytuacji wiąże się jednak z pewnymi komplikacjami:

na code review nie widać typu zmiennej, przez co trudniej określić intencje autora kodu,
korzystanie że źle zaprojektowanego api jest mało czytelne,
odczytanie typu poza środowiskiem programistycznym z intellisense jest utrudnione.

var contentUrl = provider.ContentReference;

Spotkałem się również z metodą mieszaną - stosowanie var tylko w przypadku tworzenia nowego obiektu za pomocą konstuktora lub metody wytwórczej.

var element = new Element("Name");
var secondElement = Element.Create("Name");

Podsumowanie

Osobiście stosuję var gdzie się da. Prawdę mówiąc mam wrażenie, że unikanie var jest wymówką dla złego nazywania zmiennych i pól. W końcu nazwa zmiennej powie wszystko o jej zawartości. A co jeżeli…

IRepository<Banana> applesRepository = new Repository<Banana>();
// a lot of crappy code
(...)
// we don't know type of result just because of wrong variable name
applesRepository.First();

Moje podejście dotyczy to jednak tylko moich własnych projektów. Pracując w zespole dużo istotniejsza jest spójność. W moim obecnym projekcie w pracy stosujemy metodę mieszaną.

A wy? Używacie tego słowa kluczowego w swoich projektach?

PS. Jestem na etapie życia, w którym wszystko zaczyna zasuwać jak gepard goniący gazelę. Pisanie kolejnych postów często spada na dalszy plan. Dlatego potrzebowałem motywacji. Postanowiłem rzucić wyzwanie mojemu dobremu kumplowi Arkowi, który właśnie transferuje się z upadającego WP na Androida. Wyzwanie polega na opublikowaniu przynajmniej jednego wpisu w miesiącu. Arek, jak przystało na człowieka o wyglądzie drwala, podniósł rękawicę. Dzięki temu na naszych blogach będzie więcej contentu dla Was :-)

F#: po radosnej stronie programowania

Mon, 15 Feb 2016 03:00:00 -0600

Dwa lata temu spotkałem go poraz pierwszy. Cechowały go dziwna składnia, nienaturalny przepływ sterowania i komplikowanie najprostszych operacji do rocket science na linked listach i rekurencji. Pomyślałem wtedy - jak można pisać w czymś takim?! Byłem w błędzie.

/ wow, temat wpisu w ogóle nie sugerował takiego plot twistu /

Programowanie funkcyjne

Być może potknąłeś się o programowanie funkcyjne. Mógł to być wielki kamień stojący 20 metrów od Twojej ścieżki kariery. Tak, ten z wysprayowanym napisem “NIE DOTYKAĆ”. Jeżeli to Twój pierwszy kontakt z programowaniem funkcyjnym, to musisz wiedzieć, że programowanie funkcyjne nie jest nowym tworem. Podstawy teoretyczne istnieją już od lat 30 ubiegłego wieku, a pierwsze języki funkcyjne powstały w tych samych czasach, co pierwsze języki imperatywne.

Czym jest programowanie funkcyjne? Jest to po prostu podejście do pisania programów, w którym wszystkie rozwiązania problemów sprowadza się do zbudowania funkcji. Jeżeli Twoją pierwszą myślą jest “przecież teraz też implementuję funkcje”, to masz rację. Różnica polega na tym, że:

przypisujesz wartości do zmiennych,
implementujesz procedury (takie funkcje, tylko nie zwracające wartości),
sterujesz wykonaniem programu instrukcja po instrukcji.

W podejściu funkcyjnym wszystko co robisz jest ubrane w funkcję. Wynik jednej funkcji musi być przekazany bezpośrednio do drugiej funkcji. Funkcja musi zwracać wartość.

F# nie jest językiem funkcyjnym.

/ Kurtyna /

F#

F# jest hybrydą. Większość języka jest skonstruowana pod paradygmat funcyjny. Mamy jednak wszystkie konstrukcje, potrzebne do stworzenia obiektowego kodu.

Kilka cech F# sprawia, że jest on doskonałym narzędziem do bezpiecznego programowania:

statyczne typowanie z silną inferencją,
używa wyrażeń zamiast twierdzeń - funkcja zawsze zwraca wartość,
domyślnie operuje na wartościach niezmiennych (ang. immutable),
używa typów opcjonalnych zamiast null,
pozwala na łatwe zwracanie niepoprawnego stanu zamiast operowania na wyjątkach.

Istotną cechą F# jest możliwość wykorzystania kodu napisanego w tym języku w dowolnych aplikacjach .NET. Interoperacyjność pozwala na wykorzystanie właścowości F# w tych miejscach, w których mają zdecydowaną przewagę nad kodem C#. Przykładami takich zastosowań jest implementacja skomplikowanych algorytmów oraz tworzenie wielowątkowego kodu.

W kolejnych wpisach będę przybliżał poszczególne cechy F# i porównywał je z możliwościami języka C#.

Dlaczego Java ssie?

Mon, 18 Jan 2016 03:00:00 -0600

Ostatnio zdarzyło mi się wdać w jałową dyskusję na temat wyższości C# nad Javą. Padł tam koronny argument fanboya Javy, pt. “nie masz pojęcia o czym mówisz, nie używasz Javy”. Otóż, prawie. Od kilku miesięcy pracuję jako programista tego pokracznego języka. Postanowiłem wreszcie wylać swoje żale na wasze ekrany.

Gettery i settery

Java, WTF? Rozumiem konwencję utrzymywania enkapsulacji pól i udostępniania/modyfikacji danych przez funkcje. Moje pytanie brzmi: skoro jest to praktycznie obowiązkowa część korzystania z języka i każdy framework wymaga stosowania się do tej zasady, to dlaczego nie można było tego zmieścić do jednej linii? Zarządzanie kodem udekorowanym getterami i setterami to piekło. Brak sensownego rozwiązania problemu getterów i setterów to tylko wierzchołek góry lodowej, jakim jest…

Brak lukrów składniowych

Operujesz na kolekcji. Chcesz dostać jej pierwszy element. Co robisz? Oczywiście, wywołujesz metodę, zamiast zastosować stosowany w tablicach operator []. Przyczyna jest prosta: nie można przeciążać operatorów. Właściwie wszystko co robisz musi być opisane słowem, nazwą metody.

Takich przykładów jest mnóstwo. Aż dziw bierze, że ciągi znaków konkatenujemy operatorem +, zamiast .append().

Deklarowanie rzucanych wyjątków

Java wymaga zadeklarowania jakie wyjątki mogą zostać rzucone przez metodę. Wydaje się przydatne, prawda? Korzystając z danej metody, wiesz czego się spodziewać. Problem polega na tym, że kod jest organizmem żywym i zdarza się, że metoda, której używasz, zaczyna rzucać więcej wyjątków. Co się wtedy stanie? Ano dupa, Twój kod przestał się właśnie kompilować. Musisz obsłużyć sytuację albo dodać wyjątek do listy throws.

Ok, załóżmy nawet, że API z którego korzystasz się nie zmienia. W Javie istnieje coś takiego, jak RuntimeException. Wyjątek ten, jak i jego potomstwo nie muszą być zdefiniowane jako rzucane przez metodę. W ten sposób otrzymano konstrukcję językową, która nie daje żadnej pewnej informacji. Przynosi w zamian za to mnóstwo problemów z utrzymaniem kodu.

Zarządzanie zależnościami

Napisałeś własną bibliotekę. Brawo! Korzystasz w niej z innej biblioteki. Dla uproszczenia, nazwijmy Twoją bibliotekę BadassLib, a bibliotekę od której zależysz - HaxxorLib. Pisząc swój kod korzystałeś z HaxxorLib w wersji 2.1.0. W wersji 2.2.0 usunięta została jedna z metod, na której polegałeś. Przygotowałeś konfigurację Mavena (taki javowy NuGet + msbuild), w której jasno określiłeś, że BadassLib wymaga HaxxorLib w wersji dokładnie 2.1.0. I co? Panu Ryszardowi spodobała się Twoja biblioteka i postanowił jej użyć. Niestety, w swoim projekcie nie korzysta z Mavena. Dlaczego nie korzysta z Mavena? Powodów może być wiele, nie chcę się nad nimi rozwodzić. Istotne jest to, w jaki sposób Pan Ryszard rozwiąże problem zależności BadassLib. Otóż doda on do classpatha ręcznie pobrany HaxxorLib. Zgadnij w jakiej wersji HaxxorLib była do pobrania ze strony biblioteki :-) Miłego debugowania, Panie Ryszardzie.

Źródłem tego problemu jest beznadziejny system zarządzania zależnościami w środowisku Java. Decyzja o wykorzystaniu zależności podejmowana jest na podstawie classpatha, a nie wymagań konkretnego modułu. Z tego powodu otrzymujemy piękne zjawisko, jakim jest Jar Hell. Problem ma zostać rozwiązany przez projekt Jigsaw, jednak na to przyjdzie nam jeszcze długo poczekać.

Podsumowanie

Nie chodzi o to, że język Java do niczego się nie nadaje. Po prostu jego składnia jest toporna i nie sprzyja czytaniu kodu, a zarządzanie zależnościami pozwala na nadużycia i prowadzi do trudnych do wykrycia błędów. Do tego dochodzi problem z niespójnością koncepcji. Możesz używać +operatora +_ na obiektach String, ale nie możesz ich wykorzystać w swojej klasie. Musisz stosować gettery i settery, ale nie możesz mieć ich skróconych do jednej linii. Same sprzeczności…

Narzędzia programisty #1: Brackets

Mon, 09 Mar 2015 08:00:00 -0500

Rozpoczynam nowy cykl na blogu. Co jakiś czas będę prezentował przydatne narzędzia, które ułatwiły moją pracę. W dzisiejszym odcinku mowa będzie o edytorze tekstu Brackets - open-sourcowym dziecku firmy Adobe.

Po co kolejny edytor tekstu?

Edytor tekstu, sam w sobie, nie jest niczym szczególnym. Narzędzia tego typu powstają od ponad 40 lat. Siła Bracketsa leży jednak w przejrzystości i użyteczności. Jako główne zalety podałbym:

tekst jest czytelny i nie męczy oczu,
standardowe kolory są idealnie dobrane,
interfejs jest przejrzysty,
opcja live preview pozwana na podgląd projektowanej strony WWW na żywo (a’la Browser Link z Visual Studio),
system rozszerzeń pozwala na bardzo duże modyfikacje, jednocześnie uniemożliwiając popsucie UX.

Edytor miły dla oka

Czcionki i kolory mogą wydawać się błahostką. Sprawiają jednak, że długie korzystanie z narzędzia jest (lub nie jest) przyjemne. To samo dotyczy interfejsu. Dodatkowe okna w każdym miejscu środowiska prowadzą do dekoncentracji. Brackets wygrywa w tej kategorii. Oczywiście w VS, Sublime Text czy Atomie mogę również zmienić kompozycję i kolorystykę. Jednak powiedzmy sobie szczerze: dostępne modyfikacje zwykle wyglądają paskudnie.

Który tekst jest czytelniejszy?

Adobe Brackets - fragment kodu JSON

Github Atom - fragment kodu CSON

Oczywiście takie przykłady można mnożyć.

Rozszerzenia

Czysta instalacja Bracketsa jest dość mało rozbudowana. Na szczęście mamy rozszerzenia. Zmieniają one prosty edytor tekstu w pełnoprawne IDE.

Nie będę wymieniał dostępnych rozszerzeń. Nie brakuje praktycznie niczego. A w każdym razie ja nie potrzebowałem rzeczy, do których nie było plugina.

Trafiłeś na coś, czego brakuje? Obecne rozszerzenie posysa? Napisz własne lub popraw istniejące. To naprawdę proste. Brackets jest w rzeczywistości oknem przeglądarki. Oznacza to tyle, że edytor i wtyczki są połączeniem plików JavaScript, HTML i CSS. Podstawowe API jest proste i nawet żółtodziób poradzi sobie z pisaniem rozszerzeń.

OmniSharp

Przyszedł czas na zabawkę dla niegrzecznych programistów. Tych od czarnych korpo-technologii .NET.

Microsoft postawił ostatnio na wieloplatformowość i niezależność od Visual Studio. Słyszałeś o projekcie OmniSharp? Jest to zbiór wtyczek do popularnych edytorów tekstu. Owe wtyczki mają za zadanie dostarczyć środowisko do pracy z C#.

Dobra wiadomość jest taka, że OmniSharp dla Bracketsa istnieje. Zła - jest mało rozbudowany. Obecnie pozwala jedynie na formatowanie kodu i usunięcie nieużywanych importów (using). Na domiar złego, wersja w repozytorium rozszerzeń Bracketsa jest nieaktualna. Trzeba ją pobrać z repozytorium do katalogu wtyczek.

Istnieje kilka problemów podowanych przez pracę poza Visual Studio:

budowanie aplikacji i uruchamianie testów jest problematyczne,
opcje refactorowania i debugowania są mocno ograniczone,
nie ma narzędzi do profilowania wydajności.

Jeśli chodzi o budowanie i uruchamianie testów, sprawa jest prosta. Obydwa procesy można wykonywać poprzez proste skrypty. W ASP.NET 5 jest to szczególnie ułatwione - wszystko uruchamia się za pomocą polecenia k.

Brak możliwości debugowania i profilowania psuje zabawę. Częściowo można zastąpić oba procesy pisząc testy. No właśnie, częściowo…

Co dalej?

Edytor możesz pobrać ze strony projektu. Jeżeli jesteś webdeveloperem z .NETowym zapleczem i zależy Ci na narzędziach niezależnych od Visual Studio, spróbuj wspomóc rozwój omnisharp-brackets.

Jekyll: ucieczka od Wordpressa

Mon, 23 Feb 2015 09:00:00 -0600

W życiu każdego bloggera przychodzi taki moment, w którym zaczyna blogować o blogowaniu. U mnie wypada to teraz. Jak pewnie zauważyliście, na blogu nastąpiły drobne zmiany stylistyczne. Pod maską natomiast zmiany są drastyczne: przeniosłem wszystko na platformę Jekyll.

Czym jest Jekyll?

Jekyll jest frameworkiem do blogowania. Różni się jednak od klasycznych narzędzi tego typu. Cała treść generowana jest po stronie autora strony, a na serwer trafiają jedynie statyczne pliki. Nie ma tu żadnej bazy danych, dziurawych pluginów i ponownego generowania tej samej treści.

Zlikwidowanie wartwy aplikacji webowej wydaje się cofnięciem o 20 lat w rozwoju. Ma to jednak wymierne korzyści:

zmniejszamy powierzchnię ataku
zwiększamy wydajność strony

Z miejsca eliminujemy błędy związane z uwierzytelnianiem, autoryzacją, kontrolą sesji użytkownika, wstrzykiwaniem kodu (SQLi, RCI), międzydomenowym fałszowaniem żądań (CSRF) i pewnie wiele innych. Oczywiście możemy zwiększyć ponownie powierzchnię ataku, odbierając dane od użytkownika, jednak w większości przypadków związanych z blogowaniem jest to po prostu zbędne.

Jednocześnie usuwamy wąskie gardła – komunikację aplikacji z bazą danych i innymi zasobami sieciowymi. Statyczne pliki mają jeszcze jedną zaletę: serwer WWW kompresuje je znacznie wydajniej niż treść generowaną dynamicznie. W moim przypadku czas łączny ładowania strony głównej zmniejszył się o 2/3.

Layouty, wpisy i metadane

Layout i treść strony generowane są z plików HTML i MarkDown przez silnik Liquid. Wygląda to podobnie do widoków w ASP.NET MVC. Istnieją tu koncepcje layout, view, partial view etc. Są po prostu inaczej nazwane. Największa wada? Nie ma gotowych layoutów. Największa zaleta? Nie ma gotowych layoutów.

Wordpress jest świetny do szybkiego rozpoczęcia przygody z pisaniem. Niestety, layouty zwykle są marnej jakości i nie są responsywne. Jakby tego było mało, do każdej pierdoły potrzebny jest plugin, który jeszcze bardziej psuje strukturę plików HTML i CSS. Spotkałem się z pluginami doklejającymi wszystkie swoje style w treść HTML. Za każdym przeładowaniem strony konieczne było pobranie na nowo tych samych stylów.

Wersja dla leniwych jest prosta – możemy skorzystać ze standardowego layoutu Jekylla.

Jak już wspomniałem, wpisy trzymamy w plikach HTML/MarkDown. Metadane przechowywane są razem z treścią wpisu, na samej górze dokumentu. Mają postać dokumentu YAML.

Serve i Build

Jekyll posiada dwa polecenia służące do kompilowania projektu do statycznej strony:

jekyll build
jekyll serve

Build wykonuje jednorazową przebudowę projektu. Serve buduje projekt i czeka na zmiany w plikach projektu.

Instalacja środowiska (Windows)

Najpierw instalujemy manager pakietów Chocolatey. Chocolatey można porównać do apt-get z systemów GNU/Linux lub Homebrew z Mac OS. Uruchamiamy polecenie:

@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Następnie instalujemy wszystkie niezbędne paczki oraz gemy. Gemy są paczkami języka Ruby. Uruchamiamy ponownie konsolę i wpisujemy:

choco install git ruby ruby2.devkit 7zip.commandline
(echo --- && echo - C:/tools/ruby215) > C:/tools/DevKit2/config.yml && cd C:/tools/DevKit2 && ruby dk.rb install && cd ..
@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object System.Net.WebClient).DownloadFile('https://github.com/rubygems/rubygems/archive/v2.4.6.zip','rubygems-2.4.6.zip'))"
7za x rubygems-2.4.6.zip && cd rubygems-2.4.6 && ruby setup.rb && cd .. && rd /s /q rubygems-2.4.6 && del /s /q rubygems-2.4.6.zip

Ponownie restartujemy konsolę i wpisujemy:

gem install jekyll rouge

Przechodzimy do wybranego katalogu i tworzymy nowy projekt Jekylla:

jekyll new appName
cd appName
echo highlighter: rouge>> _config.yaml

Możemy uruchomić aplikację:

jekyll serve

W tym momencie pod adresem http://localhost:4000 działa statyczna strona WWW z przykładowym wpisem. Każda zmiana w plikach projektu spowoduje natychmiastową przebudowę projektu.

Uwaga: plik _config.yml jest ładowany jednorazowo. Żeby załadować go ponownie, wymagane jest ponowne uruchomienie polecenia jekyll serve.

Import bloga z Wordpressa

Na początek wymieńmy rzeczy, które można zaimportować:

wpisy,
statyczne strony,
metadane wpisów i stron.

Oznacza to tyle, że nie ma możliwości automatycznego przeniesienia layoutu, o czym wspominałem wcześniej.

Proces importowania zaczynamy od instalacji niezbędnych gemów:

gem install sequel fileutils safe_yaml unidecode mysql2 htmlentities jekyll-import

Przechodzimy do katalogu utworzonego wcześniej projektu. Następnie tworzymy plik import.rb. Wstawiamy do niego dane do Wordpressa:

require "jekyll-import";
JekyllImport::Importers::WordPress.run({
  "dbname"   => "",
  "user"     => "",
  "password" => "",
  "host"     => "localhost",
  "socket"   => "",
  "table_prefix"   => "wp_",
  "clean_entities" => true,
  "comments"       => true,
  "categories"     => true,
  "tags"           => true,
  "more_excerpt"   => true,
  "more_anchor"    => true,
  "status"         => ["publish"]
})

Teraz uruchamiamy skrypt:

ruby -rubygems import.rb

Po wykonaniu importu warto przejrzeć zawartość plików .markdown i poprawić ewentualne błędy. Przydatna będzie funcja znajdź i zastąp. ;-)

Materiały dodatkowe:

ASP.NET 5

Mon, 24 Nov 2014 00:00:28 -0600

Nadchodzi król. Jedenastego listopada została wydana pierwsza beta ASP.NET 5.

O co chodzi?

Microsoft realizuje szalony pomysł. Zespół ASP.NET przepisuje frameworki MVC, Web API oraz Web Pages, a dokładniej łączy je w jedną całość. Mało tego, że przepisuje. Otwiera kod źródłowy i na bieżąco słucha głosu programistów. Możesz na bieżąco sprawdzać postęp w tworzeniu frameworka ASP.NET 5, testować nowe wersje i zgłaszać błędy (lub pomysły). Całość toczy się na GitHubie.

Moloch w kawałkach, czyli budowa ASP.NET 5

W zamierzchłych czasach ASP.NET był częścią .NET Framework. Jeżeli oczekiwałeś nowości - aktualizowałeś cały .NET. Jeżeli WinFormsy były łatane - aktualizowałeś cały .NET. Przypadkiem mogli przecież dołożyć zmiany w ASP.NET (konia z rzędem temu, kto czyta opisy poprawek). Wszystko było ciężkie i mało zwinne. Na szczęście sytuacja od dawna wygląda inaczej. ASP.NET MVC i jego pochodne są serwowane jako pakiety NuGet. Niestety, niektóre zależności w dalszym ciągu są częścią platoformy .NET. Cały stos ASP.NETa jest oparty o bibliotekę System.Web. Zawiera ona wszystko, czego mógłbyś(mogłabyś) użyć przy pisaniu aplikacji internetowej. Problem w tym, że nie użyjesz. Otrzymujesz ciężkie obiekty, które zapychają pamięć. ASP.NET 5 nie korzysta z System.Web! Nie będę tęsknił.

W ASP.NET 5 wszystko, z czego chcemy skorzystać musi zostać jawnie zadeklarowane.Najbardziej charakterystycznym przykładem jest włączenie serwowania statycznych plików (whaaat!?).

K-da fuq?

Nowy ASP.NET niesie ze sobą nowe narzędzia i środowiska uruchomieniowe. Pierwszym ich zbiorem jest Project K. Składa się z kilku elementów:

kre - (K Runtime Environment) - środowisko uruchomieniowe dla aplikacji ASP.NET 5, obsługuje proces budowania aplikacji,
kvm (K Version Manager) - program zarządzający wersjami kre (pierwsza rzecz do pobrania),
k - polecenie uruchamiające skonfigurowane skrypty (np. k web uruchamia aplikację w trybie self-hosted).

Interesujący jest fakt, że wersję KRE wybierasz dla projektu, nie dla wszystkich aplikacji na maszynie. Jeżeli piszesz swoją aplikację w Visual Studio i uruchamiasz na serwerze IIS, możesz nawet nie zauważyć różnicy. Co innego, gdy tworzysz program za pomocą vima (:q) na Arch Linux.

Wiele systemów, wiele środowisk programistycznych

Tak, nie pomyliłeś(-aś) się czytając nagłówek. ASP.NET 5 działa na Windowsie, Macu i GNU/Linux. W przypadku Windowsa możesz użyć serwera IIS lub uruchomić aplikację jako self-hosted. Na pozostałych systemach pozostaje Ci tylko druga opcja (za pomocą miniserwera Kestrel; możesz też poczekać na jakiś sensowny serwer/mod do nginxa).

Według mnie, istotniejsza jest możliwość wyboru IDE. Visual Studio jest prawdziwym kombajnem. Nadaje się całkiem nieźle, jeżeli całą aplikację robisz samodzielnie (albo każdy programista robi wszystko po trochu). Problem pojawia się, gdy jesteś front-end developerem i nie potrzebujesz budowania całej aplikacji w ciężkim środowisku, jakim jest VS. Chcesz tylko co jakiś czas pobrać kod z repozytorium i sprawdzić, czy koledzy z zespołu nie popsuli modelu danych, które odbierasz. W takiej sytuacji możesz korzystać z Sublime Text + Kulture.

Nowa struktura projektu

Pamiętasz bałagan w projektach ASP.NET MVC? JavaScript, CSS i obrazki rozrzucone po kilku miejscach? Od teraz wszystkie statyczne elementy statyczne będziesz wrzucał(-a) do katalogu wwwroot. Co prawda widoki są oddzielone od załączanej do nich treści, ale daje to dość dobry rezultat. Kolejną zmianą jest podział projektu na źródła (/src) i testy (/test). Prawdę mówiąc wolałbym sortowanie projektów wg typu, ale dzięki dodaniu nowego poziomu hierarchii możliwa jest praca w dowolnym środowisku.

Struktura projektu ASP.NET 5

Node.js w ASP.NET

ASP.NET 5 korzysta z narzędzi takich jak:

NPM (Node Package Manager) - zarządca pakietów napisanych w Node.js/JavaScripcie,
Bower - zarządca pakietów dla aplikacji internetowych,
Grunt - program automatyzujący zadania front-endowe.

W dużym skrócie: za pomocą Bowera ściągamy front-endowe zależności takie jak Angular.js, Knockout etc. etc. Za pomocą Grunta uruchamiamy zadania, np. kompilacja TypeScript -> JavaScript, LESS -> CSS. NPM służy do pobrania Bowera, Grunta i gotowych skryptów dla Grunta.

Dzięki użyciu Bowera, zależności front-endowe i back-endowe zostały rozdzielone. Na obrazku wyżej jest to wyraźnie widoczne: front-endowe zależności w Dependencies, back-endowe w References. Dla back-endu w dalszym ciągu używać będziesz NuGeta.

Nowa wersja czy nowy framework?

Patrząc na ogromną liczbę zmian możesz dojść do wniosku, że powstał zupełnie nowy framework. Na szczęście nie wszystko zostało porzucone. Idea modeli, widoków i kontrolerów pozostała taka sama. Możliwe jest więc przeportowanie starej aplikacji MVC 5 na ASP.NET 5. Oczywiście nie obejdzie się bez zmian w kodzie. W szczególności czekam na nowe podejście do procesu uwierzytelniania i autoryzacji użytkowników.

Kiedy pełna wersja?

Podczas dotnetConf 2014 Daniel Roth wspomniał o terminie wydania wersji RTM. Microsoft planuje wydanie na pierwszy kwartał 2015 roku. Daje to niewiele ponad 4 miesiące od teraz. Zobaczymy czy dadzą radę. Osobiście im kibicuję. Zaplanowałem nawet oparcie pracy magisterskiej o nowy framework ;-)

Posłowie
O kilku rzeczach nie wspomniałem.

Pierwsza sprawa - kod ASP.NET MVC był od dawna publiczny. Nie było jednak możliwości współpracy przy jego tworzeniu. Microsoft dał możliwość dołożenia własnych cegiełek do projektu za pomocą mechanizmu pull requestów i issue trackera. Nowością jest też rozwijanie oprogramowania w czasie bliskim rzeczywistemu - nowe zmiany pojawiają się niemalże każdego dnia.

Druga sprawa - mam nadzieję, że zespół ASP.NETa się opamięta i zmieni nazwę projektu K. Już wyobrażam sobie szukanie rozwiązań za pomocą Google, StackOverflow etc. Trzecia sprawa - nawet, jeśli jesteś front-end developerem, zastanów się nad pisaniem aplikacji w Visual Studio. BrowserLink + Web Essentials dają niesamowitego kopa. Wygląd aplikacji możesz tworzyć/poprawiać w przeglądarce za pomocą narzędzi developerskich.

Na koniec uwaga co do samej nazwy frameworka. W tej chwili Microsoft przeplata kilka nazw tego samego: ASP.NET 5, ASP.NET MVC 6, ASP.NET vNext. Wybrałem pierwsze ze względu na fakt, że zmianie nie ulega sam framework MVC. Zmienia się cały ekosystem.

ASP.NET 5 + Raspberry Pi

Sat, 25 Oct 2014 09:40:12 -0500

Dzisiejszy odcinek jest sponsorowany przez problem zarządzania prywatnymi finansami. Wpadłem na pomysł zrobienia usługi + aplikacji klienckich (Web i Windows Phone) do zbierania danych o moich wydatkach. Mogłem oczywiście sprawę rozwiązać Excelem. Przeklikiwanie arkusza na telefonie nie należy jednak do najprzyjemniejszych rzeczy.

Rozważałem napisanie usługi w pythonie, jednak chciałem sprawdzić nowości na platformie firmy Microsoft. Ostatecznie wybór padł na ASP.NET vNext. Nowa wersja ASP.NET ma ogromną zaletę - łączy usługi Web API ze stronami WWW frameworka MVC. Dzięki temu, jestem w stanie napisać usługę REST i aplikację WWW opartą o Angular.js w jednym projekcie. Aplikacja będzie działała w trybie self-hosted na Raspberry Pi.

Czym jest ASP.NET 5?

W dużym skrócie, ASP.NET 5 (vNext) jest:

przyszłą, pisaną od nowa, wersją ASP.NET MVC (6),
połączeniem ASP.NET MVC, ASP.NET Web API i ASP.NET Web Pages,
otwartym kawałkiem kodu, który możemy dowolnie edytować.

Jedną z większych zalet ASP.NET 5 jest wieloplatformowość - aplikacje mogą być uruchamiane zarówno na Windowsie, jak i systemach GNU/Linux czy Mac OS X. Co istotne, wszystkie platformy są oficjalnie wspierane przez Microsoft.

Dlaczego Raspberry Pi?

Raspberry Pi było akurat pod ręką. Miniaturowy komputer leżał nieużywany w szafie i czekał aż z niego skorzystam. Miał służyć jako multimedialny hub, ostatecznie jednak postawiłem na usługi zewnętrzne (Spotify).

Instalacja pakietów

Zanim rozpoczniemy właściwą instalację, potrzebujemy kilkunastu pakietów. Większość z nich to zależności mono.

UWAGA: Moje Raspberry Pi działa pod kontrolą Raspbiana. Jeżeli posiadasz inny system operacyjny (np. Pidora), być może będziesz musiał/a skorzystać z innego managera pakietów (yum, pacman etc.).

Logujemy się przez SSH na Raspberry Pi.
Aktualizujemy repozytorium pakietów:

$ sudo apt-get update

Pobieramy niezbędne pakiety:

$ sudo apt-get install libcurl4-gnutls-dev libexpat1-dev gettext libz-dev libssl-dev build-essential git-core automake libtool libglib2.0-dev libxrender-dev libfontconfig1-dev libpng12-dev libgif-dev libjpeg8-dev libtiff5-dev libexif-dev mono-complete screen lynx

GNU Screen

Kompilacja mono trwa kilka godzin. W razie zerwania sesji SSH, proces zostanie przerwany. Rozwiązaniem jest wykonywanie poleceń w sesji screen. GNU Screen jest programem utrzymującym uruchomione zadania po wylogowaniu użytkownika. Posiada też inne zastosowania (podobno ktoś z nich korzysta). Uruchomienie nowej sesji sprowadza się do wykonania:

$ screen -S mono

Odłączamy się od sesji za pomocą skrótu CTRL + A, D. Po tej operacji możemy bez problemu się wylogować. Aby przywrócić odpiętą sesję, wystarczy wpisać:

$ screen -r mono

Voila. Możemy spokojnie odłączyć się od RPi w trakcie kompilacji.

Instalacja mono

Wszystko gotowe, czas zainstalować środowisko uruchomieniowe

Ściągamy najnowsze źródła mono:

$ sudo git clone git://github.com/mono/mono.git

Przechodzimy do repozytorium:

$ cd mono

Uruchamiamy konfigurator autogen:

$ sudo ./autogen.sh -prefix=/usr/local -enable-nls=no

Plotki mówią, że zamiast parametru -prefix/-enable-nls, konieczne może być użycie .prefix/.enable-nls.

Ściągamy binarkę mini-kompilatora C# monolite (część mono jest napisana w C#; żeby skompilować mono, musimy najpierw posiadać mono ;-))

$ sudo make get-monolite-latest

Kompilujemy mono:

$ sudo make EXTERNAL_MCS="${PWD}/mcs/class/lib/monolite/gmcs.exe"

Instalujemy mono:

$ sudo make install

Sprawdzamy, czy wszystko poszło zgodnie z planem...

$ mono -V
Mono JIT compiler version 3.10.1 (master/8d9f05e czw, 23 paź 2014, 20:16:10 CEST)

Super; możemy odpalić pierwszy program!

Uruchamiamy testowy program:

$ echo 'namespace Test { public static class TestClass { public static void Main() { System.Console.WriteLine("Hello, Mono!"); } } } ' > Main.cs
$ sudo chmod -x Main.cs
$ mcs Main.cs
$ mono Main.exe
Hello, Mono!

Jak widać, wszystko przebiegło pomyślnie. Możemy kompilować programy przeznaczone na platformę .NET 4.5 i niższe.

Instalacja ASP.NET vNext

Centralnym punktem frameworka ASP.NET vNext jest menedżer wersji kvm (K Version Manager). Za jego pomocą instalujemy różne wersje frameworka, a także przełączamy się między nimi.

Instalujemy kvm:

$ curl https://raw.githubusercontent.com/aspnet/Home/master/kvminstall.sh | sh &amp;&amp; source ~/.kre/kvm/kvm.sh

Przechodzimy do repozytorium:

Instalujemy najnowsze kre:

$ kvm upgrade

Wielki test

W celu sprawdzenia konfiguracji naszego nowego serwera ASP.NET vNext, uruchomimy prostą aplikację.

Ściągamy repozytorium:

$ git clone https://github.com/Keraxel/MvcNext.git &amp;&amp; cd MvcNext

Dodajemy certyfikaty (są niezbędne do pobrania zależności):

$ sudo certmgr -ssl -m https://go.microsoft.com
y
y
y
y
$ sudo certmgr -ssl -m https://nugetgallery.blob.core.windows.net
y
$ sudo certmgr -ssl -m https://nuget.org
y
y
$ mozroots --import --sync

Uzupełniamy zależności projektu:

~/MvcNext $ kpm restore -s https://www.myget.org/F/aspnetvnext/ -f https://nuget.org/api/v2/
~/MvcNext $ mv ~/.kpm/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-alpha4/native/darwin/universal/libuv.dylib ~/.kpm/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-alpha4/native/darwin/universal/libuv.dylib.backup
~/MvcNext $ cp libuv.so.1 ~/.kpm/packages/Microsoft.AspNet.Server.Kestrel/1.0.0-alpha4/native/darwin/universal/libuv.dylib

Uruchamiamy projekt:

~/MvcNext $ cd MvcNext
~/MvcNext/MvcNext $ k kestrel
Started

Działa! Możemy wejść do aplikacji: http://[ip]:5004/Users.

Aplikacja ASP.NET vNext na Raspberry Pi

Do aplikacji można się dostać również poprzez przeglądarkę Lynx, bezpośrednio na Raspberry Pi:

$ lynx http://[ip]:5004/Users

W następnym wpisie napiszę o samym ASP.NET vNext: zmianach, nowościach i niespodziankach, które zaserwował Microsoft.

Bundler w ASP.NET - przyspiesz ładowanie strony

Mon, 12 May 2014 06:52:46 -0500

Transmisja w Internecie przyspiesza z dnia na dzień. Jeszcze 15 lat temu na załadowanie prostej strony Interii z grą flash czekałem około minuty. Obecnie duże aplikacje internetowe obsługują setki tysięcy klientów w każdej sekundzie. Każde z żądań musi być obsłużone w przeciągu kilku sekund. Każde przeciążenie serwera jest potencjalną stratą dla właściciela aplikacji.

Drogi optymalizacji

Mam aplikację, która cieszy się popularnością. Obecnie nie stać mnie na skalowanie w którąkolwiek stronę, a użytkownicy zaczynają dostawać błąd HTTP 504 lub strona ładuje się potwornie długo. Co zatem mogę poprawić?

Istnieją dwie drogi warte sprawdzenia, a mianowicie:

zmniejszenie objętości komunikatów,
zmniejszenie liczby komunikatów.

Do zmniejszenia objętości komunikatów mogę wykorzystać mechanizm minifikacji (kompresji skryptów i styli), a także kompresję HTTP. W celu zmniejszenia liczby żądań do mojego serwera użyję bundlera i serwerów CDN.

Bundler

Na stronie głównej aplikacji mam dołączonych kilkadziesiąt plików CSS i JavaScript. Co się dzieje podczas ładowania strony? Przeglądarka dla każdego pliku wykonuje osobne żądanie HTTP! Jeżeli klient ma włączone cachowanie, zawartość plików zostanie załadowana jedynie raz. Przy kolejnych odwiedzinach serwer będzie zwracał HTTP 304. W ten sposób powstają dwa problemy:

serwer jest niepotrzebnie obciążany dodatkowymi zapytaniami,
klient wykonuje zbędne zapytania, co wydłuża czas ładowania strony.

Problem można częściowo rozwiązać za pomocą bundlera. Bundler jest narzędziem łączącym kilka plików w jeden. ASP.NET używa do tego celu biblioteki Microsoft ASP.NET Web Optimization Framework. Wdrożenie “paczkowania” jest bardzo proste.

Chcę połączyć zawartość styli załączonych za pomocą kodu:

<link href="/Content/bootstrap.css" rel="stylesheet">
<link href="/Content/site.css" rel="stylesheet">

W pierwszym kroku wybieram pliki, które chcę scalić. Dodaję wpis do pliku App_Start\BundleConfig.cs (na końcu funkcji RegisterBundles()):

bundles.Add(new StyleBundle("~/Content/css").Include(
    "~/Content/bootstrap.css",
    "~/Content/site.css"));

W drugim kroku możemy już skorzystać z bundla. W treści mojego widoku zastępuję stary kod HTML za pomocą kodu:

@Styles.Render("~/Content/css")

W wyniku tej operacji ASP.NET załącza do dokumentu jeden styl CSS, który jest sklejeniem dwóch wymienionych plików:

<link href="/Content/css?v=Bz3KZjU_pdOm2wAVr7z_ylCuQzQDs1O8N6pV4cvXc_Q1" rel="stylesheet">

Minifikacja

Otwierając otrzymany plik widzę nietypową zawartość:

article,aside,details,figcaption,figure,footer,header,hgroup,main,nav,section,summary{display:block}audio (...)

Powstała paczka jest pozbawiona zbędnych białych znaków i komentarzy - jest zminifikowana. Spakowanie danych w ten sposób pozwala na zmniejszenie wielkości pliku nawet o kilkadziesiąt procent. W przypadku plików JavaScript minifikacja idzie o krok dalej. Skraca nazwy lokalnych funkcji i zmiennnych. W związku z tym plik jest jeszcze mniejszy, co oszczędza przepustowość serwera. Zminifikowane wersje skryptów i styli zazwyczaj są dostarczane wraz z oryginalnym kodem źródłowym w paczce NuGet. Jeżeli tak nie jest, możesz użyć narzędzia do minifikacji, np. Web Essentials. Istotne jest, aby zminifikowany skrypt/styl miał taką samą nazwę jak oryginał, a zmieniony format na .min.js/.min.cs (np. script.js -> script.min.js).

Serwery CDN

Serwery CDN są publicznymi repozytoriami popularnych skryptów i arkuszy stylów (np. bootstrap, jquery, angular.js). Utrzymywane są przez dużych dostawców usług internetowych, np. Google. Korzystanie z nich rozwiązuje problem ograniczenia liczby połączeń, a także ułatwia korzystanie z cache przeglądarku.

Ograniczenie liczby połączeń w przeglądarkach WWW

Przeglądarki internetowe mają domyślnie ograniczoną liczbę połączeń z danym serwerem. Jeżeli moja aplikacja będzie miała zbyt wiele zależności w osobnych plikach, nie wszystkie będą pobierane równolegle. Użycie serwera CDN zmniejszy licznik równoległych połączeń dla serwera mojej aplikacji.

Internet Explorer 7 i kilka innych przeglądarek ograniczają liczbę połączeń na serwer do dwóch. W przypadku pisania aplikacji internetowej dla starszych przeglądarek użycie CDNów może dać istotne przyspieszenie ładowania strony.

Cache

Popularne skrypty/style z serwerów CDN prawdopodobnie znajdują się już w cache przeglądarki użytkownika. Zysk jest oczywisty - klient nie musi ponownie pobierać skryptu/stylu.

Popularne serwery CDN

Serwery z których korzystam to:

Fallback, czyli co zrobić, gdy serwer CDN nie odpowiada

Czasem zdarza się sytuacja, w której klient nie ma połączenia z serwerem CDN. W takiej sytuacji moja strona załaduje się bez niezbędnych skryptów. Rozwiązaniem tego problemu jest tzw. fallback, czyli załączenie biblioteki z mojego serwera w przypadku awarii CDN. Implementacja w HTML/JS jest niezwykle prosta:

<script src="//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<script>
if(!window.jQuery){
    document.write('<script src="/path/to/your/jquery"></script>');}
</script>

Oczywiście przy takim podejściu tracimy możliwość globalnej zmiany załączonego skryptu w BundleConfig.cs. Na szczęście ASP.NET wspiera fallback:

bundles.UseCdn = true;
var jquery = new ScriptBundle("~/bundles/jquery", "//ajax.aspnetcdn.com/ajax/jquery/jquery-2.1.1.min.js")
    .Include("~/Scripts/jquery-{version}.js");
jquery.CdnFallbackExpression = "window.jQuery";
bundles.Add(jquery);

ASP.NET obsługuje również fallback dla arkuszy CSS, jednak rozwiązanie problemu ze stylami jest nieco trudniejsze. Więcej informacji znajdziesz tutaj.

Bundler vs CDN

Co jest bardziej opłacalne: połączenie kilku skryptów w jeden i dołączenie do dokumentu HTML, czy załączenie każdego osobno za pośrednictwem CDNów? Jeżeli masz możliwość, użyj serwerów CDN. Bundler jest świetnym rozwiązaniem w przypadku własnych lub mało popularnych skryptów.

Kompresja HTTP (IIS)

Serwer IIS ma możliwość kompresowania treści komunikatów osobno dla plików statycznych i generowanych dynamicznie. Istnieje 10 poziomów kompresji. Każdy kolejny daje większy stopień kompresji przy jednoczesnym większym zużyciu czasu procesora. Co więcej, IIS ma możliwość wyłączenia kompresji przy dużym obciążeniu CPU. Powołując się na ten test, ustaliłbym poziom kompresji następująco:

pliki statyczne: 7-9, w zależności od częstości używania plików (pliki statyczne są cachowane),
pliki dynamiczne 0-4, w zależności od klientów (np. klienci mobilni mają ograniczone możliwości przesyłania danych przez sieć komórkową).

Pimp my bundler

Poniżej znajdziecie ściągę dla popularnych skryptów, wraz z fallbackami:

// jQuery
var jquery = new ScriptBundle("~/bundles/jquery", "//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js")
{
    CdnFallbackExpression = "window.jquery"
};
jquery.Include("~/Scripts/jquery-{version}.js");
bundles.Add(jquery);

// jQuery UI
var jqueryUi = new ScriptBundle("~/bundles/jquery", "//ajax.googleapis.com/ajax/libs/jqueryui/1.10.4/jquery-ui.min.js")
{
    CdnFallbackExpression = "window.jquery.ui"
};
jqueryUi.Include("~/Scripts/jquery-{version}.js");
bundles.Add(jqueryUi);

// Bootstrap JS
var bootstrap = new ScriptBundle("~/bundles/bootstrap", "//netdna.bootstrapcdn.com/bootstrap/3.1.1/js/bootstrap.min.js")
{
    CdnFallbackExpression = "$.fn.modal"
};
bootstrap.Include("~/Scripts/bootstrap.js");
bundles.Add(bootstrap);

// Respond.js
var respondjs = new ScriptBundle("~/bundles/respondjs", "//cdnjs.cloudflare.com/ajax/libs/respond.js/1.4.2/respond.js")
{
    CdnFallbackExpression = "window.respond"
};
respondjs.Include("~/Scripts/respond.js")
bundles.Add(respondjs);

// Moment.js
var momentjs = new ScriptBundle("~/bundles/momentjs","//cdnjs.cloudflare.com/ajax/libs/moment.js/2.6.0/moment.min.js")
{
    CdnFallbackExpression = "window.moment"
};
momentjs.Include("~/Scripts/moment.js");
bundles.Add(momentjs);

Automatyczny deploy na Windows Azure

Wed, 18 Dec 2013 20:51:12 -0600

Automatyzacja deployowania pozwala na skupienie się na pisaniu aplikacji. Skutecznie eliminuje martwienie się o umieszczanie kolejnych wersji oprogramowania na serwerze. Narzędzia opisane w tym poradniku pozwalają na przełączanie pomiędzy kilkoma ostatnimi wersjami naszego projektu, a także automatycznie uruchamiają automatyczne testy (np. testy jednostkowe), oczywiście jeżeli zostały dołączone do solucji. W skrócie, będziesz miał/a mniej roboty z pierdołami.

Wymagania

Visual Studio 2013,
Windows Azure SDK dla platformy .NET (http://www.windowsazure.com/pl-pl/downloads/),
Konto Microsoft (dawniej Live ID).

Krok 1. Zakładamy konto na platformie Visual Studio Online

Visual Studio Online (dawniej Team Foundation Service), jest internetowym narzędziem służącym do zarządzania projektem i kontroli wersji kodu.

Wchodzimy na stronę: http://www.visualstudio.com/,
Logujemy się za pomocą konta Microsoft,
Przechodzimy przez kolejne kroki, podając nazwę naszego VS Online.

Krok 2. Zakładamy konto Windows Azure

Windows Azure jest publiczną chmurą Microsoftu, pozwalającą na umieszczanie naszych aplikacji bez zbędnego konfigurowania serwera. W scenariuszu, którego użyjemy, aplikacja trafi na Azure Web Sites – kontener służący do przechowywania aplikacji internetowych, np. ASP.NET.

Wchodzimy tutaj: http://www.windowsazure.com/pl-pl/pricing/free-trial/,
Zakładamy nowego triala.

Uwaga! Do rejestracji potrzebna będzie karta płatnicza. Strony internetowe w podstawowym planie są bezpłatne (do 10 sztuk), jednak jest to wymóg, w razie podniesienia planu lub użycia innych usług. Dla pewności skorzystaj z karty prepaidowej. W wielu bankach takie karty są darmowe.

Krok 3. Dodajemy nowy projekt do VS Online

Wchodzimy do naszego VS Online: twojaunikalnanazwa.visualstudio.com,
Zakładamy nowy projekt, wybierając jako system kontroli wersji Git:

Rysunek 1. Przycisk dodawania nowego projektu

Rysunek 2. Formularz dodawania nowego projektu

Wchodzimy do naszego projektu i przechodzimy do zakładki Code,
Umieszczamy nasz kod w repozytorium zgodnie ze wskazówkami:
1. Jeżeli mamy już założony projekt w środowisku Visual Studio:
  1. dodajemy go do kontroli wersji,
  2. dodajemy połączenie ze zdalnym repozytorium i synchronizujemy kod.

Rysunek 3. Łączenie Visual Studio ze zdalnym projektem VS Online

Rysunek 4. Publikowanie lokalnego repozytorium do aktualnie połączonego projektu VSO

Rysunek 5. Komunikat potwierdzający umieszczenie kodu w repozytorium VS Online

Jeżeli nie mamy kodu, tworzymy nowy projekt w Visual Studio, a następnie wracamy do punktu a.

Microsoft opublikował instrukcję dot. Gita w Visual Studio.

Krok 4. Zakładamy nową stronę na Windows Azure

Wchodzimy na Windows Azure Management Portal,
Dodajemy nową aplikację, klikając na przycisk New (lewy dolny róg okna):

Rysunek 6. Interfejs dodawania usług Windows Azure

Rysunek 7. Dodawanie Azure Web Site, krok 1.

Wkroku 1. (rysunek 7.) wybieramy nową, darmową bazę SQL. Unikniemy w ten sposób niepotrzebnych kosztów. Podajemy adres, pod którym będzie dostępna nasza aplikacja. Stronę umieszczamy w regionie West Europe, gdyż jest to lokalizacja najbliższa Polsce.

Rysunek 8. Dodawanie Azure Web Site, krok 2.

W kroku 2. (rysunek 8.) dodajemy nowy serwer SQL. Podajemy nazwę serwera, a także nazwę i hasło użytkownika. Serwer umieszczamy również w West Europe.

Rysunek 9. Dodawanie Azure Web Site, krok 3.

W kroku 3. (rysunek 9.) wybieramy serwer repozytoriów – Visual Studio Online.

Rysunek 10. Dodawanie Azure Web Site, krok 4.

W kolejnym kroku (rysunek 10.) podajemy adres naszego zbioru projektów. Następnie naciskamy przycisk Authorize Now. W nowym oknie klikamy przycisk Accept.

Rysunek 11. Dodawanie Azure Web Site, krok 5.

W kroku 5. (rysunek 11.) wybieramy repozytorium, z którego Azure ma pobierać kod źródłowy.

Automatyczny deploy na Windows Azure

Po zaakceptowaniu formularza, nasza konfiguracja dobiegła końca. Wystarczy wypchnąć następną wersję projektu na repozytorium. Windows Azure samodzielnie pobierze nasze zmiany, skompiluje kod i umieści go jako aktualnie działającą aplikację.

Asynchroniczność w ASP.NET - wprowadzenie

Thu, 12 Dec 2013 07:51:17 -0600

Asynchroniczność w ASP.NET to temat, który ostatnio przewija się gdzie nie spojrzę. Microsoftowy zespół od ASP.NET kilka miesięcy temu postanowił zatruć życie początkującym programistom tej platformy. Jak to się stało? Otóż w nowej wersji MVC usunęli starą bibliotekę do zarządzania uwierzytelnianiem i autoryzacją użytkowników. Co do samej zmiany nie będę się wdawał w szczegóły - jak wszystko, ma swoje dobre i złe strony. Istotne jest to, że szablon dla nowych aplikacji ASP.NET MVC 5 jest wypchany wywołaniami metod z końcówką Async. Większość tego postu odnosi się do wszystkich aplikacji internetowych, nie tylko ASP.NET, czy innych frameworków .NETowych.

Po co wielowątkowość w aplikacjach internetowych?

Aplikacje internetowe z natury muszą być wielowątkowe. Wyobraźmy sobie sytuację, gdzie do naszego serwera WWW przychodzą równocześnie sto żądań HTTP. Jeżeli nie rozdzielimy obliczeń:

nie wykorzystujemy w pełni naszego procesora - po co 8 rdzeni na serwerze, skoro wszystkie obliczenia wykonujemy na jednym?
prosimy się o atak odmowy dostępu - nasz system operacyjny nie będzie kolejkował żądań.

Oczywiście developerzy samej aplikacji nie muszą się tym zwykle przejmować. Umieszczając aplikację na serwerze WWW (IIS, Apache etc.) mamy ten problem z głowy. O co więc chodzi z tym wpisem? Kolejkowanie żądań czasem nie wystarczy.

Kiedy powinienem pisać asynchronicznie?

Zasadniczo, powody są trzy:

wykonujesz operację na systemie plików (bazy danych też zwykle trzymane są na dysku),
używasz zdalnego API (np. wrzucasz zdjęcia kotów na Facebooka),
wykonujesz skomplikowane obliczenia, które można zrównoleglić.

Pierwsze dwa przypadki są do siebie podobne - oddajemy obliczenia do innego urządzenia (kontroler dysku, zdalny serwis). Co się wtedy dzieje z naszym wątkiem, w którym obsługujemy żądanie? Nasz wątek czeka. A mógłby robić inne rzeczy… :-)

Asynchroniczność to nie same zalety

Jak się możecie domyślać, wątki też kosztują. Zwykle serwery WWW mają dostępną pulę wątków, dzięki czemu nie musimy ich tworzyć i zabijać. Kosztem jest jednak przełączanie się pomiędzy wątkami, odpowiednia synchronizacja i przekazywanie danych.

Kolejna sprawa - klasyczne programowanie wielowątkowe jest trudne, musimy unikać zakleszczeń. W kolejnych wpisach pokażę, jak .NET 4.5 pozwala uniknąć tego problemu.

Na koniec zostaje perełka, a mianowicie: aplikacja musi być asynchroniczna “all the way”. Co to znaczy? Jeżeli napiszemy asynchroniczne repozytorium (np. do zapisywania danych do BD), to asynchroniczne musi być również wszystko, co wywołuje naszą metodę - serwis, kontroler, framework. W kolejnych wpisach przedstawię jak wygląda obecnie ASP.NET MVC i Entity Framework pod kątem asynchroniczności, a także jak możecie to wykorzystać.

Ehlo Wurld

Wed, 11 Dec 2013 18:58:56 -0600

Paw paw.

Rebootuję bloga. Będzie więcej. Będzie technicznie. Będzie z dystansem. Będą łzy, trudne sprawy i przelewanie krwi. Cyfrowej, oczywiście. Tematem będzie to, czym obecnie się zajmuję - ~~różowe kucyki~~ informatyka. A właściwie świeże spojrzenie na nią, moim okiem oczywiście.

Zapraszam do czytania!

A, będą jeszcze obrazki. Duże.