そのオブジェクト指向入門は間違っている（大げさ） - Webアプリエンジニア養成読本 AdventCalendar2014 25日目最終日！

はい、Webアプリエンジニア養成読本 AdventCalendar2014です。突然トリをやる事になってしまったので、どうしたもんかとおもいます…。
「最終日だぞ…ちゃんとかかないといけない…しかしネタはない…そうだリンク集を作ろう！」とか思ったんですが、そもそもアドベントカレンダーってリンク集だよねって気付いて愕然としているクリスマスの夜です。現在朝の4時、これを書き終えて寝たい。

さて…何を話そう

ここまでWebアプリエンジニア養成読本アドベントカレンダーということで続けてきました。そして今日は25日、ついに最終日です！

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

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

著者陣４名と読者の方１名が特に取り決めなく、めいめい好き勝手に書いてきました。皆さん、いかがでしたでしょうか？もしこのエントリにいきなり来た方は、後で他のエントリも是非ご覧ください！

さて、私の担当箇所は、繰り返しになりますが「Webアプリエンジニア養成読本では、初心者は入門できない」と、複数の方にいわれつづけたので（まあ、実際言語の入門ではないので、そういう本なのですが）、あの本に書けなかった多少初心者向けの事をかいてきました。いくらかでも初心者の皆さんのお役にたてていれば幸いです。ブクマは多少ついていて希望は持てます。

とはいえ、ミッシングリンクはまだまだ埋まっていないのが現実です。
ここで私が書いたエントリを振り返ってみましょう。

・PC初心者でもPHP言語を兎に角手軽に試す 
・超初心者プログラミング入門は「何」をやるべきか、主にPHPの場合。 
・PHPだってアプリたい！
・コミュニティに参加してつまづき最小限、学び最大限に
・ライブラリをつかって効率的にプログラムを書くぞ！
・PHP開発には単なるエディタだけでなく、もっと良い環境を

とりあえず、PHPをはじめて、コピペコードをかいて、分からない事があれば、誰かに聞く、ライブラリもつかってみよう、そしてエディタもPHPStormとかIDEをつかいだすようになった…、そうなったら次はなにか？

そうですね、わかってますよ…オブジェクト指向プログラミングです！！

オブジェクト指向言語入門…？

もう勢いでここまで書いてしまいました、後戻りはできない。

本当は書きたくなかったんですよ、こんなの終わるわけねえもん。

ただ、ちょっとだけ、本当にチョットだけ、私の偏見（？）あるオブジェクト指向入門についてお話ししたいとおもいます。

オブジェクト指向入門のごくごく一部しかお話しませんから、これだけをもってオブジェクト指向プログラミングだと思わないでください。*1

でも、…もし気付きがあった！とおもったら、是非ともブクマでもツイッターでも何でもいいので教えてください。今後人に聞かれたら、自信をもってこの話ができます。

あと、いまさらですが、識者の方々へ。「こんなふざけた事かきやがって！」と思うでしょう。ごめんニャンごめんニャン…（(c)すがまさお）。

しかし、私は当時結構苦労しました。こういう気付きでの入り方もある、ということでご容赦いただければ幸いです…。あるいは、本当にすばらしいオブジェクト指向プログラミングへの道筋となる資料をお教えいただければ、全部このエントリを消して、それへのリンクにしてしまいたいとおもいます…是非お願い致します。

本題、オブジェクト指向プログラミング「入門」は、何がむずかしいのか

これは本やサイトそれぞれなんですけど、大抵の場合、一番最初に「動物クラスがあって、トリクラスがあって、鳩クラスに継承されます」みたいな典型的な説明があるわけですよ、一度でもオブジェクト指向プログラミングを勉強したことがあれば、かならずそういう比喩をみていると思います。

今の私なら、言ってる意味は分かります。そう、言ってることはわかるんですけど、これ分かってる人からの目線なんですよね。いままで関数と変数で勉強してきたのに、いきなりトリとかカプセルとかでてきても困るじゃないですか！そっ閉じ回避不可能ですよ！

はい、これで困らない方は本当に有り難うございました、このつつましいエントリは貴方のお役にたてません、すみません。

「トリ未満」のオブジェクト指向プログラミング

