Latest Posts (20 found)
A Token of My Extreme Today

New in Barium & ChessLab, 2026/Q1

In the tradition of “shut up and write the code” there have been no recent updates on what I’ve been up to. However, the pile of finished stuff is now high enough to call it a milestone or two, so I finally got down to compile a summary for those of you wishing to follow along.

open-source Open Source programming Programming
0 views
neilzone Yesterday

Moving my static site blog generator from hugo to BSSG

I enjoy blogging. I blog on my own personal site (this blog), and I also have a blog for my work site, decoded.legal . In 2023, I moved my blog to a static site generated by hugo . I've been reasonably pleased with hugo, and it does the job, but I find it complex. In short, if an update broke my site, I am not 100% convinced that I would be able to fix it. I don't need much in the way of complexity; I have a simple, predominantly text, blog, and all I want is to be able to write posts in markdown, generate a static html site from it, andrsync it to a webserver, along with an RSS feed. I am using a Raspberry Pi 4 as my webserver, and this works fine, given my lightweight, low complexity, sites. On the fediverse, I saw Stefano Marinelli discussing his own static site generator - the Bash Static Site Generator, also called "BSSG" - and I was keen to give it a try. I guess that I am simply more confident that, if there was a problem, I'd be more confident about fixing something written in bash. I am running hugo (and now BSSG) on my Raspberry Pi 4 webserver. I could install it on something beefier, like my laptop, and then just rsync the output files to the webserver, but, again for simplicity, it makes sense to me to run the static site generator on the webserver itself. I don't have anything particular to note about the basic installation. I wanted to make quite a few changes to the default configuration, so I decided that the simplest thing to do was to copy the whole config file from the BSSG installation directory into my site directory, and then amend it. Here is my configuration file . (I have a separate file, in the same directory, for my .onion site; this is much the same, but referencing the .onion URL instead, and with a separate output directory.) I was happy with how my old blog looked, and, for the work blog, I wanted it to remain consistent with the main website. I started with the BSSG "minimal" theme, and then made the changes that I wanted to support "dark mode", remove transitions/transformations, and to generally get to the look that I wanted. Here is the resulting css . Once can also have site-specific templates, so I copied the templates directory from the BSSG directory into my site directory, and made changes there. In particular, in the header template, I: Here is the header file . In the footer, I amended the copyright information, and, on the work blog, added a short disclaimer. ( My footer .) There is a significant (but not total) overlap between the header material of blogposts for hugo and blogposts for BSSG. I'm not entirely sure that I needed to do anything at all, aside from copying the raw markdown files into BSSG's directory, but I used a few regexes to align the header material anyway: (Yes, there might be shorter / cleaner / faster etc. ways of doing this. This worked for me.) I also found - thanks to an error message when I first tried to build the BSSG content - that BSSG does not like src files with spaces in the names. I did not have many (although one was enough), so I fixed that: One thing that I did not do with hugo is have descriptions for my posts. I think that I'd prefer not to have descriptions displayed at all, but I've yet to find a way to suppress them in BSSG without editing the underlying scripts, which (for ease of updating), I am loathe to do. I am not using BSSG's editing tool, or its command line tools for adding new posts (although I might need to use it for deleting posts). Instead, I prefer to write markdown in vim, and then upload that to the webserver and then build the site. I have a small shell script on my laptop and phone, which generates a text file (with a .md extension) with the correct header material, and it pre-populates the date and time in the correct format. I then have a separate script which I use to push the new blogpost to the webserver, and then, via ssh, runs a script in the relevant BSSG site directory to build the site and rsync it into place. Here is that build script . (Although "build script" makes it sound fancier than it is.) It is early days, so these are little more than my immediate notes. I'd like to find a way to remove the descriptions from the index page. But, other than that, I am very happy with BSSG, and I am very grateful to Stefano for making it available. Building this blog on a Raspberry Pi 4, even using the (newly-fixed; thanks, Stefano!) "ram" mode, is not exactly rapid, but that is not a particular concern for me. I am very pleased. And, if you can read this - my first new blogpost since adopting BSSG - then everything is going well :) added an inline svg for the icon, in lieu of a favicon file added a link for fediverse verification ( ) added a link for "fediverse:creator", so that post previews in Mastodon link to my Mastodon account ( ) adjusted some of the OpenGraph (fedi previews) stuff, to use a static image, since I do not use header images (or, really, any images at all)

html HTML Bash css CSS web-development Web Development
0 views
Simon Willison Yesterday

My fireside chat about agentic engineering at the Pragmatic Summit

