Už jste se prolétli na webu Google Earth? Přibyl tam Simulátor letu (Nástroje / Simulátor letu). Funguje i bez účtu Google [𝕏].
Byla vydána nová verze 4.7 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Mastodon (Wikipedie) - sociální síť, která není na prodej - byl vydán ve verzi 4.6. Přehled novinek s náhledy v oznámení na blogu.
V Edici CZ.NIC, knižní řady správce české národní domény, vychází nová kniha Martina Malého Kódy, buildy, firmwary. Autor po půl roce od vydání předchozího titulu přichází se svou již sedmou knihou, tentokrát zaměřenou na vývoj programového vybavení pro embedded zařízení. Publikace s podtitulem Základy vývojářského řemesla pro tvůrce hobby elektroniky nabízí praktického průvodce pro všechny, kdo své projekty vytvořené s Arduinem
… více »V Brně na FIT VUT probíhá dvoudenní open source komunitní konference DevConf.CZ 2026. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Byla vydána nová verze 15.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Vývojáři Ubuntu představili projekt Myna, tj. iniciativu zaměřenou na přidání funkce převodu řeči na text do prostředí desktopu Ubuntu. Dle plánu již v Ubuntu 26.10.
Společnost Epic Games představila nový open source systém pro správu verzí Lore navržený pro "bezprecedentní škálovatelnost dat i týmů a optimalizovaný pro projekty, včetně her a zábavy, které kombinují kód s velkými binárními soubory, aby uspokojil potřeby vývojářů i umělců". Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Úřad pro ochranu hospodářské soutěže (ÚOHS) provedl v říjnu 2024 místní šetření u společnosti Seznam.cz. Úřad prověřoval důvodné podezření na možné protisoutěžní jednání, konkrétně zneužití dominantního postavení. Krajský soud v Brně v květnu 2025 konstatoval, že toto šetření bylo nezákonné. Nejvyšší správní soud (NSS) včera rozhodl, že šetření bylo provedeno v souladu se zákonem. Krajský soud bude muset případ posoudit znovu.
Byl představen skládací telefon Commodore Callback 8020. Ani hloupý, ani chytrý. Pro fanoušky Commodore a digitálního minimalismu. Bez webového prohlížeče a sociálních sítí. S předinstalovaným WhatsAppem. S operačním systémem Sailfish OS.
Kdysi jsem si chtěl udělat vlastní webové stránky. Hezké, čisté jednoduché. Ve své třetí verzi jsou stále ve vývoji a technologii jsem věnoval tolik času, že se příliš nedostává na obsah. Vyzkoušel jsem všechny možné jazyky, technologie, CMS, frameworky a jiné buzzwordy, bez přílišného výsledku. Přestože si rád hraju s různými technologiemi, pořád je to pro mě hlavně o obsahu a pohodlná práce s ním je pro mě klíčová. Představuji si web, který se točí kolem dokumentu, jako původní ideály prastarého HTML, jen trochu pohodlnější. Ovšem kromě lidsky zpracovatelného obsahu (nápady, zamyšlení, pohádky...) tu máme i obsah, u kterého je výhodnější, aby za nás udělal práci stroj. U projektů chci automaticky generovat sekci stažení podle souborů v download adresáři, zobrazovat changelogy, etc. Myšlenka je jednoduchá — zkombinovat krásu jednoduchých značkovacích jazyků (Markdown, Textile, RST...) se silou programovacího jazyka (v tomto případě Pythonu) vloženého do dokumentu trochu jako PHP...
0. Přirozenost — co nejvíce se přiblížit lidskému myšlení, aby stálo minimální úsilí převést myšlenku do strojem zpracovatelné podoby. Minimalizovat pomyslnou bariéru mezi rozmanitostí lidské mysli a omezeností stroje.
1. Jednoduchost — abych nemusel mít na zdi přivěšenou referenční příručku
2. Neukecanost — (X)HTML je dost "ukecané" (i když oproti Javě úplný břídil) — moc píšete a málo dostanete. Rád bych se vyjádřil za pomoci minimálního množství zbytečných znaků.
3. Univerzálnost — narozdíl od jednoduchých značkovacích jazyků bych rád plně využil plnou množinu XHTML tagů — bez přímého vkládání XHTML kódu, které většinou není řešeno příliš šťastně (např. nejde používat jednoduché značky uvnitř XHTML bloku)
4. Rozšiřitelnost — možnost vytvářet si vlastní "tagy" či příkazy, které se mohou nějakým způsobem převést na XHTML. Ne všechno se dá řešit přes CSS a ne vždy je to žádoucí. V ideálním případě obecně rozšiřitelná syntaxe (prostřednictvím nějakých regexů či gramatik), aby se vlastní příkazy daly vkládat nejen použitím jakési obecné syntaxe, ale třeba i jejich vlastní. Základ by měl obsahovat v ideálním případě jen naprosto minimální obecnou syntaxi, zbytek doplní jednotlivé moduly. Dá-li Bůh.
5. Kontextovost — plně kontextová gramatika, která např. umožní zpracování všech řádkových značek uprostřed nově vytvořeného blokového tagu, který o nich nemusí mít ani ponětí. Prostě nastaví, že chce obsah zpracovat v řádkovém kontextu.
6. Programovatelnost — podpora rozumného vkládání Pythoního
kódu (případně s rozšířením na další programovací jazyky),
blokový exec příkaz, klasická eval syntaxe $proměnná
a ${výraz}. Jednoduché vkládání řídících konstrukcí
(if, for, ...), jejihž obsahem není kód, ale kus dokumentu.
Vhodné pro generovaná data jako tabulky apod.
7. Objektovost — každý "kus dokumentu" — tedy nějaký text, prvek, nebo jejich posloupnost, i celý dokument, by měl být schopen být reprezentován nějakým objektem — nad kterým půjde udělat nějaké zpracování, a hlavně jej půjde na nějaké místo nějakého dokumentu zase vložit — tímhle by se daly řešit layout šablony a podobné
8. Sémantičnost — výsledkem by měly být výhradně sémantické značky, i při použití vlastních. Vzhled se vyřeší odděleně. Minimalizovat "režijní" tagy nutné z technických důvodů (i když to ne vždy lze).
9. Lineárnost — zpracování lineárním, ideálně jednoprůchodovým parserem, bez nutnosti přednačtení celého vstupu do paměti. Možnost zpracování dat z pajpy.
10. Strukturovanost — jasná, logická, vnořovatelná struktura. Musí být jasné co k čemu patří. Nepoužívat pevné úrovně nadpisů (kdo se s tím má přepisovat, když zjistí, že chce celou sekci zabalit do jiné?)
Jednak je třeba zachovat jednoduchou syntaxi, na kterou jsou
všichni zvyklí (prázdný řádek oddělující odstavce,
*zvýraznění*, etc.), ale druhak také vytvořit syntaktická
pravidla obecná, pro vkládání libovolných příkazů, která ovšem
nesmí být příliš složitá nebo jít na obtíž. Ideálně by si měla
vystačit s minimálním počtem speciálních znaků, aby ostatní
zbyly na "volná" syntaktická pravidla.
Následuje spíše taková sbírka hrubých nápadů, rád budu za jakékoliv připomínky:
Základem syntaxe je příkaz. Každý příkaz musí mít dopředu definováno, v jakém kontextu/režimu se může vyskytovat. Celý parser funguje jako takový state machine, svým způsobem. Žádný příkaz nemůže být současně řádkový i blokový, protože by se nepoznalo, o který případ jde, pokud by se vyskytl na začátku bloku.
Každý příkaz má parametry, nejspíše poziční i pojmenované, jako jsme zvyklí z Pythonu, a případný textový obsah, který může případně obsahovat i další prvky. U blokových příkazů jsou možné dvě základní podoby syntaxe: odsazená (nám Pythonistům dobře známá) a s explicitním ukončením (ala Ruby či Pascal). Myslím, že obě mají něco do sebe (při psaní textu by odsazení mohlo být nepříjemné, ale v dokumentu, kde převládá struktura — např. layoutu stránek — by zvýšilo přehlednost), proč tedy neimplementovat obě? Třeba takto:
:section
text
:section
podsekce
:end
pokračuje sekce
:end
a :section: Tady máme nějaký text :code: and some(code) a tak dále...
Samozřejmě případně libovolně kombinovat. Dvojtečka jako začátek
příkazu je používána z čistě estetických důvodů — pokud by se
ukázalo, že je potřeba v textu příliš často, není problém zvolit
jiný znak. Jinak se samozřejmě dá escapovat příkazem ::.
Pokud mají inline příkazy textový obsah, asi by odsazení nebylo příliš vhodné, myslím, že docela hezky by mohl vypadat například následující zápis:
Toto je odstavec s :em{zvýrazněným} písmem a odkazem na
:link http://seznam.cz;
Středník je nutný aby se poznal konec příkazu, protože narozdíl
od blokového, který můžeme uzavřít koncem řádku, za ním ještě
může následovat další text. Ovšem po ukončovací } již není
třeba, jak jistě všichni céčkaři chápou;)
S takto překvapivě jednoduchou syntaxí, která si vyžádala
obětování defacto dvou znaků (v kontextu běžného textu se mohou
objevit jen : a }) už se toho dá udělat docela hodně.
A na první pohled to vypadá i čitelně:
:header První dokument
:section
:header Úvod
V dokumentu se mohou vyskytovat různé věci. Třeba takové
:img obrazky.png Obrázky;, :link http://seznam.cz{
Odkazy}.
:if 'MSIE' not in environ['HTTP_USER_AGENT']:
:link #{:img $logo; :)}
Ony tam jdou i obrázkové odkazy, ale Exploreristům
:strong{ani muk}.
:end /*konec sekce*/
Ale jistě by se to dalo udělat ještě čitelněji s trochou syntax sugaru...
První dokument
==============
Úvod
<<<< /*nadpis začánající sekci — jen ukázka, nevím, jestli
to k něčemu bude */
:defimg logoimg $logo
:defimg obr obrazky.png Obrázky
:deflink imglink #{[logoimg]{logo} :)}
:deflink ukazka http://seznam.cz{Odkazy}
V dokumentu se mohou vyskytovat různé věci. Třeba takové
[obr], [ukazka].
:if 'MSIE' not in environ['HTTP_USER_AGENT']
[imglink]
Ony tam jdou i obrázkové odkazy, ale Exploreristům
**ani muk**
:end MSIE /*end ignoruje vše za ním — můžeme si třeba popsat co končí*/
>>> /*konec sekce; nic lepšího mě zrovna nenapadlo*/
Základní trik se jmenuje vkládané objekty a ve většině podobných věcí je dnes běžný. Prostě si definuji objekt (odkaz, obrázek, …) a později se na něj odkazuji. Jen narozdíl od jednoduchých jazyků nebude v duchu průběhu programu shora dolů možné implementovat používání objektů nad jejich definicí, třeba všechny odkazy definovat na konci odstavce, etc.
Při samotném vložení objektu se někdy hodí změnit/doplnit určité parametry,
jako např. v ukázce výše textový obsah. Měnit můžeme i jiné parametry,
např. [mujimg alt=Nějaký popisek|title=Titulek] (možná by byla
přijatelnější qouted syntaxe [mujimg alt="Nějaký popisek" title=Titulek]
...
Ukázky zmíněné víše jsou jen takovým hrubým nástinem obecné idey a rád bych slyšel také názory a náměty jiných. Zatím to vypadá, že z toho vznikne ne-zcela-texu-nepodobné monstrum se složitým syntaktickým aparátem, ale doufám, že pro člověka trochu čitelnější a hlavně zaměřené na XHTML výstup a tedy i webové prezentace...
Tiskni
Sdílej:
Co Lisp? (to bude flame...)
(header První dokument)
(section
(header Úvod)
V dokumentu se mohou vyskytovat různé věci. Třeba takové
(img obrazky.png Obrázky)(link http://seznam.cz Odkazy)
(if 'MSIE'
(link (img $logo ))
Ony tam jdou i obrázkové odkazy, ale Exploreristům
(strong ani muk).
)
)
Tohle by se mi fakt líbilo. 
No ja tedy nevim, ale mysl, ktera by se lepe pracovalo s XML nez s vyse uvedenym zapisem, ma k te moji hodne daleko.
No vida, nemyslel jsem to predtim uplne vazne, ale tohle je fakt hezke. Jeste poresit escapovani zavorek (a dalsich znaku) a je vymalovano. Mozna by bylo lepe pouzit hranate - nedavno jsem premyslel nad Lispem s hranatymi zavorkami, maji tu velkou vyhodu, ze maji na klavesnici vlastni klavesy (resp. ja jsem premyslel nad Lispem, kde by bylo jedno, jakou ze tri zavorek clovek pouzije, pokud by se matchovaly, a tedy by se lepe vizualne pocitaly).
Na originalniho autora - mel byste si podle me predevsim vyjasnit, jestli chcete pravidelnou syntaxi (jako Lisp, HTML nebo obvykle programovaci jazyky), nebo nejakou "lidsky citelnou" (jako maji treba Wiki, YAML nebo ruzne publikacni systemy).
Pravidelna syntaxe ma jasna pravidla, snadno se parsuje pomoci bezkontextove nebo LL(1) gramatiky, jasne escapovani (vetsinou), a jasne definovano, co je syntakticky spravne a spatne. Naopak lidsky citelna syntaxe miva mnohem slozitejsi pravidla a parsery, nejasne ecapovani (pokud vubec) a byva daleko volnejsi, co se tyce zpracovani chyb. Toto rozhodnuti IMHO zasadne ovlivnuje zpusob, jakym bude parser napsany.
Mozna by bylo lepe pouzit 2 jazyky - jeden na markup a druhy na logiku. Kombinovat je do jednoho je nesmyslne.
Líbí se mi myšlenka odkazování na objekty, to by mohlo být hodně užitečné a lehce propojitelné s generovaným obsahem. Ale znamená to nutnost víceprůchodového zpracování.