過去分はこちら。

2014年01月


2014年02月


2014年03月


2014年04月


2014年05月


2014年06月


2014年07月


2014年08月


2014年09月

今回は10月のまとめです。管理画面やアイコン、ローディングなどのスタイル系は人気があります。また、Excelやコマンドラインツールも一部入っているなど、業務ですぐにでも役立つものも好まれます。すぐにでも業務で活用できそうなものがたくさんありますのでぜひチェックしてみてください。
Marka – アニメーションをサポートした綺麗なアイコンライブラリ

Webサイトにはアイコンが付き物ですよね。しかしフラットUIが流行とあって、アイコンも派手なものではなく単色でシンプルなものが好まれるようになっています。例えばWeb Fontを使ったアイコンです。Web Fontを使った場合、カラーリングやサイズの自由が大きいですが、向きを変えたりアニメーションさせたりするのは難しいでしょう。そこで使ってみたいのがMarkaです。m.set('arrow').rotate('left');
fsql – CSV形式などのテキストファイルを対象に、クエリーを実行できるコマンドライン・ツール。
fsql は Perl製のソフトウェアです。CSV形式などのテキストファイルをオプションで指定し、クエリーを実行できます。CSV形式などのテキストファイルで既にデータソースがあり、すぐに中身の調査をしたいが、テーブルを定義したりするのは面倒だという方に便利なソフトウェアです。RDBMSでは、データベースやテーブルをつくり、データソースをインポートした後にSQLを記述して実行します。fsqlならばこの手間がありません。簡単な検索や集計処理を行う場合、すぐに結果を得ることができます。結果を利用して資料を作成する際、資料作成だけに専念できますので大変便利です。CSV形式やTAB区切りのテキストファイルだけでなく、JSON形式、YAML形式のファイルも処理できます。
Mozilla Brick - 再利用可能なWeb UIコンポーネント集

Webアプリケーションを開発する際に厄介なのがUIです。標準では提供されないコンポーネントはもちろんのこと、ちょっとしたエフェクトやアニメーションを作ろうと思うと非常に面倒なことになります。よりWebアプリケーションを手軽に開発するためにMozillaが開発しているのがMozilla Brickです。多彩なUIコンポーネントで開発を手助けしてくれます。Mozilla Brickでは再利用の容易なUIコンポーネントを多数提供しています。これらを組み合わせることでWebアプリケーション開発がスムーズになることでしょう。デザイン全般を提供する訳ではないので、他のフレームワークと組み合わせて使うのが良さそうです。
　

今回のテーマは認識です。従来はコンピュータはデジタルデータを処理することが多かったですが、その範疇が徐々に広がっておりアナログデータ（リアルのデータ）を取り込みつつあります。とはいえ単にデータ化するだけでは意味がなく、そこから何らかの意味がある情報を読み取るのがおもしろさです。
そのための認識技術、そしてそれらを利用したソフトウェアを紹介します。
OCR
昔から行われているテキストをデジタル化する技術です。手書き文字を認識するのは未だに難しいですが、昔の書籍であったり、名刺の文字を認識するのは技術が向上しており、認識率が高まっています。スマートフォンのカメラで撮影してそこに書かれている文字を読み取るアプリも数多くあります。
音声
SiriやGoogleが有名ですが音声入力も活発に開発されています。音声から文字にできれば良いわけですが、実際にはその後自然言語からコンピュータに命令を行う必要がありますので音声認識以上に言語解析が難しい分野といえます。テキストにする所までであればオープンソース・ソフトウェアにも幾つかの選択肢があります。
もちろん多言語対応が必須なので、英語圏のみならず正しく認識するのは困難でしょう。
Webカム
Webカムは従来Webチャットくらいしか使われてこなかった訳ですが、HTML5のgetUserMediaに対応したことで利用範囲が広がっています。得られた映像をCanvasを使って解析し、オブジェクトを認識します。最も分かりやすいものは顔認識で、OpenCVなどと組み合わせるケースが多いようです。
さらに簡易的なジェスチャー認識も行われています。手や腕を振ったアクションや特定の色やマーカーを認識させることで、アクションを起こすことができます。
ジェスチャー
最近ではLeap Motionをはじめとして外部デバイスを使った認識技術が登場しています。Kinectはその走りともいえますが、今なおトップレベルではないでしょうか。最近筆者はTouch+というデバイスを購入しましたが（Mac OSX向けドライバはまだ出ていませんが…）、それは画面のタッチを認識するガジェットになります。
OculusでもDK2は物体の距離をはかるセンサーを別で提供しており、コンピュータ内だけで処理できないセンサーも出てきているようです。
AR
ARはカメラを使って実装できる点で手軽です。物体をそのまま認識するケースと、マーカーを通して認識するものがあります。マーカーを認識する方がシンプルですし、多少動かしたとしても認識し続けてくれます。逆に物体認識の場合、向きを変えただけでも認識できなくなる場合があります。
　

今回のテーマは通知です。様々なソフトウェア、アプリを使っている現在、ちょっとしたお知らせではあっという間に他の情報の中に埋もれてしまいます。そうならないためにも、積極的に情報を発信するための手段として生まれたのが通知です。
通知はいくつかの種類があります。今回はその種類と、それらを実現するためのソフトウェアを紹介します。
ローカル
デスクトップ向けへの通知として有名なのはGrowlではないでしょうか。それをAppleが模倣する形で通知センターにしています。通知センターは各種Mac OSX向けのソフトウェアが使える通知場所となっています。
App Store以外のソフトウェアからでも使えますので、Mac OSXを使っている人に対しての通知場所として便利です。
HTML5 デスクトップ通知
HTML5のデスクトップ通知はチャット系ソフトウェアなどで使われるようになってきました。ネイティブの機能を使っているので、ブラウザウィンドウ外に通知の表示ができるのが便利です。ただしHTML5なので、そのURLを開いていないと通知は出せません。
利用用途として多いのはチャットですが、それ以外にも時間がかかる処理を行う際にその完了を通知するのに使えるかと思います（たとえばファイルのアップロード）。
プッシュ通知
スマートフォン、タブレットアプリであれば積極的に使っていきたいのがプッシュ通知でしょう。今やほとんどのアプリにおいてプッシュ通知が使われています。メール、チャット、ソーシャルをはじめ、ゲームにおいてもイベントの開催など通知してきます。
正直、プッシュ通知は過多になっていますので、効果は薄れてきているでしょう。とはいえ送らないとゼロな訳で、頻度さえ守れば一定の効果が望めるのは間違いありません。
ダイアログ/アラート
最も忌み嫌われるのがアラートではないでしょうか。非同期処理の多いJavaScriptにおいて、アラートは完全に処理を止めてしまう類のものです。他のタブでアラートが出ても、強制的に移動させられます。
強力な通知機能ではありますが、ユーザストレスは相当大きいといえます。HTML5からはダイアログ要素が追加されており、ストレス軽減にはつながりますが、デザイン含めて考える必要があるのが若干敷居を高くしているかも知れません。
独自
独自の通知ライブラリは押しつけがましくない、ユーザストレスの少ないものが多いです。そのURLをアクティブにしている場合においてはとても有益といえます。
インラインで表示した場合、スクロールしていたりするとメッセージに気づかないことがあります。独自ライブラリも多くはフローティングで表示されますので、あえてデザインを気にするなく実現できるのもメリットです。
　

