ライブラリをつかって効率的にプログラムを書くぞ！ - Webアプリエンジニア養成読本 AdventCalendar2014 18日目

ついにはてなブログがMarkdownとはてな記法の都度切り替えができるようになった！すげー便利だ！（ただ、なんかリンク埋め込み時とかに、無駄に改行がはいるような？バグかな）

さておき、本エントリはWebアプリエンジニア養成読本アドベントカレンダーです。

Webアプリエンジニア養成読本 Advent Calendar 2014 - Qiita

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

私の担当分においては、こちらの書籍でお話できなかった、初心者向けの事について書いたりしております。

あと一週間ですが、ネタ切れ著しいです、だれかネタをください。

ライブラリとは

ライブラリは、特定の処理を再利用するためにきりだされたプログラムの一部です。なにか処理を行う時に、自分で0から全部の処理をかかなくても、ライブラリをつかえば再利用する事が可能です。あるいは、自分が書けないような複雑な処理をライブラリを使う事で代行するような事も可能です。

「それってたとえばPHPの機能、関数じゃないの？」とPHP初心者の人ならば思うかもしれませんが、まあ、当たらずとも遠からずですね。

世の中には様々なライブラリがありますが、多くの物は公式的にだされているわけではありません。

誰がライブラリを公開しているのかといえば、個人、あるいは企業などが作成して、それを配布しています。

「なんでそんなことをするの？」といわれれば、作ったモノが便利なので、世の中の役に立ちたい*1とか、名前を売りたいとか。あるいは企業ならば自社の製品の販促活動の一環の場合もあります。あと、ライブラリ自体を販売しているケースもあります。

特に、ウェブ系にまつわるプログラミング言語にはオープンソースかつ、ライセンスの自由度が高いライブラリが数多くあり、そういったものは無償で、「ライセンスの範囲で」自由に自分のプログラムに組み込んだりできるので、効率的にプログラムを作成する事が可能になります。

私としても、自作、他作ふくめて、まったくライブラリ等をつかわないでプログラムをかくことはほぼありません。

たとえば…

私が良くつかうライブラリをいくつか挙げてみます。

ライブラリ名	概要
swiftmailer	メール送信
qdmail	メール送信(昔の端末向け)
Woothee	ブラウザ判定
twig	テンプレートエンジン
faker	ダミーデータ生成
Respect/Validation	値チェック
slim framework	軽量ウェブアプリケーションフレームワーク

どれもよく使うような機能です。

こういうのは1から書くのは面倒ですし、自分よりも腕の良いプログラマがかいた処理がつかえれば、プログラム全体の品質だってあがります。

一例として、メール送信

SwiftMailerはメールを送信するライブラリですが、まあPHPにももともとメール送信のライブラリは存在します。mail()関数やmb_send_mail()関数です

mail関数を使う場合には、以下のようにすれば一発ですね。

<?php
mail(
    '[email protected]',
    'title',
    'hello hello!!',
    'From: [email protected]'
    );

しかし、mail関数は日本語がうまく処理できないので*2mb_send_mailを使う事が多いのではないかなと思います。

<?php
mb_send_mail(
    '[email protected]',
    '題名',
    'こんにちは！こんにちは！',
    'From: [email protected]'
);

まあ、ここまではこれらの関数でも特に問題ありません。

じゃあこれにファイルを添付してみましょうか…となると一気にややこしくなります。 私はmail関数で添付ファイルを扱う事は絶対にないのでサンプルコードは掲載しませんが、「mb_send_mail 添付ファイル」とかでググると色々でてきます。

mb_send_mail 添付ファイル - Google 検索

多分、メール周りを手で書いた事がなければ「えっ、なんなの、何でこんな面倒なの」と思うでしょう。メールは歴史があり、様々な仕様が入り交じっていて複雑怪奇なのです。

