Velocity

方向を定めて

2018年の振り返りと2019年の抱負

2018年の振り返り、そして2019年の抱負を綴るには少し出遅れてしまった感が否めないが、better late than never ということで書いていく。

2018年の振り返り

1月 ~ 2月

GASで社内業務の効率化してた。
いわゆる6分の壁を乗り越えるための time-driven-trigger に苦戦していた記憶がある。 kido0617.github.io

また、Node.js/Express/GCP/OAuth2.0 辺りの勉強も兼ねて、GASで行なっていた一連の処理をWebアプリにリプレイスする業務も行なっていた。 その頃は、それぞれの要素がシステム全体でどのような役割を担っているかも正確に把握出来ていなく、雲を掴むような感覚でコードを書いていた気がする。

あとは、TypeScriptとかAWSの勉強させてもらったり。

3月 ~ 5月

別の現場に異動して、kintoneで地図プラグイン・アプリ開発してた。
gitの使い方とかREST APIの基本的な考え方とかJSのPromiseとか、最初の1ヶ月は非常に学びが多かった。 US圏向けのジオコーディングAPIの調査をやらせてもらったおかげか、ここで英語ドキュメントへの耐性がついた気がする。

そのチームはテストコードを書く文化が無く、E2Eテストで品質を担保するような運用だった。 後半の方は毎週本番環境にリリースを行っていたため、その度にdev環境と本番環境に対して手動でE2Eテストを行なっていたが、それが辛かった。

試験項目が多いため、どうしてもテスト工数が多くなってしまい、仕様変更やバグ修正が追いつかなくなってきてしまう。 よって必然的に残業時間が増えてしまっていた。

ここでテスト自動化の重要性を理解した。

6月 ~ 7月

何でも屋さんの時期。
Go/Revelでミニマムな出欠管理アプリ開発を開発したり、Javaシステムの動作検証・デバッグの手伝いをしたりしていた。

この時期は1つのことに集中できないために悶々としていたが、この時期のおかげでGo/Javaの文法やオブジェクト指向プログラミングの考え方について理解することが出来たため、意外と良い経験になっているかもしれない。
OOPを学ぶ過程でデザインパターンも勉強したのだが、既に頭の中で風化しつつあるのでよろしくない。


オブジェクト指向の勉強にはこの書籍を用いて勉強した。少し古い本だが、オブジェクト思考の概念を理解するには良い書籍だったように感じる。
なぜ、あなたはJavaでオブジェクト指向開発ができないのか―Javaの壁を克服する実践トレーニング


また、6月に21歳の誕生日を迎えたため、こんな記事も書いていた。

tmkk.hatenablog.com

業務ではプレーンのJSとjQueryしか触っていなくて、 モダンな環境で開発がしたいという気持ちが非常に強い。切実に。


現時点では アーキテクチャ・APIの設計 とか パフォーマンスの改善 を将来的にはやってみたい。 しかし元々フロントエンドに憧れていたので、SPAの実装とかにも興味あるし...といった感じで定まらない。

モダンなフロント開発をしたい欲に満ち溢れている様子が見て取れる。

8月

8月はファイル共有システムのデモを開発していた。念願のSPA開発だ。

Vue.js/Bulma でのフロントエンドをメインに担当していたが、API Gateway/LambdaでのAPI・サーバーサイドの開発や、Serverless frameworkを用いたデプロイ環境構築など、AWS周りにも横断的に携わっていた。

この時期はかなり能動的に動ける環境だった、ありがたいことにフロントエンドの技術選定から任せていただいた。
JS/CSSフレームワークは、波が来てそうなVue.jsと相性が良さそうなBulmaをチョイスした。

Vue.jsは本当に使いやすく日本語ドキュメントも充実しているため、人気が出るのも納得した。
Vue CLIによるDeveloper Experienceも素晴らしく、スピード感が求められるデモ開発では非常に助かった。

丁度Vue CLI 3.0が出たタイミングだったので記事も書いた。Vue CLI UIの体験が良すぎて、びびった。

tmkk.hatenablog.com

qiita.com

9月上旬

社内でミニマムな採用試験アプリの開発していた。

ここでは、俗に言うMERNスタック(MongoDB/Express/React/Node.js) で開発を行なった。
Reactに触れるのはほぼ初めてだったが、Vue.jsでの開発経験があったため、スムーズに開発を行うことができた。

少人数だったが、自分以外フロントエンドの開発経験が無い人だったため、設計も担当することになった。 Atomic Designを推進したが、開発者毎のイメージの違いやレベル感の差異、用意されていた開発期間の短さから、結局コンポーネント毎の粒度にばらつきが出てしまった。

設計、チームでの意思統一の難しさを実感することができ、良い経験になった。

9月下旬 ~ 11月

某仮想通貨取引所のフロントエンド開発をしていた。

この現場は TypeScript/React/Redux/redux-thunk/ImmutableJS/LESS/gRPC/WebSocket とモダンな開発環境で楽しかった。 また、問題提起に対して積極的に議論し共有する風潮があったため、様々な課題がみるみる内に改善されていく様は初めての体験で驚いた。

ただ、以下の事柄が暗黙知となってしまっており、書く人によってコードの書き方にバラツキが出たり新規参画者のキャッチアップが大変になってしまっていた。

  • Atomic Designを参考にしたコンポーネント設計
  • コーディングスタイル
  • propsの渡し方やPureComponentの使用などについて

これを解決するために、フロント周りの開発ルールをWikiに書き起こし、明文化する活動も行なっていた。

また、フロントエンドの設計にも携わらせていただいた。Reduxあるあるだと思うが、特にローディング周りの設計に苦労した。
各非同期処理の前後に HOGE_REQUEST/HOGE_SUCCESS/HOGE_FAILURE を書き、その中で isLoading を切り替える実装は負債になり得る可能性が非常に高いと感じたため、以下の記事を参考に実装を行なった。

medium.com

結果として HOGE_REQUEST/HOGE_DONE というアクション名をキーに、isLoading のstateを切り替える実装にした。
ここら辺については別途、記事として書きたい。

悲しいかな、再び短期間で異動となってしまったが、ここでの開発から得た学びは非常に大きかった。

12月

現在進行形で採用管理アプリの開発をフロントエンドからサーバーサイドまで担当している。

  • フロント: RxJS
  • BFF: Node.js/Express
  • API: Go/Echo

DIやTable Driven Testなど概念は理解できているが実装はしたことがない、といった事柄がたくさんあるので全て吸収していければと思う。

そしてRxJSは難しい...。


2018年は幅広い技術に触れることができ、広く浅くの年だった。

2019年の抱負

2019年は「基礎力」をテーマに勉強を進めていきたいと考えている。

特に下記の事柄の「基礎力」だ。

  1. コンピュータサイエンス
  2. 英語力
  3. 文章力

これらはエンジニアとして生きていく上で、風化しにくく価値が変わりにくいものだと自分は考えている。

コンピュータサイエンス(CS)

自分はCSのバックグラウンドが無い為、必ずどこかで勉強しなくてはいけない運命なのだ。

とりあえず年末年始の時間を使って下記の本を読んでいる。計算・アルゴリズム・データ構造・P=NP問題 などの概念を、有名な物語に紐づけて解説している書籍でとっつきやすくオススメ。
ワンス・アポン・アン・アルゴリズム: 物語で読み解く計算 Martin Erwig

また、競技プログラミングにも興味が出てきた。AtCoderのBeginner向けの問題をやってみたら結構楽しかったので、コンテストにも参加してみたい。

英語力

よく大事って言われるけど、学習が続かないランキング第一位。（俺調べ）

これに関しては、半年前から通勤中に iKnow というアプリで学習を進めている。

iknow.jp

継続的に iKnow での学習を進めつつ、3月頃にTOEICも受ける予定なのでそれに向けての対策もやっていきたい。

文章力

これについては最近まであまり意識していなかったが、ドキュメントを書いたりSlackでのコミュニケーションなど文章力が必要になる機会は非常に多いことに気づいた。

TOEICが終わった頃に一冊本などを読んで基礎から学び直したい。


2019年は基礎力を高め、変化に強いエンジニアを目指そう。

工場勤務時代とソフトウェアエンジニアになってからの、仕事の充実度の比較

はじめに

高校卒業後、工場でメンテナンスを行う物理系エンジニアとして働いていた。
1年半勤めた後に転職、ソフトウェアエンジニアとしてのお仕事をしている。(2017/11~)

エンジニアからエンジニアの転職だが、畑が全く違うので (当然だが) 転職したての時の日々の生活のギャップはすごかった。

工場で働いていた時の事を忘れないうちに、それぞれの職種での業務経験を比較してみる。

仕事の充実度の比較

1日24時間しかない内、仕事が占めるウェイトは非常に大きい。

仕事が充実していると人生はさらに楽しくなるという考え方があるが、自分はそれを全力で肯定するタイプだ。 後50年弱は働かないといけないと考えると、人生を楽しむためには、仕事にやりがいを持つことはマストだと思う。

転職して、ソフトウェアエンジニアになり、コードを書いて。なんとなく以前よりも仕事を楽しむことができているような気がする。 この理由を探るために なんとなく をもう少し抽象化してみる。

まず、仕事においての充実度を比較するために自分の中の判断基準を整理してみる。


1. 明確な課題があり、それについて考え自分からアクションを起こせる機会があるか？

  • 昔から、課題について考え答えを出す という作業が好きだった
  • 課題をクリアした時の喜びと、様々なアプローチがあるというポイントが個人的に重要
  • ゲームが昔から大好きなのもこれが関係していると思う


2. 取り組む課題には様々な結果が存在するか？

  • 例えば　1+1=? おそらくこの式は誰に訊いても同じ答が返ってくる
  • 上は極端な例だが、この問題はアプローチによって結果が変わることはない
  • 業務の成果が物事への取り組み方や考え方によって変動する方が個人的にやりがいを感じる (大体の職種がそうだろ というツッコミがあるかもしれないがメンテナンス職などは、人によって結果が左右されることは比較的少ない)


3. 人とコミュニケーションを取る頻度が多いか？

  • 物事を考えている時間も好きだが、誰かと話したりする事も大好き
  • もしくは問題解決のために相談する機会が多いかどうか


以上3点が、自分の中での仕事の充実度を測る三本柱だと思う。

この3つの視点から、ソフトウェアエンジニアとして働いている今と工場で働いていた時の仕事の充実度を比較していく。

これはあくまで個人的な比較なので、どちらかの職種を否定するようなことは一切ない。


明確な課題があり、それについて考え、アクションを起こせる機会があるか？

ソフトウェアエンジニアとして働いている現在

ソフトウェアエンジニアとして仕事をしていると、どのような開発をしている場合にも、大なり小なり課題・問題にぶち当たると思う。

  • どうすればユーザーの体験をより向上できるか？
  • どのような設計にすると改修がしやすいか？
  • なぜこの変数が undefined なのか？

開発中は課題だらけだ、好き嫌いに関係なくエラーが襲ってくる。
まぁこれは物事を考える機会になるので嬉しい悲鳴といったところか。。。

自発的にアクションを起こせる機会も非常に多く、コーディング中はそのスパンが非常に短い。 Googleで検索して関連記事を漁ったり、ログを出してみたり、設定を変更してみたり、非常に様々だ。 課題の規模によるが、良いアイデアがあれば改善に向けたアプローチも積極的に行うことができ結果に繋がることが多いと感じている。


工場で勤務していた時

明確な課題は存在していたが、大体の作業は手順書がありルーティン化されている。 考える機会はイレギュラーなケースが発生した際など非常に少なく、誰がやっても結果大体は同じ結果になる。

この時は時計の針が17:30を指すのをひたすら待ち続けているような感覚だった。


上記を踏まえた個人的な比較はこんな感じ。

現在 >>> || 超えられない壁 || >>> 工場勤務時代


取り組む課題には様々な結果が存在するか？

ソフトウェアエンジニアとして働いている現在

成果物には様々な結果が存在する。

見た目上同じ結果になったとしても、本質的には差異が出る場合がほとんど。例えば...

  • どのようなシステム構成にしたか システムのパフォーマンス、実装コスト、金銭コストが異なる

  • ダイアログに表示するボタンは何色にしたか、どのくらいの大きさにしたか 細かな差異によってUXは左右される

  • function writeArticle(text) {} と書くか const writeArticle = text => {} と書くか → 同じ動作をする場合が大抵だが、thisが bind されたり、巻き上げがあったりなかったり、可読性が異なる

よく プロの仕事は細部に宿る と言われるが、エンジニアの世界でも全く同じだと思う。 変数名の付け方や、エラー処理のハンドリングの方法など、細かい事を詰めていく事に楽しさややりがいを感じるタイプなので、割と向いている気がする。


工場で勤務していた時

定期点検などのメンテナンス業務は、誰がやったとしても同じ結果になることが多く、異なる結果になってとしてもそれを体感できる機会は少ない

試しに、モーターのメンテナンスの作業のクオリティによって結果が異なる例を挙げてみる。

  • 油を挿す量が少なかったため、1年後に軸の部分が焦げ付いてしまっていた。
  • サビ落としが甘かったため、塗ったペンキが半年で剥がれてしまった。

このように時間経過を伴うことが多く、自分でその事象を確認することは少ないため、一個人としての結果としては非常に感じにくい。


個人的比較は下の通り。

現在 >>> 工場勤務時代


人とコミュニケーションを取る頻度が多いか？

ソフトウェアエンジニアとして働いている現在

コーディング中は基本一人。
構成や詰まった所をSlackで相談することもあるが、頻度としては比較的少ないと感じている。

工場で勤務していた時

ほとんどの作業を誰かと一緒に行うため、常にコミュニケーションを取りながら業務をこなしていた。休憩が午前中と午後に一回ずつあるため談笑をする機会も多かった。

余談だが、自分が勤務していた工場では 休憩の事を 一服 と呼んでいた。（タバコを吸う人が多いため）
自分はタバコを吸わないのだが、一服一服〜と言いながら休憩に入るのは中々乙なものだった。


ここの比較はこんな感じ。

現在 <<< 工場勤務時代


仕事の充実度を比較して分かったこと

前文の通り、ソフトウェアエンジニアに転職してから仕事が楽しいとは感じてはいたが、それが何故なのかはあまり理解していなかった。


前職と今を比較してみた結果として、仕事が楽しいと感じていた理由は、

自分のアプローチ次第で結果が変動し、それを一日を通して短スパンで体感することができるから

だと分析することができた。


人とコミュニケーションを取る頻度は以前より少なくなってしまったが、これはトレードオフだと感じている。(チームにもよるのだろうけど)

意外と面白かったので、次は1日の過ごし方でも振り返ってみようかな〜というお気持ち。


Twitterやってます、気軽にフォローしてください☺️ twitter.com

Vue CLI での環境構築覚え書き (2.x/3.x)

業務でVue.jsを使う機会があり、Vue CLIについて調べたのでまとめた

Vue CLIとは

Vue.jsを使った開発環境を整えるためのCLI (Command Line Interface)

2018/08/01現在、Vue CLI 3のステータスがRC (Release Candidate)*1
よって、正式バージョンのリリースが秒読み状態
数ヶ月もすれば環境はガラッと変わっていると思うので、ご参考までに。

前提条件

Node.jsとnpmがインストールされていること

インストール

npm i -g vue-cli

2018/08/01現在、stable versionの 2.9.6 が入る

今すぐ3.xを試したい好奇心旺盛な人は、
npm i -g @vue/cli

3.x へのアップデートに伴い、vue-cliから@vue/cliにパッケージ名が変更されている
2.x が入っていて 3.x に上げたい人は、npm rm -g vue-cli してから、3.xをインストールする必要があるみたい

