めるノート

へっぽこWebエンジニアが地団駄を踏んでいる日誌

Vuepressをサッとビルドして、Netlifyでサッとデプロイしてみた

すごく今更感があるのですが、先日Vuepressを立ち上げてみたので、雑にその様子を書いてみます。
最初はVuepressで、こっそり掃き溜めブログでも作ろうかなって思ったんだけど、Kibunlogというアプリが掃き溜めにとてもよかったので、Vuepressでの公開は特にしていません。

KibunLog:気分ログ日記-楽しく続くメンタルケアSNS

KibunLog:気分ログ日記-楽しく続くメンタルケアSNS

  • Haruka Murakami
  • ヘルスケア／フィットネス
  • 無料

Vuepressのビルドについては公式サイトの通り。

# install
yarn global add vuepress # OR npm install -g vuepress

# create a markdown file
echo '# Hello VuePress' > README.md

# start writing
vuepress dev

# build to static files
vuepress build

これでサッとビルドができます。

ディレクトリ構成や設定ファイルについては以下が参考にできます。
.md ファイルが記事なので、ファイルを増やすと記事も増やせます。

vuepress.vuejs.org

デプロイについても公式ドキュメントがあります。
自分は今回Netlifyを使いました。

vuepress.vuejs.org

まず、Netlifyにデプロイするために、Vuepressのプロジェクトで git init して、GitHubのリポジトリにPushします。
また、今回自分はNetlifyを使うのが初めてだったので、GutHubのアカウントと連携して、Netlifyのアカウントを作成しました。

www.netlify.com

Netlifyでアカウントを作成してログインをしたら、右上に「new site from Git」ボタンがあるのでそれをクリックします。

f:id:c5meg1012:20180609141408p:plain

デプロイしたいVuepressのリポジトリを選択して、デプロイ設定に進みます。

ヘッダーメニューの「Settings」に進んで、左サイドバーの「Build & deploy」の「Edit settings」からデプロイの設定ができます。

f:id:c5meg1012:20180609141442p:plain

Vuepress公式ドキュメントのこちらを参考に、Netlifyを設定します。

vuepress.vuejs.org

f:id:c5meg1012:20180609141511p:plain

これで、GitHubのリポジトリにpushをすると自動デプロイされるようになっていると思います。
pushしてデプロイがうまくいったかどうかは、Netlifyのヘッダーメニューの「Overview」から確認できます。

f:id:c5meg1012:20180609141528p:plain

以上、サッとビルドしてサッとデプロイしたときの雑なメモでした。
Vuepressについての日本語記事でとてもいいなーと思ったのは、有料記事にはなってしまいますがCodeGridの@nakajmgさんの記事です。
サッと作るだけではなく、Vuepressをきちんと作り込みたいなって思った時に参考になると思います！

app.codegrid.net

ダイエットアプリ、睡眠アプリ、英語アプリの話

ゆるゆるダイエットをはじめました

きっかけはこれです。

あと、温泉入る前に体重計に乗ったら増えすぎててビックリしました。

ということで、こちらを導入しました。

Noom - AI とコーチが健康管理、食事記録、歩数計連携

Noom - AI とコーチが健康管理、食事記録、歩数計連携

  • Noom, Inc.
  • ヘルスケア／フィットネス
  • 無料

やってることとしては以下です。

  • 大江戸線六本木駅で階段を使う
  • AppleWatchとアプリを連携して運動量を記録
  • 体重を毎日記録
  • 食事を毎回記録
    • 朝はカロリーメイトハーフサイズ
    • 昼はサラダと焼き魚
    • 夜は自炊（ライザップご飯のレシピ本を参考）

こんな感じ。
まだはじめたばかりだけど、2キロくらい減っています。
まあ、まだ誤差の範囲内なので、油断せずに続けます。

AppleWatchで睡眠を測りはじめました

ここしばらく寝つき / 寝起きがあまり良くない気がしているので、睡眠を測りはじめました。

AutoSleep Watchを使って睡眠を自動で追跡します

