Jak zostać dobrym programistą?

Jest chłodne grudniowe popołudnie. Siedzę w kawiarni na warszawskim Ursynowie, popijając pyszną kawę przy uspokajającej muzyce sprzyjającej kreatywności. Za oknem zmrok, na ulicy można zaobserwować pojedyncze osoby. Po drugiej stronie ulicy migające światełka przypominają, że niedługo święta i koniec roku. Koniec roku zawsze mi przypomina o tym, że przydałoby się zajrzeć do spraw, których dawno z różnych powodów nie sprawdzałem. Jedną z nich jest ten blog. Zajrzałem więc do listy tematów, które zbieram od dłuższego czasu i znalazłem temat idealny na piątkowe popołudnie. Dziś postanowiłem napisać mało techniczny, raczej “lekki” i krótki tekst. Piszę ten wpis bardziej z myślą o programistach, niemniej jednak myślę, że myśli tutaj zawarte są dość uniwersalne i mogą mieć zastosowanie również poza branżą IT.

Być może zastanawiasz się czasem czy jesteś dobrym specjalistą lub dobrą specjalistką. Być może napisałeś/-aś wiele aplikacji w swojej karierze. Czy możesz powiedzieć, że jakość wytworzonego oprogramowania była bardzo dobra? Uważasz, że Twoim współpracownikom dobrze się z Tobą pracuje? Wdrażasz własne inicjatywy? Na jakim poziomie teraz jesteś? Jak w ogóle określić poziom, na jakim się znajdujesz? Czy udało Ci się określić swoje słabe strony i czy pracujesz nad nimi? Jak zostać dobrym programistą? Co robić, aby być w tym jeszcze lepszym?

Ja zadaje sobie takie pytania dość często. Przeważnie wydaje mi się, że nie mogę nazwać się dobrym programistą. Wynika to z mojego bardzo krytycznego myślenia na temat swojego rozwoju. Mój wewnętrzny krytyk, zawsze mówi “Ciśnij mordo, musisz poznać wszystkie technologie. Do tego warto byłoby znać kilka języków obcych, umieć się ładnie wysławiać, dbać o swoją prezencję i przy okazji o zdrowie i wiele innych rzeczy, na które niestety zaczyna mi już brakować czasu.”. Mimo to uważam, że udało mi się wybrać dobrą ścieżkę kariery i konsekwentnie nią podążać.

Moje sposoby na to jak zostać dobrym programistą

Być może kolejny raz zabrzmię jak pierwszy lepszy internetowy coach rozwoju osobistego, ale jak to mawia klasyk “Bez rozwoju jesteś w d… (tam, gdzie plecy tracą swą szlachetną nazwę)”. Oczywiście nie samym kodem człowiek żyje i czasy, gdy programiści siedzieli całe dnie tylko w piwnicy, bez konieczności rozmawiania z kimkolwiek, już się skończyły. Dziś prawdziwy specjalista w branży IT nie tylko pisze kod, ale również musi prowadzić dość dużo interakcji z innymi ludźmi, udzielając rad, zbierając wymagania czy tłumacząc swoje pomysły nie tylko programistom.

Poniżej zamieszczam kilka zasad, którymi ja kieruję się w życiu oraz które pozwoliły mi zajść w mojej karierze dość daleko w szybki sposób przy stosunkowo niewielkim nakładzie pracy.

Zasada 5W

Co według Ciebie odróżnia juniora od regulara (mida)? Co odróżnia programistę, który po pewnym czasie staje się dla zespołu ciężarem zamiast być wsparciem? Dlaczego niektórzy stają się wybitnymi programistami, a niektórzy po prostu zostają na przeciętnym lub gorszym poziomie? Wiele zależy od samych chęci i podejścia do życia. Uważam jednak, że jedną z ważniejszych rzeczy we własnym rozwoju jest zadawanie dużej ilości odpowiednich pytań. Odpowiedzi na pytania może udzielać ktoś z większym stażem, ale można też samemu szukać informacji w internecie. To będzie nawet lepsza droga. Najlepszymi pytaniami będą te rozpoczynające się od słowa “dlaczego”.

Zasada 5W

Nazwa zasady 5W wzięła się od 5xWhy. Mówi ona o tym, że gdy chcemy zrozumieć dogłębnie jakiś temat, to zadając 5 razy pytanie “Dlaczego…” po każdej uzyskanej odpowiedzi dochodzimy do sedna sprawy. Wyobraź sobie, że drążysz w ten sposób każdy nurtujący się temat związany z pracą. Spróbuj! Według mnie to jedna z najszybszych dróg do szybkiego awansu na wyższy poziom.

Naucz sie rozmawiac z biznesem

Kolejny punkt ma dość niefortunną nazwę, bo co to właściwie oznacza “rozmawiać z biznesem”. Wyjaśnię, że my programiści jako rozmowę z biznesem określamy rozmowę z ludźmi mającymi wiedzę w zakresie tego jak działa dany biznes. Po angielsku tych ludzi można nazwać stakeholders a po niemiecku Fachbereich co w obu przypadkach jest lepiej nazwane niż nasz polski odpowiednik.

