Jak zaczac przygode z Ruby on Rails

Ostatnia pozycja to niezły oldschool.

Lynda.com opowiada wszystko szczegółowo (w sensie opisywania jak działa przeglądarka, przekierowania itp., chociaż na początku twierdzą, że jeżeli chcesz uczyć się RoR to musisz posiadać tą wiedzę :D) i monotonnie. Jeżeli jeszcze nie ruszyłeś Railsów to się z tego coś nauczysz, ale jeżeli już masz jakieś podstawy to nie będzie chciało Ci się przy tym siedzieć. Ogólnie to wygląda jak Rails Guides na wideo. 6 minut gadania i 10 sekund na kod. Polecam do spania (włączasz i śpisz w momencie, przyda się do książki o RoR 2.1 na zimę). Plusem jest to, że poprzez naukę różnych elementów frameworka tworzysz od razu aplikację, a nie musisz składać jej z tekstowych guides czy innych darmowych tutoriali (ale jak koledzy twierdzą, z video udało im się zrobić, ale jak zaczęli coś samodzielnie pisać to i tak do guides i dokumentacji wracali bo nie potrafili zapamiętać z filmu nic). Po za tym denerwujące są te slajdy jak przez 5 minut patrzysz się na białe tło, 4 wyrazy i nic się specjalnego nie dzieje :stuck_out_tongue:

Jak programowałeś wcześniej strony to nie polecam (znajdziesz to samo za darmo), chociaż nie którzy wolą słuchać 6 minut nt. jak to wspaniale generuje się linki w Railsach, a inni wolą przeczytać na czym to polega i po 20 sekundach się tym rozkoszować :wink:

Czyli spokojnie mogę oddać książkę pana Zabiełło do biblioteki. A powiedźcie mi czy warto szukać Agile Web Development with Rails Edition 4 czy wystarczy trzecia edycja?

Gdybym teraz mial zaczynac od 0 to zrobilbym to w takiej kolejnosci:



http://ruby.learncodethehardway.org/book/

Po trzech pierwszych linkach najlepiej znalezc jakis realny problem i probowac go rozwiazac - nic tak dobrze nie uczy jak praktyka, tylko trzeba zaczac od malych rzeczy zeby sie nie zniechecac brakiem sukcesow.

Oprocz tego, bardzo duzo daje przegladanie kodu popularnych gemow na GitHubie.

A jezeli chodzi o ksiazki to lepiej poczytac biografie kogos z IT. :wink:

Jak Wam się wydaje, w jakim stopniu należy opanować RoR’a tak aby ubiegać się o praktykę w firmie? Co na pewno trzeba umieć, żeby to miało jakiś sens? Ruby on Rails wciągnął mnie i chcę go naprawdę solidnie opanować.

Jeden prosty, hobbystyczny projekt. Ale taki od początku do końca: rozpoczęcie aplikacji, dobór gemów, deployment.

I najlepiej, żeby można było poklikać. To też dużo mówi, np. ja mam syndrom porzucania projektów, przez co bardzo mało rzeczy doprowadzam do końca. Dlatego jeżeli ktoś oprócz tego, że coś napisał, doprowadził to do działającej w sieci formy, to dla mnie duży plus.

No i jeszcze jakby aplikacja była otestowana, nawet najprostsze test unity, kilka integracyjnych, żeby było widać, że wiesz o co chodzi. Na początku takie rzeczy często się olewa, ale jeśli się do tego przyłożysz, to powinno to znaleźć uznanie osoby przeglądającej taki kod.

Jak tylko uporam się z inżynierką to wrzucę projekcik. Będę liczył na surową ocenę doświadczonych programistów :wink:

Czasami się o oczywistościach zapomina :slight_smile:

Taka historyjka dla ludzi, którzy będą szukać pracy. Szukałem jakiś czas temu programisty. Wszystkich kandydatów prosiłem o przesłanie jakiegoś kawałka swojego kodu albo linka do githuba do jakiegoś swojego projektu. Dostałem od jednego z kandydatów w miarę standardowy kod railsów (jakiś model) bez testów. Poprosiłem o testy i wtedy kandydat napisał, że nie ma do tego testów, bo u nich w pracy się nie testuje, bo to im lepiej wychodzi biznesowo. Nie chcę oceniać tego co u kogo działa, przy bardzo małych i prostych projektach prowadzonych w bardzo małych teamach może to ma jakiś sens. Kłopot w tym, że w większości innych miejsc, sensu to nie ma, więc jeżeli pracujecie gdzieś gdzie się nie testuje przez długi czas, to później przesiadka w fajniejsze miejsce może być ciężka.

imho ten temat wymaga lekkiego ogarnięcia.
1 post zawiera przestarzałe informacje na temat tutoriali. :stuck_out_tongue:

