2012年10月1日月曜日

iPhoneアプリ開発入門[Objective-C][初心者]

イトウです。

iPhoneアプリ開発に有益なサイトをまとめてみました。
これから開発を始める人は一度読んで見て下さい〜



2012年9月14日金曜日

[Git][バージョン管理][Dropbox]GitとDropbox使って、チーム開発を爆速にしよう

イトウです。

本日のテーマは「Git + Dropboxで、バージョン管理しようぜ!」です。

■バージョン管理する方法

■バージョン管理って?
■個人開発?チーム開発?
■共用リポジトリをどこに置くか?
■GitとSubversion

=======================


■バージョン管理する方法
GitやSubversionなどのバージョン管理ソフトに慣れ親しんでいる人は、
特に説明は要らないでしょう。下のスライド読みながらサクサクいきましょう。




================

ここから下は「Git?Subversion?え?え?え????」な人のために書きます。


■バージョン管理って?
・書いたソースコードを効率的に管理するための仕組み、みたいなものです。
・ソースコードを簡単に昔のバージョンに戻すことができます。
・なので、変更してる内に分けわからんくなった…、なんて時も大丈夫。

究極の手動バージョン管理は、
・作業ディレクトリをコピー
・「backup_20120914」とか別名でディレクトリを保存
・ソースに変更がある度、この手順でディレクトリを作っていく
みたいな感じ。

手動でコピーするのめんどくさい。 → コマンド打つだけで自動でやってほしい
各バックアップ毎の中身の確認が面倒。 → 差分だけ表示してサクッと確認したい
ディレクトリ作りすぎて容量圧迫やばい。 → 容量を圧迫することなく管理したい


この赤字の部分の問題を解決したのが「バージョン管理ソフト」なのです。


■個人開発?チーム開発?
・バージョン管理を使うには、「リポジトリ」というのが必要になります。
・「リポジトリ」ってのは簡単にいうと、バージョン情報を保持してるフォルダみたいなもの。
・一人で開発する時には、適当にデスクトップとかのローカル環境に作ればOK。
・しかし、チームで開発する時には、チームのメンバ全員から参照できる必要がある。


AさんのPCのデスクトップにリポジトリ(フォルダ)を作ると、
もちろんBさんのPCからはアクセスすることができません。
これではチーム間でソース共有はできません。困りました。

では、どうすればいいでしょうか?


■共用リポジトリをどこに置くか?
1. GitHub
2. どっかのサーバ上に設置
3. Dropboxを使う

1. Github
・最近話題のGitHub。
・ウェブ上にリポジトリ(フォルダ)を置くことでチーム全員がアクセスできるようにする。
・無料で使えて、操作性も高いので人気。
♦ただ、SSHとかの設定をする必要があるので、超ド初心者は時間かかる。
♦無料利用ではソースは全世界に公開されてしまうので、超ド初心者は恥ずかしい。

2. どっかのサーバ上に設置
・自分で借りているレンタルサーバ上にリポジトリを設置する方法。
・リポジトリ(フォルダ)までのURLは関係者にしか知らせないので、非公開で運用できる。
♦ただ、レンタルサーバ借りてない人はGitだけのために借りるのはアホらしい。
♦チームのメンバ分アカウント作ったり、設定にも時間がかかる。

3. Dropboxを使う
・上のスライドは、これを使った際の手順書。
・Dropboxには「フォルダ共有機能」というのがあり、チームみんなで一つのフォルダを持てる。
・この共有フォルダにリポジトリを置けば、チームのみんながアクセスできちゃう。
・Dropboxはローカル環境からアクセスできるため、SSHの設定はしなくてもOK。


僕の個人的なオススメは、
・最初Dropbox → 慣れてきたらGitHub
パターンです。理由はありません。何となくです。


■GitとSubversion(おまけ)
・本題からは少し外れるメモ。
・バージョン管理ソフトとして有名なものに、GitとSubversionがあります。
・Gitは分散型、Subversionは集約型なんて呼ばれたりしますが、初心者にはカオスです。

簡単に説明すると、
Subversionではソースコードをコミットすると、いきなりチーム共有のリポジトリが変更されます。
Gitではソースへの変更をコミットすると、いったん自分のローカルのリポジトリ内でのみ変更されます。その後、プッシュ操作を行うことで初めてチーム共有のリポジトリが変更されます。

どちらが良いというわけではなく、好みかと思います。
僕はGit派。
理由としては、最近Gitがキテルらしいというミーハー精神と、ちょいちょいコミットしたい性分だからです。Subversionだとちょいちょいのコミットが他のメンバーに見られちゃうんで恥ずかしいですよね。



以上、バージョン管理ソフト使って爆速開発しようぜ!な記事でしたー。



[Objective-C] 指定したURLにGETアクセスし、レスポンスをJSONとしてパースする

本日のテーマです。
① Objective-c からAPIを叩く
② レスポンスをJSONとしてパース


■ソースはこんな感じ

NSString* url = @"アクセスするapiのURL";
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:url]];
NSData *json_data = [NSURLConnection sendSynchronousRequest:request returningResponse:nil error:nil];
NSError *error=nil;
    
NSArray *jsonArray = [NSJSONSerialization JSONObjectWithData:json_data options:NSJSONReadingAllowFragments error:&error];


■説明
1. リクエストURLを作成
2. sendSynchronousRequest: メソッドでURLにアクセス
3. 返ってきたデータをJSONObjectWithData: メソッドで分解


■メモ
・JSONObjectWithData~ の受け取りは、NSDictionaryの時がある。
・これは簡易にHTTPRequestできる方法で、GETでのアクセスになる。
・POSTでアクセスするにはもうちょっと複雑(後日記事書きます。)
・URLにパラメータが含まれる場合、 [NSString stringWithFormat] で作りましょう。




2012年8月23日木曜日

php高速化tips

勉強になったのでメモ。


 *  PHP コード最適化 Best Practices 63+
  * 01. static にできるメソッドは static として宣言しよう。(4倍速い)
  * 02. echo の方が print より速い。
  * 03. echo '文','字'; (カンマ区切り)の方が、'文'.'字' (ドット連結)より速い。
  * 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。
  * 05. 大きい配列のような変数は unset() してメモリを解放しよう。
  * 06. マジックメソッド(例: !__get, !__set, !__autoload)は使用を避けよう。
  * 07. require_once はハイコストなのです。
  * 08. include や require でファイルはフルパスで指定しよう。
  * 09. スクリプト開始時間は time() でなく $_SERVER!['REQUEST_TIME'] で取得。
  * 10. 可能であれば、正規表現より strncasecmp、strpbrk、stripos を使おう。
  * 11. strtr(str_replace の4倍速い) > str_replace > preg_replace の順に速い。
  * 12. 引数に配列、文字列両方を受け入れるような関数は避け、個別に関数化しよう。
  * 13. if をたくさん使ってるなら switch を活用しよう。(訳注:ってことでいい?)
  * 14. @によるエラー制御はすんごく遅い。
  * 15. Apache の mod_deflate(Apache2系) を ON にしておこう。(No.42 参照)
  * 16. 処理が終わったらデータベースの接続は切っておこう。
  * 17. $row!['id'] は $row[id] より7倍速い。
  * 18. エラーメッセージはハイコスト。
  * 19. for 文の条件式には count($array) のような関数をいれない。(変数に格納)
  * 20. メソッド内ではローカル変数をインクリメントするのが一番速い。
  * 21. グローバル変数のインクリメントはローカル変数より2倍遅い。
  * 22. オブジェクト変数(例:$this->v++)のインクリメントはローカルより3倍遅い。
  * 23. 未定義のローカル変数のインクリメントは定義されたものより9~10倍遅い。
  * 24. 未定義のグローバル変数についても同様。
  * 25. メソッドの起動コストはクラス内のメソッド数とは無関係。
  * 26. 派生クラス内のメソッドは、基底クラスで定義されたメソッドよりも速い。
  * 27. 引数1つの空関数を呼び出すのにも、ローカル変数 $local++ 7~8回分のコスト。
  * 28. ダブルクォート より シングルクォート の方が若干速い。
  * 29. 03 と重複か。(注:これは複数の引数を受け取る echo でのみ有効)
  * 30. PHP スクリプトは静的な HTML ページよりも2~10倍の時間がかかる。
  * 31. キャッシュを利用しよう。通常、コンパイル回数 x 25~100% 分速くなる。
  * 32. これもキャッシュについて。memcached とか使おうよ。
  * 33. if (strlen($foo) < 5) を調べたいなら if (!isset($foo!{5})) と書くと速い。
  * 34. $i++ より ++$i の方が速い。(そういう opcode optimizer が走ってる場合)
  * 35. 全部が全部 OOP でなくても良い。(コストやメモリの浪費になってるかも)
  * 36. すべてのデータをクラスにしようとしないこと。配列も十分便利です。
  * 37. メソッドを分割しすぎない。(どれを再利用するのかよく考えよう)
  * 38. メソッドを分割したくなったら後でいくらでもできる。
  * 39. もとから用意されてる 関数たち を活用しよう。
  * 40. 非常に時間のかかる関数 → C言語による拡張モジュール化も検討しよう。
  * 41. コードをプロファイリングしてボトルネックを見つけよう。Xdebug とか。
  * 42. Apache の mod_gzip(Apache 1系)は、転送量を最大80%減。
  * 43. : A HOWTO on Optimizing PHP with tips and methodologies を見てね。
  * 44. 28 と重複か。
  * 45. 13 と重複か。
  * 46. 19 と重複か。
  * 47. ループ処理には foreach を使おう。
  * 48. 複雑なクラスを作ってるなぁと思ったら → Singleton モデルを検討しよう。
  * 49. DB に入れる値なら GET より POST を使おう。(パフォーマンスが上がる)
  * 50. 可能なら正規表現より、ctype_alnum、ctype_alpha、ctype_digit を使おう。
  * 51. ファイル指定は basename / file_exists / open_basedir よりフルパス指定が速い。
  * 52. require_once より require を使おう。(opcode キャッシュがらみの理由で)
  * 53. 一時的なファイルを作るときには tmpfile や tempnam を使おう。
  * 54. 外部サービスに XMLHTTP で接続するときにはエラー回避のため Proxy を使おう。
  * 55. デバッグするときは error_reporting (E_ALL); にしておこう。
  * 56. Apache の allowoverride を "none" にしておくとパフォーマンスが向上。
  * 57. 静的なコンテンツには thttpd のような高速なファイルサーバを使おう。
  * 58. パスなどの設定パラメータは配列に serialize して入れ、キャッシュしておこう。
  * 59. アクセスの多いページには PHP の 出力バッファリング を使おう。
  * 60. DB 固有の prepare メソッドではなく PDO::prepare を使おう。
  * 61. SELECT * (ワイルドカード)を使うのはやめよう。
  * 62. PHP より賢い DB ロジック(queries, joins, views, procedures)を活用しよう。
  * 63. SQL の省略表記を活用しよう。
   * (例:INSERT INTO MYTABLE (FIELD1,FIELD2) VALUES (("x","y"),("p","q"));)

 * [ PHPコード最適化Tipsのウソと本当(解説)] (PHP コード最適化 Best Practices 63+に優先度と解説つけたもの)
  * 優先度A. 頻度も高いし使えそう
   * 01. static にできるメソッドは static として宣言しよう。(4倍速い)
   * クラス内で定数代わりに使ってる変数があるなら、const にしよう。
   * 04. ループの最大値は、ループ「内」ではなく「前」にセットしておこう。
   * 19. for 文の条件式には count($array) のような関数をいれない。(変数に格納)
   * 10. 可能であれば、正規表現より strncasecmp、strpbrk、stripos を使おう。
   * 11. strtr(str_replace の4倍速い) > str_replace > preg_replace の順に速い。
   * 50. 可能なら正規表現より、ctype_alnum、ctype_alpha、ctype_digit を使おう。
   * 39. もとから用意されてる 関数たち を活用しよう。
   * 53. 一時的なファイルを作るときには tmpfile や tempnam を使おう。
   * 18. エラーメッセージはハイコスト。
   * 55. デバッグするときは error_reporting (E_ALL); にしておこう。
   * 17. $row!['id'] は $row[id] より7倍速い。
   * 23. 未定義のローカル変数のインクリメントは定義されたものより9~10倍遅い。
   * 24. 未定義のグローバル変数についても同様。
   * 31. キャッシュを利用しよう。通常、コンパイル回数 x 25~100% 分速くなる。
   * 32. これもキャッシュについて。memcached とか使おうよ。
   * 58. パスなどの設定パラメータは配列に serialize して入れ、キャッシュしておこう。
  * 優先度B. 機会があれば / 迷ったら使うかな的
   * 03. echo '文','字'; (カンマ区切り)の方が、'文'.'字' (ドット連結)より速い。
   * 08. include や require でファイルはフルパスで指定しよう。
   * 51. ファイル指定は basename / file_exists / open_basedir よりフルパス指定が速い。
   * 09. スクリプト開始時間は time() でなく $_SERVER!['REQUEST_TIME'] で取得。
   * 20. メソッド内ではローカル変数をインクリメントするのが一番速い。
   * 21. グローバル変数のインクリメントはローカル変数より2倍遅い。
   * 22. オブジェクト変数(例:$this->v++)のインクリメントはローカルより3倍遅い。
   * 28. ダブルクォート より シングルクォート の方が若干速い。
  * 優先度C. 実はほとんど効果がないけどね
   * 02. echo の方が print より速い。
  * 優先度不明. 効果がいまいちわかんないです。誰か説明 / 検証してください
   * 05. 大きい配列のような変数は unset() してメモリを解放しよう。
   * 07. require_once はハイコストなのです。
   * 52. require_once より require を使おう。(opcode キャッシュがらみの理由で)
   * 16. 処理が終わったらデータベースの接続は切っておこう。
  * 非推奨? 速度の代償が大きすぎるんじゃ…
   * 06. マジックメソッド(例: !__get, !__set, !__autoload)は使用を避けよう。
   * 33. if (strlen($foo) < 5) を調べたいなら if (!isset($foo!{5})) と書くと速い。
   * 34. $i++ より ++$i の方が速い。(そういう opcode optimizer が走ってる場合)

