アイアンボトムサウンド杯と弊社艦これインフラについて

11月の初めての更新になりますが、このような状況になってしまった原因である「アイアンボトムサウンド杯」についてまずは書こうと思います。

アイアンボトムサウンド杯とは

アイアンボトムサウンド杯とは、艦これ秋の特別イベント「決戦!鉄底海峡を抜けて!」の第4海域が未クリアだった@nsgc提督と@hrysd提督が、母港拡張を賭け、11/21〜11/27の期間で対決をするというイベントであった。

また、イベント最後の週末ということもあり、E-4、E-5への挑戦する提督が多数現れちょっとした祭となった。

参加した提督は以下の通りである。

  • E-4: @nsgc, @hrysd, @m_pixy, @htkymtks
  • E-5: @ursm, @hide_nba, @kenchan

今回は、母港拡張をかけた2名だけではなく、総勢7名の作戦となった 広義のアイアンボトムサウンド杯 と、弊社の提督活動を支えるインフラについて紹介する。

弊社艦これインフラについて

提督の活動を支えるインフラは以下の2つである。

  • idobata
  • Google Hangout

idobataの艦これルームには、便利情報を通知してくれるGeneric Hookがあり、公式やまとめブログの情報などが自動で流れてくるようになっている。

また、お互いの指揮を披露する場として、Google Hangoutの画面共有を積極的に活用している。夜になるとどこからともなくidobataにURLが貼られ、多い時では6名くらいの提督が集まって、各自が艦隊の指揮を取りながら他の提督の様子をウォッチしている。

アイアンボトムサウンド杯の結果

肝心のアイアンボトムサウンド杯の結果だが、両者の事前準備があまりにも惨々だったため、2名ともクリアできないという斜め上の結果となった。

ただ、両者がクリアできなかった場合は(何故か)@ursmが2名から母港拡張の権利を得るということになっていたために、狭義のアイアンボトムサウンド杯の勝者は@ursmとなった。

広義のアイアンボトムサウンド杯の結果も以下に記す。

  • E-4失敗: 捨て艦の@nsgc, 大破進撃の@hrysd
  • E-4クリア: 魔法(のカード)使いの@m_pixy, 艦これ最後の良心@htkymtks
  • E-5クリア & 阿賀野: @kenchan
  • E-5クリア & 阿賀野 & 矢矧: @ursm, @hide_nba

なんと、当人2名以外は全員が目標を一定のレベルで達成できるという異常事態であった。

アイアンボトムサウンド杯を終えて感じたこと

初めてのイベント参加となったが、他の提督の指揮や、自身の経験でいろいろと思うことがあったので記録しておく。ただし、全て主観に基いたものであることをあらかじめ断わっておく。

キラキラ付けはストレスにならないならやればいい

E-4は常に戦艦以外をキラキラで出撃、E-5は隠れ疲労回復で出撃、という感じでやっていたが両者で大きな差があるとは感じなかった。夜戦メインというのもおそらく影響があったと思われるが、次回は無理にキラキラを付けるということはやらないと思う。

一方で、隠れ疲労と疲労無しでは、体感ではカスヒット率がかなり違うように感じた。特に最終日など、隠れ疲労回復の時間をケチって出撃した場合の初戦カスヒットはひどいもので、場合によってはA勝利も取れないということが何度かあった。

決戦支援は高レベルのほうがよい

E-5の決戦支援は、最初「駆逐2+ちとちよ」のレベル50-60を使っていたが、同じ構成で平均レベル80超えの@ursm提督とのダメージ差があまりにあったため、「駆逐2正規空母2」のレベル70-80にしたところだいたい同じダメージがでるようになった。空母の艦載機はたしかに@ursm提督のほうが充実していたが、ステータスの数値差を遥かに超えるダメージ差だったことを記しておく。

まとめ

あまりソーシャルな面が表に出ていない艦これだが、インフラを整えれば十分にソーシャルな遊び方ができるので、まだ上記のような遊び方をしたことがない人がいれば是非試してみてほしい。

また、アイアンボトムサウンド杯の勝者である@ursm提督おめでとう。

秋のエンジニアぶつかり稽古2013を見学

