クリアコードの開発の様子をフォローしやすくしました - 2013-07-11 - ククログ
クリアコードでは、社名からわかる通り、日頃からクリアなコードを書くべく日々コードと向き合っています。そのために「みんながみんなのコードを読む文化」を維持しています。 クリアコードでは自分たちがクリアなコードを書くだけではなく、自分たち以外の人たちがクリアなコードを書くことを支援したいと考えています。そのために、他社の開発チームに「みんながみんなのコードを読む文化」を根付かせる支援をするコミットへのコメントサービスも提供しています（導入事例）。また、クリアなコードを書くために実践しているノウハウを文書化して公開しています。例えば、以下のようなノウハウです。 よいコードの書き方に関して 名前のつけ方 - ククログ(2012-06-28) ifとreturnの使い方 - ククログ(2012-03-28) クリアなコードの作り方: 余計なことを書かない - ククログ(2012-05-21) デバッ
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
Gitで不適切なコミットメッセージを削除した公開リポジトリを作る - 2012-01-05 - ククログ
分散バージョン管理システムのGitには様々なサブコマンドがありますが、その中の1つである git filter-branch を使用すると、過去のコミットを完全に無かった事にしてしまうなどの強力なコミット履歴の編集が可能となります。大きなリポジトリの特定のディレクトリ以下の内容をコミット履歴付きで別の小さなリポジトリとして取り出したり、ファイルの中に書かれていた生のパスワードを履歴の中から消去したり、というのはよく紹介される例です。 このエントリでは別の例として、コミットメッセージだけを後からまとめて修正する手順をご紹介しましょう。 元々非公開なプロジェクトとして開発を進めていたものを、公開リポジトリに移動したいとなると、やはり機密情報は完全に取り除いておく必要があります。リポジトリに格納されているファイルそのものの内容の編集方法については上記の例で解説されていますが、それ以外の場合として
デバッグ力: よく知らないプログラムの直し方 - 2011-12-06 - ククログ
クリアコードではMozilla製品やRuby関連の開発だけではなく、広くフリーソフトウェアのサポートもしています。もちろん、サポート対象のソフトウェアの多くは私達が開発したものではありません。しかし、それらのソフトウェアに問題があった場合は調査し、必要であれば修正しています。 このようなサポートが提供できるのは、もともと、私達がフリーソフトウェアを利用したり開発したりしているときに日常的に問題の調査・修正をしていたからです。ソフトウェアを利用していると、問題に遭遇することはよくあることです。そのソフトウェアがフリーソフトウェアの場合は、開発者に問題を報告し、可能ならパッチを添えます。このとき、そのソフトウェアの内容を完全に把握していることはほとんどありません。しかし、それでも修正することができます。 それはどうしてでしょうか？今まではどのようにやっているのかを自分達でもうまく説明できなかっ
いらないキャッシュを消すとRubyスクリプトが速くなる - 2011-11-24 - ククログ
いらないキャッシュを消すことでRubyスクリプトが倍速で動作するようになった話です。 先日、るりまサーチをRackspaceのクラウドサーバー（メモリ1GB）からさくらのVPS 512（メモリ512MB）に移行しました。理由はRackspaceのサーバーが遠くにあるのでレスポンスがもっさりするからです。最速検索がウリなのにこれでは遅いのでないかと誤解されてしまいます。さくらのVPSにしたら近くにあるためサクサクとレスポンスが返ってくるようになりました。しかも、リソース（主にメモリ量）はスケールダウンしているのにです。 るりまサーチはバックエンドの全文検索エンジンgroongaが高速に動作するのとそれほどアクセスがない（！）ため、CPUやI/Oがネックになることはありません。それよりも、ほとんどメモリを搭載していないマシンで動かしているため、ボトルネックになるとすればメモリです。実メモリ以上
どうして開発者がドキュメントを書くべきか - 2011-10-27 - ククログ
オフィス文書形式が要求されるようなドキュメントではなくて、自分が開発したライブラリのドキュメント（リファレンスマニュアルやチュートリアルなどライブラリのユーザーが読むためのドキュメント）の話です。以下の「ドキュメント」もそのような意味で使っています。 使いやすいライブラリを開発したかったらプログラムだけではなくドキュメントも書くべきです。 なぜドキュメントを書くか ドキュメントを書く習慣があるかどうかは開発者によってあったりなかったりです。使っているプログラミング言語に相関がある気もしますし、リリースするかどうかに相関がある気もします。理由はいろいろあるでしょうが、ドキュメントを書く習慣のない開発者の方が多いでしょう。 書かない理由はこんな感じでしょうか。 面倒。 自分しか使わないからいらない。 どのように書けばよいかわからない。（どのツールを使えばよいかわからない。） 一方、書く理由はこ
おすすめzsh設定 - 2011-09-05 - ククログ
他の人がzshを使っているのを見ていると、「もっと便利に使えるのに」と、もやっとしたり、「え、その便利な機能ってなに？」と、発見があったりします。だれかに「この設定をすると便利ですよ」と話しやすくするために、今のzshのおすすめ設定をここに記しておきます。 もし、Emacsも使っている場合はおすすめEmacs設定もどうぞ。 ディレクトリ構成 長年漬け込んできたzshの設定がそこそこの量になっているので、以下のようなディレクトリ構成にして分類しています。主に、zsh標準機能の設定と追加パッケージの設定を分けるためにこうしています。 ~ ├── .zshrc # シェルを起動する毎に読み込まれる。 │ # ~/.zsh.d/zshrcを読み込んで │ # 標準機能の追加設定を行う。 ├── .zshenv # ログイン時に一度だけ読み込まれる。 │ # ~/.zsh.d/zshenvを読み込ん
もっと知られてもいい人たち - 2011-02-03 - ククログ
るりまサーチという最近の検索技術を使ってRubyのリファレンスマニュアルを検索するWebアプリケーションがあります。表向きの存在理由は「手早く簡単にドキュメントを検索できるシステムを提供することで、Rubyユーザが楽しくプログラミングすることを妨げないようにする」ですが、実はもう一つ理由があります。それは、「Rubyのリファレンスマニュアルをよいものにしている人たちがいることに気づいてもらう」というものです。 ここを読んでいる人の中に、他の人が実装したプログラミング言語やライブラリのドキュメントを書いて、メンテナンスしている（アップデートに追従するなど）人がどれだけいるのかわかりませんが、この作業はとても大変で根気のいる作業です。しかも、その成果をなかなか実感してもらえません。Ruby本体に新しい機能（例えば、「バイト長」ではなく「文字長」を数える機能）が入ったら、プログラムが簡潔になるな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
