Once I had decided that the website should have user accounts, I had to answer a fairly important question. Where should authentication live? The obvious answer, if I was thinking about the individual applications, would have been to put it in each application. After all, an application needs to know whether someone is logged in. But that immediately brought me back to the problem that had started the whole framework project in the first place. Duplication. If Publications had its own authentication system, and Marketplace had another, and another application had another, I would once again have several versions of essentially the same functionality. That wasn't what I wanted. If a user account belonged to the website rather than to an individual application, then authentication needed to belong to the platform as well. That was an important distinction. The applications shouldn't each have to work out how to authenticate a user. They should simply be able to ...

When I started building the Auspice Darer Framework, I wasn't trying to create a framework. I was trying to solve problems as they appeared. The original problem was duplication. I had a number of PHP applications, and each one had developed its own header, footer, navigation and supporting code. Making a change to one application was easy enough. Making the same change consistently across all of them was where the time went. So the first stage was fairly straightforward. I began bringing the applications together under a common structure, sharing things that didn't need to be independently maintained. That was already making life easier. Then, at some point, I had another idea. Why not have user accounts? It sounds like a fairly ordinary feature. Most websites have them. But in the context of what I was building, it changed the nature of the project. Until then, the applications could largely be thought of as separate programs that happened to live on the sam...

One of the biggest lessons I learned while working with AI wasn't about prompting. It wasn't about context windows. It wasn't about choosing the right model. It was about recognising when neither the AI nor I were solving the right problem. Software development has a habit of encouraging incremental fixes. A bug appears. You fix it. Another edge case appears. You patch that too. Eventually the code works—but it becomes increasingly difficult to understand why. AI can unintentionally reinforce this pattern. If you ask it to solve today's problem, it will usually do exactly that. If another problem appears tomorrow, it will solve that one too. Before long you've accumulated a series of perfectly reasonable fixes that, taken together, have become an increasingly awkward design. I saw this happen more than once while building the Auspice Darer Framework. We would spend time refining an approach, improving it a little with each iteration, only to realise that the underly...

One of the biggest misconceptions about AI-assisted software development is that the AI is somehow "in charge" of the project. It isn't. No matter how capable AI becomes, the responsibility for the overall architecture still belongs to the human developer. I learned this repeatedly while building the Auspice Darer Framework. Most of the time, the AI produced excellent ideas, spotted bugs I had overlooked and suggested cleaner implementations than I might have written myself. But occasionally it would head in the wrong direction. Sometimes it would forget an important design decision we'd made earlier. Sometimes it would suggest a solution that ignored one of the framework's architectural principles. Sometimes it would continue reasoning from an assumption that was no longer true. When that happened, I discovered something important. The AI doesn't know it's gone wrong. It simply continues reasoning from the information it believes to be correct. That's...

One of the first habits I had to change when working with AI on software projects was how I shared my code. Initially, I'd upload one file, ask a question and wait for the AI to request the next file. Then another. Then another. If you've ever done this with a large application, you'll know how quickly it becomes a game of "Can I see the next file?" The problem isn't that the AI is asking the wrong questions. The problem is that it can only reason about the information it has available. If the bug appears in a controller but is actually caused by a service, configuration file or bootstrap process, the AI has no way of knowing that until it sees those files as well. Before long, you've spent more time uploading files than discussing the solution. Eventually I started taking a different approach. Whenever I was working on something that involved architecture, debugging or major refactoring, I'd simply upload a ZIP archive of the entire project. That chan...

When people first start using AI for software development, they often treat it like a search engine. They open a single conversation and keep asking every question in the same place. I started that way too. For small projects, it works perfectly well. Large software projects are different. As my work on the Auspice Darer Framework grew, I realised that one conversation was trying to cover too many different topics at once. One moment I was discussing dependency injection, the next I was redesigning CSS, then debugging routing, before switching to documentation or database design. The conversation became cluttered, and the AI had to continually switch context. Eventually I tried something different. Instead of one conversation, I created a project and gave different chats different responsibilities. One chat focused entirely on framework architecture. Another concentrated on CSS and presentation. Others were dedicated to individual applications, documentation, testing or specific migrat...

When people hear the word architecture , they often imagine something complicated. Layers. Patterns. Dependency injection. Service containers. Routing. They're all useful tools, but they're not the reason architecture exists. For me, architecture serves a much simpler purpose. It makes change inexpensive. That lesson wasn't something I learned from a book. It was something I discovered by maintaining an increasing number of applications. Every time I found myself making the same change in multiple places, I asked the same question. "Why isn't there just one place to change this?" Over time those questions shaped the Auspice Darer Framework. There became one shared configuration. One common layout. One routing system. One authentication service. One way of rendering pages. One location for reusable components. Instead of every application deciding how to solve these problems, they all relied on the same shared platform. The result wasn't simply less code. I...

By this point I knew what the problem was. Every new application meant another copy of the same infrastructure. Every improvement meant updating multiple projects. The duplication wasn't making development difficult—it was making maintenance expensive. My first instinct wasn't to build a framework. It was simply to stop copying code. The obvious place to start was with the parts that almost never differed between applications. The website header. The footer. The navigation. Instead of maintaining separate copies, I began sharing them between applications. Suddenly a change to the site's appearance only needed to be made once. That small change had a surprisingly large effect. The more code I shared, the more I realised that the same principle applied elsewhere. Configuration files didn't need to exist in every project. Common helper functions didn't need to be duplicated. Authentication didn't need to be rewritten. Database access could be standardised. Even the...