内容については当事者(?)のあんちぽさんが詳しく書かれているのでこれで。「#ぶつかり稽古」という事件について - delirious thoughts

なんというか、とにかくすごかった。あと、冗談みたいなことを本気でやるってのがやっぱりかっこいい。

AWS Casual Talks#1 で発表してきました

(これを書いているのは一ヶ月後の12/1です…)

AWS Casual Talks#1で「Amazon Simple Workflow Casual」というタイトルでLTしてきました。

会場で Simple Workflow を知っているというレベルでも片手で足りるくらいの人数だったような。

開始時点で、これはまずったなと思ったのですが、もう走り抜けるしかないと思い、当初の予定通り「Simple Workflowとはなんぞや」という説明を一切せずに、使っていて困ったところや、いろいろ試行錯誤して解決した話をしてきました。

ただ、話したいことや相談したいことはもちろんこれだけはないので、もしまた機会があればもう少し時間をいただいて、導入的なところから、他にもあるハマり所やTipのようなものを紹介したいなぁと思いました。

他の方の発表や、その後のインターネットの動向を見るに、mBaaSやVPCあたりがやっぱりホットなテーマなんですね。 このあたりは自分はまったくノータッチな分野だったので、一線の人達の話が聞けて勉強になりました。

主催の@con_mameさん、会場のAmazonさん、ありがとうございました!

追記:

gihyo.jpの記事になってました。 第6回 ガジュアルなナレッジ共有でクラウドサービスを使い倒す~AWS(Amazon Web Services) Casual Talks:IT勉強会を開催するボクらの理由|gihyo.jp … 技術評論社

AWS Casual Talks#1 で SWF について LT します

参加登録開始後あっという間に定員となったイベントAWS Casual Talks#1で Amazon Simple Workflow について LT することになりました。

詳しい内容はまだ決めてないのですが、非同期化、エラー処理、イベントの履歴、あたりでよさそうなところを探しているところです。

なんとかカジュアルに参加するのは初めてなのですが、カジュアルとは名ばかりというのは聞いているので、回りに負けないようにカジュアルな話ができるようにがんばろうと思います。

散髪ログ

前回から丁度2ヶ月。

息子と一緒に行ってきたんだけど、終始借りてきた猫状態だった。

息子は2回目の美容院だったはずなんだけど、前回は奥さんがずっと近くいたりトーマスのDVDを見せてもらっていたらしいが、今回は席も少し離れていたしDVDも見れなかったらしい。

だいぶ不安そうな顔をしていたので、美容師さんにも緊張が伝わっていたらしく、終わってから心配されてしまった。

外に出て聞いてみると「また行きたい」と言ってたので大丈夫でしょう。

結婚(式)記念日

ケーキ買って帰ったらサプライズ的なプレゼントを貰ってしまったのであった。

もう5年もたったんだなぁ。今後とも宜しくおねがいします。

YAPC::ASIA 2013

YAPC::ASIAに初めて参加してきました。

印象に残っているトークの感想などなど。

大規模Perl初心者研修を支える技術

圧巻の71人個別指導。

最初から高トラフィックを想定してデータ設計やコーディングをさせるというのは、そういうノウハウがあるからこそできることで、すごく羨ましいですね。

あとは、自身でふりかえれるようにフォローアップしていくというのは、自立的に動けるメンバーを育てるという観点からもいいやりかただなぁと勉強になりました。

ちなみに、これに関係する話が聞ける師弟登壇・新米サムライの集い 2013というイベントが来月開催されるみたいですよ。

僕の考えたFuture Perl

Perl 6、噂話程度にどういう状況なのかは聞いていましたけど、今の状況を整理して聞くことができたのはとてもよかった。

また、Perl 6 の機能を Perl 5 でも使えるような CPAN が出てきていて、その中でよいものを Perl 5 のコアに取りいれていくというのもよいのではという話は、言語のコアでそういうことをやれるとしたらおもしろいなぁ。

YAPC::Asia Tokyo 2013 特別座談会 「Rubyの良いところ語ってください 〜そんなPerlで大丈夫か?〜」

