2018-10-21

Gulp - v4 の series と parallel を使って直列・並列処理を制御する

f:id:azuuun:20181021234214p:plain

Gulp v4 で導入された series と parallel を使ってみました。

動作環境

$ node -v
v8.12.0
$ npm -v
6.4.1
$ ./node_modules/.bin/gulp -v
CLI version 2.0.1
Local version 4.0.0

series の使い方

series は直列（同期的とも言える）に処理を順次実行します。今回は、js ファイルのコンパイル等を行う scripts タスクと sass ファイルのコンパイルを行うstyles タスクを順次実行して動作を確かめます。

const gulp = require('gulp');

gulp.task('scripts', () => {
    return gulp.src('./src/scripts/*.js')
        .pipe(...)
        .pipe(gulp.dest('./dist/assets/js'));
});

gulp.task('styles', () => {
    return gulp.src('./src/styles/*.css')
        .pipe(...)
        .pipe(gulp.dest('./dist/assets/css'));
});

gulp.task('series',
    gulp.series(
        'scripts',
        'styles'   
    )
);

これを実行します。

$ ./node_modules/.bin/gulp series
[22:21:11] Using gulpfile ~/programming/.../gulpfile.js
[22:21:11] Starting 'series'...
[22:21:11] Starting 'scripts'...
[22:21:11] Finished 'scripts' after 357 ms
[22:21:11] Starting 'styles'...
[22:21:15] Finished 'styles' after 3.25 s
[22:21:15] Finished 'series' after 3.61 s

scripts タスクの完了を待ってから styles タスクが開始されていますね。

parallel の使い方

parallel は並列（非同期的とも言える）に処理を実行します。先程の scripts タスクは結果を styles タスクで利用しているわけではないので、実は並列で実行してしまってもよい処理でした。なので、この2つを parallel に置き換えます。

const gulp = require('gulp');

gulp.task('scripts', () => {
    return gulp.src('./src/scripts/*.js')
        .pipe(...)
        .pipe(gulp.dest('./dist/assets/js'));
});

gulp.task('styles', () => {
    return gulp.src('./src/styles/*.css')
        .pipe(...)
        .pipe(gulp.dest('./dist/assets/css'));
});

gulp.task('series',
    gulp.series(
        'scripts',
        'styles'   
    )
);

これを実行します。

$ ./node_modules/.bin/gulp parallel
[22:26:54] Using gulpfile ~/programming/.../gulpfile.js
[22:26:54] Starting 'parallel'...
[22:26:54] Starting 'scripts'...
[22:26:54] Starting 'styles'...
[22:26:57] Finished 'scripts' after 2.7 s
[22:26:57] Finished 'styles' after 2.86 s
[22:26:57] Finished 'parallel' after 2.86 s

parallel タスクの実行と同時に scripts タスクと styles タスクが並列で Starting していますね。並列なので、全体の処理速度も先程の series の処理時間 3.61 s と比較して parralel は 0.75 s 速いです。

series と parallels を併用してみる

最近、自分が実際に実装した中で series と parallels を併用したパターンを例に取ってみます。

例えば、ビルド作業の前処理と後処理が必要な場合、これらは必ずビルドの最初と最後に実行したいので直列的に扱いたいです。一方でビルド作業自体で実行される各ビルドタスクはそれぞれ独立した処理を行うため並列的に実行しても問題ないという場合があります。

図示したものが以下です。

f:id:azuuun:20181021231358p:plain

処理の流れを通明すると、

build タスクが開始
前処理として clean タスクを実行する
cleanタスクが完了するのと同時に、scripts、styles、html タスクなどが並列で実行する
それら並列で実行されたタスクがすべて終了したあと、後処理である zip タスクを実行する
build タスクが終了

並列の処理はなるべく parallel でまとめて実行してあげることによって、タスク全体の処理速度の向上が期待できます。

具体的なコードは以下です。

上記コードを実行すると、

