Organizátoři Dne IPv6, tradiční akce věnované tématům spojeným s tímto protokolem, vyhlásili Call for Abstracts. Na webu konference mohou zájemci přihlašovat příspěvky o délce 20 nebo 40 minut či 10minutové lighting talky a to až do 30. dubna. Tvůrci programu uvítají návrhy přednášek z akademického i komerčního sektoru, které mohou být technického i netechnického zaměření. Den IPv6 se letos uskuteční 4. června a místem konání bude i
… více »Euro-Office (Wikipedie) je evropský fork open source kancelářského balíku OnlyOffice. Za forkem stojí koalice firem IONOS, Nextcloud, Eurostack, XWiki, OpenProject, Soverin, Abilian a BTactic. Cílem je zajistit digitální suverenitu Evropy a snížit závislost na neevropských platformách. Projekt vznikl mimo jiné v reakci na nedávné uzavření cloudové služby OnlyOffice. OnlyOffice obviňuje Euro-Office z porušení licenčních podmínek. Na možné problémy upozorňuje i Collabora Online. Jednostranná změna licence není v pořádku.
Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
. Takže nápad podporuji.
) třeba takhle (za předpokladu, že id spotů jsou v čase rostoucí):
SELECT * FROM blog WHERE id IN (SELECT MAX(id) FROM blog GROUP BY autor) ORDER BY datum LIMIT 10
a nestačí na to náhodou .. max(id_prispevku) .. group by id_prispevku) ..Jako bez ORDER BY? To by stačit mohlo, ORDER BY jsem tam napsal ještě před tím, než jsem si uvědomil, že brát nejmladší příspěvek ve vniřním SELECTu by znamenalo asi třetí vnořený SELECT
Otázka také je, zda WHERE id IN (...) zachovává pořadí z vnitřního SELECTu…
SELECT * FROM blog ORDER BY datum GROUP BY id_uzivatele LIMIT 10 ale to alespoň v mysql nefunguje - moje představa byla - uspořádá se to podle data, pak se z toho vytvoří ty skupiny (takže uvnitř skupiny to zůstane uspořádané) a vrátí se první řádek té skupiny vaše řešení samozřejmě funguje, ale zkoušel jsem to bez toho vnořeného dotazuTo nemůže fungovat z několika důvodů:
ORDER BY se provádí až po GROUP BY (a když to do SQL nepíšete opačně, dostanete nejspíš chybu syntaxe)SELECT pak můžete použít buď sloupec, který je v GROUP BY (protože ten je pro celou skupinu stejný), nebo agregační funkci (která se spočítá přes všechny řádky ve skupině.
(to nedá moc práce, při jejich četnosti
) Každopádně ty vnořené selecty by měly být novinka ve verzi čtyři jedna, aspoň si to myslím.
Ta cisla jsou skutecne rostouci, resp. byla nez jsem napsal odlozena publikovani. Takze by se ted muselo tridit podle created sloupecku. Ale to je detail.Kdepak, to by byl právě problém
Zatím intuitivně bych řekl, že by tam musel být ještě třetí vnořený SELECT, a to ještě bůhví jestli by to pomohlo…
Spise se snazim pochopit, co presne ten dotaz bude delat. Ten vnoreny nalezne cisla vsech zapisu podle autoru, ze? A bude to omezeno jen na nejvetsi cislo pro kazdeho uzivatele? To by bylo resenim, za predpokladu ze to mysql zvladne.Ten vnořený najde největší id od každého autora.
Pokud ano, jde omezit ten pocet uzivatelu v tom subselectu? Preci jen delat tuhle tabulku pro vsechny uzivatele, kdyz potrebuju jen prvnich dvacet .. Nejlepsi to bude vyzkouset v reale, treba to bude tak rychle, ze se nad tim mavne rukou ..Šlo by to omezit i uvnitř, je to dokonce lepší. Ten LIMIT na vnějším SELECTU je pozůstatek z doby, kdy jsem to uvnitř chtěl třídit podle času - než mi došlo, že to bude složitější.
Kazdopadne diky. Ja si to furt komplikoval ruznymi podminkami pro efektivnost ..To znám. Ale poslední dobou jsem skončil u SELECTů, u kterých mě překvapilo, že to databáze vůbec zvládne. Ale byl to jeden SELECT, ze kterého vypadly rovnou hodnoty, které jsem potřeboval, tak to stačilo
Tak jde to i podle data na 2 SELECTy, akorát to vybere autora a datum jeho nejnovějšího příspěvku, a pak to hledá záznam, kde je stejný autor a datum – což není úplně nejhezčí řešeníTa cisla jsou skutecne rostouci, resp. byla nez jsem napsal odlozena publikovani. Takze by se ted muselo tridit podle created sloupecku. Ale to je detail.Kdepak, to by byl právě problémZatím intuitivně bych řekl, že by tam musel být ještě třetí vnořený SELECT, a to ještě bůhví jestli by to pomohlo…
Ale on by ten třetí SELECT asi nedělal nic jiného
Takže varianta B:
SELECT * FROM blog WHERE (autor, datum) IN (SELECT autor, MAX(datum) FROM blog GROUP BY autor LIMIT 10) ORDER BY datum
GROUP BY a místo MAX() je LIMIT, což je např. u PostgreSQL (zatím) rychlejší. Jestli to bude rychlejší i v MySQL je asi potřeba jedině vyzkoušet.
SELECT * FROM autor, blog
WHERE blog.autor = autor.id AND blog.id IN (
SELECT blog.id FROM blog
WHERE blog.autor = autor.id ORDER BY datum LIMIT 1
)
LIMIT 10
Ale bohuzel to s 4.0 verzi mysql nedam. Zkusim pozadat admina o upgrade, snad to na debianu pujde udelat rozumne. Stejne me tato verze stve, casto vidim v logu, ze se na cas zasekne a prestane komunikovat s JDBC ovladacem. Az si pomalu rikam, ze bych radsi presel treba na Firebird ..
Jen pro strycka prihodu, prelozene SQL do schematu abicka:
SELECT * FROM polozka WHERE (pridal, vytvoreno) IN (SELECT pridal, MAX(vytvoreno) FROM polozka where typ=12 GROUP BY pridal LIMIT 10) ORDER BY vytvorenoA to jsem neresil, ze tohle musim zapouzdrit jeste do joinu s tabulkou relace
Ten vnitrni select spustim, prvni volani trvalo pul sekundy, dalsi uz jen 2 setiny sekundy. Asi tedy ani nema cenu tvorit index na ten sloupecek vytvoreno. Vnitrni select ale skoncil na syntax error.
Ale bohuzel to s 4.0 verzi mysql nedam. Zkusim pozadat admina o upgrade, snad to na debianu pujde udelat rozumne. Stejne me tato verze stve, casto vidim v logu, ze se na cas zasekne a prestane komunikovat s JDBC ovladacem. Az si pomalu rikam, ze bych radsi presel treba na Firebird ..S Firebirdem jsem chvilku také koketoval, ale pak jsem skončil u PostgreSQL. A od té doby nepřemýšlím o tom, zda to umí databáze, ale jestli to dokážu v SQL napsat
(Pravda, u toho třetího SELECTu - bez GROUP BY - mne PostgreSQL příjemně překvapil, že i v tomhle vnitřním SELECTu se umí odkázat na vnější tabulku
Jen pro strycka prihodu, prelozene SQL do schematu abicka:
SELECT * FROM polozka WHERE (pridal, vytvoreno) IN (SELECT pridal, MAX(vytvoreno) FROM polozka where typ=12 GROUP BY pridal LIMIT 10) ORDER BY vytvoreno
Ten vnitrni select spustim, prvni volani trvalo pul sekundy, dalsi uz jen 2 setiny sekundy. Asi tedy ani nema cenu tvorit index na ten sloupecek vytvoreno. Vnitrni select ale skoncil na syntax error.Nevím, zda MySQL umí používat MAX() s indexem, pro ORDER BY by se každopádně index na
vytvoreno hodil. Ono by to šlo asi přepsat i bez toho vnitřního SELECTu, jenže to už by asi byl kartézský součin dvou nebo tří tabulek, spousta MINů nebo MAXů, a celkově by to byla spíš zkouška toho, co databáze vydrží, než použitelný příkaz
všechny takové ty zápisky zavánějící nějakým flamováním a nedodržením těchto pravidel by se nějak zmrazily a zamklyTo je a) Velmi subjektivní. Co je pro jednoho otravné, je pro druhého zábavné. b) Náročné na čas. Nemáme lidi na to, aby kontrolovali kvalitu všech blogů.
Neomezovat. To leda tak vyvolá ve fanaticích pocit, že je jim nějak ubližováno a povede k mazání zápisů.Souhlasím. Omezování k blogům nepatří. Je-li problém se záplavou nezajímavých zápisů (i když je zajímavost relativní), mělo by se to řešit nějakou funkcí, která by usnadnila orientaci, ne limitem.
file:///. Informační hodnota je nulová, stránka při tom není prázdná a na většině počítačů to vypadá ve stejném prohlížeči stejně.
)
omezovat obsah blogů jenom na GNU/Linux se mi zdá, promiňte, scestné.S tím souhlasím.
Tiskni
Sdílej: