Příspěvky

1

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 22. 04. 2021, 17:16:58 »

že existují lidi, co se snaží kladivem zatlouct šroubky, a "ze své vlastní zkušenosti" pak šíří, jak jsou ty šroubky nesmyslná technologie.

Jako profesně bývalej truhlář musím poznamenat, že šroubky se kladivem zatloukají naprosto v pohodě ;-)

Nás to tak učili na základce a to si nedělám srandu! Myslel jsem tehdy, že umřu - můj tatínek byl (mimo jiné) jemný mechanik a pracoval v letecké prototypové dílně - zatímco soudružka učitelka zatloukala vruty kladívkem, uf! Pak mi ještě utkvěly takové ty umělohmotné šuplery, které byly pružné, takže když člověk dorazil naměřil +- 0.5mm. Inu, totalita.

2

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 22. 04. 2021, 15:36:42 »

Ondra:

IMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě.

Toto myslím není úplně přesně řečeno. Jsou jednoduché projekty, které se do tohoto stavu niky nedostanou a noSQL tam bude o něco rychlejší (o definici tabulek). A jsou projekty, které jsou tak složité, že když je někdo založí na jednoduchých technologiích, spláče nad vejdělkem.

Samozřejmě souhlas.

3

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 21. 04. 2021, 20:07:34 »

Jak jsem se poprvé dozvěděl o MongoDB? Bylo to asi v roce 2016 a vedoucí projektu řekl "Na blbnutí s SQL nemáme čas!" Zákazník očekával rozběhnutí projektu prakticky hned. Než jsem si to osahal, myslel jsem si, že se zbláznil. Ale vývoj produktu - oproti jiným projektům - doslova uháněl. A to se zadání v průběhu projektu měnilo, jak se zákazník vyspal. S NoSQL se člověk nesoustředí na "vyšpekulování krutopřísného Joinu", ale hloubá nad svým objektem, aby lumpík dělal, co dělat má.

Představa, že Vám něco zázračně ušetří práci, je podle mě mylná. IMHO v dlouhodobějším horizontu pracnost+nákladovost srovnatelných technologií konvertuje k podobné hodnotě. Co ušetříte v denormalizaci, objeví se časem v nárocích na aplikační kód, výkon hardware nebo údržbu. Což zde bylo už opakovaně řečeno. Jinak nic proti nadšení z NoSQL, ale každé nadšení časem vyprchá a sedne si a člověk pozná limity.

Jinak Pavla Stěhule považuju za odborníka se značným rozhledem a zkušenostmi a přijde mi nesmysl obírat ho o čas nějakou neplodnou polemikou...

4

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 20. 04. 2021, 19:24:20 »

Vinit z těch nešvarů SQL nedává smysl. Je to obecný jev napříč všemi technologiemi a ani super přímočaré a jednoduché koncepty to nezlepšují (např. JSON se používá protože je tak jednoduchý a každý ho pochopí - ale že má nějaká omezení, které přinesou problémy a odloženou pracnost, to si řada lidí neuvědomí).

Ve skutečnosti je to prostě projev změněných poměrů - jiné množství programátorů, jiný poměr počtu lidí vs. počtu počítačů, jiný rozsah kódu atd. atd.

Asi to lze řešit na osobní úrovni - kdo chce pracovat s kvalitním kódem, musí se probojovat do nejlepších kruhů, kde se děje něco zajímavého nebo běží nějaký výzkum. Jinak plave v kompromisech, které ale na druhou stranu na řadu věcí stačí a pracovat tímto stylem taky není ostuda, alespoň pokud se k nim člověk přiklání vědomě.

Jako třeba ten příklad s taháním celých dat, abych použil jedno číslo - to zase není rozhodnutí jednoho programátora, jde o množství kódu, použitý framework (často ORM, které má přinejlepším nějaký lazy loading) takže nakonec se programátor rozhoduje zda napíše nové sql dotazy (které bude muset navíc obhájit) nebo použije existující otestovaný kód pro uložení celé beany. Prostě - kompromis.

5

Desktop / Re:Jak vypnout čínské, japonské a další non-latin varianty písma?

« kdy: 19. 04. 2021, 21:43:04 »

Pozoruhodné... 

6

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 18. 04. 2021, 22:53:31 »

...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze. Podle mě by v pohodě nahradily 90% případů, kdy je sql použita neoptimálně a de fakto zbytečně. Dnes se do této oblasti tlačí NOSQL a dokumentové databáze, ale to mapování opět bolí.

Nemohlo by to být tím, že zatímco relační algebra je jasný, matematicky propracovaný systém, kde jsou problémem spíše uživatelé, tak u objektů je problém si jen ujasnit, co je "správně objektově"?

Nemyslím, že by to byl ten problém. „Správně objektově“ je prostě to, co daný programátor napíše. Databáze mu do toho nemluví - ta má jen object graph uložit a opět načíst. Problém může být nejednotný dotazovací jazyk (stejný problém jako u  ORM) a samotný princip object graphu - poznat, co se kde změnilo a do jaké úrovně to ukládám. Udělat to plně automaticky asi není snadné (s detekcí cyklů a kolizí) a pokud musí vše řešit programátor např. implementováním nějakého předepsaného rozhraní, tak má dost práce navíc. Ale stále mi přijde, že by u malých databází by leckdy stačila in memory databáze se atomickým dumpem paměti.

