散髪ログ

めずらしく奥さんに言われる前に我慢できなくなっての散髪。前回が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

賞与的なもの

の支給日だった。

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

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

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

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

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

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

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

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

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

kenchan聖誕祭 in 熱海

6/21と言えば皆さんご存知のことと思いますが、息子と私とウィリアム王子と高校の同級生の誕生日ですね。

今年はHackathon準備委員会のご好意(?)により、6/21 00:00から「kenchan聖誕祭」なるイベントを企画していただき、会社のみんなに誕生日を祝ってもらいました!

実は夕飯食べたあたりから非常に体調が悪くなってまずいと思っていたのですが、なんとかアルコール消毒が成功したようで無事聖誕祭を満喫できました。

定年まであと4年となりましたが、このまま意識を高めていけばなんとか定年は免れることができるんじゃないかなぁと思っていますので、今後ともみなさん宜しくお願いします!

一応ウィッシュリストのURLをはっておきますね。 https://amzn.to/kenchan-wl

熱海でHackathon & Rails Battle

6/20-6/21の2二日間、熱海の芳仙閣という旅館で、社内ツールのHackathonとRails Battle 2013が開催されました!

私は、リポジトリだけ作ったけど進められずにいた「fluentdから某チャットサービスへメッセージ投げるためのプラグイン」を動くようにして、 おまけで某チャットサービスにその受け口を作るというのができたので大変満足。

その過程で、某チャットサービスのサーバ側のコードをだいぶ読んだので勉強にもなって一石三鳥くらい。

このプラグインはお仕事で使いたかったやつなので、まずは週明けにテスト環境につっこんでみて様子を見てみよう。

今は private repo にあるけど、某チャットサービスが公開されたら public にする予定。

Rails Battle については、今年は始めてのペアを組んでの対決だったけど、当日発表されたペアで制限時間内にアプリケーションを作り上げるってのは予想以上に練度が必要なんだなぁと見ていて思ったのでした。

ちなみに、優勝は @chibamem & @akiinyo ペアでした!おめでとうございます!

あと、事前準備を中心になって進めてくれた @hide_nba と @t_wtnb と、車の運転の @chibamem 、ありがとうございました!

今回は、参加したくても業務の都合等で参加できなかった人もいたので、近いうちにまたやりたいですね。

(聖誕祭については別エントリで)

靴が左右バラバラだった

初めての経験だったので記録しておこう。

片方白で、もう片方は黒だったのでかなり目立ってたと思う。

呑んでたわけでもないのになんでこんなことに…

TDDBC長岡 1.0 でTAをしてきた

ついに開催された TDDBC長岡 1.0 で、ペアプロデモとTAという形でお手伝いしてきました。

せとあずささんとのデモは、Eclipseの設定忘れがあってもたもたしてしまうことに。

デモ自体は無難にできたような気もするんですか、ちょっとわざとらしすぎましたかね…

午後はRubyの2ペアのTAという形で見てたんですが、プライベートでRuby書いている人たちばかりだったので、それほど口を出すこともなく…

  • Rubyでクラスを判定するのはあまり筋がよくないよ
  • RSpecについて調べたかったら RSpec - Relish を見るのがいいよ

というくらいしか役にたった記憶がないような。

あまりにみなさんが優秀だったので、こっそりお題をやってみたり。 成果はこちら。途中までだけど。

kenchan / tddbc_nagaoka_java_version_parser

終わったあとの懇親会、二次会共に、お酒も料理もとても美味しくて、完全に呑みすぎていました。(変な風に絡んでしまった皆様、ごめんなさい)

故郷の方の皆さんと、こういう形で触れ合えてとても嬉しかったので、また機会があればお手伝いしたいと思います!

散髪ログ

近くの美容院が結局深夜営業を再開したみたいだったので夜に予約して散髪。

前回は3月3日だったので2ヶ月半くらい。すごく伸びた気がしてたんだけど、そんなでもなかったのかな。

Ruby 2.0.0-p195

Ruby 2.0.0-p195がリリースされて、さらにruby-buildもすぐにタグが打たれたので、esm-overlayのruby-buildを更新して入れたのでした。

MacにTDDBCの環境を作った(Java, Eclipse)

TDDBCに向けて、デモの環境をMacに作ったのだった。

自前のMacはSnow Leopardのまま凍結されてしまっているので、JDK 7が入れられなかったり、Quick JUnitとGrowlの連携がうまく動かなかったりと思ったような環境にできなかったけど、とりあえずデモができるくらいの環境にはなった気がする。

ところで、KeyCastrの代替ソフトって今あるんですかね?(旧いdmgみつけて入れてみたけどまともには動かなかった)

Funtoo Linux インストール講習会本番

まずは、当日の参加者の皆さん、会場を提供してくださったEngineYard様、ありがとうございました。

全員がブートまでは行けた前回に油断した結果、今回は何名かkernelのビルドが終わらないまま終了してしまいました。

前日の素振りでdebian-sourcesのbinaryフラグを付けた場合のビルド時間がやばいことには気付いていて、当日はCPUの割り当て数をなるべく多くしてもらったんですが、それでもマシンスペックによっては数時間コースになってしまい時間内に終わらず…

前回はgentoo-sourcesでカーネルのオプションもある程度整理したものをビルドしてもらっていたんですが、そうするとどうしてもブートしないマシンが出てきたりしてしまうので、今回はFuntoo Linux Installation ドキュメントをなぞることにしようとしたのが失敗といえば失敗ですね。

ただ、その長いビルド時間を利用して補足説明や、普段私達がどんな感じで使っているのかを紹介できたので(今までも軽くはやっていましたが)、今後のFuntooライフに役立ていただければと思います。

VirtualBoxコースを見ていてのメモ

  • BIOSでCPUの仮想化オプションが無効になっている場合があるので最初に確認してもらう
  • インストールのときはなるべく多くのCPUを割り当ててもらう(コア数の半分くらい)
  • debian-sourcesのbinaryフラグ付きビルドはディスクを大量に食うので20Gくらいは開けておく
  • どうせみんな同じ環境なんだから、kernelのオプションを決めて自前でビルドしたほうがいい(準備の時間…)

もしかしたら次回があるかもしれないし、参加者の皆さんからは「普段の使い続け方についてもっと知りたい」という声もいただいたので、今後ともよろしくお願いします。

TDDBC長岡に向けたミーティング

TDDBC 長岡でのデモの打ち合わせをしていた。

題材からデモの流れ、どこでどういう説明をするのか、みたいなのを整理しながら、最後に軽く通してみて終わり。

@t_wada さんや @setoazusa さんがどういう問題意識を持っているのかもわかって大変勉強になった。

これがちゃんとできればいいデモになりそうなので、あとは私のEclipseリハビリだけですね…

プロジェクトの歓迎会

プロジェクトの歓迎会で一回休み。

数カ月前からぜんぜん咳が止まらないのでいいかげん病院に行ってきたのだった。

連休明けだから午前中を完全に潰す覚悟でいったけどそんなに混んでなくてよかった。

喉もはれてるから、まずは咳を止めましょうということでちょっと強めの咳止めをもらって終わり。

GW後半終了のお知らせ

5/3にはプラレール博へ海浜幕張まで。3時くらいに着いた段階でも入場には10分くらいかかったかな。 中はそれはそれは大変な感じになっていて、とりあえず一周見てから、奥さんはお土産を買いに、私と息子は比較的空いてる広いスペースでひたすらプラレールを眺めていた。

(下の写真は閑散としているエボルタエリアの様子です)

丁度入場口が閉まるくらいの時間になったので、ためしに入口まで戻ったらだいぶ過疎っていたので、それからスタンプラリーを開始して、最後に一番空いているアトラクション(3つの箱の中から車両を一つずつ取って、おなじ車両だったら金メッキの車両がもらえるというビンゴゲーム)を1回やったが、息子に事前情報を与えすぎたため、中を覗きまくるという恥しい感じになってしまった…

「中を見ないで取って」としつこく言っていたら、ピカピカのプラレールが欲しかった奥さんにうるさいと言われたが、子供だからってルールを無視するのはよくないと思うんです!!1

あとは、幕張限定の連結バスにも乗れたので息子はだいぶ満足だったみたい。帰ったらみんな疲れ果ててすぐに寝てしまったのと、翌日(5/4)はだいたい死んでいた。

5/5は子供の日なので息子と外に出て、ヨーカドーの海老の大きさに比例して価格が決まる寿司(もちろんそれだけじゃないが、安い方だと海老が小さい)とオランダ家のケーキを買って帰宅。

そして今日は、たまには外でゆっくりしてこいと言われたので、お言葉に甘えて淡路町のスタバでもくもくしながらこれを買いているのであった。

Sidekiqを使った非同期処理のテストについて

まとめ

sidekiqを2つのRailsアプリケーションで使ってみて、テストの書き方と残し方について思うところがあったので書いてみます。

  • 特別な事情がなければsidekiq/testingを使うべき(sidekiq/testing/inlineは使わない)
  • 非同期処理そのもののユニットテストはMyWorker.new.performで書けばよい
  • 非同期処理をキックする側のユニットテストはMyWorker.jobs.sizeを検証するだけにする
  • エンドツーエンドテストでは「全ての非同期ジョブを実行する」というようなstepやメソッドを作ってそれを呼ぶ

sidekiq/testingsidekiq/testing/inlineについて

sidekiqのwikiには、テストのための仕組みとしてsidekiq/testingsidekiq/testing/inlineの2つがあり、**「どちらか選んで使え」**と書いてあります。

それぞれの実装を読んでもらえばわかりますが、

  • sidekiq/testingはジョブキューをArrayで潰して非同期処理が実行されなくする
  • sidekiq/testing/inlineはワーカーの処理を同期実行する

という動きをします。

