Androider

Don't fight the language! JS is a still an evolving language, class properties are at Stage 3 draft, and have effectively been usable for years already. I feel the verbosity argument against classes is complete bunk.

When you write "TLDR: There are no plans to remove classes from React... Crucially, Hooks work side-by-side with existing code so you can adopt them gradually... Finally, there is no rush to migrate to Hooks." it doesn't give me the warm and fuzzies, quite the opposite. I can feel the momentum is going to shift to the new hotness and a completely different way of doing things and I'm not sure I want to go where you're heading. Until the next shiny thing.

I wish React would stop adding to the core library. I strongly feel most of the innovation should be happening in libraries surrounding it, even if they're first party libraries, with the core being much slower to change. A good reason to change the core would be taking advantage of new standardized JS features in the future, or (minimally breaking) changes to support big ideas like async rendering. Changing the fundamental way you write React code because "classes are confusing" is just a terrible reason!

You can tell it's made to spec and with zero developer love softening the rough corners, because no developer who cares would make a full-screen screenshot view mode you cannot exit with Esc.

That's a good suggestion, but I just don't need or want to maintain two sets of bookmarks, install each plugin twice, configure each setting in two places, etc. But I guess I'll have to... sigh.

I have a personal Gmail account, and a business G Suite account, and this change makes working with the two accounts a complete pain. All my years of Chrome bookmarks/settings/etc. are associated with my personal account, so I want the browser itself to always be logged in with that identity. But I want to be logged into my business G Suite email account "by default" when I hit gmail.com, when I open Google Analytics, Drive etc. so I don't have to use the account picker a hundred times a day. It just doesn't seem possible. Argh.

I wonder if Google employee accounts were to be considered business G Suite-like instead of consumer Gmail like, all these kinds of problems that constantly keep popping up for G Suite customers wouldn't be fixed overnight.

In my opinion, GraphQL moves too much of the burden to the user of the API. It makes most sense if the data is highly dynamic, you have a mobile app and every call is expensive, or (and this seems more common) the backend and frontend teams don't like to talk to each other. As a user, I just want to GET /foo, with a good old API token I pasted from your dev docs, and move on to the next thing. I don't want to spend time figuring out your database schema. Or perhaps I've just yet to see single good public GraphQL API. I just recently had look at the Github GraphQL API and it's non-existent docs (no, I don't want introspect your data models at runtime), noped the hell out of that, and got the REST integration for the bit I needed done in an hour.

I'm building my own company now, fully remote, and from an engineering output point of view I've never seen such productivity. No ass-in-seat supervision, no assigned hours, just straight throughput of engineering tasks being closed and features being shipped every day.

I'd trust the AWS datacenter security and processes over your average big-corp datacenter any day, having seen quite a few.

It's like the difference between an old-style Taxi and an Uber, with the latter you just get up and go when you're done. The whole dance of flagging down the server to request the bill, get the bill, oops the server disappeared before you could pull out your card, wait for 10 minutes while they are off exploring Narnia in the kitchen cupboards. Finally they come to take the card and disappear again, what should have taken 30 seconds is now at 15 min+, hope you're not missing your show... ah, finally they're back! Now try to figure out the tip line, with the air of one who is trying to convert Fahrenheit to centigrade in your head while your house is burning down.

Waitstaff-less high-end restaurants expand the audience and frequency of visits of people who can now enjoy these better-than-Chipotle dining experiences. Much like Uber, which doesn't only cannibalize existing providers but actually creates a whole new category of short rides that you would never have previously considered using a Taxi for.

BBC: More evidence essential oils 'make male breasts develop' [2]

I'll stick with my no-fragrance detergent, thanks!

[1] https://livefrey.com/shop/the-detergent/ [2] https://www.bbc.com/news/health-43429933

It's a double edged sword. It's easy to be let go (basically, pack your stuff and get out while escorted by security, just like in the movies), but it also makes it much easier for companies to take a risk and hire you. In Europe, hiring someone is a big risk and companies are extremely careful to hire since they're taking on a big responsibility. As a result, permanently contracted positions are even more common in Europe than the US as a result in my experience.

It's also really easy and convenient, while setting up wire transfers with our Major Bank in the US was complicated and arcane. To date, Major Bank doesn't offer us online wire transfers, for a business account!

We also use TransferWise to accept customer bank payments in Europe, without having an actual presence there.

You don't have to use Redux etc. (but you probably do if you have sufficiently complex state). Even then, you can do things like have multiple stores in the same app. It's fine! It's just JS objects being spliced, merged, propagated. You eventually converge on a single store as the various React parts merge.

You don't need to use react-router, or even a router lib. It's probably better if you don't, given how many times that shitshow of an API has been completely rewritten. I took one look at it, could tell that this lib wanted to be fully in charge, and noped out. It's fine to manage browser URL state yourself, it's just JS and the browser APIs are OK for that nowadays.

Now we're in the process of adopting Immutable.js. It's fine, it's just fancier collections, with some conveniences and being able to use React.PureComponent 99% of the time without worry. So your codebase is 50% fancy collections and 50% JS natives? That's fine, don't worry about it, just write new components using Immutable.js if that's the direction you're going. Don't worry about the top-level Redux container not being an Immutable instance, just use it for the leaves then.

Server side rendering? I retrofitted that in a weekend by compiling the app as a lib with Webpack (project started as Gulp way back), included that in Node.js as an import. Worked just fine, nothing to it. Now we're generating PDFs using the same frontend code with Puppeteer and SSR, it's awesome.

The app is in a better shape than ever, a real pleasure to work with. Jest tests for React stuff, Mocha tests for other parts. And that's fine, no need to get all religious about which one is the "one true" framework.

They're supposed to be the old-school paper tags with a hole in the narrow end [0].

These tags, like floppy's and manila folders, will live on in our iconography even as someone born this decade is unlikely ever encounter the real thing. I was recently amused to explain to my kid what the dialer icon on the iPhone is: "well, a long, long time ago (it's getting close to 20 years now since the Nokia 3310 sold over a 100 million units and we got rid of our landline) we used to have stationary phones in our homes and you would talk into a wired handset that looked like this icon".

[0] https://www.amazon.com/Martha-Stewart-Crafts-Kraft-Tags/dp/B...

Being able to write really well can also make you stand out and do wonders for your career, especially if everyone else on the team is likewise a high performer (Jeff Dean style). The best people I've worked with have also all been really nice and kind to a fault.

Donating blood is one of the easiest thing you can do to prevent all kinds of cardiovascular disease! Thanks for the reminder, I will be going to donate.

The John Legend voice for Google Assistant was apparently made without hours of recordings. Companies like https://lyrebird.ai/ do a basic job of copying your voice with about a minute worth of samples (more obviously helps).

I think it's entirely inevitable that at some point you will be able to customize the Google Assistant to use your own voice thanks to WaveNet and it's successors. Instead of the recognizable assistant making calls, every assistant will be different.

If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Everything is a trade-off.

I personally feel the JS ship has long sailed. I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. That is definitely a bit sad.

https://ny.curbed.com/2018/1/24/16925172/nyc-rent-2017-decre...

11+ super-talls (300m+) and 40+ talls (150m+) are under construction at the moment, and more than that has been completed in just the last few years. Massive amounts of rental units and co-ops are coming online in UWS (Riverside Center), Hudson Yards in Mid-Town etc [1]. And prices have come noticeably down as a result, you can also get more concessions than ever. I just recently received 3.5 months free on a 14 month contract in a brand new building.

[1] https://ny.curbed.com/maps/nyc-new-development-hudson-yards-...

So a legacy architecture will for instance specify the "frontend servers subnet" (and a unique SG, hopefully!), while a cloud-native architecture will only specify a SG. I think, asking which subnet some machine is in, is kind of like asking which core some process is running on at the moment: any one of the subnets for any one of the availability zones in that region, and the next one will automatically and on purpose be assigned to a different one by the ALB/ASG combination.

The other case of componentWillReceiveProps usage I see is where there is computationally expensive derived state, but for some reason the asynchronous nature of setState prevented it from being used, and an instance variable "had" to be used instead. There are a few cases of these where after much hair pulling the instance variable "fixed" the issue.

That's just to cover previously made mistakes. Reducing enforcement is going to keep adding to that list, and reducing safety and quality of life for all Americans.

The vast majority (60-80%, Robert L. Glass) of costs for software is also in maintenance, as any of the classic software project management books will tell you.