Cześć
Za jakieś pół roku będę szukać pracy jako programista rails, dlatego cały czas staram się poznawać Railsy i technologie pokrewne jak najlepiej, i tu powstaje moje pytanie.
Co wypadałoby, żebym dobrze poznał zanim zacznę szukać prace. Jakie technologie, gemy, techniki, itd. to taka podstawa bez której nie mam się co pokazywać?
Z góry dziękuje za wszelkie podpowiedzi
Pozdrawiam
Ruby, Rails, Git, conieco odnośnie baz danych. Do tego przyda się haml/sass + jquery.
Gemów nie ma sensu jakoś specjalnie poznawać - i tak w każdym projekcie będziesz korzystał z innego zestawu, poza tym jak chcesz pracować jako programista to musisz mieć otwarty umysł na zmiany i chęć nauki czegoś nowego.
Poza tym jest moim zdaniem zasadnicza różnica czy szuaksz pracy jako młodszy programista, który otrzymuje zlecenie od swoich starszych kolegów co ma być zrobione, a jako starszy, gdzie to Ty często musisz podejować decyzje będące ciut z dala od takiego stricte programowania.
Pytanie jest źle postawione.
Powinno brzmieć: co powinien umieć programista Rails.
A powinien na pewno umieć:
A podział na “młodszych” i “starszych” programistów (i jeszcze pewnie “architektów”) is soooooooo waterfall. 
nieno, Tomash, nie powiesz mi, że świeżak który dopiero co trafia do firmy nie powinien mieć jakiegoś “opiekuna” który będzie miał decydujące zdanie na temat tego jak coś trzeba napisać. Nie mówiąc już o sporo większym doświadczeniu (i rozległości wiedzy starszego programisty) względem młodszego - ogólnie chodzi mi o rozdział kompetencji, a nazywanie tego młodszy/starszy czy jakikolwiek inny sposób imo ma trzeciorzędne znaczenie.
Byłbym dziś o wiele słabszy gdybym nie pytał i nie słuchał “młodszych” programistów, ich pomysłów i opinii. I nie wdrażał w życie tych celnych czy dobrze uzasadnionych.
“Decydujące zdanie” czy “leader technologiczny” nie oznacza, że można olać wiedzę osób mniej doświadczonych. To nie liceum, gdzie pan magister mówi, a uczniowe notują w kajecikach. Jasne, że weteran przeżył więcej i o wiele lepiej sobie poradzi w sytuacjach które już przeszedł, ale to młokos pokaże mu nowe pomysły i technologie.
A bzdurne to nazewnictwo jest z jeszcze jednego względu: mówimy o społeczności programistów Ruby, wśród których praktycznie nie ma osób powyżej trzydziestki (z wyjątkiem Bragiego, no ale to emeryt ). Banda dwudziestoparolatków roztrząsająca kto jest “starszym”, a kto “młodszym” programistą, musi z zewnątrz wyglądać zajebiście śmiesznie 
Chciałbym, Tomash, chciałbym już być emerytem 
Niestety na razie musiałem odpuścić programowanie i zająć się pracą kreatywną (znaczy: definiowanie serwisu, btw: dostałeś już zaproszenie?)
W naszej firmie każdy wnosi coś nowego, włącznie z praktykantami. Ale wiesz, że zatrudniam tylko ludzi, którzy coś ROBIĄ. Podstawowa wiedza jest dostępna w sieci: DRY, KISS, testy, fat model/thin controller i do przodu. Reszta - to praktyka.
Gdy nowy człowiek przychodzi do pracy to na dzień dobry dostaje dwa zadania: zapoznaj się z ludźmi i zrób konkretny ticket dla klienta. Nie ma znaczenia czy ticket jest prosty czy trudny - z resztą najlepiej wychodzą trudne, przekrojowe zadania. Rzucamy świerzych na głęboką wodę i oczekujemy, że sami spytają się reszty teamu czy dobrze robią. Osobna sprawa, że przynajmniej jedną (a czasem więcej) rzeczy schrzanią. Wtedy wystarczy wytłumaczyć jaka byłaby lepsze droga i dać czas na refaktoring przy okazji następnego ticketu. No i weź wywal to co napisałeś, przecież jest gotowa biblioteka, która robi to lepiej
Morał dla ludzi, którzy dopiero startują w Rails: mniej martwcie się co powinniście wiedzieć a więcej o zdobycie praktyki. Weźcie udział w projekcie Open Source. Zaimplementujcie własny pomysł i trzymajcie go na Githubie. Dwa dni spędzone nad wykonaniem zadania uczą szybciej niż przeczytanie całej książki. Pamiętajcie, że NIH jest zły i starajcie się wykorzystać zewnętrzną bibliotekę do rozwiązania każdego problemu zanim napiszecie linijkę kodu. Testy jednak na wszelki wypadek napiszcie wcześniej
Język angielski, resztę doczyta to nie Rocket Science 
Zależy, w której firmie. W niektórych, computer science + software craftsmanship. Czyli przede wszystkim technologiczny kręgosłup.
Ja od siebie polecę e-booka Getting Real. IMO jest to pozycja podstawowa zanim zabierzesz się za pisanie jakiejkolwiek aplikacji.