phil-martin

Maybe it’s not a developer at all, and a couple of open claws doing random app things…

I believe the article is written from a lisp point of view where it interactivity is inspecting and modifying the application itself while it is running. It’s assuming that the software has already been written with no existing concurrency issues, but when a person comes along and does something unexpected and rewrites pose of the application or in the example they gave, modifying a hash map, things break.

They used C as an example because under normal circumstances you compile a binary and don’t modify it at runtime.

I’m not doing to defend it to strongly though, I _think_ that is what they were getting at, but to be honest I found much of it confusing.

It is just zipped xml, but to do a search and replace while retaining document structure is very very complicated, and I’m struggling to think of how to combine sed and awk to achieve it.

I'm confused - it feels like orchestration tools or how to organise agents is one of the most frequently discussed topics?

When I posted this comment there were 4 posts on the front page about orchestration, and another 3 on the second page.

I think this is an excellent start!

I have a few questions/comments.

- the site said it would be worked on collaboratively, but I couldn't find a way to do that? I interpreted that to mean multiple people woroking on it together

- I would find this more valuable if it was less text editor and more interactive editor. If the goal is group consesus, expanding the tool so more people in the group could modify it would be good

- What is the reason for having default names like "SprintReady" instead of "Sprint ready" ?

- Zoom to all and zoom to selected wold be super useful in the flowchart view

- being able to rename/edit things in teh flowchart view would be great

- Having an AI embedded in the tool itself so you did't have to manually round trip and copy/paste with claude code would be super useful

- It might be worth trying moving the comments panel to the right hand side of the screen. Very similar to google docs, word and other document tools. Makes the visual chart front-and-center and makes the comments separate from the simulate step

It’s interesting eh, it’s a wonderfully straightforward tool to use, but it’s scary.

My theory is that those courses aren’t selling you on how to use obsidian, but are instead selling “how do I organise knowledge and information. Oh btw we’re using obsidian”

They aren’t marketed like that, but I think that is what they’re really doing

It’s like taking a course of office organisation. I mean filing cabinets are easy right, it’s just putting labels on folders and putting them places.

Except I would absolutely be terrible at that job and would pay nearly anything to be good at it.

I found all the themes interesting, but "the rigor has to go somewhere" and "the enterprise reality check" resonated.

I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.

When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.

Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)

If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.

Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.

One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.

It's nape-js

https://newkrok.github.io/nape-js/index.html

While the gummy geometry one is a little twitchy, but most all the other demos were very stable, much more than most other 2d solvers I've seen.

All true, but also depends on jurisdiction the product is operating in

For example, in Australia any consumer has rights around products and services they purchased regardless of the terms agreed to during sale. If a business offered 99% uptime in their marketing, then they are required to provide that or, something equivalent, or a refund, even if it was never mentioned or some lower number was mentioned in the terms and conditions.

Enforcing that however, particularly with companies that are renowned for having no human staff, is tricky.

So yes, definitely agree - builders have to be aware of their dependencies and work with the realities of what they provide, not the theoretical

So what would you estimate is the real amount of time?

I’m confused - is it the actual source code, or minified/bundled code? I don’t think those two are the same thing - unless of course you write your code minified. That would be really impressive.

One of the things I miss most about the Amiga workbench is variable size icons.

I love them, and miss them

That giant battletech icon before you play that fantastic turn based hexagonal game, or the Amos basic icon, there was just so much opportunity for fun.

Ever since then I occasionally try and make it happen on vanilla OS’s, without success.

Them I just realised I’ve been a dev forever, and various desktop environments on Linux have been open forever, it might be time for me to try one last time. It may never take off, but I would love to see it :D

https://www.sarna.net/news/mechcombat-from-ralph-h-reed/amp/

Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?

Accounts (in the accounting sense) are unitless, and refer to whatever meaning we ascribe to them, so we can transfer value from $ to shares, or USD to GBP or whatever.

Lalit describes this I think really well in his article

https://lalitm.com/post/one-number-i-trust/#chapter-4-invest...

I love that, thank you for sharing.

Would you consider a follow up blog post about how you structure and approach your monthly finance sessions? I understand that it would be well outside of your topics of software engineering, performance and open-source, but I find that the human component of our industry is often missing. An insight into how someone has successfully navigated that would be a wonderful read.

