Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - noef

Stran: 1 ... 14 15 [16] 17 18 ... 60
226
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 06. 11. 2016, 17:32:28 »
Po tom vyroku, ze Vim toho umi vic, nez bezne IDE, jsem se rozmyslel nad tim, jestli to teda pro tu Javu nebo Scalu nezkusim, abych se treba neco priucil, co bych mohl vyvojarum z IDEA navrhnout jako novou feature. Kdyz ale ctu, jak ve Vimu "funguje" trivialni refaktorovani jmena metody... Je tedy krajne nepravdepodobne, ze Vim bude umet neco navic, kdyz vec, co IDE zvladaji roky (desetileti?) nevzlada.

K Haskellu a "pretezovani" - myslim, ze je to s Javou nesrovnatelne. V Jave bezne menite metodou stav objektu, metoda ma nejmene nekolik radku (dano rozvlacnou syntaxi), vetsinou spise desitky. Naopak v Haskellu IMO mivate spise velmi kratke funkce (na pocet radku), ve kterych se ale deje hodne (vysoka mira obstrakce, strucna syntaxe a operatory ze symbolu). Mate jasne dany vstup a vystup funkce. Dalsi vec je, ze v Haskellu snad pretezovani ani neni - tam nelze definovat fkci, ktera ma jiny typ, nez predhozi definice:

Kód: [Vybrat]
a :: Int -> Int
a = (+) 1

a :: Int -> Int -> Int
a = (+)

main = do
  print $ a 1
  print $ a 1 2

Kód: [Vybrat]
[1 of 1] Compiling Main             ( double_fn.hs, double_fn.o )

double_fn.hs:4:1:
    Duplicate type signatures for ‘a’
    at double_fn.hs:1:1
       double_fn.hs:4:1

double_fn.hs:5:1:
    Multiple declarations of ‘a’
    Declared at: double_fn.hs:2:1
                 double_fn.hs:5:1

Take muzete pouzit guardy. To, cemu rikate "pretezovani" v Haskellu, spise slouzi jako ify v Jave - podle podoby parametru se vybere vetev, ktera se ma pouzit. Stezujete si snad u ifu, ze zalezi na pozici, kde je v kodu umisten?

PS: Jsem v Haskellu zelenac, tak snad nejsem uplne mimo :D.

227
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 05. 11. 2016, 17:10:53 »
... I pro rozhraní přece platí pravidlo, že ho smíš rozšířit, ale nesmíš ho změnit. ...

citation needed

Proc bych jako svoje rozhrani v ramci modulu nemohl zmenit? IMO neni zase tak vzacne, ze i v ramci projektu se meni rozhrani. U vystavenych rozhrani to je asi spise vyjmecne, nicmene kdyz se to stane, tak radeji stravim 2s automatickym prejmenovavanim nez nekolik dnu manualnim.

Navic to prece musi vest k hroznemu kodu, kdyz problemy neopravujete, ale nabalujete nove metory (typu. add a addEx).

228
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 05. 11. 2016, 15:44:10 »
Práce s Vimem nikdy nemůže být rychlejší, protože IDE se ovládá jen klávesnicí + má hromadu věcí navíc. VIM je super pro začátečníky a adminy.

Vim se také ovládá jen klávesnicí a proti IDE má hromadu věcí navíc.

:o To se mi moc nezda, muzete to necim podlozit? Napr. vyvoj v Jave v IntelliJ IDEA vs ve Vimu - co presne ten Vim umi navic? Posledne, kdyz jsem popsal nejake zakladni refaktorovani, typu prejmenovani metody na vsech mistech pouziti (klidne ikdyz je pojmenovana stejne jako jina metoda v jinem rozhrani/tride), tak jsem se dozvedel, ze to Vim neumi a ze je stejne rychlejsi to provest rucne ;D.

