Jarmark.org

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.

Nie wiem czy web2.0 się już zestarzało i odeszło (zgodnie z sugestywną prezentacją Marcina na ostatnim bootstrapie), czy też dopiero wchodzi w wiek nastoletni. Faktem jest, że wraz z wysypem serwisów ometkowanych jako webdwazerowe pojawiła się także moda na udostępnianie funkcjonalności serwisu lub jej części przez API. Krok ten dla większości serwisów to bardziej próba wykorzystania potencjału developerów żyjących gdzieś tam hen, hen w fałdach długiego ogona niż decyzja podyktowana realnymi potrzebami klientów/użytkowników serwisu, ale zjawisko przybiera na sile. Nie jest to w żadnym razie krytyka z mojej strony - raczej obserwacja. Trudno nie zauważyć, że ta moda na API umożliwiła powstanie wielu serwisów nadających nowe znaczeniu słowu ‘integracja’. Inna sprawa, że przytłaczająca większość tych serwisów nie prezentuje zbyt wielkiej wartości nawet jako oprogramowanie - nie mówiąc już o biznesie. Właśnie ten ostatni aspekt zainteresował mnie szczególnie.
Przejrzałem API kilkunastu serwisów (oraz warunki korzystania z nich) zastanawiając się czy twórcy serwisów starają się budować jakieś przychody związane z korzystaniem z API, czy tylko jest to objaw swoistego developerskiego ekshibicjonizmu :)
Przeczytaj cały wpis »

Korzystanie z Google Docs stało się już dla mnie codziennością. Większość dokumentów, które przygotowuję piszę w edytorze z docsów. Narzędzie to jest całkiem sprawne, ma swoje dziwactwa, ale to niewielka cena za edytor z możliwością pracy grupowej nad dokumentem i wersjonowaniem wyników pracy. Ale… apetyt rośnie w miarę jedzenia - niemal od początku brakuje mi możliwości stylizowania tworzonego dokumentu za pomocą własnych arkuszy CSS.

Czy taki feature ma sens praktyczny? Myślę, że tak - dodając własny CSS do tworzonego dokumentu przekształcamy Google Docs w prawdziwie internetowy edytor WYSIWYG nie poświęcając niczego z jego pierwotnej funkcjonalności. Jest to szczególnie przydatne przy korzystaniu z GD jako edytora dla CMS czy bloga. Tak, tak wiem, że istnieje TinyMCE czy FCKeditor - GD daje jednak znacznie większe możliwości out-of-box.

Sposobu na realizację swojego pomysłu początkowo szukałem w API udostępnionych przez Google, niestety póki co rozwijane jest tylko API dla Google Spreadsheet - ta droga okazała się więc ślepym zaułkiem. Drugim pomysłem na rozwiązanie problemu było skorzystanie z Greasemonkey. Tym razem wkroczyłem na drogę która okazała się być szeroką, równą i prostą jak, nie przymierzając, nasze autostrady na Euro2112^*…

Przeczytaj cały wpis »