1. Nigdy nie używaj czasowników w URI.

Przykład błędnych linków:

GET: localhost\persons\1\UpdateEmail?email=’…’

Jedynym dozwolonym czasownikiem w adresie to HTTP verb. Całość linku to nic innego jak hierarchia zasobów. Poprawna aktualizacja adresu email może wyglądać zatem następująco:

PUT: localhost\persons\1\email

Metoda PUT oznacza, że mamy do czynienia z modyfikacją danych. UpdateEmail to nazwa metody, a nie zasobu co jest sprzeczne z REST. Adres email’a w przypadku PUT można umieścić w ciele zapytania.

Analogicznie jeśli chcemy odczytać dane osoby, nie powinniśmy:

GET localhost\persons\1\getdata

Poprawny adres to:

GET localhost\persons\1\data

2. REST != RPC.  

Osoby zaczynające z REST, często próbują korzystać z tego typu usług tak samo jak np. z WCF. Klasyczne RPC (Remote-Procedure-Call) polega na wykonaniu konkretnej metody na usłudze. REST to hierarchia zasobów  więc powinniśmy tworzyć linki w postaci:

localhost/persons/1/address/town

Widzimy, że operujemy tutaj na kilku poziomach. Niepoprawną z kolei postacią jest:

localhost/persons/gettown?id=1

Wynika to nie tylko z użycia czasownika w nazwie, ale również w operowaniu bezpośrednio na korzeniu zasobów, zamiast na wykorzystaniu całej dostępnej hierarchii.

3. Korzystaj z dostępnych metod  HTTP.

Jeśli chcemy usunąć zasób wtedy:

DELETE local/host/persons/1

Początkujące osoby zbyt często korzystają wyłącznie z GET. Jeśli usługa ma realizować zadania CRUD, wtedy zdecydowanie potrzebujemy POST,GET,PUT,DELETE.

4. Korzystaj z dostępnych statusów HTTP.

Status 200 (OK) zdecydowanie nie jest jedynym z którego możemy korzystać. Jeśli operacja nie uda się, wtedy oprócz zwrócenia błędu w ciele HTTP, należy zwrócić również kod np. 500 (Internal Error) albo 400 (Bad Request) w zależności od kontekstu. Kody od 400 to błędy spowodowane przez klienta (np. nieprawidłowe zapytanie), z kolei od 500 to błędy spowodowane przez serwer.

Jeśli tworzymy nową encję za pomocą HTTP POST, można zwrócić 201 (Created) zamiast po prostu 200 (OK), który bardziej nadaję się na zapytania HTTP GET.

Inny przykład to kod 204 (No content). Jeśli użytkownik wywoła localhost/persons/5, a osoba o identyfikatorze 5 nie istnieje, wtedy zamiast 200 należy zwrócić kod 204.

5. QueryString

Klasyczne parametry QueyString wciąż są dozwolone, ale nie powinny określać one zasobów. Innymi słowy, złą praktyką jest:

localhost/persons?id=1

Identyfikator w tym przypadku jest ściśle powiązany z zasobem. Dopuszczalne jest za to używanie QueryString do określenia np. sortowania:

lcoalhost/persons?sort=desc

Podobnie sprawa wygląda z filtrowaniem czy z innymi parametrami, które nie określają zasobów a po prostu np. ich sposób wyświetlania.

6. Zwrócenie stanu obiektu po aktualizacji.

Utworzenie zasobu lub jego aktualizacja (POST, PUT) powinny zwracać jego reprezentacje albo link, który umożliwia odczytanie pełnego stanu. Innymi słowy, po utworzeniu zasobu, ciało odpowiedzi nie może być puste. Zwykle zwraca się mapę linków\operacji, które można wykonać na nowo utworzonym zasobie.

7.  Usługa powinna być bezstanowa.

Umożliwia to łatwiejsze skalowanie jak i cachowanie. Oznacza to, że wywołanie danej akcji, nie powinno zależeć od wykonania wcześniejszych operacji. Oczywiście mowa o stanie usługi, a nie aplikacji, gdzie stan stanowi zestaw reguł biznesowych. Z tego względu, autoryzacja nie powinna bazować na ciasteczkach czy sesjach ponieważ łamią one tą zasadę. Lepiej przesyłać dany token w każdym zapytaniu. Innymi słowy, każde zapytanie powinno dostarczyć wszystkie niezbędne dane do wykonania akcji.

Strange Loop

At the Strange Loop I presented Aurelia – the next generation JavaScript Framework:

Strange Loop is an intersection of everything: from Researchers, through programmers maintaining 20 years old systems that still works, Web Developers using the latest Frameworks (like React), Web Developers using mature (AKA ‘old’) frameworks (like Spring), DevOps deploying with Docker, large scale distributed systems architects, to Common Lisp fans. The most important thing is – most of the people at this conference are real passionate programmers. I really recommend you to check out Sam Aaron’s session: Beating Threads – live coding with real time. Sam is a researcher who created programming environment that allows you to compose music by writing code. Something that can be used today, which is cool, and he presented it with such a passion that cannot be described by words.

All videos from Strange Loop are available on their YouTube channel.

If you think that now everyone is creating Web Apps and Mobile Apps – go to Strange Loop! You will see a different World.

NCDevCon

I’ve been at NCDevCon only for the day two, because of overlap with Strange Loop, and I presented how TypeScript helps to build large scale applications. Unfortunately, there is no video from my session, because just before my talk there was a power outage. I, and other speakers (if they still had battery), had to present from laptops while people were looking from behind our shoulders.

I gave similar talk earlier this year at .NET Developers meetup in Redmond. You can find video and slides in this blog post.

At NCDevCon I’ve seen only 3 sessions, because 1 hour after my session, in addition to power outage, the fire alarm started beeping, and the rest of the conference was cancelled. Videos from day 1, and maybe some from day 2 (if speakers record them at home) will be available at NCDevCon.com.

This conference was more down to Earth for me, as everybody was talking about Web and Mobile. You can find more detailed overview in this blog post.

On my way back from Raleigh, NC (where NCDevCon took place) I had connection flight in Minneapolis, MN. This gave me an opportunity to see the airport of XXI century: power outlets everywhere, free WiFi, and iPads for free public use (utilized also for ordering food at restaurants).

p ;-).

Ponad cztery lata minęły od publikacji tekstu o wdzięcznym tytule “Szkolenia programistyczne, czyli maszyna ssąco-uciszająca“. Ależ wtedy sobie ulżyłem. Nadszedł czas na refleksje trochę z drugiej strony: skupię się na zaletach szkolenia-sukcesu, a nie wadach szkolenia-porażki. Szklanka jest w połowie pełna, nie?

Praktyka > teoria

Programista to taki zwierz, który z internetu korzystać umie jak mało kto. Logiczne, prawda? Jaki jest więc sens sadzania go w ławce i recytowania do jego uszu informacji, które odnajdzie w ciągu 5 minut obcowania z Google? Ano wydaje mi się, że… średni.

Przy okazji CraftConf 2015 wraz z Robertem uczestniczyliśmy w całodniowym warsztacie na temat mikroserwisów. Realizujemy projekt w tej “architekturze”, więc chcieliśmy przekonać się, ile jeszcze o tym nie wiemy. Prowadzący sroce spod ogona nie wypadł, bo był to koleś z Thoughtworks. Okazało się niestety, że przez bite 7 godzin nawet nie trzeba było otworzyć swoich laptopów. Ot, pooglądaliśmy slajdy, posłuchaliśmy i wyszliśmy. Bardzo, bardzo średnio. Wyszła z tego “jednoosobowa mikrokonferencja” o mikroserwisach, a nie szkolenie czy warsztat.

Szkolenie powinno obfitować w ćwiczenia praktyczne. Takie, które zaangażują zerojedynkowego dev-ducha. Moim zdaniem szkolenia w postaci warsztatów są o wiele bardziej wartościowe niż czysto teoretyczne wykłady. Oczywiście podstawy teoretyczne także muszą się pojawić, ale programista powinien robić głównie to, co lubi najbardziej, czyli: kombinować, zmagać się z wyzwaniami i rozwiązywać problemy za pomocą kodu! Od razu zastosować w praktyce wszystko to, o czym jest mowa. Teoria to tylko odpowiedni wstęp, podkładka.

