Maciej Aniserowicz's Blog, page 4

PO CO i JAK testować? SmartTesting LIVE!

Już w najbliższy poniedziałek o 20:00 odbędzie się megaciekawy LIVE o testach! Testy dla programistów, nie testerów. Jednostkowe, integracyjne, E2E… unameit!

W podróż zabiera Cię ekipa SmartTesting: Olga Maciaszek-Sharma, Marcin Grzejszczak i Maciej Aniserowicz.

Porozmawiamy o takich tematach:

Po co testować?
Jak to robić?
Najczęstsze problemy w pisaniu testów i jak ich uniknąć?
Błędy w edukacji o testach
Najlepsze praktyki w testowaniu

… a to nie wszystko :).

Zarejestruj się na https://smarttesting.pl/live!

Przygotuj ciekawe pytania, bo przewidujemy sesję Q&A!

Nie zabraknie również informacji o Programie SmartTesting.

Do zobaczenia!

The post PO CO i JAK testować? SmartTesting LIVE! appeared first on devstyle.pl.

DevTalk #119 – O testach część 2 z Marcinem Grzejszczakiem

Kolejny tydzień, a zarazem kolejna część DevTalka o testowaniu. Tym razem razem z  Marcinem Grzejszczakiem rozmawiamy o metodach prywatnych i jednostkach w testach jednostkowych. Interesują Cię testy regresji? W dzisiejszym odcinku mentor SmartTestingu porusza ten temat BONUSOWO, wsłuchaj się uważnie.

Marcin Grzejszczak można nazwać nie tylko programistą, ale również autorem. Ojciec książek Mockito Instant oraz Mockito Cookbook. Twórca kursu Hands-On Guide to Spring Cloud Contract oraz współtwórca kursu Applied Continuous Delivery Live Lessons. Lead projektów Spring Cloud Sleuth, Spring Cloud Contract oraz Cloud Pipelines w VMware. Współzałożyciel Warsaw Groovy User Group, Warsaw Cloud Native Meetup oraz inicjatywy DiverseIT.

Z tego odcinka dowiesz się: 

Jak testować metody prywatne?
Co metoda prywatna ma wspólnego z Frodem?
Czy problemem jest duża ilość klas?
Czego nie testować? 
Kiedy testować wszystko?
Czy kasowanie testów ma sens?
Czym jest jednostka w testach jednostkowych?
O testach regresji

I uwaga! Wraz z Marcinem oraz Olgą Maciaszek-Sharma pracujemy na czymś bardzo fajnym! Nad inicjatywą SmartTesting, dzięki której nauczysz się pisać testy tak, jak trzeba. Odkryjemy piękno testów, poznamy niebezpieczeństwa z nimi związane i przede wszystkim: zobaczymy, dlaczego są tak cholernie ważne!

Zapisz się do SmartTesting od razu, już dziś czeka na Ciebie MASA materiałów!

 

A teraz… PLAY!

http://traffic.libsyn.com/devtalk/DevTalk_119_-_O_testach_cz_2_z_Marcinem_Grzejszczakiem.mp3
Montaż odcinka: Krzysztof Śmigiel.

Ważne adresy:


zapisz się na newsletter


zasubskrybuj w iTunes, Spotify lub przez RSS


ściągnij odcinek w mp3

Linki:

Marcin:

Mockito Instant
Mockito Cookbook
Hands-On Guide to Spring Cloud Contract 
Applied Continuous Delivery Live Lessons

Muzyka wykorzystana w intro:

“Misuse” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0

http://creativecommons.org/licenses/by/3.0/

The post DevTalk #119 – O testach część 2 z Marcinem Grzejszczakiem appeared first on devstyle.pl.

