2020 年の振り返り的な伺か

2年ぶりにブログを書いている。

今年は色々自身の生活に大きな変化があった。 通して気持ちの変化や、考え込むこともあったので吐き出しておこうとしている。

…が、何かしらの記事を書こうとすると、体裁を整えようと躍起になって超大作を作り出してしまうタイプなので、もう書くのに飽きた時点で投稿するぞ! というか年越しそうだぞ!遅筆だぞ!😌

転職したぞ

開発の話

diescake's magnet
diescake's magnet

ちょうど今年の初め 2020/1/1 から新しい職場で働き始めた。早いものでもう 1 年になる。

1-2 月はオンボーディング的に新規プロダクト開発中のチームで力を貯めて、3 月からはウェブアプリケーションのリニューアルを行うチームで主にフロントエンドを担当した。このプロダクトには外部要因による明確なデッドラインがあり、リリース前の1-2ヶ月は熾烈を極めたが結果的には無事にローンチできた。

まだまだ色々と課題はあるものの、フロントエンドエンジニアとしてのアウトプットは出せたはず。ひとまずよかった。

それと、元々の転職の動機の 1 つである「様々な柵に囚われず、ちゃんとユーザに向いた開発をしたい」が無事叶ったのもよかった。 もちろんこれは叶ってからがスタート地点なんだけども。

コミュニケーションの話

コミュニケーションに関しては心疲労が絶えなかったと思う。

前職の会社は新卒で入社してから、あれよあれよと 10 年弱も働いていたので、大抵の社員は顔と名前が一致するし、異動やヘルプ(鎮火作業)を重ねるうちに自然と交友関係("戦友"と書いて"友")も広がっていたことで、いつからかコミュニケーションに要する MP も抑えられてのびのび過ごせていたというのがある。

それに比べるとまだまだ落ち着かないし、正直会社に馴染んでいるという実感はあまりないかもしれない。

今思い返すと、新卒で入社したときは割と相手を知って覚える努力をしていた気がする。

うん、もうちょっと行動せねば…!

日常生活の話

コロナの影響

元々引きこもり体質なので、コロナによる外出自粛で辛いということは特になかった。なんなら直接的な影響にのみ絞れば、リモートワーク中心の生活になって快適になったといえる。元々自宅の開発環境も充実している方(だと思う)で、補助が出ても買い足すものもあまりなかった。

2020/4月頃の PC 環境
2020/4月頃の PC 環境

天気の良い晴れの日に家に引きこもって PC 叩いていても、外出しなければならないという強迫観念に囚われることも減った。ただ、運動不足過ぎて早死しそうなので、もう少しちゃんとテニスしたい。あるいは、ロードバイクをオーバーホールして乗りたい。

ちなみに、1 人で過ごしている際の食に対する関心の薄さが極まって、大体いつも BASE BREAD をそのままかじりながら PC に張り付いていた。栄養面はともかく、何か精神的にとても不健康な感じがする…。

家にいることが多くなったこともあって、ゆったりな服を着ることが多くなった。T シャツは丈がジャストな M サイズ中心だったが XL でだるだるな服を着ている。スーパー銭湯とか健康ランドにあるような快適な館内着(≠ じんべえ) が欲しくて探してる。

ワークライフバランス

元々、業務時間以外でも予定がなければ趣味で開発(半分くらい仕事)しているような生活スタイルだったのだけど、今年は仕事自体が切羽詰まっていたことに加えて、プライベートでもやりたいことが多くて業務以外の開発・勉強時間が皆無に近かった。(Ruby を少し修練したくらい)

GitHub contributions
GitHub contributions

週末ほとんどコミットしてないのがわかる。

その結果、プライベート(主に switch ゲー説)はとても充実していてよかったんだけど、もうちょっと開発関連のインプットに時間振らないと成長感なくてエンジニアとしてやばいな、という漠然とした焦りを感じることが増えた。

ただ、結局インプット増やしたとしてどうなりたいんだっけ?という目的が曖昧なので、モチベーションの源泉として弱いようにも思う。

元々実務に使わない技術習得にはあまり手が伸びないタイプなのだけど、 その辺りは前職だと PoC で興味がある技術をカジュアルに採用できたので、それが新たな技術習得に向いていたのはありそうだ。 (PoC の開発で得た経験なんて表面的なものでしかないのもわかるんだけど)

ビールの話

今年は特に うちゅうブルーイング のビールをよく飲んだ。

うちゅう戦争(発注競争)にもすっかり慣れて、新商品でもなければほぼ確実に購入できるようになった。 自身のツイートを見ると今年は7箱(6瓶/箱)も飲んだようだ。

流石に高頻度で飲みすぎて、うちゅうっぽさの飽きが進行していたところ、ある意味対極な感じもする繊細な味わいの StormBreaker Brewing のビールに感動したりした。

StomBreaker Brewing at iBrew Akihabara
StomBreaker Brewing at iBrew Akihabara

総括

自分でいうのもなんだけども今年は割と頑張ったぞ!

???「褒めてやりたいところだァ!」

その上で、色々と実を結んだと思っている。良い1年であった。

ただ、頑張ったことと頑張らなかったことの差が激しいので、もっと良い感じにフットワーク軽くタスクスイッチしてバランスよくできると良いなと思う。

何か別の作業を1 時間するために、5 時間力を貯める必要がある、みたいな立ち振舞ををなくしていきたいが、果たしてそんなことができるのだろうか…。

では!今年も散ッ!

Bonfire Frontend #3 に参加してきました(╹◡╹)

BONFIRE LIT
f:id:gachapining:20190128144248j:plain

Bonfire Frontend #3 で ヤフーさんの LODGE へお邪魔してきました!

初 LODGE だったのですが、オープンで遊び心が感じられる自由な雰囲気の空間で、それはもうとても素敵なものでした。ずるいぞ。

さて、今回はブログ枠として参加してきましたので、本記事を書いています。発表スライドは connpass にアップロードされるようなので、 自分が特に印象に残っていることと、その所感を述べます。

最初は、見聞きした内容を中心に要約しようと思いましたが、いざ書き始めてみると、スライドのクローンを錬成している感があり方針転換と相成りました。

Bonfire Frontend #3 パフォーマンス改善

アーキテクチャリニューアルから、考えるフロントエンドとデータモデリング

  • Retty 株式会社: 竹野峻輔
  • slide: https://

皆さんご存知 Retty さんの提供されるサービス Retty のリニューアル(リアーキテクチャ)に関するお話。 今回は具体的なベストプラクティスや、Tips といった話よりは、先を見据えた計画や、チームビルディング、心構えといった話が中心であった。

竹野さんはデータエンジニアとしても活躍されている様子。すごい。

プロダクトだけではなく、チーム自身も作り変える

特に印象に残っているのは、中長期的なパフォーマンス改善においては、 単にプロダクトを作り変えるという意識だけではなく、チーム自身も作り変えていく必要があるという話。

今回登壇された方々は表現は違えど共通して、パフォーマンス改善は(プロダクトの)一生続けるべきものであるという話をしていて、 そのために、継続的に改善を続けられるチーム作り(仕組み)が重要であると。

モノリシックからマイクロサービスへ

元々モノリシックに構築されているサービスをマイクロサービス化しているという話では、 モジュール化する上でどこに境界を引くかが設計の争点となるが、 この境界は横断的なチームコミュニケーションによって、必要に応じて各モジュールの責任範囲を改め、柔軟に変更しているという話であった。

これについて、コミュニケーションを綿密にとることが重要だという話に異論はないが、 それでも Retty ほど利用ユーザの多い商用サービスで、インパクトの大きい変更をガシガシ加えることは、それなりにリスクがあるように感じた。

先端を行く B2C サービスではそのくらいのアジリティが求められているということだろうか。 もしくは、production deploy 前の状況であったとか・・・?

チームで技術を選定する

