Postřehy z KWebCMS 2

Věci, na které jsem narazil při vývoji KWebCMS 2

velke_soubory.htm

zakladni_operace.htm

2 kola komunikace

aneb proč mívám logiku v konstruktorech

Komunikace mezi pohlížečem uživatele a serverem je dvousměrná. Proto mi na stávajících kódech přišlo divné, že zpracovávající část je často smíchaná s odpovědní. Proto jsem zahájil praxi, kde modul dostává informace, které ho dále nastavují, již při sestavení. Uvnitř modulu pak jen přebývá struktura - a je na diskuzi, co všechno v ní musí být - v niž jsou již předpřipravená data pro výstup. Samotné volání výstupu pak jen vezme strukturu a podle potřeby s její pomocí vycpe šablony.

Můj přístup je excelentně vidět v instalátoru, kde požadavky od uživatele a serveru jsou logicky shodné celky, avšak funkčně musí paradoxně jít v obráceném pořadí (nejdřív výstup, aby bylo co nastavit, potom vstup, kde to zpracuju) a tedy by měly jít v po sobě jdoucích modulech - to se mi ve starší variantě trochu vymstilo. Ostatně je to i jeden z důvodů, proč nechávám při provedení modul chcípat na vyjímku. Neúspěšné dokončení znamená uchování popisku vyjímky a opětovnou inicializaci bez parametrů, zatímco úspěšné dokončení sáhne po dalším modulu.

Správa modulů - problém verzí

Spousta modulů bez správy - to je solidní problém. A ony se rády množí jako králíci. Bohužel máme tu spoustu líných programátorů, kteří nechtějí umět napsat podvozek. A pak máme spoustu ještě línějších uživatelů, kteří jsou rozmlsáni z desktopu. Takto nám začínají kynout knihovny a vzápětí i jednotlivé moduly. A v té celé míchanici se začínají moduly hádat o knihovny. Pak sem-tam někdo ukončí vývoj a zatímco uživatel by chtěl nějaký modul novější protože má další úžasnou funkci, díky které by si život zjednodušil, tak nemůže aktualizovat, neboť by si rozhasil jiný modul. A v tu chvíli je každá rada drahá. Udržovat vlastní větvi modulu svépomocí často nejde, neboť uživatel není automaticky programátor, natož zběhlý v dané technologii a nemusí mít potřebu koukat do cizích duševních výblitků. Navíc jeho čas je zhusta placen za jiné činnosti. Takže často zbývá jen možnost zůstat viset na stávající verzi. Ne vždy je takovéto rozhodnutí úplně mimo. Jindy autor předvede takovou duševní kreaci, že je to moc i na ostřílené kolegy. A pak zase zbývá jen sedět na starší verzi či (pokud to licence a schopnosti dovolují) se trhnout.

Aktualizace systému jím samým

Jo, dělám na aktualizačním modulu. Jak jsem již předeslal, v rámci hubení chyb a úprav střev je potřeba vydat něco, čím si uživatel bezbolestně může systém zaktualizovat. Stávající řešení na většině služeb využívá ruční práce správců. To ovšem vyžaduje o trochu více, než jen nahrát a zapomenout. Často to také znamená delší odstávku. A tak místo toho, aby změny chodily postupně (jako v operačních systémech), tak chodí najednou a často je to skok o několik verzí (alá firmy, ale ruku na srdce, kdo by měl chuť každý měsíc aktualizovat stanice od počtu 2 a víc, natož když základní pravidlo praví, že co funguje, na to se nehrabe). To začíná být problém - projekty jako PHP přechází na rychlejší vývoj a to znamená rychlejší nasazování i věcí na nich běžících. Naštěstí postup již před drahnou dobou představily linuxové distribuce. Já jej nyní hodlám aplikovat do světa webových aplikací. Základní ideu už mám popsanou na papíře (ne, kreslící tablet nevedu a myší se obecně kreslí mizerně), teď jen zjistit, co všechno je pro takovýto modul potřeba na obou stranách (u distribuce a u uživatele). Největší problém pravděpodobně vyteče z potřeby někde definovat verze, které se spolu baví.