既存nuxtjsプロジェクトにVuetifyjsを追加する方法

@nabeemichi です。

一人でWEBアプリの企画から作成をしているるのですが、 新規でアプリをつくるときは、どのフレームワークを利用しようか考えるわけです。 今回はNuxt.jsを利用することを心に勝手に決めたわけでなのでキャッチアップするわけですが、 はじめてのフレームワークはキャッチアップに集中してしまうから、HTMLをマークアップしてることの面倒くささとかは忘れてるのですが、ある程度キャッチアップすると、、、

あれ？画面つくるのめんどくさい！

と、冷静におもうようになります。 だって、普通にHTMLマークアップして、CSS書いて、アニメーションつけたりすると作業量が多い。 なので、CSSフレームワークであるVuetify.jsをキャッチアップに利用していたNuxt.jsプロジェクトに後入れしようと思ったのだが、 Vuetify.jsのドキュメント見たら、Nuxt.jsに入れる方法って書いてないんだね。既存のVueプロジェクトに入れる方法ならあったので、それみながら作業すればなんとなくわかるけど、せっかくトライアンドエラーしたので

まずはインストール

Nuxt.jsプロジェクトにVuetify.jsをターミナルでインストールするのですが、npm利用しているかyarn利用してるかで変わりますが、ここはyarnベースで考えます。

yarn add vuetify

css-loaderを利用するので、入ってなければ同じくインストール

yarn add css-loader

マテリアルデザインのアイコンをインストール。 カレンダーのアイコンとかそうゆうやつ。

これは、Vuetify.jsの公式ドキュメントでコンポーネントのExampleのソースをコピペしながら開発したい場合は、入れておかないとアイコンがないよー！ってエラーになる。

yarn add material-design-icons-iconfont

Vuetify.jsをアプリ内で利用するための下ごしらえ

Nuxt.jsプロジェクトのpluginsフォルダ以下にVuetify用のファイルを作成

projectRoot ┣ assets ┣ componets ┣ layouts ┃ ┗ default.vue ←あとでVuetifyが適用できてたかの確認に使うファイル。nuxtがデフォで作ってる ┣ middleware ┣ pages ┣ plugins ┃ ┗ vuetify.js ←このファイルを新規作成 ┣ static ┣ store

新規作成したvuetify.jsの中身はこんなかんじ

   import Vue from 'vue'
   import Vuetify from 'vuetify'
   import 'vuetify/dist/vuetify.min.css'  // Vuetifyが利用するCSSを読み込む
   import 'material-design-icons-iconfont/dist/material-design-icons.css' // マテリアルデザインアイコンを読み込む

   Vue.use(Vuetify);

nuxt.config.jsに作成したpluginを追加

module.exports = {

  plugins: ['~plugins/vuetify.js'], //こいつを追記

}

Vutify.jsフレームワークが適用できたかの確認

以下のアプリの雛形のsourceをコピってきて同じのが出たらとりあえず作業完了

Baseline layout example — Vuetify.js

ペーストさきは

projectRoot/layouts/default.vue

これの中身を全部消してペースト。

プロジェクトの適当なページ（例えば、localhost:3000 とか) をブラウザでひらいて、雛形とおんなじの出てればOK。

きれいなよりも変化に強いソースコードが良い

@nabeemichi です。

ほとんどのエンジニアはソースコードを綺麗に書けと言う。 確かに汚いよりも綺麗な方がいい。 綺麗だと不具合も少ないし、整理整頓されていれば捜し物だって見つけやすい。 でも、エンジニアに「きれいなソースコードってなに？」って聞くと答えられない人が多い気がする。

可読性が悪いから綺麗ではない

と答えるエンジニアは多い。

そもそも可読性って何よ？

ってことになる。調べてみると

コンピュータ・プログラミングにおける可読性（readability）とは、プログラムのソースコードを人間が読んだときの、その目的や処理の流れの理解しやすさを指している。

引用：Wikipedia

人間が読んだときの理解しやすさとのことだが、

これって人によって理解のしやすさなんて変わるだろうに。 読んでるソースコードのバックグランドをよく知っている人もいればどうでない人もいる。 読んでいる人によって前提条件が違うのである。

さらに、処理の複雑さによっても理解のしやすさが違う。 足し算をプログラミングするのと、積分を実装するのでは複雑さが違う。

可読性は読む人と処理によって大きく変わってくる。

つまり、このソースコード可読性いいよね？

と聞いて、いいね！と答える人の確率はクソ低いのである。

実装が少ないからきれいなソースコードだね

と、言う人もいる。

確かに小さい字で書いてある小説の本よりも、俳句などの少ない文字で表している方が綺麗に見える。 なによりも少ない方が読む気が起きる。というよりは、読むのに飽きる前に終わってくれる。

少ない実装量になる可能性は、処理が簡単かフレームワークを最大限に利用しているかが考えられる。

前者の場合は簡単な処理なのできれいもくそもない。書くことがないから少ないのだ。

後者の場合、フレームワークをあまり知らない人にとっては、何をしているのか全く理解できない。 きれいだなんて思わないはずだ。だって疑問ばかりが浮かんでくるからきれいなんて考えない。

つまり、このソースコード可読性いいよね？

と聞いて、いいね！と答える人の確率はこれまた低い。

きれいなよりも変化に強いソースコード

ソースコードは機能追加や不具合修正などを繰り返す。これを繰り返してくうちに、汚くなる。 いろいろな人が手を加え、締切の都合により一時的な修正が永遠に残る。

こんなのはどのアプリでも出くわす。

どんなに万人にとって可読性が良いソースコードを書いても、締切や緊急性などの都合上いろんな人の手が入る。 実装量が少なかった部分も機能追加で実装量は増えていく。

こんな時でも、少ない修正量で影響範囲を最小限にできて、機能追加がしやすいソースコード。 きれいなソースコードを目指すよりも変化に強いソースコードを書くことが価値がある。

変化に強いソースコードは実装が多くて可読性が低い

のである。 変化に強いということは、取替可能が部品がたくさんあることになる。

どこか一箇所が壊れてもすぐ交換できて、 どこかを拡張しようとする場合もすぐにドッキングできる。

これを実現するには、意味のある単位で部品であるソースコードを完結させ、 ジョイントするためのソースコードを用意し、簡単に結合できるようにする。

それを実現するために、適切なインターフェースが必要になり、メソットの一つ一つのinとoutを規格化していく。 こんなことをすると、あっという間に実装量が増える。 細かいパーツが増えていくので可読性なんてよくわからない。わかるのはパーツが組み上がって出来上がったときだ。

アプリが出来上がって、アプリが進化し続けれるかが重要なんだ。 きれいなソースコードであることは重要ではないよ。

自分の実装を何度も書き直すことはプログラミング能力を伸ばすのに有効

@nabeemichi です。

プログラミングをしていると、自分で実装したソースコードを何度も実装し直します。 プログラミングをやったこともない新人時代は、先輩からダメ出しを喰らいまくって何度も実装しなおしました。

ちょっとした不具合修正するためにどんだけ時間がかかったことか…

そしてどんだけ自分のソースコードをDeleteで消しまくったことか。 でも、同じ機能に対してプログラミングを消しては書いて、書いては消して、と何度も書き直すことでプログラミングに対する考え方も変わってくるのです。

効率的なプログラミングについて考えるようになる

何度も書き直していると、書き直しのためにDeleteボタンを押すのも面倒になってきますから、どんだけ書かなくていいかを考え始めます。 プログラミングは無駄なロジックがない方が早く動きますし、メンテナンスも楽です。 つまり書かなければ書かないほど、不具合が発生する確立も減り、タイピングする労力も減るのでいいわけです。

一度実装が終わり、期待する結果を出せる機能に対して、何度も書き直しを行っているとこれを考え始めるようになります。 なぜなら、アルゴリズムや期待する結果を出すための実装方法をすでに確立しているため、他のことを考える余裕が生まれるのです。

