CentOS6 に MySQL+Mroonga を mysql-build 経由でインストールする

前提

• Docker で MySQL + Mroonga (+ Q4M + HS) な image をビルドしたい
• iwata/docker-centos6-mysql56-q4m-hs · GitHub を踏襲したい

ハマったこと

2.5. CentOS — Groonga v5.0.6ドキュメント を見ると

% sudo rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm
% sudo yum makecache
% sudo yum install -y groonga

するのみでよいと書いてありますが、鵜呑みにして Dockerfile に

RUN rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm && \
       yum makecache && yum install -y groonga

と書くだけでは mroonga の configure がうまくいきません。
mroonga は pkg-config で groonga, groonga-normalizer-mysql を探したがっているので、
groonga.pc が含まれている groonga-devel パッケージも同時に install する必要があるのでした。
groonga-normalizer-mysql についても同様です。

RUN rpm -ivh http://packages.groonga.org/centos/groonga-release-1.1.0-1.noarch.rpm && \
       yum makecache && yum install -y groonga groonga-normalizer-mysql groonga-devel groonga-normalizer-mysql-devel

参考になりました: MySQL 5.5 に mroonga を組込む - 飛光よ、飛光よ

JSON Schema の oneOf / anyOf / allOf

draft v4 の validation keyword たちであるところの xxxOf 三兄弟。
混乱しがちなのでまとめるぞ！

共通点

• object の array であること
• 中の object は JSON Schema として valid であること
• array の中身は１つ以上であること

相違点

(oneOf) An instance validates successfully against this keyword if it validates successfully against exactly one schema defined by this keyword's value.

(anyOf) An instance validates successfully against this keyword if it validates successfully against at least one schema defined by this keyword's value.

(allOf) An instance validates successfully against this keyword if it validates successfully against all schemas defined by this keyword's value.

http://json-schema.org/latest/json-schema-validation.html#anchor75

oneOf

"it validates successfully against exactly one schema"
array のうち、かならずひとつの schema に合致することが条件です。
anyOf と違い、array 中のふたつ以上の schema に合致してしまうと fail します。

anyOf

"it validates successfully against at least one schema"
array のうち、ひとつ以上の schema に合致することが条件です。

allOf

"it validates successfully against all schemas"
array の中身すべての schema に合致することが条件です。

特に oneOf と anyOf の違いが仕様を読んでもぱっと頭に入ってこなかったので、実際に実装までたどってナルホドしました…

いまさらMySQLのcharsetとcollationの話

awesome先生*1に基礎を教わってきたので忘れないうちにメモ。

utf8_unicode_ci / utf8_general_ci

• MySQL で default charset を utf8 に指定すると、デフォルトで選ばれるコレーションは utf8_general_ci
• unicode_ci は文字に対して独自の weight map でもって評価する（general_ci は ascii とコードポイントで評価）
• MySQL で実装されている weight map は１階層のみのため、日本語が入る環境では意図しない挙動をする*2
• utf8mb4 も基本的には同一
  • ただ utf8mb4_general_ci だと絵文字の評価が厳しいので、やるならコードポイントのみで比較する utf8mb4_bin に設定するしかないとのこと

"default" charset の挙動

• 本来 MySQL は charset / collation を column ごとに適用する
• charset / collation の適用は column を生成するタイミング（多くは create table 時）のみ
• column 生成時に default の指定がなかった場合のみ table => database の順に生成条件を参照し、default charset / collation が指定されていればそれが適用される
  • なので、show create database と show create table の charset が違っても慌てる必要はない
  • ただし例え alter で table の charset / collation が変更されても、既に存在する column にその設定は適用されない
• column の charset / collation と connection 時の（client の）charset が一致していれば（もしくは変換可能な定義どうしであれば）不整合は起きない

そのた

• database の charset / collation を見るなら INFORMATION_SCHEMA.SCHEMATA を見るのが便利

勉強になりました。なむなむ

*1:id:kamipo

*2:http://blog.kamipo.net/entry/2015/03/08/145045

Slackでカジュアルにスクリーンショットを投下する

みなさんSlackで日常的にスクリーンショットによる晒しageコミュニケーションを取ったりされているとおもうんですが、
これはそのたびにスクリーンショット.pngが増えていってつらいなーと思っている人向けのエントリです。

方法はかんたん、
⌘ + Shift + Ctrl + 4
で選択範囲を画像としてコピーできるので、Slack上で貼り付け（⌘ + v）するだけでアップロードできます。

こんなかんじ。
えんじょい！

(4/21 追記)
なおGitHubやQiitaもこの機能に対応しているとのこと。はかどりますね！

Webエンジニアの教科書をよみました

.@sasata299 さんからご恵贈いただきました！わいわい！ [pic] ? URL

2015-03-25 13:28:51 via Path

id:sasata299さんよりWebエンジニアの教科書をご恵贈たまわりましたので簡単に感想をば！

ターゲット層

Webエンジニアの教科書、メインターゲットはエンジニア1年生ではないので注意が必要

2015-03-25 16:26:15 via Twitter for Mac

インフラエンジニアの教科書は入門+αといった印象でしたが、
こちらは「はじめに」でも触れられているように、

・2年目、3年目のエンジニア
・フロントエンドをやっているがサーバサイドにも興味があるエンジニア
・サーバサイドをやっているがフロントエンドにも興味があるエンジニア
・フルスタックエンジニアになりたいエンジニア
・最近新しい技術を目にするけど試せていないエンジニア

