ページ

2010年8月31日

学生のころのプログラミングの力

会社ではなんだか、新入社員を採ろうとしているようです。当然、開発の人もです。僕は他の職種についてはよく分かりませんが、プログラマについては新入社員はとる必要がないと思っています。プログラマであれば、未だ学生であろうが、既に卒業していようが、いつでも採用すればいいだけで、新入社員という枠にくくる必要はないのかな・・・、と。とは言っても、社会人経験がないと、最初の名刺の渡し方とかの練習は必要ですが・・・。なので、どっかで新入社員を募集するかも知れませんが、そんなのは関係なく、会社のWebページの採用のところから申し込めばいいのです。そっちの方が自分でちゃんと調べた感がでて、評価が高くなるかも。

で、もう、十数年前のころ、僕が学生だった頃も就職は大変だったらしいですが、今の方がもっと大変なのかも知れません。就職活動もとてもがんばった訳じゃないので、特殊な環境だったのかも知れません。

で、就職活動(実質一社しか受けていない。もう一社は面接で断ったので)を経てプログラマになったのですが、学生のころは周りにプログラマが沢山いたわけではないです。なので、全体の中での自分の位置づけが全く分かりませんでした。今は、ネットの中に情報は氾濫しているし、人のコードもごろごろ落ちています。で、それらを書いた人たちに会うのも比較的容易です。でも、ちょっと前まではそうしたことがちょっと敷居が高かったので、自分の位置づけが分かりませんでした。まあ言い訳かも知れません。位置づけが分からないので、プログラマとしての自信がありませんでした。今も、本心としては自信はないのですが・・・。

なので、自分のレベルは一番下だと信じ込んでいました。就職すると、プログラマの人はうじゃうじゃいました。同期の人も、先輩も。で、自分より下の人は見ないので、その環境でもやっぱり僕は一番下だと信じ込んでいました。うーん、劣等感の塊だったような気がしてきた。 と言っても、周りの人は全くそんな風に感じていなかったと思いますが・・・。

で、自分のことを一番下だと思っているのに、面接なれしていない時にその時の自分を面接したら・・・。多分、採用していないでしょう。キリッ。

まあ、今はブログとかでいろいろ評価しやすいので、面接受けまくるより、ちゃんとした技術系のブログを書いて、技術力とか自称しているような会社を受ければいいじゃないかな。そうすれば、面接でおおぽかしない限りなんとかなると思う。 



2010年8月28日

誰にも理解されないこと

どんなに説明しても、悲しいくらい誰にも理解されないことがあります。その中の一つに半休があります。一日会社を休むんじゃなくって、半日だけ休むというやつです。僕は半休が好きで、無意味に半休をとって突発的に休みたくなるときがあります。一日中休みたいんじゃなくって、半日だけ休みたいのです。

このことを会社で話すと、「全休でいいじゃん」と、みんな納得してくれません。どうせ休むんなら一日休むというのがすべての人の意見でした。でも、僕は全休じゃなく半休がいいのです。

半休で何をするかと言えば、うーん、基本的には何もしません。僕が覚えている限りでは、初代iPhoneを買ったときが最初です。でも、このときは、契約が遅れて全休になっちゃいました。その次がiPhone 3GSを買ったときです。このときは、半休をとってお店にiPhone 3GSを見にいったのです。買うつもりはなかったのですが、なぜか買って会社に行きました。それから、2回ぐらい半休をとったことがあります。

半休をとる場合は午前休です。たぶん、午後に休みを入れたい場合は、お客さんに会う時間を調整して、直帰しちゃうから必要ないのかも。休みたい理由は、

1. 朝ゆっくり寝ていてもいいという安心感、心の余裕。でも普段通りに起きます

2. お昼頃に会社でみんな一生懸命仕事をしているんだと思いつつ、のんびり電車に揺られている倒錯感。

3. 会社に行く前に、ちょっと寄り道するわくわく感。(家をでる時間は大体同じです) 

すばらしいじゃないですか?でも、誰にも理解されません。会社のakayamanが今週の月曜日に午前休をとりました。「やっぱり分からん」と。 うーん、いつも通りに起きなかったか、いつも通りに家を出なかったせいだ。それから、寄り道せずに会社に来ちゃうからだ。

