Database Design for Google Calendar: a tutorial

Mike's Notes

The first customer needs a Gregorian calendar module that can import and export with Google Calendar, and the rest (Outlook, Yahoo, etc). Here are some notes and references to help me build this quickly. The data model is mainly complete.

There is also an existing Pipi Engine that deals with space and time.

Below is a table of contents from the Google Calendar online article by Alexey Makhotkin, taken from his book.

Resources

References

  • Database Design Book. By Alexey Makhotkin.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Minimal Modelling
  • Home > Handbook > 

Last Updated

11/07/2025

Database Design for Google Calendar: a tutorial

By: Alexey Makhotkin
Database Design Book: 20/05/2024

Table of contents

  • Introduction
  • Intended audience
  • Approach of this book
  • Problem description
  • Part 1: Basic all-day events
    • Anchors
    • Attributes of User
    • Attributes of DayEvent
    • Links
    • A peek into the physical model
  • Part 2: Time-based events
    • Time zones
    • Anchors
    • Attributes of Timezone
    • Attributes of TimeEvent
    • Links
    • Similarities between DateEvent and TimeEvent
  • Part 3. Repeated all-day events
    • Attribute #1, cadence
    • Attribute #2, tangled attributes
    • Attribute #3
    • Days of the week: micro-anchors
    • Are we done?
    • Repeat limit: more tangled attributes
  • Part 4. Rendering the calendar page
    • A note on tempo
    • General idea
    • Day slots
    • Exercise: TimeSlots
    • How far ahead do you need to think?
  • Part 5. Rendering the calendar page: time-based events.
  • Part 6. Complete logical model so far
  • Part 7. Creating SQL tables
    • Anchors: choose names for tables
    • Attributes: choose the column name and physical type
    • 1:N Links
    • M:N links
    • Finally: the tables
  • Conclusion
    • What’s next?
By , No comments:
Tags , , ,

Bootstrapped CPC rule of thumb: ARPU/25

Mike's Notes

Ajabbi is a bootstrapping social enterprise, but the useful measures outlined in this excellent article still apply.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > A Smart Bear
  • Home > Handbook > 

Last Updated

09/07/2025

Bootstrapped CPC rule of thumb: ARPU/25

By: Jason Cohen
A Smart Bear 01/07/2025

In the first year of business, you have no data for decision-making.

Even after the first hundred customers, half of those were serendipitous one-offs, not representative of repeatable, predictable customer acquisition, and the scale of the data isn’t statistically significant.

One of the fundamental data-driven questions (but you don’t have data) is: What’s the maximum I should bid for CPC (cost-per-click) campaigns like Google AdWords?

The answer for a funded startup is “Bid as much as possible, to get as many customers—and data!—as you can, as quickly as you can, then rapidly iterate from there in the presence of that data.”

That’s a smart use of money: To “pay to find out.” But what about a bootstrapped, profit-driven business? You don’t have that budget, and you’re keen on getting a reasonable return on investment reasonably quickly.

Here’s my way.

(Tune the exact numbers if you disagree with my assumptions!)

LTV = ARPU x 20

ARPU (Average Revenue Per User) is the amount you charge the average customer every month, which is typically a mixture of different quantities of customers at different tiers, special add-ons, etc..

LTV (Life-Time Value) is the total amount of money you expect to collect from a customer over their entire tenure. A simple version [1] is ARPU ✕ [expected months] meaning the average number of months a customer sticks with you.

[1] The correct version also includes multiplying by Gross Profit Margin, i.e. the cost to serve customers, which for SaaS is tech support, server infrastructure, and payment fees. You should include this for a more accurate calculation; small bootstrapped companies often have very high GPMs, so ignoring it for this back-of-the-envelop calculation was simpler.

Some customers cancel in one month, some cancel in a year, some in five years, and some never cancel! So it can be difficult to compute LTV accurately for small companies, and impossible to know for young companies (where five years hasn’t elapsed yet to see how many customer stuck it out that long). These are among the reasons that I dislike the LTV metric, but it’s common to use it in this context.

If you do have data, the simplistic calculation is [expected months] = 1/c where c is your monthly cancellation rate.

But since you don’t, in my experience (and in a non-scientific survey of some of the 100 startups currently officed at the fabulously Capital Factory co-working space in Austin), a good pre-data rule of thumb is 20 months.

If you have an average customer lifetime smaller than 20 months (i.e. cancellation rate higher than 5%/mo), that’s a dangerously high cancellation rate for almost any SaaS business, and you need to focus on addressing the business issues before acquiring more unsatisfied customers. Use surveys and one-on-ones to try to understand whether it’s technical failings, lack of features, missed expectations, bad service, doesn’t hit pain points, or what.

