AWS and Google Cloud Preview Secure Multicloud Networking

Mike's Notes

The Connection Coordinator API Specification may be essential to use if it becomes widely adopted. It depends a bit on the pricing model.

Resources

References

  • Connection Coordinator API Specification

Repository

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

Last Updated

13/03/2026

AWS and Google Cloud Preview Secure Multicloud Networking

By: Renato Losio
InfoQ: 25/12/2025

Renato has extensive experience as a cloud architect, tech lead, and cloud services specialist. Currently, he lives in Berlin and works remotely as a principal cloud architect. His primary areas of interest include cloud services and relational databases. He is an editor at InfoQ and a recognized AWS Data Hero. You can connect with him on LinkedIn.

In a surprising move, AWS and Google Cloud have recently partnered to simplify multicloud networking, introducing a common standard and leveraging "AWS Interconnect - Multicloud" and "Google Cloud's Cross-Cloud Interconnect". The new option makes it easier for organizations to manage and secure workloads across both clouds, with Azure expected to join in 2026.

Currently in preview, the solution combines AWS Interconnect – Multicloud with Google Cloud’s Cross-Cloud Interconnect and defines an open interoperability specification that other cloud providers can also adopt. Designed to avoid managing circuits, routers, and routing configurations, the new option is intended to simplify the deployment of secure multicloud workloads, enabling customers to establish private, high-speed connectivity between Google Cloud and AWS.

Available on GitHub, the Connection Coordinator API Specification describes the OpenAPI 3.0 specification for the symmetric API used to coordinate managed L3 connectivity. Rob Enns, VP of cloud networking at Google Cloud, and Robert Kennedy, VP of network services at AWS, write:

"Previously, to connect cloud service providers, customers had to manually set up complex networking components including physical connections and equipment (...) This could take weeks or even months. AWS had a vision for developing this capability as a unified specification that could be adopted by any cloud service provider, and collaborated with Google Cloud to bring it to market."

The new solution targets customers who want to run workloads across distributed regions, have low-bandwidth needs, and want cross-cloud connectivity without managing physical infrastructure. One of the common concerns among practitioners is the pricing of the solution, which has not been disclosed yet, with Corey Quinn, chief cloud economist at The Duckbill Group, writing:

"This is either transformative or a waste of everyone's time, and it's impossible to tell which because the one thing that matters most to settling that question is "what's the price." They aren't disclosing it yet, so at the moment it occupies a superposition of "excellent/crap." Please collapse the waveform so we know which one it is."

According to AWS documentation, the managed private connectivity service enables customers to define direct 1 Gbps connections between AWS VPCs and Google Cloud VPCs at no cost during the preview. Tyler Batts, senior customer ops engineer at Second Front, comments:

"It’s not in GovCloud yet, but the direction is obvious: AWS is baking multicloud into the platform instead of leaving teams to piece it together themselves (...) If you run serious workloads in the cloud, this is one of those updates worth paying attention to!"

All connections between the AWS and Google Cloud network devices are encrypted by default, and hardware is configured to transmit customer traffic only when the encryption session is active. Enns and Kennedy add:

Both providers engage in continuous monitoring to proactively detect and resolve issues. And this solution is built on a foundation of trust, utilizing MACsec encryption between the Google Cloud and AWS edge routers.

The preview is currently free and supports five AWS and Google Cloud regions in the US and Europe, including Northern Virginia, Oregon, and Frankfurt.

Design in code, get praise

Mike's Notes

Using this method for the upcoming workspace testing. Design is done in Pipi, not Figma. IMO, Figma is over-hyped.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Adam Silver
  • Home > Handbook > 

Last Updated

12/03/2026

Design in code, get praise

By: Adam Silver
Adam Silver: 19/01/2026

Adam Silver is an interaction designer with over 15 years experience working on the web for a range of companies including Tesco, BBC, Just Eat, Financial Times, the Department for Work and Pensions and others.

He’s particularly interested in inclusive design and design systems and writes about this on his blog and popular design publications such as A List Apart. This isn’t his first book either: he previously wrote Maintainable CSS, a book about crafting maintainable UIs with CSS.

This week I demoed some flows I’d been redesigning to a room full of product managers and stakeholders.

The programme I’m on is huge. We’re redesigning a highly complex, enterprise-grade, case-working system.

There are many feature teams, each with their own product manager. I’ve been on the programme for 6 months now but it’s so big I’ve not met many of them.

The meeting was meant to present the before/after of the redesigns to show what it looks like to just use the simple and accessible patterns from the GOV.UK Design System and a few of my own, encouraging other feature teams to reuse them.

It did that.

