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 - Standa Blábol

Stran: 1 ... 8 9 [10] 11
136
Vývoj / Re:Java - jak vymazat z ArrayListu množinu položek
« kdy: 24. 09. 2019, 23:39:25 »
Nerad rusim vysoce abstraktni debaty, ale IMHO bude nejefektivnejsi prosty pristup puvodniho tazatele, kdy vytvari novy arraylist kopii dat z puvodniho.

A to z toho prosteho duvodu, ze se jedna o shallow copy, na objekty uvnitr array listu (tipuju nejake beany) se nijak nesaha, pouze se vyrobi nove pole s referencema na puvodni objekty (kryci nazev arraylist), kde budou obsazeny pouze pozadovane reference.

A az se puvodni arraylist descopuje, zmizej i reference na vyhozene objekty, garbage collector to pozere.

Hotovo, veru neni potreba vyrabet selmostroje s kopirovanim nalezenych bloku.
Jednoduche, ucinne, proto mame jawu radi.

137
Vývoj / Re:Java - jak vymazat z ArrayListu množinu položek
« kdy: 20. 09. 2019, 15:40:30 »
Bud si proste vyrob novy arraylist zkopirovanim dat ve foreach cyklu, kde key not in keylist. Keylist array si preved na arraylist a pouzij contains().
Tenhle pristup je vhodny, pokud pocet klicu > polovina delky arraylist


Nebo si vyrob pomocny arraylist pro vsechny keys z keylistu a na puvodnim arraylistu zavolej removeAlll()
Tehnle pristup je vhodny pokud je pocet klicu maly vzhledem k delce arraylistu.

Nepredpokladam, ze resis kazdou milisekundu, to by nebyly daove struktury tak blbe navrzene.

138
Certifikat ma smysl, pokud nic neumis - muzes ho potom vytahnout u pohovoru.

Přesněji řečeno - místo relevantní praxe.

Zdaleka ne jenom to.
Ja si delal certifikaci nekdy v davnych dobach na 1.5 a byl jsem prekvapeny, co vsechno navic jsem se naucil.
Ona dlouholeta praxe taky casto znamena jednotvarne bouchani toho samyho porad dokolecka dokola.


139
Bazar / Re:Prodám knihu: Mistrovství v PHP 5
« kdy: 31. 08. 2019, 15:30:38 »
Od PHP 5.1 se toho zas tak moc nezměnilo.
Delas si kozy?

Ne. V PHP 7.2 používám prakticky totéž, co už bylo v PHP 5.1. Jistě, spousta věcí je vylepšených, spousta opravených a jsem za to rád. Principy jsou však stále stejné.

Co je podle tebe tak zásadně nového, že bys to v PHP 5.1 postrádal?

PHP je nyni pouzitelne hlavne pri vyuziti frameworku.

A Laravel vyzaduje minimalne PHP 7.1

140
Vývoj / Re:Za jak dlouho se naučím C++?
« kdy: 13. 06. 2019, 15:20:46 »
Pro nováčka je C++ asi nejtěžší z rozšířených jazyků.

není, nejtěžší je Java, až pak nasleduje C++

Java je proti C++ triviální. Dá se naučit poměrně rychle - za měsíc až dva se ji naučíš tak, že si s ní můžeš začít vydělávat.

nemyslím si, resp. abych to upresnil tak môžem to povedať tak že sa dá Java naučiť rýchlejšie tak abys dokázal niečo zozliepať a naprogramovať, ale rozhodne si myslím že je Javu omnoho ťažšie sa naučiť tak abys chápal kompletne a presne jak to funguje a vedel v ňom naprogramovať SW kvalitne. Totiž C++ je striktnejšie, a nepovolí ti to naprogramovať až tak moc "špatne" ako Java.

He?

Tak to je poprve co slysim, ze se v Jave daji napsat vetsi praseciny nez v C++

Realita je presne opacna, nic jako pointerova aritmentika, multiinheritance, prima sprava pameti apod v Jave neni.

Java vznikla prave jako bezpecne C++ s osmirglovanymi hranami...

141
Vývoj / Re:MySQL - určení hierarchie potomka
« kdy: 06. 06. 2019, 14:22:56 »
Tady je varianta pro MySQL 8

https://stackoverflow.com/questions/20215744/how-to-create-a-mysql-hierarchical-recursive-query

Jinak zvazil bych prechod na Postgres.

142
Vývoj / Re:MySQL - určení hierarchie potomka
« kdy: 06. 06. 2019, 14:20:39 »
https://explainextended.com/2009/03/17/hierarchical-queries-in-mysql/

Ale je to celkem starsi clanek.

Googli "connect by prior in mysql"

143
Server / Re:Stream server pro audio v mp3
« kdy: 17. 05. 2019, 09:04:21 »
Kdyz tahle moda letela, nejpouzivanejsi byl http://icecast.org/

