nanisore oishisou

プログラマ、ララ・ベル子さん改めArm4さんのゆるふわ奮闘記。

Laravelでgroup byしたら、"~ isn't in GROUP BY (~)"って怒られました

group byしたら、うちのMariaさんが
「selectで設定した全カラムをgroup byに入れなさいよ!言わせんな恥ずかしい!!」
という、ヒステリックなことを言ってきた。
あ、これ、どれ選べばいいのか分からないから勝手にマージして表示してやんぜ、というmysqlの優しさが失われているやつや。。
そんな設定した覚えないのに、なんで。。。

おいらの環境

config/database.php

strict = true

この環境で、ONLY_FULL_GROUP_BYがsqlのmodeとして追加されてしまうみたい。

これはLaravel側で設定してしまうようで、私のMariaDBではmodeとして追加はされてはいなかった。

f:id:arm4:20190111181301p:plain
ONLY_FULL_GROUP_BYは設定されてないYODA

以下にissueが上がっていた。

github.com

原因はstrict = trueのようだ。

strict = falseにすれば、確かにヒステリックなことは言わなくなりMariaさんは優しさを取り戻してくれる。

しかし、マージされてしまっていて特に使わないカラムを取得する意味もないし、
ヒステリックなMariaさんも、私は何気に嫌いでもない。

true時に適用されてしまう項目は以下のようなので、

  • ONLY_FULL_GROUP_BY
  • STRICT_TRANS_TABLES
  • NO_ZERO_IN_DATE
  • NO_ZERO_DATE
  • ERROR_FOR_DIVISION_BY_ZERO
  • NO_AUTO_CREATE_USER
  • NO_ENGINE_SUBSTITUTION

現状の差分的には以下が追加で設定されてしまうということだ。

  • ONLY_FULL_GROUP_BY
  • NO_ZERO_IN_DATE
  • NO_ZERO_DATE

うーん。

正直falseでもいいような気がするが、アプリ側でそんなん絶許!!してくれるというのは、考えようによってはいいのかもしれない。

一部のみを適用したい場合はissueにあるとおり、config/database.phpmysqlの設定にmodesを追加して、適用したいmodeのみを記載すればいい。

ONLY_FULL_GROUP_BYだけをオフりたい場合は、↓以下。
分かりやすくコメントアウトにしてあげました。(優しさ)

config/database.php

            'strict' => true,
            'modes'  => [
                // 'ONLY_FULL_GROUP_BY',
                'STRICT_TRANS_TABLES',
                'NO_ZERO_IN_DATE',
                'NO_ZERO_DATE',
                'ERROR_FOR_DIVISION_BY_ZERO',
                'NO_ENGINE_SUBSTITUTION',
            ],

ちなみにONLY_FULL_GROUP_BYをオフらなくても怒られなくするには、
以下の記事を参考にそれぞれのカラムでどの値を持ってくるか指定してやればいいようだ。

mashup.hatenablog.com

え、超めんどくさい。。。。
おとなしくオフしたい。

末永いお付き合いをするには、優しさも大事なときが来るかもしれないが
ひとまずヒステリックになったのは、きっと何か嫌な出来事があったからだと思うので
大人しく過敏になったLaravelさんとお付き合いを続けることにした。

まあでも、今回はテストで*で書いて気づいたけど、
ちゃんと書き込むときはマージされるカラムなんかselectしない気もする。

教えてくれて親切だけど、
怒られるとビックリして、それの原因突き止めるのに時間かかったりして
なんかちょっとしたトラップ設定のような気もするし
こんなんオフればいいやんって気もする。

ただ何度も言うが、
これをデフォルト設定にしたのには何か嫌な出来事があったからかもしれないので
このストイックさを優しく受け止めてあげる男っぷりを私たちは試されているのかもしれない。
そんなわけないか。

新年一発目のブログでしたーーー!!!!

技術力を向上するモチベーション、そしてエンジニアの価値と幸せについて

先日、PG会でエンジニアのメンタルコントロールについて、後輩たちに伝えたいこととしてKさんが率直に話してくれました。 その勇気に、私はとても感嘆しました。

そして、こうも思いました。 私は、今までエンジニアのメンタルコントロールについて、率直に自分の言葉で周りに伝えたことがあまりないな、と。

これまで私がエンジニアになってから、自分の技術力、周りの技術力、チームの技術力、会社の技術力を向上させることを、いつも考え、いろいろと働きかけてきました。 技術力とエンジニアは切っても切り離せないものだからです。

しかしながら、エンジニアにとって技術力の向上を続けることは、容易なことではありません。

何のために、この勉強をしているのか。
何のために、こんなに必死になっているのか。
自分は、そもそもこんなことを勉強することを周りに求められているのか。
技術力を向上して、自分は何がしたいのか。
劣っていなければ、それでいいのではないか。
周りに、この新しくて素晴らしい技術を語り合える人が誰もいない。
こんなに勉強をしたのに、私はまだこんなにも未熟で、理解できていないことが多すぎる。
世界は広く、技術は果てしなく、到達すべきゴールが見えない。
勉強をすればするほど、孤独になっていく。
そんなふうに感じていたことがあります。

「あの人は、技術が好きで趣味のようなものだから。真似をする必要はないんだよ。変わった人だからね」

そう言われるたびに、伝えたかったことが私にはあります。

もがき苦しみながらも、エンジニアとして技術力を向上し続けてきた私の、技術力を向上するモチベーションについて。
私が思うエンジニアの価値と幸せについて。

そのことについて、今回は話したいと思います。

技術力を向上するモチベーション、そしてエンジニアの価値と幸せについて

私には、技術力が高ければ市場価値が上がり、思い描いた職場で働け、理想のカッコいいシステムが作れ、収入もどんどん上がり、幸せで充実したエンジニアライフが過ごせる、そう思っていた時代がある。
しかし今は、そうではないと思っている。

エンジニアとして市場価値を高めたいということに、技術力向上のモチベーションを持つことは、もちろん悪いことじゃない。
しかし、技術力だけがエンジニアの価値を決めるものではない。
むしろ、技術力ではないものが、エンジニアの価値を決めると言っても過言ではない。

銃撃の腕は抜群だが、作戦どおりにまったく動かない兵士は、兵士として価値は高いだろうか。

また、逆に作戦どおりに動くが撃っても一発も当たらない腕前の兵士は、兵士として価値は高いだろうか。

また、作戦どおりに動き、銃撃の腕前もいいが、作戦の抱える問題点を上官に進言できずに、ミッションを成功させられない兵士は、兵士として価値は高いだろうか。

また、作戦どおりに動き、銃撃の腕前もよく、作戦の抱える問題点も指摘できるが、決められた時間までにミッションを遂行できない兵士は、兵士として価値は高いだろうか。

作戦どおりに動き、腕前もよく、作戦の問題点も指摘でき、タイムリミットも守るが、チームのメンバーと協力できない兵士は、兵士として価値は高いだろうか。

価値の高い兵士とは、ミッションを正しく理解し、その作戦に問題がないか判断ができ、上官と意思疎通をきちんと取り、チームと協力して、その作戦を高度な腕前で指定のタイムリミットまでに遂行することができる、そういう人間だ。

そのどれか一つでも欠けている兵士は、その他がいかに優れていても、価値が高い兵士にはなれない。

技術力が高いというのは、兵士の銃撃の腕前と同じように、エンジニアに求められる最低限の価値だ。

だから、技術力向上をすれば価値を高められるというのはある意味で正解であり、ある意味で正解ではない。

技術力向上とは、いかなる作戦にも対応できる最低限の能力を高めていることに過ぎない。
それ以上に価値を高めるのには、技術力だけでは不十分であり、その他の要素を高めるということが技術力を手に入れたエンジニアが次にしなければいけないことだ。
その他の要素を高めなければ、苦しんで手にした技術力も、何の価値もないものになってしまう。

また、技術力を向上させないエンジニアは、ミッションを成功に導くための最低限の価値をチームに与えることができない、銃撃の腕前を磨かない兵士と同じで、そもそも兵士であるべき人ではない。

しかし、市場価値を高めることをモチベーションとして技術力の向上を続けられるのか、と聞かれると、私はそうじゃないと思っている。

なぜエンジニアとして価値を高めたいのか。
収入を上げたいから。
人よりできると思われたいから。
好きな職場で働きたいから。
自分の信じる美しいものを作りたいから。

エンジニアとして、そのモチベーションで、毎日勉強を続けながら幸せに過ごすことはできるだろうか。

おそらくそのモチベーションでは、毎日幸せに過ごすことはできないだろうと思っている。

エンジニアとして収入が上がり、人よりできる人だと思われ、好きな職場で働き、理想の美しいコードを書けたとしても、またそこでも、エンジニアとして技術力を向上するように求められるだろう。
この課題を解決するためには、より高度な技術力が必要だ。時代は変わっていくのだから。
そう言われるだろう。
それはエンジニアとしての宿命だ。

なぜ技術力向上を求められるのか、それは、エンジニアは技術力を持ってミッションを成功させなければならないという職務を担っているからだ。
私たちエンジニアは、芸術家ではない。
企業に勤める企業人であり、チームに所属するチームの一員だ。

私たちのミッションとは何か。
チームが持つ課題を解決すること、ユーザーが持つ課題を解決すること、世の中に新しい価値を生み出すこと。
私たちエンジニアに課せられるミッションとは常にそういうものである。
その課題は、常に時代と共に高度な要求になっていく。その前にあった課題がクリアされたら、次のより高次元な課題をクリアしなければならなくなるからだ。

だから、私たちエンジニアは常にその高度になっていく課題を解決するために、高度な技術力を求められ続ける。

何のために技術力を高めるのか。
市場価値を高め、需要のある価値の高いエンジニアになるためか。
エンジニアとして日々成長を求められ続けていく中で、こういったものをモチベーションにしているなら、きっと幸せを感じることはできないだろう。

上にはいつも上がいて、いつも自分のいるところより上を見上げながら、自分は本当ならばあちらにいるはずの人間だ、自分はあのように崇高なものを作る人間のはずだ、そう思いながら生きていくことしかできないだろう。

そして必死になって見上げていたその場所に辿り着いても、その先にも上があり、技術の世界は果てしなく、新しい世界に足を踏み入れるたびに、自分はいつでも何も知らない未熟者であったと気づかされるのだ。

やってみたこともないものを、何日で作れるのか問いただされ、期日を決められ、初めての試みに対しても責任を負うことを求められる。
ビジネス要求の理解、周りへの配慮、エラーやバグを量産しない思慮深さ、コーディング能力の高さ、スピード、技術に対する深い知識、市場価値が高まれば、それらの要求度も当然のように高くなる。
常に、どこへ行っても、今の自分よりも、より高度な技術を身につけるよう、技術力の向上を求められ続ける。

それを全身で受け止め、それを楽しみ、幸せを感じるためには、何のために技術力を高めているのか、自分が目指すものは何なのか、その明確な目的を、理由を、志しを、いつも心に掲げていなければならない。

かつての私は、実装がうまくいかないたびに、技術の習得がうまくいかないたびに、バグやエラー、障害があるたびに、期日に追われるたびに、チームメンバーとうまくいかないたびに、エンジニアとしての熱意を否定されるたびに、メンタルコントロールが難しくなり、職場に行くことが苦しくなるということがあった。
技術力が足りない私は、才能が足りない私は、人としての配慮が足りない私は、空気の読めない私は、相手が分かる言葉で説明できない私は、こんなに弱い私は、エンジニアには向いていないと、何度となく思うことがあった。

必死になればなるほど、自分という蜘蛛の巣に絡まっていくような気がした。

周りには誰もいない。信じられるのは自分の技術力だけだ。誰も助けてなどくれない。
私ができないと言えば、そこで私の価値も、私という存在の意味も、無くなる。
必死に、目の前の技術に向き合わなくては。

そういう不安定なメンタルをなんとかごまかしながら懸命に働いた。
自分の不安定な内面とは裏腹に、私はいつも順調に仕事を終わらせることができた。
やはり、信じられるのは自分の技術力だけだ。
そう思った。

しかし、仕事がいくら評価されても、技術力を認められても、私の心は、幸せというにはほど遠かった。
いつも迷子の子供のように、不安がつきまとって頭から離れなかった。

何故、私はエンジニアになろうと思ったのか。
私は何か、もっと大切なものを、目指したのではないか。
そんなふうに考えるようになった。

