I believe you are talking about ff xii with its gambit system. It's sort of a simplified programming tool to program your AI companions behavior without having to directly micromanage them. For example, a companion can be programmed to heal ally if their HP is less than 50% hp, cast specific spell if there 3 enemies or more, attack nearest enemy in that priority order. I wish more games have this system.
I'm not sure where you got the idea that the rich people clogged the road in developing countries, but we heavily depend on cars/motorcycles for our transportation. Poor people use them all the times (especially motorcycles). And people with low wages do take loans just to buy a cheap car/motorcycle, even way before buying a house since they provide immediate benefits with manageable monthly installments.
EDIT: It makes me think why there is not much push for electric motorcycles. Whenever EV is mentioned, it's always been a car.
Cheap Chinese electric bikes and trikes aren’t a thing in your country?
> It makes me think why there is not much push for electric motorcycles. Whenever EV is mentioned, it's always been a car.
That simply isn’t accurate. Chinese electric scooters were common even back in 2008, they are pretty ubiquitous by now. Electric motorcycles aren’t common, but neither are gas powered motorcycles in that country. These aren’t the fancy “for play” motorcycles replacements or electric bikes that the west want, but are definitely work horses in developing countries.
They don’t have paved roads, but they still have electricity. I stayed in a place in China off the grid on a trip (it was on a mountain in the Tibetan part of Sichuan), they still had electricity via a water wheel. When the water wheel was knocked out of alignment, the electricity went off.
A lot of off the grid solutions for electricity, getting regular gasoline shipments to those locations is much more of a challenge.
It could be phrased better, but I think they got the point across. The message is something that most people (not just programmers) could relate on various levels and learn to get better.
One other reason is probably because inches is not a universal unit of measurement for computer graphic. Especially for someone who comes from country where inch is never used (like me), you need to mentally calculate the value to something more familiar.
I'm not the commenter. But taken at face value, your comment could be either bye bye mailinator.com (I'm not using you anymore) or bye bye mailinator.com (no one is going to use you anymore). Fwiw, I thought you meant the latter until I read your reply.
To me, it would be very odd if no one wants that since human vary. Someone out there must be crazy enough to just abandon their life on earth to have a chance to set the first stone of civilization in mars (or on the other extreme, no longer wants to live on earth).
You could spin up a server with just one AWS CLI command (and most likely google console, but I have no experience with it). As you said, just specify the server spec in the command option. Though, AWS CLI is very verbose with their commands, imo.
Anything more complex, such as weaving several server under one VPC with a load balancer and routing configuration, I'd recommend checking out terraform. It also supports multiple cloud providers.
People can sue you for insulting religion, there is a law for it (not specific to Islam, but religion in general). 99% of the times, this is a non-issue. People just don't care enough to bring the issue to court. However, if politic is involved, this can be used as a ground to discredit a politician. It is a hot topic this year before our capital's election, where one of the frontrunners was sued for allegedly insulting al-qur'an[1]
One other exception is if you live in Aceh. It is a special region in Indonesia which implements Islamic law to the tee.
> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends.
While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, rather than completely ignoring it (like code styles as you mentioned). He created Prettier, so I'm sure he knows the value of code styling.
Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repetition.
I had a coworker come to my desk one day, years ago. "Why did you add all that duplicated code to that file??" Huh? Oh, I didn't 'add' that duplication. I took two long files by two different authors, changed them to use the same white space, variable names, comment style and organization strategy. That's all I did. I didn't have the time at that moment to take the next step.
He came back four hours later and said that he couldn't stand it and he had refactored the code and fixed/written some tests.
Perfect. I learned long ago that there are ways you can start cleaning that will induce (some) others to participate.
He spent hours writing tests while I was working on an adjacent part of the code that had worse bugs in it. The work got done and a big piece of the code (this was a project I supported but didn't maintain) didn't, in the end, have my edit history all over it.
I see a lot of article that tell you how to improve code, and they often seem focused in the wrong area. Python's PEP for example, I see the value in it, but you can follow that to the letter and still have a badly designed application and confusing code.
Aren't style guides supposed to help write code that is more standard in style, and hence easier to read - because your brain will become accustomed to that style.
I think pure style (e.g. that a linter would catch) and DRY could be treated separately. The former should always be followed. To the latter: I find weak or incorrect abstractions much harder to follow than repetitive code. And I find those much more commonly when implemented early rather than later.
There's definitely a balance, and if you know the type of problem you are solving ahead of time you can probably abstract early. But if you're just kind of feeling around in the dark, which seems to be relatively common in complex business applications (for instance), I much appreciate an implement-test-reflect-refator cycle.
For actual redesign, you end up with a long true refactoring iteration when no new features can be added. There is no guarantee you will not repeat the same mistakes or make it worse.