W tym kontekście bardzo, ale to bardzo podoba mi się poniższy cytat:

Tell me and I forget. Teach me and I remember. Involve me and I learn.

(Benjamin Franklin)

Dobrze skonstruowane, ciekawe zadania mają jeszcze jedną zaletę: już dzień po szkoleniu programista może wziąć zdobytą wiedzę i zastosować ją w praktyce! Jeżeli jednym z ćwiczeń będzie, na przykład, odpowiednia konfiguracja kontenera Dependency Injection w aplikacji webowej i pokrycie tej konfiguracji testami, to co zrobi uczestnik szkolenia gdy następnym razem będzie musiał taką czynność wykonać? Wróci do materiałów szkoleniowych, przypomni sobie jak zostało to zrealizowane i DLACZEGO, a następnie świadomie zrealizuje część swojej codziennej pracy. Wiedząc dlaczego działa tak a nie inaczej, bez copy/paste ze StackOverflow.

Ale przecież każdy problem programistyczny można rozwiązać na wiele sposobów. Nie ma jednego idealnego złotego środka!

Jak najbardziej, dlatego też potrzebny jest:

Czas na dyskusje

Szkolenie, w przeciwieństwie do prezentacji na konferencji, to komunikacja w obie strony. A nawet w “trzy strony”: trener -> uczestnicy, uczestnicy -> trener oraz uczestnicy <-> uczestnicy! Komunikacji powinno być jak najwięcej. Pytania, dywagacje, wymyślanie dodatkowych scenariuszy i najlepszych sposobów na uporanie się z przedstawianym problemem – to wtedy tak naprawdę powstaje faktycznie pożądana agenda szkolenia. Każdy w sali powinien mieć okazję do wypowiedzenia się, podzielenia swoimi refleksjami i doświadczeniami. Zabierając głos nie chciałbym usłyszeć: “cicho, bo nie wyrobimy się z materiałem”.

Często te dwa czy trzy dni szkolenia to najlepszy czas na szczerą komunikację nawet w samym zespole, wśród uczestników! Być może na co dzień pracują w innych projektach i widują się przelotnie na kawie w kuchni, a może i to nie. Podczas szkolenia sami mogą lepiej się poznać i wspólnie wpaść na pomysł rozwiązania problemu dręczącego ich w codziennej pracy. Szkolenie to nie tylko “flow trenerskiej wiedzy”, ale również “team building”, jakkolwiek tego wyrażenia nie znoszę :). Jego charakter często jest nie tylko edukacyjny, ale i – w rozsądnych granicach – rozrywkowy.

Ja wolałbym skończyć szkolenie chwilę przed czasem (w razie braku dyskusji), niż siedzieć godzinę dłużej z pękającą głową, bez oddechu i możliwości wyrażenia swojego zdania, czekając tylko na koniec bo “kotlety w domu ubite, kartofli kipio, żonka zła, a ja jeszcze w robocie”.

Ważne jest również jednak do kogo się “swoje zdanie wypowiada”. Tutaj kluczowe okazuje się być:

Doświadczenie

Znam niestety przypadki szkoleń, podczas których jedyna różnica w wiedzy pomiędzy trenerem a uczestnikami jest taka, że trener ma jakiegoś “training kita”, czy jak to się nazywa. Czyta z książki po kolei co ma do przeczytania, a jeśli w książce nie ma na jakiś temat informacji, to po pojawieniu się trudniejszego pytania na sali słychać tylko… skowyt świerszczy ;).

Często wynika to z bardzo prostej przyczyny: brak doświadczenia praktycznego. Nie da się przygotować dobrego szkolenia z tematu, nad którym sam się człowiek nie natrudził, nie nagarbił, nie namęczył. Nawet podczas prezentacji wiedzy z książki, artykułu czy “encyklopedii”, osobiste doświadczenia szkoleniowca dają o sobie znać, przepuszczając wszystkie podane informacje przez bardzo wartościowy filtr: “ja WIEM jak to się sprawdza”.