助けてくれる人は本当に誰もいないのだろうか。
本当に私は一人なのだろうか。
私のことを心配し、気にかけてくれる人はいなかっただろうか。
私のプロダクトの完成を、一緒に祝ってくれる人はいなかっただろうか。
本当に私が信じられるのは、自分の技術力だけだったのだろうか。
私は、本当に自分のためだけに、こんなに必死になったのだろうか。

いや、たぶん違う。
絶対にそうじゃない。
私が技術力を高めようと思った理由は、エンジニアとしての価値を高める、技術力を高める、そんなつまらない理由じゃなかったはずだ。
誰にも否定することはできない、私の信念と情熱があったはずだ。
その信念と情熱を思い出してから、私の前にあった霧は、消えてなくなった。

何のために技術力を高めるのか。
私はこう思う。
それは自分の作るものと、自分の周りの人の価値を高めるためだ。
自分や、周りの人が抱えているたくさんの課題を鮮やかに解決していくためだ。
そして次々に生まれるより高度な課題を、解決し続けていくためだ。
自分の作るものと、自分の周りの人と、何よりも自分を愛するためだ。

私のプロダクトを私が愛し、その価値を高めるためだ。
私のチームの価値を高めるためだ。
私のプロジェクトマネージャーの価値を高めるためだ。
私のプロダクトを受注してきた営業の価値を高めるためだ。
私たちのプロダクトの価値を高めるためだ。
私の会社の価値を高めるためだ。
私たちの会社を選んでくれたクライアントの価値を高めるためだ。

そして、周りの価値を高められるそういう人間だからこそ、そういうエンジニアだからこそ、人はその人に価値を見出し、信頼し、尊敬し、称賛し、対価を支払ってくれる。

あなたの技術はすごい。
あなたがいなければこの課題は解決できなかった。
任せてよかった。
一緒に働けてよかった。
そう言ってもらえる。

たとえ、そう言ってもらえなかったとしても、そうである事実は誰の目にも明らかであり、
その事実は、自分に確かな自信をもたらしてくれる。
そしてきっと、理解し、応援してくれる人が増えていくはずだ。
愛するプロダクトと、信頼できる仲間ができる。

それこそが、エンジニアとして幸せを感じながら成長し続けていくモチベーションになりえる唯一のものであると、今の私は、そう思っている。

誰かと比べるものじゃない。
誰かと張り合うものじゃない。
幻想のような理想にすがるものじゃない。
私は、チームのミッションを鮮やかに成功させ、周りの価値を高め、自分の作るものを愛し、自分の仕事を愛する、そのために必要とされる最低限の能力である、技術力を高める。

私は、けして一人ではない。
これまでもずっとそうだったように、これから先もそうであるように。

その過程で、きっと鮮やかに解決できずに、もがき苦しむこともあるだろう。
思い通りにいかないこともあるだろう。
新しい技術を理解できずに苦しむこともあるだろう。
思想の違いでチームメンバーと口論になることもあるだろう。
自分の妥協を軽蔑したくなるときだってあるだろう。
自分の才能に、絶望することだってあるだろう。
だけど、少なくとも私は、打算やエゴ、自分のことだけを考えて苦しんだわけじゃない。
誰かを幸せにするために、もがき苦しんだ。
そのことは、きっと誰も否定できるものじゃない。

私は、そうやって幸せを感じながら、エンジニアとして成長し続けていきたいと思う。

この仕事を選んだ私を、受け入れてくれた人たちのためにも、そうであるべきだと思っている。

Atomic DesignをVueコンポーネント設計に適用するために見るやつ

Vue Fes JapanのスライドでAtomic Designについて書いてあるスライドがあり、
コンポーネント設計であったもやもやが解決しそう!と思ってほんのり調べてみた。

コンポーネント設計にAtomic Designを採用したというスライド note.mu

▼Vue.js からみた AtomicDesign medium.com

▼Atomic Designを考案した人のブログ

bradfrost.com

そして、みんなで認識合わせる時には、発音しないといけないので
読み方と意味を調べてみた。
これが正しいかどうかは分からないので参考程度にお願いします。

Atom

  • 読み方:アトム
  • 意味:原子

【Molecule】

  • 読み方:モリキュール
  • 意味:分子

【Organism】

【Template】

  • 読み方:テンプレート
  • 意味:雛形

考案した人のブログにあるPageという概念は
デザイナーから見た個別のページと
デザインされるべきテンプレートを呼び分けるということなので
Vueのコンポーネント設計では存在しない、はず。

なるほどー!めっちゃ設計概念として分かりみある!!

Vue.jsの人気UIフレームワークまとめ2018秋

お久しぶりです。ベル子です。

Vue.jsのUIフレームワークについてのまとめ記事(英語)を見つけてツイートしたところ、
それなりにいいねがついたので
「みんな、UIフレームワークをめっちゃ探してるな」と感じとり
人気のあるフレームワークを日本語でまとめてみることにしました。

人気のあるフレームワークは以下のブログ記事などを参考にしています。

11 Vue UI Component Libraries You Should Know In 2018

海外のVue.js用UIフレームワーク紹介記事を読み漁り、どの記事にもだいたい出てきているフレームワーク
女の勘でチョイスしました。

人気がありそうなVue.jsのUIフレームワーク

Vuetify

vuetifyjs.com

Quasar

quasar-framework.org

Element

Element

Vue Material

vuematerial.io

BootstrapVue

bootstrap-vue.js.org

Buefy

buefy.github.io

どのフレームワークがどのくらい人気なの?

Star Historyを皆さんご存知ですか。
ちなみに私は知りませんでした。
githubのスター獲得の歴史をグラフで確認できるサービスです。

丁寧な解説記事はこちら。

Star history - GitHubのスター獲得履歴をグラフ化して比較できるWebサービス | ソフトアンテナブログ

そのStar Historyを使いまして、
女の勘で選んだベストフレームワークのスター獲得曲線を確認してみます。

Star history

見ておわかりのとおり、Elementは先発のVueのUIフレームワークで、スター数も飛び抜けて多いです。

どのフレームワークも右肩上がりでスターが増えていますね。
一度つけたstarをunstarすることってなかなかないと思うので、右肩上がりじゃないと逆に気になって夜も眠れませぬが、
見てお分かりのようにVueのフレームワーク自体の人気が急激に出てきているのがお分かりいただけると思います。

実は先発のフレームワークであるvue-materialも人気があったのですが、
こちらの曲線を見てお分かりのように後発のマテリアルデザインフレームワークである
Vuetifyが人気をかっさらっていってしまったようです。

Vue.js自体の人気について

ちなみにここで、世界三大jsフレームワークである、Vue.js、React、AngularのStar Historyも確認してみましょう。

Star history

ご覧になってお分かりのように、ついにVue.jsがReactを抜きました。(めでたいぜ!)

私がVueを初めた数年前はフロント界隈のイベントにおいてVue勢はややマニアック勢だったのですが、
もはや巷ではReactおじさんからVueおじさんへ変身しているおじさん勢も出てきています。

twitter.com

ごらん。女の勘を。
もはや、メインストリーム!!!!

Elementについて

ちなみに私はフレームワークは一通り候補を調べて人気があるものを、
使ってみて判断する派です。

それで2018年6月にVueのUIフレームワークを選定するにあたり、
当時最も人気と思われたElementとVuetifyを使ってみました。

2018年6月時点で、Elementはレスポンシブレイアウトに対応していない状態で
コンポーネントの詰め合わせという様相が強く統合的なフレームワークという感じではありませんでした。
そのため、レイアウトされたページの見本がなく、綺麗にレイアウトするのがかなり大変でした。

ということで、当時は結果的に楽で綺麗にレスポンシブ対応のレイアウトができるVuetifyを選択しました。

現在のElementのドキュメントを見る限りでは、
レスポンシブ対応されていて統合的なフレームワークとして使えそうに見えます。
アプリケーションに必要そうなコンポーネントもほぼ揃っているので
マテリアルデザインに抵抗がある人は使ってみてもよさそうだと思います。

github.com

リリースノートを見てみても活発に更新されてメンテナンスされているのが分かります。
一点、注意としては中国の方が開発されているので、突然中国語がドキュメントなどに登場したりします。

