Vojtěch Polášek představil Vojtux, tj. linuxovou distribuci pro zrakově postižené uživatele. Vychází ze spinu Fedory 43 s desktopovým prostředím MATE. Konečným cílem je, aby žádný Vojtux nebyl potřeba a požadovaná vylepšení se dostala do upstreamu.
Byla vydána (Mastodon, 𝕏) druhá RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 160 (pdf).
Izrael od února zakáže dětem používat v prostorách základních škol mobilní telefony. Podle agentury AFP to uvedlo izraelské ministerstvo školství, které zdůraznilo negativní dopady, které na žactvo používání telefonů má. Izrael se tímto krokem přidává k rostoucímu počtu zemí, které dětem ve vzdělávacích zařízeních přístup k telefonům omezují.
Internetová společnost Google ze skupiny Alphabet pravděpodobně dostane příští rok pokutu od Evropské komise za nedostatečné dodržování pravidel proti upřednostňování vlastních služeb a produktů ve výsledcích vyhledávání. V březnu EK obvinila Google, že ve výsledcích vyhledávání upřednostňuje na úkor konkurence vlastní služby, například Google Shopping, Google Hotels a Google Flights. Případ staví Google proti specializovaným
… více »Byl oznámen program a spuštěna registrace na konferenci Prague PostgreSQL Developer Day 2026. Konference se koná 27. a 28. ledna a bude mít tři tracky s 18 přednáškami a jeden den workshopů.
Na webu československého síťařského setkání CSNOG 2026 je vyvěšený program, registrace a další informace k akci. CSNOG 2026 se uskuteční 21. a 22. ledna příštího roku a bude se i tentokrát konat ve Zlíně. Přednášky, kterých bude více než 30, budou opět rozdělené do tří bloků - správa sítí, legislativa a regulace a akademické projekty. Počet míst je omezený, proto kdo má zájem, měl by se registrovat co nejdříve.
Máirín Duffy a Brian Smith v článku pro Fedora Magazine ukazují použití LLM pro diagnostiku systému (Fedora Linuxu) přes Model Context Protocol od firmy Anthropic. I ukázkové výstupy v samotném článku obsahují AI vygenerované nesmysly, např. doporučení přeinstalovat balíček pomocí správce balíčků APT z Debianu místo DNF nativního na Fedoře.
Projekt D7VK dospěl do verze 1.0. Jedná se o fork DXVK implementující překlad volání Direct3D 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána nová verze 2025.4 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Ahoj, píšu v PHP aplikaci, která bude přes SOAP komunikovat s klientem, který bude v příkazovém řádku. Hodiny jsem strávil přemýšlením o používání různých návrhových vzorů pro všechny možné účely - DI, data mapper, active record, factory, ... Chtěl bych co nejjednodušeji vyřešit typově následující situaci:
Databáze v postgresql
třídy:
Plan, Kroky
- v tabulkách v databázi je uložený nějaký plán, který obsahuje nějaké kroky. V databázi realizované několika tabulkami. V PHP chci přímo pracovat s plánem jako celkem => vytvořit plán, uložit/načíst z/do databáze.
Přikláním se k tomu, řešit to takto:
Třída Plany: - vytváří nové - načítá z db - ukládá do db Poté práce s ní cca takto: Application::getInstance()->getPlany()->...To je v podstatě kombinace Data Mapper s Factory. Jenže to by teoreticky nemělo být a data mapper by zase měl pracovat jen s jednou tabulkou. Nejsem zastáncem používání "zrovna frčících" návrhových vzorů, které po přečtení různých článků stejně každý používá tím svým jediným "správným způsobem". Rád bych to udělal co nejjednodušší, aby se mi to pak dobře upravovalo. Nějaká ohromná vrstevnatá architektura by mi podle mě spíš přidělala práci. Jenže zase s tímto nemám nějaké zkušenosti. Rád si nechám poradit. Jak byste to řešili vy?
20.11.2014 10:14
Konqui | skóre: 18
| blog: Konqui
| Rožnov pod Radhoštěm
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
20.11.2014 19:16
Application::getInstance()->getPlany()->$this.
getPlany() je takové ošklivé. Lepší je mít objekt ve stylu úložiště (manager), které bude mít metodu na nalezení plánu a na získání seznamu plánů podle daných kritérií. Většina implementací ORM a podobných módních zvrhlostí jsou v tomhle dost nešikovné.
Dále pak to moc nepřeháněj s operátorem '->', neboť takový řetěz mnoha a mnoha volání je často obtížné dešifrovat.
try {
$plan = $this->planManager->findPlan($plan_id);
foreach ($plan->steps as $step) {
// ...
}
}
catch (PlanNotFoundException $ex) {
// ...
}
$filters = $_GET; // něco v tom smyslu
$list = $this->planManager->listPlans($filters);
if (empty($list)) {
echo "Nejsou.\n";
} else foreach ($list as $plan) {
echo "<li>", $plan->title, "</li>\n"; // jen pro ilustraci
}
// Vytvoření a uložení plánu do XML dokumentu
Plan::getInstance(XMLPlanManager::getInstance(), XMLStepManager::getInstance())
->name('Plan 9)
->addStep('Krok 1')
->addStep('Krok 2')
->addStep('Krok 3')
->save();
// a nebo
Plan::getInstance(PDOPlanManager::getInstance(), PDOStepManager::getInstance())
->name('Plan 9)
->addStep('Krok 1')
->addStep('Krok 2')
->addStep('Krok 3')
->save();
PHP Fatal error: Class 'Plan' not found PHP Fatal error: Class 'XMLPlanManager' not found PHP Fatal error: Class 'XMLStepManager' not found PHP Fatal error: Class 'PDOPlanManager' not found PHP Fatal error: Class 'PDOStepManager' not found
Do testů dávám úmyslně i chybné SQL dotazy, dotazy na neexistující sloupce, neexistující metody apod. a aplikace si s tím musí poradit. Je to užitečnější, než všechna statická typování dohromady.Z mého pohledu zbytečné, rozumný staticky typovaný jazyk by vás toho ušetřil.
SELLECT * FROM tabulkaVždyť to vůbec není v jeho kompetenci. Testy jsou nezbytné.
To by mě zajímalo, jak by se třeba takový kompilátor Javy vypořádal s SQL dotazemPrávě proto jsem psal slovo "rozumný". Staticky typované jazyky s makry nebo něčím podobným – např. poskytovateli typů (type providers) to dokáží. Pár konkrétních příkladů:
I po kompilaci se přece může stát, že mi někdo změní strukturu databáze.Ano, pak bude vyhozena výjimka a aplikace s ní naloží jako s kteroukoli neodchycenou výjimkou – tj. stále nevidím důvod, proč testovat chybné SQL dotazy. Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.
Jak může ta třída v F# tušit, jaké budu dělat dotazy?Je podporována pouze podmnožina SQL dotazů. Kromě toho ta třída dovoluje volat uložené procedury.
Jak se takový F# modul přidává do javovské aplikace?Těžko.
Ano, pak bude vyhozena výjimka a aplikace s ní naloží jako s kteroukoli neodchycenou výjimkouPokud aplikace vyhazuje výjimky, musím v ní i testovat, jestli je vyhazuje správně a jak se při zachytávání výjimky chová. Aplikace nemusí dělat nic z toho, co není testováno.
Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.To samozřejmě testuji také.
Podmnožina mě nezajímá. Chci kompletní sadu SQL dotazů.Jak může ta třída v F# tušit, jaké budu dělat dotazy?Je podporována pouze podmnožina SQL dotazů.
V tom případě F# vypadává ze hry.Jak se takový F# modul přidává do javovské aplikace?Těžko.
Opět byste si ušetřil práci, kdybyste použil rozumný jazyk.Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.To samozřejmě testuji také.
V tom případě F# vypadává ze hry.Podobné věci má i Scala – viz sqlτyped.
Opět byste si ušetřil práci, kdybyste použil rozumný jazyk.Neexistuje žádný "rozumný jazyk", který by sám otestoval logické chyby. Jednotkové testy mohu z editoru spouštět třeba 5× za minutu, klidně i po každém napsaném řádku. Vyvíjet něco pro Javu, Scalu nebo pro F# jen proto, abych to nakonec převedl do požadovaného PHP? To je příliš velká oklika. To už je daleko jednodušší naučit můj editor generovat SQL dotazy reflexí z testovací databáze a pak si je upravit dle aktuální potřeby.
Neexistuje žádný "rozumný jazyk", který by sám otestoval logické chyby. Jednotkové testy mohu z editoru spouštět třeba 5× za minutu, klidně i po každém napsaném řádku.S tím souhlasím. Já ale mluvím o něčem jiném. A to, že existují určité vlastnosti, které může snadno ověřovat kompilátor, tudíž je zbytečné je testovat, stačí jen použít vhodný programovací jazyk.
Je zbytečné hledat vhodný jazyk, stačí testovat. Kompilátor stejně neověří vše, co ověřit potřebuji.Testování bohužel nestačí – příkladem jsou nedeterministické programy nebo programy, jenž nejste schopen otestovat na všech možných vstupech. Na druhé straně ověřovat všechny vlastnosti pomocí typového systému je velmi nákladné. Proto se používá kombinace obojího. Ostatně výhod statického typování si všiml i autor Pythonu.
Testy jsou prostě jednodušší na použití, než nějaké metaprogramování přes dekorátory.To není přes dekorátory. Je to kód, který se spouští při kompilaci a vygeneruje jiný kód. V principu je to velmi jednoduché.
To není přes dekorátory. Je to kód, který se spouští při kompilaci a vygeneruje jiný kód. V principu je to velmi jednoduché.Takže v principu ten kompilátor F# dělá totéž, co lepší editor pro libovolný jazyk.
Takže v principu ten kompilátor F# dělá totéž, co lepší editor pro libovolný jazyk.V tomto případě ano. Výhodou je nezávislost na editoru. Kromě toho si to umí poradit i se situacemi, kdy je informační zdroj příliš rozsáhlý a kdy by generovaný kód byl příliš velký (dokonce to může fungovat i v případech, kdy počet metod nebo počet typů není omezený).
Že se ani jeho struktura nevejde do RAM?Ano, ta struktura může být klidně nekonečná.
The second option, code generation, is also problematic: it adds yet another step to the build process, which means that automated builds must have the tool or its artifacts, it interacts badly with source control, particularly when the generated code is large and should be cached and shared among a development team, and it leads to either code bloat or the need for (yet another!) tool for pruning the compiled artifacts*. * Note that this last point is not a hypothetical: the authors have been informed of cases where the generated code for an enterprise system is so large that it cannot fit within the limits of a .NET process.
data.Society.Government.Politicians.IndividualsAZ.V.``Václav Havel``.Education.
To je sice hezké, ale pořád to nemá šanci se vypořádat s generovanými SQL dotazy, kterých je dle mé zkušenosti ve webových aplikacích značná část.Co myslíte generovanými SQL dotazy?
Koukal jem do různých zdrojáků různých opensource PHP projektů a tam se dost často objevovalo něco ve stylu AplikacniKontejner::getDatabase(), ...Jo, když se začalo více mluvit o návrhových vzorech, singleton byl jedním z těch základních. Chvliku trvalo, než lidem došlo, že to vlastně až tak dobrý nápad není. Dnes už je považován za anti-pattern.
Pokud bych měl takto "schovaný" PlanManager, kde by vznikaly nové plány?Ten PlanManager by měl mít factory metodu na vytváření nových plánů. V jednoduchém případě to bude jen vracet
new Plan($this). Často je žádoucí (ale ne vždy), aby takový objekt znal svého tvůrce a mohl ho používat (proto to $this). Sám uvidíš, co novému plánu bude potřeba předat.
$configuration = new Config();
$container = new AppContainer($configuration);
$container->getServiceSoapServer()->run();
AppContainer {
...
public function getServiceSoapServer() {
// ... testovani zda instance soap serveru existuje ... pokud ne pak:
return new SoapServer($this->getServicePlanManager(), $this->getServiceXY(), ...)
}
...
uvnitř SoapServer:
$this->planManager->create()
...
$this->planManager->findById()
...
}
To už vypadá lépe. Nebo mi něco uniká :) a dělám někde brutální chybu v nepochopení patternu?
Tiskni
Sdílej:
