けいまさんですけど

死ぬ気でやってりゃ、そりゃ死ぬわ

はじめに

もういくつ寝るとマチ★アソビ。

マチ★アソビ

当ブログでもしばしば話題にしている、徳島で行われる年2回のガチイベント。

僕が徳島を好きな理由として、このイベントがあることは理由の1つとして挙げられると思います。
(他にもちょっと常軌を逸した県民性とかも好きですがまぁそれはそれとして)

こうどなじょうほうせん

マチ★アソビは、とにかく情報戦が激しいのです。
イベントが近づいてくる今現在のところ、まだイベントの情報開示は半分も終わってないと思います。
そういう情報をすぐさまキャッチするために、Twitterなどのツールを使って情報を集めなければなりません。

情報を集めて整理すること

集めた情報は整理しなければなりません。
具体的には・・・

  • どこで何が行われるのかを把握する
  • それを一覧管理する
  • そのなかで行きたいものをピックアップする
  • 当日には節度を守り体調管理を充分に行いイベントを楽しむ

ぶっちゃけ上記2点はマチ★アソビのフライヤーが公開されればOKなのですが、そのフライヤーの情報は、場所ごとのイベントが列挙されているだけ(これだけでも価値ある情報です!)となります。
まぁ慢性的なリソース不足だったりで難しいのは知っていたので仕方ない感じです。

ともあれ、僕がずっと欲しかったのは、「このイベントの裏番組なんだっけ」を一望できることでした。
そんなわけでマチ★アソビvol11くらいから色々思案していたものがやっと形になったので公開します。

マチ★アプリ

「ないものは作れ!」の精神で制作しました。構想2年、制作2週間。

現在は評価段階のベータ版として公開しています。
そのため、表示されている情報は「マチ★アソビ vol.11」の内容です。
マチ★アソビの前夜祭が24日ごろに行われるので、そのあたりからvol.12モードに切り替えようと思います。

マチ★アプリでできること

  • イベントの日別表示
    • 左にスワイプ(画面左上の[三]をタップ)して表示される表示ON/OFFパネルを切り替えることで、会場ごとのイベントの表示/非表示を切り替えることができます
    • 例えばボードウォークは興味ないね!って人はチェック切れば消えるので可視性UP
  • 公式Twitter、ハッシュタグの確認
    • 画面右上の鳥アイコンをタップすると表示されます
    • 画面下部のタブを切り替えて表示を切り替えます
    • ハッシュタグページでは、画面下部の入力ボックスみたいなのをタップするとツイートできるっぽいです

実装したいなーって思ってるもの

以下はまだ実装してないのですが、なんとか頑張って実装したいですね。。

  • イベントをふぁぼる
    • 行きたいイベントをタップしてお気に入りに追加
    • お気に入りに追加したイベントだけを表示する機能
    • ふぁぼを集計して人気のあるイベントとか事前に確認できたら楽しそうだけど、一気にめんどくさくなる雰囲気 is ある

技術的統括

苦労した点

画面を左から右にスワイプすると、カレンダーの表示ON/OFFスイッチが出てきます。このスイッチの切替でカレンダー部分のデータが切り替わるロジックがけっこうきつかったです。
使用しているカレンダーライブラリがデータをチェックしているのですが、そのチェックをすり抜けるようなデータ操作をすると想定外の動きをします。
なので、データ操作する部分は気をつけて(そして時にまわりくどいような)データ操作を行うようにしました。
これに気がつくのに結構かかった。。。

OnsenUIについて

いわゆるモバイルUIフレームワークとしてOnsenUIを採用しました。

最近はIonic Frameworkが結構人気っぽいのですが、あえてOnsenUIを選んだのは、まぁAndroid Bazzar and Conferenceで色々とお話を聞いたからという。

使い勝手に関して、割と素直ではあるのですが、CSSとして提供されているけどComponentがないケース(ButtonBarとか)があって、そこはやや苦労しました。
あと基本的にDirectiveのコードは読まないと何やってるか理解できなかったり、うまくUIを構築できなかったりしますね。。
あんま良い考え方ではないですしOnsenUIに限った話ではないですが、せっかく楽するためにフレームワーク選んでいるのに、なんかあった時に実装まで掘るの、ちょっと手間だなぁとは思います。

