Staż/praktyka Ruby on Rails

Szukamy ludzi, którzy chcą się uczyć Ruby on Rails - studentów ale i programistów innych języków.

Wymagamy dobrej znajomości języka angielskiego, umiejętności szybkiego uczenia się i samodyscypliny.

Oferujemy ciekawe zadania programistyczne: rozwijanie dopasowanych do umiejętności projektów open source, udział w projektach komercyjnych.

Praktyki nie wymagają obecności osobistej i można wykonywać je zdalnie.

Głównym zyskiem wyniesionym z praktyki będzie dobra znajomość Ruby, frameworku Ruby on Rails, umiejętność pracy z git, Trac i innymi narzędziami często wykorzystywanymi w projektach. Po ukończeniu praktyk kandydat będzie miał wiedzę niezbędną, żeby być wartościowym członkiem zespołu z praktyczną znajomością Rails.

Osoby, które wykażą duże zaangażowanie i szybki rozwój otrzymają zapłatę za swoją pracę i mogą liczyć na długoterminowe zatrudnienie. Ci, którzy wykażą się konkretnymi umiejętnościami już na starcie i których kod będzie wartościowy (np. będą w stanie stworzyć gem rozwiązujący konkretny problem) otrzymają zapłatę w wysokości od 10 pln/h wzwyż.

Chętnych zapraszamy do naszego biura lub prosimy o mail na adres praktyki@ragnarson.com.

Ragnarson Łukasz Piestrzeniewicz
ul. Łąkowa 11
90-562 Łódź

Do stałych forumowiczów: mile widziane Wasze opinie na ten temat. Co warto jeszcze zawrzeć by przyciągnąć młodą krew?

Po pierwsze: fajnie, że w Łodzi :slight_smile:
Po drugie: nie podobają mi się bezpłatne praktyki jako takie, jak człowiek coś robi, to wypadałoby zapłacić, no chyba, że chodzi tam dla przyjemności tylko i patrzy w sufit. Ale oczywiście to tylko moja opinia, jak komuś takie praktyki odpowiadają, to OK.
Natomiast na serio nie podoba mi się coś innego, z tego co napisałeś (a mniemam, że to ino przejęzyczenie jakieś) wynika, że firma szuka kogoś kto będzie pracował, a potem może zapłaci, a może nie. Pracowałem już kiedyś w jednym miejscu na tych zasadach, narobiłem się jak głupi i nie zobaczyłem kasy za dwa tygodnie roboty. To może od razu jasne zasady, czyli: nie płacimy za pracę, a potem może będziecie mieli etat.

A odnośnie przyciągnięcia młodej krwi to się nie wypowiem (bo ja to ani młoda, ani krew - w żyłach mam raczej kawę), ale mogę powiedzieć jaka praca by mnie odpowiadała: ma być ciekawie, niebanalnie, część, albo całość pracy może być zrobiona zdalnie, w miarę elastyczne godziny pracy, praca z sensownymi i uczciwymi ludźmi, jasne zasady rozliczania a mój przełożony albo będzie nietechniczny, albo techniczny, ale wtedy powinien umieć więcej niż ja (chociaż w przypadku Railsów nie będzie to trudne). Do tego sensowne i płacone w terminie wynagrodzenie. Ogólnie ma być miło, uczciwie… no tak profesjonalnie.

Skoro nie chcecie płacić, to warto wspomnieć, że każdy kod opensource jest również zyskiem dla developera. Względnie napiszcie o takich aspektach jak wsparcie project managerów, możliwość nauczenia się efektywnego kożystania z różnych narzędzi np redmine (czy czego tam używacie), capistrano, git itp. Swoją drogą o wiele łatwiej znaleść kogoś na wakacje.

Też prawda, pytanie tylko czy będzie się firmie opłacało brać kogoś tylko na wakacje, ktoś się narobi i nic nie zarobi i się obrazi, albo będzie super, ale po wakacjach firma go straci, bo on ma inne zajęcia, a firma włożyła w niego sporo pracy.

Może z jednej strony napiszcie co taki człowiek może zyskać, czego się nauczyć itp. Z drugiej strony może jednak dać pewną kwotę od samego początku, nie na zasadzie pensji, ale bardziej zadaniowo, dla różnych ludzi motywacja jest różna, może po prostu ktoś potrzebuje trochę kasy i bardziej pójdzie tam gdzie mu zapłacą niż tam gdzie nie zapłacą. Osobiście bym wolał np. mieć od razu jasne warunki, nie że kasa będzie jak się komuś spodobam (może to wynika z moich wcześniejszych doświadczeń) ale kasa będzie jak zrobię to i tamto i jak będzie zrobione dobrze.

