株式会社クリアコード > ククログ

ククログ

«2013-12-26 最新 メタプログラミングをして割に合うかの判断基準:処理を1箇所に局所化できるか»
タグ:

2014年にやりたいことと2013年のまとめ

年の初めなので、2014年にやりたいことと2013年のまとめを書きます。

2014年にやりたいこと

まず、今年やりたいことです。

設立当時からクリアコードが大事にしていることは次の2つです。

  • 継続的にフリーソフトウェアの考えを実践すること
  • ソフトウェアを継続して改良してくいくためにクリアなコードを書くこと

これらを実現するために今年は次のことに力を入れます。

  • フリーソフトウェアの考えを実践している人・実践したい人の採用
  • コミットへのコメントサービスの改良

それぞれ、もう少し説明します。

フリーソフトウェアの考えを実践している人・実践したい人の採用

まず採用についてです。

フリーソフトウェアの考えを実践している人・実践したい人を採用したいです。これは、「働く人が実践したくてそれを会社が支援する」という仕事の進め方を強化したいからです。

これを実現するためには、クリアコードに入ってからフリーソフトウェアに興味を持ったというケースよりも、フリーソフトウェアに興味があるのでクリアコードに入ったというケースの方が自然だと考えました。前者の場合は「実践することを会社が働く人に促す」仕事の進め方になってしまうでしょう。

そのため、すでに実践している人あるいは実践したい人を採用したいという考えになりました。

もう少し背景を説明します。

これまでの応募者や外の人から話を聞くと、クリアコードでのイメージは次のようなものでした。

  • Rubyをやってそう
  • Mozillaをやってそう
  • キレイなコードを書いていそう

一方、「フリーソフトウェアの考えを実践していそう」というイメージはほとんどありませんでした。

イメージではなく実際のクリアコードは、フリーソフトウェアの考えを実践するためにイメージ通りの技術を使っています。Rubyを例にすると、Rubyで開発し、成果物を自由に使えるソフトウェアとしてリリースします。

クリアコードは自社のサービスを提供することで対価を得るのではなく、受託開発で対価を得ています。そのため、成果物を自由に使えるソフトウェアとしてリリースするためにはお客さんと相談する必要があります。相談するときは、お客さんにとってのメリット・デメリットを伝えます。特にデメリットは正直に伝えます。その上で判断を仰ぎます。部分的な場合もありますが、多くの場合は賛成してくれます。クリアコードの仕事は開発して対価を得るだけでなく、成果物を自由に使えるようにするところまで含んでいます。

Rubyを使いたい*1という気持ちはあるものの、フリーソフトウェアに関しては特に思うところがない人にとっては、成果物を自由に使えるようにするという話は面倒なことに感じるでしょう。この場合、クリアコードでの仕事は面倒なことがついてまわる仕事という扱いになります。それは働く人にとってもクリアコードにとってもつらいことです。

成果物を自由に使えるようにすることをやりたいことと感じる人であれば、つらい思いをせず、むしろ積極的に行動できるはずです。そのため、フリーソフトウェアの考えを実践している人・実践したい人を採用したいです。

コミットへのコメントサービスの改良

次にコミットへのコメントサービスについてです。

クリアコードとしては、このサービス自体はよいサービスであり、続けていきたいサービスです。ただし、今のままでよいものではなく、もっとよくしていけるサービスであると認識しています。2014年は、このサービスをよくして、それを実際に提供したいです。

このサービスは、開発チームが「よいコードが当たり前な文化」になるために「みんながみんなのコードを読む」文化づくりを支援するサービスです。それを支援するためにコミットにコメントするという「手段」を使います。そのため「コミットへのコメントサービス」という名前になっています。

実際にサービスを提供したところ、コミットにコメントすること以外にも「みんながみんなのコードを読む」文化づくりを支援するためにできることがいくつもあることがわかりました。それらのフィードバックを反映し、「みんながみんなのコードを読む」文化づくりをよりうまく支援できるようにこのサービスを改良し、実際に改良したサービスを提供します。

近いうちに詳細を発表する予定です。

2014年にやりたいことのまとめ

2014年にやりたいこととして次の2つのことに力をいれたいということを説明しました。

  • フリーソフトウェアの考えを実践している人・実践したい人の採用
  • コミットへのコメントサービスの改良

2013年のまとめ

それでは、2013年のことを月ごとにふりかえります。

1月

設計判断事例の紹介:E4Xの事実上の廃止を受けての、UxUの開発方針の検討では、ふだんあまり言葉にしない、どのように設計判断をしているかということを文章にまとめました。なんとなく決めているようにみえてもいろいろ考えているものなのです。

Ruby用単体テストフレームワークtest-unitでのデータ駆動テストの紹介では、test-unitでのデータ駆動テスト機能の使い方について紹介しました。使いすぎると逆にテストをメンテナンスしづらくなりますが、適切な分量で使えばメンテナンスしやすいテストになるので活用してください。

社宅制度による社会保険料と所得税の削減はクリアコードのお金関係のことの紹介です。

