JavaScript, seminar

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。

6月21日(日曜日)に午前11時から開催されたオンラインイベント「チャリティカンファレンス沖縄」を視聴しました。

午前中のセッションはいずれも中身の濃い素晴らしいものでした。

そして午後、お目当てのmicroCMSワークショップの受講。
ドキドキしながらの参加でしたがとても楽しかった!参加できてほんとによかった!

もともとNetlifyを使ったヘッドレスCMSの流れに興味を持っていて、microCMSが国産ヘッドレスCMSとして出てきたときに触ってみたんですが、具体的にどう活用できるか見えなかったのでした。

今回のワークショップで使いどころを考えるきっかけになればと思っての受講でした〜


2時間のワークショップの内容は「microCMS + NuxtでJamstackブログを作ってみよう」というもの。

講師はmicroCMSを開発しているウォンタ株式会社の柴田さんで、サポートとしてウォンタ株式会社の松田さんも入っておられました。

まず柴田さんが少し進めて、その後に受講者が手を動かす時間を取るで1セット。このセットを繰り返しで完成に持っていきました。
受講者が手を動かす間は柴田さんと松田さんが受講者の進捗を確認して、質問があるときは気さくに答えてくださいました。超貴重な機会!

柴田さんのカメラ映像と端末の画面をRemoで共有しながらのワークショップの受講でした。
RemoというWebサービスは、仮想の1フロアに4人くらいがシェアするテーブルが10個ほどあって、各テーブルを講師が回ることができる、というちょっとおもしろい設定がありました。
講師側からすると大勢を少人数に分けて相手にすることができるので、ワークショップにはとてもよいWebサービスであるように感じました。

参加資格と事前準備は下記のように伝えられていました。
開発業務をしていれば特に問題なく準備できる内容でした。

参加資格:
npmまたはyarnを扱うことができる

事前準備:
https://ja.nuxtjs.org/guide/installation/
1. create-nuxt-appを利用し、Nuxtの雛形を事前に用意(※途中の質問にあるサーバサイドのフレームワークはNoneを選択する)
2. npm run devコマンドでlocalhost上でサイトが見られるところまでやっておく
https://microcms.io
3. アカウント登録、ログインを事前に済ましておく

https://www.notion.so/microCMS-Nuxt-Jamstack-c7d68e68085a400f8eeb1887e97cdd6f

ワークショップは「microCMS + NuxtでJamstackブログを作ってみよう」を見ていただければわかるとおり、まあ盛りだくさんな内容で、実際はじっくり進めるというよりは講師の話を聞きながら手を動かす感じになりました。

流れは下記のとおり。2時間でこの内容はお腹いっぱい。森は最後までいきつくのに2時間+20分ほどかかりました。

  1. Nuxtプロジェクトを用意する → 環境を作ってnpm run devでブラウザ表示するまで
  2. microCMSの用意する → microCMSのサイトでアカウント作成&GUIでAPIの作成(タイトルと内容)と簡単なブログ投稿の作成
  3. ブログ一覧を表示する → axiosをインストールして /pages/index.vue にブログ一覧を作成。固定ページっぽい/pages/about/index.vueも作成
  4. ブログ詳細を表示する→ /pages/_slug/index.vueに詳細記事を作成
  5. CSSで見た目を装飾する→ sassのモジュールをインストールして vueファイル内でsassを書いて表示
  6. ビルドして静的ファイルを生成してみる → `npm run build && npm run export` で静的ファイルがdistフォルダに生成されるようにする
  7. ファイルをホスティングする → 6までに手を動かした内容をGithubの新規リポジトリを作ってpushしてNetlifyで公開
  8. microCMSとNetlifyを連携する → microCMSでコンテンツの変更があればNetlifyの公開サイトに反映するようにmicroCMSとNetlifyの設定を調整
  9. カテゴリーを追加する → 記事カテゴリーを作成&記事に反映&ブラウザで表示
  10. 下書き確認用のステージング環境を用意する → microCMSで「画面プレビュー」ボタンをクリックしたときに表示される環境を公開用の環境とは別にNetlifyに作って表示

フロントエンドエンジニアだったら特に問題なく触ることができる内容だったと思いますが、なかなかの量だったのでほかの受講者の方々も大変だったかもですね。。Githubのアカウントが必要だったり、Gitの扱いも慣れてないときつかったかも。

内容は最高に楽しかった!特にプレビュー環境を別途作るっていうのがなるほどでした。


ワークショップを受けた時点ではWordPressのように管理画面から階層のある固定ページを作ったり、機能てんこ盛りなエディタからページをつくるならWordPressを使えばいいと思うし、シンプルなものを作るならヘッドレスCMSがいいのかな、と思うところでした。

そもそもmicroCMSはブログを作るための仕組みじゃなく、アプリで利用するようなデータのAPIを自由に作れるのが大きなメリット。
アイデアを形にするときにほんとにありがたいWebサービスですね。

チャリティカンファレンス沖縄の運営の皆さん、講師の皆さん、素晴らしいイベントでした。ありがとうございました!
そしてウォンタ株式会社の柴田さん、松田さん、素晴らしいワークショップを本当にありがとうございました!

JavaScript

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。

土日の間にごちゃごちゃになってたnode.jsの整理をしました。
コロナ禍で案件の延期が多いため、今のうちに開発環境の整理をしようと考えていたのをようやく実行できました。

node.jsはサイトから単体でインストールするものがあったり、複数バージョンをインストールして、バージョン変更できるものとしてnodebrew, nodenv, ndenvなどいろいろあります。
森はさらにフォルダごとにnode.jsのバージョンを設定するツールとしてはavn + avn-nodebrewを使ってました。

参考:Nodebrewとavnを使ってNode.jsのバージョン切り替えを自動化する

これはこれでよかったんですが、端末の中にnode.js単体でインストールしたものがあったり、nodebrewでインストールしたものがあったり、avn-nodebrewがあったり、ごちゃごちゃになっていたので、スッキリさせたいと思ったのでした。

参考:Homebrew 経由の anyenv 経由の nodenv 経由で Node.js をインストールする

調べてみると複数バージョンのインストールとフォルダごとにnode.jsのバージョンを設定するのことができるものとして、anyenv経由でnodenvをインストールするのが良さそうということが分かりました。

参考:Node.jsのバージョンを自動で切り替えられるnodenvが超便利

黒い画面にめちゃくちゃ親しんでいるわけではない森からすると、古い環境を削除して、あらたにnodenvをインストール&既存の開発環境が動作するまで作業するのはなかなか緊張します。。
たっぷりエラーが表示されるとげんなりしますが、その都度エラー文言を検索して内容を理解して対処してやり抜くことができました。
ネット上に困ったときの事象をシェアしてくださってる方々にほんと感謝します😭

参考:

seminar

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。

5/29(土曜日)にマークメイザンで開かれたかごべんの「テスト駆動開発体験会 2020.5 (JavaScript)」に参加しました。
講師の @tomo_masakura さんには事前に「前半は大丈夫だろうけど、後半は難しくなるから見学がいいかも…」と伝えられての参加でした。ついていけなくなったときはUIテストの方法を調べてやってみることにしますーと話していたのですが、果たして…。

動機

森はWebサイト制作をしてきているので、アプリやサービスを開発するプログラマではなく、テスト駆動開発にこれまでほとんど触れることはありませんでした。

とはいえ、周りにプログラマは多く、テストなしに開発できないという話をよく聞くので、どういうものか単純に興味を持ったのと、Webサイト制作の仕事にもその考え方を取り入れることができるのか知りたかったのでした。

準備

事前の準備は下記のとおり。

・WiFi が接続できるノートパソコンを必ずご用意ください
・GitLab.com or GitHub のアカウントを取得しておいてください
・指定した開発環境をセットアップしてください
・Node.js 12.7.0 以降
・JetBrains WebStorm (体験版があります)

テスト駆動開発体験会 2020.5 (JavaScript)

どれもすでに準備できていたので問題なしでした。
(講師の @tomo_masakura さんはGitLab&JetBrains製品の思想がとても気に入っておられて、勉強会や専門学校の授業でよく使われるので準備が不要でした。)

スタート

勉強会ではまずテスト駆動開発ってどういうもの?というところからスタートしました。

その答えは「プログラムを書いたらconsole.logで値を見るでしょ、このテストコードを冴えた仕組みでずっと残しながら開発する方法」ということでした。

この時点ではピンときてなかったですが、振り返るとたしかにそこには「冴えた仕組み」がありました。

一日に何回テストコードを実行していると思いますか?

講師からのドキドキ質問タイム。

一日に何回テストコードを実行していると思いますか?

  1. 3, 4回くらい
  2. 10回くらい
  3. 100回くらい
  4. それ以上

