先輩から教えてもらったコードレビューLT大会にお呼ばれしました。 内容は以前ブログにしたためた「コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと」についてです☺ http://b.hatena.ne.jp/entry/yutokyokutyo.hatenablog.com/entry…
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
Re:VIEWとDockerとCircleCIで原稿を継続的インテグレーション - orangain flavor
Re:VIEW で執筆する原稿を継続的インテグレーションしたかったので、以下の図のような仕組みを作りました。 ローカル執筆環境の前提条件 Docker 1.3以降がインストールされている Re:VIEW形式の原稿のフォルダがある Re:VIEWやLaTeXはDockerイメージのものを使うので、インストール不要です。 私はMac OS X 10.9とBoot2docker 1.4.1で動かしましたが、WindowsやLinuxでも動くのではないかと思います。 Re:VIEWをDockerで動かす vvakameさんがDocker Hubにイメージを公開してくれていますので、これを使います。 https://registry.hub.docker.com/u/vvakame/review/ dockerコマンドさえ使える状態であれば、以下のようにしてサンプル書籍 をコンパイルしてbook.p
Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい
来年は、インプットあたりのアウトプットの増加を目指しています。具体的なアウトプットとしては、ブログを書くこともその1つですし、公開・非公開を問わずに効率的にドキュメントを書いていくこともあります。その中で効率的にドキュメントを書くには、バージョン管理を含めドキュメントを管理する仕組みが必須だと思います。以前、原稿を書いていた時は、Git+MS Wordで書いていました。版管理出来るという点では良いのですが、Wordということで執筆出来る端末も限定され、またフォーマット変更もしづらいので改善を考えていました。 そんな中で、IT系の物書きの人たちの間でReVIEW良いよという話を何度も聞いたので試してみようと思いました。一方で、記述のデファクトは今後はMarkDown基本になると思うのでそちらもマスターしたいと考えています。Twitterで何気なく呟いたら、@masawadaさんにmd2rev
ReVIEW + Jenkinsでドキュメントを常時ビルドする
ReVIEWはマークアップ言語でソースを記述することで、html形式やPDF形式の綺麗な体裁の文書を作れるオープンソースのツールです。入手はhttp://github.com/kmuto/review から可能です。例えば = 章 == 節 === 項 * 箇条書き * 箇条書き のような書き方をするとhtmlであれば、それぞれh1〜h3に変換されたり、ulに変換されたりします。PDFの場合は予め規定された体裁に変換されます。 今回は、Windows Azure上の仮想マシン(Ubuntu12LTS)上で、このドキュメントを常時ビルドする方法を紹介します。 ReVIEWのインストールReVIEWは動作にrubyが必要です。また最新版はgithubにて提供されていますので、gitを導入しておきます。 sudo su apt-get install ruby apt-get install g
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
