• 0 Posts
  • 34 Comments
Joined 1 year ago
cake
Cake day: July 1st, 2023

help-circle





  • This is great, honestly.

    If you go back to antiquity, education was about philosophy. It was about learning how to observe, and think critically, and see the world for what it is.

    And then in modern times, education became about memorisation - learning facts and figures and how to do this and that. And that way of teaching and learning just doesn’t fit any longer with what our digital age has become.

    In my opinion, we are heavily overdue for a revamp of what education should be, and what skills are most important to society in this post-truth world. Critical thinking is an important foundation to real knowledge that we don’t teach enough.







  • Any company that hides their documentation has an awful product that they are actually embarrassed about, from a tech perspective. They are hiding it because they are afraid to show it.

    I’ve seen this so many times, and it’s a big red flag.

    These companies work on the basis of selling their product the old-fashioned way, directly to management with sales-people and business presentations and firm handshakes, and then once you’re sold then developers (which management doesn’t care about by the way) have to do the odious task of getting everything working against their terrible and illogical API. And when you need help implementing, then your single point of contact is one grumpy-ass old dev working in a basement somewhere (because they don’t care about their own devs either) and he’s terribly overstretched due to the number of other customers he’s also trying to help, because their implementation is so shitty.

    Conversely, public documentation is a great sign that companies took a developer-led approach to designing their solution, that it will be easy to implement, that they respect the devs within their own company, and they will also respect yours.

    When I am asked to evaluate potential solutions for a problem, Public docs is like the number one thing I care about! It’s just that significant.

    Side story - I once worked with one of these shitty vendors, and learned from a tech guy I’d made friends with that the whole company was basically out of office on a company-paid beach holiday - EXCEPT for the dev team. Management, sales, marketing, finance, they all got a company trip, but the tech peeps had to stay at home. Tells you everything you need to know about their management attitude towards tech.



  • There are lots of reasons why governments might desire to get rid of physical currency.

    1. Crime - Physical money is the option of choice for criminals as it allows them to make off-record transactions so their activities are hard to trace

    2. Tax - When otherwise legal business is conducted in cash, it’s possible for business income or employee pay to be undeclared or underreported, meaning the government is losing out on tax revenue. This is huge, and the gov really wants their slice of that cash.

    3. Manufacturing and distribution - A minor point, but it is expensive to make physical currency, as well as to keep improving it to prevent forgeries and such. Getting rid of physical currency removes this problem.

    I’m sure there are other reasons but those are what came to mind.

    Despite these factors, any move to a fully cashless society is controversial, because not everyone is in a position where being fully digital is feasible. It has the worst effects on those who are already marginalised and disadvantaged in society, like the homeless, who may not even be able to open a bank account.

    So I think it will be quite a long time until it might happen.


  • It’s good practice to run the deployment pipeline on a different server from the application host(s) so that the deployment instances can be kept private, unlike the public app hosts, and therefore can be better protected from external bad actors. It is also good practice because this separation of concerns means the deployment pipeline survives even if the app servers need to be torn down and reprovisioned.

    Of course you will need some kind of agent running on the app servers to be able to receive the files, but that might be as simple as an SSH session for file transfer.



  • That’s probably okay! =) There’s some level of pragmatism, depending on the sort of project you’re working on.

    If it’s a big app with lots of users, you should use automation because it helps reliability.

    If there are lots of developers, you should use automation because it helps keep everyone organised and avoids human mistakes.

    But if it’s a small thing with a few devs, or especially a personal project, it might be easier to do without :)


  • Sure, but having a hands-off pipeline for it which runs automatically is where the value is at.

    Means that there’s predictability and control in what is being done, and once the pipeline is built it’s as easy as a single button press to release.

    How many times when doing it manually have you been like “Oh shit, I just FTPd the WRONG STUFF up to production!” - I know I have. Or even worse you do that and don’t notice you did it.

    Automation takes a lot of the risk out.


  • I’m sure there’s nothing wrong with the program at all =)

    Modern webapp deployment approach is typically to have an automated continuous build and deployment pipeline triggered from source control, which deploys into a staging environment for testing, and then promotes the same precise tested artifacts to production. Probably all in the cloud too.

    Compared to that, manually FTPing the files up to the server seems ridiculously antiquated, to the extent that newbies in the biz can’t even believe we ever did it that way. But it’s genuinely what we were all doing not so long ago.