1日でAWSソリューションアーキテクト アソシエイトを取得
先日（2019/03/25）、
AWS認定ソリューションアーキテクト アソシエイトを取得しました。
業務でなかなかに忙しく、前日夕方に勉強を本格的に始めて、
なんとか合格できたので、試験準備（前提知識、勉強方法の順に）を紹介します。
※どやってますがほぼ徹夜なので、オススメはしません。
参考に見ていただければと思います。
まずは一応、エビデンスを。
受験スコアは1000点中726点（ラインは720点）なので、
めちゃくちゃギリギリです。
ではでは紹介を。
■前提知識
一応、業務やプライベートでちょこちょこAWSは触ってました。
なので、AWSが全く分からないというわけではなかったです。
触ったことのある機能、操作はこんな感じ。
＜業務＞
- スナップショットの取得、ボリューム復元（デタッチ、アタッチ）
- リザーブドインスタンスの費用確認、購入
- CloudWatchでのメトリクス作成、確認
- インスタンスタイプ変更
- ボリュームサイズ変更
- ボリューム追加
- AMI取得、リカバリ
- ECS操作、設定変更
＜プライベート＞
等々
上記の通りなので、EC2やECS周りの操作ぐらいの経験や
AWSってこういうものだよねというザックリとした全体知識があるくらいでした。
■勉強方法
それでは勉強方法を。
こんな流れで1日消化（約10時間くらい？）しました。
- 青本を読む（20ページくらいでやめる）
- 黒本を熟読（本格的に受験対策）
- 黒本の過去問を解き始める
1.青本を読む（20ページくらいでやめる）
はじめの20ページくらいまでは見ていて、
前日の段階でこのままこれを読むメリットがないと判断（遅い）
※読まない判断要素
・AWSの知識本として古い
・AWSの試験体系が変わった
・これを読んでいる時間が残ってない（黒本は読む予定だった）
合格対策 AWS認定ソリューションアーキテクト ?アソシエイト
- 作者: 大塚康徳
- 出版社/メーカー: リックテレコム
- 発売日: 2016/10/14
- メディア: Kindle版
- この商品を含むブログを見る
2.黒本を熟読（本格的に受験対策）
青本をやめてから黒本に移行。
黒本を読んで→過去問受けて→模擬試験を受けるという流れをイメージして着手。
ここから本格的に熟読。
各章別の問題は完全にスルーして進める。
時間的にも1周しかできないと判断して、みっちり読む。
⇒言葉の節々の意味合いとか、どういう根拠でこれが使えるか認識する
各機能（GlacierやRedshiftとか）の特徴も押さえる
※読み始めは18、19時頃
徹底攻略 AWS認定 ソリューションアーキテクト ? アソシエイト教科書
- 作者: ??部昭寛,宮?光平,菖蒲淳司,株式会社ソキウス・ジャパン
- 出版社/メーカー: インプレス
- 発売日: 2019/01/18
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
↓の赤本？もあったが特に根拠のない「黒本なら安心」で進める
赤本のほうがリリース日が2019年3月時点で新しいほうなので、
本当は赤本が良かったかもしれない。
（図は赤本のほうが多かった印象）
最短突破 AWS認定ソリューションアーキテクト アソシエイト 合格教本
- 作者: 村主壮悟
- 出版社/メーカー: 技術評論社
- 発売日: 2019/02/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
3.黒本の過去問を解き始める
途中、集中力が途切れてダラダラも交えつつ、
朝方6時頃に読み終える。
（途中、本当にわかっているのか不安になってサンプル問題解いてみたり、問題の傾向は確認）
※自分は本をガッツリ読み込み吸収派なので、スピードは一般の人より遅いかもです。
問題は正答率を上げるように見開き（約5～10問ほど）毎に解く→解答確認を
繰り返しました。
間違えたところは解説を読み、わかりにくいところは対象の章に戻り、
欠けた知識を補填するの流れで取り組む。
30～40問くらいまで解いたころでタイムアップ！
試験会場に向かう。
受付を終えて、試験直前は準備が万全とは言えなかったので、
めちゃくちゃ緊張しました。
なので、問題集読んでも頭はいらないなと切り捨て、
「問題文をしっかり読む、何を聞かれているかの読解を第1とする」
と作戦？を頭の中で整理して挑みました。
（試験中はまずは冷静になる為に、すんなり回答できる問題以外はすっ飛ばして進める！）
傾向的には「構築でコスパ（セキュリティ）が良いのはどれ」が多い印象です。
VPCの中にサブネット（プライベート、パブリック）があって、そこにEC2インスタンスがあると何を使って外部につなげるのが良いとかとか。
ちなみに自分はインフラ屋ではなく、アプリ屋なので、
このへんの細かいのは概念として頭の中でイメージできるくらいです。
以上！
正直、合格率を安定して上げるなら勉強時間は20時間の目安で、
- 参考書（黒本や赤本）を1冊熟読する
- 過去問を解く
- 模擬試験受ける
- （苦手分野は実際に触ってみる）
の流れが適切だなぁと感じてます。
【追記】
ソリューションアーキテクト アソシエイトの下位資格にはなりますが、
料金系（どれに費用かかるかからない、どのくらいかかる）とかを
業務的に知ってると助かるなと思い、受験しました。
こっちは参考書もなく、半日ほどしか勉強時間を作れなかった（おい！）ので、
・模擬試験で苦手分野を押さえる
・全体的な知識は黒本でさらっとおさらい
の流れで受けました。
本番環境DBと検証環境DBのデータexport,import
タイトル通りデータのexport,importについて。
本番環境DBからexportし、検証環境DBへimportした作業を記載していきます。
まずは各環境、
DBはOracle
OSはLinux
です。
Oracleにはデータのexport,importに2種類ありますが、
ここではData Pumpを用いた方法になります。
まず、Data Pumpを行う場合、
ディレクトリ・オブジェクトの作成
と
権限の付与
が必要です。
まずData Pumpの概念として理解する必要があります。
Data Pumpは標準のexport,importに比べて、高速に作動します。
これはなぜかというと、
Data PumpはOracle Database内に実行エンジンをもっているからです。
※そりゃあDB自身にエンジンをもって作動を働きかけたほうが早い。
そしてなぜディレクトリ・オブジェクトなんてものが必要なのか…
データをexportする場合、dmpファイルを作成します。
DB自身に働きかけるということは、
DB自身がdmpファイルを作成します。
つまり、dmpファイルを作成するためにDB自身にディレクトリ情報を保持してもらわなければなりません。
そして、
exportしたいデータのユーザーにそのディレクトリ・オブジェクトへの権限を付与しなければなりません。
ディレクトリ・オブジェクト一覧の確認sql(もちろんしかるべき権限のユーザーで)
SELECT * FROM ALL_DIRECTORIES;
SELECT directory_name, directory_path FROM ALL_DIRECTORIES;
ディレクトリ・オブジェクトの作成sql(作成権限のあるユーザーで)
CREATE OR REPLACE directory ディレクトリ・オブジェクト名 as '対象のパス';
権限の付与sql(権限付与できるユーザーで)
GRANT READ, WRITE ON directory ディレクトリ・オブジェクト名 to 権限付与するユーザー名;
もろもろ設定後、
sqlplusをせずにコマンド実行します。
export文(サンプル)
expdp ユーザー名/パスワード directory=ディレクトリ・オブジェクト名 dumpfile=ダンプファイル名.dmp
※テーブル名指定オプション tables=テーブル名
※exportデータタイプ指定オプション(例はデータのみ) content=data_only
※ダンプファイル名指定オプション dumpfile=ダンプファイル名.dmp
他のオプションはいろいろ参照してみてください。
ちなみにダンプファイル名を指定しなかった場合、ダンプファイル名は
【EXPDAT.DMP】になります。(windowsでの実行確認)
また、事前作成済みのダンプファイルと同名のダンプファイルを指定して実行した場合、
ORA-39001: 引数値が無効です
ORA-39000: ダンプ・ファイル指定が無効です
ORA-31641: ダンプ・ファイル"/work\sample.dmp"を作成できません
ORA-27038: 作成したファイルはすでに存在します
OSD-04010: <create>オプションが指定されましたが、ファイルはすでに存在します
と作成はできません。
では次にimportです。
exportしたユーザーと同ユーザーでimportする場合は問題なく、以下の通り、
import文
impdp ユーザー名/パスワード directory=ディレクトリ・オブジェクト名 dumpfile=ダンプファイル名.dmp
しかし、タイトルにあるような違うユーザーの持っている同名テーブルにimportする場合、
リマッピングをする必要があります。
以下が、
データexportユーザー名：A、データimportユーザー名：B
とした場合のsqlです。
impdp ユーザー名/パスワード directory=ディレクトリ・オブジェクト名 dumpfile=ダンプファイル名.dmp remap_schema=Aユーザー名:Bユーザー名
以上！
こんな感じでやります。
コーディング方針
今週も終わって、明日からまた仕事ですよ。。
みなさん、お疲れ様です！
そして私は明日、明後日でリリース作業です。
というか現在、私はプロジェクトを２つ抱えてます。
そんでもってさらに追加で３つ目のプロジェクトの引き継ぎ中です。
そして、年明けには４つ目が来るんじゃないかと思ってます。
忙しすぎでしょ、おかし。。。いえ、有難うございます。
成長の機会だ！ってことでがんばってる次第です。
と雑談はさておき、
タイトルのコーディング方針について。
あるプロジェクトの改修でパッケージをちょこっといじくってます。
要件整理、
見積り、
設計、
開発、
テスト仕様書作成、
改修に伴う仕様書修正、
手順書作成、
リリース作業
まで一貫して自分がやります。(もちろん、レビュー有ですよ)
まぁ今回はある特定の取り込みデータのみに対して仕分け方法を変えるだけの単純明快な改修です。
ちゃちゃっと1時間くらいで
パッケージの中身にファンクション追加して
whereで絞ったのをupdateみたいな感じで作って上にレビュー依頼を出しました。
「次はサクッとテスト方針決めるかー。」って思ってたのですが、
初心に返される指摘を受けました。
それは。。。
- 今回以外に仕分けを変更したいデータが出たらどうするのか
- 上記点の改修があったあとに追加テストでテスト観点が無駄に増えない為にどう改修したらよいのか
個人的には、
「いや、絞る条件チャカチャカっと追加したらよいだけじゃないか」
と思っていたのですが、
「先読み」と「親切心」が足りなかったみたいです。
例えばシンプルに
update
テーブル名
set
カラムA=1
where
カラムA=0
and
カラムB=xxxx
;
とするよりも
update
テーブル名
set
カラムA=1
where
カラムA=0
and
カラムB in(
xxxx
)
;
としたほうがよいということ。
(そういう細かいところに気づけない自分、技術力低いな)
なぜかというと後者のほうが
もし今後追加で対応が必要になり、
かつ、別の作業者が対応するとなった場合、
可読性が高い。そして、改修行も最少。
もう少し、目の前のことばかりに対応する力だけではなく、
先まで見通した考える力を養えるべきだと感じました。
そのためにはほかに何が予測されるか、自分でどこまで周りを、このシステムのことを考えて動くかがカギです。
以上！
「sys」と「sysdba」の違い
Oracle 12cを勉強中なので、タイトルを基に記述。
というか、「sys」と「sysdba」の違いが気になった。
Oracleデータベースを作成すると必ず作られるこの２つ。
何が違うのか。
- sys
データベース管理者アカウント。
データベースの管理情報を格納するデータディクショナリのすべての実表とビューを所有する。
- system
データベース管理者アカウント。
管理情報を表示する表やビュー、Oracleデータベースのオプションやツールで使用する内部的な表やビューを所有する。
うーん。。具体的には結局わからない。
さらに追加
- sys
DBAロール(USER、ALL、DBAの順で大きい)が付与されている。
SYSDBA権限が付与されている。
すべての管理機能を実行可能
- system
DBAロールが付与されている。
さらに以下を除いたすべての管理機能を実行可能
⇒バックアップとリカバリ
⇒データベースアップグレード
これもわかりそうでまだスッキリしない。。
が、とどのつまり、
権限の括り具合としては
sys＞＞＞＞＞system
ってことだろう。
また、
sys
⇒SYSDBA権限(インスタンス管理権限＋データベース内部の管理権限)
というのはデータベースの起動・停止とか
データベースの外側からいじくれる
のに対して、
system
⇒DBA権限(データベース内部の管理権限)
というのはデータベースの起動・停止とかできないけど、
データベースの中側はいじくれるよ
ってことだろうと解釈。
そのため、sqlplusなんかで接続するときは
sysは「as sysdba」をつけなきゃなんない。
なぜかっていうと、
「as sysdba」
が付加されていることによって、
OS認証されているから。
OSグループの「dbaグループ」または「operグループ」(LINUX,UNIXでね)
※Windowsなら「ORA_DBAグループ」または「ORA_OPERグループ」
に所属しているかどうかはデータベース外部でしかわからない。
そんでもって外部で認証できなければ、データベースの起動も停止もできない。
あとOS認証だけでなくて、パスワードファイル認証ってのもあるらしい。
パスワードファイルというファイルが存在していて、それに登録されているか
確認されてSYSDBA権限が付与されるとかなんとか。。
ちなみに
OS認証
⇒CONNECT /AS SYSDBA
パスワードファイル認証
⇒CONNECT ユーザ名/パスワード AS SYSDBA
と入力！
最後に簡単に言うと、
sysが一番強くて
systemはsysより弱いってこと。
あと接続時に「as sysdba」忘れるべからずってこと。
【追記】
sqlplusでは
sqlplus /nologでsqlplusをとりあえず接続できる。
そのあとは
connect ユーザ名/パスワード
または
conn ユーザ名/パスワード
で接続。
disconnectまたはdisconnで接続解除できる。
※quitだとsqlplus自体、終了してしまう。
はじめまして Part2(目標や記事の定義)
ではでは前回の自己紹介の続きを。
現在は自己紹介通り、SEとして働いています。
ある意味、一つ夢がかないました。
そこからSEになって現在、前のような成長してる、何か夢に向かって頑張ってる！みたいなのがなくなっているように感じました。
言い訳ですが、高卒からこのSEになるまでモーーーーーーーーーレツに走り抜けたおかげか燃え尽き感がすごいのです。
というか次の明確な、燃えるような、我武者羅になれるような目標がない。
ってなわけで、改めて原点を。
そもそもなんでSEになりたかったのか、なんで今この地点の人生を歩んでいるのか
根っこを考えてみました。
すると…
- 人としゃべるのが好き。たくさんコミュニケーション取りたい。
- システム、ハイテクなものが好き。
- 人の役に立ちたい。感謝されたい。認められたい。すごいと思われたい。
というのが根本の自分の理想像と分析。
じゃあそれを職業に当てはめるとなにかなー・・・っと探してみると、
ITコンサルタント！！！
(まぁ極論いうとITじゃなくてもよかったりする、
とにかく営業とか人と接するのが好きで前職が天職なんじゃないかとおも)
ただよく見るのがコンサルタントは大卒以上、高学歴とか高学歴とかこうがｋ。。。
とはいってもそれで諦めません。
自分の人生一度きりなので、挑戦しようと思います。
以上で自分の自己紹介のすべてになります。
このブログでは
- 自分の夢・目標に伴う考え方や行動の履歴
- IT技術的な備忘録
- IT資格受験の記録
を書いていこうと思います。
自分の成長のためでもありますし、
また、同じような境遇の方や興味のある方の少しでも助けや安心、勇気を
与えれたらなと思います。
＜追記＞
補足でSEといっても今なにしてんの？ってところを。
私の業務は参画プロジェクトによってやることがまちまちです。
現在はあるシステムの運用・保守を中心にしてます。
具体的な作業としてはテスターみたいにテストしたり、
プログラマーみたいに改修プログラミングしたり、
エラーが発生して調査したり、
顧客から問い合わせがあって調査したり、
提案資料を作ったり、対応見積もりを作成したり、
顧客と話し合ったり、
上流？から下流？までざくっとやります。
(すげー経験がもらえる、周りの人に感謝してます)
はじめまして！
タイトル通り、はじめまして！
最初は自己紹介やこのブログを始めた理由を書きたいと思います。
私は東京でIT業界に入ってSE2年目の25歳です。
そんでもって田舎からの出です。
地元にいたときからのことを説明しますと。。
元々、小さい頃からゲームやハイテクな技術が好きでした。
また、テレビなどで黒い画面、英文字だけのものをパソコンでカチャカチャ動かしているプログラマー、SEって「カッケーっ！」という興味本位から
高校卒業後、情報工学を勉強しようと大学受験をしたのですが。。。
失敗しました(笑)
まぁよくある学力不足やお金不足が原因です。。(あと大学高望み)
いろいろ自分が原因(＾＾；)
その後、浪人・・・というかニートして
親にも迷惑かけてしまい、これじゃ不味いなってところで
某流通業界大手の契約社員になりました。
(学費を貯めて大学いこう！ってことで)
ぐぁーーーーーーーっと！我武者羅に！
働きまくって3年目になったくらいに
このまんまじゃ大学いっても専門いってもだいぶ歳がいっちゃうな。。
就職とか諸々、きつくなっちゃうなと漠然に感じました。
また、その時の流通業界では営業職だったので、仕事していく中で人としゃべるの好きだな。得意なんだな。
「感謝されるとたまらないな。」って気持ちと
SEってコミュニケーションが求められる。
また、人々に感謝されるようなシステムやすごい！って思われるシステム作りたいって気持ちから
ますます、人と話す力が強いSEになりたくなりました。
そんなことから資格とって転職しちゃえばいいや！って気持ちから
ITスクールに通い、Javaの資格をとりました。
そんでもってどうせなら東京の大舞台でがんばろう！って極端な性格で一気にこっちに。
そして現在、IT業界に入り、SEになっています。
これが「高卒から現在、SEの自分」までの大まかな流れです。
では次回、その後の目標について書いていきます。