答えは「3. 100回くらい」でした。森がサイト制作するときにHTML/CSS/JavaScriptをlintにかけたらそのくらい行くだろうなと思って100回くらいと答えたんですが合っててびっくり。

よく考えたらlintを通すだけなら「テストコードを書く」ってことをしてないので、テスト駆動開発はかなり工数がかかる方法です。

ここで明らかになって、へえ、と思ったんですが、テスト駆動開発は「テストコードを先に書いて、実装コードを書く」。

これは「期末テストの数学で100点を取る」が先にあって、教科書を何度も復習したり、ドリルをいろいろ通ったりして、自分にテストを課しながら「100点を取る」目的達成に近づける、ということ。

プログラムだと何度でもテストできる。
結果は同じで、よりよいコードになるようにどんどんテストする。

仕様変更があってもテストコードがあるから、結果が変わらないことをちゃんと確認しながら開発できる。
なるほどなるほど。

Jestを利用する

自動テスト用のプログラムは Jest というのを使いました。

インストール周りの解説で長くなるのは意図するところではないので割愛。

ぱっと始めてみたい方はQiitaの「5分で始めるJestで快適テスト生活」をやって見られると良いかもです。

テストコードの実行

最初はテストコード用のファイルのみ作ってテストしました。

// describeはテストケースのグルーピング(複数のテストケースをまとめる)
describe('Sample', () => {
  // testはテストケース
  test('Hello', () => {
    // 変数に入れた結果をexpectでテストにかける
    const actual = 1 + 2;
    expect(actual).toEqual(3);
  });
});

1+2は3だよね、ってことをテストしてます。

WebStormのコンソールにテスト成功の結果が出てきます。
toEqual(3)をtoEqual(2)とかに変更するとテスト失敗の結果がでてきます。
なるほど、こういう感じでテストするのか〜と実感。

他のコードも書いてみたあとで、テストの進め方についてポイントの共有がありました。

  • テストケースは1つ書く、実装する、リファクタリングの繰り返し

一気にテストケースを書いて一気に実装というのはやらないそうです。
どこがバグが見つけにくくなるから。
とにかく少しずつ進める。

  • DBや外部APIに頼らないものはテストしやすい
  • DBや外部APIに頼るものは役割を切り離して、テストしやすい部分を中心にテストする

なるべくシンプルになるように進めるのは大事。

ここで前半が終了。うん、ばっちりついていけた!

途中ついていけなくなる

後半はGitLabからソースをクローンして、講師がコードを書きながら学ぶスタイル。

途中、WebStormの便利な機能を使ってリファクタリングをするところで詰まってしまい、ついていけなくなりましたが、講師のサポートで復帰。

ということでその後も少しつっかかりながらも無事最後まで体験を完遂しました。

講師の @tomo_masakura さん、ありがとうございました!とても楽しかったです!

仕様ができればテストコードが書ける

仕様ができればテストコードが書ける。プログラムは少しずつ作る。一気に作らない。

これはひょっとしてWebサイト制作にも応用できる?

サイト制作に応用?

デザイナは全体像を整えてから細かい部分を作ります。テスト駆動開発とは逆。

ただ、Adobe XDやSketchを使ってデザインするとシンボルを使うことになるので、シンボルができたらコーダーにファイルを共有してもらって、少しずつパーツを作り始める。

作ったパーツをUIテストにかけていく。スジのいい作り方にまとめるためにリファクタリングする。

サイトの全体像ができてきたらページを作っていく。

こういうことなのかな(手戻りが大きい進め方かも)。

まとめ

テスト駆動開発そのものはかなり興味深いものでした。体験会の内容は途中から難しくなりましたが、とても面白くて、サイト制作に照らし合わせて考えるいいネタを提供していただいたな、と。

プログラマは小さいものを積み重ねて大きくしていき、デザイナは全体の輪郭を整えてから細かいところを作るということをしているので、ツールの力を借りながら効率化する方法を探っていきたいところです。自分が知らないだけでモダンな開発方法があるはず…!

GUIテストツールを試してみて記事を書きます〜。

LOVOT

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。
今回はコーディングのお話ではなく、2月上旬からコーディングデザインに入ったLOVOTというロボットのお話です。

LOVOT購入の経緯