プロジェクトの作成

vue create {project-name}

Vue CLI 3ではプロジェクト作成の推奨コマンド

Usage: create [options] <app-name>

create a new project powered by vue-cli-service


Options:

  -p, --preset <presetName>       Skip prompts and use saved or remote preset
  -d, --default                   Skip prompts and use default preset
  -i, --inlinePreset <json>       Skip prompts and use inline JSON string as preset
  -m, --packageManager <command>  Use specified npm client when installing dependencies
  -r, --registry <url>            Use specified npm registry when installing dependencies (only for npm)
  -g, --git [message|false]       Force / skip git initialization, optionally specify initial commit message
  -f, --force                     Overwrite target directory if it exists
  -c, --clone                     Use git clone when fetching remote preset
  -x, --proxy                     Use specified proxy when creating project
  -h, --help                      output usage information

2系までのvue initに比べ、柔軟にプロジェクトを作成することができる

コマンドを入力すると、設定をデフォルトで行うかマニュアルで行うか聞かれるのでカーソルキーで選択し、Enterキーで確定する

defaultを選択した場合、babel + eslint の標準的なプロジェクトが作成される

Manually select featuresを選択した場合、プロジェクトに必要な要素を選択できるのだが...

正直チェックの付け方が分からなく、3分は悩んだ
Enterを押すと次の画面に行くし、適当なショートカットを探しても見つからない

結果から言うと 1~9 でチェックをON/OFFできる
この記事を読んだ方にはA~Zをポチりまくるという悲しいことは是非しないでいただきたい (恥を晒していくスタイル)

チェックできる要素は以下の9つ

  1. Babel
  2. TypeScript
  3. Progressive Web App (PWA) Support
  4. Router
  5. Vuex
  6. CSS Pre-processors
  7. Linter / Formatter
  8. Unit Testing
  9. E2E Testing

チェック後はEnterで先に進み、選択した機能に応じてyes/noを答えていく
TypeScriptがサポートされていたり、Linterの選択肢にPrettierが含まれていたり色々お〜となった

プロジェクトを作成した後は、
cd {project-name} でプロジェクトディレクトリに移動し、
yarn serve でアプリが立ち上がる(これはyarnの場合、npmの場合はnpm run serve)

vue init {template} {project-name}

Usage: init [options] <template> <app-name>

generate a project from a remote template (legacy API, requires @vue/cli-init)

Options:

  -c, --clone  Use git clone when fetching remote template
  --offline    Use cached template
  -h, --help   output usage information

2.x のプロジェクト作成時に良く使われてたコマンド

templateを基にした構成でプロジェクトを作成することができる テンプレートで良く使われるものは下の3つ

webpack

2018/8/1時点で一番starが付いているvue-cli用テンプレート(7,774)*2

webpackを使った単一ファイルコンポーネントのテンプレート
webpack + vue-loader + hot-reload + ESLint + Jest + Nightwatch

GitHub - vuejs-templates/webpack
A full-featured Webpack + vue-loader setup with hot reload, linting, testing & css extraction.

pwa

PWA(Progressive Web App)用のテンプレート

GitHub - vuejs-templates/pwa
PWA template for vue-cli based on the webpack template

webpack-simple

webpack + vue-loader とシンプルなテンプレートで見通しが良くカスタマイズしやすい
これも単一ファイルコンポーネントとして.vueファイルが生成される

GitHub - vuejs-templates/webpack-simple
A simple Webpack + vue-loader setup for quick prototyping.

こちらもいくつか質問されるので、良きように答える
するとプロジェクトが作成される

cd {project-name} でプロジェクトディレクトリに移動し
npm run dev でアプリが立ち上がる

段々雑になった気がしないでもないが、とりあえずこんな感じ

Vue CLI 3 の目玉機能の Vue CLI UI の体験も素晴らしいものだったので、気が向いたら記事書く.

*1:内部での最終テスト段階、β版の次のイメージ

*2:なんとなく非常に惜しい気がする

20歳のエンジニアは何を学ぶべきなのか

