• 1 Post
  • 285 Comments
Joined 2 years ago
cake
Cake day: June 19th, 2023

help-circle
  • Nah, cos the way the self driving thing will be structured will make it pretty much impossible to actually buy one - they’ll be crazy expensive to buy outright, but you can absolutely lease one - oh but if you are using it for commercial purposes it’s more expensive cos… insurance or something, oh and don’t forget the per-km fees, and the servicing fee, and the battery wear fee, and …


  • Yeah, doordash can gdiaf. Local burger joint only does delivery through doordash, but adds 20% on top of the base price to cover the fees doordash change them (fair enough), then doordash adds the delivery fee they charge me on top of that as well. They double dip on fees by changing both the restaurant and the customer, what should be a fairly affordable lunch when I don’t have time to make something or go out and get it myself would end up being stupid expensive












    • https://github.com/prometheus/node_exporter?tab=readme-ov-file#textfile-collector - which makes node exporter watch a specific directory for files that contain metrics, then re-export them back to the central Prometheus server
    • Some systems have their own metrics endpoints - instead of getting Prometheus to scrape these directly I set up a Cron job to curl these into files for node exporter - this means I don’t need extra config in Prometheus to find the endpoints, and don’t need to mess with firewall rules
    • Other systems don’t directly expose metrics in a format Prometheus can use - in this case I will write/find a script that can do the conversation, then either set it up to write the metrics file directly and run it on a Cron, or run it as a service and another Cron job to do the scrape


  • Bit of a rambly story, but I swear it is relevant.

    So previously I worked as a consultant for a company that manufactured a relatively small number of high value (tens of thousands of dollars each) Gizmos in a lightly regulated industry - the requirements weren’t too crazy, basically that everything has a serial number and they can prove that any given serial passed the full range of tests before it left the factory. Pretty much the sort of thing you’d want to have if you gave a crap about quality products anyway.

    Initially they were using Excel to keep track of this - they manufactured 10 units a week, it worked well enough. Eventually, they got more successful and needed to scale up to 50 units a week, and it was decided that they needed A System to keep track of testing and manufacturing. Their head of manufacturing “looked around and couldn’t find anything off the shelf that was suitable” (ie, cost $0, and perfectly matched his aesthetic tastes; mistake #1), so they decided to build their own system.

    They had a few in house developers, but they were focused on building new features (things that drive sales, unlike maintaining their reputation for delivering reliable products), so head of manufacturing decided to get one of the production line techs (who was “good with computers” by virtue of having built the Excel system, but was not a software developer mistake #2) to do it.

    Eventually, they decided to use Microsoft PowerApps to build the new system - for those with the good fortune never to have seen PowerApps, it’s essentially a “no code required” drag and drop UI tool that you script using Excel formulas. Think Visual BASIC or Scratch, but Cloudy.

    On the surface this made sense - the developer was proficient in Excel, so use what you know. Unfortunately, PowerApps is designed to rapidly build throwaway UIs over simple data models and lacks some of the things that actual software developers would have thought to ask about:

    • It lacks real version control - you can “undo” a deploy, but there is no way to discover what changed between versions, or do branches, or code review
    • Because you can’t effectively manage changes to the system, you can’t do pre-production releases
    • Its native database system doesn’t do referential integrity
    • There is no straightforward way to do any kind of locking - and because there is no referential integrity, it’s really easy for concurrent users to really mess up the data
    • There is no way to do automated testing
    • The development group could have actually documented how stuff worked, requirements, specs etc but didn’t, so any time there was any issue you had to play the game of “is this a bug or bad design?”

    Eventually, these chickens came home to roost in the form of a defect that slipped through testing that they then couldn’t isolate to a particular batch because none of their testing data could be trusted. I was brought in to try and unpick this mess and advise on a replacement system, but between the cost to fix the issue and the lost sales from it they ended up in a pretty bad spot financially and ended up being acquired by an investment group.

    Anyway, the takeaway from this is that you disregard experience and judgement at your own peril, up front savings generally don’t manifest in the long term and I expect there is going to be a thriving market of consultants brought in to point and laugh at companies that decided that a bunch of cheap, inexperienced developers and a magic talking parrot would build better software than cheap, inexperienced developers being guided and upskilled by an experienced senior developer


  • The thing people don’t really get about “bullet proof armour” is that it’s job is to stop the bullet going into you and messing up your fragile internals - but Newton still wins. The force still has to go somewhere.

    Imagine someone held a stake to your chest then someone else smacked it with a sledgehammer - this would be a Very Bad Time for you, what with all the bleeding and internal trauma. If instead someone held you down with a steel plate and that was sledgehammered with the same force - it would hurt like hell, but probably not do the same amount of internal damage because the force is distributed over a wider area. There is of course a limit - at some point the force is still going to be too high and cause fatal damage.

    Helmets work the same way - the internals of your head are very fragile, so keeping the bullet out is pretty important, but the same problem exists. The force has to go somewhere, and while getting whacked in the face with a sledgehammer is better than having a stake driven into your forehead it not that much better