SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
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:
