| @binkmail.com | |
| @bobmail.info | |
| @chammy.info | |
| @devnullmail.com | |
| @letthemeatspam.com | |
| @mailinater.com | |
| @mailinator.net | |
| @mailinator2.com | |
| @notmailinator.com | |
| @reallymymail.com |
| <!-- iPhone 6 Plus --> | |
| <link href="startup-image-1242x2148.png" | |
| media="(device-width: 414px) and (device-height: 736px) | |
| and (-webkit-device-pixel-ratio: 3)" | |
| rel="apple-touch-startup-image"> |
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).
Would you love to get Docker up and running on you Raspberry Pi 2? Fortunately someone already did most of the leg work for you, as you will see from the article "Kick-Ass Raspberry Pi 2 having a forbidden love affair with Docker 1.4.1".
Check the official article "Installing Operating System Images" for more information on how to install this Debian Wheezy OS.
After you have downloaded and installed the image referenced in the article you're ready to do some adjustments to improve security.
Log in as root to create a personal user and give it a password:
| /* bling.js */ | |
| window.$ = document.querySelector.bind(document); | |
| window.$$ = document.querySelectorAll.bind(document); | |
| Node.prototype.on = window.on = function(name, fn) { this.addEventListener(name, fn); }; | |
| NodeList.prototype.__proto__ = Array.prototype; | |
| NodeList.prototype.on = function(name, fn) { this.forEach((elem) => elem.on(name, fn)); }; |
Short version: I strongly do not recommend using any of these providers. You are, of course, free to use whatever you like. My TL;DR advice: Roll your own and use Algo or Streisand. For messaging & voice, use Signal. For increased anonymity, use Tor for desktop (though recognize that doing so may actually put you at greater risk), and Onion Browser for mobile.
This mini-rant came on the heels of an interesting twitter discussion: https://twitter.com/kennwhite/status/591074055018582016
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| """ | |
| Copies all keys from the source Redis host to the destination Redis host. | |
| Useful to migrate Redis instances where commands like SLAVEOF and MIGRATE are | |
| restricted (e.g. on Amazon ElastiCache). | |
| The script scans through the keyspace of the given database number and uses | |
| a pipeline of DUMP and RESTORE commands to migrate the keys. | |
| Requires Redis 2.8.0 or higher. |
| #!/bin/bash | |
| # Checks active, non-spot, EC2 instances against the list reserved instances | |
| # in order to determine which availability-zone/instance-type combinations | |
| # are paying for on-demand prices (that could benefit from reserved instance | |
| # purchase), or current reservations that aren't being used. | |
| # | |
| # Dependencies: | |
| # * awscli (http://aws.amazon.com/cli/) | |
| # * jq (http://stedolan.github.io/jq/) |
This is the follow up to a post I wrote recently called From Require.js to Webpack - Party 1 (the why) which was published in my personal blog.
In that post I talked about 3 main reasons for moving from require.js to webpack:
Here I'll instead talk about some of the technical challenges that we faced during the migration. Despite the clear benefits in developer experience (DX) the setup was fairly difficult and I'd like to cover some of the challanges we faced to make the transition a bit easier.