Tingbotを少し試してみた。
前回は、組み立ててサンプルアプリを動かしてみただけだったが、もう少しいじってみた。
イメージファイルの表示
アニメーション GIF はサンプルアプリで試せるので、 それ以外でどんな画像フォーマットが表示できるのか試してみた。
試した結果は次の通り。
フォーマット | 表示結果 | 備考 |
---|---|---|
GIF | ◯ | アニメーションもOK |
PNG | ◯ | アルファチャンネル付きもOK |
JPG | ◯ | |
MBP | ◯ | |
WebP | △ | エミュレータでは利用できず |
それを表示した画面写真は次の通り。 右下方は 33.3 %の赤、青、緑の半透明 PNG を重ねている。
よく使われる画像フォーマットは問題なく表示できる。
WebP は実機では問題ないが、エミュレータではエラーとなり起動もできなかった。
日本語の表示
日本語を表示できるのか?
これは日本人にとっては重要なのだが、英語圏の人々からは軽視されている機能なので試してみた。
結果としては、表示可能。
ただし、次の 3 項目に注意する必要あり。
# coding: utf-8
でソースコードのエンコーディングを指定すること。
さもないとコード内に日本語を含むと accii 文字として解釈されてエラーとなる。- Unicode文字列を使うこと。
リテラルではu'ほげ'
を使い、ネットワーク越しに日本語を取得したときにはunicode()
関数や.decode()
メソッドで Unicode 文字列に変換する - フォントをアプリに同梱して、コード内で指定すること
フォントファイルのファイル名にハイフン-
を含んでいるとエラーとなるので注意。
アプリを公開する場合、同梱するフォントは再配布可能なライセンスである必要があるので注意。
フォントファイルのフォーマットは TTF でも OTF でも OK。
サンプルコードはこんな感じ。
# -*- coding: utf-8 -*- import tingbot from tingbot import * # setup code here @every(seconds=1.0/30) def loop(): # drawing code here screen.fill(color='black') message = u'日本語もOK' screen.text(message, xy=(0,0), color="white", align='topleft', font='fonts/NotoSansCJKjpRegular.otf') screen.text(message, xy=(0,45), color="blue", align='topleft', font='fonts/ipagp.ttf') screen.text(message, xy=(0,80), color="aqua", align='topleft' , font='fonts/ipamp.ttf') screen.text(message, xy=(0,120), color="lime", align='topleft' , font='fonts/cinecaption226.ttf') screen.text(message, xy=(0,160), color="yellow", align='topleft', font='fonts/TanukiMagic.ttf') screen.text(message, xy=(0,200), color="fuchsia", align='topleft', font='fonts/kiloji_p.ttf') tingbot.run()
これを表示した結果は次の通り。
Webhook
この機能は使い方によっては面白いことができそう。 URL を指定して、ネットワーク上の画像を表示したり、API にアクセスしてデータを取ってくることもできるのだが、 Webhook はネットワーク越しに Tingbot にデータを渡すための機能。
例えば、次のようなコードを Tingbot で実行する。
# -*- coding: utf-8 -*- import tingbot from tingbot import * font = 'NotoSansCJKjpRegular.otf' font_color = 'white' wh_name = 'my_webhook' screen.fill(color='black') screen.text('Waiting...') @webhook(wh_name) def on_webhook(data): data = data.decode('utf-8') screen.fill(color='black') screen.text(data, color=font_color, font=font) tingbot.run()
その状態で次のコマンドを実行する。
$curl -X POST -d '日本語!!!' "http://webhook.tingbot.com/my_webhook"
するとデータとして送った文字列を表示させることができる。
マニュアルにも書かれているが、IFTTT の Maker チャネルを使えば、様々な Web サービスをトリガーにして Tingbot にデータを渡して表示させることができるだろう。
ただし、使い方には注意が必要で、Tingbot にデータを渡すには次のような URL に文字列を POST してやればよいのだが、 webhook 名は予めどこかに登録しておく必要もなく自由に設定できる。
http://webhook.tingbot.com/<webhook名>
ということはたまたま、Tingbot ユーザの誰かと使っている webhook 名が一致してしまうと、見知らぬ誰かにデータを見られてしまう可能性や見たくもないデータを見てしまう可能性がある。
ある程度、ランダムで長い webhook 名を使えば、当てられることも少ないと思うが、一度送ったデータは次のデータを送るまでずっと Tingbot で取れてしまうのであんまりプライベートなデータを送らないほうが良いだろう。
逆に大勢にデータを配信するのに使えるかと思ったが、他人も同じ webhook 名にデータを送信できるので容易になり済ませてしまう。
そういう使い方もしないほうが良いと思う。
おおらかなパブリック性をもった Pub/Sub(誰でも投稿できて、誰でも見たい人に配信される)と捉えれば、面白い使い道があるかも。
このエントリーで書いた 3 つのアプリは次のリポジトリで公開している。 tingbot_samples
Tingbot が届いたので動かしてみた。
Kickstater で申し込んでいた Tingbot がやっと届いたので触ってみた。
ポチった時の計画だと5月に出荷予定だったので、約4ヶ月遅れで手元に届いた。
どんなもの?
Rasphedy Pi を中に組み込んで写真用なモニター付きの小型端末にするキット。 自分でアプリを書いて実行させることができる。
ハードウェア
ものとしては 3.2 インチのタッチモニターと4つのボタン。これとラズパイを包む筐体からなる。 ラズパイは自前のものを使う。なんとなく購入して放置していた RPi3 を組み込んで組み立てた。
モニタとラズパイを接続するコードの接続ピンさえ間違わないように注意すれば組立自体は簡単。ただし、筐体を閉じるネジが極小なので精密ドライバーがないと閉められない。
ソフトウェア
ソフトウェアとしては Tingbot-OS というものが提供されており、それを SD カードに書き込んで起動すると動く。
SD カードへの書き込み方も セットアップガイドの通りやれば特にハマりどころもなかった。
Tingbot-OS と言っても Raspbian の一部を上書きしただけのもののようで、起動後は Raspbian のデフォルトユーザで SSH 接続もできる。
開発環境
Tide という Electoron ベースの IDE が開発環境として提供されている。 リリース前にGithubに上がっていたものは起動しようとしてもうまくいかなかったので心配したが、Mac 用に配布されているビルドは問題ない。
この IDE ではコードを書く他に次のことができる。
同じネットワークにある Tingbot を自動検知してくれるので、なんなく接続できる。
Tingbot-Python
Tingbot アプリは Python で実装できるようになっている。 Tingbot 用に用意されている機能は次の通り。
- 画面上に図形を描画する
- イメージファイルやテキストを表示する
- 画面タッチを検知する
- ボタンの押下、押しっぱなし、複数ボタンの押下の組み合わせ検知
- ハードウェア情報(IP アドレスやキーボード、マウスの接続状態)の取得
- 設定の保存
- Webhook
ちなみに Python のバージョンは 2.7 のようだ。
sys.version_info(major=2, minor=7, micro=10, releaselevel='final', serial=0)
起動
起動すると、2 つのアプリがインストールされている。ひとつは Kickstarter のバッカーのリストを表示するもの。 もう 1 つが、Terminal。キーボードを USB で接続すると、コマンドの入力、実行が可能。
左右 2 つづつある 4 つのボタンのうち、外側のボタンを押すとアプリの切り替え、 内側の 2 つを同時押しすると HOME に戻るようだ。
サンプルアプリの実行
Tide には 5 種類のサンプルプログラムがついている。 それらを順に実行してみた。
-
- まあ、何はともあれスタートはこれから。
- まあ、何はともあれスタートはこれから。
Show an Image
- アニメーション GIF で猫が走る
- アニメーション GIF で猫が走る
Buttons
- 本体ボタンのサンプル。押す毎にカウントアップ/カウントダウンする
- 本体ボタンのサンプル。押す毎にカウントアップ/カウントダウンする
More Buttons
- これも本体ボタンのサンプル。ボタンの DOWN/UP、長押しのサンプル
- これも本体ボタンのサンプル。ボタンの DOWN/UP、長押しのサンプル
Touch
- 画面タッチのサンプル。タッチしたところに点を打つ。
- 画面タッチのサンプル。タッチしたところに点を打つ。
いずれも、TingBot の基本的なハードウェアの操作サンプルとなっている。
なかなか遊べそうだ。
東京防災アイデアワークショップに行ってきた
9/4 に実施されたオープンデータ利活用 防災アイデア ワークショップに参加した。
ネットのニュースか何かで見かけて、すぐに申し込んでみたのだが、 抽選とのことだったので、当たるかなぁと思ったいたら当選メールが来た。
当日は電車の遅延に巻き込まれ少し遅刻してしまった。
会場についてみると、すでに始まってはいたが、神武直彦氏が主催者挨拶と概要説明しているところで、まだ内容の説明には至っておらず支障はなかった。
参加者は約 40 人で 5,6 人づつチーム分けされていた。受付で所属チームを知らされたので、指定されたチームのテーブルに着いた。
プログラム
ワークショップのプログラムは次の通り。
- 主催者挨拶・概要説明
- イニシャルトーク
- チームビルディング
- フィールドワーク
- 昼食
- 午後のイニシャルトーク
- データサポートの説明
- アイデア創出のためのワークショップ
- 最終発表
- ドット投票
- 講評
- 表彰
- 閉会挨拶・写真撮影
- 閉会
イニシャルトーク
最初はインプットからということで、墨田区企画経営室情報システム担当課長 内田正代氏から「墨田区の特徴」ということで、ワークショップの開催地である墨田区の地域的な特徴や情報発信の取り組みの説明があった。
オープンデータは昨年から公開を始めており、区としても推進していくとのことで今後に期待だ。
オープンデータポータルサイト 墨田区公式ウェブサイト
最近、区のホームページをリニューアルしたとのことで、キーワード検索を中心のナビゲーションに変更したとことだった。 見てみると、従来の自治体のホームページのトップと言えば、ページのインデックスになっているところがほとんどだが、 墨田区のホームページでは検索ボックスが最初にある。そしてスマートホンでも使いやすそうなデザインとなっていた。 検索に慣れていない人が迷ってしまうのでは? と気になったが、メニューも備えており、一応、階層的に辿れるようだ。
続いて東京都総務局情報通信企画部情報通信施策推進担当課長 斎藤圭司氏より「東京都のオープンデータの取り組み」の説明があった。
まだまだ PDF 中心だが公開はしている(東京都オープンデータ一覧(試行版)|東京都)。
データを公開するとそれを使って、GD Freak のようなサイトが可視化したりして新たな気づきや価値の創造に繋がる可能性を感じており、今後、データを増やしていきたいとのことだが、なにぶん費用もかかるので... とのことだった。
特に防災ということでは東京都防災マップを公開しており、地理情報の上に載せて提供していきたいとのこと。 すでに、避難所やコンビニ、ガソリンスタンドなどはマッピングされており、東京での災害時には役立つだろうと思った。現在は PC 向けなデザインなので、スマホから使いやすい UI も用意してもらえればと思った。
チームビルディング & フィールドワーク
イニシャルトーク後は、チームでの活動。
チームメイトは、学生 1 人と社会人の混成チーム。学生は神武直彦氏のゼミの学生のようだった。
アイスブレークとして、6 つのマスに名前や日頃の防災活動、この夏のニュース等を書き込んでお互いに説明した。
その後、このあとのフィールドワークに出かけるコースの確認と、どのような観点で見て回るのか?といった点を軽く話し合ったあと
フィールドワークに出かけた。
フィールドワークは会場となっているリッチモンドホテル プレミア東京押上から墨田区役所までの指定コースを歩きながら話し合った観点で見て回るというものだった。早朝、雨が降っていたけれどフィールドワーク頃にはやんでおり、それほど日が照っていないので、まあまあの夏のフィールドワーク日和といったところか(暑いのは暑かったが)。
墨田区で防災というと、木造家屋が密集したいわゆる木密地域を思い浮かべるが、フィールドワークのエリアは、どちらかという住居よりも事業所が多いようだった。各所の案内図や防災設備(消化器や町内会の防災倉庫)などを写真に撮りながら歩き、墨田区役所を往復した。 歩いてみた感想としては、思ったより避難所の案内が少ないのと、公衆トイレも少ないなぁということだった。
会場まで帰ると昼食の時間で、ホテル 1F に入っているスーパーで惣菜とおにぎりを買って、チームメンバーとフィールドワークで見たものを話ながら食べた。
午後のイニシャルトーク
午後の最初は墨田区都市計画部危機管理担当防災課長 菅原幸弘氏から「墨田区の防災対策と課題」の話があった。
内容は「すみだ防災パンフレット 地震に備えて」を見ながら以下のような内容についての説明だった。
- 墨田区は関東大震災で被害が大きかった。
- 本所は江戸時代から都市部
- 向島は木密地区
- 地震以外の災害への対策は?
- 荒川が万一決壊すると2回床下で2週間水が引かないと言われる
- 識者から近年の意見を聞いている
- 既存の増水対策は割りと設備が整っている
- 複合災害への対策は?
- 区の基本計画で複合対策を意識し始めている
ワークショップ
いよいよ、このイベントのメインのワークショップ。テーマは「避難のためのアイデア」ということだったので、それに沿ったチームテーマをブレストしながらまずはアイデア出し。付箋にアイデアを書いてはホワイトボードに張り出した。30 ほどのアイデアが出たところで、メンバー全員で良いと思うアイデアに印をつけて評価。結局、避難所までのナビゲーションアプリという案でまとまった。
方向性が定まったところでブラッシュアップ。
このアイデアの課題としては次のような項目が挙がった。
- 災害時にしか使わないものなら、結局災害時にしか使われない
- ナビゲーションって、最初どっちに進めばよいかがわかりにくくない?
- ありがちなないようなので何かひとひねり必要
などなど。
これらに対して出たアイデアは次の通り。
- やっぱ墨田区ってどこからでもスカイツリー見えるよね! これを利用して方向示せばわかりやすいんじゃない?
- 普段は避難所の代わりに観光スポットを案内すれば、予めのインストールも促せるんじゃない
- アプリとしての特徴も出る!
というような議論をして、アイデアが固まって来たところで、 ステークホルダー分析と、体験スケッチボード分析していった。
ステークホルダ分析
ステークホルダ分析では、誰が運営するのか? サービスとして持続するにはマネタイズもできないとな。 などと考え次のように考えた。
体験スケッチボード
体験スケッチボードと言うのは今回初めて知ったのだが、「サービスの利用体験を、顧客の目線で感情豊かに捉えるための道具」でユーザ体験をステージに分けて、各ステージでのユーザの行動と思考を同時に考えてユーザの感情の変化を曲線で表す。そこからサービスに必要なもの・仕組みを考察するというもの。
今回作成した体験スケッチボードは次の様になった。
アプリの内容
ざっくりではあるが、アプリの内容は次の様に決まった。
- 通常時はスカイツリー周辺の観光案内アプリ
- 行きたい場所を選んで、スカイツリーにスマホをかざせは、AR チックに方向を矢印で示す
- 災害時には、スカイツリーにかざすだけで最寄り避難所を示す。
- スカイツリーと避難所の座標と、GPS による現在位置座標がわかれば方向を示せるのでオフラインでも機能する
- PUSH 通知で災害状況も通知できる
サーバサイドには次の仕組みが必要であろう。
- 観光スポット情報の管理
- 観光スポットに関連した広告の管理
- 避難所情報の管理と更新情報の発信
- 災害時の情報配信
発表
チームごとに、アイデアを発表。各チームの内容はざっくり次の通り。
- 災害時に表示が変わるデジタルサイネージ
- デジタルサイネージによる情報提供
- 避難弱者を救う地域医療 SNS
- バルーン型ディスプレイによる避難誘導システム
- 地元住民を活用した災害時情報提供
- スカイツリーを利用した避難所ナビ
- 避難所ナンバリング:コード統一システム
各チームともなかなかおもしろいアイデアが出ていたと思う。
特にチーム 4 のアドバルーン型のディスプレイで避難所に誘導するアイデアは、誰にでも 避難所の場所がわかりやすく示せ、興味深かった。
表彰
各チームのアイデアは参加者全員で評価した。 評価軸は次の 3 点。
- 実現性
- 革新性
- データ活用の有用性
我々のチームは、すぐにでも作れそうな内容だったので、実現性でトップとなり、賞品(慶応義塾のボールペン)を頂いた。 各評価軸毎の表彰のあとは最優秀の発表。 すでに自分たちは表彰されていたので、どのチームのアイデアが獲るのかなと思っていたら、最優秀も頂いてしまいました!
必要なオープンデータもすでに存在しており、すぐにでも実現できそうなことに加え、スカイツリーという象徴的なランドマークをうまく利用できている点が評価された。
優秀賞の賞品はスカイツリーのチケット。ただし、当日券(よく見たら、防災訓練用と書かれており、余り物だったのかな)。
感想など
個人的には優秀賞も貰ったし、楽しいイベントだった。
東京都が主催するオープンデータ活用イベントは初めてだったと思うが、今後も継続してほしい。 都側のオープンデータへの取り組みの活性化になると思う。
また、防災に限らず問題山積の東京都なので、こういったイベントから思わぬ解決や改善が生み出されるかもしれない。 しかも東京で住んだり、働いたりしている人々が、行政を利用、あるいは行政と協力してより良くしていこうという意識を高められるのは良いことだと思う。
小池都知事は情報公開を方針に掲げているが、データとして活用できる形で公開していただくよう願いたい。
関連リンク
Googleスプレッドシートのアドオンをリリースした。
Google スプレッドシートのアドオン Address2Geocode というのを作ってリリースした話。
これはなに?
Google スプレッドシート上の日本の住所に緯度経度を付加できるアドオン。住所の一覧にバッチで処理もできる。住所を記載したセルやカラムを選択し、変換ボタンをクリックすると、住所の右側のセルに緯度と経度を書き込む。 住所のあるデータを地図にマッピングするときに緯度・経度を求めるのに便利(だと思う)。 ただし、精度は番地レベル(ちなみに Google Maps などは号レベルで更に精度が高い)。
きっかけは熊本地震
減災インフォという Web サイトの運営に参加しており、地震などの自然災害は起こった際には情報を収集して再発信している。2016年4月14日の熊本地震以降も、活動している。 熊本地震で回ってきたデータのうち、200 ヶ所以上の避難所の住所の一覧というものがあった。添えられた依頼は「Geocoding API - 住所から緯度経度を検索」というサイトを利用して、緯度経度をつけてほしいとの事だった。できたデータは減災インフォで地図にマッピングしたり、他に活動している人たちに配って活用してもらおうというのが目的だった。 数カ所なら手作業したかもしれないが、200 ヶ所以上は流石に辛いと思い Google Maps API を利用したスプレッドシートのカスタム関数を作って対応した。 しかし、次のような問題があった。
- Google スプレッドシートはちょっと操作すると関数の再計算が走るのですぐに Maps API のリミットに達してしまう
- APIの規約で Maps API により得たデータは Google Maps 以外で利用するのは NG
- カスタム関数だと別のスプレッドシートで使いたい場合にコードをコピー&ペーストして移植する必要がある。つまり配布しにくい
Google Maps API以外への変更
上記の 1,2 の理由により、Google Maps API は使えないなぁという結論に至った。1.は関数にせず、バッチ処理に変更するなどすれば回数のコントロールは可能だろうが、2 の制約のために作ったデータの利用に制限ができるのは嬉しくない。乗換先としては Yahoo!ジオコーダAPI も考えたが、「API経由で取得したデータを保存したり、二次利用することはできません。」との事なのでやはり NG。 色々探してみて、利用についてほぼ制限がなさそうな CSISシンプルジオコーディング実験 の提供する API を利用に乗り換えることとした。
カスタム関数からアドオンへ
カスタム関数だと上記の 1 で挙げたように外部の API を無駄にコールして、不要な負荷になりかねないし、3 で挙げたように配布にしにくい。 熊本地震でもまだ同様の作業が必要になるかも知れないし、今後発生する災害時にも必要になるかも知れない。せっかく作ったのだから利用しやすい形にしたい。ということで、スプレッドシートのアドオンサイトからすぐにインストールして使えるように最初に作った関数を基にアドオンを作って公開しすることとした。
はじめはナメてた
アドオン自体の実装はそれほど難しいものではなく、HTML と JavaScript で作ることができる。見栄えをそれらしくできる CSS も提供されている。 きっと Android アプリ同様に登録すればとりあえず公開されるのだろうと思いさくっと作って、登録してみた。
登録直後はレビュー待ちのステータスになった。すぐに公開状態になるのかと思いきや、一向に変わらない。 数日後、リジェクトされ、その理由がメールで送られてきた。
メールには Google Doc が添付されていて、不具合と UX の改善提案が記載されていた。エラーの画面キャプチャも貼り付けられており、思っていた以上に丁寧にレビューされていた。
指摘事項は次の項目
- 処理でエラーが発生し、しかもエラーハンドリングされておらず、組み込みエラーダイアログが表示されている
- 変換した緯度・経度を出力するカラムをユーザがわざわざ指定する必要があるのは使いづらい
- 処理終了を知らせるのにアラートでなくトーストを使っては? そうすればユーザは閉じるボタンを押す必要がない。
- ユーザを待たせる時間があるならローディングイメージを表示したほうがよい。
1.について、確かにエラー処理については自分でも足りないだろうなと思っていた部分だった。でも、地震発生時でニーズがある時にまずリリースしてそれから改善していこう思っていた。そんな甘く考えていた部分を的確に指摘されたのだった。利用していた API が日本語で住所を送らないと該当なしの空レスポンスではなく、サーバーエラー(500)を返してくるのも確認不足だった。
2,3,4 は不具合ではなく、うーんなかなか的確だなぁと思う改善の提案。 2.については、選択範囲のすぐ右のカラムが空ならば緯度経度を書き込む様に変更した。ただ、緯度経度を書き込む位置は自分で指定したいと日本人マインド的に思う人も結構いるのではと、指定できるようにもした。 3.で提案されたトーストについてはそんな機能があるとは知らなかった。変更してみると確かにトーストのほうが格好いいし便利だなぁと思った。 4 についてはちょっと困った。ぐるぐる廻るイメージを処理中表示しようと思って、フリーな素材はすぐに見つかったが、アドオンには HTML と JS のファイルしか含められない。プロダクトの一部としてイメージを入れることができないのだ。一箇所にまとまっていないと今後のメンテナンス的に面倒だけど、外部画像をアドオン内で表示できそうなので S3 にでも置いてそれを表示しようかと思ったが、画像のサイズがそれほど大きなものでなかったので、base64 変換してコードに含めてみてはどうだろうかと試してみると思った通りに動く。ということでコードに含める実装にした。
再レビュー、再々レビュー
Google の Add-ons Advisor 氏の指摘に沿って修正した後、修正したアドオンの更新の仕方が間違っていて再レビューまでに時間がかかったが、再度評価してもらった。で、またリジェクトされた。 理由は、「うまく動かない」とのこと。どうやらアメリカの住所を試しているらしい。日本語で表記した住所しか変換できないことを伝えたら、次のいずれかの対応を入れようとの返事が来た。
- もし日本語以外の入力だったら、日本の住所にしか対応していないことをユーザに示す
- 翻訳 API を利用して翻訳してから変換する
結局のところ、翻訳しても日本国内の住所にしか対応できないので、1 を対応して、再々レビューを受けた。 数日後、まだうまく動かないとの返事がきた。今度はきちんと日本語で試していると。 どんな住所を試しているのかと聞いたら次の文字列が返ってきた。
4-2-15銀座、中央区、東京104から0061 、日本
ああ、単に英語表記の住所を機械翻訳にかけただけなのね...。思わず笑ってしまった。それは予想してなかった。 そりゃあ、アメリカ人は普通、日本語の住所表記がアメリカの逆になっているなんて使うべきではない言葉なので修正してくださいんだろうなぁ。 日本語の住所表記はアメリカとは順序が違うんだよと説明して、いくつか住所のサンプルを送った。
そうしたら、動いたよという返事とともにアクセプトされた。
リリース
アクセプトされると公開状態となり、Addon ストアから見えるようになった。 結局、最初の申請からリリースまで半月ほどかかった。
おもったより時間がかかったが、自分の作ったものをしっかり評価して改善提案もしてくれる Docs Add-ons Advisor とのやり取りは楽しかった。
Code for Japan Summit 2014 に行ってきた。
2014/10/11 に開催されたCode for Japan Summit に行ってきた。
Code for Japan というのは、Code for America の日本版で、テクノロジーを活用して公共の課題に取り組み、より良くしていこうという団体。
存在は以前から知っていたが、イベント等に参加するのは今回が初めてだった。
最初の基調講演では SIX 代表の野添剛士さんの講演が特に良かった。 一言でいうと「作った」だけではまだ登山で言うと 5 合目で、ユーザの心を動かすものに磨き上げることが必要ということだった。 作る側としては、実現しているアイデアがどんなに奥深くてもバックエンドでどんなに高度なことをしていてもそれを使うユーザにとっては得られる体験がすべてである。その体験が心に響かなければアイデアや実現されている仕組みが理解されることもないという内容だった。 それが、氏がこれまでに取り組んだプロジェクトで具体的に説明された。よくわかり、よく”心に響く”講演だった。
午後は 3 トラックにわかれたセッションだった。自分は特に聞こうと思って行ったわけではなかったのだが、「コミュニティデザイン」セッションを聴いた。
5 人の実際に地域コミュニティ活性化の取り組みをしている方の発表のあと、パネルディスカッションという内容だった。 中でも印象に残ったのは、studio-L の西上ありささんの発表だった。ある地方自治体の美術館設立を通じた地域活性化の事例の紹介だったが、最初はなかなか参加してくれなかった住人の方々をいかにして巻き込んでいったのかという話が面白かった。 基本的には女性を巻き込めば男性も参加し始めるということで、おばさん、おばあさんの懐にどう飛び込むかが重要らしい。この事例ではイケメンの担当者を現地に住まわせ、かわいがってもらうという方法が有効だったとのこと。あと、現地で買えないお菓子を持って行くと「それが食べたい」という口実で集会に参加してくれるという。なるほどなぁと思った。 いずれの発表者の方も、これからの地域コミュニティ活性化には IT の活用が不可欠だという。その上で、地域の方だたの IT スキルの差をどのように埋めるのか、特に高齢者にどのように教え、使ってもらうかが重要ということだった。IT エンジニアとして自分にはなにができるだろうかと聞きながら思った。
これまでは IT エンジニアばかりのイベントには参加してきたが、そこでは聞けないエンジニアでない方々の話を多く聞くことができ、楽しいイベントだった。
Mozilla Open Web Day に行ってきた
台風が近づく中、 3331 Arts Chiyodaで行われた Mozilla Open Web Day in Tokyo に行ってきた。
思ったより人は少なく感じたが、盛況は盛況。Mozilla は大学といくつかの研究プロジェクトをやってたりらしく、参加者の年齢は若く感じた。
最初に以前から気になっていた FirefoxOS 搭載の開発用スマホ Flame の即売ブースがあったので、展示機をいじらせてもらった。スペックからすると、もっとカクカクした動きかと思いきや、結構サクサク動作だったので、衝動的に欲しくなり購入してしまった。隣のブースで売っていた Tech Booster の FirefoxOS 本も合わせて購入。この秋は FirefoxOS 向けのアプリにも挑戦してみよう。
さて、今回一番気になっていたのは、金曜日に KDDI が発表した開発キットなのだが、実物を見ることができた。 最初に全展示内容の LT 的な発表があったのだが、その中で何やら重大発表があるという。後ほどのセッションをお楽しみにと勿体つけるので、楽しみにしながら、Open Web Board の実物デモをみた。
Open Web Board 本体は上の 1 枚目の写真の上部の USB メモリみたいなやつ。結構小さいが、HDMI 端子と USB-A 端子、Wifi と Bluetooth を備え、Zigbee デバイスや mbed とも接続容易で、USB 端子に Web カメラだって接続可能という拡張性の高い設計。まさに IoT のためのデバイス。なかなか良さそうだ。 デモではセンサーからの入力を Zigbee 経由で Open Web Board で集め、Websocket でサーバに送信しているという。 Gluin という Web ベースのデバイス管理ツールも提供され、デバイス間の連携も簡単に行えるらしい。自分は組み込み系のエンジニアではないので、JS を使って拡張できる仕組みが用意されているのは助かる。
このイベントの冒頭で Mozilla 代表の瀧田さんもおっしゃっておられたが、FirefoxOS を IoT デバイスにも活用しようとしているらしい。Arduino にもチャレンジしたがやはり馴染みのない言語を覚えないといけないのはとっつきにくかった。FirefoxOS をなら JS で実装できるので、Web 系エンジニアにも始めやすだろう。 今後、Open Web Board はハッカソン等のイベントで配布するという。是非参加したいな。
あと、OpenStreatMap の人も参加していて、最近の OpenStreatMap についていろいろ聞くことができた。以前からかなり進化しており、びっくりした。特に地図を登録するツールが使いやすくなっていたので、久々に使ってみようと思った。
おっと、書き忘れそうになったが、重大発表というのは au から FirefoxOS のスマホが年内、クリスマス時期に出るらしい。わざわざ社長がビデオメッセージで発表したので出るのだろう。端末のデザインにも力を入れているとのことなので、こちらにも期待。
Chcolatyを使ってみた
普段、Mac か Linux を使っていてあんまり Windows を使う機会が減っているのだが、久々に Windows を触ってみた。
Windows って初期からセットアップしようとするとあちこちからインストーラをダウンロードしてって作業があるので Linux や Mac よりめんどくさいと思っていた。 apt や homebrew の様にコマンドラインからソフトをインストールできるという Windows 版パッケージマネージャで以前から気になっていた Chocolatey を試してみた。
インストール
インストールする前に Windows update で最新にしておく。インストールしたばかりの Windows だとそうしないと .NET フレームワークがインストールされていなくて warning が出ることがある。
cmd を管理者モードで起動する https://chocolatey.org/ をブラウザで開き、そこに乗っている次の文字列をコピー&ペーストする。
C:\Windows\system32>@powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin
少し時間はかかるが、後は自動的にインストールされる。
インストール後の確認として chocolatey version
を実行してみる。
これも若干時間がかかるが次の様な出力が表示されればインストール成功。
C:\Windows\system32>chocolatey version name : chocolatey found : 0.9.8.27 latestCompare : 000000000000.000000000009.000000000008.000000000027 verMessage : Latest version installed latest : 0.9.8.27 foundCompare : 000000000000.000000000009.000000000008.000000000027
パッケージのインストール
一度インストールしてしまえば、いろんなソフトウェアが cinst コマンドを使って簡単にインストールできる。
例えば、Git と Ruby をインストールするなら次のコマンドを実行すれば、ダウンロードからインストールの作業が自動的に実行される。
cinst git ruby
これまで、それぞれの配布サイトに行ってインストーラーをダウンロードしていたのと比べるとなんと便利なのだろう。
また、GitHub が開発しているエディタ Atom も今のところ Windows にインストールするには chocorateyを利用することを勧めている。
その他にも JDK などもインストールできる。 インストールできるパッケージはChocolatey Software | Packagesで探すことができる。
一度使ってしまうと便利で手放せなくなった。