Ubuntu - to już dla mnie zbyt wiele

Moje używanie linuksa to najświeższe Ubuntu na beztrosko uruchomionym VirtualBox pod kontrolą radośnie działającego Windows 7 :) Dlaczego? Wygoda - nie muszę restartować komputera gdy zmieniam system, pełna kompatybilność sprzętowa - sprzęt nadal obsługuje Windows, który ma do niego dedykowane sterowniki nie zaś Linuks, który ich nie posiada i przez to nie mogłem np. wyłączyć głośników w Laptopie. Te dwa powody skłaniają mnie do korzystania z VirtualBox, ale co z dystrybucją?

Ubuntu zmienia się z roku na rok. Dzisiaj przeczytałem listę zmian Ubuntu 10.10 RC. Powiem krótko - nie interesuje mnie większość z nich. Oczywiście - nie uważam, że są złe. Moje użytkowanie Linuksa to ostatnio czysta deweloperka: Google Chrome, Vim, SSH, SCP, Ruby, Python, PHP - koniec. Najczęściej uruchamianym przeze mnie programem jest Terminal, w drugiej kolejności Google Chrome.

Wszystko co dla mnie jest fajne w nowej wersji systemu to nowe wersje programu. Wiem, że Canonical od dawna pracuje nad user-friendly systemu i dobrze im to wychodzi jednak dla mnie zmiany zachodzą w miejscach systemu, których w ogóle nie używam. Co rzutuje na moją pracę?

Chyba największą zmiana dla mnie jest nowa wersja oprogramowania, z mniejszą ilością bugów i nowymi featurami. Gdyby więc mieć tylko system, który cały ewoluuje na zasadzie apt-get update && apt-get upgrade to dla mnie to rozwiązanie byłoby idealne.

Minimalna dystrybucja - to był mój pierwszy pomysł. Debian w wersji base z doinstalowanymi paczkami, których wymagam. Z drugiej strony kiedyś już tak żyłem i Ubuntu okazało się o tyle lepsze, że gdy potrzebowałem czegoś "nagle" nieprzewidzianie to w Ubuntu już to miałem - w Debianie musiałem czekać aż się zainstaluje. Tak więc odchudzona wersja Ubuntu byłaby super. Na tyle obszerna aby miała już wiele rzeczy zainstalowanych, na tyle lekka aby nie przycinała VirtualBoxa. Jednak w międzyczasie wpadł mi do głowy inny pomysł - ChromeOS.

ChromeOS może okazać się "świętym gralem" dla osoby z moimi wymaganiami. Jest Google Chrome, jest konsola - cóż więcej mi trzeba? Oczywiście pod warunkiem, że będzie działał na VirtualBox - co się wkrótce okaże. Na pewno spróbuję tego systemu i przekonam się czy spełni moje oczekiwania. Do tego czasu pomyślę nad jakąś lżejszą dystrybucją Linuxa, która odciąży trochę moje zasoby VirtualBoxowe :)

Nie tylko relacyjne bazy danych

Artykuł, na który ostatnio się natknąłem uświadomił mnie, że w projektach, które ostatnio tworzę wcale nie wykorzystuję relacyjnych baz danych. Wręcz przeciwnie. Do wyszukiwarki 1procent.zhr.pl wykorzystałem MongoDB. W ankiecie do głosowania ZODB, w mod_spam'ie, do którego nawet ręki nie przyłożyłem co prawda, chodzi o implementację Redis albo Memcached.

Kolejnym odkryciem było dla mnie: "Przecież Review Board poza RDBMS używa Memcached!". Nie musiałem więc daleko szukać realnego zastosowania polyglot persistence w projekcie, z którym ostatnio mam dużo styczności.

Cieszy fakt, że istnieje wiele prostych w użyciu, szybkich do przyswojenia dedykowanych narzędzi, które można wykorzystać w swoich aplikacjach. Czasy kiedy pisało się aplikację z użyciem wyłącznie MySQL w moim życiu mijają. Czuję, że częściej będzie to coś znacznie bardziej dedykowanego, a w przypadku większych projektów na relacyjnej bazie danych się nie skończy - a silników przechowywania informacji będzie więcej niż dwa (a na pewno jeden).

Flask - Nie tylko Bottle

W poprzednim wpisie pisałem o Bottle jako fajnym microframeworku dla Pythona. Jeszcze wczoraj zupełnie przypadkiem trafiłem na Flaska.

Na pierwszy rzut oka zniechęca mnie fakt, że zbudowany jest na WerkZeug. W drugim rzucie Flask wymaga ciut więcej kodu niż Bottle:

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
return "Hello World!"

if __name__ == "__main__":
app.run()

Jednak później jest już tylko lepiej. Dostępna funkcja url_for do budowania poprawnych linków - to strzał w dziesiątkę. Dokładnie to czego brakowało mi w Bottle.

Renderowanie szablonów odbywa się tutaj bardziej w stylu Pylons. Domyślnym mechanizmem jest Jinja2.

Dokumentacja Flaska wypada o niebo lepiej aniżeli konkurenta. W dokumentacji Bottle zdażają się działy mające status todo. Tutaj nie znajdziemy nic podobnego.

Na koniec dwie rzeczy, które pozytywnie mnie zaskoczyły we Flask. Wsparcie dla Flash Messages oraz wbudowane loggery aplikacji.

Bottle i ZODB w jednym stali domu ...

... o swojej genialności nie mówiąc nikomu.

Wybory w Kręgu Harcerstwa Starszego Matrix - napisanie prostej ankiety. W końcu okazja, aby przećwiczyć coś nowego. Tym razem ZODB i Bottle.

