2016年12月30日金曜日

AirPodsは落ちそうで落ちない、しかし...

AirPods

AirPods買いました。
Appleのサイトで出荷日が「4週」になっていて(この記事を書いている時点では6週に延びてます)、てっきり年明けに届くのかと思っていたら、12月25日に届きました。実質10日。そんなもん?
というわけで2、3日使ってみて、いろいろ思うところがあったので、レビュー記事なんかを書いてみたいと思います。

まず、私のiPhoneは7じゃありません。6です。なので、ヘッドホンジャックがあります。
ではなぜAirPodsを買ったのか?
それはワイヤレスが欲しかったから。

私がiPhoneでイヤホンを使うのは通勤(電車)のときです。これは大半の人がそうなんじゃないかと思います。
ではそのときiPhoneをどこに入れて(しまって)ますか?
もしくは「手に持ってる」という人もおられるでしょうが、私はいつもジーンズのポケット(ケツポッケ)に入れてます(ちなみに私服通勤です)。
有線のイヤホンを使うと、お尻から肩付近まで線がビヨーンと伸びた状態になっていて、そこから左右の耳に分岐するわけですが、歩いているとだんだんイヤホンが下に引っ張られてくるんですよね。
それが不快で、線をぐいっと上に引っ張って、肩付近でたるむような状態にするんですが、またしばらくすると下にずり落ちて引っ張られる。この繰り返し。
これがホント嫌で、いつかイイ感じのワイヤレス出たら買ったろって思ってました。
その点に関して言えばAirPods最高です。もうiPhoneをポケットに入れたまま、下に引っ張られることもない。

音質について

AirPodsの音質については他のサイトで専門家の方がレビューされていますので、そちらを参考にしてください。
音質に拘りがないなんてことは全くありませんが、そもそも私はAirPodsに音質を求めていません。これは別にAirPodsの音質が悪いという意味ではありません。
前述のとおり私がAirPodsを使うのは通勤時なので、電車に乗れば走行音がうるさいし、駅までの徒歩移動にしても車の騒音に晒されています。
そんなガヤガヤした中で音質を求めてもあまり意味がないんですよね。

耳から落ちない?

AirPodsで一番話題になることが多い「落ちないのか」問題ですが、これは後述の不満点と関係があるんですが、意図して落とそうとしない限りは「落ちない」です。
ただ、厳密には「落ちない」というより「落ちそうで落ちない」というのが正しい表現です。
問題はこの「落ちそう」という感覚にあります。
落ちそうかどうかは人(耳)と状況により変わりますが、私の場合は歩いていると「落ちそう」という感覚があり、そこに気を取られてしまうことが難点です。
「落ちそう」と感じるたびにイヤホンをつけ直すんですが、これでは有線で下に引っ張られるのを直していたときと本質的に変わっていません。
なんでこんなことになるんでしょう。

不満点

理由は明確です。AirPodsのイヤーピースが私の耳にフィットしないからです。これは個人差なのでどうしようもない。
最初、イヤーピースにカバーをつけてみようかと思ったんですが、カバーがAirPodsの充電器に引っかかってしまって、毎回取り外さなければなりません。
AirPodsは裸のままで(そのままで)使えということなんでしょう。

実は私は有線のイヤホンはSONYのインナーイヤーを使ってました。シリコンゴムみたいのを耳にズボっと入れるやつです。
あれは何が良いかって、シリコンの柔軟性が耳の形状の違いを吸収してくれるので、こんな私の耳にもぴったりフィットするんですよね。
ぴったりフィットすると「落ちそう」という感覚はほぼ無くなりますし、遮音性が高まって良く聞こえます。
AirPodsは「落ちそう」という感覚があるときは、同時にイヤーピースと耳の間に隙間が生じている状態なので、外部の騒音が入ってきてしまい、結果的に音量を上げる必要が出てきます。
音量を上げれば音漏れのリスクも上がるわけで。
AirPodsがインナーイヤータイプだったら完璧なのに...そう思わずにはおれません。

AirPodsのイヤーピースの形状はEarPodsと同じようです。もしEarPodsを使っていてフィット感に問題がないのであれば、AirPodsを買っても問題はないでしょう。

AirPodsは音質よりもフィット感が大事です。

2015年12月13日日曜日

パイチャートのSVG仕立て 〜アニメーションを添えて〜

