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 - Filip Jirsák

Stran: 1 ... 95 96 [97] 98 99 ... 375
1441
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 21. 02. 2021, 10:38:11 »
By the way, když už jsme stejně úplně OT.

Proč to vlastně chci, mám v hlavě takový projekt.

Možnosti:
  • Věnovat se obsahu
  • Tohle někomu zadat, ať to "zdevelovepří"
  • Za web, ksicht, backend vypláznu tak 50 hadrů

Nebo:
  • Sfouknout to sám, ale zabere mi to násobně víc času
  • Učit se znovu něco, co jsem dlouho nedělal
  • Ušetřím celkem dost peněz
  • Budu to mít udělané tak, jak chci
  • Na obsah budu mít násobně méně času

 ??? popravdě mám zkušenost, že když něco chci, musím si to udělat sám. V opačném případě to je A) blbě, B) draze, C) za dlouho, D) jinak než jsem chtěl, E) cena vyskočí na dvojnásobek, F) nic si na tom pak neudělám, G) musím ukecávat někoho, aby milostivě splnil svoje slovo chlapa  :-\ :P

Jinak jsem koukal na Bootstrap, Svelte a pythonové frameworky, není to těžké, naopak lehčí než dřív.
Jenže k tomu je potřeba ještě grafika a čas, sousta času.

Co znamená ten „obsah“ – je to něco dynamického, každá stránka obsahu se bude muset naprogramovat, nebo je to jen klasický statický webový obsah (texty, obrázky, videa apod.)? Pokud je to ten druhý případ, zvolil bych generátor statických webů – Gatsby (založený na Reactu), Hugo (napsaný v Go), NextJS (založený na Reactu, má blíž k aplikacím než GatsbyJS), Nuxt.js (založený na Vue). Nebo si prostě vyberte na webu JAMstack, co vás zaujme. Generuje to statické weby, takže web je velmi rychlý, dá se snadno hostovat v CDN. Zároveň při buildu můžete pracovat s daty – v jednodušším případě mít třeba jednotlivé stránky napsané v Markdownu, ale můžete i sahat pro data do databáze nebo přes API. A když někde potřebujete nějakou dynamickou část, není problém ji tam přidat – vyhledávání, formuláře nebo prostě jakoukoli frontendovou logiku. Všechny uvedené nástroje mají už spoustu hotových šablon, takže na začátku se můžete věnovat jenom obsahu – a pokud se projekt ujme a vyplatí se do něj investovat, můžete následně nechat někoho udělat šablonu na míru, přidat víc backendové logiky atd.

A kdybyste nutně chtěl udržovat obsah ve WordPressu, i to je se statickými generátory možné. Budete mít schovaný WordPress u sebe, v něm budete udržovat obsah a pak to třeba přes Gatsby publikujete jako statický web. Takhle funguje třeba https://covid.gov.cz.

1442
Tohle je u me standard pocitani s desetinnym cisly.
Jistě, naučil jste se to v šesté třídě a už jste se pak nikdy nedozvěděl, že to ve skutečnosti může být trochu komplikovanější (jako všechny věci, které se člověk naučil v šesté třídě). Tak pokud půjdete třeba k lékaři, doufejte, že nemá stejný přístup jako vy, že všechno důležité se naučil už v šesté třídě a žádné hlubší znalosti nepotřebuje.

Vsak jo, ale at se zaokrouhli, az kdyz se jdou reprezentovat, a ne v procesu vypoctu.
Co jiného asi dělá

Kód: [Vybrat]
print(round(data))

na konci výpočtu, než že to zaokrouhlí výsledek při prezentaci a ne v procesu výpočtu?

1443
Zatímco tohle zaokrouhlování zvýhodní sudá čísla. Prostě posun k dokonalosti.
Což ve většině případů ničemu nevadí, na rozdíl od systematického posunu jedním směrem. Nicméně právě proto existuje více způsobů zaokrouhlování a podle situace se vybere ten, který napáchá nejméně škod.

Krom toho Váš příklad s obchodem pokulhává, při Vaší genialitě byste měl vědět jak se tam správně na ty koruny zaokrouhluje a neplácat tady nesmysly.  Stejně tak se platí i DPH.
V obchodě se (v ČR) pouze při platbě v hotovosti ze zákona zaokrouhluje na nejbližší nominální hodnotu peněz (§ 3 odst. 1 písm. c) zákona č. 634/1992 Sb.). Což opět neřeší případ, kdy se má zaplatit 50 haléřů. Takže tam už záleží na obchodníkovi, zda bude zaokrouhlovat spravedlivě na nejbližší sudé číslo, nebo zda bude zaokrouhlovat ve svůj prospěch na vyšší číslo, nebo ve prospěch zákazníka na nižší číslo.