2012年7月27日金曜日

Developers [Social Enterprise] Summit 2012に参加してきました。

Developers [Social Enterprise] Summit 2012に参加してきました。
忘れない内に感想とかをメモしときます。

全体的なテーマはエンタープライズ向けのサービスを提供する身としてソーシャルとどう向き合うか的な感じ。
協賛にSalesforce、GREEなど多くの有名企業が名を連ねていました。
またJenkinsの開発者の方とかもいました。
普段のweb系のカンファレンスよりもエンタープライズ向けだからか年齢層は高めに感じました。
名刺見ると名だたる日系大企業の方々が多く来場されていました。

タイムテーブルはこちら

僕が参加したセッションは
【S-1】クラウドが破壊するもの、創造するもの
新野 淳一 氏 / 西脇 資哲 氏 / 藤井 彰人 氏 / 村上 明子 氏 / 関 孝則 氏

【B-1】Salesforce R&DとソーシャルとEngineer Happiness
 大沢 良樹 氏 

【B-2】エンタープライズ開発におけるコラボレーション - JIRAによる顧客と開発チームのつなぎ方
鈴木 雄介 氏

【B-3】社内ソーシャルメディア開発トライ&エラー ~おれたちの4tate~
原島 法子 氏 / 岩永 義弘 氏 
【A-4】[パネルディスカッション] エンタープライズ✕ソーシャルエンジニアのスキルセット
鈴木 雄介 氏 / 山本 裕介 氏 / 藤本 真樹 氏 / 大沢 良樹 氏 

以上です。 順番に軽く内容と感想。
【S-1】 新野さんの講演から。
クラウドが普及することでSIerの仕事が減り、単価も下がってるという破壊の側面。
実際、あるSIerの単価は二桁下がったそうです。なかなか衝撃的な下げ幅。
ハードウェアがいらなくなったこと、Paasなどでは運用もいらないことが要因だそうです。

一方クラウドが想像するものとして

  1. サービスモデル・・・誰でもどこでもサービスを開始できるようになったね
  2. マルチデバイス対応・・・モバイルでもどこでも使えるようになったね
  3. ビッグデータの活用・・・かなりのコストがかかってた大規模分散処理はクラウドで低コストできちゃうね
てなことが語られました。
すべての共通することとして「コミュニケーションの重要性」という話から、エンタープライズ向けソーシャルの話へ。

ソーシャルエンタープライズという言葉は二年ほど前にSalesforceが言い出してからかなりかなり熱い。
chatterとかそんときからがんばってる。