それとも、僕はちょっと寄り道すれば江ノ島とか鎌倉に行けちゃうから違うのか? 

と言うことで、みんなで午前休をとって、会社に行く途中でどこかで寄り道してみてはどうでしょうか? 



2010年8月27日

gdataでGoogle Calendarのイベントの検索とデータの登録、ついでに削除

ふざけたタイトルのエントリですが、昨日の続きです。

1. 検索

昨日のエントリでは、カレンダーのイベントの取得は、GetCalendarEventFeedを使って取得しました。この人はお手軽なんですが、取得した一覧がどういうものかよく分かりません。まず、このAPIはデフォルトでは25件しか結果を返しません。これはmax_resultsで制御できるようです。続きを取得したければ、eventのGetNextLinkを使えと書いています。このへんの制御は負荷の問題もあるのでしかたないです。取得する25件がどういう順番なのかわからないのが不満です。ドキュメントを読めば書いてあるかもしれませんが、無意味に全部そうなめしてもうれしくありません。前後ひと月分のデータをハンドリングしたいだけなので、期間を限定して取得します。

query = gdata.calendar.service.CalendarEventQuery(calendar_id, "private", "full")
now = time.time()
query.start_min = time.strftime("%Y-%m-%d", time.gmtime("%Y%m%e", now))
query.start_max = time.strftime("%Y-%m-%d", time.gmtime("%Y%m%e", now+60*60*24*31))
query.max_results = 256
feed = self.client.CalendarQuery(query)

これで、feed.entryにひと月分入っています。256件超えるとその分はとれませんが、そんなに僕は忙しくないので気にしません。

2. ついでに削除

まあ、削除は簡単です。

event = feed.entry[0]
client.DeleteEvent(event.GetEditLink().href)

client.DeleteEvent(event)とかの方がスマートに思いますが、まあ、ほかのところもこんな感じなのでなれるしかありません。

3. データの登録

データの登録はめんどくさいので明日。


それ以外で、あるカレンダーとGoogle Calendarでデータのマッピングをどうするかで、icalのuidとgoogleのeventのidをマッピングすればいいのですが、そのためにはマッピングテーブルを別に持たないといけません。マルチスケジューラ、通称マルスケはマッピングテーブルを外部に持っています。gdataのcalendarにはuidがあるので、それでマッピングできると思ったのですが、どうなんでしょう?あと、googleのイベントのlinkにicalのurlを持たせてマッピングしようかと思ったのですが、こっちはますますよくわかりません。

ということで、のんびりと遊んでいます。いや、お仕事がなぜか忙しんだが・・・。誰かの呪いに違いない。

2010年8月26日

pythonでgdata

googleさんのgdataを使ってGoogle Calendarをごにょごにょしてみました。gdataのAPIはversion 2.0と1.0の二つあるみたいです。version2.0はJavaと.netしか言語をサポートしていません。Pythonは1.0系しかないです。ちょっと悲しいですが、できることがそれほど大きく変わる訳じゃないので、気にしません。

さて、インストールはやっぱりいつものeasy_install gdataです。でも、ソースコードをダウンロードしてsampleディレクトリをみると、だいたいAPIの仕組みがわかります。よいサンプルコードです。すばらしいです。さて、それじゃ、順番に。

1. ログイン

import gdata.calendar.service

client = gdata.calendar.service.CalendarService()
client.email = "my_google_email_id"
client.password = "my_password"
client.ProgrammaticLogin()

です。ちょっと、4行目、5行目あたりがきもいですが、気にしません。

2. カレンダーの一覧を取得

feed = client.GetOwnCalendarsFeed()
for calendar in feed.entry:
    print calendar.title.text

これだけです。かえってくるものはatomです。atomのフォーマットができた頃は、こんな無意味に汎用的なもの、誰が使うんだ?blogの更新に特化しておけばいいのに・・・、と思っていましたが、gdataをみていると僕の考えは浅はかでした。

3. カレンダーのエントリーを取得

feed = client.GetCalendarEventFeed()
for event in feed.entry:
    print event.title.text

