czarneckid

Zero downtime deploys with unicorn + nginx + runit + rvm + chef

Below are the actual files we use in one of our latest production applications at Agora Games to achieve zero downtime deploys with unicorn. You've probably already read the GitHub blog post on Unicorn and would like to try zero downtime deploys for your application. I hope these files and notes help. I am happy to update these files or these notes if there are comments/questions. YMMV (of course).

Other application notes:

• Our application uses MongoDB, so we don't have database migrations to worry about as with MySQL or postgresql. That does not mean that we won't have to worry about issues with the database with indexes being built in MongoDB or what have you.
• We use capistrano for deployment.

Salient points for each file:

mislav

The reason why you might get certificate errors in Ruby 2.0 when talking HTTPS is because there isn't a default certificate bundle that OpenSSL (which was used when building Ruby) trusts.

Update: this problem is solved in edge versions of rbenv and RVM.

$ ruby -rnet/https -e "Net::HTTP.get URI('https://github.com')"
net/http.rb:917:in `connect': SSL_connect returned=1 errno=0 state=SSLv3
  read server certificate B: certificate verify failed (OpenSSL::SSL::SSLError)

You can work around the issue by installing a certificate bundle that you trust. I trust Mozilla and curl.

SzymonPobiega

If you have two days to learn the very basics of modelling, Domain-Driven Design, CQRS and Event Sourcing, here's what you should do:

In the evenings read the [Domain-Driven Design Quickly Minibook]{http://www.infoq.com/minibooks/domain-driven-design-quickly}. During the day watch following great videos (in this order):

1. Eric Evans' [What I've learned about DDD since the book]{http://www.infoq.com/presentations/ddd-eric-evans}
2. Eric Evans' [Strategic Design - Responsibility Traps]{http://www.infoq.com/presentations/design-strategic-eric-evans}
3. Udi Dahan's [Avoid a Failed SOA: Business & Autonomous Components to the Rescue]{http://www.infoq.com/presentations/SOA-Business-Autonomous-Components}
4. Udi Dahan's [Command-Query Responsibility Segregation]{http://www.infoq.com/presentations/Command-Query-Responsibility-Segregation}
5. Greg Young's [Unshackle Your Domain]{http://www.infoq.com/presentations/greg-young-unshackle-qcon08}
6. Eric Evans' [Acknowledging CAP at the Root -- in the Domain Model]{ht

jpetazzo

Rectifier

The diode bridge is the simplest rectifier I know.

Rectifier lets you share a directory with a docker container (just like $yourvm shared folders).

You don't have to install anything in your containers, and you only need to install diod in the host. diod is packaged on Ubuntu/Debian distros, and will automatically be apt-get install-ed if needed.

Since it uses diod to make a bridge, I called it rectifier. Yeah, that sucks, so if you have a better name, I'll steal it!

marknca

#! /usr/bin/env bash

# Remove OpsWorks security groups from the given region

# Available regions:
# ====================
# ap-northeast-1 => Asia Pacific (Tokyo) Region
# ap-southeast-1 => Asia Pacific (Singapore) Region
# ap-southeast-2 => Asia Pacific (Sydney) Region
# eu-west-1 => EU (Ireland) Region

wsargent

303 See Other

Location: https://github.com/wsargent/docker-cheat-sheet

Hi there!

The docker cheat sheet has moved to a Github project under https://github.com/wsargent/docker-cheat-sheet.

Please click on the link above to go to the cheat sheet.

ruyrocha

 ~ # redis-benchmark -s /var/run/redis/redis.sock -q -n 10000
PING_INLINE: 156250.00 requests per second
PING_BULK: 196078.44 requests per second
SET: 212765.97 requests per second
GET: 185185.19 requests per second
INCR: 217391.30 requests per second
LPUSH: 200000.00 requests per second
LPOP: 222222.22 requests per second
SADD: 204081.64 requests per second
SPOP: 217391.30 requests per second

chenglou

Interesting part (unmounting & API) is at the end if you're not interested in the rest =).

Stress Tests

This animation proposal is just an attempt. In case it doesn't work out, I've gathered a few examples that can test the power of a future animation system.

1. Parent is an infinitely spinning ball, and has a child ball that is also spinning. Clicking on the parent causes child to reverse spinning direction. This tests the ability of the animation system to compose animation, not in the sense of applying multiple interpolations to one or more variables passed onto the child (this should be trivial), but in the sense that the parent's constantly updating at the same time as the child, and has to ensure that it passes the animation commands correctly to it. This also tests that we can still intercept these animations (the clicking) and immediately change their configuration instead of queueing them.

2. Typing letters and let them fly in concurrently. This tests concurrency, coordination of an array of ch

jlongster

(function() {
  // Do not use this library. This is just a fun example to prove a
  // point.
  
  var Bloop = window.Bloop = {};

  var mountId = 0;
  function newMountId() {
    return mountId++;
  }

timruffles

In many production systems you'll want to have one module capable of talking to many potential implementations of a collaborator module (e.g a in memory cache, a redis-based cache etc). While testing it's useful to control which module the module under test is talking to.

Here are the approaches I can see. The two points that seem to divide the approaches are their tool-ability (dialyzer) and their ability to handle stateful implementations (which need a pid).

Passing modules

Modules are first class, so you can pass them in. Used in EEx, where passed module must implement a behaviour.