Internet Explorer 50.86% Chrome 31.12% Firefox 11.28% Safari 5.01% Opera 1.28% other 0.45%
2015年10月の世界ブラウザシェア
出典: https://www.netmarketshare.com/

これはSVG Advent Calendar 2015の13日目の記事です。

お仕事でも個人的なものでも構いませんが、ウェブサイトにグラフを表示したいと思ったこと、またはそういう要望を受けたことはありませんか?
私はありまます。ちょうど今もそうだったりします。まぁ、どちらもお仕事でなんですけど。
数字をビジュアル的に見せられると中身のうすっぺらいプレゼンでも妙に説得力があったりしますよね。

ウェブサイトにグラフを表示する手段のひとつとしてSVGがあります。Retinaなどの高密度ディスプレイでもキレイに表示でき、なおかつJavaScriptからグリグリ動かすことができる、優れものです。
ここでは数あるグラフの中からパイチャート(円グラフ)に絞って、最初にこれをライブラリを使わずスクラッチで描く方法をご紹介します。お題目は冒頭に示した2015年10月の世界ブラウザシェア。これをつくります。
後半ではこのパイチャートにアニメーションを付けて見栄えを良くしてみます。
対象ブラウザはChrome、Firefox、Safari、Operaの各最新版とIE9以上とします。

この記事で扱うこと

  • SVGをhtmlにインラインで書く方法
  • SVGをJavaScriptで書く方法
  • SVGをアニメーションさせる方法

この記事で扱わないこと

  • グラフライブラリの使い方
  • ブログ書いたの1年半ぶりとかいう、この体たらくについて

SVGで円を描いてみよう

まずは肩ならしに円を描いてみましょう。
SVGには基本的な図形を描くための要素が用意されています。円はcircle要素を使って簡単に描くことができます。
具体的にはこんな感じです。

SVGタグについているxmlnsやversionは省略可能です。widthとheightはSVG領域のサイズですね。
この中にcircle要素を定義します。cxとcyは円の中心座標です。SVG領域が300px*300pxですので、この場合はちょうど領域の中心でもあります。rは円の半径、fillは円を塗りつぶす色です。
ちなみに3行目はラベル要素です。
このスニペットをhtmlに貼り付けてブラウザで開くと、以下のように描画されます。

Internet Explorer 100%
2015年10月の世界ブラウザシェア
出典: https://www.netmarketshare.com/

このように、円を描くのは非常に簡単です。
ちなみに15年ぐらい前に実際にこのグラフにかなり近い状況がありましたけど(笑)、あえてこんなラベルをつけたのには意味があります。circle要素では、今回のお題目であるパイチャートは描けないのです。半円さえも描けません。

SVGで円弧を描いてみよう

パイチャートを描くには角度を指定できる円弧(アーク)が必要になってきます。

安心してください、円弧はarc要素を使って簡単に描くことが...できませんよ!
SVGには円弧を描く要素は提供されていません。arc要素はウソです。

SVGにはpathという、任意の図形を描くための汎用要素があります。円弧はそれを使って描くしかありません。
こんな感じです。

2行目でpath要素を使っています。
どうでしょう、安心なんか、できないですね!パッと見では全然意味が分からない。
ちなみに実際に表示させてみるとこんな感じになります。

Internet Explorer 50.86%
2015年10月の世界ブラウザシェア(IEのみ)
出典: https://www.netmarketshare.com/

path要素ではd属性というもので図形を定義するのですが、それはこちらの「svg要素の基本的な使い方まとめ」で詳しく解説されていますので参考になさってください。私はpath要素に限らずSVGのほぼ全てをこちらのサイトで学びました。
ただ、たとえd属性の書式を理解したとしても、これを手書きするのは人間の所業ではありません。そのため大抵のグラフライブラリには円弧を描く機能が提供されているはずです。
今回はスクラッチで描く方法のご紹介なので、簡易な円弧専用のd属性書き出し関数を作ってみました。

IEのシェアは50.86%だそうなので、角度に換算すると183.096度になります。11行目の例にあるような呼び出し方をすると望みのd属性が得られます。

"M 150,0 A 150,150 0 1,1 141.8986347236027,299.7810664959306 L 150,150 Z"

あとは他のブラウザの分も同様に、シェアを角度に換算して、またこの関数を呼んで、結果をコピペして、

...って、やりませんよ!
ここまできたら、d属性だけでなく全てJavaScriptから動的に生成したほうが良いでしょう。

