Partial Sun Eclipse 2026

I didn’t know there was an eclipse. I found it by unusual crowds of people around me on the beach with tripods, filters, drones, a great deal of expensive glass pointed at the same place.

Because you cannot see it. Eighty-two percent of the Sun was gone and the light was an ordinary Baltic sunset. An eclipse doesn’t dim the Sun, it only makes it smaller.

So I did it properly wrong. An unfiltered iPhone, and ( luckily ) I took that day a Nikon EM with a Tair 11A and a sunglasses too that served as additional ‘hand mounted’ filter in front of the lens. Improvisation.

I think, however, those two frames are more honest than the ones showing eclipse in high resolution. On the digital photograph the Sun is a white blob with no eclipse in it at all and exactly this is how it looks like, the crescent is only at the bottom, as lens side defect, lying on the dark sand, in the lens flare.

The good photographs show you an eclipse. Mine show you the evening reality.

Analog photo:ISO 100 film, Tair 11A, f22 + sunglasses

iPhone photo, note the small eclipse flare.

AI reconstructed eclipse from the flare:

Data and analysis:

DateTimeOriginal2026-08-12 20:05:24.411, offset +02:00
GPS54°48′32.61″N, 17°49′21.23″E, altitude 14.48 m
GPSImgDirection291.25° true
CameraiPhone 14 Pro, 9 mm f/2.8 (the 3× tele), 1/657 s, ISO 32, spot metering
Image3024 × 4032
Sunaltitude 2.310°, azimuth 292.99°
Moonaltitude 2.229°, azimuth 292.96°
Angular radiiSun 15.784′, Moon 16.286′
Separation of centres5.250′
Eclipse magnitude0.8496
Obscured area81.7%
Local maximum20:03.2 CEST — the frame is 2.2 min after it
Crescent arc span172° (cusp half-angle 86.0°)
Crescent thickness4.749′ = 0.1504 of the solar diameter
Position angle of the Moon from the Sun202.92° from the zenith, clockwise

AI measured info:

MEASURED FROM PIXELSVALUES
Saturated solar core256 × 286 px, centroid (1325.7, 1067.6)
Sea horizonrow 1553
Horizon dip for 14.48 m eye height0.112°
Plate scale, from 2.310° + 0.112° over 485.4 px0.004989 °/px
True solar diameter at that scale105.5 px
Flare, fitted outer limbcentre (1530.7, 2879.4), R = 51.72 px
FLARE propertiespredicted ephemeridesmeasured
Flare diameter105.5 px (= the Sun’s true diameter, if magnification is 1)103.4 px → 0.981×
Crescent tilt in the flare22.92° from vertical15.3° (15.9° after horizon-tilt correction)
Crescent thickness15.9 px (0.150 of diameter)17.6 px FWHM (0.171)
Flare quadrantopposite the Sun through the frame centre(1531, 2879) vs (1698, 2964) predicted
Analog PHOTOVALUES
Crescent tilt measured on the Tair frame49° ± 5 (three estimators: 44°, 51°, 53°)
Predicted tilt at 20:09.3 / 20:11.044.4° / 51.3°
Implied time20:10 ± 1 min CEST

Mega katastr

Prázdninově laděný projekt / relax zone – 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.

https://ikatastr.cz/mega

AI Gambling Zones

A picture is worth thousands of tokens. A rough map of AI gambling zones in software development.

References:

Some thoughts on LLM coding

The Dark Addiction Patterns of Current AI Chatbot Interfaces

Artificial intelligence addiction: exploring the emerging phenomenon of addiction in the AI age

How AI assistance impacts the formation of coding skills

AI Safety Label: Original picture on the left is from random walk in Las Vegas, right AI modified.

AI Coding Agents and Team Knowledge Depreciation.

only reflection, no deep dive.

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.

Updated on 31.3. – less words. Also added AI usefulness map here : https://blog.sumbera.com/2026/03/28/ai-usefulness/

Saimon 1 BCD jako nástupce Logitronik 01

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.

IO-2 NAPÁJENÍ-+5V,
+5V-116,
117-62-63,
117-93,
92-0V,
64-95,
94-0V

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.


návody ke stavebnici Saimon

Simulace obvodu

Na strance https://falstad.com/circuit/circuitjs.html zadejte File/Import from text a můžete si obvod také nasimulovat :

vložte tento text:

$ 1 0.000005 10.20027730826997 54 1 50 5e-11
s 304 64 304 144 0 1 false
r 304 144 304 272 0 3300
w 176 272 304 272 0
v 176 176 176 144 0 0 40 6 0 0 0.5
w 176 64 176 144 3
w 176 272 176 176 0
w 176 64 304 64 0
w 304 144 384 144 0
r 384 144 384 208 0 330
d 384 208 384 272 2 default-led
w 384 272 304 272 0
153 384 144 560 144 0 1 5 5
r 560 144 560 208 0 330
d 560 208 560 272 2 default-led
w 560 272 384 272 0

