CSS Gridって本当に便利だなぁと思う今日この頃ですが、そのなかでも特に注目しているのがrepeat()とminmax()です。この2つのCSS関数を使うとグリッドレイアウトの構築が楽になるだけでなく、CSS Gridだけでメディアクエリなしでもレスポンシブなレイアウトが実現できます。

今回はそのrepeat()で使えるauto-fillとauto-fitという値について。ちょっと違いが分かりづらいのでメモっておきたいと思います。

auto-fillとauto-fitの違い

auto-fillとauto-fitの違いは実装例を見るのが一番わかりやすいので、まずはデモをご覧ください。repeat()とauto-fill、auto-fit、minmax()を使ったデモです。

デモはこちら

デモページをブラウザで開いてウィンドウ幅を変えてみてください（CSS Gridがサポートされているブラウザはこちら ）。なんとなく違いがわかったでしょうか？

下のGIFアニメのようになるはずです。

• auto-fillでは、親要素にスペースが余る場合、空のグリッドが作られます
• auto-fitでは、親要素にスペースが余る場合、グリッド・アイテムの幅が変わってスペースが埋められます

ざっくり言ってしまうと、これら2つの違いはそんな感じなんですが、なぜこのようになっているのか、もう少し詳しく見て行きましょう。該当する部分のCSSとHTMLは以下のとおりです。

CSS

.grid-auto-fill,
.grid-auto-fit {
  display: grid;
  border: 1px solid #ddd;
  grid-auto-rows: 5em;
  grid-gap: 10px;
  padding: 10px;
  margin: 1em 0 2em;
  overflow: hidden;
}

.grid-auto-fill {
  grid-template-columns: repeat(auto-fill, minmax(100px, 1fr));
}

.grid-auto-fit {
  grid-template-columns: repeat(auto-fit, minmax(100px, 1fr));
}

.grid-auto-fill > div,
.grid-auto-fit > div {
  padding: 10px;
  background: #ddd;
}

.grid-auto-fillと.grid-auto-fitの違いは、repeat()のauto-fillとauto-fitの記述だけです。他はまったく同じです。

HTML

<h3>auto-fill</h3>
<div class="grid-auto-fill">
  <div>Item 1</div>
  <div>Item 2</div>
  <div>Item 3</div>
  <div>Item 4</div>
</div>
<h3>auto-fit</h3>
<div class="grid-auto-fit">
  <div>Item 1</div>
  <div>Item 2</div>
  <div>Item 3</div>
  <div>Item 4</div>
</div>

.grid-auto-fillがauto-fill、.grid-auto-fitがauto-fitのグリッド・コンテナ（親要素）になります。グリッド・コンテナにはminmax()で指定した最小幅が100px、最大幅が1fr（フラクション）を指定した4つのグリッド・アイテムを入れています。

さて、ここからはCSSの記述を詳しく見て行きます。まずはrepeat()について。

CSS Gridのrepeat()とは

CSS Gridでrepeat()関数を使うと、グリッドの繰り返しの指定ができます。たとえば、以下を指定すると

grid-template-columns: repeat(2, 100px 1fr);

以下の記述と同じになります。

grid-template-columns: 100px 1fr 100px 1fr;

便利ですね。

次にrepeat()で使えるauto-fillとauto-fitについて説明します。これら2つはminmax()関数と一緒に使うと挙動に違いがでるので、組み合わせで使用する際の説明をします。

念のため仕様を確認してみる

デモを見ればこれらの挙動は一目瞭然なんですが、念のため仕様ではどのように説明されているのか確認しておきます。

• CSS Grid Layout Module Level 1の仕様のauto-fillとauto-fitの説明部分（英語）

仕様ではauto-fillとauto-fitについて以下のように書かれています。

auto-fillの仕様

When auto-fill is given as the repetition number, if the grid container has a definite size or max size in the relevant axis, then the number of repetitions is the largest possible positive integer that does not cause the grid to overflow its grid container (treating each track as its max track sizing function if that is definite or as its minimum track sizing function otherwise, and taking gap into account); if any number of repetitions would overflow, then 1 repetition. Otherwise, if the grid container has a definite min size in the relevant axis, the number of repetitions is the smallest possible positive integer that fulfills that minimum requirement. Otherwise, the specified track list repeats only once.

– CSS Grid Layout Module Level 1: Repeat-to-fill: auto-fill and auto-fit repetitions

意訳してみます。

繰り返しの数値にauto-fillを指定すると、グリッド・コンテナの幅が当該の軸に向かって定数サイズか最大サイズの場合、繰り返し回数はグリッドがコンテナからはみ出ない最大の回数になる（それぞれのトラックを、それが定数の場合は最大サイズの機能として、それ以外の場合は最小サイズの機能として扱う。その際、ギャップも勘案する）。どの数値でもコンテナをはみ出てしまう場合は繰り返しは1回になる。また、グリッド・コンテナの幅が当該の軸に向かって定数の最小サイズの場合、繰り返しの回数は最低要件を満たす最小の整数になる。そうでなければ指定のトラック・リストは1回のみ繰り返す。

auto-fitの仕様

The auto-fit keyword behaves the same as auto-fill, except that after grid item placement any empty repeated tracks are collapsed. An empty track is one with no in-flow grid items placed into or spanning across it. (This can result in all tracks being collapsed, if they’re all empty.)

A collapsed track is treated as having a fixed track sizing function of 0px, and the gutters on either side of it—including any space allotted through distributed alignment—collapse.

– CSS Grid Layout Module Level 1: Repeat-to-fill: auto-fill and auto-fit repetitions

こちらも、意訳してみます。

auto-fitもauto-fillと同じように振る舞います。ただし、グリッド・アイテムが置かれた後、繰り返された空のトラックは崩されます。空のトラックはインフローのグリッド・アイテムが置かれていない、または、スパンされていないトラックのことを指します。（すべてのトラックが空の場合、すべて崩されることもあります。）

崩されたトラックは0pxの固定のトラック・サイズの機能を持つものとして扱われ、アラインメントによって配分されたスペースを含む両サイドのガッターも崩れます。

うむ。なるほど。

文章だとイメージするのが難しいですが、そういうことなんですね（どういうこと？笑）。僕は何度も読み返して、ようやく理解できましたが「なるほど、だからそういう挙動になるのか」というのがわかりますね。

さいごにひとこと

先日の「CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法」でも書きましたが、CSS Gridのrepeat()とminmax()を使いこなせるとグリッドレイアウトの可能性がすごく広がります。さらにjustify-content、align-content、justify-self、align-selfあたりをマスターすれば最強ですね。

古いブラウザを気にせずにCSS Gridを自由に使える日が待ち遠しいです。

では、Happy gridding!（造語）

FirefoxのCSS Gridインスペクターが便利！

2018/02/20 6:24 | 制作・効率化ツール

CSS Gridのデバグに便利なFirefoxのCSS Gridインスペクターをご紹介します。Firefox 56から搭載 されているこのインスペクターを使うと以下のグリッド関連の情報が表示できます。CSS GridするならFirefoxがいいですね。

• グリッドをオーバーレイ表示
• 線番号を表示
• 領域名を表示
• グリッド線を無限に延伸
• 各グリッドの詳細を表示

さいごにひとこと

このツール、複雑なグリッドを作るときには特に便利そうですね。グリッドオーバーレイを表示する方法しか知らなくて、つい最近、この「CSS Gridインスペクター」に気づいたので記事にしてみました。

ちなみに、この記事の執筆時（2018年2月19日）、Safariにはこういった機能はなく、Chromeも拡張機能をインストールする必要があるようです。CSS Gridを使った制作には、やっぱりFirefoxが良さそうですね。Firefox QuantumになってからメインのブラウザをFirefoxに移行したんですが、なかなかいいですね！

That’s it for today. See you again next week!

CSS GridとFlexboxを使ってメディアクエリなしでレスポンシブにレイアウトする方法

2018/02/13 7:36 | ウェブ制作・運営ノウハウ

レスポンシブなレイアウトにはメディアクエリが欠かせないわけですが、CSS GridやFlexboxを使えばメディアクエリなしでもレスポンシブなレイアウトが可能です。メディアクエリが全くいらなくなるということはないと思いますが、CSS GridとFlexboxを使えば、メディアクエリの記述を減らす方法があります。しかもコンテンツの幅に合わせて中身のレイアウトを調整するようなエレメント・クエリ的な使い方も、ある程度なら実現できます。

応用すれば今後のレスポンシブなレイアウトのCSSの組み方を変えてしまうような方法です。

※デモはFirefox 58.0.2、Chrome 64.0.3282.140、Safari 11.0.3でテストしています。

CSS Gridを使ったレスポンシブレイアウト

CSS Gridで以下の2つのCSS関数を使うと、メディアクエリなしでレスポンシブなレイアウトが実現できます。

• repeat()（auto-fillまたはauto-fit）
• minmax()

デモ を見てもらうのが早いと思いますが、下図のようなレスポンシブなレイアウトが簡単なCSSで実装できます。

デモはこちら

必要なHTMLとCSSは以下のとおりです。

HTML

<div class="cssgrid">
  <div>アイテム1</div>
  <div>アイテム2</div>
  <div>アイテム3</div>
  <div>アイテム4</div>
  <div>アイテム5</div>
</div>

CSS

.cssgrid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
  grid-auto-rows: 1fr;
  grid-gap: 0.8em;
  border: 1px solid #ddd;
  padding: 0.8em;
  margin: 0 0 2em;
}

.cssgrid > div {
  background: #ddd;
  overflow: auto;
  min-width: 0;
  padding: 1em;
}

これだけでレスポンシブなレイアウトができちゃうんですね。CSS Gridは、レスポンシブな時代に作られた仕様なだけあって、マルチデバイス対応が組み込まれてるんですね。かなり便利です。

repeat()とminmax()がポイント

ここで、repeat()とminmax()という2つのCSS関数について、少しだけ書いておきます。

• repeat()はグリッドの指定の繰り返しを可能にします
• minmax()は最小値と最大値を指定するCSS関数です

これら2つのCSS関数とauto-fillまたはauto-fitを組み合わせて以下のような記述をすると、display: grid;を指定した親要素の幅に応じてグリッドを自動的に調整して子要素を配置してくれます。

grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));

floatとメディアクエリを使う場合

以前「表示件数と高さが変わるブロックの一覧を、画面サイズに合わせてカラム数を変えて表示する方法」という記事で似たようなレイアウトのデモを作ったんですが、同じレイアウトをfloatでやるとメディアクエリが必要になります。また、コンテンツの高さが変わる場合、nth-child()を使ってclearを入れたり面倒なCSSが必要になります。

CSS Gridだとgrid-gapでアイテム間のガッターも簡単に指定できますけど、floatでやるとmarginの調整とか結構面倒です。

デモはこちら

CSS

参考までに、floatを使った場合のCSSを載せておきます。ほぼ同じようなレイアウトが実現できるんですけど、CSS Grid版の方がシンプルでいいですね。

.float {
  border: 1px solid #ddd;
  padding: 1%;
  margin: 0 0 2em;
  width: auto;
  overflow: hidden;
}

.float > div {
  background: #ddd;
  overflow: auto;
  padding: 1em;
  margin: 2% 2% 3%;
}

.float > div:last-child { margin: 2%; }

@media screen and (min-width: 660px){
  .float > div {
    width: 48%;
    margin: 1%;
    float: left;
  }

  .float > div:last-child { margin: 1%; }
}

@media screen and (min-width: 990px){
  .float > div {
    width: 31.333333%;
  }
}

さいごにひとこと

以上、CSS GridとFlexboxを使ったメディアクエリなしのレスポンシブなレイアウトの方法でした！

CSS Gridを使ったレスポンシブなレイアウトの方法は、以前どこかのブログ（どこか忘れてしまいました…）で見かけて気になっていたんですけど、先日公開されたSmashing Magazineの「Using Media Queries For Responsive Design In 2018 」という記事でRachel Andrewさんがわかりやすく解説してくれています。

僕にとってはかなり画期的な内容で、嬉しすぎて初めてSmashing Magazineで記事にコメント 入れちゃいました。笑

Have fun making grids!

スクリーンリーダーのマーケットシェア 2017

2018/02/06 7:16 | ウェブについての考察など

スクリーンリーダーのマーケットシェアが気になってデータを探してみたら、2017年10月に行われた利用状況の調査結果が2017年末に公開されてました。WebAIM（Web Accessibility In Mind） というユタ州立大にある非営利団体が2009年から行なっている調査で、スクリーンリーダー利用者にアンケートを行った結果 がまとめられています。欧米を中心としたグローバルな調査結果（アメリカ60%、ヨーロッパ23%）です。

この調査結果にはない日本での状況についても少しだけ言及しつつ、一番気になったデータを抜粋してまとめてみます。

回答者の概要

アンケートに回答した1,792名のうち9割近い方がなんらかの障害を理由にスクリーンリーダーを使っていると回答しています。また、障害のうち盲目（blindness）が75.8%、低視力・視覚障害（low vision/visually impaired）が20.4%で、この二つが大半を占めます。

デスクトップのスクリーンリーダー Top 3

複数のデスクトップ・スクリーンリーダーを利用する人が68%いて、メインで使っているリーダーは以下の通りです。

「その他」のなかにはZoomText、SA or SAToGo、Window-Eyes、ChromeVox、Narratorが入っています。また、「よく使うスクリーンリーダー」という質問への回答結果も似たような割合ですが、こちらではNarratorを回答に入れている方が多いです。

そのころ日本では…

2013年の調査結果なので現在の状況とは異なるかもしれませんが、日本ではPC-Talker という日本製のスクリーンリーダーが高いシェアを誇っています。税込41,040円でJAWSと比べると1/3の値段ですし日本製ということでシェアが高いのも理解できます（記事執筆当時）。

• スクリーンリーダーのシェアを調べた研究報告書の紹介 – 聴く耳を持たない（片方しか）

ここで紹介されているのは新潟大学の研究室で行われた調査の結果 なんですが、2013年以降の調査は見当たりません。5年近く経っているので、だいぶ状況は変わってるんじゃないかと想像します。

一緒に使うブラウザ

デスクトップでメインのスクリーンリーダーと一緒によく使われるブラウザは以下の通りです（複数回答）。

近年、Firefoxがいい感じでシェアを伸ばしてるようです。どこかでオープンソースでNVDAとの相性が良いといったことも書いてあったので、NVDAの改善に伴って一緒にシェアを伸ばしてるのかもしれませんね。意外にもChromeのシェアが低いんですね。

ちなみに、「その他」には「IE6、7、8」、「IE9、10」、MS Edgeが入っています。

よく使うスクリーンリーダーとブラウザのコンビネーション

JAWSとIE、NVDAとFirefoxが定番のコンビネーションなんですね。

スクリーンリーダーとビジュアル・ブラウザの使い方

ページを閲覧しながらスクリーンリーダーを使う方も結構いるんですね。約3/4がスクリーンリーダーのみを使うという結果ですが、2割近い人がビジュアルとリーダーの両方を使うと回答しています。

モバイルではVoiceOverが主流

「モバイルでスクリーンリーダーを使いますか？」という質問に88%の方が「はい」と答えています。デストップとモバイルを同じくらいの割合で利用する人が54.0%、デストップをより頻繁に使う人が34.6%で、11.4%がモバイルをより頻繁に使うとのことです。また、モバイルで利用するプラットフォームははiOSが75.6%、Androidが22.0%とのことです。

よく使うスクリーンリーダーのTop 3は以下になります（複数回答）。

