| Website | https://rock-the-prototype.com |
| YouTube | https://youtube.com/@Rock-the-Prototype |
| Spotify 🇩🇪 | spoti.fi/3NJwdLJ |
| Apple Podcast 🇩🇪 | apple.co/3CpdfTs |
Vertrauen sollte immer in beiden Richtungen bestehen. Und will gepflegt sein…
Wenn ich frage, wem ich auf meinem Server ein Konto anvertrauen kann, ist genauso die Gegenfrage genauso berechtigt.
Was prĂĽft ihr, bevor ihr euch fĂĽr einen Server entscheidet?
Regeln und Moderation? Das Team oder die Person dahinter? Backups? Datenschutz? Die Möglichkeit, das eigene Konto später umzuziehen?
Oder vor allem das GefĂĽhl, willkommen zu sein?
This quote has been circulating recently, from a 1985 paper that was part of a conversation at the time about what a computer program *is*. Is it the source code? Or the final executable binary? Or the sum of its versions? Or the people who wrote it?
I've been programming for over 40 years, and I can tell you with great confidence that Naur was right. When I'm building software, first and foremost what I'm building is me.
Das #Fediverse ist bunt. 🤗 Seit Januar betreibe ich einen kleinen Mastodon-Server, um das Fediverse besser zu verstehen.
Inzwischen erreichen mich regelmäßig Registrierungsanfragen. Damit stellt sich für mich eine grundlegende Frage:
Wie entscheidet ihr als Betreiber:innen, wem ihr ein Konto anvertraut – ohne aus einer offenen Community ein KYC-Verfahren zu machen?
Welche Kriterien, Vertrauenssignale oder Erfahrungen helfen euch dabei?
Kurz nach 7 Uhr war heute die beste Zeit für mich zum Löten. Gleich nachdem ich um 6.30 Uhr den Topf Nudeln gekocht habe.
Jetzt ist 8 Uhr, die Sonne knallt schon auf die Dachwohnung und der Verschlusszustand wird hergestellt - und ich vermeide für den Rest des Tages irgendetwas einzuschalten, was größer Wärme erzeugt.
Spitzenwert an Raumtemperatur gestern: 32,9 C. Und ich vermute, das wird heute noch mehr.
#Hitze #Dachwohnung
Digital identity folks on Mastodon: do you listen to English #podcasts? đź‘‹
I just published an RTP (EN) episode on #digitalIdentities + #IAM — #ITsecurity & #trust at the core.
Reply with: Apple / Spotify / YouTube / you preferred delivery / (or “no podcasts”) ✅
🍎 Enjoy on Apple Podcasts: 👉 https://qrco.de/bgXoxH 
🎧 Listen on Spotify: 👉 https://qrco.de/bgXouD
Podcast on YouTube: 👉 qrco.de/bgXour
I’m looking for 2 people to sanity-check the approach (10 minutes).
If you work with #requirements, #compliance, or #audits: what would you need to try this on a real spec?
Boost welcome 🤗
#DSL #opensource #itsecurity #requirementsengineering #infosec
Fediverse check: who can actually see this? đź‘‹
I’m building dsl-core: an open-source #DSL that makes requirements machine-readable and verifiable (ambiguity / atomicity / consistency).
âť“ What would be the first meaningful use case for you?
Repo: https://github.com/rock-the-prototype/dsl-core
(Boost welcome 🙏)
Core Specification for the Audit-by-Design DSL - Human- and machine-readable domain-specific language (DSL) for defining, validating, and auditing atomic requirements (AFOs) in regulated software e...
From #Stargate to Europe: Why innovation has no future without values - “Europe is not held together by power, but by the common pursuit of justice and progress.” – Jean Monnet We in #Europe stand for #freedom, #democracy and #progress.
https://rock-the-prototype.com/en/artificial-intelligence-ai/from-stargate-to-europe-why-innovation-has-no-future-without-values/ #ElonMusk #Musk #Europa
From STARGATE to Europe - We in Europe stand for freedom, democracy and progress! Our responsibility for ethical innovation
Dreaming again about software as a graph. Instead of using the semantic units of programming languages, our entire dev infra rests on hierarchies which should have zero relation with the internal structures/architectures of our code and, like so much else, are the byproduct of older legacy decisions. Despite this, 99% of modern PLs are still designed around these seemingly permanent legacy structures.
Early “web search” indices before Google (i.e. Altavista, DMOZ, Yahoo) were all about putting links into hierarchies. Our entire modern software development architecture is (still) using the same model: From hierarchical file systems, languages using files as basic organizational unit (vs functions/classes/types), name spaces, packages (aka virtualized folders) as containers, both to group functionality and to distribute it. Git repos are yet another level of hierarchy on top (although excluding monorepos, they’re usually the same level as packages). It’s folders, not turtles, all the way down (and up)!
Caring about usability & maintenance, for years I’ve been struggling with this overall setup and having an increasingly hard time (and spending too much of it) to figure out _where_ to put (new & old) functionality: Should it be combined with or become part of existing packages, go in a new file/package, should it be (always) internal or public, should it exist at all (as standalone unit)... This struggle, first stemming from 15 years of Java coding, largely motivated my adoption of Literate Programming (LP) during most of the 2010s (via #Clojure & #OrgMode), though it only partially helped with some aspects, and other people around me discouraged it...
Hierarchies lead to hard-to-undo systemic calcification of structures. Structures/institutions which only make/made sense for a time, maybe were a good pragmatic/useful solution at the time, but then should be allowed to cease to exist, or the very least should be more soft and open for change. To me software is NOT about upholding hierarchies, but about malleability, above all other concerns like reliability, reproducibility, security, etc. There’re hundreds of existing things I’d like to migrate/re-organize, but I can’t because it’d break hundreds of downstream projects — and I do care about others who’re using these libraries! For context, being the by far largest thi.ng meta-project, the https://thi.ng/umbrella monorepo contains 200 packages/libraries with a total of 4100+ standalone functions and ~2200 types/interfaces/classes. It’s getting ever harder to fight the existing hierarchies and I know I could drastically reduce these numbers if it wasn’t for these enforced structures.
Apart from calcification, hierarchies also lead to other issues like duplication, (lack of) discoverability, competition (of responsibilities), paradox of choice, and increased maintenance efforts... All things I’d like to avoid in my work!
What I want instead (and have already started prototyping several times) is a distributed graph based version of:
- Content addressable standalone semantic units of code (language agnostic). Any change immediately leads to new version. Requires an alias system to make references & versions human readable.
- RDF-style graph database of all code. Each node has typed links to dependencies (e.g. other functions), documentation (incl. example usage, references, research papers), bidirectional links to previous and next versions, other metadata (author, license etc.)
- No files, no packages, only tags (for discovery)
As an interim adaptation step to keep on using existing languages/infra, a form of LP style “tangle” tool is required. This tool would linearize/dedupe the referenced subgraph(s) into traditional source files as a pre-build step and implicitly perform dead code elimination, which should also lead to much lower compile efforts/times...
Using a graph approach, we can have much more advanced & useful dev tools, more easily produce visualizations to aid codebase & dependency analysis/maintenance, refactoring, etc.
Dreaming again about software as a graph. Instead of using the semantic units of programming languages, our entire dev infra rests on hierarchies which should have zero relation with the internal structures/architectures of our code and, like so much else, are the byproduct of older legacy decisions. Despite this, 99% of modern PLs are still designed around these seemingly permanent legacy structures. Early “web search” indices before Google (i.e. Altavista, DMOZ, Yahoo) were all about putting links into hierarchies. Our entire modern software development architecture is (still) using the same model: From hierarchical file systems, languages using files as basic organizational unit (vs functions/classes/types), name spaces, packages (aka virtualized folders) as containers, both to group functionality and to distribute it. Git repos are yet another level of hierarchy on top (although excluding monorepos, they’re usually the same level as packages). It’s folders, not turtles, all the way down (and up)! Caring about usability & maintenance, for years I’ve been struggling with this overall setup and having an increasingly hard time (and spending too much of it) to figure out _where_ to put (new & old) functionality: Should it be combined with or become part of existing packages, go in a new file/package, should it be (always) internal or public, should it exist at all (as standalone unit)... This struggle, first stemming from 15 years of Java coding, largely motivated my adoption of Literate Programming (LP) during most of the 2010s (via #Clojure & #OrgMode), though it only partially helped with some aspects, and other people around me discouraged it... Hierarchies lead to hard-to-undo systemic calcification of structures. Structures/institutions which only make/made sense for a time, maybe were a good pragmatic/useful solution at the time, but then should be allowed to cease to exist, or the very least should be more soft and open for change. To me software is NOT about upholding hierarchies, but about malleability, above all other concerns like reliability, reproducibility, security, etc. There’re hundreds of existing things I’d like to migrate/re-organize, but I can’t because it’d break hundreds of downstream projects — and I do care about others who’re using these libraries! For context, being the by far largest thi.ng meta-project, the https://thi.ng/umbrella monorepo contains 200 packages/libraries with a total of 4100+ standalone functions and ~2200 types/interfaces/classes. It’s getting ever harder to fight the existing hierarchies and I know I could drastically reduce these numbers if it wasn’t for these enforced structures. Apart from calcification, hierarchies also lead to other issues like duplication, (lack of) discoverability, competition (of responsibilities), paradox of choice, and increased maintenance efforts... All things I’d like to avoid in my work! What I want instead (and have already started prototyping several times) is a distributed graph based version of: - Content addressable standalone semantic units of code (language agnostic). Any change immediately leads to new version. Requires an alias system to make references & versions human readable. - RDF-style graph database of all code. Each node has typed links to dependencies (e.g. other functions), documentation (incl. example usage, references, research papers), bidirectional links to previous and next versions, other metadata (author, license etc.) - No files, no packages, only tags (for discovery) As an interim adaptation step to keep on using existing languages/infra, a form of LP style “tangle” tool is required. This tool would linearize/dedupe the referenced subgraph(s) into traditional source files as a pre-build step and implicitly perform dead code elimination, which should also lead to much lower compile efforts/times... Using a graph approach, we can have much more advanced & useful dev tools, more easily produce visualizations to aid codebase & dependency analysis/maintenance, refactoring, etc. #Software #Graph #OpenSource
4am ❧
HerrThees
Karsten Schmidt