Pierwsze spostrzeżenie jakie mi się nasunęło: Bazaar jest dość powolny przy niektórych operacjach – szczególnie branchowaniu (tworzeniu odnogi w produkcji). Nie mam zbytniego porównania z innymi systemami kontroli wersji, bo nie użytwałem ich zbyt długo, ale jak dla mnie przydałoby się nieco szybciej to robić. Może być też tak, że korzystając z jakiegoś przełącznika da się to przyśpieszyć, ale też tego nie poszukiwałem.

Jeżeli chodzi o samą pracę to tutaj bardzo przydatny okazuje się TortoiseBzr (dołączony do wersja Bazaara dla Windows). Dzięki niemu nie musimy gimnastykować palców przy selektywnym dodawaniu plików do repozytorium. Także selektywny commit jest dużo wygodniejszy.

Wracając do branchowania to jest to jedna z bardziej użytecznych opcji, zaniedbana nieco w zwykłych (nie rozproszonych) systemach kontroli wersji. Polega to na tym, że tworzymy gałąź jeżeli chcemy coś przygotować, do niej wykonujemy commity a następnie łączymy (mergeujemy) z główną gałęzią. Mimo, że pracowałem sam, praktycznie każda większa zmiana miała u mnie swoją gałąź, dzięki czemu mogłem się zajmować tym co mi odpowiadało w danej chwili. Jednocześnie robiło mi to za taką “listę rzeczy do zrobienia” – każda gałąź odpowiadała za inną rzecz, gałęzie czasem dalej mi się rozgałęziały. Trzecim powodem takiej pracy jest fakt, że mogłem commitować niedziałający (bądź nawet nie kompilujący się) kod i nie miał on wpływu na inne części systemu którymi się zajmowałem.

Jedyną większą wadą takiego systemu jest to że potem trzeba to łączyć ze sobą, co czasami bywa karkołomnym zadaniem. Oczywiście praktycznie nic nie da się zrobić, jeśli z jakąś binarką się rozbiegniemy, ale nawet dla zwykłych plików mogą powstać problemy. Bazaar promuje metodę 3-way diff: mamy 3 pliki: bazę, wersję tego repozytorium i wersję drugiego repozytorium. Naszym zadaniem jest połączenie tych trzech wersji w jedną. Bywa ciężko.

Oczywiście jeśli już rozwiążemy problemy to wszystko toczy się dalej świetnie – Bazaar pozwala nawet na najbardziej karkołomne połączenia między gałęziami. Takie dzikie połączenia przydały mi się gdy na jednym branchu przygotowywałem menu dla aplikacji.

Oddzielną kwestią jest numerowanie wersji. Jest ono zrobione DUŻO lepiej niż w Git. Tutaj numery są nadawane tylko i wyłącznie lokalnie. Teraz jeśli robię merge to brancha wyżej to moim rewizjom nadawany jest prefix w formie numeru rewisji od której się odbranchowalem oraz kolejnego numeru identyfikacyjnego brancha. Ma to jedną wadę – nie do końca wiesz jaki numer rewizji dostaniesz, ale jest to dużo wygodniejsze niż numer w postaci SHA1 zawartości (ble!).

Jak tylko rozwiąże wszystkie sprawy z uczelnią napewno postawię sobie serwer Bazaara (na FTP ) żeby móc wygodniej z niego korzystać.

Wada 1: Co to za wersja???

Podstawową denerwującą rzeczą w Git jaka mi się rzuciła w oczy to nazywanie wersji. Nie mamy tutaj wersji 1, 2, 3 tak jak w Subversion, ale 40 znakowe, alfanumeryczne hashe. Po co to? Rozumiem, że macie kompleksy związane z tym, że w systemie rozproszonym każdy może mieć inny numer wersji u siebie i wypadałoby je jakoś od siebie odróżniać. Ale czemu nie można zostawić ładnych numerków tylko trzeba wrzucać te potworne hashe? Tutaj rozwiązał to choćby Mercurial, gdzie nazwa wersji składa się z normalnej liczby porządkowej i hasha. Do przeglądania wystarczy numer,  przy łączeniu wersji hash się przydaje.

Wada 2: Jakie to polecenie???

Wada druga jest związana z tym, że twórca Git’a (tak tak, TEN Linus Torvalds) musiał koniecznie stworzyć coś nowego. Więc oprócz nowego systemu kontroli wersji dał też nowy zestaw poleceń, które mogę przypominać to co znamy z SVNa, ale tym nie są. Istnieją nawet magiczne tabelki dla użytkowników SVNa którzy by chcieli poGitować sobie. Nowy zestaw komend to chyba najbardziej głupi sposób na bycie innowacyjnym.

