-
Z čeho se staví dům
Minule jsem se rozepsal o tom, jak se staví dům svépomocí, ale nedostal jsem se k tomu, z čeho je postaven. Shrnuji, co jsme si vybrali a proč a případné poučení. Původně jsme uvažovali o dřevostavbě, ale od té jsme nakonec upustili. Především si myslím, že s nimi nemají čeští řemeslníci dostatečné zkušenosti, a ani nevím, ke komu bych si chodil pro radu. Jistěže chceme bydlet rychle, ale je tu i otázka velkých úspor na hrubé stavbě, na kterou si v případě cihel troufnu. V neposlední řadě je to otázka tepelného komfortu. Je sice krásné, že prostor rychle vytopíte, ale bude vám chybět tepelná akumulace; především v létě, kdy budete mít problém dům uchladit. -
Stavebnictví versus softwarové inženýrství
Máme tendenci neustále něco srovnávat. I softwarové inženýrství srovnáváme. S vojenstvím, strojírenstvím nebo se stavebním inženýrstvím. Martin Fowler v článku New Metodology, který byste si měli rozhodně přečíst (i když je dlouhý), popisuje motivace a vznik agilních metodik a vyvozuje závěr, že pro softwarové inženýrství je takové srovnání zavádějící. Přeložil jsem několik vybraných odstavců a doplnil o svoje poznámky.
-
Jak se staví dům svépomocí
Správný muž by měl zplodit syna, postavit dům a zasadit strom. A to v tomhle pořadí, abyste totiž nebudovali ohromné sídlo, ve kterém nakonec budete bydlet sami, což se nezřídka stává. Zrovna dům stavím a na twitteru občas zmíním nějaké detaily. Objevilo se několik ohlasů, že by vás zajímaly podrobnosti, obzvlášť protože stavím částečně svépomocí. Tady jsou. Především je celá stavba lekce trpělivosti a pokory a v neposlední řadě i kvalifikace na projektového manažera. Důležité je mít na paměti, že i když se nastěhujete a začnete bydlet, tak deset let dostavujete, pak si dáte rok pauzu a začnete opravovat. Jo a až budu stavět třetí dům, tak ten bude nejlepší, jelikož konečně budete vědět, jak na to.
-
Nepotřebujete UX, ale zdravý rozum
Nejsem ani zdaleka tak pokorný, abych se řídil heslem kamarádova otce: „Nemůžeš-li pochválit, tak alespoň mlč.“ Jedna z mých zvídavých otázek, které kladu u přijímacího pohovoru jako uchazeč je, zda mají HCI designéra. Potřebujete přinejmenším někoho, kdo má zdravý rozum a četl třeba knihu The Design of Everyday Things. Na dvou službách od Seznamu bych chtěl ukázat, jaké klacky jsou uživatelům házeny pod nohy. Klidně to berte tak, že si chci jen zchladit žáhu. V lepším případě tak, že chci upozornit na to, jak mohou zlepšit své služby.
-
Kde mě tlačí bota - code review
Mám poměrně jasnou představu, jak by měla vypadat organizace softwarového projektu. Mimo jiné dokola přesvědčuji, že je potřeba psát testy a instaluju nástroje na statickou analýzu kódu. Už to mám nacvičené. Ovšem čím dál tím víc mi chybí code review. Ještě jsem toto téma zatím uspokojivě neuchopil, ale minimálně jsem se zamyslel, jak bych z toho chtěl vybřednout, ačkoliv jsem tak ještě neučinil.
-
Voda ve vaší studni není vaše
Jsem za exota, když tvrdím, že voda ve vaší studni není vaše. Konkrétně hájím rozhodnutí Odboru životního prostředí a památkové péče, který mi ve svém povolení k nakládání s vodami stanovil (na základě projektu) maximální odběr 504 l pitné a užitkové vody na den (počítáno pro čtyři lidi), což činí 184 m3 na rok. Srovnám-li to s měřením spotřeby v bytě, je to víc než velkorysé, protože jsme si vystačili se 104 l na člověka a den. Budu sice zalévat zahradu, ale k tomu bude ještě sloužit dešťová voda a vyčištěná odpadní voda. Největší emoce ovšem vyvolává to, že mi předepsali vodoměr (zápis co tři měsíce, archivace pět let).
-
Jak lépe na abstract entity v JPA
Absolvoval jsem svůj doposud nejlepší technický pohovor (ne, v Google přijímací pohovor rozhodně lepší nebyl). Nikdo nedělal ramena s asymptotickou složitostí apod. Ba právě naopak to bylo velmi inspirující. Kromě toho, že jsem pochytil takové drobnosti jako unixový příkaz tree, jsem se hlavně přiučil, jak psát lépe abstract entity v JPA. SoftWare Samuraj měl pochopitelně k mému kódu zvídavé otázky a podnětné připomínky, které mě přiměly se na kód znovu podívat a zamyslet se.
-
Inherit javadoc
Jak píšete javadoc u implementací rozhraní nebo u překrytých metod? Léta jsem používal výchozí generovaný javadoc v Eclipse
(non-Javadoc) @see
, později jsem přešel na standardní
{@inheritDoc}Nedávno jsem si na twitteru stěžoval, že v Intellij Idea není možné si potřebnou šablonu upravit. Připadám si jak z té historky, ve které dcera celý život pekla štrúdl tak, že vždy před vložením na plech zařízla patky, protože to tak pokaždé dělala i její matka. Předpokládala, že je to součást receptu, že to tak bude prostě lepší. Ovšem matka to dělalal proto, že měla malý plech a štrúdl by se jí tam celý nevešel.
-
Hackeři a malíři
Z esejů Paula Grahama jsem již (s laskavým svolením) přeložil Přebal Javy. Nyní se dostávám k delší a hlubší úvaze, kterou lze označit za kultovní. Původní text Hackers and Painters. (překlad uvolňuji pod licencí Creative Commons by-nc-sa)
Květen 2003
Tento esej vznikl z hostující přednášky na Harvardu, která zahrnovala dřívější proslov na Northeastern University Boston.
Když jsem dokončil inženýrské studium informatiky, šel jsem na uměleckou školu studovat malířství. Mnoho lidí, zdá se, překvapilo, že někdo, kdo se zajímá o počítače, by se také mohl zajímat o malířství. Očividně si mysleli, že hackování a malířství jsou velmi odlišné druhy práce - hackování je chladné, přesné a metodické; zatímco malířství je bouřlivé vyjádření nějakého prapůvodního nutkání.
Oba tyto pohledy jsou nesprávné. Hackování a malířství toho mají mnoho společného. Ve skutečnosti jsou všichni tito rozdílní lidé (hackeři a malíři), které znám, podobní.
Hackeři a malíři mají společné to, že obě skupiny jsou tvůrčí. Spolu se skladateli, architekty a spisovateli se hackeři a malíři snaží dělat dobré věci. Nedělají výzkum jako takový, přesto objeví-li při samotném pokusech o dobru věc nějakou novou techniku, tím lépe.
-
Proč programátoři odcházejí
Měním zaměstnání. Jsem tedy často dotazován: „Proč?”. Rozhodl jsem se především proto, že jsem chtěl alespoň částečně pracovat z domova. Nicméně důvody k odchodu z firmy lze zobecnit na několik málo příčin.
V článku How To Keep Your Best Programmers, který rozhodně stojí celý za přečtení, Erik Dietrich tyto příčiny vyjmenovává. Mimoto rozvádí teorii bodu zlomu, nudy jako vyčerpatelného přídělu a efekt Mrtvého moře. Navíc nabízí řešení, jak si nejlepší programátory udržet.
#/media/File:Java_programming_language_logo.svg){kind=logo}
subscribe via RSS
