Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って始めたブログ

Webエンジニアへ転職後に学んだ事(6回目)

はじめに

このブログ記事は、約11年間、客先常駐で『マネジメント』をメインに続けてきて、技術力が全く無くて後悔していた人が、Webエンジニアへ転職して学んだ事を記録しておくために書いています。自身の振り返りのために書いている記事ですが、30代の方で同じような境遇で技術力が全く無くて後悔している方々にとっても「Webエンジニアになるとこんな事を勉強するんだ・・・」と雰囲気を掴んで貰えれば幸いです。

AWS Dev Day Tokyo 2018 の一部のセッションに参加

10月末、上司とこんなやりとりがありました。

上司「AWS Dev Day Tokyo 2018のServerlessのセッションを見たほうがいいよ」

私「え、会社で見ていいんですか?」

上司「うん、ストリーミング放送見る時はイヤホンつけてね。あと、この2つのセッションは僕が仕事で行けなくなったから代わりに参加してきていいけど・・・行ってくる?」

  • GraphQL 入門(AWS AppSync)
  • クックパッドの動画事業での AppSync 活用事事例 - Firebaseからの移行 -

私「ぇ、マジっすか?」
(過去にこんな経験は無かったので・・・しばらく考える・・・)

私「行ってきます!!!」

というわけで、AWS Dev Day Tokyo 2018のServerlessの以下2つのセッションを聞きに行きました。

  • GraphQL 入門(AWS AppSync)
  • クックパッドの動画事業での AppSync 活用事事例 - Firebaseからの移行 -

場所は目黒のAmazonの新オフィス!

f:id:special-moucom:20181111165807j:plain オフィスは新しいビルだけあって、すごくキレイでお洒落でした。
(ああ・・・一度でいいから、こんなオフィスで働きたい・・・)

最近、噂になっていたAWSのアカウント持っている人だけのコワーキングスペースAWS Loft Tokyoも「あ、ここだったんだ・・・」と知りました。

aws.amazon.com

一度はここで勉強してみたいものですが、営業時間が平日のみというのが残念なところ・・・
Amazonのオフィスと併設なら仕方ありませんね。

会場にてセッションを視聴

f:id:special-moucom:20181111165833j:plain 会場に来て、1つ後悔したことがありました。

「パソコンもってきてない!!」

周りを見ると、皆さんパソコンを持ち込んでいらっしゃる・・・

  • 仕事をしながら(コードを書きながら)セッションを聞いている人
  • セッションで重要なところをパソコンでメモっている人
  • セッションを聞きながらTwitterに書き込んでいる人

様々ですが、パソコンを持ってきていない人は少数でした。(もしかすると私だけだったかもしれません・・・) 以後、気をつけよう・・・そう心に留めてセッションを視聴しました。

セッション視聴:GraphQL 入門(AWS AppSync)

大変わかりやすく「GraphQLとは何なのか?」を説明して頂きました。
一応簡単にセッションを聞いた上での私のGraphQLの解釈を書いておきます。

GraphQLとは? ・・・ API Query言語。REST APIに変わる次の技術。SQLのようにQueryを書く事で、欲しいデータを取得できる。

REST APIでは以下課題があり、それを解決してくれる。

  • APIドキュメントの管理:管理がずさんになってくると、ドキュメントとAPIの仕様の相違が出てきて大変。
    -> GraphQLなら、ドキュメントは拡張を見据えた汎用的なものを作れば良い。

  • APIの実行方法がわからない&複雑:ちょっとだけ欲しいデータがあっても、全量取得&複数回APIを実行する必要があったりする。
    -> GraphQLなら、APIの実行は欲しいデータだけをSELECTして取得すれば良い。

GraphQLの特に優れている点 ・・・ リアルタイム性。Query言語のため、SELECTだけでなくUPDATEも可能。例えば携帯のオンラインゲーム等でネットに繋げない間はローカル側でデータを更新 -> ネットに繋がった瞬間に更新したデータをGraphQLを使ってUPDATE(つまりクライアント側と即時に同期可能)できる。

というのが、セッションを聞いての私の解釈です。(間違っていたら、ごめんなさい)REST APIの課題については、非常に共感できました。

セッション視聴:クックパッドの動画事業での AppSync 活用事事例 - Firebaseからの移行 -

こちらも大変わかりやすくGraphQLを使った実例を説明して頂きました。
その前に、AppSyncですね。こちらも私なりの解釈を書いておきます。

AppSyncとは? ・・・ フルマネージドのGraphQL。

フルマネージドって? ・・・ GraphQLに以下機能を付属したもの。

  • 認証
  • 通知
  • ゾルバ、リクエストレスポンスの関数が使用可能
  • DynamoDBからテーブルをプロビジョニング