But it also did something else, something I didn’t really expect:

Toward the end of the meeting, the conversation veered off.

There were comments and questions about the tool I'd used to create and demo the designs:

“I love the way this demos new concepts.”

“The prototype really helps you to understand the user journey”

“It’s been so helpful for our developers to show them how something actually works”

Most designers use Figma, but I had created an HTML prototype using the GOV.UK Prototype Kit.

Don’t get me wrong, Figma has its place but at the end of the day:

Figma can only produce pictures of software.

Not actual software.

Actual software is alive.

  • It moves
  • It adapts
  • It errors
  • It loads
  • It responds

Figma might be useful to design in.

But it’s not good to design “out”.

By that I mean:

When you present your designs with Figma, you’re not interacting with the product you’re designing.

You’re interacting with the software you used to design.

As a result:

  1. It’s slow and jarring. Your audience has to watch you stop, scroll, pan and zoom around Figma between each step.
  2. It may not do your design justice. Your audience is focused on you navigating Figma rather than experiencing your design.
  3. It may hide problems. You’ll probably jump between screens and miss important details - realistic data, micro interactions, transitions, loading states, error states and edge cases.

Designing in code and demoing in the browser forces you - or at least encourages you - to confront these things.

For my demo, instead of just sharing screens:

  1. I opened the browser and typed in the URL
  2. I signed into the case-working system
  3. I landed on the overview page which showed me my priority tasks
  4. I made the screen smaller to show two instances of the app side by side
  5. I clicked “Cases” in the primary menu to go to the case list
  6. I searched, filtered and sorted the list to find a particular case
  7. I filled out a complex multi-step form flow with conditional logic

In other words, I went through the entire end-to-end journey and interacted with the prototype just like real users would.

This allowed my audience of product managers to free up their mental energy and instead focus on understanding the design intention and potential gaps.

That’s 100x harder to do with Figma.

After the meeting, I received a lot of positive feedback which is great because I love praise.

One product manager actually suggested I help train some of the other designers on the programme who are less familiar with the Prototype Kit.

But she also pointed out that it would probably take up too much of my time.

Luckily, I’ve been preparing for this moment for 2 years. I told her:

I have a course that teaches designers how to use the GOV.UK Prototype Kit to unlock the many benefits of prototyping in code.

If you’d like to learn how to use the Prototype Kit and unlock those benefits — including a little unexpected praise when you present at your next show and tell:

​https://prototypekitcourse.com​

Cheers,

Adam

10 Must-read books and surveys about AI and Machine Learning

Mike's Notes

Alyona Vert from Turing Post compiled this fantastic list of free resources on AI and Machine Learning. Turing Post is excellent and worth subscribing to.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Turing Post
  • Home > Handbook > 

Last Updated

11/03/2026

10 Must-read books and surveys about AI and Machine Learning

By: Alyona Vert
Turing Post: 16/02/2026

Joined Turing Post in April 2024. Studied control systems of aircrafts at BMSTU (Moscow, Russia), where conducted several researchers on helicopter models. Now is more into AI and writing.

Deep Learning, context engineering, LLMs, multimodal models and agents – all the basics together for your convenience

Sharing some free, useful resources for you. In this collection, we’ve gathered books and surveys that can be your perfect guides to the major fields and techniques. Hope this really helps you master AI and machine learning and fill in any gaps in your knowledge!

  1. Machine Learning Systems by Vijay Janapa Reddi
  2. Understanding Deep Learning by Simon J.D. Prince
  3. Interpretable Machine Learning by Christoph Molnar
  4. Foundations of Large Language Models by Tong Xiao and Jingbo Zhu
  5. A Survey on Post-training of Large Language Models
  6. A Survey of Generative Categories and Techniques in Multimodal Generative Models
  7. Context Engineering 2.0: The Context of Context Engineering
  8. Agentic Large Language Models, a survey
  9. Geometric Deep Learning: Grids, Groups, Graphs, Geodesics, and Gauges
  10. Mathematical Foundations of Geometric Deep Learning by Haitz Saez de Ocariz Borde and Michael Bronstein

jQuery Releases v4: First Major Version in Almost 10 Years

Mike's Notes

JQuery is a popular JavaScript library in use today.

***

jQuery is a JavaScript library designed to simplify HTML DOM tree traversal and manipulation, as well as event handling, CSS animations, and Ajax. It is free, open-source software using the permissive MIT License. As of August 2022, jQuery is used by 77% of the 10 million most popular websites. Web analysis indicates that it is the most widely deployed JavaScript library by a large margin, having at least three to four times more usage than any other JavaScript library. - Wikipedia

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > InfoQ Weekly Digest
  • Home > Handbook > 

