A Day In The Boy's Life -20ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

とある案件で新しいPHPのフレームワークを使おうという話になり、結論としては最近流行のLaravel を使おうということになったのですが、どういったステップで選定作業をしていったのかのまとめを書いてみます。

どちらかというと選定ステップに重点を置いて書いているのであまり技術的なことは書いてません。



まずはどんなフレームワークがあるのか


ググって見たら色んな情報が出てくるわけですが、下記のQiitaのまとめがPHP以外にも様々な言語のフレームワークの情報が掲載されていて役立ちました。


2014年 Webアプリケーションフレームワークトレンド(PHP / Java / Ruby / Python / Perl) / Qiita


2014年って言っても年末に書かれているので比較的新しいソースになってます。

さて、この中から何を選ぶかということになりますが、PHPのフレームワークだけでも17も載っていてこれらを一つずつ調べていくほど時間はありません。


ある程度自分が見聞きしたことがあるってもので対象を絞ってもよいですが、フレームワークを使うに当たって情報量の多さって命綱になるので、その辺で候補を絞るのが無難かもしれません。

こうなってくると、このまとめが書かれた時点でのGoogleのインデックス数から


・ FuelPHP

・ Zend Framework

・ CakePHP

・ CodeIgniter

・ Symfony

・ Laravel

・ Yii


といったフレームワークが候補として出てきます。

個人的にはCakePHPが好みだったりもしたり、Symfony1系を使ったことがあったりでその後継(2系)でいいじゃんみたいな意見もあったりしたのですが、もう少し客観的に見て選んだ方が後々後悔しなくて済みそうです。

ここからさらに絞り込むに当たって、どんな基準で選定していかないといけないかをまとめて見ます。



情報量の多さで選ぶ


先ほど書いたように新しく習得するフレームワークの情報量の多さってかなり大きなウェイトを占めたりします。

もちろん、ネット上の情報だけで判断する必要も無いので、きちんとまとめられた優良な書籍があれば事足りたりもしますが。


後は、情報量が多いといってもなるべく日本語の情報であったほうがありがたかったりもします。

エンジニアたるもの英語圏の情報ぐらい読めってのは全くその通りだったりもするのですが、その案件に多くのエンジニアが携わることになった場合、やはり日本語の情報が多い方が学習コストやトラブル時の対処において調査に大きな時間をとられずに済むので助かります。


で、日本語の情報量ということになった場合、先ほどのQiitaのまとめではStackOverflow のタグ数も参考値に入れていますが、StackOverflowは主に英語圏でのエンジニアQAサイトのため、これが活発というのは主に海外での流行を表していたりもします。

日本語用のサイト もあったりしますが、本家よりもだいぶ情報量が少ないですし、大体困ったときにググってヒットするのって英語圏の人たちのやり取りだったりもします(それはそれで役立ったりもしているのですけど)。


一方で、Qiitaのタグ数を見るとこれは日本人エンジニア向けのQAサイトではあるため、(あくまでタグ数なので一概には言えませんけど)比較的日本においてのエンジニア数や情報の多さを表しているため、こちらを参考にした方がよさそうです。

こうなってくると、CodeIgniterやYiiはどちらかというと海外で主流になっていて、日本ではまだそれほど馴染みが無いように見受けられます。



安定性で選ぶ


もちろん採用する技術が安定しているに越したことはありません。

しかし、フレームワークの世界で言うと安定したレガシーなものはアプリケーション開発手法自体も古臭く安定の見返りに開発コストが増加したり、エンジニアの教育の観点で考えると採用することが望ましくないケースもあったりします。


安定しないといっても、不具合の修正などに伴うバージョンアップが繰り返し行われていればそれをカバーしてくれたりもします。

バグ修正や機能の追加・改修の対応が行われるというのはそのコミュニティが活発に活動している証拠でもあったりしますので、どれくらいのスパンでマイナーバージョンアップが行われているのかや、メジャーバージョンがどれくらいまでサポートされるのかの情報を調べてみるのは大事だったりもします。

(あんまりはっきりと何時までサポートするといったライフサイクルを提示しているフレームワークって無かったりもするんですけど)


このバージョンって結構厄介で、選定の過渡期でメジャーバージョンが発表されたりすると現行の安定バージョンと新バージョンのどちらを採用すればよいのか悩ましい問題に陥ります。

Laravelは現在4系の最新であるバージョン4.2に加えて、最近発表されたバージョン5の両方が並行して開発されていますし、CakePHPも2.6系に加えて3.0系もリリースされていたりしてこれらはアーキテクチャや開発手法が違っていたり、パフォーマンスも(場合によっては最新バージョンの方が悪かったりと)違ったりして、候補としてはメジャーバージョンが違えば別物として候補に上げて選定していった方がよいかと思います。



既存環境との親和性で選ぶ


新しいフレームワークを採用するにしろ、一部は既存の環境を流用しなければならないというケースはあったりします。

例えば、DBは今使っているOracleを使おうといったもので、これは全く新しく環境を作るにしてもシステム要件からどうしてもこのOS環境やソフトウェアを採用しなくてはならないといったことがあったりもするので、その環境に新しいフレームワークが馴染むのかどうかを調査しておくのは重要だったりもします。

(FuelPHPはこの辺で採用が見送られたりもしました)


DBの件で言えば、フレームワークに付属しているORMとかは全てのDBに対応できてなかったり、そのために本家とは別に有識者による別のモジュールを導入せざるを得なかったりもします。

DBの仕様からシステム構成が強要されるケースもあったりして、例えばMySQLのAUTO_INCREMENTはOracleにはない機能なので、別でシーケンスを作る必要が出たりもします。

これは別にフレームワークの問題ではないんですけど、シーケンスが増えるとシステム移行の際に保守・運用で手間が増えたりするので、既存環境を優先すべきなのか全く新しい環境を作ったほうがよいのかはフレームワークを導入するに当たってよく検討しておいた方がいい事項ではあります。


また、既存の社内標準ライブラリを使う必要があるならその組み込みができるかとか、Laravelの話で言えばパッケージ管理にComposerを使う必要があったりするので、いやいやPEAR使い続けようぜみたいなイタタ・・・な反対が出たりすると採用が難しくなったりもするのでその辺はどう環境が変わっていくのかも調べて話し合っておいた方がよいかと思います。



まとめ


あんまり具体的なことをかけては無いのですが、こんなことを基準にさらに候補のフレームワークを絞っていったわけですが、最終的にはサンプルアプリを作ったりして実際に開発するメンバーの感触を掴んでもらってどれがいいか決めていくのが一番よい方法だとは思います。

どのフレームワークにもマニュアルにサンプルアプリの構築手順が掲載されていたりもしますので。


どのフレームワークにも良し悪しがありますし、選定基準から機械的点数化して候補を絞ってもよいでしょうけど、実際に導入するに当たっての障壁がそれぞれの環境やチーム体制、システム要件や顧客の要望などから限定されたりもしますからそれに見合ったフレームワークを選んでいくということも大事だとは思います。




もっと技術力を高めたいとか、知らない分野の知識を貪欲に吸収していって成長していきたいと願うエンジニアって結構いたりしますが、会社の組織の中においてそういう人たちに適切な評価を与えることによってその成長機会を奪うケースって結構あるような気がします。

 

どういうことかというと、組織において一定の評価を得たときにそれ相応の役職が与えられたりして、それによって本来のエンジニアとしての仕事以外のこともせざるを得なくなるというものです。

また、与えられた権威が邪魔して競争力や本来の貪欲さを失ったりすることもあったりします。

 

 

組織のトップとしての仕事

 

会社の中のスキルパスとして、管理職や専門職といった明確な区分けがあったとしても一定の職位まで達した際にのしかかる仕事はあまり相違が無いものになったりもします。

例えば、任される組織内の人員管理であったり、その組織においてミッションを達成するための計画化であったり、その予実管理であったり報告であったり。

こうなってくると専門職としてのスキルパスを描いていたとしても、本来やりたいこととは異なる業務が与えられた職位によってやらざるを得なくなり、技術を磨く機会は減ってきたりもします。

 

よくテレビとかでその分野で実績を出している科学者とかが記者会見で実績の報告をしたりする姿を見たりもしますが、本来そういうことってやりたくないんじゃないかって個人的には心配になったりもします。

もちろん、その実績を誰よりわかっているのは当人であり、その実績を世間に的確に説明する義務があったり、一部ではその組織の広告塔としての役割も一員としてやらざるを得ないのは理解できるのですが、その時間があったら研究を進めたいとか思っている人も多いんじゃないかと思ったりもするわけです。

 

職人気質なエンジニアはこの辺のことにあまり興味が無かったりして、自分の実績や持っている技術力の価値をうまく伝えられずに適切な評価を受けていないケースも多々あったりするので、こういうある程度の職位に付く人ってコミュニケーション能力やプレゼン能力も長けててそんなことを苦労していると思っていないのかもしれません。