VoiceOver	69.0%
TalkBack for Android	29.5%
Voice Assistant	5.2%

さいごにひとこと

先日のCSS Gridとアクセシビリティの記事を書いていて、ユーザの利用環境に近い環境でテストしてみないとわからないことが多いと思ったので、主要なスクリーンリーダーでのテスト環境を整えて使い方もしっかり覚えようと思っています。MacのVoiceOverの使い方を覚えるのでさえ、すでに挫折してるんですけどね。なんか馴染めなくて。。。頑張ろう。

ちなみにWebAIMの「Screen Reader Survey」には、Landmarkについてや情報の探し方など、スクリーンリーダーの使い方に関するより具体的な調査結果も含まれていて、ウェブサイトのアクセシビリティ対応を考える際にとても参考になりそうです。その辺りはもう少し読み込んでリサーチして後日このブログでシェアできたらと思います。

アクセシビリティには「独自の”テクニック”」が必要

今回、アクセシビリティについて学び始めてみて、改めて「独自の”テクニック”」が必要だというのを実感しています。セマンティックなコーディングをしていればアクセシブルなはずだ！というわけにはいかない部分があるんですね。セマンティックなコーディングをベースとすることは間違ってはいないものの、より多くの方々に気持ちよくウェブサイトを使ってもらうためには、やはりそれなりの工夫というかテクニックが必要なんですね。

近い将来、職場のウェブサイトのデザインシステム（またはフレームワーク、またはパターン・ライブラリ）を再構築しようと考えているので、その際は、そういったアクセシビリティの「独自の”テクニック”」をソースに組み込めるように、しっかり準備をしていきたいと思います。

システムに組み込んでおけば、それを元に作られたページがアクセシブルになる確率が格段に上がりますからね。

Let’s all aim for making reasonably accessible websites! Imagine all the people…

参照URL

• WebAIM: Screen Reader User Survey #7 Results
• スクリーンリーダー PC-Talker
• スクリーンリーダーのシェアを調べた研究報告書の紹介 – 聴く耳を持たない（片方しか）
• 視覚障害者の携帯電話・スマートフォン・タブレット・パソコン利用状況調査2013 – 新潟大学学術リポジトリ Nuar
• JAWS vs. NVDA: Hearing Another Voice
• Screen reader testing guidelines v2.0 – BBC Future Media Standards and Guidelines
• USING NVDA SCREEN READER ON WINDOWS – Bocoup
• JAWS Screen Reader
• JAWS日本語版
• NVDA日本語版 ダウンロードと説明
• NV Access
• VoiceOver について
• 高知システム開発
• 平成18年身体障害児・者実態調査結果 – 厚生労働省
• スクリーンリーダと音声ブラウザの種類とそれらの概要

iPad Pro用に買った極薄・軽量のコンパクトBluetoothキーボードがかなり良い

2018/01/30 7:38 | IT・ガジェット

電子書籍を読んだり、情報収集したり、アイディアをスケッチするのにはiPad ProとApple Pencilの組み合わせが最高なんですけど、ガッツリ文章を書きたいときはやっぱりキーボードが欲しい。ということで、コンパクトなBluetoothキーボードをゲットしました。ドトールの小さなテーブルでも十分作業ができます（下の写真を参照）。

上海問屋の「DN-914246 Bluetooth接続 極薄・超軽量 二つ折キーボード (スタンド型ケース付) 」というやつなんですけど、折りたたみ時で165 x 130mmの大きさで厚さ13mm、重さ170gというコンパクトサイズ。しかも3,500円という低価格です（記事執筆当時）。充電2時間で40時間使えるそうですよ。

見た目も良いしキーボードの打感も値段の割にはいい感じです。キーボードは開くと結構大きいので（キーピッチは18mm）、DELETEキーが小さ過ぎるのに慣れればあとは快適にタイプできると思います。キーボードを開くと勝手に接続されるのでサクッと作業に入れます。

重さと値段を考えれば純正と比較しても悪くない

純正のSmart Keyboard も魅力的ですが、値段がはるのとけっこう重いんですよね（9.7インチ版は230g 、10.5インチ版は244g ）。僕が持ってるiPad Proは9.7インチで、このモデル用のSmart Keyboardはあまり評判が良くなかったし。

iPad Pro 9.7インチは444g なので、キーボードと合わせた重さを比較すると以下のようになります。

iPad Pro 9.7 + Smart Keyboard	674g
iPad Pro 9.7 + Foldable Keyboard	614g

その差は60gなので、そんなに違わないか。。。でも、単三電池の重さが1本で23.5gだそうなんで、2.5本分くらい違います。笑

今使っているMacBook Pro mid-2014が1.57kg なので、MBPを持ち歩くことを考えれば半分以下の重さです。iPad Proだと読書もしやすいしApple Pencilでアイディアスケッチも描けるから、持ち歩くのにこの組み合わせは最強かもしれません。

キー操作で英語と日本語を切り替える方法

ドスパラの商品レビュー欄 に、キー操作での英語と日本語の切り替え方法がわからないと書いてありましたが、いろいろなキー・コンビネーションを試してたら発見しました。

英語と日本語の切り替えはCtrl + SpaceまたはCaps lockでできました。

その他のキー操作

その他にもFnキーとの組み合わせで「すべて選択」、コピー、ペースト、カットなどのキーも用意されてて重宝しそうです。音量や音楽再生のキーまであります。

ケースの使い方はよくわからない

取り外すとスタンドになる透明なケースが付いてるんですけど、造りが少し安っぽくてiPadに傷がつきそうなのはご愛嬌といったところでしょうか。

下の所に動かせるベロが付いていて、スタンドの角度を調整できるみたいなんですが、iPadを乗せると重すぎて壊れそうで不安です。スマホ程度の重さなら大丈夫そうだけど。

まとめ

使用期間はまだ短いですが、なかなか良かったので早速レビューを書いてみました。タブレットやスマホ用に持ち運べるBluetoothキーボードを探してるなら、これ、かなりオススメです。

Amazonに酷似の商品 が売っていて、そっちは4,790円なんですけど違う商品なのかな？微妙にスペックも違ってるしキーの装飾も違って見えます。1,300円分だけクオリティの差があるのか。ないのか。

論理的なコンテンツの順番について考えてたら、CSS Gridで順番は変えない方がいいと思えてきた件

2018/01/24 7:16 | ウェブについての考察など

CSS GridやFlexboxを使うと簡単に視覚的なコンテンツの順番を変えられるけど、アクセシビリティについては注意が必要ですよということを「CSS Gridとアクセシビリティについて気になっていたこと」で書きました。

ざっくり言うと以下の3つに気をつける必要があるんですが、そもそも「論理的なコンテンツの順番」てなに？どうやって決めたらいいの？という疑問は未解決のままでした。

1. HTMLソースでは論理的なコンテンツの順番を保つ
2. CSS GridやFlexboxを使った順番の変更は視覚的な順番のみが変わる
3. スクリーンリーダーやタブ操作にはHTMLソースの順番が使われる

ということで、今回はこの「論理的なコンテンツの順番」についてとCSS GridやFlexboxでのコンテンツの順番の変更につい書いてみます。実は、まだモヤモヤが残ったままなんですが、どこでハマっているか整理しておけば次につながると期待しています。

では、とにかく行ってみましょう！

論理的なコンテンツの順番はスマホでの表示順を目安にする

「論理的なコンテンツの順番」を考える1つの方法は、スマホのような小さい画面にコンテンツをレイアウトする際に何をどの順番で表示するかを考えて、それを論理的なコンテンツの順番とする方法です。前回紹介したMoz web docs にも書いてあるんですが、たしかに、それが一番シンプルでやりやすい方法だと思います。

スマホからのアクセスが優に5割を超えるウェブサイトがほとんどだと思うので、モバイル・ファーストでHTMLを組んでコンテンツをレイアウトしてみて、自然に落ち着いた順番を「論理的なコンテンツの順番」と考える。そして、大きな画面にあわせてレイアウトを調整していく際に、必要に応じて視覚的なコンテンツの順番を変えていく。そんなやり方が一番しっくりきそうです。

そんな感じで、まずはモバイル・ファーストでHTMLを組んで、無事に論理的なコンテンツの順番でページをレイアウトします。で、次にレスポンシブ対応するわけですが、その際、コンテンツの順番を変えるときはアクセシビリティに気をつけましょう！となるわけです。

CSS Gridのorderプロパティは宝の持ち腐れ？

そう考えるとCSS GridやFlexboxの順番の変更機能って簡単には使えなくなっちゃうんですよね。せっかくの機能が宝の持ち腐れというか。。。

そもそも論理的なコンテンツの順番ってコンテキストによって変わる場合もあると思うんですよね。だって、デスクトップでレイアウトする時はAの順番が理にかなっているけどスマホの小さい画面ではBの順番が理にかなってるってことありますよね？え？ない？

なので、いっそのことスクリーンリーダーやタブ操作でのコンテンツの順番もCSS GridやFlexboxで指定したものにするという柔軟な仕様にすれば問題は解決できると思うんですけどね。それか、どちらかに指定できるようにするとか？

まぁ、そういうわけにはいかない事情があるんでしょうね。

憲法改正くらい大変なこと？

セマンティックスはHTMLでスタイルはCSSでというように、セマンティックスとスタイルを明確に分けた状態を保つことを考えると、セマンティックスにあたる文章構造、そして、文章構造の一部であるコンテンツの順番をCSSでいじくるというのはありえない話なんでしょうか？HTMLとCSSの基本的な考え方を覆しちゃうから、憲法改正くらい大変なことなのかもしれません。

個人的には論理や理念にこだわり過ぎると現実的じゃなくなって、結局、ルールが無視されるか、もしくは使われないものになるかどちらかだと思うので、どこかで折り合いをつけた方がみんなのためだと思うんですけど、どうなんでしょうね。未知の大問題を作ってしまう可能性もあるので怖いのはわかるんですけど。

さいごにひとこと

本当に煮え切らない感じで申し訳ないですが、今のところ良い解決策が思いつかないんですよね。もう少しアクセシビリティについて勉強して何か良いアイディアを学べたら、またここでシェアしたいと思います。

それまで、良い解決策をご存知の方がいたら、ぜひお知恵を拝借したいところです。よろしくお願いしますm(_ _)m

Until then, enjoy learning more about a11y!

Atom Editorのツールバー・プラグインに設定するコマンドの探し方と設定方法

2018/01/16 22:35 | 制作・効率化ツール

どこかで見かけて便利そうだなぁと思ったので、 Atom Editor のツールバー（tool-barパッケージ）を入れてみました。設定に少し手こずったのでメモっておきます。

目次

• パッケージのインストール
• Atom Tool Barの基本設定
• 設定ファイルでのボタンの設置
• 設定ファイルの項目説明
• ボタンに設定するコマンド（アクション）の探し方

Atom Tool Barの基本設定

Atom Tool Bar (tool-bar)の基本設定はパッケージ一覧からアクセスできるtool-barのSettingsからできます。以下がここで設定できます。

• ツールバーの表示・非表示
• アイコンのサイズ
• ツールバーの表示位置
• 全幅を使う
• TouchBarを使う（TouchBar搭載のMBPのみ）

設定ファイルの項目説明

Key	説明
type	button、url、function、spacerから選べる。 button: ボタンの設置 url: デフォルトブラウザで指定のURLを開く function: 関数の呼び出し spacer: スペースを入れる
icon	ボタンに使うアイコン名
iconset	アイコンセット名。Octicons以外を使う場合は指定の必要あり。下の一覧から選べる
callback	ボタンに設定するアクション
url	typeにurlを指定した場合、開くサイトのURL
tooltip	ボタンにマウスオーバーした時に表示されるツールチップ

使えるアイコンセット一覧

以下のアイコンセットからアイコンを選んで使えます。

• Octicons (Atom’s flavour)
• Ionicons (ion)
• FontAwesome (fa)
• Foundation (fi)
• IcoMoon (icomoon)
• Devicon (devicon)
• MaterialDesignIcons (mdi)

以下のサイトで探せます（Devicon以外）：

• GlyphSearch

さいごにひとこと

以上、Atom Editorのtool-barパッケージの設定についてでした。ツールを自分好みにカスタマイズして使うの楽しいですねぇ。

Enjoy customizing your tools!

CSS Gridとアクセシビリティについて気になっていたこと

2018/01/15 11:05 | ウェブについての考察など

前回の記事でCSS Gridは「魔法の杖」だと書きましたけど、1つ気になっていたことがあります。

それは、HTMLソースの順番（ソースオーダー）と視覚的な順番（ビジュアルオーダー）にまつわるアクセシビリティについてです。FlexboxでもそうなんですがCSS Gridを使うとCSSで表示順を変更することができます。そうするとHTMLソースにあるコンテンツの順番とブラウザで表示される順番が異なる場合が出てくるわけですね。

「でも、それってアクセシビリティ的にはどうなんだろう？」というのが気になっていました。

マルチデバイス対応のレイアウトを考える際、CSSで表示順を変えられるのはものすごく便利で、まさにここがCSS Gridの「魔法の杖」的な要素の一つでもあるわけです。でも、技術的にできるからといって考えなしにやっていいかというと、そんなことはないですよね。

調べてみたところ、CSS Gridを使い始める前に絶対に知っておきたい最重要のポイントが3つあったのでシェアします。

これってアクセシビリティのことを考えたらどうなの？

ビジュアル・ブラウザだけじゃなくて、スクリーンリーダーでページを読んでる人には不便はないか？キーボードでコンテンツを操作している人に不便はないか？

CSS Gridで簡単にレイアウトが変更できるからこそ、一度立ち止まって考える必要がありそうです。

僕はアクセシビリティのエキスパートではないので（学べよ！自分…）確かな知識はないですが、「HTMLソースの順番がコンテンツとして問題なければ表示順は違っていても良い」と考えていました。なにをもって「コンテンツとして問題ない」とするかは考えが分かれるところだと思いますけども。

マルチデバイス対応でさまざまなデバイス向けにレイアウトを順応させるのと同じで、スクリーンリーダーやキーボード操作でも問題ないようにページを制作していれば、それぞれでコンテンツの順番が違っていても（ソースオーダーとビジュアルオーダーが違っていても）問題はないと思っていたんですね。でも、そんなにシンプルではありませんでした。

すでに仕様策定者やウェブ制作者コミュニティで議論がされているので、その辺りもCSS Gridを使い始める前に知っておいた方が良さそうです。

ポイント1： CSS Gridは視覚的な順番の変更にのみ使う

極端な話、CSS Gridを使うとHTMLにはコンテンツの順番を適当に書いておいて、あとでコンテンツの順番を整えるといったことも可能です。そんなことをする必要性やメリットはないと思うのでやらないとは思いますが、やろうと思えばできる。

でも、それはやめましょう。HTMLソースはセマンティックスに則って論理的な順番で記述して、CSS Gridは視覚的な順番の変更にのみ使いましょうということが仕様にはっきり書かれています。

まず覚えておきたいのは以下の3つです：

• HTMLソースでは論理的なコンテンツの順番を保つ
• 論理的なコンテンツの順番を変える場合はHTMLソースを変える
• CSS Gridで変えるのは視覚的な順番のみにする

一応、仕様の一部を引用しておきます。

Authors must use order and the grid-placement properties only for visual, not logical, reordering of content. Style sheets that use these features to perform logical reordering are non-conforming.

