<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>localhost.pbcopy</string>
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
# to generate your dhparam.pem file, run in the terminal | |
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
#!/bin/bash | |
# | |
# transcode-video.sh | |
# | |
# Copyright (c) 2013-2015 Don Melton | |
# | |
about() { | |
cat <<EOF | |
$program 5.13 of April 8, 2015 |
You should never let passwords or private data be transmitted over an untrusted network (your neighbor’s, the one at Starbucks or the company) anyway, but on a hacker congress like the #30C3, this rule is almost vital.
Hackers get bored easily, and when they’re bored, they’re starting to look for things to play with. And a network with several thousand connected users is certainly an interesting thing to play with. Some of them might start intercepting the data on the network or do other nasty things with the packets that they can get.
If these packets are encrypted, messing with them is much harder (but not impossible! – see the end of this article). So you want your packets to be always encrypted. And the best way to do that is by using a VPN.
Here's what I did to get things working.
Yep, over at: https://developer.apple.com
#!/bin/bash | |
############################################################################### | |
# NOTICE: This script is intended to be used in conjunction with a openssl.cnf | |
# template such as this one: | |
# https://gist.github.com/jameskyle/8106d4d5c6dfa5395cef | |
# (C) Copyright 2014 James A. Kyle. | |
# | |
# Licensed under the Apache License, Version 2.0 (the "License"); | |
# you may not use this file except in compliance with the License. |
(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.
I've been looking for the best Linux backup system, and also reading lots of HN comments.
Instead of putting pros and cons of every backup system I'll just list some deal-breakers which would disqualify them.
Also I would like that you, the HN community, would add more deal breakers for these or other backup systems if you know some more and at the same time, if you have data to disprove some of the deal-breakers listed here (benchmarks, info about something being true for older releases but is fixed on newer releases), please share it so that I can edit this list accordingly.
- It has a lot of management overhead and that's a problem if you don't have time for a full time backup administrator.
#!/bin/sh | |
# iohyve v0.2.5 2015/05/06 "ALL HAIL LINUS edition" | |
# Process command line | |
__parse_cmd () { | |
while [ $# -gt 0 ] ; do | |
case "$1" in | |
version) __version | |
exit |