1週間で受かる！(基本|応用)情報技術者試験
TL;dr
Twitterやってるような人間はなんとなくやれば受かるから取り敢えず過去問解け
この記事はIPA試験を真面目に受けることができない人間の合格体験談です。本来は1ヶ月程度の時間を掛けてじっくり対策をすることが望ましく，この通りに勉強すれば誰でも合格するという保証をするものではありません。非推奨です。
はじめに
春のIPA試験まで1ヶ月を切りTwitterもIPA試験の勉強をしたいがやる気にならない人で賑わいを見せています。
ぼくは2018年春に基本，同年秋に応用情報技術者を取得しましたが，基本は1週間，応用は2日の勉強で受験してなんとか合格したので，合格体験談(笑)みたいなものを書いておこうかと思います。
ところでこれは当たり前の話なのですが，これからIPA試験を受ける皆さんは絶対に3日前まで勉強をしないとかそんな怠慢は辞めましょう。受験料払ってるんだからちゃんと勉強して合格しようね。
基本情報技術者試験
TL;dr
- 参考書をなんとなく読む
- 午前過去問だけやっとけばどうにかなる
詳しく
ぼくは高専の制御情報工学科に通っていますが，1年次の必修科目だった「情報リテラシー」にてITパスポートのテクノロジ系の範囲を学習していました。
また，3年次までの科目で論理回路や集合論，ソートアルゴリズム，探索アルゴリズムなどについては触れていたため，基本的にはストラテジ・マネジメント系を重点的に対策しました。
勉強法についてですが，割と真面目に(1週間前から)やりました。
数年前に買っていた参考書があったので引っ張り出してきて全ページに目を通しました。当然自明だなと思う部分があるのでそこは飛ばして，「これはわからないかもしれない」という部分を紙に写経しました。
その後，過去問道場でひたすら過去問を解きました。解く問題は直近3～4回のものを繰り返しておけば良さそうです。80%ぐらいあれば余裕だと思います。
インターネットでやれ難関だ対策が必要だ何だと評判の午後試験ですが，午前試験の内容をちゃんと理解していれば特に難関でも対策が必要でもないです。所詮は文章題だし選択式。
ただし文章読解が壊滅的に無理である自覚のある方は文章題に慣れる練習ぐらいはしておきましょう。
ぼくは午後問に目すら通さず望みましたが結局午前試験より午後試験のほうが得点高かったです。
応用情報技術者試験
TL;dr
- 参考書を捲る
- 午前試験の過去問をひたすら解く
- 余力があるなら午後試験の対策(狙っている選択分野について深く勉強)
詳しく
高専プロコンの準備をしていたら2日前になっていたので死ぬ気で勉強しました。
取り敢えず図書館で数年前の参考書を1冊借りましたがほぼ開きませんでした(厚くて重いので)。
とにかく常に過去問(過去3,4回分)を解いていました。事前勉強を一切せずひたすら過去問を解きました。過去問道場は偉大。
最初の頃は正答率が40%ぐらいだったのが70%と少しになるぐらいまでひたすら過去問を周回しました。
過去問を解いていて何だお前と思った部分は調べたり解説を見て理解する，あとはひたすら解きます。
気付いたら当日になっていたので直前はなんとなく参考書を捲って心を落ち着かせていましたが不安になるばかりでした。
確実に6割取れてるなというのが確認できたところで早めに退室して初めて午後問の形式を見ました。急いでご飯を食べて選択問題でどれを選ぶか当たりを付けつつ集中的に参考書を読みました。
応用情報の午後問は基本情報と違って記述があるのでちゃんと対策をしたほうが良いです。ただ分野が選択できるので，分野によっては自明しかないな大丈夫かこの問題となったりもします。
基本的には得意分野で満点近い得点ができれば苦手なところは半分ぐらい当てれば大丈夫なので，得意分野で殴る感じが良いと思います。
特にセキュリティとかソフトウェア開発，アルゴリズム辺りはTwitterで毎日技術の話をしているような人間なら簡単に思えるかと思います。Linuxコマンドの話とかCIの話とかが出ました。
対策をするとすれば参考書の狙っている分野のところを写経すれば十分だと思います。
まとめ
直前に勉強しても合格はできますが真面目に対策した方が身に付くので良いです。
ただし受験1週間前になって「基本情報 直前」とかを調べ
「直前1ヶ月でも大丈夫じゃねえんだよ俺はもう1週間切ってんだよ！！！！！助けてくれ！！！！！」
と絶望することはありません。君ならできる。1週間前でも2日前でも大丈夫。
この記事を読んでいるあなたの健闘を祈ります。
高専カンファレンスin西京2の運営をした話
TL;dr
- たくさん人が来てくれたし楽しんでくれていたので良かった
- 中途半端に企業を関わらせると良くない
- 運営としては失敗だった
注意
呪詛っぽい話が多いです。
ぼく個人としてのあくまで主観的な話です。高専カンファレンスin西京2実行委員会とは関係がありません。
事前準備
昨年3月17日に行われた高専カンファレンスin西京を引き継ぐということで実行委員長が奮起になってくれたので手伝うよと声を掛けました。5,6月には運営メンバーは大体決まっていました。
元々「宇部と徳山合同なので宇部って使うのもあれだし西京にしませんか」というのが名前の由来だったので，西京という名前を引き継ぐわけだし徳山の人間も入れませんか良いですねとなり結局宇部徳山の7人？ぐらいで運営チームを組みました。
昨年の反省を活かした結果少人数での運営になりましたがここは非常に良かった点です。正解でした。
11月とかそれぐらいの頃に運営メンバーを集めて顔合わせをしました。
主に役割分担とか自己紹介とかをしていました。ぼくはまあ受付とかやりますとなりました。
顔合わせミーティングのときに，運営のメンバーから「ある企業の人からイベントをやるなら面白いゲームがあるから呼んでほしいと言われている」みたいな話をされました。
西京2に来た人ならわかると思います。懇親会のゲームです。
このときは詳しいことを聞いていなくて，まあ盛り上げてくれるなら良いんじゃないぐらいに思っていました。「良いんじゃないですか」と言った覚えがあります。思えばこのときにもっと詳細を明らかにしておくべきでしたね。
ある程度の準備は順調に進みました。当初会場にしようと予定していた中市コミュニティホールNacさんとはこの頃既に3月16日に会場を借りるという話を進めていました。
…が，会場担当とNacさんとの間で何らかの認識の食い違いがあり(認識の食い違いがあったとしか聞いていません)，突如Nacはカンファ当日に使えなくなりました。これが判明したのが1月始めです。厳しい。
このあとはしばらく必死に会場探しをすることになります。
良い感じに会場が山口労福協会館に決まりました。立地以外は特に文句ない環境だったかなと思います。
並行して「ある企業」とのやりとりが進んでいました。ここでいろいろと問題がありました。
「ゲームに2時間かかる」との話があったのです。
いやいやいや2時間は無いだろ。懇親会全部潰れるだろ。絶対に無理だろ。人集まらんだろ。
さらに内容が「ビジネスゲーム」だと言うので，それ人集まるか？と思い始めました。ぼくは不安になりました。
このときは結局まあ所要時間は1時間が限界ではないですかという話になったので，担当のメンバーには先方にそのように伝えてもらいました。
そこで判明したのが，実はこの2時間には企業紹介が含まれていたということです。
メンバーからは「企業紹介とゲーム説明の一部を削ってもらうことで所要時間を1時間に短縮することができたが，その結果こちらから来てもらうようにお願いしたような形になってしまった」と連絡がありました。ぼくはとても不安になりました。
当初の話ではスポンサーをお願いするということで交渉を進めていたはずだったのですが，相手方からは「企業としての利益が薄い，今のままでもボランティアのようなものなので」と断られたとのことでした。はい…
さて，そんなこんなでごたごたしている間にも発表応募が始まります。当初の予定以上の応募をいただきました。ありがとうございました。
できるだけたくさんの発表を聞きたかったので当選発表直前，ギリギリまでスケジュールを調整しました。その結果当初は懇親会を2時間ほど取りゲームに参加した人も懇親会で自由な時間が取れるようにと思っていたところが半分に削れて厳しいことになってしまいました。懇親会でゲームに参加してくださった参加者の方には本当に申し訳ないと思っています。
抽選を完全に抽選にするかある程度内容でふるうかという議論がありましたが，結局あのフォームの内容ではふるいにかける材料として足りないし云々というので完全抽選式にしました。
ここでやりとりをしていた企業の方から「10分枠で登壇したい」と声掛けがありました。
ここには
- 応募フォームからの応募ではない
- connpassで参加者として登録されていない
という問題がありました。
高専カンファレンスin西京2のconnpassページには
発表を希望される方は、当ページからイベントに参加登録した後、以下のフォームからご応募ください。
と明確に記述があります。
この記述があるにも関わらず運営と関わりがあるからという理由で特例措置を取って良いものなのかというので運営でも揉めました。結局，降りていただくことにしました。
正直企業として来られる以上ある程度イベントに対する理解はしてほしかったという気持ちがあります。公式な手続きも踏まずにイベントに対して「利益が薄い」と言われてしまうとこちらとしてはうーんとなりますね。当日も「自分たちはイベントに参加しに来たのではない，ゲームを提供しに来たのだ」みたいな態度をされていてあまり良い印象は受けなかったです。
このあとは基本的にポスターやステッカーの入稿スケジュールと戦うことになります。
ポスター担当には2月14日を期限としてお願いしていましたが実際に原稿が上がってきたのは3月3日でした。おかしいな。
ステッカーは爆速で仕上げてもらいました。ありがとうございました。
当日
特別問題なく進めることができました。参加者のみなさん円滑な運営にご理解・ご協力ありがとうございました。
運営のメンバーが当日無線LANルータを持参してくれたり，私物の配信機材を持ってきてくれたりしました。
それに伴って司会担当が突如配信と司会を両方行ってくれていたので途中からはぼくが司会を交代しました。
気になった点は司会が登壇者名を正しく読まなかったり知り合いだからといって「〇〇くん」と呼んでしまったりしたなどです。
イベントの運営に私情を持ち込んではいけないと思います。これは高専祭のゲーム大会でも思ったことですが。
途中から司会を交代したので，ぼくが司会をしている間に懇親会のお菓子を買ってきてもらいました。ごめんなさい。
展示発表はとにかく厳しかったなという印象です。時間に余裕がなかったことと事前準備が十分でなかったことが原因としてあります。
ぼくとしては事前準備として不備なく展示品が動くかどうかのチェックまでしておいてほしかったのですが，担当メンバーに上手く伝わっていなくて設置のみの事前準備になってしまっていました。実際に上手く展示品が動いていないっぽいのを見たので悔しかったです。ここは本当に運営の意思疎通が悪かったです。
また，展示ブースに展示者の知り合いが集まってほぼオフ会状態になっていたりしたので適宜散らしていました。純粋に展示を楽しみたい人に対して迷惑でしかないですし，展示者としてもそれを自分から散らせないのはちょっと誠意が足りないかなという気がしなくもなかったです。
一番心配していた時間については綺麗に想定範囲内に収まったので良かったかなと思っています。
タイマーのベルの回数について司会から言及がないと心配になりますね。
飛び入りLTも良い感じに進みましたし，今回の運営の一番良かった点はリアルタイムに参加者の意見を聞きながら動けた点かなと思います。
途中から飛び入りLTの会場を移動したのは正解だったと思いつつ，移動前に話をしてくださった方には申し訳ない気持ちしかありません。
個人的に不満だったのはぼくの飛び入りLTのときに知り合いが野次を飛ばしてきていたところで，ぼくはあくまで運営として登壇者としてLTをしていたので，ぼく個人を茶化す意図の大きな声が飛び交っていたのは正直少し悲しいなと思いました。仕方ないと言えばそう。
今後の反省
中途半端に企業との関わりを作るのは良くないです。
また，今回はぼくは受付という立場だったのに関わらず事前準備のスケジュール管理をしたり当日の司会をしたりしてしまったので，そこは悪い癖だなと思っています。ちゃんと実行委員長にやらせなければいけないところでした。
去年は運営チームが大きすぎて運営がいろいろと滞ったりしてしまいましたが，今年は少数で進めたことで発言に対して誰からもレスポンスがないという嫌な事態は目にせず済みました。良かったです。
ただやはり宇部と徳山の間にはいろいろと壁があったように思います。イベントの運営は少なくとも実行委員長が全員とある程度信頼関係のあるメンバーで行うべきです。
とは言え全体的には参加してくださった方々にも楽しんでもらえていたようですし，イベントとしてはまあまあ良かったのかなと思います。
参加してくださった皆さんは全国各地から山口まで来ていただいてありがとうございました。
山口が「なにもないクソ田舎」という認識をされていないことを祈ります。ぜひまた山口に来てください。
また，高専カンファレンスin西京の実行委員長として，このように下の代が自分の意志を継いでくれたことを本当に誇りに思います。嬉しいです。実行委員長，本当にありがとうございました。お疲れ様でした。
また山口県で高専カンファレンスをするという動きがあればそれは本当に嬉しいことだなと思います。
以上でぼくの高専カンファレンスin西京2を締めたいと思います。お疲れ様でした。
Docker入門備忘録① Dockerの基本コマンドを使えるようになる
TL;dr
- docker runの基本的なコマンドを使う
- コンテナにローカルのディレクトリをマウントする
想定層
- dockerが本当にわからない
- dockerの基本的なコマンドも使えない
- docker-composeの良さがよくわからないし何をしているのかもわからない
Dockerの概要
Dockerの中にコンテナと呼ばれる無数の仮想環境を作ることができる。
DockerHubにはたくさんのイメージ(=既に出来上がった環境)が転がっているので，それをdocker pullで拾ってくると使えるようになる。
docker pullで拾ってきたイメージをdocker runで有効化し(=コンテナ化)再生することができる。
docker psをすると現在立ち上がってるコンテナの一覧が見れる。
docker ps -aで現在存在する(止まっているコンテナも含む)コンテナを一覧できる。
docker stopでコンテナを停止できる。
docker rmでコンテナを削除できる(このとき元になったイメージは残る)。
元のイメージを削除したい場合はdocker rmi，現在システム上にあるイメージはdocker imagesで確認できる。
docker execでコンテナの中に入ってコマンドを実行できる。
Docker上にGolangの実行環境を作ってみる
まずはGolangを実行するためのイメージを拾ってきます。
$ docker pull golang
$ docker images REPOSITORY TAG IMAGE ID CREATED SIZE golang latest 36e5881731e4 6 days ago 774MB
正常にgolangというイメージが取得できていることがわかります。
このイメージを使ってコンテナを作ります。
$ docker run -d -it --name golang_container golang 85f7fd1c6ea3155d8a6ac6cf924715d20c0e2f3dd9235756298ef1710d6389a4 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 85f7fd1c6ea3 golang "bash" 6 seconds ago Up 5 seconds golang_container
コマンドを解説していきます。
docker run -d -it --name golang_container golangでgolangというイメージを元にしたコンテナgolang_containerを作っています。
-dフラグはバックグラウンドで実行するという意味です。これがなければ直接ターミナル上でコンテナが起動します。
-itフラグはコンテナ上で任意のコマンドを実行し，ターミナルにつなげます(lsやcatなど。今回の場合(?)指定がない場合bashが起動します)。
--nameフラグはコンテナに名前を付けています。名前は直後の引数に指定します。この場合はgolang_containerです。
最後にgolangとして元にするイメージを指定します。
よって，今回の例では，golangというイメージを元に作成したコンテナにgolang_containerと名付け，bashをバックグラウンドで実行しています。
この例でbashをバックグラウンドで実行している理由として，今回利用しているgolangイメージの場合デフォルトの状態だとコンテナを実行したときに何もせず終了してしまうためです。
本来ならこの中でサーバプログラムを実行するなどして永続的に終了しないようにするのですが，今回は説明のためにbashを実行したままにしてコンテナが止まらないようにしています(今回の例で-itを付け忘れるとdocker psに出てこなくなります)(正直この辺よくわかっていません)。
コンテナの中に入ってみます。
$ docker exec -it golang_container /bin/bash root@bac2899e4a10:/go#
コンテナ内のbashが立ち上がり，ターミナルに接続され入出力ができるようになりました。
この中にはデフォルトでbin，srcの2つのディレクトリがあります。この中に自由にソースを作成し，実行できます。
動作確認ができたので，コンテナから出て，コンテナを削除します。
root@bac2899e4a10:/go# exit exit $ docker stop golang_container golang_container $ docker rm golang_container golang_container
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
コンテナからホストのディレクトリにアクセスできるようにする
Dockerを使う際，ふつうコンテナの中でソースを書いたりすることはありません。ホスト側で作ったソースコードをDockerコンテナ上から実行したいと思うはずです。
そのような場合，ホストのディレクトリをコンテナ内にマウント(=対応付け)することができます。
ホストの./src/appをコンテナ内の/go/src/appにマウントします。
$ docker run -d -it --name golang_container -v $(pwd)/src/app:/go/src/app golang b303f3e4eb06db65242bafb1e746f90d187c354b8eb3597776011b36486057e1
このコマンドでは，新しく-vフラグが出てきました。
直後の引数に[ホスト側の絶対パス]:[コンテナ側の絶対パス]と指定することで，ふたつのディレクトリを結びつけることができます。
$(pwd)と書いたところには，カレントディレクトリの絶対パスが出力されます。
実際に以下のようなファイルをホストのsrc/app下に置いておきます。
package main
import (
"fmt"
)
func main() {
fmt.Println("Hello, golang from docker!")
}
このソースをコンテナ上で実行してみます。
$ docker exec -it golang_container /bin/bash root@b303f3e4eb06:/go# go run src/app/hello.go Hello, golang from docker!
正しくコンテナ上からホスト側のディレクトリに存在するファイルを読み込み，実行できました！
まとめ
- golangのイメージからコンテナを作成しホストで作成したプログラムを実行できた
気が向いたらっていうか勉強したらDockerfileの話とかdocker-composeの話とか書きます。