（意訳）
orderとgrid-placementプロパティーは論理的ではなく視覚的な順番を変える場合にのみ使われるべきである。これらの属性を論理的な順番を変更するために使っているスタイルシートは非準拠とみなします。

— CSS Grid Layout Module Level 1 – Reordering and Accessibility

「非準拠（non-conforming）」とまで書かれているので、ここは要注意！ということですね。

ここで「論理的なコンテンツの順番」てなによ？という疑問がふつふつと湧いてくるわけですが、それはちょっと置いといて、その前に知っておくべき大切なことをもう一つ。

ポイント3： 表示とナビゲーション操作の順番に差異が生じる

ブラウザでTabキーを押すとリンクを辿っていけるわけですけど、CSS Gridで表示順を変えてHTMLソースの順と異なる場合、リンクが突然思わぬところに飛んでいってしまう可能性があります。Tabキー操作での動きは、左上から右下（言語によっては逆）に順に移動していくのが理想ですが、CSS Gridで表示順を変えるとそうならない場合があります。

表示順とタブ操作の順は同じになるようにした方が良いのでは？という議論もあるようですが、仕様では音声ブラウザやナビゲーション操作はHTMLソースに従うと明記されています（FlexboxとCSS Gridの両方で）。解決策も議論されてる ようですが、あまりいいものが出てきていない。

基本的にはHTMLソースと表示の順番が大きく変わってしまうようなレイアウトは避けるべき（そういう場合はソースを変えるべき）だと思いつつも、それだとCSS GridやFlexboxのメリットが半減しちゃうし、そんなに白黒はっきりさせられないレイアウトもあるから「なんも言えねぇ」というのが正直な感想です。

最終的には音声ブラウザやTabキー操作を使うユーザのために、どちらか選べるようにしたらいいんじゃないかと思いつつ、この辺については後日もう少し調べて整理したいと思っています。

参考リンク集

全部英語ですけど、参考にさせていただいたウェブサイトやビデオを載せておきます。

• CSS Grid Layout Module Level 1
• CSS Grid Layout and Accessibility – MDN web docs
• Flexbox & the keyboard navigation disconnect – Tink
• Léonie Watson / Technologic (Human After All): Accessibility remix (YouTube) (32:15あたりでFlexboxとアクセシビリティについて説明があります)
• HTML Source Order vs CSS Display Order – Adrian Roselli
• Does reordering content affect accessibility? – A11ycasts #21 (YouTube)
• Maintaining Accessibility in a Responsive World – filament group
• CSS Grid: Responsive and Accessibility

CSS Gridでレイアウトやフレームワークの考え方・作り方が変わる

2018/01/10 7:28 | ウェブについての考察など

最近、ようやくCSS Gridを学びはじめてるんですけど、学ぶ課程で「CSS Gridが”普及”するとBootstrap や Foundtion のようなフレームワークの作り方も変わるんだろうなぁ」と考えています。

どう変わるのかというと、まずは：

• 基本的にレイアウトはCSS Grid（必要に応じてflexbox）でやるようになる
• コンポーネントはいままでのフレームワークと基本的には同じだけど、CSS Gridに入れ込みやすい設計に変わる

もう少し詳しく書くと：

• Bootstrapなどで採用されているグリッド・システムが必要なくなる
• 少なくともrowとcol-4、col-md-6のような書き方はなくなる
• 独自のグリッド・システムで作っていたレイアウトはCSS Gridでやるようになる
• つまり、HTMLにクラスを記述してHTMLでレイアウトを組むのではなくCSSでレイアウトするようになる（あとで説明します）
• コンポーネントは幅に依存しない設計になるが、最適幅（最小幅と最大幅）を定義するようになる

といった感じです。

そうなると、レイアウトやフレームワークに対する考え方を少し変える必要があると感じています。ちょっとしたマインドシフトが必要になる。そんな気がしています。

コンテンツを基準にしたレイアウトが可能に

いままでのHTMLの組み方ではグリッド・システムでレイアウトを作って、そのグリッドにコンポーネントをはめ込んでいくというのが主流でした。でも、CSS Grid後の制作では、まずページに必要なコンポーネントをHTMLに記述する。そして、それらコンポーネントの組み合わせに最適なレイアウトをCSS Gridでするようになる。CSS Gridはすごく柔軟にできた優れたグリッド・フレームワークなので、その方がより柔軟で効率的なコーディングができます。

コンポーネントは幅や高さが可変で、柔軟にレイアウトに組み込める設計にして、基本的には幅に依存しないものにするのが良いと思うんですが、最適幅（最小幅とか最大幅）を定義してルール化しておくと、CSS Gridのminmax()を使ってレイアウトに組み込みやすくなります。

そして、この方法が実現すると真にコンテンツを基準にした「コンテンツのためのレイアウト」が可能になります。いわゆるコンテント・アウト（Content-out）な制作ですね。コンテンツを無理やりグリッドにはめ込むんじゃなくて、中のコンテンツに合わせてレイアウトをするやり方です。

というのが、いまのところの結論です。

で、どのようにこの考えに至ったのか、参考までに書いておきます。

まずは、Bootstrapなグリッドの書き方のおさらいから。

テーブルレイアウトと変わらない

極端な話、概念的にというか根本的には、やっていることは古き良き時代（？）のテーブルレイアウトとあまり変わらないんですね。ただレスポンシブに対応できるようになっただけというか。。。

<table>
  <tr>
    <td width="50%"></td>
    <td width="50%"></td>
  </tr>
  <tr>
    <td width="66%"></td>
    <td width="34%"><td>
  </tr>
</table>

セマンティックスを考えるとレイアウトにテーブルを使うのはイケてない。じゃぁ、divにしてクラス入れよう、みたいな。。。

CSS Gridを使うメリット

CSS Gridを使うことで以下のメリットが得られます。

• HTMLを本来あるべき文書構造に近いものにできる
• HTMLとレイアウトを分離できる
• より柔軟なレスポンシブなレイアウト対応ができる
• いままではDOMを変更しないと出来なかったことができるわけです！
• そうすると、コンテンツを基準にレイアウト制作ができるんです！

これを活用しない手はないわけですね。

では、これを具体的にフレームワークに組み込んで、どうシステム化するのか？というところまでは実はまだ答えが出ていません。はい、すみません。

ただ、ひとつはっきりしているのは、いままでのレイアウトの考え方とは違ったマインドで進めないと、このメリットを最大限に生かせないんじゃないかということです。

ちょっとしたことなんですけどマインドシフトが必要になるんだろうな、と。長く続いた古い習慣を断ち切る必要があるわけです。

結局レイアウトはCSSで書く

原点回帰じゃないですけど、結局レイアウトはCSSでやるようにするのがいいと思っています。HTMLのソースをこねくり回すことを考えるんじゃなくて、CSS GridでCSSでレイアウトをこねくり回す。そのためにCSSの中で「システム」を作る。毎回同じようなスタイルを書かなくてもいいように何かしらのシステムを作ると便利なんだろうなぁと想像しています。

そうすると、やっぱりSassとか使うのがいいのかなぁ。。。
ちょっとわかりませんが、もう少しクリアになってきたらまた書きます。

とりあえず、いまのところ現場からは以上です。

Enjoy experimenting with CSS Grid. It’s much fun!

スクリーンキャストで学べるCSS Gridの入門コースがわかりやすくておすすめ

2018/01/09 7:16 | ウェブ制作・運営ノウハウ

CSS Gridってなんかとっつきにくくないですか？
一通り学んで理解すると「あ、なるほど。これは超便利！」ってなるんですけど、今までのCSSとは違った考え方というか書き方だからですかね？

でも、そんなとっつきにくさを解消してくれるのがビデオ とかスクリーンキャストです。ブログ記事 とか書籍 でも素晴らしいリソース がたくさんあるんですけど、文章だけで学ぶ よりもビデオ やスクリーンキャストの方が「はじめの一歩」としてはわかりやすいですね。

英語ですけど「これはわかりやすい！」というのに出会ったのでご紹介します。スクリーンキャストなので英語が苦手でも大丈夫だと思います。英語の勉強もかねてぜひ！

Learn CSS Grid for free

Scrimba というインタラクティブなスクリーンキャストのプラットフォーム上で作られた無料のCSS Grid入門講座 です。登録は必要ですけど、無料で以下のようなCSS Gridの基礎が短時間で学べます。すごくオススメです。

• CSS Grid Layoutの基礎
• レスポンシブなグリッドの作り方
• repeat()とminmax()の使い方
• justify-content、align-content、justify-items、align-itemsなどの「寄せ」の使い方
• auto-fitとauto-fillの違い

• Learn CSS Grid for free

コース自体もわかりやすくていいんですけど、Scrimbaというスクリーンキャストの仕組みがすごくいいなと思います。キャストを見ながら学べる仕組みで、途中でも見終わった後でも、見ているコードをその場で編集して手を動かしながら学べるようになっています。

コーディングやプログラミングを学ぶのにはすごく良さそうな画期的なプラットフォームです。日本でもすぐに広まりそう。

さいごに

昨年、主要なブラウザのサポートが揃ったことで、ますます注目を集めるCSS Gridですが、これ本当に画期的ですね。レスポンシブなサイト制作にもすごく役立ちますし、プロダクションでも使えるようになる日が待ち遠しい。。。

CSSレイアウトのルネッサンスや〜！

Xcode SimulatorでMobile Safariのインスペクタを使ってページ要素を検証する方法

2018/01/06 7:51 | 制作・効率化ツール

Xcode Simulator（iOS Simulator）のMobile Safariでインスペクターを使ってページ要素を検証する方法です。やり方がトリッキーだったのでメモっておきます。

デスクトップ版Safariで見ると同じように崩れてることが多いので、そっちで直せば解決することが多いんですけど。今回のは久々にMobile Safariのみの崩れだったので少し戸惑ってしまいました。

Safari Technology Previewをインストール

まずはDownloads for Safariページ から、使っているmacOS向けのSafari Technology Previewをダウンロードしてインストールします。

この記事の執筆当時（2018年1月）は通常のSafariで検証できたんですが、ある時期からSafari Technology Previewじゃないとできなくなってしまいました。

要素を検証する方法

• Simulatorを起動してMobile Safariでウェブサイトを開く
• Safari Technology Previewを起動する
• Developメニューに表示されるSimulatorから検証したいページを選ぶ
• これでWeb Inspectorパネルが開きます

Developメニューには「Simulator — iPhone 8 — iOS 15.2 (19C51)」といったように、Simulatorで起動した端末とiOSバージョンが表示されます。Simulatorが表示されない場合は、Safari Technology Previewを再起動してみてください。

環境

ちなみに、上記の方法が使用できたのは以下の環境です。macOSやXcode、Simulatorのバージョンは関係ないのかもしれませんが、念のため書いておきます。

• macOS Monterey 12.1
• Xcode 13.2.1 (13C100)
• Simulator 13.2 (972.2)
• Safari Technology Preview Release 138

以上です！

2017年のRriverを振り返る

2017/12/30 9:18 | ウェブについての考察など

2017年も今日を含めてあと2日ですね。今年もお世話になりました。

今年はブックレビューを書いてみたり、勝手にUI・UXを改善する記事を書いてみたり、いろいろ試してみた年でした。とにかく「明日のウェブ制作に役立つアイディア」に少しでもつながるなら、なんでもいいから書いてみよう！という感じで書いていました。

いいか悪いかは別にして、日々のウェブ制作にちょっとでも役立つ情報とか、ちょっと違った考え方や視点が提供できていれば幸いです。

では、1年の締めくくりにRriverの2017年を簡単に振り返ってみます。

2017年に書いた記事

2017年も週1本を目標に記事を書いてきたんですが、今年の合計は44本！
足りませんでした。数書けばいいってもんじゃないですけど、週1という目標を掲げた以上、達成できないのは悔しいですね。ネタはたくさんあるはずなのに。。。来年こそは52本目指して頑張ります！

2017年	44本
2016年	42本
2015年	28本
2014年	15本

アクセスランキング トップ10

2017年に書いた記事でアクセスの多かった記事 トップ10をご紹介します。

1. 生年月日の入力欄のレスポンシブ対応についていろいろ考えてみた

2. Macの画像管理アプリ「Pixave」が万能でいい感じ

3. レスポンシブに対応できてCSSでデザインを柔軟に変更できるスライダー「Slider Pro」がなかなかいい

4. JavaScriptだけでサーバーの日時を取得する方法のメモ

5. スタイルガイドジェネレーターの「Fractal」がかなり良さそう

6. Affinity Designerの使い方： 画像の書き出し機能が便利ですよ編

7. スタイルガイドとパターンライブラリの違い

8. 頑張れウェブ担！ウェブサイトの良し悪しはウェブ担当者の粘り強いコミュニケーションにかかっている

9. ローカルサイトを外部に公開するためのツール「ngrok」が便利

10. スマホシフトとUIデザインが情報消費に与える影響について思うこと

以上、トップ10のご紹介でした！

さいごに

ということで、2018年はいま一度基本に立ち返っていろいろ見直してみようかなぁと、ぼんやり考えております。

では、今年もあと少し、良いお年をお過ごしください！
そして、2018年もこのブログをどうぞよろしくお願いします。

初心者のためのよく使うLinuxコマンド一覧

2017/12/26 8:59 | 制作・効率化ツール

最近ターミナルでの作業が増えてきて「あれってどうやるんだっけ？」とか「これができたら便利なのに」と思うことが増えてきたので、基礎からコマンドラインの使い方を覚え直しています。使ってないとまたすぐに忘れてしまうので覚え書きです。

とりあえず「これくらい知ってれば便利に使えるはず」というのをざっくりまとめてみました。

ちなみに「6日間で楽しく学ぶLinuxコマンドライン入門 」という本をベースに学び直しています。以下にまとめたコマンドだけでなく、viの使い方からシェルスクリプトの書き方、さらにはシステム管理などについて、すごく丁寧に解説されていてオススメです。

目次

• 頻繁に使うコマンド一覧
• たまに使いそうなコマンド一覧
• 覚えておくと便利な記号
• 覚えておくと便利なキー操作
• Linux系システムのディレクトリ構造
• 確認に使った実行環境

頻繁に使うコマンド一覧

コマンド	説明	オプション
ls	ディレクトリ情報の表示	-a システムファイル表示 -l ロングフォーマット -d 指定のディレクトリ情報のみ表示
cd	ディレクトリの移動
cp	ファイルのコピー	-i インタラクティブモード -p ファイルの属性を維持 -R 丸ごとコピー -v コピーされたファイル名の表示
mv	ファイルの移動 ファイル名の変更にも使えます。mv 元ファイル名 新ファイル名
rm	ファイルの削除	-r ディレクトリとディレクトリ内の全てのファイルを削除。確認なしに全部消えちゃうので要注意です！
cat	テキストファイルの内容を表示	-n 行数表示
touch	ファイルのタイムスタンプの変更。ファイルが存在しない場合は空ファイルが作られる
mkdir	フォルダ作成	-p 入れ子のフォルダを一気に作成
man	マニュアルの表示

たまに使いそうなコマンド一覧

コマンド	説明	オプションまたは使用例
whatis	コマンドの簡単な説明を表示
which	コマンドの保存先を調べる
type	コマンドの保存先を調べる	-a 全ての保存先を表示
apropos	コマンドをキーワードで検索
find	ファイルの検索。find ディレクトリ名 -name ファイル名で検索できる。※いろいろ便利な使い方があるので別途記事にします	-name ファイル名 -typeタイプ（d: ディレクトリ、f: ファイル、l: シンボリックリンク） -mtime 変更日時（-3で3日前から現在、+3で3日前よりも前） -sizeサイズ
cal	カレンダーの表示	例） cal 11 2018
date	日付の表示
pwd	いまいるディレクトリの表示（print working directory）