229
Vývoj / Re:Obfuscator pro javascript
« kdy: 04. 11. 2016, 16:59:43 »
To, o cem pisu neni trapne "desifruj -> eval". Ale zjisti od servru (po overeni napr. auth tokenu a "unikatniho" fingerprintu prohlizece) unikatni klic a dalsi casti kodu, ktere nasledne vzdy chvili vykonavas a pak desifrujes dalsi cast kodu ve VM, nebo dostanes dalsi klic nebo kod.

Jenze browser nic jineho nez JS neumi spustit. I kdyz si tam implementujes proprietarni jazyk ci celou VM tak se to musi decodnout do JS a ten spustit. A to neschovas, jenom udelas zlozitejsi. V podstate tve definici vyhovuje treba takovej React ale na konci je porad plain JS, ktrery se spousti.

To ja nikdy nepopiral. Stejne tak SecuRom nebo Denuvo je porad spousteny na realnem procesoru, kde snad take lze trackovat instrukce, a presto je to ucinna ochrana (relativne receno - nebyla prolomena mesice, coz na pomery hernich ochran je neuveritelne dobre skore). Jde o to, ze tam pridavate dalsi vrstvu - sebemodifikujici se dynamicky spousteny kod, ktery staticky nemuzete cely ziskat - jednoduse proto, protoze nemate vsechny casti a ruzne casti jsou sifrovany ruznymi klici (generovani casti i klice se ziskavaji ze servru kdyz je potreba, nelze si vyzadat vsechny; navic dane casti funguji jen pro dany klic prohlizece, jinde spusti pasti).

Mate pravdu, splnuje to asi i ten React (detailne neznam) i Angular. Asi stejne tak, jako ze sifrovaci algoritmus je Caesarova sifra. Rozdil je v tom, ze v pripade Angular aplikace si muzete hromadne stahnout vsechny sablony (casto jsou predkompilovane primo v js) a casto je cela aplikace jeden bundle, takze mate cely zdrojak v cistem JS, staci najit funckci, ktera dela vypocet. V pripade te hypoteticke ochrany mate kusy sifrovaneho kodu, ktery je vam na nic, protoze potrebujete vsechny kusy a klice pro vsechny kusy (rozkouskovani i klice mohou byt dynamicke, takze pokud vam v polovine grabovani server zasle nove vm, tak jste v haji a muzete zacit od znova). Navic kdyz je to sebemodifikujici se, tak musite i simulovat ten VM a prolomit generovani toho "unikatniho" klice pro prohlizec, jinak to bude nahodne davat spatne vysledky na jinych prohlizecich/strojich. Je rozdil dekodovat par kilobajtu minifikovaneho JS, kde vim, ze tam nekde asi bude ta "zlata" funkce versus dekodovat par megabajtu kodu VM, kde casti jsou obsluzne veci VM, casti samotny zasifrovany kod vevnitr a dalsi casti data toho VM (pripadne oboje zaraz). Pokud jsou napr. nektere veci pouzivane ve vice formach (rozsiforvane i zasifrovane), tak napsat nastroj, ktery to automaticky deobfuskuje nebude trivialni snapshot ast v prohlizeci. Bude se muset celkem dlouho sbirat klice a kusy kodu, zjistovat, jak je davat dohromady (vm muze server zaslat nove, ktere nebude mit stejnou podobu provadeneho VM kodu, klidne muze byt ten jeden algoritmus implementovany nekolika zpusoby, coz razantne prodlouzi prolamovani). Dalsi vec je, ze musite take identifikovat vsechny trapy (coz je vetsinou nerealne) nebo rozlousknout, jak se generuje ten prohlizecovy klic.

Chapu, proc nikdo takoveto slozite ochrany v prohlizeci neresi. Proc to resit na strane klienta, kdyz to bude neuveritelne drahe, pomale (na mobilech nepouzitelne) a nikdy ne 100%, kdyz to lze trivialne resit na strane servru za zlomek ceny a bude to rychle jako blesk.

