ohnetaの、以上、よろしくお願いいたします。

なんとまー、一年ぶり？

2011-08-22T17:05:00.002+09:00

忘れた頃に更新されるブログ？

えっと、（株）ケロン軍の運転資金稼ぎに某社で働いていましたが、7月末をもって契約が終了しました。
また、今月からは開発の請負業務を再開です。

で、この丸1年間の間にiPhone(iOS搭載機)アプリ開発のスキルもいろいろ上がりましたよ。
External AccessoryやExternal Displayの経験もしましたので、iPhoneへの外部機器接続プログラミングもイケます！

個人的にスマートフォンと外部機器の接続ってとても興味のある分野なので、この分野のお仕事なら、ばんばん受けたいとおもっています。

OTOduino/SoftModemのような簡易接続からMFiばりばりのI/Fまでなんでもござれ！ｗ

で、リアルタイムキャプチャ

2010-08-02T23:41:00.000+09:00

というわけで、リアルタイムでキャプチャして、そのキャプチャデータのbitmapへアクセスする方法を調べたさ。

これ、Appleがサンプルを出しているんだけど、うちの環境だとちゃんと動かない。
なにがダメかってと、captureOutputメソッド(delegate)で取得したUIImageをそのdelegateの外(メインスレッド)から使おうとすると、データの中身がなくなっているのです。
原因はよくわかんないんだけど、これはdelegateを呼び出すタイミングと外側から使おうとしてオブジェクトへアクセスするタイミングでうまく噛み合わなくてダメなんじゃないかと憶測。delegate内で処理を完結させればいいのかもしれない。

AbrViewerで使うならdelegate内で処理を終わらせればいいんだけど、別アプリで使おうとしているアイディアではキャプチャしたデータを外側で使いたいから、これじゃダメ。
なので、いろいろ試行錯誤で実験してみた。

で、最終的にどうしたかというと、delegateの中で sampleBufferからCGBitmapContextCreateでbitmapを作って、そこから CGImageを作る。
そこから定番のCGImageGetDataProvider/CGDataProviderCopyDataでCFDataRefを作って、そのコピーをメンバ変数に設定して全体で使えるようにしておく。

使う側では、そのコピーからCGImageを作って、UIImageにしてやる。
っと、ここまでやればキャプチャされたデータをメインスレッド側で好き勝手に使えるようになるみたいだ。