Vuetifyについて

Vuetifyは現在、本稼働案件で使用していますが、
目立った致命的なバグやレイアウト崩れなどはほとんどないように思います。
リリースノートを見てお分かりのとおり尋常じゃなく活発にリリースが行われています。

github.com

先日も新しいコンポーネントがリリースされました。
現在まで定期的にアップデートしていますが、
radioコンポーネントのイベントがinputからchangeになってしまったということ以外では
書き換えが発生するようなことはありませんでした。

一点注意点としてはVuetifyが採用しているcssプリプロセッサがstylusなのでstylusのloaderなどを入れたり
ファイルの分割などで少し工夫が必要かもしれません。

Vue.jsのUIフレームワークのデザイン分類

UIといえばデザインも非常に大事です。
デザインがアレなツールを使いたい人はあまりいないので、 できれば綺麗で好みのデザインに近いフレームワークを使いたいところです。
ということでデザインに着目して分類してみました。

マテリアルデザイン

  • Vuetify
  • Quasar
  • Vue Material

Bootstrap系

  • BootstrapVue
  • Buefy

独自デザイン系

  • Element

マテリアルデザインはレスポンシブ時の操作感まで考え抜かれていると感じることが多いです。
特に大きな時計が出てくるTimePickerは当初は正直「え、なにこれ。。」と思ったのですが
使い慣れてくるとスマホからでもPCからでも驚くほど素早く気持ちよく時間の入力ができます。

ただ、見慣れていないクライアントに「え、なにこれ。。」と言われてしまうかもしれないので
お好みで使っていただければと思います。

全体的にマテリアルデザインは洗練されている印象で、Bootstrap系は少しカジュアルな印象を与えます。
Elementについては、色が全体的に薄いのでオシャレ感はかなりありますが、
オシャレじゃなくていいからハッキリ見えるほうがいいというクライアント向けではなさそうです。

マテリアルデザインはよくアニメーションがついてくるので、それが煩わしいと感じる人もいるかもしれません。

フレームワーク選定について

ここで紹介したフレームワークコンポーネントがかなり充実しているものばかりなので
どれを採用しても良さそうな印象を受けます。

あとは、Vue.jsの場合はコンポーネントがいかにカスタマイズして使えるかということが重要になってくるので
その辺の使い勝手は多少、自分で使ってみて検討してみるのがいいです。

フレームワーク選定の時は、まずは人気があるものをリストアップし当たりをつけて、
ドキュメントなどを読み込んで絞り込み、
あとは実際に動かしてみて決めるというプロセスがいいように思います。

ドキュメントの出来がいいというのはフレームワークを選ぶ上でかなり大事です。
以下のポイントを重視するといいかなと思います。

  • 説明が分かりやすい。
  • 見本が豊富にある。
  • 概念の説明とAPIの仕様がきちんと分けて書いてある。
  • 目的の情報まで素早く到達できる。
  • 更新がマメに行われている。

今後も良さげなフレームワークが出てきたら紹介したいと思います★

Laravel 5.5で超絶便利なヘルパーoptionalってのできてるよ

この前、同僚にベル子たんに教えてもらったやつめっちゃ便利そうなのに何というヘルパーか忘れてしまいました!

と言われて、私も忘れてしまっていたという事件がありました。

現在、私がコアで開発してる案件は、5.7にアップデートしたので使えるのですが、
あまりにも"Trying to get property of non-object"を見すぎてしまったせいで
息を吸うように以下のように書いてしまいます。

<?php

$user_name = User::find(1) ? User::find(1)->name : '';

それか、php7で搭載されたnull合体演算子を使うともっと綺麗に書けます。

<?php

$user_name = User::find(1)->name ?? '';

何度も同じこと書かなくてよくなった!

PHP: 新機能 - Manual

これだけでも非常にありがたいのですが、
Laravel 5.5 で追加されたoptionalヘルパーを使うと息を吸うように
nullの時のエラーを回避できるようになります。

<?php

$user_name = optional(User::find(1))->name;

optionalを使うと、userが見つからなかった場合はnullを返して来ます。
厳密に空文字にしたい、などの時はnull合体演算子がいいかもしれません。

