Před nějakým časem jsme opět uspořádali naši dnes už tradiční akci – MoroHackathon. Tentokrát jsme se na tuto noční bojovku sešli již potřetí. Hackathon je akce, která se pořádá 2x za rok s cílem během jednoho dne/večera vytvořit chytrá řešení a posunout tak lidstvo zase o kousek dál. Jde o to, že se několik týdnů před samotným hackathonem začnou sbírat témata. Každý může přijít s nápadem. Ostatní si pak vybírají téma, které se jim líbí nebo se po domluvě k někomu přidají. A pak už se jde na to. Následující řádky vám vše přiblíží.

Hackaton #3 měl tyto parametry

  • začali jsme ve 12:00 v pátek a končili jsme v 9:00 v sobotu
  • sešli jsme se v Brně v našem největším meeting roomu Cinema
  • bylo o nás dobře postaráno, což dokazuje hrubý harmonogram
    • 12:00 – 13:00 – představení projektů a rozdělení do týmů podle zájmu jednotlivců
    • 15:00 – každý tým představil výsledný produkt (co bude na konci jejich snažení)
    • 18:30 – přijela večeře
    • 22:00 – přijela 2. večeře
    • 07:00 – 08:00 – snídaně
    • 09:00 – ukončení a prezentace projektů
  • koukali jsme u programování na hokej
  • občas si nějaký slabší kus odskočil se na pár hodin prospat
MoroHackathon

Na čem jsme pracovali (aneb čím jsme lidstvo chtěli obohatit)

ProfitSplitter – Nástroj pro sběr dat pro rozdělení zisku

  • Cíl: Cílem bylo dokončit ProfitSplitter tak, abychom s ním mohli letos pohodlně rozdělovat podíly na zisku – přidat funkcionalitu podporující historii jednotlivých roků, umožnit ukládat drafty, přidat statistiky pro administrátora a udělat redesign.
  • Co se podařilo: Podařilo se udělat většinu věcí na backendu – učesání kódu, API, příprava dat atd. Podařilo se připravit funkcionalitu pro draft a historii roků na frontendu, stejně jako udělat menší redesign zadávání jednotlivých odměn.
  • Co se nepodařilo: Nedokázali jsme dokončit všechny funkce hlavně kvůli tomu, že nám vše dlouho trvalo na frontendu prokopnout, nepodařilo se přemístit graf z naší interní wiki do ProfitSplitteru.
  • Co byla největší výzva: React –  limitovaná znalost Reactu a jeho zákonitostí nás hodně brzdili.

TogglSync for Jira Cloud

  • Cíl: Cílem bylo rozpracovat variantu TogglSync add-onu, tentokrát pro cloudovou verzi Jira. Hlavním úkolem bylo zmapování toho, jak to s vývojem pro cloud vlastně je a zda jsme schopni pro tuto platformu něco vyvíjet.
  • Co se podařilo: Podařilo se nám vyrobit funkční add-on, který pokrývá všechny důležité části flow od načtení záznamů z Toggl, zpracování záznamů a jejich zobrazení na screen a zápis do Jira worklogů. Dále je v aplikaci naimplementována konfigurace Toggl Tokenu na User profile obrazovce. Aplikace byla spuštěna v lokálním prostředí a úspěšně otestována v DEV instanci cloudové Jira.
  • Co se nepodařilo: Nepodařilo se nám z časových důvodů udělat okno zobrazující záznamy z Toggl tak, aby byly záznamy editovatelné. Dále jsme nestihli vyřešit „zapamatování si“ již zpracovaných záznamů v Toggl pomocí tagů.
  • Co byla největší výzva: Dokumentace k vývoji od Atlassian. Je to v podstatě stejně špatné jako dokumentace pro vývoj serverových add-onů.

TogglSync for Server – nové features

  • Cíl: Cieľom bolo pridať do nášho produktu TogglSync nové features – pravidelnú synchronizáciu worklogov na pozadí (spolu s možnosťou vypnutia funkcionality a nastavenia synch. obdobia per užívateľ a notifikačných hlášok o neúspechu a úspechu (úspešné je možné vypnúť)), úprava UI dialógu (validácie na permissions, možnosť zvoliť si custom obdobie, zoskupovať záznamy po dňoch, zobrazovať u každého dňa sumu worklogov, učesať trochu UI) a úpravu UI detailu (zobrazovať užívateľovi pri spúštaní timeru už existujúce záznamy, ktoré môže len resume)
  • Co se podařilo: Podarilo sa implementovať väčšinu features, niektoré sú production ready, niektoré ešte budú vyžadovať refactoring, napísanie testov, apod.
  • Co se nepodařilo: Nepodarilo sa nám implementovať zoskupovanie záznamov po dňoch v UI dialógu a ponúkanie existujúcich time entries v UI detail issue.
  • Co byla největší výzva: Udržať si mentálnu kapacitu pre programovanie aj po bezspánkovej noci. 