まず、あなたが変数と関数でPHPのプログラミングが多少できると仮定します。すみませんが、変数と関数の解説はしません。
もしそれらも分からなければ、まずは変数と関数のプログラミングをおぼえてからで遅くありません、一回もどって勉強して、いつかまたこのエントリにもどってきてください。

さて、オブジェクト指向プログラミング（以後OOP）は、「クラス」っていうのと「インスタンス」っていうのだけが特に新しい概念です。

「…オブジェクトってどこいったの？」そうですね、それはわすれてください、マジで。*2

これの他にも絶対にでてくるのが「プロパティ変数」と、「メソッド」ってのがあるんですが、これは「変数」と「関数」だと思ってください、マジで。

クラスとは？

クラスってのは基本的に「一つのプログラム」です。

「なにいってんだこいつ」とおもわないでください、そういう風に捉えると、理解が早い、という話です。

クラスというのは、基本的に「プロパティ変数（以後プロパティ）」と「メソッド」でできています。前述の通り、これは「変数」と「関数」です。

ここでOOPでないコードを以下に書いてみます。変数と関数でできてますよね？わかりますよね？

<?php
$text = "hello world!";
function say($text){
    echo $text;
}
say($text);

このように、普通のPHPプログラムは、変数と関数をつかってつくられています。…わかりますよね？

さて、いきなりですが、OOPのクラスは、たとえばHelloWorldのプログラムを、プログラムの中に詰め込んだものです。

…どういうことかわからないですかね、ちょっとコードかいてみます。HelloWorldをするOOPのコードです。

<?php
class HelloWorld{
    public $text = "hello world";
    public function echoHello(){
        echo $this->text;
    }
}

これがクラスでかかれたHelloworldプログラムです！！！（ババーン

では、これを実行すると…なにもおこりません。なぜなら、これはクラスを定義した、つまりプログラムを作成しただけで実行していないからです。実行はこうやります。

<?php
class HelloWorld{
    public $text = "hello world";
    public function echoHello(){
        echo $this->text;
    }
}
// ここから下が実行している所
$helloworld = new HelloWorld();
$helloworld->echoHello();

実行すると、「hello world」と表示されます！

さて、これはHelloWorldという「クラス」を「インスタンス化」して、echoHello「メソッド」を呼び出しています。インスタンス化、というのはまあプログラムを起動だとおもってもらってさしつかえないです。

$helloworld = new HelloWorld();

このように書くと、$helloworld変数の中に、インスタンス化されたHelloworldクラス（プログラム）、つまりHelloWorldのインスタンスが起動されて、保存されます。
で、インスタンスに「->」という記号をつけると、その中にあるメソッド（関数）を呼び出せます。

$helloworld->echoHello();

このようにかくと、$helloworld変数の中にあるHelloWorldクラス（プログラム）の、echoHello()というメソッド（関数）を呼び出す事ができるのです。
どうです？なんとなくわかりますか？

ここで、あらためてよくわからない気がするHelloWorldクラスをみてみましょう。HelloWorld{〜}でかこまれているのと、まだ「public」ってキーワードはまあよくわからないかもしれませんが、変数ぽいのがあります、functionってのはあきらかに関数宣言っぽい、そうなんですよ、実はこれは変数と関数です。

「…あれ？なんだ？OOPというけど、たんなる変数と関数でできてるじゃないか？」とおもったら、まあその通りなのです。

ちょっとクラスに関数（メソッド）を増やしてみましょう、こんな風になるかもしれません

<?php
class HelloWorld{
    public $text = "helloworld";

    public function echoHello(){
        echo $this->text;
    }

    public function echoHelloWithName($name){
        echo $name."さんこんにちは！";
    }
}

$helloworld = new HelloWorld();
$helloworld->echoHelloWithName("太郎");

こうやると…想像つきますよね？「太郎さんこんにちは！」と表示されます。

書き方はちがいますけど、これってまったく普通の関数を追加作成しているのとかわらないとおもいませんか？実際その通りです！

変数の方もちょっと書き換えてみましょうか、以下のようにしたら？

<?php
class HelloWorld{
    public $text = "helloworld";

    public function setText($text){
        $this->text = $text;
    }

    public function echoHelloWithName($name){
        echo $name."さん".$this->text;
    }
}

$helloworld = new HelloWorld();
$helloworld->setText("こんにちは");
$helloworld->echoHelloWithName("太郎");

