Ubiquity for Firefox from Aza Raskin on Vimeo.

Dnes počas používania sa mi podarilo aj stiahnuť nejaké nové príkazy, plus sa mi nejake podarilo napísať. Všetky nové príkazy sa píšu v javascripte čiže je to pomerne jednoduché. Najjednoduchšie je asi si nechať v ubiquity editore vygenerovať prototyp príkazu a doimplementovať už iba logiku príkazu. Odporúčam si pozrieť video a skúsiť to Potom samozrejme stiahnuť nejaké príkazy (tu je celkom dobrý zoznam) alebo si napísať nejaké vlastné podľa návodu.

Moje aktuálne príkazy: http://www.tomaj.sk/html/ubiquity.html (js) - niektore som napísal, niektore stiahol a trochu upravil podľa mojich potrieb

Typoscript je deklaratívny jazyk. To si treba hneď na začiatku uvedomiť. Nie je to procedurálny jazyk ako PHP, takže veci ako napríklad cykly v ňom nenájdeme. Preto je tažké tieto jazyky nejak porovnávať. Jeho primárnou úlohou je popísať stránku spolu s ďalšímy objaktami a ich vlastnosťami z ktorých bude táto stránka zostavená. Z nich sa potom po transformácií vygeneruje požadovaný výsledok. Čiže typoscript sám o sebe nerobi vôbec nič. Slúži iba na popísanie objektov s ich vlastnosťami pre ďalšie spracovanie. Má stromovú štruktúru.

Takže krátka ukážka typoscriptu:

page = PAGE
page.typeNum=0
page.10 = TEXT
page.10.value = Hello world
page.20 = TEXT
page.20.value = a dalsi text...

Takáto jednoduchá šablona nerobí nič iné ako vygeneruje stránku na ktorú vypíše 2 vety. Každá typoscriptova šablóna musí obsahovať “objekt” PAGE. V príklade sa tomuto objektu nastavuje vlasnosť typeNum a potom sa v ňom vytvoria ďalšie 2 objekty typu TEXT na pozíciach 10 a 20. Tieto pozície sa dajú chápať ako číslovanie riadkov v starodávnom basicu To znamené, že vo výsledku budú tieto objekty zoradené poďla pozície, nie podľa riadku na ktorom boli definované. Nechem nejak hlboko popisovať typoscript keďže ide o pomerne komplikovnú vec. Viac sa dá dočíťať napríklad na oficiálnej dokumentácii.

Reálna ukážka

Prechádzajúci príklad slúžil len ako jednoduchá ilustrácia typoscsriptu, aby bolo jasné o čo asi ide. Teraz som pripravil konkrétny príklad generovania úplne jednoduchého menu na stránke.

page.10 = HMENU
page.10.1 = TMENU
page.10.1.NO {
   linkWrap =
	<li>|</li>
allWrap =
<ul>|</ul>
}

Tento príklad vygeneruje jednoduché menu zložené zo zoznamu UL a jednotlivých LI položiek. Ten istý kod by v PHP ako modul vyzeral nejak takto:

$query = 'SELECT title,uid FROM pages WHERE pid=1 AND deleted=0 AND hidden=0
	AND nav_hide=1 ORDER BY sorting';
$res = $GLOBALS['TYPO3_DB']->sql_query($query);
$items = array();
while ($row = $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res)) {
	$items[] = '
	<li>' . $this->pi_linkToPage($row['title'], $row['uid']) . '</li>
';
}
$GLOBALS['TYPO3_DB']->sql_free_result($res);
$menu = '
<ul>' . implode("\n", $items) . '</ul>
';

Takže porovnanie elegantnosti týchto dvoch riešení nechávam na Vás. Ešte ale musím podotknúť že menu generované prvým spôsobom je podstatne komplexnejšie, pretože rieši situácie ktoré druhá varianta nerieši. Bolo by to podstatne zložitejšie. Ide napríklad o situácie ako keď je stránka “shortcut” na nejakú ďalšiu stránku, alebo ak ide o takzvanú “externú url“. Tiež nepočíta so situáciou, keď má stránka alternatívny názov pre použitie v menu. Prvá alternatíva všetky tieto TYPO3 like featuri zohľadňuje a jednoducho to popisuje na 7 riadkoch.

Môj pohľad na vec

