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] 2 3 ... 11
1
Server / Re:MariaDB vs Postgres vs SQL Server
« kdy: 20. 04. 2021, 13:27:49 »
To se netýká jen práce s databází. Často jsou celé aplikace psané tak, že se na nich nedá výkon škálovat.
Programátoři se neradi zajímají o takové "detaily", že server je jen stroj, má jen určitou paměť, počet jader procesoru. Nezajímá je, že nelze nastavit např.  PHP tak, aby byl povolený běh scriptu desítky sekund a zároveň, že se nezahltí FPM a nepřestane přijímat další požadavky (v lepším případě).

Programátoři by podle mě měli vědět, že existují limity technologií, jaká je náročnost algoritmu, jak se dá škálovat a jak optimalizovat (třeba v budoucnosti). Netýká se to jen SQL.

Pocit, ať to napíšu, jak to napíšu, bude to fungovat, a když ne, tak se zaplatí vyšší výkon serveru, prostě není platný. Co funguje dobře v malém a bez dat, nemusí vůbec jít škálovat do velkého. Pokud script běží 100 ms, za sekundu jich prostě neobsloužíte víc jak 10 x počet jader, a to ještě v úplně ideálním případě. Pokud chcete vyřešit i střední odezvu, tak mnohem méně.

Programátor nemusí umět spravovat server, nastavovat databázi, umět dokonale určit vhodné indexy. Ale měl by umět poznat, kde je potřeba se zeptat - správce serveru, SQL specialisty, a dalších. Problém tedy není v tom, že neumí vše, ale že ani neví o tom, že to někdo jiný umět může a dokáže poradit.

Toto nezachráníte žádnou magickou technologií, ale širším přehledem - celkově, vzděláním v oboru.

Práce s relačními databázemi má aspoň tu výhodu, že tam ten prostor pro optimalizaci obvykle nějaký zůstává a někdy i obrovský. U jiných vám nezbude, než škálovat horizontálně, což taky není žádný med, zbytek aplikace na to musí být připravený (což třeba běžná aplikace v PHP prostě není ani vzdáleně).

IMHO jsou dnesni IT zamestnanci cim dal blbejsi a linejsi.
Co se tyce relacnich databazi, rozhodne nejsem odbornik jako Pavel Stehule, prece mam s jejich vlastnostmi velice dobre zkusenosti.
Potrebne znalosti za rozumnou praci s RDBMS s pohledu vyvojare jsou tyto:
-umet definovat tabulku a select joinem, integritni omezeni
-chapat co je to index a jeho vliv na select a update
-chapat problem redundance x vykon ve forme 3 zakladnich NF
-chapat co je to transakce, jak se projevuje (forknuti dat), pochopit rozdil truncate/delete
-vedet co je to trigger a jak se pouziva
-vedet co je to explain plan
-chapat se existuje neco jako PL/SQL, kde si v primitivnim jazyce na urovni shellu vyrobim proceduralni kod
 - a kdyz vyse uvedene nestacilo, zeptal jsem se lidi s vetsi hlavou, to nastalo snad jenom  dvakrat.

Vyse uvedene mi staci ke stesti. Nic, co by normalni hlava s IQ nad 100 nepobrala za dve odpoledne skoleni.
V realu, kdyz jsem delal s Oraclem, sedel jsem u Toada a jak opice jsem klepal na ikonu sanitky (explain plan) a rypal do toho jak tak dlouho, az Toad prestal zvyraznovat cervene nested loopy. Pak par hintu, aby se jako vychozi tabulka pro join pouzivala ta vzdalena pres DBLink (byla o nekolik radu vetsi), vysledek funguje upokojive dodnes.

Staci povsechne povedomi a RDBMS se pouziva luxusne.


