#mozaicfm #7 REST を聞いた
RESTの引力に惹かれたREST人達を、RESTの伝道師たる@yoheiが粛清する話。だったと思う。
APIバージョニングの話を聞きながら、/api/v1/fooじゃなくいっそ/api/v1.2.*/fooとか/api/>=v1.3.4,<v1.4/fooとかだったらどうなるだろう。とか想像した。APIのセマンティックバージョニング。まあマイナーバージョンは必要無いかな。
とはいえ、もともとはURLの設計としてどうかというよりサーバー側をどう実装するかの話だったので、そういう意味ではほぼ無理ゲーな気がする。たとえバージョンごとに別々のサーバーがあったとしても、最終的には永続化レイヤーが問題になるんだろうなあ。
Goのバージョンの話が出てたけど、最近TypeScriptを勉強していて、あの.d.tsもなかなか大変なことになってるなと思った。
伊勢神宮の話が面白かった。昔（多分十年以上前）、どこかで「工場のようなソフトウェア」という話を読んだのを思い出した。もう元ネタは探し出せなかったけど。
PHPUnitでGrowl通知する方法を書いた件
PHPUnitの実行結果をGrowlに通知する方法 - Qiita
事の発端は、去年の年末あたりからRails Tutorialをやっていて、GuardのGrowl通知いいなーと思い始めたことだった
PHPUnitの実行にguardやglupを使うという方法もあったけど、ちょっとした用途には大げさかなと思ったのと、その手のやつはPHPUnitの標準出力をパースして結果を取得しているのがイケてないなー、PHPUnitを拡張するような方法でできないだろうかと思っていた
まず最初にPHPUnit_Framework_TestListenerを思いついたけど、これは個々のTestやTestuSuiteに対して呼び出されるのでちょっと頻度が多すぎる。で、次にprinterClassを見つけた
次にどうやってGrowlに通知する方法、gntpnotifyやgntp-sendといったコマンドを実行させるという方法はあまり好きじゃなかったのでGNTPを実装したモジュールを探したけど、イマイチ良いのが無かったので結局自分でGNTPを実装することにしたんだけどインターフェースを決めきれずに数か月放置
なんやかんやでPackagestにも登録して、Qiitaに投稿しようかなと説明を書き始めたところでphar版PHPUnitでテストしてないことに気が付いて、まさにRebuild: 52: TLDR Driven Development (Naoya Ito)でやっていた「先にREADMEを書く」ことの効果を気づかされることになった
書いたコードはわずかでもリリースするところまでやると色々学ぶことがあるなーと思った。PHPUnitを調べたりComposerを調べたり。あとTravisのMatrixを使ってPHPとPHPUnitの複数のバージョンでテストする方法を試せたのが良かった
マークアップエンジニアが欲しいエディタってこういうの？Bracket Comp to Code
Comp to Code ToolはAdobe Bracketsの拡張で、PSDファイルからフォントや色やテキストの情報を抜き出してCSSやHTMLファイルの編集時に利用できたり、imgタグの編集と連動して画像ファイルの書き出しをしてくれたりするもの、、、じゃないかと思う。
というのもこれ、今Private Betaなので触ったことないのと、僕自身はPhotoshopを全然使ったことないので、これがどれくらいのインパクトがあるものなのか良くわかってないです。個人的にはこれすげーんじゃないのと思ってますが勘違いかもしれません。
なのでまあ3分間ほど動画をご覧ください。
おわかりいただけただろうか。
上のペインでCSSを編集、下のペインでPSDファイルを開いて、PSD側でボタンのレイヤーを選択すると、CSS側でwidth, height, gradientなどを補完してくれる、みたいなことになってます。
この機能は去年のAdobe MAXでもPSD Lensという名前で紹介されていました。こちらの妙にゴージャスな動画も公開されています。少々おっさんがうるさいですが。
あと興味がある方はこちらの紹介記事もどうぞ。
Windowsのフォントレンダリングについて知っておきたいこと
Windowsのフォントについては、そもそも埋め込みビットマップが嫌いとか、特定のフォントの品質が悪いという意見もあるでしょうがそれ以外の話。
2種類のAPI
あまり詳しくはないのですが、Windowsには文字描画のAPIが新旧2種類あります。
このため、文字がどのように見えるかはそのアプリケーションがどちらのAPIを使っているかによって異なります。現状、IE11やFireFox29は新しいAPIを使っていて、Chrome35は古いAPIを使っています（試験運用機能にDirectWriteがあるようですが）。
わかりづらいかもしれませんが、上がChrome、下がFireFox。フォントはMS Pゴシック。300%に拡大してあります。
比較
比較記事など
Font smoothing, anti-aliasing, and sub-pixel rendering - Joel on Software
読めないのでこの辺を参照。本にもなってます。
- 作者: Joel Spolsky,青木靖
- 出版社/メーカー: 翔泳社
- 発売日: 2009/04/09
- メディア: 単行本（ソフトカバー）
- 購入: 12人 クリック: 166回
- この商品を含むブログ (95件) を見る
とはいえ2007年の記事なので、当時とはディスプレイの性能が変わりつつあるとは思いますが。
The Typekit Blog | Type rendering: operating systems
Core Text(Mac)、DirectWrite、GDIの比較記事のようです。
使われているレンダリングエンジン毎にCSSを切り替えるためのJavaScriptのようです。こちらも参照。
MarkdownエディタStackEditのベータ版はシーケンス図やフローチャートが書けるよ
StackEditはブラウザ上で動くMarkdownエディタ。MathJaxで数式を書いたり、LocalStorageに保存したり、DropBoxやGoogleDriveと同期したりもできて、bloggerやtumblrに投稿したりPDFにエクスポートなんかもできるらしい。
そのStackEditが新しいバージョンを作っている。
https://stackedit-beta.herokuapp.com/
目玉っぽいのはUML diagrams
この辺を使っているそうです。
日本語もかける。
但し、ダイアグラムはPDFにはエクスポートできないようだ。それ以外は数式も日本語も普通にPDFになっててびっくりするんだけど。
（5/8 タイトル修正）
PostgreSQL BuildFarmとOSSの継続的インテグレーション
急に思い出したので書いてみる。
PostgreSQL BuildFarmというのは、チェックアウトしてビルドしてテストして結果をサーバーに報告するというのを自動でやってくれる仕組み。もちろんユーザー登録をすれば誰でも参加できるので、いろんな人のいろんな環境でのビルド結果が日夜このサーバーに報告されている。
Statusを見るとLinuxやBSDはもちろん、Windows、Solaris、HP-UXなどでもビルドされていることがわかる。
要するにCIなんだけど。とはいえ10年くらい前からあるので、最初のこれを知ったときは僕はCIなんて言葉は知らなかった（逆にCIを知った時にああアレのことかと思った）。
特にインフラ層よりのOSSでは、毎回クリーンで同じ環境でビルドするよりもこういったさまざまな環境でビルドできる仕組みの方がよいのかもしれない。
Java Exception Handlingメモ
Amazonに勧められたので2013年の8月に買ったんだけど、なんかamazon.co.jpに売ってないなあ。
- Amazon.com: Java Exception Handling eBook: Jakob Jenkov: Kindle Store
- http://jenkov.com/books/java-exception-handling/index.html
Javaに特化した話題もあれば、より一般的な話題もある。心に残った一節。
Designing exception handling for an application means deciding how the application should react to errors to assure the application stays healthly.
(Exception Handling Helps Preserve Application Health)
（例外処理を設計するということは、アプリケーションがその健全性を保証するために、 エラーに対してどのように反応すべきかを決めることを意味する）
例外を投げる側が、何が起こったという情報を収集する一方で、例外をキャッチする側は、 その例外に対してどう反応すべきかを決めなければいけない。 例えばアプリケーションを終了するのか、リクエストを中断するのか、リトライするのか。 他のシステムや人間に通知するのか、等々。
How an application should react to errors depends on what state it is in.
(Application States)
- not running
- initializing
- running
- temporarily unavailable
- shutting down
例えばinitializingでエラーが発生したらshutting downに移行すべきだが、 runningでエラーが出た場合は、その処理だけを中断して継続可能か、shutting downに移行するか、temporarily unavailableに移行するか（一時的なリソース不足）。
The origin of an error influences how the application can react to them.
(Error origins)
- Client Errors
- Service Errors
- Internal Errors
- (Temporary Internal Errors)
例えば、Service Errors（アプリケーションが利用する外部のサービスエラー） であれば、リトライするか、あるいは別のサーバーにリクエストするといった対応もありえる。
As you can see, determining the true origin of an error may not always be possible at the point where the error is detected.
そしてそれらは、例外を検出した箇所で決定できるとは限らない（複数の箇所から呼び出される処理内で検出された場合のように）。適切な文脈を決定するために、例外を上位に伝播する必要がある。
