プロとアマの違い

これは良い訓示。
宴の支度 (3) 小さな変化からすべては始まる。「プロ」と「アマ」の１３の違い

このサイトでは、以下の２つを対比させて表示させているので、
非常にわかりやすいです。

「アマの考える習慣」　　　　　　　　　　　　　　

１、現状に甘える
２、ぐちっぽい
３、目標が漠然
４、自分の傷つく事は回避
５、経験に生きる
６、不信が先にある
７、気まぐれ
８、時間の観念がない
９、失敗を恐れる
１０、享楽的資金優先
１１、途中で投げ出す
１２、できない言い訳が口にでる
１３、他人のシナリオが気になる

「プロの考える習慣」

１、人間的成長を求め続ける
２、自信と誇り
３、常に明確な目標を指向
４、他人の幸福に役立つ喜び
５、可能性に挑戦しつづける
６、思い信じこむ事ができる
７、自己訓練を習慣化
８、時間を有効に組織化
９、成功し続ける
１０、自己投資を続ける
１１、使命を持つ
１２、できる方法を考える
１３、自分のシナリオを書く

人により、ペースは様々なので
私はこのプロの習慣を行い、
自己研鑽の意思をいつまで持ち続けることができるかが大事だと思います。

ようは、ウサギとカメの話です。

PHPのセッション維持管理

これがすごいタメになった。
第５回：HTTPセッションの永続性確保

HTTPのセッション情報をDBに保存すると、
Webサーバが複数あった場合にセッションが切れることがないのは理解していた。

しかし、セッション管理用のDBを設け、それが複数ある場合、
どのセッションDBにアクセスすればいいかわからなくなってしまう。

そこを、セッションIDからアクセスするDB名を算出するという手法に目からウロコ！

たしかに、セッションIDは維持管理する必要のある間は固定なので
これなら、アクセスするDBを間違わずに済む！！

交渉テクニック

日本を値切り倒せ！カル○ールのバイヤーの必殺マニュアル

こういうハッタリを使って交渉するのは苦手。
普通にやってたら、得られないはずの利益を
相手からひっぱり出すことが出来るのはすごいと思います。

商社の人とか、グローバルで交渉する人には必須のテクニックなんですかね。
自分が使うかどうかはともかくとして、
相手は使ってくるものとして、挑まないとコロっとやられてしまいそうです。

感想文：ホンネを誰にも読ませない超心理術

仕事をする上での実践的な行動心理学ノウハウの本。

ものごとはケースバイケースなので、
本書に書かれていることをそのまま実践するだけではケガをしそうだが、
確かにそうだなと、ナットクできる内容が多かった。

ウソをつく時、人間は頭をかいたり、髪の毛を触ったり
服をつまんだりなど、体や物をさわるクセがあります。

ウソをつくわけでもないのに人と話すときに、
そのような手クセをしてしまう人は注意した方がいいでしょう。

実際、自分が話していて相手がそういう態度を取ることはあると思います。

そういう場合、相手がウソをついているワケではなく、
話に興味がないことが多いですよね。

ので、そう思われないためにも、目につきやすいクセは無くした方がいい。
方言をやめて、標準語で話そうとするみたいな感じで矯正するといいかも。

全体を通して非常に読みやすくわかりやすい
胡散臭い本だ←著者があとがきで本書をそう表現しています。

感想文：Webアプリセキュリティ対策入門

PHPを使った実践的なWebアプリケーションのセキュリティ対策本。

だが、内容がイマイチ。
読者の期待に応えられない感がある。
ちょっと冗長なところが目につきます。

「入門」という言葉が表すとおり、
本当にWebアプリへの攻撃手法ってどんなのがあるの？
という初心者向けの本である。

ただ、あまり内容を熟読しようとしてはいけない。
サラっと、ふ～ん、程度に読み流すのが一番だ。

セキュリティを高めた掲示板のサンプルプログラムが
掲載されているのが一番のポイント。

もう１つは、セキュリティに目を向けた
PHPの設定項目が一覧になっているのがイイ。

逆に一番、本書のマズイ点は誤字がありすぎること。
本当によく目につく。
出版前にチェックしてないのかと疑えるほどに。

付録として、言語「PHP」の仕様の説明が記載されているのだが、
この本でPHPの言語の勉強をしたいと思う人はいるのだろうか。
ホントに入門者向けだ。

その意味でタイトルは間違っていない。

■参考リンク
Amazon

高速な次世代Webブラウザが広げるWebの未来

以下のサイトによると次世代Webブラウザは
描画速度の高速化が１つのポイントとなっている。

SaaSに追い風、桁違いに速い次世代Webブラウザたち

FireFox3,Safari,IE8 betaが特に顕著なようだ。
このスピードアップは体感的に、アナログ回線からADSLになった時と同レベルではないだろうか。

これがWebに何をもたらすのか。

Web2.0がもてはやされた時に登場したフルAjaxのWebアプリケーションに
多大な恩恵をもたらす。