Že vím, jak se v obchodě v ČR správně zaokrouhluje, nesvědčí o mé genialitě. Nicméně to, že vy to nevíte a na základě chybné domněnky kritizujete někoho jiného, svědčí o vaší hlouposti.

Jinak můj příklad s obchodem byl opět jen příklad na zaokrouhlování. Pokud zaokrouhlování stanoví zákon tak, že povede k systematické chybě, obchodník s tím nic dělat nemůže. To ale není případ ČR, kde zákon právě ten detail, o kterém se celou dobu bavíme, neřeší.

1444
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 20. 02. 2021, 16:42:44 »
WASM snad není plnohodnotnou náhradou?
Současná verze WASM ne, protože nemá přístup k API prohlížeče (např. k DOMu).

1445
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 20. 02. 2021, 12:02:38 »
Já jsem zvědanej, jestli někdy bude vývoj webový aplikace stejně snadnej jako desktopový - jeden jazyk a nebude se muset řešit transformace dat mezi serverem a klientem.
Už dávno můžete psát serverovou část v JavaScriptu. A ještě starší jsou možnosti překládat „serverový“ jazyk do JavaScriptu – mezi ty známější patřil třeba Google Web Toolkit.

1446
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 20. 02. 2021, 10:58:05 »
Zkuste Ruby on Rails , pak snad pochopíte, že ty capiny jako React, Angular, Vue, Svelte apod vůbec nepotřebujete!
JS už používám jen na jedinou věc a tou je grafická animace a ta se děje na klientské straně, takže stačí JQuery, MooTools, GreenSock apod a dost věcí už lze i pomocí CSS.
To by mne zajímalo, jak chcete server-side řešením konkurovat frontendovým frameworkům v rychlosti odezvy.

1447
Server / Re:Migrace RAID 5 ze tří disků na čtyři
« kdy: 19. 02. 2021, 22:14:20 »
Pokud manipuluji s diskovým polem, musím předpokládat, že se může stát cokoliv a o data bych mohl přijít. Je dobré mít vždy! zálohu :)
Kdykoli musím předpokládat, že se může stát cokoliv a o data bych mohl přijít. Je dobré mít vždy! zálohu :)

1448
V takej situácii nie je normálne v systéme ukladať hodnotu s vysokou presnosťou (trebárs aj 10 desatinných miest), ale pri vyplatený "odrezať tých 0.00neco a čakať až sa pri ďalšom zapísaní úroky preklopý tá hodnota cez 0.01 ? takto nikdy nestratí ani cent ani nedá ani cent navyše. Že v systéme bude hodnota desatinná nemusí znamenať že musí banka vyplatiť desatinné haliere.
Nedovedu si moc představit, jak byste tohle popisoval v obchodních podmínkách. Pořád ale hledáte detaily na konkrétním příkladu, ale neřešíte princip.

Můžeme zkusit jiný příklad. Obyčejná prodejna s potravinami, která má ceny, které mají náhodné rozdělení (tedy žádné psychologické ceny záměrně končící devítkami). Ceny jsou normálně s přesností na halíře. Když se platí v hotovosti, je potřeba cenu nákupu zaokrouhlit na celé koruny. Když se bude zaokrouhlovat matematicky („pětka nahoru“), obchod na zaokrouhlování hotovostních nákupů vydělá. Když se bude pětka zaokrouhlovat na nejbližší sudé číslo, obchod na tom v průměru nevydělá ani neprodělá.

Doufám, že se nedozvím, že dneska každý platí kartou…

1449
už se těším, až tu více lidí přijde na to, že 0.1 s 20 desetiními místy u float je 0.999xxx :)
„Číslo s X desetinnými místy u float“ je nesmysl, pokud tedy myslíte float podle IEEE 754 (tedy ve skutečnosti single – 32 bitů). Každé číslo reprezentovatelné v IEEE 754 je reprezentované právě jedním způsobem. Pokud si určíte počet desetinných míst na výstupu, bude se muset buď zaokrouhlit nebo doplnit nulami (pokud zrovna nepotřebujete ten počet míst, který je v daném čísle použit). Takže když se pokusíte do single typu uložit 0,1, uloží se tam ve skutečnosti přesně 0,100000001490116119384765625. Pokud z toho při výpisu dostanete 0,999…, máte něco špatně…