今回のテーマはvi/Vimです。古参のプログラミングエディタでありつつも、今なお高い人気を誇ります。ちなみに筆者はEmacs派です。
単純にvi/Vimといったソフトウェアで使われている他、そのキーバインドを他のソフトウェアでも使いたいという夢を叶えるソフトウェアもまた多数存在します。今回はそうしたvi/Vimライクな世界を実現してくれるソフトウェアを紹介します。
大抵のLinux/Unixにデフォルトで入っている
最も大きなアドバンテージがこれです。Emacsは入っていないことが多く（サイズが大きいからですが）、他人のサーバでは好き勝手にインストールすることはできないのでviを使うことになります。なのでEmacs派とは言いつつも筆者も普通にviを扱える程度にはキーバインドを覚えています。
軽い
Emacsは（ってEmacsとの比較ばかりですが）起動に時間がかかります。viは軽量ですぐに起動します。Emacsの場合、一度起動したらほとんど終了することがないので多少重たくても良いですが、テキストエディタとして活用していく上では軽さは大事でしょう。
マルチプラットフォーム
Linuxはもちろん、Windows/Mac OSXでも同じように操作できます。ローカルアプリケーション、サーバサイドを問いません。そのためローカルで慣れたキーバインドでそのままサーバ上のファイルが編集できます。
Windowsでは他のテキストエディタを使う人が多いですが、キーの打ち間違いをしたり、生産性が損なわれることも多いです。
他のソフトウェアでもキーバインドを再現
有名なソフトウェアであればviのキーバインドを実現するソフトウェアが存在します（PhotoshopやIllustratorといったデザイナー系ではありませんが）。普段使い慣れたプログラミングエディタのキーバインドそのままで操作できるのは便利です。
ただし大抵はHJKLキーでの移動、検索と置換、ヤンク風のクリップボード操作が行える程度のようです。
　

今回のテーマはマインドマップです。ある課題に対する情報を構造化し、整理する上でとても役立つツールになります。また、人によっては議事録に使ったり、プロジェクトのタスク管理に使っていたりもします。
そこで今回はマインドマップのお勧めな点と、各プラットフォーム向けのマインドマップソフトウェアを紹介します。
テーマは一つに絞る
最近、複数のノードを中心にできるものもありますが、個人的にはテーマは一つにして作成すべきだと思っています。テーマを中心にドリルダウンすれば、網羅的に考えられるようになります。複数のテーマを設けると、その関連性は見いだせるかも知れませんが、考えが散発してしまう可能性が高くなります。
ドリルダウンは順番に
子ノードを作成する際には、一つ一つのノードに集中するのではなく、全体を俯瞰するようにノード作成を行っていくべきです。まず子ノードを複数作成して、次に全体の孫ノードを作成していきます。一つのノードだけ集中して掘り下げてしまうと、バランスが悪くなったり他のノードを掘り下げる気力がなくなってしまうものです。
色を使う
本来のマインドマップは紙で行うのが推奨されています。それは単に頭で思い浮かんだ単語を書き記すだけでなく、自由に線を引いたりノードを囲んだり、さらに色を変えてカラフルに仕上げるのが求められているからです。
カラフルになると頭の中の刺激も変わってきます。単調な白黒だけでなく、グルーピングや重要度、日付などによって色を変えてみるのをお勧めします。
いつでもどこでも
最近はWebやアプリで動くマインドマップも増えてきました。それによっていつでもどこでもマインドマップをメンテナンスできるようになっています。これは大きなポイントです。
マインドマップは短時間に集中して作成するよりも、時間を区切って頭をリフレッシュしてから作る方が良いものができたりします。あまり根を詰めるのではなく、頭をすっきりさせた状態の方が、良いアイディアがふっと沸くかも知れません。
　