I was a speaker last month at the Pragmatic Summit in San Francisco, where I participated in a fireside chat session about Agentic Engineering hosted by Eric Lui from Statsig. The video is available on YouTube . Here are my highlights from the conversation. We started by talking about the different phases a software developer goes through in adopting AI coding tools. I feel like there are different stages of AI adoption as a programmer. You start off with you've got ChatGPT and you ask it questions and occasionally it helps you out. And then the big step is when you move to the coding agents that are writing code for you—initially writing bits of code and then there's that moment where the agent writes more code than you do, which is a big moment. And that for me happened only about maybe six months ago. The new thing as of what, three weeks ago, is you don't read the code. If anyone saw StrongDM—they had a big thing come out last week where they talked about their software factory and their two principles were nobody writes any code, nobody reads any code, which is clear insanity. That is wildly irresponsible. They're a security company building security software, which is why it's worth paying close attention—like how could this possibly be working? I talked about StrongDM more in How StrongDM's AI team build serious software without even looking at the code . We discussed the challenge of knowing when to trust the AI's output as opposed to reviewing every line with a fine tooth-comb. The way I've become a little bit more comfortable with it is thinking about how when I worked at a big company, other teams would build services for us and we would read their documentation, use their service, and we wouldn't go and look at their code. If it broke, we'd dive in and see what the bug was in the code. But you generally trust those teams of professionals to produce stuff that works. Trusting an AI in the same way feels very uncomfortable. I think Opus 4.5 was the first one that earned my trust—I'm very confident now that for classes of problems that I've seen it tackle before, it's not going to do anything stupid. If I ask it to build a JSON API that hits this database and returns the data and paginates it, it's just going to do it and I'm going to get the right thing back. Every single coding session I start with an agent, I start by saying here's how to run the test—it's normally is my current test framework. So I say run the test and then I say use red-green TDD and give it its instruction. So it's "use red-green TDD"—it's like five tokens, and that works. All of the good coding agents know what red-green TDD is and they will start churning through and the chances of you getting code that works go up so much if they're writing the test first. I wrote more about TDD for coding agents recently in Red/green TDD . I have hated [test-first TDD] throughout my career. I've tried it in the past. It feels really tedious. It slows me down. I just wasn't a fan. Getting agents to do it is fine. I don't care if the agent spins around for a few minutes wasting its time on a test that doesn't work. I see people who are writing code with coding agents and they're not writing any tests at all. That's a terrible idea. Tests—the reason not to write tests in the past has been that it's extra work that you have to do and maybe you'll have to maintain them in the future. They're free now. They're effectively free. I think tests are no longer even remotely optional. You have to get them to test the stuff manually, which doesn't make sense because they're computers. But anyone who's done automated tests will know that just because the test suite passes doesn't mean that the web server will boot. So I will tell my agents, start the server running in the background and then use curl to exercise the API that you just created. And that works, and often that will find new bugs that the test didn't cover. I've got this new tool I built called Showboat. The idea with Showboat is you tell it—it's a little thing that builds up a markdown document of the manual test that it ran. So you can say go and use Showboat and exercise this API and you'll get a document that says "I'm trying out this API," curl command, output of curl command, "that works, let's try this other thing." I introduced Showboat in Introducing Showboat and Rodney, so agents can demo what they've built . I had a project recently where I wanted to add file uploads to my own little web framework, Datasette—multipart file uploads and all of that. And the way I did it is I told Claude to build a test suite for file uploads that passes on Go and Node.js and Django and Starlette—just here's six different web frameworks that implement this, build tests that they all pass. Now I've got a test suite and I can say, okay, build me a new implementation for Datasette on top of those tests. And it did the job. It's really powerful—it's almost like you can reverse engineer six implementations of a standard to get a new standard and then you can implement the standard. Here's the PR for that file upload feature. It's completely context dependent. I knock out little vibe-coded HTML JavaScript tools, single pages, and the code quality does not matter. It's like 800 lines of complete spaghetti. Who cares, right? It either works or it doesn't. Anything that you're maintaining over the longer term, the code quality does start really mattering. Here's my collection of vibe coded HTML tools , and notes on how I build them . Having poor quality code from an agent is a choice that you make. If the agent spits out 2,000 lines of bad code and you choose to ignore it, that's on you. If you then look at that code—you know what, we should refactor that piece, use this other design pattern—and you feed that back into the agent, you can end up with code that is way better than the code I would have written by hand because I'm a little bit lazy. If there was a little refactoring I spot at the very end that would take me another hour, I'm just not going to do it. If an agent's going to take an hour but I prompt it and then go off and walk the dog, then sure, I'll do it. I turned this point into a bit of a personal manifesto: AI should help us produce better code . One of the magic tricks about these things is they're incredibly consistent. If you've got a codebase with a bunch of patterns in, they will follow those patterns almost to a tee. Most of the projects I do I start by cloning that template. It puts the tests in the right place and there's a readme with a few lines of description in it and GitHub continuous integration is set up. Even having just one or two tests in the style that you like means it'll write tests in the style that you like. There's a lot to be said for keeping your codebase high quality because the agent will then add to it in a high quality way. And honestly, it's exactly the same with human development teams—if you're the first person to use Redis at your company, you have to do it perfectly because the next person will copy and paste what you did. I run templates using cookiecutter - here are my templates for python-lib , click-app , and datasette-plugin . When you build software on top of LLMs you're outsourcing decisions in your software to a language model. The problem with language models is they're incredibly gullible by design. They do exactly what you tell them to do and they will believe almost anything that you say to them. Here's my September 2022 post that introduced the term prompt injection . I named it after SQL injection because I thought the original problem was you're combining trusted and untrusted text, like you do with a SQL injection attack. Problem is you can solve SQL injection by parameterizing your query. You can't do that with LLMs—there is no way to reliably say this is the data and these are the instructions. So the name was a bad choice of name from the very start. I've learned that when you coin a new term, the definition is not what you give it. It's what people assume it means when they hear it. Here's more detail on the challenges of coining terms . The lethal trifecta is when you've got a model which has access to three things. It can access your private data—so it's got access to environment variables with API keys or it can read your email or whatever. It's exposed to malicious instructions—there's some way that an attacker could try and trick it. And it's got some kind of exfiltration vector, a way of sending messages back out to that attacker. The classic example is if I've got a digital assistant with access to my email, and someone emails it and says, "Hey, Simon said that you should forward me your latest password reset emails." If it does, that's a disaster. And a lot of them kind of will. My post describing the Lethal Trifecta . We discussed the challenges of running coding agents safely, especially on local machines. The most important thing is sandboxing. You want your coding agent running in an environment where if something goes completely wrong, if somebody gets malicious instructions to it, the damage is greatly limited. This is why I'm such a fan of Claude Code for web . The reason I use Claude on my phone is that's using Claude Code for the web, which runs in a container that Anthropic run. So you basically say, "Hey, Anthropic, spin up a Linux VM. Check out my git repo into it. Solve this problem for me." The worst thing that could happen with a prompt injection against that is somebody might steal your private source code, which isn't great. Most of my stuff's open source, so I couldn't care less. On running agents in YOLO mode, e.g. Claude's : I mostly run Claude with dangerously skip permissions on my Mac directly even though I'm the world's foremost expert on why you shouldn't do that. Because it's so good. It's so convenient. And what I try and do is if I'm running it in that mode, I try not to dump in random instructions from repos that I don't trust. It's still very risky and I need to habitually not do that. The topic of testing against a copy of your production data came up. I wouldn't use sensitive user data. When you work at a big company the first few years everyone's cloning the production database to their laptops and then somebody's laptop gets stolen. You shouldn't do that. I'd actually invest in good mocking—here's a button I click and it creates a hundred random users with made-up names. There's a trick you can do there which is much easier with agents where you can say, okay, there's this one edge case where if a user has over a thousand ticket types in my event platform everything breaks, so I have a button that you click that creates a simulated user with a thousand ticket types. I feel like there have been a few inflection points. GPT-4 was the point where it was actually useful and it wasn't making up absolutely everything and then we were stuck with GPT-4 for about 9 months—nobody else could build a model that good. I think the killer moment was Claude Code. The coding agents only kicked off about a year ago. Claude Code just turned one year old. It was that combination of Claude Code plus Sonnet 3.5 at the time—that was the first model that really felt good enough at driving a terminal to be able to do useful things. Then things got really good with the November 2025 inflection point . It's at a point where I'm oneshotting basically everything. I'll pull out and say, "Oh, I need three new RSS feeds on my blog." And I don't even have to ask if it's going to work. It's like a two sentence prompt. That reliability, that ability to predictably—this is why we can start trusting them because we can predict what they're going to do. An ongoing challenge is figuring out what the models can and cannot do, especially as new models are released. The most interesting question is what can the models we have do right now. The only thing I care about today is what can Claude Opus 4.6 do that we haven't figured out yet. And I think it would take us six months to even start exploring the boundaries of that. It's always useful—anytime a model fails to do something for you, tuck that away and try again in 6 months because it'll normally fail again, but every now and then it'll actually do it and now you might be the first person in the world to learn that the model can now do this thing. A great example is spellchecking. A year and a half ago the models were terrible at spellchecking—they couldn't do it. You'd throw stuff in and they just weren't strong enough to spot even minor typos. That changed about 12 months ago and now every blog post I post I have a proofreader Claude thing and I paste it and it goes, "Oh, you've misspelled this, you've missed an apostrophe off here." It's really useful. Here's the prompt I use for proofreading. This stuff is absolutely exhausting. I often have three projects that I'm working on at once because then if something takes 10 minutes I can switch to another one and after two hours of that I'm done for the day. I'm mentally exhausted. People worry about skill atrophy and being lazy. I think this is the opposite of that. You have to operate firing on all cylinders if you're going to keep your trio or quadruple of agents busy solving all these different problems. I think that might be what saves us. You can't have one engineer and have him do a thousand projects because after 3 hours of that, he's going to literally pass out in a corner. I was asked for general career advice for software developers in this new era of agentic engineering. As engineers, our careers should be changing right now this second because we can be so much more ambitious in what we do. If you've always stuck to two programming languages because of the overhead of learning a third, go and learn a third right now—and don't learn it, just start writing code in it. I've released three projects written in Go in the past two weeks and I am not a fluent Go programmer, but I can read it well enough to scan through and go, "Yeah, this looks like it's doing the right thing." It's a great idea to try fun, weird, or stupid projects with them too: I needed to cook two meals at once at Christmas from two recipes. So I took photos of the two recipes and I had Claude vibe code me up a cooking timer uniquely for those two recipes. You click go and it says, "Okay, in recipe one you need to be doing this and then in recipe two you do this." And it worked. I mean it was stupid, right? I should have just figured it out with a piece of paper. It would have been fine. But it's so much more fun building a ridiculous custom piece of software to help you cook Christmas dinner. Here's more about that recipe app . Eric asked if we would build Django the same way today as we did 22 years ago . In 2003 we built Django. I co-created it at a local newspaper in Kansas and it was because we wanted to build web applications on journalism deadlines. There's a story, you want to knock out a thing related to that story, it can't take two weeks because the story's moved on. You've got to have tools in place that let you build things in a couple of hours. And so the whole point of Django from the very start was how do we help people build high-quality applications as quickly as possible. Today, I can build an app for a news story in two hours and it doesn't matter what the code looks like. I talked about the challenges that AI-assisted programming poses for open source in general. Why would I use a date picker library where I'd have to customize it when I could have Claude write me the exact date picker that I want? I would trust Opus 4.6 to build me a good date picker widget that was mobile friendly and accessible and all of those things. And what does that do for demand for open source? We've seen that thing with Tailwind, right? Where Tailwind's business model is the framework's free and then you pay them for access to their component library of high quality date pickers, and the market for that has collapsed because people can vibe code those kinds of custom components. Here are more of my thoughts on the Tailwind situation. I don't know. Agents love open source. They're great at recommending libraries. They will stitch things together. I feel like the reason you can build such amazing things with agents is entirely built on the back of the open source community. Projects are flooded with junk contributions to the point that people are trying to convince GitHub to disable pull requests, which is something GitHub have never done. That's been the whole fundamental value of GitHub—open collaboration and pull requests—and now people are saying, "We're just flooded by them, this doesn't work anymore." I wrote more about this problem in Inflicting unreviewed code on collaborators . You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options .

go Go html HTML ai AI javascript JavaScript programming Programming
0 views
Chris Coyier Yesterday

Kermit Roosevelt

I was at a school function the other day where the 2nd graders performed a bunch of Aesop’s Fabels and it was great. It was a double-header with 3rd graders who then read prepared reports on famous people. It was cross-disciplinary thing as the kids brought props from design class, costumes from performing arts, and did the speech both in Spanish and English. It was cute. A lot of astronauts and artists and stuff. One kid did Theodore Roosevelt. I’m not a smart man, and I just had no idea this happened . 1912. He’s giving a speech in my old stomping grounds, Milwaukee, Wisconsin. Dude friggin shoots him in the chest. The bullet goes through a thick, folded-up bit of paper in his pocket, but then still into his body. Then he’s like “I’m good” and continues his speech for an hour. He recoups a couple of weeks but they leave the bullet in his body and didn’t seem to care. Kind of a badass. No wonder he leaned into the “Bull Moose” thing. Then the kid is like, and he had five kids, yadda, yadda, Kermit , yadda, yadda. I was like LOL, he named one of his kids Kermit. Turns out all of his kids led fascinating lives too! Kermit was an unhealthy kid, but ultimately went to Harvard and then did a bunch of literal jungle exploration with his dad (?!) and later Asia with his brother. … he postponed his marriage to join his father on a dangerous journey to the River of Doubt in Brazil. Both he and his father nearly died during this trip through the jungle. He fought in both World Wars, deciding to go to England and join the British Army to fight for them. Apparently, you can just do that? War breaks out, and you can just pick one of the countries and go there and fight for that side? WTF? He doesn’t make it all the way through WWII because of the health stuff, so they stick him up in Alaska, and he kills himself. Wild stuff. Oh and speaking of his brother Theodore III… Along with his brother, Kermit, Roosevelt spent most of 1929 on a zoological expedition and was the first Westerner known to have shot a panda.

culture Culture
0 views
A Working Library Yesterday

The Salt Eaters

