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 ... 13 14 [15] 16 17 ... 60
211
nicmene tak pred rokem jsem v jednom podobnem vznesl ze zvedavosti dotaz, na najeakou libovolnou javovksou desktop aplikaci, ktera se da pouzit jako dukaz ze to jde....
Uvedu znovu kvalitni (jiz mnohokrat zminenou) IntelliJ IDEA, ale stitek desktop aplikace nese i velmi popularni Minecraft.

<trolling>
v tu dobu byl ale vysledek vsech odpovedi cistokrevna nula.....proste v jave neni napsane kvalitni vubec NIC. myslim ze par lidi nabydlo nejake utilitky, tooly atd, ale zadna big java desktop app vubec nikoho nenapadla......takze round #2, ma uz java nejakou vykladni skrin?
</trolling>
FIFY

PS: IDEA zcela jiste spada do kategorie "big java desktop app" (stejne jako Eclipse a NetBeans) .

212
Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?
« kdy: 13. 11. 2016, 07:07:46 »
Hm, C bezi vsude, argument jako prase proc mit binarni/cizojazycnou zasivlost v JavaScriptu, ktery take bezi skoro vsude (a tam, kde nebezi, tam mi je bezici knihovna v C na prd, kdyz hlavni aplikaci nespustim :D). U vykonostne nekriticke knihovny to muze jen idiot takto roztrkat. C bych i chapal, pokud je opravdu narust ve vykonu v nasobcich a pokud bottleneck vetsiny aplikaci prave stoji na teto knihovne. Pokud knihovna zavisi na vylozene pomalejsich vecech  jako Python nebo Ruby, tak je to vzdycky na facku. Pokud existuje alternativa, tak nasleduje instantni zahozeni tohoto odpadniho baliku a nainstalovani normalniho. Kdyz totiz mate takhle "genialne" resene zavislosti (spise neresene), tak nestaci mit nainstalovany node a npm, ale musite instalovat Python, build veci pro C, dalsi ne-npm knihovny (dll/so), laborovat s verzemi Pythonu a zjistovat, jakymi workaroundy se ma predavat node-gyp cesta k pythoni binarce, protoze pozaduje prirozene nejakou archaickou verzi (dvojkova vetev). Takze si instalujete knihovnu pres balickovac - npm, ktery bezne resi zasislovi, pokud ale pouzivate takoveto veci mimo platformu, tak tam si musite cast zavislosti resit sami.

Jestli je to stejne polamane i v Jave, tj. ze se knihovna distribuuje napr. treba jen binarkami pro linuxu x64 a vse ostatni "pores si sam", tak se vubec nedivim, ze to nekdo prepsal do Javy. Jen opravdu ve vypocetne kriticke situaci bych sahl po kockopsovi (napr. knihovna pro nejake obecne mat. vypocty). Pokud je to knihovna, ktera i kdyby byla 100x pomalejsi nez verze napr. v C, ale aplikace stravi 0.01% casu vykonavanim kodu knihovny, tak to pridava akorat zbytecne starosti.

213
Vývoj / Re:Co zpomaluje Javu? A co preklad do nativniho kodu?
« kdy: 12. 11. 2016, 17:22:30 »
K tomu prepisovani "lepsiho" softu do Javy, ona vyhoda bude, ze to potom spustite vsude, kde se spusti Java. Nejste zavisli na nejakych binarkach pro konkretni architekturu.

Treba v JavaScriptu je to podobne. Nektere baliky z npm si s sebou tahaji ruzne obludnosti v Ruby, Pythonu nebo C (klidne na vsech zaroven) a jsou s tim neustale problemy. Pokud to funguje, tak to muze byt rychlejsi, ale pokud to nefunguje, tak je to celkem peklo - dohledavani na cem vsem to zavisi, ze to nefunguje s touhle verzi Pythonu (2 vs 3) a ze se tomu musi manualne nekde predat cesta, ze se nekde nestahly predkompilovane binarky pro mou architekturu a OS, ze mi chybi nejaka knihovna. Proste tohle u cisteho JS reseni neni, tomu date "npm install" a konec. Vse je rychle stazene, nic se nemusi prekladat nebo dotahovat odjinud, funguje to vsude, kde jede nodejs.

214
Vývoj / Re:Responzivní design v česku moc nefrčí?
« kdy: 12. 11. 2016, 06:55:43 »
prumerna rychlost netu v CR (2015): 14.5Mbit ~ 1,8MB/s