どんどんいろんなツール(エンタープライズ向け、コンシュマー向け含む)が出てきたけど、それを整備する共通基盤みたいなものが必要なのでは。
それらに向かう新技術としてOauth2.0とか出てきてるけど、まだまだだよね。
これからだよね!
てな感じでした。

続いてgoogle藤井さん
ユーザ側の変化。
コンシュマーとして受け入れたものをエンタープライズでも受け入れるようになってきた。
テクノロジーの変化。
クラウド、モバイル、ソーシャル。
こんなキーワードが出た上で、googleサービスの紹介。
Hangoutを使って六本木にいる社員の方と話してみたり、Google Big Quey、Google Map Engineなどの説明をされていました。
どれもgoogleは情報を与えているに過ぎない。
この上でなんかおもろいことできそうでしょ!?ってスタンスが印象的でした。
その通りだと思いますw
いろいろ妄想の膨らむお話できた。

続いてマイクロソフト西脇さん
マイクロソフトはソーシャルに向けたたくさんのラインナップ持ってますよってお話。
skype、yammer、office365、azure、windows8。
病院での事例などをもとにどう使われているか、いかにソーシャルであるべきか、が語られていました。
人だけでなく、ドキュメント、ファイルなどすべてをソーシャルに扱おうという姿勢が印象的でした。

IBM村上さん
ソーシャル活用したたくさんの分析のお話。
かなり詳細にソーシャルメディアでの行動、会話を分析してらっしゃいました。
分析ツールは作るから、どんな情報が欲しいのかもっと現場から情報ちょうだい。
て感じが印象的でした。

Salesforce関さん
chatterいいよ!!ってお話。
たしかによさそうでしたw
今までいろんなツールでいろんなとこで管理してた情報も一つにして、その中で探せるようにすることで、かなり効率があがったそうな。
chatterはほんまによさげでした。

■感想
ソーシャルエンタープライズのサービスが数多く紹介されていてその多さにびびりました。
まだまだ伸びる市場ではあると思いますが、すでに数多くのプレイヤーが世界中にいるtことも確かでした。
コンシュマーでの体験がエンタープライズにもどんどん入ってきてることを考えると、そこをとれるプレイヤーは数多くないはずなので、どこが取るか注目ですね。
また、コンシュマー向け、エンタープライズ向けを統一するような共通基盤が現れるのではないかという妄想もだいぶ楽しいですね。

【B-1】
Salesforceがどのように社内向けソーシャルを実現しているかのお話。
主に、chatterをどう使っているかのお話でした。
Salesforceの文化として「Dog fooding」使ってみなきゃわからんでしょ。
って話が印象的でした。
実際、Salesforceではかなり盛んにchatterが使われている様子。

chatterはすべての情報のハブとなり、いろんな情報をタイムラインで流してる様子。
リリース情報、コミット情報、tips、疑問、雑談などいろんな情報が流れることで、社内の部署を超えたコミュニケーションが活発に行われてる様子でした。

■感想
chatterはかなりよさそうでした。
効果がありそうなのが、目に見えた感じでした。

【B-2】
アジャイルとWFの話。
まぁ、何が最適かとか状況次第だし、最適解はないね!
ただ、エンタープライズ向けは「複雑かつ不定期で短納期でスコープに妥協がゆるされない」つまりアジャイルもWFも向いてないね!って結論が印象的でしたw
その通りだと思いましたw

その流れを組んでJIRAの説明。
プロジェクト管理としてかなりよさそうでした。
いろんなプラグインが出てて、好きにカスタマイズできそうな感覚。

■感想
JIRA使ってみますw


【B-3】
アジャイルやってみたこと報告するよってセッションでした。
会社の合併とかいろいろ合って、いろんな人と仕事するのが大変でしたよ〜
そこで、先が不透明なときはアジャイル!!
って感じで始めたけど、二人で開発するのはおすすめできません。。
って結論でした。
そのあとUXについて。
主にユーザビリティテスト大事だよね!
ってお話でした。
作ったもののつかわれなかったら意味ないよね。
ちゃんとユーザビリティテストして使われるものを作りましょう。
ってことでした。

■感想
恥ずかしながらユーザビリティテストまだやったことないので、今度やってみようと思います。。

【A-4】
パネルディスカッション形式。
テーマ1「ソーシャルとは何か」
・twitter 山本さん
今まではエンタープライズと対極。
これからはエンタープライズで応用するもの。

