CakePHPでリダイレクトする際のお作法

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

Linux上でファイルを削除してしまった際にさっくり復活できるextundelete

Linux OSユーザーの色々なリソースを制限する

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

共有ユーザー環境でIPアドレスごとにhistoryコマンドを使い分ける

簡単にファイル比較ができるdiffコマンドの使い方

不要なファイルやディレクトリを削除できる「tmpwatch」コマンド

「とりあえずこれを優先度上げてやっといて」と上から言われたことは誰しもあるのではないでしょうか。

冷静に考えればその目的や効果というものがはっきりしないものの、取りあえず言われたからやらないと・・・と必死になって作り上げたものの大して使われずに終わるという経験も合わせてあるのではないかと思います。

こういうの無茶振りって言うんでしょうけど、もっと酷いものとして明らかに失敗することが目に見えているものやその場の思い付きを押し付けられることがあったりします。

最終的に無駄になるわけですから、モチベーションもかけられませんし案の定そうなった場合の徒労感が半端無いわけです。

要は上から仕事を降られて対応したものの結局は無駄に終わるというもので、こういったものは時間や労力の無駄というだけでなく、現場を混乱させ未来への投資機会を奪う結果にもなったりします。

現場の人間にとっては戦々恐々で、報告のたびに何言われるんだろうという不安に駆られたり、言われたところで「絶対思いつきだな」と思うものや「言いたいだけだろ」という不満も持つことになったりします。

無駄振りの怖さ

無駄振りされたものは最終的に何も残りません。

無茶振りでも何かしらの成果物ができたり、新たなサービスや仕組みが生まれたりすれば後で落ち着いたときに達成感というものも得られるかもしれませんが、無駄振りはその場の思いつきでしかなく、達成したところでその個人だけが満足するという結果しか得られません。

また、思い付きであるが故に本人にも明確なビジョンを持っていないことが多く、そういうことを言い出す人にはそれなりに社会的権威や地位があったりして、それが邪魔して周りも聞くに聞けない状況になっていたりします。

言われたことの情報が少なすぎるために何を具体化すればいいのかわからず目的や効果、ゴールが見えないマイルストンの中でタスクを試行錯誤するしかなく仕事がとても非効率となったりします。

何とか形として成果を見せれば満足はしてくれるものの、それ以降の運用やブラッシュアップすることに当人の興味は薄く、言ったことはすぐ忘れられたりします。

そして形だけ出来上がったものが当然うまく回るわけも無くそのうち形骸化してすぐに仕組みは廃れていくわけですが、怖いのは本人がその頃に再度似たような仕組みを作るアイデアを持ち出したりするわけです。

「あれがうまくいかなかったのはこういう理由であるから、今度はこうしよう」みたいな。

延々と作っては壊れるのループでしかなく、アイデアの種としてはよくてもそのアイデアが昇華していくことがないわけです。

ここには言った本人と現場との間に大きなギャップがあります。

その人に先見の明があるのであれば、結果として大きなものを生み出すかもしれませんが、こういったことをする人は大抵何かが抜けているように見えます。

サービスがよくても運用が考えられていなかったり、仕組みがよくても展開方法に問題があったり、アイデアがよくても実装に問題があったり。

そういったものを見ると現場としては少し考えただけでその仕組みがすぐに破綻することが目に見えてしまったりします。

現場が相当がんばり屋さんだったらどうにか軌道に乗せる事はできるかもしれませんが、果たしてそれをうまく回したとしても意味があるのかどうかは疑問で、一番怖いのはその一言によって生まれてしまった業務が現場に根付いてしまい多大な工数を浪費するだけでなく、それによって新しいことへの投資ができなくなってしまうことだったりします。

無駄振りへの対処

一つは本当にやりたいのか、本気で言っているのか（アイデアが馬鹿げていても大抵は本気なんでしょうけど）、その本気度をきちんと見極める必要があります。

その熱意をまずは感じ取ってみてそれが無駄になるものかどうかを判断必要はあります。

何でもかんでも本気で受け取っていてはこちらの身が持ちませんので。

もし、アイデアが未熟であればそれをきちんと昇華するために工夫や新たなアイデアを付け加える必要も出てきます。

無駄振りになるかどうかというのは、最終的なゴールがきちんと描けていないところが大きかったりするのですが、言っていることはわからなくは無いってものって結構多くあったりもします。

要は言っている事は正しいんだけど方法論がやっつけすぎて、そしてその実装もやっつけになってすぐに破綻するというものがあって、そのゴールのイメージを描いてやると目的もはっきりして周りも何ためにこのタスクをするのかというのが明確になってきたりします。

手間がかかるわけですが、最終的に何も残らないものをやるよりはきちんと運用され軌道に乗るものを作るほうが誰しもいいでしょう。

ここまではある程度本気で取り組まないといけなかった場合ですが、本当にそれが無駄に終わりそうだというのであれば、言い方は悪いですが適当に流してしまうということもありではないでしょうか。

無駄なことに時間を割くよりは本来やらないといけないことや前に進めるべきことがあるでしょうから、形だけ見せてその場を収めてしまうこともできるかもしれません。

まぁ、この辺は人によりますのでちょっとした形を見せたら細かく突っ込んでくる人や形だけでは納得しない人もいたりしますので難しいところではありますが、あえて突っ込ませてみて本人の考えを引き出すやり方もあるでしょう。

もう一つは、話を自分たちのやるべき方向性にうまく持っていくやり方です。

先に書いたように無駄振りの中にあるアイデアの種としては、本来やらなくてはいけない課題や施策が含まれていたりもしますので、それと自分たちがやろうとしている道筋に強引でも結びつけて引き込んでしまうやり方です。

話が大きくなってしまったりもするのですが、言った本人的にも大きなPJとして動いている体を見れば納得度も増してきたりもしますから。

あまりにも突飛な仕事の振り方であれば、話を摩り替えてしまえばそのうち忘れられたりもするんですがね。

何れにせよ、言った本人の性格などにもよるので対処として難しくはあるのですが、無駄な仕事をするために振り回されるのは誰しもやりたくないことですから、その本人が言ったことをうまくコントロールして有益なものに変える対処というものを考えた方が楽しく仕事ができるのではないでしょうか。

[PR]

企業向けIT製品／キーマンズネット

[PR]

就転職に強い資格・スキルをマスター！ヒューマンアカデミー

[PR]

独立・開業・起業のサポート情報の検索・資料請求サイト「アントレnet」

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

[PR]

変わらない情報システム部としての使いどころ

別に採用関連の仕事をしているわけではないのですが、毎年募集する新人とかの選考には多少絡んできたりもして、エンジニアを採用する難しさって結構身にしみるようになってきました。

一緒に仕事をして行く上で人間性も大事だし、ただ仕事を任せる上での技術力や知識というのも大事だしというジレンマがあったりするわけです。

人を育てる風土を維持できるか

新入社員を採用する場合、会社側の立場としては即戦力を求めることはないかと思いますが、入社後の教育というものにどれだけの時間とお金をかけられるのかはその企業文化によってきたりもします。

入社後の数ヶ月の研修だけですぐに現場に飛ばされ、現場で仕事を覚えろといういわゆるOJTが一般的で、言ってしまえば人は辞めるもの担当者は代わるものとしてマニュアル化した教育をしているところもあれば、なるべく企業に根付いて欲しいと思い、研修期間を終わってもある程度じっくりと時間をかけて長い眼で人を育てていくところもあります。

こういうのも企業の業務形態や戦略的な面にも大きく左右され、下請けを使うなどアウトソースするところやオフショア開発などに傾倒しているところでは、そんなに教育に投資できないというところもあるかもしれませんし、そういった戦略をとって痛い目を見たところはやっぱり自社にちゃんと自分たちのサービスのコアがわかるエンジニアを育てないといけないとして、ちゃんと教育して囲い込むことをやっている企業もあるでしょう。

こういうのは企業文化レベルだけでなく、その時々の経営判断なんかでも大きく左右されるので、幾ら自部門で人を育てていこうという戦略を立ててもその風土を維持することが難しかったりもします。

そして、誰がその人を育てるのか、というのも大きな問題となります。

大きな組織で教育部門がしっかりしていればある程度の基礎レベルまでは引き上げられるでしょうけど、それでもその人がサービスの核となるエンジニアになるためには、より多くの知識と時間が必要になります。

その組織の中にはロールモデルとなる人が存在するかもしれませんが、その人を教育担当者にあてがうには多くの場合ためらわれることだと思います。

その人に教育をさせるよりすべきことが他に多々あるでしょうし、場合によってはその人が多くの時間を教育にとられることを嫌いモチベーションが下がるかもしれません。

また、以前に何度か書いていますが現在の業務環境だと失敗できないものが非常に多くなってきており、十分な経験を与えることが難しくなってきたりもしています。

経験を経てわかることも、その経験する機会が減少したことにより、幾ら人を育てていきたいと考えていても採用したエンジニアをうまく育てていけない状況にあったりするわけです。

これにはある程度の失敗を許容できる環境が無いといけませんし、周りの人たちもそれに耐えられる、対応できるようになっていなくてはなりません。

経験者か未経験者か

採用する対象者もこういった企業文化やそのときの戦略によって大きく変わってきます。

PCやプログラミングに関する知識が皆無でも人となりがよく、素直に聞いて成長していってくれればよいということであればそれほど大学のブランドや学部、何を研究してたのかといったことなんかそれほど気にしなくてもよいでしょうけど、なるべく早く業務に就けるようにするのであれば大学でやってきたレベルとはいえ、基礎知識がその後の教育に大きく左右されたりします。

よっぽどの熱意があったり、大きな研究室で時間を費やしていたとしても、エンジニアとして社会に出る多くの人たちの多くは業務で開発する能力として適合しないケースの方が多かったりします。

それは、プログラミングのスキルがあるというのと、開発業務が行えるというのは当然違っていて、悲しいかな多くのスキルは企業のルールや体制・役割によって潰されたり適合できない場合があるからです。

個人の趣味でやる分には最先端の技法やツールを使う分には何の問題もありませんが、企業内では酷くレガシー化したシステムも多数残っていたりして、むしろ個人としてやってきたスキルを活かせない持ち腐れ状態になる人もいるかもしれません。

技術一本でやっていきたいという人は、最初から独立するか研究室のようなそれだけをやれる環境を目指した方が良いかもしれませんが、一般的な企業の中ではその人の幾ら強みであろうとも、それだけをやらせるという余裕も無ければ許容もしてくれません。

大学で勉強してきたからといって即戦力になるとは企業の中のヒト的に誰も思っては無いけど、基礎レベルとして構造が理解できるかどうかって結構その後の教育にも大きく影響を与えてきたりもします。

未経験者は素直で吸収も早いかもしれませんが、根本的に開発における理系脳のようなものについてこれない人もよく見かけます。

暗記ができても応用できないという感じで、プログラミングの構文を覚えても仕様どおりに組み立てるという応用が全然できないという具合に。

そういう意味で当然経験者の方を優遇したりもするのですが、必ずしもチームにある空いているポジションというのはバリバリできる開発者ばかりというだけでなく、運用を組み立てたりユーザーとの業務調整や企画をする人など幅広いところで役割があるので採用側もどのポジションに人を入れるかで変わってくるところではあります。

全員4番打者で打順を組み立てる必要は無いですし、当然そんなことでチームがうまく回るわけでもなく、フルスタックエンジニアなんて要らない、ミドルだけまたはネットワークだけができれば十分と思っているところもあるわけなので、どのポジションの人を採用するかというのをきちんと考えておかないと、何でもできる人材像を勝手に描いてしまって、入社後のその人の能力とのギャップに組織が苦しむことになります。

まとめ

新卒採用にしろ、中途採用にしろ、社員として雇ってしまったからには日本文化的にその人を急に辞めさせることもできませんし、メンバーとそりが合わない人や期待したスキルを持っていないという状況で現場を混乱させることは避けたいところです。

ですが、履歴書や筆記試験や採用面談の少ない情報や短い時間の中でその判別をするのは凄く難しいことですので、ある程度企業側も期待することや許容範囲を決めておく必要はあると思います。

そういったときに、ちゃんと人を育てることができるのかや、今の体制の課題からどの役割を埋めて欲しいのかというその人のキャリアも含めてきちんと考えておかないと、何時まで経っても組織の課題は解決されずに無駄に人だけが増えてしまうということになってしまうのだと思います。

[PR]

スカパー！厳選69チャンネルを今すぐ！スカパー！簡単申込

[PR]

独立・開業・起業のサポート情報の検索・資料請求サイト「アントレnet」

プロジェクトに人をアサインする際に陥るよくないパターン

5年目のエンジニアと話してアドバイスしたこと

今風のWebサービスを使っていると重たい処理などを行う際に画面上にプログレスバーが表示されたりして、ユーザーのイライラを緩和する措置が取られたりしています。

特に重たいファイルをアップロードする場合などにプログレスバーが表示されれば進捗もわかり、ユーザー的にも後どれぐらい待てばいいのかといった状況が把握しやすくなります。

今回は、PHPのキャッシュモジュールとして使われているAPC とjQueryUIのProgressbarウィジットを使って、ファイルアップロード時にプログレスバーを表示するというプログラムを書いてみたいと思います。

プログレスバーのイメージとAPCの環境設定

今回実装するプログレスバーのイメージは下記のようなものです。

進捗率の表示などはオリジナルな部分はありますが、ファイルを指定してからアップロード完了までの間、画面上にプログレスバーが伸びていき状況が把握できるようになっています。

通信は非同期に行われるため画面遷移が無く、ファイルアップロード画面だけで処理が完結できるようになっています。

今回の実行環境はPHP5.3.3、APCは3.1.13を使っています。

APC導入に関して詳細は書きませんが、PHPの設定ファイル（php.ini）に下記の設定項目を追加しておきます。

apc.rfc1867 = On

これにより、ファイルアップロードの進捗ハンドラが有効になります。

詳細は、マニュアルにも記載があるので確認するとよいかもしれません。

ファイルアップロード時にプログレスバーを表示するプログラム

今回作成したプログラムは、3つに分かれています。

1つ目がファイルアップロード画面のプログラム、2つ目が送られたファイルのチェックやアップロード後の処理を行うプログラム、3つ目が進捗管理用のプログラムです。

順番に見て行きますが、1つ目のファイルアップロード画面（index.php）は下記のようになっています。

<html>
<head>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'>
<link rel='stylesheet' href='//code.jquery.com/ui/1.10.4/themes/smoothness/jquery-ui.css'>
<script src='//code.jquery.com/jquery-1.10.2.js'></script>
<script src='//code.jquery.com/ui/1.10.4/jquery-ui.js'></script>
<style type='text/css'>
.upload {
  padding:10px;
}
#progressbar {
  position: absolute;
  margin: 10px;
  width:500px;
}
#loading {
  position: absolute;
  left: 50%;
}
</style>

<script>
var timer = null;
var progressMeter = 0;
// ファイルアップロード
function formSubmit() {
  $('#progressbar').progressbar({
    value: false,
    change: function () {
      $('#loading').text($('#progressbar').progressbar('value') + '%');
    }
  });

  var formData = new FormData();
  formData.append('APC_UPLOAD_PROGRESS', $('#progress_key').val());
  if ($('#uploadFile').val() !== '' ) {
    formData.append('uploadFile', $('#uploadFile').prop('files')[0] );
  }
  timer = setInterval('progressBar()', 3000);
  $.ajax('/upload.php', {
    method: 'POST',
    contentType: false,
    processData: false,
    data: formData,
    dataType: 'text',
    error: function (XMLHttpRequest, errorText) {
      clearInterval(timer);
      console.log(errorText);
    },
    success: function (res) {
      clearInterval(timer);
      if (res) {
// Uploadしたファイルのエラー内容を受信・出力
        alert(res);
        $('#progressbar').progressbar("destroy");
      } else {
        $('#progressbar').progressbar('value', 100);
        location.href = 'index.php';
      }
    }
  });
}

// 進捗割合の取得・表示
var progressBar = function () {
  jqxhr = $.ajax('/progress.php', {
    type: 'POST',
    data: { APC_UPLOAD_PROGRESS: $('#progress_key').val() },
  }).done(function (progressMeter) {
    if (progressMeter) {
      $('#progressbar').progressbar('value', parseInt(progressMeter));
    }
  });
}
</script>
</head>
<body>
<br />
<form  method='post' enctype='multipart/form-data' id='uploadForm'>
  <input type='file' name='uploadFile' style='width:400px;' id='uploadFile' />
  <input type='hidden' name='APC_UPLOAD_PROGRESS' id='progress_key' value='539e79fc9249f' />
  <input type='button' value='アップロード' onClick='javascript:formSubmit();'>
  <div id='progressbar'>
    <div id='loading'></div>
  </div>
</form>
</body>
</html>

まず、jQueryやjQuery UIのソースコードはホストとされているものを使っていますが、この辺は自信の環境にあるのであれば読込み方を適宜変更してください。

進捗の表示は、HTML内のIDがprogressbarのDIV要素にプログレスバーが、その中のloadingのDIV要素に進捗割合が表示されます。

表示処理しているjQueryのコードの箇所は、

  $('#progressbar').progressbar({
    value: false,
    change: function () {
      $('#loading').text($('#progressbar').progressbar('value') + '%');
    }
  });

の部分となります。
valueに、進捗率を設定すればバーが100%に向けて伸びていきます。

厳密に言うと、「max」の項目を追加することで100%を幾つの数値にするか決められたりするので、valueで設定できるのは100までの数値とは限りません。

最初にfalseを設定しますが、これを設定すると先ほどのイメージの例の最初に表示されるような斜線のバーがぐるぐる回るようなアニメーションをするというだけで、あまり意味はないです。

「change」の設定項目はvalueの値が変化したときの処理を書きますが、画面上にその値を描画するように定義しています。

あとは、FormData()でフォームオブジェクトを作成し、APC_UPLOAD_PROGRESSの値とファイルデータをAjaxで送信しています。

APC_UPLOAD_PROGRESSは、マニュアルにも記載の通りこのパラメータがあればAPCはアップロードの進捗データを生成するようになります（このキーは、apc.rfc1867_name にて変更ができるみたいです）

ですので、APC_UPLOAD_PROGRESSの値をサーバーに送ることで、進捗データを生成させ、下記の進捗率を取得する関数でその値を受け取って画面上の割合を変化させています。

（詳細は、後述する進捗管理用のプログラムのところで触れています）

var progressBar = function () {
  jqxhr = $.ajax('/progress.php', {
    type: 'POST',
    data: { APC_UPLOAD_PROGRESS: $('#progress_key').val() },
  }).done(function (progressMeter) {
    if (progressMeter) {
      $('#progressbar').progressbar('value', parseInt(progressMeter));
    }
  });
}

続いて、送られたファイルのチェックやアップロード後の処理を行うプログラム（upload.php）ですが、この辺はシステム要件によってどんなチェックをするのかや、アップロードされたファイルをどこに保存するのかが変わってくるので、ここではかなり適当に書いています。

<?php
// 簡易的なエラーチェック
if (!empty($_FILES)) {
    if (!empty($_FILES['uploadFile']['error'])) {
// エラーがあったら返すとか
        echo $_FILES['uploadFile']['error'];
    } else {
// アップロード成功したら適切な場所に保存するとか
        move_uploaded_file($_FILES['uploadFile']['tmp_name'], "/tmp/" . $_FILES['uploadFile']['name']);
    }
} else {
    echo "Empty File";
}

最後は、進捗管理用のプログラム（progress.php）です。

<?php
$num = 0;
if (isset($_POST['APC_UPLOAD_PROGRESS'])) {
    $status = apc_fetch('upload_' . $_POST['APC_UPLOAD_PROGRESS']);
    if (isset($status['current'], $status['total'])) {
// 進捗計算
        $num = strval(ceil($status['current'] / $status['total'] * 100));
    }
}
echo $num;

こちらは、先ほど書いたようにAPC内のキャッシュデータから進捗データを読み取って計算して割合を返すということをしています。

キャッシュデータの読み込みは、APC_UPLOAD_PROGRESSの値によって行われますので、このキーはユーザーごとにユニークなものを割り振る必要があります。

先ほどのindex.php内で「539e79fc9249f」という値で送信していますが、この値をユニークになるように設定し埋め込んでおく必要があります。

また、apc_fetchにて進捗データを読込む際に、「upload_」の接頭辞を使っていますが、これもデフォルトのものでapc.rfc1867_prefix の設定項目によって変更することが可能です。

apc_fetchで受け取る配列のtotalキーがファイルの合計容量、currentが現在受け取っているデータサイズとなるので、ここから進捗を計算しているということになります。

今回はファイルアップロードの進捗表示ということで書いてみましたが、進捗を返せばjQueryのProgressbarウィジットでプログレスバーを表示することはできるので、処理内で進捗計算して値を返すようにすれば、その他の処理でも進捗表示をさせることができたりしますので応用してみてもよいかもしれません。

[PR]

NTTPCのVPS 『WebARENA SuitePRO V3』

[PR]

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

[PR]

jQuery UI Sortableを使ってドラッグ＆ドロップでリストを並び替える

[jQuery] 外部JavaScriptファイル読込みに関する考察

Googleサジェストが実装できるjQuery Autocomplete Mod

Twitter入力フォームのように文字カウントしてくれるcharacter count

JavaScriptからPHPの関数呼び出し

[PHP] 余計なHTMLタグや属性を消してくれるHTML Purifier

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

CakePHPを利用する場合、そのサーバーのDocument Rootにインストールしてしまうのが一番手っ取り早いのですが、場合によってはDocument Rootを他のツールやコンテンツで利用したいために、他のパスで動作させたいということがあったりします。

ということで、元々Document Rootで動かしていたCakePHPを別のパスで動くようにお引越しした際の備忘録です。

環境は、CakePHP2.3.7＋Apache2.2.15で動かしています。

CakePHPをDocument Root以外で動かす

まず、CakePHPは下記のパスにインストールされているとします。

/var/www/cakephp

DocumentRootでCakePHPを動かしていた頃のApacheの設定ファイル（httpd.conf）のVirtualHostは下記のようにしていました。

<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/cakephp/app/webroot
    ServerName www.example.com
    ErrorLog logs/error_log
    CustomLog logs/access_log combined
</VirtualHost>

DocumentRoot以外でCakePHPを動かすので、URL上でのCakePHPのパスを決めなくてはなりません。

今回は、「http://www.example.com/apps/」でCakePHPが動くように設定をしたいと思います。

合わせて、DocumentRootを他のコンテンツが表示されるように置き換えるので、まずはApacheの設定ファイルを下記のように編集します（編集後は要Apache再起動）。

<VirtualHost *:80>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/html
    ServerName www.example.com
    ErrorLog logs/error_log
    CustomLog logs/access_log combined
    Alias /apps/ /var/www/cakephp/app/webroot/
</VirtualHost>

これで、DocumentRootのパスはCakePHP以外のディレクトリに移り、Aliasによって/appsにアクセスがあるとCakePHPのディレクトリが参照されるようになります。

次に、CakePHPのインストールディレクトリ以下にある.htaccessファイルを編集します。

これは、下記の3つのパスにそれぞれ存在します。

/var/www/cakephp/.htaccess
/var/www/cakephp/app/.htaccess
/var/www/cakephp/app/webroot/.htaccess

追加する設定は、mod_rewriteの下記の設定で、URLの基点となるパスを指定しておきます。

RewriteBase /apps

例えば、/var/www/cakephp/app/webroot/.htaccessのファイルには下記のように設定します。

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /apps
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

これだけで一通りの設定が完了です。

http://www.example.com/apps/コントローラ名/アクション名

にアクセスすれば、今までのページが見えるようになっているはずです。

ちなみに、画像ファイルやJavaScript、CSSなどのパスもそれぞれ/apps以下となるため、直接パスを書いているテンプレートやレイアウトファイルなどは一通り編集する必要があります。

変更したURLを元のパスに戻す

これは余談ではあるんですが、今回の目的はDocumentRootを他のコンテンツのために明け渡したいということであって、決してURLのパスを変えたいというものではありません。

そこで、Apacheの設定ファイルに下記のようにAliasを設定することで、DocumentRootをCakePHPが使わなくても元々のパスを使い続けることができます。

Alias /apps/ /var/www/cakephp/app/webroot/
Alias /foo/ /var/www/cakephp/app/webroot/

/fooはCakePHPのコントローラ名です。

前述の設定により、通常は

http://www.example.com/apps/foo/bar

というアクセスをしなければならないのを、

http://www.example.com/foo/bar

という元々のパスに戻すことができます。

ただし、コントローラごとにAliasを設定しなくてはならないのと、CakePHPの画像ディレクトリ（/img）やJavaScriptディレクトリ（/js）やCSSディレクトリ（/css）などは一般的過ぎる名前のため、Aliasの設定はしないほうが無難かもしれません（他のDocumentRootを使うコンテンツと競合するので）

今回の設定変更は、先ほどのmod_rewriteでのRewriteBaseの追加により、http://www.example.com/foo/barのURLでアクセスをしてもベースとなるURLを/appsに置き換えられて内部的にリクエストが投げられるため、URLをごまかすことができます。

URLを変更する影響が大きい場合は、このように設定してもよいかもしれません。

[PR]

NTTPCのVPS 『WebARENA SuitePRO V3』

[PR]

ワンクリック・20秒でスマホサイトへ自動変換

[PR]

CakePHPでHtmlHelperを使って開いているページのURLを取得する

CakePHPでリダイレクトする際のお作法

CakePHPのエラーページをカスタマイズする

CakePHPのデフォルトレイアウト「default.ctp」を読み解く

繰り返し使うテンプレートを一元管理できるエレメント

CakePHPでアプリケーション独自の設定ファイルを利用する

CakePHPの共通のライブラリの作り方

CakePHPでファイルキャッシュ、メモリキャッシュを使う

今やWebサイトを開設したらモバイルへの対応は必須という状況になってきています。

CakePHPで作ったサイトでも簡単なステップを踏めばPC用とモバイル用を分けて表示するということができたりします。

※ ここで書いたモバイルというのはスマートフォンが中心なので、正確に言えば「CakePHPのサイトをスマートフォンに対応させる」かもしれません。

今回の環境では、CakePHP2.3.7を使っています。

isMobileを使ってモバイル判定をする

CakePHPのRequestHandlerComponentの中には、モバイル判定をしてくれるメソッドが標準で用意されています。

それが、isMobileメソッドでユーザーエージェント内に特定の文字列があるかどうかで判定を行っています。

日本のものでは何故かDocomoだけが入っていますが、ほぼ海外の端末判定しかしてくれません。

まぁ、スマートフォンであれば多くはiPhoneかAndroidになるかと思いますので大部分はカバーできるかもしれませんが。

使い方は単純で、メソッドを呼び出せばアクセス元のユーザーエージェントから自動的に判別してくれます。

ですので、共通の事前処理としてbeforeFilter()などでisMobileを呼び出して判定してあげます。

    public function beforeFilter() {
        if ($this->request->isMobile()) {
            $this->mobile = TRUE;
        }
    }

次に、モバイルの場合はPC用のテンプレートが使えないので、モバイル専用のテンプレートを用意してあげます。

これは、各アクションの中で

$this->render('mobiePage');

などとしてもいいのですが、PC用のテンプレートと混在すると保守しづらかったり、アクションごとに判定と設定をしていくのは手間なので、beforeRender()でモバイル判定された場合のテンプレートのディレクトリを別で参照するようにしておきます。

    function beforeRender() {
        if ($this->mobile === TRUE) {
            $this->viewPath = 'Mobile';
        }
    }

これで、モバイル判定された場合はView/Mobileディレクトリが参照されます。

あとは、モバイル用のViewファイルを用意しておきます。

<?php $this->layout = "mobile"; ?>
<div data-role="page">
  <div data-role="header" data-theme="b">
    <h1>モバイルページ</h1>
  </div>
  <div role="main" class="ui-content">
    <p>モバイルからのアクセスです</p>
  </div>
</div>
</body>
</html>

モバイル用のレイアウトファイルも別に用意しておいた方が便利かもしれません。

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title><?php echo $title; ?></title>
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.4.0/jquery.mobile-1.4.0.min.css" />
<script src="http://code.jquery.com/jquery-1.10.2.min.js"></script>
<script src="http://code.jquery.com/mobile/1.4.0/jquery.mobile-1.4.0.min.js">
</script>
<script src="/apps/js/jquery.mobile.nestedlists.js">
</script>
</head>
<body>
<?php echo $this->fetch('content'); ?>

これは、jQueryモバイルを使ったレイアウトおよびテンプレートファイルとなりますが、モバイルページの作り方は様々なので環境に応じて作りこみます。

これで一通りモバイルへの対応が完了です。

isMobileのモバイル判定を拡張する

isMobileの判定はマニュアルページにも書いてあるとおり、あまり多くのモバイルに対応しているわけではありません。

これを、その他のモバイル環境でも判定できるように拡張したい場合もあるでしょう。

その前に、isMobileの判定方法を簡単に書いておきます。

/path/to/cakephp/lib/Cake/Controller/Component/RequestHandlerComponent.php

isMobileはRequestHandlerComponentに定義されていると書きましたが、具体的には上記のパスに存在します。

    public function isMobile() {
        return $this->request->is('mobile') || $this->accepts('wap');
    }

この中で呼び出されているis()メソッドは、Network/CakeRequest.phpの中で定義されていて、is()メソッドは_detectorsという特殊な変数の中身に該当するかどうかをチェックする動きをします。

detectorsの中身はデフォルトで下記のように定義されています。

    protected $_detectors = array(
        'get' => array('env' => 'REQUEST_METHOD', 'value' => 'GET'),
        'post' => array('env' => 'REQUEST_METHOD', 'value' => 'POST'),
        'put' => array('env' => 'REQUEST_METHOD', 'value' => 'PUT'),
        'delete' => array('env' => 'REQUEST_METHOD', 'value' => 'DELETE'),
        'head' => array('env' => 'REQUEST_METHOD', 'value' => 'HEAD'),
        'options' => array('env' => 'REQUEST_METHOD', 'value' => 'OPTIONS'),
        'ssl' => array('env' => 'HTTPS', 'value' => 1),
        'ajax' => array('env' => 'HTTP_X_REQUESTED_WITH', 'value' => 'XMLHttpRequest'),
        'flash' => array('env' => 'HTTP_USER_AGENT', 'pattern' => '/^(Shockwave|Adobe) Flash/'),
        'mobile' => array('env' => 'HTTP_USER_AGENT', 'options' => array(
            'Android', 'AvantGo', 'BlackBerry', 'DoCoMo', 'Fennec', 'iPod', 'iPhone', 'iPad',
            'J2ME', 'MIDP', 'NetFront', 'Nokia', 'Opera Mini', 'Opera Mobi', 'PalmOS', 'PalmSource',
            'portalmmm', 'Plucker', 'ReqwirelessWeb', 'SonyEricsson', 'Symbian', 'UP\\.Browser',
            'webOS', 'Windows CE', 'Windows Phone OS', 'Xiino'

        )),
        'requested' => array('param' => 'requested', 'value' => 1)
    );

この配列の中で、mobileキーがモバイル判定するためのユーザーエージェントの一部の文字列が入っています。

モバイル判定を拡張したい場合はこれに追加すればいいわけですが、addDetector()という専用のメソッドが用意されています。

例えば、Kindleからのアクセスをモバイル判定にしたい場合、下記のように事前にaddDetector()でKindleという検知用の文字列を追加しておきます。

$this->request->addDetector('mobile', array('options' => array('Kindle')));
if ($this->request->isMobile()) {
    $this->mobile = TRUE;
}

これで、isMobile()の判定データを拡張しておけば定義されていない環境からのアクセスでもモバイル判定できるようになります。

[PR]

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

[PR]

禁断の無制限解禁！【ディスク容量無制限のレンタルサーバー】

[PR]

CakePHPをDocumentRoot以外で利用する

CakePHPでリダイレクトする際のお作法

CakePHPでHtmlHelperを使って開いているページのURLを取得する

CakePHPのエラーページをカスタマイズする

CakePHPのデフォルトレイアウト「default.ctp」を読み解く

繰り返し使うテンプレートを一元管理できるエレメント

CakePHPを利用した簡単アプリケーション開発～ ViewとControllerに触れる

宿選びの参考に。ホテル・旅館などに掲示される新たな表示マークをご紹介

Ads by Trend Match

私たちの身の回りの多くはソフトウェアによって制御されているものが数多くあり、そのソフトウェアの構造は年々複雑化の一途を辿っていっています。

TVにしろ、カーナビにしろ、エアコンにしろ、ゲームにしろ、Webサービスにしろ、全てがその製品があり続ける限り多機能化され、モデルチェンジやバージョンアップによって新しい処理が加わっています。

TVのリモコンを見るたびに使っていないボタンの多さに戸惑い、自分が望むものはどの操作をすれば解決するのかわからず悩みます。

自分が欲しいものはもっとシンプルなものだ！といったところで、それに反するものが世の中にあふれるのは何故なのでしょうか。

シンプルなものは満足されない

モノがあふれる時代では、あるものに特化したごくシンプルな機能というのは、それにかなりの強みやメリットが無い限りなかなか満足されません。

スマートフォンは、もはや元の携帯電話の型から逸脱していますし、単に電話ができればよいというシンプルな機能だけでは満足されません。

らくらくホンといった電話の機能だけに特化したニッチな製品もありますが、それが多数派となっていない以上、少なくとも携帯電話が通話だけの機能でよいと考えている人は少ないのでしょう。

単に自分のつぶやきを140文字で投稿するというシンプルなTwitterでも、サービス開始以降に公式のリツイート機能が実装されたり、フォロワーをグループ化できるリストや、他人の行動を確認できるアクティビティ、（誰が何のために使うんだと思う）自分のつぶやきのダウンロード機能などが加わっています。

単に地図を表示するというシンプルな機能であったGoogle MAPもストリートビューやコミュニティの機能が加えられたり、写真を投稿するシンプルなアプリであるInstagramも写真の加工機能やフィルタが多種多様に追加されていっています。

こういったソフトウェアのバージョンアップは、便利だと思うものも多くある中でそれと同じぐらいに自分には不要と思うものがあったりします。

こういった経緯の中で、自分の中でシンプルでわかりやすく取り扱いやすいものと思っていたものが、複雑でとっつきにくいものへと変貌していくのでしょう。

しかし、一方で単にシンプルだったものに飽きがきてしまうこともあります。

単純だから好きというものが単純すぎると感じられるようになったり、あとこの機能があればいいのにという欲が出てきて似たような別の製品やサービスに心変わりしてしまうのよくあることです。

今のユーザーの心理としては、無いよりはあったほうがマシ、あって邪魔なら無視すればいいだけのこと、と考える人の方が多いからかもしれません。

ソフトウェア開発に纏わる複雑化の要因

ソフトウェアを開発する上で、その最初はシンプルだった機能がどんどん複雑化する要因はどんなものがあるのでしょう。

1つは、先ほど書いたようにシンプルな機能だけでは強みが無く、例えニッチだとしても少数派を取り込み差別化を図りたいというものがあるかと思います。

要はシェアを獲得するためには多くのユーザーが必要であり、その獲得のためには広く満足してもらうための機能が必要だという観点です。

世の中、似たような製品があるわけで競争に勝つためには、他に無い機能をどんどんと取り入れていかないといけないわけで、その過程でソフトウェアは複雑化していきます。

2つ目は、下位互換によって機能が残されるというものがあったりします。

新バージョンではその機能は別のものに取って代わっているのに、旧バージョンから引き継ぐためにその機能を残さざるを得ない状況です。

いきなり無くすのはユーザーへの影響度をから乱暴だと考え、段階的に廃止するためにしばらくの間、下位互換としてその機能が継続されることはよくあったりします。

ただし、すっぱりなくなくるということの方が稀だったりもして、何時までもその機能を引き継ぎメンテナンスせざるを得ないソフトウェアも数多く存在します。

3つ目は、ステークホルダーとの関係によるものだったりします。

株主などそのサービスに投資している人がいて利益拡大のためにサービスを常に拡張しつづければならなかったり、そもそもユーザーからの声というものが機能追加の後押しとなったりします。

実はサービスや製品を複雑化しているのは私たちの意見からくるのかもしれません。

場合によっては、権威ある人からの鶴の一声で要らぬ機能が追加されるということもあるでしょう。

4つ目は、ソフトウェア開発コストの低下に伴う使い捨ての思想によるものがあります。

ソフトウェアは複雑化しても単機能としての開発コストは下がっているので、リリースして使われなければ捨てればよいという発想があったりします。

シンプルな機能で良いといっても、そのシンプルという定義は人によって異なるので、多機能なものを与えてその人に取捨選択してもらうほうが楽だったりします。

なので、数打てば当たると言わんばかりに、多くの機能をスクラップ＆ビルドしていくわけですが、一度作ったものはなかなか取り下げることが難しく、スクラップするはずのものがそのまま残されていったりもします。

5つ目は、関連するソフトウェアの多さによるものです。

技術の発展により、ソフトウェアの開発コストは下がり、簡単に万能なインフラがすぐに構築できる環境であっても、そこには数多くのソフトウェアが存在しています。

例えば、仮想化の技術によってより多くのOSが1つのハードウェアの中に集約できたとしても、その上で起きたソフトウェアの問題は、アプリケーションによるものなのか、OSによるものなのか、ハイパーバイザーによるものなのか、ファームウェアによるものなのかの切り分けが非情に難しかったりします。

ソフトウェアがソフトウェアと関連するたびに、その複雑さは単純に増していくことになります。

まとめ

ということで、ソフトウェアの複雑さは単にその制御の仕組みだけでなく、ユーザーのニーズや心理であったり、サービスの強みによるものだったり、開発手法であったり、と様々な要因によって複雑化していっているのではないでしょうか。

一昔前なら、こんな機能があるなんて夢のようだといわれたものが今や付いてて当たり前という時代になってたりもします。

しかし当然ながら、それを制御するソフトウェアというものはその機能の数以上に存在しており、それらを制御するためにはかなり難易度の高い処理をしなくてはなりません。

こんな機能、誰が使うんだという感情はそれを使うユーザー以上に、それを作るエンジニア自身が持っていたりするのかもしれません。

[PR]

スマホやTV、PCで、いつでも映画や海外ドラマを見れる！今すぐ無料視聴！

[PR]

禁断の無制限解禁！【ディスク容量無制限のレンタルサーバー】

サービス構築の実行コストは構築側より提案側のほうが上回ってるんじゃないかって話

システム運用後のトラブルはリスクを誇張させる

初めからやっておけばよかったとあとで思うシステム構築に関する10のこと

運用の中で崩壊していくシステム

システムはなぜダウンするのか知っておきたいシステム障害、信頼性の基礎知識

2006年から開始したこのブログもこの8月で8年が経過したことになりました。

当初はあまり技術ログとしてスタートするつもりは無かったのですが、ここ最近はプログラミングなどのネタの方が中心となって、更新頻度も生活リズムの変化とともに変わり、当初のやろうとしていたことから随分とかけ離れてしまったかなと思ったりしています。

ネットに住まう難しさ

じゃあ、当初何をしたかったのかというと、プログラミングやライブラリの使い方などの技術ログを残すというよりは、IT業界の話題や仕事の上での考え方などのまとめて、同じ業界で仕事しているエンジニアのブログとかとのつながりが持てたらいいなと思ってました。

まぁ、ブログ界隈で少しは有名人になればいいなとかの野心も少し持っていましたが、如何せんそんなに凄いネタを提供できるほどの情報力も文章力も知識量もないものなので単なる日記としての足跡ぐらいしか残せていないのですが。

当時は、トラックバックの機能もまだ比較的使われていましたし、個人がやっているまとめサイトなども数多くあって、ブログとブログがつながっている印象を凄く感じていたのですが、時代の流れとともに情報発信もTwitterやFacebookに流れていったり、ブログ同士のつながりというものも薄くなってしまったように思えます。

これは当然色んなサービスが出ては消えていく時代の流れの中でのことなので仕方が無いことですが、自分的にはこのブログを始めた当初はネットにおけるホームのような位置づけだったりして、それを発展させたいという思いを強く持っていました。

ただ、ホームは作ったもののそこに時間をかけるのはそれなりの労力が当然かかるわけで、一方でその労力が目に見えて報われるほどの大きなリターンというのは当時すぐに得られるわけも無く、なかなかモチベーションを維持し続けることが難しいと思うようにもなり、それを専門でやっているようなブロガーのネットに住んでいる感って半端ないんだなと感じたりもします。

それを感じとったぐらいから自分がネットに住まうというのは難しいとも思うようになって、自分のペースというものを見出し、ある意味その諦めからブログというものを長く続けられているのかもしれません。

技術ネタに逃げたのは反応が得やすいから

年々技術的な話題のエントリって増えていったりしているのですが、それはある意味ネタとして書きやすいからだったりします。

自分が調べ上げたことの結果を、スタートからゴールまで単に羅列していけば済むので。

ただ、入社当時の上司の言い分で「ネットで調べてみたら自分と同じ状況で困っている奴は1人はいるから調べろ」って言われたことがあって、その困っている人を助けられる1人に今度は自分がなれたらいいなとかって思いはあったりもします。

まぁ、それは自分への備忘録のついでという意味もあったりするのですが、現にこういうエントリって今でも数年前のものがそれなりに読まれていたりして、技術ログって反応が継続的にあってわかりやすかったりします。

もう1つ、技術ネタを中心に書いていた効能としてはエンジニアとしてのモチベーションが上がったんですね。

他の人の技術ネタのエントリを読んでみたらこれは凄いと思えるようになりますし、そのネタを試してみたいとも思いますし、そんなネタを自分でも書いてみたいとも思うようになったりします。

最初から技術ネタだけを扱うブログとしてスタートできなかったのは、当時の自分にはたいした技術的な知識ってあんまり持ってなかったからというのが正直なところなんですが、ブログでプログラミングネタとかを書いていってその反応が見て取れたからこそ、今でもエンジニアとしてのモチベーションが維持できているのかなと思ったりします。

ただ、技術系のエントリはそもそも書くのにはかなりの時間がかかってしまいます。

エンジニアとしてのモチベーションはあっても、実際の仕事としてプログラマとして第一線にいるかといわれたら、やっぱり経験とともに他の仕事も押し付けられたりしてなかなかそうはいかないので、ネタとしても幾つも出てこなかったりもするわけです。

なので、現場では下の子がやっているテクニックや使っているツールなどをみては吸収できることは無いかなという見方をしてたりもして、そういう技術的なことに対する興味が尽きないのはブログをやっていたおかげなのかもしれません。

まぁ、それでもエンジニアブロガーとして結果を出すということにこだわるのであれば、技術ネタをどんどん書くよりは、小規模なものでもいいので使えるサービスというものを産み落とすことをした方が説得力もありますし、周りからも受け入れやすいと思う今日この頃ではありますが。

ということで、自分のペースを維持しつつ、このブログ運営を今後も継続できるようになんとかがんばっていきたいと思います。

[PR]

スマホやTV、PCで、いつでも映画や海外ドラマを見れる！今すぐ無料視聴！

気になるおケイコを手軽に検索「ケイコとマナブ.net」

[PR]

ブログを7年間書き続けて変わった5つのこと

ゆるりと続けるブログ術

 技術ネタをブログに書く上で気をつけている7つのこと

周りから「ストレス耐性があるよね」なんて言われるんですよ。

でも、実際ストレスに強いわけではなく結構ガラスのハートの持ち主だったりするわけですよ。

で、ストレス耐性ってものが本当にあるのかって言われたらそんなものないと思うわけです。

ストレスからは逃げるしかない

自分的にストレス耐性があるって思われているのは、

1. 寝たら忘れられる都合のよい性格

2. 人の話を適度にスルーできる

3. 面倒がありそうなところに突っ込んでいかない無関心さ

4. ストレスを共有できる気があう仲間の存在

5. 逃げられない環境を作らないための空気口

のようなものがあって、要はストレスを溜め込まないようにしているわけです。

1.の性格は結構都合のよいものだったりもするのですが、この辺は人によって何日も引きづったり、怒りを維持したまま眠って、そのままのテンションで次の日に怒る人もいたりするものですからあんまり参考にならなかったりするのですが、2.3.なんかは要はスルー力みたいなところで、ストレスを受け止めるのではなく流したり、あんまり面倒くさそうなところには関わらないことでストレスの発生源を少なくするというように、ストレスを溜め込まないためには必要だったりするんじゃなかろうかと思うわけです。

もちろん、悪いところもあって人の話を聞いていないとか怒られたり、無関心さから人間関係が希薄になったり、冷たい奴って思われたりするんですが、情報があふれる現代においては自分が嫌だと思う情報は適度にスルーしたり、SNSなど気軽にコミュニケーションが取れる今だからこそ返ってSNS疲れなんかを起さないような適度な無関心さっているんじゃないかとも思ったりします。

4.の話は、気の合う仲間と愚痴をぶつけるために飲みに行ったりしても、似た状況で共通のストレス発生源があればぶつけ合うことで互いに外に追い出すことはできるでしょうが、片方の愚痴を延々と聞かさせるだけだったりしてそれが何日も続いてしまうと、聞いているほうのストレスが溜まってしまって、さらに別の人にそのストレスをぶつけるといった悪循環に陥ったりもします。

ですので、こういう仲間というのは同じ職場の人であったり、職種であったり、立場であったり、結婚しているとか似たような状況下にあるもの同士のほうがよいのではないかと思います。

単に愚痴の聞いてくれる都合のよい人という捉え方をしてしまうと、その人にストレスを押し付けているだけでいつか関係性が壊れてしまうかもしれませんし。

5.の話は、例えば家庭であったり職場であったり、どうしてもストレスを受けざるを得ない環境ってあったりするわけで、気軽に逃げるという選択肢が取れない場合に対して、その受けてしまったストレスをうまく逃がすための自分なりの空気口をちゃんと用意しておいた方がよいかと思っています。

例えば、ストレスを発散できる趣味があったりとか、家庭内でも一人の時間をもてるとか、運動して汗をかくとか、この辺は人それぞれ違ってくるでしょうけど、どうしても受けてしまうストレスに対しては、それを抜くための空気口ってちゃんと用意しておいて、自分であけることができるようにしておいたほうがよいと思ったりします。

精神論を振りかざす

人っていたりするわけですけど、そういう人ってきっと適当な人なんだろうなって思ったりします。

適当というのは、「○○は甘え」というような自分の意見を押し通していて、そうではないという人の話を聞かなかったりするので、ある意味その人はストレスを受けづらい人なんだと思います。

人の話をスルーでき、相手の立場を棚に上げることができるので、言い返したところで聞いてないし、ポジショントークを繰り広げられます。

過去の体験をベースに話したりする人もいますが、その時と今の時代の状況の違いを理解してなかったり（または、それを棚に上げておいたり）、昔の状況がより不利であったかのように話してきたりもするのですが、結局のところその優劣を判断することは誰もできませんし、今の時代の方が全てにおいて優れているとも限りません。

「情報を捨てるセンス選ぶ技術」という本（まだ、全部読んでないですが）の中に、現代において人が１日に下す決断の数は約1万件、消費した情報量は50年前に比べて3倍になっているそうです。

都合のよい捉え方をすれば、それだけ豊富な情報があるのに何で仕事ができないんだ見たいな事を言えるかもしれませんが、実際それだけの情報に埋もれ、その目にする情報によって素早い判断を求められ、得たくも無い情報を耳にしたりすることでストレス量も増加します。

また、こういうことを言う人って、立場的に上だったりするもんですからそもそもストレスを受けにくい環境下にいたりします。

ストレスが無い立場なんで、ストレスを受ける側の立場を理解できなかったりしますし、その上下関係の有意性からストレートに発する言葉に、受け手はストレスを感じたりするわけです。

立場が上であるが故に、ストレスを逃がすための空気口はいつでも自分で作れますから、状況がまずくなったら逆ギレして強制させたり、あとは適当にやっといてと丸投げしてくるのではないかと思います。

何れにせよ、こういう人が今の自分と同じ立場でやったら我慢してできるのだろうかとか思ったりすることもありますが、これはその人と同じ考えに染まることになるわけなので、そういった考えをするよりはそういう人にはなるべく近づかないで済むように考えた方がストレスが溜まらなくてよいかもしれません。

結局、ストレスなんて誰しもまともに受け続けていたら自分の中に蓄積されていきいつかつぶれてしまうもので、受け流すまたはストレスから逃げる・遠ざかる術を身につけるしかないのかなと思っています。

[PR]

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

[PR]

気になるおケイコを手軽に検索「ケイコとマナブ.net」

[PR]

PCもタブレットも外出先で快適ネット！速度制限ナシは、WiMAXだけ。

人の多様性を認めてしまえば評価ってそれほど怖いものでもない気がする

文化の違いという言葉への違和感

IDやパスワードを一元管理するために、Active Directoryと連携したいというケースがあったりしますが、ADへ認証やパスワード変更などをPHPから行うためのメモです。

LDAPを通して簡単に認証やパスワードなどの属性値変更が行えます。
PHPは5.3系を使っています。

Windows側はWindows2008およびWindows2012で動作確認しています。

Active Directoryへ認証するPHPプログラム

これは特に難しいことなく、PHPのldap_bind を使えば認証が行えます。

<?php

$host = "ldaps://192.168.0.100";
$ldapConn = ldap_connect($host);

// userprincipalnameを指定
$userId = "username@testdomain.test";
$userPass = "HogeHoge12";

ldap_set_option($ldapConn, LDAP_OPT_PROTOCOL_VERSION, 3);
if (ldap_bind($ldapConn, $userId, $passwd)) {
    echo "ログイン成功" . PHP_EOL;
} else {
    echo "ログイン失敗" . PHP_EOL;
}
ldap_close($ldapConn);

ポイントとしては、ユーザー名にはuserprincipalnameを指定すること（dnを指定してもできますが）ぐらいで後は認証するldap_bindに引数を渡して結果がTRUE/FALSEで返ってきます。

Active Directoryのパスワードを変更するPHPプログラム

お次はAD上のパスワードを変更する方法ですが、前提としてパスワード変更する際にはAD上にSSL証明書を用意し、LDAPSで接続する必要があります。

SSL証明書は正規のものではなく自己証明書でもかまいませんが、その場合は接続するサーバー側で証明書の検証を無効にするように設定しておく必要があります。

TLS_REQCERT never

上記の設定を、/etc/openldap/ldap.confあたり（環境によっては複数あったりしますが）に記載しておきます。

パスワード変更するための具体的なプログラムは下記の通りです。

<?php

$host      = "ldaps://192.168.0.100";
// 管理権限を持つユーザー名
$adminId   = "administrator@testdomain.test";
// 上記ユーザーのパスワード
$adminPass = "adminpassword";

// パスワード変更対象のユーザー名
$userId   = "username@testdomain.test";
// 変更するパスワード
$userPass = "HogeHoge12345";

// 管理者権限を持つユーザーでADへ接続
$ldapConn = ldap_connect($host);
ldap_set_option($ldapConn, LDAP_OPT_PROTOCOL_VERSION, 3);
if (!ldap_bind($ldapConn, $adminId, $adminPass)) {
    echo "ログイン失敗" . PHP_EOL;
    exit;
}

// ユーザーのDNを取得する
$baseDn = "OU=Employee,OU=Users,DC=testdomain,DC=test";
$filter   = array("dn");
$ls       = ldap_search($ldapConn, $baseDn, "userprincipalname=$userId", $filter);
$userInfo = ldap_get_entries($ldapConn, $ls);

// 設定するパスワードはダブルクォートで括ったものをUTF-16に変換する
// unicodePwdはパスワードを格納しているエントリ名
$entry["unicodePwd"] = mb_convert_encoding("\"" . $userPass . "\"", "UTF-16LE");

if (ldap_mod_replace($ldapConn, $userInfo[0]['dn'], $entry)) {
    echo "変更成功" . PHP_EOL;
} else {
    echo "変更失敗" . PHP_EOL;
}
ldap_close($ldapConn);

パスワードを変更するプログラムは、少し複雑にはなりますが予約すると下記の流れで組んでいます。

（その他の属性の変更も基本同じ流れでいけるはず）

1. パスワードを変更できる管理権限を持つユーザー（ここではadministrator）でADへ接続
2. 変更したいユーザーのDNを取得するためにADを検索
3. 変更したいパスワードをダブルクォーテーションで囲ったものをUTF-16LEで変換
4. 変更したいユーザーのパスワード属性（unicodePwd）に2.のパスワードを変更

2.の処理でDNを検索するのは回りくどいように思えますが、ldap_mod_replace（またはldap_modify）で変更したいユーザー属性やオブジェクトを変更したい場合、DNを指定する必要があるためにそうしています（ldap_bindはuserprincipalnameの指定でもいけるのに何故・・・）

3.の処理はWindows側の仕様のようで、本来であればダブルクォーテーションで囲った平文パスワードをUTF-16LEに変更し、それをBase64エンコードすることになるのですが、Base64へのエンコードはLDAP関数側で自動的にやってくれるので省略可能です（逆にBase64にエンコードしてしまうと二重にエンコードされます）。
この辺の話は、下記に情報があります。

Active Directory: AD LDS における unicodePwd 属性値の謎

また、実運用するならエラーハンドリングをきちんと書いたほうが良いと思いますし、LDAPに渡すフィルタの値などはエスケープ処理をきちんとしておいたほうがよさそうです。

PHPにはldap_escape という関数ができているようですが、PHP5.6以上じゃないと使えません。
これ以下のバージョンを使っている場合は自前で用意するしかなさそうです。

下記のRFCの要約を見る限りは、「* ( ) \ NULL」は円マークでエスケープしたあとにASCII値に変更しろって書いていますので、その辺の処理を組み込む必要がありそうです。

付録 A:RFC2254 - LDAP 検索フィルタ

あと、余談の余談にはなりますけど、PHPのldap_mod_replace のマニュアルを見ていると、設定するパスワードの最後に「\000」をつけていたりしていて、これなんだろうとか思ってましたがどうもNULL文字つけて文字の区切りをはっきりさせているのでしょうか。

$newPassword = "MyPassword";
$newPassword = "\"" . $newPassword . "\"";
$len = strlen($newPassword);
for ($i = 0; $i < $len; $i++)
        $newPassw .= "{$newPassword{$i}}\000";
$newPassword = $newPassw;

この処理はいるのだろうか（無くても動く）と思ったり。

[PR]

低価格・携帯対応のSSLをお探しなら　ジオトラストクイックSSLプレミアム

[PR]

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

OAuth経由でTumblrの情報を取得・投稿するPHPスクリプト

OAuthを使ってPHPからTwitterへ投稿する

先日、同じチームの部下が一人辞めまして、まぁその子は少し前からそんなニュアンスをほのめかしていましたので話を聞いたときは致し方ないかとは思ったりしたんですが、仕事に対するモチベーションというのは環境にも増して自分自身の内から来るものが大きかったりするのでどうやってそれを外からの刺激として向上させるのかというのは難しい問題であると痛感したりしました。

どうやってモチベーションを与えるのか

チームメンバーが流動的であることは決して悪いことではありませんし、それによって新しい知識やその人が他のメンバーの模範となることによってモチベーションが生まれることもあります。

ただ、一般的に人が新しく入ってくるのは、それまでの過程も含めて手続きや教育のコスト、その人が立ち上がるまでの一時的な戦力ダウンを補うための編成などなどを考慮すると大きな労力がかかることです。

組織長から見れば人を一人入れたんだから要員は足りているはずだし戦力もアップしているだろうと考えられたりもするのですが、現場をまとめる立場からすればそうも簡単な話ではなく、やっぱり（優秀であって）その環境に慣れていて話を通しやすいメンバーがいてくれた方がチーム運営としては随分と楽なことではあるわけです。

その維持のためにメンバーにどうやってモチベーションを持続させるのか、というのは自分自身のモチベーションを維持する話より難しいことであると思ったりしています。

親の世代ならいざ知らず、自分たちの世代では終身雇用なんてものは全然実感がわかなかったりするもので、現に周りでは人の出入りが多かったりしますからそんなに難しく考える必要が無いことなのかもしれません。

ただ、自分が小さくとも組織というものを管理する立場になったりすると、優秀な人材は長くいて欲しいと思いますし、今要るリソースでその後のプロジェクトの計画を立てるのでその要員が抜けたりすると頭を抱えることになったりします。

その人のモチベーションをあげる方法は、その対象者によって給与だったり、やりがいであったり、職場の雰囲気や仲間であったりと異なってくるのですが、管理するマネージャーの立場からみればその要素を与えること自体が最初から難しいということもあります。

例えば如何に組織を管理する立場でも給与を大幅に上げることは難しいでしょうし、変な会社の文化というものが根付いているところではそれを大きく変えることに抵抗が生まれたり、ある人のために仲間を選定するということも本末転倒なことになったりします。（ここでの話はたいした権限も持たない中間管理職ってことで）

結局のところ、一番それっぽくそして融通が利きそうなところで「やりがい」という言葉を口に出したりもするのですが、それでもその組織のミッションが決まっていることから、システム運用をするチームでバリバリ開発業務を与えるというのは難しかったりもするので、かなり制限をさせられる結果になります。

私の場合も、一番手っ取り早いところで「やりがい」というものを何とかその子に与えてやれないかと考えてたりもしましたが、最終的には本人の希望に沿うことができなかったようです。

「やりがい」というものも当然本人が意図しているところと、会社として与えるものとの差は大きくあったりもして、「そんなことに興味は無い。面白いとは思わない」といわれたらそれまでなんですが、それでもこの「やりがい」という言葉を会社として多用するのは、半ばやりがいという言葉と組織としてのミッションと一緒くたにしてしまおうという打算も見え隠れします。

ですので、最初からその当人に対して（そもそもそれを求めているかも含め）やりがいを与えることでもベーションを維持させることすら難しいケースも多々あるかと思います。

どんな仕事の楽しさを与えられるか

モチベーションというのは自分で見出すものだという意見もあったりします。

現に、そんな啓発本なんかいっぱい目にしたりもしますし、（外部からの助言によって増減するところではありますが）、最終的にやる気というのは自分の内から出てくるものなので、気持ちの持ちようってところもあります。

モチベーションがあがらないといって辞めたはいいものの、結局次の職場でも同じような仕事をしていてまた転職していくという人を見てきてますが、職場が変われば雰囲気も違うしその環境だったらもっと楽しく仕事ができるのかもしれないと考えているのかもしれませんが隣の芝生は青く見えるだけなところも否めません。

給与だけを追い求めて転職を繰り返し、やっぱり定時に上がれる仕事をしてた方がいいなんて愚痴を聞いたりもしますけど、そうやって経験をしないとなかなか本人的にわからないことなのだと感じます。

仕事のモチベーションが給与だけといわれたんなら、（それをどうにかできる権限が自分に無いとして）転職を勧めることも本人のためかもしれませんが、そうではないのであればやはりモチベーションを上げる環境を提供することでそれを向上させてあげるしかありません。

やりがいという言葉について先ほど書きましたが、なんとなく今のこの言葉は本人の内なる気持ちを表す言葉なのに会社が与える使命のように使われている気がしてならないんですが、もっと簡単に言ってしまえば仕事が楽しいって思ってくれることなんではないかと思うわけです。

この仕事が楽しいって言葉は言うのは簡単でもそんな単純ではないのですが、仕事に集中できる環境があり、自身が思い描くキャリアパスを通ることができ、切磋琢磨できる仲間がいて、アイデアが沸いてくる刺激があり、政治的な立場に巻き込まれる面倒がなく、快適なオフィスがあって・・・、と言い出したらきりが無いわけですけど、実際問題それらを全て与えることもよっぽどの大企業でもない限りできませんし、それがよい方向に必ず転ぶわけでもなく賛否両論もあったりします。

結局のところ自分のような小さなチームの中でのエンジニアとしての楽しさを出すためには、同じ開発手法をとらないとか、違った言語やフレームワークを採用するとか、業務のローテーションをさせてインフラからアプリケーションレイヤまで幅広い仕事をさせてみるとか、客先に出して生の声を聞いてみるとか、小さなことでも色々と目新しいことを当人にさせてみるうちにどの分野で楽しさを実感するのかということを試行錯誤ぐらいしかないかなと思ったりします。

一口にエンジニアといっても、技術のコアの細部まで突き詰めていくような博士肌な人もいれば、上流工程でお客さんと話しをするのが好きとか色々タイプも異なりますので。

結局は自分で楽しいと思えることに気が付いてくれ、その仕事をしたいと思ってくれないのとなかなかそのチームに長く居座ってくれないんでしょうけど、その環境やきっかけを与えるために何をしてあげられるのかって考えるのは大事なことではないかと思うわけです。

[PR]

ASUSの公式オンラインショッピングサイトはこちら

[PR]

低価格・携帯対応のSSLをお探しなら　ジオトラストクイックSSLプレミアム

エンジニアの採用におけるジレンマ

エンジニアの情熱と暴走モード

35歳になってもプログラマのモチベーションを保つ方法

部下ができたプログラマーのもどかしさ

5年目のエンジニアと話してアドバイスしたこと

Active Directoryでアカウントロックをした場合、AD上の「lockouttime」属性の値でロックの有無を検知できると思っていたんですけど、できないみたいですね。

ユーザがロックアウトしてるかどうかの判断＠マイナーでもいいよね？？

アカウントロックを解除したい場合、この属性値に「0」をセットすることでロックは解除されるようですが、AD上のグループポリシーでアカウントロックを自動解除する（例えば、ロック後に一定時間経過したらロックを解除する）場合、「lockouttime」の属性は「前回ロックした時刻（最終ロック時間）」が何時までも残ってしまうようです。

その他に、badpwdcount属性を使ってパスワードを間違えた回数を拾えば、グループポリシーに設定している閾値に達しているものはアカウントロックしているはず、という基準のものロジックを組み立ててみたりもしたのですが、このbadpwdcount属性はAD間で同期されるものではなくそのADローカルで管理されている属性のようです。

ってことでかなり途方にくれていたのですが、「msds-user-account-control-computed」という属性を調べればアカウントのロックアウトステータスなどを確認することができるようです。

ADのアカウントロック状態をLDAPを通して検知する

PHPで書いてしまいますが、LDAP使っているのでほかのプログラムでも置き換え可能です。

<?php// ADサーバーのホスト$host = "ldaps://192.168.0.100";// ロックアウトをチェックする対象ユーザー名$user = "username@testdomain.test";// ADサーバーの管理者ユーザー$adminId = "admin@testdomain.test";$adminPass = "FooBar";// LDAPに接続$conn = ldap_connect($host, 636);ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);// 管理者ユーザーでBIND$auth = ldap_bind($conn, $adminId, $adminPass);// msds-user-account-control-computed属性を検索$ldapSearch = ldap_search($conn, "OU=Employee,OU=Users,DC=testdomain,DC=test", "userprincipalname=" . $user, array("msds-user-account-control-computed"));$info = ldap_get_entries($conn, $ldapSearch);$msds = $info[0]['msds-user-account-control-computed'][0];// ロックアウトしているか検証if (($info[0]['msds-user-account-control-computed'][0] & 16) === 16) {    echo $user . "はロックアウト中" . PHP_EOL;} else {    echo $user . "はロックアウトしていません" . PHP_EOL;}

ADへの認証方法やLDAPSを使う場合の設定などは前回書いた「PHPからActive Directoryに認証・パスワード変更する方法」を参考にしてください。

属性の検索は一般的な方法ですが、ロックアウトの検証に関してはちょっと特殊で「msds-user-account-control-computed」の値と16の論理積が16の場合はアカウントロックしているという判断になります。

ms-DS-User-Account-Control-Computed attribute＠Microsoft Developer Network

こちらに値についての説明が書かれていますが、「msds-user-account-control-computed」属性の値はその他のアカウントのステータスを表す数字との積み上げになっています。

アカウントロック（UF_LOCKOUT）を表す数値は16（16進でいう0x0010）となっていて、パスワードの有効期限切れ（UF_PASSWORD_EXPIRED）は8388608（16進でいう0x800000）となっています。

パスワードの有効期限切れかつアカウントロックしている場合の数字はこの足し算の「8388624」となり、このような場合でも論理積は16であるのでアカウントロックしているということがわかります。

予断ですが、ldap_searchは第3引数の検索フィルタに「array("*")」を指定すると全属性を引っ張ってこれるんですけど、その中に「msds-user-account-control-computed」属性はありません（全属性を引っ張ってこれるという思い違いをしていたみたい）。

なので、この属性はLDAPを通して取得できないんだと思い込んではまってました。

[PR]

低価格・携帯対応のSSLをお探しなら　ジオトラストクイックSSLプレミアム

[PR]

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

[PR]

NTTPCのVPS 『WebARENA SuitePRO V3』

PHPからActive Directoryに認証・パスワード変更する方法

最近、採用の広告などでフルスタックエンジニアという言葉を見かけます。

あんまりよくわかっては無いんですが、ネットワークやサーバー、OSなどのインフラ関連からプログラミングやHTMLなど幅広いレイヤーの知識を持っている人を募集しているようです。

個人的にはそんな人がチームに入ってくれるんなら願ったりかなったりだとは思うのですが、技術が複雑さを増していく中でそんなレイヤー1から7とかまでをちゃんとわかっている人なんてそうそういないだろうとかも思ったりするわけです。

フルスタックであることの難しさ

最近は高度なライブラリが揃っていたりクラウド系のサービスによってそんなに知識が無くても新しい仕組みを作ったりすることはできたりします。

ただ、それを支えるエンジニアという職業から見れば、やっぱり一つ一つに対してきちんとしたスキルを持ってないと通用しないわけで、じゃあそれが幅広いスキルを横断的に身につけられるかというと技術の多様化によって決して楽なわけではない状況です。

確かにネット上には技術ネタを書いているエンジニアブロガーや、企業でもその情報を数多く公開していたりもしますので、一昔前よりは困るレベルは低くなっています。

それでも技術の変化などによって新たに会得しないといけない知識は年々増えていっているわけで、確かにインフラからフロントエンドまでかなり密に連携しているわけですからそれらを全てマスターしているに越したことはありませんけど、エンジニアの求められるスキルレベルは上がっていっていると思ったりします。

前に「クラウド時代のエンジニアの活きる道」というエントリで書きましたが、この辺は募集対象のエンジニアの仕事によるんでしょうけど、現在ではクラウドサービスを作る側と使う側とで二極化していったりしてるので、後者ならまだしも前者においてはかなり複雑なスキルが求められます。

そんな中で、フルスタックな知識を求めるなんて、おいおいちょっと待てよって気分にもなってくるわけですけど、確かに技術というのは1つの分野で完結するものではなく、関連性があるものまで知識を持っていないとなかなか解決できない問題もあったりします。

一極集中、この分野だけで飯を食っていくんだと言ったところで、例えばプログラミングだけであったとしても、通信においてはネットワークが、ファイル操作においてはOSやファイルシステムの知識も要るわけですから、なかなかプログラムの知識が非情に長けているから良いというわけにもいきませんし、そういった関連性のある知識は必然的に持っていないとプロフェッショナルな領域まで到達することもできません。

まぁ、そんなギークな世界につかっている人にとってはフルスタックエンジニアなんて言葉を聞いても鼻で笑えばよいわけですが、私のような凡人エンジニアにとっては1つのコアとなるスキルを磨きつつ、関連があるところも通信簿で言うところの普通レベルの知識を持つところで結構四苦八苦しているわけです。

フルスタックに夢見るエンジニア

何よりこの言葉について疑問に思うのは、あたかも幅広い知識を求め、そしてそれに応じた様々なレイヤーでの仕事ができるように謳っているところなわけですけど、ブッフェで自分が好きなものを取って食べるかのように自分の興味のある仕事だけができるとは限りません（多くの場合できないでしょう）。

会社としては幅広い知識を持っている人がきてくれたほうが当然助かります。
プログラムができ、ネットワーク機器の設定もでき、サーバーのセットアップやミドルウェアにも理解があれば色んなプロジェクトや状況に応じて（というのは多くの場合は炎上している場合かもしれませんが）その人のポジションを変えることができます。

これはある意味、会社にとって都合のいい人となるリスクもあったりします。

わからないことがあったらあの人に任せればいいとか、この分野を担当できる人がいないからやってもらおうとか。

それによって希望する経験と知識を得ることができたのならよいかもしれませんが、そうではなく自分が持っている知識を淡々とこなせば済むようなタスクの繰り返しになることもあります。

それは最初は楽しいことのように感じるかもしれませんが、新たに得るものがなくそのうちその技術も枯れていってしまっては将来的にエンジニアとして活きる道が無くなる可能性もあります。

そもそも全てのレイヤーの仕事がその人に任せることができるほどシステム構築の作業は単純ではないので、酷く疲弊しなくてはならない仕事となるか、先ほど書いたように都合のよいポジションに当てはめられるということも考えておかなくてはなりません。

そういうことを考え出すとフルスタックというスキルを求められる仕事というのは、物理的に不可能な仕事を求められたり、酷く単調な仕事を求められたり、という感じで個人的にあまり良いイメージを持つことはできないなとか思ったりもするわけです。

エンジニアと一言でいっても色んなレイヤーの仕事があり、それぞれに面白そうと興味を引かれることもあるでしょう。

ただ、その多くを体得することはかなりの時間を使わなくてはならないことで、やっぱり自分の中で得意とするもの、面白いと思うものをきちんと見つけて、そこから異なるレイヤーにも知識や興味を広げていくということをしないと、フルスタックという言葉に惑わされて横断的なスキルはあるものの中途半端となってしまっては都合のよい扱われ方しかされなくなってしまうのではないかと思うわけです。

まぁ、そういう人って知識の幅があることを理由に最終的には上流工程の担当や管理職に当てはめられたりするんですが、本人が納得するなら全然かまわないわけですがエンジニアとしての道はなくなるわけで、どういうキャリアパスを描くかしっかり考えておく必要があるなって思います。

[PR]

企業向けIT製品／キーマンズネット

[PR]

禁断の無制限解禁！【ディスク容量無制限のレンタルサーバー】

[PR]

やりがいしか与えられない僕ら

何故ソフトウェアは複雑化し続けるのか

エンジニアの採用におけるジレンマ

システム運用後のトラブルはリスクを誇張させる

起業家が開発者の管理で犯しやすい11の失敗＠ readwrite.jp

運用業務担当者が変化を嫌うまたは変化できない理由

エンジニアの情熱と暴走モード

開発チームと運用チームの戦い

変わらない情報システム部としての使いどころ

起業家ではないにしろ、システム開発においてはエンジニアとの付き合いというのはうまくしていくに越したことはありません。

例えエンジニア同士であったとしてもその管理というのは結構難しくて気を使うものだったりします。

エンジニアとしての立場を尊重すること

仕事をしていく上では役割というものがあるわけですので、担当しているエンジニアの領域というものをきちんと尊重してあげる必要があります。

よくありがちなのが非エンジニアが技術的なことに口出しをしてしまい、過去に自分が使ったことがあるツールであったり、他のサービスで利用している仕組みをそのまま当てはめようとするようなケースがあったりして、こういったことはエンジニア自身によって、そのシステムの組み上げ方やアーキテクチャとの相性やインフラにおいての特性などを考慮して決めるべきだったりします。

そういったことを考えて決めようとするときにこういった横槍を入れられるとエンジニア自身のモチベーションが下がるだけでなく、システム構成がめちゃくちゃになって保守性が落ち、サービスの寿命を縮める結果になるかもしれません。

エンジニア同士であれば、それが先輩後輩としての教育の一環ということであれば大きく介入せざるを得ない場合がありますが、異なる役割のエンジニアとしてならその立場をある程度尊重してあげないと同じ結果になるかもしれません。

一言でエンジニアといっても専門分野が大きく異なりますし、インフラならインフラ担当としての意見もありますが、それによってアプリケーションの構成に大きな偏りが出てしまったりもするのでそれぞれの立場としての意見をきちんと言い合えるのが重要ではないかと思います。

技術的な苦労を理解する

技術が如何に進歩したからといって、システムを組み上げていく苦労が単純に減っていくわけではありません。

前回の「フルスタックエンジニアなんて目指さない方がいい」の中で書きましたが、エンジニアが会得しなくてはならないスキルというのは多様化しているので求められるスキルレベルはどんどん上がってきているかと思います。

ですから、システム構築の際に技術的な課題にぶち当たり悩むこと自体が減っているわけでもなく、また技術的な進歩によって悩むレベルが低くなっているわけでもありません。

まぁ、エンジニアを管理する立場の人がエンジニアとしての業務を経験した人ばかりというわけではなかったりするわけですが、技術的な問題で悩むエンジニアは結構孤独で戦っていたりもするので、その状況を把握してあげて、技術的なこと以外での解決方法（例えば運用的な回避やそもそもその課題を先延ばしにすることでスケジュール的な負担を軽減できないかとか）がないかを一緒に模索してあげることも必要です。

ここでわかっていないことをジャストアイデアで言ったりするとさっき書いたようなケースに陥ったりもしますし、エンジニアの立場からすればわかっていない人に言われたくないって思いもあったりして（非エンジニアからすればその技術的な課題が何で解決できないのかがわからないので）、こういったナーバスな状況においては双方の言い分の応酬になるので注意が必要です。

もちろんエンジニアとしても、それ以外の役割で動いている人の立場を理解してあげる必要はあるかと思いますが。

作ったものを否定しない

例え他人のアイデアだったとしても作ったプログラマは作ったシステムに誇りや愛着をもっていたりもしますので、その仕様を考えた本人がそれを否定したくなったとしても言葉を選ぶ必要があります。

サービスの要件はそれを作ったときから流行りなどによって常に変化していきます。

ですので、リリース後に全く異なるものを作りたくなる気持ちもわからなくはないのですが、作ったものを否定するのは（例えそれがそのサービスの仕様や特徴という意味であったとしても）、エンジニアから見れば自分たちが作ったものが否定されるものと同じ意味に捉えられかねません。

大事なのはきちんとサービスのロードマップを作り、各フェーズを終えて次のステップに移っていることを共有しておくことです。

行き当たりばったりで作っては壊しというステップを踏むのはエンジニアの疲弊を招き次のモノづくりをしようとする意欲を削いだりします。

集中できる環境を作る

エンジニアとしての役割に注力して欲しいならその業務に集中できる環境を提供してあげる必要があります。

しかしこれは組織や会社の多くのルールによって阻まれます。

出なくてもよい会議であったり、作っても読まれないドキュメントであったり、教育という名の下に使わない知識を埋め込まれたりするわけです。

そういったものをなるべく取り除き、集中すべき仕事に割く時間を確保してもらうことが必要にはなりますが、これには多くのサポートが必要です。

エンジニアがそれをやらなくて済むように周りが多少の犠牲を払う必要もあるからで、それは本来やら無くてもいい仕事を自分や周りがかぶることにもなったりします。

もちろんエンジニアとしてはそういった環境を作ってもらえることに感謝を示すべきでしょうけど。

何を作るかをはっきり決める

特に経験の浅いエンジニアはタスクの優先順位を見誤ったりします。

技術的な興味が先行するあまり重要ではない機能を深掘りしたり、気まぐれで言ったことがエンジニアの心に火をつけて突っ走っていくことはよくあることで、後々それが大して重要なものではないとわかったりお蔵入りするような結果になったらエンジニアのその熱意が台無しとなります。

ですから何が重要で何が重要ではないかははっきりと決めておく必要があります。

この際に、サービスとしての優先順位と技術的な組み立ての意味での順序の折り合いをきちんと付けておくことです。

サービスとしては、この機能ができたら次にこれを作りたいという願望を持っていても、技術的な側面から見ればその順番の前にこの機能実装が必要だという順序がエンジニアの頭の中にあるので、それを互いに合意しながら進めていく必要があります。

これはサービスのリリーススケジュールに大きく影響がでることなので双方できちんと確認しておかないとプロジェクト管理上でもまずいことになりかねません。

[PR]

独立・開業・起業のサポート情報の検索・資料請求サイト「アントレnet」

[PR]

集客にお困りの方は必見。Yahoo! JAPANが提案する集客アップの方法。

[PR]

ビジネスの最前線で勝ち残るための必要な情報が凝縮　日経ビジネス

やりがいしか与えられない僕ら

エンジニアをイラっとさせない仕事術

エンジニアの情熱と暴走モード

初めからやっておけばよかったとあとで思うシステム構築に関する10のこと

クラウド時代のエンジニアの活きる道

運用業務担当者が変化を嫌うまたは変化できない理由

5年目のエンジニアと話してアドバイスしたこと

Apache Solrには同義語の定義ができます。

要するに検索する際のキーワードやインデックスのAとBは同じ言葉ということを定義できるわけですが、こういったことを人力で行うのは不可能に近いことです。

で、もっとも身近なデータから機械的に同義語データを定義できたらいいなということでWikipediaのデータを使って同義語ファイルを作成してみました。

結果からいうとこの同義語ファイルはまぁまぁ・・・な内容です。

Wikipediaでは厳密に同義語だという扱いをしているわけではなく、情報を正式名称のページに寄せているだけですからそれは同義語じゃないよねってデータも含まれるのですが、その辺の情報を精査するものは別途作る必要があるかと思います。

Wikipediaのデータから同義語となるデータを抽出する

使うのはWikipediaの記事データで、下記のURLに誰でもダウンロードできるように公開されています。

http://dumps.wikimedia.org/jawiki/latest/

で、この中で使えるデータがjawiki-latest-stub-articles.xml.gz（このファイルはあまりに巨大なので、今回使うのは分割しているjawiki-latest-stub-articlesN.xml.gz（Nは数字で2015.01時点では4分割）というファイルを使ってます）というファイルで、この中身はXML形式で記事のタイトルなどが含まれています。