Bottle wydaje się nadal rozwijany oraz w jakiś sposób subiektywnie "lepszy" niż Bobo. Posiada prosty wbudowany system szablonów. Bazuje on na założeniu, że szablony znajdują się w katalogu "views" dzięki czemu unikamy potrzeby konfiguracji (jak w Rails - convention over configuration).

W obu frameworkach brakuje mi jakiejś funkcji, która generowałaby poprawne linki - chociaż niby co to za problem zrobić sobie jednolinijkową funkcję do tego. Może tyle na temat micro-frameworków. Czas o ZODB.

O ZODB usłyszałem od mojego przyjaciela, który pracuje od jakiegoś już czasu w Plone i jest tym CM/F/S em zafascynowany. Kiedyś wracając z kina powiedział "No przypisujesz sobie jak chcesz atrybuty/klucze do obiektu i jest". Brzmiało obiecująco jednak nie okazało się tak piękne.

Plone robi bardzo dużo za nas. Pierwsze - nie wystarczy przypisać. ZODB jest bazą transakcyjną i nasze działania wymagają commitowania. Najprostsza sytuacja wygląda tak:

import transaction

#
# Tutaj sobie zmieniasz
#

transaction.commit()

Kolejna sprawa, dojście do której zajęło mi sporo czasu - ZODB wychwytuje zmiany tylko elementów korzenia. Tak więc:

# W bazie danych mamy taką strukturę:
# root.osoby = [{'id': 1, 'imie': 'Jan'}, {'id': 2, 'imie': 'Katarzyna'}]

# Łączysz się z bazą danych

root.osoby[1]['imie'] = 'Kasia'
transaction.commit()

Nie zadziała ponieważ ZODB nie przeczesuje w głąb struktur danych w celu poszukiwania zmian. Musimy więc zrobić na przykład:

osoby = root.osoby
osoby[1]['imie'] = 'Kasia'
root.osoby = osoby
transaction.commit()

Co odniesie skutek. Jak więc widać ZODB jest znacznie fajniejszy w Plone niż poza nim choć nadal jest fajny :)

Metoda małych zwycięstw a Drupal 7

Od kilku miesięcy skrupulatnie obserwuję dział Critical Issues (D7) i powiem szczerze, że osobiście jestem przygnębiony.

Każdy kto choć odrobinę zajmował się metodologiami Agile czytał o potrzebie małych zwycięstw, które motywowałyby i podnosiły wydajność zespołu. To co dzieje się w critical issues jest dokładnym anty-przykładem.

Jak każdy wie Drupal 7 w wersji beta wyjdzie gdy ilość krytycznych błędów spadnie do zera. Wszystko pięknie jednak śledząc każdego dnia spadki i wzrosty oraz pobieżnie przeglądając statusy poszczególnych zgłoszeń jestem załamany.

Generalnie ilość zgłoszeń utrzymuje się na poziomie trzydziestu kilku. Bywają okresy, po których liczba ta spadała do dwudziestu lub nawet kilkunastu jednak był to raczej efekt mechanizmu, który po 14 dniach braku aktywności uznaje zgłoszenie za rozwiązane aniżeli faktyczne zakończenie rozwiązywania problemu.

Oczywiście mechanizm ten ma sens i zgłoszenia tak zamykane zawierały szereg łatek będących propozycjami rozwiązania problemu. Odnoszę jednak wrażenie, że proces recenzji trwa w nieskończoność i brak jakiegoś BDFL w tym całym zamieszaniu.

Wracając do małych sukcesów. Wiele projektów przyjmuje bardzo prostą i moim zdaniem słuszną zasadę - skupiamy się w danej wersji na zaimplementowaniu kilku - dwóch, trzech rzeczy i koniec. Cel jest niedaleki, do osiągnięcia w niedługim czasie i bardzo dobrze określony. W Drupalu brakuje mi dobrze określonego celu. Metoda SMART byłaby tutaj nieoceniona i znacznie przyspieszyłaby wydanie stabilne. Jednak już sam fakt braku "małych kroków" sprawia iż nie widać końca a utrzymująca się liczba bugów nie cieszy, brak jest małych sukcesów, które podniosłyby morale.

Dobrą drogą dla projektów OpenSource jest stawianie sobie malutkich celów. Dobrze widać to w przypadku Google Chrome. Niemal od samego początku wiadomo jakie nowe funkcje pojawią się w nowej wersji, każda kolejna wersja stabilna cieszy i przynosi kolejne usprawnienia. Wszystko dzięki po mistrzowsku zaprojektowanemu procesowi (Review process, continous integration, tests), używaniu nowoczesnych narzędzi (Buildbot, Review Board, coś na wzór ANT ale dla typowe dla GNOME) i jasno określonym zasadom. Drupal mógłby się tu wiele nauczyć.

Moim zdaniem po wydaniu Drupala 7 społeczność powinna przestawić się na wydania drupala 7.1, 7.2,7.3 z kolejnymi elementami przygotowywanymi przez społeczność. Projekt rozwijałby się na bieżąco, nadążał za obecnie panującymi trendami, był innowacyjny i nowoczesny. Wydanie wielkiego Drupala 8 za kolejne kilka lat pozostawiłoby ponownie siódemkę w tyle i sprawiło, że strony na niej oparte trącą myszką.

Życzę zespołowi Drupala 8 lepszego określania celów, stosowania metody małych sukcesów, małych wydań przynoszących cieszące użytkowników zmiany i rychłego wydania ósemki :)