要は、添付ファイルというのはメールの本文を複雑に処理して、ファイルを埋め込む必要があるのですが、膨大なお作法があるし、相手のメーラーによっては上手く動かない事があったりして非常に面倒なので、自分で書きたくなんかないのです。

そんな時、SwiftMailerなどをつかえば

<?php
// ライブラリ読み込みは省略
 
$mail = \Swift_Message::newInstance();
$mail->setTo('[email protected]');
$mail->setSubject('テストメール');
$mail->setFrom(['[email protected]' => 'うずら']);
$mail->setBody('画像おくるよ！');

$file = \Swift_Attachment::fromPath('/path/to/img.jpg');
$mail->attach($file);
 
$sm = \Swift_Mailer::newInstance();
$sm->send($mail); 

まあ、概ねこんな感じで書く事ができます。これで大体のケースで、相手にきちんとしたメールを送ることができます。*3

希にある、UTF-8でのエンコードに対応できていないメーラーがあり、その場合は私はqdmailという昔からあるライブラリを使っています。本当にqdmailにはガラケーのころにお世話になりました…。ガラケー相手にちゃんと表示できて、絵文字みたいなのもつかえるメールを、mb_mail_sendとかで書くのは結構悪夢です（特にキャリアや機種での動作確認が…）。

このように、様々なメーラーやMTAの動作保証をするのは大変なので、信頼のできるライブラリを利用すればそのあたりの手間を減らす事もできつつ、プログラムの品質があがってよいですね。

PHPには標準ではないような機能

PHPは非常に豊富な関数や機能をそなえているので、ライブラリがなくても一通りのことを行う事は可能です。しかしながら、高機能であるとは言えないものも多くあります。

勿論、PHPに最初から無いような機能もあります。たとえばTwitterへの投稿ですね。

TwitterやFacebookなどのAPI操作は、OAuthと呼ばれる認証をおこなわなければならないので、全部を自分で実装するのは面倒です。そういったものは素直にライブラリを使う方が速いと思います。

また、Amazon Web Servicesなどを始めとして、自社のAPIを利用しやすくするために、自分で作成して配布しているケースもあります。

また、APIなどは仕様がかわったりすることがあり、ライブラリのバージョンをあげるだけでその仕様変更に対応ができることもあり（絶対できるわけではない）、それもまたライブラリをつかうことのメリットになります。

ライブラリをどうやって探すのか？

このように、便利なライブラリですが、一つ不便なのはライブラリを探すという行為です。

基本的にライブラリは、プログラミング言語の組織が「公式」に配布されているものではなく*4、みなが好き勝手に公開していたりします*5。 つまり書籍やphp.netなどにすべてがあつめられたり公開されているわけではありませんので「ここをみれば全部ある！」ということではありません。

とはいえ、ある程度あつめている有志のサイトや書籍はありますので、それらからさがしたり、最近であればGithubなどを自分で検索して探して見つける必要があります。 最近だと、Composerと呼ばれるライブラリ管理ツールの中央レポジトリであるPackagist.orgなどでも検索する事が可能です。 まあ、兎に角「目的 PHP ライブラリ」とかでググったらみつかるかもしれません。

いくつか方法はあるのですが、あなたが初心者であれば、まずは書籍を見てみるのもよいのではないでしょうか。

PHP逆引きレシピ 第2版 (PROGRAMMER’S RECiPE)

PHPライブラリ&サンプル実践活用[厳選100] (Software Design plus)

たとえば、これらのような本があります。

個人的には、こういった書籍はちょっと古いものもあるかな？と思う所もないわけではないのですが、初心者の方には古いやり方のほうがわかりやすいかもしれません。

Composerをつかったライブラリインストールなども解説されていますので、昔のやり方しかしらない方でも参考になるとおもいます。

どれにするか決める

見つけた後も、いくつか注意が必要です

ライブラリはプログラムの一部としてつかいますので、ライブラリがダメになると、当然プログラム全体がダメになります。つまりそのライブラリに自分のプログラムの運命がかかるわけです。