アーキテクチャにおいて、選定する技術は特定の領域のメンバーが決めるのではなく、 関わるメンバー全体で決定し、個々人が納得感を得ることが重要であるという話。

これには同意見でありながらも、現実では割とトップダウンで自分が選んでしまうことが多く、 仮に形式的であっても、議論する場を設けて決定した方が良いのかも、と反省。

形式的という表現をしたのは、意見を変える気がないという意味ではなく、 フロント経験者が少なく、未経験者や外注さんと組むことが多いため・・・。

また、その具体例として、クライアントとサーバ間の通信において、GraphQL を採用したという話は興味深かった。 確かに、チャレンジングな技術選択でノウハウを持つ人は少ない状況だと思うので、選定に納得していないと辛いフェーズは出てくるように感じた。

一休.com のフロントエンドパフォーマンス改善

今回は、ウェブフロントエンド全体における、マクロな観点におけるパフォーマンス改善の話。ベストプラクティスといった話から昨今の現状や経験談など、幅広く濃い内容で聴き応えがあった。

また、もう少しミクロな観点である、コード改善や Tips といった話については、 前回に話したスライド を参照とのこと。

一休.com と一休コンシェルジュ

パフォーマンスの計測

「推測するな。測定せよ。」とは良くいったもので、十分理解しているつもりではあったが、サイトの形態によって、どのメトリクスが重要視されるかというのは深く考えたことがなく頷くばかりであった。 (ECサイト、メディアサイトであればロード時間、ゲームであればプレイ中の FPS 維持など)

さて、自分の直近の仕事であった B2B サービスではどうかと思考を巡らせてみると、初回読み込み時間は重要でユーザ体験に直結はするが、離脱する種のサービスではないので、頻繁に利用する機能のパフォーマンス改善がよりよいユーザ体験に結びつくだろうか。

ただ、これらの改善は求められているわけではないのが現状で、逆に重要だという提案をするにしても、それと利益との相関関係を証明することは難しく、現実的には厳しいところだろう。うーむ。

計測ツール

ツールは多様であるが、Chrome DevTools (audit) を始めとして、そのバックエンドとしては Lighthouse が利用されていることが多いらしい。各人ローカルで DevTools を利用すると環境による影響が出るため、クラウドサービスを利用した方が良いとのこと。

恐らく、サービスであれば CI とも連携しやすく、定常的にパフォーマンスを計測することができるため、導入しない理由はないように感じる。想定外のパフォーマンスデグレードにも早い段階で対応ができそう。

PageSpeed Insight

  • とっつきやすい
  • 下り 1.40Mbps 環境で測定される
    • お昼時の、格安 SIM (4G回線)がこのくらい

WebPageTest

  • とっつきにくいが多機能、上級者向け
  • locaton(region) の変更、繰り返し測定など

余談だが、サイトを探す際に googlability が低く勿体無いと思った。

Lighthouse のスコアと指標

  • Lighthouse のスコアは他社サイトとの比較に便利
    • EC サイトは目標 50〜
    • メディアサイトは目標 70〜
  • 自社サービスのチューニングの際は指標を見るべき
    • スコアは算出方法が変わることがある
    • 主要導線である複数ページを対象とする

この辺りも肌感が全く無かったため、実際運用されているサービスの体感速度とそれに対応するスコア感の話は非常に参考になった。

パフォーマンスの最適化戦略

かなり省いているので詳細はスライド参照。

遅い要素を減らしていくのが基本方針。

一休.com / 一休コンシェルジュ、共に画像リソースが非常に多いため、この最適化による影響が大きいという話であった。 ツールとしては imgix を利用して画像自体のサイズを削減すると同時に、ファーストビューに入らない画像は lazy load とする。

メディアサイトは Fastly のキャッシュ戦略が特に有効であるが、EC サイトは性質上長くキャッシュをもたせることができないデータも多いため、(価格、ユーザ情報など)メディアサイトに比べると TTFB が落ちるのは一般的。

全く関係ないが、"Above the Fold" という表現を初めて知った。ファーストビューと同じ?意味合いではあるが、かっこいいとおもいました。(小並感)

