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 ... 18 19 [20] 21 22 ... 60
286
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 02. 10. 2016, 17:11:41 »
@dustin: Hezke shrnuti. Jak velke jsou ty monitory a jake maji rozliseni?

Co se tyce tech 3 monitoru tak teda nevim, jestli to neni uz moc. Nekde jsem videl studii, ze pri prechodu 1->2 monitory se produktivita zvysila, naopak ale pri prechodu 2->3 monitory poklesla. Podobne negativne produktivitu ovlivnila prilis velka uhlopricka (myslim >24).

287
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 02. 10. 2016, 11:29:26 »
Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?

Pokud to zhorsuje tvoji produktivitu, tak ano, je na tom neco spatne. To stejne plati pro textovy editor versus IDE - si pamatuju, ze z tebe minule vypadlo, ze vlastne ani netusis, co za refaktorovani IDE opravdu umi; pro Javu opravdu hodne: napr. zmena poradi parametru metody [vsude tam, kde se opravdu dedi, ne jen trapne pouze podle jmena], presunuti tridy mezi baliky [automaticky to upravi vsechny importy], presun members do predka/potomka [nemusi byt v jednom souboru]*. Argument, ze to nepouzivas (to jsi myslim minule napsal, ale mozna se pletu), opravdu nepouzivej, protoze to znamena, ze delas pouze na nejakych trivialitach, kde se nikdy nemeni pozadavky v prubehu vyvoje (to jsem jeste nezazil :D) a kde vysledny kod je pouze napis a zapomen, nikdy se do vysledne aplikace nebude nic pridavat/opravovat/upravovat (take jsem take nezazil). Predchozi veta navic pocita s tim, ze pises hned napoprve dokonaly kod, coz jsem opet v praxi take nikdy nevidel.

Popsal jsi jen kosmetické úpravy v kódu, které by mi na plnohodnotné refaktorování nestačily a stejně bych ho musel dělat ručně. Na to mi stačí Vim s 2GB RAM.

Problem je, ze i tyto "kosmeticke upravy" by jste delal dlouhe hodiny, ve vetsim projektu klidne dny, zatimco poradne IDE by je melo hotove za par vetrin ;D.

Pokud se mění požadavky během vývoje, tak jen dopíši chybějící třídy, případně staré vyměním za nové, ale architekturu aplikace neměním.

Nemusi se menit cela architektura, staci hloupe upravy v interfacu, prave treba ty zminene presuny parametru v metode napric vsemi implementacemi, ale i trivialni prejmenovani metody rozhrani ve vsech implementacich (ne nahrazeni textu "update" za "updateUser", protoze to pochopitelne rozbije vsechny metody v projektu pojmenovane "update", ne jen ty, ktere implementuji dane rozhrani nebo dedi).

Upripmne, cim vic pisete, tim vice mam pocit, ze se realnym vyvojem moc nezabyvate a spise delate male write-only one-man-show veci, kde to, co popisujete, asi muze fungovat.



K tematu - planuji si poridit 4k kvuli praci, myslite, ze na to os/aplikace jeste nejsou pripravene (jde mi o widle 10 tak i o tucnaka)?

Velka ramka muze byt pouzita i jako ramdisk, pokud v nejake aplikaci je ssd pomale.

Pamet 4GB je naproste minimum, i s tim se bude v Jave vyvijet nepohodlne. 2GB budou sotva stacit na OS a prohlizec. Poradne IDE si napr. cachuje vsechny objekty v projektu, takze lze rychle navigovat a vyhledavat, o cem doufam nikdo nepochybuje, ze produktivitu zvysuje - samozrejme za cenu pameti, ale to uz jsem napsal nekolikrat, ze ta investice tisicovky do 8GB se brzy vrati. Osobne doporucuji tech 16GB a vic, protoze nikdy nevite, kdy bude potreba pustit virtualku, dalsi instanci aplikaci, dalsi prohlizec, dalsi instanci IDE se souvisejicim projektem atp.

288
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 02. 10. 2016, 07:13:16 »
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).

Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.

Ehm, co je to za logiku? Podle tohoto tvrzeni by muselo platit:

Protoze pri vyvoji front-endu pouzivam 16GB pameti tak to znamena, ze vysledny JavaScript pro stranku bude vyzadovat 16GB pameti.

To jako myslite vazne? WTF?

Používám tolik RAM, kolik mají zákazníci. Bohatě mi to stačí, víc nepotřebuji. Je na tom snad něco špatně?

Pokud to zhorsuje tvoji produktivitu, tak ano, je na tom neco spatne. To stejne plati pro textovy editor versus IDE - si pamatuju, ze z tebe minule vypadlo, ze vlastne ani netusis, co za refaktorovani IDE opravdu umi; pro Javu opravdu hodne: napr. zmena poradi parametru metody [vsude tam, kde se opravdu dedi, ne jen trapne pouze podle jmena], presunuti tridy mezi baliky [automaticky to upravi vsechny importy], presun members do predka/potomka [nemusi byt v jednom souboru]*. Argument, ze to nepouzivas (to jsi myslim minule napsal, ale mozna se pletu), opravdu nepouzivej, protoze to znamena, ze delas pouze na nejakych trivialitach, kde se nikdy nemeni pozadavky v prubehu vyvoje (to jsem jeste nezazil :D) a kde vysledny kod je pouze napis a zapomen, nikdy se do vysledne aplikace nebude nic pridavat/opravovat/upravovat (take jsem take nezazil). Predchozi veta navic pocita s tim, ze pises hned napoprve dokonaly kod, coz jsem opet v praxi take nikdy nevidel.

Vsimni si, ze podle tve logiky by kazdy, kdo si prohlizi stranky s JavaScriptem, ktery jsem napsal, by mel mit alespon 16GB pameti**, protoze tolik bylo pouzito pri jeho napsani (realne staci par desitek megabajtu). Vzdyt to je uplne na hlavu, proc by se podle pametove narocnosti dev nastroju mela jakkoliv ridit pametova (nebo jakakoliv) narocnost vysledne aplikace?

**: Pripadne "pouze" nejakych 6GB, pokud pocitas pouze pamet zabranou programy, ktere byly pouzity pri vyvoji samotnem.

*: A to bych rad pripomnel, ze se psanim kodu v Jave nezivim a ani v ni nepisu ve volnem case, takze jsem urcite mnoho pripadu pouziti vynechal. Takovy pristup, jako mas ty, bych cekal spis od studenta, co potrebuje nejak slepit tech par radku na zapocet a v podstate se mu ani nevyplati se ucit ovladat a pouzivat, pripadne i platit, plnohodnotne IDE.

289
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 21:13:23 »
Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).

Jenže to často vyvíjím pro zákazníky, kteří ani ty 4 GB nemají. Nemůžu pro ně dělat něco, co jim na jejich mašinách nepojede. Za to by mi nezaplatili.

Ehm, co je to za logiku? Podle tohoto tvrzeni by muselo platit:

Protoze pri vyvoji front-endu pouzivam 16GB pameti tak to znamena, ze vysledny JavaScript pro stranku bude vyzadovat 16GB pameti.

To jako myslite vazne? WTF?

290
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 20:45:07 »
Jeste k tomu, ze nailgun musi bezet jako server a tedy porad zabirat pamet. Existuje i napr. drip, ktery se spusti s prvnim spustenim javovske aplikace a nechava pripravenou VM pouze urcity cas. Takze jakmile prestanete programovat, tak to po chvili sam vypne. Ale stejnak si myslim, ze je to zbytecne resit, protoze i kdyby vam ten mini plugin jel stale v pameti, tak tech par megabajtu se zcela ztrati vedle gigabajtu na prohlizec, desitek az stovek megabajtu pro aplikaci, db server, IDE/textovy editor atd.

Pokud opravdu vyvijite na takove plecce, tak silne doporucuji se poohlednou po necem, co je z tohoto desetileti (nedavno jsem instaloval xubuntu na notebook s CPU, u ktereho zacal prodej pred 15 lety, a mel 4GB pameti!).

291
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 20:32:27 »
Cílem programátora není psát rozsáhlé molochy. Nejsem placen za řádky, ale za výsledek. Když je má aplikace 100× rychlejší než aplikace konkurenta, tak jsem spokojen dvojnásobně.

