ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。 なので作ってみた。 まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。 SSGだとクライアントから直接検索のAPIを叩くわけにはいかないので、そこらへんは文献を読んで、クライアントからは APIを直接叩かない方法で実装した。このあたりの実装方法も面白いので今度紹介できたらと思う。 あとは個人的にはnext/routerの使い方とか勉強になったりしたのでとても良い体験になった。 余談だがNext.jsやNuxt.jsでプロダクトを実装するとフロントエンドのフルスタック化が凄まじいと感じる。 多分将来的にフロントエンドエンジニアという肩書きはなくなりそう。 アプリエンジニアとか、もっと領域が広くなるとフルスタックエンジニアになるかも。

ブログ記事を自分の学習のために見直す時があるのだが、記事数が10件超えると検索が欲しくなる。
なので作ってみた。まだ未対応な機能としてページネーションとOR検索があるけど、まぁそれはそのうち必要になったら実装すれば良いやぐらいな感覚で。。

ブログ記事に全文検索を追加した

<h2 id="hfa138adc31">Cypressで退屈な作業からの部分的解放</h2>Cypressをご存知であろうか。 もしあなたが画面をチェックする複合テストでエクセルにテストチェックシートを作成し、画面の表示チェックをするという 退屈なことを毎日しているならその退屈さを軽減できるかもしれない。 <h2 id="ha32723984a">Cypressとは</h2>複合テスト(e2eテスト)を自動化してくれるテストツールである。 画面で例えば特定の要素が表示されているかとかはテストコード一行書くと自動実行してくれる。 これを少し応用すると例えばフォームにテスト用のユーザー情報を添付して、ログインができるかを自動実行してくれる。 テスト実行するとこんな風に自動処理してくれる <img src="https://images.microcms-assets.io/assets/f9ba4609593647fdb1caa834aab8b0d4/4f7f5cf54d6443e2b804b2585f1d2ca2/output.gif" alt=""> これをどのレベルまで実行していくかは別問題だが、単純な要素テストはこれで十分な気がする。 個人的にはログイン機能など仕様として不変の色合いが強い機能に対しては極めて有効であると考える。(認証の仕様が日々動的に変化するなど仕様上あり得ないからである) <h2 id="hf031c5e696">実装方法</h2>フロントエンド環境でTypeScriptを導入しているのであれば、TypeScript側が提案している下記のやり方に従うのがベストそうである。 <a href="https://basarat.gitbook.io/typescript/intro-1/cypress" target="_blank" rel="noopener noreferrer">公式ドキュメント</a> ポイントとしてはe2eテストコード環境は 実装コード環境とは独立させること だと思っている。なので別途e2eフォルダなんかを作成して、モジュール依存関係を切り離す状態にすると変更に強いe2eテスト構造になりそう。

Cypressをご存知であろうか。
もしあなたが画面テストでエクセルにテストチェックシートを作成し、画面を表示チェックをするという
退屈なことを毎日しているならその退屈さを軽減できるかもしれない。


Cypressでお手軽画面テスト

早くリリースしたいから雑なコードでもとっととやろうぜ、は自らの首を締める。 最近読んで本当にしっくりくる資料であった。質とスピードの関係性は最も判断を誤る材料である。 最初から質に投資することで、将来のダメージを最小限に食い止めることができる。 <a href="https://speakerdeck.com/twada/quality-and-speed-2020-autumn-edition?slide=54" target="_blank" rel="noopener noreferrer">詳細はこちらより</a>

早くリリースしたいから雑なコードでもとっととやろうぜ、は自らの首を締める。
最近読んで本当にしっくりくる資料であった。

質とスピードという資料を読んで

<h2 id="h833f40a2cb">Lighthouseでwebページの品質を測定</h2> webページの品質測定には様々な見方があるし、測定ツールも様々である。 今回はそんな中でLighthouseを紹介したい。 LighthouseはChromeの拡張ツールで導入できる、手軽なwebページの測定ツールである。 測定は多岐にわたるが、大きくは以下の五つに集約される。 <ul><li> Performance</li><li> Accessibility</li><li> Best Practices</li><li> SEO</li><li> PWA</li></ul> それぞれのスコアの見方については公式ドキュメントにあるので、読んでみると良さそう。 <a href="https://developers.google.com/web/tools/lighthouse?hl=ja" target="_blank" rel="noopener noreferrer">紹介ドキュメントはこちら</a> <a href="https://web.dev/learn/#lighthouse" target="_blank" rel="noopener noreferrer">スコアの見方</a> 当サイトも最初にテストした時はアクセシビリティに改善ポイントがあることがわかった。(ありがたいことにどうやって修正すれば改善するかも教えてくれる) 地道に修正していくと、下記の感じになり、合格点に到達していると思われる。 <img src="https://images.microcms-assets.io/protected/ap-northeast-1:658ce9f3-f881-4ea3-8c24-a60e5d6296f2/service/sirius/media/lighthouse_score.png" alt=""> 手軽な計測ツールがChromeの拡張ツールで取り入れられるので、まだ入れてないエンジニア、サービス関係者だったら、ぜひ入れて欲しいと思う。 品質を100%保証するものではないが、今よりは明らかに改善できるツールである。 あと、重要な事実としてこれらの指標が2021年5月あたりからのGoogleの検索ランキングに影響するという見解を出しているそうだ。 影響度合はわからないが、webサービス品質が良いものをなるべく上位に食い込ませて、ユーザー体験を向上させようとする狙いがうかがえる。 <a href="https://developers-jp.googleblog.com/2020/05/web-vitals.html" target="_blank" rel="noopener noreferrer">Googleのブログ内容</a>