Trener mówiący o testach powinien pisać testy. Trener mówiący o wdrożeniach powinien realizować wdrożenia. Wreszcie: trener mówiący o <TFU TFU przez lewe ramię, i prawe też na wszelki wypadek> SharePoincie, powinien w tym SharePoincie siedzieć po uszy! W przeciwnym wypadku: od razu widać braki. Widać, gdzie się zmyśla informacje na bieżąco. Kiedy się WIE, a kiedy się “gdyba”. I takie gdybanie, jeśli ma kamuflować brak doświadczenia, wygląda dość kuriozalnie. A nawet żałośnie.

Ale czy niezbędna jest alfa i omega? W praktyce: zdrowo jest zdawać sobie sprawę z tego, że nikt nie wie “wszystkiego” o “wszystkim”. Ba, nikt nie wie “wszystkiego” o “czymkolwiek”! Choćby nawet wydawało się inaczej. Zamiast tego co powiecie na to:

Trener członkiem zespołu

Takim jak wszyscy inni. Ze swoją wizją, bogatym doświadczeniem, rozległą wiedzą na eksperckim poziomie w prezentowanym obszarze, ale jednak… omylnym? Nie ma wszechwiedzących guru. Nie w “realu”, poza internetem :).

Miałem doświadczenia ze szkoleniowcami broniącymi niedających się obronić teorii. Ignorujących sensowne argumenty. Zamykających oczy na rzeczywistość inną niż ta przez nich kreowana. Puszczających mimo uszu niewygodne pytania. Bo przecież “trenerowi nie wypada się przyznać do błędu”. Lub “nieprzewidzenia wszystkich możliwych scenariuszy”. Tak? A no nie! Takie podejście nie zachęca bynajmniej do dalszych dyskusji. Ile zespołów – tyle problemów. I to niejednokrotnie tak pokręconych, że po prostu nie da się ich przewidzieć podczas przygotowywania materiału szkolenia.

W swojej “trenerskiej karierze” miałem już historię, kiedy to musiałem zmienić program szkolenia, bo jeden z zespołów uznał, że prezentowane przeze mnie podejście jest… dalekie od ideału. Podczas kilkuminutowej dyskusji uargumentowali to na tyle dobrze, że po prostu przyznałem rację. Nie jest to proste, gdyż materiał szkoleniowy powstaje przez naprawdę bardzo długi czas, dojrzewa i jest szlifowany, wydaje się być dopracowany w najmniejszych szczegółach… Czasami jednak spojrzenie kolejnych oczu z innej perspektywy burzy ten słodki obrazek i wychwytuje niedoskonałości. I to dobrze gdy tak się dzieje! W omawianym przypadku wspólnie wypracowaliśmy najlepszą alternatywę, pośmialiśmy się, i od razu po powrocie do domu poprawiłem materiał zgodnie z ich sugestiami. Kolejna edycja tego szkolenia będzie więc lepsza niż wszystkie poprzednie.

To buduje zdrową relację. Atmosferę dialogu. Zachęca do poszanowania wzajemnych – różnych przecież! – doświadczeń. Szkoleniowiec nie dostarcza wyrytych w skale przykazań, na pytania odpowiadając “BO TAK!”. Nie jest “jedynym mądrym w sali pełnej debili”. To by było strasznie smutne.

Skoro tak, to szkoda byłoby spędzić te wspólne chwile na przeciąganiu kontrolek po designerze, czyż nie?

Bez marnowania czasu

Niedawno rozmawiałem z firmą, która podczas zamawiania szkolenia upewniała się: “czy nie będzie tak, że połowę czasu spędzimy na konfigurowaniu środowiska i zadaniach pobocznych?”. Ano właśnie…

Czy programiści są w stanie w trakcie jednego szkolenia napisać cały skomplikowany system? Prawdopodobnie nie. Dlatego do każdego ćwiczenia, skupiającego się na wybranym elemencie zagadnienia, powinno być stworzone odpowiednio skonfigurowane środowisko. Czy to kawałki już napisanego kodu: wymaganego, a niemającego związku z zadaniem. Czy to gotowy skrypt instalujący potrzebne narzędzia/rozszerzenia. Czy to, w najbardziej rozbudowanych przypadkach, nawet cała maszyna wirtualna!

