Notebook pro vývojáře v Javě

[Kit]

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.

Jenže já toho výkonu nedosahuji přepisem do C++ nebo Javy. Dělám to formou objektového návrhu. Už použitím samotného objektového přístupu se aplikace významně zrychlí. Zrychlení nebývá mým cílem, ale dostavuje se tak nějak automaticky právě použitím vhodné architektury. Tím, že mám ten kód výrazně kratší než kdyby byl v Javě, mám aplikaci hotovou dříve.

[Reklama]

[javaman ((]

Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.

Tím bych si nebyl tak jistý. FlowViewer je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).

Ta pomalost může mít spoustu důvodů. Nejspíš bude problém na straně databáze. CGI skript by měl zpracovávat jen tolik dat, kolik se zobrazí.

Určitě, DB to zabila



http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/

[javaman ((]

Tím, že mám ten kód výrazně kratší než kdyby byl v Javě, mám aplikaci hotovou dříve.

To zase asi ve snu. Java má jedny z nejlepších knihoven vůbec, které v PHP budeš mít až tak za 5 let.

[Kit]

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.

[linuxtardis]

Náročné aplikace nikdy v Perlu nenapíšeš, takže je ti úplně jedno, kdy se co začne zpomalovat.

Tím bych si nebyl tak jistý. FlowViewer je psaný jako sada perlových CGI skriptů. Bohužel rychlost nad větším množstvím dat celkem upadá (konkrétně FlowGrapher Analysis s velkým časovým rozsahem).

Ta pomalost může mít spoustu důvodů. Nejspíš bude problém na straně databáze. CGI skript by měl zpracovávat jen tolik dat, kolik se zobrazí.

Máte pravdu, návrh v tom také bude mít prsty.
Databáze je kolekce souborů s flows z NetFlow kolektoru, nad kterými se spouští céčkové utility. Ty jsou brzděné jen rychlostí IO (cache kromě souborové není). Horší je pak zpracování do grafu.

[Reklama]

[to_je_jedno]

to je šulín... jsem ho do ted jen podezrival, ale on se priznal - tvari se, ze neco vyviji a pritom pracuje se 2GB RAM - to staci stezi na prohlizec a IDE. Zbytek te omacky jen svedci o tom jaky je asocial ktery navic uctuje zakaznikum vlastni neefektivitu pouzivanim obskurnich nastroju. Kite ty dneska davas teda bomby.

[Kit]

Určitě, DB to zabila
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/

Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.

[gl]

Určitě, DB to zabila

To je hodně debilní benchmark, který není v rozporu s tím, co jsem psal. Pokud potřebuješ smyčku o 10 * 32000 * 32000 krocích pro vygenorování jedné stránky, tak děláš něco špatně. A psát takovou smyčku v bashi? LOL

[javaman ((]

Určitě, DB to zabila
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/

Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.

Přesně. Chudák objektový Bash, vůbec se nedostal ke svému

[neruda]

Každé fórum má čas od času nějakého stálého retardovaného kašpara, který se časem vyčerpá a zmizí.
Tady je to teď "javaman".

[noef]

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?

[javaman ((]

Každé fórum má čas od času nějakého stálého retardovaného kašpara, který se časem vyčerpá a zmizí.
Tady je to teď "javaman".

Jen Kit s bráchou jsou tu navždy!

[Kit]

Určitě, DB to zabila
http://blog.carlesmateo.com/2014/10/13/performance-of-several-languages/

Tím, že někdo udělá test na nějaké cykly, jasně upřednostní imperativní jazyky, jakým je např. Java. Vsadil bych se, že v testu nebyl použit ani jeden objekt, proto jsou ty výsledky zcela nesmyslné.

Přesně. Chudák objektový Bash, vůbec se nedostal ke svému

Bash na cykly vůbec není stavěný, proto v takovém testu logicky propadl. Síla Bashe je v něčem úplně jiném - používá se jako lepidlo mezi drobnými utilitkami, kterých je v linuxových systémech hromada a které jsou rychlé.

Bash má k OOP blíž než Java.

[javaman ((]

Jako třeba Systemd

Java je normální objektový jazyk a Bash k tomu asi blíže bude mít těžko Ale to bude zase nějaká specialita! Povídej!

[Kit]

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ě?