Last Updated

10/03/2026

jQuery Releases v4: First Major Version in Almost 10 Years

By: Daniel Curtis
infoQ: 20/02/2026

Daniel Curtis is a UI Development Manager at Griffiths Waite, a software consultancy based in Birmingham, UK. He leads front-end engineering efforts with a strong focus on delivering innovative enterprise solutions using TypeScript across the stack. Daniel is passionate about modern web architecture, developer experience, and the use of AI to both support software delivery and solve real customer problems within products.

jQuery, the pioneering JavaScript library that revolutionized web development, has released jQuery 4, marking its first major version in almost 10 years. The release coincides with the library's 20th anniversary, having first been introduced on January 14, 2006.

jQuery 4 brings extensive modernizations while maintaining the simplicity and developer experience. The team has focused on trimming legacy code, removing deprecated APIs, and dropping support for outdated browsers, resulting in a leaner and more performant library. The jQuery team expects most users will be able to upgrade with minimal changes to their code, supported by a comprehensive upgrade guide and jQuery Migrate plugin.

A key support change in jQuery 4 is the removal of support for Internet Explorer 10 and older browsers, including Edge Legacy, iOS versions earlier than the last 3, and Android Browser. Internet Explorer 11 remains supported in this release, though the team has indicated that support will be removed in jQuery 5.0.

The library source code has been migrated from AMD to ES modules, making jQuery compatible with modern build tools and development workflows. Developers can now import jQuery directly as ES modules through the use of script type equals module tags, and the project has switched from RequireJS to Rollup for packaging.

The modernizations have been well received by the community, with users on Reddit noting how far vanilla JavaScript has become:

I think it's a sign of how good vanilla browser JS is when half of the changelog is stuff getting removed.

jQuery 4.0 adds support for Trusted Types, ensuring that HTML wrapped in TrustedHTML can be used as input to jQuery manipulation methods without violating Content Security Policy directives. The library has also switched most asynchronous script requests to use script tags rather than inline scripts to avoid CSP errors.

Several deprecated functions have been removed, including jQuery.isArray, jQuery.parseJSON, jQuery.trim, and jQuery.now, as modern browsers now provide native equivalents like Array.isArray(), JSON.parse(), String.prototype.trim(), and Date.now(). Removing deprecated APIs has saved over 3,000 bytes of gzipped code.

The slim build has been further reduced to around 19.5k bytes gzipped by removing Deferreds and Callbacks, as native Promises are now available across all supported browsers except IE11.

Community reaction has been positive, with HackerNews users highlighting that jQuery's code remains "shorter, cleaner, and more intuitive than the vanilla modern JS" alternatives.

On a reddit thread for the release, which attracted over 130 replies, one person asked:

Real question: why use this on any greenfield app?

With one replier suggesting:

I'm guessing probably habit and convention more than anything. It's still bundled with Wordpress and all the tutorials use it.

Another commenter said the following, which emphasises the library's stability and predictability in an ecosystem of rapidly changing frameworks:

Most people don’t use it on a greenfield app, but why does that matter?

It’s still downloaded by millions everyday so I suspect there are some good reasons why people still use it today.

    • Maintaining or extending a large existing codebase that uses Jquery,
    • Extremely fast DOM work with minimal mental overhead
    • Cross browser normalization still has value
    • Small interactive behavior without a framework
    • Massive plugin ecosystem that still works
    • Excellent readability for non specialists
    • Progressive enhancement and server rendered sites
    • Performance is no longer the liability it once was
    • Reduced dependency surface
    • It is boring and boring can be good

Compared to modern alternatives like vanilla JavaScript DOM APIs or frameworks such as React and Vue, jQuery continues to excel in scenarios involving progressive enhancement, server rendered sites, and small interactive behaviors without the overhead of a full framework. The library remains a practical choice for maintaining existing codebases and projects where simplicity and cross browser normalization are priorities.

jQuery is available on the jQuery CDN and via npm with npm install jquery@4.0.0. The release represents not just a technical milestone but a celebration of 20 years of making web development more accessible and enjoyable for millions of developers worldwide.

Ajabbi slide talks

Mike's Notes

I will have to give many presentations (talks and demos) in the future, so here is a rough plan that builds on an earlier note from a month ago. Feedback on it is welcome.

Resources

References

  • Reference

Repository

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

Last Updated

12/03/2026

Ajabbi slide talks

By: Mike Peters
On a Sandy Beach: 09/03/2026

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

Background

I previously gave hundreds of slide talks to conferences, workshops, and public meetings in NZ. I enjoyed explaining complex things so that anyone could understand. Everything from 30 seconds to 2+1/2 hours. But that was years ago.

As Pipi continues to develop and international interest grows, I will have to give many talks to different audiences in the future. 

The need is now becoming urgent, with requests and opportunities arriving.

What works

I'm also highly visual and prefer to talk about something I can see, like a map, chart, video, gadget, or drawing, rather than read a speech.

What is needed

Audiences

  • Software developers
  • Scientists
  • Pitching to a panel
  • Training users
  • Radio or TV interviews
  • Contractors
  • Volunteers and staff
  • Open office hours
  • etc
Format
  • In-person
  • Remote
  • Hybrid

Delivery

  • Live
  • Pre-recorded

Modular

  • Short & consice
  • Combined for longer talks.

What will happen

This is what I thought might work.

  • Design a structured outline of topics to cover.
  • Design a simple uniform slide format.
  • Apart from the title, utility, and end slides, use one slide per minute, following the 5:5:5 rule.
  • Practice delivering some to the fortnightly research group I attend online, as well as to other groups I am a member of.
  • Start rapidly manufacturing slide talks based on the priority of need.
  • Reuse the notes and images from the 650 posts on this blog.
  • Create simple 1-page A4 summary notes for print, hand out, event notices and email invitations.
  • Record the talks with slides in advance and upload them to YouTube as a library.
  • Pre-record short videos of live demos of using Pipi and upload them to YouTube as a library.
  • Save and share the slides using links as PowerPoint, Google Slides, or Adobe PDF. On Slideshare.
  • Automate by using the Pipi CMS Engine (cms) to store, reuse, update, render, and manage metadata, put in the right place, etc

Work Log

09/03/2026

  • Wrote this post
  • Made A4 paper card mockups of typical slides, looking at layout, fonts, and colours

10/03/2026

  • Created a topic outline (Google Sheet)
  • Watched how TED recommend how to give talks
  • Built a temporary Access Database to organise content. To be imported into the Pipi Learning Object Engine (lob) and use those tools to further configure.
    • ID
    • Code No, e.g., "103-10045-100001-eng-US", "103-10045-100001-fra"
    • Footer, e.g., "Ajabbi Learn"
    • Collection, e.g., "Signing Up"
    • Title (5 word max), e.g., "Creating your profile"
    • Subtitle (5 word max)
    • Slide Talk Flag Y/N
    • Video Demo Flag Y/N
    • PDF Summary Flag Y/N
    • Note
  • Imported the Google Sheet topic outline into the database
  • Discovered Free/open-source screen capture software to pre-record live demos for YouTube.
    • "ShareX (Windows): Open-source, lightweight, and excellent for both screen recording (including GIFs) and screenshots, featuring powerful, automatic sharing options."
    • "OBS Studio (Windows/Mac/Linux): The premier choice for high-quality, unlimited, and feature-rich recording. It is ideal for streaming and complex recordings but has a steeper learning curve."

11/03/2026

  • Added list of slide footers (lower right-hand side)
  • Added list of Collections
12/03/2026
  • Created codes
    • 3-digit footer
    • 5-digit collection
    • 6-digit presentation
  • Heavy editing and reorganising
13/03/2026

Content reuse

The same material can be reused in many formats.

  • Developer Docs
  • User learning (Diataxis)
  • In-context workspace help
  • Newsletters
  • This blog
  • Whitepapers
  • Etc

Slide Footers (Host websites)

Visit the Presentation Catalogue (Google Sheet)

  • 100 Ajabbi
  • 101 Ajabbi Learn
  • 102 Ajabbi Design
  • 103 Ajabbi Research
  • 104 Ajabbi Foundation
  • 105 Ajabbi Developer
  • 106 Ajabbi Handbook
  • 107 pipiWiki
  • 108 Ajabbi Community
  • 109 Ajabbi Project
  • 110 Ajabbi i18n
  • 111 Ajabbi Workspace

Collections

Visit the Presentation Catalogue (Google Sheet)

  • 101-10001 Personal Account
  • 101-10002 Enterprise Account
  • 101-10003 Developer Account
  • 101-10004 Researcher Account
  • 101-10005 SME Account
  • 107-10006 Engines
  • 101-10007 Content Management System
  • 106-10008 History
  • 106-10009 Engineering
  • 106-10010 Ajabbi
  • 103-10011 About
  • 103-10012 Research Publications
  • 103-10013 Research Platform
  • 104-10014 Mission
  • 101-10015 Agent Account
  • 102-10016 Components
  • 102-10017 Accessibility
  • 109-10018 Accessibility
  • 105-10019 Boxlang
  • 107-10020 Industries
  • 107-10021 Plugins
  • 109-10022 i18n
  • 103-10023 Complex Systems
  • 104-10024 Programme
  • 104-10025 Board

Talks & Demos

Visit the Presentation Catalogue (Google Sheet)

101 Ajabbi Learn

  • 101-10007 Content Management System
    • 101 Introduction
    • 102 Content Management System
    • 103 Publication
    • 104 Website
    • 105 Blog
    • 106 Wiki
    • 107 Docs
    • 108 Help
    • 109 Workspace
  • <Unknown>
    • Agents & engines
    • How to use the engines
    • DevOps
    • Security
    • Pipi
    • Sign up
    • Choosing an account type
  • 101-10001 Personal Account
    • Personal Account
    • Username, password, and 2FA
    • Account settings
    • Create a profile
    • Languages
    • Accessibility
    • Support
    • Training
  • 101-10002 Enterprise Account
    • Enterprise account
    • Account settings
    • Default Language
    • Billing
    • Support
    • Training
    • Creating a deployment
    • Choose a Language
    • SaaS configuration
    • Creating a workspace
    • Adding modules
    • Adding Plugins
    • Roles and Permissions
    • Adding Users
  • 101-10003 Developer Account
    • Developer account
    • Account settings
    • Default Language
    • Billing
    • Support
    • Training
    • Creating a deployment
    • Choose a Language
    • Creating a workspace
    • Adding modules
    • Adding Plugins
    • Roles and Permissions
    • Adding Users
  • 101-10004 Researcher Account
    • Researcher account
    • Account settings
    • Default Language
    • Billing
    • Support
    • Training
    • Creating a workspace
    • Adding modules
    • Adding Plugins
    • Roles and Permissions
    • Adding Users
  • 101-10005 SME Account
    • SME account
    • Account settings
    • Default Language
    • Billing
    • Support
    • Training
    • Choosing a module
    • Roles and Permissions
    • Adding Users
  • 101-10015 Agent Account
    • Agent Account
    • Account settings
    • Default Language
    • Billing
    • Support
    • Training
    • Creating a deployment
    • Choose a Language
    • Creating a workspace
    • Adding modules
    • Adding Plugins
    • Roles and Permissions
    • Adding Users

102 Design System

  • 102-10016 Components

  • 102-10017 Accessibility

103 Ajabbi Research

  • 103-10011 About
    • Ajabbi Research 
    • Role and purpose
    • Income
    • Open handbook
    • Team culture
    • Open Research
    • Library
    • Projects
  • 103-10023 Complex Systems

  • 103-10012 Research Publications
    • Publications
    • Newsletter
    • Friday Report
    • Seminars
    • On arXiv
  • 103-10013 Research Platform

104 Ajabbi Foundation

  • 104-10014 Mission
    • Ajabbi Foundation
    • Role and purpose
    • Income
    • The Open Handbook
    • Team culture
  • 104-10025 Board

  • 104-10024 Programme
    • Future support
    • Ortus Open-source
    • SIL KeyMan
    • User groups
    • Books

105 Pipi Developer

  • 105-10019 Boxlang
    • BoxLang in a VM
    • BoxLang in Docker

106 Ajabbi Handbook

  • 106-10010 Ajabbi
    • Ajabbi intro
    • Who am I
    • Resources
    • Thanks & Questions
    • Origin
    • Mission & values (why)
    • Organisational form
    • Ajabbi
    • Role and purpose
    • SaaS
    • Profit distribution
    • From customers to community-driven
    • Bootstrap Startup
    • Scaling
    • Open-source
    • GitLab
    • GitHub
    • Future Collaborations
    • Unicode
    • OMG
    • W3C WCAG
    • CNCF
    • Pipi
    • Intro
    • Origin
  • 106-10008 History
    • Pipi 1-5 (1997-2008)
    • Pipi 6 (2017-2019)
    • Pipi 7 (2020)
    • Pipi 8 (2021-2022)
    • Pipi 9 (2023-2026)
  • 106-10009 Engineering
    • Closed core & open-source
    • Closed-core
    • Roadmap
    • Pipi 9 (2023-2026)
    • Pipi 10 (2027-2029)
    • Pipi 11 (2030-)
    • Open-source
    • Roadmap
    • Pipi 9 (2023-2026)
    • Pipi 10 (2027-2029)
    • Pipi 11 (2030-)