$ ./node_modules/.bin/gulp build
[23:30:04] Using gulpfile ~/programming/.../gulpfile.js
[23:30:04] Starting 'build'...
[23:30:04] Starting 'clean'...
[23:30:04] Finished 'clean' after 54 ms
[23:30:04] Starting 'scripts'...
[23:30:04] Starting 'styles'...
[23:30:04] Starting 'html'...
[23:30:04] Starting 'fonts'...
[23:30:04] Starting 'images'...
[23:30:04] Starting 'vendors'...
[23:30:04] Starting 'manifest'...
[23:30:06] Finished 'manifest' after 2.62 s
[23:30:06] Finished 'html' after 2.69 s
[23:30:07] Finished 'vendors' after 2.84 s
[23:30:07] Finished 'scripts' after 2.92 s
[23:30:07] gulp-imagemin: Minified 5 images (saved 2.91 kB - 23.9%)
[23:30:07] Finished 'fonts' after 3.36 s
[23:30:07] Finished 'images' after 3.36 s
[23:30:07] Finished 'styles' after 3.55 s
[23:30:07] Starting 'zip'...
[23:30:07] Finished 'zip' after 99 ms
[23:30:07] Finished 'build' after 3.71 s

clean タスクが Finished するのと同時に各種ビルドタスクが一斉に Starting しており、すべてのビルドタスクが終了したタイミング（今回であれば stylesが一番最後に Finished している）で後処理である zip タスクが走っています。

以上です。

参考

gulpjs.org

2018-10-08

デザイン組織のつくりかたを読んだ

デザイン備忘録

きょうはデザイン組織のつくりかたという本を読みました。

デザイン組織のつくりかた　デザイン思考を駆動させるインハウスチームの構築＆運用ガイド

作者: ピーター・メルホルツ,クリスティン・スキナー,長谷川敦士,安藤貴子
出版社/メーカー: ビー・エヌ・エヌ新社
発売日: 2017/12/22
メディア: 単行本（ソフトカバー）
この商品を含むブログ (2件) を見る

この本を読むきっかけは、とある記事の一文でした。

どうしてデザインが大切なのか、ここ最近デザインが盛り上がっている歴史的背景を一通り話して、「あーやっぱりデザインって大事だね！」って思ってもらうまでにまずひと苦労。（中略）だんだんめんどくさくなってきたんですよね…　もうめんどくさいから、そういう説明するのはやめることにしました。この本に委ねます。

「デザイン組織のつくりかた」がめっちゃ良かったので、100冊ぐらい配ってみようかと思う | TECHNICAL CREATOR

昨今の「デザイン大事だよね」という流れの歴史的経緯を学んでいきたいというモチベーションで購入し、しばらく積読となっていました。

一通り読んでみて、いくつか学びになったところを備忘録として残しておきたいと思います。デザイン組織の構築の部分より前の、デザイン組織が必要になってきた経緯が中心です。自分なりの言い回しでメモしているため、原著との解釈が異なる部分があります。

コンシューマライゼーションの波

何十年ものあいだソフトウェアは Microsoft、Oracle、Adobe といった会社が作る製品だったのが、インターネットの急速な普及によって、大きく変化してきた。業種に関わらず、業務の中心にソフトウェアが存在し、インフラとなり、程度の差はあってもすべての会社はソフトウェア会社になりつつある。

ソフトウェアは性質上抽象的なものであり、ほとんどの人にとってその抽象性を理解することは容易くない。そのため、ソフトウェアの分野では「ヒューマン・コンピュータ・インタラクション」「インタラクションデザイン」「インターフェースデザイン」「ユーザビリティ」といったデザインに対して、相対的に多くの投資が行われている。

単純に作られているソフトウェアの数が増えているだけでなく、高いレベルの性能を要求される。「高いレベル」という曖昧な表現だが、ただ要求にこたえられる「すべての機能の全部盛り」ではもはや不十分である。ソフトウェアの分野はそれくらいに成熟したフェーズにあり、他社と横並びに機能するサービスを提供すれば戦略的にまずまずだった時代は終わり、体験価値の点でも競争していく段階に来た。業務や作業に使うソフトウェアの数が増えていくにつれ、ユーザーの知識も高度化し、効率的に機能するソフトウェアは評価されても、そうでないものはそもそも見向きもされなった。

