bernawil

  never even think about how their services will inevitably be used against others.

Or they know how it will be abused and want to charge for filtering the abusers.

That's the yelp way.

I did some contracting as tech lead for a contracting agency and was very involved in the recruiting process. I advised against some recruiters recommendations for "hiring fast" when candidates were hot in the market or they accepted some hourly rates when I knew they could get better. If you want them to stick for a while make sure you're paying as much as they can get!

  If the developer can get permission to build 3-5 story apartments on the lot

wouldn't that only work for a single unit? Like, yes, if inside a single-family-zoned block a unit would get a special permission to be the only one to build high density, sure that piece of land would be more valuable than before.

But if the whole block gets rezoned, then there's a race to the bottom.

  The pronunciation of something is secondary to its definition. But with a phonetic language, it's easy to fool yourself as well as others of an understanding that is not very deep.

well, children are introduced to "reading" as in mapping written symbols to phonemes. Yes, there's more to reading than that, as in you can side-step the mapping to phonemes and map straight to "meaning", but nobody is doing that with children. Phonetic languages just make the (indispensable) step of text to sound easier and gives you a head start.

  I think it's a big stretch to assume that Japanese people can't even read books on the train because their literacy is so low.

That's also an uncharitable interpretation of the article, or anything I pointed.

The best way I could put it is, "the Japanese writing system is pretty cumbersome and in turn the people on average are less drawn to literal mediums and more drawn towards visual media".

And that's just the opinion of an english teacher in japan after all.

That makes sense. On the other hand, what made me side with the author here is this.

  About a year ago, I read a study (which I wish to hell I could locate again) that made the case that children raised with more phonetic languages, such as Spanish and Finnish, had a notable advantage over children whose native language is English, because they learned to read and write much earlier. While American, British, and Australian children puzzle over words like “plough,” “epitome,” and “Worcestershire,” children in Spain are steadily progressing through more and higher-level books, enabling them earlier access to advanced skills such as reasoning, synthesis, and discussion. They simply read at a higher level than English speakers of the same age.

this highly resonates with my experience as Spanish is my first language and started learning English since first grade.

Spanish speakers are expected to read arbitrary words and write (albeit with lots of spelling mistakes) by (optimistically) kindergarten or early first grade. The written-spoken language is very regular so it's very easy so "sound out" words. This is in contrast to what I hear is like to teach English speaking children. So yes, the author's hypothesis seems plausible to me.

  Japanese folks lag behind in education simply because their language requires them to spend far longer mastering reading. This significantly delays their progress.

  

https://japaneseruleof7.com/are-japanese-people-retarded/

EDIT: I see the URL seems offensive but it's clickbait, the article is actually serious.

> <h> for a time was not silent, and many words that start with <h> used to have an /f/.

Probably related, most words with an H in Spanish use an F in Portuguese. Like 'HONGO' - > 'FUNGO'.

In the 17th century there was a concerned effort to make the written language consistent in writing.

> it was anything from socially unacceptable (England) to effectively illegal (Roman Republic/Empire) for aristocratic landowners to invest in non-land things

can you expand on this? It's harder to think about "investment" opportunities back then because the economy was basically agriculture, the slave trade, urban real estate, and trading the fruits of agriculture and slavery. I think landowners in the Roman Empire did in fact partake in other business, say starting gladiator companies.

I think it's because these languages really like mono and two syllable words. Shorter words make a shorter "namespace" so repetition is more common. It's also the reason rhyming is easier though.

and there's localstack for those cases.

  We're not animals

  so the engineers went to greener pastures

...for grazing?

you can make your component's css "not leak" if you name all it's classes with random uuid and scope all selectors accordingly, exactly what styled components does. But "not leaking css" is a nicer way of saying that you can't customize it.

It's funny -and not counter to your point- but several of the succession struggles that plagued the Eastern Empire are characterized as "almost elections", by historians. Since its inception, the empire never had an official succession system and hence every new ruler was contested. Constantinople was so easily defendable that a popular usurper had great chances of making himself with the throne if he could take control of the capital. More than once, pretenders rose to power by popular acclaim at the hippodrome.

  I'm trying to see any disadvantages for countries that do this

One unintended consequence could be that while a country might get some foreign citizen remote workers, it would decrease the remote working opportunities of their own citizens.

E.g Spain might think "we'll get Americans to move here and do their U.S jobs" but what they actually get is, for example, Moroccans getting U.S jobs from Spain and more less chances of Spanish citizens getting U.S jobs.

Well, but then it's not the same api call and that's the point: that in the old mvc frameworks it was painful having to support controllers that both rendered html and json for doing both SSR and Ajax.