色々言ってますが、HTMLで実装できるくせに(とあえて書く!)サクサク動くのは時代の進歩すげーなぁと思いました。

(ちなみにカレンダー部分は重い、これは仕方ないね)

github

PullRequestやご意見などあればどうぞー。

まとめ

マチ★アソビ楽しみですね

はじめに

今日の東京はクソサムイ。。。皆様もお体壊されないように。。。

Docker

Docker meetup #2 というイベントに行ってきた。

僕はここ半年くらいはどっぷりフロントエンドばかりやっており、サーバーサイドはてんで分からず、いつの間にかサーバーサイドは「食わず嫌い」改め「触らず怖い」になっていた。
(LAMP環境みたいなのは構築できますが、複数台構成とかは経験がない。。)
でもDockerに関する発表を見ている限り、全然怖くないじゃん、という感想になった。

そもそもDockerは現行の仕組み上、シェルスクリプトのような感じで書くことが出来る。1行1コマンドのような感じ。
このあたりの気軽さは、その仕組み上がっちりした感じになるChefと比較すると明らかに敷居が低い。

そんなわけで、かねてよりちゃんと実装し直さないといけないなと思っていた、とあるTwitterボットをDocker上に載せることにした。

Google Compute Engine

Docker meetup #2の会場はGoogleの東京オフィスだった。そこで500ドル分のクーポンを貰った。
これを使わない手はないし、Googleの人もGCEでDocker使いましょう!みたいなこと言ってたので使ってみた。

GCE自体は、GoogleのUIで操作できるAWSという印象。実際提供しているもの自体はそこまで違うわけでもないし、そりゃそうなんだけど。
gcutilというツールがあり、基本的にはこれを使ってSSH接続したりする。直接SSHコマンドもOKなんだけど、gcutilは鍵のやり取りなんかもうまくやってくれているので楽。

あと財務管理が楽だという話もあるようで。詳しくは以下スライドをチェック。

Ruby

もともと運用していたTwitterボットは、Webサービスを使って静的にツイートさせていた。
ただ、元となるデータがGoogleスプレッドシート上で管理してあったので、これを直接参照できるようにしたかった。
とりあえず、まずはツイートする「仕組み」を作成することに。

Rubyのtwitterモジュールで、ファイルを実行するたびに(ruby twbot.rb)ツイートするようにした。
twbot.rbでは、だいたい以下の様なことをやっている。

  • 「データソース(Googleスプレッドシート)からデータを取得」
  • 「記録しておいたindexをインクリメントし、それを取得データの配列のindexとして取得」
  • 「取得データのツイート」
  • 「前回ツイートした配列のindexを記録」

なんでRubyかというと、知っている限り一番ラクに目的を果たせるのがRubyのtwitterモジュールだったから、という。

Google Apps Script

上記サイトを参考にしつつ、スプレッドシートのデータをJSONとして得るクチを作成した。このスクリプトの場合は全件をJSONで返すし、ボットスクリプトで「どれをツイートしたか」を保持する仕組みが必要になる(というか僕が作ったものはそうなっている)。

けれど、実際やるんだったらGAS側でカウンターを保持するようにするのが色々楽かもしれない。getSequence()とかそういうノリで、実行するたびに1件ずつ取得していく感じ。

結果

たまに壊れてる時ありますが、原因調査中だったりします。

ともあれ、無事にボットを動かすことが出来た。

まとめ

Docker面白い。うまくやったら結構いいかんじなのでは。

追記

ふと思ったが、これJenkinsでやればいいやんけ案件だった

はじめに

ここ最近は花粉症の薬の副作用で寝てしまうことが多くなっており、かなりつらい日々を過ごしております。そろそろ真剣に専門医のお世話になろうかと考えています。

事の発端

2010年10月ごろに買ったiMacは、僕が保有しているマシンの中でもかなり信頼しているマシンで、動画作成からプログラミングまで幅広くこなしておりました。

ただ、最近はどうも動作に倦怠感を感じるようになりました。おそらくはiMac以外のマシン(VAIO XやVAIO Pro)がSSDになったことで相対的に性能が下がったように感じられるようになったのが原因だと思います。
それでもCPUはSandyBridge世代ながら3.2GHzのCPUだったり、メモリはマザーボード限界の16GBまで増設しているので、まだこんなもんじゃないだろう、ということで、やきもきしておりました。

