Webárna - RSS odběr

Git od úplného začátku - důležité zdroje

Mon, 12 Dec 2011 23:00:00 GMT

Git – distribuovaný systém pro správu verzí – rozhodně není žádnou novinkou. Přesto potkávám poměrně dost lidí, kteří o něm téměř nic nevědí a zatím neměli příležitost nebo důvod o něm uvažovat, nebo rovnou nasadit do praxe. Pár z nich se rozhodlo Git zkusit a (také) pro ně jsem se pokusil sestavit seznam důležitých odkazů.

http://www.slideshare.net/…arel-minarik

Slajdy od Karla Minaříka. Ideální pro úvodní seznámení, bohaté na (i poměrně hloubkové) informace, rozhodně doporučuji.

http://www.spheredev.org/…for_the_lazy

Git wiki pro lenochy, cílová skupina široká. Stručný a přehledný souhrn toho, co potřebujete od prvního impulsu k prvnímu projektu verzovanému gitem.

S tímto zdrojem se mírně rozcházím v instalaci gitu na windows, zatímco odkazovaný na to jde přes konzoli, mě připadá jednodušší na windows nainstalovat Git-1.7.8-preview20111206.exe z http://code.google.com/…wnloads/list?….

http://git.or.cz/course/svn.html

Pro ty, kteří přecházejí z SVN, nebo třeba jen chtějí vidět rychlé srovnání příkazů.

http://gitref.org/

Pěkná a stručná příručka.

http://progit.org/book/

Kniha zdarma pro zájemce o hlubší a širší porozumění. Chcete-li aspirovat na titul git-ninja.

Uvedené zdroje myslím pro začátečníka úplně stačí, mojí snahou bylo vybrat zdroje, které učedníka nezahltí balastem a dají mu určitý přehled a možnost hned experimentovat.

Pokud jsem na něco zapomněl, do komentářů s tím.

Readme Driven Development

Wed, 14 Sep 2011 12:22:13 GMT

Readme Driven Development v podstatě říká, že první věc, kterou byste na začátku jakéhokoliv projektu měli udělat, je sepsat si k němu README. Dřív než cokoliv jiného, než první příkaz v kódu, nebo testu, prostě úplně nejdřív. Tenhle postup může mít hodně výhod, doporučuju přečíst celý článek.

Stává se totiž, že vývojáře přepadne prostá myšlenka „udělám bookmarkovací službu“ a už přemýšlí nad kódem, jaké knihovny použije a tak dále. Kdyby si předtím napsal kvalitní README, donutilo by ho to přemýšlet například nad tím, jestli a jak bude zrovna ta jeho bookmarkovací služba jiná než stovky dalších.

Když si napíšu (třeba) do README co aplikace má dělat a jak to má dělat, mám hned na začátku něco, nad čím můžu dumat, nezapomenu to, můžu to s někým konzultovat, můžu dokonce představu upravovat, aniž bych musel draze přeprogramovávat. Mám todo list podle kterého můžu postupovat – a to s lepší šancí, že se mi funkce aplikace nekontrolovaně nerozlezou někam mimo hlavní záměr aplikace.

Readme Driven Development vidím jako nezbytný doplněk ostatních Driven Developmentů a to hlavně proto, že na rozdíl od nich ukazuje co je potřeba vyvíjet a ne to jak se bude vyvíjet.

S čím si hraju - Fórum s CouchDB

Thu, 08 Sep 2011 19:56:42 GMT

Open source a placených fór je strašná spousta a všechny jsou na jedno brdo. Myslím, že je na nich hodně co napravovat. Namátkou ovládání, použitelnost, funkčnost, koncept. Když jsem naposled viděl administraci phpBB, nestačil jsem se divit. Kdokoliv udělá nové fórum s kvalitním UI, bude podle mě mít „úspěch“ a „zásluhy“. Bude to ten, kdo z kabiny raketoplánu dokáže udělat joystick (nebo spíš iPhone?).

