Co waszym zdaniem zwykle jest najsłabszą stroną osób aplikujących o pracę? Czego im zwykle brakuje, niekoniecznie na tyle by ich nie zatrudnić, ale na tyle, że chcielibyście aby byli w tej dziedzinie bardziej biegli? Co uważacie za pochodne do rails technologie i umiejętności, które powinno się znać? Css, js, tdd? Osobiście wydaje mi się patrząc na ogłoszenia, że często szuka się osoby, która oprócz znajomości Rails (oczywiste) zna się także na tej stronie frontendowej bardziej niż backendowej. Nie wszyscy to lubią, niektórzy dużo lepiej się czują operując raczej na poziomie M-C niż C-V w modelu MVC. Mam małą nadzieję, że te pytania staną się zalążkiem do małej dyskusji o tym jakich programistów Rails wyróżniamy i w czym się powinni specjalizować oraz w jakim kierunku rozwijać po godzinach w pracy.
TDD - jak ktos by do mnie przyslal papiery i udowodnil, ze pisze testy to wielki plus
OOP - wielu nie pisze obiektowo tworzac jakies potworki z pomieszana logika itp.
BDD - Burdel Driven Development, wielu, ktorzy wyrosli na projekcie - fucha, olewa pisanie ladnie na korzysc pisania skutecznie. Czytanie i utrzymanie ich kodu to masakra jakas.
- Portfolio w postaci konta na Github - działa lepiej niż CV
- Praktyczna umiejętność testowania w oparciu o RSpec i cucumber (i potwierdzające to commits na Github)
- Dobra znajomość MVC i umiejętność skutecznego umieszczenia każdego kawałka programu w jednym z tych działów bez ‘przelewania’ w pozostałe
- Haml
- Sass/compass
- jQuery i non-obtrusive JavaScript
- REST
- Znajomość nowinek technologicznych, może być teoretyczna
- Jeden szczególny konik, w którym jest się naprawdę dobrym: bazy NoSQL, mocks, praktyka jako ScrumMaster, kanban, język D, serwery WWW, chmura
- Brak specjalizacji - większość zespołów Railsowych ma do 9 osób, w takiej grupie specjalizacja jest mało praktyczna. Oznacza to, że trzeba być wystarczająco dobrym w M, C i V.
Moim zdaniem w każdym projekcie powinien być jakiś frontend developer. Ale to już temat na kolejną długą dyskusję.
A stare dobre C nie wystarczy ? Kurcze, ledwo człowiek załapie o co chodzi w C i zacznie extensiona pisać a tu już wymagają D 
Masz rację. To jednak tak legendarne bestie, że jednorożce znają je tylko z opowiadań 
Ja nie do końca się zgodzę z praktyką jako Scrum Master - szukamy w końcu programisty a nie kogoś od miekkich skilli. Jestem prawie pewień że większość gwiazd ze świata ruby nie ma prktyki jak Scrum Master bo po co im to? Oni mają umieć programować a nie zarządzać ludzmi którzy to robią.
Można by ewentualnie zmienić ten punkt na “umiejętność pracy w Scrumie” ale napewno nie praktyka jako Scrum Master.
Tak samo z językiem D. Ja nie znam, ba w C nie wiele co pisałem, to nie znaczy że jest się gorszym, bo może taka osoba jest wymiataczem w Erlangu i do pary z Rubym zrobi takie cuda na kiju że głowa mała. Ten punkt zmienił bym po prostu na doświadczenie w innych językach i tyle. Szufladkowanie do jednego konkretnego jest moim zdaniem bez sensu.
W idealnym zespole taka umiejętność jest bardzo przydatna - nikt nie poprowadzi projektu tak, jak programista, który bardzo dobrze zna wykorzystywaną technologię. Dodatkowo, znajomość sposobu pracy każdego z członków zespołu i dostosowanie się do niego, to dodatkowa zaleta. A jak jest kilku programistów z umiejętnościami scrumowymi, to w kolejnych projektach mogą się zmieniać na miejscu prowadzącego.
Zauważyłem w paru zachodnich ogłoszeniach wymagania umiejętności rozmowy z klientem, więc pewnie za jakiś czas stanie się to normą w ogłoszeniach o pracę ‘pierwszej kategorii’.
Bragi się tu trochę puścił poręczy ale chyba po prostu chodzi o znajomość jakiegoś nowoczesnego i ciekawego języka, którego wiadomo, że nauczyłeś się samemu z pasji, a nie wcisnęli w Ciebie na siłę na uczelni czy w pracy (z tej samej rodziny np. Clojure, Erlang, Go, node.js).
(node.js wpisałem obok języków, bo nawet dla wymiataczy w JS jest to wuchta nowego API, spora zmiana w myśleniu i niezły skok technologiczny względem “przeglądarkowego” javascriptu)
Co do Githuba: chyba trochę umiem ogóra, pomimo tego na moim githubie nie ma go ani linijki.
Dlaczego? Bo nie ma tam ani jednego mojego projektu w Railsach.
Dlaczego? Bo nie chcę (kwestie biznesowe) / nie potrzebuję pomocy w ich pisaniu. Oraz nie od dziś wiadomo, że na githubie lepiej “chodzą” (followers, forks, pomoc itd.) projekty mniejsze i ciekawsze niż kolejny startap.
Także nie przesadzałbym z tą miarodajnością Githuba.
A odpowiadając na pytanie postawione w oryginalnym poście: najsłabszą stroną jest brak pasji i parcia do samorozwoju. Jeśli to jest, to wszystkie inne braki będzie nietrudno wypełnić już w pracy
Ok, nie będę się już przyczepiał do node.js ale co do reszty owszem.
[quote]Co do Githuba: chyba trochę umiem ogóra, pomimo tego na moim githubie nie ma go ani linijki.
Dlaczego? Bo nie ma tam ani jednego mojego projektu w Railsach.
Dlaczego? Bo nie chcę (kwestie biznesowe) / nie potrzebuję pomocy w ich pisaniu. Oraz nie od dziś wiadomo, że na githubie lepiej “chodzą” (followers, forks, pomoc itd.) projekty mniejsze i ciekawsze niż kolejny startap.[/quote]
Kompletnie nie rozumiem tych argumentów.
Nie używasz cucumbera w projektach dlatego że nie są to Railsowe rzeczy jest słabym argumentem. Cucumber to nie jest fw do testowania tylko aplikacji railsowych, zresztą - osobiście kupiłeś RSpec booka i wiesz co tam było testowane Cucumberem. Ty poprostu nie masz żadnych scenariuszy bo są to jakieś liby do których się nie pisze scenariuszy za to powinny być testy w TestUnit lub Specu lub czym innym…
Ale właśnie to co przedstawiłeś pokazuje jak Github jest miarodajny Wchodząc na Twój profil można zobaczyć jakieś pluginy, rubiowe liby, aplikację w Grailsach oraz coś z D. Co można z tego wydedukować? To że nie jesteś pierwszym lepszym gościem który dorwał AWDwR klepnął kilka scaffoldów i jest “programistą Rails” a nawet nie zna Rubiego, masz plugin do railsów, masz projekty w innych językach czyli spełniasz te wymagania o których mniej więcej pisał Bragi oraz Ty tutaj:
W D narazie więcej chyba pasjonatów niż zawodowych programistów (chociaż moge się mylić )
Pasja i parcie do samorozwoju - to jest najważniejsze.
Idąc tokiem myślenia z the RSpec book to owszem, można wszystko testować Cucumberem. Tylko że jakoś mi mordę wykrzywiało jak czytałem o pisaniu ogóra do tekstowej gry w kolorowe groszki
Ale właśnie – Cucumber to tylko jedno z narzędzi! Jeśli trafię na profil gościa, który będzie miał biblioteki, pluginy i skrypty – i zobaczę, że ma je po prostu pokryte testami, choćby i w Test::Unit – to będzie świadectwo bardzo dobrej (solidnej, nowoczesnej itd.) kultury programowania. I to wystarczy. A już konkretne narzędzie (Cucumber, Shoulda, RSpec itd.) to detal, którego łatwo nauczyć.