bluehatbrit

This is super nice, and I'm a big fan of the detailed readme with screenshots.

I'll definitely be trying it out, although I do have a pretty nice setup now which will be hard to pull away from. It's ansible driven, lets me dump a compose file in a directory, along with a backup and restore shell script, and deploys it out to my server (hetzner dedicated via server auction).

It's really nice that this handles TLS/SSL, that was a real pain for me as I've been using nginx and automating cerbot wasn't the most fun in the world. This looks a lot easier on that front!

I'm working on a library and accompanying notebooks to process secondary school exam results (UK). My father has been doing this for years for his trust and has a fantastic spreadsheet that spits out loads of data for each school.

I've recently taken a new job working closely with some data scientists so wanted to skill up a little. So far I've got an elixir library which can calculate Attainment 8 and Progress 8. They're formulas provided by the DfE to understand individual student progress, and the schools ability to progress students.

It's just a bit of fun, and is letting me experiment with some of the various elixir data libraries and livebook. At the end of it, his trust is going to plug in some anonymous data and see if they can get more insights than this mega spreadsheet.

It's also nice to be doing a side project which isn't aimed at being a business.

We have a joint daily account (called a "current account" in the UK, maybe a checking account in the US?). Both our income goes into that in full. We then have a few different types of savings which come out as soon as the income goes in. This is a more flexible "easy access" account, and more of an investment account. The investment account isn't joint purely because of how the tax shielding for them work in the UK but we both have access to them.

The remaining amount in the daily account is used for bills, groceries, and such. We also have a budget in here for various social things like dinners out and such as we do a lot of these together.

We then have an individual checking account which we both take an equal monthly allowance for discretionary spending. This is also how we buy gifts for each other for birthdays and Christmas.

I've had the "pleasure" (/s) of inheriting a pretty large GraphQL API which I've had to maintain for the past few years. I've gone through the process of the hype, and then the sheer frustration. I'm now at the point where I think most people are just using it in the wrong places.

GraphQL works pretty well when it's acting as a Backend-For-Frontend. The client can make a single call to get everything it needs at once, the BFF can then fan out to various microservices as needed. The frustrating part is when it's blindly used for something like a monolithic CRUD API with some light permissions. In that scenario you're taking all of the drawbacks, without reaping any of the benefits.

I'm really glad to be leaving this project behind as I move jobs, and I'm praying no one suggests using it in my new job. At least not until the industry more broadly understands it in more depth.

This could be great satire. The fact it's actually serious is both surprising and sad.

The point of an MVP is to do the minimal to prove viability. A waitlist gives you an iteration of that in a tiny space of time. In OP's case they failed to critisie their MVP (marketing site and waitlist) enough. But if they had, they'd have only wasted a few days.

If you go much lower, shareholders become reluctant wondering if it's really worth it, or if the board are negotiating hard enough.

If you go much higher, shareholders start to wonder why someone is willing to pay so much for a stock. People start to get cagey and wonder what's going on. The sellers interest is to keep it lower as well.

It's just the region things have settled over time. It's generally enough that the board feel they're doing the right thing, it doesn't spook anyone, and it's what the buyer is expecting.

I don't think there's any more magic behind it, it's just what has become the norm over the years.

Given the rate of change, for both UX and scams, I think it's probably best not to pre-plan. There's a very high chance you won't be able to predict the way you'll need to interact with technology in the future. Knowing how stubborn people get as they age, it's likely better to make sure your kids are generally tech savvy and find ways to learn to trust them as you get older.

They'll be better placed to keep up with everything and figure out the best path forward when we're old stubborn gits!

That would be very difficult. The ghost foundation's constitution specifically states the company cannot be bought or sold.

While I don't doubt there's some good thinking behind this, there just isn't nearly enough information for me to even begin to trust this. If I'm storing data which I might need again later I need to know, at minimum:

* Where is the data stored, and what's done to keep it safe * How / why is it so cheap, and how can I be assured the business will keep going once I've loaded data into it * What is my upload and access method? Is this S3 compatible, maybe something else? * What sort of terms are we entering into, what's the companies support obligation to me if I need my data tomorrow and there's a problem? * Do you have any existing customers, and if not why should I trust you with my data over AWS et al?

I'm sure there's some great thoughts about the business model, and probably a lot of hard work on the technical side. As a prospect customer though, I'm just seeing a price and a sign up button. It doesn't inspire any confidence to give over my email address, if anything it feels quite shady. This sort of information needs to be at my finger tips to form some level of trust.