+1. Jeśli nie testuje się w pracy, to trzeba testować po godzinach (najlepiej na kodzie z pracy to wszyscy zyskują). Inaczej ciężko później wrócić do dobrych nawyków a jeszcze ciężej nadążyć za tymi wszystkimi gemami do testowania.

  • praca po godzinach
  • praca “zawodowa” za darmo

Świetna recepta na wypalenie, nic więcej.

Tomashu, oczywiście łatwiej zmienić pracę no nie ale jak zmienić jeśli jesteś w pracy gdzie nie testują a wszyscy wokół wymagają testowania i nie chcą Cie przyjąć ? Paragraf 22 ? Pozostaje Ci kodzenie po godzinach by podszlifować swoje umiejętności prawda ? Możesz to robić na hobbistycznym projekcie, ale wtedy musisz wymyślać całą resztę a możesz na kodzie z pracy gdzie właśnie tylko testów brakuje i możesz skupić się tylko na tym by szybko podszkolić tą umiejętność, której Ci brakuje by zmienić pracę. Efekty mogą być dwa: Nauczysz się testować i odejdziesz albo w twojej pracy docenią testy i będziesz mógł kontynuować swoją naukę bez konieczności spalania się w domu.

Ja zawsze uczyłem się na hobbistycznych projektach, ale to chyba kwestia podejścia :wink: Jak ktoś lubi na projekcie z pracy, to jego sprawa.

Rynek pracy programistów Ruby jest tak bardzo przesunięty w stronę pracownika, że szkoda życia na pieprzenie się w firmie operującej na antywzorcach (bądźmy szczerzy, brak kultury testowania jest zazwyczaj najmniej upierdliwym antywzorcem).

Nie słyszałem też o firmie która by na etapie rekrutacji odrzuciła kogoś za tekst “nie umiem testować, bo w poprzedniej firmie nikt tego nie chciał robić, ale ja bardzo chciałem, dlatego odszedłem i szukam fajniejszego miejsca pracy”. Więc nie, nie kupuję tego z Paragrafem 22.
Nawet jeszcze anecdata: podczas ostatniej rekrutacji nie pytaliśmy (W OGÓLE) o testowanie. Głównie dlatego, że w projekcie pokrycie testami każdego nowego kodu jest obowiązkiem i zawsze jest na to czas. Więc siłą rzeczy nowy programista będzie zmuszony nauczyć się testowania, tak jak się będzie musiał nauczyć innych gemów użytych w projekcie. Jeśli się okaże że pisanie testów sprawia mu ból i tego organicznie nie lubi (protip: dobry test suite właściwie to wyklucza, oglądanie zielonych kropek bardzo pozytywnie uzależnia), to po prostu się z nim rozstaniemy.

I owszem, zasuwać hobbystycznie po godzinach trzeba jeśli chce się być na bieżąco. I skoro już to robić, to o wiele lepiej stworzyć jakąś wartość dla siebie (choćby i dla nazwiska/reputacji, a może też spróbować siły z jakimś startupem na boku) niż dla swojego pracodawcy i za darmo.
(zwłaszcza że on na pewno sprzeda te testy klientowi)

Teraz mi przyszło jeszcze do głowy, że własny projekt jest lepszy bo można na nim red, green, refactor wypróbować a przy dopisywaniu testów do już istniejącej implementacji nie ma się tego komfortu.

Niekoniecznie moim zdaniem. Rozmawiałem z agencją reklamową, która używa Rails i tam często czas życia projektów jest tak krótki (3 miesiące), że faktycznie biznesowo bardziej może im się opłacać nie pisać testów. Ja pracuję praktycznie w samych projektach długoterminowych i widzę w nich zysk z testów. Może gdybym robił inne projekty miałbym inne podejście. Zwłascza projekt, który kilka lat w Railsach jest robiony dużo mnie nauczył dlaczego warto. Ale czy to znaczy, że w firmie wszystko jest źle tylko dlatego, że przyjmują takie a nie inne zlecenia. Nie byłbym taki pewien. Może to całkiem spoko miejsce pracy.

Chyba nawet wiem z którą agencją rozmawiałeś :wink:
Jasne, przy małych projektach testy się nie opłacają. Przy okazji masz też ciasne dedlajny (“projekt opłaci się firmie tylko jeśli zamkniemy go w miesiąc”) i ograniczone możliwości nabycia doświadczenia z technologiami i rozwiązaniami sensownymi tylko przy średnich i dużych projektach (strategie cache’owania, wieloserwerowy deployment itd.).
A agencje reklamowe/medialne/interaktywne zazwyczaj świetnie pasują do mojej uwagi o antywzorcach.

Cześć
Panowie dopiero zaczynam swoją przygode z ROR i aby było ciekawiej utknołem na etapie konfiguracji ROR i mysql na windows 7 64 bit . Mam pytanie czy ktoś z was będzie wstanie mi pomóc postaram się jakoś odwdzieczyć. Najlepiej jeżeli byłaby to osoba z Krakowa ;).