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

Stran: [1] 2 3 ... 99
1
Vývoj / Re:Discriminated unions v C++
« kdy: 24. 10. 2020, 14:17:30 »
C++ baví z viacerých dôvodov (je univerzálne, je rozšírené, dá sa tam hrať z detailami a optimalizovať, je to hlavný jazyk pre Unreal Engine, je to jazyk orientovaný na rýchlosť, nič pred programátorom neskrýva atď).

Řekl bych, že o Rustu to všechno platí taky až na "rozšířené" (to se doufám změní :-) a "hlavní jazyk pro Unreal Engine" (to chápu, že může být blocker). Ale nechci ho nikomu vnucovat.

Naprosto souhlas.

IMHO Rust sestřelil C na úroveň udržovacího legaci kódu. Má všechny výhody C a málo z jeho nevýhod.

2
Kotlin, Haskell

Na to, zda se učit Haskell mám rozporuplné pocity. Sice se naučíš a pochopíš spousta věcí z programování, jenže... Já třeba teď dělám v C# a furt zakopávám o to, že se samozřejmostí očekávám věci, které C# prostě neumí. Typové varianty, gradual typing, a tak.

3
O serveru Root.cz / Re:placené odběry
« kdy: 22. 10. 2020, 15:50:29 »
Teda, říkám si, chtěl bych mít Krčmářovi nervy. Dělat fórum pro tyhle lidi... by mě kleplo.

4
Vývoj / Re:Bootstrap: počet prvků na řádek
« kdy: 11. 10. 2020, 00:42:58 »
Nepoužij row. Vytvoř si box, do kterého budeš umisťovat prvky, které budeš pozicovat pomocí flex pravidel. Baj vočko, dle ukázky, by si mohl zkusit použít jako základ pro prvek karty (cards) - ale to není podstatné. Zajímá tě to nepoužití bootstrap row, a použít css vlastnosti flex.

5
Software / Zálohovací nástroj
« kdy: 11. 10. 2020, 00:35:37 »
Zdravím.

Můžete prosím doporučit nějaký šikovný zálohovací nástroj/systém (linux, debian, příkazová řádka).

Moje představa je, že si zaregistruju v cronu, že se má každý den zálohovat tato a tato databáze, tento a tento adresář, připojit disk, překopírovat, odpojit disk. (Zatím neuvažuju rozdílové zálohy - teď jsem se s nimi dost spálil, takže snad jindy.)

Vypadá to celkem jednoduše, takže by to mohl být triviální script. Ale třeba existuje nějaké už hotové řešení, které by bylo lepší než co si ubastlím sám.

Díky za podněty.

6
Vývoj / Re:Typový system versus unittesty
« kdy: 16. 09. 2020, 00:55:07 »
Před pár dny jsem narazil na indexikální typy a vzpomněl si, že tebe typové systémy a intuicionistická logika zajímají, tak jen dávám tip ;) Je to něco jako “this”, ale na úrovni typů. Jdou skrz to implementovat higher-kinded typy v systému prvního řádu (bez explicitních HKT), takže ve výsledku je takový systém formálně silnější (a kompatibilní s dědičností).
Díky. Jsem rád za každý hint.
Nějaký odkaz, článek, by nebyl?
Takhle z hlavy mě napadá jen dokumentace ke Swiftu, zejména použití Self a jeho spojení s asociovanými typy. Teď zrovna nemám na nic čas, ale za pár dnů k tomu můžu něco napsat tady.

To by bylo super. Na Swift se podívám. Já hledal obecně, a našel jen něco pro TypeScript, ale to odhadem je něco jiného stejného jména.

7
Vývoj / Re:Nový projekt vs. cizí kód
« kdy: 14. 09. 2020, 19:18:38 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.
No architekturně mi přijde, že je to hodně neočekávané chování databáze. Databáze je úložiště, které obsluhuje požadavky. Od PL/SQL věcí bych čekal, že budou nějak přežvykovat data v rámci té databáze.

Kdybych hledal místo, kde se rozesílají notifikace nebo přeposílají data, tak je databáze jedno z posledních míst, kam bych se díval.
Vzhledem k návrhu aplikace, jak tu byla popsána nemohu souhlasit.

8
Vývoj / Re:Nový projekt vs. cizí kód
« kdy: 14. 09. 2020, 19:17:31 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ok, asi se pouštím  na tenký led (protože jsem ovlivněný tím, že dělám "vícevrstvé" aplikace, kde business logiku mám v aplikační vrstvě a db je prostě úložiště a tím, že PL/SQL tolik neznám), ale nepřišla mi databáze zrovna na tohle ideální nástroj.

Už jen ta SOAP/HTTP komunikace byla hodně low-level, přes nějaký utility balík se ručně skládal request (hlavičky, xml skládání ze stringů atd. (xml injection? ;-))), co by asi šlo abstrahovat a zapouzdřit do nějaké šablony, ale to se nestalo a tak se boiler-plate kód táhnul těmi procedurami... možná že existují nějaké pokročilejší tooly a jde to řešit elegantně, ale nevím. Také se mi nelíbilo, z pohledu architektury, že stejná db instance, která řeší úložiště dat, řeší i složitou business logiku zahrnující cally na web servisy.. (blokující a dlouho trvající). Také ta aplikace měla problémy s performance, ale jestli to bylo zrovna kvůli tomuhle, nevím.

Takže škálování a udržovatelnost. Když otočím otázku, proč to mít v databázi?
Když máš dvě vrstvy a ta druhá je prezentační...

Jako já vůbec neřeším, zda takto dvojvrstvá aplikace je dobrej nápad (dokonce by i mohl).
Určitě by bylo vhodnější udělat ten SOAP a posílání mailů jako nějakou service, etc. Protože otestování, a tak. Ale nakonec by to stejně skončilo v db, protože posílání mailu i SOAP je práce s daty.

Čímž nijak nezpochybňuji, že ten kód musel být hroznej. Ono, někdy jdou věci dělat velmi netradičně a přitom vlastně dobře. Pokud k tomu přistupuje dotyčný s tou ideou a nesnaží se jít proti ní, protože tak se to přeci nedělá.

9
Vývoj / Re:Nový projekt vs. cizí kód
« kdy: 14. 09. 2020, 15:43:08 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ptal jsem se z pohledu architektury, nikoliv z pohledu zvolené technologie. Viz kontext jeho příspěvku.

10
Vývoj / Re:Typový system versus unittesty
« kdy: 14. 09. 2020, 14:47:44 »
Před pár dny jsem narazil na indexikální typy a vzpomněl si, že tebe typové systémy a intuicionistická logika zajímají, tak jen dávám tip ;) Je to něco jako “this”, ale na úrovni typů. Jdou skrz to implementovat higher-kinded typy v systému prvního řádu (bez explicitních HKT), takže ve výsledku je takový systém formálně silnější (a kompatibilní s dědičností).

Díky. Jsem rád za každý hint.
Nějaký odkaz, článek, by nebyl?

11
Vývoj / Re:Nový projekt vs. cizí kód
« kdy: 14. 09. 2020, 14:45:55 »
Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.
V čem vidíš zrovna v tomto problém?

12
Vývoj / Re:Modifikovatelné UI/GUI - c++
« kdy: 13. 09. 2020, 23:13:23 »
3/ neumí svižné aplikace, kde záleží na rychlosti odezvy UI
z me zkusenosti jdou problemy s vykonem weboveho frontendu vzdy vyresit, urcite neni treba psat celou aplikaci v nejake exoticke limitujici technologii, kvuli male vykonove kriticke casti.
Já tu zkušenost nemám. Mě přijde, že všechny engine běžící na html jsou nenažraný bumbrlíci, a ta svižnost UI je prostě webová.

za to vetsinou muzou reklamy

Může být. Já jsem jen chtěl poukázat, a myslím, že se mi to celkem povedlo, že ta exotická limitující technologie je spíše HTML než co jiného.

13
Vývoj / Re:Modifikovatelné UI/GUI - c++
« kdy: 13. 09. 2020, 20:23:30 »
Co konkretne HTML neumi oproti tem alternativam, ktere tu navrhujete?

1/ neumí nativní look&feel
podle me takova UI technologie neexistuje, ktera by vypadala nativne vsude,
wxWidget, yue, jenom z těch co znám.

lepsi je ladit jeden vzhled pro konkretni aplikaci, nez X ruznych vzhledu pro ruzna prostredi

2/ neumí lehké nenáročné aplikace nenáročné na zdroje paměti a procesoru
no to je dan za flexibilitu, na dnesnich desktopovych pocitacich to neni problem, mozna na starsich mobilech
O tom nediskutuji. Já jsem jen odpovídal na otázku, co konkrétně HTML neumí. Zda to za to stojí je úplně jiná otázka.

3/ neumí svižné aplikace, kde záleží na rychlosti odezvy UI
z me zkusenosti jdou problemy s vykonem weboveho frontendu vzdy vyresit, urcite neni treba psat celou aplikaci v nejake exoticke limitujici technologii, kvuli male vykonove kriticke casti.
Já tu zkušenost nemám. Mě přijde, že všechny engine běžící na html jsou nenažraný bumbrlíci, a ta svižnost UI je prostě webová.

14
Vývoj / Re:Modifikovatelné UI/GUI - c++
« kdy: 13. 09. 2020, 16:39:06 »
Co konkretne HTML neumi oproti tem alternativam, ktere tu navrhujete?

1/ neumí nativní look&feel
2/ neumí lehké nenáročné aplikace nenáročné na zdroje paměti a procesoru
3/ neumí svižné aplikace, kde záleží na rychlosti odezvy UI

15
Vývoj / Re:Modifikovatelné UI/GUI - c++
« kdy: 13. 09. 2020, 16:32:40 »
Co konkretne HTML neumi oproti tem alternativam, ktere tu navrhujete? Pro pouziti nejake malo rozsirene technologie by mel existovat dobry duvod, protoze si tim v kazdem pripade pridelate spoustu problemu.

Nejde o to, že by HTML něco neumělo. Ta formulace je výstižná "zjistí, že technologicky to tak velká výhra není".

Stejně tak souhlasím s tím, že zásadní (a možná jediná) výhoda HTML je "možnost běhu aplikace v prohlížeči a množství dostupných vývojářů".

Stran: [1] 2 3 ... 99