| language: ruby | |
| rvm: | |
| - 1.9.3 | |
| before_install: | |
| - openssl aes-256-cbc -K $encrypted_755628117be5_key -iv $encrypted_755628117be5_iv | |
| -in travis_ci_ec2.pem.enc -out ~/.ssh/travis_ci_ec2.pem -d | |
| - chmod 600 ~/.ssh/travis_ci_ec2.pem | |
| install: | |
| - bundle install --without vagrant | |
| - bundle exec berks install |
| Tricks to add encrypted private SSH key to .travis.yml file | |
| To encrypt the private SSH key into the "-secure: xxxxx....." lines to place in the .travis.yml file, generate a deploy key then run: (to see what the encrypted data looks like, see an example here: https://github.com/veewee-community/veewee-push/blob/486102e6f508214b04414074c921475e5943f682/.travis.yml#L21 | |
| base64 --wrap=0 ~/.ssh/id_rsa > ~/.ssh/id_rsa_base64 | |
| ENCRYPTION_FILTER="echo \$(echo \"-\")\$(travis encrypt veewee-community/veewee-push \"\$FILE='\`cat $FILE\`'\" | grep secure:)" | |
| split --bytes=100 --numeric-suffixes --suffix-length=2 --filter="$ENCRYPTION_FILTER" ~/.ssh/id_rsa_base64 id_rsa_ | |
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
| # knife cheat | |
| ## Search Examples | |
| knife search "name:ip*" | |
| knife search "platform:ubuntu*" | |
| knife search "platform:*" -a macaddress | |
| knife search "platform:ubuntu*" -a uptime | |
| knife search "platform:ubuntu*" -a virtualization.system | |
| knife search "platform:ubuntu*" -a network.default_gateway |
| package main | |
| import ( | |
| "encoding/hex" | |
| "log" | |
| "net" | |
| "time" | |
| ) | |
| const ( |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
| zsock_t *radio = zsock_new_radio ("inproc://zframe-test-radio"); | |
| zsock_t *dish = zsock_new_dish ("inproc://zframe-test-radio"); | |
| // Use following for multicast | |
| // zsock_t *radio = zsock_new_radio ("udp://239.0.0.1:55555"); | |
| // zsock_t *dish = zsock_new_dish ("udp://239.0.0.1:55555"); | |
| // Join to group | |
| rc = zsock_join (dish, "World"); | |
| assert (rc == 0); |