Tak jako nejde jen o rychlost, ale třeba u mobilního připojení o spotřebu dat kvůli FUP.

JS, pokud to nedelal idiot, se taha jen pri prvnim nacteni stranky. Tzn. treba jen jednou za mesic, nebo za rok.

215
Vývoj / Re:Responzivní design v česku moc nefrčí?
« kdy: 12. 11. 2016, 06:54:14 »
Jo, to jiste vocenej, tada predevsim lidi co to s radosti hackujou, protoze deravy jak reseto je to porad.

Jako front-end v JavaScriptu je deravej? wtf?

A jak vidno, patris mezi ten dobytek, co vsude nasere hromady scriptu, protoze nic neumi. Proc psat neco na 5 radku, kdyz si na to muzem nalinkovat 5MB knihovnu zejo ...

Jen tak mimochodem Angular 2 ma tusim 8MB a jestli bude tak uspesny a lidi nebudou pouzivat aot, tak to bude na zatracene hodne webech ;D.

Ke knihovne, 5MB je trochu moc, ale par desitek nebo stovek kilo je nic, protoze vetsinou tech knihoven neni potreba zase tolik. Navic ten JavaScript se stahne jednou a pak pri kazdem dalsim nacteni se uz znovu nestahuje, takze je celkem putna jak je velky (bolet to muze jen na prvni nacteni mobilni uzivatele a i tam existuji reseni, treba nejake siroce pouzivane cdn -> knihovna se na strance nenacita nikdy). Zamestnavatel mi opravdu nebude proplacet patlani se s nejakou komponenou nebo funkci, pokud existuje open source knihovna.

A root ... lol ...

Load time 7.63 s
Requests 242

Jo .. je to testovany jen z gigovy patere, pravda, to ma kazdej druhej lepsi ...

Samotny web je v poradku, problem jsou reklamy. Ale o tom jsem psal uz pred dlouhou dobou.

Citace
Bohužel reklamy samotné mají velmi výrazný vliv na čas, který uživatel stráví čekáním - bez reklam se čtenáři stránka načte skoro čtyřikrát rychleji!
http://mnn.github.io/blog/cs/2016/Root-cz-osklivy-JavaScript-a-fonty-mi-ruinuji-FUP/

Premereni dnes:
Bez reklam: 1.4s (1.99s load time)
S reklamami: 3.1s (9s load time)

Responzivni != tuna pomalych reklam ;).

216
Vývoj / Re:Responzivní design v česku moc nefrčí?
« kdy: 11. 11. 2016, 20:24:43 »
Ach jo, zase je to tu, "odborne" debaty o webovych strankach.

Tmave stranky jsou podle vyzkumu velmi nevhodne, vice jak polovina lidi ma problemy je cist a musi si na ne "zvyknout". Take mam rad tmave skiny, ale zadna webova profi firma je nikomu nedoporuci.

Responzivni != nelze zoomovat.

Responzivni != lista musi byt prilepena nahore.

Responzivni != material design (s tim jdou ruku v ruce barvy). Jde pouze a jen o to, ze oba pristupy jsou moderni, takze logicky se kombinuji.

Delat stranky bez JavaScriptu pro pouha 2% navstevniku vetsina firem opravnene vyhodnocuje jako vyhazovani penez.

Mit stranky ve Wordpressu/Drupalu, ikdyz jsou staticke, je vyhoda - jsou velmi levne na vytvoreni (casto se jen lehce upravi sablona), maji tunu pluginu (i zadarmo) a hlavne je klient BFU muze jednoduse upravovat pres klikatka vcetne formatovani textu a nemusi platit drahe profesionaly.

Osobne si myslim, ze par mega JavaScriptu neni zadny problem. Tolik da v pohode dohromady par obrazku na strance. Navic rychlosti pripojeni uz nejsou, jak v dobach dial-upu. Priklad:
prumerna rychlost netu v CR (2015): 14.5Mbit ~ 1,8MB/s
velikost roota vcetne reklam: 1.3MB
doba nacitani roota na prumernem ceskem netu: 0.7s

217
Windows a jiné systémy / Re:Je lepší Windows nebo Linux?
« kdy: 09. 11. 2016, 20:07:37 »
64b verze na 32b stroji (alespon v tom lts) nedavalo cerveny text (asi nejaky fail pri pousteni sluzby?) ale bily, ktery zustal viset. vyzkouseno asi dva mesice zpet. jsem netusil, ze takovy srot jeste mezi lidmi zije :D.