そういう傾向は長い間、消費者向け（toC）の製品に限られたものだった。というのは、何を買う・使うかは個人がそれぞれに選ぶ立場にあったからだ。一方でエンタープライズ系のソフトウェアはデザインがずっとひどいものだった。というのにもいくつか理由がある。

購入者が必ずしもユーザーではなかった
ユーザーに選択肢がなかった
デザインのひどさはトレーニングによって克服できると信じられていた
仕事は面白くて楽しいものであってはならないからソフトウェアにもその堅苦しさを反映すべきという空気

しかし、今のエンタプライズ系ソフトウェア市場は進化しており、企業は”ひどいデザイン”のソフトウェアを使うことで生産性の足を引っ張ると悟った。エンタープライズ系ソフトウェア会社は、デザインがお粗末だと顧客を失いかねないことに気づいた。高度な知識を持つようになったユーザーは”ひどいデザイン”を我慢することを嫌うようになった。

そして、子供の頃からデジタルテクノロジーに浸かってきたミレニアル世代が社会人になってきてから、ITのコンシューマライゼーションが加速している。

Everything-as-a-Service

これまでソフトウェアは、プロダクト、つまり製品だと考えられてきた。完成すると、箱に入れてパッケージ化され販売されるか機械に直接インストールされる。しかし、常時ネットワークに接続されるようになってからの世界では、ソフトウェアが完成することはなく、より最適化され、より強化され、デプロイされ続ける。

そうした変化から、今では顧客がソフトウェアそのものを手に入れることはなくなり、そのライセンスへのアクセス権を購入するサブスクリプションモデルによって収益を生み出すのが当たり前になってきた。修正され続けるソフトウェアの性質が、売り手と買い手の関係性を変えた。両者の関係が継続的なものになってから、すべての会社はソフトウェア会社であるのと同時にサービス会社になりつつある。

まだ、サービス会社になることができていないソフトウェア会社は、顧客をどう捉えて、どうやり取りするかを根本的に再考する必要さえある。今は、製品を使うために顧客はアカウントを発行し、その行動は細かく追跡されている。企業には、顧客のことをよく知り、ソフトウェアを修正し、サービスを提供し続ける責任がある。

ユーザーエンパワーメントという諸刃の剣

ただ「サービスを提供する」会社を目指せばいいわけでもない。これまでになく現状は複雑化している。1990年代半ばまでは、企業に連絡するツールは電話や FAX、または郵送を使って直接働きかけた。その後、Web や E-mail が登場し、やがてオンラインチャットやソーシャルメディア、モバイルアプリが加わり、デジタル上での顧客とのタッチポイントが爆発的に増えた。

インターネットにつながったソフトウェアはコミュニケーションだけにとどまらない。インターネットが普及する以前は、銀行であれば、ソフトウェアは主に訓練された専門の銀行員によって使用される社内ツールだった。顧客が直接アクセスできるのは ATM やテレフォンバンキングくらいで、それらでできることは基本的なものに限られていた。デスクトップから Web へのアクセスが可能になると、銀行はかつて社内システムとして公開していた機能を顧客に提供するようになった。

こうした複雑なシステムを顧客は喜んで利用した。自分で直接管理できることを高く評価した。一方の銀行も人件費の削減に役立つため、それを促進した。

だが、社内の訓練された専門の銀行員（ユーザー）は一日に何時間もそうしたツールを利用するのに対して、一般のユーザーの場合は一週間、あるいは数ヶ月の数分のために利用する可能性が高い。専門家以外の比較的使用頻度の低いユーザーに分かりやすいものを作るには、根本からじっくりと考え直す必要が出てくる。

そして、競合するソフトウェアと機能が横並びである以上、ユーザーエクスペリエンス（UX）も顧客がサービスを選ぶ際の理由になる。

複雑さと単純さという正反対の性質を抱えないといけない矛盾は、携帯電話の登場でますます深刻化した。アクセスポイントを一つ増やすと、その分だけ複雑さは増す。だが、モバイルデバイスには画面の小ささや処理能力の低さなどの制約がある。その範囲内でデザインするにはさらなる合理化と単純化が必要になる。

デザインのポテンシャル

ソフトウェアによってビジネスはより一層複雑さを増した。それに対処するために、企業はデザインに投資する。一方で、デザインを企業に導入する責任を負うほとんどの人はデザインが持つ力について初歩的な理解しかない。デザインを主に美的価値を高め、スタイルや外見をよくするものだと認識している。

ジョブズの有名な言葉に以下のものがある。

ほとんどの人はデザインを見た目のことだと思っているが、それは間違いだ。デザインをうわべだけのことだと勘違いしている。デザイナーには箱を渡して、「見た目をよくしてくれ！」と言えばいいのだと。私たちは、デザインとはそういうものではないと考える。どのように見えるか、どのように感じるかではない。デザインはどのように機能するかなのだ。

プロダクトデザインのコンサル会社 Ammunition の設立者のロバート氏は、「デザインはプロセスだ。イベントではない。」と語り、最近までデザインは一つの流れの中での一つのステップだとみなされてきたという。

f:id:azuuun:20181008203733p:plain

彼は、図.1 のようにデザインは単独で存在しうるものではなく、図.2 のように製品開発のライフサイクル全体に取り入れてこそ、最大の効果が発揮されるプロセスであると主張している。

f:id:azuuun:20181008203942p:plain

すべてのデザインはサービスデザイン

「サービスデザイン」という新しい領域は、企業によるデザインの活用方法をリフレーミングする。これまでのデザインは作ることに焦点を当てるよう求められてきた。サービスデザインも本質は変わらないものの、視点はもっと高く、広いものであり、作られた成果物自体を重視するより、ステークホルダーとそれらと関わるすべての活動の関係性を理解しようとする。

作られた成果物は独立した存在ではなく、より大きなサービス・エコシステムのなかの一つのツールに過ぎないと考える。

さいごに

この記事は、本書籍の導入部のみの備忘録です。この後、書籍では「組織に広く貢献するデザインの力」へと解説が続きます。私が所属する会社もエンタープライズ系のソフトウェア会社の一つで、実際にデザイングループが存在し、日々製品／サービスの顧客体験を考え、提供し続けています。そういった背景があり、本書を読むことで組織の中でのデザイングループの位置付けや重要性を改めて学ぶことができたように思いますし、ITエンジニアの立場からも積極的にデザインに関わっていきたいと感じています。

以上です。

2018-09-19

fish - Macのシェル環境を新しくした

備忘録日記

f:id:azuuun:20180919233241p:plain

これまでシェルにそこまでこだわりがなかったのですが、身の回りの方々を見ていると、かっこいい・便利な感じにカスタマイズしている人が多く、「おっ、良さそうだな」と思ったのでシェル環境を一新しました。

どのシェルを選ぶか

個人的な見解として、「死ぬほど時間かけてシェルの到達点を目指す」ならzsh、「設定ファイル書きたくないけどそれなりに便利に使いたい」ならfish、「Pythonで全部CLIやりたい」ならxonsh、「emacs lisp使ってる人」はらeshellって漢字で、もうbash選ぶ理由はほぼないと思ってる
— えぬなお☁nnao45 (@nnao45) 2018年9月11日

fish にします。

導入手順

Homebrew を使って導入します。

$ brew install fish
$ fish -v
fish, version 2.7.1

ログインシェル（デフォルトで立ち上がるシェル）を bash から fish に変更します。

$ sudo vi /etc/shells

# 末尾に以下を追加
/usr/local/bin/fish

保存した後、以下を実行します。

# ログインシェルを fish に変更
$ fish
> chsh -s /usr/local/bin/fish

これで、次シェルを立ち上げたときも fish になります

パッケージマネージャー fisher を導入する

github.com

> curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs https://git.io/fisher
> fisher -v
fisher version 3.1.1 ~/.config/fish/functions/fisher.fish

個人的にとりあえず以下の2つを入れてみて便利でした

jethrokuan/z
- ~> z 移動したいディレクトリ名 で移動できる
jethrokuan/fzf
- ディレクトリ検索やコマンド履歴検索が強力