AutoSleep Watchを使って睡眠を自動で追跡します

  • Tantsissa
  • ヘルスケア／フィットネス
  • ¥360

睡眠の質は悪くなさそうだと安心したら、すこし寝つき / 寝起きが改善された気がします。
上手く眠れてないと思い込んでて悪循環だったのかもしれません。

英語の勉強を習慣づけています

それから、英語の勉強もサボり気味だったので、リマインダー通知できちんと行動管理するようにしました。
英語の勉強は以下のアプリでやっています。
ある程度慣れてきたら英作文もできるようなものを試して、そのあと英会話をやってみようと思っています。

発音の練習

ELSA Speak - Accent Reduction

ELSA Speak - Accent Reduction

  • Elsa Corp
  • 教育
  • 無料

聞き取り・ディクテーション

英会話、英語リスニング - スタディサプリENGLISH

英会話、英語リスニング - スタディサプリENGLISH

  • Recruit Co.,Ltd.
  • 教育
  • 無料

英単語

スタディサプリ 英単語

スタディサプリ 英単語

  • Recruit Co.,Ltd.
  • 教育
  • 無料

リマインダー

HabitMinder

HabitMinder

  • Funn Media, LLC
  • ヘルスケア／フィットネス
  • 無料

一気にいろいろはじめすぎて、全部破綻しそうな予感がめっちゃしているけれど、うまくいくと楽しいし、ひとつくらいできなくても落ち込みません。

最近、なにかの数字を見るのが好きだな、と思うのです。 家計簿とか、カロリーとか。

内定を辞退してTwitterで転職活動をしました

先駆者であるひよこ大佐（@hiyoko_taisa）さまに敬意と感謝をこめて。

こんばんは。めるです。表題の通りです。

年末の時点で次に行く（はずだった）会社が決まりまして、1月末で退職をしていました。
しかし、最終出社1日を残したあたりで状況が一転、内定を辞退して転職活動を再開することになりました。
内定を辞退した理由については、直接聞いてもらうか、時期でお察しください。。

有給を使いきっていたのもあり、もともとバッファで2週間だけ無職になることにしていましたが、それにしても早く職に就かねばならない、ということでTwitterで求職してみることにしました。

Twitterで求職しようと思ったのは

  • 一度内定が出ていて、個人的に満足のいく年収だったので、それベースで年収交渉できそうだった
  • もう退職することになっているので、現職に内緒で転職活動をやる必要がなかった

という理由があります。これがなかったらやってないです。

思い切ってツイートしてみたところ、リプライ、DM、Eメール、Facebookなどで、30社ほどの企業さまよりお声がけいただきました。
お声がけいただいた皆さま、本当にありがとうございました。

まずはテキストベースで

  • 技術スタック
  • 組織体制
  • 想定されるポジション

などをヒアリングさせていただいて、実際にお会いさせていただいた企業さまは10社くらいになります。

もともと「バッファの2週間」だったので、沖縄行ったり、親知らず抜いたり、デブサミに行ったりしていたため、全部で3週間くらいかかりましたが、そういうのがなければ2週間でいけたんじゃないかな、と思っています。

自分はコードレビューの記事の件もあり、とても残念なことに、技術力よりもSNS力や知名度のほうが先行してしまっている傾向があるため（早くなんとかしないと...）、普通では難しいと思われる企業さまからも、Twitterのおかげでお声がけいただけたりしました。
あとは、互いのニーズがある程度一致したうえで初回面談できるのがよかったです。

改めて決まった転職先については落ち着いたらまた書きますが、実は、年末に一度内定が出たくらいの時期に、旦那（@polidog）経由でお声がけいただいていた企業さまなので、Twitterきっかけではないところで決まってしまったという。。

でも、Twitter経由でお会いした企業さまも、全部本当に素敵な企業さまだったので、今までの転職活動の中で一番有意義なものになったと思います！！ほんとに！！

改めて、今回の転職活動でお声がけくださった皆さま、リツイートしてくださった皆さま、そして旦那さまも（笑）、本当に本当にありがとうございました。

Vue.jsでインクリメンタルサーチを作った

これは Vue.js #2 Advent Calendar 2017 の24日目です。

qiita.com

こんばんは、める（@c5meru）です。
日付まわっちゃいました、ごめんなさい…＞＜
今回、あまり技術的なことを細かく書けない題材にしてしまったので、Qiitaではなく、はてブでカンタンに書かせていただきます。

なんでインクリメンタルサーチを作ったの？

自分が現在のお仕事で作っているサービスは、『JOB LIST』という、アルバイト・パートを中心とした求人情報のサイトです。
タウ◯ワークやバイ◯ルさんのような一般的な求人広告と、それに加えて、ユーザー投稿の「求人張り紙」が掲載されています。

あ、よかったらアプリから「求人張り紙」投稿してみてくださいね、ポイント集めるとAmazonギフト券にできるので。
それから、求人を出したい方は、こちらからセルフで作って無料で出すこともできますので、よかったらどうぞ。
と、サービスの宣伝はおいといて。

前々から、このサービスの検索部分で、インクリメンタルサーチを採用してみたいなーと思っていたのですが、諸般の事情で出来ずにいます。

とはいえ、いろんな予約サイトとかフリマ系アプリなどは、インクリメンタルサーチをガンガン使っているので、即時で検索ワードが見られるのって結構メリットなんじゃないかなーと思うのです。

インタラクティブなUIを、お仕事に関連するところで作ってみたいなーという気持ちはずっとあって、今年のうちに消化しちゃいたいな、と思って、作ってみました。

作ったもの

苦労したポイントは？

取り込むデータ形式

まあ、本当にお仕事でやるならAPIになるんでしょうけど、その場合も、どういうデータをやりとりするべきなのか、きっちり考える必要がありそう。
今回は漢字だけのサジェストで作りましたが、実際やるなら、ふりがなとかもサジェストできた方がいいですよね。

マルチキーワード対応

今回は愚直にsplitと、マルチキーワードかどうかのフラグを用意して、、という感じで作りました。
時間がなくて実装しきれなかった、キーワード削除機能でも、結構ややこしくなりそうなところです。
複数のキーワード管理、もうちょっとうまいやり方がありそう。経験のある方に、知見をいただきたいです。

まとめ

インクリメンタルサーチを実装するのは初めてでしたが、Vue.js公式のドキュメントと、Codegridの記事がとても参考になりました。

パッと思いついたワードを打ち込むとソレっぽいワードが出てくるのは嬉しいし、制作陣が意図する検索方法と、ユーザーがやりたい検索方法が、うまい感じにマージできるのかな、と思いました。

あとは、まあ、時間がなかったので、けっこう突貫工事になってしまったな、という感じです。
最近Rubyに重きを置いていたので、もともとないJS力がさらに下がっており、些細な事で詰んでたりしました。反省。
来年はもっとレベルアップして、いい記事が書けるようにがんばります(｀・ω・´)

『改訂第3版 すらすらと手が動くようになる SQL書き方ドリル』をやっています

これは 積読本 Advent Calendar 2017 の23日目です。

adventar.org

こんばんは、める（@c5meru）です。
今回積読本ということで、選んだ本は表題の通り、
『改訂第3版 すらすらと手が動くようになる SQL書き方ドリル』
という本です。

f:id:c5meg1012:20171223221037j:plain

まず最初に、お詫びをさせてください。
この本、まだ全部おわってません…ごめんなさい(´・ω・｀)
必ずや今年中に全部おわらせるぞ！という宣言とともに、途中までではありますが、取り組んでみた感想などなど、書いてみようと思います。

なんでSQLをやろうと思ったの？

会社でいろいろ教えていただいている@mikedaさんがインフラのほうに詳しい方で、クエリのパフォーマンスの話がよく出るので、チンプンカンプンじゃダメだな、と思った次第です。
あとはまあ、HTML、CSS、JavaScript、PHP、Rubyとやってきて、これといって特化したものがないのが悩みなのですが、ちょっと前に、Rubyをコアスキルにしたいな、と思うきっかけになる出来事がありまして、サーバーサイドをやっていくならSQL文は押さえておきたいな、と思いました。

どんな本なの？

SQL文のケースごとに小さな章がたくさんあって、それぞれ、例題→解説→練習問題、という順番で進んでいきます。
練習問題はSQL文の穴埋めからフリーテキストまで5問あり、高校数学の教科書・参考書みたいな感覚で、ノートを用意し、手で書いて覚えられるようになっています。

なんで積読になっちゃったの？

例題の解説で小さく備考として書かれていた要素がしれっと練習問題に出てきて、比較的序盤なのに分からないことが積み上がって、先に進むのがしんどくなってしまったためです。
あとは、ペンとノートを用意して作業環境を整えるのが（普段やってない分）意外とハードル高かったというのもあります。笑

やってみてどうだった？

アドベントカレンダーを書くにあたり、「備考もすみずみまで読む」「作業環境を整える」というハードルを乗り越え、章をいくつか進めてみました。

積読本になっている間、お仕事で集計のために何度かSQL文を（見よう見まねで）書いたこともあり、はじめからある程度わかる状態で始められたのはとても良かったです。
当たり前ですが「わかるようになると楽しい」というやつです。なので、なにもわからない初心者だとキツイ本だったのかも？
章の分け方はとても細かいので、チョットデキルくらいの人がケーススタディ的にやるのに向いてると思います。

自分は受験勉強を楽しんでたタイプだったので、ペンとノートで書いていくのは、それなりに楽しいです。普段やらなくなっちゃったから余計に。笑
逆に、ペンとノートで何かやるのが苦手な人には、向かないかもしれません。まあ、付録で学習用ソフトもついているので、そっちでやるといいのかも。

まとめ

そういうことで、本の紹介をさせていただきました。
わが家にはまだまだ積読本がたくさんあるので、年末年始も利用して、ガンガン読んでいこうと思います。

闇に飲まれてしまったときは、もっと深い闇に飲まれればよかった

これは Dark - Developers at Real Kommunity Advent Calendar 2017 の22日目です。

adventar.org

ただのポエムになってしまったので、そういうのが苦手な人は、ブラウザバックしてください。

Darkのコミュニティは、今年からになります、める（@c5meru）と申します。
家が近所なメンバーが多かったことと、旦那である＠polidogの知り合いが多かったこともあり、すんなり馴染むことができて、いつもお世話になっております。

去年の今ごろは「年が近い友達がほしい」と、よく嘆いていました。
現在は、近い年齢のDarkメンバーに囲まれて、毎日Slackで楽しく話しながら毎日を過ごしています。とてもありがたいことです。

実は、社会人になってからの数年間、年の近い人達が本当に苦手で、恐怖で、たまりませんでした。
そのあたりのことを、上手く書けるかわからないけれど、書いてみようと思います。

自分が東京へやってきたのは、大学2年生の7月でした。
東京に引っ越せば、サークルのみんなともっと仲良くなれるかもしれない。もっとサークルのために力になれるかもしれない。
そう思って、有り金のほとんどと奨学金を駆使して、わたしは東京へやってきました。

でも、残念ながら、その希望が叶うことはありませんでした。
サークルのメンバーとのあいだにあったのは、金銭感覚の違いとか、根回しなどの政治力とか。そういうものが絡んだ、どうにも出来ない理由でした。たぶん、場違いなところだったんだと思います。

掛け持ちしていた別のサークルのメンバーや、学科の友人とは仲良く楽しくやれました。
しかし先述のサークルの規模はとても大きくて、人数も、コミットした時間も、そっちのほうが圧倒的でした。だからなんだか、それからずっと、トラウマになってしまったのです。

幸いなことに卒業後すぐ、同じ大学が母体の音楽団体に身を寄せることができました。
10〜20歳ほど年上の方が多い団体で、そこではみなさんとてもやさしくて、人に対する根本的なトラウマは大分癒されました。
ただしそこには当時、年の近いメンバーはほとんどいませんでした。

トラウマが癒された自分は、ヤケクソで新卒入社した生保レディをやめてIT業界に飛び込みました。
そこでは年の近い人、年下、年上、まったく関係なく、たくさんの人が業界のために活き活きと働いていました。
そんなIT業界に慣れてきた頃に見つけたのが、Darkのもくもく会でした。
最初は年の近いメンバーたちにおっかなびっくりで、いまでもデスマス調が抜けないこともありますが、みんなに優しくしてもらって、毎日楽しく過ごしています。

なにはともあれ、優しく迎え入れてくれて、ほんとうに感謝しています。
主宰のarata 氏、そして、我々夫婦の出会ったgotanda.jsの主宰であるhoto氏を始め、メンバーのみなさまには改めてお礼を述べたいと思います。ありがとうございます。
不束者ですが、今後ともどうぞよろしくお願いします。

フルリモート旦那のすゝめ　〜あれから1年〜

これは 妻・夫を #愛してる ITエンジニア Advent Calendar 2017 の11日目です。

adventar.org

今年も参加してみました。める（@c5meru）です。旦那は @polidog です。
昨年は新婚だったので以下のような記事を書きまして、大きな反響をいただき、ありがとうございました。

c5meru.hatenablog.jp

今年は「あれから1年」ということで、もうちょっとみなさんがフルリモートの配偶者との暮らしをイメージしやすいように書こうと思います。
フルリモートがひとつの働き方として、より一般的になりますよう...

もくじ

  • フルリモートって？
  • わが家のフルリモート旦那
  • デメリット（わが家の場合）
  • メリット（わが家の場合）
  • フルリモート旦那のすゝめ

フルリモートって？

フルでリモートワークなことです（雑）。
リモートワークについては以下をご参照ください。

partners.en-japan.com

わが家のフルリモート旦那

わが家のフルリモート旦那は、いまのところ、コワーキングスペースなどをもたず、在宅で仕事をしています。
週1日、数時間、打ち合わせのために出社しています。この打ち合わせをのぞき、勤務時間の指定やコアタイムなどはありません。
業務委託やフリーランスだったり、自分の会社だったりするのではなく、いまは、いち正社員として勤務しています。

ちなみに自分は、きっかり9時〜18時出社で、最近の悩みは早起きがつらいことです。

フルリモート旦那のデメリット（わが家の場合）

普通はメリットから書くものだと思いますが、そうなると良いシメ方が思いつかないので、先にデメリットを書きます。笑

「いつどこで仕事をしてもいい」となると、自分だったら全く仕事しなくなりそうだなーと思うのですが、旦那さんはそういうこともなく、しっかり仕事しているようで、本当にすごいと思います。
ただし、お仕事のピークタイムがPM21:00〜AM3:00くらい、なのです。なんだか大学生のレポート課題のようですが、本当にそうなんです。
夜中のほうが集中できることがあるのは確かですが、毎日となるとどうなんだろう、、でも、本人曰く、この時間帯がベストなんだとか。

ということでデメリットは、おおむねこのタイムゾーンの違いに由来します。

だいたい自分がゴミ捨て担当になる

ゴミ捨ては基本、朝8:00ですからね...自分が寝坊しようものなら、ほぼ次回に持ち越しです。

生活時間帯が真逆になると寝顔しか見ない

「寝顔しか見ない」というレベルになることはあんまりないですが、どっちかが疲れてて、寝坊したり、早めの就寝をしたりすると、そうなることがあります。
まあでもこれはフルリモートに限らず、シフト勤務の配偶者さまなら、あるのかな。

特に理由もなく働きたくなくなる

相手のお仕事タイムに自分が熟睡しているので、相手が仕事しているのを見ることが少ないためか、
「自分は満員電車で朝9時に出社して、規定の時間頑張ってるのに、のんびりマイペースで働く旦那さんに比べてお給料少なすぎ...なんか、何やってるんだろう...」
みたいな無力感に襲われてしまうことがあって、働きたくなくなることがあります。
そうはいっても専業主婦になりたいとは思っていないし、お仕事がんばりたいと思っているので、もちろん働きますよ。笑
時間＝バリューではないことは言うまでもないですし、旦那さんは自分よりも、はるかにすごいエンジニアだからこそ、のんびり働いても十分なバリューが出せるんですよね。だからそうやって悩むのは不毛なんです。たぶん。

フルリモート旦那のメリット（わが家の場合）

どの項目もやっぱり、自分にはない「場所と時間の自由」があることに、関係していますね。
今年の初出社に財布を忘れて、会社から初詣に出かけるまでの間に、届けてもらったことがあります...ありがたやありがたや...。

お洗濯や、ごはんの準備がされている

これは去年も取り上げましたねｗ
旦那さんは、お洗濯が外干しじゃないとイヤみたいなので、きっちりやってくれます。すごい。
ごはんは、自分が作るの苦手なので、、、とても助かっています(´；ω；｀)

宅配便が無限に受け取れる

宅配ボックスでいいじゃん、という話ですが、一人暮らしのときにとても悩まされたので、感動しています！！！　わーい！！！

一緒にいられる時間がたぶん長い

デメリットで「生活時間帯が真逆になると寝顔しか見ない」と書いたので、一見矛盾しているように感じると思います。
しかしおそらく、エンジニア以外の職種で頑張っている男性は、けっこう帰宅も遅かったり、付き合いで飲みに出かけてしまったり、、ということが多いのではないでしょうか？
奥さんがごはんを作って待っていても、急な飲み会で深夜帰りだったり、ブラック企業で終電帰りが続いたり。。そんな結婚生活を送っている知人の話を聞くと、自分は本当に恵まれているんだなー、と思います。

フルリモート旦那のすゝめ

ということで、今年はフルリモート旦那のデメリットとメリットに分けて、お伝えさせていただきました。
フルリモート旦那は「場所と時間の自由」があるので、いろいろ融通がきいて、おすすめです。
また子供が生まれたりとかしたら、いろいろ変わるんだろうな。

おっと、そういえばここまで、「愛してる」要素がありませんね。笑

新婚ホヤホヤの去年と違って、お互いいろいろ分かってきて、だからこそ、改めて言葉にするのは難しいような「居心地の良さ」のようなものを感じはじめています。

けれど旦那さんの、エンジニアとしての優秀さに嫉妬してしまって、頑張ってる旦那さんを素直に認められないことがあったり、自分自身、子供ができる前にあれもこれも…と生き急いでしまって、あまりゆっくり一緒にいられなかったりすることもあって、本当に申し訳なく思っています。

いろいろ迷惑をかけてしまうことも多々あるとは思いますが、愛してる旦那さんは、帰る場所であり、頼れる先であることは間違いありません。
こんな妻ではありますが、引き続きどうぞ、よろしくお願いいたします。

polidogへ感謝と愛を込めて。

Rails Developers Meetup 特別編 に行って、「あの」伊藤さんとお話をさせていただいた

Rubyを使っている人が調べ物をすると必ず出会うであろう、伊藤淳一（@jnchito ）さんの著書「プロを目指す人のためのRuby入門」出版イベントに行ってきました。

techplay.jp

著書はこちら

ruby-book.jnito.com

動機は単純で、物理の伊藤さんがひと目見たかったからです。
自分は伊藤さんの記事と、その視点がとても好きで、そこには以下のような理由があります。

  • 文系出身エンジニアだから（自分も文系出身なので）
  • 元バンドマンだから（自分も音楽漬けだったことがあるので）
  • フルリモートだから（旦那がフルリモートなので）
  • 読む人、相手の気持ちを考えているから
  • そこに裏付けられた分かりやすさがあるから

などなど。
今日の話で出ていたものもありますが、過去の記事でも取り上げられていたことがあります。

↓文系エンジニアのくだり↓

blog.jnito.com

↓読む人の気持ちを考えるくだり↓

blog.jnito.com

そんな感じで、Qiitaやブログをちょいちょい追っかけていたため、
「おお、本物が見られるのか」という軽いノリで参加してみたのでした。
（リファクタリングコンテストは、前日の深夜2時まで粘って記念参加したけど、全然歯が立たなかった...）

いざ会場に着くと、自分はミーハーなので登壇位置の目の前に陣取りました。笑
乾杯してビール飲んで、ピザ食べて、質問タイムがあって、その後は「分かりやすい技術記事を書くために」「技術書を読む価値」などについての、伊藤さんのありがたい講演がありました。そのあたりはきっと、他の参加者の方が詳しく書いてくださるかな、と思います。

そして、講演の後は「リファクタリングコンテスト」でした。
お題は以下のリポジトリです。

github.com

挙手制で、PRの内容を「タケシくん」に語りかけるように説明してください。とのこと。
自分もPR出してみたのですが、他の参加者のPRを見るとあまりにも圧倒的すぎて、挙手は控えていました。

数人「タケシくん」への説明を終えたところで、突然、司会の平野さん（@yoshi_hirano）が、なぜ今回このような形にしたかというと...というお話を始めました。

「もともとは、8月のイベントでやったように、伊藤さんにコードレビューをやってもらおうと思っていました。」

↓8月のイベントはこんな感じだったようです↓

blog.jnito.com

「ところが伊藤さんが、『コードレビューを受けるのがつらくなったときは』という記事を読んで、参加者の方々にコードレビューをしてみてもらいたい、ということで、今回このような形で、みなさんがコードレビューをするという設定になりました」

えっ、ちょっと待って、それ自分の記事では...と思っていたら、

「その記事を書いた、めるさんがここにいらっしゃるということで」

なぜか立ってマイクを持つことになり、伊藤さんと数分間、対談させていただきました。
伊藤さんからも、
「東京に来たら、めるさんと話をしようと思っていました」
とおっしゃっていただけて、控えめに言っても、夢のようでした。

実は、こんな風にツイートしてくださっていたのは存じていて、

それについて直前の質問タイムで挙手したらちょうど時間切れだった、という偶然がありました。ネタバレしなくてよかったｗ

自分が座っていた位置も関係者席っぽい感じだったのでアレですが、帰り道で話しかけてくださった参加者の方々から、
「あの流れ、前もって言われてたんですよね？」
と何度か言われたのですが、いや、もちろん、まったく言われてませんでした！！！笑

思いがけず、きっと一生忘れないんじゃないか、という機会をいただけて、本当に本当に嬉しかったです。
伊藤さん、平野さん、本当にありがとうございました！

あー、一緒に写真撮ってもらえばよかったな、でもRubyを書いていれば、きっとまた会えるかな。
なんて思いながら、忘れないために書いておきます。

f:id:c5meg1012:20171206224449j:plain

コードレビューを受けるのがつらくなったときは

そういうときがよくあります。
コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。

「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。

anond.hatelabo.jp

さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。

私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？

刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をまとめておきます。

www.slideshare.net

ソニックガーデンの方です。
7つの秘訣は、

  1. レビューの観点を明確にすること
  2. 我が身に返ることを恐れずに指摘すること
  3. 何故悪いコードなのかを論理的に説明すること
  4. 良いコードについて共通認識を持つこと
  5. 小さい単位でレビューを繰り返すこと
  6. 指摘は素直な気持ちで受け入れること
  7. 指摘は人格否定でないことを理解すること

レビューを受ける立場として、6と7は「あっ、そうだよな」と自身の未熟さに気づいたところがありました。
一方で、1や4のような、共通認識とか、前提としての観点っていうのもあまり明確でないことがあるので、それは自分からある程度提示したり、問題提起したりで改善できそうです。

speakerdeck.com

ペパボの方で、新卒のメンバーに向けてお話されたそう。「コードレビューのやり方」な話です。
勉強会などでよくペパボの方を見かけますが、ほんと、いい会社なんだなあ、という感じがします。

印象に残ったところだけ、かいつまんでしまいますが、
（主に新卒など駆け出しのエンジニアが）コードレビューをやる上で大切なのは、コードを読んで理解することだそうで、

  1. なんでこうなっているのか？を考えながらコードを読む
  2. わからないところがあると悩む
  3. 10分悩んだら自分ではわからないと判断して聞く

この「なんで・悩む・聞く」を繰り返すとできるようになる、とのことでした。

あとはコードレビューは「伝え方が9割」ということで

  1. 理由を書く
  2. 褒める
  3. 提案する
  4. 提案にも理由を書く
  5. コードで示す

ただし、このへんは上級者じゃないと難しいかも？だけど、LGTM画像、絵文字、顔文字で「めでたく」盛り上げることはできるよね、という感じでシメられていました。

ここからは自分の感想になりますが、コードレビューはとてもデリケートだから、レビュアーはいろんなこと意識しないといけないなって思いました。
指摘されたとき、レビューイ側は「じゃあどうすればいいの！」ってなっちゃうとき、ありますもんね。

LGTM画像については、以下の記事でも「叩かれすぎて凹む問題」で取り上げられていました。
http://ogihara-ryo.herokuapp.com/blogs/1

あとは、まあ、やっぱり「悩んだら聞く」ことが大事だなと。
自分もレビュアー側のとき、さっぱり分からずチンプンカンプンだったらレビューイに聞くようにしてます。当たり前ですがｗ

レビュアー側が「聞く」ことは初心者じゃなくても大事だということで、以下の記事でも取り上げられていました。

qiita.com

そして、レビューイ側も「聞く」ことが大事だと、以下の記事で取り上げられていました。

blog.sushi.money

レビューイ側としても「悩んだら聞く」こと、痛いほど、わかっているんですよね。。。
ちょっとしたCSSの設計とか、エラーハンドリングとか、書く前に相談すれば間違いないんですよね。

techblog.timers-inc.com

この記事で良いなって思ったのは「修正対応の有無はハッキリと」のところです。
MUST・THINK・INFO・TRIVIALなど、修正対応の必要性がわかると、自分がレビューイだったら嬉しいなーと思いました！今度やってみよっと。

よーし、いろいろ見てたら楽しくなってきたぞ。

www.chirashiura.com

わかるわかる！と読んでいたら、存じている方の2年前の記事でした。
すごい人だなぁ、と思っていたので、誰もが最初はそうなんだな、とも思えて、元気が出ました。笑

変数やクラス名について批判されるのもなんだかセンスがないと言われているようで辛い。

これもあるある！な感じで、こういうものこそ、具体的な提案とその理由がほしいですよね。

qiita.com

この記事くらいちゃんと説明してくれないと、エラーが出たりパフォーマンスに関わる問題じゃないので、センスとか才能の問題なのかな？ってなっちゃって、違うと分かっていても、自分を否定されたような気持ちになっちゃいますよね。

ということで、いくつか記事や資料を挙げてきました。

コードレビューがつらくなっちゃうときは誰しもあるけれど、だからこそ、自分が担当するレビューイにはそんな思いをさせないよう、つらさを胸に刻みながら、精一杯相手のことを思ってレビューしよう、という感じでしょうか。
将来、後輩ができたときには「わかりやすくてやさしいから、あのひとにレビューされたい」って思われたらいいなあ。うん。

船の中で飛行機を間近に見ながらPHPの話ができるイベントを開催しました

嘘は言ってないぞ。嘘は。

お越しいただいたみなさま、本当に本当にありがとうございました。
あの場で初めてお会いした方々も含めて、またみなさまとゆっくりお話できたらな、と思います。

本日で、望月姓としては1歳、わたくし個人としては26歳を迎えました。
去年はいろいろ目標をたてましたが、これからの1年はその延長線上で、ゆっくり目の前のことに取り組めたらな、と思います。
どうぞ、よろしくお願いします。

以下、今日でラストにするので許してくださいw