ぱっとみsidekiq/testingはユニットテスト、sidekiq/testing/inlineがエンドツーエンドテスト向き、のように見えますが、両方ともsidekiq/testingを使うべきだと私は感じました。

  • requireしただけで有効になってしまうのでspec_helperで切り分けるのが困難である
  • 同期処理を前提としたテストを書けてしまう(実際に書くかどうかは別として)
  • エンドツーエンドテストでは後述の仕組みを使って、明示的に非同期処理を走らせたほうがテストの意図を表現しやすい
  • テストを書く上では非同期処理の先を気にしなくていい場合の方が圧倒的に多いのに、その全てでperformをstubするのが面倒だし意図が捕みにくい

というところで、sidekiq/testingを使ってどうやってテストを書いていけばよいか紹介します。

非同期処理の処理内容のテスト

非同期処理の処理内容は簡単で、testing-workers-directlyの項にあるように直接performを呼べばよいです。

describe S3UploadWorker do
  let(:worker) { S3UploadWorker.new }

  describe '#perfome' do
    it { expect { worker.perform() }.to change(...) }
  end
end

非同期処理の実行をキックする方のテスト

非同期処理の実行をキックする側は、sidekiq/testingの流儀に従ってジョブキューに処理が入ったことだけを検証するようにしましょう。

例えばImage#uploadS3UploadWorkerを使ってS3へのアップロードを非同期化していることを検証したい場合は以下のように書けばよいでしょう。

describe Image do
  let(:image) { Image.new(...) }

  describe '#upload' do
    it { expect { image.upload }.to change(S3UploadWorker.jobs, :size).by(1) }
  end
end

これだけだとジョブがいつまでも残ってしまうのでspec_helper等にclean_allを呼ぶコードを入れておきましょう。

config.before(:each) do
  Sidekiq::Worker.clear_all
end

エンドツーエンドテスト

では、非同期処理も含めたエンドツーエンドテストはどうすればいいでしょうか。

sidekiqのwikiを読むとdrainというクラスメソッドがあります。これを使います。

  • Sidekiq::Worker.drainは特定のワーカーのジョブキューに溜っているジョブを全て実行します
  • Sidekiq::Worker.drain_allは全てのワーカーのジョブキューに溜っているジョブを全て実行します

request specsならばこれらを直接、cucumberやturnipであれば以下のようなステップを作って明示的に呼び出すようにします。

step 'バックグランド処理を全て実行する' do
  Sidekiq::Worker.drain_all
end

この方法は、非同期処理の完了を待ち合わせをしたり、適当にsleepを入れたりしなくてもいい上に、テストの意図も表現しやすいのでお勧めです。

おわりに

今回のエントリは、実際にお仕事で別々のテスト戦略を選択したRailsアプリケーションに機能追加や修正をしてみたところ、sidekiq/testing/inlineは安易に選択しないほうがよさそうと思ったのがきっかけです。

sidekiq/testing/inlineを選択した場合は、以下のような問題が起きる可能性を考慮しなければなりません。

  • 非同期処理がいらないところにすべてstubを仕込まないといけない
  • 実行されてもされなくてもいいところでは全て実行されるので、スローテスト問題になりやすい
  • 同期実行される前提でテストが書かれる可能性がある
  • 非同期処理の先も含めてのユニットテストが書かれてしまったりする

「そんなの書かねーよ」と言われればそれまでですが、こういう書き方ができてしまう方法を選択しないほうがよいにこしたことはないと思います。

というわけでみなさん非同期処理のライブラリとしてsidekiqを選択する場合は以下のような方針でテストを書いみるのがよいのではないでしょうか。

  • 特別な事情がなければsidekiq/testingを使うべき(sidekiq/testing/inlineは使わない)
  • 非同期処理そのもののユニットテストはMyWorker.new.performで書けばよい
  • 非同期処理をキックする側のユニットテストはMyWorker.jobs.sizeを検証するだけにする
  • エンドツーエンドテストでは「全てのジョブを実行する」というstepやメソッドを作ってそれを呼ぶ

おわり。

WEB+DB PRESS vol.74

一番よかったのは特集2のMySQL特集で、とくに3章の運用ノウハウと5章のInnoDB-memcachedの話がよかったですね。 早速手元のMySQLを5.6にして、試す準備をしたのでした。

あとは、 @yuki24 さんの英語の話は今まで見た事がない切り口ですごく面白かったし、JavaScriptのメモリリークの話はあとで写経していざというときに供えようと思いました。

4774156078.01.MZZZZZZZ.jpg

GW前半終了のお知らせ

今年は余分な休みなど取らずに暦通りにしたので、すでに前半が終わってしまっていた。

だいたい普通の休日と同じように息子と外にでたのと、日曜は久し振りにヒルトン東京ベイのデザートビュッフェへ。

奥さんがそこのクロックムッシュが好きだったのでたまーに行っていたが、数年前に無くなってしまったのであった…

息子はメロンのゼリーを3個にサンドイッチやケーキなど、お腹がパンパンになるまで食べていた