Software Craftsmanship Saturday vol.84 – Atlassian, Scraping oraz Rekrutacja

1. Wielka, dwutygodniowa (🤯) awaria Atlassiana

Zaczniemy od “ulubionej” aplikacji wszystkich programistów, Jiry. Nie ma chyba drugiego kawałku softu, który byłby równocześnie tak mocno znienawidzony i tak powszechnie przy tym używany – swego czasu pewnie konkurowały by z nią niektóre rozwiązania Microsoftu, ale przez lata twórcy Windowsa zdążyli przekonać do siebie użytkowników… Atlassian tak średnio.

Dlatego też zaraz przed świętami wielkanocnymi społeczność programistyczna (a przynajmniej ta kochająca dobre “dramy”) wyciągnęło Popcorn i patrzyło, jak się biedny Atlassian miota przy okazji jednej z najbardziej kompromitujących awarii ostatnich lat. Przez prawie dwa tygodnie ponad 400 klientów Jiry nie miało dostępu do swoich danych i nawet nie mogło się zalogować, a Atlassian… nabrał wody w usta i tydzień zajęło im przyznanie się, że w ogóle do jakiejkolwiek awarii doszło – gdy pierwsze zgłoszenia pojawiły się już 4 kwietnia, pierwszy oficjalny komunikat zaafektowaniu użytkownicy dostali dopiero 12 kwietnia, a i on tak naprawdę nie bardzo wyjaśnia co się wydarzyło i większość komunikatu to standardowe “naszym nadrzędnym celem jest przywrócenie możliwości pracy klientów”.

Mimo tak pięknie postawionych priorytetów całość ciągnęła się jednak aż do 18 kwietnia, kiedy to ostatecznie podobno problem został rozwiązany… aczkolwiek ja w dalszym czasie czekam na jakiś sensowny post-mortem, bo mam wrażenie że wiele się będziemy mogli z niego nauczyć.

A teraz porównajcie to do legendarnego już streamu z odtwarzania produkcji przez GitLab.

Ciekawym efektem ubocznym całego zamieszania jest pojawienie się w technologicznej blogosferze (ktoś jeszcze tego terminu poza mną w 2022 używa?) tekstu z rzadko spotykanego gatunku… śledztwa dziennikarskiego. Otóż szeroko znany Gergely Orosz z bloga The Pragmatic Engineer zajął się nagłośnieniem sprawy i śledzeniem jej dzień po dniu jeszcze zanim Atlassian przyznał że ma problem, dzięki czemu całość zyskała spore zainteresowanie branży.

Oczywiście, awarie zdarzają się absolutnie każdemu, ale Atlassian to akurat jedna z tych firm posiadających swoich “psychofanów”, którzy z aptekarską dokładnością kolekcjonują wszystkie wady ich oprogramowania. Choćby rzut oka na podlinkowaną listę pokazuje, że powodów braku sympatii do Jiry trochę się znajdzie, ale z pewnością jednymi z wybijających się przyczyn jest nadmierne skomplikowanie oraz kiepska wydajność. Pośrednią przyczyną obu jest fakt, że oprogramowanie Atlassianu jest po prostu niesamowicie wręcz konfigurowalne, co oczywiście nie jest za darmo – każda abstrakcja kosztuje. Dlatego w celu poznania “wroga” lepiej, polecam zapoznać się z nowiutkim case study dotyczącym tego, jak od strony architektonicznej wygląda proces “linkowania” zgłoszeń. Dowiecie się z niego, jak szalenie elastycznym jest jirowy model i możliwe, że będziecie w stanie podglądnąć parę interesujących rozwiązań dla siebie – choćby po to, żeby nie wpaść w te same pułapki.

Aczkolwiek przy lekturze nie zapominajcie, że gdy patrzycie się w otchłań, ta również na Was spogląda i śmieje się złowieszczo. Dbajcie tam o siebie w tej Jurze.

Źródła

2. Scrapowanie publicznych danych uznane za legalne

… przynajmniej w Stanach Zjednoczonych. I nie jest też czymś szczególnie nowym, ale jest na tyle ciekawa, że zauważam wartość w przywołaniu tego ostatniego wyroku sądowego.

Sprawa o którą chodzi ma już parę lat na karku, a wytoczona została przez LinkedIn przeciwko Hiq Labs, firmie, która wykorzystuje dane publiczne do analizy odpływu pracowników. LinkedIn-owi baaaaardzo się to nie podobało i powołując się na fakt, że masowe pobieranie profili użytkowników LinkedIn było niezgodne z jego warunkami korzystania z usługi, stanowił… włamanie. Tak, brzmi to iście kuriozalnie, ale dokładnie tak wyglądały oryginalne zarzuty.

Zdjęcie z siedziby głównej LinkedIna, animizowane.

LinkedIn po raz pierwszy przegrał sprawę przeciwko Hiq w 2019 r. Wtedy to sąd orzekł, że CFAA (Computer Fraud and Abuse Act), czyli amerykański akt prawny definiujący przestępstwa związane z nielegalnym pozyskiwaniem danych elektronicznych nie zabrania nikomu pozyskiwania danych, które są publicznie dostępne. LinkedIn się oczywiście odwołał, sąd ponownie podtrzymał swoje oryginalne oświadczenie i dzięki temu macie okazję przeczytać o tym w naszej dzisiejszej edycji. Mimo niekorzystnego wyroku, LinkedIn twierdzi, że się nie podda, musi bowiem dbać o dane kandydatów, które zostały im w zaufaniu powierzone.