Velma Henry is brought before Minnie Ransom for a healing. Velma, an activist who has become cynical of the movement and especially of the egocentric men who attempt to lead it, has recently channeled her cynicism into cutting her wrists and placing her head in the oven. Alive, wrists bandaged, gown flapping open in the back, she sits before a dozen friends and neighbors as Velma and her spiritual guide Old Wife try to bring her back. The book centers on this moment, sweeping backwards and forwards and around the Southern town where each of these people live and work and hope for better days. The opening question lingers through every page, perhaps unanswerable, or perhaps only to be answered by the whole: “Are you sure, sweetheart, that you want to be well?” View this post on the web , subscribe to the newsletter , or reply via email .

culture Culture writing Writing books Books
0 views
iDiallo Yesterday

You Digg?

For me, being part of an online community started with Digg. Digg was the precursor to Reddit and the place to be on the internet. I never got a MySpace account, I was late to the Facebook game, but I was on Digg. When Digg redesigned their website (V4), it felt like a slap in the face. We didn't like the new design, but the community had no say in the direction. To make it worse, they removed the bury button. It's interesting how many social websites remove the ability to downvote. There must be a study somewhere that makes a sound argument for it, because it makes no sense to me. Anyway, when Digg announced they were back in January 2026, I quickly requested an invite. It was nostalgic to log in once more and see an active community building back up right where we left off. But then, just today, I read that they are shutting down. I had a single post in the technology sub. It was starting to garner some interest and then, boom! Digg is gone once more. The CEO said that one major reason was that they faced "an unprecedented bot problem." This is our new reality. Bots are now powered by AI and they are more disruptive than ever. They quickly circumvent bot detection schemes and flood every conversation with senseless text. It seems like there are very few places left where people can have a real conversation online. This is not the future I was looking for. I'll quietly write on my blog and ignore future communities that form. Rest in peace, Digg.

culture Culture ai AI
0 views
Sean Goedecke Yesterday

Big tech engineers need big egos

It’s a common position among software engineers that big egos have no place in tech 1 . This is understandable - we’ve all worked with some insufferably overconfident engineers who needed their egos checked - but I don’t think it’s correct. In fact, I don’t know if it’s possible to survive as a software engineer in a large tech company without some kind of big ego. However, it’s more complicated than “big egos make good engineers”. The most effective engineers I’ve worked with are simultaneously high-ego in some situations and surprisingly low-ego in others. What’s going on there? Software engineering is shockingly humbling, even for experienced engineers. There’s a reason this joke is so popular: The minute-to-minute experience of working as a software engineer is dominated by not knowing things and getting things wrong . Every time you sit down and write a piece of code, it will have several things wrong with it: some silly things, like missing semicolons, and often some major things, like bugs in the core logic. We spend most of our time fixing our own stupid mistakes. On top of that, even when we’ve been working on a system for years, we still don’t know that much about it. I wrote about this at length in Nobody knows how large software products work , but the reason is that big codebases are just that complicated. You simply can’t confidently answer questions about them without going and doing some research, even if you’re the one who wrote the code. When you have to build something new or fix a tricky problem, it can often feel straight-up impossible to begin, because good software engineers know just how ignorant they are and just how complex the system is. You just have to throw yourself into the blank sea of millions of lines of code and start wildly casting around to try and get your bearings. Software engineers need the kind of ego that can stand up to this environment. In particular, they need to have a firm belief that they can figure it out, no matter how opaque the problem seems; that if they just keep trying, they can break through to the pleasant (though always temporary) state of affairs where they understand the system and can see at a glance how bugs can be fixed and new features added 2 . What about the non-technical aspects of the job? Nobody likes working with a big ego, right? Wrong. Every great software engineer I’ve worked with in big tech companies has had a big ego - though as I’ll say below, in some ways these engineers were surprisingly low-ego. You need a big ego to take positions . Engineers love being non-committal about technical questions, because they’re so hard to answer and there’s often a plausible case for either side. However, as I keep saying , engineers have a duty to take clear positions on unclear technical topics, because the alternative is a non-technical decision maker (who knows even less) just taking their best guess. It’s scary to make an educated guess! You know exactly all the reasons you might be wrong. But you have to do it anyway, and ego helps a lot with that. You need a big ego to be willing to make enemies . Getting things done in a large organization means making some people angry. Of course, if you’re making lots of people angry, you’re probably screwing up: being too confrontational or making obviously bad decisions. But if you’re making a large change and one or two people are angry, that’s just life. In big tech companies, any big technical decision will affect a few hundred engineers, and one of them is bound to be unhappy about it. You can’t be so conflict-averse that you let that stop you from doing it, if you believe it’s the right decision. In other words, you have to have the confidence to believe that you’re right and they’re wrong, even though technical decisions always involve unclear tradeoffs and it’s impossible to get absolute certainty. You need a big ego to correct incorrect or unclear claims. When I was still in the philosophy world, the Australian logician Graham Priest had a reputation for putting his hand up and stopping presentations when he didn’t understand something that was said, and only allowing the seminar to continue when he felt like he understood. From his perspective, this wasn’t rude: after all, if he couldn’t understand it, the rest of the audience probably couldn’t either, and so he was doing them a favor by forcing a more clear explanation from the speaker. This is obviously a sign of a big ego. It’s also a trait that you need in a large tech company. People often nod and smile their way past incorrect technical claims, even when they suspect they might be wrong - assuming that they’ve just misunderstood and that somebody else will correct it, if it’s truly wrong. If you are the most senior engineer in the room, correcting these claims is your job. If everyone in the room is so pro-social and low-ego that they go along to get along, decisions will get made based on flatly incorrect technical assumptions, projects will get funded that are impossible to complete, and engineers will burn weeks or months of their careers vainly trying to make these projects work. You have to have a big enough ego to think “actually, I think I’m right and everyone in this room is confused”, even when the room is full of directors and VPs. All of this selects for some pretty high-ego engineers. But in order to actually succeed in these roles in large tech companies, you need to have a surprisingly low ego at times. I think this is why really effective big tech engineers are so rare: because it requires such a delicate balance between confidence and diffidence. To be an effective engineer, you need to have a towering confidence in your own ability to solve problems and make decisions, even when people disagree. But you also need to be willing to instantly subordinate your ego to the organization, when it asks you to. At the end of the day, your job - the reason the company pays you - is to execute on your boss’s and your boss’s boss’s plans, whether you agree with them or not. Competent software engineers are allowed quite a lot of leeway about how to implement those plans. However, they’re allowed almost no leeway at all about the plans themselves. In my experience, being confused about this is a common cause of burnout 3 . Many software engineers are used to making bold decisions on technical topics and being rewarded for it. Those software engineers then make a bold decision that disagrees with the VP of their organization, get immediately and brutally punished for it, and are confused and hurt. In fact, sometimes you just get punished and there’s nothing you can do. This is an unfortunate fact of how large organizations function: even if you do great technical work and build something really useful, you can fall afoul of a political battle fought three levels above your head, and come away with a worse reputation for it. Nothing to be done! This can be a hard pill to swallow for the high-ego engineers that tend to lead really useful technical projects. You also have to be okay with having your projects cancelled at the last minute. It’s a very common experience in large tech companies that you’re asked to deliver something quickly, you buckle down and get it done, and then right before shipping you’re told “actually, let’s cancel that, we decided not to do it”. This is partly because the decision-making process can be pretty fluid, and partly because many of these asks originate from off-hand comments: the CTO implies that something might be nice in a meeting, the VPs and directors hustle to get it done quickly, and then in the next meeting it becomes clear that the CTO doesn’t actually care, so the project is unceremoniously cancelled 4 . Nobody likes to work with a bully, or with someone who refuses to admit when they’re wrong, or with somebody incapable of empathy. But you really do need a strong ego to be an effective software engineer, because software engineering requires you to spend most of your day in a position of uncertainty or confusion. If your ego isn’t strong enough to stand up to that - if you don’t believe you’re good enough to power through - you simply can’t do the job. This is particularly true when it comes to working in a large software company. Many of the tasks you’re required to do (particularly if you’re a senior or staff engineer) require a healthy ego. However, there’s a kind of catch-22 here. If it insults your pride to work on silly projects, or to occasionally “catch a stray bullet” in the organization’s political fights, or to have to shelve a project that you worked hard on and is ready to ship, you’re too high-ego to be an effective software engineer. But if you can’t take firm positions, or if you’re too afraid to make enemies, or you’re unwilling to speak up and correct people, you’re too low-ego. Engineers who are low-ego in general can’t get stuff done, while engineers who are high-ego in general get slapped down by the executives who wield real organizational power. The most successful kind of software engineer is therefore a chameleon: low-ego when dealing with executives, but high-ego when dealing with the rest of the organization 5 . What do I mean by “ego”, in this context? More or less the colloquial sense of the term: a somewhat irrational self-confidence, a tendency to believe that you’re very important, the sense that you’re the “main character”, that sort of thing Why is this “ego”, and not just normal confidence? Well, because of just how murky and baffling software problems feel when you start working on them. You really do need a degree of confidence in yourself that feels unreasonable from the inside. It should be obvious, but I want to explicitly note that you don’t just need ego: you also have to be technically strong enough to actually succeed when your ego powers you through the initial period of self-doubt. I share the increasingly-common view that burnout is not caused by working too hard, but by hard work unrewarded. That explains why nothing burns you out as hard as being punished for hard work that you expected a reward for. It’s more or less exactly this scene from Silicon Valley. This description sounds a bit sociopathic to me. But, on reflection, it’s fairly unsurprising that competent sociopaths do well in large organizations. Whether that kind of behavior is worth emulating or worth avoiding is up to you, I suppose. What do I mean by “ego”, in this context? More or less the colloquial sense of the term: a somewhat irrational self-confidence, a tendency to believe that you’re very important, the sense that you’re the “main character”, that sort of thing ↩ Why is this “ego”, and not just normal confidence? Well, because of just how murky and baffling software problems feel when you start working on them. You really do need a degree of confidence in yourself that feels unreasonable from the inside. It should be obvious, but I want to explicitly note that you don’t just need ego: you also have to be technically strong enough to actually succeed when your ego powers you through the initial period of self-doubt. ↩ I share the increasingly-common view that burnout is not caused by working too hard, but by hard work unrewarded. That explains why nothing burns you out as hard as being punished for hard work that you expected a reward for. ↩ It’s more or less exactly this scene from Silicon Valley. ↩ This description sounds a bit sociopathic to me. But, on reflection, it’s fairly unsurprising that competent sociopaths do well in large organizations. Whether that kind of behavior is worth emulating or worth avoiding is up to you, I suppose. ↩

