Testing Zend Framework 1 apps with PHPUnit 3.7+ [EN]

Great Zend Framework apps definitely should have automated tests. ZF helps you with that by providing PHPUnit extension which allows you to test controllers – adds special asserts for response and DOM queries. But there is a big downside – it works only with PHPUnit 3.4. I agree with the goal to maintain ultimate backwards compatibility, but I prefer to use latest versions of my tools. So I have latest PHPUnit installed for testing other apps and 3.4 for testing ZF1 apps (see this tutorial to install PHPUnit 3.4 and the latest one). I hate having to set up two PHPUnits after reinstall (and setting them up on CI server).

So I decided to fix the Zend_Test (for myself) to work with latest PHPUnit. I originally thought I would have to do it myself, but then I found this patch (thanks!) which I have applied to a branch in my fork of ZF1.

After that, I needed to fix my tests to work with latest PHPUnit. Luckily it meant just replacing assertType() with assertInstanceOf().

Shortly, you need to do this:

  1. Fix the Zend_Test (see diff)
  2. Fix your tests
  3. Get rid of the old PHPUnit 3.4
  4. Profit

After that the tests run fine with latest PHPUnit.

If you have any questions or trouble fixing ZF1 and tests for latest PHPUnit, feel free to ask in the comments.

Jak propojit KeePass s Google Chrome?

Pokud si z článku nepřečtete nic dalšího, tak si prosím alespoň u e-mailu nastavte heslo, které nebudete používat nikde jinde!

Používáte všude stejné heslo? Víte, že když pak někdo prolomí nějakou špatně zabezpečenou službu (např. LinkedIn), tak získá vaše heslo, které pravděpodobně využíváte na spoustě dalších míst.

Určitě je mnohem lepší mít alespoň k e-mailu jiné heslo než k webům (službám, e-shopům) kam zadáváte svůj e-mail. Protože pokud by někdo získal heslo k vašemu e-mailu, tak si snadno může nechat zaslat „zapomenuté heslo“ z jakékoliv další služby.

A úplně nejlepší je mít unikátní heslo pro každý web, kam se přihlašujete. A ideálně pokud je trochu složitější :)

Samozřejmě nemá smysl si pamatovat tolik hesel. Můžete si je psát na papír, nechat ukládat v prohlížeči, nebo využít nějaký specializovaný program jako je KeePass nebo LastPass. Já používám KeePass a zjistil jsem, že spoustu lidí neví, že ho jde snadno propojit s Google Chrome a nechat si hesla doplňovat automaticky. Takže jak na to?

Nastavení KeePassu

  • Stáhněte si KeePass – doporučuji Portable KeePass 2.22 (ZIP Package) a rozbalte ho (ideálně do Skydrive nebo Dropboxu)
  • Stáhněte si plugin na propojení s prohlížečem a umístěte ho do adresáře KeePassu (tam kde je KeePass.exe)
  • Nastavení KeePassu tady nemá cenu rozepisovat, pěkně to popsali na CNews
  • Jediná věc, kterou zdůrazním – u uložených hesel je potřeba mít vyplněnou URL

Nastavení Chrome

  1. Do Chrome je potřeba nainstalovat rozšíření chromeIPass
  2. Klikněte na ikonu vedle adresního řádku a zvolte Connect

3. Přepněte se do KeePassu – tam uvidíte následující okno – potřebuje si uložit klíč pro šifrování komunikací – nějak ho pojmenujte 

4. Pokud pak přejdete na stránku, jejíž adresu máte v KeePassu vyplněnou u nějakého hesla, zobrazí se okno, kde se KeePass ptá, jestli dovolíte přístup daného webu k záznamu v KeePassu. Zkontrolujte, že vše sedí a zatrhněte „Remember this decision“, abyste to nemuseli potvrzovat pokaždé. 

5. Čárymáryfuk a jméno s heslem jsou předvyplněné. 

Pro Tips:

  • Existuje obdobné rozšíření pro Firefox – PassIFox
  • rozšíření vás umí automaticky přihlásit do webů, které mají HTTP autentizaci

Jak pracujete s hesly vy? Pochlubte se v komentářích!

Nedaří se vám to nastavit? Zeptejte se!

