Asi jsem zase objevil Ameriku, ale tohle je hodně šikovná věcička na zachytávání celých obrazovek, jednotlivých oken, obdélníků, nebo kompletně vlastních výřezů vašeho screenu.
Ve verzi 5.3 je jako freeware.
úterý 15. září 2009
neděle 6. září 2009
Založení nového projektu Subversion a Debian
Neustále zapomínám, co si nenapíšu, to nevím. A už vůbec ne to, co použiju jednou za dva měsíce.
Jelikož si to vždycky vygoogluju (asi jako spousta dalších z nás), je to v pohodě. Ale nemůžu se spoléhat, že ten zdroj informací bude vždy platný.
Čili, tohle je taková moje záloha.
4. Create Repository
# mkdir /var/svn/
# svnadmin create --fs-type fsfs /var/svn/myproject
5. Generate Test data in repository
# mkdir ~/TEMP/
# echo "Testing" > ~/TEMP/test.txt
# svn import -m "Testing via ssh+svn" ~/TEMP/ svn+ssh://127.0.0.1/var/svn/myproject/trunk
# svn co svn+ssh://127.0.0.1/var/svn/myproject/trunk testcheckout
6. See if files in repository
# svnlook tree /var/svn/myproject/
7. Changeowner of repository folder to apache user
# chown -R www-data:www-data /var/svn/*
# chmod -R 770 /var/svn/*
Originál článku: http://www.reviewingit.com/index.php/content/view/62/2/
pátek 4. září 2009
Sharepoint a velké soubory
Tak studujte:
http://intellects.in/2008/07/11/optimizing-sharepoint-or-wss-for-large-document-size/
Nakonec to nebude tak zlé.
Nicméně, implementovat to lze taky jinak. Řekněme, že velké soubory vůbec do Sharepointu nepolezou. Ošetříte si vlastní upload, navhrnete strukturu jinak (tak aby položka listu referencovala fyzicky umístěný soubor někde na disku) a taky to půjde...
středa 2. září 2009
úterý 4. srpna 2009
C# - CodeRush - plugin do VS2008
Kromě express edicí VS je možné zdarma využít tento plugin:
ten by vám měl pomoci psát čistší a přehlednější kód, jak pro C#, tak i VB.NET
Šikovná věcička, a zdarma.
čtvrtek 30. července 2009
úterý 28. července 2009
Řízení maličkých IT projektů - ano nebo ne?
Jedním slovem:
- ANO
Všechny?
- ANO
Proč?
- Protože i ty nejmenší projekty se vám mohou rozrůst
Jak je řídit?
- Rozumně!
(To vám asi moc neřekne, takže to rozeberu trochu víc.)
Pokud chcete zabít mouchu, berete si na to brokovnici? Asi ne. (Tacklebarry, tebe nepočítám.)
Stejné je to se řízením projektů.
Asi těžko budete instalovat Project Server kvůli projektu, který dohromady trvá 5MD a pracujete na něm jen vy.
Co byste ale rozhodně měli při projektech takto malého objemu udělat?
1) Uložit si veškerou e-mailovou komunikaci s klientem
2) Pokud musíte vyvinout speciální knihovny, řádně je dokumentujte
3) Veškeré know-how získané na projektu si poznamenejte do nějaké vaší databáze poznatků
4) Obrovskou pozornost věnujte Quick-Wins a jejich dokumentaci
5) Poznamenejte si čas, který jste odhadli při naceňování projektu a skutečný čas (pozor! včetně čtení e-mailů, brainstormingu, komunikace s klientem a další časy spojené s projektem)
6) Striktně vyžadujte rozhodnutí klienta v digitální nebo písemné formě
Potřebujete to vysvětlit?
Dobře, ale krátce.
add 1)
Uložením e-mailů nemám na mysli jejich ponechání v Outlooku. Dejte si tu práci a uložte si je do projektových složek na disku, umístěte si je do nějakého vašeho informačního systému, cokoliv, kamkoliv, jen je nenechávejte pouze ve vašem poštovním klientovi.
Až naberete dalšího kolegu, který bude dělat update. Až vám havaruje Outlook (prý se to stává ;-), až vám havaruje disk, až havarujete vy (omylem poštu smažete) - Poděkujete mi.
add 2)
Jestli tento bod musím vysvětlovat, obávám se, že byste se měli začít věnovat jiné profesi.
add 3)
Za půl roku vás klient kontaktuje, že potřebuje rozšířit funkcionalitu. Není nic horšího, než dva dny přicházet na to, co ten kód vlastně dělá a proč to dělá, jak to dělá.
V know-how můžete mít odkazy na stránky, blogy, kusy textu opsané z knihy, obrázky, popisy API a všechno co vám pomůže rychle se do projektu znovu dostat.
Myslíte si, že u tak malého projektu, na kterém právě pracujete se to stát nemůže?
Hoši, hoši, ale může...
A jak by řekl Murphy, taky se to stane.
add 4)
OBROVSKOU!!! Napsal jsem to dostatečně jasně?
Jo ták, vy nevíte, co je Quick-Win. A už jste někdy zapsaly heslo přímo do kódu? Proměnnou jste předali metodě a pak v té metodě zahardkodovali její hodnotu, aniž byste provedli code-review a řádný refaktoring?
Že se vám tohle nestává? Promiňte, ale nevěřím. Tohle se prostě stává. Nemusí často, ale stává.
Jde o to, že na projekt máte vyšetřený nějaký čas, provedli jste odhad, ale nějaká část vám dala řádně zabrat. Víc, než jste čekali. Abyste v tom nezahučeli a projekt pro vás nebyl vysloveně ztrátový, musíte si někde pomoct.
A v ten okamžik jde někdy řádný návrh, objektovost a další věci stranou.
Projekt jste odevzdali, vše funguje, zákazník je spokojený.
To je dobře.
Věnujte ale trochu toho času a alespoň komentujte kód nebo si jinak poznamenejte, co vylepšit, až vás klient bude kontaktovat, že potřebuje další funkcionalitu.
add 5)
Toto je velmi důležité z pohledu návratu do budoucnosti. Pokud budete řádně měřit časy, odhadované a skutečné, pomůže vám to odhadovat čas na dalších projektech přesněji.
Hodně vám to také prozradí o vás samotném. Například, že si moc věříte a některé věci vám trvají mnohem déle, než odhadujete. Nebo naopak (ano, toto je přesně váš případ, já vím) se zbytečně podceňujete a práci odvedete mnohem rychleji.
add 6)
Jedete autem, klient volá, něco si vzpomněl, vy mu to odsouhlasíte, provedete, implementujete. Po dokončení projektu vás seřve, že toto nikdy v životě nechtěl a jak je to možné, a jak se to tam dostalo a vy nebudete moci říct nic.
Nehledě na to, že zadavatelů pro váš projekt může být více a klasickou cestou "levá ruka neví, co dělá pravá" se v tom můžete pěkně vymáchat.
Někteří klienti na to dokonce vysloveně "hrají". Prostě si vás povodí. Jeden chce to, druhý chce ono, vy kódujete celé noci a na konci jste rádi, že dostanete alespoň část peněz za vysvícené oči vaším monitorem.
Sbírejte a pečlivě uschovávejte důkazy, bude vás vysloveně těšit, až původní cena bude pod víceprácemi pěkně bobtnat.
To je vše, víc vám toho neřeknu.
Snad jen, hodně štěstí - budete ho potřebovat. Proč? Protože Murphy je hajzl.
- Příště více o těch projektech většího typu -
CSS - jak bojovat proti prohlížečům a neprohrát
Pokud chcete podvádět, tak pořádně. CSS Cheatsheets a další tipy, triky, layouty zde:
úterý 9. června 2009
Sharepoint - nástroje a šikovné utilitky
A opět bez dlouhých řečí, proč psát o něčem, o čem existuje daleko hezčí povídání:
čtvrtek 28. května 2009
Popis architektury
Nedávno jsem se dostal k jednomu projektu, na němž tým vývojářů s menšími obměnami pracuje přes tři roky.
A už dlouho jsem se necítil tak hloupě, jako právě u tohoto projektu.
Proč?
Protože, abych pochopil celkovou architekturu, musel jsem studovat zdrojový kód. Na začátku jsem dostal krátký briefing, od mimořádně sdílného programátora, jehož nejdelší věta se skládala z pěti slov.
Když jsem se zeptal, zda mají k dispozici nějakou dokumentaci, pomocí níž bych se s celým projektem seznámil, začali se hýkavě smát.
Dovedete si asi představit, že to celé vedlo k naprosté frustraci a vyčerpání. Hodiny strávené studiem kódu, jež měnil styly a sémantiku téměř s každou třídou, byly naprosto ubíjející. Nicméně se mi podařilo do kódu proniknout a podařilo se mi svůj úkol splnit.
Po dokončení práce jsem přešel na jiný projekt, a musím přiznat, velmi rád.
Nedokumentovat kód je obecně špatná věc. To víme všichni. Jenže zároveň dokumentovat kód je strašně otravná věc a pro vývojáře naprosto nedůstojná a pokud to jen trochu jde, nedělá se to. Ne nadarmo se říká, že nejlepší programátor je programátor líný. A chtěli byste po takovém člověku, aby dokumentoval kód. Našel v sobě zbytečky vyjadřovacích schopností a popsal význam, chování a příklady použití třídy, kterou navrhl za pět minut, ale dokumentací by měl strávit půl hodiny.
Nemyslitelné.
Na jednu stranu je to dobře. Tedy, částečně dobře. Umění je rozhodnout, kdy kód dokumentovat a do jaké míry a kdy ne. Nepředpokládám, že u malé utility aplikace byste vytvářeli dokumentaci na dvacet stran.
U složitějších aplikací je potřeba mít alespoň popsanou rámcovou architekturu a její důležité části, například ty, u kterých se při implementaci vyskytly problémy a bylo je potřeba řešit konkrétním způsobem.
U vysloveně složitých aplikací je potřeba dokumentovat a to velmi důsledně. Vy, kteří tak nečiníte, mnoho štěstí, řítíte se do pekel.
Věřte mi, sám jsem tam už několikrát byl.
Vývoj v PHP a v C# .NET framework
V době, kdy jsem se prokousával C# a přecházel jsem z PHPka, jsem byl strašně nešťastnej. Nebylo to C# nebo .NET nebo ASP.NET, bylo to ve mně. Bylo pro mne strašně složité začít přemýšlet opravdu objektově a jelikož jsem se učil PHP sám, a nikdy jsem neměl k ruce zkušenějšího kolegu, který by mne správně směřoval a případně poradil, naučil jsem se PHP "tak nějak".
Pak jsem v PHP objevil třídy, které když se dívám dozadu, pro mne byly jako jakési helpery. Něco jako namespace a v něm zapouzdřené funkce. V žádném případě se nedalo hovořit o OOP.
Jenže hlava programátorská, bez zpětné vazby, bývá hlava namyšlená. A tak jsem si začal myslet, že v PHP umím. C# a hlavně .NET framework mě hodně rychle vyléčil.
Šok, jinak se to popsat nedá. První dva měsíce jsem tápal jako tele. Dělal jsem chyby při návrhu a dostal jsem k ruce senior programátora, který toho moc nenamluvil a hlavně pro něj bylo nepochopitelné, že bych objektově psát neuměl.
Zase špatný start, ale nedal jsem se. Začal jsem hledat po netu. Prohlížel příklady. Dostával do sebe první návrhové vzory a pokoušel se je používat. Po nějakém roce bylo ze C# a .NET líp, mnohem líp.
Paradoxně však došlo k něčemu úplně jinému, stal se ze mě mnohem lepší vývojář v PHP. Ano, paralelně jsem pokračoval na projektech v PHP i v .NETu.
A ASP.NET se mi zhnusil.
Nějak jsem nikdy nedokázal přijmout web forms. Prostě to není moje krevní skupina. Respektuji tento přístup, ale nechtějte, abych dle něho vyvíjel. Prostě ten bastl v HTML kódu, aby fungovalo jakési pseudo-event-handling programování na webu nejsem schopen zkousnout.
V PHP jsem si zamiloval Zend framework a MVC architekturu. Něco podobného se chystá v ASP.NET, tak jsem zvědav, jak to dopadne. Zatím mi to vypadá hodně sympaticky. Třeba se k vývoje v ASP.NET zase vrátím.
Každopádně, .NET framework je super na desktop aplikace a aplikace pro mobilní zařízení. Tam si nemůžu stěžovat a nic jiného bych nepoužíval.
Nette a Zend - co je víc?
Nemám rád hype.
Nemám rád nekonečné diskuze o ničem.
..ale prostě si nemůžu pomoct.
Zhruba před rokem jsem se rozhodl vytvořit si jakousi základnu pro informační systém. Takovou základnu, kterou by bylo možné jednoduše rozšiřovat o funkcionalitu specifickou pro každého svého klienta.
Nebudu zastírat, že má inspirace se nacházela především ve Windows Sharepoint Services 3.0, kdy osobně pro mne je to vývojová platforma v .NET. V .NET už bych nepsal žádný informační systém bez WSS3.0, ale o tom jindy.
Předpoklady byly tehdy jasné:
- chci si vyvinout aplikaci za použití šikovného frameworku
- má to být PHP
...a tak začalo hledání a zkoušení... a zase hledání a zase zkoušení, zklamání nebo nadšení a zase zklamání. Nejvíc bylo ubíjející se vždy naučit základy daného frameworku a vyzkoušet si na vlastních příkladech složitost implementace.
A pak bum!
Zend Framework stál přede mnou majestátně, perfektně zpracovaná dokumentace, obrovská podpora, obrovská komunita. Bylo jasno.
A musím říct, že čím víc jsem do Zend Framework pronikal, tím víc jsem si ho zamilovával. Když hoši psali tenhle framework, opravdu přemýšleli a mnohdy jsem se od nich naučil něčemu novému.
A tu jsem začal registrovat zprávy o Nette frameworku. Přišlo velké nadšení. Čistý, český PHP framework? Co víc si přát.
Začal jsem po očku sledovat jeho vývoj. A čím víc jsem ho začal sledovat, tím víc mi něco připomínal, něco, co už dobře znám. V čem už nějakou dobu vyvíjím.
Ano, začal mi připomínat Zend.
A čím víc to sleduji, tím víc mi ho připomíná.
Je to špatně? Ale vůbec ne. Který je lepší? To záleží na úhlu pohledu. Nejlepší je, vyzkoušet oba frameworky na malé webové aplikaci a uvidíte sami, co vám víc sedne. Má to velkou výhodu, jakmile proniknete do jednoho, v tom druhém to naleznete podobně.
U mne je jasno v několika věcech:
- Zend má delší historii
- Zend má větší podporu
- Zend má větší komunitu
- Zend má lepší dokumentaci
- Zend se rozvíjí daleko rychleji
- Zend tu bude ještě za pár let, o Nette to říct nedokážu
Pro mne je tedy vybráno, ale vy se rozhodněte sami. Nette je dobrý framework, a ačkoliv jsem do něj nepronikl úplně, věřím, že bych si na něj zvykl a používal ho rád.
Týmu okolo Nette držím palce, ačkoliv být na jejich místě, možná bych se pustil do něčeho jiného.
Přihlásit se k odběru:
Příspěvky (Atom)