1. ZÁMĚR
1.1. Chceme nadchnout PHP vývojaře se zkušeností s nette, aby k nám přišli pracovat do SiteOne.
1.2. Poukazujeme na to, že SiteOne je velkým přítelem frameworku, který si vybrali a že ho posouváme ještě o kousek dál.
1.2.1. ...PHP vývojaři jsou v SiteOne považování za zlato, pracoval bych se spoustou chytrých lidí...
1.2.1.1. Myšlenku potvrzujeme vychytávkama nad rámec toho, co nette poskytuje a integrovaným workflow.
1.3. Měli by si odnést, že je práce v SiteOne dokáže odstínit od nudných a opakujících se činností, které možná musí podstupovat jinde.
1.3.1. ...Už mě nebaví dělat pořád dokola to samé, ale u nás mým inovacím nikdo nerozumí a nikdo mi na to nedá čas. V SiteOne by to bylo jiné...
1.3.1.1. Myšlenku potvrzujeme připravenými nástroji, které se jinde píšou furt dokola
1.4. Chceme je zaujmout tím, že pracujeme pro super klienty a na velmi navštěvovaných projektech.
1.4.1. ...Už mě nebaví dělat weby pro Pepu Vonáska, nebo facebookové microsity s životností pár měsíců. Chci svůj otisk na českém online trhu...
1.4.1.1. Myšlenku potvrzujeme featured klienty na screenshotech. Cílem je, aby když si dotyčný otevře ten web, aby na první pohled viděl, že je to hustý.
1.5. Nezapomenout tam dát nějakou naši společnou fotku, ať to má lidskou tvář. Třeba z Painballu se textací "Přidej se k nám"
2. Trošku kecáme, jsme rádi, že tým okolo nette v čele s Davidem Grudlem vydali nedávno finální nette 2 :) Pro všechny vývojaře v SiteOne je nette především nástroj, který nás zbavuje otravných činností při tvorbě, pomáhá při ladění, zabezpečení našich webů a v neposlední řadě podporuje dobré návyky a týmovou spolupráci. Za roky používání nette jsme si vytvořili pár vychytávek, které posouvají naše workflow ještě o kousíček dál a chtěli bychom se o ně podělit.
3. Automatické generování DB Modelu na základě struktury databáze
3.1. Funguje to takhle
3.1.1. V SiteOne klademe důraz na kvalitní návrh databáze, ze kterého, díky analýze schématu, zpětně generujeme DB model - tzn. opační přístup, jako s Doctrine. Značná část doménové logiky je řešená na DB úrovni formou triggerů a uložených procedur.
3.1.2. Nejdříve navrhneme a vytvoříme databázi
3.1.2.1. Tabulky i sloupečky opatříme komentáři
3.1.2.2. Zavedli jsme speciální značky do komentářů, které říkají, že se např. sloupeček nemá vkládat z formuláře, protože se plní jiným způsobem (auto increment, trigger, ...)
3.1.2.3. Vytvoříme cizí klíče
3.1.3. Poté spustíme generátor, který nám připraví nette třídy přesně podle databázového modelu
3.1.4. Do tříd generátor automaticky přenese komentáře a doc bloky tak, aby nám jakékoliv IDE krásně hintovalo
3.1.5. Hotovo, můžeme pracovat :)
3.1.6. V případě, že potřebujeme změnit model, změnu provedeme pouze v databázi a generátor nám upraví již existující kód.
3.2. Potřebuju odpovídající screenshoty, které ukazují databázový model s commenty
4. Generování administrace
4.1. Přiznejme si, že jednou z nejúnavnější činností je psaní administrace. Většina webů potřebuje spravovat desítky entit, je nutné ošetřit přihlašování, role, práva v rámci systému a spoustu dalších věcí. Protože se jedná o opakující se práci, připravili jsme i generátor na admin, který za nás udělá většinu otročiny. Nám pak zbyde čas na třeba na optimalizace rozložení prvků ve formulářích a další UX vychytávky, které uživatel ocení.
4.2. Funguje to takhle
4.2.1. Na základě vygenerovaného DB modelu (který zná všechny souvislosti mezi doménovými objekty) můžeme vybrat, pro který doménový objekt chceme CMS generovat. Vybereme, co má být součásti seznamu, exportu, filtru, přidávacího i editačního formuláře. Generátor zároveň rozumí vazbám mezi objekty a přímo do editace objektu přidá správu vazeb na další objekty. Vygenerovaný presenter a Latte šablony jsou hned funkční. Někdy to stačí, někdy se to dále “velebí” o funkčnosti, které již automatizovat nejde.
4.3. Potřebuju screenshoty, které ilustrují, jak je to awesome.
5. Správa prostředí
5.1. Každý projekt je nasazený na spoustě místech. Každý vývojař má svou instanci, máme společné testovací prostředí, předprodukci a jednu nebo i více produkčních prostředí. Každé se může připojovat do jiné databáze, může mít vlastní nastavení pro zpracování chyb, zobrazení laděnky, cachování a spoustu dalších věcí. Abychom si ulehčili život a zjednodušili nasazování, vytvořili jsme společného správce prostředí.
5.2. Funguje to takhle
5.2.1. Na vývojovém serveru ti připravíme vlastní instanci projektu
5.2.2. Pro každého vývojáře máme připravenou možnost vlastní konfigurace
5.2.3. Pro každé prostředí - devel, test, integr, preprod, prod... - máme připravenou možnost vlastní konfigurace - milujeme config.neon
5.2.4. Jaká feature bude kde nasazena je ve správě verzovacího systému
5.2.5. Nasazování do konkrétního prostředí je tímto velmi snadné, bezpečné a rychlé
5.2.6. Bacha, neměli bychom zmínit, že tím ,že máme veškerou konfiguraci v SVN v podstatě tvoříme security problém, protože kdokoliv, kdo má přístup ke zdrojákům, má automaticky přístup do všech prostředí.
5.2.6.1. MST: Myslím, že jsme se shodli, že to nějak extra řešit nebudeme. Současné řešení nám přináší spoustu výhod.
5.2.7. sem chci dát i handlování 404ek
5.2.8. Chci screenshot kódů
6. Správa URL a SEO konzole
6.1. Někteří naši klienti mají externí SEO agentury, kterým chtějí dát možnost spravovat URL webu, titulky stránek, keywords a description, ale nechtějí jim zpřístupnit celou administraci. Proto jsme vytvořili SEO Toolbar, což je pro SEO konzultanta to samé jako Laděnka pro vývojaře.
6.2. Funguje to takhle
6.2.1. Často nám standardní Nette routy založené na pravidlech (formátech URL) nestačí, proto jsme vyvinuli vlastní Router, který nám umožňuje mít jakékoliv URL, bez dodržování formátů. Klient navíc může na všech stránkách webu využívat tzv. SEO toolbar, kterým je možné spravovat informace související s vyhledávači.
6.2.2. Tady reálně mixuju dvě rozdílné věci dohromady. Jsem si toho vědom. Pokud by to pro vás nebylo zkousnutelné, tak mi dejte vědět.
6.3. Potřebuju screenshot SEO Toolbaru
6.4. Potřebuju screenshot kódu, který ilustruje sílu správy URL
7. Inline CMS
7.1. Pro spoustu projektů by bylo plnohodnotné CMS kanónem na vrabce. Proto jsme připravili lightweight inline CMS, které ke svému chodu nepotřebuje obsah uložený v databázi. Funguje to tak, že uživateli s patřičným oprávněním zobrazíme na webu tlačíko pro přepnutí do editačního režimu. Pokud ho zvolí, může upravit bloky textu, které jsou označené příslušnými značkami. Změna se uloží přímo do souboru s šablonou. Bezpečnost je zajištěna, uživatel jásá. Velkou výhodou je i to, že Inline CMS je možné na webu zapnout i dodatečně.
7.2. Funguje to takhle
7.2.1. Klient chce mít obsah na stránce editovatelný. Na běžném webu a bez prvotní přípravy špatná zpráva. Ne pro nás.
7.2.2. Otevřeme šablonu stránky
7.2.3. Obsah, který má být editovatelný uzavřeme do speciálního latte makra
7.2.4. Hotovo! Nyní je obsah po přihlášení přístupná inline editace. Včetně live náhledu, revizí a přehledu změn přímo na webu!
7.2.5. Dále chci screenshot kódu, kterým se určuje to, co se edituje