A healthy SaaS company will have a higher number of expected months, but at the start you also will have lots of mis-steps with weird early-adopters and non-ICPs where your product is at its worst—least features, least quality, etc—so it’s good to assume a low LTV instead of inflating it to where it might be in future.

CAC = LTV / 5

CAC (Cost to Acquire a Customer) is your average total cost to get a new customer, which includes direct costs (AdWords spend, affiliate payouts, the fees your affiliate system charges to process them) and indirect costs (consultants and your own time). So to compute CAC, take your total costs to acquire new customers and divide by the number of customers you acquired.

In general of course CAC needs to be less than LTV, otherwise it costs so much to get the customer that you will never make money. A surprising number of startups have CAC > LTV. Many justify this either by not correctly computing CAC (e.g. ignoring indirect costs) or saying they’ll “fix that later” by raising prices or finding other channels of revenue. Others justify by saying they’re doing a “land-grab” for customers, and just having a customer at all has intrinsic value.

Profit-seeking bootstrapped companies cannot afford those delusions. Also you need something far stronger than CAC = LTV, because you need to pay for other business expenses and still produce a profit. So how big can CAC be before it’s “too big?”

Growing, funded SaaS companies who treat CAC with respect often commonly target CAC = LTV / 3.

Back at my second startup IT WatchDogs, my co-founder Gerry Cullen used to say “A third to built it, a third to get rid of it, and a third to keep,” meaning a third of revenue goes to pay for hardware/inventory/shipping costs of the sale, a third goes to what I’m calling “CAC” here, and a third for the overhead costs, development costs, and profit.

That’s a good model, and I think a bootstrapped company can copy it, but I urge profit-seekers to instead adopt an even more strict model of CAC = LTV / 5. The reason is that at the start you should be able to find a few efficient ways of acquiring customers, even if those get saturated over time.

CAC = ARPU x 4

If you combine the previous two results, you see that the cost to acquire a customer should be no more than four months of revenue.

Another good way to think about it is: “The payback-period for my cost to acquire a customer is four months.” Also, ideally you’re getting the first month of revenue back immediately, so it’s really three months of cash-float.

Companies with large budgets to deploy at scale will often be happy with 12 month payback periods; some very high volume businesses like shared hosting will accept 24 or 36 months! But a bootstrapped company’s cash-flow won’t allow it, even if the math would work in the long run.

Conversion Rate = 1%

Conversion Rate is the percentage of visitors to your website who convert to a paying customer.

This is another step which in practice should be completely data-driven, segmented by customer type and marketing channel, segmented by landing page, A/B tested and iterated, blah blah blah. But since you don’t have data, and you don’t have enough visitors to have real ratios, you have to take a swag at this number.

In that same informal survey I ran, and bolstered by other formal surveys, a huge number of bootstrapped SaaS companies report a 1% conversion rate.

Another way of saying the same thing is “You need 100 visitors to make 1 sale.”

And since you need to incur no more than CAC dollars in the making of that sale, you need to incur no more than CAC/100 dollars in the making of each of those visitors.

And if you’re running a CPC campaign, that means you can pay up to CAC/100 dollars per click.

And since CAC is ARPU x 4, we can substitute and get the end result:

CPC = ARPU / 25

So for example if your average customer generates $50/mo, you can spend $2/click.

Indeed, this is a great way to prove one of my main arguments for all bootstrapped companies, which is that you should charge a lot more than you think, in part because it enables you to pay quite a lot per click, which enables a wide number of marketing channels, and out-bidding parsimonious competitors whose paltry LTVs preclude them from competitive marketing spend.

Customized

“But my numbers are different!” Of course, but now you have a formula you can plug them into, to arrive at the answer:

CPC = (ARPU) r/5c

Where:

  • c = monthly cancellation rate
  • r = visitor → purchase conversion rate from the paid marketing source in question

By , No comments:
Tags , ,

Everything, everywhere, all at once: Inside the chaos of Alzheimer’s disease

Mike's Notes

This article provides a clear explanation of the brain with Alzheimer's disease. It's also a great example of a complex system.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Transmitter
  • Home > Handbook > 

Last Updated

08/07/2025

Everything, everywhere, all at once: Inside the chaos of Alzheimer’s disease

By: Michael Yassa
The Transmitter: 16/06/2025

Michael A. Yassa is professor of neurobiology and behavior and James L. McGaugh Endowed Chair at the University of California, Irvine. His lab has been developing theoretical frameworks and noninvasive brain-imaging tools for understanding memory mechanisms in the human brain and applying this knowledge to human neurological and neuropsychiatric disease.

