A curated list of AWS resources to prepare for the AWS Certifications
A curated list of awesome AWS resources you need to prepare for the all 5 AWS Certifications. This gist will include: open source repos, blogs & blogposts, ebooks, PDF, whitepapers, video courses, free lecture, slides, sample test and many other resources.
| # CircleCI failed to build a git submodule update step. | |
| # Tracked it down to partially complete .git/modules existing in our source cache. | |
| # This removes the .git/modules directory before the submodule update. | |
| # The error: | |
| # $ git submodule update --init | |
| # git submodule update --init returned exit code 128 | |
| # fatal: Not a git repository: ../.git/modules/<project> Action failed: git submodule update --init | |
| checkout: |
openssl req -nodes -newkey rsa:2048 -sha256 -keyout mysite-ssl.private-key.pem -out mysite-ssl.csr -subj '/C=US/ST=California/L=Palo Alto/O=My Company Inc./CN=*.example.com'openssl req -nodes -newkey rsa:2048 -sha256 -x509 -days 3650 -keyout selfsigned.key -out selfsigned.crt -subj '/C=US/ST=Anywhere/L=Anywhere/O=Localhost/CN=local.example.com'
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.
| #!/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/) |
| """ | |
| 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. |
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
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
| /* bling.js */ | |
| window.$ = document.querySelectorAll.bind(document); | |
| Node.prototype.on = window.on = function (name, fn) { | |
| this.addEventListener(name, fn); | |
| } | |
| NodeList.prototype.__proto__ = Array.prototype; |
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:
