Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Jasně, nejedná se o nic převratného a tato technika se používa běžně. I tak si myslím že si zaslouží článek, už jen proto že jsem si k ní sám přišel přes JSON a až poté si uvědomil že se o nic převratného nejedná .
Python přímo v základní distribuci obsahuje knihovny pro práci s ini (ConfigParser), JSON (json), balíčky pro yaml (pyYaml) jsou snad v každé distribuci. Já se pro konfiguraci našeho projektu rozhodl použít JSON, kvuli pokročilejší struktuře než jednoduché ini a také protože json modul je součástí standardní python distribuce. Ukázalo se to jako špatná volba, protože jednoduše naimportovat soubor jako python kód vyjde prakticky nastejno a navíc umožňuje používat callbacky, reference atd. Ukázalo se to jako dobrá volba, protože přejít z JSON na import python kódu je až drasticky jendoduché
Předvedu na jednoduchém příkladu s vymyšlenou konfigurací jednoduchého serveru:
Json config:
{ "name":"lucifer", "listen_ip":"127.0.0.1", "listen_port":"666", "requests" : { "/A":"filepath", "/B":"filepath" } }
Použití z pythonu
import json conf = json.load(open('config_file')) conf['name'] conf['requests']['/A'] # ...Využijme toho, že JSON dictionary je vlastně validní python, takže stačí přidat název proměnné před JSON dictionary a nahradit json za imp a získame všechny výhody (a nevýyhody - musíme teď více duveřovat configum) loadováni přímo python kódu místo JSONu.
config:
config = { "name":"lucifer", "listen_ip":"127.0.0.1", "listen_port":"666", "requests" : { "/A":"filepath", "/B":"filepath" } }
Použití z pythonu
import imp conf = imp.load_source("config","config_file").config conf['name'] conf['requests']['/A'] # ...
Takto budou configy mnohem mocnější a jednoduše omezíme zbytečnou duplikaci.
Pokud například chceme pustit server jěšte na jednom extra portu a s jiným jménem
Druhý config:
import prvni_config config = prvni_config.config config["listen_port"] = "777" config["name"] = "inferno"
Tiskni Sdílej:
Oproti tomu s programovanou konfigurací neexistuje (tedy alespoň není znám) způsob jak sestavit z načtené konfigurace zpět zdrojový soubor a při tom mít jistotu, že je stejný jako původní (s tolerancí na formátování). Takže případný editor konfigurace nemůže nic, než vygenerovat zcela nový konfigurační soubor a zahodit vše, čemu v předloze nerozuměl.Hm, dumam tady jiz chvili nad nevyhodou reseni obycejneho rekurzivniho pruchodu strukturou, serazeni polozek napr. podle abecedy a ulozeni (v pripade kolekce samozrejme nic neradit a zachovat stavajici poradi). V ukladani a nacitani a pripadnem pouzivani diffu na takoveto konfiguraky by nemely nastat zadne problemy, takze vidim problem akorat v tom, ze se v konfiguraku muze objevit nejaky skodlivy kod nestatickeho (spustitelneho) charakteru jako velke bezpecnostni riziko. Celkovy prinos tohoto jednodussiho reseni imho ale prevazi pred nedostatky.
# prvni config config = { "name":"lucifer", "listen_ip":"127.0.0.1", "listen_port":"666", "requests" : { "/A":"filepath", "/B":"filepath" } }
# druhy config import prvni_config config = prvni_config.config config["listen_port"] = "777" config["name"] = "inferno"A chceš udělat grafický nástroj pro editaci takové konfigurace, aby to měl uživatel jednodušší. Zní to lehce. Načteš config, zobrazíš dialog s pár políčky, uživatel něco upraví a výsledek zas uložíš. S prvním configem problém není. Je to celkem jednoduchá datová struktura – pár vnořených hash tabulek, žádný problém. Ale co ten druhý config? Když ho načteš, dostaneš tohle:
config = { "name":"inferno", "listen_ip":"127.0.0.1", "listen_port":"777", "requests" : { "/A":"filepath", "/B":"filepath" } }To je snadné. Ale hádej, co se stane, když to uložíš? A co se stane, když pak změníš první config?
config = { "name":"inferno", "listen_ip":"127.0.0.1", "listen_port":"777", "requests" : { "/A":"filepath", "/B":"filepath" } }A nejak nepobiram proc bych mel menit prvni config. Rekneme, ze ho zmenim na nasledujici:
# prvni config config = { "name":"lucifer", "surname":"the_big_boss", "listen_ip":"127.0.0.1", "listen_port":"666", "requests" : { "/A":"filepath", "/B":"filepath", "/C":"some_new_filepath" } }Kdyz tohle nactu do GUI, nic divneho se nestane a bude to v poradku upravitelne. Kdyz na to postvu diff, bude to krasne citelny patch a tedy se take nic hrozneho nestane. Ano, spatne jsem se vyspal, takze muzu pekne placat, ale proste mi porad nedochazi v cem je problem .
Nebylo by lepší používat třídy/instance + mapování na nějaký serializační formát.Co by tím získal, kromě pár set řádků zbytečného kódu navíc?
"listen_port"
, "requests"
a další) se obecně nedoporučuje (nejen) kvůli překlepům a je tedy vhodné použít místo toho konstanty. Pak se mi to ale rozpadne a rozplizne – někde mám definované konstanty stylem:
CONFIG_NAME = "name"; CONFIG_LISTEN_IP = "listen_ip";a všude možně v kódu roztroušená volání
config[CONFIG_NAME]
. A nikde není na jednom místě definovaná ta struktura – v konfiguráku bude zase jen nějaká ukázka, v dokumentaci možná výčet parametrů… ale víme, jak to chodí s dokumentací – jednak není strojově čitelná a jednak se někdy zapomíná na její aktualizaci. Proto považuji za užitečné mít někde (definice třídy/tříd) definovanou celou strukturu konfigurace.
Pak když někde ty konfigurační volby používáš, tak je taky příjemné, když napíšeš instance.vlastnost
a IDE ti napovídá, jaké vlastnosti tam jsou + jejich dokumentaci, místo abys střílel od boku nějaké config[KONSTANTA_NEBO_LITERÁL]
a doufal, že tam taková vlastnost bude a že bude mít význam, který předpokládáš, doufat, že jsi neudělal překlep nebo nepoužil konstantu patřící do jiného rozsahu (to se sice dá řešit přes různé předpony – ale při větší strukturovanosti je to odporně dlouhé…). Proč vlastně nepoužít OOP, když ho máme k dispozici?
Přijde mi, že jedna třída s pár „zbytečnými“ řádky navíc dokáže ušetřit spoustu dokumentace, příkladů, zbytečného kódu jinde a hlavně nervů a nejistoty (např. překlepy v literálech nezřídka vedou k tomu, že program sice nespadne, ale funguje špatně a na chybu je obtížné přijít).
class Config(object): pass config = Config() config.__dict__ = literal_eval(read(config_path))a mas ze slovniku udelanej (uplne zbytecnej) objekt. Bum.
Ono pak taky budeš chtít napsat dokumentaci, takže nějaká struktura, která popíše přípustné volby, jejich hodnoty a jejich význam je celkem potřeba.No právě. Použil bych třídu + anotace a dalo by se z toho vygenerovat XML schéma a docela slušná dokumentace.
Asi bych takovou strukturu dal parseru a přihodil do ní i funkce… Takže vše bude pohromadě a přehledné.Můžeš napsat nějakou ukázku? Zajímalo by mne, jak by se tohle řešilo v Pythonu.
json_encode(json_decode(json))
, tak dostaneš přesně to samé jako na vstupu (až na nevýznamné bílé znaky). To hodně zjednodušuje práci s takto uloženými daty. Přidání komentářů tohle buď rozbije, nebo neskutečně zesložití práci. Takže vlastně nevýhoda JSONu je jeho výhodou.
Ale na ručně upravovanou konfiguraci se to opravdu moc nehodí. Naopak na konfiguraci upravovanou z nějakého GUI to je super, neboť to zůstává snadno upravovatelné i bez GUI, ale přitom se nic neztratí.
To hodně zjednodušuje práci s takto uloženými daty. Přidání komentářů tohle buď rozbije, nebo neskutečně zesložití práci. Takže vlastně nevýhoda JSONu je jeho výhodou.V XML je komentář uzlem a není problém je uložit zpět stejně jako ostatní druhy uzlů (textové, elementy atd.).
>>> pickle.dump({'x':'y'},open('/tmp/yodawg','w') ) >>> d = pickle.load(open('/tmp/yodawg')) >>> print (d)
Ano pickle znám, problém je s tím, že nezapíšete to co máte ve slovníku.? Vždyť to v pohodě funguje. Na složitější věci je ale asi lepší shelve.