<page>    <title>ヨーロッパ</title>    <ns>0</ns>    <id>32</id>    <revision>      <id>52739692</id>      <parentid>52357980</parentid>      <timestamp>2014-08-31T09:03:15Z</timestamp>      <contributor>        <username>Dexbot</username>        <id>620423</id>      </contributor>      <minor/>      <comment>Bot: Removing Link FA template</comment>      <text id="52784825" bytes="54708" />      <sha1>giuwvpewi1w7k2luxgwmyk2u7pyu08a</sha1>      <model>wikitext</model>      <format>text/x-wiki</format>    </revision>  </page>  <page>    <title>生物</title>    <ns>0</ns>    <id>42</id>    <revision>      <id>52108199</id>      <parentid>51054233</parentid>      <timestamp>2014-06-27T14:18:57Z</timestamp>      <contributor>        <ip>118.153.79.10</ip>      </contributor>      <comment>説明の具体化</comment>      <text id="52146183" bytes="13225" />      <sha1>gjcin6me04awp6g9z5rgwu563x30an8</sha1>      <model>wikitext</model>      <format>text/x-wiki</format>    </revision>  </page>  <page>    <title>コケ植物</title>    <ns>0</ns>    <id>43</id>    <revision>      <id>49410361</id>      <parentid>48129936</parentid>      <timestamp>2013-10-14T02:13:55Z</timestamp>      <contributor>        <username>Zqmykbvoh</username>        <id>140470</id>      </contributor>      <minor/>      <comment>「単相」 lk 修正</comment>      <text id="49421841" bytes="20742" />      <sha1>jp71dgglkk20tqoj11arwm02am8p856</sha1>      <model>wikitext</model>      <format>text/x-wiki</format>    </revision>  </page>

この中で、Wikipediaでよく見かけるリダイレクトをかけている項目を抽出します。

例えば、こういうページ

http://ja.wikipedia.org/w/index.php?title=%E3%83%AA%E3%83%8A%E3%83%83%E3%82%AF%E3%82%B9&redirect=no

これが、元のWikipediaのデータだと下記のようになっています。

  <page>    <title>リナックス</title>    <ns>0</ns>    <id>1016</id>    <redirect title="Linux" />    <revision>      <id>2169766</id>      <parentid>8081</parentid>      <timestamp>2003-03-02T19:47:50Z</timestamp>      <contributor>        <username>Okome</username>        <id>98</id>      </contributor>      <text id="2169766" bytes="19" />      <sha1>ow6122zxo9so312b35n5wtu21s92l0c</sha1>      <model>wikitext</model>      <format>text/x-wiki</format>    </revision>  </page>

redirectという要素があって、そこのtitle属性に転送先が書かれているわけですね。

ってことで、このデータを抽出して同義語ファイルを作るということです。

Solr用同義語ファイルを作成するPHPスクリプト

PHPで作った抽出スクリプトは下記のものです。

