先日無事入籍を終え、結婚式に向けてあれこれ準備が必要になるということで、友人の何人かがやっていたように家庭内でRedmineを導入した。「結婚式準備」プロジェクトを立ち上げて暫く運用していて 最近ようやく運用が落ち着いてきたため、今度は少し欲が出てきた。
現状、チケットが更新されるタイミング・何のチケットが更新されたか等タイムラインでしか把握できない状態になっているので、Slackを使って チケットが更新されたらリアルタイムに通知が飛ぶようにした。最近一部の界隈では家庭内でこういうツールを導入するのもよくある流れになってきたのかなあとは思う(ねーよ)ので、流行に便乗してみようといった所だ。導入・設定に苦戦するかなあと思ったら、元々Redmineが入っている状態から15分くらいで意外とサクッと導入できた。

これまで

家庭内でRedmineを導入したのはおよそ一ヶ月前のことだ。使い方としては、以下のような感じでチケット毎にタスクの進捗状況などを書き込んだりして使用していた。
暫く回してみた感じ、中々良い感じに管理できているなという手ごたえがあった。

そこに今回、より利便性を高めるためSlackを導入しようという算段である。
導入に際し、今後何かとライフイベントが発生する可能性を考慮して、「結婚式準備」「引越し」等プロジェクトごとにチャットルームを作成し それぞれに通知が飛ぶようにした。

結果

以下のような感じでRedmine側で更新をかけると･･･

以下のようにリアルタイムで通知が飛ぶ。デスクトップ上にNotificationも飛んでくれるので便利ですね。

まとめ

大人になると色々と比較的大きめの取り決め事を並行して消化していかないといけない事が多くなってくるので、こういう風に家庭の事も管理しておくと「あーこれも準備しておかなきゃいけなかったー」みたいな抜け漏れも防ぐことができ、且つ計画的・効率的にタスクをこなしていくことができて結構良いのではないかと思った。

参考にさせていただいたサイト様

● Redmineの変更をSlackで通知できるようにする
SlackとRedmineを連携し、登録したチケットの更新を通知する方法 – LIG INC.

● Redmine上の複数プロジェクトをSlackのチャットルームごとに通知
SlackにRedmineのチケット更新を通知する – ZEALOTエンジニアブログ

The post 家庭内のタスクをRedmineとSlackを連携させて管理するようにしたらうまくいった話 appeared first on きのこる庭.

特に「秒間にさばけるリクエスト数って、何をもって秒間●リクエストって言えるのか」 とか、
「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？例えば有線のPCと3Gのスマホだと全然速度違うから、サーバ-クライアント間のコネクションが続く時間も変わってきてしまうんじゃないの？」
とか色々考えていたけど、調べているうちに自分なりに何となくハッキリしてきたので 情報の整理がてら共有。
もしかしたら認識誤りで 間違った事を言っているかもしれないので、その場合はご指摘いただければ本当に嬉しいです。

「秒間リクエストを測る際に、ユーザごとの端末の違いは考えなくて良いの？」について

結論から言うと、サーバが秒間でさばけるリクエスト数はユーザが使用しているネット回線には依存しない。

これは速度の差が発生するのがどこのネットワークにおいてかを考えるとわかりやすいかも。
PCでもスマホでも ユーザ側のネットワークにおける速度が変われど、サーバ側における通信の速度は(PC/スマホごとにネットワーク側で別々の処理が行われていない、またはサーバ側でリクエスト元のIPに対して特定の帯域制限等をしていない 等の限りにおいて)変わらないことがわかる。
以下はそれを示した図である。

ユーザ側のネットワークの帯域制限(図で言うと Aくんの使用しているWiFiのネットワークにおける帯域制限)とか媒体のネットワークは、飽くまでユーザ側のネットワークにおけるものであり、さらに言うと、サーバ自体のネットワーク領域は同じなので、ユーザ側のネットワークの帯域はサーバがさばける秒間リクエスト数には関係しない。