Automatizované testy pro Amethyst

  • Cíl: Cílem bylo rozjet automatizované testy pro náš produkt Amethyst a realizovat tak repetitivní scénáře.
  • Co se podařilo: Podařilo se nám prokousat se tutoriálem (Cucumber+Gherkin+Java), rozjetí struktury testů a přihlášení do testovacího prostředí Amethystu.
  • Co se nepodařilo: Po půlnoci jsme začali narážet na problémy a náročnost Javy. Nepodařilo se nám tedy zrealizovat repetitivní scénáře a „nice to have“ cíl – spouštět testy na Bamboo.
  • Co byla největší výzva: Java 

Použítí Netty a Google protocol buffers pro client – server komunikaci

  • Cíl: Navrhnout novou komunikační vrstvu pro eSF projekt založenou nad Netty a Google Protobuf. Hlavní požadavek byl vytvořit novou knihovnu pro vytváření a obsluhu rychlého, plně duplexního spojení mezi dvěma endpointy. Náš cíl jsme následně chtěli ověřit nově vzniklým performance nástrojem, který by byl schopen simulovat dostatečné zatížení a dostatečný počet připojení.
  • Co se podařilo: Celkem rychle se nám podařilo setupnout klient-server spojení pomocí gRPC knihovny, na kterém jsme chtěli začít stavět.
  • Co se nepodařilo:  Vytvořit duplexní spojení mezi endpointy. Spojení request-response nám v tuto chvíli nevyhovuje.
  • Co byla největší výzva:  Seznámení se s gRPC knihovnou, se všemi jejími možnostmi i nemožnostmi.

Kubernetes

  • Cíl: Cílem bylo mít na AWS v Kubernetes deploynutý AEVI Dashboard (2 EC2 instance, na každé 3 pody) a IDM (2 EC2 instance, na každé 2 pody).
  • Co se podařilo: Podařilo se rozběhnout celý stack na Kubernetes (ADB – TV backend, BI backend, frontend;; IDM frontend a backend). Všechny služby spolu komunikovaly a bylo možné je škálovat. Nebylo nutné nic měnit v samotných containerech, vše byla konfigurace na úrovni Kubernetes. Celý deployment máme popsaný formou Kubernetes yaml konfiguračních souborů.
  • Co se nepodařilo: Nepovedlo se vytvořit Kubernetes cluster na AWS pomocí kops, hlavně proto, že můj AWS uživatel neměl dostatečná práva. Nepovedlo se rozběhnout Ingress controller pro loadbalancing externího trafiku, protože už nezbyl čas.
  • Co byla největší výzva: Rozjetí na AWS. Z toho, co se povedlo, to bylo správné nastavení vzájemné komunikace mezi jednotlivými službami, aby vše fungovalo.

Nové featury do EasyMind

  • Cíl: Cílem bylo dokončit rozpracovanou featuru z posledního hackathonu v podobě správy Confluence stránek pomocí EasyMindu a dále prokopnout nové featury, jako je přidávání poznámek k uzlům mapy, editace mapy více lidmi nejednou nebo kopírování uzlů. Také jsme chtěli zmapovat stav a možnosti importů a exportů do jiných mind mapových nástrojů, navrhnout nový sexy vzhled a zmodernizovat dokumentaci pro naše zákazníky.
  • Co se podařilo: Správa Confluence stránek je hotová. Není to ještě production ready stav, ale po pár drobných úpravách přidámé featuru do oficiálního releasu na Atlassian Marketplace. Také jsme na dobré cestě s přidáváním poznámek k uzlům mapy a máme pěkně zpracováno porovnání exportů a importů.
  • Co se nepodařilo: Měli jsme moc ambiciozní cíle s počtem dokončených features. Tedy z plánovaných 4 – 5 jsme jednu dokončili a druhou rozpracovali. Ale máme alespoň co dělat na dalším hackatonu 
  • Co byla největší výzva: Vzpomenout si, v jakém stavu rozpracování jsme nechali správu Confluence stránek po posledním hackathonu. A také orientace v JS kódu – je ho hodně.
2

Závěrem…

Hackaton #3 je sice za námi, ale #4 se už plánuje. Už jsme začali sbírat témata, čím chceme lidstvo zase o posunout o kus dál. A tentokrát přenocujeme v Hradci.

Těšíme se, jak naše témata opět posuneme a na to, co nového se naučíme.