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

2
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.
 

3
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.

4
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.

5
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"

6
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.

7
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

8
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.

9
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.

10
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

11
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.







12
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.

13
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.

14
Vývoj / Re:Práce s vlákny v C
« kdy: 25. 01. 2021, 18:42:30 »
Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
S tou bezpečností ani blbuvzdornstí bych to nepřeháněl. Stačí si přes channel nevhodně poslat pointer a je na světě problém úplně stejnej jako v C. A vzhledem k tomu, že pointery na structy jsou tak nějak default... Zákeřnější varianta stejné chyby je poslat si sice kopii structu, ale nevšimnout si, že má přes pointer embeddovaný jiný struct. Moc pěkná chyba, hledat ji je čirá extáze :)

Opravdu blbuvzdornou konkurentnost má Erlang, kde chybu tohodle typu udělat z principu nejde, protože sdílet paměť mezi vlákny ("procesy") prostě nejde a basta :) I tam samozřejmě pořád zůstává možnost deadlocku.

No to je sice pravda, lec musim s tim pointerem aktivne prasit dale v main threadu.
Pokud pouzivam aspon trochu stabni kulturu, poslu pointer do IN channelu a v main threadu zapominanm na jeho existenci, tam se to bezpecne posle do jedne instance gorutiny (tudiz nenastane situace, ze 2 gorutiny delaji na stejnem pointeru) a vysledny pointer na vysledny gorutinou modifikovany struct nacpu  do OUT channelu, odkud si to v main threadu zase vytahnu.

Takze staci nebyt uplny dobytek a prace v GO je rozumne bezpecna.


15
Vývoj / Re:Práce s vlákny v C
« kdy: 20. 01. 2021, 03:11:28 »
Mimo puvodni dotaz.
Multithreading v C je pain a porad jednou nohou v pruseru. Business kod taky pain, prenositelnost a devops peklo.
A to nejenom pri vyvoji ale hlavne dale pri zmenovkach a udrzbe.
Neznam samozrejme pozadi tohoto programu, ale zvazil bych pouziti vhodnejsiho jazyka.

Treba v GO je to pres gorutiny s prstem v nose, mechanismus channelu je z bezpecny a blbuvzdorny
Nebo v Jave pri pouziti netty.io

Stran: [1] 2 3 ... 11