2月

クリアコードのサポートサービスはクリアコードがサポートサービスをどのように提供しているかを説明しています。仕事の仕方を説明している珍しい記事です。回答の書き方の部分を、機会があれば回答の書き方(相手に伝える文書の書き方)についてもっと詳しく説明したいところです。

インターン募集を開始しました。その後、2回インターンシップを実施しました。

るびま0041号の「Rubyコードの感想戦」のお知らせでは、咳さんから文通の返事があったことをお知らせしました。

クリアなコードに囲まれて - クリアコードでの二年間は、クリアコードでアルバイトをしていたおやまださんに、クリアコードがどう見えていたかを書いてもらったものです。

3月

Developer Migration 2013: 「開発者は仕事でリーダブルなコードを書けるのか?」 #devmiは今年最初の発表です。SIerの人向けに話すこともパネルディスカッションも初めてで、発表した側としては得るものがたくさんあったよい機会でした。

ぐんまRuby会議01: 「プログラマー」 #gurubyは今年2回目の発表です。とてもよい雰囲気のRuby会議だった印象と、リベンジしたいような悔しさと、しばらく自重したくなる挫折感が相まって、とても突き刺さるRuby会議でした。

Mac OS XのCocoa版GTK+で日本語入力を行うためのgtkimmodule(GtkIMCocoa)の開発は、OS X上でのGTK+の日本語入力まわりを改善する取り組みです。この後も取り組みを継続して、途中経過を報告しています。

日本OSS奨励賞受賞!しました。数年前から関わっているGroongaの開発チームの一員としての受賞です。受賞者発表ページの「肉の日リリース」の解説がとても詳細だったことが印象的でした。

Sylpheedのプラグインの作り方は貴重な情報です。これほど詳細にSylpheedのプラグインの作り方を解説した文書は他にありません。

4月

Rubyで定義したメソッドの引数にYARD用のドキュメントを書く方法Rubyで定義したメソッドに戻り値のYARD用ドキュメントを書く方法はYARDの使い方をまとめるシリーズの記事です。

Fedoraプロジェクトで新規パッケージをリリースする方法も貴重な資料です。実際にFedoraプロジェクトで新規パッケージをリリースした経験を元にまとめたものです。リリースするまでの作業を時系列でまとめているので流れもわかります。日本語での情報としてここまでまとまっているものは他にないでしょう。

わかりやすいコミットメッセージの書き方は久しぶりにコミットメッセージの書き方をまとめたものです。これを実践することでコミットメッセージがグッとわかりやすくなります。コミットメッセージを書くことに慣れてきたらステップアップのために実践してみてください。なお、これが2013年で一番反応が多かった記事です。

5月

GDBでデバッグするなら-g3オプションはコミットへのコメントサービスを実施しているときのやりとりで出てきた話題をまとめたものです。

働く環境としてのクリアコード(福利厚生編)はインターンとパッチ採用の問い合わせがないのはクリアコードのことをわからないからではないか、と予想し、その状態を解消しようとしたものです。その後、インターンにもパッチ採用にも問い合わせはあったのですが、それまで問い合わせがなかったのはこれが原因ではなかったようです。

GtkIMCocoaの動作状況はこの頃のOS X上でのGTK+の日本語入力周りの話です。前回の記事への反応があったことからXamarin Studioのことを知りました。

コミットへのコメントサービス導入事例のご紹介はミラクル・リナックスさんに導入した事例を紹介しています。現時点でも導入実績はこの1件なのですが、今年は前述のような改良をしながら新しく導入したいです。

RubyKaigi 2013の予告:ステッカー・チラシの配布とRubyHirobaでの企画案と発表内容 #rubykaigiでは、RubyKaigi 2013で発表した「Be a library developer!」の内容を説明しています。RubyKaigi 2013ではまっとうに発表できたので、ぐんまRuby会議01での挫折感を解消することができました。

6月

RubyKaigi 2013にシルバースポンサーとして参加したまとめ #rubykaigiはスポンサー視点でのRubyKaigi 2013の成果をまとめたものです。RubyKaigi 2013きっかけでインターンの応募があったことは特筆すべきことです。RubyKaigiは(うまく活用できれば)宣伝効果があるのです。

クリアコードの1日は、あるクリアコード社員の1日の仕事の流れを説明したものです。なお、この記事の中で触れられている「向日葵」は今は閉店しています。

クリアコードがインターンシップを実施する理由は、インターン候補の人に説明する中で、なぜクリアコードはインターンシップをするのか、ということを言葉で説明できるようになったのでそれをまとめたものです。

問題の原因調査のためのログ収集のセオリーはデバッグの仕方の1つであるログを利用する方法を説明しています。このあたりを論理的に進めることができれば、原因判明までの時間を短くできるので、とても大事な考え方です。

7月

Mac OS X版GTK+における日本語入力対応の近況はこの頃の日本語入力周りの状況報告です。別の実装がGTK+に取り込まれたのでGTK+の標準機能で日本語入力できるようになっています。ただ、いくつか問題が残っていることもわかりました。

