過去分はこちら。

2014年01月


2014年02月


2014年03月


2014年04月


2014年05月


2014年06月


2014年07月

今回は8月のまとめです。Web系が多いのは紹介しているソフトウェアの性質上致し方ないとして、最近node/Goを使ったソフトウェアが増えてきています。まだプロダクションで使えるレベルかは分かりませんが、尖った技術者の人柱的段階を過ぎて、技術力の高いエンジニアによる試用段階に入ってきたものと思われます。
geojson.io - GeoJSON出力に対応したWebベースのマップエディタ

地図コンテンツはいつも根強い人気があります。しかし意外と作るのは面倒だったりします。地図は色々なプロバイダーから提供されていますが、その上にマーカーを立てたり、四角く囲んだりするのは面倒です。それをビジュアル的にできるのがgeojson.ioです。最終的にGeoJSONファイルを生成してくれるマップエディターです。その他TopoJSON、CSV、KML、Shapefileでも出力できます。GeoJSONを使えば他のシステムとの連携も容易です。生成されたファイルをテンプレートに、システムから出力してもいいでしょう。色々な使い道が考えられそうです。
HTML5 device mockups - 各種デバイスに埋め込むデザインテンプレート

自分のWebサービスがスマートフォンやタブレットをサポートしている場合、それを全面に打ち出したいですよね。そんな時には通常、スマホやタブレットのモックアップをサイトに表示して、その中にWebサービスのコンテンツを表示します。そんな感じの表示を簡単に実現してくれるのがHTML5 device mockupsです。多種多様なデバイス、向き、カラーリング選択にも対応しています。このデバイスモックアップは画像で、Webコンテンツが埋め込める形になっています。HTMLはもちろん、画像も埋め込めます。色々と使い道が多そうですね。
LiveMd - Google Chrome機能拡張のMarkdownエディタ

普段使いのテキストエディタがあるので、なかなか気に入ったMarkdownエディタが見つからない…そんな方はLiveMdを試してみてはいかがでしょう。ローカルアプリケーションではなく、Google Chrome機能拡張として動作します。Chromeアプリではなく、機能拡張で提供されているのが利点です。ボタンを押すだけで素早く起動できて、素早くメモができます。作成したテキストはMarkdownフォーマットでダウンロードできます。LiveMdはGoogle Chrome用のソフトウェア（ソースコードは公開されていますがライセンスは明記されていません）です。
　

今回はInstagramを取り上げます。月間アクティブユーザが2億を越え、各種ブランドからも利用されているInstagramですが、技術者的にはあまり積極的に使われていないような気がします。
ということで利用者としてだけでなく、開発者としてInstagramの面白さを使って、その世界観の中で何ができるのか考えてみたいと思います。
最近の話題
2013年のスマートフォンアプリ7位
ソーシャル系としては、Facebook（1位）、YouTube（4位）に次ぐ3番目となっています。Twitterは10位なので、ソーシャル系サービスとしては相当大規模なものになっているのが分かります。
写真投稿数は200億枚以上
2014年03月時点で月間アクティブユーザ数が2億を突破、2010年10月からの総投稿数は200億枚を越えているそうです。1日6,000万枚以上投稿されているそうなので、もうすぐ300億万枚に到達するかも知れません。
OAuth2による連携が可能
Facebook、Twitterに比べるとあまり使われている気がしませんがOAuth2によるシステム連携が可能です。かつて写真投稿といえばFlickrが使われてきましたが、今は写真コンテンツを投稿するようなユーザをターゲットに考えるのであればInstagramユーザを取り込んだ方が良いのではないでしょうか。なおOAuth2とはいっても写真投稿のAPIはありません。
クローンが多い
Instagramの肝になるのは何と言っても写真加工でしょう。そのため写真加工部分を真似するクローンアプリ、ライブラリがとても多く存在します。技術者としてはOpenGLを使った加工処理を真似してみたいという思いはあるかも知れません。
サーバをAWSからFacebookのインフラに移行
最近話題になっていたのがInstagramのサーバインフラをAWSからFacebookへ移行したという記事です。数千の仮想マシンを1年間かけて移行し、収束にさらに1ヶ月かかったとのことです。サービスの中断をすることなくやりきったというのが凄いですね。
ちなみにその結果として、サーバ台数は1/3になり、大幅なコスト削減につながったとのこと。さらにインフラが統一されることでFacebookに実装されている機能も使えるようになるメリットがあるとのことです。
　

