「Webエンジニアが知っておきたいインフラの基本」読みました

Web系エンジニアでベンチャーに転職して1年ほどやって来て、自分のインフラ力の低さを実感するとともに前職のインフラ先輩勢の方々は偉大だったのだと認識することが多いのでこの本は自分向けだと思い買ってみました。リアル本もあるのですが、達人出版会/Kindle から電子版も出ています。自分は電子版を買ってみました。

本の内容など

インフラスキル高い人が当たり前にやっている、

• モニタリング・監視ツール
• tcpdump
• パフォーマンスチューニング

などについて、わかりやすく書かれています。

扱ってくれてる範囲が広く、今のところは必要ないけど、困ったら参考にする、みたいな知識がいっぱいあって良かったです。

特に、P.210にあった以下の言葉が重要だと感じました。

特によく使われている歴史のあるミドルウェアの場合、制約のデフォル ト値は往々にして小さく設定されています。ハードウェアはムーアの法 則に乗ってどんどん高集積化していますが、ソフトウェアのデフォルト 設定値はこのハードウェアの進化に追従できていないことが多いので、 制約の上限の影響で性能問題が起きていないか調査しましょう。

システム的に負荷が掛かってトラブルが起きている状況で、今の時代カジュアルにインスタンスを1グレード良い物に変えて改善を試みる、ということができてしまうのですがCPUやメモリを使い切っているわけではないのになぜか調子が悪いということも良くあるので、どこかしらのOSの設定やミドルェアの設定がボトルネックになっていないかをチェックしないといけないですね。

良かった一言

障害時の連絡フローの話で、

なお連絡を貰った側は、念のためだとしても、的外れだったとしても、た とえ不要な連絡であっても感謝する姿勢を示し、次回以降に萎縮されないよう務める必要があります。

というのが心に響きました。(p106)

これはソフトウェア開発においてのバグレポートにも同じことが言えそうですし、心掛けていきたいと思います。

Webエンジニアが知っておきたいインフラの基本 ~インフラの設計から構成、監視、チューニングまで~

パーフェクトRuby on Rails 読みました

パーフェクトRuby on Rails買って、家庭持ち朝方エンジニアなので毎日朝25分ずつコツコツ読んでて読み終えたので感想書きます。

全体として

実践的なテクニックがいっぱい書いてあって、「これいいね、すぐやろう！」とか、「こんな便利なものあったのか！」みたいな感動をたくさん経験できる本です。

一方で、リファレンス的なことはそんなに書かれていないので、そういうのはRails公式ドキュメントを読むか別の本を読むのが良さそうです。 手元において調べ物をしたいときに読む本というよりは、まず読んでみて、「なにこれすごい」って思ったことをすぐに実践してみて、またしばらく時間を置いてから読むとその時に気づかなかった別の凄いテクニックに気づく、みたいな本だと思います。Ruby本で人気のあるメタプログラミングRubyとかもそんな感じですね。

これやろうと思ったこと

NewRelicの導入(p.313)

NewRelicの導入手順や画面での導入手順が書かれており、今まさにRailsで新サービスを開発している自分にとってダイレクトに役に立つ情報でした。 計測にあたって見るべきポイントも詳しく書かれているので、すでに導入済みの人にとっても読むべき情報だと思いました。

Rack::CommonLogger::Fluent(P.327)

最近のログ集積のデファクトスタンダードと言えるFluentdや、それを可視化するkibanaについても書かれています。

FluentdでRailsのログ収集をするにあたって、RailsのログをltsvにするGemを試したりしていたのですが、ユーザのアクセス情報については細かくltsv化してくれるわけではないようでした。このGemを利用することでFluentdで扱いやすい形になってデータ収集できるようなのでこちらも使ってみようと思います。

値オブジェクトとcomposed_of(p.353)

まったく知らなかった知識だったので、非常に勉強になりました。

関連している属性を別モデルに切り出してスッキリさせたいけど、データベース的には同じレコードで保持しておきたいというケースはあるので、そういうときにこういう解決策があるというのが知れたのはとても良かったですね。使うべきところを見極めて、活用していきたいと思います。

その他にも良かったことリスト

初耳だったり、あまりはっきりと知らなかったことを改めて知れて良かったです。