I hope they're able to expand the information if it is a long term business venture. For all I know it could be amazing, unfortunately they're just not telling us why.

GitHub and many other sites support TOTP 2FA. These create a key which is used by an TOTP app to generate a time based code which is used. This is generally considered better than SMS codes as it's harder for someone else to hijack. There are loads of TOTP apps, Google Authenticator is a popular one, but lots of password managers like 1Password and co also support it.

I use my password manager for 2FA for low value accounts. High value ones I use a separate mobile app. I only use SMS when the service forces me to because they don't support anything else.

The risk here is of course that if your password manager is compromised, your second factor has no security value. For some cases people might be okay with that. In many cases I'm more concerned about a password being leaked rather than my password manager being compromised. For anything with significant value to me, I use a separate 2FA app though. In this case if my password manager was compromised, 2FA gives me some added security.

I don't store much stuff, so I mostly backup to AWS S3 and Backblaze (duplicated). I use Arq on windows and mac machines, and restic on linux. Job done! I'm looking at getting a NAS soon myself and then I'll backup or save to that as needed.

If you're not storing much then it's pretty cheap. For me it's mostly just photos and important documents, it comes to no more than a few 100GB total and costs me maybe 5 USD per month if that.

Congrats on your launch! It seems well designed and well thought though from a UX perspective. The landing page is also very simple and easy to wrap my head around.

I'd be tempted to use this for a small side project, but I'm not sure it has a huge draw when getting to the paid tiers. There are plenty of competitors out there and this doesn't seem to have a niche that this serves any better than them. Open source is great but I'm not sure it's a strong differentiator in this case.

I'd probably compare this to something like Plausible Analytics. They lean heavily into privacy-friendly, and easy GDPR/CCPA/PECR compliance. It being open source is what gives you confidence to use it, knowing that if the small business did disappear you can continue using the product on your own infra for as long as you want. OpenStatus seems to be trying to lean on the fact it's open source, but if their SaaS business failed it would be trivial to move to a competitor without much consideration. It's not delivering anything different, and it's not baking itself into my app or infrastructure, so moving is the case of setting up with a competitor and moving a subdomain.

I really hope you're able to make it work and get profitable though. Having high quality open source options is really fantastic, I just think it's going to take more to cement a place in the market.

Generally there's a promoter in the middle. They sign the artist and then have a deal signed with their ticketing partner. They'll then sign contracts with venues for the given tour. The contracts between promoters and ticketing agencies vary a lot depending on the country but that's how it often works in the states.

The "face value" (base price) will usually be determined between the artist and promoter, the venue will apply a fairly generic fee on top, as will the ticketing provider.

How much of the face value goes to the artist will depend on their leverage in the contract with their promoter. This is usually best improved by the confidence that the venue will sell out, meaning artists with bigger audience and social media presence will usually get the best terms.

I don't have a paper or article I can link to as a source, but I have experience in the industry.

Honestly, I don't track what I want to do, I just track what I've done. Git commit logs with reasonable detail do that just fine. I also track bugs, but nothing about future features or enhancements.

The things that annoy me the most or get me the most excited get done. Usually this is driven by users repeatedly asking for it. My lack of brain capacity acts as a natural filter to forget the things I and my users don't desperately want.

I keep a notebook as well with pen and paper, and this lets me keep details of what I'm currently doing right this moment. I then also use that for very short term todo lists, but these are mostly "get back to person X" or "send accountant Y", it's not long term planning.

Obviously this isn't always perfect or appropriate, but it's my default for personal projects and it's made me a lot more relaxed about the management side. As a result, I get a lot more done.

To be fair, the offer to rejoin Horizon has been on the table to the UK for a long time now. The UK government have been the ones dragging their heels on actually doing the work to kick off that process. Scientists like Sir Paul Nurse have been very outspoken for several years about this. That's not to say there aren't failings in the EU, there definitely are, but this is heavily on the UK.

This is a great idea, and I love that it's based on power draw. It means it can be used for all sorts of things, like a TV or lamp turning on. I might experiment with something like this for my grandmother who lives alone.

I know of small companies and charities that would use Access as their homegrown CRM back in the 2000's. It worked really well, you just needed one guy who'd be willing to set it up and they'd be good to go with the basic forms for a couple of years usually.

It's definetely not great by todays standards when it comes to backups and what not, but it was really fantastic at the time.

This is how I've done things in the past when working with VM's. It definitely works well with containers as well though. The really great benefit is you can check the new version is healthy before introducing it to public traffic, and then you can hold off as long as you want before pushing on with replacing the other nodes.

