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

はじめに

このブログ記事は、約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

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

比較項目	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を使ったメリットにも気づけました。

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

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

先ほど無事に子供が産まれました。
あまりの感動に泣いてしまった……

父親として、エンジニアとして、立派な男になる様、努めたいと思います。

— @Kodak_log (@Kodak_log) 2018年9月30日

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

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

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

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

赤ちゃんが家にきて3日目、か、体が痛い…… 完全に体力不足か……

— @Kodak_log (@Kodak_log) 2018年10月6日

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

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

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

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

techbookfest.org

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

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

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

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

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

はじめに

このブログ記事は、約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の存在
クラウドになってもサーバーに対するセキュリティや監視は大切であり、その方法の１つとしてこの様なサービスを使って、保守・管理を楽にするのかが重要だと学びました。

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

はじめに

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

転職後2週目

1週目でPython3、AWS lambda等を(初めて)使った課題をやったわけですが、まだまだ戦力外・・・
ですが、今度は課題ではなく、保守改善の仕事を頂きました。

保守改善の仕事

課題内容：
１日１回、RSSフィードの情報を取得して、他のサイトでも展開されている情報と突合せ、情報の正確性を確認する。
（一応仕事の内容なので、曖昧な表現で書かせていただきます）

使用言語：
Python3、AWS Lambda

感想

またもやAWS Lambdaです。
使ってみて感じたのですが、AWS Lambdaは凄く便利です。何かをトリガーにして処理が動く(イベントドリブン)は、本当に画期的だと感じました。

Python3もまだまだ勉強中です。今回は初めてWebスクレイピングに挑戦しました。

ちなみに、私の知る限りPython3が得意な先輩が社内にいない・・・
（先輩もPython3を進めておきながら、自分は書かないと言っているし・・・う〜む・・・）

学んだ事

1) [AWS]実はAWS Lambdaは処理速度が遅い
当たり前かもしれませんが、個人環境(以降、ローカル環境)でLambdaを動かすのとAWSからLambdaを動かすのとでは、処理速度が全然違いました。ローカル環境では、3秒で終わる処理が、AWSだと10秒くらいかかります。
これによって何が問題なのかというと、2)になります。

2) [AWS]Lambdaには、デフォルト設定の3秒ルールがある
Lambdaのデフォルト設定では、ファンクションの実行時間は3秒になっています。
もちろん設定の変更は可能ですが、ローカル環境で処理がうまく動いたとしても、AWSへ移植した後にLambdaを動かすとTimeout Errorになる事があるので、注意が必要です。（なお、この3秒ルールはローカル環境でも同じです。しかし、1)で書いた通りローカルとAWSで処理速度に差があるので、AWSへ移植する際には注意が必要です。)

3) [Python3]RSSパースの使い方
Python3のライブラリのfeedparserを使ったのですが、上記1)と2)により、処理速度改善が必要でした。lambdaを動かした時に、どの処理に時間が掛かっているかを調べるには、AWS X-Rayを使用します。私は以下を参考にしました。

qiita.com

X-Rayの結果、RSSのパースに時間がかかっていたことがわかりました。
feedperser.pase(URL)という書き方で実装しましたが、私なりに調べた結果、以下の2つの方法で改善できました。

　1. request.getでオブジェクトを取得した後に、パースする。
　2. 別のライブラリであるspeedparserを使用する。

結果的には、2.のspeedparserを使用するのが一番処理速度が早かったです。しかし、今回はspeedparserを使用せずに、1.のrequest.getで改善しました。
(家で)処理速度も簡単に比較してみました。処理速度の結果に並はありますが、比較的speedparsrが一番早く、次にrequests.getでした。

#### [RSSパースサンプルプログラム]
import datetime
import requests
import feedparser
import speedparser

YAHOO_RSS_URL = "https://news.yahoo.co.jp/pickup/rss.xml"

def main():

    # feedparser.parse(URL)を使用
    f_start = datetime.datetime.now()
    f_yahoo_parser = feedparser.parse(YAHOO_RSS_URL)
    f_end = datetime.datetime.now()
    print("feedparser.parse(URL)を使用")
    print(f_end - f_start)

    # requests.getでオブジェクト取得後、feedparser.parseを使用
    fr_start = datetime.datetime.now()
    r = requests.get(YAHOO_RSS_URL)
    fr_yahoo_parser = feedparser.parse(r.content)
    fr_end = datetime.datetime.now()
    print("requests.getでオブジェクト取得後、feedparser.parseを使用")
    print(fr_end - fr_start)

    # speedparserを使用
    sp_start = datetime.datetime.now()
    r = requests.get(YAHOO_RSS_URL)
    sp_yahoo_parser = speedparser.parse(r.content)
    sp_end = datetime.datetime.now()
    print("speedparserを使用")
    print(sp_end - sp_start)


if __name__=='__main__':
    main()

#### [出力結果]
$ python yahoo_rss_sample.py
feedparser.parse(URL)を使用 ・・・　3番目に早い
0:00:00.343013
requests.getでオブジェクト取得後、feedparser.parseを使用　・・・　2番目に早い
0:00:00.144237
speedparserを使用　・・・　1番早い
0:00:00.122377
$

最後に

私事ですが、昨晩、子供が産まれました。
父親として、エンジニアとして、一人前になる様、努めたいと思います。

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

はじめに

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

私はサーバーサードのエンジニア

ちょっとした自己紹介になります。
Webエンジニアへ転職しましたが、私の仕事での立ち位置はサーバーサイドエンジニアになります。他にもWebディレクター、Webデザイナー、フロントエンドエンジニアが会社にいます。
私がサーバーサイドエンジニアを選んだのは、以下理由からです。

・Webディレクター　・・・　(偏見かもしれませんが)技術力が身につかなさそうだと感じた。
・Webデザイナー　　・・・　デザイナーセンスが無いので、難しいと感じた。
・フロントエンドエンジニア　・・・　今までJavaScriptやCSSの勉強をあまりしてこなかった。
・サーバーサイドエンジニア　・・・　Ruby on Railsの勉強をしていたし、AWSの資格もあった。

フロントエンドエンジニアとサーバーサイドエンジニアで悩みましたが、元々技術力は無く、転職活動でアピールできる材料も少なかったのでサーバーサイドエンジニアを選択しました。(後々、フロント側も学んでいきたいと思っています)

入社後、はじめての仕事？

転職して直ぐに仕事ができるワケも無く、最初にやったのは課題でした。

課題

　課題内容：
　　AWS S3に特定のファイルがputされた時に、lambdaを動かしてSNSで通知する。
　　使用言語：Python3

感想

この課題を貰った時、AWS lambdaなんて触った事も動かした事も無かったので、最初は戸惑いました。しかし、AWSなんて前職だと触る機会が(もしかすると一生)無かったので、その機会がいきなり貰えた事は嬉しかったです。

Python3も初めて使った言語でした。RubyやJavaなら少しは書いた経験があるんだけどなぁ・・・とは思いましたが、lambdaがRubyに対応していないのと、Javaだとパフォーマンスが悪いとの事なので、Python3を選択しました。
(Nodeも選択肢にありましたが、先輩がPython3がいいよと助言してくれたのでPython3を選択しました)

プログラム完成後は、Git/GitHubを使って『クローン→コミット→プッシュ→プルリクエスト→解答→再コミット→再プッシュ→プルリクエスト返信』の流れを初めてやりました。 Git/GitHubも前職だと使う機会が無かったので、この時点でのカルチャーショックは凄かったです。

学んだ事

1) Pythonは、少しRubyと似てる？
PythonもRuby同様に動的型付け言語なので、Rubyと似た感覚で使う事ができました。ただ、Python固有の書き方もあるので、ちゃんとした勉強が必要だと感じました。現在は以下の本を読んで勉強中です。

みんなのPython 第4版

2) Git/GitHubのコメントの付け方
Gitについては「わかばちゃん本」で学習していたので、特に詰まること無くできました。(「わかばちゃん本」を読んでおいてよかった・・・)
ただ、commit時のコメントの書き方は、どうしたものか・・・と悩んだので以下を参考にしました。
qiita.com

3) AWS lambdaはローカル環境を作って動かすことができる
AWS lambdaを自分のPC内でローカル環境を作って動かせる事を知りました。ローカル環境の作り方は、以下を参考にしました。 dev.classmethod.jp

今後について

今後は可能な限り仕事で学んだ事は、こうやってブログに書いていきたいと思います。
同じ様な事をmochikichiさんがやられており、毎週ブログに書かれていて本当にすごいなぁと思いました。mochikichiさんの様に毎週ブログに書けるかわかりませんが、可能な限り私も頑張りたいと思います。
mochikichi.hatenablog.com