JAMSTACK と SEO

JAMSTACK というキーワードは初めて聞いたのだが内容としては馴染み深いもので、ざっくりといえば、ウェブアプリは SSR しないプリビルドされた SPA を利用する方式で、これは静的データであることから CDN で効果的にキャッシュできるという話である。(た、たぶん)

ただし、当然 SEO については色々と検討が必要になり、現在は Google bot 対策として、dynamic rendering で Rendertron を実験中とのこと。

この辺の用語もわからず調べたのだが、dynamic rendering とは、サーバサイドで Google bot からのリクエストの場合にのみ、事前にレンダリング済みの専用の HTML をレスポンスに返すという方式らしい。

当然この HTML は本来のウェブアプリ(SPA)と同等の内容が期待され、あからさまに異なる HTML を用意している場合はクローキングとして扱われてペナルティを受けることがあるそうだ。

個人的には、Google 側が「あからさまに異なる」という判定をどう行っているのか気になった。Chrome 41 相当の Google bot とは異なる一般ユーザと区別がつかない bot が存在してクローリングしているのだろうか。

その他所感

パフォーマンス改善にガチに取り組む姿勢に驚いた。パフォーマンス改善を目的としてサービスの構成から作り変える可能性も含めて検証し、積極的に production に取り込んでいくという意思を感じた。

私自身は B2B サービスの請負い開発が多いためか、銘打ってパフォーマンスが重要視されることはほぼなく、姿勢の違いに衝撃を受けた。

恐らく、B2C サービス(特に ECサイト)の世界では、パフォーマンス改善が利益に直結する世界であるため、こういった姿勢に差が生まれるような気がした。

実際に、一休.com 開いて、これだけ画像が多いのに確かにはえー、と盛り上がったりした。

パフォーマンス改善の具体例とサービスへの売上貢献

  • ヤフー株式会社: 笹原翼
  • slide: https://

自社サービスであるヤフーショッピングに対して、なぜパフォーマンスチューニングを行い、どう取り組み、どう成果がでたか、その一連の流れを丁寧にかつ、面白く話をしていただいた。また、参加者がすぐに実務に適用できるような Tips やチェックシートまでもが整理されていて、即効性が高く非常に参考になった。

パフォーマンスチューニングに取り組んだ結果としては CVR が 110% 向上したそうだ。

パフォーマンス改善のリソースを確保する

明確な回収見込みが提示できないとリソースを割くことが難しいという話。よくあるジレンマだと思っているが、ヤフーさん程の体力があっても変わらないというのは意外であった。

A/B テストによって、ページの初回ロード時間と CVR、各種指標への相関を示すことで、実際に偉い人を説得し、リソースを確保したそうだ。確かに、これ以上ない仕事の運び方だと思う。

ファーストビューの9割表示を指標とした

これが興味深かった。

先の一休.com さんの例でいうと Lighthouse の何かしらの指標を目標としておいていた(と記憶している)が、ヤフーさんの場合はエンドユーザ視点で、9割表示されれば体験を阻害せずサービスとして十分機能している状態であるという判断したのだろう。

私の社内の話だが、ページを読み込んだ後に、投機的にリンクの先読みを行う仕組みがあり、計測結果としては先読み完了後までの時間が得られてしまい実際の体験に即していないという悩みがあった(らしい)

その点でも、ファーストビューの表示率という観点は良いもののように思えた。

計測ツールは SpeedCurve を利用

  • 強豪と比較がしやすい
  • 継続的に確認してグラフ化する
  • 有償だけど比較的手頃
  • キャプチャを目視でグラフを見やすく加工している

ヤフーショッピングの場合は明確な競合があり、リアルタイムに競合と指標を比較し続けることができるという機能はとてもマッチしていたように感じた。

ただ、それ程高価ではないとはいえ、有償ツールで維持コストがかかるため、継続的に結果を出していかないと稟議の説明が苦しくなるのかな、とか思った。(弊社視点)

レスポンスの圧縮形式を gzip -> brotli へ変更