Officeアプリ(例：Googleスプレッドシート),Webメール(例：Zimbra),WebOS(例：StartForce)
これらの普及を後押しするのではないだろうか。

個人的にはWebOSが実用レベルにまで行くと楽しそうだ。
理由はインターネットに繋がれば、いつでも自分のデスクトップ環境が使えるから。
メールはGmailがあるが、ブラウザもお気に入りとかあるので、
Webアプリのブラウザなんてのがあると便利かも。

インターネットが普及するために、定額のADSLが一役かったように、
普及するためには、ストレスのないレスポンスが必要。

ブラウザのシェアトップのIEが高速になるのはIE8であり、
上記で上げた中では一番リリースされるのが遅い。
だから実際に恩恵がもたらされるのはまだ1年以上はかかるだろう。

セキュリティについてはNGNが解決してくれるのだろうか。
NGN…実現するのかな。どうだろう。

アップロードファイルのリカバリ問題

サーバにディスク障害が発生した場合、
ＤＢのリカバリはロールフォワードなどして、
障害発生の直前まで復旧できる。

しかし、アップロードファイルはどうだろうか？

アップロードされたファイルをディスクで管理している場合、
そのディスクが壊れた場合、一体どこまで復旧できますか？

簡単な日次バックアップしかしていないならば、
ＤＢのように障害発生直前まで復旧することはできない。
これではデータの不整合が発生してしまう。

■解決方法
ワードや画像ファイルなどのバイナリファイルもＤＢで管理すれば
通常のデータと同レベルに復旧可能だ。

アプリケーションがこれに対応していればいいが、
対応していない場合はどうすればいいのだろう？
（明確な答えは持ち合わせていません）

また、ＤＢに巨大なファイルを１カラムに保存するのは大丈夫なの？
（私はやったことがない）

■代替手段？
rsyncコマンドで差分バックアップをすることで
一応、日次バックアップよりは短い間隔で実行し、運用可能と思われる。
しかし、以下のサイトによるとバックアップの負荷も相当なもののようだ。
http://www.hpc-technologies.co.jp/solution/storagetech-rsync.html

小規模サイトであれば、rsyncでも問題ないのだろうが、
中大規模、また長年使っていると、どんどんデータは溜まっていく。
いつか、rsyncがボトルネックになる日が来てしまうことだろう。

やはり、アップロードファイルもＤＢに保存すべきなのだろうか。
それとも運用で、アップロードファイルは日次バックアップのみ、
としてしまうのがいいのか。

ケースバイケースかもしれないが、悩みどころだ。

SaaSについて考える その２（各社動向と限界）

KDDI、富士通、Microsoft、SAP、Oracleなど
大手がSaaSに取り組んでいる。

最近のニュースでは、NECもSaaS事業に着手したようだ。
http://www.itmedia.co.jp/news/articles/0804/01/news052.html

■SaaSの弱点
ソフトウェア開発がまだ製造業のようなレベルに達していないように、
ＩＴの活用・利用についても標準的な指針が
確立されておらず、多種多様である。
果たして、日本のユーザが標準化されたＩＴを活用できるだろうか？
日本のユーザはカスタマイズが当然の文化である。
業務をシステム側に合わせるという
今まで苦手としてきたことをやらなければならない。
これが普及のネックとなりそうだ。

プログラムの改修なしに、
ブラウザからのカスタマイズ操作で
どこまで対応できるかがカギとなるのではないだろうか。

■費用の支払い方法
従来は一括でドンと大きな費用を支払って、
何年かを通じて原価償却してきた。
SaaSは１ユーザの月額料金がいくらというタイプ。
家を買うのと、アパートを借りる賃貸ぐらい違う。
何が言いたいかというと、お金を払っても、システムは自分のものにならないのだ。
従来とは大きく異なる点だろう。

■一極集中の問題。
SaaSは多くの企業で１つのシステムを利用するということになる。
つまり、１つの企業に対してのみ有効なカスタマイズは不可能となる。
それゆえ、全体で有益となるものしか取り入れることが出来ない。

これに対して、セールスフォースはAppExchangeというものがあり、
ユーザは自由に必要な機能をインストールすることが可能。
自社に必要な機能を作って、それをインストールすればよいが、
アプリのコアに関わるような、「それは仕様です」に関わるような
カスタマイズはやはり対応できないだろう。

また、万が一、SaaSのシステムがダウンすると
ユーザ全員に影響が及ぶという問題が一極集中による大きな欠点である。
SaaS事業者が絶対に避けたい問題だ。

■そしてなにより価格
SaaSは中小企業を対象としていると言われている。
自然と低価格にならざるを得ない。

しかし、SaaSはインフラを事業者が一括面倒みますよ方式なので
インフラが貧弱だとサービス自体がしょぼいことになってしまう。

また、薄利多売にならざるを得ない。

業界的に、将来的に、この価格バランスは大丈夫なのだろうか？
利益はちゃんと確保できるのか？

SaaSが一時の流行で終わるかどうか。今後の動向に注目だ。