To truly understand Alzheimer’s disease, we may need to take a systems approach, in which inflammation, vascular injury, impaired glucose metabolism and other factors interact in complex ways.

For nearly three decades, Alzheimer’s disease has been framed as a story about amyloid: A toxic protein builds up, forms plaques, kills neurons and slowly robs people of their memories and identity. The simplicity of this “amyloid cascade hypothesis” gave us targets, tools and a sense of purpose. It felt like a clean story. Almost too clean.

We spent decades chasing it, developing dozens of animal models and pouring billions into anti-amyloid therapies, most of which failed. The few that made it to market offer only modest benefits, often with serious side effects. Whenever I think about this, I can’t help but picture Will Ferrell’s Buddy the Elf, in the movie “Elf,” confronting the mall Santa: “You sit on a throne of lies.” Not because anyone meant to mislead people (though maybe some did). But because we wanted so badly for the story to be true.

So what happened? This should have worked … right?

I would argue it was never going to work because we have been thinking about Alzheimer’s the wrong way. For decades, we have treated it as a single disease with a single straight line from amyloid to dementia. But what if that’s not how it works? What if Alzheimer’s only looks like one disease because we keep trying to force it into a single narrative? If that’s the case, then the search for a single cause—and a single cure—was always destined to fail.

What if Alzheimer’s only looks like one disease because we keep trying to force it into a single narrative? If that’s the case, then the search for a single cause—and a single cure—was always destined to fail.

Real progress, I believe, requires two major shifts in how we think. First, we have to let go of our obsession with amyloid. Now don’t get me wrong. There’s no question amyloid plays a role. It was the first thing Alois Alzheimer saw under the microscope in 1906. And there’s decent evidence that misfolded amyloid spells trouble for the brain. But betting the house on clearing amyloid has been a costly mistake. In fact, we have long known that one-third of people with amyloid pathology do not show any cognitive symptoms, a disconnect that should have forced a rethink years ago.

To the field’s credit, a shift is underway. We’re now exploring other mechanisms—tau, inflammation, metabolic dysfunction, vascular damage, neuronal hyperexcitability and more. But too often, these alternatives are still treated as side plots in an amyloid-centered story. They get less funding, less attention and fewer drug development efforts. That needs to change. These mechanisms may be far more central to the disease than we once thought. And they may drive it differently in different people.

This brings us to the second shift: We need to stop thinking in straight lines. The brain isn’t exactly a flowchart. It’s a dynamical system—a tangled web of feedback loops, compensations and nonlinear interactions. In such systems, small disruptions can ripple outward in unexpected ways. When one part starts to fail, another compensates. Over time, those compensations can become part of the pathology. In some people with Alzheimer’s disease, amyloid might be the trigger. In others, it might be inflammation, vascular injury, impaired glucose metabolism or runaway neural activity. These factors don’t act in isolation—they interact in complex ways, creating a web of multicausal loops. They are less like a chain of dominoes and more like a knot of tangled threads pulling on one another.

In systems terms, it’s not a cascade. It’s a state space. To understand this space, it’s useful to imagine a map in which every possible state of the brain is a point. In this space, healthy brains tend to move within a basin of attraction, a functional stable state. In Alzheimer’s, the brain may be pushed by interacting pathologies into a different region of state space, a pathological attractor—stable but dysfunctional.

There’s growing experimental support for this view. Functional imaging, for example, has shown that people with Alzheimer’s spend more time in sparsely connected, low-flexibility brain states, and MEG recordings reveal changes in the temporal complexity of network dynamics. Recent work in my lab identified a dominant state, characterized by co-activity of nodes in the limbic network, that is linked to worse cognition and Alzheimer’s pathology. The idea is that once the brain tips into the dysfunctional state, it can get stuck there, even if you remove the original trigger.

The idea is that once the brain tips into the dysfunctional state, it can get stuck there, even if you remove the original trigger.

Researchers have already identified a number of “systems-level” factors that can disrupt network stability and contribute to Alzheimer’s disease, including vascular compromise, in which small vessel disease disrupts blood flow and triggers downstream effects; metabolic dysfunction, such as insulin resistance or glucose hypometabolism; runaway inflammation, such as overactive microglia or cytokine chaos; and overactivity, driven by an imbalance in neuronal excitation or inhibition. These factors may represent different systems-level routes to the same clinical outcome. Each person’s condition likely involves a different mix or “weighting” of underlying mechanisms. For someone with a history of diabetes, metabolic dysfunction might be the dominant factor. For someone with high blood pressure, the vascular component could play a bigger role. Ultimately, pinpointing this weighting—the primary mechanism driving the system’s dysfunction, or the mechanistic phenotype—could help match people with the most appropriate treatment.