あくまで、紹介されていた施策のうちの1つでありこれ単体で大きな効果があったわけではなかったようだが、そもそも brotli という圧縮形式を知らなかった。ググってみたところ、Google の開発した近代的な圧縮フォーマットで、gzip に比べて2割くらい軽くなる傾向にあるという。Encode/Decode にかかる時間は若干増加するという情報もあるが、込みでスループットが向上することは多いようだ。

私が聞いたことすらなかったため、ブラウザが対応しているものなのかと疑問に思ったのだが、全てのブラウザは余裕で対応していた。(IE からは目を背けながら)

https://caniuse.com/#search=brotli

リクエストヘッダの Accept-Encoding では 'br' が追加されるようだ。

その他所感

CVR の計測について気になるのだが、サービス自体、目まぐるしく変わるであろうコンテンツと、加えて、運用としての様々な試みや、機能追加も色々とあるはずだが、パフォーマンスチューニングのみの成果を測定するというのはできるものなのだろうか。

チューニング期間全体の上がり幅を見るのではなくて、個々の施策の成果を合計値で見るとか?

あと、スライドのクオリティがとても高かった。こういったデザイン的にも内容的にも洗練されたスライドってどうやって作っているんだろう。エンジニアソロで完結しているように思えないのでとても気になる。

全体の所感

非常に勉強になった。

いずれも初回読み込み速度の短縮を指標として置いていたが、このチューニングを考えると、WebFrontend というよりは、もっと広くサービス全体の構成を抑えた上で、技術スタックやその特性を1つ1つ丁寧に理解していないと、適切な考察や改善策を打ち出すことが難しく、広く深い知識が求められるように感じた。

道中にも少し書いたが、私自身は B2B 向けの請負ウェブアプリの開発が多く、仕事として既存サービスに対するパフォーマンスチューニングが求められる機会というのは少ない現状ではあるが、新たにゼロベースでサービスの設計から入る機会は多いため、これらのナレッジを生かしていきたい。

「はじめてのペアプロ / モブプロ」を読んだメモ

去年の反省の1つであるが、一般的なパラレルに開発して上がってきた PR をコードレビューしてマージするという開発スタイルにあらゆる意味で限界を感じていて、ペアプロ、あるいはモブプロを取り入れるべく検討していた。

早速 Discord で頼れる有識者達に相談してみたところ、WEB+DB PRESS の特集を紹介いただき読んでみた。関係者間で要点をシェアするためのメモとして本記事を書いている。実際に実施して適宜加筆していきたい。

gihyo.jp

ペアプロ

効果的なタイミング

  • 新メンバーがジョインしたとき
    • キャッチアップする最速の方法
  • 新機能を実装するとき
  • デバッグや不具合修正を行うとき
    • 複数の観点によってデグレ防止に有効
  • 定期開催
    • Daily / Weekly
      • Daily なら 1h, Weekly なら 3h とか
  • 技術的負債の返済日

進め方

1. コードを書く前に方向づけを行う

  • 最終目標を決める
  • 作業項目をリストにする
    • 開発中も都度更新していく
    - [x] 新規画面の追加
    - [ ] データ取得 API の呼び出しと表示
    - [ ] CSS を書いてデザインを実装
    - [ ] リファクタリング
    - [ ] 動作検証
  • 最初の目標を決める
    • リスト化して作業を開始
    • 小さい作業項目から着手して流れを作るのがよい

2. コードを書きながら会話し、考えを共有する

  • ドライバー
    • 考えていることを口に出す
    • 実況のように、よく喋ることが重要
    • 思考をそのまま口にする
  • ナビゲーター
    • よく聞き、ドライバーを支える
    • 実況に対してコメント、評価、盛り上げる
    • 同時にコードレビュー
    • 立ち止まって設計の共有
    • 視野を広く持つことが大事

3. ロールを交代する

ドライバーの方が消耗が激しいため、ローテーションするのが基本

  • 時間で交代する
    • 15分くらいの交代が目安
  • ステップで交代する
    • Pair Programming Ping Pong Pattern
    • 作業項目単位での交代
  • 適宜自由に交代する
    • ある程度慣れた人向け

