Drugiego marca 2010 miałem przyjemność dać krótką prezentacją na spotkaniu WRUG (Warsaw Ruby Users Group) dotyczącą technologii WebSockets i WebGL. Dzięki uprzejmości Czaka jest dostępne wideo z prezentacji:
Zamieszczam tu także slajdy i użyte przykłady:
Może to się robi już trochę nudne, ale znowu poszukujemy rąk (a przede wszystkim “ostrych” umysłów) do pracy. Wymagania są takie same jak zawsze: biegła znajomość Ruby i Ruby On Rails + solidne przygotowanie z zakresu SQL (pracujemy na Postgresie), XHTMLa i JavaScriptu. Do koordynacji pracy używamy Traca, Subversion i Jabbera, a więc dość powszechnego zestawu.
Praca jest zdalna, zespół młody i sympatyczny, a wynagrodzenie atrakcyjne :) Mile widzani studenci, możliwe zatrudnienie w wymiarze 20 lub 40 godzin tygodniowo. Zainteresowanych proszę o przesłanie CV w języku angielskim na adres:
Jakiś czas temu poświęciłem parę postów na anglojęzycznym stifflogu swojej konfiguracji środowiska pracy. Nie miałem jakoś wtedy wielkiej chęci żeby przełożyć te wpisy na polski, a jako że teraz potrzebuje czegoś niezbyt wyszukanego na ponowne blogowe rozruszanie, czas na zbiorcze wydanie opisujące dość dogłębnie zestaw oprogramowania, jakiego używam, podobne do wpisów ze StarychDobrychCzasów[tm]. Nie jest to dosłowne tłumaczenie, minęło dość czasu żebym kilka rzeczy w swoim ustawieniu pozmieniał, dodał i porobił nowe screeny pokazujące całość w akcji. Trąci niezdrowym lansem i genciarstwem, ale cóż, może kogoś jednak zainteresuje :)
Tak, kompiluje wszystkie pakiety ze źródeł. Nie interesuje mnie zbytnio szlifowanie flag do uzyskania 2% przyrostu wydajności, cenie sobie natomiast możliwość dokładnego dostosowania oprogramowania do swoich potrzeb (flagi USE), a przede wszystkim ilość wysokiej jakości i świeżości pakietów w Portage. Z innych dystrybucji, bardzo spodobał mi się Zenwalk, którego mam na laptopie. Całkiem możliwe, że gdyby np. padło mi teraz Gentoo, to zainstalowałbym właśnie Zenwalka , zamiast znowu kompilować system przez tydzień. Wprawdzie bogactwo pakietów jest dużo mniejsze, a właściwie to nie ma ich prawie wcale, ale za to całość jest prosta, domyślny zestaw programów bardzo sensowny, system jest gotowy do pracy praktycznie z marszu, działa WiFi, wszystko jest ładnie zintegrowane i w pewnym sensie “przystrojone”. Faktycznie jest w tej dystrybucji pewien powiew zen… Od bardziej pragmatycznej strony jest tym, czym powinien był stać się Slackware pewien czas temu (Zenwalk jest zreszta na nim oparty).
Podczas wczorajszego spotkania KRUG-u wygłosiłem króciutką prezentacje na temat wyżej wspomnianego BDD. Dla tych którzy nie mogli się stawić w zastępstwie naszykowałem krótki artykuł pokrywający się mniej więcej z jej treścią. Reszta może od razu przejść na koniec, pobrać “slajdy” które nie są slajdami, obejrzeć przykłady i przejrzeć dalsze zasoby. Może, ale nie musi, bo w artykule napisałem kilka rzeczy o których zapomniałem powiedzieć w prezentacji.
A więc cofnijmy się na chwilę do lat cirka abałt powiedzmy 1995-2000. OOP przeżywa prawdziwy boom (chociaż Smalltalk jest od kilkunastu lat na rynku), Sun ładuje kase w marketing Javy, powstają pierwsze design patterns, a dookoła kręcą się adwokaci Extreme Programming którzy też chcą zarobić trochę kasy - przy okazji jednak mają też kilka naprawdę niezłych pomysłow.
Po raz kolejny brakuje nam rąk do pracy. Sporo ludzi wydaje się mówić coś ala “nie ucz się Rails, kto cię w Polsce zatrudni…”, tymczasem syutacja wygląda na dokładnie odwrotną - mimo zapotrzebowania są olbrzymie problem ze znalezieniem kogoś kompetentnego. W każdym bądź razie oto nasze wymagania:
Niezbędna jest biegła znajomość angielskiego, niemieckiego zaś będzie dodatkowym atutem. Poprawna polszczyzna również mile widziana, ale sama w sobie nie wystarczy :-)
Narzędzia: Ruby (on Rails), PostgreSQL, JavaScript (AJAX), Subversion, Trac.
Praca zdalna, komunikacja w zespole przy pomocy poczty elektronicznej i IM (Jabber, Skype). Tylko pełny wymiar czasu, tzn. 40 godzin tygodniowo. Nie mniej i nie więcej :-)
Realizujemy kilka projektów webdwójkowych dla klientów z Europy Zachodniej. Nasze najnowsze dzieło to niemieckojęzyczny serwis dla pokerzystów.
Zainteresowany? Przyślij proszę CV w języku angielskim w formacie PDF na adres:
W pewne gorące, nudne popołudnie naszedł mnie _Pomysł_. Za pomocą publicznie dostępnych adresów e-mail zadałem 10 pytań kilkunastu programistom, których uważam za ludzi ciekawych i których szanuje. Wymyślaniu pytań poświęciłem jakieś 5 minut - o to właśnie chciałbym ich zapytać gdyby dane mi było porozmawiać z którymś z nich osobiście przez powiedzmy 10 minut i nie miałbym czasu na zastanowienie. Ostatnie dwa pytania nie mają nic wspólnego z programowaniem, to prostu coś, co lubie wiedzieć o każdym człowieku z którym rozmawiam, takie hobby. Nie wszyscy chcieli na nie odpowiadać, co zresztą niespecjalnie mnie dziwi. To był pierwszy “wywiad” jaki przyszło mi zrobić, więc popełniłem też pewne błędy, które ujawniły się kiedy wszyscy Ci ludzie zaczeli odpowiadać… Ale i tak dowiedziałem się kilku ciekawych rzeczy, więc było warto.
“Jeśli widziałem dalej niż inni, to dlatego, że stałem na ramionach gigantów.”– Isaac Newton
Witam wszystkich serdecznie w pierwszym polskim tutorialu Ruby On Rails. Dziś zaczniemy od spraw najbardziej podstawowych, w rzeczywistości nie dotkniemy nawet na chwilę samego przedmiotu naszych rozważań, lecz zajmiemy się za to czymś o wiele ważniejszym - fundamentalnymi ideami na których jest on zbudowany i bez których nie byłby tak genialny, jak moim zdaniem jest.
A więc, dlaczego kogoś wogóle miałby interesować Rails? Potencjalnych powodów jest wiele…
Ostatni odcinek zakończyliśmy w miarę już działającym programem. Niestety, daleko jest mu do funkcjonalności w stosunku do swojej długości, a w dodatku jest zabugowany. Dziś postaramy się doprowadzić do postaci, za którą nie będzie się trzeba wstydzić.
Efektem ostatniego odcinka jest ten podsumowujący listing. Zaimplementowaliśmy pewne podstawowe funkcje, poznaliśmy pewne “idiomy” Ruby’ego, ale wciąż nie bardzo jest co uruchamiać. Zaczniemy więc od wzięcia na tapetę klasy “Interfejs”:
class Interfejs
def initialize
@lista = ListaZadan.new
@lista.wczytaj
end
def start
puts "Lista zadan do zrobienia: "
puts "--------------------------"
@lista.zadania.each_index do |idx|
print "#{idx} "
@lista.zadania[idx].wyswietl
end
puts "--------------------------"
puts "Co chcesz zrobic? [ Wpisz odp. polecenie ]"
puts "dodaj - Dodaj nowe zadanie"
puts "usun - Usun istniejace zadanie"
puts "koniec - Koniec pracy"
end
end
W tej części będziemy chcieli przede wszystkim stworzyć główną pętle programu: wyświetlenie zadań do zrobienia i listy poleceń, pobranie polecenia od użytkownika, wykonanie go i rozpoczęcie całej pętli od początku (chyba że użytkownik wydał polecenie zakończenia pracy z programem).
Zgodnie z zapowiedzią, bierzemy się za praktyczne programowanie. Przez następne pare odcinków będziemy rozwijać prostą, konsolową aplikacje będącą czymś w rodzaju PIMa, z naciskiem na wsparcie dla GTD (pasujące do tematyki strony). W trakcie pisania programu zaczną nam oczywiście wypływać na powierzchnię pewne niezbędne sprawy o których dotąd nie mówiliśmy, tak więc po drodze poruszymy mnóstwo pobocznych aspektów Ruby’ego. Wszystko będzie się działo dość spontanicznie, nie mam napisanych 10 odcinków tutoriala do przodu, więc asekuracyjnie proszę o wyrozumiałość :)
Odpuścimy sobie GUI, bo jego pisanie jest nudne, pozatym pojawia się problem znalezienia crossplatformowej biblioteki, trzeba opisać jej instalcję… Nudy, nudy, nudy. Skupimy się na esencji, na logice programu. Jeśli ktoś chcę, może potem w ramach ćwiczeń dopisać GUI, nie powinno być to szczególnie trudne.