ので、秒間リクエスト数を測る際に 秒間リクエストに直接関わってくるネットワーク周りの問題は、サーバ側のネットワークが提供しているスペック、つまり以下の部分となる。

上記の赤枠で囲まれたネットワーク部分からサーバ間通信( アプリケーション自体のレスポンス、DBサーバのレスポンス速度等 )等を見て最終的なレスポンスの速度を判断し、ボトルネックを見つけて改善し続けていく工程が「秒間●リクエストをさばく」という事の意味なのかなと思った。

つまり「秒間●リクエスト」とは

「秒間●リクエストをさばける」事が保障するのは、その量のリクエストが来た時にサーバがダウンすることなく稼動し続けられる事、及びシステム全体におけるボトルネックの特定が可能になる事( アプリケーションの特定のSQLクエリが重く、結果的にAPサーバで遅延が発生している、各サーバ上では処理に時間がかかっていないがネットワークの帯域のスペックがそもそも微妙でレスポンスが遅れている 等)である。
言い換えると、サービスがユーザにとってサクサク見られるかどうかを”完全に保障するわけではない”。

「秒間で沢山リクエストをさばける＝ユーザがサクサクページを見られる」ではない

勿論、サーバが十分にリクエストをさばくことができないと 待ち行列ができてレスポンスが遅延してユーザがサクサクページを見られないので、サーバが想定されるリクエストを十分にさばけることは最低限保障されている必要があるが、さらにユーザがサクサクページを見られるようにするための工夫は秒間リクエストの話とは別に別途必要になる。
例えば以下のような事を考慮する必要がある。

1. ターゲットとするユーザが主に使用するであろう端末

有線で見れば速いページでも、スマホ媒体向けに提供されている特定の回線で見たら遅い、且つサービスが提供するターゲットとなるユーザがスマホ媒体 なんてこともあるので、(当たり前だけど)ターゲットとする人達が利用するであろう端末での速度面の検証作業は必須になるだろうなあと思う。
それでもって、明らかに媒体に対してコンテンツのサイズが大きすぎる場合は圧縮したりキャッシュを利用したり何なりの手立てが必要になる。

2. ターゲットとするユーザの居住地

基本的にインターネットは様々な異なるネットワークを経由してできているため、距離が遠ければ遠い程 パケットがネットワーク上を移動するのに要する距離・時間が長くなる。
更に、国によっては 海外IPのサーバに対して自動で検閲が入るようになっている関係で遅くなったり、一つの国の中でも南部と北部で異常に重くなったりする事もあるそうなので、特に海外ユーザ向けにサービスを展開する場合は基本的に サービスを提供するユーザに近い場所にサーバを置くのが良いらしい。

まとめ

・ サーバ側で「秒間●リクエスト」をはかる時、ユーザ側のネットワーク帯域までは見ない( ユーザが有線を使っていようが3G回線を使っていようが、最終的に到達するサーバ周りのネットワーク領域は同じで、サーバ側のネットワーク領域側で特別な設定をしていない限りレスポンスの速度も基本的に同じだから )
・ 「秒間●リクエストをさばける」事が保障するのは、その量のリクエストが来た時にサーバがダウンすることなく稼動し続けられる事 と システム全体におけるボトルネックの特定が可能になる事
・ 「秒間で沢山リクエストをさばける＝ユーザがサクサクページを見られる」ではない
・ ただし必要最低限の秒間リクエスト数をクリアできないと 勿論ユーザへのレスポンス遅くなる
・ ユーザがサクサクコンテンツを利用する上で、秒間リクエスト数の話とは別にターゲットとなるユーザの媒体とか居住地は別途考慮する必要はある

…という認識です。

