devel.cz

Webové IDE používám už asi 10 let. Tehdy ještě žádné neexistovalo (kromě ORACLE Apex, který jsem viděl někde na výstavě) takže jsem si Web IDE napsal sám.
Za klíčové vlastnosti, ale považuji něco úplně jiného. Klíčová je podle mne integrace IDE do aplikace, což ovšem nevím jak moc v případě třeba Cloud9 jde. A také to záleží na tom jak je psaná ta aplikace. Základem mého IDE je samozřejmě editor zdrojáků, editor Db (něco jako phpmyadmin nebo adminer) a zobrazení tabulek v relačním diagramu. Konkrétně za nejdůležitější vlastnosti pokládám toto:

1. V patičce stránky mám ikonu a když na ní kliknu tak se přepnu do zdrojáku stránky. Tohle je naprosto killer vlastnost, neuvěřitelně návyková a příjemná. Po pěti letech přijdu k aplikaci (kterou si už dávno nepamatuji) zákazník najede na nějakou stránku řekne "tady chci přidat XXX" já se zaloguju najedu stejným způsobem na tu stránku zmáčku "jdi do návrhu" a jsem v tom správném souboru. Žádné projíždění adresářů, hledání souboru, pamatování si jak se jmenuje atd...

2. A samozřejmě po oeditování stránky kliknu na ikonu "zkontrolovat syntax, uložit, a zobrazit". Takže ten editor si pamatuje stavovou informaci stránky (v principu URL) z které jsem přišel a je schopen se k ní vrátit (to je zobrazit přesně stejné místo). Důležitá je i ta kontrola syntaxe, takovou tu prázdnou stránku s nápisem "Chybí středník na řádce 123" jsem neviděl ani nepamatuji. Tím se ušetří spousta kliků, přepínání mezi stránkami atd... Případné chyba vyjede mi to přímo v editoru a kurzor se přesune na příslušný chybný řádek.

3. A podobné je to s editací tabulek, ve zdrojáku si najedu kurzorem na tabulku, zmáčknu ikonu a v iframe mám její strukturu (editovatelnou), včetně indexů atd... Aplikační logiku mám v datových událostech (analogie trigerů, akorát nejsou zapsané v SQL, ale v PHP). Takže ve struktuře tabulky si vyberu z událostí Before/After + Insert/Update/Delete a jsem v editaci aplikační logiky na tom správném místě.

4. Je tam řada dalších vychytávek, třeba stránku si mohu zobrazit se "značkama volaných věcí" Pak se klikem na značku mohu přesunout nejen na správnou stránku, ale i přesně na řádek, kde ta značka je. A pokud je pro vykreslení použita nějaká komponeta, tak se dostanu přímo do zdrojáku té komponenty. Další značky jsou pro použité tabulky, takže přímo ze stránky aplikace mohu editovat struktury db. Samozřejmě tabulky mohu editovat i z relačního diagramu. V iframech mohu spustit je kontextovou nápověda pro PHP, CSS, SQL atd...

Samozřejmě zde popisované výhody (hlavně možnost pracovat odkudkoliv bez jakékoliv instalace se také uplatní), ale můj odhad je, že to je tak desetina těch výhod oproti tomu pokud je IDE integrované do aplikace. Ale nevím jestli se dá třeba ten Cloud9 dá do aplikace integrovat? A je k tomu nějaký "návod" jak to integrovat protože systém integrace IDE a aplikace člověk za týden nevymyslí.

Samozřejmě i aplikaci je pro tuto integraci nutno připravit, minimálně je potřeba moci některým uživatelům "přidělit práva pro vývoj", ale v praxi je to mám podrobnější, protože podle mne je hranice mezi vývojářem a uživatelem nezřetelná. Někdy překlady použitých textů dělám já někdy metodický gestor zákazníka, někdy CSS dělám já jindy tyto .css soubory a obrázky zpřístupňuji grafikovi...

Nějaké screany jak to u mne prakticky vypadá:
https://www.qcd.cz/rob/dev1.png První část menu (až po "Seznamy") je spíš vývojářská normální uživatelé na ní nemají práva. Ale je hezky vidět jak prorůstá aplikace a IDE
https://www.qcd.cz/rob/dev3.png Z relačního diagramu jsou samozřejmě volat i datové události (tj. editovat aplikační logiku)
https://www.qcd.cz/rob/pl3.png Tabulka "ví" jaké stránky se jí týkají takže z relačního diagramu lze i zobrazovat stránky, které se jí týkají. Na stránce "Firmy přehled" (která tam je v iframu, ale normální uživatelé ji mají jako základní stránku) je dole ta "vývojářská lišta" (nejlepší přirovnání je asi k hodně vylepšené laděnce z NETTE) kde se dá přepnout do zdrojáku, debugovat kód, explainovat a ladit SQLka z této stránky, ladit překlady, zobrazovat práva, atd... Pod tím iframe "Firmy přehled" je tato stránka firmy přehled "překnutá do zdrojáku" a to co je vidět je celý zdroják této stránky. Je vidět že se skládá, že čtyř komponent (Header, Bar na přpínání stránek, Grid, Footer) a právě součástí footer je ta vývojářská lišta (která se samozřejmě zobrazí dle práv).

09.11.2019 - Doplněno o dotaz na verzování

