AWS 認定ソリューションアーキテクト・アソシエイトなど一気に受けまくった
会社でAPNパートナーになろうとしていて条件を満たしたいという側面もありましたが、この機会に2010年あたりほとんどのプロジェクトでAWSを使い続けてきたので、経験と照らし合わせて体系だって知識を埋めあわせてみるのも良いかもと思って、AWSの認定系試験を受けまくりました。
APNパートナー認定系
Webinarでトレーニングを受けて、最後に20問程度問題を80%以上の正解率で解答して認定を受けれる資格。 動画や解説がけっこうよくて、仕事で実践をしていると知っていることが多いのだけれど、以外と気にしていなかったことや、細かいことやAWSの流儀や思想などもわかって、AWSに馴染みがなく、ひととおり覚えたいという人には、ソリューションアーキテクト・アソシエイトより先にこちらを受講・認定を受けるのをお勧めしたいです。
現場のインフラ屋が教える インフラエンジニアになるための教科書の
0章 0.2.2 インフラエンジニアの役割と業務の目的 や
インフラはプロジェクトや事業の目的を達成するための「手段」であるということです。そこのとらえ方を間違ってしまうと、無駄なスペックばかりを追い求めたり、極端に安全な構成をとってしまったり、目的を達成するために必要のない仕事をしてしまいます。
同じく 0章 0.2.2 インフラの一生を面倒見る
プロジェクトの時系列で考えると、ヒアリング、設計、構築、運用、移行、サービス終了など、インフラエンジニアは全てのフェーズで関わります。
でも言及されていますが、手段と目的を考える過程で、運用のトレードオフになりやすい、コスト管理やビジネス寄りも思考も大事なことで、それを改めて知ったり再認識できるのがAPN系のトレーニングや認定のいい所だと思います。
ソリューションアーキテクト・アソシエイト
こちらは個人レベルで受けれる認定資格。
業務でかなり使い込んでいるので、基本的には問題ないとは思っていたのですが、ドキュメントや設定値を見れば一目瞭然なものでも、記憶から薄れている内容も出題されるので、暗記系の傾向対策や試験範囲のドキュメントを読むという勉強を3日ほどやりました。
試験内容は実用的な内容が多いので体系知識を埋めるというのにピッタリで、難易度もそれなりにあって問題もうまく作っているなぁと感心。
「高可用性、コスト効率、耐障害性、スケーラブルなシステムの設計」や「トラブルシューティング」は実践に近い感覚だったので正解率が高かったのですが、その他の覚える系は間違った所も幾つかありました。
NDA的なことがあるので詳しくは書けないのですが、「XXXXの最低値は何か?」というような問題があって、少し前提補足がを書いてもらわないと、前提条件により選択項目が違ってくるのに・・・ というケースもありましたが。
まぁ、無事一発合格もできたのでほっとして、プロフェッショナル試験はどうなんだろ?と、サンプル問題も見てみましたが、こちらはかなり難しそうでした。
受けてみて
クラウド時代でもセキュリティや運用は大事なことです。クラウド時代は発想や常識やセオリーを変える必要もあります。 ドキュメントを読み込まずとも、簡単に使えてしまうAWSですが、AWSを適切に使えることということは「コストやリスクマネージメントやプラクティスや責任分岐も含め周りに説明できること」と考えられる人にはお勧めだと思いました。
申し込めば1週間後程度で受験できたので、集中力やモチベーションや維持できて面白かったです。
アジャイル好きな私がデビッド・アレン来日GTDワークショップに行ってきました
GTDのプロセスの生みの親で生産性向上コンサルタントのデビッド・アレンさんが来日してワークショップが開催されるということで、先日、参加してきました。
なぜGTD?
10年程前にこちらのサイトを知ったのをきっかけとして、シンプルでわかりやすいGTDが好きになりました。
そんな私も、実はアジャイル開発がやりたくて現所属会社に入社し、隠れ認定スクラムマスターでもあり、アナログのタスクボードでプロジェクトを回したり、デジタルだけでやってみたりと、ツールもやりかたも色々試してきました。
そんな、色んな手法やツールを経験してもやっぱり、個人のタスク管理はGTDが一番スッキリします。
私たちの頭の中に働きかけます
デビッド・アレンが口調はゆっくりで躍動があり存在感がありました!
デビッド・アレンが常々言っていたことは作業効率と脳は非常に関係あることで、今やるべきことある時に心が穏やかな状態であることが大事なんだと。
- 頭の中で考えていることは多岐にわたっています
- 脳は過去・現在を区別して整理して記憶されていません
- 脳は終わりを捉えることは得意ではない
- 研究分野でも50年くらい前には証明されているそう
- GTDは今・明日に何をやることが明確なのかが単純ではない時代にあったツールである
- 仕事・家庭・顧客・子供、どんな人であっても目の前にいる人にどれくらい集中できるかは脳の状態よって大きく異なる
- クリエイティブになるための必要な時間は0である
- お風呂の中、レストランで食事をしている時、ソファの上などよくあること
気になっていることを書き出そう
1.把握・意識する
気になっていることはなんでしょう? ずっと頭の中にある必要がないということを意識しましょう
GTDには気になっていることを書き出すをプロセスがあり、「マインド・スイープ」といいます。 これは、頭の中を見える化するものです。
このマインドスイープをやっている時には、私生活・仕事にかかわず気になっていることを時間制限まで吐き出すことが大事です。 浮かんだ内容で優先順位をつけてはいけません。なぜなら、価値あることはこの時点ではわからないからです。
書き出した内容は、今それをやる時ではないのに強迫観念に責め立てられて脳がやらなきゃと思ってしまっていることも多いはずです。脳に抱え込むと脳が働かなくなります。
アレンの話を聞いていて思ったことは、「あらためてそう思うなぁ」 という同調でした。
- 悪い状態
- 頭のなかに置いたまま
- 良い状態
- 頭の外に出して信頼できる所にだしておく
アンチパタン
保管の仕方も大事です。信頼できるというのはいつでも取り出せ使える状態になっているということです。スマホアプリやサービスなども増えてきていますが、キャプチャするだけだと散らばるだけで、そういう状態で溜めるだけ溜めて放ったらかしにしておくと結局は頭で覚えることになります。
2.見極める
- 行動をおこす必要があるか?
- 起こす必要がない場合
- 3週間後の勉強会など間際にならないと決められないものは「保留」にしましょう
- 自分だけで決められることか?
- 任せる(WatingFor)
- 2分以内にできるものならすぐやる(全網羅した見極めのあと)
- 起こす必要がない場合
- 分かりきっていることは書かなくても良い
- お昼ご飯を食べる(腹減ったら食べるよね)
- 洗濯する(着替えがなくなってくればわかる)
- ただリマインダーは効果的だよ
一つの作業で終わらないものは、終わったと思っていても小さいことがでてくるので、小さいことまでチェックリストを作ってプロジェクト化するがお勧め!
結果を書き留めておくことはコンピュータにはできるが、決断はできないのでそこに脳を使おう!
- 悪い状態
- 尻に火がついてからやるのをやめよう!
- 旅行の為に直前準備するのにかけた48時間の疲れをとりにいくのって多いよね。
3.整理
この辺のやり方は、GTDの手法やワークフローになっているので、こちらのサイトか本を読むのが良いと思います。
私のやりかた
私は、個人と仕事の2つにわけておりデジタルツールで管理・整理しています。
仕事はGoogleAppsを使っているのでGmailと統合させて、ActiveInboxで一元管理。
個人はThingsというアプリ(Mac、iPhone、iPad版あり)を使っています。
Things - task management for Mac & iOS - Cultured Code
4.更新する(随時アップデート)
私はこれが苦手で、ルーチンワークというのが忙しくなってくると、ついおろそかになってきます。こういうところをどうしたらいいのか?というのを最後の質問タイムでアレンに聞いてみました。
現時点のGTDという視点でアレンに幾つか質問できたのは貴重な体験でした。
5. 選択する
ビジートラブルにならず、安心して実行することができる状態を保ち、優先度順に着手していきましょう。
あれっ?これってスプリントに区切ったり、プロダクトバックログの優先順位の本質とそんなに変わらないよね。と思って方もいるのではないでしょうか。私もそう思います。
デビッド・アレンからのアドバイス
- リストを作ることに慣れよう
- 「任せるよ」だけではだめ
- 責任の所在と期待をしっかり伝えよう
- 2分以内に決定できるなら任せるということが非常に効果的になってくる
- 1時間は自分一人で「まとめる」(マインドスイープなど)をする時間を確保することが大事で必要
FAQ
- 望むべき事項と連絡待ちはどうやってWatingForとして使い分けたらいいの?
- うまくGTDを続ける方法は?
- 提案1. 避けていることを先にやる
- 提案2. 好きなことだけをやる
- アレンさんはずっと1と2を行き来している(笑)
記念撮影してもらった
写真ははずかしいのでここでは公開しないのですが、快く撮影に応じてくれて肩組をアレンさんからしてくれました。あと、ミーハーっぷりを出して書籍にサインまでしていただきました!
デビッド・アレンの秘話
- 当日来ていたデビッド・アレンの友人はずっと日本在住で40年来の友人らしい
- その友人の会社のロゴをデビッドに作ってもらったらしく、まだアレンさんが24歳くらいだたらしい
- デビッドの会社は何でも屋さんだよ(笑)って言っていた
- デビッドは・アレンのデジタルツールはロータスノーツを使っていて、返信時だったかな?状態がわかりやすく通知されるので使い続けているそう。
最後に
アジャイル関係の勉強会は日本各地でやっていたり、ムーブメントや盛り上がりの波は何度も来ています。それに比べGTDはというと日本での注目度はいまいちだと感じています。シリコンバレーをはじめ海外では会社・教育現場など様々な所で活用されていたり人気があると聞きます。
GTD好きや日頃の工夫ややりかたなど、情報交換したりワークショップをしたりするコミュニティがあってもいいんじゃないかと思い、個人的にやりたいなーと思っていました。ただ、「GTD」という名称に著作権があり、勝手に利用できないと何かで見たことがあったので、アレンさんに
日本でコミュニティ活動したいと思っているんだけど、GTDという名前を使ってもいいですか?
とお願いしてみたら
もちろん!!あなたのコミュニティ活動でGTDという名を使っても問題ないよ。
というOKをいただき、アレンさんも喜んでくれました。そのうち小さな力ですがGTD活動もしていきたい思います!
MVNOでiPhone5からiPhoneSEにMNPしました
4年くらい使っていたiPhone5のバッテリーが持たなくなってきたので、iPadの2年契約の月になったことも重なり、iPhoneSEに乗り換えました。
乗り換えのポイント
- 家族でauを使っていてSMS無料や家族割りの関係などで家庭内キャリア縛りがあった
- iPadが主なモバイル端末としiPhoneは通話のみプランで運用していた
- 信号待ちやエレベータでも携帯に目をやってしまう依存症の兆候を直したかった
- iPhoneは2年ほど980円運用していたので、新しいiPhoneを買う為の貯蓄はあった。
- MNPでの優遇が春からなくなってしまったので、新しい機種でSIMロックを解除したらMVNOに乗り換えようと考えていた。
最終的な選択
MVNO業者の選定
- 音声のMNPしたい
- 決め手
- エンジニア視線でDMMラボのイメージと留守番電話の開発予定がよかったのでDMM Mobileにした。
- オンラインチャットの担当者のやりとりもよかった
- エンジニア視線でDMMラボのイメージと留守番電話の開発予定がよかったのでDMM Mobileにした。
MVNOでMNPをするまで
お得情報とハマったことを
- Amazonで580円で申し込みパッケージを買う(新規手数料の3000円→580円に)
- パッケージ番号を入力し契約申し込みする
ここから重要
- 新SIMが3日ほどで届く
- 手持ちのSIMを抜き、新SIMをさす
- 電波をつかまず、圏外と表示される
- ネットワークリセットをするも現象かわらず
- SIMロックがかかってしまったのではないかと心配した
- ネットワーク設定で「プロビジョニングされていないSIMです」と表示された
- 圏外のままだった
まとめ
というのを家族が来月2年縛りが終わるのでMNPする時の参考にします。 auでSIMロック解除対象外機種を引き続き使う場合(わたしの家族のようにテザリング必要ない人)は、マイネオにして次に買い替える時にMNPを再検討するのがよさげ。
Nulabさんの東京オフィス移転パーティでLTをさせて頂きました
7月15日に行われたNulabさんの東京オフィス移転パーティに参加させていただきました。
その時に、おみやげ何を持って行こうかな?と考えた所、きっと酒のつまみにNulabネタに絡めたLTを持って行くと喜んでもらえるのではないかな(場を温めるくらいはできるかも)と思って、まずはネタだけ仕込んで、当日お伺いさせていただきました。
素敵なオフィスとロケーション
Nulabさんのオフィスは以前は渋谷駅にあって華やかな場所でしたが、手狭になってきたとのことで移転されたそう。フリースペースのオフィスで空間も広めで素敵でした。
新オフィスの場所は神楽坂で、ランチで選べるお店多くご飯がとても美味しい場所なので、うらやましい限りです。
素敵なNulabさんのキャラクター
こちらのニョロニョロしているキャラは、GitHubのタコさんやTwitterのトリさんのロゴをデザインされたサイモンさんに作ってもらったとのこと。名前は、そう!!その前は、、、なんでしたっけ・・・ 教えて頂いたのに忘れてしまいました。すいません。
ヌーラボさんの方々やゲストとお話させていただきました
レセプションパーティーがはじまって、何人かの方にご挨拶させていただき、顔見知りの方や初めての方などたくさんの方とお話しました。ヌーラボの橋本さんにご挨拶させて頂いた時に「酒のつまみにもしよければLTネタでも」と話したら、喜んで受け取っていただき、快く「よさそうなタイミングでお声掛けしますね」と言ってくださいました。
会場が和んできた頃に上の写真は橋本さんが移転ご挨拶を、スライドを使ってしゃべっている様子なのですが、すごく気さくで魅力的な方でした。
私のつたないLT
橋本さんご挨拶タイムのあとLTをさせていただきました。
www.slideshare.net
Nulabさんネタをスライドに仕込んで、ほめちぎるというスタイルで発表しました(笑)
AWSのネタはLambdaを使ってEC2のメンテナンススケジュールされたイベントを運用で困らなくする話です。メールだと、どうしても伝達洩れが発生しやすく、チャットとすごくイケてる課題管理ツールのBacklogに登録すれば適任者が忘れず処理できるよね。というような内容です。
Cacooもスライドの図を書く時に使い、Cacooにログインする時にNulabアカウントも利用したので、プロダクト群コンプリートしました!というのをほめちぎるネタのひとつとして、LTで言うのを忘れてしまいました...
最後は神楽坂の私が好きなお店を紹介し、「近くによった時など機会があれば神楽坂ランチご一緒させてください」ということで、LTを締めました!
つたない飛び込みLTを受入れていただき、ゲストの皆様はじめ、ヌーラボメンバーの方々ありがとうございました。
その他トピック
- agataさんに開発秘話や福岡の話など色々聞かせていていただきとても楽しくてうきうきしました。CacooのHTML5版楽しみにしています!
- @garbagetownさんが以前にSkinnyMeetupで会った時のことを覚えていてくださり嬉しかった
- 当日もたくさんお話させていただきました!楽しかったです。
- クラスメソッドさんの方ともお話する機会があり、違った機会で交流できそうな予感。
- お久しぶりに方々とも少しの時間ですがご挨拶できてよかったです
- Cacoo忍者が3人オフィスに隠れているとのことで探してみたが1体も見つけられず...
- 吉澤さんに1人の場所を教えていただきました。「残り2人はまた今度来た時に探してください!」とのこと
- Nulabニューカマーの3人の方ともお話させていただきました!
- 橋本さんが挨拶の時に「早くもオフィスのキャパ埋まりそうで、引っ越しします」と冗談で言っていた時には笑わせてもらいました
最後に
当日は楽しい時間を過ごさせていただきありがとうございました! これからも素晴らしいプロダクトに期待しています。 神楽坂ランチうらやましいです。えっ!?
AnsibleSpecを複数環境プロビジョニングに対応させてOSSに初Contributeした
この度、AnsibleSpecにコントリビュートして「複数環境プロビジョニング」のユースケースで便利にテストを実行できるようにしました。
私がやろうとした時に目の前にあった前提
最初に、私がこの対応をするにあたって目の前にあった前提をお伝えしておきます。
プロビジョン完了時に合わせてインフラの状態をテストしておきたかった理由としては、こんな感じです。
- 本番・検証など多くの環境ができてくるとインフラテストがやりきれない
- インフラテストを自動化してインクリメンタルに作業を進めたい
- よりよいプラクティスを追求したいという想い
その他、下記が決めてあったことです。
Ansibleのディレクトリ構成ベストプラクティスを採用
TerraformやCloudFormationなどで環境群自動構築のアプローチを採用
- 環境がProduciton、Staging、develop、demo、などセットをたくさん作る事を想定
- Immutable Infrastructureを意識し環境を使い捨て・切り替えしていく
- プライベートIPアドレスは任意のアドレスが割り当てられている
- Ansibleのプロビジョンコードをコミットする時点ではhostsは予測不能
各環境には基本的にSSHしない
- 運用的なセキュリティ強度を高める為にSSHをしなくても済むようにしたい
- 必要なログ情報は全てログコレクタを使って転送
- 障害やアラートの検索はElasticsearchやCloudWatch logsなどで実施
- 必要なログ情報は全てログコレクタを使って転送
AnsibleとAnsiblespecの組み合わせを選択
「Ansibleのテスト事情」も参考にさせて頂き、結果的にAnsible標準テスト方法ではなく、Serverspecを使う事にしました。左記のエントリーでは好みの問題でAnsibleSpecは避けられていましたが、最近「Dynamic Inventory」に対応された事もあり、統合的に使いたかったことも相まって、私はAnsibleSpecを選びました。
話しが少しそれますが、「Ansibleのテスト事情」エントリーで下記が言及されていました。
また、serverspecをrole単位で実行できるansiblespecという拡張モジュールもあります。 こちらも使ってみましたが、テスト単位がrole単位というのが好みに合いませんでした。 構成管理ツールは上から下まで流してナンボだと思うので、playbook単位に行うべきだと思います。 プログラムでいえばユニットテスト用で扱い難く、severspecでインテグレーションテストをすべきという考え方です。
これが示す意味としてはtest all的なものがないということかなと。私もplaybook単位で実行できる方が便利だと感じたので、デフォルトのRakefileでallというrakeタスクを追加し、"rake all"または"rake serverspec:all"でプロビジョニング対象になったタスク全部を一括で流せる形にしました。
この修正は、まだ現時点ではRubygemsとしてはまだリリースされていませんが、一緒に取り込んでもらえました。きっと、次のバージョンに含まれる事になると思います。
パッチが必要になった機能
AnsibleSpecの幾つかの機能がまだ未実装で自前でパッチを当てる必要がありました。
- AnsibleSpecではHostsに対して複数のホストを指定されたPlaybookに対応していない
- AnsibleではgroupのChildren指定で依存関係を書けばgroup_varsも依存を辿って参照してくれるがAnsibleSpecでは未対応
この2点は複数環境プロビジョニングにとって重要な要素でしたのでパッチをあてることにしました。パッチもAnsibleSpecを追従していくのはきついし、後からわかった事なのですが、GitHubを見るとアイディア・要望としてchildrenの依存でgroup_varsを参照したいというのを幾つかみたので、思い切ってプルリクすることに決めました。
プルリクするために自分以外のInventoryやhostsファイルの書き方でも正常に動く必要があるので、AnsibleSpecライブラリ自体のテストコードを修正したり、新しくテストを追記したりしました。
実例
実際にはAWS CLIなどを使って命名規則や条件に従ってhostsのアドレスを取得し埋め込み、JSON文字列を生成する必要があります。また、実行時に環境変数に環境名を置き換えれるようなスクリプトにすれば、環境名は容易に変更する事ができますね!
dynamic_inventory.sh
#!/bin/bash cat << EOS { "database-servers": { "hosts": [ "10.0.0.4" ] }, "application-servers": { "hosts": [ "10.0.0.2", "10.0.0.3" ] }, "web-servers": { "hosts": [ "10.0.0.1" ] }, "staging-database-servers": { "children": [ "database-servers" ] }, "staging-application-servers": { "children": [ "application-servers" ] }, "staging-web-servers": { "children": [ "web-servers" ] }, "staging": { "children": [ "staging-web-servers", "staging-application-servers", "staging-database-servers" ] } } EOS
group_varsは環境やグループ(サーバー群)毎に設定ファイルが配置します。
- all
- 環境に左右されない全てのホストに設定したい内容を記述
- staging(productionやdevelopなど環境名)
- 環境ごとに切り替えたい内容を記述
- サーバー群に依存しない共通設定を書く事を想定
- confファイルを環境毎にansilbe templateとして切り替えたいなど
- staging-web-servers(環境名+グループ名)
- サーバー群単位で環境毎に切り替えたい内容を記述
- 最新バージョンを試す場合などのversion番号など
- web-servers(グループ名)
- サーバー群単位で環境に左右されない内容を記述
- mysqlのport番号など
$ls ./ .ansiblespec dynamic_inventory.sh* group_vars/ Rakefile roles/ site.yml spec/ $ls ./group_vars all production-application-servers application-servers production-database-servers database-servers production-web-servers develop staging develop-application-servers staging-application-servers develop-database-servers staging-database-servers develop-web-servers staging-web-servers production web-servers
playbookでは下記のような書き方をします。
インベントリファイルで依存関係を指定してあるので、ホスト毎にgroup_varsが参照されます。 例えば、web-serversが参照するgroup_varsは「all, staging, staging-web-servers, web-servers」です。
site.yml
- name: install-common-libs hosts: - web-servers - database-servers - application-servers roles: - common - name: install-nginx hosts: - web-servers roles: - nginx - name: install-java hosts: - application-servers roles: - java - name: install-mysql hosts: - database-servers roles: - mysql
うれしかった・よかったこと
- そっこー返事くれて・コードをレビューしてくれテストケースの抜けが1つあったことを指摘してくれた
- あまり自信がなかったが快くマージしてもらえた
- AnsibleSpecが裏でどんな事をやっているかわかった
気になっていること
他の方はどんな風にやっているのか?
実は当記事が、来月に行われる Ansible Meetup in Tokyo 2016.06のLT発表予定のtakuya_onda_3さんによる「Ansibleとterraformで実現するタグベース複数環境プロビジョニング実例」とすごく内容かぶっている気がします。
残念ながら申し込みをしようとした時にはLTも応募枠いっぱいで、抽選にもはずれてしまったのでお話を聞く事はできませんが、どうやってテストをされているか興味があります!
変数値は共有すべきか?
オライリー出版の「Serverspec」という書籍があり、「5.4 サーバ構成管理ツール」の項で、このようにServerspec作者は述べられています。
また、Node Attributes を使ってそのままテストすると、もし Node Attributesを間違った値に書き換えてしまっていても、Serverspecではそれに気づくことはできません。Serverspecの目的の1つは、Chef レシピ等のインフラコードが正しく書かれているかテストすることです。したたがって、Node Attributesを利用してテストを行うと、このようなミスにきづくことができず、本来の目的を果たせなくなってしまいます。
TDDでいう先にテストコードを書いて、テスト失敗で気づくというプラクティスに似ているのかもと。変数値を変数値を共用してしまうとその気づきが失われ、意図しないヒューマンエラーで修正に洩れや間違いがあった場合、実際の環境で問題がおきてから気づくことは、この項を読んで色々と思考を巡らせるきっかけになりました。
今回このような仕組みをAnsible+AnsibleSpecで実現させてはみたものの、上記のようなケースもあり、完璧に自動化・不用意なミスを防げたとは言い切れないなと思っています。ペアワークのレビューである程度失敗は防げますが、そもそも完璧というものを求めてしまうのが過ちなのかもしれません。
私自身、なぜImmutable Infrastructureにするのかの深ぼり、担保したい事やどういう状況にもっていきたいことは何か、運用経験も加味しながら考えていく必要があると感じました。
最後に
今回はすごくいい経験になり楽しかった...
考える事は幾つかあるものの、導入してみて開発・テストのサイクルがすごくスムーズになりましたし、導入の敷居も低いこともあって、AnsibleSpecはお勧めだと感じました! Serverspec自体を使ったことない人にもぜひ使ってみて頂ければと思います。
2015年のふりかえり
今年は思い越せばアクティブに動いた年でした。 2〜3年前の家庭の事で大変だった時期から状況がかわって、勉強会に参加できる時間がとれるようになったのが大きかったのかも。
コミュニティ活動
よこはまクラウド勉強会
夏ごろまでの前半はよこはまクラウド勉強会で地域コミュニティ活動をアクティブにしていました。 今思えば、積み重ねる事によって秋から冬にかけての後半にモチベーションがあがったのかもしれません。
イベント開催ページを確認したら、こんなにも開催したのか...
- 第四回 よこはまクラウド勉強会 「AWSで簡単にWordPressサイトを立ち上げてみよう!」
- 第五回 よこはまクラウド勉強会 「そろそろGitを触ってみたいと思っている方に向けて」
- 第六回 Dockerでらくらく開発・運用を体感しよう
- 第七回 BigQueryでサクッとログ解析してみよう!
- 第八回 Amazon EC2 Container Serviceでスケーラブルなコンテナ管理の世界
- 野毛倶楽部 クラウド時代のソフトウェア開発を考える
- 第九回 Mackerelを使ってサーバーのモニタリングをしてクラウド時代の運用を体感してみよう!
- 野毛倶楽部「いま、なぜドメイン駆動設計か 現状と展望」
- 第十回 AWS LambdaとAPI Gatewayでサーバレスなシステム構築に踏み出してみる
- 野毛倶楽部「Reactiveの夜」
よこはまクラウド勉強会は「ふつうのソフトウェアエンジニアを対象とした勉強会」なので、はじめてみよう系が多かったですね。
このうち私が発表者およびハンズオンの進行者として担当したのが
のふたつ。幾つか予定が重なって参加できなかったものもあったのが残念でした。
通常回とは別開催の「野毛倶楽部」。こちらは主催者の私たちが話しを聞いてみたいと思うネタを肴にゲストを呼んで、野毛で飲みながら話しを聞いたり質疑応答・実際の所どうなの?と、野毛という街で繰り広げました。 私が唯一参加できた岡本さんをゲストに迎えて開催された「Reactiveの夜」は熱かったです!
11月、12月は失速してしまったので来年活動を再開できればと思っています。
Yokohama.vim
秋に2回開催しました。久しぶりにお逢いできた方もいたり、はじめてお逢いできたかたも一緒に楽しい時間を過ごせました。これをきっかけに11月に開催されたVimConf2015でLT発表してみようという気になりました。VimConf2015では大勢の聴衆の前で発表するという久々の経験でしたが、Twitterで頂いたコメントや懇親会で感想を聞いたりお話しをさせてもらったりで、これでまたモチベーションがあがったので、時間がなかなかとれない中でも応募して発表を実行できたのはよかったです。
お仕事
AWS周りのことをやっていた中心に印象です。プロダクトのコードを書く機会がグッと減ってしまいましたが、Ansible周りのスクリプト書いたり、自動化にいそしんだりしていました。また、システムの全体的な構成や方式や仕組みを考えたりして、ステークホルダーがたくさんいるなかでプロダクションへ持っていくまでの難しさも体験しました。
色々と新しい出逢いもあって、Scala先駆者インタビューの企画のインパクトは大きかったです。人間的にも成長できそうで、来年やりたいことがたくさんできました。
会社のことにもパワーをかなり使いました。会社が過渡期を迎えているなかで、ビジョンや方向性を立てて実行していく事と、理想に近い組織形成までの道のりの険しさを感じました。人との関わりを通して、おかれている立場や状況が違えばものの見方が異なり、主観や人の気持ちってそれぞれ違ってくるというのを目の当たりにして、「組織ってむずいけど興味深いなぁ」と。
個人的な興味
GTD
このブログであまり触れてこなかったGTD。Active InboxとThingsを組み合わせて実践しました。 マインドスイープの実行と、タスクの粒度がまだ課題です。
色んな所からストリームで流れてくるTODOを纏めて実行していけるというところまでの形はつくれたので、来年は実用的なプラクティスを確立させてGTDをより進めていきたいです。
Tumblr
Tumblrにはまりました。というより、Reblogを空気のように... 自分の好みや思考がわかるようになってきて、心に残ったフレーズもありました。
フレーズって面白いですね。画像もそうですけどw
来年にむけて
今年は公私ともに「人との関わり」が中心でした。新しい出逢いがここ数年家庭の事情で外への活動が滞っていた気持ちやモチベーションに火をつけてくれたので、来年は新しいMacを手に入れて、影響を受けた事を自分の中で消化したり体感できるように、手を動かす時間の割合を増やしていければと思います。
楽しい事したい。
Skinny Framework Meetup Tokyo 2 に参加しました
池袋のサムライズムさんオフィスで開催されたSkinny Framework Meetup Tokyo 2 へ行ってきました。
オフィス前でエレベーター入り口がわからずグルグルと建物の周りを回ってしまいましたが、建物名と入居社名プレートを発見し無事到着する事ができました。
@seratchさん発表
Skinny Framework 2.0 アップデートに関して発表です。と思ったら、
_人人人人人人人人人人人_ > 突然の さだまさし <  ̄YYYYYYYYYY人 ̄
どうやら、私は会場を完全に間違えてしまったようで、
きっとこの会場に来ている方を含めほとんどの方が動作させた事がないと思うのでデモします
と、そして唐突に日本語名でコンパイル。「エラーが出ても大丈夫。規定ブラウザが開きGoogleで曲名検索できます」「Youtubeで曲が開きます。あっ、今日はハズレの日ですね。」など豪快な技術力の無駄遣いっぷりを目の当たりにして、会場を沸かせました。きっと池袋界隈で瞬間的に気温があがったのはこの為ですね。
続いて、Skinny Framework 2.0 アップデートの話し。会場は間違っていなくホっとしました。
Skinny MicroとScalatraの違いや特徴などをはじめ、OSSの事情なども聞きました。あるOSSのメインメンテナがVMWareに転職したら、違う言語でのOSS活動がアクティブになり元々やっていた事の活動力が落ちてきた話しや、メンテナに名乗りをあげてForkした話しなどとても興味深かったです。時間軸で物事を考えた場合に、どんな人も24時間と使える時間は同じで、「アクティブになれる事」「時間の使い方」「ウェイトのかけ方」などを考えると私自身の事も見つめ直したくなりました。
2.0に関する活動はほとんど一人でやっていたとのことで、構想を形にしたうえで、ドキュメントを始めユーザの事を考えたケアまで行き届いているのには感心するばかりです。
Skinny Frameworkはライブラリ群は単体でも使えるという話しを聞いたので、部分的に使って学習や実用にも役立ててみたいと思いました。
@roundropさん発表
このmeetupに参加しようと思ったきっかけの一つとして、roundropさんが発表すると聞いたからでもありました。 実はroundropさんとは同僚で、発表の中で触れられていた「社内ナレッジ共有ツール」は、立ち上がりから社内に根ざしていくまでの変遷を見てきたので、こうやって存在が事例として世に公表された事に感慨深い物がありました。
初心者の心理を描写したこのフレーズはグっときました。
「Playのドキュメント見ると"we are reactive"とか書いてあって、そういうのあとでいいから、と」 #skinnyjp pic.twitter.com/oULTOPdkeH
— でくのぼうは静かに暮らしたい (@garbagetown) 2015, 12月 22
資料にもでてきた
http://www.slideshare.net/RyujiYamashita/skinny-framework-scala/26
初心者からみる下記は
- はじめやすさ
- わかりやすさ
- 生産性
私も実体験で体感し、Skinny Framework 1.0 Introduction in Japaneseが充実したわかりやすい構成で、数名で行った「社内ナレッジ共有ツール」開発合宿を開催した時に参考にさせて頂き、Skinny Frameworkが始めての人にとって、とても役立った事を思い出しました。
また、「オープンソースにしないの?」という質問に「GoogleApps利用前提などの社内独自仕様などを解消した後にOSSで公開したいです」と回答されていたので、これからがとても楽しみです。
懇親会
サムライズムさんのご好意で当初予定していた懇親会費が無料になり飲み物とピザを振る舞って頂きました!*1 テーブルクロスがとてもかわいくて、これうちの会社にも欲しいなと思いました。 :-)
懇親会では @garbagetown さんから Play Framework の日本語ドキュメント訳をしているという話しを聞きました。
「している」というのがポイントで「ドキュメントが追いついていないんです」とのこと。その理由がすごくて、「私のMacbook Airがメモリ4GBで最新のPlayを使うとファンが唸りをあげて、まともにドキュメント書きながら動作確認できないんです。」と... 「新しいMacbookにしたらファンレスだから大丈夫だね」と周りから冗談を突っ込まれてましたが、「家庭内稟議の関係でまだ新マシンにできてない!」と言われており、すごくリアル感がありました。コミュニティを支えていらっしゃる方も実は意外と私たちとそれほど変わりない家庭環境なんだと親近感をもつ反面、そういう方にメモリが16GBのMacbookを寄贈するだけで、世の中での会社利用の敷居や導入コストが下がったりするので面白いんじゃないかと思います。
これからPlay Frameworkを導入を検討していて「日本語ドキュメント」を切望している会社さん、是非。きっと元とれます(笑)
他にも始めてましてのいろいろな方とお話させていただき楽しい時間を過ごす事ができました。
最後に
Scala界隈のコミュニティへ行ったのは初めてでしたが、楽しかったです。 どうもありがとうございました。