Jak zatem nauczyć się rozmawiać z takimi ludźmi, którzy nie zrozumieją programistycznego żargonu. Otóż odpowiedź brzmi może trochę śmiesznie i niepoważnie, ale jest prosta. Naucz się tłumaczyć zagadnienia IT w taki sposób jakbyś tłumaczył to małemu dziecku, albo jeszcze lepiej swojej babci. Swoją drogą spróbuj wytłumaczyć swojej babci, jak działa SSL, to będzie bardzo dobre ćwiczenie. Lubię czasem zadawać to pytanie, gdy kogoś przepytuję. Odpowiedź nie tylko pozwoli mi się dowiedzieć czy ktoś rozumie SSL, ale również czy potrafi w prostych słowach, lub używając różnych analogii wytłumaczyć skomplikowane zagadnienie w prosty sposób. Gdy ktoś ma taką umiejętność, to będzie nie tylko cenionym konsultantem, ale również dobrym mentorem. Będąc przy mentoringu możemy przejść do kolejnego punktu…

Nauczanie innych

Uczenie innych jest świetnym sposobem na samorozwój i świetnym sposobem, aby zostać dobrym programistą. Ucząc innych, bardzo dużo uczysz się sam/sama. Często zdarza się, że osoby z mniejszym doświadczeniem zadają pytania na tematy, które wydają się oczywiste i nigdy byśmy na nie nie wpadli. Pozwala to często zrozumieć powód powstawania wielu błędów pojawiających się w kodzie, a co za tym idzie, pomaga ich unikać. Robienie przeglądów kodu innych osobom również zmusza Cię do pogłębienia swojej wiedzy. Nauczanie ludzi rozwija w nas umiejętność klarownego przekazywania wiedzy oraz lepszego zrozumienia swoich rozmówców.

Szukaj lepszych rozwiązań

Czy wiesz, dlaczego tak zwana “świeża krew” jest tak bardzo ceniona w projektach? Często bardzo dobrze ułożone i ustrukturyzowane projekty mają to do siebie, że nie są ulepszane i aktualizowane. Wszystko jest utrzymywane na tym samym dobrym poziomie, ale nic ponadto. Czasem projekty nie są prowadzone nawet na akceptowalnym poziomie i zespołom to nie przeszkadza. To bardzo często występująca sytuacja. Wedle zasady “Jak działa to nie ruszaj” wiele aplikacji nie nadąża za trendami. Wersje bibliotek, metodologie, architektura i sposoby rozwiązywania problemów zostają takie same od początku do końca życia aplikacji, bo po prostu tak jest wygodniej.

Szukaj lepszych rozwiązań

Jeśli szukasz przepisu jak zostać dobrym programistą to — bez względu na to czy jesteś nowym członkiem zespołu, czy nie — bądź tą “świeżą krwią”, która zawsze poszukuje lepszych i nowszych rozwiązań. W poszukiwaniu informacji o technologiach polecam stronę thoughtworks.com oraz ich technology radar.

Zacznij prowadzić rozmowy kwalifikacyjne

Jeśli to tylko możliwe, postaraj się o dodatkowe zajęcie, jakim będzie prowadzenie technicznych rozmów kwalifikacyjnych. Będzie to dla Ciebie nie tylko motywacja do tego, aby samemu poszukiwać wiedzy i się rozwijać. Prowadzenie rozmów kwalifikacyjnych uczy nas wielu wartościowych miękkich umiejętności. Poza samym prowadzeniem rozmów, uczymy się udzielania konstruktywnego feedbacku oraz oceny umiejętności.

Mnie prowadzenie rozmów dodaje sporo pewności siebie. Często nie otrzymuję odpowiedzi, gdy pytam o rzeczy, które wydają mi się oczywiste i wydawały mi się oczywiste, gdy byłem na poziomie kandydata, z którym rozmawiam. Uświadamiam sobie wtedy, że faktycznie w którymś momencie mojej kariery włączyłem wyższy bieg i trochę odjechałem do przodu. Nie myślę już o tym jak zostać dobrym programistą a jedynie o tym jak poprawić swoją sytuację lub jak zostać architektem z prawdziwego zdarzenia. Mój biedny wewnętrzny krytyk wpada wtedy w depresję i długo się do mnie nie odzywa.

Zapisz się na newsletter, aby otrzymywać informacje o nowych artykułach oraz inne dodatki.

Podsumowanie

Jako podsumowanie chciałbym tylko zachęcić wszystkich do rozwoju nie tylko swoich umiejętności programistycznych. Miękkie umiejętności są nie mniej ważne niż te techniczne i powinny być tak samo regularnie pielęgnowane. Do wymienionych wyżej punktów dorzuciłbym jeszcze, dzielenie się wiedzą, w postaci bloga lub wpisów na branżowych portalach oraz rozwój umiejętności publicznego przemawiania. Celowo nie napisałem nic o przemawianiu publicznym, mimo iż uważam to za jedną w najważniejszych życiowych umiejętności. Po prostu nie chcę się wymądrzać na tematy, o których mam tylko niewielką wiedzę teoretyczną. Myślę, że nagram kiedyś film o tym jak zostać dobrym programistą, który będzie rozwinięciem i kontynuacją tego artykułu.

