ゆとり日記

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

『オブジェクト指向UIデザイン』を読んだ感想

はじめに

www.amazon.co.jp

UIデザインを学ぶ必要性を感じたので、積ん読にしていた本を読んでみました。この本を読む前は『はじめてのUIデザイン』を読んでいて、次は実際に手を動かすステップがある本を求めていたら、『オブジェクト指向UIデザイン』にたどり着きました。

オブジェクト指向UI」とはどんなものだった?

この本では、エンジニアとしては馴染みのある概念である「オブジェクト」をデザインを考えるために使用しており、「オブジェクト = ユーザーの目当て」と表現しています。この場合の「目当て」とは、AmazonのようなECサイトであれば「商品」となり、はてなブログやnoteのようなコンテンツを扱うサービスであれば「コンテンツ」となります。目当てとなるオブジェクトを中心にユーザーが行う行動を設計していく手法がこの本では語られています。

  • ECサイトの「商品」に対する行動
    • 詳細を見る
    • 検索する
    • 「欲しい物リスト」や「気になるリスト」に入れる
    • バスケットに入れる

このように「オブジェクト = ユーザーの目当て」を中心に行動を考えていきます。つまり、UIデザインを実際に始める前に、アプリケーションのメインが何になるのかを先に考えていきます。

オブジェクト指向UI」とは逆の「タスク指向UI」

オブジェクトではなく、タスクを中心に考える手法です。ECサイトを例に言語化するとm「〜を買う」の動詞に対して、名詞である「商品」を引数として渡すイメージです。

この本では銀行のATMを例に挙げていました。最初の画面で利用者に行動(引き出し、振り込み等)を選択させるUIとなりますが、ATMの場合は「タスク指向UI」が機能する例として扱われています。何故なら、ATMで扱うオブジェクトは「口座」のみだからです。

現実でありがちな「タスク指向UI」

現実世界のやり取りをそのままUIに落とし込むと「タスク指向UI」になりやすいと個人的には考えています。ここで、ハンバーガーショップハンバーガーを買うシーンを想像してみてください。

  • お客さん「注文いいですか?」
  • 店員さん「店内でお召し上がりでしょうか?」
  • お客さん「持ち帰りで」
  • 店員さん「ご注文をお伺いします」
  • お客さん「チーズバーガーのセットで。飲み物はコーラでお願いします」
  • 店員さん「お支払い方法はどうされますか?」
  • お客さん「Suicaで」

実際の店舗で行われるやり取りの基本です。このやり取りをそのまま画面に置き換えると、最初の画面は「店内or持ち帰りを選択する画面」になるはずです。この本を読んだ後、飲食店の券売機やオンライン注文を実際に利用してみました。

牛丼チェーンはテイクアウト不可の商品もあるので、最初に「店内で食べるか」を選択させたいのは理解できます。決済する段階まで進んだ後に「この商品はテイクアウト不可」ですと言われたらムッと来ますからね・・。

ですが、ピザを注文する時に「配達」か「持ち帰り予約」を最初に選択させられるのは納得いきませんでした。メニューを見たかったのですが、配達先の住所を入れ終わらないとメニューが表示されなかったのです。「配達」と「持ち帰り予約」の違いは割引があるかどうかだけなので、「まずはメニューを見せてくれ!」という気持ちでいっぱいでした。

読んでみた感想

自分のような「デザインを少しでも理解したい非デザイナー」には得るものが多い書籍でした。普段使っているアプリケーションの画面を見ている時も「このアプリの主要人物は誰だろう?」と考えるようになったので、自分の中での思考の変化を感じています。書籍の1/3は読者が画面を実際に作るパートになっており、この構成も理解を深める助けになっています。

一方で少しひっかかる箇所もありました。プログラミングやデータベース設計を比較例として挙げている頁があるのですが、非エンジニアの人には逆に伝わりにくくなっている印象です。エンジニア側の自分にはスッと入ってくる話でしたが、賛否が分かれるところだと思います。

PHPerKaigi 2021でDIの話をしてきました

phperkaigi.jp

3/26〜28の3日間で開催されたPHPerKaigiにCFPを通すことができたので登壇してきました。

今回のネタ

今回はDependency Injectionに焦点をあてて、今こそ理解するDI(Dependency Injection)というタイトルにしました。TimeTableを改めて見てみると、僕以外にもDIの話をされる方がいらしたので、そんな中で採択されたのはとても嬉しかったです。

テーマをDIにした理由

  • CakePHPにDIコンテナが実験的に導入されるにあたって、DIを正確に理解しておきたかった。
  • PHPに限定した話にしたくなかった。

理由は2つあります。

1つめはCakePHPにDIコンテナが実験的に導入されるにあたって、DIを正確に学んでおきたかったからです。

book.cakephp.org

僕は元々Java畑でプログラミングに入門した人間です。Seasar2やSpringを使ったこともあるので、自分でも知らないうちにDIを使っていたとは思うのですが、人に言葉で説明できるほどの理解をしていませんでした。なので、CakePHPにDIが実験的に導入されると耳にした時、学びなおすチャンスだと思ったのです。

