Re: Alternatives?
Pythonanywhere is heartily recommended by one of my customers as a Python-specific PaaS; I am planning on trying out render.com myself.
19 publicly visible posts • joined 15 Aug 2016
Heroku was the first mover, but there are arguably better alternatives out there these days, such as Pythonanywhere or Render. Since I will now be stopped from using the free tier for backup services, prototyping, and staging, I’m going to start migrating my projects elsewhere.
I’m of the belief that comments should be used sparingly, ie for documenting public APIs, or for explaining workarounds for third-party bugs. Code should be written so that its behaviour is self-evident; otherwise comments need to be maintained and updated as well as code. So that rules me out (I’m assuming that the service only writes code based on comments).
I just finished reading Surveillance Capitalism; which I imagine was on some internal EU reading list, and was partly responsible for triggering the EU's crackdown on personal data collection. I'm minimising the contact with Google/FB in all my software - that book convinced me that the problem is way worse than I could have imagined initially.
80 million dollars could have bought a lot of testing, but no amount of testing is going to hit every edge case. I think adding an escrow step before letting the funds clear is probably a good idea, for any time an algorithm is automatically handing out loads of cash. Plus some run-time sanity checks, to make sure that final values are within the right orders of magnitude.
Online collaboration is a commodity now, thanks to WebRTC support in the browser, and drop-in libraries for file sharing and chat. It's easy to add or find niche-specific features that large services do not provide. Look at how quickly covid pushed Zoom into everyone's app list.
I think that the second Teams starts sucking enough to provide impetus to look past the default installed option, companies will look elsewhere. Vendor lock-in and a lack of API integration options are going to make this a sub-standard offering.
I evaluated Flutter for a mobile project and passed in favour of React Native (still not perfect, but more suitable for my purposes than 2 native apps would be).
Go to GitHub and gaze in horror at Flutter's 5000+ open issues before you commit to this platform. It seems to be a case of big brands pushing something which is not mature and has not got its quality issues under control, just so they can have their own brand in a space.
For cross-platform desktop apps, I'll keep using Qt, as I have done for about the last 20 years.
It sounds like a case of "when all you have is a hammer, everything looks like a nail": going for the bad solution that they know, rather than doing a quick search online to see if there are any better options out there. Or it was a stack decision forced onto the developers by management.
For example, Qt Quick is an excellent, mature framework designed for doing secure cross-platform JavaScript desktop apps. Maybe Electron can do it properly too, without the local server, for all I know.
It's $3 per kilo in electricity prices to get a kilo into orbit - that's very expensive garbage disposal. Or will the earth become an ever-growing pile of junk?
Creating a circular economy sounds like a more viable focus.
https://space.stackexchange.com/questions/4330/how-much-energy-is-required-to-put-1-kg-in-leo
At the old Nokia, engineers could take prototypes out in public to use as our personal phones as soon as they were announced. That smoothed off a lot of rough edges in the final product.
Maybe Samsung's engineers were also testing the phones, but they had internalised some preconceptions about how to treat them (ie, "be gentle - I know how flakey this hinge is", "don't peel off the protective thing, which we know all about because we developed it").
Developers on a system like this don't have to, and shouldn't, be developing a cryptographic algorithm at the level of the actual arithmetic. They should use a proven library or framework. Many problems come when a developer is trying to be cute and tries to "roll their own" security. No developer should be developing a cryptographic algorithm for a production system unless they are an expert and it's being peer reviewed.
*Symbian, the framework* was an engineering marvel for running low-powered devices in the early 2000s. However, during the latter part of that decade, the huge Symbian company, S60, and the conflicts of interest between it and Nokia, prevented any true OS innovations from within Nokia from seeing the light of day.