garbagetown

個人の日記です

Developers.IO 2017 に参加しました #cmdevio2017

クラスメソッドさんのカンファレンスイベント Developers.IO 2017 に行ってきました。

まったく関係ないけど、会場近辺は一昨年のビッグデータ案件で終電を逃しては缶ビール飲みながらタクシーを拾ったりしていた場所なので懐かしかったw

K-1History of AWS, Still Halfway through

基調講演は AWS 事業部部長の佐々木大輔 (@smokeymonkey) さん。

早速スライドとブログ (と言うかスクリプトと思われるw) が惜し気もなく公開されているので、そちらを参照。

個人的に自己紹介スライドが印象的でした。

  • AWS 事業部長
  • 北海道在住
  • AWS 認定資格・ダブルプロ
  • JFA 公認 C 級コーチ

と、技術力があり、しかし場所には縛られず、ワークライフバランスの充実度が感じられるクラスメソッドさんらしい一枚。

基調講演らしく力強い想いが溢れつつも、しっかりと市場を見定め、かつ確かな技術に裏付けされたすばらしいセッションでした。

ランチセッション

続いてお弁当を頂きながらランチセッション。

クラスメソッド代表の横田 (@sato_shi) さん。

いろいろとリアルな数字の載ったスライドだったので、さすがに公開されないのかな。

前半はこの 2〜3 年でクラスメソッドさんが急成長されていることがはっきりと見て取れる各種数字や、ワークライフバランスを重視した社風などについて、後半はこれからクラスメソッドさんが取り組まれていく VUI についてのお話でした。

佐々木さんの基調講演と同様、ビジョンとビジネスとテクノロジーのバランスがすばらしいなあと感じました。

全体的に非常にリラックスした雰囲気で、「このペースで話すと終わらないね」と時間を気にしつつも、しばしば司会進行役のマーケティング部長嵩原さんとの息の合ったノリツッコミや、いらすとやの話に脱線するのが印象的でしたw

【A-1】 クラメソの請求を支える技術(サーバーレス編)〜40歳中年エンジニアの生存戦略

午後イチは植木 (@czkuk) さん。サブタイトルに惹かれて拝聴w

現時点でスライドは公開されていないようですが、いずれ公開されると思いますので気になる方は http://dev.classmethod.jp/ をしつこくチェックしましょう。

タイトルの通り、急成長するクラスメソッドさんの請求システムを AWS Lambda で短期間に刷新したお話と、中堅エンジニアならでの視点についてのお話。

サーバレスというキーワードだけ切り取るとテクノロジー的にホットな内容を想像しますが、以前は半月掛かっていた請求処理コストをわずか数日にまで削減し、これによって浮いたコストで事務作業に付きっきりだった社員がエンジニアに転向することができたという、地に足の付いた内容でした。

クラウドネイティブな世代にとっては当たり前のことかもしれませんが、以前は自分たちで手を動かして構築・設定していたハードウェアやミドルウェアはどんどんサービスとして提供されており、これらを API でつなぎ合わせるだけでシステムが作れる時代になっているんだなあと再確認させられるセッションでした。

最後に「半径 5 メートルを幸せにする」ことが自分の生存政略とお話されており、不惑ならではの堂々たる安定感を感じました。

【A-2】 基礎からの OAuth 2.0 〜 認証と認可の概念、認可コードとアクセストークンの意味 〜

続いてなぜか変換できませんが、みやもと (@daisuke_m) さん。

スライドはこちら。

技術的な内容の分かりやすさはもちろんのこと、現実世界のメタファの使い方と話の組み立て方が抜群でした。

誰しもストーリーのしっかりした映画や小説、漫画などで「あそこで張った伏線がここで回収されるのか!」と膝を打った経験があるかと思いますが、あれと同じ感じです。とても勉強になりました。

あと、なんかスポットライトみたいにできるポインターが超かっこよかった。

↑これ。ほしい。けど高い。

あまり多用されていませんでしたが、リダイレクトが大量で超むずかしいインプリシットフロー、認可コードフローを説明するときこそスポットライトの機能を使うべきなんじゃ、って思いましたw

【F-3】 今さら聞けないAWSによる監視の世界

ここで 3 階に降りて菅野さん。ツイッタアカウントは非公開もしくは存在しない?

スライドは下記ブログから参照できます。

恥ずかしながら AWS のことはほとんど分からないド素人なので、とても分かり易かったです。

必ず失敗すると言われているデモもしっかりと成功されていました。デモ用 EC2 に cmdevio2017!!!!! というリクエストを送って 404 アラートメール飛ばさせたのは自分です。すみませんwww

【A-4】 Amazon Elasticsearch Service の使いドコロ

