コンデンサの隣からひとこと

TokyuRuby会議04に参加＆お手伝いしてきました

Ruby, イベント

肉の吉日10/29に開催されたTokyuRuby会議04に、スタッフとして参加してきました。

http://regional.rubykaigi.org/tokyu04

当日の雰囲気とかはTogetterなどを見ていただければ伝わるのではないかと思います。

http://togetter.com/li/197803

今回も、べろんべろんになりつつも、LTしたり、交流したり、独特の空間が生まれていました。Rubyのコミュニティにもっと触れてみたいという希望がある方にとっては、いろんなRubyistに酒に酔った勢いで交流できる良い機会なんではないかと思います。

Rubyに限る話ではないんですが、技術には興味を持ちつつも、あんまり勉強会などで幅を広げることに興味がない同僚などにも来てほしくて、そのためにはどうすればよいのか？というのは自分の最近の考え事だったりします。全くの初心者向けの導入をもっと気楽にやる方法ってなんだろう、という。

仕事からみだとRubyはほぼ関係ないので、Androidとかだとまだ関係がありそうなので、どうかなあ、とか。またそれは追々なのです。

いずれにせよ楽しい一日でした。関わった全ての方に感謝を。(Tシャツのデザイン素敵でした)

あみだくじ

何となく恒例になっているあみだくじによる抽選LTですが、毎回同じなのも芸がないので、今回はアニメーションを付けてみました。

で、何を使おうかと考えたところ、先日のHTML5とか勉強会で紹介されてたenchant.jsを採用してみることにしました。（Rubyと関係ないだろ、とか言わない）

enchant.jsとはUEIが公開している、Javascriptでゲームを作るためのエンジンのことです。JSなのにフレームレートを指定して、スプライトが使えるってあたりに、ぐっときて試してみたかったので、試してみました。BASICでスプライトとか触ってた人間にはたまらないです。

で、簡単ですがこんな感じでできあがりました。

サンプル。

そもそもJSに慣れてないのは差し引いて、ちょっとしたゲームを作るのはかなり簡単にできる印象です。また何か作って遊んでみたいですね。Rubyで同じくらい手軽に作れるとベストなんですが。

ソースは下記にupしてます。

https://github.com/kishima/Amida-js

ビール力の測定

以前、思いつきで作ったスクリプト(「TokyuRubyKaigi03におけるビール力の推定」)をリアルタイムに動かしてみたかったので、当日に作ってみました。

動かした結果が下記のような感じです。

http://silentworlds.info/beerpower.html

前回よりも多いビールパワーが観測されたようですね。

ツイートする

Permalink | コメント(0) | トラックバック(0) | 23:58

Ruboto-core 0.4.0リリース

ruboto, Ruby, Android

勉強をさぼっているうちにRuboto-core 0.4.0が9/19にリリースされてました。

0.3.0に遡って、リリースノートの内容をピックアップしてまとめてみました。サイズが大きくなったり、起動が遅くなる原因でもあったjrubyとruby-stdlibがプラットフォームapkとして分離されました。まだ試してないので、あとで試してみようと思います。

0.3.0(8/4リリース)

• Android API 3.2 Level 13のサポート
• appのサイズを減らすために、ruboto.ymlでRuby-stdlibを除くような設定をできるように
• スタック展開されたブロックまたはスレッド上の名前を設定できるように
• Android3.xデバイスのために最大ヒープサイズを増やした
• 生成されたAPIドキュメントへのリンクを追加

0.3.3(8/21リリース)

• IDEの誤動作を避けるため、gemの定義をGemfile.apkへ移動
• GEMに含まれるJARの中身をlib/bundle.jarへ展開
• APKを最新に保つために、update_scriptsを改善

0.4.0(9/19リリース)

• 直接APKからスクリプトを実行
• Ruboto Core Platformアプリ >くわしくはこちら
• Ruboto Coreアプリが起動したときに、自動的に Ruboto Core Platformアプリをインストール
• Ruboto CoreアプリをSDカードへ移動できるように
• "ruboto update app"が生成されたJavaエントリークラスを更新するように
• RubotoBroadcastReceiverがRubotoActivityとRubotoServiceと同じパターンを参照するように
• 起動時のダイアログをキャンセルできるように
• rubygems 1.8.0をサポート

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:40

今のテレビ業界について何か感じること、思うことがあれば教えてください。

思考, INTERVIEWS

THE INTERVIEWSより。

もともとそんなにテレビが好きな方ではないのですが、お仕事のこともあって気がついたら色々考えるようになってました。ちゃんとした結論はないですが、答えてみます。世界を変えたいという意識が根底にあるので、それを踏まえて読んでもらえるとよいと思います。

　テレビという言葉に対する視点としては、端末としてのテレビと、文化としてのテレビの二つに分けられると思います。（私の興味として）

　文化について最初に書きます。