Jako uznavam, ze je zajimave se nad tim zamyslet, ale zodpovezeno to bylo uz na zacatku vlakna.
@OP presun ten vypocet na server a neres kraviny.

230
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 04. 11. 2016, 16:23:11 »
Presne tak. I treba to nenavidene (a z hlediska jazyka a knihovny objektivne spatne) PHP muze dobre poslouzit treba na maly e-shop s woocommerce, ktery je nekde na hostingu za par supu. Delat toto napr. v Jave, tak by jen hosting vysel nekolika nasobne draz.

231
Vývoj / Re:Obfuscator pro javascript
« kdy: 04. 11. 2016, 16:09:37 »
Jsem prave mel na mysli neco pokrocilejsiho, kde je napr. primo v JavaScriptu naimplementovana vlastni virtualni masina s vlastnim siforvanym kodem, ktery se pri provadeni modifikuje a presifrovava a zadne spusteni neni stejne, prestoze vysledek to vyplivne stejny.

To by vyzadovalo "zamcenou" cast pameti co v browseru neni. Proste i dynamicky generovany JS kod se musi nasledne executnout a ty mas moznost videt co se prave provadi i pamet vsech objektu. Proste jakakoli obfuskace kodu nic neresi, protoze ty ho mas moznost videt jak bezi. I kdyby to cele bylo zasifrovane 4kilovym blowfishem tak se to nekde musi desifrovat a neschovas to.

A pri spusteni hry na pc snad muzes jadru nebo jinym ovladacum efektivne zakazat pristup do sve pameti? (Tak nizko OS jsem nikdy nedelal, takze fakt netusim.)

To, o cem pisu neni trapne "desifruj -> eval". Ale zjisti od servru (po overeni napr. auth tokenu a "unikatniho" fingerprintu prohlizece) unikatni klic a dalsi casti kodu, ktere nasledne vzdy chvili vykonavas a pak desifrujes dalsi cast kodu ve VM, nebo dostanes dalsi klic nebo kod. Nic nelze 100% zabezpecit, ale treba ten SecuRom nebo Denuvo to muze zatracene zpomalit (napr. mesice po vyjiti ocekavane AAA hry necracknute) a pokud je to unikatni ochrana, tak si kazdy dvakrat rozmysli, jestli se to bude snazit prolamovat, kdyz by bylo levnejsi si treba 10x zaplatit predplatne a napsat bota.

Ale stejne jako ve vlaknu o zabezpecovani mapy v JS - osobne silne pochybuju, ze OP ma tak ceny algoritmus, ktery musi bezet na klientovi a zaroven se vyplati jej takto chranit.

232
Vývoj / Re:Obfuscator pro javascript
« kdy: 04. 11. 2016, 14:22:30 »
V (de)obfuscaci se moc nevyznam, ale neni neco podobneho pro JS, jako v oblasti her? Tj. ze ochrana si v podstate provozuje vlastni VM, ktere se nahodne modifikuje a ze servru ziskava kusy kodu, ktery desifruje, zakomponuje a pousti na tom virtualnim stroji?

Vetsinou se jenom vygeneruji absurdni jmena promennych, neco se prehazi, neco inlinuje, pokazi se formatovani...

Jn, jasne. To je bezna minifikace, ktera se pouziva tedy spise kvuli rychlosti. To se snad ani neda povazovat za "obfuskaci", kdyz kazdy deobfuscator/beatufier nebo i hloupy dev tool v Chrome to zvladne celkem solidne narovnat do citelne podoby. Je to skoro jako kompilace zdrojaku v C++ ci Jave, kterou take nenazyvame obfuskaci, prestoze technicky asi take je.