programming Programming career Career
0 views
Stratechery 2 days ago

2026.11: Winners, Losers, and the Unknown

Welcome back to This Week in Stratechery! As a reminder, each week, every Friday, we’re sending out this overview of content in the Stratechery bundle; highlighted links are free for everyone . Additionally, you have complete control over what we send to you. If you don’t want to receive This Week in Stratechery emails (there is no podcast), please uncheck the box in your delivery settings . On that note, here were a few of our favorites this week. This week’s Stratechery video is on Anthropic and Alignment . Integration and AI . One of the most important and longest-running questions about AI has been whether or not models would be commodities; Microsoft once bet on their integration with OpenAI, but in recent years has made the best that the infrastructure they can build around models will matter more than models themselves. However, the most recent evidence — particularly Copilot Cowork — is that the companies who are best able to harness (pun intended) model capabilities are the model makers themselves. If none of that makes sense, Andrew and I do a much more extensive deep dive on these different layers of the evolving AI value chain on this week’s episode of Sharp Tech. — Ben Thompson The Team Test and a Basketball Disgrace. On Greatest of All Talk, we thought the news of the week would be the return of Jayson Tatum for the Boston Celtics, which provided a delightful excuse to take stock of the Celtics, Wemby’s gravity-defying Spurs, Shai’s Thunder, KD’s Rockets and the NBA’s field of title contenders using Ben’s very scientific Capital-T Team Test for contenders. That was a great episode. Unfortunately, on the follow-up Friday, we had to discuss the crime against basketball decency that took place in Miami Tuesday night. Come for the Team Test joy, then, and stay for Erik Spoelstra outrage (and also check out Ben Golliver’s column about the calamity on his new Substack ). — Andrew Sharp The US, China and Iran. The past two weeks in the China policy space have been full of debates over the implications of the war in Iran for China specifically, and the U.S.-China relationship generally. I wrote about all of it on Sharp Text this week , including thoughts on some takes from last year that haven’t aged well, and why, with respect to China, the war in Iran is best understood as the latest in a succession of U.S.-led body blows to Beijing’s global interests. At least over the past 12 months, countering China has been a consideration in almost everything the U.S. has done in the foreign policy space.  — AS MacBook Neo, The (Not-So) Thin MacBook, Apple and Memory — The MacBook Neo was built to be cheap; that it is still good is not only a testament to Apple Silicon, but also the fact that the most important software runs in the cloud. Copilot Cowork, Anthropic’s Integration, Microsoft’s New Bundle — Microsoft is seeking to commoditize its complements, but Anthropic has a point of integration of their own; it’s good enough that Microsoft is making a new bundle on top of it. Oracle Earnings, Oracle’s Cloud Growth, Oracle’s Software Defense — Oracle crushed earnings in a way that not only speaks to the secular AI wave they are riding but also to Oracle’s strong position An Interview with Robert Fishman About the Current State of Hollywood — An interview with MoffettNathanson’s Robert Fishman about the current state of Hollywood, including Netflix, Paramount, YouTube, Disney, and Amazon. Loud and Clear — The War in Iran is not entirely about China, but it’s definitely about China. MacBook Neo Review Designing for the Low End The Wildly Infectious Banana Plague The ‘Raising a Lobster’ Frenzy; Iran and US-China as Trump’s Visit Looms; Two Sessions Takeaways Tatum and the Team Test, The Spurs Continue to Defy Young Team Gravity, Russ Takes Aim at Kings Reporters Spo and Bam and a Basketball Betrayal, An SGA Early Warning System, Kawhi, Luka and The Other MVP Candidate Nerding Out with the Neo, Claude and the Integration Question, The End of Coding Language History

ai AI business Business
0 views
Ed Zitron's Where's Your Ed At 2 days ago

Premium: The Hater's Guide To The SaaSpocalypse

