danjac

It would be nice to work with Elixir, having played around with it.

However every Elixir job I've seen requires Elixir experience, so I don't really see much opportunity for working with it professionally.

Regardless of whether people liked the content or not: it only employed 23 people (not sure how many were freelance or part time), and I assume it had good traffic throughout its life.

Yet it wasn't able turn a profit?

The tell-tale sign is when you hear the word "they". "Yes, I know it doesn't make sense, but it's what "they" have been asking for".

As opposed to saying, "Steve from Sales was on the call to a customer and they have this specific problem".

Would be great if they did this in gyms as well. Keep the influencer scum out so people can work out in peace.

My tendency now is to aim for over-simplicity in hobby projects. I already have to deal with over-engineered garbage at work I have no choice but to accept, so I don't want to bring those headaches home.

Particularly as Stalin himself wilfully ignored intelligence about the imminent Operation Barbarossa, for example from the agent Richard Sorge.

And he executed hundreds of capable officers in the 1930s, replacing them with incompetent yes-men, which greatly degraded Soviet defences.

In Western corporate terms, Stalin would be a boss who carried out mass layoffs of his most competent employees, ignored the threat of a competitor, and only survived due to the hard work and sacrifice of his remaining underlings, while taking credit for their work. All in all, he'd probably be quite a good modern American CEO.

Mass transit in the US is a political problem. Political problems in the US are unsolvable by design. So driverless cars it is. Meanwhile countries where political problems are not unsolvable by design (either because they are dictatorships or they don't have broken political systems) will move ahead with mass transit.

I have never, ever in my career ever seen one "thrown away". Unless the project or startup itself dies, of course.

Once something is built, and in production in the hands of end users, it is something that needs to be maintained and built on and fixed over time. It's never thrown away.

Now if you are lucky, it has been well-written and designed so that parts can be refactored over time as new features are needed and old ones deprecated. If it's shoddily built and rushed because you couldn't afford or couldn't be bothered to do it right the first time, then that's going to be tech debt you are going to have to deal with for years to come.

For anyone trying to engage with this nonsense seriously: this is just a man with a fragile ego who is annoyed that the public no longer take his brand seriously after the collapse of crypto and other SV-adjacent grifts and wants to keep his latest AI grift going on as long as possible.

Honestly reads like an essay written by a 15 year old who has just got introduced to Robert Heinlein and Ayn Rand.

Legally perhaps, but firing people particularly en mass is hard to do right, unless you don't care and you are just prepping for a fire sale.

You can lose people who might be key contributors. You can destroy morale in the rest of the company. Everyone else knows they might be next, so they will leave first chance they get. Finally, it signals to the market you are in trouble (hence why a lot of companies are doing it now: better to be just one more company doing layoffs when everyone else is doing it).

Bandcamp has (or had) 118 people. Their business is music, not a chat app, so it will have different needs, both technical and non-technical. Maybe their engineering team is slightly larger than WhatsApp, but not by orders of magnitude.

Now maybe their business model was flawed (I heard it was profitable, but perhaps not profitable enough). But otherwise 118 people for a global brand-recognized business is pretty lean already: I have worked for medium sized businesses around the same headcount you have never heard of, which don't even operate outside their home country.

That's all very well, but the average person does not have the money to spend on well-crafted furniture. At the end of the day, they need somewhere to store their stuff and a cheap chest of drawers does the job. Ethics about buying choices are for people with money and will make zero difference in the grand scheme of things. Maybe that chest of drawers falls apart after 5 years instead of 20, but that's not going to sway a person who just gets by financially.

If you hate globalisation, then maybe that can be tackled with better legislation, improvements in working conditions and standards of living, and other systematic changes. It's not going to be changed by lecturing poor people on the ethics of buying cheap stuff.

From the article there is no detail of what problem they were solving, just "we used tech stack A, we ran into issues, so we went with tech stack B". So I have no idea whether MongoDB was a good choice to begin with, or not, or whether the problem needed a relational database or not. Or for that matter GraphQL or AWS Lambda.

I do get the feeling they went YOLO and built their solution on an over-engineered approach with a stack they were unfamiliar with, and when they hit problems, they YOLO'd into another solution without properly evaluating why, which feels like a team of junior developers run amok.

They also seemed to not really understand relational databases, and why foreign keys are kind of important when you are choosing a relation database implementation (yes you can do without them, but it's best to understand them first).

Maybe they should take one of their courses.

Again, not an area I know much about, but: there are going to be hundreds, if not thousands, of medium sized legal firms in the US handling, say, criminal defence.

They can't be that different from one another that they would require bespoke software, other than an off-the-shelf solution for criminal defence lawyers? Or is there sufficient difference e.g. state to state that this would never work?

By opinionated, do you mean buying specialized off-the-shelf CRM solutions for a specific industry? For example, if the customer runs a legal firm, they should buy a CRM with functionality targeted towards legal firms?

Was it Kekkonen who said that the Finnish economy is like a chair, and two of the legs are made of wood?

The forestry industry is still a big player, especially with the recent disconnection of Russia from the world economy. Biofuels may play a part in that. But not sure it's a big enough differentiator these days.

The country is well-educated, however it suffers from the same problem as much of Europe: not enough young people to support a growing retired population. That retired population is also more conservative leaning and doesn't want more immigration, yet Finland needs more skilled immigrants. Again, a common European story of an older voting base who want to live off the fruits of other peoples' labour (whether as recipients of government largesse, or as landlords on their property investments) but do their darnedest to make it harder for that labour to make those fruits.

One thing I love when going on holiday is paying the equivalent of a hotel for the privilege of doing my own dishes and cleaning the place afterwards.

And having to sneak out the guiltily because you know everyone else in the apartment block hates the owner for turning their apartment into an Airbnb without their consent.

What's not to like?

Alpine is just used for pure client lightweight interactions, such as toggling a menu (if CSS was insufficient) or (in this case) handling the audio player controls. Of course, I could even go more lightweight, and just use vanilla JS in such cases, but as both libraries are pretty small anyway it was easier to manage client DOM interactions with Alpine.

There's no JSON in this site: the only pure non-HTML interaction is a "ping" where the audio player posts the latest play time of an episode every few seconds while running, so that if the user switches to another device, or closes the tab, they get the latest runtime of the last episode they were listening to.

In terms of performance, I found there wasn't much difference between this approach and an SPA. For example, if I navigate from page A to page B in a React app, I still need to fetch JSON or GraphQL data for that new page, perhaps including multiple round trips to the server depending on the API design. With HTMX, I can just fetch a small HTML snippet: for example, if I click a "Subscribe" button, it just returns some new HTML showing "Unsubscribe" and updated URL or whatever. Sure you can do that with plain Alpine, but HTMX makes it easier to reason about state, which I'd need to otherwise manage client side (e.g. keeping a tally of all my subscribed podcasts).

HTMX also provides solutions for things like updating state in multiple places: for example you if you have a shopping cart, and you want to update not only the cart itself but a counter widget in the navbar, you can do "out of band" responses that can insert snippets of content outside the main target. Again, totally doable with Alpine, but more work for me.

And not every interaction has to be a server round-trip, you can certainly push work to the client side if needed, and use Alpine or vanilla JS or even React if you want: in a work project for example, we had most of the site in HTMX, but used React for a dashboard page with lots of complex interactive graphs and whatnot.

As I said, it was a pretty simple app, certainly not as complex as Spotify. But given that the often repeated example of when to use an SPA is "running an audio player while navigating around the site", it makes me wonder why the need to reach for React or other SPA framework for even simpler needs.

I built a podcast library/player[1] using HTMX and Alpine, using Django as the backend. It has an audio player that would stay open and keep playing while the user navigates around the page. This is quite easy to do with HTMX.

It's pretty simple - it's just for my own needs - but it works quite well. You can go far these days before needing an SPA.

[1] https://github.com/danjac/radiofeed-app

That's about as silly a measure as number of lines of code produced.

That appears to be an iceberg problem. While the public UI of Twitter is simple and is often used as the basis of a starter project in training courses, there's also likely to be a lot of backend admin tools for things like moderation, advertising, sales, etc (not to mention as others have the scaling: at this level it's not so much a "solved" problem but one that requires constant monitoring, tweaking, and preventing newly-minted CEOs from literally pulling the plug on running servers).

Isn't this basically how Mithril works?

Altruistic to whom? How many big companies with turnover in the millions rely on the unpaid work of volunteer open-source developers?

Even today, English is still not an official de jure language of the United Kingdom, although Welsh is.

Maybe the best way is to avoid these consultancies altogether and create a government digital agency (whether at local or national level). Motivated and well-trained civil servants familiar with the bureaucracy and terminology who can maintain and improve services in the long term. The UK .gov project seems to point the way.

I use Dokku for side projects, where I don't expect high traffic, I'm the sole developer and I don't want any unexpected invoices I might get from a cloud provider.

You can run it on top of a single cheap VM, for example Digital Ocean or Hetzner, for a few dollars/euros a month. It is compatible with a lot of Heroku buildpacks e.g. PostgreSQL and Redis, has a similar CLI, and includes plugins for things like LetsEncrypt that can be installed with a couple commands. As with Heroku and other PAAS you can deploy with a simple git push.

It's absolutely fine for the MVP stage of a more serious project, but it's not really meant for scaling out beyond a single server. I mean sure, it's possible, but there are better tools for the job, and at that point you should have a bigger budget/team.

While there are definitely developers who are enthusiastic about microservices for all the wrong reasons (e.g. it looks good on the resume) I think it's more about how companies deal with complexity.

Companies don't just ship their org chart, they ship all their dysfunction and historical baggage. A beautiful, well-architected platform from 5 years ago, with an efficient, thought-out data model and API and well-written and tested code, might be a total mess after 5 years of constant pivots from the CEO, last minute customer requests the sales team have pushed through, product managers doing their hydrant-meets-dog act of adding features nobody needed or asked for, and never enough people and time to do as good a job as the developers would like.

One day you wake up with a big pile of tech debt and fixing bugs and adding features takes way longer than it should, and microservices are that siren call that promises a solution that doesn't involve burning the whole thing to the ground and starting over.

Moreover success depends on factors that may be tangential to the quality of the project. I have had more Github stars from low-quality "throw over the wall" projects that just happened to use whatever framework/language was cool at the time, as opposed to projects that I have put more effort into but used more "boring" technologies. As with a startup, if you catch the wave at the right time, you can succeed with a relatively low quality/effort project.

But that depends on what counts as "success". If you are looking at just money or Github stars (or whatever the equivalent is in art or music) then that's one measure, but success could mean learning, personal satisfaction, something that helped or inspired someone else, the praise of a few people you look up to, or a job opportunity.

There's a happy medium. Even a startup can do with some well-maintained READMEs. But the problem with startups is churn, which makes for docs that rapidly go out of date, and the only thing worse than no docs is out of date docs that lead you down the wrong path.