When I first started writing my own PHP applications, every project was self-contained. That seemed like a sensible approach. Each application lived in its own directory, had its own configuration files, its own navigation, its own page layout and its own collection of helper functions. There were no dependencies between projects, and that meant I could develop each one independently. For a while, that worked perfectly. The problem wasn't building new applications. The problem was changing existing ones. Imagine deciding that your website header needs redesigning. Perhaps you want to add a search box, change the navigation or update your branding. With a single application, that's a straightforward task. With ten independent applications, it becomes ten separate tasks. Every header had to be updated. Every footer had to be updated. Every navigation menu had to be updated. Every configuration change had to be copied into every project. Every bug fix had to be repeated. None of t...

For many years, my website was powered by WordPress. Like millions of other people, I appreciated how quickly it allowed me to publish content without having to build everything from scratch. However, over time my website evolved beyond a simple blog. I found myself wanting applications that WordPress wasn't really designed to provide. Some projects needed custom databases, others required specialised interfaces or unique workflows that didn't fit naturally into the WordPress ecosystem. While plug-ins could sometimes fill the gap, they often introduced complexity and compromises that felt increasingly uncomfortable. Eventually I decided that, for these applications at least, it would be simpler to build them myself. At first there was no grand architectural vision. Each application was a completely independent PHP project. Every one had its own directory structure, its own configuration, its own navigation and its own way of doing things. That wasn't a deliberate design dec...

Artificial intelligence has become one of those subjects that is difficult to discuss without encountering either exaggerated enthusiasm or outright hostility. Depending on which article you read, AI is either about to replace entire professions or is little more than an overhyped autocomplete system. After spending several months using AI to help build the Jersey News Aggregator, the wider Auspice Darer publishing platform, and various supporting tools, my own view is somewhat different. I have come to regard AI as something closer to a very advanced programming language. That may sound like an unusual comparison, but it helps explain both its strengths and its limitations. Programming Through Abstraction The history of computing is largely the history of abstraction. Early programmers worked directly with machine code. Later they used assembly language. Then came higher-level languages such as C, Pascal, PHP and Python. Frameworks and libraries followed, allowing developers to expres...

When I first built the Jersey News Aggregator and the wider Auspice Darer website project, I concentrated on functionality. The site could collect news, display articles, search archives and present information exactly as intended. What it could not do was explain itself very well to search engines. That changed when I began setting up Google Search Console and Google Analytics. One of the first recommendations was to submit an XML sitemap. At first glance, an XML sitemap appears to be little more than a list of pages. In reality, it serves as a roadmap for search engines, helping them discover content that might otherwise take longer to find. What Is an XML Sitemap? An XML sitemap is a machine-readable file that lists the pages available on a website. A typical sitemap entry looks something like this: <url> <loc>https://www.example.com/about.php</loc> <lastmod>2026-05-01</lastmod> </url> The sitemap tells search engines: Which pages exist Wh...

After creating an XML sitemap for the Jersey News Aggregator and wider Auspice Darer website project, the next step was understanding another file that search engines pay close attention to: robots.txt. While a sitemap helps search engines discover content, robots.txt helps control what they should and should not crawl. Both files work together, and both play an important role in how a website is indexed. What Is robots.txt? A robots.txt file is a simple text file placed in the root directory of a website. For example: https://www.example.com/robots.txt When a search engine visits a website, one of the first files it requests is robots.txt. The file contains instructions that tell search engine crawlers which parts of the site are available for crawling and which areas should be ignored. A basic robots.txt file might look like this: User-agent: * Allow: / Disallow: /admin/ Sitemap: https://www.example.com/sitemap.xml In plain English this means: All search engines are allowed to cra...

You’ll usually want to connect three Google services to your Blogspot blog: Google Analytics 4 (GA4) — visitor statistics Google Search Console — search indexing & SEO monitoring Google AdSense (optional later) — monetisation For now, here’s the clean setup process for Analytics and Search Console. 1. Create Google Analytics (GA4) Go to: https://analytics.google.com/ Steps A. Create an Account Click Start measuring Account name example: Auspice Darer Leave sharing settings enabled unless you want stricter privacy B. Create a Property Property name example: Auspice Darer Blog Choose your local timezone Select your currency (GBP if in Jersey/UK) Click Next C. Business Details Choose an industry category such as: Arts & Entertainment Books & Literature Games Other Select your business size D. Choose Objectives Examine user behaviour Measure enga...

Buoyed by the experience of writing custom HTML gadgets, the idea to take on a bigger project and develop www.dariuspearce.com into something other than a vanity e-mail address drove me to give it a go. There is something deeply satisfying about discovering that the internet is not nearly as mysterious as the technology industry would often like people to believe. IT, much like law, is fundamentally a very simple process hidden behind layers of jargon and technicality designed to make the uninitiated reach deep into their pocket to have someone else take care of it. Once you realise that, a great many things suddenly stop feeling impossible. Now admittedly, I am not coming to this as a complete novice. Quite by coincidence, this very week I happened to bump into my old computer science teacher and we reminisced about the old days. Back then computer science teachers were often mathematics teachers first, because computing itself is fundamentally built upon mathematics and logic....

Building a Jersey News Aggregator for Blogger Using RSS Feeds I recently decided to experiment with building a live Jersey news aggregator directly inside Blogger using nothing more than custom HTML, CSS and JavaScript. The idea was simple: Get Jersey news from multiple local sources in one place — without constantly jumping between websites filled with adverts, popups and distractions. What began as a relatively simple RSS experiment gradually evolved into something much more sophisticated: live RSS aggregation responsive news cards dark mode search filtering headline ticker automatic sorting source filtering article thumbnails auto refresh fallback default images Today.je source extraction duplicate story filtering mobile responsive design curated feed selection Important Blogger Limitation One important thing I discovered during testing is that this works far more reliably inside: a dedicated Blogger page or a full blog post rather than ...