勉強会で登壇してきた話

先日、DevLOVEというエンジニアの外部の勉強会で「越境」をテーマに初めて30min セッションでトークをしてきた。

詳しい内容は会社のブログで書くのでここは書かないが、勉強会に登壇した思いだけ残したい。

この半年の自分の目標として、「アウトプットしていく」という課題があった。アウトプットというと少し抽象的だが、自分がやろうとおもったアウトプットは「OSS活動を頑張る」、「ブログ、勉強会等でやっていることを出していく」ということを主に掲げていた。そんな中、CTO経由で「勉強会登壇の話があるんだけどどうかな？」というありがたいお話を頂いた。その時期は少し忙しく、うーーーんと迷ったのだが、目標にもかがけてるし、せっかく頂いた有難いお話なので、全力で乗っかるかという気持ちで「やります！」と答えた。

やってみて結局資料の作成もギリギリになってしまったけど、イメージした形に近い発表はできたし、その会場で他の方の様々な学びある発表を聞けたので今となっては良かったと思う。 発表の前とか緊張するし、不安な気持ちはあったのだけれど、自分が話したことが誰かのためになるならいいやという心境で、悔いなく話すよう努められた。

また余談だが発表の時間配分もうまくいったし、質問もたくさん出たので、初めての登壇にしては発表はそこそこうまくできたのではないだろうか。

とまあ、振り返りとしてはこんな感じ。 目標を目指すべきところとしておいておくだけでなく、しっかり実現していけるように軽いフットワークで今後も頑張っていきたい。

ポエムになってしまったけどそんな気持ち。

バックエンドエンジニアとしての行いと評価

ちょっと前だけど自分が主担当ではないサービスのログ監視を強化したことがあった。強化しようとおもったきっかけは垂れ流しになっている5xxエラーを見て、これらのエラーはユーザに取って良くないという意識というか空気づくりとサービス品質の向上のためだった。

監視をするとやはりある程度の5xxエラーを検知したという通知が飛んできた。ユーザにとってよくない体験が起こっているので、優先度高めで修正するほうがいいと思うけど長く放置されているエラーだとユーザから問い合わせがなかったら「シュッと直すぞ！」っという空気にはなかなかなりにくい。またこれも差し込みのタスクだし、他の予定されたタスクがあれば尚更だと思う。一時期は自分が関わっていたサービスだから自分の責任もあるだろうし、自らやった反面急いで直したほうがいいと力説するのも違うなと思い、とりあえずエラーを修正したPRを出した。翌日主担当のエンジニアに修正を取り込んでもらって本番化され、しばらくの期間動いてなかった機能がちゃんと動くようになった。5xxエラーも減ったし良かったと思う。　

そんな感じでちょっとずつサービス品質向上させねばと努めていた時期があった。自分としては

• エンジニアのエラーログに対する意識向上
• アプリケーションの異常検知する体制の強化
• エラーでサービスの一機能に満足に使えなかったユーザの体験を変えた

などの効果はあったんじゃないかと思うし、個人的な振り返りとしても今思うとアンテナ張って能動的に取り組んめてたとは思う。自分で良かったと思うことなので自己満かもしれませんが。

とまあその話を酒の席でする機会があったのでしてみたら「それじゃダメで、みんながそれをできるようにならないとそこまでの行為とは言えない」というお言葉を頂いた。そういう見方もあるのかと思いつつも、そこまだダメかなーってしっくり来なかったのであたまの片隅でもんもんと考えていた。

しばらく考えて自分なりにこうなのではみたいなのが考えがまとまったので忘れないようにブログに書いておく。

バックエンドエンジニアとしての行いが良かったかどうかみるには

• サービスの品質向上に努められているか
• パフォーマンスがでているか
• 安定・安全に運用していけてるか
• etc...

など至ってシンプルで、数値(監視グラフなど)として良くなってるかとどうかでも見ることができると思う。そう考えた時に今回悪かった数字が改善されたのだからやった行いとしては間違ってなかったと思う。でも人に教えるという行為も育成という面では大事だともちろん思う。サービスの品質を改善した行為と技術的なことを教えるという行為を一緒に評価するのではなくて、それぞれ別軸で加点要素としてみていったほういいのではないかな。両方できたらパーフェクト文句のつけようの気持ちで前向きにプラスに考えて行きたい気持ち。

目標調整

年明けに出勤日は毎日ブログを書いていくぞ宣言をしましたが、体調不良でまともに記事がかけませんでした。

何らかの影響で記事書けない日がでてしまうことは今後もありうるので、これからは週1-2ぐらいを目処に更新していくのをマストにブログを書いていきます🙏🏻

kramdownというgemについて調べる

最近kramdownというgemを触る機会が増えてきたのですが、使い方など参考にしようとググっても実際に使ってみた例などあまり多くはないようなので公式のドキュメントを参考にしつつ、実際に使ってみようと思う。長くなりそうなので今回は簡単な紹介だけします。

github.com kramdown.gettalong.org

kramdownとは

githubのdescriptionによると

kramdown is a fast, pure Ruby Markdown superset converter, using a strict syntax definition and supporting several common extensions

と書いてあって、稚拙ながら直訳すると「pure rubyで書かれているmarkdown上位変換機能で処理が早い。厳密な構文を使って、幾つかの共通拡張をサポートしています」みたいな感じに書かれています。「???」みたいな気持ちになったので公式サイトの方を見たらわかりやすい図がありました。

参照: https://kramdown.gettalong.org/

要するに様々なインプットに対して、様々なアウトプットへの変換をサポートしているらしいです。2017年1月時点だと

• input
  • kramdown
  • Markdown
  • Github Flavored Markdown -HTML
• convert
  • HTML
  • LaTeX
  • kramdown
  • RemoveHtmlTags

以上には対応しているそうです。便利。

簡単ですが最近使っているgemの紹介でした。明日は実際に使ってみた例を書いていきます。

【MySQL】idカラムをとりあえずつくる

私は新規で作成するテーブルにはほぼ必ずidカラムを作成しています。定義は以下のような感じです。

`id` int(11) NOT NULL AUTO_INCREMENT, ... PRIMARY KEY (`id`)

自分がidカラムつけるのは主に、データ量が膨大なテーブルを扱う時にシーケンシャルな処理ができることです。 実装をそのidを基準に処理をかけばrow readsが少なくDBに優しい処理をかけます。

例えばPKがある場合

1. idを1から1000までを取得する

SELECT * FROM hoge WHERE id > 0 ORDER BY id asc LIMIT 1000;

1. 次に1001から2000までを処理する

SELECT * FROM hoge WHERE id > 1000 ORDER BY id asc LIMIT 1000;

みたいな処理をかけば、row readsは1000になると思います。これが例えばindex key基準に処理した場合そのindexでヒットする件数分row readsになると思うので良くないなという時があります。idを追加した場合のデメリットは、その分のデータ量が増えることかとおもいますがそれを許容できるような条件ならば追加しておいても損はないかなと。

ここ数年でRailsプロジェクトに関わるようになったのですが、Railsもmigrationでテーブル作成するとidカラムは自動でついてくるみたいでちょっぴり嬉しい。

勤怠のChrome拡張を社内向けに公開する

先日勤怠のChrome拡張を作ったというブログを書きましたが、一人でしばらく使ってみて便利だったので今回社内向けに公開しようとおもって調べました。

macotasu.hatenablog.jp

社内向けに公開する方法

社内向け = 一部のユーザに限定して公開とした時に現状以下の選択肢があります。

• URLを知っている人のみの限定公開
• Trusted Testerというテスターのメールアドレスを明示的に指定し、彼らにのみ公開
• <ドメイン>のすべてのユーザに公開

今回は社内向けということでドメイン限定の方が都合がよかったのでこの方法を選びました。 ドメインで縛りをつけて公開する方法は公式ドキュメントのこちらに書いてあるのでそちらを参考にしてください。

すこしハマった点

ドメイン限定にしたい場合は、管理者権限が必須

管理者ユーザの方にコンソール上から「Chromeウェブストアに公開することを許可する」を有効にしてもらわないとドメインの選択肢がでてきません。ドキュメントよく読めばわかることですが、よく読まないと？？？ってなります。

必須項目のスクリーンショット入れ忘れに注意

ウェブストアに公開にするには1点以上のスクリーンショットが必須らしいのですが、この項目入れないでも公開ボタンが押せます。この項目を入れなかった場合に、ポリシーに反しているよっていう自動メールと思わしきものが飛んできますがどう読んでも文章が繰り返しの表現とか誤解を招く表現とかしか書いてなくスクリーンショットの問題じゃないか気づくのに難儀しましたが現状そこ以外問題なりそうな点はないので間違いないかと。(※スクリーンショットが必須という点は入力時にフォーム付近にカーソルをあてたらhover?で注意書きがでてきます)

2, 3度失敗したら人力によるチェックに移るらしく数営業日待たされるそうです。

. . . . . . . . . . . .

そして私は今待っています。 （泣）

もし急ぐような場合などでは、管理者だと電話やチャットでのサポートが受けられるそうなので、相談してみるといいのかもしれません。

2017年の目標

2017年になりました。年始めということで「今年の目標」と「エンジニアをすることについて」を書こうと思い筆を取った次第です。

今年の目標

• 出勤日は毎日ブログを書く
• 個人でwebサービス一個作る
• 基本情報技術者試験受けてみる

の３つになります。

出勤日は毎日ブログを書く

昨年の終わり頃に書いたブログは200日以上ぶりという感じで、「|'-') 今年一年何してきたか振り返れないやん？」みたいな気持ちになったし、対外的に見ても何してるかよくわからない人に見えたと思うので、今年はアウトプットしていこうという気持ちです。このブログはその初めということで。

また出勤日という括りにしているのは自分のルーチンとして生活に組み込みやすいからという意味以外はないです。

個人でwebサービスを一個作る

これは去年他の人のwebサービスを作成したのだけれど、それを経て自分もつくりたいなっていう気持ちからやろうと思った次第。

基本情報技術者試験を受けてみる

エンジニアとして今年で5年目になるのだけれど、基礎的な知識で自分がわからないところを明確にするために受けてみようかなという試みです。とりあえず有名な柏木先生の本を買ったのだけれど早速わからないところがあって何とも言えない気持ちになった！

新しい知識を学ぶ機会だと切り替えて引き続き頑張る

エンジニアをすることについて

今年も改めて自分がエンジニアをすることについて簡単に振り返ると、

• ものづくりが自分でできる楽しみ
• 学ぶべきこと多くて成長しかない

以上の２つかなと思います。

ものづくりが自分でできる楽しみ

やっぱり真剣にものづくりするのがすごく楽しいし、そういった環境に近い場所にあるエンジニアという職業は楽しみしかないなというところにつきます。自分で頑張った分だけスキル・できることも増えるし、努力した分だけより多くの表現ができるようになるのは楽しいかなと。

学ぶべきことが多くて成長しかない

この業界に身をおいて5年目ですが、自分がまだまだわからないことあるのにどんどん新しい面白い技術がでるので、常に新しいことに触れている感じで常に成長できるのではみたいな感じが面白い。頑張って成長するように努力はするけど、自分よりすごい人たくさんいてもう我以外皆我師みたいな感じで常に合掌して学ばせてもらっております。

以上です。 本年もよろしくお願い致します。