jtk

Nuxt.js をさわってみる

Vue.js と WordPressと使って、SSRできる仕組みということで Nuxt.js を触ってみました。
yuheijotaki/nuxt-study_20190919: Nuxt.js for study 20190919

f:id:jotaki:20190924093802p:plain

導入は基本これ通りです。
Vue CLI使うとすんなり環境構築できますね
Nuxt.js使ってみた - Qiita

sass を使う

index.vueやcomponents配下の.vueファイルでsassを使うには、ふつうのVueと同じで $ npm i -D sass-loader node-sass
をインストールする

_mixin.scss など .scssのグローバルファイルを使う

$ npm run dev をすると触れるようになるのですが、Sassのグローバルファイルを使いたい場合、Nuxt Style Resources というモジュールをインストールして nuxt.config.js に設定情報を記述する。
$ npm i -D @nuxtjs/style-resources
nuxt.config.js

module.exports = {
  // ...
  modules: ['@nuxtjs/style-resources'],
  styleResources: {
    scss: [
      '~/assets/sass/foundation/_variable.scss',
      '~/assets/sass/foundation/_mixin.scss',
      '~/assets/sass/foundation/_common.scss'
    ]
  }
}

これでindex.vueやcomponents配下の.vueファイルで_variable.scssで設定した変数が使えるようになる。
参考: 《Nuxt.js》Sassの共通の変数やmixinを一括で各コンポーネントに読み込む方法。 - Qiita

参考

【読書メモ】正しいものを正しくつくる

正しいものを正しくつくる を読みました。
数ヶ月前にスクラム開発を取り入れたある程度大きな案件に携わったのですが、そもそもアジャイルスクラム開発についての理解が薄かったので最近出た本で評判が良さそうだったのでこの本を選びました。

概要・ポイント

この本のなかの「正しい」という言葉の定義については、

「わかるものをわかるようにする、わかったことを形にする」 「正しいものを正しくつくる」を、「わかったことを正しくつくる」と読み替えて、

あたりが定義されている箇所かなと思います。

  • 第1章 なぜプロダクトづくりがうまくいかないのか → プロダクトづくりの現状
  • 第2章 プロダクトをアジャイルにつくる → アジャイル開発/スクラムとは、イベントについて
  • 第3章 不確実性への適応 → アジャイル開発で出てくる問題点にどう対応すべきか
  • 第4章 アジャイル開発は2度失敗する → プロダクトオーナーが自身やチームとどう関わるか
  • 第5章 仮説検証型アジャイル開発 → 検証活動について
  • 第6章 ともにつくる → まとめ

現在の私たちが作ろうとしているプロダクトとは、「どうあるべきか本当のところが誰にもわからないが、なんとかして形に仕立てていく」

と書かれている通り、その前提がどのように生まれてどのようにそれぞれの立場や役割で関わったり向き合うべきか、もしくは周囲の状況(ユーザーやニーズ)の多様化など、不確実性の高いプロダクトづくりにどう向き合うべきかのような内容が主かなと思います。

良かった点

  • アジャイル開発、スクラム開発について一連のフローやイベントの目的が分かった
  • スクラムマスター、プロダクトオーナーがどのような視点(視座/視野)で仕事をするのか(するべきなのか)がなんとなく分かった
  • 現在の開発スタイルへの考え方のトレンドというか流れと、今後どのように開発者がプロジェクトに携わるようになるかが分かった

惜しかった点

  • 仮説検証段階の話は、自分の今の立ち位置だとピンとくる話が少なかった。けど、それも含めて越境していくことなんだと思う。

まとめ

開発手法についてのこういう類の本ははじめて読んだのですが、会話などの直接コミュニケーションも大事にすることは意外でした。 アジャイルソフトウェア開発宣言 というのがあるのですが、そこにも

プロセスやツールよりも個人と対話を、 とあるので開発手法っていうのが上辺だけの開発にまつわる決まりと勘違いしていました。

プロジェクトに関わる人が多い案件はやってこなかったので、今の会社はそれができる体制が整っているので今だから勉强できること、という感じで新しい学びが得られるように今後もしたいなと思います。

2019年8月 振り返り

結果

ブログ