Nikdy jsem ale nezkousel

145
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 22:14:59 »
Zprasit se da vzdycky a vsechno. Touto logikou bys nevytvoril nic

No samozrejme, ze se da zprasit vsechno, pak nema smysl sasit s prekoplikovanym WSDL selmostrojem, kdyz mi staci jednoduchy XML-RPC over HTTPS a zabezpeceni spring-security poveseny na Url pattern.
Ws security extensions je ciste dilo blaznovo, ti tri magori, co to navrhovali, se u toho museli smat jak Joker z Batmana.
Wsdl.se.da navrhnout bud striktne, pak je to straslive neohebne a da se na ro realne napojit jenom z Jawy a castecne z C#. Nebo se WSDL definuje jako shluk optional stringu, pak se na to da napojit i s PHP, Perlu - na nejake checky konzistence dat sozrejme zapomen.
Kdyz uz mam sasit s pevne definovanou strukturou zprav, to uz radri nasadim ProtocolBuffers - to ma aspon vykon.

146
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 15:37:50 »
Zaprve je treba si ujasnit, proc chceme dat pryc SOAP. Z meho uhlu pohledu jediny rozumny duvod ktery jsem slysel je, ze se to blbe pouziva treba prave javascriptarum.

Podle me je SOAP v principu genialni a nikdo nevymysli nic lepsiho - tehda moc dobre vymysleli, jak mezi sebou maji backend komponenty komunikovat. SOAP ktery je zalozeny na RPC vlastne vytvari pro programatora ten use case, ze programator jakoby vola metodu v jine komponente a to volani je nezavisle na pouzite platforme.

SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
- HTTP metody - nanic
- path variables - nanic
- jenom jeden mozny request body - nanic
- url parametry - nanic

Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.

Proc volani mezi komponentami je RPC a resource je nanic? Protoze my takrka vsichni programatori delame v proceduralnim paradigmatu - nepotrebujeme mit jedno paradigma pro programovy kod a jine paradigma pro komunikaci se vzdalenymi komponentami. A nevsiml jsem si, ze by mezi programatorama byl takovy prehrsel borcu, co maji vsechno v maliku, a zvladnou mit v pouzitych technologiich gulas, plny redundtnich kravin. Je to prave naopak.

At uz je programator zalozeny vice OOP nebo vice proceduralne, tak komponenty predstavuji objekty, ktere si mezi sebou posilaji zpravy (volanim metod) uplne stejne, jako kdyz volame v ramci kompinenty nejakou service. Neni tam zadny duvod pouzivat Resource API.

Nevim cim nahradit Swagger API, ale SOAP je v principu pekne a jendoduse nahraditelny a uz jsem to videl:

V prve rade se pouzije uplne stejny princip, jaky pouziva SOAP, protoze nikdo nic lepsiho nevymysli. Pouzije se REST, API se modeluje pomoci XSD, uplatni se uplne stejne pravidla jako ma SOAP:
- vsechny HTTP requesty jsou POST
- sere se z vysoka na path variables a jine kraviny, je tam jen body
- body je XMLko nebo JSON, je to jedno, jeho jmeno predstavuje jmeno metody a atributy jsou 1:1 parametry jakoby parametry metody
- jako bonus se uz zezacatku mysli na zpetnou kompatibilitu pro Response, aby se porad nemuselo verzovat API. K tomu slouzi v XSD tag "<xsd:any ... >" do ktereho se pri prekladu Response na Java objekt nastrkaji do Listu ty atributy, pro ktere se nepodarilo najit zadny konkretni element pro namapovani - takze kdyz se do Response nekdy prida dalsi atribut, tak kvuli tomu nezacnou okolni komponenty padat na hubu.

Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.

A ted jak je to v realite.
Prijdu u zakaznika k jeho SOAP service.
Totalni chaos a bordel, veschny atributy vystaveny nako optional String. Beda ale kdyz onen optional string nevyplnim, vrati se mi SOAP exception s payload "Eror-11355 - Bus error".

Dostanu WSDL, pro ktery si mam vygenerovat skeleton. Vsechny datove polozky se jmenujou "data" a pouzivanji WSDL s indcludouvanym XSD, co ma includovany XSD, co ma includovany XSD. Nejlepe nejaky business celofiremni header, co odkazuje na nejake dalsi XSD, nejlepe tak kouzelne provazano, ze cely balik provazanych XSD ma 30 mega, vsechno kolem toho chodi a boji se do toho sahnout.
Pak udelam zakladni jednoduchy Spring client, ktery si vzdy na zacatku vyrobi z WSDL skeleton callu, springovi pak trva priprava na kazdy WS call 4 sekundy na 8jadrovem serveru. Tak si jak u blbejch implementuju pool predpripravenych clientu a reusuju.
Konkretne onen 30MB bulk mej i tu vlastnost, ze jediny, kdo byl schopen pro to vygenerovat skeleton byl priohly SpringWS za pouziti wsimport, JAXB nelepil vubec, ten lehl rovnou pri generovani.

