2016-11-07

PHPカンファレンス2016に参加/発表してきました #phpcon2016

PHP SSH

「.ssh/configを管理する .ssh/configで管理する」というタイトルで発表してきました。

発表後の感想

今日の発表は、裏番組強かったしPHP成分ゼロだったけど、人もある程度入ってもらえてよかった。とりあえず最近までの集大成の話ができてよかった。VulsとかSTNSの紹介も（手をあげてもらったら知名度低かった。。。）できてよかった。 #phpcon2016 https://t.co/UJbrCTmTrR
— k1LoW (@k1LoW) 2016年11月3日

話せる場所を作ってくれた @tomzoh をはじめとする懐の深いPHPカンファレンススタッフの方に感謝 #phpcon2016
— k1LoW (@k1LoW) 2016年11月3日

.ssh/configというかなりニッチな話題でしたが、スライドのブクマ数を見る限りは、発表を見ていない人にも少しは興味を持ってもらえたんではないかなーと思いました。（解決方法になるかは別）

komad（仮）も今後も少しずつ考えていきたいなと思います。

PHPカンファレンス（無印）は規模が違った

7年ぶりに同じ開催場所に来たはずなのに、なんというか規模の大きさを感じました。本当にお祭りという感じ。

お世話になります #phpcon2016 pic.twitter.com/8Gude5esuQ
— k1LoW (@k1LoW) 2016年11月3日

#cakephp !!! https://t.co/jLDEwjxOn8
— k1LoW (@k1LoW) 2016年11月3日

満席の発表が出たりするのも凄いなーと思うし、数少ないながらも見れた発表は面白かったし、スポンサーブースの充実度も良かったし、ネットワークは安定しているし、CakePHPは投票1番だし、懇親会では、いろいろお世話になっている人とリアルで会えるし、「これがPHPカンファレンスかー」という感じでした。

スタッフのみなさんありがとうございました！参加者、発表者のみなさんお疲れ様でした！

次回も参加できるように頑張っていきたい。

2016-10-31

PHPカンファレンスで.ssh/configについて話します #phpcon #phpcon2016

SSH

7年振りの参加です。

phpcon.php.gr.jp

PHPは自分の主力言語なわけですが、PHPカンファレンスについては「（出力言語だし）スピーカーになれたら参加する」というオレオレルールを課しています。

そんな他人にはよくわからないルールを課していたら「PHPで話すことがない」ためにずっと参加できずじまいでした。

（PHPが主力なのにPHPで話すことがないってどういうことなんですかね・・・）

RubyKaigiがRubyエンジニアの修学旅行だと言うなら、PHPカンファレンスもしばらく前からPHPエンジニアの修学旅行になってるよね。
今年はスタンプラリーまでやってるし（各地のカンファレンスに参加するとスタンプ貰える）
— suzuki (@suzuki) 2016年9月11日

↑のような楽しみをずっとできずにいました。

募集要項がちょっと違った

そんなわけで毎年PHPカンファレンスで話せるネタを探しては諦めていたのですが、今年PHPカンファレンスの募集要項を確認したら以下のような記述が。

トークのテーマは必ずしもPHPの話である必要はありません。JavaScriptの話、HTMLの話、開発環境の話、チームビルディングの話などなど、PHPエンジニアが聞いて面白ければ何でもOKです。

「これはPHPカンファレンス福岡と同じだ！」ということで、さっそくずっとどこかで喋りたかったことを応募しました。

.ssh/configを管理する。.ssh/configで管理する

様々なプロジェクトに関わっていると、自然と様々なサーバへのSSH（公開鍵認証）が必要になり、.ssh/configの管理も必要になります。これを管理する1つの方法、また、逆に .ssh/configを利用してサーバ情報などを管理しようとしている取り組みについて紹介します。

今年のPHPカンファレンスのテーマは"NEXT"ということです。

Docker界隈などで「SSHをしたら負け」と言われはじめている昨今の状況からすると、.ssh/configの話はあまり似つかわしくないかもしれません（言い訳をすると応募当初、今年のテーマを知りませんでした）。

ただ様々な事情からSSHを多用するエンジニアの方は（自分を含め）いますし、これからも .ssh/config と向き合っていく必要性はあると思います。

ただ、「普通に .ssh/configをホームディレクトリに置いてSSHだけをしている」方に、ちょっとだけ"NEXT"に行ってもらえるような話ができればと思います。

ちなみに本当の"NEXT"は多分もっと先か、別な方向なので、サイセンタンな方には物足りないかもしれません。