最初の実装の場合はこうは行きません。

まずは実現できるのか？

本当に期待する結果を出すことができるのか？

というこを考えるのが優先事項になるため、効率とか言ってられません。まずは形にするのが最優先で考えるべきです。

なので時間や思考回路といったリソースを割り当てる対象が、期待値出せるかどうか？にピンどめされます。

ですが、何度も実装しているとリソースを割り当てる対象が変わってきて、効率的な実装に変わるのです。 更に先に進むと、もっとマニアックな場所にリソースを投入し始めるので、切り上げるタイミングは見計らう必要があります。

教科書に書いてあることだけやってても効率的なプログラミングができないことを思い知る。

何度も書き直しをしていると、自分の書いているソースコードを暗記し始めます。 したくてするのではありません。暗記してしまうほど、見たり消したり、同じこと書き直したりしていうる状態になってるのです。

技術書なんかに書いてあることを取り入れて効果的に実装してやる！

と思って、意識高い系プログラマになってしまったときに、一般的に出版されている技術書なんかを見ながら意識高い系実装をしてしまうと、 崩壊する部分が一瞬で頭をよぎり始めます。 なぜなら、暗記してしまっているので気づかないことなどできないのです。

このことにより、

技術書やWEBで見つけた意識高い系の方法は、自分の直面している問題と違うのではないのか？

と考え始めます。 問題や課題が違う場合は、自分がつくったものが崩壊し、効率的なプログラミングを考えていたのに全く効率的にならないということを経験することができます。

小さなことまで気がついて調べるようになる

ある程度余裕が出てきて、それなりに効率化され始めてくると、些細なことも気にし始めます。

例えば、メソッド名や普通の変数は小文字で書くのに、大文字で書く変数があって、なんでなんだろう？

とか、考え始めます。

ある程度余裕が出てくるからこそ、このような小さなことに対しても「なぜ」と考える癖が出てきます。

これをすると、他人が書いたソースコードを修正するときにも、「なぜ、この書き方なんだ？」と疑問を持つことができ、原因を調べるようになります。 これはリグレッションを防いでくれる最も有効的な考え方になるでしょう。

自分のクズさに気がつく

何度も書き直していると、前日までの自分のクズさに気づきます。

昨日の俺はどうやったらこんがクソな実装できるんだ？

と不思議に思うようになります。そして、成長を実感することができて、ディスプレイを見ながら嬉しくなり、ニヤけてしまいます。

「俺って、、、できるようになってるんじゃね？」

こう思ってしまうと、やばいです。たいてい、こうゆうときは誰かに見られてます。向かいの席に座ってる同僚がドン引きした顔をしていること間違いなしです。

プログラミングができるようになるためには効率いい。

どんどん新しい機能を作りまくるというのもいい方法かもしれませんが、

何度も同じ機能に対して書き直すことで、プログラミングスキルの上達は早くなります。 なぜなら、PDCAを回しやすいからです。 効率化するためにはどうするか？ 失敗した場合は、前回の実装との比較もしやすい。期待値はすでに固定されているし。

実際、これに似た現象は、大学受験勉強でも起きます。 たくさんの問題集をやるよりも、１冊の問題集を完璧にするほうが成績は伸びます。 同じ問題を説いても必ず溶けるとは限らないし、間違った問題を放置せずに、この間違った問題に対してPDCAを自分で回さないとできるようにならないのです。 間違ったという現象を放置せずに、なぜ間違ったのか？次回はどのように考えれば間違わないのか？を考えて、できるようになることでスキルは伸びます。

プログラミングのレベルアップしたいならサンプルコードを探すのだ。

@nabeemichi です。

フリーランスでエンジニアをしていると、いろいろな経歴を持った人のソースコードを見ます。 SIer出身のソースコードみたり、有名なベンチャー出身の人のソースコードを見たりします。 ソースコードは人間が記述するので、それなりに癖があるのは仕方ない。 どんな経験をしてきたとしても、プログラミングのレベルが高い人とそうでない人がいるわけ。 みんなそれなりにプロジェクトを経験してきてるのにレベルに差がでてくる。 この差がつく理由が何なのかを観察してみた。

