Příspěvky

511

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.

512

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.

513

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.

514

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

515

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.

516

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?

517

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?

518

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.

519

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

520

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

521

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ářů".

522

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 13. 09. 2020, 01:45:03 »

Ja teda nevim, kolik jste kdo za svuj zivot prebiraly projektu ja par jo a muzu vam rict ze je to vzdy nocni mura. Jednou jsem treba dostal za ukol "doladit" program po slavnych Andersen Consulting ( docela znama "
banda nachytrovacu"  kolem roku 2000 ). Byl to nejaky reportovaci system napsany v pro*c, bezici nad oracle db pod hp-uxem. Moc dobre se cisti kod, ktery bezi 16hodin nez to slitne na core dump. Vy na to kouknete, je vam jasny proc to slitlo ale vite ze pricina je ukryta nekde jinde a tak tu chybu huntite nekolik dni. A takovych chutovek jsem za svoji karieru par resil a muzu vam rict, never more. Proste nejsem genius abych se kouknul a hned mi bylo vsechno jasne, jak vsem tady ve vlaknu :-) a vedl tady filosoficke debaty o refactoringu, ucesani api, pridani webove sluzby a zvyseni vykonu odladenim a to vsechno behem 10ti minut :-).

No, a pak přijdu já, a řeknu, ok, tak já vám to udělám. Ale samozřejmě to nebude hned. Pochopitelně to nebudu dělat deset minut. Já totiž žádný génius nejsem. Ale pár zkušeností mám, a když to zákazník chce, a chce to zaplatit, tak fajn.

523

Vývoj / Re:Modifikovatelné UI/GUI - c++

« kdy: 12. 09. 2020, 20:59:37 »

Tak záleží co autor dotazu plánuje budoucí rok dělat - jestli implementovat nějakou vlastní vrstvu nad Qt/Gtk/JavaFX/Pharo/(cokoliv dalšího co tu někdo zmíní), která by mu umožnila to co chce (tedy vytvoření UI uživatelem pro nějaký plugin/mod system) a nebo prostě sáhnout po něčem hotovém a řešit tu samotnou hru Opravdu mi přijde nejjednodušší to HTML - nedokážu si představit use-case, na který by to nestačilo, a zkušenosti tím získané pak může aplikovat u dalších projektů.

S tou první myšlenkou určitě souhlasím - rozhodně je lepší, když zvolí už nějakou hotovou platformu na hry (třeba Unity, nebo tak, bohužel nemám v tom přehled), než si to dělat sám.

Ale proč by měl použít zrovna HTML, to mi tak nějak nedochází, a už vůbec ne proč by to měla být platforma na hry.

524

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 12. 09. 2020, 00:20:13 »

Nicmene si myslim, ze i kdyz sednu do rozjeteho vlaku tak porad tvurci byt muzu. A ne mene nez u neceho na cem se zacina.

Jasně. Ale je to více přehrabování se ve špíně. Zatímco když děláš něco nového, tak jen tvoříš. Asi jako rozdíl mezi kuchařem a umývačkou. I umývačka může být kreativní a efektivní. A rozhodně velice užitečná, až nutná. Ale přeci jen to není vono.

Tahle analogie nesedi.
Cilem kuchare je pripravit pro zakaznika jidlo...
Cilem umyvace je pripravit pro kuchare prazdnej talir aby ho mel kam dat.

Cilem programatora obvykle neni vytvorit prazdny repozitar. (Jen v pripade, ze se na projektu zacina ;-))

To přirovnání je naopak velice přesné. Refactoringem nic nového nepřipravuješ. Konfigurací CI nevytváříš žádnou zvláštní hodnotu. Určitě ne produkt. Nenene, to přirovnání považuji za velice výstižné.

Refactoring se pri novem vyvoji nedela?

Dělá. Což nic nemění na skutečnosti, že refactoring obvykle není moc tvůrčí/zábavný, etc.

Na druhou stranu, já třeba mám ten pocit ozdravování celkem rád, našel jsem se v tom.

Jsou to prostě dva naprosto různé pocity: Možnost odejít z kuchyně, která je vyfintěná; nebo položit na stůl voňavou večeři. Vyřešit a rozmotat špagety, a vyhodit z kódu špatné věci, pročistit a učesat API, zrychlit kód; versus adoptovat novou webovou službu na stávající api, kdy vám všechno krásně hraje do noty, všechno přesně zapadá, pomocí pár řádek kódu.

525

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 11. 09. 2020, 21:54:38 »

Nicmene si myslim, ze i kdyz sednu do rozjeteho vlaku tak porad tvurci byt muzu. A ne mene nez u neceho na cem se zacina.

Jasně. Ale je to více přehrabování se ve špíně. Zatímco když děláš něco nového, tak jen tvoříš. Asi jako rozdíl mezi kuchařem a umývačkou. I umývačka může být kreativní a efektivní. A rozhodně velice užitečná, až nutná. Ale přeci jen to není vono.

Tahle analogie nesedi.
Cilem kuchare je pripravit pro zakaznika jidlo...
Cilem umyvace je pripravit pro kuchare prazdnej talir aby ho mel kam dat.

Cilem programatora obvykle neni vytvorit prazdny repozitar. (Jen v pripade, ze se na projektu zacina ;-))

To přirovnání je naopak velice přesné. Refactoringem nic nového nepřipravuješ. Konfigurací CI nevytváříš žádnou zvláštní hodnotu. Určitě ne produkt. Nenene, to přirovnání považuji za velice výstižné.