プログラマーですが何か?まだプログラマーですが何か?プログラマーネタとアスリートネタ中心。久喜事業所の工場見学をする機会がありました。普段は写真を撮るばかりのマンホール蓋の、そのデザインから色付けまでの製造過程、および性能テストの様子を拝見させていただきました。貴重な機会をありがとうございました。この工場見学を企画いただいた関係者の皆さん、お疲れ様でした。工場内でも多くの写真を取りましたが、公開NGなものが多く、ここでの紹介は控えることにします。写真ではなく、その中で説明いただいたことを1つだけ紹介させていただきます。マンホール蓋には、通称「親子蓋」と呼ばれる形状のものがあります。http://manholemap.juge.me/page.jsp?id=1192002親子蓋とは親蓋の中に子蓋が埋め込まれている形状のものです。街中でもたまに見かける機会があり、これ自体は特別に珍しいわけではありません。2つの疑問点があります。「何故2つ必要なのか?」という疑問があります。そもそも大きい蓋と小さい蓋に分ける理由があるのか?「大は小を兼ねる」的な発想で、大きい蓋だけでは何か不都合があるのか?そしてもう1つは「何故同心円の形状ではなく、ある方向に偏った2つの円なのか?」という疑問です。同じ中心の、2重丸の方がキレイだし、デザインも楽なのではないかと思うのですが、どうして小さい蓋は(上の写真では)上方向に寄せられているのでしょうか?それらの答は今回の工場見学を通じて知ることができました。大きい蓋と小さい蓋に分けられている理由ですが、小さい蓋は人間が出入りするためのもので、大きい蓋は機械を中に入れる際のものなのだそうです。「人間も大きい蓋を空けて出入りすればいい」とも思うのですが、空けた穴に取り付ける器具など、小さい穴のサイズが想定されているものもあるため、人間が出入りする際にはあくまで小さい穴を使うことになるようです(ちなみに人間用の穴は直径60cmという規格があり、周辺機器(っていうのか?)もその規格にそって作られているようです)。この規格に合わないような大きな機械を中に入れることが必要になることもあるのですが、その場合のために大きい蓋が用意されている、とのことでした。1つの謎ですが、これは実際に使う段階を考えればすぐ分かることでした。マンホールの蓋を開けると、その下へ進むためのはしごが筒の内側に用意されています。親子蓋が同心円で2重丸の様になっている場合、子蓋だけを空けた時に穴の位置よりも更に外側にはしごが設置されていることになるため、穴に入って足を引っ掛けたり、はしごを掴むまでが結構大変な作業になることが分かります。上記画像のようにある方向に偏った位置に子蓋があると、そこを空けた時にスムーズにはしごが掴める位置に穴が空くことになります。広い意味で「安全のため」に、親子蓋の蓋は同心円上ではなく、わざと偏った位置に作られている、ということでした。サービスを試しに使ってみました。よる買収が発表されました)。サービスの1つとして提供されている、ということになります。CouchDB」ということになります。サービスを使う手順を紹介します。見つけることができます。アプリケーションを選択します(試しに使うだけなら特定のアプリケーションへの紐付けは不要です)。サービスが生成されます:ちなみに、上記画面の下の方までスクロールするとサービス価格についての説明があります。までは無料枠内で使えるようです。実行回数についても無料枠と有料枠が設定されているようです。サービスが生成されるとダッシュボード内にこのようなパネルが追加されているはずです。情報を確認している画面です。メモしておきましょう。サービスについても説明が表示されている画面です。サーバーコンソールが表示されている画面です。ここでデータベースや複製、アカウントなどの情報を参照したり、実際にドキュメントを読み書きできます。ボタンをクリックして最初のデータベースを作成しておきます:データベース名を指定します。タブ内の画面が変わりました(まだデータはありません)。ボタンをクリックして最初のドキュメントを作成しておきます:中身はこんな感じにしました。ボタンをクリックします:保存されました。一覧画面に戻りました。先程作成したドキュメントが表示されています。経由で呼び出してみます。目的のドキュメントの情報が取得できました。日本語情報も問題なさそうです。使い始めて3ヶ月とちょっと。サービスを実際に使ってみた上で気付いた勘所というか、感想をまとめてみます。1サーバーあたり月額467円から提供されている。最安のエントリーサービスの場合はメモリ1GB+ディスク50GB。この2倍と4倍のサービスも用意されていて、価格もほぼ2倍と4倍。コストパフォーマンスが上回る。中でも特に安い部類のサービスだと思います。ウェブインターフェースからのサーバー管理も可能です。「普通に使える」という印象です。エントリーサービスで契約しているため、メモリは1GBで運用していて、それがもう少しあればいいなあ、と思うことはありますが、絶対的に足りないわけでもありません。ディスク50GBは全然余裕。パフォーマンスも特別に遅いとは思いません。アクセスできるホストが月500円足らずで使えてしまう、というコストパフォーマンスに驚いてます。会員情報の「メンテナンス情報」と「障害アナウンス」はメールで受け取れるように設定しておくべきです。それなりの頻度でメンテナンスがあり、その期間中はサーバーが停止します(アクセスできません)。このメンテナンスのタイミングを事前に知るには、会員サービスで「メンテナンス情報をメールで受け取る」ように設定しておく必要があるのです(単に契約しただけだとこの設定はされていないので、サーバーがメンテナンスに入るタイミングを知ることができません)。同様に、「障害のアナウンス」もメールで知ることができますが、これも会員サービスで「障害アナウンスをメールで受け取る」ように設定する必要があります。これをやっておかないと、知らない間にメンテナンスが行われ、その間は「なぜかサーバーにアクセスできない。調べてみたら止まってる」ように見えてしまいます。メンテナンスのタイミングが事前に分かっていれば、アプリケーションサービス内でユーザーに告知することもできるようになるし、運用側としても事前に準備できます。使うならメンテナンス情報はメールで受け取るように設定することが必須だと思われます。標準でここまでやってくれてもいいと思うくらい必須。サーバーのデータをバックアップ&リストアする手順を紹介します。バケットに対してのみ可能な手順です。バックアップを実行します。以下に出力しています。以下にはバックアップ結果のダンプファイルができています。ダンプファイルはクラスタ毎に作成されるので、クラスタ数と同じ数のダンプファイルが出力されているはずです:/tmp/default_backup/bucket-default/node-couchbase.test.com%3A8091/data-0000.cbb次にリストアを実行します。いうバケットに対してリストアする、という処理を指示しています。サーバーの特長の1つに「memcached互換」があります。サーバーは比較的遅いリレーショナルデータベースのフロントエンドプロセッサーとして配置することで、部分的/仮想的に高速なデータベースサーバーを実現できます。メモリ上にのみ存在させて、ディスクへの読み書きを最小限に減らすことで高速化を実現しているため、そのままサーバーを落とすと中身が無くなり、再度メモリ上に展開して初めて再度利用することができるようになります。そのもののようにディスクへの退避のないデータストアとして利用することもできますし、データを非同期にディスクへ退避させつつメモリ中心のアクセスで高速化をはかる、という利用方法も選択できます(バケット単位で種類を指定します)。ちなみにデフォルト設定では後者になります。挙動を真似ているというだけでなく、互換性があります。サーバーのデータも読み書きできます。実際に試してみましょう。クライアントを用意しておきます。サーバーに接続します。表示されれば接続できています。試しにこのプロトコルでデータを作成してみます。コマンドでデータを作成します。ここでは0を指定します。3番目のパラメータはデータの有効期限を秒単位で指定しますが、ゼロを指定すると無制限(ずっと残るデータ)になります。4番目のパラメータはデータサイズ、そして最後に実際のデータを入力します。いう入力した値が正しく取得できました。プロトコルで値の読み書きができることが確認できました。同じように使えることが分かりました。対しても使えることになるので、これは便利な互換性といえます。ブログ検索」ブログパーツは、サービスを終了しました。