Dlaczego liczy się jakość implementacji?

Programowałem już w kilku frameworkach. Jeszcze kilka przede mną.Czy zgodzicie się, że wszystkie frameworki są takie same? Nie - wszak różnią się między sobą... To inaczej. Czy zgodzicie się, że robią to samo? Inaczej, że próbują osiągnąć ten sam cel? Moim zdaniem każdy framework (wszak nazywa się frameworkiem) ma za zadanie:

• stworzyć środowisko pracy charakterystyczne dla prac webdeveloperskich
• zapewnić bezpieczeństwo aplikacji charakterystyczne dla webserwisów
• ułatwić utrzymywanie projektu poprzez separację - na przykład z użyciem wzorców projektowych

Każdy framework realizuje te cele na swój własny sposób. Jest jakaś warstwa obsługi bazy danych, tworzony jest jakiś wzorzec do udostępniania funkcji klientowi (MVC, REST, EDA), proponowany jest system wprowadzenia nieinwazyjnie logiki do warstwy HTML (szablony, widoki). Realizacja tych celów mogłaby stanowić pewną definicję frameworka.

W tym świetle frameworki nie różnią się od siebie. Wszystkie realizują swoje cele. Django czy Pylons, Rails, CakePHP, Symfony, Kohana albo Web2Py, Lift - wszystkie z definicji realizują te cele. Którego użyć do prostego projektu, który da się zrealizować w każdym z nich?

Wielu może dziwić, drażnić postawa często prezentowana przez Jarka Zabiełłę - zachwytu nad perfekcją programistów tworzących konkretny framework. Technologiczną doskonałością Merba, geniuszem z jakim zakodowany jest Lift. U mnie ta postawa znalazła w końcu grunt.

Lepsza jakość kodu i restrykcyjne coding standard (np. w Merb) oznacza wiele dobra: prostsza refaktoryzacja, mniejsza ilość potencjalnych błędów, znacznie zwiększone bezpieczeństwo, posunięty performance. Taki jest właśnie Merb.

Ponawiam pytanie: "Jaki framework wybrać do prostego projektu, który można stworzyć w każdym z nich?" odpowiedź - najdoskonalszy technologicznie. Jaki framework wybrać aby mieć pewność największego bezpieczeństwa? Najdoskonalszy technologicznie? Jaki framework wybrać aby moja aplikacja była możliwie najszybsza? Najdoskonalszy technologicznie.

Tak. Frameworki różnią się między sobą: dostępnymi wtyczkami, architekturą, możliwościami, językiem programowania. Do momentu, w którym którykolwiek z tych składników odgrywa rolę - walka między frameworkami nie jest równa i w konkretnych przypadkach wybór jednych przeważa nad drugimi. Jednak dla prostych projektów, gdy nie masz bariery poznania nowego języka programowania tylko doskonałość technologiczna może przeważyć nad użyciem jednego ponad drugim.

Mam nadzieję, że udało mi się oddać moje ostatnie przemyślenia, na których znalazło grunt podejście Jarka Zabiełły, który często rozwodzi się nad doskonałością techniczną pewnych rozwiązań :) Wszak dla najlepszych przestaje być ważne, że potrafią coś zrobić, a zaczyna być ważniejsze jak to zostało wykonane.

Skoro coś można zrobić na wiele sposobów to czemu nie ma budzić uznania i szacunku i być przez nas wybieraną technologia, która została zrobiona w sposób genialny i najlepszy?

Co wkurza mnie w ludziach, którzy wielbią Railsy

Tytuł jest troszkę kontrowersyjny i powinien brzmieć "co wkurza mnie w ludziach, którzy wielbią jeden - jedynie słuszny - framework" bo o to mi naprawdę chodzi. Celowo jednak napisałem, że o Rails mi chodzi ponieważ wszyscy, którzy rażą mnie swoim podejściem wśród moich znajomych to właśnie Railsowcy.

Nie jestem uczulony na każdego kto broni jakiegoś frameworka. Tak na przykład bardzo lubię argumentację Jarka Zabiełły, który dałby się dosłownie poszatkować za Lifta, skoczyć w ogień za Merbem czy odtańczyć taniec radości przez Web2Py. Nie widzę nic złego w posiadaniu swojego ulubionego frameworka. Co więc mnie denerwuje?

Niepowetowanie rozdrażniają mnie osoby, które programowały tylko w jednym (nie ważne jakim) frameworku i mając takie doświadczenie opowiadają o nim jak o wybawieniu. Po prostu krew mnie zalewa. Ktoś programował sobie w PHP (na sucho): echo do HTML, include $_GET do ładowania stron, mysql_query do robienia zapytań i nagle [... tu wstaw nazwę jakiegoś frameworka, który stał się religią dla Twoich znajomych]! Po prostu objawienie! Ścieżka światła otworzyła się przed biednym, pogrążonym programistą i doznał olśnienia! I od tamtej pory nie rozstaje się ze swoją cudowną technologią, genialnym wybawicielem! Po prostu ... śmiechu warte. Tyle powiem.
Nie mogę znieść braku chłodnego dystansu do technologii, której się używa. Pewnej podejrzliwości i niepokoju: A może istnieje jeszcze inna, może lepsza technologia? Może to nie jest szczyt wszystkiego? Może w innych językach programowania istnieją inne równie dobre a może nawet lepsze frameworki? Taka właśnie postawa budzi we mnie szacunek do adwersarza i otwiera na jego argumenty.
Rozumiem jak najbardziej - użyciem frameworka jest ogromnym postępem i tak! zgadzam się w 100%! jest często niesamowitym, ekscytującym, powalającym na kolana odkryciem. Szczególnie w świetle czasu jaki zyskujemy - tworząc aplikację. Jednak zdrowe moim zdaniem jest gdy ów zachwyt pcha programistę do przodu, nie daje mu spokoju, każe poznawać nowe frameworki, lepsze technologie, doskonalesz rozwiązania. Nie mogę znieść gdy widzę, że ktoś po prostu na tym zachwycie - spoczął na laurach. Jego poglądy zaczynają wtedy dla mnie przypominać religię, a argumentacja staje się "nawracaniem" na moją stronę.

Mało kto będzie krytycznie i obiektywnie podchodził do frameworków jeżeli nie pozna na wstępie kilku. Poznanie wyłącznie jednego i zatrzymanie się na nim - w 99% skazuje człowieka na brak obiektywizmu. Nie jest wtedy ani dobrym adwersarzem do dyskusji bo jedyne co może powiedzieć, że to czego używa jest dobre (a często mówi, że najlepsze) - jednak co znaczą jego słowa kiedy nie ma porównania.
Dużo bardziej wiarygodną wypowiedzią jest dla mnie zdanie programisty, który nigdy nie programował we frameworku, o którym mowa, ale dużo o nim czytał i tworzył oprogramowanie w kilku innych pochodzących z różnych języków programowania niż opinia osoby, która poznała swój pierwszy framework i tak się nim zachwyciła, że nie pozwala jej to iść dalej.
Na koniec może troszkę powiewu optymizmu. Trzeba cieszyć się z każdej osoby, która zacznie używać frameworków. Nawet takiej, która uczyni z tego religię. Niech programuje w nim nawet nieświadomie i źle, ale zawsze będzie oznaczało to więcej lepszej jakości kodu aniżeli ta sama aplikacja miałby być pisana na sucho.

Gdyby pieniądze Microsoftu ...

Ostatnio kolega podesłał mi ciekawy artykuł Python + Django vs. C# + ASP.NET: Productivity Showdown. Złożyło się to z rozmową z jednym z moich współlokatorów o doświadczeniu pisania w .NET aplikacji webowych.

Przytoczny artykuł pokazuje w skrócie, że kilku niedoświadczonych programistów zaczynających swoją przygodę z Django może pobić wydajnością większą grupę doświadczonych C# piszących ten sam projekt w ASP.NET. To pokrywa się z moimi doświadczeniami z pracy. Jednak w tym wpisie chciałem zwrócić uwagę na coś innego.

Model MVC - pierwszy raz opisany w 1797 został zastosowany we wszystkich znanych mi frameworkach i okazał się dobrym rozwiązaniem. Microsoft dopiero w 2009 r. wypuścił stabilną wersję MVC.NET. Iron Python i IronRuby to próba nadgonienia przepaści pomiędzy ASP.NET a światem rozwiązań Open Source, w końcu umożliwienie wchłonięcia dobrodziejstw wszystkich projektów typu Django czy Ruby On Rails.