これで、デフォルトカレンダーの予定の一覧がとれて出力されます。calendarの一覧の取得方法と対比すると、フォーマットなどが類推しやすいですね。

さて、特定のカレンダーの中のエントリを取得するにはどうするんだろう?と言うことで、ドキュメントらしきものを読みましたがわかりません。GetCalendarEventFeedのuriのデフォルト引数をみると/calender/feeds/default/private/fullとなっています。多分defaultをカレンダーのIDを指定すればいいはず。あらかじめわかっている場合はそれを直接書けばいいですが、カレンダーの一覧から適当に選んだものを指定したいので、どうしよう?

ということで、

cal_id = calendar.id.text
cal_id = cal_id[cal_id.rindex("/")-1:]
feed = client.GetCalendarEventFeed("/calendar/feeds/%s/private/full" % cal_id)

としました。ちょっと違和感がありますが、まあよしとしましょう。目的の動作ができました。

2010年8月25日

icalendarとPythonと・・・

ちょっとわけあって、iCalendarのファイルをパースしたくなりました。会社ではグループウェアとか作っているのに、僕が直接iCalのファイルを操作するのは初めてです。世の中そんなものです。会社はJavaですが、個人の不満を解消するのにわざわざJavaで何かを作る気はしません。やっぱり、Pythonになっちゃいます。まあ、そのうち、会社に捨てるかもしれませんが。
さて、python icalendarで何がよいかGoogle様にお伺いをたてると、iCalendar for Pythonのお達しがくだりました。ページをみるとバージョンが1.2で更新日が2006年です。死んだプロジェクト?とか思いましたが、代替がなさそうなのでeasy_install icalendarでインストールすると、2.1がインストールされました。あれっ?と思ってみると去年の年末に更新されています。完全に死んだ訳じゃなさそうですが、ホームページが更新されないと不安になります。まあ、最初は僕のお遊びなので気にしないことにします。

それでは、icalのファイルをパースしてみます。

import icalendar

cal = icalendar.Calendar.from_string(open("mycal.ics").read())
events = cal.walk("vevent")
for evt in events:
    print evt["summary"]

のようにすれば、summary(タイトル)が一覧されます。日付の扱いがまだよく分かりませんが、おいおい。それではまた。

2010年8月23日

トゥクトゥクと言う乗り物に乗ったぞ

夏です。暑い日が続きます。家から5分ぐらいのところに海水浴場がありますが、ほとんどが原住民です。大磯や茅ヶ崎の海水浴場にも行くことがありますが、ほとんどが原住民です。サーフィンする人は遠くから来ることもあるらしいですが、それはよく分かりません。まあ、そんな感じの夏の近所ですが、先週末にトゥクトゥクと言う乗り物にのりました。ホテルの送迎用の乗り物らしいです。

公園で子供と遊んでいたら、見かけぬ変なバイクのようなものが止まっています。子供と近づいて見ていると、乗せてくれました。ホテルの送迎用の乗り物らしいです。でも、とっても暇しているらしいです。朝から晩まで、乗せるべき人がいないので、近所の人とおしゃべりして、近所の人をのせてその辺をドライブしているそうです。夏だから少しは客がいるんじゃ?って聞くと、「いないね〜。お盆のころはちょっとは人がいたけど、まあ、暇だよ〜」「暇だからこうやってそこらへんの人を乗せて暇を潰しているんだけどね」。

うーん、そもそも、僕が遊んでいるあたりはお客は全く来そうにないところですが、なぜそんなところにいるんだろう?いや、だからか?とか思っちゃうのですが、ホテルの経営状況とは裏腹にのんびりしたおっちゃんで、嫌いではないです。この乗り物のおかげで、近所では割と有名人です。まあ、サーファーとか、そこらへんのおっちゃん、おばちゃんは割とそういう人が多いですが。

経営的にはこれはどうなんだろう?と思いつつ、地域のコミュニケーションとしてはとてもおもしろかも。いや、ちょっと前から見かけていて、何か知りたかったので、良かったです。乗っていた人は、やっぱり近所の原住民でした。

で、そんなに遊んでいるんなら、駅と海の間(1kmぐらいある)を往復すれば人も多いのでそこそこの宣伝になるような気もするけど、まあ、いろいろやっちゃいけない理由があるのかも知れません。一人100円とかなら乗りたいかも。

まとめると、僕はアメリカに行ったときにも消防車に乗せてもらったりしたので、変なものに乗せてもらえる運命なのかもしれません。ちなみに、日本でも子供と消防署にいけば、時間が空いていれば救急車や消防車に乗せてもらえます。少なくとも僕の近所と江ノ島のあたりはそうでした。

 



2010年8月20日

データストアの方法とか・・・

アリエルの最初の製品はP2P型のグループウェアで、データはXMLとしてファイルシステム上の保存しているとはどこかで書いたような気がします。今の主力製品はP2PではなくてWebアプリケーションとしてグループウェアを作っています。Lotusのころから考えると、グループウェアが好きなのか、一番知っているからたまたまそうなったのか・・・。

そのグループウェアですがデータストアにはOracle様のRDBMSを使っています。言語はJavaで作っているので、結局、いろいろなものがOracleに集約されていくように感じます。XMLではなく、RDBMSを選択したのはパフォーマンス上の理由です。開発が始まった4年か5年前にもオブジェクトデータベースとか、変なデータベースがありました。もっと前のあり得るができる前後の2000年ぐらいには、これからはXMLだと言われていましたが、RDBMSは未だに主流です。RDBMSをXMLにマッピングするのは無理があるとか、蔑まれたりもして、オジェクとデータベースだ、と聞いたこともありますが、やっぱりまだ、RDBMSです。NoSQLでキーバリューストアだと見せかけて、MySQLもPostgresも面白い動きを見せていて、やっぱり目が離せません。この後にインデクシングの話をしようかと思ったのですが、それはまた、別の機会に。

さて、RDBMSを選択しましたが、当初のもくろみから、テーブル構造はころころかわるものを想定していました。 これは、Notes/Dominoを強く意識していたためです。Notesほどエンドユーザコンピューティングじゃなくてもいいのですが、もっと簡単にユーザがアプリケーションを開発できる環境を提供したく、そのためにはテーブル構造が固いのは不都合だったからです。

で、最初の実装では、NoSQLのキーバリューストアのように、キーバリューを保持するテーブルにすべてを保存して、あとはそれらを適当にインデクシングできるようにしてパフォーマンスを稼ごうという戦略でした。この戦略はある程度まではうまくいきましたが、ある一定量のデータを超えると次第に遅くなっていきました。まあ、そりゃそうですね。

で、その次に考えたのが、テーブルをもう少し分割して、データタイプに応じて分割したりするものです。こちらは最初の方法の延長線上なので比較的簡単なのですが、本質的に同じ問題をはらんでいます。以前、とあるシステムで月ごとにテーブルが分割されていてとても扱いにくかったので、それはさけたかったのです。(月ごとにテーブルを分割するのが適切なアプリケーションではなかったのに)

で、その次のものが今の形です。それは、テーブルを動的にどんどん変更してきます。動いている最中にテーブルを変えるので、とってもいやんです。しかも、クラスタリングしてアプリケーションサーバーが複数あると、動いているのが不思議なくらいです。いや、動くように作っているんですがね。で、カラムが増える分には割と問題ないのですが、減るときは、こっちもあんまり問題ないですね。でも、データタイプが変わるときは、うーん、がんばっています。 

で、データの保存の仕方は変わるんですが、その上で動くアプリケーションはほとんど変更を加えていません。アプリケーションはデータストアを全く意識する必要がないのはすてきなことです。データベースをよくわからないエンジニアも、ごりごり何かを書いています。これがフレームワークがすごいところなんですね。

ということで、次はまた、思いついたことを適当に書いています。 

 

 



2010年8月19日

師匠は誰だ?

柴田さんに「アプレンティスシップ・パターン
」をもらって読んでから、社内では師匠と弟子という関係がちょっとだけ意識されています。「プログラマーは一子相伝で技を伝承するので、簡単には弟子をとらない」とよく分からないことを言う人もいますが、アリエルの場合、新入社員をとらないので本当のところは不明です。ちなみに、新入社員はとらないけど、社会人経験がなくてもプログラマーならいつでもとるので、応募してください。

さて、弟子候補がそもそもいないので、かつての自分たちに当てはめてみることになります。CTOに「師匠はいましたか?」と聞くと、「う〜ん、いなかったです」と。社内のめぼしい人に聞いてみましたが、100%の人がいないと答えました。「大谷さんは?」と聞かれたので、とりあえず、「僕の師匠はCTOです」 と笑顔で答えたら、真顔で「おおたにさんは弟子とは認めません。そもそも何も教えていないし」と一瞬で破門、と言うか、弟子入りを拒否されました。

まあ、師匠はいなくても仲間というか、ライバルというか、そんな関係の人がいたという人は、当社調査で約78%いました。誰かに教えてもらうと言うより、誰かと一緒にと言う方が多いのかも知れません。僕も後者でした。

それじゃ、師匠と弟子っていらないんじゃないか?ということになりそうですが、まずは、アリエルは特殊な環境なので、僕の知っているもう一つの特殊な環境のLotusはどうだったかというと、友達の何人かは、先輩に当たる人に細かく教えてもらっていました。遠くから見ていただけなので真実は不明ですが、僕から見るとそのようにうつりました。放置プレーされていた僕からすると、うらやましかったような、うざいような、どうでもいいような、微妙な心境でした。まあ、80%の時間を遊んでいたので、懇切丁寧に教えられると遊べなくなるので、やっぱりいやですね。後に別の人から聞いたところ、その友達は「最初は使えなかったけど、何年かしたら使えるようになった」らしいです。さらにその後どうなかったかは、プログラマじゃなくなりました。それは日本の環境のせいなのか、本人が飽きたからなのか、なんらかの壁のせいなのかは不明です。アプレンティスシップ・パターンにもドロップアウトというパターンはあるので、これが悪いことではないのでしょう。

まあ、師匠はいない人は多いですが、その場合は、仲間のような人の存在が多いのかも知れません。えっ?うちのCTO?彼は孤独を愛する人です。何度頼んでも、僕を弟子にとってくれません。 



2010年8月11日

KeyValueストアとか・・・

あまり、会社の製品について書いたりしていないので、ちょっとだけ。もともとの発端は、「最近、NoSQLとかKey Value Storeとか流行っているよね。でも、それらがどう分散されているかと言うことを除けば、アリエルってkey value store好きだよね。もしくは大谷さんが好きなのか・・・」と言うCTOのお言葉です。多分、僕じゃなくってアリエルです。

で、時はさかのぼること10年前。アリエルはP2Pのグループウェアを作っていました。その時の文書(スケジュールとか掲示板の文書とか)は、それぞれにキーが割り振られていて、XMLのドキュメントとして扱っていました。大昔に、Unix Magazineにそのへんの仕組みを書いたことがありますが、多分、忘れ去られています。この場合の文書が、Valueに相当します。まあ、アリエルのシステムが特異というわけじゃなく、割と一般的にだと信じています。

さて、アリエルの最初の製品はP2Pのシステムです。これは、Key Value Storeがインターネットに分散されていると言うことです。で、最初にアリエルがつまずいたところが、一覧で見たときにパフォーマンスが追いつかないとことです。 ちょっと前のKey Valueの動向を見ていていると、昔の記憶がよみがえるようで感慨深いです。

で、文書という概念、もしくはValueという概念は今の製品にも受け継がれているのですが、これはもっと古いです。ZopeのZODBというオブジェクトデータベース由来だという噂もありますが、それは嘘です。基本的にはLotus Notes/Domino由来です。新入社員として入ったせいで、大きな呪縛があるのかも知れません。Notesにはとても影響されています。

Key Value Storeは最近出てきた凄いものという受けとめ方もありますが、確かにCassandraとかVoltDBとか面白いんですが、Key Value Store自体はdbmとか大昔からある仕組みです。それをどう使うかは新しいかも知れません。新しいものを追い求めるのも大事ですが、ちょっと立ち止まるのもまた面白いかも。 

とか、そんな昔話はどうでもよくって、今作っている製品の仕組みを書こうと思っていたんだけど、それはまた、今度。 



2010年8月10日

画面が広いのはいいことだ

家には、コンピュータが2台ありました。一台は嫁のネットブックです。もう一台がMac Miniで3年ちょっと前のものです。今までは大体3年ごとに買い換えていました。なので、今年はちょうど買い換え時期にあたります。ちなみに、ノートPCも3年ごとに買い換えています。自宅サーバがあったときは、サーバも3年ごとに買いかえ(もしくはどこかからもらってきた)ていたので、結局毎年一台づつ買い換えるということをやっていました。買い換えるときも、大体が壊れるとかです。いや、本当に壊れるのです。サーバはメモリがすぐにやばくなったり、ハードディスクに不良セクタができたり・・・。ノートは、液晶が壊れたり、熱暴走し始めたり・・・。デスクトップは、うーん、愛情を注がなくなってすねちゃったり・・・。

で、我が家に27インチiMacがやってきちゃいました。嫁の許可がおりたので、BicCameraで購入。「お届けしますか?」の質問に「お持ち帰りします」キリッ。でも、こやつはばかでかい。キャリアに載っけたときに、お持ち帰りにしたことを少し公開しました。で、電車にのって、駅からはとぼとぼ歩いて我が家にやってきました。なぜ、車で買いに行かなかったのか、すごく後悔。途中、おばあさんに「でっかいテレビですね」と言われます。これ、テレビじゃないし、テレビだとしたらそんなにでかくないし・・・。

で、机にセットすると、ばかでかい。子供達もでかすぎて興味をしめさない。で、データを移行しつつ、いろいろ作業や設定をします。割といい感じ。と言うか、最初は広い画面に戸惑いつつも、なれるとやっぱり広い画面はいいです。作業が快適です。ノートPCじゃ、こうは行きません。でも、この広さになれるともう、引き返せないんだろうな・・・。







2010年8月8日

エディタは・・・

ちょっと前の会社での会話。

A: 「エディタはEmacs使っているんですか?」
僕: 「もう、Emacsは使っていません。Aquamacsを使っています!」キリッ。
A:「えっ? それはMeadowよりEmacsです」
僕: 「えっ!?だって、だって、だって」

2010年8月7日

「もしも高校野球の・・・」を読んだ

 「もしも高校野球の女子マネージャがドラッカーの『マネージメント』を読んだら」を読みました。タイトルなが!読んだ理由は

1. 流行っているらしいから

2. 夏休みの読書週間だったから

の2点です。 夏休みは先週で、旅行から帰ってきてから読みました。この本もホリエモンの「拝金」のように読むつもりはなかったんですが、ちょっと時間が空いたのと、テレビでダイアモンドの本では久しぶり(始めて?)の大ヒットらしいと言っていたので読んでみました。

それ以外にも、iPadで読んだのですが、電子書籍ということもありますが、気軽にiTunes Storeで買えるのがいいです。 紙の本より安いし。でも、このアプリは悲しいことに横書きには対応していません。電子書籍であればすべて横書きで読めると信じ切っていたのでショックでした。

今までにドラッカーを読んだことはありませんでした。ドラッカーっておっさんが読むものでしょ?もしくはビジネスマンと言うか、経営者が読むもんでしょ?僕みたいな若者(?)やエンジニアが読むもんじゃないよね。と思っていました。なので、あえて読んではいけないものでした。でも、この本を読んでみて、それは誤解であることが分かりました。僕のような若者どころか、女子高生が読むべきものだったのです。 

小説としては話が強引すぎるように思いますが、ドラッカーに興味をもって、本の中にでてきたマネジメント - 基本と原則 [エッセンシャル版]
を読んでみたくなりました。

それから、会社の中に新たにマネージャの階層が増えて、チームリーダー的な人たちが増えました。彼らに読ませて、もしくは勉強会をさせて、どう変わるか見てみるのも面白いと思いました。 

 この本が電子書籍になったのなら、一緒に「マネージメント」も電子書籍にすれば、もっと売り上げが上がると思うんだけどな。少なくとも僕は欲しいと思ったし、iTunes Storeで手軽にかえるんだったら買っちゃっていると思う。まあ、Amazonで買ってもいいんだけど・・・。

 

 