キーワード

.ssh/config
サーバ管理

PHPとTokyoTyrantの組み合わせについてLTした以来のPHPカンファレンスでの発表！楽しみです！（はい！「TyokyoTyrant懐かしいなー」とか思ったアナタ！是非声かけてください！）

ところで

PHPカンファレンス（本家）が言語の制約を取っ払ったのは今年からですかね？

自分みたいなニッチなことにしかコミットしない（それ以外は普通な）エンジニアにはとてもありがたいです。

少なくとも応募できるのが嬉しい。

buildersconにも応募したかった人生だった。。。

2016-10-27

Backlog Favicon ChangerをNew UIに対応させました

Backlog Chrome

nulab-inc.com

というわけで、いつもお世話になっているBacklogにNew UIがやってきました。

ただ、残念ながら今回のアップデートでもファビコンは各プロジェクトのアイコンを反映するものではなかったので、「これはまたBacklog Favicon Changerの出番かな」と思ったらHTMLが変わった結果、見事に動かなくなりました。

というわけでNew UIに対応しました（v0.2.0）（Chromeウェブストアへの反映待ちです）。

chrome.google.com

新しいUIに対応してくれるといいなー♪ Backlogのプロジェクトごとのファビコンをわかりやすくする"Backlog Favicon Changer"をつくった - Copy/Cut/Paste/Hatena https://t.co/Jz93hkzXck
— しばっち Hiroki Shibata (@sivacchi) 2016年10月23日

というわけでニッチですがご利用下さい。

2016-10-18

JAWS Festa 東海道2016でawspecとかAWSの構成テストとかについて話します

AWS

登壇者応募をして採択されたので今週末名古屋に遠征します。

楽しみです。

jft2016.jaws-ug.jp

AWSをテスト(？)

タイトルは「Inside of awspec -AWSをテストする方法。そしてその中のはなし-」ということなのですが、 25分という時間なので、内容的には、JAWS-UG福岡：３度目の濃い目にAWSの話をしてみよう - JAWS-UG九州 | Doorkeeper で喋った若干濃い内容を時間に合わせてぎゅぎゅっと濃縮して短くしたうえで、「AWSのリソース構成のテスト(？)」について思うことをしゃべろうと思います。

awspecのメンテナンスをしていると、いろいろなPull Requestを国内外からいただきます。本当にありがたいです。

そのPRから垣間見える「テストツール作ってくせにお前わかっていないな！ここをテストしたいんだよ！」という思いとかは、実際にPRをマージしている自分が紹介すると面白いかなーと思っています。

会社の元名古屋在住の同僚に20,000円オーバーの寿司屋の紹介をされて戸惑っているので、もう少しリーズナブルなところで美味しくご飯を食べたいです。

ぼっちだと思うので是非声かけて下さい！

2016-09-30

Developers Summit 2016 FUKUOKAで発表してきました

発表してきました。

思い起こせば10年たっていた

どうやら勤続10年目に突入していました。実は、会社の全体合宿でサプライズで祝ってもらったことで気づきました。

気づいたら入社10年目。会社のツートップからのサプライズプレゼント。一生モノ。頑張ります。 #work10thyears

10年かー

と思いつつ、ちょうどいいので10年を振り返る形で、Fusicがどのように生き延びてこれたのかについて考えた結果を発表しました。

実際は正直わからない

ぶっちゃけたはなし、

いちエンジニアの想像ですし、全ては結果論でしかないので合っているかどうかはわからないです。

ただ、最後の結論について同意してくれる人が思いのほか多く、「もしかしたら間違っていないかも」とも思ったり。

こういうイベントで、ツートップが喋ったら面白いと思うんですけどねー。聞いてみたい。

というわけで

良い機会をいただきありがとうございました。

2016-08-24

Codenize.toolsのRoadworkerのソースコードを読む(roadwork -e) #fukuokarb

AWS Ruby

AWSのCLIツール系では最高レベルに便利なCodenize.toolsからいろいろ学ぼうと思って、Fukuoka.rbでもくもくと読んでいました。

fukuokarb.connpass.com

同時にawspec業もしていたので、面白そうなapplyコマンドまで読み進められなかったのが残念。

以下、メモ。

bin/roadwork

なんとなく bin/roadwork からスタート。optparseを使っているのか。

if options[:debug]
  Aws.config.update(
    :http_wire_trace => true,
    :logger => options[:logger]
  )
end

おお...（デバッグオプションとかつけてないな、awspec

client = Roadworker::Client.new(options)

roadwork -e