Jsem prave mel na mysli neco pokrocilejsiho, kde je napr. primo v JavaScriptu naimplementovana vlastni virtualni masina s vlastnim siforvanym kodem, ktery se pri provadeni modifikuje a presifrovava a zadne spusteni neni stejne, prestoze vysledek to vyplivne stejny. V tom Denuvu se navic nejak pouziva unikatni desifrovaci klic generavoany podle seriovych cisel komponent v pc (klic je vytvoreny serverem) a zdrojak hry je prosety pastmi, kdy hra sice nespadne, ale zamerne se nejak lehce polame (napr. nedoplnovani hp, zamceni dveri, 5x vetsi damage od nepratel, pridani pasti, ktera instatne hrace zabije atp.).

233
Vývoj / Re:Obfuscator pro javascript
« kdy: 04. 11. 2016, 13:41:30 »
V (de)obfuscaci se moc nevyznam, ale neni neco podobneho pro JS, jako v oblasti her? Tj. ze ochrana si v podstate provozuje vlastni VM, ktere se nahodne modifikuje a ze servru ziskava kusy kodu, ktery desifruje, zakomponuje a pousti na tom virtualnim stroji?

234
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 04. 11. 2016, 13:36:21 »
Rozdíl je v tom, že na to nepotřebujete žádné speciální IDE, což bylo to, na co jste reagoval.

To uricte nepotrebujete ani na ty Visual srandy od Mrkvosrotu, taky to "jde" urcite napsat. Stejne tak tu ANTLR gramatiku muzete napsat rucne textove bez pomoci GUI nebo jak pisete, pouzit uplne jiny nastroj. Ja nepsal, ze neexistuje jina cesta, jen ze ta zatracovana cesta muze byt klidne lepsi/nejlepsi, rychlejsi na implementaci i beh, nez si to placat na vlastnim pisecku od 0 v poznamkovem bloku.

Naopak me prijde ve vetsine pripadu zpatecnicke vyzadovat po programatorovi (nebo i jen glorifikovat) pouzivani objektivne podprumernych nastroju jen proto, protoze "je programator" a stravit tim 10x nebo i vice casu jen proto, ze "je programator" :D. Snad dostavame zaplaceno za funkcionalitu a efektivitu, ne za to, ze "jsme programatori"...

No proti IDE jsou spíš mladí, starší jsou odkojeni Windows a tedy IDE. Mladí začínali s linuxem a pro ně přitažlivou magií bashe :-)))

To snad ne ;D. Ze bych byl tam moc stary? :(

Ale jinak - na FITu si nevybavuju moc studentu, kteri by (dobrovolne) pouzivali Tuxe a textove IDE. Po pravde si z desitek lidi, co jsem s nima delal na projktech, vybavuju presne jednodho linuxaka ve vimu, zbytek Wokna (v te dobe vcetne me).

235
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 04. 11. 2016, 13:02:07 »
Proč jste nepoužil Bison nebo Boost Spirit, kterému předhodíte gramatiku a parser to vygeneruje automaticky během buildu?

To uz snad vyjde nastejno, ne? Nekde si neco naklikam, pripadne upravim recept, a ono to nekdy vyplivne nejaky kod, ktery nemusi byt esteticky pirtazlivy, ale parser je "napsany" za hodinku, ve vetsine pripadu je podstatne rychlejsi nez custom a je plne funkcni (nejsou ani treba testy, nebo jen velmi malo ve srovnani s vlastnim parserem).

PS: Nezivim se Javou ani psanim parseru, to byl jen priklad jak "dnesni hloupy programator" zvladne ukol za zlomek casu a lepe, nez "chytry poradny programator" dedek, co si to pise na kolene :).

236
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 04. 11. 2016, 12:39:47 »
...

Většina věci, které Vám generuje IDE je děláno tak aby je program mohl vytvořit, to jestli jsou 100% dobře, maximálně optimalizovaný jak rychlost, tak velikost je věc vedlejší, to je právě to o čem mluvím. Dnešní doba je fajn, každý mámě X GB a tak velikost programu je OK a nikdo ji neřeší, ale nepřijde Vám lepší napsat program, který je přehlednější, čitelnější, méně náročnější a menši než to, co by jste vygeneroval/vyklikal z IDE?

