shkumagai

use strict;
use warnings;

use Digest::SHA;

# Using sha256 algorism
our $ctx = Digest::SHA->new(256);

sub bit_to_digest {
    my ($bits) = @_;

hiroeorz

{sys, [
       {lib_dirs, ["../deps"]}, %% depsを追加
       {erts, [{mod_cond, derived}, {app_file, strip}]},
       {app_file, strip},
       {rel, "hogeapplication", "0.1",
        [
         %% 標準で使うライブラリも全て追加
         kernel,
         stdlib,
         sasl,

keikubo

LXC

コンテナは、軽量な仮想化技術です。これはQemuやVMwareのような完全仮想化に比べると、どちらかというと拡張されたchrootに似ています。なぜなら、コンテナはハードウェアをエミュレートしたりせず、ホストと同じOSを共有するからです。なのでコンテナは、SolarisのzoneやBSDのjailと比べて優れています。Linux-vserverとOpenVZの二つが、現在のところ既に存在している独立して実装されているLinux機能のコンテナ実装です。実はコンテナは、vserverとOpenVZの機能の上位互換を開発するための仕事の延長で登場しました。いくつかのvserverとOpenVZの機能は現在のコンテナではまだ実装されていませんが、コンテナは多くのLinuxディストリビューションを起動(boot)することができ、upstreamカーネルの変更なしで利用することができるという利点があります。

コンテナのユーザー領域の実装には、カーネルの同じ機能を利用した二つの方法があります。Libvirtは、「lxc:///」に接続してLXCドライバー経由でコンテナへのアクセスを許可します。この仕組みは他のドライバーと同じ使い方をサポートしているので、非常に使い勝手の良いものになるでしょう。もう一つのコンテナ実装は、単純に「LXC」と呼ばれるものです。これはlibvirtとは互換性はありませんが、より多くのユーザー領域ツールによってより柔軟に使うことができます。これは、少し混乱を生む特異な部分もありますが、二つのLXC間での入れ替えも可能になります。

このドキュメントでは主にlxcパッケージについて記述します。あとは、ドキュメントの最後の辺りにかけてlibvirt LXCドライバーについても記述します。

このドキュメントでは、コンテナの名前はCN、C1、そしてC2として説明します。

qnighy

nginx Digest認証 メモ

概要

• nginxはDigest認証非対応
• モジュール増やせばできる
• モジュール増やすにはnginxからビルドし直さなくてはいけない

免責

Gab-km

GitHub Flow

• Scott Chacon on the Interwebs(リンク切れ)
• Scott Chacon on the Interwebs
• GitHub Flow - The best way to use Git and GitHub

31 Aug 2011

git-flowの問題点 (Issues with git-flow)

makotoworld

import datetime
import time

int(time.mktime(datetime.datetime(2012, 3, 3, 22, 0, 57).timetuple()))

kenjiskywalker

http://nginx.org/en/docs/http/configuring_https_servers.html
http://nginx.org/ja/docs/http/configuring_https_servers.html

default_server

default_serverは対象のポートに対して有効だから
下記のようにポート毎にデフォルトサーバを指定できる。

server {

repeatedly

MessagePackが文字列とバイナリをわけないのは問題？

msgpack/msgpack#121

Objective Cの実装使ってるとある問題にぶちあたった．なので，文字列をちゃんとバイナリ(Raw)と分けるべき，という提案

(*) 俺は熟読したわけではないので，中身が気になる人はちゃんと本スレを読みましょう

そもそもMessagePackとは

kuenishi

ついに顕在化し始めてもいない「Erlang/OTPリスク」

英語圏ではかなり前からErlang/OTPを開発し続けることのリスクについて語られていたが，具体的な弊害が出て来たので，単なるメモ．日本では起こり得ない未来だと思う．

若手エンジニアの不足

COBOLのように需要が逼迫しているのに人材の供給が増えず需給ミスマッチが起っているわけでは無く，需要も供給も増えないという状況下でわずかながら需要が上回っている質の悪い状況がErlang/OTPに起きている．特に深刻なのは高価な若手エンジニアの採用が絶望的に難しいという現実だ．Haskellが台頭して数年経ちScalaがメインストリームの先頭を突っ走る2013年において全く別の関数型言語もどきを勉強しようとする若者はよほどの物好きしかいない．20~30歳のErlang/OTPエンジニアを雇うのはそれほど難しい上にコストがかかる．優秀な30代前半の若手エンジニアを雇いたいという企業の思いとは裏腹にErlang/OTP新たに学ぶ若者は絶滅寸前だ．

とても優秀な若手を雇用できるチャンスが巡って来た．採用担当者はこう尋ねる．「Erlang/OTPは習得していますか？」「もちろんRuby/Scalaはお手の物です．Haskellもある程度可能です」「もう一度伺いますがErlang/OTPまたはCは習得していますか？」「申し訳ございません 未習得です」

shkumagai

original:	Using Unicode in Erlang
source:	STDLIB User's Guide Version 1.19.1
url:	http://www.erlang.org/documentation/doc-5.10.1/lib/stdlib-1.19.1/doc/html/unicode_usage.html

2 Erlang で Unicode を使う

2.1 Unicode の実装