愛と勇気と缶ビール

ふしぎとぼくらはなにをしたらよいか

FT142A (priori2 3G) は安かろう悪かろう

iPhone (もう、いくつだったか忘れた)からNexus5に持ち替えて、Nexus5がぶっ壊れたので、freetelのpriori2に変えていた。

Nexus5を使っていた時は「この端末いいぜ!」みたいなエントリーを書いたり人に勧めたりしていたけど、すまんあれはウソじゃったウソとまでは言わないが、買った当初はよくてもAndroid5.0にしてから極端にバッテリーの持ちが悪くなり、なんだか微妙な端末であった。

で、「もうスマホに金を掛けることが既にダサい。お、10000円で買えるのがあるじゃないか」と思ってpriori2の3Gを買ったのだが、これはこれでケチりすぎた。

スマホとしての機能にそこまで問題があるわけではないが、やはりタッチ感度が悪いのと、LTEが使えないのは流石にやりすぎだ。今は反省している。まあ、スマホが欲しい!と泣く子に買い与える用途なんかにはいいんじゃないでしょうか。え、何?iPhoneがいいって?iPhoneは子供が持つと乳首が伸びるのよ!

しばらくはこのままいくけど、どこかのタイミングで端末を安く買える格安スマホ業者(例えば、楽天とか)にSIMごと引っ越そうかと思っている。

「Javaパフォーマンス」はいい本だった

Javaパフォーマンス

Javaパフォーマンス

とても馬鹿っぽいタイトルになってしまったが、気にしないのである。

だいたいの内容としては、

  • パフォーマンス・チューニングに関する一般論
  • Java付属のモニタリングツール(jstatとかあれとかこれとか)
  • JITコンパイル周りについて
  • GCについて

等々がいい感じに、過不足なく書いてある。

既にJava10年選手で、GCのチューニングもしたことあるし、JVMとは戦友みたいなものだ…みたいな人にはおそらく必要ないだろうが、JVM周りのあれやらこれやらを知らない人(つまり僕のような)がとりあえずJava始めてみたときに、頭の中に見取り図を書くためにはこの本を読むのが適切そうだ。

以前にも同じようなことを書いたけど、ベースとなる知識をまとめて仕入れるにはインターネットで情報の波をかき分けかき分け調べるより書籍の方が効率がよい。もちろん、よい書籍がある場合の話。

公私ともにToDo管理にTrelloを使うようになった

trello.com

これまでToDo管理を色々なツールで行っていたけど、Trelloに落ち着きそうな気配。

Trelloは本来、小規模なチームで使うことを意図したツールだと思うのだけど、お一人様でも十分使える。 何より、めんどくさいこと考えなくていい。色々な操作が直感的なので使うために何も覚えなくていい。という点が気にいっている。

以下、仕事用のToDo管理ツールとして便利な点

  • 優先度の変更や、タスクの終了 (= 僕の場合はどちらもリスト間の移動で表現している) がドラッグ&ドロップで出来てラク
  • 各タスクにコメントが付けられるので、進行中のタスクの付随情報(ticketとか、調べ物をした結果のURLとか)が管理しやすい

ほっとくとChromeのタブがどんどん増えて、小さくなっていく…というのはChromeユーザーのエンジニアなら誰しも経験したことがあると思う。 何かを調べながら作業している時のタブはあくまで「今の調べ物」にフォーカスしたものなので、一々ブックマークするほどでもないし(ブックマークを頑張って管理するのは人生における大いなる無駄の一つだ)、 また閉じてしまうと後から探すが面倒なので、ついつい開きっぱにしてしまう。そうするとゴミがどんどん溜まってタブが小さくなる以下略なのだが、このうざったらしい現象がいささか緩和される。 (それでもやっぱりある程度は開いたままキープしてしまうんだけども。)

微妙に活用しきれていないが、プライベートでは「家の中で切れそうな生活必需品ボード」を奥さんと共有している。「買い置き有り」「買い置きないけどまだ大丈夫」「ピンチ」みたいなリストがあり「米」「塩」「歯磨き粉」などのタスクがそれらのリスト間を移動していくイメージである。またどうやら、奥さんは個人のタスク管理にも使っているようである。

ドラッグ&ドロップが重要な機能に割り当てられている関係上、モバイルアプリが若干使いにくいが、僕はモバイル上ではあれこれ頑張らないことにしているのであまり関係ない。

JavaScriptでCSVを生成するのはやめたほうがいい

もう2015年だから別にいけるんじゃね?出したいのはクライアントサイドで表示してるデータだし。と思ったけど、

  • 例によって古いIE (9以下かな) でめんどくさい
  • SafariだとHTMLAnchorElementのdownload attributeが無効 (http://caniuse.com/#feat=download) で、"unknown" ってファイル名になったりする
  • 文字コード周りがめんどくさい

…といった事情があるため、msSaveBlobやらcreateObjectURLと戯れるのは諦めて、おとなしくサーバサイドで生成してContent-Dispositionつけて返しましょう。

「俺ならクロスブラウザな実装が出来る!やってやる!」と思ったそこのアナタ。それは、この場合においては無用な努力です。

Marionette.jsを使ってみている

最近Marionette.jsを使ってみている。

時は未だにJSフレームワーク大戦争時代、なんでMarionetteなんですか?って話なんだけども、

  • 作ってるのが管理画面に毛が生えたようなものなので、別にそんなパフォーマンスとか考えなくていい
  • だから別にReactとか、DOM周りに工夫が入ってるやつじゃなくてよい
  • 深遠な理由によりIE8に対応できるようにしておく必要があった
    • この時点でいくつかのフレームワークは除外される
    • Backbone系列には古いブラウザでも動きそうな謎の安心感がある
  • Angularは個人で使ってみて好きじゃなかったので除外

この辺の理由です。ゴリゴリって訳じゃないんだけど、ちょっとリッチクライアント?的なものだからBackbone + Marionetteくらいの塩梅がええかなー、と。

実際、真面目に使ってみたらBackboneとMarionette、特に前者は老舗だけあって中々良く出来てるなー、と思った。それだけだと何とも出来ない部分は多いけど、「自分はここまではやりまっせ」という線引きは少なくともはっきりしている。

別にこれは比較でも何でもないので、他のは知らんけどな。

フレームワークオタクになる時間もなる気もないので、あんまり最近のナウいやつは追ってないんだけども、今後の流れとして

  • 全体としてコンポーネント(modelとviewとロジックをくっつけて一つのまとまりを作って再利用する、その名前は何でもいいけど)志向になっている
  • それらの通信はevent的な何かで行うことになるのだろう(多分)
    • ここは最終何でもいいんだけど、event的なものが一番おさまりがいい気がしている。単にDOM Eventsが念頭にあるからだけど。

というイメージを持っている。

何らかのフレームワークに乗って気分良く作っていたとしても「Bootstrapのmodalを出さんといかん(ヒエー)」「XHRでPOSTした結果を何らか通知するようなUIがいる(ウヒョー)」みたいな要件は一杯あり、それらを全て気持よくカバーするフレームワークなんてものはおそらく存在しないので、実際の開発ではどうしてもフレームワークからはみ出した書き方をせざるを得ないことが多い。

なので、なんというか、「出来るだけはみ出しすぎないように書きつつ」「まあしょうがないよね、そういうもんだし」という気分でコードを書いている。

フレームワークの上に乗って、気分よく綺麗に書けるのはToDoアプリくらいなもんだ。