Kotlin Bites Code

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.

AreaJavaKotlinTakeaway
Signature-polymorphic callsEmits correct signature for MethodHandle.invokeExactFalls back to (Object[])Object, causing mismatchesKeep these calls in Java
Default parametersNo defaults → use overloadsGenerates synthetic $default methods with bitmaskAvoid defaults in public APIs for Java clients
Companion objects / @JvmStaticTrue static methodsMethods live in $Companion unless annotatedUse @JvmStatic or plain Java for static APIs
Internal visibilityPackage-private supportedinternal compiles to public + metadataDon’t rely on internal for cross-language encapsulation
SAM interfacesAny functional interface = lambdaOnly fun interface supports SAM; lambdas may create synthetic classesDefine callbacks in Java for performance
NullabilityAll references nullableAnnotations encode nullability, JVM doesn’t enforceExplicit null checks needed in low-level code
Suspend functions / coroutinesN/ACompiles to (Arg, Continuation) → ObjectKeep coroutines in Kotlin wrappers, not core API

Other Kotlin Caveats for Low-Level Code

This wasn’t an isolated issue. Kotlin differs from Java in other ways that make it risky for core interop code:

AreaJavaKotlin limitation
JNI declarationsstatic native boolean render(int, int)Needs @JvmStatic in a companion object; generates synthetic names
JNI header generationjavac -h works directlyNo header generation for Kotlin sources
Checked exceptionsEnforced at compile-timeKotlin ignores them (all unchecked)
Raw typesAllowed (List)Always requires generics (List<*>)
Wildcards? super? extends supportedOnly in / out; cannot express everything
Default paramsNot supported (overloads instead)Compiles to synthetic $default methods
Static membersstatic keywordRequires @JvmStatic in object/companion
Suspend functionsN/ACompiled 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

BenefitWhy It Matters
One language to maintainSingle codebase, easier contributor onboarding, faster builds
Interop for everyoneJava APIs work in all JVM languages; Kotlin clients lose nothing; Java clients stay safe from Kotlin-only features
JNI friendlinessDirect mapping of Java types to JNI (int → jintboolean → jboolean); javac -h header generation works; avoids $Companion/$DefaultImpls surprises
Bytecode predictabilityNo 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 MethodHandleVarHandleUnsafe
    • 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

PointWhy
MethodHandle supportJava compiler emits exact signatures ((int,int)boolean), Kotlin falls back to (Object[])Object, causing runtime issues
Bytecode predictabilityJava produces direct, predictable bytecode; Kotlin adds synthetic constructs and indirections
JNI compatibilityJava maps directly to JNI types and header generation; Kotlin introduces complications
Best practiceKeep the core in Java for stability and performance; add Kotlin wrappers for ergonomics (DSLs, coroutines, null-safety)

interesting link: https://www.okoone.com/spark/technology-innovation/why-kotlin-swift-and-ruby-are-dropping-off-the-radar/

References

  1. Java SE Docs — MethodHandle and signature-polymorphic methods
    https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/MethodHandle.html
  2. OpenJDK Wiki — Deconstructing MethodHandles
    https://wiki.openjdk.org/display/HotSpot/Deconstructing%2BMethodHandles
  3. Kotlin Docs — Functions and default arguments
    https://kotlinlang.org/docs/functions.html
  4. Medium — Kotlin Function Parameters and Default Values: Behind the Scenes
    https://medium.com/@AlexanderObregon/kotlin-function-parameters-and-default-values-behind-the-scenes-6551fa515fa1
  5. Kotlin Forum — Kotlin bytecode on default parameters
    https://discuss.kotlinlang.org/t/kotlin-bytecode-on-default-parameters/6159
  6. Kotlin Docs — Visibility modifiers (internal, etc.)
    https://www.digitalocean.com/community/tutorials/kotlin-visibility-modifiers-public-protected-internal-private
  7. YouTrack — KT-14416: Support of @PolymorphicSignature in Kotlin compiler
    https://youtrack.jetbrains.com/issue/KT-14416
  8. Baeldung — The @JvmStatic Annotation in Kotlin
    https://www.baeldung.com/kotlin/jvmstatic-annotation
  9. StackOverflow — How to call a static JNI function from Kotlin?
    https://stackoverflow.com/questions/57117201/how-to-call-a-static-jni-function-from-kotlin
  10. The golden age of Kotlin and its uncertain future https://shiftmag.dev/kotlin-vs-java-2392/