Wszystkie wpisy, których autorem jest ynka

Recenzja książki „Zawód: Programista” Macieja Aniserowicza

W tym wpisie będę zachęcać Was do przeczytania dzieła blogera, który ma zasięg o dwa rzędy wielkości większy od mojego. W pierwszej chwili pomyślałam, że nie ma to sensu, bo kto miał wiedzieć o jego książce ten wie z samego źródła.  Po namyśle uznałam jednak, że wśród mojej publiczności chyba więcej jest osób, które nie są programistami i tylko nieśmiało zaczynają interesować się tym tematem – a ta wyjątkowa pozycja jest przeznaczona także dla nich.

No to piszę.

Na moim blogu znajdziesz sporo tekstów opisujących zawód programisty i starających się odpowiedzieć na pytanie, kto może go wykonywać i czy warto (linki poniżej) – ale Maciej podszedł do tematu w sposób o wiele bardziej metodyczny.

Moje teksty na podobne tematy:

Maciej, czyli kto?

Maciej Aniserowicz jest autorem popularnego bloga https://devstyle.pl/, na którym pisze o technologiach związanych z .NET, ale także zamieszcza sporo ciekawych, ogólniejszych felietonów. Oprócz tego jest konsultantem, nagrywa podcast, występuje na konferencjach, prowadzi szkolenia. Jest organizatorem konkursu https://devstyle.pl/daj-sie-poznac/, który dał mi sporo inspiracji i motywacji podczas mojego pierwszego urlopu macierzyńskiego (dał mi także, w ramach nagrody za 3 miejsce, moją własną licencję na IntelliJ).