Jak v Jenkinsu buildovat branche z forků?

bakalářce jsem psal o tom, jak nastavit a používat Jenkins pro statickou analýzu PHP projektů. V té době jsme ještě na Shopiu používali Subversion, takže build byl nastavený pro trunk a všechno bylo krásné a sluníčkové.

Po přechodu na git (a Github) jsme začali používat koncept „forků“ a PullRequestů (každý vývojář má svoji kopii – fork – hlavního repositáře, jednotlivé změny dělá v branchích a ty pak odešle jako PullRequest a jiný vývojář je zkontroluje a mergne).

Problémem bylo, že přestože většinou spouštíme testy lokálně před vytvořením PullRequestu, tak občas po mergnutí build na Jenkinsu spadnul na neprocházejících testech. Jenkins běží na Linuxu, vyvíjíme na Windows, takže občas šlo o problém s konci řádků, ale většinou o nějaký problém s pořadím testů (na Linuxu je jiné, a ano, vím že je velmi špatně mít testy závislé na stavu prostředí, ale lepší mít takové než žádné). A občas šlo samozřejmě o chybu a nespuštěné testy na localhostu („Tohle přece žádný test rozbít nemůže!“). Takže by bylo super testy spouštět automaticky pro každou změnu v jakékoliv branchi ve forku každého vývojáře.

V Jenkinsu to nakonec šlo nastavit velmi snadno – vytvořit jsem pro každý fork samostatný projekt a nastavil cesty k jednotlivým Githubovým repositářům. Pak je důležité nastavit, aby se v rámci buildu forku spouštěl jen phpunit a nic jiného – chceme co nejdříve vědět, že testy neprocházejí a nějaké porušení coding standards nás v tu chvíli tolik netrápí.

Druhou věcí, co je potřeba nastavit jsou branche pro buildování: 

A samozřejmě nastavit, aby v případě failu přišel mail danému vývojáři: 

Ještě jedna věc – je dobré, pokud mají tyhle rychlé buildy přidělené svoje vlákno, aby nečekaly dobu ve frontě, než doběhne jiný projekt (tohle zatím nastavené nemáme, ale budeme mít brzy).

Pro opensource projekty existuje super věc – TravisCI, který dělá přibližně to samé – builduje všechny vaše branche a na Githubu se dokonce stav branche ukazuje u PullRequestu

3 tipy pro pohodlnější život

1. Jak vyřešit připečené zbytky v toustovači?

Pečete si občas tousty? A točí vás, že pokud z nich vyteče sýr, tak pak musíte toustovač čistit?

Zkuste ho vyložit pečícím papírem a už ho nebudete muset čistit. Papír vydrží na několik pečení.

2. A menší nemáte?

Určitě to také znáte, vyberete si z bankomatu a pak když chcete platit větší bankovkou, tak s ní prodavači většinou mají problém. Ono taky platit rohlíky ke svačině tisícovkou není úplně vhodné.

Některé moderní banky umí ve svých bankomatech zobrazit výběr bankovek (nejdříve to uměla Air Bank; teď už i UniCredit, Česká spořitelna, Raiffeisenbank – ale ty jen v části bankomatů).

Pokud to vaše banka neumí, tak stačí místo celých tisíců vybírat o 100 méně – třeba 1900,– místo 2000,– a dostanete i drobnější bankovky.

3. Neklikejte na podezřelé odkazy! A když už, tak…

Pokud narazíte na nějaký podezřelý odkaz (třeba na Facebooku) tak největší hloupost je ho rovnou otevřít. Stránky mohou využít clickjacking a třeba vytvořit událost, kde bude ten podezřelý odkaz a pozvou na ni všechny vaše kamarády (tohle jsem zrovna viděl nedávno).

Řešením je podezřelé odkazy otevírat v „Privátním okně“ – dnes už to umí většina prohlížečů (v Chrome zkratka CTRL+SHIFT+N). Pokud by pak zlá stránka chtěla provést něco nepatřičného, tak si toho snadno všimnete (bude třeba chtít přihlášení k Facebooku).

Šifrování dat v notebooku je nutnost!

Už jsem psal o tom, jak je důležité data zálohovat. Ale pokud vám někdo ukradne notebook, tak snadno získá přístup i k vašim datům (to že máte nastavené heslo do Windows je k ničemu – jde ho vyresetovat během chvilky).