サンプルを探す人、探さない人

一番の違いはこれだろう。 レベルアップしていく人はサンプルを探す。 社内のソースコードを探したり、GitHubを検索したりする。

自分が実装したいことに近いことなんて誰かがすでにやってるはずだ。 だからサンプルを探して、自分の実装したいことにフィットさせよう！と、考える。

サンプルを探すと、スタート地点が一気に上る。 何もないところから実装するよりも難易度は下がるうえに、サンプルから書き方も学べる。

僕もサンプルをよく探すが、こんな書き方できるんだー！！って勉強になることが多々あるし、 こうゆうことができるなら、こんなこともできるのでは？ と思って、サンプルを改造して実験したりする。

一方サンプルを探さない人は、書き方がゼロから自分で考えた方法でプログラミングしている。 少し調べればもっと楽な方法があるのにもかかわらず、自分の持ってる知識のみで戦っているため、 実装の量も多いし、読んでいて何がしたいのかわからない。 そして一番やばいのが、新しい知識や実装に対する考え方がアップデートされないから、プログラミングが成長しないのだ。

日々進化しているフレームワークや技術のなかで戦わないといけないので、プログラミングの知識と考え方は常にアップデートしよう。 というか、サンプル探さないでどこで勉強してんだろ？

サンプルを見ることでセンスを鍛えれる

センスといっても大した事ではない。 自分が実装したいことに対して、他のケースや他のアプリでもやらなきゃいけないことだから、簡単な方法あるはず！と考えて検索するクセがつくということ。 これが大事で、プログラミングの生産性を上げるポイントにもなる。

そして、いろいろなサンプルを見たりすることで、自分がやってることがおかしなことしてないか？って判断もできる。 サンプル見つからなかったら、変なことしてるから考え方変えたほうがいい。もしくはガチで世界初のことをしているかのどっちかだ。

トラブルシュートができないエンジニアは、変数いじりすぎて自爆してる

@nabeemichi です。

エンジニアとしてプログラミングしていると、トラブルシュートはつきものです。 開発中に期待値とは異なる結果になってしまった場合やエラーが起こってしまった場合にすることもありますし、 既存システムを保守していて、ユーザーからエラー報告があった場合に修正するときにもトラブシュートをする必要があります。 なので、世の中のすべてのエンジニアはトラブシュートは経験するし、永遠にお友達なわけです。 ですので、効率的に開発するにはトラブシュートの時間を短くするとエラーに時間をられなくなるわけですが、これを効率的にできないエンジニアが多いのです。

効率的なトラブシュートって何？

ということなのですが、それは、

最短でエラーの根本原因を見つける

という、元も子もない当たり前のことになります。 もう少し具体的に話すと、 同じ動作のトラブシュートをしないでエラーの原因を特定するのです。

トラブシュートは理論と現象の２軸攻め

で原因を絞り込んでいきます。 エラーの現象やログを見て、原因がありそうなソースコードにある程度の予想をします。 その予想をもとに、ソースコードを読み漁り、原因になりそうな部分のを特定し、ソースコードから読み取った条件を整えて再現させ、条件を変更してエラーの根本原因を探します。

重要なのはソースコードから読み取った条件

この条件を変更させて、エラーの発生条件を探すのですが、 この条件が１つのパラメータだけで構成されている場合は問題ありません。 １つしかないパラメータの条件を変更して、動作を確認という作業を繰り返していれば、そのうちエラー発生条件は見えてくるでしょう。

ですが、このパラメータが複数になった場合が問題です。 例えば、エラーの原因の可能性がありそうなパラメータが[A, B, C]と３つあったとします。 パラメータ[A, C]の２つがエラーの原因だと予想できる状況だとしたとき、

