Przetwarzanie u klienta a requesty do serwera

Dwa dni temu trafiłem na ciekawe zagadnienie. Mam około 166 KB danych w postaci wartość: klucz i mam taką listę odfiltrowywać w jquery ui autocomplete. Początkowo bardzo chciałem uniknąć ciągłego odpytywania serwera więc napisałem filtrowanie pełnej listy w jQuery mniej więcej tak:

source: function(request, response) {
if (cache.length > 1) {
matched = jQuery.grep(cache, function(element, index) {
return element.name.search(request.term) != -1;
});
return response(matched);
}
$.getJSON("/javascript/data.json", function(data) {
cache = data;
response(data);
});
},

Byłem szalenie zaskoczony gdy to rozwiązanie okazało się wolne! Wciąż słyszę tylko, że JavaScript jest wciąż przyspieszana, że któryś z silników prześcignął inny i potem znowu, że ktoś znowu bije rekordy szybkości JS... a tutaj takie zaskoczenie.

Generalnie pierwsze wpisanie litery pobierało wszystkie dane, które po pierwszym pobraniu, które trwało naprawdę długo potem zaczynały już szybciej się filtrować, ale nadal to było toporne. Testowałem to w Chrome 4 i powiem szczerze. To nie działało jakoś super szybko. W ogóle się tego nie spodziewałem. Jak jeszcze pomyślałem, że > 50% użytkowników wyszukiwarki to IEowcy... nie, to nie miało szans powodzenia. Nawet kiedy Chrome działało tak sobie.

Generalnie szybko zakodowałem standardową wersję z bazą danych, odpytywanie serwera przy każdej literce. Zaczęło działać naprawdę dobrze. Plusem było na pewno to, że można było ograniczyć zapytanie do 10 wyników, a nie pakowało się 166KB danych. Tego mi w sumie zabrało w jQuery, żeby był parametr do funkcji grep, który mówi po ilu elementach przerwać - może wtedy byłoby szybciej.

Podsumowując: jeżeli masz do wyboru pobrać dużo danych do JS i filtrować je u klienta, a zrobić standardowo filtrowanie po stronie serwera i odpytywać o wyniki serwer - wybierz drugie, chyba, że znasz sprytniejszy sposób zrobienia tego co ja próbowałem po stronie JS.

Przygoda z Merbem i jak przeszedłem na Sinatrę

Dzisiejszej nocy nadszedł czas, gdy miałem okazję zmierzyć się wreszcie z Merbem. Znany mi świat frameworków to raczej rozwiązania typowe dla Pythona. Byłem bardzo mile zaskoczony poznając świat frameworków Ruby.

Do tej pory nie było żadnego małego projektu, od którego można byłoby zacząć naukę. Stworzenie wyszukiwarki dla kampani 1% dla ZHR.pl było fantastyczną okazją do liźnięcia Merba.

Pierwszym rozczarowaniem, była walka z samym Merbem. Zainstalowałem nowe gemy Merba 1.1.0. Pamiętał, że jest coś takiego jak wersja flat aplikacji. Bardzo zależało mi na tym właśnie modelu. Już na samym początku trafiłem na bug Merba #712. To było niestety bardzo bolesne spotkanie z rzeczywistością, które pozostawiło mnie bez złudzeń - Merb nie jest już rozwijany.

Kolejną niemiłą niespodzianką było odpalenie mongrela. Na szczęście tutaj pomogło dodanie require 'mongrel' do skryptu merb w katalogu bin projektu i skorzystanie z tak zmodyfikowanej binarki. Co gorsza, wcześniej straciłem kilkadziesiąt minut na odpalaniu webricka, który w ogóle nie łykał urlsów.

Skoro już jesteśmy przy dodatkowym sofcie. Najnowsza wersja Haml 3.0.2 nie radzi sobie z renderowaniem SASS, który kończy się błędem jak w issue #163. Wszystko działa natomiast bez problemu z najnowszą wersją Haml z gałęzi 2. Aha. Najlepsze jest to, że istnieje masa nieaktualnej dokumentacji. Szczególnie bolesne gdy chodzi o włączenie SASS. Nawet dokumentacja SASS podaje jakieś lewe informacje. Dopiero ten wpis pozwolił mi prze konwertować SASS do CSS.

Takie przygody to chleb powszedni, jeżeli oprogramowanie nie jest rozwijane od ponad roku. Nie ma się co dziwić. Najgorsze jest dla mnie to, że w Rails 3 nie ma czegoś takiego jak merb-gen flat czy merb-gen very_flat. Można obciąć to co generuje Rails 3 ale to wciąż nie jest minimalna aplikacja z własną konfiguracją. Trochę pocieszyła mnie Sinatra. Kiedy w niej kodowałem to przypomniał mi się Pythonowy WerkZeug, z tym, że w przeciwieństwie do tego drugiego Sinatra działa :P Ciekawe, że Sinatra to DSL :) co daje bardzo miłe wrażenie kodowania w zetknięciu z nią :]

Kiedy przenosiłem aplikację z Merba na Sinatrę to właściwie jedyne co musiałem zrobić poza przekopiowaniem plików statycznych i widoków to zmienić rozszerzenie widoków HAML. Reszta sama poszła. Bardzo spodobał mi się minimalizm Sinatry, który w przypadku wyszukiwarki jaką piszę był w dziesiątkę! Niestety to nie to samo co modularny Merb, który jak trzeba było to poza wygenerowanie małej aplikacji potrafił i kapcie przynieść i kawę zaparzyć. Rails nie posiada tak rozwiniętej modularności w stopniu w jakim została stworzona w Merbie - a szkoda.

Jeżeli miałbym porównać świat frameworków Pythonowych i Rubowych to tutaj jest jak z językiem - Python prosto, Ruby z dużo bogatszym wachlarzem możliwości. Mam wrażenie, że deweloperzy Pythona skupili się na prostocie jako celu, gdzie w Rubym widać dążenie do niej ale przez wszystkie etapy ogólności, które widać w wielu narzędziach.

Na tle tych przygód jest jeszcze gdzieś Scala, która wydaje mi się tak zaawansowana, że aż nie widzę dla niej zastosowania w projektach, które tworzę. To jest chyba jakiś target heavy enterprise a ja jeszcze w tych kategoriach nie myślę. Szalenie podoba mi się tutaj Merb, w którym możesz zacząć sobie dewelopować aplikację od jednoplikowej wersji very_flat po typowo railsowym bufoniastym systemie układu katalogów skończywszy. Szkoda, że Rails 3 nie daje takiego wyboru. Na szczęście jest Sinatra :) jednak jak już pisałem, Merb był gdzieś pomiędzy i szkoda, że go już nie ma.

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!