Ilość pieniędzy wpakowana w ASP zapewne jest ogromna. Zastanawiam się w jakim miejscu bylibyśmy dzisiaj gdyby te same środki przeznaczyć na rozwój takich projektów jak Ruby On Rails, Django, Pylons, Web2Py, Lift ,Merb czy chociażby Drupal.

Są to projekty o skromnych funduszach lub powstające niemalże wyłącznie dzięki dobrej woli wolontariuszy. Niemniej łamią stereotypy, wyznaczają nowe trendy w tworzeniu aplikacji sieciowych, są ponadczasowe a rozwiązania w nich zastosowane wyprzedzają swoją epokę. Gdzie byłby dzisiaj świat gdyby przeznaczyć na tego rodzaju projekty pieniądze jakie Microsoft zainwestował w ASP?

Odpowiedź na to pytanie istnieje. Masz ją nawet "przed oczami" lub na stronie startowej twojej przeglądarki. Tak jest! Zgadłeś! Odpowiedzią jest - Google.
Google jest jedyną znaną mi firmą, która powszechnie na dużą skalę korzystała z dobrodziejstw rozwiązań Open Source i inwestowała w nie pieniądze. Adaptacja jądra Linuksa w projekcie Android, własne patche do MySQL czy zmodyfikowany Python to tylko niektóre przypadki sukcesu Google w wykorzystywaniu tego co już zrobiono i udostępniono za darmo.

Wiele firm z powodzeniem korzysta z całych środowisk, ekosystemów udostępnianych przez Microsoft: serwery, usługi, fora, wiki, blogi, platformy multimedialne, narzędzia do pracy zdalnej i grupowej, aplikacje biurowe. Przykładów można byłoby mnożyć i mnożyć. Wtedy tworząc narzędzie dla firmy jesteś "zmuszony" tworzyć go w .NET. Być może nie jesteś zmuszony wprost ale jednak aplikacje pod produkty Microsoft pisze się najlepiej właśnie z użyciem tych technologii. Ba! Wyobraź sobie reakcje wyższego managementu na zażądanie Apache 2 i Python bo chcesz pisać coś w Django - kiedy oni wydali setki tysięcy dolarów na produkty firmy Microsoft. A Ty chcesz im powiedzieć, że niepotrzebnie - bo użyjesz sobie darmowego softu? Zbrodnia!

Może troszkę udemonizowałem scenariusz w poprzednim akapicie, ale to wyjaskrawienie jest moim zdaniem potrzebne. Google jest jedynym przedsiębiorstwem, w którym nie widać wszechobecności technologii Microsoftu. Z mojego punktu widzenia wygląda to tak, że Google chce wciąż mieć wybór w tym czego i jak używają. Czuć się dzięki temu wolnym i nieskrępowanym co czyni z nich niesamowicie elastyczną i innowacyjną firmę.

Mam wrażenie, że języki programowania znane ze świata Open Source ukierunkowują "na zewnątrz" zaś języki Microsoft "do wewnątrz". Python, Ruby czy Scala nie są związane z żadną konkretną technologią i dlatego powstające na ich bazie rozwiązania ukierunkowane są na nowe cele wyznaczające nowe kierunki. Tak robi Google i wiele innych firm kiedy tworzy coś nowego: Gmail, Google Docs, Youtube, Facebook, Twitter.
Platformy programistyczne Microsoft wymagają zawsze włożenia gro wysiłku w opracowaniu ich "pod systemu Microsoftu". Są więc ukierunkowane "do systemów Microsoft" działania z nimi, stworzenia API i do tego najlepiej się nadają - tworzenia własnych narzędzi dobrze zintegrowanych z ekosystemem ze stajni Billa Gatesa.

Myślę, że właśnie to "przywiązanie", to "zaplecze" jakie musi posiadać każda nowo powstała technologia wytwarzania oprogramowania z Microsoft sprawia, że nie starcza już tym technologiom "pary" aby stać się technologią, w której powstanie coś ponad epokowego i łamiące współczesne standardy.