setTextというメソッドに「こんにちは」という文字列をわたして、「$helloworldインスタンスの中にある」$textプロパティ（変数ですね！）に代入して、それをechoしているわけですね。

どうです？おわかりいただけるのではないでしょうか？

これで、クラスってのが、PHPのコードの中にかける、「プログラム」だというのがわかっていただけたのではないでしょうか？どうですかね？わからない？

「プログラムの中にプログラムってなんだよ…」って思うかもしれません。プログラムってことは、いくつも同時に起動ができるのです。

<?php
class HelloWorld{
    public $text = "helloworld";
    public function setText($text){
        $this->text = $text;
    }
    public function echoHelloWithName($name){
        echo $name."さん".$this->text;
    }
}

$helloworld1 = new HelloWorld();
$helloworld2 = new HelloWorld();
$helloworld1->setText("こんにちは");
$helloworld1->echoHelloWithName("太郎");
$helloworld2->echoHelloWithName("太郎");

このようにかくと、$helloworld1と$helloworld2で、二つHelloWorldクラスがインスタンス化（起動）されます。

そんで、1の方だけ、「こんにちは」とsetTextして、2はなにもせずにechoHelloWithName()を読んでいます。

これがどうなるか…想像つきますか？

太郎さんこんにちは
太郎さんhelloworld

こうなるわけです！このように、インスタンス（実行されているプログラムみたいなもの）は、それぞれが別の（プログラム）実行（みたいなもの）とされるので、１つのPHPコードの中で、同時に同じプログラム（クラス）を衝突することなく動かす事ができるわけです！*3

どうですか？これで

・クラスがちっちゃいプログラム
・インスタンスはクラスをプログラムの中でクラスをプログラムみたいに起動したもの
・複数インスタンスをつくれば、それぞれ別の実行で、それぞれのインスタンスは衝突せず

ということがわかるのではないでしょうかね？

ここまでくると、最初の「クラスはちっちゃいプログラム、普通のPHPコード同様に、中には変数と関数がはいって出来てる」というのもなんとなくまあ言ってる意味はわかっていただけるのではないでしょうか。

これが私がお伝えしたかった事です！以上！！お疲れ様でした！！

…なんだこれは

以上です、これが原始的なOOPです。

「えっ…、こんなのがOOPなの？なにが嬉しいの？」と思うかもしれません。実際こんなの関数と変数でかけることです。たとえば

<?php
$text = "こんにちは";
function echoHelloWithName($name, $text){
    echo $name."さん".$text;
}

echoHelloWithName("太郎", $text);

こうやって書けばよい、その認識は猛烈に正しいです。

OOPは、猛烈に新しい「結果」ができる魔法ではない

そうなんですよ、OOPをつかわなくても、Hello worldは作れます！！びっくりしましたか！？

「じゃあなんで、OOP！OOP！って世の中は叫んでるの…？」

そこで！やっと！ハトとか！トリとか！継承とか！カプセル化とか！ああいうなんかオブジェクト指向プログラミングでやたらと解説される話がでてくるのですよ！

ここらへんはキリがないので、ここでは解説しません！それに「どういう利点があるか」というのはあらゆる本で語り尽くされていますので、本を読んでみてください。

実際のところ、OOPの様々な機能（というか可能になる事）は、スゴイ便利なんですよ！（まあ、ここまでの説明ではOOPが全く便利に見えないと思いますが…）

OOPをつかうだけの人もいる

余談みたいですが、クラスを一切書いた事がなくても、知らず知らずの内にOOPを使う人もいます。

たとえば、（ウェブアプリケーション）フレームワークとか、ああいうのをつかうと強制的にOOPをつかわされたりします。いまどきはOOPでないフレームワークはレアですからね。あれは「フレームワーク」のインスタンス（プログラム）を起動して、チョイチョイと色々操作して、まあうまいことウェブサイトが効率的につくれるようになっている。

クラスになっているから簡単につかえる。クラスになっているから膨大なフレームワークがもっている関数や変数と、自分がつくった関数や変数がぶつかることを心配しなくてもプログラムが書けたりするのです。

フレームワークでなくても、まあ、メール送信ライブラリとかツイッターAPIを叩くライブラリとか、そういうのもOOPでつくられていたりします。まあ、関数しかないライブラリとかもまだまだありますけど、大分減ってきてるかなとおもいますね。

OOPがわからずに使う時は「->ってなんだ？」と思いつつも、コピペすればなんとなく変数と関数の世界のPHPでもつかえたりします。それはOOPでかかれていることで、そのライブラリの中身の膨大なコードがうまく閉じ込められているからで、ぱっとコピペで良い感じに便利につかえたりするのです。便利ですね。

ここまで読んで「やっぱりOOPはいらないのではないか？」という話

実際、「関数と変数のPHPでできるじゃん？OOPとかいらないよ！」というのは、ある意味正しいんですよ、PHPでできることなんてタカがしれてますからね。
HTMLがちゃんと返せればいいだけですので、それには関数と変数で十分な事も多いんですよ。速いし*4。

ただ、前述の通り、ライブラリをつかうときにはOOPをつかってたりする事もあるわけです。
で、そういう便利なライブラリってのは、大抵（入門者の自分よりは）スゴイ人が書いてるものじゃないですか？そうですよね？そう言う人がこぞってOOPで書いてる、そういう事実はありますよね？
つまりスゴイ人がつかっているのだから、スゴイんじゃないか？と素直に思うのも大事な事です。

私の実感としても、OOPってのは慣れてくるとすっごい便利なのは間違いないんですよ。難しく書くためにあるわけではなくて、実際に便利なんです。ただ、「○○が便利！」ってのは実際つかってみないと分かりづらい所です…。

一応、一つだけ具体的にどのように便利かここで書いておきます。
既に何回か述べていますが、「クラスはプログラム」という文脈でいえば、関数とか、変数をクラスの中だけに閉じ込めておけるわけです。普通、プログラムの外からは変数とかみえませんからね（そんなのできたら、セキュリティ的に最悪だ！*5）。

そうなると、いろんなところにそのクラスをもっていっても、既存のコードの関数や変数と衝突することがないので、色々な所でつかいまわすのにめっちゃ手軽！安全！便利！という所ですね。
（入門書とかでよくあるMyClassなんてクラス名は生涯一度位しかつかうべきではなく、Uzulla\Util\HelloWorldとかにすべきです。毎回絶対に世界で衝突しないユニークなクラス名を付ける必要があるのですが、やってみると割とどうにかなります）

これは、自分でライブラリを作り始めると、本当に意味があるんですよね。さらに、先日紹介したIDEとかつかいだした日には「うわぁ！スッゴイ！」ってなるんですよ、補完とかで、本当に。

まとめ

とにかくですね、OOPってのはなんてこたーないんですよ！

しかしながら、最初に「OOPがいかにすばらしく、何ができて世界が救われるか」という紹介が先行しすぎていて、自身がもっている知識とのつながりが完全にたたれてしまう事が多いので辛い（と思う！）！
…ということでこのエントリを書きました。

なんかもう雑な文章で、推敲したら10行くらいにできそうですが、言いたい事は書きました。クリスマスなので勘弁な！

さて、PHP入門はOOPまでおぼえれば、入門完了！と言えるとおもいます。

あとは好きなライブラリを探したり、PHP以外の言語でもよまれるようなデザインパターンとか（まあこれは賛否ありますが）をおぼえて、「PHP言語」の入門をこえた、プログラミングの勉強を進めていと言う事になります。もうこうなったら入門者とはいってられないですよね！

で、ですよ。ここまでくれば？…そうですね！このアドベントカレンダーのタイトルでもある、Webエンジニア養成読本を読む事もできますね！！ぱちぱちぱち！！やったぜ！是非ご購入ください！！

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

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

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

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

このエントリが役立った方には、その翌月か翌々月くらいには多分おやくだつのではないかな！と思います。

即座に買えとはいいませんが、いつかは買って欲しいです。まあ、本屋にいって他の書籍のついでに立ち読みしてみるのも良いでしょう、買って欲しいですが。

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

本当の最後に、しなければならない宣伝２

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

YAPC::Asia Tokyo 2015

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

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

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

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

…といっても、来年の話では忘れてしまうでしょう。冒頭にも記載しましたが、メール通知サービスが開始されました！是非ご登録下さい！

YAPC::Asia Tokyo 2015

やった！！ゴール！ゴールだ！！

