• ニコニコ動画
• ネットラジオ（radiko.jpなど）

AmebaアプリのiOS版を担当している田坂(@tasanobu)です。
先日、iOS7のデザインに最適化したバージョンをストアにリリースしました。
今回はiOS7対応時に行ったUI実装をご紹介させて頂きます。

1. NavigationBarやToolbarがコンテンツに被ってしまう問題

Before	After

また、以下のようにNavigationBarとToolbarのtranslucentを変更しても同様の動作をするようです。（正しい実装かは怪しいですが。。。）

2. StatusBarがコンテンツに被ってしまう問題

Before	After

この場合、UIViewController.topLayoutGuideの値を参照し、viewDidLayoutSubviewsでveiwのframeを調整することにより解決しています。

3. UINavigationBarのtintColor設定

iOS7からUINavigationBarやUIToolbarなどのtintColorの仕様が以下のように変わっています。

AppDelegate の application:didFinishLaunchingWithOptions: でNavigationBarの背景色設定などをiOS7とそれ以前に分けて行っています。
（UIAppearanceを利用してアプリケーション全体に設定を反映させています。）

4. UITableViewのSeparator設定

Before	After

AmebaアプリではSeparatorを左端まで引くデザインを採用しています。
AppDelegate の application:didFinishLaunchingWithOptions: でUITableView.separatorInsetの値を設定しています。
（"3"と同様、UIAppearanceを利用してアプリケーション全体に設定を反映させています。）

Before	After

5. UIImagePickerControllerのカメラに電池残量が表示されてしまう問題

まとめ

参考情報

(この記事は、Hadoop Advent Calender 2013 の12日目の記事です)

こんにちは、Amebaのログ解析基盤Patriotの運用をしている、鈴木(@brfrn169)と柿島です。

Patriotについては以下をご覧ください。
http://ameblo.jp/principia-ca/entry-10635727790.html
http://www.slideshare.net/cyberagent/cloudera-world-tokyo-2013

今回、Amebaのログ解析基盤PatriotにCloudera ImpalaとPrestoを導入しました。

Cloudera ImpalaとPrestoのインストール方法や詳細ついては、下記URLをご覧ください。

Cloudera Impala
http://www.cloudera.com/content/cloudera-content/cloudera-docs/Impala/latest/

Presto
http://prestodb.io/

インストールは、基本的にはドキュメントに従って実施しました。
一箇所だけハマったのが、PrestoでのHDFSのHAの設定方法です。

etc/catalog/hive.propertiesに以下を追加する必要があります。

あけましておめでとうございます。

あけましておめでとうございます。
仕事柄まだ去年からの障害を引きずっていて年明けどころじゃないよ！と言う方もいらっしゃるかもしれませんが・・・。
新年ということで心機一転システム改善／新規開発、頑張って行きましょう！

昨年は滞っていた更新を定期更新ペースに戻すことが出来たのではないかと思っているサイバーエージェント公式エンジニアブログです。


2013年エンジニアブログランキング

それでは、早速ですが2013年の総決算として2013年に公開された記事のアクセス数ランキングを公開いたします！
この年始のお時間あるときに読んでいただけましたらと思います。

10位：ピグ麻雀のアルゴリズム
ピグのミニゲームとして提供している麻雀ゲームのアルゴリズムについての記事です。
麻雀やったこと無いエンジニアの人たちが麻雀ゲームを作るための苦悩も綴られていますｗ

9位：redisをsentinelとAliasIPを利用して冗長化
優しいマサカリを受けた記事ですね。
ありがたいことですm(_ _;)m

8位：弊社の最近のDevOpsへの取り組み
監視の生成等を自動で行うためのアプリケーションの作成などについて語っています。
弊社でのAWS事例としても。

7位：第６回テックヒルズでアメーバピグにおけるJenkinsの活用例を発表しました。
六本木ヒルズで行われた、CROOZさん主催のテックヒルズにおけるJenkinsの発表について。みんなでHadoopTシャツ着ていった所視線が熱かったですｗ

6位：社内勉強会制度「Skill U Friday」
社内勉強会をまとめている織田さんのエントリです。
織田さんはSUFだけではなく他の社内外の勉強会にも精力的に進めています。

5位：cassandra運用監視小ネタ集
Cassandra芸人と言われるOranieさんの運用監視小ネタ集です。（弊社NoSQL芸人を多数抱えております）
ただのTIPS集ではない血反吐にまみれた記事をお読みください。

4位：出、出、出～ameba画像配信奴～！！
アメブロの画像配信の現在とこれからについての話です。
タイトルとは違って内容はきちんと書かれていますｗ

3位：lombokで快適Java生活
getter/setterメソッドなどのジェネレイトツールであるlombokの紹介です。
Scalaを使おう！

2位：WebSocketで監視もリアルタイムに
WebSocketを使った監視のリアルタイム更新についてまとめたエントリになります。
ゲーム系などのリアルタイムが重要に成るサービスなどにはこういう監視方法が主流に成るかもしれません。

1位：キラキラ女子を支える技術
弊社故にといいますか、この記事が1位になってしまいました・・・ですが、中身は真面目な社内のエンジニア環境の紹介エントリになっていますｗ


2014年もよろしくおねがいします

今年も、技術レポート、企画などを通じた会社の文化やエンジニア環境の紹介、イベントレポート、頂いたフィードバックの反映等々をみなさまにお届けしたいと思っております。
本年もサイバーエージェント公式エンジニアブログをよろしくお願いいたします。

こんにちは、Morino(@kohei_april20)と申します。（だいぶ前にFlashの代替としてのHTML5というエントリを書いて今回２回目です）

ちょっと前にスマホブラウザ向けのサービスでアバターを動かすアニメーションの仕組みが必要になった時がありました。それでボーンアニメーションやパラパラ漫画形式のアニメーションのスプライトシートによるアニメーションの仕組みを、Flashのアニメーション素材を元に生成して再生する仕組みを作ったりしていたのですが、その時に画像データにピクセルの色データとしてメタデータを埋め込む仕組みを作ったのでそれの紹介をしたいと思います。（ここ扱う画像はアルファ有りのPNG画像です）

特徴

• スプライトシートアニメーションは通常スプライトシート画像とメタデータの少なくとも２つのデータを配信する必要があるのですが、このメタデータを画像データに突っ込んでしまえば一気に配信することが可能になり、必要なリクエスト数を減らすことができます。またこれはスプライトシート用途に限らず、汎用性があります。
  
• PNG画像の仕様から言えば実はチャンクと呼ばれるデータの塊を独自に付加できるので、データをここに付加することが可能です。しかし、ここにデータを入れてもブラウザからJavaScriptを通じてのアクセスが非常に悪く実用的でなさそうです。（仮にこの方法で出来ても画像とメタデータを両方得るには無駄に２度ロードが必要かも？）そのため、ピクセルの色データを画像として付加することでJavaScriptからのアクセス可能なデータとしてデータ付与ができるようになっています。

データを付与された画像

データ構造
埋め込むデータの構造は下図のようになっています。

データ構造

埋め込み

1. 埋め込むデータ量を算出（情報が付加されているかを判別するためのシグネチャ、付加情報文字列のデータ長、付加情報本体の総和）
2. 埋め込むデータ量から、1ピクセル3バイト（本来は4バイトあるが後述の理由により3バイトのみ利用）として必要ピクセル数を算出
3. オリジナル画像の幅から必要行数を算出
4. 「幅」×「必要行数」で確保するピクセル数の内の余るデータ長（アラインメント）を算出
5. アラインメント部分(ゼロフィル)、付加情報、付加情報データ長、シグネチャ（文字列'EMB'の3バイト）を合わせて埋め込みデータを整形
6. 埋め込みデータを各ピクセルに順にセット（アルファ部分は0を埋めてスキップ）

データ埋め込み部分の抜粋
※Flash素材からデータを生成するツールでAIRアプリケーションによる実装なのでActionScript3です。

public function embedToBitmap(bitmap:BitmapData, stringBytes:ByteArray):BitmapData {
 
    var lengthWithoutAlpha:int = stringBytes.length + STR_LENGTH_SIZE + SIGNATURE_SIZE;
    var numLines:int = Math.ceil(lengthWithoutAlpha / (bitmap.width * RGB_SIZE));
    var fraction:int = lengthWithoutAlpha % (bitmap.width * RGB_SIZE);
    var alignment:int = fraction == 0 ? 0 : bitmap.width * RGB_SIZE - fraction;
 
    var appendDataBytes:ByteArray = new ByteArray();
    var i:int, j:int;
    for (i = 0; i < alignment; i++) {
        appendDataBytes.writeByte(0);
    }
    appendDataBytes.writeBytes(stringBytes, 0, stringBytes.length);
    appendDataBytes.writeShort(stringBytes.length);
    // signature 'EMB'
    appendDataBytes.writeByte(0x45);
    appendDataBytes.writeByte(0x4D);
    appendDataBytes.writeByte(0x42);
 
    var newBitmapData:BitmapData = new BitmapData(bitmap.width, bitmap.height + numLines, true, 0x00FFFFFF);
    newBitmapData.draw(bitmap);
 
    var y:int = bitmap.height;
    var x:int = 0;
    // add data to original bitmap
    for (i = 0; i < appendDataBytes.length; i += 3) {
        var b1:uint = appendDataBytes[i] << 16;
        var b2:uint = appendDataBytes[i+1] << 8;
        var b3:uint = appendDataBytes[i+2];
        var color:uint = 0xff000000 | b1 | b2 | b3;
        // alpha must be 0xFF to avoid rounding RGB values by browser
        newBitmapData.setPixel32(x, y, color);
        // proceed pixel
        ++x;
        if (x >= bitmap.width) {
            x = 0;
            y++;
        }
    }
    return newBitmapData;
}

復元

1. 末尾より4バイト（アルファ情報は捨てて3バイト）を読み、シグネチャを確認
2. 更に3バイト（アルファ情報は捨てて2バイト）を読み、データ長を取得
3. 付加情報領域の行数を算出
4. データ長分をアルファ情報をスキップして読み進みバイナリ情報を構築して文字列を得る

データ復元部分抜粋

....
var data = context.getImageData(0,0,width,height).data;
 
// data length including image part and extra data part
var length = height * width * RGBA_SIZE;
var currentPosition = length - 4;
var sign = fromCharCode(
    data[currentPosition],
    data[currentPosition + 1],
    data[currentPosition + 2]
);
if (sign !== SIGNATURE) {
    // error handling
    ...
    return;
}
currentPosition = currentPosition - 3;
var strLength = data[currentPosition] << BITS_PER_BYTE | (data[currentPosition + 1]);
var numExtraLines = ceil((strLength + BYTES_STR_LENGTH + BYTES_SIGNATURE_LENGTH) / (width * RGB_SIZE));
var imageHeight = height - numExtraLines;
// data length of extra data part excluding alpha data (1 byte for each pixel 4 bytes)
var extraLength = width * RGB_SIZE * numExtraLines;
// data length of alignment excluding alpha data (1 byte for each pixel 4 bytes)
var alignLength = extraLength - (strLength + BYTES_STR_LENGTH + BYTES_SIGNATURE_LENGTH);
var extraStartPosition = imageHeight * width * RGBA_SIZE;
var strStartPosition = extraStartPosition + alignLength +
    // add alpha data length
    floor(alignLength / RGB_SIZE);
 
var text = '';
currentPosition = strStartPosition;
for (var i = 0; i < strLength; i++) {
    text += fromCharCode(data[currentPosition++]);
    if ((currentPosition - extraStartPosition + 1) % RGBA_SIZE === 0) {
        currentPosition++;
    }
}
...

色データへ変換したデータの復元性とその検証

アルファの値とブラウザの挙動
アルファ情報を持つPNGの各ピクセルの色データはR（赤）・G（緑）・B（青）・A（アルファ）を1バイトずつの計4バイトあり、始めは4バイトすべてを利用してデータを格納しようと試みました。しかし、ブラウザで画像データに含まれるピクセルのデータをピックアップして復元する際に、アルファの値によってRGBの値がわずかに元のデータから変化してしまい元のデータを復元することができないケースが多発しました。これはアルファによる各色への影響を考慮した上でブラウザでの見た目上問題の無い範囲で丸め処理がブラウザによって行われているように思われます。そこでアルファの値を他の色に影響のない0xFFに固定してみたところ完全に元データを復元することができました。この理由から、4バイトのうちの1バイトは捨ててRGBの3バイトのみを利用してデータ埋め込みを行いました。

検証と実用性
検証はRGBの3バイトのとりうるすべてのパターンについて色データから復元したものと元データを照らしあわせ差異の無いことをGoogle Chrome、iOS4・5・6・7のSafari、Android2系・4系のデフォルトブラウザで確認しすることで行いました。また、万一復元のうまくいかないブラウザがあった場合に備えて、サーバ側でスプライトシートだけでなく付加情報だけを取得できるように配信をしておき、クライアント側で復元にエラーが発生した場合にのみ付加情報を別途サーバにリクエストするようにしておけば安全を期すことができます。実用性という点に関しては現在「ペコロッジ」というサービスで実運用しているので一応運用実績もあります。※ちなみにペコロッジはまもなくクローズしてしまいます(´；ω；｀)（執筆時点での情報です）

データの正当性
復元の際のデータの正当性に関してはシグネチャの有無、復元処理でのエラーの有無、復元後のテキストデータのパースでのエラーの有無によって判定することができます。これだけでも確率的には運用上問題ないと判断して上記のようなデータ構造を採っていますが、CRC検査などを入れればより堅実なチェックが出来るようになるのではないかと思います。



以上、スプライトシートに限らずメタデータとPNG画像がセットで必要になる場合にはこんな配信の仕方もあるよ、という紹介でした。
ちなみに画像などのコンテンツにデータを埋め込むことを電子透かしと言いますが、これも一応電子透かしと呼んで良いのでしょうかね・・？ただデータを末尾に追加してるだけですが。

　　

　　

　　

■プラットフォーム

　　

■サーバサイド

　　

はじめに

さくっと書いてためしてみることが出来るの