Pak prijde pozadavek za zabezpeceni. Mrknu se na WSsecurity extenze a zjistim, ze tohle narhoval naprosty magor. Ze jakmu jsem si nasel autory navrhu, tri panove ze Microsoftu/Sunu/Ericssonu. Napriklad existuje 7 zpusobu predavabi verejneho klice, koncept je tak brutalne slozity, ze prakticky neexistuje plna implementace vseho.
Finalne po cca mesici prace (nedelam si zadek) se "zabezpecene" pripojim, request ma celkem 7 KB z toho payload je jeden bajt "0" nebo "1".

Vse co popisuju jsem realne zazil a ty systemy stale "funguji".

SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.

147
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 15:23:24 »
Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.
Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?

Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"

Najaty programator naprogramoval aplikaci kde je 1 management node, a N slave nodu stylem ze se ten centralni uzel pripojuje skrze nanomsg do klienta a provadi jakysi pokus o RPC. Sakra velky problem je, ze to spojeni navrhnul opacne (protoze dnes je vsecho P2P tak na to co je klient a co server s*re pes vid?), takze moznost pripojit libovolny, predem neznamy pocet uzlu neni mozny. Druhy problem neznalosti sitariny je, ze borec to pseudo RPC mel v blokujicim rezimu pro obe strany. Jako really? A pak to lepi pouzitim X vlaken podle poctu klientu. Dusledek opacne konektivity je, ze namisto dorucovani zprav a normalniho FSM, delal polling, ktery ve spojeni s blokujicim pristupem delal psi kusy a musel dolepovat mutexy. Nemluvne o stavu, kdy jeden klient vypadl, a cely distribuovany system chcipl. Na to, ze UDP by bylo vyhodnejsi pro distribuci broadcast sdeleni, protoze ty uzly se musi synchronizovat a ridit spolecne muzeme taky zapomenout. Co to melo delat bylo znamo predem, ale jak to ma presne udelat nebylo dano. Tak z toho vznikl takovej humus... opravdu neni kazdy hodne programatorske profese.

Abych to shrnul, nanomg je spatne, protoze to nejaky jouda spatne pouzil, proto budeme pro broadcast messages pouzivat UDP pakety, u kterych neni jistota ze vubec dojdou, o nedoruceni se nikdo nedozvi, koncept postavime na uporne vire, ze UDP paket zkratka dojde. Nebo budem UDP pakety potvrzovat ja u blbych a naimplementujem si vlastni TCP stack pro chude.
Hlavne nepouzit neco jako NATS, ktery je na tyhle ulohy delany.

148
TL;DR
... Taktiez je istota, ze apple nezareze podporu daneho modelu po troch rokoch ....
Někdo má telefon 3 roky? Co tak vidím kolem sebe, tak se obměňují i častěji než jednou ročně.

No napriklad ja som mal samsung galaxy s4 mini. Pouzival som ho dovtedy, kym sa dalo. Ked sa mi zacali kazit tlacitka a musel som to mat na powerbanke, tak uz som si povedal ze je cas na zmenu. Uz ani ten os tam dobre nefungoval. Ale este uvazujem, ze to fixnem a dam tam cyanogen (neviem, ako sa to teraz vola). No proste updaty boli strasne zle.  Uz len boli bezpecnostne a jeden z nich mi odfajcil externu sd kartu. Stabilita systemu bola celkom smutna.

Preto teraz pouzivam iphone. Je pekne si kupovat xiaomi, mat tam kukuckove hodinky s vodotryskom, ale cim mi dlhsie telefon vydrzi, tym menej bordelu sa narobi. (teda to je aspon moja naivna teoria) Xiaomi je instant landfill.

Jojo, neni nad to, na foru radit ostatnim a sypat moudra, kdyz moje zkusenosti konci s pomerne smejdskym telefonem z roku 2013, z obdobi, kdy Samsung desive trpel na bloatware, co do svych telefonu cpal.

Upozornuju, ze nynejsi rok je 2019.

Nynejsi situace je takova, ze soucasne SW telefonu nedokaze rozumne vyuzit vetsi vykon, nez cca 100000 bodu antutu a 4GB RAM. A treba Xiaomi A2 lite ma antutu jenom 76000 a sveho uzivatele opravdu nebrzdi.
Vykon navic je vicemene zbytecny, projevi se tim, ze vygenerovani requestu do facebooku trva 8 ms namisto, 16 ms, pak se ceka sekundu na response, tudiz dvojnasobny vykon CPU urychli facebuka z 1.16sec na 1.08 sec. To je vicemene vsechno, co momentalne dalsi navysovani vykonu prinasi.