Around the time the first js FE frameworks came out, people finally became confident enough to have pure js clients and only json APIs.

And finally gatsby, next.js, etc. brought a new twist to the SSR and Ajax api combo.

Well, it's code for "keep density low" and "keep traffic out of my property while I go generate traffic on other people's property". The results are the same though.

the template rendering lives side by side with the controllers, why would it make an api call?

But something similar but not the same as that was the norm during the jquery era before the early js frameworks arised (backbone, ember et all). You had your full-stack server-side MVC framework render initial views and from there the js would pick up and all UI interactivity would be ajax calls to the restful(ish) api. It was pretty terrible.

Not to cache simple trips to the database is pretty uncontroversial, the are more controversial cases elsewhere.

Say you consume a Restful API to hidrate order data in another system. Do you fetch orders as:

  /orders?ids=id-1,id-2,id-3

or separate calls to

  /orders/id-x

which can be cached and retrieved by id as a memoized function?

Well if you had to pick only one the second is probably better, but the best would be abstracting away order fetching in application code to always fetch single orders and behind the scenes looking up the cache for singles and pooling all the misses into a single request to the plural endpoint.

  And if you DO need caching, keep your hands off of the application; add a cache layer in front, or between the application and the database. But don't invent it yourself.

so, redis?

   Now a garbage man says “I’m not gonna be a garbage man anymore, I can do something I love now, like a music teacher that pays $30k”

"wait it's gone to $25K... to $15K.. aand it's gone". Other people might have the same idea and if more people want to become music teachers, music teacher salaries go down and garbageman keeps picking garbage.

  the economic differences between classes just comes down to neighborhoods, property wealth and accumulated family wealth... not necessarily income.

In the long run salaries (incomes) tend to subsistence levels, capital dwarves labor and it all comes down to "accumulated family wealth". That's the normal. Postwar raised the relative value of labor for a while but that cycle is coming to an end.

  Imagine some incubating startup where you have an initial 4-week runway for development, with the goal of getting a prototype working

Are you talking about an actual prototype or an MVP? A prototype meant to showcase some idea doesn't need any unit tests. An MVP? probably yes.

Now back to the practicality of software development. Unit tests are fundamental when working in a team setting. What are people doing in PRs without unit tests?

came from... Flash? so he was doing FLASH right until now?

Agreed, but I wouldn't put 2015 as the year React "won". It did "win" the SPA frameworks war, but back then the default for webdev was still non-SPA and React was competing with jquery/"no framework" and the rest of not-quite-spa frameworks like backbone, ember, etc. Nowadays React is the standard, I dare say even for SSR sites!

The javascript framework fatigue meme was born during the early days of ember, backbone, angular 1, knockoutjs and meteor. Sometime between 2016 and 2017 was when it should have been put to rest.

Dark Ritual was banned for as long as I remember (I played extended during 2003-2006). It's pretty much the definition of an OP card: if you were to draw 2 copies and a strong creature it'd be almost imposible to lose that game.

  If the project requires me to locally install a database, configure ports, or anything of the like, that's a shining red flag that things are very wrong

Backend project? you need to provide a docker-compose setup. Not just for the database, also for any other service like Redis, ElasticSearch, etc. If you're expecting PRs, you'll also need a good database unit test suit, preferably running something like Sqlite.

Frontend? ideally you'll provide the API setup like before, but I'll settle for a dev env online.

  I don't think they really understood what working from an office was really all about.

So right.

Working from a big corporate campus: gee, this team member is in another floor, I better talk to him via IM and email.

Working from small startup open office: gee, this team member is opposite myself from this small common table, better talk to him via IM, we don't want to bother every single person in the open-plan office.

  It signals insecurity about your culture and why anyone should want to work there. (We can't keep people here except under threat.)

well, unless you're paying top dollar you can be sure people are working at your place until they can get a job at a place that does.

  It's ineffective against your best employees, who will have options and will not fear you.

again, if your place isn't on top of everyone's preference list it's futile to hold onto your best perforers. Better to embrace it will be a revolving door.

  it kind of just breezes over it without explaining the reasons why DataLoader isn't a good long-term solution

nit: I don't think the author argues that dataloader isn't a good long term solution.

If I had to guess, because it's something that you just turn on in your project and it just works -or doesn't-.

I've used it in a project together with graphql-sequelize, which gives you "automatic" resolvers for your queries. Turn dataloader on, perform a query that uses any of those automatic resolvers and all underlying SQL queries to the same table are magically merged together. Now, replace those automatic resolvers with custom ones and you lose this magic. Now you have to write your own ORM query that groups anything that would end up being multiple queries into one, basically the case the author is pointing out.