Osobne nie som nejakým extremistickým fanúšikom typoscriptu. Ale považujem ho za veľmi silný nástroj. Jednoduchá štandartná stránka sa da v TYPO3 spraviť len pomocou typoscriptu a klikania v admine. V niektorých prípadoch doinštalovať nejký ten nový modul. Samozrejme pri rôznych špeciálnych veciach a častiach stránok šitých na mieru pre daného klienta je potrebné riešiť aj PHP. A pri zložitejších projektoch je to samozrejme nutnosť ;-). Typoscript ma jednu veľkú nevýhodu. Pre človeka čo s TYPO3 začína je to asi nočná mora. Musí sa účiť jednoducho niečo nové, čo sa ľudom prirodzene nechce, keď už vedia PHP. Na začiatok to môže pôsobiť metúco. Netreba sa však hneď zľaknúť Naozaj je to mocná vec, ktorá výrazne odlišuje TYPO3 od ostatných CMS. Osobne mi príde rozumné riešiť veci typoscriptom, keď v ňom viem spraviť danú vec elegantne za 5 minút a v PHP by ma to vyšlo na viac.

Jedna trochu parafrázovana veta o TYPO3 hovorí, že TYPO3 ľudia buď ospevujú, alebo preklínaju. Žiadna stredná cesta zrejme neexistuje v čom sa čím ďalej viac utvrdzujem

Ďalšie linky o typoscripte

• krátke ukážky typoscriptu
• Typoscript examples
• Typoscript vs. XSLT (by kasper)
• typo3wizard.com
• typo3apprentice.com

CMS TYPO3 je rozdelené do rôznych balíčkov. Balík source je základný balík. Obsahuje všetky potrebné zdrojové kódy cmska. Na tento balíček treba pre reálne použitie aplikovať ešte nejaký ďalší poďla toho čo chceme robiť. Kedysi existovalo oficiálnych balíčkov viacero, dnes je udržiavaný asi len jeden - dummy package. Tento balík len rozširuje základnú adresárovú štruktúru a pridáva zopár súborov. Takže najjednoduchšia cesta ako nainštalovať TYPO3 je rozbaliť si niekde TYPO3 source a potom do neho rozbaliť TYPO3 dummy(tak aby súbory z dummy balíku prepísali tie zo source prirodzene). Je možné si vytvoriť aj vlastný balíček namiesto dummy balíčka a pripraviť si tam moduly, ktoré zvykneme použiť vo väčšine inštalácii spolu s predpripravnými nastaveniami. Dummy package je vhodné použíť v prípade, keď ideme vytvárať stránku samy.

Po nainštalovaní by mala vzniknuť takáto adresárová štruktúra:

• [D] fileadmin
• [D] misc
• [D] t3lib
• [D] typo3
• [D] typo3conf
• [D] typo3temp
• [D] uploads
• [F] index.php
• [F] _.htaccess

Značkou [D] sú označené adresáre a značkou [F] sú označené súbory. Ďalej sú tam ešte súbory typu README, clear.gif atď ktoré asi netreba popisovať, takže som ich vynechal.

FILEADMIN

Adresár fileadmin je určený pre ukladanie súborov. Je rozdenlé na viaceré podadresáre:

• [D] template
• [D] user_upload
• [D] _temp_

Adresár template(alebo aj templates) sa tam od začiatku nenachádza, ale zvyknú sa prave do tohto adresára ukladať html šablóny. Spolu s nimi aj csská, javascripty, obrázky a napriklad aj swfka. Jednoducho všetky staticke súbory.

Adresár user_upload je primárne určený ako adresár, do ktorého môže používateľ uploadovať, čo len bude chcieť, taktiež si tam môže vytvárať ďalšiu adresárovú štruktúru. Jednotlivé adresáre sa dajú sprístupniť pre rôzne skupiny/používateľov cez file mount-y.

Adresár _temp_ je podobný adresáru user_upload. Je určený na dočasné uchovávanie súborov. V každom prípade nikdy by sa nemalo nič linkovať na hocičo z tohto adresára, kedže ide iba o “temp”!

MISC

Tento adresár je určený pre veci ktoré sa inde nevošli Dajú sa tam napríklad nájsť rôzne varianty súboru .htaccess pre TYPO3, alebo pravidlá pre prácu s TYPO3 SVN ak by ste chceli prispieť niečim do jadra CMSka. Nič nevyhnutné pre beh aplikácie tam nie je, ale odporúčam sa tam aspoň jedným okom pozrieť Niekedy sa môže zísť…