最後のセッションは 11 階に戻って藤本 (@a04316) さん。

スライドはこちら。渾身の 108 枚w

内容が盛り沢山で、タイトルには出てこない RDBMS による全文検索転置インデックス形態素解析などにも触れられており、肝心の Amazon Elasticsearch Service については駆け足な印象でした。

個人的には MySQL全文検索ができることや、Elasticsearch の内部構造などは知らなかったので、興味深く拝聴できましたが、この辺りはすっかりご存知で AWS ならではのお話を期待した方には物足りなかったかもしれないですね。

後ほど駆け抜けたスライドをゆっくり拝見しますw

【F-1】 Festivals.IO

参加者全員で会場設営に協力して懇親会。

飲み切れないほど大量のビール (プレミアムモルツ!) と、食べ切れないほどの食事、そしてなぜか光る棒が振る舞われました。

ぽきっと折ると光るようです。ツイッタで教えてくれた @opengl-8080 さん、ありがとうございました!

スポンサー各位の LT を拝聴しながらクラスメソッド社員数名の方とお話させて頂くことができました。お話しさせて頂いた方々、ありがとうございました!もっとたくさんの方とお話したかったですが、またの機会の楽しみにしたいと思います :-)

とても楽しかったです。クラスメソッドの皆さま、ありがとうございました!

#WEBエンジニア勉強会01 で発表しました

WEBエンジニア勉強会 #01 (東京都, 新橋) でお話してきました!

connpass.com

発表資料はこちら。

経緯

4 月中頃に知人の濱野 (@engineer_osca) さんから勉強会を開催するので時間があれば協力してほしいと連絡頂きました。開催は 6 月とのことだったので、5 月 20 日の JJUG CCC までは動けないけど、そのあとでよければ協力するよー、登壇でも LT でもなんでもやるよー、と安請け合いしてしまいました。懲りない人ですね。

資料は CCC のリプレイでいいかなーなんて思っていたのですが、開催趣旨をよくよく聞くと特定言語やフレームワークに依らない方が望ましい、枠も 30 分とのこと。スプリングブートの 50 分ものじゃだめですね。

運良く(悪く?) OAuth 2 についていろいろ調べながら四苦八苦していて、「OAuth 2 ってむずかしい…自分ならこう説明するのになあ」という想いが溜まっていたので、それを吐き出すことにしました。

目的

なかなか抽象度の高い勉強会タイトルだったので少々悩みましたが、以下を目的に設定しました。

  1. JJUG CCC の反省を活かすこと
  2. 聴講してくださった方が OAuth 2 を学ぶ際に自分と同じ遠回りをせずに済むようになること
  3. 新しい知り合いを増やすこと

1.については後述の KPT で。2.についてはアンケートがないので詳細は不明ですが、この辺りのツイートから察するにまずまず達成できたと思っていいのかな。

3.については、イベント後の懇親会などで数名と名刺交換してお話できたので良かったです。

KPT

以下、簡単に振り返り。

  • Keep
    • CCC でまとめたマスタースライドを使い回して作業を効率化できた。今後もマイナーチェンジはあると思うけど、飽きるまでは継続
    • CCC よりもまとめをしっかり書いたら締まりが良くなった。継続
    • 付録に参考資料を多数掲載したところ好評だった。継続
  • Problem
  • Try
    • 聴講者からもっと質問を引き出してみたい。Slido を使ってみる?

Ask the Speaker

以下、登壇後やアンケートなどで頂いたご意見に対する回答。って言っても 1 件のみですが。

悪意あるクライアントにアクセストークンを渡してしまったらどうなるの?

当然、認可された範囲内でリソースオーナーの意図しない操作を実行される可能性があります。トークンは合鍵のようなものなので、信頼できないクライアントに預けてはなりません。

とは言え、下記のとおり ID/パスワード を預けるよりは遥かに安全ですね。

  • くり返しだけど、クライアントは認可された範囲内の操作しか実行できない
    • ID/パスワードを預けた場合、クライアントはやりたい放題
    • クライアントにパスワードを変更された場合、リソースオーナーはどうすることもできない
  • 認可サーバに連絡して当該クライアントに発行したアクセストークンを無効化できる
    • Twitter で言えば、アプリ連携を解除する
    • リソースオーナーが特定のクライアントのトークンを無効化する仕様は RFC 化されていない (と思う)
    • クライアントが特定のリソースオーナーのトークンを無効化する仕様は RFC 7009 で定められている
  • (認可サーバがアクセストークンのリフレッシュを自動処理しない場合) トークンの有効期限が切れれば使えなくなる

トークンのリフレッシュや無効化は時間の関係上、説明できなかったので、とても良い質問だなと思いました。