$ scala

println("hello world.")

brew install scala

なにが楽しいのかな

• マスコットがかわいい
• やりたいことが素直に書ける
• 言語仕様にわくわくできる
• 言語を拡張できる
• すてきな環境

■「マスコットがかわいい」

■「やりたいことが素直に書ける」

• 今までの考え方がそのまま使えること
• それがよりシンプルに実現できること

コレクション操作の考え方

List(1, 2, 3).map(i => i * 2).foreach(i => println(i))

List(1, 2, 3).map(_ * 2).foreach(println)

文字列操作の考え方

"hello_scala_world".split("_").map(s => s.capitalize).mkString("")

値としての関数という考え方

// func という関数を受け取り呼び出す関数
def callCallback(func: String => Any) = {
  func("callback!!")
}


// print するだけの関数
def callback(s: String) = println(s)


// callCallback に callback を引数として渡す
callCallback(callback)

代数的データ型とパターンマッチという考え方

  sealed trait Node


  final case class Leaf(l: Int) extends Node


  final case class Branch(a: Node, b: Node) extends Node


  def depth(tree: Node): Int = tree match {
    case Leaf(_) => 1
    case Branch(a, b) => 1 + depth(a).max(depth(b))
  }


  val tree = Branch(Branch(Leaf(1), Leaf(2)), Branch(Leaf(3), Leaf(4)))
  depth(tree)

よりシンプルな DTO

case class User(
  name: String,
  age: Int)

モナ・・・

■ 「言語仕様にわくわくできる」

データの生成の一般化

  val list = List(1, 2, 3)
  
  val array = Array(1, 2, 3)


  val map = Map(
    "モナド" -> "わかんない",
  )

null の扱いの一般化

  val foo: Foo = null

null.toString

■「言語を拡張できる」

• プロジェクト固有の構文を定義できたり
• 組み込み型にプロジェクト固有の処理を追加できたり

演算子の定義

1 + 2

1.+(2)

case class Vector2(x: Double, y: Double) {
  def +(v: Vector2) =
    Vector2(this.x + v.x, this.y + v.y)
}


Vector2(1, 2) + Vector2(3, 4)

制御構造の定義

import scala.util.control.NonFatal


def ignoreException(f: => Any) {
  try {
      f
  } catch {
    case NonFatal(e) =>
  }
}


ignoreException {
  println("hi!")
  throw new Exception
}

組み込みクラスにメソッドを追加

implicit class MyString(val s: String) extends AnyVal {
  def hello = s"Hello! $s こんにちは!"
}


"よっしー".hello

for 式

マクロ

すてきな環境

ライブラリの海に潜っていこう

最後に

こんにちは。最近専らjavascriptを書いています、maginemuです。今回はjavascriptとは全く関係ないエントリーです。

はじめに

巷でスタンディングデスクとか言われてどれくらい経ったのでしょうか。

サイバーエージェントでもスタンディングデスクをしている人は少しだけ居ます(僕のチームくらいしか見たことない)。

そういう試みをしてる人も居るよということで紹介してみたりします。

スタンディングデスクとは？

にわかに話題になった「スタンディングデスク」というキーワード。一言でいえば「立って仕事をする」ということなのですが、思いの外メリットもあるようです。

ざっと「スタンディングデスク」で検索すると沢山エントリーが出てきます。
いくつか挙げてみましょう。

• スタンディングデスクを３カ月試して感じた6つのメリット

• 長時間座っていることは喫煙並にあなたの寿命を縮める

• 「1日に6時間座っていると死のリスクが40％増大する」など、座りっぱなしのデスクワークがもたらす弊害と解決法

• スタンディングデスクの導入を考えてみる

• ワイヤーシェルフでスタンディングデスク環境を構築してみた

• 運動不足を解消する、スタンディングデスク Sit & Stand®

などなど…内容としては主に

• 健康によい
• 集中できる
• 自作してみた
• 製品紹介

といったところでしょうか。

我々の現状

さて、それでは我々の職場を紹介していきたいと思います。

2013年5月頃

当時が、現在所属しているプロジェクトにジョインした時期でした。

スタンディングデスクではないのですが、当時はバランスボールの導入を始めた時期でした。
なぜ始めたのか今は全然覚えてないのですが、多分運動不足とものぐさの結果ではないかと思います。

2013年6月末

オフィスの階を引っ越し、あるときトレーニーのチャーリー(日本人です)が段ボール箱を机の上に載せ始めたのが始まりでした。

「スタンディング憧れるわー、やりたいけど良いところないかな」

「これで良くね？」

というノリで始まりました。w

2013年10月末

スタイルが定着。バランスボールも併用しています。

2013年12月

キーボードをPCのものから外付けを導入した結果、マウスも使いたくなったりしてダンボールを2つ併用したりしています。