Abych nebyl škarohlíd, nějaké pokusy existují, zajímá mne hlavně java a tam (nepočítaje v to zaniklou db4o) existuje např. MapDB, ZooDB, pcollections nebo asi nejprogresivnější MicroStream.

7

Server / Re:MariaDB vs Postgres vs SQL Server

« kdy: 17. 04. 2021, 16:25:05 »

To je otázka interface - a když použijete Linq, tak ani nemusíte vědět, co je pod tím. Ale pokud nepoužijete opravdovou objektovou databázi, tak stejně bude docházet k nějakému mapování

Ta degradace databáze na storage má svoje výhody (máte méně kódu), ale i svoje nevýhody (nikdo jiný než vaše aplikace) neumí s daty pracovat - nemáte garantováno, že vám někdo externě naleje data ve správném formátu. A při exportu musíte načítat generické json - ta data mohou být relativně komplikovaná, protože mícháte víc entit do jednoho dokumentu. U relační databáze máte vstupně výstupní formát mnohem jednodušší (není rekurzivní) a garantuje vám ho databáze.

Domenove objekty ve vasi aplikaci mezi sebou maji vazby, ktere tvori graf, a ne strom. Jakym zpusobem grafove zavislosti ukladate do MongoDB? Vsude vidim jenom priklady na ukladani stromovych vazeb.

...a to je mi právě záhada, proč se více neuchytily a nerozšířily objektové databáze. Podle mě by v pohodě nahradily 90% případů, kdy je sql použita neoptimálně a de fakto zbytečně. Dnes se do této oblasti tlačí NOSQL a dokumentové databáze, ale to mapování opět bolí.

8

Odkladiště / Re:Setkáváte se z "updatofobií"?

« kdy: 16. 04. 2021, 16:44:07 »

Jelikož jsou uživatelé čím dál více jen hříčkou technologií a technologických firem, tak se jejich odporu k updatům ani nedivím. Základní potřeba uživatele je mít technologii pod kontrolou, tedy vědět co mi update přinese, možnost update odmítnout případně určit čas, kdy k němu dojde.

Stanovisku vývojářů nicméně také rozumím, sám jako vývojář chci, aby měl uživatel pokud možno poslední verzi. Takže je to o budování důvěry a  loajality...

9

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 14. 04. 2021, 19:58:31 »

Proroutování adresy na koncové zařízení je technicky velmi jednoduchá věc, přeci nemůže nikdo v diskusi psát, že to stojí o hodně víc, než ty adresy, které na to padnou.

Ano, je to jednoduchá věc – když to děláte ve své síti s pěti počítači. ISP pravděpodobně používá nějakou automatizaci – zasahovat do automatické konfigurace ručně je vždycky velmi problematické.

Nevím nevím, není to náhodou tak, že routovací démoni právě to routování automatizují až na úroveň toho, že v ideálním případě se přidělená IP adresa naroutuje veskrze sama? Takže pokud by infrastruktura s tím počítala tak tam pracnost navíc není žádná, akorát vypotřebují jednu IP adresu...

10

Vývoj / Re:Výroba multiplatformní aplikace s GUI v Javě

« kdy: 14. 04. 2021, 16:26:46 »

PS: Koukám, že zrovna vyšla nová verze SceneBuilderu  Doporučuju na to kouknout https://github.com/gluonhq/scenebuilder https://docs.gluonhq.com/scenebuilder/ https://gluonhq.com/products/scene-builder/

11

Vývoj / Re:Výroba multiplatformní aplikace s GUI v Javě

« kdy: 14. 04. 2021, 16:09:15 »

Taky přidám názor :

Vše závisí pro jakou verzi SE?
-pokud 4,5,6,7,11,12+, pak rozhodně Swing. Starý, odladěný, spousta návodů, stále implementován v JavaSE.
-pokud 8,9,10 pak možná JavaFX

Přestože JavaFX se mi zdá pěknější než Swing, tak například ta FXML mě vůbec nesedla. Radši jsem to programoval vše v kódu. Navíc jak byla v SE11+a odstraněna z JDK, protože se příliš nechytla se to trochu zkomplikovalo. Tím, že jsou knihovny JavaFX plně modulární, tak to dělá problémy u nemodulárních projektů s tvorbou spustitelných jar.(samozřejmě lze to obejít ale práce navíc). Samozřejmě při tvorbě modulárního run-time projektu vše je v pohodě.

Proč to dělení dle verze? Úplně nerozumím. IMHO možná bych akorát zvážil to držet se LTS verzí (Java SE 11).

