Chcete vědět, co se odehrálo ve světě techniky za poslední měsíc? Nebo si popovídat o tom, co zrovna bastlíte? Pak dorazte na prosincovou Virtuální Bastlírnu s mikrofonem a kamerou, nalijte si něco k pití a ponořte se s strahovskými bastlíři do diskuze u virtuálního piva o technice i všem možném okolo. O čem budou tentokrát strahováci referovat? Téměř každý už si všiml významného zdražení RAM a SSD, jsou zde ale i příjemnější zprávy. Průša uvádí
… více »Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) podporuje vyjádření partnerů ze Spojeného království, kteří upozorňují na škodlivé aktivity společností Anxun Information Technology (též „I-S00N“) (pdf) a Beijing Integrity Technology (též „Integrity Tech“) působících v kyberprostoru a sídlících v Čínské lidové republice (ČLR). Tyto společnosti jsou součástí komplexního ekosystému soukromých subjektů v ČLR,
… více »Společnost Pebble představila (YouTube) prsten s tlačítkem a mikrofonem Pebble Index 01 pro rychlé nahrávání hlasových poznámek. Prsten lze předobjednat za 75 dolarů.
Společnost JetBrains v listopadu 2021 představila nové IDE s názvem Fleet. Tento týden oznámila jeho konec. Od 22. prosince 2025 již nebude možné Fleet stáhnout.
Byl vydán Mozilla Firefox 146.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 146 bude brzy k dispozici také na Flathubu a Snapcraftu.
Před rokem převzala Digitální a informační agentura (DIA) vlastnictví a provoz jednotné státní domény gov.cz. Nyní spustila samoobslužný portál, který umožňuje orgánům veřejné moci snadno registrovat nové domény státní správy pod doménu gov.cz nebo spravovat ty stávající. Proces nové registrace, který dříve trval 30 dní, se nyní zkrátil na několik minut.
IBM kupuje za 11 miliard USD (229,1 miliardy Kč) firmu Confluent zabývající se datovou infrastrukturou. Posílí tak svoji nabídku cloudových služeb a využije růstu poptávky po těchto službách, který je poháněný umělou inteligencí.
Nejvyšší správní soud (NSS) podruhé zrušil pokutu za únik zákaznických údajů z e-shopu Mall.cz. Incidentem se musí znovu zabývat Úřad pro ochranu osobních údajů (ÚOOÚ). Samotný únik ještě neznamená, že správce dat porušil svou povinnost zajistit jejich bezpečnost, plyne z rozsudku dočasně zpřístupněného na úřední desce. Úřad musí vždy posoudit, zda byla přijatá opatření přiměřená povaze rizik, stavu techniky a nákladům.
Organizace Free Software Foundation Europe (FSFE) zrušila svůj účet na 𝕏 (Twitter) s odůvodněním: "To, co mělo být původně místem pro dialog a výměnu informací, se proměnilo v centralizovanou arénu nepřátelství, dezinformací a ziskem motivovaného řízení, což je daleko od ideálů svobody, za nimiž stojíme". FSFE je aktivní na Mastodonu.
Paramount nabízí za celý Warner Bros. Discovery 30 USD na akcii, tj. celkově o 18 miliard USD více než nabízí Netflix. V hotovosti.
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í.