Stanislav Fort, vedoucí vědecký pracovník z Vlčkovy 'kyberbezpečnostní' firmy AISLE, zkoumal dopady Anthropic Mythos (nový AI model od Anthropicu zaměřený na hledání chyb, který před nedávnem vyplašil celý svět) a předvedl, že schopnosti umělé inteligence nejsou lineárně závislé na velikosti nebo ceně modelu a dokázal, že i některé otevřené modely zvládly v řadě testů odhalit ve zdrojových kódech stejné chyby jako Mythos (například FreeBSD CVE-2026-4747) a to s výrazně nižšími provozními náklady.
Federální návrh zákona H.R.8250 'Parents Decide Act', 13. dubna předložený demokratem Joshem Gottheimerem a podpořený republikánkou Elise Stefanik coby spolupředkladatelkou (cosponsor), by v případě svého schválení nařizoval všem výrobcům operačních systémů při nastavování zařízení ověřovat věk uživatelů a při používání poskytovat tento věkový údaj aplikacím třetích stran. Hlavní rozdíl oproti kalifornskému zákonu AB 1043 a kolorádskému SB26-051 je ten, že federální návrh by platil rovnou pro celé USA.
Qwen (čínská firma Alibaba Cloud) představila novou verzi svého modelu, Qwen3.6‑35B‑A3B. Jedná se o multimodální MoE model s 35 miliardami parametrů (3B aktivních), nativní kontextovou délkou až 262 144 tokenů, 'silným multimodálním vnímáním a schopností uvažování' a 'výjimečnou schopností agentického kódování, která se může měřit s mnohem rozsáhlejšími modely'. Model a dokumentace jsou volně dostupné na Hugging Face, případně na čínském Modelscope. Návod na spuštění je už i na Unsloth.
Sniffnet, tj. multiplatformní (Windows, macOS a Linux) open source grafická aplikace pro sledování internetového provozu, byl vydán ve verzi 1.5. V přehledu novinek je vypíchnuta identifikace aplikací komunikujících po síti.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 15.0 (Mastodon). Forgejo je fork Gitei.
Současně se SUSECON 2026 proběhne příští čtvrtek v Praze také komunitní Open Developer Summit (ODS) zaměřený na open source a openSUSE. Akce se koná ve čtvrtek 23. 4. (poslední den SUSECONu) v Hilton Prague (místnost Berlin 3) a je zcela zdarma, bez nutnosti registrace na SUSECON. Na programu jsou témata jako automatizace (AutoYaST), DevOps, AI v terminálu, bezpečnost, RISC-V nebo image-based systémy. Všichni jste srdečně zváni.
Český úřad zeměměřický a katastrální zavedl u anonymního nahlížení do katastru nemovitostí novou CAPTCHA ve formě mapové puzzle: nepřihlášení uživatelé musí nově správně otočit devět dlaždic v 3x3 poli tak, aby dohromady daly souvislý obrázek výseče reálné mapy, přičemž na to mají pouze jeden časově omezený pokus. Test je podle uživatelů i odborníků příliš obtížný a na sociálních sítích pochopitelně schytává zaslouženou kritiku a
… více »Byla vydána verze 1.95.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Mozilla prostřednictvím své dceřiné společnosti MZLA Technologies Corporation představila open-source AI klienta Thunderbolt. Primárně je určený pro firemní nasazení.
Firma Cal.com oznámila, že přesouvá svůj produkční kód z otevřeného do uzavřeného repozitáře z důvodu bezpečnostního rizika umělé inteligence, která prý dokáže vyhledávat a zneužívat zranitelnosti rychleji, než by je jejich vývojářský tým stíhal opravovat. Zároveň zveřejnila samostatnou, open-source verzi Cal.diy pod licencí MIT, ovšem bez řady původních funkcí. O tom, zda je toto opatření rozumné, existují pochyby. … více »
Minule jsem se pokusil ve stručnosti popsat fungování kontrolerů v Zendu, zejména pak front controller, o action controllerech (potomcích Zend_Controller_Action) jsem se zmínil ještě stručněji. Dnes bych rád, opět jen povrchně, popsal, jak se od kontroleru dostat až k html stránce, která se posílá uživateli do prohlížeče (nebo přesněji řečeno prezentační vrstvě, tedy view v onom MVC, což nemusí být jen html stránka).
Prezentační vrstva je v Zendu reprezentované především třídou Zend_View.
Až dosud jsem k vytvoření view používal action controller, který na konci každé akce vygeneroval příslušné view automaticky. Každý action contoller má totiž přiřazenou pomocnou třídu (hepler class) ViewRenderer, která, pokud není stanoveno jinak, se postará o vygenerování view, které očekává skript action.phtml v adresáři application/views/scripts/contoller/. Pokud chceme zavolat jiný skript, můžeme metodu render() zavolat explicitně se jménem skriptu, který se má rendrovat. Pokud chceme zabránit defautlnímu volání ViewRenderer (např. akce nevytváří přímo žádný výstup pro view nebo výstup ukládáme přímo do objektu respose), můžeme to explicitně zakázat v příslušné akci voláním $this->_helper->viewRenderer->setNoRender(true);.
Vytvoření view probíhá ve třech krocích: vytvoření instance Zend_View, přiřazení proměnných vytvořené instanci a vykreslení (renderovaní). Vše obvykle probíhá v kontroleru nebo nějakém jeho pluginu. Instanci Zend_View můžeme buď vytvořit jako instanci každé jiné třídy ($view = new Zend_View();), v action controllerch pak můžeme využít metodu k tomu určenou, initView(). Pokud inicializace neproběhla před voláním metody render(), provede ji tato metoda.
Obě tyto metody přiřadí atributu kontroleru view instanci třídy Zend_View, můžeme ale použít i nějakou jinou třídu, která implementuje Zend_View_Interface. Metoda render(),jak již bylo řečeno, se stará o vytvoření výstupu. Můžeme ji volat s následujícími parametry: render(string $action = null, string $name = null, bool $noController = false). Parametr action určuje jméno skriptu, který se má vykreslit a který musí být v adresáři views/scripts/controller_name. Pokud by se skript nacházel v jiném adresáři, je potřeba nastavit parametr $noController na hodnotu true (nastavení cesty ke view skriptům se provádí pomocí $view->setScriptPath();, případně $view->addScriptPath();). Výstup je uložen do objektu Zend_Controller_Response. Jednotlivé části výstupu mohou být pojmenované, k čemuž slouží parametr name metody render() (pojmenované bloky můžeme ukládat i přímo do objektu response pomocí metod prepend($name, $content) a append($name, $content)). Pokud vytváříme instanci Zend_View mimo action controller, musíme jí nastaví cestu v view skriptům($view->setBasePath()). Tato situace například nastává, když vytváříme view v pluginu. Jednoduchý příklad použití: hlavička a patička stránky jsou obvykle pro všechny stránky stejné, tak abychom je nemuseli pokaždé nastavovat, můžeme si vytvořit plugin front controlleru, který se zavolá při každém požadavku a bude hlavičku a patičku nastavovat:
class ZendTest_View_HeadfootPlugin extends Zend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$view = new Zend_View();
$config = Zend_Registry::getInstance()->get('config');
$view->setBasePath($config->myview->viewpath);
$this->getResponse()->prepend('header', $view->render('header.phtml'));
}
public function postDispatch(Zend_Controller_Request_Abstract $request)
{
$view = new Zend_View();
$config = Zend_Registry::getInstance()->get('config');
$view->setBasePath($config->myview->viewpath);
$this->getResponse()->append('footer', $view->render('footer.phtml'));
}
}
Velmi užitečnou metodou třídy Zend_View je metoda $view->escape($variable), která nahradí příslušné znaky escape sekvencí (co se má escapovat můžeme měnit pomocí metody setEscape()). Kapitolka v manuálu, která stojí za nahlédnutí, ale je zbytečné ji sem opisovat, je View Helpers (Partial Helper, Head helpery, Translate Helper a další).
K rozvržení jednotlivých prvků v prezentační vrstvě slouží Zend_Layout. Slouží v podstatě jako šablona, podle které se skládají jednotlivé části (view popisovaná v předchozím odstavci) do výsledného dokumentu. Pěkný příklad použití Zend_Layout uvedl Karel Benák v diskuzi pod prvním zápiskem o Zendu. Je zbytečné jej sem opisovat, takže se jej pokusím jen trochu okomentovat a doplnit, co mi tam na první pohled, jako člověku Zendu neznalého, nebylo zcela jasné. Řádek $layout = Zend_Layout::startMvc(); vytvoří instanci Zend_Layout a zaregistruje ji ve front contorlleru, který po ukončení dispatch smyčky vygeneruje konečnou podobu prezentační vrstvy aplikace. $layout->setConfig($config); načte konfiguraci layoutu. Typicky nastavujeme hlavně cestu k layoutu. Zkráceně můžeme použít $layout = Zend_Layout::startMvc($config->testlayout); (zde je navíc v XML konfiguračním souboru přidán obalujicí element testlayout). Parametrem metody setConfig je objekt Zend_Config. Obvykle jeho instanci vytvoříme v souboru bootstrap.php, kde jej rovnež uložíme v registru (kontejner sloužící uchovávání objektů a hodnot, které mají být dostupné v celé aplikaci):
$config = new Zend_Config_Xml('../../zendTest/config.xml', 'production');
$registry = Zend_Registry::getInstance();
$registry->set('config', $config);
Zbytek příkladu mi příjde vcelku jasný a asi nepotřebuje další komentář.
Tiskni
Sdílej:
Každopádně se těším na další zápisky, vyděržaj pijaněr!
PS: Ve vysvětlovacím komentáři jsem měl chybku, místo $this->layout()->code mělo být $this->layout()->content.
Až se např. dostaneš k Zend_Form, zjistíš, že si celý formulář můžeš nadefinovat právě v konfiguračním souboru a není třeba jej složitě programovatMe osobne presne tohle vadi. Nemam rad generovani markupu v PHP a pak jen nekde
<?= $this->form ?> a to proto, ze se to pak vsechno rozjizdi a v ramci view nemam kontrolu nad stylovanim a vlastnim pojetim markupu -- nemluve o praci v tymu programator-koder.
= $this->render('header.phtml') ?> a = $this->render('footer.phtml') ?>
(Chtel jsem vymyslet nejaky prilad, kde se vytvari Zend_View mimo action contoller a vystup se primo zapise do Response. No, asi to nebyl uplne nejlepsi priklad