107 pipiWiki

  • 107-10006 Engines
    • Algorithm Engine (alg)
    • CMS Engine (cms)
    • Configuration Engine (cnf)
    • Factory Engine (fac)
    • Workflow Engine (wfl)
    • Workspace Engine (wsp)
  • 107-10020 Industries
    • Agriculture
    • Arts & Culture
    • Built Infrastructure
    • Civil Defense
    • Data Centre
    • DevOps
    • Learning
    • Nature Conservation
    • Research
    • Transport
  • 107-10021 Plugins
    • AddThis
    • Amazon Book
    • Apple Map
    • Apple Music
    • ArcGIS Map
    • Atlassian Analytics
    • Azure Map
    • Cacophony
    • CloudConvert
    • CodePen
    • CodeSandbox
    • Confluence
    • Elfsight Weather
    • Flightradar24
    • FormBlock
    • GitHub-Embed 
    • GitLab Snippet
    • Google Analytics
    • Google Calendar
    • Google Docs
    • Google Form
    • Google Map
    • Google Meet
    • Google Sheets
    • Google Slides
    • Instagram
    • IUCN Threat Status 
    • Jira Advanced Roadmap  
    • JSBin
    • Jupyter Notebook
    • KeyMan
    • MailChimp
    • Metservice Weather
    • Microsft Forms
    • Monaco Editor
    • NASA Spot the Station 
    • NASA Worldview
    • NetSuite Case Form 
    • NIWA CO2 Widget
    • NIWA Tide Widget
    • NIWA UV Widget
    • NIWA Weather Widget
    • Odoo Form
    • PDF
    • PostHog Analytics
    • Survey Monkey
    • Trello Board
    • Trello Card
    • TypeForm
    • VesselFinder
    • Vimeo Video
    • Weather Widget
    • Wolfram Notebook  
    • Yandex Map
    • Yandex Video
    • YouTube Video
    • Zoho Calendar
    • Zoho Form
    • Zoom Meeting
108 Ajabbi Community

109 Pipi Project
  • 109-10018 Accessibility
    • Accessibility Profile
    • UK.Govt Design Guide
  • 109-10022 i18n
    • Web KeyMan
    • Mobile KeyMan
110 Ajabbi i18n

111 Ajabbi Workspace

About time

Mike's Notes

If we are lucky, we get 4,000 weeks to live, love and contribute.

Make every week count.

Resources

References

  • Reference

Repository

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

Last Updated

08/03/2026

About time

By: Chris Loy
Chris Loy: 27/12/2024

Hey, I'm Chris. Nice to meet you!

I spend my professional life writing code, training machine learning models, building software products and running tech teams. I'm a startup founder with a successful exit, and in my career I've been CTO, a developer and a data scientist. I've worked at companies big and small, mentored junior engineers and data scientists from across Europe, and served as an advisor for some companies. Throughout my career I have been lucky enough to work with and hire some amazingly smart people.

This is my website, where I write about tech, data and AI, as well as some of my other interests and hobbies. Those include music and photography, and I also use this site to document the books I read..

As I write this, I’m about 7 months away from my 40th birthday. That milestone, numerologically important to inhabitants of our particular planet who happened to evolve 10 fingers upon which to count, will come a little past the halfway point of the average life expectancy of males from my country of birth.

We are a couple of days away from the start of 2025, and it seems like a suitable moment to reflect on the passage of life.

4,000 weeks

Back in 2022, I read Oliver Burkeman’s thought provoking book Four Thousand Weeks, named for the length of time that more or less corresponds with the average human lifetime. A worldview that acknowledges this surprisingly brief existence can be traced back to Roman stoicism - notably Seneca and Marcus Aurelius.

Fans of thinking about their own inevitable death sometimes create diagrams like this one:

My 4,000 weeks

This chart displays my life from birth, through to an expected death around 80 years old, with a few assumptions such as retirement at age 65. Each square is a week, each row is a year, and I have coloured it to indicate the major time demarcations of my life thus far. The current calendar year of 2024 is marked by a border, and as you can see lies around the midpoint.

Time moves fast and slow

The thin yellow sliver at row 31 represents my time studying Machine Learning at UCL. This period looks tiny on my diagram, but it looms large in my memory. In that year I switched careers, I studied a new field, and I found a new passion that led me into the world of AI. I also met my wife, and the co-founders of Datasine - my first startup that stands out in blue on the above chart. That little yellow line was a pivotal and momentous year.

In comparison, the first green slice (my time working for tech companies as an engineer) is more than 8 times the length, but now feels far less substantial in how I think of myself as a person.

The lesson is that 4,000 weeks can be a long time, or can be a short time. It is the meaning ascribed to each week that dictates the importance - not the length.

Age is biological