NIE ROBIĘ JUŻ VLOGA – Dlaczego? [vlog #357]

The post NIE ROBIĘ JUŻ VLOGA – Dlaczego? [vlog #357] appeared first on devstyle.pl.

DevTalk #118 – O testach część 1 z Olgą Maciaszek-Sharmą i Marcinem Grzejszczakiem

Nurtuje Cię temat testów w pracy programisty? A może… chcesz dowiedzieć się jakie typy testów można wykorzystywać w pracy? Świetnie trafiłeś! W najnowszym DevTalku poruszamy te tematy wraz z mentorami SmartTestingu. Olga razem z Marcinem zaspokoją Twoją żądzę wiedzy.

Olga Maciaszek-Sharma jest programistką Java oraz Groovy, wcześniej pracowała jako Inżynier Jakości Oprogramowania. Interesuje się  mikroserwisami, resilient architecture i rozwiązaniami chmurowymi. Obecnie pracuje w Spring Cloud Team dla VMWare, gdzie rozwija projekty Spring Cloud LoadBalancer, Spring Cloud Contract, Spring Cloud Netflix i Spring Cloud OpenFeign.

Marcina Grzejszczaka można nazwać nie tylko programistą, ale również autorem. Ojciec książek Mockito Instant oraz Mockito Cookbook. Twórca kursu Hands-On Guide to Spring Cloud Contract oraz współtwórca kursu Applied Continuous Delivery Live Lessons. Lead projektów Spring Cloud Sleuth, Spring Cloud Contract oraz Cloud Pipelines w VMware. Współzałożyciel Warsaw Groovy User Group, Warsaw Cloud Native Meetup oraz inicjatywy DiverseIT.

Z tego odcinka dowiesz się:

Jakie są typy testów dla programisty oraz czym się różnią?
Jakie są najczęściej używane podejścia do izolacji?
Dlaczego nie chwalić się powermockiem?
Czym są mocki i kiedy ich używać?
Jakie są różnice między mockiem a stubem?
Dlaczego próby mockowania frameworków są złe?

I uwaga! Wraz z Marcinem i Olgą pracujemy na czymś bardzo fajnym! Nad inicjatywą SmartTesting, dzięki której nauczysz się pisać testy tak, jak trzeba. Odkryjemy piękno testów, poznamy niebezpieczeństwa z nimi związane i przede wszystkim: zobaczymy, dlaczego są tak cholernie ważne!

Zapisz się do SmartTesting od razu, już dziś czeka na Ciebie MASA materiałów!

A teraz… PLAY!

http://traffic.libsyn.com/devtalk/DevTalk_118_-_O_testach_cz_1_z_Olg_Maciaszek-Sharm_i_Marcinem_Grzejszczakiem_vol2.mp3
Montaż odcinka: Krzysztof Śmigiel.

Ważne adresy:


zapisz się na newsletter


zasubskrybuj w iTunes, Spotify lub przez RSS


ściągnij odcinek w mp3

Linki:

Marcin:

Mockito Instant
Mockito Cookbook
Hands-On Guide to Spring Cloud Contract
Applied Continuous Delivery Live Lessons

Olga:

Consumer-Driven Contract Testing with Spring Cloud Contract
How to Live in a Post–Spring Cloud Netflix World
Testing REST and Messaging with Spring Cloud Contract at DevSkiller – DevSkiller Tech Blog

 
Muzyka wykorzystana w intro:

“Misuse” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0

http://creativecommons.org/licenses/by/3.0/

The post DevTalk #118 – O testach część 1 z Olgą Maciaszek-Sharmą i Marcinem Grzejszczakiem appeared first on devstyle.pl.

Saas Porażka #2: Opowieść o tym, jak NIE zaczynać projektu

W poprzednim artykule dokładnie opisałem, czym będziemy się zajmować przez najbliższe miesiące. Omówiłem też domenę, żeby potem sprawnie przejść przez Event Storming oraz implementację i nie musieć po raz kolejny wyjaśniać wymagań biznesowych. Będzie to nasz punkt odniesienia.

Dzisiaj w najdrobniejszych szczegółach przedstawię, jak narodził się pomysł, jak go „walidowałem” i ile się napracowałem, jeszcze zanim machina ruszyła. Innymi słowy, podzielę się tym, jak prawdopodobnie nie zaczynać projektu.

Narodziny pomysłu

Jak wiele rzeczy na świecie, pomysł w pewnym sensie zrodził się pod wpływem… alkoholu. Spotkałem się po dłuższym czasie z kumplem, który wymyślił, że spoko byłoby mieć firmę HR, która weryfikuje kandydatów i wystawia ich na stronie internetowej w takich jakby „aukcjach”. „Tanio sprzedam developera” – ciśnie się na usta. Kolega wpadł na to po tym, jak opowiedziałem mu, że za polecenie dobrych ludzi w IT dostałem niezłe pieniądze. Oczywiście w natłoku krążących po żyłach promili, oprócz deklaracji wzajemnego „szasunku”, postanowiliśmy, że trzeba coś z tym zrobić. Jeszcze kilka razy do tego wracaliśmy, no a potem pomysł… umarł.

Jakiś czas później pracowałem w projekcie z całkowicie innej branży, w którym taki odwrócony model wyszukiwania dobrze się sprawdzał. Wtedy przypomniałem sobie rozmowę sprzed lat. Z tym że chciałem pominąć weryfikację kandydatów czy potrzebę posiadania firmy HR, a to właśnie zakładał oryginalny plan. Idea polegała na oddaniu inicjatywy w ręce samych developerów. Dzięki temu na początek byłby to prosty CRUD z wyszukiwarką. Szybko by się to zrobiło, a z nieba spadłby złoty deszcz.

Na to wszystko nałożyło się też kilka artykułów i podcastów, które zacząłem analizować. Do jakich wniosków doszedłem po tych „badaniach”, już wiesz po przeczytaniu poprzedniego artykułu. I wtedy wszedł on, cały na biało – pomysł na projekt pod nazwą kodową DFS (Developer For Sale). Niewątpliwie potrzebowałem innej nazwy, ale do tego jeszcze dojdziemy.

Teraz:

Walidacja bronienie swojej wizji pomysłu

Każdy poważny przedsiębiorca wie, że zanim zacznie się cokolwiek robić, pomysł na biznes należałoby zweryfikować. Albo przynajmniej dowiedzieć się, jakie potrzeby ma grupa, do której kieruje się dane rozwiązanie. Jako aspirujący „entrepreneur” postanowiłem, że zacznę od stworzenia ankiety. Problem polegał na tym, że w głowie miałem już gotowy produkt, z którego formy wcale nie chciałem rezygnować. Dlatego też, zamiast pytać o bolączki, postanowiłem sprawdzić, czy potencjalni użytkownicy będą skłonni anonimowo zostawić w formularzu informacje, za jaką kasę, w jakim mieście i w jakiej technologii chcieliby pracować. Ankieta ta była dla mnie potwierdzeniem, że ludzie nie obawiają się ujawniać takich danych.

Dobra, skoro wymyśliłem, o co zapytam, to pozostawało pytanie, gdzie o to zapytam. Nie zbudowałem wokół siebie żadnej społeczności. Czułem niechęć do proszenia o odpowiedzi bezpośrednio na grupach czy do pisania wiadomości prywatnych. Byłem natomiast patronem Maćka na Patronite. W jednym z progów była możliwość zamieszczenia u niego we vlogu kilkunastosekundowego nagrania wideo. Pomyślałem, że to dobra okazja, by pokazać innym, co robię. No i wpadło mi do głowy, że może tam poproszę o wypełnienie ankiety. Wewnętrznie mi to jednak zgrzytało, bo nie chciałem wykorzystywać takiej możliwości do prywaty. Postanowiłem zostawić decyzję Maćkowi. Jemu z kolei pomysł się spodobał, cytuję: „to też fajnie mogłoby pokazać innym Patronom, co można zrobić z tym bonusem oprócz przedstawienia się”.

Ale się wszystko spina! No to jedziemy z tą ankietą – myślałem. Tutaj jednak moje podejście sprytnego i rzutkiego przedsiębiorcy się kończyło. Zamiast zrobić to jak każdy myślący biznesowo człowiek, czyli wziąć smartfona, w 5 minut się nagrać, a w kolejne 5 wyklepać ankietę w jakimś gotowym narzędziu, postanowiłem zrobić wszystko „profesjonalnie”. Wydawało mi się, że przecież potrzebuję jakiejś fajnej nazwy, designu, że wideo powinien nagrać ze mną kumpel, który się na tym zna, i że koniecznie moje nazwisko razem z wielkim logo musi wjeżdżać na tle wpadającej w ucho muzyczki. Ostatecznie sama ankieta wyglądała tak:

Po wypełnieniu formularza i kliknięciu „Wyślij” wyświetlało się oczywiście podziękowanie. Oprócz tego były też widgety z różnych portali społecznościowych, żeby móc udostępnić ankietę, oraz miejsce na zapisanie się do listy mailingowej, jeśli ktoś uzna, że temat go interesuje i chce dostawać informacje o postępie prac. Ma się ten byznesowy pomyślunek, co nie? Słusznie możesz teraz myśleć, że wcześniej mówiłem o anonimowej ankiecie, a tutaj proszę – prośba o adresy mailowe. Wierz mi lub nie, ale poważnie traktowałem anonimowość i w żaden sposób nie śledziłem ani nie zapisywałem powiązań między mailem a ankietą. Zależało mi wyłącznie na zbudowaniu jakiejkolwiek listy mailingowej.

Kiedy już wszystko było gotowe, Maciek wrzucił wideo do swojego vloga. Nie było tam mowy o tym, co to za projekt i jak w ogóle ma pomóc w znalezieniu pracy. Jedynie prośba o wypełnienie ankiety. (Oczywiście z muzyczką i logo). ;) W badaniu wzięło udział około 300 osób, a ponad 100 zapisało się na listę mailingową, co dla mnie było wielkim sukcesem.

First things first

Czas zająć się rzeczami najważniejszymi, czyli nazwą i logo. Jak ludzie mają w ogóle wypełnić ankietę, jeśli nie wiedzą, czego ona dotyczy? Taaa… tak wtedy myślałem. Historia jest dość ciekawa.

Wcześniej pracowałem przy małym projekcie, którego nazwę i design wymyślił znajomy doktor historii sztuki. Bardzo przypadły mi do gustu styl i to, jak argumentował stojącą za nimi ideę. Dlatego – gdy sam potrzebowałem pomocy – postanowiłem, że podpytam go, czy coś fajnego nie przychodzi mu do głowy. Przecież nie mogłem nazwać apki Developers For Sale. Po kilku dniach odezwał się do mnie z propozycją. Z racji tego, że on też jest użytkownikiem Linuxa, pomyślał, że skoro „dev” szuka pracy, to może warto byłoby to odnieść do montowania przez użytkownika zasobu (w tym przypadku pracy) w Linuxie! Ostatecznie doszliśmy do tego, że w linii komend mogłoby to wyglądać tak:

Spodobał mi się ten pomysł nie tylko z powodu odniesienia do wspomnianego montowania, ale też dlatego, że występował tam znak „$”(takie puszczenie oka do osób szukających lepiej płatnej pracy). Poza tym „mount” kojarzy się z górami (Mount Everest), co może też być nawiązaniem do wspinania się po szczebelkach kariery. Mind blown, co nie?

Przekazałem tę wizję grafikowi, który przygotowywał logo. W odpowiedzi dostałem dwie propozycje:

Spodobała mi się ta pierwsza, ale gdy teraz na nie patrzę, to nie wiem, czy nie zdecydowałbym się na tę drugą – trochę bardziej „retro”. A Tobie która bardziej przypadła do gustu?

Zauważ, że w obu projektach jest widoczne nawiązanie do linii komend. Pojawia się „$”, a kolejne wyrazy są coraz wyżej, przywodząc na myśl szczeble kariery. Pewnie mało kto by o tym w ogóle pomyślał, ale ja byłem bardzo zadowolony, że w przyszłości jak już będę pytany w wywiadach o logo, będę mógł przedstawić tak głęboką interpretację. ;)

Design

Z racji tego, że wiedziałem, co ma się znaleźć na portalu, grafik wykonywał design równolegle z logo. Nie ma tutaj co się rozpisywać. Przedstawiłem mu opis projektu i mockupy i to w zupełności wystarczyło. Dostałem propozycję designu, który praktycznie od razu klepnąłem. Kilka przykładowych widoków poniżej:

Ankieta już prawie gotowa, jeszcze tylko hosting…

Long story short – przy okazji robienia designu docelowej apki poprosiłem grafika o zaprojektowanie ankiety, no bo przecież ona też musiała być „customowa”. Zamiast wziąć gotowe narzędzie do ankiet i jakoś dostosować jej wygląd, wymyśliłem, że wyklepię ją od zera i zrobię deployment do AWS Elastic Beanstalk…

Po kilku dniach ankieta była gotowa. O wynikach już wspominałem.

Koniec rumakowania

Po wstępnym sukcesie zastanawiałem się, w jaki jeszcze sposób mógłbym promować pomysł. Wymyśliłem, że napiszę artykuł (podlinkowałem go w poprzednim poście), wrzucę go na Hacker News i moja lista mailingowa urośnie do tysięcy subskrybentów w kilka godzin. Jak słusznie podejrzewasz, tak się nie stało. Tekst napisałem, choć zajęło mi to dość dużo czasu. W obawie przed tym, że native speakerzy, czytając go, będą słyszeć mój wschodnioeuropejski akcent, podesłałem szkic znajomemu, który jest genialnym filologiem. Na szczęście okazało się, że wyszło całkiem dobrze i skończyło się na drobnych poprawkach, takich jak wrzucenie bardziej naturalnych kolokacji. Poza tym pomyślałem, że dla przykucia uwagi przydałyby się jakieś fajne odręczne rysunki, tak żeby artykuł wyróżniał się na tle innych postów ze stockowymi zdjęciami. To z kolei zleciłem swojej znajomej rysowniczce. Jak już wszystko było gotowe, wrzuciłem post na HN i… nie pykło. Po statystykach w Medium widziałem, że trochę osób go przeczytało, ale nie przekładało się to na wzrost liczby subskrybentów. Wysyłałem też link do tekstu w odpowiedziach na oferty pracy, które nazbierały mi się w różnych miejscach. Wydawało się, że wśród ludzi z HR idea wzbudzała wyraźne zainteresowanie, dlatego zachowywałem kontakt do każdej osoby, która chciała, żebym informował ją o postępach. Jednak pomysł bez realizacji jest niczym, więc moje zapewnienia, że „startuję wkrótce i dam znać”, spełzły na niczym.

