derekjkeller

## From a post on the ML, apropos this: 
## http://lowlatencyweb.wordpress.com/2012/03/20/500000-requestssec-modern-http-servers-are-fast.
## For sysctl.conf

net.ipv4.tcp_slow_start_after_idle = 0


  echo "2048 64512" > /proc/sys/net/ipv4/ip_local_port_range
  echo "1" > /proc/sys/net/ipv4/tcp_tw_recycle
  echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse

derekjkeller

<?php

class Crypt {

    private $key;

    function __construct($key){
        if(ctype_xdigit($key) && strlen($key) === 64){
            $this->key = $key;
        }else{

derekjkeller

<?php
// your main aplication config file
// app/config/application.php
$config = [
    'application' => [
        'cacheDir'   => __DIR__ . '/../../cache/',
        'appDir'     => __DIR__ . '/../',
        'baseUri'    => '/',
        'basePath'   => '/',
        'publicUrl'  => 'http://www.your_domain.com',

derekjkeller

<?php
/**
 * Batch Mockup
 *
 * I placed this in my BaseController.php file
 *
 * @usage
 *     $batch = new Batch('stats');
 *     $batch->columns = ['score', 'name'];
 *     $batch->data = [

derekjkeller

#!/usr/bin/env ruby

# This pre-commit hook will prevent any commit to forbidden branches
# (by default, "staging" and "production").
# Put this file in your local repo, in the .git/hooks folder
# and make sure it is executable.
# The name of the file *must* be "pre-commit" for Git to pick it up.

FORBIDDEN_BRANCHES = ["staging", "production"]

derekjkeller

This page provides a full overview of PHP's SessionHandler life-cycle - this was generated by a set of test-scripts, in order to provide an exact overview of when and what you can expect will be called in your custom SessionHandler implementation.

Each example is a separate script being run by a client with cookies enabled.

To the left, you can see the function being called in your script, and to the right, you can see the resulting calls being made to a custom session-handler registed using session_set_save_handler().

derekjkeller

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, when I started going through the process of forking and issuing pull requests, I had some trouble figuring out the proper method for doing so and made quite a few mistakes along the way. I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your

derekjkeller

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

• Two developers working on independent features must never be blocked by each other
  • No code freeze! Ever! For any reason!
• A developer must be able to base derivative work on another developer's work, without waiting for any third party
• Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
• Developers must be able to work on multiple features simultaneously, or at lea

derekjkeller

Automation for the People

Long ago, the first time I read "The Pragmatic Programmer", I read some advice that really stuck with me.

"Don't Use Manual Procedures".

This in the chapter on Ubiquitous Automation. To summarize, they want you to automate all the things.

The trouble was that I hadn't much of an idea how to actually go

derekjkeller

I just made the terrible mistake of turning thirty. Apparently, one of the things that 30-year olds do on YouTube is make lists of 30- things. 30 is a lot of things to put in a list. I tried to make a list of 30 things about being 30, but I got like, four things in before I realized that I didn't have that many things.

So instead, I thought I'd make a list of 30 things I've learned about programming. Let's begin.

1. this first episode has Q in it? Like, first episode. ugh, this is not off to a strong start.
2. why does everybody hate Wesley Crusher so much? He doesn't seem so bad, and Wil Wheaton is a really nice guy in real life.
3. oh. OH. I get it now. I understand the hate.

Oh. Sorry, that's a list I'm making about watching Star Trek The Next Generation for the first time. I'll .. uh... get to that later.