Or don't. I've done both, published OSS projects and sold some software. The level of entitlement in some comments I received on the OSS side was pretty crazy at times. While with the paid software, all of the interactions I had were so much more constructive. YMMV, but willingness to pay is a great filter.
While I somewhat understand the impact on the craft, the agents have allowed me to work on the projects that I would never have had enough time to work on otherwise.
> Do you have any examples or resources that worked well for you?
Using this particular example, if you simply paste the exact code into the prompt, the model should able to reproduce it. Now, you can start removing the bits and see how much you can remove from the prompt, e.g. simplify it to pseudocode, etc. Then you can push it further and try to switch from the pseudocode to the architecture, etc.
That way, you'll start from something that's working and work backwards rather than trying to get there in the absence of a clear path.
If you've got some time, I highly recommend going through the exercise of trying to change the prompt in a way that would produce code similar to what you've achieved manually. Doing a similar exercise really helps to improve agent prompting skills, as it shows how changing parts of the prompt influences the result.
What's incredibly ironic is that research labs are releasing the most advanced hacking toolkit ever known, and cybersecurity defence stocks are going down as a result somehow. There’s no logic in the stock markets.
In Theory There Is No Difference Between Theory and Practice, While In Practice There Is.
In large projects, having a specific AGENTS.md makes the difference between the agent spending half of its context window searching for the right commands, navigating the repo, understanding what is what, etc., and being extremely useful. The larger the repository, the more things it needs to be aware of and the more important the AGENTS.md is. At least that's what I have observed in practice.
Great article! Just yesterday I watched a Devoxx talk by Andrei Pangin [1], the creator of async-profiler where I learned about the new heatmap support. To many folks it might not sound that exciting, until you realise that these heatmaps make it much easier to see patterns over time. If you’re interested there’s a solid blog post [2] from Netflix that walks through the format and why it can be incredibly useful.
Definitely not the first AI generated font. One can find an enormous amount of research in AI font generation on https://scholar.google.com/ going back many years. This could possibly be the first one that used Nano Banana though, and the result is impressive for sure!
I believe there is no contradiction with the definition from the linked article?
> A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:
> Hard – missing a deadline is a total system failure.
> Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
> Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.
The highest level of cringe you can feel is when you see people you know well in real life post on LinkedIn. The contrast between the way they speak in real life and on LinkedIn is often immense, you don't feel that level of contrast with random internet strangers.
> Isn’t not that they’re “not perfectly accurate”, it’s that you can find half an order of magnitude of performance after the profiler tells you everything is fine.
> That’s perfectly inaccurate.
That's a very strong claim, and it's not true in my experience as I've showed above.
> Let me save you fifteen minutes, or the rest of your life: They aren’t.
Knowing that all profilers aren't perfectly accurate isn't a very useful piece of information. However, knowing which types of profilers are inaccurate and in which cases is indeed very useful information, and this is exactly what this article is about. Well worth 15 minutes.
> And that often involves ignoring the fancy visualization and staring at the numbers.
Visualisations are incredibly important. I've debugged a large number [1] of performance issues and production incidents highlighted by the async profiler producing Brendan Gregg's flame graphs [2]. Sure, things could be presented as numbers, but what I really care about most of the time when I take a CPU profile from a production instance is – what part of the system was taking most of the CPU cycles.
> So yeah, why expose it to those who are not the "main customer"?
How did modules affect you as a user? I'd guess that you had to add `--add-opens`/`--add-exports` during one of the JDK migrations at some point. And the reason you had to do it was that various libraries on your classpath used JDK internal APIs. So modules provided encapsulation and gave you an escape hatch for when you still have to use those libraries. How else would you do it while still achieving the desired goal?
My read is that it's easy to be quite negative on Java features when you're not the person they were designed for. For example, the main "customer" of the module system is the JDK itself. The main customer of NIO/2 is the low-level libraries like Netty.
I highly recommend the Growing the Java Language talk by Brian Goetz to anyone who's interested in the philosophy behind evolving the modern Java language [1]. And Don’t be misled by the title, it’s not just about Java, it’s about software design.
What this post might be missing is that it’s not just Google that can block your website. A whole variety of actors can, and any service that can host user-generated content, not just html (a single image is enough), is at risk, but really, any service is at risk. I’ve had to deal with many such cases: ISPs mistakenly blocking large IP prefixes, DPI software killing the traffic, random antivirus software blocking your JS chunk because of a hash collision, even small single-town ISPs sinkholing your domain because of auto-reports, and many more.
In the author’s case, he was at least able to reproduce the issues. In many cases, though, the problem is scoped to a small geographic region, but for large internet services, even small towns still mean thousands of people reaching out to support while the issue can’t be seen on the overall traffic graph.
The easiest set of steps you can do to be able to react to those issues are:
1. Set up NEL logging [1] that goes to completely separate infrastructure,
2. Use RIPE Atlas and similar services in the hope of reproducing the issue and grabbing a traceroute.
I’ve even attempted to create a hosted service for collecting NEL logs, but it seemed to be far too niche.
I own a 12 mini, and I'm planning to upgrade my phone this year, it's time. If there were an iPhone 17 mini, I'd buy it, but because there isn't one, I'll probably go for the Pro to get a bigger battery. Apple knows that many folks like me would buy a cheaper mini if there were one, and not spend as much on Pro.