T3LIB

Veľmi dôležitý adresár. Obsahuje triedy, ktoré používa TYPO3, či už v backende alebo frontende. Každý súbor predstavuje jednu triedu. Napríklad v súbore ‘class.t3lib_db.php’ je trieda s metódami pre prácu s databázou. Tiež napríklad ‘class.t3lib_cs.php‘ obsahuje triedu s metódami pre konverziu textu medzi rôznymi kódovaniami. Je dobré sa naučiť používať tieto triedy. Dokážu ušetriť čas.

TYPO3

Objemom ide o najväčší adresár. Obsahuje celý backend a tiež aj frontend so všetkými základnými modulmi. Bližšie to tu popisovať nemá význam, lebo by to bolo zbytočne veľmi rozsiahle. Možno o ňom nabudúce napíšem celý článok:-)

TYPO3CONF

Adresár, kde sú uložené všetky lokálne moduly a nastavenia. Zvyčajne má nasledujúcu štruktúru:

• [D] ext
• [D] l10n
• [F] localconf.php
• [F] temp_

EXT - tu sú uložené všetky lokálne moduly (tie, ktoré tam doinštaloval privilegovaný používateľ a sú potrebné pre danú inštaláciu). Každý modul je potom v samostanom podadresári.
L10N - adresár, kde sa ukladajú XML súbory s prekladmi popisných textov pre všetky lokálne moduly aj systémové moduly. Štruktúra týchto adresárov je nasledovná: Jazyk -> modul -> plugin -> jazyk.locallang.xml.
localconf.php - základný súbor s nastaveniami cms TYPO3. Obsahuje informácie potrebné pre pripojenie k databáze, zoznam aktívnych modulov atď… Niektoré nastavenia sa dajú konfigurovať cez TYPO3 inštalačný nástroj (123 install tool)
temp_* - súbor kde sú nacechované a pospajané configy z modulov aby ich nebolo nutné zakaždým spracovávať zvlášť.

TYPO3TEMP

Adresár určený pre ukladanie cache súborov. Obsah tohto adresára môže byť kedykoľvek vymazaný. Pri najbližšom requeste na stránku sa vygeneruje nový obsah. Obsahuje naparsovné XMLka, vygenerované javascripty a iné dočasné súbory.

UPLOADS

Veľmi dôležitý adresár, kde sa ukladajú všetky reálne použité súbory na stránke na ktoré sa ničo linkuje. Napríklad používateľ si do fileadmin/user_upload uploadne nejaký obrázok. Tento obrázok potom použije pri nejakom článku. TYPO3 tento obrázok nakopíruje do adresára uploads/EXTENSION_KEY/obrazok.jpg na ktorý to potom aj linkuje a zobrazuje na stránke. Tento prístup k správe súborov zabraňuje zmazaniu už použitého súboru na stránke. Čiže v prípade že si používateľ omylom tento obrázok zmaže z adresára user_upload, tak na stránke sa bude zobrazovať stále.

index.php a _.htaccess

Myslim, že žiaden špeciálny komentár netreba k týmto súborom netreba. Snáď len, že súbor .htacces má na začiatku v mene znak ‘_’, ktorý treba zmazať ak ho chceme použiť.

Našiel som na nete ešte jednu zaujímavú stránku kde boli vyrátane zaujimáve kalkulácie o TYPO3. Vcelku zaujímave čísla… a to sú ešte viac ako rok staré

Autorom jazyka Ruby je Yukihiro Matsumoto, ktorý celý tento jazyk postavil na veľmi pekných princípoch a myšlienkach. Jednoducho chcel vytvoriť niečo, čo bude jednoduché a v čom budú ľudia radi programovať a bude ich to baviť. Jedným základným princípom pri návrhu ruby bol princíp čo najmenšieho prekvapenia. Autor sa snažil vytvoriť jazyk, ktorý nebude programátorov prekvapovať nejakými záludnosťami. Autor bol primárne C++ programátor pred tým ako začal robiť na ruby. A ako sa hovorí, že aj po 2 rokoch intenzívneho programovania v C++ ho programovanie v tom jazyku vždy niečím prekvapilo. Tento syndróm sa nachádze takmer všade a preto sa chcel pri návrhu ruby tomuto čo najviac vyhnúť a spraviť ho čo najviac intuitívny a jednoduchý. Jedna veľmi zaujímavá myšlienka autora v podstate o spôsobe programovania:

Often people, especially computer engineers, focus on the machines. They think, “By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.” They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

A tak teda čo ja a ruby?

Pri jednom z posledných zadaní do školy som sa rozhodol, že ho skúsim imlementovať v ruby. Išlo o implementáciu nejakých mutačných algoritmov, kde sa program podľa vstupov a výstupov snaží prísť na to aká funkcia generuje dané vystupy z týchto vstupov. Na moje prekvapenie sa mi podarilo takmer celý program napísať na 200 riadkov a pomerne rýchlo. V podsate za jeden večer, kde väčšina času bolo aj tak štúdium tutoriálov a hľadanie rôznych konštrukcií. Celé sa mi to programovalo dosť intuitívne. Ku koncu som už nemal problém doslova uhádnuť nejakú metódu, čo ma celkom potešilo

Hneď o dva dni som potreboval na ďalší predmet implementovať ďalšie zadanie. Samozrejme som sa rozhodol pre ruby Pri implementovaní som sa cítil naozaj dobre. Písal som naozaj veci, ktoré som chcel aby program robil. Nemusel som sa starať o žiadne iné veci. Celkovo úsporný zápis ruby sa mi veľmi hodil. Už sa teším na ďalšiu implementáciu ďalších vecí. Rozhodol som sa, že budem do školy robiť všetko v ruby pokiaľ to bude možné. Naozaj sa to oplatí. Keby som to isté zadanie implementoval napríklad v c, tak by som s tým mal podstatne viac práce. Samozrejme človek čo pracuje s céčkom denno denne by to spravil raz dva ale určite tá efektivita, keď porovnáme čo všetko spraví jeden riadok v ruby a jeden riadok v céčku je jasná v prospech ruby.

Takže môj postoj k ruby je veeeľmi kladný. Samozrejme je to jazyk nie je vhodný na všetko Určité veci by som v ňom neprogramoval… O tom už možno niekedy inokedy. Ale ruby ako jazyk je podľa mna strašné mocná vec. Tiež sa mi veľmi pozdávalo aj Ruby on Rails, ktoré som skúsil. Samozrejme na prvom mieste je u mňa stále PHP, ktoré ako jazyk zaostáva veľmi ďaleko za ruby, stále má čo ponúknuť aj vďaka extrémne veľkej komunite a neskutočne veľkému množstvu rôznych aplikácií, ktoré sú v ňom napísané. No ale v každom prípade RUBY RULEZZ

Nejaké ďalšie odkazy

• Wikipedia a ruby
• Oficiálna stránka jazyka RUBY
• Ruby on Rails
• Yukihiro Matsumoto

Ďalšie odkazy

• FLOW3 - oficiálna stránka
• Kasperov TYPO3 podcast
• Robertov FLOW3 podcast

Pripravenie stránky javasriptu

Vo všeobecnosti odporúčam vkladať flash pomocou knižnice swfobject. Umožňuje automatickú detekciu potrebnej verzie flashu a možnosť ponúknuť automatickú inštaláciu novej verzie flashu vo flashi ;-). Viac na stránkach swfobjectu
Samozrejme je potrebné mať na stránke vložený kód GA pre meranie navštevnosti stránky kde je flash. Dnes je možné si vybrať z 2 GA kódov. Starý urchin.js a nový ga.js. Tento skript bude vedieť pracovať s oboma týmito kódmi. Takže do stránky si vložíme takýto kód:

<script type="text/javascript">
function trackMySubpage(subpageURL) {
   if (window.pageTracker) pageTracker._trackPageview(subpageURL);
   else urchinTracker(subpageURL);
}
</script>

Túto funkciu musíme vo flashi zavolať vždy, keď sa návštevník preklikne na novú stránku vo flashi. Flash bude posielať tejto funkcii ako parameter fiktívnu url pre danú stránku.

Pripravenie flashu

Vo flashi sa da javascriptová funcia zavolať takýmto spôsobom:

if(ExternalInterface.available) { 
  ExternalInterface.call(funcName:String, parameters....); 
}

V našom prípade to môže vyzerať napríklad takto:

if(ExternalInterface.available){ 
  ExternalInterface.call("trackMySubpage", "uvod"); 
}

Odporúčam vytvoriť si vo flashi nejakú triedu pre trackovanie celej aplikácie, kde by mohla byť zadefinovaná celá štruktúra stránky s fiktivnými urlkami, ktoré sa budú posielať do GA.

Záver

Pokiaľ je všetko správne nastavené, tak hneď na druhý deň by ste mali v GA vidiet reálne čisla pre jednotlivé podstránky vo flashi. Podobným spôsobom je samozrejme možné sledovať aj ďalšie veci v GA v prípade, že stránka napríklad využíva AJAX.

• Verzia 2.5 sa vyvýjala 185 dní
• Zmenených bolo 364 súborov v 54008 iteráciach a 29136 zmazaní
• Do novej verzie prispelo 110 rôznych prispievateľov
• Bolo urobených cez 1300 úloh. Kompletný zoznam.

Nova verzia prináša samozrejme trochu zmenený dizajn backendu aplikácie, ktorý teraz pôsobi čistejšie. Celý nový layout na mňa pôsobi jednoduchšie s menším počtom liniek na obrazovke. Práca pri písani a spravovaní príspevkov bola zjednodušená a pridané boli nové funkcie ako napríklad lepší upload, automatické dopĺňanie tagov pri článkoch a kopec iných

Priamo pri článku je možné uploadovať fotky, videa a hudbu. Všetko sa deje počas písania článku v špeciálnom okne. Je možné uploadnúť aj viac súborov naraz a pri uploadovní sledovať priebeh uploadovania. Hneď po uploade je možné nastavovať meta informácie ku všetkých súborom. Odporúčam pozrieť toto video, kde su predstavené nové featuri a dá sa ňom vidieť ako reálne nová verzia vyzera

Tak a prvý článok v novom wordpresse som napísal a môžem ísť spať Zatiaľ sa mi veľmi páči, uvidíme keď ho začnem ďalej použvíať.

Dôležité linky

• Download WORDPRESS 2.5
• Video a predstavenie základnych featur WORDPRESS 2.5
• Oficiálna stránka wordpressu
• Zoznam pluginov kompatibilných s novou verziou
• Základný návod ako upgradovať wordpress
• Podrobnejší návod ako upgradovať wordpress

Keď som začínal s PHP, tak som takmer vždy chcel všetko naprogramovať sám, navrhnúť si veci po svojom, potom ich implementovať, testovať a jednoducho sa tešiť z tejto práce. Toto je myslím vec, ktorú každý prográmator prežíva a v skutočnosti všetci normálni programátori chcú veci programovať(tvoriť) a nie len používať už niečo naprogramované. Preto sa tomu až tak nečudujem, keď si každý chce naprogramovať vlastné CMS. Aký je však z toho reálny výsledok?

• Programátor plný nadšenia začne robiť na svojom cms. Po veľmi krátkej dobe zisťuje, čo všetko by jeho CMS mohlo vedieť a aké by bolo skvelé a tak si spisuje všetko, čo ho napadne. Po chvíli má toho na stole toľko, že si začína uvedomovať, že to nemá šancu v blízkej budúcnosti dokončiť. Prvotné nadšenie vyprchá a CMS(hoci mohlo byť naozaj veľmi dobré a mohlo byť tak revolučné, že by prevalcovalo všetky ostatné) nikdy neuzrie svetlo sveta.
• Druhým prípadom je, že sa programátor pozerá reálne, nedáva si nereálne ciele a CMS nakoniec dokončí. Niečo sa pri tom všetkom naučí, použíje to CMS na nejaký jeden projekt(pre ktorý to možno aj celé pripravoval) a potom zistí, že pre použitie v ďalšom projekte bude musieť ešte kopec veci doprogramovať a možno aj prerobiť a tak sa na to vykašle…
• V prípade, že sa na to nevykašle tak ďalej vyvíja veci pre svoje CMS a lepí tak jednotlivé projekty a stále ho vylepšuje. Samozrejme strávil na vývoji enormne veľa energie a času a tak sa rozhodne si to CMS nechať len pre seba a ďalej v ňom lepí projekt za projektom
• V prípade, že sa rozhodne svoje CMS zverejniť, povedzme ako open source projekt a dúfa, že ho všetci začnú používať lebo je podľa neho skvelé. To sa ale vačšinou nestane… Prídu ďalší ľudia, zistia že je to len ďalšie CMS, ktoré im neponúka nič viac ako ostatné CMS na trhu, ba dokonca sa možno zvláštne ovláda a nastavuje (keď bolo stavané jedným programátorom tak je to dosť pravdepodobné). Zistia že za CMS stojí len jeden človek, čo znamená že si hneď uvedomia, že prípadná strata záujmu o toto CMS týmto programátorom bude znamenať koniec CMS. Čiže ho nakoniec nepoužijú…
• Úplne najkrajším scenárom by bolo samozrejme, že po zverejnení ho objavia programátori a používatelia a zistia, že je úplne revolučné a predstihuje všetku konkurenciu. Developeri zistia že sa do neho veľmi ľahko programujú nové moduly a tak za krátky čas vznikne CMS so silnou komunitou a používateľmi na celom svete.

