Zastanawiałeś się kiedyś jaki język jest “przyszłościowy”? Nie Ty jeden, na forach i portalach co kilka dni pojawia się podobne pytanie. Czy nauczyć się php? Czy może ruby, albo python? W co zainwestować?

Często odpowiedzi są niezadowalające – możesz dowiedzieć się, że jeśli będziesz wybierał język wg spodziewanych przyszłych zarobków, to nie będziesz dobrym programistą. W tym stwierdzeniu jest tylko połowa prawdy. Jeśli zostajesz programistą ze względu na możliwe zarobki możesz nie być tak dobry jak ten, dla którego jest to pasja.
Jeśli jednak już wybrałeś tą ścieżkę i chcesz się nauczyć tej technologii, która jest najbardziej pożądana, a przez to najlepiej płatna – jest to jak najbardziej rozsądne działanie. Porównałbym go do inwestowania tam, gdzie spodziewamy się największych zysków.

Jeśli stoisz właśnie przed podobnym dylematem chętnie zasugeruję Ci książkę, która może nieco rozjaśnić Ci sytuację. “Więcej niż Java” nie odpowie Ci na pytanie “którą droga iść?”. Ale rzuci światło na każdą z interesujących ścieżek, dzięki czemu, być może, łatwiej będzie Ci zdecydować.

Jednocześnie warto mieć w głowie pewne stwierdzenie, które przeczytałem w informatorze uniwersytetu kiedy startowałem na studia.

Studia informatyczne nie mają za zadanie nauczyć studentów jakiegokolwiek języka programowania. Mają za zadanie nauczyć ich myślenia, zasad i mechanizmów zachodzących w świecie informatyki, żeby absolwent mógł nauczyć się samodzielnie dowolnej potrzebnej technologii

Dlatego nawet jeśli podejmiesz decyzję i okaże się strzałem w dziesiątkę (zastąpi Javę i da Ci wspaniałe zarobki) pamiętaj, że powstaną wspanialsze narzędzia, które prędzej czy później wrzucą z piedestału Twojego wybrańca i kurę znoszącą złote jajka w jednym.

Bądź na bieżąco, poznaj jeden, ciekawy język/framework przynajmniej raz na pół roku… choćby pobieżnie i przeczytaj książkę, którą Ci polecam, bo warto ;)

Dlaczego jest to takie fajne? Posłużę się antyprzykładem z cakePHP.
Wyobraź sobie, że masz projekt i zarządzasz jego wersjami za pomocą popularnego SVN, czy CVS. Najczęściej pracujesz na lokalu i we wczesnych fazach projektu to dodasz pole w bazie danych w jakimś miejscu, do zmienisz indeks. Robisz commit kodu, który na nowej strukturze działa dobrze, ale struktura bazy danych nie podlega wersjonowaniu.
Zatem albo musisz zrobić eksport struktury do pliku który jest wersjonowany, albo (jak często odbywa się to w moich projektach) – robisz zmiany na pewnej głównej i ogólno dostępnej bazie (co by reszta mogła sobie ściągnąć nową wersję).

Pierwsze rozwiązanie sprawia, że przybywa Ci pracy. Wiem, że to nie dużo, ale zawsze jedna dodatkowa rzecz o której musisz pamiętać. A w przypadku gdy commit zrobiłeś po tygodniu pracy, bo wcześniej cały system się sypał – możesz zapomnieć o takich szczegółach jak dodanie pola na początku.
W przypadku jest jeszcze gorzej. Oprócz problemów opisanych powyżej dochodzi niebezpieczeństwo usunięcia całej bazy, brak możliwości powrotu z bazą do wcześniejszej wersji.

Z kolei w django możesz zapomnieć o phpMyAdminie i innych. Całą strukturę bazy danych masz zdefiniowaną w modelu i jednym poleceniem synchronizujesz jej wersję w silniku bazy z definicją w modelu.

Oczywiście do podejścia trzeba się przyzwyczaić.  W cake’u trzymając się konwencji wszystkie modele mogą wyglądać tak:
class TabelaWFormieLiczbyPojedynczej extends AppModel {};
W django – to co nie istnieje w modelu – nie istnieje w bazie.

Ciekaw tylko jestem jak to się sprawdza przy nietypowych sytuacjach, które nieraz wymagają nieco karkołomnych konstrukcji w projekcie bazy danych i specyficznych zapytań sql. Moja znajomość samego Django jest na ten moment za mała, żeby odpowiedzieć na to pytanie.