2つめは広めなテーマで話をしたかったからです。

僕は去年のPHPカンファレンスではPHPに限定した話でCFPを通すことができました。

今こそ理解する PHPの日時計算 / Understand date manipulation of PHP - Speaker Deck

その流れに乗るつもりで、今回もPHPに限定した話でネタを練っていましたが、PHPに限定しない話をしたい気持ちもありました。特に設計やデザインパターンにまつわる話に興味があったので、DIはCFPのテーマとしてマッチしていたというわけです。

録画収録の感想

PHPerKaigiのトークは事前収録だったので、本番の2週間前には収録を終えていました。

枠は20分と決まっているので、20分ジャストで終われるように事前練習を何回かおこないました。初回の事前練習では、余計な小話をしたせいで26分程度かかっていましたが、話す内容を絞り、話す速度を調整することでなんとか形にできました。

個人的に意外だったのは、トークを事前に収録してあっても、本番で自分のトークが始まる前は緊張してしまうことでした。Ask the Speakerでちゃんと受け答えができるか不安だったんですかね・・?

まとめ

トークの準備はかなり大変でしたが、話す側でイベントに参加すると本当に勉強になりますね。Ask the Speakerの時間で理解を更に深められた気がします。

  • 「GoにはInterfaceがないが、InterfaceがないとDIはやれないのか?」
  • 「一般的なデザインパターン(Factory Method等)とDIの使い分けはどうすればいいのか?」

この辺りは自分の中でも新たな課題として残ったところなので、PHPerKaigiの登壇で満足せずに深堀りを続けていきます。

Amazon | Head First Design Patterns | Freeman, Eric, Robson, Elisabeth, Sierra, Kathy, Bates, Bert | Software Development

「Head First Design Patterns (リンクは2nd edition)」が参考文献としてすごく良いらしいんですが、632ページもあるうえに英語なので途中で挫折する気がしてなりません(´・ω・`)。

Amazon | Dependency Injection Principles, Practices, and Patterns | Seemann, Mark, Deursen, Steven van | Software Development

僕の登壇資料の根っこになっている「Dependency Injection Principles, Practices」も良書なんですが、日本語版がないので誰かに翻訳してほしいなって100回くらい思ってます。

PHP Conference Japan 2020 Re:bornに登壇してきました

phpcon.php.gr.jp

本日行われた、こちらのイベントに「今こそ理解するPHP日時計算」というタイトルで登壇させていただきました。 資料は発表前にSpeakerDeckにあげているので、そちらでご覧いただけます。

今こそ理解する PHPの日時計算 / Understand date manipulation of PHP - Speaker Deck

CFPが通った感想

正直言うと、CFPが通るとはあまり思っていませんでした。PHPの8系やcomposerの2系が出るタイミングでもあったので、セッションはそういった話題で埋まってしまうだろうと予想していたわけです。

予想に反してCFPが採択された時は、嬉しさ半分、驚き半分の気持ちでした。「こんな地味な内容で人が集まってくれるのかな・・?」という不安はあったものの、僕が過去に躓いたトピックが刺さる人は一定数いると考えることにし、資料作りに勤しみました。

準備にあたって意識したこと

  • 普段話をする時よりも、少しゆっくりめに話す。
  • 素振り(事前の1人リハーサル)を多めにやる。

今回は以上の2点を意識しました。

「オンライン配信で早口で話しすぎると、リスナー側が聞き取りにくいのでは?」と思い、本番では素振りをした時よりも少しゆっくりに話すことを意識しました。話すスピードを考慮して直前に内容を少しだけ削ったのですが、それでも1分半ほど時間をオーバーしてしまいました。タイムキーパーの方、すみません・・(´・ω・`)。

25分の枠で話すのも初めてだったこともあり、その感覚を掴むために予行演習もきっちりやりました。初回の予行演習は喋りに詰まってしまった上に説明も間延びしてしまい、正直聞けたものではなかったです。その後、自分の口から出た言い回しや説明をノートに書き出し、不要なものを削りつつ整理して本番に臨みました。

自分の録画を見返してみての感想ではありますが、70点くらいの発表には出来たんじゃないかと思っています。

オンラインのカンファレンスに参加した感想

聴衆側の観点でいうと、気軽に色んなセッションを覗きに行けるのが便利でした。オフラインだと、混みそうなセッションの会場に先に入っておいて待機するサイクルになりがちでしたが、オンラインなら会場の定員を気にする必要もないので楽です。

登壇側の観点でいうと、出番前の独特の緊張感が印象的でした。劇の出番を舞台袖で待つ役者はこういう気持ちなのかな・・とか考えながら待機していました。始まってしまえばスラスラ話せるものなんですが、登壇は何度やっても緊張するものですね。

discordを見ながら話すのは難しい

登壇時は、PCの脇に置いたiPadにdiscordの画面を映しながら喋っていました。コメントに対するリアクションを交えながら話すつもりでしたが、実際はそこまでの余裕がなくて歯がゆい思いをしました。

合間でコメントに反応する前提で話すなら、スライドの量もそれに応じて調整した方がよかったかもしれません。