Zkuste se zamyslet, jaká data máte v počítači uložená a co by se stalo, kdyby k nim někdo získal přístup…

  • uložená hesla v prohlížeči
  • pracovní dokumenty
  • zdrojové kódy aplikací
  • e-maily
  • fotky
  • SSH klíče
  • účetnictví

Nevím jak vy, ale já bych byl docela nerad, kdyby má data získal někdo cizí.

Nebo jiná situace – Michal má ultrabook od Asusu a jednoho dne mu přestal fungovat pevný disk. NBD záruka to sice kryla, jenže na disku (i když se hlásil jako nefunkční) měl data, která nemohla ven z firmy. A vzhledem k tomu, že Asus je posílá zpět a případně opravuje (na rozdíl od HP/Dell, kteří nefunkční disky likvidují), nakonec musel ten nefunkční disk odkoupit.

Všechno tohle řeší šifrování.

Šifrovat data lze buď pomocí BitLockeru (součást Win7 Ultimate, nebo Win8 Pro), nebo pomocí open-source TrueCryptu. Funguje to tak, že ve vybraném nástroji vytvoříte silné heslo (třeba 20 znaků) a nástroj pak zašifruje celý systémový disk. Po spuštění šifrovaného počítače se nejdříve zobrazí výzva k zadání hesla a teprve poté začne startovat systém.

Závěrem

Šifrování je (spolu se zálohováním) snadná cesta jak můžete ochránit svá data v případě ztráty notebooku. Určitě se vyplatí o něm popřemýšlet – zvážit, jaké negativní důsledky by mohlo přinést, pokud by někdo získal vaše data.

Data mám aktuálně zálohovaná do SkyDrive, takže teoreticky by k nim někdo mohl získat přístup, pokud by prolomil můj Live účet. Případně by se k nim mohl dostat provozovatel úložiště. Nicméně taková varianta je výrazně méně pravděpodobná, než že mi někdo ukradne notebook.

Samotnou kapitolou je správa hesel – na ta spokojeně používám KeePass a možná o tom někdy napíšu samostatný článek.

A co vy, máte notebook šifrovaný? Nebo se svými (a cizími) daty hazardujete?

Migrace SVN do GITu od A do Z

V nedávné době jsem migroval několik SVN repositářů do GITu a rád bych zaznamenal postup a pár tipů, protože věřím, že někdo budete řešit podobnou věc. Přechod na GIT se vyplatí, to tu není potřeba rozebírat :)

První věc, kterou je potřeba vědět je, že to trvá dlouho. Dlouho. DLOUHO. A čím více revizí, tím déle. Samozřejmě záleží na systému, HW atd., ale orientačně počítejte, že tisíc revizí v SVN může trvat zmigrovat tak dvě hodiny. Tohle samozřejmě měřím s lokálním SVN serverem. Před samotným řešením migrace je vhodné pročistit repositář.

Pročištění SVN repositáře

Migrace do GITu bude snazší, pokud před tím pročistíte strukturu repositáře. Dobře funguje, když máte trunk/branches/tags, případně soubory přímo v kořenu repositáře, bez branchí a tagů. Nicméně pokud váš repositář obsahuje nestandardní strukturu (dva trunky, víceúrovňové branches), je vhodné to ještě před řešením migraci pročistit přímo v SVN.

Rozjetí lokálního SVN serveru

Migraci je velmi vhodné dělat lokálně (rozjet si lokální SVN server). Zaprvé to je mnohem rychlejší a zadruhé se migrace nepřeruší při výpadku síťového spojení. Takže jak na to?

1. Pokud na práci s SVN používáte TortoiseSVN, tak je potřeba si nainstalovat ještě konzolové SVN například z http://www.sliksvn.com/en/download a přidat ho do systémové cesty. Zda je vše v pořádku ověříte pomocí následujícího příkazu:

> svn --version
svn, version 1.7.7-SlikSvn-1.7.7-X64 (SlikSvn/1.7.7) X64
   compiled Oct  9 2012, 15:02:27