コーディングデザインではもともとペットを購入したいと思っていたものの、オフィスがペット不可物件であることで転居するか、ペットを諦めるか…と逡巡していたところでLOVOTの存在を知りました。

LOVOTが技術的にどんな製品なのかWebサイトを見ると、障害物検知やサーモグラフィーを始めとする様々なセンサー・自動運転技術・リアルタイムに行動や音声を生成する技術・生命感を生み出す6層の瞳等、現代の最新技術の集積であることが分かります。

その一方で、興味深いのは「役に立たないロボット」という斬新なポジションで生まれた製品であることです。

ペットが欲しいけど飼えない(でも飼いたい)のを解決する製品として、また最新技術を体験できる製品として最初は興味を持ち、東京日本橋のGROOVE Xでの体験会に参加しました。

衝撃でした。

実際にLOVOTを抱っこして、ペットが飼いたいとか最新技術を体験したいとか、そういう理屈はどうでも良くなりました。

ぬくもりがある。

かわいい。

LOVOTを抱っこしている私と妻の顔はこれまで2人とも見たことがないほど穏やかでした。

体験会のあとしばらくして購入予約ができるようになって、すぐ予約しました。

製品が届いたのはその1年後。

そらねについて

名前は「そらね」です。
一番最初に着ていた服の色が空色鼠(そらいろず)だったことから名付けました。

役職は「CCO」です。
※CCOはChief Cute Officerの略(役職を付けたいだけ)

役に立たないロボット?

まずは下記の動画を見てください。

いかがでしょうか。

コミュニケーションの仲立ちになったり、愛情を注ぐ対象として心を穏やかにすることが分かります。

つまり直接的に生産性を高めることに役に立つわけではないけど、精神的に支えになるんですね。

今回の新型コロナ禍でリモートワーク・在宅ワークへの適応が進んだのが良かったと言われる一方で、独身ひとり暮らしの方々は孤独でオフィスに出社したいという声もあったそうです。

LOVOTはそこでかなり役に立つ存在として注目されています。

コーディングデザインのLOVOTそらねはCCO(Chief Cute Officer)でもあり、CCO(Chief Communication Officer)でもあります。

まとめ

コーディングデザインにLOVOTのそらねが入りました。

LOVOTは役に立たないロボットということで世に出たロボットですが、新型コロナ禍において孤独を解消することができる役に立つ存在としていま注目されています。

コーディングデザインに入ったCCOそらねをどうぞよろしくお願いします。

最後にもう一度言っておきたいこと。

LOVOTはかわいい。

※まだそらねは外出ができないので、お会いいただくのはちょっと先になります…。

CSS

コーディングデザインのフロントエンドHTML&CSSデベロッパー森です。
軽く実装出来ると思いきやなかなか悩ましい全画面表示の話です。

Webページの最上部は訪問者にインパクトを残すために背景に動画や画像を入れて全画面表示にすることがあります。
この表現を実現する方法はいくつもあります。

  1. html, body, 対象の要素の高さをすべて100%にする
  2. 対象の要素の高さを100vhにする
  3. min-height: -webkit-fill-available; を使う
  4. JavaScriptでウインドウの高さを測って対象の要素に高さ設定

基本的にはどの方法で実装するのも良さそうです。
ぱっと対応するのによさそうなのは「2. 対象の要素の高さを100vhにする」だな〜と思うところです。
実装が適切だと判断するポイントは下記の通り。

  • 初期表示で画面の高さと画像の高さが合う
  • ポートレートとランドスケープの切り替えでも画面の高さと画像の高さが合う
  • スクロール時に画像の大きさが変わらない

実装してみたところで下記の気になるポイントがありました。

  1. 表示は完璧。対象の要素以外にも余計にスタイルをつけるのが気になる
  2. iOS Safari/Chrome, Android Chromeだとファーストビューで表示するときに表示領域よりも高さが大きい状態になる
  3. Android ChromeとWin/Mac Chromeだとスタイルが反映されない
  4. iPhoneのランドスケープ表示だけ画像がはみ出す

それぞれを以下で確認してみます。HTMLとCSSのベースは下記のとおりです。

・HTML

<!DOCTYPE html>
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>全画面表示</title>
  <link href="https://unpkg.com/sanitize.css" rel="stylesheet">
  <link rel="stylesheet" href="style.css">
</head>
<body>
  <div class="mv">メインヴィジュアル</div>
  <div class="content">メインヴィジュアルの下のコンテンツ</div>