注意点・コツ

  • ドライバーの正面にキーボードを置く
  • 定期的に休憩を取る
    • ロール交代の際に適宜取ると良い
  • 開発環境差異の問題
    • 非常に悩ましく、完全な解決方法はない。下記はいずれも対策の一例
      • 各自キーボードを持ち寄る
      • チームメンバーでエディタ、環境を統一してしまう
      • ペアプロ用にデフォルト設定の環境を別途用意する
    • リアルタイム共同編集機能を持つエディタを利用する
      • ペアプロの最終型。これが可能であればベストだがエディタを揃える必要があるか?
      • 同時に編集できなくとも、ツリーをファイルサーバ上に配置したり、dropbox を利用する等でリアルタイムにソースコードを共有して PC をスイッチしやすくするのはどうか?(IMHO)
    • ステップで交代する場合は push / pull してドライバーの PC にスイッチするのはどうだろうか?(IMHO)
  • メンタル的にペアプロが合わない人もいる
    • 強要してペアプロハラスメントに陥らないこと
    • ただし、単に食わず嫌いの人は多い

モブプロ

ペアプロでは、ペア以外のチームメンバーへ情報が伝達されにくいという問題がある。例えば、チケットや PR に試行内容とその結果、コードレビューのやり取り等が残らない。よし、ならば全員同席だ。 ➔ モブプロ

  • 3〜5人が適正
  • できる限り大画面を用意する
    • 調べ物用の PC がもう1台あると良い
  • ナビゲーターそれぞれが課題を調査する

正直なところ、ペアプロほどメリットがスッと頭に入ってこなかったが、とりあえずやってみて考える。

【2018 - 2019年】総括と抱負のような伺か

あけましておめでとうございます(╹◡╹)
今年もよろしくお願いします。(◜◡◝)

年末 Twitter の TL を眺めていると、技術的強者の方々がこぞって 2018年の総括をブログにアップしていたので、ワイも振り返りたいんじゃあ〜、と思いたち、ほぼ衝動でブログ開設にまで至った。

彼らのような目覚ましいアウトプットや輝かしい社外活動はないけども、それでも、自分にとって2018年は大きな転換期となったため、振り返ってく。

主な仕事の振り返り

2018/1〜2月

前年より引き続き、前部署で Chromium 製ブラウザの TV 向け拡張の開発と移植サポートを行っていた。主な言語は C++14 で、ビルドシステムは Ninja だが、Chromium において Ninja ファイルは generate されるものなので、エンジニアが向き合うのは専らメタビルドシステムである GYP/GN であった。(現在 Chromium は GN に統合)

この辺りの技術スタックは Chromium くらいでしか利用されていないため情報が少なく、ちょっとした嵌まりどころが致命傷でリリース遅延に繋がったり、リリース優先筋力回避によって即座に技術的負債化、暗黙知化したりと、本質的ではないリスクやコストが大きく、非常に厳しい開発環境だとつくづく感じた。

また、ネットに情報が少ない技術というのは習得しにくいだけではなく、一般的に需要が少ない(ピンポイントで刺さる場合はあるが)という意味でもあり、自身のキャリアを考えるとあまり習得にモチベーションが上がらず。

そんな頃、逃避エネルギー駆動で即興で書いたプログラムがウケたので記事にしたものが以下でございます。

qiita.com

うん、逃避エネルギーの有効活用は重要だな…。

2018/3〜5月

急遽別チームのヘルプで iOS アプリの機能開発を担当することとなった。Swift のバージョンはいくつかなー?、3.x 以降だったら速習しないとなーふふふ、などと思っていたところ、Objective-C であり、これはこれで結局1冊本を読んで速習するところから入ることとなった。

今思えば最初から Objective-C と言われていたら断っていたかもしれないが、結果的には久々の純然たるチーム開発で、iOS 開発も楽しく、そこからスムーズな異動に繋がったので、打診に対して迷いなく YES と答えたあのときの俺、偉いぞ。