感想

今回の感想はこれに尽きます。

なんとなく分かった気になってスライドを書いて、RFC を読み返して間違いに気付いてスライドを直して、のくり返しでした。

発表の機会がなかったらここまでしつこく RFC を読み直さなかったと思います。貴重な機会をくださった濱野さん、ありがとうございました!

あとは、これですね…

16GB MacBook ProIntelliJ IDEA Ultimate をご用意頂ける企業様からのお声掛けをお待ちしております…

JJUG CCC 2017 Spring に参加しました #jjug_ccc

ずいぶん日が経ってしまいましたが拝聴したセッションの感想を書き留めておきます。

Vue.js + Spring Bootで楽しくフルスタック開発やってみた

うらがみさん。

フロントエンドの知識が皆無なので、後日検索するキーワードを拾い集めるくらいの低い意識で拝聴。あとで調べようと思った (けどまだ調べてない…) キーワードは

  • Cordova
  • vue-router 2
  • Vuex
  • axios

など。webpack もなんとなくしか分かってない。で、こんなこと思った。

Gradle, Doma2, Vue はマイナーだったり開発リソースの弱さが気になって距離を置いていたんだけど、尊敬するエンジニアの皆さんが声を揃えて推すのでちょっと考え方を改めようかと。イミュータブル、バリューオブジェクトを多用するのも興味あり。

最後にデザパタの話。むかし Swing をいじっていたこともあって Observer パターンが超重要なのは納得だったけど、Visitor パターンと型とパターンマッチングの話に付いていけなくて “???” と思っていたら、うらがみさんがすでにブログに書いていた。Brian Goetz の Java にパターンマッチ入れるとしたらこんな感じ?という記事にも同じことが書いてあって、すごく勉強になった。

データ履歴管理のためのテンポラルデータモデルとReladomoの紹介

FOLIO の伊藤さん。転職おめでとうございます!ドラム関連のツイートにいつも fav くださってありがとうございますw

履歴データのモデリングについて、よくあるパターンを丁寧に説明してくださって、とても分かり易かった。パターンに名前を付けるの重要ですね。

で、バイテンポラルデータモデルをネイティブにサポートする Reladomo (レラドモ) の紹介。XML によるエンティティ定義、ジェネレーションギャップパターンを考慮したコード生成という説明に会場がざわついていた (ように感じた)w

分かり易さと発表時間の関係だと思うけど、導入部分のみの説明だったので、この辺を疑問に感じた。

Q&A や懇親会で聞いた話では表の結合も考慮されているとのこと。シャーディングもサポートしているようなので、履歴をシャードに追い出せば性能も出るのかな。

Eclipse Collection と同様、Kata があるのでやってみようと思った (まだやってない…)。

ヤフーの広告レポートシステムをSpring Cloud Stream化するまで

塩野さんと橋本さん。懇親会でたくさんお話しさせて頂いてありがとうございました!共通の知り合いがいることも判明したので、いつかご一緒できるといいですねー。

各世代のアーキテクチャと問題点、それを次世代のアーキテクチャでどのように解決していったのか、という歴史の紹介が興味深かった。

歴史と言っても第一世代は 2014 年の話で、わずか 3 年で規模もアーキテクチャもこんなに変わるのか・・・と唖然とするばかり。ビジネスがちゃんと成長して、成長に伴って解決しなければいけない課題が発生して、その課題をエンジニアリングで解決して、って理想的な環境だなーと思ったり、夜中に叩き起こされる毎日もつらいなーと思ったり ^^;

MQ を挟んだストリーム処理は MQ を死守しなきゃいけないんだけど、その辺どうしているのか説明がなかったのでセッション後に質問。

ちょっとやそっとでは落ちないことが分かったのが大収穫。こういう実績のお話を聴けるのがカンファレンスの醍醐味ですね :-)

Javaで実装して学ぶOAuth 2.0!

多田さん。連続登壇記録を伸ばし続けていて本当にすごい。

Spring で実装するとセッションが Spring だらけになるので意地で Java EE で実装したという漢気には誰もが惚れたと思う。あと、合間に挟んでくる CM の面白さとデモ失敗のほうがみんなの記憶に残ってしまったようなw

個人的に OAuth 2 をそこそこ勉強した状態で拝聴したので、とくに OLTU による実装の部分はとても面白かったんだけど、ほぼ無知、あるいは OAuth 2 ってトークン使って認可するアレだよねーくらいの知識だと、ちょっと厳しかったんじゃないかなーと思った。

ここでの経験が後日の自分の発表につながるのですが、それはまた別ポストで。

Java8プログラミング ベストプラクティス & きしだが働いてるかどうかIDEのメモリ使用状況から機械学習で判定する

