Showing posts with label integration. Show all posts
Showing posts with label integration. Show all posts

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

  • The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
  • Future integration with cloud-based LLMs.
  • Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

  • Standards schema
  • Ontologies
  • Parameters
  • Laws of physics
  • HTML + CSS
  • Algorithms
  • Module DDD models
  • Workflow diagrams
  • Documentation
  • API schema
  • UI code
  • etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

  • camelCase: userProfilePicture
  • kebab-case: user-profile-picture
  • PascalCase: UserProfilePicture
  • snake_case: user_profile_picture
  • SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
  • Train-Case: User-Profile-Picture
  • flatcase: userprofilepicture
  • UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
  • Sentence case: User profile picture
  • Title Case: User Profile Picture
  • middot·case: user·profile·picture
  • dot.case: user.profile.picture
  • UPPER CASE: USER PROFILE PICTURE
  • lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the GΓΆdel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

  • I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
  • The website's .robot.txt file will then be unlocked to enable search engines.
  • The HTML will be updated to make it easier for AI to read.
  • This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
  • The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 23/07/2026

On the basis of open collaboration and credits for experimentation, I was going to offer Google exclusive use of Pipi for a period (as a thank you) before Pipi open-source is donated to the Cloud Native Computing Foundation for all to use.

Make money to provide a service.

