Nexus5XにAndroidOを手動インストールした手順
先日GoogleがAndroidOの開発者プレビューを公開しました。
会社での検証が必要だったので、手動インストールをしてみました。
そもそも普段からiPhoneユーザーだしAndroidを使ったことも無いので、とにかく調べながらの実践だったので、最終的に何が正解だったのかわかりませんでした。
しかし、どうにかアップデートできたので備忘録として記しておきます。
端末
- Nexus5X(Android7.1.2)
- MacBookAir 13-inch, Early 2015(10.11.6 OSX El Capitan)
AndroidStudio AndroidSDKのインストール
何やらAndroidを手動でインストールするためには、AndroidSDKが必要で、adb
?とか言うコマンドで実施するとのこと。
AndroidStudioは必要ではないっぽいけど、後々アプリ開発もするかもしれなかったのでAndroidStudio経由でAndroidSDKをDLしました。
HomebrewにてAndroidStudioをインストール
$ brew cask install android-studio
インストールされたAndroidStudioを初回起動すると、AndroidSDKをインストールするかを聞かれるので、適当にダウンロードします。 (この辺りはどうやったか詳細を忘れました。)
するとSDKがDLされます。多分デフォルトだと大体同じかと思われます。 (自分の環境だと```$HOME/Library/Android/sdk/)にインストールされました。
このsdkフォルダ以下のplatform-toolsへのパスを通します。
$ echo "export PATH=$PATH:$HOME/Library/Android/sdk/platform-tools" >> ~/.bash_profile $ source ~/.bash_profile
これでadb
などのコマンドが使えるようになります。
Nexus5Xを開発者モードにしUSBデバッグをオンにする
以下を参考に実施。
Android端末を「デバッグモード」(USBデバッグ)に設定する
システムイメージのダウンロード
以下より、端末に合ったファイルをダウンロードします。
Android O のダウンロード | Android Developers
Nexus5Xの場合はbullhead-opp1.170223.012-factory-338a95b1.zip
というファイルで1.5Gバイトほどのサイズでした。
リカバリーモードを起動
ここからは以下を参考に実施。
Nexus端末を手動でAndroid5.0にアップデート | うめの記録帳
端末を「adb sideload」を使って手動で即座にアップデートする方法
NEXUSデバイスをSDK、adb sideloadを利用して最新ビルドのAndroidOSに手動で強制的にアップデートする方法
Nexus5Xの電源を切り、ボリュームダウンボタンを押し続けながら電源ボタン長押しで起動すると、以下のようにファストブートモードの画面になります。
ボリュームボタンのアップとダウンで選択が出来るので、リカバリーモードに合わせ、電源ボタンで選択します。すると以下のような画面になります。
電源ボタンを押しながらボリュームアップボタンを押してリカバリーメニューを表示します。
ボリュームボタン上下で、Apply update from ADB
を選択すると、以下のような画面になります。
ここからがPC側の作業で、ターミナルを起動し、先程ダウンロードしてきたシステムファイルbullhead-opp1.170223.012-factory-338a95b1.zip
があるディレクトリに移動します。
ここで、以下コマンドを実行します。
$ adb sideload bullhead-opp1.170223.012-factory-338a95b1.zip
これでアップデート出来るはずだと思っていたが、以下のようなメッセージが出て終わってしまった。
loading: 'bullhead-opp1.170223.012-factory-338a95b1.zip'... connecting... Total xfer: 0.00x
Nexus5X側では以下のようなエラーメッセージが。。。
次に、以下のページを参考に、別のやり方を試してみた。
Android 6.0 Marshmallowを手動アップデート/インストールする方法
何やら、oem unlock
というのが必要らしい。
以下を参考に実施。
Nexus5X/Nexus6Pのブートローダーアンロック方法・手順。
Nexus5Xの設定→開発者向けオプション→OEMロック解除を有効にする
再度Nexus5Xでファストブートモードを起動し、PCに接続します。 ターミナルより、以下コマンドを実行します。
$ fastboot oem unlock
すると以下のようにロックを解除しても良いか聞かれるので、ボリュームボタンでYesを選択し、電源ボタンで決定します。
その後しばらくすると再起動し、端末が初期化されます。
再度ファストブートモードを起動すると、下部のDEVICE STATEがunlockedになりました。
PC側で、bullhead-opp1.170223.012-factory-338a95b1.zip
を解凍して出来たディレクトリの中に移動し、中にある./flash-all.sh
を実行する。
$ cd bullhead-opp1.170223.012 $ ./flash-all.sh
Nexus5X側では以下のようにdownloadingという文字が表示され、正常に進行していることが分かります。
これにて無事アップデートが完了しました。
参考
想像力がないことについて
だいぶ前の記事だがこれを読みました。あまりに自分と同じだったので「オレのことか?」と思いびっくりしました。 ただ自分は、小さい頃特にゲームばかりをやっていたわけでもなく、そこまで多い方とまでは言えないがそれなりに読書は好きだったので本も読んでいました。 なので、ゲームをやりすぎたことが想像力がない原因と結論付けることに違和感を感じました。 そこで、今回は想像力がないことの原因について考えてみました。
想像力がないことは悪いことだけではないのでは?
まず前提として、自分は想像力がないという自覚があるが、それは純粋に想像することができないという意味ではなく、想像する力を常日頃から働かせる力がない、つまり想像する習慣がないという状態だという認識です。 何が言いたいかというと、自分の場合は想像しようと思えばできると思っている、ということ。(それが本当にそうかは別として)
では、なぜできないか?
それは結局そういう習慣がないから、ということに尽きるが、習慣がないのはないなりの理由があると考えます。 理由としては、想像する必要がないような何かがあったから想像しなかった、ということが考えられます。 想像力がないということは、捉え方を変えれば既知の情報を用いて効率的に大枠を捉えているとも言えます。 想像力がないのは、ゼロから情景を構築しないで済むように、既知の景色で補完しているということなのではないでしょうか。
でもそれはつまり先入観をもって物事を捉えているだけにすぎない
既知の情報を元に目の前の事象に触れている。つまり、想像力がない=先入観、バイアスを持って物事を捉えること 複眼的思考法では、冒頭部分でこのバイアスを持って物事を捉えることの意味と、危険性について論じています。
知的複眼思考法 誰でも持っている創造力のスイッチ (講談社+α文庫)
- 作者: 苅谷剛彦
- 出版社/メーカー: 講談社
- 発売日: 2002/05/20
- メディア: 文庫
- 購入: 64人 クリック: 567回
- この商品を含むブログ (213件) を見る
先入観をもって物事を捉えるのは効率的で、素早い判断をするには役に立つ。 この説明には納得がいきます。 自分も想像力はないが、本を読むのは早い方でした。
しかし、やはりこれだと細い部分は抜け落ちてしまう。
入社してすぐのときに、かんたんな開発の案件に参画しました。 要件が定まらない中でも大枠を捉えてプロトタイプをどんどん作って開発を進めたことで、比較的スムーズに開発をすすめることができました。 しかし最終局面になったときに、使用するライブラリのクリティカルな仕様を読み落としていることに気づき、大変な目にあいました。 (幸い開発量としては大きい案件ではなかったので休日出勤をすることで解決できたが。。) 多分これも、自分の上記のような性質によるものだと思います。 一部の情報と自分の先入観から大枠を構築するので、確かに行動のスピードは早くはなるが、細かい部分を見落としがちになってしまう、ということなのかもしれません。
まとめ。
想像力がないことは、先入観を持って物事を見ていることと一緒
先入観を持つことで素早い判断ができるようになるが、それでは本質を見落としかねない
自分が得た情報をしっかり検証し、そこから考えを構築することが大切
結局ぼんやりと考えていることを書いただけになってしまったので、次はこうした症状を持っている場合にどうしたら治すことができるのか、といった方法論に落とし込みたいと思います。
Nginxとffmpegで映像プレイヤーの検証環境を構築(RTMP、HLS)
背景
FlowPlayerを仕事で使うことになり、デザインの変更やFlash Failbackの検証などを行うための軽量な環境が欲しかった。
やりたいこと
- 映像ソースを送る側と、それを配信するサーバーをローカル環境上に立ち上げたい(LIVE配信で!!)
- 同一LANの他の端末から接続できるようにしたい
- RTMPとHLSどちらも検証したい
- コマンドひとつで環境を立ち上げたい!
構成
そこで以下のような構成を作ることにしました。
コンテナ1の作成(Web、配信サーバ)
要件
- Webサーバの機能を持つこと
- RTMPサーバの機能を持つこと
- HLSのセグメント化もできること
設定ファイル
nginxのRTMPモジュールを使えば、nginxだけで上記の機能のすべてを賄えるとのこと。
インストール方法はこちらを参照。
これをベースにDockerfileを作成します。
FROM centos:latest RUN yum update -y && \ yum -y install gcc pcre-devel openssl openssl-devel wget unzip tar git make && \ useradd --shell /sbin/nologin nginx && \ wget http://nginx.org/download/nginx-1.10.2.tar.gz && \ tar -zxvf nginx-1.10.2.tar.gz && \ wget https://github.com/arut/nginx-rtmp-module/archive/master.zip && \ unzip master && \ cd nginx-1.10.2 && \ ./configure \ --user=www-data \ --group=www-data \ --with-http_ssl_module \ --with-http_realip_module \ --add-module=../nginx-rtmp-module-master && \ make && \ make install COPY ./nginx.conf /usr/local/nginx/conf/nginx.conf WORKDIR /usr/local/nginx/html EXPOSE 80 1935 ENTRYPOINT ["/usr/local/nginx/sbin/nginx", "-g", "daemon off;", "-c", "/usr/local/nginx/conf/nginx.conf"]
RTMPサーバの設定については、以下の記述をnginx.conf
に追記すればOKのようです。
参考:nginx-rtmp-module/wiki
rtmp { server { listen 1935; application live { live on; wait_video on; exec ffmpeg -i rtmp://localhost/live/$name -c:a libfdk_aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost/hls/$name_low -c:a libfdk_aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost/hls/$name_mid -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost/hls/$name_hi; } application hls { live on; hls on; hls_path /usr/local/nginx/html/hls; hls_nested on; hls_fragment 5s; hls_variant _low BANDWIDTH=160000; hls_variant _mid BANDWIDTH=320000; hls_variant _hi BANDWIDTH=640000; } } }
まずrtmp://{IPアドレス}/live/{ストリーム名}
にストリームを送ると、
それを受け取ったあと、
exec ffmpeg -i rtmp://localhost/live/$name -c:a libfdk_aac -b:a 32k -c:v libx264 -b:v 128K -f flv rtmp://localhost/hls/$name_low -c:a libfdk_aac -b:a 64k -c:v libx264 -b:v 256k -f flv rtmp://localhost/hls/$name_mid -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv rtmp://localhost/hls/$name_hi;
上記が実行されrtmp://localhost/hls/$name_low
、rtmp://localhost/hls/$name_mid
、rtmp://localhost/hls/$name_hi
の3ストリームに更に流されるという仕組みのようです。
そして、下記の部分でHLSについての設定が記述してあるので、ここでセグメント化がされるという流れみたいです。
application hls { live on; hls on; hls_path /usr/local/nginx/html/hls; hls_nested on; hls_fragment 5s; hls_variant _low BANDWIDTH=160000; hls_variant _mid BANDWIDTH=320000; hls_variant _hi BANDWIDTH=640000; }
しかし、自分の環境ではこのHLS化の部分がうまく動作してくれなかったので、nginxでストリームを受け取ってからHLSに流すのではなく、最初から映像ソースを送信するffmpeg側でRTMP+HLS×3の4ストリーム流すことで対応しました。
最終的に、nginx.conf
は以下のようになりました。
user nginx nginx; worker_processes 1; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; sendfile on; keepalive_timeout 65; server { listen 80; server_name localhost; location / { root /usr/local/nginx/html; index index.html index.htm; expires -1; sendfile off; } location /hls { types { application/vnd.apple.mpegurl m3u8; } root /usr/local/nginx/html; add_header Cache-Control no-cache; # To avoid issues with cross-domain HTTP requests (e.g. during development) add_header Access-Control-Allow-Origin *; } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } include servers/*; } rtmp { server { listen 1935; application live { live on; wait_video on; } application hls { live on; hls on; hls_path /usr/local/nginx/html/hls; hls_nested on; hls_fragment 5s; hls_variant _low BANDWIDTH=160000; hls_variant _mid BANDWIDTH=320000; hls_variant _hi BANDWIDTH=640000; } } }
参考
コンテナ2の作成(映像ソース)
要件
このあたり↓を参考に設定させていただきました。
テスト用の自動配信環境をDockerとFFmpegで構築してみる
というかDockerfile
に関しては全く同じです(汗)。
FROM jrottenberg/ffmpeg:3.2-centos COPY source.mp4 ./ COPY start.sh ./ COPY ./ffserver.conf /etc/ffserver.conf EXPOSE 80 1935 ENTRYPOINT bash start.sh
ただし、前述のようにffmpeg側で4ストリーム流す必要があったので、実行するシェルスクリプトを以下のように書き換えました。
#!/bin/bash ffmpeg -re -stream_loop -1 -i 'source.mp4' -acodec libfdk_aac -vcodec libx264 -f flv "${TARGET_RTMP_IP}/live/{設定したストリーム名}" \ -c:a libfdk_aac -b:a 32k -c:v libx264 -b:v 128K -f flv "${TARGET_RTMP_IP}/hls/{設定したストリーム名}_low" \ -c:a libfdk_aac -b:a 64k -c:v libx264 -b:v 256k -f flv "${TARGET_RTMP_IP}/hls/{設定したストリーム名}_mid" \ -c:a libfdk_aac -b:a 128k -c:v libx264 -b:v 512K -f flv "${TARGET_RTMP_IP}/hls/{設定したストリーム名}_hi"
この状態でDockerコンテナを立ち上げれば映像ソースを以下の4つに対して延々と配信してくれるはずです。
${TARGET_RTMP_IP}/live/{設定したストリーム名} ${TARGET_RTMP_IP}/hls/{設定したストリーム名}_low ${TARGET_RTMP_IP}/hls/{設定したストリーム名}_mid ${TARGET_RTMP_IP}/hls/{設定したストリーム名}_hi
docker-composeでの立ち上げ
ffmpeg(コンテナ2)からnginx(コンテナ1)に映像ストリームを送る際にはコンテナ間通信となるため、コンテナをリンクさせる必要がある(??Dockerまだあまり詳しくないので多分です。。。)ので、docker-composeを使ってコンテナをリンクさせて立ち上げるようにします。
結果的に以下のようなdocker-compose.yml
となりました。
version: '2' services: nginx: build: context: ./ dockerfile: ./Dockerfile_nginx container_name: nginx ports: - "80:80" - "1935:1935" volumes: - ./:/usr/local/nginx/html ffmpeg: build: context: ./ dockerfile: ./Dockerfile_ffmpeg container_name: ffmpeg environment: - TARGET_RTMP_IP=rtmp://{Dockerが動作するゲストOSのIPアドレス}:1935 links: - nginx
TARGET_RTMP_IP
として映像ソースの送信先を環境変数として渡しています。
コンテナ2で記述したシェルスクリプトがこの宛先に向けて映像を送ります。
{Dockerが動作するゲストOSのIPアドレス}
については、ゲストOSのIPアドレスなので、次項で設定するVagrant上のCentOSのIPアドレスを記載します。
参考
ゲストOSの立ち上げ
要件
- LAN内の外部端末から接続できるような基盤とすること
- 立ち上げる際にDockerも自動で実行できること
ここまでで、メインの機能となるDockerコンテナは作成できました。 そしていよいよそのDockerの土台となるゲストOSを立ち上げてきます。
Dockerのコンテナに別の端末から接続する際には、そのDockerが動作しているOSのIPアドレスを指定すれば可能なようです。 Docker の基本学習 ~ コンテナ間のリンク
また、Vagrantで立ち上げる仮想OSも以下の記述を加えるだけで簡単に外部からのアクセスが可能になるようです。
config.vm.network "public_network", :ip => "{IPアドレス}" , :bridge => "en0: Wi-Fi (AirPort)"
[Vagrant] LAN内の別マシンから仮想マシンにアクセスする
よって、Vagrantで立ち上げるOSに上記の設定を加えれば、その上で動作しているDockerコンテナのサーバにも外部から接続ができるようになるということです。
更に、Vagrantで仮想OSを立ち上げる際に、同時にDocker、docker-composeも実行したいです。
dockerをVagrantのprovisionerとして使う方法は公式に記述してあります。 DOCKER PROVISIONER
また、docker-composeをprovisionerとして使うためのプラグインもあり、
$ vagrant plugin install vagrant-docker-compose
でインストールできるようです。 leighmcculloch/vagrant-docker-compose
設定
結果的に以下のようなVagrantfileになりました。
Vagrant.configure("2") do |config| config.vm.box = "bento/centos-7.2" # LAN内部に公開するため、public_networkを選択 # IPアドレスはホストOSと同じセグメントのIPアドレスでないと接続できない config.vm.network "public_network", :ip => "192.168.0.100" , :bridge => "en0: Wi-Fi (AirPort)" config.vm.synced_folder "./", "/vagrant", type: "virtualbox" # provisionerとしてdockerとdocker-composeが使えるようにする # 起動のたびにコンテナを起動 config.vm.provision :docker config.vm.provision :docker_compose, yml: "/vagrant/docker-compose.yml", run: "always" end
参考
- Docker の基本学習 ~ コンテナ間のリンク
- [Vagrant] LAN内の別マシンから仮想マシンにアクセスする
- DOCKER PROVISIONER
- leighmcculloch/vagrant-docker-compose
プレイヤーを作る
今回はFlowPlayerの検証のために環境を作ることが目的だったので、FlowPlayerのセットアップ方法に従いindexhtml
を作成しました。
まずは、flowplayerのライブラリを読み込みます。
<head> <!-- flow player --> <link rel="stylesheet" href="//releases.flowplayer.org/6.0.5/skin/minimalist.css"> <script src="//code.jquery.com/jquery-1.12.4.min.js"></script> <script src="//releases.flowplayer.org/6.0.5/flowplayer.min.js"></script>
今回はFlowPlayer上でHLSも使いたいので、hls.jsも読み込みます。
<!-- load the Flowplayer hlsjs engine, including hls.js --> <script src="//releases.flowplayer.org/hlsjs/flowplayer.hlsjs.min.js"></script> <!-- optional: the quality selector plugin for quality selection when hlsjs is not supported --> <script src="//releases.flowplayer.org/quality-selector/flowplayer.quality-selector.min.js"></script> </head>
プレイヤーを作成するには、<div>
要素に対して、jsでソースを指定します。
RTMPは下記のように指定。
var rtmp_player_flv = document.getElementById("rtmp_player_flv"); flowplayer(rtmp_player_flv, { autoplay : true, clip: { sources: [ { type: "video/flash", rtmpt : false, src: "rtmp://{配信サーバのIPアドレス}:1935/live/mdst" }, ] } });
HLSは下記のように指定。
var hls_player = document.getElementById("hls_player"); flowplayer(hls_player,{ autoplay : true, live : true, clip: { sources: [ { type: "application/x-mpegurl", src: "http://{配信サーバのIPアドレス}/hls/mdst.m3u8" }, ] }, });
最終的にindex.html
は以下のような形になりました。
<!DOCTYPE html> <html lang="en" class=""> <head> <!-- flow player --> <link rel="stylesheet" href="//releases.flowplayer.org/6.0.5/skin/minimalist.css"> <script src="//code.jquery.com/jquery-1.12.4.min.js"></script> <script src="//releases.flowplayer.org/6.0.5/flowplayer.min.js"></script> <!-- load the Flowplayer hlsjs engine, including hls.js --> <script src="//releases.flowplayer.org/hlsjs/flowplayer.hlsjs.min.js"></script> <!-- optional: the quality selector plugin for quality selection when hlsjs is not supported --> <script src="//releases.flowplayer.org/quality-selector/flowplayer.quality-selector.min.js"></script> </head> <body> <div> <h2>RTMP</h2> <div id="rtmp_player_flv"></div> </div> <div> <h2>HTTP Live Streaming</h2> <div id="hls_player"></div> </div> <p id="vinfo" class="info"> </p> <script type="text/javascript"> flowplayer(function (api) { api.on("load", function (e, api, video) { $("#vinfo").text(api.engine.engineName + " engine playing " + video.type); }); }); var rtmp_player_flv = document.getElementById("rtmp_player_flv"); flowplayer(rtmp_player_flv, { autoplay : true, clip: { sources: [ { type: "video/flash", rtmpt : false, src: "rtmp://{配信サーバのIPアドレス}:1935/live/mdst" }, ] } }); var hls_player = document.getElementById("hls_player"); flowplayer(hls_player,{ autoplay : true, live : true, clip: { sources: [ { type: "application/x-mpegurl", src: "http://{配信サーバのIPアドレス}/hls/mdst.m3u8" }, ] }, }); </script> </body> </html>
起動
起動する際は、Vagrantfile
があるディレクトリで下記のコマンドを実行します。
$ vagrant plugin install vagrant-docker-compose $ vagrant up
まとめ
これにて、コマンド一つ(実際には2つ)で動画配信と視聴の環境を構築することができました。
あとはindex.html
を修正することで様々なプレイヤーの検証を行うことができます。
応用情報技術者に2週間で合格できた背景と方法
先日12月16日に合格発表があり、無事合格していました。
8月に試験を申し込んだあと、そのことを忘れていたので試験勉強を始めたのは10月に入ってからでした。。。。
実質2週間程度しか勉強時間はなかったのですが、なんとか合格することができました。
今回はその経緯と勉強方法について書きたいと思います。
なぜ応用情報技術者試験を受験したか
理由としては以下の3つです。
- 昨年、基本情報技術者試験を受験してから一年が経っていたため、次の資格を取得したかった
- 通信系の会社にいるが、情報系の学部を卒業していないので、体系的に学ぶために資格勉強を活用したかった
- 来年にでもネットワークスペシャリストを取得したいが、その前段階として応用を取得しておきたかった
午前 | 午後 | |
---|---|---|
出題形式 | 多肢選択式(四肢択一) | 記述式 |
出題数 解答数 |
出題数:80問 解答数:80問 |
出題数:11問 解答数:5問 |
合格基準は午前試験、午後試験でそれぞれ60点/100点を取得することです。
午前試験で60点が取得できていない場合、午後試験については採点すらも行われません。
試験範囲としては、以下の範囲が出題されます。
- 基礎理論
- アルゴリズムとプログラミング
- コンピュータ構成要素
- システム構成要素
- ソフトウェア
- ハードウェア
- ヒューマンインターフェース
- マルチメディア
- データベース
- ネットワーク
- セキュリティ
- システム開発技術
- ソフトウェア開発管理技術
- プロジェクトマネジメント
- サービスマネジメント
- システム監査
- システム戦略
- システム企画
- 経営戦略マネジメント
- 技術戦略マネジメント
- ビジネスインダストリ
- 企業活動
- 法務
特に16以降なんかは、正直なんか別の人が考えてよ・・・と言いたくなってしまう気がします。。。
とはいえ、応用情報技術者資格を持つ人材に対して期待されていることは、
基本戦略立案又はITソリューション・製品・サービスを実現する業務に従事し、独力で次のいずれかの役割を果たす。(1) 需要者(企業経営、社会システム)が直面する課題に対して、情報技術を活用した戦略を立案する。(2) システムの設計・開発を行い、又は汎用製品の最適組合せ(インテグレーション)によって、信頼性・生産性の高いシステムを構築する。また、その安定的な運用サービスを実現する。
もちろん、これらの範囲を専門家並に理解しなくても問題ないのでご安心ください。
自分のもともとの学習レベル
先に、「学習時間が2週間程度しかなかった」と書いたのですが、もちろん完全にゼロからのスタートで2週間で合格したわけではありません。
- 仕事でもある程度ネットワークの設計などを行っている
- 学生時代にプログラマとしてのバイト経験があり、また趣味でもプログラムを多少書く
- 直前にドットコムマスター を受験して合格していた
- 基本情報技術者を一年前に取得
- プログラム、データベース、ネットワーク周りはある程度理解している。
- 法律的な部分であったり、CPUの構成がなんたらとかという部分は、一度ある程度勉強したことがある
勉強方法
前述のような状態からのスタート、時間も限られていたのでひたすら過去問を解くという戦略を取りました。
午後試験は4問選択だったので、プログラミング、データベース、ネットワークを選択すればまぁ解けるだろうという甘い考えでした。
それ以上に、午前試験で60点以上を取得しないと無条件で不合格になってしまうので、そちらの対策に全力を注いだわけです。
毎日こちら↓のサイトを使って過去問を解き、5年分は解きました。
応用情報技術者試験ドットコム
また、下記の本も購入しわからないことは調べて、理解を深めました。
まぁ、一応本は買いましたが、正直使用頻度も少なかったですし、買わなくても大丈夫だったと思います。
こうしてひたすら過去問を解いたことで、概ね出題されるパターンも分かってきて、よく出る知識については効率よく覚えることができました。
午後試験の選択問題もすんなりと解くことができ、無事合格することができました。
まとめ
応用情報技術者試験は上述の通り、試験範囲も広いですし、午後試験も基本情報技術者試験に比べ記述式の分量が多く、とても大変な試験に見えるかもしれませんが、受けてみるとさらっと合格することができました。
その要因としてはやはり、ある程度技術的な知識を持っていたということが大きいと思います。
そういう意味では、もともと技術職の方であったり、そういった勉強をしている方なら、とてもかんたんに取ることができる資格なので、範囲の広さに怯える必要は無いと思います。
逆に技術にあまり詳しくない方は、午前試験に加えて午後試験の記述対策もしっかりと行う必要があるので、結構たいへんかもしれません。
ブログタイトル変えました
今ではもう社会人にもなり、結婚もし、子供も居るので、改めてブログをやろうと思って変えました。
社会人になって
大学では、学部は宇宙系、大学院では土木を専攻していましたが、会社は通信会社に就職しました!
今ではNE(ネットワークエンジニア)としてお仕事をしています。
プログラミングも好きなので、趣味でソフトウェア開発もしています。
まだまだネットワークもソフトウェアも学ぶことが多そうです。
このブログ
今後はこのブログでは普段の日常とかで考えたことだったり、技術的な事を書いていきたいと思います。
またすぐ更新しなくなるかもしれませんが、頑張っていきます!
vagrant 上のCentOSにSymfonyをインストール
下記↓を参考にしながら実行。
Symfony のインストールと設定 | Symfony2日本語ドキュメント
まず、
curl -s https://getcomposer.org/installer | php
を実行すると、
#!/usr/bin/env php
All settings correct for using Composer
Downloading...
というメッセージが返ってきて無事入れられたようです。
次に、
php composer.phar create-project symfony/framework-standard-edition /path/to/webroot/Symfony 2.7.0
というコマンドを実行。
すると、しばらくの後、
というエラーメッセージが、、、、
どうしようどうしよう、、、なんか権限がないらしいけど、こういうのイジるの怖い、、、
と、思ったら、単純にパスを指定していなかっただけっぽい。笑
普通に/path/to/webroot/のままやってた。
じゃぁここを変更しよう、と思ったはいいが、
rootディレクトリの場所がわからない、、、、、
確か仮想環境のフォルダとlocalのフォルダを共有するのにどこだかをいじった気がする、、、、
と思って調べたら/var/www/htmlがrootであるということが分かりました。
そこで、ここをrootパスとして再度
php composer.phar create-project symfony/framework-standard-edition /var/www/html/Symfony 2.7.0
を実行。
すると、無事ダウンロードが始まり、うまく進みました。
そしたら、最後の最後で下記のエラーメッセージが!!!!!
Fatal errorが出てしまった、、、、
何やらphp-xmlとか言うのがないとのこと(何だそれ?)
と言うわけで、以下のページを参考にしてインストール。
PHP Fatal error: Class ‘DOMDocument’ not found in … - Techie Corner
sudo yum install php-xml
を実行。
そしたらまたエラー、、、、
もうイヤだ、、、、
もうなんなのさ。。。と思いながらまた調べてみると、この記事を発見↓。
kuma memo: Symfony2をComposerでインストール
どうやらPHPをインストールした際の方法と違うから同じ方法じゃないとphp-xmlをインストールすることも出来ないらしい(?よく分からん)
ひとまず下記コマンドを実行。
sudo yum install --enablerepo=remi php-xml
すると、うまく進み完了したようです。
OSX - yosemiteにアップデートしてhosterが起動しなくなった
まぁ今回はちょっとしたことだけど。
初心者なので逐一備忘録としてとっておきます。
内容としては掲題の通り。
アップデートしたのは結構前だけど、Hosterを起動したのが相当久しぶりなので気が付かなかった。。。
yosemiteにアップロードしたからなんか再インストールしなきゃならないっぽい?ので、一端アプリを削除。一個しか登録してなかったしね。
そしたら以下の記事を発見
OSX - yosemiteにアップデートしてhosterが立ち上がらなくなった時の解決方法 - Qiita
復活出来たんか。。。。。
そっちにすればよかった。。。
まぁしょうがないので、以下の記事を参考に再インストール。
Mac - OS X 10.10 Yosemite に Hoster がインストールできない場合の対処法 - Qiita
記事を書くほどではないとか言わないでください。
自分にとってはこんなんでも大変なことなんです、、、、
サイドインストールしたら無事動きました。