2. dalším krokem je zkopírování repositáře ze serveru – na serveru zabalit, u sebe rozbalit (třeba do c:\svn2git\moje-repo)

3. teď už máme repositář lokálně, tak spustíme server:

svnserve --daemon --root c:\svn2git\

4. a zkontrolujeme, že nám SVN server funguje – třeba pomocí repository browseru z TortoiseSVN se podíváme do svn://localhost/moje-repo

Příprava authors.txt souboru

Vzhledem k tomu, že SVN identifikuje autory změn jen uživatelským jménem (např. martin.hujer) a GIT jménem a e-mailem, je potřeba mezi nimi vytvořit mapování.

1. Nejprve si vypíšeme všechny autory z SVN repositáře – z bashe spustíme:

$ svn log --quiet svn://localhost/moje-repo | grep -E "r[0-9]+ \| .+ \|" | awk '{print $3}' | sort | uniq

2. Vytvoříme soubor authors.txt, který bude obsahovat mapování uživatelských jmen. Všimněte si, že z historických důvodů (přesun SVN repositáře jinam) jsem tam commitoval pod dvěma různými uživatelskými jmény.

martinhujer = Martin Hujer <mhujer@gmail.com>
martin.hujer = Martin Hujer <mhujer@gmail.com>

3. Zkontrolujte, zda v souboru máte opravdu všechny autory, jinak se migrace přeruší, až narazí na revizi s autorem, který bude v mapování chybět.

Jdeme migrovat!

Na migraci je vhodné použít nástroj svn2git. Ten na migraci použije git-svn a po migraci repositář dočistí (z tagů v SVN udělá GITové tagy, správně namapuje branche a další).

1. svn2git je vytvořený v Ruby, začneme tedy instalací Ruby interpreteru. Doporučuji použít JRuby. Poté nainstalujeme svn2git:

gem install svn2git

ProTip: Pokud budete potřebovat něco, co svn2git v základu neumí (třeba pokračování v přerušeném importu, nebo možnost specifikovat více adresářů s branches), tak si určitě projděte PullRequesty na jeho GitHubu, některé užitečné věci už tam jsou vyřešené, ale ještě nejsou zahrnuté v oficiální distribuci nástroje.

2. Že je svn2git správně nainstalovaný ověříme pomocí zadání svn2git -h do konzole. Měla by se zobrazit nápověda k použití nástroje.

3. Vytvoříme adresář, kam budeme migrovat. Například C:\svn2git\moje-repo-git\. A otevřeme příkazový řádek v tomto adresáři.

4. Spustíme migraci pomocí následujícího příkazu (nezapomeňte upravit cesty)

svn2git svn://localhost/moje-repo PARAMETRY --authors c:\svn2git\authors.txt

takže například:

svn2git svn://localhost/moje-repo --rootistrunk --authors c:\svn2git\authors.txt