Jeśli udało Ci się dotrzeć do tego miejsca, to dziękuję Ci za przeczytanie tego tekstu i życzę wytrwałości w samorozwoju i dążeniu do zamierzonych celów.

Zapraszam do polubienia profilu na facebooku oraz obserwowania na instagramie. Zapraszam również do grupy Wsparcie w programowaniu i zadawania pytań oraz do kontaku.

The English version of this post is available on my other blog EagerToIT.com

Mikroserwisy – Czy na pewno ich potrzebujesz?

Mikroserwisy w ostatnich kilku latach są postrzegane zarówno przez developerów, jak i organizacje jako bardzo sexy podejście do tworzenia aplikacji. Dlaczego tak się dzieje? Mikrousługi są lekkie, stworzone przeważnie w nowoczesnych technologiach, szybkie oraz łatwe w utrzymaniu. Ale co stoi z drugiej strony? Czy są ciemne strony tego podejścia?  Książka o ekonomii „Co widać, a czego nie widać”, Frederika Bastiata, uświadomiła mi, że w IT również trzeba zaglądać w te zacienione miejsca, aby podejmować świadome decyzje.

Architektura mikroserwisowa bazuje na koncepcji wydzielania małych niezależnych części kodu z większej aplikacji. W systemach monolitycznych często takie wydzielenie kodu sprowadzane było do stworzenia nowego pakietu lub modułu w aplikacji. Taki moduł finalnie uruchamiany był razem z innymi modułami na serwerze aplikacyjnym oraz traktowany jak jedna aplikacja. Mikroserwisy, w przeciwieństwie do tego podejścia, uruchamiane są niezależnie. Każdy moduł aplikacji uruchomiony jest jako osobna aplikacja, często z własną bazą danych, na własnym serwerze. Taka architektura dostarcza nam ogromną ilość zalet, ale może również stać się dla naszego projektu ogromnym obciążeniem. Jaka zatem jest odpowiedź na pytanie zadane w tytule? Otóż… to zależy. W tym tekście opiszę, z czym wiąże się tworzenie aplikacji w architekturze mikroserwisowej.

Architektura mikroserwisowa

Zerknijmy na te mikroserwisy

Gdy chcemy stworzyć aplikację w takiej architekturze, będziemy potrzebować kilku dodatkowych narzędzi. To one uczynią naszą infrastrukturę otwartą na skalowanie. 

  • Na początek potrzebujemy service discovery. Jest to wzorzec, który mówi, o potrzebie posiadania jednego miejsca, w którym każda mikroaplikacja będzie mogła się zarejestrować, aby inne aplikacje wiedziały, pod jakim adresem się znajduje. W rozwiązaniu tego zagadnienia pomogą nam narzędzia takie jak Kubernetes, Consul, Eureka lub inne dedykowane API dostępne w rozwiązaniach chmurowych.
  • Aby móc wygodnie zarządzać konfiguracją poszczególnych usług, możemy wdrożyć config serwer. Frameworki takie jak Spring wspierają ten mechanizm. Wystarczy stworzyć nową usługę i przy pomocy odpowiedniego pliku konfiguracyjnego sprawić, że każdy mikroserwis będzie pobierał swoje konfiguracje z jednego miejsca. Pliki konfiguracyjne mogą być przechowywane jako fizyczne pliki na serwerze lub możemy skorzystać z systemu kontroli wersji GIT. 
  • API gateway to kolejny element naszej mikrousługowej układanki. Aplikację budujemy po to, aby ktoś mógł z się z nią skomunikować. Aby to zrobić, dobrą praktyką jest stworzenie jednego punktu wejścia do systemu, który przekieruje ruch w odpowiednie miejsce. API gateway zatem będzie pełnił nie tylko rolę proxy, ale może się również dobrze sprawdzić jako load-balancer.
  • W większości przypadków będziemy potrzebować systemu, który odpowiada za uwierzytelnienie ruchu przechodzącego przez nasz system. 
  • Dodatkowe sprawy, o które trzeba zadbać w takiej architekturze to: odpowiednie zunifikowane logowanie błędów, śledzenie wiadomości przepływających przez system oraz monitoring aplikacji.
Ja pokazujacy na swoją głowę

Jak widać, zanim zaczniemy prawdziwy happy-coding aplikacji, musimy sporo nagimnastykować się z konfiguracją infrastruktury. Dodatkowo, aby wdrożyć taki system na serwerze i móc go łatwo utrzymywać, potrzebujemy narzędzia do orkiestracji takiego jak np. Kubernetes, którego również trzeba dostosować do naszych potrzeb.

