Technologické řešení webu

[Ondrej.dj-bobr.Ulehla]

Ahoj, v diskusi o koncepci webu a navazujícím setkání se nám podařilo dosáhnout vymezení informací, které by web strany měl obsahovat a co je jeho cílem. Nyní v tom budeme pokračovat, pojďme diskutovat o vhodném technickém řešení (vzhled se řeší jinde). Standa Štipl nastínil několik variant a budu rád, pokud je rozebereme i promluvíme o alternativách.

Já jsem uvedl nějaké zásady, které by podle mého mělo splňovat každé řešení:

Principy fungování webu

Web je v celém svém fungování příkladem uplatňování politiky strany (citování autorů, github, odpovědnost).
Web je časově neomezeně a rychle dostupný (statický web pomocí generátoru, jednoduché styly a skripty, minifikace) a zobrazování na všech zařízeních (responsive design).
Web není používán jako náhražka jiných webových aplikací strany.
Web je klonovatelný pomocí github a v případě likvidace serveru znovu nahoditelný.
Na web přispívají autorizované osoby, v každém kraji je vyškolen aspoň jeden správce.
Web dodržuje rozšířené konvence a standardy webdesignu.
Web je grafickým základem pro všechny ostatní webové aplikace strany (např. horní lišta).
Každý informace je snadno dohledatelná do 3 kliků.

Diskuse k technickému řešení proběhne na základě podkladů v tomto vlákně v úterý 17.2.2015 po 19. hodině v Pirátském centru.

Dávám sem některé zajímavé technické okruhy k diskusi:

• Já mám zatím dobré zkušenosti s jekyllem a foundation.
• Je třeba, aby někdo navrhl strukturu krajských webů. Pod krajskými weby by byly také příslušné reporty zastupitelů. Je třeba popřemýšlet o tom, zda zachovat současné krajské subdomény a zřizovat městské subdomény.
• Je třeba vymyslet, jak ty krajské weby navázat do stranického a jak synchronizovat společný obsah (např. styly - pomocí submodulů?). Vašek Klecanda v tom přislíbil pomoc.
• Vašek také upozornil na nástroj usnadňující úpravy za běhu (prose.io).
• Pokud by byl použit systém jekyll, je možné hostovat na githubu, a tedy mít dostupný zdarma dobrý hosting. Je třeba mít dobře zdokumentovaný návod na specializované úkony (minifikace css a js apod.).
• Vedle toho je třeba vyřešit otázku dynamických prvků webu (registrační formulář, go pay brána).
• Je vhodné si položit otázku, zda chceme pod články povolit diskusi či nikoliv a sofistikovaně si na ni odpovědět.

[Vaclav.Klecanda]

- Weby bych rozhodne hostoval a delal na githubu s vyse zminenymi vyhodami.
- Decentralizaci bych resil pomoci subdomen, kde kazda organizace (kraj, MS) ma svoji subdomenu. Vyhoda: web je rozdelen na mensi, kdyz se vhodne prolinkuji, pro rank vyhledavacu je lepsi vice mensich, nez 1 velky.
- universalni styl/js bych resil samostatnym projektem s asset pipeline nastroji = minifikace, uglifikace, sass compilation, ... (muze byt i v jinych jazicich nez ruby), dulezity je ten vystup z nich, ktery se verzuje -> odkazovatelny z jednodlivych stranickych webu. Vyhoda: stranicke webu nemusi obsahovat zadne css, nebo js, ale jen a pouze content.

[Jan.Kohler]

Nejsem si jist, zda teď nenavádíme k opačnému extrému.

Jekyll mám rád, též ho využívám, ale:

1. Nejsem si jistý GH-pages v daném kontextu, neporušíme pravidla? Přecijen tohle už není jenom "webík", ale portál, který má potenciál být jedním z největších a zároveň nejprovokativnějších v ČR
2. U submodulů bych chtěl vidět proof of concept
3. I v případě malého pražského webu jsem to několikrát opravoval, protože "zaškolená" osoba neuměla správně commitovat. Na tom není nic divného - opravdu to není jednoduchá dovednost. Opravdu se jí nenaučí každý. (Opravdu nežijeme v ideálním světě.)
4. Vzhledem k tomu co všechno na tom webu nejspíše chceme (kalendář, účet), tak budeme buďto dělat hrozné hacky, nebo budeme využívat masivní JS API, které stejně celý web zpomalí. Dokonce by to mohlo vypadat, tak, že se vždy načte web, kde reálný návštěvník nikdy některé moduly nespatří, jelikož tak dlouho na webu není.
5. Z předchozího bodu plyne, že budeme stejně mít docela velký backend. Na druhou stranu ten samozřejmě může sloužit i dál.
6. liquid je asi nejhnusnější značkovací jazyk, který jsem kdy viděl. Vede k dosti prasáckému kódu. Opět s tím máme bohaté zkušenosti.

Nechci tím pohřbít tuto cestu. Jen bych se nerad vydal hůrá cestou, kterou bude někdo za rok a půl napravovat.

[Stanislav.Stipl]

Také nejsem zastáncem toho využít Github a Jekyll za každou cenu. Právě tady a teď je prostor si některé věci včas a důkladně ujasnit.

Nejsem si jist, zda teď nenavádíme k opačnému extrému.

Jekyll mám rád, též ho využívám, ale:

• Nejsem si jistý GH-pages v daném kontextu, neporušíme pravidla? Přecijen tohle už není jenom "webík", ale portál, který má potenciál být jedním z největších a zároveň nejprovokativnějších v ČR