ファイル操作（フィルタ）系コマンド

コマンド	説明	オプションまたは使用例
head	指定した最初の行を表示する（デフォルトは10行）	-3 最初の3行を表示
tail	指定した最後の行を表示する（デフォルトは10行）	-3 最後の3行を表示
sort	行の並べ替え	-r 降順 -u 重複を削除 -b 先頭のスペースを無視
uniq	隣接する重複行の削除。sortしてからじゃないと機能しない
wc	文字数のカウント。結果は行数、単語数、文字数の順に表示される	-c 文字数の表示（バイト数） -l 行数 -w 単語数

覚えておくと便利な記号

カレントディレクトリ

記号	説明
.	カレントディレクトリ。たとえば、他のディレクトリにあるファイルを、今のディレクトリにコピーするときに使える。

使用例

$ cp /Users/rriver/docs/readme.txt .

直前にいたディレクトリ

記号	説明
~-	直前にいたディレクトリ

使用例

$ cd ~-

ワイルドカード（任意の1文字）

記号	説明
?	任意の1文字

使用例

$ ls ????.txt

ファイル名が4文字の.txtファイルの一覧を表示

ワイルドカード（0個以上の任意の文字列）

記号	説明
*	0個以上の任意の文字列

使用例

ls *.png

.pngのファイル一覧を表示。

出力のリダイレクション

記号	説明
>	出力のリダイレクション

使用例

cat text1.txt > text2.txt

text2.txtにtext1.txtの内容を書き込む。上書きされる。

出力のリダイレクションで追加

記号	説明
>>	出力のリダイレクションで追加

使用例

cat text1.txt >> text2.txt

text2.txtの後にtext1.txtの内容が追加される。

出力のリダイレクションでエラーを書き込む

記号	説明
2>	エラーをファイルに書き込む

使用例

ls - 2> error.txt

error.txtに「ls -」コマンドで出力されるエラーが書き込まれます。

複数のコマンドをつなげて実行する（パイプ）

記号	説明
|	複数のコマンドをつなげて実行できる。前のコマンドの出力が次のコマンドの入力になる

使用例

last | head -3

ログイン情報（lastで出力）の最初の3行をheadで出力

複数のコマンドを連続して実行

記号	説明
;	複数のコマンドを連続して実行（別々のコマンド）

覚えておくと便利なキー操作

キー	説明
Tab	最初の数文字を入力して「Tab」を押すと残りの文字を保管してくれる
Ctrl + B	前
Ctrl + F	後
Ctrl + A	行頭
Ctrl + E	行尾

カット&ペースト

キー	説明
Ctrl + H	カーソルの前の文字を削除
Ctrl + D	カーソル位置の文字を削除
Ctrl + K	カーソルから行尾までを削除
Ctrl + U	カーソルから行頭までを削除
Ctrl + Y	削除した文字をペースト

コマンドの呼び出し

キー	説明
Ctrl + P	前のコマンド
Ctrl + N	次のコマンド

Linux系システムのディレクトリ構造

システムのディレクトリ構造なんて別に知らなくても生きていけるんですけど、知っていると困ったときに便利なんですよね。ということで、超ベーシックなものを一覧にしておきます。「Filesystem Hierarchy Standard 」で標準化されているそうで、リンク先にあるドキュメントにどのディレクトリに何をおくべきか、また、どのようにシェアされるべきかなど、こと細かく書かれています。すごいですね。

ディレクトリ	格納されているもの
bin	必要不可欠（Essential）な基本コマンド。バイナリの略
sbin	管理（システム系）コマンド
usr	各種コマンドやドキュメント
home	一般的にはユーザのホーム。MacではUsers
var	頻繁に更新されるデータ。logとか
etc	設定ファイル
lib	ライブラリ
dev	デバイスファイル
media	リムーバブルメディアのマウントポイント
mnt	マウントポイント。Macの場合Volumes

usrディレクトリの中

ディレクトリ	格納されているもの
bin	ほとんどの基本コマンド
sbin	必要不可欠でない（Non-essential）管理コマンド
local	ユーザがインストールしたコマンド。だからHomebrewとかここなのね
share	共有ファイル

ちなみに、Macではローカライズドファイルシステムという仕組みでFinderでは日本語表記のものがターミナルでは英語で表記される。

確認に使った実行環境

ここに記述したコマンドはすべて以下の環境で確認しています。記事タイトルに「Linuxコマンド」と書いたので「えっ、Macで確認？」というツッコミもあったのでCentOSでも確認をしておきました。さらに書いておくと、macOS はLinuxではなくてUNIXベースのDarwinですが、ここで書いたような基本的なコマンドはほぼ同じように使えます。記事タイトルは「Linux」にしようか「Unix」にしようか迷ったんですが、最近ではLinuxの方が一般的なのかと思ってLinuxにしたのでした。

Mac

• macOS High Sierra 10.13.2
• iTerm2 Build 3.1.5.beta.2
• zsh 5.4.2

Linux

• CentOS Linux release 7.4.1708
• GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)

ここに書いたものはごくごく一般的なコマンドなので問題ないと思いますが、実行環境によっては記述と異なる場合があります。ご注意ください。

Twitterで「タイトルにLinuxコマンドライン操作とあるのに確認したのはmacOS」というご指摘をいただきました。確かに、おっしゃる通りなので、念のためVagrantで走らせているCentOS（CentOS Linux release 7.4.1708）でも確認しました。CentOSの設定がおかしくなっているのか、なぜかwhatisコマンドだけLocaleの問題か何かでエラーが出てしまいますが、それ以外は同じように動きます。

更新情報

• mvコマンドにファイル名の変更について追記しました（2018/8/26）

iPhone Xは本当にスマホの未来なのか

2017/12/18 12:39 | ウェブについての考察など

結局、iPhone X買っちゃいました。スティーブ・ジョブズの言葉に忠実にカバーやケースを着けずに使っています。若干、恐る恐るですけど。笑

当初、発売日に絶対に手に入れるぞ！と意気込んでいたんですが、予約開始日は旅行中で予約を試みたのが夜になってしまい、数週間後まで手に入らないのを見て意気消沈。その時は購入を諦めました。その後、レビューを見て「もしかして、まぁまぁか？」とか「やっぱり14万円は高いよなぁ」と、うだうだ迷っていたんですが結局買っちゃいました。

やっぱりAppleが描くスマホの未来を見てみたくなってしまったんですね。笑

「未来をその手に。」って、Appleが自信を持ってそこまで言うなら「見せてもらおうじゃぁありませんか、その未来を！」と。

ということで、iPhone Xはスマホの未来なのか？2週間ほど使ってみて思ったことをまとめてみます。

そして、コンテンツの花開く未来が始まる

とにかくユーザをコンテンツに集中させてくれる。タスクに集中させてくれる。iPhone Xはそんなデバイスだと思います。

Appleにとって、そして、開発者にとって、さらにはユーザにとってもデバイスとプラットフォームの環境が整った。10年かけて初代iPhone開発当時に思い描いたビジョンがようやく現実となり、そして、「ここから未来が始まります」。

何もかもマーケティングの言葉通りなんですよね。この辺がAppleのすごいところでもあるんですけど。

それ自体の存在は限りなく背景に溶け込んだスマホで体験するコンテンツに、新しい可能性を感じます。ようやく真の意味でコンテンツの花開く時代が来たのだと思います。ユーザをコンテンツに集中させられる環境が整ったことで、アプリであれウェブサイトであれ、制作者はコンテンツの可能性を最大限に引き出せる、そして、そういったコンテンツが最適な環境でユーザに消費される、そんな時代がやってきたんだと。

アイディアとやる気、そして、共感を得られるセンスさえあれば、誰でもコンテンツを作って発進して共有してもらえる。そして、そういったコンテンツがシームレスに消費される環境がある。そんな時代です。改めて考えると、すごいことですよね。

さいごに

こういうガジェットとかサービスのUXって、日常の中で普通に使ってみて体験してみないとわからないことがたくさんあると思っています。ここがイイとかまぁまぁとか、細かいニュアンスって他の人のレビューをみたり、すこし触ってみたくらいではわからないんですよね。やっぱり、自らがっつり体験してみないとユーザの気持ちはわからない。

たとえば、

• はじめは良いと思っていたが、しばらく使ってみたらそうでもなかった
• はじめは気に入らなかったが、しばらく使ってみたら結構よかった

などなど。

日々触れてみてわかることって結構あるんですよね。

「ただ欲しかっただけでしょ？」と、言われると言葉に詰まって反論できませんけど。笑

それはさておき、今回iPhone Xを買ってAppleが描く未来とやらを少しでも感じることができて良かったと思っています。

ハードルは上がるばかりですけど、より良い体験を提供することでユーザに喜んでもらえることを思えば制作が楽しくなりますよね。きっと。笑

では、Enjoy designing for the users!

JavaScriptで簡単に日付が有効かチェックする方法

2017/12/09 12:28 | ウェブ制作・運営ノウハウ

閏年の2月の日付とか各月の31日のある・なしとか、JavaScriptで簡単に日付をチェックする方法はないもんかなぁと探していたら、Stack Overflow にありました。さすがStack Overflow。いつもお世話になってます。

素（Vanilla）のJavaScriptのDate()オブジェクト を使えばけっこう簡単にチェックできるんですね。

ただ、Stack Overflowでの説明だけでは、初心者の僕にはわかりづらいところもあったので調べたことをメモっておきます。

JavaScript関連の他の記事

よかったらこちらも合わせてどうぞ

• JavaScriptだけでサーバーの日時を取得する方法のメモ
• iframeの高さをJavaScriptで自動的に調整する方法
• スクロール時にちょっとしたアニメーションを加えたいときに使えるJSライブラリ「ScrollReveal」
• JavaScript寺子屋に入門させていただきました。よろしくお願いします
• GatsbyJS + Airtable + NetlifyでJAMstackな雑記サイトはじめました

有効な日付かチェックする方法

まず、やり方を簡単に説明します。

Dateオブジェクトに年月日を引数で渡して日付を生成します。

var y = 2017;
var m = 12;
var d = 10;

var date = new Date(y,m-1,d);
// 月は「0」を起点とするので「-1」で調整します

ここで生成される日付の月と最初に指定した月が同じ月になっていれば日付は有効、違っていれば無効になります。

var month = date.getMonth() + 1;
// 月は「0」を起点とするので今度は「+1」で調整します

if(m==month){
 var result = "有効な日付";
} else {
 var result = "無効な日付";
}

上記のコードに間違いがありました！

1行目の「var month = date.getMonth();」を「var month = date.getMonth() + 1;」に修正しました。ここでも月の値の調整が必要でした。CodePenのサンプルコードではこちらの記述になっていたのですが、記事中に記載したこちらのものは間違っていました。

大変ご迷惑をおかけしました！ご指摘いただいて修正しました。わざわざご指摘いただき、本当にありがとうございました！

簡単ですね！

でも、これだけだといったいなぜこういう結果になるのかわかりづらいですよね。
ということで、順を追って説明します。

Dateオブジェクトとは？

たとえば、Dateオブジェクトを使うと引数を与えない場合はシステム上の日付と時刻を返してくれます。

date = new Date();
// dateの値： Sat Dec 09 2017 10:17:26 GMT+0900 (JST)

このDateオブジェクトにnew Date(year, month, day)のように複数の引数を指定すると、指定した日付を生成してくれます。

date = new Date(2017, 11, 10);
// dateの値： Sun Dec 10 2017 00:00:00 GMT+0900 (JST)

ここで注意したいのは、「11」を指定しているのに「Dec（12月）」になっているところです。月は「0」を起点とするので11だと12月になるんですね。

Dateオブジェクトに無効な日付を渡すと…

では、13月に相当する「12」を指定するとどうなるかというと…

date = new Date(2017, 12, 10);
// dateの値： Wed Jan 10 2018 00:00:00 GMT+0900 (JST)

月が1つ進んで2018年1月10日（水）が返ってきます。「無効な引数」とかエラーが出るのかと思ったら違いましたね。

これは日の部分も同じで、たとえば4月31日（4月は30日までしかない）を指定すると、以下のように5月1日が返されます。

date = new Date(2017, 3, 31);
// dateの値： Mon May 01 2017 00:00:00 GMT+0900 (JST)

この特性を使って、指定した月と返ってくる月が同じかどうか調べれば、日付が有効かどうかわかるんですね。

さいごに

これを考えついた人、頭いいですね。尊敬します。
Stack Overflowにもあるように、31日のある日とない日や閏年を一つ一つチェックする方法もありますけど、こっちの方が簡単ですね。

では、Enjoy developing!

コマンドラインでの作業が増えてきたのでMacにzshとzplugを入れてみた

2017/12/06 6:35 | 制作・効率化ツール

最近コマンドラインで作業をすることが増えてきたので、うちのMacBookでzsh の設定を見直しました。備忘録としてメモっておきます。

目次

• 各種バージョン情報
• 使っているシェルの確認
• Homebrewでzshをインストール
• プラグインやテーマを管理するzplugをインストール
• zplugの起動とプラグインやテーマのインストール
• インストールしたプラグイン

各種バージョン情報

• MacBook Pro (Retina, 13-inch, Mid 2014) 古くなってきたなぁ…
• macOS High Sierra 10.13.1
• iTerm2 Build 3.1.5.beta.2
• Homebrew 1.3.8

使っているシェルの確認

現在使っているシェルは以下のコマンドで確認できます。

$ echo $SHELL

あと、どのシェルがインストールされてるか以下のコマンドで確認できます。

$ cat /etc/shells

Homebrewでzshをインストール

管理が楽なのでHomebrewでインストールしました。

$ brew install zsh

vimなどで/etc/shellsに/usr/local/bin/zshを追加します。

$ cat /etc/shells
/bin/bash
/bin/csh
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/zsh

※ sudoを使わないと/etc/shellsは編集できませんでした。

zshをデフォルトシェルに設定

以下のコマンドでzshをデフォルトのログインシェルに設定します。

$ chsh -s /usr/local/bin/zsh

Macのログインシェルの確認や変更については、この辺り を参考にさせていただきました。

.zshrcに設定を書き込む

zshのインストール後、とりあえず、少し凝った zshrc あたりを参考に.zshrcに設定を書き込みました。zshのインストールや.zshrcの記述については「とりあえずZshを使えば良いんだろう？ 」もわかりやすくとても参考になりました。

プラグインやテーマを管理するzplugをインストール

ついでにzplug というzshのプラグインやテーマを管理するツールをインストールしました。zshのプラグイン管理はAntigen とかoh-my-zsh あたりが有名らしいんですけど、情報を漁っていたらどうやらzplugがいいぞとのことでzplugにしてみました。

$ brew install zplug

zplugの起動とプラグインやテーマのインストール

.zshrcに以下を書き込む。

# zplug settings
export ZPLUG_HOME=/usr/local/opt/zplug
source $ZPLUG_HOME/init.zsh

# plugins
zplug "plugins/git", from:oh-my-zsh
zplug "zsh-users/zsh-autosuggestions"
zplug "mafredri/zsh-async", from:github
zplug "sindresorhus/pure", use:pure.zsh, from:github, as:theme
zplug "zsh-users/zsh-syntax-highlighting"

