2016/12/27 更新 Googleなどの大手IT企業がうるう秒対策済のNTPサーバが公開したため、これを利用する内容などを以下にまとめました。 元旦に実施される うるう秒の対策 まとめ 2016/07/08 更新 2017/1/1に閏秒の実施が決定されました。対応はこの記事のとおりで問題なさそうです。 2015/06/24 情報追加(2015/06/29 更新) 下記の対応に関わるntpdの比較的新しいバージョンにSLEWモードで動作していても、うるう秒が挿入されるバグが発見されました。[redhat] これによりntp-4.2.8p3-RC1以降のバージョンでないとSLEWモードで動作していてもうるう秒が挿入されます。RedHatはntp-4.2.6p5-3.el6_6という対応済みのバージョンを提供しています。Ubuntuでは今日現在12.04LTS, 14.04LTSの２バージ
Pythonで書かれたレビューツールです。VMware社内で利用されていることで有名なツールです。 プレコミットレビューという概念のレビューツールです。つまり、コミット前にレビューをするという事が前提になっているツールです。よって、結果的に差分を重点的に確認していくツールのつくりになっています。 rietveld rietveld – Code Review, hosted on Google App Engine – Google Project Hosting Google社内で使われているコードレビューツールである「Mondrian」のオープンソース版です。基本的にGoogle App Engineで動くことが前提になっています。 GAEの上のコードのデータを置くということがオトナの事情的に難しいかもしれませんが、検討してみてください。 Phabricator Phabricator
なぜ今頃ログまわりの話しが注目されはじめたのか？ いにしえの昔、ログから可視化といえばAWstatsやWebalizerといったApacheのログに特化したレポートツールぐらいでした。やがてGoogle Analyticsのようなサービスの登場によって、こういったツールは駆逐されていきます。 ここにあげたのはApacheという代表的なhttpdサーバのログに特化したツールであり、もっとシステムに特化した柔軟性のあるログを集計してレポートするという物ではありません。たとえば、本日に売上げのあった商品一覧を把握したければ、DBに格納されている情報をバッチ処理で集計して、レポートメールを送る。というような専用のコードを書いたりして対応していたのではないでしょうか。 可視化したいデータが発生した時点から可視化するまでの枠組みになる代表的なツールがなかったのです。(ログ収集についてはscribedと
KPTとは？ まず、KPTの読み方ですが「けーぴーてぃー」とは読まず、「けぷと」と読むのが正しいようです。このやり方を指してKPT法（けぷとほう）なんて言い方も見かけます。プロジェクトや日々の業務のふりかえりをするためのツールとして使われることが多いです。 やり方 Keep（いいところ）、Problem（悪いところ）、Try（改善のためにやること）をチームで共有し、改善するためのきっかけを作る手法です。実際にはそれぞれを付箋紙に書き出して、チームで共有し、改善の行動となるキッカケをつくります。これを継続的におこなうことによりPCDAサイクルに似た日々の改善をおこなっていきます。特にソフトウェア開発のアジャイル開発手法では日常的によく使われる手法です。 KPTでチームの未来が見える 私の経験でもKPTを見れば、チームが良い方向に進んでいくかがわかります。それは彼らの仕事が、彼らの手によって改
hubコマンドは、MacやLinuxのターミナルからGitHubの操作をおこなうためのコマンドです。通常はブラウザを通しておこなっているような操作をCLIでおこなうことができます。 これがURLを渡すだけで、利用シーンがあるので、紹介します。 インストール 公式サイトを確認する限りgemでインストールするのは、動作が遅くなるので非推奨とのこと。よって、Mac環境はHomebrewかMacPortsで入れた方が良い。 gitコマンドのエイリアスとしてhubを設定してしまうことが推奨されてますが、あえて今回はしません。 MacPortsの場合 $ sudo port install hub Homebrewの場合 $ brew install hub 動作確認 $ hub --version git version 1.7.12.4 hub version 1.10.2 GitHubへの初回ア
Rubyの自動テストといったらRSpec もう、当たり前すぎて、多くを語る必要がないと思うが、今Rubyで自動テスト書くならRSpecできまり。 http://rspec.info/ エンドツーエンドのテストはCapybara いわゆるブラウザ操作からの自動テストツールである。標準でSeleniumをサポートしていてビックリ。 手元のMac環境でFirefoxやChromeを勝手に動かしてテストしてくれました。すごいですねーこれ。 https://github.com/jnicklas/capybara fixtureを書く必要はもうない。factory_girlをつかえ！ Fixture Replacementってジャンルのツール。大量のfixtureを書くのを卒業させてくれるのです。 あぁ、こうやってつかうのね。ってのが参考になる。この手のツールはRubyは充実していて羨ましい。 ht
１．テストやデバッグに使う時間を削減して、プロダクトコードの品質をあげる 単体・結合・統合テストは全体の8〜25%が費やされるべきであるといわれています。ですが、デバッグは開発の50%におよぶ場合があると言われています。これは、テストには本来多くの時間を割くべきであるが、デバッグが膨大な時間に及ぶことが事実としてあるということです。 プログラミングについてあまり知られていない７つのことより １．スキルのレベルにかかわらず、プログラマーは全時間のおよそ１０～２０％をコードを書くのにあてており、たいていのプログラマーは完成品ができるまで一日あたりおよそ１０～１２行のコードを書いています。優秀なプログラマーは残りの９０％のうち大部分を、考えること・調べること・最高の設計を見つけるための検証作業に費やします。ダメなプログラマーは残りの９０％のうち大部分を、やみくもに変更と検証を繰り返すようなデバッ
オブジェクト指向エクササイズ 下記のルールで、1000行程度のソフトウェアを書いてください。 1. 1つのメソッドにつきインデントは1段階までにすること 2. else句を使用しないこと 3. すべてのプリミティブ型と文字列型をラップすること 4. 1行につきドットは1つまでにすること 5. 名前を省略しないこと 6. すべてのエンティティを小さくすること 7. 1つのクラスにつきインスタンス変数は2つまでにすること 8. ファーストクラスコレクションを使用すること 9. Getter、Setter、プロパティを使用しないこと というルールが適応できない場合は優先すべきルールを選択し、どのルールを適応するのか判断して欲しいとの旨が記載されています。 9つのうち 7つがデータのカプセル化 1つポリモフィズの適切な利用（else句をつかわない） 1つが明確でわかりやすい命名標準 オブジェクト指
TDDがアジャイル開発では前提 ここまでに説明した、アジャイル開発を支えるエンジニアリングのプラクティスをまとめておこう。 ユニットテスト リファクタリング テスト駆動開発（TDD） 継続的インテグレーション これら4つを実践することなしにアジャイル開発を成功させることはかなり難しい。たちまち「書いて直す」だけの日々に逆戻りすることになるだろう。 アジャイルサムライでは成功させることはかなり難しいと甘い表現をされているが、ほぼ不可能であるといえる。 プラクティスとは習慣である。つまり、やることが当たり前なのである。やるべきことなのです。 テスト駆動開発を推し進めれば、必然とここにあげられている4つのプラクティスを実践することになる。 注意しなければいけないことは、テスト駆動開発をおこなうこと事態ががアジャイルソフトウェア開発ではありません。 アジャイルにソフトウェアを開発するためにエンジニ
心底、プログラマとして生きていくのが幸せなんだなと思える人に出会ったことのある@HIROCASTERでございませう。 プログラミングが上達するベストプラクティスってあるんでしょうか？ 大学でコンピュータ教えている教授なんかは、そのあたり教えてくれるんでしょうか？ あなたの先輩は教えてくれましたか？ 昔ながらの職人がいう、見て、まねて、盗め。ですかね？ 僕の経験で、いくつか書いてみました。 毎日コードを書く とにかく毎日コードを書いている。 息を吸うように、歯磨きををするように、顔を洗うように、食事を取るように毎日コードを書いている。 テストコードも書く 動くソフトウェア側のコードだけでなく、テストコードも書いている。 必然と設計も考える癖が付くわけで…。 ソフトウェア全体を仕上げるまで書く 例えば、小さなメソッドだけでなく、クラス全体を。 ソフトウェアとして動作するまで全体を。 全体を仕上
「ソフトウェアのプロになるには本書が必要だ！」と、ボブおじさんがおっしゃっております。 このボブおじさんは、あの有名なアジャイルマニフェストにも名前を連ねているRobert C. Martinです。 プロとしての最低限必要な知識、姿勢、規律など、教育を受けたり学んだことがあるプログラマはあなたの現場に何人ぐらいいるでしょうか？ 今こそ、本書を取って、プロとしての道を歩み始めて欲しい。（amazonでずっと売りきれだったけど、やっと入荷したようだ。すぐに売り切れそうではあるが…） プログラミングの練習 僕はプログラミングの練習というのを意識的にあまりやったことが無い。日本だとTDD Boot Campなどでおこなわれる小さなテーマでプログラミングをおこなうことである。本書の6章に練習について書いてる。 個人的にはRubyKaigiで、ペアプロした外人が、これはToys Programming
288ページという少ないページ数の中に、ほとんどの見開きの中に図をいれて、アジャイル開発のすべてがザックリ凝縮された書籍です。思わず「こういうのが欲しかったんだ！」と声に出してしまう内容に仕上がっています。この業界の新人に必ず読ませたいバイブルです。 今の仕事やプロジェクトに問題がある。順調でない。解決策の糸口が欲しい。 アジャイル開発に興味がある。はじめてみたい。どういったものか知りたい。 もっと価値のあるソフトウェアを顧客に提供したい。 ソフトウェア開発に携わるすべての人（プログラマ以外にも）にオススメします。東京に住んでいる人はよかったら読書会に参加してください。 良いコードを書く技術 -読みやすく保守しやすいプログラミング作法 (WEB+DB PRESS plus) 今年、プログラミングを本格的にはじめた人や、会社に入って多人数での開発をはじめてやる人に読んでもらいたい書籍。自分一
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く