今回のテーマはローディングアイコンです。最近はWebアプリケーション化が進んでおり、JavaScript/Ajaxを多用した開発が多くなっています。アプリのように画面遷移しないケースも増えており、スピーディーになっているものの、処理状態がわかりづらくもなっています。
そこで使っていきたいのがローディングアイコンをはじめとするステータス、二重処理の防止策です。手法およびオープンソース・ソフトウェアを紹介します。
ステータス表示
最近多いタイプです。YouTubeなどで別画面に切り替わる際に画面上部に読み込み中のステータスが表示されます。元々アプリには多かったので、それをWebにも持ち込んだ仕組みといえます。
視認性はあまり高くないので、使い慣れたWebサービスでないと気づかないことも多そうです。
ローディングアイコン
最も多い手法で、従来であればアニメーションGIFを使うことが多かったように思います。最近ではSVGアニメーションであったり、CSS3アニメーションを使って実現するものもあります。画像は多少なりともリソース読み込みに時間がかかるので、あらかじめ読み込んでおくか、SVG/CSS3でリソース読み込みのロスがない仕組みのが良いでしょう。
ボタンの無効化
もっともシンプルですが確実な方法です。ボタンをdisableにしておくことで、二回押せないようにします。ただしJavaScriptの内部的エラーがあった時に無効状態のまま止まってしまうことがあるので注意が必要です。
　

昨年のGoogleリーダー終了祭（？）に続き、Livedoorリーダーも終了を発表しました。これまで情報収集に使ってきた人たちは難民として溢れ出しています。そこで今回は新たなフィードリーダーの選定と、一助になりそうなソフトウェアを紹介します。
面白いことにGoogleリーダーが終了を発表した時に開発者がこぞってGoogleリーダーライクなソフトウェアを開発しました。なので現状では選択肢が増えていたりします（継続的に開発されているかは怪しいですが）。
他のWebサービス
個人的にはGoogleリーダーからFeedlyに移った口です。記事単位の未読、既読管理が欲しかったのでちょうど良かったのです。Livedoorリーダーのように一気に既読状態にするタイプとしてはBloglineがありましたが、あれも既にサービスを終了していますので同じような選択肢は難しいかも知れません。
ただ安定的なクローラを作るのは難しいので、そういう部分だけでもFeedlyを使う（Web APIが公開されています）手はあるかも知れませんね。
Fastladder
Livedoor英語版がベースになっているオープンソース・ソフトウェアです。Heroku buttonにも対応していますのですぐにデプロイ出来ます。更新はそれほど頻繁ではありませんが、数日前にも更新されている部分があるようです。
自前で立てるとそのサーバの管理があったり、Herokuの場合もクローラー分の費用が発生する（WebとWorkerで2つなので）と思いますが有力な選択肢と言えそうです。
ローカル
外部サービスに依存するとサービス終了するリスクがある訳で、いっそローカルに立ててしまう手もあります。難点としては最近はスマートフォンやタブレットで見たいというニーズも多いので、そういった場合に各デバイスごとにデータをもたないといけないということでしょう。
後は総じてキャッシュのデータ量が大きいので、ストレージを逼迫する可能性があります。
フィードリーダーを止める
最近は筆者の周囲でもフィードリーダーは使っていないという人が増えています。使っている人が増えているならGoogleリーダーもLivedoorリーダーも終了していない訳ですし、分からないでもないですが。
FacebookやTwitter、ソーシャルニュースリーダーのようなサービス/アプリで十分かも知れません。個人的にはフィードリーダーがなければ仕事が成り立たないですが、実は他の選択肢でもカバーできるかも知れませんよ。
　

