Monthly Archives: December 2016

RE: Malá reakcia – k mojej prednáške o TypeScript v Žiline

Všimol som si dnes na Twitteri reakciu na moju prednášku. Konkrétne tu :

https://www.juffalow.com/ine/mala-reakcia/ 

Priznám sa bez mučenia, zamrzrela ma a zarazil som sa. Prečo? V podstate obsah reakcie nieje nič iné len kritika (čo je tiež samo o sebe OK), problém je že bola bez položenej otázky prečo som urobil čo som urobil v kóde a hlavne, kritika bez overenia si faktov. A tiež kritika s implikovaním niečoho, čo autor okamžite usudzuje o mne (neviem čo je DRY atď.). Takže som si dovolil napísať túto reply. Budem tvorcovi článku rovno tykať ako je v IT bežné, verím že môžem, hoci sme sa nikdy nevideli. Možno raz pri pive, teším sa.

S čím súhlasím :

  • môj kód je do istej miery crap a vo svojej podstate som ho takto nemal odprezentovať. shame on me. keď sa teraz pozerám na kód, rovno z prvej vidím chybu ktorá ma napadla keď som “sa pozrel lepšie a vyspatý” (if 0 sa v JS evaluuje na false – https://github.com/dorey/JavaScript-Equality-Table) aj po nedávnom probléme v práci s jednou drobnosťou @ runtime.

Fixnuté zmeny sú už na githube.

  • kým nemusím použiť dependencies (tu is.js), načo ich používať, to je jasné. súhlasím. pointa bola že ukážem ako funguje “intellisense” z .d.ts per danú libku a ako veci spolu hrajú – import modulu v TS. v projekte na ktorom robím primárne túto knižnicu dosť používam. áno, nemusel by som. ale dáva mi výhodu pekného počtu checkov ktoré už za mňa niekto otestoval. koniec koncov, aj jQuery nemusím používať, ale môžem. preto existujú weby ako youmightnotneedjquery.com a je na nás, aby sme si povedali kedy áno a kedy nie – rýchlosť app vs moja pri developmente.
  • npm môže byť niekedy dole, ale to je vec ktorú vieš vyriešiť cez yarn (https://yarnpkg.com), cez vlastný npm server. to je vec, ktorú rieši x ľudí. preto by som nemal používať npm packages? žiadne? really? už kompilátor typescriptu je niečo čo musíš dať dole z npm. už on môže mať dependencies ktoré nevieš zmeniť. čo ak padnú, niekto ich removne? nebudeš používať nič z npm?
  • súhlasím, že test parametrov je opakujúci sa a mohol byť/mal byť v jednej funkcii.
  • súhlasím, že aj takéto sample projekty by mali byť kvalitné a neukazovať omladine bad practices, ale to by si potom mohol povedať, že som mal použiť interface, ten implementovať a použiť DI aby sa veci dali lepšie testovať. proste je to sample, chcel som niečo oddemovať a nikde netvrdím že môj sample je kompletný zo všetkých uhlov pohľadu. class je static a pre mnohých code smell, prečo ti nevadilo to? použil som mochu. niekto používa tape lebo mocha podľa ich pohľadu zavádza do kódu globálne premenné ako describe a it a to je v JS vcelku dosť bad practice.

S čím nesúhlasím :

  • nesúhlasím s posudzovaním ľudí spôsobom aký si to urobil. skús unavený písať kód a potom si ho pozri ráno. nebudeš spokojný, ver mi. sám so sebou. keby som použil rovnaký meter, tak ti môžem povedať, že sisi nevšimol/neuvažoval ani vo svojom kóde nad if (0)
  • nesúhlasím, že ušetrenie 1 riadku ktoré si navrhol je zlepšenie. podľa mňa nieje. každý vidí aj z môjho kódu, čo robí. keby si to celé nejak zredukoval na 1 riadok, alebo o 1/2 alebo výrazne zjednodušil if, poviem OK, tu by som OK nehovoril. ak tam vidíš speedup, tak ja nie. to je ako hádka či { patrí na začiatok riadku, alebo na koniec.
  • kopol sisi do TypeScriptu bez googlenia : Ked je uz ten TypeScript taky dobry, preco po urceni typu, musim aj tak tento typ overovat? Hmm…Na prednáške som hovoril, že TypeScript pomôže s typmi len za compile time. Nie za runtime. Takže preto ten check. Za runtime môžeš poslať do funkcie čo len chceš. Ak je JS ktorý bude konzumovať môj vygenerovaný kód mimo môjho projektu, neviem čo tam pôjde a správam sa defenzívne.

Pre všetky tieto dôvody som napísal ku samplom svoj mail. Kľudne si mohol napísať, rád by som vysvetlil. IMO tvoj blog je tak trochu diss.

Samozrejme shame on me za chyby v sample kóde ktoré sa nemuseli stať. Mrzí ma to, milé publikum.