いろいろな諸事情により、私は個人的に「IT技術者の健康」というものにも非常に興味があります。自分が経験したことを考えると、Dominoよりこちらのほうが社会的責任があるのではないかと思っているくらいです。（もちろん、Dominoに関してもこれまで通りマイペースで何か書くつもりです。）
本当はここでそのような話をしようかと思ったのですが、ブログを分けたほうがいいというアドバイスを頂いたので、別途作ってみました。こちらで健康の話をするのは最初で最後ですが、一応リンクを貼っておきます。
IT技術者の健康徒然
専門家ではありませんが、何らか社会の役に立てれば嬉しいです。
2006/08/27
数学は役に立たないか
夏休みに、藤原先生の「世にも美しい数学入門」という本を読みました。
内容は、博士の愛した数式の小川さんとの対談形式で、一般人が興味をひきやすいような読みやすいものでよかったです。
で、中で気になったのは、「数学は人類の役に立たない」というお話。
そういえば、自分も高校生の頃、数学の中でどうしても理解出来ない部分があって、自分の当時の家庭教師の先生に「XXXなんてなかったらよかったんですよ」と言ってみたら、「でもXXXがなかったら、今の生活の中でなかったものや出来ないことがあったかもよ」とあっさり言われたのを思い出しました。
さらにいろいろ考えてみると、先日読んだ「暗号技術入門」の本で解説されていたPKIの解説では、思いっきり現代数学が関係していたな・・・、と。昔、離散数学を勉強したときは、こんなもの何の役に立つかと思ったけれど、こういった暗号数学がなければ、インターネットでお買い物も出来ないのだなあと、ふと思いました。
きっと、フェルマーやポアンカレの証明なんかは、今のところ直接現代社会の役に立たないのかもしれないですが、ふと、人が言うほど不要なわけでもないよな・・・と思い返してみました。
Notes/Domino技術者として、この部分に興味があったら、やはり「ネットワークセキュリティ」を読むべきなのでしょうね。なんといっても、Notesのセキュリティを設計した、当時Irisのチャーリー・カウフマンが著者で、Notesのセキュリティについても短く触れてあります。
この本の存在は、かなり前に知って購入済みでもあるのですが、難しそうで開く気になれず眠ったままになっています。読まなければなあ。
内容は、博士の愛した数式の小川さんとの対談形式で、一般人が興味をひきやすいような読みやすいものでよかったです。
で、中で気になったのは、「数学は人類の役に立たない」というお話。
そういえば、自分も高校生の頃、数学の中でどうしても理解出来ない部分があって、自分の当時の家庭教師の先生に「XXXなんてなかったらよかったんですよ」と言ってみたら、「でもXXXがなかったら、今の生活の中でなかったものや出来ないことがあったかもよ」とあっさり言われたのを思い出しました。
さらにいろいろ考えてみると、先日読んだ「暗号技術入門」の本で解説されていたPKIの解説では、思いっきり現代数学が関係していたな・・・、と。昔、離散数学を勉強したときは、こんなもの何の役に立つかと思ったけれど、こういった暗号数学がなければ、インターネットでお買い物も出来ないのだなあと、ふと思いました。
きっと、フェルマーやポアンカレの証明なんかは、今のところ直接現代社会の役に立たないのかもしれないですが、ふと、人が言うほど不要なわけでもないよな・・・と思い返してみました。
Notes/Domino技術者として、この部分に興味があったら、やはり「ネットワークセキュリティ」を読むべきなのでしょうね。なんといっても、Notesのセキュリティを設計した、当時Irisのチャーリー・カウフマンが著者で、Notesのセキュリティについても短く触れてあります。
この本の存在は、かなり前に知って購入済みでもあるのですが、難しそうで開く気になれず眠ったままになっています。読まなければなあ。
2006/08/04
技術者と英語について
技術者に必要なもの
上記記事を読んだり、開設したばかりの「ShortCuts」を試してみたことにインスパイアされたので、私が思っている英語についてを書いてみます。
個人的に現在一番気になっているのは、「日本」と「英語を母国語としない国」の英語力の差です。
去年の冬、1ヶ月ほどボストンで仕事をする機会に恵まれました。日本人は私だけでしたが、身近には、数名のアメリカ人に加え、フランス、アイルランド、インド、ブラジル、ドイツから来た技術者たちがおり、非常に多国籍な環境でした。アメリカとアイルランド以外は、みな、non-native です。
当然かもしれませんが、母国語ではないにしろ、全員かなり流暢に英語を使っていました。発音は厳しいものがありましたが、「英語を使いこなす」という能力においては十分で、きっとTOEICを受けたら文法問題を間違えない限り、Listeningは満点、Readingも470点くらいはとるでしょう。彼らが選ばれた戦士なのかは不明ですが、私はTOEIC965なんて保有していませんから、諸外国との能力差は感じたわけです。
こういった個人的な問題は、私１人が努力すればよい話ですが、むしろ気になったのはこれからの話。
フランスやドイツの技術者と話をしてみたところ、彼らの国では、英語の技術文書を当たり前のように読むと言っていました。この文の主語は、「IBM社員」ではなく、あらゆる技術者（つまり、身近にいえば、パートナー様や、各企業の情報システム担当者様）なのだそうです。もちろん、日本にだって当たり前のように英語を読む方もたくさんいると思うのですが（特に、ブロガー近辺）、基本的に日本語で閉じている自分たちにとって、彼らとのこの時の会話はやや衝撃的でした。
そういえば、以前台湾に言ったときも、彼ら同士、会話は中国語でしたが、お客様への提出資料は英語で作成していました。メールも英語でした。中国語入力が大変だから英語を使う、と言っていたのを思い出します。（英語はそんなに上手でなかったですが）
もちろん、日本は、翻訳されたもの、独自に書かれたものを含め、英語以外の言語での技術情報は極めて豊富な国だと思います。それでも、英語の情報には数ではとてもかないません。（ニーズからいえば、作成者側の努力がまだまだ必要とされる）
そんな中、諸外国の技術者たちが、普通に英語で情報収集していたら、「日本語だけ読む日本人」とはどんどん差が出てしまうのではないか、という危惧をその時に思いました。
現在インターネットを通じて加速する国際的な情報交流ですが、日本は物理的な線でこそ海外とつながったものの、言語的な問題から島国になっていると思います。私個人も、島国ハンデが出ないように、いろいろと努力してるつもりではあるのですが、それでも情報の流通にギャップを感じることがあります。
ということで、1人でも多くの日本人が、日本語情報にあわせて英語情報も読むようになると、私としてはとても嬉しいです。私の所属や業界に関わらず、全てのジャンルにおいてそう思います。取り残される日本にはなって欲しくないです。フランスやドイツに負けたくないです。
最近では、むしろ、私たちは日本語＋英語の両方の情報が入手出来るのだから、英語さえきちんと出来れば、アメリカ人よりよほどよい環境だと思います。トラブルで困っているときなんか、英語情報は心強い味方になることも多いですよ。
上記記事を読んだり、開設したばかりの「ShortCuts」を試してみたことにインスパイアされたので、私が思っている英語についてを書いてみます。
個人的に現在一番気になっているのは、「日本」と「英語を母国語としない国」の英語力の差です。
去年の冬、1ヶ月ほどボストンで仕事をする機会に恵まれました。日本人は私だけでしたが、身近には、数名のアメリカ人に加え、フランス、アイルランド、インド、ブラジル、ドイツから来た技術者たちがおり、非常に多国籍な環境でした。アメリカとアイルランド以外は、みな、non-native です。
当然かもしれませんが、母国語ではないにしろ、全員かなり流暢に英語を使っていました。発音は厳しいものがありましたが、「英語を使いこなす」という能力においては十分で、きっとTOEICを受けたら文法問題を間違えない限り、Listeningは満点、Readingも470点くらいはとるでしょう。彼らが選ばれた戦士なのかは不明ですが、私はTOEIC965なんて保有していませんから、諸外国との能力差は感じたわけです。
こういった個人的な問題は、私１人が努力すればよい話ですが、むしろ気になったのはこれからの話。
フランスやドイツの技術者と話をしてみたところ、彼らの国では、英語の技術文書を当たり前のように読むと言っていました。この文の主語は、「IBM社員」ではなく、あらゆる技術者（つまり、身近にいえば、パートナー様や、各企業の情報システム担当者様）なのだそうです。もちろん、日本にだって当たり前のように英語を読む方もたくさんいると思うのですが（特に、ブロガー近辺）、基本的に日本語で閉じている自分たちにとって、彼らとのこの時の会話はやや衝撃的でした。
そういえば、以前台湾に言ったときも、彼ら同士、会話は中国語でしたが、お客様への提出資料は英語で作成していました。メールも英語でした。中国語入力が大変だから英語を使う、と言っていたのを思い出します。（英語はそんなに上手でなかったですが）
もちろん、日本は、翻訳されたもの、独自に書かれたものを含め、英語以外の言語での技術情報は極めて豊富な国だと思います。それでも、英語の情報には数ではとてもかないません。（ニーズからいえば、作成者側の努力がまだまだ必要とされる）
そんな中、諸外国の技術者たちが、普通に英語で情報収集していたら、「日本語だけ読む日本人」とはどんどん差が出てしまうのではないか、という危惧をその時に思いました。
現在インターネットを通じて加速する国際的な情報交流ですが、日本は物理的な線でこそ海外とつながったものの、言語的な問題から島国になっていると思います。私個人も、島国ハンデが出ないように、いろいろと努力してるつもりではあるのですが、それでも情報の流通にギャップを感じることがあります。
ということで、1人でも多くの日本人が、日本語情報にあわせて英語情報も読むようになると、私としてはとても嬉しいです。私の所属や業界に関わらず、全てのジャンルにおいてそう思います。取り残される日本にはなって欲しくないです。フランスやドイツに負けたくないです。
最近では、むしろ、私たちは日本語＋英語の両方の情報が入手出来るのだから、英語さえきちんと出来れば、アメリカ人よりよほどよい環境だと思います。トラブルで困っているときなんか、英語情報は心強い味方になることも多いですよ。
2006/07/28
サーバータスクのリスタート
主にテスト環境での話が多いと思いますが、試行錯誤しながら設定変更してはタスクを再起動することは結構あるものです。
HTTPタスクの再起動というのは、非常によく行うもので、「tell http restart」のコマンドに、これまでさんざんお世話になりました。
Routerタスクの再起動というのも、頻繁にやります。そこで、なんとなく「tell router restart」と打ち込むわけですが、これは間違い。Routerタスクで、設定変更を反映させたい場合は「tell router update config」を使う必要があります。
と、ここまではいいのですが、では他のタスクは・・・・という話になります。
実は、Domino 6以降、サーバーコンソールコマンドとして、以下のようなものが用意されました。
restart task <タスク名>
例えば、「restart task router」とか「restart task adminp」などというように使います。
実は、この技術文書を見て、私も今日知ったところです。
Can the Domino Router task be restarted with a 'Tell Router Restart' command?
余談：
restart server というコマンドは、世界中で相当打ち込まれていると思うのですが、ブラインドタッチ組にとっては、このコマンドはうちにくいですね。左手1本で、特に「r t」がうちにくいです。私は、res ser と打ってます。（「res s」でよいのですが、回文になってるのが気持ちよいので・・・）
HTTPタスクの再起動というのは、非常によく行うもので、「tell http restart」のコマンドに、これまでさんざんお世話になりました。
Routerタスクの再起動というのも、頻繁にやります。そこで、なんとなく「tell router restart」と打ち込むわけですが、これは間違い。Routerタスクで、設定変更を反映させたい場合は「tell router update config」を使う必要があります。
と、ここまではいいのですが、では他のタスクは・・・・という話になります。
実は、Domino 6以降、サーバーコンソールコマンドとして、以下のようなものが用意されました。
restart task <タスク名>
例えば、「restart task router」とか「restart task adminp」などというように使います。
実は、この技術文書を見て、私も今日知ったところです。
Can the Domino Router task be restarted with a 'Tell Router Restart' command?
余談：
restart server というコマンドは、世界中で相当打ち込まれていると思うのですが、ブラインドタッチ組にとっては、このコマンドはうちにくいですね。左手1本で、特に「r t」がうちにくいです。私は、res ser と打ってます。（「res s」でよいのですが、回文になってるのが気持ちよいので・・・）
2006/07/21
TeamStudio Analyzer
あるところで、TeamStudioの情報交換を行ったのですが、わりといろいろな使い方があるものだと感心しました。私は、AnalyzerとConfiguratorしか普段はインストールしておらず、日常的に使っているのはConfigurator だけです。
一応、情報交換会に出る都合上、少しは機能を理解しておこうかなとヘルプを読んでみましたが、なかなか面白かったです。Analyzerといえば、設計書の提出に使ったり、設計要素を抜き出して全文検索したり、専用のビューを作って、「何らか一覧」を作ったりする・・・というのがよく知られたところでしょうか。「監査機能」も面白いですね。デフォルトのフィルタだけでも、何らかの発見になるかもしれませんし、上手く使えば「お作法のよいアプリケーション」も増えていくと思います。
ヘルプを読むと、例えば「フィールドヘルプのない項目一覧」とか「名前が_1で終わるフィールド一覧（コピペすると出来る）」とか、ノウハウ的なことも書いてあったりします。
使いやすいツールだけに、ヘルプをじっくり・・・なんてあまりやらないのですが、たまには読んでみるのも面白いですね。
きっと、このツールには、フィルタやら、分析結果DBのカスタマイズなどまだまだベストプラクティスがいろいろとあるのではないかと思います。
一応、情報交換会に出る都合上、少しは機能を理解しておこうかなとヘルプを読んでみましたが、なかなか面白かったです。Analyzerといえば、設計書の提出に使ったり、設計要素を抜き出して全文検索したり、専用のビューを作って、「何らか一覧」を作ったりする・・・というのがよく知られたところでしょうか。「監査機能」も面白いですね。デフォルトのフィルタだけでも、何らかの発見になるかもしれませんし、上手く使えば「お作法のよいアプリケーション」も増えていくと思います。
ヘルプを読むと、例えば「フィールドヘルプのない項目一覧」とか「名前が_1で終わるフィールド一覧（コピペすると出来る）」とか、ノウハウ的なことも書いてあったりします。
使いやすいツールだけに、ヘルプをじっくり・・・なんてあまりやらないのですが、たまには読んでみるのも面白いですね。
きっと、このツールには、フィルタやら、分析結果DBのカスタマイズなどまだまだベストプラクティスがいろいろとあるのではないかと思います。
不在通知
不在通知エージェントは、Hannoverからエージェントではなくなり、コアコードになるそうです。
Instantaneous Out-of-Office in "Hannover"
Lotusphereの資料、きちんと目を通してなかったので、流れていってしまうところでしたが、Edのブログで気が付きました。 instant response って何なのでしょうね。
実は、私個人は、ユーザーとしてこの不在通知使っていません。。。深い理由はないのですが。
Instantaneous Out-of-Office in "Hannover"
Lotusphereの資料、きちんと目を通してなかったので、流れていってしまうところでしたが、Edのブログで気が付きました。 instant response って何なのでしょうね。
実は、私個人は、ユーザーとしてこの不在通知使っていません。。。深い理由はないのですが。
技術情報のRSSフィード提供
既にあちこちで宣伝されているのでご存知の方も多いでしょうが、サポートページのRSSフィード提供が開始されました。
サポート/技術情報
AutoDiscoveryはついていないので、上記ページのXMLリンクから直接登録して下さい。
これまでMyRSS使ってかろうじて読んでいたのですが、いちユーザーとして非常に嬉しいです。
私は、フィードジャンキーとまではいかないにしても、情報収集の9割以上をRSS/atomに頼っています。ブラウザのブックマークは、ほとんどすかすかで、RSS提供されていないページは基本的に読んでいません。
ちなみに、このフィードをFirefoxのライブブックマークで読むことは可能です。でも、私の個人的好みでは、それはあまりオススメ出来ない読み方です。
フィードには、「全部読みたい」タイプと、「全部読まなくてもよい」タイプと2種類ありますが、サポート情報の更新件数はたかがしれているし、Domino技術者なら全部目を通しておいてもよいのではないかと思います。
このように全部目を通したいタイプのフィードには、未既読管理機能を備えたRSSリーダーを使うのが私の好みです。こういうRSSリーダーとして、昔は、Bloglinesを使っていましたが、今は livedoor Reader を使っています（キーボードショートカットがショートカットが気持ちいいので）。 そのまた昔は、クライアントインストールタイプを使っていましたが、大量のフィードをさばくにはサーバー型のほうがよさそうだと思っていつからか変更しました。
一方、Firefoxのライブブックマークも使っていますが、こちらは極めて局所的に、自分のdel.icio.us の登録項目、はてなブックマークの人気エントリだけ使ってます。昔は、asahi.comのフィードや CNET Japan も入れてましたが、ニュース読まないのでやめました。特に、自分のソーシャルブックマークのRSSを設定しておくというのは、オススメです。 その他、「暇なときにぱらっと見てタイトルを確認する」という程度のフィードは、ライブブックマークでよいかなという気がしてますが、多く登録しすぎるとブラウザが重くなるので微妙ですね・・・。
サポート/技術情報
AutoDiscoveryはついていないので、上記ページのXMLリンクから直接登録して下さい。
これまでMyRSS使ってかろうじて読んでいたのですが、いちユーザーとして非常に嬉しいです。
私は、フィードジャンキーとまではいかないにしても、情報収集の9割以上をRSS/atomに頼っています。ブラウザのブックマークは、ほとんどすかすかで、RSS提供されていないページは基本的に読んでいません。
ちなみに、このフィードをFirefoxのライブブックマークで読むことは可能です。でも、私の個人的好みでは、それはあまりオススメ出来ない読み方です。
フィードには、「全部読みたい」タイプと、「全部読まなくてもよい」タイプと2種類ありますが、サポート情報の更新件数はたかがしれているし、Domino技術者なら全部目を通しておいてもよいのではないかと思います。
このように全部目を通したいタイプのフィードには、未既読管理機能を備えたRSSリーダーを使うのが私の好みです。こういうRSSリーダーとして、昔は、Bloglinesを使っていましたが、今は livedoor Reader を使っています（キーボードショートカットがショートカットが気持ちいいので）。 そのまた昔は、クライアントインストールタイプを使っていましたが、大量のフィードをさばくにはサーバー型のほうがよさそうだと思っていつからか変更しました。
一方、Firefoxのライブブックマークも使っていますが、こちらは極めて局所的に、自分のdel.icio.us の登録項目、はてなブックマークの人気エントリだけ使ってます。昔は、asahi.comのフィードや CNET Japan も入れてましたが、ニュース読まないのでやめました。特に、自分のソーシャルブックマークのRSSを設定しておくというのは、オススメです。 その他、「暇なときにぱらっと見てタイトルを確認する」という程度のフィードは、ライブブックマークでよいかなという気がしてますが、多く登録しすぎるとブラウザが重くなるので微妙ですね・・・。
2006/07/19
確率と網羅性
先日、知人のマイミク日記に書いてありました。
Dominoの技術者をしていると、「ドメイン設計」や「運用設計」「移行設計」などに関わることも多いかと思います。そのような時に、各ドメインの特徴を理解した上で、例外ケースを見逃すことなく、網羅性のあるデザインをするのは重要ですし、またこれは非常に難しくもあります。実はこれらは、上記のような確率の問題を正しく考えることとわりと近い能力が要求されるのではないかと思いました。（二項定理のような数式変形はどうでもよいのですが、漏れなく場合分けして数えるというところ。数学証明の場合分けも似たようなものだと思います）
私の脳も、長らくご無沙汰でさび付いたものですが、たまにはこのようなことをするのもよいかもしれないと思った次第です。
よく、ベストのデザイン方法を探すときに、いくつかの候補があがった上で、「他によい方法はないですかね」という質問ももらいますが、これも上手く網羅性の観点から考えると、「他にはない」ということが証明出来ることもあります。
こういう質問のとき、私はわりと、「Xか、Xでないか」の2種類に分割して、深く考えていくことが多いです。例えば、「ドメインを１つにする方法と、分割する方法と2種類が考えられますよね。１つにすると・・・」など。この時点まででは、全ての解決方法は必ず網羅されているといえます。で、さらにそれぞれのケースを掘り下げていっては「×マーク」をつけています。
きっと、これだけビジネス本が普及している世の中ですので、世の中には確立されたよいメソッドがあると思うのですが、私の整理も含め、ふとDomino技術者として思ったことを書いてみました。
n人でじゃんけんして「あいこ」になる確率っていくつだろう・・・何を思い立ったか、久しぶりにこのような確率の問題を解いてみたくなり、紙と鉛筆で計算してみました。高校数学からは久しく遠ざかっていたため、二項定理をすっかり忘れており、コンビネーションのΣまでで止まってしまったのですが、それでも久しぶりに普段使わない部分の脳の末端を運動したかんじで気持ちよかったです。この問題では、「あいこになる全ケースをどうやって数えるか」がポイントですね。
Dominoの技術者をしていると、「ドメイン設計」や「運用設計」「移行設計」などに関わることも多いかと思います。そのような時に、各ドメインの特徴を理解した上で、例外ケースを見逃すことなく、網羅性のあるデザインをするのは重要ですし、またこれは非常に難しくもあります。実はこれらは、上記のような確率の問題を正しく考えることとわりと近い能力が要求されるのではないかと思いました。（二項定理のような数式変形はどうでもよいのですが、漏れなく場合分けして数えるというところ。数学証明の場合分けも似たようなものだと思います）
私の脳も、長らくご無沙汰でさび付いたものですが、たまにはこのようなことをするのもよいかもしれないと思った次第です。
よく、ベストのデザイン方法を探すときに、いくつかの候補があがった上で、「他によい方法はないですかね」という質問ももらいますが、これも上手く網羅性の観点から考えると、「他にはない」ということが証明出来ることもあります。
こういう質問のとき、私はわりと、「Xか、Xでないか」の2種類に分割して、深く考えていくことが多いです。例えば、「ドメインを１つにする方法と、分割する方法と2種類が考えられますよね。１つにすると・・・」など。この時点まででは、全ての解決方法は必ず網羅されているといえます。で、さらにそれぞれのケースを掘り下げていっては「×マーク」をつけています。
きっと、これだけビジネス本が普及している世の中ですので、世の中には確立されたよいメソッドがあると思うのですが、私の整理も含め、ふとDomino技術者として思ったことを書いてみました。
2006/07/18
全文検索結果のハイライトウォーキング
実は私も今日知ったコネタです。多分、私はユーザーとしては Ctrl-F を使うと思うのですが、価値観はそれぞれ・・・ということで、ご紹介します。
How to navigate through full-text search highlights
Notesクライアントで全文検索を行ったとき、文書を開くとキーワードがハイライトされています。実はこの検索結果のハイライトのフォーカスを、キーボードショートカットで進むことができます。
次のキーワード： Ctrl＋"+"
前のキーワード： Ctrl＋"-"
現在のフォーカスは「ピンク色」になります。
例えば、１つの文書が非常に長く、なおかつキーワードのヒットが文書に少なければ、ひょっとしたら有効かもしれませんが、どうも自分のユーザー的な好みでは、いつもの癖で Ctrl-F しちゃいそうです。
How to navigate through full-text search highlights
Notesクライアントで全文検索を行ったとき、文書を開くとキーワードがハイライトされています。実はこの検索結果のハイライトのフォーカスを、キーボードショートカットで進むことができます。
次のキーワード： Ctrl＋"+"
前のキーワード： Ctrl＋"-"
現在のフォーカスは「ピンク色」になります。
例えば、１つの文書が非常に長く、なおかつキーワードのヒットが文書に少なければ、ひょっとしたら有効かもしれませんが、どうも自分のユーザー的な好みでは、いつもの癖で Ctrl-F しちゃいそうです。
2006/07/17
あるDomino技術者の通勤時間
ここでは決してLifehackの話がしたいのではなく、あくまで1人のDomino技術者が通勤時間で何をしているか、という紹介話です。
私は、もともとハートが小さいタイプなので、他の人が通勤時間をどのように活用しているかには興味があります。特に、自分が尊敬する技術者には、しょっちゅうこの質問をしては、参考にしています。
結局のところ、自分はたいしたことをしていないのですが、何かの参考やきっかけになるかもしれないので書いておきます。
昔は、職場がラッシュと逆方向だったので、Thinkpadを広げて、大量に複製したDBを処理していました。電車の中で仕事をするという概念は、私の当時の師匠の影響もあると思います。その方は、朝は喫茶店で朝食を取りながら仕事をされていましたし、しょっちゅう通勤電車（JR）のグリーン券を買って、仕事をされていました（はかどるそうです）。
そんな刺激を受けているはずの私ですが、今はだいたい次のどれかです
英語はいくらやっても身につきませんが、電車の中で「ヒヤリングマラソン」と「週刊ST」を繰り返しやることで、留学もせずにTOEICで高スコアを出しているDomino技術者が身近におり、その影響でSTを購読しています。難易度も頻度も、自分には最適で、今にも挫折しそうですがそこそこ読んでいます。あと「頭の中だけで英語日記」も時々やりますが、効果のほどはわかりません。
「寝る」というのも、時間の有効活用方法の１つかと思っています。極力ぽーっとした無意味な時間を作らないようにしています。
現代社会で生きていくのはなかなか大変ですね・・・。
私は、もともとハートが小さいタイプなので、他の人が通勤時間をどのように活用しているかには興味があります。特に、自分が尊敬する技術者には、しょっちゅうこの質問をしては、参考にしています。
結局のところ、自分はたいしたことをしていないのですが、何かの参考やきっかけになるかもしれないので書いておきます。
昔は、職場がラッシュと逆方向だったので、Thinkpadを広げて、大量に複製したDBを処理していました。電車の中で仕事をするという概念は、私の当時の師匠の影響もあると思います。その方は、朝は喫茶店で朝食を取りながら仕事をされていましたし、しょっちゅう通勤電車（JR）のグリーン券を買って、仕事をされていました（はかどるそうです）。
そんな刺激を受けているはずの私ですが、今はだいたい次のどれかです
- 図書館から借りてきた技術書を読む
- 週刊STを読む
- 英語のリスニング
英語はいくらやっても身につきませんが、電車の中で「ヒヤリングマラソン」と「週刊ST」を繰り返しやることで、留学もせずにTOEICで高スコアを出しているDomino技術者が身近におり、その影響でSTを購読しています。難易度も頻度も、自分には最適で、今にも挫折しそうですがそこそこ読んでいます。あと「頭の中だけで英語日記」も時々やりますが、効果のほどはわかりません。
「寝る」というのも、時間の有効活用方法の１つかと思っています。極力ぽーっとした無意味な時間を作らないようにしています。
現代社会で生きていくのはなかなか大変ですね・・・。
2006/07/02
[雑談]通院して思う、トラブルシューティング
非Notes/Dominoネタで恐縮ですが、最近思ったことです。
このG/Wに、ちょっとした炎症をおこしてしまったため、病院に通っていました。すぐによくなった部分もあったのですが、なかなか治らない部分もあって、いくつか薬をかえていました。
前回診察していただいたときに、「うーん、もうXXな原因は治ってると思うので、あとはこの薬を使って下さい。もし治らなければ、次回詳しい検査をしましょう。」と担当医師から言われました。
実はこの薬がものすごくよく効いて、ようやく完治したみたいです。治ればもういい、と言われていたので、特にもう1回通院するつもりはありません。
そこで、ふと思いました。前回の診察は多少自信なさげなコメントだったわけですが、私は「薬が効いて治りました」と、たとえ行かなくても、電話するくらいしたほうがよいのかどうか、ということです。普通の患者は、おそらく、よほどのことがない限りは「治りました」という電話はかけないと思います。でも、医者の立場からすると、どうなんでしょう・・・。ひょっとしたら「治った」という結果を受けることで、担当医師の経験が増え、結果的に社会のためになるかもしれません。
私は、仕事上、突発的にいろいろなご相談を受けることがあるため、「問題事例」はわりと耳にすることもあり、何らか自分が思う解決案や原因となりそうなことをお伝えしています。ところが、「解決しました」という連絡を受ける回数はわりと少ないので、最終的に自分の考えが正しいかの経験が蓄積していかないというジレンマは多少あります。
仕事をやっている上で自分自身が困ることは、プライベートを含め逆の立場では極力行わないようにしたい、ということは日頃思っているのですが、ひょっとして今回の完治問題はその1ケースなのかもしれないと思いました。
そうは言っても、まだ電話してないのですが、家族に医者がいるので、ちょっと医者心理についてきいてみたいところです。
このG/Wに、ちょっとした炎症をおこしてしまったため、病院に通っていました。すぐによくなった部分もあったのですが、なかなか治らない部分もあって、いくつか薬をかえていました。
前回診察していただいたときに、「うーん、もうXXな原因は治ってると思うので、あとはこの薬を使って下さい。もし治らなければ、次回詳しい検査をしましょう。」と担当医師から言われました。
実はこの薬がものすごくよく効いて、ようやく完治したみたいです。治ればもういい、と言われていたので、特にもう1回通院するつもりはありません。
そこで、ふと思いました。前回の診察は多少自信なさげなコメントだったわけですが、私は「薬が効いて治りました」と、たとえ行かなくても、電話するくらいしたほうがよいのかどうか、ということです。普通の患者は、おそらく、よほどのことがない限りは「治りました」という電話はかけないと思います。でも、医者の立場からすると、どうなんでしょう・・・。ひょっとしたら「治った」という結果を受けることで、担当医師の経験が増え、結果的に社会のためになるかもしれません。
私は、仕事上、突発的にいろいろなご相談を受けることがあるため、「問題事例」はわりと耳にすることもあり、何らか自分が思う解決案や原因となりそうなことをお伝えしています。ところが、「解決しました」という連絡を受ける回数はわりと少ないので、最終的に自分の考えが正しいかの経験が蓄積していかないというジレンマは多少あります。
仕事をやっている上で自分自身が困ることは、プライベートを含め逆の立場では極力行わないようにしたい、ということは日頃思っているのですが、ひょっとして今回の完治問題はその1ケースなのかもしれないと思いました。
そうは言っても、まだ電話してないのですが、家族に医者がいるので、ちょっと医者心理についてきいてみたいところです。
2006/06/30
サーバーエージェントの検証
今日、うちのワカモノからもらった質問：
Q:「不在通知の検証をしたいのですが、今すぐ動かす方法ってないでしょうか？」
A:「うーん、 tell amgr run mail\test.nsf 'OutOfOffice' でどう？」
Q:「おおー、動きました」
Domino 6から、サーバーコンソールからサーバーエージェントを実行することが出来ます。
上記、mail\test.nsfはファイル名で、 OutOfOfficeはエージェント名です。
通常運用で使うのはちょっと変ですが、検証などで待ちきれないときなどは便利でしょうか・・・。
Q:「不在通知の検証をしたいのですが、今すぐ動かす方法ってないでしょうか？」
A:「うーん、 tell amgr run mail\test.nsf 'OutOfOffice' でどう？」
Q:「おおー、動きました」
Domino 6から、サーバーコンソールからサーバーエージェントを実行することが出来ます。
上記、mail\test.nsfはファイル名で、 OutOfOfficeはエージェント名です。
通常運用で使うのはちょっと変ですが、検証などで待ちきれないときなどは便利でしょうか・・・。
2006/06/28
整合性のチェックとは
こちらもTechnoteの斜め読みから。
What does the message 'Performing consistency check' mean?
「整合性のチェック」はFixupと同義です。サーバークラッシュ後の起動時などによく見かけますが、実はこれには３つの種類があります。
What does the message 'Performing consistency check' mean?
「整合性のチェック」はFixupと同義です。サーバークラッシュ後の起動時などによく見かけますが、実はこれには３つの種類があります。
- unknown state ： DBが正常に閉じられなかったとき（クラッシュの後や、開いている最中のOSコピーしたものなど）
- corrupt state ： どこかで破損が起きている場合
- Questionable integrity ： データベースのヘッダやインデックスがおかしいようなとき
NotesDBのサイズ
これもよく聞くお話です。
Understanding Notes database size
Notesのデータベースサイズを理解しましょう、というTechnoteより。
Technoteでは、以下の３つの観点でまとめています。
データベースの文書数は、DBプロパティから確認可能ですが、サーバーコンソールを使える環境なら、「show database DBファイル名」と入力すると、各設計要素の数や、削除スタブ数も表示されるし、ビューのインデックスのサイズも表示されます。
ビューインデックスについては、上記コンソールからも把握可能ですが、Domino管理クライアントからも実はビュー情報は確認可能です。（「ファイル」タブより、「データベース」→「ビューの管理」）
DBのサイズを最も小さくするためには、compact -d がよいのですが、これは全ビューインデックスが削除されるため、ある意味非常な危険なコマンドです。というのも、次回のユーザーアクセス時にビュー索引を構築する必要があるからです。ビューの構築というのは、非常に負荷の高い操作であり、１つや２つのビューならまだしも、多数のDBに対してビュー構築の動作が同時に行われると（例：サーバー上全てのDBにcompact -dをした場合）、その後のユーザーアクセスピークの間はサーバー負荷は大変なことになります。
ということで、上記Technoteのcompact -dに興味を持った場合も、いきなり週末に本番サーバーで実行・・・というのはお勧め出来ません。
ちなみに、compact -dは、-cスタイルの圧縮になります。
Understanding Notes database size
Notesのデータベースサイズを理解しましょう、というTechnoteより。
Technoteでは、以下の３つの観点でまとめています。
- 文書
- ビュー（インデックス）
- ホワイトスペース
データベースの文書数は、DBプロパティから確認可能ですが、サーバーコンソールを使える環境なら、「show database DBファイル名」と入力すると、各設計要素の数や、削除スタブ数も表示されるし、ビューのインデックスのサイズも表示されます。
ビューインデックスについては、上記コンソールからも把握可能ですが、Domino管理クライアントからも実はビュー情報は確認可能です。（「ファイル」タブより、「データベース」→「ビューの管理」）
DBのサイズを最も小さくするためには、compact -d がよいのですが、これは全ビューインデックスが削除されるため、ある意味非常な危険なコマンドです。というのも、次回のユーザーアクセス時にビュー索引を構築する必要があるからです。ビューの構築というのは、非常に負荷の高い操作であり、１つや２つのビューならまだしも、多数のDBに対してビュー構築の動作が同時に行われると（例：サーバー上全てのDBにcompact -dをした場合）、その後のユーザーアクセスピークの間はサーバー負荷は大変なことになります。
ということで、上記Technoteのcompact -dに興味を持った場合も、いきなり週末に本番サーバーで実行・・・というのはお勧め出来ません。
ちなみに、compact -dは、-cスタイルの圧縮になります。
Notesアプリケーション開発時のパフォーマンス考慮
同じくTechnote斜め読みより。
Are there any guidelines regarding performance when developing a Notes application?
細かいお話は、Related Informationというところに入っていますが、基本的には「Performance Considerations for Domino Applications」というRedbookを参照せよとのことです。これはR5における情報ですが、基本アーキテクチャは大きく変更していないので、現在でも利用可能です。
以前のエントリの中でも触れたのですが、上記Redbookは日本語訳もされています。他にもいくつか参考になるのもあるかもしれないので、こちらもどうぞ。
アプリケーションのパフォーマンスが・・・
Are there any guidelines regarding performance when developing a Notes application?
細かいお話は、Related Informationというところに入っていますが、基本的には「Performance Considerations for Domino Applications」というRedbookを参照せよとのことです。これはR5における情報ですが、基本アーキテクチャは大きく変更していないので、現在でも利用可能です。
以前のエントリの中でも触れたのですが、上記Redbookは日本語訳もされています。他にもいくつか参考になるのもあるかもしれないので、こちらもどうぞ。
アプリケーションのパフォーマンスが・・・
暗号化されたデータベース
Technoteの斜め読みから見つけたトピックより
Can you find out who encrypted a database?
少し前に、データベースの暗号化 というエントリを書いたのですが、その関連項目です。
暗号化されているデータベースを、「どのID」を使って暗号化したかがわかりますか？ というお話。
当然ながら、これはわかりません。
よくある話としては、
Can you find out who encrypted a database?
少し前に、データベースの暗号化 というエントリを書いたのですが、その関連項目です。
暗号化されているデータベースを、「どのID」を使って暗号化したかがわかりますか？ というお話。
当然ながら、これはわかりません。
よくある話としては、
- サーバー上のDBを直接ファイルコピーした場合はサーバーIDで暗号化されている
- ローカルにコピー or 複製したファイルをコピーした場合は、そのコピー、複製オペレーションをしたユーザーIDで暗号化されている
2006/06/24
クラッシュとハング
Dominoサーバーのハングとクラッシュに関する英語記事の日本語翻訳が公開されたようです。
Lotus Domino のハングとクラッシュのトラブルシューティング
一言でDominoサーバーの問題といっても、ハングやクラッシュから、パフォーマンスが遅いなど、いろいろとあるのですが、この記事はクラッシュやハングを理解する手がかりになりそうです。
私の個人的な意見では、まず、「クラッシュ」と「ハング」の違いを認識し、情報伝達をするときに、この２つの用語を正しく伝える、というだけで、最初のすれ違いを防止するのに非常に有効だと思います。上の記事では、「ダウン」という言葉も同義で使ってるようです。（私の）日本語的には「サーバーが落ちる」も同義としてよく使います。ハングは「フリーズ」とも言ったりしますね。
よくメールで「サーバーがハングしました・・・」と連絡を受けたりするのですが、多くの場合話を聞いてみると意図したいことは「クラッシュ」だったりするんです・・・。
この記事の中では、いろいろなことが書いてあるのですが、以下のところをきちんと読むのがよいかと思ってます。
問題発生時には、いろいろな人が関わる都合上「伝言ゲーム」が多いのですが、少なくとも技術者が関わる部分では誤解のないように伝達しあいたいというのが私個人の希望です。
で、この記事ですが、残りの部分も、読めば面白かったり、役に立つこともあるかもしれませんが、幅広くいろいろと読まされることになるので、まずは上記のとこだけでも最低限読むとよいかと。
Lotus Domino のハングとクラッシュのトラブルシューティング
一言でDominoサーバーの問題といっても、ハングやクラッシュから、パフォーマンスが遅いなど、いろいろとあるのですが、この記事はクラッシュやハングを理解する手がかりになりそうです。
私の個人的な意見では、まず、「クラッシュ」と「ハング」の違いを認識し、情報伝達をするときに、この２つの用語を正しく伝える、というだけで、最初のすれ違いを防止するのに非常に有効だと思います。上の記事では、「ダウン」という言葉も同義で使ってるようです。（私の）日本語的には「サーバーが落ちる」も同義としてよく使います。ハングは「フリーズ」とも言ったりしますね。
よくメールで「サーバーがハングしました・・・」と連絡を受けたりするのですが、多くの場合話を聞いてみると意図したいことは「クラッシュ」だったりするんです・・・。
この記事の中では、いろいろなことが書いてあるのですが、以下のところをきちんと読むのがよいかと思ってます。
- サーバークラッシュと何か、と、一般的な症状。
- クラッシュの原因として箇条書きに書かれていること
- サーバーハングとは何か、と、一般的な症状。
- サーバークラッシュのトラブルシューティングに書いてある「次の点を考慮します」の箇条書き
問題発生時には、いろいろな人が関わる都合上「伝言ゲーム」が多いのですが、少なくとも技術者が関わる部分では誤解のないように伝達しあいたいというのが私個人の希望です。
で、この記事ですが、残りの部分も、読めば面白かったり、役に立つこともあるかもしれませんが、幅広くいろいろと読まされることになるので、まずは上記のとこだけでも最低限読むとよいかと。
2006/06/20
タブの切り替えショートカット
Windowsでアプリケーションを切り替えるときに、「Alt」＋「Tab」を使ってる方は非常に多いと思います。私も1日に100回以上使ってると思います。（左手親指＋薬指）
それに似た技がNotesの中でも使えますよ、というお話です。
TABbing between Notes windows
Notesクライアントでは、新規ウィンドウをタブ形式で開いていきますが、このタブの切り替えはマウスを使わなくても、「Ctrl」＋「Tab」で出来ます。とのこと。
私は10本の指をかなり器用に動かすことが出来るので、「Ctrl+W」のショートカットも左手の小指＋薬指で普通に押すことが出来るのですが、ホームポジション・手首固定のタイプ打ちにとって、少なくともThinkpad Tモデルのキーボードでこの「Ctrl」＋「Tab」は厳しい・・・。
ということで、マウスを使わなくともウインドウ切り替えられるのは嬉しい反面、自分のタイプ癖からは絶対に使わないショートカットのご紹介でした。 使う人・・・いますかね。
それに似た技がNotesの中でも使えますよ、というお話です。
TABbing between Notes windows
Notesクライアントでは、新規ウィンドウをタブ形式で開いていきますが、このタブの切り替えはマウスを使わなくても、「Ctrl」＋「Tab」で出来ます。とのこと。
私は10本の指をかなり器用に動かすことが出来るので、「Ctrl+W」のショートカットも左手の小指＋薬指で普通に押すことが出来るのですが、ホームポジション・手首固定のタイプ打ちにとって、少なくともThinkpad Tモデルのキーボードでこの「Ctrl」＋「Tab」は厳しい・・・。
ということで、マウスを使わなくともウインドウ切り替えられるのは嬉しい反面、自分のタイプ癖からは絶対に使わないショートカットのご紹介でした。 使う人・・・いますかね。
2006/06/15
データベースの文書数
答えがないとわかっていながらも、何かよい答えを言ってくれる人がいるのでは・・・と回答を期待してしまう質問の１つに「Notesのデータベースは何文書まで大丈夫ですか」というのがあります。
でも、きっと本当の意味での正解は、「it depends」でしょう（つまり正解は存在しない）。
そこで、１つの指標として、事例として存在する巨大DBを参考にしてみる、というのが考えられます。残念ながら、私の周りはわりと平和的な使い方をしているため、無謀なケースはあまり知りません。知っている限り最も文書数が多いデータベースは、developerWorks上のフォーラムです。
こちら、2006年6月15日現在のステータスは以下の通り。
Notes/Domino 4 and 5 Forum (Notes1/NotesWeb)
文書数：885,938文書
DBサイズ：9,986MB
全文索引サイズ：1,573MB
実体はこれです。
http://www-10.lotus.com/ldd/46dom.nsf
大量文書を持ちながらも、わりと快適にWebでサービス提供が出来ていることを考えると、データベースの環境次第（DB設計、サーバーの環境）では、100万文書も十分にありえると思います。
さて、「文書数」というのは、ある意味「DBサイズ」よりもパフォーマンスにとっては重要で、特に文書数が多い場合「ビューの数」や「ビューの複雑さ（選択式、列の数、列式、ソートの有無、カテゴリ展開の有無、索引更新の頻度など）」には細心の注意を払わないと、ビューが開かなかったり、サーバー全体のパフォーマンスへ影響があったりします。
また、いかにビューをシンプルにしたとしても、文書数が非常に多い場合、破損時や移行時などのビューの再構築には、それなりの時間がかかるので注意が必要です。
なお、私個人の感覚では、「削除スタブ」の数もパフォーマンスに影響するのではないかと思っています。このため、新規にアプリケーションをデザインするときは、表面的な文書数だけでなく、削除運用を含めた上で、考えたほうがよいと思っています。
既にパフォーマンスに問題のあるDBを調査するときには、文書数のほかに削除スタブの数も知っておきたいところです。削除スタブの数え方はいくつかあるかと思いますが、私はサーバー上で「show database データベース名」を叩いて確認しています。
削除スタブの削除の仕方は、こちらをどうぞ。
How to purge document deletion stubs on the server immediately
もちろん、削除時は複製運用などに注意が必要です。
以上、よく問い合わせを受ける話なので、私個人が持っている意見などを書きましたが、この考えは絶対ではないと思いますし、もっと参考になる事例などもあると思います。あくまで１つの参考としてご参照下さい。またよい事例はシェアさせて頂けると幸いです。
でも、きっと本当の意味での正解は、「it depends」でしょう（つまり正解は存在しない）。
そこで、１つの指標として、事例として存在する巨大DBを参考にしてみる、というのが考えられます。残念ながら、私の周りはわりと平和的な使い方をしているため、無謀なケースはあまり知りません。知っている限り最も文書数が多いデータベースは、developerWorks上のフォーラムです。
こちら、2006年6月15日現在のステータスは以下の通り。
Notes/Domino 4 and 5 Forum (Notes1/NotesWeb)
文書数：885,938文書
DBサイズ：9,986MB
全文索引サイズ：1,573MB
実体はこれです。
http://www-10.lotus.com/ldd/46dom.nsf
大量文書を持ちながらも、わりと快適にWebでサービス提供が出来ていることを考えると、データベースの環境次第（DB設計、サーバーの環境）では、100万文書も十分にありえると思います。
さて、「文書数」というのは、ある意味「DBサイズ」よりもパフォーマンスにとっては重要で、特に文書数が多い場合「ビューの数」や「ビューの複雑さ（選択式、列の数、列式、ソートの有無、カテゴリ展開の有無、索引更新の頻度など）」には細心の注意を払わないと、ビューが開かなかったり、サーバー全体のパフォーマンスへ影響があったりします。
また、いかにビューをシンプルにしたとしても、文書数が非常に多い場合、破損時や移行時などのビューの再構築には、それなりの時間がかかるので注意が必要です。
なお、私個人の感覚では、「削除スタブ」の数もパフォーマンスに影響するのではないかと思っています。このため、新規にアプリケーションをデザインするときは、表面的な文書数だけでなく、削除運用を含めた上で、考えたほうがよいと思っています。
既にパフォーマンスに問題のあるDBを調査するときには、文書数のほかに削除スタブの数も知っておきたいところです。削除スタブの数え方はいくつかあるかと思いますが、私はサーバー上で「show database データベース名」を叩いて確認しています。
削除スタブの削除の仕方は、こちらをどうぞ。
How to purge document deletion stubs on the server immediately
もちろん、削除時は複製運用などに注意が必要です。
以上、よく問い合わせを受ける話なので、私個人が持っている意見などを書きましたが、この考えは絶対ではないと思いますし、もっと参考になる事例などもあると思います。あくまで１つの参考としてご参照下さい。またよい事例はシェアさせて頂けると幸いです。
2006/06/10
[雑談] 数独
Notes/Dominoとは全く関係ない話なのですが、IBM Lotus Notes/Domino Hints and Tips のSu Doku for Notes - Coming Soon を見て思い出しました。
ニコリ系のパズルといえば、私も若い頃、数独とカックロだけは結構やったのですが、去年 Codestoreを読んでいて、The Soduko Crazeのエントリを見たときに、初めてこの遊びが海外でもブームになっていることを知りました。Wikipediaの英語版にも、Sudokuという形で詳細が記述されています。
確かに昨年末東海岸に行ったときも、空港やB&Nで大量に積んでありました。きっとテトリスが流行したように、シンプルなとこがウケてるのでしょうか。
私自身は最近は空き時間は読書や勉強などに使いたいと思っていますが、一昨年入院していたときは、暇つぶしに結構やっていました。それほど得意ではないんですが、9x9(3x3x9コマ)は時間をかければだいたい解けた気がします。25x25 (5x5x25コマ) は結局1度も解けませんでした。
別にNotes/Dominoの技術者がというわけではないんでしょうが、IT系の技術者はこの手のものはわりと好きなんでしょうね。
ニコリ系のパズルといえば、私も若い頃、数独とカックロだけは結構やったのですが、去年 Codestoreを読んでいて、The Soduko Crazeのエントリを見たときに、初めてこの遊びが海外でもブームになっていることを知りました。Wikipediaの英語版にも、Sudokuという形で詳細が記述されています。
確かに昨年末東海岸に行ったときも、空港やB&Nで大量に積んでありました。きっとテトリスが流行したように、シンプルなとこがウケてるのでしょうか。
私自身は最近は空き時間は読書や勉強などに使いたいと思っていますが、一昨年入院していたときは、暇つぶしに結構やっていました。それほど得意ではないんですが、9x9(3x3x9コマ)は時間をかければだいたい解けた気がします。25x25 (5x5x25コマ) は結局1度も解けませんでした。
別にNotes/Dominoの技術者がというわけではないんでしょうが、IT系の技術者はこの手のものはわりと好きなんでしょうね。
登録:
投稿 (Atom)