Zalety

  • Możliwość wdrażania części aplikacji. Architektura mikroserwisowa, dzięki posiadaniu niezależnie działających usług, pozwala na wdrażanie części funkcjonalności bez potrzeby zatrzymywania systemu. Dzięki temu unikamy przestojów aplikacji. W najgorszym przypadku tylko niektóre funkcje systemu przestaną na chwilę działać. Dodatkowo downtime systemu będzie niższy niż w przypadku monolitów, ponieważ nie uruchamiamy na raz całego kodu aplikacji, a jedynie małą jego część.
  • Możliwość zwiększenia wydajności. Oprócz tego, że każdą usługę możemy uruchomić na osobnych maszynach, co już jest dużym usprawnieniem, mamy możliwość skalowania części aplikacji. Gdy któryś z serwerów ma dużo większe obciążenie niż pozostałe, możemy tę samą część uruchomić więcej niż jeden raz. Równomierne obciążenie serwerów zapewni wdrożony load-balancer.
  • Łatwość zrozumienia. Dzięki zwiększonej granulacji w systemie wdrożenie nowych programistów do pracy z mikroserwisami jest dużo prostsze niż w przypadku monolitu.
  • Większa izolacja błędów. Błąd w jednym mikroserwisie przeważnie nie wpływa na działanie pozostałych serwisów.
  • Możliwość zastosowania różnych technologii. Zespoły piszące aplikację mogą tworzyć każdą mikrousługę w innym języku. Ważne jest, aby wszystkie mikroserwisy komunikowały się ze sobą w ten sam sposób.

Wady

  • Mikroserwisy wymagają dokładnego przemyślenia i starannego zaprojektowania. Podczas projektowania należy dobrze przemyśleć, jak będzie odbywać się komunikacja w systemie. Ważne, aby unikać sytuacji, gdy funkcjonalność wymagająca transakcji wykonuje się sekwencyjnie w kilku serwisach. Nie jest to proste zadanie. Gdy okaże się, że musimy zbudować taki mechanizm, trzeba dobudować dodatkowe mechanizmy takie jak Two-Phase-Commit lub implementacja wzorca Saga. To dodatkowo komplikuje implementacje.
  • Więcej usług oznacza więcej zasobów potrzebnych, aby uruchomić aplikację, a co za tym idzie, większe koszta.
  • Bardziej skomplikowana architektura w porównaniu do monolitu. Obecność wymienionych wcześniej dodatkowych narzędzi oraz mechanizmów czyni architekturę mikroserwisów bardziej skomplikowaną.
  • Autoryzacja i uwierzytelnienie w rozproszonych systemach. To zagadnienie jest całkiem proste, dopóki nasz kod i wszystkie żądania mamy zamknięte w jednej fizycznej aplikacji. W przypadku systemów rozproszonych musimy zadbać o dużo mocniejsze zabezpieczenia, ponieważ usługi będą przesyłały żądania między sobą. Dodatkowo każda usługa musi „wiedzieć”, kto wykonuje zapytanie i, czy w ogóle może je wykonać.
  • Utrudnione śledzenie błędów. Jako że każdy mikroserwis generuje swój zestaw logów, to w przypadku problemów trzeba przejrzeć więcej plików i porównać z logami z innych serwisów. Aby ten proces ułatwić, stosujemy tracing, ale nadal proces przeglądania logów bywa mozolny.
  • Globalne testowanie end-to-end jest trudne. W przypadku monolitu po prostu uruchamiamy aplikację i uruchamiamy testy. W przypadku mikroserwisów wymagane jest odpowiednie uruchomienie wielu mniejszych aplikacji, co może sprawiać problemy z ich orkiestracją.
  • Cost per line przy małym systemie jest duży. Na początku trzeba dużo rzeczy skonfigurować i napisać sporo kodu boilerplate, zanim wystartujemy z developmentem. W monolicie koszt linii kodu jest mały na początku, w miarę rozrastania się systemu koszt się zwiększą, linie kosztów przecinają się bardzo daleko.
  • Pojawiają się problemy typu shared libraries vs. copy-paste. Z jednej strony zasada DRY (Don’t repeat yourself) mówi o wydzielaniu części wspólnych, lecz doświadczenia programistów często mówią o unikaniu współdzielonych bibliotek w mikrousługach na rzecz starego dobrego copy-paste.

Zapisz się na newsletter, aby otrzymywać informacje o nowych artykułach oraz inne dodatki.

Jeśli nie mikroserwisy, to co?

