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.
Zprasit se da vzdycky a vsechno. Touto logikou bys nevytvoril nic
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.
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.
TL;DRNěkdo má telefon 3 roky? Co tak vidím kolem sebe, tak se obměňují i častěji než jednou ročně.
... Taktiez je istota, ze apple nezareze podporu daneho modelu po troch rokoch ....
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.
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)
OK, beru.
A jakou aplikaci konkrétně?
(mi se třeba ten WA fakt nezdá)
Zdravím,
přišla mi notifikace od někoho (koho znám), že bychom mohli používat WhatsApp.
Vím, že na dané téma se tu objevilo už hodně vláken, ale ptám se na aktuální stav:
Pamatuju si ještě ze začátků matlafounů (a naprosto zhovadilých tarifů operátorů) třeba Viber, který měl "výhodu" v tom, že se daly posílat zprávy jinak, než cestou normální (=předražené) sms. Že to bylo cestou internetů (=o5 úžasné ceny za datové přenosy, pokud nebylo wifi) nikomu moc nedocházelo.
Od té doby se vyrojilo takových kecálků bambilonšest a já se ptám: JAKÁ je jejich výhoda, oproti třeba těm sms? Nebo pro hovory?
Konkrétně třeba ten WA. Jen tady na rootu jsem našel nějaké články o jeho průs...ech. Nehledě k tomu, že to před časem schramstla xychtokniha a já nemám žádný důvod používat od nich cokoli.
CO je pro Vás důvod pro používání toho kterého klienta?
Smajlíci?
Hejbající se smajlíci?
Smajlíci s pachy?
Možnost volání mimo operátora?
Videohovory?
Jako rád si přečtu něco o tom, že klient ten a ten má "nenapadnutelné" šifrování, ale to je hodně specifický use case...
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.