Parafrazując słowa Hitchcocka: dobry rok powinien się zacząć od trzęsienia ziemi, a potem napięcie musi stopniowo rosnąc… Wygląda więc na to, że nowo napoczęty rok ma szanse być naprawdę dobrym. Zaczął się w każdym razie od trzęsienia ziemi.
Przeczytaj cały wpis »
Dziś w webankiecie miał premierę nowy moduł pozwalający na zmianę wyglądu ankiety samodzielnie przez użytkownika. Projektując ten moduł doszedłem do wniosku, że aby dać prawdziwą moc w ręce ludu będę zmuszony stworzyć szereg małych edytorów pozwalających na zmianę parametrów poszczególnych atrybutów CSS. Dopiero te edytory mogą utworzyć coś co będzie można nazwać edytorem szablonów. Aby pokazać co mam na myśli mówiąc o edytorach oto rysunek z instrukcji prezentujący edytor dla obramowań:
Zadanie było o tyle ambitne, że zwykle rozwiązania szumnie nazywane edytorami szablonów sprowadzają się do możliwości zmiany kolorów tła (mam na myśli oczywiście rozwiązania w aplikacjach webowych). Planowane przeze mnie rozszerzenie interakcji użytkownika ze stroną wymagało dosyć rozważnego podejmowania decyzji dot. sposobu implementacji.
Na pierwszy ogień poszedł RJS, wkrótce jednak okazało się, że w tym przypadku jego zalety stają sie przekleństwem. Konieczność ‘konsultowania’ z serwerem każdej akcji wykonanej w UI przez użytkownika wiązała się z przesadnie wielką liczbą gadek klient-serwer, a w efekcie cały edytor sprawiał wrażenie niemrawego. Przy okazji sprawdziłem w praktyce, że przy bardziej skomplikowanych konstruktach RJS ma poważną wadę - wymaga ciągłego przełączania kontekstu mentalnego pomiędzy Ruby a JavaScript. Wydaje się, że helpery dostarczane przez railsy eliminują tą konieczność - praktyka pokazuje, że jednak nie. Gdy do tego dołożymy potrzebę sporej elastyczności na etapie projektowania interakcji (nie wszystko da się zasymulować na kartce papieru - czasem trzeba też poklikać) - RJS wypada niestety słabo.
Na czym stanęło? Na banalnie prostym podziale - niech każdy robi to na czym się zna najlepiej. Przeglądarka rysuje html do którego dopinane są JavaScriptowe kontrolery - razem tworząc żywe i reagujące na zmiany kontrolki. Poszczególnymi edytorami zarządza jeden główny kontroler, którego zasadniczym zadaniem jest wymiana danych z serwerem. Przez dane rozumiem tu już tylko gotowe informacje o parametrach szablonu, któresą przesyłane na serwer jako JSON. Serwer zajmuje się więc tylko zamianą otrzymanego JSONa na CSS (za pomocą zwykłego szablonu ERb). Takie naturalne rozdzielenie zakresu obowiązków spowodowało znaczne uproszczenie w pracy nad modułem - nie było potrzebne choćby ciągłe przełączanie kontekstów mentalnych :) Po przygotowaniu części serverside i otestowaniu generacji CSSa spokojnie mogłem przesiąść się na pracę tylko z częścią klienta.
A końcowy efekt? To największy spójny (w sensie poświęcony temu samemu zadaniu) fragment kodu w JavaScript jaki napisałem :) źródła mają w sumie ok. 120kB.
Jak mój wypasiony edytor szablonów działa w praktyce? Zapraszam do wersji demo webankiety.
[javascript rails webankieta]Z końcem września na oficjalnym blogu railsów pojawiła się informacja o nadchodzącej wersji 2.0. Przeskok od wersji 1.0 do 2.0 to zawsze jest trauma i dla projektu i dla jego użytkowników. O zmianach i ZMIANACH w railsach 2.0 mówiło się od jakiegoś czasu. Nie ma się co dziwić - projekt wyrósł z lokalnej anomalii do popularnego frameworka używanego przez wiele serwisów. Zmiany są więc konieczne zwłaszcza, gdy coraz częściej przebąkuje się o enterprajsowych zapędach RoR. Sam także miałem przygotowaną swoją prywatną listę oczekiwań wobec nowych railsów. Dopiero dziś miałem odrobinę czasu i zaległem w wannie, aby na spokojnie poczytać o tym co nadchodzi. Poczytałem i… przyznam trochę się rozczarowałem.
Przeczytaj cały wpis »
Uffffff. Dziś delirycznie wczesnym rankiem zakończył się konkurs railsrumble.com. Pomysł wzięcia w nim udziału rzucił na ostatnim Bootstrapie Witek, potem do dream teamu dołączyłem ja, Zbychu i Jarek. Tak powstała drużyna mocarzy o swojskiej nazwie ‘Świerszcze’ :)).
Założenia konkursu są proste: 48 godzin na napisanie dowolnej aplikacji railsowej, żadnych gotowych wcześniej fragmentów kodu, grafik itd, dozwolone korzystanie z pluginów. Konkurencja była spora, a najlepszy projekt zostanie wybrany głosami użytkowników.
Pomysł na naszą aplikację zrodził się jeszcze na Bootstrapie - zróbmy grę! Jaką? Hmm… Wiedzieliśmy tylko jedno - taką z jajem! Po uformowaniu się teamu w czasie burzy mózgów powstał Pomysł. Napiszemy managera startupów - nie takich zwykłych nudnych biznesów - ale czegoś więcej: startupów web2.0! Tak narodził się pomysł na StartupTycoon.
Co udało nam się wyprodukować w ciągu niecałych dwóch dni możecie zobaczyć sami, nasz killer-app jest dostępny pod adresem startup-tycoon.railsrumble.com. W imieniu całego zespołu zapraszam Cię do rejestracji, zostań osobą oceniającą i oddaj głos (od środy, 12 września od czwartku, 13 września) na jedyną (chyba) jedną z dwu aplikacji z Polski :)
Dzięki chłopaki za wspólną walkę z materią :) i napady głupawek po kilkunastu godzinach rytmicznego walenia w klawisze. Do następnego konkursu!
[game rails startup]W ostatni piątek firma Joyent na swoim blogu obwieściła, że otwiera kod swoich produktów dwóch Connector i Slingshot. Oba projekty dostały swoje miejsce na developerskim serwisie Joyent, a cały developerski świat dostęp do SVN ze źródłami. Nie muszę chyba specjalnie wyjaśniać jak ekscytującą dla każdego developera jest możliwość zapoznania się ze źródłami prawdziwej, sporej (aż chciałoby się powiedzieć enterprajsowej :)) aplikacji zwłaszcza napisanej w railsach. Sam z ogromną ciekawością pobrałem źródła Connectora i przyjrzałem się części z rozwiązań zastosowanych przez Joyent. Szczególnie byłem ciekaw jaka biblioteka została przez autorów wybrana do obsługi wersji językowych. Okazało się, że Connector korzysta ze starego dobrego Get Text (za pośrednictwem pluginu Ruby Get Text ), to odkrycie oszczędziło mi sporo czasu i utwierdziło mnie w przekonaniu, że spośród wszystkich dostępnych bibliotek warto jednak oprzeć się na tym sprawdzonym rozwiązaniu. Źródła Connectora zawierają jeszcze kilka ciekawych smaczków, ale nie będę psuł tu przyjemności samodzielnego ich odkrywania :)
Druga z otworzonych aplikacji ma szanse wywołać sporą rewolucję. Slingshot to rodzaj pomostu między webem a desktopem. Działa jako środowisko uruchomieniowe, które pozwala uruchomić aplikację railsową tak jakby była aplikacją dekstopową. Sami autorzy tak tłumaczą działanie Slingshota:
It provides a consistent and stable environment for a Rails application to run off Windows and Macintosh OS X. We remove all dependencies and conflicts with system binaries. Additionally, Joyent Slingshot allows developers to customize their environment as they please. Install any gems, plugins, binaries, whatever. We can handle it. Joyent Slingshot is like a virtual machine for a Rails application to run on.
Krótki screencast pokazujący jak w praktyce może wyglądać praca z tak ‘zainstalowaną’ aplikacją railsową robi niemałe wrażenie.
Podsumowując, dostaliśmy ciekawą okazję skonfrontowania swoich doświadczeń i umiejętności z kodem prawdziwej aplikacji. Aplikacji, która powstała z myślą o rozwiązywaniu realnych problemów i zarabianiu na tym pieniędzy, żaden tam 1001 quasi-engine blogowy czy inny prawie-sklep, tu jest prawdziwa krwista tkanka sporej aplikacji.
Zastanawiam się co skłoniło ludzi z Joent do takiego kroku. Nie chcę tu snuć spiskowych teorii, ale gdy przyjrzymy się stykowi open-source i biznesu dostrzeżemy raczej odwrotną tendencję. To raczej rokujące projekty OS dostają patronat/wsparcie komercyjne powoli wchodząc do portfolio produktów firm sponsorów. Czasem ten proces wychodzi na dobre sponsorowanym projektom, czasem następuję kanibalizacja i stopniowa śmierć projektu OS. Dużo rzadziej mamy do czynienia z sytuacją odwrotną, szczególnie gdy ma ona dotyczyć całego kompletnego komercyjnie stworzonego produktu nie komponentu / biblioteki. Tym bardziej warto docenić odwagę Joyent za tak śmiały i… trochę szalony krok.
[rails ruby]