クックパットさんは、AppSyncをcookpadTVのLive事業にて使用しており、Live時のコメントやスタンプ投稿でGraphQLを使用しているとのことでした。
当初、FirebaseのRealtime Databaseを使っていたそうですが、AmazonGoogleでデータを分散させたくないとの事からAppSyncに移行したとの話でした。
「データを分散させたくない。」長期的に見れば保守性が上がり、コストも下がるかもしれませんが、これだけを理由に移行を考えるなんて、さすがクックパットさんだなぁと思わされました。

AppSyncへの移行も色々と課題があったそうです。
1つ「なるほどなぁ」と感じた部分があったので、そこだけ書いておきたいと思います。

AppSync(GraphQL)は上記の通りAPI Query言語で、あくまでクライアントからQueryを投げてもらって処理が動きます。そのため、クライアントとAppSync間には何も無く、Queryの内容をチェックする事ができません。そういった場合はサーバーを1つ挟むしか方法がありません。クックパットさんの実例では、コメント書き込み時に誹謗中傷を書かれる恐れがあるため、クライアントとAppSync間に1つサーバーを挟んで、コメント内容をチェックした後にAppSyncへ反映しているとの事でした。

ここは「あ、なるほどなぁ」と思わされました。
新しい技術は次々と出てきて、どんどん便利になっていきますが、その技術にも課題があり、また新しい技術が産まれるんだなぁと感じました。

最後に

f:id:special-moucom:20181111165901j:plain

実はこういったカンファレンスへの参加は今回が初めてでした。
カンファレンスに参加したことで、GraphQL/AppSyncに大変興味を持ちましたし、周りのエンジニアも凄そうな人ばかりで大変刺激になりました。今度は、上司に進められる前に自分が興味を持ったカンファレンスに参加したいと思います。
というわけで、次回はこちらに参加したいと思います。

phpcon.php.gr.jp

現在、WordPressの案件がくるとの事で、WordPressPHPの猛勉強中です。PHPで何ができるのか?何に使われているのか?そこを知りたいと思い参加を決めました。(まぁ、子供がいるので本当に参加できるのかはギリギリまでわかりませんが、可能な限り参加したいと思います(パソコンを忘れずに・・・))
最後に、カンファレンスの参加を進めてくれた上司(と会社)に非常感謝しています。前職なら絶対にありませんでした。(そもそも客先にいて業務中に不在にするとかありえない・・・)
頂けた機会を活用して、もっともっと知識を増やして強いエンジニアになれる様、頑張りたいと思います。

Webエンジニアへ転職後に学んだ事(5回目)

はじめに

このブログ記事は、約11年間、客先常駐で『マネジメント』をメインに続けてきて、技術力が全く無くて後悔していた人が、Webエンジニアへ転職して学んだ事を記録しておくために書いています。自身の振り返りのために書いている記事ですが、30代の方で同じような境遇で技術力が全く無くて後悔している方々にとっても「Webエンジニアになるとこんな事を勉強するんだ・・・」と雰囲気を掴んで貰えれば幸いです。

転職後7週目

今回は、転職後7週目の話になります。
が、今回学んだ事は久しぶりにQiitaに書きました。

qiita.com

私はQiitaとブログ両方のアカウントを持っていますが、以下のように使い分けて書いて行こうと思います。

  • ブログ ・・・ 私が学んだ事や近況について書く。
  • Qiita  ・・・ 技術的な事で悩んだ or 調べた事について書く。

Qiitaは技術的な話が集まる場なので、自身が悩んだ or 調べた情報を書いて、同じ様な境遇で悩んでいる方々への参考になればいいなという思いで書いていきたいと思います。
(もし、私が書いた情報に誤り等がありましたら、ご指摘頂けると幸いです。m( )m)

最近は?

上司から「もしかするとWordPressの案件がくるかもー」と言われたので、WordPressPHPの勉強をしています。開発環境は、Dockerコンテナを使ってWordPressを立ち上げて色々と触っているところです。
こちらについては、またどこかでブログに書いていきたいと思います。

学んだ事

ホントこれです。

普段意識しないで使っているコマンドでも「ちゃんと知っておこう」という姿勢が大事

以後、気をつけたいと思います。

Webエンジニアへ転職後に学んだ事(4回目)

はじめに

このブログ記事は、約11年間、客先常駐で『マネジメント』をメインに続けてきて、技術力が全く無くて後悔していた人が、Webエンジニアへ転職して学んだ事を記録しておくために書いています。自身の振り返りのために書いている記事ですが、30代の方で同じような境遇で技術力が全く無くて後悔している方々にとっても「Webエンジニアになるとこんな事を勉強するんだ・・・」と雰囲気を掴んで貰えれば幸いです。

転職後6週目

今回は、転職後6週目の話になります。
4週目と5週目は、子供が産まれた事でドタバタしており、慶弔休暇も頂いていたので割愛します。