• コールバックの条件分岐の書き方と、コールバックが走らないメソッド
• ActiveRecordのenum型
• distance_of_time_in_words_to_now => タイムライン型のサービスで使うと捗りそう
• jbuilderの使い方
• coffee-rails-source-maps
• 特定のパスをautoload対象にする
• sideKiqの使い方
• exception_notification
• shoulda-matchers
• brakeman
• unicornの設定
• capistrano-github-release

まとめ

即実践できる内容が盛りだくさんで、とても満足度の高い書籍でした。 Railsで仕事している人なら買いだと思いますので、ぜひ読んでみてください。

パーフェクト Ruby on Rails

「Team Geek」読みました

身近なエンジニアの人達が面白いって言っているので、気になってはいたもののまだ読んでいなかった「Team Geek」をようやく買って読みました。

内容

エンジニア及びエンジニアのマネジメントをする立場向けの本ですね。とはいえ、技術的に難しい話はなく、謙虚・尊敬・信頼を持ってメンバーと接しよういうのが中心のメンタルに訴えかける感じの本ですね。私としては転職をしたこともあり、今は幸福な感じなんですが、これから生きていくのにつらくなったら読み返すべき内容がたくさんあるな、という感想を持ちました。

GoogleのエンジニアというすごいGeekな人たちの話になるものの、普通のエンジニアである自分が読んでも共感できる内容はたくさんありました。

特に良かったポイント

p.xxv 趣味（コンピュータで遊ぶこと）で生計を立てられることがわかった

なにげなくさらっと書いてあるんですが、いつの間に、（仕事で）コンピュータさわることが「今日も頑張ります！」みたいな感じなっちゃったのかなぁ、って考えさせられました。本当はコンピュータさわるの楽しくて仕方なかったのでこの仕事についたはずなので、初心を取り戻す必要があることを感じました。

P15. 三本柱

先程述べた謙虚・尊敬・信頼の話ですね。本書ではHumility, Respect, Trustの略でHRTという用語が何度も繰り返し出てきます。

p21. コードの否定の話

「君は君の書いたコードではない」という、指摘される側に向けたアドバイスが有りつつも、指摘する側に対しても「間違ってます」ではなく、「こうすればどうだろうか」とすべきという話が書いてあるのは良かったですね。つまり、「こんなひどいコードを書くのは間違いである！」&& 「コードの否定は人格否定ではない」というのを同じ人が考えているのはとてもまずくて、お互いのHRTが大事ということですね。

p47. 「ミーティング中はノートPCの使用禁止」みたいなことを言い出す人がいるが、それでは何も解決しない。メールを読み出すのは、おそらくミーティングに参加しなくてもいい人だからだ。

会議に呼ばれたので内職します VS ノートPCの使用禁止おじさんの夢の対決、よくある

• p71,72. パフォーマンスの低い人への対処の話
• p85. 建設的な批判の話
• p89. 事を荒立てるときを知る

明らかに生産性が低い人やチームへの対処として静観してても改善されないし、やんわり伝えても改善されない、みたいな状況の時にどうすべきかということの悩みを前職の時に持っていたので、しっかりとなにが問題なのかを伝えるということをしていかないといけないなと認識しました。

p87. 誰かがやらなくてはいけない面倒で報われないタスクをまとめて表にして、チームに均等に割り当て

このやり方は参考になると思いました。特にエンジニアリングでいうと自動化で楽になろう、という話が流行ですが、どうしてもすぐには自動化できなくて手作業が必要な苦しい作業が残ってくるので、こういうのを均等にやるっていうのは大事だと思います。

p128. オフィスの政治家

こんな言葉知らなかったけど、たしかにこういう人いるなぁと思いました。

p136. 「攻撃的」な仕事と「防御的」な仕事

ひたすら技術的負債を気にせずにその場しのぎの汚い設計、コードで機能追加させるやり方と、リファクタリング、疎結合に時間をかけきれいな設計を作りつつ顧客になんの価値も届けてないというどちらの状況も良くないですね。最近、「技術的負債」に関する話題が盛り上がってますが、自分もきれいな設計とビジネスの成功の因果関係は最近気になっていました。技術的負債の解消に関する仕事を「防御的」な仕事と定義し、それに労力の1/3〜1/2を掛けないという話を書いていました。この分量の話は考え方の参考になると感じました。