引っ越しの時にしぼませたバランスボールがしぼんだまま…最近はスタンディングと椅子で過ごしていました。

スタンディングデスク開始から半年

月並みですが所感をば。

インターネット上に載っているエントリーで自分の感覚に一番しっくりきたのは

• 1年間立って働いた編集者による「スタンディングデスク」の感想

こちらのエントリーでしょうか。この感覚に近い状態に、今なっていると思います。

どちらが良いというものではない

暫く立って仕事をしていると、立っている状態も普通になってきます。

立つことによるメリット/デメリットの話は散々語られていると思うのですが、
個人的には立つのが良い悪いというよりは、座るのと同じくらい立ってもいいと思う、ということ。

幸いなことにプログラミングという仕事は立っていてもできるので、そのスタイルは座ったままに留めておく必要はないと思います。

ではどうすればいいの？

立つことによって

• 集中できる(ノれる)
• 疲れる(のが良い。頭だけでなく身体も疲れたい)
• 思考や作業内容の切り替えがしやすくなる

というのは実際に感じることができました。さらに

• 特に辛くはない
• (辛くなるほど頑張らない)

とも思います。疲れたら座れば良くて、立っている時間は10分とかでもいいのではないかと思います。

 重要なのは、その時々に合わせて「簡単に立ったり座ったりを切り替えられる状態を作る」ことかなと思います。
 ここ数週間はあまり立ってなかったんですが、それでもいいかなと。ふと思い立った時に、立てばいいだけです。

たとえば

• 朝来てメールチェック, 事務処理
• ふとトイレに立つ
• 戻ってきたらそのまま立って仕事したくなって、足元からダンボールを机に上げる
• 立ってプログラミング！ (どうでもいいんですがクラブミュージック流してると個人的にはイイカンジデス)
• 疲れてきたなと思ったのですぐ座る
• 暫くするとそのうちまた立ちたくなってくる
  

慣れてくると、作業によって立ちと座りが決まってきたりしますね。 レビューやリーディングしてるときは座ってて、 書く時は立つとか。

さいごに

そんな感じでスタンディングを取り入れて半年続けてきたわけですが、特に身体に不調などは感じられていません。

 個人的には座っていると姿勢が悪くなりがちなのですが、立っているとそこまで変な姿勢にはなりづらいですし、ネットに載ってる通りの効果も実感できたし、今後も続けていくのではないかなーと思っています。

ただ、最近は慣れたのですが序盤は

• 罰ゲームに見える

というデメリットがありました。これはきちんとした環境ではなくダンボールを使っているというのと、まだあまりスタンディングデスクという文化が定着していないためだと思っています。

このエントリーで「立つのも普通」という文化がもっと定着していけば良いなと思います！

ではでは、Happy Standing!!

こんにちは。
Amebaの基幹システムを担当している松本と申します。

待望のCluster機能が実装された3.0が2014/2/11にBetaになり、
正式リリースされる日が近づいてきているRedis。

今回はアプリ開発でRedisを使って実現できる機能の一部をご紹介させていただきます。

Redisとは

本ブログにも何度か出てきているためご存知の方も多いと思いますが、
簡単に紹介しますと、Redisは高速なデータ操作が可能なインメモリKVSです。
シングルスレッドで動作しているためアトミックな操作が可能になっています。

また、Redisは様々なデータ型に対応していて、文字列型の他にリスト型、ハッシュ型、
セット型、ソート済みセット型、さらにはPub/Subまで扱えることが最大の特徴だと思います。

それぞれのデータ型に対するコマンドも多数用意されており、
それを組み合わせることで様々なケースで利用することができます。

普通にデータ操作を行うだけでも十分魅力的なRedisですが、
複数のコマンドの組み合わせるとどのような機能が実現できるのでしょうか。

カウンターやランキング、タイムライン等が有名ですが、他にもあるのです。
簡単ではありますが、2つほどJavaを用いてご紹介していきます。

ロック

1つめは、RedisのDocumentでも少しだけふれているロック機能を実装してみます。

ロック機能はRedisがアトミックな操作を保証しているから実現できる機能で、
実装に用いるのは以下の4つのコマンドです。

ロック機能のポイントはSETNXです。

指定したキーがなかった場合は値をセットして1を返し、
既に存在する場合は何もせず0が返ってきます。
つまり、1はロック成功、0は他からロック済みと判断することができます。

それでは実装に進みましょう。
まずロックのインタフェースを用意します。

public interface Lock {

    public void lock() throws TimeoutException;

    public void unlock();
}

最低限のロックとアンロックを用意しました。

続いて中身を実装します。

public class RedisLock implements Lock {

    private static final String LOCK_KEY_PREFIX = "lock:";
    private static final int LOCK_EXPIRE = 30;
    private static final long LOCK_SLEEP = 10L;