今回はAWS Lambdaを使った開発を続けてきて資産が増えてきたので、この資産をどのように管理していくのか。という事を考え、色々と学んだのでそれを書いていきたいと思います。

資産管理はやっぱりGitHub

AWS lambdaといえど、管理対象となるのはプログラムのソースコードになるので、GitHubで管理すべきかと考えます。AWS CodeCommitを使う手段もありますが、開発者側が使い慣れている人が多いGitHubが良いと思いました。

GitHubでの管理は決まった。じゃあ開発環境や本番へのデプロイ方法は?

ここが悩みどころでした。
多くの方々がAWS lambdaの管理・デプロイ方法に悩まれており、現段階(2018/10時点)だと以下フレームワークの何れかを使うのが定番になっています。

AWS SAM
・Serverless Framework
・Apex

当然、私は3つのフレームワークの何れも使った事がありません。
そのため、1つ1つ導入からデプロイまでをやってみて、使用感を確かめていきました。 私なりに使用感を以下に纏めてみました。

比較項目 AWS SAM Serverless Framework Apex
公式/非公式 公式 非公式 非公式
検索したときの情報量 中(Oracleに同名の製品があり、稀にそっちの情報が混ざる事あり)
S3/CloudFormationの使用要否
テンプレートの作成難易度
デプロイの難易度 簡単 簡単(早い) 簡単(早い)
備考 Dockerコンテナを使った開発環境も提供 使用している人が多く、プラグインも多い S3/Cloud Formationを使用していないため、迅速にデプロイできるのが魅力

纏めてみた結果、個人的にはAWS SAMで行うべきかと思いました。
公式なので今後もサポートが期待できるという事やDockerコンテナを使った開発環境も提供されているので、開発環境で動いたけどデプロイしたら動かなくなった等のトラブルを未然に防げるのが良いかと思いました。

さて、これでAWS lambdaの管理方法は全てきまった問題なし

と思ったのですが・・・次はこんな疑問に辿り着きました。

「果たしてAWS Lambdaの資産管理ってどこまで管理すべきなの?」

AWS lambdaはイベントドリブン(つまり、AWS GateWayやS3にファイルが格納された等)なので、単体では動きません。
AWS lambdaを動かすためには、それに紐づくイベントの設定(AWS Gatewayの設定やS3のファイル格納場所、権限等の設定)が必要で、デプロイとイベントの設定をして初めて動かす事ができます。
AWS SAMやServerless Frameworkは、結局はCloudFormation(AWSの構築をテンプレートと呼ばれるファイルにそって自動で行ってくれる機能)を使ってデプロイしているので、テンプレートにイベントの設定を書く事で、この問題はクリアにできます。

ですが・・・

AWS lambdaをちょっとやりました。という人が、そのテンプレートにイベントの設定を書いていくのはキツイ!!本当にキツイです!!!

色々テンプレートの書き方を調べてみましたが「テンプレートはこう書きます。(ボンッ)」という感じで、既に完成済みのテンプレートが出てくるものばかり・・・

ホントすごくない????

と思ったのが正直な気持ちです。
というわけで、一旦管理するのはAWS lambdaのプログラムのみにして、イベントの管理はまた考える・・・という事になりました。

どなたかCloudFormationのテンプレートの簡単な書き方を教えてくださいorz

学んだ事

AWS lambdaの管理方法を考える上で、現状3つのフレームワークを使う手段があるということ。
AWS lambdaはイベントドリブンなので、イベント側の管理方法も考えないといけないということ。
AWS SAMにはDockerコンテナを使用したテストが可能であること、また、Dockerを使ったメリットにも気づけました。

妻への感謝と子育てエンジニアの凄さを実感したこと

この度、我が家に新しい家族が加わりました。(女の子です。)

今は本当に幸せです。
娘は可愛くて、泣いている時、笑ってきる時、無心の時(ボーっとしてる時)、今は全てが私の宝物になっています。「あぁ、こうやって親バカになっていくんだな」と思いました。

妻には本当に感謝しています。
出産の時に陣痛で苦しんでいる妻の姿を見て、私も凄く辛い気持ちになりました。
少しでも陣痛の痛みを和らげようと一晩中マッサージを繰り返しましたが、それでも痛みの方が強らしく「私はなんて無力なんだろう・・・」と思う時もありました。

そんな中、無事出産を終えて子供の姿を見たときは思わず涙がでてしまいました。
「これから頑張って娘を育てていこう。」妻とそう約束しました。

数日が経ち、妻と娘が退院して家で一緒に暮らす事になりました。
そこからは、もう大変です。
オムツを換えたり、ミルクをあげたり、沐浴させたり、夜泣きに抱っこ等、何もかもが初めてで、学ぶことが沢山あります。(現在進行系)
それに加えて、家事やエンジニアとしての勉強もしないといけないので、完全に体力不足だと実感しました。