218
Windows a jiné systémy / Re:Je lepší Windows nebo Linux?
« kdy: 09. 11. 2016, 19:35:11 »
Za posledni rok jsem ubuntu live bootil na par desitkach komplu a nikdy nebyl problem (vzdy lts). Jste si jisty, ze neni problem v HW (at uz ta klicenka nebo pc)? Jako jo, parkrat se me podarilo ubuntu rozdrbat, ze skoncilo na kernel panic (ovladace grafiky). Ale teda nikdy ne tu live verzi, ta me jela i na 10 let starem kramu, ktery Widle uz nepodporovaly.

Ta argumentace je samozrejme trapna - uplne stejne snadno lze pouzit proti cemukoliv. Napr.: "Protoze pacient v ustavu pro mentalne chore neumel nainstalovat Windows 10, tak ten OS musi byt hrozny odpad."

219
Studium a uplatnění / Re:Co vás motivuje k programování?
« kdy: 09. 11. 2016, 19:23:24 »
Asi podobne jak uz tu nekdo psal - hrat si s necim hodne rozdilnym, nez v cem/na cem pracujete.
Ja delam v JavaScriptu a po vecerech si hraju s Haskellem (velmi pomalu zacinam pronikat do uplne odlisneho sveta nez je mainstream OOP ala Java, C++ a C#). Treba nyni mam rozdelany prekladac a interpret vlastniho esoterickeho jazyka.
Drive jsem pro zabavu vyvijel modifikaci Minecraftu (nejdrive v Jave, pak ve Scale) - tam bylo skvele, ze jsem neco naimplementoval za par hodin a pak jsem tu hru i s tim novym obsahem hral s dalsim znamym.
Vejska na tohle byla skvela - hromada temat se tam jen nakousla a dala mi povedomi o mnoha vecech, co bych treba v budoucnu chtel zkusit.

220
Hardware / Re:Jak často měníte hardware?
« kdy: 09. 11. 2016, 10:38:52 »
1) mobil android, menim zhruba kazde 2 roky
2) Desktop - dokud jsem studoval, tak jsem moc casto neupgroval, asi kazdych 5-6 let a byl to spise herni low-end. Celkem dost jsem hral. Po skole (asi 2-3 roky zpet) jsem si konecne poridil trochu lepsi stroj (i5, gtx 950, 8GB, ssd). Ta i5 a 8GB pameti byl obrovsky skok ze starickeho phenomu 1 s 6GB (velmi pomale pameti). ssd zatracene zlepsilo dobu kompilace i obcasne prodlevy v IDE. Konecne jsem pri vyvoji nemusel zavirat Firefox, protoze dochazela pamet :D. Bohuzel od dokonceni skoly, prestoze jsem mel konecne i trochu herni pc, hravam podstatne mene :-\. Nasledoval upgrade pameti na 16GB, asi rok zpet. No, nedavno jsem si poridil dalsi ssd, gtx 1070 a budu kupovat nejaky 4k monitor. Take jsem presel na tuxe jako hlavni os a tim doslo k dalsimu zrychleni prekladu pracovnich veci - zhruba o tretinu. Osobne nechapu, jak se to stalo, kdyz to vse jede ze stejneho ssd a fs, asi nejaka krpa ve Widlich.

Jak to tu ctu, tak nejsem asi moc typicky linuxak ;D.

Provozuju i domaci server a to je kockopes seskladany ze starych komponent, ktere zbyly po upgradu ruznych pc v okoli. Tipuju, ze komponenty v nem jsou stare 0-8 let.

Rodice maji hodne prehistoricke kusy, notebook i desktop budou mit 10 let, mozna vic. Na vsem jim jede tux a je to (pro ne) plne dostacujici - nenarocne brouzdani, maily v thunderbirdu, dokumenty v libreoffice.

221
..Dnes chodia lopaty skor na to pravo a ekonomiu a technicke smery su v kurze.

Opravdu se to tak zmenilo? Kdyz jsem se na to pred nekolika lety dival, tak pocet absolventu tech. oboru stagnoval - vztazeno k celkovemu poctu absolventu se dlouhodobe propadal.