環境変数とPATHの設定

fish の環境変数の設定ではexport AWS_ACCESS_KEY_ID=HOGE1234 というような見慣れた記法が使えません。

ターミナルに直接以下のようにsetを叩くか、~/.config/fish/config.fishに以下を追記します。-xは環境変数としてsetするオプションで、これがないとシェル変数として定義されます。

> set -gx AWS_ACCESS_KEY_ID HOGE1234

PATH は以下のように設定します。コロンで区切るのではなく、配列で管理されています。

> set -gx PATH $HOME/.rbenv/bin /usr/local/var/pyenv $PATH

テーマを変更する

github.com

結構、いろいろあります。今回は、oceanを入れてみます。 fisher add oh-my-fish/theme-{color-theme-name}で導入できます。

> fisher add oh-my-fish/theme-ocean
Installing 1 plugin/s
OK Fetch ocean github.com/oh-my-fish/theme-ocean
Done in 1s 558ms

フォントによっては、アイコンが Apple Emoji になったりしますが、以下のような powerline 対応のフォントを導入すると良さそうです。

fonts/Meslo LG L Regular for Powerline.ttf at master · powerline/fonts · GitHub

iTerm2 を設定する

以下から設定を選ぶか、お好みのものをインポートします。

iTerm2 > Preferences > Colors > Color Presets...

f:id:azuuun:20181116192659p:plain

自分が Ocean と合わせて使っているカラーセットは以下です。よければ、ダウンロードして使ってください。

自分のiTerm2の設定（oh-my-fish/oceanと併用）

さいごに

乗り換えてみて、とても便利ですし、いい意味で”驚きが少ない”（予想に反する挙動がない）です。また何かカスタマイズしたときに、追記したいと思います。

以上です。

参考

2018-09-17

UIが消えて何もしなくてよくなっていく

日記

最近読んだ２つの記事がつながって、「なるほど」と腑に落ちた。

サービス開発において「ユーザーがしたいことをできるようにさせてあげる」という議論は活発だが、いっぽうで「しなくていいことをしないようにさせてあげる」分野はまだまだ発展途上だと思う。（中略）システムで吸収してあげれば、人間がしなくていいことはまだまだある。

しなくていいUX｜小山田翔子 / GMOペパボ｜note

つまり・・・

UIとかUXとか、サイコーな状態になると、使ってる側はまったくその存在を気にしなくなるのだ。

UIがサイコーになるとUIは消える｜米光一成｜note

サイコーな状態のUXは、「しなくていいことをしないようにさせてあげる」分野が発展していくと、徐々に増えていく。ユーザーが「しないようにさせてあげられる」システムを作れるようになりたい。

引用した記事

note.mu

2018-09-17

デザイン - 信頼感を持たせる色・透明感のあるデザイン

今回は、「信頼感を持たせる配色」「透明感がある配色」に着目して、カラーコードと色見本を見ていきます。

信頼感が生まれる配色

f:id:azuuun:20180917222830p:plain

一般的に、信頼・冷静といった印象を与える色は青系、安心感を与えるのは緑系の色だと言われています。

色の数を少なくナチュラルな印象

f:id:azuuun:20180917222954p:plain

冷静な印象を与える

f:id:azuuun:20180917223032p:plain

意欲的な赤色を添える

f:id:azuuun:20180917223058p:plain

緑をメインに安定感を与える

f:id:azuuun:20180917223124p:plain

参考

Webデザイン良質見本帳目的別に探せて、すぐに使えるアイデア集

作者: 久保田涼子
出版社/メーカー: SBクリエイティブ
発売日: 2017/06/16
メディア: 単行本
この商品を含むブログを見る

2018-09-17

デザイン - 色の持つイメージ

UIデザイン備忘録

色について

色というのは、人によって違ったイメージを持つもので、その人の経験や住んでいる国、その土地にある文化によって変化する。色によるイメージをポジティブ・ネガティブの２つの視点からまとめ、それに適した領域を以下に示す。

赤

f:id:azuuun:20180917190404p:plain