Treba v pripade tech generovanych parseru - ne, neprijde me to lepsi. V ramci bakalarky jsem si parser psal a kdyz jsem pak srovnal, jak trivialne, prehledne a i vykoneji to generaval tusim ten ANTLR, tak jsem byl zatracene prekvapeny. V ramci skoly budiz, napsat si neprilis vykonny, hure udrzovatelny parser s ne prilis chytrymi chybovymi hlaskami neni zase takovy problem. Ale ve vsem volnem case, pokud neni cilem naucit se psat parser? Nebo nedejboze v praci, kde by me za takove plytvani mohli i vyhodit? Citelnejsi to bude akorat pro autora custom parseru, ale pro dalsi vyvojare bude popis pro ANTLR urcite prehlednejsi. Custom reseni neni ani mene narocne a mensi netusim. Ale osobne resit par KB nebo MB, kdyz knihovny muzou mit desitky az stovky MB? Bikeshedding, nic jineho.

Priklad jednoduche gramatiky:
Kód: [Vybrat]
grammar Expr;		
prog: (expr NEWLINE)* ;
expr: expr ('*'|'/') expr
    | expr ('+'|'-') expr
    | INT
    | '(' expr ')'
    ;
NEWLINE : [\r\n]+ ;
INT     : [0-9]+ ;
Muzete si to zobrazit v klikatku, mit to zaintegrovane v IDE. Napr. takto -> http://www.antlr.org/images/antlrdt-v4-plugin.png. Prepsat ten (asi jakykoliv) parser do kodu zabere urcite podstatne vice mista, nez ten predpis pro vygenerovani. Casove bude rucny parser o nekolid radu drazsi - precejen zkonvertovat gramatiku z dokumentace na predpi pro generator muze byt na hodinku, nebo den, vypiplat si vlastni parser se bude spise pocitat na tydny. Navic ten predpis pro vygenerovani je velmi intuitivni, na rozdil od implementace custom parseru, kde pokud nedodrzujete nejake predem stanovene konvence, tak budete dlouho bloudit, nez ho cely pochopite (myslim samozrejme netrivialni pripady).

Tak jako tak IDE musite stanovit strukturu, ve které chcete projekt vést, kde co bude uležené, jak se to má tahat (nemusíte, ale pokud si chcete být 100% jistý, stejně to uděláte) takže to, že mi to stáhne nějakou pro mě nelogickou strukturu projektu je prostě špatně.

Pokud sahate po spatnem seedu, je to vas problem. V pripade JavaScript sveta napr. pro Angular jsou guideliny pro strukturu projektu, pojmenovavani atp. Pokud chcete vynalezat po desate kolo... Pokud jde o one-man-show, write-only projekt, tak prosim, ale takove projekty nejsou v komercnim svete prilis bezne. Tam se naopak hezky postupuje podle doporuceni a best practises, pouzivaji se frameworky, ktere nabadaji, jak kod strukturovat a velmi ulehcuji orientaci v kodu, o to vic, kdyz prijdete k hotovemu.

Našeptávání, refaktoring, autocomplete mě osobně přijde, jako kdyby programátor nevěděl kde co v projektu má, jak se k tomu dostat, jak daný kód dokončit, nebo třeba našeptávání funkci (jak ta funkce vlastně má vypadat? Aha našeptávání mě poradí i včetně zápisu atd). K čemu tedy se člověk musí učit programovat, když tu je chytré IDE a dá se v něm vše naklapat? Nemusím si nic pamatovat, nemusím mít přehled v projektu, nemusím nic znát, IDE to vlatsně umí za mě. Pak mě napadá otázka, k čemu je takový programátor, který když posadíte před konzoli na webovém serveru, kde je spadlá webová aplikace aby jí opravil na Vás bude koukat a ptát se, jaké IDE má použít a kde ho najít?