Vy mozna, ale zakaznik zaplati treba za 10x vice hodin, nez kdyby to nekdo udelal v Jave. Navic podle dost lidi  ve velkych aplikacich je Java pomalejsi pouze o 0-1x nez C++, ale za vyvoj Javovske verze zakaznik zaplati zlomek penez (vyviji se velmi rychle, skoro vse je standardizovane, zajete nastroje, Java programatori na kazdem rohu) a je to pak snazsi na udrzbu (tusim ze u C++ byly problemy s konvencemi - knihovnami a programatory a napr. stylem pointeru, vse slo resit [a resilo se] mnoha zpusoby v jedne code base; v Jave mate zajete velke knihovny, ktere se pouzivaji na ty molochy, v C++ myslim takoveho nic ani neni). Pokud zvolite spatny nastroj (PHP, C, assembler) a sice dosahnete vyssiho vykonu, ale za cenu napr. o rad vice hodin, tak jste spokojen vy, ne nutne zakaznik. Co tak sleduji vyvoj projektu v Jave, tak vykon se resi spise spravnym navrhem, vhodnymi knihovnami, nastavenim db, optimalizaci dotazu a velmi vyjmecne se meri kazda instrukce a spada se k optimalizaci na urovni bytekodu. Nikdy jsem nevidel, ze by to nekdo resil prepisem do C++. IMO to bude tim, ze takovy vykon potrebuje jen par gigantu na planete, vetsina malych a strednich firem si vystaci s tim, ze to funguje a kdyztak poridi silnejsi zelezo za par supu, protoze se proste nevyplati to cpat do optimalizaci na urovni SW.

Jestli jsem to pochopil správně, tak nailgun je server. To nepotřebuji.

Protoze nemate 2Kc na pamet? Pak tedy nepiste hlouposti, ze v Jave by ten plugin nesel napsat, protoze to pomalu startuje, kdyz by ten start Javovskeho programu mohl byt skoro o rad rychlejsi nez standardni interpret PHP.

Z použitelných nástrojů mi tedy zbývá Perl a Haskell + pár dalších, které jsi neměřil, ale také dávají dobré výsledky.

Kdyz mate poradne IDE, tak mate neco ala live templaty z IDEA a neni potreba zadny dalsi plugin, ktery si musite sam psat. Podle me jen resite neexistujici problemy. Pokud nemate 2Kc na pamet, tak asi ani nepracujete, protoze i s minimem ze zakona by nebyl problem si ji dokoupit (po par mesicich, prece jen s minimem nasetrit tisicovku na pamet, kde rozjedete az 340 instanci weboveho servru v Jave, chvili trva :P).

292
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 18:20:43 »
Neni to malo, ale rozhodne na to, co chtel Kit, to s prehledem stacilo - 100ms pro generovani kodu je myslim celkem v poradku cas.

ok, udelame si tedy mensi srovnani:

JS - 102ms
java - 99ms
ruby - 48ms
php - 31ms
java + nailgun - 4ms  ;)
perl - 3ms
haskell - 2ms
c - 1ms

Takze se ukazuje, ze Java muze klidne byt skoro 8x rychlejsi nez PHP, jen se musi chtit.

PS: Pametovou narocnost zcela zanedbavam, protoze resit nejakych 20MB je uplne mimo, kdyz to doslova stoji DVE koruny. To neberu jako validni argument :D.

293
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 17:55:24 »
Mám 2GB RAM a také v pohodě.

Tohle mne nestaci ani na rozumny vyvoj v JS  - 4GB je naproste minimum (pres 1GB si v pohode vezme build, pres 1GB IDE a na prohlizece a system moc nezbyva). Neni to ani nic obrovskeho, prumerny (mozna dokonce i mensi) JavaScriptovy front-end. Kdyz jsem pak musel zacit testovat proti realnemu BE na lokale, tak bylo potreba jeste mnohem vic (pustena DB, dalsi IDE a samotny BE).