webサービスというかwebページの品質測定には様々な見方があるし、測定ツールも様々である。
今回はそんな中でLighthouseを紹介したい。

webページの品質を測定

<h2 id="h7b0d1f391a">今年一年の技術スタックを振りかえる</h2> 今年も一年が終わった。 今年はコロナ禍ということもあり、ほぼ一年中どこにも出かけず(ジム行ったり、買い物ぐらいはしたけど)ずっとコードを書いていた。 なので一年を振り返ってもコードぐらいしか記憶がない。 でも今年は個人的には公私に渡って最も多くのプロダクトを作れた年でもあったと思う。 そしてフロントは2020年は激動の一年だった。 具体的にはNext.jsがSSRからSSGに大きくテコを入れたこと、Vue3の登場でこれからのVueのコーディングや設計が大きく変わること、 この二つが個人的に最も大きかったと思う。 人間の目に触れやすいインターフェースに近づくほど技術革新が凄まじいというのを最も実感した。 一方、AWSも今年でAmazon Linuxの基本機能におけるAMIサポート終了という流れもあり、インフラ側も一定の動きがあったようだ。 一部は3年先まで延長っぽい?→ <a href="https://aws.amazon.com/jp/blogs/news/update-on-amazon-linux-ami-end-of-life/" target="_blank" rel="noopener noreferrer">公式ドキュメント</a> 技術革新について行くには手持ちの環境やライブラリ、モジュールを常にアップデートし続けること。 これが技術負債解消にもつながる、と個人的には思っているし、これからもそうしていくだろう。 昔はアップデートは大変だったと思うが、コードに関しては今やdependabotがあったりして一部、あるいは全てを自動化できるようになった。 楽をするために、手間を惜しまないをモットーに来年も疾走する。

今年も一年が終わった。今年はコロナ禍ということもあり、ほぼ一年中どこにも出かけず(ジム行ったり、買い物ぐらいはしたけど)ずっとコードを書いていた。なので一年を振り返ってもコードぐらいしか記憶がない。




技術スタックを振りかえる

Vue 3 がリリースされてはや１ヶ月半が経過し、公式ドキュメントや先行して試した方々の知見が蓄積され始めている。 僕の場合は業務でVueを使う場面は限られているのだが、やはり3になると今までの書き方とは大きく変わるという前評判を聞いていたので早速試してみた。 ちなみに、Vue 3のバージョン名というか愛称は「One Piece」らしい。少年ジャンプのOne Pieceになぞらえてアイコンはあれである。 (著作権とか大丈夫なのかというのは気になるが。。。) <h2 id="h06843bf80c">Composition API</h2> やっぱり一番驚いたし、素直に嬉しい機能である。 Vueだと、今までいわゆるコンポーネントの内部でAPI通信とかを呼び出しすると、その関連ロジックが都合上、どうしてもView Component側に流れてしまうケースが発生する。 要するにロジックの分離と共通化というのがVueだと難しい場面があり、課題があった。 しかし、Vue 3からは(2系でもプラグイン経由で使えるらしい?)このComposition APIを使うことで、上記のことが分離できる。 書き方はこれまでのVueとはちょっと一味異なっていて、これはどちらかというとReactのCustom Hooks書くのに似ている。 このAPIを本格的に使いこなすためにはいわゆるロジックの隠蔽化やオブジェクト指向といった考え方が試されるので、プログラマーの腕が試される。 そして、このAPIで特に使われそうなのが、reactiveとrefと考えている。 いずれもコンポーネントで柔軟に使用できる値をリアクティブな値として提供されている。(ここら辺公式Docがより詳細に説明している) あとは型推論もちゃんと効いていて、VueがTypescriptに本腰を入れ始めていることを実感した。 他にもあるけど、紹介しきれないので次回以降に持ち越し。

Vue 3 がリリースされてはや１ヶ月半が経過し、公式ドキュメントや先行して試した方々の知見が蓄積され始めている。
僕の場合は業務でVueを使う場面は限られているのだが、バージョン3になると今までの書き方とはうって変わるという前評判を聞いていたので早速試してみた。


Introduction

Oss/GitHub

Career

Articles

ブログ記事に全文検索を追加した

Cypressでお手軽画面テスト

質とスピードという資料を読んで

webページの品質を測定

技術スタックを振りかえる

Vue 3を試してみる

Articles Search