総括としては、落ち着いた頃にこんな記事書いた。 qiita.com

また、逃避モチベにより登壇を決めた「Manabiya Teratail Developer Days」 の Web 枠で LT もした。
完全にネタ枠であったが、何回か笑いを取れたので目標は達成できた。

speakerdeck.com

2018/6〜10月

先のブラウザチームから、種々請負開発がメインとなる部署へ異動。

私自身の担当はウェブフロントエンドの分野で、(とはいえ、必要に応じて色々手広くやるけども…)
早速とあるウェブサービスフルスクラッチで開発するプロジェクトにジョイン。

今まで、自社ブラウザの上で動く特殊な用途のウェブアプリや、iOS/Android のハイブリッドアプリ向けウェブアプリの開発経験はあったが、もっとベーシックなウェブサービス(特に PoC ではない)という意味でのウェブアプリ開発経験はなかったため、その技術選定からローンチまで経験できたのはとても嬉しく、大きな経験値となった。

また、実際には諸事情で Lambda をメインで書くことになり、ウェブアプリはレビュワーとしての関わりが大半になってしまったが、これらのレビューはたぶん自分で書くよりも大変で、これはこれでチームビルディングに関する学びと多くの反省を得た。

下記は、相当数のレビューを行った知見から一部抽出して書いた記事。 qiita.com

他にもまだまだたくさんメモはあるけど、まとめられていない。

2018/11〜12月

続いて、別のウェブアプリ開発の案件へ。

自分の立ち位置としては PL よりで自身では直接コードは書かず、未経験者や新卒の教育とサポートが主な目的として参画。

フルスクラッチの開発ではあるものの比較的シンプルな要件で、かつ POC なので、正常系中心にある程度安定していれば問題ない・・・そう考えていた時期が私にもありました。

POC に対する品質の認識は関係者間でバラバラなので(特にディレクターと開発)、この認識をすり合わせておかないと、作業量感が合わなくなるの結構重要。(POC に限った話ではないかもしれないが)

それと「POC なのでこの画面の UI デザインはないよ!よくある無難な感じに作ってね!ლ(╹◡╹ლ)」という、恐らく見積り上のコストカットポイントがあったのですが、

皆が思う以上に「UI に興味がないエンジニア」は多く、ブナンッテナンダ?ウマイノカ?となりがちなことと、通常デザイナーが行う要件を UI に落とし込むための詳細化工程が1枚抜けていることによる手戻りもあり、とことん POC という甘美な罠に嵌った気がした。

UI に関しては PR でちょろっと指摘して対応できるものではないので、自ら Adobe XD で Bulma ベースのコンポーネントを想定した簡単なレイアウト・デザインを作ることになった。

おかしい…、こんなはずでは。

今年やりたいこと

さて、2018年の仕事は大まかにこんな感じであったが、やり残したことも多い。(エンジニアリング以外でも・・)

弊社フロアを VR 化して、仮想出勤するとか、社内 Slack にジョークボット作ったりとか、Nokia Sleep を利用した自動遅刻通知もサーバサイドは GAS に変更しよう、という状態のまま未完成で記事も下書きのまま。

Nightmare.js で書かれたテニスコートクローラーを Puppeteer で書き直したいし、REST API として切り出したのに、アプリ化もできていない。PWA にしたかった。

夏場に CSS 鍛錬のため、無作為に選んだ有名サイトのトップページの目コピをやろうとしたが、結局できていない。

技術の裾野を広げるために Hello World streak やってみるの凄い良さそうと、思いたったがこれも行動できてない。

ポチった技術書も無事積読済みだし、英語にもちゃんと向き合わないといけない。

…と、無限にやりたいことはあるわけだけど、先立つものは時間・・!!

勤務時間を減らす

今年はこれを一番大事にしたい。

2018年は、自分の仕事と身につけたい技術が合致したので、仕事と趣味の境界なく無制限に働いてしまったが、たぶん今見えてる感じ2019年はそんなことはなく、仕事の経験を通して学べることの密度はかなり薄くなると思われる。