Jinak mám nemodulární projekty ke kterým si buildím runtime pomocí jdeps a jlink a balím pomoc jpackage a na problém jsem nenarazil. Pokud je runtime standardní s extra instalací javafx, musí se předat javě správné parametry - to je pravda, ale taková specifika mají všechny frameworky a nevidím v tom nic co bych považovat za chybu. Co se týče jpackage, je sice v plenkách, ale pokud nevyhovuje, není problém použít jiný balíčkovací nástroj/instalátor. Neměl bych nic ani proti Swingu, jsou pro něj komponenty, které v javafx chybí, ale ten look and feel mi přijde dnes už hůře obhajitelný. Taky nevím, jak je na tom teď s podporou HiDPI, ale nebylo to nic moc. FXML nemusíte používat, současně jej můžete používat s vlastními komponentami - oboje je výhoda. SceneBuilder a celý postup práce by chtěl sice více dotáhnout, ale použít se to dá.

12

Desktop / Re:Jak vypnout čínské, japonské a další non-latin varianty písma?

« kdy: 14. 04. 2021, 02:02:04 »

Odinstaloval jsem co systém dovolil. A po aktualizaci mi tam zas vše doinstalovali.

Já mám na Manjaru jen pár defaultních non-latin fontů. Třeba Noto jako výchozí nemám, ale pokud by se seznam výchozích nežádoucích fontů rozšířil, tak se tvůj script určitě bude hodit. Díky.

Teď jsem zkoušel ten Font-Downloader a třeba u fontu Noto to nabízí jednotlivé jazyky samostatně a v nastavení lze zaškrtnout, že se má hledat jen Latin. Písma lze stahovat nebo instalovat, akorát nevidím žádnou možnost jak fonty odinstalovat, takže se to bude muset dělat ručně - smazáním *.ttf souboru. Zdá se mi to asi lepší varianta, než instalovat celý balíček Noto se všemi těmi čínskými variantami a pak je ručně vypínat ve Font-manageru nebo mazat.

Ale možná existuje i lepší program než Font-Downloader. To byl jen první co jsem našel.

Občas by se mi také hodilo mít nějaké předvolené sady písem, mezi kterými by šlo system-wide přepínat.

Primitivní možnost je mít v systému jen základní sadu písem a zbytek si instalovat do ~/.fonts a spravovat nějakým skriptem. To je zřejmě to, co dělají někteřé fontmanagery (koukněte na Fontmatrix).

IMHO je to ale komplexnější téma. Asi mimo jiné záleží na software, ve kterém ta písma využíváte a způsobu, jak jsou ty fonty distribuované.

V některých programech si lze filtry předvolit (Scribus...), nějak jinak to zas řeší Xorg, některý software si písma umí načíst i mimo systém (Scribus, možná LibreOffice?)

Koukněte ještě na příkazy fc-* (fc-list, fc-cat, ...) - možná tam najdete něco užitečného k filtrování fontů.

13

Vývoj / Re:Výroba multiplatformní aplikace s GUI v Javě

« kdy: 12. 04. 2021, 20:45:36 »

...a hlavně dotaz zněl na multiplatformní vývoj v javě a tam je odpověď JavaFX zcela validní možnost. Základní charakteristika odpovídá současnému standardu:

• deklarace UI v xml nebo programově v kódu
• automatický nebo ruční binding
• celkem široká paleta GUI prvků
• možnost kombinovat GUI prvky do vlastních komponent (včetně práce s nimi ve SceneBuilderu)
• možnost napojit doménové objekty z business vrstvy
• možnost stylování pomocí css-like stylesheetu (automaticky layout je samozřejmostí)
• další navazující projekty řešící DI, MessageBus apod.

IMHO se to podobá QT (disclaimer: nejsem QT vývojář, QT znám pouze z doslechu).

Nedostatky by se pochopitelně našly taky - víceméně je znát, že JavaFX není zas tak rozšířená, takže některé věci si musí člověk prošlapat sám a něco není standardně dostupné (nenašel jsem např. použitelný docking systém, chybí podpora system tray, ...). Nicméně v době Electron aplikací se ledacos ztratí, takže... 

14

/dev/null / Re:Je to plnohodnotná veřejná adresa?

« kdy: 12. 04. 2021, 18:52:38 »

Třeba u IPSecu je to občas dost bolestivé. Ovšem pokud se takto ptáte, bude vám to nejspíš jedno.

Huh, opravdu? Pokud má někdo problém do left dát 10.1.2.3 a do leftid a leftsubnet 81.82.83.84, tak nemyslím že ho reálná veřejná IP spasí.

Což nic nemění na tom že veřejná ip adresa je terminus technicus a ISP by ji neměl nabízet, pokud umí nabídnout jen NAT. Protože pokud uživatel žije s tím, že má veřejnou IP adresu, nebudou mu pak fungovat příslušné návody na rozběhání služeb apod.

15

Software / Re:Aký softvér na správu tímových projektov?

« kdy: 09. 04. 2021, 16:52:52 »

V práci máme Redmine a je to fajn.
Na soukromé věci používám https://gitea.io

Dík za odkaz na Gitea, to vypadá super použitelně.

Redmine mi přijde dost neohrabaný s předpotopním rozhraním, chtělo by to něco elegantnějšího.