AWS 認定ソリューションアーキテクト – アソシエイトとして認定されました
これをとりました。スコアは 909/1000 でした。 公開している認定情報はこちら。
AWS 認定の種類やランクについては公式のドキュメントや、他の記事に譲ります。
AWS 認定 – AWS クラウドコンピューティング認定プログラム | AWS
バックグラウンド
AWS の知識や経験は初心者を脱しているかな〜というレベルです。
試験前の対策
試験前はがっつり勉強するというより、これまでの知識と経験、ちょくちょくインプットしてきたものを振り返るような形でした。
- サンプル問題 *1 の確認
- 模擬試験 ( ¥2,000 )
- これで 9 割程度のスコアだったので新たに知識を詰め込まなくてもいけるだろうと判断
- Web 上にある問題集を眺める
- ところどころ、内容が古かったり回答が間違っているものがあり
- 未経験者・初学者はまず公式ドキュメントや書籍から学習する方がいいと思う
- 経験者が振り返りに使う分にはコスパがいい
準備期間は 1 週間でした。
どうやって知識や経験を得るか?
これだけでは AWS 認定の取得を目指す人の参考にはならないので、個人的にどうアプローチすればいいと思うか書いておきます。 ほとんどが継続的に取り組むものなので時間はかかりますが、この方法で得た知識や経験は認定取得に関わらず確実に役に立つと思います。 試験内容も単なる暗記ものではなく、「ある前提条件においての最適解はどれ?」というような問いがほとんどのため、試験前に暗記して突破できる類のものではないです。
知識
- 入門者向けの座学
- 既に AWS 上で稼働しているシステムの AWS 環境を参照できるなら、どういう設計になっているか見てみる
- 新サービスの発表やアップデートをチェック
- 先輩や同僚で詳しい人に相談や質問する
- 勉強会に参加する
- AWS がやたらと推してくるサービスやアーキテクチャを知る
- DynamoDB とか DynamoDB とか
書籍は知識が体系的に、かつコンパクトにまとまっているので入門としては優れていると思います。 しかし AWS のサービスはアップデートが早く、特に紙媒体の情報は陳腐化しやすいです。 したがって、継続的なウォッチと知識のアップデートは必要です。
経験
- 何はともあれ構築してみる!
- チュートリアルができたら自分なりの工夫を入れてみる
- 例えば
- パブリックサブネットにあるデータベースをプライベートサブネットに置いてみる
- メンテナンスしやすいセキュリティグループを考えてみる
- シングルインスタンスを Auto Scaling させてみる
- CloudFormation ( インフラのコード化 ) でやってみる
- 他のチュートリアルと悪魔合体してみる
- AWS のチュートリアル同士の掛け合わせじゃないけど、考え方としてはこういうのとか ikasamak503.hatenablog.com
- トラブルシューティングする
- 失敗からはたくさんのことを学べます
- 本当はトラブルは無いに越したことないけどね
- 勉強会等で登壇する
- 得られた経験を整理するいい機会です
- 僕はまだできてない
本試験の本人認証における注意点
TL;DR
- 顔写真付きの証明書は運転免許証またはパスポートが無難
- 日本のマイナンバーカードは政府発行の証明書として認識されないようなので避けたほうがいい
本人認証の書類として顔写真付きの証明書を持参し、テスト前に機械でスキャンする必要があります。 当日はマイナンバーカードを持参しましたが、何度スキャンしても NG 判定となって先に進めませんでした。 テスト用端末ではチャットでオペレーターとコミュニケーションを取ることができ、 端末操作に関する質問や、オペレーターからの指示がきます。 何度もマイナンバーカードをスキャンしていると、オペレーターからこんな質問がきました。
「それは政府機関発行の ID ですか?」
思わず「まじか・・・」と呟いていました。
ikasama「日本の自治体が発行する個人番号を確認するカードです」 オペレーター「確認します、少々お待ちください」
といってしばらく待たされました。 しばらく待っていると遠隔操作ソフト *3 のセッションが開始し、オペレーターが画面を操作し始めました。 試験アプリケーションを閉じて Windows のデスクトップが表示されて「おおっ」となったり、管理者ユーザーっぽいものに切り替えたり。 証明書スキャナーを起動するスタンドアロンのアプリケーションを起動して、 マイナンバーカードをスキャンするように指示 *4 されたり。 最終的には顔写真を撮る用の Web カメラにマイナンバーカードを近づけて認識 *5 してもらうということに。 なんとか確認は取れたことになって、試験アプリケーションの証明書スキャナーはスキップして進みました。 これだけで約 30 分くらい費やして変に疲れました。
次は
AWS 認定を取得すると模擬試験が無料になったり、本試験の受験料が半額になる特典があります。 せっかくなので Developer Assoiate か SysOps Associate を目指そうと思います。
まとめ
*1:ここからダウンロードできます https://aws.amazon.com/jp/certification/certified-solutions-architect-associate/
*2:https://aws.amazon.com/jp/free/
*3:具体的な製品名の公表ここでは控えます
*4:この間、コミュニケーションの手段がないので Windows のメモ帳で筆談しました
*5: 見えづらいとか、 2cm くらいの距離に近づけて、とか色々めんどくさかった
マーソ株式会社を退職します
6 月 30 日付けで退職、昨日 28 日が最終出社日でした。 2018 年 2 月から、約 1 年半お世話になりました。
マーソ株式会社 is 何
( 2019 年 6 月末時点の情報です )
MRSO という Web サービスを運営している会社です。 MRSO は、人間ドックや検診を全国の医療施設から検索・予約できるポータルサイトです。 登録されている医療施設数は、国内の類似サービスの中ではトップクラスの規模です。
他にもこんな事業をやっています。
- MRSO で利用できるギフト券、マーソギフト券の販売
- 健康をプレゼントするとう考え方
- ご両親に人間ドックを受けてほしい! というユースケースが多いようです
- 企業向けの健診結果管理システムの開発・運用 ( toB )
何をしていたのか
MRSO の開発・運営に必要なほとんどの領域を担当していました。 具体的には、
- 新機能の開発やバグ修正
- 問い合わせ対応
- 現行の仕様や不具合の調査 ( ほとんどの仕様がドキュメントに残っていない )
- 一部機能の設定変更
- エッジケースの手動オペレーション
- 障害時のトラブルシューティング
- データの抽出
- こんなデータが欲しいんやけど、を SQL にゴリゴリとトランスパイルしていました
- 開発環境、テスト環境、本番環境のインフラメンテナンス
こんなことをやっていました。
他にも片手間で、
- 技術的な相談
- こういうことを実現したいけどどうしたらいい?
- 壁打ち役
- Slack bot を作る
- 分かったことをひたすらドキュメントを残していく
- 新卒 3 名 ( ベトナム人 ) の教育
- 議事録をとらせて、あとで一緒に振り返り
- モブプロ + TDD
もやってましたが、特に教育に関しては思いつきベースで取り組んだものの、 もっとちゃんと考えてあげたかったな~と反省しています。
何を残せたのか
具体的な成果物として残って、特に活用されている ( と感じている ) 順に並べてみるとこんな感じです。
- 本番環境相当のテスト環境作成
- テスト環境 Docker 化
- 社内にあった Jenkins サーバーを AWS 上に引っ越し
- メルマガの配信作業を都度から 月 1 回にまとめた
- 仕様などを調査したドキュメント
- CakePHP 2.x -> CakePHP 3.x のコア機能移植
- 管理画面のセキュリティ強化
- WordPress Plugin & CLI 開発
特に 1. 本番環境相当のテスト環境 は社内・社外関係者含めてめちゃくちゃ使われています。 網羅的な状態パターンのテストができていないと、本番環境の状態の再現してテストする必要があって、 そのコストをすっ飛ばせるようになったのは大きいです。 構築当初に想定していた以上の ROI だったんじゃないかと思います。
なぜ辞めるのか
会社や上司、同僚の仕事に対する考え方が合わない
一言でいうとこれにつきます。 具体的には、
- エンジニアがあまり大事にされないと感じる
- フレックス・リモートワークなし、 9 時 - 18 時は要出社
- 実際は出社しないとできない仕事はほとんどない
- リモートでコミュニケーションをうまく取れない人が多いのは事実
- 保守的な考えの人が多く、変化を恐れがち
- 技術レベルの高い人がいない
- みんな見様見真似で CakePHP を書いている
- チームで成果を出すことを真剣に考えていない
- 要するに個人プレーの集まりで仕事をしている感
- とりあえず人を集めてリソース効率高く仕事を振ることはできる
- 成果の品質やフロー効率は考えられていない
- あまり情報をオープンにしない文化
- 期限を守ることが最優先され、品質の妥協や残業でカバーといった手を打ちがち
- 事前にプレスリリース打ってるわけでもないのに、みたいなのがちらほら
- オンボーディング、教育が無
- エンジニア採用をあきらめている感
- このまま居ても優秀な人には出会えなさそう
こういうことが積み重なって入社直後からモチベーションが下がり、 遅刻や欠勤が目立つようになってしまいました。 単純に体調が悪い日もあれば家で自己研鑽する日もあり、 そうやって身に着けたスキルや経験を仕事に還元していくスタイルでやっていました。 しかし面談では勤怠が悪いと評価はできないと通達されてしまい、 その際に働き方や今感じている問題を話し合いましたが、解決は難しいと確信し、退職を決めました。
2019/07/01 追記 評価と反省点、よかったところ
一方的に前職のネガティブな面を書いているように見えるので、上司や同僚からの評価と自身の反省点、前職でよかったことも書いておきます。
上司や同僚からの評価
Good Point
- キャッチアップが早い
- 入社数日でバグ修正の Pull Request 出してた気がする
- インフラ、特にネットワーク周りが強くて助かった
- 問い合わせへの回答が丁寧で的確
- 仕事の仕方がスマート
Bad Point
- 勤怠が悪い
- 期限切れのタスクを抱えたまま報告がないことが度々あった
- 特にクリティカルなものに関しては一人で考えて決める前に相談して欲しい
???
- 先生みたい ( 新人談 )
反省点
- 勤怠不良がアウトプットの物量にも影響し、結果として担当タスクの完了が遅れるなどした
- コミュニケーションで誤解や不安を与えるような伝え方をしてしまっていたかもしれない
- 良いことも悪いことも包み隠さず発言していたが、社内の文化からは逆行していたように思う
- とにかく「論理的」に「正しい」主張をするため、冷たい印象を与えたかもしれない
- もっとたくさんコミュニケーションをとったほうがよかったと思う
- 特にエンジニア以外ともっと話すべきだったな〜
- 新人の教育にしっかり取り組めなかった
前職のよかったところ
- 休みを取りづらいという雰囲気はあまりない
- あれだけめちゃくちゃ休みまくってたけど逆に気を遣ってくれてもいた
- 性格の悪い人は居なさそうだった
- そういう人も自然とフェードアウトしていくのかも
- ビジネス面でもまだ伸び代があると思う
- ルールが整備されていないので自分たちでルールを作っていける余地がある
2019/07/01 追記終わり
次はどうするのか
株式会社ゆめみ でサーバーサイドエンジニアとして働きます。よろしくお願いします。
ゴリラ.vim #4 に参加してきました #gorillavim
当日飛び入りで参加してきました。 今回は神回という声もあって、そんなタイミングで参加できたのは幸運だったなと思います。
各発表のサマリと感想
翻訳プラグイン作った by ゴリラ さん @gorilla0513
- コマンドやバッファで入力した内容を翻訳
- GAS ( Google Translate ) + Go + VimScript で実装
- バッファに文字列を入力して Enter すると逐次翻訳されていく様は見ていて楽しい
- 学生の頃、英単語の勉強のために xyzzy で似たようなことやってたな~としみじみ
- ゴリラさん、 さくらのナレッジで vim の連載が決定! 今から楽しみです。
- 書籍も出したいとのこと
【速報】
— ゴリラ (@gorilla0513) 2019年5月13日
さくらインターネットさんのさくらのナレッジでvimの連載が決まりましたhttps://t.co/GRgdjHmrBi
GWで初めてVim Pluginを作った話 by かまたけんし さん @knsh14
- Vim のバッファ上の選択範囲から GitHub のリンクを作ってクリップボードにコピーするプラグイン
- 便利!
- コードレビューとかで「ここの実装見てみて」といったアドバイスするときに URL 欲しくなる
- いつもブラウザでアクセスしてアドレスコピーしてた
- 今のところ GitHub と GitLab に対応
選択範囲から GitHub のリンクを生成してクリップボードにコピーするプラグインhttps://t.co/JSFZKZg0MB#gorillavim pic.twitter.com/kDyWQ9Y9D4
— ɐɯɐsɐʞ! (@ikasamak) 2019年5月15日
terminal-api について by てんなし さん @tnnsh1
Neovim 0.4.0 新機能 フロートウィンドウについて by ドッグ さん @Linda_pp
- 既存のウィンドウの上にオーバーラップしたウィンドウを作ることができる!
- 従来の Vim ウィンドウと同じように使える
- はみ出すときは自動で位置とサイズを調整してくれる
- こういうところ考えなくてよくなるのは楽!
- フロートウィンドウを使った Plugin 例
- git-messenger.vim
- カーソル位置のコミットログをフロートウィンドウで表示 github.com
- vim-iced
- カーソル位置の Clojure の評価結果をフロートウィンドウで表示 github.com
- git-messenger.vim
- 惜しむらくは Neovim の機能というところ
- 本家 Vim にもほしい!
- それか Neovim に乗り換えるか
飛び入り LT by tamy さん @__tamy
- comamnd-line fuzzy finder の紹介
- 作者謹製の Vim Plugin もある
- バッファをたくさん開いているときのバッファ選択とかに強い
- fzf はいいぞ!
- ぼくも enhancd と組み合わせて使ってます
飛び入り LT by ujihisa さん @ujm
- ライブコーディングが印象的でそれしか覚えてない、、、
grep
コマンドを VimScript で実装してみることに- 「美しいけど動かないコードより汚くても動くコードのほうが無限倍良い」、至言
- 小さく実装して QuickRun を回す
- スピードが圧倒的に違う、、、
- マニュアルを参照しながら実装していく
- これはフレームワークに乗っかって開発するときはよくやる
最終的に出来上がったコード ( 所用時間: 15 分 ) gist.github.com
米国に行かれるそうなので、これが日本で最後の LT になるかもとのこと
- 最後に面白いもの見させてもらいました!
飛び入り LT by はやぶさ さん @haya14busa
- タブにラベルを付与して表示させて、それをもってタブ移動できる
- タブ 4 つ以上開いてるときは便利そう
- でもぼくは tmux 使うから Vim の中であんまりタブ開かないかも……
VimConf 2019 の告知!
全体を通して
レガシーをぶっつぶせ。現場でDDD! 参加レポート #genbadeDDD
申込み時点で +100 人くらいで補欠だったので諦めてたんですが、 当日の 0:30 に繰り上がり通知が来て、慌てて参加しました。
全体を通して、いくつか印象に残ったことを書いておきます。
- 始める前にメンバーとの共通認識をつくる
- DDD の方法そのものの学習
- 業務知識の理解
- エンジニア以外のメンバーとの共通認識も重要
- 良い設計のためにはビジネスの理解が必要
- まったく新しく取り組む場合はリスクを小さくする
- 小さく始める
- 重要だが緊急性が低いもの
- 緊急性が高いと品質を犠牲に完成を強いる圧力がかかりがち
- ビジネスサイドへの説明は簡単ではないが大事
- 小さく始めると少ないコストで実績を積んで成果を確認できる
- 刷新前と刷新後のコードベースに対して同じ改修をして効果測定をした
説得のために刷新前と刷新後全く同じ機能を作って効果測定したらしい!すごい #genbadeDDD pic.twitter.com/xVcRCk8kfn
— 松岡@DDDブログ書いてます (@little_hand_s) 2019年5月11日
- 変化に弱い = レガシーになりやすい
- とりあえずマイクロサービスにすればいいというわけではない
- サービス分割がイケてないとやっぱりポシャる
感想
- 新規開発ではつまづかないような、レガシーと戦う上での知見が聞けてよかった
- チームで DDD に取り組むための心構えができた
- まだ仕事で実践できていないけど、学んだ内容の再確認ができた
- DDD は銀の弾丸ではない。レガシーとの戦いは泥臭い作業の繰り返しだ。
zsh + zplug で最強でポータブルなターミナル環境を作りたい
タイトルで言いたいことは全部言いました。
なんとなくインストールしていた zplug, よく見ると何でもかんでもインストールできることに気づきました。
zplug "jhawthorn/fzy", \ as:command, \ rename-to:fzy, \ hook-build:"make && sudo make install"
これを使えば、言語環境から各種 CLI ツールまで全部 zpug で管理できるのでは? 最終的に、まっさらな環境で
sudo yum install -y git zsh git cllone git@github.com:ikasam/dotfiles.git chsh -s /bin/zsh exec zsh -l
と実行するだけで開発環境が出来上がるかもしれない。
導入するもの
次に新しい職場に行くまでに作っておきたい。
技術書典 6 の本の感想 / 技術を伝えるテクニック
- テクニックの具体例があって実践しやすい
- 文章だけでなく、登壇のテクニック、上手く教わるテクニックも紹介されていて良い
- 目次だけでもだいたい伝わってくるところがすごい
技術書典 6 の本の感想 / フリーランスを完全に理解できる本 / バーチャル幼女プログラマー きりみんちゃん 公式ファンブック
フリーランスを完全に理解できる本
- フリーランスという働き方にまつわる事柄を 1 冊で知れます
- 一つ一つのトピックは自力で調べられる内容だけど、コンパクトにまとまっていて良い
- 単価水準は参考にしてみようと思いました
- あくまで 2019 年現在、東京都内の Web 系エンジニアの相場です
- 税金周りはサラリーマンでも知っておいて損はない内容だと思います
- キャリアについては軽く触れられている程度ですが、すぐに実践しやすい内容です
- このあたりを掘り下げたかったら、より詳しい専門書をあたると良いでしょう
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (8件) を見る
バーチャル幼女プログラマー きりみんちゃん 公式ファンブック
- 文字が少ないので脳のリソースを使わなくて良いです
- 1 ページ目に
Hallo kirimin-chan
って書いてあるけど幼女キャラの演出かなと好意的に捉えています - 君も公式ファンブックを買ってきりみんちゃんを応援しよう!