　「テレビ文化は衰退して、これからはネットだ」というお話をよくネット上では見かけます。私もそうなったら面白いと思う一人です。しかしテレビはなんだかんだ言っても、いまだ大多数の人にとってメディアの主であるし、これからもそれは劇的には変わらないのではないかと色々経験して実感として感じています。既存のテレビとネットという軸はずっともやもやしているところです。

　ネットから情報を得ることと比較して、情報のインタフェースとしてのテレビはとても分かりやすくて、チャンネルを選べばそれなりのコンテンツがゆるりと視聴できる。そしてみんながそれを見ている。しかしネットはそうではない。これは優劣ではなくて、コンテンツに接する文化の違いなので、そうそう入れ替わるものではないと思います。または、この場合はテレビというより放送という言葉の方が適切だと思います。

　それを踏まえた上で、自分の感想として、テレビは、ネットうんぬんは多少あったとしても結局これからもこのまま現状の延長が続くのかなあと何となく想像しています。それはアクトビラの現状を見ていても感じることです。

　でも個人としてはそれはとても面白くない。

　自分にとってテレビは特定のコンテンツを視聴する再生専用機になっています。例えばそういう方向性ではいくらでも進化の余地はあると思います。インタフェースからコンテンツを得る手段など、それこそAppleとかがやりそうな方向性で。個人的にはアニメとNHKのドキュメントとかいくつかの番組さえ視聴できれば、放送は無くなってもさほど問題はない方面の人間なので、こういう進化をしてくれれば放送が見れなくなっても大して困らないです。

　しかし今こうして無料でこんなに沢山のコンテンツに接していられるのは、今の広告によるビジネスモデルが上手くいっていることが前提で、それが崩壊するような方向性での進化は中の人はそうそう認めないでしょうし、単に壊すだけなら結果として今のようなコンテンツが見られなくなるかもしれないです。絶対数からすると壊したいという願いを持つ人は少数派なんだと思います。

　少数派としては自身の視聴文化を布教していきたいと思うのですが、さっきも言った通り、誰もが望んでいることではない以上、それはとても困難なことです。奴らは分かってない、とかなんとか言っても意味のないことです。たぶんこれを変えるには現状の延長ではなく、別の方向性から切り込んで、新しい価値に賛同する消費者を拡大していくことが必要なんだと思います。

　そういう新しい方向性としてはニコニコ動画が放送形態も含めたメジャー指向で進化しているのは興味深いです。万人受けを目指した結果、その筋の人間にとってはつまらなくなるかもしれないですが、そんなメジャーへの挑戦をするネット企業は応援したいです。

　その他では、Netflixのようなコンテンツ販売主体のサービスは価格と内容の組み合わせ次第で一定以上普及するとは思いますが、能動的にコンテンツを摂取する文化側のサービスである限りは現状のテレビ／放送をそのまま置き換えることにはならないと思います。

　しかしNetflix系のサービスが流行ることによって、テレビ局の収益が悪化して、それがきっかけに不連続な変化が起きる可能性もありそうかなと思います。どこかに買収されそうになったときに以前と同じことが繰り返されるのかどうか、興味があります。

　

　そして端末としてのテレビについて。

　今のテレビは基本的にパネル中心に動いているので、投資も基本的にはパネル関連に行われるのが常です。コストが掛かる部分なので、大量に作る／調達する必要があります。

　でも個人的にはいいパネルから得られる画質には大してこだわらないし、大多数の人も積極的にこだわっているのはさほど多くない印象です。スペック並べて同じ値段だったら高画質な方を選ぶという感じで。

　乗ってるソフトウェアはチープなので、どのテレビを触ってみても、操作はもっさりしていて、リモコンは複雑で、お世辞にもUXをちゃんと設計してるとは言えない。

　私個人は最悪と思っていても、現状のニーズから考えると実はそれで必要十分な状態であるのかも、というのは実感として感じています。単に受動的な放送視聴するには数字ボタンを押して、チャンネルが映ればそれで十分なんだと思います。残念。

　個人的にtorneのUIは面白くて好きです。自分がこうあればいいなと思ったことの多くが実装されてます。（メニュー画面が先頭にある、動作の軽快さ、スキン機能がある、トルミル機能とか）

　しかし、torneが素晴らしいと思っても、それは世界を変えるほどには至っていないわけです。それもやはりそれを求める人が限られているからだと思います。

　もし端末をもって世界や文化を変えるのならば、その端末は新しいUXとそのUXでしか経験できない新しい何かをセットで提供してあげないといけないのだと思います。（それをやりとげたのがiPhoneだと思っているので、自分の中では最高にリスペクトしてます）

　テレビで変革を実現するために、一つの可能性として、GoogleTVがあったわけですが、蓋を空けてみるとテレビとネットが不協和音を起こしているような印象でした。テレビを変えて行くにはAndroidのようにフレームワークだけ提供すればよいのではなく、放送にも踏み込んで行く必要があるのだと思います。しかしGoogleはそこには興味がなさそうなので、微妙です。

