<div> <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa fa-spin">く <span class="fa fa-spin">る <span class="fa

という話を、社内のインフラチーム向けにしました。 Webオペレーションエンジニアの大体のイメージについてはこちらを御覧ください。書評なのですが、とてもイメージしやすいエントリになっていると思います。 blog.riywo.com スライドの中でも一応定義していて、３行にまとめると Webサービスの運用 OS・ミドルウェアの運用 運用技術の調査・開発 を主な業務として行っているエンジニアを指すことにします。 入社して間もないので、僕の人格の好き嫌いや人間関係みたいなものがまだできていない頃の発表ということで、素直に内容を聞くことができる、という意味でいい機会だったと思います。 この内容は、社内だけでなく社外のWebオペレーションエンジニアや、所謂、インフラエンジニアと呼ばれている人でも同じような悩みを抱えている人がいるかもしれないと思っていて、内容的にも公開しても良い話なので公開しようと思い

技術部の鈴木 (id:eagletmt) です。 クックパッドでは一部の Web アプリケーションサーバで Docker が使われており、今回はそのデプロイ方法について紹介します。 Docker で Web アプリケーションをデプロイするときには、まだまだベストプラクティスがある状況ではありません。 たとえば、どのように無停止でデプロイするか、どのようにコンテナと通信するかといった問題があります。 最初に Apache Mesos と Marathon などのツールを検証しましたが、クックパッドの環境において使いやすそうなものはなく、最終的に自前でデプロイのしくみを作ることにしました。 しかし Docker 周辺のツールは様々な新しいものが出てきている最中です。 今はまだベストなものが無いけれども、近いうちによりよいものが出てくるかもしれません。 そのため、できるだけ単純なしくみにしておく

esa.ioは組織内のドキュメントを管理するWebサービスで、まずは小さくはじめて何度も更新して大きくし、大きくなったら整理しましょうという考えになっています。これはとても分かりやすく面白いサービスです。 そんなesa.ioの専用クライアントソフトウェアがkotoriです。esa.ioに行くことなくドキュメントを作成したり、アップデートができます。 kotoriの使い方 kotoriを立ち上げた画面です。まずログインが求められます。 最初の画面です。esa.ioの説明が書かれています。 編集画面。予めテンプレートも用意されていますのですぐにはじめられます。 プレビュー機能もあります。GitHub FlavoredなMarkdown記法が使えます。 バージョン管理もされています。どんどんアップデートしていきましょう。 kotoriはRubyMotionで作られている点も興味深いです。esa.

渋谷のセルリアンタワーGMO Yoursにて第1回ペパボテックカンファレンスが開催されたので、参加レポートです。 開会の辞 なぜ、開いたか あんちぽくんさんより 色んな会社が自社のテックカンファレンスをやっているので、やってみたかった 領域が広い　→　普段やっていることを話せば面白いかも これからのペパボの技術 by あんちぽくんさん speakerdeck.com ペパボがなにを考え思いエンジニアリングしているのか これからどうエンジニアリングするのかを話していく これまでやってきたこと 技術基盤の改善 基本事業部制で縦割りだったのを技術基盤チームを作ったことで横につなげた 技術的な改善&エンジニアが言うことを聞き入れてくれる組織作り CTOとは 経営をすることのみ それ以外はない 経営の中で技術を担う 今後の技術的展望 １.マイクロサービシーズ化 色んな言語で細分化して小回りがきくよう

命名の話をしました．1時間位でなんとか間に合わせで書いた資料です． よろしくお願いします． 命名の話 from moznion www.slideshare.net あと，例えばメソッド名で"get"と"retrieve"と"fetch"をどう使い分けるか，みたいな話題が出て， 僕あたりは getは単純なゲッター的なものに使う retrieve は DB にアクセスして値を取ってくるものに使う fetch は何らかごちゃごちゃ処理をして (API 叩くとか) 所望の値を取ってくるものに使う という風な使い分けの話をしました．そういったルールが各々の人の中にはあります． ここらへんのルールというのは個人が好き放題やっても無力なので (というかノイズたりえるので) プロジェクトの人間たちが話し合ってすり合わせる必要があります． とは言え，いちいち些細な命名の問題について話し合っていくのはだるい