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

34歳で技術力が無くて不安を感じていた人がWeb系エンジニアに転職した話

はじめに

この度、約11年程いた会社から新しい会社に転職しました。
34歳になってからのはじめての転職です。

前職は客先常駐で金融系のSE(システムエンジニア)をしていたのですが、以下の悩みがあり「Web系のサーバーサイドエンジニア」へと転職しました。同じような事で悩んでいる方々の参考になれば幸いです。

[転職前の悩み]

• もうすぐ子供が産まれるけど、子育てをする余裕が無い。
• 今の職場で働いていても技術力(プログラムを書く力）がつかない。
• もし、今の会社が潰れた時に周りにアピールできる技術が無くて不安。
• 技術について話せる人が周りにいない。
• 自分の考えが上司に理解されず、職場移動をしてもらえない。

前職の内容と自身の思考について

客先常駐で金融系のSEをしていました。ネット上で良く話題に上がるSESですね。
SEとしてプログラムを書いていたのは入社してほんの2〜3年です。その後はマネジメントとして、ずっとリーダー業務をしていました。
マネジメントやリーダー業務と聞いて、イメージが沸かない人のために簡単に言うと「お客さんと話して、案件を貰って、開発作業をメンバー（パートナーさん）に振る」事をしていました。簡単そうに見える仕事ですが、これらを3〜4つ並列で行い、加えてお客さんからの急な依頼や問い合わせ等も発生するため、メンバーの進捗や工数(作業に掛かる時間やお金)を管理して、お客さんへの報告や課題の共有等を行う事が私の仕事でした。

「この仕事自体に不満はありませんでした。」と言えば、それは嘘になりますが、無数に降ってくるお客さんからの依頼や作業に対して、誰かが管理し、お客さんと話をしなくてはいけないので、仕事のやりがいは感じていました。

ただ、この仕事を続けていても他に潰しがきかなくなるのでは？という、ざっくりな不安というものは感じていました。
例えば「プログラムを書いていた経験が殆ど無いけど、それが無くても通用していたのは金融系でレガシーな技術しか使われなかったからではないのか？」「最近では金融系でもAWSやIoT等の新しい技術が使われはじめているけど、それについていけるのか？」「もし、今の会社が潰れた時に目に見える技術力が無いけど大丈夫なのか？」等です。

こういった不安から、もっと人の目に見える潰しのきく技術力を身につけよう。と考えていました。

転職を決めたきっかけ

転職をしようと思ったきっかけは、以下の３つです。

「もうすぐ子供が産まれるけど、子育てをする余裕が無かった」
前職は、通勤に01:40程掛かり、出社時間が08:40だったので07:00には家を出なくてはなりませんでした。 そうなると、朝は06:00前には起床する必要があり、帰りも遅い事が多いので、この生活を子供が産まれてからも続けるのは無理があるなと感じていました。

「職場移動ができない」
転職を考える前に職場移動の希望を会社に出しましたが「リーダーポストにいて、お客さんから信頼を得ている人を簡単に移動する事はできない」との事で、職場移動は何年も先になる（事実上不可能？）との事でした。

「会社、会社の上司との考え方が合わない」
会社自体の方向性もそうでしたが、会社の上司とも考え方が合いませんでした。私は「技術力を身に着けたい（プログラムを書きたい）」と上司に相談しましたが、「そんなものは会社は求めていない。プログラムを書くのはパートナーの仕事だ。」と一蹴されました。

一番大きかったのは、自分の考えと会社（上司）との考え方が一致していない事でした。
ここから私の転職活動が始まりました。

転職してどう変わったのか

転職活動を経て、無事Webエンジニアとして働く事になりました。
プログラムを書く技術が殆ど無いにも関わらず、採用(オファー)して頂いた今の会社には感謝しかありません。まだ、働いて2週間ですが、こんな感じに変わりました。

出社時間：　08:40　→　10:00
通勤時間：　01:40　→　01:00
仕事内容：　リーダー職　→　サーバーサイドエンジニア（プログラマー）
自分の席：　ない　→　ある

出社時間が遅くなったのと通勤時間が短くなったので、これなら子供が産まれても色々と余裕がありそうです。

仕事内容が変わった事が一番大きく、前職では1日の半分以上が打合せだったのですが、今ではゼロです。自席でずっとプログラムを書く生活に変わりました。

前職は客先常駐だったので自分の机というものが無かったのですが、今は受託開発の会社なので自分の机があります。これも大きく変わった事の１つです。

で、転職して良かったの？悪かったの？　今後はどうしたいの？

今はまだ働き始めて2週間なので、転職して良かったかどうかの判断は保留にしたいと思います。まずは1年を今の会社で働いて、それから結論を出したいと思います。

あと、今後は転職前から考えていた通り人の目に見える潰しのきく技術力（プログラムを書く力）を身につける事を目標にがんばりたいと思います。まだ転職したてなので、偉そうな事は言えませんが、30代で同じ様な事で悩んでいる方々の参考になれば良いかと思います。

[余談]その後の前職について

私が「技術力を身に着けたい（プログラムを書きたい）」と言った事に対して「そんなものは会社は求めていない。プログラムを書くのはパートナーの仕事だ。」と上司に言われた前職ですが、今では社員に技術力（プログラムを書く力）を身に付けさせようと色々と体制変更を行っている様です。
というのも、私が感じていた不安の通り？なのか、会社自体に技術力が無くて、今後の仕事が取れない（かもしれない）事を懸念しての体制変更なんだとか・・・
可能であれば、もっと早くに手を打って欲しかったなぁと思うばかりです。

Amazon echo dotのリマインダー機能で、薬の飲み忘れが極端に減った話

Amazon Echo Dotを購入して、約4ヶ月が立ったので、使用感と便利なリマインダー機能について書いていきたいと思います。

Amazon Echo Dotとは？

Amazonが販売しているスマートホーム。人の声に反応して、様々な情報を返してくれる便利なガジェットです。最近では、液晶画面付きのものも販売されている様ですね。

Amazon Echo Dot(液晶画面なし)

Amazon Echo Spot(液晶画面付き)

スマートホームを購入理由は？

約5ヶ月くらい前、のぼりーさんのクラウドインフラPodcastの『Event-01 Alexa Day 2018 出張インタビュー(神戸で行われたAmazon Echoを使ったTech Conferenceの話』を聞いて、スマートホームに興味を持ち、「面白そうだなぁ使ってみたいなぁ」と思ったのが購入のきっかけです。なので、ちょっとした玩具感覚での購入だった事もあり、GoogleHomeよりも安価なAmazon Echo Dotを購入しました。

意外と便利に感じたリマインダー機能

スマートホームは声に出すだけで、音楽をかけてくれたり、タイマーのセットや天気や交通情報を教えてくれるのは、とても未来感があって新鮮に感じました。中でも重宝しているのはリマインダー機能¹です。
僕は毎朝、薬を飲んでいる（飲まなくてはならない）のですが、これがなかなか継続できなくて困っていました。朝御飯食べた後に薬を飲む。という事が頭の中でわかっていても、朝は出社の準備等に夢中で余裕が無く、つい忘れてしまう。というのが良くありました。(意外と同じ様な方々は多いのではないでしょうか？)「毎朝、誰かが薬を飲む事を教えてくれないかなぁ」と調子の良い事を考えていたら、Amazon Echoにデフォルトでリマインダー機能が付いている事に気づき、さっそく登録して使ってみました。

すると、なんという事でしょう。
毎朝、僕が朝食を食べている時間帯に、Amazon Echoが、薬を飲む時間だと教えてくれるじゃありませんか!!

以降、タイトルの通り薬の飲み忘れが極端に減り、最初は玩具感覚で購入したスマートホームが意外にも生活改善の役に立ったというお話でした。

あと、リマインダー機能を使っていて面白い事が起きたのでこちらも書いておきます。
最初リマインダー機能に「○○さん、薬を飲む時間です。」と登録していたんですが、Amazon Echoは「○○さん薬 （やく）を飲む時間です。」と言ってきて、ビックリしたので前に「お」を付けて「お薬を飲む時間です。」に変更しました。いや、うちの奥さん大爆笑してましたけどね……（第三者が聞いてたら誤解されそうです（汗））

---

1. Amazon echoデフォルトの機能で、日付と時間とリマインドして欲しい内容を登録すると、登録した時間にリマインドした内容を声に出して読み上げてくれる機能です。↩