20歳のときに知っておきたかったこと

20歳のときに知っておきたかったこと スタンフォード大学集中講義/ティナ・シーリグ

￥1,470

Amazon.co.jp

これを読んでうらやましいと思ったことが2つあって、1つ目はアイデアの創出の仕方を大学の授業として学ぶことが出来るんだという点。

私は、情報系の大学を出ましたけど大学で学んだことは情報処理の基礎と高校の時から少しグレードを上げたぐらいの一般教養ぐらいです。

過去に幾度と無く個性を磨けとは言われてきましたが、アイデアの出し方なんてものを学ぶ機会はありませんし、自分自身のアイデアを披露することも比べることもありませんでした。

むしろそういうことは幼稚園ぐらいまでの方が授業の中でも家庭の中でも学ぶことが多かったかもしれません。

そして、狭い頭の中だけで自分は他人よりアイデア力はあるんだろうとか勘違いして、就職活動の面接でも必死に独自性をアピールしたりしていました。他人も同じようなことを言っていることさえも知らずに。

他人と比べるのは単にテストの点数ぐらいで、それが社会に出て意味が出ることはないってことはありませんし、むしろその基礎となる知識をどう活用するかという点はグレーゾーンとして自分で考えましょうみたいな教育が一般化されてるんじゃないかなと思ったりします。

別に学校での勉強そのものを否定しているわけじゃなくて、そういったものは必要で社会人になってからもっと勉強しておけばよかったなんて思う人は多々いるでしょうし、ただその勉強そのものが社会に出てなんに役立つかがわかってなかったなと思うわけです。

他人の頭の中を覗いてみる機会があれば、自分の頭の中にあるものがなんの役に立つかって事を理解する手助けになるのがわかったりもするんですけど、そういった機会があまり多くなかったなと。

2つ目は、人との接し方や付き合い方や生き方そのものの話で、こういったことって頭で理解していても体験しないとなかなか体現できないんですよね。

この本に書かれている一部のことは、過去に親や先生とかにも言われたことがあったりするんですけど、やはりそれも一度自分で失敗をしてみないとなかなか「やっぱりそうだったんだ」と思えないわけで。

そういう意味でも20歳のときに知っておきたかったことと、どうしても過去形になってしまったりするんでしょうけど、そこにもっと早く気づいておきたかったなと。

社会に出ての人付き合いは、学生の頃だった気の合う友達のみの環境とは大きく異なりますから、そういった人たちと1つの仕事を遂行していくためにはまるで違う感性が必要になってきたりするわけです。

当然、好き・嫌いだけで職場の人間関係を決めることは出来ませんし、社会に出ての経験をつめば積むほど社会って狭いんだなと感じたりもします。

若いうちはそういったことに関心を示さなかったりし、未来にどれほどの影響を与えるかなんて気にかけもしないことが多いんですけど、それは後々しっぺ返しを食らうこともまた多いわけです。

なので、文字通り20歳のときに出会いたかった本だったなと思ったりしたわけです。

目次

第1章 スタンフォードの学生売ります
自分の殻を破ろう

第2章 常識破りのサーカス
みんなの悩みをチャンスに変えろ

第3章 ビキニを着るか、さもなくば死か
ルールは破られるためにある

第4章 財布を取り出してください
機が熟すことなどない

第5章 シリコンバレーの強さの秘密
早く、何度も失敗せよ

第6章 絶対いやだ！工学なんて女がするもんだ
無用なキャリア・アドバイス

第7章 レモネードがヘリコプターに化ける
幸運は自分で呼び込むもの

第8章 矢の周りに的を描く
自己流から抜け出そう

第9章 これ、試験に出ますか？
及第点ではなく最高を目指せ

第10章 実験的な作品
新しい目で世界を見つめてみよう

関連記事

イノベーション・オブ・ライフ ハーバード・ビジネススクールを巣立つ君たちへ

ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図〈2025〉

小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則

30代を後悔しない50のリスト 1万人の失敗談からわかった人生の法則

9割がバイトでも最高のスタッフに育つ ディズニーの教え方

ドラッカー 時代を超える言葉―洞察力を鍛える160の英知

BOM付きUTF-8のPHPファイルからBOMだけを一度に削除するスクリプト

あまりUTF-8の環境でPHPを動かすということがなかったのではまったんですが、BOM（Byte Order Mark）ありのUTF-8で保存したPHPって動作に問題が出るんですね・・・。

要はBOMの先頭バイトが邪魔をしてPHPスクリプトと認識してくれなかったり、文字化けを起すような弊害が出てきます。

じゃあ、事前にBOM付きのUTF-8をBOMなしのUTF-8に変換すればいいとiconvコマンドで変換しようとしても

$ iconv -f UTF-8 -t EUC-JP hoge.php
iconv: 位置 0 で不正な入力シーケンスがありました

と、iconvコマンドはBOM付きのUTF-8に対応していない模様・・・。

nkfコマンドもうまくBOMを取り除くということが出来ませんでした。

vimコマンドでは

:set nobomb

として保存することでBOMを取り除くことができます。

ただし、大量にBOM付きのPHPコードが合った場合、ちまちまやってられないので、BOMを取り除くPHPスクリプトを書いてみました。

UTF-8（BOMあり）からBOMだけを取り除くPHPスクリプト

ファイルの先頭に来るBOMコードは0xEFBBBFとなるため、該当ファイルからそれを除去して同じパス上に保存するという動作をします。

<?php

$target_dir = "/var/www/html/";

if (is_dir($target_dir)) {
    if ($dh = opendir($target_dir)) {
        while (($file = readdir($dh)) !== false) {
            $path_parts = pathinfo($file);
// 拡張子がphpのファイルのみが対象
            if ($file != '.' && $file != '..' && ($path_parts['extension'] == 'php')) {
                $path = $target_dir . $file;

// kccコマンドでUTF-8のファイルかどうか判断
                $cmd = `kcc -c $path`;
                list($fname, $enc) = explode(':', $cmd);

                if (trim($enc) == 'data') {
                    $contents = file_get_contents($path);

// BOMありの場合
                    if (preg_match("/^efbbbf/", bin2hex($contents[0] . $contents[1] . $contents[2])) === 1) {

// 先頭3バイトのBOMコードを除去して同名で保存
                        $contents = substr($contents, 3);
                        file_put_contents($path, $contents);
                   }
                }
            }
        }closedir($dh);
    }
}

対象は拡張子が.phpのファイルのみとしていますが、違えばお好みで変更できます。

また、kccコマンドでUTF-8のファイルかどうか判別（厳密にkccコマンドではUTF-8コードかを判別できず、結果はdataと返ってきます）をしていますが、全てがBOM付きUTF-8のファイルだということであれば、特にその条件判定は必要ないかもしれません。

ツールを使ってPHPファイルを保存した場合、意図しないところで勝手にBOMが挿入されてたりもするのですが、大量に保存してしまったPHPファイルを再度保存しなおすのは手間となるので、こういったスクリプトで一気に除去してしまえば便利かもしれません。

[PR]DMM mobileデビュー！基本料金￥０キャンペーン実施中！

[PR]キャンペーン開催中！パソコンを買替えるならFRONTIER

[PR]格安固定IPが【５分で発行】＋【初期無料】＋【２ヶ月無料体験】

関連記事

クラスファイルのオートローダーを実装する

PHPのセッションアダプションによって任意のセッションIDが受入れられる

[PHP] pChartの使い方 - 棒グラフとレーダーチャートを描いてみる

ノンプログラミングでも利用可能！PHPで多様なグラフを作れるpChart

ApacheのプロセスがどのPHPプログラムの処理をしているか調べる方法

レベル3までの文字コード入門 UTF-8の冗長なエンコードの問題へ続く道

[PHP] inotify関数を使ってログを監視するスクリプトを作ろう

NFSマウントした領域内でPHPのsession_startを実行すると異様に重い件

PHPでブラウザのキャッシュを利用させる検証

PHPのプログラムをデーモンとして動かしてくれるPEAR::System_Daemon

NFSマウントした領域内でPHPのsession_startを実行すると異様に重い件

PHPネタと思いきやLinuxサーバーネタで。

NFSマウントしたディレクトリ領域内でPHPのsession_startを実行すると30秒ほど待ち時間が発生するという状況が発生しました。

今回現象が出た環境はRedHat Enterprise Linux5で、ストレージ内のコンテンツ領域のディレクトリをマウントしています。

NFSの設定やマウントオプションが問題なのかなと思い、原因を調査してみました。

Linux上のflockの仕様が変わった？

結論から書くと、クライアント（NFSマウントする）側でnfslockデーモンを起動してあげることで状況は改善しました。

今回の現象は、そもそもNFSサーバー上のコンテンツ書き込みが遅いということではなかったため（vimで書き込んだり、touchコマンドでファイル作成しても一瞬で終わる）、セッションファイルを作成してそれをロックするのに時間がかかっているのかなと思い、ファイルロック周りの仕様を調べていました。

セッションファイルの出力先も下記のようにNFSマウントしているディレクトリ内に出力するようにしています。

session.save_path = "/path/to/nfs/dir"

session_startに限らず、PHPでファイルロックを取得するflock 関数を使っても同様に異常に重くなるという現象が発生します。

また、PHPのログばかりに気を取られていましたが、syslogに下記のようなエラーも出力されていました。