たとえば、PHP5.3未満でしかちゃんとうごかないライブラリを今取り入れるのはありえない選択です。

長くつかうなら、古くさくなく、なおかつバグなどもすくなく、色々な所で利用されて信頼できるかどうかは重要です。

たとえば、以下のようなことを注意できるのではないでしょうか。

• 使い方のサンプルなどがあるか？
• ドキュメントは見やすいか？（重要です、ライブラリの姿勢が見えます）
• 使っている人が多そうか？（ちょっと重要です、困ったときに調べられます、特に日本語の情報）
• バグがたくさん貯まっていないか？（GithubならISSUEなどを見る）
• バージョンがちゃんとあがっているか（放置されていないか）
• ライセンスは、使いやすいか？（後述します）

勿論、後でそのライブラリを別のライブラリに置き換えたり、自分で書き直してしまう事も可能ですが、最初から不安になるような行為をする理由はありません。

あるいは、相談できる人に相談して、問題がないか聞くのもよいでしょう。

ただ、そうはいっても他人に運命を預けるわけですから、ある程度は天に運をまかせることにはなりますし、ひるんでいたら使えるものもつかえなくなってしまいますので、深く考えずにエイヤと導入する時も必要になります。

残念なことに、日本語のライブラリは少ないです、英語のものとくらべて、1/10とか1/100くらいしかないとおもいます*6。英語がどうしても苦手ならば、日本語で紹介されているライブラリを重点的にさがしましょう。

ライブラリをどうやっていれるか？

PHPのライブラリは色々な形態で配布されています。

• コード断片（をソースコードの中にコピペしてつかう）
• zip（などの圧縮ファイルを展開して、ファイルを設置する）
• pear
• Composer

様々な方法がありますが、今はComposerをつかった方法で利用するのが一般的になりつつありますし、私としても一番おすすめです、ぜひ一度しらべてみてください。

いずれにせよ、多くのライブラリ（特に、人気があってつかいやすいもの）は使い方も書いてありますので、それに従って下さい。

たとえばzip配布の場合、大体ダウンロードすると、PHPのソースコードがはいっていますので、適当にファイルを設置してよみこませ、ドキュメント通りに関数やクラスなどをよびだすことになります。

また、特にZIPなどで配布されているライブラリは、ダウンロードした後保存しておいたほうが無難です、突然配布されなくなる（消される）ことも希にあります。

ライブラリでわからないことがあったらどうすれば？

勿論ドキュメントを色々よんだり、自分のプログラムから一端はなれて、最小限のテストコードでライブラリをうごかしてみるのは重要です（自分のコードや使い方がおかしかったらどうしようもないので）。それでもうまくうごかないことは多々有ります。どのライブラリも完全無欠ではないのです。

いきなりライブラリの作者に問い合わせるのは考え物です。後述もしますが、多くのオープンソースのライブラリのライセンスにおいて「なんの責任ももたない」とあります。つまりあなたに説明する責任もありません。返事がもらえないのが当然、くらいでかんがえないとショックを受けるかもしれません。 （「サポートフォーラム」とかかいてあってもレスがつかないことも多い）

まずはやりたい事や、エラーメッセージでググってみたりしましょう。あるいは、詳しくて、質問できる人に質問してみるのもよいでしょう（先日かいた通り、コミュニティに参加するとこのような場合に助かります）。

あるいは、英語ができればStackOverFlowなどの有名なQ&Aサイトで検索したり、質問するのがよいでしょう（先日日本語版のStackOverFlowもオープンしましたが、まだあまり活発ではないですね）。

Stack Overflow - Where Developers Learn, Share, & Build Careers

しかしながら、一番確実で、逆にてっとりばやいのはライブラリのソースコードを読むことです。ライブラリはなんだかんだで結構バグってることが多いのです（が、本エントリを読む方には敷居が高いかもしれませんね…）。もしバグで、なおせたらライブラリ作者にそれを連絡するのは良い事ですね。