きしださん。メガネかけているの初めて拝見したような気がする。かっこいい!

離散ウェーブレット変換とか循環ニューラルネットワークとか何も分からないんだけど、きしださん独特の声と話し方で説明して頂くとまったく怖くなくて、むしろ面白いのがきしださんのすごいところだと思う。挙句、オチがロマンだったり、ちゃんと働けだったりw

コーディングプラクティスは Java 8 オンリーかと思いきや Java 7 以前のものもそれなりに。ラムダで例外処理はあきらめていいんだ、って割り切れたのが収穫。

この辺りから体力の限界が迫っており当日のツイートも少なめ・・・

あと斜め前の席でやんくさんがばりばりスライドを書いているのが気になったw

VMの歩む道。Dalvik、ART、そしてJava VM

最後はやんくさん。

体力の限界と VM 知識の不足で聞いているだけになってしまったけど、そもそもなぜ Android は独自に VM を作ったのか、Oracle JVM とは何が違うのか、など分かり易く説明していただいて面白かった!こういう完全に専門外の話が聴けるのもカンファレンスの面白いところですね :-)

裏番組でおそらくここと同じくらい分からんセッションをされていた @tan_go238 さんがバイナリに足を踏み込んだ経緯は以前に伺ったことがあるんだけど、やんくさんはなぜこの道に踏み込んだんだろう?と思った (けど訊いてないので今度いつか機会があったら訊いてみよう) ←訊かないパターン

懇親会

で、懇親会。LINE 寿司がめちゃくちゃおいしかった。LINE さん、ありがとうございました!

登壇効果もあったのか、初めての方とも沢山お話しすることができてこれまでの懇親会で一番楽しかったと思います。ご挨拶させて頂いたみなさん、本当にありがとうございました!

自分は人のお名前とお顔を覚えるのが苦手で、頂いた名刺にはどなただったかメモった付箋を貼ったりしているのですが、せめてお相手にはそんな苦労をかけたくないと思ってツイッターアイコンのシールを用意してみたところ、なかなか好評だった。今後も続けよう。

今回は PRINTAIL というサービスを使ってみました。1,000 円前後とお手軽なので、気になった方は試してみてください。

二次会

で、二次会。バイナリ部屋に押し込められたこざけさんがしょんぼりしていたのが面白かったw

あときの子さんがヒーローの存在に気付いてなかったりw

と言うわけで登壇から二次会までとても楽しい一日でした。また次回もよろしくお願いします!

JJUG CCC 2017 Spring に登壇しました #jjug_ccc #ccc_g1

はじめて JJUG CCC でお話してきました!

jjug.doorkeeper.jp

発表資料はこちら。

いろいろと反省点はあるものの、アンケート結果を見る限りでは多くの方に喜んで頂けたようでひと安心。

f:id:garbagetown:20170524124729p:plain:w800

登壇の背景

今回の CfP は身辺が慌ただしかったために一度は見送ったのですが、締め切りが延長されたので応募したところ採択されました。

はじめての CCC なのでひとつずつハードルを越えようと当初は 20 分枠で応募しましたが、JJUG 幹事から 50 分で話せないかと連絡があり、ありがたくチャレンジさせて頂きました。今になって振り返ってみると 50 分でも足りないくらいだったので拡大して頂いてよかったです。

登壇のねらい

自分は準大手システムインテグレータに勤める中堅エンジニアであり、そんな立場からコミュニティに貢献できることはなんだろう?と考えた結果、非機能要件という固めのテーマと Spring Boot という技術的なテーマを関連付ける内容にしました。

技術には強いけど IPA とか ISO とかあんまり知らないなーっていう方々には、これらの固い資料って伊達ではなくて網羅性が超高いので有用ですよっていうことをお届けしたく、一方で新しい技術の導入に苦戦している方々には、こんな便利なツール類がありますよ (って上司を説得して採用しましょう!) っていうことをお届けできればと。

わざわざ休日に勉強会に来るような人は技術者が多いはずなので、非機能要求グレードが届けばいいなーと思っていて、アンケート結果を見る限りこのねらいは達成できたようです。

あとは資料が一人歩きして Spring Boot 導入にひと役買ってくれれば万々歳ですね。

KPT