I'm getting exasperated with XWF. They are the external sales contractors to Google, and since 2021, they regularly contact me.

  • Selling GCP products (No need; I'm already convinced).
  • Acting as gatekeepers to any contact with Google Engineers to discuss novel integration options, which is the actual issue. How to combine Gemini (an LLM) and Pipi (non-LLM) to make something much better.
  • They are all very nice, but a complete waste of my time. No more XWF meetings, folks.

So, I have decided to target integration with OpenRouter (and its alternatives) instead of Gemini and open up the Pipi developer platform (it is big and coming 😎) to enable developers from Alibaba, Alice AI, Anthropic, AWS, Azure, ByteDance, DeepSeek, Google, IBM, Meta, Mistral, Moonshot AI, Naver, OpenAI, Oracle, Palantir, Sarvam AI, xAI, etc, and anyone else, to enable integrations that are optimal, 100% secure and vetted, with everything publicly verifiable.

Pipi closed-core will never be for sale; this year it's getting a non-profit foundation behind it, a bit like Patagonia. I'm open to all genuine offers of assistance, collaboration and experimentation with no strings attached. Contact me.

Don't send sales engineers

Send a senior, highly experienced engineer/architect/chief scientist who loves a big fat problem and has time for an open chat without a pitch or an agenda, and just see where it goes.

If you want to meet in person, expect to work collaboratively at a whiteboard or blackboard like a real mathematician. Plus coffee, of course. 😎 To see how this works, watch the seminars at the London Institute of Mathematical Sciences, or the recorded physics seminars at Perimeter.

Pipi is rooted in biology and the laws of physics, so you need a very solid background in advanced sciences (microbiology, biochemistry, mathematics, philosophy, particle physics, thermodynamics, complex adaptive systems, etc).

Please, no venture capitalists or private equity. You're wasting your time. Go find something else to plunder. Pipi is a gift to humanity.


Being very high-functioning Asperger's (autism) with hyperphantasia, plus multiple synesthesias, I think visually at lightning speed and output solutions as fast as I can draw. I love solving very hard problems that matter. I can only write very slowly with the help of assistive technology, so I prefer video meetings with good spoken English, slides and time for trading quick engineering drawings.

Pipi is designed to run massive enterprise systems for socially useful critical infrastructure on every platform in many languages and writing systems.

The intention is to make life better for all of humanity by destroying waste, failure and crippling bureaucracy in;

  • Health systems (hospitals)
  • Transport systems (rail, road, air, shipping)
  • Sewerage
  • Drinking water
  • Land drainage
  • Nature conservation
  • Built infrastructure
  • Electricity networks
  • GLAM (galleries, libraries, archives, museums)
  • Farming (agriculture, forestry, aquaculture, horticulture
  • etc
Infant mortality rates will be the KPI

Pipi makes these systems self-assembling, self-managing, resilient and adaptive. I had to solve hundreds of very big, hard, complex problems in parallel to make this work. Some of them were abandoned research by others, who couldn't make them work, so I solved them. The answers were there, hidden in plain sight. Invisible due to a lack of imagination or courage.

Easy for me, because I can do it visually in my mind, run simulations of thousands of components while sleeping, including the testing, then wake up and just build; it always works 100% (been doing it for decades). That's why no one else has cracked this problem. I can remember everything I have designed this way since age 4 in great detail. Curiosity-driven learning turns everything I read that's interesting into a moving 4d model in my mind; there are tens of thousands of these shimmering mental models, and they self-assemble when I shut my eyes to solve a problem. Each model grows in detail and size as I learn more. I can fly through the models, exploring and touching them. Really cool.

Ahaa moments most days

Some days, I wake up, and the insights and designs pour out of my head like a firehose, and I can barely keep up even after outputting 20+ drawings on A4 paper in a day. Now, there are many thousands of colour-coded drawings in ring binders.

I turn the growing backlog of these designs into data models, code, and documentation with references by giving simple, direct instructions to Google Search AI Mode (Gemini), which teaches me new skills and gives me a response to edit, test, correct, and use. I'm going 100x faster, like a bat out of hell, the equivalent of a crack team of pre-AI developers. 😎 And I'm getting a lot faster.

I rely 100% on intuition when surfing a sea of 4D visual mental models. I really don't understand how the rest of you can only think in words, because I can't.

I have been very lucky

My grandmother Bessie showered me with attention and love, gave me endless things to pull apart to see how they worked, and took me to meet very clever people in a small-minded backwater town.

Family holidays in wild New Zealand, next to rivers, beaches, forests and mountains, which ignited a lifelong obsession with the patterns of nature, the why.

My best friend right through school; he was the brightest kid in NZ.

My high school science teacher, Alan Morgan, let me play in the chemistry lab, doing experiments after school unsupervised for several years, and taught me the scientific method on my very last day at school, the most important thing I learned in 12 wasted years.

The wise old tradesmen, who took a skinny kid from sweeping the floor to being able to make anything, by learning on the job, trying hard, and having my butt kicked.

Nelson Mandela taught me to have the courage of my convictions and never give up.

The sculptor Neil Dawson and the set designer Tony Geddes taught me how to work authentically.

My blind friend Grant, who cut down bushes with a chainsaw and made and gave away $60 M, teaching me quiet courage and human decency.

The magnificent 50,000 working people of South Christchurch, who trusted me to lead a volunteer residents army doing recovery for 3 years, after the Christchurch Earthquake, teaching me humility and valuable leadership skills gained by trial and error in the moment.

My beloved Tracy, the bravest woman I have ever met, the only paraplegic to do the Coast-to-Coast Iron Man, who married a lost autistic male and made me a much better man. Her unwavering devotion, encouragement and loyalty made all this possible.

They all shaped me; I can't thank them enough. May their memories be a blessing.

The future is open, at the edge of chaos

Update 28/07/2026

Most of the equipment has arrived, and the small data centre setup is coming together. More deliveries later this week. It's already running a lot better and is much more productive.

Update 30/07/2026

My creative problem-solving and build process is evolving, and the loop is getting faster. Works every time.

  • Understanding the problem starts with reading or talking with someone, watching a YouTube talk, or listening to the radio.
  • Do lots of research, mostly reading books (days to months).
  • Drink plunger coffee.
  • Print off a paper(s) or article(s) and file it in an A4 3-hole ring-binder.
  • Drink Chamomile tea.
  • Daydream (solutions come within hours or months later).
  • Drink plunger coffee.
  • Draw the solution as many colour-coded A4 architecture drawing(s).
  • Drink more coffee (Cappuccino).
  • File the drawing(s) with the printed paper.
  • Use the drawings to prompt Google Search AI Mode (free) with detailed instructions on what to build.
  • Output teaches me, describes data model, code, documentation.
  • Print off and file with the rest.
  • Walk a dog. Plant a tree. Watch the sun rise.
  • Read the printed AI output, colour-code, add doodles, correct, test, edit names, build, use in Pipi, while listening to music. (I don't copy-paste. I manually type to copy, because it helps me learn and understand.)
  • Throw away all the paper except for the original research, which is moved from DevOps to the research library.
  • Pipi then generates self-documentation, including mermaid drawings.
  • Repeat.

Each loop cycle takes weeks to years. There are hundreds running in parallel at any one time. It's a pull system. I work on Pipi when something needs to be solved, and look up my library of solutions. Totally intuitive, just like an artist, not an engineer, and always fun like a kid playing.

These changes are made possible because of the detailed work done over the last few months removing barriers, including modifications to Pipi, reorganising space, equipment, and routines.

I think I have now solved all major problems to get Pipi 9 Core (Loki) running 24x7x52. Anything else that pops up can be solved along the way as part of maintenance.

Now to execute very fast.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

30/07/2026

No posts for a wee while

By: Mike Peters
On a Sandy Beach: 15/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

  • New posts "On a Sandy Beach
  • All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
  • The fortnightly online Open R&D meeting.

Rapid refocus

  • A new developer area with five coding screens, designed to be more productive for hypervisual learners.
  • A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
  • The server rack has been moved to a better location.
  • The light levels have been adjusted.
  • A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
  • A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

  • 20 engines enable Pipi 9 Core in a simple, deterministic structure.
  • 40 engines enable a workspace with a UI for administering Pipi Core.
  • 60 engines enable self-generation of user documentation.
  • 80 engines enable REPL and IAC (infrastructure-as-code).
  • 100 engines enable Workspaces for different user accounts.
  • Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
  • And so on until...
  • 200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
  • 200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.

Creating an environment for plug-ins

Mike's Notes

Here are my rough ideas about how to create an environment in Pipi 9 for plug-ins.

I want to reduce Pipi to its essential and closed core, and the remainder will be turned into open-source plug-ins available on GitHub. The community could then create other plug-ins and modules to extend the platform.

I would like to talk with people who have done something similar.

Resources

References


Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

11/05/2025

Creating an environment for plug-ins

By: Mike Peters
On a Sandy Beach: 04/03/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

From Wikipedia - "In computing, a plug-in (or plugin, add-in, addin, add-on, or addon) is a software component that extends the functionality of an existing software system without requiring the system to be re-built. A plug-in feature is one way that a system can be customizable.

Applications support plug-ins for a variety of reasons including:

  • Enable third-party developers to extend an application
  • Support easily adding new features
  • Reduce the size of an application by not loading unused features
  • Separate source code from an application because of incompatible software licenses
..."

I have been putting off creating a plug-in environment for Pipi 9 because it wasn't an urgent task.

However, recently, a representative of a large software company contacted Ajabbi about embedding their product on ajabbi.com web pages, which raised the issue of plug-ins. We talked, and now they are considering it.

I might have a first plugin to build, so I better figure out how to do this. :)

I am now working this out by the seat of my pants, and things will no doubt change a lot.

I did a lot of investigating when working on Pipi 6 (2017-2019), and I liked how OpenERP (Now Odoo) enabled community-sourced extensions (they call them addons) to its open SaaS product.

The Odoo addons are packaged using a sensible standard format.

  • manifest_py
  • readme
  • controllers/
  • data/
  • demo/
  • doc/
  • i18n/
  • models/
  • report/
  • security/
  • static/
  • tests/
  • tools/
  • views/
  • wizard/

Plug-in package

A package structure similar to Odoo and simple industry standard file formats would work, packaged in a zip file and including the following.

  • Name
  • Description
  • Author/developer
  • Icon
  • Manifest file (XML)
  • Sample data (SQL)
  • Language strings of any other language mapping to the base English string (CSV)
  • etc

Plug-ins and modules are quite different.

SaaS Module

  • SaaS applications are built out of reusable modules.
  • The admin web UI should be the only thing required to add or remove modules (tick boxes).
  • Modules follow domain-driven-design (DDD) principles.
  • Have an MCV architecture.
  • Examples:
    • Assets
    • Invoices

SaaS Simple Plug-in

  • Simple Plug-ins add simple UI functionality to a SaaS application and usually involve HTML.
  • Simple forms are used to add plug-ins.
  • CMS Examples:
    • Embed Google Map
    • Embed ESRI Map
    • Embed Mathematica Notebook
    • Embed Jupyter Notebook
    • Embed complex Java object

SaaS Complex Plug-in

  • Complex Plug-ins can work with third-party applications using methods such as databases, APIs, scripting, XML, and JSON.
  • The DevOps Engine (dvp) is required to configure integration.
  • Examples:
    • Office 365
    • Google Workplace
    • Zoho
    • Odoo

Pipi Plug-in

  • Pipi Plug-ins extend Pipi by adding 3rd-party software using wrapper and configuration settings.
  • The DevOps Engine (dvp)  is required to configure integration.
  • The plug-ins can interact fully with the engines and other Pipi objects.
  • Examples:
    • Docker
    • Database, e.g. semantic, graph, document
    • Another computer language, e.g. Prolog
    • Another API type, e.g. SOAP
    • Azure platform config
    • AWS platform config
    • GCP platform config
    • WolframAlpha
    • ESRI ArcGIS

Engines

  • The Plug-in Engine (plu) to register plug-ins is now being built.
  • The Module Engine (mdl) registers all modules.

Health systems in New Zealand

Mike's Notes

One of the reasons for creating Pipi is to provide support for health systems.

I have followed SNOMED for several years and participated in an OMG health workflow effort during the COVID lockdown. I did not contribute much, but I learned by watching how a standard's body functions with people working remotely. Ken Rubin skillfully led the effort.

Locally, there is Health Information NZ (HINZ). This is the primary organisation involved in standards and interoperability. The NZ public health system has 3,000 applications that don't integrate and must be fixed. I recently signed up to use SNOMED.

My account at SNOMED CT has been approved.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/5/2025

Health systems in New Zealand

By: Mike Peters
On a Sandy Beach: 17/08/2024

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

SNOMED

"SNOMED CT or SNOMED Clinical Terms is a systematically organized computer-processable collection of medical terms providing codes, terms, synonyms and definitions used in clinical documentation and reporting. SNOMED CT is considered to be the most comprehensive, multilingual clinical healthcare terminology in the world.[1][2] The primary purpose of SNOMED CT is to encode the meanings that are used in health information and to support the effective clinical recording of data with the aim of improving patient care. SNOMED CT provides the core general terminology for electronic health records. SNOMED CT comprehensive coverage includes: clinical findings, symptoms, diagnoses, procedures, body structures, organisms and other etiologies, substances, pharmaceuticals, devices and specimens.

SNOMED CT is maintained and distributed by SNOMED International, an international non-profit standards development organization, located in London, UK. SNOMED International is the trading name of the International Health Terminology Standards Development Organisation (IHTSDO), established in 2007" - Wikipedia

Webinar

Topic: Transforming healthcare interoperability with FHIR

12:30pm to 1:30pm, Wednesday 28 August 2024

Watch live or on demand

"FHIR has become a household name as the standard that has moved health data exchange into the modern era.

Experts from both sides of the Tasman will discuss the latest developments using FHIR for joined-up care and better user experience.

This will include an update on the HISO interoperability standards and supporting tools that are Health NZ's delivery priorities in 2024, including the NZ Health Terminology Service (NZHTS), SNOMED CT NZ Edition, and NZ Core Data for Interoperability (NZCDI).

Also hear about developments from the first FHIR Accelerator in Australia, as well as implementation of the New Zealand Patient Summary." - HiNZ

Enterprise Integration Patterns from Gregor Hohpe

Mike's Notes

Resources

References

  • Enterprise Integration Patterns

Repository

  • Home > Ajabbi Research > Library > Authors > Gregor Hohpe
  • Home > Handbook > 

Last Updated

11/05/2025

Enterprise Integration Patterns from Gregor Hohpe

By: Mike Peters
On a Sandy Beach: 03/05/2019

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Enterprise Integration Patterns is an excellent book by Gregor Hohpe and Bobby Woolf, and describes 65 patterns for the use of enterprise application integration and message-oriented middleware in the form of a pattern language.

Published by Addison-Wesley, 2004.

Gregor Hohpe is currently a technical director in Google Cloud's Office of the CTO.

There is an excellent website for the book.

A 2016 interview with the authors on IEEE Software. A Decade of Enterprise Integration Patterns: A Conversation with the Authors. PDF is available.

A presentation by Gregor at YOW Singapore Conference 2017



Integration styles and types

The book distinguishes four top-level alternatives for integration:

  • File Transfer
  • Shared Database
  • Remote Procedure Invocation
  • Messaging

The following integration types are introduced:

  • Information Portal
  • Data Replication
  • Shared Business Function
  • Service Oriented Architecture
  • Distributed Business Process
  • Business-to-Business Integration
  • Tightly Coupled Interaction vs. Loosely Coupled Interaction

The graphic icons used in the patterns are also freely available from different sources.

  • Visio Stencils
Some additional graphics notes here.

Blogs

Software

Enterprise Integration Patterns are implemented in many open-source integration solutions.

Commercial MOM Message Queuing Services in the cloud include