Darmowe rzeczy są dobre, bo są dobre i darmowe

Nie ma to jak dostać coś wartościowego za darmo. Wiele osób twierdzi, że na tym polega ruch otwartego oprogramowania. To nie do końca jest prawdą, bo można zarabiać na oprogramowaniu open source, a wręcz je sprzedawać. Faktem jednak jest, że coraz więcej materiałów w Internecie jest (legalnie) dostępna za darmo. Dzisiaj chciałem zwrócić uwagę na trzy książki, które warte są poznania, kiedy zabieramy się do pracy z językami programowania Haskell i Ruby.

Naukę języka Haskell można zacząć, korzystając z Wikibooks. Dostępna tam jest książka o tym języku. Obejmuje treścią niemal wszystko co z Haskellem się wiąże, chociaż nie każdy fragment książki został dopracowany, jak to często z Wiki bywa. To, co jest już napisane, jest jednak naprawdę porządną porcją wiedzy, zarówno dla zaczynających poznawanie języka jak i dla chcących poznać go lepiej.

Drugą pozycją o języku Haskell, bardzo obiecującą ale jeszcze nie skończoną, jest książka "Real world Haskell", która stanowi przystępnie napisane wprowadzenie do języka. Powstaje ona dosłownie na oczach jej czytelników, ponieważ kolejne fragmenty pojawiają się na stronie w miarę, jak autorzy książki je tworzą. Dodatkowo, każdy akapit można komentować, sugerując zmiany lub błędy (ten sposób pisania książki można by nazwać zgodnym z Web 2.0).

Wiele osób poznających język Ruby z kolei na pewno zna już ten adres: "Programming Ruby - The Pragmatic Programmer's Guide". Są tacy, którzy uważają Pickaxe (jak popularnie zwana jest też ta książka) za angielskojęzyczną biblię programistów Ruby. Dla wszystkich tych jednak, którzy nie trafili jeszcze pod wyżej wymieniony adres mam informację - to podstawowy zbiór informacji o języku Ruby. Nie jest to niestety książka do nauki stylu programowania w tym języku, ale jako baza wiedzy o składni i bibliotece standardowej (do wersji 1.6) jest niezastąpiona.

Życzę wszystkim dobrej lektury na święta!

Z archiwum X

Każdy kto na poważnie zajmuje się programowaniem w Javie zetknął się z przełącznikami, które można ustawiać przy wywołaniu wirtualnej maszyny. Naturalnie w większości przypadków wystarczają trzy:

• -jar do wskazywania archiwum Jar zamiast pojedynczego pliku klasy
  
• -cp (lub -classpath) do ustawiania ścieżki klas
  
• -Xmx do ustawiania maksymalnej wielkości stosu (przydatne zwłaszcza przy pracy ze środowiskami typu Eclipse czy Netbeans)
  

Ten ostatni to tak naprawdę tylko jeden skromny przedstawiciel bardzo płodnej rodziny przełączników X. JVM od Suna posiada ich mnóstwo, a implementacje od IBM czy Bea również posiadają swoje zestawy. Jak się w tym połapać? Na szczęście jest strona która zbiera wszystkie przełączniki w jednym miejscu (chociaż tylko z implementacji Sunowskiej) - "A Collection of JVM Options". Podane są przełączników nazwy, wartości, wersje JVM które je obsługują, a spora część z nich jest całkiem dobrze opisana (chociaż nie znalazłem tam np. niekiedy cennej informacji że przełącznik -client jest zawsze domyślnie włączony w JVM dla systemów Windows).

Od teraz będę już wiedzieć jak sprawić żeby JVM zauważył że jest w środowisku 64-bitowym (-d64), włączyć zapisywanie do pliku logu akcji odśmiecania pamięci (-Xloggc), wymusić użycie maksymalnej dostępnej pamięci (-XX:+AggressiveHeap) czy wyświetlić ilość użytej pamięci stosu (-XX:+PrintHeapUsageOverTime). Masa innych trików czeka jednak na swoich odkrywców, a więc do dzieła!

Unikanie błędów

Tytuł tego posta jest dość chwytliwy. Kto nie chciałby unikać błędów w życiu? Wiedzieć z góry, że kupno tamtego mieszkania będzie oznaczało nieustanną walkę z grzybkami na suficie albo że autobus, do którego ma się zamiar wsiąść, ma zamiar się w połowie drogi zepsuć?

Tutaj chciałbym jednak zwrócić uwagę na jeden specyficzny sposób unikania błędów podczas tworzenia oprogramowania. Sposób jest bardzo prosty - pisać mniej kodu. Po chwili zastanowienia można zauważyć, że pomysł jest wręcz oczywisty, bo nie da się zrobić błędu w linii kodu, która... nie istnieje.