以下、簡単に振り返り。

  • Keep
    • 当たり前だけどレビューとリハーサルは超重要なので継続。レビュー、リハーサルにご協力頂いたみなさん、ありがとうございました!
    • 節目スライドに目標経過時間を書いておくメソッドは有効なので継続。あからさまに見せるとみっともない場合はスピーカーノート (後述) に書けばよさそう
  • Problem
    • スライドのレイアウトやフォントサイズなど本質的でないところに時間を掛けすぎた。今回の資料でマスタースライドはまとまったので次回以降は改善できそう
    • テンパって当日まで家庭や職場がおろそかになった。公私混同もはなはだしい。猛省
    • テンパって当日ディスプレイをミラーリング設定にしてしまいスピーカーノートが読めなかった。猛省
  • Try
    • ピンマイク、レーザーポインタ、黒曜石などを活用して身軽にプレゼンしたい
    • 音楽や動画などのメディアをプレゼンに活用できないか (<marquee> タグをカクカク動かしたかった…)

Ask the Speaker

以下、登壇後やアンケートなどで頂いたご意見に対する回答。

非機能要求グレードは項目多くて見積もり地獄にならない?

あらゆる案件に非機能要求グレードを全量使うのはアンチパターンです。

ほとんどの案件は「社会的影響が限定されたシステム」になるので、IPA のそれを “竹” として、よりお手軽な “梅” やリッチな “松” とセットで提案するとよいと思います。で、契約できたら各項目を調節して再見積もり。

IPA や ISO の資料は実用性より網羅性重視なので、現場で活用する場合はテーラリング必須だと思います。

spring-boot-admin のほうが便利じゃない?

複数アプリケーションを一元管理したい場合は Spring Boot Admin も便利そうですが、以下の理由より取り扱いませんでした。

  • 運用・保守に特化しており mappings など開発に有用なエンドポイントは見られない (たぶん)
  • 自分が使ったことがない…
  • 発表時間も足りなかった ^^;

Jasypt の鍵はどうやって守る?

暗号化した値をアプリケーションで複合しなければならないので、完全に守ることはできないと思います。自宅の鍵を二個にするのと同じで、攻撃の手間を増やして機会を抑制することが重要かと。

Spring Cloud だと spring-cloud-vault があって、このへんのソリューションになるっぽいですが、まだよく分かっていません。

TERASOLUNA って有償じゃないの?

TERASOLUNA Server Framework for Java (5.x) は独自のフレームワークではなく、Spring Framework を中心とした OSS の組み合わせです。既存の OSS では足りない機能は共通ライブラリとして Apache 2 ライセンスで公開されています:-)

github.com

スライドの字が小さくて読めなかった…

コード例のフォントサイズは先輩方のアドバイスに則って 24pt で書いていて、これより大きくするのは厳しそうです。

お手元で資料をご覧になれるよう URL をお知らせしていましたが、セッションが始まってから来られた方には案内が行き届いていませんでした。申し訳ありません。次回以降、備え付けのホワイトボードに書いておくなど配慮します。

タイトルが抽象的。性能要件の話を期待した

ご指摘のとおりですね。タイトルが細かくなり過ぎるとくどくなってしまうので、セッション概要あたりに明記すべきでした。改善します!

それはそうと、性能要件をフレームワークやライブラリで対応するという観点で研究するのも面白そうです。ぱっと思いつくのはキャッシュ、非同期化、負荷試験あたりかなー。

Actuator が向く場面と向かない場面を明記すると良い

こちらもご指摘のとおりですね。個人的には、システム負荷がそれほど高くなく、かつ運用・保守にそれほど大きな予算を割けない社内システムなどが最適と考えています。

さらに詳しく学ぶためには何を参考にすればいい?

Spring Boot ではなく Spring MVC になりますが、TERASOLUNA 開発ガイドライン を読まれるとよいと思います。kazuki43zoo さんの Qiita も必見です。

英語に抵抗がなければ、やはり 公式ドキュメント が間違いないです。http://www.baeldung.com/ も小粒な情報が多くて参考になります。

まとめ

長くなったので拝聴したセッションの感想は次ポストで。

JJUG CCC 初登壇、楽しかったです!心身ともにしんどいときもありましたが、チャレンジして本当によかったです。

JJUG 幹事各位をはじめ、ボランティアスタッフのみなさん、セッションに足を運んでくださったみなさん、お疲れさまでした。ありがとうございました!

@toru_inoue から食洗機を譲り受けた

タイトルですべて言っているけど周辺の知見などを。

TL; DR

  • @toru_inoue から食洗機を譲り受けた (圧倒的感謝)
  • AR アプリで設置シミュレーション
  • らくらく家財宅急便は着払い不可
  • 分岐水栓は自分で取り付けるべき
  • 食洗機は全自動食器棚

経緯

加齢とともに肌から潤いが失われ、かつ家族が増えて水仕事をする機会が多くなり、冬になると手荒れがひどくてハンドクリームを手放せず、漠然と食洗機が欲しいなあと思いつつも安くないし場所も取るので二の足を踏んでいたところ、タイムラインに以下のツイートが流れてきた。