    private final Redis redis;
    private final String lockKey;
    private final long lockMillis;

    private volatile boolean isLocked = false;
    private volatile String lockedValue = "";

    public RedisLock(Redis redis, String lockKey, long lockMillis) {
        this.redis = redis;
        this.lockKey = LOCK_KEY_PREFIX + lockKey;
        this.lockMillis = lockMillis;
    }

    @Override
    public void lock() throws TimeoutException {
        if (isLocked) return;
       
        // ロック待機時間
        long max = System.currentTimeMillis() + lockMillis;

        while (true) {
            long now = System.currentTimeMillis();
            String value = String.valueOf(now);
            // ロック試行
            Long result = redis.setnx(lockKey, value);

            // ロックが成功したらexpireを設定してデッドロック防止
            if (result != null && result.longValue() == 1L) {
                redis.expire(lockKey, LOCK_EXPIRE);
                isLocked = true;
                lockedValue = value;
                break;
            }
           
            // ロック待機時間を過ぎたら終了
            if (max <= now) {
                String locked = redis.get(lockKey);
                if (locked != null) {
                    long elapsedTime = now - Long.parseLong(locked);
                    // expireが効いていなかったら削除してデッドロック防止
                    if (elapsedTime >= LOCK_EXPIRE * 1000) {
                        redis.del(lockKey);
                    }
                }
                throw new TimeoutException("lock timeout.");
            }

            try {
                // ロックできなかったらsleepして再試行
                Thread.sleep(LOCK_SLEEP);
            } catch (InterruptedException ignore) { }
        }
    }

    @Override
    public void unlock() {
        if (!isLocked) return;
        // ロックの値を取得
        String value = redis.get(lockKey);
        // このインスタンスでロックされたものなら削除
        if (lockedValue.equals(value)) {
            redis.del(lockKey);
        }

        isLocked = false;
        lockedValue = "";
    }
}

大分できてきました。

SETNXでロック可否を判断し、ロックできたらEXPIREで有効期限を設定します。
他からロックされていた場合は再試行し、待機時間が過ぎたらロック失敗です。
ロック失敗後はロック情報を調査し、EXPIREが効いていなかったら削除します。

アンロック時はインスタンスでロックしたものかを確認後に削除します。

最後に、この実装を返すFactoryを用意します。

public class RedisLockFactory {

    private final long lockTime;
    private final Redis redis;

    public RedisLockFactory(Redis redis, long lockTime) {
        this.redis = redis;
        this.lockTime = lockTime;
    }

    public Lock getLock(String lockKey) {
        return new RedisLock(redis, lockKey, lockTime);
    }
}

これでロック機能の完成です。

以下のようにロックを取得して利用します。

public class RedisLockExample {

    public static void main(String[] args) throws Exception {
        Redis redis = new RedisPool("localhost", 6379);
        RedisLockFactory lockFactory =
            new RedisLockFactory(redis, 10000L);

        for (int i = 1; i <= 10; i++) {
            // ロック取得
            Lock lock = lockFactory.getLock("hoge");
            // ロック実行
            lock.lock();
            try {
                // 排他制御を行いたい更新処理
                update();
                Thread.sleep(3000L);
            } finally {
                // アンロック
                lock.unlock();
            }
            Thread.sleep(1000L);
        }
    }

    private static void update() {
        System.out.println("hoge");
    }
}

ローカルでRedisを起動し、このクラスを複数実行してからMONITORコマンドで状況を
見てみると、ロックされている様子がよくわかります。

1392260782.952660 [0 127.0.0.1:56465] "SETNX" "lock:hoge" "1392260782949"
1392260782.955800 [0 127.0.0.1:56465] "EXPIRE" "lock:hoge" "30"
1392260783.955176 [0 127.0.0.1:56464] "SETNX" "lock:hoge" "1392260783951"
1392260783.968747 [0 127.0.0.1:56464] "SETNX" "lock:hoge" "1392260783965"

・・・略・・・

1392260785.940036 [0 127.0.0.1:56464] "SETNX" "lock:hoge" "1392260785936"
1392260785.953764 [0 127.0.0.1:56464] "SETNX" "lock:hoge" "1392260785949"
1392260785.960863 [0 127.0.0.1:56465] "GET" "lock:hoge"
1392260785.963952 [0 127.0.0.1:56465] "DEL" "lock:hoge"
1392260785.967388 [0 127.0.0.1:56464] "SETNX" "lock:hoge" "1392260785963"
1392260785.970122 [0 127.0.0.1:56464] "EXPIRE" "lock:hoge" "30"
1392260786.968606 [0 127.0.0.1:56465] "SETNX" "lock:hoge" "1392260786964"
1392260786.983315 [0 127.0.0.1:56465] "SETNX" "lock:hoge" "1392260786979"