トラブシュートが効率的なエンジニアは、一度にパラメータは１つしか動かさない

のです。 上記の場合だと、パラメータ[A]だけを変更させて、動作を確認してエラーの発生条件を探します。 では、なぜ同時にパラメータ[A, C]を動かさないかというと

同時に２つ動かしたら、どっちが原因かわからない

じゃん！ 同時にパラメータ[A, C]を動かして、エラーが直ったとすると、パラメータ[A]が原因だったの？それともパラメータ[C]が原因だったの？ と動作を見ながら判断できないですよね？

原因がわからなければ修正方針も考えられないので、最終的には

パラメータ[A]だけを動かして、動作確認をする

っていうことをするんです。 最初から1つだけうごかしてら、動作確認の回数減らせますよ。原因の特定もできるし。

最も効率的なトラブシュートは変数を１つしか動かさない

という、最も非効率そうなことが実は効率的なんですよね。 これやらないと原因わかっても修正方法わからなかったりしますから。

エンジニアになりたい人多かったりして、ITエンジニアとかいうと華やかなイメージあるのかもしれませんが、 正直エンジニアなんて ちょー地味 な作業ばっかりですからね。 なんたってIT技術なんて、ルーチンワークを機械に任せるのが目的ですからね。 ルーチンワークを消すためにはルーチンワークをするしルーチンワークを理解しないといけないですから。

フレームワークのソースコードを読まないからプログラミングが上達しないのですよ。

@nabeemichi です。

WEBアプリだろうがスマホのアプリだろいうが今の時代、アプリケーション開発においてフレームワークやライブラリを利用しないことはない。 世界中の頭のいい人たちや、世界中の開発者の経験を詰め込んだ素晴らしいフレームワークやライブラリがオープンソースとして提供されてるからね。

これによって、アプリケーションを作成するために開発者がプログラミングをする部分はアプリケーション固有の動きの部分に集中することができ、 アプリケーション固有ではない他のアプリケーションでも行う部分はフレームワークにまかせて生産性を上げることができる。 なので、

フレームワークを理解し使いこなすことがエンジニアの仕事

の大部分になっているのです。 理解して利用しないと使えないし、生産性もあがらないので当たり前のことですが。。。

そんでもって、理解するために何をするかというと

フレームワーク作成元が発行している公式ドキュメント

を読んで理解するのです。 理解して利用できればいいのですが、ドキュメントだけでは理解しきれない場合もあるわけです。

ドキュメントは、英語や日本語で書かれていますので、一意に特定しきれない表現があったり、読んでいる側の勘違いだってあるのです。

で、理解できない場合はどうするのかというと、

フレームワークのソースコードを読む

のです。僕の場合はね。

ほとんどの開発者は読まないらしい。というか、読んでるやついないのでは？ 実際に僕が手伝いに行っている会社のエンジニアも６人くらいいて、みんな読んでない。

他のエンジニアから言われるのが、

フレームワークの中身読むなんて、よっぽどフレームワーク好きなんですね？

とか言われるが、それは誤解です。 フレームワークを正しく、理解して、動作も確認して使いたいだけ。 論理的にも動作的にも理解した状態で使わないとか、僕には恐ろしくてできないわけよ。

なぜかというと

想定外の動作が起こったときにすぐに原因の想定ができる

ってことが大きい。 フレームワークのソースコード読んで論理的に理解しているから、原因箇所の仮説が立てやすい。

アプリケーションの作り方の正しさを論理的に察知できる

フレームワークも利用場面や利用想定がなければ機能は作れません。 フレームワークのソースコードを読んでいると、なんとなく思想や利用想定が見えてくる。 そのため、動き的には正しいのだけれど、論理的に正しい実装になっているのかを理解できる。

論理的に間違った実装をすることが、なぜダメかというと

フレームワークが想定していない利用方法だから

これをすると、バージョンアップで動作が変わってしまって対応できない。 まぁそうですよね？フレームワークが想定してない利用方法なので、バージョンアップのときに論理的に間違った実装していたら、動作の保証なんてされません。