This framing also changes how we think about treatment. In a system governed by feedback loops and nonlinear dynamics, removing a single trigger may not be sufficient to get the system “unstuck.” That may explain why anti-amyloid drugs haven’t made a major clinical impact: By the time symptoms show up, the system has already reorganized itself. Instead, we may need interventions that restore network stability—rebalancing excitation and inhibition, reducing inflammation or improving metabolic resilience. Noninvasive brain stimulation is one such approach, potentially nudging the system toward a more functional dynamic without needing to target a molecular mechanism. The goal isn’t to fix a part. It’s to shift the conditions that shape how the whole system behaves.

So where is amyloid in all this? Well, amyloid is always present, because our diagnostic criteria make it so. Think of it like background noise—it’s there, but it may not be what’s pushing the system off-key. Unlike the factors described above, amyloid doesn’t consistently drive network-level disruption. It reflects cellular dysfunction, such as misprocessing of amyloid precursor protein or altered lipid metabolism, but the downstream systems-level effects aren’t nearly as consistent or potent as those seen with, say, inflammation or synapse loss. This doesn’t mean addressing amyloid buildup or clearance has no clinical value. It just means it’s likely a small piece in a much larger puzzle. Focusing on it is like trying to fix a whole cacophonous orchestra by tuning but one violin.

Of course, there’s no perfect framework yet. To build it, we’ll need better tools. That includes better ways to capture brain dynamics in vivo, not just static pathology. We also need animal models that go beyond single-gene variants—instead, we need models that combine multiple hits, such as inflammation plus hyperexcitability. And we need ways to track these factors in humans, using multimodal imaging, physiological sensors and inflammatory biomarkers.

Getting there will take work. Paradigm shifts happen slowly, painfully, often after the old model has failed enough times to lose its grip. That’s where we are now. The dominant model isn’t working anymore. What comes next isn’t fully formed—but it’s coming into view. Mechanistic phenotyping and dynamical systems thinking may offer a path forward. It won’t be neat or linear. But it may finally meet the disease on its own terms.

By , No comments:
Tags , , ,

Supporting “Power Users” Isn’t Enough: 3 Complex-App User Types

Mike's Notes

I will implement this excellent advice in future changes to the Pipi UI framework.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The NN/g Newsletter
  • Home > Handbook > 

Last Updated

07/07/2025

Supporting “Power Users” Isn’t Enough: 3 Complex-App User Types

By: Kate Kaplan
NNGroup: 27/06/2025

Kate Kaplan is Nielsen Norman Group's Insights Architect. She specializes in the application of human-centered design and research practices to enterprise UX challenges. With over 15 years in UX, Kate has extensive experience in both conducting research and helping teams understand and apply user insights to overall business strategy.

Summary:

Complex-app users don’t always fit neatly into “novice” or “expert” labels. Designing for Legacy, Legend, and Learner users leads to more inclusive, effective systems.

When designing complex applications, practitioners often feel pressure to center efforts around “power” users: highly trained professionals with deep domain knowledge and years of experience using the software in question. While these expert users are important, focusing solely on them means overlooking other critical user types.

This tendency reflects a deeper issue: the overly simplistic assumption that complex-app users fall into one of two categories: either novices or experts. In reality, this binary framing fails to account for the users who don't fit cleanly into either category — such as long-term users who never achieved deep system mastery, or domain experts who are new to the software and still learning how to navigate complex workflows. Failing to recognize these nuances results in exclusionary design, inefficient workflows, and missed opportunities to improve user experience.

In This Article:

  • Three Complex Apps User Types
    • 1. The Legacy
    • 2. The Legend
    • 3. The Learner
  • Balancing All Three User Types

Three Complex Apps User Types

To move beyond the novice-expert binary, we need a more nuanced understanding of how people actually engage with complex applications.

Complex applications are systems designed to support specialized workflows, often involving multiple user roles, advanced configurations, and domain-specific operations. 

These tools demand higher levels of cognitive load and feature density compared to typical consumer apps, and they attract a broad range of users whose experience with the software varies widely.

When I coach people to design better complex applications, I highlight three distinct complex-app user profiles whose needs, behaviors, and limitations are often misunderstood or overlooked.

  • The Legacy: The long-term user with deep familiarity but low efficiency
  • The Legend: The power user who has achieved expert-level proficiency
  • The Learner: The domain expert who is new to the software and still building system knowledge

Each of these user types presents distinct design challenges and opportunities that are often overlooked in design decisions and roadmap planning.

1. The Legacy

A legacy user has used the software for years or even decades but hasn’t become truly efficient. Longevity has not translated into true system expertise or understanding. We often mistake legacy users for power users, assuming that frequent and long-term use equates to deep system expertise. However, many of these users continue using the system inefficiently for decades, learning and utilizing only what they need to get by, rather than the system as a whole.

Legacy users often:

  • Use rigid, familiar methods to accomplish tasks
  • Avoid customization and stick to system defaults
  • Use only a narrow slice of the application’s features
  • Develop workarounds (e.g., bookmarks, personal notes, manual processes)

How Legacy Users Are Left Behind

Legacy users are often viewed as resistant to change. The assumption is that they simply don’t want to learn new methods and fear any design modifications, optimizations, or usability improvements. But, in reality, what they often fear is loss of productivity, not change itself. 

Many of these users have adapted to suboptimal workflows over time and are wary of changes that disrupt what little efficiency they have established. 

As one complex-apps practitioner explained, this resistance often stems from deep habits and experience with the existing system:

It wasn't what they were used to. There was that resistance to change. They have great muscle memory. They have great experience. They know workarounds on how to maneuver or how to operate certain things.

These ingrained behaviors can make it difficult for legacy users to recognize inefficiencies or adapt to new workflows, even when those workflows are objectively better designed.

How to Support Legacy Users

Supporting legacy users means recognizing that familiarity doesn’t always equal mastery, and that productivity, not resistance, is often at the heart of their hesitation. The key is to introduce improvements with change-aversion in mind — in a way that feels safe, respectful of their workflows, and clearly beneficial. 

To support legacy users:

  • Avoid sudden, large-scale UI changes that disrupt learned behaviors
  • Communicate upcoming changes early and clearly
  • Provide the option to keep legacy views or workflows during transition periods
  • Offer low-risk beta environments to explore new features
  • Involve them in usability testing and rollout feedback loops
  • Emphasize feature discoverability, especially for time-saving shortcuts

2. The Legend

A legend user is a system expert who has reached a high level of efficiency and fluency within the application. They’ve mastered shortcuts, customized their workflows, and are often deeply embedded in user communities or advisory roles.

We often hear from legend users the most through channels such as forums, beta launches, and customer advisory groups. Their influence can be substantial, and their requests often reflect deep technical understanding and a desire for even greater user control and freedom.

Legends often:

  • Use keyboard shortcuts, macros, and accelerators extensively
  • Advocate for advanced features and customization
  • Desire and request greater flexibility in workflows and outputs
  • Engage heavily in feedback channels, user communities, or advisory boards

How Legend Users Are Left Behind

Legend users introduce two different but significant risks.

First, their feedback may be over-prioritized (either due to their willingness to vocalize their desires or insistence from the business that they are the most “valuable” users). While their input is valuable, over-prioritizing it can skew product decisions toward edge-case, high-effort features that don't benefit the broader user base. This risks bloated features and added complexity for everyone else.

Second, their continued usage of the system is often taken for granted by the business. It's easy to assume that because they’ve mastered the system, they’ll remain loyal. But even legends have limits. When they hit a performance ceiling — or see better, more efficient tools emerge elsewhere — they may abandon the product in search of greater speed, flexibility, or control.

One complex-app practitioner reflected on this competitive pressure from newer, more agile tools:

A lot of other technologies have been innovative and disruptive in the last 15 years. More [companies] have been able to create their own tools and software, and it's like, ‘Wow, you can really get going and do things way faster and easier [with other tools].’

If organizations assume legend users will always stay loyal, they risk overlooking the very real need to continually improve performance and usability for this group.

How to Support Legend Users

Supporting legend users means treating them not just as vocal power users, but as valuable early indicators of system limitations and opportunities. They need continued innovation to stay engaged, and product teams need to listen with discernment, balancing their input with broader user needs.

To support legend users:

  • Don’t assume loyalty; continue to innovate and optimize
  • Conduct regular competitive audits to understand what other tools offer
  • Provide advanced features without compromising core usability
  • Invite legend users into early betas or pilot programs to test high-efficiency features
  • Recognize and celebrate their contributions, but avoid letting their preferences overrule broader design priorities

3. The Learner

The learner is new to the system but not the domain. They bring deep subject-matter expertise but limited familiarity with the system’s workflows, features, and capabilities.

We often assume that learners will simply “figure it out” through training or forced repetition. But without early support, these users may never gain the confidence or fluency needed to use the system effectively. Worse, they may develop workarounds that bypass core features, or disengage entirely due to mistrust in the system.

Learners often:

  • Learn by doing, diving into the interface without any true onboarding
  • Struggle with discovering key functions or the most efficient workflows
  • Lack confidence in whether they are using the system correctly
  • Misunderstand system capabilities or misinterpret outputs due to gaps in system knowledge

How Learners Are Marginalized

Learners are frequently dismissed with the assumption that their struggles are “training issues” — that if they just had more instruction, they’d succeed.

One practitioner summarized the prevailing attitude as:

[Leaders] oftentimes think that it's still the idea of, ‘Well, people go to school to learn how to use our stuff, so we don't really have to worry about that part of the user experience.’

But this mindset shifts the burden of usage from design to users. While training may supplement the learning process, even great training and documentation cannot compensate for poor usability or unintuitive workflows.

If learners aren’t supported during their first encounters with the system, they may never progress to true efficiency or expertise. They will remain dependent, error-prone, and at risk of churning, or worse, transition into Legacy users who never truly master the tool.

How to Support Learners

Supporting learners requires a strong focus on initial usability and progressive learning. It’s about shortening the path from initial usage to proficient usage without relying on a formal training program to bridge the gap.

Consider the following tactics to support this group:

  • Prioritize learnability in design
  • Use inline help, onboarding flows, and just-in-time tips
  • Avoid relying on dense documentation or external training programs
  • Create safe environments (e.g., sandboxes or templates) to encourage low-risk exploration
  • Provide meaningful error messages that include actionable next steps
  • Conduct longitudinal usability testing to observe learning over time

Balancing All Three User Types

Designing successful complex applications means more than choosing whether to support novice or expert users. That question presents a false dichotomy. 

In reality, sustainable product success that delivers on business goals — from long-term user retention to reduced churn and higher satisfaction — requires thoughtful support for all three user types. Each represents a different point on the user journey, and each offers critical insights for improving the system as a whole.

Each group offers unique insights:

  • Learners reveal where onboarding, discoverability, and digital content (including domain-specific language) need improvement
  • Legacies highlight which features remain unwanted, underutilized, or unnecessarily complex
  • Legends surface opportunities for deep feature use, innovation, automation, and long-term efficiency gains

These users should not be treated as static categories. A learner can become a legend — or a legacy — depending on the support they receive and the design choices made over time. Designing for just one of these groups creates long-term risk. Supporting all three builds a more resilient, effective, and loyal user base.

By , No comments:
Tags , ,

Science vs Māori Knowledge

Mike's Notes

More following on from the discussion raised in the Listener Letter. I agree with Kendall Clements. I support academic freedom and the neutrality of universities.

  • Science is the why
  • Observation is the what

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Quillette Weekly
  • Home > Handbook > 

Last Updated

06/07/2025

Science vs Māori Knowledge

By: Iona Italia
Quillette Weekly: 28/06/2025

Podcast #291

Iona Italia interviews biologist Kendall Clements about New Zealand’s efforts to equate Mātauranga Māori with science in the national curriculum. Clements argues that while traditional Māori knowledge has empirical elements, conflating it with scientific epistemology distorts both systems and undermines academic freedom.

Introduction

I’m your host this week, Iona Italia. My guest today is Kendall Clements, a professor at the University of Auckland who specialises in the ecology and evolution of fish. We talk about attempts in New Zealand to conflate Mātauranga Māori—roughly, traditional Māori knowledge—with science. Kendall explains some of the very different defining features of each of these epistemological systems and argues that conflating the two degrades both of them and is symptomatic of a misunderstanding of one or both. In our wide-ranging conversation, we discuss New Zealand universities, Māori knowledge and traditions, Karl Popper, and the way science works.

If you want to really get into the weeds about the convoluted and absurd scandal in which Kendall was involved after he co-authored a brief letter in defence of science in the Listener magazine in 2021, check out the shownotes on our website version of the podcast at quillette.com, which includes a full transcript of our conversation and some further background reading on that controversy.

Finally, please accept my profound apologies for the way I butcher the pronunciation of Māori terms.

I hope you enjoy my conversation with Kendall Clements.

more ...
By , No comments:
Tags , , ,

Next Ajabbi project will use MovieLab ontology

Mike's Notes

I'm starting to map out the shape of the next project. Please note that everything is subject to change as I learn by trial and error. :)

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subject > Film
  • Home > Handbook > 
  • Home > Learn > Docs > Film
  • Home > Wiki > Ontologies > MovieLab

Last Updated

05/07/2025

Next Ajabbi project will use MovieLab ontology