言語の差よりも、プログラマ自身の能力の差の方がずっと大きいからみんながんばれという話。

Rubyだと普通にその辺に言語のコア開発者がぞろぞろしてるけど、これはかなり特殊というか特別な状況というのを実感した。

Railsの影響でRubyには経済圏が出来たというのと、モダンな有償サービスでPerlのサポートは少なくて自分達で働きかけないといけないというのはハッとした。

本当にあったレガシーな話

どこかで聞いたことがあるような大変そうな話だった。 最後のキーノートにも繋る話で、こういうことをやった人を評価する仕組みっていうのが大切なんだなぁと。

Keynote

マネージャーという役職(?)についていろいろと考えさせられるトークだった。

  • 運動部のマネージャーと会社のいわゆるマネージャー
  • 社内政治のハッカー
  • ディレクション
  • リーダーとマネージャー

Ikebeさんみたいなマネージャーのいる会社はきっと楽しい(だけじゃないだろうけど)と思いました。

Closing

なんとなく、そろそろYAPCに参加してみようかなぁと思ったら、「現行体制での最後のYAPCです」と言われて、嬉しいやら悲しいやらという感じ。

RubyKaigi(1stシーズン)の最後にも立ち合ってしまったし、この業界自体がそういう時期にきているのかなぁと、いろいろ考えてしまいました。

まとめ

はじめて参加したYAPCでしたが、

  • インターネットでしか見たことない人の顔と名前がいっぱい一致した
  • Perl ちょっとやってみようかな、という気になった
  • 武蔵小杉の横須賀線からの乗り換え設計した人出てこい

という感じで、とても充実した二日間でした。ありがとうございました!

Sansan様でNiigata.rbの再演

昨年からお仕事でお世話になっているSansan様にてNiigata.rbの再演をしました。

この発表を作る上で今のプロジェクトに影響されているところも沢山あるので、そのあたりの裏話を混ぜたりして話してみました。

発表後の質疑応答のときに「なかなか上手にテストが書けないんだけど、いいテストと悪い(?)テストは何がどう違うのか。どうやったらいいテストが書けるようになるのか」みたいなことを言われたのですが、私の思いとしては

  • describeとcontextが整理されていること
  • そのdescribeとcontextが嘘をついていないこと

で十分じゃないかなぁと思います。

1番目は、ここが整理されていると、エッジケースの漏れがないかとか、仕様のずれや漏れなどがないかとか、一目でわかるのでレビューが楽なんですよね。

2番目は、よくあるのがmockやstubを多用している(せざるをえない)ときですね。 shard_contextとかにも繋がるんですが、せっかく日本語(や英語)で状況を整理して書いているのに、実際にコード見たら「その騙し方はないだろう」みたいになるのがつらいよねという話。 で、多くの場合そういうテストコードは落ちてほしいときに落ちなくて、落ちないで欲しいときに落ちるよね、と。

他にもいろいろ質問をいただいたのですが、外と発表するのとは違ってコンテキストを共有できる状態でのディスカッションはやっぱり話が早いので、こういう機会を増やしていけるといいなぁと思ったのでした。

発表の機会をくださったSansan様ありがとうございました。

60min.第13回「Background Job Worker座談会」

ursmから、このようなものが何故必要なのか、そしてidobataで実際にどう利用しているのか、ということを話してもらった。

なぜ必要なのか

Railsのプロセスはだいたい200Mくらいはメモリを使うので、たとえばそれを32個上げるとするとそれだけで 200M * 32 でだいたい6Gくらいのメモリを使うことになる。(そして、メモリは普通有限なのだ)

たとえば1秒かかる処理があると、同時に捌けるリクエストは32個になってしまい、33個目は1秒後に処理が開始されることになって、レスポンスを返すまで2秒かかる。

これが1秒ならまだいいが、普通、処理待ちをしている間にもどんどんリクエストは来るので、雪だるま式に処理待ちのリクエストが増えていくことだろう。

なので、同期処理が必要ない部分は、積極的に非同期処理に逃がしていかないといけない。

Background Job Workerはどれを使えばいいの?

