RubyKaigiのCFPへの応募例 #rubykaigi - 2017-06-06 - ククログ
須藤です。関西Ruby会議2017が終わってからRubyKaigi 2017の発表を応募しました。 RubyKaigi 2017のCFPがでています。CFPとはもともと（？学会の文脈で）はCall For Papersの略ですが、RubyKaigiの文脈ではCall For Proposalsの略で、「RubyKaigiでの発表を募集しています」という意味です。RubyKaigi 2017の発表の応募は6月17日まで受け付けています。 応募する人が増えるといいなぁと思うので、実際の応募例として私のRubyKaigi 2015からRubyKaigi 2017の分の応募内容を紹介します。どうしてRubyKaigi 2015の分からかというと、CFPアプリケーションができて応募の記録が残るようになったのがRubyKaigi 2015からだからです。 項目 実際の応募内容を紹介する前に、どのような
fluent-plugins-nurseryのご紹介 - 2016-11-09 - ククログ
クリアコードではFluentdの開発に参加しています。 以前の記事でも紹介した通り多くのプラグインの開発にも参加しています。 Fluentd v0.14系がリリースされたので、最近はプラグインをFluentdのv0.14 APIに対応させるようなプルリクエストを送っています。 移行手順については公式のドキュメントに説明があり、ククログにもいくつか記事があります。なので、やろうと思えばすぐにFluentd v0.14 APIに移行することができます。 Fluentdには600以上のプラグインがありますが、中にはメンテナンスが活発でない1プラグインもあります。 今のところ足りないドキュメントがあったり、新APIに移行した事例が少なかったりして、新APIへの移行をためらっているプラグイン作者もいると思われます。 そこでFluentdのプラグインを安定してメンテナンスできる体制を構築し、Fluen
RubyKaigi 2014：Three Ruby usages - High-level interface, Glue and Embed #rubykaigi - 2014-09-24 - ククログ
株式会社クリアコード > ククログ > RubyKaigi 2014：Three Ruby usages - High-level interface, Glue and Embed #rubykaigi 関連リンク： スライド（Rabbit Slide Show） スライド（SlideShare） スライド（Speaker Deck） リポジトリー（スライドのソースだけでなく、読み原稿や、発表では使わなかったベンチマークスクリプトなども置いてあります。） 内容 この発表では特に目新しい技術的な話題はありません。これまで何年もRubyを使ってきた経験からRubyの使い方を大きく3つに分けて整理した、という話です。 応募したときは、それぞれの使い方についてメリット・デメリットを説明しこの使い方をするときのトレードオフはどこになるかまで示して、「聞いている人たちがどの使い方を選べばよいか（選ば
v0.14 Outputプラグインの仕様解説 - 2016-10-20 - ククログ
はじめに クリアコードはFluentdというソフトウェアの開発に参加しています。Fluentdはログ収集や収集したデータの分配・集約などを行うソフトウェアです。 v0.14での新機能を使ったプラグインを作成する際にはこれまでの Fluent 以下のクラスではなく、Fluent::Plugin 以下のクラスを継承し、実装する必要が出てきました。 また、v0.14のOutputプラグインはv0.12とは異なり、Fluent::Plugin::Output クラスに様々な機能が入っています。これらの機能をプラグイン開発者向けに解説することを目指します。 この記事はv0.14.8以降が対象です。 まずは、Outputプラグインが必ず実装するべきメソッドについてのおさらいです。 non-buffered
RubyKaigi 2016にスポンサーとして参加 #rubykaigi #oss_gate - 2016-09-13 - ククログ
予告通り、2016年9月8日から10日まで3日間開催されたRubyKaigi 2016にスポンサーとして参加しました。今年はブースを出せるということだったのでブースを出しました。（スピーカーとしての参加についてはHow to create bindings 2016を参照してください。） クリアコードは例年RubyKaigiをスポンサーとして応援しています。応援することが目的なので特に会社としての明確なメリットを設定しておらず、次のような「こうなるといいな」が実現されたらラッキーくらいに考えています。 パッチ採用に応募する人がいればいいな インターンシップに応募する人がいればいいな OSS Gateに参加する人が増えればいいな OSS開発支援サービスを利用する企業が増えればいいな その他、Mozilla FirefoxやGroongaなどの問い合わせにつながればいいな そのため、それほど前
GObject Introspection対応ライブラリーの作り方 - 2013-12-16 - ククログ
require "gobject-introspection" module Sample loader = GObjectIntrospection::Loader.new(self) loader.load("Sample") end greeter = Sample::Greeter.new puts(greeter.greet) # -> Hello! どちらの場合も、「Greeterクラスを定義、Greeterクラスにはgreetメソッドを定義」ということを指定していません。「Sampleライブラリーを使う」と指定しているだけです。 SampleライブラリーのAPIは2つの関数しか提供していませんが、通常、ライブラリーのAPIはもっと多くの関数を提供しています。ライブラリーがGObject Introspectionに対応していると、それらの関数をどのように使うかを1つずつ定義し
Rubyのテスティングフレームワークの歴史（2014年版） - 2014-11-06 - ククログ
2014年12月にRuby 2.2がリリースされる予定です1。 Ruby 2.2にはRuby 1.9.1のときに外されたtest-unitというテスティングフレームワークが再びバンドルされる予定です。Rubyのテスティングフレームワーク周りに詳しくない人にはよくわからない状況でしょう。そこで、Rubyのテスティングフレームワークの歴史を説明することで状況を整理します。 名称の整理 この説明の中ではたくさんのテスティングフレームワークが登場します。似たようなものもあるため、最初にテスティングフレームワークの名称を整理します。この説明の中で登場する名称は次の通りです。 RubyUnit Lapidary rubyunit Test::Unit test/unit test-unit miniunit minitest RSpec 違いがわかりますか？ざっくり説明すると次の通りです。 RubyU
Rubyで自然なDSLを作るコツ：値を設定するときはグループ化して代入 - ククログ(2014-02-13)
最近、fluent-plugin-droongaという分散データストリームエンジンを書いています。その中で、RubyでDSLを実現するときに工夫していることに気づきました。それは、値を設定するときは代入する字面にするということです。代入する字面にするために、グループ化用のオブジェクトを作っていました。 これだけだとどういうことかわからないので、具体例を示しながら説明します。 RubyとDSL Rubyを使っているとRubyで実現されたDSLに触れることが多くあります。RubyのMake実装であるRakeの設定ファイルもそうですし、ライブラリー管理ツールのBundlerの設定ファイルもそうです。 Rakeの場合:
test-unitならRSpec 3のComposable Matchers相当のことをどう書くか - 2014-03-19 - ククログ
RSpec 3の新機能であるComposable Matchersの使い方の例をtest-unitならどう書くか紹介します。リンク先のコードを示し、それのtest-unitバージョンを示す、という流れを繰り返します。 テスト対象 テスト対象は次のコードです。 class BackgroundWorker attr_reader :queue def initialize @queue = [] end def enqueue(job_data) queue << job_data.merge(:enqueued_at => Time.now) end end describe BackgroundWorker do it 'puts enqueued jobs onto the queue in order' do worker = BackgroundWorker.new worker.
メタプログラミングをして割に合うかの判断基準：処理を1箇所に局所化できるか - 2014-01-16 - ククログ
毎日他の人のコミットをながめる文化で生活していると、理由は浮かばないけど「ん？このコミットはなんか気になる」と感じるようになります。それは、新しいことを知ることができたコミットだったり、真似したくなるようなコードが入っているコミットだったり、なんかまずそうな気がするコミットだったり、様々です。 「ん？」と感じてコミットを見直してみても、何が気になったか自分でもすぐにわからない場合があります。そんなとき、気になったことをコミットした人に伝えるために、コミットへのコメントをまとめ始めます。「コミットした人に伝えるため」というように、他の人に伝えようとすることがポイントです。他の人に伝えるためにまとめようとすると、思いの外なにが気になったかまとまるものです。 今回は、メタプログラミングを使ってコードを整理したコミットで「ん？」と感じたときのことについて紹介します。このおかげで「メタプログラミング
GDBでデバッグするなら-g3オプション - 2013-05-08 - ククログ
RubyやPythonなどのスクリプト言語では実行中に例外が発生するとバックトレースを出力してくれます。バックトレースがあるとどこで問題が発生したかがわかるためデバッグに便利です。一方、CやC++では不正なメモリアクセスをすると、バックトレースではなくcoreを残して1終了します2。デバッガーでcoreを解析するとバックトレースを確認できます。 このように、CやC++でデバッグするときにデバッガーはなくてはならない存在です。スクリプト言語にもデバッガーはありますが、デバッガーを使わなくてもデバッグできる範囲が広いため、CやC++をデバッグするときのほうがデバッガーのありがたさがわかります。 この記事では、広く使われているデバッガーであるGDBをもっと便利に使うためのGCCのコンパイルオプション-g3を紹介します。 サンプルプログラム まず、この記事で使うサンプルプログラムを示します。マクロ
クリアコードのフリーソフトウェアビジネス - 2013-07-24 - ククログ
はじめに 7月12日につくばインターンシップ・コンソーシアム主催の夏休みインターンシップマッチングフェアにインターンを受け入れる企業として参加してきました。中小、ベンチャー企業16社と50名ほどの学生さんが参加していました。クリアコードのブースには10名近い学生さんがきてくれました。ブースではクリアコードの業務内容、インターンシップを実施する理由、現在実施しているインターンシップを紹介しました。ブースにきてくれた学生さんはフリーソフトウェアでビジネスをしているというクリアコードの特徴に興味をもったようで、どうやってフリーソフトウェアでビジネスができるのかという質問をよく受けました。そこで今回はクリアコードがどうやってフリーソフトウェアでビジネスをしているのか紹介します。 クリアコードの業務内容 クリアコードは2006年7月25日に創業し、今月7周年を迎えました。これまでの7年間、さまざまな
わかりやすいコミットメッセージの書き方 - 2013-04-24 - ククログ
もう1年以上前になりますが、コミットメッセージの書き方を説明しました。ざっくりまとめると、以下のことを説明しています。 わかりやすいコミットメッセージがいかに大切か どのようなコミットメッセージがわかりやすいか（具体例付き） この説明をしてからも、日々コミットしていくなかで新たに得られた「どうすればもっとわかりやすいコミットメッセージになるか」という知見が増えていました。これは、コミットへのコメントサービスの提供を開始した1ことも影響しています。このサービスでは、コミットへコメントするときに「どうして自分は他の書き方よりもこの書き方をわかりやすいと感じるか」を説明しています。その過程で「なんとなくこっちの方がよさそう」だったものを「具体的にこういうときにこう感じるのでこっちの方がよさそう」と何かしら理由を考えるようになりました。これにより、今までそれぞれの開発者でなんとなくだった考えが共有
クリアなコードに囲まれて - クリアコードでの二年間 - 2013-02-27 - ククログ
クリアコードでアルバイトをしているおやまだです。このたび、二年間お世話になったクリアコードを離れることとなりました。はじめてのククログ記事が、お別れの記事となってしまいました。 この記事では、私がこの二年間で見てきたクリアコードの姿とそこから学んだことがらについて、ご紹介したいと思います。 フリーソフトウェアの会社 クリアコードで二年間働いて強く感じたのは「クリアコードはフリーソフトウェアの会社なんだ」ということです。 思い返せば、クリアコードとのはじまりもフリーソフトウェアでした。二年前、私の公開するフリーソフトウェアをみた社員の方が、うちに興味はないかと連絡をくれたのです。当時は採用プロセスにペアプログラミングがあり、私も社員の方と共に実際のフリーソフトウェアの機能拡張をおこないました。 驚いたのは、そこでおこなった機能拡張が実際のリポジトリにコミットされ、公開されたことです。フリーソ
2012年のまとめと2013年にやりたいこと - 2013-01-08 - ククログ
毎年、年の最後にはその年の記事をまとめていたのですが、2012年分のまとめをし忘れたので、ここでまとめておきます。 2013年の記事に2012年のことだけが書かれているというのは違和感があるので、はじめに、2013年にやりたいことをまとめておきます。 2013年にやりたいこと 2012年に社外に向けて新しくやり始めたことがいくつかありました。ただ、クリアコードは「社外に向けて新しくやり始めること」に慣れていなかったので、始めるだけで大変でした。始めることはできたので、2013年は実際にやっていくことに力を注ぎます。具体的には以下のことに力を注いでいきます。 パッチ採用 コミットへのコメントサービス 詳細は後述します。 また、以下に挙げる既存の業務においては、ソフトウェアの発展やお客様のニーズの変化にあわせて、提供するサービスも多様化してきました。2013年もクリアコードならではの専門的な支
リーダブルコードの解説 - 2012-06-11 - ククログ
注: 記事中の「解説」の部分のライセンスは「Creative Commons 表示 - 非営利 - 継承」です。「解説」は「クリアコード」（「ClearCode Inc.」）によって変更されています。変更前の原著作者は「オライリー・ジャパン」です。「Creative Commons 表示 - 非営利 - 継承」なので再配布や変更や翻訳などはライセンスに従って自由に行えますが、営利目的で利用することはできません。 https://amazon.co.jp/dp/B0064CZ1XEの翻訳である「リーダブルコード」が今月（2012年6月23日）発売されます。すでに予約できるようです。 https://amazon.co.jp/dp/4873115655 本書の内容は原書の紹介記事を参照してください。 日本語版の訳者は角さんです。これまでの訳書と同様にとても読みやすく訳されています。翻訳なので読
クリアなコードの作り方: 意図が伝わるコミットのしかた - 2012-03-13 - ククログ
コミットメッセージの書き方ではコミットをわかりやすくするためには以下の2つの条件を満たす必要があると書きました。 コミットの内容が分かりやすく説明されていること コミットの内容が小さくまとまっていること このうち「コミットの内容が分かりやすく説明されていること」についてはすでに説明済みです。今回は「コミットの内容が小さくまとまっていること」について説明します。 めざすところ 単純にコミットの内容を小さくするだけではわかりやすくなりません。それでは、どのような基準で小さくすればよいのでしょうか。 よく言われることは1つのコミットには1つの小さな論理的にまとまった変更だけにする、というものです。たしかにこれは重要です。しかし、これだけを基準とすると、人によっては大きめなコミットになってしまいます。人それぞれで論理的なまとまりの大きさが異なるからです。 1つのコミットでどうすればよいかを考えるの
The Art of Readable Code - 2012-03-05 - ククログ
2011年11月に「理解しやすい、読みやすいコードはどのように書けばよいか」という内容の本がO'Reillyから出版されました。（英語です。） https://amazon.co.jp/dp/9780596802295 英語なので読む人はいないでしょうが紹介します。読みやすい英語で書かれているので、「読みやすいコードだけではなく英語の勉強にも興味がある」という人にはちょうどよいでしょう。ページ数も200ページにいかないぐらいとコンパクトにまとまっています。 さて内容ですが、第一部が「SURFACE-LEVEL IMPROVEMENTS」です。見た目をよくしようという話です。具体的な内容は読んでもらうとして、まず、見た目のよさから入っているところが「わかっている感」をだしていますね。 読みやすいコードにするテクニックはいろいろありますが、まずは見た目が整っていないと、どんなにテクニックを駆使
コミットメッセージの書き方 - 2012-02-21 - ククログ
はじめに 「分かりやすいコードを書く」、「コードと一緒にテストも書く」等はソフトウェア開発において大切なことです。しかしそれと同じくらい大切なことして「分かりやすいコミットメッセージを書く」があります。これはあまり着目されていなく、見過ごされていることです。 今回は、コミットメッセージの分かりやすさの大切さ、そして、分かりやすくするための書き方を説明します。 コミットメッセージとその大切さ バージョン管理システムとコミット 現在、ほとんど全てのソフトウェア開発ではSubversionやGitなどのバージョン管理システムを使っています。バージョン管理システムを使うことによるメリットというのは、ソフトウェアの変更が記録されていくことにあります。 具体的なメリットは3つあります。 ソフトウェアの調査がしやすくなることです。現時点でのコードと、そして変更の履歴とを組み合わせることで、それらから非常
クリアなコードの作り方: 縦長・横長なメソッドを短くする - 2012-02-07 - ククログ
最近読んだRubyのコードではYARDのコードがキレイでした。 さて、長いメソッドは不吉なにおいがするからメソッドを分割するなどして短くしましょうとはよく言われることですが、ここでいう「長い」とは「縦に長い」ことを指していることがほとんどです。長いのが問題なのは縦に長いときだけではなく横に長いときもです。 縦に長いメソッド まず、どうして縦に長いメソッドが問題かについてです。縦に長いメソッドには「処理を把握しづらい」という問題がある可能性が高いです。 どうして処理を把握しづらいか 処理を把握しづらい原因はいくつかあります。例えば、抽象度が低いのが原因です。 メソッドが縦に長くなっているときは、多くの処理が行われていることがほとんどです。これらの処理はメソッドになっていないため名前がついていません。処理に名前がついていない場合は実装を読まないとなにをしているかがわかりません。 せっかくなので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