Na Vaší poslední otázku si myslím je odpověd výše pochopitelná

Vy se zivite vyvojem? Takhle to muze fungovat u maleho skriptu na par stovek radku, tam asi i jeste udrzite cely mentalni model v hlave. Ale jak to jde do tisicu radku, tak budete vetsi a vetsi problemy a to i kdyz jste autorem toho kodu. V realnych pripadech je to ale vyjimecny stav, vetsinou se dela v tymu a cely projekt ma mnoho autoru. Ne, programator si nema pamatovat kompletni strukturu vsech modulu v projektu, parametry a chovani kazde funkce, vsechny cleny vsech trid atp. Nejen, ze je to v realnem svete nemozne, je to i silne neprakticke. Proc si vyhrazovat kazdy den hodiny na memorovani kodu, kdyz to v par vterinach zvladne IDE a me staci jen velmi hruby prehled o projektu?

K posledni casti - auto si asi nebudete opravovat lzickou, tak proc ocekavate od programatora, ze bude pracovat s nevhodnym nastrojem?

PS: Za takoveto vynalezani kola by me pravdepodobne vyhodili. To si nedovedu predstavit, ze bych dosel po tydnu prace za sefem a rekl, ze jsem se cely tyden placal s komponentou, kterou jsem mohl vzit z opensource knihovny a zaintegrovat za pul hodiny s lepsim vysledkem a usetrenym tydnem prace. :o

237
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 04. 11. 2016, 10:42:34 »
Nevidím důvod, proč bych měl nějaký kód opakovat pomocí nějakého klikátka. DRY.
To sa lahko povie, ale zarovnavat pixely v nejakom xml alebo v kode, pripadne pisat si rucne parser nie je ziadna zabava. Tak pouzijem Eclipse a jeho modelling tools, kde si naklikam co chcem a to vygeneruje dost hnusny kod, ktory sa opakuje. To neopakujem ja, to robi za mna IDE.

Ako zariadis DRY? Mas vlastny Eclipse?

Ne. Mám Vim. Ten mi hnusný kód nedělá.

Ten vam nedela zadny kod ;D. Takze misto par kliknuti a "hnusneho kodu", ktery stejne nikdo nema udrzovat, protoze se snad ma udrzovat predpis pro to vygenerovani, ve Vimu musite hodiny zkoumat, jak asi napr. ten naklikany parser napsat sam a pak k nemu napsat jeste kotel testu. Navic napr. ty generovane parsery byvaji mnohem rychlejsi, protoze jsou podstatne lepe optimalizovane, prestoze to vypada jako kod od prasete (tusim ANTLR to byl - switch na stovky radku atp.).

Libí se mi dnešní doba programátorska + IDE ...

Programátor bez IDE nevytvoří projekt.

A když ho vytvoří v IDE (krásně dříve řečeno "nakliká") má hnusný kód ... (logicky)

To je okecáváno tím, že to generuje IDE, ale přitom 80% programátorů ani neví, co to to IDE vygenrovalo natož co to dělá a jak by to měli udělat bez IDE.

Líbí se mi jak Kit razí "svůj styl" jelikož osobně to mám stejně ;-)

Nevim no, pokud nektere formaty souboru jsou delane tak, aby je generoval program, tak nevidim moc pointu v tom to psat rucne (nejsem si moc jisty, ale namaji to tak prave M$ veci?).

Osobne kdyz vyvijim ve Scale, tak si "zakladam" projekt sam (napisu si SBT build file). Ale zaroven pouzivam IDE, protoze bez toho je vyvoj velmi pomaly (od zakladnich veci jako navigace a importy az po refaktoring a chytre - type-aware - naseptavani).

