uzullaがブログスマートフォン用の表示で見るuzullaがブログuzullaがブログです。AdventCalendar2014ついにはてなブログがMarkdownとはてな記法の都度切り替えができるようになった!すげー便利だ!(ただ、なんかリンク埋め込み時とかに、無駄に改行がはいるような?バグかな)さておき、本エントリはWebアプリエンジニア養成読本アドベントカレンダーです。見る私の担当分においては、こちらの書籍でお話できなかった、初心者向けの事について書いたりしております。あと一週間ですが、ネタ切れ著しいです、だれかネタをください。ライブラリとはライブラリは、特定の処理を再利用するためにきりだされたプログラムの一部です。なにか処理を行う時に、自分で0から全部の処理をかかなくても、ライブラリをつかえば再利用する事が可能です。自分が書けないような複雑な処理をライブラリを使う事で代行するような事も可能です。「それってたとえばPHPの機能、関数じゃないの?」とPHP初心者の人ならば思うかもしれませんが、まあ、当たらずとも遠からずですね。世の中には様々なライブラリがありますが、多くの物は公式的にだされているわけではありません。誰がライブラリを公開しているのかといえば、個人、あるいは企業などが作成して、それを配布しています。「なんでそんなことをするの?」といわれれば、作ったモノが便利なので、世の中の役に立ちたい*1とか、名前を売りたいとか。企業ならば自社の製品の販促活動の一環の場合もあります。あと、ライブラリ自体を販売しているケースもあります。ウェブ系にまつわるプログラミング言語にはオープンソースかつ、ライセンスの自由度が高いライブラリが数多くあり、そういったものは無償で、「ライセンスの範囲で」自由に自分のプログラムに組み込んだりできるので、効率的にプログラムを作成する事が可能になります。私としても、自作、他作ふくめて、まったくライブラリ等をつかわないでプログラムをかくことはほぼありません。...私が良くつかうライブラリをいくつか挙げてみます。軽量ウェブアプリケーションフレームワークどれもよく使うような機能です。いうのは1から書くのは面倒ですし、自分よりも腕の良いプログラマがかいた処理がつかえれば、プログラム全体の品質だってあがります。一例として、メール送信SwiftMailerはメールを送信するライブラリですが、まあPHPにももともとメール送信のライブラリは存在します。mail()関数やmb_send_mail()関数ですmail関数を使う場合には、以下のようにすれば一発ですね。);しかし、mail関数は日本語がうまく処理できないので*2mb_send_mailを使う事が多いのではないかなと思います。uzulla@example.jp');まあ、ここまではこれらの関数でも特に問題ありません。これにファイルを添付してみましょうか...となると一気にややこしくなります。添付ファイル」とかでググると色々でてきます。メール周りを手で書いた事がなければ「えっ、なんなの、何でこんな面倒なの」と思うでしょう。メールは歴史があり、様々な仕様が入り交じっていて複雑怪奇なのです。要は、添付ファイルというのはメールの本文を複雑に処理して、ファイルを埋め込む必要があるのですが、膨大なお作法があるし、相手のメーラーによっては上手く動かない事があったりして非常に面倒なので、自分で書きたくなんかないのです。\Swift_Mailer::newInstance();$sm->send($mail);まあ、概ねこんな感じで書く事ができます。これで大体のケースで、相手にきちんとしたメールを送ることができます。*3希にある、UTF-8でのエンコードに対応できていないメーラーがあり、その場合は私はqdmailという昔からあるライブラリを使っています。本当にqdmailにはガラケーのころにお世話になりました...。ガラケー相手にちゃんと表示できて、絵文字みたいなのもつかえるメールを、mb_mail_sendとかで書くのは結構悪夢です(特にキャリアや機種での動作確認が...)。このように、様々なメーラーやMTAの動作保証をするのは大変なので、信頼のできるライブラリを利用すればそのあたりの手間を減らす事もできつつ、プログラムの品質があがってよいですね。PHPには標準ではないような機能PHPは非常に豊富な関数や機能をそなえているので、ライブラリがなくても一通りのことを行う事は可能です。高機能であるとは言えないものも多くあります。PHPに最初から無いような機能もあります。Twitterへの投稿ですね。TwitterやFacebookなどのAPI操作は、OAuthと呼ばれる認証をおこなわなければならないので、全部を自分で実装するのは面倒です。いったものは素直にライブラリを使う方が速いと思います。Servicesなどを始めとして、自社のAPIを利用しやすくするために、自分で作成して配布しているケースもあります。APIなどは仕様がかわったりすることがあり、ライブラリのバージョンをあげるだけでその仕様変更に対応ができることもあり(絶対できるわけではない)、それもまたライブラリをつかうことのメリットになります。ライブラリをどうやって探すのか?このように、便利なライブラリですが、一つ不便なのはライブラリを探すという行為です。基本的にライブラリは、プログラミング言語の組織が「公式」に配布されているものではなく*4、みなが好き勝手に公開していたりします*5。書籍やphp.netなどにすべてがあつめられたり公開されているわけではありませんので「ここをみれば全部ある!」ということではありません。いえ、ある程度あつめている有志のサイトや書籍はありますので、それらからさがしたり、最近であればGithubなどを自分で検索して探して見つける必要があります。最近だと、Composerと呼ばれるライブラリ管理ツールの中央レポジトリであるPackagist.orgなどでも検索する事が可能です。ライブラリ」とかでググったらみつかるかもしれません。いくつか方法はあるのですが、あなたが初心者であれば、まずは書籍を見てみるのもよいのではないでしょうか。大型本この商品を含むブログを見るたとえば、これらのような本があります。個人的には、こういった書籍はちょっと古いものもあるかな?と思う所もないわけではないのですが、初心者の方には古いやり方のほうがわかりやすいかもしれません。Composerをつかったライブラリインストールなども解説されていますので、昔のやり方しかしらない方でも参考になるとおもいます。どれにするか決める見つけた後も、いくつか注意が必要ですライブラリはプログラムの一部としてつかいますので、ライブラリがダメになると、当然プログラム全体がダメになります。そのライブラリに自分のプログラムの運命がかかるわけです。PHP5.3未満でしかちゃんとうごかないライブラリを今取り入れるのはありえない選択です。長くつかうなら、古くさくなく、なおかつバグなどもすくなく、色々な所で利用されて信頼できるかどうかは重要です。以下のようなことを注意できるのではないでしょうか。使い方のサンプルなどがあるか?ドキュメントは見やすいか?(重要です、ライブラリの姿勢が見えます)使っている人が多そうか?(ちょっと重要です、困ったときに調べられます、特に日本語の情報)バグがたくさん貯まっていないか?(GithubならISSUEなどを見る)バージョンがちゃんとあがっているか(放置されていないか)ライセンスは、使いやすいか?(後述します)勿論、後でそのライブラリを別のライブラリに置き換えたり、自分で書き直してしまう事も可能ですが、最初から不安になるような行為をする理由はありません。相談できる人に相談して、問題がないか聞くのもよいでしょう。はいっても他人に運命を預けるわけですから、ある程度は天に運をまかせることにはなりますし、ひるんでいたら使えるものもつかえなくなってしまいますので、深く考えずにエイヤと導入する時も必要になります。残念なことに、日本語のライブラリは少ないです、英語のものとくらべて、1/10とか1/100くらいしかないとおもいます*6。英語がどうしても苦手ならば、日本語で紹介されているライブラリを重点的にさがしましょう。ライブラリをどうやっていれるか?PHPのライブラリは色々な形態で配布されています。コード断片(をソースコードの中にコピペしてつかう)zip(などの圧縮ファイルを展開して、ファイルを設置する)pearComposer様々な方法がありますが、今はComposerをつかった方法で利用するのが一般的になりつつありますし、私としても一番おすすめです、ぜひ一度しらべてみてください。いずれにせよ、多くのライブラリ(特に、人気があってつかいやすいもの)は使い方も書いてありますので、それに従って下さい。zip配布の場合、大体ダウンロードすると、PHPのソースコードがはいっていますので、適当にファイルを設置してよみこませ、ドキュメント通りに関数やクラスなどをよびだすことになります。ZIPなどで配布されているライブラリは、ダウンロードした後保存しておいたほうが無難です、突然配布されなくなる(消される)ことも希にあります。ライブラリでわからないことがあったらどうすれば?勿論ドキュメントを色々よんだり、自分のプログラムから一端はなれて、最小限のテストコードでライブラリをうごかしてみるのは重要です(自分のコードや使い方がおかしかったらどうしようもないので)。それでもうまくうごかないことは多々有ります。どのライブラリも完全無欠ではないのです。ライブラリの作者に問い合わせるのは考え物です。後述もしますが、多くのオープンソースのライブラリのライセンスにおいて「なんの責任ももたない」とあります。あなたに説明する責任もありません。返事がもらえないのが当然、くらいでかんがえないとショックを受けるかもしれません。(「サポートフォーラム」とかかいてあってもレスがつかないことも多い)まずはやりたい事や、エラーメッセージでググってみたりしましょう。詳しくて、質問できる人に質問してみるのもよいでしょう(先日かいた通り、コミュニティに参加するとこのような場合に助かります)。英語ができればStackOverFlowなどの有名なQ&Aサイトで検索したり、質問するのがよいでしょう(先日日本語版のStackOverFlowもオープンしましたが、まだあまり活発ではないですね)。Overflowしかしながら、一番確実で、逆にてっとりばやいのはライブラリのソースコードを読むことです。ライブラリはなんだかんだで結構バグってることが多いのです(が、本エントリを読む方には敷居が高いかもしれませんね...)。バグで、なおせたらライブラリ作者にそれを連絡するのは良い事ですね。ライセンスについてライブラリやソースコードには著作権があります。ネット上でググってみつけたソースコードは「つかっていい」と書いて無ければコピペしてつかったりはしてはいけません。「自由につかっていいですよ!」と横に書いてあったり、解説系のサイトや書籍はある程度参考にしてよい、とか書いてあるでしょうから、それらは大丈夫でしょう(とはいえ、それもわりとふわっとしていて、個人的にはイヤですが)。ライセンスが定義されているソースコードは、ライセンスを守る限り比較的安心して使う事ができます。逆にいえば、ちゃんとしたライセンスが書いていないソースコードは使えないと思った方がよいでしょう。(特に仕事なら当然です。「このコードはネットのどこかでひろいました!」とかヤバイ、全部書きなおしになる)ソースコードが公開されている=いくらでもコピーしてつかってよい、という意味ではないのです。大体のライブラリのライセンスは、そのソースコードの先頭か、あるいはLICENSE、などというファイル名で同梱されているとおもいますので、それを読みましょう。大体の場合、英語で書かれていてウッとなりますが、大体の場合これは定型的なものになっています。具体的にいえば、MITやGPL、パブリックドメインなどをしばしば見かけるとおもいます。これらがそれぞれどういう意味なのか、調べるとすっごくむずかしいのですが、ちゃんとググって調べてみるようにしましょう。調べたとしても、(特に日本語だと)大抵どこも玉虫色に「〜〜と、解釈できるような気がする(けど責任は持ちません)」みたいな事をかいてあるとおもいます。多くのライセンスは日本国外の法律をベースに考えられているのと、判例を重視する日本では、判例がでないとなんとも判断がしづらいのでしょう。(私も専門家でないので、なんともいえませんが...)とはいえ、そこまで気にしていくと、オープンソースのライブラリは使う事ができません*7。こわかったらあきらめて自分で全部書きましょう(実際の所、業界によってはオープンソースのライブラリは怖い!と禁忌して、全部自分達で書く所も多くあります)。ポイントとして、大体どのオープンソースライセンスも以下の事を問題にしています。再配布の許可(自分が書いたコードとセットで、たとえばお客さんに渡して良いか)ソースコード開示がどのような時に必須になるか元の作者と、元のライセンスを明示するか改変(改造)をしてよいか、その後のライセンスはどうなるか責任の所在このあたりを注意しつつ、Wikipediaなどをググってしらべてみてください。すべてのオープンソースライセンスは「自分が自分のためにつかい、自分のPCやサーバで動かす」のであれば、おおよそ考えられるほとんどのことは問題ありません。問題になるのは、そのライブラリを使って作った何かを他の人に渡したり、販売、配布や公開するときにかかってきます。商売や仕事にするなら、気合いを入れてしらべましょう。逆に個人の勉強をしているウチは深く考えなくて良いでしょう。指標がないのは困るとおもいますので、一個だけ言っておきますと、酷く雑な言い方ですが、MITライセンスのものがあれば、それを使うようにしてください。MITライセンスはかなり寛容であり、PHPのようなスクリプト言語の場合には、露骨に著作権表記や同梱されているLICENSEファイルを削除しなければ考えることはほぼないでしょう。*8しばらくすると...ライブラリをつかっていると、色々不満がでてきます。なったら自分で創る段階です!...が、まあこのエントリを読む人はそこまではまだ到達していないのではないでしょうか。いつかは是非挑戦してみてください。いって、今ドキならばComposerに対応、つまりPackagist.orgに登録するとよいのではないでしょうかね。あとは、ライブラリの作者に要望をおくる事があるかもしれません。Githubなどで公開されていれば、ISSUEなどで比較的簡単にバグ報告などを報告できるでしょう。運がよければなおしてもらえたり、回避策を教えてもらえる事もあります。オープンソースのライブラリは相手に責任や義務はまったくないのが通常です。できれば自分で直し、直した内容をプルリクエストなどで送って、取り込んで貰う様に御願いしてみましょう。まちがっても「こういう機能が俺がほしいからつくってくれ!来週までに!」みたいなのは送らないようにしましょう(というか、とりあってもらえないと思います)。私も何回かバグ報告をしたことがありますが、ソースコードをつけて送っても反応がもらえるのは半々くらいですかね...。手元で修正して、それを使うという手もあります(ちょいと悲しいですが)。いつかのバージョンで治る事を期待しましょう。まとめライブラリをつかうと、色々と便利な機能を簡単につかう事ができます。ライブラリは様々な種類があって、おおよそ考えつくようなことはすでにライブラリになっていたりします。ライセンスなどにはきちんとしたがい、正しく活用するようにしましょう!最後に、しなければならない宣伝さて、宣伝タイムです。見るまず再度の書籍の宣伝です、本アドベントカレンダータイトルの書籍です。このエントリが役立つ方には、まだちんぷんかんぷんかもしれません。即座に買えとはいいませんが、いつかは買って欲しいです。本屋にいって他の書籍のついでに立ち読みしてみるのも良いでしょう、買って欲しいですが。この書籍の内容が理解できれば、おそらく仕事でもなんとかやっていけるレベルにいるのではないでしょうか。そのようなベンチマークとしても役立つと考えております。買っていただきたい!ということです。2015についてです。Tokyoは世界最大級のエンジニアの手による草の根技術カンファレンスです。これまで9回開催され、様々な技術に関する発表そして技術者同士の出会いを生んできました。「なんかエンジニアコミュニティってきいたことがあるけど...」「カンファレンスってどんなの?いったことない」という人でもきっと新しい発見があるイベントとなりますので是非ともチェックしてください。YAPCはPerlのカンファレンスと思われがちですが(実際そうなのですが)、どんな言語の人でも、きっとPHPの人でも楽しめるイベントになっております。去年のベストトーク賞はPHPのトークでした*9。来年は10年目かつ、今の運営における最後の開催となり、規模も、話題のバリエーションも間違いなくパワーアップしますので、是非来年のスケジュールにいれておいてはいかがでしょうか?...といっても、来年の話では忘れてしまうでしょう。Twitterといった宣伝をおこなった所で、こちらからは以上です。AdventCalendar2014です。Advent...昨日オールナイトの忘年会で完全に眠いuzullaです。サービスを追記しました。»プロフィールid:uzullauzullaがブログです。参加してきました!月別アーカイブ参加グループWindows開発者はてなブログをはじめよう!uzullaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。