ただ、何れにせよ当人が本当にやりたいことに割く時間が奪われていることは確かなので、組織としての役割とその人が望む成長機会とは相反する部分っていうのは出てしまうのだと思います。

 

 

No.2であることの意義

 

自身のスキルを磨きたいと望んでいるエンジニアにとって、組織の中の立ち位置としてNo.1を目指すことにあまり興味はなかったりします。

技術の世界においてNo.1という称号はそもそも判断が難しいことですし、一般社会においてはスポーツのように何か勝ち負けで決まるわけではありません。

その技術分野の第一人者というのはあったりしますけど、それは新しい分野を切り開いた人であり、多くの企業にとってそんな技術的に新しい分野を切り開くという事業をしているのはよっぽど大手のIT企業や業界団体ぐらいしかないのではないかと思うんですけど、つまりは一般企業が抱える優秀なエンジニアにおいてNo.1の称号を与えるのは大小問わず組織の階級と一致させるしかなく、多くの企業はそういった評価基準を採用しているのだと思います。

 

ただ、それによって今日から君がこの分野のNo.1だと言われたところで当人の心境とのギャップもあったりします。

技術を磨いていくというのは自分より優れている人の存在がいることが大きかったりもします。

あの人が書くコードが凄いから自分も負けないようにしたいとか、悩んでいることを聞くと幅広いレイヤーでアドバイスをくれるその知識量にあこがれるとかあったりするわけで、技術を貪欲に磨いていくにはNo.2であることの意義って結構大きかったりもするわけです。

 

もちろん、そんなこと気にせずにスキルアップを目指すエンジニアも多いとは思いますが、それは組織外でもうまく理想の人を見つけられる人だったりして、ある組織の中でしか視野をもてなくなってしまうと途端にそのNo.1の称号が邪魔をして本来の意欲を失わせてしまうことにもなったりします。

これは、その組織に本人をとどめておく意味を失わせることにもなりますし、留めておいたとしても成長機会を与えたと思っている組織と成長機会を奪われたと思う当人との間に溝ができることにもなったりします。

 

だからNo.2にしておけというわけではなく、スキルアップに貪欲なエンジニアへの成長機会の与え方と評価の仕方というのは組織構造とは離れて考えるべきでしょうし、逆に優秀なのに職位が無いから評価が低いというは考え方として正していかないといけないのではないかと思うわけです。

 

 

 

 

以前に「PHPからActive Directoryに認証・パスワード変更する方法 」について書きましたが、このソースコードを開発環境であるローカルのWindows7(+ XAMPP)環境に持ってくるとうまく動作しなかったのでその回避方法についてのメモです。

確認した環境でのXAMPPのバージョンは1.8.2、含まれるPHPのバージョンは5.4.31です。



LDAPが有効になっているかを確認する


まずはXAMPPのPHPがLDAP関数を使えるようになっているかを確認します。

手っ取り早い方法はphpinfo()で見てみることです。


ldap.gif


上記のようにLDAP Supportがenabledになっているかを確認します。

なっていない場合は、PHPの設定でLDAPを有効にしていない可能性があるので、php.iniファイルを編集します。


extension=php_ldap.dll

php_ldap.dllは、php/extディレクトリ内にあるはずです。

設定変更後は、Apacheを再起動し再度phpinfoでLDAPが有効になったかを確認します。



LDAPSを使えるようにする


LDAPS(LDAP over SSL/TLS)を使いたい場合は、OpenSSLの設定も必要になります。

LDAPSを使いたいというのは、


$conn = ldap_connect('ldaps://ldap.example.com');

というような接続をしたいというケースです。

まずは、OpenSSL関係のextensionを有効にしてdllを読み込ませます。


extension=php_openssl.dll

続いて、証明書の検証を無効にするように設定しておきます。

接続先のLDAPサーバーが自己証明書を使っている場合、この設定を入れておかないとチェックに引っかかって接続できません。


c:\openldap\sysconf\ldap.conf

上記ファイルを編集します。

存在しない場合は、新しく作成します。

その後、下記の一行を追加します(中身はこの一行のみで大丈夫です)。


TLS_REQCERT never

これにより証明書のチェックが行われなくなります。

この設定無しに、LDAPS経由でサーバーに接続すると「Can't connect to the LDAP server」が返ってきてうまく接続できませんでした(LDAPだとうまく接続できたり)。

Linuxサーバー上だと、意図的にopensslをインストールしているので設定ファイルとか把握していましたが、XAMPP環境だとオールインワンのせいでどこに何がインストールされているのかよくわからないため、こんな設定ができるとも知らず結構はまってしまいました。