Vizualizace katastralní mapy na celém území ČR bez omezení dat podle úrovně přiblížení (zoomu).Nechte se unášet po parcelách v ČR. Nejlépe na 4k monitoru a vyšším, nebo použijte výřez jako antistresové omalovánky…Stiskněte kostku 🎲 na random území, vytiskněte a vybarvěte. Tlačítko 3D vás přenese do 3d ikatastr.cz kde můžete zjistit kde se nacházíte. Můžete také přepínat inverzní variantu ◐, zapnout automatický průlet ▶ , nebo pořídit záznam pohybu po mapě jako video 🔴.
Potřebujete poměrně rychlé připojení a počítač který ‘to zvládne’ resp. .. data jsou velká a těžká a je potřeba trpělivosti.
Napište pokud máte nápad tam přidat nějakou zajimavou funkci a nebo jen tak, co na to říkáte…
AI coding agents are useful. However I keep wondering whether trade-off is limitation in knowledge flow inside teams. A team can become faster at producing output while becoming worse at building shared understanding. And that shared understanding depends not only on what the team knows, but also on the social fabric through which knowledge moves : trust, explanation, mentorship, disagreement, and shared ownership. If that weakens, the long-term cost may be larger than we think. I think of it as the risk of “team knowledge depreciation”: trading long-term learning and collective understanding for short-term gains in speed.
This is, in some sense, a more grounded follow-up to my earlier , over-excited post “Developer Twin”.
1. AI may optimize for local speed while weakening global understanding. A patch gets written faster, but fewer people understand why it exists, which trade-offs were made, and what it may affect elsewhere. Individual throughput and collective intelligence are not the same thing.
2. The biggest risk may not be code quality, but knowledge flow. Teams do not work only because individuals are smart. They work because knowledge moves between people and gets recombined into a shared view of the system.
3. A team does not need everyone to understand everything. But it does need a healthy way to reconstruct the whole together. That shared reconstruction may become weaker if too much work shifts from human-to-human exchange to human-to-AI interaction.
4. Documentation can serialize rules, but not fully transmit judgment. Skills, playbooks, prompts, and agent instructions can capture explicit knowledge. They do not fully capture the painful experience from which engineering judgment is formed.
5. Mentoring a person compounds. Steering an AI often does not. When you invest in a junior engineer, the team may get that investment back over time. With current AI systems, much of that effort is spent in the moment.
6. Faster delivery can hide a weakening learning culture. A team may ship more while learning less. Over time, that can turn into a quiet form of knowledge capital depreciation: accumulated expertise is consumed faster than it is renewed. The deeper question is what kinds of team behavior AI quietly rewards, and what kinds it replaces.
7. The real challenge is not just building faster systems, but preserving the human mechanisms that make learning possible. Speed matters. But so do explanation, mentorship, disagreement, review, and shared ownership.
Mám doma starší stavebnici Logitronik 01, která už má po letech nespolehlivé kontakty. Zkusil jsem proto převést jednu z jeho základních úloh (invertor / NOT) na stavebnici Saimon 1 – školní verze (DEC/BCD)… z aukra
Saimon je mechanicky i elektricky velmi pěkně zpracovaný.Celá stavebnice působí moderně a nadčasově, je robustní a počítá i s chybami při zapojování – například má základní jištění proti přetížení. To z ní dělá vhodnou platformu nejen pro výuku, ale i pro opakované experimentování bez obav z poškození
K vyzkoušení jsem zvolil z Logitroniku 01 obvod č. 3 “Logický člen “NOT” jako invertor.” Obvod samotný byl jednoduchý, pro převod schématu jsem použil ChatGPT5.2 – občas otravného “robodruha”.
Při řešení zapojení mi také pomohla konzultace přímo s autorem stavebnice. Upozornil mě, že nad spínači jsou zdířky 110–115 na rezistory,které lze jumperem nastavit jako pull-up nebo pull-down, aby při rozepnutí spínače nebyl vstup „ve vzduchu“. Zároveň upřesnil, že k integrovaným obvodům je nutné přivést +5 V, zatímco zem je rozvedena přímo na plošném spoji.
Výsledný postup propojení na Saimon 1 BCD
Zapojení funguje stejně jako původní úloha na Logitroniku a lze stejným způsobem převádět i další logické obvody.
Chat GPT 5.2 umí porozumět schématům, dokonce zaznamenal i ručně dokreslené napájení a ground. Dokáže poměrně dobře vysvětlit základní koncepty v elektronice a doplnit tak mezery, které se např v původním Logitroniku nevysvětlují.
Poznámka k dalším možnostem
Při tomto převodu se ukázalo, že je praktické mít možnost se průběžně doptávat na detaily zapojení
a interpretaci schémat. Nabízí se proto myšlenka jednoduchého Custom GPT zaměřeného přímo
na stavebnici Saimon, které by pracovalo s ověřenými podklady (mapa zdířek, příklady zapojení)
a sloužilo jako interaktivní náhrada stručného návodu.
Do podobného rámce by šlo zařadit i jednoduché ukázky principů učení,
například základní analogový nebo diodový perceptron, kde je „učení“
realizováno změnou zapojení a zpětnou vazbou, nikoli softwarem.
9. album od Maxmiliána Šumbery s názvem Letní imprese je nově k dispozici na Audiomack. Skladby Duo pro hoboj a klavír No.1 “Ametystové červánky” a Rozkvetlé louky se umístily ve zlátém pásmu soutěže XIII. Múzy I.Hurníka 2025. Navíc první z nich dostala také zvláštní cenu v kategorii instrumentální hudby.
Disclosure:AI-assisted content — consult with an organic-developer.
When building low-level libraries for the JVM — especially those that interact with JNI, rendering engines, or MethodHandles — the exact bytecode emitted matters. Recently I hit a limitation in Kotlin that reminded me why the JVM world still needs Java for certain things.
Where Kotlin Emits Different Bytecode than Java
Here are the main areas where Kotlin’s generated bytecode diverges from Java’s, and why that matters.
Area
Java
Kotlin
Takeaway
Signature-polymorphic calls
Emits correct signature for MethodHandle.invokeExact
Falls back to (Object[])Object, causing mismatches
Keep these calls in Java
Default parameters
No defaults → use overloads
Generates synthetic $default methods with bitmask
Avoid defaults in public APIs for Java clients
Companion objects / @JvmStatic
True static methods
Methods live in $Companion unless annotated
Use @JvmStatic or plain Java for static APIs
Internal visibility
Package-private supported
internal compiles to public + metadata
Don’t rely on internal for cross-language encapsulation
SAM interfaces
Any functional interface = lambda
Only fun interface supports SAM; lambdas may create synthetic classes
This wasn’t an isolated issue. Kotlin differs from Java in other ways that make it risky for core interop code:
Area
Java
Kotlin limitation
JNI declarations
static native boolean render(int, int)
Needs @JvmStatic in a companion object; generates synthetic names
JNI header generation
javac -h works directly
No header generation for Kotlin sources
Checked exceptions
Enforced at compile-time
Kotlin ignores them (all unchecked)
Raw types
Allowed (List)
Always requires generics (List<*>)
Wildcards
? super, ? extends supported
Only in / out; cannot express everything
Default params
Not supported (overloads instead)
Compiles to synthetic $default methods
Static members
static keyword
Requires @JvmStatic in object/companion
Suspend functions
N/A
Compiled to Continuation-based state machines, awkward for Java callers
Why This Matters for Library Code
A low-level library often deals with:
JNI ↔ JVM bridges
OpenGL or native rendering loops
Performance-critical calls that must inline
Reflection and MethodHandles
All of these require predictable bytecode and signatures. Kotlin often inserts synthetic classes ($Companion, $DefaultImpls, $WhenMappings) or adapts signatures in ways Java clients (and JNI) do not expect.
Why Keeping the Library Core in Java Makes Sense
Benefit
Why It Matters
One language to maintain
Single codebase, easier contributor onboarding, faster builds
Interop for everyone
Java APIs work in all JVM languages; Kotlin clients lose nothing; Java clients stay safe from Kotlin-only features
JNI friendliness
Direct mapping of Java types to JNI (int → jint, boolean → jboolean); javac -h header generation works; avoids $Companion/$DefaultImpls surprises
Bytecode predictability
No synthetic baggage ($Companion, $default, $WhenMappings); avoids mismatched signatures; JIT optimizes exactly as written
Strategy: Java Core + Optional Kotlin API
The pattern I adopted (and which many frameworks use):
Core in Java
Predictable bytecode
JNI header generation
Works with MethodHandle, VarHandle, Unsafe
Safe for both Java and Kotlin clients
Optional Kotlin extensions (-ktx)
Extension functions for ergonomics
Coroutines (suspend wrappers)
Null-safety
DSLs for configuration
This is the same model Android Jetpack follows: androidx.core in Java, androidx.core-ktx in Kotlin.
Takeaways
Point
Why
MethodHandle support
Java compiler emits exact signatures ((int,int)boolean), Kotlin falls back to (Object[])Object, causing runtime issues
Po skoro 30 letech od ‘obyčejné’ klavírní verze je tu verze orchestrální. Překvapivě bohatá a rozšiřující původní námět. Zvláště střední a závěrečná, epicky znějící část, se mi velmi líbí. Orchestraci z původní skladby vytvořil a vhodně rozšířil Maxmilián Šumbera.
Night runner, by Maxmilián Šumbera, my favourite one released ! I love the uncommon accents forming a distinct rhythm, interleaving with a faster pulse — like a heartbeat echoing the rhythm of feet hitting the ground in that first minute.
This is another nice half-frame camera — the Olympus PEN-D. It has an uncoupled meter and a smart way of setting aperture and shutter speed together. Works great and produces nice photos. Compared to the Canon Demi EE28 , it’s a bit bulkier, mostly due to the faster Zuiko 1.9 lens.
It features a Copal leaf shutter, fully mechanical, so no batteries are needed. Focusing is manual via a distance scale. Zone focusing works well once you get a feel for it.