目標:月 12 回(週 3 回)更新
結果:月 7 回 更新

読書

目標:月 1 冊
結果:月 2 冊

反省点など

読書やVueのクイズを一旦完成までもっていけたが、ブログの更新数がまた達成できず

来月に向けて

来月も忙しそうだが細かめの内容でもメモしてアップする習慣をつける  
Vueで新しくなにかを作る

Backlogでの課題管理など

最近案件でBacklogを使っていて、課題管理など自分なりにやりやすい方法をみつけたのでまとめてみます。

f:id:jotaki:20190827101916p:plain

ルール決め(ざっくりとでも)

最初に構想をもつ。
下記に挙げるようなフローにおいて、

  • どのタイミングで起票するか
  • どのくらいの粒度で課題を立てるか
  • だれに担当者の割り振りを行うか
  • いつどのようなときにステータスを変更するか
  • だれにとっての完了か
  • なにWikiに記載するか

上記はプロジェクトごとに、どのようなプロジェクトか、誰と共有するプロジェクトか、いつまでのプロジェクトかでも変わるので毎回変わる。
また運用していく中でもこっちの方が分かりやすいねといった感じで変わっていくが、あらかじめ枠組みないと各自のルールで進めてしまい課題に対しての捉え方(特にステータス変更)がバラバラになってしまう気がする。

起票タイミング

何か課題となること(タスクとなること)を見込みを含めて起こりそうになったタイミングですぐに起票する。
起票しないと忘れてしまうし、仮にタスクがなしになったときも完了理由を「対応しない」で課題完了すればOK。

課題の粒度

基本的には細かければ細かいほうがやりやすい。
大きな粒度だと、例えばその中でタスクが10個ある状態だと9個完了してても残りの1個がまだで課題完了ができない。→ 一覧で見たときに進捗含め可視化しづらい。

課題詳細

コメントには重要な情報を置きっぱなしにせずに、こちらに不変の情報(仕様や修正内容)を記載する。
各課題はコメントの着信ベースで閲覧されるが、課題の本来の目的に立ち返るときに参照できるものに随時アップデートしておく。
何個かタスクが入った場合はチェックボックスを使う必要があるが、本来確認事項のメモなどに使う用途のような気がするのでやはり課題自体の粒度を細かめにするのがよさそう。

ステータス

どのタイミングで各ステータスに変更するか、共通認識をもっておくことが大事。
特に「完了」課題は一覧でフィルターかからないのがデフォルトのため、基本的には誰にも見られない課題になってしまい注意が必要そう。

担当者

基本的には未設定にしない。だれがボール持っているかをはっきりさせる。

コメント、コメントのお知らせ

誰に言っているのかをはっきりさせる。(@でメンションつけれればいいなと、自動的にお知らせも届く)
お知らせはcc的な意味合い込めて関わる人にはつける。

種別とマイルストーン

あんまりきちんと使えてないんですけど、課題フィルターするときとかつけておくと便利だなーと思います。

ガントチャート

こちらは全然使えてないです。

Wiki

こういうBacklogルール含めルールなどをHomeはインデックスつけておいておく。


こんな感じでしょうか。
とにかく忘れるのが怖い(自分の記憶に自信がない)ので、管理のための管理にはならないようにツールに頼りたいと思います。

↑とは関係ないですが、最近読んだBacklogのアクセシビリティ改善の話
https://speakerdeck.com/nulabinc/actions-for-improving-accessibility-in-backlog-ja11yc

vue-quiz の Tips

f:id:jotaki:20190212100544p:plain

vue-quiz を作った際にでてきたTipsをまとめておきます

同じID(値)を持った配列をまとめたい

今回の場合、ラジオボタン式(単一解答)なら問題ないけど、チェックボックス式(複数解答)のときに整形する必要がでてきた
つまり

array = [
  { id: "1", answer: "d" },
  { id: "3", answer: "a" },
  { id: "3", answer: "b" },
  { id: "3", answer: "c" },
  { id: "4", answer: "b" }
]

を↓のようにしたい

formatArray = [
  { id: "1", answer: ["d"] },
  { id: "3", answer: ["a","b","c"] }
  { id: "4", answer: ["b"] }
]

