ゆとり日記

心にゆとりを持って生きたいプログラマーの雑記です。気が向いたら書きます。

グラフィックレコードを英単語の暗記に利用する

英単語の暗記を日常的にやっているんですが、頭に入ってこない単語や熟語がたまに出てきます。 字面から意味を想像しにくい熟語が出てきた時にそうなりがちで、なかなか覚えられないことがストレスになっていました。

そのイライラポイントを解決するため、例文をイラストで表現して記憶の定着を狙うことを考えました。

具体的にやっていること

グラフィックレコードについての話はここでは省略します。

僕はグラフィックレコードの手法を利用しているのではなく、グラフィックレコードの練習と英単語の暗記を一緒にやっていると説明するのが正確かもしれません。情報をイラストで表現することがグラフィックレコードの練習にもなりますし、英語の例文をイラストで表現することが記憶の定着の手助けになると考えています。

実際にやってみた

"You've lost me." という表現があります。TOEICやTOEFLのリスニング練習をしていると出てくる口語的な表現で「あなたの言っていることがわかりません」「話についていけません」という意味です。覚えてしまえばなんてことはないですが、僕はなかなか覚えられなくて苦労しました。

このフレーズが出てくるであろう状況をイラストで表現してみます。

積分の話をされて困惑している人の様子
積分の話をされて困惑している人の様子

積分の話をされて困惑している人の様子を書いてみたイラストです。実際の会話だと、" I'm sorry. You've lost me. Can you explain about integral?" のようなやり取りになるでしょうか。積分の話が分からなくて困っている様子をどう表現するかが意外と大変でした。

落書きのような絵ではありますが、試行錯誤することが記憶の定着につながっている感触は間違いなくあります。

書いている時に意識したこと

いくつか意識したことがあります。

  • 性別はイラストの要素に含めない。
  • 言葉はなるべく使わない。
  • 時間をかけすぎない。

今回は「積分が分からなくて困惑している人」がテーマだったので、イラストに性別の要素を含めないようにしました。主題と関係のない要素を含めると、ノイズになると考えてのことです。

残りの2つはただの縛りです。相手の発言に困惑している様子の表現を楽しみつつも、ダラダラしないことを自分へのルールとしました。言語を用いない感情表現を楽しみつつ、長い時間は使いません。イラストを書くことが目的ではないので、基本的には5分〜10分の制限時間を設けています。

暗記にイラストを用いた感触

英単語の暗記に少し飽きていたので、個人的にはいい刺激になっています。音読をしつつ、状況をイラストで表現することで英単語の学習がほんの少しだけ楽しくなりました。英単語の暗記に飽きてる人にはおすすめです。

参考図書

www.amazon.co.jp

グラフィックレコードの練習の仕方は、この本で勉強しました。アフィリエイトのリンクではので、気楽にポチってください。

GitHub Actionsを使って、Next.jsを静的にデプロイする

「Next.jsを静的サイトにホスティングできるんだっけ・・？」

Deployment | Next.js

公式にStatic HTML Exportと書かれているので出来るはずですが、自分で試さないと安心できなかったのでやってみました。

実現したいこと

Next.jsで作成したアプリケーションを静的サイトとしてデプロイするが目的です。 今回はデプロイ先として、GitHub Pagesを選択しました。

実際に動いているURLはこちらです。 Next.js Sample Website

デプロイまでの手順

  • GitHub Pagesとして使うリポジトリを用意する。
  • Next.jsのnext buildでビルドしたソースコードをnext exportで静的サイトとしてエクスポートできるようにする。
  • GitHub ActionsでGitHub Pagesにデプロイできるようにする。
  • masterブランチへのpushをトリガーにして、 GitHub Actionsが動くようにする。

必要な手順はこのようになります。一つずつ見ていきましょう。

GitHub Pagesとして使うリポジトリを用意

https://help.github.com/ja/github/working-with-github-pages/about-github-pages

公式のドキュメントを一読しましょう。日本語のページが用意されているので、実際に手を動かしてやってみるのがおすすめです。

静的サイトとしてエクスポートする

"scripts": {
  "dev": "next dev",
  "build": "next build",
  "start": "next start",
  "export": "next export"
}

package.jsonの抜粋です。next exportがエクスポートのコマンドなので、npm run exportで実行できるようにしておきましょう。 yarnでも同様の進め方が可能ですが、今回はnpmで進めていきます。

GitHub Actionsでデプロイ

github.com

今回はこちらを使っていきます。

help.github.com

