読者です 読者をやめる 読者になる 読者になる

たまごかける日報

ここにAA貼りたい

2015の振り返り的なアレ

大晦日

毎年の如くですが、今年も実家に帰っております。
ブログを見てみると去年はインフルエンザにかかってたみたいですね。今年はというと私の母が風邪にかかってしまい一家で年末年始に病気にかかる呪いにでもかかってるのかなと疑ってる私です、こんにちは


今年何やって来年は何を頑張りたいのかな〜とか考えながら自分のブログ見てたら、なんも書いてなくてゲロはいた。

っていうね


今年

仕事回り的な

今年一年のしごと的なアレを振り返ろうとして気付いたのは、今年一回も異動してなかった。
新卒入社4年目だけど1年を通して環境が変わらなかったのは今年が初めてで、抱えてるサービスは相変わらず多いながらも同じサービスに対して半年以上のスパンで継続して関われたのは嬉しかった。今いるのが基盤に関わる部分なので余計にね。

ので、今までとは違った働き方が出来たなと。
特に、ウチの画像配信基盤で抱えてた複数の画像Storage(Voldemort + Swift + WebDAV)を、S3(新規file)+ 独自Storage(Archive file)の構成に変更したのは動き出しから含めて1年以上の長期計画だったので完遂できたのは凄い嬉しかった。レガシーからの脱却とかコスト削減だったりキャッシュと向き合ったりいろいろ楽しかった。

単純な新規立ち上げではなく、ごくアタリマエにあるモノ(特にレガシーの塊的な奴)を改善しながら提供し続けるという難しさみたいなのも実感しつつ学べたしいい経験したな、と。

あとの細かいイベントはうるう秒対応したり、Cassandra Meetup in Tokyo, Summer 2015で喋ったり、Akamai Edge Conference 2015に行かしてもらったり、また会社のAdvent Calendarでクソ記事量産したり、結構好きにやらせてもらって楽しかったなー。なんて。

人回り的な

別に今年に限ったことじゃないんだけど、インフラエンジニアとして尊敬する先輩たちが次の職場で新しいチャレンジを続々としていく状況で、一番の下手くそでいよう派として自分も環境をカエルべきなのか、いやいや自分がココでその立場になるべきなんでしょというのをすごく考えた1年だった気がする。というより、キャリアパスをどうしていくべきなのかみたいな。今は後者で頑張ってる感じ。一周回って考えたんだけど、全然いまも結構な下手くそだった
ので、まだまだやりたい事をどんどんやっていく、、、で!!なんか、エモキモい

来年

去年はちゃんと目標書いてなかった気がする。

  • 英語
  • Blog
  • Code

これかな、、、
Blogというか、アウトプットは本当にしてないと腐る。evernoteに溜め込んだクソクローズドメモとかマジ意味ないなと実感する。ので、少しでも出していく...で

英語は、今年カンファレンスも旅行も含めて海外に行く機会が多かったってのが大きな要因の一つだがエンジニアやってく上で逃げられないなというのを実感してるので目標に...TOEICも受けよう。

Codeはこれからのキャリア的に。ちゃんとかけるインフラエンジニアにならんとなという。こまかくてもいいからGitHubに草生やしていこう。

そんな雑な感じで今年の振り返り終わり。
今年お世話になった人に感謝の気持ちを述べつつ、 良いお年をノシ

おわり

varnishのTransfer-Encodingとのお付き合い的なナニカ

これはVarnish Cache Advent Calendar 2015の21日目の記事です。
ナンカ書こう、と軽い気持ちで参加したらいつの間にか当日になっていました。

何を書くか直前まで迷っていたのですが、最近varnishのAccept-Encodingの扱いでチョト困ったのでその備忘録的なことを書きます。versionは4.1.0-1です。

TL;DR

  • vcl_recvでpipe,passを使っている場合を除き、varnishはdefaultでbackendにAccept-Encoding:gzipを投げる。
    • なんなら、Accept-Encoding:kakeruとか適当にリクエストを投げても、Accept-Encoding:gzipで上書きしてbackendに投げてくれる
  • 奇特な理由があってgzipをoffりたい場合は以下どれかの対応で逃げられる。
    • 起動オプションで、-p http_gzip_support=false
    • vcl_backend_fetchでunset bereq.http.Accept-Encoding;
    • vcl_backend_responseでset beresp.do_gunzip = true;

