| 'use strict'; | |
| module.exports = function CustomError(message, extra) { | |
| Error.captureStackTrace(this, this.constructor); | |
| this.name = this.constructor.name; | |
| this.message = message; | |
| this.extra = extra; | |
| }; | |
| require('util').inherits(module.exports, Error); |
| // | |
| // Regular Expression for URL validation | |
| // | |
| // Author: Diego Perini | |
| // Created: 2010/12/05 | |
| // Updated: 2018/09/12 | |
| // License: MIT | |
| // | |
| // Copyright (c) 2010-2018 Diego Perini (http://www.iport.it) | |
| // |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| # Add the following 'help' target to your Makefile | |
| # And add help text after each target name starting with '\#\#' | |
| help: ## Show this help. | |
| @fgrep -h "##" $(MAKEFILE_LIST) | fgrep -v fgrep | sed -e 's/\\$$//' | sed -e 's/##//' | |
| # Everything below is an example | |
| target00: ## This message will show up when typing 'make help' | |
| @echo does nothing |
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.
I say "animated gif" but in reality I think it's irresponsible to be serving "real" GIF files to people now. You should be serving gfy's, gifv's, webm, mp4s, whatever. They're a fraction of the filesize making it easier for you to deliver high fidelity, full color animation very quickly, especially on bad mobile connections. (But I suppose if you're just doing this for small audiences (like bug reporting), then LICEcap is a good solution).
- Launch quicktime player
- do Screen recording
| package main | |
| import ( | |
| "net/http" | |
| "database/sql" | |
| "fmt" | |
| "log" | |
| "os" | |
| ) |
Hey everyone - this is not just a one off thing, there are likely to be many other modules in your dependency trees that are now a burden to their authors. I didn't create this code for altruistic motivations, I created it for fun. I was learning, and learning is fun. I gave it away because it was easy to do so, and because sharing helps learning too. I think most of the small modules on npm were created for reasons like this. However, that was a long time ago. I've since moved on from this module and moved on from that thing too and in the process of moving on from that as well. I've written way better modules than this, the internet just hasn't fully caught up.
@broros
otherwise why would he hand over a popular package to a stranger?
If it's not fun anymore, you get literally nothing from maintaining a popular package.
One time, I was working as a dishwasher in a restu
A collection of links to the "Master the JavaScript Interview" series of medium stories by Eric Elliott.