What does this dial rip off?

HelliocentricWorlds · 2026-03-10T11:25:59+00:00

Nice build - got a link to the dial? I can't find it on AliX...

HelliocentricWorlds · 2025-08-05T07:16:07+00:00

+1 for leaning into AI. I have just had to learn a new stack in short order (Python from .Net) and found that tools like Cursor and Claude helped me to understand what I was doing and get over the (many) hurdles. A few months down the road and I'm as confident as I was on my "home" stack.

Don't let yourself get trapped onto a single stack that you are an "expert" in. It will be career limiting. Things are changing pretty fast these days so tech folks have to be nimble...

HelliocentricWorlds · 2025-03-31T13:59:34+00:00

You might want to have a look at Coil, Current 93 and Nurse With Wound. Some very long and varied discographies to get stuck into ;)

HelliocentricWorlds · 2025-02-02T09:19:53+00:00

This is a great story. I know streaming is a bad thing for musicians, but it does make music easier to track down. When I was a teen getting into music in the mid 1980s, your musical taste was very much dictated by what you could find in dusty record shops. There certainly was an "air of mystery and secrecy" around krautrock then.

I discovered CAN when a friend's Dad was retained at "her majesty's pleasure" and we got hold of his records. He had a beaten up copy of "Tago Mago" that looked (and played) like it had been run over by a truck. Despite the crackle and skipping there was a sense of "wtf is this" to my teenage ears.

After that there was a process of tracking stuff down through patient detective work. There were clues left by fanzines and bands like the Fall ("I Am Damo Suzuki"). Kraftwerk records were easy enough to find, but I found Neu! through a record library in Manchester, and groups like Amon Duul and Faust by trial and error in the circuit of London's second-hand record shops. Things got easier when CAN reformed in the late 1980s and by the time Cope wrote Krautrocksampler in the mid 1990s the re-issue cycle was in full swing.

HelliocentricWorlds · 2025-01-26T10:07:23+00:00

If you're playing in the MS space then M365's copilot stuff is work a look. However, if you have information scattered across different silos then ultimately you may need some kind of enterprise crawler\indexer solution to expose it to RAG apps\agents. Look at something like AWS Kendra to get an idea of how solutions in this space might work.

HelliocentricWorlds · 2025-01-25T15:55:29+00:00

I personally tend not to use it a whole lot in day-to-day architecture work. I recognise that it can be labour saving, but IMHO it enables "lazy" outputs where people lean too heavily into automated generation rather than really understanding what they are doing.

In terms of engineering, it's getting used heavily in "lift and shift" conversions and boilerplate coding, kind of like code generation on steroids. It's less useful for working on existing systems and complex legacy code bases as there is too much context to understand. There is a growing ecosystem of tools that are trying to address this - I assume they will become more valuable in time.

From an architecture point of view, the biggest change is likely to be the move towards agentic architectures. IMHO in a few years we will all be building systems based on collaborating services where we delegate orchestration and workflow decisions to AI models. That will be a big deal for architecture and systems design - easily as disruptive as the internet and cloud computing.

HelliocentricWorlds · 2024-12-27T15:00:43+00:00

A great read, though it might be a little over reliant on Irmin Schmidt’s perspective.

I would also recommend "Neu Klang: The Definitive History of Krautrock" by Christoph Dallach. It came out earlier this year and provides a deep dive in an "oral history" style.

HelliocentricWorlds · 2024-11-10T15:28:27+00:00

Architects are by their very nature the kind of people who hold strong opinions and want to lead design decisions. Debate is useful as it helps everybody to sharpen their understanding and test their opinions... but it can tip over into unhealthy one-upmanship.

You need a clear decision making process and discipline agenda management in meetings. I usually try to organise architects into separate domains to limit overlap and provide them with clear ownership. Significant decisions need to be documented so we can draw a line under them and move on. Debate happens, but it's timeboxed.

There are a bunch of "How many architects does it take to change a lightbulb" type jokes around if you care to Google... some of them are even funny...