最終日、多少のごたごたはございましたが、 無事、アドベントカレンダーゴールです！！

これでネタを必死に考えなくても済むようになります！年末はゆっくり眠りたいとおもいます！！

みなさんメリークリスマス！！そして良いお年を！！！エントリ書いた皆さんもお疲れ様でした！！皆さんのハッピーPHP（等）ライフを祈っております！

こちらからは！以上です！！！

*1:たとえば、「スタティックおじさんだ！」って笑われます

*2:オブジェクトの概念は、インスタンスとイコールで語られる事が多いと思いますが、結局クラスとも一部イコールで語られるので、初心者は戸惑う様です。

*3:ここでは説明しませんけど、スタティック変数をつかえばわざと衝突させる事もできますが

*4:変数と関数だけのPHPより、OOPをつかうほうがほんのわずかながら遅い、とはいえOOPしないとすぐにごちゃごちゃしたコードになるので、そっちのほうがよっぽどつらい（あなたはどうあれ、そういうことに世の中的にはなっています）

*5:register_globals？しらない子ですね…？

*6:というか私です

PHP開発には単なるエディタだけでなく、もっと良い環境を - Webアプリエンジニア養成読本 AdventCalendar2014 22日目

いきなり宣伝ですが、エンジニアのお祭りYAPC::Asia Tokyo 2015の情報をもれなくチェックするためのメール通知サービスが開始されました！

YAPC::Asia Tokyo 2015

毎年「チケット販売いつのまにおわったの…」等といった悲しい声をいただきます。わすれないように是非上記リンクより、メールアドレスを登録しましょう！

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

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

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

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

上のアドベントカレンダーページから是非他の記事もご覧下さい。

エディタの話

多くの書籍などで様々なエディタが紹介されますが、初心者向けの書籍では、ほとんど機能のない素のエディタを使う事が多いと思います。
しかし、実際問題として、書籍でcoteditorなどをおすすめした当の本人である私もcoteditorでPHPを書く事はほとんどありません。

現在私は主にPHPStormでPHPをかいています。

開発環境の種類

基本的にPHPはいまどきのエディタであれば何でも開発ができます。CotEditor等で開発することは全く問題ありません。CotEditorはすごく良いエディタで私も愛用しています。

しかし、CotEditorはPHPの開発支援はほとんどなく、シンタックスハイライト（コードを色づけして、みやすくする）くらいしかありません。

高度な開発環境、IDEをつかうことで、もっと様々な開発支援機能が提供されます。

PHPのIDEはさまざまなものがありますが、PHPStorm、Netbeans、Eclipse＋PDT等が一般的だとおもいます*1。ここではPHPStormを念頭にお話しますが、他でも同様の機能は提供されているはずです。

具体的な開発支援機能

IDEには色々な機能がありますが、少し紹介します。

シンタックスエラーチェック

一番わかりやすくて便利なのは、シンタックスエラーをチェックする機能ではないでしょうか。要は、PHPの文法がまちがっていたりすると、赤いバッテンや下線などがでて、実際に動かす前にエラーを教えてくれます。

PHPStormくらい高度な解析が可能なIDEだと、「文法的にはあっているけど、あやしい」という所も積極的におしえてくれます。従っていくだけで、コード品質がどんどんあがっていくわけです。自分では合ってるとおもっているけど、PHPStormが文句を言うコードは実際にうごかなかったりするので、非常に便利です。

PHPのバージョンを指定すれば、PHPのバージョンに応じた解析をしてくれます（たとえば、PHP5.5で非推奨な関数で文句をいったり、5.3以下でサポートしていない文法をエラーにしたり）。

コード整形（リフォーマット）

コードのインデントや、=や括弧の前後をキッチリそろえ、コーディングスタイルが統一されていることがのぞましいですが、気を付けて書いてもキッチリ揃えるのは困難です。そんな時に一発で綺麗にしてくれます。手間もへりますし、品質もあがります。

なにも考えずにガンガンかいた後にGitなどにコミットし、後で「あー、なんかこのコードきたないなー」とおもってなおすと、無駄に整形しただけのコミットログとか残るのも微妙なものです（特に、後でBlameする時とか、Diffをとったりするとかしづらくなるので）。