まとめ

準備はそれなりに大変でしたが、参加して本当に良かったと思います。スタッフの方々の手厚いサポートもあって、不安の少ない登壇経験が出来た気がしています。本当にありがとうございました。

カンファレンスのCFPが正式に採択されたのも今回が初めてで、個人的にも一歩前進できて本当に嬉しいです。

会社のちょっとした宣伝

connehito.connpass.com

今週末の12/17(金)には自社のミートアップがあります!「サービス開発のあるある話」などをしつつ、会社を跨いだ交流が目的のイベントです。 興味のある方は是非ご参加ください〜〜!

O’Reilly書籍をサブスクリプションで読もう

この記事はコネヒト Advent Calendar 2020 2日目の記事です。

O’Reilly(以下、オライリー)のサブスクリプションに契約するとオライリーの技術書が読み放題になるので、今回はその話をします。

概要

www.oreilly.co.jp

www.oreilly.com

Safari Books Onlineという名称で提供されているデジタルライブラリサービスです。サービス名が紛らわしいんですが、SafariはブラウザのSafariとは関係なく、運営会社の名前です。

閲覧可能なのは本だけではなく、UdemyやUdacityで提供されている動画教材も豊富にあります。ただし、全てのコンテンツが英語なので、動画コンテンツの学習コストは高めかもしれません。

実際に読める本

オライリー本は全部あるんじゃないかと思える程度のラインナップなので、エンジニア界隈で話題になる本は見つかるはずです。僕が実際に目を通した本をいくつか挙げていきます。

Refactoring: Improving the Design of Existing Code

www.oreilly.com

マーチン・ファウラーのリファクタリング本の第二版です。

第一版はJavaのコードがベースになった内容でしたが、第二版ではJavaScriptのコードがベースになっており、2019年12月には日本語版も出版されています。余談ですが、僕が原著を読み終わった直後に日本語版の発売が発表されて愕然とした記憶があります。

Clean Architecture

www.oreilly.com

今日(2020/12/01)時点で何故かAmazonの紙在庫がなくなっていることでお馴染みの本です。これまた余談ですが、この記事で紹介しているサブスクリプションを知る前に原著を輸入しております。もっと早く知りたかった。

Escaping the Build Trap

www.oreilly.com

プロダクトマネジメント」という名前で出版で日本語訳が発売されています。現在進行系で会社で読書会をやっているので、読書会向けに買った日本語版と読み比べたりしています。

Programming PHP, 4th Edition

www.oreilly.com

この本は日本語訳が出ていないので、サブスクリプションで読めるのは非常に助かってます。紙媒体も持っているんですが、検索したい時はやはり電子書籍が便利です。

課金前に考慮したい点

個人的に気にした箇所をここで書いておきます。 クレジットカード登録不要のお試し期間が10日間あるので、使い勝手は実際に試してもらうのが良いと思います。

料金はやや高め

Online Learning Platform Pricing - O'Reilly Media

  • 個人利用
    • $49 / month
    • $499 / year

高めの技術書を月に1冊買える程度の料金がかかります。オライリーの本を読み放題であることを考えれば高いとは感じないかもしれないですが、そこは人それぞれです。 使用頻度が下がっているのに自動更新されてしまう事態を避けるため、年間契約の場合は自動更新をOFFにしておくのがオススメです。

サブスクリプションをおまけでもらう

agnozingdays.hatenablog.com

詳細は省きますが、年会費99$でサブスクリプション権をもらうことも可能です。

英語と向き合う気力

結論から言うと、書籍ならなんとかなりますが、動画はハードモードです。

電子辞書やDeepLを併用すれば、時間はかかりますが読めます。文学小説と違って、古典的な単語もほとんど出てきませんし、サンプルコードを読めば筆者の主張を汲み取りやすい場合も多いです。とはいえ、一気に読もうとすると疲弊してしまうので、小分けにすると読書を継続しやすいです。

一方、動画は字幕すら出ないので難易度が高いです。 聞き取りやすい英語であればまだ良いですが、講師の人が早口だと秒で心が折れます。「とりあえず、サンプルコード見せてくれ!」ってなります。

オフライン保存に制限がある

オンライン図書館みたいなサービスなので当然といえば当然なのですが、書籍を無制限にダウンロードしておくことはできません。専用のアプリケーションを使っても、無制限なダウンロードはできないようです。

なので、事前にダウンロードしておいてからオフラインで読書することを想定している人は注意が必要です。

まとめ

値段はそこまで安くないですし、英語を読むのは大変ではありますが、オライリーの技術書の読み放題が非常に魅力的なのは事実です。

  • 英語を読むのが苦ではない。
  • 年会費の元が取れるペースで技術書を買っている。
  • 読みたい本の日本語訳を待ちきれない!

これらに当てはまる人は、サブスクリプション契約を検討してみるのがおすすめです。

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

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

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

具体的にやっていること

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

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

実際にやってみた

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

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

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

積分の話をされて困惑している人の様子を書いてみたイラストです。実際の会話だと、" 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の練習にもなるので、これから入門する人はやってみるのがオススメです。