Pokračujeme jinde

30.11.2011 10:44 | programování | Komentářů: 4, poslední 2. 12. 2011 | Hodnocení: 10 % (10 hlasů)

…konkrétně tady

Na čem skutečně záleží při programování

17.6.2010 12:20 | programování | Komentářů: 73, poslední 21. 6. 2010 | Hodnocení: 77 % (22 hlasů)

„Nezáleží na tom, jak dobře umíte řešit hádanky nebo jestli jste nejchytřejší ze třídy. Musíte si uvědomit, že vedle složitosti softwaru je i ten největší talent nepatrný; že samotný intelekt nemůže nikdy vyhrát. Jediné dvě zbraně, které máme, jsou jednoduchost a konvence. Tohle si nechte zrcadlově vytetovat na čelo, aby se vám to věčně připomínalo na monitoru. Když dojde na lámání chleba, záleží na přístupu: na tvrdé práci, zodpovědnosti a na tom, abyste sledovali realitu, nikoliv hlasy ve vlastní hlavě.“ — Jonathan Edwards, Mea Culpa

Jak v gitu rozdělit už mergnuté změny

14.6.2010 09:41 | programování | | Přečteno: 1280× | Komentářů: 28, poslední 16. 6. 2010 | Hodnocení: 75 % (4 hlasů)

Pracoval jsem na nové funkci, pečlivě v samostatné větvi, a ke konci vývoje jsem změny mergnul do hlavní větve a původní feature větev zahodil. Bohužel se chvíli poté ukázalo, že novou funkci ještě na nějakou dobu odložíme, takže bylo potřeba všechny změny zase vyprat z master větve pryč. Čekal jsem, že to bude bolet, a nadával jsem si za zbrklé mergování, ale git je kamarád:

K čemu jsou technické knihy

16.5.2010 10:55 | psaní | Přečteno: 1280× | Komentářů: 3, poslední 16. 5. 2010 | Hodnocení: 100 % (10 hlasů)

Jsem perfekcionista. (Což považuju za nedostatek, nikoliv za přednost.) Když píšu nějaký text, snažím se ho promyslet do důsledků, očesat zbytečnosti, chci aby jeho logika plynula od jedné části ke druhé a podobně. Z toho plyne, že příliš nepíšu, protože mě to stojí moc času. Při psaní včerejšího blog postu jsem si uvědomil, že pro mě (a doufejme i pro ostatní) má cenu i „zbrklejší“ psaní, které sice není tak dobře rozmyšlené, ale zato vůbec vznikne.

Distribuce perlových webových aplikací

15.5.2010 22:20 | programování | | Přečteno: 1041× | Komentářů: 3, poslední 16. 5. 2010 | Hodnocení: 100 % (6 hlasů)

Poslední dobou jsem hodně přemýšlel nad distribucí webových aplikací napsaných v Perlu. Dneska mě napadlo, že bych mohl dosavadní výsledky sepsat „na papír“ — z velké části jako akt psychohygieny, aby se mi úvahy pořád nemotaly v hlavě.

Validace HTML pomocí crawleru

7.1.2010 22:21 | programování | Přečteno: 1052× | Komentářů: 0 | Hodnocení: 100 % (7 hlasů)

Minule jsem si hrál s validací HTML v automatizovaných testech. Jsem s ní spokojený, jen se ukázalo, že by bylo dobré validovat celý web. A navíc nejen validovat – rád bych při každém spuštění testů zkontroloval, jestli mi někde nevisí linky a podobně. Napadlo mě tedy napsat malý crawler, který by web prošťáral a podle potřeby zkontroloval.

Legrace s typovým systémem Perlu 6

4.1.2010 19:15 | programování | | Přečteno: 1385× | Komentářů: 27, poslední 6. 1. 2010 | Hodnocení: 56 % (9 hlasů)

U Ovida jsem narazil jsem na pěkný kus šestkového Perlu, který si hraje s typovým systémem:

Validace HTML v rámci testů

15.12.2009 07:38 | programování | | Přečteno: 1360× | Komentářů: 26, poslední 16. 12. 2009 | Hodnocení: 100 % (6 hlasů)