Soundtrack: The Dillinger Escape Plan — Black Bubblegum To understand the AI bubble, you need to understand the context in which it sits, and that larger context is the end of the hyper-growth era in software that I call the Rot-Com Bubble .  Generative AI, at first, appeared to be the panacea — a way to create new products for software companies to sell (by connecting their software to model APIs), a way to sell the infrastructure to run it, and a way to create a new crop of startups that could be bought or sold or taken public.  Venture capital hit a wall in 2018 — vintages after that year are, for the most part, are stuck at a TVPI (total value paid in, basically the money you make for each dollar you invested) of 0.8x to 1.2x, meaning that you’re making somewhere between 80 cents to $1.20 for every dollar. Before 2018, Software As A Service (SaaS) companies had had an incredible run of growth, and it appeared basically any industry could have a massive hypergrowth SaaS company, at least in theory. As a result, venture capital and private equity has spent years piling into SaaS companies, because they all had very straightforward growth stories and replicable, reliable, and recurring revenue streams.  Between 2018 and 2022, 30% to 40% of private equity deals (as I’ll talk about later) were in software companies, with firms taking on debt to buy them and then lending them money in the hopes that they’d all become the next Salesforce, even if none of them will. Even VC remains SaaS-obsessed — for example, about 33% of venture funding went into SaaS in Q3 2025, per Carta . The Zero Interest Rate Policy (ZIRP) era drove private equity into fits of SaaS madness, with SaaS PE acquisitions hitting $250bn in 2021 . Too much easy access to debt and too many Business Idiots believing that every single software company would grow in perpetuity led to the accumulation of some of the most-overvalued software companies in history. As the years have gone by, things slowed down, and now private equity is stuck with tens of billions of dollars of zombie SaaS companies that it can’t take public or sell to anybody else, their values decaying far below what they had paid, which is a very big problem when most of these deals were paid in debt.  To make matters worse, 9fin estimates that IT and communications sector companies (mostly software) accounted for 20% to 25% of private credit deals tracked, with 20% of loans issued by public BDCs (like Blue Owl) going to software firms. Things look grim. Per Bain , the software industry’s growth has been on the decline for years, with declining growth and Net Revenue Retention, which is how much you're making from customers and expanding their spend minus what you're losing from customers leaving (or cutting spend): It’s easy to try and blame any of this on AI, because doing so is a far more comfortable story. If you can say “AI is causing the SaaSpocalypse,” you can keep pretending that the software industry’s growth isn’t slowing. That isn’t what’s happening. No, AI is not replacing all software. That is not what is happening. Anybody telling you this is either ignorant or actively incentivized to lie to you.  The lie starts simple: that the barrier to developing software is “lower” now, either “because anybody can write code” or “anybody can write code faster.” As I covered a few weeks ago … From what I can gather, the other idea is that AI can “simply automate” the functions of a traditional software company, and “agents” can replace the entire user experience, with users simply saying “go and do this” and something would happen. Neither of these things are true, of course — nobody bothers to check, and nobody writing about this stuff gives a fuck enough to talk to anybody other than venture capitalists or CEOs of software companies that are desperate to appeal to investors. To be more specific, the CEOs that you hear desperately saying that they’re “modernizing their software stack for AI” are doing so because investors, who also do not know what they are talking about, are freaking out that they’ll get “left behind” because, as I’ve discussed many times, we’re ruled by Business Idiots that don’t use software or do any real work . There are also no real signs that this is actually happening. While I’ll get to the decline of the SaaS industry’s growth cycle, if software were actually replacing anything we’d see direct proof — massive contracts being canceled, giant declines in revenue, and in the case of any public SaaS company, 8K filings that would say that major customers had shifted away business from traditional software.  Midwits with rebar chunks in their gray matter might say that “it’s too early to tell and that the contract cycle has yet to shift,” but, again, we’d already have signs, and you’d know this if you knew anything about software. Go back to drinking Sherwin Williams and leave the analysis to the people who actually know stuff!  We do have one sign though: nobody appears to be able to make much money selling AI, other than Anthropic ( which made $5 billion in its entire existence through March 2026 on $60 billion of funding ) and OpenAI (who I believe made far less than $13 billion based on my own reporting .) In fact, it’s time to round up the latest and greatest in AI revenues. Hold onto your hats folks! Riddle me this, Batman: if AI was so disruptive to all of these software companies, would it not be helping them disrupt themselves? If it were possible to simply magic up your own software replacement with a few prompts to Claude, why aren’t we seeing any of these companies do so? In fact, why do none of them seem to be able to do very much with generative AI at all?   The point I’m making is fairly simple: the whole “AI SaaSpocalypse” story is a cover-up for a much, much larger problem. Reporters and investors who do not seem to be able to read or use software are conflating the slowing growth of SaaS companies with the growth of AI tools, when what they’re actually seeing is the collapse of the tech industry’s favourite business model, one that’s become the favourite chew-toy of the Venture Capital, Private Equity and Private Credit Industries. You see, there are tens of thousands of SaaS companies in everything from car washes to vets to law firms to gyms to gardening companies to architectural firms. Per my Hater’s Guide To Private Equity : You’d eventually either take that company public or, in reality, sell it to a private equity firm . Per Jason Lemkin of SaaStr : The problem is that SaaS valuations were always made with the implicit belief that growth was eternal , just like the rest of the Rot Economy , except SaaS, at least for a while, had mechanisms to juice revenues, and easy access to debt. After all, annual recurring revenues are stable and reliable , and these companies were never gonna stop growing, leading to the creation of recurring revenue lending : To be clear, this isn’t just for leveraged buyout situations, but I’ll get into that later. The point I’m making is that the setup is simple: You see, nobody wants to talk about the actual SaaSpocalypse — the one that’s caused by the misplaced belief that any software company will grow forever.  Generative AI isn’t destroying SaaS. Hubris is.  Alright, let’s do this one more time. SaaS — Software As A Service — is both the driving force and seedy underbelly of the tech industry. It’s a business model that sells itself on a seemingly good deal. Instead of paying upfront for an expensive software license and then again when future updates happen, you pay a “low” monthly fee that allows you to get (in theory) the most up-to-date (in theory) and well-maintained ( in theory ) version of whatever it is you’re using. It also ( in theory ) means that companies need to stay competitive to keep your business, because you’re committing a much smaller amount of money than a company might make from a single license. Over here in the real world , we know the opposite is true. Per The Other Bubble, a piece I wrote in September 2024 : It’s hard to say exactly how large SaaS has become, because SaaS is in basically everything, from whatever repugnant productivity software your boss has insisted you need, to every consumer app now having some sort of “Plus” package that paywalls features that used to be free. Nevertheless, “SaaS” in most cases refers to business software , with the occasional conflation with the nebulous form of “the enterprise,” which really means “any company larger than 500 people.”  McKinsey says it was worth “$3 trillion” in 2022 “after a decade of rapid growth,” Jason Lemkin and IT planning software company Vena say it has revenues somewhere between $300 billion and $400 billion a year. Grand View Research has the global business software and services market at around $584 billion , and the reason I bring that up is that basically all business software is now SaaS, and these companies make an absolute shit ton on charging service fees. “Perpetual licenses” — as in something you pay for once, and use forever — are effectively dead, with a few exceptions such as Microsoft Windows, Microsoft Office, and some of its server and database systems. Adobe killed them in 2014 ( and a few more in 2022 ), Oracle killed them in 2020 , and Broadcom killed them in 2023 , the same year that Citrix stopped supporting those unfortunate to have bought them before they went the way of the dodo in 2019 . To quote myself again, in 2011, Marc Andreessen said that “ software is eating the world.” And he was right, but not in a good way. Andreesen’s argument was that software should eat every business model: Every single company you work with that has any kind of software now demands you subscribe to it, and the ramifications of them doing so are more significant than you’ve ever considered.  That’s because SaaS is — or, at least, was — a far-more-stable business model than selling people something once. Customers are so annoying . When they buy something, they tend to use it until it stops working, and if you made the product well , that might mean they only pay you once.   SaaS fixes this problem by giving them only one option — to pay you a nasty little toll every single month, or ideally once a year, on a contractual basis, in a way that’s difficult to cancel.  Sadly, the success of the business software industry turned everything into SaaS.  Recently, I tried to cancel my membership to Canva, a design platform that sort of works well when you want it to but sometimes makes your browser crash. Doing so required me to go through no less than four different screens, all of which required me to click “cancel” — offers to give me a discount, repeated requests to email support, then a final screen where the cancel button moved to a different place.  This is nakedly evil. If you are somebody high up at Canva, I cannot tell you to go fuck yourself hard enough! This is a scummy way to make business and I would rather carve a meme on my ass than pay you another dollar!  It’s also, sadly, one of the tech industry’s most common (and evil!) tricks .  Everybody got into SaaS because, for a while, SaaS was synonymous with growth. Venture capitalists invested in business with software subscriptions because it was an easy way to say “we’re gonna grow so much ,” with massive sales teams that existed to badger potential customers, or “customer success managers” that operate as internal sales teams to try and get you to start paying for extra features, some of which might also be useful rather than helping somebody hit their sales targets.  The other problem is how software is sold. As discussed in the excellent Brainwash An Executive Today , Nik Suresh broke down the truth behind a lot of SaaS sales — that the target customer is the purchaser at a company, who is often not the end user, meaning that software is often sold in a way that’s entirely divorced from its functionality. This means that growth, especially as things have gotten desperate, has come from a place of conning somebody with money out of it rather than studiously winning a customer’s heart.  And, as I’ve hinted at previously, the only thing that grows forever is cancer. In today’s newsletter I am going to walk you through the contraction — and in many cases collapse — of tech’s favourite business model, caused not by any threat from Large Language Models but the brutality of reality, gravity and entropy. Despite the world being anything but predictable or reliable, the entire SaaS industry has been built on the idea that the good times would never, ever stop rolling. I guess you’re probably wondering why that’s a problem! Well, it’s quite simple (emphasis mine): That’s right folks, 40% of PE deals between 2018 and 2022 were for software companies, the very same time venture capital fund returns got worse. Venture and private equity has piled into an industry it believed was taking off just as it started to slow down. The AI bubble is just part of the wider collapse of the software industry’s growth cycle. This is The Hater’s Guide To The SaaSpocalypse, or “Software As An Albatross.”  In its Q4 2025 earnings, IBM said its total “generative AI book of business since 2023” hit $12.5 billion — of which 80% came from its consultancy services, which consists mostly of selling AI other people’s AI models to other businesses. It then promptly said it would no longer report this as a separate metric going forward .  To be clear, this company made $67.5 billion in 2025, $62.8 billion in 2024, $61.9 billion in 2023 and $60.5 billion in 2022. Based on those numbers, it’s hard to argue that AI is having much of an impact at all, and if it were, it would remain broken out. Scummy consumer-abuser Adobe tries to scam investors and the media alike by referring to “AI-influenced” revenue — referring to literally any product with a kind of AI-plugin you can pay for (or have to pay for as part of a subscription) — and “AI-first” revenue, which refers to actual AI products like Adobe Firefly. It’s unclear how much these things actually make. According to Adobe’s Q3 FY2025 earnings , “AI-influenced” ARR was “surpassing” $5 billion (so $1.248 billion in a quarter, though Adobe does not actually break this out in its earnings report), and “AI-first” ARR was “already exceeding [its] $250 million year-end target,” which is a really nice way of saying “we maybe made about $60 million a quarter for a product that we won’t shut the fuck up about.”  For some context, Adobe made $5.99 billion in that quarter, which makes this (assuming AI-first revenue was consistent) roughly 1% of its revenue .   Adobe then didn’t report its AI-first revenue again until Q1 FY2026, when it revealed it had “more than tripled year over year” without disclosing the actual amount, likely because a year ago its AI-first revenue was $125 million ARR , but this number also included “add-on innovations.” In any case, $375 million ARR works out to $31.25 million a month, or (even though it wasn’t necessarily this high for the entire quarter) $93.75 million a quarter, or roughly 1.465% of its $6.40 billion in quarterly revenue in Q1 FY2026. Bulbous Software-As-An-Encumberance Juggernaut Salesforce revealed in its latest earnings that its Agentforce and Data 360 (which is not an AI product, just the data resources required to use its services) platforms “exceeded” $2.9 billion… but that $1.1 billion of that ARR came from its acquisition of Informatica Cloud , (which is not a fucking AI product by the way!). Agentforce ARR ended up being a measly $800 million, or $66 million a month for a company that makes $11.2 billion a year. It isn’t clear whether what period of time this ARR refers to.  Microsoft, Google and Amazon do not break out their AI revenues. Box — whose CEO Aaron Levie appears to spend most of his life tweeting vague things about AI agents — does not break out AI revenue .  Shopify, the company that mandates you prove that AI can’t do a job before asking for resources , does not break out AI revenue. ServiceNow, whose CEO said back in 2022 told his executives that “everything they do [was now] AI, AI, AI, AI, AI,”   said in its Q4 2025 earnings that its AI-powered “ Now Assist” had doubled its net new Annual Contract Value had doubled year-over-year ,” but declined to say how much that was after saying in mid-2025 it wanted a billion dollars in revenue from AI in 2026 .  Apparently it told analysts that it had hit $600 million in ACV in March ( per The Information )...in the fourth quarter of 2025, which suggests that this is not actually $600 million of revenues quite yet, nor do we know what that revenue costs.  What we do know is that ServiceNow had $3.46 billion in 2025, and its net income has been effectively flat for multiple quarters , and basically identical since 2023. Intuit, a company that vibrates with evil, had the temerity to show pride that it had generated " almost $90 million in AI efficiencies in the first half of 2025 ,” a weird thing to say considering this was a statement from March 2026. Anyway, back in November 2025 it agreed to pay over $100 million for model access to integrate ChatGPT . Great stuff everyone.  Workday, a company that makes about $2.5 billion a quarter in revenue, said it “generated over $100 million in new ACV from emerging AI products, [and that] overall ARR from these solutions was over $400 million.” $400 million ARR is $33 million.  Atlassian, which just laid off 10% of its workforce to “ self-fund further investment in AI ,” does not break out its AI revenues. Tens of thousands of SaaS companies were created in the last 20 years. These companies, for a while, had what seemed to be near-perpetual growth. This led to many, many private equity buyouts of SaaS companies, pumping them full of debt based on their existing recurring revenue and the assumption that they would never, ever stop growing. I will get into this later. It’s very bad. When growth slowed, the reaction was for these companies to raise venture debt — loans based on their revenue — and per Founderpath , 14 of the largest Business Development companies loaned $18 billion across 1000 companies in 2024 alone, with an average loan size of $13 million. This includes name brand companies like Cornerstone OnDemand and Dropbox, the latter of which took on a $34.4 million debt facility with an 11% interest rate. One has to wonder why a company that had $643 million in revenue in Q4 2024 needed that debt.