222
To jsou zatracene vyznamne zmeny a je jedno, ze cast je pouze cukr. Napr. ten splat je sice cukr, ale je rozdil napsat nekolik radku hnusneho boilerplate kodu vs. tri tecky. Importy jsou taky velmi dulezita vec, nebo strukturovani programu neresite a mate jednu dlouhou nudli?

JS sice tridy nepotrebuje, ale taky proto se casto nepouzialy. A kdyz, tak bylo nekolik zpusobu jak to resit a vsude to tedy bylo pouzivano ruzne - byl v tom bordel -> radeji nepouzivat. To se prave s es2015 zmenilo - jsou proste jedny tridy, ktere jsou jasne na prvni pohled kazdemu a IMO prehlednejsi, treba ta dedicnost. Prototypy tam dale jsou, kdyz nekdo chce jit lowlevel a oldschool, tak ma moznost.

V Haskellu nebo Scale je destructuring (pattern matching) zcela bezny a je to naopak preferovane oproti rucni manipulaci. Nepouzivat to znamena mene prehledny kod (pomijim prejmenovani v JS, tak je to asi o zvyku). To stejne => nebo kratke zapisy vlastnosti, usetri to spoustu boilerplatu - programator nemusi cist balast. Fat arrow zkratily zapis fce a usetrily tolik radku s boilerplate "var that = this;". Const sice lze simulavat, ale z jednoho kratkeho radku se stane obr na 6.

Veci typu typovane pole, proxy nebo generatory umoznujici async nejsou zadny cukr. Stejne tak kolekce, weak kolekce, symboly, nove metody na primitivech (repeat, startsWith, includes), i18n a l10n.

Ikdyby tam byl jenom cukr (coz neni), tak s vasim pristup muzu o C/C++ rict, ze je to jen cukr pro assembler ;D.

223
Vývoj / Re:Jak udržet přehlednost JavaScriptu
« kdy: 07. 11. 2016, 15:33:54 »
jQuery je dobre, rozhodne na nej nenecham dopustit. Ale je to jen takovy univerzalni nastroj, ktery pouzivam spise kdyz pisu kratke user-scripty. Na psani celych aplikaci se moc nehodi. Rozhodne je nutne ho nejak znat, jak piseste, dost knihoven/komponent na nem zavisi. Parkrat jsem musel sahnout po jQuery i pri praci v Angularu, ale je to opravdu vyjmecne, neco jako jedno pouziti jQuery na tisice radku kodu.

S webpackem se celkem dobre zacina, gulp bych do zacatku urcite neradil (navic IMO jeho popularita klesa na ukor ostatnich reseni - treba webpacku a npm skriptu).

224
Ale houby. V PHP se od verze 5.1 nic zásadního nezměnilo, Java 6 zůstala také stejná, Python 2 také bude ještě dlouho v kurzu, Javascript se také nezměnil, Fortran podobně jako Lisp funguje už mnoho desítek let...

Co je na tom tak dynamického?

 :o Vzdyt v Jave 8 je  kotel FP veci, z toho vyplyvajici novy best practices a urcite tuna dalsich veci, o kterych nevim, protoze v Jave nepracuju.

To stejne JavaScript - ES2015 byla teda zatracena zmena: napr. tridy, template stringy, fat arrow, destructuring, default arg, rest arg, spread, let a const, moduly, generatory, mnoho pomocnych funkci pro zakladni typy, typovana pole, nove kolekce. To by me zajimalo, co si predstavujete pod velkou zmenou, jestli tohle vsechno je pro vas "se nezmnenil". Asi zahozeni stavajici syntaxe a semantiky a predstaveni noveho jazyka se stejnym jmenem ;D.

225
Vývoj / Re:Jak udrzet prehlednost javascriptu
« kdy: 07. 11. 2016, 14:33:27 »
Od vetsiho pouzivani jQuery se uz dlouho odrazuje, prave kvuli problemum, ktere vyvstavaji u netrivialnich aplikaci. Kdekoliv se muze odkukoliv cokoliv zmenit, takze se v tom velmi spatne orientuje. Jak popisujete, casto jsou to spagetova reseni, protoze samotne jQuery ani JS k nicemu nenavadi. Tento problem se bezne resi pouzitim knihovny ci frameworku. Podivejte se napr. na Angular 2, ktery ma jasne danou strukturu kodu a sepsana doporuceni, co jak resit, organizovat a proc to tak delat (nebo Angular 1 ci React, ale ten strukturu vynucuje podstatne mene).

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