Validace HTML v rámci testů

15.12.2009 07:38 | programování | | Přečteno: 1329× | 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: 1524× | 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: 1274× | 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: 982× | 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: 2250× | 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: 1148× | 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: 1644× | 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.