Jako parametry můžeme použít tyto kombinace:

  • -v – verbose – detailní výpis průběhu, určitě doporučuji použít
  • --rootistrunk – všechny soubory v repositáři jsou uložený v kořenovém adresáři, nepoužíváme trunk/tags/branches
  • --trunk hlavni --tags tagy --branches vetve – adresáře, které obsahují trunk/tags/branches. Pokud branches nebo tags nepoužíváte, tak přepínač nahraďte --notags nebo --nobranches. Pokud využíváte standardní layout SVN repositáře (trunk/tags/branches), tak je možné tyto parametry vynechat a nastaví se automaticky
  • --no-minimize-url – chceme z repositáře zmigrovat jen podadresář (takže by příkaz vypadal např. svn2git svn://localhost/moje-repo/podadresar --no-minimize-url --authors c:\svn2git\authors.txt)
  • --exclude – měl by fungovat příkaz exclude na vynechání některých adresářů, které jste někdy omylem do SVN vložili, nicméně mě nefungoval – migraci se s ním ani nepodařilo spustit, ale jde to pak vyřešit v gitu (viz dále)

5. Migrace poběží dlouho (jak jsem psal výše, záleží na velikosti repositáře a počtu branchí). Na konci pak svn2git udělá výše zmíněnou magii, aby repositář po migraci dočistil.

Vyčištění repositáře

Po migraci do GITu se naskýtá jedinečná příležitost pročistit historii projektu a zbavit se například velkých, kdysi omylem přidaných a pak zase smazaných adresářů, knihoven atd. Sice by to mělo jít pomocí přepínače --exclude zadat hned při migraci, ale mě to nefungovalo a řešil jsem to až poté v gitu (a podle mého transparentněji) – pomocí filter-branch. Ten postupně projde všechny revize a v každé může provést nějakou změnu. Než budete filter-branch zkoušet, tak si zmigrovaný repositář zazálohujte, abyste v případě, kdy se něco nepodaří, nemuseli znovu čekat, než se zmigruje.

Následující kód projde celou historii repositáře a smaže adresář build:

git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch build/' --prune-empty --tag-name-filter cat -- --all

Můžeme jich spustit více za sebou (pro eliminaci více adresářů), ale ty další musí začínat git filter-branch -f

git filter-branch -f --index-filter 'git rm -rf --cached --ignore-unmatch tmp/' --prune-empty --tag-name-filter cat -- --all

A poté pročistíme dočasné soubory a cache repositáře:

rm -rf .git/refs/original/
git reflog expire --expire=now --all
git gc --prune=now
git gc --aggressive --prune=now

git checkout master

Více o pročištění historie najdete na Githubu nebo git-scm.com

Kontrola migrace

Po migraci je vhodné ověřit, že se nám nic nepoztrácelo a zmigrovaný GIT repositář obsahuje stejné soubory jako migrovaný SVN repositář.

Vytvořil jsem tedy jednoduchý skript, který vyexportuje GIT repositář do struktury jakou má SVN repositář (tedy trunk/tags/branches).

Podobně si uděláme SVN export a pak obě složky porovnáme třeba pomocí Total Commanderu (Commands → Synchronize Dirs).

Závěrem

V článku jsem se snažil ukázat, jak je možné stávající SVN repositář co nejsnadněji zmigrovat do GITu.

Pokud máte opravdu velký SVN repositář a svn2git vám nestačí (mě fungoval i pro migraci 12000 revizí se spoustou branchí), tak můžete vyzkoušet nástroj, který se jmenuje shodně svn2git, nicméně jde o úplně něco jiného. Tento si vyvinuji vývojáři KDE, když připravovali přechod na GIT. Jim by původní svn2git na zmigrování více než milionu revizí asi nestačil :)

Pokud se budete snažit zmigrovat svůj SVN repositář a narazíte na nějakou komplikaci, tak se určitě zeptejte v komentářích, pokusím se vám poradit. Jestli už migraci do GITu máte za sebou, tak uvítám vaše postřehy či tipy.

Proč je dobré dodržovat Coding Standards (Pravidla pro psaní kódu)?

Nečekal jsem, že ještě někdy budu muset někoho přesvědčovat, že je fajn dodržovat Coding Standards (CS). Ale v rámci školního předmětu 4IT445 (ten je mimochodem super!) jsem musel, takže jsem se rozhodl ty důvody sepsat (abych měl příště jen kam odkazovat)

Co těmi coding standards myslím?

  • formátování souboru (kódování, znaky pro konce řádek, odsazování – taby vs. mezery)
  • pojmenování proměnných, metod, tříd atd.
  • styl psaní kódu (jaké používat a nepoužívat konstrukce, kde dělat mezery, kam dávat závorky)
  • standard pro dokumentaci

Proč je důležité je dodržovat

Pokud píšete projekt sami pro sebe, a s jistotou víte, že ho nikdy nebude upravovat nikdo jiný, ten si můžete psát, jak chcete. Ale většinou, i když píšete sami, ale na zakázku, tak je pravděpodobné, že v té aplikaci bude někdy někdo jiný potřebovat něco upravit a určitě ocení, pokud budete coding standards dodržovat. Dodržování coding standards je samozřejmostí, pokud na projektu pracuje více vývojářů.

Jedním z často používaných principů je Colective code ownership, kdy jakýkoliv kód v aplikaci může upravovat kdokoliv. Nehraje se na to, že tohle je Petrům kód a tohle Karlův a ten si budou upravovat oni. A jinému členovi týmu by se v kódu, který není psaný podle coding standards, hůře orientovalo.