p145. 正しいことをして、解雇されるのを待とう。

正しいことをしていく、というのがキャリア戦略の話。

最近、会社を辞める話をした時に「大企業やめてベンチャー行って大丈夫か？」的なことをすごく聞かれたのですが、会社に縛られるキャリアではなく、ビジネスの成功のために技術的貢献ができるキャリアでありたいと考えて転職したので、この話はすごくしっくり来ました。

p160. ウェブページの読み込み

いきなりアカウント登録させるUXのダメさと、ウェブページの読み込み秒数を早くという話。 「遅い」と不満が出てから解消するのでは遅くて、継続的に観測して手を打っていかないといけないな、と感じました。

p170. ユーザの技術的能力が下がる話

アーリーアダプタとレイトマジョリティの話ですね。 ユーザが増えていくと既存のユーザはより進化した機能を求めますが、難しくしてしまうと新規ユーザの流入が止まってしまうというのは、成熟してきたソフトウェアにもありますし、ゲームの続編（特に音ゲーや格ゲーみたいなスキル求められるやつ）なんかにもある話だと思います。

まとめ

技術的にすごい何かが即効性で身に付くような本ではないですが、今後のエンジニア人生における考え方として共感できる部分が多いです。 前向きに働けるようになると思うのでぜひ読んでみてください。

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

WEB+DB PRESS Vol78 読みました

先日出たWEB+DB PRESS読みました。

WEB+DB PRESS Vol.78

今回自分的に良かった情報はこんな感じです。

実践スクラム

• スクラムチームの全体像の図(p.17)
  • 役割の再認識ができました。
• ユーザーストーリーの基準、「INVEST」(p.22)
• ユーザー目線でイイネ！の思考(p.28)
  • 機能を実装する前提のストーリーではなく、ユーザのやりたいことからのストーリーにすることで、その内容がユーザに価値をもたらすかどうかというところから考えられる、という内容
• スクラムごとに出荷可能な増分を出すために品質保証チームをメンバーに入れているという話(p.34)
• スプリントバックログを書いてみたらバラバラで、みんなの頭のなかがはじめて見えたという話(p.38)

DMM.com

• サービスの特性に合わせてフレームワークを選択するという話(p.47)
  • 2つ目の理由の「技術を特定のものに限定すると技術者の思考が硬直化して、新しい技術への興味を失う」というのをリスクとして考えているのが良い会社だと思いました。
• OpenID Connectへの移行進めているという話(p.49)
  • そういえばFBでログインできるようになってなぁ、と思いだしました。
• マルチデバイスで、レスポンシブWebデザインは採用していないという話。大規模サイトには向かない。(p.51)
• 高速開発
  • DMM.comはスピード速いのに、プロジェクト立ち上げの会議や開発計画作成と大人数でのキックオフ会議、一部にウォーターフォールのプロセスを採用など、大企業でもやっているようなプロセスを行っててうまく回っているというのが面白いなぁと思いました。

Redshift

サービス概要について非常に良く分かったのでよかったです。値段もまだ高いので、自分が必要になるのはもっとデータを取れる仕組みを構築してからだな、とわかりました。BIツールとの連携(p.97)で自分が昔使っててつらかった製品名が載っていたんですが、この記事を読んでみて使い方をちょっと間違えてたかな、という気がしてきました。

Middleman

記事自体の完成度も高い上に、個人的に気になってた

• Grunt
• Yeoman

との違いが書かれていたのが良かったです。Jekyllとも競合してる部分があって、Middlemanに移行している話もあるとかの情報がありがたかったです。

一歩先ゆくRuby Rails4世代のgem

全部便利そうなんですが、ransackとpublic_activityは完全に初耳で便利そうだと感じられたので良かったです。

WEB+DB PRESS vol.77(2013/10発売) をようやく読みました

10月に出たWEB+DB PRESSまだ読んでなかったのをようやく読みました。 今後、自分に役立ちそうな記事はこんな感じでした。

スマートフォンテスト

ゲーム系のテストは、仕事で使うことはないもののそういうやり方をしてるんだぁ、というのがわかって面白かったですね。 Seleniuをirb使って動作確認するのは、上手く動かない時に調べるのに役立ちそうだと思ったので今後やってみます。