Dělám na jedné webové aplikaci, u které bych chtěl kontrolovat HTML několika hlavních stránek, jestli jsem se někde neuklepl. Ruční validace se nehodí, protože vyžaduje čas a úsilí a tím pádem by šla dřív nebo později stranou: Pokud není řízení kvality automatizované, jako by nebylo.™ Vzpomněl jsem si, že validátor HTML5 poskytuje webové API.

Jednotkové testy času

27.8.2009 08:43 | programování | Komentářů: 6, poslední 29. 8. 2009 | Hodnocení: 17 % (6 hlasů)

S časem je v jednotkových testech maličko problém. (Co když chci otestovat například funkci, která parsuje data s ohledem na aktuální datum?) V dynamičtějších jazycích se to naštěstí dá vyřešit snadno:

use Test::More 'no_plan';
use Test::MockTime 'set_absolute_time';
set_absolute_time('27/08/2009', '%d/%m/%Y');
# A jedeme.

Základ Test::MockTime je přitom jednoduchý:

BEGIN {
	*CORE::GLOBAL::time = \&Test::MockTime::time;
	*CORE::GLOBAL::localtime = \&Test::MockTime::localtime;
	*CORE::GLOBAL::gmtime = \&Test::MockTime::gmtime;
}

Kult hotového

24.8.2009 18:12 | psaní | Přečteno: 1556× | Komentářů: 9, poslední 25. 8. 2009 | Hodnocení: 89 % (9 hlasů)

Manifest kultu hotového. Přeložený za deset minut, protože právě tolik jsem měl, abych překlad dokončil:

Kvantová fyzika v Perlu

20.8.2009 19:36 | programování | Komentářů: 40, poslední 23. 8. 2009 | Hodnocení: 100 % (5 hlasů)

use Modern::Perl;
use Perl6::Junction qw/any all/;
my @numbers = 1..5;
say "Yes" if any(@numbers) == 3;
say "Nope" if not all(@numbers) == 5;

Není to hezké? Viz Perl6::Junction a Exegesis 6.

Jak v gitu při merge konfliktu přijmout celý soubor

9.7.2009 08:19 | programování | Komentářů: 10, poslední 11. 7. 2009 | Hodnocení: 80 % (5 hlasů)

Při mergování běžně narážím na problém s projektovými soubory Xcode, které jsou sice textové, ale automaticky se příliš mergovat nedají a ručně je to nereálné, protože jde o stovky řádek XML. Naštěstí se většinou dá jednoduše použít verze z novější větve. Chvilku jsem musel hledat, než jsem zjistil, jak při merge konfliktu přijmout celý soubor z mergované větve:

$ git merge spawner-rewrite
…
Auto-merging Source/Paperworks.xcodeproj/zoul.mode1v3
CONFLICT (content): Merge conflict in Source/Paperworks.xcodeproj/zoul.mode1v3
Auto-merging Source/Paperworks.xcodeproj/zoul.pbxuser
CONFLICT (content): Merge conflict in Source/Paperworks.xcodeproj/zoul.pbxuser
Automatic merge failed; fix conflicts and then commit the result.
$ git checkout --theirs Source/Paperworks.xcodeproj/zoul.{mode1v3,pbxuser}
$ git add Source/Paperworks.xcodeproj/zoul.{mode1v3,pbxuser}
$ git commit -m "A je to."

Stejně by ale bylo pěkné, kdyby byl k dispozici nějaký specializovaný merge skript pro soubory Xcode.

Zkrácené příkazy v gitu

6.7.2009 08:14 | programování | | Komentářů: 9, poslední 7. 7. 2009 | Hodnocení: 75 % (8 hlasů)

Potřeboval jsem nějakou dobu pracovat offline, a když jsem hledal nástroje pro offline práci se Subversion, nakonec jsem skončil u gitu (konkrétně u git-svn). Jsem nadšený, jen mi trochu chyběla tolerance Subversion při zadávání příkazů. Zatímco Subversion stačí říct svn co a ono už si samo doplní co → checkout, git mě vždycky nechá vydusit. Nakonec jsem ale zjistil, že krátké varianty jdou nastavit pomocí aliasů:

$ git config --global alias.co checkout
$ git config --global alias.st status

A jsem spokojený pantáta!

Jak jsem se nachytal na ukazatelové aritmetice

1.7.2009 20:22 | programování | Přečteno: 1304× | Komentářů: 13, poslední 3. 7. 2009 | Hodnocení: 75 % (4 hlasů)