You also make sure you get a clean VM each time configured the way your IaC dictates. Obviously if your nodes hosting the application are not under IaC or for some reason you want them to be long lived, then this doesn't work as well and your model is going to the better way to go.

Great writeup and thanks for providing the code as well!

I think if I were to do this I'd probably do it the other way around. I'd introduce the new code first on a new node, add it to the load balancer, check it's healthy, and then remove the old node.

It allows a bit more growth for new functionality should it be needed. For example you can run a canary for an hour and check the error rates before promoting the deployment. Or you can rollback if the new code fails to start for some reason without needing to reload the previous application version first.

On the other hand, this works great if you want to keep the VPS more long lived by recycling it.

I think that's a little unfair given what was in the postmortem. It may not be a separate section with the key points, but the information is all there of what the issues were and what the solutions are. I think it's fair to assume they're actually acting on those without them needing to be reiterated at the bottom of the page.

If discord disappeared tomorrow, I'm not entirely sure I'd care that much. I personally rarely find myself searching back through historic messages for something.

I and the communities I interact with seem to treat it as if it were ephemeral, despite it actually storing everything. People seem to want to converse about a topic and then work on the idea that those messages will fade into obscurity over the course of minutes, days, or weeks.

The data that would be useful is really the connection with a given group of people. I'd want to be able to find them again and move somewhere else with them, but the conversations themselves I wouldn't miss.

This is of course a big contrast to other platforms though. Reddit, Stack Exchange, and similar platforms are great because they're searchable and are (or were) geared towards long term conversations and searchability. If all their content disappeared then I really would feel the impact.

That's just my usage, but I'm always surprised when people say they'd want to hold onto conversations in discord.

I managed to move into one pretty quickly after learning it and adding it to things like LinkedIn as a preferred language. There are companies out there but the pool is smaller for sure. The upside is a lot of companies using it will happily hire remote because that's the only way to get a reasonable sized candidate pool.

Every time this topic comes up I realise just how good my parents were at being parents, for me anyway. In retrospect they put a lot of effort into encouraging me to be my own person and make my own decisions, and then letting me experience the consequences. I think that helped the relationship shift over time away from parent child and towards something more equal.

I'd say it's reasonable to list it as separate outages on the status page as it's really a representation of "is github available and working as expected". Even if it is the same issue, when they manage to mitigate it (or it goes away) I'd want to see that everything is now available from a user perspective.

That said, they're getting to the point where they really need to make some larger post about this. It seems reasonable to assume it is all from one root cause.

A VPN provider who wouldn't be subject to a search warrant? I suppose only one operating from a country where warrants aren't required for a search by police, but that would presumably be much worse.

What's happened here is the best way it could possibly go. A warrant was needed which meant prosecutors / police had to meet a certain bar to conduct a search, and when the search happened the data does not exist anyway. That's exactly what you want from a VPN. This isn't "a shame", it's cause of celebration that the process actually worked and the provider can clearly demonstrate that.

I guess the only alternative would be a country which passes a law saying that VPN data (or something including VPN data) could never be searched, but that's extremely unlikely of any country at the moment.

Judging by the slides and graphs in the article, it looks like this is completely expected by Ford. They seem to be predicting an 8% margin by 2026 with a clear path way. It doesn't look like Ford is worried about it being sustainable for them in the long term.

I've been using Elixir + Phoenix professionally for a few years. The design decisions behind phoenix in particular are very much aimed at scratching this itch.

The most obvious difference between Phoenix and Rails is the leaning on code generators. You run a mix command to generate out the data models, migrations, and controller / live view and all the code is there in your project. It makes use of functions from the phoenix library, but if you don't like how something is working you just change the code. This very much removes the "magic" and makes changing the behaviour as simple as reading your code.

This was a big difference for me when I was trying out Rails vs Phoenix to figure out which direction to go in. It made the experience feel simpler as I spent more time reading standard "elixir" code and very little time reading special "phoenix" DSL code. When I was exploring rails, this dynamic felt like flipped to me.

I've been playing around with it recently on macos and Podman is still a bit hit or miss. It seems mostly to be around assumptions of permissions. I switched over to colima (which is specifically for macos) and have had next to no issues though. Hopefully podman is able to tick off those last few boxes and make it properly stable in this use case.

Same here. I just spun up a new phoenix project (mix phx.new) to mess around with some of the new pieces and this really is a brilliant release.