# Install plugins if there are plugins that have not been installed
if ! zplug check --verbose; then
    printf "Install? [y/N]: "
    if read -q; then
        echo; zplug install
    fi
fi

# Then, source plugins and add commands to $PATH
zplug load --verbose

以下のコマンドで.zshrcを読み込み直すとzplugが起動してプラグインやテーマがインストールされます。

$ source .zshrc

※これだとシェルを起動するたびに以下のように情報が表示されます。この表示がいらない場合は.zshrcに書き込んだzplug loadの--verboseオプションを取ります。

[zplug] Loaded from cache (/usr/local/opt/zplug/cache)
 Load "/usr/local/opt/zplug/repos/zsh-users/zsh-autosuggestions/zsh-autosuggestions.plugin.zsh" (zsh-users/zsh-autosuggestions)
 Load "/usr/local/opt/zplug/repos/zsh-users/zsh-syntax-highlighting/zsh-syntax-highlighting.plugin.zsh" (zsh-users/zsh-syntax-highlighting)
 Load "/usr/local/opt/zplug/repos/mafredri/zsh-async/async.plugin.zsh" (mafredri/zsh-async)
 Load "/usr/local/opt/zplug/repos/robbyrussell/oh-my-zsh/lib/git.zsh" (plugins/git)
 Load "/usr/local/opt/zplug/repos/robbyrussell/oh-my-zsh/plugins/git/git.plugin.zsh" (plugins/git)
 Load "/usr/local/opt/zplug/repos/sindresorhus/pure/pure.zsh" (sindresorhus/pure)
[zplug] Run compinit

インストールしたプラグイン

プラグインはawesome-zsh-plugins あたりを参考にインストールしました。ちなみに、上で入れてるのは以下のプラグイン。

• mafredri/zsh-async （タスクを非同期で実行できるようにする）
• zsh-users/zsh-syntax-highlighting （コマンドをハイライトしてくれる）
• zsh-users/zsh-autosuggestions （履歴をベースにコマンドをサジェストしてくれる）
• plugins/git （gitのエイリアス 。oh-my-zshのプラグイン）
• sindresorhus/pure （かなりミニマルなテーマ。けっこう気に入ってます）

さいごに

ということで、zshとzplugのインストールと設定についてでした。

Enjoy zsh!

22個のフォーム項目を5つに？モバイル・ウェブ制作に必要な考え方とは

2017/11/30 14:04 | ウェブについての考察など

Conversions@Google 2017 での「Mobile in the Future 」というルーク・ロブルースキー氏のプレゼンにすごく感銘を受けたので、ここでもシェアします。ルーク氏はモバイル・ファースト を提唱した、そう、あの人です。

ちなみに、2017年11月にダブリンで行われたイベントだそうですが、アップされてる動画の中でルークさんのプレゼンが圧倒的に再生回数が多い です。さすが。

プレゼンの内容やスライドのデザインはもちろん、Q & A まですべて素晴らしい内容でした。話も上手で出てくる情報やデータの量も半端なくて説得力があるんですよね。本当にすごい。

ところどころ彼のテクノロジーオタクっぽいところが出ているんですけど、それも含めて好きなプレゼンです。自分の考えとシンクロすることも話していて、すとんと腹落ちしました。

3つのポイント

僕がこのプレゼンを見て最も重要だと思ったところを、ざっくり3つの要点にまとめてみます。

プレゼンはYouTube にアップされてるので、英語が大丈夫な方にはぜひ通しで見てもらいたい内容です。1時間40分の価値ありです。

以下はあくまで僕の解釈なので悪しからず。

モバイルがビジネスの主戦場に

ビジネスはモバイルに完全に移行している。アプリでもウェブでも。モバイルでのユーザ数やモバイルで行われるビジネスのボリュームは、ここ10年で爆発的な成長を遂げている。たとえば、FacebookのモバイルMAUなんて100倍とかそんなレベル。

モバイル・アプリやウェブは進化していない

それなのにモバイル向けのアプリやウェブは、ここ10年であまり進化を遂げていない。デスクトップでやっていたことを、そのまま小さい画面に詰め込んでいるだけと言っても過言ではない。細かい改善は繰り返しているのかもしれないけど、そんなに大きくは変わっていない。。。というのが現実。飛躍的に良くなったとは決して言えない状態。

人をテクノロジーに従わせるのをやめる

では、モバイル制作を進化させるにはどうすれば良いのか？

それには人をテクノロジーに従わせるという考えを捨てて、テクノロジーを人のために最大限に活用するという考えを持つ必要がある（後ほど具体的に説明します）。ユーザの体験をよりシンプルにするために技術を活用する。

たとえば、iPhoneのTouchIDやFaceIDなんかはそれの最たるもので、裏では革新的な技術や複雑な仕組みが走っているのに、ユーザ体験はすごくシンプルです。以前は端末をアンロックするのにわざわざパスコードを入力していたのに、指を置くだけで、スクリーンを見るだけでアンロックできるようになりました。

技術で複雑さを解決するというのは、まさにこういうこと。

さて、プレゼンは1時間40分もあるので、もっと盛りだくさんの内容ですが、絞り絞って要点をざっくりまとめるとこんな感じです。

まさにその通り！でも。。。

現代のモバイル制作（ウェブでもアプリでも）に求められているのは、確かに上にまとめたようなことで、小さい画面にいかに情報やデザイン要素を詰め込むか、いかに上手に隠すかを考えることではないんですね。目指すべきは、技術を活用してユーザの体験をいかにシンプルに、よりシームレスなものにできるかを考えることです。いかにモバイルにあった体験にできるかが課題です。それが解決できて、ようやく進歩した、進化したと言える。

う〜ん、なるほど。まさにその通りですね。
たしかにそうしたいと思うし、それが当たり前の流れだと思います。

でも。。。実際にやることを考えると「う〜ん」と唸りたくなります。

だって、チームや組織でそれを成し遂げるって、かなりハードル高いですよね。もう、ハードルというよりも棒高跳びレベルというか。。。笑

これをやろうとすると、技術力やデザイン力もさることながら、担当者の調整力や粘り強いコミュニケーション、さらには組織内での政治力みたいなものが必須になってくるわけです。はっきり言って、ここが一番面倒で大変なところだったりもするので簡単には解決できないことが多くなります（それができなくて悩んでいるデザイナーやエンジニア、ディレクターの方はけっこう多いはず）。

でも、大変だからこそ価値があるし、2年後、3年後にそういったことができてなかったら、ビジネスという戦いの場で組織も人も生き残れなくなるんじゃないかと思っています。

だって、競合やライバルはどんどん進化して待ってくれませんからね。

「22個の項目を5つにする」という考え方

では、「技術を活用してユーザの体験をいかにシンプルに、よりシームレスなものにできるかを考えること」とは、具体的にどういうことなのでしょうか？

ルーク氏がプレゼン中に1つの例を紹介してるんですけど、その例では22個もあるフォームの項目を5つにしているんです。20とか18にというレベルじゃなくて、5つに！です。

たとえば、下の項目をいかに減らせるかを考えるとします。

なかなか次のようには出来ませんよね？

氏名の項目ってデータベースでは2つの項目に分かれてるから、ユーザにも同じように入力してもらわないと困るし。カタカナ表記の氏名も読み方がわからないと困るから入力してもらわないと。。。

そんなふうに考えていると、結局、データベースというテクノロジーに支配されてしまっていることに気がつくんですね。データベースで項目が2つ必要だから、入力フォームでも2つの項目が必要だと考えてしまっている自分に気づくわけです。

ルーク氏が伝えようとしているのはまさにここで、人をテクノロジーに従わせないというのはこういうことなんですね。そうではなくて、テクノロジーを活用してユーザにとって面倒なことを解決するのが僕らデザイナーやエンジニアの仕事なんだ、と。

たとえば氏名の項目一つをとっても、そもそも2つの項目である必要があるのか、真剣に問い直してもいいのではないか？と。

以上、おおまかに言うとルーク氏が訴えているのはそういうことだと僕は理解しました。

まとめ

ルーク氏のプレゼンを見て「そうそう！それそれ！」と、ものすごく共感したので、ここでもシェアさせてもらいました。

うまく伝わっていると良いですが。。。

しかし、22個の項目を5つにって、技術者目線で考えると、けっこうハードル高いですよね？というのも、データベースだけじゃなくて製品やサービスの根本的なところから見直して、どのデータがなんのために必要でどういった形で利用されているのか確認が必要になるんですよね。ユーザのイニシャルタッチポイントからライフタイムのジャーニーマップをしっかり把握する必要があって、さらに、たいていの組織では部署間を横断するコミュニケーションが必須になる。

さまざまな知識やスキル、さらには実行力や忍耐力が必要とされます。組織によっては、かなりチャレンジングな課題です。ウェブ担当者にはそこまでの権限が与えられていないことも多そうだし。

でも、ルーク氏のプレゼンを見て「これはチャレンジする価値のある課題だ」と再び心から思わされました。

このプレゼンには、他にもたくさんのインサイトがちりばめられています。アイディアの起点となる情報もたくさんあります。オススメです。

Thank you, Luke!

さくらのレンタルサーバー上のWordPressの常時SSL化でハマりまくったのでシェアしておきます

2017/11/21 23:00 | ウェブ制作・運営ノウハウ

さくらのレンタルサーバーで無料SSL証明書が使えるようになったということで、このブログも常時SSL化してみました。やっぱりブラウザに緑のロックアイコンが表示されてると安心しますねw

さくらのレンタルサーバーの無料SSL証明書の設定はすごく簡単で、説明通り にやればものの5分くらいで設定できちゃいました。設定後しばらくしたらすぐにhttpsでサイトにアクセスできるようになったので「お、楽勝か！？」と思ったのですが、そんなことはありませんでした。

このブログはWordPressを使ってるんですが、さくらサーバー特有の設定とかテーマのテンプレートに使っていた古い関数とか、けっこういろいろなところでハマったのでメモっておきます。

サーバー環境やWordPressについて

一応、ざっくり環境を書いておきます。

• さくらのレンタルサーバーのスタンダードプランを独自ドメインで使ってます
• WordPressを自前でインストールして使ってます
• テーマはかなり昔に自分で作ったもので非推奨の古い関数を使っていた
• ドメインのルートではなくてサブディレクトリ「rriver」をトップにしてます。これがリダイレクトの設定の際に結構ややこしい

さくらのレンタルサーバー特有の設定

さくらのレンタルサーバではWordPressの関数が参照している環境変数の$_SERVER['HTTPS']が「on」にならないようになっているらしく、以下をwp-config.phpに追加する必要がありました。

僕の場合は「www」なしのURLを使っているので以下の設定を追加しました。

if( isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR']) ) {
  $_SERVER['HTTPS'] = 'on';
  $_ENV['HTTPS'] = 'on';
}

$_ENVは実は必要ないとのことですが、保険のために入れているとか。

www付きのURLの場合は以下が必要とのこと。

if( isset($_SERVER['HTTP_X_SAKURA_FORWARDED_FOR']) ) {
  $_SERVER['HTTPS'] = 'on';
  if( substr($_SERVER['HTTP_HOST'], 0, 4)!=='www.') {
    $_SERVER['HTTP_HOST'] = 'www.'.$_SERVER['HTTP_HOST'];
  }
}

より詳しく知りたい方は、こちらのサイト で丁寧に説明されています。ありがたや。

画像URLの一括書き換え

あとは各記事で参照している画像URLを書き換えれば、ページが参照しているリソースがすべてhttpsになります。

この書き換えにはSearch Regex というプラグインを使って意外と簡単にできました。記事中にある「http://parashuto.com」をSearchしてざっと確認して、Replace & Saveで、すべて「https://parashuto.com」に書き換えました。

これでhttpへの参照はすべて修正したので、サイトのSSL化は完了しました。無事に緑のロックアイコンも表示されるようになりました！

あとは常時SSL化するために、httpへのアクセスをhttpsにリダイレクトすれば作業完了です。

ところが。。。

さいごに

ということで、紆余曲折しながらなんとか常時SSL化ができました。まだ腑に落ちないところはいくつかあるので、調べて修正したいですが、当面は完了ということで。

お疲れさまでした！

今後の課題:

• ブラグインの書き出すhttpへの参照
• .htaccessのリダイレクト設定

To be continued…

iframeの高さをJavaScriptで自動的に調整する方法

2017/11/20 6:21 | ウェブ制作・運営ノウハウ

レスポンシブなコンテンツをiframeでページに埋め込んでスクロールさせないように表示するとウィンドウ幅によってコンテンツの高さが変わるので、親フレームで高さを調整しないとコンテンツが隠れてしまう場合があります。iframeを埋め込んでいる親フレームにメディアクエリを書けば調整できますが、かなり非効率的な作業です。

先日、JavaScriptを使った方法を見つけたのでこのブログでもシェアします。ちなみに、以下の条件に当てはまる場合に有効です。

• 違うドメインからiframeのコンテンツを読み込む
• iframe内のコンテンツをスクロールさせたくない
• レスポンシブでコンテンツの高さが変わる

同じドメイン内のページを読み込む場合やiframe内でスクロールさせる場合は当てはまらないのでご注意ください。

JavaScript関連の他の記事

よかったらこちらも合わせてどうぞ

• JavaScriptだけでサーバーの日時を取得する方法のメモ
• JavaScriptで簡単に日付が有効かチェックする方法
• スクロール時にちょっとしたアニメーションを加えたいときに使えるJSライブラリ「ScrollReveal」
• JavaScript寺子屋に入門させていただきました。よろしくお願いします
• GatsbyJS + Airtable + NetlifyでJAMstackな雑記サイトはじめました

実装方法の説明

ここではiframeを読み込むページを親フレーム、読み込まれるほうを子フレームと呼びみます。下図のようにJavaScriptのwindow.postMessage()メソッドを使って子フレームから親フレームにコンテンツの高さを送信します。

親フレームで高さを受け取ってJavaScriptでiframeの高さを調整します。

シンプルですね。

実は、長年この解決策が見つけられずに困っていたんですが、意外にもシンプルに解決できて驚きました。しかし、こういう解決策ってふとしたときに見つかるもんですね。

コンテンツの高さの取得についてのメモ

JavaScriptには高さ関連のプロパティがいくつかあってわかりにくいのですが、今回は<html>要素のscrollHeightを使いました。

scrollHeight	隠れているコンテンツを含む全てのコンテンツで、paddingを含む高さ。
offsetHeight	表示されているコンテンツの高さで、padding、border、scrollbarを含む高さ。
clientHeight	表示されているコンテンツの高さで、paddingを含む高さ。

参考: stack overflowにあった図 がわかりやすかったです。

ChromeとSafariでscrollHeightの高さが違う場合がある？

display: none;などでコンテンツが非表示になっている場合で、コンテンツの高さの取得にdocument.body.scrollHeightを使う場合、ChromeとSafariの数値が違っていました。Safariの場合はbodyの高さよりもウィンドウの高さが大きい場合、bodyの高さに関わらずウィンドウで表示されている領域の高さが返されているように見えます。ChromeとFirefoxは若干の数値の差はあるもののSafariほど大きな差がありません。謎です。。。

お気をつけください。

後日、document.documentElement.scrollHeightやdocument.body.heightあたりのプロパティをクロスブラウザで検証してみようと思います。

セキュリティについての注意点

MDN web docs に書いてあるように、postMessage()メソッドは正しく使えばセキュアに違うドメインに設置された複数ページ間でのデータのやり取りができるんですね。

