These rules are adopted from the AngularJS commit conventions.
# Hello, and welcome to makefile basics. | |
# | |
# You will learn why `make` is so great, and why, despite its "weird" syntax, | |
# it is actually a highly expressive, efficient, and powerful way to build | |
# programs. | |
# | |
# Once you're done here, go to | |
# http://www.gnu.org/software/make/manual/make.html | |
# to learn SOOOO much more. |
cd /tmp | |
curl -o git-2.2.1.tar.gz "https://www.kernel.org/pub/software/scm/git/git-2.2.1.tar.gz" | |
curl -o git-2.2.1.tar.sign "https://www.kernel.org/pub/software/scm/git/git-2.2.1.tar.sign" | |
# if you want to verify the tar signature | |
gpg --keyserver hkp://keys.gnupg.net --recv-keys 6092693E | |
gunzip git-2.2.1.tar.gz | |
gpg --verify git-2.2.1.tar.sign |
@binkmail.com | |
@bobmail.info | |
@chammy.info | |
@devnullmail.com | |
@letthemeatspam.com | |
@mailinater.com | |
@mailinator.net | |
@mailinator2.com | |
@notmailinator.com | |
@reallymymail.com |
package main | |
import ( | |
"io" | |
"log" | |
"os" | |
"os/exec" | |
"io/ioutil" | |
"bytes" | |
) |
# Template composition with inclusion | |
Every template language I have seen provides some mechanism for one template to include another, thus supporting the reuse of repeated elements like headers and footers. The included templates are called partials in Mustache parlance: | |
```html | |
<!-- home.hbs --> | |
<html> | |
<body> | |
{{> header}} | |
<p> HOME </p> | |
{{> footer}} |
function isalpha(c) { | |
return (((c >= 'a') && (c <= 'z')) || ((c >= 'A') && (c <= 'Z'))); | |
} | |
function isdigit(c) { | |
return ((c >= '0') && (c <= '9')); | |
} | |
function isalnum(c) { | |
return (isalpha(c) || isdigit(c)); |
<?hh | |
async function helloAfter($name, $timeout) { | |
// sleep asynchronously -- let other async functions do their job | |
await SleepWaitHandle::create($timeout * 1000000); | |
echo sprintf("hello %s\n", $name); | |
} | |
async function run() { | |
$joe = helloAfter('Joe', 3); |
I'm writing this up from memory, so errors may appear.
This has been updated to use SHA256 certificates.
- Go to http://www.startssl.com/
- Click on 'Control Panel'
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