　結局端末だけではだめで、放送とセット変化を起こすことができれば、それが新しい「テレビ」になると予想してます。

　それを実現させるのが、現状の放送業界かというと、そうは思えないというのが、自分の印象です。じゃあ他に誰がいるか、というそれも思いつきません。

　と言いつつも、ここ10年で携帯業界に起きたようなことが放送業界で起きそうな漠然とした予感もあります。

　それが日本発であって欲しいなとは思っていますが、日本からではしがらみを乗り越えられそうもないと感じているので、そこが大変もやってます。（業界規格とかについても色々思う所はありますが、話すと長いのと、ここで書いちゃうのもあれなのでこれくらいにしたいと思います）

結論：快適にアニメを視聴したい

ツイートする

Permalink | コメント(0) | トラックバック(0) | 00:58

DevQuiz：スライドパズルのソースコード(C言語)

技術

GDD2011のDevQuizのチャレンジクイズである、スライドパズルのソースコードを晒します。

たいへんぐちゃぐちゃなので、恥ずかしい…。

これで２日くらい５プロセス回すと、4500/5000くらい解くことができます。（自分の結果は4427/5000でした。合計してDevQuizの成績は144.3点でした）

おそらく最短手が得られているはずです。

全問解答するためには、これに色々ヒューリスティックな改造をする必要があります。＞と思ったのですが、色々工夫するとヒューリスティック抜きでもいいところまでいけるようです。

アルゴリズムの方針としては、反復深化深さ優先を基本としてます。加えて終了局面を起点として幅優先で正解局面を展開してハッシュに溜めて、深さ優先の終了チェックに使用します。終了局面との距離には普通のマンハッタン距離を使用してます。それだけです。

他の方のツイートをみると、壁を考慮したマンハッタン距離を使うのが普通のようで、確かにすっかり考えから抜けていて大変悔しかったり。

改善版では、手数は伸びるけれど深いところまで探れることを期待して山登り法を試していて、確かに解けない問題も解けては居たんですが、爆発的に手数が増えてしまって困っているところでタイムアップでした。あと無計画に実装したソースコードが手に負えなくなってきて、詰まったというのもあり…orz

ソースはgithubに上げておきます。

https://github.com/kishima/SlidePuzzle

ツイートする

Permalink | コメント(0) | トラックバック(2) | 12:40

TokyuRubyKaigi03におけるビール力の推定

Ruby, 思いつき

先日のTokyuRubyKaigi03では、大変ありがたいことに、サントリーさんがスポンサーになって下さって、ビールが振る舞われました。

その力がどれほどであったか、Twitterでの発言から推測してみました。（主な目的はRubyを書く練習）

推測方法

• Togetterから当日の#tqrk03ハッシュタグ付きツイートを回収
• その中から、「モルツ」「ビール」「サントリー」を含むツイートを選別
• ビール関連ツイート主のfollower一覧を取得
• 一覧から重複を排除したfollowerの合計数がビールの力が届いた人数

まあ色々突っ込みどころはありますが、下記のような感じで調査してみた。

 # -*- coding: utf-8 -*-

require "rubygems"
require "nokogiri"
require "rubytter"

$stdout.sync = true 

doc = Nokogiri::HTML(open("togetterのHTML"))
tweets=[]

doc.xpath("/html/body/div[@id='document']/div[@class='contents']/div[@class='left']/div[@class='tweet_box']/ul/li[@class='list_item']/div[@class='list_box balloon_box type_tweet']/div[@class='balloon_module']/div[@class='balloon_body rad5']").each do |d|
  tweet = d.xpath("div[@class='tweet']").inner_text
  id = d.xpath("div[@class='status']/div[@class='status_right']/a[@class='status_name']").inner_text
  time = d.xpath("div[@class='status']/div[@class='status_right']/a[@href]").inner_text
  h = { :name=>id , :comment=>tweet, :time=>time}
  tweets.push h
end

puts "tweets.legth="+tweets.length.to_s

supporters = tweets.select{ |a|
 a[:comment] =~ /モルツ/ or a[:comment] =~ /ビール/ or a[:comment] =~ /サントリー/
}.map{|a|a[:name]}.uniq

p supporters

consumer = OAuth::Consumer.new( 'xxx','xxx',:site => 'http://api.twitter.com' )
token = OAuth::AccessToken.new(consumer,'xxx', 'xxx' )
twitter = OAuthRubytter.new(token)

def twitter.followers(screen_name)    
  begin
    self.followers_ids(screen_name)
  rescue
    []
  end
end

arr = []
supporters.each{|name|
  followers = twitter.followers(name.strip) 
  arr.push *followers
}

puts "all users "+arr.uniq.length.to_s

結果は、#tqrk03のツイート数1182。そのうちビール関連ツイートをしたアカウントは43。

ビールの力が及んだアカウント数、18979！

でした。

次回はどうなるか分かりませんが、また楽しくお酒とRubyを楽しみたいものです。

ツイートする

Permalink | コメント(0) | トラックバック(1) | 21:45