ライセンスについて

ライブラリやソースコードには著作権があります。ネット上でググってみつけたソースコードは「つかっていい」と書いて無ければコピペしてつかったりはしてはいけません。

勿論「自由につかっていいですよ！」と横に書いてあったり、解説系のサイトや書籍はある程度参考にしてよい、とか書いてあるでしょうから、それらは大丈夫でしょう（とはいえ、それもわりとふわっとしていて、個人的にはイヤですが）。

ライセンスが定義されているソースコードは、ライセンスを守る限り比較的安心して使う事ができます。逆にいえば、ちゃんとしたライセンスが書いていないソースコードは使えないと思った方がよいでしょう。 （特に仕事なら当然です。「このコードはネットのどこかでひろいました！」とかヤバイ、全部書きなおしになる）

ソースコードが公開されている＝いくらでもコピーしてつかってよい、という意味ではないのです。

大体のライブラリのライセンスは、そのソースコードの先頭か、あるいはLICENSE、などというファイル名で同梱されているとおもいますので、それを読みましょう。

大体の場合、英語で書かれていてウッとなりますが、大体の場合これは定型的なものになっています。

具体的にいえば、MITやGPL、パブリックドメインなどをしばしば見かけるとおもいます。 これらがそれぞれどういう意味なのか、調べるとすっごくむずかしいのですが、ちゃんとググって調べてみるようにしましょう。

ただ、調べたとしても、（特に日本語だと）大抵どこも玉虫色に「〜〜と、解釈できるような気がする（けど責任は持ちません）」みたいな事をかいてあるとおもいます。 多くのライセンスは日本国外の法律をベースに考えられているのと、判例を重視する日本では、判例がでないとなんとも判断がしづらいのでしょう。（私も専門家でないので、なんともいえませんが…）

とはいえ、そこまで気にしていくと、オープンソースのライブラリは使う事ができません*7。こわかったらあきらめて自分で全部書きましょう（実際の所、業界によってはオープンソースのライブラリは怖い！と禁忌して、全部自分達で書く所も多くあります）。

ポイントとして、大体どのオープンソースライセンスも以下の事を問題にしています。

• 再配布の許可（自分が書いたコードとセットで、たとえばお客さんに渡して良いか）
• ソースコード開示がどのような時に必須になるか
• 元の作者と、元のライセンスを明示するか
• 改変（改造）をしてよいか、その後のライセンスはどうなるか
• 責任の所在

このあたりを注意しつつ、Wikipediaなどをググってしらべてみてください。

ほぼすべてのオープンソースライセンスは「自分が自分のためにつかい、自分のPCやサーバで動かす」のであれば、おおよそ考えられるほとんどのことは問題ありません。

問題になるのは、そのライブラリを使って作った何かを他の人に渡したり、販売、配布や公開するときにかかってきます。 （ただし、AGPLと呼ばれるライブラリだけはさらにややこしく、ウェブサービスなどで公開したときにも公開義務が発生する…のですが、詳しくはしらべてください） 商売や仕事にするなら、気合いを入れてしらべましょう。逆に個人の勉強をしているウチは深く考えなくて良いでしょう。

まったく指標がないのは困るとおもいますので、一個だけ言っておきますと、酷く雑な言い方ですが、MITライセンスのものがあれば、それを使うようにしてください。

MITライセンスはかなり寛容であり、PHPのようなスクリプト言語の場合には、露骨に著作権表記や同梱されているLICENSEファイルを削除しなければ考えることはほぼないでしょう。*8

しばらくすると…

ライブラリをつかっていると、色々不満がでてきます。そうなったら自分で創る段階です！

…が、まあこのエントリを読む人はそこまではまだ到達していないのではないでしょうか。しかし、いつかは是非挑戦してみてください。

強いていって、今ドキならばComposerに対応、つまりPackagist.orgに登録するとよいのではないでしょうかね。