Zato dneska vidim magory, co tahaj megabajty resultsetu mezi DB a aplikacem, aby to pres ORM namapovali do beanu, pak nad tim provedli agregace, jehoz vysledkem je jeden KPI integer.
Pricemz to samy slo udelat s prstem v nose v PLSQL a z pohledu aplikace jeden primitivni "select genKPI() from dual;"
Jenze k tomu je potreba vubec vedet,  ze PLSQL existuje.
A kdyz uz vim, ze PLSQL existuje, pak treba i zjistim, ze Oracle podporuje Java stored procedury. Kde udelam s velice rychlym lokalnim pristupem k datum i takove ficurky jako je test pruchodnosti grafem s vyhledanim optimalni cesty podle vah.


Hlupak se strasne nadre, to plati vzdy a ve vsech oborech.

Prave mi pristal mail s HW sizingem pro jeden system postaveny kolem Elasticu, 48 CPU cores a 100GB RAM.
Podle ceniku AWS $1000 mesicne list price.
A podle meho laickeho nahledu by ty pozadavky dala dvojice postgresu (live + historic data) s TimescaleDB extenzi. Pro kazdy 8GB RAM a 4 CPU cores.

2
Co je tohle za blaboleni?

Python i Javu muzu muzu mit bez omezeni primo na Woknech, sam to tak mam a funguje to flawless. Netusim, co by mi to jako melo prinest, oba jazyky jsou dusledne multiplatformni. A zrovna Pycharm si i virtualenvy spravuje sam

Pro terminal mam koupenou plnou verzi MobaXTerm a veru netusim, co vic bych si mel prat, ani Mac Linux terminaly kvality moby nedosahuji.

WSL2 neni nic jinyho, nez mirne upravena HyperV virtualka s predkonfigurovanyma diskama, pak jeste VSCode ma plugin, ze to s WSL2 pracuje v projektech nativne.

Osobne pouzivam primo HyperV virtualky, kdyz ladim.na linux, tak hezky presne na cilovou verzi, kdyz potrebuju CetOS 7.4, mam tam Centos 7.4.
HyperV funguje na woknech zdaleka nejlip, je to tier1 hypervisor, VMWare player na to nelepi. A  pri pouziti WSL2 stejne dojde k prepnuti hostitelskych oken do urovne nula virtualniho modu a cely slavny VMware player se stava zpomalovacem nad HyperV backendem, ona totiz virtualizace ve virtualizaci je E!E.
HyperV na w10 pro devel ucely funguje skvele, luxusni je hlavne mechanismus checkpointu, vyvoj Ansible playbooku si bez toho uz ani nedokazu predstavit.

Mam pocit, ze mistni osazenstvo ustrnulo nekde v dobach WinXP.

3
Hardware / Re:Lenovo Thinkpad vs Dell Latitude pro vývojáře
« kdy: 31. 03. 2021, 15:16:00 »
Osobne pro tyto ucely pouzivam starsi Lenovo P50 s plnotucnou zacvakavaci dockinou.
64GB RAM, v hyper-v spoustim virtualek bezne 4 kusy vedle sebe, kdyz ladim ansible playbook ma ruzne verze linuxu, klidne i vic.

Na vyvoj neni potreba nejak moc CPU vykonu, pokud je problem s dobou kompilace na starem i7 v P50, popremyslel bych spis o optimalizaci kompilace

4
Server / Re:Databáze - 300 GB tabulka
« kdy: 14. 03. 2021, 21:28:21 »
Mno, uplne sice nechapu zadani, lec pokud je potreba pracovat s time-series daty, doporucil bych time-series databazi.
Konkretne v postgresu velice schopna extenze TimescaleDB, kdera podporuje i komprimaci

Jinak co se tyce mych zkusenosti s Postgresem, je nutno mit na mysli, ze je to databaze transakcni.
Mnoho podivnych brzd v Postgresu uz vyresilo nastrkani commitu, kde je vsude mozno logicky strcit.
 

