Projekt

Obecné

Profil

Setkání TO k budoucnosti webů

řešili jsme, jaké jsou aktuální a výhledové potřeby, a jejich možná řešení.
Přidáno uživatelem Martin Rejman před 22 dnů

Přitomní:

Martin Rejman Jitka Novotná Filip Vařecha Jan Suchánek Andrej Ramašeuski Ondřej Profant

Plán:

  • uložiště (CDN)
  • people na keycloak

    • profilové fotografie
    • texty profilů jednotlivých uživatelů (případně i dle jejich rolí - zastupitel, člen, poslanec)
  • jak zvýšit rychlost buildu?

    • dlouho trvá načtení úvodní homepage webu pirati.cz
    • lze testovat pomocí Google Lighthouse, Google Speed Tools (https://developers.google.com/speed/ ještě možnost nastavit si vlastní úpravu NGINX)
  • zavést systém modulů (pro javascript)

    • rozdělit JS pro aplikace na jednotlivé ucelené funkcionality tak, abychom mohli na webech vkládat pouze určité části, nikoliv nahrávat vše v jednom souboru
  • co vše ještě přidat do jekyll-theme-pirati ?

  • jak/kdy na thema převést na pirati.cz

  • nasazování webu

  • microsites

  • kdy / jak / jestli dělat větši redisign webu, o kterém mluvili grafici?

  • pojmenávání gitových repozitářů a url + přesměrovaní

  • tagování článků, třídění informací, sdílení informací mezi weby a jejich emailové rozesílání

Zápis:

  • SEO:
    Filip napiše 2 věty jak na webmastertool do USAGE na jekyll-theme-pirati

    • jak používat Wembastertool společně s novým tématem
  • Ondra: Flicker už máme koupený

  • Martin: nová koncepce TO, máme více peněz peníze se rozdělují podle toho kdo co dělal, každý měsíc se rozdělí 30k,

  • Jitka: chce hackaton

  • Andrej: chce schze

  • Filip: hackaton musí mít téma

  • uložiště ( cdn.pirati.cz )

  • co máme: static

  • potřebujeme:

    • řídit přístup pro nahrávání obsahu (kdo co kam smí nahrávat)
    • všechen obsah je veřejný pro čtení
    • má řešit on-download resize obrázků podle parametrů, varianty obrázků jsou uloženy na CDN
    • jak hlídat, jaký obsah je kde použit - pro případné odstraňování starého obsahu
  • v jekyllu budou placeholdery na obrázky - aby samotný mediální obsah mohl být na CDN, ale web se nerozpadl po grafické stránce

  • všechny fotky přijdou do CDN

  • pokud nebudeme mít vlastní řešení, je třeba určit postup migrace dat

  • ke zvážení (dostupná komerční řešení):

    https://cloudinary.com, imho bychom potřebovali verzi za 5 000 Kč / měsíčně

    https://www.cdn77.com, tady mi to vychází na nějakých 2 500 Kč / měsíčně

    poznámka: ještě to, ale sníží trafik

  • people na keycloak (profilová data uživatelů)

    • profilové fotografie
    • texty profilů
    • další možná strukturovaná data
    • možnost míc více variant uložených dat podle role (pirát, poslanec, zastupitel, ... )
    • výhledově budou tato data dostupná pomocí graph-api (očekává se vytvoření náhrady)
    • je třeba řešit propagaci aktualizaci informací na webech z centrální databáze
    • možná vyřeší pravidelný rebuild 1x měsíčně všeho
    • sloužilo by i jako kontrola toho, že všechny weby jsou v pořádku a správné

      • jekyll plugin podle vzoru redirectfrom
      • asi půjde vyřešit pomocí "vzdálených kolekcí" v jekyllu
        • fallback solution je javascript + řešit seo
    • google možná už umí spouštět JavaScript

      • lide.pirati.cz zobrazí všechny profily
  • jak zvýšit rychlost buildu ?

    • hlavní problém je počet a velikost fotografií
    • počet článků by neměl být problém
    • měla by pomoci nová verze jekyllu
    • asi není snadné rozdělit buildování webu
    • zkusíme "include" cache pro buildování
  • rychlost načítání webu

    • dlouho trvá načtení úvodní homepage webu pirati.cz
    • lze testovat pomocí Google Lighthouse, Google Speed Tools (https://developers.google.com/speed/
    • ještě možnost nastavit si vlastní úpravu NGINX https://developers.google.com/speed/pagespeed/module/)

      • Aktivujte kompresi v NGINX - Komprimací zdrojů pomocí nástroje Gzip nebo Deflate - Výrazně to zrychlí web i indexovatelnost google.com a využít načítání do mezipaměti prohlížeče v záhlavích protokolu HTTP statických zdrojů
    • jaká je maximální velikost souboru, který dáváte na github?

    • zkusíme zapnout kompresi obsahu

  • zavést systém modulů

    • Javascript
    • rozdělit JS pro aplikace na jednotlivé ucelené funkcionality tak, abychom mohli na webech vkládat pouze určité části, nikoliv nahrávat vše v jednom souboru
    • mapa záměrů
    • custom kalendář
    • loadovat pomocí Jekyll direktiv
    • chceme řešit pomocí WebPack-u
    • na to navázat Jekyll build dle parametrů v hlavičce builovaného souboru
    • Jekyll
    • co vše ještě přidat do jekyll-theme-pirati - jak rozlišit to, co je lokální, a co "celostátní"
    • např. rozcestník na místní sdružení (má to pardubicky.pirati.cz)
    • dokumentovat možnosti stávajícího stavu
    • rozdělit stávající README na podstránky na Github-Wiki
  • search na jekyll-theme-pirati

    • centralni elastic search
    • stávající hledání bude nahrazeno pomocí Elastic Search a centrální hledací služby
    • jednotlivé weby pushují svoje vlastní záznamy v indexovatelné formě při buildu
    • za účelem úspory indexování se udělá manifest se seznamem změn, pouze ty se pak nahrávají dále
  • jak/kdy na thema převést na pirati.cz

    • fáze 1: pouze přesunutí na nový build systém paralelně
    • fáze 2: postupná refaktorizace kódu
    • začít s novým repozitářem, nasadí se nové téma
    • přesunout pouze články, profily lidí a nějak namapovat program
    • vyčlenit velké samostatné celky:
    • snemovna
    • senat
    • fáze 3 (společně s Mediálním odborem, odborná konzultace):
    • konzultace s MO
    • zpracování koncepce webu
    • UX analýza + informační architektura
    • určení SEO strategie
    • redesign titulní strany a obsahu
    • fáze 4 (společně s Mediálním odborem, odborná konzultace):
    • testování a nasazení
    • rozšiření poznatků do thema
  • nasazování webu

    • preview
    • přidat na weby HTTP 404
    • TODO: jednodenní rebuild článků kvůli
  • microsites

    • vznikne CSS toolkit
    • bez foundation, bootstrap ...
    • asi neni potreba ani kompatibility CSS layer
    • na počátku se aplikuje pouze na mikrosites, následně i do příspěvků na webu
    • TODO: měl by vzniknou standardní katalog prvků
    • interně se stanoví, které prohlížeče podporujeme
    • pro staré prohlížeče nahrajeme compatibility layer, případně zobrazíme varování
    • (odpovídající snippet se dá
  • pojmenávání gitových repozitářů a url + přesměrovaní

    • necháváme to plně na místních sdružení
    • kraje končí na -ský,-cký (nikoliv např. liberecko)
  • tagování článků, třídění informací, sdílení informací mezi weby a jejich emailové rozesílání, vyhledávání informací

    • dát doporučený seznam tagů, ideálně vynucovat min. dva tagy - téma a území
    • navázat na Redmine ... úkoly s programovými cíli
    • TODO: dodat základní strukturu pro Redmin pro radnice a zastupitelstva
    • zpracovávat setkání a zápisy, následně je dávat do EstudentlasticSearch a zpřístupňovat členům (obdobně i pro další sdělení ... )
    • TODO : dopracovat propojení na tagy
    • schází platforma na sdílení zkušeností typu StackOverflow
    • máme askbot
    • bude to potřebovat lidi, kteří se starají o to, aby tam byly relevantní odpovědi
    • i informace typu "Jak něco .... "
    • je třeba i otázky a odpovědi ověřovat, pokud by tyto odpovědi měly nebo mohly vypadat "závazně" - aby to někdo

    případně nepovažoval za garantovanou a směrodatnou odpověď

    • měly by to být spíše organizační otázky
  • editor článků

  • servery - rozdělení místa na disku

    • máme celkem 8TB diskového prostoru pro data, máme RAID1, takže pouze 4 TB
    • pokud budou všechna data replikovaná, máme pouze 2TB dat.
    • výsledek: 0.5TB v RAID1, 1.5TB mirrorovanych pouze pres sit.

Komentáře