Kdyz jsem si hral se sitovou aplikaci v Jave, tak to spolklo jeste podstatne vic - 2x IDE (klient a server; >2GB), 2x ta spustena aplikace (~1GB), build veci (1-2GB), emulator Androidu (necele 1GB).

Jak bylo napsano stokrat - HW je levny, pamet nestoji skoro nic - 8GB je za tisicovku, lepsi dat par susnu do HW, nez aby skudleni vedlo k opakovanym zpozdenim (=ztratam penez) pri kazdem otevreni projektu, prekladu, debugovani.

Kdybys používal rozumné nástroje, tak ti pro vývoj stačí nejlevnější VPS s 500 mb paměti, na kterém může současně běžet i produkční aplikace.

Technologie jsou zadane klientem, pouzivam nejrychlejsi a nejstabilnejsi varianty. Napr. pro takovy sass prekladac nic lepsiho neni, proste si to giga pameti ukousne (prekladac existuje i ve variante v Ruby a to je jeste horsi).

IDE, ne textovy editor, si take bezne 1GB vezme. Tech 500MB by mozna stacilo na spusteni prohlizece a web servru. Ale pokud bych nemohl psat kod a ani ho prekladat, tak je to k nicemu. Navic tahle levna VPS jsou vykonem casto horsi nez treba RPI, takze to doufam nemyslis vazne. On je "vyvoj" a vyvoj. Pri "vyvoji" ti IDE textovy editor nepomaha a musis casteji provadet preklad a manulani testovani. Pri vyvoji ti IDE pomaha - naznaci ti preklepy ve jmenech promennych, nevalidni kod, pomaha ti s refaktorovanim, dokumentaci atd.

294
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 16:58:08 »
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.

Stare PC s CPU, ktere se davno nevyrabi (vyslo pred 7 lety) a HDD, ktere je urcene na data (tj. pomale):

Kód: [Vybrat]
$ time java HelloWorld
Hello World!

real    0m0.099s
user    0m0.093s
sys     0m0.016s

To mame 100ms. Podotykam, ze jsem nedelal zadne tuneni na vykon/rychlost spusteni, urcite to pujde doladit mnohem vic.

Pokud ti to dava >500ms, tak mas velky krap. Masina pro vyvoj by IMO mela mit alespon starsi i5, kotel pameti a SSD.

295
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 16:21:23 »
I obyčejný Hello, World ti poběží v Javě alespoň půl sekundy. Než se natáhne JRE, tak to prostě trvá.

Odpovedel sis sam, reseni je nenatahovat JRE pri kazdem spusteni - napr. staricky Nailgun (ale urcite jsou novejsi a lepsi reseni).

HTTP server v PHP mi zabírá jen 3 MB RAM. Tomu Java nemůže konkurovat.

To je naprosto smesne:

php: 3MB
java (tomcat, mozna jsou jeste mene narocne): 24MB

rozdil v cene za pamet: 2,35Kc ;D ;D ;D

Navic tyto rozdily, ktere dopadaji negativne pro Javu v tomto prikladu ala hello world, pri nenulovem vytizeni,  netrivialni aplikaci a nutnosti ji i udrzovat budou dopadat pro Javu jen lepe a lepe (JIT = vykon, stabilita, rozsirenost, knihovny). Osobne bych se ridil pravidlem, ze cim vetsi aplikace to ma byt, tim vice pri zvazovani preferovat Javu na ukor PHP, Pythonu, JS, atd.

296
Hardware / Re:Notebook pre Java Vyvojara
« kdy: 01. 10. 2016, 16:00:04 »
Mám 2GB RAM a také v pohodě.

Tohle mne nestaci ani na rozumny vyvoj v JS  - 4GB je naproste minimum (pres 1GB si v pohode vezme build, pres 1GB IDE a na prohlizece a system moc nezbyva). Neni to ani nic obrovskeho, prumerny (mozna dokonce i mensi) JavaScriptovy front-end. Kdyz jsem pak musel zacit testovat proti realnemu BE na lokale, tak bylo potreba jeste mnohem vic (pustena DB, dalsi IDE a samotny BE).

