Návrh téma na další screencast
- Tharos
- Člen | 1030
Začátkem týdne jsem potřeboval vytvořil jeden screencast pro klienty do práce a když už jsem pracně poladil všechny kodeky, napadlo mě, že bych mohl také natočit nějaký Nette screencast.
V Nette už nějaký ten pátek dělám, a tak bych si troufl možná i na něco pokročilejšího, než na návštěvní knihu a podobné věci (čímž nechci v žádném případě snižovat existující screencasty – jsou vynikající!). Třeba bych úplně oželel to stahování a zprovozňování Nette zabíjející hned několik minut od začátku. :)
Napadlo mě udělat screencast o přípravě funkčního modelu podle vzoru Entity-Repository-Mapper tak nějak na zelené louce (respektive za použití Nette a Dibi). Mám takovou vrstvu hotovou a po nějaké době používání docela i prověřenou. Mně osobně se s ní pracuje výborně. A oproti pouhému publikování kódů někde na GitHubu by screencast mohl mít tu výhodu, že by v něm byly jasně patrné myšlenkové pochody při implementaci a tím by se to publiku určitě lépe chápalo jako celek (kód by pak samozřejmě byl i někde ke stažení).
Mohu nabídnout i to, že by celý vývoj byl řízen testy (TDD), a tak by to mohlo být přínosné snad i z tohoto hlediska.
Co vy na to? Anebo je nějaké urgentnější téma, které by stálo za to zpracovat?
Editoval Tharos (26. 5. 2011 14:54)
- newPOPE
- Člen | 648
Mne sa to paci.
Co sa tyka scrcastov co su doteraz tak aspon ja som sa snazil vyhnut nejakemu modelu nakolko to kazdy robi inak…
Ono v dalsom som mal v plane prejst na model (len jednoduchy filestorage napr pole…).
Nakoniec si myslim, ze zbytocne nestracaj cas na fore ale proste TO NATOC ;-).
Vela zdaru
- bojovyletoun
- Člen | 667
Já se také těším. Pokud by to bylo ve spolupráci s Notorm/Database. by to bylo super. Mě zajímá, jak začlenit Notorm do 5vModelu.
- Cifro
- Člen | 245
bojovyletoun napsal(a):
Mě zajímá, jak začlenit Notorm do 5vModelu.
Aj mňa. To by bolo fajn keby bol na to nejaký screencast.
- Tharos
- Člen | 1030
@newPOPE: To, že právě v pojetí modelu jsou napříč Nette programátory asi největší rozdíly, si také uvědomuji a taky jsem se toho trochu bál. Ale pak jsem si řekl, že to vlastně vůbec nevadí… Pro někoho bude screencast třeba trefa do černého, pro jiného inspirací a pro posledního třeba jen exkurzí, jak to dělají jiní.
Jsem rád, že ses ozval, Tvé sreencasty spolu s ostatními nasadily vysokou laťku. :)
@22: Tu cache by chtělo asi dobře promyslet, aby tam měla opravdu význam. Kešovat samotné dotazy (a nutno podotknout, že tady to budou dost triviální dotazy) nemá v podstatě žádný smysl a pak už se ve vrstvách nad tím odehrává jen zabalování do entitních tříd a předávání přes repository. Mám zkušenosti, že největšími adepty na kešování jsou právě následovné operace s entitami (například rekurzivní přeuspořádání do stromu v service vrstvě nebo tak).
Moc hezké je to NotORM předbíhání budoucnosti, ale to už by bylo výrazně nad rámec screencastu (a ani nemám s implementací něčeho podobného zkušenosti) a navíc to ani není třeba, protože v tom mém přístupu lze repository sdělit, jaké proměnné se mají v entitě inicializovat. Takže lze dosáhnout úplně stejných dotazů.
@bojovyletoun: Ono to je právě trochu problém, protože NotORM v podstatě představuje alternativu ke všem těm vrstvám a jeho začleňování do nějaké z nich je takové samoúčelné. Je zkrátka fakt, že NotORM, a posléze i Nette\Database, nejsou nástroje, které by byly určeny pro zakomponování do nějakého dalšího řešení – v podstatě si kladou za cíl (svým vlastním přístupem) pokrýt vše od A-Z.
Jinak mě napadlo, že bych to mohl rozdělit do více částí. Z více důvodů – určitě by tak byl první díl dříve na světě /dny versus měsíce :)/ a určitě by to bylo i stravitelnější. V prvním díle bych si představoval naprogramování a osvětlení úplného základu a nezbytného minima, ve druhém díle by se mohly například rozšiřovat repositáře a mappery on snadné použití IN operátoru (pro vazby ala NotORM, to už v podstatě naimplementované mám, i když to není tak advanced, jako v NotORMu) a třeba bych i mohl nějak předvést vytvoření služeb pro repositáře a použití z presenterů při plně DI přístupu za využití vestavěných DI nástrojů Nette? To mě jenom tak napadlo.
- na1k
- Člen | 288
Osobně jsem taky pro model, ale ani TDD bych se nebránil. Vždycky mě to zajímalo, ale nikdy jsem se k tomu nakonec nedostal :-p
Podobně jsem na tom ale i s NotORM, takže ať už to bude simple dibi model anebo nějaký NotORM model, určitě se podívám :)
Předem chválím za snahu, screencasty mi vždycky přišly takové lidštější než tutoriály/dokumentace ;)
- OK3
- Člen | 91
Za mě by to bylo využití DI (kontejneru) na nějakém smysluplném příkladu. Chápu, že využití DI úzce souvisí s architekturou aplikace, takže by bylo fajn se na to podívat nejdřív globálně (proč a kde to používat) a pak na konkrétním příkladu implementace (jak). Princip DI chápu, ale trochu mi chybí konkrétní příklady užití.
Každý screencast je subjektivní a prezentuje určité best practices autora a myslím, že (jak už zaznělo) je to tak v pořádku.
Editoval OK3 (27. 5. 2011 11:25)
- Tharos
- Člen | 1030
@OK3: DI mě též napadlo, ale připadá mi, že ideální je prezentovat DI na nějaké skutečné situaci. Ne úplně na zelené louce (respektive na čerstvě vysypaném pískovišti). Ale u těch modelů by šlo DI více přiblížit třeba v tom druhém díle – šlo by ukázat, jak implementovat nějakého správce repositářů a jak jej injektovat do presenterů, komponent či podle potřeby dalších modelových tříd. V podstatě je to i nezbytný krok k tomu začít ty modelové vrstvy reálně používat.
Co se DI týče, rozdíly napříč programátory jsou snad ještě větší, než u modelů samotných. :) Takže tady by to asi byla totálně subjektivní záležitost. Ale inspirativní by to určitě bylo :).
Jinak na natáčení jsem si vyhradil jeden z pracovních dní příští týden, kódy už mám de facto kompletně připravené. Do 5. června by měl být screencast online.
- Tharos
- Člen | 1030
Jo, napadla mě ještě jedna věc. Na závěr bych mohl ukázat i jednoduché profilování pomocí XDebugu a WinCacheGrindu za účelem ověření, že napsané vrstvy nejsou nějakým „performance killerem“. A vůbec za účelem takové lehké exkurze, co jak dlouho v Nette trvá a jak pracovat s WinCacheGrindem.
Není to nijak složité téma, ale třeba i to by mohlo pro někoho zvýšit užitnou hodnotu screencastu.
- Tharos
- Člen | 1030
@HosipLan: Že by začal vybalením komponent z krabice Alza, pokračoval sestavením počítače, instalací Windows 7 a tak dále říkáš :). Nesmí to být dlouhý, dávám si limit 60 minut /scénářový, takže tak +/- 15 minut ;)/.
@xxxObiWan: To bych ale určitě dával až do nějakého dalšího dílů, na jeden screencast už by to bylo moc. A taky bych pak rád své řešení předem představil alespoň několika místním Nette Guru a poprosil je o oponenturu. To aby to bylo opravdu kvalitní a neprezentoval jsem nějaké vyloženě sporné věci (třebaže funkční).
- Ondřej Mirtes
- Člen | 1536
Hodinový screencast? A na to bude někdo koukat? Nemyslím to zle, jsem rád, že chceš něco udělat pro komunitu (sám bych na screencast neměl nervy), ale bylo by dobré, aby ta práce nepřišla nazmar.
Screencasty by měly mít jedno téma a měly by být krátké, tedy 5 až 10 minut. Tomík Vítek dělal desetiminutový screencast 35 hodin, aby za něco stál, což s hodinovým screencastem fakt nedokážeš.
- Tharos
- Člen | 1030
@Ondřej Mirtes: Jsem přesvědčen (shlédl jsem myslím také dost screencastů, i opravdu dlouhých), že délka nemusí být problém (pokud to není opravdu celovečerní film). Shlédl jsem pro inspiraci všechny screencasty týkající se Nette a už jeden ze současných má 20 minut. A nepřijde mi, že by byl špatný. Při jeho sledování jsem se nenudil a pozornost bych udržel klidně i déle.
Jsem přesvědčen, že hodinu dospělý člověk pozornost udrží, zvláště pak v pohodlí domova. Školení běžně mívají v jednom dni 8 hodin a přestávky se dělají často právě po hodinách. Navíc není problém shlédnout screencast na více fází, je-li dobře strukturovaný. Spíš je opravdu důležité, aby každá minuta byla kvalitní – nekvalitních 5 minut budu mít osobně větší problém shlédnout, než 30 minut smysluplného videa.
Možná si trochu špatně rozumíme v tom, co nazýváme screencastem. Délka 5 minut je ideální pro nějaké promo video o nějakém produktu (pak je 5 minut možná až moc, ideál je IMHO někde kolem 2 minut). Do takového času se vejde třeba ono stažení a zprovoznění Nette Frameworku.
Má-li se ale jednat o demonstraci nějakého složitějšího problému, i 10 minut je žalostně málo. Zeptám se jinak – máš problém vydržet třeba u hodinového záznamu z nějaké přednášky z nějaké zajímavé konference? To, co bych rád vytvořil, bude cílené na jinou skupinu diváků, než Tomášův (vynikající!) screencast. Bude to určené spíše do „učebny se zainteresovanými lidmi“, než někam na veletrh frameworků s tisícem kolemjdoucích. Určitě cítíš ten rozdíl.
Ale tak jako tak je 60 minut na hranici a mám samozřejmě motivaci udělat to co nejkratší. Jenom ale nechci na úkor komplexnosti…
Editoval Tharos (27. 5. 2011 19:58)
- Mikulas Dite
- Člen | 756
Lepší vrabce v hrsti, než holuba na střeše. Jasně, že delším a obsáhlejším se půjde prokousat. Jenomže než to vydáš, bude Nette už úplně jinde.
Editoval Mikulas Dite (27. 5. 2011 20:11)
- Tharos
- Člen | 1030
@Mikulas Dite: Natáčet to budu příští týden, už na to mám vyhrazený čas. Kódy už jsou hotové, scénář ladím po večerech. :)
Edit: Chci předem upozornit, že to nebude mít takovou kvalitu (scénář, střih) jako Tomíkův screencast, ale propadák to snad taky nebude. A obsahovou hodnotu to určitě bude mít. Kvalitou bych se rád přiblížil ostatním screencastům /tím mám na myslim těm ne-Tomíkovo :)/, které mi přijdou, že nejsou špatné.
Editoval Tharos (27. 5. 2011 20:17)
- Nox
- Člen | 378
Neřekl bych že 20+ minut je nějaký problém, třeba nedávno známé video ‚10 things I learned from jQuery source‘ od Paula Irishe má 53min … pokud člověk umí přenášet tak i mnohem víc je ok
„Hodinový screencast? A na to bude někdo koukat?“
to je jen 1/3 školní přednášky… a narozdíl od ní si to můžeš
libovolně kouskovat atd.
- Tharos
- Člen | 1030
@spidy: Jeden článek přesně na toto téma už existuje a je velmi dobrý. Nerad bych toto téma v Nette Wiki nějak duplikoval…
Takže tématické resumé:
1. díl
- Lehký teoretický úvod (opravdu lehký, aby se zbytečně neztrácel čas)
- Návrh veřejného API repozitářů (aby se s tím pohodlně pracovalo a použití bylo minimálně tak snadné, jako napsat SQL dotaz :-P)
- Naprogramování abstraktních base tříd
- Implementace ukázkové entitní třídy, repositáře a mapperu
- Ukázky použití
- Zbyde-li čas, krátká exkurze do WinCacheGrindu
Vývoj bude řízený testy, ale z časových důvodů se nebudu snažit o nějaké 95% pokrytí kódu…
2. díl
- Rozšíření o podporu pro snadné použití (v současné době populárního) IN operátoru
- Ukázka získávání entit ve vztahu 1:N
- Rozšíření o snadné získávání entit ve vztahu M:N, přičemž vrstvy budou generovat optimální dotazy (aka NotORM, i když samozřejmě API NotORMu je ještě někde jinde)
- Ukázka získávání entit ve vztahu M:N a nějakých dalších složitějších konstrukcí (což mi u ukázek týkajících se tohoto návrhového vzoru vždycky trochu chybělo) → v podstatě vše už mám v šuplíku a snad i docela odzkoušené…
- Zabalení do služeb a ukázka používání celého výtvoru v duchu DI
Tak a teď už se tu přestanu vykecávat a jde se na to. Mým dalším příspěvkem nechť je odkaz na výsledek. :) Díky moc za dosavadní názory!
Editoval Tharos (29. 5. 2011 19:03)
- bojovyletoun
- Člen | 667
Lepší je imho KcacheGrind. Ohledně modelu jsem měl takovou vizi- nápad:
vytvoříš si službu EntityManager- což je hlavní prvek. Pak tam je třída
Repository- která bude základní- ale ne abstraktní – entity manager
zavolá repository – nějaké entity – Repository v konstruktoru určitě
bude mít jméno entity. Teď přijde magie – Pokud bude Pro danou Entitu
existovat její speciální Repository – tak se vytovoří on. (zatím nevím
jak konkrétně – zda to je jako v neuronu, kde je např namespace
models\Aritcle\{Finder,Article,Service}. (Finder představuje repository,
Article Entitu).
Tím by bylo hotové repository. Ser
Ještě jedna poznámka, chtělo by to, aby ústřední prvek byl místo Repository Service, která by měla referenci ne Repository.
- Tharos
- Člen | 1030
@bojovyletoun: KCacheGrind je linuxový a já osobně vyvíjím ve Windows. Ono existuje neoficiální build pro Windows, ke kterému se lze po několika minutách dogooglovat, ale mohlo by být matoucí, kdybych tam najednou ve Win 7 otevřel KCacheGrind :). Je samozřejmě na funkce bohatší, ale WinCacheGrind je taky dobrý nástroj a pro účely zpestření nějakého screencastu vychází podle mě úplně rovnocenně… A proto kdyžtak použiji nástroj nativně dostupný pro Windows.
Díky vřele za další hodnotné poznámky. Ono se pohybujeme přesně v oblasti, kde co člověk, to názor. :) Něco mám naimplementované podobně, jak popisuješ, něco jinak. Předně nemám v kódu nic magického, protože mám zkušenosti, že výhody všemožných magií jen málokdy vyváží horší čitelnost, transparentnost a pochopitelnost kódu. V tom prvním díle bych chtěl klást největší důraz na mapper a API repository (mapper je „funkčně nejzajímavější“, API se zase hodí mít efektivní). Samotné repository bývá v jednoduchých příkladech vcelku triviální a nějaký manager nad tím vším je IMHO až další krok.
Editoval Tharos (29. 5. 2011 20:35)
- Filip Procházka
- Moderator | 4668
bojovyletoun: tady je vidět nepochopení DDD :) protože repository a service nejsou ve vztahu 1:1 ale N:1. To samé Finder, mi přijde jako přešlap. A zbytek je opisování Doctrine. No jsem zvědav co z toho vyleze :)