あとは、すごく酷いコードをなげわたされたとき（みたことありますか？）、コード整形をかけると一発でそれなりに読みやすくなるのが最高だと思います。同様にHTMLのコードも整形できることが多いので、こちらも結構重要です。

コードジャンプ

変数や、関数の宣言部分（つまりは、本体）にジャンプする機能です。コードをかいていると「この関数ってどんな処理だっけ？」とおもったりすることがありますが、そこにキー一発でジャンプします。勿論別のファイルであっても問題ありません。

他人のコードや、大きなフレームワークを使っていると自分が覚えていない関数を使う事が頻繁に発生しますので、これをドンドンつかうことで快適にコードを読みつつコーディングが可能になります。

単純に、コードを読むだけの作業の時にもつかうと、非常にはかどります。

補完、サジェスト

関数名を途中までいれると自動的に関数名を補完してくれます。あるいは、関数の引数が何個あって、どういうものなのかも表示してくれます。

関数だけだと、コードジャンプ（宣言ジャンプ）だけでも助かりますが、オブジェクト指向プログラミングをはじめると、コード補完のありがたみがどんどん増します。
（OOPのオブジェクトにどんなメソッドやプロパティがあるのか、うろおぼえでもドンドン補完かけて書いていけるので）これはJavaなどでは定番（必須？）の機能なのですが、LLにおいてはPHP以外では少ないようにおもいます 。

vimやEmacsなどでも補完をする機能があったりするのですが、PHPStormなどのIDEはちゃんとコンテキストをよんでくれるので、補完の精度が非常にたかく、ウソがでてくることが希で信頼できます。

リファクタリング

変数名や、クラス名が後になってきにくわないことは良くあります。そんなとき、一発で、問題無く置換してくれる機能がリファクタリング機能です。
単純な置換とはまったくちがい、ちゃんと文脈をみてコードを壊さないように置換してくれるので非常に便利です。

リファクタリングを活用すれば、微妙な変数も億劫になる事無く修正できます。

デバッガ

PHPで一番つかわれているxdebugと呼ばれるデバッガ（の機能）は色々なクライアントをつかって利用できるのですが、IDEのクライアント機能はエディタと連駅してステップ実行やブレークポイントをうつことができます。

デバッガといっても初心者の方にはなんのことやら？とおもうかもしれませんが、いわゆるプリントデバッグ（echoデバッグ）をほとんどやらなくてすむようになるので、非常に便利な機能です。（とはいえ、私はぱっとみるだけなら、プリントでバッグをつかったりもしますが）

Git連携

簡単にGitコミットや、過去のコミットとのdiffを見る事ができます。現在のブランチもPHPStormの場合、左下に常時表示されます。特に、Diffは便利で、コンフリクトの解消もサイドバイサイドでみながらマウスでポチポチできるのは大変楽です。

コミット前にコードに怪しい（前述のシンタックスエラーチェック）所がないかおしえてくれますし、コードフォーマットを自動でかけるオプションもあったりします。

ほかにも…

IDEによって機能はまちまちですが、便利な機能はたくさんあります。PHPStormでいえば、Shift2回おした後にでてくる入力欄に、ファイル名でも関数名でもクラス名でも入力したらそのファイルのそこが開ける機能があり、いちいち深いディレクトリにいかなくても一発でファイルを開くことができて、とても便利です。

他にも、私はあまりつかっていませんが、VagrantやComposerなどの外部ツールの連携もあったりします。シェルをひらくことなく利用ができます。

IDEが向かないケース

とにかく私はIDE最高！と考えていますが、デメリットはないのでしょうか？

有償（PHPStormの場合）

PHPStormは一番いいIDEだとはおもいますが、有償です。私は仕事でガンガンつかうので当然払いますが、まだお金ははらいたくない人も多いでしょう。あるいは、企業で何人も導入するのは負担がきびしい、という場合もあるはずです。

そのときは、Netbeansがまずはお勧めです、オープンソースで無償で利用できます。

英語が無理

PHPStormは基本的に英語でつかいます。日本語化が検討されていますが、まあ割とだれも必要性を感じていないので、英語のままです。私も、ヘルプの長い文章以外で英語でこまったことはありません。

ただ、どうしても日本語が使いたい場合には、こちらの場合もNetbeansの日本語版をつかってみてください。

複雑な（ごった煮の）サイトの修正