あとは、ライブラリの作者に要望をおくる事があるかもしれません。Githubなどで公開されていれば、ISSUEなどで比較的簡単にバグ報告などを報告できるでしょう。運がよければなおしてもらえたり、回避策を教えてもらえる事もあります。

ただ、オープンソースのライブラリは相手に責任や義務はまったくないのが通常です。できれば自分で直し、直した内容をプルリクエストなどで送って、取り込んで貰う様に御願いしてみましょう。 まちがっても「こういう機能が俺がほしいからつくってくれ！来週までに！」みたいなのは送らないようにしましょう（というか、とりあってもらえないと思います）。

私も何回かバグ報告をしたことがありますが、ソースコードをつけて送っても反応がもらえるのは半々くらいですかね…。まあ手元で修正して、それを使うという手もあります（ちょいと悲しいですが）。 いつかのバージョンで治る事を期待しましょう。

まとめ

ライブラリをつかうと、色々と便利な機能を簡単につかう事ができます。 ライブラリは様々な種類があって、おおよそ考えつくようなことはすでにライブラリになっていたりします。 自分が複雑なことができなくとも、ライブラリを活用して魅力的なプログラムをつくりましょう！ ただし、ライセンスなどにはきちんとしたがい、正しく活用するようにしましょう！

最後に、しなければならない宣伝

さて、宣伝タイムです。帰らないで下さい。

Webアプリエンジニア養成読本[しくみ、開発、環境構築・運用…全体像を最新知識で最初から! ] (Software Design plus)

まず再度の書籍の宣伝です、本アドベントカレンダータイトルの書籍です。

このエントリが役立つ方には、まだちんぷんかんぷんかもしれません。即座に買えとはいいませんが、いつかは買って欲しいです。まあ、本屋にいって他の書籍のついでに立ち読みしてみるのも良いでしょう、買って欲しいですが。

もし、この書籍の内容が理解できれば、おそらく仕事でもなんとかやっていけるレベルにいるのではないでしょうか。そのようなベンチマークとしても役立つと考えております。つまりは買っていただきたい！ということです。

しなければならない宣伝２

来年の夏に開催されるYAPC::Asia Tokyo 2015についてです。

YAPC::Asia Tokyo 2015

YAPC::Asia Tokyoは世界最大級のエンジニアの手による草の根技術カンファレンスです。これまで9回開催され、様々な技術に関する発表そして技術者同士の出会いを生んできました。

「なんかエンジニアコミュニティってきいたことがあるけど…」「カンファレンスってどんなの？いったことない」という人でもきっと新しい発見があるイベントとなりますので是非ともチェックしてください。

YAPCはPerlのカンファレンスと思われがちですが（実際そうなのですが）、どんな言語の人でも、きっとPHPの人でも楽しめるイベントになっております。なにせ去年のベストトーク賞はPHPのトークでした*9。

来年は10年目かつ、今の運営における最後の開催となり、規模も、話題のバリエーションも間違いなくパワーアップしますので、是非来年のスケジュールにいれておいてはいかがでしょうか？

…といっても、来年の話では忘れてしまうでしょう。近日中にお知らせをとどけるメールマガジン的なものができるはずです（鋭意作成中）

本日の所は、まずは公式Twitterアカウントのフォローなどをされてはいかがでしょうか？

といった宣伝をおこなった所で、こちらからは以上です。また次回お会いしましょう！

*1:ザックリしてますが、まあそういうことですよね

*2:させようとすると、多少面倒なので

*3:上記は過去のコードからコピペ整形しており、動くかわかりません、すみません

*4:そう言う物もあったりしますが

*5:あるいは、販売している場合もあります

*6:日本人がつくっているライブラリでも、英語でかいてあることも多いです

*7:そもそも、多くの場合、配布している人も法律の専門家ではないし

*8:コードからなにも考えずに勝手に著作権表記を消すのはやめましょう！！これはライブラリでも何でもそうです

*9:というか私です