Wada 3: Windows – tak, tam też byś się przydał.

Trzecią wadą jest fakt, iż Git ma kłopoty pod Windowsem. Ponoć nie są to już problemy z kompilacją (istnieje wersja msys która działa) ale miliony (czy jakoś tak) skrypcików doczepionych do Git-a nie działa, bo nie mamy basha i innych fajnych rzeczy. Ludzie… Czy nie można zrobić tego kulturalnie, tak, żeby nawet człowiek któremu Linux kojarzy się z chorobą weneryczną mógł tego używać? Pomnę tutaj takie dodatki jak seria Tortoise, pluginy SCC dla Visual Studio czy też choćby pluginy NetBeans. Dlaczego mimo, że Bazaar jest projektem młodszym to ma własnego TortoiseBzr (w testach) czy też plugin SCC dla Visual Studio (w developmencie, ponoć coś działa).

Podsumowanie

Pewnie każdy kto to czyta albo stwierdzi że albo Git jest do niczego, albo że plotę bzdury. Owszem, Git ma zalety takie jak gigantyczna prędkość działania czy też branche in-place (nie tworzysz nowego katalogu, po prostu katalog roboczy zmienia się). Ale te zalety są sobie, a wady sobie.

Bean Stalk

Bean Stalk oferuje nam niewiele. Mamy na nasz użytek 20 MB przestrzeni na jedno repozytorium SVN z maksymalnie trzema użytkownikami. ALe są też większe problemy. Bean Stalk w wersji darmowej NIE obsługuje szyfrowania. Ani SFTP and HTTPS. Oznacza to, że nasz cenny kod lata sobie po Internecie czytelny dla każdego kto się o to postara.

Dla osób które w grupie tworzą projekty też mam złe wieści. Oprócz przeglądu aktywności na repozytorium z narzędzi inżyniera oprogramowania nie ma nic. Nie mówię tutaj o integracji Trac’a czy też innego podobnego oprogramowania, ale nawet biedne autorskie rozwiązania Assembli już dawały jako takie możliwości.

Unfuddle

Unfuddle z drugiej strony wygląda lepiej. Mamy tutaj 200 MB miejsca, jeden projekt (projekt, nie repozytorium). Niestety w projekcie mogą brać udział jedynie dwie osoby. Repozytoriów natomiast możemu stworzyć ile dusza zapragnie. I do tego nie tylko SVN, ale także ostatnio coraz bardziej popularnego Git’a.

Do tego Unfuddle obsługuje tickety, milestone’y i newsy, dzięki czemu wytwarzanie oprogramowania jest trochę przyjemniejsze. Niestety SSL dalej jest płayną opcją i do dość daleko w planach hostingowych.

Podsumowanie

Który serwis teraz bym wybrał? Jeśli chodzi o moje prace na Politechnikę, a to jest  moje najczęściej używane repozytorium to Unfuddle. Właściwie to tylko dla tego, że daje więcej miejsca i pozwala na utworzenie dodatkowych repozytoriów. A jeśli chodzi o Bean Stalk, to daje on po prostu za mało.

Jeśli znacie jakieś dobre serisy z darmowymi repozytoriami do piszcie je w komentarzach. Chętnie je przetestuje, może skorzystam.

Najpierw najważniejsze, czyli co to jest ten bootstrap. Otóż jest to proces w którym Gentoo przebudowuje samo siebie od nowa. Startujemy tutaj nie z gotowej bazy systemu (czyli tzw. stage3) ale z podstwowego zestawu narzędzi (Binutils, GCC itp.) czyli kochanego stage1. Ciekaw byłem co się stało ze stage2, które też było dostępne do ściągnięcia, no ale znowu odbiegam.

Jeżeli chodzi o większość dystrybucji Linux’a bootstrap jest niemożliwy (no dobra, jest, ale nie ma on sensu). A dlaczego bootstrap się wykonuje? Są dwa główne powody: cross-kompilacja na nieobsługiwaną platformę oraz przyśpieszenie systemu. Dla mnie ważny jest ten drugi powód. Zwykle gdy używamy dystrybucji Linux’a jest ona przeznaczona (teraz) na procesory i586, czyli okolice Pentium. Od tamtej pory trochę się jednak pozmieniało, mamy MMX, SSE, SSE2, 3DNow! i masę innych optymalizacji. GCC je obsługuje, możemy je wprowadzać do instalacji Gentoo, ale tak naprawdę toolchain, czyli m.in. GCC nie korzysta z ich dobrodziejstw, tak samo jak biblioteka Glibc (tak, ta główna od każdego programu w C/C++ itd.).