Nie oszukujmy się: nawet małpa byłaby w stanie wziąć myszkę w dłoń i poprzeciągać kontrolki z toolbara na designer. I czułem się właśnie jak małpa na szkoleniu, w trakcie którego na podobne – powtarzalne, nudne, banalne – zadania przewidziana była godzina.

Nienawidzę marnowania czasu: “ani swojego, ani bliźniego”. Zadania podczas szkolenia powinny mieć cel. Każde powinno wnosić coś nowego. Wymagać skupienia, uwagi i zaangażowania, ale nagradzać satysfakcjonującymi rezultatami.

A do tego wszystkiego, na koniec – okrasa:

Pasja i inspiracja

Bardzo pożądaną cechą u szkoleniowca jest to, aby prezentował coś więcej niż “tylko” materiał aktualnego szkolenia. Owszem, odpowiednie przygotowanie tych kilku(nastu) godzin jest niezmiernie ważne, ale co jeśli dodatkowo w trakcie spotkań da się… zmienić podejście do zawodu programisty?

Będąc smutasem, “odbębniającym te kilka godzin dziennie w dev-kopalni i do domu”, którego na chwilę wygonili z “cubicle” na szkolenie żeby wymusić przedłużenie lojalki, wbrew pozorom największą korzyść mogę wynieść nie z zawartości sladjów czy ćwiczeń, a z… rozmowy. W przerwach, przy obiedzie czy przy poszkoleniowym browarze. Z rozmowy z kimś, kto z zawodu programisty czerpie pełnymi garściami: jeździ na konferencje, uczestniczy w życiu lokalnych grup pasjonackich, potrafi wskazać drzwi do dev-społeczności i nazwiska warte poznania. Z kimś, kto może pokazać, ilu świetnych rzeczy związanych z programowaniem nie widać z tego “cubicle”. Z kimś, kto może na długo zmienić stosunek do wykonywanej pracy, otworzyć oczy na “dev-świat”. Wszędzie da się znaleźć możliwości rozwoju oraz zwiększenia satysfakcji z “roboty”, tylko trzeba wiedzieć gdzie tego szukać. Bywało już tak, że między jednym a drugim dniem szkolenia umawiałem się na występ na lokalnej grupie pasjonackiej. I gorąco zachęcałem cały zespół, aby wybrali się tam ze mną. Szczególnie jeśli byłby to ich pierwszy raz.

I co dalej?

Z wystąpieniami publicznymi przetestowałem pewien proces. Najpierw zdefiniowałem taką prezentację, jaką sam bym chciał oglądać. Prezentację “dobrą”, która nie jest marnowaniem czasu widza. A następnie zacząłem takie właśnie prelekcje przygotowywać i z nimi jeździć po konferencjach oraz grupach pasjonackich. Efekt? 28 prezentacji w przeciągu najbardziej intensywnych 20 miesięcy (niektóre można obejrzeć tutaj: Video). A co najważniejsze z mojego punktu widzenia: podobają się publiczności!

Wtrącenie:
Zachęcam do zapoznania się z moją ofertą szkoleń na http://www.maciejaniserowicz.com/szkolenia/. Znajdziesz tam agendę kilku proponowanych tematów (testy, SOLID, CQRS, mikroserwisy), a następne (wzorce projektowe, kontrola wersji…) czekają na swoją kolej. Każdy program można pobrać jako ładny PDF i podesłać osobom odpowiedzialnym za organizację szkoleń Twojej w firmie. Do zobaczenia?

Dodatkowo zachęcam do zapisania się na newsletter: http://eepurl.com/bw_LL5. Informacje o szkoleniach otwartych będą znajdować się najpierw tam, wraz z kuponami zniżkowymi.