5
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 17. 02. 2021, 10:23:55 »
PanVP to ze PHP je pre patlaly su strasne kecy. Najdes patlalov aj v Jave aj ASP. V tvojom svete je to tak ze cim kompilovanejsie tym lepsie? Minule som sa bavil s jednim kolegom ktory ma na vsetku silu presviedcal podobne ako ty. Resp. mal rovnaky nazor a nakoniec s neho vypadlo ze PHP je zlo lebo to moze pisat aj "franto od lopaty" ale Javu tak lahko nedas. Argument ako prasa. Zaujimave je ze taky FB si tiez ide PHP. To znamena ze je tam patlalovo? Casto krat ide o to ako rychlo vies dodat riesenie zakaznikovy a s pohladu firmy o to najst kvalitnych ludi ktory pisu rychlo, dobre a lacno.

Hlavni rozdil je v tom, ze v Jave nebo C# jsou frameworky zabezpecene by default, napr ochrana CSFR nebo cross origin  pro rest API se musi aktivne vypinat. A tak koder, co nema poneti, pise bezpecne by default.
V PHP, co si neudelas, to nemas.

6
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 13:33:05 »
Zkratka je to porad nejlepsi a postupne se doiterovavame k vynalezeni kola, viz Typescript, cop Jave ze zadnice vylezl.

Jak říkám, nomen omen. Typescript používá typový systém založené na úplně jiné filosofii, než Java (a podobné jazyky).

Heh, ducktyping je prosty implementacni detail, ktery je jednodussi na transpilaci do Javascriptu.
Staci se podivat, jak se zapisuji v Typescriptu generika, do spicatejch zavorek, stejne jako v Jave. A jak dekoratory, zajimavy, ze pres zavinac jako Java anotace...
Jo, zajimava shoda nahod.
Resultat je takovy ze Typescript jest implementaci Java-like jazyka do sveta JS bordelu.
A snazi se drzet predlohy verne, akorat cast terminologie bere z C#, viz namespaces.

Takze JS je proste takova genialita, az to ze zoufalstvi prepisoujou do Java like syntaxe s obdobnym feature setem.

7
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 12:46:19 »
NodeJS je jeden velky singlethread bordel s callbackama navic s Javascriptem, Typescript se prosazuje velice pomalu.

Ta přezdívka je opravdu nomen omen. Další, má nutkavou potřebu se blamovat dáváním svých neznalostí na odiv.

NodeJS může být i multithread, callback hell je dávno minulostí a větší projekt dneska už v čistém JS nikdo příčetný nezačíná.

Jojo, jasnacka.

Na NodeJS se mi nejvic libi, jak je porad nejlepci a progresivni, dobre navrzeny s rockstable API.
Byl nejlepsi v dobe callback hellu, byl nejlepci v dobe desiveho plain JS a ted kdyz zacina pouzivat Typescript, co resi ty nejvetsi sracky, tak zase je nejlepci.
Akorat si davej bacha pri pousteni npm update, taky se to muze cely sesypat.
 Proste ke starym JS knihovnam pribastlim *.ds.td definici a jedeeem! Nebo to naimportuju jako any.
Zkratka to bylo nejlepci, a kdyz se ty hovna komplet zahodily a predelaly zgruntu odnova, zase je to nejlepci. Nasadime rovnak na ohybak na rovnak a vsecko je skvele.
Zkratka je to porad nejlepsi a postupne se doiterovavame k vynalezeni kola, viz Typescript, cop Jave ze zadnice vylezl.

Ne, vubec to neni kupa hoven splacana na hromadu, na kterou vyvojari zvykli na normalni svet cumi nevericne a se zajmem prohlizelu na Redditu clanky typu "Modni policie: Co je v Javascriptu in a out v roce 2020"

8
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 12:03:09 »
Pokud je důraz na výkon, tak z paměťově bezpečných jazyků jsou nejlepší Go a Rust, jsou zhruba stejně rychlé, Go je velice jednoduché na naučení, Rust nabídne nižší memory footprint. Jinak záleží na kontextu, i node.js na některé projekty stačí (i když JS je otřesný jazyk).