さらに Laravel 5.6.13 ではクロージャも第2引数で渡せるようになったらしいので
さらに使い勝手がよくなったっぽいいです。
すごい!さすが私のLaravel。

laravel-news.com

Laravelの公式ドキュメントはこちらです。

laravel.com

便利なものはどんどん使っていきたいところです。

git研修用スライド&Web API勉強会スライド

新卒が入って来た時に行ったgit研修用のスライドをSpeaker Deckで全世界に公開したので
Gitをこれから教えようと思ってるor初心からやり直したいという人がいたら参考にしてみてください。

あと8月のPG会で
初心者向けにWeb APIを超分かりやすく初歩の初歩から説明した際のスライドもアップしました。

話すことをすぐ忘れてしまうタイプなので
話すことをスライドに全部書いているため、スライドというか、もはや本w

あと時間管理ができなくて話しすぎるとよく言われてしまうので
これ以上は話さないぞという戒めでもあるw

git研修用は自分でも時々見返してしまうくらい頭がすっきりします。

ぜひ、ご一読ください!

VuetifyのDate Pickerを日本語化したら"日"ってついてくる、やだキモい

長い前置き(飛ばし読み推奨)

最近、フロント側を完全に脱jQueryして、Vue.js + Vuex + VueRouter + Vuetifyで開発を進めている。

これまでもVue.js + Vuex この2つは使っていたわけなんだけど
bootstrapベースであるAdminLTEと組み合わせることに限界を感じていて、
それぞれの開発者がVueライブラリを探して入れてみたり、
自作してみたりみたいなことを、それぞれの案件で繰り返していたわけだ。

心の声(もう、こんなお飾りのjQuery依存のUIフレームワークなんて実際は足枷じゃねーか。確かにデザインは綺麗なんだけど。。)

そこで出会ったのがVuetify。

少し使い込んでみた感じ、グリッドレイアウトにflexboxを採用しているので
レイアウトに苦戦することもあるけど、それだって新しいbootstrap4も同じだし
もはや、これが時代の流れなのかもしれないと思い、思い切って使ってみることにした。

エンジニアは、手を動かさなくなったら
時代に置いていかれて、すぐに周りについていけなくなる。
これは私がしばらくエンジニア業から離れたときに、痛いほど感じたことだ。
久しぶりに会ったエンジニアの知人の言っていることが分からなかった。

別に毎日懸命に手を動かして勉強する必要はない。
ただ、ニュースを毎日見るように、
ご飯を毎日食べるように、
時代の流れだけは把握しておかないといけない。
エンジニアとは、そういう生き物だ。そう感じた。

話が脱線しすぎた。元に戻そう。

Vuetifyを採用してみて最初は、
使い慣れないこととドキュメントの多さにグロッキーになっていたが
いくつか実装してみると、だいぶ手に馴染んできた。
アニメーションが綺麗でデザインも綺麗。
動きもサクサク。

モックを作成しPMに見せたら、いたく感動してくれた。

よかった。間違ってない。何となくそう思えた。
いいデザインは、人の心を魅了する。
いいデザインは、高品質を演出する。
いいデザインは、そのプロダクトを作った人間の情熱を伝えることができる。

要するに、
Vuetifyっていいね!

本題

Vuetifyのコンポーネントは、かなりいろいろ気が利いている。
色を変えるのも、デザインをカスタマイズするのも設定一つでできてしまう。

しかし、日本語化したDate Pickerだけは(あとTime Pickerもなんだけど。。)
ちょっとキモい部分がある。

f:id:arm4:20180817154130p:plain
日本語化したDate Picker

え?何この"日"ってやつ。
しつこいwwwwwwwww

消したかったけどoptionにday-formatはあるけどdate-formatがない。

いろいろ検索してみたらこんなcodepenを発見。

codepen.io

あれ?day-formatで指定すればいいっぽい?

ためしにday-formatに以下を設定してみたところ、
しつこい"日"は消えてくれました。

    <v-date-picker
      v-model="picker"
      :landscape="landscape"
      :reactive="reactive"
      locale="jp-ja"
      :day-format="date => new Date(date).getDate()"
    ></v-date-picker>

f:id:arm4:20180817154555p:plain
日よ、消え去れ!

めでたし、めでたし。