1
Vývoj / Re:Typescript module vs namespace
« kdy: 14. 10. 2025, 16:23:30 »
ale už sa k tejto téme nejdem vyjadrovať odpoveď na nastavenie tslintu som sa nedozvedel, ale už vidím že sa tu schyluje ku flame a na to fakt nemám čas.
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.
2
Vývoj / Re:Typescript module vs namespace
« kdy: 14. 10. 2025, 16:19:26 »Termín "module" už má v ECMAScript-e svoj význam a TypeScript ho len rešpektuje (t.j. ES6 prípadne CommojJS modules). Preto sa táto ďalšia/iná vlastnosť volá "namespace" a príde mi to ako technicky presné pomenovanie.CitaceKaždopádne v TS je modul synonimum pre namespace
Nie je, sú to dve odlišné veci. Možno ťa mýli, že pred dávnymi rokmi sa terminológia TypeScript-u trochu líšia, ale to je fakt dávno.Citacev iných jazykoch je NS čisto len menný priestor (C++, C#).
Takto ho vnímam aj v TypeScript-e.CitaceA modul je skutočne element jazyka, ktorý sa stará aj o viditelnosť (exporty) taktiež modul môže byť v jednom súbore len jeden zato namespace môže byť rozdelený do viac súborov.
Takto to v TypeScript-e je.
Ale možno mi len niečo uniká, namespaces vôbec nevyužívam.
v TS nie su odlisne. Ale semanticky je to nezmysel.
>> Takto ho vnímam aj v TypeScript-e.
menný priestor nemá riešiť viditelnosť (exporty), a má byť možné ho definovať vo viacerých súboroch. namespace v TS neni možné definovať vo viacerých súboroch a obsahuje exporty, teda to neni skutočný menný priestor ale modul. TS skutočné menné priestory neobsahuje obsahuje len moduly pomenované menný priestor.
keď si trabant microsoft premnuje na lambo tak stále to bude trabant a nie lambo
3
Vývoj / Typescript module vs namespace
« kdy: 12. 10. 2025, 20:16:32 »
VSCode resp tslint mi zakazuje používať keyword module. Pritom celé JS / TS je o moduloch. Nameisto modulu mi to vnucuje keyword namespace.
Každopádne v TS je modul synonimum pre namespace (čo je úplná absurdita vymyslená Microsoftom), v iných jazykoch je NS čisto len menný priestor (C++, C#).
A modul je skutočne element jazyka, ktorý sa stará aj o viditelnosť (exporty) taktiež modul môže byť v jednom súbore len jeden zato namespace môže byť rozdelený do viac súborov.
Potom sú jazyky ktoré majú aj moduly s parametrickým polymorfizmom, ale to teraz nejdem riešiť. Proste modul má bližšie k static class ako ku namespace. Z tohto pohľadu ide v TS o moduly a skutočné namespaces TS ani JS nemá. Inými slovami chcem používať kľúčové slovo module. Ako to mám povoliť? Tipy od AI nefungujú.
Každopádne v TS je modul synonimum pre namespace (čo je úplná absurdita vymyslená Microsoftom), v iných jazykoch je NS čisto len menný priestor (C++, C#).
A modul je skutočne element jazyka, ktorý sa stará aj o viditelnosť (exporty) taktiež modul môže byť v jednom súbore len jeden zato namespace môže byť rozdelený do viac súborov.
Potom sú jazyky ktoré majú aj moduly s parametrickým polymorfizmom, ale to teraz nejdem riešiť. Proste modul má bližšie k static class ako ku namespace. Z tohto pohľadu ide v TS o moduly a skutočné namespaces TS ani JS nemá. Inými slovami chcem používať kľúčové slovo module. Ako to mám povoliť? Tipy od AI nefungujú.
4
Vývoj / Re:.NET F# SQLProvider - leftOuterJoin
« kdy: 22. 09. 2025, 22:45:23 »Používá se kombinace join ... into a DefaultIfEmpty().
Hej presne, ten druhy pripad. zial SQLProvider ho nepodporuje.
Ale uz som sa zbavil SQLProvidera nebudem pouzivat taketo obskurne knniznice. Boli s nim aj ine problemy. Napriklad ze connectionString cital z Web.config ktory uz ale nova verzia ASP.NET Core nahradila appstettings.json
Nakoniec som pouzil normalny EntityFrameworkCore, sice teraz tam mam este dalsi medzikrok a po zmenach v DB musim generovat entity, ale aspon pouzivam dobre odtesovanu kniznicu a nie nejaky one man show.
5
Vývoj / .NET F# SQLProvider - leftOuterJoin
« kdy: 22. 09. 2025, 16:56:24 »
Ahojte pouzivam v jednej F# appke SQLProvider
https://fsprojects.github.io/SQLProvider/
na pristup k DB. Funguje to krasne a mozem zapisovat dotazy priamo v jazyku F# co je fajn, lebo nemusim nic escapovat a mam to pekne v jednom jazyku (F#). Klasicky (inner) join sa robi takto:
ale ako zapisat leftOuterJoin? LINQ pre F# normalne podporuje keyword leftOuterJoin, ale zda sa ze SQL Provider pre MS SQL ma s tymto zapisom problem. Skusal som toto:
A hadze mi to runtime error:
Ako sa teda zapisuje leftOuterJoin pre SQL Provider? Ci mam v DB spravit View a az na ten sa dotazovat? Ale nechce sa mi verit ze by SQL Provider leftOuterJoin a rightOuterJoin nepodporoval. Ved to je uplne zakladna vec pre kazdu DB.
https://fsprojects.github.io/SQLProvider/
na pristup k DB. Funguje to krasne a mozem zapisovat dotazy priamo v jazyku F# co je fajn, lebo nemusim nic escapovat a mam to pekne v jednom jazyku (F#). Klasicky (inner) join sa robi takto:
Kód: [Vybrat]
query {
for country in dc.Dbo.Countries do
where country.IsEnabled
join city in dc.Dbo.Cities on (country.Id = city.CountryId)
sortBy country.Name
thenBy city.Name
select (country.Id, country.Name, city.Id, city.Name, city.IsCapital)
}ale ako zapisat leftOuterJoin? LINQ pre F# normalne podporuje keyword leftOuterJoin, ale zda sa ze SQL Provider pre MS SQL ma s tymto zapisom problem. Skusal som toto:
Kód: [Vybrat]
query {
for country in dc.Dbo.Countries do
where country.IsEnabled
leftOuterJoin city in dc.Dbo.Cities on (country.Id = city.CountryId) into cities'
for city' in cities'.DefaultIfEmpty() do
sortBy country.Name
thenBy city'.Name
select (country.Id, country.Name, city'.Id, city'.Name, city'.IsCapital)
}
A hadze mi to runtime error:
Kód: [Vybrat]
System.Exception: 'unrecognised method call value(FSharp.Data.Sql.Runtime.QueryImplementation+SqlQueryable`1[FSharp.Data.Sql.Common.SqlEntity]).GroupJoin(value(FSharp.Data.Sql.Runtime.QueryImplementation+SqlQueryable`1[FSharp.Data.Sql.Common.SqlEntity]), country => country.GetColumn("Id"), city => city.GetColumn("CountryId"), (country, cities') => new AnonymousObject`2(Item1 = country, Item2 = cities'.DefaultIfEmpty()))'Ako sa teda zapisuje leftOuterJoin pre SQL Provider? Ci mam v DB spravit View a az na ten sa dotazovat? Ale nechce sa mi verit ze by SQL Provider leftOuterJoin a rightOuterJoin nepodporoval. Ved to je uplne zakladna vec pre kazdu DB.
6
Vývoj / Re:Konfiguračný formát: *.conf
« kdy: 30. 07. 2025, 11:57:10 »rc.conf je sh skript, loader.conf umí jen přiřazení hodnot se syntaxí kompatibilní se sh, jail.conf je interní formát jailu. Ke všem třem jsou manuálové stránky a ke všemu ve FreeBSD jsou zdrojáky.
aha tak to je kazde iny format? ja som myslel ze to je jeden univerzalny, len ohnuty pre konkretne potreby kazdej aplikacie. Tak asi sa tymi konfigmi inspirujem a spravim nejaky format ktory bude podporovat veci ktore vidim napriec vacsinou konfigurakov roznych aplikacii. lebo fakt mi ta syntax pride citatelnejsia ako nejake TOML
7
Vývoj / Konfiguračný formát: *.conf
« kdy: 30. 07. 2025, 00:32:05 »
Ahojte vo freebsd je pekný, prehľadný a funkciami nabitý formát konfiguračných súborov s koncovkou *.conf (rc.conf, loader.conf, jails.conf atď).
Podľa mňa je tento formát oveľa čitateľnejší ako nejaké toml, ini, yaml, xml atď. Taktiež je výborne štrukurovaný a má bohaté možnosti aké som v iných formátoch nevidel. Ale čo to je vlastne za formát? Má nejakú špecifikáciu? Dá sa k nemu zohnať parser?
Podľa mňa je tento formát oveľa čitateľnejší ako nejaké toml, ini, yaml, xml atď. Taktiež je výborne štrukurovaný a má bohaté možnosti aké som v iných formátoch nevidel. Ale čo to je vlastne za formát? Má nejakú špecifikáciu? Dá sa k nemu zohnať parser?
8
Software / Tlač na rôzne druhy textilu - software na design
« kdy: 06. 03. 2025, 20:58:36 »
Ahojte viete poradiť nejaký software určený na návrh potlače už hotových textílií?
Boli mi poradený NedGraphics a C-Design Fashion. Zatiaľ to pozerám len chvíľu, ale už na prvý pohľad mi udrelo do očí, že nikde neni cena produktu. Nehovoriac o tom, že asi by som sa do toho softwaru musel zaškoliť čo ma bude stáť veľa času a peňazí, školenia na to asi nie sú bežne dostupné, takže asi bude lepšie vybrať menej špecializovaný SW.
Z klasických softwarov mi AI doporučila Blender. Myslíte že je to dobrý nápad naučiť sa Blender aspoň na základnej úrovni a potom si potlač navrhovať cez tento software?
Predstavujem si to tak že by som kúpil 3D scanner a vybral gildan oblečenia ktorý chcem potlačiť (nohavice, triko, košeľa, kabát, mikina) a ten by som nascanoval ako 3D model a potom by som v illustratore + mozno obcas photoshope vytvoril nejaký vektor a ten by som preniesol ako textúru na ten 3D model. Samozrejme sú rôzne techniky tlače či tvorby nášivok, to ale teraz neriešme, najprv chcem pochopiť základný proces výroby potlače oblečenia a potom budem pridávať rôzne ďalšie techniky, prípadne aj tvorbu strihov atď.
mimochodom blender vraj dokáže aj simulovať rôzne druhy látok.
Boli mi poradený NedGraphics a C-Design Fashion. Zatiaľ to pozerám len chvíľu, ale už na prvý pohľad mi udrelo do očí, že nikde neni cena produktu. Nehovoriac o tom, že asi by som sa do toho softwaru musel zaškoliť čo ma bude stáť veľa času a peňazí, školenia na to asi nie sú bežne dostupné, takže asi bude lepšie vybrať menej špecializovaný SW.
Z klasických softwarov mi AI doporučila Blender. Myslíte že je to dobrý nápad naučiť sa Blender aspoň na základnej úrovni a potom si potlač navrhovať cez tento software?
Predstavujem si to tak že by som kúpil 3D scanner a vybral gildan oblečenia ktorý chcem potlačiť (nohavice, triko, košeľa, kabát, mikina) a ten by som nascanoval ako 3D model a potom by som v illustratore + mozno obcas photoshope vytvoril nejaký vektor a ten by som preniesol ako textúru na ten 3D model. Samozrejme sú rôzne techniky tlače či tvorby nášivok, to ale teraz neriešme, najprv chcem pochopiť základný proces výroby potlače oblečenia a potom budem pridávať rôzne ďalšie techniky, prípadne aj tvorbu strihov atď.
mimochodom blender vraj dokáže aj simulovať rôzne druhy látok.
9
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 07. 02. 2025, 15:13:52 »V TypeScript-e som takéto reflexie nikdy nepotreboval. Veci tam do seba pekne zapadajú už v compile time vďaka vlastnostiam ako discriminated unions alebo type predicates.
Uf brzdi to nekritické nadšenie, všetko má svoje plusy aj mínusy, nechápem ľudí ktorí sa tie mínusy snažia nevidieť. To, že si niečo nepotreboval neznamená, že to nepotrebujú ostatní. Tu ide o to aby som ten typ dal zistiť a checkovať rovnako v compile time ako aj v runtime (tak ako to umožňujú skoro všetky hi level kompilované jazyky). Lebo dajme tomu mame funkciu:
Kód: [Vybrat]
type LedColour = 'red' | 'green' | 'blue';
function lightUpTheLed(color: LedColour) {
...
}
lightUpTheLed("yellow"); // tu mi kompilator vyhodi chybu
const ledColour = await (await fetch('/api/get-color')).json<LedColour>(); // vrati "yellow"
lightUpTheLed(ledColour); v poslednom riadku mi hodnota "yellow" prejde a celé sa mi to zosype až v tele funkcie, nevyskočí mi žiadna exception o nesprávnom type argumentu, runtime nevie kde nastala chyba - IDE mi neoznačí argument funkcie ako chybový. Načo je potom taký deravý typing? Ako pomáha to, ale často tá schýza vedie skôr k pocitu falošného bezpečnia.
Potom keď chcem napísať ORM framework, service kontainer, alebo validovať restové apiny, tak sú mi typescriptové typy na dve veci. A potom vznikajú projekty ako https://github.com/gcanti/io-ts Kde si type checker píšem v novom DSL, nestačí mi na to jeden jazyk (typescript) potrebujem extra DSL s novou syntaxou zápisu typov, ktorý pokrýva len malú podmnožinu typingu TS, aby javascript runtime konečne rozumelo tomu istému čo som už raz vyjadril v TS.
Môj názor je presne opačný - ak potrebujem reflexie, aby som v runtime zistil typ objektu, tak je to nedostatok daného jazyka (prípadne nevhodný návrh kódu). TypeScript je pre mňa dôkaz, že sa to dá urobiť bez reflexií, jednoducho, čitateľne a v compile time.
píšeš to ako keby reflexia bolo niečo desivé:
Kód: [Vybrat]
var text = "ABC";
text.GetType().Name // vrati nazov typu premennej "text" ako "string";Je na tomto niečo desivé? Nehovoriac o tom, že tú reflexiu / introspekciu najčastejšie používa priamo runtime keď ťa upozorní na chybu. Málokedy narazíš na situácie keď sa musíš na typy dopytovať sám (aj keď občas sa to hodí).
10
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 02. 02. 2025, 22:52:43 »Proč se cpe JavaScript na backend?
pretože isomorfné aplikácie umožňujú zdielať jeden kód medzi frontendom a backendom. takže môžem rovnaké triedy, funkcie a libky používať na frontende aj backende.
11
Vývoj / Re:Proč se cpe JavaScript na backend?
« kdy: 02. 02. 2025, 22:41:48 »Za 20 rokov som si prešiel asi všetkými mainstreamovými jazykmi a TypeScript je môj obľúbenec [*1] Nepoznám žiadny iný jazyk, ktorý by mal takú vyjadrovaciu schopnosť čo do typov [*2] A od typovej bezpečnosti sa potom odvíja veľa ďalších vecí.
Statický typing v TS je fajn, sám ho obľubujem, avšak funguje len v compile-time, naopak runtime typescriptovým typom nerozumie nedá sa s typescriptovými typmi pracovať za behu napr pomocou reflexie, takže pri programovaní cítim , že ten strong typing je len umelo dolepený na inak veľmi weak typed jazyk. Ešte som sa nestretol v inom jazyku s takou veľkou schyzofréniou ako pri TS. A toto je obrovský nedostatok. Aj keď uznávam že iná možnosť ako dolepiť typy na JS ani nebola. Dnes už naštastie existujú technológie ako Blazor a Bolero postavené nad WASM a tam už je prítomný plnohodnotný staticko-dynamický typing.
Čo sa týka vyjadrovacej schopnosti také C++ 23 je ešte dalej (aj keď uznávam že tu trošku porovnávam hrušky s jablkami). C++ má ďaleko pokročilejší typový systém. TS generics sú oproti C++ templatom (halvne v oblasti metaprogramovania) len vtip, ale pre širokú komunitu vývojárov sú na druhej strane generics ľahšie na pochopenie a naučenie. Takže všetko má svoje pre a proti.
12
Server / Ovládání VPS s FreeBSD
« kdy: 05. 01. 2025, 14:43:52 »
Ahojte doteraz som mal Windows VPS u Forpsi. Všetko som si administroval sám cez RemoteDesktop, ale nakolko už mám aké také skúseností s FreeBSD na desktope premýšlam či neprejsť na iné VPS s FreeBSD, s tým že ak by som potreboval spustiť Windows veci napr .NET aplikáciu tak by som si vo virtualizovanom FreeBSD rozbehal ešte bhyve a tam nahodil Windows.
Otázka je ako Unixové VPS fungujú? Tiež sa to administruje cez GUI (napr vzdialeny pristup do KDE na serveri cez RDP) (VNC nechcem)? Alebo sa to zvykne riešiť cez textový terminál? Možno sú tie moje otázky pritiahnuté za vlasy ale fakt nie som server admin ale len BFU, doteraz vždy som na serveri používal len Windows Server, a popravde ak to mám administrovať na dialku cez textový terminál tak to radšej ostanem pri Windowse. Terminál sice používam ale úplne bez GUI by som fungovať asi nedokázal.
Otázka je ako Unixové VPS fungujú? Tiež sa to administruje cez GUI (napr vzdialeny pristup do KDE na serveri cez RDP) (VNC nechcem)? Alebo sa to zvykne riešiť cez textový terminál? Možno sú tie moje otázky pritiahnuté za vlasy ale fakt nie som server admin ale len BFU, doteraz vždy som na serveri používal len Windows Server, a popravde ak to mám administrovať na dialku cez textový terminál tak to radšej ostanem pri Windowse. Terminál sice používam ale úplne bez GUI by som fungovať asi nedokázal.
13
/dev/null / Kde neon neodporucam
« kdy: 07. 11. 2024, 19:44:06 »
Nainštaloval som si distro KDE neon. Je to ubuntu s KDE. Áno má to nový SW a najnovšie KDE čo je asi jediná výhoda. Inak to ubuntu premenované na KDE neon je divné. Všetko sa tam robí inak ako v ostatných linuxoch / unixoch. Aj update / upgrade sa robí inak.
Inak NVIDIA grafika je pomalá, a KDE je také nie úplne plynulé čo je na 16/32 jadrovom stroji s RTX4070 12GB trošku záhada. Systém mi ponúkol upgrade na novšiu verziu, po upgrade sa začali diať veci... najprv to pridalo ďalší nový spúštací oddiel, ten pôvodný nezmazalo, ale pôvodný nefunguje. Po upgrade na novšiu verziu mi nabehlo nejaké ultra nízke rozlíšenie pritom mám 4K monitor. Neviem či to bolo 1920x1080 ale pripomenulo mi to doby keď bol štandard 640x480
Mám KDE aj v vo FreeBSD 14.1 a tam je naopak všetko rýchle. Na žiadne problémy som nenarazil nepoznám stabilnejší systém. Síce tam neni KDE 6 ale KDE 5+ ale inak je to superrýchle dokonca mi tam bežia rýchlejšie aj linuxové binárky a linuxové aplikacie pre GUI (cez vrstvu linuxulator).
Takže asi popri FreeBSD nainštalujerm znovu arch, alebo Kali linux ktorý síce slúži na penetračné testy ale čo tam po tom. Vo Windowsovom WSL mi to funguje dobre, tak skúsim aj normálnu inštaláciu Kali linuxu.
Inak NVIDIA grafika je pomalá, a KDE je také nie úplne plynulé čo je na 16/32 jadrovom stroji s RTX4070 12GB trošku záhada. Systém mi ponúkol upgrade na novšiu verziu, po upgrade sa začali diať veci... najprv to pridalo ďalší nový spúštací oddiel, ten pôvodný nezmazalo, ale pôvodný nefunguje. Po upgrade na novšiu verziu mi nabehlo nejaké ultra nízke rozlíšenie pritom mám 4K monitor. Neviem či to bolo 1920x1080 ale pripomenulo mi to doby keď bol štandard 640x480
Mám KDE aj v vo FreeBSD 14.1 a tam je naopak všetko rýchle. Na žiadne problémy som nenarazil nepoznám stabilnejší systém. Síce tam neni KDE 6 ale KDE 5+ ale inak je to superrýchle dokonca mi tam bežia rýchlejšie aj linuxové binárky a linuxové aplikacie pre GUI (cez vrstvu linuxulator).
Takže asi popri FreeBSD nainštalujerm znovu arch, alebo Kali linux ktorý síce slúži na penetračné testy ale čo tam po tom. Vo Windowsovom WSL mi to funguje dobre, tak skúsim aj normálnu inštaláciu Kali linuxu.
14
Hardware / Rádio pre DAB+ a internetový streaming
« kdy: 31. 10. 2024, 13:38:49 »
1. Viete poradiť nejaké rádio, ktoré vie prijímať rozne digitálne rádiá, či už z FM alebo z Internetu? (Internet je ešte dôležitejší ako DAB)
Ale nech má pekný štýlový CASE. Lebo do obývačky si ozaj nedám nejaký plastový či cuprextitový bordel.
2. Alebo premýšlal som či by som si nejaké internetové rádio nevyrobil sám, ale mám dosť estetické cítenie. A určite nechcem mať doma niečo neprofesionálne, čo vyzerá ako vyrobené v garáži. Ak byste vedeli poradiť nejaký pekný veľký case strieborný prípadne drevený (pls nie plastové) za 50 - 200 euro, tak ho kludne kúpim a rádio si vyrobím sám. Zoberem dáky MCU s Wifi a BT pridám kvalitný shield pre spracovanie zvuku s trebars 24 bit DAC a ADC a možno nejaký NF modul. DAB+ tuner. A farebný displej LCD alebo ak by bol tak aj OLED, možno ešte ethernet. Takéto rádio by malo výhodu že by bolo ľahko rozšíriteľné aj o iné typy príjímu (trebars satelitny tuner či odposluchavať radioamaterske frekvencie s NBFM - fantazii sa medze nekladu). A mohol by som si to celé naprogramovať podľa seba na mieru.
Ale nech má pekný štýlový CASE. Lebo do obývačky si ozaj nedám nejaký plastový či cuprextitový bordel.
2. Alebo premýšlal som či by som si nejaké internetové rádio nevyrobil sám, ale mám dosť estetické cítenie. A určite nechcem mať doma niečo neprofesionálne, čo vyzerá ako vyrobené v garáži. Ak byste vedeli poradiť nejaký pekný veľký case strieborný prípadne drevený (pls nie plastové) za 50 - 200 euro, tak ho kludne kúpim a rádio si vyrobím sám. Zoberem dáky MCU s Wifi a BT pridám kvalitný shield pre spracovanie zvuku s trebars 24 bit DAC a ADC a možno nejaký NF modul. DAB+ tuner. A farebný displej LCD alebo ak by bol tak aj OLED, možno ešte ethernet. Takéto rádio by malo výhodu že by bolo ľahko rozšíriteľné aj o iné typy príjímu (trebars satelitny tuner či odposluchavať radioamaterske frekvencie s NBFM - fantazii sa medze nekladu). A mohol by som si to celé naprogramovať podľa seba na mieru.
15
Vývoj / Re:Windows .NET, Docker, Linux a Python
« kdy: 29. 10. 2024, 22:47:58 »
Ahojte ďakujem vám za dobré pointy.
