In EU (and probably elsewhere), there are strict rules for the stability of power wheelchair. One such rule is "On a incline of x% (x chosen by the manufacturer), pushing for max speed from stop should not lift the front wheels"
To achieve that, the max acceleration must be quite low (software controlled), and the whole experience is sluggish, like trying to steer a car by pulling on rubber bands attached to the wheel.
From the moment I found a way to overcome this, I never went back. I know that I can hurt myself if I do something stupid, but I prefer this hypothetical risk instead of cursing 100 times a day because I cannot move how I want. It has been 10 years and I never got hurt.
I understand that such "high" risk device cannot be sold, but forbidding someone to change this is like inflicting a second handicap on him.
I suppose we all have, or should have, the right to try stupid things. Sometimes experience and competence are more important than 100% safety. Your comment made me realize how limiting it would be to be physically incapable of taking even the smallest risk.
That is a very poor regulation. Why enforce wheel lift? What matters is that the chair doesn't tip over - that the center of gravity remains in the center of the four wheels.
These shenanigans before displaying the final result can have quite a lot of psychologic effects.
Back when I started programming, I did simulate a jackpot machine in software (no money involved). The final probabilities were fair, but I added a twist while rolling the images: before stopping, the probability of having 2 or 3 of the same image was quite significant...
My younger brother was instantly hooked to it. The trick made him overestimate the probability of having 3 images the same, as he was seeing this pattern quite often just before stopping.
This made me realize of fucked-up casino can be, while still abiding by the rules
On the other hand, rebasing can create its own problems re: regression finding
If you rebase more than one commit, you can also have an intermediate commit which does not run fine, or even compile. This can happen silently, without conflict resolution while you rebase. Think a function call in trunk needs one additional parameter.
So you have a commit message saying "Protocol X tested successfully with Y", which was true when the code done and tested. After the rebase, it might not run anymore because of changes done in the trunk. You will probably notice it and correct it in a later commit, but good luck in 3 month when someone points a bug at protocol X and you want to re-run the test in this commit...
That’s why at work we have a “commit queue” that tests that every commit builds as it comes in in the order it’s merged (or more accurately: cherry-picked). Don’t leave those things to manual checks and human vigilance. They’re too fallible.
About touch buttons, I have seen once a lift with touch buttons for controls.
For accessibility, the floor were also written in Braille. I thought to myself: "nice, they thought about vision impaired people".
Then, a friend of mine, which has completely lost vision and can read Braille, jokingly said to me when he arrived: "Trying to find the right button, I probably send the lift to all floors!"
That’s funny. And sad. Vision impaired people have really been taken by a rollercoaster with modern tech. First the touch screen which is useless (not sure if that’s the case still?). But then tech companies invested massively in voice interfaces for completely unrelated reasons, which I assume, is a godsend.
They claim a save of 400kW per sail, with a boat cruising at 22kts.
Let's do some math:
- 400kW is 400e6 J/s, or 400e6 N.m/s
- 22kts is 11.31m/s
So the forward force must be 400e6/11.31 = 3.5e7N, so around 3500 metric tons of force for a single sail.
And with a relative wind coming from the front usually, this means the side force will be much bigger than that.
Exactly my point. Not to mention transferring that load to the body of the vessel, which has a structure made to withstand loads in specific points. A container stacked on top of other containers for sure isn’t able to sustain such forces lol not even if it’s well latched. It’s just too much force. Also the ship is hollow, there are like 5 rows of containers below deck, so the deck itself is not very strong except for some points that have the mechanism for the ropes.
Good writing is clearly useful and quite often mentioned. But good reading is very rarely talked about. I think it is even more important.
Too many people cannot maintain attention for more than a few seconds while reading. Or they read "what they want to read" instead of the actual text. Like I write a "list of things" and they read it like "a set of things", loosing the meaningful ordering of a list.
I tend to write concise documentation, but people always loose some important details that way. So I am now purposefully adding more text than strictly required to be sure important points are really understood.
Like a good teacher repeats at least 3 times the same matter, with a slightly different angle
This reminds me of an old Spolsky blog post on writing specs: [0]
> Programmers often try to write specs which look like dense academic
> papers. They think that a "correct" spec needs to be "technically"
> correct and then they are off the hook.
>
> The mistake is that when you write a spec, in addition to being
> correct, it has to be understandable, which, in programming terms,
> means that it needs to be written so that the human brain can
> "compile" it.
> Like I write a "list of things" and they read it like "a set of things", loosing the meaningful ordering of a list.
That's on you. A lot of code use list instead of set purely because set is rarely a basic primitive language offers.
If I see method returning list of users I'm just gonna assume it is unordered, and it usually is unordered.
If you return list that's ordered and that matters for some reason, the docs should say it is ordered and by which key.
If the method is called RunTasks(list) and documentation is "runs a list of tasks" it is perfectly fine to assume it means "runs list of tasks in order" but it is also perfectly fine to assume "runs all of the tasks in parallel".
I think everyone is capable of reading well-written text or code. The problem comes when it’s not well written, in which case you’re in the real of reverse engineering. And most people are bad at RE.
About mental effort in meetings being lower than solving a technical issue, it is definitively true (most of the time), even though non-technical people cannot even grasp how much a difference there is.
In a previous software job, I was participating in a trade show. It was meeting after meeting, with both sales and technical aspects (I was paired with a sales guy). After several days like this, I remember vividly the sales guy saying how this trade show was good, but at the same time complaining how tired he was because all of these meetings. I kept it to myself, but for me, this was nearly like vacations compared to the day to day usual work