Czyli tak naprawdę dopalamy sobie tylko dalsze elementy systemu podczas gdy wnętrze dalej jest ociężałe. Dlatego też wymyślono bootstrap, dzięki którymu to my decydujemy na jakich flagach zostanie zbudowany system (najważniejsza jest tutaj -march=). No tak, darmowa prędkość, trochę więcej czasu spędzimy przy instalacji, ale czy są jakieś tego wady?

Okazuje się niestety że tak. Podstawowy i z tego co wiem jedyny duży problem z tak przygotowanym systemem jest jego niekompatybilność z Gentoo. No nie z całym oczywiście, ale z pakietami binarnymi. Niestety (tutaj wiele osób stwierdzi, że się mylę) Gentoo wprowadziło pakiety binarne, żeby użytkownicy mogli szybcie instalować programy. Ja z tego nigdy nie korzystałem, mimo że przygotowanie do działania KDE3 zajmuje ok. 24h (!!).

A nie robię tego dlatego, że to niszczy całą ideę używanie Gentoo – pełną optymalizację pod względem funkcji i prędkości. W wypadku innych systemów często wpadałem w szał, gdy widziałem, że nie wiem z jakiego powodu np. kdepim chce instalować mi oprogramowanie od Bluetooth. Nie mam dongla, nie używam tego, więc po co mi to?

No ale czas już na podsumowanie. A jest ono proste – jeśli zależy ci na maksymalnej prędkości, a nie na szybkiej instalacji, wykonaj bootstrap od stage1. Jeśli jednak chcesz mieć system teraz, zaraz, już i przeżyjesz niewielkie spowolnienie jego działania, nie rób tego. Dla ciebie są pakiety binarne (i inne dystrybucje…).

Więcej o bootstrapie można przeczytać tutaj.

Trochę musiałem powalczyć żeby to naprawić. Niestety dokumentacja RubyGems jest biedna i dotyczy wersji sprzed dawna (0.8.7 jak sie nie myle, gdzie teraz jest 1.3.0). Udało mi się doczytać, że teraz nie ma już require_gem, lecz trzeba najpierw aktywować gem a dopiero potem zrobic require. No cóż, szkoda że tych informacji na oficjalnej stronie RubyGems nie ma.

Druga sprawa jaka mnie dziwi, to fakt, że w Rake 0.8.3 w changelogu nie ma żadnych informacji o usunięciu funkcji do_option. Przecież zmianie uległo zewnętrzne API, takie rzeczy się pisze. No nic, kolejny problem ze społecznością Ruby’ego.

No ale jeśli tu trafiłeś to pewnie masz ten sam problem co ja miałem. Oto rozwiązanie:

1. Musisz mieć zainstalowanego Rake 0.8.1 (pamiętaj że gemy pozwalają na wiele wersji naraz!). Jeśli skasowałeś to “gem install rake -v 0.8.1″
2. Musisz odnaleźć plik “rake_tasks_info.rb”, powinien być w katalogu “<NetBeans>\ruby2″.
3. Przed linijką “require ‘rake’” dopisz linię “gem ‘rake’, ‘<= 0.8.1′ ” (bez cudzysłowów).

Ponoć w trunku najnowszej wersji pluginu do NB jest już dodana poprawka na to.

Dawniej było tak, że był tylko SVN i można było go udostępniać publicznie, albo i nie. Czyli prywatne małe projekciki mogły sobie bezpiecznie żyć pod kontrolą ich serwera. Teraz sytuacja się dość mocno zmieniła. Otóż jeśli chcemy mieć za darmo “przestrzeń” (ang. space) to musimy ją udostępniać. A jak nie to płacić.

Cena może nie jest zabócza ($2 miesięcznie za każdego developera i $3 miesięcznie za 1 GB przestrzeni) ale moje repozytorium to tylko 6 MB (2 semestry PG) i 1 developer czyli bym płacił $5 miesięcznie, co daje $60 na rok. A to już trochę dużo jak za taką usługę.

Dlatego teraz będę kombinował jak tutaj zrobić zrzut repozytorium i przenieść je na inny serwer (możliwe że dogadam się z dostawcami tego serwera i za 50 zł dokupię obsługę SVN). A jak nie to będę musiał szybko wymyślić jakiś sposób na tworzenie kopii zapasowych.