Co jsem zběžně procházel podmínky GH, nenašel jsem nic, co by vyloženě bránilo umístění našeho webu. Nedomnívám se také, že by náš web byl kontroverzní do tém míry, že by to zrovna GH měl potřebu řešit. Je ale pravdou, že:

• služba je zcela bez záruky
• pokud by uživatel generoval nadprůměrný traffic, může jej github odpojit; to se může stát velice snadno například v době před volbami, kdy by to bylo zvlášť nepříjemné

• U submodulů bych chtěl vidět proof of concept
• I v případě malého pražského webu jsem to několikrát opravoval, protože "zaškolená" osoba neuměla správně commitovat. Na tom není nic divného - opravdu to není jednoduchá dovednost. Opravdu se jí nenaučí každý. (Opravdu nežijeme v ideálním světě.)

Zde bych viděl jako prioritu, abychom skutečně v každém kraji zaučili aspoň jednoho člověka, který to umět bude. Každý člen by měl aspoň tušit, co to git je a k čemu slouží. Podobně, jako by měl každý Svobodný vědět, co je to Laissez faire a každý zelený vědět, co je biomasa.

[*]Vzhledem k tomu co všechno na tom webu nejspíše chceme (kalendář, účet), tak budeme buďto dělat hrozné hacky, nebo budeme využívat masivní JS API, které stejně celý web zpomalí. Dokonce by to mohlo vypadat, tak, že se vždy načte web, kde reálný návštěvník nikdy některé moduly nespatří, jelikož tak dlouho na webu není.
[*]Z předchozího bodu plyne, že budeme stejně mít docela velký backend. Na druhou stranu ten samozřejmě může sloužit i dál.[/list]

Nechci tím pohřbít tuto cestu. Jen bych se nerad vydal hůrá cestou, kterou bude někdo za rok a půl napravovat.

Problém může nastat u následujících komponent:

• kalendář (řešitelné js nebo iframe)
• účet (stejné jako kalendář)
• platební brána (řešitelné tak, že na titulce bude pouhý odkaz na bránu samotnou)
• komentáře (doporučuji udělat rozhodnutí, že komentáře na hlavním webu nebudou - k tomu slouží jiné kanály)
• vyhledávání na vlastním webu (imo největší problém, v podstatě nemožné rozumně realizovat, otázkou je, zda je vůbec potřeba)
• youtube kanál (ne až tak podstatné)

Nemyslím si, že by se jednalo o hrozné hacky a že by to nutně muselo mít zásadní vliv na rychlost načítání. Na druhou stranu bych zmínil ještě jeden aspekt - informace, které se budou načítat přes JS, nebudou indexovat vyhledávače.

[Stanislav.Stipl]

Ještě pár pros/cons ke GH pages:
- načítání stránek nemusí být zrovna rychlé, například kvůli geografickému umístnění serverů
- použití CDN bude problematické
+ v pokud se rozhodneme zkusit Jekyll a GH pages, kdykoliv můžeme snadno přejít na Jekyll bez GH pages

[Lukas.Novy]

Zdrojaky na github, zkompilovane stranky hostovat na nasem zeleze, update pres github webhooks.
+ vsechny vyhody github pages
+ zadne dalsi podminky od github, ani zruseni uctu stranky nevypne, lze okamzite prejit na jineho hostera repository
+ lze pouzit s CDN
+ ochrani nas pres nekolika typy bezpecnostnich problemu (filtrovani Set-Cookie, vkladani pouze schvaleneho JS)
+ moznost injekce dynamickeho obsahu do staticky vygenerovanych stranek (url routing + server-side includes...)

[Ondrej.Profant]

Lukáš: Tím pádem nám z původních zbude:
+ lehký fork a provozování vlastní instance (nevidím rozdíl oproti jakémukoliv normálnímu zdokomentovanému zdrojáku)
+ hotová a otestovaná kompilace (nicméně to má dnes každý framework)
- liquid
- vlastní infrastruktura o kterou se staráme
- náročný způsop správy obsahu

[Stanislav.Stipl]

+ moznost injekce dynamickeho obsahu do staticky vygenerovanych stranek (url routing + server-side includes...)

Zajimavy napad, ale to uz celkem hack je

Lukáš: Tím pádem nám z původních zbude:
+ lehký fork a provozování vlastní instance (nevidím rozdíl oproti jakémukoliv normálnímu zdokomentovanému zdrojáku)

Mno jedna z výhod Jekkylu měla být v tom, že veškerý obsah je v git repo, to znamená není nutné řešit zálohování (každý klon repozitáře je zároveň záloha), případně databázi. Pokud vytvoříme jednoduchý CMS postavený na normálním frameworku (např. Rails, Nette), typicky se budou data ukládat stejně do databáze. Samozřejmě to můžeme udělat i tak, že se data budou psát v markdownu a nahrávat přes git, ale v tom případě by asi bylo na místě oddělit repozitář s daty od repozitáře s aplikací. Kromě toho nám zůstane

- náročný způsob správy obsahu

[Jakub.Michalek]

Výhoda jekyllu je snadná dávková zpracovatelnost obsahu (přepisování souborů obsahující regulérní výraz).

[Ondrej.Profant]

Výhoda jekyllu je snadná dávková zpracovatelnost obsahu (přepisování souborů obsahující regulérní výraz).

Výhoda oproti čemu?