『かんたん工数見積もり』 リリースしました

工数見積もり? 難しいよね(「豊島? 強いよね」風に)

転職して1ヶ月ちょっと経ち、仕事にも余裕ができてきたついでに、リハビリがてら何かアプリでも作って公開してみようかと考えたわけです。

ネタとしては、開発工数の見積もり補助ツールに決めました。

工数見積もりって難しいですよね。真面目に考えれば考えるほど、可変パラメータが数を増していき、楽観的見積もりから悲観的見積もりまでの間のどのあたりで提出するのが妥当なのか決めにくい。

結局のところ、ある程度考えた上で安全マージンと予算の兼ね合いを見ながら、えいやっと出してしまうしかないのですが、基準が決めきれないと無駄に考えてしまいがち。

ということで、私の場合は「(楽観的見積もり×1+普通の見積もり×n+悲観的見積もり×1)÷(1+n+1)」的な計算で出すことにしています。nは3~5くらいにしつつ。ただ、これも手で計算しているといろいろ微調整したくなったりして、また無駄に時間を費やしてしまうんですよね。

というわけで、この辺りのノウハウを盛り込んだアプリを作ることにしました。

ワンアイディアのユーティリティアプリ、今なら何で作る?

今まで作ったことがあるスマホアプリは、Objective-C iPhoneアプリと、MonoTouch iPhoneアプリ、Java Androidアプリ。ただしどれも4~5年前。

ソシャゲ業界ではFlash/AIRアプリをだいぶやったけど、今更なー。Unityはいじったけども本格的な開発までは絡まなかった。

アプリの内容と今どきの技術から考えると、Web系技術をベースにしたアプリ開発環境が一番良さそう。ReactNativeとかWeexとか。PhoneGapとかってまだあるのかな?

C#好きーとしてはMonoTouchというかXamarinがいいかなーと思ったんだけど、なんかこの辺4~5年前と比べて特に使いやすくなっておらず、C#好きーの目から見てもいまいち感が否めない感じがした。

で、マルチプラットフォームで手軽に作れる開発環境と言うことで、最終的に決めたのはUnity。

こんな感じのアプリです

タイトル画面とかアバウト画面とかもあるけど、アプリとしての機能はこの画面に集約されている。

一番シンプルな使い方としては、まず真ん中に一番ありそうに思える見積もりを入力し、その左に最速でできた場合の見積もり、右には最悪に時間がかかった場合の見積もりを入力する。

単位は日でも時間でも、自分の中で統一していればなんでもいい。

すると、下の「見積もり結果」のところに、入力された3つの数値から算出された見積もり工数が表示される。

まあだいたい一番ありそうに思える見積もり周辺の数値が出るはず。なんだかんだ言って、自分が妥当と思った見積もりに近い結果になることが多いはずだから。

ただ、仕事の内容によっては自分の予測があまり当てにならないだろうなー、と思われるときもある。慣れないジャンルの仕事とか勝手の分からないお客さんが相手とか。

そういう場合は、下にある「見積もり難易度」のバーを右側にずらしていくと、ありがち以外の見積もりの比重が高い「見積もり結果」に変わっていく。

これだけで、通常の見積もりには十分に使えると思うが、上下にさらに3つずつ入力欄が用意されている。

これらは見積もりの際に軽視しがちな「事前準備」「後始末」にかかる工数を意識するためのものだ。

開発作業にはメインの作業工数以外にも、事前・事後に付随する工数が思いのほか多く必要になることがある。

それらをメインの見積もりに加味して考えてもいいのだが、別に分けて考えることでより正確な見積もりをやりやすくなる。

「このシステムを開発するには、環境準備が結構大変そうだなー」とか「このお客さんだと納品関連のやりとりは普通よりもかなり多めにかかるよなー」とか。

そして、それらの見積もりに対しても楽観的バージョンと悲観的バージョンを検討することもできる。

それら全体を加味した結果が「見積もり結果」として表示される。

これをUnityで作ったわけだが

という非常にシンプルなアプリなので、一般的なUI SDKを備えた開発環境ならば何を使っても簡単に作れるだろう。もちろんUnityも一般的なUI SDK機能が標準で取り込まれているので、簡単に作れる。

ライブラリなどを別途用意しなくても、Unityの標準機能だけでも簡単に作れるのだが、イベントハンドリングなどをスマートに書きたいのでUniRxを利用し、C#の記述力が大幅に変わってくるので.NETのバージョンはExperimentalな4.6を採用した。

自分で書いたC#のコードは500行くらいで、画像(テクスチャ)はアイコン画像1つをあちこちで使い回しているだけ。なぜかiOSビルドだけ透過PNGをアイコン指定したらビルド後のアイコンが腐るという症状に悩まされたが、何とか解決した。

Unityは割引価格のインディーアカウント契約し、JetBrainsの全部入りにも入っているのでエディタにはRiderが使える。これでMacでのUnity開発はだいぶやりやすくなる。

レポジトリはgithub利用。しばらくBitBucketを使っていたんだけど、やっぱりgithubに戻ってしまった。

ビルドはUnity Cloud Buildに丸投げした。Unityでのクソ面倒くさくて時間がかかるビルド、しかもマルチプラットフォーム分なんて手元でやってられるか。

AppleやGoogleのDeveloper登録もやりなおした。Appleの税務関係の登録の仕方はすっかり忘れていた。あとiTunes Connectの使い方も4~5年前から結構変わっている気がする。ビルドの差し替えにずいぶん苦労した。

たったこれだけのアプリなので、Unityを使ってもバイナリサイズは20Mバイトくらいですまないかなーと思っていたのだが、実施にはiOSストアサイズで60Mバイトくらいにはなってしまった。

これはまだ改善の余地はあるはずだが、半分ジョークアプリみたいなものなのでこのままでもいいかな。でも今後のことを考えるとサイズは追求しておいた方がいいんだろうな。

もうなんでもUnityで作っちゃおうかな

とそれぞれのプラットフォーム版を公開できるところまでたどり着いて振り返ってみたところ、このくらいのアプリを作って公開するのにUnityを使うというのは、バイナリサイズが無駄に大きくなることをのぞけば、悪くないなーという感触だ。

特にUnityはOS標準で用意されているUI部品などは使わず、全部ゲームのようにレンダリングして描画してしまうため、マルチプラットフォームの差異を吸収する能力が高く、何も考えなくてもマルチプラットフォームで動くバイナリが作れてしまう。

今回はiOS、Androidは(自分で書いたコードやUIに関しては)完全1ソースで書けたし、各プラットフォーム向け設定に関しても、ビルドやストア公開向けの部分数カ所以外は特にいじる必要がなかった。

たぶん他のマルチプラットフォーム向けの開発環境だと、もうちょっと各プラットフォーム向けの設定を書いたり、場合によってはUI構築やコーディング自体も環境依存のことを色々考えてやらなきゃならないんじゃないかな。

今どきはその辺、他の開発環境でも簡単になってるのかな?

このくらいのアプリを作るのに、わざわざ各プラットフォームの最新情報を勉強し直す気にはなれないので、何も考えず見た目ベースで設計・開発できるUnityはとても楽。

ただ、ストア公開のための知識はどうしたって各プラットフォームごとに必要だけど。

Unityの標準UIはそんなに強力ではないので、複雑なUIが必要なアプリを作ろうとすると結構苦労するだろうが、逆にゲーム系エフェクト・Tween表現などには強いので、動きや見た目に凝るのは簡単にできる(やってないけど)。

また開発環境としての将来性は、ゲーム系開発ツールとしてはほぼデファクトスタンダードになりつつあるので、かなりの長期先まで安定して開発され続けることが期待できる。

個人で作るアプリ開発環境としてはもうUnity一択でいいかもしれないと思えてきた。Web系・サーバー系は別ね。あくまでもスマホクライアントアプリ開発環境。

アプリのサイトは『かんたん工数見積もり』に用意したので、実際に触ってみたい方はそちらへどうぞ。

最近のUnityはWebGLビルドもだいぶ使い物になっているので、Webブラウザ向けにもビルドできる。サイトにはWebGL版も置いておいた。つるしでビルドするとWebGLでだけ日本語表示できないのが面倒だよね。

Mac App版とかWindows版とかLinux版とかも(Cloud Buildで)ビルドは作ったんだけど、Mac App Storeに公開するのは思ったより面倒くさそうだし、その他のビルドもジョークで公開するにしては色々面倒そうなんでやめ。

余裕があったらもういくつか違うパターンのアプリを作って、Unityの底力を試してみよう。

転職しました 2018

2月1日付で転職しました。

前職はソシャゲ屋さんで4年ほどマネージメント成分多めのエンジニアをやっていましたが、

  • ゲーム系の技術ばかりやっていると、Web/アプリ系技術に触る機会が少なすぎて、技術的なトレンドの(私にとっての)メインストリームに疎くなる
  • 会社が大きくなるにつれマネージメントの比重が重くなり、ますます現場レベルでの技術に疎くなる
  • ソシャゲ的なお客さんとの向き合い方、コンテンツの作り方がどうもしっくりこない

というあたりに行き詰まりを感じていました。

ゲーム系の技術もそれなりに面白くはあるんですけど、ゲーム系の技術はやはりフロントエンド寄りのほうが華という感じで、バックエンド方向への興味が強い私にとっては、それだけで満足という感じにはならなかったんですよね。

で、やっぱり自分の志向としては、マネージャーよりもエンジニアのほうが好みだし、ゲーム系よりもWeb系だよなーということで、現場レベルのWeb系技術をやらせてくれるところを探していたところ、roomclipというサービスをやっているTunnel株式会社に声をかけてもらい、そちらでお世話になることになりました。

もういい年齢でこういう志向の人間を雇ってくれるというのは、なかなか懐の深い会社だと思います。エンジニア35歳定年説? なにそれおいしいの?

そっち方面に転職するのにあたって、あんまりWeb系へのブランクが大きすぎるとまずいかなーと思い、転職前にリハビリがてらFirebaseを使ってtwEssayというサービスを作ってみたりしたんですが、Web系フロントエンド技術からずいぶん離れていたため、mBaas+Vue.jsで開発するのになかなか手間取り、結局作りかけのまま時間切れになってしまいました。

本当は、今は亡き日記猿人(才人)テキスト庵みたいな日記/雑文サイトのコミュニティをTwitterベースで再現する、みたいな感じのものを作ってみたかったんですけど、データ設計的にもコミュニティ設計的にも行き詰まってしまいました。

というわけで、twEssayは単に長文テキストを画像化してTwitterに投稿するだけのサービスになってしまっています。

そのうちモチベーションが上がったら続きを作りたいところですが、業務で色々覚えたり慣れたりしなければならないことが多く、しばらくの間は技術的な興味はそちらで充足してしまう気もするので、手をつける気になるのは大分先のことになるでしょう。

でもFirebaseならば維持費もほとんどかけずに放置できるのがいいですね。一昔前ならばサーバー維持費もおもりをする手間もかけなければならなかったのに、Firebaseならば低コストで維持しておけるし、まかり間違って流行ったところで勝手にスケールしてくれるはず。

レンタルサーバー→自宅サーバー→個人向け専用サーバー→VPS→クラウドサーバー→○aasと、個人でWeb系サービスを立ち上げる環境もずいぶんと変わってきたものですなー。

なんかインターネット老人会濃度が高い。

久しぶりのブログで発散気味なので、これにて終了。今後はちょっとは発信頻度が高い感じになるといいな。

1470.netをまとめサイト化

ドメイン売らないかメールが来たのをみて、放置していた1470.netドメインのことを思い出し、最近仕事以外ほとんど何もしない状態が続いているんで、twe-tdからネタを抽出して一言コメントをつける形のまとめブログを始めてみました。

ゆるいネットの話題を追う作業を習慣化して、オンラインリハビリします。

あけましておめでとうございます

去年の4月に、SIer風何でも屋からオンラインゲーム制作会社に転職し、初めての正月を迎えました。

開発部門を社内に持たずにやってきた会社に、新しく社内で完結した開発体制を構築するため、技術基盤整備と人員確保にばたばたしつつ、合間に開発業務を行っているうちに過ぎ去った半年ちょっと。

ネット徘徊やブログ書きなどもろくにやれませんでしたが、ようやく人員も八割方確保できたので、今年はもうちょっと余力がある感じでやれるんじゃないでしょうか(でもまだ人材募集中です)。

もともと、SIer系のお仕事では使うことができなかった、最新技術を実践できることを期待して転職したんですが、やっぱりオンラインゲーム関係はその辺りの技術が使いやすくていいですね。

前職の頃は、業務ではできない最新技術もろもろは、個人の趣味の範囲でいろいろ試してみたりしていたんですが、数十台規模のサーバーを使ったあれこれなどはなかなか実践できませんでした。

また、個人でやっているサービスではアクセス数なども知れていますし、ユーザーのバリエーションやリアクションもあまり期待できません。

一方オンラインゲームでは、アクセス集中時の負荷は個人でやっているサービスとは比べものにならず、かつては技術要素だけは試してみたことがある各種負荷分散対策を、実践でいろいろ試すことができました。

また、ユーザーのバリエーションやリアクションも多いので、それらに対しての事前準備や事後対応、それらを行うための環境整備など、技術的な課題としてやりがいのあるあれこれを実践することができました。

といった感じで、あれこれブログに書いても良さそうなネタは転がっていたんです。

しかし、ゴミが多すぎてGoogle様を使ってもまともな記事を見つけるのが困難な昨今、中途半端なゴミ記事を追加するのも気が引けるし、かといってそれなりのクオリティの記事を書くほどのモチベーションもない。

特に、技術的な記事の内容が現状に即しているかどうか識別することが難しい状況が多すぎるので、そろそろGoogle様は記事の内容の鮮度を明示する仕組みを導入するべきじゃないでしょうか。更新日時ベースだとコピーブログにやられちゃうから、ちゃんと内容を見る仕組みが必要だよね。あと、技術系ブログはできるだけ記事執筆日時を目立つようにレイアウトしておいてくれると助かりますよ。

とか昔同じようなことを書いた記憶があるな。もう7年まえから状況変わってないのか。

転職する前に最後の個人サービスとして作ったtwe-tdですが、ほぼノーメンテで済ますつもりが、集計結果テーブルだから大丈夫だと思っていたら、1年も持たずにint(11)があふれてしまいbigintでprimary keyを付け直す羽目になりました。やはりTwitterのデータ流速はなめちゃいけません。

今年はほとんど巡回することもないまま、いつの間にか存亡の危機を迎えて乗り越えたらしいLivedoor Reader改めLive Dwango Readerを久しぶりに使おうかと思い、ついでに更新が途絶えた登録フィード群を整理していったところ、ブログ系フィードが半分くらいに減りましたよ。

面倒くさいので,自動移転に対応していない引っ越しをした人は追わなかった(ブログ系サービスはフィードの301 redirectに対応するべき)のですが、オンラインから姿を消した人もたくさんいるんでしょうね。逆に、昔と全く変わらない感じで活動し続けている人達も見かけて感心。

Ruby界隈は息が長い人が多いのはtDiaryのおかげでしょうかねー。「日記」は続けやすいけど「ブログ」は続けにくいしねー。あと今ではTwitterが個人が持つ日記的なコンテンツを吸収しちゃうあたりも、ブログを続けることを難しくしている。

遙か昔のWeb日記界隈の人で生き残っている人って、どれくらいいるんでしょうね。日記猿人とか各種アンテナ群にかつて登録されていた方々の、現在の動向をまとめたページとかないかな。ネットストーカー度が高いコンテンツだけど。

今年もプロテニス観戦はまめにやってました。錦織人気がすごくなると天邪鬼が出てブログとかに書く気になれない感じですが。自分でプレイする方のテニスは頻度が1/3くらいに落ちてだいぶぐだぐだです。身体能力がた落ちです。F1は遂に一戦もちゃんと見ませんでした。まあフジテレビNEXTは解約しちゃってたんで、もともとライブでは見られなかったんだけど。motoGPの方がよほどちゃんと見たかも。

BUFFALOのゼン録は2回の故障交換を乗り越えた後1年間もったんですが、年末差し迫った頃にまたエラーで停止していたので、パナソニックのBXT970買っちゃいましたよ。一週間全録から一ヶ月全録にステップアップですよ。一ヶ月だとそう簡単に消えないんで、前よりもテレビを見る頻度は逆に落ちちゃいました。

紙の本を買うのをほぼ辞めました。今家にある本もほとんど全部処分して、欲しかったらデジタルで買い直すことにしました。今度ブックオフを呼んでまとめて処分します。今まで紙で買っていた本も、ほとんどがデジタルで続きを買えるようになってくれたのですが、たいてい紙より発売が遅れることと、ごく少数いまだにデジタル化しない出版社(あるいは作者)があるのが腹立たしいです。

思いつきがだいぶ発散しているので、そろそろおわります。今年もよろしくお願いします。

Twe-td client for iPhoneを作った

というか、作ったのはTwe-td client for Androidよりも前なんだけど、ようやく公開されたんで。

機能としてはAndroid版とほぼ同じで、画面左右端あたりをタップするとアイテムの前後移動。画面下にある言語とタイプの左右の「<」「>」をタップすると、言語やタイプが切り替わる。画面右上にあるゴミ箱をタップするとそのアイテムが非表示になる。

Web版だと過去の日付を指定して、「○○語で○月×日に話題になった○○」とかを見ることができるけれども、アプリ版は「○○語で現在話題になっている○○」しか見ることができない。

単にユーザーインターフェースをシンプルにするために、それだけに機能を絞っているだけで、作れば簡単に作れるんだけど。

ところで、Android版にもiOS版にもGoogle Analyticsのアプリ版を仕込んでいるんだけど、プラットフォームごとにGoogle Analyticsのプロパティをそれぞれ別に設定してある。けど、同じアプリの別プラットフォームバージョンを作る場合って、別プラットフォームでも同じプロパティIDを使うのが普通なのかな?

