けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

はじめに

ここ最近は花粉症の薬の副作用で寝てしまうことが多くなっており、かなりつらい日々を過ごしております。そろそろ真剣に専門医のお世話になろうかと考えています。

事の発端

2010年10月ごろに買ったiMacは、僕が保有しているマシンの中でもかなり信頼しているマシンで、動画作成からプログラミングまで幅広くこなしておりました。

ただ、最近はどうも動作に倦怠感を感じるようになりました。おそらくはiMac以外のマシン(VAIO XやVAIO Pro)がSSDになったことで相対的に性能が下がったように感じられるようになったのが原因だと思います。
それでもCPUはSandyBridge世代ながら3.2GHzのCPUだったり、メモリはマザーボード限界の16GBまで増設しているので、まだこんなもんじゃないだろう、ということで、やきもきしておりました。

そんなある日、作業中に聞いたこともない「バリバリバリ」という異音を発しました。ファンが何かに干渉しているようです。これは良くないので電源を落とし、かねてより気になっていた内部のホコリ掃除を行うことにしました。

iMac Mid 2010 SSD換装

異音の原因は目視できず。というかiMacのファン部分は結構深い位置にあるので、マザーボードなどをはずさないとアクセスできない、でもかなり厳重にビス止めされていて、戻ってこれなくなるのが怖かったので諦めました。
ホコリは想像よりも酷くなかったですが、エアダスターと掃除機であらかたホコリを片付けて組み直しました。

iMac Mid 2010 SSD換装

その時にふとHDDドライブが目に入りました。「そういえばHDDドライブをSSDに入れ替えるとパフォーマンス良くなるんだっけ」と思いつつiMacのガラスを付けました。

それからは異音もなく快適に使っていたのですが、増税前ということもあり、SSD換装したiMacはいったいどのくらいのスペック・モンスターになるのか興味深かったのと、あとTwitterのわるいひとが耳元で囁いたのです。。。

SSD換装

そんなわけで購入しました。