Kód se mnohem častěji čte, než píše, takže pokud strávíte o něco více času psaním kódu, tak se vám to bohatě vrátí na ušetřeném čase při jeho čtení.

Pokud bude kód psaný podle coding standards, tak se snižuje riziko nějakého přehlédnutí z důvodu jinde umístěné závorky, jinak odsazovaného kódu atd., což může ušetřit spoustu dalšího času při řešení bugu tímto způsobeného.

Jedním z argumentů proti CS je „vždyť to funguje stejně“. Na to odpovím jedním citátem:

„Napsat kód, kterému rozumí počítač, umí napsat každý blbec. Dobří programátoři píší kód tak, aby mu rozuměli lidí.“

– přeloženo z Martin Fowler, „Refactoring: Improving the Design of Existing Code“

Další důležitou věcí je rozumné pojmenovávání proměnných. Dobré pojmenovávání není žádná legrace, ale můžeme se o dobré a předvídatelné pojmenovávání alespoň snažit. Nestojí za to, ušetřit pár znaků při psaní názvu proměnné (vždyť máme autocomplete), pokud to zbude znamenat, že při každém čtení budete muset zkoumat, co v té proměnné vlastně je.

To, že se tým dohodne na Coding Standards a bude je dodržovat (a vynucovat!) je prvním krokem ke kvalitnějšímu kódu (poté má smysl řešit dobrý OOP návrh, automatizované testování atd.). Ale pokud se tým nezvládne ani řídit CS, tak těžko zvládne automatizované testování.

Jak na coding standards?

Vůbec jsem nezmiňoval, jaký coding standard dodržovat. Ono na tom tolik nezáleží, jen je potřeba, aby všichni v týmu dodržovali ten stejný. Samozřejmě je vhodné zvolit nějaký ověřený, detailně popsaný, používaný mnoha lidmi, kde výhodou je jeho podpora nástrojích (viz dále) a to, že už ho spoustu lidí zná. Pro aplikace na Zend Frameworku je jasnou volbou Zend Framework Coding Standard (věnujte čas jeho přečtení a pochopení, vyplatí se to).

Výhodou dodržování osvědčeného standardu je jeho podpora v nástrojích, které umějí jeho dodržování kontrolovat. Jedním z takových nástrojů je PHP_CodeSniffer, který umí reportovat, kde se váš kód odchyluje např. od Zend Coding Standards. Samozřejmě je nejlepší kontrolu coding standards automatizovaně provádět po každém commitu pomocí nějakého integračního serveru – pokud vás toto zajímá, tak doporučuji svou bakalářku, kde kontinuální integraci pro PHP detailně rozebírám (nejen kontrolu coding standards).

Další, lehce se coding standards dotýkající věc, jsou výstižné commit messages. Opět platí, že alespoň nějaké jsou lepší než žádné, ale vynikající jsou nejlepší :)

tl;dr

Batoh na notebook Topgal HIT 129

Několik let jsem na notebook používal BAG 012 od české firmy Topgal, se kterým jsem byl hodně spokojený. Když se pak po třech letech každodenního nošení začal rozpadat, chtěl jsem si koupit ten stejný, jenže mezitím už ho přestali vyrábět a inovovaný model neuvedli.

Dlouho jsem přemýšlel, co si pořídím a nakonec jsem si koncem srpna v Jablonci v obchodu s batohy koupil HIT 129 opět od Topgalu. Líbí se mi na něm totiž to, že stejně jako na BAG 012 jsou zádové popruhy přes kapsu s notebookem, takže se vám nemůže otevřít, pokud máte batoh na zádech.

Jenže po měsíci se začaly párat zádové popruhy (batoh má nosnost 12kg a myslím, že jsem tam nenosil ani 7kg). Kromě toho jsem zjistil, že má křivě ušitá záda – výztuhy nebyly ve stejné výši.

Reklamace

Odnesl jsem batoh na reklamaci, za 14 dní mi přišla SMS, že už je reklamace vyřízená a mohu si ji vyzvednout. Topgal batoh neopravoval, ale rovnou poslali nový. A ten měl záda také špatně ušitá, tentokrát jinak křivě. Batoh jsem tedy ani nepřevzal, ať jim ho rovnou pošlou zpět. Další den mi volal pán z obchodu, ať se tam stavím pro peníze, že to mají všechny ty batohy špatně.