聞けば Panasonic の NP-TR8 という製品で、けっこうデカいけど、ざっと寸法を測ってみたところなんとか設置できそう。

戸棚からシステムキッチンの説明書を引っ張り出して確認すると自宅の水栓はタカギの JG 1230 という機種で、ネットで調べてみると CB-STKB6 という分岐水栓で Panasonic の食洗機を取り付けることができるらしい。

急な話で他に検討漏れがないか不安はあったものの、この千載一遇の幸運を逃すまいと図々しく手を上げた。

準備

@toru_inoue 曰く、念のため電気屋に置き場所や水回り工事の相談をしたほうがよいとのなので、さっそく翌日仕事を休んで (ちょうど有給休暇を取る予定だった) 台所の写真を撮りまくってから駅前の電気屋に行って相談したところ、問題ない模様。

分岐水栓の取り付けを業者に依頼すると一万円くらいかかるらしく、自分で作業する人がどれくらいいるのか聞くと「そんな人はいない。うちの店で買ってくれれば五千円で工事する」と言われた。分岐水栓も一万円くらいするし、自分でやってみないことには費用に値する作業なのかも分からないので、検討します、とだけ言って帰ってきた。

帰宅してアマゾンで分岐水栓を注文した後、もらってきたパンフレットをぱらぱら眺めていたら設置シミュレーション用 AR アプリの存在を知った。

カタログの特定ページを開いて置き、AR アプリを通して見るとそこに食洗機が登場するという、なんと言うか想像の斜め上をいく仕様。

アップストアのレビューには悪いことばかり書いてあるけど、設置イメージを具体的に把握できたし、無駄に風呂やトイレに食洗機を登場させて笑えたし、個人的にはとても良かった。

分岐水栓の取り付けに必要なモンキーレンチとプライヤーは別の友人から借りることにして準備完了。

問題

迅速に配送の手配をしてくれた @toru_inoue から連絡。モノがデカいので家財宅急便になるけど着払いは受け付けていないとのこと。

配送料は四千円程度。いったん立て替えてもらい、後日精算することにした。

設置

で、実際にモノが届いたので設置。結論から書くと分岐水栓は自分で取り付けるべき。

実際に使ったのはマイナスドライバー、ピンセット、プライヤー。モンキーレンチはアゴが小さくて使えず、どこかで何かが固着していた場合を想定して用意したゴムハンマーは使わなかった。

具体的な手順は分岐水栓の取扱説明書と上記ツイートの一連のメンションを参照してもらうとして、若干ハマったところだけメモ。

  • 止水栓がちょっと固かった
    • ご家庭ごとに場所や形状が違うので注意
    • 固さはパワーで解決した
  • バーハンドルも固かった
    • 製品によっては六角ネジなどを外してから引き抜くものもあるので注意
    • 固さはパワーで解決した
  • カートリッジも固かった
    • ネットで調べてみたら外したレバーハンドルを差し戻して引き抜けとあったので、その通りにしたら無事に引き抜けた
  • 分岐水栓の取り付けが少し難しかった
    • ここをミスると水漏れの原因になるので注意
    • きちんとハマっていないと分岐水栓側のハブという部分がくるくる回るので、これが回らなくなるまで軽く前後左右に揺すりながら下に押し込む。きちんとハマるとガチっと音がする
  • 分岐水栓、分岐コックのナットが予想より大きかった
    • あとから知ったことだけど水栓工事のナットは 28mm が標準らしい。モンキーレンチはアゴが 30mm まで開くものを用意する
    • 分岐コック側のナットを押さえるために一本、分岐水栓側のナットを締めるために一本、計二本あるとよい
    • 分岐コック側のレバーを手で押さえ、分岐水栓側のナットをプライヤーで締めることで対応した

なにか失敗すると家中水浸しの即クラシアン案件になる気がしてビビっていたけど、やってみたら思ったより簡単だったし、自宅の止水栓や水栓の知識も得られたので自分で作業して良かった。

ただしパワーで解決する場面が何度かあるので、そっち方面に自信がない場合は大人しく金で解決するのもよいと思う。

感想

雑に述べると最高なんだけど、なにが最高なのかよく考えてみた結果、これは全自動食器棚であるのだなと思い至った。

実際に食洗機を利用してみると食洗機導入前後の食器に関する手順は以下のようになる。

手順 導入前 導入後
1 食器棚から取り出す 食洗機から取り出す
2 使う 使う
3 ざっと水で流す ざっと水で流す
4 洗う ほぼ自動
5 乾かす 自動
6 食器棚に収納する ほぼ不要

食洗機という名前から手順 4 が省略されるのは期待通りとして、5 と 6 も省略されるのは意外な体験だった。