こういうときに reduce() を使うみたい

const data = array.reduce((acc, value) => {
  acc[value.id] = acc[value.id] ? acc[value.id] : [];
  acc[value.id] ? acc[value.id].push(value.answer) : [value.answer];
  return acc;
}, {});
let formattedAnswerArray = Object.entries(data).map(d => ({ id: d[0], answer: d[1] }) );

参考: https://stackoverflow.com/questions/31688459/group-array-items-using-object

配列の比較

これも参考のとおりなのですが、配列を比較、今回の場合は答え合わせの際に、問題の正解とユーザーの解答を比べるときに使いました。

function array_equal(a, b) {
  if (!Array.isArray(a))    return false;
  if (!Array.isArray(b))    return false;
  if (a.length != b.length) return false;
  for (var i = 0, n = a.length; i < n; ++i) {
    if (a[i] !== b[i]) return false;
  }
  return true;
}

というfunctionを作って computed

// スコアの計算
calcScore: function () {
  const correctAnswer = this.correctAnswerArray; // 問題の正解
  const userAnswer = this.userAnswerArray;       // ユーザーの解答
  let userScore = 0;
  correctAnswer.forEach((value,index) => {
    const correctAnswerValue = value;
    const userAnswerValue = userAnswer[index];
    // ユーザーの解答が問題の正解とイコールならスコアを+1する
    if ( array_equal(correctAnswerValue,userAnswerValue) ) {
      userScore ++;
    }
  });
  return userScore;
}
<template>
...
  <p>{{calcScore}}問正解です</p>
...
</template>

参考: https://marycore.jp/prog/js/array-equal/

<template> を使って条件分岐

直接HTMLタグに分岐を書かずに <template> に分岐を書く。
あらかじめどちらに統一すると決めてマークアップしていったほうがいいですね。
answerCorrect() メソッドで分岐する場合

<div>
  <template v-if="answerCorrect(hoge,fuga)">
    <p class="text text--correct">{{ value }}</p>
  </template>
  <template v-else>
    <p class="text">{{ value }}</p>
  </template>
</div>

カスタムデータ属性(data-*)をバインドする

<input
  type="checkbox"
  v-bind:data-hoge="post.id"
  >

Vue.js でクイズをつくる

f:id:jotaki:20190212100544p:plain

結構前からやってたような気がするクイズの実装一旦できたので内容まとめようと思います。

GitHub Pages: https://yuheijotaki.github.io/vue-quiz/
GitHub: https://github.com/yuheijotaki/vue-quiz