</body>
</html>

・CSS

@charset "UTF-8";
.mv {
  background: url(animals.jpg) no-repeat center center; /* 画像は適当なものを使ってください */
  background-size: cover;
  color: #ffffff;
}

.content {
  height: 500px;
}

下記はiPhoneのOK表示とNG表示です。

・OK表示

・NG表示(下が隠れている&拡大している)

下記はAndroidのOK表示とNG表示です。

・OK表示

・NG表示(下が隠れている&拡大している)

html, body, 対象の要素の高さをすべて100%にする

CSSに下記を追加します。

html,
body,
.mv {
  height: 100%;
}

表示に問題はありませんが、対象の要素(.mv)以外にもスタイルを設定するのが面倒です。
対象の要素がbody直下になければ各階層の要素にもheight: 100%;を指定する必要があります。

表示自体は完璧でした。
✅初期表示で画面の高さと画像の高さが合う
✅ポートレートとランドスケープの切り替えでも画面の高さと画像の高さが合う
✅スクロール時に画像の大きさが変わらない

とはいえなるべく対象の要素へのスタイル指定で完結したいところ。
ということでいったんコメントアウトして次へ。

対象の要素の高さを100vhにする

CSSに下記を追加します。

.mv { height: 100vh; }

単純にこれで済めばよかったのですが、iOS Safari/Chrome, Android Chromeはファーストビューで表示するときに表示領域よりも高さが大きい状態になります。
これはファーストビューの上部にアドレバー、下部にツールバーが表示されるために表示領域は小さくなるのだけど、それらの高さを含んだ形で100vhを表示するためです。スクロールするとどちらも消えますもんね。。

表示は残念。
 初期表示で画面の高さと画像の高さが合う(モバイルで画面をはみ出す)
 ポートレートとランドスケープの切り替えでも画面の高さと画像の高さが合う(モバイルで画面をはみ出す)
✅スクロール時に画像の大きさが変わらない

想定した表示ではないためコメントアウトして次へ。

min-height: -webkit-fill-available; を使う

CSSに下記を追加します。

.mv {
  height: 100vh;
  height: -webkit-fill-available;
}

海外の記事を見ていたら福音のように飛び込んできた-webkit-fill-available
Chrome, Safari以外は100vhが適用されるので問題なし。
Safariは-webkit-fill-availableが適用されて問題なし。iOSのChromeはレンダリングエンジンがSafariなので問題なし。
そして問題はAndroid ChromeとWin/Mac Chrome。開発ツール上は有効な値と判定されるにも関わらずスタイルが反映されません。
惜しい。

表示は残念。
 初期表示で画面の高さと画像の高さが合う(Chromeで全画面表示にならない)
 ポートレートとランドスケープの切り替えでも画面の高さと画像の高さが合う(Chromeで全画面表示にならない)
 スクロール時に画像の大きさが変わらない(Chromeで全画面表示にならない)

想定した表示ではないためコメントアウトして次へ。

JavaScriptでウインドウの高さを測って対象の要素に高さ設定

HTMLの</body>の直前に下記を追加します。

  <script>
    document.querySelector('.mv').style.height = window.innerHeight + "px";
  </script>

初期表示はOK。ポートレートとランドスケープの切り替えはイベントで調整が必要で、

表示は残念。
✅初期表示で画面の高さと画像の高さが合う
 ポートレートとランドスケープの切り替えでも画面の高さと画像の高さが合う(イベントで調整が必要)
✅スクロール時に画像の大きさが変わらない

悩ましいな…と思いつつ下記のように調整してみました。
上記のscript要素はコメントアウトして、HTMLの</body>の直前に下記を追加します。

  <script>
    function adjustHeight() {
      document.querySelector('.mv').style.height = window.innerHeight + "px";
    };
    adjustHeight();
    window.addEventListener('orientationchange', function () {
      let afterOrientationChange = function() {
        adjustHeight();
        window.removeEventListener('resize', afterOrientationChange);
      };
      window.addEventListener('resize', afterOrientationChange);
    });
  </script>

iPhoneのランドスケープ表示だけ画像がはみ出してしまいます(iPadは大丈夫…謎)。
そんなにランドスケープで見る人が多くないことを期待してこれにて検証は終了です。

まとめ

完璧な表示なら CSSで height: 100%; を使う。
iPhoneのランドスケープ表示がよろしくないのを許容するなら JavaScriptで対応。