window.postMessage は、安全にクロスドメイン通信を可能にするためのメソッドです。通常、異なった複数のページでのスクリプトはそれらが実行されたページが同じプロトコル（たいてい http）、ポート番号（http のデフォルトは 80）、ホスト（両方のページによって同じ値に設定される document.domain を基準とする）である場合に限りお互いにアクセスすることだけが可能です。window.postMessage は正しく使われたときに安全な方法でこの制限を回避するための制御された仕組みを提供します。

– MDN web docs からの引用

ただ、「正しく使われたときに」というのがキモで、上述したページの「セキュリティに関すること」に書かれているように間違った使い方をするとクロスサイトスクリプティング攻撃を可能にしてしまうので注意が必要です。

任意のウィンドウが、いつでも、ウィンドウの文書の場所にかかわらず、メッセージを送るために、任意の他のウィンドウ上でこのメソッドにアクセスするかもしれません。従って、任意のイベントリスナーはメッセージを受け取る際に、origin あるいは source プロパティを用いて、まず最初にメッセージの送信者の識別情報をチェックしなければなりません。これを軽視することはできません。なぜなら、origin あるいは source プロパティのチェックの失敗はクロスサイトスクリプティング攻撃を可能にするからです。

– MDN web docs からの引用

まとめ

今回紹介したような条件に当てはまる状況って、よくよく考えると結構レアな感じかもしれませんね。でも、似たようなことで困っている方のお役に立てれば幸いです。

では、Happy developing!

頑張れウェブ担！ウェブサイトの良し悪しはウェブ担当者の粘り強いコミュニケーションにかかっている

2017/11/13 12:44 | ウェブ制作・運営ノウハウ

大なり小なり、企業組織でウェブ担当者をしていると組織的な事情でUXを損なう判断をせまられる時があります。たとえば、以下のようなシチュエーション。

• 責任者の〇〇さんがそう言ったから
• システム的に無理だから
• 他媒体と表記の統一をしたいから

ユーザを中心に据えて考えたら「その選択肢はないよね」という判断を余儀なくされる時が結構あるんですね。だけど、そこを知恵と想像力とバイタリティでなんとかするのがウェブ担当者やUXデザイナーと呼ばれる人たちの仕事だと思っています。

ウェブ担当者やUXデザイナーがそこでもうひと踏ん張りして「それはユーザ目線で考えたら○○の方が良いですよ」とか「ユーザ目線で考えることが結果的にビジネスを成功に導くんですよ」と、ユーザを中心に据えた考え方でプロジェクトを導くことで、良い成果をあげてプロジェクトに関わる人たちをハッピーにできる。そして、そういったウェブ担当者の粘り次第でウェブサイトのUXが良くも悪くもなるわけです。

では、上にあげたようなシチュエーションに出くわした時、どういった対応ができるのか？
思いつくことを書き出してみます。諦める自分への自戒の意味も込めて。

組織のさまざまな事情や社内政治が絡んでくるとウェブ担当者の仕事ってすごく大変になるときがあります。この記事が、同じような悩みや課題を抱えているウェブ担当者の方々の少しでもお役に立てば幸いです。

システム的に無理だから

僕が働く組織ではサイト制作と運営を担当する部署とCRM（カスタマー・リレーション・マネジメント）システムなどのシステム導入やインテグレーションを担当する部署（ここではシステム部と呼びます）が分かれています。なので、たとえばCRM関連のウェブへのインテグレーション・プロジェクトではシステム部の人たちと一緒に仕事をします。

そこでたまにあるのが、以下のようなシチュエーションです。

• システムでサポートされていないので対応出来ない
• ベンダーのサポートに問い合わせても答えが返ってこないので対応が難しい

組織内でそのシステムについて一番詳しいシステム部の人がそう言うんだから、しかもベンダーのサポートに聞いても答えが返ってこないんだから仕方がない…と、諦めてしまいそうです。が、ここはあえてウェブ担当者に粘って欲しいところです。

個人的に、技術的なことに関してはなんらかの解決策もしくは代替案が存在して、リサーチして検証すればかならず見つかると思っています。もちろん、想定した仕様のままでは達成できないこともあるので、その辺はフレキシブルな対応が必要です。

では、こういったシチュエーションでウェブ担当者になにができるのか？

• システム部の人より、そのシステムについて詳しくなる。システム部の人に教えてもらったり、自分で勉強したり。なにが出来て、なにが出来ないのか詳しく把握する努力をする。ドキュメントを読み込むとか。
• 周辺技術を勉強しておいて、常に代替案を提案したり検証してもらえるようなアイディアを持っておく
• Proof of Concept（概念実証とかプロトタイプ？）を作って代替案の可能性を見てもらう

ざっと思いつくのはこんな感じですが、やっぱりここでも大切なのはシステム部の人との丁寧かつ粘り強いコミュニケーションだと感じます。あとは、自分の技術的な知識・スキルと経験をどこまであげられるかも大切です。日頃の勉強が肝心になってきますね。勉強しなくっちゃ。。。

まとめ

上にあげた3つのシチュエーション以外にも、ウェブサイトでのUXを壊しかねない組織的事情はたくさんあって、ウェブ担当者は日々対応を迫られます。ウェブサイトは企業とユーザとの1つの大きなタッチポイントでその役割は企業活動にとって大きな影響を与えます。そのタッチポイントでのUXが壊れてしまうと、サービスや製品全体のUXに与える影響は大きいです。

企業ウェブ担当者にあまり権限が与えられていない場合は特に大変ですが、ここで企業ウェブ担当者がどこまで粘れるかが企業活動の成功に大きく影響を与えると言っても過言ではないと思います。それだけ企業ウェブ担当者は責任ある、そして、価値のある仕事をしているのだと思います。

企業ウェブ担当者は企業を支える大きな力を持っているんですね。

頑張れウェブ担！てか、一緒に頑張りましょう！

TotalFinderがHigh Sierraでも動くようになっていた件

2017/11/12 23:00 | 制作・効率化ツール

Mac OS El Capitanから導入されたSystem Integrity Protection (SIP)のせいで使えなくなっていたTotalFinderが復活してました！High Sierraでも動きます。Finder補完ツールとしては一番気に入っていたので嬉しい限りです。これはめでたい。笑

v1.10.2をサイトからダウンロード して以下の手順でインストールしたらmacOS High Sierra (10.13.1)でも問題なく動きました。

1. SIPをオフにする
2. TotalFinderをインストール
3. SIPをオンに戻す

SIPオフ・オンの方法は以前に書いた記事をご覧ください。

TotalFinderの復活は結構前の話 でv1.9.0からだったみたいなんですけど、家のMacBook Pro (Retina, 13-inch, Mid 2014)をHigh Sierraにアップグレードして諸々のメンテをしていて気づきました。

設定メモ

アイコンの変更

TotalFinderのアイコンはあまり好きではないので「環境設定 > Dock」で「Finderアイコンはオリジナルを使う」をオンにする

メニューバーアイコンを非表示

メニューバーのアイコンも邪魔なので「環境設定 > メニュー」から「メニューバーからTotalFinderを取り除く」をオンにする

バイザー機能がやっぱり便利

Finderが下からにょろっと出てくるバイザー機能は便利ですね。
起動ショートカットを「環境設定 > バイザー」で設定できるので、僕は⌘ + ⌘に設定しました。これで⌘キーを2回打つとFinderが出てくるようになります。

システムファイルの表示・非表示

Shift + ⌘ + .がデフォルトのショートカットになってます。

カラム表示の列幅の自動調整

これも地味に便利ですね。デフォルトではオフのようなので、「環境設定 > ファイルブラウザ」で「カラム表示で列幅を自動的に調整します」をオンにします。

デュアルモードも便利

2つのWindowが画面に2分割で表示されるデュアルモードもやっぱり便利ですね〜。

以上、遅ればせながらTotalFinder復活祭でした！

iOS 11で動画の保存フォーマットがHEVCに変わって困った件（と対処法）

2017/10/25 7:09 | 制作・効率化ツール

最近、職場で映像制作に携わる機会が増えていて、先日もBロール（セカンドロール）の撮影のためにiPhoneを使って撮影したんですが、Macに取り込もうとしたらエラーが発生するではないですか？！

なぜかと思ったら、iOS 11から動画の保存フォーマットがHEVC（High Efficiency Video Coding）に変わったんですね。iPhoneはiOS 11に更新していたのでHEVCをサポートしてるんですが、MacはまだSierraのままなのでHEVCがサポートされてないんですね（High Sierraでサポート開始 ）。

AirDropや写真アプリ経由でMacに取り込む場合は自動変換してくれるんですが、iPhoneのDropboxやGoogle Driveアプリ経由でファイルをダウンロードすると変換されないままなんですね。フォーマットがHEVCのままなので、Macに取り込んだファイルを開けようとするとSierra搭載のQuickTime Playerではエラーが出てしまいます。

ということで、今回はHEVCについて注意点をまとめておきます。

そもそもHEVCってなんなのよ？

HEVCはH.265の俗称で動画圧縮規格の1つだそうです。High Efficiency Video Codingの略で、従来方式のH.264 / AVCよりも2倍（40%という情報も ）の圧縮効率があって、次世代映像圧縮技術 なんだそうですよ。4K映像にも使われているとか。

圧縮効率が2倍ということは、単純に考えてファイルサイズが半分になるんだから、そりゃそっちのほうがいいですよね。

iOS 11の動画フォーマットには要注意

繰り返しになりますが、iOS 11になってからiPhoneで撮影する写真や映像はデフォルトでHEIF/HEVCに変わった ので要注意です。設定は変えられますが、気づかずに撮影すると面倒になる可能性があるのでお気を付けください。

HEVCで撮った映像をmacOS Sierraに取り込むときは、iPhoneをケーブルでMacにつないで写真アプリでダウンロードするかAirDrop経由でダウンロードすると自動でフォーマットを変換してくれます。

逆にDropboxやGoogle Driveなどの他のアプリ経由だとHEVCのままなので、macOS SierraのQuickTime Playerで再生できないですし、Adobe Premiereにも取り込めません。Premiereは2017年10月24日現在、最新版にアップデートしても取り込めませんでした。iMovieではまだ試してないんですが、10.1.7からサポートしているとのことです。

macOS SierraでのHEVCの再生と変換について

再生

VLC のようなアプリを使えば再生できるんですが、Finderでサムネイルとかプレビューが見られないので不便です。

変換

あと、他の動画ファイルフォーマットに変換したい場合はオープンソースのHandbrake が便利です。ただ、日本語版（0.9.3） はHEVCがサポートされてないみたいなのでお気を付けください。

Apple Watch Series 3，下から見るか？横から見るか？

2017/10/17 22:16 | IT・ガジェット

2年ほど前にAndroid版のスマートウォッチを試してから、スマートウォッチの進化をずっと待ち続けていました。そして、Series 3が出たのを機にApple Watchを買ってみました。購入してから毎日使って実体験としてのUXを検証しています。使い方やスマートウォッチに求めるものは人それぞれなので1人だけの限定的な検証ですが、せっかく体験中なので書き残こしておきます。

ちなみに、セルラー版ではなくてGPS版です。Appleの新製品発表イベントでは、湖でパドルサーフィンをしながらApple Watchで会話するのをデモしていて感動すら覚えましたが、よくよく考えると「やらないな…」という感じだし。個人的にはまだセルラーはいらないかなぁと思ってます。

そもそも格安SIM を使っているから無理というのもありますが、まだ対応したアプリがそろってないのが大きいですね。1年くらい経ったら端末の可能性を引き出してくれる面白いアプリが出てくるんじゃないかと期待しております。その頃にはMVNOでもeSIMに対応していることを期待して。

では、Apple Watch Series 3のレビュー行ってみます！

下から見るか？横から見るか？

ついパロってみたくなるタイトルだったので。。。まだ映画 は見てないですけど。ドラマ版 の奥菜恵の方がやばいとのウワサです。なにが？

それはさておき「Apple Watchって下から見たらどんなだっけ？」と思ってAppleの製品紹介ページ を探したんですが、写真を見つけられませんでした。裏側も格好いいデザインなのに。買う前にシリーズ3で変更があったか見たかったんですよね。

ということで。。。

Apple Watch Series 3を下から見る

Series 3を下から見るとこんな感じです。

さて、ここからようやく本題に入ります。

Apple Watch Series 3の体験レビューとスマートウォッチの将来の可能性について書いていきます。

やっぱりフィットネスが一番の目玉だった

Apple Watchを使ってみて1つだけ大きく生活が変わったことがあります。それは健康促進への意識です。アクティビティ・アプリで日常のフィットネスをモニタリングすることで、Apple Watchを使い始めてから以前よりも意識的にというか強制的に健康管理に意識が向くようになりました。

話だけ聞くと「へぇ〜」という感じで、たいしたことじゃないように聞こえるかもしれないですけど、意外にも日常の行動にかなりの影響があるのを実感しています。

腕時計が生活意識を変えるってすごいことですよね。はい。

1分間の呼吸を促される

たとえば、普通に生活してると呼吸をすることだけに1分間集中することなんて皆無でした。ところが、やってみると意外とこれが気持ちいいもんなんですね。呼吸アプリのアニメーションも良く出来ていて気に入っています。

定期的に立ち上がるように注意してくれる

長い間座ったままで過ごしていると、立ち上がって体を動かすように促してくれるんですね。これも作業に集中していたり、ぼーっとテレビを見ていたりすると座りっぱなしになっていることが多いのでありがたいです。

1日のアクティビティが可視化される

わかりやすく、シンプルに見える化するって本当に大切なんだなと実感しました。1日の活動がわかりやすく可視化されるだけで、こんなにも健康に対する意識が変わるもんなんですね。改めてデザイナーとして強く意識しておくべきことだなと実感しました。UIやUXを考える際も同じですね。

この3本の輪っかをコンプリートするために、もう少し歩くように回り道をしてみたり、エレベーターをやめて階段を登ったり。いままでやらなかった、ちょっとした運動をするようになっています。「疲れてるからいいや」という気持ちを「あともう少し。頑張れ！」と、優しくプッシュしてくれるんですね。

たったそれだけなんですけど、それが大きいんですよね。不思議なもので人間の心理なんてそんなもんなんですね。

キラーアプリの存在

Apple Watch（たぶんスマートウォッチ全般にも言える）の一番の売りは、もっぱら健康管理とかフィットネスモニタリングで決定のようですね。いまのところ他にキラーアプリは存在しない気がするし。

キラーアプリと言えば、後でもう少し詳しく書きますけどSuicaはかなりイケてますね。

あとはゴルフコース上で残りの距離を教えてくれるGPSアプリ もスゴイですけど。ゴルフ自体、プレー人口が減ってるみたいだし年齢層が高いからキラーアプリとまでは行かないですね。

Apple Watchで気に入っているところ

Apple Watchで気に入っているのは以下のようなところです。リストアップしてみたら結構ありましたねw

健康促進に貢献している気がする

上述したとおり健康への意識改善促進には感謝さえしています。まだアラフォーですけど歳をとってきて体がターニングポイントに来ているのを感じるので特にありがたいです。

バンドを気軽に交換できる

普通の時計だとバンドを簡単に替えられないので、これは画期的でした。気分に合わせてバンドが替えられるって楽しいんですね。

サードパーティー製のはAmazonとかで探すとたくさん出てくる ので、僕は3本 ほど大人買い しちゃいました 。それでも、Apple製のレザーバンド1本より少ない値段でそこそこのクオリティーのものが3本買えたので結構満足してます。あくまで個人的な感想ですけど、値段の割にはかなり良かったです。

