Příspěvky

211

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

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

Pozoruhodné... 

212

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.

213

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

214

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

215

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

216

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/

217

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

218

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

219

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

220

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

221

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.

222

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

« kdy: 09. 04. 2021, 16:44:41 »

JavaFX je dobře navržená platforma a nepřijde mi zas tak mrtvá. Akorát by mohla být rozšířenější a s větší komunitou, to ano. Bohužel, dnes vše běží v prohlížeči a vyvíjí se v javascriptu nebo transpilovaných jazycích. Ale IMHO se to kyvadlo pomalu překlopí a bude se víc vyvíjet pro desktop, byť s cloudem někde na pozadí. Já si myslím že se oba přístupy (desktop vs. browser) obohacují, takže v tom nevidím moc problém. Chtělo by to dotáhnout ty hybridní platformy jako je Electron - on se deploy javafx aplikace s přibalenou javou nápadně podobá Elektron aplikacím co se týče velikosti, nároků a nedostatků. Takže jde o systémový problém. V případě javy s tím může ještě docela pohnout GraalVM, v případě browseru WASM.

223

Vývoj / Re:Používá někdo cloudové IDE?

« kdy: 08. 04. 2021, 19:29:34 »

V rozumné firmě nechají pracovat vývojáře pomocí nástrojů, které vyhovují jemu. Kontrolují pak jen výstupy, pochopitelně včetně dodržení firemních postupů (správa kódu, dokumentace, testování...).

Eclipse Che a podobné nemusí být k zahození, protože umožní oddělit runtime a pracovat vzdáleně. Ale vůbec nemusí jít jen o „cloud“, ale třeba o ladění aplikace v jiném běhovém prostředí, například. Takže úvaha, že jde o kladivo na vývojáře, mi přijde totálně mimo.

224

Software / Re:Jakou aplikaci na psaní poznámek?

« kdy: 08. 04. 2021, 19:19:07 »

Používám ZIM, který interně používá DokuWiki syntax a adresářovou strukturu. Obrázky, soubory, vkládání kódu se zvýrazněním syntaxe atd. funguje. Není to dokonalé, ale použitelné ano. Vzhledem k úložišti je možné snadno verzovat gitem případně zahrnout přímo do projektu. Umí spustit interní http server, takže pak funguje i jako jednoduchá webstránka.

Na editaci samotných markdown nebo reStructuredText souborů používám ReText. Opět docela použitelný, hodí se export do html a pdf.

225

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

« kdy: 08. 04. 2021, 19:07:04 »

Stejné jako provoz jiného software, tj. hlavně nutnost aktualizací? Ale to se týká právě každého software, takže jako argument to je celkem k ničemu. Javu bych v daném případě přibalil k programu a prostě vydával aktualizované verze programu i při vydání nové verze javy. Protože autor by měl stejně svůj program testovat vůči novým verzím javy, tedy pokud chce držet aktuálnost a funkčnost (a to bez rozdílu na tom, jak se ta java do pc uživatele dostane). Takže pak už není tolik práce navíc vydat nový aktualizovaný balíček.