• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    KOJAProgramovani 40+
    OMNISLASH
    OMNISLASH --- ---
    GOSHEWAN: Zvedaci stoly a fixni misto bez potreby rezervace.
    SATAI
    SATAI --- ---
    GOSHEWAN: Za mne

    - standup desk a poradna zidle (naprosty zaklad, bez ktereho proste ne-e), poradny display

    pak dlouho nic

    - poradne kafe (tim myslim vyberovka)
    - jidlo (ne nutne obed, ale pokud dostanu ve ctyri hladik, tak proste bud koncim a jdu nebo mne tam slusny sandwich a banan udrzi na dalsi hodinu, dve)
    - pivo by potesilo, ale na rozdil od kafe na nem nefunguju
    - gym... asi si dovedu predstavit, ze nemit za rohem park, vzal bych za vdek i tim
    - fotbalky, PS5... nikdy mne nenapadlo neco takoveho pouzit (kecam, jednou, jeste v Sunu)

    Jinak nejlepsi lakadlo byla Avasti kantyna (holky Doubleshotky u espresso stroje, solidni obedy, dorticek)
    GOSHEWAN
    GOSHEWAN --- ---
    offtopic

    Ti z vas, kteri alepson obcas chodi do kanclu - jake jsou podle vas TOP lakadla/perks vaseho on-site pracovniho mista? Ptaji se nas jake bychom chteli office improvements a moc me toho nenapada, tak bych se rad inspiroval (:

    Je tedy fakt, ze toho mame (imo) celkem hodne. Kdyby se chtel inspirovat nekdo jiny, tak na tohle lakaji do kanclu nas:
    - vlastni gym (profi rotopedy, veslovani, cinky, dumbell, box. pytel... vc. sprchy)
    - kafe, caj, ovocne sirupy atd. zdarma
    - jednou tydne ovoce zdarma
    - jednou za 14dni craftove pivo zdarma (ano, mame pipu)
    - lednicka s ruznymi snacky i hotovymi jidly (neplacene)
    - 2x PS5, air hockey, fotbalek, sachy

    V ramci baraku pak kolarna, sprchy, na strese sdileny gril, samozrejme parkovani, nejaka cistirna. Lokalita Pankrac, hned vedle OC, takze spousta veci dostupnych.

    Kolega navrhoval tyce na stryptiz ¯\_(ツ)_/¯ Me napadaji akorat variace na vyse uvedene (redbull lednicka, v lete zmrzlina, lepsi kafe...)
    JANFROG
    JANFROG --- ---
    Myslel spis pak sklouzava pocitu falesne jistoty ala SUCHRE. Cim vic low-level vec to je a cim vic je to knihovna (a ne aplikace) tim je to horsi.

    Tohleto, spolecne s pouckou ze nemas delat zbytecne abstrakce a featury co ted nejsou potreba a se zaklinanim se Knuthovym "premature optimization" zadelava na vrazednou kombinaci, alespon co obcas (casteji nez bych chtel) vidim.

    Takze, kdyz o tom premyslim, mi spis vadi to, jak je to "prodava" (a husti do studentu :-), vetsina knizek / prednasek na to tema to podava jako "the way" a malokdo (nikdo?) nerekne na ferovku ze to ma sve limity a kde. Na to si musi kazdy prijit sam, jenze behem toho prichazeni domrvi dost veci, nejen sobe, ale i ostatnim.

    No nic, konec filozofickeho okenka :-)
    E2E4
    E2E4 --- ---
    QWWERTY: no to je to jak jsem to myslel - ne honit se za 100%, ale aby to pokrejvalo potencialni problemy, na kterejch zalezi. jo, nekdy to neni uplne mozny a pak nema smysl delat test kterej testuje syntetickou haluz..

    v tom pripade je treba se zamyslet nad tim, zda by jinej test (cojavim, end to end test) neposlouzil stejnymu ucelu "ten vobjekt se asi zpracoval dobre, kdyz vysledek je presne takovej jako by mel bejt".

    ale:

    JARDABEREZA
    JARDABEREZA --- ---
    SATAI: Já jsem si hodně oblíbil TDD na psaní binárních parserů. Např. TIFF tu je cca od roku 1992 a žádné převratné změny se tam nedají čekat. A ta struktura a očekávání jsou pevně danné.
    KOLCON
    KOLCON --- ---
    JANFROG: TDD asi dobrý na business funkcionalitu. Vložím jabko vypadne mošt.
    QWWERTY
    QWWERTY --- ---
    E2E4: za me osobne je blby, kdyz se v ramci svate 100% coverage zamotam do mockingu
    nikdy jsem testovani poradne nedelal (nejsem dev), ale pokazde kdyz jsem se snazil psat slozitejsi testy, tak jsem skoncil s pocitem, ze bud testuju kompletne virtualni objekt, ktery se pomoci mockovanych dat snazi imitovat ten realny, ale nikdy to nebude ekvivalentni
    nebo jsem se ve vysledku ztratil v tom mocku a ztratil jistotu, ze opravdu testuju, to co bych mel .. ackoliv test prosel
    SATAI
    SATAI --- ---
    JANFROG: Ono zalezi... (panaka!)

    Kdyz to je zmena v systemu, co mu rozumim a je jasne, co se ma menit, tak TDD (nebo jeste lepe testy z venku dovnitr...) je prima nastroj, ktery mi umozni jet jak fretce. Pokud je problem z vetsi casti zkouseni a postupna iterace veeeelkou spiralou k necemu, tak testy zacit neumim a asi ani nechci.
    LARS_GUNNER
    LARS_GUNNER --- ---
    JANFROG: Jestli delas low-level, tak to asi nebude uplne idealni, protoze bottleneck celeho reseni je v tom, jak moc se muzes pri navrhu systemu rozmachnout.
    E2E4
    E2E4 --- ---
    JANFROG: tak to jsou nějaký nástroje, který se snaží naplnit cíl, možná někdy vylévají vánicku i s dítětem, protože jsou v reálným životě nemožný.. ale jde o ten princip, software psaný lidmi má chyby a nezamýšlené dopady, testování je to co pomůže, není to jen testování pro testování..

    klíčový je testovat ty důležitý věci a to co nejdřív.
    JANFROG
    JANFROG --- ---
    E2E4: Ja se teda priznam, ze TDD (test driven dev) ve sve krystalicke podobe povazuji spis za kontraproduktivni (i tu coverage). Ale mozna je to jen tim, ze jsem to nikdy nepochopil :-)
    SATAI
    SATAI --- ---
    E2E4: on unit testy nikdo jiny nez programator psat nemuze. Leda jiny programator, pokud zrovna parujete. Nebo mobujete.
    E2E4
    E2E4 --- ---
    KOLCON: moje chápání je, že současná best practices je

    1. unit testy píšou autoři
    2. integrační testy píšou autoři nebo testeři
    3. funkční testy dělají testeři/QA
    4. end to end testy dělají QA

    pak je tu test driven development, kde se testama začíná a trend dělat testy automaticky jako součást CI/CD, cokoliv co jde je dobrý mít automaticky a čím dřív tím líp.
    JARDABEREZA
    JARDABEREZA --- ---
    KOLCON: Když jsem já dělal jakýkoliv PR, tak k němu musel být i test, pokud to měnilo funkčnost. A na PR review se na to podíval člověk, který řeší QE, jestli ty testy jsou dobré a případně mi navrhl co nebo jak změnit/přidat. Jinak to prostě nepustil dál :-D
    KOLCON
    KOLCON --- ---
    ETKAR: Testy by měli psát testeři/QA, ne? Nebo aspoň scénáře.
    ETKAR
    ETKAR --- ---
    SUCHRE: a kdo psal testy? Unit test co si napíše vývojář neznamená, že sw naplňuje představu zadavatele/nebo aspoň analytika.
    ETKAR
    ETKAR --- ---
    VOY: no jo, je to open source. Ta myšlenka Wiki page která je zároveň automatickým testem zní skvěle. Faktem je že zápis některých testů je lehce kryptic.
    Nicméně pro nás to řeší dost dobře testy kdy výstup má skoro vždy stejný formát a liší se hodnotami. Hodnoty na výstupu jsou nepřekvapivě závislé na vstupech uvedených v testu.
    JANFROG
    JANFROG --- ---
    LUDWIG_: Take pekne, to jsem neznal :-( RAF Chinooks nam tu litaly nad hlavou pravidelne (i kdyz ne casto) ze zakladny v Leuchars, nez ji zavreli.
    LUDWIG_
    LUDWIG_ --- ---
    a taky tohle:

    1994 Mull of Kintyre Chinook crash - Wikipedia
    https://en.wikipedia.org/wiki/1994_Mull_of_Kintyre_Chinook_crash#FADEC_problems
    Kliknutím sem můžete změnit nastavení reklam