同時に、へーしゃの報酬体系も変わるので、同じ時間働いたとしても結構な金額をロスすることになるので、逆に良いチャンスだと捉えて、引き受ける仕事を最小限に抑えて、極端に残業時間を減らしてみようと思う。

年末にちょっとトライした感じ、最大のポイントは仕事の進捗が遅れていようが構わず時間になったので帰る、ということみたいだ。

あとちょっとキリの良いところまでやる・・。は大体ダメな結果になった。

技術書を読む

先に書いたが現場で学べることが少なくなっている、ならどうしようかという話であるが、積読されている技術書を読んで体系的に学べという話である。(あるいは転職か・・)

技術トレンドや、商用実例、ノウハウ的なことを学んだりモチベーション維持には勉強会も良いのだが、それよりもレベルの高い人と話をしていると、自分が雰囲気でやっていて、基礎力が足りていないと感じることが多かったのも理由の1つである。

点と点を結んで線にして面を増やしていきたい。

ウェブサービスを作る

これよこれ。

やっぱり、フロントエンドエンジニアだもの。
ウェブサービスを作って、そして運営してなんぼよね。

ネタは色々あって、去年もあれこれ考えてたけど実現できてなかった。

まとめ

というわけで、最後の方雑になってしまったが、Qiita に技術記事を投稿するときとは違って、個人ブログは流入量は少ないしわざわざマサカリも飛んでこないと思うので幾分気が楽である。

このブログを書くこと自体は目標に挙げていないけれど、自分の思考を整理して吐き出したり、勉強会のメモ書きを投稿したりとか、必要に応じて便利なツールとして扱っていければと思う。

はてなブログの Markdown 動作確認

ちょっとお試し

はてなブログMarkdown が使えると知って試しています。

ブログ開設のため、notemedium などのちょっと憧れていたブログプロバイダを先に試しましたが、 改行と段落が独特?(自分に馴染みがないだけかも)だったり、実質必須のショートカットキーを別途覚えるの面倒だと感じたため、 書きなれた Markdown が使えるブログを探して、はてなブログにたどり着きました。

ちょっと調べた程度ですが、 意外にも? Markdown をサポートしているブログは意外と少なく、

くらいでした。

今どきは文章の記述は Markdown が基本だと勝手に思っていましたが、 ソフトウェアエンジニアのうちのさらに一部のクラスタしか利用しないマイナーなメソッドなんでしょうかね?

改行

そういえば、QiitaGitHub と同じく、 純粋な Markdown ではなく、いわゆる flavored の一種ようで、改行コードを改行と解釈してくれるのはとても良いですね。

純粋な Markdown だと行末に半角スペース2つを打ち込まないと開業できず、 直感的ではないし WYSIWYG でもないのであまり好きではないです。

ソースコード

const printHello = text => console.log(text);
printHello('hello world');

どのくらいの言語やテンプレートをサポートしているかはわかりませんが、 ひとまず、JavaScript の Syntax Highlighting は動作するようですね。

ちょっと触った感じでは言語指定の文字列は、略記はダメでフルで名称を記述する方式かな。

❌: js, md
⭕: javascript, markdown

あと、Qiita のように js:hello のように label は記述できないっぽいですね。 これはちょっと残念。

画像

LGTM

![LGTM](https://media.giphy.com/media/JIX9t2j0ZTN9S/giphy.gif)

ふむふむ、意図通りには使えそう。 Markdown の仕様では resize はサポートされていないので、 必要があれば HTML タグで記述する必要がある点も変わらないと思われる。

<img width="300px" src="https://media.giphy.com/media/JIX9t2j0ZTN9S/giphy.gif" />

結論

自然な書き心地で、割と良さそう。 自分が良く見る有名なテックブロガーが採用しているようなシンプルなテーマも好きですし、 はてブで良く大喜利しているのもあって親和性が高いので、ひとまずはてなブロガーとして居座って見ようと思います。