I guess it depends on the complexity of ones personal finances? The author had multiple currencies, investments, and who knows what else.

I ran a small business for a while, and I would draw a parallel to that. Once a family's finances hits the complexities of a small business, multiple assets, loans, cars, long term savings, investments, I'd say the granularity is worth it. I would certainly like to try it out.

Thank you for taking the time to reply - thank you!

I have question on a more personal front - please feel no obligation to reply.

What impact has having such clear visibility into your accounts had on your relationship with your wife? It feels like it would be a great catalyst for communication, trust and building things if shared finances was a key part of the relationship.

I think this part was the most inspirational - it takes a lot of courage to be that open about finances, even with partners, perhaps especially with partners.

I must have read half a dozen intro-to-accounting books, and it never ever clicked for me. I understood the concepts, the benefits, but it just felt 'wrong'.

It wasn't wrong of course, there is so much history, ingenuity and the invention of double entry accounting, but I just couldn't get my brain to understand it.

The way the concepts settled in my head was: double entry accounting is just an excellent way of modelling a graph with nodes and edges. Accounts are nodes, transfers are edges. Every edge has a source and a destination.

For a paper ledger, each column is graph node, and each row is a graph edge.

That was enough for me to be able to learn the rest of the things I needed for interacting with the accounting world.

But I also realised that that description really only helps a very small part of the population. :D It makes things so much worse for most people.

"Hey could you help me understanding this accounting thing?"

"Sure, but first thing is, let's learn graph theory! You know who Dijkstra right?"

Whole buckets of nope.

But thats a digression from your actual question - whats the point?

It presents a rigid set of rules of recording transfers, everything has to have a from account and to account (i.e. a graph edge), every row must add up to zero.

Because of that, it makes it easy to spot any mistakes in data entry. If any of your rows dont add up to zero - then you've made a mistake.

I really enjoyed reading this, and it is inspirational as it is something I have wanted to do for a long time. And as a software developer, it really appeals to me.

How do you think it compares time-wise to using existing accounting software? Was the time investment worth it to get the control and visibility you now have?

The main one I could think of was maximising 3D printer utilisation, I.e if filling your print volume was something you wanted to optimise for.

Sure is - Windows Server Core

https://learn.microsoft.com/en-us/windows-server/get-started...

i had a read through but I couldn't figure this out: What does it improve on compared to jsut regularly doing a git pull and git push to a different origin?

Also, can the destination be something other than GitLab?

That is a really interesting investigation, but I am curious - how did the author go about evaluating whether or not was following a process? How did they measure success / failure ?

But a fascinating experiment and something I’ll try with Codex

I was reading through the article genuinely looking forward to a methodical discussion on all the negative points raised about other protocols

For example this was about one of the other protocols

“ There is no key rotation that preserves your social connections. You would need to create an entirely new identity.”

It didn’t elaborate much, but briefly mention Marmot, but I thought it was about Nostr? It was confusing enough for me to shrug and move on. Which is a shame, because it feels like it might be important to understand.

It started waaaaay before backend server-rendered pages

https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93con...

"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."

With numbers like, if it scares customers a good strategy is to implement the filtering very gradually over time, over 6 months or a year. The fall off is way less scary, and it can be described as improving bot filtering.

It’s not as honest, but more palatable unfortunately

The article was fascinating, but the part I didn't see was... what was the motive? Assuming the article paints an accurate picture of what was going on... why was it going on? Is it solely because he runs a company in the same competitive space?

I think this is a potential building block for transforming how MSP organisations manage documentation and workflow.

Despite the goal of homogenizing each clients environment to simplify support, there will always be uniqueness amongst them. Having documentation that can be collaboratively edited, versioned, that is also runnable to perform management tasks would be a HUGE deal.

I understand this isn't the target audience, but its exciting to imagine the possibilities of other uses.

The major issue was the trajectory of impact, particularly when the ClickUp access was attained. If the person doing it was malicious, participating on that platform could have quickly led to some social engineering that led to accessing private business critical intellectual property, staff names, contact information, and accessing more systems.””

Definitely not a nothing burger.

Which makes it ill-suited when you need multiple canvases. Pixijs is amazing, and I mix Pixi, Fabric and regular canvases in my application.