Takže jsem se do toho taky z hecu pustil. Měl jsem, a stále mám, tři hlavní cíle – pocvičit se s CouchDB, udělat ovládání kterému porozumí BBU (Běžná Babička Uživatelka) a zajistit vysokou rychlost, která s přibývajícími záznamy v databázi nebude klesat. Mám na mysli dvěstě třista tisíc záznámů a dál.

Mám úplně první nástřel a zatím jsem si na tom vyzkoušel dvě věci – CouchDB hosting Cloudant (ten je super) a css „framework“ Twitter Bootstrap (ten není až tak super).

Výsledek je prozatím ten, že rychlé to fórum tedy není, protože se připojuje ke vzdálené databázi a to něco stojí. PHP server je v ČR, db server nejspíš v USA – nic dobrého.

S tím souvisí další „problém“ – výběr databáze. CouchDB je pořád ve srovnání s MySQL trochu exotika vzhledem k hostování. Pokud bych chtěl, aby to moje fórum někdo používal, připojování ke vzdálené databázi asi nebude to pravé, i když tím na druhou stranu provozovateli fóra odpadají starosti s db serverem.

Pořád tedy zvažuji možnost použít klasické MySQL a rychlost zajistit třeba s pomocí NotORM.

… pokračování příště …

Makra v Sublime Text editoru

Wed, 07 Sep 2011 22:00:00 GMT

Psát pořád dokola ty stejné příkazy je jednoduše opruz a proto existují makra. Do makra si uložíte nějakou sekvenci a klávesovou zkratkou potom takovou sekvenci vyvoláte bez nutnosti ji psát.

Příklad – v nette dost často používám třeba NDebug::dump(); a psát to pořád dokola je na hlavu. V novém nette je myslím ten příkaz ještě delší. Takže si v Sublime Text editoru uděláme makro.

Nahrávání krátkodobého makra, co nepřežije zavření editoru, se spustí klávesami ctrl+q → normálně píšete svůj příkaz → a zastavíte ctrl+q. Vkládáte potom makro pomocí ctrl+shift+q. To my ale nechceme, my chceme trvalé makro.

Takže – vytvořte a otevřete si (na linuxu) soubor

/home/you/.config/sublime-text-2/Packages/User/ndebugdump.sublime-macro

a vložte do něj toto

[ { „args“: { „characters“: „ndebug::dump“ }, „command“: „insert“ }, { „args“: { „contents“: „($0)“ }, „command“: „insert_snippet“ }, { „args“: { „by“: „characters“, „forward“: true }, „command“: „move“ }, { „args“: { „characters“: „;“ }, „command“: „insert“ } ]

Posléze otevřete soubor

/home/you/.config/sublime-text-2/Packages/User/Default (Linux).sublime-keymap

a vložte do něj toto

[ { „keys“: [„alt+d“], „command“: „run_macro_file“, „args“: {„file“: „Packages/User/ndebugdump.sublime-macro“} } ]

Hotovo. alt+d krásně píše NDebug::dump() za nás a my jsme zase o kousek spokojenější, že.

Update o deset minut později: pohodlně prohlížet obsah mé Packages složky, kde se dějí tyhle úpravy můžete na githubu.

Zvolte si uživatelské jméno a heslo

Tue, 06 Sep 2011 13:15:38 GMT

Jedním z nejotravnějších problémů internetových stránek a aplikací, je velmi častá nutnost registrace pod jménem a heslem. Příliš mnoho účtů na příliš mnoha místech snižuje pohodlnost užívání pro uživatele a zvyšuje bezpečnostní riziko – člověk si pravděpodobněji vymyslí jedno slabé heslo, které použije kde se dá.

K heslům a jejich složitosti jsem poměrně nedávno narazil na zajímavý matematický rozbor, který ale nemůžu najít, tak alespoň jeho komiksový výcuc http://xkcd.com/936/. Zjednodušeně řečeno: heslo „kytara s intarziemi“ je obtížnější na prolomení a daleko lépe zapamatovatelné, než třeba „XjžzH54a“. Zdá se, že tento přístup k tvorbě hesel by mohl částečně „vyřešit“ problém mnoha účtů na internetu, ale samozřejmě lze jít dál.