・GREE 藤本さん
対義語はスタンドアローン??
そんなことはありえないからそんな厳密に考えなくてもいいんじゃない?
そんなことより、エンタープライズでもコンシュマー向けでもどこまでオープンになるか。
その閾値を見極めることに興味がある。

・Salesforce 大沢さん
デベロッパーを成長させてくれるツール。
デベロッパーとして必須なスキル、ツール。

テーマ2「仕事の中でソーシャルプラットフォームをどう使っているか」
・GREE 藤本さん
人数が急増しているため、情報の管理、伝播がソーシャルな要素を取り入れないとできない。
例 github enterprizeでのソース共有
最新の情報を得るためにはtwitterが一番早い。わかった気になった問題は残るがセキュリティなど更新の早い分野ではスピードも大事。

・Salesforce 大沢さん
chatterの導入によって開発とオペレーションの差を埋めた。
最適な情報をどんどん取り入れることでエンジニアのポテンシャルも高まる。

テーマ3「オープンすぎてこまったこと」
・GREE 藤本さん
今のところない。
コードの共有も含めて議論し続けている。
ちょっとづつ公開してどこまでできるか探り探り。

・twitter 山本さん
オープンにすることは最終的に会社に返ってくる。
社内で使って誰でも使えそうであれば、どんどんオープンにする。
bootstrapはその例。
オープンにするかどうかは専門の部署がありそこが判断してる。
ソーシャルの一番の特徴はタイムライン。
古い情報はもう見なくていいよね!っていう暗黙の了解がある。
タイムラインを中心として情報を拾っていく。

ざっとこんな感じでした。

■感想
何がどこまでオープンになっていくかはかなり興味がある。
個人的にはほぼすべてくらいオープンにしてるが、たぶんそうはならない。
人によってソーシャルとの付き合い方は変わると思うが、オープンにすることのメリットがもっと普及すればいいのにと、個人的には思う。


2012年7月23日月曜日

【C言語】システムコール関数でファイル入出力(2)

前回に引き続き、システムコール関数でのファイル入出力のメモ。

【C言語】システムコール関数でファイル入出力(1)


write()関数とread()関数

writeの例.


#include<stdio.h>
#include<hogehoge.h>

int main(void){

int fd;
char filename = "test.txt";
char message = "ここにファイル出力したい文字列を書く";

//  ファイルオープン
fd = open(filename, O_WRONLY);

//  ファイル書き込み
write(fd, message, strlen(message)+1);

//  ファイルクローズ
close(fd);

return 0;

}


write関数

fd - 対象ファイルのファイルディスクリプタ
message - 書き込む文字列
strlen(message)+1 - 書き込み文字列の長さ




readの例.


#include<stdio.h>
#include<hogehoge.h>

#define BUF_LEN 1024

int main(void){

int fd;
char filename = "test.txt";
char buf[BUF_LEN];

//  ファイルオープン
fd = open(filename, O_RDONLY);

//  ファイル書き込み
while ( ( n =read(fd, buf, BUF_LEN) ) > 0 ){
     printf("%s", buf);

}

//  ファイルクローズ
close(fd);

return 0;

}




read関数
fd - ファイルディスクリプタ
buf - 読み込んだ文字列を格納する箱
BUF_LEN - 一回で読み込む文字列の長さ(バイト数)



readの返り値として、「読み込んだバイト数」が返ってきます。
つまりこのwhile文は、まだ読み込む文字がある場合はずっとループする、ということ。
BUF_LENで指定したサイズ(今回は1024)ずつ読み込み、表示します。





【C言語】プロセスIDを表示する

C言語と対話する日々のイトウです。
今回はプロセスIDの表示方法について。


UNIXコマンドだと
$ echo $$
$ ps u
で表示できるプロセスID。C言語では少し記述が必要です。



#include <stdio.h>

// (1) 必要なライブラリをインクルード
#include <sys/type.h> 
#include <unistd.h>

int main(void) {
    int pid;
// (2) プロセス番号を取得
    printf("my PID is %d¥n", getpid() );  
    return 0;
}



こんな感じで表示できます。
getpid()が自身のプロセス番号を表示する関数で、
それを使うために必要なライブラリをインクルードしてる感じです。

簡単ですね。