僕自身 まだまだ勉強不足な部分もございますので、「ここの部分根本から認識間違ってるよ」という部分がございましたら、優しくマサカリを投げていただければ幸いです。。。(´・_・`)

The post 「秒間●リクエスト」の具体的な定義がモヤモヤしていたので調べてみた話 appeared first on きのこる庭.

覚えたてのマクロの練習がてらつくってみた。500バイト程度で実装。ファイル出力がなければ400バイトくらい？

(defmacro css (name elems)
  (with-open-file
    (*standard-output* (string-downcase name) :direction :output :if-exists :supersede)
    `(progn
       ,@(mapc
           (lambda (style)
             (let ((elem (car style))
                   (attrs (cadr style)))
               (format t "~a {~%" elem)
               (loop for i in attrs do
                     (format t "~2T~a: ~a;~%" (string-downcase (car i)) (cadr i)))
               (format t "}~%~%"))) elems)) t))

引数には名前と要素のリストを取るようにしよう。要素のリストは CSSの構造が以下のコードのようにネストされているようにする。
2行目で with-open-file関数を呼び出し、3行目では標準出力の使用、アウトプット先などのオプションの指定。
あとは 要素 { … } が 各要素毎にひと固まりとして生成されるように mapをかけてあげる。ここでmapは直接ファイル出力として作用しており、リストを返す必要が無いのでmapcarではなくmapcを使用している。

そんでもって変換用のLispコードを用意する。

; Macro Sample 1

(css
  test.css
  ((".hoge"
     ((background "#F00")
      (border-radius "5px")))
   ("#fuga"
     ((background "#009")
      (color "#FFF")))))

; Macro Sample 2

(css
  test2.css
  (("body"
     ((background "#CCC")))
   ("p"
     ((font-size "10px")
      (margin "3px 0")
      (padding "5px 0")))))

これを先ほどのマクロと共に実行すると、「test.css」「test2.css」という二つのCSSファイルが作成される。

/* test.css */
.hoge {
  background: #F00;
  border-radius: 5px;
}

#fuga {
  background: #009;
  color: #FFF;
}

/* test2.css */
body {
  background: #CCC;
}

p {
  font-size: 10px;
  margin: 3px 0;
  padding: 5px 0;
}

もう少し厳密に書けばファイル出力のあたり関数に分けられるだろうし そもそももっと賢い書き方ができそうな気がするので、「ここはこうした方が良い」という部分がございましたら そっとマサカリを投げて頂ければ幸いです。

The post LispマクロでLispコードをCSSに変換するようにしてみた appeared first on きのこる庭.

本当は「数千万件のデータが入ったテーブルでインデックスを構築したらパフォーマンスが劇的に改善された話」というタイトルで書こうと思ったのだけど、書いているうちに内部構造が気になり出したので上記のタイトルに変更。

まずはパフォーマンスが改善された話から

SELECT A FROM hoge WHERE B = ~~~ ORDER BY C DESC;

hogeは数千万件のデータが入ったテーブルで、その中から結果約4万件程のデータのうち A の部分をSELECT。条件としては、カラムBの値が~~~に合致するときで、更には Cという別のカラムで並び替えるというクエリになっている。

結果的に

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

というインデックスを張ることによって、それまで2分以上かかっていたselect文が 0.1秒～0.2秒まで短縮されたという某赤いモビルスーツも驚きのパフォーマンス改善を見せた。

正直インデックスの劇的な威力に感動して、その喜びをブログにつづろうと思い立った所、以下の疑問が生まれたというのが始まり。

すなわち、

何で↓じゃだめなの？

ALTER TABLE hoge ADD INDEX foo ( A, B, C );

という話(どこかのブログで「インデックスは順序左から書かないと意味無いよ」と書いていたので)。

仮説

なんとなーく最近コンパイラをいじっていて記憶に新しい構文木的なにおいがするなあと感じた。

そこで、MySQLの構文解析機構を調べてみたところ、

案の定字句解析と構文解析をそれぞれFlexとBisonで行っているようなので、勉強がてらMySQLの構文解析ロジックを見てみることにした。

調査