Tipy na batoh?

Teď když jsem opět bez batohu, uvítal bych nějaké tipy na notebookové batohy, se kterými jste spokojeni. Díky!

Jak na diplomku při fulltime zaměstnání?

Adélka teď řešila z hlediska time-managementu zajímavý problém – jak zvládnout napsat diplomku za tři měsíce při práci na fulltime. Na VŠE spoustu lidí při studiu pracuje a často právě i na fulltime nebo skorofulltime (zvlášť ve vyšších ročnících). Proto si myslím, že by tenhle článek mohl (i třeba jen malinko) pomoci někomu dalšímu včas a bez stresu dopsat diplomku.

Začínáme

Rady pasují na situaci, kdy už víte, o čem chcete psát, máte připravené podklady a jde jen o samotné napsání. (Ale samozřejmě se mohou hodit i pro předchozí fáze)

Výchozí situace:

  • Vracíte se z práce kolem 18h, než si vydechnete nebo si dojdete zaběhat, tak je 19h. Kromě toho máte čas na psaní ještě o víkendech.
  • Máte hotovou hrubou osnovu z diplomového semináře, takže víte o čem psát
  • A hned po návratu domů otevíráte Facebook a koukáte, co nového (nebo nějak podobně proflákáte večer)

Co s tím?

Podle mě je hlavním problémem začít na té DP něco dělat. Proto si teď hned vezměte mobil, nastavte si odpočítávání na 30 minut a pracujte na DP. Je jedno, jestli budete hledat zdroje, plánovat jednotlivé kapitoly nebo (nejlépe) opravdu psát. Ale neřešte formátování nadpisů, na to bude čas jindy. Zavřete ten Facebook a všechna ostatní okna, která na DP nepotřebujete. A článek si dočtete potom.

Už máte hotovo? Jestli ne, tak tím, že budete místo psaní číst články na webu to nedoděláte.

Opravdu teď přestaňte číst a běžte na tu půlhodinu makat.

Hotovo? Další krok na cestě k hotové a odevzdané DP je za vámi :)

Co dál? Podle mě úspěšné napsání DP s takhle málo časem tkví v pravidelných blocích maximálně efektivní a soustředěné práce. Rozeberu to ve třech částech.

Hlavně se soustředit

Pokud se snažíte psát, ale do toho vám někdo píše na FB, vyskakují upozornění na e-maily, a ještě sledujete televizi, tak ten strávený čas bude skoro k ničemu. Je potřeba se na to psaní pořádně soustředit, takže:

Tip č. 1: Na psaní zavřete Facebook i všechny další nepotřebné stránky a vypněte různá vyskakovací upozornění v programech

Vzhledem k tomu, že se nikdo nedokaže soustředit dlouhou dobu, tak je lepší si to maximální soustředění rozdělit na menší bloky a mezi nimi si dát pauzu, kdy se půjdete protáhnout nebo se i na ten Facebook a e-mail podíváte. Samozřejmě už s tím někdo experimentoval a došel k tomu, že nejlepší jsou 25 minutové bloky a mezi nimi 5 minut flákací pauza. Pojmenoval to jako Pomodoro Technique (nebo také jen „pomodoro“) – podle tvaru kuchyňské minutky, kterou používal. Jako dobré online měřítko se mi osvědčil online nástroj Tomatoi.st

Tip č. 2: Používejte pomodoro a pracujte v blocích maximálního soustředění, které proložíte krátkými pauzami

Pravidelně, pravidelně, pravidelně

Je fajn psát pravidelně každý den, protože se pomalu dostanete do tempa a zvyknete si, že vás po návratu domů čeká psaní. A odměnou vám bude to, že uvidíte, jak vám DP pěkně přibývá. Určete si nějaký rozumný počet pomodor (tzn. 25 minutových úseků práce), které DP každý den věnujete. Může být dobré se domluvit s někým blízkým, že mu každý den dáte vědět, až budete mít „odpracováno“ – bude vás to motivovat to opravdu dodržet.

Tip č. 3: Každý den se DP věnujete vámi určený počet pomodor.

Efektivně!

