Jeszcze raz o nazewnictwie, bo dziś trafiłem w kodzie na coś takiego:
Listing 1. Potworek
findPxxSxxInPxxSxxListByCxxIdSxxsIdSxxCxxxxIdUxxxxTp
wyiksowałem rzeczy, które są biznesowo istotne, ale nie straciło to nic ze swojego uroku. Metoda jest prywatna w danej klasie, bo takie potworki czasami trafiają się w Spring Data, i przyjmuje trzy parametry. Zwraca jakiś tam obiekt biznesowy.
Ja się pytam, co ćpał człowiek, który to napisał.
W poprzednim wpisie omówiłem, krótko, bo krótko, problem skracania nazw w kodzie. Dziś poruszę problem zbyt długich nazw. One też nie są dobre.
No właśnie… Czy pojęcie to oznacza nazwę, która jest długa, precyzyjna i w najmniejszych szczegółach oddająca co dzieje się w środku? A może nazwa opisowa niesie ze sobą pewien „ładunek emocjonalny”, który pozwala na wczucie się w kod? Był sobie taki nurt w literaturze. co nazywał się RealizmW. Jednym z jego najwybitniejszych przedstawicieli był Lew TołstojW. I większość z nas zapamiętała go jako autora długich, bardzo szczegółowych opisów.
Im bliżej technicznych aspektów projektu, tym bardziej rozwlekłe są nazwy. Jest to oczywiste przeciwieństwo problemu z poprzedniego wpisu. Być może ma ono źródło w „nie jesteśmy humanistami” i brakach w umiejętnościach językowych? Z drugiej strony płodzenie takich potworków.
Na dziś tyle. Zostawiam was z problemem nazywania różnych elementów w kodzie i szukania tego złotego środka pomiędzy nazwami zbyt krótkimi i zbyt długimi. Jako „zadanie domowe” możecie spróbować wypisać sobie trzy dobre i trzy złe cechy nazw popularnych algorytmów jak Quick Sort, A*, Sidewinder.
Nowy rok, nowe błędy. Wpis miał być o czymś innym, tzn. miało to być podsumowanie poprzedniego i plany na obecny rok, ale jak to w życiu bywa, plany poszły się paść. Będzie o czymś, moim zdaniem, ciekawszym. Będziemy przyzywać wielkich przedwiecznychW.
Mając możliwość obcowania z różnymi systemami, zauważyłem pewną prawidłowość. Im bliżej biznesu umieszczamy kod, tym bardziej niezrozumiałe i skrótowe są nazwy. Dotyczy to zarówno nazw usług, jak i bytów biznesowych. Co ciekawe w dokumentacji mamy do czynienia z całymi tabelami translacji, które tłumaczą nazwy domenowe na nazwy techniczne. Jednocześnie im bardziej zagłębiamy się w kod, tym bardziej opisowe i abstrakcyjne nazwy poszczególnych elementów. Takie nazewnictwo, zarówno bliżej biznesu jak i bliżej krzemu ma pewne negatywne konsekwencje.
Wiele lat temu pracując przy systemie SIS spotkałem się z bardzo ciekawym problemem. Pewien fragment systemu posługiwał się nazewnictwem pozbawionym samogłosek. No spoko, da się żyć z tego typu „optymalizacją”. Tyle tylko, że nazwy pochodziły z języka portugalskiego. No kurwa…
Dopiero wtedy odkryłem, po co mi była karteczka z tłumaczeniami, którą otrzymałem pierwszego dnia od liniowego. Tak, zawierała ona tłumaczenie skrót → całe słowo po portugalsku → słowo po angielsku, bo oczywiście klasy były już w cywilizowanym języku. Narzut komunikacyjny, który był spowodowany koniecznością, takiego wielokrotnego tłumaczenia był znaczny.
Kolejny ciekawy przykład, to tytułowy PrtDtRefStsMngmnt, który jest nazwą klasy. Spoko, prawda? Tylko co to, kurwa, jest? A teraz wyobraźcie sobie, że spotykacie taki oto fragment kodu:
Listing 1. Co to?
List<String> attrList = prtDtRefStsMngmnt.queryPrtDtRefSts();
Cytując klasyka, o co tu kurwa jego mać chodzi, w tym burdelu? Pozostawię was z tym problemem.
Powyższy kawałek kodu jest wynikiem pracy z SOAP-em i usługami na szynie danych. Tak już się jakoś złożyło, że biznes postanowił oszczędzić kilka znaków i spłodził potworka.
Moje obserwacje wskazują na trzy główne powody używania tego rodzaju konwencji nazewniczych. Po pierwsze to ograniczenia innych technologii. XML nie jest jakoś specjalnie elastyczny, jeśli chodzi o nazwy. Podobnie wiele narzędzi około XML-owych wprowadza własne ograniczenia związane zazwyczaj z długością nazw. Po drugie na poziomie analizy istnieje silna potrzeba upraszczania. Upraszczanie jest najbardziej widoczne na poziomie długości nazw. Działa to trochę jak taka typowa restrukturyzacja w przedsiębiorstwie. Wywali się 30% załogi, a reszcie utnie pozapłacowe dodatki i będzie zreformowane. Nie ważne, że procesy nadal są słabe, ale finansowo widać poprawę. Podobnie tutaj. Wywali się długie nazwy, które robią wrażenie skomplikowania systemu. W zamian wstawi się skróty, które będą wyglądać mądrze i pseudo-technicznie, a jednocześnie przepchną „komplikację” na stronę techniczną. Inaczej mówiąc, analitycy chcą dobrze, ale ci techniczni… Po trzecie lenistwo w pisaniu. Dziesięć znaków wedle konwencji pisze się szybciej niż 20 pełnej nazwy.
Oczywiście jest to moja obserwacja i może być błędna, ale chyba nie mylę się jakoś szczególnie.
W niektórych przypadkach, szczególnie bardzo starych systemów, przyczyną są rzeczywiste ograniczenia techniczne. W DOSieW nazwa pliku mogła mieć jedynie osiem znaków plus trzy znaki rozszerzenia. Tyle tylko, że DOS umarł w 2003 roku wraz z wersją 7.1 (dla specyficznych maszynek IBMa).
Najpoważniejszą konsekwencją są wspomniane wcześniej zatory komunikacyjne. Nowa osoba wchodząca do projektu musi poświęcić mnóstwo czasu i energii na odszyfrowanie dziwnych nazw. Czy stać nas na ten luksus? Chyba tak, bo twardo trzymamy się tego typu nazw. Kolejny problem to błędy wynikające ze stosowania intuicji. Jeżeli mamy takie oto nazwy:
to, co oznacza attrValPrnt? Odpowiedź będzie w jednym z kolejnych postów, a na razie czekam na propozycje w komentarzach.
Blogonotkowe życie toczy się samo. Miała być szybka notka będą pewno trzy. Jednocześnie mam nadzieję, że mi się uda wrócić do regularnego pisania 🙂
Wiem, że wiele osób czekało na ten wpis. Kolejna prezentacja Wojtka Seligi na Confiturze i kolejny raz mam okazję do napisania polemiki. Na wstępnie chcę jednak zaznaczyć, że zgadzam się z częścią tez Wojtka. W czasie prezentacji pojawiło się jednak wiele wątków, z którymi nie mogę się zgodzić.
Nagranie całej prezentacji:
Pierwszą tezę Wojtka można ująć tak
Z Polskie przestaliśmy eksportować towary, a zaczęliśmy eksportować usługi.
Ciężko jest mi zgodzić się z tak postawioną tezą, ponieważ jest ona nieprawdziwa. Bazując chociażby na publikacji Ministerstwa Gospodarki/Rozwoju możemy stwierdzić, że w takim 2014 roku eksport towarów wynosił ponad 157 mld EUR (str. 39), a eksport usług wynosił raptem 36 mld EUR (str. 69). Co więcej jeżeli przyjrzymy się jakie usługi eksportujemy, to większość stanowią odpowiednio usługi transportowe ponad 10mld EUR (str. 72), a następnie turystyka ponad 8mld EUR (str 72).Eksport usług telekomunikacyjnych, informatycznych i informacyjnych to raptem 3 mld EUR. Jak ma się, to do sprzedawania ciał… nie wiem.
Ale, ale… dane które tu przytaczam pochodzą z 2014 roku. Mamy rok 2017! Ok, należy jednak zwrócić uwagę, że dane statystyczne co do zasady są publikowane z pewnym opóźnieniem. Publikacja, którą linkuję pochodzi z 2015 roku. Sięgnijmy zatem do nowszych danych, za rok 2016. Tu niestety forma jest znacznie mniej przystępna i trzeba się trochę nagimnastykować, by odszukać potrzebne informacje. Informacje będą dotyczyć roku 2015. Według tej publikacji wartość eksportu towarów wynosiła prawie 180 mld EUR (tab 19 str. 90), a wartość usług dostarczonych (wyeksportowanych) wynosiła około 40mld EUR (tab 29, str. 206). I znowuż lwią część tej kwoty stanowią usługi transportowe (str. 222). Warto też tu wspomnieć, że do usług zalicza się obrót własnością intelektualną, więc jeżeli takie LPP tworzy spółkę w ZEA czy innym Katarze, by tam ulokować swoje biznesy związane z posiadanymi znakami towarowymi, to też liczymy ten biznes do bilansu (choć jest to tylko optymalizacja podatkowa, a nie realny biznes).
Więcej do poczytania na ten temat:
Podsumowując, Wojtek postawił pewną tezę i nie skonfrontował jej z rzeczywistością. A rzeczywistość okazała się brutalna.
W świetle danych, trudno odpowiedzieć na to pytanie. W trakcie prezentacji Wojtek słusznie wspomniał o Mordorze i milionach metrów kwadratowych powierzchni. Jak to możliwe, że pomimo dostępu do tak ogromnych zasobów, eksport jest niewielki. Przecież wiele firm otwiera swoje centra usług wspólnych w Polsce! Przepracowałem kilka ostatnich lat w tego typu miejscach i chyba mogę odpowiedzieć na to pytanie.
Po pierwsze dużą część powierzchni zajmują firmy, które nie uczestniczą w eksporcie. Czy taki Play albo mBank eksportują swoje usługi? No nie. Eksport usług jest zapewne ułamkiem procenta ich „produkcji”. Jednocześnie te firmy muszą jakoś obsłużyć sporą liczbę klientów tu na miejscu. I to właśnie obsługa rynku wewnętrznego pochłania lwią część powierzchni. Dołóżmy do tego przepisy BHP, które określają ilość miejsca (wolnej podłogi jak i kubaturę pomieszczenia) na pracownika i nagle okazuje się, że chcąc zatrudnić 100 osób, trzeba mieć na „dzień dobry” około 1000-1500m^2 biura (w zależności od zagęszczenia i układu, więcej tu). Czy 100 osób to dużo? No nie, ale poza powierzchnią musisz zapewnić im też otoczkę, czyli zatrudnić kolejnych ludzi, którzy będą dbali o to biuro.
Drugim pochłaniaczem powierzchni jest obsługa biura. Serwis sprzątający, to tylko ułamek. Przecież ktoś musi zadbać o to, żeby sale konferencyjne były przygotowane na spotkania (ustawione stoły, krzesła, dodatkowe wyposażenie), ktoś musi obsłużyć interesantów (recepcja i ochrona), a jak spieprzy ci się myszka, to też ktoś musi ją naprawić. Nie wspominam tu już o działach typu księgowość, kadry, rekrutacja, bo to kolejni pracownicy. Jeżeli nałożymy na to typowy dla korporacji sposób organizowania pracy poprzez ujmowanie jej w regulaminy, to nagle dla naszych 100 „roboli” musimy zapewnić jeszcze 10-20 osób „obsługi” (weź pod uwagę urlopy). Nasze biuro rośnie już do 1200m^2. A przecież wymagania stawiane dużym firmom są bardziej rygorystyczne. Pokój dla matek karmiących, kuchnia, która „przyjmie” twoich pracowników w porze obiadowej, sławetny jeden pisuar i jedna miska ustępowa na 20 chłopa (plus 1 miska ustępowa na 10 pań). Biuro puchnie.
Trzeci pochłaniacz to powierzchnie wspólne, których zadaniem jest „oczarowanie” wchodzących. Odpowiednio duży hol, przestronna recepcja, ale też odpowiednie drogi ewakuacyjne, parkingi, hole windowe, to wszystko pompuje nam budynek. W Mordorze pracuje około 100 tysięcy ludzi. Ogromna część z nich pracuje na to, by Mordor w ogóle działał.
Drugą tezę z prezentacji można opisać w następujący sposób:
Tylko wojna na Ukrainie spowodowała, że usługi nie zostały przeniesione dalej na wschód.
Nie siedzę w głowach managerów, ale teza ta wydaje mi się mocno naciągana. Wojtek odwołuje się tutaj do, fenomenalnej skądinąd, książki My Job went to India autorstwa Chada Fowlera. BTW druga edycja tej książki ma inny tytuł, ciekawe dlaczego…
Zacznijmy od podstawowych różnic pomiędzy Polską, a taką Rosją. W sumie różnica jest jedna i widoczna najlepiej na lotniskach. Jako obywatel Polski, nie muszę tłumaczyć się z tego dlaczego przyjechałem, po co przyjechałem, co przywiozłem. Gwiazdki unijne w paszporcie dają bardzo dużo. Dla korporacji system polityczny nie ma większego znaczenia. Do póki idzie dogadać się z rządem, czy to za pomocą oficjalnych kanałów, czy to za pomocą kanałów mniej oficjalnych, nikt nie będzie się zastanawiać nad tym czy rząd pałuje obywateli. Zresztą bardzo dobrym potwierdzeniem mojej tezy jest zachowanie instytucji takich jak Citigroup czy Morgan Stanley w obliczu Brexitu. Banki te po prostu przenoszą swoje zespoły na teren UE (opisane tutaj). Dlaczego? Ponieważ wspólny rynek i swobody przepływu dają znacznie większe zyski niż niskie pensje pracowników. Pozwalają też na budowanie pewnych konstruktów biznesowych w rodzaju podwójnej kanapki irlandzkiej z wkładką holenderską, czy jakoś tak (to konkretne rozwiązanie uwalono, ale są inne). Inaczej mówiąc jeżeli jesteś w UE, to łatwiej prowadzić ci biznes. Wycieczka dalej na wschód nie ma sensu.
Tu mały pr0tip. Jeżeli chcecie pozwiedzać Amerykę Południową, to Air France lata do Gujany Francuskiej po kosztach lotów krajowych. Można dużo zaoszczędzić.
Kolejna teza opiera się o założenie, że programiści nie są zawodem wybranym. W pełni zgadzam się z tym twierdzeniem, ale pozwolę sobie na małą kontrę co do listy innych „zawodów wybranych”, którą przedstawił Wojtek.
No nie. Pozycja jaką mieli górnicy w czasach PRLu, to taki trochę urban legend. Po pierwsze na górnictwo i hutnictwo jako branże „wiodące” postawił dopiero Edward Gierek. W dodatku zrobił to tylko i wyłącznie z przyczyn politycznych. Jako sekretarz wojewódzki ze Śląska wsparł swój twardy elektorat. Zresztą takie same kroki podjęto wobec innych branży w drugiej połowie lat 80-tych. Stąd właśnie jako dziecko kolejarzy miałem darmowe i nielimitowane bilety na pociągi. Po prostu nie mogąc dać ludziom pieniędzy dano im pewne przywileje. Zresztą większość z nich odebrano, a sławetne 13-stki i 14-stki, to potoczne nazwy na premie roczne albo spieniężone świadczenia materialne, których istnienie w przemyśle wydobywczym ma bardzo dawne korzenie.
Witki mi opadły jak to usłyszałem. Serio. Redukcja zatrudnienia w bankach jest po części związana z kryzysem. Największy wpływ na redukcje zatrudnienia w bankach miała automatyzacja. Taki mBank, który jest czwartym co do wielkości bankiem w Polsce (pod względem wielkości aktywów), zatrudnia raptem 5 tysięcy osób. Mniejsze ING zatrudnia ponad 7 tysięcy (tamże), a większe BZ WBK ponad 11 tysięcy (tamże).Zresztą procesy automatyzacji mają to do siebie, że są w dużym stopniu wymuszane, ale jak już zaistnieją, to gwałtownie wypychają wcześniejsze formy. Nie dotykają też tylko bankowości. Przez ostatnie 200-250 lat trudnym do automatyzacji był proces szycia ubrań. Dlatego też szyjemy ubrania w krajach tanich. Jednak ostatnio coś drgnęło. Można to traktować jako ciekawostkę, ale z drugiej strony, jeżeli wypali, to kraje Azji Południowo-Wschodniej mają poważny problem.
Trochę inaczej miała się sprawa z nauczycielami języka angielskiego. Na początku lat 90-tych po prostu ich nie było. Jednocześnie powstało ogromne zapotrzebowanie zarówno prywatne, jak i publiczne. Szkoły przechodziły z nauczania rosyjskiego na nauczanie angielskiego. Po 20 latach publiczna edukacja spowodowała, że nie ma aż takiego zapotrzebowania na nauczycieli angielskiego, bo po prostu uczymy się w szkole. Pozostał rynek korepetycji i prywatnych szkół językowych, który będzie zachowywać się tak samo, jak na przykład rynek korepetycji z matematyki.
Prawnicy to zupełnie inna działka. Zacznijmy od wspomnianych „ustawionych” notariuszy. Po pierwsze w przypadku pewnych działań np. sprzedaży nieruchomości jest przymus notarialny. Po drugie taksa notarialna jest określona w rozporządzeniu. Po trzecie notariusze, tak samo jak inne zawody prawnicze „dla ludu” (adwokaci, radcy, komornicy), mają zakaz reklamy oraz zakaz pracy poza kancelarią (z nielicznymi wyjątkami jak praca na uczelni, czy w jednostkach administracji publicznej). Jeżeli tak ograniczony rynek nałożymy otwarcie zawodu, które miało na celu:
Otwarcie dostępu do zawodów prawniczych wychodzi naprzeciw społecznym oczekiwaniom zwiększenia dostępności do pomocy prawnej oraz potrzebom prawników aspirujących do wykonywania tych zawodów.
Jednak zostało zaaplikowane w społeczeństwie, które nie ma w zwyczaju korzystać z pomocy prawnika, albo korzysta w ostateczności narzekając na cenę i bardzo często przychodząc „po ptokach”. Więc nie należy się dziwić, że dziś prawnicy mają pod górkę.
Podsumowując, przyczyny załamań w różnych zawodach są znacznie bardziej skomplikowane, niż przedstawił to Wojtek. Tu bardzo ładnie wchodzi temat codzienności programowania i cyfryzacji społeczeństwa. Teoretycznie każdy z nas potrafi pisać i czytać. Praktycznie czytamy i piszemy, ale niewiele osób potrafi kaligrafować i recytować. W każdej powszechnej umiejętności jest pewien próg, którego zwykle nie osiągamy.
I całkiem dobrze mu to idzie. Co więcej, w przeciwieństwie do tego co Wojtek próbuje wmówić, potrafi robić nie tylko z cegieł. Technologia jest celem sama w sobie. Dzięki temu potrafiliśmy odejść od cegieł i zmusić wielki stalowy walec najpierw do pływania, a potem do latania. Właśnie na tym polega rozwój technologiczny. Potrafimy rozwiązać problem, ponieważ znamy się na konkretnej technologii i rozumiemy dlaczego, ona nie będzie działać w danym przypadku. Murarz nie będzie na siłę murował hali sportowej, a odeśle nas do kogoś, kto jest specjalistą od konstrukcji tego typu. Wojtek podszedł tu bardzo naiwnie do tematu. Kontrastuje to z jego wcześniejszymi słowami, o przeskakiwaniu pomiędzy technologiami. Takie zmiany robimy nie dlatego, że nam się nudzi, ale po to by nie murować wszystkiego. Mówiąc inaczej dostosowujemy narzędzia do oczekiwań.
Bardzo zabawnie może wyglądać w tym miejscu tabelka z cenami wynajmu zespołów. Tyle tylko, że została podana bez kontekstu. Co czyni ją zabawną w dalszej części prezentacji, gdzie widzimy podwójną toaletę. PM po 5USD/h nie dostanie z tego 3USD/h. Pracując kilka lat w firmie o rosyjskich korzeniach i rozmawiając z kolegami z Ukrainy o zarobkach, przekaz był jednolity. Na Ukrainie zarabiali więcej niż w Polsce (mówimy o IT, a nie innych sektorach). W dodatku płacone mieli w twardej walucie (przede wszystkim dolary), a nie w hrywnach. Dlaczego zatem przenieśli się do nas? Ponieważ po pierwsze Polska jest w UE i wielu kolegów po odpracowaniu lojalki przeniosło się dalej na zachód (bezterminowa wiza pracownicza), a po drugie „u was żyje się normalniej”. Co oznacza normalniej? Chociażby to, że w zimie jest prąd i woda, a nie awaria.
Wróćmy jednak na chwilę do tabelki i sięgnijmy po dane. Średnie zarobki senior java deva na Ukrainie to niecałe 41 tys. USD (za payscale). W Polsce to niecałe 38 tys. USD (tamże). Zatem wniosek, który wyciągnął Wojtek o tych trzech dolarach, jest błędny.
Brak kontekstu, który zna autor tabelki prowadzi nas do błędnych wniosków. Oczywiście możemy spróbować wydedukować pewne elementy tego kontekstu i tym samym spróbować zrozumieć dlaczego oferta wygląda tak, a nie inaczej:
Druga opcja jest trochę naiwna, ale prawdopodobna. Czasami bardzo nam zależy na konkretnym kliencie, bo wartość niematerialna, a tym samym wpływ na wartość późniejszych biznesów będzie większy niż bezpośrednia strata. Takie myślenie nie jest niczym nowym i choć w Polsce przybrało w pewnym momencie karykaturalną formę „będzie miał pan do portfolio”, to robienie po kosztach dla VIP-ów nie jest niczym nowym.
Znacznie ciekawsza jest tu pierwsza opcja. Jeżeli firma chce wejść na jakiś rynek, zamknięty i regulowany, to musi znaleźć pierwszego klienta. Nie jest to coś niezwykłego. Pierwszy, drugi udany kontrakt na danym rynku daje większe możliwości negocjacyjne z innymi klientami. Nie muszą oni dokładnie sprawdzać firmy, bo sprawdzenie takie zrobił już ktoś inny i było ono pomyślne. Pamiętacie firm ę Covec? Dokładnie ten sam mechanizm.
By dopełnić obrazu zarobków na wschodzie udajmy się do Indii. Średnie zarobki dla senior java deva w Indiach to około 12 tys. USD (j.w.). Dlaczego zatem nie zatrudniamy w Indiach na jeszcze większą skalę? Podpowiem chodzi nie tylko o jakość, bo i drodzy programiści na przykład z Niemiec, potrafią walnąć ciekawe babole, a tani nie są.
Skupienie się na produkcie, a dokładnie na wartości dla klienta, jest kolejną tezą prezentacji.
Technologia w tym wszystkim staje się rzeczą, tak samo jak umiejętność programowania, czymś po prostu domyślnym, którą się bierze by default.
Jest to ciekawe stwierdzenie, biorąc pod uwagę poprzednie wywody o niskiej jakość tanich programistów. Bo, czy możemy sobie pozwolić na zignorowanie technologii i całkowite skupienie się na produkcie? Czy bycie dumnym, że coś potrafimy zrobić jest czymś złym? Oczywiście nie. Nawet jeżeli nasza praca jest odtwórcza i powtarzalna, to nadal nasze umiejętności są bardzo ważne. Wojtek mówi, że niewiele jest firm w IT, które robią coś rzeczywiście innowacyjnego w skali świata. Pełna zgoda. Takich firm jest niewiele. Jednak tak samo niewiele jest firm, które tworzą innowacyjne rozwiązania w budownictwie. Tu też 99% pracy to lanie betonu i układanie cegieł. Jeżeli murarz, albo zbrojarz-betoniarz (boska nazwa stanowiska pracy tak BTW) będzie partaczył, to nawet przy najlepszym fokusie na produkt, nie dowieziemy. Przy czym nadal istotą jest rozwiązanie, które działa dla klienta. Inaczej mówiąc technologia nie jest czymś, co możemy sobie zapudełkować, bo realnie wpływa na koszty biznesu i jego późniejsze losy. Słaby programista wyprodukuje słaby kod, który będzie budować słaby produkt. Tak samo jak słaby murarz wybuduje krzywą ścianę.
Uwaga, nie oznacza to, że dobry programista zawsze stworzy dobry kod. Dobry programista ma większą szansę na stworzenie lepszego kodu. Na tej samej zasadzie świetny kierowca może mieć zły dzień i zamiast elegancko zaparkować po prostu zwali gruchę do wykopu.
Kolejna teza jest silnie powiązana z koncepcją „Golden Circle” Simona Sineka. Tyle tylko, że Wojtek chyba trochę ominął dość istotny szczegół. Otóż aplikujemy to do dwóch różnych światów. Cel firmy produkującej oprogramowanie, czyli WHY, jest inny niż cel firmy, która to oprogramowanie zamawia. Niezależnie czy zamawia to bank, czy hodowca bezmózgich kurczaków. To o czym wspomina, czyli kto będzie używał, jak będzie używał, jest elementem wspólnym tych dwóch światów. Jednak informacje te służą nam w zupełnie innym celu. Bank powie, że będzie to grupa około 100 traderów klikających jak szaleni. Dla osoby, która ten soft będzie robić, to jest informacja, a nie to, że będą oni robili nielegalne operacje finansowe. Nasza definicja WHY jest inna niż definicja WHY hodowcy kurczaków.
Jednak poruszone są tu inna ważne kwestie. Pierwsza z nich to skrytość i brak zaufania. Prowadzę obecnie projekt, który da naszemu klientowi bardzo dużą przewagę nad konkurencją. Klient pochodzi z sektora IT, ale z zupełnie innego segmentu. Teoretycznie wiedząc, co chce osiągnąć, mógłbym na bezczelnego ukraść mu ideę i samodzielnie ją wdrożyć. Tyle tylko, że jest to bez sensu, bo nie znam się na rynku, na którym nasz klient jest obecny. Z drugiej strony klient mógłby nam zlecić przygotowanie produktu, a potem wypiąć się na nas, bo teoretycznie ma możliwości, by samodzielnie stworzyć oprogramowanie. W praktyce jednak nie zna się na naszej działce i nie wie o wszystkich potencjalnych problemach. Obydwaj mamy tego świadomość i dlatego współpracujemy. Nasze motywacje są zupełnie różne, ale dzięki otwartości możemy razem coś osiągnąć. Niestety nie zawsze istnieje zaufanie. Druga istotna kwestia, to wiedza specjalistyczna. Czy muszę poznać tajniki hodowli kurczaka, by zaprogramować rozrzutnik karmy? Trochę tak, chociażby po to, by dostosować się do rodzaju karmy. Jednak głęboka wiedza specjalistyczna powinna być domeną klienta, który potrafi robić na tym biznes. Moja wiedza specjalistyczna, jako programisty, jest związana z komputerami. Tym właśnie jest element HOW, czyli umiejętności, które pozwalają na wybranie narzędzi używanych w WHAT. Hodowca kurczaka będzie wiedział, jak określić parametry karmy, bo ma taką wiedzę, a ja będę wiedział jaki serwer potrzebny jest do kontroli stu rozrzutników. Kwestia wybranej technologi implementacji serwera jest już szczegółem tak samo jak sposób machania łopatą, by się nie męczyć przy rozrzucaniu karmy.
W ten sposób płynnie przechodzimy do product engineeringu, czyli umiejętności dostarczania produktu, który trafia w potrzeby rynku. Jest to oczywiście kluczowa umiejętność. Tyle tylko, że Wojtek trochę miesza różne odpowiedzialności. Znowuż dział programowania odpowiada za techniczną część produktu, dział zajmujący się UX za odpowiedni wygląd i funkcjonalność, a dział sprzedaży za taki dobór funkcjonalności, by klienci byli zadowoleni. Tego nie zrobi jeden pojedynczy człowiek i nie ma co czarować, że programiści, którzy całe życie grzebali w krzemie nagle staną się specjalistami od psychologii.
To o czym jest product engineering, to umiejętność łączenia pracy różnych specjalistów w ramach procesu produkcji. Czy łączymy specjalistów z różnych dziedzin życia, by otrzymać dobrze działającą firmę produkującą oprogramowanie, czy też produkującą bezmózgie kurczaki oznacza, że rozumiemy NASZ biznes. Wymaganie by programista nagle stał się specjalistą od sprzedaży mija się z celem.
Zresztą Wojtek mówiąc o PE, posiłkuje się slajdem , na którym wymienione są różne cechy związane z tym pojęciem. Rzecz w tym, że jedna osoba nie może być odpowiedzialna za wszystkie te obszary. Może mieć pojęcie o strategiach cenowych, o analizie danych, o UXie, ale nadal jest, to wiedza powierzchowna, bo tak naprawdę wiedzę ekspercką ma w innej dziedzinie. I to nie jest złe. To jest bardzo dobre, bo wolę mieć zespół ekspertów, którzy mają szeroką wiedzę ogólną (niekoniecznie bardzo głęboką), niż zespół złożony z ludzi, którzy wiedzą trochę o wszystkim, ale napotykając na poważny problem, nie są wstanie prawidłowo go opisać i zadać pytania. Jest jeszcze trzecia, moim zdaniem najgorsza grupa. Zespół ekspertów, którzy dziobią tylko własną działkę, nie wykazując zainteresowania resztą. Zresztą zaczął się sezon skoków narciarskich, a przecież każdy z nas jest ekspertem w tej dziedzinie.
Kolejna kwestia, która wynika bezpośrednio z PE, to wybory, których dokonujemy. Zastanówmy się przez chwilę, jakie jest WHY każdej firmy. Odpowiedź brzmi zarabiać pieniądze. Praktycznie poza kilkoma wyjątkami każda firma jest nastawiona na zarabianie pieniędzy. Ile? Nie koniecznie jak najwięcej, ale wystarczająco dużo by zaspokoić udziałowców.
//offtopic
Jedną z nienastawionych na zysk form pracy jest spółdzielnia pracy. Celem spółdzielni jest zapewnienie zatrudnienia spółdzielcom. Nie oznacza to, że spółdzielnia nie ma zarabiać. Ma zarabiać, ale nie jest to najważniejsze zadanie. Zresztą zyski spółdzielni dzieli się pomiędzy spółdzielców.
//offtopic
Jeżeli mamy firmę, która produkuje oprogramowanie, a do tego sprowadzają się firmy outsourcingowe, to nie powiem klientowi „słuchaj my ci sprzedamy produkt naszej konkurencji”. To jest pozbawione sensu. Jeżeli chciałbym sprzedawać gotowe rozwiązania, to zostałbym re-sellerem. Jest jeszcze coś co umyka wielu osobom, które nie pracowały w outsourcingu IT. Instytucje, które „kupują ciała”, to nie są firmy, które nie potrafią albo nie chcą kupować gotowych produktów. Bank kupuje JIRE nie dlatego, że jest taka wspaniała i nie mógłby napisać własnego, podobnego rozwiązania. Kupuje, bo jest to produkt pudełkowy, dostarczany jako archiwum tar.gz, ale to nowa forma pudełka. Kupuje, ponieważ nie jest to produkt związany z głównym biznesem banku. Tak samo kupuje się szyny rozliczeniowe, czyli aplikacje do obsługi komunikacji z systemami rozliczeniowymi, bo to nie jest coś nietypowego. Bank kupuje ciała, i obarcza je zakazami konkurencji, ponieważ potrzebuje produkować bardzo specyficzny soft lub utrzymywać własną infrastrukturę. Coś, co jest charakterystyczne tylko dla danego banku i co buduje jego przewagę konkurencyjną.
To samo dotyczy traktowania kodu jako własnego dziecka. Z Jarka Pałki (który kogoś cytował, ale nie pamiętam kogo):
Dobra architektura, to architektura, której nie szkoda wyrzucić.
Podobnie ma się rzecz z kodem. Dobrzy programiści nie boją się wyrzucić własnego kodu, bo to tylko forma zapisu wiedzy. Wiedzy tak łatwo z głowy nie wyrzucimy. I znowuż Wojtek mówi dostarczmy, byle co, byle szybko, a potem będziemy się martwić i poprawiać. Nie chciałbym się leczyć w sprzęcie programowanym w takim startupowym stylu. Zresztą nie musi być to sprzęt medyczny czy krytyczna aplikacja bankowa. Facebook czy Apple mogą wypuścić gówniane rozwiązanie. Nie tylko ich stać, ale przede wszystkim mają na tyle mocną pozycję, że potencjalny bojkot konsumencki mogą zignorować. Mniejsze firmy nie mają takiego luksusu. Sprzedaż produktu w fazie „wczesna beta” wiąże się z bardzo dużym ryzykiem. W dodatku ryzyko to jest nieproporcjonalne do potencjalnych zysków.
Co ciekawe w kolejnych argumentach Wojtek zaprzecza sobie. Nagle okazuje się, że rozwiązania „too fast” nie są najlepsze, bo zazwyczaj adresują problem w zły sposób. Nagle potrzeba nam komunikacji z biznesem, bo sami tak szybko nie ogarniemy domeny. No nie trzyma się to kupy. Albo znamy WHY klienta, albo rozmawiamy z klientem o rozwiązaniach bez głębokiego wnikania w zasady działania specyficznego biznesu. Albo szybko dowozimy produkt, ryzykując złe adresowanie, albo robimy porządną analizę i solidne rozwiązanie, co trwa. Tu przechodzimy do kolejnej kwestii.
No nie, nigdy w niej nie byliśmy. Wszystkie rzeczy o których mowa w prezentacji zamykają się w świętej trójcy szybko-dobrze-tanio. I dotyczy to każdego rodzaju inżynierii. Kolejny cytat w prezentacji pochodzi z Mario Andrettiego i moim zdaniem jest on na miejscu. Co ma on do strefy komfortu?
Po 18 latach turlania się po tatami wiem co mogę zrobić, a czego nie. Andretti nigdy nie opuścił swojej strefy komfortu. Nie musiał, bo potrafił dostosować prędkość do panujących warunków. Jako dobry programista wiem kiedy mogę olać TDD, a kiedy mogę je przytulić. Ta umiejętność cechuje ekspertów. Znają swoje granice i wiedzą kiedy mogą je bezpiecznie przekraczać. Wyjście ze strefy komfortu jest zgrabnym pojęciem z zakresu sprzedaży głupcom.
Wisienką na tym torcie jest stwierdzenie, że stare firmy są wygryzane przez młode. Pamiętacie procesory CyrixW? Nie? Byli najlepsi i najszybsi, ale jakoś nie wygryźli starych i powolnych wyjadaczy jak Intel(rok zał. 1968) czy AMD(rok zał. 1969). Dlaczego? Ponieważ jeżeli firma jest wystarczająco duża, to w najgorszym przypadku stanie się nudna. Jak IBM czy Microsoft. Ubrana w korpo-procedury armia ludzi. Sukces, o którym wspomina Wojtek, nie jest wynikiem przewagi nad wielkimi graczami, a wejścia w niszę rynkową, która dla dużych nie jest istotna. Facebook wygrał, bo Google odpuścił usługi społecznościowe. Zanim Google się połapał co i jak było pozamiatane.
W tym miejscu jest już źle. Bardzo źle, bo o ile wcześniejsze dywagacje Wojtka dotyczące branżuni, to nasza wewnątrz plemienna filozofia, to mówienie o mindsecie wymaga, znowuż, solidnych podstaw w źródłach. Pozwolę sobie rozprawić się po kolei.
No sorry, ale tak to działa. W Polsce inicjatywy typu Booksy chwytają słabiej, bo też jest na nie mniejsze zapotrzebowanie. Jeżeli ktoś dobrze zarabia, jak na nasze warunki, to nie zatrudnia sprzątaczki by raz w tygodniu ogarnęła mieszkanie, bo go nie stać. Jeździmy starymi samochodami, bo nas nie stać. To samo tyczy się wszystkich innych zakupów. Uważnie oglądamy każdą złotówkę, bo jako społeczeństwo jesteśmy biedni i oszczędzamy gdzie się da.
Bogatsi rodzice mogą zapewnić dzieciom lepsze wykształcenie. Nawet jeżeli bogactwo oznacza możliwość wysłania dziecka na „obóz z niemieckim” (w okolice Dachau – Mysza na taki pojechała kiedyś dawno temu), to jest to gigantyczna przewaga nad dzieciakami z rodzin, których nie stać na takie „luksusy”. Co zatem z całymi społeczeństwami, które dzięki swojej otwartości mogły się rozwijać?
Jeżeli stracę pracę, to czy pewność wysokiego zasiłku dla bezrobotnych, powiedzmy 90% ostatniej pensji przez 6 miesięcy, nie motywuje mnie do szukania pracy w zawodzie, a nie jakiejkolwiek pracy, nawet znacznie poniżej kwalifikacji i w efekcie opuszczenia rynku pracy? Czy nie oznacza, to lepszej alokacji talentów obywateli? Takie mechanizmy zbudowały Europę Zachodnią. Ich brak odbija się w Polsce, bo nie dość, że jesteśmy biednym społeczeństwem, to jeszcze dodatkowo marnujemy zasoby. Takie marnowanie opisał Kamil Fejfer w Zawodzie. Nieskładnie, ale zawsze. O tym pisał, znacznie lepiej, Filip Springer w „13 Pięter”. O tym też pisze Chang Ha-Joog w „23 rzeczach, których nie mówią ci o kapitalizmie”. Bez mocnych fundamentów społecznych nie wybudujemy nowoczesnej gospodarki.
Jesteśmy krajem na dorobku. Krajem wysoko rozwiniętym, ale nadal stosunkowo biednym. Wróćmy na chwilę do statystyk związanych z zarobkami, a pośrednio z możliwościami zakupowymi obywateli. Jak już wiemy średnie zarobki programisty Java w Polsce to niecałe 38 tys. USD. Jeżeli przeliczymy to na euro, to otrzymamy około 32 tys. EUR (po kursie z początku grudnia 2017). Teraz porównajmy to z średnim wynagrodzeniem w UE. Nie podam tu kwoty by nie psuć niespodzianki (ale jest w źródle strony). Powiem to dosadnie. Jeżeli kurwa myślisz, że masz szmal jako java dev, to kurwa się grubo mylisz. Przyczynę już znamy, ale jakie jest rozwiązanie? Przeczytajcie wywiad z Pawłem Dobrowolskim.
Prezentacja dotarła do miejsca, gdzie pojawił się bohater. Elon Musk, który wyszedł ze strefy komfortu, zaryzykował i stworzył PayPala. Firmuje swoim nazwiskiem Teslę, bo nie jest większościowym udziałowcem, a w SpaceX ma ponad 50% udziałów, ale nie ma wyłącznego prawa głosu (trzeba mieć około 80%). Rzecz w tym, że jemu się udało. Nie udało się AOL, ani Yahoo, ani też wielu innym firmom. W tym miejscu prezentacji widzimy klasyczny błąd przeżywalnościW. Zakładam, że to nie jest celowe działanie, ale mówienie, że kilka osób nakręca sukcesy kolejnych firm i jeżeli będziemy tak jak one, to wygramy, jest nieprawidłowe. Toż to klasyczny cherry picking. Widzimy tylko zwycięzców. Ile dużych firm upadło. Co więcej ten błąd może doprowadzić do wniosku, że kopiowanie rozwiązań jest drogą do sukcesu. Nie jest. Co prawda przewija się motyw bankructwa Muska, ale znowuż odsyłam do „23 rzeczy…”, gdzie opisany jest mechanizm powstania czegoś takiego jak spółka Ltd. Elonowi Muskowi nigdy nie groziło bankructwo. Dzięki zabezpieczeniu de iure mógł zwinąć SpaceX, ale nadal miałby bardzo dużo pieniędzy.
Na koniec Wojtek odwołuje się do piramidy związanej z zyskami. Problem nie jest nowy i na zachodzie jest coraz częściej podnoszony. Nierówności płacowe i związane z ryzykiem są badane i wskazywane jako przyczyna wielu problemów społecznych. Chociażby kryzys z 2008 roku. Najbardziej poszkodowani zostali zwykli ludzie. Bankierzy nie ucierpieli. Co więcej, nadal radośnie kombinują, chociażby w Legnickiej SSE na pl. Dominikańskim we Wrocławiu.
Będzie. W dodatku silnie dotknie branżunię. Obecnie na rynku kumulują się problemy, które znamy już z dawnych czasów. Kryzys finansowy, w połączeniu z kryzysem zatrudnienia. Zarówno rewolucja przedindustrialna, która wprowadziła na rynek manufaktury, jak i rewolucja przemysłowa były związane z brakiem rąk do pracy. Pierwsza w wyniku epidemii, które dotknęły kilka pokoleń, a druga w wyniku wojen, które trwały przez ponad 200 lat. W obu przypadkach nastąpiła optymalizacja procesów produkcyjnych i automatyzacja pracy. To samo czeka rynek IT. Brak rąk do pracy oznacza, że będzie trzeba automatyzować.
Rozwiązania proponowane przez Wojtka nadają się niestety na buniowy profil Zausz Firmę. Niemiecki system edukacji kształci mechaników samochodowych mniej więcej od 13 roku życia. Na zawodach iaido, w finale rzadko widać osoby młodsze niż 60 lat. Skakanie ze specjalizacji do specjalizacji nie jest wbrew pozorom drogą do sukcesu. Można rozważyć taki model, ale trzeba pamiętać o ryzyku i o tym, że niewielu wygrywa. W dodatku należy założyć, że nie wiemy wszystkiego o zwycięzcach. Koniec końców Musk swój kapitał społeczny budował jako biały w podzielonym rasowo RPA. Mówiąc prościej, jego sukces jest, pośrednio, wynikiem pracy niewolników.
Na koniec wraca jeszcze praca prawników jako instytucji dostarczających holistycznych rozwiązań dla klientów. Mam takiego księgowego. Czasami coś ciekawego podrzuci. Rzecz w tym, że o ile mój księgowy działa jak tablica ogłoszeń, to prawnicy nie zawsze działają w zgodzie z prawem. Najlepszym przykładem tego typu prawników magików są specjaliści od odzyskiwania kamienic. Niestety.
Uodporniłem się na prawdy objawione. W prezentacji zabrakło weryfikacji danych. W ten sposób powstał potworek, który ma w sobie trochę prawdy, trochę magii, trochę zachwycania się nad zajebistością branżuni. IT nie jest branżą wybraną, ale niestety w ostatnich latach wielu ludziom na oczy spadły klapki. Wiara w to, że zarabiając przysłowiowe 15k, jesteśmy narodem wybranym, spowodowała, że nie dostrzegamy rzeczywistości. Specyfika naszej pracy pozwala na więcej, ale nie żyjemy w próżni. Chcemy wierzyć, że prowadzimy ludzi w epokę post industrialna, ale to słaby mit. Zakończę cytatem z Chang Ha-Jooga:
Podsumowując, nawet bogate kraje nie stały się jednoznacznie postindustrialne. Choć większość ich mieszkańców nie pracuje już w fabrykach, to – licząc w kategoriach cen względnych – znaczenie sektora wytwórczego w ich systemach produkcji nie spadło znacząco. Ale nawet jeśli deindustrializacja nie jest z konieczności symptomem upadku przemysłu (choć często bywa), to należy pamiętać o tym, że ma ona negatywne skutki dla wzrostu produktywności w długim okresie i dla bilansu płatniczego. Mit, że żyjemy teraz w erze postindustrialnej sprawił, że wiele rządów zlekceważyło negatywne konsekwencje deindustrializacji.
I pamiętajcie, że pracujecie w usługach, które, choć ciężko zautomatyzować, to jak już to nastąpi…
Ten tekst powstawał przez około 5 miesięcy. To dużo czasu. Jednak całość nadal odzwierciedla moje poglądy co do prezentacji. Wojtka Seligę szanuję jako specjalistę, ale po prostu nie zgadzam się z jego poglądami.
Projekt używa kilku wersji Javy. Tak mniej więcej czterech, czyli od 6 do 9. Nic nadzwyczajnego, ale czasami mavenowi trzeba podstawić inne JDK. I tu zaczyna się robić ciekawie…
Listing 1. Domyślna konfiguracja JDK
$ echo $JAVA_HOME /usr/lib/jvm/java-9-oracle
To nas nie zadowala z kilku różnych powodów. Maven co prawda ruszy, ale Java 9 poprzerzucała kilka przydatnych rzeczy i na przykład pluginy do generowania kodu nie za bardzo chcą działać. Jak sobie z tym poradzić?
Listing 2. Rozwiązanie proste
$ export JAVA_HOME=~/jdk-8
Tyle tylko, że jak będziemy chcieli coś zmienić, to znowu trzeba eksportować, a tu jeszcze dochodzą różne wydania w ramach „dużej” wersji języka. Można oczywiście to opędzić dodając odpowiedni skrypt i dodając go do $PATH! No nie…
Gdy uruchamiamy skrypt (proces) w bashu, to tworzona jest kopia wszystkich zmiennych środowiskowych i skrypt dział na tej kopii. Nie ma dostępu do zmiennych procesu rodzica. Inaczej mówiąc, jeżeli wykonamy kod z listingu 2 w skrypcie, to po zakończeniu skryptu, zmienna JAVA_HOME w aktualnej powłoce, będzie miała taką samą wartość jak przed wywołaniem skryptu.
To może aliasy? Aliasy mają to do siebie, że są rozwijane w ramach bieżącego procesu, ale nie mogą przyjmować parametrów. Można sobie zdefiniować kilka aliasów i mieć z głowy. Jeżeli jeszcze dodatkowo zautomatyzujemy tworzenie aliasów przy starcie powłoki, tak by opierając się na konwencji nazewniczej, generować alias per folder z JDK, to już miód. Osobiście ten pomysł nie przypadł mi do gustu. Bardzo mocny, ale ma pewną wadę. Jest zbyt dynamiczny jak na mój gust. Tak naprawdę nie wiem, co mam dostępne.
Opcją pośrednią jest zdefiniowanie funkcji w pliku .bashrc. Funkcja taka jest wykonywana w kontekście bieżącej powłoki. Mamy do niej dostęp i możemy ją swobodnie modyfikować.
Listing 3. Przykładowa implementacja.
use-java(){
export JAVA_HOME=~/jdk-"$1"
}
Podsumowując, należy raz jeszcze wspomnieć, że skrypty (procesy) uruchamiane w powłoce są odseparowane od środowiska rodzica i nie mogą go zmieniać. Warto o tym pamiętać, bo pozwala, to na uniknięcie wielu uciążliwych błędów.
Nowa fabryka, nowy projekt, nowe wyzwania. Tak można by podsumować ostatnie trzy tygodnie w moim wykonaniu. Projekt został przejęty po innej firmie, która się zwinęła z rynku. Otrzymaliśmy niewydolne repozytorium svn z pełną historią, dokumentację i tyle. Kilka osób w zespole przeszło z tamtej firmy, ale jest to dla nich stan przejściowy. Co najważniejsze nie mamy, poza kodem, nic innego. Trzeba wszystko zestawić praktycznie od zera.
Dziś chciałbym opisać nasz pomysł na code review. Jednak zanim do tego przejdę, to krótkie wprowadzenie, które przybliży, dlaczego wybraliśmy takie, a nie inne rozwiązania.
Jak już wspomniałem mamy kod, ale nie mamy żadnego narzędzia, które pozwoliłoby nam na organizację procesów. Nie mamy też budżetu na zakup JIRY, a charakter projektu, bankowy core, wyklucza wypchnięcie całości na rozwiązanie chmurowe w rodzaju Githuba czy Bitbucketa. Poszukiwaliśmy zatem rozwiązania opensource, bezpłatnego w opcji self-hostingu, oraz kompletnego. Kompletność oznacza, że w jedynym narzędziu, albo grupie narzędzi współpracujących ze sobą, mam dostęp do wszystkich elementów związanych z prowadzeniem projektu. Tak właśnie działa JIRA z przyległościami. Grupa narzędzi, które możne ze sobą łatwo zintegrować. Jednak JIRA jest poza zasięgiem budżetu. Po krótkim rozpoznaniu wybór padł na Phabricatora.
Phabricator jest otwarty, bezpłatny i zawiera wszystko, czego potrzebujemy. Jest obsługa zgłoszeń, wiki, kanban board, zarządzanie repozytoriami kodu, CI oraz narzędzia do code review. Całość napisana w php, co oznacza, że wystarczy bardzo prosta konfiguracja po stronie serwera. Do tego całość jest żywa, to znaczy aktywnie rozwijana, oraz sprawdzona przez większych graczy np. Ubera, Facebooka, czy Fundację Wikimedia. Proces instalacji i konfiguracji jest bardzo prosty i dobrze opisany w dokumentacji. Aktualizacja do nowszej wersji polega na zatrzymaniu serwisów, zrobieniu git pull i ponownym uruchomieniu serwisów.
Przejdźmy zatem do dania głównego tego wpisu, czyli narzędzia do code review.
Przegląd kodu można prowadzić na wiele sposobów. Każdy z nich ma zalety i wady. Każdy może też być dobrze i źle wdrożony. Nie twierdzę, że nasz pomysł jest najlepszy z możliwych, ale na chwile obecną wydaje się najsensowniejszy. Przyjrzyjmy się jakie mamy możliwości i czym się różnią.
Jak sama nazwa wskazuje przeglądy takie, są wykonywane na kodzie, który już znajduje się w repozytorium. Typowy proces pracy wgląda w tym przypadku w następujący sposób:
W tym momencie możliwe są dwa scenariusze. Zamknięcie CR automatycznie łączy gałąź ze zmianami z gałęzią główną. Warunkiem koniecznym jest możliwość złączenia bez konfliktów. Drugi scenariusz to ręczne łączenie gałęzi.
Takie podejście jest o tyle fajne, że jest bardzo proste w implementacji. Zazwyczaj nie wymaga żadnych dodatkowych narzędzi poza narzędziem do CR. Całość opiera się na poleceniach naszego VCS-a. W dodatku jesteśmy niezależni od silnika VCS. Wady są dwie. Po pierwsze przeglądany kod jest już w repozytorium. Po drugie nie wszystkie silniki VCS są, wstanie płynnie działać w ten sposób. Chyba najlepszym przykładem jest SVN i jego model tworzenia gałęzi. Dla dużej ilości danych będzie to powolne, a ciągły schemat nadawania numerów wersji będzie tylko przysparzał problemów. W dodatku nie mamy możliwości zablokowania commitowania do głównej gałęzi. Podobnie w git. Co prawda można tak skonfigurować narzędzia, by nie akceptowały commitów bezpośrednio do mastera i pozwalały jedynie na pull requesty, ale na „czystym” gicie jest to, co najmniej uciążliwe.
W praktyce podejście post-commit nie służy do CR rozumianego jako element wewnętrznego procesu w zespole. Podejście to służy do audytu kodu przez podmiot zewnętrzny. Załóżmy, że dowieźliśmy sprint na czas. Jednym z artefaktów końcowych, jest opis zmian w kodzie w formacie podobnym, do tego którego używamy do CR. Nasz klient wysyła taki pakiet do na przykład usługi Veracode, gdzie zmiany są badane pod kątem luk bezpieczeństwa. Inaczej mówiąc, wszystkie zamiany wprowadzone przez zespół podlegają przeglądowi przez niezależny podmiot.
Phabricator wspiera ten model i co ciekawe jest to osobny moduł. Audyty są czymś niezależnym od CR. Jest to osobne menu.
Wspomniałem wyżej, że w gicie można wykorzystać trochę inny mechanizm, a mianowicie pull requesty. Schemat działania jest podobny do poprzedniego. Też trzeba zacommitować zmiany do gałęzi w zdalnym repo (bare), a następnie wypchnąć zmiany do własnego repozytorium. Kolejnym krokiem jest stworzenie PR-ki do repozytorium docelowego. I działa to świetnie. PR-ka może zostać przejrzana i zaakceptowana bądź odrzucona. Kolejne zmiany w naszym repozytorium będą uwzględniane w PR-ce we w miarę zautomatyzowany sposób. Oczywiście o ile korzystamy z jakiegoś narzędzia w rodzaju githuba.
Zresztą jest to najpopularniejsza metoda pracy z repozytoriami na githubie. Ma jednak pewien feler. W pewnym momencie mamy dwa repozytoria, które mają w głównych liniach kodu dwie różne wersje kodu. Można to naprawić. Wystawiając PR gałęzi z naszego repozytorium do głównej gałęzi repozytorium docelowego… co efektywnie można zredukować do commitowania do gałęzi w repozytorium docelowym i w efekcie PR staje się takim post-commit CR, tyle tylko, że jest ładniej nazwane. Dodatkową wadą jest ograniczenie się do rozproszonych VCS-ów. Jeżeli chcemy zrobić coś takiego w SVNie, to musimy korzystać z mirroringu i personal upstreamów, które są zwyczajnym hakiem.
I tu dochodzimy do przeglądów wykonywanych przed commitem. Przy czym „przed commitem” oznacza, że zmiana nie wycieka poza nasze lokalne repozytorium. Na czym to polega. Zamiast wysyłać zmiany do zdalnego repozytorium, przygotowujemy patch file, który będzie podlegać przeglądowi. Taki patch file jest traktowany jako wsad do narzędzia CR. Akceptacja zmian pozwala nam na ich opublikowanie w zdalnym repozytorium.
Taki model jest przyjęty wśród programistów jądra. Linus ostatecznie akceptuje lub odrzuca zmianę. Zanim zmiana trafi do niego, jest oczywiście przeglądana przez opiekunów poszczególnych modułów, a oni otrzymują wstępnie przesiane zmiany przez opiekunów poszczególnych plików lub fragmentów kodu. Ci są adresatami zmian, które są tworzone przez zwykłych programistów. Oczywiście opisuję tu model w sposób uproszczony, ale to mniej więcej tak działa. Zaletą tego modelu jest to, że zmiana nie jest opublikowana przed akceptacją. W dodatku całość jest niezależna od systemu VCS, ponieważ opiera się na patch filach, które są standardem. Najpoważniejszą wadą jest użycie formatu patch file, który ma pewne ograniczenia m.in. w przeciwieństwie do PR nie można ich budować ze zmian, które mają różnych autorów. Drugą wadą jest konieczność przestrzegania procesu, bo narzędzia nie radzą sobie jeszcze z np. commitem bez zatwierdzenia CR. Tu na scenie pojawia się phabricator i jego narzędzie arcanist.
Tu dochodzimy do kolejnego pytania. Dlaczego nie użyć gerrita? Z bardzo prostej przyczyny. Gerrit pracuje tylko z repozytoriami git, a obsługa svn jest możliwa tylko poprzez git-svn. Tyle tylko, że git-svn wymaga gita, a my nie możemy go użyć w jednym z naszych projektów. W dodatku jest to kolejne narzędzie, które wymaga uwagi z naszej strony.
Arcanist jest konsolowym interfejsem phabricatora. Daje on dostęp do różnych modułów, ale my skupimy się na module differential, który służy do zarządzania CR.
Mała uwaga, w dokumentacji Differentiala jest mowa o pre-push CR. Wynika to z popularności gita i gitowej nomenklatury. W przypadku svn-a jest to oczywiście pre-commit.
Żeby móc korzystać z arcanista należy go zainstalować. W przypadku linuxów znajduje się on w pakiecie arcanist, który wymaga instalacji php7. Dodatkowo należy zainstalować najnowszą wersję pakietu php7.0-xml/php7.1-xml. Pakiet ten nie jest w podstawowej dystrybucji php i trzeba go samodzielnie zainstalować.
Po zainstalowaniu arcanista należy jeszcze skonfigurować projekt. Konfiguracja jest bardzo prosta. W katalogu głównym należy utworzyć plik .arcconfig, który jest prostym JSON-em:
Listing 1. Plik .arcconfig w wersji minimum.
{
"phabricator.uri" : "http://phabricator.yourcompany.pl/",
"repository.callsign" : "NAZWAREPO"
}
Zgodnie z dokumentacją minimalna konfiguracja może być ograniczona tylko do własności phabricator.uri, ale bez repository.callsign arcanist może mieć problemy z rozpoznaniem repozytorium projektu. Teoretycznie robi to automatycznie, ale nie zawsze to wychodzi. W szczególności gdy nazwa lokalna różni się od zdalnej.
Proces tworzenia CR jest niezależny od silnika VCS, którego używamy. Phabricator wspiera git-a, svn-a i mercicurala więc nie jest źle. Po wprowadzeniu zmian w kodzie wystarczy w linii poleceń uruchomić:
Listing 2. Tworzenie CR
$ arc diff
Zostanie uruchomiony edytor, w moim przypadku jest to nano, w którym musimy wypełnić szablon z informacjami:
Listing 3. Szablon CR
<<Replace this line with your revision title>> Summary: Test Plan: Reviewers: Subscribers: # NEW DIFFERENTIAL REVISION # Describe the changes in this new revision. # # arc could not identify any existing revision in your working copy. # If you intended to update an existing revision, use: # # $ arc diff --update <revision>
Obowiązkowymi polami są tytuł, podsumowanie i plan testów. Pola Reviewers i Subscribers są opcjonalne i podajemy tam loginy. Po zapisaniu i wyjściu z edytora arcanist utworzy CR w phabricatorze. W tym celu używa crul-a.
Jeżeli pracujemy z gitem, to nie musimy wykonywać git commit, bo arc diff zrobi to za nas. W przypadku svn-a zostanie wygenerowany patch file i nie będzie zmian w repozytorium. Pytanie, które zmiany są brane do CR? Odpowiedź jak zawsze brzmi, to zależy. W przypadku svn-a jest są to zmiany, które są widoczne w svn status. W przypadku git-a są to zmiany widoczne w po zaaplikowaniu git merge-base origin/master ..HEAD. Inaczej mówiąc wszystkie różnice pomiędzy aktualna gałęzią, a zdalnym masterem.
Jeżeli chcemy zobaczyć, jakie CR czekają na nas, wystarczy wydać polecenie arc list.
Listing 4. Lista oczekujących CR
$ arc list * Needs Review D6: Testowe CR w svn
Należy tu zwrócić uwagę na identyfikator CR. W tym przypadku jest to D6. Będzie on nam potrzebny do dalszej pracy z arcanistem. Jeżeli CR-ka zostanie zaakceptowana, to wystarczy klepnąć zmianę i wysłać ją do repozytorium. Niestety nie ma jednego spójnego interfejsu do wykonania tej operacji.
Listing 5. Zamknięcie niezaakceptowanego CR w svn-ie
$ arc commit --revision D6
Revision 'D6: Testowe CR w svn' has not been accepted. Commit this
revision anyway? [y/N] N
Usage Exception: User aborted the workflow.
Oczywiście można wymusić zamknięcie CR i wysłać zmiany do repozytorium.
Listing 6. Zamknięcie niezaakceptowanego CR w git
$ arc land --revision d7
Landing current branch 'master'.
TARGET Landing onto "master", selected by following tracking branches upstream to the closest remote.
REMOTE Using remote "origin", selected by following tracking branches upstream to the closest remote.
FETCH Fetching origin/master...
This commit will be landed:
- 4affd51 OK
Revision 'D7: OK' has not been accepted. Continue anyway? [y/N]
Usage Exception: User aborted the workflow.
Jak widać svn i git mają osobne polecenia. To nie jest najfajniejsze rozwiązanie, ale daje radę. Jeżeli CR zostało zaakceptowane, to nie otrzymamy komunikatu, że coś wisi, tylko zmiana zostanie wysłana na serwer. Tu właśnie wychodzi największa zaleta modelu pre-commit/pre-push w porównaniu do pull requestów. Zgłoszenie CR jest nieblokujące. Oczywiście, jeżeli ktoś odwali maniane i wyśle kod, który nie był przejrzany, to odpowiednia adnotacja pojawi się w historii CR. Winny zostanie już odpowiednio nagrodzony…
Czas na krótkie podsumowanie. Phabricator ma bardzo dobrze przemyślany mechanizm przeglądów kodu. W dodatku jasno rozgranicza przeglądy od audytów. Wspiera kilka różnych rodzajów repozytoriów. Co prawda interfejs nie jest spójny, ale różnice są minimalne. Całość jest nieblokująca i w przeciwieństwie do klasycznych gitowych PR łatwiejsza do zrozumienia.
Rozwiązanie nie jest pozbawione wad. Największą jest konieczność używania arcanista, który jest dodatkowym oprogramowaniem. Jeżeli używamy niestandardowego sposobu zarządzania commitami, to musimy zapomnieć o automatyzacji niektórych czynności. Gotowe rozwiązania muszą zostać dostosowane. Niektórych może też zaboleć, że całość jest w php, co powoduje, że kod jest rozszerzalny dla zespołów niephpowych.
Podsumowując, lubię i polecam. Pobawić się można, a potencjalne korzyści są duże. Jeżeli zatem szukasz narzędzia do ogarniania projektu, to phabricator będzie całkiem fajny.
Zasadniczo leżę i kwiczę. W zasadzie to cichutko pokwikuję. Bywa, zdarza się najlepszym. Oczywiście przeglądam sobie internety i trafiam na ten oto wywiad. Co w środku? Ano taka oto perełka:
Odwrócę pytanie. Czego absolutnie nie polecasz osobie uczącej się programować?
Pójścia na studia. Przynajmniej w Polsce. To będzie strata czasu i brak konkretnego przygotowania do pracy.
Kilka dni temu prowadziłem rozmowę rekrutacyjną do mojego teamu. Trafił nam się osobnik, który ogólnie rzecz ujmując, studiował dość dokładnie, licencjat robił już siódmy rok. Przy czym studiował kierunek spokrewniony – elektronikę. Jednak studia zapewne były tylko dodatkiem do pracy, bo pracował już z pięć czy sześć lat i to jako programista. Na czym poległ?
Poległ na dwóch prostych pytania, na które odpowiedź poznałby na studiach:
Easy, prawda?
ps. Bohaterka wywiadu prowadzi podobno bloga technologicznego. Tyle tylko, że mało tam treści technologicznych, a więcej life stylowych.
Pierwsza z książek, której przyjrzymy się dzisiaj, jest chyba najważniejszą w 2017 roku książką poruszającą kwestie społeczne. Tyle tylko, że jest to książka marna. Mamy tu mieszankę treści wartościowych. Chociażby historię ratownika medycznego, laureatki studenckiego nobla, która nie za bardzo może znaleźć pracę zgodną z kwalifikacjami czy nawrócenia uberkuca po kuracji MLMem. Oraz treści chujowych jak płacz dziewczyny, która postanowiła studiować hobby (teatrologię czy coś w ten deseń) czy narzekania dziennikarki-freelancerki. I szkoda mi tej książki, bo autor spierdolił koncertowo arcyciekawy temat.
Czego mi w tej książce zabrakło? Przede wszystkim głębszej analizy, dlaczego rynek pracy wygląda tak, a nie inaczej. Rzuciła mi się w oczy wzmianka o „mentalności folwarcznej”, które to pojęcie, zresztą źle zapisane, bo chodzi o relację folwarczną, pochodzi z eseju Andrzeja Ledera pod tym samym tytułem. Weźmy teraz to pojęcie i zestawmy je z historią Katji Schrodinger, czyli autorki bloga o życiu z zespołem AspergeraW. Tyle tylko, żeby to zrobić trzeba umieć coś więcej niż wstawianie memów w internety.
Podsumowując. Mam wrażenie, że autor chce między wierszami powiedzieć „mi się udało frajerzy”. Tyle tylko, że wystarczy podejść do tej książki na spokojnie i widać miałkość. No cóż… w kapitalizmie nie wygrywa się umiejętnościami, a odpowiednim zapleczem. Niech ono nawet składa się z ludzików, lubiących dłuższe teksty na memach…
To może coś zza oceanu. Dan Lyons to dziennikarz zwolniony z Newsweeka w ramach redukcji. Po dość długim okresie bezrobocia trafia do tzw. „fabryki kontentu” w HubSpocieW, czyli startupie. 52-letni dziennikarz technologiczny, który ma na koncie poważne artykuły i jest autorem wywiadów z najważniejszymi osobami w świecie IT, musi zmierzyć się z całkowicie innym światem. Światem słabo opłacanych dzieciaków, którym zrobiono pranie mózgów i wmówiono, że pracują w najlepszej firmie na świecie. Mamy tu, oczywiście, elementy typowego korpoświata z kopaniem się po jajach, podkładaniem świni i podpierzaniem zasług. Całość doprawiona wszechobecnym sloganem „jest bosko”.
I właśnie tu wychodzi największa zaleta tej książki. Jak na dłoni widać, że w Polsce to my jesteśmy jeszcze daleko za cywilizacją białego człowieka, funfact w HotSpocie pracują praktycznie sami biali, co jest nie lada wyczynem w USA.
Warsztatowo książka jest świetna, widać tu rękę profesjonalisty. To, czego mi brakuje, to próba analizy, dlaczego system działa. Autor wskazuje co prawda na mechanizm opcji i stara się go wytłumaczyć w prosty i zrozumiały sposób, ale dla osób spoza amerykańskiego kręgu kulturowego ten mechanizm może wydawać się niejasny. Szczególnie że sposób wyceny oraz wyznaczania granicy opłacalności wymaga trochę rozeznania w mechanizmach giełdowych.
Podsumowując. Fajne czytadło. Nie jest to typowy reportaż, ale też nie jest to opowiadanie „na faktach”. Epilog „miażdży”, a dla zainteresowanych artykuł wspomniany w książce znajdziecie tu.
Na koniec warto się pokusić o porównanie tych dwóch książek. Obie dotykają tego samego problemu. Rynek pracy zmienił się wraz ze wdrożeniem neoliberalnych reform pod koniec lat 70-tych. Problemy, które obserwujemy w Polsce, nie są niczym niezwykłym w gospodarkach opartych na liberalnym podejściu. Rzecz w tym, że USA miały za sobą cztery dekady budowania bogactwa, gdy zdecydowano się na odejście od keynesowskiego modelu gospodarczego. Polska nie miała okazji na stworzenie odpowiedniego zaplecza społecznego, przed przyjęciem „dobrodziejstw” neoliberalizmu. I to niestety widać.
ps. następna w kolejce recenzenckiej jest „Prześniona rewolucja” Ledera. Więc będzie grubo.
W dużym skrócie było zacnie.
W szczegółach to powiem tak. Jarek Ratajski zjechał adnotacje z góry do dołu. Następnie wykonał nawrót i poprawił. Świetna prezentacja o tym, że warto czasami wrócić do podstaw języka, zamiast korzystać z rozwiązań w rodzaju Springa. Później Tomek Kleszczyński opowiedział o Kotlnie. Bardzo podstawy, ale miało to ręce i nogi. W tym samym czasie Przemysław Hojnacki mówił o chatbotach. Trochę wyszła z tego prezentacja marketingowa narzędzi i jakoś tak sztywno było. Nie sztywno było za to na prezentacji Tomka Borka, który przeszedł przez historię Javy, a następnie skompilował to, co będzie w i o Javie 9 na JDD. Szkoda tylko, że organizacja dała ciała z rzutnikami.
Potem był obiadek i młodzi programiści mogli przeżyć chwilę „historycznej grozy”, stojąc w kolejkach po papu.
Po obiadku poszedłem na prezentację Heinza Kabutza o Fork/Join i sposobach na zwiększenie utylizacji sprzętu. Z prezentacji twardych to była chyba najlepsza w pierwszym dniu. Przy okazji załapałem się na promocję kursów robionych przez jego firmę. Wyglądają całkiem zacnie. Potem udałem się na prezentację Piotra Wittchena o reactive streamach w bibliotece standardowej. Może byłem już nieogarnięty, ale jakoś tak mi to nie pasowało. Odpuściłem po 20 minutach. Ostatnia sesja tego dnia, w której uczestniczyłem to opowieść Mateusza Gajewskiego o germańskim oprawcy. Dla niezorientowanych:
Świetna prezentacja o tym, jak działa dług techniczny i jak sobie z nim radzić. Później udałem się do speakers cornera by pozalegać…
A później była impreza… i zaprawdę powiadam wam alkohol to zuo…
Drugi dzień zacząłem od prezentacji Jarka Pałki o Javie 10. Była moc… może troszkę wczorajsza, ale była. Jarek mówił nie tylko o tym, co nas czeka, ale też opowiedział, dlaczego niektóre rzeczy działają tak, a nie inaczej. Później znowu odstaliśmy w kolejce po obiad, a potem coś pierdolnęło i się zrobił RoomOverflowError. Slajdy tutaj. Dzień zakończyłem na prezentacji Ewa Nestorowicz i Dominika Dzienia o tokenach U2F. Fajna mięsna prezentacja z dodatkami hardwerowymi (żeby między ząbkami chrupało). Na koniec poszedłem na prezentację Piotrka Przybyła o graylogu. Powiem tak, ze wszystkich prezentacji na tegorocznym JDD, ta była chyba najlepszą w kategorii „pójdę jutro do pracy i to wdrożę”. Świetnie opowiedziane i były przykłady.
Podsumowując. W końcu dotarłem na JDD. Było super. Tyle tylko, że znalazłem trzy wady. Po pierwsze, całość na strasznym zadupiu. Po drugie drugiego dnia koniec o 18:15 to był mocno poroniony pomysł. Po trzecie drugiego dnia przerwy na kawę po obiedzie były na wodzie i sokach, bo kawa się skończyła, a co gorsze nie było nic na ząbek 🙁 Po 17 to prawie wszyscy już o jedzeniu myśleli.
Bo w speakers cornerze na jdd pojawił się ten temat
Sendbajt
Copyright 1998 by oscyloskop
Jest to opowiesc o najbardziej chyba spektakularnej grupie hackerskiej w historii Netu oraz najgenialniejszym hackerze wsrod seniorow. Pan Jan S. , bo o nim mowa zaczal sie co prawda interesowac komputerami dopiero w wieku 68 lat lecz efekty jego zainteresowan przerosly jego nasmielsze oczekiwania.
Ale zacznijmy od poczatku.
– Pamietam jak dzis. To bylo w 1987 roku… bylem wlasnie wtedy na poczcie po swoja emeryture (u pani Halinki z 3 okienka) kiedy po raz pierwszy zobaczylem komputer. Stal na biurku przykryty pokrowcem – wspomina pan Jan. Wtedy jeszcze nic nie wskazywalo na to ze komputery stana sie zyciowym hobby pana Jana.
– W roku 1989 w bibliotece wojewodzkiej, gdzie czesto zagladalem tez byly juz komputery… pamietam, ze po raz pierwszy (i ostatni) usiadlem wtedy przed klawiatura. Kompletnie nie wiedzialem co mam zrobic, wiec najpierw przeczytalem cztery razy to co bylo napisane na monitorze. Potem jakos juz poszlo… Tego samego dnia wypozyczylem ksiazke o rosyjskich maszynach cyfrowych z ktorej dowiedzialem sie co to jest bit i bajt oraz kto to jest Lenin.
Od tej pory zaczal sie intesywny okres w zyciu pana S. Cale dnie spedzal w czytelni pochlanialac ksiazki o komputerach, systemach operacyjnych, sieciach komputerowych , ale nie tylko. W kregu zainteresowan pana Jana znalazla sie rowniez telefonia i budowa modemow, co zreszta zaowocowalo w pozniejszym czasie rewolucyjnymi metodami stosowanymi przez grupe „Sendbajt” Ale nie uprzedzajmy faktow. Na poczatku 1989 roku poznal pan S. niejakiego Mieczyslawa R., rowniez emeryta, ktory wiekszosc zycia spedzil na instalowaniu sieci telefonicznych oraz pracy na Strowgerze. Mietek (jak o nim mawial pan Jan) byl wtedy zgorzknialym 64 letnim emerytem, dysponowal jednak duza wiedza praktyczna i dlatego wlasnie pan Jan postanowil zawrzec z nim spolke w celu wyciagniecia od niego mozliwie duzo wiedzy (byc moze juz wtedy istnialy w glowie Jana S. zarysy szatanskiego planu ktory pozniej przyniosl slawe jemu oraz grupie „Sendbajt”).
Kolejny rok pan Jan spedzil razem z Mietkiem na dalszym intensywnym szkoleniu w bibliotekach i nie tylko. Prenumerata „Bajtka” otorzyla mu oczy na wiele zagadnien o komputerach o ktorych dotad nie wiedzial nic. Nieodzownym elementem zycia staly sie nocne rozmowy z Mietkiem przy kubku kakao, w czasie ktorych prowadzili ozywione duskusje a to o plikach, a to o sytemach Dos, Unix a to o protokolach sieciowych lub modemowych. Czasami w domu pana Jana pojawiala sie takze pani Bozenka – zona pana Mietka. Przygotowywala im kakao i przysluchiwala sie o czym rozmawiaja. Czasem tez zadawala pytania, ktore jednak nie zawsze mialy sens.
Gdzies tak w sierpniu 1990 pan Jan stworzyl swoj pierwszy program – byl to generator liczb losowych totolotka napisany w basicu commodore 64. Niestety program istnial tylko na kartce z notesu, a to z tego prostego powodu, iz pana Jana nie bylo stac nawet na najtanszy komputer 8 bitowy. Pozniej przyszla nauka assemblera. Okazalo sie ze pan S. ma do tego nadzwyczajny talent. Juz po miesiacu nauczyl sie wszystkich rozkazow procesora 8086. Po kolejnych 3 miesiacach zmudnej nauki mial opanowane wszystkie przerwania i byl w stanie pisac i debuggowac programy w assemblerze i to jedynie za pomoca kilku kartek papieru kancelaryjnego i olowka z gumka.Kiedy pan Jan dowiedzial sie juz dostatecznie duzo o komputerach i systemach operacyjnych przyszla pora na gruntowne studiowanie sieci, zwlaszcza rozleglych. W ciagu pol roku intensywnego wkuwania polaczonego z cwiczeniami praktycznymi pan Jan zdobyl tak wiele informacji, ze mogl np. zakodowac dowolny tekst na ciag znakow ASCII po czym zamienic to na ciag zer i jedynek oraz podzielic na pakiety wyposazone w sume kontrolna, bity stopu, parzystosci i takie tam. Po wielu treningach okazalo sie ze potrafi on z pamieci podac 1 kB plik binarny (ewentualnie zaszyfrowac go np. metoda xor w czasie rzeczywistym). Pan Mietek takze nie proznowal – na polecenie pana Jana zbudowal specjalny aparat telefoniczny z dwoma mikrofonami oraz z trzema sluchawkami.
Mowi pan Jan:
– Tak pod koniec roku 1991 mialem juz duzo wiadomosci i wiedzialem dokladnie czego chce. Chcialem dostepu do niezliczonych zasobow wiedzy zgromadzonej na wszystkich komputerach swiata. – Mowiac to pan Jan wzrusza sie bardzo i widac, ze silnie to przezywa.
– Przelomem byl styczen 1992. Czytalem wlasnie o najnowszych metodach modulacji sygnalu w pasmie telefonicznym, kiedy wpadl Mietek z nowym „Bajtkiem”. Byla tam opublikowana lista wszystkich BBS-ow w Polsce. Postanowilismy sprawdzic te numery. Pozniewaz ja nie mam telefonu, ubralem sie cieplo i poszlismy nie opodal do automatu. Wg „Bajtka” w naszym miescie byly 3 BBSy. Drzacymi rekoma wykrecilem numer pierwszego BBSu i w chwili gdy chcialem wrzucic zeton Mietek powstrzymal mnie i sam energicznie przywalil w aparat centralnie od frontu. Spojarzalem na niego ze zdziwieniem, ale nie bylo czasu na wyjasnienia gdyz w tym momencie nastapilo polaczenie, a ja w sluchawce uslyszalem dzikie piski o duzym natezeniu wpadajace wprost do mego ucha. W pierszym odruchu wypuscilem sluchawke z reki, ale zaraz sie opamietalem i Mietek podal mi sluchawke znowu. Tym razem bylem juz przygotowany i staralem sie rozroznic poszczegolne dzwieki. W mlodosci bylem miedzy innymi muzykiem jazzowym, wiec od razu wylapalem czestotliwosc nosna na 1200 Hz. Slychac bylo regularne sekwencje piskow. Powtorzylo sie to w sumie szesc razy i modem po drugiej stronie sie wylaczyl. Czasu nie bylo duzo, ale juz po tym pierwszym polaczeniu zorientowalem sie, ze mam do czynienia z jakims modemem 2400 a takze rozpoznalem rodzaj modulacji. Za chwile wykrecilismy ten sam numer raz jeszcze i tym razem sprobowalem nawiazac lacznosc. Gwizdanie do mikrofonu niewiele pomoglo, wiec wpadlem na pomysl zeby Mietek wymawial „aaaaaaaa” na czestotliwosci ok 2400 hz a ja w tym czasie wydawalem odpowiednie piski w celu przeprowadzenia handshake’u oraz uzyskania polaczenia z komputerem odleglym z predkoscia przynajmniej 300 bps. Probowalismy jakies 4 razy zanim sie to udalo. Jednak po odebraniu wiadomosci wstepnych oraz zalogowaniu sie do BBSa jako anonymous polaczenie zostalo przerwane, poniewaz Mietek zaniosl sie nagle straszliwym kaszlem. Mnie zreszta tez rozbolalo gardlo od wydawania piskow, oraz reka od notowania zer i jedynek. Prace takze utrudnial fakt, ze musialem jednoczesnie nadawac i deszyfrowac dane. Nalezalo zdecydowanie opuscic budke i udac sie do domu w celu obmyslenia innej strategii, zwlaszcza, ze wokolo zebral sie tlumek mlodych osob przygladajacych sie nam dosc dziwnie. No coz, to moje pierwsze polaczenie z modemem bylo moze niezbyt udane ale za to wiele sie nauczylem.
Co robil pan Jan S. w nastepnych dniach? Otoz zdal on sobie sprawe ze w pojedynke z Mietkiem wiele nie zdzialaja. Potrzebowali pomocy fachowcow. Na pierwszy ogien poszla pani Bozenka, ktora jako regularna bywalczyni coniedzielnej mszy swietej dysponowala odpowim glosem z ktorym pan S. wiazal duze nadzieje.
– Pani Bozenko, pani bedzie pelnila w naszej grupie funkcje generatora fali nosnej.
– Lo Jezu! A co to jest? W imie ojca!
– Spokojnie pani Bozenko, to nic trudnegom niech no pani powie „aaa”.
– Aa
– Ale tak dlugo „aaaaaa” i tutaj, do mikrofonu prosze.
– Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
– Dobrze. No widzi pani? Trudne? Nietrudne. Panie Mietku, odczytal pan czestotliwosc na oscyloskopie?
– Niewiarygodne! Dokladnie 2400 Hz panie Janie!
– Fantastycznie! Jest pani najstarszym generatorem fali nosnych telefonicznych na swiecie.
– No wie pan?
– Zartowalem, he he.
– Panie Janie a jak bedzie sie nazywala nasza grupa?
– Juz to przemyslalem proponuje „Sendbajt”. Moze byc ?
– Eee. Dobra.
W kolejnych dniach pan Jan pokazywal pani Bozence jak ma sie zachowywac generator fali nosnej, zwlaszcza w przypadku renegocjacji polaczenia oraz zaklocen na linii. Pan Mietek przechodzil intensywny kurs HTMLa (oczywiscie w wersji zerojedynkowej). Po tygodniu do grupy „Sendbajt” dolaczyla jeszcze pani Wanda – dobra znajoma pani Bozenki, ktora wg niej spiewala najglosniej i najpiekniej w calym kosciele.
– Bardzo dobrze! – ucieszyl sie pan Jan – pani bedzie naszym nadajnikiem oraz modulatorem!
– Ale nic nie wiem! Nie umiem! – plakala pani Wanda.
– Jak to nic ? Niech pani powie „pi pi pi pioooupipaupioiopppipipiapappe pi pi”
– pi pi pi pioooupipaupi… jak bylo dalej?
– …oiopppipipiapappe pi pi …jeszcze raz!
– pi pi pi pioooupipaupioiopppipipiappe pi pi …dobrze?
– Opuscila pani jedno pa, ale korekcja bledow modemu odbiorczego powinna sobie z tym poradzic.Poza tym doskonale.Panie Mietku!
– Slucham.
– Prosze przebudowac nasz aparat tak aby drugi mikrofon byl polaczony szeregowo z pierwszym poprzez uklad, ktory pan zaprojektuje tak aby sygnal z drugiego mikrofonu modulowal sygnal pierwszego fazowo, amplitudowo lub czestotliwosciowo w zaleznosci od polozenia przelacznika p3… Druga sluchawka ma miec dodatkowy filtr srodkowoprzepustowy na 1200 Hz …zreszta tu ma pan wstepny projekt.
– Jasna sprawa, tylko co z tymi krokodylkami, zostaja jak sa ?
– tak, i niech pan skoluje jakies 50 metrow czarnego kabla telefonicznego.
– To sie da zrobic.
Nastepny tydzien uplynal na przygotowaniach. Pan Jan zarywal noce symulujac na kartce mala siec ethernet na szesc komputerow. Bawil sie kopiujac pliki miedzy stanowiskami lub uruchamiajac programy na serwerze. Zabawa ta kosztowala go co prawda dwie ryzy papieru do kserokopiarek ale jego wiedza o dzialaniu sieci wzrosla niepomiernie.
– Nasza pierwsza akcja? No coz, to bylo w piwnicy naszego bloku. Okolo godziny 23:00 zaopatrzeni w latarki, hackomat (jak nazwalismy nasz przyrzad) oraz koszyk na ziemniaki i torbe na kompoty zeszlismy do piwnicy. Mietek od razu odszukal skrzynke z napisem >TPKod jest dostępny na licencji MIT. Jednak niektóre rozwiązania mogą być objęte inną licencją. W takim przypadku jest, to zaznaczone.
Artykuły są dostępne na licencji CC-BY.
Jeżeli spodobał ci się ten wpis, to podziel się nim z innymi lub wesprzyj autora.