手洗いの場合でも水切りカゴにひと晩ほど放置しておけば乾燥は自動化できるものの、水切りカゴは収納力があまりないので乾燥後はどうしても食器棚に戻す必要がある。一方で食洗機はそのまま食器棚として使える収納力があるので、食器を使った後、ざっと水で流して食器棚に収納しておけばなぜか翌朝にはピカピカになっているという感覚に近い。

以前に洗濯乾燥機を手に入れたばかりで興奮冷めやらない友人が「これがおれの洋服ダンスだ」と言いながら洗濯乾燥機から引っ張り出した洋服に着替えていたけど、あれと同じだと思う。

謝辞

脳が若返るような刺激的な機会を提供してくれた @toru_inoue さんに感謝いたします。後日開催予定のうどん会にて配送料を精算すると共に、謝礼として上質の白い粉 (隠語) を献上したい所存です。

JJUG ナイトセミナーに登壇しました #jjug

はじめて JJUG でお話してきました!

jjug.doorkeeper.jp

発表資料はこちら。

口頭で補足した内容を含めた要約は、なかやまさん のライブドローイングレポート (すごい!) にまとまっています。

当日の会場の雰囲気や togetter を見る限り、お話したかった内容は大体伝わっているようで安心しました。

togetter.com

経緯

五月の中頃に「今度のナイトセミナーで Play Framework について話さない?」とお誘い頂きました。

誰よりもドキュメントを読んでいる自負だけはあるものの、Play2 や Scala の実践的な経験はなく、有意義なお話ができるか不安だったのですが、なかなか得難い機会だったので思い切ってお引き受けすることに。

準備

まず、以下のブログとスライドを復習しました。これからプレゼンやる人は必読です。

やるべきことはイメージできたので、続いて登壇のゴールを考えました。ひたすら考えました。グアムの海にぷかぷか浮かんでいるときも考えていました。

どんな人が、なにを期待して聴きに来るんだろう?どうなったら成功したって言えるんだろう?自分にしかできない話、プレゼン...そんなものあるのか...?本当に引き受けてよかったのか、これ?!ウオオオオアアアアア!!

みたいなことを悶々と考えて、最終的に「Play を正しく知ってもらうこと」をゴールに設定しました。

Play が作られた背景や目的、利点だけではなく欠点も正しく知ってもらって、みなさんが抱えている課題にぴたっとハマったときだけ Play を使ってもらって、それで「Play いいじゃん!」となれば最高だなー、と。

ゴールが決まればあとは資料作りです。

まず使い慣れている markdown と reveal.js で全体の構成を組み立てた後、作業環境の都合上 *1 一度 LibreOffice でスライドにしてから KeyNote で清書。その都度 @gakuzzzz さんにレビューして頂き、的確なご指摘を頂くことができました。本当に、本当にありがとうございます!

当日

計画性がないくせに細かいところが気になる性質が災いして、当日の深夜までスライドいじりに明け暮れていたので、スピーチの練習はゼロ。昼休みに会社の後輩に付き合ってもらったリハーサルはボロボロでした。

これはヤバい!と仕事(幸いヒマだった)そっちのけでスクリプトを書いて自席でひとりぶつぶつと練習しました。台本はスライドと同じくらい大事ということに気付いたのが今回の最大の収穫。

その後、終業時刻をややフライング気味に職場を飛び出して、青山のファミリーマートでスライドを最終調整。思いつきで小見出しスライドに経過目標時間や小ネタを書いてみたのですが、いろいろとリラックスできてよかったです。

本番のお話は...自分ではまずまず落ち着いて話せたと思っているのですが、どうだったんでしょう?録画はなかったようなので、なにかお気付きの点があった方はツイッターなどでお知らせ頂けるとうれしいです。

謝辞

まず、貴重な機会をくださった JJUG のみなさんに感謝します。当日の運営も含めて、本当にありがとうございました。

くり返しになりますが、資料をレビューしてくださった @gakuzzzz さん。何度も拙い資料をご確認頂き、申し訳ありませんでした。がくぞさんの協力がなかったら悲惨な結果になっていたと思います。本当にありがとうございました。

リハーサルに付き合ってくれたポリーさん、イッチー、ありがとう!約束どおり今度お酒をごちそうします。

貴重な時間を割いて私のプレゼンを聴いてくださったみなさん、感想をツイートしてくださったみなさん、懇親会でお話させて頂いたみなさんにも感謝です。頂戴した感想を活かして、次回があれば必ずパワーアップしたプレゼンをお届けします!