Registrace bez vyplňování emailu a hesla

Jeff Atwood (spoluautor http://stackoverflow.com/) například sní o systému, který by uživatele odstínil od neustálého zadávání jména a hesla. Jak?

stránka vyžadující registraci by obsahovala speciální meta tagy, které by označovaly, že stránka podporuje automatický login
váš prohlížeč by podle tohoto tagu rozpoznal, že se má pokusit automaticky vyplnit registrační/přihlašovací údaje, které by získal z nějakého bezpečného „cloud“ úložiště skrze zabezpečené https. Prohlížeč také vymyslí heslo.
uživatel by nejspíš musel vyplnit nějaký druh captcha kontroly

Doporučuji si přečíst celý článek, ačkoliv si myslím, že Jeff Atwood celý nápad nazývá „svým snem“ celkem oprávněně.

Problémy s git-flow

Sun, 04 Sep 2011 10:39:48 GMT

Scott Chacon (git evangelista, pracuje v GitHubu) sepsal velmi zajímavý článek o tom, jakým způsobem v GitHubu pracují s gitem, jaké mají pracovní flow. Protože git umožňuje celou plejádu způsobů jak řídit verzování, vzniká mnoho takzvaných flow a jeden z těch známých, propracovaných a používaných je git-flow

V githubu to ale dělají trochu jinak, protože hodně často dělají deploy na ostrou aplikaci. Hlavní body tohoto GitHub flow jsou

všechno v master větvi je vždy připraveno na deploy
když chcete pracovat na něčem novém, vytvořte si novou větev s popisným názvem vedle master větve
komitujte lokálně a a pushujte svou práci do vaší větve na serveru
když potřebujete zpětnou vazbu, nebo radu, nebo když si myslíte, že větev je připravena k mergi, otevřete nový pull request
potom co někdo jiný zkontroloval a podepsal novou funkčnost, můžete ji včlenit do master větve
jakmile je včleněno a pushnuto do master větve, můžete a měli byste udělat okamžitě deploy

GitHub má zhruba 15–20 vývojářů pracujících na jednom projektu a toto flow jim zdá se svědčí.

Appstorm.net - o webových aplikacích

Tue, 30 Aug 2011 21:10:25 GMT

Mám trochu úchylku na webové aplikace. Nebo je to profesionální deformace, jak chcete. Když na nějakou webovou aplikaci náhodou (!) narazím a líbí se mi, pěkně si uložím odkaz s popiskem a je moje. Koukám jak jsou udělané, přemýšlím co se mi na nich líbí a proč. Co by se z nich dalo využít a kde.

Tak mě přirozeně napadlo přetavit tuhle úch…eh zálibu v něco konkrétního. Napadaly mě takové ty klasické nesmysly typu „katalog“ webových aplikací, nebo blog o webových aplikacích a tak podobně. Už jsem ve svém věku přece jen o něco moudřejší než v patnácti a tak nic takového z mé ruky (zatím) nevyšlo.

No a dneska jsem objevil http://web.appstorm.net/ což je vlastně blog o webových aplikacích, ha!

Hlavní důvod, proč o tom všem píšu, je ale způsob provedení toho blogu. On má takovou vlastnost, která se mi zdá zajímavá a nejspíš by mě nenapadla.

O co jde: mají tam rubriku Quick Look, do které si za poplatek může kdokoliv poslat svoji webovou aplikaci, kluci a holky z appstorm o ní napíší krátkou představovačku a dají hlasovat zda je v publiku zájem o její recenzi.

No nezlobte se na mě, ale mě to prostě připadá geniální.

nové webové aplikace se objevují dnes a denně
každý chce tu svoji zviditelnit
redakce ušetří nějakou tu práci s hledáním aplikací
dostanou zaplaceno
čtenáři si sami řeknou co je zajímá a co ne

Prostě nápad jsme měli stejný, ale (představu) provedení odlišné.

Přednastavení syntax highlight v Sublime Text editoru

Wed, 17 Aug 2011 11:03:08 GMT

Jak změnit přednastavení zvýraznění syntaxe podle koncovky souborů v Sublime Text editoru.

Když třeba používáte LESS při psaní stylů, tak soubor ve kterém pracujete má koncovku .less, čili vám ho editor neobarví. Aby Sublime obarvoval co chcete, nastavte v:

Preferences  → Browse Packages…  → CSS (složka)  → CSS.tmLanguage (soubor)

<dict> <key>comment</key> <string></string> <key>fileTypes</key> <array> <string>css</string> <string>css.erb</string> <string>less</string> <!-- tohle je ta změna  → </array>

Historky z natáčení - CouchDB 3. - PHP knihovny

Sun, 14 Aug 2011 16:30:29 GMT

Neladem a neskladem naházené knihovny a třídy pro zpříjemnění práce s CouchDB z PHP. Je-li tedy někdy názoru, že je to třeba.

Na wiki CouchDB se pro příklad používá jednoduchá sada tříd z rodinky CouchSimple – pro začátek rozhodně postačí.

Může to pak vypadat třeba nějak takhle (v Nette)

$options = NEnvironment::getConfig(‚couchdb‘); $resp = $this->couchdb()->send(‚GET‘, ‚/‘ . $this->couchdb()->db . ‚/_design/foo/_view/bar?include_docs=true&descending=true‘); $doc = json_decode($resp);$rows = array(); foreach ($doc->rows as $row){ $rows[] = $row->doc; }

Nějakou dobu jsem takhle vydržel, při připojování k databázi na cloudant.com mě to ale zlobilo, takže jsem zkoušel dál a celkem se zadařilo s českou knihovnou Jakuba Kulhana. Potom to může vypadat zase třeba takhle:

$couchdb = CouchDB::open(‚fsock://account.cloudant.com‘); $db = $couchdb->db(‚some_database‘); $params = array( ‚include_docs‘ =>‚true‘ ); $items = $db->view(‚some_design‘, ‚some_view‘, $params); if(isset($items->rows)){ foreach (items->rows as $item) { echo $item->doc->some; } }

Komu by stačilo si zjednodušit práci s HTTP, v článku na Couchbase.com se doporučuje HTTP_Request2 a Zend_Http. Současně tam, jistě zkušený, autor podotýká, že zatím nenarazil na PHP knihovnu, kterou by mohl doporučit pro všechny případy a k tomu se přidávám.

Historky z natáčení - CouchDB 2.

Fri, 12 Aug 2011 09:07:53 GMT

Může být nevědomost zdrojem dobrých nápadů? Myslím, že určitě, jen nevím jestli je to tenhle případ.

Mějme blog s CouchDb databází (například). Chtějme na hlavní stránce blogu zobrazovat počet komentářů u každého článku s tím, že články a komentáře máme v oddělených dokumentech.

Jsme u toho, že potřebujeme dělat něco jako JOIN, že? V MySQL denní chléb, v NoSQL trochu špunt v hlavě. Tenhle článek perfektně osvětluje, jak třeba udělat „JOIN“ v případě zobrazení článku s komentáři. Ok. Jenže to je případ kdy „taháme“ a zobrazujeme jak článek tak komentáře. Naproti tomu v případě ze začátku článku nechceme „tahat“ ani zobrazovat komentáře. Chceme jen jejich počet.

Zkrátím to – nevím jak to udělat. Nevědomost. Ale musím to nějak udělat. A mozek běží…

Co takhle udělat další typ dokumentu – meta dokument? Meta dokument, který by uchovával data o článku. Počet zobrazení, počet komentářů atd. Dost pravděpodobně je to nápad blbý a po pravdě řečeno se mi moc nelíbí, ale na druhou stranu, výpočetní výkon je dražší, než úložiště, čili počítat počet komentářů je dražší než ho ukládat.

Jenže zase ty vazby a určitá hrozba nekonzistencí a náchylnost k chybám…