Psal jsem dneska jednoduchou třídu pro animované sprajty v OpenGL. Abych nemusel texturovací souřadnice počítat při každé změně snímku, předpočítal jsem si je všechny předem do bufferu. Když pak dojde na kreslení snímku, texturovací souřadnice zadám jednoduše jako offset do tohohle bufferu. V principu velmi jednoduchý kód, ale stejně se mi v něm podařilo vyrobit chybu, kterou jsem pak dlouho a nespokojeně hledal. Je to klasický přehmat v ukazatelové aritmetice – býval bych řekl, že takovou chybu bych neudělal, no ale zjevně ano:

REPL v Perlu

24.6.2009 19:02 | programování | Přečteno: 1027× | Komentářů: 2, poslední 24. 6. 2009 | Hodnocení: 75 % (4 hlasů)

A ještě jednou Perl, tentokrát REPL. REPL je praktická věc, zvlášť při ladění. Zvykl jsem si do některých svých modulů v průběhu vývoje a testování strčit malou funkci, díky které se dá modul v případě potřeby spustit jako běžný perlový skript a zobrazí REPL, ve kterém si s ním můžu hrát:

Moderní Perl

24.6.2009 12:05 | programování | Komentářů: 5, poslední 25. 6. 2009 | Hodnocení: 100 % (5 hlasů)

Včera vydal chromatic moc pěkný blogpost, ve kterém shrnuje některé moderní způsoby psaní v Perlu – Moose, výjimky a podobně. Příjemná drobnost je například psaní CLASS místo ošklivého __PACKAGE__ nebo Modern::Perl, díky kterému by se podobné moduly časem mohly dát zapnout jedním řádkem kódu.

Základní problémy Linuxu na desktopu

13.4.2009 08:40 | programování | Přečteno: 2290× | Komentářů: 111, poslední 16. 4. 2009 | Hodnocení: 28 % (36 hlasů)

Zajímavý post o tvůrčím procesu, ve kterém autor dobře vystihuje i jeden ze základních problémů linuxového desktopu:

In fact, it’s far more common to go backwards: to see just the surface gloss of something and try to mimic that, with no understanding at all of the decisions that inform the rest of the work, and how they depend on each other. (…) Our equivalent is the UI “skin”, like the hackery that can make a Windows or Linux desktop look like Mac OS X, but can’t change the fact that everything below the surface is built up with the respective ideas of those operating systems.

Jak se pozná dobře napsaný kód

22.3.2009 09:18 | programování | Komentářů: 5, poslední 25. 3. 2009 | Hodnocení: 100 % (9 hlasů)

Prohlížím si zdrojový kód Kokosu a srovnávám ho s tím, co jsem psal pro BubbleHeada. Je zajímavé sledovat, jak podobné problémy jsme řešili. Přicházím na to, že i problémy, které jsem původně měl za relativně složité, se často dají vyřešit velice jednoduše. Zatímco ze špatně navrženého kódu abych každou funkci páčil heverem, dobře navržený kód bývá jednodušší, přehlednější a nové možnosti mi sám vnucuje. Když se člověk nad kusem kódu nadře, je lepší se zamyslet, jestli to nejde jednodušej. („It’s not meant to be / a struggle uphill.“) Odtud ostatně lenost jako jedna z hlavních programátorských ctností. Teď už jen vystihnout tu hranici…

Why Writing an Introductory Book is Not Easy

3.3.2009 11:29 | psaní | Přečteno: 1189× | Komentářů: 52, poslední 8. 3. 2009 | Hodnocení: 40 % (25 hlasů)

This might be obvious, but writing for beginners is harder than writing for experts. In other words, writing a good programming tutorial is harder than writing a good stack overflow tutorial.

How Not to Write a Programming Book

1.3.2009 18:51 | psaní | Přečteno: 1684× | Komentářů: 46, poslední 5. 3. 2009 | Hodnocení: 73 % (15 hlasů)

By this post I would like to start a longer series about common mistakes made by authors in programming books. If I waited until I was happy with the thoughts expressed in the post, I would most probably never finish a single one. Therefore I will intentionally publish the text a bit raw and maybe return to the interesting thoughts in subsequent posts or even edit the post after publishing. I will start with what seems to be my favourite topic lately, with bogus code samples.