awspec generateと同じ流れだろうと踏んで、exportコマンドから追ってみる。

コードを追ってみると実体は Roadworker::Exporter#export_hosted_zones(hosted_zones) っぽい。

Roadworker::Collection.batch

Roadworker::Collection.batch で（大抵のaws-sdk-rubyの*::Clientクラスのレスポンスで返ってくる）ページング可能なオブジェクトをいい感じに回している。カッコいい。

module Roadworker
  class Collection

    class << self
      def batch(pageable_response, collection_name)
        pageable_response.each do |response|
          response.public_send(collection_name).each do |item|
            yield(item)
          end
        end
      end
    end # of class method

  end # Collection
end # Roadworker

DSL変換

aws-sdk-rubyからのレスポンスをいい感じにハッシュにまとめてRoadworker::Client#exportに戻して、今度はRoadworker::DSL::Converter#convert でRoadworkerのDSLに変換している。

Roadworker::DSL::Converter#output_rrsetの中

name = recrod.delete(:name).inspect

Hash#deleteの動きで、keyを消しつつvalueを取り出していて、String#inspectで、エスケープしている。こういうふうに使うのかー。

というわけで時間切れ。

2016-07-28

"Amazon Web Service企業導入ガイドブック" はまさにそのサブタイトルの通りだったし、AWS導入に関わるエンジニアも読んでおくべき内容だった

AWS

タイトルでほとんど言いたいこと言ってしまった。。。。

なおサブタイトルは

企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで

です。

Amazon Web Services企業導入ガイドブック -企業担当者が知っておくべきAWSサービスの全貌から、セキュリティ概要、システム設計、導入プロセス、運用まで-

作者: 荒木靖宏,大谷晋平,小林正人,酒徳知明,高田智己,瀧澤与一,山本教仁,吉羽龍太郎
出版社/メーカー: マイナビ出版
発売日: 2016/06/10
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

@ryuzeeさんがプレゼントキャンペーンをされていたので、興味があったので応募したのですが、見事に当たりました。

connpass.com

本当にありがとうございました！

じっくり読んでいたら時間がたってしまったのですが、本当に読んで良かったです。

というよりも、この本は、特に弊社みたいな会社は、エンジニア問わず広く共有すべき本だと感じました。

いくつか感じたことを書いておきたいと思います。

AWSの全貌をつかめるという意味で網羅的である

まず、AWSの全貌をつかめるという意味で網羅的です。

AWSは今では70を超えるサービスがあるそうです。

AWSを導入するにあたって、より良い形で導入するためには、それなりに各サービスを知っていなければなりません（知っていなければ検討すらできない）。

自分もawspecというAWSのサービス全体に関係できるツールを作っていますが、全てのサービスを良く知っているわけではありません（なので理解できたところから実装している状況）。

そういった意味でも、たった数ページで検討や調査をする最初の一歩にできるのは非常に心強いです。

企業として導入において検討すべきポイントが網羅的である

さらに、導入において、検討すべきポイントが列挙されているという意味で網羅的です。

"企業導入ガイドブック" と銘打っているだけに、「おみそれしました。勉強になります。」としか言えない内容です。

自分みたいなエンジニアは、ついついAWSのテクノロジーの新しさに目がいきがちですが、企業にとって必要なポイントは、AWS導入によって得られた価値です（ざっくり）。

AWS導入に関わるエンジニアはまずこの本で「提案内容、導入検討内容に、ヌケモレがないか」を確認をしたら良いと思いました。リーンシートとか3Cとかフレームワークみたいなイメージ。

"AWSノックアウト条件"など、ヒアリングが漏れていて時間をかけて検討が進んだあとに「実は導入できませんでした」となったら目も当てられません。

導入前の分析から導入後の改善まで、フローについて網羅的である

導入だけでなく、導入前の検討から。導入まででなく、導入後の運用、さらには監視・改善まで。企業としてAWSに関わる全てのフローについて網羅的に記載されています。

なので、導入時に読む本でもありますが、運用時に読む本でもあると言えます。

AWSに関わっている間、いつ手にとって良いという意味でも非常に強力な書籍と言えます。

というわけで

網羅的でした！もう社長も含めて社員全員読めばいい！！

次はうちのマーケティングチームのリーダーに情報を共有して読んでもらおうと思っています（会社の書籍制度フル活用）。

AWSに関わるならば一度は読んでおきたい本、置いておきたい本です。

AWSに関わるエンジニアとしては、この本から飛び出した価値を提供できるようがんばらないと。。。