By: Mike Peters
On a Sandy Beach: 05/07/2025

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

Ontology

MovieLab has matured significantly since 2019. The ontology and schema are very easy to follow.

I will use this project to production-test Pipi by importing ontologies and automatically generating entities using these engines.

  • Ontology Engine (ont)
  • Boro Engine (bor)
  • Entity Engine (ent)

They will also receive full documentation and have UI workspaces.

Art Department

I previously worked in the art department, so I will build that part of the MovieLab schema. I could also test this on an upcoming 40-minute film, currently in pre-production, in which I'm involved.

  • Art Department
    • Hair
    • Wardrobe
    • Props
    • Sets
    • Greenery

From MoveLab

"In the Summer of 2019, MovieLabs, on behalf of its member studios, published a whitepaper called “The Evolution of Media Creation”, which laid out a bold 10-year vision for the adoption of new technologies to aid in content production, post and VFX. The paper, often referred to as the ‘2030 Vision’ has now been broadly adopted by many partner companies and is accepted as the industry ‘north star’ for guiding production technologies towards a shared goal.​

The original Evolution of Media Creation paper, available as a free download, lays out 10 Principles for a more efficient media pipeline using cloud infrastructure, zero trust security and software-defined workflows. The Principles act not just as a destination, but also a roadmap for how to get there. This roadmap drives the work of MovieLabs and those of our studios and external partners as we work together as an industry to bring the promise of the 2030 Vision forward. ​

Although the 2030 Vision is a technology roadmap it’s primary focus is in empowering the creative – to be able to achieve more – to be more efficient (replacing repetitive and menial tasks so they can focus on creative tasks), flexible (so workflows can change and adapt to new situations and technologies) and faster (so there’s more of the most precious resource – time)." - MovieLab
more ...
By , No comments:
Tags , , , , , ,

A new website for learning Java!

Mike's Notes

According to the Oracle newsletter, Inside Java - June 2025, a new website is available for beginners learning Java. The new website is helpful for both learning and as an example of how to organise a learning program. I can use this as an example of how to also do this for Pipi 9.

With the planned Pipi 10 migration to BoxLang, using Java directly will become available to the Pipi Dev community.

Here is the navigation outline;

  • Learn Java (beginners)
    • Why Java
    • Learners Corner
      • Getting Setup
      • Learn
      • Practice
      • Apply
      • Other Resources
    • Teachers Corner
      • Curriculum Map
      • Educator Briefings
      • Recruitment & Engagement
      • AP CSA
    • Java Playground
  • Developers (experienced)
    • Learn
    • Download
    • Community
    • Contribute
    • News
    • Future
    • Playground

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Inside Java
  • Home > Handbook > 

Last Updated

04/07/2025

A new website for learning Java!

By: Crystal Sheldon
Inside Java Newsletter: 28/06/2025

A new platform at Learn.java for learners, students, and teachers of Java! And we're looking for contributions!

Whereas the Dev.java platform is excellent at serving the needs of Java professionals, we've recently added Learn.java as a new platform to serve the uniquely different needs of new learners, students, and teachers of Java. It seeks to motivate, inspire, and support the Java education community.

Learn.java motivates the use of Java by answering the question: Why learn Java? This site showcases Java in real life and what it means to be a Java developer. Through learn tutorials, practice exercises, and opportunities to apply with mini-labs, the site inspires learners to engage in Java. The site includes a section dedicated to supporting teachers and curriculum providers, where they can find a curriculum map with lesson plans, an educator briefing on the latest Java updates, and a section dedicated to the needs of AP Computer Science A teachers.

Do you want to contribute and support students and teachers? Please contact me. We are looking for contributors to share their unique stories as Java professionals. Students struggle to understand what it means to be a part of a computer science related field. Your story can inspire them and help them understand the ways Java is used to solve the problems important to them. We hope you will work with us to share your story to help motivate future generations.

Crystal Sheldon

Director, Java in Education, Java Developer Relations

By , No comments:
Tags ,

The 2025 DORA survey is open now

Mike's Notes

Note

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > IT Revolution
  • Home > Handbook > 

Last Updated

03/07/2025

The 2025 DORA survey is open now

By: 
DORA: Copied 03/07/2025

The DORA research program is dedicated to helping technology teams get better at getting better. That journey often starts with a moment of reflection.

We invite you to take 10 minutes for that reflection with the 2025 DORA Survey. Participants often tell us the survey itself is a valuable self-assessment, sparking immediate ideas for how their team can improve.

Your anonymous contribution will also power the industry’s most trusted research on software delivery performance. This year, we’re exploring crucial topics like AI integration, platform engineering, and developer well-being.