Z języka prezesów odpalających cygara studolarówkami na ludzkie: “me dane mą fortecą i wara Wam od nich”. Prawdziwych bohaterów naszych czasów.

Żeby temat podsumować, postanowiłem przyglądnąć się jeszcze, jak temat wygląda od strony prawnej w Unii Europejskiej. Temat był bardzo mocno rozważany przy okazji pojawienia się Copilota – ukazał się wtedy post Julii Redy z Europejskiej Partii Piratów, specjalistki od licencji. Udowadnia w nim, że w świetle europejskiego prawa Copilot tak naprawdę nie naruszył ani prawa, ani postanowień licencyjnych. Ogólnie web scraping publicznych danych wydaje się więc być spoko… chyba, że dotyczy to danych osobowych (czyli trochę jak było to w przypadku LinkedIna), bo wtedy wchodzi GDPR z całym dobrodziejstwem inwentarza i sprawa się mocno komplikuje.

Źródła

3. A może powinniśmy kazać kandydatom czytać kod zamiast go pisać?

No dobra, przyznać się, kto regularnie uczestniczy w procesach rekrutacyjnych? I nie, nie chodzi mi o regularne chodzenie do konkurencji w celu “sondowania” rynku, ale o tą drugą stronę barykady – Wasz zespół/projekt/firma potrzebuje zasilenia (może jesteście ofiarą własnego sukcesu, a może właśnie ktoś zbyt dobrze rynek wysondował). Jakie macie techniki, jeśli chodzi o znalezienia tych prawdziwych “pereł”, z którymi chcecie pracować?

Metod rekrutacyjnych jest wiele i każdy ma swoje ulubione, ale dzisiaj podzielę się tekstem How to Freaking Find Great Developers By Having Them Read Code, który zdobył dużą popularność na Reddicie w zeszłym tygodniu.

Otóż sugeruje on, że tak naprawdę zamiast kazać ludziom pisać kod, powinniśmy im takowy dawać do… aktywnego (w znaczeniu – w IDE) czytania. Ma to bowiem według twórców wiele zalet. Przykładowo, jest znacznie szybsze – prawie natychmiast jako rekruter możemy podjąć dialog z potencjalnym kandydatem, który pozwoli nam poznać jego preferencje. Okazuje się też, że eliminuje to z całego procesu masę elementu stresu – masa ludzi czuje się niekomfortowo, gdy ktoś patrzy im na ręce. Z mojej perspektywy najważniejsze jest chyba jednak to, że taki proces pozwala od samego początku sprawdzić, jak dana osoba radzi sobie z bardziej zaawansowaną abstrakcją – zadania w których kandydat musi coś napisać muszą być z założenia mocno uproszczone. Co ciekawe, dość dobrze pokrywa się to z badaniami, które ostatnio analizowało It Never Works at Theory (strona internetowa przyglądający się akademickim badaniom dotyczącym tego, jak wytwarzane jest oprogramowanie), więc tym bardziej zachęcam do lektury.

Co ciekawe Joel Spolsky (twórca StackOverflow) napisał tekst w podobnym tonie już… prawie dokładnie 20 lat temu. To jest życia krąg, co prowadzi nas…..

No to jak już porozmawialiśmy o tym, jak odkryć dobrych kandydatów, będę miał też coś jeśli siedzicie po drugiej stronie rekrutacyjnego stolika. Dzisiejszy rynek sprawia, że rekrutacja to obustronny “konkurs piękności” – i tak naprawdę w równym stopniu to firma rekrutuje kandydata, co kandydat firmę. Dlatego też polecam zobaczyć sobie krótki poradnik 3 Interview Questions to Spot „Fake Agile” Software Engineering Teams. Zaproponowane w nim pytania są bardzo konkretne i stanowią swoiste pułapki, z których rekruterowi naprawdę trudno jest uciec w przekonujący sposób.

No i zaczęliśmy Oroszem więc nim sobie również zakończymy. W zeszłym tygodniu na jego niezwykle popularnym blogu pojawiła się świetna checklista tego co powinno (albo wręcz przeciwnie) znaleźć się w kuszącym programistów ogłoszeniu o pracę. Podobnie jak w poprzednich tekstach z tej sekcji nie znajdziecie tam jakiegoś Świętego Graala, który sprawi, że nie będzie mogli odgonić się od kandydatów, na pewno jednak jest to lista którą warto się kierować projektując ogłoszenia.

I tak żeby zupełnie domknąć już tą sekcje (i ogólnie edycje), jeszcze dwa moje ukochane klasyki z The Pragmatic Engineer – Reverse Interviewing Your Future Manager and Team oraz Preparing for the Systems Design and Coding Interview. Mam nadzieje, że gdy następnym razem będziecie szukać pracy się Wam przydadzą. I absolutnie nie zachęcam do zmiany pracy czy coś – nie chce trafić na czarną listę firmowych firewalli (wystarczy, że już HRom tą edycją podpadłem).

1. Wielka, dwutygodniowa (🤯) awaria Atlassiana

Źródła

2. Scrapowanie publicznych danych uznane za legalne

Źródła

3. A może powinniśmy kazać kandydatom czytać kod zamiast go pisać?

Źródła

Odkryj więcej świetnych treści!