結構、めんどくさいね。。。。(^^;

もう先週の話だが、、、

2010-07-30T23:02:00.001+09:00

UIGetScreenImageがまたもや非公開API扱いになった。

一応、iOS4からリアルタイムでカメラキャプチャデータを取得するAPIができたので、それを使ってくれとAppleからメールが来てた。いまいま公開されてるアプリを非公開にするわけではないらしい。
んま、iOS4からしか対応できないから、しかたない。

つかさー、こんなAPI、最初から用意しとけってーの！ > Apple

で、どうするかだ、、、
ま、そんなに難しくはないようなので組み込んでみることにしますよ。まったく、もうっ。

はてさて、

2010-07-17T01:06:00.000+09:00

夏もだいぶ本格的になってきつつある梅雨の後半、猛ダッシュ。
(株)けろんぐん　も東京に越してきてから早２ヶ月が過ぎました。

その後、けろんぐんはなにをやっているかって？
いや、はい、もちろんiPhoneアプリの開発はやってますよ、、、やってるはず、、、やってたっけな？、、あれれ？？？

ahaha!

ええっとですね、、、、資金不足です。運転資金ありません！！
もともと貧乏会社なので運転資金なんてものはないのですが、さらに貧乏になりました。

なので、けろんぐんの代表、わたくしことohnetaは働きにでています！ｗ

いやぁ、もちろん、この仕事もけろんぐんとして受注した仕事なので、立派にお仕事ではあるのですが、iPhoneアプリを作っているわけではないのです、、、
まぁなんというか、、、SIerな感じの仕事をして、ちょっと食いつないでいます(^^;

で、普通にお仕事なので、けっこうフルタイムで時間を拘束されるわけで、終業時にはけっこうクタクタ。iPhoneアプリを作るパワーが、もう、ほんの少ししか残っていません。

そのほんの少しのパワーを寄せ集めて、バージョンアップやら新アプリやらを、ちまちまとやってますので、この年末年始でいっきにアプリを作ったようなスピードでは、いまはできてません。トホホ。

などと、いいわけを書いてみる昨今です。

いくつかおもしろいアプリのアイディアはあるので、やってみたいのだけどなー。
だれかプログラムつくってくれる人おらんかな？けろんぐんで雇えるかな？という問題もあるのだが。。。ｗ

移転したよー！

2010-05-10T00:38:00.000+09:00

まだインターネットへは仮アクセスしかできないのだけど、(株)けろんぐんは実質的に東京に引越しましたよー。
いや、登記上はまだ本社は和歌山にあるのだけど、実際の会社機能は東京に移りました。
今月末に登記上も東京にもってくるつもりです。

いやぁ、ながかった。。。。
けろんぐん設立前年に和歌山に移住して、勢いで会社をつくって、、、、ん、、実に丸３年間、縁もゆかりもないど田舎生活でした。

で、これから、東京でなにしていけばいいですかねぇ、、、やっぱまだiPhoneアプリ開発なのかなー、、、、ちょいとばかし悩んでみます。

iPhoneで任意のオンラインストレージを使ってファイルのやり取りをしたいのさ！

2010-04-06T10:01:00.010+09:00

iPhoneでもiPadでもそうなんだけど、基本、MacなりPCを母艦としてiTunes経由でデータのやりとりがされているけど、それってカッタるくない？
世の中、クラウドだとか騒いでいるんだから、ファイルのたぐいはオンラインストレージでいいんでないの？と思うのだけど、Appleはそう考えていないようなのよねー。

いや、Appleが MobileMeでストレージスペースを提供しているのは知ってるけど、あれって有料だし。DropboxやSugerSyncなんかの無料なサービスがあるんだから、そっちを使いたいのが消費者の気持ちってもんだよね。べつにそんな貴重なデータを残しておきたい訳じゃない場合とかならなおさら。
つか、すでに使っているサービスがあるなら、そっちを使いたいじゃない？
ま、オンラインスストレージベンダーさんたちもiPhone用アプリを提供してたりするんだけど、あれも自分ち専用だったりするから、どうしたものかと。

いろんなアプリがデータのやり取りしたいしたがってるとおもうのよねー。私のAbrViewerだって履歴のエクスポートをファイルでやりたかったもの。もし、ファイルが取り込めるならウィッシュリストの取り込みとかやりたいもの。。。

そんなこんなで、アプリを提供する側からいえば、ユーザがどこのオンラインストレージを使ってもかまわないんだけど、いちいちそれらのサービスに対応したコードを用意するのは面倒なので、共通ライブラリがあれば便利じゃね？と思うわけですよ。
重要なのはアプリが出し入れするファイルであって、そのファイルを置いておくサービスなんかどこでもかまわないわけ。でも、広くサポートはしたい。てか、ストレージ業者じゃないんだからヘタに囲い込みたくないわけです。Evernoteじゃあるまいしｗ

ライブラリ１つで、ユーザがどこでも好きなサービスを使ってもらってかまわない。自由な選択にしたい。
今でも、多くのオンラインストレージサービスってAPI持ってたりするから、それらアクセスするための共通I/FをもったライブラリをiPhoneなりAndroidなりなんなりに提供できれば、デベロッパーもハッピー、ユーザもハッピー、ストレージベンダーもハッピー(かな？ｗ)になって、いいんじゃね？
と、思いついた、とある４月の午前中。

こういうアイディアに資金だしてくれるとこないかなぁー？　ひと月もあれば立派なもの作れる気がする。速攻作りたいよなー。
それに、ライブラリ販売すれば、それなりに売れるとおもうんだけどねぇ。

AbrViewer 1.2.1 および AbrViewerLite が公開されました。

2010-04-03T17:47:00.000+09:00

やっと、やっとのこと AbrViewer1.2.1とAbrViewerLiteの申請が通りました。
長かった、、、２回rejectを喰らって、途中でバグを発見してdevelopper rejectを３回、、計5回のバイナリ提出し直し。
ふぅ。

まぁ、これでとりあえず無料版(AbrViewerLite)も提供できたのでヨシとしましょう。
いろいろ機能が増えてるので便利になっているはず。と思います。

どうぞ、よろしくｗ

あはは、Liteがrejectくらった！

2010-03-27T05:12:00.000+09:00

なんか無料アプリのほうが審査がはやいのかな？早々、reviewステータスにかわって、早々連絡がきた。

rejectされた。。。。orz

いや、単にUIボタンの使い方が悪かっただけで、すぐに直せるとはおもうので、落ち込むほどでもないんだけど、、、やっぱ、rejectくらうとちょっとショックだな。

てか、今回のバージョンを提出してから、さらに新しい機能を思いついたので、ついでだからそれも入れて、再提出しよう。。。

ふみぃ。。。。

これで、次

2010-03-26T14:12:00.001+09:00

これで、とりあえず次のやつのやりかけのを再開することができる。
んま、申請通ったら通ったで、また、いろいろやること出てくるので、それはそれでまた時間がとられるのは目に見えているのだが、、、、ｗ

AbrViewer 1.2.1申請だしましたん。今回からLiteもあるよ。

2010-03-26T14:01:00.002+09:00

何日か前に書いたとおり、Appleの申請が通れば、AbrViewerがバージョンアップできる予定。
バージョンアップ情報をブログに書いた後からも、某ユーザさんからいただいた要望などを取り入れて、若干のUI変更と機能追加をしましたよ。

ISBN入力画面の修正
ISBN入力フィールドのフォントを大きくした。
入力された文字数をカウント表示をするようにした。
アプリ内ブラウザ画面からのISBNリンク
amazonサイトが表示されているとき、そのページでISBNが取得できたらそれをボタンにして表示。タップするとブックレビューを表示
スクロールコントローラの追加
それぞれのレビューの下位部分に画面を強制的にスクロールするボタン（コントローラ）を付けた。

1はバーコードスキャナが使えない環境での入力を補助しようとするものの一環。

文字が小さいとの意見をもらったのでテキストフィールドを横一杯まで広げた。
電卓アプリくらいのUIがいい、と言われたのだけど、さすがにあれを作るのは面倒だったのでテキストフィールドで実現。

文字数カウント表示は長いISBNの入力の目安になれば、、、という感じ。
数字をハイフンで区切って！って要望もあったのだけど、ISBNのハイフン間の文字数ってISBN仕様上は不定なので、とりあえずなんか、、、とおもって作ってみた。

2はamazonをブラウズ表示して他の関連書籍に移ったとき、それもAbrViewerのレビューで表示してあげようという機能。自分で作っといてなんだけど、これは便利だ。

amazonの商品紹介ブラウズ中だと画面の下側にISBNボタンが表示されるので、これをタップすれば、その本のレビューが読める。
でなにが便利って、レビューが表示されれば履歴に入るようになっているので、これと履歴のエクスポートを併用することで、簡単なウィッシュリストを作ることができる。
もうちょっとiPhoneの画面が大きければ更に使いやすいんだろうけど、それは無い物ねだりだし。。。

3はレビューを読みながらフリックする面倒くささの低減をはかったもの。だらだらとレビューをいくつも読んでいると、先頭に戻るためのフリックが結構面倒になる。ので、一気に先頭にもどったりするのに便利。

下ボタンで次のレビューまで強制スクロール
上ボタンで現在のレビューの先頭まで強制スクロール
二重上矢印でこの画面の先頭までスクロール
このボタンは大きめなので邪魔だと思う場合は設定でON/OFFできるようになっている。

などと、機能が結構追加されたのので、今回のリリースはバージョンも 1.2.1 にすることにした。
最後の .1 はちと内部的な問題があったので付けました。あまり深い意味はない。

それで、これと同時に若干の機能制限をつけた無料版 AbrViewLite　も申請。

こちらの制限は、

履歴が５つまで
履歴のエクスポートができない。
全レビューの取得ができない。最大20まで。
レビュー表示で5回に１回くらい「これはLite版なのでFull版買ってよ、おねがい♪」の旨のメッセージが強制表示される。

など。
「買ってよ、おねがい♪」メッセージがうざいくらいで、本質的な制限ではないので、バーコード入力を試してみたい方はこちらでもいいかもね。。。。
(本音ではFull版を買ってもらいたいのだけどw)

ということで、さっき申請したので、うまくいけば来週中には公開されるかも。あくまでもうまくいけば、、です。どこでrejectされるかわからんから、、、Appleの場合。汗

うまくLite版が公開されたら、ちょっとキャンペーンやってみようかなと検討していますので、こうご期待！ｗ

なにがどう、、、とはいえないんだけど、

2010-03-23T23:28:00.000+09:00

昨晩から今朝にかけてネット上で起きた出来事により、流れが変わった気がする。
これが、くすぶっていたものが流れ出て湧き溢れる潮流であってほしい。

新アプリの前にAbrViewerバージョンアップと...

2010-03-19T13:24:00.001+09:00

新アプリをリリースするまえに AbrViewerの拡販のために無料版をつくることにしました。
とはいえ、今時、無料版といっても機能を削るわけにもいかないので、いま販売しているものと同じくらいの機能は備えるつもり。制限は履歴の数くらいかなぁー。

そうなってくると、有料版の差別化をしていかないといけないので、有料版は同時にバージョンアップ。という話になってくるわけで、その内容です。

ISBN入力フィールドにクリアボタン
入力のクリアに本体シャッフルかキーボードバックスペースしかなかったので、一気に全部消すボタンを新設。
[978]の短縮入力ボタン
ISBN-13の場合、先頭の「978」は固定なのでそれを簡単に入力できるボタンの新設
ISBN-10の X に対応したキーボード
実はISBN-10のチェックデジットが「X」という本があるがその入力方法がなかったのでキーボードをカスタマイズして「X」が入力可能なように機能追加。
ブックレビュー後にamazonサイトの切り替え
ブックレビューを表示後、同じ本を別amazonで再表示できるよう機能追加
ISBN検索失敗後にISBNを保持したままamazonサイトの切り替え
4と同様の機能なのだが、こちらはISBNが見つからなかった画面からのamazonサイト切り替え
履歴情報のメールによるエクスポート
プレーンテキストとHTMLテキスト(amazonサイトへのリンク付き)が設定で選べるエクスポートメール。
amazonサイト表示のアプリ内webブラウズ
いままでmobile safariで表示していたamazonサイトをアプリ内のwebブラウズ機能で実現

と、これくらい。

4、5のISBN保持したままamazonサイトの切り替えってamazon.co.jpしか使っていない場合、あんまり恩恵がわからないとおもうのだけど、英語の本などの場合、扱っているamazonサイトが US、UK、CAと3カ国あったりするのでそれぞれでレビューの内容も違うからそれを読み比べることも出来るようになる、という英語圏の人向けの機能。日本ででも洋書のレビューを読みたいときには便利かもね。いちいち設定画面からamazonサイトを切り替えないでも済むし。

6はせっかくの履歴情報をPCなりなんなりに取り込みたい、という人向け。将来の書籍管理機能のへの布石(えっ？)　www

7は自分で使っていて不満だったwebブラウジングの内包。いったん別アプリを起動しちゃうと戻ってくるの面倒だったから。いや、ver.1.0でも付けたかったかったのだけど、手を抜いてました。すんません(汗

こんくらいしか機能的には変わってないので ver.1.1ってことにします。

えっ！？バーコードの認識率上げろって？

わーわーわーーーーぁ　キコエナイ。キ、コ、エ、ナ、イ、ヨーォＯおoヲ---。。。。。。

写真は開発中のものです。リリース時にはもちっと綺麗になります。なるでしょう。なると思います。なるのか？なるのかなぁ？？？？

ISBN入力フィールドにクリアボタンの新設
[978]の短縮入力ボタンの新設

ISBN-10の X に対応したキーボード

ブックレビューを表示後、同じ本を別amazonで再表示できるよう機能追加

ISBN検索失敗後にISBNを保持したままamazonサイトの切り替え履歴情報のメールによるエクスポート

プレーンテキストとHTMLテキスト(amazonサイトへのリンク付き)が設定で選べるエクスポートメール。

などと。

こんなん見ちゃったらさー、自分のレベルあげなきゃしゃーないやん。

2010-03-03T11:30:00.006+09:00

AbrViewerは世間のiPhoneアプリと同様、なかなか売れない。
販売努力をまったくしてないので、こうなるとは思っていたが、これほど売れないものなのかと。
マジで対策せねば死活問題なのだが、この話題はそれはそれでおいといて、、、、ｗ

今、次のプロダクトをつくっているのだけど、いろいろ参考にと他の方々のアプリを調べていた。
個人的には奇をてらったUIは好きじゃないので、iPhoneのガイドラインに沿って作るべき。と考えているのだけど、これを見たらヤラレました。自分の考えが粉々に砕け散りまくった。

Awesome Note
http://bridworks.com/

機能はもちろんだが、そのUIとデザイン。まったく知識なしに使い始めたのだけど、
「こうするためには、こうすればいいのかな？」
って操作すると、実際にそうなる。
なに、これ！？　なに？この爽快感！！

そして、これを味わうと　「じゃ、この場合は？」　と自ら課題を作って、そのアプリの操作性自身を楽しみ出すことに気がついた。そして、だんだんそのアプリ自身が好きになっていく自分。

もう、こうなると、より難しい操作ができなくても、それはそれでＯＫ。だって好きになっちゃったんだもん、多少の問題は目をつぶっちゃうよね。てか、それも含めてＯＫだよね。だって好きになっちゃったんだもん。愛は盲目！ｗ

で、アプリユーザならここまででいいのだけど、一応、アプリを作る側の人間なので、これを冷静に考えてみると、

『解決すべき問題に直面したときに、自分が思いつく方法(操作)で問題が解決できると、そのプロダクトへの親近感が増す』

ようである。
iPhoneアプリのように操作性が限定される場合はさらにそれが端的に発揮されるのであろう。
携帯サイトをつくっていたときも、どんだけ直接的に必要な画面に移行できるか。ってのは課題の１つであったわけだし。

しかし、さすが定番アプリ。iPhoneアプリは消費されるものなので、その中で選ばれて勝ち続ける。ってのはすごく大変だが、これはそのデザインと操作性で圧倒的であった。
なるほど、ここまで作らねば勝てないのか。

てかさぁーーー、こんなの見せられちゃうと、ここがスタートラインになってしまうよ。
これくらいできて当たり前。この先をどうするかが勝負になってくる。

やはり後発組には厳しい市場だなー。
ま、大きな壁ほど乗り越えるのも楽しいのだけどね。まだ、乗り越えられる程度の壁だしw

お誕生日だった。

2010-02-18T10:01:00.009+09:00

いやぁ、また年取ってしまいました。とほほ。

2月17日は私のお誕生日でした。
ここ数年、嫁さんの流行で私のお誕生日におかしなケーキを注文する。というのがあるらしく、
昨年はこんな感じ

やら、こんな感じ

でした。

で、今年。

そう、きましたか！　www

iPhoneですね、これ。

しかも、AbrViewerがちゃっかりのってますｗ

つか、アイコンがすべて作ってあるよ。。嫁さん、こんな無茶発注かけて、ケーキ屋さん、ごめんなさいｗ

なので、せっかくなのでケーキ屋さんの力作アイコンを１つ１つ見ていきましょう。

左上から。

コンパス

乗換案内

Google Earth

Skype

UstreamのBroadcaster

Flickr

ニコニコ動画

セカイカメラ

Classical

VoiceBand

Dropbox

RedLaser

和英和

eBay

aMart

で、AbrViewer

下段は定番のこいつら。

メール、電話、Safari、iPod

いやぁ、やはりパティシエ、Good Job !

こんな仕事してもらって通常のお誕生日ケーキと同じ値段だった(らしい)ので申し訳ないので、お店のリンクだけでも貼らせてもらいます。

ボナペティヤナギヤ

というわけで、ここを私がいただきました。ｗ

毎年、毎年、ありがとう、嫁さん。愛してるよw。

p.s.

ムービーにしてみましたｗ

http://www.nicovideo.jp/watch/sm9762021

でた！ AppStore/utilitiesの新着トップだ！

2010-02-15T16:09:00.002+09:00

iTunesのAppStoreに新着として表示されました。

これ、どうもリリース日のものをアルファベット順に並べるようで、偶然にも「AbrViewer」なんてけっこう索引の前めの名前だったのでトップページの最上段に表示されました。
あはは、これは良い誤算ｗ

これが日本のiTunesの画面。

こっちがアメリカのもの。

まんなかコンテンツの左上に注目！ほらほら！

左上！左上！

うほほ。らっきぃー♪
つか、他のアプリはエロっちぃのが多いぞ？ここユーティリティカテゴリ―だったよな？(^^;

で、つぎ。

2010-02-15T01:08:00.001+09:00

音声ものにするつもりで、録音とか再生の実験コードを書いてます。
MP3を再生させるコードを書いて、テストで何曲かいれてみて、いろいろ操作してたら、そっちが楽しくなってきてしまって、アプリ用のコードが書けてません。(^^;

もちっとマジメにやりますよ、、、はいっ！

無事販売開始されたようです。

2010-02-15T00:38:00.001+09:00

AbrViewerはアメリカ太平洋標準時2月14日0時から iTunes AppStoreで販売がはじまりました。
英語と日本語に対応しているので、usと日本のiTunes Storeから検索効いて買えるようです。

iTunesのURIを設置しておきます。

何人かの知人が購入してくれたようで、すでに鋭い意見をいただいています。
さっそくバージョンアップになるかも。。。(^^;

あ、あと、サポートページは結局 mobile safari対応に間に合っていません。ただのwebページしかありませんので見づらいです。
これも実施日未定ですが対応予定になっています。

AbrViewerのサポートページとかいろいろ

2010-02-13T08:33:00.002+09:00

AppStoreでアプリを公開するにはサポートのwebページやらなにやらを用意することがAppleから必須にされているので、作った。

英語は全く自信なし。とりあえずあるだけ。片言でもあるだけでなんとかなるかな、、、という甘い考え。
実際、私の場合、日本語だってあやしいのに。

で、これを作るついでに会社のwebサイトも、ちゃんと(?)作ることにした。
以前は私個人のwebサイトに会社情報だけ載せてたんだけど、ドメイン自身はだいぶ前から取って持っていたので、それを設定した。

なんと！今時、日本では珍しい .com 企業ですｗｗｗ

まぁwebのほうはボチボチと更新していきます。

in Review & Ready for Sale

2010-02-11T11:55:00.003+09:00

えと、バーコードでISBN読んでamazonのブックレビューを表示するiPhoneのアプリは「AbrViewer」として2月6日にiTune Storeに登録申請しました。
で、2月9日になってin Reviewになり、2月11日早朝、めでたく Ready for Sale になりました。

なにしろハジメテのことだったので、ちょっと（いや、だいぶｗ）ドキドキしてましたが、けっこうすんなり通りました。
でも、Appleのreviewってどうなんでしょうね？
今回申請してみて思ったんだけど、基本的に申請するものってアプリそのものとそれのサポートサイトのURLくらいで、マニュアル的なものはまったく提出しない。それに今回、サポートサイトもちゃんと出来てるわけではない状態だったので参考にしたとも思わわれない。つまり、いきなりアプリ渡されて、これをAppStoreにのせるかどうか判断してるわけだよね？

これって手の込んだアプリとかだと難くしねーか？
今回、私が申請したヤツは単機能だから比較的わかりやすいし簡単だろうけど、手の込んだヤツだと目的を達成させるための操作が煩雑だったりすると、reviewerの中の人も困惑だろうに。。。
ああ、だからreviewの期間ってアプリ次第でバラバラなのか。

つまりだ、はやくreviewを通りたかったらわかりやすい単純な操作にしとけ。ってことだな。
じつにiPhoneアプリのガイドラインに沿ってるな、と妙に納得ｗ

あ、AbrViewerは登録時に公開日を2月14日にしてしまったので、それまで公開されませんけどねｗ

カイゼンカイゼンまたはオオキクカイゼン

2010-02-08T08:48:00.005+09:00

バーコードは読めるようになったので、アプリ全体の機能をすべてつけて、いざ、大量の本で実地試験と相成りました。

とりあえず、作業デスクのそばにある何冊香の本で試してみたところ、うまく読み取れないコードがいくつかでてきた。
バーコード自身を目視してみると白黒が１モジュールづつ連続しているところだったり、４モジュール連続で白とかの部分がうまく読み取れない場合があった。
(モジュールとはバーコードの最小単位。あのバーの一番細いのが1モジュールにあたる)

自分のソースコードなのでいくらでも手を入れられるし、あーでもない、こーでもない。といった実験もできる。ちょっと反応は鈍くなったけど、手近の本のバーコードが読めるようになった。
まぁ反応の鈍さは複数回のループ処理など、まだコードの最適化をやっていない部分が大きいので、コード確定次第、最適化を施せばいいやと。

ので、自宅にある1,800冊オーバーの蔵書を誇るマンガ棚にいって、かたっぱしからバーコードを読んでみた。(なぜそんなにあるかはここらへん参考にしてね)

、、、、、勝率８割程度、、、、orz

これじゃだめだ。20%も読めない読み間違えが発生する。
せめて95%、希望は99%。願わくば100%認識率にしたい。

ちなみにライセンス買おうかどうか迷ったRedLaserのバーコードは認識率100%。しかもすごい速さで認識される。

負けてる、、、いや、負けてもいいのだけど、負けすぎている。
相手はiPhoneもバーコードも先達で社名からもわかるようにバーコードのプロだろう。
こちとら２日間やそこらでつくったバーコードスキャナだもの、負けているのは仕方がない。しかし、負けすぎだろー。実用にならないよ、、、、80%程度じゃ。

そして、決定的に敗北を味わったのが、いくつかある洋書(主にアメリカ)のバーコードスキャンをおこなったとき。

ぜんぜん認識されない。勝率1割程度。。。
当初からワールドワイドに展開♪とかうそぶいていたのに、なにこのありさま？
アメリカ向けにはバーコードスキャン機能禁止ってしないとならない？
ちなみにRedLaserはこちらも100%認識してました。

それでも、ちまちまとカイゼンカイゼンを勧めた結果、多少まともに洋書は読めるようになったけど、こんどは日本の本の認識率が下がりだした。

あっちを立てればこっちがたたず。

もう手詰まり状態で悶々とした日を数日過ごしたので、いっそのこととおもい、バーコード認識部、正確にいえば画像を取り込んでから２値化補正するまでの部分を、まったく新しい方法で実装し直すことにした。
それまでは画面を10分割くらいして、ちまちまドットを数えていたのだが、この新しい方式は分割は３つ。ドットもちまちまカウントするのではなく、X軸の各位置(dot)をY軸方向に全部加算して得られた値からバーコードを内部的に再構成してから、それのドットを数えるようにした。

で、これが大正解！！
日本のバーコードもアメリカのバーコードもほぼ問題なく読めるようになった。稀に間違いがあるよう(経験則からいって1〜2%程度かな)だけど、それも再度バーコードスキャンしてみればちゃんと読める。希望の99%はほぼクリアされただろう。
で、なにが良くなったかって、全体の計算量が減ったので、すごく反応がよくなったこと。レスポンスがいいので使っていてストレスがない。
バーコードをちょっとかざすだけでサクっと読んでくれる。(もちろんオートフォーカスがちゃんと焦点をあわせていることが前提だが)

RedLaserのバーコードスキャナと比べれば、もちろんまだまだ負けてるけど、負けすぎていない。十分実用になる範囲だ。

と、いうことで、この新しい方法を正式に採用し古いバーコードスキャンルーチンは捨ててしまい、これをいれたものをビルドしてAppleにアプリ申請した。
これが2月6日。

さてさて、申請のreviewがいつから始まってどうなることか、まだ先のことはわからんけど、とりあえずiPhoneアプリ第一弾は提出できた。

思いのほかバーコードの認識率がいいので、これを使った第２、第３のアプリの構想もはじめたので乞うご期待！

というわけで、これが現在の本業なのです。

そしてバーコードの読み取り機能

2010-02-08T05:39:00.006+09:00

さて、最大の目玉機能であるバーコードスキャンの件。

下調べはamazonアクセス実験なんかと並行して実施してたけど、amazon接続がうまく行くことを確認したので、本格的にバーコードの読み取り機能をつけていこうとした。

下調べ中にわかったんだけど、iPhoneのバーコード読み取り機能ってアプリで販売されている。(RedLaser)
しかも、このアプリは大ヒットらしく、TechCrunchにこの件について記事になっていたくらいだ。
それから、このアプリの会社は、このバーコードスキャン機能を有償でライブラリ提供しているようで、会社のwebサイトにライセンス料金が書いてあった。それによると、、、

デベロッパ登録は $50
最低$2,500
5万本以上売ったら、そこからパーセンテージでライセンス料ね。

とのこと。
100本とか200本売れれば御の字だぜ！と思っている身に $2,500はきびしーー。
てか、仕事がなくて貧乏になっているのに、ここで払える金なんぞありません！

とはいえ、バーコード読み取り機能がついてないと、当初の構想の達成にはならないので、最悪、金を払ってでもライセンスを受ける覚悟だけ決めて、まずは自分でバーコードスキャン機能を作ってみることにした。

まずはバーコードとはどのようなもので、ISBNとはどのようなもので、ISBNとバーコードとはどんな風に絡んでいるのか？ってのをwebなどで調べて、それぞれの規格を把握。
これをもとにバーコードの読み取りコードを書いていこうとしたのだけで、その前にiPhone固有の大問題が発覚した。

実はAppleから提供されるドキュメントや前述の「iPhone SDKアプリケーション開発ガイド」にはiPhoneカメラのリアルタイムでの画像取り込み、処理の方法がまったく書いてない。
カメラで写真やムービーを撮る方法はいくらでも解説がありサンプルコードが存在するのに、カメラ機能だけ有効にして写真をとらずに表示されているカメラの映像をプログラムに取り込む方法がまったくわからなかったのだ。
これはバーコードスキャンするほうからすると致命的な問題。だってバーコードの写真をいちいち撮影した上でそれをアプリに読ませて認識されるなんてしたくないじゃない？バーコードにカメラをかざしたら「ピッ！」とかいって即でamazonに飛びたいじゃない？

いやぁ、延々調べましたよ。セカイカメラやUStreamアプリ、それに上記のRedLaserもリアルタイムで画像処理してるんですよ。でもその公式APIが存在しない。まじで途方にくれました。
で、その探しいる途中ですごくヒントになるwebの書き込みを見つけました。

これですべてわかりましたよ。
そうなのです！カメラのリアルタイム画像を取り込むAPIはまったく存在しないのです。そんなものはもともとないんですよ！
カメラの画像を取り込むのではなく、カメラが写したiPhone上の画像を連続でキャプチャすればいいわけだ。
で、キャプチャもAPIがあるわけでもなく、いま現在iPhoneに写っている画像のビットマップメモリを直接参照(実際には一旦、別のCGImageにコピーしたものだけど)すればいいわけです。

実はこの機能も非公開APIなのだけどUStreamが審査を通過してからはその利用が暗黙のうちにOKになったようで、おかげでセカイカメラやそれにつづくAR/VR/リアルタイムカメラエフェクトなアプリも軒並み審査を通過している。
すごく合点がいきました。いっきに視界が晴れ上がった気がしました。

で、さっそくその機能をつかってバーコードをキャプチャし、仕様書をもとにオリジナルで考えたアルゴリズムでバーコードデータをリアルタイムで２値化、補正してみることにした。
それがこれ。

画像のが上半分が実際にリアルタイムスキャンしているバーコード。

その中段にあるのが２値化直後の画像。

そして下段、タブバーの上にある細い白黒画像が実際にバーコードとして認識させようとして補正を加えたもので、非常に鮮明にバーコードが二値化された。

で、これをバーコードの規格(JANコード)にそって読み出すと、ISBNコードを取得することができた。

やったね！　これで下手にライセンス料を払わないで済むことになるよ！

と、バーコードが読めた瞬間、

「オレって天才！　いま、世界はオレを中心に廻っている！」

と、いつもの勘違いを味わっていました。

その後に、まさかあんなことがおきようとは。。。

ちなみに、このバーコードの読取コーディングをはじめてから実際にISBNが読めるようになるまで約2日くらい。結構楽勝！

謎のamazonへのアクセス失敗

2010-02-08T04:43:00.003+09:00

さらに続くのだがｗ

そうなってくると、目的はしっかりしたので、手段を決めて、ひとつづつ解決していけばいいわけです。もう、ここまでくれば50%はできたも同然。
技術的に懸念があるとすれば amazonのAPI使ったことないのでその使い方の習得と、iPhoneでのバーコードスキャン機能。

バーコードスキャン機能はバーコードの規格やら画像認識やら面倒が多そうなので、まずはamazon APIへのアクセス方法を調べて実際にやってみることに。

これはそんなに難しくなかった。
amazonはすでにAWSのEC2をつかっていたりするのでデベロッパとして登録済み。なのでamazonサイトを漁って必要なドキュメントを読んだり、webで解説している人たちのサイトを参考にして自分でもAPIつかってamazonにアクセスしてみることにした。
もちろん、いきなりiPhoneのコードで書くと基本的なところでツマズいた時に原因の切り分けができない可能性あるので手馴れたPHPでwebサービスとして実験コードを書いてみた。資料もあるしPHPのコーディングは慣れているのであっという間に完成。個人的にamazon EC2のサーバを借りているのでそこに設置して実験してみた。
amazon.co.jpにISBNをItemの引数としてアクセスしてみると見事にamazonで表示される情報が引き出せた。これは楽勝！

と、おもいきや、なんかうまく引き出せない場合もある。
まったく同じISBNなのに、うまくできるときとできないときがあり、原因がわからない。ちなみにamazon.comやamazon.co.ukへのアクセスではこのような状況は発生せず、毎回、すべてうまくアクセスできた。amazon.co.jpだけ、なんかダメみたい。
webで同じ様な境遇が人がいないかと調べたけど、こんな症状はみつからないので、仮説をたてた。

◆仮説
仮定1.
amazon.co.jpのAPIリクエストを受けるサーバは複数台ある。
(これは仮定ではなくて実際そうだとおもう)

仮定2.
そのサーバは地域もしくはIPアドレスでフィルタされる設定がされている。
もしくはルータとかでフィルタされているかもしれない。
(実際、アクセスしてくるIPアドレスでブロックしていて、amazonからの接続を拒否されているwebサービスもあったらしい)

仮定3.
私が実験しているサーバのIPアドレスもしく地域(us東海岸)がそのフィルタにひっかかっている。IPアドレスはEC2から払い出しされたものなので可能性はある。

仮定4.
で、そのフィルタの設定はamzonのサーバ間で共有、統一されていない。
(不当なwebサービスをブロックしたいなら、一部サーバだけでもブロックすれば恒常的なサービスとして提供できなくなるのでamazonとしてはこれで問題はないだろう)

この４つの仮定が成立していることによって、私の実験コードはうまくいったりいかなかったりしているのではないか？
これはamazon.com/co.uk/.fr/.ca/.de のそれぞれでは発生しなかったため、amazon.co.jpだけの固有の問題だと思われる。

ってことでIPアドレスを変えればうまく行くだろう。という結論にした。
他にグローバルIPアドレスは持っていないので実験はできないけど、これを問題にしている人が見つからないということから、非常に稀な現象であろうと。なので１つでも仮定が崩れれば問題なくアクセスできるであろう。ということにした。こんなことでいつまでも時間とられれていても仕方なのでね。

まぁPHPで不安は残りながらもamazon APIの使い方はわかったのでそれをもとにObjective-CでiPhoneに実装してみたところ、もちろん、アクセスに失敗することなどなく、すべてうまくいきました。
仮説成立！めでたしめでたしｗ

ちなみに、この時点でISBNコードの手入力でブックレビューを表示するところまでは成功している。これ1月の中旬ごろのことだと記憶している。ここまでくれば機能的には70%はできたも同然状態でしょうか。最悪、バーコードスキャンのプログラムが失敗しても製品としては言い訳がたつくらいの機能はついています。

でも、本当にほしいのはISBNバーコードをサクっとスキャンしてレビュー表示する機能です。本題はこれからだっ！！！

注)
http://twitter.com/ohneta_/status/8064153065
http://twitter.com/ohneta_/status/8064154887
ここらへんで結論をtweetしてるけど、これはiPhoneで実際にamazon.co.jpにアクセスした結果をもとにして確証を得たあとの発言です。

それで本業であるiPhoneのアプリ開発なんだけど

2010-02-08T03:36:00.006+09:00

で、いっこ前の話題の続きになるけど、 12月初頭に Mac miniを購入してデベロッパ登録もした。仕事がなくて貧乏なのに年会費１万なにがしとか取られるんだよなぁ。
まぁ、それでMacの操作になれてみたり、ドキュメント読んだり、知人からいただいた本でiPhoneやcocoaフレームワークに慣れてみたり、、、。何を作るか決めてはいなかったのだけど、基本事項を習得していった。
で、実際にプログラムを書き始めると自分専用で使えるiPhoneがほしくなるわけで、12/23に私もMNPしてiPhone 3GSをゲット！

この日から本格的にiPhoneアプリ開発を開始です。

当初、嫁さんが欲しいといっていたマルチタイマーアプリを作ろうかなと目論んでいたんだけど、正月前にオライリーの「iPhone SDKアプリケーション開発ガイド」は読んでおくべきだなと思い、和歌山県で最大の本屋さんに出向いて購入。いったついでにiPhone関連の本も何冊か仕入れておこうとおもって、いろいろ漁っていたのだけど、どの本がいいのかよくわからなかったので、その場で持参したiPhoneでamazonのブックレビューを読んで選んでいた。で、その時、

ピンっ！

ってきたのよ。

実用書とかって実際どれがいいのかってわかんないじゃない？目的はわかっているのだけど手段がわからないから参考にしようとして本を買って読むのだけど、その本自身に書いてある手段がどれくらい参考になるのか、って自分じゃまだ理解できていない場合がほとんどでしょ？だからamazonのブックレビューとかとても参考になるし、参考にしてもらいたいとの思いで書く人もいるわけです。

ただ選択肢の本がいっぱいあると、そのブックレビューを見るためにamazonで検索するにも結構な労力が必要じゃない？と思ったわけです。 iPhoneなんか画面小さいからさらに苦労が多いわけですよ。まったく。
だったらさ、せっかく本にISBNついてるんだから、それ入力で即目的の本のブックレビュー読めたらうれしくね？ってのが最初の発想。
実際、amazonの検索ワードにISBN入れれば一発で検索されるんだけど、ブックレビューだけ読みたいのだからamazonの他の情報は邪魔なわけです。専用アプリでサクっと表示できたらいいのになー。と思ったわけです。
そしてISBNっていま出版されている本にはすべてバーコード印刷されている(ここ大事です！試験にでますよ！ww)のですよ。だったらiPhoneのカメラでバーコードをスキャンしてISBNを拾い出して、それのブックレビューを即読めたら、すごくうれしくね？　すごくね、それ？　欲しくね？少なくとも、いまの俺はすごく欲しいぞ！！
という連鎖反応がおきて、頭のなかでアプリの構想が決定してしまいました。
で、これ思いついたときに、すんごく興奮していっしょに行っていた嫁さんに話たんだけど、反応はいまいちｗ。
でも、まぁ、少なくとも俺は欲しいし、俺が欲しいと思うくらいだから、世界中で100人や200人くらいは欲しがるだろうと。ニッチすぎるかもしれないけど、でも欲しがる人はいるだろうと思い、嫁さん要望のマルチタイマーアプリは置いといて、自分の構想のアプリ開発を強行決定！(@自分の中で)したのでした。

これ、去年の12月28日くらいの話です。

flying tweetその後といまなにしてるの？

2010-02-08T03:14:00.002+09:00

いやぁ、最後にブログ書いてからすでに３ヶ月近く経ってしまった。
ちょいと本業を本気でやっていたので、flying tweetをぜんぜんやってなかった（汗
盛大にバグってるまま公開放置してたから、もうだれも使ってくれてないようだ。実際自分でも使ってないし。。。。

で、その本業のほうなんだけど、いまさらながらiPhone/iPodのアプリ開発を始めたのです。
去年の夏くらいから受注の仕事が全くなくなってしまって、収入の見通しがたたなくなってしまい、世の中不景気なので営業かけたところでそうそう受注仕事があるわけでもないし、現在住んでいる地域ではそんなもの壊滅的な状態。

なので、「こんな時こそ自分中心でできるものを作っておくべきだよな」とおもい、以前に作っていたwebサービスの展開を考えたり、現場復帰をちょっと希望している組み込み系マイコンやFPGAを触ってみたりとしていたのだけど、どうせやるならワールドワイドに展開したいの思いが強いので、今更ながらiPhone/iPodのアプリ開発をやってみることにした。

実際は11月に嫁さんがiPod 3GSに機種変して実際に触ってみて面白かった。ってのが要因なんだけど、昔とった杵柄でMacの(Macで)プログラムを書くこと(といってもSystem8ぐらいまでだが)に抵抗はないし、NeXTだってちっとは触っていたので、どうにかなるでしょう。。。と、相変わらず甘い考えで手を出しましたw

てことで、flying tweetはもちっと時間に余裕ができたら、開発再開したいと思っていますが、いまはちとペンディングにしといてください　_o_ 　>　関係各位

flying tweet alpha5はメモリ喰らい (バグか？)

2009-11-20T10:08:00.001+09:00

自分でも(てか、自分だけ？)alpha5を試しているのだが、クライアントがどうも「メモリ喰らい」の感がある。

一応、クライアント側はnow/friends/mentiosのそれぞれのメッセージを最大200件づつまで持てるようになっていて、余計なメモリ確保をしないようにしているつもりなのだが、動作途中でつくられるオブジェクトの解放がされないのか、どんどんメモリを消費しているようだ。firefoxでしかためしてないけど。

JavaScriptだから動的なメモリ確保は言語任せだし、オブジェクトの参照がなくなればメモリは解放されるはずではあるのだが、どうもそうなってはいないみたい。どこかで参照が残り続けてるのかもしれない。これは困った。

通常のwebページであれば、継続的に表示されつづけることはないので、多少メモリリークしていてもブラウザを閉じちゃえば完全に解放される。しかし、webアプリケーションとして提供する場合、比較的長時間、そのページ(webアプリ)を開き続け、さらにそのページ内で動的にいろいろ動作するので、メモリリークは深刻な問題だ。

手っ取り早い解決方法は、重くなりはじめるポイントを見つけて、そのタイミングでページをリロードしてしまえばいいのだけど、現在のクライアント実装だとリロードするとそれまで溜め込んでいたメッセージ情報も解放されてしまうので、ユーザインタフェース的にはダメだろう。

解決策として、クライアントの溜め込んだメッセージをサーバ側で保存して、リロード時にそれをクライアントに渡す。という方法を考えたのだが、twitter自身をメッセージのストレージとして使う的な目標もあるので、この方法は本末転倒。

なんかうまい方法を考えないとなぁー。というか、メモリリークをなくさないとな(^^;

flyingtweet alpha5

2009-11-18T12:35:00.006+09:00

まだアルファ版ですよ。

機能が決定できないのでいつまでたってもアルファ版です。どこぞの「永遠のベータバージョン」よりひどい状況だなｗ。

で、alpha5。クライアント、サーバとも書き直してみた。

クライアントのほうはalpha2～4まで、timelineはIFRAMEを使って子ページで実行したいたけど、親子間でデータの受け渡しが面倒になってきたので、YUIのタブ機能を使って１つに納めることにした。

もともとはファイルを分離すればコードの見通しがよくなるだろう、という単純な発想からIFRAMEつかってみたのだけど、親子間でいろんなデータの受け渡しをするようになってくると、逆に分離されていることの煩わしさが気になり出して、今回、クライアンのト書き直しでJavaScriptのコードが減ったので、まとめてしまうことにした。

いやぁ、コードのどこからでもデータが参照できるので楽になったよｗ

あと OAuthに対応。対応ってか、完全依存。。。

ログイン後もOAuthのライブラリを使ってtwitter APIを発行するので、APIは完全に依存してしまった。

ただ、これだとtwitter停止時に独自にメッセージ配信をおこなう。という当初の2大目標のうちの１つが出来なくなってるのよねー、、、いや、できなくはないのだけど、サインインをどうするかを決めてないので、結局、このバージョンでは出来てないわけです。

flying tweet側で会員登録するのでは本末転倒だし、なんか安くてうまい方法あればなー。OAuth認証されたら、｢認証済みだよ」cookie設定しておいて、twitter停止時はだけそのcookie参照すればいいかな。twitter停止時だけ利用するなら、そんなに悪利用されることもないだろう。ん？悪用はないよな？　たぶんないよな？なければいいな。。。あったらどうしよう。。。。。。。(T_T)

で、TLは最大200メッセージまで保持できるんだけど、現バージョンは20固定。最大TL数は内部では変数でもっているので単に手抜きで20で固定しちゃっている状態。

timelineのアップデートインターバルなんかもそうなんだけど、ここらへんはクライアント側の設定画面で変更できるようにするつもり。表示や回線負荷は個人の環境に左右されるからね。

サーバ側はベースの考え方に変更はないんだけど、フォローしていない第3者にreplyメッセージが配信されちゃうって不具合があったので、その対策。これはtwitterのfriends_timelineと同じ動作になるように工夫した。

本当にこれは工夫が必要。

flying tweetは全twitter会員のfollowerリスト持ってるわけじゃないから、だれがだれ宛にメッセージを配信するかの判断をさせるのは結構面倒な処理だった。

それと、サーバへのアクセス方法はweb API化した。twitter絡みのアクセスはほぼtwitter API互換。flying tweetの大本の発想はサーバ側からでたものだったので、クライアントは単にサーバの動きを確認してもらうためのツールでしかない。なのでこのAPIを使ってクライアントをつくってもらえたらうれしいな。という甘い考えが本音ｗ。

てなわけで、alpha5は大幅な刷新がなされているわけです。

つまり、新規のバグもたくさん含んでいるということ！！そこをご注意のうえ、ご利用いただければと思います　：）

flying tweetへ

書き直し中

2009-11-14T04:05:00.002+09:00

flying tweetを書き直してます。alpha4まではいろいろ試行錯誤してたので、クライアント側のコードがグチャグチャで見通しは悪いし、メモリリークっぽい動きはするし、えらく重くなったりするし、、、と、ちょっと動作が残念な状況になっていたので。

サーバ側はけっこうシンプルですっきりできているので、根本的には手を入れるつもりはないのだけど、ちょっとおもしろいこと思いついたので、それを入れておこうかなと。

あ、あとtwitterのOAuth登録したので、次期バージョンからはOAuthログインできる予定。

quick tweet → flying tweet 早速名称変更

2009-11-12T07:16:00.007+09:00

quick tweetはあんちょくに名付けてしまったのです。

だって、quickにtweetできるから。。。。

α版を公開してから気づいたけど、「QuickTweet」って名称のtwitterプロダクトは結構あるようで、すでにiPhoneとかでは有名らしいので、早々、名称を変更。

結構悩んだ(約1時間)末、またogochanから「Flying Twitterでいいんでねの？」的に提案があったので、それで、、とも思ったのだけど、名称に「Twitter」が入ってるのは問題かな？と。

一応、今後のことも考えてTwitterのOAuthを実現するつもりなのだけど、その申請時にサイトの名称を登録しなければならないので、へたに刺激しないほうがいいかなとおもって無難に flying tweet としてみた。

ちなみに全部小文字で書くのが正式です。なぜだかわかりませんけど。

ということで、今後は flying tweet として開発していきます。てか、開発継続なの？本当に？(汗

quick tweet (仮称)を作成中

2009-11-11T17:03:00.006+09:00

ご多分にもれず私もtwitterを使ってるわけですが、time line(TL)の表示のタイムラグやサイトが重くなってサービスがつかえない。ってことが結構頻発してる。

で、まぁ、twitterってそんなものだよなぁー的に思っていたのだけど、twitterでfollowingしているogochanが「メッセージの配信をtwitterにまかせるのではなく独自にやっちゃえばいいんでね？」的なことをつぶやいているのを読んでちょっと興味があったので実験しながら作ってみることにした。

以前からtwitterのクライアントだとか自サーバを介してのサービスだとか実験的には作っていたので、twitterへのアクセスは比較的簡単に実現。

自サーバ経由でAPIを呼び出すと呼び出し制限数にすぐにひっかかるので、webクライアントからAPIを呼び出して結果を自サーバに送りつけて自サーバ側でTL管理とか以前つくったものがあるので、これらを整理して、ちょろっと作ってみたのがこれ。

http://site2.ohneta.net/

ユーザインタフェースとかまったくアイディアがなかったので作りながら考えてるとこあるので、リリースごとに極端に画面や機能が変わることがあるのでお気をつけてｗ

python3/mod_wsgiで日本語表示

2009-10-28T09:00:00.002+09:00

python3 (python3.1.1)＋mod_wsgiで日本語なページを表示しようとしたら、なんかエラーがでたので、もろもろ調べて対策してみた。

その顛末を自分のwikiページにまとめたよ。
http://www.ohneta.net/wiki/index.php?python3%2Fmod_wsgi%E3%81%A7%E6%97%A5%E6%9C%AC%E8%AA%9E%E8%A1%A8%E7%A4%BA

いろいろ集めてみる。

2009-09-09T07:23:00.004+09:00

mixiの日記機能が閉じた環境なので、friendfeedに繋いでみた。
これなら、twitterもbloggerもはてなもまとめてmixi側に出すことができるとおもう。

問題はmixi自身がfeedの反映が遅いってことか。
friendfeedはなんであんなに反映がはやいの？pingしてるのかな？

関数型言語わかりましぇーんｗ

2009-09-05T08:14:00.015+09:00

やっぱLisp使いってかっこいいじゃない？20年くらい前かなぁ、、、Franz Lispの人(もちろん外国人w)とちょっとだけ仕事したことあったんだけど、やっぱLispで食っている人は、私らマイコンあがりからしたら別世界の人だった。
当時はMIT震源地のLispブームみたいのもあったので憧れだったりと。。。

で、この20年くらいLispかっこいいなぁ、関数型言語すげーなー、、などと思いながらも、仕事ではC→C++→Java(webに転向)→Perl→PHP/JavaScript って感じでメイン言語を渡り歩いてきたので、まったく関数型言語を使う機会がなかったわけ。関数型言語を使うような仕事って、私がいたような環境ではありえなかった。

ところが、ここ最近、日本ではrubyでなんかする。ってのが流行りだしてきている。rubyってぜんぜん詳しくないのだけど、ちょっとみLispを現代的なセンテンスで書き直したって感じ？と思っていたりしたのだ。

それから、なんかHasｋellやOCamlが話題だし、MicrosoftがF#を出してきたりと、関数型言語を実際の仕事として使える環境が整いだしてきたような気がする。

さらに言えば、いままで使ってきた言語類もその拡張でイテレータが普通に使えたり、lambdaできるようになったり、FirstClassObjectが使えたりと関数型言語の特徴が取り入れられてきていることで、だんだん関数型言語が身近になってきている。

特にJavaScript。こいつ、あまり好きな言語ではないのだけど、それはなぜかというとwebでHTML書くときに使うから。
webではデザインとロジックを分離して書くのが主流の現在、HTMLの修飾のために使われていたりするので「どうもなぁ～」と思っていたのだけど、単純に言語としてみるとそれはそれでよくできている。DOM内蔵してるしねｗ。
で、いま、JavaScriptを触っている人が大量にいるわけで、JavaScriptの現代的な記法に慣れた人にとって関数型言語の概念は結構すんなりと入っていくのではないかと思うわけです。

かく言う私は、それはもう旧態然とした脳なのでなかなかハードルが高いのだが、やはり関数型言語を華麗に操るプログラマはかっこいいわけで、やらないわけにはいかない！ってのがここんとこのキモチ。

とはいえ、食っていくためにはPHPもやるしPythonだってやるさー。しゃーねーもんっ！

ううーーポータビリティにならない。。。

2009-09-05T03:33:00.002+09:00

ハード的に同一サーバ上で開発環境とステージング環境を提供している。(実行環境)
しかも、初期化情報ファイルをweb側とバックグランドバッチ処理側で共通化している。(ファイル環境)

これが面倒なことこのうえない。
実行環境を切り替えるためにスクリプト内でdefineしている部分があるのだが、それをインクルードするファイルのディレクトリはファイル環境によって変えなければならない。つまり環境によってディレクトリが変わるが、ディレクトリの指定は環境を前提にしている。。。。なにをいいたいのかわかりづらいな、、、

んま、端的にいえば、条件が２重になっていて、それぞれが依存関係にあるので、共通化できないのだ。

これは非常にこまった。
環境変数とかで指定する方法もなきにしもあらずなのだが(実際、ほかのサイトではそうやってるものもある)、サーバ環境に依存しないポータビリティを追求している(していた)ので、ここで妥協するのはちと悔しいのだ。
どうにかならんもんかなーーー。

こうなんか、漲らない

2009-09-01T02:20:00.003+09:00

なんかねー、ここ数日、本業以外のとこでいろいろ面倒な細かいことがあって、まとまった時間がとれない。
プログラミングなんてまとまった時間がないと進まないものだから、どうもダメだねぇ。
で、中途半端な時間で作業しても、中断されたとこから元に戻すのに、またいくらかの時間がかかる。

頭の思考を100%プログラミングに向けないと仕事できないようだな。わたしは。
自分ではコントロールできない状況をすごく嫌っているようだ。

と気づかされるここ数日であった。

結論は別RDBMSをqueueにみたてて読み書きGo!Go!

2009-08-17T13:58:00.007+09:00

結論からすると、RDBMS自身がネットワーク越しに接続できるのだから、それを利用しようということになりました。
messageに対して１対１で処理プロセスが走るならメモリ上のqueueでもいいのだろうけど、1つのmessageで複数の情報を生成するつもりなのでね。あ、あとqueueからmessageを消すタイミングは時間ベースでやるし、リレーションしやすいというかすでに慣れてるRDBMSのSQLでやろうかなと。

さー、DBのschemaガチガチに固めなければ、、、いまどきっぽくないですけどっ！(T_T)

で、いろんなfeedを提供したいのだが、

2009-08-16T17:56:00.006+09:00

いろんな切り口でRSSってかfeedを提供したいのだが、message queueに入ってる情報をどう使うかはクライアント(この場合、提供するfeed情報を生成する)プログラム側の処理次第。

で、じゃ、いつまでqueue内の情報は残しておけばいいの？ってのが問題。
クライアントプログラムがどのように切り込んでくるかはわからない状態だと、永遠にすべて残しておかないといけなくなる。さすがにそれは無理ぽ。
だとすると、やはり先に生成するfeed情報を決めておかなければならない。そうしないとqueue内のデータがいるのかいらないのか判断をつける材料がないもの。

さーて、困った。
どこまでほしいんだ？個人的には what's new と個別テーマくらいでいいかなとは思うのだけど、mylistの更新情報もfeedでほしい気がする。
他にも共通グループでのfeedもほしいかもな、、、グループは大枠できてるし、このまま採用されるだろうから、それも考慮しておいたほうがいいよな。
あー、だれそれさんって個人ののfeedもほしいかなー。

feed集めて表示してるfriend feedとかfacebookとかはどうやってるんだろうか？
動的に取ってるわけでもないだろうし。。。むむー、悩むぅ～～～～

だいたい提供するfeedそんなに多くていいのか？ mylistを分類できるようにしといて、それをfeedすればよくね？「feedしたかったらmylistに登録しやがれ、このヤロウ！」と言い切れるしｗ。

でだ、

2009-08-14T22:41:00.005+09:00

そうなってくると、更新のタイミングで処理するものが多くなってレスポンスが悪くなるのがみえみえ。
まだ、ユーザが少ないので更新なんてそうそう発生してないから、マシンパワー使いたい放題だけど、ユーザが増えてきたらここらへんが効いてきそうだなーと。60万PV/日の携帯サイトをやってた経験からね。

なので、リアルタイムで更新する必要のないものは、チマチマとバックグラウンドで処理しようかなと。RSS の書き出しとかtwitterでつぶやきとか。(RSSつける前にtwitterのつぶやきI/Fをつけたあたり今時でしょ？ｗ)

ということで、そんなときは、メッセージキューだよな、と。IPCだと同一マシン(ていうかOSのインスタンス)内でしか利用できないので、それは却下。ネットワーク越しにできたほうがいいじゃない？いまは利用しなくても将来的に絶対に。
てことでActiveMQやらRabbitMQやらを調べていたのだけど、結構面倒そう。Java環境入れなきゃならんしねー。もちっと軽量なのないかなぁー。

でけた。RSS

2009-08-14T22:26:00.005+09:00

なんと、問題はURLの&でした。xmlを書かなくなって久しいので、こんな問題にひっかかってましたよ。とほほ。つか、HTMLは普段書いてるんだから、意識しろよ＞おれ。

てわけで、とりあえず what's new をRSS1.0で書き出せるような仕組みはできた。
あと、個別のテーマ更新もそれを追ってる人向けにRSSできればなぁ、、とおもい、更新のタイミングをトリガとしてRSSファイルをベースにした更新履歴を考えたのだが、そうなると、RSS1.0よりもRSS2.0のほうが簡単な処理で済みそうなので、RSS2.0ベースで全体で使えるユーティリティクラス化してみた。

当初、node操作なんぞせずに、ベタにXMLファイルを書き出すつもりだったけど、node操作しないと履歴操作できないから、結局DOMでガリガリにXML操作するハメになったし。。。実に10年ぶりくらいにDOMでXML操作したよ。はじめてつくった携帯サイトがXMLバリバリでつくったヤツなので、あれ以来。いやぁ、XPathだとか便利なものも揃ってるし、いいね。いまどきのXMLは。

2009-08-13T15:07:00.002+09:00

ハート型のビーズに黙々と糸を通していく娘、３才。

すでに５０個くらいは通したようだ。
色はバラバラだが、すべて同じ方向に通してるぞ、、、

なんかチマチマした作業が好きなのか？

自分がダメだと思う瞬間

2009-08-13T09:42:00.003+09:00

エロサイトを見ていて大量のサンプルムービーを見つけて、その一括ダウンロードスクリプトを書いているとき。特にJavaScriptとか絡めれて簡単にぶっこ抜きできなくしてるようなサイトを攻略してるとき。

すべてのしがらみを振り切って、一心不乱にサイトの構造とかファイルの規則性だとか見つけ出したり、HTMLやJavaScriptを読んでどう動いてるか調べてるときに、ふっと我に返ってしまうと「ああ、おれ、ダメじゃね？」と思う。
だが、そんなものは一瞬なので、すぐに作業に戻るのだがｗ。

てか、その情熱を生産的ななにかに向けろよ、、、４２才のおれ。(汗

やっぱいまどきのサービスを作ってるんだから

2009-08-13T09:26:00.003+09:00

feedできなきゃね。とおもい、RSSを自動生成しようとしてるのだが、
なんかうまくないのです。

ひとんちのサービスが提供してるRSSファイルを参考にいぢってみたりもしたのだが、
まるまるコピーする分にはうまくいくけど、大幅に項目削除して縮小版とかつくってみるとうまくいかなくなる。

なんでかなぁ～。もちっと悩んでみるかぁ...(T_T)

私の中のmixi終了のお知らせ。

2009-08-12T14:51:00.003+09:00

私の中ではmixiは利用価値が激低下。
単なる知り合いのblogのfeedの価値ぐらいしかない。
あ、ときたま２ホップ以上の知り合いで近しくなりたい人はでてくるけど、んま、それもmixiである必要はなし。私がwebサービスに求めるものがmixiでは実現できないので、利用価値激減。

ユーザ側の要望（つか進歩？）をフォローしきれなかったmixiさん、敗北です@私の中。

AmazonEC2 postfix submisson 設定時のメモ

2009-08-12T12:03:00.003+09:00

ローカルのPCのHDDが吹っ飛んだりした場合、メモをなくすと困るのでブログに書いとく。
---------------------------
■環境
amazon ec2 m1.small
(fedora x86/32bit インスタンス)

submmision port = 587
TCP/UDPの両方が必要

MTA is postfix.

■submission portを開ける

/etc/postfix/master.cf
#submission inet n - n - - smtpd
↓
submission inet n - n - - smtpd

■SMTP Authする
/etc/postfix/main.cf

smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
#smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes

aws EC2 の fedora8 Basicでは sasl2はデフォルトインストールっぽい....
一応、確認...
> # cat /usr/lib/sasl2/smtpd.conf
> pwcheck_method: saslauthd
> mech_list: plain login

いらない
mkdir /var/state/saslauthd
chmod 700 /var/state/saslauthd
chown postfix /var/state/saslauthd

saslauthd で使用可能なメソッドを確認。
># /usr/sbin/saslauthd -v
>saslauthd 2.1.22
>authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap

とりあえずpamで運用。

sasl2の起動
/etc/init.d/saslauthd start

動作してることを確認
> # ps ax | grep saslauthd
> 31697 ? Ss 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31699 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31700 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31701 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam
> 31702 ? S 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam

postfixの再起動
/etc/init.d/postfix restart

----------------------------------
■popperの設定
dovecot.i386
dovecot-devel.i386

># yum install dovecot.i386 dovecot-devel.i386

/etc/init.d/dovecot start

----------------------------------
■EC2の Security Groupsの設定
メール関連部分のみ抜粋

C/Method Protocol FromPort ToPort Source
POP3 tcp 110 110 0.0.0.0/0
SMTP tcp 25 25 0.0.0.0/0
- tcp 587 587 0.0.0.0/0
- udp 587 587 0.0.0.0/0

----------------------------------

■動作確認
自ホストから....
># nmap localhost
>
>Starting Nmap 4.52 ( http://insecure.org ) at 2009-08-12 02:36 UTC
>Interesting ports on localhost.localdomain (127.0.0.1):
>Not shown: 1705 closed ports
>PORT STATE SERVICE
>22/tcp open ssh
>25/tcp open smtp
>80/tcp open http
>110/tcp open pop3
>143/tcp open imap
>587/tcp open submission
>993/tcp open imaps
>995/tcp open pop3s
>5432/tcp open postgres
>
>Nmap done: 1 IP address (1 host up) scanned in 0.155 seconds

外から...
>$ nmap さーばあどれす
>
>Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2009-08-12 11:54 JST
>Interesting ports on さーばあどれす:
>(The 1654 ports scanned but not shown below are in state: filtered)
>PORT STATE SERVICE
>22/tcp open ssh
>25/tcp open smtp
>80/tcp open http
>110/tcp open pop3
>587/tcp open submission
>
>Nmap run completed -- 1 IP address (1 host up) scanned in 35.845 seconds

メールサーバ移行の手順メモ for 自分

2009-08-11T20:45:00.003+09:00

旧DNS
MX=旧サーバ
TLLを300程度にする。浸透するまで待つ。(いまのままだと10時間程度)

■新サーバ
新DNSをたてておく

SMTP AUTH/TSLでpostfixを入れる。
旧サーバと同等のアカウントを作る。
旧サーバと同等のmain.cf/virtual/aliasを用意する
(virtualで旧サーバのアカウントをフォローしておく)

別ドメイン名の新旧DNSのMXを新サーバに向け、それで送受信ができることを確認。
-----------------

旧サーバMTA停止
DNSのMXを新サーバに向ける

10分程度待ってで新サーバにメールがとどくかどうかチェック

ドメイン名のレジストラにDNSの変更通知(新DNSに変更)
了承がとれたら、旧DNS停止

以上。

FriendFeedが買われた。

2009-08-11T09:54:00.005+09:00

んま、企業の売買はよくあることなので、珍しくもなんともないのですが、買ったのはFacebookですか。
金に困って売った。的なものではないようなので。

なんていうんですか、feedを集めて１つのコンテンツにする。って最近のはやり、名称はよくわかりませんが。この手のサービスは、元ネタ提供の他のサービスから独立した位置にあって成立しているのでおもしろいとおもっていたのですよ。

あ、ああ、あれだ。mixiがなんでもかんでも囲い込んでしまっているのとは対照的な位置ですね。
オープンな感じ。個人の采配で好きなようにサービスが組み合わせられる。という感じ。

んとね、以前からなんかやれそうだな。とは思っていたんです。んま、自分でやってないのでその時点で負け犬の遠吠えなんですが。
この手のソーシャル系サイトとかブログとかニュースサイトなんかでもいいんですけど、今時的にいえばリアルタイムストリームサイト(？)などの更新が頻繁なものを、個人にどうみせるか。ってインタフェースね。
もう、webでしかサービスが許されないような状況になりつつあるので、やるならweb上で。

常に集めて、趣味嗜好、現在の興味のターゲットでリアルタイムに分類して、表示方法も工夫。
たとえば、いま興味の中心になっているものは大きく見やすく、情報量多めに。
iTuneとかsafariのUIでCDジャケットやらwebページが3次元的に並んでいて、注視しているところが中心に表示されるヤツあるじゃないですか？あんな感じのもっとイイやつ版。
もちろん、ぼんやりとしか考えてないので、どうすればいいか？なんてわかりませんよ。そりゃ。汗。
でも、あの手のUIで見せてあげれば、人の思考の補助装置としてはとてもよいのではないかなー
と思っていたのです。

で、その手の可能性としてFriendFeedを使い始めたのですよ。
そしたらその矢先にFacebookによる買収って。
いや、ただ、いまFriendFeedとtumblrに注視してたのでこの話題を書いてるだけです。

ここから

2009-08-10T21:43:00.001+09:00

friendfeedを経由してtwitterにでるのか？ほんとに？

よ、わからんちん。

2009-08-10T15:37:00.001+09:00

よっ！？？？
どう？