2013年では以下の4つのライブラリを抑えておけば十分で、それぞれ特徴があるからアプリの特性やインフラと相談して決めるのがいいよということ。

まず、ResqueとSidekiqについて。 仕組みはだいたい同じだが、Resqueは処理がプロセス、Sidekiqはスレッドになっている。

Ruby(MRI)はグリーンスレッドなのとMRIは1.9以降はネイティブスレッドだけどGVLがあるのと、マルチスレッドがらみのメモリリークやバグに悩まされたくないなら、とりあえずResqueという選択でもいいかもしれない。

queue_classicは、ジョブキューがPostgreSQLのPubSubを使っているので、ポーリングしている他のライブラリに比べて仕組みがクール。Redis等を入れなくてもいいので便利。

girl_fridayは、ジョブキューを自身のプロセスの中に持っている。ジョブを依頼する側と処理する側が同じプロセスになるので、ちょっと面白い(強引な)こともできたりする。ただ、Railsのプロセスが落ちるとジョブキューも無くなってしまうので、Redisバックエンドの仕組みを入れておいたほうがいいだろう。

因みに、私はとあるアプリでインフラにあまり手をいれたくなかったので、girl_fridayのオンメモリで実装したことがあります。ただ、それは運用の支援ツールみたいなやつで、「だめなら再実行すればいいからさくっと作ってほしいという話だったからなので、なるべくRedisバックエンドにしましょう。

まとめ

あまりこの辺に詳しくないなら、まずはResqueを使おう。ただ、Sidekiqでも実感できる程の処理の遅さはないと思う。

DBMSがPostgreSQLならqueue_classicは試してみる価値があるよ。

girl_fridayは、仕組みが面白いから教養として使ってみるといいかも。

ちなみに、idobataではSidekiqとgirl_fridayを使っているとのこと。(なんで2つあるのかは、忘れてしまったそうな)

健康診断

今年の採血は痛かった。

最近ちょっと体重が増えたような気がしていたけど、1Kgくらいしか増えてなかった。ただ、お腹回りがたるんできたような気はするので、なにかしたほうがいいのかなぁ。

あとは、目がたぶん悪くなったかも。左右で差があるのはしょうがないにしても、今年は結構自覚できるくらい見え方に差があってちょっと凹んだのでした。(といっても両方1.0くらいはあるけど)

Niigata.rb#3 でテスト駆動開発についてお話してきました

TDDBC長岡で主催の@dictavさんにお会いして「今度Niigata.rbやるならお手伝いさせてください」と話していたので、その約束を果すために「私がテスト駆動開発について思っていること」を発表してきました。

狙いとしては

  • テスト駆動開発という言葉は聞いたことあるというくらいの人に「テスト駆動開発ってこんなことでいいんだ」と思ってもらう
  • 日々テスト駆動開発をしている人には、自分だったらどう考えて、どう書くかを考えてもらう

ことができたら嬉しいなぁと思ってストーリーを考えました。

この思いが、少しでも伝わった方がいれば嬉しいです。

当日のスライドはこちら。

帰省

昔は蒸し暑いなぁと思っていた地元も、東京の暑さを知ってからは快適すぎて昔はごめんなさいという感じ。なにより夜ちゃんと気温が下がるというのがすばらしい。

近況として、まもなく家の前の小学校(実家は、文字通り小学校の校門の目の前にあるのだ)が統合されそうという話と、中学校は既に統合が決まっているという話を聞いて、田舎の厳しさを噛み締めている。

あと、ずっとカナブンが蛍光灯に突撃しててうるさい。

読了「プレゼンテーションパターン」

4766419898.01.MZZZZZZZ.jpg

誕生日プレゼントに頂いた本シリーズ第1弾。

エモいプレゼンはもちろん、テクいプレゼンにも役立つ要素がぎっしり詰まったとてもよい本だった。

今まで他人に勧められるプレゼンの本と言えばプレゼンテーションZenパブリックスピーカーの告白だったんだけど、それぞれ

  • Zenはエモいけどね
  • パブリックスピーカーの告白は具体的な技法とかの話はほとんどないけどね

という但し書きを付けて紹介せざるをえなかった。