最後に、構想段階ではいつもぼーっと考え事をしていて、作業段階では毎晩夜更かししてふらふらしていたダメダメな夫・父親を支えてくれた妻と娘に感謝します。本当にありがとう!しばらく家事に専念します ^^;

*1:自宅は Mac で職場は Windows なので...

Cloud Foundry ワークショップに行ってきた #cfws

04/18 に開催された Cloud Foundry ワークショップに参加してきました。

Open PaaS かつ PlayFramework 対応ということで Ruby で実装されていた頃から名前はよく耳にしていましたが、当時は PaaS をなんとなく制約の多い IaaS くらいにしか捉えておらず、あまり積極的にウォッチしていませんでした。

あれから数年が経って Docker や Spring Boot が登場した現在における PaaS の感触を持っておきたかったことと、なにより Pivotal Japan に行ってみたかったことから、業務をさっさと切り上げて参加してきました。

Introduction

30 分くらいと言いつつ 45 分くらい Cloud Foundry の紹介。

以下、当日のメモから特に印象に残った点。

  • Why PaaS?
    • インフラは PaaS に任せてリソースをアプリ開発に集中する
  • Cloud Foundry
    • OSS
    • エンドユーザ企業や日本企業も Foundation に参加
    • マルチベンダで実装。開発スピードが速い
  • Structure
    • CPI (Cloud Provider Interface) を提供する基盤であればどこでも動く
    • BOSH は超すごいオーケストレーションツール
    • Cloud Foundary はそれらの上で動く Runtime
  • Architecture
    • Go で書かれた REST API ラッパの cf コマンドで操作
    • cf push するとアプリケーションに応じた runtime をくっつけた droplet になって cell にデプロイされる
    • cell では Docker Image も動く
  • Service
    • データベースなどのバックエンドサービスは環境変数を通じてアタッチする
  • HA
    • コンテナ/プロセス/VM/AZ の 4 レベルで高可用性を実現
  • Cloud Foundry of Pivotal
    • PWS (Pivotal Web Services) : AWS 上で動作する web サービス。利用メモリ単位で課金
    • PCF (Pivotal Cloud Foundry) : private/public クラウドで動作する商用パッケージ。リッチな GUI など豊富な付加価値
    • PCF Dev : ローカルに PCF 環境を構築する Vagrant イメージ。メモリ 8GB 以上を推奨

ベンダロックインされない OSS 版 Heroku という印象ですが、自分で構築/運用するのはなかなか手強そう。大人しくフルマネージドな PCF の導入を検討した方が良さそうです。

WorkShop

@making さん恒例のサバイバルワークショップ。ある程度 Spring Boot を触っておかないと dependency をダウンロードしている間に置いていかれますw

お品書きはこちら。

  • Pivotal-Japan/cf-workshop: Cloud Foundry Workshop
    1. 事前準備 / Prerequisite
    2. 簡単なアプリケーションをデプロイ / Deploy hello world
    3. バックエンドサービスの利用 / Use backend service
    4. スケールアウト / Scale out application
    5. ログの転送 / Forward logging
    6. Blue-Greenデプロイ / Blue-Green deployment
    7. PCF Devを用いたローカルCloud Foundry環境

上記 1. は事前に済ますようあらかじめ連絡があり、当日は時間の関係から 2. から 4. まで実際に手を動かし、5. から 7. までは説明とデモでした。

実際に手を動かした部分では、やはり OSS 版 Heroku という印象。Heroku を使ったことがあれば、すんなり触ることができます。Spring または Play アプリケーションでのみ利用できる Auto Reconfigure という仕組みで Redis 接続先が自動的に切り替わるのが便利でした。

Blue-Green デプロイは、知識として知っているのと実際に目にするのとでは随分印象が違って、これぞクラウドという感じでした。オンプレシステムの移行案件で死んだ経験があったりすると涙なしでは見られないと思います。複数台のサーバがじわじわ移行していく Scaleover も面白かったです。

まとめ

12 Factor App を満たすクラウドネイティブなアプリケーション開発は今後ますます重要になっていくことを再確認しました。最近話題のマイクロサービスアーキテクチャと合わせて少しずつエンタープライズの世界にも浸透してくると思われるので、リードアーキテクト的な立場にいるエンジニアは三回目以降が開催されたら参加されることをおすすめします。

ただ、そんなマイクロでクラウドなアプリをどこで動かすかは状況次第かなと思います。大規模サービスをコア業務としているのであれば PCF を導入するメリットが十分にあると思いますが、小中規模の請負開発ではフィットしない場合もありそうです。

PCF がもっと広まると PWS の東京リージョンができて、そこで運用するという道も見えるかもしれません。少しでも興味を持った方は、まずワークショップに参加して、60 日間の試用期間を使い倒してブログを書きましょう!