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 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 31/07/2026

Work on Pipi has reached a tipping point or system phase change as Pipi takes over tasks using autonomous automation. Pipi now has deadlines, not me. Soon it will set the deadlines. It's now a downhill run; daily posts from me resume tomorrow, and much more will come.

In hindsight. This whole project has been systematic trial and error, spending 10 years learning how to crack a hard problem.

Resources

References

  • Reference

Repository

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

Last Updated

31/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