Firefox 4.0

Firefox 4.0にアップデートしてみたのは良いんだけど、まだボタン配置などに慣れないなぁ。

プラグインの対応も追いついていないので、ちょっとだけ困っていますが、
動きは確かに軽快になった気がする。

radiko 2011/4に福岡でも

http://radiko.jp/info/?f=201103　を見ると、４月中にも福岡でradikoが使えるらしい。
うーむ、視聴スタイルがちょっと変わるかなぁ。

でも、うちの場合、なぜか場所が熊本と認識されているんだよなぁ↓。


聞こえるのかなぁ(^^;

今日は一日”大滝詠一”三昧...堪能しました

いやぁ、堪能した。新しい発見がいっぱいあった。
今日は一日”大滝詠一”三昧

最初の２時間程度の録音失敗は痛いけど、まぁ、ほとんど聞けたから良いか。

lvm関連の記録

サーバの計画停止前後の作業に関するご参考メモにて、下記のように書いた。

• mountしているファイルシステムを記録する。
  mount > 正常時マウントファイルシステム一覧.txt


• 各ファイルシステムの空き容量なども、同時に記録しておく。
  df > 正常時ファイル使用量一覧.txt

しかし、今時のlvmを使っているシステムでは、上記だけでは分からないこともある。

実際に、このBlogを動かしているLinux機もlvmを使っていて、dfとmountだと物理的なドライブと論理的なパーティションの関係が見えない。

root@hong:/# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/hong-root
115460648 11691632 97903956 11% /
none 498572 240 498332 1% /dev
none 504548 0 504548 0% /dev/shm
none 504548 92 504456 1% /var/run
none 504548 0 504548 0% /var/lock
/dev/sda1 233191 74886 145864 34% /boot
/dev/mapper/home-shibata
103212320 42069396 55900044 43% /home
/dev/mapper/home-backup
77409288 68440672 5036456 94% /home/backup
root@hong:/# mount
/dev/mapper/hong-root on / type ext4 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
/dev/mapper/home-shibata on /home type ext3 (rw)
/dev/mapper/home-backup on /home/backup type ext3 (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)

これでは、ディスククラッシュ時にどのHDDをどうすれば良いのか分からない。

自分の記録を兼ねて、lvmの状態記録するコマンドとその結果を書いておく。

root@hong:/# lvm pvs
PV VG Fmt Attr PSize PFree
/dev/sda5 hong lvm2 a- 114.80g 0
/dev/sdb1 home lvm2 a- 186.30g 11.30g
root@hong:/# lvm vgs
VG #PV #LV #SN Attr VSize VFree
home 1 2 0 wz--n- 186.30g 11.30g
hong 1 2 0 wz--n- 114.80g 0
root@hong:/# lvm lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
backup home -wi-ao 75.00g
shibata home -wi-ao 100.00g
root hong -wi-ao 111.87g
swap_1 hong -wi-ao 2.93g
root@hong:/# lvm pvdisplay
--- Physical volume ---
PV Name /dev/sdb1
VG Name home
PV Size 186.31 GiB / not usable 3.69 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 47694
Free PE 2894
Allocated PE 44800
PV UUID 7lVW1I-bkBd-JqAY-ZmKr-NO87-uuRD-0AVyao
--- Physical volume ---
PV Name /dev/sda5
VG Name hong
PV Size 114.80 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 29388
Free PE 0
Allocated PE 29388
PV UUID ZH3dd0-8P2q-1zTz-2DYj-zDgf-hd14-vFVGgX
root@hong:/# lvm lvdisplay
--- Logical volume ---
LV Name /dev/home/backup
VG Name home
LV UUID IGmFsr-KCJJ-dYB8-Vn7O-fFMB-cbmv-NxyNjq
LV Write Access read/write
LV Status available
# open 1
LV Size 75.00 GiB
Current LE 19200
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:0
--- Logical volume ---
LV Name /dev/home/shibata
VG Name home
LV UUID tLrUnV-VRQo-uSUj-dB6N-mTKK-Qh9u-kt0OkV
LV Write Access read/write
LV Status available
# open 1
LV Size 100.00 GiB
Current LE 25600
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:1
--- Logical volume ---
LV Name /dev/hong/root
VG Name hong
LV UUID Eo3Xgd-8z3D-MlKt-ZpCF-SGxu-OaWM-IuP8kF
LV Write Access read/write
LV Status available
# open 1
LV Size 111.87 GiB
Current LE 28638
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:2
--- Logical volume ---
LV Name /dev/hong/swap_1
VG Name hong
LV UUID gFiccD-EZH3-QAZy-SWG1-wd2a-HPoM-E9gtq7
LV Write Access read/write
LV Status available
# open 1
LV Size 2.93 GiB
Current LE 750
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 251:3
root@hong:/# lvm vgdisplay
--- Volume group ---
VG Name home
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 186.30 GiB
PE Size 4.00 MiB
Total PE 47694
Alloc PE / Size 44800 / 175.00 GiB
Free PE / Size 2894 / 11.30 GiB
VG UUID doTZj5-bjAc-Tu1q-FElV-GkSQ-Y17F-2wO4F8
--- Volume group ---
VG Name hong
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 2
Open LV 2
Max PV 0
Cur PV 1
Act PV 1
VG Size 114.80 GiB
PE Size 4.00 MiB
Total PE 29388
Alloc PE / Size 29388 / 114.80 GiB
Free PE / Size 0 / 0
VG UUID yOL3WY-JR09-qc9P-1EiV-d8d0-pWqT-Be0ipp


宇宙は何でできているのか

会社の同僚が貸してくれたので、久々に本らしい本を読んでみた。
��老眼がひどくて、目が疲れてしまい、めっきり読書が億劫になっております。


うーん、私が知っていた物理学の知識は、古典物理＋前世紀の量子物理の世界までであることがよくわかった(^^;
同い年著者は、難しいことを分かりやすく書いて頂いているが、基礎ができていないとちょっと難しいなぁ。
そもそも、新しい物理学の世界が「フレーバー」だの「スピン」だの「ストレンジネス」だの、比喩だったりアナロジーだったりを多く使って説明している感じなんだけど、これがまた原理を分かっていないものに取っては難しい。(著者のせいではない。)

��私も「カレーの作り方」に例えて論文の作成過程や説明／記載内容に関する指導を行ったり、
��「うどん屋を作るための費用」の例で超概算見積もりの方法の話などをするけど、
��かえって混乱させていないかと、ちょっと反省(^^;

本書に話を戻すと、最近ノーベル賞を受賞された南部博士、小林博士、益川博士がすごい人たちなんだと言うことの片鱗も知ることが出来ます。

��えらそうにしているけど、知らないことだらけだなぁ、私σ(^^;

my用語集：「アドバンテージ見てるよ！」

私が若手に対して「アドバンテージ見ているよ」と言うことがある。

ここでの「アドバンテージ」はWikipediaにも書かれているラグビーでの用法である。
http://ja.wikipedia.org/wiki/アドバンテージ

どういう時に使うかというと、

• 色々説明を行っているが、要領を得ない。しかし、もう少し聞くとポイントに迫りそうな気配があるとき。


• いくつかの必要条件を示さなければ行けないのに、一部しか出てきていない。しかし、もう少し聞くと最重要と思われる必要条件が出てきそうな気配があるとき。

ですかねぇ。

気が短い私は、黙って聞き続けることは出来ないので「アドバンテージ見てるよ」と思わず言ってしまうけど、それでも全てを遮らずに、もう少し聞く耳はあるつもりなんですよ(^^;

髭剃りました

やはり、間の抜けた顔に(--;
��次に生やすことが出来るのは、いつの日か？

髭を剃ったことに伴い、
メールシグネチャ上の顔は以下のように変更になります(。。)＼バキッ☆

改善前


改善後(当社比)

大塚商会：Windows系：停電に備えてサーバーの停止をする場合の操作方法

「頼れ」る主婦から教えてもらいました。
停電に備えてサーバーの停止をする場合の操作方法

その主婦談

この程度の手順書なら、当然我々は作っていますが
あるのとないのとでは大違い（特に緊急時）

でも、もう少し濃い内容を期待したのですが・・・
コンシューマ向けならこのくらいのほうがよいのかもしれません。
# サービスだのリソースだのの確認/停止/起動手順は別途ということで。

ちなみにUnix/Linux系はこちら→サーバの計画停止前後の作業に関するご参考メモ

当面、東電のWebは見ない

本当に必要な人が、アクセス集中で見ることが出来ないんじゃないかと、
ここ数日のアクセスの遅さで感じておりますので、私は見ないようにします。

当面、見るのは砂原先生のミラーサイト。
http://hope.viops.jp/

東電のコールセンターにも、本当に確認が必要な人以外は電話しないでほしいなぁ。

このBlogサーバは60Hz地域にあります

うーん、電源周波数がこれほど重要な問題になったのは、
20年以上前に関東近辺で購入した家電類を、
15年ほど前に九州にもって帰るとき以来だな(。。)＼バキッ☆

ps.
うちの若女将は「え？電気に周波数があったの？」とのこと(--;
交流ということは知っていたようだけど、そこから先に疑問が及んでいないらしい。
確かに、今時の家電って周波数関係ないものがほとんどだもんなぁ。
発電所が復旧するまで、西日本から60Hzの送電線を延ばす...ってのは、無理か(^^;

サーバの計画停止前後の作業に関するご参考メモ

輪番停電などが予定されているので、不慣れな人(?)もサーバのシャットダウンと再起動を行う必要が出てくるだろう。
仮想化されているサーバに関してはスナップショットを取り、復帰させるなどの手が簡単だと思うけど、
物理サーバの停止／再起動前に気をつけることを自分の経験で書いておく。

＃きっちりしたシステムであれば、停止／起動に関するテストも実施しているだろうし、手順書やチェックリストもあるだろうが、
��残念ながらそうではないシステム向けの簡易なものと考えて頂きたい。

＃＃尚、計画停電も迫っており、拙速ながらエイやっと書いているので、
��＃もっと良い資料がどこかにあるはず。ありかを教えてください。リンクします。
��＃改善点があれば、教えてください。加筆／修正します。21:08書き始め。

＃＃朱記部分を追加 2011-03-14 22:45
＃＃青文字部分を若干加筆 2011-03-19 10:30

1.停止前に行うこと
　基本は「正常動作状態とは、どのような状態であるかを認識し、記録しておく」こと。

＃本来なら、各サーバの設計書／設定書に「正常状態」の定義と、起動後の「確認項目」があるだろうけど、
��設計書が見当たらない事態もままある。そんな時には、まずは下記。

(1)停止可能なサービスは何かを明確にする。
　　　そして、そのサービスを担当しているサーバを洗い出す。

• データバックアップサーバや日次でのバッチのためなど、
  一定時刻／時間帯しか動かす必要がないサーバがもしあれば、止める対象としてリスト化する。


• 逆に、止められない／止めたくないサーバもリスト化する。


• この際、上記リストに従い電源供給系統の見直しを行うかどうかを考えておく。
  　（あまり欲張って、何もかもやろうとすると破綻するので、実力との見合いで実施を検討すべし）


• サービス利用者への周知を行う。
  若干でも時間幅の余裕を持って、サービス停止の連絡を行う。
  また、その連絡の際には問い合せ先なども明示しておく。

(2)該当サーバ単体での状態の記録

• 動いているプロセス、インスタンスなどを記録する。
  Unix系であれば、psコマンドに各種オプションを付けて出力しておく。
  ps -axww > 正常時プロセス一覧.txt


• mountしているファイルシステムを記録する。
  mount > 正常時マウントファイルシステム一覧.txt


• 各ファイルシステムの空き容量なども、同時に記録しておく。
  df > 正常時ファイル使用量一覧.txt


• 開いているportも記録する。
  netstat -n　>　正常時接続状態一覧.txt
  ��で良いかな？


• ネットワークの経路も記録する。
  route -n > 正常時経路一覧.txt


• runlevelも記録する。
  runlevel > 正常時経路一覧.txt


• 仮想サーバを動かしているなら、それらの状態も記録する。


• Active-Standbyなど、冗長構成になっている場合は、
  どちらのサーバが運用系、どちらのサーバが待機系であるかをラベルなどで明示しておく。
  (紙のラベルなど、アナログ的なものの方がこういう時は良かったりする）


• もちろん、可能であればオフラインメディア（テープやDVD、外付けHDDなど)に
  データバックアップを行っておく。

(3)他のサーバへのサービスを記録

• nfsやDNS、RDBMSなど、他のサーバへのサービスを提供していることが分かったら、どのサーバへ提供してるかを、記録。
  ��複数サーバで(2)の手順を行い、つきあわせれば分かるはず。


• 他のサーバへサービス提供をしている場合の、依存関係を整理する。
  つまり、あるサーバの正常動作を行うのに前提となる別のサーバは何かを書き起こす。


• 上記をもとに、電源停止と電源投入の手順（サーバの順序）を書き起こす。
  この際、一般には、停止順序と起動順序は全く逆になる。
  ��停止順がA→B→C→Dなら、起動はD→C→B→Aになるはず)


• 再起動時に、他のサーバへのサービスを行っているプロセス／インスタンスなど
  確認すべきものを書き起こす。出来るだけチェックリスト化する。
  ��この場合のチェックリストとは、計画書兼報告書となるようなもの...と言って分かるかなぁ)


• 各種資料を、なるべく紙で出力しておくこと。
  　チェックリストや手順書はもちろん、参照すべき資料を探しておく。
  　電子データは、参照できなくなることが多い。Ecoではないだろうけど、必要。

2.停止作業
基本は「計画していない思いつき作業は絶対に行わない」
「計画していない事象が発生したら、深呼吸して、連絡取れる有識者に相談して対応を決める」です。
(1)手順に従い、粛々と停止する。

• サービス利用側サーバから正常にシャットダウンさせて行く。


• 前者サーバが停止してることを確認し、サービス提供側サーバをシャットダウンさせる。
  一般に、DBサーバやDNSサーバなどを最後に落とすと思われる。

(2)停止状態の確認

• 正常に停止できていることの確認。


• 停電時に備えた照明などの準備。


• 再起動作業時に必要な道具類の準備。
  普段必要ないディスプレイやキーボード、特殊なコンソールケーブルなど、取り揃えておく。

３.停止中に行うこと
これも基本は「計画していない思いつき作業は絶対に行わない」です。
(1)サーバ停止時にしか出来ないことを実施

• 掃除する
  充電式掃除機などでのゴミ取りや、FAN／フィルタの掃除や交換など。
  また、電源コンセントの差し込み口周辺のホコリなどは吸い取っておく。
  さらに可能なら、未使用の差し込み口には、養生用テープ(粘着力が弱めでベタつきにくい）を貼り、予期せぬ電源ショートなどを未然に防止する。


• 配線の張り替えや部品交換などを行う
  UPSとサーバの組み合わせの変更や絡み合ったネットワークケーブルの張り直しなど。
  尚、一度に全部のケーブルを外すと大変なことになるので、計画していないことはやらないこと。
  場合によっては、HDDなど寿命部品の交換も行えるかもしれない。
  ��これも、事前に計画が必須ですけど）


• 滅多に無いと思いますが、復電時の電圧変動などで
  機器にダメージが発生しないように、ブレーカや配電盤、元となっているコンセントなどは
  抜いておくと良いかも。

(2)再起動に向けたリソースの確保

• まずは、再起動時に必要な人的リソースの確保
  誰でも出来る訳ではない。連絡がつかないかもしれない。交通手段が確保できないかもしれない。
  事前に、誰にいつ来てもらうかを計画する。また、予備の人も含めて計画しておく。
  さらに、待機してもらう人／当日連絡を取る必要がある人にその旨お願いしておく。
  ��大災害の際に、連絡を取ることが困難な場合は、あらかじめ来てもらうしか無いんだけど）


• 再起動時の各担当者／関係者にて、机上リハーサルを行う。
  チェックリスト／手順書に、各担当者名を書いて、時系列に従い、誰が何をやるか（実施者）を確認する。
  どのような道具を使うかも、道具の確認も含めて行う。
  ��ケーブル長が短くて届かないなど、しょぼい事態もあり得るので、細かく見てね）


• 上記の机上リハーサル時に、複数名で確認すべきチェックポイントが何かを決める。
  そのチェックポイントでの実施者に加えて、確認者を明確にする。


• 正常状態の記録をもとに、チェックポイントの抜け漏れを見直す。


• 直前確認のための一覧表を作成する。


• 寝る。または充分休養を取る。
  来るべき大作業に備えて、気力／体力／知力のリフレッシュをはかる。
  大事なリソースです＞体力。

４.再起動時に行うこと
これまた、基本は「計画していない思いつき作業は絶対に行わない」です。
(1)必要なリソースがそろっていることの直前確認

• 居るべき人が居るか？道具はそろっているか？
  事前に作成した一覧表をもとに確認。


• 計画書／チェックリストはあるか？

(2)安定した電源が来ていることの確認

• 再停電の可能性が無いか、発表されている停電予定などとつきあわせて確認。


• 計画が変更になっていないか、一時ソースや信頼できる情報源などで確認する。


• テスターなどで、電源電圧を確認する。
  (停電／復電時に限らず、電源電圧の確認は本当は必要。安価なやつでも買っておけ）
  ブレーカや配電盤で電源を落としている場合は、そこで測定するべし。
  測定の際は、出来れば電工用のゴム手袋などを着用し、感電には充分注意すべし。

(3)手順書に従ったサーバの起動と確認

• 手順に従い、一度に全部のサーバの電源を入れないこと。
  突入電流を避けることと、サーバ間の依存関係を満たすように、順に入れること。
  尚、電源投入順序だけ満たしてもダメで、依存するプロセス／サービス／インスタンスの
  順序性を満たすことが必要。


• 内蔵のRTC(時計)用の電池が切れていたりすると、
  時刻が大きくずれることがあります。時刻の確認を行いましょう。ずれていたら設定しましょう。
  (ネットワーク上のntpサーバが落ちているかもしれません。まずは自力で正しく動くように設定を)

(4)サービスの確認

• サーバルーム内からの動作確認はもちろん、外部ネットワークからの確認も行う。


• logやプロセスも一定時間確認を継続する。可能なら、エンドユーザにも確認してもらう。

5.正常動作確認後に行うこと
ここでの基本は「如何に有益な教訓を記録するか」です。
本当は、じっくり時間をかけて行うべき話が多いのでしょうけど、
頻繁に計画停電があるのなら、手順／戦術ベースの教訓は迅速に整理し、反映すべき。
(1)反省事項の整理

• 予定外の事象が発生した場合には、何が起きたのか、なぜ起きたのか、次にどうすべきかを議論する。
  この際、「誰が悪い」というような犯人探しを行うのではなく、「何が悪い」「次に同じことをするならどうする」という行動の改善観点で行う。


• 人間なのでミスもある。
  ミスを防ぐための「しつけ」と「しかけ」は何が必要なのかを議論したい。
  ＃将来に向けての成長を促す「しつけ（教育）」も必要なのだが、
  ��直近の次回作業に向けては、失敗事例の関係者による共有と、
  ��それをふまえた議論による再発防止の「しかけ(ツールやワークシート、体制見直しなど)」検討をサクサク行う。

(2)手順書や道具へのフィードバック

• 反省事項の整理をもとに、手順書／チェックリスト／道具見直しを行う。

(3)飲む

• 安定稼働が確認できて、一息ついたら、ビール一杯ぐらい飲んでもバチは当たらんだろう。
  停電でぬるくなったビールもまた一興。
  ��その昔、フィリピンに行った時は、ぬるいビールに氷を浮かべて飲みましたが、
  ��なかなか乙なものだった。

まずは、ここでいったんリリース。気がつくと２時間以上かかってた。
途中、他のこともしながらとはいえ、もう少し筆が速いと良いなぁ。自戒。23:25

ディザスタリカバリーに思う

いわゆるDRとしての遠隔地データバックアップとして、
顧客データだの取引データだのって言う話をすることがあります。

しかし、今回のような激甚災害時には、誰がどこに住んでいて、
今どうなっているのか？ってのも大事だなぁ。

��役場丸ごと流されて、安否確認リストすら作れないというニュースを見るにつけ。

自治体の壁を越えて、遠隔地(500km以上離れていて、電源種別(50/60Hz)も別のところだとかなり良いのかも。

福島第一原発１号機に関する枝野官房長記者会見

枝野官房長の記者会見をまとめると、下記かな？
・爆発は発生した。建屋内の水素に引火し、建屋が爆発した。
・東電によると、格納容器は破損していない。
・現時点では、放射性物質が大量に漏れだす状況ではない。
・外部で計測されている放射能は爆発当時よりも低く推移している。
・格納炉の破損などによる今後の被害拡大を防ぐため、海水による冷却とホウ酸水による再臨界防止を行う。

長期視点というよりも、短期的に最悪の事態になることを防ぐために、
今出来ることのベストを尽くしているんだろうなぁ。

ちょっと修正。21:06

短期的な取り組みがダメというつもりではありません。
緊急時には緊急時に適した行いがあると思うから。21:23

頑張る人に幸運あれ！

いろんなところで自分を顧みずに働いている人たちがいる。
遠くから言えることは、Good Luck!
その努力が報われてほしい。

特に修羅場の技術者達のことは、他人事とは思えない。

激甚

被害の大きさに驚く。
プロとしてやれることが無いかと考える。
誰が今何をすべきか。

これだけ大きな災害になった時に、同様のニュース映像を繰り返すのではなく、
各報道機関は役割分担をすべきではないだろうか？
��NHKの総合と教育は分担しているが。
同じ情報に群がるのは、とにかくボールに集まるようなガキのサッカーと同様で、ダメだと思う。

原発も心配だ。

被災お見舞い

今現在までに分かっている情報では、私の身の回りの方々は、
幸い無事のようです。
これからも大変でしょうけど、まずは安全第一で。

夜にかかるので、明かりなどの確保も必要だな。
福岡の地震直後は色々準備していたけど、
ちょっと緩んでいるので我が家も再点検。

餃子の王将

原四つ角に餃子の王将原店が出来ているのを発見して行ってみた。
��学生時代から安くてカロリーとボリュームがある王将にはお世話になったので、懐かしくて。

その昔良く行った箱崎の王将と比べると大型の店舗でびっくりした。
真新しいお店は満員で、待ち行列に入るほど。
待っている間に、何ともなしに働いている人を見ていると、面白いことに気がついた。
メインで料理を作っている人は、ひっきりなしに作っている。稼働率１００％でフル回転である。
配膳をするバイトらしき若手は、料理が出来るまでじっと待っているものもいる。稼働率は低い。
配膳も、一人でお盆一つだけ持っている者もいれば、両手に二つ抱えて持っている人もいる。
生産性は、倍半分違う。
テーブルの空きを見ているチーフらしき人は、近くで注文用の「ピンポン」が押されても見にも行かない。それはそれで良いと思うが、指示ぐらいしても良かろうにとも思った。
厨房内の配置も、もう少し工夫すれば効率が上がるような気がするが、具体的にどうすれば良いのかは素人には分からなかった(^^;

なんだか、自分を省みて「人をどう活かす（生かす）かで、お客の満足感も、売り上げも変わるんだろうなぁ...」などと、腹が減ったのも忘れて見入ってしまった。

まぁ、餃子は懐かしい王将の餃子の味だったし、天津飯も王将の味だった。
ただ、唐揚げ用の胡椒がテーブルに見当たらなかったような気がしたのは気のせいか？
また、定食類が減っていたのはちょっと残念。
回鍋肉定食とか、レバニラ定食など、各種定食をローテーションさせて食べていた学生時代。

ps.
王将のWebはレスポンスが悪いなぁ。
サーバ強化してください(^^;

散髪

いつもの床屋さん。
早めに行ってみたところ、待ち時間なし。
大将にやってもらったが、毎度、落ちる髪の量が減っているのが寂しい(^^;

多久ゴルフ倶楽部

1年半ぶりにリベンジに出かけたが、返り討ちにあった(--;

天気もメンバーも最高、出だしのティーショットも最高だったんだけどなぁ。
また、いつか...。