Cieszę się, że z bezpłatnej praktyki wyciągnąłeś naukę: wszystko omówić na początku bezpośrednio i umówić się na konkretne warunki :slight_smile:

Myślę też, że byłoby lepiej gdybyś tak skonstruował swoją wypowiedź by o tym przypomnieć potencjalnym praktykantom - ale nie starać się ich odstraszyć.

Umiejętności praktykantów są różne. Interesują mnie zarówno tacy, którzy chcą się po prostu nauczyć nowego języka jak i tacy, którzy już umieją to i owo i chcą potrenować w działającej firmie. Z tymi drugimi chętnie już w pierwszej rozmowie porozmawiam na temat ‘za ile’? Pierwsi muszą mi udowodnić, że jest sens prowadzić taką rozmowę - po kilkunastu poświęconych przez nich godzinach.

Pierwszych kilka albo i kilkanaście dni praktykanta to często jest tylko nauka i niemal zero efektu. Z naszej strony poświęcamy czas, żeby wiedzę przekazać, pokazać w którą stronę warto iść a co ominąć przy nauce. To kosztuje. W tym czasie zysk z praktykanta jest żaden. De facto praktykant dostaje w takim czasie sporo kasy - tyle, że całość idzie na koszt utrzymania nauczycieli.

Projekty są ciekawe. Dołączył do nas asok (znany z forum) i pracuje już nad nowym gemem, który zrewolucjonizuje podejście do helperów Rails. Kod jest dostępny na http://github.com/bragi/representations.

Czy w taki sam sposób zatrudniasz ludzi z doświadczeniem, a nie praktykantów, że muszą najpierw jakiś czas pracować charytatywnie? Przecież każdy kto przychodzi do nowej pracy czy nawet nowego zespołu musi się na początku uczyć i generuje zero dochodu dla firmy (i to bez względu na to jakie ma doświadczenie). To jak to tam u Ciebie jest, tak się pytam, bo naprawdę jestem tym szczerze zainteresowany.

Ja z mojej strony mogę napisać, że te praktyki są bardzo fajne. Z jednej strony mogę popracować w firmie, nauczyć się czegoś, poza tym projekt nad którym siedzę jest bardzo ciekawy. 10zł/h za praktyki to moim zdaniem uczciwa płaca. Poza tym rzeczywiście godziny pracy są bardzo elastyczne, można pracować cześciowo zdalnie, częściowo w biurze.

Chyba nieco przesadzasz. Sugerujesz, że jak zatrudnię programistę z 2-3 letnim doświadczeniem i początkującego, który 2 tygodnie wcześniej kupił Agile, a wcześniej klepał jakieś skrypciki w PHP, to będę miał z nich przez pierwsze tygodnie taki sam pożytek? :wink:

Nie, ale sugeruję, że przez kilka dni/tygodni z nowego programisty jest żaden pożytek, musi się wdrożyć w to co robi zespół, no chyba, że dasz mu całkiem nowe projekty. A poza tym tak tylko pytam, na praktyki i tak się nie wybiorę.

Nie uważam się za osobe bardzo zaawansowaną, ale SimonG prowokuje mnie do sprawdzenia w ile bym się wdrożył w którymś z zespołów Bragiego. :wink:

No comment.
Super podejscie do pracownika, gratsy, tak trzymaj i czekaj konca.

znaczy się to chyba raczej pozywne prowokowanie :slight_smile:

No comment.
Super podejscie do pracownika, gratsy, tak trzymaj i czekaj konca.[/quote]
Przepraszam… ale co to są/jest “gratsy”?

Twierdzenie dosyć odważne. Z przykładu i opisu, wnoszę, że idzie to na przekór konwencji MVC:
“Resource representations change syntax to object oriented and model specific.”

Można prosić o jakieś szersze uzasadnienie?

(Swoją drogą w przykładnie nie podoba mi się jeszcze jedna rzecz user = r(user) - user i user to dwie inne rzeczy - czy nie lepiej nadać im inne nazwy?)

Skoro apohllo rozpoczął offtopa.

Jest późno, ale spróbuję przeprowadzić mały dowód, który pomoże wychwycić błędy.

Na warsztat biorę przykład-sposób użycia:

[code=ruby]- user = r(user)

  • user.form do
    login:
    = user.login
    = user.email.label
    = user.email.text_field[/code]
  1. Założenia:
  • widok jest “głupi” (lub pasywny, jak kto woli), dostaje wszystkie zmienne z kontrolera i sam z siebie nie powinien tworzyć zmiennych lokalnych
  • model nie powinien tworzyć widoku

Przynajmniej jeśli chodzi o tworzenie formularzy (pomijam rozbudowane raporty) można się z tymi zaożeniami zgodzić :wink:

Na początku linie:

[code=ruby]- user = r(user)

  • user.form do[/code]
    Zgodnie z założeniem pierwszym należy unikać tworzenia zmiennych lokalnych (a tak się własnie dzieje).
    Można próbowac tworzyć moduł i rozszerzać nim model, ale jest to niezgodne z drugim założeniem, więc potraktuję to zdanie jako żart.

Drugim wyjściem jest zastosowanie bloku:

- r(user) do |user| = user.login = user.email
A na poważnie, domyslam się, co chcesz utworzyć. Jak rozmawialiśmy w biurze zasugerowałem użycie własnego form buildera i wciąż sądzę, że własny, dopieszczony form builder mógłby rozwiązać sprawę.

Twoją ideę chyba łapię, chcesz użyć refleksji na modelu, by generowac formularze; bardziej rozbudowany przykład mógłby wyglądać tak (już z uzyciem bloku):

[code=ruby]- bragi_form_for @invoice, :vertical do |invoice|
= invoice.seller
= invoice.customer
= invoice.date

  • invoice.lines(:horizontal) do |line|
    = line.product :combo
    = line.quantity
    = line.product.price :editable => false
    = invoice.total :editable => false[/code]
    To taki podgląd na szybko. Uważam jednak, że narazić się tu można na pewną nieelastyczność. Czasem w widoku w różny sposób chcemy reprezentować dane pole z modelu.
    Weźmy przypadek pola “sprzedawca”. Czasem chcemy reprezentować sprzedawcę pełną nazwą, a czasem tylko skrótem, albo pełnym adresem (w widoku - na przykład w polu kombo). Łatwiej powiedzieć chyba, że

wstawiamy do
formularza.pole_kombo ze_zrodlem_danych (tu chyba można nawet lambdę wstawić (?))
formularza.pole_tekstowe email

Jeśli chodiz o etykiety, można je pobierać z tłumaczeń i18n. Zrobiłem nawet swój prosty form builder oparty na, niestety tabelkach (obiecuję poprawić), ucząc się z przykładu na pragmatic.tv: http://pastie.org/646149

i przykładowe użycie:

- tabled_form_for user do |f| = f.text_field :user = f.password_field :password = f.submit
Faktycznie jest ty pewne ograniczneie co do obsługi relacji has_many (w form builderach) - przynajmniej jeszcze do tego nie dotarłem, ale rozwiązanie wydaje mi się logiczne

(Rano obiecuję przeczytać jeszcze raz to, co napisałem :wink: )

EDIT: tak, nadużywałem słowa “tworzyć” :wink: ale programownaie to taka twórcza praca :stuck_out_tongue:

Te rozważania na temat resource representations warto byłoby przenieść do innego wątku.

Natomiast co do powodów/pomysłu, dla którego to rozwiązanie ma być lepsze.

  1. Helpery nie obsługują namespaców - ale coś na ich kształt. Z założenia są związane z kontrolerami/widokami i można łatwo wybrać który zestaw helperów chcemy używać (w kontrolerze).

  2. Powiązanie helperów z modelami nie wydaje mi się dobrym pomysłem. Tym bardziej, że i tak tworzysz jakiś obiekt opakowujący… czy to będzie resource, czy form_builder, to chyba nie ma specjalnego znaczenia. Już prędzej spróbowałbym zmodyfikować implementację tych ostatnich,
    tak żeby były bardziej świadome przetwarzanego obiektu. Ale gdzieś przecież musisz określić, czy dane pole ma być wyświetlane jako text_field, czy może jako text_area. Wywołanie user.name przecież musi zostać jakoś obsłużone - gdzieś musi być “konfiguracja”. Gdzie? W jakimś helperze…

Zdecydowanie lepszym pomysłem wydaje mi się rozbudowanie tego co oferuje ActiveScaffold, gdzie określamy tylko, jakie pola mają być widoczne
i z automatu dostajemy domyślną reprezentację (np. dla daty - wybór daty). A jeśli chcemy coś zmienić, to tworzymy helper o odpowiedniej nazwie.
AS jest dodatkowo świadomy relacji pomiędzy modelami i np. możemy tworzyć, bez dodatkowego wysiłku, obiekty powiązane z danym obiektem.

Wysłałem maila w sprawie praktyk

[quote]Szef dostaje 100 Życiorysów. Bierze połowę i ciska do kosza.
Zaskoczona sekretarka pyta:
“Dlaczego? Przecież nawet pan nie rzucił okiem?!”
Szef na to:
“Nie potrzebujemy kandydatów, którzy mają pecha w życiu!”[/quote]
Tak mi się przypomniało jak wyciągałem Twojego maila ze spamu :slight_smile:

Twoja odpowiedz, nie wiedzieć czemu, też tam trafiła. Dziwne

Będzie Wam się doskonale pracować, spamerzy :smiley: