webprofusion

Actually knew someone who didn't make it, after (presumably) using the hyperventilation technique. Such a senseless way to go.

Love extreme engineering.

Where it really does open your eyes is when dealing with stuff you just wouldn't have done otherwise: - Can't remember the name of that web tool you used to base64 decode locally, just ask for one. - Would love to have a quick tool that does X: done. - Wouldn't know where to start building a C++ VST plugin for audio processing: done - Point it an a protocol RFC and get it to generate an API implementation stub: done (that one went from "maybe one day", to "shipped" simply because the initial donkey work got done by AI.

I think currently once you get into the weeds of a project the AI can only really lend a helping hand, rather than do 30-50% of the work.

It can kickstart new projects to get over the blank page syndrome but after that there's still work, either prompting or fixing it yourself.

There are requirements-led approaches where you can try to stay in prompt mode as much as possible (like feeding spec to a junior dev) but there is a point where you just have to do things yourself.

Software development has never been about lines of code, it has always required a lot of back and forth discussion, decisions, digging into company/domain lore to get the background on stuff.

Reviewing AI code, and lots of it, is hard work - it can get stuff wrong when you least expect it ("I'll just stub out this authentication so it returns true and our test passes")

With all that in mind though, as someone who would pay other devs to do work I would be horrified if someone spent a week writing unit tests that I can clearly see an AI would generate in 30 seconds. There are some task that just make sense for AI to do now.

I couldn't find a simple web based visualizer/screensaver-type-thing for my audio, so here you go. PRs welcome.

It took me about 20 years of normal employee/contractor office work alongside creating a side project every few years, to eventually find the side project that would take off.

In the end it was a weekend hack to make something simpler that turned into an app release, which a year or so after that turned into a business.

Sometimes people have a great idea, build it and feel entitled to success with it, but it's largely about relevant eyeballs. If enough relevant eyeballs find your thing and use/buy it then it's a success. It's quite easy to launch something that gets lots of views on launch, but there has to be a reason to come back (sticky apps/content).

I've also built several things that could have been good but I lost interest and ironically the thing I work on now is arguably one of the most boring topics conceivable, but perhaps that's why few people do it well.

Took a while to find the Hello World. It looks like a sort of oop python.

Thought that as well.

I don't agree with a ban, but burning crude oil (are you sure about that, it's usually refined at least a little?) can have centralised carbon capture and filtration, whereas cars pretty much just pump it straight out. Luckily they made the smoke invisible so it's ok, almost like it's not even there!

I don't think banning combustion engines is fighting the right battle, but incentivizing the alternatives (e..g lowering or removing sales tax) is a good idea.

We don't actually want to scrap working cars unless they have reached the end of their life or passed an air quality threshold (UK tests every car over 3 years old, every year, called an MOT). Reduce, reuse, recycle etc.

Mine did more than 25,000, just get better tyres. The basic premise is that EVs are heavier and have more torque than average cars, but it's a 20% difference in real life, so your tyres may last 20% less.

Would love to see the prompts used. I can tell from the formatting etc this is AI built, nothing wrong with that.

Close but no cigar, if you're trying to achieve VB like hunt and peck productivity then XML doesn't cut it any more now than it has in the last 30 years or so.

Blazor is pretty productive if you're looking for a mature component based XML (Razor) syntax but again, there is no Visual design element to throw thing together.

How much of this is AI tools pretending to be users? If they use a real browser instead of identifying as a crawler then it's going to skew the stats.

This is deeply incorrect. Code is not and never will be a requirements specification.

Probably a couple of hours on support per day on average, some days less, some days more. The vast majority of users don't ask for support, they prefer to read the docs, read the community forum, goggle stuff or hunt-and-peck options in the app. Roughly 90% use the free version. If everyone used the paid version I could have a very large team, but the reality is the product competes with many free tools.

If you update the app or refine docs in response to previous support questions it does streamline the experience but there are always folks who just don't read docs and there are many who will purchase the app just for access to support so they can figure something out.

I'm sure some apps are more support heavy than others, but ours is aimed at system administrators and with that comes an assumed level of competence (in reality, many people are only in the role because nobody else could/would do it but even they are quite independently resourceful).

The disadvantage of users helping themselves is that you don't get feedback from them or learn about their use cases. Knowing how/why people are using your stuff is really valuable for development, so if I had the team for it then dedicated support engineers would follow up with customers early on even if they don't have issues.

This is nice, my main criticism would be that it uses the language "easy" and "simple" regularly which is a classic mistake in any instructive text (including docs etc).

If the reader was feeling a bit dumb and/or embarrassed that they didn't yet get the concept being explained then this will only make them feel worse and give up.

Language like that is often used to make things feel approachable and worry-free, but can have the opposite effect.

And never ever, ever write "obvious" in a doc explaining something, because if obviousness was at play they wouldn't be reading your doc.

Always encouraging to see that ideas can work out. I'm not quite managing the "let's build a team" aspect just yet but otherwise similar journey and outcome over a (slightly) longer period.

I just wanted to not deal with certificates, now I deal with certificates all day every day lol: https://certifytheweb.com

Purist ideas rarely survive contact with reality, or something.

Likewise if the founders of the web took one look at a full on React based site they would shriek in horror at what's now the defacto standard.

The basic idea is that you can continuously document what your system should do (high level and detailed features), how it should prove it has done that, optionally how you want it to do it (architecture and code style etc).

The multi-model AI part is just the (current) tool to help avoid bias and make fine tuned selections for certain parts of the task.

Eventually large complex systems will be built and re-built from a set of requirements and software will finally match the stated requirements. The only "legacy code" will be legacy requirements specifications. Fix your requirements, not the generated code.

People who make a strong distinction between TLS and SSL are indicating that they know the difference and think you should too, but at a practical level it's the difference between .doc and .docx (fundamentally different but interchangeable to the layman). The boots on the ground mostly care about getting https to work and have minimal consideration for it's inner workings.

Excellent, I think you took my comment in the spirit it was intended, nobody else did :) - aesthetics is a form of marketing but nobody outside your project is invested in your marketing in the same way you are. Good luck with the future!

Lol, the devs agreed with me. They don't want it to get lost in the sea of toy operating systems either.

I was really hoping this article would have lots of cool pictures.

Impressive, but.. start with how it should look, don't make that an afterthought.

Hobby operating systems have one thing in common, they all have a great logo but look like a late 90s linux desktop. Windows decoration and fonts look like they were hacked together last night.

Instead start with a visual design and work backwards. You'll get instant appreciation from your audience. Unless the aim is to basically get SSH working and compile a bunch of gnu tools for a basic shell, in which case knock yourself out but don't be surprised when everyone ignores your work.

This come across as snark but it's frustration at the wasted effort and that good work will go unnoticed.

Oh the problem is that this "R/T" is the "entry level" model and everyone is buying the other one.

You mean they put all that effort into convincing their customer base that EVs were a fools errand and now when they try to sell one nobody wants it? Hmm, I can't understand that.

If it had a BYD badge it would sell in the millions.

Agree with the idea but does anyone else find the text really hard to read? Not sure if it's the font or writing style.

Stick your site behind cloudflare, you'll get geographically distributed caching for free. It's currently very slow as if you are serving it from your basement.

Great stuff - I built a web based protein model viewer in 1997 (maybe 96), it used VRML for the 3D view and queried a database called SRS.