しかしこの「プレゼンテーションパターン」は「技法」と「心構え」、その両方がバランス良く紹介されているので、どんな人が読んでも役に立つことがあると思う。

ページ数も少ないので、毎回プレゼンテーションの準備をする前にパラパラ見るだけも、その都度新しい発見があるんじゃないかと期待させる一冊だった。

読了「Webサービスのつくり方」

4774154075.01.MZZZZZZZ.jpg

誕生日プレゼントに頂いた本シリーズ第2弾。

立ち読みでパラパラ読んではいたんだけど、その時の感想は「この業界に興味のある人が一冊目に読む本としてはすごくよさそう」というものだった。

しかしちゃんと読んでみると、Webサービスを作り始めるところから公開した後まで、数多くのサービスを公開してきたゆーすけべーさんのノウハウの断片がちりばめられて、どんな人が読んでも勉強になることが多い本だと感じた。

また、もっと深く知りたい人向けの参考文献のチョイスも流石で、もちろん初学者の人にもお勧めできる。

ただ、唐突に「いかにおっぱい画像を」というような章が始まったりするので、電車の中で読むときは最新の注意が必要である。

散髪ログ

めずらしく奥さんに言われる前に我慢できなくなっての散髪。前回が5/16だったので2ヶ月半くらい。夏だしまぁこんなもんかな。

mysql2を 0.3.13 に上げて苦労した話

今のプロジェクトは Jenkins に bundle update した上で Pull Request させる - @kyanny's blog を参考に10弱くらいのリポジトリを週1で bundle update してるんですが、今朝のアップデートで mysql2 があがってちょっとだけはまったのでメモ。

問題が起きたのは、SELECT SUM(column_name) AS s FROM table_nameという感じでSQL的にSUMしたときなんだけど、もしかしたらSUM以外でも影響あるのかもしれない。

0.3.11では、SUMを入れると必ずBigDecimal(ただしfloatを除く)だったのが、0.3.13だと「その数値を表現するのに必要十分な型」で返すようになったような印象。

地味にDecimalのprecision: 10, scale: 0の結果が変わってるのがちょっと疑問が残るところ…

以下に例を上げておきますので「そうじゃねーよ」ということなら教えてください>< (ちなみに、Railsは3.2.11です)

以下のようなモデル(Point)があったとして、それぞれどんなかんじになるかというと

class CreatePoints < ActiveRecord::Migration
  def change
    create_table :points do |t|
      t.integer :i
      t.float :f
      t.decimal :d1, precision: 5, scale: 2
      t.decimal :d2, precision: 10, scale: 0

      t.timestamps
    end
  end
end

0.3.13の結果

irb(main):001:0> Point.create(i: 1, f: 1.1, d1: 1.2222, d2: 1)
   (0.0ms)  BEGIN
  SQL (0.3ms)  INSERT INTO `points` (`created_at`, `d1`, `d2`, `f`, `i`, `updated_at`) VALUES ('2013-07-22 11:30:40', 1.2222, 1, 1.1, 1, '2013-07-22 11:30:40')
   (0.1ms)  COMMIT
=> #<Point id: 1, i: 1, f: 1.1, d1: #<BigDecimal:7f930db7b4a0,'0.12222E1',18(45)>, d2: 1, created_at: "2013-07-22 11:30:40", updated_at: "2013-07-22 11:30:40">