プログラマの間では当たり前になっている差分ツール。GitやSubversion、Hgなどのリポジトリ管理において更新された箇所をチェックするのに使っているかと思います。
今回はそんな差分ツールに注目したいと思います。テキストだけでなく、各種バイナリについてもソフトウェアが存在するので仕事がさらに便利になるはずです。
要点
画像
クライアントサイドの差分表示としてはテキストに次いでポピュラーだと思います。GitHubでもWebベースの差分ビューワーで画像の差分表示に対応しています。画像はバイナリなので差分処理がテキスト以上にしづらい分、使いやすいライブラリは人気があります。
処理的に見れば、縦横のサイズが同じであれば、バイナリのピクセル単位での比較になるのでそれほど難しい訳ではないでしょう。サイズが変わったり、JPEGのようにデータが保存するごとにちょっと違ったりすると、その差が大きく見えてしまうので注意が必要です。
更新チェック
差分の使い方として、Webサイトやディレクトリの更新チェックに使うというものも幾つかあります。これは面白いアイディアだと思います。Webサイトであれば更新チェッカーであり、ディレクトリであればバックアップや同期ツールとして利用できるでしょう。
データベース
データベースの差分チェックツールも人気があります。スキーマの更新状態をチェックしたり、2つのデータベース間の差分を抽出します。一般的にはスキーマレベルのチェックで、データの差分は行いません。
オフィスファイル
ExcelやWord、PDFなどの差分チェックです。ビジネスでよく使われるファイルだけに差分チェックは欠かせません。特にオフィスファイルをメールでやり取りするような場合、更新された場所を明確化するためにも使いたいですね。
オフィスファイルは更新履歴をとれるようになっていますが、それ以外の機能もあるので余計ややこしくなってしまったり、慣れていない人には分かりづらかったりします。個人的にはオフィスファイルも差分チェックツールを使う方が良いと思います。
その他
その他、レジストリの差分をとったり、実行ファイルの差分を抽出したりと様々な差分ツールがあります。仕事上、よく使うファイルフォーマットについてどんなツールがあるか調べてみると面白いかも知れません。
　

今回はプロジェクト管理がテーマです。GUIからWebベース、ごく小規模なスモールチームからエンタープライズまで数多くのプロジェクト管理が存在します。さらにウォーターフォールやアジャイル、リーンなどプロジェクト形態も増えていく中で、どういった選択肢を考えるべきなのかまとめてみました。
要点
基本はタスク管理
プロジェクト管理は色々機能があると思うのですが、肝になるのはタスク管理だと思います。某プロジェクト管理システムは多くの機能を備えていますが、使われていないものが殆どだと言われています。
まずタスク管理をきちんと行えるようになった上で、次の機能を使うようにすべきです。いきなり全てを使いこなそうとしても管理工数が膨大に増えるために早々に破綻してしまうでしょう。
複数プロジェクト対応
企業において、一つのプロジェクトしか稼働していないというケースは多くないと思います。むしろ複数プロジェクトに参加しているのが基本ではないでしょうか。そのため複数のプロジェクトを管理し、横断的にデータが見られるものを選択すべきです。
そのためWebサービスにおいてプロジェクト数で価格の変わるものは個人的にはお勧めしていません。もっとダイナミックにプロジェクトを作成し、ステータスを管理して終わったら終了にするくらいのシンプルさで良いのではないでしょうか。
なるべく機能を少なめに
機能が多い＝良いことであるかのように考えるとプロジェクト管理は大抵破綻します。使わなければ良いだけという考えも大抵失敗します。表面上にあるだけで、それは負荷を増やす要因になると言えます。
まず最低限としてタスク管理があり、その上で本当に必要なものだけ追加していけるのが良いでしょう。プロジェクト管理以外にも既にスケジューラーがあったり、メールやチャットを使っているケースは多いので、そういったものと重複しない注意が必要です。
進捗が見やすいもの
逆に必須なのが進捗が見やすいことです。プロジェクト管理の目的はプロジェクト管理を運用することではなく、開発が円滑に進んでいることを確認し、問題を早期発見できる点にあります。そのために必要なのは、状況が可視化されて問題も把握できるようになっている必要があります。
リポジトリと連動
プロジェクト管理の難点はとにかく管理工数、運用工数が増えます。プログラマに日々の状況を入力してもらうだけでも大きな負担になるはずです。そこで考えてみたいのがリポジトリと連携する形での運用です。
プロジェクト管理にはリポジトリビューワーが入っていますが、そのログから状況が読み取れれば工数入力の手間は軽減されるかも知れません。
　

