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.
A to je problem ty kytky jednou tydne zalit konyvkou? Se podivej na tu hromadu soucastek z Ciny. Kontejnerove lode, logistika... Planeta place...
(...) je to myšlení hazardního hráče, který je přesvědčený, že když na ruletě padla 10x za sebou červená, tak příště už musí přijít černá - a nechce uvěřit, že šance je stále 18:37, stejně jako při prvním roztočení. Šalba vlastní zkušeností je nebezpečná.
Jednou z mnoha zásad je separovat technologie a segregovat oprávnění. Zjednodušeně řečeno, není dobré mít VPN endpoint na serveru, na který jinak uživatelé nemají mít přístup (...)
...
Zvažte webovou self hosted aplikaci (v javě) - https://www.picapport.de/en/ Je to poměrně propracované a trvale vyvíjené aplikace s dobrou komunikací vývojářů. Pracuje nad adresářovou strukturou, kterou nemění, fotky procházíte podle tagů, času, adresářů, hledání... Fotky lze tagovat apod.
Zkousel jsem to, kvalita te aplikace mi nepripada moc dobra, moc perspektivne to s ni nevidim.
Moje idea je, že se to celé převrátí. Nebudeme se z aplikace dotazovat na data do databáze, ale budeme mít databázi, ve které bude napsaná aplikace. Další generace smalltalku.A nechceš si napsat prototyp, ať se máme nad čím bavit?Nevím, jestli přímo ve Smalltalku, ale určitě by to bylo zajímavé.
ORM jsou pomalé svině. Ale ne proto, že by pomalé být musely. Není důvod, aby se načítali po jednom. A v mnoha případech se i načítají velice chytře. Vůbec, obecně vzato není důvod si myslet, že by ORM neměli být stejně chytré, jako ručně psané SQL. IMHO je to stejný vývoj, jako ruční správa paměti -> GC -> escape analýza. Ručně psané ASM -> C -> JustInTime. Je to jen otázka času.
Tak mě v této souvislosti napadá, že místo kolekcí s proxy objekty, používaných v současných objektových databázích, by byly efektivnější streamy (bez proxy objektů).
Moje preferovana varianta pro strojovou operaci "SET" je:Vychazim totiz z predpokladu, ze soubor nemusi obsahovat dany parametr, nebo ho muze obsahovat jinak napsanej. A pak se hodi videt historii zmen / customizaci nastave na konci souboru na jednom miste, nez abych musel delat diff vuci distribucnimu default configu.
- smazat vsechny radky obsahujici case insensitive verzi: ^\s*KeyWord\s.*
- append na konec, KeyWord NewValue
Něco na tom bude, protože původní parametr nejraději zakomentuji a hned pod něj uvedu s novou hodnotou.
(...)
Když se pracuje s izolovanými hodnotami, tak objektové databáze nebo ORMka nemají jediný problém. Ale pro hromadné operace, tam vlastně není moc prostoru jak je implementovat efektivně (neduplikovat objekty v RAM, redukovat síťové operace, redukovat diskové operace). Řešitelné by to podle mne bylo - tytéž operace, které dělám nad objektem bych měl být schopen udělat nad kolekcí objektů - a mohlo by to fungovat pokud by vývojář použil tento interface.
(...)
To je jen ilustrace možných problémů. V rámci jedné aplikace se dají změny z jiného vlákna (nebo korutiny) ohlídat (v Rustu v době překladu), ale nad změnami na jiném stroji už člověk kontrolu nemá. Vytvoření kopie range řešení není, když ten objekt už bude menší.Viděl bych to tak.Kód: [Vybrat]A teď mi příjemce na druhé straně síťového kanálu změní size (řekněme, že hodnotu zmenší). Co se stane s tím for-cyklem?let obj = ... // fetch somehow an object
remoteChannel <- obj
for i in range(0, obj.size) { ... }
Jako že za běhu cyklu změní size použitý v podmínce cyklu? Stane se IMHO to stejné jako pokud na tu size sáhnu z jiného vlákna?
Některé jazyky pro foreach vytvoří kopii té kolekce (varianta optimistické transakce).
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.