「エンジニアマネージャー論と学びを抽出する努力を続けること」を読んで - $shibayu36->blog;
http://wazanova.jp/items/1574を読んで、非常に参考になったのでいつも本を読んで感想書いている時と同様、思うところについて書いてみる。 今回は以下の二つのポイントについて非常に感銘を受けた。 やるべきことを毎日洗い直して、絞り込むことが大切 適切な意思決定プロセスとメンバとの良好な関係が築ければ、95%は大丈夫 やるべきことを毎日洗い直して、絞り込むことが大切 上であげたブログに 真剣にものごとに取組むと、やらなくてはいけないことはそのうち次から次へと気づく and/or 嫌でも湧き出てくるもの。なので、アドバイスを求められれば、やるべきことは最小限、できれば三つ以内に絞って、何をやめることができるかを探す手伝いをするようにしています。やるべきことを毎日洗い直して、絞り込むことが大切。 ということが書いてあり、直近の自分の状況もあいまって非常に納得できる言葉だなと
設定の仕様をドキュメントに書くのではなく、テストにしてしまう - $shibayu36->blog;
以前開発のドキュメントをどこに置くか問題 - $shibayu36->blog;という記事を書いた。まだよい方法はちゃんと考えられてないが、少しずつケースバイケースでいろいろな手法を試してみている。今回は設定項目の仕様のドキュメントという観点で考えたときに、テストを作ることで解決できないか、ということについて書く。 設定項目の仕様 例えば以下の様な設定があったとする*1。 [ { "blog_url" : "http://shibayu36.hatenablog.com/", "permission" : "public", "can_be_edited_by" : [ "shiba_yu36" ] }, { "blog_url" : "http://shibayu36-private.hatenablog.com/", "permission" : "private", "can_be_
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);
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
最近タスクがどのくらいで終わるか見積もることが多いんだけど、そのたびにうまく見積もりができてなかったり、思ったより長引いてしまってすごく忙しくなってしまったり、といったことが何度かあった。このままじゃ良くないなーと思って、「アジャイルな見積りと計画づくり」を読んだ。 アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ 作者:Mike Cohn,マイク コーン毎日コミュニケーションズAmazon 実際読んでみると今の状況に非常にぴったりで良い本だった。この本を読んでいくと、最初から正確な見積りをするのは不可能で、作業をしながら見積りの精度をあげるといったり、変更やリスクに強いスケジュールをうまく作るということをしていく必要があるということが分かる。なんとなく自分がタスク管理をしないといけなくなったけど、なんかうまくいかないと思っている人には非常に参考になると思う。あと
最近のテストケースの決め方メモ - $shibayu36->blog;
テストケースを決めるの結構難しい。最近Perlでのテストでテストケースを選ぶときに気をつけてることを適当にメモする。 条件分岐ごとにテストケース 基本的には条件分岐ごとにテストケースを作ってテストする。 ブログサービスの場合だったら、ブログがあるときないときでsubtest分けて書く さらにブログが公開状態、非公開状態とか 下の方は厳密に、上の方はゆるく 下の方のレイヤーではテストケースの種類は増やして厳密にテストするけど、上の方ではロジックは正しい前提でそんなにテストケース増やさない ロジックの部分はC0 100%は絶対だけど、ViewやControllerの部分ではそこまでは目指さないみたいな 下のほうの組み合わせで上のレイヤーできるので、あんまりやり過ぎるとテストケース爆発する もちろんうまくスタブとか使ったりする 出来るだけ落ちやすいテストケース 出来るだけ落ちやすいと思われるテス
レビュータイムの導入・消滅・再導入 - $shibayu36->blog;
今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。 ひさいちレビュー、必ず通すみたいなの良いのか悪いのか— ひさいち (@hisaichi5518) 2014年3月13日 @hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう— 柴崎優季 (@shiba_yu36) 2014年3月13日 @hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。— 柴崎優季 (@shi
Perl + Travis CI + Coveralls (PrePANの対応) - $shibayu36->blog;
CIサービスが結構出てきてる中、自分自身がまだ触ったこと無くて遅れてるなーと思ってたら https://twitter.com/kentaro/status/433058168847884288 と言われたのでPrePANでTravis CIとCoverallsを使ってみた。こういうのみんなやってると思うので真新しいことはないけど自分用メモ。 PerlとTravis CI 手順としては Travis CI側で設定をON状態に repositoryに.travis.ymlを作成 で終わり。 Travis側設定 Travis CIにログインすると自分のprofileで設定を変えられるので、適当にボタンを押す。 .travis.ymlの編集 その後.travis.ymlを編集。参考例は以下。 language: perl # perlを利用 # どのperlを使ってbuildするか、複数書いてお
LWP::Protocol::PSGIを使ってAPIを叩くメソッドのテストを書く - $shibayu36->blog;
テストをするときに外部のAPIを叩く部分のテストを書きたい場合、出来る限り外部にアクセスせずにテストを書きたい。そういう時 Test::Mock::Guardを使って該当部分のメソッドが特定のデータを返すように書き換えてしまう LWP::Protocol::PSGIを使うなど、APIを叩くclient部分を差し替える Test::TCPを使って、APIのserver部分を差し替える などの方法がある。 今回はLWP::Protocol::PSGIを使ってAPIを叩くclient部分を差し替えるというのをやってみた。 テストしたい実装 例えばはてなブックマーク件数取得APIを使った実装があるとする。 以下の様な感じ。 package Bookmark::Client; use strict; use warnings; use URI; use URI::QueryParam; use LW
Immutable Infrastructureに対する自分なりの考えメモ - $shibayu36->blog;
インフラ系技術の流れ - Gosuke Miyashita 今さら聞けない Immutable Infrastructure - 昼メシ物語 2014年のウェブシステムアーキテクチャ - stanaka's blog http://rebuild.fm/25/ この辺りを読んだ。自分の中ではImmutable Infrastructureについてはここ一週間で調べただけであり、解説などは出来ないが、とりあえず自分用のメモとして自分の思ったことなどを書いていく。 コンテナベースのデプロイ Dockerなどが出てきたことにより、Dockerのイメージをそのままアップロードし、それを本番でも動かすということが出来そうというのが面白かった*1。こういう風なフローになるとすると、これまでのデプロイ手順とは全く違うようになりそう。 これまでのデプロイと、コンテナベースのデプロイ これまでのデプロイは
Dockerで立てたコンテナにsshで接続する - $shibayu36->blog;
最近Dockerをちょっと触っていて、とりあえずDockerでコンテナを立ててsshでつなぐということをやってみた。 Dockerを入れる macだとDockerが入っているvagrant環境があるのでそれを落としてくる。 http://docs.docker.io/en/latest/installation/vagrant/ $ git clone https://github.com/dotcloud/docker.git $ cd docker $ vagrant upこれでDockerが動くvagrant環境が出来た。今後の作業はこのvagrantにsshした状態で行う。 $ vagrant ssh sshdが起動したコンテナにつなぐ http://docs.docker.io/en/latest/examples/running_ssh_service/ この辺を参考に。 まず
AWS, chef, Cinnamon等を使った無停止デプロイ(PrePAN carton 1.0化の裏側) - $shibayu36->blog;
最近PrePAN uses carton 1.0 now! - $shibayu36->blog;でも書いたとおり、PrePANのcarton 1.0化を進めていました。 通常であれば変更点をアプリケーションサーバにデプロイし、サーバを再起動すれば良いのですが、cartonを0.9から1.0に上げるというまあまあ大きな変更を加えるため、事前に動作確認を行い、無停止でデプロイしたいと考えました。そこでAWSを使って無停止デプロイを試してみたのでそれについて書こうと思います。 PrePANのサーバ構成やデプロイ手順の検討 無停止デプロイの説明の前にPrePANのサーバ構成を紹介しておきます。 現状はELB 1つに対し、EC2が2台ぶら下がっているという状態で運用しています。そしてEC2に対してはそれぞれapp-1, app-2という名前でタグがついています。 開発メモ#2 : AWS でのホス
znc 1.0をインストールした - $shibayu36->blog;
そろそろちゃんとIRC Proxyのセットアップとかしようと思っていたら、zncが1.0になって、SSL周りの設定がさらに簡単になっていたのでやってみた。tiarra+stoneを卒業してZNCを使い始めた - すぎゃーんメモ時点では、複数のネットワークに接続するには複数ユーザ作らないといけなかったんだけど、1.0の時点では単一ユーザで複数ネットワークに接続出来るようにもなっていた。 インストール aptitudeのstableとかに1.0がまだ来てなかったので、sourceからインストールする。http://wiki.znc.in/Installation を参考に。 $ wget http://znc.in/releases/znc-1.0.tar.gz $ tar -xzvf znc-1.0.tar.gz $ cd znc-1.0 $ ./configure --prefix=$HO
Test::Perl::Criticでコーディング規約をテストする - $shibayu36->blog;
コーディング規約はあるけれど、レビューの時にチェックするのは大変ということで、とりあえずTest::Perl::Criticを使って軽くテストを書いてみました。 僕はある程度のコーディングのブレは許容して、チーム全員で合意がとれるものだけを自動でチェックするようにしたほうが良いと思っているので、rcファイルを使って、必要な物だけ追加していく形式を試してみました。 テストの追加 まずテストは以下のようにt/perlcriticrcを読み込むという設定をしてあげた上で、libとt全部をテストするように書きます。 require Test::Perl::Critic; my $rcfile = File::Spec->catfile( 't', 'perlcriticrc' ); Test::Perl::Critic->import( -profile => $rcfile ); all_cri
XslateのテンプレートをCSSインライン化する - $shibayu36->blog;
HTMLメールを送信する時、クライアントによってはlinkでのcss指定やstyleタグを解釈しない場合があります。その場合、CSSをHTML要素にインライン化しないといけないのですが、今回はこのことについて書いてみます。 CSS::Inlinerを使う perlにはCSS::Inlinerというモジュールがあって、これを使えばstyleタグの入ったhtmlに対して、CSSインライン化することが出来ます。 例えば以下の様なHTMLがあった場合 <html> <head> <style type="text/css">body { margin: 0px; } #a { padding: 0px; }</style> </head> <body> <p id="a">hoge</p> <p id="b">fuga</p> </body> </html> 以下の様なコードを書けば my $in
Test::Moreのsubtestで困っていること - $shibayu36->blog;
最近はperlでテスト書く時はTest::Classを使うようにしている。その理由の一つとして、subtestだけのテストだと少しだけ困ることがあるからだ。 具体的には以下の事がある。 subtestは書かれている順に実行されるため、前のテストの状態に依存したコードが書かれがち 特定のsubtestだけを実行するのが面倒 前のテストの状態に依存したコードが書かれがち 僕の中では、テストが前のテストの状態に依存しないようにすべきと思っている。各テストの依存度が増えると、その後テストを追加したいときにコードの見る範囲が増え、テストが書きづらくなってしまうからだ。 しかし、subtestは単に書かれた順にテストが実行されるので、前のテストの状態に依存したコードが書きやすいと思っている。例えば以下の様なコードが書かれがち(少し極端な例だが)。 use Test::More; # insert_en
Harrietを使ってprove単位でmysqldを作ってみた話 - $shibayu36->blog;
tokuhirom blog を見て、これ便利だなーと思ったので、試しにこれを使ってprove単位でTest::mysqldを起動するやつを作ってみた。 harriet用設定を作る まずt/harriet/mysqld.plみたいなのを作る。この中でmysqldの起動とschema流し込みまでしてしまう。複数のdsnを保存しておきたければ、jsonで入れておくと良さそう。 # t/harriet/mysqld.pl use JSON::XS; use Path::Class; $ENV{TEST_EPIC_DSNS} ||= do { require Test::mysqld; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '', # no TCP socket 'default-storage-engin
処理のtimeoutを簡単に書くためのSub::Timeoutというモジュールを作りました - $shibayu36->blog;
ある処理をするときに一定以上の時間かかったらtimeoutして処理を終わりたいみたいなことをしたい時がたまにあるので、それを行うSub::Timeoutというモジュールを作りました。 https://github.com/shibayu36/p5-Sub-Timeout 使い方 use Sub::Timeout; use HTTP::Tiny; my $res = timeout 3.5, sub { HTTP::Tiny->new->get('http://example.com/foo'); }; 基本的には上のように、タイムアウトしたい秒数と処理のcoderefを渡します。 上の例だと3.5秒間で処理が終わった場合、その返り値を$resとして返し、処理が終わらなかった場合、その時点で処理を打ち切って例外を投げるようにしています。例外を投げるのでその後も処理を続けたい場合は例外処理をし
zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog;
仕事でgit使っていてレビューとかしていると、どうもgitのブランチ切り替えがだるくなってくる。それで、zawで更新日時順でブランチが並んでいて、選択するとgit checkout出来ればすぐにブランチ切り替えが出来て便利ではと思いやってみた。 bindしたキーを押すと、更新日時順でブランチが表示されて、Enterを押すとチェックアウトする。更新日時順なので数回キーを押すだけで、チェックアウトしたいブランチに辿り着けることが多い。zawを使っているので絞り込みも出来る。 インストール zawを使っていれば、導入は簡単。 まずzawのsourceのディレクトリに以下のファイルを置く。もしくは適当なところに置いて、zawのloadの後にsourceを使ってloadする。 https://github.com/shibayu36/config-file/blob/master/.zsh/zaw-
perlでforkしたプロセスとの通信を簡単に行う方法が知りたい - $shibayu36->blog;
今作っているもので、「forkした後、子プロセスの実行の結果を最後に親プロセスに通知し、親プロセスは子プロセス群の状態をまとめて取得する」、ということがやりたいのですが、モダンかつ簡単な方法って何があるんでしょうか？ 具体的には use Parallel::ForkManager; $pm = Parallel::ForkManager->new(5); foreach $data (@all_data) { # Forks and returns the pid for the child: my $pid = $pm->start and next; # ... do some work with $data in the child process ... # 実行結果のサマリーを親プロセスに投げておく $pm->finish; # Terminates the child proc
修正時に一箇所リファクタリングする - $shibayu36->blog;
最近仕事でバグ修正をするときには、必ずその周辺のリファクタリングを一箇所行うという事をしている。今日はそのことについて書いてみる。 時間が経つとコードはレガシーになる これは自分の感覚でしかないのだが、コードというのはどんなに素晴らしい人が書いたとしても、時間が経つと必ずレガシーコードになると思っている。これには例えば以下の理由などがある。 技術が進む 昔は無理やりやらないといけなかったものが、ミドルウェアを入れると簡単に出来るようになったとか コーディング規約が変わる 人が増えるなど、外部要因によってコーディング規約が変わるけど、昔のコードは思想が違うとか そのため、少しずつリファクタリングの時間を設けないとどんどんレガシーなコードが作られていく。 修正時、一箇所修正する それでリファクタリングをしたいのだけど、ずっとリファクタリングをするのもモチベーションを維持できないし、リファクタリ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