このRedisを用いたロック機能はAmebaのサービスで実際に使用しているものもあります！

設定の同期

2つめは、設定変更時に通知して複数サーバ間で設定を同期する機能を実装してみます。

実装に用いるのは以下の3つのコマンドです。

RedisのPub/Subは非常に面白い機能で、簡単にObserverパターンの実装ができます。
SentinelもPub/Subを使用して情報のやりとりをしています。

今回はこのPub/Subを使って設定の同期を実装します。

public class SyncProperties {

    private static final String SYNC_PROP_CHANNEL = "sync.prop";

    private final Redis redis;
    private final Properties properties;
    private final SyncPropPubSub syncPropPubSub;
    private final ExecutorService threadPool;

    private boolean isStart = false;

    public SyncProperties(Redis redis, Properties properties) {
        this.redis = redis;
        this.properties = properties;
        this.syncPropPubSub = new SyncPropPubSub();
        this.threadPool = Executors.newSingleThreadExecutor();
    }

    public void syncStart() {
        if (isStart) return;
        isStart = true;
        // subscribeはスレッドを専有するので別スレッドでチャンネル接続
        threadPool.execute(new Runnable() {
            @Override
            public void run() {
                redis.subscribe(syncPropPubSub, SYNC_PROP_CHANNEL);
            }
        });
    }

    public void syncEnd() {
        if (!isStart) return;
        // チャンネル接続を閉じる
        syncPropPubSub.unsubscribe();
        isStart = false;
    }

    public void shutdown() {
        try {
            threadPool.shutdown();
            if (!threadPool.awaitTermination(3, TimeUnit.SECONDS)) {
                try {
                    threadPool.shutdownNow();
                } catch (Exception ignore) { }
            }
        } catch (Exception e) {
            try {
                threadPool.shutdownNow();
            } catch (Exception ignore) { }
        }
    }

    public String get(String key) {
        return properties.getProperty(key);
    }

    public String get(String key, String defaultValue) {
        return properties.getProperty(key, defaultValue);
    }

    public void put(String key, String value) {
        properties.put(key, value);
        String message = "put:" + key + ":" + value;
        // put情報をチャンネルに送信
        redis.publish(SYNC_PROP_CHANNEL, message);
    }

    public void remove(String key) {
        properties.remove(key);
        String message = "remove:" + key;
        // remove情報をチャンネルに送信
        redis.publish(SYNC_PROP_CHANNEL, message);
    }

    @Override
    public String toString() {
        return properties.toString();
    }

    private class SyncPropPubSub extends RedisPubSub {
        @Override
        public void onMessage(String channel, String message) {
            // 受信したメッセージを分解
            String[] m = message.split(":");
            String type = m[0];
            switch (type) {
            case "put":
                if (m.length < 3) break;
                // put情報を反映
                properties.put(m[1], m[2]);
                break;
            case "remove":
                if (m.length < 2) break;
                // remove情報を反映
                properties.remove(m[1]);
                break;
            default:
                break;
            }
        }
    }
}

Propertiesをラップし、putとremoveが実行された時にメッセージを送信します。
受信したメッセージは分解して解析し、Propertiesに反映します。

送信側は以下のように使用します。

public class PublisherExample {

    public static void main(String[] args) throws Exception {
        Redis redis = new RedisPool("localhost", 6379);

        Properties properties = new Properties();
        properties.put("hoge", "0");

        SyncProperties syncProperties =
            new SyncProperties(redis, properties);
        // 設定追加
        syncProperties.put("fuga", "true");
        for (int i = 1; i <= 10; i++) {
            // 設定更新
            syncProperties.put("hoge", String.valueOf(i));
            Thread.sleep(2000L);
        }
        // 設定削除
        syncProperties.remove("fuga");

        syncProperties.shutdown();
    }
}

受信側は以下のように使用します。

public class SubscriberExample {

    public static void main(String[] args) throws Exception {
        Redis redis = new RedisPool("localhost", 6379);

        Properties properties = new Properties();
        properties.put("hoge", "0");

        SyncProperties syncProperties =
            new SyncProperties(redis, properties);
        // 同期開始
        syncProperties.syncStart();
        for (int i = 1; i <= 10; i++) {
            System.out.println(syncProperties.toString());
            Thread.sleep(3000L);
        }
        // 同期終了
        syncProperties.syncEnd();
        syncProperties.shutdown();
    }
}

受信側を起動してから送信側を起動すると、受信側のコンソールで同期の様子がわかります。

{hoge=0}
{hoge=0}
{fuga=true, hoge=1}
{fuga=true, hoge=3}
{fuga=true, hoge=4}
{fuga=true, hoge=6}
{fuga=true, hoge=7}
{fuga=true, hoge=9}
{fuga=true, hoge=10}
{hoge=10}