9 września 2008 roku Steve Jobs na “Apple Special Event” prezentował wiele ciekawostek jakie w ciągu ostatniego tygodnia pojawiły się na rynku. Jak zawsze nowe iPody: Nano generacji czwartej z akcelerometrem i paletą kolorów (btw: najcieńszy iPod w ofercie) i iPod Classic 2. generacji w jednym rozmiarze: 120 GB. Tak, era gigantycznego (nawet jak dla mnie) iPod’a z 160 GB dyskiem twardym się skończyła. Teraz dostępny będzie jedynie ten w uśrednionym rozmiarze. Wg. informacji na CNet.uk Apple mógł opracować wersję 240 GB w obudowie rozmiarów wersji 160 GB (którą to posiadam).

Pojawiły się także informacje o nowym iTunes 8 który wprowadza seriale TV (nie wiem czy filmy nie były uż wcześniej dostępne) w rozdzielczości HD. Ponoć iPod Classic ma to obsługiwać, ale już nikt nie wie nic napewno. No ale nie to mnie wkurzyło. Otóż nowe dziecko Steve’a posiada ciekawą funkcję Genius. W założeniu ma ona na podstawie jednego utworu tworzyć listę 25, 50, 75 bądź 100 utworów które dobrze do niego pasują. Testowałem to na komputerze, efekt nie jest idealny, ale jest bardzo zadowalający.

W funkcję Genius został wyposarzony nowy iPod Nano, iPod Touch (w wersji z softem 2.1, update za darmo z 2.0, albo z 1.0 za $9,95), no i iPhone. Rozumiem, że na tej liście nie znalazł się malutki Shuffle, bo on i tak ma mało miejsca. No ale czemu nie ma na tej liście iPod’a Classic? Miejsca ma najwięcej na bazę Geniusa, moc obliczeniową też chyba nie najgorszą, a mimo to go nie ma.

Atmosferę podgrzeje kolejny fakt: wg pewnego reprezentanta firmy Apple, Genius miałby się pojawić w Classic’u w niedalekiej przyszłości. No ale się okazało, że to jednak bujda, przynajmniej wg CNet.uk. Można tam wyczytać, że owszem, taka informacja była, ale została zdementowana przez Apple. Czyżby więc nadchodził koniec “dużych” iPodów?

Wszystko na to wskazuje. Tylko dwie odmiany kolorystyczne, spowolniony rozwój, brak nowych funkcji. Nowy iPod Classic został oczywiście odświerzony, ale co z tego jak tylko wymienili dysk twardy? Nic nowego w oprogramowaniu gwarantuje, że nadeszła późna starość. Jedyne co przemawia za tym, że pozostanie na rynku, to historyczne przywiązanie, gdyż jest to potomek ich pierwszej serii odtwarzaczy. Ale czy to wystarczy? [1]

Cały jego bajer polega na tym w jaki sposób pracujemy z przeglądarką. Powiedzmy, że siedzę sobie na necie i widzę ciekawą stronę której fragment chciałbym przesłać kumplowi. Otwieram więc pocztę, kopiuję fragment do schowka… tylko czy nie da się szybciej? Tutaj z pomocą przychodzi Ubiquity. Wystarczy tylko zaznaczyć fragment który nas interesuje, nacisnąć Ctrl+Spacja żeby otworzyć konsolę Ubiquity i wpisać “email selection to migol@migol.net”. W tym momencie otwiera nam się konto na Gmail.com (warto je mieć!), w tytule wiadomości pojawia się tytuł strony, a w jej treści zaznaczony fragment. Proste i szybkie, przynajmniej jeśli umiemy w miare szybko klepać na klawiaturze.

Więcej możliwości Ubiquity zobaczycie na tym filmiku:

Ubiquity for Firefox from Aza Raskin on Vimeo.