JavaScriptでパイチャートを描いてみよう

htmlにはSVGタグだけを記述しておき、JavaScriptで円弧を生成してそこにappendChildする、という方法でパイチャートを描いてみます。
前述のd属性出力関数を使用して円弧を生成する、パイチャート描画関数を作成してみました。

13行目のforEachは、あらかじめ割合の分母を知っておきたいためにループして値を合算しています。
17行目でpath要素をcreateElementNS(createElementではないので注意)で生成し、その下でd属性をはじめ必要な属性を設定、23行目でsvg要素にappendChildしています。これを円弧リストの数分繰り返します。
この関数は以下のように呼び出すことができます。

できあがったパイチャートはこんな感じになります。
マウスを置くとブラウザ名と割合が表示されるようにしてありますが、面倒なのでSVGとは直接関係ないので説明は省略します。ソースコードだけでよろしければ記事末にリンクしておきますのでご覧ください。

Internet Explorer 50.86% Chrome 31.12% Firefox 11.28% Safari 5.01% Opera 1.28% other 0.45%
2015年10月の世界ブラウザシェア
出典: https://www.netmarketshare.com/

さらに真ん中に小さい円を追加してあげると、ドーナツチャートもできますね!(こういうインチキっぽい方法ではなくpath要素を駆使してちゃんと円環を描くこともできます)

2015年10月の 世界ブラウザシェア Internet Explorer 50.86% Chrome 31.12% Firefox 11.28% Safari 5.01% Opera 1.28% other 0.45%
出典: https://www.netmarketshare.com/

アニメーションをつけてみよう

ここからは余興です。

グラフはただそれだけでも説得力がありますが、さらにアニメーションの演出を加えて見る者を完全に信じこませましょう。
アニメーションもスクラッチで書いていると本題を見失うので、今回はVelocity.jsの助けを借りることにします。Snap.svgでも良いと思います。

まずは、この怪しげなボタンを押してみてください。

Internet Explorer 辛うじて過半数維持! Internet Explorer 50.86% Chrome 31.12% Firefox 11.28% Safari 5.01% Opera 1.28% other 0.45%
出典: https://www.netmarketshare.com/

選挙風になっているのは特に意味はないですが、このパイチャートを見て分かるのは、IEが50%を切るのは時間の問題だ、といことです。それをアニメーションを使って、より強調してみました。ちなみにこのデータにEdgeは含まれていませんが、もしかしたらotherとして計上されているのかもしれません(それだと少なすぎるかな?)。

さて、アニメーションの方法ですが、考え方はとてもシンプルです。
すでに円弧を描くpathのd属性を生成する関数をご紹介しましたが、これを少しずつ角度を増やしながら何度も呼び出して、ひたすらd属性を書き換えてやります。今回はIE以外の円弧を反時計回りで描く必要があるので、関数を少し改造しました。

引数に方向fを追加しています。1が時計回り、0が反時計回りです。パイチャートは時計回りで描画することが多いので、普段は固定値にしておいて問題ないと思います。

さて、Velocity.jsは本来は要素のtransform属性を操作して滑らかなアニメーションを実現させるライブラリですが、任意の値を指定時間かけて徐々に変化させるという機能も実装されています。今回徐々に変化させたいのはpathのd属性なので、この機能を利用してd属性を変化させていく処理を書きます。

4行目のtweenというのは任意の値を指定するための仮の属性です。180.096は最終的なIEの角度です。値は暗黙的に0スタートなので、このように指定することで「0度から180.096度まで徐々に変化させよ」という意味になります。
6行目のdurationはアニメーション時間です。この場合は「6秒かけて徐々に変化させよ」という意味になります。
7行目のeasingはいわゆるイージング、変化のさせ方です。バウンドする効果が欲しかったのでeaseOutBounceを指定しています(実際にはVelocity.jsにeaseOutBounceはデフォルトでは実装されていません。こちらに関しては記事末のソースコードのリンクをご覧ください)。 8行目のprogressは値が変化する度に呼び出される関数です。この関数の5番目の引数tがその時点での値となります。つまりこの場合t=角度であり、これを使ってd属性を生成し、書き換えてやります。

IE以外のブラウザは反時計回りに描画したいので、progressで呼び出すd属性書き出し関数の第6引数に0を渡すようにします。また、ブラウザをひとつひとつ順番にアニメーションさせていくためPromiseを使います。Promiseを使わないと同時にアニメーションが開始してしまい、うまくいきません。詳しくは記事末にソースコードをリンクしておきますのでご覧ください。