CPU power Apple Xs max je momentalne priblizne na urovni Macbooku Pro, je vykonnejsi nez Macbook Pro 2017
http://barefeats.com/ipad-pro-versus-13-inch-macbook-pro.html
K cemu je na telefonu takovy vykon? Spravne, k hovnu.

A treba Xiaomi A2 s Android One, Snapdragon 660, 135000 Antutu, 4GB RAM, stoji 5000 Kc. Odpovidajici priblizne iPhone Xr, ktery ma cca dvojnasobny CPU vykon (k nicemu nevyuzity) zato jenom 3GB RAM - stoji 22000Kc. Vice nez ctyrnasobek. Xiaomi drzi oficialni podporu 2 roky, pak se pouzivaji komunitni ROMky, viz miuios.cz. Technicky mene zdatni zkratka po 2 letech telefon vymeni, stoji to ctvrtinu.
A pokud zvolime Xiaomi A2 s 6GB RAM do budoucna, ten stoji 6500Kc.

iPhone mival za ty prachy aspon lepsi fotak. Jenze nyni ono Xiaomi ma dualni fotak s dvojici jinak zaostrenych cocek a to je tak kvalitativni skok, ze ze ZADNY jednocockovy fotak (tedy ani ten na iPhone Xr) nelepi.

Podstatne lepsi je az iPhone Xs - cena kulantnich 30000Kc.

149
Pokud bych se rozhodl pro přeinstalaci na Android, nejsem si jistý, zda-li bych mobil nenávratně nepoškodil, jelikož není cesty zpět. Jste spokojeni s Androidem? Díky za každý tip ;).

Ako uz tu pisali, ono to moze po preinstalovani na android nejak fungovat, ale nebude to na 100%.(Pretoze kazdy hw ma svoje specifika a vyrobci si os hackuju)

Ale v pripade noveho telefonu radim prejst skor na ios, nez na android. Telefony s ios su sice drahsie, a je pre ne menej aplikacii. Ale je na behu poznat, ze system je odladenejsi a len tak si do store hocico nepustia. Taktiez je istota, ze apple nezareze podporu daneho modelu po troch rokoch. Vendor lock-in nehrozi, ako vacsinou nim strasia, ide pouzivat sluzby tretich stran. Napriklad ja hudbu pouzivam spotify, ako doposial a na mail gmail.

Ale aby som iphone len neospeval, ma to svoje specifika, na ktore si casom zvyknete - menej seamless dizajn, notch. (klamem na notch si nezvyknete nikdy)

Bejvavalo. Mozna nekdy v dobach Androidu 4.
IOS 11 byl zoufaly bugfest a IOS 12 to teprve jakztakz stabilizoval.
Zato Android od verze 7 dale bezproblemova zalezitost.

Modernejsi streva Androidu se zkratka uz projevuji, Android s jeno managovanou platformou a garbage collectorem je mnohem snazsi spravovat a je odolnejsi vuci programatorskym chybam.
Za to Android plati vyssi spotrebou RAM o cca pul giga fixne (coz je v dobe 4GB cinanu za 4000Kc smesne) a cca 5-10% zpomaleni managovaneho kodu, pricemz kriticky kod typu OpenGL driveru je stejne psan nativne.

Souhlasim s predrecniky, ze dnes bych sel do libovolneho Androidu z programu Android One, ktery ma android 8 nebo vyssi.

Iphone doplaci na shnile koreny, puvodni iPhone navrhl "vizionar" Jobs jako iPod s GSM modulem s ocekavanymi prodeji 10 mil kusu rocne, do ktereho nesel ani doinstalovat 3rd party SW. Smartphone se z toho stal az za pochodu a to pomerne zoufalym bastlenim typu fixni screen size 3,5 palce (nyni uz vyreseno) a nulove zabezpeceni "vyresene" totalnim sandboxingem 3rd party aplikaci.

Uz nyni z Apple appstore zmizela hromada softu, ktera neprezila prechod 32-64 bit. Android se snazi od pocatku byt co nejmin platformne zavisly, stale jedou i drevni appky, na ktere nikdo 5 let nesahl.
 

150
Software / Re:Messenger pro Android? (aktuální stav)
« kdy: 05. 03. 2019, 19:48:09 »
OK, beru.

A jakou aplikaci konkrétně?
(mi se třeba ten WA fakt nezdá)

Pokud to byla otazka na me, pouzivam Hangouts, WhatsApp, Viber (ruzne kontakty pouzivaji ruzne sluzby) - vyse popsane umi vicemene vsechny. Akorat tusim ze hangouts neumoznuje mazat odeslane zpravy.
Hangouts ale konci, pak prejdu asi primarne na whatsapp.

Stran: 1 ... 8 9 [10] 11