ゆっくり…順序立てて…慌てない…
仕事でペアプロを主体にしてタスクを進めていく開発スタイルになって暫く経つのだけど、その上で結構自分に問題があるな〜と思った点があったので書き留める。
タスクを状況の共有がうまくいかない時がある
今のペアプロの体制は、二人一組になって、一つのタスクを担当して進めていっている。タスクを進めていき1時間程度経ったらペアを交代して、また別の人とタスクを進めていく。 こうすることによって、お互いの知識を補填し合えるので、行き詰まることも少なくなってくるし、お互いの知識の共有や取り組むタスクの範疇も広がっていくので、ひとりひとりの知識や出来ること増えていって、組織メンバーの技術のレベルアップにも繋がる。すごく良い取り組みだと思うし、こういう環境で色々なタスクに取り組めるのは、大変なときもあるけれど、有意義でやりがいがある。
で、このペアを切り替える時に新しく組んだ相手に、タスクの進捗状況を説明して、次に何をやるべきなのかを伝えない。これが上手くいかないと、タスクの目的やゴールがモヤッとした状態で進んでうまくいかない時がある。
この伝えるのが個人的にうまく伝えられなくて、相手が首を傾げてしまうパターンが結構多いな〜と感じるときがあり、どうしたもんかな〜となっていた。
なんで伝わらないのか？
色々思いつくのだけど、今一番個人の問題だと思っているのは「できるだけ今の状況を早く伝えようとして、途中過程や状況を少し飛ばして話してしまうこと」かな〜と思った。
うまい問題例が思い浮かばないので、あまり深く書かないが、ここ最近、この問題の解決のために、安直だけど「ゆっくり慌てず順序立てて話す」ということが良いかなと感じている。 今の状況に至った過程や理由を知れるほうが相手も納得しやすいし、理解もしやすいのだと思う。また、その先の新たな問題意識に目を向けてもらいやすくなる感じもしている。
他にも色々問題はあるだろうし、上の対策は超当たり前の事かもしれないけれど、ちょっと意識するだけでもいいかもしれない。
Firebase Realtime DatabaseのデータモデルはデカイJSON
去年モモンガ本を見ながら作った Vue.js + Firebase製のマークダウンエディタを作って、その後もVue.jsの勉強も兼ねてちょっとずつ機能を追加していた。
で、「メモにもカテゴリタグ的なもの付けて、それで検索とかもできると便利そう！」と思ったので、データベースにカテゴリカラムを追加しよう！とか思ったのだけど、データを管理しているFirebase Realtime database(以下 realtime）のデータモデルがちょっと余り触ったことない感じで取っ付きにくかったのでメモ。
とりあえずデカイJSON
公式のドキュメントを見ればわかるのだけど、NoSQLデータベースでredisのようなキーバリュー指向ではなくて、JSONを使った所謂ドキュメント指向的なもの。つまり、でかいJSONになっている。 データ構造もできるだけJSONのネストを深くせず平坦に保つとか、RDBみたいな正規化でなくむしろ非正規化をしてデータを冗長な形にしたほうがフェッチするときに効率的になるとか、色々書いている。 これが普段RDBとか使ってる身としては、結構取っ付きにくかった。realtimeのデータ構造についてググってみると「RDBのようなデータ構造の考え方は一旦忘れたほうがいい」的なことも出てきたりして、普段のDBの扱い方とは勝手が違う。
migrationとかそういうのは無い
で、最初に話していた「カテゴリ機能」を追加したいので、普段Railsに慣れ親しんでいる自分としては「なんかmigration的なことをするのかな？」とか思ってたのだが、実際はそういうことはしない。 クライアント側で、新しくカテゴリのparameterに追加してrealtimeのapiにpostするようにすれば、それ以降に追加したメモにはカテゴリが追加されることになる（こういうデータ構造は多分はスキーマレスDBとか言ったりすると思う）。 それより前に保存されていたメモたちについても、再度保存したタイミングでカテゴリが追加されて更新される。つまり、クライアント側でpostするデータを書き換えれば、それに合わせたデータ構造でレコードも更新してくれるということ。事前にmigration的なことしてデータ定義を設定するという前処理はない。
なんか一つ手間が省けた感があって、いい感じだと思うが以下のような問題も出てくるかなと思う。
例えば、途中でクライアント側からpostするattirbute Aを追加したために、参照しようとしたときにあっちのレコードにはAがあるけど、過去のこっちのレコードにはAがないということが起きたり、途中追加したattributesを使って全データを集計したいとき、そのattributesが無いレコードもあって集計が単純にいかない、とかはありそうだな〜と思った。なので、そのあたりをクライアント側で上手いことしてあげる必要が出てきそう（このあたりは類似形式のDBの特性とか運用方法を勉強すると楽しくなりそう 👨🏼💻）。
もしかしたら、FireStoreのほうがいいのかも…
realtime databaseと一緒に似たような Cloud Firestoreってのもあって、こっちはコレクションとかドキュメントという概念でデータを構造化する仕組みになっている。まだ内容をちゃんと読んでないので、よくわかっていないが、もしかしたらrealtime databaseより場合によっては運用がしやすいのかもしれない。こっちも追々触ってみたい。
こんな感じで暇な時にVueと一緒にFirebaseでも遊んでいる 🧔
2018年を振り返る
せっかくブログも書いてるので、自分の2018年を振り返ってみたい。
平成最後の今年はかなり周辺環境が変化して、はじめての経験をすることが多かった刺激のある1年だった気がしている。
色々書きたいけど、長文疲れるので、今年の自分の一番のトピックだと思っている「転職」にフォーカスして書いてみようかと思う。
はじめての転職
新卒で入社した会社を約2年で辞職して、今年の3月1日に転職した。
転職活動をしていた当初は、「新卒のうちは最低でも3年はいたほうがいいよ」とか、「今のレベルじゃ転職しても厳しいよ」とか、「次もすぐ辞めちゃうんじゃないの？」とか、正直耳を塞ぎたくなるような声をちらほら聞かされた（応援してくれる同僚とかも、ちょっとはいたけど）。また当初は実家から通っていたので、親にもだいぶ心配をかけてしまった。色々思い悩んだ末の転職だった記憶がある。
また、転職活動が初めてということや、大学院卒で社会人2年目で会社辞めてるという、世間一般的な人から見たら少しめんどくさそうな感じを漂わせる経歴だと個人的に思っていたので、こんな自分に本当に新しい職が見つかるのか！？という不安が大きかった。「俺、このままニートになっちゃうのでは？」とか思ったりもして、とにかく不安だった。
転職活動は「自分のエンジニアとして成長につながる」「会社の考え方に共感できる」「一緒に働いてみたいと思う社員の方々がいらっしゃる」という希望をもって会社を探し、結果、いくつか内定も頂いて、今の会社に転職がすることができた。本当にありがたい。
学生時代から知っていて「楽しそうだな〜。こんなところで働いてみたいな〜。」と思っていたところに入社できたのは、単純に嬉しかったし、不思議な気分だった。実際の仕事も、前職にいたら任せてもらえないような仕事をやらせてもらえたりして、学びや経験のある刺激的な楽しい時間を多く過ごせた。振り返ってみると、個人的に転職は正解かと思っている。
転職後の仕事は、社内管理画面の機能開発、認証機能の一からの実装やpuppetなどのインフラコードの触りなど、webフロントからサーバサイド、更にその下の層インフラ周りを触る機会もあり、結構幅広い技術畑を歩かせてもらえた。ディレクター、デザイナーやCSといった他職種との関わりがあるタスクにも携われた。 他にも、レビューやデプロイなども積極的に行い、ペアプロも初めてやった。
個人的には、このペアプロで得た知識というか成果みたいなものが、この1年を通して非常に有意義で良かったという印象がある（何が良かったについては、上のブログに書いている）。
あとは転職して半年？くらい経ったくらいで技術書の読書会なども開催して、色々な議論ができたのも楽しかった。読書会もそうだけど、転職後の会社ではフロントエンドに関する知識をキャッチアップするランチとか、Goを勉強するランチとか、社内勉強会とか、めちゃくちゃ積極的に開催されていて、そこで色々な知識を持ったエンジニアとの話や議論に参加することができたのが、非常に楽しかった。外部の勉強会やイベント、また技術以外の関連イベントのお手伝いなども参加させてもらえたので、これもまた刺激をたくさんもらえて、自分のモチベーションに繋がった。
転職に合わせて一人暮らしも開始
転職と、長年（多分８年くらい）単身赴任していた父が実家に帰ってきたので、これを機に一人暮らしをはじめたりもした。学生時代に少しした経験はあったので特に不安はなかったのだけど、転職と並んで、今年の周辺環境の変化の一つだと思う。
特段、書くことはないのだけど、転職と同じタイミングで一人暮らしを始めて、結構自分の身の回りのことに集中する時間を多く取りやすかったので、振り返ってみると良いタイミングで引っ越しできたなと思う。（書くことないので、一つ引っ越しの思い出として残っているのは「寝具選び」。 引っ越し仕立ての時は実家の古い煎餅布団を使っていたのだけど、それで寝ると翌朝首は痛い、背中痛い、肩は痛いで、体バキバキになってしまって次の日何も出来なくなってしまうので、お店を色々回った。で、折りたたみで干しやすいマットレス形式で、かつ寝心地が良いものを探して、マニフレックスのマットレスを買うに至った。やっぱり良い明日を迎えるには、良い睡眠から🛌）
来年は‥
もう書くことなくなってきたし、書いてたら2018年終わりそう。。。
転職して、色々経験ができて非常に有意義な1年（正確には10ヶ月）だった。でも、もっと良くできたのではないか？という感触があって、実際、目標とかも設定して仕事を進めていたが、あまり達成できていない状態で今年を終えてしまった。あとは一つのタスクに対して、とても時間をかけすぎてしまったという印象がある。色々と要因はあるとは思う。こういった反省点もあるので、来年は、、、
- 有言実行
- 実行するためのスピード向上
ということを意識しながら、1年過ごせればなと今は思っている。まだ具体的にどうするのかとかまとまっていないので、早いうちにまとめていく。
もうすぐ平成最後の年が終わる。来年もよろしくお願いします。とりあえず、メイウェザーつえぇ。
Vue.js入門を読み終えた
目次を見てもらえればわかるが、vue.jsの基礎から、コンポーネントについて、SFC, Vue Router, CLI, などなど、Vueに関わる知識を網羅的に得られて良かった。 最後の２章くらいは看板アプリを作る事ができるので、今度見ながら作ってるつもり。
あと個人的に読んで良かったな〜と思ったのでコンポーネントに関する知識や設計について書いてあったので、ちょっと前に参加したHTML5 Confで、Web Componentsの話をすんなり聞くことができた。Vueのこと以外にも、最近流行りのコンポーネントベースでの開発の基礎知識を得るためにも良い書籍だなと思う。
この本で得た知識を生かして、今ちょっとずつ開発しているmarkdownエディターをもっと良くしていきたいな〜 （あと、よく引き合いに出されるReactとAngularにも手を出してみたい）。
「自分はどういった実装が良いと思うのか？」をもっと考えたり、主張したりすること
以前書いた
にも似ている話な気がしている。
先輩や熟練者の実装やレビューが正しいと思い込みすぎる癖があった気がしている
個人的な話。
既存のコードが良いだろうという思い込みにも似ていて、開発経験が自分よりも多い先輩や熟練者の方々のレビュー、指摘、アドバイスはだいたい正しいだろうという思い込みが結構強すぎる癖があったなと最近思った。もっと「自分はどうするべきだ〜」とか「こうすると良くなるかも〜」という意見や逆提案をしていくことも大事だなと。
たしかに自分よりも経験や知識が多い先輩や同僚の指摘やアドバイスは、自分が目の前で取り組んでいる問題に対して、よりベターな解決案であることが多くて、本当に学びにあって楽しい。そのアドバイス等をもらって「その通りだ！」と思ったなら、そのアドバイスを使わせてもらえばいい。
でも「確かに！」と思う半面「うーん、自分はこう思ったりもしたな」と思ったり、「うまく理解できてない箇所があるけど、きっとアドバイス通りにしておけばいいだろう」と思ってるするときもあった気がした。そういった指摘を鵜呑みにしたり、「あの人が言ってるのだから間違いではないだろう」と言わば自分で考えることを疎かにしてしまう（意識的にはそういったつもりはないのだが）のは良くない。お互いに良くない。
なにか少しでもより良い方法や考えがありそうだったら、それを出していかないと、せっかく議論の余地があるかもしれないのに、、、もったいない気がする。これまたお互いのためじゃなくなってしまう。
うだうだ書いたけど、要は、もっと自分の意見を言っていかないとな〜と思ったってこと。
やっとこさ色々と慣れてきた感があるので、これから自分なりの良さそうな考えがあれば、もっと出していきたいという気持ち。
HTML5 Conferenceに初めて参加した
今回で（たしか）７回目の開催だというHTML5 Conference 2018に参加しに北千住の東京電機大学に行ってきました（どうでもいいけど大学思ったよりもキレイだった）
参加したセッション
- 最初の基調講演
- いつもブログを拝見させてもらっているmizchiさんの講演
- googleの方によるAMPの紹介講演
- web componentsの基礎から最近に流行りの開発手法を紹介していただけた講演
- webAssemblyの話をしてくださった講演
- 最後のLT大会とクイズ大会
zozoのECアーキテクチャとか、WebXRとか、有名な古川さんのnodeの話とか、yahooさんのFIDO認証の話とか、他にも聴きたいセッションがありすぎて、迷いに迷って上のを聞いてきた。
メモとかしたけど、とりあえず印象に残ったことを書き留めてみる
続きを読む既存のコードに習う実装には気をつける
既存のコードを良しとする思い込み
当たり前なのだけど、個人的に既にある既存のコードが比較的正しいほうだろうと思い込むことが多かったりする。
『まあ、既存コードがこうだし、真似すればいいよね』 『既存がこういう設計だから間違いではないよね』
既存コードを参考にするのは、サクッと開発するのには良いときあったりするとは思う。いわゆるコピペでうまく行っちゃうときもあるとは思う。
でも、上記のことばかりやっていて、既存コードに対して何も疑問を持たずに良しとする考え方になってしまうのは良くないな〜と思う（ごめんなさい。自分で言っておいて、たまにそれで良くね？って思うっちゃうときあります。反省してます）。
既存のコードが良いなんて保証はないと思うし、せっかくプログラマーやってるんだから、もっと良い設計とか良い実装を提案してリファクタリングしていくのが良いはず。 疑問に思う既存実装があったら、疑問を投げかけてみると、意外と歴史的な経緯で仕方なくそうなっていて、放置状態だったりすることもあるはずだ。そういった所を地道に直していくのも、プログラマーの仕事だと思うし、未来のために有益だったりするので、もっと既存のコードを良くする心構えと強くしたいな〜ってなんかふと思った。