2008年くらいから知られるようになってきたソースコードレビューですが、一時は熱も高まったものの、そのコストがかかる割にメリットが少なかったりして次第に廃れていってしまっています。
今はGitHubなどでWebベースのコードレビューができるようになっちえます。そこで今回は改めて意味のあるソースコードレビューのやり方を考えてみたいと思います。
要点
オンラインで行う
ソースコードレビューの悪しき習慣とも言えるのが、メンバー全員が揃って行う形だと思います。ごくわずかな効果のために、全員の開発力が止まって束縛されてしまうのはデメリットが大きいのではないでしょうか。
最近ではWebベースのコードレビューも増えていますので、マージする前に必ずその機能に関わるメンバーにオンラインで目を通してもらうくらいが良いと思います。
テストをしっかり書く
動くコードをチェックするのも必要ですが、そこで分かるのは悪いコードかどうかです。これはだいたい一度か二度、その人のコードを見れば分かるのではないでしょうか。奇麗なコードを書く人が突然ダメなコードを書くケースは多くありません。
可読性高いコードであればあえて説明をうけなくとも処理内容は予想がつくはずです。むしろコードレビューでバグを見つけるのは相当大変だと思います。であればテストをしっかりと書く時間に充てる方が有益です。
仕様書を書く
それでもなお、不具合が減らないとすれば、それは仕様がちゃんと把握されていない可能性があります。APIドキュメントを書いたり、期待する動作を明文化する仕様書を適切に作る方が大事です（ソースコードが奇麗である前提です）。
バグが起きた時にレビュー
問題があるかどうか分からないコードを全て見るのは大変ですが、バグが起きているコードは必ずどこかに問題があるはずです。なのでコードレビューをマージする前ではなく、不具合が発生したタイミングで行うという手もあります。
不具合を個人の責任にするのではなく、チーム全体で把握して同じ問題が起きないように共有することでシステム全体の質を向上させていく姿勢が大事ではないでしょうか。
こまめにする
XPなどではペアプログラミングを推奨していますが、それは日々の作業時間の中でコードレビューを兼ねられるからでしょう。週に一度とかでダメ出しを食らってまとめて修正なんてのは現実的ではありません。なるべく短い時間で、少ないコードに対してレビューすべきです。
その場合、人数も最低2名からでできますし、熟練者と初級者という組み合わせであれば初級者のOJTとして考えることもできるでしょう。
　