Codementor z zarówką nad głową.
  • Sharding bazy danych. W przypadku gdy system staje się mniej wydajny i szybkość zapisu w dużej mierze jest podyktowana szybkością operacji na bazie danych, to być może wystarczy skorzystać ze skalowania horyzontalnego Twojego źródła danych.
  • Skupienie się na wydajnych algorytmach – uświadamianie zespołów developerskich na temat złożoności obliczeniowej. W projektach IT często bywa tak, że odpowiedzialność za jakość jest nieco rozmyta. Programiści nie czują się w 100% właścicielami swojego kodu i po prostu budują rozwiązania wystarczające, nie skupiając się na optymalizacji algorytmów. Ciągłe uświadamianie członków zespołu oraz budzenie w nich poczucia odpowiedzialności za napisany kod może przyczynić się do znacznego zwiększenia nie tylko jakości kodu, ale i wydajności.
  • Podejście hybrydowe. Być może zamiast budowania całej aplikacji w architekturze mikroserwisowej wystarczy wydzielić z monolitu tylko niektóre kawałki aplikacji, które wymagają szybszego działania. 

Podsumowanie

Jak widać, mikroserwisy mogą wnieść wiele dobrego, ale również mogą stać się sporym obciążeniem. Jeśli nie masz zamiaru przetwarzać ogromnej ilości danych w projekcie albo zespół developerski składa się z kilku programistów, prawdopodobnie nie potrzebujesz wdrażać u siebie tak złożonych rozwiązań.

Bardzo dobrym podejściem może być zaczynanie od architektury monolitycznej. W miarę rozwoju systemu wydzielenie niektórych części systemu wyniknie naturalnie i raczej wydzielimy je słusznie i w odpowiedni sposób. Zaczynając nowy projekt, nie jesteśmy pewni, czy wydzielanie niektórych usług jest konieczne. Mikroserwisy w tym momencie mogą okazać się nie najlepszym wyborem. Aby zapewnić dobrą organizację kodu w monolicie i ułatwić późniejsze wydzielanie odrębnych usług, warto skorzystać z architektury heksagonalnej.

Przejście na architekturę mikroserwisową w istniejącej aplikacji również należy dokładnie przemyśleć. Istnieje szereg usprawnień, które powinniśmy rozważyć przed wdrożeniem tak skomplikowanej architektury.

Podsumowując, jeśli budujesz rozwiązanie dla małej firmy, start-upu lub system nie będzie ogromy, to raczej mikroserwisy nie będą dobrym rozwiązaniem. Dobrze zaplanowany modularny monolit na początek to bardzo trafny wybór.

Codementor z pieniedzmi klienta.

Ważne, aby w pierwszej kolejności dokładnie przeanalizować wymagania, biorąc pod rozważanie wiele czynników. Gdy w grę wchodzą pieniądze klienta, należy dobrze przemyśleć wszystkie aspekty, aby zaproponować rozwiązanie idealnie dopasowane do budżetu i potrzeb. Na etapie projektowania warto skorzystać ze świeżego spojrzenia architektów z innych zespołów, to pozwala na zaprojektowanie systemu w taki sposób, aby nie tylko był dobry tu i teraz, ale również służył klientowi w przyszłości z uwzględnieniem minimalnych kosztów.

Każdy z nas uwielbia nowe i ciekawe technologie, ale wynik analizy nie zawsze mówi, że to, co jest trendy, jest odpowiednim rozwiązaniem w danym przypadku. Jeśli nie chcemy być zespołem przytłoczonym przez wielką i ciężką machinę mikroserwisów, to warto na początek rozważyć inne lżejsze rozwiązania.

Jeśli artykuł Ci się podobał, zapraszam do polubienia profilu na facebooku oraz obserwowania na instagramie. Zapraszam również do grupy Wsparcie w programowaniu i do kontaku.

Jak na kilka godzin zablokowałem StackOverflow w całej firmie?

Jak na kilka godzin zablokowałem StackOverflow w całej firmie? Czyli o tym jak nieumiejętnie napisać web crawler.

StackOverflow to platforma, która z niejednego przeciętnego programisty zrobiła eksperta. Chyba ciężko w tych czasach wyobrazić sobie pracę programisty bez tego narzędzia. Kiedyś przypadkowo udało mi się na kilka godzin zablokować możliwość korzystania z tej strony w całej firmie. Zaraz po tym incydencie dało się zauważyć wzmożony ruch przy ekspresie do kawy i luźne rozmowy na open space. Niektórzy nawet wysnuli ciekawe wnioski, że chyba za dużo pracujemy, skoro zablokowali nam StackOverflow. Ale właściwie, o co chodzi? Co trzeba zrobić, żeby dostęp do takiej witryny został zablokowany?

Jak to się stało?

Zacznę od początku. Winny całego zmieszania jest Michał Sadowski i jego narzędzie do monitorowania internetu – Brand24. No dobra może Michał nie jest winny, ale na pewno mnie zainspirował. Otóż w drodze do Warszawy tłumaczyłem mojej kuzynce, jak może działać Brand24, i że sama koncepcja bez wnikania w szczegóły jest dość prosta. Otóż jest sobie program, który przegląda stronę internetową w poszukiwaniu słów kluczowych oraz linków. Po przejrzeniu danej strony odwiedza kolejne strony, używając wcześniej znalezionych linków, i potem jeszcze kolejne itd. Tak działa Google, DuckDuckGo i wiele innych narzędzi do indeksowania treści w internecie.