Napr. v JavaScriptu mne ale prijde jako ztrata casu zacinat od piky. Vsak se doporucuje najit si seed nebo alespon buildfile ci konfiguraci, ktera nejvice sedi projektu a ten pouze jemne upravit. Ono psat si svuj gulpfile i pro celkem bezny projekt (ES6, Sass, Angular) je celkem na dlouho (den, asi spis i dny - musi se resit bundlovani, kompilovani sablon do JS, kompilovani zavislosti [bower/npm], minifikace, ruzne kontexty [napr. local BE, mock API a produkce] a pripadne i pokrocilejsi veci [proxy s nejakym mapovanim, generovani zdrojaku podle parametru tasku atp.]). Nebo snad kdyz potrebujete sifrovani, tak si taky implementujete hranate polamane kolo radeji nez pouzit roky overene, poradne otestovane v produkci, opravdu kulate a otevrene kolo?

238
Vývoj / Re:Angular2 vs React
« kdy: 03. 11. 2016, 17:51:25 »
Pokud vim, tak Angular presel na semver a verze 3 bude znamenat jen dalsi update 2ky s nejakymi breaking changes, zadny prepis od piky jako 2. Takoveto updaty se dely s Angularem 1 bezne, akorat se kvuli tomu nezvedala hlavni verze.

Ke komponente a sablone - mozna to neni presne, ale v Angularu 2 je Component dekorator (anotace) tridy kontroleru (component =?= controller) a sablona je retezec nebo html soubor, coz snad odpovida view. Takze v ramci nejake knihovny to muze znamenat neco jineho.

S Angular 2 velmi pomalu zacinam, ale pokud vim, tak ma server-side rendering a jako dalsi optimalizaci i predkompilovani sablon (AOT).

Take by mne zajimalo, co je spatneho na pouzivani Angularu a Reduxu? Jednu mensi aplikaci jsem v ng 1 + Redux psal a prislo me to dobre - diky loggeru stavu se velmi pohodlne debugovalo ve srovnani s ng 1 bez Reduxu.

Ptam se, protoze dalsi projekt mame delat v Angularu 2 a ngrx/store (vychazi z Reduxu), tak by me zajimalo, co je na tom tak sileneho.

Jinak me prijde, ze Angular 2 vs React zustava klasicke "vse pripravene v jednom" vs. "poskladej si sam" a k Angularu 2 oproti 1 jeste pribyla dobra podpora TypeScriptu, ktera pro nekoho (treba me) je velke plus. Cetl jsem, ze pro zacatecnika muze byt Angular lepsi, protoze jasne udava mantinely a vse ma clovek pripravene (ale osobne srovnat s Reactem nemuzu, zkusenosti s nim nemam).

239
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 03. 11. 2016, 16:54:26 »
Vlakno mne pripomnelo tento trefny citat :):

Citace
There are only two hard things in Computer Science: cache invalidation and naming things.
- Phil Karlton

240
Vývoj / Re:Pravidla pro pojmenování proměnných
« kdy: 03. 11. 2016, 12:39:15 »
BTW nektere jazyky umoznuji i UTF8 identifikatory, fuj.

Překladem do angličtiny se ten název otestuje, přece jen je lepší pojmenovat třídu Worker, než Dělník, či Zpracovatel.

Co prosím? Jak se ten název otestuje pouhým překladem do angličtiny? Proč je lepší název Worker než Dělník či Zpracovatel?

Protoze mu bude rozumnet v podstate kazdy vyvojar na svete? Ja nerustinar proste v nazvu tridy Разнорабочий nevidim toho ceskeho Dělníka. Jako jo, pokud si neco matlate v jednom cloveku a ani se to neplanuje udrzovat, tak pak jo. Ale vzhledem k tomu, jak casto se meni zadani a pozadavky zakaznika, tak ani tomu bych neveril. Mozna kdybych to mel vyslovne ve smlouve, ale i tak nevidim zadne klady v pouzivani ceskych/českých identifikatoru. Pokud neni zcela jasne, jaky je preklad, tak se ma tym domluvit na slovnicku a toho se striktne drzet.

Stran: 1 ... 14 15 [16] 17 18 ... 60