今回はWeb表計算をテーマにお送りします。業務システムにおいてデータをグリッドで一覧表示したいという要望は良くあります。テーブルをリッチにするライブラリもたくさん出回っています。
そこでさらにWeb上でデータを編集させてしまうのを可能にするのがWeb表計算です。解析系は難しいかも知れませんが、Excelでよくやっているような編集であれば現在はHTMLベースでも十分こなせるようになっています。
Webサービス
かつてはWebベースの表計算サービスもたくさんあったのですが、現在は随分と減っています。サービス自体が終了していたり、ピボットして新しい展開を行っていたりするケースもあります。そして最近の主流としては表計算だけでなく、ドキュメントやプレゼン作成も含めたオフィススイートとして一括提供されるもののようです。
Apple – iWork for iCloud beta
Appleの提供するクラウドオフィススイートです。まだベータですが、表計算もきちんと動作します。
Apple – iWork for iCloud beta
Excel Online の概要 - Office Web Apps
Microsoftの提供する、言わば本家のWebベースオフィススイートです。ただしマクロ、VBAは使えません。
Excel Online の概要 - Office Web Apps
Document Management Software | Manage Documents Online : Zoho Docs
Zohoが提供するWebベースオフィススイートでは何とVBAがインポートできるようになっています。全ての機能が動く訳ではないでしょうが、これはすごいですね。
Document Management Software | Manage Documents Online : Zoho Docs
My Drive - Google Drive
Googleが提供するWebベースオフィススイートです。VBAは使えませんが、Google Apps ScriptというJavaScriptを使った拡張ができるようになっています。
My Drive - Google Drive
Welcome to SpreadsheetWEB
表計算機能を提供しつつ、さらにデータベースアプリケーションとしても使えるようになっています。フォームを作成し、アプリケーションが作れます。Excel + Accessといった感じでしょうか。
Welcome to SpreadsheetWEB
ThinkFree Cloud Office
ThinkFreeも他社同様、ドキュメント/表計算/プレゼンテーションの3パターンを提供しています。HTMLではなくJavaアプレットで動作するのも特徴です。
ThinkFree Cloud Office
　

プログラマ、エンジニア、デザイナーであっても文章を書くという機会は多いと思います。ブログ、メモ、寄稿、書籍、議事録、報告書、仕様書、スライド…様々な機会で文章を書くと思いますが、文章を書くのが苦手という方は少なからずいます。
そんな方々に向けて、分かりやすい文章を書くにはどういった所を注意すればいいかというのが今回の記事になります。
話すように書く
口語と文体が全く違う場合、頭の中で考えている内容と実際に書く内容が異なるためにその翻訳が大変です。そのため、話している感じでそのままテキストに落とし込んでいくくらいの方がスムーズに書けるようになります。
実際、文章を書くと突然冗長的になる方が多かったりするので、話し方のように書いているかどうかは良いチェック法になります。ただし普段あまり適切な喋り方でない方には向かないかも知れません。
正しくではなく読ませるように書く
自分が正しいことを書いていれば相手にも正しく伝わるはずだと考える方がいますが、総じて間違います。むしろ正しいだけの文章はとても読みづらい場合があります。まず読み手のことを考えて文章を書くべきです。
段落ごとの文字数、一文毎の文字数を気をつける
だらだら喋っても要領を得づらいように、文章においても段落と一文あたりの文字数に気をつけましょう。一文に句読点は多くとも三つまでにとどめるべきだと思います。そして三文あたりで一段落にするのがいいかと思います。
書いている方は色々盛り込みたいと思ってしまうのでついつい長く書いてしまうのですが、読み手にとってはもっと大事なポイントだけに抑えて欲しいと思うものです。小説を書くならともかく、仕事における文章、ブログなどであれば短くまとめる方がいいでしょう。
漢字を多用しない
漢字を多く使うと締まった印象になりますが、逆に堅苦しくなったり、窮屈な文章になってしまいます。そこで読み手のレベルに合わせて使う漢字を決めた方がいいでしょう。オンラインメディアなどでは「事」「毎」「等」「有る」「無し」などは使わないようです（MOONGIFTでも使いません）。
あまり平仮名ばかりだと幼稚な文章と思われてしまうので、それも避けるべきです。この辺りはバランスだと思いますが、オンラインメディアは一つの参考としてチェックしてみるのはいいと思います。
　

