See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
// basic usage: new Markov(lotsOfText).generate() | |
// markov chain constructor | |
// | |
// @string input {example text} | |
// @integer len {optional # of words to output} | |
// @integer stateSize {optional chain order} | |
function Markov( input, len, stateSize ){ | |
this.cache = Object.create(null) | |
this.words = input.split(/\s/) |
<html> | |
<head> | |
<meta charset=utf-8 /> | |
<title>London Pollution</title> | |
<meta name='viewport' content='initial-scale=1,maximum-scale=1,user-scalable=no' /> | |
<script src='https://api.mapbox.com/mapbox.js/v3.0.1/mapbox.js'></script> | |
<script src="https://unpkg.com/esri-leaflet@2.0.4/dist/esri-leaflet.js"></script> |
[Settings] | |
ID = "Your_Site_ID" | |
# Settings in the [build] context are global and are applied to all contexts unless otherwise overridden by more specific contexts. | |
[build] | |
# This is the directory to change to before starting a build. | |
base = "project/" | |
# NOTE: This is where we will look for package.json/.nvmrc/etc, not root. | |
# This is the directory that you are publishing from (relative to root of your repo) |
⚠️ Note 2023-01-21
Some things have changed since I originally wrote this in 2016. I have updated a few minor details, and the advice is still broadly the same, but there are some new Cloudflare features you can (and should) take advantage of. In particular, pay attention to Trevor Stevens' comment here from 22 January 2022, and Matt Stenson's useful caching advice. In addition, Backblaze, with whom Cloudflare are a Bandwidth Alliance partner, have published their own guide detailing how to use Cloudflare's Web Workers to cache content from B2 private buckets. That is worth reading,
Get the metadata and content of all files in a given GitHub repo using the GraphQL API
You might want to get a tree summary of files in a repo without downloading the repo, or maybe you want to lookup the contents of a file again without download the whole repo.
The approach here is to query data from GitHub using the Github V4 GraphQL API.
class Spiderman { | |
lookOut() { | |
alert('My Spider-Sense is tingling.'); | |
} | |
} | |
let miles = new Spiderman(); | |
miles.lookOut(); |
This is definitely not the first time I've written about this topic, but I haven't written formally about it in quite awhile. So I want to revisit why I think technical-position interviewing is so poorly designed, and lay out what I think would be a better process.
I'm just one guy, with a bunch of strong opinions and a bunch of flaws. So take these suggestions with a grain of salt. I'm sure there's a lot of talented, passionate folks with other thoughts, and some are probably a lot more interesting and useful than my own.
But at the same time, I hope you'll set aside the assumptions and status quo of how interviewing is always done. Just because you were hired a certain way, and even if you liked it, doesn't mean that it's a good interview process to repeat.
If you're happy with the way technical interviewing currently works at your company, fine. Just stop, don't read any further. I'm not going to spend any effort trying to convince you otherwise.