あとは、PhantomJSも今後capybara-webkitから移行していきたいと思っていたので記事があって良かったです。

AWSの話

EC2, S3, Glacier, RDSの話はよく理解できて面白かったですね。

実際に自分たちで運用しているDBサーバをRDSに置き換えたらどれだけ料金がかかる代わりに人的コストはどれだけ減らせるんだろう、というのは気になりますね。もちろん、増えるとか自分たちの使い方にはそもそも合わない、というケースも有るでしょうけど。

ネットワーク周りの話はすごそうだけどあまり理解できなくてこのへんの理解は浅いなぁと実感。

Sass/Compass

Sassは最近のRailsを使っている関係で使ってるんですけど、Compassはすごいすごいと聞いていてなにがすごいかわかってなかったのでそこがわかってよかったです。ただ、筆者の人が導入するモチベーションだったCSSスプライトは、今の自分達の開発では今のところ必要ないかな、と感じているのでそれ他に大きなメリットがあるか、ですね。

Sassの落とし穴のところは特に良くて、@mixinや@extendを活用してSassを短く書ければいいだろうと思ってたら、それはアンチパターンで生成されるCSSが長くなってしまってはだめ、ということに気付かされました。注意して使いたいですね。

今後、Rails4で新アプリ作ることになりそうなのでこのタイミングで読んでおいて良かったです。

社内の情報共有・情報発信

クックパッドに入った時に、社内情報発信がなかったのでその文化を作ったという話でした。今の自分の部署は情報発信の文化があるので、その点で何か改善しないといけないことはなさそうなのですが、自分がJOINした時にそこのチームができていないところを改善していくという姿勢は自分も見習って行きたいと思いました。

Boxen

@udzuraさんによる「一歩先ゆくRuby」の今回は、Macの開発環境ツールであるBoxenの記事で、これも気になってたので面白かったですね。 自分は仕事も含めてMacを3台使ってて、DropboxやGitHubを使ってすでに同じような開発環境を作っているので特に導入する必要はないかな、と思っていたのですが、

• Boxenによって既存の環境が壊れることはない
• ただし、一部のアプリケーションについて気をつけないといけない

というかゆいところに手が届く情報が書いてあって、次のMac買うときに備えて入れておいた方がいい気持ちになってきました。homebrewやrbenvに関する情報も詳しく書かれていて良かったです。

Grunt

このツールちょっと使ったことあったもののがよくわかってなかったんですが、js,cssのビルドを楽にするツールなんですかね。 Railsを使っている感じだと、コンパイル周りはRailsビルド時になされて困ったことってないんですが、altjs,やcssを他のフレームワークで触るときに使うべきものなのかな、という印象を持ちました。間違ってたらすみません。

あと、Jenkinsでもできるよなぁ、と思ったんですが、JenkinsはあくまでCIで、開発者がOKと思ってコミットしたものに対してコンパイルする責務で、こっちは開発者が開発時に自分の作業をラクにするために導入するツールなのかなと解釈しました。もちろん、JenkinsにGrunt入れるっていう使い方もあると思います。

Foremanのことも書いてあって、これは同僚が使いこなしているので今度使い方教えてもらおうと思います。

まとめ

というわけで、他の積ん読消化などをしていて10月号にもかかわらず今まで読んでなかったんですが、いい情報がたくさん載ってて良かったです。

WEB+DB PRESS Vol.77

「パーフェクトRuby」読み終えたので感想

8/10（土）に出たRuby本「パーフェクトRuby」を読み終えたので感想です。

全体的な感想

開発環境の作り方やメソッドやクラスの定義方法などの入門的な内容から、メタプログラミングという中級者以上向けの内容が含まれているほか、著者の人たちが実際に開発に使用しているであろう役に立つgemの使い方が書かれてある本です。

入門やメタプログラミングについては他の書籍でもカバーされていますが、こういうgemの情報はなかなかまとまった書籍には情報がないのでありがたいですね。Webでググって出てきた情報やGitHubのREADMEを見て、試してみるというのがデファクトになっているかと思います。WEB+DB PRESSなどには載っていたりすることもありますが、こういうRuby専門書で詳しい解説が日本語で読めるという本は今まで見たことがなかったので、こういう実践的な内容が読める本は素晴らしいと思います。

各パートと自分が学べた点の一部