In recent years, I have become increasingly aware of the limitations placed upon us by biology. As my peers and I face both the aging of our own parents, our own growing awareness that we are not as young and fit as we used to be, and the shock of sudden severe illness and even death among our friends and colleagues, we start to think more seriously about our future health.

In the part of the diagram that is above, there are a handful of hospital visits - a couple of broken bones and sprained ankles, an emergency appendectomy near the end of row 24. Several rows in the school years with various medications for lung issues that variously pushed my weight up and down, affected my skin etc.

Despite this smattering of issues here and there, the reality is that 90% of my health problems are ahead of me. If I want to live my fullest life through the bottom half of this diagram, I need to start thinking more seriously about my physical health and wellbeing, and preserving the state that I am in as long as possible.

Life happens

I started writing this blog some way into row 29. It isn’t the first website I’ve kept, but I remember deciding to break with a past that had included vague aspirations towards journalism, creative writing and other pursuits. “I’ll write a tech blog!”, I thought, and so I did.

But over time, all that other messy stuff - life - kept creeping back in: sporadically voracious reading habits to be documented, music to be made in the dead of night and leaked out into dark corners of the internet, cryptic crosswords to nerd over, and much more besides.

This is part of a wider pattern across my life. As I have got older, I have also got fuzzier. I can’t think of a better way of describing it. I have let the partitioned parts of my life blend and overlap in a way that when younger I would have found frankly embarrassing. Is this what acceptance is - a letting go of your ability to control the separation between the parts of your life that you try to optimise separately?

Even the choice of colour coding above feels increasingly arbitrary and artificial. Why demarcate a life through jobs and education? Why not relationships, or books read, or recipes learned, or jokes told?

At the top of the hill

I really don’t like the phrase “over the hill”. It is usually quite disparaging, implying a decline that has set in to the point at which a person’s actions are of little importance.

Nonetheless, I find myself feeling the urge to acknowledge that I am likely currently standing at the top of the hill - in the best possible position dispassionately to survey all the terrain I have covered so far, and to look ahead and see where the road might lead as I start my descent down the second half of my 4,000 weeks.

I believe that this is an urge I should resist. Does the second half of my life just involve winding my way down into the valley, trying not to stumble, tipping my cap to others travelling past me on their way to the summit? I certainly hope not.

My belief is that the second half of that diagram contains greater summits to scale. To reach them, and make the most of my remaining 2,000 weeks, I will need to be strong of body and of mind, more than a little bit lucky, and walking with my eyes fixed on the horizon.

SIL KeyMan

Mike's Notes

Recently, I received an email from SIL KeyMan requesting donations to support their excellent, free, open-source, multilingual keyboards. They had lost a major donor whose circumstances had changed. This article is about what followed on from that message.

Where I stand

"Every child has the right to be educated in the language of their people and of their birth. This (issue) is dedicated to those working tirelessly to record, strengthen or revive human languages." - The i18n Issue, Ajabbi Research.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > KeyMan Newsletter
  • Home > Handbook > 

Last Updated

07/03/2026

SIL KeyMan

By: Mike Peters
On a Sandy Beach: 07/03/2026

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

Background

I had long planned to use KeyMan with Pipi to enable people to use their choice of written language.

Tibetan Keyboard

After receiving an email from SIL Keyman requesting donations, I sent a message offering future donations from the yet-to-be-established Ajabbi Foundation. Ajabbi is a community-driven bootstrapping pre-revenue startup that solves some very big, expensive problems with Pipi. With no investors needed, the surplus income will go to a future foundation to support open-source, books, user groups, conferences, science, etc.

They replied via a developer in Australia who contacted me.

I then spent a bit of time reading their blog, learning about their 30-year effort, watching a seminar, and looking at their GitHub repository. They are very humble and very impressive.

Thinking more about it, they need more developers in their team working on this important project for humanity.

Future long-term sponsorship priorities of open-source

  1. Support Ortus in providing free CommandBoxBoxLang, etc., and outsource all related remote development to them.
  2. Support SIL KeyMan to provide free KeyMan access and ensure they can meet demand, scale, and focus on supporting KeyMan rather than raising funds. Everyone has the right to use their own language.

Memberships

Another option could be for Ajabbi Research to join Unicode as a paid member and contribute.

Pipi Keyboard Engine (kyb)

A new Pipi engine will be created to handle keyboards.

Pipi 10 (2027-)

The Pipi 10 roadmap includes support for multiple languages and scripts across all workspace User Interface (UI) components. The hundreds of agent engines, their internal databases and namespaces already support this.

One of the primary tools will be to embed a language-specific keyboard using KeyMan Engine for Web in the HTML of the workspace UI for individual users. This will be available to all users using a simple profile form.