irb(main):002:0> Point.select("SUM(i) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(i) AS s FROM `points` LIMIT 1
=> 1

irb(main):003:0> Point.select("SUM(f) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(f) AS s FROM `points` LIMIT 1
=> 1.100000023841858

irb(main):004:0> Point.select("SUM(d1) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d1) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f930db243d0,'0.122E1',18(18)>

irb(main):005:0> Point.select("SUM(d2) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d2) AS s FROM `points` LIMIT 1
=> 1

0.3.11の結果

irb(main):001:0> Point.create(i: 1, f: 1.1, d1: 1.2222, d2: 1)
   (0.0ms)  BEGIN
  SQL (0.3ms)  INSERT INTO `points` (`created_at`, `d1`, `d2`, `f`, `i`, `updated_at`) VALUES ('2013-07-22 11:30:40', 1.2222, 1, 1.1, 1, '2013-07-22 11:30:40')
   (0.1ms)  COMMIT
=> #<Point id: 1, i: 1, f: 1.1, d1: #<BigDecimal:7f930db7b4a0,'0.12222E1',18(45)>, d2: 1, created_at: "2013-07-22 11:30:40", updated_at: "2013-07-22 11:30:40">

irb(main):001:0> Point.select("SUM(i) AS s").first.s
  Point Load (0.1ms)  SELECT SUM(i) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31daaf1730,'0.1E1',9(18)>

irb(main):002:0> Point.select("SUM(f) AS s").first.s
  Point Load (0.3ms)  SELECT SUM(f) AS s FROM `points` LIMIT 1
=> 1.100000023841858

irb(main):003:0> Point.select("SUM(d1) AS s").first.s
  Point Load (0.2ms)  SELECT SUM(d1) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31da9b7e28,'0.122E1',18(18)>

irb(main):004:0> Point.select("SUM(d2) AS s").first.s
  Point Load (0.3ms)  SELECT SUM(d2) AS s FROM `points` LIMIT 1
=> #<BigDecimal:7f31da98b440,'0.1E1',9(18)>

Bluetoothデビュー「SBH50」

そろそろ音質()よりも利便性を取りたくなってきたお年頃なので、Bluetoothヘッドセットを買いました。

アキヨドで店員と話した感じだと、AT-PHA05BT はやっぱり鉄板で、次点で HA-FBT60 ということだった。

後者のやつはノーマークだったのでいろいろ聞いてみると

  • 3種類あるけど受信機は一緒でイヤホンが違うだけ
  • これに付いてるイヤホンが一番コスパがいい
  • クリップのところが金属だから折れない

というあたりがオススメポイントらしい。

ただ、よほどの掘り出しものがなければ SBH50 にしようと決めていたので結局これを購入。

3日くらい使ってみた感想は概ね満足。思ったことを以下に書いてみるので、参考にどうぞ。

  • ペアリングが切れたりすることもほとんどない(と思ってたら今日謎の切断があった…)
  • 商品紹介にある Twitter や Facebook の通知を受けとるには「スマートコネクト」なるアプリを入れないといけないけど、これはこれで便利だった
    • ペアリング開始したら自動で音楽プレーヤーを起動したり
  • ディスプレイには日本語もちゃんと出るが、日本語の読み上げはしてくれない
  • NFC はペアリングを変えたりしないので使ってない…

付属のイヤホンはだいぶ残念な感じだけど、イヤホンを取り替えられるタイプのやつを買う人は大抵好きなイヤホンを使うと思うので、7,000 円で有機ELディスプレイ付きならまぁ満足できるのではと思います。

読了「白と黒のとびら」

RubyKaigi 2013 で見て以来ずっと気になっていたんだけど、予想よりもずっとずっと面白くて2週くらい読んでしまったのでした。

私のように、一応情報系の大学は出ているけどコンピュータサイエンスを真剣に勉強してこなかった人にぴったりな感じ。

最後の方はかなり難解な言語が出てきて頭を抱えながら読んでみたけど、「とりあえず流し読み、最後の解説を読む、本編もう一度読む」とするとだいぶ理解が深まるのでオススメ。

参考文献も丁寧に紹介されていて、もっと深く勉強してみたいと思わせるようなすばらしい本でした。

4130633570.01.MZZZZZZZ.jpg

Plan 8 と 外付けドライブを買った

月曜か火曜くらいにPlan 8は届いんたんだけど、我が家のPCの光学ドライブが全滅してしまっていて取り込めずにいたのでした。

しょうがないのでAmazonで一番上に出てきたBUFFALO Boostケーブル搭載 ポータブルDVDドライブ ブラック DVSM-PC58U2V-BKを買って、取り込みは無事に完了。

最近のは小さくて場所もとらないし、USBケーブル一本で電力が足りないときは視覚的にわかるようになっていたりと、だいぶ便利になっているんですね。

賞与的なもの

の支給日だった。

今年は、13年連れ添った洗濯機を買い替えようという話をしてるので、その資金になる予定。

そろそろ上京したときから使い続けてる家具とか家電とかが寿命になってきているので、他にも買い替えたほうがよさそうなやつは買いかえちゃおうかな。

奥さんになんか欲しいものあるか聞いたら「ケーキ」と言われたので、タイムセール的なスイーツセットを買って帰ったのだった。

来期もがんばりましょう。

WEB+DB PRESS vol.75

特集1のペパボのいい話はとてもとても勉強になった。特に「技術的負債がサービスの負債になる」というのはとても説得力のある言葉で、身の引き締まる思い。

あと、特集3の「SPDY & HTTP/2.0」と、連載の「理論で学ぶSQL再入門」がお仕事でタイムリーな話題なのでちょうどよかった。

「SPDY & HTTP/2.0」の方は実戦投入はまだまだ先だろうけど、SQLの方は、履歴データがそもそもリレーショナルデータベースでは扱いにくいものだという前提に理由を理解した上で立てたのが収穫。

どこかにいい答えがあるんじゃないかなぁという漠然とした希望を捨てて、ちゃんと現実を見ようという気になったのでした。

4774157198.01.MZZZZZZZ.jpg

誕生日プレゼント着弾のお知らせ

みなさんありがとうございました!(この写真以外にも、パイン飴1kgをどなたかからいただきました)

この大量の豆乳が無くなるまでに、上手に豆腐が作れるようにがんばります:-)

60min.第11回「Vagrantハンズオン」 & 第12回「Client-side MVC特論」

先月5/23に「Vagrantハンズオン」、そして6/27に「Client-side MVC特論」と二ヶ月連続で60min.を開催した。

第11回 Vagrantハンズオン

入門Chef Soloを読んで高まった意識をみんなに振り撒こうと、40分くらい駆け足でVagrantとChefでVMをセットアップしてみて、残りの時間を座談会という感じにしてみた。 自分の問題意識を共有できたし、参加者からは「思ったより簡単だったから自分でも触ってみようと思う」という声も聞けたのでけっこうよかったんじゃないかな。

第12回 Client-side MVC特論

EmberやBackboneを使っているプロジェクトも増えてきたので、急にそういうプロジェクトに参加することになって混乱することがないように、Client-side MVCの基本的な考え方や、なぜ必要とされているのか、みたいなのを、ursmの資料をベースに話してもらった。

Introduction to Ember.js

  • WebのMVCとの違い
  • なぜClient-side MVCが必要なのか
  • Emberはどう実装しているのか

初めてさわる人が混乱しがちな、言葉の定義みたいなの(Emberでいうコントローラとは、など)を整理して話してもらえたので大変勉強になった。

そろそろ、誰か若い人からやりたいテーマが上がってくると嬉しいなぁ。(チラッ

さよならR25カフェ

銀座のR25カフェが今月で閉店するそうなので、某プロジェクトの関係者で最後のコーヒーを飲みにいってきた。

某プロジェクトは自分が初めてリーダーをさせてもらったり、殿として一人で保守開発っぽいことをしたりといろいろ思い出深いプロジェクトで、思い出話に華が咲いて大変よかった。さらに、なんと、当時のお客さんもたまたま都合がついて来てもらえたのがまたよかった。(ありがとうございました)

2、3年のあいだ週1から月1くらいでお世話になりました。期間限定で復活とかなったらまた行きたいなぁ。

鉄道博物館に行ってきた

息子の生誕イベントとして、大宮の鉄道博物館に行ってきた。

到着してすぐのときはなぜかあまり乗り気じゃなかったけど、電車の中に入れることを知ったあたりからだいぶ盛り上ってきてよかった。 恐らく休日は長蛇の列ができているであろうNゲージのジオラマも空いててゆっくりみれたので満足できたっぽい。

お土産は鬼門で、プラレールがリモコンになる謎の装置が売られていて、なんとかそれ以外にさせようと色々見せて、結果としてなぜかSuicaを入れるケース(新幹線の写真)に落ち着いたのだった。

誕生日プレゼントは1年中受け付けておりますので以下のU(ry https://amzn.to/kenchan-wl