タイトル/名前 | 更新者 | 更新日 |
---|---|---|
日記/2008/11/30/プロジェクトコーディネータ(PC)という呼び方はどうだろう | msakamoto-sf | 2008-11-30 10:18:58 |
日記/2008/11/29/YakiBikiのセッション管理、とりあえずの対応。 | msakamoto-sf | 2008-11-29 09:12:52 |
日記/2008/11/29/YakiBikiのセッション管理、自前にしようかどうしようか。 | msakamoto-sf | 2008-11-29 00:27:10 |
レジストリの直接編集によるファイルの拡張子と関連づけ | msakamoto-sf | 2008-11-27 23:51:11 |
サイバー日野/2002/03/07/15/PHPでのメール送信時エンコーディング | msakamoto-sf | 2008-11-27 08:26:08 |
日記/2008/11/25/YakiBikiのWebサイト | msakamoto-sf | 2008-11-25 01:35:48 |
日記/2008/11/24/松井冬子いいなぁ | msakamoto-sf | 2008-11-24 11:13:42 |
TODO | msakamoto-sf | 2008-11-24 00:20:59 |
日記/2008/11/24/移設開始、あとYakiBikiのBracketリンクでバグ。 | msakamoto-sf | 2008-11-24 00:17:00 |
SandBox | msakamoto-sf | 2008-11-23 18:31:05 |
あるソフトハウスの部長の方なのですが、営業的なこともするしマネージャ的な事もするし、部長として部門の数字に責任を負ったりして、非常にいろんな仕事をこなしてらっしゃる。
「お客に『マネージャの方ですか?』と訊かれてもそうとも言えないし、今の仕事をどう呼べばいいのか分からない」とかこぼされていたので。
半ば思いつきで、「じゃあ『プロジェクトコーディネータ』というのはどうですか?」と。
面白いとはいってもらったのですが、まぁ名刺にはさすがに載せてないようで。
その方、営業的な事と言いましてもお客様からITプロジェクトの話を聞いて、「弊社であればこういう人員をそろえてこういう布陣でその仕事、お受けできます」というふうに、「会社として体制を整えて」お仕事を受けるのが多いのです。自分達の会社で足りない人員については横つながりでお知り合いの会社に声をかける。となると会社間の人間の調整もする。
なんというか、「営業」という括りとは違う。部長としての仕事も兼務してて、特定のプロジェクトに専任されているわけでもないので「マネージャ」という呼び方もしっくりこない。何かプロジェクトで緊急事態が発生したら現場に出向いてヒアリングしてお客と相談したりもする。
というわけで「コーディネータ」、物事を調整する人、という呼び方が(個人的には)一番自然でしっくりくるのでどうかなぁとおもうわけです。(*1)
ふと、よくよく考えたらセッションCookieのexpireが2週間だからといって、session.gc_maxlifetimeまで2週間にする必要は無いんじゃないかと思い直した。
YakiBikiって基本的にメモ帳なので、例えば自分などは一日一回は必ずアクセスする。で、その度にYakiBikiはセッションの値に「最終更新日」を入れてる(*1)。なので、一日一回は自分がログインした分のセッションデータファイルのmtimeは更新されるという事。
・・・であれば、別にgc_maxlifetimeはもっと短くしても良いよね。gc_maxlifetimeが例えば24時間であれば、一日一回は使っている人間にとっては消される心配はなくなる。逆に検索BotやRSSリーダー、普通の閲覧者のセッションデータについては、24時間が経過したモノについてGCが消してくれる。
24時間は短すぎるか。1.5日位にしてみよう。
というわけで、1/20リクエストで起動するようにしたうえで、gc_maxlifetimeを1.5日に調整した。
いえ、gc_maxlifetimeを延ばした後二日ほどでセッション用のディレクトリに750を越えるデータファイルができて3MB程取ってしまいまして。二週間だとその7倍ですから、サイズはおいとくとしてもファイル数が半端じゃなくなる。
まぁ見るだけの人であればログインする必要がないのが大半ですので(少なくともこのブログについては)、これで良いか、という感じです。
どうも・・・自分のサイトにログインしてると、次の日とかになるとセッションが消えてしまうという現象に遭遇した。
セッションのexpireは2週間に設定しているし、FireFoxでCookieを確認してみても有効期限は2週間加算された日付になっていて問題はない。
ここ数日、自分のサイトでYakiBikiを使い始めて初めて遭遇したのだけれど、確実に再現できる方法が分からない。
ローカルでテストしている環境ではずーっとセッションCookieが持続していたのに。
で、いろいろローカルとサイト(レンタルサーバ)のsession関連の設定値を見比べていたら、session.gc_divisorがローカルは1000になっていたが、レンタルサーバは100になっていた。
あとsession.gc_maxlifetimeがローカル・レンタルサーバとも1440になっていた。
で、試しにレンタルサーバの方の session.gc_maxlifetime をセッションCookieのexpireに合わせて2週間の秒数にしてみたところ・・・どうにか維持できているっぽい。
なんだけれど、これやってしまうとguestユーザ相当に発行したセッションデータファイルが大量に残留してしまう。gc_divisorの頻度をいくら上げても、2週間経過したファイルでないと削除されないので。
弱った。
こうなったらXhwlayのBookmarkのGCと同じように、自前で session.save_handler を実装した方が良いかもしれない。発生頻度は1/20位にして、但しguest相当のセッションは有効期限に関係なく削除する、みたいにしないとディスクの無駄使いになる。
当面は session.gc_maxlifetime を24時間程度にして、YakiBikiの方の _YB('session.lifetime') には0を設定してブラウザを閉じるまでにしておくべきか。元々この前身となったPHPスクリプトでも、セッションはブラウザを閉じるまでにしておいて、一度ブラウザウインドウでログインしたら使い終わるまで(= PCの電源OFFるかブラウザが重たくなりすぎりか)開きっぱなしにする使い方をしていた。うーん。
このドキュメントは、Windows2000以上の環境で、レジストリを直接編集することによりファイルの拡張子とその関連づけの設定を行うための指南書として作成したものです。
通常、ユーザーレベルでファイルの関連づけを設定するには以下の方法が提供されています。
しかし、トラブルが起こった場合上記の設定を弄くるだけでは解決しない場合も多々あります。(往々にしてそういうトラブルの解決策はネット上にすら存在しません。)そういった場合、最終手段としてレジストリを直接編集し、拡張子とその関連づけを設定し直す必要があります。
このドキュメントは、そのような局面において「広大なレジストリのどこを編集すれば良いのか?」を解説するものです。
なお、このドキュメントは 無保証であり、無保障です。このドキュメントを参考にした操作により発生したいかなる現象も、操作を行った者の自己責任となります。ありきたりですが予防線でした。
このドキュメントを読む対象としては、レジストリエディタを起動し、操作できる人間を仮定しています。「レジストリエディタって何?」とか、「キーの追加ってどうやるの?」という方は、まずは「regedit.exe」などで検索し、使い方を覚えてからこのドキュメントを利用してください。(残念ですがそこまで手が回らないッス・・・)
ファイルの拡張子とその関連づけを保っているレジストリとそのキーを以下に示します。
このように、実際に操作するレジストリの範囲は案外と狭かったりします。しかし、今までレジストリをさわったり弄ったことのある人なら次の疑問が生じるかもしれません。
「HKEY_CLASSES_ROOT(HKCR)キーは操作しないのですか?」
これに対する答えとしては、
「HKCRはHKLM\SOFTWARE\Classes + HKU\(ユーザー識別子)\Software\Classes\Applications である」
つまり、HKEY_CLASS_ROOTはエイリアス(別名)であり、あくまでも「現在ログイン中のユーザー設定の確認用」として使用すべきなのです。実際に編集すると分かりますが、HKLM\Software\Classes や HKU\...\Software\Classes\Applications に対して行った変更は直ちに HKCR 以下にも反映されます。
本ドキュメントでは、「HKCRの実体は別にある」ことを明確にするため、あえてHKCRではなくその元となるHKLMやHKUを操作することにします。
最初に行うのは、HKLM\Software\Classes 以下に「ProgID」と呼ばれる形でアプリケーションを登録することです。
結論から先に言ってしまうと、Windowsのエクスプローラ(と言うよりは"シェル")は、ファイルがダブルクリックされると以下の順でたどっていきます。
拡張子 → 拡張子に設定された ProgID → ProgID に設定された実行ファイル本体
従って、とにもかくにも "ProgID" を登録しないと始まらないわけです。
C:\Program Files\Hoge\hoge.exe "%1"
この時点までを自動登録するファイル「hoge1.reg」の内容を示します。
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Hoge.Document] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Hoge.Document\shell] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Hoge.Document\shell\open] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Hoge.Document\shell\open\command] @="\"C:\\Program Files\\Hoge\\hoge.exe\" \"%1\""
続いて拡張子を登録します。今回は「.hoge」という新たな拡張子を設定してみます。
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.hoge] @="Hoge.Document"
・・・実は、たったこれだけで拡張子の関連づけができてしまいます。後の細かい設定は、エクスプローラの「ツール」→「フォルダオプション」→「ファイルの種類」で行う方が良いと思います。アイコンとかの設定は、そちらから行った方が断然楽だと思います。
まだシステムに登録していない拡張子のファイルをダブルクリックすると、開くアプリケーションを選択する画面が表示されます。そこで自分でアプリを選択すれば、自動的にその拡張子の関連づけを行ってくれます。この裏側では何が行われているのでしょうか?
結論から言うと、「拡張子_auto_file」という ProgID を自動的に生成しています。
上の例で言うなら、自動的に以下のエントリを設定してくれるわけです。
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.hoge] @="hoge_auto_file" [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hoge_auto_file] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hoge_auto_file\shell] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hoge_auto_file\shell\open] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\hoge_auto_file\shell\open\command] @="\"C:\\Program Files\\Hoge\\hoge.exe\" \"%1\""
著者がこのドキュメントを公開する直接の動機は、「プログラムから開く」でプログラムを参照できないというトラブルに見舞われた経験から来ています。(原因そのものは非常に単純なものでしたが・・・)
しかし、トラブルに見舞われずとも「プログラムから開く」で表示されるプログラムの一覧はどこから来ているのか、不思議に思われている方も多いのではないでしょうか?さらに不思議なのは、一度でも「参照」で自分で設定したプログラムは、自動的に一覧に登録してくれる点です。
ここではそのからくりについてみていきます。からくり・・・と言っても、その原理は驚くほど単純です。
(Excluding your applications from "Open With..." dialog box list.)
結論から言うと、「プログラムから開く」(英語だと「Open With...」)に表示されるプログラムの一覧は、次のレジストリキー以下にあります。
HKEY_LOCAL_MACHIN\\SOFTWARE\Classes\Applications
ユーザーが「参照」で自分で指定したプログラムの一覧は、次のレジストリキー以下に保存されます。
HKEY_USERS\(ユーザー識別子)\Software\Classes\Applications
では、今回の例に従い実際に「hoge.exe」を追加してみます。ユーザー別ではなく、HKLMの方を利用してみましょう。結論から提示します。以下の自動登録ファイルのようになります。
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\hoge.exe] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\hoge.exe\shell] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\hoge.exe\shell\open] [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\hoge.exe\shell\open\command] @="\"C:\\Program Files\\Hoge\\hoge.exe\" \"%1\""
"ProgID"の登録の時と似ています。ユーザーが自分で「参照」で選択した場合、 HKU\...\Classes\Applications 以下にこれと同様のキーとエントリが追加されます。
しかし、実際には HKLM\Software\Classes\Applications には一覧で表示されるよりも遙かに多数の .exe が登録されています。それらはなぜ表示されないのか?結論から言うと、「NoOpenWith」エントリが存在するからです。
NoOpenWith エントリ自体は中身が空の文字列ですが、これが設定されているキーは「プログラムから開く」の一覧には表示されません。
(How to delete history from "Open With..." sub menu)
これはインターネット上でも広く知られているTipsです。
HKEY_USERS\...\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts
上記中に、これまでユーザーが開いてきた拡張子の一覧がキーとして登録されています。さらにその中の "OpenWithList" 中に、a から始まるエントリが存在します。それがこれまでそのファイルを開いてきたプログラムの履歴となります。
履歴を削除するには、好みのエントリを削除すれば良いわけです。
著者自身が遭遇したトラブルは、"「プログラムから開く」でプログラムを参照できない」"という珍妙な現象でした。原因は単純で、C:\Program Files 以下にインストールしたフリーソフトのエディタを、丸ごとマイドキュメント以下に移動したことが原因でした。
詳しく説明すると、C:\Program Files 以下にインストールした時点で、一度「プログラムから開く」で参照できました。「プログラムから開く」の一覧にも表示されていました。この時点で、HKU\...\Software\Classes\Applications 以下にそのエディタのキーが登録されます。(利用したエディタは、インストーラなど無く、圧縮ファイルで展開されたフォルダ中のexeを実行すればそれで済むタイプでした。)
いけなかったのはその後で、エディタの入っているフォルダをマイドキュメント以下に移動してしまったのです。
これにより、「プログラムから開く」一覧を生成する際に「参照先が存在しない」として表示されません。さらにまずいのは、エントリ自体はすでに存在するため、「参照」で移動先のプログラムを指定しても修正されず、結局、プログラムを参照できない状態に陥ったわけです。(試しに適当なフリーのエディタをDLし、実験してみてください。フォルダ名を変更するだけで発現します)
この場合の解決策としては、HKLM\Software\Classes\Applications または HKU\...\Software\Classes\Applications 中の該当プログラムのエントリを一度削除します。その後、改めて「プログラムから開く」で移動先のプログラムを参照すれば、新規エントリとして正常に追加されます。
2008年11月時点での参考URLです。
記事作成当時は下記URLを参考にしたのですが、サイト構成などが変更されたようで、現在全てLOSTしています。
二、三日前にPHP掲示板でメール送信時に文字化けしてしまう部分を修正したことがある。その時に散々EUCSJIS変換で悩まされたのだが、この際そのときの「コツ」を書き付けとく。
結論から言うと、例えばSubject ヘッダーに対するEUC->SJIS変換は、
$subject = i18n_convert($subject,'JIS','EUC'); $subject = tree::mime_enc($subject);
こんなカンジで済ますことができる。
tree::mime_encの中身は
function mime_enc($str){ if(get_magic_quotes_gpc()) $str = stripslashes($str); $encode = "=?ISO-2022-JP?B?" . base64_encode($str) . "?="; //Bヘッダ+エンコード return $encode; }
とまあこんなカンジ。ようするに、
''先にEUC->JIS変換をかませた後、改めてbase64_encodeとか言うのをすれば、インターネットで標準的なエンコーディングができる''ということらしい。
じっさい、この順番で行うようになってから文字化けがぴたりと収まった。
これ・・・会員管理用のdo_mail.incとかにも適用したほうがいいかなあ・・・。
SF.netのwebスペース間借りできるので作ろうと思ったんですが。
SF.netのwebスペースってかなり制限がきつかったりするので、構築するのが手間。SSHでターミナルログインできないようなので、WinSCPなど経由でしかファイルを弄れないとか。
あと、利用者がそんな居るわけでもないのに専用サイト用意してもなー。という感じです。一応yakibiki.netとかyakibiki.orgのドメインは押さえてはいるけれど。
現実問題としてまだ専用サイトが無い事が原因で困った事が起きているわけでもないので、当面は個人ベースでのんびりと進めた方が良いんじゃないかなと。
専用サイトが云々とか、英語サイトも作りたいなーとかは、とどのつまりは見栄っ張りなだけなので。
という風に自分を納得させておく。
先日用事で出掛けて、書店に立ち寄った折に目の端に止まったのが
・「松井冬子 一(普及版)」
http://www.editions-treville.net/?pid=6114761
誰だろうと思って調べてみたら、何か結構有名人だったんですね。
ホームページもありました。
http://matsuifuyuko.com/index.html
画集、買おうかな・・・ボーナス入ったら。
Glamenv-Septzenへの移設を開始。
とりあえず、Nifty時代のコンテンツを移設した。
で、早速YakiBikiのBracketリンクのバグ発覚。
[[Alias > yb://hoge/ ]]
みたく末尾が"/"で終わる場合、
<yb_link yb://hoge/>Alias</yb_link>
という形になる為、 "/>" でyb_link HTMLプラグインの終端と認識されてしまうと言う罠。
・・・これ・・・うーん・・・yb_linkというかHTMLプラグインの限界だなぁ。
パラメータとかtrim()して渡しちゃってるし・・・。Bracket側で、">"の前に1つ半角空白入れるとかすれば良いかな。
Wiki書式のサンプル集
external site link : [http://www.google.com]
external site link : [http://www.google.com]
mail link : [mail@example.com]
mail link : [mail@example.com]
bold format(1) : ** bold "><'& ** bold format(2) : '' bold "><'& ''
bold format(1) : bold "><'&
bold format(2) : bold "><'&
italic format(1) : * italic "><'& * italic format(2) : ''' italic "><'& '''
italic format(1) : italic "><'&
italic format(2) : italic "><'&
deleted text : %% deleted "><'& %%
deleted text : deleted "><'&
footnote1((footnote1 "><'& http://www.google.com )) foobar1. footnote2((footnote2 "><'& http://www.google.com )) foobar2.
footnote1(*1) foobar1.
footnote2(*2) foobar2.
preformatted text. "><'& preformatted text. "><'& preformatted text. "><'& preformatted text. "><'&
blockquote. "><'&
blockquote. "><'&
blockquote. "><'& blockquote. "><'&blockquote. "><'&
blockquote. "><'&
data1 | data2 | data3 |
---|---|---|
data4 "><'& | data5 "><'& | data6 "><'& |
http://example.com/ | aaaaaaaa aaaaaaaaa |
bbbbbbbbbbbbbb |
L: col10 | c: col11 | r: col12 |
---|---|---|
col13 | col14 | col15 |
col16 | col17 | col18 |
col19 | col20 | col21 |