Feb  1 21:10:31 hoge kernel: statd: server localhost not responding, timed out
Feb  1 21:10:31 hoge kernel: lockd: cannot monitor 192.168.0.100
Feb  1 21:10:31 hoge kernel: lockd: failed to monitor 192.168.0.100

RHEL3の環境では同様のストレージをNFSマウントして使ってみても今回の現象は発生せず、そもそもnflockデーモンも起動していませんでした。

なので、NFS自体の設定やオプションが悪いのかなと思いかなりはまってしまいました。

で、そのflockについて調べまわっていたところ、下記の記事を見つけました。

シェルスクリプトでflock ＠ Stray Penguin

確かにRHEL5からflockがコマンドレベルで使えるようになっていますが、RHEL3では存在していません。

それがどうnfslockと絡んでるんだ、という点までについては調べきれてないのですが、ファイルロックの取得の仕様の変更により、NFS上のファイルロックの取得の仕様も変わったのかもしれません。

nfslockも内部的にはrpc.lockdとrpc.statdを利用していて、先のkernelのエラーのようにrpc.statdへのレスポンスが無くてタイムアウトしてますから、NFSへのファイルロックをkernelそのものから発行するんじゃなくて個々のデーモンに実装が移ったんでしょうかね。詳細わかりませんけど。

その他の回避方法

回避方法も何もnfslockデーモンを起動するだけなので、あまりその他のワークアラウンドを試す必要もないかと思いますが、調査していく中で3つこの現象を発生させない方法を見つけました。

1つ目は、session.save_pathをNFS上にはないディレクトリを指定してセッションを利用するというもの。

NFS上のファイルロックの取得が出来ないために今回の現象が発生していたので、その他のファイルシステム上であれば特に問題はでません。

ただし、今回のsession_start以外にも同様に内部的にファイルロックを取得しようとする挙動をする関数があるかもしれませんし、アプリケーションの仕様でファイルロックを用いるというものがあればこの回避方法は役に立たないかもしれません。

また、そもそもセッションファイルをNFS上に保存するというのは、複数台のアプリケーションサーバー構成の中でもセッションを維持させ続けるための対策として取られてたりもするので、ローカルディスクにセッションファイルを保存する事でその要件を満たせなくなる可能性は出てきます。

2つ目は、セッション利用時の読み込みや保存のロジックをユーザー定義してしまうというもの。

PHPでは、session_set_save_handler によりセッション関数を利用する際の各挙動をユーザー側で定義することができます。

ちょうどマニュアルにもサンプルが掲載されていますが、flockしない版のsession_startと同等の機能を作ってしまうことで問題を回避することも出来ます。

ただし、これもフレームワークを使っているなど、セッションの挙動をその他のシステムが握ってしまっているような環境の場合、思ったより適用することが複雑になったり、反って保守しにくい環境を生み出すことになってしまうかもしれません。

また、こちらもNFS上でファイルロックをするという仕様を満たしてはいないことになりますが。

3つ目も似たようにファイルロックをしないというものですが、NFSマウント時に下記のようにオプションを指定することでロックをしない仕様でNFSマウントをすることができます。

# mount -o nolock /path/to/nfsdir

こちらもNFS上でファイルロックをしないので要件を満たせていない場合がありますが。

後になって調べてみたら、結構似たような状況のことが下記のスレッドにまとまっていました。

【NFS】Network File System ＠ パソコン情報局

NFS上のファイルロックに関する信頼性の低さなども語られていますけど、複数台のサーバーに対して同一のコンテンツを補完しておきたいなんて場合は、NFSサーバーがあったほうが楽なんですよね。。。

別にNFSである必要は無いんですけど、簡易的な対策としてはポピュラーなのかなと個人的に思ったりします。

まぁ、システム全体の信頼性をあげるために、高価なディスク装置を用意するなど、コスト面では安価となるとは言えませんけどね。

[PR]エンジニアに特化！エンジニア専門の転職支援は「メイテックネクスト」

[PR]固定IPが【業界最安値クラス】＋【５分で発行】＋【２ヶ月無料体験】

[PR]アイルのホスティングサービス　月額1,995円～（税込）

関連記事

PHPをソースからインストールするときにopcacheを有効にできない

PHPのセッションアダプションによって任意のセッションIDが受入れられる

ApacheのプロセスがどのPHPプログラムの処理をしているか調べる方法

BOM付きUTF-8のPHPファイルからBOMだけを一度に削除するスクリプト

PHPでブラウザのキャッシュを利用させる検証

ソケット通信でサーバーの状況を監視する

[Linux] ファイルを暗号化する方法あれこれ

inotifyを使ってファイルやディレクトリに起きたイベントを簡単に監視する

Linuxサーバー上でデータ操作に便利な10のコマンド

サーバー管理で知っておきたいコマンドあれこれ。 - sysreport編 -