せっかくGoogle Analyticsがその辺を識別して集計してくれるのに、わざわざ別IDに分けてしまうのはアホらしい気がする。と、公開されてから思った。

それにしても、Androidアプリの公開までのスピード感と比べると、iOSアプリのスピード感のなさは、自分で軽量の(作成に一週間もかからない)アプリを作るときには、致命的なくらいきついな。

Androidアプリは実験的なWebサービスを公開するのと大して変わらないスピード感でいけるけど、iOSアプリの10日近いタイムラグは、公開されるまで待っている間に、次のバージョンを開発するモチベーションがなくなるくらいだ。

こんなに間が空くと、既存のアプリをアップデートするよりも、別の新しいアプリを作ったほうがましな気分になってしまう。

Twe-td client for Androidを作った

Twe-td(http://twe-td.net/)のAndroidクライアントアプリを作りました。Google Play Storeからダウンロードできます。

howto

機能としては単純で、起動すると前回表示した言語/種類の最初のアイテムが表示されます。画面左右の端にある「<」「>」で表示するアイテムを前後に切り替えることができます(「<」「>」が表示されている部分だけでなく、画面端のほぼ全体でタッチに反応します)。

画面下側にある「Engilish」「Tweets」の部分が、現在表示しているアイテムの「言語」「種類」の設定で、その左右にある「<」「>」で切り替えることができます。種類は「Tweets(ツイート)」「Movies(ムービー)」「Pictures(写真)」「Goods(商品)」「All Types(すべてのURL)」が選べます。

スマートフォンでWeb版を表示すると、一度に表示するアイテム的に厳しい端末もあるのですが、アプリ版だと一度に1アイテムずつを素早く切り替えることができるので、たいていの端末で軽快に動作するはず。

iPhone版も1週間くらい前にAppleStoreに申請に出しているんだけど、いまだにWaiting For Reviewのままだなー。iPhone版を作った後に作り始めたAndroid版の方が先に公開されるとは。

【PC遠隔操作事件】第2回公判傍聴メモ・最初の検察側証人は「ファイルスラック領域」を強調(江川 紹子) – 個人 – Yahoo!ニュース

【PC遠隔操作事件】第2回公判傍聴メモ・最初の検察側証人は「ファイルスラック領域」を強調(江川 紹子) – 個人 – Yahoo!ニュースを読んでの感想をTwitterにいくつか書いたんだけど、なんか端的に書くと中途半端感が否めないんで、もうちょっとちゃんとまとめておく。

警察側の証言の要旨は、『押収したPCを調査した結果、OSレベルで見えるファイルシステムからは、事件に関連する情報はほとんど得られなかったが、HDDのセクターレベルに残された情報からは、事件に関連すると思われる情報がいくつか見つかった。それらは、そのPC上の暗号化された仮想Fドライブにおいて、問題のウイルスを開発した可能性が高い痕跡だった』と言うもの。

この仮想Fドライブの存在に関しては、片山氏も身に覚えがあるが、そこにウイルスのソースコードが置かれていたことには気がつかなかった、と言っている。そして、それらの情報は自分のPCが犯人によって遠隔操作されてできた、偽の証拠だろうと主張している(のだと思う)。

しかし犯人が、氏を犯人に仕立て上げるために偽の証拠を残そうとしたのだとしたら、どうして『暗号化ドライブ』のような『証拠が残りにくい』場所に証拠を残そうとしたのだろう。

暗号化されているため捜査側がそこから証拠を取り出すことは難しいし、実際警察は暗号化ドライブ自体から証拠を取り出すことはできていないようで、OSやプログラム開発環境が非暗号化ドライブ上でテンポラリ的に使用するファイルの痕跡から、暗号化ドライブ上での作業内容を推測している。わざわざ偽の証拠を残そうとしたにしては、あまりにも証拠が弱すぎる。

もちろん『犯人はわざとそういう遠回しな証拠を残したのだろう』という主張もできなくはない。しかし『自分のPC上で開発した痕跡をできるだけ隠そうとした』と考える方が自然だ。このあたりは犯人の能力をどのくらい大きく評価するか、でどちらの説が有力に思えるかが変わってくるだろう。

あるいは『犯人は、自分のPCでウイルスを開発して自分のPC上に痕跡を残すことを恐れて、すべて他人のPC上でウイルスを開発したのだ』という考え方も、あり得るかもしれない。偽の証拠を残そうとしたのではなく、片山氏のPCが犯人のメイン開発環境であった、という主張だ。

その場合は、できるだけ(普段PCを使用している片山氏にも)痕跡が見つからないように、暗号化ドライブ上で開発を行うことも十分にあり得るだろう。

ただその場合、Visual Studioのような比較的重い開発ツールを使って(しかもVisual Studioのインストール自体も犯人がリモートでやった? この辺片山氏はどう主張しているんだろう)、ウイルス関連の様々なプログラムの開発およびテストを、完全に氏のPCの遠隔操作のみで作る、というなかなか難易度が高い作業を犯人が行ったということになる。

また、Visual Studioを平日午前中に使用した形跡が残っていることを考えると、その日片山氏がそのPCで作業していたかどうかはわからないが、普通に会社が営業しているであろう時間帯にも、犯人は遠隔操作でウイルス開発作業を行っていた、という推測されるため、かなり状況の妥当性に無理が出てくる(それとも片山氏も、Visual Studio自体は(C#以外の言語で)使っていたと主張しているのかな?)。

推測も多いし、どちらにしろ決定的な判断基準となるような証拠はないわけだけど、今までマスコミ報道で出てきた怪しげな証拠と比べると、今回の話はとても真っ当な内容で、警察が片山氏を犯人と考えている理由は納得できた。それが裁判で有罪になるくらいの証拠なのかどうかはわからないし、ましてやコンピュータおよびプログラミングについて深い知識がない人間にどこまで通じるのかわからないけど。

あと、「遠隔操作ではファイルスラックのスペースは自由に残せない」というのは、警察が証拠を見つけ出したのはOSのインストールドライブからだと思われるので、遠隔操作するためのリモート接続プログラムは、OS上のアプリケーションやサービスとして動作している以上、遠隔操作している状況下でOSインストールドライブに対してHDDの低レベルアクセスはできないから、ということだと思われる。

chkdiskみたいなHDDへの低レベルアクセスが必要なプログラムを実行しようとすると、いったんWindowsを終了し、オンメモリで動作するDOS互換な環境で起動し直してから、そこで実行されるよね。あんな感じ。

Twe-td – what is tweeted in the world ? -を作りました。会社を辞めました

Twe-td(ツイーティド) [http://twe-td.net]というサービスを作りました。

これは何かというと、Twitter上でつぶやかれているツイートに含まれるURLを収集・解析し、世界中でどんなWebサイト、ツイート、ムービー、写真、グッズなどの話題が注目を集めているのかを、シンプルなインターフェースでみることができるサービスです。

「世界中で」というところがポイントで、Twe-tdでは収集した情報をつぶやかれた「言語」を軸に区分しています。

たとえば、トップページから「Let’s go!」で飛んだ先は「表示する種類:ツイート(Tweets)」+「表示する言語:全言語(All languages)」となっており、この記事を執筆している時点では、以下のような内容になっています。

表示する内容は、画面上下にあるナビゲーションから変更することができます。

twe-td-selector

一番左が表示する種類の選択肢で、「All(全種類)」「Tweets(ツイート)」「Movies(ムービー)」「Pictures(写真)」「Goods(グッズ)」から選べます。

真ん中が、対象となる言語の選択肢で「All languages(全言語)」「English(英語)」「Japanese(日本語)」を始め、Twitter上でツイートされている様々な言語が選択できます。一応投稿されているツイートが多い順に並んでいます。

一番右は対象の日付(GMT)となります。データ収集プロセスを動かし始めたのは2014-02-20くらいなのですが、いろいろ試行錯誤があり、まともにデータが取れ始めているのは2014-03-02以降となっています。

たとえば「表示する種類:ツイート(Tweets)」+「表示する言語:日本語(Japanese)」にしてみると、以下のような内容になります。

これをスペイン語(Spanish)のムービー(movies)に変えると、以下のようになります。

「ツイート」などは知らない言語だと内容がさっぱりわかりませんが、「写真」や「ムービー」ならば違う言語でもなんとなくわかるもの。言語圏の違いによって、流行にどのような違いが出てくるのか、わからないなりに眺めていても楽しいものです。

また、もうちょっと情報がたまってきたら、同じ言語でも「何月何日頃にはどういうものが流行っていたっけ?」みたいな探索にも使えるかもしれません。

ちなみに、ツイーター上に流れる大量のツイートから無作為にデータを収集しているため、収集結果にはいわゆる「公序良俗に反するもの」が含まれている場合があります。その場合、各URLのそばに表示されているゴミ箱マークをクリックしてもらえると、そのコンテンツを画面から削除することができます。

この削除行為は運営側にも通知が来るようになっていて、ユーザー削除が多いコンテンツはサーバー側でも削除されますので、やばそうなコンテンツを見かけたらまめに削除していただけると助かります。

「公序良俗に反するもの」の規定は明確に定めていませんが、ひとまずは「日本の法律的にNGなもの」は削除していこうかと思っています。また、「自動生成アカウントによる大量操作」「釣りアプリによる権限奪取を使った大量操作」なども、スパムとして削除対象にするつもりです。

まだ開発し始めたばかりですが、自分で使ってみてなかなか面白そうな感じにできてきつつあるので、興味を持った方は是非使ってみてください。

あと私事ですが、長い間お世話になった株式会社ジョルスを3月一杯で退職することになりました。在職中にお世話になった方々、今までありがとうございました。

充電しながら使えるBluetoothレシーバー+ケーブルが絡まないイヤフォン

Bluetoothレシーバーのバッテリーが切れるのにうんざりしている人、ポケットとかに適当にしまったイヤフォンを取り出すたびに、いちいち絡まったケーブルをほどくのにうんざりしている人にオススメ。最近買って大当たりだった組み合わせ。

まずは、micro USBケーブルで充電しながら使えて、バッテリー持続時間も8時間程度と長めのBluetoothレシーバー『BTTC-200』。値段も3000円ちょっとと、Bluetoothレシーバーとしてはお安め。

IMG_0106
micro USBで充電しながら使えるBluetoothレシーバー『BTCC-200』

私は普段移動しながらiPhone/Androidの音声を、仕事をしながらPC/Macの音声をイヤフォンで聞いている。そうやって一日中音声を聞くとなると、どんなにバッテリー持続時間が長いBluetoothレシーバーでも、短くて4時間、長くて8時間程度でバッテリーが切れてしまう。

しかもたいていのBluetoothレシーバーは、充電しながら使用することはできないので、せっかくBluetoothレシーバー経由で音声を聞いていても、バッテリーが切れるとBluetoothレシーバーを充電器にセットして、iPhoneやPCにイヤフォンを指し直す必要が出てくる。

でもBluetoothレシーバーで音声を聞くのに慣れてしまうと、iPhoneに直接イヤフォンをつないだ状態でのケーブルの取り回しがうざいし、PCなんかだとちょっと席から離れるときなんかに、いちいちイヤフォンを外すのも面倒くさい。Bluetoothレシーバーならばトイレに行くくらいの距離ならば、そのまま音楽を聴き続けることもできるのに。

というわけで、このBluetoothレシーバー『BTTC-200』。これならば普通に使っていても比較的バッテリーの持ちがいい上に、使っている最中にもmicro USBケーブルをつないで充電することができるので、PCで使っているときに時々micro USBケーブルをつないで充電しておけば、バッテリー切れの心配がなくなる。

小さくて軽いのでどんなに小さいポケットに入れても大丈夫。イメージとしてはちょー軽い懐中時計サイズ。

充電しながらの利用は、バッテリーの寿命にあまり良くない影響を与えるという定説があるわけだけど、まあ値段も大して高くはないんで、バッテリーが劣化したら買い直せばいい。

おまけとして、この『BTTC-200』はレシーバーとしての機能だけでなく、トランスミッター(送信機)としての機能も持っている。Bluetooth機能を持たないミニコンポとかのイヤフォン端子にこれをつなぐと、他のBluetoothレシーバーでその音声を受信することができる。バッテリーが劣化してきたら、micro USBケーブルつなぎっぱなしにして、そういう用途で使うのもいいかもしれない。

ずいぶんBluetoothレシーバー『BTTC-200』の紹介が長くなってしまったが、もう一つのオススメ商品は靴ひも風のケーブルを使ったイヤフォン『アルペックス クツヒモコードイヤフォン SLYP』。

ポケットにぐしゃぐしゃに突っ込んでから取り出した状態

普段から外出中も仕事中もイヤフォンを使っているんで、常時イヤフォンを持ち歩いていて、普段使っているイヤフォンは使わないときはポケットに突っ込んでしまうことが多い。そうすると、使おうとしてポケットから取り出すと、イヤフォンが絡んでしまっていて、それをほどいてから使わなければならなくなる。

じゃあ、ケーブルが絡まないような、巻き取り式のイヤフォンとかを使えばいいんじゃないか、と思っていくつか買ってみたのだが、どうも巻き取り式イヤフォンは、巻き取り部分の機構がなめらかに動かなかったり、最初のうちはちゃんと動いていても、そのうちだんだん動きがしぶくなっていったり、巻き取りの仕組みのためか普通のイヤフォンよりも断線などの故障率が高い(3、4個使ってみての経験談)など、今ひとつ満足いくものがなかった。

ポケットから取り出した状態からでも、すぐに使える状態に

そこで、この『アルペックス クツヒモコードイヤフォン SLYP』。「絡まないようにすることが難しいならば、絡んでもほどきやすくすればいいじゃない(マリー・アントワネット風に)」。

実際、ポケットにぐしゃぐしゃに突っ込んでおいても、ケーブルが太いためか絡んでいることが少ないし、多少絡んでいたとしても、すぐにほどける。これならば使わないときにポケットに突っ込んだり、カバンに突っ込んだりと、気を遣わずにしまっておいても大丈夫。

これをBluetoothレシーバー『BTTC-200』と組み合わせて使うと、いつでもポケットに突っ込んで持ち運び、使いたいときに取り出して接続したいデバイスとリンク、micro USBケーブルが確保できる場所では使いながら充電、といった感じの使い方で、ほぼ充電切れの心配なしに一日中使い続けられる。

というわけで、ここ数年間日常的に微妙なフラストレーションを感じていたBluetooth+イヤフォン関連の問題がすっきり解消されて幸せになれたので、久しぶりに物欲日記を書いてみた。

まだ耐久試験が終わっていないから、それによってある程度評価の上下はあるけれども、Bluetoothレシーバー『BTTC-200』の方は1年程度もってくれれば上等、『アルペックス クツヒモコードイヤフォン SLYP』の方は半年程度もってくれれば十分だ。もちろんそれ以上使えるならそれにこしたことはないけど。

LaravelをWindows環境で使う

最近メインマシンをMacbookに移行したんだけど、Laravel4で作ったアプリケーションをWindows環境で動かさなければならない要件があったんで、Windows環境にセットアップして問題ないかどうか試してみた。手元にあるのがほぼまっさらなWindows8.1(on Parallels)だったので、それをベースに。

まずXAMPP for Windows をインストール。今だとXAMPP 1.8.3(Apache 2.4.7/MySQL 5.6.14/PHP 5.5.6)だった。

インストール後、XAMPPコントロールパネルからApacheを起動して、http://localhost/にアクセスできるかどうか確認。

続いてLaravelをcomposerを使ってインストールするために、まずはPHPにパスを通す。コントロールパネルのシステムの詳細設定-環境変数から、システム環境変数のPathにPHPのパス(C:\xampp\php)を追加する。

試しにコマンドプロンプトを起動して、php -iとか実行してちゃんとPHPにパスが通っているかどうかを確認。すでにコマンドプロンプトが起動済みだった場合、環境変数の変更を反映させるためにコマンドプロンプトを再起動。

続いて、composerをインストール。コマンドプロンプトで、

cd C:\xampp\php
php -r "eval('?>'.file_get_contents('https://getcomposer.org/installer'));"

を実行してcomposer.pharをダウンロード。これだけだと使い勝手が悪いので、C:\xampp\php内にcomposer.batファイルを作成。内容は、

@echo off if "%PHPBIN%" == "" set PHPBIN=C:\xampp\php\php.exe "%PHPBIN%" "C:\xampp\php\composer.phar" %*

にしておく。これでコマンドプロンプトから、

composer update

みたいな感じでcomposerを実行できる。

でcomposer create-project laravel/laravelしようと思ったら、途中でgitがなくてこけた。gitも必要だったっけ。

Git for Windows(msysgit)をインストール。コマンドプロンプトから使いたいんで、インストールオプションで実行スタイルを選択するところで、「Run Git from the Windows Command Prompt」とか、gitにPathを通してくれるオプションを選択する。

もう一回コマンドプロンプトを再起動。Laravelアプリケーションプロジェクトを作りたいディレクトリを適当に作成する。

mkdir c:\laraveltest
cd c:\laraveltest

あとは、

composer create-project laravel/laravel .

今度はエラーも出ずにプロジェクトの作成に成功。Apacheからこのプロジェクトディレクトリを参照したい場合は、C:\xampp\apache\conf\httpd.confから、

DocumentRoot "C:/xampp/htdocs"
<Directory "C:/xampp/htdocs">

となっている部分を、

DocumentRoot "C:/laraveltest/public"
<Directory "C:/laraveltest/public">

なんて変えてから、Apacheを再起動すると、http://localhost/で今作ったプロジェクトにアクセスできる。まあC:\xampp\apache\conf\extra\httpd-vhosts.confとC:\Windows\System32\drivers\etc\hostsを使って、バーチャルホストにしておいた方が便利だろうけど。

前にWindows環境でLaravelを動かしたときは、mcryptとかのPHPモジュールを有効にしたり、timezone設定を追加したりとかしないといけなかったような気がするんだけど、今はそういう問題はないんだな。

このくらい手軽に動くなら、ピュアPHPで作れるようなアプリならば、Windows環境でも作りやすそうだ。