現象

会社の画像配信基盤のcache層としてvarnishを使わせてもらってるのですが、
とある日にjson fileやcssや画像を配信しているごった煮Backendのみvarnishにcacheさせていなかった所を、他の画像が乗っているbackend達と同様にcacheさせるように変更を行いました。 後日そこの特定Backendへの一部リクエストでエラーがちょろちょろ出るようになっていたので、そこを調べていったよという話。

config変更はこんな感じ

急に出てきたエラーとしては、アプリがTransfer-Encoding: chunkedに対応してないよという感じのエラー。

原因

先に原因を書いてしまうと、以下になる

  • varnishはdefaultでbackendにAccept-Encoding:gzip を送りつけるが、今までpassで設定していたため付与されていなかった。
  • passを外してcachesさせるようにしたので、Accept-Encoding:gzip を付けて対象のbackendへのリクエストを生成するようになった。
  • その対象backendのみ Accept-Encoding:gzip を解釈出来たため、chunked responseを返しアプリであぼんしてしまった。

調査過程

恥ずかしい話、varnishがdefaultでAccept-Encoding:gzip を送りつけるのを把握していなかったので、 誰がAccept-Encoding:gzip を送りつけ始めたのかを調べるところから始まった。

調査方法はみんな大好きtcpdump

passを抜いたことが明らかに原因だったので、
今回はその前後のconfigでの動作の差異を調べる。

ので、varnishが付与してると断定。varnishのgzip回避の設定を調べることに。

ちなみに、
Headerを見たいだけならvarnishlogでも可能。

こっちの方が簡単ですね。

対応

今回の対象backendのみcssjsonなどの圧縮の恩恵を預かりやすいfileの配信を行っているbackendだったが、画像配信基盤全体としての配信内容はほぼほぼ画像コンテンツだったということもあり、画像にgzipは無意味ということでvarnishとしてgzipをサポートしなくても良いかなという結論に至った。

上記を踏まえた対応方法としては以下の3つぐらいかな。

  • varnishのgzipサポートをそもそも切る
    • varnishdの設定で、-p http_gzip_support=false にする
  • varnishがbackendにAccept-Encoding:gzipを送らないようにする
    • vcl_backend_fetchでunset bereq.http.Accept-Encoding;の記述を追加
  • gzipでbackendからgetしてきたコンテンツを解凍してキャッシュとして保存する
    • vcl_backend_responseでset beresp.do_gunzip = true;の記述を追加

今回は vcl_backend_fetchでunset bereq.http.Accept-Encoding;を追加して対応した。
ちなみに、 do_gunzipは本家でも、なんでそんな事すんの?と書かれるぐらいなので、流石にやらなかった。明らかにナンカ無駄感ありますしね。。

http_gzip_supportをoffに関しては、結局はAccept-Encoding:gzipをbackendに送らないようにするだけなので、そっちでもよかったかも

おまけ

varnishはgzip supportをしている & pipe or passを使っていない場合、
どんなリクエストが来てもAccept-Encodingの中身をgzipで上書きしてリクエストを処理するらしい。

されてた。
Accept-Encoding:kakeruとかのアホなリクエストを投げてもちゃんと上書きされてた。
なるほどです。

といった

ただの備忘録ですが、
こんなアホみたいな所で困ってる人の役に立てれば幸いです

おしまい

参考document
https://www.varnish-cache.org/docs/trunk/users-guide/compression.html
https://www.varnish-cache.org/docs/trunk/reference/varnishd.html#varnishd-1
https://www.varnish-cache.org/docs/trunk/phk/gzip.html

渋谷にいるなら一旦コレ食っとけってカレー達

カレー Advent Calendar 2015の18日目
昨日は @kuwa_tw さんだったけど、まだ記事が見当たらないですね?^ー^

諸君、私はカレーが大好きだ

とか、言っちゃったりしてね。
一部の常にスパイスを持ち歩いてるカレー狂いには遠く及ばないが、 私も結構カレーが好き。ということで、良く行かせてもらってるカレー屋を紹介してく。