機能

  • JSONから設問情報(設問テキスト/選択肢/解答など)を取得して描画
  • 回答形式は単数(ラジオボタン)と複数(チェックボックス
  • 答え合わせボタンでスコアと解答を表示

設問のJSON

READMEにも書きましたがこんな感じで調整しながら落ち着きました

[
  {
    "id": 1,                // [Number] question ID
    "queText": "text",      // [String] question text
    "ansType": "single",    // "single" or "multi"
    "ansCorrect": ["A"],    // [Array(String)] correct answer. If 'ansType' is "multi", specify like ["A","B"]
    "ansChoice": {          // [String] choice answer text
      "A": "answer A",
      "B": "answer B",
      "C": "answer C",
      "D": "answer D"
    },
    "ansCommentary": "text" // [String] answer commentary using HTML tags
  },
  {
    "id": 2,
    ...
  }
  ...
]

ハマったこと

いろいろあった気がしますが、コンポーネントの構成はあらかじめ紙に書いて進めても後で設計し直しがありました。

また設問の描画(components/Question.vue)、解答データの取得(components/Answer.vue)で一覧取得するのに同じメソッド使ってたりするのですが、うまくまとめたりできるんだろうなと思いつつ書き方わかんないなーと思って冗長なところが多々ある気がします。

残り課題

  • リセットボタン(ページ最下部)の追加。全回答リセット機能がほしい
  • 線 or 円形のプログレスバーの追加。回答状況の進捗を確かめられる要素を入れると親切な気がする
  • LocalStorage で質問リストの解答を保存。リロードで一瞬で消えてしまうので
  • 複数時 質問リスト 選択肢上限(jQueryチェックボックス不具合(前選択していた上限が引き継がれてしまう)
  • (そもそも)設問1問ずつでページ遷移する形のほうがよい?

とかですかね。基本の回答 → 答え合わせはできたのですが細かい所でちょくちょく改善したい点はあります。

これから

CLI使うとき、ビルドインにするとき、Router 使うときなどいろいろな導入の方法あると何がベストなのかが実際に触っている段階でも分からないので触れる機会を増やさなきゃなぁと思います。
SPAから逃げてきたので次回はページ遷移する要件もった何かを作りたいと思います。

【読書メモ】はじめてのUIデザイン

はじめてのUIデザイン を読みました。

サイトに書かれていますが対象読者は、

  • UIデザインについて知りたい、勉強したい人
  • UIデザインの経験はあるが、基本から再入門したい人
  • 開発しているアプリ、サービスのUIデザインをしたいエンジニア
  • UIデザインを理解したいディレクター

ということで自分はUIデザインするわけではないですが、著者の人の感じから最近の動向なども込み込みで理解できるのでは、と思って手に取りました。

f:id:jotaki:20190815083838p:plain

PEAKS というクラウドファンディングで技術本を出版しているレーベルから出ているもので、サイトからPDF or 物理本を購入する形です。自分は物理本にしました。

概要

PC/アプリをはじめとしたオンスクリーンデザインの歴史(iPhone登場の2007年あたりから)、領域で活動するにあたり関わることの多いメンバーの役職の説明などベーシックな内容からはじまります。
次にUIコンポーネントといわれるもののひとつひとつの説明、情報設計について、アプリ/Webそれぞれのデザイン手法についてが続きます。
5章でサンプルの題材をもとに実際にUIデザインに落とし込む流れの解説、その後UX的な話、最後はサービス全体に目を配るといった広いデザインについて書かれています。

ポイント

気になったコンポーネントやツールの紹介などはキリがないので印象に残ったところだけ

5-5 「UIデザイン」の意味を改めて考える

UIは「ユーザーインターフェース」の略ですが、あなたが作ったUIデザインはまだユーザーに使われていないはずです。そうです。ツール上でUIを作っただけでは、それは「インターフェイスデザイン」であって「ユーザーインターフェースデザイン」ではないのです。
...
UIを作るまでのフェーズ、情報設計のさらにその前には「そもそもなぜサービスを作るのか」「そのサービスは誰のために作るのか」「その『誰か』は存在していて、サービスを使いたいと思うのか」といった視点があるはずです。UIを作った後のフェーズは「作ったUIは本当に使われるのか」「作ったUIをどう改善していくのか」といった視点です。

7-1 サービスをつくる

何のためにサービスを作るのか
サービスは企業が売上や企業価値を上げるために作ります。ユーザーに価値を与えた結果、利益を生み出す製品を作るのがデザインです。

本当は人や目的によってそれぞれでもいいのかもですが、この本で扱うデザインの定義に関してはこうですよって感じでしょうか。

良かった点

  • UIデザインの基礎的なレベルの考え方、手法、運用、ツールなど広い知識が得られた
  • 最近のデザイナーが利用しているツールの紹介があったので、ある程度スタンダードが分かった気がする(Sketch / Figma / Sketch は仕事で使っているか認知はしているが Abstract などは知らなかったので)
  • 資料や紹介されるツールが新しいものであること
  • 関連資料(Webのページや書籍情報)が豊富でQRコードつきでアクセスしやすいこと

惜しかった点

  • 物理本は2章の一部分しかカラーでなかった(PDF版はオールカラーなのかな)

まとめ

自分がデザインしていたのは7〜8年くらい前なので、単純に今求められることは領域が広がったなあと思いました。
でも広がったというより当時の自分が気づいていないだけで、ポイントにあげたようなことに関して目が向いていなかっただけなのかも知れません。
エンジニアとうまく連携するのも、レイヤー(コンポーネント)の命名規則を考えたりするのもデザイナーのスキル(価値)になって大変だなと..

でもデザイナーとエンジニアも同じ目線で、作りやすさではなくユーザーや未来に目を向けることは同じ部分もたくさんあるなと思って勉強になりました。