Oczywiście jak dla każdego programisty ważne jest też jak łatwo się rozszerza taki plugin. No bo po co mi on, jak tak naprawdę nie współpracuje on za dobrze z moim Gmail’em a zamiast mapy Google przydałaby mi się raczej mapa z Zumi. No ale o pisaniu własnych komend już nie będę tutaj pisał, wszystko co trzeba wiedzieć zostało napisane tutaj. Jak dla mnie plugin jest świetny, i z pewnością napiszę kilka własnych funkcji do niego (pewnie gdzieś się na tym blogu znajdą.

No więc co nowego? Przede wszystkim przechodzi w 100% test ACID 2. Cóż to takiego? Otóż ten test sprawdza w jakim stopniu przeglądarka spełnia wymaganie W3C w zakresie renderowania (czyli wyświetlania) stron internetowych. Ten konkretny test jest nastawiony na HTML i CSS2. Niestety FF3 nie przechodzi testu ACID 3, który sprawdza masę innych elementów takich jak pełen ECMAScript, SVG i inne. Jak narazie żadna przeglądarka w wersji stabilnej go nie przechodzi (jedynie developerzy Opery i Safari zrobili wersję mającą pełną obsługę, ale nie jest ona stabilna).

Kolejną ważną rzeczą odnośnie nowej wersji FF jest DUŻO szybsze wykonywanie skryptów JavaScript. Najlepszym tego przykładem jest korzystanie z Gmail’a który jest niemal w 100% napisany w tym języku.

Trzecią rzeczą którą warto o nowym Firefox’ie wiedzieć jest to, iż duża część wtyczek może być niekompatybilna. Oczywiście z biegiem czasu to się zmieni, ale narazie z niektórymi musiałem się pożegnać.

A, pobieranie oczywiście z http://www.getfirefox.com/

Ruby on Rails jest to platforma do tworzenia serwisów internetowych, na licencji MIT. Powstała ona w przeciwieństwie do większości tego typu oprogramowania nie jako idea rozpoczęta od początku, ale została wyciągnięta bezpośrednio z działającego produktu – Basecamp. Różnica jest znaczna, gdyż na start był to już dojrzały produkt. Aktualnie mamy wersję 2.0.2, na co radzę zwrócić uwagę szukając tutoriali (np nie istnieje już instrukcja scaffold).

Ruby on Rails (RoR) nie jest to coś podobnego do np. PHP, gdyż PHP to tylko język programowania, którym w wypadku RoR jest Ruby. O Ruby może napiszę jeszcze kiedyś. Bycie platformą oznacza więc, że RoR daje coś więcej.

Przede wszystkim Rails zmienia sposób spojrzenia na utrzymanie jakości w oprogramowaniu. Np. bardzo popularny i ważny model MVC (Model, View, Controller) czyli trójwarstwówka (model odpowiada za dane, view za to jak są one wyświetlane, a controller za logikę biznesową). W Ruby on Rails jest to właściwie jedyna metoda dodawania czegoś na stronę. Możliwe że istnieją inne metody, ale tworząc w RoR wydają się one cokolwiek nie na miejscu.

Kolejną ważną rzeczą we współczesnym podejściu do jakości oprogramowania jest automatyczne testowanie programów. Dlaczego jest ono ważne? Po pierwsze dzięki automatycznym testom nie musimy sprawdzać sami, czy coś działa czy nie. Nie jest to bardzo odkrywcze stwierdzenia, ale ważności nabiera w momencie w którym np. optymalizujemy kod, czy robimy

“refactoring”. Wtedy chcemy, aby kod miał takie same efekty jak wcześniej, ale robił to w inny, lepszy sposób.

Następna interesująca sprawa to sposób zarządzania bazą danych. Tutaj RoR daje nam po pierwsze mechanizmy zarządzania trzema podstawowymi bazami danych: development na której tworzymy oprogramowanie, test na której je testujemy i production, czyli baza danych dla pracującego systemu. Dalej dostajemy piękny mechanizm migracji bazy danych.

Migracja baz danych do kolejnych wersji stanowi bardzo problematyczną sprawę dla większości systemów. Żaden ze znanych mi systemów bazodanowych nie wspomaga tego procesu. Tymczasem Rails rozwiązuje przepięknie ten problem poprzez system migracji bazy danych. Mówiąc z skrócie polega to na tym, że kodem w Ruby zmieniamy bazę danych. Tak, bez użycia SQLa. I to działa. A wygląda np. tak:

class CreateBooks < ActiveRecord::Migration
  def self.up
    create_table :books do |t|
      t.column :title, :string
      t.column :author, :string
      t.column :rating, :int
      t.column :description, :text
    end
  end
 
  def self.down
    drop_table :books
  end
end

Metoda self.up służy do przeniesienia wersji bazy danych na aktualna, natomiast self.down wycofuje wprowadzone zmiany. Ten kod tworzy tablicę “books” z czterma polami (i dodatkowo piątym – id). Zasadniczo każdą podstawową operację na bazie danych można w ten sposób opisać. Prościej się juz chyba nie da.

Do tego wszystkiego Rails oferuje generatory – skrypty które tworzą nowe element strony takie jak modele, widoki, czy migracje bazy danych, razem z wszystkimi testami które wypadałoby zrobić. Jakby tego było mało, aplikację RoR można połączyć z SVNem, dzięki czemu pozbywamy się problemu ręcznego dodawania plików.

O Ruby on Rails i jego zaletach możnaby pisać godzinami, więc tym razem to już wszystko.