to też wesołe:
“I only fly Delta Airlines (first class) and I only stay at Hilton Hotels.”
Tzn. $300/h za faktycznego rubiowego albo railsowego turbowymiatacza (np. kogoś z rails-core albo ruby-core, taki Ryan Davis bierze $200/h) jest jeszcze zrozumiałe (chociaż jeśli Ryan Davis czy Jose Valim biorą mniej, to co-najwyżej-drugoligowiec Obie nie jest tyle wart).
Ale to $10k/d plus reszta warunków (first class, Hilton) zaczyna mi wyglądać na bezczelny troling zaporowy, na zasadzie “nie jestem dostępny na całe dnie pracy na miejscu, chyba że kogoś pojebało” 
Uważałbym też z epitetami typu “posrało” – punkt widzenia zależy od punktu siedzenia. Gdybym powiedział samemu sobie sprzed dwóch lat jaką będę miał dziś stawkę godzinową, to bym wybuchł śmiechem w twarz 
$300 za godzinę jeszcze ujdzie. Stawki “freelancerskie” dla dobrych developerów w stanach to spokojnie $100 i wiecej za godzinę (pamiętajcie, że tam dobrzy developerzy zarabiają powyżej 100k rocznie, nierzadko pewnie sporo więcej, żeby mieć podobną pensję jako “contractor” stawka musi być odpowiednio wyższa, polecam różne posty o tym jak obliczyć swoją stawkę pracując jako freelancer). Dlatego rozumiem, że Obie, który nie dość, że jest znany, to jeszcze rozkręcił bardzo fajną firmę, może sobie tyle zażyczyć. Ale rzeczywiście z $10k to sporo przesadził. Ten hilton i deltę można nawet pominąć bo przy 10 tysiącach to mała część wydatków
UPDATE:
O, Tomash mnie ubiegł, tak to jest jak się robi 10 rzeczy pomiędzy pisaniem kolejnych zdań posta
Stawki naprawdę dobrych deweloperów są duże, w dodatku ludzie nie zdają sobie sprawy jak są takie rzeczy rozliczane.
Jak się rozliczasz po 20-30$ za godzinę to czy ktoś ci policzy godzinę czy dwie nie ma znaczenia. Jak bierzesz 200$ to ci ze stoperem czas mierzą. Nie wspominając że organizuje się to tak że wtedy cały zespół pracuje na takiego gościa żeby jak najwięcej się nauczyć w jak najkrótszym czasie.
Na sam koniec często płacisz 200 i człowiek ci w godzinę mówi co masz poprawić żeby zaoszczędzić zespołowi 4 osób tydzień pracy. Więc rachunek zysków do kosztów, każda firma sobie może przeliczyć.
A jak ktoś chce stosować stawki zaporowe - jego wola. Wolny rynek.
PS. Weźcie jeszcze pod uwagę, że gość liczy po 15 minut, więc można sobie kupić naprawdę skompresowaną wiedzę.
Notka Teda Dziuby pod którą mógłbym się podpisać. Tak, też jestem w szoku.
Polecam:
-
Najbardziej praktyczne przedstawienie wzorców projektowych jakie kiedykolwiek widziałem: http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns
-
Service Oriented Agony wujka Boba: http://blog.8thlight.com/uncle-bob/2012/02/01/Service-Oriented-Agony.html
Pierwszy link super.
Drugiego jeszcze nie otworzyłem, ale czy wujek Bob ostatnio nie przeskoczył rekina jednym wpisem? Sporo złej krwi było na Twitterze niedawno.
[quote=Tomash]Pierwszy link super.
Drugiego jeszcze nie otworzyłem, ale czy wujek Bob ostatnio nie przeskoczył rekina jednym wpisem? Sporo złej krwi było na Twitterze niedawno.[/quote]
Przeskoczył
Ale ten powyższy całkiem sensowny.
A co do przeskoczenia, to od razu opiszę Zobaczyłem któregoś dnia na twitterze inka do tego wpisu: http://blog.8thlight.com/uncle-bob/2012/01/31/The-Ruby-Colored-Box.html
TL;DR Odpowiedź na wpis programisty, który wkurzał się, że kazali mu klepać jakiś kod na tablicy. No i według Boba nie ma sensu sprawdzać w sieci dokonań pracownika, a klepanie kodu na tablicy podczas rozmowy o pracę jest bardzo fajne i pozwala odsiać pracowników, którzy się nie nadają (powiedziałbym, że pozwala tylko odsiać pracowników, którzy nie kojarzą akurat danego algorytmu i/lub stresują się w takich sytuacjach).
Wpis dość śmieszny, bo nie dość, że stwierdził “Any decent programmer can learn Ruby in a week.”, to jeszcze pokazał, że nie ma żadnego szacunku dla ludzi, których chce ciągnąć na rozmowę o pracę na miejscu: “Does this guy really think he’s so hot that I’m going to do research on him before I meet him?”. Nie wiem skąd ten rage, bo nawet jak pracownik jest początkujący, ale jest w jakiś sposób obecny w sieci, to naprawdę można sobie i jemu zaoszczędzić czasu.
A teraz najlepsze:
Jak czytałem ten wpis, to sobie myślę: no ok, ten koleś, o którym ten wpis powstał może trochę przesadza, może jest kiepski ogólnie i narzeka, że mu nie dali roboty, bo jest niezły w rubim, ale oprócz tego nic nie umie. I wtedy zobaczyłem, że chodzi o Toniego Arcieri, czyli kolesia, który napisał język skryptowy w Erlangu: http://reia-lang.org/ i który jest mastachem jeżeli chodzi o programowanie współbieżne, wystarczy zobaczyć jego ostatnie repozytoria: https://github.com/tarcieri Miałem okazję z nim pracować przez ponad pół roku i do tego dochodzi jeszcze kilka innych rzeczy typu clojure, czy dobra znajomość też niskopoziomowych rzeczy. Tak więc stwierdzanie, że to jakiś kolejny programista rubiego jest trochę nietrafione
Dodatkowo jest też keynote z rubyconfa chyba, którym się wiele osób zachwycało chociaż było tam strasznie dużo bezsensownych rzeczy. Np. że po strukturze plików powinno być widać co robi aplikacja Jakby mi ktoś zaczął wpieprzać wszystko w jakieś dziwne katalogi zamiast w app, to bym nie był wesoły - z dwojga złego wolę nie być w stanie powiedzieć co robi aplikacja po zobaczeniu katalogów (OJEJ!) niż zrezygnować z konwencji, które ułatwiają mi połapanie się gdzie co jest w projekcie.
Trochę pechowo wujkowi wyszło, że blog akurat na przykładzie Toniego Arcieri.
Ale ja tego bloga odczytuję inaczej. To jest zawołanie o pokorę wśród programistów, zwłaszcza railsowych. Niezależnie od stopnia ich zajebistości.
Pracodawca ma prawo mieć marny proces rekrutacji, bo jest klientem. Ciężar przedstawienia się od najlepszej strony zawsze spoczywa na programiście.
Oczywiście smutno jeśli pracodawca nie raczył nawet rzucić okiem na karierowe i githubowe dokonania, i trzeba cały marketing rozpoczynać od zera na białej tablicy i w obliczu niedopasowanych pytań. Ale pamiętajmy o rolach - to on jest klientem naszych usług. Nie robimy łaski.
W stwierdzeniu, że “po strukturze katalogów powinno być widać co robi aplikacja” nie widzę nic zdrożnego. Sprowadza się to mniej więcej do katalog-per-pakiet, plik-per-klasa, małe klasy robiące jedną rzecz, dobrze dobrane nazwy pakietów i klas, czyli samych oczywistości. Wszystko oczywiście w podkatalogach app zgodnie z railsową konwencją.
Dla równowagi we wszechświecie polecam: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html
Od siebie dodam jeszcze, że jeśli w którymś momencie i tak będziemy musieli przejść na rozproszoną architekturę systemu to warto od samego początku taką mieć. Rozbijanie monolitów na kawałki kiedy trzeba się skalować na wczoraj to nie jest najfajnieszy sposób spędzania czasu :). Zalety posiadania rozproszonego systemu (swoją drogą czy jak mam N instancji aplikacji ale one się nie komunikują ze sobą to mam rozproszony system czy nie? 
) jest to, że błędy nie powodują padu dla wszystkich użytkowników oraz fakt, że można deployować tylko na niektóre maszyny nowy kod i dopiero po pewnym czasie dystrybuować go wszędzie. Także nie wszystko jest takie czarno białe. Oczywiście monolityczne systemy są najłatwiejsze w utrzymaniu.
Dla równowagi we wszechświecie polecam: http://www.codinghorror.com/blog/2011/04/working-with-the-chaos-monkey.html[/quote]
+1
Ja ogólnie zgadzam się z tym, że Ci goście z wpisu Uncle Boba po prostu spieprzyli dzielenie (tzn. zamiast wydzielić konkretne funkcje systemu podzielili jego warstwy), ale nie do końca, że trzeba od SOA uciekać jak się da.
Bardzo fajny pomysł z tym Chaos Monkey
W stwierdzeniu, że “po strukturze katalogów powinno być widać co robi aplikacja” nie widzę nic zdrożnego. Sprowadza się to mniej więcej do katalog-per-pakiet, plik-per-klasa, małe klasy robiące jedną rzecz, dobrze dobrane nazwy pakietów i klas, czyli samych oczywistości. Wszystko oczywiście w podkatalogach app zgodnie z railsową konwencją.[/quote]
Spojrzałem szybko i jego zdanie to było: “Nothing at the top level (…) talks about what this application does”. Z tym, że warto tworzyć coś więcej niż tylko kontrolery i klasy dziedziczące po AR::Base się zgadzam, tylko moim zdaniem zupełnie nie o to mu chodziło.
Druga sprawa jest taka, że tego typu talki bez wsparcia przykładami mają moim zdaniem mały sens. Jest tam kilka stwierdzeń, z którymi się zgadzam i uważam, że warto się nad nimi zastanowić (np. “Database is a detail” albo “A good architecture allows major decisions to be deferred”), ale te schematy z Interactorami, Boundaries, Entities itp. itd. mają dla mnie małą wartość. Moim zdaniem przy pisaniu aplikacji najlepiej pójść na kompromis pomiędzy architekturą i wartością biznesową. Tzn. trzeba dbać o jakość i dobrą architekturę, ale pewne elementy można uprościć i nie być do końca “true”. Railsy to jest jedno wielkie uproszczenie tak naprawdę i o ile teraz widać dość duży ruch w stronę tego, żeby trochę poprawić architekturę aplikacji (presentery, domain driven design, objects on rails avdiego), to zawsze trzeba uważać, żeby nie pójść o ten jeden krok za daleko.
Niektóre rzeczy w aplikacji są proste i pozostaną proste. I w tym momencie nie ma żadnego sensu ich ruszać. Jeżeli w danym miejscu musimy dorzucić więcej kodu i przestaje to być już podręcznikowy najprostszy przypadek (typu jednolinijkowa prosta akcja w kontrolerze), to warto się tym miejscem zająć i refaktoryzować, inaczej zrobimy klasyczny przypadek “over engineering”.
W stwierdzeniu, że “po strukturze katalogów powinno być widać co robi aplikacja” nie widzę nic zdrożnego. Sprowadza się to mniej więcej do katalog-per-pakiet, plik-per-klasa, małe klasy robiące jedną rzecz, dobrze dobrane nazwy pakietów i klas, czyli samych oczywistości. Wszystko oczywiście w podkatalogach app zgodnie z railsową konwencją.[/quote]
Spojrzałem szybko i jego zdanie to było: “Nothing at the top level (…) talks about what this application does”. Z tym, że warto tworzyć coś więcej niż tylko kontrolery i klasy dziedziczące po AR::Base się zgadzam, tylko moim zdaniem zupełnie nie o to mu chodziło.[/quote]
Odnalazłem ten keynote ( http://www.youtube.com/watch?v=WpkDN78P884 ) i masz rację! On ma na myśli strukturę top level (1 i 2 poziom; jest nawet screenshot).
Ciekawe, ciekawe, słucham dalej…
…ok, to jest propozycja całkiem innej architektury aplikacji, bez większego związku z railsami, i niekoniecznie webowej => oczywiście nijak ma się to do railsowych konwencji.
Chętnie zobaczyłbym nietrywialną aplikację zbudowaną w ten sposób. Mam nadzieję, że ktoś podejmie się takiego eksperymentu. Na razie nie sposób się odnieść (np. czy na pewno warto, czy nie jest to przerost formy nad treścią?). Pewnie za 10 lat okaże się, że wujek Bob jak zwykle miał rację.
“Pechowo” tylko w sensie że jeszcze bardziej jaskrawo wyszło jakim wujek jest dupkiem? No weź.
Przeczytałem tę notkę i chyba nie chcę mieć do czynienia z innymi “mundrościami” tego typa. Szkoda, bo pamiętam że dawno temu zdarzało mu się mieć dobre teksty. Ot, co egotrip potrafi zrobić z ludźmi.
(Serio, zapraszać na rozmowę kandydata bez zriserczowania? Do takiego “luksusu” trzeba mieć totalnie w dupie czas – własny, zapraszanego kandydata i wszystkich pozostałych osób zaprzęgniętych do rekrutacji. Może wujek jest takim przeziomem że nie musi dbać o czas, natomiast wolę słuchać ludzi którzy jednak go cenią)
Piotrek, proszę Cię. Co takiego napisał wujek Bob że się po dekadzie okazało, że miał rację on, a nie wszyscy pozostali?
Patrz też biasy działające na korzyść “wróżbitów”: jeśli regularnie będziesz ssał z brudnego palucha niepodparte niczym przepowiednie i pomysły, to kilka Ci się sprawdzi. Ale to jest statystyka, a nie “manie racji” czy “wróżenie”.
Piotrek, proszę Cię. Co takiego napisał wujek Bob że się po dekadzie okazało, że miał rację on, a nie wszyscy pozostali?[/quote]
- TDD?
Wtedy było to bardzo kontrowersyjne, jeśli nie absurdalne, żeby najpierw pisać testy. A jeszcze, że to ma przyspieszyć projekt?!
- Że debugger to zło?
Wtedy wszyscy używaliśmy debuggerów. Takie stwierdzenie było obrazoburcze. Jak to przeczytałem - wiedząc jak bardzo debugger pomaga mi na codzień - to pomyślałem, że to jakiś chory ekstremista i się obraziłem na wujka na kilka lat. A teraz? Nie mogę sobie przypomnieć kiedy ostatnio używałem debuggera.
Jestem świadomy zjawiska confirmation bias (btw, świetnie wyjaśnia je Michael Shermer http://www.youtube.com/watch?v=8T_jwq9ph8k). Nie znaczy to, że jestem na nie odporny ale to już inna bajka
Bo TDD nie przyspiesza. Nie poprawia też jakości bardziej niż np. code review. Polecam nieliczne porządnie (grupy kontrolne itd.) przeprowadzone badania. Jeśli test-first ma jakąś wartość dodaną, to wymuszenie pisania testów (u wielu programistów nie do przecenienia) i minimalnego działającego designu (co nie zawsze jest najlepszym pomysłem). Także bez rewelacji. A uważanie tego za standard? Sorry. No cookie.
[quote=qertoip]* Że debugger to zło?
Wtedy wszyscy używaliśmy debuggerów. Takie stwierdzenie było obrazoburcze. Jak to przeczytałem - wiedząc jak bardzo debugger pomaga mi na codzień - to pomyślałem, że to jakiś chory ekstremista i się obraziłem na wójka na kilka lat. A teraz? Nie mogę sobie przypomnieć kiedy ostatnio używałem debuggera.[/quote]
Oczywiście gratuluję, ale bez debugera nie sposób się zabrać do bugów w cudzym kodzie. Może więc po prostu nie możesz sobie przypomnieć kiedy ostatnio pracowałeś z babolami w cudzym i/lub kiepsko otestowanym kodzie?
Znaczy, pogłoski o śmierci debuggera należy uznać za mocno przesadzone.