Code Example


<script src='https://s.keyman.com/kmw/engine/18.0.246/keymanweb.js'></script>
<script src='https://s.keyman.com/kmw/engine/18.0.246/kmwuitoggle.js'></script>
<script>
  (function() {
    keyman.init({attachType:'auto'});
    keyman.addKeyboards('@en'); // Loads default English keyboard from Keyman Cloud (CDN)
    keyman.addKeyboards('@th'); // Loads default Thai keyboard from Keyman Cloud (CDN)
  })();
</script>

KeyMan currently supports 1550 keyboards and 2650 languages. It uses CLDR/LDML to configure the keyboards. This is wonderful news and will make it very easy to integrate with Pipi 10.

There is a great Cloud Services API which will assist automation.

Translation

The keyboards will assist with volunteer user input to translate the Pipi User Interface into many languages, much like OpenOffice and Wikipedia/MediaWiki.

Codes

Since Pipi 6 (2017-2019), standard codes have been used internally to make internationalisation possible for potentially every language.

ISO 639-3

ISO 639 gives comprehensive provisions for the identification and assignment of language identifiers to individual languages, and for the creation of new language code elements or for the modification of existing ones (Terms of Reference of the ISO639/MA). - ISO 639-3

*** 

It defines three-letter codes for identifying languages. The standard was published by the International Organisation for Standardisation (ISO) on 1 February 2007. As of 2023, this edition of the standard has been officially withdrawn and replaced by ISO 639:2023.

ISO 639-3 extends the ISO 639-2 alpha-3 codes with an aim to cover all known natural languages. The extended language coverage was based primarily on the language codes used in the Ethnologue (volumes 10–14) published by SIL International, which is now the registration authority for ISO 639-3.[2] It provides an enumeration of languages as complete as possible, including living and extinct, ancient and constructed, major and minor, written and unwritten. However, it does not include reconstructed languages such as Proto-Indo-European.

ISO 639-3 is intended for use as metadata codes in a wide range of applications. It is widely used in computer and information systems, such as the Internet, in which many languages need to be supported. In archives and other information storage, it is used in cataloging systems, indicating what language a resource is in or about. The codes are also frequently used in the linguistic literature and elsewhere to compensate for the fact that language names may be obscure or ambiguous. Wikipedia

Examples

  • Eng (English
  • Fra (French)

ISO_3166-1_alpha-3

ISO 3166-1 alpha-3 codes are three-letter country codes defined in ISO 3166-1, part of the ISO 3166 standard published by the International Organization for Standardization (ISO), to represent countries, dependent territories, and special areas of geographical interest. They allow a better visual association between the codes and the country names than the two-letter alpha-2 codes (the third set of codes is numeric and hence offers no visual association). They were first included as part of the ISO 3166 standard in its first edition in 1974. - Wikipedia

 Examples

  • ABW  (Aruba)
  • AFG  (Afghanistan)
  • AGO  (Angola)

Unicode

Unicode (also known as The Unicode Standard and TUS) is a character encoding standard maintained by the Unicode Consortium designed to support the use of text in all of the world's writing systems that can be digitized. Version 17.0[A] defines 159,801 characters and 172 scripts used in various ordinary, literary, academic and technical contexts. - Wikipedia

Examples

  • Latn (Latin)
  • Lina (Linear B)
  • Hebr (Hebrew)

CLDR/LDML

The Common Locale Data Repository (CLDR) is a project of the Unicode Consortium to provide locale data in XML format for use in computer applications. CLDR contains locale-specific information that an operating system will typically provide to applications. CLDR is written in the Locale Data Markup Language (LDML). - Wikipedia

Example

 <?xml version="1.0" encoding="UTF-8" ?>
<ldml>
  
    <version number="1.1">ldml version 1.1</version>
    <generation date="2024-03-06"/>
    <language type="en"/>
    <territory type="US"/>
  
  <!-- other locale data sections follow -->
</ldml>

Localisation (L10N)

Language localisation (or language localisation) is the process of adapting a product's translation to a specific country or region. It is the second phase of a larger process of product translation and cultural adaptation (for specific countries, regions, cultures or groups) to account for differences in distinct markets, a process known as internationalisation and localisation. - Wikipedia

***

Pipi internally automatically stores and uses 3-letter language codes, 4-letter Unicode and 3-letter country codes to define Locales. Other code formats are also stored to enable interoperability. Many languages can be written in several scripts.

Examples

  • eng-Latn-NZD (New Zealand English)
  • eng-Latn-USA (United States English)

Customers can configure the options for their own websites.

Examples

  • en-NZ
  • en-uk