さいごに

SVG、特にグラフに関していえば、実際はライブラリを使うんだとしても、素のSVGを知っているのと知らないのとでは、見えないところで差が出てきます。
素のSVGを知っていれば、何ができて何ができないかを予想することができます。
素のSVGを知らなければ、ライブラリの挙動がバグなのか仕様なのか切り分けることもできません。
ライブラリを完全なブラックボックスにせず、本当はスクラッチでも書けるけど(書く方法を知っているけど)工数を減らすためにライブラリを使う、というのが理想だと思います。

pie-chart.html
pie-chart.js

2014年5月28日水曜日

MacBook Air 2014年モデルを買ったら Mid 2013 だった

Webを検索してみた限り、私と同じ問題を抱えている人は少ないようですが、こちらとかこちら(英語)に同様の方がいらっしゃいました。
2014年モデルをカスタムして購入すると、"このMacについて"で Mid 2013 と表示されます。


良く見ると2014年モデルであることを示す 1.4 GHz Intel Core i5 の文字が・・・。つまり、中身は確かに2014年仕様になっている。なのに Mid 2013
こちらのサイトを見てみると Early 2014 という表示が読み取れるので、この部分はやっぱり Early 2014 となるのが正解のはず。
今回初めて Apple のサポートに問い合わせてみました。
まぁ色々あったのですが省略して、結論をいいますと、Apple では2014年モデルの一部に私のように誤表記されてしまう個体が存在することを認識しているそうです。時期は未定ですが恐らくOSのアップデートで修正されるでしょうとのこと。

あー、問い合わせて良かった。少し安心しました。

2014年2月10日月曜日

続 WebSocket for Android (Cordova/PhoneGap Plugin)

気が付けばブログ更新がほぼ1年ぶりという...。
しかも内容が前回記事のアップデート、Cordova/PhoneGap の Android 向け WebSocket プラグインのお話。

Cordova/PhoneGap がバージョン3になって、環境周りが大きく変更されました。
それに伴ってプラグインの導入方法や開発方法も変更になり、以前作ったバージョン2向けのプラグインが使えなくなってしまったのですが、バージョン3がリリースされた当時(記憶では2013年の夏だったかと)仕事が超絶忙しく、全然キャッチアップできていませんでした。
Android 向けの WebSocket プラグインは私の他にも公開されている方がいらっしゃるのですが既にバージョン3対応済み。完全に出遅れです。
それで、ようやく時間が作れるようになったので、自分のプラグインをバージョン3対応してみることにしたのでした。

何が変わったのか


バージョン3では開発環境がNode.jsベースになりました。Android の場合でいうと、Eclipse などの IDE さえ不要になりました。この変更が一番大きいですね。
プラグインの導入については、以前は必要なファイルを手動で自分のプロジェクトにコピーしていましたが、コマンドを叩くことで自動的に取り込まれるようになりました。プラグイン導入のコマンドは以下のような感じです。
cordova plugin add プラグインのURL
または
phonegap plugin add プラグインのURL
これらの変更は、ターゲットOSの開発環境(手法)に精通していなくてもそのOS向けにアプリをビルドできる、という恩恵をもたらしてくれます。
ただ、この新しい開発環境はまだまだこれからだなという印象です。特に、現時点では PhoneGap (の存在)が微妙です。PhoneGap は簡単にいえば Adobe 版 Cordova で、Cordova との明確な違いは PhoneGap Build に対応していることぐらいしかないのですが、各種コマンドの文法を微妙に変えていたり、その一方で、ファイル名だけ PhoneGap に変えただけのものがあったりします。この中途半端な独自性が災いして、サンプルアプリを動かしただけなのに「cordova.js が見つかりません」などという警告が出たりします。

新しい WebSocket for Android


プラグインのバージョン3対応は、つまりはこの新しいプラグイン導入コマンドに対応することです。
Android 向けのプラグインについていえば、名前空間に若干の変更が入りましたが、インターフェースそのものは以前から変わっていません。
変更点としては plugin.xml というマニフェストを用意する必要があるぐらいです(この定義ファイルをコマンドが解釈し、従来手動で行っていたファイルのコピーなどが自動化されます)。
そのため従来のプラグインをそのままバージョン3対応することはそんなに難しくありませんでした。ただ、プラグイン自体が現在の WebSocket 仕様と違っている部分があったり、テキスト送受信にしか対応していなかったりで、ただバージョン3対応するだけではイマイチな状況。そこで今回は、

  • インターフェースを現在の WebSocket 仕様になるべく準拠させること
  • その上でバイナリ送受信にも対応させること