丁度GoogleがMySQLのコードを出していたので、MySQLの構文定義部であるsql_yacc.yyの中身を拝見。

http://code.google.com/p/google-mysql/source/browse/sql/sql_yacc.yy?r=d15790ab618324fb1729aa212b244cad5cb9778f

まずは式全体の構文を探す。1600行目でみっけ。

/* Verb clauses, except begin */
statement:
alter
| analyze
| backup
| binlog_base64_event
| call
| change
| check
| checksum
| commit
| create
| deallocate
| delete
| describe
| do
  :
  :
  :

中には「select」もしっかり定義されていたので、続いてselectを探す。

6638行目から始まっているのがそれっぽい。

select:
select_init
{
LEX *lex= Lex;
lex->sql_command= SQLCOM_SELECT;
}
;

/* Need select_init2 for subselects. */
select_init:
SELECT_SYM select_init2
| '(' select_paren ')' union_opt
;

どんどん掘り下げていった結果、だいたいこんな感じになりました。

考察

選択するカラムと where句、order by句、 having 句、group by 句などの条件が明確に分断されていました。

つまり、select_from の部分は、よくあるコンパイラの factor = ( expression ) 的な感じで先に解析されていて、解析が終了した後でSELECT_SYM とがっちゃんこするのではないかと予想(定かではありません)。

こう考えると

ALTER TABLE hoge ADD INDEX foo ( B, C, A );

になるのはそこまで不思議な話ではないかなと感じた。

実際はどうだったのか(2014.03.26追記)

記事の公開後、友人から「covering index 的な話では」とご指摘をいただきました。

Covering Indexに関しては 以下の記事がとても参考になった。

MySQLでインデックスを使って高速化するならCovering Indexが使えそう

もう少しDBまわりの勉強もしないとなあと思いつつ、また新しいことを勉強させていただいた上にMySQLの内部構造にもちょこっと触れられたので 結果としては良かったかなと思った。

The post 【MySQL】インデックス指定の順序が気になったので、MySQLの構文解析ロジックを検証してみた話 appeared first on きのこる庭.

上記の構文規則に基づくとすると、
10 + 20 * 5 + 10 * (1 + 1)
の再帰ルーチンは以下のようになる。
(なお、 expression(), term(), factor() はそれぞれ上記の構文規則を実装した関数 )

簡単な解説

再帰的下向き構文解析って？

コンパイラとかで構文を解析する時に使う方法の一つ。

例えば以下の図は再帰的下向き構文解析を行うための簡単な規則の例です。

ここで使用しているそれぞれのワードについては以下の式を考えると分かりやすいかもしれないです。

10y + 3/5(10 + 10)

数学では 10y とか 3/5 とかのことを「項(term)」と呼ぶけど、
10y, 3/5 というのは
複数の変数・数値を割って成り立っているものなので、

10y = 10 * y
3/5 = 3 / 5 * (10 + 10)

というように、
項は 複数個の 割り算 または かけ算 によって成り立つ一つの単位として考えられるので、上記のような構文規則になります。

この項を足したり引いたりしたものをここでは「式(expression)」と呼びます。

10y + 3/5(10 + 10) は式です。

「あれ？そうすると ( 10 + 10 ) は式じゃないの？」
となりますが、こちらの 10 + 10 も立派な式です。
ですが、最初の expression() の段階では計算しません。
項を更に分割した単位である「因子(factor)」まで分解して 因子にたどり着いた段階ではじめて 式に変換して計算を開始します。

因子については、上の式で言うと

10, y, 3, 5, (10 + 10) にあたります。

10, y, 3, 5 はそれ以上分解できない「定数」「識別子」としてそのまま処理され、
括弧がついている場合は「その中に式がある」と判断して計算を開始します。

The post [Cコンパイラことはじめ] 再帰的下向き構文解析の再帰ルーチンがいまいちイメージできない人に送る記事 appeared first on きのこる庭.