Ja "Czemu mój crawler jest zły?"

No dobra, ale co w końcu z tą blokadą dostępu. Otóż zaciekawiony tematem postanowiłem napisać swój własny bardzo prosty crawler. Po mniej więcej trzech godzinach pracy był gotowy. Zadaniem aplikacji było wyszukiwanie frazy “Michał Cholewiński” w całym internecie i wysyłanie na maila raportu gdzie udało się znaleźć moje nazwisko. Co prawda większość wyników należała do prezentera z telewizji o takim samym imieniu i nazwisku, ale udało się też znaleźć wzmianki o mnie. Kolejnego dnia w czasie pracy wpadłem na pomysł przyspieszenia aplikacji, więc od razu postanowiłem go wypróbować. Uruchomiłem program i wróciłem do służbowych zajęć. Przyznam że gdy pierwszy raz tego dnia probowałem sprawdzić coś na StackOverflow i nie udało mi się tego zrobić, nie rozumiałem, co się wydarzyło. Po prostu nie połączyłem kropek.

Można by się zastanowić, czemu poważna firma buduje takie rozwiązanie miesiącami, a ja w trzy godziny zrobiłem swój prywatny monitoring internetu. Jedyna różnica była taka, że moją aplikację blokowała co druga strona a Brand24 działa non-stop. No w sumie to nie jedyna różnica. Problem był o wiele większy. Po pierwsze pisząc tego typu aplikacje, trzeba to robić zgodnie ze sztuką. Istnieje wiele zasad, które mówią, jak wygląda poprawne zachowanie robota. Można ich przestrzegać albo po prostu pozwolić mu naparzać po internecie jakby jutra nie było. Ja nieświadomy tych zasad poszedłem drugą drogą.

Od strony technicznej

Aplikację napisałem w Javie z użyciem biblioteki JSOUP. Działanie polega na pobraniu jednej strony, sprawdzeniu jej zawartości i odwiedzeniu wszystkich nieodwiedzonych linków z tej strony. Czynność wykonywałem dosłownie w nieskończoność. Co kilka tysięcy odwiedzonych stron aplikacja wysyłała do mnie maila z raportem.

Dzięki dobremu wsparciu wielowątkowości mogłem zwiększyć szybkość przeglądania stron. Stworzyłem 20 wątków, z których każdy w ciągu jednej sekundy odpytywał kilka razy jedną witrynę. Jako jedną ze stron, od których zaczynałem poszukiwania, wybrałem StackOverflow. Jak łatwo się domyślić 20 wątków razy około 5 pobrań strony oraz dodatkowych zasobów daje dość nietypowy wynik jak na ruch zwykłego zjadacza chleba. Witryny takie jak StackOverflow też świetnie zdają sobie sprawę, że takie zachowanie na łączach to nic normalnego i po prostu blokują adresy IP takich delikwentów. Pech chciał, że tym razem zablokowali IP naszej firmy. Kod aplikacji można znaleźć tutaj.

Czego nie wiedziałem, pisząc własny crawler?

Ja wystraszony

Zabierając się za tę aplikację, nie wiedziałem wielu rzeczy o działaniu tego rodzaju systemów. Przede wszystkim nie wiedziałem, że aplikacja musi udawać człowieka. Twórcy aplikacji internetowych zabezpieczają się przed nadmiernym ruchem, który mogą generować boty. W tym celu budują rozwiązania, które mierzą ilość zapytań pochodzących z jednego adresu IP, osadzają na stronach ukryte linki, których przeciętny użytkownik nie zobaczy i nie kliknie, a robot raczej to zrobi, itp.

Drugą rzeczą, o której nie wiedziałem to fakt, że nie wszystkie strony możemy tak po prostu przeglądać. Wyobraźmy sobie, że piszemy crawler, który przegląda internetowy słownik języka angielskiego. Czy jesteśmy w stanie pobrać większość słów wraz z definicjami? Oczywiście, że tak. Czy to uczciwe? Oczywiście, że nie. Niektóre strony mają wyraźny zapis w regulaminie, że nie można ich scrapeować. Musimy na to uważać.

Zapisz się na newsletter, aby otrzymywać informacje o nowych artykułach oraz inne dodatki.

Jak ma działać crawler, aby nie szkodzić?

Istnieje kilka zasad, które musimy wdrożyć w takiej aplikacji, aby nie była blokowana oraz aby nie szkodziła stronom internetowym. Tak jak napisałem wyżej, aplikacja musi udawać człowieka. Wystarczy spróbować napisać swój crawler w taki sposób, aby symulował wizyty wielu użytkowników o różnych zachowaniach.

  1. Łączenie się do strony internetowej z różnych adresów IP. Gdy podejrzane żądania są wysyłane tylko z jednego adresu IP, to mechanizmy obronne przeglądanej strony mogą pomyśleć, że to jakiś atak. W przypadku gdy podobne żądania pochodzą z różnych IP, ruch przestaje być aż tak podejrzany.
  2. Klikanie po stronie w losowych odstępach czasu. Człowiek nigdy nie klika na stronie w równych odstępach czasu, czasem są to szybsze przejścia między podstronami a czasem wolniejsze.
  3. Symulowanie ruchu myszy. Użytkownicy przeważnie do przeglądania stron używają myszy, której kursor porusza się po ekranie w dość nieprzewidywalny sposób.
  4. Symulowanie przewijania strony. Praktycznie na każdej stronie internetowej coś zescrollować i jest to nieodłączny element zachowania użytkownika każdej strony internetowej.
  5. Respektowanie linków no-index oraz plików robots.txt. Strony internetowe często jawnie “mówią” nam co możemy, a czego nie możemy przeglądać. Powinniśmy to respektować.

