Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
class Validator { public static function notEmpty($mValue){ if(!isset($mValue)){ return false; } else if(is_null($mValue)){ return false; } else if (is_integer($mValue)){ return true; } else if (is_object($mValue)){ return true; } else if(is_string($mValue)){ return strlen($mValue) != 0; } else if(is_array($mValue)){ return sizeof($mValue) > 0; } } }Tato metoda dost zpřehlednila kód. Bohužel se ale volá během requestu mnohokrát a to něco stojí. Pokud test implementuju jako normální funkci, je to jen nepatrně rychlejší. Pokud však tělo metody zapíšu do kódu rovnou jako výraz, je to mnohem rychlejší. Jednoduchý test volající validaci 1000x ukázal:
Checked 1000x via Validator method in 3.41 ms Checked 1000x via inline expression in 0.19 msTo mne vede myšlence, zda neexistuje v php něco jako makra v C? Tj. abych měl validační kód na jednom místě a přitom aby odpadla režije s voláním metody? Díky za případné náměty!
To mne vede myšlence, zda neexistuje v php něco jako makra v C?Když bude nejhůř, můžeš na zdrojáky vždycky pustit
cpp
(nebo jakýkoli jiný preprocesor nebo makroprocesor nebo obecně šablonovací systém, whatever).
if (!empty($mValue)) { ... }nebo
if ($mValue !== null) { ... }Jak vypadá ten kód okolo?
Považuju současně za dobré mít kontroly na jednom místě - moje pojetí neprázdnosti je pak na onom místě zřetelně vyjádřené a platí pro celou aplikaci - stačí se podívat na onu metodu. Pokud bych pomíněně kontroloval přímo v kódu s ohledem na typ, zanese se užitečný kód balastem, který nesouvisí přímo s aplikační logikou a tím utrpí čitelnost.Kontrola přece patří k objektu, do kterého se daná hodnota ukládá. Dál se pracuje už jen s naplněnými objekty, resp. jejich gettery. Tím se hlavní kód zjednoduší na minimum a zpřehlední.
$x !== null
napsat !empty($a)
.
Btw, ty dvě rovnítka tam nejsou omylem.
$_GET[nick]
ve skrytém poli), jiné mohou být prázdné (např. $_GET[state]
u neamerického státu) a jiné je třeba nutné před uložením do objektu otestovat na přítomnost v databázi. Nejsou to řetězce, ale nick
, state
a např. username
. A každý z nich se testuje jinak.
""
vs. null
.
# Checked via static Validator::notEmpty() in 1.84 ms # Checked via inline expression in 0.30 ms # Checked via normal function in 1.64 ms # Checked via object->notEmpty() in 1.87 ms
U dynamicky nebo slabě typovaných jazyků si s typem jist nemusím být. Takže to je otázka přístupu.Pokud testuji například číslo domu v adrese a očekávám řetězec, tak budu testovat a ukládat řetězec. Nebudu se snažit ho převádět na číslo, i když ve většině případů to číslo bude. Takže vždycky vím, jakého typu ta uložená proměnná bude. Nebo mi to může být jedno a uložím to co přijde. Záleží na požadavcích na aplikaci. Pokud naopak očekávám číslo a někdo mi tam narve string, mám podle požadavku na aplikaci na výběr, zda se pokusím ten string převést na číslo nebo ten string odmítnu. Vždy záleží na konkrétním případě vstupní hodnoty, zda budu tvrdě kontrolovat přesnost vstupů, zda se vstupní data pokusím normalizovat nebo mi to bude jedno. Testovat všechny vstupy postupně jedním univerzálním nástrojem je IMHO blbost a aplikace na to doplatí výkonem. Mám na mysli testování po jednom. Výkonově přijatelnou variantou by mohlo být testování všech vstupů jednou třídou, která by všechny ošetřené hodnoty poskytla buď ve formě objektu, anebo třeba ve formě asociativního pole. Objekt se mi však jeví jako lepší, neboť umožňuje vytváření i jiných než primitivních getterů. Jsem prostě zaujatý proti primitivním jednořádkovým getterům a setterům. A nestydím se za to. Jsem zastáncem toho, že setter si musí umět sám ošetřit vstupy a nesmí očekávat, že to za něj udělá někdo předtím. Tím pro mne uvedené statické validátory postrádají na významu.
Uvedené měření mi vlastně dokázalo, jak nesmyslné je objektové programování s jednořádkovými gettery a settery. Výsledné aplikace jsou pak líné, protože proměnné jsou testovány ještě před uložením do objektu a to znamená další režii a znepřehlednění kódu.Objektové programování nemá být rychlejší než assembler, ale má zpřehlednit program pro programátory. Rozvinutí jednořádkových getterů a setterů je jedna ze základních optimalizací, které může dělat kompilátor. Jinak dotaz je ukázkovým příkladem předčasné optimalizace. Ztráta výkonu spojená s voláním jednořádkových funkcí bude nejspíš o několik řádů menší, než ztráta výkonu spojená s typickým nasazením PHP – zpracování zdrojového kódu pro každý požadavek, chybějící optimalizace překladače a běhového prostředí, neexistující kontext aplikace, který by umožnil kešovat data rovnou v paměti procesu atd. Pokud je tedy pro aplikaci zdržení voláním funkce kritické, zvážil bych spíš změnu běhového prostředí aplikace, která by přinesla řádově větší zlepšení výkonu.
Je hodně podivné proměnnou testovat na číslo, řetězec a objekt zároveňJenže to je právě dáno tím, že to není objektové. Pokud by bylo, tak každý typ, kde je to zapotřebí, má svou validační metodu (resp. více), a ta se prostě zavolá. Tohle je prostě pokus o makro/šablonu v jazyce, který nic takového nemá.
Jinak dotaz je ukázkovým příkladem předčasné optimalizace. Ztráta výkonu spojená s voláním jednořádkových funkcí bude nejspíš o několik řádů menší, než ztráta výkonu spojená s typickým nasazením PHP – zpracování zdrojového kódu pro každý požadavek, chybějící optimalizace překladače a běhového prostředíAno. Proto vidím šanci v makrech nebo JIT optimalizaci. Pokud nic funčního v PHP zatím není, kašlu na to protože ta pomalost není kritická.
Jenže to je právě dáno tím, že to není objektové. Pokud by bylo, tak každý typ, kde je to zapotřebí, má svou validační metodu (resp. více), a ta se prostě zavolá. Tohle je prostě pokus o makro/šablonu v jazyce, který nic takového nemá.Ano, souhlasím.
Tiskni
Sdílej: