hknd

I really want a heated cupholder now - how did I never hear for this before. This is a gamechanger.

Which will only get the price up for a short amount of time, it will be dumped after that anyway.

GME fundamentals haven't changed (much) - it's not worth much on paper, maybe $10, $20, $30?

Market behaves irrational rn, but at some point it will become rational again. And then GME stock will crash.

https://webassembly.org/docs/use-cases/

TL;DR: - "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server - "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)

wow :cry:

Probably just re-using a footer component which wasn't updated yet

Literally the first thought which popped in my head.

Most of the stores not long-life objects.

The current store holding most of the displayed data stays alive (while not switching to a different route), but everything else resets or gets recreated when needed. (no need to keep stores alive if they are not required or used)

Stores for specific "sub" views (think dialogs, tabs, collapsibles, ...) are getting created/destroyed ad-hoc.

Main Store for a specific view holds the current data (which receives updates via gql subscriptions ~every second), the current filter which is applied to it's children (only show Apple related securities) and currently visible/hidden state of any children.

User/App/Global related attributes which don't change often are stored in a globally available object (and is easy for us as users don't log out or anything)

We used to have that but moved to an approach with multiple "rootStores" per self-contained route (sometimes we have more than 1 root store in such a scenario).

But we also have multiple smaller stores which are not connected to the root store. Think: multiple not-connected trees where each node is a store.

I must agree that both approaches have pros and cons, e.g. passing down data down a long path of stores is annoying.

Mobx is not a global state, you can create your stores as granular as you want them to.

Each widget can have a store, each section can have a store, each view can have a store, etc. You decicde what works for you.

(I use mobx in a large and complex trading application)

The status dashboard is something which will be updated by an operations employee manually (yes by hand), who is a couple of layers behind the actual SWE/SRE who gets the page.

Google has multiple internal alerting systems and people are aware of any disruption/delay/anomaly from the minute it happens.

The on-caller for the specific service decides on how to produce.

The status dashboard is something which will be (manually, yes by hand) updated by an operations employee, who is a couple of layers behind the actual SWE/SRE who gets the page.

notion.so

Finally a simple issue tracker - I was waiting for something like this for ages.

Haha, same - this is so frustrating.

Anyone know from the inside how this affects stock vesting and pre-IPO stock options?

I got introduced to this in my first week at Google and using this for multiple years now, with multiple work accounts and multiple personal gmail accounts. (multi inbox, labels, filters, aliases, etc)

Can't think of going back tbh, really like it. One think I'm doing is checking emails quite a lot instead of just once/twice a day tho.

Using ExtJS for a couple of finance web apps ~6years ago.

I like using firebase (auth, firestore, functions) as it's kinda easy to use which makes me get stuff done.

We are happy with using jamboard.

https://jamboard.google.com/

no it's always optional - they recommend adding one to be able to retrieve a lost/hacked account

I used to write SQL at Google/FB, and I did and still do struggle with it.

I think it's because I usually touch SQL like once a month and by the time I need it I already forgot everything :shrug:

It's the same every year: learn and completely understand the basics - the rest will follow.

If you know how latest react works you don't need redux or rxjs as hooks can solve most problems in a reusable way.

Example: https://github.com/oldboyxx/jira_clone

"ZEIT is now Vercel. This new identity aligns with our new focus — to provide the ultimate workflow for developing, previewing, and shipping Jamstack sites."

(╯°□°）╯

Let them setup an environment s.t. they can work on the codebase - help them, but also let them document it for the next person (or update existing documentation).

Give them a high level overview of architecture and best practices.

Let them work on very small features/bugs (update text, fix small issues, ...) s.t. they learn the process end-to-end without spending much time on code.

[^ everything until here could be done without human explanation if you have solid documentation and codelabs]

Give them small features to work on s.t. they can own part of the codebase.

Twitter Source: https://twitter.com/PA/status/1238397976768282626

[wfh] My company forces me to work from home which means I can't get breakfast/lunch/dinner/snacks at the office but have to order food. As people stopped ordering from Chinese/Asian restaurants, many of them give amazing discounts :-)

[business travel] We are not allowed to do any business travel which means I had to cancel several NYC trips, which I was really looking forward too.

[travel] I had multiple flights booked for a variety of short holidays for the next weeks. Many of my flights have been cancelled or rebooked.

I live in London.

These are different teams within Google, and it's kinda not fair to say that Google is not truly behind open web standards.

Their whole web developer advocate team is behind open web standards, and pushes it forward everyday. The engineering team actually working on Chrome is behind those standards, and pushes it forward. They work closely with other browser vendors. and try to make everything work everywhere.

Then there is the Chrome marketing team which has to goal (OKR) to increase the reach of Chrome. They might still support the open web, but their goal is to get more users using chrome.

off-topic: I like how that agency is selling "Faster pages" / "just like this website hence resulting in lightning fast websites."

But sending 1.3MB over the wire for a super simple website :D

Better pay is imho not true.

Maybe the lower bound might be higher, but from my experience working in FAANG/IB/HedgeFunds the pay for normal SWEs (web frontend+backend, fullstack, whatever you wanna call it) was always higher than iOS devs. (most of the time much higher).

mate - this is super cool. Love how you structure your project (very similar to mine).