ちなみにですが(というか換装作業やるまで気が付かなかったのだけど)、iMac Mid 2010はSATA2です。
上記SSDはSATA3接続でのRead 500MB/sというカタログ値を出しているので、完全にオーバースペックなSSDです本当に(ry
そんなわけで性能は理論値のおよそ半分くらいしか出ません。。。
(ベンチマーク結果ではHDDとは比較にならないくらい速度が出ているので、まぁ良いのですが、、、)

さて、早速届いたSSDを開けてみると、「軽い!薄い!小さい!」。

iMac Mid 2010 SSD換装

近くにあったペットボトルと比較しても、この小ささがお分かりいただけるかと。

HDDは鉄の塊なので、「よっこらせ」と持ち上げる感覚があります。SSDもHDDと似たような機能を提供するので、けっこうずっしりとしているのかと思ったら、もう軽々と持てるので驚きです。

iMac Mid 2010 SSD換装

iMac Mid 2010 SSD換装

こんな感じで3.5インチHDDのフォルムを再現するゲタを付けてやって設置しました。

ネジがトルクスドライバーを必要としていたのですが、HDDドライブを止めていたネジ穴のサイズが持っていたトルクスネジと微妙に合わず、仕方なく手持ちのマイナスドライバーで作業したり(そしてドライバーの先端がへし折れたり。。。)苦労しつつ、なんとか作業完了となりました。

ひとまず仮組みした後、予め用意しておいたMavericksのインストールUSBを差し込んで、SSDを初期化後OSインストールして作業完了です。

(ただ、この後に「Trim命令の有効化」と「HDD冷却用ファンの回転速度を下限値に設定」という作業を行っています。詳しくはググってね)

実測結果

実行環境:
OS: OS X 10.9.2
CPU: 3.6 GHz Intel Core i5
RAM: 16 GB 1333 MHz DDR3

HDD(Apple純正ですが、ラベル見たらHitachiって書いてあった)

Xbench 実行結果(HDD)

まぁこんなもんだと思います。。。
ReadよりWriteのほうが早いのがちょっと気になりますね。。。やっぱ何かおかしかったんでしょうか?それともこれが正常?

SSD (CFD)

Xbench 実行結果(SSD)

さすがSSD。Sequentialの値もそうですが、Randomの値が100倍以上違うケースもあり、SSDすげー!という感想です。
ただ、SATA2の性能限界にあたっているので、もしiMacがSATA3を搭載していたら、と思うと、まだこの値が伸びるということですね。。。

まとめ

SSD換装して(OSもクリーンインストールして)iMacの挙動が2010年当時の体感値に近づいた印象です。ただ、今度はCPUの性能限界が感じられるようになってきました。。。まぁCPUの換装はやらないかな。。。

はじめに

そう言えば書くの忘れてた。。。

あと思ったよりもDL数伸びてないので宣伝ついでに。

Muzei 飯テロ.in Plugin つくりました

@masawada さん達のチームが開発している飯テロ.inというサービスが有ります。

こちらのサービスのAPIにタダ乗りさせてもらう形で、「Android端末の壁紙を周期的に変更するアプリ」を作成しました。
定期的に飯テロ画像を取得し、壁紙にします。昼飯時にAndroid端末を見て不意の飯テロにもだえ苦しむ。合言葉は「てのひらに飯テロを。」。

このプラグインはMuzeiというアプリのプラグインとして動作します。

開発背景

Muzei

このアプリ(プラグイン)は、まずMuzeiというアプリのプラグインとして動作します。

Muzeiを一目見て、「おっこれでアプリ作ってみたい!」と思いました。
MuzeiのAPIおよびソースコードは公開されており、誰でも自由に使うことが出来ます。そしてAPIの使い勝手も良いので、非常に簡単にアプリを書くことが出来ました。
また、「単なる壁紙チェンジャー」としてではなく、そのデザインも非常によく出来ており、常用するに耐えられるおしゃれ感を勝手に出してくれたりします。
アプリ制作の初学者が最初に飛びついても良さそうな気はしますが、もしかすると予期せぬ複雑さを持ってるかもなので、要検証というところではあります。

mstr.in

もうひとつ、飯テロ.inの独創性も、僕がアプリ作ってみたい!というハートを揺さぶりました。
こういうサービスがずっと欲しかったのです。「メシ画像を投稿する」これだけですが、非常に良い感じです。このくらいのシンプルさが丁度よい。

まとめ

「Muzei 飯テロ.in Plugin」、是非使ってみてください。僕も使ってます。

ちなみにこのアプリはgithubでソースコードを公開しています。gradleの設定とか頑張った気がします。

はじめに

人生24年目にして人生の迷走期に入っています。誰か僕を導いて下さい(

#libcodingso at 2nd Infinite

numaさん主催の大人気イベント「Live Coding de Night」の2回目に参加してきました。

前回は事故ったので、今回は徹底的にミスらないように対策しました。

  • 事前にコードをタイピングして10分くらいで終わることを確認した
  • ↑で書いたコードを紙で印刷してカンペにした
  • 本番で使うPCでも入念にチェックした

そんなわけで、前回のリベンジを果たすべく頑張りました。

イベントの感想

凄く楽しかったです(小学生並の感想)

numaさん、僕を入れて6人がライブコーディングしました。皆さん個性的だったのと、結構Vim派が多くて、IDEに頼るコーディングをしていた俺はちょっとVim頑張らないとなーと思いました。。

あと、僕を除くと全員が林檎のロゴが付いたPCを操作していたのをMCが指摘していた中、僕だけが赤いVAIOで珍しがられるという珍事があったりw

終了後の打ち上げも非常に面白い話が聞けたり、店員がノリノリだったりで面白かったw

つくったもの

WebAudio APIでVisualizerを作成しました。

本番で伝え忘れていたのですが、「Visualizerは、つくれる!」ということを説明したかったのです。そりゃ確かに波形の意味とか数学的センスとか音響の知識があるともっと色んな事ができるんですが、これらの意味を知らなくても何となくリアルワールドの状況を収集してデジタルに可視化することは簡単にできるんだぜ!ということを示したかった。

参考にしたサンプルコードがあって、それは非常に良く出来ている(そしてうまくカプセル化されててグローバル汚染などにも配慮されている)のですが、意味がいまいち分かりづらかったので、べた書きできるように再解釈してみました。

追記:
書き忘れてたw 上記リンクで2つのリンクがあるのですが、ひとつはライブコーディングでつくったもの(に解説をつけたもの)。もうひとつは、ライブコーディングしたものを時間かけてD3.jsなどを使うとこういうのも作れるよ、というサンプルです。ちょっとD3.jsがクセ強くてアレですが、色々とできそうです。

結果

当日に順番が決まって(抽選するScalaプログラムをライブコーディングするnumaさんスゲーって思ったマジで)、一番最後の登壇で少し押し気味だったのですが、何とか時間内にやるべきことをやれて良かったです!

ただあんまりコードの解説を入れることが出来なかったのと、できればマイクではなくてLINE入力で直接DJブースから音声引き込みできれば良かったかなぁ、と思いました。機材買うか。。。

余談

WebStorm使ったんですがWebAudio APIってドラフトだからうまく補完してくれないんですよね。。。それがちょっとつらかった。

今後

とりあえずネタ切れなので、次からは聞く側に廻りたいっすw

あとLive Coding de Nightでは皆様のご登壇・ご参加をお待ちしております。

はじめに

ぬまさん ( @numa08 )から光栄なことにお誘いを受けまして、Live Coding de Night というイベントに参加させて頂きました。

僕はAngularJSを使ったライブコーディングをすることにしたのですが、非常に残念な感じになってしまったというお話しです。

Live Coding de Night とは

渋谷にある 21cafe さんにて開催された、ぬまさん主催のライブコーディングのイベントです。
プロジェクターとマイクがあればパフォーマンスができるのですが、そこにDJブースが組まれていたりと非常にゴージャスな感じでした。また会場が非常にオシャレでびっくりしました。さすが渋谷。

僕以外にも色んな方のいろんなジャンルのライブコーディングが行われました。個人的にはmikutterのプラグインはつくれる!というところが印象に残っています。

お前はなにをやらかしたのか

AngularJSの発表をしましたが、色々あって時間ギリギリのところで事前に用意していたリポジトリを使って緊急回避する事態になってしまいました。無念である。

以下、言い訳じみたことを書きますと。。。

プロジェクターに繋いだら画面サイズが小さくなってしまった

VAIO Proは1920x1080のメインディスプレイがあるのですが、プロジェクタに繋いでミラーリングに設定した途端、 1024x768サイズになってしまい、情報量が激減してしまいました。。ちょっと予想外で調子狂ってしまった。。。

テンパって ng-src の使い方を間違えた

ng-srcというAngularのDirectiveがあるのですが、これは {{ variable }} と書かないと動かないのです。この括弧を付け忘れて爆死しました。。。つらい。。。

そもそも練習量と本番の想定が圧倒的に足りなかった

まず普段のプレゼン程度の練習だと死にます。最低でも普段の3倍は練習しておきたい。

あと、ライブコーディングは緊張とか予期せぬトラブルとか諸々あって、練習時の10%くらいしか実力を発揮できない感があります。。。そのあたり加味して頑張らないと駄目ですね。。。

まとめ

ライブコーディングの経験があまりなかったですが非常に楽しかったです。また良い経験になりました!

しかし自分のパフォーマンスにはまったく納得できてないので、もし次回も呼んで頂けるのであればリベンジしたいです。。。

ソースコードとかスライドとか

はじめに

タイトルはナウでヤングなネットサーファーにバカウケする感じにしてみた。

一応先に言い訳すると、デザインパターンなどのソフトウェア概念については自分の知識がまだまだ乏しくて学習段階なので、間違ってることがあります。そのときはご助言お願いします><;

MVC, MVVM, MVW, .....

世の中にはMVC(モデル,ビュー,コントローラー)と呼ばれる設計・実装するための技法が存在する。小規模なアプリであればいざ知らず、大規模なアプリであるとコードの複雑性が上がるので、それをちゃんと体系づくって見通しよくしたい。それらを開発者共通の認識としておけば色々都合が良いのですね。

ただ、MVCそのものの説明については何回読んでも難解でございます(ぬまさんリスペクト)

  • ModelなるものとViewなるものとControllerなるものがある・・・?
  • Viewはなんだか描画するものっぽい・・・?
  • Modelはなんだか描画したりするのに使うデータっぽい・・・?
    • じゃあデータベースにあるデータはModelだよね・・・?
  • ControllerはModelとViewを橋渡しする・・・?

だいたいこの程度はわかる気がしますが、上記の認識のままだと、実際に開発すると綺麗に3分割できない事象がたくさん出てきます(主に悩むのはModelかControllerなので2分割かな?)。というか僕がそうでした。

例えば、データをフィルタリング(条件にマッチしたデータだけ返す)するロジックはどこに書く?Viewではないことは確かですが、ControllerかModelか・・・?ModelはしかしながらデータなんだからControllerかな?

_人人人人人人人人人_
> Fat Controller <
 ̄Y^Y^Y^Y^Y^Y^Y^Y ̄

世知辛い世の中です。良かれと思って考えて挿入したコードが、「これじゃコントローラーが肥大化するよー」と言われるのですから。つらい。しかしそう云う人も悪意があるわけではなくて、押し込められたコードは可読性を下げます。なのでちゃんとしたいということです。

ところでこの例(データをフィルタリングするロジック)だと、どこに何をすればいいのか?ということですが。。。言語やフレームワークの事情が色々あるので一概には言えないですが、Javaだったらモデル層に DataAdapter クラスを作って List を返すようにするのがいいのかな、とふと思いました。が、いやしかし List を継承したクラスを書いてそこにロジックを書くほうが良いのだろうか、とか色々思うところはあります。あと「データ」がSQLiteにあるなら直接クエリ叩いて得たものを返せばいいわけで、結局やはり一概には言えないのかも。助けて!

まぁそれはそれとして。

MV○についての長年のモヤが晴れるたった1つのスライド

最近はそういうもやもやをずっと抱えていたのですが、Twitterで流れてきた以下のスライドを見てすごく腑に落ちました。

このスライドは(Windowsのソフトウェア開発で提唱されている)MVVMパターンについて書かれていますが、MVVMについての説明がこのスライドの本旨ではなくて、

MVVMのよく云われる説明だけだとMVCとの違いがわからないし何も説明できてない、ちゃんと理解しないとMVVMの旨味を享受できないからちゃんと基礎部分から説明するね(そもそもなんでMVCに代表されるパターンが必要なのかも)

という感じだと僕は理解しました。

これを読んでからさっきのWikipediaを読んでみると、あんま大したこと書いてないという印象です。だってMVCパターンは各アーキテクチャの都合を叶えるためにあるのだから、MVCそのものの説明はかなり抽象的にならざるを得ない。

また、このスライドは結局MVVMを強制しているわけでもない感じです(わかったうえで型を崩すことについても言及している)。「MV○使え!」と強制されるより、「MV○使わなくてもいいけど使ったらこういう利点あるよ〜」のほうが心理的に受け入れやすい感じがするのは僕だけではないはず・・・。たぶん。

まとめ

どこかしらから怒られそうな感じもしないでもないですが、特定の事情を考慮しないMVCパターンのあるべき論というのは不毛な感じがしました。モデルとコントローラが言語やフレームワークのわがままをうまくやるためのアイデアであるなら、その言語やフレームワークでのあるべき論を追求することは出来ても、抽象概念のMVCパターンには関係のない感じがします。(だからAngularJSのMVWパターンがこうあるべきだ、は成立しえても、MVCとはこうあるべきだ、についてはフレームワークや言語の事情があるので話がオチない)

まぁそんなわけで、まだまだ勉強せねばならないですね。