Motorola, Altkom, Samsung.
Od tych 3 firm dostałem do wykonania codility. Od każdej dostałem podsumowanie w stylu, dzięki za poświęcony czas ale spier***. 0 konkretów. Jaki miałem wynik, co było źle.
Wniosek: dostajesz codility? Zlewaj firmę na starcie.
Jeden rabin powie tak, drugi powie nie :D mnie po codility + małe zadanie praktyczne zaproszono na dzień próbny w firmie i opłacono dojazd + nocleg, więc różnie bywa.
A obrońcy codility (i zadań domowych) mówią że warto to robić chociażby dla samego feedbacku :|
A zrobiłeś testowe zadania z Codility dla siebie? Ja przed testem zrobiłem i bardzo się zdziwiłem... ale za to na prawdziwym teście poszło mi mocno dobrze (pamiętam, że nauczka była taka - rób te testy jakbyś znowu był studentem, a nie siedział 20 lat w javie).
@thock: nie od dziś wiadomo że najlepsze oferty są z polecenia. Dlaczego na rynku nie ma ofert dla Senior QA? Bo Senior QA jest tak mało że większość stanowisk jest obsadzana z polecenia
@Tomek Pycia: i tak się odsiewa tych najsłabszych albo tych co mają szacunek dla siebie. Zostają tylko Ci co chcą robić nadgodziny za darmo
Z dwojga złego Codility jest przynajmniej mniej czasochłonne, niż "zadanko" na za tydzień ;) chyba że ktoś jest przyzwyczajony do taśmowej produkcji springowych apek i faktycznie potrafi się zmieścić w 60-90min z testami, security etc.
@KamilAdam: Nigdy nie miałem rekrutacji na codity, tak że nie mam pojęcia co to jest i jak to wygląda. Ale mógłbym poopowiadać dużo o patologiach klasycznych metod rekrutacji. No i może lepiej poświęcić te 60 minut na jakieś codity i dać se spokój nie 3 h - dojazd, rozmowa, powrót tylko po to, żeby stwierdzić ze chyba jednak, ta firma cie nie interesuje.
Rozumiem krytykę Codility, ale nie uważam, że jest bez sensu. To co ja dostałem to faktycznie nie były testy sprawdzające użyteczność umiejęstności nabyte w normalnej pracy. To były 2.5 godziny poświęcone na udowodnienie, że jestem w stanie nauczyć się rozwiązywać zadania w nietypowym środowisku, z ograniczeniami i nietypowymi zasadami. W normalnej pracy też nie wszystko to CRUDy, gettery i settery. IMO małe poświęcenie jeśli ktoś na serio szuka pracy na miesiące, albo lata. I dostałem wyniki testu.
Jak byłem na rozmowie w Google to miałem kilka godzin maglowania zadań na żywo i jedyny feedback jaki dostałem to też ten na żywo (bardzo ubogi, w zasadzie tylko tyle czy idę w dobrym kierunku czy nie jeśli chodzi o rozwiązywanie zadania i to nie od razu tylko po jakimś czasie kombinowania). Po całym dniu rozmów mieli mnie dalej oceniać (tym razem wspólnie między sobą, a nie indywidualnie ze mną na bieżąco) i wysłać opinię emailem. Jednak opinia (w emailu) była standardowa typu, że się nie nadaję na żadne otwarte stanowisko (może jakoś bardziej dyplomatycznie to napisali), a poza tym 0 konkretów. Myślę (aczkolwiek moje przemyślenia są oparte o bardzo małą liczbę przypadków), że w ogóle liczenie na rzetelną opinię jest daremne, no chyba, że coś na żywo podpytamy, albo ktoś jest chętny coś nam proaktywnie na żywo zasugerować.
Feedback nie leży w interesie firmy. I dlatego tego nie robią - ktoś by musiał poświecić czas, zebrać informację oceny. Ubrać to w słowa itp itd. nikt za to nie che płacić i nie ma co się dziwić. Należy mieć wywalone i szukać dalej. Kiedyś dzwoniłem do takich firm i pytałem to i tak nie wiedzieli, dlaczego i kto mnie odrzucił. Czasem można odpaść tylko dlatego, że ktoś miał gorszy dzień, od 3 dni naprawił awarie a kazali mu iść na rekrutację i milion innych powodów.
Już kiedyś przytaczałem opinię ludzi ze strony 'socji-psycho-itd'. Takie testy są po to, żeby wybrać ludzi którzy od początku zgadzają się na takie praktyki. Na wstępie test który kompletnie nic firmy nie kosztuje, później, później... Później mamy ludzi z którymi można robić (prawie) wszystko, nawet wsadzać tam gdzie kontrakotrzy uciekali.
U mnie w firmie chyba też na rekrutacji teraz jest codility i codziennie dostaje newslettera jak prowadzic rekrutacje albo o pracy zdalnej, śmiesznie ogolnie.
@Tomek Pycia: Co ma codility do tego co się robi w firmie? W pierwszej pierwszej firmie miałem codility, trzeba było zrobić napisać funkcję sprawdzającą czy string jest palindromem (Z jakimiś tam ekscesami, nie istotne), a jak się dostałem to w robocie siedziało się, logi czytało i ify wstawiało aby się klientowi soft nie wykładał. Jak się ma poziom trudności do jednego a do drugiego? Na zadaniu musiałem pomyśleć a w robocie wstawiam log, patrze gdzie jest "dupa print" jak jest to patrze co się sypie i ifuje
No chyba żadna rekrutacja nie ma odzwierciedlenia z wykonywaną pracą na stanowisku
@Wibowit: "Jak byłem na rozmowie w Google to miałem kilka godzin maglowania zadań na żywo" I to jest istotna różnica. Bo na żywo oznacza, że po stronie firmy zaangażowano jedną, dwie osoby które poświęciły nawet więcej czasu niż ty (bo wewnętrzny feedback musiały zrobić). Codility oznacza zero zaangażowania po stronie firmy.
Kilka miesięcy temu miałem świetny test wstępny - pytania, CR i testy do napisania. Uważam, że jedna z najlepszych form z jaką do tej pory miałem do czynienia
Na rekrutacji w Google to moge pisac kod nawet w Google docs, ale to jest Google a nie firma Krzak.
@karsa: a jakie to ma znaczenie, że to Google? Im bardziej zaawansowana firma to należy się po niej więcej spodziewać.
@Tomek Pycia: że mają ludzi na pęczki, więc kazdy czlowiek u nich na rekrutacji to jakis random. Po drugie Google w CV to otwarcie sobie drzwi wszędzie. Po prostu FAANG to inna para kaloszy i tyle.
@karsa: Bo FAANG to FAANG, a nawet tam zaangażowanie jest z dwóch stron. Testy z automatu może pisać sprzedawca w sklepie który chce się przebranżowić i startuje na Nokia Academy. Ale nie rozumiem jak ktoś daje się namówić na zmianę pracy w lokalnej firmie gdzieś we Wschodniej Europie i robi jakieś testy z automatu za które nie dostanie nawet kopa w d... w odpowiedzi.
@karsa: trochę inaczej postrzegam te branże. A tego FAANG to musiałem wygooglowąć.
Codility oznacza zero zaangażowania po stronie firmy. - oczywiście, bo firma powinna pokazywać zaangażowanie, żona szefa powinna rozkładać każdorazowo czerwony dywan, a jak się zgodzisz na jakieś testy to potem będzie jeszccze gorzej, będziesz siedział w firmie z samymi no-life co umieją kodować, a jakiś manago będzie Ci kazał pisać nudny kod biznesowy... Przegryw.
@jarekr000000: żona szefa powinna rozkładać każdorazowo
..
..
..
czerwony dywan
Firma powinna wykazać zaangażowanie. Najpierw umówić się na krótką rozmowę przez telefon. A, zapomniałem, wielka depresja jak prawie 100 lat temu, pod drzwiami koczują setki bezrobotnych. Bo w 21 wieku w zaawansowanych technologiach nie jest tak, że układ jest 1:1, firma chce zatrudnić, pracownik chce pracować. "Dlaczego chciałby pan u nas pracować? Nie wiem czy chciałbym u was pracować, to pani do mnie zadzwoniła z ofertą. Ale po to ta rozmowa, żeby się przekonać, czy ewentualnie chciałbym odejść z mojej pracy".
@BraVolt: Bosze to nie odpowiadaj na takie oferty i koniec. http://bibsy.pl/C0iLEcF0/nietolerancja-psingwinie-a-co-to-tolerancjajesli-nie-tolerujesz-np-laktozy-to-po-prostu-nie-pijesz-mleka-a-nie-golisz-leb-na-lyso-i-ganiasz-po-miescie-krzyczac-jebac-krowy
@BraVolt: pojechaliśmy (razem) w Ad absurdum (ja zacząłem) . Ale ja tu wstawię to: 11. Do new candidates write code during their interview?
@Tomek Pycia: ale co tu jest inaczej do postrzegania. Dla FAANG jesteś nikim i oni mają kandydatów na pęczki. Oni tam się nie muszą starać o programistów, jest większa podaż pracowników i czesto nie wykazuja jakiegos wielkiego zainteresowania. I to już TOP 30 firm tak wygląda. Niektórzy ludzie idą do Amazona tylko dla CV. I nie jest wcale istotne, że wcale nie robisz w tym Google nic zaawansowanego. Funkcjonuje nawet coś jak "regular googler" bo takich też mają pełno.
@Tomek Pycia: tak zmienia. Alkohol spożywany umiarkowanie nie szkodzi nawet w dużych ilościach. A mleko to biała śmierć.
https://lubimyczytac.pl/ksiazka/66335/mleko---cichy-morderca - autor nazywa się jak swojsko przerobiony fastfood serwowany na dyskach SSD. To rodzi zaufanie.
@karsa: jak jesteś kiepski to wcześniej czy później wylecisz, czy masz w CV google facebook, czy pornhub. Tak naprawdę być jakimś szeregowym mięsem w Google nic nie znaczy. Liczą się znajomości zaangażowanie i wiedza.
@jarekr000000: "candidates write code during their interview" - robiłem niejeden raz. Ale dla mnie wysłanie 100 linków do wygenerowanych zestawów testów to nie to samo co przeprowadzenie 100 rekrutacji.
Cukier da się zneutralizować do postaci bezpiecznej do spożycia (fermentacja).
@Tomek Pycia: w mleku jest cukier m.in laktoza, w bimbrze cukier jest asekuracyjnie przetworzony w etanol
@jarekr000000: gluten nie, mleko nie, mięso też nie - to już chyba lepiej się zachlać i mieć spokój.
@Tomek Pycia: tylko musisz uważać na wódki z żyta - powszechne, niestety. Tak samo blendy - też, niestety. gluten.
no niestety mam podobne doswiadczenia - jak firma daje hackerranka albo codility to od razu mam mieszane uczucia, ale moze dlatego ze kazda firma w ktorej je mialem wypadla mega słabo i nie dogadalismy sie; za to najlepsze byly projekty w ktorych na rozmowie byla zwykła rozmowa o umiejetnosciach, doswiadczeniu i podejsciu, bez żadnego maglowania algorytmów itd.
jak jest firma co daje nudnego CRUDa do zrobienia i dostajesz feedback bo temu co oceniał miał inne własne preferencje to też słabo
W mojej firmie na rozmowach też jest live coding jako jeden z etapów ale nie lubie w tym uczestniczyc, uważam, że to blędogenne. Wole brać udział w częsci gdzie jest system design i przekrojowo przejście po CV kandydata + trochę pytań technicznych.
@null null: ja tez wyslalem ostatnio jakiegos home taska i gosc sie przyczepil, że nie podoba mu się jak zgrupowałem testy, albo, że mogłem zrobić X ale nie zrobiłem... bardzo twarde kryteria
Kiedyś sobie śmieszkowałem z kumplem, żeby dokumentacje rozpisać na zadania i dać rekrutom do rozwiązania, posklejać, drobny refactoring i projekt gotowy za półdarmo :D
To jeśli nie Codility czy inny tego typu system - jak najprościej sprawdzić jak ktoś programuje, samą rozmową? "Jak można zatrudnić programistę bez sprawdzenia jak koduje?" - Seliga, 2012.
@null null: Szacun, nie zmarnowałeś bonu wakacyjnego. Urlop poświęciłeś na zadania rekrutacyjne. W nagrodę za tydzień pracy w urlop dostałeś przejście do następnego etapu. Fajne wakacje.
@dargenn z tej samej prezentacji dowiedziałem się, że mogą dać juniorowi 20k ale u nich na entry-level w Javie powinienem znać siedemnaście garbedż kolektorów i inne takie, a jak nie to wypad bo jestem C-playerem :D :D :D nie neguję bycia C-playerem ale trochę jednak popłynął, rozumiem że u niego najwyraźniej robią (robili?) sam cutting-edge, low latency soft, ale jeszcze nie widziałem człowieka grzebiącego w GC (nie tylko JVMowych) bo latencje miał za wysokie.
@superdurszlak: polecam , trochę sie zmienil. Ale tez z innych prezentacji wynika, że "dziewczyny lubią brąz" w tym spartezie, więc nie wiem czy podejście z A players sie nie zmienilo czasem teraz. Skoro mozna kupic zespol gdzies taniej . No i widełki od nich już raczej nie są TOP.
@superdurszlak: już nie pamiętam tej prezentacji (i nie chce mi sie oglądać), ale też może być ważna perspektywa czasowa. Gdzieś do javy 1.6 włącznie było dużo problemów z tunungiem GC w javie. Nawet jak robiłeś monolit JavaEE z czasem odpowiedzi ... dobrze by było, żeby mniej niż minuta, to bywało, że o 8:15 system umierał. Często przez GC - były wycieki w PermGen (tymczasowe klasy od g**no frameworków). Jak sie udało wypracować taki trzylinijkowy zestawc przełączników -XX do GC to był to prawie skarb firmy jak recepta na CocaCole. Więc jeśli Seliga wychował się jako javowiec, walcząc z produkcję gdzieś tak w latach 2000-2009 to może mieć takie właśnie wspomnienia.
Ta prezentacja jest super stara jak Wojtek był dość mlody, w 5-10-15 bardziej to widać. A co do GC to dalej jest problematyczne i dalej gdzie jest większa skala to się jednak tego JVM wywala. Najbardziej JVM się ostał przy technologiach typu Lucene/ES/Solr, nie ma za bardzo alternatyw.
@karsa Najbardziej JVM się ostał przy technologiach typu Lucene/ES/Solr - czasem nie wiem co Ty piszesz. A JVM Gdzieś się wywala, a gdzieś się stawia - normalny cyk życia i śmierdzi.
No nie bardzo jest czym to zastąpić, Kafke już X firm probuje wywalic ze stacku. Podobnie cudowny pomysł pisania Linkerd w jvm.
@karsa - no ja próbuję kafki nie wpuścić ( i raczej przegram) :-) ale nie ma to nic wspólnego z JVM ani z GC.
Odnośnie Linkerd https://www.infoq.com/articles/linkerd-v2-production-adoption/
@karsa - nie wiem ile żyjesz na ziemii, ale w końcu ogarniesz, że jakiekolwiek racjonalne przesłanki to zwykle 5% tego co stoi za wyborem, albo zmianą technologii. Co więcej, ze względu na survival bias większość historii o zmianach/wyborach to jedno wielko pasmo sukcesów.
@jarekr000000: nie neguję, że kiedyś musiało być dużo gorzej z GC - teraz to może w jednej kobyle z rodowodem z tego właśnie okresu widziałem może 1 albo 2 przełączniki -XX na krzyż. Może ktoś rzeczywiście musi po dzień dzisiejszy żmudnie kulać do niej recepty na Coca-Colę, żeby się nie potknęła pod produkcyjnym obciążeniem, tego nie zweryfikuję. Ale nie sądzę, żeby nawet w 2012 albo i 2005 ktoś sadzał na rekrutacji delikwenta-interna przed takim krówskiem i kazał z palca ukulać receptę, bo jak nie to wypad :)
@superdurszlak: racja - dziwne, co więcej nawet w czasach, kiedy byłem mocno na bieżąco w tych wszystkich GC i przełącznikach główny sposób działania to było: zrób test, pomierz... zmień przełącznik, pomierz (mówimy tu o odpalaniu symulacji produkcji na kilkanaście minut i sprawdzanie czy się np. nie wywali pod obciążeniem), jakakolwiek logiczne rozumowanie użyte do parametru GC zwykle wprowadzało skutek odwrotny od oczekiwanego...
@jarekr000000: co? Tam gdzie jest naprawdę duża skala to JVM jest problemem i tyle (1 mln req/min to jeszcze nie tak dużo). JVM zwyczajnie się nie nadaje do robienia baz danych, service mesh, brokerow itp. To zwyczajna glupota. Owszem da się i zostało tego pełno stworzone, ale to głównie popularność Javy i nic więcej. Ale nie po to się coś robi , żeby odprawiać nad tym tańce indiańskie tylko by dzialalo, i zabawy z tysiącem flag a połowa z nich nie działa...
Polecam serie z Cantrillem https://edgemesh.com/blog/performance-talks-episode-1-bryan-cantrill
@karsa: to ja mam teraz pytanie: czy tam gdzie jest naprawdę duża skala i np. wymagane jest SLA 4/5/6 nines, w 2020 roku nadal polega się wyłącznie na tym, że ten jeden jedyny proces nigdy nie padnie (lub nie zostanie ubity) i uciągnie cały ruch, a system będzie mieć na pewno 10 lat uptime? Jeśli tak nie ma co zwalać problemu wyłącznie na JVM, każdy proces może się kiedyś wysypać lub zostać uwalony.
Poprawcie, ale czy nie w krajach Afryki: Erlang, telekomy, i największa liczba mikrotransakcji (taka specyfika tamtego rynku). Po prostu działa.
Beam z Erlanga to nie JVM I jakos broker to przejdzie najprędzej. Rabbita też pod niskie latency nikt nie wezmie. Proponuję piszcie load balancery w javie, z pewnością zrobicie furorę na rynku.
@superdurszlak jeszcze kwestia ile zasobów to zeżre.
@karsa: Proponuję piszcie load balancery w javie, z pewnością zrobicie furorę na rynku. o co Ci teraz chodzi? ktoś Cię obraził, bo nie przyłączył się wystarczająco ochoczo do lamentowania nad beznadziejnością JVMa? Do nas masz pretensje, że ktoś pisze brokery i load balancery w językach z GC albo VM? Ustawą tego nie zabronisz, ludzie próbowali pisać OS w Javie, .NET i zapewne całej masie innych języków, które były do tego zbyt wolne i zbyt zasobożerne - i ot, okazało się że są zbyt wolne i zbyt zasobożerne albo z dowolnych innych powodów się nie nadawały. Kurtyna.
@superdurszlak: he? A gdzie ja lamentuje. Prędzej nie wiem o co chodzi Jarkowi. Dla mnie język to tylko narzędzie, nie wierzę w 'general purpose' languages. We wszystkich można pisać wszystko. W czymś ma to większy sens w czymś mniej i tyle. Mówię tylko za siebie i po prostu jeżeli z czymś trzeba się gimnastykować to najpewniej dane narzedzie jest po prostu zle. I broń Boże nie uważam, że JVM jest beznadziejne, wręcz przeciwnie. Z pewnych dziedzin życia jest wypierana i dobrze. Są też miejsca gdzie sprawdza się świetnie.
@karsa: po co w takim razie przytyki takie, jak przytoczyłem wyżej? Jarkowi jeśli dobrze rozumiem (czuję się teraz trochę jak korwinista tłumaczący wypowiedzi JKM - a śmiałem się kiedyś na forum, że @jarekr000000 będzie mieć wianuszek kuców tłumaczących jego wypowiedzi, o ironio) chodziło o to, że decyzje odnośnie tego, w jakiej technologii coś będzie rozwijane rzadko są dyktowane racjonalnymi lub technicznymi argumentami, często decydują buzzwordy, widzimisię itd. Mamy na zbyciu kilka zespołów Javowców -> każemy im pisać w Javie, bo przecież z czymś innym sobie nie poradzą. Wybuliliśmy miliony na supporty, licencje na jakieś paskudztwo -> szkoda, by się marnowało. Ktoś ważny chciał się wykazać, albo uznał że on to musi coś zrobić żeby było lepsiej -> i siup, wszyscy muszą pisać w X bo wierchuszka przykazała. Mikroserwisy są w modzie, a chcemy być nowocześni -> i cyk, będziemy łoić te mikroserwisy choć nie wiemy jak i po co i skończymy z analogią Wrocławskich krasnali - rzeźba z brązu, tylko rozproszona.
Pan czarodziej zaczął pierwszy od przytyków "nie wiem ile żyjesz na ziemii, ale w końcu ogarniesz". Nie wszystko kręci się wokół biznesowych aplikacji i biznesowego JVM. Open source i rzeczy niższego poziomu rządzą się nieco innymi prawami i niewiele osób coś takiego klepie. Najłatwiej mówić jak nie trzeba było tego supportować na produkcji.
@karsa Po pierwsze to gratuluję odwagi. życia na krawędzi - już tyle godzin opluwasz jvm, że aż dziw, że jeszcze nie wywołałeś tego, którego imienia ... (zresztą, bez wody, wprost z woreczka najlepszy). Po drugie: Zapominasz o tym, że projekty nie są statycznie, żyją i ewoluują. Kafka jest obecnie dość dobrze zdefiniowanym projektem, prawie co do bajta wiadomo co i jak ma robić. Dlatego, można się mądrzyć, że jakby jąktos napisał w Rust to może byłaby i szybsza i mniej zasobów zajmowała - jest to prawdopodobne. Ale gdzieś kiedyś był team, który nie do końca wiedział co robi, nie do końca wiedział czy dobrze i czy to się przyjmie. Potrzebował platformy, w którą umi, która będzie dość elastyczna, będzie łatwa w integrowaniu i analizie problemów, a do tego przy 10000 req na sekunde nie wywali się nawet jak programiści nie są bogami i czasem czegoś nie zwolnią, przytnie się, ale się nie złoży. Fakt, że przy pewnej skali to już gc i żadna magia jvm nie pomoże, a wręcz zaczyna ta magia przeszkadzać... ale trzeba do tej skali(Scali) dojść. Wiec te bazy nadal będą robione w jvm, i pewnie nawet w js, a może jeszcze w PHP i jeszcze będziesz musiał to przełknąć na produkcji - deal with that.
Nie wiem jak to można nazwać opluwaniem jvm, ale ok niech będzie, imo nawet nie zaczalem. Ogólnie przy niczym z wyżej wymienionych nie chciałbym pracować on premise, jedynie z cloud. Starczy mi, że widziałem całkiem duży klaster Solra, jest po prostu za dużo zabawy z czymś takim. + Moje ulubione zookepery.
Mnie się jvm już dawno znudził, ale każde wyjście poza ten światek w real life pokazuje, że ta platforma ma jednak mocne i niedoceniane strony (bierzemy je za oczywiste). Na przykład: nieważne jak rzadkie jest twoje zboczenie to znajdzie sie dobra biblioteka jvm, która to zboczenie zaspokaja. (Zupełnie tak jak w js/npm). I nieważne co już masz narypane w swoim projekcie możesz tą bibliotekę użyć i dołożyć jako 137-mą zależność. Wszystko będzie działać, build się nie wywali, nie wpadniesz raczej w żaden dependency hell. (Zupełnie NIE tak jak w js/npm). Btw. Haskell/hackage stack jest gorszy w dependency hell nawet od js (tylko bibliotek 1000 razy mniej).
Kafka jest i tak dość udanym projektem, ale i tak większość nie potrzebuje takiej armaty. Chwała im za to, że chociaż wywalili zookepera
Jeżeli chodzi o backend development okolo crud aplikacji to JVM ma moim zdaniem solidny fundament. O ile lubię Golanga do pewnych zastosować to do programowania biznesowych aplikacji uważam za kontrproduktywne i nie wiem jak PHPowcy i pythonowcy mogą próbować z tego robić PHP2.0. Albo wciskać DDD do Golanga...
Mi się JVM znudził jak i biznesowe aplikacje już wolę swojego opsowego yamla +możliwość cisnięcia devom, że to co wyrabiają nie ma prawa działać.
Przestań szufladkować ludzi. Opsowalem zanim ktoś nazwał to "devops", kiedyś nikt tego nie rozgraniczal. I jestem programista i najwięcej spędziłem swojej kariery w javie na backendzie. A próbuje być po prostu Inżynierem Oprogramowania a bez Opsowania bylbym raczej marnym programistą.
@karsa - sorry, mam uraz - tak 15 lat temu koszmarem byli rozsiani po firmach BOFHowie, których cechą wspólną było to, że największy program jaki napisali to miał 60 linijek i był w bashu, ale którzy za każdym razem mówili Ci jak masz programować. I w ogóle zawsze można się było tony psikusów spodziewać - od podmienienia jvm na najlepszą implementację kaffe, bo w debianie pogłogosławiona. Do przemigrowania mysql z innodb na myisam, bo przecież szybsze...
Dalej są i tacy ale sporo się zmieniło w tej kwestii. Mimo to większość opsow jest dużo bardziej pragmatyczna, bo skupiają się, że ma działać i być dostępne a nie na nowym frameworku, który absolutnie nic nie zmienia, poza tym, że jest większe prawdopodobienstwo, że się wywali. ;) Obecnie jest już to raczej mix Adminów co zostali programistami i programistów co mieli większe zacięcie do infry gdzie ja to bardziej to drugie.
Opsy w mikroserwisach to są absolutnie pochłonięte ratowaniem wszechświata przed zagładą. Niestety tak to wygląda w większości przypadków.
@karsa zdziwiłbyś się, co programisto-opsi ratujący świat w mikroserwisach potrafią wyczyniać :D
@superdurszlak: wiem, widziałem, nic mnie nie zdziwi. I wrzucanie do wszystkiego kubernetesa to też jedna z głupot. Ale to devy mają częściej podejście "wrzucmy service mesh, nie będziemy musieli pisać circuit breakers". Och, wait, wiekszosc devow zapyta "co to circuit breaker?"
No I to jednak w większości firm działa tak, że błędy aplikacyjne ląduja na opsach. Nie bez powodu poziom happiness jest dość niski.
@karsa to działa w obie strony, opsów wyświadczających niedźwiedzie przysługi developerom już widziałem, problemy z infrą i opsami lądujące u developerów też. O całej masie groteskowych sytuacji na linii developerzy vs X dla dowolnego X to już nawet nie wspomnę, też w obie strony. Do 30tki zdążę pewnie osiwieć.
Bo każda grupa ma nieco inne cele i to jest docieranie sie. Ale sensowność opsow jest tylko w większych firmach. Jakiś projekt w SH to raczej bezsens.
@urke: widziales co napisałem? Bo napisałem, że często psujące się aplikacje lądują na tapecie opsów. A opsów jest zazwyczaj dużo mniej niż aplikacji (czasem w setkach do kilku osób) i developerów. Widziałem absurdalne sytuacje gdzie Opsy debugowaly i szukały memory leakow w javie... Gdzie w ogóle nie powinni się tym interesować, tylko zepchnąć na team. Więc dziwnym trafem jest to kwestia polityki i niezrozumienia tematu przez leadership. Bardzo rzadko aplikacja rozwala się z powodu samej infrastruktury. Jak jest auto wadliwe to jest to wina producenta. Ale w tym przypadku winę zrzuca się na zarządcę drogi. I to nie jest odosobniony przypadek gdzie devi cos robia a ktoś inny ma być do tego on call. Z pewnością aplikacja nie działa bo AWS albo kubernetes nie działa, ta , na pewno. Żeby zmienić podejście trzeba być dobrym w politykę, przekonać management, zdefiniować SLA, SLO, Error budgety, cokolwiek, zmienić rotację on call.
"Good operations can often work around the limitations of bad (or incomplete) software, but good software cannot run reliably with bad operations" - tylko dzięki temu aplikacje które nie powinny dzialac, działają na produkcji. A żyjemy w świecie dość dużej tolerancji na half baked solutions.
Mam wrażenie, że problem pogłębiło jeszcze podejście Devops. Źle zrozumiane zamiast współpracy wprowadziło duża separację i obrzucanie się jednych przez drugich. Ale w wielu firmach przesunęło odpowiedzialność za aplikację na mitycznych "devopsow". Kiedyś jak pracowałem w firmie to Pan Ops to był co najwyżej jakiś Admin co o mojej appce nie miał pojęcia. A to właśnie zespół zajmował się od A do Z aplikacją i musiał rozumieć na jakiej infrastrukturze operuje i uczyć się na bledach. A z drugiej strony często zwykłego admina zaczęto nazywać inna nazwa a oni dalej co najwyżej instalują pluginy do Jiry. To jest przede wszystkim problem organizacyjny.
Ja swego czasu zobaczyłem to w Scrum, zespół developerów robił taski jak najszybciej - bo velocity, a powoli rósł sobie drugi zespół od sprzątania. Nawet ciekawy eksperyment wyszedł. Nie było jakiegoś narzekania, ale musiałem to ubić. Oryginalny zespół developerów zaczął się specjalizować w pisaniu coraz gorszego kodu, bo i tak przyjdzie walec i wyrówna, a przecież velocity!.
@jarekr000000: jakby nie patrząc jest to ciekawe. I tu mam duży zarzut do mikroserwisow. Bardzo często na rzecz "developer experience" poświęcono "experience" innych postaci które również mają spory wpływ na development. Ale ogólnie mam obawy, że to się opłaca. Mimo, że pod względem technicznym jest to bez sensu bo zespoły tracą feedback loop z produkcji. No ale jej mamy małe grono sprzątaczy a tyle ficzerow dowozimy, tak? Oczywiście wszystko trwa do czasu przekroczenia masy krytycznej. Ale na pewno nie o to chodziło w "devops"
@superdurszlak: Mikroserwisy są w modzie może jeszcze u nas, bo bezwładność. Z tego co obserwuję, to wahadełko od pewnego czasu ruszyło w przeciwną stronę. Następna faza to zapewne: monolity 99%, mikro 1% przypadków (gdzie rzeczywiście warto).
@thock: może trzeba w końcu nauczyć się pisać aplikacje modułowo zamiast robić separacje na poziomie networku...
@KamilAdam: pod tym wzgledem też niewiele języków pomaga, bodajże właśnie Scala robi to dość dobrze ale Java czy Kotlin to już tak srednio.
@KamilAdam: chodzi mi o zarządzanie pakietami i modyfikatory dostępu. W javie miałeś chociaż package scope. Kotlin ma internal. Jezeli dobrze pamiętam to w Scali można nawet robić struktury drzewiaste. Gdzie w Javie jak cos jest public to jest public wszędzie i tyle https://www.jesperdj.com/2016/01/08/scala-access-modifiers-and-qualifiers-in-detail/ , pewnie @jarekr000000 to lepiej ujmie
@thock: masz nawet prelegenta który niemal specjalizuje sie w udowadnianiu, że coś już kiedyś było https://twitter.com/KevlinHenney ,
@karsa ma racje, aczkolwiek kotlin też zły bo ma internal. Po prostu zamiast pakietu (w scali) robisz moduł w gradle (serio- mam moduły po 3 klasy). Zresztą moduły w javie też problem naprawiają tylko masz wiekszą biurokrację.
A co do modularnego monolita. Naprawdę prostym rozwiązaniem, ktôre pomogło by wielu zespołom, jest separacja bazy danych na małe kilkutabelkowe schematy. Zależności między pakietami w javie nie są tak problematyczne, jak optymalny join co leci przez 15 tabel z różnych kontekstów (ale optymalny).
@karsa: Dzięki, obejrzę. Myślę, że po przekroczeniu ściany (30-35 lat), jeżeli tylko nie siedzisz głęboko w jakiejś sekcie, zaczynasz te cykle dostrzegać.
tyle, że im real life to czasami widze odwrotną akcje - kilkaście na siłę rozerwanych serwisów, na osobnych jvm rypie się razem w jednej bazie. Co jeszcze ma zabawny wpływ na wersjonowanie i deploymenty...
@jarekr000000: no niby można wspomóc sie gradlem przy kotlin i internal, ale wolalbym to zrobić na poziomie samego języka. A zabawa z multi modules gradle nie jest czyms co mi sie podoba :P
@karsa Henneya kojarzę, to było niemal urocze jak pokazywał, że współczesne wymysły i nowinki pojawiły się tak naprawdę w latach 60, potem zostały zapomniane, a teraz ludzie uważają że odkryli Amerykę. Teraz czytam Kleppmanna i na wstępie w zasadzie to samo zrobił z NoSQL :D @thock: do nas wahadełko też już dotarło. To znaczy - dotarło w słowie mówionym, i ludzie zdają już sobie mniej-więcej sprawę w czym im się przychodzi babrać. ALE to, że do klepaczy wahadełko dotarło nie znaczy, że do matek korporacji to dotarło - tam to dopiero jest inercja, i korporacje nadal mierzą sukces w liczbie mikroserwisów. A przy okazji Red Flag Law trzyma się mocno i dopiero mamy kombo.
@jarekr000000: sorry, ale nie rozumiem o czym wy gadacie... zrobił się tu nam jakiś wątek jvm :)
@superdurszlak: sztandarowe jest przypominanie konferencji NATO z 1968 gdzie można powiedziec, że było już wiekszosc rzeczy tych co teraz. Paweł Szulc - z bojówki Scali chocby o tym przypominał tutaj, pierwsze 15 minut
sorry, ale nie rozumiem o czym wy gadacie @thock: chodzi Ci o widoczność klas? Java ma domyślnie pakietową widoczność klas dzięki czemu abstrakcja nie wycieka po całym projekcie. Scala ma konstrukcje private[nazwapakietu] dzięki czemu możesz ustalić jak wysoko w hierarchii pakietów będzie widoczna klasa. Kotlin w zamian za to nie ma dostępu pakietowego tylko internal który powoduje że klasa jest widoczna w całej bibliotece (jarze, jednostce kompilacji), dlatego Kotlin zachęca do podziału projektu na dużą ilość podprojektów (z każdego jest budowany osobny jar więc klasy oznaczone internal nie ciekną po całym projekcie)
Mnie się podobały również jego wypowiedzi o znaczeniu nazw itd. i jasnym komunikowaniu intencji przez kod. Myślałem, że to ja jestem upośledzony (bo Javowcem zostałem niejako przypadkiem - korporacja chcąc nie chcąc przerobiła mnie z Pythonowca na Kotlinowca, a potem jakoś tak wyszło że musiałem zstąpić do piekieł bo Kotlin w backendzie to do niedawna była rzadkość) skoro trafia mnie na widok tych klasycznych, długaśnych Javowych nazw, które ledwo mieszczą się na ekranie, absolutnie niczego nie komunikują, albo raczej informacja jest tak rozrzedzona zbędnymi słówkami, że i tak jej nie widzę. No ale nie, okazuje się, że nie tylko mnie to drażni :D
@karsa: te multi modules w gradle nie są idealne, ale problemów i biurokracji jest mniej niż sie człowiek spodziewa - jeśli już wdepniesz w kotlina to IMO warto z tego korzystać,
@jarekr000000: z alternatyw o ktorych myslalem to ArchUnit... ale też trochę workaround ;)
@karsa kiedy Twoim zdaniem byłoby warto wprowadzić ArchUnita? Jak zaproponowałem to u siebie to oberwało mi się, bo po co i na co i nie piszemy przecież monolitu na 300 modułów, a w ogóle skąd wiemy że to kiedyś urośnie a nie zdechnie (zakładam - dlatego, że nie mamy zamiaru pisać do szuflady, a jeśli mamy to nie piszmy wcale i po sprawie). Ja tam wolę, żeby to co się dało pilnował automat i większość baboli odsiewał automat, a nie tylko czujne oko reviewera, no ale...
@superdurszlak: jezeli nie automat to kto bedzie pilnowal? Alternatywa to tylko code review. A code review w tym przypadku checkout brancha, co jest ciężkie by wszystko sprawdzac... Więc jeżeli mamy przynajmniej kilka domen/subdomen biznesowych w naszej aplikacji... to może być to przydatne. No i Albo pomaga nam w tym sam język, albo robimy gradle + internal lub whatever, lub próbujemy zrobić ArchUnita... tyle, żeto też może być dość błędogenne... i nie udało mi sie tego wykorzystać w praktyce więc nie wiem na ile to jest uciążliwe w użyciu
czysteskarpetyOczywiste ;)