今回のテーマはレスポンシブWebデザインです。MOONGIFTでレスポンシブWebデザインという単語が出たのは2012年7月ということで、2年前のことになります。その2年間で注目が一気に高まりましたが、色々な場面で問題点があるとも聞きます。
銀の弾はないという話ではあるのですが、そういった問題を踏まえつつもトレンドとして使っていく必要があるでしょう。ということでよくある問題点と、レスポンシブWebデザインを活かせるライブラリを紹介します。
作成コスト
レスポンシブWebデザインは基本3パターンのデザインを作成しますが、作成コストは1ページ分になるなんて聞いたことがあります。スマホ、携帯、デスクトップと分かれていた時代は3ページ分だった訳で、高度なテクニックが必要な割に残念な結果になるようです。
こだわったデザイン
時々レスポンシブでありながら各端末向けにカスタマイズされたサイトを見かけますが、大抵は情報を整理して表示するレベルに留まっています（メニューくらいでしょうか）。あまり各デバイス向けにこだわると、表示/非表示が増えてしまいレスポンシブである意味がなくなります。
更新コスト
レスポンシブの問題として、更新コストが思いのほか大きいという問題があります。一つの変更が他のデバイスに及ぼす影響範囲が読めなかったり、他のデバイスでは表示したくない情報が増えていくことが起こりえます。
予めベースがきっちりと決まっていれば更新もスムーズになるかも知れませんが、それはシステムを作る側とも同じ問題と言えます。
余計なリソース
最近ではスマートフォンも解像度が高まっていますが、それでもモバイルネットワーク向けには大きな画像リソースは帯域の問題になります。また画像の上の文字など、そのまま縮小するだけでは芳しくない表示もあります。
各幅向けに画像リソースを振り分けるライブラリもありますが、画像を何パターンも用意する面倒さがあるでしょう。そうなるとテンプレートも分けてしまっても…といった声があるのも確かです。
　

今回のテーマはExcelです。Excelは日本のITを根底から支えている存在といっても差し支えないでしょう。開発者にしてもExcelがなかったら業務が回らないという方はとても多いです。
必須のExcelだからこそ、逆にExcelの便利ツールを知り、使いこなすことができれば生産性を大幅に向上させることも可能でしょう。ということで今回はExcelの便利な（？）使い方とオープンソース・ソフトウェアの紹介です。
業務システムのフロントエンド
Webでシステムを組んでいると大抵、マスタメンテナンスや検索結果においてExcel並の機能が求められます。正直、そこまで作り込んだとしても使われる機能はごくごく僅かであり、工数の割に合わないことが殆どです。
そこで簡易的なシステムであればいっそExcelをフロントエンドとして、RESTfulなAPIで対話するのが良いのではないでしょうか。集計系はCSVダウンロードではなく、XML出力にして直接Excelで読み取ってもらう方が楽なケースは多々あります。
VBAの呪縛を脱する
Excelで帳票作成を考えた時に必ずVBAが話題になります。しかしコードがスパゲティになりやすく、メンテナンスも考えるととても面倒です。そこで使えるのがデータシートと帳票シートの二つに分けたExcelファイルです。昔から良く知られていると思いますが、未だにVBAごりごりなケースをよく見るので。
データシートにはシステムから出力したCSVをそのまま貼付けます。後は帳票シート側で "=!データシート.A1" （こんな感じでしたっけ？）のように記述しておくだけです。連続帳票の場合、多少VBAを記述しますがデータロジックは全てVBAから切り離せるのでメンテナンスは楽になるでしょう。
クラウドに移行する
最近はMac OSXも現場で使われるようになっているので、あえて別ライセンスのMS Officeを購入するのをためらうことがあります。Numbersの互換性は高いとはとても言えません。そこでいっそクラウドに移行してWebベースで作業するのはいかがでしょう。
とは言えOffice.comではVBAが使えません。選択肢としてはGoogleスプレッドシートでApp Scriptを覚えるか、Zehoスプレッドシートを使う手があります。
画面はWebで
昔はExcelとAccessは連携可能で、Accessの中にExcelの表をリンクさせて編集が可能でした。これにより、Excelの表をAccess上で分かりやすいGUI画面を作って作業できたのですが、特許の絡みで現在はできなくなっています。
Excelで画面を作るのは絶望的に難しいのではないかというのが個人的な感想です。そのため、ユーザが使う画面はWebで、その結果をExcelファイルに追記していく形はありな気がします。最近ではサーバサイドでもExcelファイルを操作できるようになっていますので、データベース代わりに使ってみると意外と便利です。