6月13日で21歳になる。
一般的にマイルストーンとされやすい 30歳 まで10年間も残されている。

はえ～、まだ21歳だからなんとかなるっしょ～鼻ほじ～
とか言ってたらいつのまにかおじいちゃんになってそう。


なので、誕生日を迎える前にスキルを棚卸しして、
今後のキャリアをなんとなく考えていこう という記事。


今現在の言語周りのスキルをまとめるとこんな感じ

JavaScript
　唯一まともに書ける言語
　CMSのカスタマイズを業務で5月末まで行っていた
　ReactやVueを使った開発経験は無し

GAS
　業務で扱っていたため、普通に書ける
　業務効率化の用途が多いため、関心は薄い

Golang, Python
　簡単なスクリプトは書けるが、業務経験としては無し

英語
　Reading → ライブラリとかに書いてある平易な英語なら読める
　Listening → 語彙力の無さ ＆ ジャパニーズ耳だからやばい
　Speaking → 文章として組み立てれない、単語ベースになってしまう


整理してみると本当にしょっぱい。
エンジニアなりたてだからこんなもんなのかな～とか思ってたら、
いつの間にか7ヶ月経っててびびる。

業務ではプレーンのJSとjQueryしか触っていなくて、
モダンな環境で開発がしたいという気持ちが非常に強い。切実に。


そもそも自分がどういったエンジニアになりたいか明確に定まっていない部分が問題なんだと思う。

現時点では アーキテクチャ・APIの設計 とか パフォーマンスの改善 を将来的にはやってみたい。
しかし元々フロントエンドに憧れていたので、SPAの実装とかにも興味あるし...といった感じで定まらない。

そういったことをやっている人が周りにいないので、話を聞くことが出来ないのが若干のつらみである。


正直今までの半年間、家でコードを書いている時間があまりなかった。
目標だけはいっちょ前で行動が伴っていない最悪のパターン、コード書こう。

個人的には今後需要が増していくであろうGoをガッツリ勉強していこうかなと思っている。
あとやっぱり英語はそこそこできるようになっておきたい。
ドキュメントすらすら読みたいし、何よりかっこいい。


家でコードたくさん書いてGoodでCoolなエンジニアを目指してこう！

エンジニアになった


エンジニアになった。


まぁ実際のところ、11月からエンジニアとして働いているので、そろそろ半年になる。


前の記事でRubyがなんちゃらかんちゃらと言っていたが、今はJavaScriptを主に書いている。

半年経って思うことは前職より明らかに自分に向いている。


前職は、地方の工場でメンテナンスを行っていた。


毎日コンセントを分解したり大きなパイプを修理したりしていた。
元々自分は手先が器用でもなく、パワー系の人でもないので肉体労働はしんどかった。

何より来る日も来る日も。同じような作業をすることが苦痛でしかなかった。
飽き性にとってルーチンワーク程恐ろしいものはない。いやそんなことないか。


対してエンジニアは毎日自分にとって新鮮な問題に取り組むことができる。
頭を働かせて、うーんうーんと物事を考えることは嫌いじゃないので性に合う。


また 解が一つではない という点も非常に面白いと思う。

  • 問題にどのようにアプローチするか？
  • 配列、オブジェクトをどのように回すか？
  • 変数名、関数名の付け方は？
  • インデントはどのように空けるか？


人が変わればコードが変わる。
当たり前だが本当に面白い世界だと思う。


毎日新しい技術がぽこぽこ出てくるのも素晴らしい。

新しいもの好き、情報収集好きな自分にとっては毎日漫画の新刊が出るようなものだ。
昼休みはQiitaのトレンド記事とはてぶITの人気エントリーを漁ることが日課になっている。


新しい技術を学び続けないといけないのはもちろん簡単なことではないと思うけど、
毎日ぼけーっと過ごすよりも、ずっとずっと幸せだと思う。



半年前はスチールをパイプを繋いでいたかと思えば、

今ではstreamをpipeで繋いでいる...


という無理やりなオチ、Node.js勉強中です。

github.com