本の各パートと、自分にとって知らなかったのを理解できてとても良かった！って部分を書いていきます。

Part2 Ruby言語仕様

• Object#freezeでオブジェクトの変更を禁止する。定数などにオススメ(P.137)
• Numberc#step(P.144)
  • times, uptoを使ってたけどこれも状況によって使い分けするとよさそうだと思いました
• Arrayの第二引数に渡した値は同じオブジェクトなのでひとつの要素に破壊的操作をするとすべての要素に影響する。(P.172)
  • 気をつけないとまずい
• Hash#to_aとArray#assoc(P.185)
  • HashからArrayに変えたあと、それにアクセスする方法

Part3 メタプログラミング

• クラス変数とクラスインスタンス変数の違い(P.237)
• Ruby2.0の新機能 Module#prepend(P260)
  • モジュール側でsuperを書いて利用側で実装するという使い方が例を含めて書かれていてよかったです
• Refinements(P.263)
  • これも実例を踏まえてわかりやすく書かれていました
• Module#remove_methodとModule#undef_methodの違い(P.318)

Part4 標準添付ライブラリ

• benchmarkライブラリ(P.387)
  • 実行前と実行後でTime.nowしたものを引いた値を出力するようなことをしてたんですが、こういうものがあるんですね
• gem serverでRDocを参照するためのローカルサーバが立ち上がる(P.432)
• 自分で編集してしまったgemの状態をインストール直後に戻すgem prinstineコマンド(P.435)

Part5 実践プログラミング

• bundle openでgemパッケージがインストールされているディレクトリが開く(P.462)
• binstubs(P.464)
• bundle package(P.468)

特にPart5は

• gemの作り方
• Rakeタスクについて
• よく使われるGemの説明
  • Bundler
  • Capistrano
  • YARD
  • Pry

など、実践的な内容でむちゃくちゃありがたいですね。さっそく職場に持っていって活用しようと思います。

また、最後のアプリケーション開発例も、「RailsでScaffoldで一瞬でアプリが動きます」というよくある内容ではなく、まずはコマンドラインインターフェースのものをgemとしても公開できるように作成し、それからSinatraでWebアプリケーション化するという内容。渋い。そして、仕組みへの理解が深まりますね。特に私が感銘を受けたのはコマンドラインアプリをgemとして公開する用に作るという思想。gem公開まだしたことがなくてしてみたいんですけどアイデアがなくてな～って思ってたんですが、コマンドラインから叩く自分用のツールはいくつか作ったことがあるので、これをちょっといじって公開できるレベルにすればいいんだな、と考えられる用になったのでよかったです。

まとめ

全体的に広い範囲をカバーしていますが、Ruby2.0でのメタプログラミング箇所とgemの作り方や有益なgemの説明のあたりの内容の充実度が素晴らしいと感じました。初学者向けではなく、初学者レベルはある程度こなせるようになった上で、中級者、上級者を目指したい人におすすめの本だと思いました。

パーフェクトRuby (PERFECT SERIES 6)

WEB+DB PRESS PLUS 開発ツール徹底攻略を読んだので感想

最近のモダンな開発ツールについてまとめられたWEB†DB PRESSの開発ツール徹底攻略を読んでみました。

開発ツール徹底攻略 (WEB+DB PRESS plus)

以下のツールについてまとめられています。

• Git
• GitHub
• Jenkins
• Vim
• Emacs
• Linuxの基礎

Vim,Emacs,Linuxはモダンと言うよりは、最近はやりの言語が統合開発環境で作るよりもこういうエディタ+pluginで作ったほうが効率的になっているからふたたび価値が高まっているような感じですね。自分も開発を始めたのがエクリプス全盛期だったので、Ruby書くのにもエクリプス使ってたのですが、Vimに乗り換えてその価値はあったと感じています。というか、最近はあらゆることをVimのキーバインドで編集したくなっています。

というわけでJava以外の言語触るのにエクリプス使っている人は頑張ってVimかEmacsに乗り換えたほうがいいんじゃないでしょうか。

で、本書の感想とか、良かったところとか。

全体

これだけの開発ツールを取り扱っているので、どうしても内容は「広く浅く」になってしまっています。gitやVim,Emacsについては、それ用の専門書がたくさん出ているのでそれを比べると内容は深くないですが、入門用に読むというのはいいと思います。

