| const express = require('express'); | |
| const app = express(); | |
| // Application | |
| app.get('/', function(req, res) { | |
| if (process.env.NODE_ENV === 'development') { | |
| for (var key in require.cache) { | |
| delete require.cache[key]; | |
| } | |
| } |
Localz is building a platform to track driver locations as they deliver parcels.
A driver logs into their device and begins submitting location. This location will be used for the customer to track the driver on a map.
Please conform to the requirements below, we do not expect you to go beyond these. This is a server-side challenge.
| git log --author="Linus Torvalds" --date=iso | perl -nalE 'if (/^Date:\s+[\d-]{10}\s(\d{2})/) { say $1+0 }' | sort | uniq -c|perl -MList::Util=max -nalE '$h{$F[1]} = $F[0]; }{ $m = max values %h; foreach (0..23) { $h{$_} = 0 if not exists $h{$_} } foreach (sort {$a <=> $b } keys %h) { say sprintf "%02d - %4d %s", $_, $h{$_}, "*"x ($h{$_} / $m * 50); }' | |
React recently introduced an experimental profiler API. This page gives instructions on how to use this API in a production release of your app.
Table of Contents
React DOM automatically supports profiling in development mode for v16.5+, but since profiling adds some small additional overhead it is opt-in for production mode. This gist explains how to opt-in.
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
| // | |
| // Author: Jonathan Blow | |
| // Version: 1 | |
| // Date: 31 August, 2018 | |
| // | |
| // This code is released under the MIT license, which you can find at | |
| // | |
| // https://opensource.org/licenses/MIT | |
| // | |
| // |
| [00:25:11.086] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:20.117] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:25.449] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:32.414] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:37.246] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:42.978] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:51.842] npc_dota_hero_legion_commander uses item_armlet | |
| [00:25:55.675] npc_dota_hero_legion_commander uses item_armlet | |
| [00:26:04.139] npc_dota_hero_legion_commander uses item_armlet | |
| [00:26:11.237] npc_dota_hero_legion_commander uses item_armlet |
I have migrated about 11 kloc from material-ui 0.X to material ui 1.0 (a moderate size project). It has taken me more than 20 hours, and it was not a pleasant experience. cf https://github.com/marmelab/admin-on-rest/pull/1167
I understand that you took the opportunity of a major BC break to rethink the API completely.
But coming from 0.X, the changes often aren't consistent. Each component has changed in a different way,
and for a given component, there is no way to guess the 1.0 API based on the 0.x API. Why did <ToolbarGroup> disappear?
Why do I need to decompose a ListItem into so many sub components now? Why was Toggle renamed to Switch?
While I'm learning how to use Nginx, I was instructed to update the server_names_hash_bucket_size (/etc/nginx/nginx.conf) value from 32 to 64, but I don't understand why should I increase the value to 64.
References that have been read so far:
