新居に引っ越して、もうすぐで1ヶ月。外構も昨日終わり、ほぼ完成。今まで実家に置いてあったサーバも新居に持ってきたため、自宅でのネットワーク環境もそのサーバが提供するサービスが基盤となった。アパートでは、ルータのDNS機能を使っていたが、今は自作サーバのbindが自宅内ネットワークのDNSを担当している。
しかし、何故か名前解決が遅い。5秒程度かかっている模様。完全に体感できる遅さで、だんだんとストレスが溜まってきた。試しにルータのDNSに切り替えてみると、瞬時に結果が得られる。これは自分で構築したbindが何かいけないことになってるはずだ。
ということでいろいろ検索して原因を探すと、ipv6が遅さの原因らしい。Solaris10付属のbindは、ipv6に対応したコンフィグレーションとなっていて、ipv4よりも前にipv6が優先されて参照され、毎度毎度ipv6のタイムアウトを待っている状態だった。しかも、bindのipv6対応の無効化は、再makeが必要とのこと。面倒なことになりそうだけど、ネット環境は精神衛生上大切なので、チャレンジすることにした。
最新のbindを落としてきて、–enable-ipv6=noを付けてconfigure&make。「そう言えばbind8からbind9へのバージョンアップだな」とか思いながら、コンパイル＆インストールは終了。設定ファイルはそのまま引き継ぐので手を加えず、svcのマニフェストファイルに手を入れて新しくインストールしたbindが使われるようにして、サービスを再起動。
期待通り、namedが起動しない。「unknown key ***」。設定ファイルいじってないのに。。。
どうもbind9では、named.confファイルからrndc.keyファイルをinclueしないといけなくなったらしい。そのための文をnamed.confファイルに追記して再度サービスを起動したら、ちゃんとnamedが常駐するようになった。
速い。これは速い。というか、これが普通。今までのipv6タイムアウト状態があり得なかった。
というわけで、新居でも快適なネット環境となりましたとさ。めでたしめでたし。
[参考にしたサイト]
http://cocorat.com/blog/entry/solaris10%E3%81%A7ipv6%E3%82%92%E7%84%A1%E5%8A%B9%E3%81%AB%E3%81%97%E3%81%9Fbind9%E3%82%92%E5%B0%8E%E5%85%A5%E3%81%99%E3%82%8B
http://sakanade.asablo.jp/blog/2008/05/29/3548480
- Posted:
- 09.27.2008
- Category:
- My PC environment
Solarisでのパッケージ管理にCSWを使っているが、ある日を境にupgradeに失敗してしまう状況が続いていた。
<CSWcommon> の削除が一時停止しました (対話型操作が必要です)。
システムは変更されていません。
Analysing special files…
Hmmm. Retrying with different archive offset…28 ブロック
現在の管理上では、<CSWcommon> パッケージに固有なインスタンスを作成する必要があります。ただし、同じシステム上で 1 度にサポートできる最大数のパッケージインスがすでに存在しています。
システムは変更されていません。
ERROR: could not add CSWcommon.
この現象で、せっかくmercurialを使ってみようと思っていたのに、出鼻をくじかれることになった。あれこれ調べた結果、/var/sadm/install/admin/defaultファイルのinstance項目を、uniqueからoverwriteに変更することで問題を回避することに成功。どうやらuniqueだと「上書きインストール厳禁」という設定らしく、これをoverwriteにして「上書きインストール大歓迎」としてあげればオッケーになった。
- Posted:
- 09.14.2008
- Category:
- My PC environment
OpenSocialコンテナとして広く使われているApache Shindigには、残念ながらSNSとしての機能は搭載されていない（当たり前だけど）。そのため、ローカル環境でOpenSocialアプリケーションを開発するには、実はShindigだけだと、どうしても役力不足になる。Shindigは会員情報や友達情報、アクティビティなどをXMLファイルにて記述し利用することができるようになっているが、OpenSocialアプリケーションから作成を要求したアクティビティなどは、メモリ上でしか保持されないため、実際に処理が完了したかどうかを確認することさえ困難を極める。デバッガ環境を作らないといけないので。
その不便さを解消するために、予めShindigに対応した簡易SNSがある。それが「Partuza!」である。詳しくは、以下のエントリを参照されたし。
「オープンソースのShindig対応SNS – Partuza!」 – Tender Surrender
「Partuza!」 – Google Code
さて、このPartuza!だが、生まれたてホヤホヤのプロジェクトであり、超基本的な機能は備わっているんだけど、かゆいところまで実装されているかというと、まだまだこれからという感じのレベルである。もちろん、Partuza!があるのとないのとでは雲泥の差であることは確か。Partuza!とSindigの最新コードでOpenSocial v0.8のアプリの動作確認をローカルで行うことができるのは、めちゃくちゃ嬉しい。けれど、惜しい。
多くのSNSにおいて、なぜかアクティビティの作成に関する実装が酷く、まともに作成できるSNSは一つもない。TITLEとBODYのみの作成だけでも、NOT IMPLEMENTEDあるいはJavaScriptエラー。
そこでPartuza!の出番なのだが、アクティビティの作成に関して、マルチメディアコンテンツ（MediaItemオブジェクトで表現される）を含むアクティビティの作成には成功するのだが、実際に表示されるのはＴＩＴＬＥとBODYの文字列のみ。MediaItemオブジェクトにて指定した画像の表示は、残念ながら未実装。
ほとんどのSNSにて動作確認できず、頼みの綱であるPartuza!でもダメなのは、僕の気持ちが許さない。Partuza!のコードはPHPで書かれており、中身を見るとそう難しくなさそうなので、画像付きのアクティビティが表示できるようにコードを修正して、パッチを送ってみた。
「Issue 19 in partuza: The patch to display the activity with the image」 – Google Code
ドキドキだったけど、めでたくコミットされ、Contribution完了。もれなく自分のコードが入ることになるのは、ちょっとのコードでも、とても嬉しい。Partuza!は、今後OpenSocialアプリケーションの開発効率をあげるためのキープロダクトになると思うので、今後も機能追加をしてみたい。
- Posted:
- 09.12.2008
- Category:
- OpenSocial
Seasar Foundation主催のイベント「Seasar Conference 2008 Autumn」が、本日開催された。そこで「OpenSocialに見るGoogleのオープン戦略」というセッションで話をしてきた。
OpenSocialに関するほとんどの行動は、Googleに閉じた話ではなく、コミュニティを中心としたオープンな場で行われている。これを通じて、他のプロダクトも含め、一般の開発者とGoogleとの距離の縮め方がどのように行われているのか、について説明を試みてみた。
思ってたよりも多くの人が聞きに来てくれた。ありがとうございます！そして、発表の場を作って頂いたSeasar Foundation関係者の方々には、感謝の意を伝えたい。
さて、うまく説明できたかどうか自信がないけど、OpenSocial-Japanやその他のAPIに関するコミュニティに、多くの方が積極的に参加してもらえると、とても嬉しい。そして、もっとうまく何かを伝えられる技術不足を何とかしたいな、と再度思ったイベントだった。
- Posted:
- 09.06.2008
- Category:
- OpenSocial
無事に完成を迎えて今週から実際に住み始めている我が家において、設計の時点で僕がどうしても付けたかったものがあった。それが「ニッチ」スペース。壁を一部くり抜いて、ちょっとしたものを飾れるようにするスペースだ。我が家のニッチスペースは、玄関を外から入ったときの正面に見える壁と、階段を2Fに登り切ったときの正面の壁の2カ所に作ってある。
まず、玄関正面のニッチは、透明なリンゴを3つおいてシンプルな雰囲気を出してみた。
下からライトアップすると、以下のような感じになる。
次に階段正面のニッチスペースだが、ここは最近の思い出の品をいくつか飾ってみた。
左から、
- Mash up Award 3rdの副賞でもらったDukeシューズ。
- Googleのロゴの背景の手前に、クリスタルDuke。
- Mash up Award 3rdの賞状。
- Sunからもらったあぶら取り紙と、Google Developer Dayやデベロッパー交流会の時の参加証。
と並べてある。このニッチスペースも、ライトアップが可能だ。
これからもっともっといろいろなことをやって、このスペースに並べていきたい。僕のちょっとしたモチベーションだ。
- Posted:
- 09.04.2008
- Category:
- Etc
OpenSocial JavaScript APIを実際に使って動作確認を最近数多くこなしているが、その際に気がついたことがある。
「XMLって、未だにversion=”1.0″としか書いたことがない」
皆さんは、version=”1.1″ と書いたことがありますか？「version=”2.0″にいつなるんだろう？」とか考えたことはありませんか？
これ、実はすごいことで、最初のXML 1.0の勧告がW3Cからされたのは、今をさかのぼること何と10年前の1998年2月10日。途中でXML 1.1の勧告やXML 2.0に関する議論が行われたこともあったけど、10年という長い間、Version 1.0がこのネット時代を支えてきたことになる。
ではXML 1.0の歴史は10年間なのか？というと、実際には半分嘘。XML登場以前の約12年間、その前身となったSGMLが徐々に成熟してきた成果がそのままXMLに反映されているために、SGMLも含めたXMLの歴史は、すでに20年以上も経過していることになる。つまり、「XMLって10年も同じバージョンなのか、すごいなー」という印象ではなく、実際には「XMLって20年以上も同じバージョンなのか、すごいなー」という印象を持つべきかもしれない。ちょっと乱暴だけど。ちなみに、SGMLの前身にGMLという仕様もあり、GMLは1960年代から1970年代にかけてIBMの社内文書で使われていた。文字情報のマークアップという発想は、僕が生まれた1975年以前からあったということになる。
昔話はさておき、XML 1.0が10年もの間使われ続けてきた歴史は、個人的には「最小限の仕様策定という方向性が正しかった証明」と言えるのではないかと思う。つまり、SGMLやDSSSLなどの歴史を踏まえて、重量級な仕様ではなく最小セットの仕様とすることで、XML 1.0の仕様を崩すことなく新しく外部の仕様で補完してあげることで未知の仕様追加に対応する、といった今日では当たり前な考え方を最初に実証した例ではないかと考えられる。
YAMLなどのアンチXML仕様が一般的な大多数になっているかというと、そうはなっていない。やっぱりXMLはVersion 1.0のまま、今日もその利用は拡大し続けている。version=”1.0″と書くたびに「XMLの仕様って、やっぱりすごいんだなぁ」と思う今日この頃である。
- Posted:
- 09.02.2008
- Category:
- Etc