Je důležité pracovat efektivně. Pokud na DP strávíte několik pomodor denně, ale budete je zpola trávit zbytečnými činnostmi, tak se vpřed budete posouvat jen pomalu. Pár tipů, co mě teď napadlo:

  • pokud pracujete s cizojazyčnými zdroji, tak si do prohlížeče přidejte nějaké rozšíření, které vám přeloží slovo pod kurzorem (klidně i třeba Seznam Lištičku) – ušetříte si čas kopírování slova do nějakého online slovníku
  • přepínejte okna pomocí Alt + Tab a ne zběsilým rejděním myší po obrazovce
  • pokud se v textu posouváte pomocí kurzorových šipek, tak k tomu držte Ctrl a budete se posouvat po slovech
  • … další možná doplním – až někoho zas budu sledovat při práci :) …

Bonusový tip

Bonusový tip: Zálohujte!!! Určitě nechcete ztratit nic, co jednou napíšete, proto je fajn si dokument s DP nebo i celou složku s materiály zálohovat. Pokud neznáte, tak fajn nástrojem na to je Dropbox, který vám v počítači vytvoří speciální složku, a cokoliv do ní uložíte, hned zálohuje do on-line úložiště. (A můžete ji i někomu nasdílet a ten může sledovat, jak vám DP přibývá)

Závěrem

Zkusil jsem sepsat pár tipů, které by vám mohly pomoci dopsat diplomku včas a s menším stresem i pokud pracujete na fulltime. Nejdůležitější je ale vaše pevná vůle – sám vím, jak je těžké se po celodenní práci k něčemu produktivnímu dokopat. Pokud vás napadnou další vylepšení, tak se určitě podělte v komentářích.

Držím palce!


Update 12. 12. 2012:

Tak je potvrzené, že ta metoda opravdu funguje :-)

HipHop for PHP

Dalším zajímavým nástrojem, který by bylo možné zařadit do kontinuální integrace, je HipHop for PHP vyvinutý společností Facebook Inc. Jeho primárním účelem je převod skriptů v jazyce PHP do jazyka C++, nicméně je možné ho využít pro statickou analýzu (umí odhalit chyby, které jiné nástroje neodhalí). A případně ho zařadit jako jeden z nástrojů kontinuální integrace.

Instalace nástroje

Nástroj je nutné zkompilovat ze zdrojových kódů, nejsou k dispozici instalační balíčky. Zároveň je nutné nejdříve zkompilovat několik knihoven třetích stran. K dispozici jsou postupy na wiki projektu na githubu, zvolte ten odpovídající vaší linuxové distribuci.

Já jsem instaloval na VirtualMasteru, takže jsem zvolil návod pro Ubuntu 10.04

Pokud si chcete HipHop jen vyzkoušet, tak je zbytečné trávit čas kompilací. Proto jsem na VirtualMasteru vytvořil veřejnou šablonu s připraveným HipHop for PHP

Použití nástroje

Poté, co máme nástroj nainstalovaný (buď podle postupu a nebo vytvořením serveru z image výše), nastavíme potřebné cesty:

cd /root/hiphop/
export HPHP_HOME=`/bin/pwd`
export HPHP_LIB=`/bin/pwd`/bin

A zkusíme spustit analýzu. Já jsem zkoušel Zend Framework 1.

cd /tmp
svn export http://framework.zend.com/svn/framework/standard/trunk/library zf1
cd zf1
/root/hiphop/hiphop-php/src/hphp/hphp -t analyze --input-dir ./Zend/ --include-path ./

Výstup je poté uložen v /tmp/hphp_AFDvIh/CodeError.js (resp. v podobně nazvaném adresáři).

Když jsem prosěl výstup z kontroly ZF1, tak jsem postupně přidal 12 issues do ZF – od ZF-12225 do ZF-12236

Zařazení nástroje do CI

Sebastian Bergmann vyvinul nástroj obalující HipHop do PHP s možností exportu výsledků ve formátu pro CheckStyle. Nicméně do CI jsem ho zatím nenasadil, protože se bojím, že bych kompilací a instalací zkompilovaných věcí mohl poblbnout server.

Závěrem

Pokud chcete ztratit iluze o svých zdrojácích, zkuste na ně spustit HipHop :)