以前、goo ブログに書いておいた内容をここに新たにまとめる。
fortunefield.com ドメインの取得に Yahoo のサービスを
使った。
自分でネームサーバも立てたので、それのレジストラへの登録も
する必要があるが、これも Yahoo のサービスから行った。
自分のゾーンに権限をもつネームサーバを２つ以上登録しなければならない。
これは冗長性をもたせるためのインターネットの規約である。
このネームサーバは、｢登録済み｣ のものを指定しなければならない。
レジストラには、登録済みのネームサーバのホスト名と IP アドレスが
あって、その中から指定しなければならないということだろう。
したがって、ここにはすでにネームサーバとして機能しているサーバを
指定すればいい。むろん、そのサーバに自分のドメインのゾーン情報が
定義されていなければ無意味だが。そして、この他人のネームサーバを
勝手に指定することを阻止するようなチェック機構はないのではないかと
シマリンは語っていた。
自分で立てたネームサーバを指定するには、まず、そのネームサーバを
登録しなければならない。これを Yahoo のサービスでおこなうには、
Yahoo のヘルプから登録情報を送信しなければならない。送信後、５営業日くらいで
レジストラへの登録が終了するようだ。その後で、Yahoo のドメインコントローラ
を使って、自分で立てたネームサーバを指定することになる。
Saturday, April 29, 2006
Friday, April 28, 2006
Oracle メモ -- 起動・終了と表領域の更新
$ sqlplus /nolog
> connect user_name as sysdba
で Oracle に入る。user_name は SYSDBA の権限をもつユーザ名。
昔は、connect internal が使えたが Oracle 9 あたりから使えなくなった。
> shutdown
で終了。immediate 等のオプションもある。
> startup
で起動。これにも、どこまで起動するかを決めるオプションがある。
OS 起動直後などの場合、リスナーを立てる必要もあるので
> lsnrctl start
も実行する。
> ALTER DATABASE TEMPFILE '/home/oracle/app/oradata/temp.dbf' OFFLINE;
これで一時表領域に割り当てられた一時ファイルをオフラインにできる。
> ALTER DATABASE TEMPFILE '/home/oracle/app/oradata/temp.dbf' DROP INCLUDING DATAFILES;
これで一時ファイルを削除し、
> ALTER TABLESPACE TEMP ADD TEMPFILE '/home/oracle/app/oradata/temp.dbf' SIZE 2048M AUTOEXTEND OFF;
これで再作成する。AUTOEXTEND を ON にすれば、指定した SIZE に達すると自動拡張
される。
こういう操作をいちいちしなくて済む方法はないのか？
必要ない領域は削除して、自動的に一時ファイルのサイズが小さくなるような。
> connect user_name as sysdba
で Oracle に入る。user_name は SYSDBA の権限をもつユーザ名。
昔は、connect internal が使えたが Oracle 9 あたりから使えなくなった。
> shutdown
で終了。immediate 等のオプションもある。
> startup
で起動。これにも、どこまで起動するかを決めるオプションがある。
OS 起動直後などの場合、リスナーを立てる必要もあるので
> lsnrctl start
も実行する。
> ALTER DATABASE TEMPFILE '/home/oracle/app/oradata/temp.dbf' OFFLINE;
これで一時表領域に割り当てられた一時ファイルをオフラインにできる。
> ALTER DATABASE TEMPFILE '/home/oracle/app/oradata/temp.dbf' DROP INCLUDING DATAFILES;
これで一時ファイルを削除し、
> ALTER TABLESPACE TEMP ADD TEMPFILE '/home/oracle/app/oradata/temp.dbf' SIZE 2048M AUTOEXTEND OFF;
これで再作成する。AUTOEXTEND を ON にすれば、指定した SIZE に達すると自動拡張
される。
こういう操作をいちいちしなくて済む方法はないのか？
必要ない領域は削除して、自動的に一時ファイルのサイズが小さくなるような。
Sunday, April 02, 2006
メールと Web ページの文字エンコーディング
メールでもっとも単純な場合は、メールヘッダに
Content-type: text/plain; charset=ISO-2022-JP
のようなヘッダが入る。これにより、そのメールで
使われている文字エンコーディングが判明し、
メーラはメール本文を表示することができる。
Web ページの場合、HTTP レスポンスヘッダに
Content-type: text/plain; charset=UTF-8
のようなヘッダがあれば、ブラウザはここで指定された文字エンコーディングで
ページ内容を解釈して表示する。
Web サーバは、text/plain や text/html のような MIME タイプについては、
ブラウザからリクエストされたファイルの拡張子にもとづいて判別できる。
たとえば Apache だと、mime.types ファイルで対応関係を定義している。
問題は、charset で指定される文字エンコーディングの方で、これは
Web サーバが判定するのは難しい。そこで、HTML ファイルの場合は、
meta タグによって、この問題を解決している。つまり、
HTML ドキュメントで
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=euc-jp">
</head>
のように head セクションの最初に書く meta タグで文字エンコーディングを指定する。
ブラウザはここで指定されているエンコーディングにしたがって、ドキュメントを
解釈し、表示する。本当は、Web サーバがここを見て HTTP レスポンスヘッダを
設定してくれるのがベストだが、そこまではしてくれない。
もちろん、この手法は HTML ファイルにしか使えない便法にすぎない。
やはり、もっともよいのは HTTP のレスポンスヘッダで charset を指定してやることなのだ。
これを簡単にやる方法として、たとえば Apache だとディレクトリに
.htaccess というファイルをつくって、そこに
AddType "text/html; charset=EUC-JP" html
と書いてやると、そのディレクトリとサブディレクトリ以下に置かれた拡張子が
html のファイルの HTTP レスポンスの Content-type ヘッダの値を指定することが
できる。この方法だと、HTML 以外のファイルにも charset を指定することができる。
HTML の文字符号化スキーム を解説した文書を参考にしてくれ。
Web サーバは、
Content Negotiation
という処理をしてくれることがある。
これは HTTP/1.1 の規格で定められている。この処理は、
ブラウザからのリクエストヘッダ Accept-Language や Accept-Charset の値から
適切な言語、適切な文字エンコーディングのドキュメントを選択して
レスポンスするというものだ。たとえば、index.html として複数の
index.html.en, index.html.fr, index.html.ja.jis, index.html.ru.cp-1251
等々を用意しておき、リクエストヘッダを使って Content Negotiation して
適切なファイルをレスポンスする。この場合は、HTTP レスポンスヘッダに
文字エンコーディングが入ることもあるだろう。
Content-type: text/plain; charset=ISO-2022-JP
のようなヘッダが入る。これにより、そのメールで
使われている文字エンコーディングが判明し、
メーラはメール本文を表示することができる。
Web ページの場合、HTTP レスポンスヘッダに
Content-type: text/plain; charset=UTF-8
のようなヘッダがあれば、ブラウザはここで指定された文字エンコーディングで
ページ内容を解釈して表示する。
Web サーバは、text/plain や text/html のような MIME タイプについては、
ブラウザからリクエストされたファイルの拡張子にもとづいて判別できる。
たとえば Apache だと、mime.types ファイルで対応関係を定義している。
問題は、charset で指定される文字エンコーディングの方で、これは
Web サーバが判定するのは難しい。そこで、HTML ファイルの場合は、
meta タグによって、この問題を解決している。つまり、
HTML ドキュメントで
<html>
<head>
<meta http-equiv="Content-type" content="text/html; charset=euc-jp">
</head>
のように head セクションの最初に書く meta タグで文字エンコーディングを指定する。
ブラウザはここで指定されているエンコーディングにしたがって、ドキュメントを
解釈し、表示する。本当は、Web サーバがここを見て HTTP レスポンスヘッダを
設定してくれるのがベストだが、そこまではしてくれない。
もちろん、この手法は HTML ファイルにしか使えない便法にすぎない。
やはり、もっともよいのは HTTP のレスポンスヘッダで charset を指定してやることなのだ。
これを簡単にやる方法として、たとえば Apache だとディレクトリに
.htaccess というファイルをつくって、そこに
AddType "text/html; charset=EUC-JP" html
と書いてやると、そのディレクトリとサブディレクトリ以下に置かれた拡張子が
html のファイルの HTTP レスポンスの Content-type ヘッダの値を指定することが
できる。この方法だと、HTML 以外のファイルにも charset を指定することができる。
HTML の文字符号化スキーム を解説した文書を参考にしてくれ。
Web サーバは、
Content Negotiation
という処理をしてくれることがある。
これは HTTP/1.1 の規格で定められている。この処理は、
ブラウザからのリクエストヘッダ Accept-Language や Accept-Charset の値から
適切な言語、適切な文字エンコーディングのドキュメントを選択して
レスポンスするというものだ。たとえば、index.html として複数の
index.html.en, index.html.fr, index.html.ja.jis, index.html.ru.cp-1251
等々を用意しておき、リクエストヘッダを使って Content Negotiation して
適切なファイルをレスポンスする。この場合は、HTTP レスポンスヘッダに
文字エンコーディングが入ることもあるだろう。
ジョエル・テスト：いいプログラムへの１２のステップ
１．ソース管理システムを使っている？
CVS 等のこと。これがないと複数のプログラマの作業を調整することができないし、
バージョンを戻したりとか、複数のバージョンを管理したりとかいったことが
できない。
２．１ステップでビルドできる？
１ステップで、スクラッチからビルドして、ダウンロードサイトだろうと
CD-ROM のインストールだろうとリリースできるものができるということ。
#ifdef や各国語バージョンもすべて作成できなければならない。
３．デイリービルドしてる？
デイリービルドすることによって、ビルドできないソースを放置することが
なくなる。いい方法は、昼休みにデイリービルドし、うまくいけば昼休み後に
みんなが最新のソースをチェックアウトし作業を続ける。失敗したら、
チェックアウトせずに以前のソースで各々作業を続ける。もちろん、ビルドが
うまくいくように修正作業もおこなう。
４．バグデータベースはある？
・バグを再現する手順
・期待される（正しい）ふるまい
・観察される（バグの）ふるまい
・誰に割り当てられているか
・修正済みか否か
この５つは最低でも管理しなければならない。Bugzilla を使うとよい。
５．新しいコードを書く前にバグを直してる？
バグを直すのが遅ければ遅いほど、時間もコストもかかるので、できるだけ速く
修正するということだ。また、バグがなければ、直ちにリリースすることだって
できるのだ。
６．アップデートされてるスケジュールがある？
デモや広告など、ビジネス上の計画を立てるためスケジュールは必要だ。
また、スケジュールを立てることによって、実装すべき機能を明確にしなればならず、
それにより、あまり重要でない機能を先に実装してしまうなどということを
避けられる。
７．仕様書はある？
アジャイルな開発手法だと仕様書がないというか、実装しながら
設計していくというやり方のようだが。。。
いずれにしても、いきなりコードを書き始めるというやり方はまずいのだ。
最初から実装レベルの細かい仕様書を作る必要はないし、作れないだろうが
おおまかなレベルの仕様書は書く必要がある。
８．プログラマは静かな環境で働いてる？
ゾーン（集中状態）に入るには時間がかかる。よって、静かな環境で
働く必要がある。理想的には個室ということだが、なかなか難しいかな。
９．手に入る最高のツールを使ってる？
プログラマがストレスを感じないようにするということだ。
よりよいツールを使えば、生産性も上がる。
１０．テスタはいる？
TDD を実践してるときは、少なくとも単体テストはプログラマがやるだろう。
統合テストやユーザビリティテストでは、より時給の安いテスタを使え、って
ことだな。
１１．採用前にコードを書かせてる？
当然のことだが、なかなかやってるところは少ないかな。
履歴書と世間話で決めてるところが大半かな。
１２．ユーザビリティテストをしてる？
GUI プログラムではこれが重要。ユーザビリティによってユーザに
受け入れられるかどうかが決まってくる。
いわゆる『廊下でのユーザビリティテスト』で十分。５人に使ってもらえれば
９５％の問題点は分かる。
CVS 等のこと。これがないと複数のプログラマの作業を調整することができないし、
バージョンを戻したりとか、複数のバージョンを管理したりとかいったことが
できない。
２．１ステップでビルドできる？
１ステップで、スクラッチからビルドして、ダウンロードサイトだろうと
CD-ROM のインストールだろうとリリースできるものができるということ。
#ifdef や各国語バージョンもすべて作成できなければならない。
３．デイリービルドしてる？
デイリービルドすることによって、ビルドできないソースを放置することが
なくなる。いい方法は、昼休みにデイリービルドし、うまくいけば昼休み後に
みんなが最新のソースをチェックアウトし作業を続ける。失敗したら、
チェックアウトせずに以前のソースで各々作業を続ける。もちろん、ビルドが
うまくいくように修正作業もおこなう。
４．バグデータベースはある？
・バグを再現する手順
・期待される（正しい）ふるまい
・観察される（バグの）ふるまい
・誰に割り当てられているか
・修正済みか否か
この５つは最低でも管理しなければならない。Bugzilla を使うとよい。
５．新しいコードを書く前にバグを直してる？
バグを直すのが遅ければ遅いほど、時間もコストもかかるので、できるだけ速く
修正するということだ。また、バグがなければ、直ちにリリースすることだって
できるのだ。
６．アップデートされてるスケジュールがある？
デモや広告など、ビジネス上の計画を立てるためスケジュールは必要だ。
また、スケジュールを立てることによって、実装すべき機能を明確にしなればならず、
それにより、あまり重要でない機能を先に実装してしまうなどということを
避けられる。
７．仕様書はある？
アジャイルな開発手法だと仕様書がないというか、実装しながら
設計していくというやり方のようだが。。。
いずれにしても、いきなりコードを書き始めるというやり方はまずいのだ。
最初から実装レベルの細かい仕様書を作る必要はないし、作れないだろうが
おおまかなレベルの仕様書は書く必要がある。
８．プログラマは静かな環境で働いてる？
ゾーン（集中状態）に入るには時間がかかる。よって、静かな環境で
働く必要がある。理想的には個室ということだが、なかなか難しいかな。
９．手に入る最高のツールを使ってる？
プログラマがストレスを感じないようにするということだ。
よりよいツールを使えば、生産性も上がる。
１０．テスタはいる？
TDD を実践してるときは、少なくとも単体テストはプログラマがやるだろう。
統合テストやユーザビリティテストでは、より時給の安いテスタを使え、って
ことだな。
１１．採用前にコードを書かせてる？
当然のことだが、なかなかやってるところは少ないかな。
履歴書と世間話で決めてるところが大半かな。
１２．ユーザビリティテストをしてる？
GUI プログラムではこれが重要。ユーザビリティによってユーザに
受け入れられるかどうかが決まってくる。
いわゆる『廊下でのユーザビリティテスト』で十分。５人に使ってもらえれば
９５％の問題点は分かる。
Subscribe to:
Posts (Atom)