Co z Captcha?

Captcha to rodzaj zabezpieczenia na stronach internetowych mających zapewnić, że formularze są wypełniane przez człowieka. Chodzi o taki widget, który wymaga od Ciebie przepisania jakiegoś zniekształconego tekstu albo wskazania podobnych obrazków.

Czy da się złamać captcha? Co jakiś czas powstają nowe zabezpieczenian, aby captcha była jeszcze bardziej odporna. Dzisiejsza technologie pozwala zarówno na tworzenie skomplikowanych zabezpieczeń jak i również na ich łamanie. W tym artykule można poczytać więcej na ten temat.

Podsumowanie

Po co napisałem ten artykuł? Uważam, że historia jest całkiem ciekawa i pokazuje, że nie wszystko, co jest publicznie dostępne w internecie, należy do nas i że nie możemy robić tam wszystkiego, co nam się podoba.

Jeśli w przyszłości, będziesz chciał napisać podobną aplikację to ważne, abyś wykonanie poprzedził sumienną analizą, aby ograniczyć sobie problemów. Zanim rozpoczniesz pracę, możesz spytać innych developerów lub swojego mentora o poradę odnośnie implementacji.

Zastanawiasz się być może, do czego w ogóle można potrzebować takiego mechanizmu. Istnieje wiele aplikacji poza Google, które indeksują strony. Jednym z bardziej popularnych przypadków użycia w ostatnim czasie jest skanowanie serwisów ogłoszeniowych z nieruchomościami albo z ofertami pracy.

Jeśli artykuł Ci się podobał, zapraszam do polubienia profilu na facebooku oraz obserwowania na instagramie. Zapraszam również do grupy Wsparcie w programowaniu i do kontaku.

Czy do nauki programowania potrzebny jest mentor?

Czy mentor jest Ci potrzebny, aby nauczyć się programować? Mógłbym napisać “TAK” i zakończyć ten post, ale myślę, że powinienem nieco więcej o tym opowiedzieć. Przeważanie najlepszą odpowiedzią na tego typu pytania jest “To zależy”. To czy potrzebujesz mentora i czy będziesz korzystał właściwie z jego wiedzy, zależy od kilku czynników i samego podejścia do nauki.

Mentor vs. Coach

Na początku warto wspomnieć, kim jest mentor. Ważne, żeby nie pomylić mentoringu z coachingiem, a zwłaszcza z coachingiem znanym z internetu typu “Do it! Teraz!“, “Możesz wszystko jeśli tylko zechcesz!” czy “Kto Ci ukradł marzenia?“.

Mentor z postawą pytającą

Czy mentor jest tym samym co coach? No nie. Mentor to osoba, która dobrze zna wszystkie zagadnienia, w których doradza, bazując na swoim doświadczeniu. Mentor musi mieć zdecydowanie większe doświadczenie i wiedzę niż Mentee (podopieczny mentora). Coach natomiast nie musi mieć większego doświadczenia, nawet nie musi znać się dobrze na tym, co Ty robisz. Rolą Coacha jest stawianie odpowiednich pytań w taki sposób, abyś Ty sam doszedł do rozwiązania.

Mentoring w programowaniu

Na czym polega mentoring w programowaniu? Na Mentora-Programistę dobrze wybierać sobie kogoś, kto ma już spore doświadczenie w programowaniu. Najlepiej, aby było to doświadczenie w więcej niż jednym projekcie i w więcej niż jednej firmie. Dzięki doświadczeniom zdobytym w różnych projektach oraz pracy z różnymi programistami taka osoba jest w stanie łatwiej wskazać, co wychodziło dobrze w różnych projektach, a co po prostu było słabe.

Należy pamiętać również, że nauka programowania to głównie praca samodzielna. To oznacza, że w pierwszej kolejności rozwiązań swoich problemów szukasz sam/sama a dopiero później wracasz z konkretnymi pytaniami do mentora.

Nauka podstaw programowania

Zdecydowane NIE. Mentor oparty o kulę z napisem No.

Moim zdaniem do nauki podstaw programowania nie potrzebujesz niczego więcej niż internetu i dużych pokładów cierpliwości. W internecie znajdziesz mnóstwo przykładów jak zrobić podstawowe aplikacje typu kalkulator, liczenie silni czy liczenie ciągu Fibonacciego. Na podstawie tak prostych programów oraz wiedzy z pierwszego lepszego darmowego kursu, jesteś w stanie zrozumieć podstawy i przejść krok dalej.