;



2010年8月5日

ホリエモンの「拝金」を読んだ

最近、ホリエモンの「拝金」を読みました。文章がつたないな〜、と思うところがあったり、そこはもう少し詳しく知りたいな〜、と思ったりするところもありますが、すんなりと読めて楽しめました。

紙の本じゃなくって、iPhoneで読んだのですが、意外と読みやすかったです。まず、最初は僕はこの本を買うつもりは全くありませんでした。でも、ホリエモンが小説を出すらしい、最初の方はブログに載っていてタダで読める、と知ってとりあえずブログに載っているタダで読める分だけを読みました。多分、これが間違いの始まりです。途中まででもちゃんと読んじゃうと、多少つまらなくても最後まで読んでみたくなります。でも、この本はつまらないと言うよりは面白い方です。少なくとも僕は好きです。なので、気がついたら買っていました。

買うときなんですが、iPhoneで本を読んだことなかったので、読みにくいんじゃないかな?ととても不安でした。iPhoneのアプリだと1000円ぐらいするし・・・。iPadにちゃんと対応していれば迷わなかったのですが・・・。でも、紙の本を買っても読んだらゴミになるのでiPhoneでがんばって読むことにしました。 

iPhoneで読んでみると、意外と読みやすいです。紙の本だとどれくらいの分量になるか知りませんが、全然ありです。これは新鮮な驚きでした。それから、文字の大きさを変えられるのはもちろん、ちゃんと横書きで読めるのがいいです。うん、やっぱり縦書きより横書きの方がいいです。キリッ。

で、ホリエモンの術中にはまってるな〜、と思いつつ、ある程度はタダで読ませてある程度納得させてから、全体のコンテンツを有料で読むというのはいいモデルだと思います。紙の本でも、書店である程度立ち読みして吟味できるかも知れませんが、自分の部屋なり落ち着いた場所や好きな時間に試せるのはいいです。この本に限らず、もっと多くの本がそうなればいな。数学ガールとかも、そういうモデルですね。 

でわでわ、夏は読書感想文の季節なので、良い読書を・・・。




2010年8月3日

JALは変わった?のか?

先週とった夏休みにJALにのって海外に出かけました。このとき、最初に驚いたのは、CAの人たちです。ちょっと前までは日本人だらけだったのが、僕が乗った飛行機は半分ぐらいが中国の人でした。日本語もたどたどしいのですが、若い人が多かったです。コスト削減の一環なんでしょうか?「あのJALが・・・」と、ちょっと驚きです。サービスの質とかは僕はよく分かりません。いい意味で、あんまり昔と変わっていないような気がします。 

でも、でも、でも。現地に向かうときに黄色い紙(なんて言う名前か忘れた)を書いていたときのことです。表を書き終えて、裏側を半分ぐらい書いたときのことです。突然、ちょっと年配のCAの人に何も言われずいきなりその紙をとられました。「えっ?」って思っていると、「白い紙と黄色い紙は切り離さないでください」 と。「いや、それ裏だから」というと、しばらく表と裏を確認して「失礼しました」と去っていきました。例え、切り離しちゃいけない紙を切り離して書いていたとしても、いきなり何も告げずに奪い取っちゃいけません。と言うか、年齢からするとCAのボスだと思うんだけど、こんなんで大丈夫か?まだ若そうなCAだったら納得できるんですが、ボスキャラがこんな接客でいいのか?まあ、こんな経験は初めてのことでビックリしましたが、CAが礼儀正しくても英語しか喋らないよりはましなので、いいです。 

そして、しばらくして、機内に「裏面もあるからそちらも書くように」とアナウンスが流れました。うーん、こんなぐらい確認しとけよ、と思いつつ、他の国に行くときも、裏面があるとこもそこそこあるよな〜、と思ったりして。

でも、僕は臆病者なので、そのあと文句を言うこともなく寝てしまいました。真夜中の出来事で、ホテルに着くのが3時ぐらいなので体力を温存しないといけないし・・・。