な皆さんが対象とのことです。
個人的には「自分の明るくない分野に対してのとっかかりをつかむことができる本」だと感じました。
あるていど前提知識があるものとしてお話が進んでいくので、「Webエンジニアのはじめの一歩」としてこの本を手に取るとギャップに驚いてしまうかも。

内容

●CHAPTER-01　Webエンジニアについて
●CHAPTER-02　Ruby on Railsでの開発
●CHAPTER-03　PHPでの開発
●CHAPTER-04　NoSQLデータベース
●CHAPTER-05　フロントエンドの実装
●CHAPTER-06　ログについて
●CHAPTER-07　データの可視化について
●CHAPTER-08　環境構築の自動化
●CHAPTER-09　便利な外部サービス

http://www.c-r.com/book/detail/1006

と、webサービス開発・運用にまつわるさまざまな要素が取り上げられています。

話題のCHAPTER-04(NoSQLデータベース)について

見出しでいちばん食いつかれていた*1のはこの章ではないでしょうか。

ここではまずRDBの概要が説明されたうえで、RDBの不得意なことを補うための選択肢としてNoSQLを検討するべき、とはっきりと書かれていました。
中ではRedisとMongoDBが紹介されていましたが、それらが活きる具体的な例も示されています。
こちらもターゲット層からブレずに、NoSQLが気になっている人向けに踏み込んだ紹介がなされているという印象です*2。

どの章も、いつどういうタイミングでなぜそれを選ぶのか、というところまで説明がなされているものが多く、目的意識を持って読み進めることができました。
新しく触れる技術をより効率的に、詳しく学んでいくためのとっかかりとなる、心強い本です！
ささたつさん、ありがとうございました！

Webエンジニアの教科書

インフラエンジニアの教科書

*1:RDBすっとばしてNoSQLやるの？というような

*2:RDBの入門書なんてそれこそたくさんありますし

いまさらencode/decodeとflagged utf8の話

すでにさまざまな方が論じられておりますが、ちょいとややこしくて忘れられやすいのであらためて。

とりあえず至言をコピペ

入り口で decode して、内部ではすべて flagged utf8 で扱い、出口で encode する。これがすべてです！とにかくこの基本方針をまもっていれば幸せになれます。

http://blog.64p.org/entry/20080408/1207619640

[request]
入力値はすぐdecode
…
なにかしらの処理
…
DBから引いたらすぐdecode
…
なにかしらの処理
…
出口付近でencode
[response]

in/outのdecode/encodeはWAFが肩代わりしてくれることが多いので、レスポンスを返すときにはちゃんとdecodeした文字列を返してやりましょう。

ref:
Perl: 文字コードとutf8フラグについて - @bayashi Wiki
Perl の文字列エンコーディングの話 | Hachioji.pm 日めくりテックトーク
Perl で utf8 化けしたときにどうしたらいいか - blog.64p.org

2014年ふりかえり(技術編)

ぽえむははてぶろのほうに書いたので、技術的な視点でざっくり振り返ってみる。

1-3月

お仕事ではずっとPM業と実装の二足のわらじでかけぬけていた、気がする。
2月あたりはミドルウェアまわりをおさらいしたい！とおもってVPSであそんでいたようす。
なにをしていたかあんまり覚えていないの、よくない！今年はもうすこしログを取る。

4-6月

YAPC::Asia 2014のトークの初期構想みたいなのをハマピーではなしたりした。
Chrome Extension（github issuesでつけたラベルを/pullsにも表示するextension。地味にべんり）をつくってあそんだりもしていた。

7-9月

YAPC::Asia 2014でトークした！初トーク。たくさんフィードバックもいただけて、嬉しいかぎり。
Perl的な話だと、デモに使いたくてこのあたりでまともにAEを勉強しはじめた*1。
@ikeayとおしごとができたのもとっても楽しかった！来年もあんなようなことやりたいなー。

そしてはじめてISUCONに出場して、予選敗退した！くやしい！
やっぱりああいう場では普段できることしかできない、ので、趣味の範囲を拡大していくか、仕事の範囲を拡大していくか、どちらかだと思う。

10-12月

ハマピーとかゴタピーとかに参加した。
ゴタピーではAPIを作るときの話と、テストで気をつけていることの話をしていたのだけど、資料がふっとんだ*2。むねん。
Perlアドベントカレンダーではbitというコマンドを作った話を出して、Minillaではじめて(github.com上に)リリースしたりもした。

12月後半はgolangにも手を出し始めて、かんたんなwebアプリケーション+認証まわりをごりごり書いていた。
golangはまだ手になじんでいないので、もう少しお作法が身についたらいまお世話になっているライブラリにぷるりを投げつけたいなーと思っている。

web屋さんでPerlを書くようになって1年とちょっと、すこしずつエンジニアとしては足場ができてきたようにおもうけれど、今年はもっとエンジニアとしての体力をちゃんとつける1年にしたい。
ずっとAPIとか画面のないものをつくっているので、今年前半は「ふつうのwebアプリ」をひととおり組み立てられるよう*3になっておきたいなーとか、
iOSを1年くらいお休みしているのでそろそろリハビリしないといかんなーとか、
メディアアート方面にももう少しかじりついていたいなー*4とか、
そんなようなことを思いながら三が日が過ぎていったのでした。
ことしもかけぬけるぞー！

*1:そういえばブログにAEのこと書こうとおもってすっかり忘れてた…

*2:知見：http://d.hatena.ne.jp/ar_tama/20141224/1419386670

*3:たとえばセッションまわりとか認証とか、まだまだ弱いなーと感じている

*4:p5 / openFrameworks