1450
To mi príde sprosté, a na výpočet priemernej hodnoty po zaokrúhlení čísel z pola desatinných čísel (napr. všetkých končiacich .5) existuje logickejší spôsob pomocou sčitovania zvyškov z modula a deleno a následne je zdeliť a pričítať ku priemeru samotných celých čísel (s odrezaním desatinej časti), alebo ešte lepší, a to vynásobiť hodnoty *10 následne vypočítať priemer a výsledný priemer vydeliť /10 a previesť na celé číslo. V oboch prípadoch neprekročíš odchýlku väčšiu než 0.5
Ono samozřejmě nejde o výpočet průměrné hodnoty zaokrouhlených čísel. Představte si, že vám třeba banka vyplácí úroky ze zůstatku na účtu. Na účtu typicky nemáte nějakou kulatou částku, takže po vypočtení úroku vyjde nějaké hausnumero jako 0,12489 Kč. To vám banka samozřejmě vyplatit nemůže, je potřeba to zaokrouhlit na halíře. No a když to banka bude zaokrouhlovat matematicky, tedy 0,5 hal vždy nahoru, zaplatí nakonec na úrocích víc, než by odpovídalo úrokové sazbě. Když bude zaokrouhlovat na nejbližší sudé číslo, vyplatí celkově přibližně tolik, kolik by odpovídalo úrokové sazbě – zaokrouhlovací chyby se navzájem víceméně vyruší.

1451
Kterého dementa napadlo, že zaokrouhlených 1.5 se bude rovnat zaokrouhlených 2.5 ?
By mě zajímalo, kdo vymýšlí takovéhle vyfikundace a navíc je nacpe do standardní funkce.
K čemu to vůbec je?
Napadlo to někoho, kdo toho o zaokrouhlování ví víc, než vy. Existuje totiž mnoho způsobů, jak zaokrouhlovat. Tenhle způsob zaokrouhlování vede k menší průměrné chybě, která se zaokrouhlováním vnáší. Ona je totiž pětka jaksi přesně uprostřed intervalu, takže když ji budete zaokrouhlovat stále k větší absolutní hodnotě (tzv. matematické zaokrouhlování, které asi znáte ze ZŠ) a budete mít nerovnoměrně rozložená kladná a záporná čísla (např. budete zaokrouhlovat jenom samé kladné hodnoty), bude vám zaokrouhlování systematicky posouvat výsledek (u kladných čísel nahoru).

Nazývat někoho dementem jenom kvůli vlastní neznalosti je – řekněme hloupé.

1452
Server / Re:Migrace RAID 5 ze tří disků na čtyři
« kdy: 19. 02. 2021, 16:28:04 »
Nenapsal jste, co je to za NAS. Ale bylo by hodně divné, kdyby to vyžadovalo zálohu a rekonfiguraci. Mělo by stačit disk přidat a v nastavení NASu nový disk zařadit do RAIDu. Migrace dat se pak provede automaticky na pozadí.

1453
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 19. 02. 2021, 15:47:10 »
Nakouknul jsem co je Svelte zač - a zjistil, že s JS knihovnami typu jQuery to nemá nic společného.
Není to nic, co by rozšiřovalo možnosti skriptování v JS na straně klienta, ale je to vývojový FW který transpiluje nějaký zdrojový kód do JS/CSS - jeden kód píšu a jiný kód jde do browseru.
To už se asi raději naučím Blazor - stejně serverovou část píšu v ASP .NET c#.
Svelte je frontendový framework, typicky se používá pro SPA, podobně jako React, Vue, Angular… Všechny tyto frameworky dělají to, že místo HTML značek a DOM událostí pracujete s komponentami, které jsou napojené na data. React, Vue i Angular to řeší tak, že dodávají vlastní knihovnu funkcí, které poslouchají události a manipulují s DOMem. Svelte na to jde jinak, přímo generuje kód, který na základě událostí manipuluje DOMem. Odpadá tam tedy velká část knihovních funkcí, místo toho se už v době transpilace vytvoří ten správný kód pro prohlížeč.

1454
Vývoj / Re:Náhrada PHP nebo ASP.NET Core
« kdy: 19. 02. 2021, 12:28:29 »
ano, musíš ho optimalizovat a to tak, že v něm prostě data nemáš nebo vše cpeš do immutable struktur, pureComponent rulezz a celou dobu bojuješ s re-render problémem. Náklady na optimalizaci u vývoje u reactu dosahují už pěkného poměru k samotnému vývoji. Mně připadalo zajímavé na jedné straně mluvit o tom, že jQuery zbytečně zpomaluje web a pak říct, že se dá také použít React.
Akorát jste k tomu zapomněl napsat takovou drobnost – že ten web v Reactu, o jehož optimalizaci píšete, je tak složitý, že s jQuery byste ho vůbec nenapsal.

O zpomalování webu jQuery byla řeč v souvislosti s tím, že potřebujete vybrat pár elementů a jim nastavit nějaký ovladač události – a místo abyste to udělal prostředky, které má každý dnes používaný prohlížeč, dotáhnete tam celou knihovnu jQuery (a pokud možno ještě tak, aby její stažení blokovalo vykreslení stránky).

1455
Podívejte se na OBS Studio. Je to softwarové video studio pro vytváření videí a vysílání. Funguje jako klasická video střižna. Zkombinujete si tam různé video vstupy – třeba vás obraz z kamery a plochu počítače nebo konkrétní program, ze kterého budete promítat prezentaci.

Stran: 1 ... 95 96 [97] 98 99 ... 375