を目指しました。
過去のバージョンのことなので詳細は省きますが、インターフェース部分は以前に比べだいぶ WebSocket 仕様に近づいたと思います(複数サブプロトコルや ready state、bufferedAmount など、まだ対応すべき部分は残っていますが)。

そして今回一番大きな追加機能であるバイナリ送受信。
はじめに書いてしまいますが、プラグインでのバイナリ送受信はあまりメリットがありません。。
プラグイン(JavaScript)とネイティブ(Java)との間では文字列しかやり取りできないので、バイナリは一旦 base64 でエンコードしなければならないからです。これを送受信両方で行うのです。テキスト送受信と比較したときの速度面でのアドバンテージはほとんどありません。これは WebView の宿命ともいうべき仕組み上の限界です。
まあ、ネイティブ WebSocket のフォールバックとして、バイナリ送受信もできるということに一定の価値はあるとは思いますけどね。
そうそう、ネイティブといえば、Android 4.4 から標準ブラウザが Chromium ベースに変更されたことに伴い プラグインなしで WebSocket が使えるようになりました。4.4 以降がシェアの大半を占めるようになったとき(何年後?)、本プラグインはその役割を終えるでしょう。。

詳しい使い方は GitHub をご覧いただけたら幸いです。できない英語を無理強いしているためツッコミどころ満載かとは思いますが、その際はそっとご指摘いただきたく存じます。。

2013年3月17日日曜日

WebSocket for Android (PhoneGap Plugin)


とある理由によりPhoneGapでWebSocketが使えるプラグインを作りました。こちらに置いてあります。ただしAndroid専用です。
iOS用も探せばあると思いますが、こちらのサイトによるとiOS Safariでは4.2からWebSocketをサポートしているので、そちらで十分なんじゃないでしょうか。

作った理由のひとつは上記サイトにあるとおりなんですが、Android BrowserがなぜかWebSocketに未対応なんですよね。
んで、WebSocketを使うAndroid専用アプリを作る場合、JavaでWebSocketをやる方法は検索すると割と豊富に出てくるわけですが、今一度、PhoneGapでAndroidアプリを作ってみたかったんです!ただそんだけ!(本当に単純な理由だな...)
そしてPhoneGapでWebSocketを使ったアプリ作るなら、そのプラグインも作ってみようかと思ったわけです。

プラグインの中身ですが、W3CのWebSocketの使用感に極力合わせることを目標にしました。
サンプルコードはこんな感じです。

// WebSocketのインスタンスを生成
var ws = new plugins.WebSocket('ws://echo.websocket.org:80');

// ソケットオープンしたときの処理
ws.onopen = function () {
    console.log('onopen');
    // メッセージの送信
    this.send('hello');
};

// メッセージ受信したときの処理
ws.onmessage = function (data) {
    console.log(data);  // hello
    // 受信したらクローズ
    this.close();
};

// エラーが発生したときの処理
ws.onerror = function (message) {
    // エラー理由をコンソールに出力
    console.log(message);
};

// ソケットクローズしたときの処理
ws.onclose = function (code) {
    // 終了コードをコンソールに出力
    console.log(code);  // 1000
};

WebSocket.orgのサイトでechoサーバが公開されているので、そちらに繋いで「hello」とメッセージを送り、サーバからエコーされてきたメッセージ(helloのはず)をコンソールに出力して終わりです。
なお、これをエミュレータで動かすとうまくいかないので、以下のような「おまじない」をActivityのonCreateに追加します。実機では必要ないです。

java.lang.System.setProperty("java.net.preferIPv6Addresses", "false");
java.lang.System.setProperty("java.net.preferIPv4Stack", "true");

2012年12月31日月曜日

自分の2012年を振り返る


ほぼ半年ぶりのブログ更新...ダメだ...続かない。(笑)
2012年もいよいよ大晦日。区切りとして今年1年を総括してみたいと思います。

今年、自分にとって最大の出来事は、会社を辞めてフリーになったことです。4月のことでした。今回はこのことをメインに書いてみたいと思います。