今回のテーマはWebメーラーです。個人的にはローカルのメールアプリケーションは何年も使わなくなっています。Webメーラーで十分使えています。ネットワークが完全にない場合は閲覧できませんが、今日において全くネットワークがない状況で1日以上過ごすことのが少ないのではないでしょうか。
ということでWebメーラーを、特に企業において使っていくのをお勧めする内容になっています。インシデントや誤配などが起きる前にぜひ後半にあるようなソフトウェアを試してみてください。
要点
機密データ
メールは機密データであることを考えると、ローカルにデータがあると危険であると言えます。通常、メーラーの起動時にパスワードを求めるようなことはないので、暗号化されていない状態で保存されていると言えます。
データ容量
かつてはHDDで大容量化が進んでいたため、メールが多少大きくても問題ありませんでしたが、SSDの時代になってまた容量が低減した中では添付が数多くやり取りされるビジネスメールの蓄積は負担が大きくなっています。
とは言え簡単に削除することもできないので、バックアップをとってから削除などすると過去メールの検索がうまく行えずかえって不便になったりもします。
OS
WindowsであればOutlookやBeckyなどの優秀なメーラーがありますが、OSを乗り換えたりするとクライアントソフトウェアも変えなければなりません。使い勝手が違うと途端に作業効率が落ちてしまうものです。
Webベースであればブラウザさえあれば変わらず利用できるという利点があります。さらにデータ移行の手間もありません。
HTML5
かつてのWebメーラーはクリックが多く、使い勝手がよくありませんでしたがGmailがAjaxを多用してからというもの操作性がどんどん向上しています。その流れで最近ではHTML5が用いられるようになっています。
例えばGmailではドラッグ&ドロップによるファイルアップロードに加えて、オフラインアクセスも使われています。他のWebメーラーについてもそれに負けじと機能追加がされています。
インストール不要/データ管理
当たり前ですがWebアプリケーションであればインストール不要で使えます。さらにデータ管理についてもサーバ側で一元的にまとめられます。これらの利点は企業内において大きいのではないでしょうか。
オフィスファイルやPDFのようなローカルアプリケーションによる編集が伴うフォーマットはともかく、メールは閲覧や作成ができれば良いので、ローカルで個々人にインストールや作業するよりも、サーバサイドでまとめた方がセキュリティ的にも安心できるはずです。
　

今回のテーマは位置情報です。スマートフォンが流行るのにともなって位置情報を使うアプリ、サービスが増えていますが、その反面プライバシーに直結することもあってその扱いに注意が必要にもなっています。
とは言え技術的に見ればとても面白い活用法が考えられるだけに、様々な活用法が出てきているのも事実です。そこで最近の話題と関連オープンソース・ソフトウェアを紹介します。
トレンド
プライバシー
位置情報を同一セッションにおいて記録し続けるとその人の生活圏、自宅など様々な情報が漏洩してしまいます。そのため、その取り扱いについて国としての枠組みが出来つつあります。
先日、総務省の位置情報プライバシーレポートにおけるYahoo! Japanの意見が酷いといった話題があがっています。企業として位置情報を扱うサービスを提供する場合、ユーザの承認を確実得るといった仕組みが大事になるでしょう。
入力データとして扱う
スマホ、タブレットにおいて情報を入力するというのはとても面倒なものです。ソフトウェアキーボードで長文を打っていくのはとても面倒で、外付けキーボードを使ったりします。その入力ソースの一つとして使えるのが位置情報です。
データを入力する際には位置情報（場所）や時間に関連づいていることが多々あります。位置情報を使って近くにある店舗や公共施設の名前と一緒に保存することが出来れば後で検索するのも容易にできます。
フィルタリング
近くの人とだけチャットをしたり、アドレス交換をしたりと位置情報をキーにすることでリアルな場所において近くにいるというフィルタリングに使うことが出来ます。技術によって、または場所によって誤差が大きいのが難点ですが、ある程度のフィルタには使えるのではないでしょうか。
多彩な位置取得技術
位置情報を取得するのはGPSだけではありません。Wifi、IPアドレスなど様々な情報から取得できます。ただし精度が最も高いのはGPSなどで、かつ屋外にいる場合でしょう。
最近、磁気指紋データを使った位置情報取得技術magnetic fingerprintというのが注目を集めています。建物に対する調査が必要ではありますが、モールの中や地下、博物館のような建物でも位置情報が使えるようになるでしょう。
データベース
位置情報をデータベースで扱うのは意外と面倒です。有名なところではPostgreSQLのPostGISであったり、MongoDBを使うかと思います。全文検索との組み合わせを考えた場合はGroongaやElasticSearchが利用できます。
既存のデータベースに対してある程度粗い条件でも許容できる場合、GeoHashを使う方法もあります。予め計算しておく必要がありますが、MySQLなどでインデックスも効きやすいので気軽に使えるはずです。