世の「子育てエンジニアの方々」ってなんて凄い存在なんだろうと改めて思いました。
頭の中では、大変だろうなぁとかイメージは十分持っているつもりでしたが、実際に体験すると身に沁みてわかりました。

今はこうやってブログを書くだけでも精一杯なので、今後は自身の時間の使い方や効率良く作業をこなしていきたいと思います。 (もしかすると子育てはマネジメント力や作業効率を高めるアイディア力を養えるし、経験にもなるかもしれませんね。)

最後にちょっとだけ技術ネタです。

2018/10/08に『技術書典5』がありました。

techbookfest.org

Twitter等で話題になっていたので、私も参加してみたかったのですが、当然行けるはずもなく参加を諦めました。 しかし、本自体は以下で買う事ができるとの事です。

BOOTH - 創作活動がより楽しくなるショップ作成サービス

とりあえず、読んでみたいと思った以下2冊だけ購入しました。

f:id:special-moucom:20181013132459p:plain

感想はブログかTwiitter等で書きたいと思いますが、他にも面白そうな書籍が沢山あるので、興味を持ったものはどんどん買って読んでいきたいと思います。

Webエンジニアへ転職後に学んだ事(3回目)

はじめに

このブログ記事は、約11年間、客先常駐で『マネジメント』をメインに続けてきて、技術力が全く無くて後悔していた人が、Webエンジニアへ転職して学んだ事を記録しておくために書いています。自身の振り返りのために書いている記事ですが、30代の方で同じような境遇で技術力が全く無くて後悔している方々にとっても「Webエンジニアになるとこんな事を勉強するんだ・・・」と雰囲気を掴んで貰えれば幸いです。

転職後3週目

2週目で、保守改善の仕事を任されてクラウド環境を保守するためのソフトウェア(Trend Micro Deep SecurityとMackerel)を初めて知ったので、そちらについて書きたいと思います。

Trend Micro Deep Security

多くの方が御存知かと思いますが、 家庭のパソコンやスマホインターネット犯罪から守る『ウィルスバスター』を販売しているTrend Micro社。そのTrend Micro社はクラウドに対してもサービスを行っており、それが『Deep Security』と呼ばれています。

www.trendmicro.com

Mackerel

サーバーを監視するためのサービスを提供するMackerel。サーバーのCPU負荷やメモリ使用率等をブラウザ上から簡単に見る事ができます。しかも、グラフ等を使っていて大変見やすく、閾値を超えた時にアラートで通知したり、サーバーを保守するための便利な機能が多く提供されています。

mackerel.io

感想

Trend Micro Deep Security:
Trend Micro社は、こんなことまでやっていたのか!」と初めて知りました。市販の『ウィルスバスター』同様、一度導入と設定をしてしまえば、殆ど触ること無くセキュリティの強化をしてくれる。そんな印象です。もし設定を変更するような場合でも、REST APIが提供されているため、APIを使ってツールに組み込めば色々と工夫できそうです。

Mackerel:
こちらも初めて知りました。使ってみた感想としては「なんて便利なんだ。」の一言です。 デフォルト機能だけでは最低限の監視しかできないので、GitHubで公開されているプラグインやチェックツールを導入・作成して、保守しやすい様に自分でカスタマイズしていくところが魅力なのかなという印象です。

両サービスを初めて知りましたが、個人的に面白いなと感じたのはMackerelです。
サーバーに対して、こんな監視はできないか or こんな情報はとれないか。等、色々と試行錯誤するのがとても面白いです。
例えば・・・
1) CPU負荷が掛かった時にどのプロセスが動いていたのかチェックしたい。
Mackerelには、1分毎に自身で作成したプログラムを実行してステータスコード(正常終了、ワーニング、エラー)を返せるチェック機能が提供されています。それを使用して、CPU使用率をチェックして、使用率によってステータスコードを返すプログラムを自身で作る事で実現できます。
2) Nginxのプロセスを監視したい。
GitHubプラグインが提供されています。

mackerel-agent-plugins/mackerel-plugin-nginx at master · mackerelio/mackerel-agent-plugins · GitHub

3) Nginxの死活監視をしたい。
こちらもチェック機能を使用して、Nginxのステータスを1分毎にチェックするプログラムを自身で作成すれば実現できます。
4) sendMeilのport25/TCPを監視したい。
GitHubプラグインが提供されています。

https://github.com/mackerelio/go-check-plugins/tree/master/check-smtp

この様にサーバーに対して何を監視したいのかを考えて、色々と思考錯誤できるのがMackerelの良いところだと感じました。

学んだ事

Trend Micro Deep SecurityとMackerelの存在
クラウドになってもサーバーに対するセキュリティや監視は大切であり、その方法の1つとしてこの様なサービスを使って、保守・管理を楽にするのかが重要だと学びました。