2013-05-12
Hachioji.pm #28 に行ってきました
hachioji.pm | |
Hachioji.pm #28 に参加してきました。当日はあいにくの空模様でした。
Hachioji.pm 開催日は天気が悪い事が多い気がするので、誰か雨男がいるに違いねえ……
(事前ハッカソンにも参加してきましたが、とりわけモノは完成しませんでした。残念です)
今回のHachioji.pm はというと、Microsoft Surfaceみせびらかし会があったり、TDD って名前がイケてないよねー的な議論があったり、
RTOS の話があったり、ファッションチェックがあったりと盛りだくさんな内容でした。
特に「ファッションチェック」なんかは普通のIT 系勉強会ではまあやらない内容ですよね！ 非常に捗ります！！！
メモ
今回のLT のテーマは「ヤバイと思ったが、○○を抑えきれなかった」でした。以下メモです。
- @kkotaro0111 さん - Sketch の話
- @K_Trial さん
- @ichigotake さん - Yancha 料金請求プラグインを作った
- @hide_o_55 さん - Data::FuzzyHashの話
- Algorithm::HyperLogLog のランカスターコンセンサス対応
- Data::FuzzyHash の話
- @akira1908jp さん
- @ono_pm さん
- @uzulla さん - TAILF の話
- http://tailf.cfe.jp/:TAILF というウェッブサービスを作った
- Perl で初めて書いたウェッブサービス
- 詳しい話は以下を参照
- サーバー台くらいは出たかも！
- 「ヤバいと思ったが宣伝を抑えきれなかった」
- http://tailf.cfe.jp/:TAILF というウェッブサービスを作った
- @maka2_donzoko さん
以上メモでした。
僕のLT
40分くらいで勢いに任せてスライド作ったら、なんか微妙な感じになりました！！！中途半端にマジメな内容なのでおもしろみが一切無い！！！ しんだ！！！！！
Hachiojipm 28 from moznion
そんな感じです
@kkotaro0111 さんのLT で紹介されていたSketch、なんだか便利そうなので使ってみたいなと思いました。あと、Data::FuzzyHash も使い方によってはなんだかすごい便利そうですね！
次回
次回みんなで喜びをわかちあおうと思う。そういえば次回いつにするか #hachiojipm 6/15、または22か…
コメントを書く
2013-05-11
Provisioning Frameworks Casual Talks vol.1 に参加してきました
|
Chef とかChef-Solo とかを最近触っていて、知見を広めたいというモチベーションがあったので、
Provisioning Frameworks Casual Talks vol.1 に参加してきました。
講演の内容としては以下の通りです。
@fujiwara さん - 新卒研修でserverspecとChefを使った話
http://dl.dropboxusercontent.com/u/224433/pfcasual_1/index.html@antipop さん - 宣伝Puppet Book
https://speakerdeck.com/kentaro/puppet-book@naoya_ito さん - 入門 Chef Solo 落ち穂拾い
https://speakerdeck.com/naoya/ru-men-chef-sololuo-tisui-shi-i@jhotta さん - Chef市場動向
(資料がみつかりませんでした……)@sethvargo さん - “chef-plus-environments-equals-safer-infrastructure”
https://speakerdeck.com/sethvargo/chef-plus-environments-equals-safer-infrastructure@hiboma さん - SqaleのChefとテストの話
(資料がみつかりませんでした……)以下、メモ書きです。
なんか間違ってたら指摘して下さると助かります。
(@naoya_ito さんのトークの終わりあたりからメールの対応をせざるを
得ない状況に陥ったので、メモの量が少なくなってます……すみません)
メモ
- @fujiwara さん - 新卒研修でserverspecとChefを使った話
- 手作業でのセットアップはだるい
- シェルスクリプトを書くよりもChef で書いた方が良いのでは無いか
- Chef が出始めのころ
- 当時はPuppet の情報を知らなかったので、特別比較して採用した訳ではない
- Chef 全般の話
- Cookbook 運用の話
- Chef-Server vs Chef-Solo
- 各サービスごとにChef-Server を用意したくない
- 強力なChef-Server (一元管理できるような) を立てる方法も有るには有るが……
- solo + sh で運用、後にsolo + capistrano に移行
- Solo でやるよりもChef-Server で運用する方が良いのか？
- 台数がそこまで無いのならsolo でも良いのでは
- インフラ管理者とアプリ開発者が分離してしまう
- 新卒研修の話
- serverspec
- サーバーが要件を満たしているかどうかをテストできる
- recipe とspec は対応している
- spec を書いてからcookbook を書いてやると良いのでは無いか
- serverspec ではコマンドの実行結果もテスト出来るので、振る舞いレベルのテストもできる
- cron とテストスクリプトを組み合わせて監視すると、人的なオペレーションミスも検出できる
- まとめ
- 手作業からバージョン管理されたコードへ
- 「コードを書いてテストを書く」これをインフラでもやらなければならない
- 監視 = 継続的なテスト
- @antipop さん - 宣伝 入門Puppet
- 以下から出版中
- 入門Puppet Tシャツもある
- 日本初のPuppet 本
- Puppet を使っていると苦労する
- 日本語の資料が少ない
- 日本語の資料、有るには有るし内容は良いが、情報が古かったりする
- 結局、英語の厚いドキュメントを読まないとやってられないのでつらい
- オペレーションの専門家だったらできる（やる）けれど、カジュアルに使ってみたい人にはきつい
- 入門Puppet の読者層はオペレーションエンジニアよりもアプリケーションデベロッパを装丁している
- 基礎編
- 応用編
- Learnning Puppet は良いリファレンスだが、入門に使うには難しい
- Chef で出来る事はPuppet でもできる
- エンジニアの共通語はコードである
- システムの状態をコードで記述し、ソーシャルシステム構築を行う
- 秘伝のタレ的なものを無くす
- プルリクでレビューも出来る
- システムの状態をコードで記述し、ソーシャルシステム構築を行う
- プラットフォーム固有のアセンブラ→高級言語
- プラットフォーム固有の手作業→Puppet/Chef
- システム構築に無精を持ち込む
- サーバー立てるにあたって、面倒な事が多すぎる
- 一見、プロビジョニングツールは面倒だが、面倒を回避するために面倒をこなして勉強する
- これぞ無精
- Infrastructure as code
- Chef vs Puppet
- @naoya_ito さん - 入門 Chef Solo 落ち穂拾い
- 実際の電子書籍の売れ行きに関して
- 現時点で合計2409部出ている
- 週に80 くらいのペースで出ている
- 電子書籍の売り上げで家を建てたい
- Facebook の話
- Chef でどこまでやるのか
- どこまでも
- 基本的にはChef だけでやる
- インスタンス起動後の構成変更は全てChef で行う
- 直接触ってはならない。外部からの変更が加えられると、Chef は元の状態に戻そうとする。
- アプリケーションのデプロイは例外。capistrano など
- Chef は自動化ツールではない
- Chef はノードの状態を管理するものである
- Convergence (収束)
- Chef-Solo でどこまでやるのか、できるのか
- 数百台〜 Chef-Server 一択
- 数十台くらいまで Solo でも頑張れる、Server を導入するかどうか迷うところ
- 数台だったら xargs + knife solo でよいのでは
- xargs につらくなってきたらcapistrano の出番
- Chef-Server はノードの検索が出来る
- 莫大な数のノードがあると、どんなノードがあるかとか把握しきれない
- 検索があると便利
- 莫大な数のノードがあると、どんなノードがあるかとか把握しきれない
- Chef-Server ではClient が自立更新できる
- Chef-Server は導入が面倒
- chef-zero がある
- 未確認情報
- Chef vs Fabric
- Git でレシピを管理すればノードの「状態」をバージョン管理する事が出来る
- 開発環境の構築にChef を使う
- テストはどうするのか
- 実際の電子書籍の売れ行きに関して
- @jhotta さん - Chef市場動向
- @sethvargo さん - “chef-plus-environments-equals-safer-infrastructure”
- @hiboma さん - SqaleのChefとテストの話
雑感
Chef、Chef-Solo を触ってからまだ日が浅いので、情報に追いついていくのがやっとの状態でしたが非常に勉強になりました。「Chef-Server とChef-Solo をどういった基準で使い分けるのかの判断」といった話題はやはり経験が物を言うと思うので、
経験豊富な先駆者の皆様から貴重な情報を聞く事が出来て良かったです。
あと、テストの話題が多く出ていて大変参考になりました。
実際にどうやってテストをすれば良いのかがいまいちピンと来ていなかったのですが、
とりあえずserverspec が良い感じだ！！！！ という事が分かったのは収穫でした。
「調べようにも、それを調べる為のワードを知らないが為に詰む」というケース、結構あると思うんですよ。
そういう場合には人に聞くのが一番なんだけれど、周りに聞ける人がいないしインターネッツでも誰も相手してくれない！！ 本格的に詰んだ！！ という時に、
こういう勉強会に参加して情報仕入れて、ググリングワードを獲得する、みたいな流れは本当に重要だと感じているんですよね。
今回は「テストしたいけどどうすりゃいいんだろう、ググっても良い感じに引っかからない……」という軽く詰んだ感じの所に、
「serverspec」という検索ワードを手に入れられたのは本当に良かったです。それだけでも儲けものみたいな。
なので、プロヴィジョニングフレームワークに話題を絞った勉強会を開催して下さった@studio3104 さんと発表者の皆様には大変感謝しております。
次回もよろしくお願いします！！！
(付録) 事前登録不可/先着順受付というシステムに関して
僕みたいな小心者は「会場、入れるのかな……定員オーバーして入れなかったらどうしよう……わざわざシヴヤとかいう怖い所まで来てるのに……ｳｯ、胃が」みたいな感じになっちゃうので、メンタルに良くない感じはしています！！！ 1日中そわそわしてしまう！
事前登録不可/先着順受付システムって、事前登録制に於いてドタキャンしたりカジュアルに遅刻してきたりする人があまりに多すぎる為に出来たシステムだと思うんで、
それは良いと思うし画期的だと思うんです。
ですが、それって今までちゃんとやってきた人達 (遅刻とかしない人達) が割を食ってる印象が拭いきれないんですよね。僕だけかもしんないですけど。
個人的には事前登録方式の方が安心感があって良いなーと思っています。
とかなんとか言ってますけど、主催側の一番楽な方法が良いと思います！！！ 我々は開催して頂いている側なので！！
蛇足
学振の提出に失敗しました2013-04-19
chef-jubatus を書きました
https://github.com/moznion/chef-jubatus
色々と必要に迫られたので書きました。
Chef の詳しい事とか難しい事とか、あんまり分からないのでrecipe にベタァッと書いてます。
なんだか良くない予感がしますね！！！！
とりあえず、run_list にrecipe[jubatus] を加えてやるとjubatus をインストールしてくれるはずです。
Red Hat Enterprise Linux 系のOS とDebian 系のLinux だと動くと思います。
Pull-Request 等、目下募集中です！
2013-04-15
cpanfile 向けのVim 拡張を書きました
cpanfile が書きやすくなるかも知れないVim 拡張を書きました。
「書きやすくなるかも知れない」ってことは「書きやすくならないかも知れない」って事です。
深淵ですね。
プラグインたち
何ができるのか
- vim-cpanfile
- cpanfile キーワードの自動補完 (neocomplcache に依存)
- シンタックスハイライト
ハウトゥユーズ
インストール
NeoBundle 'moznion/vim-cpanfile' NeoBundle 'moznion/syntastic-cpanfile'的な感じで。他の管理システムを使っている場合はそれに合わせてよしなにお願いします。
共通で設定するもの
.vimrc に以下を記述しましょう;... au BufNewFile,BufRead cpanfile set filetype=cpanfile au BufNewFile,BufRead cpanfile set syntax=perl.cpanfile ...
自動補完を使う場合
.vimrc に以下を記述しましょう;let g:neocomplcache_dictionary_filetype_lists = { \ ... \ 'cpanfile' : $HOME . '/.vim/bundle/vim-cpanfile/dict/cpanfile.dict' \}（事前にneocomplcache をインストールしておく必要があります）
シンタックスチェックを行う場合
syntastic-cpanfile/syntax_checker/cpanfile ディレクトリのシンボリックリンクを張ります。（パス等は環境に合わせて適宜読み替えて下さい）
cd ~/.vim/bundle/syntastic-cpanfile ln -s `pwd`/syntax_checker/cpanfile ~/.vim/bundle/syntastic/syntax_checkers/cpanfile或いはディレクトリのコピーを取る方法でも良いです。
cd ~/.vim/bundle/syntastic-cpanfile cp -R syntax_checker/cpanfile/ ~/.vim/bundle/syntastic/syntax_checkers/多分、シンボリックリンクの方が良いと思います。
（事前にsyntastic 及びModule::CPANfile のインストールが必要です）
そんな感じです
いちいちシンボリックリンク貼ったりするのが面倒くさいので、そこら辺はいずれ何とかしたいと考えています。
2013-04-12
Test::LocalFunctions というモジュールを書いてました
色々と[私仕]事が重なっていて忘れておりました。
Test::LocalFunctions をリリースしておりました。
https://metacpan.org/module/Test::LocalFunctions
https://github.com/moznion/Test--LocalFunctions
これはなに？
モジュールファイル内 (MANIFEST ファイルに記載されているpm ファイル群) に、使われていないローカル関数が存在していないかをテストします。
ここで言う「ローカル関数」というのは、関数名がアンダースコア(‘_’) から
始まる関数の事を指しています。
モチベーション
gfx さんのTest::Vars が便利で、「これのローカル関数版がほしいなー」と思って作りました。
そこそこ規模の大きいモジュールになってくると、使われてないローカル関数が
存在する場合がしばしばあるんですが、それを人力で検出・判断するのはだるいので、
そこら辺は自動的にやってしまおう！ というのが動機です。
静的解析 *1 のフェーズでやっちゃえる事はやっちゃった方が良いという思想に基いています。
なかみ
本当はB 系のモジュールでゴリゴリモリモリッと書くのが正しいし、何より早いのは理解しているんですけど、ちょっと今の僕のパワーでは無理だったので、
PPI を使ってゆるふわな感じで実装しています。
PPI でバッツンバッツンぶった切って、解析に不要な部分は予めフィルタしてから
処理を行う、という感じで実装しています。
ソースを読みましょう。
読みましたね？
ゆるふわでしょう。
大丈夫かこれ。
ゆくゆくはB とかで再実装したい感じはあります。
*1：と言うのだろうか？
