テストについての個人の雑感 - tokuhirom's blog
テストについての個人の雑感です。ここでいうテストってのは、なんかいわゆる開発をドライブするための開発者用のテストについてであって、品質の保証とかについては一切かんがえてません。 ざっくりいうと 「テストを書いた方が効率的に開発がすすむ場合にはテストを書く」 テストに対する認識 ソフトウェアにたいするテスト というものはソフトウェアそのものの価値には関係しない。 なので、テストにたいしてかけるコストなど、すくなければすくないほど良いにきまっておる。 Open Source Software のテストについて オープンソースソフトウェアの場合、送られてきた patch の品質を travis ci で確認したい、っていう要件とか、手元の環境以外での動作確認などを行いたいので、それなりにテストを書く必要がある。 まして、僕が OSS として公開しているものはライブラリが多い。ライブラリは一般にテ
Web Application の validation はどのレイヤーでかけるべきか - tokuhirom's blog
数年前にも同じことかいた気がするけど、最近の状況にあわせてかいてみる。 途中で面倒になってきて説明が雑になっている点をご容赦ください。 言いたいことは「結局、昔はサーバサイドで懇切丁寧なエラーメッセージを出すためにModelではなくControllerでバリデーションに関する知識が必要だったけど 今はJavaScriptでやるから不要だよね１１１」ってことです。 この表題は、よく話題にあがるところなのだが、理想論としては Model, Controller, Client side のいずれにおいてもきっちりと validation を行うことがのぞましい。 しかし、実際にはなかなか面倒である。ということで、どこをはぶくかというと Controller における Validation であろう。 ユーザーに対する親切なメッセージは JS の側でだすのが理想的。model の validat
Web アプリケーションのロジックを手続きとして実装する話 - tokuhirom's blog
yusukebe のObject::Containerを応用したModel呼び出し のあたりをよんでの感想ですが。 一時期 Catalyst の影響もあって、モデルのインスタンスつくったりなんだりもしていたのですが、結局のところウェブアプリケーションにおいては、モデルをがんばってオブジェクトにモデリングしようとか考えるよりも、つまり手続として扱った方がしっくりくるな、ということに自分の中でなりまして、最近は、ごちゃごちゃ考えるのをやめて、手続きとして実装しています。 yusukebe の例をベースにはなしをすすめると、コントローラを以下のようにかきます。 package MyApp::Web::Controller::Root; use Mojo::Base 'Mojolicious::Controller'; use MyApp::M::Entry; sub index { my $se
最速な JavaScript のリファレンスマニュアルサイトをつくった - tokuhirom's blog
JavaScript のリファレンスマニュアルといえば MDN(Mozilla Developers Network) が有名ですが、MDN の資料は探索がめんどくさいし、表示が遅いということで使い勝手がわるいという問題がありました。 そこで、jQuery のリファレンスマニュアルサイトとして有名な jqapi.com とおなじよような使い勝手のサイトがあったらいいのになーとおもいました。 なので、つくりました。 サイト自体はすべて static なデータで構成されているので、github からデータを取得すれば、イントラや自分のマシン内で閲覧することも可能となっています。 なお IE での動作確認はしていないので、うまくうごかない場合は pull-req してください。
node.js で人気のあるライブラリ10選 - tokuhirom's blog
node.js というか npm で依存されているライブラリの上位10個ぐらいがどういうものがはいっているのかをまとめます! 具体的には serach.npmjs.org の Most depends on にのっているリストに註釈をつけただけです! http://search.npmjs.org/ 1位 underscore.js 392個http://search.npmjs.org/#/underscore クライアントサイド JS で人気のたかいユーティリティーライブラリの underscore.js が堂々の第１位。 クライアントサイドでつかってるからそのままつかってる人が多いのかな、とおもっています。
Node.js で重い処理をしてしまったときにタイムアウトするの法 - tokuhirom's blog
(この記事は Node.js アドベントカレンダー不参加記事です) チャットサーバー的な使い方とか意外とみんな興味なくて、普通のウェブアプリケーションなどをかく、という用途にちょっと node.js がつかえたらいいのにな、とおもっている人がおおいようにかんじています。Node.js が人気なのは、v8 をうまくパッケージングしているのが node.js ぐらいで、そして v8 をうまくパッケージングするのが結構めんどくさいから、というところが大きいのです。ぶっちゃけ node.js が〜 とさわいでる人のうち8割は I/O multiplexing だからとかそういう理由で支持しているわけではなかったりするのです(偏見)。 さて、普通の web application のようなものを書こうとしたときに Node.js って基本シングルスレッドだし、なんかうっかり重い処理したときにどうした
モダンな Perl の開発環境の構築方法 - tokuhirom's blog
一般的な OSX 環境および Linux 環境における、モダンな Perl 開発環境の構築方法についてまとめてみたよ。 perlbrew のインストールperlbrew をつかうことにより、簡単に最新版の Perl5 を利用することができるようになる。 perlbrew をいれる。% curl -L http://xrl.us/perlbrew | perl - install % ~/perl5/perlbrew/bin/perlbrew init ~/.bashrc (または ~/.zshrc)に source ~/perl5/perlbrew/etc/bashrc を追記。あたらしいシェルをたちあげる。最新版の perl をインストールする。% perlbrew install perl-5.12.1 % perlbrew switch perl-5.12.1 ここまできたら、she
tokuhirom blog
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
