GitHubリポジトリにセキュリティ脆弱性の警告が表示された
GitHubでリポジトリ開いたらこんな表示が。
We found a potential security vulnerability in one of your dependencies. A dependency defined in Gemfile.lock has known security vulnerabilities and should be updated.
(翻訳)依存関係の1つに潜在的なセキュリティ脆弱性があります。 Gemfile.lockで定義された依存関係には既知のセキュリティ脆弱性があり、更新する必要があります。
クリックしてみてみると、sprocketsのバージョンが古いとのこと。
以下でアップデート。
$ bundle update sprockets
アップデートしたGemfile.lockをコミットしてpushしたら無事アラートは消えました。
まとめ
見たことない警告表示でしたが、2017年から運用開始された機能とのこと。
GitHubがユーザーコードの安全でない依存性を警告、コードの見つけやすさも改善
こういった形で通知してもらえるのはありがたいですね。
dotfilesリポジトリでPCの設定ファイルをクラウド管理する
最近vimの勉強をしてる中で.vimrcなどの設定ファイルをGitHubで管理する方法を知ったので記事にしようと思います。
dotfilesとは
dotfilesというのは「.vimrc」「.bash_profile」などの文字通りドットからはじまる設定ファイルを指します。これらの設定ファイルをローカルだけで管理するのは心もとないのでGitHubにリポジトリを作ってクラウド管理しようというものです。
この管理方法であればPCが新しくなっても環境設定をいちからやり直す必要がなくなります。
やり方
1. GitHubにてdotfilesリポジトリを作成する
GitHubにてdotfilesリポジトリを作成し、PCのホームディレクトリにしcloneします。
2. 管理対象のファイルをdotfilesディレクトリに移動
cloneしたdotfilesディレクトリに管理対象のドットファイルを移動します。以下のようにmvコマンドで移動してもいいですし、Finder操作でも構いません。
$ mv .vimrc dotfiles $ mv .bash_profile dotfiles …
僕はコマンド打つのが面倒だったのでFinderで複数選択してファイル移動させました。
※ うっかり秘密鍵などを移動してしまわないよう必ず目視確認しながら作業することをおすすめします。
3. シンボリックリンクを貼る
一つひとつのファイル、ディレクトリに対してlnコマンドでシンボリックリンクを貼るのは大変なのでこちらはシェルスクリプトを使います。このファイルもdotfilesディレクトリの直下においておきます。
#!/bin/bash for f in .??* do [[ "$f" == ".git" ]] && continue [[ "$f" == ".DS_Store" ]] && continue ln -snfv ~/dotfiles/"$f" ~/ done
4. GitHubにpushする
GitHubのdotfilesリポジトリにpushして完了です。
参考までに僕のリポジトリを載せておきます。
参考リンク
上記手順はこちらのリンクを参考に作成しました。 https://qiita.com/okamos/items/7f5461814e8ed8916870 https://qiita.com/b4b4r07/items/b70178e021bef12cd4a2
日々の運用方法
設定ファイルに新しい内容を記述したらcommitしてGitHubにpushします。また、新しいPCに設定を反映するときはリポジトリをcloneした上で上記手順の2と3を行えばOKです。
まとめ
バックアップという意味だけでなく、設定ファイルにいつどんな追加をしたのかが追えるようになるのは便利そうだと思いました。
リモートワークをやらない理由
うちの会社は基本的にリモートワークを積極導入していません。 もちろん災害時や悪天候、家庭の事情などでやむを得ない場合はリモートワークOKにすることはあります(この夏は35℃以上の猛暑日はリモートワーク推奨にしました!)が、積極的にやらない(やりたくない)と思っている理由について個人的意見をまとめてみました。
リモートワークのメリット
まず、言うまでもなくリモートワークには会社にとっても従業員にとってもメリットがたくさんあります。
- 通勤にかかる時間、エネルギーを節約できる
- 身だしなみに気を使わなくていい
- 同期型コミュニケーションが減るため作業に集中できる
- 子供が熱を出したとかに柔軟に対応できる
- 会社はオフィスの座席を用意しなくてすむ(フルリモートの場合)
- 採用の機会が広がる
などです。
リモートワークをやらない理由
ではなぜ積極的にとりいれないかというと、主に以下の理由です。
カルチャー醸成における不具合
急成長を目指すスタートアップ企業で働いているとさまざまなイベントが起こります。
- 移転してオフィスが大きくなる
- テレビに取り上げられてサーバーが落ちる
- 半年かけて作った新機能をリリースする
- KPIを達成して喜びを共有する
- キャッシュが尽きそうになる
このようなイベントを現場で体験できるのはベンチャーで働く上で大きな機会だと思います。
目の前の出来事に対してどんな判断をくだすのか、なぜその判断なのか、どんな温度感なのか等、その場にいるからこそ伝わる非言語情報がたくさんあります。そしてそれは同じ場所にいるからこそ価値観(=判断軸)として浸透し、それが組織のカルチャーとして形成されます。また働く個人にとってもそのような経験は暗黙知として資産になります。
価値観が浸透することでコミュニケーションコストが下がり、結果的にチームワークの生産性が上がることを考えると、リモートワークはカルチャーづくりという面で機会損失が大きいと考えます。
マネジメントと評価での不具合
- 報連相が適切にできる自立した人でないとマネジメントコストが大きくなる
- そういう意味で、社会人経験が浅いメンバーとのやりとりはよりコストが大きい
- また評価が成果ベースになるためプロセスが無視される
成果というのは適切な行動から生まれるので、役職的にマネージャーレイヤーより下に位置するメンバーに対しては結果だけでなく行動も評価してフィードバックをする必要があります。特にマイクロマネジメントが必要な新入社員や学生インターンに対してプロセスを評価してあげられないのは育成の機会を逃しているといえます。
コミュニケーション面での不具合
- 対面だと一瞬で済む内容の共有に時間がかかる
- 心理的安全性が低いチームだとよりつらみが大きい
例えばチームビルディングがまだ済んでいないチームは対面より更にやりづらさある気がしています。テキストでのコミュニケーションは対面より冷たく感じやすいので、ちょっとしたフィードバックでも受け手にとっては怒ってるように感じてしまうことってあると思います。そういう意味では少なくとも互いのことをある程度分かっていて気兼ねなく雑談できるような関係性ができていないと、コミュニケーションにかかるコストが大きいと感じます。
まとめ
デメリットにフォーカスして書きましたが、リモートワークはいい面もたくさんあります。会社として柔軟で多様性のある組織に成長するためにも避けて通れないとは思っているので、デメリットを回避する方法を考えながら部分的に取り入れていきたいと思っています。
July Tech Festa 2018に参加して戦略思考などについて学んできた
インフラの祭典July Tech Festa 2018に参加してきました。
一日を通して参加しましたが、各社具体的な事例をたくさん聞けて参考になりました。また技術以外にも面白そうなテーマについて扱ったセッションが多くありとても楽しめたのでメモしておこうと思います。
組織の生産性を上げる役割「VP of Engineering」とは?
メルカリ、ハートビーツ、Gunosy3社それぞれのVPoEが、役割と責務についてパネルディスカッション。
- 3社共通なのは技術の責任はCTO、組織づくりとマネジメントの責任はVPoE。
- ただし、VPoEにどこまで任せるかについては会社によって定義が結構バラバラ。
- VPoEが組織、マネジメントに加えて事業責任まで持つとなると組織がスケールするに従ってVPoEの責任がかなり大きくなってしまうというのはありそう。
- そんな中でCTO, VPoE, VPoPを分けて運用しているというGunosyの職務分担はうまく分けてる印象だった。解釈が合ってるかはわからないけどVPoEは縦軸(組織)の責任を、VPoPはを横軸(事業)の責任を負うというのは綺麗だと思った。
少し話はそれるけどIVSのCTONightで課題についてディスカッションすると毎回といっていいほど組織やマネジメント採用の話が上がってくるのは、CTOが実質VPoE職務を兼任するという企業が多いのだと思う。
急成長するスタートアップの開発組織においてCTOの責務がどうしても大きくなってしまう問題はあるので、組織の成長に応じてVPoEを役割として立てる会社が増えてくるのは合理的な流れだなと思う。
副業で収益化を目指す!月数百円から始めるWebサービスの立ち上げから運営まで
- 収益化するためにはとにかく支出を削る。(逆説的だが)そのためには身銭を切ってどケチになる。人は自分のお金じゃないと節約できない。
- 一人で作ることが大事。その理由は「人的コストが最小で済む」「意思疎通コストがゼロ」「リソースが最小のため単機能にせざるを得ない(運用・開発コスト減)」こと。
- 「大きな問題」は解こうとしない
中でも一人で作ることが大事という話は的を射ているなと思った。普段スタートアップをやってていかに人を巻き込むかばかり考えてるせいで忘れがちだけど、どこかでみたポール・グレアムの「スタートアップは避けられる限り採用するな」という主張ってまさにこういう事だった気がする。あと、大きな問題を避ける意思決定は後述する戦略話と重なるところがありおもしろかった。
イゼルローン要塞攻略に学ぶエンジニアの戦略思考
- 戦略は戦う前の話。戦術は戦う時の話。
- どのレイヤーの話をしているのかを意識するのは重要。
- ツール(戦術)にこだわりすぎると手段の目的化が起こって上位レイヤーの大切なことを見失う。
- 個人レベルの話でいうと特定のスキルだけ発達させる(芸の絶対化というらしい)のはキャリアを考えても危険
- 技術の変化が早く、習得したスキルがあっという間にレガシーになるIT業界では特に言えること。そのため常に成長し続ける工夫をすることが大事
- その上で何を学べばいいか、上位の戦略レイヤー(世界観、目指すべき状態)からブレイクダウンさせて考えよう
(スライドより参照)
普段よく使うけど言葉として正確に理解してはいない「戦略」について考えるいい機会になった。思考のフレームワークとしても戦略学、戦略のフレームワークは改めて勉強してみたいと思った。
ソフトウェアで構築する成長し続けるインフラストラクチャとメルカリの挑戦
- 最初はさくらのVPSでリリース
- JPリリースから1年半という恐ろしい速さでUS版リリース。
- チーム、組織のスケーラビリティを高めるためにマイクロサービス化
- QAとデプロイがボトルネックになりがちだったものをマイクロサービス化で解消
- 国によってAWS、GCPなど使い分けている
利用技術
- Container/Docker
- Kubernetes
- Spinnaker
- Terraform
まとめ
メルカリに限らずKubernetesについて取り上げてる会社が多く事例が沢山聞けて参考になりました。また、それ以外にも知らないサービスがたくさん聞けたのでキャッチアップしようと思います。
人見知りのための懇親会テクニック
勉強会やカンファレンスの懇親会が昔からあまり得意じゃないんですが、回数をこなすうちにそれなりに有意義な過ごし方ができるようになってきた気がしてます。
今週末もJuly Tech FestaというITイベントに参加するのですが、参加するにあたって自分なりに心がけていること結構あるなと思ったので、まとめてみようと思います。
事前準備
目的とKPIを決める
懇親会の何が苦手かって、中身のない会話を延々と続けることになったり、逆に誰とも話す機会を得られず孤独感を感じながらスマホをいじる羽目になったりすることなんですよね。
で、それを避けるには自分から話しかけることが大事で、目的を事前に設定し意識することで少なくとも漫然と過ごすことは防げるかなと思っています。
目的というのは例えば以下のようなものです。
- 勉強会の技術テーマをディスカッションを通して深掘りする
- 採用候補者を見つける。
- 会社やサービスの説明をしたりビジョンを話す練習をする。
で、KPIは上記目的を達成するために「5人以上に話しかける」とか「2人以上とランチの約束をする」とか定量的なものを設定します。
学生時代ティッシュ配りのアルバイトしたことありますが、目的があると不思議と人に話しかけるのって苦じゃなくなるんですよね。
自分がギブできるネタを用意しておく
こう書くと敷居が高い感じがしますが、要は自分の話せるネタを用意しておけばいいのです。
懇親会で初対面の人と話すときにやってしまいいがちな失敗が質問攻めです。これはシンプルに自分から喋れることがないから起こることだと思っています。
話し好きの相手であればそれでもいいのかもしれませんが、質問ばかりだと相手に得るものがないため辟易されてしまう可能性が高いです。
そうならないためにも自分が喋る内容を事前に準備しておくのがおすすめです。
- 名刺交換するときの自己紹介
- 仕事で取り組んでいること
- なぜこの勉強会に参加したのか
- 最近興味のある技術テーマ
などです。
これらを自分から先に話した上で相手にも問うのです。互いに興味のある話題につなげることができれば自然と盛り上がります。
ここで、話題としておすすめなのがその日の勉強会のテーマです。
事前に勉強会で扱われるテーマについて技術調査をし、知見を深めておきます。そのテーマに興味がある人ばかりが参加しているはずなので、こちらからギブできる話題としては絶好のネタとなり話も弾みます。
当日の動き
登壇者に話しかける
勉強会に参加するメリットとして、登壇者の生のスピーチを聞けたり質問できたりすることが挙げられると思いますが、懇親会はそのメリットを享受する絶好のチャンスです。
勉強会中登壇者の話でわからなかった箇所や詳しく聞きたいと思った箇所をメモしておき、懇親会のときに質問するのです。
登壇する立場からすれば、興味を持って話を聞きにきてくれる人には親切にしたくなりますし、スライドではオープンにしづらい裏話やスライドに盛り込めなかった内容とかも話したくなります。
またここで事前準備で調査しておいた勉強会テーマが生きてきます。質問するだけでなく登壇者と議論を深めることができれば間違いなく有意義なものになったと言えるでしょう。
食事に負けないようにする
これは半分精神的な話です。懇親会では大抵の場合軽食が出されますが、ここに罠が潜んでいます。
仕事終わりで登壇者の話をひととおり聞ききった後ということもあり、懇親会が始まる頃にはだいたいかなり空腹状態です。そしてそんな状態で目の前にピザがでてきたら本来の目的を忘れて食べることに意識が向いてしまいます。
さらに、料理を食べて満腹中枢が刺激されると今度は逆に落ち着いてしまいダラダラ過ごしてしまいがちになります。
なので、できれば食事はダラダラしないようサクッと済ませるか、食べないくらいのスタンスでいましょう。
コツとしては、あらかじめ空腹にならないような工夫をしておきます。勉強会に参加する前に自分で軽食をとっておくのです。サンドイッチとかカロリーメイトとかなんでもいいです。
話をうまく切り上げる
話を自然な感じでうまく切り上げるのって結構コツがいるなと思っています。特に相手に会話のペースが握られる事が多い人見知りとしては終わり時を自分から作ることが難しくなります。
話を切り上げる時は、話のキリがいいタイミングで以下のような文句を言ってからさっとその場を離れるのがおすすめです。
- 「ちょっとお手洗い失礼します」
- 「他の方にも挨拶してきますね」
- 「飲み物とりにいってきます」
- 「よかったらまたお話しましょう。Facebook申請してもいいですか?」
さっさと帰る
気分が乗らないときや、逆に今日はもう目的が達成できたと思ったときなど、これ以上得られるものがないと思ったらその時点でさっさと帰るのも大事なことだと思います。
別に最後までいなければいけないルールなんてないですし、早退したからといって主催者はほとんど気にしてないです。
ダラダラ過ごすことになるなら、その時間で家でコード書いたり技術書読んでた方がずっと有意義な時間になります。
まとめ
ということで、普段意識してることをまとめてみました。使ってみていただけると幸いです。
プルリクエストを出す際に意識してほしいこと
最近コードレビューをする機会が多いのですが、プルリクエストの中でもレビューしやすいものとそうでないものがある事を実感しています。
というわけで、レビュアーとしての観点からどんなプルリクエストだと助かるのかについてまとめてみました。上から重要だと思う順に書いています。
1. 何を実現したいのかを書く
そのプルリクエストで何を実現したいのかのインプット情報が多いほどレビューしやすくなります。例えば以下のような項目です。
概要、目的、要件、設計、テストケースetc...
また、併せてどのような観点でのフィードバックを求めているかも伝えられると親切です。
レビュアーに対してだけでなく、あとからチームに加わったメンバーが読んだときにも理解しやすくなります。
リポジトリ直下に PULL_REQUEST_TEMPLATE.md
という名前のファイルを配置することでプルリクエストをつくるときのフォーマットを設定できるので、運用の際はそれを活用するといいと思います。
2. プルリクエストの粒度はなるべく小さくする
変更の差分が数十ファイル以上もあるようなプルリクエストはレビュアーの精神をとてもすり減らします。
逆に粒度が小さいほどレビューする方も気持ち的に楽なのですばやく取り組むことができます。
感覚的には10ファイル以内に収めてもらえると助かります。
なぜプルリクエストが巨大になるのか?
設計が完了する前にコードを書き始めることがだいたいの原因かなと思っています。どこで分割していいかわからないまま結局一つのプルリクエストにすべてが収まってしまうのではないかと。
設計が完了してイシューが分割できていればプルリクエストも細かくできるはず。いやほんと、差分ファイルが多すぎるのは見るだけで疲弊します(切実)。
3. 自らコメントをつけておく
実装者がプルリクエストのレビュー依頼を出す前にあらかじめ補足事項や相談をコメントしておきます。例えば以下のようなコメントです。
- 「ここは◯◯の意図でこのような実装になっています。」
- 「ここはこうしたけど◯◯の点で問題はないでしょうか。」
このようなコメントはレビュアーの理解を助け、設計における建設的な議論にもつながるため積極的に行うべきだと考えます。
4. 綺麗なコミットログをつくる
プルリクエストの粒度を小さくしたほうがいいと書きましたが、やむを得ず差分の量が多くなってしまう場合もあると思います。
そういったときにコミットログが綺麗だとストーリーに沿って順を追ってレビューできるためとてもやりやすいです。逆に複数の変更内容を1コミットにまとめられるととてもレビューしづらいです。
コミットメッセージの内容
コミットログに書くコミットメッセージは以下のような感じでサブジェクトに「変更内容(What)」を、メッセージに「変更理由(Why)」書きましょう。変更理由があることで、ソースコードから書き手の意図を頑張って読み取るコストが省けます。
1行目:変更内容の要約(タイトル、概要) 2行目 :空行 3行目以降:変更した理由(内容、詳細)
まあこれら関しては正直毎回いちいち綺麗にするの大変なので、大量の差分が出たときだけはせめてやってほしいという感じです。
Status checkはクリアしとこう。
あれ、大丈夫?ってなるので。
クリアしてなくてもいいけど、その場合は理由を書いておいてもらえると助かります。
View変更のスクショを貼る
Viewを変更している場合はBefore, Afterのスクショを貼ってもらえると動作確認する手間が省けて助かります。
まとめ
少しの工夫を加えるだけで何倍もレビューしやすさが変わるので、ぜひ参考にしていただけると幸いです!
勉強を1日30分習慣化する方法
「1日30分を続けなさい!」という本を読みました。いかに勉強を習慣化し成果を上げるかについての方法論が書いてあり、勉強時間の確保に課題を感じる忙しいエンジニアにとっては特に参考になる本だと思いました。
「1日30分」を続けなさい!Kindle版: 人生勝利の勉強法55
- 作者: 古市幸雄
- 発売日: 2017/02/20
- メディア: Kindle版
- この商品を含むブログを見る
勉強の成果において一番重要なのは「勉強時間」
本書では長期的に勉強で成果を上げるために必要な要素は以下であるとし、特に勉強時間の確保が大事だとしています。
勉強の成果 = (教材の質) × (集中力) × (勉強時間の2乗) + (過去の勉強の蓄積)
教材の質よりも勉強時間の方が重要という点は言われてみればなるほどと思いました。
勉強の成果はしばらくすると累積効果が効いてくるので、ある一定の時期を過ぎると急激に勉強の成果が表れます。それは半年かもしれませんし、1年かもしれません。大切なことは、「勉強の成果はすぐには出ない」ということを知りつつ、日々勉強を続けることです。
脳科学の観点からも、知識が増えるほど脳が無意識にパターン認識できるようになるため勉強の成果は累積効果により勉強時間に応じて指数関数的に上がっていきます。そのため、最初はちんぷんかんぷんの内容も積み重ねることによってわからないことがある日突然わかるようになったりします。
習慣化するためには痛みを避ける
長期的に勉強時間を最大化するには習慣化することが不可欠です。本書ではそのための方法の一つとして不快な状態での勉強を避けることが大事だと述べられています。
脳の行動パターンは非常に単純です。
- 痛みを避ける
- 快楽を得ようとする
イヤイヤ勉強するということは、脳にとっては痛みになるわけです。すると、脳は痛みを避けようと、勉強をしないように指示を出し、勉強が長続きしなくなります。
これは非常に大事で、不快に感じることって無意識に脳が拒否するため習慣化できません。特に脳は変化を嫌うため新しい事をはじめようとするときはどうしても負荷を感じます。一度習慣化してしまえばなんということはないですが、新しく習慣を作ろうと取り組みはじめるときこそ気をつけなければと思いました。
また、本書ではこうも言っています。
長期間勉強を続けていると、どうしても「最近は勉強する気にならない」とか「気分が乗らない」という時期が必ず来ます。(中略)このような場合は、思い切って2~3日全く勉強に手を付けないことをおすすめします。そうすると、3~4日目には「最近勉強していないので、中期目標が達成できないぞ。まずい」という焦りの感情が起こりますから、そうしたらまた勉強を再開します。
まとめ
上記以外にも勉強を通して高い成果を上げるための具体的な方法論として、動機づけから時間の捻出方法、食事、睡眠のコントロールまでさまざまな内容が記載されておりとても参考になりました。
ちなみに本書では通勤時間にオーディオブックを聞くという勉強法がありましたが、過去に書いたKindleの読み上げ機能がとても役立つと思ったのでリンクしておきます。 katsuki.hatenablog.com
ということで、総じていい本でした。特に資格試験を受ける人や勉強を習慣化したい人にはご一読をおすすめします!
感謝を込めてKobitoのデータを移行した
KobitoというMarkdownエディタをスニペットツールとして愛用しているのですが、2017年の12月にサポート終了し新たなダウンロードもできなくなったのですね。
まあそれ以降も気にせず使っていたのですが、新しいPCを購入したため中のデータを別のツールに移行せざるをえなくなりました。
どうしたものかと思いとりあえず検索してみたところ、同じ課題を自作スクリプトで解決している方を発見。 https://qiita.com/jnchito/items/3a6861c179e2ab4a28a2
QuiverというMarkdown形式対応のメモアプリに移行するというものです。
早速スクリプトをCloneし、動かしてみました。
手順
1 ) 手元にソースコードをCloneする。
git clone git@github.com:JunichiIto/kobito-to-quiver.git
2 ) リポジトリのルートに移動し、Kobitoのバックアップデータを所定ディレクトリにコピー
cd ~/kobito-to-quiver
cp ~/Library/Containers/com.qiita.Kobito/Data/Library/Kobito/Kobito.db ./db
3 ) gemをインストールし、バックアップデータをもとにoutputディレクトリにMarkdownファイルを生成
bundle bundle exec rake export
4 ) Quiverを起動 > File > Import > Markdown で、上で生成したMarkdownファイルをすべてインポートする。
5 ) 上記によりQuiverデータとして生成されたqvnotebookディレクトリの名前を確認(6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebook
のような名前のものがそれ)
ls -lt ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/ | grep .qvnotebook
6 ) 所定のqvnotebookディレクトリ配下に、上記ディレクトリをコピー
cp -r ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebook ./qvnotebook
7 ) 記事タイトルとタグを更新する処理を走らせ、Quiverデータにコピー
bundle exec rake update_qvnotebook cp -rf ./qvnotebook/6E2E7794-D4B5-48F6-AB34-B8DBB09DB2EB.qvnotebook ~/Library/Containers/com.happenapps.Quiver/Data/Library/Application\ Support/Quiver/Quiver.qvlibrary/
無事、Quiverに移行完了しました!ちなみにruby2.4以上と書いてましたが、ruby2.3.3でも動きました。
Kobitoのおかげで得られたもの
Kobitoはスニペットツールとしてとても重宝していましたが、それだけでなくQiitaに投稿するきっかけを作ってくれました。
記録したメモをワンクリックでQiitaに投稿する機能があるため、メモった内容をカジュアルに公開することができるのです。気づいたらKobitoにメモった技術調査の内容やスニペットをQiitaに公開するのが習慣になっていました。
おかげで過去たくさんのリアクションをもらう事ができました。中には感謝のコメントをくれる人や間違った内容を指摘してくれる人もいて自らのアウトプットを世の中に公開する意義を大いに感じることができました。
人から反応をもらえるのは励みになります。 些細な内容だとしても、世の中に1ミリでも還元できているという実感が得られるからです。
KobitoとQiitaがあったから、些細な内容でも恥ずかしがらず公開してみよう!というメンタリティを得られたように思います。
サービスとしては終了してしまったKobitoですが、得られた教訓を胸に今後もアウトプットを続けたいと思います。
開発チーム勉強会はじめました
先月から新しい取り組みとして隔週に1度の開発チーム勉強会をはじめました。輪読会形式で進めているのですが、なかなかいい感じに進んでいるのでどんな風にやってるか紹介します。
やり方
各回テーマに応じた内容について書籍を使って学習します。
1. 勉強会の日時、テーマを決める
- 業務時間内でみんなが集まれる日時を決めます
- 学びたいテーマをメンバーからヒアリングして決めます
2. 参加者に本を配る
- テーマについての書籍を会社で人数分購入し、参加者に配ります
3. 当日までに読んできてもらう
- 業務時間内に読んでもらっても構いません
4. 当日、学びになった箇所についてディスカッション
- 読んできた内容で印象に残った箇所や学びを自由に発表し合います。
- 最後に次回のテーマと日時を決めて終わります。
どんなテーマにするか
以下にのような内容がいいんじゃないかと思っています。
- 直近の仕事で取り組むべき課題に関するもの
- チーム全体で伸ばしたいと思っている技術
- その他一般的にエンジニアとして身につけておくべきスキル etc....
なぜ輪読会か
一番の理由は準備が比較的楽だからです。参加者は最低限渡された本を読んでくればいいので準備が大変で続かないという事が生じにくいのではないかと思っています。
また、以下のような効果も感じています。
発表を通して学習効果が高まり新たな視点が得られる
輪読会のいいところはただ書籍を読むよりもインプットした知識の理解が深まることです。人に説明する行為を通して情報が頭の中で整理され、より深く記憶に定着します。また、自分とは異なる視点からの意見を聞いたりディスカッションしたりすることで知識が強化され、多様な考え方を身につけることにもつながります。
チームのコミュニケーションの質向上
さらに、実際にやってみて気づいたはチームの共通言語ができることです。コミュニケーションがより円滑になる効果もあると思いました。
例えば先日輪読した書籍に登場した「ウィルパワー」という言葉。これは意思決定をするたびに消耗するエネルギー的な意味を持つ言葉なのですがこれが共通言語化することで「そこにウィルパワー割く必要ある?」とか「その設計は読む人のウィルパワー消費するからよくない」などの使い方が通じるようになります。
チームの言葉が増える → コミュニケーションの質&スピード向上
となりとてもいいなと思いました。
成長に寄与しよう
このようにまだ始めたばかりですが、いまのところ楽しくやっています。
ペライチには大切にしているカルチャーの一つに「成長に寄与しよう」というのがあります。今後もメンバー一人ひとりがエンジニアとして成長できる環境を整えていくためにこういう取り組みをどんどんやっていきたいと思います!
エンジニアインターンの研修用教材としてProgateがめちゃくちゃ使えそう!
久しぶりに会社にエンジニアインターンが入社することになったので研修教材を探したところProgate がよさそうだったので使ってみることに。試しに自分でも触ってみましたが、特に初学者向けの教材としてとても使えそうだと思いました。
Progateの特徴
環境構築が不要
自前で開発環境構築などが必要なく、PCとインターネット環境さえあればブラウザ上で利用できます。
UIはこんな感じ。
イラストでわかりやすい
解説がイラストつきでとっつきやすいです。ふしぶしにゆるいキャラクターが登場し、とにかくプログラミングに対してハードルを下げようという姿勢を感じます。
フィードバックをくれる
何が間違っているのか具体的にフィードバックをくれるため、何がわからないのかわからなくてハマることがほぼありません。
安い
法人プランは一人当たり1480円/月です。安い。
いままで使ってた教材の難点
以前はドットインストールを使っていましたが、以下の問題がよく発生していました。
- 序盤の環境構築でハマって進めなくなる
- 問題の原因がわからないので自力で調べることが困難
- そのためリモートで進められない
特に初学者は何がわからないのかもわからない事が多いのでトレーナーがそばについてナビゲートしないといけない事が多いです。正直トレーナーにとってもそれなりの負担がかかります。
それに対してProgateの場合は上述の特徴があるため細かいところは一旦おいといてサクサク進められます。人に聞かなくていいから心理的に楽だしモチベーションが継続しやすいと感じました。
まず全体感を知ってもらうというやり方
全体を把握できない中で学習の本筋ではない部分でハマり、暗中模索する作業はとても辛いものがあります。
それを解消するためにも細かい事は置いておいてまず一周してもらい全体感を把握してもらう。そんな使い方に最適だと思いました。
場合によって使い分けられるといいかも
上述でドットインストールを下げた感じになってしまいましたが、要は以下のように場合によって使い分けができればいいのかなと思っています。
- 全くの初学者: Progate
- 開発経験あり: ドットインストール, Udemy etc
書籍や動画などの情報が一方向的な教材でも、ある程度わからないことを調べるスキルがあれば有効に使いこなせるはずです。
ということで、さっそく試してみます。ほかにいい教材知ってる方教えて下さい!
7日間断食して得られたもの
断食といっても正確にはファスティングという水と酵素ドリンクだけで過ごすやつを7日間行いました。
2月に受けた人間ドックで脂肪肝と診断されたのでよくいく鍼灸の先生にその話をしたところ、ファスティングやれば?といわれて興味を持ったのがきっかけです。
結論からいうと当初の目的だった脂肪肝とかどうでもよくなるくらいいろんな変化がありました。
やったこと
まずトレーナーを探した
ファスティングは素人が単独でやると危険なこともあるので、まず適切な指導をしてくれる専門家の人を見つけなければいけません。僕はネットで見つけた断食メガネさんという専門家の方に教えてもらいながらやりました。後から知ったのですがメガネさんはペライチのユーザーさんでした。
スケジュール調整
ファスティングはざっくりいうと 準備食(2日間) → ファスティング(7日間) → 回復食(3日間) という流れで行います。
期間中は外食ができないので、飲み会やランチが入れられずいろいろ調整する必要がありました。振り返ると断食よりここの調整が一番大変だった気がします。
いよいよ断食開始
準備食(2日間)
ファスティング中は肝臓が忙しいため、前段階で肝臓に負担がかからない食事をとって極力肝臓を休ませます。具体的には添加物の多いお菓子スイーツ、お酒、カフェイン、肉、魚、卵、動物性たんぱく質、揚げ物などを避けます。必然的に病院食みたいな感じの食事になります。
ファスティング(7日間)
準備食期間を終えたら本格的にファスティング開始です。期間中に摂取するのは以下だけ。
- 水
- 酵素ドリンク
- 塩
酵素ドリンクというのは、なんか乳酸菌とかが入ってて腸内環境良くしてくれる&最低限のブドウ糖が摂取できるようになってる飲み物です。
ファスティング期間は人によっては3日間や5日間で行うみたいですが、メガネさんによると3日目から本格的に脂肪が燃焼しはじめるという話だったので、僕は思い切って長めの7日間とりました。
回復食(3日間)
ファスティング後に直後にいきなり体への負担が大きいものを食べると倒れたりするそうなので、準備食同様やさしいものを食べます。
どんな変化があったか
さて、結論まで長くなってしまいましたが、断食することでどんな変化があったか書きます。
- 体重: 79.5kg → 73.4kg
- 体脂肪率: 18.2% → 12.8%
結論、めちゃくちゃ痩せました。
それも筋肉はあまり減らず脂肪が減るという嬉しい結果に。ビジュアルの変化としてはお腹まわりの脂肪がすっきりなくなり、シックスパックが出てきました。
ジムでの計測ですが、当初の目的である内臓脂肪が減少し、ウエストも引き締まっていました!
体型以外に起こったさまざまな変化
上記の変化以外にも、ファスティング中は思いもよらない変化が沢山ありました。
- 日中の集中力が高まった
- 慢性疲労や慢性咽頭炎がなくなった
- 睡眠時間が減り、寝覚めがよくなった
- メンタルが安定し、ぶれることがなくなった
一番驚いたのは、数ヶ月悩まされていた慢性的な疲労感がなくなったことです。むしろ体力が有り余りすぎてファスティング中は毎朝欠かさず5km〜8km走ってから出社してました。消化にエネルギーを使わない分睡眠の質が高くなり、短時間睡眠でもすっきり目が覚め、まるでスーパーマリオ状態でした。
ケトン体質になるおかげでいいことが起こる
ファスティング中は体内のブドウ糖が枯渇するため、代わりに脂肪酸から作り出されるケトン体をエネルギーとします。ケトン体が脳に入るとα波の分泌が高まり高い集中力が保てることがわかっています。
さらにケトン体は脂肪酸から作り出されるため、期間中はボーナスステージのようにカロリーを消費すればするほど脂肪を燃焼する体質になります。これが運動すればするほど驚くほど脂肪が落ちるしくみです。
そして、胃腸が休まることで腸内環境が整うため、幸福ホルモンであるセロトニンや快楽ホルモンのドーパミンが分泌され、自律神経が整いメンタルが安定しさまざまな不調が改善されます。
ファスティングはダイエットの文脈で語られることが多いですが、本来は健康法の一種です。胃腸を休め、ホルモンバランスを整え、免疫細胞の生まれ変わりを促進することで体に蓄積された毒素を排出します。
今回とてもよかったので1〜2年に一回くらいは体の大掃除のつもりでやってもいいかなと思いました。
20代の若手エンジニア向けにキャリアについて話してきました
というイベントで20代のエンジニア向けにお話してきました。
「会社員 → フリーランス → スタートアップ起業」というキャリアを通じて学んだことや自分が若手エンジニアだったらどのように過ごすかという軸でお話してきました。 短い時間だったので多くの内容は話せませんでしたが、参考にしてもらえたらうれしいです。
発表資料
キャリアについて考えるということ
自分が若い頃は正直それほどキャリアについて細かく考えていませんでした。ただ新卒で会社員になる前から20代のうちに起業するという方向性は胸に抱いていたため、それに向けて何が必要かを考えながらいろんな選択をしてきた気がします。
遠い未来に自分がどうなっていたいか具体的にイメージするのは難しいかもしれませんが、エンジニアとしてどういう方向性を目指すかというざっくりした指針くらいは考えておくといいのかもと思います。
iPhoneの読み上げ機能で読書量が2倍になった
昨年末から友人に教えてもらって使いはじめたんですが、iPhoneの機能に「スピーチ」というのがあります。
文章を読み上げてくれる機能なんですがこれが素晴らしく便利で、まるでオーディオブックのようにKindleの内容を読み上げてくれるんですね。
知ってから使わない日はないくらい便利なので、記事にしてみました。
何がいいのか
一言でいうと「とにかくスキマ時間を活用してインプットできるようになった」ということに尽きます。
例えば家から駅までの徒歩移動中や家事をしてるときって、考え事とか音楽聴くとかしかできなくて結構ストレス感じてたんですね。そういう時間を有効に使えるようになったのは大きいです。
また、体感として活字を読むよりも聴く方が圧倒的に楽なので、疲れて気分的に本読むのがおっくうなときとかもインプットできるというのは助かってます。
どんな時に使うか
以下のタイミングで使っています。スキマ時間はだいたいKindleを聴くようになりました。
- 徒歩での移動中
- ジムでのトレーニング、ランニング中
- 朝の支度中や食事中、入浴時
- 疲れてて本をよむ気分にはならないけど手持ち無沙汰なとき
使い方
- 設定アプリを開く
- [一般] > [アクセシビリティ] > [スピーチ]へ移動
- [画面の読み上げ] をONにする
これで設定完了。あとはKindleで読みたい本を開いて2本指で上から下にスワイプすれば読み上げ開始してくれます。読み上げスピードも自由に調整できて便利。
どんな本に向いているか
スピーチ機能で読み上げる本には向き不向きがあります。
頻繁に立ち止まって精読する必要のある難解な本や、技術書などは向いていません。またマーカーを沢山引いて勉強するぞ!みたいな場合も向いてないと思います。
向いてるのは活字でも読みやすい本です。僕の場合ビジネス書やライトめの自己啓発書が多いです。例えば今年に入ってからは以下を聴きました。
全部積読してた本です。嬉しい!
ちなみに、Kindleだけじゃなくてブラウザで開いた記事の読み上げとかにも使えます。
読み上げの弱点
スピーチ機能にはいくつか弱点があります。
まず、読み上げスピード自体は活字で読むよりも遅いです。読書できる状況のときは普通に読んだほうが効率的です。
あと、音声が若干カタコトというか機械的な感じがあるので、人によっては気になるかもしれません。
「健康で文化的な最低限度のSPA」というテーマでSPAについて話してきました!
SPAサービスサミットというイベントで登壇し、ペライチの取り組みについてお話してきました!
ペライチはいわゆるSPA(= Single Page Application)サービスですが、それに耐えうるフロントエンドをどのように構築してきたかという内容です。
うちもまだまだ試行錯誤中ですが、これまで開発を行ってきた中で突き当たった課題とその対処法についてできる限りシェアしました。
SPAに興味がある方はとても多いようで、80人の会場は満席で、参加者の皆さん前のめりで非常に盛り上がったように思います。
イベントの詳細なレポートは会場提供していただいたGoodpatchさんがまとめてくれてますので、こちらからどうぞ!
パフォーマンスチューニング開発合宿
先日会社のメンバーで開発合宿に行ってきました!
弊社では恒例行事として、3ヶ月に一度1泊2日の開発合宿を行っています。これまでの合宿では特に開発テーマは決めずに各々が各自のタスクを消化しているだけだったのですが、今回初の試みとして、全員で「プロダクトのパフォーマンスを向上する」事にチャレンジするという取り組みを行いました。
合宿の準備
今回、準備した事が2つあります。
まず、現在のプロダクトの課題がどこにあるのか探す事。どこがボトルネックで何を改善すればいいかの目処を立て、リストアップしていきました。
2つ目はパフォーマンス・チューニングのマニュアルを作ること。エンジニア、デザイナー、総務兼エンジニアインターンなど、役職もスキルレベルもバラバラなメンバーが集まっているので、基礎的な部分をオリエンテーションできるように資料を作りました。
合宿当日
各メンバーにそれぞれチューニングしてほしい場所を割当てた上でコードを改善していきます。僕の役割はというと、ひたすらメンバーが上げてくるプルリクエストのレビュー&各々の処理の効果測定。
他にもいろいろやったよ
余談ですが、合宿中はメンバー同士の親交を深める事を目的に開発だけでなく他にもいろんな事をやります。
スタートアップ的な映画を見たり、公園でチームビルディングアクティビティをやったり、寮母の手料理を食べたりムーディーな風呂に入ったりしました!
結果
1泊2日7人で合計14個のプルリクエストをマージしました。結果、サービ全体で2秒以上、平均約45%の速度向上に成功しました。
良かったこと
今回は定量的に成果を測定できるテーマだったため、限られた時間の中で表示速度を何秒縮められるかといったタイムアタック的な緊張感があり、とても集中力高く取り組めました。またそれと同時にただタスクをこなすだけよりも大きな達成感が得られたという実感がありました。
そして、メンバー全員で同一の目標ににチャレンジした事でチームの一体感が高まったように思います。
まとめ
「パフォーマンス向上」というテーマは、日常的な機能開発と切り離してトライできる上に終わりがないので、開発合宿にとても向いてるいいテーマだなと思いました。
今後も継続的にチャレンジしていきたいと思います。(皆さん他にも良いテーマがあればぜひ教えてください….!)