W pewnym momencie byłem już tak zmęczony tą „rozgrzewką”, że zacząłem w końcu myśleć o tym, żeby zlecić wyklepanie samego prototypu. Akurat tak się złożyło, że mój kolega chciał się trochę pobawić AWS-em – win-win situation! Szybko dogadaliśmy się co do ceny i po jakimś czasie miałem coś w miarę klikalnego, jednak nikomu tego nie pokazałem. Wydaje mi się, że – pomijając sprawy osobiste – ostatecznie straciłem wiarę w powodzenie projektu. Pojawił się pewnego rodzaju opór (czytaj: wymówki), który pewnie lepiej ode mnie zidentyfikowałyby osoby działające w obszarach rozwoju osobistego.

Co poszło nie tak?

Zamiast skupić się na poznawaniu bolączek potencjalnych klientów, wyciąganiu wniosków i budowaniu wokół siebie społeczność, na siłę koncentrowałem się na niepotrzebnych rzeczach. Zrobiłem research i doszedłem do sensownych wniosków, ale prawda jest taka, że zazwyczaj jesteśmy w stanie tak przedstawić sprawę, by obronić swoją tezę. Najgorsze, że w tym przypadku to było bronienie jej przed samym sobą.

Innymi słowy, na starcie wykonałem za dużo niepotrzebnej pracy: design, logo, filmiki, rysunki… Pochłonęło to tyle czasu i energii, że zabrakło najważniejszego – realnego rozwiązania problemu. Dlatego też mocno odradzam podążanie ścieżką, jaką wtedy obrałem. No ale nie ma tego złego, co by na dobre nie wyszło. Gdyby nie ta porażka, nie mielibyśmy teraz dobrego materiału do analizy i nauki.

Ostatecznie nie można mi zarzucić, że nie podjąłem działania. Problem w tym, że nie robiłem tego mądrze. Zajmowałem się mnóstwem drugorzędnych spraw, chyba tylko po to, żeby te istotne odsunąć w czasie. Ten syndrom też ma pewnie jakąś uczoną nazwę. Za dużo tych syndromów, zaczyna się robić patologicznie, więc to dobry moment na zakończenie tej autoanalizy. ;)

Jeśli masz jakiekolwiek pytania albo coś szczególnie Cię zainteresowało, napisz o tym w komentarzu, a ja odpowiem. Zachęcam też do podzielenia się swoimi doświadczeniami, bo wiem, że nie jestem osamotniony w takiej realizacji projektów. Mnóstwo z nich nie wychodzi poza ściany przysłowiowej piwnicy.

Każdy komentarz (a pod ostatnim tekstem było ich bardzo dużo, dzięki!) pokazuje, że rozwijanie tego cyklu ma sens!

The post Saas Porażka #2: Opowieść o tym, jak NIE zaczynać projektu appeared first on devstyle.pl.

DevTalk #117 – O iOS i Swift z Sebastianem Osińskim

Jeśli jesteś fanem produktów z symbolem nadgryzionego jabłka, być może zainteresuje Cię programowanie na iOS! Tylko… w Polsce nadal większość osób korzysta z Androida! Czy warto programować na iOS na rodzimym rynku? Dziś o tej technologii opowie nam Sebastian Osiński!

Sebastian z wykształcenia jest matematykiem, który po krótkiej przygodzie jako analityk w banku, postanowił zostać iOS Developerem. Od tego momentu minęły ponad 4 lata, a Sebastian stworzył wiele projektów komercyjnych. W tworzeniu aplikacji mobilnych kocha to, że może “dotknąć” tego co stworzył. Na co dzień zgłębia tajniki iOS developmentu i Swifta oraz próbuje blogować. 

Z tego odcinka dowiesz się:

Czym charakteryzuje się programowanie na iOS?
Czym różni się Objective C od Swift?
Jakie są najciekawsze ficzery języka?
Jak wygląda testowanie na iOS?
Jakich narzędzi warto używać? 
Jak ekosystem iOS ewoluował wraz z nowymi modelami iPhone?
Jakie problemy mogą wystąpić przy programowaniu na iOS?
Jak napisać aplikację w iOS i skąd brać wiedzę na ten temat?

PS Podoba Ci się ten odcinek? Zostaw gwiazdki i opinię na na iTunes. To BARDZO pomaga. Dzięki!

A teraz… PLAY!

http://traffic.libsyn.com/devtalk/DevTalk_117_-_O_iOS_i_Swift_z_Sebastianem_Osiskim.mp3
Montaż odcinka: Krzysztof Śmigiel.

Ważne adresy:


zapisz się na newsletter


zasubskrybuj w iTunes, Spotify lub przez RSS


ściągnij odcinek w mp3

Linki:

DevTalk

DevTalk #69 – O Androidzie z Pauliną Szklarską
DevTalk #103 – O Flutterze z Dominikiem Roszkowskim
DevTalk #62 – O Xamarin z Jakubem Jędryszkiem

 Sebastian Osiński

blog Sebastiana
Twitter
Kurs Stanforda – wprowadzenie do SwiftUI
Hacking with Swift
Kursy dla Mobile Developerów na raywenderlich.com
Darmowa książka od Apple o Swifcie

 
Muzyka wykorzystana w intro:

“Misuse” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0

http://creativecommons.org/licenses/by/3.0/

The post DevTalk #117 – O iOS i Swift z Sebastianem Osińskim appeared first on devstyle.pl.

Czy TDD chroni przed głupotą?

Często słyszymy: “TDD powinno sprawiać, że oprogramowanie nie ma bugów“. A to bardzo mylne pojmowanie wszystkiego, co się za TDD kryje! I dla tej praktyki mocno krzywdzące, bo gdy się okazuje, że tak nie jest, to ludzie się zniechęcają.

Ale do rzeczy: czy TDD zwalnia z myślenia? Albo inaczej: czy z TDD nie można popełnić błędów?

Czy przetestowany kod jest poprawny? Uwaga, rocket science approaching:

Testy weryfikują, że kod działa tak jak chce tego programista, a nie tak jak powinien!

Zamiast się nad tym dalej rozwodzić, przytoczę przykład. Ujawnię swój własny wstydliwy zakamar. Miałem taki interfejs:

public interface IDetectInvalidOrders
{
bool IsValid(Order order);
}

A zaimplementowałem to tak:

public class InvalidOrdersDetector : IDetectInvalidOrders
{
public bool IsValid(Order order)
{
return order.Description == "invalid-order";
}
}

Logika sama w sobie jest prawidłowa: “biznesową niepoprawność” zamówienia w tym systemie oznacza się poprzez wpisanie w nim jakiegoś zdefiniowanego opisu, który w prawdziwym systemie pobieram z konfiguracji ale tutaj to uprościłem.

Testy? Owszem, są! Ba, były nawet napisane najpierw:

public class InvalidOrdersDetectorTests
{
readonly InvalidOrdersDetector _detector;
readonly Order _order;

public InvalidOrdersDetectorTests()
{
_order = new Order();
_detector = new InvalidOrdersDetector();
}

bool execute()
{
return _detector.IsValid(_order);
}

[Fact]
public void detects_invalid_order_based_on_description()
{
_order.Description = "invalid-order";

var result = execute();

result.ShouldBe(true);
}

[Fact]
public void does_not_detect_order_with_no_description_as_invalid()
{
var result = execute();

result.ShouldBe(false);
}

[Fact]
public void does_not_detect_order_with_other_description_as_invalid()
{
_order.Description = "other description";

var result = execute();

result.ShouldBe(false);
}
}

Super. Kilkanaście commitów później sklejam wszystko w całość i uruchamiam. Damn, nie działa! Jak to możliwe?

Z kwadrans zajęło mi dojście do źródła problemu…

Co z tego że mam testy, skoro one testują ODWROTNY sposób działania tego “detectora”?

Widzicie? Metoda o nazwie “IsValid” sprawdza, czy zamówienie jest “invalid”. A reszta kodu korzysta z niej zgodnie z nazwą…

Uwaga! Z wielką przyjemnością ogłaszam Inicjatywę SmartTesting.pl i serdecznie Cię na nią zapraszam! Tam wraz z TOP Expertami będziemy dostarczać masę rewelacyjnych materiałów o testach!

W napisanym, przetestowanym, zacommitowanym kodzie mam taką głupotę, że aż strach. Moja głowa musiała gdzieś odfrunąć. Mózg się wyłączył, a rency sami klepali testy a potem implementację.

Na szczęście wykryłem ten fakt przed “git push”, więc mogłem poprawić commit żeby nie było wstydu. Co prawda wstyd i tak będzie, bo w końcu jest ten post, ale… chyba warto. Przykład z życia, że jak ktoś się nawet na chwilę zmienia przed komputerem w debiloidiotę, to i TDD nie pomoże.

Odpowiedź zatem jest prosta: nie, TDD nie chroni przed głupotą. TDD nie zwalnia z myślenia. TDD nie zrobi z nas geniuszy.

Happy testing!

The post Czy TDD chroni przed głupotą? appeared first on devstyle.pl.

Saas Porażka #1: Cała prawda o tym, jak zawaliłem realizację aplikacji typu SaaS (i co możesz na tym zyskać)

Dzisiaj wracam z opowieścią, która nigdy nie wyląduje w żadnej z poczytnych książek jakiegoś guru marketingu czy innego kołcza. Będzie to historia mojej porażki. Po prostu nie dowiozłem. Będzie to historia pomysłu, który nie daje mi spokoju, choć myślałem, że już się z nim rozprawiłem. (Pewnie ten syndrom ma jakąś mądrą nazwę).

Tym razem jednak pomysł powrócił w zupełnie innej formie, o czym opowiem w dalszej części tekstu. Przy okazji postaram Ci się przekazać bardzo dużo praktycznej wiedzy z zakresu designu i architektury oprogramowania, klocków DDD oraz pozyskiwania wymagań biznesowych. Dowiesz się też, jak Twój kolega po fachu chciał na Tobie zarobić – ale spokojnie, mniej niż na działach HR. ;) Ja z kolei definitywnie rozprawię się z tym konceptem i podbiję sobie statsy, bo wiadomo: wincyj kodu i ćwiczeń = wincyj skilla. Po wszystkim zyskam +5 do mądrości na karcie postaci.

Nowe odcinki cyklu będą pojawiały się regularnie na devstyle.pl, a ich pełną listę znajdziesz tutaj!