By participating, you:

  • Discover potential improvements for your team just by taking the survey.
  • Shape the industry’s understanding of what defines elite performance in 2025.
  • Help create the benchmark you and your peers will use to drive change.

This research is strongest when it includes diverse perspectives. Whether you’re a Software Engineer, Data Scientist, Product Manager, QA Developer, or anyone else who participates in the creation and delivery of software your voice is critical.

Thank you for helping us all get better at getting better.

Consider holding a team discussion about the survey using our discussion guide.

By , No comments:
Tags , ,

David Deutsch - What is Truth?

Mike's Notes

This video interview came in the latest issue of Aeon.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Aeon
  • Home > Ajabbi Research > Library > Subscriptions > Closer to Truth
  • Home > Handbook > Ajabbi Research > Culture

Last Updated

02/07/2025

David Deutsch - What is Truth?
By: Lawrence Kuhn
Closer to Truth: 18/10/2016

David Elieser Deutsch, FRS is a British physicist at the University of Oxford. He is a Visiting Professor in the Department of Atomic and Laser Physics at the Centre for Quantum Computation (CQC) in the Clarendon Laboratory of the University of Oxford.

Deutsch pioneered the field of quantum computation by formulating a description for a quantum Turing machine, as well as specifying an algorithm designed to run on a quantum computer. He is a proponent of the many-worlds interpretation of quantum mechanics.

He was awarded the Dirac Medal and Prize of the International Centre for Theoretical Physics in 2017, the Isaac Newton Medal and Prize of the Institute of Physics in 2021, and the Breakthrough Prize in Fundamental Physics in 2022. His popular books The Fabric of Reality and The Beginning of Infinity have each been translated into 12 languages.

Why David Deutsch believes good explanations are the antidote to bad philosophy

In this interview from the long-running series Closer to Truth, the British theoretical physicist and philosopher David Deutsch makes the case that understanding the difference between good and bad explanations is central to advancing knowledge. In conversation with the US presenter Robert Lawrence Kuhn, Deutsch outlines what he believes makes for a convincing explanation – primarily, unprejudiced thinking, relevance and specificity. Further, he argues that this framework for explanations is a vital corrective to a century in which what he calls ‘bad philosophy’, including logical positivism, has dominated, constraining the search for good ideas.

By , No comments:
Tags , , ,

Thinking about the next steps ahead

Mike's Notes

I had the regular meeting on Sunday night, which helped bounce ideas around. I would like to know what people think of what I have written. Just contact me for a chat.

Resources

References

  • Reference

Repository

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

Last Updated

09/07/2025

Thinking about the next steps ahead

By: Mike Peters
On a Sandy Beach: 01/07/2025

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

Ajabbi uses Pipi 9 to run on, known as "dogfooding". Steady progress is being made with Pipi 9, and the first customer website, which is now well underway.

The customer's website required several reusable modules and utilises these engines and more.

  • Website Engine
  • Reference Engine
  • i18n Engine
  • Reference Engine

Documentation of these modules and engines is now required for developers and administrators.

Next Project

It was now time to determine a plan for the next project.

There are three options;

  • Finish the developer documentation
  • Complete the user workspace roadmap
  • Build a simple SaaS application

I will go into some detail about each option.

Finish the developer documentation.

No developer will be able to build anything with Pipi unless they have some documentation on how it works. 5% is documented.

Complete the user workspace roadmap.

This will enable users to log in and use the available features, but they will still require instructions in the form of documentation.

Build a simple SaaS application.

The Movie Industry SaaS application is straightforward and utilises a compact ontology. Its ontology is over 1,000 times smaller than SNOMED, so it's an easy place to start. It would be a way to test the Ontology API and Boro engines. It builds some more reusable modules. It also provides a helpful tool that people can use for their work.

This would generate more learning opportunities for me, as I do this work by the seat of my pants.

Discussion

The advantage of building a simple SaaS application is that it requires a user workspace and some relevant documentation. 

Being product-led, would only schedule work on any necessary background systems and documentation. It also makes things more manageable as Pipi slowly scales.

Over time, more modules will be completed, more engines will be documented, and the user workspace will expand.

Show and tell

Embedding short YouTube video recordings demonstrating workspace usage could be incorporated into training and contextual help documentation.

A longer, prerecorded technical demonstration video, accompanied by slides and a PDF white paper, could then be shared with the Ontolog Forum to solicit critical feedback. I suspect they would be curious about a novel use of Ontology technology as part of constraints in State Space.

By , No comments:
Tags , , , , ,
Subscribe to: Posts (Atom)