romain-trotard

Recently, during the migration to React 17, I had a problem between event listeners handled by React and one added document manually. It was due to this part on the React 17 release note.

At this moment I understood that I had a misconception of how React handles event listener. So I decided to explore the React code to understand how it works.

The misconception

Before going deep in the React codebase, I would like to explain what was in my head about the management of event listeners.

For example when I write this simple code:

manuelvicnt

// PLEASE, READ
//
// This is a way to scope ViewModels to the Composition.
// However, this doesn't survive configuration changes or procress death on its own.
// You can handle all config changes in compose by making the activity handle those in the Manifest file
// e.g. android:configChanges="colorMode|density|fontScale|keyboard|keyboardHidden|layoutDirection|locale|mcc|mnc|navigation|orientation|screenLayout|screenSize|smallestScreenSize|touchscreen|uiMode">
//
// This is just an exploration to see what's possible in Compose. We don't encourage developers to copy-paste
// this code if they don't fully understand the implications of it and if this actually solves the use case to solve.

gmk57

/**
 * Coroutine-based solution for delayed and periodic work. May fire once (if [interval] omitted)
 * or periodically ([startDelay] defaults to [interval] in this case), replacing both
 * `Observable.timer()` & `Observable.interval()` from RxJava.
 *
 * In contrast to RxJava, intervals are calculated since previous run completion; this is more
 * convenient for potentially long work (prevents overlapping) and does not suffer from queueing
 * multiple invocations in Doze mode on Android.
 *
 * Dispatcher is inherited from scope, may be overridden via [context] parameter.

1242035

Error:

$ adb devices
List of devices attached
52003c2b58b445db	no permissions (user in plugdev group; are your udev rules wrong?); see [http://developer.android.com/tools/device.html]

Fix: 
1> sudo usermod -aG plugdev $LOGNAME (https://developer.android.com/studio/run/device)
2> lsusb
3> sudo vi /etc/udev/rules.d/51-android.rules

Alexx999

From a2331af9a7930fb52109d46e00b1be85711d8b5a Mon Sep 17 00:00:00 2001
From: Alexander Vostres <[email protected]>
Date: Sun, 29 Apr 2018 21:57:56 +0300
Subject: [PATCH] Fix Windows x86

---
 build32.bat                    |   2 +
 build32dbg.bat                 |   2 +
 build64.bat                    |   2 +
 build64dbg.bat                 |   2 +

jFransham

Achieving warp speed with Rust

Contents:

• Number one optimization tip: don't
• Never optimize blindly
• Don't bother optimizing one-time costs
• Improve your algorithms
• CPU architecture primer
• Keep as much as possible in cache
• Keep as much as possible in registers

chitchcock

Stevey's Google Platforms Rant

I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.

I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real