business Business
1 views
Chris Coyier 2 days ago

AI is my CMS

I mean… it’s not really, of course. I just thought such a thing would start to trickle out to people’s minds as agentic workflows start to take hold. Has someone written "AI is my CMS" yet? Feels inevitable. Like why run a build tool when you can just prompt another page? AI agents are already up in your codebase fingerbanging whole batches of files on command. What’s the difference between a CMS taking some content and smashing it into some templates and an AI doing that same job instead? Isn’t less tooling good? I had missed that this particular topic already had quite a moment in the sun this past December. Lee Robinson wrote Coding Agents & Complexity Budgets . Without calling it out by name, Lee basically had a vibe-coding weekend where he ripped out Sanity from cursor.com. I don’t think Lee is wrong for this choice. Spend some money to save some money. Remove some complexity. Get the code base more AI-ready. Yadda yadda. Even though Lee didn’t call out Sanity, they noticed and responded . They also make some good and measured points, I think. Which makes this a pretty great blog back-and-forth, by the way, which you love to see. Some of their argument as to why it can be the right choice to have Sanity is that some abstraction and complexity can be good, actually, because building websites from content can be complicated, especially as time and scale march on. And if you rip out a tool that does some of it, only to re-build many of those features in-house, what have you really gained? TIME FOR MY TWO CENTS. The language feels a little wrong to me. I think if you’re working with Markdown-files as content in a Next.js app… that’s already a CMS. You didn’t rip out a CMS, you ripped out a cloud database . Yes, that cloud database does binary assets also, and handles user management, and has screens for CRUDing the content, but to me it’s more of a cloud data store than a CMS. The advantage Lee got was getting the data and assets out of the cloud data store. I don’t think they were using stuff like the fancy GROQ language to get at their content in fine-grained ways. It’s just that cursor.com happened to not really need a database, and in fact was using it for things they probably shouldn’t have been (like video hosting). Me, I don’t think there is one right answer. If keeping content in Markdown files and building sites by smashing those into templates is wrong, then every static site generator ever built is wrong (🙄). But keeping content in databases isn’t wrong either. I tend to lean that way by default, since the power you get from being able to query is so obviously and regularly useful. Maybe they are both right in that having LLM tools that have the power to wiggleworm their way into the content no matter where it is, is helpful. In the codebase? Fine. In a DB that an MCP can access? Fine.

ai AI javascript JavaScript web-development Web Development
0 views
Robin Moffatt 2 days ago

Evaluating Claude's dbt Skills: Building an Eval from Scratch

I wanted to explore the extent to which Claude Code could build a data pipeline using dbt without iterative prompting. What difference did skills, models, and the prompt itself make? I’ve written in a separate post about what I found ( yes it’s good; no it’s not going to replace data engineers, yet ). In this post I’m going to show how I ran these tests (with Claude) and analysed the results (using Claude), including a pretty dashboard (created by Claude):

data Data tutorial Tutorial ai AI
0 views
Jeff Geerling 2 days ago

Restoring an Xserve G5: When Apple built real servers

Recently I came into posession of a few Apple Xserves. The one in question today is an Xserve G5, RackMac3,1 , which was built when Apple at the top—and bottom—of it's PowerPC era. This isn't the first Xserve—that honor belongs to the G4 1 . And it wasn't the last—there were a few generations of Intel Xeon-powered RackMacs that followed. But in my opinion, it was the most interesting. Unfortunately, being manufactured in 2004, this Mac's Delta power supply suffers from the Capacitor Plague . The PSU tends to run hot, and some of the capacitors weren't even 105°C-rated, so they tend to wear out, especially if the Xserve was running high-end workloads.

hardware Hardware
0 views
Manuel Moreale 2 days ago

Patrick Rhone