Podobnie postąpiłem i tym razem. Kiedyś wylałem swoje żale odnośnie szkoleń – no i dobra, ale nic z tego nie wynikło, poza poklepaniem się po plecach z innymi programistami. Potem zastanowiłem się (dość długo) nad przyczynami niezadowolenia i pomyślałem jak można to wyeliminować. W końcu wraz z firmą Bottega zrealizowałem garść szkoleń według “swoich” reguł. Niejednokrotnie podczas przygotowywania materiału myślałem sobie: “ale to będzie fajne, sam bym chętnie w takim warsztacie uczestniczył!”. A to jest zdecydowanie tak zwany “precondition” udanego szkolenia. Czy faktycznie są one idealne? Zapewne nie, bo przecież zawsze coś można zrobić lepiej. Nie śmiem także twierdzić, że są najlepsze. Ale do tego dążę, a droga do celu jest opisana w powyższych akapitach. Sporo zależy od nastawienia i doświadczeń uczestników. Póki co okazuje się, że uczestnicy są zadowoleni. Na tyle, że niektórzy klienci od razu zamawiają kolejne tematy, bądź kolejne terminy. No i…? No i super, czyli to działa!

Jak Ty widzisz ten problem? Uczestniczysz w szkoleniach? Co dla Ciebie jest w nich najważniejsze?

The post Najlepsze szkolenia programistyczne appeared first on Maciej Aniserowicz.

Agendę naszego spotkania znajdziecie na stronie “Testowanie automatyczne (“core” – 1 dzień)“.

Zajęcia przeplatane były kawką, pizzą i rozpakowywaniem mBankowych podarunków. A na koniec losowanie nagród: wejściówki na Programistok, Leetspeek oraz licencje od JetBrains. Strasznie miło!

Jedyne czego mi brakowało to żywiołowe dyskusje – ich nie bardzo doświadczyliśmy. Może wynikało to z faktu, że ludzie się wzajemnie nie znali. A może dlatego, że było nas w sumie aż 26 osób. A może powód jest jeszcze inny? Jeśli ktoś wie jaki to niech koniecznie da znać!

Opinie, jakie otrzymałem w powarsztatowej ankiecie, aż onieśmielają. Zobaczcie:

Do tego sporo bardzo budujących komentarzy tekstowych. Radość w sercu mym zapanowała na długie godziny po ich lekturze.

Feedback jaki dostałem zarówno po tych, jak i kilku ostatnich “zamkniętych” warsztatach, dał mi do myślenia. Mam sporo refleksji odnośnie szkoleń programistycznych. Podzielę się z Wami nimi jutro z samego rańca, więc zapraszam!

Inicjatywa devWarsztatów jest po prostu świetna. Wielkie gratulacje w stronę Gutka ślę, że udało mu się to wszystko wymyślić i zorganizować. I do tego jakie tempo: już w najbliższą sobotę odbędzie się kolejne spotkanie! Wypas. Czuję w kościach, że to się nieźle rozrośnie, bo korzyści są duże dla każdego: i uczestników, i prowadzących, i potencjalnych sponsorów, i “organizacji użyczających lokal”… Oj, aż się nie mogę doczekać i będę z ciekawością obserwować dalszy rozwój wydarzeń!

A tymczasem: dzięki wszystkim za udział i wspólne spędzenie soboty. Oraz taki miły feedback. Jeśli macie jeszcze coś – cokolwiek! – do dodania, to piszcie czy w komentarzach do tego posta, czy na maila, czy na stronie meetup, czy na fejsie, czy do Gutka, czy… kanałów jest bardzo wiele, więc na pewno drogę znajdziecie ;).

I jeszcze jedno!
Jednym z pytań w ankiecie było: “Czy poleciłbyś to szkolenie gdyby było organizowane jako komercyjny płatny warsztat otwarty?”. Ku mojemu zadowoleniu wszyscy uczestnicy odpowiedzieli twierdząco. Najprawdopodobniej uczynię więc taki eksperyment w nadchodzących miesiącach. Tym samym zapraszam do zapisania się na newsletter pod tym adresem: http://eepurl.com/bw_LL5. Planuję puścić tam informację wcześniej niż na blogu i zaoferować zniżkę dla subskrybentów.

The post Po devWarsztatach appeared first on Maciej Aniserowicz.

Here you have DbTester Training Content (9 downloads) for download and you can easily learn from this above training how to use it in your own performance tuning fights. Thanks for reading and Enjoy!

p ;).