さらに、保証されてない利用方法なので、どこでどんな影響があるのか自分で調べてドキドキヒヤヒヤしないといけない。 そんでもって、実装増やしていったときに、

動作的にも論理的にも。。。もうツンだ！作り直さないとどうにもならんかも。。。

みたいな感じで顔が真っ青になってるエンジニアを何人見てきたことやら。 フレームワークのメリットである生産性向上がまったくもってできなかったパターン。

自分の実装サンプルが増える

でもって、これがエンジニアにとっての一番のメリットだと思うわけ。

フレームワークなんてものは、自分よりも頭のいい世界中の優秀な人が作ってるはずなわけ。 だから、中身を見て、

こんな機能があるのか〜！

とか

こんな考え方で作ると効率的なのか〜！

とか

ええええ！こんな場面も想定されてるのか〜！！

とか、発見があるわけですよ。 この発見が重要なわけで、アプリケーション開発でもっと効率化した実装できないかな〜？と自分が思ったときに、 あ、フレームワークのあそこらへんの考え方が使えるかもしれない！！！！ って思いつけるわけ。

こうやって自分のプログラミング方法や考え方のサンプルを知って、利用してみないと、プログラミングって上達しないと思うのです。 せっかく頭のいい人たちと、世界中の知見が詰まってるフレームワークを利用して、自分のプログラミングも効率的にスキルアップするのです。

プログラミングできるようになりたいなら他人の責任にするエンジニアになればいい。

@nabeemichi です。

プログラミングができるようになると、どんどんゴーディングして実装を増やしたがるエンジニアは多い。 実装すればするだけ、自分が作っているという満足感もあるしできるようになっている気がするのです。

でもね、本当にできるエンジニアは実装しないのですよ。 今ではオープンソースとして優秀な人が作ったものが公開されてる時代でもあるわけですし、効率化のためにフレームワークもどんどん進化している時代です。 他人が実装したものを、作った糸の通りに使いまくり、自分の実装を極力少なくするのです。

どうしてこのようなことをするのかというと

他人の実装を利用し、自分の責任をなくす

という他力本願を最大化するのが目的です。 目的が一致していて、誰かが作ってくれているものがあるならそれを利用するのです。 そうすることによって、自分が保証しないと行けないロジックの範囲が一気に少なくなるわけ。

エンジニアはプログラミングしたら、そのロジックを保証しないといけません。テストして、不具合があったら修正して。。。。 この部分を他人が作ったものを利用するだけで、どんどん省ける。どんどん自分の責任の範囲が少なくなる。

こうすることで、

不具合が少なくなる

フレームワークなどの場合は、他の人（たいていは世界にいる自分より優秀な方々）が実装して、テストしてくれている。 社内のソースコードの場合でもすでに誰かがテストしていたりするわけです。

つまり、ある程度動作が担保されているわけですから、不具合が存在している確率は、自分でプログラミングするよりもずーっと低いのです。

他人の実装を当てにすることで、さらにいいことは

生産性をあげることができる

すでに誰かがテストしてくれていて、利用実績まであれば、開発における「実装、テスト、不具合修正」というステップがごっそり削れるため、 アプリ固有の開発に専念できるのです。しかも、テストして評価する部分もアプリ固有の部分を集中的にできるわけです。

これを自分でプログラミングしてしまっては、動作確認からテスト、不具合修正まで自分でやらないといけなくなる。 リリースまでに行わないといけない作業量が増えてしまうわけです。

まとめ

データの反映などのアプリでもするような動作はとことんフレームワークなど他人の実装にまかせて、アプリ固有のロジックだけの実装に集中する。

目的が一致しているなら他人の作ったロジックを、作った目的のとおりに使いまくり、自分の書いたロジックを極力少なくし、バグっていても自分のロジックではないことを確認して、作ったやつのせいにすればいい。

こうゆう実装してるだけで、他のエンジニアより不具合少なくできるし生産性も上がる。