I love the fact that the author "wrote" this page with massive CSS framework (tailwind) and some sort of Javascript framework, with a bundler and obfuscator - instead of a plain, simple HTML page. Well played! :-)
This is less an example of why serverless was bad but rather an example where using non-suitable services for tasks they were not meant for.
In this case they were using AWS Step functions that are known to be expensive ($0.025 per 1,000 state transitions) and they wrote:
> Our service performed multiple state transitions for every second of the stream
Secondly, they were using large amounts of S3 requests to temporarily store and download each video frame which became a cost factor.
They had a hammer - and every problem looked like a nail. In my experience this happens to every developer at a certain stage when he/she gets in touch with a new technology; it doesn't mean that the tech itself is bad - it depends on the scenario, though.
Having a good keyboard is important (not only for ergonomics, but also for efficiency) in our business. But I find I'm having difficulty when temporarily switching from US to DE keyboard layout, or when using a mac (vs linux) - so what would using a completely custom keyboard do to my general computer user ability?
This is why I never considered buying one of these...
> Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?
The standup would be the safety net when people don't see that they're stuck, know what to do and are afraid to ask / hands down in smth they just don't see the obvious.
Uncovering this in a standup should prevent them from "wasting time" even longer.
I have rarely seen this in my experience so far; either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.
By being able to modify executable files on the webserver, an attacker can add a backdoor through a security hole quite easily. Without, he could just make use of the security hole as of itself.
> A comprehensively secure automatic update system would have process isolation between the normal web interface and the updater (and the latter would run as a different, more privileged user). However, not everyone can do that. (Shared hosting, etc.)
That's right, and I also think the popularity stems from the simplicity and the fact that it existed when the whole blog thing took off.
There's actually the option to provide your FTP credentials in the admin console and have wordpress update itself over an FTP connection. It is process separation, then, but OTOH potentially exposes your webspace credentials to an attacker. :-)
The update mechanism itself is still insecure, as the wordpress instance must have the ability to exchange its own source code - something you'd at least call risky. Web applications should run with the least possible privileges, ie. only with permissions to write to dedicated locations on the filesystem (user uploads), and read permissions for the code.
PHP has composer, a dependency management system. There's an option to build a wordpress project using composer.
Even more, there's even a boilerplate project that you can use to bootstrap your new wordpress setup - see https://roots.io/bedrock/
I am a (happy) user of homeshick (https://github.com/andsens/homeshick), but this project really seems to top it by providing the only feature that I've missed until now:
- use the same source file with different results for different machines (eg. .gitconfig for home and office machines)
- option to store secrets in a credentials database and extract them from there (because you wouldn't want to store them in a git repo - even if it's a private one)
This is an unsolved problem; some people work around it by managing multiple twitter accounts, one for each "channel". It doesn't scale by topics, though.
OTOH if I have to think about which channel / user I tweet to, I think people would tweet less. A bit of noise is ok, I guess.
There's a fork called homeshick which is a plain-bash rewrite of homesick, so it doesn't have the ruby dependencies (for those who care about that). There might be few differences, though.
It needs to be sourced in .{bash,z}shrc and has features like tracking files from multiple repos (so called "castles"), auto-linking, auto-update every X days.
We also use it in our dev team to share some config (and ~/bin) files, works fine.
Just my pick. Indeed, I've found links there that haven't popped up anywhere else (HN, Twitter), so I second the original poster's opinion that mail newsletters are a good thing - wouldn't have thought that.
I wonder why it wasn't possible to restart the mistakenly shut down engine. The article states that in first seconds after the shutdown, the pilots were unaware of their mistake. They then noticed the plane stopped climbing and actually went down even when pulling up the nose (which is counterproductive in that situation).
How long would it take to restart an engine and gain speed again?
As I work on quite a big directory tree, where most of the repos are in just a few parent directories, I like using the CDPATH variable that is present in at least (oh-my-)zsh and bash(-completion) (IIRC).
That would auto-update when new directories / repos are added later - maybe a useful addition to your tool?
I need to agree. Using XSLT to write a XML -> HTML website is not a good idea - at least when a bunch of developers maintain it over time.
From the ground up, I admit I like XSLT. But: maintaining large sites that inherit templates (call-templates and apply-templates) and style through <xsl:include/> and <xsl:import/> over lots of files tends to become a template mess. After a while only the experienced devs are able to maintain the templates.
Then, it's a functional language, where lots of things are overly complicated to do; you can do just everything, but that doesn't mean you should.