クリアコードの開発の様子をフォローしやすくしましたはクリアコードの開発やインターンシップの様子などを誰でも参照できるようにした、というお知らせです。

Fedoraプロジェクトでパッケージを更新するにはは新規パッケージを更新した経験を元に日本語で説明した貴重な資料です。

クリアコードのフリーソフトウェアビジネスはクリアコードがこの7年どうやってお金を稼いできたかを説明しています。

milter manager 2.0.0 リリースは2年ぶりのmilter managerのメジャーリリースのお知らせです。ここで紹介しているtest-mailsプロジェクトは2014年も積極的に取り組んでいく予定のプロジェクトです。

8月

インターンシップで学んだこと1:コメントを書きたくなるときはコードを見直す機会は6月中旬から7月末まで実施したインターンシップで学んだことを文章としてまとめたものです。学んだことはたくさんあり、この後もいくつかまとめていますが、まだまとめられていないことが残っています。

インターンシップで学んだこと2:1人で開発しているときはていねいに開発を進めるはコミットに残らないちょっとした開発テクニックをまとめたものです。

インターンシップで学んだこと3:テストを整理する方法はメンテナンス可能なテストの重要性とその書き方をまとめたものです。

9月

インターンシップで学んだこと4:何をテストするかは、テストを書くときは何に注目しているかを考えると必要最小限のテストを書くことができるのではないか、という話です。

Autotools事始めは今でも広く使われているビルドツールであるAutotoolsの概要について説明したものです。

Rubyで定義したメソッドの使用例をYARD用のドキュメントとして書く方法は久しぶりのYARDの使い方の説明です。おそらく、これが最後になるでしょう。

インターンの作業を進めやすくするための工夫は9月に実施したインターンシップで発生した問題点とそれを解決するために行ったことをまとめたものです。

10月

現状共有の会で進行役をするとき気をつけていることはうまくまとめきれなかった記事です。

Windowsの32bit/64bit版Ruby用バイナリ入りgemをDebian GNU/Linux上で作る方法はRubyの拡張ライブラリー作者には便利な情報です。

消費税率引き上げへの対応はお金の話です。

segv-handler-gdb:Rubyスクリプトがクラッシュしたときにより詳しくCレベルのバックトレースを出力するgemは当時gdbruby.rbが話題になったので対抗して書いたものです。

11月

github-post-receiverの複数サイト対応はGitHubにpushしたらコミットメールを送信する仕組みをGitLabでも動くようにしたという話です。

gettextとバージョン管理システムの相性の悪さを解消する案は.poのメタデータをバージョン管理対象ではなく自動生成可能な情報と扱ってはどうだろうか、という提案です。その後、droonga.orgでこの方法を実装しました。しばらく試してよさそうならdroonga.org以外でも使えるようにパッケージ化する予定です。

Rubyで変数宣言っぽいものをした方が読みやすくなるときはコミットへのコミットサービスを実視している時のやりとりで話題になったことをまとめたものです。

12月

GTK-Docの使い方はGTK+用のドキュメントツールの紹介です。

全文検索エンジンGroongaを囲む夕べ 4での発表資料は毎年いい肉の日に開催しているGroongaイベントでの発表内容の紹介です。

スクリプト言語の拡張機能の作り方とGObject Introspectionの紹介はバインディング作成技術の推移をまとめています。SWIGで知識が止まっている人には役に立つ話なはずです。

パーフェクトRubyのおかげでYARDがよくなってGroongaイベントも開催できた話はちょっとした裏話です。

GObject Introspection対応ライブラリーの作り方は貴重な資料です。日本語で同種の資料はないはずです。

Mac OS X版GTK+の日本語入力対応 その後は最新情報を紹介しています。OS X上でのGTK+の日本語入力周りの話題はこれで一区切りです。

まとめ

2014年にやりたいことと、2013年のことをまとめました。

今年もよろしくおねがいします。

*1 あるいは、Mozillaを使いたい、クリアなコードを書きたい

つづき: 2015-01-07
2014-01-09

«2013-12-26 最新 メタプログラミングをして割に合うかの判断基準:処理を1箇所に局所化できるか»
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|
タグ:
RubyKaigi 2015 sponsor RubyKaigi 2015 speaker RubyKaigi 2015 committer RubyKaigi 2014 official-sponsor RubyKaigi 2014 speaker RubyKaigi 2014 committer RubyKaigi 2013 OfficialSponsor RubyKaigi 2013 Speaker RubyKaigi 2013 Committer SapporoRubyKaigi 2012 OfficialSponsor SapporoRubyKaigi 2012 Speaker RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer badge_speaker.gif RubyKaigi2010 Sponsor RubyKaigi2010 Speaker RubyKaigi2010 Committer
SapporoRubyKaigi02Sponsor
SapporoRubyKaigi02Speaker
RubyKaigi2009Sponsor
RubyKaigi2009Speaker
RubyKaigi2008Speaker