Ostatnio wydał książkę „Zawód: Programista” (https://zawodprogramista.pl/), której recenzję zamieszczam poniżej w postaci subiektywnej listy plusów i minusów tego dzieła.

Plus: świetnie ustrukturyzowana – spis treści daje dobre pojęcie, o czym jest ta książka

Mogę powiedzieć krótko, o czym jest ta książka: o tym, jak wygląda praca programisty, jakich potrzeba predyspozycji, jakie są możliwe poddziedziny, czy da się przekwalifikować, na jakie można liczyć zarobki… Ale zamiast wierzyć mi na słowo, możesz po prostu zerknąć na dostępny w Internecie spis treści i od razu będziesz wiedzieć, o czym i dla kogo jest ta książka.

Treść jest świetnie przemyślana i ustrukturyzowana. Jak maile pisane przez programistów 😊

W każdym razie, nie kupujesz kota w worku.

Plus: naprawdę jest takie zapotrzebowanie na rynku

Być może przytaczałam już tę historię w którymś z moich wcześniejszych wpisów. Mam dobrego znajomego, który na żale znajomych „humanistów” na temat wysokości zarobków i traktowania pracowników w zawodach związanych ze sztuką, kulturą lub urzędami reagował irytacją i za każdym razem ucinał dyskusję twierdząc, że powinni przekwalifikować się na inny, potrzebny zawód (czyli, w skrócie, nasz zawód). Wydawał się bardzo pewny swego, aż któregoś dnia jeden z wspomnianych humanistów stanął wycieńczony na jego progu i poprosił o wskazówki, jak dokładnie się przekwalifikować. Nagle, gdy wygadany znajomy miał stać się odpowiedzialny za poprowadzenie osoby, która chce przeprowadzić taką zmianę w swoim życiu – nie był już tak pewny swego. Ostrożnie wykręcił się od udzielenia konkretnych porad.

Maciej, oczywiście, nie bierze odpowiedzialności za czyjąś reorganizację życia zawodowego, ale opisuje kroki i warunki pozwalające się na coś takiego odważyć. Wiem, że istnieje duża grupa osób, które na taki właśnie poradnik czekają.

Sama podjęłam kiedyś próbę nauczenia grupy lingwistów podstaw programowania (począwszy od pisania gramatyk formalnych dla znanych im języków naturalnych). Okazało się, że około jedna trzecia zespołu lingwistów i filologów doskonale sprawdziła się w tej roli. Część z nich pracuje dzisiaj jako programiści lub testerzy.

Plus: to jest po polsku.

W czasach self-publishingu niestety nie można tego brać za pewnik, ale ta książka rzeczywiście jest napisana po polsku. Przecinki są we właściwych miejscach (mam wątpliwości co do jednego, ale to podobno cytat), słowa są użyte zgodnie z ich znaczeniem (choć nie rozumiem kawałka o paraboli), imiesłowy działają jak trzeba. Dla mnie to istotne.

Plus: trzeźwe spojrzenie na finanse

W porównaniu do większości moich przyjaciół pracujących na etat, w IT zarabiam naprawdę dużo. W porównaniu do osób, które prowadzą własne, dobrze prosperujące firmy – niekoniecznie. To kompromis, na który w tej chwili chętnie się godzę. Nie siedzę po godzinach, a w nocy śpię. Jestem odpowiedzialna za wyznaczony dla mnie wycinek, a nie za cały dobrostan firmy. Mi pasuje.

Istnieje wiele mitów na temat nieprzyzwoicie wysokich zarobków w IT. Najwięcej szumu wywołał chyba ten artykuł: IT-arystokracja. Najbardziej zepsuta pensjami i przywilejami grupa zawodowa. W książce Maciej rzeczowo rozprawia się z zawartymi w nim (i podobnych publikacjach) tezami. Tłumaczy, jakiego wynagrodzenia można oczekiwać w jakich okolicznościach, przekonuje również, że kasa to nie wszystko. Podaje wskazówki, jak najlepiej zarządzać programistycznymi finansami – a zwłaszcza ich nadwyżką!

Mój ulubiony cytat: „Arystokracja IT”? Co to za arystokracja, która nie przeżyje miesiąca bez wypłaty?

Plus: miło obcować ze spełnionym człowiekiem

Książkę świetnie się czyta również dlatego, że napisał ją człowiek spełniony. Widać, że autor robi to, co lubi i jest w miejscu, w którym chciał być. Uwielbiam obcować z takimi ludźmi, nawet tylko przez kartki książki 😊

Domyślam się, że znajdą się osoby, które niektóre fragmenty zaklasyfikują jako przechwałki. Nawet jeśli nie wszystkie historie z życia i wyliczanki są niezbędne – mnie takie podejście napawa optymizmem.

Plus: … na dodatek człowiekiem, który nie żyje tylko pracą

Jeden z najbardziej przerażających mnie aspektów naszej pracy to programiści-maniacy, w których życiu nie ma nic poza IT, którzy czytają tylko branżową prasę i specyfikacje frameworków. O dziwo, niektórzy z nich mają nawet żony (mężów?) i dzieci. Zdaję sobie sprawę z tego, że ja sama, z moimi dziesiątkami hobby i bandą ludzi, których uważam za niezbędnych w moim życiu, nigdy nie dorównam tym ludziom techniczną biegłością. Tym bardziej raduje się moje serce, kiedy Maciej pisze o znajdowaniu czasu dla rodziny, o nieprzekraczalnym warunku braku nadgodzin. Ogólnie o równowadze w życiu.

Plus: sporo rad uniwersalnych, np. związanych z produktywnością

Temat zachowania równowagi pomiędzy życiem prywatnym a zawodowym jest ważnym motywem tej książki. Jednocześnie od początku jest oczywiste, że jeśli chcemy coś osiągnąć, musimy wykonać dodatkową pracę i znaleźć na tę pracę czas. Poczytać coś po powrocie do domu, napisać trochę kodu albo tekstu na blogu, przygotować wystąpienie. Kiedy to wszystko robić? Jak to robić dobrze? Publikacja zawiera podrozdział „Jak zmotywować się do pracy po pracy?”, ale także poza nim przemycone jest trochę wskazówek na temat efektywnego zarządzania czasem (np. o metodzie pomodoro). To bardzo ważne.

Swoją drogą, mogę dorzucić kilka swoich wskazówek. Moje koleżanki często wyrażają podziw wobec tego, ile rzeczy mi udaje się zrobić po pracy. Oto jedna z moich najważniejszych zasad: bez żenady płacę innym za wykonywanie powtarzalnych czynności, które niczego mnie nie uczą. Raz w tygodniu przychodzi do mnie pani sprzątająca i wymiata miejsca, do których ja nigdy nie docieram (ani mąż, ani dziecko, które za to uwielbia ładować zmywarkę). Nie gotuję codziennie. Niektóre, w tym wykształcone i pracujące zawodowo, kobiety z jakiegoś powodu czują się zobligowane do regularnego wykonywania tych czynności, niekoniecznie ze względów finansowych. Później trudno im znaleźć czas na cokolwiek innego. A dzieci rysują w przedszkolu mamę z odkurzaczem.

Plus: odnośniki pozwalające dokładniej zgłębić temat

Książka ma bardzo strawną objętość – czytałam ją tylko przy karmieniu noworodka, skończyłam w trzy dni. Bardzo podoba mi się, że w wielu miejscach wskazuje źródła i autorów, z których publikacjami warto się zapoznać. Zawiera także linki do stron Macieja, gdzie znajdziemy listy blogów, inspiracji i inne obszerne zasoby, które niepotrzebnie nie zajmują miejscach na kartkach i które Autor może na bieżąco aktualizować. Zamierzam za kilkoma z takich linków podążyć.

Plus (i trochę minus): osobiste spojrzenie

Maciej pisze o swoim osobistym (przebogatym) doświadczeniu, starając się wyciągnąć z niego wnioski dla wszystkich. Przez większość czasu to się udaje. Na dodatek jest to dobre dla narracji – całą historię czyta się jak dobrą powieść 😊. Mimo wszystko, oczywiście, nie każdemu uda się powtórzyć tę sztukę. Ludzie mają różne zdolności i różne granice. Sukces to ciężka praca, ale także odrobina szczęścia. To, że Maciejowi coś się udało, nie musi znaczyć, że uda się nam po odtworzeniu jego kroków. Z drugiej strony, coś, co jego zatrzymało, dla kogoś innego może okazać się jedynie drobnym potknięciem.

Minus: za mało dystansu do coachingu

Może jestem cyniczna i zblazowana, ale w dzisiejszych czasach – coachów sprzedających masom truizmy i cudze cytaty jako własne przemyślenia – jestem bardzo sceptycznie nastawiona do sformalizowanych form samorozwoju. Kiedy Maciej zupełnie bez ironii pisze o „wychodzeniu ze strefy komfortu”, włączają mi się wszystkie dzwonki alarmowe. Choć to oczywiste, że to akurat niezbędny krok, żeby do czegokolwiek dojść.

Minus: trochę sucharów, trochę powtórzeń

Książkę pisał informatyk. Nie wiem, czy trzeba dodawać więcej 😉 Parę tez i anegdotek powtarza się w kilku miejscach (choć w większości przypadków Autor sam to zauważa). Parę zdań mnie zażenowało. Najbardziej chyba to: „Wyobraź sobie, że młoda mama na macierzyńskim może zobaczyć światełko w tunelu, błyskające znad garów i mopa.” Wyobraź sobie, Macieju, że dla żadnej z moich rozlicznych koleżanek w rozlicznych zawodach urlop macierzyński nie sprowadził się do „garów i mopa”.

Minus: za mało o dyskryminacji w naszym zawodzie

Problem dyskryminacji w naszym zawodzie jest prawdziwy. Dostaje się kobietom, mniejszościom narodowym, osobom starszym. Sama miała szczęście pracować w firmach, które zapewniały przyzwoity poziom kultury w pracy – a i tak przynajmniej raz zdarzyło mi się płakać w toalecie po kolejnym komentarzu na temat umiejętności kobiet (chociaż pan „nie mówił o mnie”). Natomiast słyszę co nieco od koleżanek z innych firm. Mam nadzieję, że kiedyś dostanę pozwolenie, żeby ze szczegółami opisać tu historię człowieka, który naskarżył na koleżankę do działu HR za „psucie atmosfery w pracy”, kiedy protestowała przeciwko kolejnym rasistowskim żartom na open space.

Sama zaczynam zwracać uwagę na to, że zaczynam zawyżać średnią wieku w firmie. Irytują mnie zaproszenia do „młodych, dynamicznych zespołów” – nie tylko dlatego, że są nic nie znaczącą kalką. A przecież Maciej jest chyba mniej więcej w moim wieku?

Polecam ten ciekawy artykuł na temat ageismu i pracy w Google po pięćdziesiątce (nie, nie, my aż tak nie zawyżamy 😀 ): Surviving as an Old in the Tech World.

Podsumowanie

Zdecydowanie polecam książkę zarówno aktywnym programistom, jak i osobom rozważającym wybór tej ścieżki kariery, na różnych etapach życia. To bardzo trzeźwe i uczciwe spojrzenie na nasz zawód. Nawet jeśli nie wszystkie porady są uniwersalne i nawet jeśli kilka istotnych kwestii pominięto, jest tam sporo przydatnych informacji i wskazówek, a także materiału do refleksji nad przebiegiem własnej kariery.

Bonus personalny: moja walka o papierowy egzemplarz

Książkę można było zamówić z wyprzedzeniem, ale ja czekałam na moment, kiedy naprawdę będzie gotowa. Jak tylko zorientowałam się, że to już, weszłam na stronę https://zawodprogramista.pl/ w celu jej zamówienia. Ręka zadrżała mi nad formularzem adresowym. Chciałam i wersję elektroniczną, i papierową, ale data uniemożliwiła mi zamówienie książki do domu. Otóż akurat wybierałam się do innego miasta, żeby skorzystać z usług prywatnego szpitala położniczego (ciągle się zastanawiam, czy ten blog jest dobrym miejscem na szczere porównanie warunków i przestrzegania standardów w placówkach NFZ i prywatnych; naprawdę jest o czym pisać). Zarezerwowałam tam mieszkanie na okres dwóch tygodni (żeby być w odległości 15 minut, a nie 3 godzin od szpitala), ale nie wiedziałam dokładnie ile dni zostanę i nie znałam z góry dokładnego adresu z numerem mieszkania. W końcu zamówiłam książkę pierwszego dnia pobytu tam, a drugiego byłam już w szpitalu! Na szczęście właścicielka mieszkania okazała się na tyle miła, żeby odebrać przesyłkę i wysłać mi ją do Poznania. Jeszcze nie doszła, dlatego nie widać jej na półce.

Liliana ma dzisiaj 13 dni i jest uwielbiana przez wszystkich domowników na czele ze swoją starszą siostrą.

Literatura informatyczna: wspominki o tłumaczeniach i korektach

Dawno, dawno temu zajmowałam się tłumaczeniem książek (informatycznych). Początkowo dorabiałam w ten sposób do stypendium doktoranckiego, ale nie bez znaczenia była dla mnie przyjemność płynąca z pracy z językiem oraz możliwość poznania nowych technologii. Żeby coś dobrze przetłumaczyć, należy to najpierw dogłębnie zrozumieć. Drogi na skróty nie ma.

Stan circa 2010, przed nocą oczyszczenia na moich półkach z książkami IT

Dlaczego akurat teraz piszę o tym na blogu?

Po pierwsze, z racji zalania mózgu prolaktyną (jeszcze chwilka!) nie jestem w stanie generować nowych, ciekawych tematów i chciałam odgrzać tekst ze starego bloga. Ostatecznie napisałam artykuł zupełnie od nowa.

Po drugie, odezwał się do mnie mój ulubiony redaktor z propozycją przetłumaczenia nowego wydania książki, nad którą pracowałam dobrych parę lat temu. Nie zgodziłam się (patrz punkt 1), ale zaproponowałam wykonanie korekty merytorycznej tekstu przełożonego przez nowego tłumacza. To było dla mnie zupełnie nowe doświadczenie i chcę podzielić się przemyśleniami.

Po trzecie, znajoma rozważająca wejście w obszar tłumaczeń IT zadała mi kilka pytań o tę pracę, w związku z czym musiałam przypomnieć sobie, jak to było.

Po czwarte, wreszcie, to kolejna ścieżka rozwoju w szeroko rozumianym świecie IT, a przecież o tym jest ten blog.

Jak się dostaje taką pracę?

Wydawnictwa techniczne, inaczej niż czysto  literackie, miewają na stronach zaproszenie do współpracy dla tłumaczy. Szukają raczej znających język praktyków niż osób z papierami tłumacza czy filologa.

Rekrutacja polega najczęściej na przetłumaczeniu próbki (za darmo), a następnie już rozdziału książki (za pieniądze). Jeśli po tym doświadczeniu obie strony będą zadowolone, przyszły tłumacz otrzyma propozycję przekładu, kiedy pojawi się coś ze zgłoszonej przez niego dziedziny.

Cały proces może trochę potrwać, nawet kilka miesięcy.

Co jest łatwe, a co jest trudne w przekładach IT?

Kilka uwag poniżej.

1. Amerykańscy autorzy zawsze zwracają się czytelnika bezpośrednio

W pierwszych tłumaczonych przez siebie książkach stosowałam wymyślną ekwilibrystykę form bezosobowych i tradycyjnych zwrotów do „Czytelnika”, ale po jakimś czasie uznałam, że w literaturze IT i poradnikach przyjęła się już przecież forma bezpośrednia. Problem krążenia wokół bezpośrednich zwrotów wydawał się rozwiązany.

Niestety, w tej sytuacji ujawnił się nowy problem w postaci form czasowników w czasie przeszłym oraz w trybie przypuszczającym. W języku polskim ujawniają one rodzaj gramatyczny podmiotu. Kłopotliwe stały się wszystkie sformułowania typu “if you removed line 3″ („gdybyś usunął/usunęła linię 3”). Jeśli posiłkuję się słowem “czytelnik”, słowo to wymusza rodzaj i wszystko jest w porządku. Zwracając się do odbiorcy bezpośrednio, mam problem. Jasne, można kombinować, ale gdy autor w co drugim zdaniu używa takich zwrotów, po chwili staje się to męczące dla obu stron (dla tłumacza i czytelnika, autora zostawmy w tym wypadku w spokoju).

W niektórych angielskojęzycznych książkach programista jest kobietą – autorzy stosują zaimek “she” (istnieje jeszcze bezpieczna forma „they”, jeśli z premedytacją odmawiamy podania płci). Po polsku to by nie przeszło. W naszym języku żeńskie formy są bardzo silnie nacechowane. Gdybym zaczęła zwracać się do czytającego książkę programisty lub studenta “jeśli miałaś kiedyś do czynienia z usługami sieciowymi”, to wprawiłabym w konsternację przedstawicieli obu płci. Techniczna książka ma się czytać płynnie i bezproblemowo.

Finalnie bez poczucia większej żenady stosuję rodzaj męski, zakładając, że piszę do domyślnego „czytelnika”.

2. Choćby nie wiem jak dziękowali korektorom, książki i tak często są napisane niechlujnie

Klasyczny przykład to zdanie „Możesz wybierać pomiędzy poniższymi trzema dostawcami”, po którym następuja lista złożona z czterech pozycji. Tego typu błędy dość łatwo wychwycić, choć człowiek zachodzi w głowę, czym dokładnie zajmował się wymieniony z nazwiska korektor.

Niestety, problemów często jest więcej:

  • zaimki („to”) pasujące do trzech różnych wspomnianych wcześniej bytów lub nie pasujące do żadnego,
  • niedziałający kod,
  • twierdzenia, które na pewno nie są prawdziwe,
  • fragmenty kodu niemające nic wspólnego z akapitem, który ma je opisywać,
  • w połowie urwane zdania.

Jako tłumacz zawsze starałam się zrozumieć intencje autora i poprawiałam tego typu rzeczy, jednak ostatnio (o czym niżej) przekonałam się, że wcale nie jest to uniwersalne podejście.

3. Tłumaczenie książek napisanych po angielsku przez autorów, dla których angielski nie jest językiem ojczystym, to temat na co najmniej rozprawę doktorską

Programowanie jest dziedziną egalitarną. Nie trzeba być rdzennym Brytyjczykiem po Oxfordzie, żeby mieć wartościowy materiał na książkę informatyczną. Książki o popularnych frameworkach piszą więc Polacy i Bułgarzy, zarówno ci pracujący w swoich ojczystych krajach jak i ci na emigracji. Jednym i drugim wydaje się, że skoro w pracy skutecznie posługują się angielskim, ich znajomość języka wystarczy do napisania książki. No cóż, nie zawsze jest to prawda.

Najgorzej jest, oczywiście, w przypadku książek wydanych własnym sumptem, których autor oszczędzał na korekcie, ale na szczęście takie dzieła rzadko kiedy się tłumaczy. W każdym razie trudno podążyć logicznie za wywodem autora, który nie widzi różnicy pomiędzy rodzajnikiem określonym a nieokreślonym, bo w jego języku nie występują ani jedne, ani drugie.

4. Rdzenni Amerykanie potrafią przyłożyć popkulturą.

Największy koszmar i blokada tłumaczeniowa spotkały mnie przy mojej pierwszej książce, ponad dziesięć lat temu. Autor określił wówczas jakąś aplikację terminem „Borg-like”. Dzisiaj Internet podpowiada nieco więcej. Wtedy tego sformułowania po prostu nie można było znaleźć w Google.

Czego się dowiedziałam po dwóch dniach kminienia? Że Borg to rasa ze Star Treka (jestem geekiem, ale w Star Trek nigdy się nie wciągnęłam, za dużo materiału do nadrobienia), która przemocą asymiluje czy wręcz „wchłania” inne rasy. O to samo można oskarżyć niektóre aplikacje.

Jest nawet taki żarcik o SP2 do Windows XP:

„Windows XP SP2 is often called Windows XP Borg Edition, as it tries to assimilate all other software (or destroys it) as is the custom with the Borg. Also common with the borg, once you install ‚Borg’ edition, resistance is futile”

5. Listingi potrafią ciągnąć się przez cztery strony…

Tłumaczowi, jak wiadomo, płaci się od „strony tłumaczeniowej”, czyli de facto od liczby znaków w wynikowym tekście. Przy listingach jest wyjątkowo mało roboty, tym bardziej, że obecnie większość wydawnictw nie próbuje polonizować np. nazw zmiennych. Szybki zarobek.

6. … ale czasem trzeba z nich wygenerować spolonizowany zrzut ekranu.

Co robi się kłopotliwe, jeśli listing zawiera błędy i kod zwyczajnie nie chce działać. Wtedy nagle jedna strona może kosztować kilka godzin.

7. Informatyczna nowomowa.

Jakiś czas temu znajomy szykował się do napisania reklamacji do wydawnictwa odpowiedzialnego za polską wersję Millenium Larssona. Otóż na tylnej okładce podobno wydanej po polsku książki pojawiają się słowa “outsiderka” i “researcherka”.  Część rozmówców stanęła w obronie tłumacza, pisząc, że “zasysanie” słów z obcych języków jest procesem naturalnym. Moim zdaniem, tendencja do zasysania obcych słów jest usprawiedliwiona, o ile słowo o danym znaczeniu nie istnieje już w języku polskim. W przeciwnym razie to zwykłe pójście na łatwiznę, niedopuszczalne zwłaszcza w wykonaniu tłumacza, czyli osoby profesjonalnie zajmującej się językiem.

W informatyce angielskie słownictwo jest wszechobecne i obezwładniające. Zgadzam się, że wymyślanie na siłę narodowych odpowiedników jest kompletnie bez sensu. Zdarza mi się, choć nie jestem z tego dumna, używać (W MOWIE) słów takich jak “zakomitować”, “dump” albo “timeout”. Poddałam się też w końcu na słowie “framework”, z którym kiedyś próbowałam się szarpać. A jednak wiele wprowadzanych w ten sposób słów ma poprawne i zrozumiałe wersje polskie. Con za tym idzie: ie toleruję pluginów (wolę wtyczki), use case’ów (przypadki użycia), forków (rozwidlenia)… Załamuje mnie “diagram kolaboracji” (współpracy, u licha! okupacja za nami). Dla tych, którzy w tej chwili przyrzekają, że nigdy nie tkną moich tłumaczeń: zawsze podaję wersję oryginalną, która ma ułatwić odnalezienie się osobie, która wcześniej czytała oryginalną dokumentację.

8. Miło jest trzymać w ręku przetłumaczoną przez siebie książkę…

Tłumacz dostaje do ręki egzemplarz autorski! O ile książka jest wydawana na papierze, o co coraz trudniej.

9. … mniej miło, po jej otwarciu na losowej stronie, trafić na przeoczoną wcześniej literówkę.

Co rzeczywiście zdarzyło mi się w przypadku pierwszej książki, mimo że przeszła przez wszystkie tury korekty (techniczna, merytoryczna, językowa).

Tłumaczenia a sprawa kobieca

Wspomnę poniżej o dwóch aspektach.

1. Żeńskie końcówki

Wracając do wspomnianej powyżej „researcherki”, mam dość silną opinię na temat żeńskich końcówek w nazwach zawodów. Z całego serca ich nienawidzę! Nie rozumiem, dlaczego spory odłam feministek tak bardzo walczy o ich stosowanie. 

Dla mnie lekarz to lekarz, nie ma znaczenia jego płeć, tylko kompetencje i, na bliskim drugim miejscu, styl bycia i szacunek do pacjenta. Czym się różni “pisarka” od “pisarza” – pisarz tworzy literaturę, a pisarka powieści dla pensjonarek? Jakie znaczenie ma tutaj płeć?! Sprawę w moim odczuciu dodatkowo pogarsza to, że żeńskie końcówki często brzmią jak zdrobnienia, mniej poważne wersje pracy, którą wykonują mężczyźni. Nie chcę, nie potrzebuję.

2. Doskonałe żarciki

A skoro o żarcikach mowa, oto przykład, na który natknęłam się kiedyś w przekładanej przez siebie pozycji z branży:

Jak wiadomo, i jak wynika z powyższego, mężczyźni zajmują się czytaniem, kobiety zajmują się plotkami. Wszyscy o tym wiedzą.  I tu muszę oddać hołd mojemu redaktorowi. Zapytany, czy mogę sprowadzić te dwie osoby do jednej płci (wydawnictwo woli spolszczać imiona w przykładach, więc fragment i tak był do zmiany) odparł, że jeśli mi zależy, to mogę nawet je odwrócić 🙂 

Sumienność, czyli dlaczego już nie polecam tłumaczy

Dwa razy poleciłam swojemu redaktorowi kolegów-informatyków, o których wiedziałam, że znają się na rzeczy i bardzo dobrze posługują się angielskim. Dwa razy prawie się spaliłam ze wstydu, kiedy okazywało się, że panowie poprzekraczali wyznaczone terminy w taki sposób, że zgodnie z umową obcięto im część wynagrodzenia za przekład.

Nie wzięłam pod uwagę tego, że jedną z najistotniejszych cech tłumacza jest sumienność, pojęcie niezbyt dobrze znane wśród programistów. Programowanie to w dużej mierze szukanie dróg na skróty, sprytnych sposobów, żeby zrobić coś szybciej, łatwiej, mniejszym nakładem sił. Usunięcie 200 linii kodu i zastąpienie ich jedną, która robi to samo (chociaż czasami załącza 3 gigantyczne biblioteki) jest powodem do dumy. Tymczasem przy tłumaczeniach po prostu się tak nie da! Trzeba przetłumaczyć wszystko, każde zdanie (no, prawie), nawet jeśli autor przez trzy strony po prostu leje wodę, żeby nadmuchać objętość książki.

Inteligencja i rzutki umysł nie pozwolą nam usiąść do tłumaczenia po dwóch miesiącach prokrastynacji i załatwić sprawy w ciągu tygodnia. Z programowaniem czasami tak się udaje.

Czego dowiaduje się korektor

Jak już wspominałam, miałam ostatnio okazję sprawdzić się w roli korektora merytorycznego książki informatycznej. Było to dla mnie przeżycie wstrząsające, ponieważ zrozumiałam, jak różne podejście do przekładu mogą mieć różni tłumacze i jak odmiennie rozumieją swoją odpowiedzialność za tekst.

Opisywałam już powyżej swoje przygody z poszukiwaniem znaczenia terminu „Borg-like”. Utknąć nad stroną książki zdarzało mi się częściej: kiedy autor załączył niedziałający kod, a ja musiałam wygenerować screenshot, więc debugowałam i pisałam kawałki od nowa; kiedy napisał „to” i w ogóle nie było wiadomo, o co mu chodzi, więc musiałam wertować dokumentację na stronie twórcy biblioteki; kiedy podane przez niego przykłady w ogóle nie przystawały do opisywanego zagadnienia i pisałam je od nowa lub sprawdzałam, skąd je ściągnął i co dokładnie mu się pomyliło. Czułam się odpowiedzialna za jakoś tekstu, który ostatecznie podpiszę także moim nazwiskiem.

Ostatnio zasiadłam do korekty merytorycznej i zrozumiałam swoją wielką naiwność…

Co może zrobić tłumacz, kiedy oryginalne zdanie nie ma sensu? Przetłumaczyć je na polski w wersji, która również nie znaczyła zupełnie nic.

Co robi, kiedy nie działa listing i nie dało się łatwo wygenerować screenshotu? Dodaje komentarz „kod nie działa” i na tym kończy swoją pracę.

Połowa czasu spędzonego przeze mnie na „korekcie” była w rzeczywistości wprowadzaniem poprawek w dziurawym kodzie, żeby polska wersja książki, w przeciwieństwie do oryginalnej, pokazywała działające przykłady. Żebym wiedziała, że tak można, w czasach tłumaczeniowych zarobiłam tę samą kasę w o połowę krótszym czasie.

Okazało się też, że tłumacze techniczni potrafią mieć ego porównywalne do programistów na backendzie. Pokłóciłam się z tłumaczem o przekład słowa „immutable”, które zamienił na „niemutowalny” (patrz sekcja o nowomowie powyżej). Takiego słowa w języku polskim nie ma, natomiast moim zdaniem spokojnie działają tu „niemodyfikowalny” lub „niezmienny”. W większości tego typu dyskusji zaznaczałam swoje zalecenia i odpuszczałam, ale tutaj nie chciałam się pod czymś takim podpisać. Wtedy tłumacz poinformował mnie, że „tak się mówi w branży”… Co rozłożyło mnie na łopatki, bo parę stron dalej nie potrafił wygenerować screenshotu z kodu, w którym jedynym problemem był brak wywołania funkcji na koniec.

Chyba napiszę w końcu osobny tekst o ego programistów.

Czy tłumaczenia informatyczne są w ogóle potrzebne?

Z jednej strony, wydaje się, że coraz mniej. Po pierwsze, naprawdę nie sposób dziś być dobrym, oblatanym programistą bez znajomości angielskiego, a to oznacza, że coraz więcej informatyków jest w stanie czytać książki w oryginale (chociaż przeszkodą bywa cena!). Po drugie, wiadomo, rozwój sztucznej inteligencji i tłumaczenia maszynowego sprawia, że niektóre teksty można wrzucić do translatora i mniej więcej zrozumieć, o co chodziło autorowi.

Z drugiej strony, dzisiaj coraz więcej osób interesuje się informatyką i programowaniem. Te tematy stają się coraz bardziej powszechne i coraz silniej wchodzą w nasze życie. O chmurze, bitcoinach i Pythonie czytają nie tylko programiści, ale także starsze dzieci, księgowe i seniorzy. Dla nich obcy język, nawet angielski, jeszcze długo może być zaporą.

Co do automatycznie tłumaczonych tekstów… Translatory są dobre, jeśli chcemy zrozumieć komunikat systemowy lub odpowiedź na forum. Książki pełne są niuansów i wstecznych odwołań… A także błędów, które tłumacz i korektor mogą skorygować, w przeciwieństwie do automatycznego translatora 🙂 Wydaje mi się, że jeszcze przez sporo lat translatory (i pamięci tłumaczeniowe CAT) będą raczej pomocą dla tłumaczy niż konkurencją dla nich.

Choć mimo wszystko odradzałabym swojemu dziecku wybór kariery tłumacza w dzisiejszych czasach.

Quiz

W ramach pół-inteligentnej rozrywki, polecam sprawdzenie, jak w różnych krajach potocznie nazywa się znak @ („małpa”).

Przy czerwonym winie, o kobietach w informatyce, z kobietami w informatyce

Poznań tej jesieni to obszar objęty epidemią: od jelitówki, przez zwykłą grypę i przedszkolne żółte katary aż po powrót odry. Chorowanie nie sprzyja kreatywności, dlatego dzisiaj odgrzewam starszy tekst, z poprzedniego bloga. Pięć lat temu (!) postanowiłam przepytać kilka koleżanek o ich przygodę z programowaniem.

Czy dużo się od tego czasu zmieniło? Nie wprowadziłam prawie żadnych modyfikacji w treści tego wpisu. Nowe akapity oraz wtrącenia zaznaczam na ciemnozielono.

Zaczęłam rozmowę pytaniem o to, dlaczego dziewczyny wybrały informatykę jako kierunek do studiowania, a także o reakcje otoczenia na ten wybór. Oto, co odpowiedziały:

  • Eliza (programuje w Delphi, C# i JS – dzisiaj w PHP): Tak naprawdę to początkowo chciałam studiować psychologię, ale w trzeciej klasie okazało się, że nie daję sobie rady z biologią. Zawsze lubiłam matematykę, dlatego w końcu wybrałam informatykę. Rodzina nie zareagowała w żaden charakterystyczny sposób. Zawsze lubiłam też grać na komputerze – uwielbiałam Boulder Dash.
  • Ewa (obecnie używa Rails i JS  i Pythona, ale jako właścicielka małej firmy ma osobiste doświadczenia z ASP, C#, PHP i Javą): Komputery pociągały mnie od dziecka. Dużą przyjemność sprawiało mi siedzenie przy komputerze mamy, kopiowanie folderów, tworzenie prostych plików wsadowych… no i gra w Prince of Persia. Oboje rodzice pracują w dziedzinach technicznych (telekomunikacja i programowanie), dlatego cieszyli się z tych zainteresowań, chociaż każde próbowało namówić mnie do wyboru swojej dyscypliny. Jednak przed rozpoczęciem studiów w ogóle nie programowałam, jeśli nie liczyć AC Logo.
  • Magda (Java serwerowa, aplikacje na Androida, aplikacje internetowe w Javie): Mam w rodzinie tradycje matematyczne. Moi rodzice są nauczycielami matematyki, więc mój wybór nie wydawał się dziwny. Miałam zdolności w tym kierunku. Poza tym lubię rozwiązywać abstrakcyjne zagadki, a programowanie dla mnie to jak układanie z klocków!

Pytałam również o rozważane inne kierunki studiów. Eliza wspominała o psychologii. Ewa przez chwilę myślała o polonistyce, jednak ponieważ za naszych czasów można było złożyć papiery tylko w 3 różne miejsca, zarzuciła ten pomysł. Magda ukończyła dwa kierunki: matematykę i informatykę. Początkowo interesowała się matematyką stosowaną, jednak teraz jest zadowolona z tego, że wybrała programowanie.

Eliza mówi, że nie chciałaby, żeby jej dziecko było programistą – „bo to nudne”. Absolutnie się z nią nie zgadzamy, jednak trzeba przyznać, że jest to praca, o której trudno rozmawia się z ludźmi robiącymi coś innego.

W następnej kolejności zadałam pytanie, jaki był stosunek dziewczyn do chłopaków w ich szkole, na studiach i w pracy. Zapłaciłam karę za ten skrót myślowy – Ewa podała mi konkretne liczby, natomiast pierwszą odpowiedzią Elizy było „lubiłyśmy ich”

Liczby:

  • Eliza: 20-10 w liceum (rozszerzony angielski), 14-48 na uczelni, 4-22 w pracy.
  • Ewa: 11-20 w szkole (mat-fiz), 14-48, 3-3 w obecnej pracy (kierownikiem projektu jest kobieta, której zależy na zatrudnianiu kobiet, po części dlatego, że produkt jest związany z modą i faceci mają problemy z identyfikacją z nim; przez wiele dni wyśmiewali się ze słodkiego wielkanocnego zajączka, którego dziewczyny wstawiły na stronę).
  • Magda: 1/3 dziewczyn w liceum („ale to dziewczyny były lepsze”), nie pamięta dokładnych liczb z uczelni, ponieważ każde zajęcia odbywały się w innym składzie. Na pewno chłopaków było więcej. W pracy 3-10.

Kolejne pytanie: Czy Twoim zdaniem kobiety i mężczyzni na kierunku technicznym na studiach są traktowani tak samo? Jeśli nie, czy możesz podać przykłady nierówności (w obie strony)?

Spodziewałam się powodzi żalu,  jednak okazało się, że wcale nie jest tak źle. Oto, co wymieniły dziewczyny:

  • Magda: Panie w dziekanacie zawsze były milsze dla mężczyzn, zwłaszcza tych przystojniejszych Poza tym nie przypominam sobie, więc chyba grubszych spraw nie było.
  • Ewa: Jeden z prowadzących rozmawiał tylko z chłopakami, nawet jeśli mieli bardzo blade pojęcie o wspólnym projekcie, a przy tym ciągle mówił do nas „panowie”.
  • Część naszych kolegów z premedytacją zapisywała się na zajęcia prowadzone przez atrakcyjne dziewczyny, traktując je bardziej jako przyjemność estetyczną niż kompetentnego nauczyciela w istotnej dla nas dziedzinie.

Powtórzyłam to pytanie jeszcze raz, ale w kontekście pracy zawodowej:

  • Ewa opowiedziała nam o paru spotkaniach biznesowych, na których potencjalni klienci rozmawiali tylko z jej wspólnikiem, mimo że w wielku kwestiach to ona ma większą wiedzę. Twierdzi jednak, że mogło tam chodzić o kwestie autoprezentacji i smiałości w kontaktach.
  • Eliza wspomniała historię, w której rozwiązała koledze problem, z którym zmagał się od dłuższego czasu. Kolega pochwalił ją przy szefie. Szef spytał, jak Elizie udało się znaleźć rozwiązanie, a ona odpowiedziała, że wyszukała je w Google. „Aha, czyli miałaś szczęście” nie było raczej adekwatną reakcją.
  • Magda czasami w obecnej pracy spotyka się ze stwierdzeniem ze strony kolegów, że robi coś w inny sposób, bo jest kobietą. „Strasznie mnie to wkurza, bo co ma do rzeczy moja płeć.” We wcześniejszych miejscach pracy nie spotykała się z takimi komentarzami.

Chciałam również poznać opinię dziewczyn na temat liczby kobiet w informatyce. Czy jest naturalna? Czy kobiety nie chcą tego robić, nie potrafią, a może chodzi o coś jeszcze innego? Ostatecznie doszłyśmy do następującego wniosku: zmuszanie kobiet do pracy w tym zawodzie nie ma sensu, jednak zdecydowanie należy je zachęcać. Sam fakt, że programowaniem zajmuje się więcej mężczyzn niż kobiet nie musi być niczym złym ani nienaturalnym, ale aktualne proporcje nie odwzorowują realnego rozkładu umiejętności. Są warunkowane kulturowo: od małego słyszymy, że „chłopcy są lepsi w naukach ścisłych a dziewczynki w humanistycznych” a nawet że „chłopcy są zdolni, ale leniwi, a dziewczynki pracowite, ale przeciętne”.

Stereotypy działają w obie strony. Słyszymy że „tylko brzydkie dziewczyny idą na politechnikę”, „na informatykę laski idą po to, żeby łatwo znaleźć męża”, ale także „jeśli pójdziesz na techniczne studia, faceci będą cię szczypać w tyłek”.

Ewa opowiedziała nam o świeżej frustrującej sytuacji powiązanej z protestowani w sprawie ACTA. Została zaproszona na oficjalną imprezę, na której przedstawiono ją – i jej szwagra –  jednemu z polskich ministrów. Oboje zostali zaprezentowani jako informatycy, z naciskiem na to, że Ewa zajmuje się programowaniem. Minister spytał szwagra, co sądzi o ACTA a gdy ten odparł „nie wiem, nie czytałem” – kompletnie zarzucił temat, nie dając Ewie okazji do wyrażenia swojej rozbudowanej opinii.

Wracając do stosunku liczby kobiet do liczby mężczyzn. Zgodziłyśmy się, że parytety nie mają sensu, jednak więcej dobrych dziewczyn w informatyce to rzecz naprawdę pożądana. Popieramy wszelkie inicjatywy mające na celu zwiększenie udziału kobiet w tym zawodzie, pod warunkiem, że nie prowadzą one do wykluczenia facetów (spójrzmy jednak prawdzie w oczy, od tego jesteśmy jeszcze bardzo daleko).

Pod koniec rozmowy próbowałyśmy odpowiedzieć na pytanie, czy istnieją obszary informatyki, w których my (lub „większość kobiet”) sprawdzamy się lepiej niż mężczyźni (lub „większość mężczyzn”).

Wygląda na to, że większość kobiet ma jednak lepsze umiejętności komunikacyjne niż większość mężczyzn. Obecność paru kobiet w zespole ma bardzo dobry wpływ na atmosferę pracy. Często mamy więcej cierpliwości podczas objaśniania różnych spraw, także osobom spoza naszej dziedziny. Nie nosimy w sobie głębokiej nienawiści do pisania dokumentacji! Chociaż czasami praca ta nie jest odpowiednio doceniana. Być może łatwiej jest nam przyznać, że (jeszcze) czegoś nie wiemy. Obawiam się trochę, że ta cecha wcale nie wychodzi nam na korzyść: inaczej odbierane są osoby, które zaczynają zdania od „uważam, że”, a inaczej te, które mówią „jestem pewien”. Nie potrafimy wskazać żadnych poważniejszych różnic, jeśli chodzi o poziom, sposób czy styl kodowania.

Przy okazji wspomniałyśmy pewnego znanego nammężczyznę, który deklaruje, że nigdy nie zatrudni kobiet, ponieważ nie wie, jak z nimi rozmawiać. Twierdzi, że jeśli skarci pracownika-mężczyznę i powie mu, że powinien robić coś inaczej, ten powie „OK” i weźmie się do pracy. Kobieta, według, niego ”zamknie się na pół dnia w łazience i będzie płakać”. Pomijając już to, że żeby zgłaszać takie obserwacje, trzeba by jednak zatrudnić kobietę – po pierwsze, żadna z nas nie płacze z takiego powodu (dwa razy w życiu płakałam w łazience w pracy, oba razy po konkretnych seksistowskich uwagach kompletnie niezwiązanych z moją pracą). Po drugie, moje doświadczenie uczy, że co prawda wiele osób powie „OK”, co nie zmieni jednak faktu, że spróbują się za to odegrać, gdy nadarzy się okazja.

Zakończę ten radosny wpis cytatem z Magdy:

Wybrałam taki zawód, bo lubię. Chociaż czasami poziom frustracji sięga zenitu! Nie rozumiem natomiast dziewczyn, które w swojej pracy chcą udowodnić, że są lepsze od mężczyzn. Nie o to chyba w życiu chodzi żeby komuś coś udowadniać.

Sama po kilku latach przeczytałam ten tekst z zainteresowaniem. Czy coś zmieniło się w środowisku? Czy zmieniły się moje poglądy? Wypunktuję poniżej kilka luźnych uwag. 

  • Dzisiaj jeszcze bardziej niż wtedy jest dla mnie oczywiste, że za „zachęcanie” kobiet do IT (a jeszcze bardziej za ich niezniechęcanie) trzeba się zabrać bardzo wcześnie. Począwszy od sklepów z zabawkami i zawartości działów „dla chłopców” i „dla dziewczynek” oraz wyboru komplementów, jakimi obdarzamy małe dzieci. 
  • Dziś jeszcze mniej chętnie używam sformułowań „większość kobiet” i „większość mężczyzn”. 
  • Uważam,  że krótkoterminowo i w niektórych sytuacajch parytety mogą mieć sens. 
  • W sektorze IT potrzeba coraz więcej pracowników. Również z tego powodu, kobiet jest więcej niż jeszcze parę lat temu. Pewną nowością są osoby, które nie studiowały informatyki, ale udało im się przekwalifikować.
  • W backendowych zespołach, z którymi obecnie pracuję, nadal nie ma jednak ani jednej programistki (są za to dwie techniczne managerki: ludzi i produktu).
  • Głupie żarciki w pracy jak były, tak są. Wbrew obiegowej opinii, korporacje z reguły radzą sobie z tym tematem lepiej niż „przyjazne” niewielkie firmy. 
  • Wśród kobiet, które twierdzą, że jakakolwiek dyskryminacja w naszej branży jest wyssana z palca, wiele jest informatyczkami w drugim pokoleniu. Moim zdaniem potwierdza to tezę o znaczeniu warunkowania w domu, na najwcześniejszym etapie rozwoju. Jeśli dziewczynka wychodzi z domu rodzinnego przekonana, że może wszystko, jest znacznie mniej podatna na drobne przejawy seksizmu i dyskryminacji.

Mordercze mikrofalówki, czyli kilka słów o fake science

Fake news, czyli fałszywe wiadomości, to ostatnio gorący temat. Oskarżeniami o ich produkowanie przerzucają się wszystkie frakcje. Rodzinne obiady stały się jeszcze trudniejsze do przetrwania, od kiedy każdy ich uczestnik czerpie informacje o świecie z wybranego przez siebie medium, które filtruje wszelkie doniesienia przez odpowiedni światopogląd. Albo po prostu je wymyśla.

W tym wpisie chcę skoncentrować się na pewnym specyficznym wariancie tego problemu, czyli fake science – fałszywych doniesieniach ze świata nauki.

 

Zacznę od historyjki z życia.

Na początku chciałam nazwać ją „anegdotą”, ale doszłam do wniosku, że temat jest jednak zbyt ponury.

W pewnym momencie, parę lat temu, mąż mojej koleżanki zaczął się gorzej czuć. Doskwierał mu pakiet mało specyficznych dolegliwości – był osłabiony, zmęczony, źle spał, miał szarą cerę. Rozpoczął tułaczkę po gabinetach lekarskich, a w międzyczasie “dokształcał się” na własną rękę, rzecz jasna głównie w Internecie.Przez chwilę na horyzoncie pojawiła się najstraszniejsza z diagnoz, co tylko dodało mu zawziętości. Zanim poznał definitywną odpowiedź – mononukleoza, dość popularny wirus z jakiegoś powodu rzadko diagnozowany w Europie (za to często obecny w amerykańskich serialach, gdzie Hanna Horvath wykręca się od pójścia na imprezę z powodu “mono”) – zdążył przewartościować swoje podejście do życia i zdrowia. Kupuje tylko organiczną żywność. Wytoczył wojnę Big Pharmie. Zabronił rodzinie korzystać z mikrofalówki.

Sądzę, że prawie każdy, kto ma pracę, dzieci i mikrofalówkę (albo przynajmniej jedną z tych rzeczy) zgodzi się, że możliwość szybkiego odgrzania posiłku za pomocą mikrofal jest nieocenioną pomocą. Koleżanka, mając dość kłótni, ostatecznie ustąpiła i pozwoliła wyrzucić maszynę, choć podśmiewa się z poglądów i obsesji męża.

– Poza tym – powiedziała mi – w Internecie są strony, według których mikrofalówki zmieniają strukturę jedzenia w sposób prowadzący do raka. Są także takie, które mówią, że żadnego ryzyka nie ma. Skąd mogę wiedzieć, kto pisze prawdę?

Ta rozmowa dała mi do myślenia. Chodzi o inteligentną i oczytaną osobę. Jeśli ona nie potrafi poradzić sobie z rozpoznaniem, która informacja jest poparta faktami, a która to wymysł i manipulacja, jak ma poradzić sobie ogół społeczeństwa?

 

https://commons.wikimedia.org/wiki/File:MW_on_fire.jpg

Przygotowałam więc krótkie studium przypadku. Jak to jest z tymi mikrofalówkami?

Oto garść materiałów głoszących szkodliwość (zabójczość) spożywania pokarmów podgrzanych w mikrofali:

Jakie są ich istotne cechy wspólne?

  • Brak źródeł (odwołań do literatury lub linków do wiarygodnych badań lub raportów) bądź źródła kuriozalne (inne dzieła tego samego autora, linki do stron z teoriami spiskowymi, linki do artykułów na inny temat lub z odmienną tezą).
  • Sensacyjny, straszący ton.
  • „Wiedza powszechna” i brak konkretów, czyli sformułowania takie jak „opinia pewnego fizyka”, jak powszechnie wiadomo”, „czytałem gdzieś”
  • Opisy absurdalnych „eksperymentów” przeprowadzonych niezgodnie ze sztuką, których wyników nigdy nie opublikowano i nie zweryfikowano. Przykład: podlewanie dwóch (!) roślinek wodą z mikrofalówki i zwykłą wodą przez jedną osobę.
  • W załączonych przeze mnie przykładach autorzy posługują się poprawną polszczyzną, ale w ogólności warto zwracać uwagę także na poziom językowy.
  • Artykuły pochodzą z prywatnych blogów lub stron „lifestyle’owych”.
  • Linki do innych artykułów z dziedziny „alternatywnej medycyny” czy „alternatywnej nauki”.

Tu artykuły zapewniające, że jedzenie z mikrofalówki jest bezpieczne: 

Warte odnotowania cechy wspólne?

  • Linki do źródeł, w tym do prac naukowych opublikowanych w renomowanych czasopisach oraz oficjalnych raportów agencji naukowych.
  • Rzeczowy ton, odwołujący się do zasad działania urządzenia.
  • Niektóre z treści zamieszczono w domenach renomowanych instytucji, jak Centrum Nauki Kopernik.
  • Niestety, więcej takich materiałów można znaleźć w języku angielskim. Wygląda na to, że wyszukiwarka Google lepiej sobie radzi z rozpoznawaniem nierzetelnych stron w języku angielskim – tam sensacje z gatunku fake science są pozycjonowane niżej.

Kilka źródeł naukowych:

Cechy wspólne?

  • Materiały zostały odnalezione w dedykowanych wyszukiwarkach Google Scholar lub w bazach artykułów naukowych (PubMed)
  • Niestety, w przypadku wielu artykułów naukowych, w Internecie znaleźć można jedynie ich abstrakty i streszczenia. O dostęp do pełnej wersji można poprosić autorów, można go wykupić (często za kwoty szokujące w przeliczeniu na złotówki), albo udać się do biblioteki uniwersyteckiej.
  • Materiały są w języku angielskim. To jest dzisiaj język poważnej nauki i trzeba się z tym pogodzić.
  • Artykuły są pisane formalnym językiem, ich treść jest poparta danymi eksperymentalnymi i dalszymi odwołaniami do zweryfikowanych źródeł.
  • Warto odnotować, że nie istnieje zbyt wiele badań na temat szkodliwości mikrofalówki, bo w zasadzie nie bardzo jest tu co badać, podobnie jak nikt nie zajmuje się dowodzeniem, że na Księżycu nie mieszkają krasnoludki. Istnieją badania (w tym jedno z podlinkowanych wyżej), które opisują wpływ podgrzewania w mikrofali na wartości odżywcze i porównują go z wpływem innych rodzajów obróbki termicznej.
https://www.flickr.com/photos/29233640@N07/5170544729

Podsumowując, jakie cechy powinien posiadać tekst głoszący szokującą lub przełomową tezę, żeby można było potraktować go poważnie?

  1. Tekst jest najbardziej wiarygodny, jeśli zawiera odwołania do źródeł. “Źródła” nie oznaczają linków do innych artykułów w pokrewnych portalach głoszących przeróżne teorie spiskowe. Źródła to artykuły naukowe opublikowane w uznanych czasopismach, które każdy otrzymany tekst przepuszczają przez kilkuetapowy proces zanonimizowanej recenzji, tzw. peer review. Każdy artykuł jest czytany przez naukowców z tej samej dziedziny, którzy zwracają uwagę na logikę wywodu, odtwarzalność wyników, poprawność analizy statystycznej. Czasami odsyłają tekst do poprawki, często – odrzucają. Na podstawie faktów, nie własnego widzimisię. Inny akceptowalny typ źródeł to materiały informacyjne uznanych, najczęściej państwowych ośrodków badawczych.
  2. Inny typ wartościowego źródła to tekst z oficjalnym stanowiskiem rządowej agencji badawczej.
  3. Podlinkowane źródła potwierdzają tezę z artykułu! Bo wyobraźcie sobie, że nie zawsze tak jest.
  4. Najlepiej, jeśli źródła są w języku angielskim. Ktoś, kto dokonuje przełomowego odkrycia i jest pewien poprawności swoich wyników, nie ograniczy się do publikacji w lokalnej prasie, tylko postara się pokazać swoje badania na forum światowym.
  5. Z reguły im nowszy tekst źródłowy, tym lepiej. Rzadko, ale jednak zdarza się, że renomowane czasopismo naukowe opublikuje tekst, który przeszedł proces peer review, a dopiero na późniejszym etapie zawarte w nim tezy zostały obalone – najczęściej, kiedy kilka innych zespołów naukowców nie jest w stanie odtworzyć wyników opisanych w „przełomowym” artykule. Jednym z niechlubnych i bardzo szkodliwych przykładów jest artykuł Andrew Wakefielda (i kolegów) opisujący związek pomiędzy szczepionką MMR a autyzmem. Artykuł został opublikowany w czasopiśmie Lancet (a później oficjalnie wycofany) i mimo że jego tezy zostały jednoznacznie obalone a autorowi udowodniono fałszowanie wyników, środowiska antyszczepionkowe nadal powołują się na ten tekst. Tu można znaleźć szczegółowy opis tej historii (po angielsku).
  6. Tekst jest napisany poprawnie, bez błędów ortograficznych. Serio! Ktoś, kto dużo czyta (a skoro wypowiada się na tematy naukowe, to powinien dużo i ze zrozumieniem czytać), nie robi głupich błędów ortograficznych. Oczywiście, istnieje dysortografia i parę pokrewnych schorzeń. Na prywatnym blogu dużo publikującej blogerki popkulturalnej błędy są do zaakceptowania. W okołonaukowym tekście – nie. Od tego jest korekta. Jeśli nie ma korekty ortograficznej, tym bardziej nie ma co się łudzić, że ktoś weryfikuje prawdziwość treści!
  7. Nie zawiera błędów logicznych, takich jak dowody anegdotyczne (przydarzyło się mojej cioci – nawet jeśli naprawdę się przydarzyło), mylenie współwystępowania i przyczynowości (dziecko zostało zaszczepione, a dwa miesiące później zmarło – na pewno przez szczepionkę), efekt potwierdzenia (mentalnie odnotowuję tylko te przypadki, które potwierdzają moją tezę – robią to nawet lekarze, jak ten, który twierdzi, że tabletki hormonalne powodują niepłodność, bo przychodzą do niego kobiety, które brały tabletki i nie mogą zajść w ciążę… Ale kobiety, które mogą zajść w ciążę, po prostu do niego nie przychodzą) i wiele, wiele innych.
  8. Omawiane eksperymenty przeprowadzono zgodne z metodą naukową. Najłatwiej potwierdzić to przez publikację w wiarygodnym źródle (punkt 1). Jeśli wyniki dopiero czekają na publikację, co jest istotne? Odpowiednio duża, statystycznie istotna próba, niezaburzona i reprezentatywna (np. badań na temat stosunkowej liczby homoseksualistów w społeczeństwie nie przeprowadzamy w klubach dla gejów – a opinii Szwedów na temat poczynań polskiego rządu nie opieramy na ankiecie w skrajnie prawicowym szwedzkim portalu). Próba jest ślepa (ani pacjent, ani lekarz nie wiedzą, czy badana osoba dostała placebo, czy nie, bo może to wpłynąć na ich zachowanie, interpretację wyników oraz proces zdrowienia).
  9. Autor ostrożnie posługuje się sformułowaniami takimi jak: “oczywiście”, “jak powszechnie wiadomo”, “normalny”. (Prawie) nic nie jest oczywiste, wszystko powinno być poparte badaniami i statystykami.
  10. Nie linkuje do stron o reptilianach, porno i reklam środków na powiększenie penisa.

Czy mikrofalówki zabijają?

Tak. Jeśli komuś uda się włożyć głowę do działającej kuchenki. Ewentualnie jeśli podgrzeje jedzenie w azbestowym pojemniku.

 

A może pominęłam jakieś inne istotne wyznaczniki wiarygodności?

Obrazek w nagłówku pochodzi ze strony SketchPort i jest dostępny na licencji CC-BY.

Technical Product Manager, czyli kto? 10 pytań i odpowiedzi

Technical Product Manager – tak nazywa się rola, którą pełnię w obecnej pracy. W tym wpisie trochę o niej opowiadam i staram się odpowiedzieć na najczęściej zadawane pytania na ten temat.  Wśród nich także „Co to za manager, który nie ma żadnych bezpośrednich podwładnych?!”. Miłej lektury.

Co robi Product Manager?

Najważniejsze zadania Product Managera, czyli po polsku kierownika produktu, to pozyskiwanie wymagań i ich priorytetyzacja. Product Manager powinien wiedzieć, co tak naprawdę jest istotne dla klienta (niezależnie od tego, czy jest nim zewnętrzna firma, użytkownicy aplikacji czy inni programiści w tej samej firmie i tego, czy klient jest jeden czy jest ich wielu). Wiedzę tę strukturyzuje i przekazuje zespołowi programistów w postaci uporządkowanej listy (możliwie) precyzyjnie zdefiniowanych zadań. Współpracuje z zespołem, dbając o terminy i zakres produktu. Pozostaje w ciągłym kontakcie z klientem i dopasowuje końcowy efekt do jego potrzeb. Dba o wizję rozwoju (firmy, produktu) i o to, żeby programiści rozumieli dlaczego każe im się robić akurat to, co robią. Wszędzie tam, gdzie to możliwe,  jego decyzje powinny być poparte twardymi danymi.

W portalu Coursera dostępna jest całkiem ciekawa sześcioczęściowa specjalizacja poświęcona zarządzaniu produktem. Niestety, możliwość korzystania z całości materiałów jest płatna (same nagrania wykładów są dostępne za darmo).

Czym różni się Technical Product Manager od „zwykłego” Product Managera?

Rola jest zasadniczo ta sama. Inny jest człowiek, który ją wykonuje. Wielu lub nawet większość Product Managerów to osoby bez wykształcenia technicznego, które nie jest niezbędne do zrozumienia wymagań klienta i priorytetyzacji kolejnych funkcji do zaimplementowania w systemie.

Istnieją jednak zespoły, których produkt jest bardzo techniczny/niskopoziomowy. Odbiorcą ich produktu nie są końcowi użytkownicy aplikacji, tylko na przykład inni programiści (członkowie innych zespołów w tej samej firmie lub użytkownicy publicznego API). W takiej sytuacji Product Manager musi znać się na technologii, bo nowe wymagania to na przykład zmiana funkcji haszującej albo obsługa nowego standardu języka.

Czym różni się Product Manager od Project Managera?

Najłatwiej podać przykład z metodologii Scrum, chociaż w szczegółach może on być trochę mylący. Product Manager przypomina Product Ownera, Project Manager – Scrum Mastera. Najważniejsze jest to, że Product Manager odpowiada za produkt, czyli to, nad czym pracuje zespół. Project Manager odpowiada za proces i to, jak zespół pracuje. Żeby zwiększyć stopień skomplikowania, wiele firm odróżnia jeszcze rolę Line Managera lub Engineering Managera, czyli osoby, która zarządza personelem, odpowiada za rozwój pracowników i układa ich urlopy.

Czy Product Manager ma podwładnych?

Z reguły nie, chyba że jest przełożonym innych, mniej doświadczonych Product Managerów. Product Manager mówi programistom, co mają robić, ale nie jest ich przełożonym. Nie odpowiada za ich rozwój osobisty (co nie musi znaczyć, że się nim nie interesuje), nie zatwierdza urlopów. Innymi słowy, jest to rola, w której trzeba przekonać zespół do wykonania pracy, bez możliwości wydania im definitywnego polecenia służbowego!

Co jest fajnego w tej pracy?

  • Pracuję z kilkoma zespołami, które robią bardzo różne rzeczy. Dzięki temu poznaję nowe technologie i wyzwania w kilku dziedzinach jednocześnie.
  • Uczę się biznesu i patrzenia na projekty z punktu widzenia ich znaczenia dla rozwoju firmy.
  • Taka dualna techniczno-zarządzająca rola doprowadziła do tego, że firma wysłała mnie i na konferencję developerską (z zespołem programistów) i na produktową (z zespołem produktowym). Żyć nie umierać! 🙂
  • Widzę efekty, czyli skończone projekty, które są w użyciu i którymi można się pochwalić. To duża satysfakcja.
  • Przynajmniej dla mnie, taka praca jest mniej stresująca od programowania. Jako programista czuję się odpowiedzialna za kod, który właściwie nigdy nie jest dokończony i zawsze może się okazać, że coś jest nie tak. Jako PM ufam zespołowi i potrafię odsunąć się emocjonalnie od kodu na tyle, żeby uznać, że zadanie zostało wykonane „wystarczająco dobrze”.

Co (mnie) drażni w tej pracy?

  • Rola jest z gatunku niewdzięcznych, bo zyski (ukończone projekty, postęp prac, kierunek) widzą przede wszystkim przełożeni moi i mojego zespołu. Programiści czasem się frustrują, kiedy muszą zrobić coś, co jest dla nich nudne, albo coś, czego nie uważają za najważniejsze. Nie lubią szacować pracochłonności zadań, o co ich proszę. Frustrują się też kierownicy innych zespołów, którzy wcześniej (kiedy nie było PM) po prostu w dowolnym momencie odrywali zespół od pracy i prosili o przysługi, a teraz w większości przypadków muszą liczyć się z okresem oczekiwania.
  • Spośród masy potencjalnych projektów trzeba wybrać najważniejsze. Niektóre propozycje zostaną odrzucone lub przesunięte na później. Nie zawsze spotyka się ze zrozumieniem zainteresowanych osób.
  • Product Manager pracuje z zespołem programistów (lub kilkoma) ale nie do końca jest jego pełnoprawnym członkiem.
  • Pojęcie MVP (Minimum Viable Product), lub dalej projektu zrobionego „wystarczająco dobrze” bywa odmiennie rozumiane przez biznes i przez programistów. PM musi łagodzić te napięcia i negocjować z obiema stronami.
  • Podział zadań pomiędzy Line Managerem, Project Managerem i Product Managerem teoretycznie jest dość jasny, ale mimo wszystko czasem wdeptujemy sobie na odcisk. Zwłaszcza, kiedy nie ma Project Managera i jego rola jest dzielona przez dwie pozostałe osoby.

Jakie cechy powinna mieć osoba na tym stanowisku?

  • Doskonała organizacja.
  • Umiejętność zajmowania się kilkoma wątkami naraz przy jednoczesnym dbaniu o koncentrację zespołu.
  • Umiejętność delegowania.
  • Asertywność.
  • Umiejętność brania odpowiedzialności za swoje decyzje i porażki.
  • Wrażliwość na potrzeby innych.
  • Znajomość metodologii wytwarzania oprogramowania.
  • Znajomość (lub gotowość do nauczenia się) statystyki.
  • Umiejętność (lub chęć poznania) narzędzi pozwalających na dostęp do danych na temat aplikacji, użytkowników i ich zachowania.
  • Umiejętność skutecznego streszczania problemów.

Czego się nauczyć, żeby się przekwalifikować?

Temat przekwalifikowania się był na tym blogu poruszany wielokrotnie. Technical Product Manager to rola wymagająca wykształcenia bądź doświadczenia informatycznego. Natomiast do zostania „zwykłym” Product Managerem wystarczy posiadanie (lub wyrobienie sobie) cech z powyższego punktu. Jeśli rozważasz spróbowanie sił w takiej roli, a nie masz jeszcze doświadczenia, radzę zapoznać się z następującymi tematami:

  • Nowoczesne metodologie wytwarzania oprogramowania. Najlepiej zacząć od najpopularniejszej obecnie metodologii zwinnej, czyli Scruma. Oryginalna definicja (Manifest programowania zwinnego) jest dość krótka, ale znajdziesz dziesiątki książek na ten temat.
  • Wspomniany na samym początku pakiet kursów na Courserze (nawet same wykłady).
  • Przyda się jakaś lektura na temat analizy i planowania w biznesie. Mnie polecono How to Measure Anything.
  • Warto zapoznać się z jakimś systemem zarządzania zadaniami, jak JIRA. Uzyskanie dostępu do działającej aplikacji może być trudne, ale w Internecie znajdziesz trochę instrukcji i filmików.
  • Podobnie Google Analytics, chociaż tego można się po prostu szybko nauczyć w pracy.

Czy Product Manager może programować?

Jeśli wystarczy mu czasu. Sama przez chwilę myślałam, że mi się uda… Wtedy dostałam pod opiekę kolejny zespół. Nie znaczy to, że moje zdolności programistyczne leżą odłogiem. Po pierwsze, bardzo dużo uczę się, widząc, jak pracuje zespół. Po drugie, w ramach ułatwiania sobie życia i postępowania zgodnie z zasadą „jeśli robisz dokładnie to samo po raz trzeci, pora to zautomatyzować” napisałam w pracy trochę kodu w Javie i Pythonie, który komunikuje się z API Jiry i Google Docs.

Co naprawdę robi Product Manager?

W praktyce głównym moim zadaniem na co dzień jest pilnowanie, żeby zespół potrafił skoncentrować się na tym, co ważne, i kończył rozpoczętą pracę. Niepilnowane, moje zespoły mają tendencję do prowadzenia pięciu projektów naraz (gdyż ciągle ktoś czegoś od nich potrzebuje) i niezorganizowanego łatania mniejszych i większych dziur. W efekcie żaden z projektów nie jest zrobiony do końca i jego klienci nie mogą z niego skutecznie korzystać. Pełnię także rolę tłumacza i opowiadacza dla Product Managerów innych zespołów, którzy nie zawsze rozumieją, co i dlaczego dzieje się na backendzie.

Brzmi jak wyzwanie, które masz ochotę podjąć? Do dzieła! Widzę sporo ogłoszeń firm szukających Product Managerów. Wiele z nich kieruje ogłoszenia do osób, które mają już doświadczenie w tej roli – ale nie wszystkie.

Jeśli masz dodatkowe pytania – chętnie odpowiem.

NLP w pigułce

Mam koleżankę, która jest doświadczoną programistką Javy oraz Scali. Kilkanaście razy w roku występuje na międzynarodowych konferencjach. Z opisu łatwo wydedukować, ze na co dzień nie potrzebuje mojej ekspertyzy technicznej 😊 Jednak kilka dni temu poprosiła mnie o pilne wsparcie. Napisała, że do tej pory traktowała NLP (przetwarzanie języka naturalnego, ang. natural language processing) jako „coś, z czego ludzie robią doktoraty”, a teraz musi sama poprawić kod z tej dziedziny.

Kod okazał się pluginem do Slacka, który pozwala programistom wydawać polecenia w języku naturalnym i w ten sposób zarządzać procesem budowania, testowania i wdrażania aplikacji. Chciała dopisać kilka poleceń, ale wystraszyły ją sformułowania takie jak „tokenizacja” czy „VP”, i inne, bezpośrednio związane z wykorzystywaną tam biblioteką OpenNLP. Poprosiła mnie o praktyczny kurs NLP w pigułce, opisujący kroki niezbędne do zrozumienia, o co użytkownikowi właściwie chodzi.

Oto on.

Pomijam kwestię rozpoznawania mowy, ponieważ niespecjalnie się na niej znam i nie ma ona znaczenia w przypadku pisania pluginów do slacka. Rozpoznawanie mowy to zagadnienie z dziedziny przetwarzania sygnałów, obecnie realizowane niemalże wyłącznie przy użyciu uczenia maszynowego. 

Na początku jest zdanie.

Tak przynajmniej załóżmy. W rzeczywistości zdań może być kilka – wtedy trzeba ja jakoś rozdzielić, co w zależności od języka może sprowadzić się do cięcia po kropkach, albo być super skomplikowanym zadaniem wymagającym wnikania w składnię.

Nietrywialny przykład z języka polskiego:

Poza tym nie wszystko jest zdaniem. Bezpieczniejszy jest termin wypowiedzenie (ang. utterance), który obejmuje również wszelkiego typu równoważniki i pojedyncze słowa.

Załóżmy, że nasze zdanie to „wrzuć wersję 3.1 config na produkcję”.

Zdanie trzeba podzielić na tokeny.

Token to, w przybliżeniu, słowo. W niektórych językach tokenizacja jest prosta. W polskim możemy chcieć rozdzielić np. „jasnozielony” na dwa tokeny: „jasno” i „zielony”. W angielskim zamienić „wanna” na „want to”. Po hiszpańsku „pokaż mi to” pisze się łącznie „muéstramelo”, co, żeby móc przeprowadzić jakąkolwiek analizę, musimy rozbić na trzy tokeny: „muestra” „me” „lo” (i po drodze zgubić akcent).

Normalizacja.

Czasami razem z tokenizacją przeprowadza się normalizację, czyli np. zamienia słowa „jeden”, „jedna” itp. na „1”.

Wszystko to po to, żeby uprościć sobie życie i zmniejszyć rozmiary modelu, w oparciu o który analizujemy tekst.

Dalej musimy rozpoznać byty nazwane (ang. named entities).

Byty nazwane to, w uproszczeniu, byty reprezentowane przez nazwy własne – w odróżnieniu od rzeczowników pospolitych. Ich rozpoznanie nie zawsze jest łatwe. Często zależy od kontekstu. Nierzadko w wyniku takiej analizy dostajemy kilka hipotez. Przykładowo, „house” to po angielsku „dom”, ale może to być również nazwa serialu lub nazwisko jego głównego bohatera.

Po tym kroku analizy powinniśmy wiedzieć, która część naszego wypowiedzenia to byt nazwany, i jakiego typu jest to byt (miejsce, osoba, tytuł, …).

W naszym przykładzie bytem nazwanym może być „config” (jako nazwa aplikacji) oraz „produkcja” (jako nazwa środowiska).

Ujednolicenie form wyrazów: lematyzacja lub stemming.

Etap ten ma różne znaczenie w zależności od języka. Chodzi tu o sprowadzenie różnych form tego samego słowa do wersji uznawanej za podstawową.

  • Stemming to obcięcie wszelkiego rodzaju przedrostków i przyrostków, mające na celu dotarcie do nieodmiennego „rdzenia” reprezentującego wyraz. Sam rdzeń niekoniecznie musi być poprawnym słowem. Algorytm stemmera nie musi być zależny od języka.
  • Lematyzacja to sprowadzenie słowa do jego podstawowej postaci. W przypadku czasownika będzie do bezokolicznik, w przypadku rzeczownika – mianownik liczby pojedynczej. Do wykonania tego zadania potrzebny jest słownik lub rozbudowany zestaw reguł fleksyjnych dla danego języka.

Oczywiście zadanie to jest trudniejsze dla silnie fleksyjnych języków, jak polski.

Rozpoznawanie części mowy.

W końcu powinniśmy się dowiedzieć, z jakimi częściami mowy mamy do czynienia, najlepiej również w jakich odmianach. Z reguły informację te zwraca lematyzator. Tegu typu analiza może być oparta o słownik, ale może również wykorzystywać końcówki fleksyjne (np. jeśli nieznane nam polskie słowo kończy się „zować”, można przyjąć hipotezę, że to czasownik).

Wreszcie dochodzimy do parsowania.

Parsowanie to analiza składniowa, jednak w praktyce już na tym etapie często wydobywa się także informacje semantyczną, czyli znaczenie wypowiedzenia.

Zasadniczo, do znaczenia można dobrać się na jeden z trzech sposobów:

Wyrażenia regularne.

To najprostsza, najbardziej naiwna metoda, jednak w przypadku pluginów do slacka, które mają pozwalać na wykonanie kilku prostych operacji, nierzadko okazuje się wystarczająca.

Możemy napisać:

lub coś odrobinę bardziej skomplikowanego i już dostaniemy wszystkie potrzebne nam informacje.

Gramatyki formalne

Oparte na teorii Chomskiego, gramatyki (tworzone ręcznie lub automatycznie) to zestawy reguł, które definiują, jak może wyglądać poprawne zdanie w danym języku (naturalnym, jak polski, albo sztucznym, jak C++).

Gramatyka może składać się np. z takich reguł:

Wówczas nasza grupa rzeczownikowa (NP) może mieć postać “a cat”, “the cat”, “a dog” i “the dog”.

Gramatykę można zapisać w postaci automatu skończonego.

Uczenie maszynowe

Efekt jest ostatecznie taki sam jak w przypadku gramatyk, tylko zamiast żmudnie definiowanych reguł wykorzystywane są wnioski wyciągnięte podczas trenowania systemu przy użyciu wybranej metody (np. CRF) na dużej ilości odpowiednio opisanego tekstu (na korpusie)

Reprezentacja danych semantycznych.

Ostatecznie powinniśmy otrzymać coś w rodzaju „ramy”, która często przypomina strukturę zdania. W naszym wypadku będzie to mniej więcej coś takiego:

Parsowanie płytkie i głębokie.

Głębokie parsowanie to pełne odtworzenie drzewa składniowego zdania. Parsowanie płytkie (czasami określane terminem chunking) ma na celu wydobycie istotnej informacji, bez potrzeby wyciągania wszystkich zależności składniowych pomiędzy słowami.

Analiza koreferencji.

Na początku napisałam, że punktem wyjścia jest dla nas zdanie (bądź wypowiedzenie), ale w języku naturalnym zdania mogą być ze sobą powiązane w taki sposób, że w celu zrozumienia zdania musimy cofnąć się o jedno lub więcej zdań wstecz.

W analizie koreferencji chodzi przede wszystkim o anaforę. Jeśli użytkownik wyda polecenie „wdróż to”, musimy zrozumieć, do jakiego wcześniej wspomnianego bytu się odnosi.

Przykład: OpenNLP

Istnieje trochę gotowych narzędzi i zasobów do uprawiania NLP: parsery, korpusy tekstów, treebanks (zdania rozbite na drzewa składniowe), biblioteki implementujące algorytmy uczenia maszynowego. Kod, przy którym pracowała Jessica, korzystał z javowej biblioteki OpenNLP, która oferuje trochę gotowych modeli językowych, a także umożliwia trenowanie własnych.

Co możemy od niej dostać?

Np. dla zdania “namiekko.pl is a the coolest site” otrzymamy:

Jak przełożyć to na nasze potrzeby? Musimy stworzyć jakieś mapowanie pomiędzy odnalezionymi grupami a naszą reprezentacją danych. Możemy napisać reguły takiego typu: jeśli czasownik w VP (verb phrase) to „deploy” lub „push”, to chcemy wykonać naszą akcję deploy. Argumentów dla tej akcji należy szukać w następujących elementach drzewa składniowego (…)

Zasoby

Doktorat z informatyki – warto?

Rozmawiałam ostatnio z kolegą, który zakończył edukację na etapie licencjatu. Uznał, że pozostałych przydatnych rzeczy szybciej i lepiej nauczy się w pracy. Taka decyzja wydaje mi się egzotyczna, pewnie dlatego, że za moich czasów studia trwały całe pięć lat.  (Chyba że ktoś bardzo się starał i do każdego semestru analizy matematycznej podchodził po dwa razy). Kolega i ja pracujemy w tej samej firmie. Dla niego równie zaskakujący był mój dyplom doktorski.

Kilka lat od opuszczenia progów Alma Mater, dzielę się swoimi przemyśleniami na temat tego, kiedy warto zdecydować się na ten krok.

TAK, doktorat to dobry pomysł, jeśli:

1. rozważasz pracę na uczelni
Doktorat jest warunkiem koniecznym do pracy naukowo-dydaktycznej na dobrej uczelni, więc jeśli czujesz, że to właśnie jest Twoim życiowym powołaniem… Nie ma nad czym się zastanawiać. Pamiętaj tylko, że pracownik polskiej uczelni (na świecie niekoniecznie tak jest) jest zobowiązany habilitować się w ciągu 8 lat od rozpoczęcia pracy – nie da się osiąść na laurach.

2. rozważasz pracę w R&D
R&D, czyli Research and Development (prace badawczo-rozwojowe), to trochę nadużywany termin określający pracę i zagadnienia na styku nauki i nowych technologii. Jeśli nie interesuje Cię stworzenie kolejnego sklepu internetowego albo aplikacji dla banku, możesz spróbować zatrudnić się w centrum R&D – państwowym (jak poznański PCSS) albo należącym do wielkiej korporacji. Tu doktorat się przydaje. Wiele projektów wymaga publikowania, występowania na konferencjach, poprawnego mierzenia i opisywania wyników oraz ogólnej naukowej wiarygodności.

3. znajdziesz super ciekawy zespół
Większość spraw w życiu sprowadza się do znalezienia odpowiednich ludzi. Jeśli możesz dołączyć do istniejącego, sprawnie działającego, zmieniającego status quo zespołu zajmującego się interesującą Cię dziedziną – nie ma się co wahać.

4. nie chcesz czuć presji wyników finansowych
Doktorat to nie wakacje. Od terminów nie uciekniesz: sprawdzanie prac, terminy wysłania artykułów, oceny roczne, warunki grantów. Mimo wszystko masz o wiele większą dowolność niż w jakiejkolwiek firmie. Możesz eksperymentować bez obawy o to, że wprowadzone przez Ciebie rozwiązanie wystraszy klientów i doprowadzi firmę do ruiny. W najgorszym razie napiszesz artykuł o tym, co poszło nie tak… 😉

5. chcesz przyczynić się do rozwoju nauki
Doktorat nie jest do tego konieczny, ale jeśli dobrze wybierzesz, poznasz warsztat niezbędny do „uprawiania nauki”.

NIE, nie rób tego, jeśli:

1. chcesz się rozwinąć i możliwie dużo nauczyć
Do tego nie trzeba uczelni. Zwłaszcza w informatyce, w odpowiednich warunkach, znacznie więcej zyskasz na pracy w ciekawej, nowoczesnej firmie, niż w kazamatach uczelni.

2. nie lubisz prowadzić zajęć (albo w ogóle nie lubisz ludzi)
Prowadzenie zajęć jest obowiązkowe dla pracowników naukowych na uniwersytetach. Istnieje pewna furtka – niektóre instytuty (np. należące do Polskiej Akademii Nauk, jak IPI PAN) umożliwiają pracę naukową bez dydaktyki. Na uczelni jednak nie ma ucieczki. O ile mi wiadomo, co jakiś czas wraca dyskusja o rozdzieleniu pracowników na naukowych i dydaktycznych. Ci pierwsi mieliby niedużo zajęć, ci drudzy nie musieliby przejmować się habilitacją. Póki co jednak nic się w tym temacie nie dzieje.

3. chcesz tylko przedłużyć studiowanie
Od doktoratu zabawniejszy będzie drugi kierunek.

4. zależy Ci na statusie
Doktorant na większości polskich uczelni plasuje się w połowie drogi pomiędzy pracownikiem a studentem. Pracownikiem jest wtedy, kiedy trzeba przypilnować rekrutacji albo na ostatnią chwilę napisać artykuł. Studentem, kiedy mowa o zarobkach albo przydziale miejsc w gabinetach.

5. Chcesz spełnić czyjeś marzenia
To zawsze bardzo zły pomysł.

Na co zwrócić uwagę, jeśli decydujesz się studia doktoranckie?

1. Starannie wybierz promotora
Na podstawie przygód własnych oraz moich przyjaciół wiem, że całokształt wrażeń, samopoczucia i wyników osiągniętych podczas studiów w Polsce jest w przeważającej mierze definiowany przez promotora. Ten może być wspierający, inspirujący i opiekuńczy, może też być egoistycznym tyranem rzucającym ochłapy i żerującym na wynikach podwładnych. Na większości uczelni nikt tego nie kontroluje! Jak sobie pościelisz, tak się wyśpisz.

Co zrobić, żeby nie wpakować się w tarapaty? Przejdź się na prowadzony przez potencjalnego promotora wykład. Podpytaj obecnych doktorantów o to, jak im się pracuje. Sprawdź, ilu spośród doktorantów danego profesora uzyskało tytuł i ile im to zajęło czasu.

2. Dowiedz się, jakie są możliwości wyjazdów i współpracy z innymi ośrodkami
Moim zdaniem każdy student i doktorant powinien spędzić przynajmniej semestr na innej uczelni, najlepiej za granicą, chociażby dla porównania.

3. Dowiedz się, co finansuje uczelnia
W informatyce częściej niż w innych dziedzinach artykuły publikuje się tomach pokonferencyjnych, a nie w czasopismach. Wyjazd na konferencję kosztuje: wpisowe, bilety, nocleg. Dowiedz się jakie są zasady pozyskiwania takich środków na Twojej uczelni.

4. Jeśli masz własny światopogląd, zastanów się nad tym, czy jest kompatybilny ze światopoglądem uczelni
Żebyś nie wstydził się przez zapraszanych gości albo nie zżymał przy religijnych uroczystościach.

5. Fail fast
W przypadku doktoratu warto zastosować zasadę znaną z inżynierii oprogramowania i środowiska start-upów. Jeśli coś się nie zgadza, nie działa – reaguj szybko i w razie czego równie szybko uciekaj. Nie daj się nabrać na regułę utopionych kosztów, która każe kontynuować przedsięwzięcie skazane na niepowodzenie. Studia doktoranckie to kolejne kilka lat Twojego życia – zastanów się, czy wykorzystujesz je najlepiej, jak się da. Wytrwałość nie zawsze jest cnotą.

Parę osobistych słów od autorki

Jak było u mnie? Jakie błędy popełniłam? Co zrobiłabym inaczej?

Po pierwsze,sprawdziłam, czym zajmuje się mój potencjalny promotor, ale nie jaki ma styl pracy. Ostatecznie, przez niedopasowanie na tym polu, przysporzyliśmy sobie nawzajem niemało nerwów. Po drugie, kiedy zorientowałam się, że nie najlepiej funkcjonuję w tym środowisku, było mi żal poświęconego roku… więc włożyłam w to jeszcze trzy!!!

Ostatecznie nie wyszło źle. W mojej drugiej po uczelni pracy zajmowałam się dokładnie tym samym, czym w rozprawie doktorskiej (agentami dialogowymi), w związku z czym już na starcie otrzymałam dość wysokie stanowisko i przyzwoitą pensję. Praca dydaktyczna do dzisiaj sprawie mi ogromną przyjemność (w umiarkowanej ilości). W pewnym momencie rozważałam nawet powrót na uczelnię… Ale to już zupełnie inna historia 🙂

Wyrażenia regularne w Javie – figle i psikusy

To trzeci (i na jakiś czas ostatni) z serii wpisów na temat wyrażeń regularnych w Javie, po O wyrażeniach regularnych. Podstępna różnica pomiędzy find i matches oraz Wyrażenia regularne dla nieprogramistów. Historycznie ten jest najwcześniejszy – to zaktualizowana wersja tekstu z mojego poprzedniego bloga.

Poruszam tu bardzo podstawowe kwestie, które potrafią jednak dać się we znaki. Rozwiązanie tych paru niewinnych problemików kosztowało mnie niemało czasu i nerwów. Liczę, że kiedy jakaś zbłąkana dusza znajdzie się w tej samej sytuacji, Google zaprowadzi ją prosto w moje troskliwe ramiona.

Artykuł powstał podczas mojej pracy nad narzędziem do przekształcania metadanych.

Psikus 1: znaki ucieczki w wyrażeniach wczytywanych z zewnętrznego pliku

Załóżmy, że wyrażenie (które chcemy wczytać z zewnętrznego pliku) w zwykłym kodzie Javy wygląda tak:

Linia przedstawia zakres wieków, do którego dopasuje się na przykład linia:

Proste, prawda?

Prawda – ale do czasu. Problemy pojawiły się, kiedy zaczęłam wczytywać wyrażenia regularne zapisane w zewnętrznym pliku. Wczytywałam między innymi następujący fragment:

Wszystko przestało działać. Łańcuchy znaków, które bez najmniejszych wątpliwości powinny były dopasować się do wyrażenia, przechodziły niezauważone. Po godzinie analiz niebezpiecznie zbliżałam się do stanu, w którym myślałam, że oszalał albo świat dokoła mnie. Wtedy na szczęście nadeszła pora lunchu. Opowiedziałam o problemie nad talerzem naleśników, a jeden z kolegów zadał oczywiste w sumie pytanie – czy na pewno dobrze wyeskejpowałam (przepraszam!!!) wszystkie znaki specjalne. I wtedy wreszcie nadeszło olśnienie: nie, nie zrobiłam tego dobrze. Przeeskejpowałam je.

Znaki specjalne, takie jak d, w wyrażeniu regularnym oznaczające cyfrę, należy poprzedzić tzw. symbolem ucieczki, czyli w tym wypadku backslashem (ukośnikiem wstecznym). W łańcuchach znaków w kodzie Javy konieczne jest wprowadzenie dodatkowego backslasha, gdyż musimy jeszcze odebrać specjalne znaczenie samemu backslashowi (musimy poprzedzić znak ucieczki znakiem ucieczki…). Tyle razy widziałam te dwa ukośniki w parze, że zupełnie zapomniałam o tym, że w zewnętrznym pliku należy użyć tylko jednego!

Psikus 2: flagi

To bardzo proste. Załóżmy, że wyrażenie nie ma brać pod uwagę wielkość liter. Normalnie oznaczamy to tak:

Świetnie, tylko jak przekazać tę flagę, jeśli wyrażenie jest wczytywane z zewnątrz? Wychodzi na to, że flagę, poprzedzoną znakiem zapytania, należy umieścić w nawiasie na początku wyrażenia. Ignorowanie wielkości liter (przy okazji, poznałam ostatnio nowe słowo – kasztowość) to literka i, zatem dodajemy (?i). Ostatecznie, w kodzie wyrażenie wygląda tak:

a poza kodem, z pojedynczymi ukośnikami, tak:

Psikus 3: String.replaceAll

W pewnym brzegowym przypadku mój kod, w wyniku wczytania wyrażeń regularnych z pliku, wykonywał operację, którą można w uproszczeniu zapisać tak:

Po wykonaniu się tego kodu spodziewałam się, że treść zostanie całkowicie zastąpiona, czyli wartością s będzie:

skoro * jest zachłannym kwantyfikatorem, to .* powinno dopasować się do całego napisu niezależnie od okoliczności.

Wyobraźcie sobie moje zaskoczenie (czy raczej przerażenie), gdy okazało się, że s przyjęło wartość:

Próbowałam użyć jeszcze bardziej zaborczego kwantyfikatora *+, ale efekt był ten sam. Byłabym mniej zaskoczona, gdyby .* zostało dopasowane do każdej litery w łańcuchu. Jakim cudem dopasowało się dokładnie dwa razy?

Dalsze śledztwo wykazało, że przebieg akcji jest następujący:

  1. Cały łańcuch dopasowuje się do .* i jest zamieniany na łańcuch „nowa treść”.
  2. Po dopasowaniu z oryginalnego łańcucha znaków nie zostaje nic, a raczej zostaje łańcuch "". Metoda replaceAll jeszcze raz sprawdza możliwość dopasowania i okazuje się, że "" także pasuje do .*, zatem pusty łańcuch również zostaje wymieniony.
  3. Zasadniczo można by kontynuować i w nieskończoność dodawać na końcu "nowa zawartość", jednak na szczęście (?) dana pozycja w łańcuchu znaków jest traktowana jako sprawdzona i wykonanie metody kończy się.

Pozdrawiam siostry i braci w cierpieniu.

Wyrażenia regularne dla nieprogramistów

Wyrażenia regularne wspominałam już w poprzednim wpisie. Jest to narzędzie ukochane przez część programistów i znienawidzone przez innych. Dzisiaj chciałabym podzielić się następującą refleksją: wyrażenia regularne mogą ułatwić życie nie tylko programistom. Przy ich pomocy można uprościć wiele manualnych czynności, wykonywanych na przykład w pracy biurowej.

Czym są wyrażenia regularne?

Teoria raczej nie zachęci początkujących, ale do zastosowań praktycznych wystarczy potraktować je jako wzorce, które umożliwiają przeszukiwanie tekstu i dokonywanie w nim podmian.

Pełna składnia wyrażeń regularnych została opisana na przykład w tej (angielskojęzycznej) ściądze. Poniższa tabelka opisuje kilka najbardziej podstawowych symboli:

Symbol Znaczenie Przykład
. Dowolny znak. k.t pasuje do „kot” i „kat”
+ Powtórzenie poprzedzającego znaku jeden lub więcej razy. kot+ pasuje do „kot”, „kott”, „kott” itp.
* Powtórzenie poprzedzającego znaku zero lub więcej razy. kot* pasuje do „ko”, „kot”, „kott” itp.
{m,n} Powtórzenie poprzedzającego znaku od m do n razy. ko{2,4}t pasuje do „koot”, „kooot” i „kooot”.
^ Początek linii. ^k – literka k zapisana na początku linii
$ Koniec linii k$
[abc] Znaki ze zbioru, wyszczególnione k[ao]t pasuje do „kot” i „kat”.
[a-c] Znaki ze wskazanego przedziału [2-4] to cyfra „2”, „3” lub „4”.
\b Granica słowa .+a\b to dowolne słowo kończące się na literą „a”, np. „torba”.
\d Cyfra \d\d pasuje na przykład do „23”
\s Biały znak k\st pasuje do „k t”
\S Znak niebiały k\St pasuje do „kot”, „kit”, ale nie do „k t”

Zadanie

Wyobraźmy sobie teraz następujący scenariusz z życia biura. Szef firmy, pan Cebuliński, organizuje przedświąteczną galę. W ramach oszczędności poprosił siostrzenicę – studentkę pierwszego roku informatyki – o wydobycie z bazy danych informacji o klientach, którzy terminowo opłacali faktury. Na podstawie przesłanej przez nią listy menedżerka biura, pani Nokturniak, ma przygotować listę gości. Jej zadaniem jest znalezienie stu klientów, na których firma w tym roku zarobiła najwięcej. Dodatkowo, ponieważ prezes Cebuliński rozwodzi się ze swoją żoną Anną, na liście gości nie może znaleźć się ani jedna kobieta o tym imieniu.

Lista ma następującą postać:

1. Borowiak, Kazimierz; 10000 zł; terminowo; kborowiak@example.com
2. Borowiak, Ania B.; 10011 zł; nieterminowo; abborowiak@example.com
3. Nowak, Jan, 9321 zł; terminowo; a@example.com
4. Nowak, Janina, 9322 zł; nieterminowo; ab@example.com
...
9816. Zi łkowski, Andrzej; 100 zł; terminowo; aziolkowski@example.com

Zadania pani Nokturniak prezentują się następująco:

  1. Musi usunąć z listy wszystkie Anie, Anki i Anny.
  2. Zauważyła, że litera „ó” została zamieniona na spację. Musi więc przejrzeć listę prawie 10000 nazwisk i poprawić niektóre z nich.
  3. Musi znaleźć 100 „najdroższych” klientów spośród tych, którzy płacili terminowo, aby wysłać im zaproszenia.

Pani Nokturniak zaplanowała kolejną długą noc przy komputerze. Spróbujmy chociaż trochę ułatwić jej życie.

Potrzebny nam będzie edytor tekstu, który rozumie wyrażenia regularne (albo konsola Linuksa – pokażę w kolejnym wpisie, jak ją do tego wykorzystać). Może to być np. Notepad++. Załóżmy, że pani Nokturniak otworzyła już edytor i przekleiła do niego dane.

Usunięcie Ań

Co wspólnego mają ze sobą łańcuchy znaków „Ania”, „Anka” i „Anna”? Wyglądają prawie tak samo, różnią się jedynie trzecim znakiem. Zgodnie z zamieszczoną powyżej tabelą, kropka (.) to symbol uniwersalny. Do wszystkich trzech słów zostanie dopasowany dopasowany wzorzec:

An.a

Wyrażenie regularne w edytorze Notepad++ dopasowane do słowa w tekście
Wyrażenie regularne w edytorze Notepad++ dopasowane do słowa w tekście

Tu uwaga na drobną pułapkę. Ciąg znaków „Anna” może być częścią dłuższego słowa, np. nazwiska („Annakowski”). Dla pewności zaznaczmy, że interesują nas tylko te wystąpienia, które nie są częścią dłuższego słowa. Użyję do tego symbolu granicy słowa:

\bAn.a\b

Co dalej? Wyczyśćmy wszystkie linie zawierające imię Anna. Wzorzec musi mieć postać: „nieważne co – imię Anna – nieważne co”, czyli:

.*\bAn.a\b.*

albo jeszcze lepiej dodajmy do niego znak początku i końca linii (choć domyślnie wyrażenia regularne i tak działają jedynie w ramach jednej linii, czyli efekt będzie ten sam):

^.*\bAn.a\b.*$.

Każmy edytorowi zastąpić wszystkie takie linie linią pustą.

regex2
Zamiana linii zawierającej którąś z wersji imienia „Anna” na linię pustą.

W tej chwili nasz dokument nie zawiera już danych żadnych Ann.

W podobny sposób możemy od razu usunąć wiersze reprezentujące klientów nieterminowych, których także nie mamy uwzględniać w obliczeniach.

2. Zamiana (niektórych!) spacji na „ó”

Jeśli po prostu zamienię wszystkie spacje na „ó”, efekt nie będzie zadowalający:

Muszę odszukać tylko te spacje, które znajdują się pomiędzy dwiema małymi literami.

Mogę wykorzystać w tym celu przedziały:

[a-z] [a-z]

lub bezpieczniej

[a-zA-ZąśćżńżĄŚĆŻŃŹ] [a-zząśćżńż]

lub najbezpieczniej (z uwzględnieniem wszystkich, nie tylko polskich znaków w nazwiskach, ale nie w każdym edytorze to zadziała) pełną klasę małych liter:

\p{Lu} \p{Lu}

Ok, znaleźliśmy te spacje, tylko jak je teraz zamienić? Jeśli zamienię cały znaleziony łańcuch znaków, Zi łkowski nie zamieni się w Ziółkowskiego, tylko w Zókowskiego (litery dopasowane do [az] również zostaną zamienione). Na pomoc spieszą nam tzw. capturing groups, czyli grupy przechwytujące.

Wszystko, co napiszę w nawiasie, zostanie zapamiętane jako grupa oznaczona kolejnym numerem. Do grup mogę się następnie odnieść w wyrażeniu, którym chcę zastąpić odnaleziony wzorzec. Jak to zrobić? Mogę mój wzorzec zapisać tak:

([a-zA-Z]) ([a-z])

a wyrażenie zastępujące:

\1ó\2

Wówczas każde wystąpienie spacji pomiędzy dwiema literami (przy czym druga z nich musi być mała) zostanie zastąpione literą „ó” otoczoną oryginalnymi dwiema literami (z grupy pierwszej i drugiej).

regex3

3. Odnalezienie „najdroższych” klientów

Do tego zadania można podejść na dwa różne sposoby.

Łatwiej ale z pomocą z zewnątrz

W wersji pierwszej wystarczy sprowadzić dokument do formatu CSV (skrót od Comma-Separated Values, czyli wartości rozdzielane przecinkami, ale czym w rzeczywistości najczęściej są to średniki, a nie przecinki). Format ten jest rozumiany przez większość, jeśli nie wszystkie, programów kalkulacyjnych typu Excel. Następnie można posortować wiersze według kolumny zawierającej poniesione przez klienta koszty.

W obecnej chwili nasze wiersze mają następujący format:
1. Borowiak, Kazimierz; 10000 zł; terminowo; kborowiak@example.com
Wystarczy zamienić pierwszą kropkę na średnik albo usunąć liczbę i kropkę. Na dobrą sprawę moglibyśmy nawet zostawić numer porządkowy jak jest. Nie będzie miał sensu, ale nie przeszkodzi w naszych obliczeniach.

Dla porządku (sic) usuńmy jednak numer porządkowy. Chcemy dopasować się do liczby na początku linii, po której następuje kropka oraz spacja – i całość zastąpić pustym łańcuchem znaków. Czyli:

^\d+\. albo ^\d+. (kropka to symbol uniwersalny, w szczególności dopasuje się do symbolu kropki; jeśli chcemy na pewno złapać tylko kropkę, musimy poprzedzić ją we wzorcu tzw. symbolem ucieczki „\”, który odbiera znakowi jego specjalne znaczenie).

Dokument z liniami postaci:
Borowiak, Kazimierz; 10000 zł; terminowo; kborowiak@example.com

możemy już spokojnie otworzyć w excelu jako plik CSV i tam przeprowadzić sortowanie.

Wersja dla ambitniejszych

Alternatywnie możemy przestawić kwotę na początek linii i w oparciu o nią posortować linie w pliku. Z pomocą znowu przyjdą nam grupy. Plan jest następujący: podzielić każdą linię na 3 grupy: przed kwotą, kwota i za kwotą, następnie zmienić ich kolejność z 123 n 213. Na koniec posortować (w edytorze, jeśli daje taką możliwość, albo w wierszu poleceń dowolnego systemu operacyjnego za pomocą instrukcji sort).

Spróbujmy. Linię pasującą do wzorca

^(.+)(\d+ zł; )(.+)$

zamieńmy na

\2\1\3

W efekcie mamy linie:
10000 zł; 1. Borowiak, Kazimierz; terminowo; kborowiak@example.com
Takie linie możemy już posortować wg wartości liczbowych.

Sortowanie linii według wartości liczbiwych.
Sortowanie linii według wartości liczbiwych.

Możliwy kłopot z sortowaniem

Drobny kłopot: standardowe sortowanie leksykograficzne (czyli według alfabetu) ustawi nam liczby w nieodpowiedniej kolejności, np. 10 przed 9, np.:
1
10
11
2
22
9

Żeby takie sortowanie się udało, liczby muszą być tej samej długości – dopełnione na początku zerami (09 będzie przed 10).
01
02
09
10
11
22

Prawdę mówiąc na szybko nie potrafię podać jednej zamiany, która upora się z wszystkimi przypadkami! Ale można zastosować tę samą zamianę kilka razy, aż przestaniemy widzieć jakiekolwiek zmiany. Załóżmy, że chcemy, żeby wszystkie liczby ostatecznie zajmowały 10 cyfr.

Możemy wtedy zamieniać każdą liczbę na początku linii, która ma mniej niż 10 cyfr:

^(\d{1,9} )

na tę samą liczbę (grupa przechwytująca!) poprzedzoną zerem:

0\1

Kiedy zapis liczby osiągnie długość 10 znaków, wzorzec przestanie się dopasowywać.

Na koniec wreszcie poprawnie sortujemy – i już możemy rozsyłać zaproszenia.

Trwało do trochę krócej niż całą noc, prawda?