<?phpclass CreateSynonymFile {    // Solrの辞書データのパス    public $dicPathIndex = "/path/to/solr/conf/synonyms.txt";    // Wikiの元ファイルがおかれたディレクトリ    public $wikiFileDir = "/tmp/articles/";    function execute() {        // Wikipediaの元ファイルのパスを取得        $wikiFiles = $this->getWikiFiles();        $fileCnt = count($wikiFiles);        for ($i = 0; $i < $fileCnt; $i++) {            $xml = simplexml_load_file($wikiFiles[$i]);            $xmlCnt = count($xml->page);            $fp = fopen($this->dicPathIndex, "w");            for ($j = 0; $j < $xmlCnt; $j++) {                $title    = (string) $xml->page[$j]->title;                $redirect = (string) $xml->page[$j]->redirect[0]["title"];                if ($this->checkSynonym($title, $redirect)) {                    $line = $title . " => " . $redirect . PHP_EOL;                    fwrite($fp, $line);                }            }            fclose($fp);        }    }    /**     * 同義語として登録するかどうかチェックする     * @param string $title    : 元の言葉     * @param string $redirect : リダイレクト先     * @return bool : 同義語登録対象の場合はTRUE、それ以外はFALSE     */    protected function checkSynonym($title, $redirect) {        // 空白は全て除去        $title    = str_replace(array(" ", "　"), "", $title);        $redirect = str_replace(array(" ", "　"), "", $redirect);        // データが空の場合は対象外        if (empty($title) || empty($redirect)) {            return FALSE;        }        // 対象の文字列が3文字未満なら対象外        if ((mb_strlen($title) < 3) || (mb_strlen($redirect) < 3)) {            return FALSE;        }        // Wikipedia関連記事のリダイレクトは対象外        if ((strstr($title, "Wikipedia") !== FALSE) || (strstr($redirect, "Wikipedia") !== FALSE)) {            return FALSE;        }        // 大文字・小文字の違いだけの場合は対象外        if (strtolower($title) == strtolower($redirect)) {            return FALSE;        }        // 「一覧」という言葉が含まれるものは抽象的な用語であるため対象外        if ((strstr($title, "一覧") !== FALSE) || (strstr($redirect, "一覧") !== FALSE)) {            return FALSE;        }        // 「曖昧さ回避」という言葉が含まれるものは抽象的な用語であるため対象外        if ((strstr($title, "曖昧さ回避") !== FALSE) || (strstr($redirect, "曖昧さ回避") !== FALSE)) {            return FALSE;        }        // ひらがな・カタカナの違いだけのものは対象外        if (mb_convert_kana($title, "h") == mb_convert_kana($redirect, "h")) {            return FALSE;        }        return TRUE;    }    /*     * Wikipediaの元ファイルを取得する     */    protected function getWikiFiles() {        $dir = array();        if (is_dir($this->wikiFileDir) && $dh = opendir($this->wikiFileDir)) {            while (($file = readdir($dh)) !== false) {                if (preg_match("/jawiki-latest-stub-articles[0-9]+.xml/", $file)) {                    $dir[] = $this->wikiFileDir . $file;                    break;                }            }        }        closedir($dh);        sort($dir);        return $dir;    }}

やってることはそんなに複雑じゃないんですけど、simplexml_load_file()をつかってXMLを解析し、redirectの項目の有無とその転送先（title属性）を抽出しています。

checkSynonym()では、同義語として登録するかどうかの関数ですが、この辺が最初に書いたようにまぁまぁな内容をどこまで精査できるかってところで、Wikipediaのデータには下記のような曖昧さ回避をする言葉もありますから、その辺は同義語として登録すべきかどうか判断が必要です（今回の場合は無視）。

http://ja.wikipedia.org/wiki/%E3%82%AB%E3%83%BC%E3%83%8D%E3%83%AB_(%E6%9B%96%E6%98%A7%E3%81%95%E5%9B%9E%E9%81%BF)

出来上がったSolrの同義語ファイルは下記のような感じのもの。

森田一義 => タモリ.NET => .NET FrameworkOSI基本参照モデル => OSI参照モデルクーロン相互作用 => 電磁相互作用場の理論 => 場の量子論

こういった例は全然いいんですけど、

エロス物 => エロス作品

これは、人の解釈によるんじゃないかとか、

錯乱坊 => うる星やつらの登場人物

そんな同義語必要ないんじゃないかとか、

将棋棋士 => 棋士 (将棋)

元の語のほうがわかりやすいと思うとか、まぁリダイレクトの処理からの抽出ですし、あくまでWikipedia上でのデータになりますから情報の精査は追加対応が必要そうです。

[PR]

NTTPCのVPS 『WebARENA SuitePRO V3』

[PR]

世界にたった一つ、あなただけのドメインを登録しよう！

[PR]

Apache Tikaを使ってドキュメントの中身を取り出すPHPプログラム

Solrのインデックスデータを他のサイトへレプリケーションする

Solrの形態素解析で使えるフィルタあれこれ

Apache Solrにおける特殊文字の意味と扱い方

Apache Solrのschema.xmlを読み解く

Apache Solrをマルチコアに対応させる

Apache Solrを利用して本格的な検索エンジンを導入する

「好きなことで生きていく」ことの現実＠狐の王国

好きなことを仕事にして生活できたら素敵だなと思う。

自分は元々ゲーム好きというところがあって、将来はゲーム会社に入りたかったりしたんですが、就職活動でことごとく蹴られ、今の会社に勤め似たような職種としてプログラマをやっていたりするわけですが、結果論から言えばこれはこれでよかったんじゃないかと思ってたりもするわけです。

自分としては、好きなものが社会人になってから見つかったって感じだからです。

好きのレベルがそんなもんだった

まぁ、ゲーム好きっていってもよくある子供のころにゲームのハードもってたからよく遊んでましたってレベルで、「俺ならこんなゲーム作るのに」とかって妄想を抱いていたようなもんだったわけですよ。

子供のころの付き合いのレベルで言えば、俺はあいつより高得点が出せるとか、隠れ技を知っているとかのもんで、その範囲で自分のやりこみレベルが高いと勘違いして好きなんだって思い込みをしていたわけですが、いざ就職活動して説明会とかに集まったライバルの多さや募集要項を見てみると自分にない高いスキルレベルを求められているわけで、そこで現実を知ったわけです。

プログラマとして応募したのに大学時代にろくにプログラミングをしてこなかったから当然そういった競争社会で勝ち抜く術もなく「他の人にはない観察眼を持ってます」とか「周りにないアイデアの出すことができます」とかスキルがない故の恥ずかしい言葉を並べて何とか背伸びしようとしていたんですけど当たり前に受け入れてくれるところもなく。

で、今の会社に応募したらあっさり採用されたんでプログラマとしての人生を始められたわけですが、最初は仕事に対してモチベーションとか全く無かったんですけど好きとか嫌いというレベルではなくただただ必死にやってました。

恵まれた環境だったこともあり、のびのびとプログラミングを学ぶことができたおかげで作る楽しさというのを知ることができ、そこで新しい好きなことができたわけです。

本当に好きを貫く人ならとことん突き詰めていくところが、自分では勘違いしていた好きというレベル感の現実を知って、一気にその気持ちが萎えてしまったところがあります。

ですから「好きなことやってるだけで仕事にできるなんていいね」って思っている人でも、当人にとってはその壁を突き抜けても好きを貫き通しているわけで、相当な覚悟がないとできないんじゃないかと思うわけです。

当人はそれが好きって思っているから覚悟なんてものは感じてないんでしょうけど、例えばゲームを一日8時間プレイするのを毎日かかさずするとか、ゲームの中の敵のステータスやダンジョンのマップを全てメモするとか、隠れ技が無いか延々とやりこむとか、全ストーリーを網羅するとか、仕事同様にそれにかける時間は膨大になるわけで、そういうことができるかって言われたら自分は多分無理なような気がします。

改めて考えると今のレベルで言えばそこそこプログラミングのスキルも身についてきて、頑張ればちょっとしたゲームを作るということも可能なような気もするのですが、その気持ちも今のところ沸いてこない。

就活の時に心が折れたというのもあるかもしれませんがつまるところ、好きって言ってもそんなもんだったんだと。

好きの定義

ゲームを作りたいというのも、ゲームを通して他の人を楽しませたいとかそういった観点があったわけで、こうしたことは今やっているビジネスツールやサービスの構築においても同様のことが当てはまるということに気がつきました。

業務で困っている人がいて、それを解決することで仕事が楽になったり、仕事をするのが楽しいと思えたり、そういった観点は自分が好きと思っていたゲームを作りたいという原点の奥底にあったものだと気がついたからこそ、今の仕事を続けてられるんだと思います。

YoutubeのCMに「好きなことで生きていく」というキャッチフレーズが出てきますが、決して「Youtubeで生きていく」ということをいっているわけではありません。

あくまでYoutubeはツールでしかなくて、好きを表現する手段でしかないわけですから、そもそも好きという定義をあまり狭く限定的に考える必要はないんじゃないかと思います。

これが好きだ、これを仕事にするんだ！って気持ちは大事ですし、とことん突き進むパワーがあれば問題ないでしょうけど、そうではない場合は何でそれが好きなのかという分析をしてみれば新たな好きなことというのも見つかるかもしれません。

その好きを実現する職業は一つとも限りませんし、それを表現するサービスも決して一つではないはずで、色んな役割や立場で好きなことを実現する方法ってあるんじゃないかと思います。

とまぁ、偉そうなことをいって見ても、いくら開発業務自体が好きになったからといっても社会人の仕組みや組織としてのごたごたに辟易することも多々あって、なんかすごいアイデアが舞い降りてそれをプライベートで作った仕組みが大当たりして、一日2,3時間適当に運用するぐらいで生活費を稼げるぐらいのサービス作れないかな俺、とか思ったりしている今日この頃です。

[PR]

重いパソコンがサクサク動くウイルス対策ソフト

[PR]

スマホやTV、PCで、いつでも映画や海外ドラマを見れる！今すぐ無料視聴！

ストレス耐性なんてものはない

やりがいしか与えられない僕ら

面倒な事はおまかせ！＠ＹＭＣの「マネージドサーバー」月額3,675円～

[PR]

多くの人に受入れられるための「無難」という考え

RedHatやCentOSなどでパッケージをインストール/アンインストールするコマンドとしてyumやrpmコマンドがありますが、その辺に関連して保守・運用上で個人的によく利用するコマンドやオプションなどのまとめです。

yumコマンドの基本的な使い方は「yumによるRPMパッケージの更新管理」を参考にしてみてください。

・リポジトリに公開されているパッケージを検索する

yumコマンドを使ってインストール可能なパッケージをリポジトリから検索します。

# yum search httpdLoaded plugins: rhnplugin, securityThis system is receiving updates from RHN Classic or RHN Satellite.Excluding Packages in global exclude listFinishedExcluding Packages from Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)Finished=================================================================== Matched: httpd ===================================================================mod_ssl.x86_64 : Apache HTTP Server 〓 SSL/TLS 〓〓〓〓〓system-config-httpd.noarch : Apache 設定ツールhttpd.x86_64 : Apache HTTP Server

・インストールされているパッケージを検索する

インストール済みのパッケージを検索します。

# rpm -q httpdhttpd-2.2.3-83.el5_10

または、yumコマンドでも。

# yum info httpdLoaded plugins: rhnplugin, securityThis system is receiving updates from RHN Classic or RHN Satellite.Excluding Packages in global exclude listFinishedExcluding Packages from Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)FinishedInstalled PackagesName       : httpdArch       : x86_64Version    : 2.2.3Release    : 83.el5_10Size       : 3.2 MRepo       : installedSummary    : Apache HTTP ServerURL        : http://httpd.apache.org/License    : Apache Software LicenseDescription: The Apache HTTP Server is a powerful, efficient, and extensible           : web server.

・インストールされているコマンドがどのパッケージに含まれるか調べる

コマンドはわかるんだけどどのパッケージに含まれてるんだっけって時はrpmコマンドで調べられます。

# rpm -qf /usr/bin/sarsysstat-7.0.2-13.el5

詳細が知りたければ

# rpm -qi httpdName        : httpd                        Relocations: (not relocatable)Version     : 2.2.3                             Vendor: Red Hat, Inc.Release     : 83.el5_10                     Build Date: 2013年09月27日 20時41分07秒Install Date: 2013年10月28日 13時56分32秒      Build Host: x86-001.build.bos.redhat.comGroup       : System Environment/Daemons    Source RPM: httpd-2.2.3-83.el5_10.src.rpmSize        : 3324015                          License: Apache Software LicenseSignature   : DSA/SHA1, 2013年10月11日 23時26分24秒, Key ID 5326810137017186Packager    : Red Hat, Inc. URL         : http://httpd.apache.org/Summary     : Apache HTTP ServerDescription :The Apache HTTP Server is a powerful, efficient, and extensibleweb server.

※ オプション「-qfi」として、コマンドから詳細を調べることも可能。これは、該当のライブラリがどのパッケージに含まれているものか（どこからインストールされたか）を調べることもできて便利です。

# rpm -qf /usr/lib/libssl.soopenssl-devel-0.9.8e-32.el5_11

・パッケージの依存関係を調べる

yumコマンドでインストールする際には自動的に依存関係を調べて関連するパッケージもまとめてインストールしてくれたり、エラーがあった場合でもどのパッケージと依存関係にあるのか表示してくれたりはしますが、rpmコマンドで調べることもできます。

# rpm -q --whatrequires httpdsystem-config-httpd-1.3.3.3-1.el5mod_ssl-2.2.3-83.el5_10httpd-manual-2.2.3-83.el5_10httpd-devel-2.2.3-83.el5_10httpd-devel-2.2.3-83.el5_10

・ログから調べる

（コマンドではないですが）現在インストールされているパッケージの一覧は、「/var/log/rpmpkgs」に出力されています。（これは、コマンドから「rpm -qa」を実行したのと同じ）

Deployment_Guide-en-US-5.8-1.el5.noarch.rpmDeployment_Guide-ja-JP-5.8-1.el5.noarch.rpmGConf2-2.14.0-9.el5.i386.rpmGConf2-2.14.0-9.el5.x86_64.rpmGConf2-devel-2.14.0-9.el5.x86_64.rpmMAKEDEV-3.23-1.2.x86_64.rpm- snip -

いつ、そのパッケージがインストールされたのかは「/var/log/yum.log」を参照します。（「rpm -qi」で出力される「Install Date」を見てもわかりますがその日・週のログとしてまとまるので見やすい）

Jan 25 08:00:35 Updated: openssl-0.9.8e-32.el5_11.x86_64Jan 25 08:00:35 Updated: 1:cups-libs-1.3.7-32.el5_11.x86_64Jan 25 08:00:36 Updated: openssl-0.9.8e-32.el5_11.i686

・パッケージの更新を通知する

バグ/セキュリティフィックスのパッチが提供された場合にいち早く情報を取得できるように更新通知をメールで受け取ったり、自動適用したりすることができます。

設定は、/etc/yum/yum-updatesd.confにて行います。

[main]# how often to check for new updates (in seconds)run_interval = 86400# how often to allow checking on request (in seconds)updaterefresh = 6000# how to send notifications (valid: dbus, email, syslog)emit_via = emailemail_to=webmaster@example.comemail_from=yum-updatesd@localhostsmtp_server=localhost:25# should we listen via dbus to give out update information/check for# new updatesdbus_listener = yes# automatically install updatesdo_update = no# automatically download updatesdo_download = yes# automatically download deps of updatesdo_download_deps = yes

説明が書かれているのでなんとなく項目の意味はわかると思いますが、run_intervalでチェック間隔を調整したり、email_xxxx関連でメール通知の設定、db_updateなどでは自動更新するかどうかの設定ができます（本番環境とかで自動適用はしないほうがいいでしょうけど）

設定が終わったらデーモンを再起動。

/etc/init.d/yum-updatesd restart

・パッケージをダウンロードする

yumdownloaderコマンドを利用すれば、サーバーにインストールすることなくRPMパッケージだけをダウンロードすることができます。（yumdownloaderコマンドはyum-utilsに含まれています）

# yumdownloader --destdir=/tmp httpdLoaded plugins: rhnpluginThis system is receiving updates from RHN Classic or RHN Satellite.httpd-2.2.3-91.el5.x86_64.rpm

ちなみに、yumコマンドでもdownloadonlyオプションを使えばダウンロードすることができます。

# yum install --downloadonly --downloaddir=/tmp httpd

[PR]

【早い者勝ち！】　.com／.net／.jp　ドメイン取るならお名前.com

[PR]

yumによる多数のサーバーへのパッチ適用を自動化する

Linux OSユーザーの色々なリソースを制限する

chkconfigに登録されていないデーモンのランレベルをいきなり変えてはいけない

PHPのcURL関数を使えば、外部アクセスが容易にできてデータを送信したり、スクレイピングするのが容易になりますが、特に社内環境などプロキシを通さないといけない環境でcURL関数を使う場合にはまったことのメモです。

cURL関数でプロキシを通す

一般的に、プロキシを使って外部にアクセスする場合のプログラムは下記のようになります。

<?php// アクセスするURL$url = "https://www.google.co.jp";// プロキシを通すかどうかのフラグ$proxyFlg = TRUE;$ch = curl_init($url);$defaultOption = array(CURLOPT_HEADER         => FALSE, // ヘッダを出力しない                           CURLOPT_RETURNTRANSFER => TRUE, // curl_exec()の戻り値を文字で受取る                           CURLOPT_FAILONERROR    => TRUE // HTTPステータスコード400 以上の場合に 処理失敗と判断                          );curl_setopt_array($ch, $defaultOption);// プロキシを通さないといけないURLの場合if ($proxyFlg === TRUE) {    $proxyOption = array(CURLOPT_PROXY     => "http://proxy.example.com",                         CURLOPT_PROXYPORT => 8080);    curl_setopt_array($ch, $proxyOption);}// サイトにアクセス、エラーの場合メッセージを出力if (($response = curl_exec($ch)) === FALSE) {    echo curl_error($ch) . PHP_EOL;}echo $response;curl_close($ch);

上記のプログラム内ではプロキシを通すかどうかは便宜上、先頭にフラグを立ててしまっていますが、実際にはそのURLがプロキシを経由する必要があるかどうかの判別が必要です。

で、本題のところですが自分の環境では上記のようにプログラム内部においてプロキシを通すかどうかの判別処理を入れていたのですが、どうもサイトからHTTPステータスコードの403が返ってきて悩んでいたわけです。

アクセス先のサイトにACLは切っていたものの、ログを見てもどうもそこまで到達していないらしく事前にアクセスを拒否されているようでした。

で、後述するデバッグ方法で通信情報を見てみるとプロキシが通るようになっており、プロキシ側で403を返されていました。

内部的なプロキシを通す/通さないの判別処理は正しかったのでなぜプロキシ経由になるんだって悩んでたわけですが、原因はApacheの環境変数にありました。

rootユーザーの.bash_profileに下記のように環境変数を埋め込んでおり、それがApache起動時に読み込まれていました。

export HTTP_PROXY=http://proxy.example.com:8080export HTTPS_PROXY=http://proxy.example.com:8080

phpinfo（またはgetenv()）で環境変数をみてみると、確かにプロキシの情報がセットされています。

var_dump(getenv("HTTPS_PROXY"));string(29) http://proxy.example.com:8080

ってことで、プログラム内の処理以前に環境変数によって強制的にプロキシを通るようになっていたわけです。

コマンドラインでどうプログラムを実行すると実行ユーザーが違うためにこの環境変数の影響を受けないのに、ウェブアクセスだとうまくいかないからかなりはまったりしました。

先のプログラムの中でアクセス先のサンプルとしてGoogleサイトを指定していますが、ここではHTTPSでのアクセスとしています。

これにも理由があって、HTTPSでのアクセスだと環境変数内のHTTPS_PROXYが有効になるのですが、HTTPでのアクセスだと環境変数のHTTP_PROXYは読み取ってくれず、PHP内のCURLOPT_PROXYオプションをcurl_setopt()でセットしなくてはなりません。

なんで、HTTPSのときだけなのかわからないんですが、環境変数の影響を受けたくないなら、先のプログラムを下記のように意図的にプロキシを通さない場合はCURLOPT_PROXYオプションをクリアしてしまうほうがよいかもしれません。

if ($proxyFlg === TRUE) {    $proxyOption = array(CURLOPT_PROXY     => "http://proxy.example.com",                         CURLOPT_PROXYPORT => 8080);} else {    $proxyOption = array(CURLOPT_PROXY     => "",                         CURLOPT_PROXYPORT => "");}curl_setopt_array($ch, $proxyOption);

cURL関数のデバッグ方法

他のサイトにアクセスするので、エラーがあった際にはcurl_error()の内容から受け取ったHTTPステータスコードなどである程度のデバッグができますが、403とか返ってくると今回のようにどこで蹴られているのか（プロキシからのエラーなのか、該当サイトのACLに引っかかっているのかなど）がわかりづらくなります。

ってことで、通信状況なども見たいのであれば、下記のようにデバッグのオプションを入れることで、cURL関数がどういう経路で通信しようとしているのか見ることができます。（先のプログラムの一部抜粋版です）

// 通信内容を保存するためのテンポラリファイル$fp = tmpfile();$ch = curl_init($url);$defaultOption = array(CURLOPT_HEADER         => FALSE, // ヘッダを出力しない                           CURLOPT_RETURNTRANSFER => TRUE, // curl_exec()の戻り値を文字で受取る                           CURLOPT_VERBOSE        => TRUE, // デバッグを有効化                           CURLOPT_STDERR         => $fp, // デバッグ情報は標準エラー出力されるためファイルに書き出す                                                                 CURLOPT_FAILONERROR    => TRUE // HTTPステータスコード400 以上の場合に 処理失敗と判断                      );curl_setopt_array($ch, $defaultOption);// サイトにアクセスif (($response = curl_exec($ch)) === FALSE) {    echo curl_error($ch) . PHP_EOL;}// 記録した通信内容を読み出すfseek($fp, 0);while (($line = fgets($fp)) !== FALSE) {    $tmp .= $line . "<br />";}// 通信状況を出力echo $tmp;

主な変更点は、CURLOPT_VERBOSEとCURLOPT_STDERRオプションを追加すること、そしてその内容を一時ファイルに書き出し、最後に出力させるというだけです。

以下のような結果が受け取れたりします（これはプロキシで拒否されて403を返されていることがわかる）

The requested URL returned error: 403 bool(false) * About to connect() to proxy proxy.example.com port 8080 * Trying 192.168.1.2... * connected * Connected to proxy.example.com (192.168.1.2) port 8080 * Establish HTTP proxy tunnel to www.example.com:443 > CONNECT www.example.com:443 HTTP/1.0 Host: www.example.com:443 Proxy-Connection: Keep-Alive < HTTP/1.1 403 Forbidden < Cache-Control: no-cache < Pragma: no-cache < Content-Type: text/html; charset=utf-8 < Proxy-Connection: close < Connection: close < Content-Length: 2943 < * The requested URL returned error: 403 * Received HTTP code 403 from proxy after CONNECT * Closing connection #0

[PR]

禁断の無制限解禁！【ディスク容量無制限のレンタルサーバー】

[PR]

スマートフォンならワイモバイル

[PR]