Jak już wspominałem przywiązaniu temu nie podlega Google, wybierające do realizacji projektów technologie, które pozwalają rozwinąć skrzydła programisto i stworzyć coś - co jeszcze nie istnieje. Nie ograniczając ich ale dodatkowo dając wsparcie ich innowacyjnym pomysłom w stosowanej technologii.

Co więc byłoby gdyby Microsoft wkładał swoje pieniądze w rozwój Ruby On Rails, Django czy innych projektów Open Sourcowych? Mielibyśmy Google świata Open Source :] Czyż nie byłoby to piękne?

Rok 2010 rokiem przełomów w aplikacjach sieciowych

To wręcz niesamowite jak wiele dzieje się w tym roku w dziedzinie aplikacji sieciowych. Być może to tylko wrażenie, jakie można mieć co roku ale moim zdaniem jest to rok przełomowy.

Dzisiaj po 2 w nocy wyszła wersja Release Candidate 1 Gallery 3. Jest to ogromny krok w dziedzinie aplikacji do przetrzymywania zdjęć. Większość dostępnych w sieci skryptów zakłada, że istnieje jeden właściciel galerii, który publikuje w niej zdjęcia. Gallery to jedyny znany mi do tej pory system pozwalający w ramach jednej galerii tworzenie wielu albumów i przydzielania uprawnień do nich wielu użytkownikom.

Gallery posiada pewne bardzo proste - acz daleko idące w skutkach założenie - jeżeli nie masz dostępu do zdjęcia - nie masz do niego dostępu wogóle, nawet poprzez bezpośredni link. Gallery w wersji 2 realizowało to poprzez przetrzymywanie obrazków poza folderami dostępnymi przez Apache zaś każde żądanie pliku PNG, JPG czy innego było tłumaczone przez mod_rewrite na wywołanie skryptu PHP, który sprawdzał uprawnienia do pliku i ewentualnie zezwalał na jego wyświetlenie.

Niestety - przy galeriach dużych rozmiarów całość znacznie rzutowała na wydajność, wygodę i szybkość korzystania.

Gallery 3 to krok milowy w każdej tych dziedzin. Dzięki modelowaniu uprawnień na poziomie plików .htaccess udało się otrzymać wydajny i szybki mechanizm bezpieczeństwa. Celem stało się utrzymanie aplikacji sprawną, lekką i wydajną. Dołożono do tego interfejs oparty o jQuery. Całość zaś oparto na fantastycznym frameworku Kohana.

Kolejne zaskoczenie to milowe w dzidzinie od lat zgłaszanych braków Django 1.2. W końcu poprawki w dziedzinie modeli, obsługa wielu baz danych, zamknięcie wielu ticketów, które od lat straszą na Djangowym bug tracku. Django w końcu przełamuje barierę "argumentu za użyciem Pylons" jakim był brak możliwości obsługi wielu baz danych co czyni go znacznie bliższym zastosowań enterprise.

Skoro już przy Pylons jesteśmy. Nigdy nie wierzyłem, że dożyję dnia kiedy zostanie wydana publicznie wersja Pylons 1.0 beta. Jednak stało się. Pylons pretenduje do wersji stabilnej z niezmiennym API i w końcu może zacząć być używany w projektach gdzie liczy się stałość i ciągłość wersji w aktualizacji 3rd party components.

Nie można też pominąć Rails 3 - chociaż tutaj nie chcę się wypowiadać to z oglądanych przeze mnie prelekcji, wypowiedzi Yehudy Katz oraz wpisów na blogach Polskich Rubystów widać, że Rails 3 jest krokiem milowym w jakości tego frameworka ku doskonałości.

Wszystko wskazuje na to, że również Drupal 7 pojawi się w tym roku. Dwa dni temu została wypuszczona wersja Alpha 2 - co oczywiście w przypadku Drupala kompletnie o niczym nie świadczy - ale zawsze to jakiś krok do przodu. Oby prace poszły szybko - bo zapowiada się naprawdę fantastyczny framework.