Kolejna chwila zastanowienia nad powyższym sposobem unikania błędów prowadzi do wniosku, że idealnie byłoby nie pisać kodu w ogóle. Zero kodu = zero błędów! Nirwana! Chociaż może nie do końca, bo tworzone oprogramowanie miało mieć jakąś funkcjonalność, a skoro nic nie napisaliśmy, to próżno szukać tej funkcjonalności.

Jak w takim razie pisać mniejsze ilości kodu, a mimo to z powodzeniem dostarczać gotowe oprogramowanie? Jest parę sposobów:

• używanie generatorów kodu - to rozwiązanie wykorzystujące fakt, że większość programów IDE ma funkcje wstawiania gotowych fragmentów kodu (np. klasyczne getters / setters dla pól obiektów w Javie); ten sposób oznacza tylko, że programista sam nie musi pisać kodu, który jednak i tak powstaje, więc nie tędy droga
  
• stosowanie zasady DRY (ang. "don't repeat yourself" - "nie powtarzaj się") - z czystym sumieniem mogę ten sposób polecić; trzymanie się głównej wytycznej DRY będzie powodować zapalenie się ostrzegawczej lampki za każdym razem, gdy spróbujemy po raz kolejny napisać to samo
  
• używanie języków wyższego poziomu - to najbardziej kontrowersyjny sposób i naturalnie nie zawsze możliwy do zastosowania; pamiętając o tym, należy jednak mieć świadomość korzyści, które niesie ze sobą język wysokiego poziomu - możliwość wyrażania myśli bardziej bezpośrednio w kodzie; jako ilustracja niech posłuży króciutki kod w języku Haskell obliczający pierwiastek liczby metodą Newtona:
  

  -- funkcja "sqrt" zwraca nieskończony ciąg kolejnych
  -- przybliżeń wartości pierwiastka, z którego możemy
  -- wybrać np. piąte jako wystarczająco dobre
  sqrt x = sqrtNewton x 1
  
  sqrtNewton x guess = average : sqrtNewton x average
  where
  average = (y + (x / guess)) / 2

Pozostaje tylko problem, co zrobić z kodem, który już został napisany i przypomina objętością miłośnika Big Mac'ów? Odpowiedź wykracza już poza tego posta, ale w największym skrócie - używając refaktoryzacji stosować się do zasady DRY.

A więc - miłego (nie)pisania kodu!

Zamienił stryjek sIEkierkę na kIEk

Sporo mojej pracy dotyczy aplikacji WWW (web applications). Z tego powodu należę do dużej grupy ludzi niezadowolonych - to najłagodniejsze określenie - z powodu konieczności użerania się z produktem Internet Explorer firmy MS, a konkretnie z jego silnikiem renderującym strony HTML. Powstało mnóstwo stron opisujących błędy tego silnika oraz sposobów ich obejścia, nie zawsze niestety skutecznych. Wiele napisano również o tym, jak bardzo zacofana jest w IE obsługa standardów (szczątkowa obsługa CSS 2 - pochodzącego z 1998 roku, brak obsługi XHTML 1.1 - to rok 2001 się kłania, brak wsparcia dla SVG 1.1 - zatwierdzonego w 2003 roku). Jednak miesiąc temu na blogu IE pojawiła się pierwsza jaskółka nadziei: kolejna, 8. już wersja IE, ma być zgodna z CSS2! Niedługo potem z piekła zaczęły docierać sygnały o wyraźnym ochłodzeniu.

Minął miesiąc i oto na tym samym blogu pojawia się wpis "Compatibility and IE8". I wszystko wraca do normy. Owszem, IE8 będzie poprawnie(*) obsługiwał CSS2, ale... mało kto się o tym dowie, bo ten tryb "super-zgodności-a-nie-jak-do-tej-pory-takiej-zwykłej-zgodności" będzie się włączał tylko na specjalne życzenie wyświetlanej strony (po dodaniu do niej odpowiedniego tagu <meta>). Czyli po raz kolejny (po sztuczce z odpowiednio spreparowanym DOCTYPE i komentarzami-instrukcjami "if IE") pojawi się hak / przełącznik / obejście dla poprzednio zepsutych implementacji. To już przestało być śmieszne, chociaż co bardziej wytrwali w komentarzach do wpisu na blogu dowcipnie i z sarkazmem sugerują że w IE9 będzie tryb "hiper-zgodności-tym-razem-to-już-naprawdę" włączany np. głośnym klaśnięciem w dłonie...

(*) oczywiście może się okazać, że będzie to "poprawnie", ale tylko w microsoftowym znaczeniu tego słowa; pożyjemy zobaczymy