Na koľko percent je podľa vás reálne, že nejaký začínajúci programátor dotiahne svoje CMS do posledného bodu a že jeho CMS bude lepšie ako iné CMS, ktoré vyvíja obrovská komunita ľudí a už v dnešnej dobe ho používajú stovky, alebo tisíce portálov?? Podľa mňa žiadna. Takže vo vačšine prípadov je programovanie vlastného cms úplná strata času.

Niektorí programátori si svoje CMS programujú len preto, aby sa niečo naučili, alebo možno do školy ako nejaké zadanie na jeden, možno aj naraz na viac predmetov Prečo je toto strata času a zbytočnosť? Samozrejme, vždy to CMS skončí už v prvej fáze a nikdy sa reálne nezačne používať. Takže jednoznačne to bude strata času. Uvažujme nad situáciou takto: Ak by sa programátor rozhodol radšej si preštudovať ako funguje nejake reálne CMS, ktoré používajú tisícky ľudí po celom svete a zistil ako sa to má fakt robiť. A následne na to by naprogramoval nejaký modul, možno dva a tie by zverejnil. O čo má vačšie šance, že jeho modul budú reálne ľudia používať? Podľa mňa neporovnateľne väčšiu. A každý programátor musí priznať, že ak jeho program niekto používa, tak má oveľa väčšiu motiváciu ho ďalej vyvíjat, resp. robiť na ďalších podobných veciach. Takže ak by sa tento človek na začiatku rozhodol pre rozširovanie už existujúceho cms, tak výsledok by bol oveľa lepší v prípade, že to, čo začne aj dokončí.

Tak prečo vlastne sa každý snaží programovať vlastné CMS??? Pretože je to jednoduchšia cesta…. Každý si myslí, že on to vie najlepšie. Nikomu sa nechce čítať nejakú dokumentáciu, pozerať cudzie kódy a prekonávať tieto prvotné problémy s novým CMS… Veď robiť niečo vlastné je predsa viac…
Nerobiť vlastné CMS, ale rozširovať už existujúce je v podstate oveľa ťažšie ako sa vrhnúť do vlastného cms, ale efekt je omnoho, ale naozaj omnoho lepší. V tomto prípade sa výsledky určite dostavia. Preto odporúčam programátorom, ktorí chcú isť programovať vlastné CMS, aby sa radšej poobzerali a otvorili oči. Našli si CMS, ktoré si naštudujú a naprogramujú niečo pre komunitu. Komunita a používatelia to potom určite ocenia a ich čas nebude zbytočne vyhodený.

A ešte jedna vec. CMSka budú vždy vznikať nové. Ale programovať vlastné má naozaj význam len pre nejakú firmu, ktorá potrebuje spraviť nejaké CMS pre totálne špeciálny projekt a úplne špecifického klienta. A v každom prípade ho nebude programovať jeden prográmator, hoci by bol aj veľmi skúsený, ale v takomto špeciálnom projekte ich bude určite viac.
PRETO NESTRÁCAJTE SVOJ ČAS A NEPROGRAMUJTE VLASTNÉ CMS, JE TO STRATA ČASU!!!!!

UPDATE kolega napisal celkom zuajímavy blogpost ako reakciu na tento článok: http://blog.monogram.sk/pokojny/2008/03/22/re-preco-je-programovanie-vlastneho-cms-v-dnesnej-dobe-uplna-strata-casu/