一冊でこれだけの内容をカバーしている本なので、新入社員や若手が読むとか、会社でエクリプス＋SubversionやVSSが強いられているけど最新の技術にキャッチアップするために読みたい、とかいう用途で読むと凄いお得な本だと思います。

また、Jenkinsについては私の知ってる限りだと日本語の専門書は２冊、かな？GitHubに至っては本がないので、これらの情報を書籍として扱っている本としては貴重だと思います。なのでこの分野についての情報がほしい人には良いと思います。

git編

この前git本再読したところなのでほとんど新発見はなかったですよ―、と見せかけて、

• git add -A
• git add -p

を覚えたりした。 特にgit add -pやばいでしょ、便利すぎでしょ。なにこれ。 これを知らずに30年以上生きてきた自分が情弱過ぎてつらい。30年前だとgitまだねえけど。

GitHub編

みんな大好きOctocat。 意外と使いこなしてたみたいで新発見それほどなかった！やはり業務で利用しているというのはでかい。

書籍の内容としてはほとんどのメニューについてカバーされて書いているので、gitの保存先としてしか使ってないとか、アカウント取ったものの使い方よくわからないって人には非常に良い内容が書かれていると思います。

面白かった内容として、以下のが挙げられます。

• 開発の途中で論議するための Pull Request(p.71)

途中の状態でコミットして、みんなから意見をもらいながらコミットを重ねていってブランチを育てていって、最後にマージする、というやり方。この発想はなかったので目からうろこでしたね。pull req,つまりコードレビューはどうしてもゲート的な審査っぽい感じになって、よりよいコードを作るための場なんだ、と思ってても自分の中でそのイメージを払拭できていないことに気付かされました。このやり方は本当にコードをみんなで育てていく感じでいいですね。技術的課題の大きい箇所の修正で活用できそうに思えました。

• pull reqのブランチをマージして、pushしたらpull reqが閉じられる(p.76)

まじかよ！( ﾟдﾟ )

• Travis CI と Coder wall

会社では使えないので、自分プロジェクトで試してみようと思いました。

Jenkins編

会社ですでに構築済みのを使わせてもらってて、割と直感的に使えて良いツールです。 で、今後使えそうなだな、と思ったのが

• fork/join
• サブルーチン

です。 今、処理の重いテストを幾つかに分割して実行、みたいなのを個別にジョブ作って実行してやってるのですが、これらの機能を使えばもっと楽に実現できそうな気がしました。

• Sauce OnDemand

Jenkinsとは関係なく、Seleniumテストを走らせてくれるクラウドサービスらしいです。同僚が以前、話していたような。 2週間ほど前、Seleniumでつらい思いをしたのでこういうのも調べてみるといいのかな、と思いました。

Vim編

初心者によくある間違いは次のような意識で操作を行うことです。

テキスト入力を行うためにiでインサートモードに「移行」し、でノーマルモードに「移行」する(p.131)

す、すみません(；´Д｀)

• vimrcのリロードと落とし穴(p140-141)

リロード自体知らなくて再立ち上げしてました。リロードできると便利そうですな。

• 意識すべきこと、に関する記述(p.154)
  • 不便だと感じる点や繰り返し行なっている定型操作がないかどうか意識すること
  • そのような点に気づいたらすぐにメモを取ること。メモを取らなければ必ず忘れてしまう
  • 時間ができたときにメモを見返してカスタマイズを行うこと
  • カスタマイズの結果や過程は公開すること

Vimに限らず、あらゆることに当てはまるなぁと思いました。例えばRubyのGemとかもこういうところから便利なものが作れそうな気がします。とりあえずいろいろ使ってて不便だな、と感じたら付箋紙にメモしていくように心がけます。

Emacs編

Vimmerなので読んでませんすみません。

Linux編

Linux、超情弱なので、

• tail head(p.154)

すら使ってませんでしたよ・・・。テキスト読むときcatとviとlessしかつかってませんでしたorx

• パイプ、リダイレクト

これもよくわかってなかったのでgrepと組み合わせるといろいろ捗るってことがわかって良かったです。ログ解析とかするときにこういうコマンドがすらすら出てくるかが作業効率に響いてくると思うのでがんばります。