pokud je z nejake nezname priciny duraz na vykot HTTP frameworku (obvykle je uzke hrdlo v DB), pak je nejrychlejsi Java v podani ActiveJ 3.0
https://github.com/the-benchmarker/web-frameworks
A mam k dispozici obri moznosti Java ekosystemu, na ktery zadny jiny jazyk nelepi.

NodeJS je jeden velky singlethread bordel s callbackama navic s Javascriptem, Typescript se prosazuje velice pomalu. Na cokoliv dlouhodobe udrzovaneho je JS a NodeJS peklo.

9
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 11:39:06 »
Citace
30 importov, aby som urobil rest service s pripojenim na mssql a chodilo to nejak rozumne

start.spring.io,  zašrknout spring web, spring data jpa, mysql. Vygenerovaná funkční kostra rest servisy s připojením na mysql ootb..

Holý spring zas tak žravý na resources nebude. Je to pár konceptů na naučení a funguje to spolehlivě.
Větší blackbox je JPA/spring data (za cenu toho, že to hodně akceleruje práci s SQL). Komu to připadá jako moc velký blackbox, může zkusit třeba JDBI (řeší infrastrukturní kód, SQL může mít uživatel pod kontrolou) nebo spring JDBC templates (to už je dost low level, jenom šablonovou metodou obaluje kód kolem JDBC, který by člověk psal pořád dokola nebo by si na to napsal sám podobnou šablonu).

A vedle springu je to třeba quarkus (podobná věc, implementace standardních java API jako JAX-RS, JPA, ale lehčí na zdroje) a nebo různé mikroframeworky (mikronaut, spark java..)

Tak ono ani Spring JPA (Hibernate) neni zadna cerna.magie,.pokud clovek pochpy par prostych principu.
A i to JPA je mozno pouzit s native queries, kdy z hibernatu pouziju jenom mapping do entity beanu.
Takto pouzivam JPA bezne, potrebuju zdimat plne vyuzivat funkcionalitu DB a prenositelnost me nezajima

10
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 10:34:17 »
java na backend je strasny moloch. Kod sice vyzera super jednoducho, ale mas tam milion roznych kniznic, o ktorych netusis ako vlastne funguju.
Ja som niekolko rokov robil servisy v c#, bezia niekolko rokov bez vypadku a zaberaju minimum prostriedkov. Teraz skusam rok javu (springboot+docker) a katastrofa. Strasne to zabera prostriedkov, ten kod je este ako-tak ok, ale 30 importov, aby som urobil rest service s pripojenim na mssql a chodilo to nejak rozumne.
"Programatori" si to pochvaluju, lebo nemusia riesit nic, ale za aku cenu. Ja osobne mam radsej veci pod kontrolou, aj ked to znamena viac pisania.

Ehm, v mavenu je to pouziti 2 (slovy dvou) maven starteru (webmvc + jpa), pricemz na generovani POMu je na webu klikatko https://start.spring.io/

Weru netusim, co by melo byt jednodussi.

11
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 16. 02. 2021, 10:30:36 »
Zalezi, co chces delat.

Jestli oldschool weby pro mensi mnozstvi uzivatelu a silnou podporou business logiky se session a MVC na serveru, pak Spring Boot pres maven starter a zvazit nejake RAD knihovny typu Primefaces, nejlepe v podani Joinfaces, kde to dostanes na stribrnym talire.
K tomu jako bonus OBRI sada funkcionalit z Maven Central, tohe jinde nenajdes, Nuget je parodie, PyPi se jenom blizi.

Jestli chces novy Angular like weby, kde je MVC na klientovi a backend jenom vystavujre REST API, tak pro mensi uzivatelskou bazi opet Spring Boot ze stejneho duvodu - REST api je tam otazkou jedne anotace nad metodou generujici listy beanu.
Pokud pottebujes vyssi vykon ale porad jednoduchou single node server instalaci, pak java netty.io nebo ActiveJ.
 
A pokud hodlas stavet novy google se radove miliony uzivatelu, pak dospod staeless Kubernetes pody v GO.

12
Me se hodne libily mestecka na brehu Bodamskeho jezera.
Nekolik let jsem tam delal.

Priroda luxusni, alpy 2 hodiny autem.

Akorat to bydleni, obecne nejdrazsi countryside v celym Nemecku, drazsi jsou uz jenom mesta jako je Mnichov

13
Server / Re:Jak začít se současnou webařinou?
« kdy: 30. 01. 2021, 14:24:49 »
Moderni weby se hlavne prestehovaly na klienta.

Zjednodusene receno, postaru mas ma serveru nejaky Tomcat/Symphony/whatever a tam bezi klasicka ModelVieverController aplikace, jejim vystupem je HTML kod, ktery se na pozadani soupne do browseru. Server drzi stav a session.

Ponovu bezi obdobna MVC aplikace jako javascript kod v browseru, a ten javascript si jenom saha pomoci RESTu na bezestavovy backend, ktery na pozadani poskytne data, na zaklade techto dat javascript updatuje DOM. A pak ten backend muze byd sada hlopouckych kubernetes kontaku, co defacto jenom obsahuji prevadec REST/JSON na SQL dodaz do DB vespod. Vlastni zatez aplikace je offloadovana na klienta.

Zjednoduseny lifecycle:
1. Browser po prvnim pristupu na stranku stahne Jvascript balik aplikace a spusti jej
2. Tento javascript kontroluje uzivatelske vstupy a pomoci REST si taha z backendu data.

Pokud se tohle chces naucit, tutorialu je hafo.
Doporucuju Angular nebo VUE, jsou to plne frameworky, pro React potrebujes dalsi knihovny, napr. Redux.
Angular ma velkou vyhodu, ze je psany v Typescriptu, VUE teprve planuje na Typescript prejit. Zakladni Javascript je pro slozitejsi projekty nevhodny.







14
Vývoj / Re:Práce s vlákny v C
« kdy: 26. 01. 2021, 08:45:41 »
Je to marný, je to marný, je to marný  :-\
Jo, je to marný, když neposloucháš. Jak chceš něco vykopírovávat ze struktury tohodle typu? https://godoc.org/go.uber.org/zap#Logger

Posilat channelem do gorutiny ruzne instance loggeru je neotrela myslenka.

Apropos, kdyz tu byla rec o Rustu a porovnani s GO, v Rustu jsou plnotucne thready s celym overheadem okolo, tedy defacto guvod, proc vxniko GO a vsecky node.js async mrdky.

15
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 19:24:40 »
Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.
A to prave nestaci. Protoze v te strukture, kterou posilas, muze byt nejaky pointer z te odesilajici goroutiny, a ty o tom vubec nevis (nejaka funkce si tam ulozila neco, cos necekal, ze si tam ulozi).

Jak rika Idris, musel bys kontrolovat cely strom - ne jenom tu horni strukturu, ale i vsechny ji odkazovane struktury.

Tomu rozumim, psal jsem o rozumne blbvzdornosti hlavne v porovnani s C.
Mechanismus pointeru a channelu neni slozity na pochopeni.

V normalnim programu mi ty pointerovane data budou vznikat lokalne v ramci loop smycky (a nasledne hned zapominany), poslany do IN channelu a vysledek vycitan z OUT channelu.
Samozrejme nemuzu posilat pointery na volatilni data.
V Jave to same, kdyz poslu ArrayList, do jehoz polozek mi nekdo z boku hrabe, dopadne to blbe.
V Jave sice muzes tomuto zamezit (https://dev.to/monknomo/make-an-immutable-object---in-java-480n), ale kdo to v realu dela.
Pokud opravdu nastane situace, ze mi nekdo modikuje predavaci datovou strukturu, je neco hodne blbe v samotnem navrhu programu. Ale samozrejme je pravda, ze moznost definice immutable jednoduchou syntaxi je velice prinosna featura.

Pokud budu chtit v danem pripade zamezit tomuto v GO, staci do channelu posilat pointery na hluboke kopie danych struktur a hned je v main threadu zapominat.

Stran: [1] 2 3 ... 11