長野沖電気の電波時計モジュール
http://www.naganooki.co.jp/news/denpa.html
サンプルは5k円だそうだけど、量産時はどのくらいに下がるのかな。あとは機器筐体に組み込んだ場合に、AMってちゃんと受信できるのかどうか不安。
■
最近の車内BGM。
Chica Boom "愛しTe Quiero" http://www.uno-music.com/chicaboom/
はまぞうでは出てこなかった。
ラテンなリズムで元気を出そうというテーマ。
どうも皿型は指になじまない
皿のふちの丸いのが気になってダメだ。東芝風のいがぐり頭に変更。
鉄人
http://www.vstone.co.jp/top/products/robot/T28/index.html
コストがもう1桁下がらないとなぁ。せめて10万円台になると違うのかも。
iPod shuffle の感想
どうにもちゃちい感じ。1万円という感じがしない。
イヤホンはダメ。バスドラムの音がボヨンとメリハリなく妙に強調されて聞こえる。ためしに Walkman 用の無電源外付けスピーカーを接続して聞いてみたけど、そういうことはないようなのでイヤホン側の特性によるものと思われ。それ以外は低音はぜんぜんダメ。
名前に1Gとあるけど、実際はシステムなどが入っているので、だいぶ容量が小さい。ディスクとして利用するサイズについては、iTunes側で曲目数でしか管理できないようだ。スライダーには240曲と表示されている。
操作については問題なし。スイッチのガタつきやスライドしにくい人、曲間にプツッという音が入るなどという報告があるが、どれもない。ただ、バッテリ残量確認のボタンパーツがやや小さいのかおさまりが悪い感じ。日本品質ではありえないかも。
ポッドキャスティングで声出していこう!
SeesaaでiPod miniプレゼントをやっているので、トラックバックしてみたりする。
いまのところ、Podcasting は可能性はあるけど、フレームワークにマッチしたコンテンツが生まれていない感じがしている。SeesaaでやっているようなBlogの読み上げは個性がなくてイマイチかな。やっぱりパーソナリティー勝負(特に聞いていてここちよい声が重要)になると思うのですが、聞き続けるのに耐えるようなコンテンツをコンスタントに出すというのは難しいのではないだろうか。今後は、アイドルなどがファンサービスでやるような既存タレントを使う事例が増えるのかもしれないし、逆にPodcastingStarが生まれる可能性もある。
コンテンツを作っても発信する環境が特殊だった問題は、既存のBlogが対応してきたことでだいぶ改善されるだろう。Blogとしてはおまけの機能なところから、専用のところまであるのだけれど、今後はメインではないもののスタンダードな機能の1つとなるだろう。専用のところは、聴取率を調査可能な機能や感想をもらえるようにする機能(非公開のも含めて)など、Podcastingを補助するための機能をどんどん充実させていってほしい。広告などスポンサーとの連携を提供する機能も、ハードやソフト側、また音源フォーマットや、音源制作システムに必要になるだろう。わずかでも儲けが出るのは、コンテンツ作成のいいモチベーションになる。
音源を作る環境もコンテンツを増やしていくためには必要になる。MP3で保存できるボイスレコーダーが使われたりしているようなのだけど、こういうデバイスでは、ライブ感はあるものの演出が難しい。パソコンの前に座ってやっていては、PCそのもののノイズなどでいい音は作れない。専用のミニスタジオ兼、発信環境と自動リンクするような専用ハードウエアがあるといいのではないだろうか。
ヒットすれば配送の問題が出るので、サービス業者のネットワーク/サーバー負荷がたいへんになるだろう。torrentocracy のようなP2Pフレームワークを使った分散データ配布(Broadcatching)やakamaiのようなエッジレベルでのコンテンツキャッシュは必須になってゆくのだろう。そういうものが苦もなく利用できるようなaggregatorアプリケーションの登場が必要だ。
次には、プレーヤー側で統一して利用できるようなUIフレームワークが必要になってくる。iPodにRSSを取得してデータを流し込むようなへたれプログラムをPythonで書いてみたりしたが、Notes機能と連携したメニューつきの再生環境を作ってみると、Notesの機能が限定的すぎて十分に使いやすいものがデザインできないのが気になった。つまりiPodははじまりに過ぎない。よりPodcastingを利用する事にフィットするためのハードウエア側の環境整備も課題になるのだろう。MusicPlayerはいまやチップ1つとメモリと若干の回路だけで出来るものなので、きっといろいろな製品が出ては消えていきながら、スタンダードが決まっていくのだと思う。現在のiPod程度の液晶画面の表現力はPodcastingといえども必要だと思う。それにコンテンツを乗せるためのルール作りは必要だ。できれば、RSSを拡張して、そのような音源と同期するコンテンツも配送してくれるようになると思う。
最後は、携帯電話の機能として、自動連携できるような仕組みが整備されるというあたりに落ち着くのだと思うが、そのためにはまだ認知と利用が盛り上がる必要があって、見通しは立たない。
# ただ、今の会社だとこういう仕事をしたいと思っても難しいところがあるのね...
3/15 東京出張決定
でも、アポが午後遅くだよ。日帰りは出来るのかな...
久しぶりの出張なのに、また、イベントが何もない時期に当たってしまったなぁ...
今回は、kurosaka さめに借りを返せるかな? でも、アポは東急多摩川線だな... 無理かも...
Pythonでのタグサニタイジング
http://www.atmarkit.co.jp/fsecurity/rensai/webhole14/webhole01.html
サンプルにないじゃないか...(まぁ、あたりまえか)。
こんなに簡単でいいのでしょうか...
そういえRubyも書いてないな(これは手抜きかも)。
fe3d
http://projects.icapsid.net/fe3d/
3Dでネットワーク状況を表示する。
視覚的には面白いけど、実用的かというと、そうでもない感じ。
file exchange daemon
http://www.zahlfee.de/fex/fex.html
intermezzo風のレプリケーションシステム。kernelモジュールを必要とせず、どのようなファイルシステムでも動作する。SSHトンネリングを自動で行い、細い帯域のためにデータ圧縮が可能
CheckDNS
http://www.enderunix.org/checkdns
DNSのチェックとリポートツール。
GKsu
http://www.nongnu.org/gksu
GTK+用のsu時GUIパスワード入力ラッパ。
ubuntuで出てくるのはこれかな。
dd_rescue
http://www.garloff.de/kurt/linux/ddrescue/
ファイルやブロックデバイスを別の媒体にコピーする。readエラーになっても処理をやめず、ブロックの切り詰めも行わない。終了後にbad_blockのリポートを出力。途中で処理をやめても、任意の場所から続行が可能。debもあり。
Qucs
http://qucs.sourceforge.net/
GUIの回路シュミレータ。Qtが必要。
Ruby/Amazon
http://www.caliban.org/ruby/
AmazonのAPIをRubyから利用するライブラリ。
L4ip
http://www.lundman.net/unix/l4ip.php
ラウンドロビン型のロードバランサデーモン。