Kontynuacja nauki

Nie ważne czy jesteś po bootcampie, jakichś praktykach czy nauczyłeś się podstaw sam. Kontynuacja Twojej nauki, czyli etap kiedy zaczniesz budować coś więcej niż aplikacje do szuflady, powinna być asekurowana przez mentora. Chodzi o kogoś, kto, bazując na swoim doświadczeniu, podpowie Ci jak poprawnie zbudować projekt, jakich narzędzi użyć oraz czego unikać. Uczenie się na błędach innych ludzi na tym etapie zaoszczędzi Ci wiele godzin nauki.

Mentor siedzący na książkach

Na tym etapie będziesz czytać dużo książek z branży IT, zadaniem mentora jest między innymi wskazanie tych właściwych pozycji. W tym momencie nie potrzebujesz jeszcze jakiejś super mądrej głowy po MIT, która będzie Ci opowiadać o szczegółach architektury czy działaniu pamięci w Javie. Wystarczy, że jako mentora wybierzesz sobie kogoś, kto już pracuje jako programista i przeszedł tę drogę, którą Ty właśnie idziesz. Możesz też dołączyć do różnych grup na facebooku, gdzie życzliwi programiści chętnie dzielą się wiedzą.

Budowanie zaawansowanych rozwiązań

Rozmowa przez telefon

W tym momencie potrzebujesz już osoby, która faktycznie napisała sporo kodu. Na tym etapie szukamy osoby raczej na poziomie seniora i wyżej. Patrząc na poziom doświadczenia, oczekiwałbym, że osoba pracowała w kilku projektach z różnych branż i miała okazję kilka razy budować projekt od zera. Mówiąc o budowaniu projektu od zera mam na myśli wszystkie warstwy od Frontendu przez Backend po konfigurację serwera.

Na początku, budując bardziej zaawansowane rozwiązanie, będziesz po prostu potrzebował kogoś, do kogo możesz zadzwonić lub napisać i wyjaśnić nurtujące Cię sprawy.

Zapisz się na newsletter, aby otrzymywać informacje o nowych artykułach oraz inne dodatki.

Jak znaleźć mentora?

Skąd wiem, że wybieram dobrego mentora?

Znak zapytania

Nie wiesz 😉 Możesz jednak zmaksymalizować szanse na wybranie odpowiedniej osoby poprzez zwykły research w internecie. Proponuję zacząć od profilu na LinkedIn, tam na pewno sprawdzisz, jakie ktoś ma doświadczenie i jak często się udziela. Często na LinkedIn można zobaczyć artykuły i odnośniki do bloga. Można spróbować wyszukać mentora na StackOverflow i zobaczyć jak wielu osobom pomógł. Dodatkowo warto poszukać w różnych innych grupach dyskusyjnych.

Gdzie znajdę mentora?

Oczy!
  • LinkedIn,
  • Meetupy takie jak JUG, WarsawJS, ReactWarsaw, Warsaw Cloud Native Meetup, Dev.js itp.,
  • Grupy dyskusyjne – grupy na facebooku (m.in. ta, którą ja założyłem), StackOverflow, 4Programmers,
  • Grupy na Slacku – na tym komunikatorze można znaleźć wiele ciekawych kanałów. Jednym z nich jest DevsPL, jest tam bardzo dużo programistów, którzy z chęcią odpowiadają na pytania. Gdy uczyłem się React.js, osoby z grupy FrontendDevelopers bardzo mi pomogli. Pamiętam, jak każdej nocy czekałem aż amerykanie skończą pracę, aby móc zadać pytania bezpośrednio jakiemuś specjaliście z zachodniego wybrzeża.

Podsumowanie

Odpowiadając na pytanie zadane w tytule: Tak, potrzebujesz mentora, ale zależy na którym etapie. Podczas budowania większych projektów używających dodatkowych frameworków, bibliotek oraz innych skomplikowanych rozwiązań, pomoc mentora na pewno Ci się przyda. W przypadku tworzenia realnej aplikacji zacznie się w Twojej głowie pojawiać milion pytań. Każda odpowiedź urodzi kilka nowych pytań i potencjalnych rozwiązań. Bardziej doświadczona osoba na pewno pomoże Ci odrzucić pewne rozwiązania i rozwiać Twoje wątpliwości.

Powiedziałbym, że do samej nauki programowania mentor nie jest Ci potrzebny, ale do dalszego sprawnego rozwoju w IT na pewno pomoc takiej osoby Ci się przyda.

Jeśli potrzebujesz mojego wsparcia oraz moich znajomych programistów, których zebrałem w jedno miejsce, to zapraszam do dołączenia do grupy na facebooku.

Zapraszam do poczytania innych moich artykułów na blogu oraz polubienia mojej strony na facebooku, oraz profilu na instagramie.