仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
Test::Time::AtというCPANモジュールをリリースしました - $shibayu36->blog;
社内でテスト時の時間操作を便利にするTest::Time::At というモジュールがあったので、それをCPAN化してリリースしました。 テスト中の時間を止めて、sleepなどの操作をうまくハンドリングしてくれるモジュールにはTest::Time というモジュールがあります。このモジュールを使っている時に、たまに、ある時間を指定してテストを実行したい時があります。そのような場合は以下のようにすれば実現できます。 use Test::Time; use DateTime; my $target_dt = DateTime->new(year => 2015, month => 7, day => 15); $Test::Time::time = $target_dt->epoch; my $now = time; Test::Time::Atを用いると、このような操作を少し便利にする事ができま
Carp::Replyを使って、モジュールの挙動を追いかける - $shibayu36->blog;
最近Cartonコードリーディング会をやっているのですが、そのときにCarp::Replyを使ってみたのでメモ。 例えばCartonとかの中身を追いかけるときに、この時点でこの変数はどうなっているのかとか調べたくなることがあります。そういうときにRubyのPryみたいな機能を持つ、Carp::Replyというのを使ってみました。 ひとまずやりやすいようにCartonのrepositoryをclone。 $ cd ~/development/ $ git clone https://github.com/miyagawa/carton.git ここに変更加えたのが使われるようにPERL5LIBに追加します。 $ export PERL5LIB=~/development/carton/lib あとは止めたい場所に以下の文を追加するだけです。 use Carp::Reply qw(repl);
いろいろなツールをplenvに移行した - $shibayu36->blog;
最近はplenvを使うべきって感じだったんだけど、promptとかemacsとかを対応させるのがちょっと面倒でサボっていた。そろそろやばいと思ったので全部plenvに移行した。 インストール macだったらbrewで提供されているので入れる。https://github.com/tokuhirom/plenv を参考に。 $ brew update $ brew install plenv $ brew install perl-build $ plenv install 5.14.2 # お好みのperl入れる $ plenv shell 5.14.2 $ plenv install-cpanm promptに現在利用しているperlのversionを出力する 以下のように、promptにperlのversion出てるとうれしいのでそういう感じにする。 plenv version-nam
Xslateのpre_process_handlerを使ってCSSのインライン化をする - $shibayu36->blog;
この前 XslateのテンプレートをCSSインライン化する - $shibayu36->blog;という記事をかいたのだけど、その時にgfxさんにコメントで gfx BKっぽい気もしますが他にいい方法は思いつかないし、最近 pre_process_handler という機能も足したので、まあ許容範囲じゃないすかね。 と言われた。 pre_process_handlerというものがあったことを知らなかったので、試しに利用してみた。 pre_process_handlerを使ってtemplateに対してCSSインライン化する さてやりたかったことを振り返ると メールを一通一通CSSインライン化するのではなく、先にtemplateをインライン化しておいて、それを利用してrenderしたい ということでした。 例えば以下のようなtemplateを用意します。 <html> <head> <styl
Test::Moreのsubtestで困っていること - $shibayu36->blog;
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
Working with Unix ProcessesをPerlで - $shibayu36->blog;
以前 Working with Unix Processesという本を読んだのですが、この本がUnixにおけるプロセスについて非常にわかりやすく解説されていました。それで自分で内容をメモしてみたり、さらにわからないところを調べたり、参考のプログラムをPerlで書いたり(この本ではRubyで書かれています)してみたのですが、ブログにまとめてなかったので、ちょっと書いてみます。 (注意)書いていたらすごく長くなりました。興味のある方は、適当に時間のあるときにでもどうぞ。 Chapter 2 : Introduction プロセスのことを知るとコードを読むだけでは分からないややこしい問題が分かるようになるよ Chapter 3 : Primer Unixはユーザ空間とカーネル空間がある kernelの機能はsystem call経由で利用する ユーザ空間ではプログラムが動く manual man
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