PHPでありがちなのですが、１つのサイトに複雑にさまざまなファイルが入り交じっていて、なおかつ環境がftpでアップロードする本番サーバーだけの場合、プロジェクト単位であつかうIDEは使いにくい事があります。そういったスタイルは旧来的なものなので、改善するか、控えるというのが一番良いと私は思いますが、まぁ、良くあるケースです。

勿論FTPでリモートサーバーをみたり、そこにアップロードする機能とかあったりもするのですが、本番サーバーをガンガン書き換えるのであれば、codaなどのエディタのほうが気楽だ、という場合もあるでしょう。
（Codaは、FTPクライアントとエディタが融合したソフトで、私もCoda1のころは愛用していました）

また、サーバーにはいって修正する、みたいなときも当然ながらサーバーにIDEをインストールするのは現実的ではないので*2むずかしいでしょう。（ただし、sshでリモートサーバーをマウントして作業することはできます）

PCの性能が低い

IDEはさまざまな支援機能のために、かなり重いです。超時間つかうと動作が緩慢になったりすることがあります。はっきりいっていいPCに買い換えるのが一番だとおもいます。

ただ、PHPStormなどはバッテリーセーブモードなど、一部の機能を動的にオフにして負荷をさげる機能があったりします。ただ、それをつかったら意味があんまりないので…微妙ですね。

他の言語も頻繁に修正する

たとえば、PHPと一緒にHTML,JSを修正するのであれば、IDEで十分でしょう。どのIDEもHTMLやJSの開発支援もセットになっており、PHPStormは特にJSもPHP同様に強い開発支援機能を搭載しています。まちがいなく普通のエディタよりも開発効率はあがるでしょう。

ただ、Perlなどまったく別の言語の場合は別です、エディタは体に馴染むものなので、つかいわけるのがむずかしい事はあります。

…とはいえ、Perl以外の、Rubyなど多くの言語についてはPHPStorm開発元がほぼ同じ体験を提供するRubyMineというIDEをだしていますし、NetbeansはCやJavaの開発をサポートします、Eclipseはいわずもがな、Javaなどを書く事ができます。（むしろ、PHPStorm以外は無料でどれも編集できるので、プロジェクトは別としても、同一のIDEで作業できるかなとおもいます）
*3

PHPをもっと好きになるために

こういったツールは「便利だけどつかうべきではない」なんて事は一切ありません。役立つなら、ドンドンつかうべきです。開発が楽になれば、もっともっとコードを気軽に書く事ができて、好きになることまちがいありません。

人気あるSublimeやATOMなどで開発されている人も多いとおもいますが、PHPは他のLLにくらべ、IDEがとても良い性能をもっていますので、是非一度つかってみてはいかがでしょうか？

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

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

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

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

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

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

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

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

YAPC::Asia Tokyo 2015

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

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

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

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

…といっても、来年の話では忘れてしまうでしょう。冒頭にも記載しましたが、メール通知サービスが開始されました！是非ご登録下さい！

YAPC::Asia Tokyo 2015

といった宣伝をおこなった所で、こちらからは以上です。

いやはや、もうすこしで終わりですがネタがありません！あとはもうPHP愛でも語るしかない気がしはじめました。なにか気になる事があれば是非聞いて下さい。

ではまた次回お会いしましょう！

*1:ほかにも結構あります、つかったことはないですが、MicrosoftのVisualStudioもPHPサポートのプラグインなどがあるようです

*2:Linuxでうごくにせよ、Xで接続するのか！？ってなるので

*3:Perlもあるにはあるのですが…うーん…

*4:というか私です

ライブラリをつかって効率的にプログラムを書くぞ！ - 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(
    'uzulla@example.com',
    'title',
    'hello hello!!',
    'From: uzulla@example.jp'
    );

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

<?php
mb_send_mail(
    'uzulla@example.com',
    '題名',
    'こんにちは！こんにちは！',
    'From: uzulla@example.jp'
);

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

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

mb_send_mail 添付ファイル - Google 検索

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

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

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

<?php
// ライブラリ読み込みは省略
 
$mail = \Swift_Message::newInstance();
$mail->setTo('uzulla@example.com');
$mail->setSubject('テストメール');
$mail->setFrom(['uzulla@example.jp' => 'うずら']);
$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:というか私です