Kdyz jsem si hral se sitovou aplikaci v Jave, tak to spolklo jeste podstatne vic - 2x IDE (klient a server; >2GB), 2x ta spustena aplikace (~1GB), build veci (1-2GB), emulator Androidu (necele 1GB).

Jak bylo napsano stokrat - HW je levny, pamet nestoji skoro nic - 8GB je za tisicovku, lepsi dat par susnu do HW, nez aby skudleni vedlo k opakovanym zpozdenim (=ztratam penez) pri kazdem otevreni projektu, prekladu, debugovani.

297
Vývoj / Re:Map vs. FlatMap
« kdy: 29. 09. 2016, 07:22:08 »
Jsem si celkem jisty, ze flatMap ve Scale neni jen na monadach, takze pokud bind v Haskellu je pouze o monadach, tak flatMap a bind nejsou ekvivalentni. Pamatuju si, ze Erik Meijer v nejakem videu rikal, ze aby to slo hezky pouzit (predpokladam ze ve for-comprehension) je flatMap i na vecech, co nesplnuji monad laws.

PS: Neco jsem k tomu nasel, tak Future to (obecne) nesplnuje - http://stackoverflow.com/a/27467037/1017211.

298
O serveru Root.cz / Re:Nový Root již dnes?
« kdy: 28. 09. 2016, 16:28:25 »
Ne, fixní font opravdu není v kategorii "responzivní design."

Ale ta velikost fontu neni fixni - reaguje na zmenu sirky okna prohlizece => je responzivni.

Treba tu definici z wiki to splnuje:
Citace
Responsive web design (RWD) is an approach to web design aimed at allowing desktop webpages to be viewed in response to the size of the device one is viewing with.

Neni tam nic o tom, ze si uzivatel muze menit velikost fontu/zoomu a stranka na to musi reagovat.

299
O serveru Root.cz / Re:Nový Root již dnes?
« kdy: 28. 09. 2016, 13:51:16 »
Opakuji svůj dotaz: opravdu je někde natvrdo zadrátované, že si na mobilu nemůžu zmenšit celou stránku, jak by se mi hodilo? (co je pak na tom responzívní?)

Ne, ze by se mi to chovani "fixni velikost fontu" libilo, ale technicky to IMO je responzivni - webova stranka se preskladala, prizpusobila a vybrala "vhodnou" velikost fontu pro danou sirku displeje (okna prohlizece). Az kdyby stranka nereagovala na velikost displeje (vetsinou se pocita pouze s sirkou), tak by nebyla responzivni. Taky ty fixni velikosti fontu nesnasim (na mobilu casto takove stranky proste zavru a jdu jinam), ale nemyslim si, ze to ma neco s responzivitou spolecneho.

300
O serveru Root.cz / Re:Nový Root již dnes?
« kdy: 26. 09. 2016, 14:48:16 »
@noef: Ano, ted to po natazeni zcerna, ale vysledek je celkem zajimavy. Tohle na malem displayi nejde. Je tam pismo jak ve slabikari a vsechny texty jsou pres obrazky. Otrava je take v tom, ze to stejne nechodi s vypnutym JS, coz ja na Rootu obvykle mam, protoze se to o dost rychleji natahuje a benefit JS na Rootu je dost omezeny.

Pismo (rodina i velikost) lze zmenit jednoduse v nastaveni. Upraveni kachli s obrazky se obavam, ze v konfiguraci zmenit nejde (po najeti je obrazek videt, pri ne-najeti je videt text; kdyz jsem si s tim hral, tak mne to prislo dostatecne a misto-setrici - vhodne na mala rozliseni). Pokud ale stejne nepouzivas JS, tak neni moc co resit, bez toho to proste fungovat nebude. Kdyz jsem posledne zkousel roota bez JS, tak to byla dost spatna zkusenost - nektere veci nesly zavrit, problemy s forem atd. Koneckoncu JavaScript je norma - pouze 1% uzivatelu JS nepouziva (ve smyslu budto JS prohlizec neumi [ctecky], nebo to uzivatel aktivne vypnul - teto skupiny je pry jen zlomek procenta [tusim 0.2%]).

Stran: 1 ... 18 19 [20] 21 22 ... 60