Do rzeczy: pomyślałem, że skoro mam w głowie w miarę dobrze poukładaną domenę biznesową, to przedstawię Ci ją z najdrobniejszymi szczegółami. Poznasz moje motywacje i tok myślenia. Zero ściemy. Później krok po kroku będę ją implementował i pokazywał cały proces. Dzięki temu zobaczysz, jakie decyzje architektoniczne dotyczące designu będę podejmował, z jakich narzędzi DDD skorzystam i jak mi to wyjdzie. Ostatecznie spróbujemy to odpalić. (Może uda się zaprosić kogoś do dyskusji, gdzie i jak zrobić to najlepiej?) Ale najważniejsze zostawiłem na koniec: to będzie projekt open source! Jeśli zechcesz, będziesz mógł w nim uczestniczyć przez „forkowanie”, łatanie bugów i tworzenie PR-ów. A jak model biznesowy Ci się spodoba i uznasz, że masz żyłkę marketera i zawsze marzyłeś o własnym start-upie, będziesz mógł go wziąć, odpalić i zarabiać na nim miliony.

Skąd takie podejście? Dlaczego nie wyklepię projektu po kryjomu w piwnicy i samemu nie podbiję świata?

Po pierwsze, o czym już wspomniałem: chcę raz na zawsze rozprawić się z tym pomysłem. Podoba mi się ta idea od strony biznesowej i technicznej – wiem, jak chciałbym to zaimplementować.

Po drugie, chciałbym żeby projekt miał wartość edukacyjną zarówno dla Ciebie, jak i dla mnie.

Po trzecie, możliwe, że biznes ten wydaje się atrakcyjny wyłącznie mnie samemu. Wypadałoby go zweryfikować jeszcze przed implementacją. Gdyby się okazało, że to klapa, oszczędziłoby mi to dużo czasu i nerwów.

Po czwarte, w momencie kiedy miałem już prototyp, nastąpiła u mnie zmiana priorytetów i cały ogrom pracy, jaki trzeba było włożyć w marketing, żeby zostać zauważonym, spadł daleko, daleko na koniec listy. Taki projekt to bardzo duża odpowiedzialność. To jak kupienie sobie małego słodkiego maine coona, który gdy dorośnie, może Cię zeżreć. (Jak myślicie, dlaczego Aniserowicz nabył 20 książek o tym, jak wytresować kota?)

Rozkład jazdy

Przedstawię teraz, co będzie wchodziło w skład serii artykułów, czyli tematy, którymi się zajmiemy – z zastrzeżeniem, że ich kolejność i zakres mogą się jeszcze zmienić. Nie wykluczam, że w trakcie pojawią się zagadnienia, którym warto będzie poświęcić trochę więcej czasu. Teraz wyglądałoby to tak:

Opis domeny i tło sytuacji. To właśnie post, który czytasz. Jego zadaniem jest pokazanie moich motywacji i wyjaśnienie modelu biznesowego. Koniecznie musisz się z nim zapoznać, ponieważ wszystko będzie się kręcić wokół przedstawionych tu założeń.
Geneza. Tu będę do bólu szczery i pokażę Ci, jak nie zaczynać takiego projektu. Zobaczysz, jak rozmyślałem nad „fancy” logiem, interfejsem użytkownika, jak „walidowałem” pomysł. Opiszę też moje nieudolne próby content marketingu.
Big Picture Event Storming. Tutaj przedstawię, jak wyglądał mój pierwszy Event Storming i jakie fajne rzeczy mogą wyjść, jeśli się go robi z kimś, kto ma duże doświadczenie biznesowe.
Design Level Event Storming, podczas którego podzielimy wszystko na bounded contexty i subdomeny.
Wybór architektury, a może nawet architektur. ;)
Dokumentacja ogólna i decyzji architektonicznych.
Setup projektu, czyli struktura, system kontroli wersji i CI.
Agregaty, polityki, repozytoria i serwisy. Tutaj nam się to rozbije na kilka wpisów, bo jest o czym pisać. Są różne podejścia, więc będziemy je analizować.
Komendy i ich infrastruktura.
Zdarzenia i ich infrastruktura.
Deployment.


Opis domeny

Domena, którą będziemy się tutaj zajmować, to wsparcie dla początkowej fazy procesu rekrutacyjnego programistów. A dokładniej odwrócenie aktualnego modelu: programiści – zamiast przeglądać oferty pracy – mieliby wystawiać swoje anonimowe, ograniczone czasowo ogłoszenia z opisanymi wymaganiami i oczekiwaniami. Dzięki temu wystawialiby się niejako „na sprzedaż” – takie Allegro z programistami, choć doskonale wiemy, że programiści to towar niepotrzebujący reklamy. ;)

Jeśli chcesz poznać genezę samego pomysłu, znajdziesz ją w kolejnym poście. Teraz jedynie zaznaczę, że na taki kształt, jaki przedstawiłem, wpływ miało głównie rozeznanie tematu. Były to różnego rodzaju artykuły czy podcasty traktujące o bolączkach procesu rekrutacyjnego oraz oczywiście bezpośrednie rozmowy zarówno z programistami, jak i rekruterami (możesz o tym przeczytać w dalszej części tego artykułu). Z moich „badań” wynikało, że wiele problemów pojawia się jeszcze przed rozmową kwalifikacyjną. Występują one po obu stronach i w takiej formie referuję je poniżej.

Problemy z perspektywy programisty(-ki):

Jeśli programista lub programistka nie byli zainteresowani zmianą pracy, to nie chcieli dostawać nowych ofert zatrudnienia przez portale społecznościowe, mailowo czy telefonicznie.
Ogłoszenia z ofertami pracy zazwyczaj były nieustrukturyzowane. Widełki wynagrodzeń, warunki zatrudnienia i wymagania były niejasne bądź ich brakowało.
Dość krępującym elementem każdej rozmowy o pracę było przedstawianie oczekiwań finansowych. Z jednej strony kandydaci obawiali się, że mogą zrazić pracodawcę, z drugiej zaś, że zgodzą się na stawkę niższą, niż mogliby dostać.
Kandydaci mieli też obawy, że jeśli sami siebie uznają podczas rozmowy za niedostatecznie wykwalifikowanych, to obniżą swoje wymagania – syndrom oszusta w praktyce ;).
Kolejnym problemem było przedstawianie pełnego profilu (np. w postaci CV) w obawie, że zostanie się odrzuconym z powodów takich jak poprzednie doświadczenie zawodowe, wiek czy płeć.