Suicaが画期的

iPhone 7でモバイルSuicaが使えるようになった時もそうでしたが、Apple WatchでSuicaで支払いが出来るってめちゃくちゃ便利です。自販機に腕時計をかざしたらジュースが出てくるって凄くないですか？笑

初めてやった時は、その場で「おぉ〜」と声を出して感動しちゃいました。

ただ、設定についてはちょっとややこしいところがあります。

たとえば、1枚のSuicaをiPhoneとApple Watchの両方で同時に使うことができないんですね。両端末間での移動は可能なんですが、Apple Watchで使いたかったらApple Watchにカードを移動して使う、同じカードをiPhoneで使いたかったらiPhoneに戻すといったことが必要になります。しかも、なぜかSuica IDが移動のたびに変わってしまうという、さらにややこしいことが起こるらしいです。

仕方がないので、僕はSuicaを2枚登録してiPhoneとApple Watchのそれぞれに一枚ずつ入れています。

あ、あとコンビニだと時計はかざしづらいですね。慣れるまでは、なんか小っ恥ずかしいし。笑

Digital Crownの操作性

昔のソニー携帯のジョグタイヤルが大好きだったので、Digital Crownも大好きです。笑

やっぱりApple Watchの小さい画面ではタッチ操作が難しいときがあるので、Digital Crownとサイドボタンが絶妙に操作性を向上しています。ミュージックのボリュームをDigital Crownで調整するのは気持ちいいとさえ感じます。笑

これもちょっとしたことですけど、使い心地に大きな影響を与えています。

ホーム画面のグリッド表示

使ってみるまでは半信半疑でしたが、実際に操作してみるとなかなかいい感じです。ウニウニ動くのが楽しいし、小さい画面では一覧表示より素早くアプリにアクセスできます。

ちなみに、リスト表示にすると以下のような感じです。

一覧性があってわかりやすいのこっちですけどね。僕はグリッド表示の方が好きです。

文字盤のカスタマイズ

Apple Watchでは文字盤を選べるだけでなく、アプリのショートカット的なものや天気、スケジュールなど、ちょっとした情報表示（コンプリケーションと呼ぶらしい）ができるんですね。

ホーム画面に行かずによく使う機能にアクセスしたり情報が見られるので便利です。

再生中の音楽の操作

イヤフォンにはBeatsX を使ってるんですが、曲戻しをするためには操作ボタンを3回連打する必要があって、それがけっこう難しいんですよね。曲戻しをするのに3〜5回やり直すというのも頻繁に起こります。

Apple Watchをしていると再生中の曲名をサッと確認したり、曲やボリュームの操作が楽にできて重宝しています。僕の場合、これがApple Watchが欲しかった理由の1つです。

ポケットからわざわざiPhoneを取り出さなくても曲名をチェックしたり快適に操作ができるのがありがたいです。

通知のバイブレーション

手首をゆるーくトントンと叩いてくれる感じが心地いいですね。さすがApple。こういうところは絶妙です。

Apple WatchはiPodになり得るのか？

Apple Watchの将来の可能性を考えるときに思い出すのがiPodです。低迷していたAppleが復活できたのはiPodのおかげだと言っても過言ではないので、Apple WatchがiPodの歴史をたどることができるのか？はたまた、iPodの成功をリピートできるのか？と、つい考えてしまうんですね。

自分がiPodを購入したときと、なんとなく状況が似ているようにも思うので、もしかしてApple WatchもじわりじわりとiPodの時のヒットに近づきつつあるのかなと秘かに期待しています。

当時デジタルポータブルミュージックプレーヤー（当時はMP3プレーヤーと呼ばれていた）は他にもたくさんあったのですが、デザインやUIが優れた物があまりなかった。プレーヤーに音楽を取り込むためのソフトも良いのがなかくて、全体としての体験が非常にいけてなかった。その隙間に入り込んできたのがiPodとiTunesだったんですね。

iPodの奇跡

タッチホイールの高い操作性と使いやすいUI、それから、音楽をMacやPCに取り込んで管理するための便利なソフト。iPodとiTunesはCDをMacやPCに取り込んでプレーヤーに入れて、何千、何万曲ものミュージックライブラリを快適に操作して楽しむ。「ポケットに自分のミュージックライブラリを持ち運んで音楽を楽しむ」というユーザ体験を一気通貫して改善することで市場をかっさらって行ってしまったんですね。

AppleがiPod nanoの発売を停止 して、「手首の上で4000万曲をストリーミング 」というのをApple Watchセルラー版の1つの売りにしているのも納得がいくわけです。

iPodと同じことがスマートウォッチというカテゴリでも起こせるのか？先行組のフィットネスバンドやAndroidスマートウォッチの市場を、Apple WatchとAirPodsがかっさらって行くのか、かなり興味深いですね。スマートウォッチ・カテゴリでは2016年後半にいまだにAppleが半数以上のシェアを誇っている らしいのですが、ウェラブルという大きなカテゴリではシェアはまだまだ小さい ので、フィットネストラッキングが強化されたSeries 3で、まだまだ成長の余地はあります。

大きめのスマホ（iPhone 8 Plus）は鞄に入れておいて、たいていのことはApple WatchとAirPodsで済ませてしまう。そんな日常すぐそこまで来てるのかもしれませんね。

iPhone 8 PlusとAirPods買わなくちゃw

ローカルサイトを外部に公開できるngrokの使い方

2017/10/11 22:50 | 制作・効率化ツール

ローカル環境で作っているサイトを、ネット経由で見せたいときってありますよね？
そんなときに便利なのが「ngrok 」というコマンドラインのツールです。

自分の端末のローカル環境で作業をしているウェブサイトを同僚に見せたいときや複数端末でブラウザテストをする際、また、BrowserStack やCrossBrowserTesting のような外部のブラウザテストサービスを使うときにも役立ちます。あと、コワーキングスペースなどで作業していてネットワーク環境がコントロールできない時にも便利ですね。

しかも、これが無料で提供されています。ありがたいですね。開発者の方に感謝です。

ngrokでできること

ngrokでできることを簡単にまとめると、以下の通りです。

• localhostにhogehoge.ngrok.comで外部からアクセスできる
• マルチデバイスのテストに便利
• CrossBrowserTestingのようなテストサービスにも使える
• コワーキングスペースなどでローカルのサイトをシェアしたい時にも便利

インストール方法

1. ngrok.com からダウンロード
2. 任意のディレクトリにファイルを解凍する

僕の場合はコマンドラインでどこからでも使えるように、パスが通っている/usr/local/binにファイルを設置しました。ちなみにPATHの確認は以下のコマンドでできます。

% printenv PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin

基本的な使い方

基本的なコマンドをいくつか書いておきます。

ローカルホストを公開

% ngrok http 8006

このコマンドを実行すると以下のように情報が表示されるので、表示されたURLからlocalhost:8006にアクセスできます。「xxxxxxxx」の部分はngrokから自動で割り当てられます。

Session Status                online
Account                       Ryo Watanabe (Plan: Free)
Version                       2.2.8
Region                        United States (us)
Web Interface                 http://127.0.0.1:4040
Forwarding                    http://xxxxxxxx.ngrok.io -> localhost:8006
Forwarding                    https://xxxxxxxx.ngrok.io -> localhost:8006

ngrokのウェブインターフェイス

ngrokを走らせた状態でhttp://127.0.0.1:4040にアクセスするとngrokのステータスをチェックしたり表示されているページの状態をインスペクトできます。

停止する方法

Ctrl-Cでngrokを停止できます。

サブドメイン

上の「xxxxxxxx」を指定することも可能です。

% ngrok http -subdomain=hogehoge 8006

-subdomainオプションに指定したサブドメイン（上の場合は「hogehoge.ngrok.io」）で、localhost:8006にアクセスできます。

パスワード保護（BASIC認証）

BASIC認証でパスワード保護することもできます。

% ngrok http -auth='user:password' 8006

「user」に任意のユーザ名、「password」に任意のパスワードを指定します。これで表示されたサブドメインからlocalhost:8006にBASIC認証付きでアクセスすることができます。

まとめ

以上、ローカル環境（localhost）を外部に公開するための便利なツール「ngrok」についてご紹介しました。こういったツールはいくつかありますが、その時の状況や環境にあわせて使い分けられるように、いくつか準備しておくと良さそうですね。ちなみに、僕は最近ではお手軽なCodekit とngrok を使い分けています。

では、Happy developing!

メディアクエリの書き方はモジュール（ページ要素）ごとにまとめるのがいい

2017/10/03 7:35 | レスポンシブWebデザイン

先日、久々に凝ったレイアウトのレスポンシブ・ウェブサイトのCSSをがっつり書いていて、やっぱりメディアクエリはモジュール（ページ要素）ごとにまとめて書いた方が良いというのを実感しました。ブレイクポイントでまとめて書くとブラウザで確認しながら細かいレイアウトの調整をするのが大変なんですね。

レイアウトの調整が細かければ細かいほど、メディアクエリはモジュールごとにまとめて書くのが良いです。途中で書き直すのは結構大変なので、これからレスポンシブなサイトのコーディングを始める方で迷っている方、お気をつけください。

以上、Rriverからのお知らせでした。笑

手短に言ってしまうと、伝えたいことは以上なんですけど、もう少し説明してみます。

Sassで書くとさらに便利

以前にも紹介しましたが、メディアクエリをモジュールごとにまとめて書く場合、Sassで書くとスタイルの記述をさらに書きやすく、読みやすくできます。

h1 {
  font-size: 1.6em;

  @media screen and (min-width: 600px) {
    font-size: 1.8em;
  }
  @media screen and (min-width: 960px) {
   font-size: 2em;
  }
  @media screen and (min-width: 1240px) {
    font-size: 3em;
  }
}

まとめ

繰り返しになりますが、あらゆる画面サイズに対応するレスポンシブなページを前提に考えると、丁寧なレイアウトの調整をすればするほどメディアクエリの記述は増えます。なので、メディアクエリはモジュールごとにまとめて書くのが便利です。

どこまで細かいレイアウトの調整をするかはプロジェクトの特性にもよるしケースバイケースなのでなかなか判断が難しいところです。それ以上やっても意味がないという臨界点みたいなのはあるかもしれないですけど、明確な線や点があるわけじゃないから「どこまで」というのはプロジェクトオーナーやマネージャーが決めるしかなさそうです。

ただ、どの画面サイズで見てもレイアウトが「完璧」に整っているものを目指すというのは、やり過ぎな気もします。なんか、クロスブラウザで1pxのづれも許さない昔のコーディングを思い出してしまいますね。

人間らしい柔軟な対応で差を付ける

たとえば、基準となるいくつかの画面サイズでは設計通りのデザインとレイアウトを実装して、残りのサイズは制作者の柔軟な対応に任せるというのが一番現実的だと思います。そして、制作者にとっては、この「柔軟な対応」の部分で技術力とかセンスの差が如実に現れると感じています。さらに言うと、そこがある意味腕の見せ所でもあるんじゃないかな、と思っています。

腕のいい職人さんて、見えにくいところや隠れたところでも丁寧な仕事をしてるもんなんですよね。そして、それが全体の質を上げ、見えないレベル（=感覚で感じ取るレベル）の差に繋がっています。なんでも効率化して数値化・可視化する時代に、こういった目に見えない部分での差別化が、サービスや製品の善し悪しを隔てる境目になってきていると思います。制作者としては、細かい対応ができるように常に準備しておきたいですね。

レスポンシブだとページ設計の自由度が低くなるのか？

2017/09/25 17:50 | レスポンシブWebデザイン

先日、ランディングページの制作を依頼した際、レスポンシブだと設計の自由度が低くなるのでデスクトップ版とモバイル版を分けて制作することを勧められました。

ふむふむ。なるほど。そうなのか…。

いやいや。ちょっと待て。
それってどちらかというと制作者の技量の問題なのではなかろうか？

もちろん、レスポンシブだと設計段階で考えないといけないことが増えるけど、それを「自由度が低くなる」と言えるのかというと、ちょっと違う気がするし。まぁ、言葉のあやなのかもしれないですけど。ユーザがどんなサイズの画面でアクセスしてくるかわからないマルチデバイスのこの時代に、モバイルとデスクトップというざっくりとした2つの画面サイズのみに向けてページを作るのはどうなんだろうか？メンテも二度手間になるし…。

というのが、当初のリアクションでした。

だいぶ昔の話になりますがレスポンシブWebデザインの本 を書いたこともあり（かれこれ5年前）、どちらかというとレスポンシブ寄りな考えを持っているので、同じコンテンツのページで、しかも、自由度が低くなるからという理由で別ページを制作するのには違和感があります。

とはいえ…

とはいえ、せっかくの提案だし試して検証してみたい気もしています。別ページにすることでより良い最適化ができて相対的なコンバージョン数を増やせるのであれば、やってもらおうじゃぁありませんか！笑。

依頼側としてはユーザ体験を損なわずにより良い成果があげられるのであれば、なんら文句はありません。たとえメンテの手間が増えたとしても、目的達成のために必要な手間をかけるのはやぶさかではないですし。

やってみないとわからないことも多いですし。そこから学べることも多い気がしています。

たとえば、以下のようなことを実務レベルで検証できるのも楽しみです。

レスポンシブでは本当に最適化がしにくいのか？

逆に言うと、デスクトップ版とモバイル版を別ページにして設計したら、そんなに最適化がしやすくなるのかというのが疑問でもあり、どんなものが出来上がってくるのか楽しみでもあります。これは嫌みでも何でもなくて。実際にレスポンシブではやりにくいレイアウト構成などもあると思うので、そのあたりの最適化を施すことでコンバージョン率を増やすことが実証できたら、これからのウェブ制作を見直す、というか制作の幅を広げる良い機会になります。

さらに、モバイル版とデスクトップ版を別ページで作ることで発生する課題とか問題とかも再度、肌間隔でつかめる良い機会にもなりそうです。

情報サイトは基本レスポンシブでいいという考え方に代わりはないですが、小数点以下で結果を争うランディングページなどの制作の場合は、あえて別ページで作るというオプションやコンテンツの動的な出し分けをするオプションも積極的に取り入れていくことを考えても良いのかもしれません。

この辺は納品されたページと実践で得られた解析データを照らし合わせてみて、制作者の技量によってはレスポンシブで対応できる物ではないのかとか、動的にコンテンツを出し分けたほうが効率的なのかといったところも検証できそうです。

できることなら、同じコンテンツでレスポンシブ版も作ってA/Bテストができたら、面白い検証になると思うんですけどね。そこまでの贅沢はしてられませんけど。

間のサイズはどうするのか？

デスクトップ版とモバイル版の2つに分けてページを作ったとして、その間のサイズの画面にはどのように対応するのか？どうやって実装して、どのような結果が得られるのか。楽しみです。

たとえば、デスクトップ版は1024pxとか1280pxあたりでレイアウトをデザインして、モバイル版は320pxでするとして、iPadの768pxあたりとかどうするんだろうか？モバイル版を可変サイズにして表示させるのか、そのまま表示させるのか。それとも、デスクトップ版をそのまま表示してスクロールさせるのか。表示の切り替えはどうするんだろうか…とかとか。

間のサイズが最適化されてなくても意外とコンバージョンがあがる、なんてことも？可能性はゼロではないですし。世の中なにが起こるかわからないですからね。いまいちど検証できるのはありがたい。

さいごに