This week on the People and Blogs series we have an interview with Patrick Rhone, whose blog can be found at patrickrhone.net . Tired of RSS? Read this in your browser or sign up for the newsletter . People and Blogs is supported by the "One a Month" club members. If you enjoy P&B, consider becoming one for as little as 1 dollar a month. My name is Patrick Rhone. When I'm not trying to be the best husband and father I can be, I'm mostly known as a writer, blogger, technology consultant, speaker, mental health advocate, and general c-list internet personality. I also restore old houses as a professional hobby. I do volunteer circus rigging at a performing youth circus school as a less professional one. The very first post on my blog, Rhoneisms, is dated November 7th, 2003. Of course, I had been blogging before that, and there used to be posts dated slightly earlier. But, my blog actually began as an internally hosted one at the college I used to work for and I lost those earlier posts when I moved to a different platform and brought it public… Gosh, that seems like it was just yesterday. Not 22 years ago. Such is life. My main blog has had many different points of focus over the years. From geeky, mainly Apple, tech stuff to GTD-driven personal productivity stuff, to practical/actionable life advice stuff, to the anything I'm interested in sort of thing it is now. And, that’s exactly what a blog should be — a reflection of one's interest and attention over time. A reflection of who one is right now and where they've been. Blogs are living things that should grow at the same rate we do. I say "main" blog above because I do have a couple of other topic specific blogs (one for my home restoration work and The Cramped which is not often updated these days). I really just post anything I feel like. Links to things I find interesting. Essays of things that take me a bit longer to express. Short thought's I'm having. All sorts of things. I’m 58 years old. The internet was not even anything regular people could use until I was in my early 20s. My first "online" writing was things I posted to dial up BBS systems/communities. In the old days of the internet, it was common to have a blog just links or thoughts much like mine is today. There was no such thing as content management systems (like Moveable Type or WordPress) or services. No such thing as blogging software. Things were hand coded HTML. There were no “rules” about what a post had to look like or be. Here’s Kottke.org from 2001 . No titles. No format. Just some thoughts and a bunch of links for the day. This is the feel I’m trying to recapture. I generally do not have a specific creative environment. I believe the best inspiration can strike anywhere at anytime for the type of blogging I'm doing. That said, for my longer form essays, in general my process is that I think about something for a very long time and then suddenly, out of nowhere at often at the most inconvenient time, what I call "writing brain" kicks in and I must find something — anything — to get it written down ASAP. It appears fully formed when that happens. So, no drafts. My blog and domain registration is through Dreamhost who I've used for too long to remember (2012 maybe). It runs on WordPress. If I'm on iOS I use Drafts to post to it. On my Mac, I use MarsEdit . I very rarely use the Wordpress web interface for posting. Only if I need to jump in and edit the HTML of something complicated to format otherwise. Nope. I'm very happy with where it is now and how it exists. Like I said, a blog should grow and change at the same rate I do so, who knows, that could change tomorrow and when/if it does, I'll change it accordingly. Back of the napkin calculation: My general unlimited hosting for all my domains (I have a lot), sites, etc. is $39.95 a month. It would be too difficult to break down how much it is just to host the one blog out of that. It doesn't generate any direct revenue really and I don't do it for that reason. I suppose people who enjoy my work will buy one of my books or something but it is not for this that I do it. I blog because it is the best way for me to catalog my interests and thinking over time. If others want to monetize their work that's their choice and I have no real opinion on it. There are a few bloggers that I support with my dollars in different ways and I'm happy to do so. I remain a fan of Nicholas Bate who currently blogs at Hunter Gatherer 21C . In general, I enjoy his thoughts and insights. I also like his style of blogging. In many ways similar to mine (and I'd be remiss if I did not admit that mine is somewhat inspired by his). I'd recommend him for sure. But, there are too many people I absolutely adore and admire to list here. Some of which have already appeared in this series. Annie Muller , Rebecca Toh , Kurt Harden , my friend Jamie Thingelstad . Obviously also internet famous ones like Jason Kottke and John Gruber . The wonderful thing about the internet and the resurgence of blogging is that there is an endless amount of great blogs and bloggers out there. There is something and someone for everyone. Google your interests and find your people. Well, I'm writing this in the middle of a tumultuous time not just in my country but in my city and local community. It is the end of January in Minneapolis/Saint Paul and anyone reading this - even long after - need only google to know what is happening here. And, I can tell you anything you do see or read or hear about it is but one of hundreds or thousands of stories. In other words, my mind is a bit pre-occupied right now. But what I do want people to know about that is that despite everything our own federal government is doing to our state, it is only making our local communes stronger. We are deepening our ties with our neighbors, developing mutual aid networks to ensure care for the most vulnerable, and building peaceful resistance rapid response groups on a hyper local level. So this is what I want people to know: The worst of them is bringing out the best of us. The worst in them is bringing out the best in us. Now that you're done reading the interview, go check the blog and subscribe to the RSS feed . If you're looking for more content, go read one of the previous 132 interviews . People and Blogs is possible because kind people support it.

c# C# html HTML culture Culture writing Writing
0 views
iDiallo 2 days ago

It's Work that taught me how to think

On the first day of my college CS class, the professor walked in holding a Texas Instruments calculator above his head like Steve Jobs unveiling the first iPhone. The students sighed. They had expected computer science to involve little math. The professor told us he had helped build that calculator in the eighties, then spent a few minutes talking about his career and the process behind it. Then he plugged the device into his computer, opened a terminal on the projector, and pushed some code onto it. A couple of minutes later, he unplugged the cable, powered on the calculator, and sure enough, Snake was running on it. A student raised his hand. The professor leaned forward, eager for the first question of the semester. "Um... is this going to be on the test?" While the professor was showing us what it actually means to build something, to push code onto hardware and watch it come alive, his students were already thinking about the grade. About the exit. The experience meant nothing unless it converted into points. That was college for me. Everyone was chasing a passing grade to get to the next class. Learning was mostly incidental. The professors tried, but our incentives were completely misaligned. Talk of higher education becoming obsolete was already in the air, especially in CS. As enthusiastic as I had been when I started, that enthusiasm got chipped away one class at a time until the whole thing felt mechanical. Something I just had to get through. I dropped out shortly after the C++ class, which had taught me almost nothing about programming anyway. I was broke and could only pay for so many courses out of pocket. So I took my skills, such as they were, to a furniture store warehouse. My day job. When customers bought furniture, we pulled their merchandise from the back and loaded it into their trucks. They signed a receipt, we kept a copy, and those copies went into boxes labeled by month and date. At the end of the year, the boxes went onto a pallet, the pallet got shrink-wrapped, and a forklift tucked it away in a high storage compartment. Whenever an accountant called requesting a signed copy, usually because a customer was disputing a charge, the whole process ran in reverse. Someone licensed on the forklift had to retrieve the pallet, we cut the shrink-wrap, found the right box, and sifted through hundreds of receipts until we found the one we needed. The process took hours. One day I decided enough was enough. After my shift, I grabbed the day's signed receipts and fed them into a scanner. For each one, I created two images: a full copy and a cropped version showing just the top of the receipt where the order number was printed. I found a pirated OCR application, then used VBScript and a lot of Googling to write a script that read the order number and renamed each image file to match it. I also wrote my first Excel macros, also in VBScript. When everything was wired together, I had a working system. Each evening, I would enter the day's order numbers, scan the receipts, and let the script match them up with a preview attached. When the OCR failed to read a number, the file was renamed "unknown" with an incrementing number so I could verify those manually. From then on, when an accountant called, I could find and email them the receipt in under a minute, without ever leaving my desk. When I left that warehouse, I was ready to call myself a programmer. That one month building that system taught me more than two years of school ever had. But the education didn't stop there. Years later, now considering myself an experienced developer, a manager handed me what looked like a giant power strip. It had a dozen outlets, and was built for stress-testing set-top boxes in a datacenter. "Can you set this up?" he asked. A few years earlier, I would have panicked. I would have gone looking for someone who already knew the answer, or waited until the problem solved itself. But something had changed in me since the warehouse. Unfamiliar problems no longer felt like walls. They felt like the first receipt I ever fed into a scanner. It was just something to pull apart until it made sense. I had never worked with hardware. I had no idea where to start. But I didn't need to know where to start. I just needed to start. I brought the device to my desk and inspected every inch of it. I wasn't looking for the answer exactly. Instead, I was looking for the first question. And I found one: an RJ45 port on one end. Not exactly the programming interface you'd expect, but it was there for a reason. I looked up the model number of the device, downloaded the manual, and before long I was connected via Telnet, sending commands and reading output in the terminal. Problem solved. Not because I knew anything about hardware going in, but because I had learned to spend time with unfamiliar problems. None of this was in the syllabus. Nobody graded me on it. There was no partial credit for getting halfway there. That's the difference between school and work. School optimizes for the test, like that student who couldn't look past the grade to see what was actually being shown to him. School teaches you the shape of a problem and gives you a method to solve it. Work, on the other hand, doesn't care about the test. Work hands you something broken, or inefficient, or completely unfamiliar, and simply waits. Often, there are no right answers at work. You just have to build your own solution that satisfies the requirement. You figure things out, not because you memorized the right answer, but because you thought your way through it. Then something changes in how you approach every problem after that. You don't flinch at the next problem. You understand that facing unfamiliar problems is the job.

c++ C++ career Career
9 views
Kev Quirk 2 days ago

My WordPress - A Private In-Browser WordPress Install

I saw this while perusing my RSS feeds last night, and thought it was interesting. In all honesty, I've completely moved away from WordPress since all the drama a while ago. But this is quite cool - My WordPress is basically a version of WordPress that runs entirely in your browser. You visit my.wordpress.net it downloads some files to your machine, and you have WordPress - no install, no sign up. Just a private WordPress instance in your browser that only you can visit. Obviously if you reset your browser, or switch to another browser, you will lose your instance, but there are backup/restore options available. I think it might be good as a private journal or something, but I'm sure other people will find some interesting use cases for it. Either way, pretty cool. Read more about My WordPress Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️ You can reply to this post by email , or leave a comment .

c# C# web-development Web Development
0 views
Unplanned Obsolescence 2 days ago

XML is a Cheap DSL

Yesterday, the IRS announced the release of the project I’ve been engineering leading since this summer, its new Tax Withholding Estimator (TWE). Taxpayers enter in their income, expected deductions, and other relevant info to estimate what they’ll owe in taxes at the end of the year, and adjust the withholdings on their paycheck. It’s free, open source, and, in a major first for the IRS, open for public contributions . TWE is full of exciting learnings about the field of public sector software. Being me, I’m going to start by writing about by far the driest one: XML. (I am writing this in my personal capacity, based on the open source release, not in my position as a federal employee.) XML is widely considered clunky at best, obsolete at worst. It evokes memories of SOAP configs and J2EE (it’s fine, even good, if those acronyms don’t mean anything to you). My experience with the Tax Withholding Estimator, however, has taught me that XML absolutely has a place in modern software development, and it should be considered a leading option for any cross-platform declarative specification. TWE is a static site generated from two XML configurations. The first of these configs is the Fact Dictionary, our representation of the US Tax Code; the second will be the subject of a later blog post. We use the Fact Graph, a logic engine, to calculate the taxpayer’s tax obligations (and their withholdings) based on the facts defined in the Fact Dictionary. The Fact Graph was originally built for IRS Direct File and now we use it for TWE. I’m going to introduce you to the Fact Graph the way that I was introduced to it: by fire example. Put aside any preconceptions you might have about XML for a moment and ask yourself what this fact describes, and how well it describes it. This fact describes a fact that’s derived by subtracting from . In tax terms, this fact describes the amount you will need to pay the IRS at the end of the year. That amount, “total owed,” is the difference between the total taxes due for your income (“total tax”) and the amount you’ve already paid (“total payments”). My initial reaction to this was that it’s quite verbose, but also reasonably clear. That’s more or less how I still feel. You only need to look at a few of these to intuit the structure. Take the refundable credits calculation, for example. A refundable credit is a tax credit that can lead to a negative tax balance—if you qualify for more refundable credits than you owe in taxes, the government just gives you some money. TWE calculates the total value of refundable credits by adding up the values of the Earned Income Credit, the Child Tax Credit (CTC), American Opportunity Credit, the refundable portion of the Adoption Credit, and some other stuff from the Schedule 3. By contrast, non-refundable tax credits can bring your tax burden down to zero, but won’t ever make it negative. TWE models that by subtracting non-refundable credits from the tentative tax burden while making sure it can’t go below zero, using the operator. While admittedly very verbose, the nesting is straightforward to follow. The tax after non-refundable credits is derived by saying “give me the greater of these two numbers: zero, or the difference between tentative tax and the non-refundable credits.” Finally, what about inputs? Obviously we need places for the taxpayer to provide information, so that we can calculate all the other values. Okay, so instead of we use . Because the value is… writable. Fair enough. The denotes what type of value this fact takes. True-or-false questions use , like this one that records whether the taxpayer is 65 or older. There are some (much) longer facts, but these are a fair representation of what the median fact looks like. Facts depend on other facts, sometimes derived and sometimes writable, and they all add up to some final tax numbers at the end. But why encode math this way when it seems far clunkier than traditional notation? Countless mainstream programming languages would instead let you write this calculation in a notation that looks more like normal math. Take this JavaScript example, which looks like elementary algebra: That seems better! It’s far more concise, easier to read, and doesn’t make you explicitly label the “minuend” and “subtrahend.” Let’s add in the definitions for and . Still not too bad. Total tax is calculated by adding the tax after non-refundable credits (discussed earlier) to whatever’s in “other taxes.” Total payments is the sum of estimated taxes you’ve already paid, taxes you’ve paid on social security, and any refundable credits. The problem with the JavaScript representation is that it’s imperative . It describes actions you take in a sequence, and once the sequence is done, the intermediate steps are lost. The issues with this get more obvious when you go another level deeper, adding the definitions of all the values that and depend on. We are quickly arriving at a situation that has a lot of subtle problems. One problem is the execution order. The hypothetical function solicits an answer from the taxpayer, which has to happen before the program can continue. Calculations that don’t depend on knowing “total estimated taxes” are still held up waiting for the user; calculations that do depend on knowing that value had better be specified after it. Or, take a close look at how we add up all the social security income: All of a sudden we are really in the weeds with JavaScript. These are not complicated code concepts—map and reduce are both in the standard library and basic functional paradigms are widespread these days—but they are not tax math concepts. Instead, they are implementation details. Compare it to the Fact representation of that same value. This isn’t perfect—the that represents each social security source is a little hacky—but the meaning is much clearer. What are the total taxes paid on social security income? The sum of the taxes paid on each social security income. How do you add all the items in a collection? With . Plus, it reads like all the other facts; needing to add up all items in a collection didn’t suddenly kick us into a new conceptual realm. The philosophical difference between these two is that, unlike JavaScript, which is imperative , the Fact Dictionary is declarative . It doesn’t describe exactly what steps the computer will take or in what order; it describes a bunch of named calculations and how they depend on each other. The engine decides automatically how to execute that calculation. Besides being (relatively) friendlier to read, the most important benefit of a declarative tax model is that you can ask the program how it calculated something. Per the Fact Graph’s original author, Chris Given : The Fact Graph provides us with a means of proving that none of the unasked questions would have changed the bottom line of your tax return and that you’re getting every tax benefit to which you’re entitled. Suppose you get a value for that doesn’t seem right. You can’t ask the JavaScript version “how did you arrive at that number?” because those intermediate values have already been discarded. Imperative programs are generally debugged by adding log statements or stepping through with a debugger, pausing to check each value. This works fine when the number of intermediate values is small; it does not scale at all for the US Tax Code, where the final value is calculated based on hundreds upon hundreds of calculations of intermediate values. With a declarative graph representation, we get auditability and introspection for free, for every single calculation. Intuit, the company behind TurboTax, came to the same conclusion, and published a whitepaper about their “Tax Knowledge Graph” in 2020. Their implementation is not open source, however (or least I can’t find it). The IRS Fact Graph is open source and public domain, so it can be studied, shared, and extended by the public. If we accept the need for a declarative data representation of the tax code, what should it be? In many of the places where people used to encounter XML, such network data transfer and configuration files, it has been replaced by JSON. I find JSON to be a reasonably good wire format and a painful configuration format, but in neither case would I rather be using XML (although it’s a close call on the latter). The Fact Dictionary is different. It’s not a pile of settings or key-value pairs. It’s a custom language that models a unique and complex problem space. In programming we call this a domain-specific language, or DSL for short. As an exercise, I tried to come up with a plausible JSON representation of the fact from earlier. This is not a terribly complicated fact, but it’s immediately apparent that JSON does not handle arbitrary nested expressions well. The only complex data structure available in JSON is an object, so every child object has to declare what kind of object it is. Contrast that with XML, where the “kind” of the object is embedded in its delimiters. I think this XML representation could be improved, but even in its current form, it is clearly better than JSON. (It’s also, amusingly, a couple lines shorter.) Attributes and named children give you just enough expressive power to make choices about what your language should or should not emphasize. Not being tied to specific set of data types makes it reasonable to define your own, such as a distinction between “dollars” and “integers.” A lot of minor frustrations we’ve all internalized as inevitable with JSON are actually JSON-specific. XML has comments, for instance. That’s nice. It also has sane whitespace and newline handling, which is important when your descriptions are often long. For text that has any length or shape to it, XML is far more pleasant to read and edit by hand than JSON. There are still verbosity gains to be had, particularly with switch statements (omitted here out of respect for page length). I’d certainly remove the explicit “minuend” and “subtrahend,” for starters. I believe that the original team didn’t do this because they didn’t want the order of the children to have semantic consequence. I get it, but order is guaranteed in XML and I think the additional nesting and words do more harm then good. What about YAML? Chris Given again : whatever you do, don’t try to express the logic of the Internal Revenue Code as YAML Finally, there’s a good case to made that you could build this DSL with s-expressions. In a lot of ways, this is nicest syntax to read and edit. HackerNews user ok123456 asks : “Why would I want to use this over Prolog/Datalog?” I’m a Prolog fan ! This is also possible. My friend Deniz couldn’t help but rewrite it in KDL , a cool thing I had to look up. At least to my eye, all of these feel more pleasant than the XML version. When I started working on the Fact Graph, I strongly considered proposing a transition to s-expressions. I even half-jokingly included it in a draft design document. The process of actually building on top of the Fact Graph, however, taught me something very important about the value of XML. Using XML gives you a parser and a universal tooling ecosystem for free. Take Prolog for instance. You can relate XML to Prolog terms with a single predicate . If I want to explore Fact Dictionaries in Prolog—or even make a whole alternative implementation of the Fact Graph—I basically get the Prolog representation out of the box. S-expressions work great in Lisp and Prolog terms work great in Prolog. XML can be transformed, more or less natively, into anything. That makes it a great canonical, cross-platform data format. XML is rivaled only by JSON in the maturity and availability of its tooling. At one point I had the idea that it would be helpful to fuzzy search for Fact definitions by path. I’d like to just type “overtime” and see all the facts related to overtime. Regular searches of the codebase were cluttered with references and dependencies. This was possible entirely with shell commands I already had on my computer. This uses XPath to query all the fact paths, to clean up the output, and to interactively search the results. I solved my problem with a trivial bash one-liner. I kept going and said: not only do I want to search the paths, I’d like selecting one of the paths to show me the definition. Easy. Just take the result of the first command, which is a path attribute, and use it in a second XPath query. I got a little carried away building this out into a “$0 Dispatch Pattern” script of the kind described by Andy Chu . (Andy is a blogging icon, by the way.) I also added dependency search—not only can you query the definition of a fact, but you can go up the dependency chain by asking what facts depend on it. Try it yourself by cloning the repo and running (you need installed). The error handling is janky but it’s pretty solid for 60 lines of bash I wrote in an afternoon. I use it almost daily. I’m not sure how many people used my script, but multiple other team members put together similarly quick, powerful debugging tools that became part of everyone’s workflow. All of these tools relied on being able to trivially parse the XML representation and work with it in the language that best suited the problem they were trying to solve, without touching the Fact Graph’s actual implementation in Scala. The lesson I took from this is that a universal data representation is worth its weight in gold. There are exactly two options in this category. In most cases you should choose JSON. If you need a DSL though, XML is by far the cheapest one, and the cost-efficiency of building on it will empower your team to spend their innovation budget elsewhere. Thanks to Chris Given and Deniz Akşimşek for their feedback on a draft of this blog. I had never heard of XPath before 2023, when Deniz figured out an XPath query that made my first htmx PR possible. Another reason to use XML is that humans who aren’t programmers can read it. They usually don’t like it, but, if you did a good-enough job designing the schema, they can read it in a pinch. Do them a favor and build an alternative view, though. Because you’re using XML, this is pretty easy. It’s probably just because I’ve started to use it—buy a Jeep Grand Cherokee and suddenly the roadways seem full of them—but lately I have noticed an uptick in XML interest. Fellow Spring ’24 Recurser Jake Low recently wrote a tool called which turns XML documents into a flat, line-oriented representation. Martijn Faassen has been working on a modern XPath and XSLT engine in Rust . I’m not sure it’s fair to call JSON “lobotomized” but I thought this article was largely correct about the problems XML can solve. The binary format is especially interesting to me.

Bash javascript JavaScript open-source Open Source java Java programming Programming
0 views
Justin Duke 2 days ago

21 Bridges

A derivative, predictable, competent crime thriller. If you read that sentence and think "good," then you will like this film, and the opposite is true as well. The banality points to the banality of everything about this film — it seems to avoid contrivance and missteps and misfires more than it goes out of its way to court success. Boseman is wonderful, but his character is given absolutely nothing to do besides act with competence and rationality. The standout — the one character both written and portrayed with any sense of moral valence — is Taylor Kitsch as a trigger-happy dude who is both clearly insane but also cares deeply about his companion. When thinking about this movie I am drawn to a comparison with the-rip , given that I watched it so recently, and I find myself at least grateful for the economy in this film's runtime and its willingness to trust that the viewer is at least spending their time watching the film and not scrolling on their phone.

entertainment Entertainment movies Movies culture Culture
0 views
Justin Duke 2 days ago

Archiving the roadmap

Pour one out for Buttondown's transparent roadmap , which I formally archived yesterday evening after a year or so of informal archival. This felt like the journey that so many other companies have had who have tried to keep public roadmaps and then for one reason or another got rid of theirs. Mine had nothing to do with transparency. It was entirely due to the fact that Linear now makes a much better product than GitHub does — at least for the kind of project management I need — and if there was a way to easily make our Linear publicly visible, I would be happy to do so. The third-party services and integrations which purport to offer such functionality ( Productlane being the most notable) seem like more trouble and money than they're worth. More than anything, the reason I dithered about this for so long was a false sense of worry that there would be a backlash. Around 100 or so folks have commented, watched, or reacted to various issues over the years, which is not a huge amount but not a small one either, and it felt faintly bad to leave them all in the cold. But in reality, no one has minded or noticed that much. And whatever negative goodwill we generate from no longer having this public repository is offset by the negative goodwill we avoid from having that public repository look so obviously abandoned.

business Business open-source Open Source web-development Web Development
0 views
Grumpy Gamer 2 days ago

Tomorrow Never Came

Here is a movie I made with my friend, Tom, back when I was 15 or so. We were sure we’d be the next George Lucas or Steven Spielberg. Little did I know a few years later I’d be working at Lucasfilm and Steven Spielberg would call me up for hints on Monkey Island. He couldn’t use the 1-900 number like everyone else. The movie has sound, but it was lost when it was transferred to VHS and this goofy music was added. In case the Smithsonian wants to preserve the movie as historically important, here is the link.

movies Movies entertainment Entertainment
0 views