Actions上でNode.jsを扱いたいので、こちらを参考にしつつ以下のようなymlファイルを用意します。

name: Node.js CI

on:
  push:
    branches: [ master ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
      - name: Install dependencies
        run: npm ci
      - name: build
        run: npm run build
      - name: export static html
        run: npm run export
      - name: jekyll
        run: touch ./.nojekyll
      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@releases/v3
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          BRANCH: master
          FOLDER: out

masterブランチへのpushをトリガーにして、GitHub Pagesへのデプロイまでを実行できるようになりました。 見れば分かる箇所は飛ばしつつ、補足をしていきます。

yamlのファイル名

今回はGitHub Actionsを1つ試すだけなので、適当な名前でOKです。作成したyamlは.github/workflows配下に配置しましょう。

jekyllの無効化

- name: jekyll
  run: touch ./.nojekyll

GitHub Pagesではデフォルトでjekyllの変換機能が入っていますが、今回はNext.jsの静的ホスティングを試すために変換を無効にする必要が出てきます。

.nojekyllをルートディレクトリに配置することで無効にできるので、忘れずに入れておきましょう。

デプロイ指定の落とし穴

- name: Deploy
  uses: JamesIves/github-pages-deploy-action@releases/v3
  with:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    BRANCH: master
    FOLDER: out

BRANCHの指定はGitHub Actionsのトリガーに選んでいるブランチと同じにしましょう。master以外のブランチでGitHub Actionsが動くように設定している場合はBRANCHの変更も忘れないでください。

FOLDERに指定しているoutディレクトリは、next exportでソースコードがエクスポートされるディレクトリです。指定があっていないと「CIは正常に通ってるけど、ページが見れない」状態になってハマるので注意してください。

まとめ

同じことを試されている方が多くいたのですんなり行くかと思っていましたが、意外とハマりどころがありました。GitHub Actionsの練習にもなるので、これから入門する人はやってみるのがオススメです。

React Hooksを使ってJavaScriptを動的に取得する

「Next.js、全然分からない」「Reactやるのが久しぶりで何もわからない」

このようにボヤきながらReactと向き合う中で、しばらくハマっていたことが解決したのでブログに纏めておきます。

何が解決したのか

独立したJavaScriptファイルを取得Custom Hookを作ることができました。

自前のソースコードを書くだけなら要らぬ心配ですが、サードパーティのスクリプト（Google Analyticsなど）をSPAでそのまま使いたい場合があると思います。そういう時に使えるかもしれない裏技です。

動作サンプル

https://codepen.io/rukiadia/pen/JjYadOL

画面表示後にjQueryのコードをCDNから取得しています。あくまでサンプルなので、jQuery云々は気にしないでください。

  • react v16.13.1
  • react-dom v16.13.1

Reactのバージョンはこちらで動作させています。

コードの説明

const { useEffect, useState } = React;
// 手元で試す場合は以下
// import React, { useEffect, useState } from "react";

const useScript = (src) => {
   // 「取得の完了」「取得時のエラー判定」をLocal Stateとして扱う
   const [state, setState] = useState({
     loaded: false,
     hasError: false
   });

  useEffect(() => {
    const scriptElement = document.createElement('script');
    scriptElement.src = src;

    const onLoadFunction = () => {
      setState({
        loaded: true,
        hasError: false
      });
    };

    const onErrorFunction = () => {
      // 取得失敗時、コンポーネント側でエラーハンドリングするフラグを立てる
      setState({
        loaded: true,
        hasError: true
      });
    };

    scriptElement.addEventListener('load', onLoadFunction);
    scriptElement.addEventListener('error', onErrorFunction);
    const wrapper = document.getElementById('wrapper');
    wrapper.appendChild(scriptElement);

    return () => {
      // load、error時の処理を関数化しておけば、ここでremoveEventListenerできる
      scriptElement.removeEventListener('load', onLoadFunction);
      scriptElement.removeEventListener('error', onErrorFunction);
    }
  }, []);

  return [state.loaded, state.hasError];
};
  • 動的にscript要素を生成してJavaScriptを取得する。
  • 「取得の完了」か「取得の成否」をLocal Stateとして管理し、結果をuseScriptを使っているコンポーネント側に返す。

やっていることを箇条書きにすると、このようになります。

実装時に気をつけること

動的に生成したscriptで取得したJavaScriptからはdocument.writeを呼び出せないので、document.writeが含まれている場合はこの手法が使えません。非同期取得を試す前に取得相手の中身は軽く見ておくようにしましょう。

Custom Hookの命名はuseで始める

ja.reactjs.org

カスタムフックとは、名前が ”use” で始まり、ほかのフックを呼び出せる JavaScript の関数のことです。

自作する場合は自由な命名をしないように意識しましょう。

ja.reactjs.org

"use"で始めなくても動かせてしまうので、公式で提供されているESLintを使っておくのが安全です。

参考資料

WebRTCを効率的にキャッチアップする

仕事でWebRTCを使うことになり、この一週間くらいはキャッチアップに勤しんでました。 ベースとなる知識の習得と、最新動向を知るためのアプローチについてブログに書いておきます。

まず大事なこと

最初のうちは、古い情報を見ないようにしましょう。 WebRTCは変化が早い技術なので、ブラウザの対応状況や最新仕様は頻繁に変わっていきます。前提知識がない状態で古い情報にアクセスすると、その情報が今も使える知識なのか判断できずに混乱してしまいます。

WebRTCで有名な人や企業を探す

WebRTCに限った話ではないが、業界の最先端でいる人や企業を探して最新動向を入手しやすくしよう。

すぐに思い浮かんだ企業はこちらの2社。

個人単位ではこの辺りの方達をフォローした。

参考に出来る資料を探す

W3Cの資料読めばいいっちゃいいんですが、網羅的に書かれた説明を読んだり聞いたりもしたいところです。 なので、udemyで動画講座を探したり、O'Reillyで参考書籍を探してみましょう。

動画

Udemyは講座がそもそもあまり無かったり、最終更新日が古いものも混ざっていて参考にできそうなものはなかった。 Youtubeで過去に開催された「HTML5 Conference」や「WebRTC Meetup Tokyo」の録画を見ることは可能だった。

youtu.be

youtu.be

書籍

色々漁ってみたが、参考にできたのはReal World HTTPとハイパフォーマンス・ブラウザネットワーキングの2冊。

「Real World HTTP」で大まかな概論とユースケースを理解して、「ハイパフォーマンス・ブラウザネットワーキング」でWebRTCのプロトコルの詳細を理解するようにすれば、学習がスムーズに進むかもしれません。

「ハイパフォーマンス・ブラウザネットワーキング」ではWebRTCを支えるプロトコルであるUDPについても詳しく解説されているので、予備知識に不安がある人は知識を補っておくとベター。

実際に作って練習する

概論を読んだだけだとイメージが湧かないので、チュートリアル的なものをこなしてみると良い。

SkyWayは有料のプラットフォームだが、開発用アカウントを作ると無料枠があるので、そちらで動きを試すのがオススメ。 WebRTCに必要なサーバ（シグナリングサーバーやTURNサーバー）も用意されているので、手早く試せる。

まとめ

簡単ですが、自分が調べたりやってみたことを纏めてみました。 僕と同じく、これからWebRTCに入門しようとしている人の道標になってくれれば幸いです。

WEB+DB PRESS Vol.116「はじめてのトラブルシューティング」特集に寄稿しました #wdpress

04/24（金）発売のWEB+DB PRESSの「はじめてのトラブルシューティング」特集に寄稿しました！

WEB+DB PRESS Vol.116の表紙
WEB+DB PRESS Vol.116

@soudai1025さん、@yutailang0119さん、@maeponさんとの共著で、僕は@maeponとフロントエンドのトラブルシューティングを担当しました。フロントエンドの基礎知識から、パフォーマンス、アクセシビリティにも触れた内容になっています。

4/16頃から大型書店ではテスト販売があるそうなので、見かけたら手にとって頂けると嬉しいです。

書いた経緯

昨年末、@soudai1025に誘ってもらったのがきっかけです。一人でやり切れるかどうかの不安が少しあったので、執筆経験のある同僚の@maeponに共著という形式でサポートしてもらう形で受けることにしました。

初めての原稿を書いてみてどうだったか

僕の担当は4ページ弱でしたが、正直とても大変でした。

初めての原稿に張り切りすぎて、文章のボリュームが膨らんでしまったのが最初の失敗です。 書いている途中に書きたいことが新たに出てきてしまい、結果的に規定ページの1.5倍近いボリュームになってしまいました。

膨らんだ文章を削っていくのもなかなかに大変でした。 どこを削るかも悩みました。また、削る過程で文章の構成がおかしくなってしまい、結果的に大部分を書き直したこともありました。 編集の稲尾さんや、レビューをしてくれた共著メンバーには負担をかけてしまったなと反省しています。

謝辞

重ねてになりますが、編集の稲尾さんをはじめ、原稿のレビューや校正をしてくれた共著メンバーにはとても感謝しています。 フロントエンドの章を分担していた@maeponには執筆の過程で大きなサポートをしてもらいました。

お疲れ様でした！

まとめ

修正の大変さに心が折れそうになる時期もありましたが、挑戦してみて本当によかったなと今では思っています！ 2020/04/24 (金) 発売予定のWEB+DB PRESS Vol.116をよろしくお願いします！！

リモートワークをしばらくやったので振り返る

タイトルのままです。リモートワークで働くようになって、今週で三週目に入ったので振り返りをしてみようと思います。

  • 良かったこと
  • 改善したいこと
  • 抱えているモヤモヤ

この辺りを触れていきます。

リモートワークの良かったこと

まずは良かったことから挙げてみます。

可処分時間が増えた

通勤時間が無くなったので、浮いた時間を使う選択肢が増えました。

電車通勤していた時は基本的に読書に時間を使っていましたが、電車が混雑して読書に時間を使えない場合もあります。また、通勤に使っている電車が事故で止まることもしばしばあったので、それが地味にストレスになっていました。

在宅であれば電車の運行状況や混雑状況は関係なくなるので、合間の勉強時間を安定して確保できるのはメリットだと感じます。

集中の時間が増えた

自分のタスクに没頭する時間は増えた気がします。

オフィスだと同僚とちょいちょい雑談をしたくなってしまうので、これをやらなくなったのが主な要因だと思っています。 雑談自体は数分で終わりますが、その後に集中状態に戻るまでにある程度の時間が必要です。これらの積み重ねでロスしていた時間が大きかったのでしょう。

しかし、雑談自体は良いことなので、雑談しすぎないようにするコントロールが重要だと考えています。「雑談は時間の無駄」と極端に考えず、適度にやっていけるのが最良でしょう。

現状共有を頻繁にするようになった

リモートワークだと個々の状況が見えづらくなりがちなので、自分の作業状況は意識的に共有するようにしました。

弊社には分報の文化があります。従業員は個々のチャンネルを作っていて、そこで勤怠報告をしたり、面白かった記事をカジュアルに共有したりしています。

僕の場合はタスクが順調に進んだ時は「秒で終わった」と言ってみたり、行き詰まった時は「完全に詰んだ」と言ってみたりして、自分の状況が他の人から見えやすいように意識するようになりました。

改善したいこと

良いこともありますが、もちろん上手くいってないこともあります。

早起きをするようにはならない

「通勤していた頃と同じ時間に起きて、早く仕事を始めて早く終わろう！」

リモートワークする前はこう考えていたんですが、実際は通勤時間の分だけ余分に寝るようになっただけに終わりました。 「遅く寝て遅く起きる生活」に脳がシフトしつつあり、早めの改善が必要なことをようやく自覚し始めました。

リモートワークになったからといって生活リズムを崩してしまうと、その影響がメンタルにも来るので一層の注意が必要です。

運動不足になった

これはリモートワークにしたことが原因ではなく、コロナが原因です。

2年近く日常的に通っていたジムに行けなくなってしまったので、運動や筋トレの時間を新規に作る必要が出てきました。 運動は外をランニングすれば済む話ですが、筋トレはそうもいきません。自宅でジムと同じトレーニングマシンを用意するのはスペース的に不可能なので、筋肉を落とさないためのトレーニングをしなければいけません。

現状では良い感じの習慣は作れていないので、今後数週間の課題として残しています。

抱えているモヤモヤ

ここからは改善すべき課題に近い、なんとなく思っていることです。

距離の遠い人がより遠く感じる

オフラインでコミュニケーション取れてなかった人達をより遠くに感じるようになった感覚を最近感じます。

仕事で関わることが少ない人と話す機会が少なくなりがちという課題は自分の中であったのですが、それを解決できないまま全社リモートワークに突入してしまったのが悩みになっています。また、4月に新たなに入社した人とも全然会話が出来てないのも良くないポイントだなと思っています。

組織の体制や方針の変更、新たに会社に入ってくる人とのコミュニケーション不足、リモートワークに慣れきれていない自分の精神状態。こういった起因による漠然とした不安の膨らみとどう向き合うかを考える毎日です。

余談

リモート飲み会は終電やトイレを気にする必要がなって便利な半面、延々と深酒出来てしまうリスクもあることがわかりました。 手の届くところにウイスキーのボトルとか置かないようにしましょう・・。