プログラマー定年の日に父親になりました | おそらくはそれさえも平凡な日々
facebookやTwitterでは思っていたよりたくさんのお祝いの言葉を頂き、本当にありがとうございました。この場でお返事とさせていただきます。 6月5日に35歳になりました。よく言われるプログラマ定年説カッコワライっていうやつです。 日付を同じくして、子供が生まれました。自分でも驚きです。 プログラマ定年の日に第一子を授かりました。 — songmu (@songmu) 2015, 6月 5 奥さんは僕の誕生日に合わせて産みたかったみたいなので特に喜んでいます。なんか色々あってここまできたなーという感じです。産まれて本当に良かった。出産にも立ち会えた。会社の皆様のバックアップにも感謝です。 前日入院したときに、同室の隣の妊婦さんが出産前で、ものすごくつらそうなうめき声を上げながら分娩室に移動していたのですが、自分の奥さんがこうなったらいたたまれなくて精神的にキツイだろうなーとか(普段奥
ソースコード以外もとにかくテストする。もしくはカバレッジだけではダメだという話 | おそらくはそれさえも平凡な日々
あなたはプロジェクトのソースコードに対して適切にCIを回しているかもしれません。定期的にコードカバレッジの測定も行い、90%以上もしくは100%の数字を出しているかもしれません。 しかし果たしてそれで十分でしょうか？もしくはコードカバレッジだけにとらわれすぎていないでしょうか？ 監視とは(システムに対する)継続的なテストである、というのは筆者の尊敬する奥一穂氏の言葉ですが、その逆もしかりで 「テストとはプロジェクトに対する継続的な監視である」 ということも言えます。 その観点に立ってみると、プロジェクトのソースコード以外にもテストが必要なものがたくさんあることに気づくでしょう。以下に実際に筆者が自分のプロジェクトの中でソースコード以外にテストを書き、CIを回していたものを挙げてみます。 アプリケーション設定ファイルのテスト 開発中に本番用の設定ファイルを使うことはないため、本番用の設定ファ
株式会社はてなに入社しました | おそらくはそれさえも平凡な日々
本日は9月1日。エイプリルフールではなくて、防災の日です。 勤務地は東京の表参道ですが、今日から2週間だけ京都で働くので、新幹線の中でこのエントリを書いています。YAPCのトークでも話しましたが、東京で僕と一緒に働いてくれるエンジニアを絶賛募集中です。 長くなるのでとりあえずwishlistを置いておきますね。 http://www.amazon.co.jp/gp/registry/wishlist/3L07LJZVYI89C/ FA宣言したら20数社から連絡を頂いたんですが、その中からはてなを選ぶことにしました。はい。Perlの会社ですね。とは言えPerlは書かない予定です。とか言いつつちょいちょい書いてしまうことでしょう。 「Perlで、日本語の会社じゃねーか！」というツッコミが飛んできそうですが、はてなが一番自分を必要としてくれたと感じたので、入社させてもらうことにしました。こういう
Perlベストプラクティスのベストプラクティスじゃないやつをまとめてみた | おそらくはそれさえも平凡な日々
Perlベストプラクティス Perlベストプラクティス(略してPBP)という良い本があります。僕自身もPerlを学ぶ過程で非常にお世話になった本なのですが、以下の様なことが度々指摘されています。 bestって書いてあるけど「著者の」bestプラクティスなので偏りがあることも 「決して」とか「必ず」とかが多いけどあんま真に受けてはいけない この本を書くために書かれたであろうCPANモジュールとかがあって、しかも公開されてないものまである 致し方ないけど現在の状況にマッチしない古い情報もある なので、PBPの何がベストじゃないのかについてまとめてみることにした。前からやりたかったんだけど、思い立ってやった。 まとめてみたら、思っていたほどには項目が上がってこなかったので、やっぱPBPは良い本だなと改めて思いました。なので、このエントリーがこれからPBPを読む人の助けになれば良いなと思います。
退職とFA宣言のお知らせ | おそらくはそれさえも平凡な日々
所属的には5月いっぱいですが、5月12日(月)が最終出社で有給消化中です。理由はいろいろありますが、結婚や離婚がそうであるように、結局のところはタイミングの問題です。 一番大きな理由は家庭の都合です。家庭の都合というとネガティブに聞こえてしまうかも知れませんが、実際にはポジティブな挑戦です。 ただ、そのために会社を辞める必要は必ずしもなく、会社も引き止めの時にその事情を鑑みてバックアップしてくれる事は伝えてくれました。CTOに 「会社は社員の夢を実現する場所だと思っていて、だからといって全員が別の方向を向いているわけにもいかないので、誰かの夢に乗っかる形で事業を作っている。なので『こいつの夢に乗っかりたい』とか思わせたり、逆にそう思えるようなイイヤツを採用している。ただ、松木くんくらい会社に貢献してくれた人間だったら、自分の個人的な夢や目的のために会社を利用してくれて構わないし、むしろそう
Carton考2014 | おそらくはそれさえも平凡な日々
こうするのがいいかなーと思ってる。経緯は端折って大枠だけ。Webアプリケーションプロジェクトの場合です。 cpanfileちゃんと書いてコミット 今やどこでもやってますね。scan-prereqs-cpanfileも便利です。 開発者は各自carton installでモジュールをインストール。プロジェクトごとにPerlをビルドしたりしてる場合は、cpanm --installdeps .でも別に良い。 CI環境でcpanfile.snapshotを作る CI環境は必ず以下のとおりとする。 本番環境と同じアーキテクチャ 本番環境と同じバージョンのPerl まっさらな状態(Globalに何のモジュールも入っていない) CIにcarton installもさせて、必要なモジュールをlocal/に入れてテストさせる。毎回サラからcarton installしてたら時間かかるので、git pull
Perlでマルチバイト文字の文字幅をAmbiguousWidthも考慮して取りたいときのTips | おそらくはそれさえも平凡な日々
08/06 17:45 追記 tokuhiromがText::VisualWidth::PP 0.02を出してくれました。 これには、$Text::VisualWidth::PP::EastAsianというフラグ変数が加わっていて、これにtrue valueをセットすることでAmbiguousWidthの扱いを変更できます。つまりこれでいける。 use Text::VisualWidth::PP; $Text::VisualWidth::PP::EastAsian = 1; my $chr = '…'; print Text::VisualWidth::PP::width($chr); # 2 これで変なバッドノウハウを避けられて万事解決な感じです。tokuhirom++ tl;dr 曖昧幅も全角幅とみなして幅を取りたい場合は以下のようにすれば良い。tokuhiromに指摘を受けて修正しま
おそらくはそれさえも平凡な日々: Puncheurのご紹介改めオレオレWAFを作ってしまった件
職質テックトークでもちょっと話したのですが、 PuncheurというWAFを作ってCPANにもあげてしまいました。 読み方はパンチャーですが、パンツァーでもパンチラでもなんでもいいです。 気軽に開発を始められてカスタマイズ可能なWAFとなっております。 最低限のユーティリティーを提供しつつ、DispatcherとViewは差し替え可能になってるという、最近よくあるあれです。 実際かなりAmon2からコピペです。 ちょっとしたPSGIアプリケーションをCPANで配布する的な用途に向いているのが大きな特徴となっています。 主な特徴としては以下。 Perl5.8切り捨て すべてMyApp->new(%opt)から始まる MyApp->new(%opt)->to_psgi; って書ける my $c = MyApp->new(%opt); ってCLIで書ける Lite的な奴も.psgiにべろっと書か
おそらくはそれさえも平凡な日々: CPANで意図しない名前空間の取得を防ぐために
だいたいこのへんで教えてもらった話のまとめです。 http://lingr.com/room/perl_jp/archives/2013/04/03 CPANで名前空間を取るのは簡単です。今ならCPANに上げるコードベースの「どこか」に package Hoge; と書けば、CPAN Indexerにインデックスされていとも簡単にHoge名前空間のオーナーになれます。 (執筆時現在Hogeのオーナーはいません) これはlib/以下の.pmファイルやファイル先頭のpackage宣言だけに限った話ではありません。 例えば、example/MyApp.pmとかも対象です。 ちなみに誰がどの名前空間を持っているかは以下を見ることでわかります。 http://www.cpan.org/modules/02packages.details.txt 多くの場合この挙動に困ることはありませんが、以下の様な
おそらくはそれさえも平凡な日々: cpanfileのrequiresにURLを直接指定するのは好ましくない
cpanfileでは、requires "git:..."; のように、gitやtarballのURL等を指定すれば cpanm --installdeps . でモジュールがインストールできる「裏ワザ」があることが 結構知られているようです。しかし、これは好ましくありません。そもそも CPAN::Meta::Spec準拠ではありません。 これはあくまでcpanm側が第1引数にgitやtarballのURLなどを指定すればよしなに インストールしてくれるから現状は「偶然」そういう動きになっているだけです。 (cpanm git:...でインストールできるので、requires "git:..."; って書いてあれば 入れてくれてしまうってことです。) あくまでインストールにcpanmを使った場合に動くってだけの限定的な話で、しかも今後は 動かなくなる可能性が高いです。 実際問題、requi
おそらくはそれさえも平凡な日々: App::Xaicron構想
タスクの定期実行としてcronが使われ続けていることに問題意識を抱えている人は数多く居れども、多くは惰性で使い続けている。何を隠そう私もその1人である。 そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。 斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。 懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るという
おそらくはそれさえも平凡な日々: CPANモジュールのパッケージングの歴史
最近同僚が次々とCPAN Authorになってて良い流れだなーとか思っています。 ただ、CPANへのモジュールの上げ方がわからないとか、M::Iを使えばいいのか M::Bを使えばいいのか、それらがそもそも何やってるのか分からないという話も 聞くので、僕自身もその辺の知識を整理してアップデートしました。 とりあえず、今はModule::Buildを使っておけば良いんじゃないかと 思っていますが、そこに至る歴史的経緯をまとめてみます。 大体、以下に書いてあることに加えて、最近の動きを書いています。 Module::Build：MakeMakerの後継者を目指して PerlでCPAN形式のモジュールを配布する場合は、Makefile.PLなりBuild.PLなりを モジュール作者が用意して、それがインストールに必要なファイル類を自動生成 するという流れになっています。 既存の雛形を使うと色々ファ
おそらくはそれさえも平凡な日々: ワンライナーでOOなPerlモジュール使うときに、2回もモジュール名を打ち込んでいられるほど人生は長くない件について
ワンライナーでOOなPerlモジュール使うときに、2回もモジュール名を打ち込んでいられるほど人生は長くない件について ランダムな文字列を求めたい時に以下のようなコマンドを打つことがあるが、String::Randomを2回も打ち込んでいられるほど人生は長くはなかった。 % perl -MString::Random -E 'say String::Random->new->randregex("[0-9a-z-A-Z]{12}")' なので、Lというモジュールを書いてみた。 https://github.com/Songmu/p5-L これを使うと上と同様の処理が以下のように書ける。 % perl -ML -E 'say l("String::Random")->new->randregex("[0-9a-zA-Z]{12}")' ただ、lという関数をかますのがダサい感じなので、 % pe
おそらくはそれさえも平凡な日々: 悪いけど正しいかもしれないPHPerになるための10個のTips
流行っているみたいなので書いてみた。かなり独断と偏見に満ちたエントリになっています。決定的な間違いがあったらブクマコメ等で指摘願います。 さて、そもそもPHPとはなんのための言語か。HTMLの延長線上で使える学習コストの低いテンプレート言語であり、多少汚くても良いから、Webアプリケーションを手っ取り早く作るための言語です。 色々なユーザーの声をやたらめったら取り込んでしまったせいで、日本の家電みたいに無駄かつ一貫性のない機能が満載で醜悪なことになっていますが、その辺は気にしないことにしましょう。 ただ、変に多方面の声を取り込んでしまったせいで、妙にお行儀よくなりたがっている部分も多く、使いづらくなっている部分も多々あったりして困りものですが。 まあ、つまりPHPにおいて「良い」ってのはありえないんですよ。とか言ってみたりして。 閑話休題。 エラーレベルは最大にしろ 色々コードが書きづらく
おそらくはそれさえも平凡な日々: 退社と転職と
前のエントリーで社内フレームワークとか言っておきながら、今日が仕事納めで今年いっぱいで現在の職場を退職となりました。 今年の頭には転職とか殆ど考えていなかったのですが、今の会社だとなかなか技術的にスキルアップが難しく、自分も技術的にもうちょっとチャレンジしたいなぁということで、新たなステージを選んだ次第です。退職を考え出したのが6月くらいで8月から活動開始。10月に内定が出て、年内退社の運びとなりました。 今の会社は安定しているし、恐らく一生勤めることも可能なので、周りの友人や前職の友人からは「勿体無い」とか「何で？」とか言われます。私としてもチャレンジだと言うことは分かっているのですが、年齢も30になってしまったので、今後そうそうチャレンジできる機会も少なくなってくるだろうと言うことで転職に踏み切ることにしました。 正直、ここ2年は技術的に学べる人が誰もおらず、逆に私が一番知識的にあると
おそらくはそれさえも平凡な日々: Perlでフィボナッチ数列の高速化とか無名関数の再帰とか
簡単にfibを高速化する方法を読み、おおっと思って、Perlでやってみた。 #!/usr/bin/perl use strict; use warnings; use feature qw/state/; use Benchmark qw/timethese cmpthese/; sub _fib_ret2 { my $n = shift; if ( $n == 1 ){ (1,1); } else { my ( $aa, $bb ) = _fib_ret2($n-1); ($aa+$bb, $aa); } } sub fib_ret2 { (_fib_ret2(shift))[0]; } sub fib_memo { state @cache; my $n = shift; $cache[$n] ||= $n <= 1 ? 1 : fib_memo($n-2) + fib_memo($n
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