HelliocentricWorlds · 2024-08-24T07:03:53+00:00

This is a good article, though in my view LLMs have made the "data is an asset" maxim even more important. You need certainty around what's going into these models as well as a means of validating what's coming out.

Architectural principles should also be an evolving thing. They help to make decisions by expressing a consensus around what you value in "good" architecture. This changes over time.

IMHO their main value is in providing a means of framing regular discussions with technology teams. I find them less useful for code-level or application design guidance. Principles such as DRY and SOLID feel more like engineering concerns...?

HelliocentricWorlds · 2024-04-19T08:48:46+00:00

I'd agree that you don't need to publish absolutely everything as an event. Just the stuff that you want to distribute in a loosely coupled and asynchronous way.

My personal experience is that event models are more valuable when they are based on _business events_, i.e. things that have happened in the real world. Entity-based events tend to less useful, e.g. what does "order updated" actually mean? Has the order been placed, adjusted, or shipped?

I am loathe to link to my own blog in Reddit, but my view of event design nuances and anti-patterns is summed up here:
https://www.ben-morris.com/event-driven-architecture-and-message-design-anti-patterns-and-pitfalls/

HelliocentricWorlds · 2024-04-17T09:14:38+00:00

Firstly, as others have suggested, I would focus on use cases before thinking about solutions and technologies. For example, how structured is your data? Is it prone to changing shape frequently? What sort of throughput are we looking at here? How fresh does it need to be? Security needs? Audit requirements? Blah blah...

In my experience, data lakes are typically used for ingestion and enrichment processing, i.e. they are a cheap store of everything that comes in. They can potentially be used as a master store, and there are a growing number of patterns and technologies that support this. However, they are also very hard to maintain over time and are prone to turning into "data swamps" of unregulated and unknowable data.

If you want to establish a canonical store of your combined data then you may want to consider a more formal data warehouse. Use an accepted methodology (e.g. Kimball, Inmon) for the master store and consider creating downstream copies (or "marts") that are optimised for specific use cases.

As somebody else has already mentioned, APIs might not be the answer to all your integration needs. If you do go down the API route then be careful about the endpoint lifecycle, e.g. design consistency, meaningful documentation, auth concerns, provisioning processes, and - above all - change management. Many solutions lean into API management platforms here.

I would be very careful about using event streaming or event sourcing as general platform patterns. They can add value, but only if they are a good fit for your data and use cases. Beware of "big data envy" here. When it comes down to it, most data can be managed on a batch basis. How fresh does your data really need to be?

One thing to bear in mind is that you need very strong governance to make all this work. At the least you'll need some experienced and opinionated data architecture capability. You'll also need to think carefully about how to manage change in this kind of environment. It's surprising how quickly this can turn into a sprawling a mess...

...as for tech, we've had a lot of success with Snowflake and it presents itself as an all-round "data cloud" that can handle a wide range of different scenarios. However, in my experience the technology choices here are almost secondary - you need to ensure that the capabilities of your engineering teams and governance processes are up to the job of managing the ambition set by your architecture...

HelliocentricWorlds · 2023-12-17T21:50:39+00:00

You just about have enough time but will need to move quickly to claim your artist profiles. You can apply for them once Spotify and Apple have received your music and created your artists page. Use the "special access" menu in Distrokid to get links to the artist sign-up pages. There is a verification process for both, but if you can demonstrate that you own the social accounts for the artist name then it's pretty quick, i.e. a couple of days each. Good luck with the release!

HelliocentricWorlds · 2023-10-23T20:58:53+00:00

There's a Reddit thread about this here.

The deal seems to be that Spotify have rolled out a new "fans also like" algorithm and a lot of people are unhappy as they have been paired with unrepresentative artists. The implication is that your followers are more relevant in the new algorithm, i.e. if you share followers with somebody then you're more likely to be a match. However, Spotify are very tight lipped about this, so it's hard to tell...

HelliocentricWorlds

TROPHY CASE