Prawdopodobnie jeszcze wiele zaskoczeń czeka nas w dziedzinie aplikacji sieciowych - jednak Luty i Marzec to prawdziwy wysyp. Dzisiejszy dzień to jeden z tych, w których nie mogę uwierzyć, że jest aż tak dobrze. Oby więcej takich postępów i dobrze wykonanej pracy!

MA starcie pierwsze - LaTeX

Zastanawiam się i nie mogę pojąć. Dlaczego LaTeXa uczono nas na pierwszym semestrze studiów kiedy faktycznie potrzebny jest dopiero teraz - na dziewiątym? Nie wiem. Może dlatego, żeby spłatać nam figla. A może dlatego, żeby sprawdzić czy istnieją jakieś genialne jednostki, które będą pamiętały jak się z tego jeszcze korzystało. Tak czy owak nadeszła ta chwila.
Do zainstalowania w Ubuntu 9.10 LaTeXa wystarczyło mi wybranie w Synapticu dwóch paczek. texlive oraz texlive-full. Później chodziło już tylko o znalezienia wygodnego edytora. Chociaż napisany w Qt - bardzo do gustu przypadł mi Texmaker.

Pierwszą rzeczą, którą zmieniłem w Texmakerze było ustawienie opcji Quick Build na pdflatex + pdf view. Generowanie plików PDF pozwoliło mi na zamieszczanie w dokumencie plików jpg przy użyciu paczki graphicx.

Chyba najbardziej dumny byłem z modelu paczek, który sobie wypracowałem. A wygląda to u mnie wstępnie mniej więcej następująco.

\usepackage{magisterka} % kilka ustawień TeX dla magisterki
\usepackage[MeX]{polski} % używamy platex do łamania
\usepackage[utf8]{inputenc} % kodowanie znaków
\usepackage[T1]{fontenc} % ustawianie dzielenia wyrazów typowe dla europy
\usepackage{graphicx} % rysunki
\usepackage{indentfirst} % wcinaj pierwszy paragraf
\usepackage{listings} % zalaczanie kodu zrodlowego
\usepackage{multicol} % tworzenie fragmentow lamanych na kolumny

Wielu rzeczy brakuje, ale jest to co dla mniej najważniejsze czyli łamanie wyrazów zgodnie z zasadami polskiej gramatyki, wcinanie pierwszego akapitu w rozdziale, listingi języków programowania i możliwość tworzenia układów wielokolumnowych :] Myślę, że ta sekcja będzie rozstała się w trakcie dodawania kolejnych rozdziałów.

Poza właśnie takimi automatami jak przenoszenie wyrazów - co LaTeX robi świetnie - bardzo ucieszyło mnie odkrycie instrukcji \import pozwalającej wręcz wstawiać zawartość innych plików do treści mojej pracy. Dzięki temu każdy rozdział magisterki mam w oddzielonym pliku, mam nawet specjalnie wydzielony plik na paczki :] Taki podział sprawia, że wszystko jest bardzo czytelne a modularność rozwiązania pozwala wszystkim łatwo zarządzać.

Skoro już o listingach wspomnieliśmy. Szalenie użytecznym jest rozpoznawanie języków programowania w nich używanych. LaTeX wspiera ogromną ich ilość i po swojemu "koloruje" składnię to znaczy, pochyla komentarze, pogrubia słowa kluczowe itd... Ponieważ języka Go jeszcze nikt specjalnie w LaTeXu nie uwzględniłem napisałem swoją własną TeXową łatkę do pliku. Wystarczy ściągnąć najświerzą wersję paczki listings spachować plik lstdrvrs.dtx patchem o poniższej treści:

1615a1616,1648
> % \subsection{Go}
> %
> %
> %
> % \begingroup
> % \begin{macrocode}
> %<*lang2>
> %%
> %% Go language definition (c) Google
> %%
> \lst@definelanguage{Go}%
> {morekeywords={break,default,func,interface,select,%
> case,defer,go,map,struct,%
> chan,else,goto,package,switch,%
> const,fallthrough,if,range,type,%
> continue,for,import,return,var},%
> moredirectives={bool,byte,float32,float64,int8,int16,int32,int64,%
> string,uint8,uint16,uint32,uint64,%
> float,int,uint,uintptr,%
> true,false,iota,%
> nil,%
> cap,close,closed,copy,len,make,new,panic,panicln,print,println},%
> sensitive,%
> morecomment=[l]//,%
> morecomment=[s]{/*}{*/},%
> morestring=[b]",%
> morestring=[b]`,%
> }[keywords,comments,strings,directives]%
> %
> % \end{macrocode}
> % \endgroup
> %
> %

http://jan.koprowski.zhr.pl/tex/lstdrvrs-go.patch

Skompilować komendą make i przekopiować powstałe pliki *.sty do katalogu /usr/share/texmf-texlive/tex/latex/listings

I tyle :] Język Go jest już wspierany przez LaTeXa :]

Ostatnim osiągnięciem, którym chcę się pochwalić jest zrobienie pliku magisterka.sty, który ma za założenie konfigurację niestandardowych dla LaTeXa rzeczy. Na razie znajduje się tam tylko kod dodający kropki za numerami rozdziałów:

%
% Dodawanie kropki po numerze sekcji
%
\def\@seccntformat#1{\csname the#1\endcsname.\space}

LaTeX to rzeczywiście system, godny pisania w nim Pracy Magisterskiej!

Makefile w języku Go

Go jest chyba pierwszym językiem, który wspiera tworzenie Makefile czyniąc je banalnie prostym:

include $(GOROOT)/src/Make.$(GOARCH)

TARG=calc
GOFILES=\
   calc.go\

include $(GOROOT)/src/Make.cmd

Praca magisterska make your knowledge out of date

Pisanie pracy magisterskiej uświadomiło mi jak wiele do życzenia pozostawia aktualność wiedzy zdobytej w trakcie studiów. Zderzenie ze światem Internetu, metodologii będących na topie, praktyk oraz kierunku w jakim poszły języki programowania - zwaliły mnie z nóg. Kiedy zaczynam czytać artykułu w języku angielskim nagle moja wiedza nie tylko przestaje być aktualna, ale wręcz mam wrażenie że "polski internet" stanął w miejscu kilka lat temu. Czuję się bardzo zacofany względem osób na bieżąco dokształcających się z dziedzin dotyczących trendów we współcześnie powstałych języka programowania. Wiadomo - student uczy się sam i tylko od niego zależy co potrafi. Gdy jednak uświadomię sobie na jak "zacofane" technologie musiałem tracić całe godziny wykładów, laboratoriów, prac zaliczeniowych, projektów - gdy tym czasem świat gnał do przodu... To przerażające. Część mojej wiedzy ze studiów można byłoby streścić na jednym wykładzie pod tytułem "historia informatyki" zaś czas marnotrawiony na wkładanie do głów rzeczy nieaktualnych poświęcić za pokazaniem rzeczywistych kierunków zmian w jakim idzie informatyka.

Mam nadzieję, że dożyję czasów kiedy Władze Uczelni przejrzą na oczy i zamiast dodawać swoim pracownikom dodatkowej papierkowej roboty i obowiązków nijak związanych z pracą naukową zostawią wykładowców w spokoju i pozwolą im stawać się coraz lepszymi ekspertami dziedzinowymi, którzy będą w stanie przekazywać studentom naprawdę najświeższą wiedzę. Będąc świadomym ogromu obowiązków kładzionych na wielu pracowników naukowych nie dziwię się, że kolejny raz wykład jest prowadzony z tych samych pożółkłych folii pamiętających czasy przewodu doktorskiego Pana Profesora. Niemniej nikt na tym nie korzysta a student wychodzi z uczelnią na funkcjonujący w obecnie obowiązujących realiach rynek pracy - z wiedzą, która była aktualna dekadę temu.

Szczególnie wielkim wyzwaniem jest tutaj informatyka (oraz prawo) ponieważ te dwa mają najwyższy współczynnik dezaktualizacji w czasie. Wymagają więc ciągłego wysiłku i nieustannej pracy w "bycie na bieżąco".

P.S. Za zacofane technologie nie uważam bynajmniej tak elementarnej wiedzy jak szlify w programowaniu w C czy C++ tudzież sędziwych językach programowania, które po prostu są powszechnie wykorzystywane na rynku z racji na już powstałe i mające się dobrze od dziesięcioleci projekty - patrz choćby jądro Linuksa.