職場が道玄坂なもんで、道玄坂近辺のお店が多め。

シブマハール

足りない分の写真 #カレーAdventCalendar #シブマハール #ほうれん草うまぁー

@kakerukaeruが投稿した写真 -

ザ・インドカレー
道玄坂のTOHOの横の通りにある。 螺旋階段を上がった2階に店を構えており、ちょっと入りにくいイキフンを漂わせてる。

が、入ったら気のいいおっちゃんが出迎えてくれる。
こういうお店では定番のいわゆる無限ナン攻撃も堪能できる。 ライスとナンを選択出来るのだが、前に一回ライスを頼んでみたらおっちゃんが明らかに「エェ〜('A`)」みたいな顔してたから、ナンがオススメなんだと思う。知らんけど。

個人的におすすめは、
カレーを2種類選べるランチAセットで 🍤 + ほうれん草 の2種コンボ
ほうれん草が絶妙にスパイス効いてて絶品なのだ〜^

マリーアイランガニー

再訪アリ

@kakerukaeruが投稿した写真 -

スリランカカレー
東急本店から原宿方面へ抜ける通り沿いのマンションの5Fにある。
これまた一見さん的には入りにくいイキフンが出ている。
5Fに上がるエレベーターでは、「あ、今地震来たら確実に死ぬわ」というドキドキ感を味わえ、 店内に入るとテレンス・リーみたいな風貌のイカした店長がいて更にビビる。

接客していただいたらとってもフレンドリー
無駄にビビってごめんなさい

オススメは1日5食限定のスペシャルポークカレー
スパイシーなルーを纏ったトロケるポークの肉塊がドドンとお皿に置かれて出てくる。たまらん。
ポークカレー以外のランチで頼めるカレーも基本的にスパイシーだから、スパイシー好きなら是非行って欲しい。

ネパリコ

ねぱる

@kakerukaeruが投稿した写真 -

ネパールカレー
セルリアンタワーの近くにある。

ネパールの家庭料理、らしいけどそんなことよりもネパリコの🍛めっちゃ体に優しい。
今まで結構スパイシーな🍛ばっかの紹介だったけど、ネパリコめっちゃ体に優しい(二回目

オーダーの時に、辛さを3段階(だったかな)選べるんだけど、愚行。
辛味とか入れずに、そのままの美味しさを味わって欲しい。
ちなみに、メニューに書いてる辛さ3段階ってのは無視できるっぽい。 おっちゃんが言うには「20モ、デキルヨ。デモ、タベラレルカナ~~?^^」との事。
この前、10辛食べたけど、それでも優しかった。
20もきっと優しいと思う。

僕は、なんやかんやのドライカレーが結構好きです。

カイラス

ズルカレー

@kakerukaeruが投稿した写真 -

ザ・日本カレー
道玄坂の交番前の道路を超えたルーニーの隣にある

カレー好きだったらやっぱりインドカレーだよね?^^
とかいう一部偏った風潮が昨今見られるが、 海外のカレーばっか食ってたら日本カレーが食いたくなる、そうですよね?(乱暴

安心できる、誰にでもオススメできる味。
まさに母の味的なアレ J( 'ー`)し

個人的なオススメは、
カツカレー + ゆでたまご + 卓上に置いてあるらっきょう
ありがたや🙏

Curry House チリチリ

安定

@kakerukaeruが投稿した写真 -

最高
大好き、とにかく最高

インド流製法を基本にした体調を整えるカレー。と本家サイトでも謳っている通り、かなり整えてくれる。あぁ〜疲れた〜^整えてぇ〜^という時にかならず行く。

食ってる時も体が整っていくのを感じる。 インドカレーウメェ〜、いや、これは最早チリチリ。チリチリという食べ物。チリチリに体整えられてるぅ〜。 今ならなんでも出来る気がする〜^

というように、こいつトリップしてしまったんじゃねーか、と心配になるような感想が出てくるほどウマい。僕の貧相な語彙力では伝えきれない旨さがある。

だから、一旦行こう。
行ってくれ、な?^^

注文は、必ずhogehogeマサラカレーの方を頼んでください。
一旦、ミックスマサラカレーかチキンマサラカレーを頼んでみればいいと思います。  

チキンマサラ、ほうれん草トッピング!

@kakerukaeruが投稿した写真 -


と、いった具合だ。
渋谷には他にも伝えきれない程たくさんの美味しいカレー屋さんがある。
以下、一例を記しておく

書くときりがないので、ここらへんで、、、
店名部分を食べログのリンクにしてるので、 (わかりにくいかな、、、) 渋谷でランチの際には是非参考にして欲しい。

では、楽しいカレーライフをノシ

おわり

Transportable Tablespace@InnoDBを使ってみたよ

最近飲み歩きたい欲が凄い。
そろそろ3大欲求に食い込んでくるんじゃないかと思ってる。
いや流石に嘘だけど。

というわけで、 Transportable Tablespaces@InnoDBを使ってみたって話。

TL;DR

  • MySQL5.6.6から使えるようになったTransportable Tablespaces@InnoDBつかってみた
  • file-per-tableのテーブルスペースとメタデータの転送でデータ移行ができる
  • ので以下の特徴がある
    • データを直接ポンと置くのでmysqldumpとかよりも早い
    • import時にテーブルスペースの破損check、index再構築などをしてくれる
    • 種サーバからメタデータを作るときは、対象テーブルに共有ロックがかかっちゃうよ

経緯

とあるStorageからMySQLへの移行的なモノを行なっていた。

作業用MySQLサーバで種データを作って本番サーバにデータを配布したいんだけど結構全体容量がデカイのでどうするか悩んでいた。出来れば簡単かつチョッパやでオシャレな感じでデータ配布したい。

そんな折に、MyISAMみたいにfileをcopyしてきてデータ移行が出来るTransportable Tablespaceなる機能がInnoDBにあると知り、試してみることに。

みたいな、ざっくりってるから正確にはチョト違うんだけど、こんな感じのが経緯で触らせて頂くことに。

前提

すべてのサーバで

  • MySQL 5.6.6 以降である
  • innodb_file_per_tableがONになってる
  • ページサイズが一緒

対象サーバ
種鯖:10.10.10.10
本番master:10.10.10.11
本番slave:10.10.10.1[2-5]

aho DBにある tmp_?? みたいな正規表現で引っかかるtable * 256個をよそDBにimportしてみよう。

作業

流れ的には

  • 移行先にテーブルつくる
  • 種サーバで一瞬メタデータ作る
  • メタデータibd fileを転送して、移行先サーバのデータディレクトリに展開
  • importする

簡単ンゴ

なんで実際にやったcommand的なアレをメモしておく。

配布先に空のテーブルだけ作って待ち構えるで

### 種サーバ作業
# tmp_??のテーブル定義抜き出して、転送するよ
$ ssh 10.10.10.10
$ mysql -uroot -N -D aho -e "show tables like 'tmp___';" | cat | xargs mysqldump --no-data -uroot aho > /tmp/aho_tmp___.dump
$ scp /tmp/aho_tmp___.dump 10.10.10.11:/tmp

### masterサーバ作業
## tmp_??のテーブルを本番サーバで作るで
$ ssh 10.10.10.11 
$ mysql -uroot -D test -vvv < /tmp/aho_tmp___.dump > /tmp/aho_tmp___.dump.out

## 対象テーブルに排他ロックかけてテーブルスペースを切り離すよ
## つまり、ALTER TABLE {対象テーブル} DISCARD TABLESPACE; のSQLを作って流すよ
$ mysql -uroot -N -D aho -e "show tables like 'tmp___'" | cat | xargs -i echo "ALTER TABLE {} DISCARD TABLESPACE;" > /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl
# 流すよ
$ mysql -uroot -D aho -vvv < /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl > /tmp/aho_DISCARD_TABLESPACE_tmp___.ddl.out

データを種サーバから配るで

### 種サーバ作業
## 共有ロックかける代わりにメタデータ吐き出すよ
## 複数テーブルのメタデータを一気に吐き出して転送したいから、1個のセッション内で作業してね
## FLUSH TABLES {対象テーブル} FOR EXPORT; のSQLを作って実行するよ
$ ssh 10.10.10.10
$ echo -e "ALTER TABLE `mysql -uroot -N -D aho -e \"show tables like 'tmp____'\" | cat | xargs -i echo -n {},` FOR EXPORT;" | sed "s/, FOR/ FOR/g" > /tmp/aho_ALTER_TABLE_tmp___FOR_EXPORT.ddl
$ mysql -uroot -D aho
mysql> さっき作ったSQLをぺろって貼ってね
mysql> まだexitしないでね!メタデータが消えちゃうよ!

# 別セッションで作業するよ
$ ssh 10.10.10.10
$ sudo ls /var/lib/mysql/aho/tmp_??.{ibd,cfg} | wc -l
512
# 確認してみると、tmp_??テーブル256個分のメタデータtmp_??.cfgがちゃんと256個作られてるよ。この2つを転送先サーバに送るから固めよう
$ cd /var/lib/mysql/aho/
$ tar cfv ../aho_tmp_??.tar tmp_??.{ibd,cfg}

## メタデータ込みのデータを固められたから、もうロック解除していいよ。
# さっきのmysqlのセッションに戻ってね
mysql> UNLOCK TABLES;
mysql> exit
# ちなみに、ロックを解除したらメタデータは消えるよ
$ sudo ls /var/lib/mysql/aho/tmp_??.cfg
ls: cannot access /var/lib/mysql/aho/tmp_??.cfg: そのようなファイルやディレクトリはありません

データをimportするよ

### 本番サーバ全台
## importするデータを引っ張ってくるよ
$ ssh 10.10.10.1{1-5}
$ cd /var/lib/mysql/
$ scp 10.10.10.10:/var/lib/mysql/aho_tmp_??.tar .
$ cd aho
$ tar xfv ../aho_tmp_??.tar
# ahoディレクトリ配下に.ibdと.cfgを設置したよ

### 本番masterサーバ作業
## ALTER TABLE {対象table} IMPORT TABLESPACE; のSQLつくって流すよ
$ ssh 10.10.10.11
$ mysql -uroot -N -D aho -e "show tables like 'tmp___';" | cat | xargs -i echo -e "ALTER TABLE {} IMPORT TABLESPACE;" > /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl
$ mysql -uroot -D aho -vvv < /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl > /tmp/aho_ALTER_TABLE_tmp___IMPORT_TABLESPACE.ddl.out
# メタデータはもういらないから、移行が終わったら消しておこうね
$ rm /var/lib/mysql/aho/*.cfg

まとめ的なアレ

悪くないんだけど、ちょっと制限が多いし手順がちょいちょいあって面倒くさい、、、

でも今回、データ移行時にテーブルのカテゴリ別にちまちま分割してimportしてたんだけど、70GB (table30個、各5000万ちょっとレコード) ぐらいの奴がSAS Raid10でimportに40分ちょっとぐらいだったから、遅くない、、、よね??( •̀ㅁ•́;)

メンテ打ってこのテーブルだけ他のSSDの鯖に移すぜ!とかいうシーンだったら重宝するかな?master分割的な?

あとは今回のケースみたいに、 Archives的な基本的に更新のないデータのStorage移行時とかには、移行用テーブルデータの用意が出来たらポンポン本番に追加していくとかには使えるのかな。

的な。
おわり🍺

参考ページ
14.4.6 Copying File-Per-Table Tablespaces to Another Server

Cassandra Meetup in Tokyo, Summer 2015でお話してきたンゴ

はい

フザけたタイトル&半年以上ぶりのブログの更新ですが、先週の金曜日にCassandra Meetup in Tokyo, Summer 2015に出てお話をさせてもらいました。

DataStaxさん、Yahoo! JAPANさん運営お疲れ様でした!& お声かけ頂きありがとうございました!

イカ、資料

内容としてはタイトルの通りとっても初心者向けで、
Cassandraは怖くないよとお伝えする感じのお話でした。
次、機会があったらもっと変な話もしてみたいな。

ちょっといい話?

僕のセリフみたいになっちゃってますが、
Cassandra meetupの最後にoranie様が解き放った言葉です。

まさにこの言葉の通りでCassandraは何をするにしても日本語の情報が圧倒的に少ない。
日本Cassandra界の天下を取るなら今に圧倒的な貢献をするなら今!といっても過言ではない。

みんなでドンドンアウトプットして、 Cassandra Communityに貢献していこう!(^ω^)
というエモい感じで半年ぶりのブログ更新を締めたいと思います。

おわり

2014の振り返り的なアレ

大晦日

今大阪の実家に帰省してるんですけど、
こっそり何も言わずに帰って驚かせてやろうとか思ってたら、
愛媛のおばあちゃんの家に家族が行ってしまってて実家で一人寂しく過ごしてた僕です。こんにちは。

また家族が愛媛から帰ってきたタイミングで40℃超えの熱を出してしまい、みんなにうつるといけないからと離れに隔離されて、年越しカウントダウンをしていますが僕は元気です。
仕事をしてる身としては体調管理的な意味でアウトですね。。。

今年の厄が一気に大晦日に来たと考えれば、逆に幸先良さそうです。逆にね。('A`)ヴァー

今年

前半

色々動いたなという感覚(異動的な意味で)。
今年のしょっぱなに異動をしたのだが、技術的な事をほぼやっていなかった。
自分のスキル不足のせいもあり、上手く動けておらず、
また技術的なモノを一切業務で触っていない不安から日々焦りを感じていた。
好きな検証とかしてみるもののこれで良いのか、エンジニアとしてゆっくりと死んでるのではないかみたいな。

ただ何も学べなかったわけではなかった、
今思うと技術的なモノ以外の、人と仕事をどう進めるかという大事なことを叩き込んでもらった期間だった。

後半

8月ぐらいになって、
新卒1年目の時に所属していた基盤のインフラチームに異動した。

これは運もあったのだが、異動してから2週間後ぐらいで社内チューニンガソンの若手の部門で1位になれた。
これは僕にとって凄く嬉しい事で、手を動かす仕事に戻ったタイミングでこういう賞を取れたのは幾分か僕の背中を押してくれたんだと思う。 その後のISUCONでは惨敗しましたが^p^

また同じチームの@namikawaさんのお誘いによりMySQL Casual Talks vol.7に出たり、CyberAgent エンジニア Advent Calendar 2014にてIT芸人としての第一歩を踏み出したりした。
IT芸人記事の方は今でも良かったのかとビクビクしながら生活をしています。

まとめ

今までのニートエンジニアだった僕からすると外に出たほうなのかな。
さっきの発言とは矛盾するがちびっとだけ外に出たことにより、より日々の焦りが増したと思う。
だが、良い焦りだとも思う。
この気持を持ち続けていかなければいけないと思う、自戒を込めてね。

これからは継続的にアウトプットしていきたい。
これ、去年も同じ事行ってる気がするな。。。
実績ベースのアウトプットはほぼ皆無ですし、🍣

プライベートは本当に書ききれない人に迷惑を掛けた気がする('A`)ヴァー
精進します。。。

今年お世話になった人に感謝の気持ちを述べつつ、
良いお年をノシ

おわり

エンジニアの僕が三軒茶屋で写真を存分に使ってmcrouter

はい


突然こんにちは!
巷でジャック・ニコルソンの偽物をさせて頂いている@kakerukaeruと申します。

CyberAgent エンジニア Advent Calendar 2014の20日目を書かせていただきます。
昨日は僕の敬愛する先輩である@strskさんのpt-online-schema-changeを安全につかう - Around the Worldでしたね、皆さんチェックされましたでしょうか。
そして、明日は@k66dangoさんの予定です。

というわけで


記事に移ります。

AdventCalendarにはMySQLかCI関係の何かと告知をしていましたが、
この前のMySQL Casual Talks vol.7で上の奴は少しお話してきてしまったので、
せっかくだから違う記事にしようと思います。

で、何を書くかというと
Facebookが今年の9月ぐらいに発表したmemcachedクラスタ化してくれるmcrouter
上の公式ブログに書いてあるのですが、

  • memchaced ASCIIプロトコルサポート
  • コネクションプーリング対応
  • マルチクラスタ対応
  • ヘルスチェック&自動フェイルオーバー
  • 新規node追加時のcacheのウォームアップ
  • etc..

などなど、上げていくとキリがないほど魅力的な機能が紹介されている。
なんと最高で秒間50億のリクエストも捌いてたんやでという逸話つき。

ほんまかいな。
ということで、動作検証から性能検証までを行っていく。

その前に


エンジニアたるものやはりお酒を飲まないと検証が捗らない。
まずはオフィスがある渋谷を離れ、弊社の社員さんもいっぱい住んでいると噂されている三軒茶屋に移動します。

1軒目は先輩におすすめしてもらった
赤鬼 (あかおに) - 三軒茶屋/居酒屋 [食べログ]

お店の外観はこんな感じ。

f:id:kakerukaeru:20141218193224j:plain

えー感じの空気が漂ってますね。
しかし残念ながら満席。
あかん、、、
お酒がないと捗らへんのや、、、
次に、移ります。

2軒目は
ほしぐみフライドキッチン - 三軒茶屋/串揚げ・串かつ [食べログ]

f:id:kakerukaeru:20141220003951j:plain

三茶のゴチャゴチャした三角地帯にあるお店。
気軽に入れて結構リーズナブルなのが好き

f:id:kakerukaeru:20141218200437j:plain

お店の提灯にもドドンと発表しちゃうぐらいおすすめの、
塩煮込みと柚子胡椒トーストは絶品。

発表?
発表といえばこの前LTをした時に使ったDecksetって便利だったなー(棒

ふぅ、お腹いっぱい。
しかし、お酒はそんなに飲んでない。
次行こうか。

3軒目は、
富士屋本店グリルバー - 三軒茶屋/立ち飲み居酒屋・バー [食べログ]

f:id:kakerukaeru:20141218213759j:plain

お肉とワインがオイシイ立ち飲みのお店。

f:id:kakerukaeru:20141218214208j:plain

元々釣り堀だった所を改装したらしいよ。

f:id:kakerukaeru:20141218221152j:plain

お腹いっぱいになってきたからチョットお腹に優しい物食べよか

優しい?
優しいといえば、ハード周り情報を拾うのコマンド纏めてみた
これで急にサーバの保守を依頼された新人さんも安心だー(棒

おいしい幸せ。
しかし、ワインも2杯ぐらいしか飲んでない
これじゃ、本気出せない

4軒目、
やっぱり日本酒が飲みたい
采 (サイ) - 三軒茶屋/立ち飲み居酒屋・バー [食べログ]
またまた立ち飲みのお店。

f:id:kakerukaeru:20141220012129j:plain

お通しからの鳳凰美田
おいしい。

f:id:kakerukaeru:20141220005331j:plain

日本酒入ってる冷蔵庫撮っていい?
ッて聞いたら快くOKしてくれた。多謝

f:id:kakerukaeru:20141220004636j:plain

日本酒大好き。
こういう所はみんなに教えたいけど、本当は秘密にしておきたい。
e,秘密?
秘密といえば、最近ようやくdata_bagの暗号化を始めたなー(棒

そろそろ気分がノッてきた。
今なら検証も出来る気がする

5軒目、
アルフヘイム (ALFHEIM) - 三軒茶屋/バー [食べログ]
個人的に一番行ってる店

f:id:kakerukaeru:20141220012902j:plain

写真撮っていい?と聞いたら
キメ顔してくれた、優しい。

f:id:kakerukaeru:20141220014724j:plain

クラナドというカクテルを注文した。
店主がクラナドというアニメが好きで作ったらしい。
新卒の子にクラナドを見たことがないと告げたら「岩永さん、人生楽しんでますか?」と壮絶にdisられた事を思い出しました。

f:id:kakerukaeru:20141220021837j:plain

もうフラフラ
最期は店主の決めポーズでさようなら

f:id:kakerukaeru:20141220023342j:plain

ふぅ


とってもいいツアーでした。
三軒茶屋はまだまだ他にもいっぱい良いお店があります。
是非飲み歩いてみては如何でしょうか。
弊社社員にばったり遭遇しちゃうかもしれません。

そろそろちゃんと検証記事を書かないと運営に怒られそうだし、
末代までクズエンジニアの烙印を押されそうなので家でPCを開いて本気出して書いていきます。
おっとこんな時間に誰かが来たようだ。うわ、何をする やめr

最期に


ここまで読んでいただきありがとうございました。
辛い道のりを乗り越えた皆さんに、弊社自慢のIT芸人 より2つ目のキーワードの発表です。

f:id:kakerukaeru:20141215111351j:plain

おわり