設定のマスタもRedisに持つようにして、起動時にそこから持ってくるようにすれば、
常に設定を最新の状態にすることができますね！

まとめ

Redisは使い方次第で様々な機能を実装することができます。
特にPub/Subは設定をはじめ、チャットやゲームの同期やMQの実装まで、
とても応用できる幅が広く面白い機能だと思います。

高速なデータ操作だけではない、使い方次第で色々な可能性を秘めているRedis。
ぜひみなさんも使ってみてください。

なお、今回作成したソースコードはこちらで公開しております。
ご興味がありましたらご覧ください。

https://github.com/yosuque/redis-lock
https://github.com/yosuque/redis-message

こんにちは。
全社システムの吉田です。

私の所属する全社システムでは、主に社内向けシステムの構築や運用を行っています。先日、社内の認証に用いている LDAP サーバーのバッチを作成しました。

全社システムでは、コーディングをする際には主に Ruby を用いています。
Ruby から LDAP とお話するには、ActiveLdap というモジュールを使用しました。ActiveLdap の利用法についてはるびまに記事が載っています。Rails を使用した事のある人ならば、きっと直感的に使用出来ると思います。

ところで、このバッチ処理のテストはどうすれば良いでしょう？？
出来れば LDAP のモックを使った Unit Test を書きたい所です。でも、適当なモックを探して見たのですが、なかなか見つかりませんでした。Schema 登録無しで OpenLDAP と ActiveDirectory のデータが登録できて、Ruby で簡単に動かせるモックが欲しかったのですが。

結局、今回は  Unit Test は書かずにリリースしましたが、何となく気になっていたので、引きこもりの時間を利用してモックを自作してみる事にしました。バレンタイン前後に外出すると精神衛生上よろしく無いですし、2014 年は記録的大雪が降りました。今月はいつもより余計に引きこもっております。（編集部注: 執筆は2月）

その時に LDAP のプロトコルも調べてみたので、今回はその内容を簡単にご紹介します。
RFC4511 によると、LDAP 通信の流れは以下の様になっています。

こんばんは、佐野です。前回はこんな記事を書きました。最近は窓際で仕事するふりをしています。
2011年3月入社なのでどうやら入社して3年も経ってしまったようです。通算して4回目の登場です...。このエンジニアブログは年イチくらいのペースで書いてることになるのかな...。入社したときは20代だったんですが今はもう立派な三十路戦士です。酒飲むとなかなか酒が抜けません。平日に深酒するといつも後悔します。でも反省はしません。

昨今のウェブサービス開発はスタートアップを中心にクラウドを使うのが主流で、あまり需要がないかもしれませんが...今回は「甘え」と言われることもあるioDriveを導入する際に注意しておくべきポイントについて書かせていただきます。
ioDriveをはじめとするフラッシュストレージは、強力なIO性能をもつこともあってiopsなどの性能指標値ばかりに検証の焦点がいってしまいがちなのですが、プロダクションで運用するには性能以外にも見ておくべきポイントがあります。今回言及するのは熱落ち、電力不足、運用が始まってから気をつけるべきこと、の三点です。前者二点はOEMで提供されているものであっても直面することがあるのでちゃんと検証した方が良いです。

アメーバのFlash事情

気をつけることその1: 温度

気をつけることその2: 電力

!! ---> There are active errors or warnings on this device!  Read below for details.
        ACTIVE WARNINGS:
            Over PCIe power budget alarm triggered.

皆様こんにちは。サイバーエージェントエンジニアブログ運営委員です。
今回の記事は、サイボウズさんの企画「エンジニア100人に聞きました」の企画です。

「エンジニア100人に聞きました」とは、サイボウズさんのブログから引用させていただくと
＞これは、毎回、同じアンケートをそれぞれの企業内で行い、結果を「せーの」で同時公開する、というものです。
＞あくまでも「お楽しみ企画」なので、統計学的に有意な結果を得ようというわけではなく、ただ、それぞれの企業カラーを反映した「エンジニアの気風」が見えてきたら楽しかろう、というぐらいのつもり。何より、テクノロジーを愛するエンジニア同士、一緒に面白いことをやって盛り上がれれば、それが一番、というスタンスです。
(サイボウズ式　「エンジニア100人に聞きました」始めます。より)

弊社が参加するのは今回で２回目です。（前回はながら聞きについてアンケートをとりました。）

今回のアンケートのテーマは「新人にお勧めする一冊」。
新人エンジニアに読んでほしい一冊を２５名の先輩エンジニアから集めました。

Q1.新人エンジニアにお勧めする一冊を教えてください。

Q2.お勧めする動機を教えてください。（選択式）

Q3.Q1で挙げた一冊以外に、お勧めの本があれば教えてください。

Q4.先輩エンジニアとして、新人エンジニアに贈る言葉をお願いします。