Aplikace se skládá z modulů. Modulem se myslí skupina tabulek, stránek, akcí, zobrazovacích komponent, lokalizačních stringů, skupin uživatelů, ... které spolu logicky souvisí a je vnitřně provádaná (a technicky mají stejný prefix). Aplikací je dále myšleno vše co je na serveru tj. jak funkčnost pro "uživatele" tak pro "vývojáře". Navíc já osobně si myslím, že tato hranice není ostrá a vývojáři jsou jen uživatelé s "o něco" vyššími právy. Ta neostrost se projevuje třeba u lokalizace aplikace, kdy někdy si jí dělá zástupce uživatelů (metodický gestor) jindy vývojář. Typická aplikace se mi skládá z těchto druhů modulů:

Sdílené "Core" moduly: To jsou základní moduly nezbytné pro běh aplikace, obsahují třeba komunikační vrstvu s db, komunikační vrstvu s FS, přihlašování (včetně login stránky a následných akcí), ... Tyto moduly se synchronizují se ze společného úložiště, a jsou tedy pro všechny mé aplikace stejné (běží na stejném kódu). Případné požadované odlišnosti jsou dané konfigurací aplikace či skinem aplikace.

Sdílené moduly potřebné pro vývoj: Třeba moduly pro správu tabulek, správu stránek, správu akcí controleru, správa datových událostí, správa lokalizací, správa komponent, správa skupin, správa vzhledů (skinů), synchronizace... Tyto moduly se dají v principu smazat a aplikace pro koncového uživatele by i nadále fungovala.

Sdílené moduly pro koncové uživatele: správa uživatelů (ten se instaluje vždy) a další instalované volitelné např.: meziuživatelský chat, fórum, znalostní databáze atd... prostě funkcionality, které se často hodí napříč různými zákazníky.

Specifické moduly pro daného zákazníka: Záleží na potřebách daného zákazníka, třeba: sklady, faktury, nabídky, poptávky, firem, lidé, produkty atd...

A jak to souvisí s verzováním? Ony každé ty moduly by chtěly trochu jiné verzování. Což souvisí se způsobem vývoje.

Jak tedy probíhá vývoj "modulů specifických pro zákazníka" a instalovaných na jediném místě na daném serveru?
Tyto moduly vyvíjím většinou přímo na "ostrém serveru". Což samozřejmě nevypadá tak, že bych uživatelům za běhu měnil stránky pod rukama, ale takto: Založím si nějaký "branch" což je vlastně jen to slovo, ten název toho branche. Pak si mohu aplikaci přepnout do režimu "pracuj v daném branch" což funguje takto jednoduše: Nikde nepoužívám přímo php include či require, ale mám na to speciální funkci. Ta, když má vložit třeba soubor './pages/app_PrehledFirem.php' si nejprve zjistí jestli jedu v nějakém branch a zjistí-li, že jsem třeba v branch "dev1" tak se jako první pokusí vložit './pages/app_PrehledFirem_branch_dev1.php'. Nenajde-li tento branch soubor tak vloží normálně './pages/app_PrehledFirem.php'. Takže tam mohu mít dvě verze daných stránek, normální uživatelé jedou na těch základních, vývojář pracuje na těch se sufixem __branch_neco a třeba metodický gestor si mezi nimi přepíná. Po schválení daného branch se prostě soubory s tímto branchem přepíšou ty základní soubory. Trojcestné slučování (na rozdíl od gitu nemám), takže musím zajistit, aby jedna stránka nebyla ve více branch.
Z tohoto typu práce je vidět, že u modulů, které nejsou synchronizované a jsou "specifické pro zákazníka" vlastně žádné verzování nepotřebuji (a nemám).

Vývoj společných "synchronizovaných modulů" probíhá někde na našem serveru úplně stejně, jediný rozdíl je v tom, že zákaznicky specifické moduly vyvíjím ve dvojici programátor + metodický gestor zákazníka, kdežto tyto společné ve dvou v klasickém párovém programování. Takže tam také žádnou verzi nepotřebuji.

Kde by se ale verzování hodilo, je v okamžiku kdy si sednu serveru k zákazníka a tam bych chtěl nahrát novou verzi nějakého společného modulu (či zkontrolovat jestli je tam aktuální verze). Ale bohužel tím jak vyvíjím "kontinuálně" žádnou verzi nemám. A rozhodně nechci někde nastavovat novou verzi třeba v okamžiku, kdy změním třeba jenom nějaký překlep v lokalizačním stringu. Šlo by to automatizovat (všechny zápisy zdrojáků mi jdou přes aplikaci) a dát tam nějaký event handler, který by podle prefixu zjistil o který modul se jedná a do verze modulu by zapsal třeba aktuální datum. Ale to mi přišlo složité. A vzhledem k tomu, že tu vlastní synchronizaci dělám pomocí komunikace serverových striptů, tak tu verzi nemusím mít uloženou staticky. Takže jsem to vyřešil tak, že "verzi" si vždy aktuálně spočtu jako nějaký crc součet souborů (a lokalizačních stringů, struktury tabulek, ...) daného modulu. Tyto součty si "synchronizační klient" stáhne a porovná se součty u sebe. A tím zjistí zda (a kde) se v daném modulu udály změny. A pak je lze zobrazit či synchronizovat (tj. přepsat).