そんなある日、作業中に聞いたこともない「バリバリバリ」という異音を発しました。ファンが何かに干渉しているようです。これは良くないので電源を落とし、かねてより気になっていた内部のホコリ掃除を行うことにしました。

iMac Mid 2010 SSD換装

異音の原因は目視できず。というかiMacのファン部分は結構深い位置にあるので、マザーボードなどをはずさないとアクセスできない、でもかなり厳重にビス止めされていて、戻ってこれなくなるのが怖かったので諦めました。
ホコリは想像よりも酷くなかったですが、エアダスターと掃除機であらかたホコリを片付けて組み直しました。

iMac Mid 2010 SSD換装

その時にふとHDDドライブが目に入りました。「そういえばHDDドライブをSSDに入れ替えるとパフォーマンス良くなるんだっけ」と思いつつiMacのガラスを付けました。

それからは異音もなく快適に使っていたのですが、増税前ということもあり、SSD換装したiMacはいったいどのくらいのスペック・モンスターになるのか興味深かったのと、あとTwitterのわるいひとが耳元で囁いたのです。。。

SSD換装

そんなわけで購入しました。

ちなみにですが(というか換装作業やるまで気が付かなかったのだけど)、iMac Mid 2010はSATA2です。
上記SSDはSATA3接続でのRead 500MB/sというカタログ値を出しているので、完全にオーバースペックなSSDです本当に(ry
そんなわけで性能は理論値のおよそ半分くらいしか出ません。。。
(ベンチマーク結果ではHDDとは比較にならないくらい速度が出ているので、まぁ良いのですが、、、)

さて、早速届いたSSDを開けてみると、「軽い!薄い!小さい!」。

iMac Mid 2010 SSD換装

近くにあったペットボトルと比較しても、この小ささがお分かりいただけるかと。

HDDは鉄の塊なので、「よっこらせ」と持ち上げる感覚があります。SSDもHDDと似たような機能を提供するので、けっこうずっしりとしているのかと思ったら、もう軽々と持てるので驚きです。

iMac Mid 2010 SSD換装

iMac Mid 2010 SSD換装

こんな感じで3.5インチHDDのフォルムを再現するゲタを付けてやって設置しました。

ネジがトルクスドライバーを必要としていたのですが、HDDドライブを止めていたネジ穴のサイズが持っていたトルクスネジと微妙に合わず、仕方なく手持ちのマイナスドライバーで作業したり(そしてドライバーの先端がへし折れたり。。。)苦労しつつ、なんとか作業完了となりました。

ひとまず仮組みした後、予め用意しておいたMavericksのインストールUSBを差し込んで、SSDを初期化後OSインストールして作業完了です。

(ただ、この後に「Trim命令の有効化」と「HDD冷却用ファンの回転速度を下限値に設定」という作業を行っています。詳しくはググってね)

実測結果

実行環境:
OS: OS X 10.9.2
CPU: 3.6 GHz Intel Core i5
RAM: 16 GB 1333 MHz DDR3

HDD(Apple純正ですが、ラベル見たらHitachiって書いてあった)

Xbench 実行結果(HDD)

まぁこんなもんだと思います。。。
ReadよりWriteのほうが早いのがちょっと気になりますね。。。やっぱ何かおかしかったんでしょうか?それともこれが正常?

SSD (CFD)

Xbench 実行結果(SSD)

さすがSSD。Sequentialの値もそうですが、Randomの値が100倍以上違うケースもあり、SSDすげー!という感想です。
ただ、SATA2の性能限界にあたっているので、もしiMacがSATA3を搭載していたら、と思うと、まだこの値が伸びるということですね。。。

まとめ

SSD換装して(OSもクリーンインストールして)iMacの挙動が2010年当時の体感値に近づいた印象です。ただ、今度はCPUの性能限界が感じられるようになってきました。。。まぁCPUの換装はやらないかな。。。

はじめに

そう言えば書くの忘れてた。。。

あと思ったよりもDL数伸びてないので宣伝ついでに。

Muzei 飯テロ.in Plugin つくりました

@masawada さん達のチームが開発している飯テロ.inというサービスが有ります。

こちらのサービスのAPIにタダ乗りさせてもらう形で、「Android端末の壁紙を周期的に変更するアプリ」を作成しました。
定期的に飯テロ画像を取得し、壁紙にします。昼飯時にAndroid端末を見て不意の飯テロにもだえ苦しむ。合言葉は「てのひらに飯テロを。」。

このプラグインはMuzeiというアプリのプラグインとして動作します。

開発背景

Muzei

このアプリ(プラグイン)は、まずMuzeiというアプリのプラグインとして動作します。

Muzeiを一目見て、「おっこれでアプリ作ってみたい!」と思いました。
MuzeiのAPIおよびソースコードは公開されており、誰でも自由に使うことが出来ます。そしてAPIの使い勝手も良いので、非常に簡単にアプリを書くことが出来ました。
また、「単なる壁紙チェンジャー」としてではなく、そのデザインも非常によく出来ており、常用するに耐えられるおしゃれ感を勝手に出してくれたりします。
アプリ制作の初学者が最初に飛びついても良さそうな気はしますが、もしかすると予期せぬ複雑さを持ってるかもなので、要検証というところではあります。

mstr.in

もうひとつ、飯テロ.inの独創性も、僕がアプリ作ってみたい!というハートを揺さぶりました。
こういうサービスがずっと欲しかったのです。「メシ画像を投稿する」これだけですが、非常に良い感じです。このくらいのシンプルさが丁度よい。

まとめ

「Muzei 飯テロ.in Plugin」、是非使ってみてください。僕も使ってます。

ちなみにこのアプリはgithubでソースコードを公開しています。gradleの設定とか頑張った気がします。

はじめに

人生24年目にして人生の迷走期に入っています。誰か僕を導いて下さい(

#libcodingso at 2nd Infinite

numaさん主催の大人気イベント「Live Coding de Night」の2回目に参加してきました。

前回は事故ったので、今回は徹底的にミスらないように対策しました。

  • 事前にコードをタイピングして10分くらいで終わることを確認した
  • ↑で書いたコードを紙で印刷してカンペにした
  • 本番で使うPCでも入念にチェックした

そんなわけで、前回のリベンジを果たすべく頑張りました。

イベントの感想

凄く楽しかったです(小学生並の感想)

numaさん、僕を入れて6人がライブコーディングしました。皆さん個性的だったのと、結構Vim派が多くて、IDEに頼るコーディングをしていた俺はちょっとVim頑張らないとなーと思いました。。

あと、僕を除くと全員が林檎のロゴが付いたPCを操作していたのをMCが指摘していた中、僕だけが赤いVAIOで珍しがられるという珍事があったりw

終了後の打ち上げも非常に面白い話が聞けたり、店員がノリノリだったりで面白かったw

つくったもの

WebAudio APIでVisualizerを作成しました。

本番で伝え忘れていたのですが、「Visualizerは、つくれる!」ということを説明したかったのです。そりゃ確かに波形の意味とか数学的センスとか音響の知識があるともっと色んな事ができるんですが、これらの意味を知らなくても何となくリアルワールドの状況を収集してデジタルに可視化することは簡単にできるんだぜ!ということを示したかった。

参考にしたサンプルコードがあって、それは非常に良く出来ている(そしてうまくカプセル化されててグローバル汚染などにも配慮されている)のですが、意味がいまいち分かりづらかったので、べた書きできるように再解釈してみました。

追記:
書き忘れてたw 上記リンクで2つのリンクがあるのですが、ひとつはライブコーディングでつくったもの(に解説をつけたもの)。もうひとつは、ライブコーディングしたものを時間かけてD3.jsなどを使うとこういうのも作れるよ、というサンプルです。ちょっとD3.jsがクセ強くてアレですが、色々とできそうです。

結果

当日に順番が決まって(抽選するScalaプログラムをライブコーディングするnumaさんスゲーって思ったマジで)、一番最後の登壇で少し押し気味だったのですが、何とか時間内にやるべきことをやれて良かったです!

ただあんまりコードの解説を入れることが出来なかったのと、できればマイクではなくてLINE入力で直接DJブースから音声引き込みできれば良かったかなぁ、と思いました。機材買うか。。。

余談

WebStorm使ったんですがWebAudio APIってドラフトだからうまく補完してくれないんですよね。。。それがちょっとつらかった。

今後

とりあえずネタ切れなので、次からは聞く側に廻りたいっすw

あとLive Coding de Nightでは皆様のご登壇・ご参加をお待ちしております。