1 - 3月
この期間はまだ会社員だったということになりますね。
前の年の年末で辞める計画もあったのですが、仕事の区切りがつかなくて3月まで延びることに。
立つ鳥跡を濁さずの精神と、一刻も早く会社を辞めたい気持ちがせめぎあっていました。
そしてこのとき既に、退社後は再就職はしないことは決めていて、かつ仕事をしばらく休んで勉強しようと思っていました。

4月
3月の末になって、それまでお世話になっていたある会社から仕事のオファーが。
会社を辞めたら休むつもりだったので正直なところ迷いましたが、夏頃までの短期案件だったというのと、今後の関係も考えて引き受けました。
ところがどっこい、先方の諸々の都合により4月いっぱいで、しゅ〜りょ〜...おっほっほっほ。
元々休むつもりだったんで別に良いんですけど、夏頃まで続くんじゃなかったんですか。
と、いきなりフリーの洗礼?を浴びることに。(スキル不足でクビになったわけじゃないですよ!)

5 - 6月
さて、あっけなく仕事が終わってしまったので、当初の予定どおり無職・無収入生活へ。
以前からコツコツと勉強はしていたんですが、やりたかったのはWebの勉強。
会社員時代はとにかく仕事に空白期間を作らないことを最優先にして、あまり興味がない仕事でも我慢してやってきました。その結果、私の場合は.NETのシステム制御にスキルが偏ってきて、いつの間にか.NET技術者の烙印?を押されていたのです。
フリーになりたかった理由のひとつとして、.NETから解放されたかったというのもあります。
昔あったブラウザ戦争とか、Officeの値段の高さとか、そして非オープンな技術によってベンダロックインされてしまう危うさとか、諸々の理由で以前からMicrosoftにあまり好印象を持っていないんです。(中立的な目で見た場合、VisualStudioの完成度は群を抜いていると思いますし、C#はJavaよりも好きな言語です。)
それにMicrosoftでWebといえばASP.NETですが、スキル的にはWebというより.NETという括りにされることが多く、案件で先方が求めているWebスキルとして見てもらえないという印象があります。(Web = Javaでしょ、的な)
ま、かといって今からJavaに肩入れする気もなかったので、Webの勉強はHTML5を意識してJavaScriptに集約されていきました。
以前からの積み上げ分とこの2ヶ月間の勉強で、JavaScriptはそこそこ出来るようになったと思います。

7月
いつまでも無職・無収入生活を続けていても良くないと思ったので、ここいらで仕事探しに。
紆余曲折あり、最終的にAndroidアプリの開発案件に参画させてもらいました。
技術者が見つからず困っていたらしく、リスク承知でAndroid未経験な自分を雇ってくれたみたいです。
面接ではPhoneGap使って5日で作ったアプリを見せました。反応は、悪かったです。(笑)
Androidのネイティブアプリ開発だったので言語はJava。PhoneGapでは門前払いされても文句は言えません。
で、それからは猛烈な勢いでAndroidの勉強。JavaScriptのことはひとまず忘れる。(笑)
やってみた印象としては、UI作るのが相当面倒なのと、それに付随して画面を動的に書き換えたりするのが難しかったです。そして、端末毎に異なる解像度も悩みの種。
iPhoneアプリみたいなUI作れ」って言われましたが、Androidでは難しすぎます。iOSなら標準で備わっているコントロール使えば済む話でも、Androidの場合は自力で線描いたりしないといけませんから。これは本当に無茶な要求だと思いました。
その結果、参画1ヶ月でさようなら。(笑)
開発していたアプリは8月リリース予定でしたが、2012年大晦日の現在でもリリースされた様子はありません。もしくは開発中止になったかな?

8月
仕事は終わってしまったのですが、せっかくAndroid開発に携わったので、以前に作ったPhoneGapアプリを全部Javaで書き直すことにしました。それがこちら
言い訳みたいですけど、あくまで習作ですので。
今思えば、Androidアプリ開発はWebの範疇なんだろうかと。アプリの種類にもよりますが、どちらかというと昔やっていたWindows FormとかSwingの開発経験が生きた気がします。

9 - 12月
8月はお盆ということもあって仕事が見つからなかったのですが、9月に入って新たな仕事が見つかりました。
で、ASP.NET...(笑)
あんだけ好きじゃねーとか言っていながら、です。
これは妥協です。別の機会に書こうと思いますが、この業界は経験が何よりものをいう世界なので、未経験または経験少の仕事はやらせてもらえないのです。7月にやったAndroid案件は完全に例外でしょう。
実はASP.NETの経験もそんなに多くはなかったのですが、前述のとおりASP.NETはWebというより.NETの括りで捉えられるため、会社員時代に身につけた.NETのスキルと「個人的にWebを勉強しています」というハッタリだけで参画できました。(ハッタリだけじゃなくてちゃんと成果を上げましたよ。)
そしてその仕事も11月に契約満了となりました。
そうしたらどういうわけか同じ先方から別案件のオファーをいただき、仕事は変わりましたが今も同じところでお世話になっています。
今の新しい仕事はJavaWebで、JavaScriptも使いまくり。特にJavaScriptは勉強してきたことが役に立ちました。
この仕事のオファーは全くの想定外でした。希望してもなかなかやらせてもらえないWebの仕事なのに、一時の妥協が良い方向に転がりました。
ただこれはゴールではないですし、来年以降もより希望の仕事に巡り会えるよう勉強は続けていくつもりです。

とまあ、徒然なるままに書いてきたのですが、長過ぎなのでこのへんで終わりにしようと思います。
フリーになってみて今言えることは、

  • 未経験の仕事に携わるのは非常に難しい(「勉強してます」はほぼ通じない)
  • 物事は自分の思うようには運べないが、思いもよらないところにチャンスはある
  • 無職になるリスクを気にしなければ自由に仕事は選べる
  • ただしいつまでも続けていられるとは思えない(年齢的に)


2012年、以上!

2012年6月6日水曜日

lego.js をリリースしました

本当は5月下旬に Github に公開してたんですが、ドキュメントを書くのにだいぶ時間がかかってしまって、不完全ながらも一応かたちになったので今回ご紹介させていただきます。

lego.js - a lightweight module loader for client-side JavaScript


lego.js?なにそれ?おいしいの?
lego.js は CommonJS Modules や RequireJS にインスパイアされた、JavaScript でモジュラープログラミングを可能にする軽量モジュールローダーです。
JavaScript ソースを機能ごとに分割してモジュール化し、それらを任意のタイミングでロードすることができます。
元々はサーバサイド JavaScript の共通仕様である CommonJS (その一部である Modules) をクライアントサイド (Web ブラウザ) に実装することを目標にしていましたが、Node.js の作者による 「CommonJS オワコン発言」を知ったこともあり、途中から AMD (Asynchronous Module Definition) Loader で有名な RequireJS の影響を多分に受け、CommonJS に準拠しながら AMD ライクなフォーマットを採用しています。

開発の経緯
HTML5 + JavaScript で Webアプリを作ると JavaScript のコーディング量が結構なボリュームになりますよね。特に何も考えず script タグなんかを使ってロードしてくると顕著に動作が重くなったりしませんか? スペックが貧弱なスマートフォンなんかで特に。
(セミシングルページとでもいうのでしょうか) ページ遷移を極力しないで Ajax やハッシュフラグメントによって表示内容を切り替えるような方式にしても、最初のページ起動時に JavaScript を一括でロードしてくると、今度は起動がやたら遅いアプリになってしまったり。

これは私自身が Web アプリの習作を作っているときに直面した悩みでもあるのですが、この問題の改善策として、起動時には必要最低限のスクリプトだけをロードしてきて、あとは場面の展開に応じて必要なスクリプトを追加ロードしてくるような仕組みがあれば良いのではないかと考え、あれこれ試行錯誤していくうちに lego.js が生まれました。

そういうの、もうあるよね
指摘される前に書いてしまいますが、lego.js のようなモジュールローダーは既にいくつか公開されています。上に書いた RequireJS や、curl、yabble.js なんかが有名です。
正直に書くと、lego.js を開発する前は RequireJS は名前しか知らず、それを使うと何がうれしいのか良く分かっていませんでした。そうして開発を進めていくうちに次第に RequireJS が分かり始め、自分のやっていることが「車輪の再発明なんじゃね?」と気づき愕然とするも、後学のためと言い聞かせ最後までやり切ることにしました (自己満とも言う)。

とりあえず
lego.js を使って Web アプリを作るとこうなる! という実装サンプルがまだないので、まずはそれを準備せねば。あとは書きかけになっているドキュメントかな。。

もし lego.js に興味を持たれた奇特な方がいましたら使ってみてください。
pullrequest も大歓迎です。