最終的には、そんなことするんだったらレスポンシブで作った方がよかったんじゃないの？と思うことも多いんだろうなぁと思いつつ。ここはぐっとこらえて余計な口は挟まずに結果を待ちたいと考えています。

では、Happy making irresponsive sites!（造語）

MacBook Proでスクリーンセーバーが起動するとファンがうるさくなる時の対処法

2017/09/24 22:54 | IT・ガジェット

最近、MacBook Pro（Retina, 13-inch, Mid 2014）で作業をしていると、たまにファンがうるさくなる時がありました。2つほど原因があったので、また発生した時のために対処法をメモっておきます。同じ問題に出くわした方の参考になれば幸いです。

目次

• スクリーンセーバーが起動するとファンがうるさくなる
• Atom Editorのautocomplete-pathsがCPUに負荷をかける
• SMC（システム管理コントローラ）のリセットについて

スクリーンセーバーが起動するとファンがうるさくなる

スクリーンセーバーをFlurryとかArabesqueに設定しているとCPUの負荷が上がるみたいで、スクリーンセーバーが起動した時にファンが高速で回り出します。スクリーンセーバーでファンがなるほどCPUに負荷かけるってどうなのよ？と思いますが、仕方がないので一番負荷が低そうなクラシックに設定してNational Geographicの写真を表示させるようにしました。設定を変えてから、今のところファンは落ち着いています。

関係ないですけど、さすがNational Geographicの写真は綺麗ですね〜

Atom Editorのautocomplete-pathsがCPUに負荷をかける

Atom Editor をブログの執筆に使っているので立ち上げていることが多いのですが、MacBook Proのファンがうるさくなり始めた時にアクティビティモニター を確認したら、Atom EditorがCPUに負荷をかけているのがわかりました。

ググってみたら、どうやらデフォルトでインストールされているautocomplete-pathsというパッケージが悪さをしているらしい。1,000個以上ファイルがあるプロジェクトを開いていると、このパッケージのせいでCPUに負荷がかかるみたいです。

このパッケージのデフォルト設定では「Max File Count」が1,000に設定されていて、それを越えていると問題が起こるみたいです。そこで、このデフォルト設定を10,000に変更したらファンがうるさくならなくなりました。そもそも1,000を越えるファイルを扱うことってそれほど多くないと思うので、たいていの場合は問題ないと思いますが。もしAtom EditorがCPUに負荷をかけているようだったら、このパッケージのせいかもしれません。確かめてみてください。

ちなみにAtomのバージョンは1.20.1 x64です。

SMC（システム管理コントローラ）のリセットについて

Appleのサポートウェブサイト で「SMC のリセットが必要だと思われる場合の兆候」の1つとして「コンピュータへの負荷が高くなく、正しく通気されているにもかかわらず、コンピュータのファンが高速で回転する」というのがあります。

そこで、MacBook Proのファンが頻繁にうるさくなるようになってからSMCのリセットを何度か試してみたんですが、特に効果はなかったみたいです。僕の場合は、上述の2つが原因だったようなので、SMCは関係なかったんですかね？

• MacのSMC (システム管理コントローラ) をリセットする

SMCのリセット方法

上記サポートウェブサイトではリセットする前の確認作業や詳しい手順が書いてありますが、手っ取り早くSMCをリセットしたい時のためにメモっておきます。以下、バッテリーの取り外しができないIntel搭載のMacノートの場合の手順です。その他の端末の場合はサポートサイトをご参照ください。

1. システムを終了する
2. キーボードの左側の⇧ + ^ + ⌥キーと電源ボタンを押して10秒待つ
3. 1度すべてのキーを放してからMacを起動する

さいごに

ということで、MacBook Proのファンがうるさくなった時の原因と対象法をいくつかご紹介しました。

僕のMacBook ProはMid 2014モデルなので使い始めてから3年ちょいたってますが、まだしばらくは使いたいので現役で頑張ってもらいたいです。新しいMacBook Proは、なんかまだ安定してない気がするし…。

SSHで公開鍵認証を使ってGitHubに接続する設定のメモ

2017/09/12 22:59 | 制作・効率化ツール

職場の新しいiMacを設定していて「あれ、どうやんだっけ？」となったので、また忘れた時のためにメモっておきます。SSHを使ってGitHubに接続するための準備と設定方法です。

GitHubのヘルプ に詳しく手順が書かれているんですが、複数ページに分かれていて若干行き来するのが面倒なんですよね。ということで、ここでは極力短くまとめておきます。

Gitの準備

Gitにnameとemailを登録します。GitHubにpushした時に、ここで設定した氏名とメールアドレスがGitHubで表示されます。

全てのリポジトリで同じ氏名を使う場合

--globalオプションをつけて設定します。

$ git config --global user.name "John Doe"

以下のコマンドで設定を確認できます。

$ git config --global user.name

同様にメールアドレスを登録します。

$ git config --global user.email "john.doe@yourdomain.com"

これでGitの準備は完了です。

SSH Keyの作成

以下のコマンドでKeyを作ります。

$ ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

-tは鍵の種類（dsaとかrsaとか）、-bはバイト数、-Cはコメントの新規作成だそうで。rsaの鍵を4096バイトでメールアドレスをコメントとして作成するというコマンドですね。

前の2つは必須ですが、メールアドレスの記載はあくまでコメントなので必須ではないはず。これがベストプラクティスということなのかな？

ファイル名を聞かれるので、Keyのファイル名を入力します。デフォルトの場合はそのままEnterで。

$ Enter a file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]

Passphraseを入力するとKeyの作成が完了します。

$ Enter passphrase (empty for no passphrase): [Type a passphrase]
$ Enter same passphrase again: [Type passphrase again]

これで.sshフォルダに、指定したファイル名でKeyが作られます。

KeyをGitHubに追加する

最後に、作ったKeyをGitHubに追加します。

Keyをクリップボードにコピーする

$ pbcopy < ~/.ssh/id_rsa.pub

KeyのGitHubへの追加

GitHubの設定画面の「SSH and GPG keys」ページで、新しいSSH Keyを登録します。

以上です！

さいごに

こういった設定は僕にとって日常的に行う作業ではないので、しばらくすると記憶があいまいになってしまうんですよね。こうやって備忘録として一度まとめを書くと情報が脳に定着しやすいので、次回は記憶に残っていることを願って！

では、Happy GitHubbing!

レスポンシブに対応できてCSSでデザインを柔軟に変更できるスライダー「Slider Pro」がなかなかいい

2017/09/07 20:51 | ウェブ制作・運営ノウハウ

ウェブ制作をしてるとスライダーやカルーセルってなにかと必要になるので、レスポンシブやタッチ操作などに対応できて、CSSで柔軟にデザインをカスタマイズできるスライダーのプラグインをいつも探しています。

過去に試したものでいくつかいいのはあるんですけど「帯に短し襷に長し」的なところが必ずあって、すべての要望を満たしてくれるやつには出会えていませんでした。自分でゼロから作るのもあれですし。利用できるものは利用したい。

で、やっと「これなら！」というやつに出会いました。
Slider ProというjQueryのプラグインです。なかなか良さそうです。

ただ、使ってみてハマったところがいくつかあったので書き残しておきたいと思います。

「jQuery オワコン 」がうたわれる昨今ではありますが、今後、Slider Proを使ってスライダーやカルーセルを実装する方の参考になれば幸いです。

• Slider Pro 説明サイト
• Github（ダウンロードはこっちから）

Slider Proの特徴

以下のような特徴があるスライダーのjQueryプラグインです。なかなか柔軟に実装ができて使い勝手が良いです。

• 細かい設定ができて、レイアウトもCSSのみで柔軟に調整できる
• スライドの中身は画像でもテキストでもHTMLで記述してCSSで自由にレイアウトできる
• 全幅表示でカルーセルっぽい使い方はできる
• レスポンシブ対応が楽にできる
• レスポンシブイメージ的な画像の切替表示機能もついている（Retina対応も可能とのこと）
• タッチにも対応。もちろん非対応に設定も可能（※）
• IE8以上で動くらしい（IE9では問題ありませんでした！）
• URLにハッシュをつけて特定のスライダーから表示させられる（deep linking）
• jQueryはオリジナルでは1.11.0を使用してます。2.2.0でも動きます。3.xはダメ。（IE8サポートしたいなら、1.11.0ですね）
• MITライセンスで商用利用も問題なし
• スクリプトがモジュール化されてるので、手間をかければ必要ないものを除外するなど最適化が可能

※ここはちょっと要注意なのであとで書きます。

便利な使い方と注意点

「これは便利！」と思ったオプションなどをいくつかと実装の際にハマったところ・注意点をご紹介します。

よく使いそうな設定一覧

まずは良く使いそうな基本的なオプションからご紹介。

スライドのサイズ指定

widthとheightでサイズを指定できます。pxは記述しなくて良くて、%を使う場合はシングルクォート「’」で囲みます。

width: 300,
height: '100%'

自動再生

autoplay: true

初期値はtrue。

スライドの表示間隔

autoplayDelay: 5000

初期値は5000。単位はミリセカンドなので5000 = 5秒になる。

スライドのアニメーションの速さ

slideAnimationDuration: 700

初期値は700。単位はミリセカンドなので700 = 0.7秒になる。

フェード表示

fade: true

初期値はfalse。スライドアニメーションでスライドを切り替えるのではなくフェード表示にしたい場合はtrue。※fadeとvisibleSizeの併用には要注意。

タッチスクリーンのスワイプ対応

touchSwipe: true

初期値はtrue。オフにしたい場合はfalse。

操作ボタンの表示・非表示

スライド選択ボタン

buttons: true

初期値はtrue。falseで非表示。

前後に進むボタン

arrows: true

初期値はfalseで非表示の状態。trueにするとマウスオーバーで矢印が表示される。

前後のスライドの表示

visibleSize: 'auto'

このオプションを使って、前後のスライドを表示することでカルーセルのように設定できます。
初期値は'auto'で前後のスライドが表示されない状態です。表示させたい場合は'100%'を指定。表示幅をpxで指定することもできる。'all'を指定すると全てのスライドが表示される幅になりました。※fadeとvisibleSizeの併用には要注意。

スライド間の空き

slideDistance: 10

スライドとスライダの間の空きスペースをオプションで指定できます。
ピクセルで指定。初期値は10。「px」の記述はいらない。

マウスオーバーでの挙動

autoplayOnHover: 'pause'

スライドにマウスオーバーしたときの自動再生の挙動をコントロールできます。
初期値は一時停止をする'pause'。そのほかに完全停止する'stop'と何もしない'none'のオプションがある。

この辺を押さえておけば、だいたいの要望には応えられますかね。その他にもたくさんオプションがあるんですが、親切にも日本語訳 を公開してくれている方がいるので、そちらでご覧ください。Githubのドキュメントページ にも英語で記載がありますが、マークダウンが間違っているのか表示が途中で崩れていて読みにくいです（2017/09/05現在）。

全幅でカルーセル的に表示させる方法と注意点

たとえば、3つのスライドをカルーセル的に表示させたい場合、以下のようにオプションを設定すれば簡単に実装可能です。

<script type="text/javascript">
  $( document ).ready(function( $ ) {
    $( '#example1' ).sliderPro({
      width: 420,
      height: 320,
      visibleSize: 'all',
      breakpoints: {
        500: {
          width: 420,
          height: 320,
          visibleSize: 'auto'
        }
      }
    });
  });
</script>

デモはこちら

表示順に関する注意点

ただ、ここで注意したいのが表示される順番です。1つ目のスライドが真ん中にきてしまうので、これを左から1、2、3と順に表示させたい場合は、startSlideでオプションを変更する必要があります。

<script type="text/javascript">
  $( document ).ready(function( $ ) {
    $( '#example1' ).sliderPro({
      width: 420,
      height: 320,
      visibleSize: 'all',
      startSlide: 1,
      breakpoints: {
        500: {
          width: 420,
          height: 320,
          visibleSize: 'auto'
        }
      }
    });
  });
</script>

ところが、先ほど書いた通り、このstartSlideオプションはレスポンシブに対応していないので、デスクトップでは一番左に1つ目のスライドを表示して、モバイル表示で1つ目のスライドから表示させることができません。

上述した対処方法で調整できますが簡単には設定できないので要注意です。

var $win = $(window);
$win.on('load resize', function() {
  var windowWidth = $win.width();

  if (windowWidth <= 500) {
    $( '#example1' ).sliderPro( 'gotoSlide', 0 );
  } else {
    $( '#example1' ).sliderPro( 'gotoSlide', 1 );
  }
});

fadeオプションで挙動が変になる件

fadeとvisibleSizeのオプションを併用してカルーセル的に表示しようとすると、スライド間のアニメーションがおかしくなってしまいます。バグというか対処してないというか。

fade: true,
visibleSize: '100%'

残念ながら対処方法は見つけられていないので、いまのところカルーセル的な使い方をする時はfadeをオフにするしかなさそうです。どなたか、解決策を知っている方がいたら、ぜひコメント欄などで教えてください。

デモはこちら

さいごに

以上、非常に便利なスライダーのjQueryプラグイン「Slider Pro」のご紹介でした。

Enjoy coding!

iOS版はてなブックマークの設定画面が見つからない！勝手にUI改善提案【File #001】

2017/08/10 13:27 | UI・UXデザイン

iOS版のはてなブックマークアプリで設定画面を見つけられずに困ったので、見つけ方を書いておきます。あと、せっかくなので、どうすればもっと見つけやすくなるか、UIの改善を提案してみたいと思います。

余計なお世話ですけどw

ちなみに、はてブアプリのバージョンは3.54でした。

Material Design風のUIデザイン

この画面はMaterial Design 風のデザインになっているので、このボタンのデザインの位置づけは「その画面のメインのアクションを起こすもの」なんですよね。画面の切り替えボタンではなくて。それがこの画面のメインのアクションだといわれたら、あれですけど。でも「アクション」ではないような。。。

なので、設定ボタンがそこに出てくるとは1ミリも予想できませんでした。

Material Designのガイドライン にも「フローティング・アクション・ボタンは画面のメインのアクションのみに使用する（Only use a floating action button for the main action of a screen）」と明記されてるんですよね。

どう使うかはデザイナーの自由ですが、ガイドラインと違った使い方をすると、Material Designを使った他のアプリと使い方が異なってしまうため、ユーザを混乱させる可能性が高いのは肝に銘じておきたいですね。

まとめ

以上、勝手なUI改善提案でした！

こうやって具体的に改善案を考えてみるとよーくわかりますけど、アプリのUIデザインもウェブのUIと同様に簡単じゃないですね。一つの小さな変更がアプリ全体の設計に影響を及ぼすので、今回、僕が無責任に提案したような変更は簡単に実装できるものではないというのは理解できます。

たとえば、2つめの改善案で画面最下部にナビゲーションを追加する場合、それに伴ってかなりの数の画面デザインをやり直さないと意味がありません。アプリ全体でUIの整合性を取り直さないと使いやすくすることは不可能なので、全画面を見直す必要が出てきます。

そう簡単には手をつけられるしろものじゃないですよね。

でも、こういった改善を重ねていかないとアプリは死んでしまう気もするし。ジレンマですね。

最終的には、いかにこういった改善を柔軟に繰り返せるか、そして、新しいワークフローや開発手法を柔軟に取り入れられるかが、アプリ開発やウェブ制作ではすごく重要です。SketchとかCraftとかInVisionとか、ユーザテストのオンラインサービスとか、便利なツールを駆使してやっていくしかなさそうですね。

では、今日はこの辺で。Enjoy improving UI and UX!