Problemy z perspektywy rekrutera(-ki):

Brak wyselekcjonowanej grupy odbiorców. Innymi słowy, jeśli byłoby wiadomo, kto chce zmienić pracę, można by było składać oferty tylko takim osobom.
Uczucie irytacji i zrezygnowania, kiedy większość wysłanych wiadomości z ofertą pracy pozostaje bez jakiejkolwiek odpowiedzi. Nawet bez krótkiego: „Nie, dziękuję”.
Ustalony budżet na pracownika, którego nie można zamieszczać w ogłoszeniu o pracę.
Wymagania kandydata nie wpasowują się w to, co może zaoferować firma. Często okazywało się to niestety dopiero podczas spotkania z kandydatem, przez co marnotrawiony był czas po obu stronach.

Możliwe, że część z tych problemów została już rozwiązana dzięki powstaniu portali z ogłoszeniami, które przedstawiają oferty w lepszy sposób, kładąc nacisk na eksponowanie warunków zatrudnienia. Nie siedzę teraz w temacie, ale nie przeszkadza to potraktować tej domeny jako problemu do modelowania.

Jak już wspomniałem wcześniej, moim pomysłem na wszystkie powyższe bolączki było całkowite odwrócenie początkowej fazy procesu rekrutacji przez przeniesienie inicjatywy na samych zainteresowanych. Dzięki temu możliwe byłoby poprawienie procesu w kilku obszarach:

Zostałaby wyizolowana grupa ludzi, którzy aktywnie poszukują pracy.
Ogłoszenia miałyby mieć taką samą strukturę, eksponującą umiejętności, oczekiwania finansowe i przykładowo lokalizację ewentualnego zatrudnienia.
Polepszenie komunikacji przez to, że od samego początku obie strony miałyby jasność co do wymagań.
Anonimowość pozwalałaby na sprawdzenie, jakie możliwości kandydat ma na rynku pracy, bez zdradzania potencjalnych czynników dyskryminujących, takich jak wiek czy płeć. Kandydaci byliby oceniani wyłącznie na podstawie posiadanych umiejętności i przedstawionych wymagań. Być może byłby to koniec z ofertami pracy, w których zwracają się do Ciebie: „Cześć, Paweł!”, gdy na imię masz Tomek. ;)
Przez to, że ogłoszenia byłyby ograniczone czasowo i anonimowe, nie byłoby tu miejsca na networking i zbieranie siatki „znajomych”. Po prostu byłoby to narzędzie, którego używasz, tylko gdy go potrzebujesz.
Docelowo sam początek procesu rekrutacyjnego zostałby przyspieszony, ponieważ łączyłby ludzi, którzy wiedzą, że mogą się dogadać.

I tak oto dochodzimy do momentu, w którym pokażę, jak widziałem nowy proces i jakie miałem wymagania biznesowe. No to lecimy:

Osoba szukająca pracy wystawia ogłoszenie.

Jest ono ograniczone czasowo, żeby nie zalegało na portalu.
Można wystawić kilka ogłoszeń w tym samym przedziale czasu. Powody tego mogą być różne, jak choćby chęć sprawdzenia innych możliwości. Przykładowo: programujesz w Ruby i szukasz pracy w tym języku, ale na boku, cichcem, chcesz sprawdzić, czy ze swoim doświadczeniem możesz znaleźć coś w Elixirze (przynajmniej kiedyś był to dość częsty przypadek). Wystawiasz wtedy drugie ogłoszenie.
Każde ogłoszenie można w dowolnej chwili ukryć (na przykład jeśli zbierzemy dużo ofert i nie chcemy więcej) albo usunąć (jeśli chcielibyśmy mieć aktywne nowe ogłoszenie, a limit na darmowe ogłoszenia nam się skończył). I tak oto płynnie przechodzimy do monetyzacji, o której w następnym punkcie.
Początkowo każde ogłoszenie miało być płatne. Założenie było takie, że skoro szukasz pracy i masz do tego dobre narzędzie, to nie będzie Ci żal wydać $5 na ogłoszenie. Problem jednak polega na tym, że możesz nie chcieć płacić, jeśli tego narzędzia jeszcze w ogóle nie znasz. Dlatego wyłoniły się dwa rozwiązania:

Każde kolejne ogłoszenie ponad X darmowych ogłoszeń jest płatne.
Wprowadzam pakiety dostępu. Pierwszy jest darmowy i pozwala na wrzucenie 2–3 ogłoszeń za darmo. Kolejne pozwalają na większą liczbę ogłoszeń i udostepniają dodatkowe funkcjonalności. Z tym że nie były one jeszcze sprecyzowane, no ale wiadomo, doda się promowanie ogłoszenia, dostęp do statystyk i tygryski dostaną to, co lubią najbardziej. Będą siedzieć, patrzeć na wykresy i merdać ogonkami.

Z racji tego, że pierwsze podejście wydaje się nadal dość rzadkie, byłem skłonny iść w pakiety. Gdy ludziom daje się do wyboru 3 opcje, to są tacy, którzy zawsze wybiorą najtańszą (w tym przypadku darmową), część zdecyduje się na środek, ale jest też grupa, która weźmie tylko najdroższą. Drugie podejście wymagało oferowania tych nieokreślonych jeszcze funkcjonalności klasy premium. Dlatego też trzeba było tak zaprojektować proces dodawania ogłoszenia, żeby był elastyczny i otwarty na różne warianty. Aby samą decyzję odsunąć w czasie i nie musieć implementować płatności, zdecydowałem, że startuję z darmowymi ogłoszeniami z twardą blokadą na X ogłoszeń.




Jak już ogłoszenie zostanie opublikowane, staje się dostępne w wyszukiwarce. Mogą z niej korzystać rekruterzy. Jeśli ogłoszenie zostaje ukryte lub usunięte, znika z wyników wyszukiwania.
Po zapoznaniu się z ogłoszeniem rekruter może złożyć ofertę. Tutaj właśnie w grę wchodziło kilka ciekawych wymagań:

Rekruter może złożyć ofertę do konkretnego ogłoszenia tylko raz.
Żeby złożyć ofertę, rekruter musi zaakceptować warunki, które zamieszczający ogłoszenie zaznaczył jako wymagane.
Przy składaniu oferty konieczne jest podanie danych kontaktowych firmy, w imieniu której się to robi.


Osoba zamieszczająca ogłoszenie widzi w swoim panelu złożone oferty. Może je usunąć, jeśli uzna, że nie są interesujące, bo np. zostały złożone przez firmę, w której aktualnie pracuje. ;) W takim przypadku już nigdy nie dostanie oferty od tej samej osoby do tego konkretnego ogłoszenia. Kandydat może skorzystać z otrzymanych danych kontaktowych i reszta procesu odbywa się wtedy już poza portalem, ponieważ nie chcemy wiązać jakichkolwiek danych użytkownika (CV) z kontami na portalu.

 

Mniej więcej tak to miało wyglądać. Wiesz już, jakie problemy zidentyfikowałem i jak chciałem je rozwiązać. Kiedyś opisałem (mniej szczegółowo) całą ideę w artykule, który znajdziesz tutaj. Miał to być element content marketingu, dlatego wrzuciłem go nawet na Hacker News, ale przeszedł bez echa. Polecam go bardziej jako ciekawostkę, bo punktem wyjścia do dalszych badań i tak pozostaje post, który masz teraz przed oczami. Tutaj drobiazgowo przedstawiłem domenę i wymagania biznesowe, żebyśmy mieli na czym pracować przy nadchodzących Event Stormingach.

Obiecałem pokazać całe zaplecze, dlatego w następnym poście – jeszcze nie technicznym – dowiesz się, jaka była geneza pomysłu, jak powstawały logo i design, jak zbierałem informacje od programistów i rekruterów oraz jak ostatecznie… odpuściłem. Krótko mówiąc: zobaczysz, jak (nie) startować z takim przedsięwzięciem. Może przyda Ci się ta wiedza w Twoich przyszłych projektach. Później wskoczymy w samo mięsko, czyli modelowanie problemu.

Zakończenie, jak już jesteśmy w takim biznesowym nastroju, nie może się obejść bez call to action!

Koniecznie daj znać w komentarzu, czy podoba Ci się pomysł na serię postów, w których przedstawiam historię i domenę, a następnie implementację modelu biznesowego. Co więcej, zrobimy to razem! Serio!

Napisz, nawet jeśli tego zwykle nie robisz. Wystarczy, że wpiszesz „+1” …

a ja będę wiedział, że chcesz lecieć z tym dalej.

 

The post Saas Porażka #1: Cała prawda o tym, jak zawaliłem realizację aplikacji typu SaaS (i co możesz na tym zyskać) appeared first on devstyle.pl.

Jedna CZYNNOŚĆ, dzięki której „żyję sobie jak chcę” [vlog #356]

The post Jedna CZYNNOŚĆ, dzięki której „żyję sobie jak chcę” [vlog #356] appeared first on devstyle.pl.

DevTalk #116 – O TypeScript z Tomaszem Ducinem

Gdy JavaScript się rozwinął, okazało się, że nie jest w stanie unieść złożonych projektów. Trzeba było wymyślić język, dzięki któremu utrzymanie systemów będzie prostsze, tańsze i bardziej przewidywalne. Tak powstał TypeScript! W sto szesnastym odcinku DevTalk bierzemy na tapetę JS i TS. Poznamy trochę historii, kilka wad i zalet oraz perspektywy rozwoju. O wszystkim opowie Tomasz Ducin.

Tomek to niezależny konsultant, architekt i programista, przewodnik po świecie JavaScriptu. Udziela się jako spiker na konferencjach w Polsce i Europie. Jako trener tłumaczy z pasją jak co działa oraz uczy unikania przekomplikowanych rozwiązań i podejmowania zbędnych decyzji. Nie cierpi buzzwordów i wciskania ludziom kitu. Jest skoncentrowany na rozwiązywaniu technicznych i organizacyjnych bolączek projektów. Uwielbia pracę z ludźmi. Dwie ciekawostki: jest ex-aktorem teatralnym i pije cztery espresso dziennie. :)

Z tego odcinka dowiesz się:

Czym się charakteryzuje JavaScript?
Czy jest sens uczyć się samego JS?
Po co komu TypeScript?
Na czym polega kompilacja TSa?
Na co możemy się nadziać w TS?
Jakie są narzędzia i wsparcie TS na rok 2020?
Gdzie warto się uczyć i w jakich projektach używać TypeScript?
Przyszłość TypeScript i JavaScript – czy będzie merge?

PS Podoba Ci się ten odcinek? Zostaw gwiazdki i opinię na na iTunes. To BARDZO pomaga. Dzięki!

A teraz… PLAY!

http://traffic.libsyn.com/devtalk/DevTalk_116_-_O_TypeScript_z_Tomaszem_Ducinem.mp3
Montaż odcinka: Krzysztof Śmigiel.

Ważne adresy:


zapisz się na newsletter


zasubskrybuj w iTunes, Spotify lub przez RSS


ściągnij odcinek w mp3

Linki:

DevTalk
DevTalk #96 – O Nauce Frontendu z Maciejem Korsanem
DevTalk #92 – O błędach w tworzeniu WWW z Tomaszem “Comandeer” Jakutem

Tomasz Ducin

blog Tomasza
Tomek na Twitterze
State of JS – ankieta o stanie javascript z 2019 roku
Coffeescript.org
Anders Hejlsberg
Flow


Muzyka wykorzystana w intro:

“Misuse” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 3.0

http://creativecommons.org/licenses/by/3.0/

The post DevTalk #116 – O TypeScript z Tomaszem Ducinem appeared first on devstyle.pl.