2020年がやってまいりましたネ。ネ。

振り返る事ができなかった2019年

すでに1日過ぎ去ってしまいましたが、あけましておめでとうございます。皆様の健やかな1年をお祈り申し上げます。

お祈り申し上げたそばからでなんですが、2019年の暮れから人生で初のインフルエンザに罹り、ウィルスと戦いながらの年越しとなりました。結果ウィルスの殲滅に成功した様で、「インフルエンザを克服する」実績をアンロックできた事をとても嬉しく思います。人生はじめての経験は、貴重な201x年代最後の年末をささげた分は楽しめたと思います。

おかげで2019年を振り返るタイミングを完全に失ってしまったのですが、今この場はそれにふさわしくないと思いますので、このまま振り返らずに2020年を邁進してまいりましょう。

2020年の豊富のようなもの

過去は振り返らずして未来を夢見よう。2020年はどんな年にするか、したいか。

1. 脱エンジニア

ここ数年は仕事ではエンジニア的な、特にフロントエンジニアとしての仕事ばかりに身を投じていたわけですが、今年は非エンジニアな活動をわずかずつでいいので挟んでいきたいと思ってます。完全に脱エンジニアするとそれはつまりほとんど仕事をしないという事になってしまいますので、バランスを考えて、よい按配に。

2. あしあとの見える化

去年一年はほぼ一切のアウトプットをしない年となってしまいました。アウトプットは人の為ならず、とはよく言ったもの。せめて1ヶ月に１つくらいは何らかの形で自分の内なる物をひねり出して形にしていけたらなと思います。そうすることで、この年が終わる時、自分がどのような一年を歩んだかの指標が生まれて、軟体動物かなにかのような正体のない一年でなく、骨のある2020年になるのではないかと。もしも今年の年末にインフルエンザに罹らなければ、の話ですが。

3. 腹筋運動をせずに腹筋を割る

これは去年からの引き続きの豊富ですが、なかなか腹筋道は険しいです。

まとめ

皆様もお体を大切に、しっかりと毎日を咀嚼して味わい深い2020年をお過ごしください。

このたび個人事業主 MATSUKAZE. のWebサイトをリニューアルしましたのでご報告いたします。

ドメインも装いも新たに

MATSUKAZE.design

旧サイト（www.mach3.jp）からドメインを改めて生まれ変わった「MATSUKAZE.design」です。自分的にナウいアレコレを盛り込んで創ってみました。制作期間はおよそ一ヶ月。

リニューアル自体は去年のはじめから進めてはいたのですが、2018年は色々と学ぶことが多かった年で、年末にそこまでに行った全てを無かった事にしたい衝動に駆られ、勢いだけで制作した一品です。お収めください。

技術的な話

技術的にはそんなに大層な事はしていませんが記録として四方山話をここに残しておこうと思います。

TL;DR

• Nuxt + Netlifyははかどるぞ
• NuxtでextractCSSは避けるべき
• Slack送信はお手軽で良い
• 読ませるサイトにリキッドレイアウトは不向きか

Nuxt + Netlify

Nuxt.js を使って静的サイトをジェネレートして Netlify にデプロイしています。

Vueはこれまでも触ってきましたがNuxt.jsについてはこれが初見でした。簡単に説明しておきますと、Vueとそれにまつわる便利なアレコレをパッケージングしてプロジェクトをクイックスタートするためのフレームワークです。名前からもReactのNextを模したものと言ってよさそうです。

Nuxtは静的ファイルの配信機能も備えていて、Nuxt自体が静的サイトジェネレータとして機能します。今回使っているのはこれですね。

一方のNetlifyは、このNuxtの静的サイト配信機能と非常に良くマッチしています。Nuxtで静的サイトを出力するために nuxt generate というコマンドを使用するのですが、これをNetlify側で自動で行ってくれます。（勿論そのように設定する必要はありますが）

図解するとこんなイメージ :

制作者が行うのはリポジトリへのpushだけで、あとはNetlifyがその変更を検知してサイトを再ビルドして公開してくれます。便利な世の中になったものです。

extractCSSには罠が潜んでいる

結論から先に書くと、extractCSSはtrueにすべきではないと考えます。

NuxtではデフォルトでCSSをHTMLファイル内に展開します。つまりドキュメントの style 要素の中にそのページで使用されているスタイルをすべて出力するのです。旧来のWeb制作者の感覚ですとCSSは別ファイルにしたい気持ちがあるかもしれません。その場合は nuxt.config.js 内で extractCSS: true にするという設定が必要になります。

しかし、この extractCSS は落とし穴があります。仕組みとしては恐らく

1. インポートされた vue ファイルの style セクションに書かれたスタイルを抽出
2. それを一旦まとめたものを適正なサイズに切り分けてcssファイルとして出力する

といった感じだと思われ、その役割を担うのが mini-css-extract-plugin なのですが、これが時折エラーを吐きます。

WARNING in chunk …  [mini-css-extract-plugin]
Conflicting order between:

Conflicting order とあるのでコンポーネントを読み込む import 文の順番を少しかえて見たところ、改善したり、逆にエラーが増えたりする症状が見られました。WARNING in chunk なのでcssファイルに切り分ける段階でプラグインがパニックを起こしているのではないかと推察します。

それとは別の問題として、ページを訪問した際に一瞬表示が乱れる不具合が発生しました。これも推測に過ぎませんが、切り分けられたスタイルの読み込み順が制作者の意図を担保出来ないので起きている現象ではないかと思います。最終的に描画されるスタイルは正しい形ですが、MATSUKAZE.design の様にアニメーションを使用しているページでは、読み込み時にかなり滑稽な挙動をします。

そもそもHTMLファイルにスタイルシートを直接展開するのはリクエストを減らしてページ描画までの時間を短縮しようという意図に則った物だと思うので、そこでわざわざ別ファイルに分けるのは愚策なのでしょう。どうしても別ファイルにしたいのならば nuxt.config.js で webpack の設定を拡張して1ファイルにまとめる方法を選択した方が良いと考えます。

クイックコンタクト（Slack）

お問い合わせフォーム とは別に、「クイックコンタクト」という物を設置しました。お問い合わせフォームはメールが送られますが、クイックコンタクトはMATSUKAZE.のSlackにダイレクトメッセージが送られます。クイックコンタクトは全てのページの右下のボタンからアクセスできます。

Slackへの送信のあまりの手軽さに「これだけで良いのでは（メールフォームいらないのでは）」という思いもありましたが、これは「自動返信メール」を送りません。自動返信メールが必要かどうかという議論は脇に置いておいて、送り先も安心と信頼のEメールであるべきという考えもあり、両方実装しておきました。

匿名でOKで自動返信も不要で、かつ重要度の高くないフィードバック等の送信はSlackで十分そうですね。

リキッドの悩み

今回、幅を制限しない純粋なリキッドレイアウトを試みてみました。タブレット・スマートフォン向けのレスポンシブ対応が幾分か楽になった一方で、PCの高解像度ディスプレイで閲覧した時に間延びする印象を受けました。横に長過ぎる文章は非常に読みづらく、無駄にスペースが空いてしまってどうにも気持ち悪さがあります。文章を読ませるサイトでは幅を固定あるいは制限した方が良いかもしれません。

おしまい

フリーランスにとって自サイトの制作は怠りがちになってしまいますよね。なってしまいますよね？しかし、自サイトは蓄えてきた知見の復習と新しい物の実験が存分に出来る楽しい砂場です。すきあらば挑戦していきたいですね。

新しい一年がスタートしました。今年もよろしくお願いいたします。

イノシシの年

イノシシといえば猪突猛進だと思われがちですが、イノシシだってちゃんと走りながら器用に方向転換できるそうです。しかしその突進力は本物なので是非とも見倣うべき。「転ぶときは前のめり」と心に抱きながら、2019年もぐいぐい邁進していきましょう。

豊富など

去年の豊富は宣言しなかった気がしますが、「腹筋運動をせずに腹筋を割る」でした。結果、思い描く割れ方にはほど遠い様でした。やはり割るためには腹筋運動をやらなければいけないのかもしれません。

さて今年は…

• 放置状態にあるサイトをちゃんとリニューアルする
• 絵を描いていく
• 写真を撮っていく

去年はコードを書く事をがんばった年だったので、今年は絵作りに傾倒していきたいです。（勿論コードも書きますのでよろしくお願いします）

放置状態にある自サイトをちゃんと完成までやり通すのが、意外とハードルが高いと思っています。作っているうちに飽きてしまって手が止まった挙げ句、別件で忙しくなって忘却の彼方に…なんていう事はよくある事です（よね？）。そこを押して、今年こそ。

それでは、皆様ともに健やかな一年となりますように。

Vueの年

Vueを触り始めたのは2017年末だと記憶していますが、今年一年はほとんどVueでしか開発をしない、Vueの年であったと言えます。Happy Vue Yearってわけですね。HAHAHA

Vueは流行っているか

個人的なプロジェクトでは勿論の事、新規プロジェクトで自分で技術選択が出来ると知るや即Vueをねじ込むといった、ややもすればエゴとも言える姿勢で臨んでいると、別方向から大変ありがたいことにVueプロジェクトの話が降ってきたりしました。

これがシンクロニシティと言われる物なのか、それとも単純にVueが流行っているという事なのかはわかりかねますが、おかげさまではじめは拙かったVueの扱いも手に馴染んで参りました。（一方で相変わらずReactは苦手意識があります。）この導入のし易さがVueの魅力のひとつでありましょう。

Vueの何が良い？

Vueと言えばまずは学習コストの低さがよく挙げられますが、低いと言っても、Vueの書き方やデータバインディングの仕組みや癖など、学ばなければならない事は決して少なくはありません。恐らく競合であり先輩であるReactと比較した上で、そのように評価されているのだと思っています。

それ以上に個人的に推したい点は、コンポーネントデザインという時流に非常にマッチしているという事です。Vueには「単一ファイルコンポーネント」という仕組みがあり、コンポーネントを構成するHTML・JavaScript・CSSを単一のファイルに、コンポーネント毎に書いていけます。

単一ファイルコンポーネントの例 :

（公式のサンプルコードをちょっといじっただけの物です。）

コンポーネントの構成要素が1ファイルでカプセル化される事で管理が容易になると同時に、プロジェクトのディレクトリ構成に頭を悩ませる時間を大きく削ってくれることでしょう。また、ファイルの構成がHTMLの構成にほぼほぼ則っているので、初学者にとっても取っつきやすいのではないでしょうか。

ちょっと脇道にそれますが、「単一ファイルコンポーネント」は “Single File Component” 略して “SFC” と呼ばれる事があります。しかしながら、わたしの年代ではSFCといえばスーパーファミコンですし、わたしの地元ではSFCといえば慶応大学湘南藤沢キャンパスですので、この略称には些か抵抗を感じざるをえません。（極めて個人的な感想です）

SVG+Vue+TypeScript に感じるノスタルジー

もう少しVueの話です。今年の前半にVueでグラフを描画する案件に携わり、描画部分でSVGを使ったのですが、そこでちょっとしたノスタルジーを感じました。また、同じく後半にVueをTypeScriptで書くプロジェクトがあったのですが、そこでも同じ種の感覚が彷彿とされました。

それは、ActionScript3のMovieClipです。以前の記事（時間を計測する装置について考えてみる） でも軽く取り上げた話ですが、SVGベースのコンポーネントはMovieClipクラスで部品を作る感覚と非常に類似しています。そこでさらにTypeScriptで const val: SomeClass = new SomeClass() の様な型指定をしはじめると、それはもう完全にソレです。

懐かしさを感じると同時に、インラインSVGベースのコンポーネントに表現の可能性を感じたので、今後積極的に使っていきたいという気持ちになりました。勿論、セマンティックの許す範囲内で。

メンターの年

今年の中盤から12月までにかけて、在る方の技術的なメンターを務めさせていただく機会がありました。松風のサイト で掲載されている様に、以前から個人として教育事業に興味があり、それが小さいながらも実を結んだ形となりました。

Web制作講座としてではなく、明確な目標を達成する為のアドバイスを中心とする、いわゆる「メンター」であったため、カリキュラムなどはなく、都度必要に応じて資料を作成して説明などをしつつ、なんとか年内に目標を達成する事ができました。

生徒さんが抱く疑問点にレスポンシブに対応する事に難しさを覚えつつ、初学者がどこで躓くのかという経験が得られた事、どのタイミングでどの知識が必要になってくるのかという「先読み」の知見が得られた事が収穫であったと言えます。

それはそれとして

松風のサイト の情報は古く、未だに横浜市は山手で活動している事になっていますが、現在の拠点は藤沢市です。医者の不養生と言うか灯台下暗しと言うか、2019年早めのリニューアルに向け目下準備中です。

リモートワークの年

2018年はリモートワークでプロジェクトに参画する事が多かった年でした。最も感じたのは、物理的な距離はリモートワークと言えど重要な要素であるという事です。

遠方リモートワークの難しさ

前半は都内のクライアントであったため月次のミーティングなどは直接参加したのですが、後半は遠方のクライアントであったために月一で出張する訳にもいかず、ビデオチャットでの参加となりました。ビデオチャットでのミーティングというのは、難しい物です。その場にいないが故の喋るタイミングの測りづらさ、ほぼ均一に聞こえてくる音声は誰の発言か判断しづらく、また、こちらの音声がちゃんと届いているのかという不安もあります。

ミーティングのみならず実作業においても、実際に物理的に対面したことのない方々とコードを共にしていくというのは何とも表現しようのない難しさがあります。現場の空気が分かっているかどうかが肝なのかもしれません。

先んじて顔合わせを

難しさばかりを書き連ねてしまいましたが、年末に現地に赴いてミーティング参加と少々作業をしたところ、それまで感じていた障壁の様な物が幾分かは払拭出来たように感じました。つまり、遠方のリモートワークに参画する場合は、キックオフの段階で現地で直接話をするのが肝要なのだと思います。きっとその後に続く開発がよりスムーズに進行するでしょう。

まとめ

地元藤沢に戻って久しぶりに年間通して過ごしてみたわけですが、なかなかに面白い一年となりました。来年もまた、小さな実をひとつずつ結んでいきたいと思います。

みなさんにとって2018年はどんな年でしたか？ それでは、良いお年を。

SVG Colk Board を作った話

SVG Colk Board

これは何？

Illustrator 上で図をコピーしてテキストエディタにペーストすると、SVGが出力されます。 しかし、そこで出力されるSVGは不要な記述も多く、末尾に付加されている謎文字のおかげで正常に表示されません。

これらをクリーンに最適化する為に作ったのが SVG Colk Board です。

使い方

1. Illustrator上で図をコピーする
2. それを SVG Colk Board 上でペーストする
3. 配置された図を選択すると「SVG」「DataURI」ボタンが表示される
4. 「SVG」「DataURI」のボタンをクリックすると、それぞれ最適化された結果がクリップボードにコピーされる
5. 結果をテキストエディタにペースト

• ペーストした図のデータは localStorage に保存されるので、ブラウザを閉じた後も保持されます
• つまり貼り付けられる図の数は localStorage の容量依存です
• もちろんブラウザをまたいでは保持されません

SVG Colk Board の中身

このアプリケーションは Vue.js で作られています。 そして Vue と共に利用しているのが Vuex と vuex-persistedstate です。

Vuex

ここでは詳しい説明を省きますが、 Vuexとは、中規模以上のアプリケーション開発向けの状態管理ライブラリで、 公式ではこのように説明されています。

Vuex は Vue.js アプリケーションのための 状態管理パターン + ライブラリです。 これは予測可能な方法によってのみ状態の変異を行うというルールを保証し、アプリケーション内の全てのコンポーネントのための集中型のストアとして機能します。
https://vuex.vuejs.org/ja

簡潔に言うと、状態管理にストア（store）という概念を導入する為のライブラリです。 以下、ものすごくざっくりとした説明をします。

Vue.js のコンポーネントは各々が持つ data の値を基にビューを構築・描画し、必要に応じて処理を行います。 store というのはその data に似た振る舞いをしますが、 data が値へのアクセスで直接変更出来るのに対し、 store はセッターのようなメソッドを介してのみ値を変更する事ができ、 それにより値を保護し、変更を集中管理する事ができます。

ざっくりしすぎていてあまりイメージし辛いかと思いますので、下記ページを参考にしてください。

• 状態管理 — Vue.js

先に述べた通り、中規模以上のプロジェクトでなければあまり恩恵にあずかれず、冗長になるだけと感じるかもしれません。 しかし、Vue.js を採用するという事は、ある程度の規模のあるプロジェクトとなる予測が立つとも言えるので、 転ばぬ先の Vuex を問答無用で入れてしまうのも選択肢の一つだと考えられます。

vuex-persistedstate

今回作った様なミニマムなアプリケーションでは正直Vuexは不向きな気がします。 それでもVuexを導入したのは、半分はVuexで習作してみるため、 もう半分はこの vuex-persistedstate を使うためです。

• robinvdvleuten/vuex-persistedstate: Persist Vuex state with localStorage.

vuex-persistedstate は、Vuexのストアの中身（state）をまるっとlocalStorageに保存してくれるプラグインです。 Vuexでストアを書く時にちょっとインポートしてやれば簡単に導入できます。 （下記はREADMEのコードそのままです）

import createPersistedState from "vuex-persistedstate";

const store = new Vuex.Store({
  // ...
  plugins: [createPersistedState()]
});

これで（同じブラウザで見る限りは）ページの状態を永続化できるという寸法です。 なんて便利なんでしょうか！

まとめ

もともとはイラレが吐き出すSVGを最適化する事しか考えてなかったのですが、 ちょうどよいお題だと思って Vuex を使って習作してみたというお話でした。 このアプリで使用している netlify の知見も少しずつたまり始めたので、それはまたいずれ。

近代以降、人は時間にしばられ、あるいは守られながら生活をするようになりました。 ここでそれが良いことだとか悪いことだとか考えるような詮無い事はしません。 今日は、私達の暮らしに欠かせない「時間」を測定する装置について考えていきたいと思います。

つまり時計である

時間を計測する装置、つまるところ「時計」と呼ばれる装置なのですが、 今あるアナログ時計のデザインに私達はあまりにも慣れ親しみすぎてしまいました。 なのでその存在からは一旦離れて、 改めて私達の生活に必要な「時間」を測る装置のデザインについて思いを馳せます。

なんでこんな事を考え始めたのか

VueでSVGベースのコンポーネントを試してみたかったからです。 ハワイの住人は非常に緩やかな時間感覚をもっていて、それは「ハワイアン・タイム」などと呼ばれるそうです。 常日頃時間に追われて生活していると、ふとそういう物に憧れをもつ事があります。 「大雑把な時間感覚で、ゆるく生きていきたい」と。

そこで、大雑把に時間を把握できるデザインの時計を考えてみようと考えました。

作ってみたサンプル達

そしてこちらが作ってみたサンプルです。 実用性等はあまり深く考えずに自由に、4種ばかり作ってみました。

• ArClock

サンプル1 : 比較的普通なそれ

普段目にするアナログ時計にかなり近いデザインです。 異なる点と言えば、針が円弧になり、時間を表す部分が12時間ではなく24時間単位、つまり1日で1周になる所です。

なぜ今あるアナログ時計が24時間ではなく12時間で1週なのかは詳しく調べていないのでわかりませんが、 12時間の方がぱっと見てより精細に時間を知ることが出来るのは確かです。 ですので、より大雑把にする為に24時間にしてみました。

サンプル2 : 波の様なそれ

このサンプルはちょっとお気に入りです。

時間部分のトータルが24時間になっているのはサンプル1と同様ですが、基点が朝の6時になっていて、右端からスタートします。 つまり、右の円弧は6時から18時までの「昼間」を表し、左の円弧は18時から翌6時までの「夜間」を表します。 右から左にしたのは、東から昇って西に沈む太陽をイメージしていたりします。

分と秒も一応なんとなく分かるようにはなっていますが、これは、あまりに動きがないとつまらないので付けたただの飾りです。 昼間/夜間のだいたい何時くらいなのかがわかれば良いというテーマの時計です。

サンプル3 : 週を意識したそれ

もっと大雑把にしてみました。一週を一つの単位として表現してみた時計（？）です。 月曜日を起点として、現在週のどの辺りなのかを大まかにあらわします。 今回作った時計（？）の中で最も動きの無い、面白みのない物となりました。

日曜日を中央に押し込んだ理由は3つあります。 1つ目は、Saturday と Sunday で “S” が続いて見づらいこと、 2つ目は、7だと360を割り切れないこと、 3つ目は、6ならばリボルバーの弾倉っぽくなるのでイメージとして採用してみようと思った次第です。 （しかし、調べたら7発装填のリボルバーも存在する様でした。 ナガンM1895 – Wikipedia ）

この7つの曜日が全て赤く染まる時、我々は月曜日の到来に恐れおののく事でしょう。

サンプル4 : 年を意識したそれ

さらに単位を大きくして、年にしてみました。 年輪をイメージしていますが、輪になってないしひとつの層は別に年じゃないでしょう？というのは野暮な突っ込みです。 むしろゼンマイをイメージしていると言った方が理解を得られるかもしれません。

このゼンマイ状の線は、現在が1年のどの辺りなのかを示しますが、 半径ではなく線分の長さであらわしている為、見た目と実際に感覚としてズレが生じるでしょう。 しかし、年始の一ヶ月よりも年末の一ヶ月の方が短く思えるのはわりと一般的な感覚のように思えます。 そんな錯覚も表現出来てしまう時計であります。

角層の塗りは60秒で終端にたどり着きます。 ちょっとした動きが欲しかったのと、ぐるぐる動いているのが楽しかったので付けてみました。

技術的な話

これらのサンプルは全てインラインSVGで作られていて、 パスは一部の物を除いてほとんど <path> の A コマンドで描画してあります。 動きはほとんど stroke-dash-array と stroke-dash-offset で実装されていて、アニメーションは全て transition です。

せっかく Vue で作ったサンプルなので <path>　の d 属性を直接書き換えてアニメーションを、とも思ったのですが、 頂点の数が変わると transition は効かないので他の方法をとりました。

SVGベースのVueコンポーネント

インラインSVGをベースにしたVueコンポーネントを今回試してみましたが、なかなか面白いものです。 <path> の描き方を理解すると大抵の物は描けますし、動的に操作する事も容易です。 例えばデータを渡してグラフを描画するコンポーネント実装などでその実力を大いに発揮しそうです。というか、まさにそういうケースで先日発揮しました。

そういった部品を実装しててふと思い出したのが ActionScript3 で作るFlashコンテンツで、非常に類似しています。 AS3でも受け取ったデータから Graphics クラスで動的に描画をするなどしていましたね。 あんなイメージです。

Netlify

Netflix とよく似ている為よくタイポしてしまいがちな Netlify にデプロイしてみました。

Netlify: All-in-one platform for automating modern web projects.
Build, deploy, and manage modern web projects

このサービスは、GitHub等のリポジトリサービスと連携して、そのリポジトリの指定したブランチにpushするだけでデプロイが完了するというお手軽なWebサーバーです。 それに加えて、様々な機能をご利用いただけます。

• ビルドコマンドをデプロイ前に実行してくれる
• Functions 機能で AWS Lambda にもデプロイできる
• Form 機能でフォームリクエストをハンドリングできる
• Let’s Encrypt によるSSL対応（独自ドメインが必要）

Lambdaと連携出来るので、開発コストはさておき大体の事は実現できそうですね。 今回はビルドコマンドの実行ぐらいしか活用していませんが、機会があればがっつり使ってみたい所存です。

まとめ

色々な時計を作ってみましたが、先に申し上げたとおり、実用出来る代物ではありません。 少なくとも、この国で今の生活をしているかぎりは…。

このブログを訪れるような方々は、「ペンで紙に文章を書く」という行為にはあまり縁がないかもしれません。 ですが、だからこそ、今その習慣を見直してみるべきかもしれません。

TL;DR

• ノートとペンを買ってこよう
• 毎朝1ページずつ、文章で埋めよう
• そのノートは誰にも見せてはいけないし、自分も読み返さない

まえがき

この記事のアイディアの源泉には参考図書（後述）があります。 有名な本なので、ご存知の方も多くいらっしゃるでしょう。 その書籍を読んで実践してみたところ、非常に効果的という事を身をもって確認したうえで、より広く知らしめたいと思った次第です。

ただし、本記事の内容は、自分の体験をわたしなりに咀嚼・解釈して読み替えた物です。 ここに書かれる手法や効果などは全て参考図書に直接因る物ではないことを、先にお断りしておきます。

はじめてみよう

まずはじめに、お勧めしたい習慣はただひとつ、毎朝「ペンで紙に文章を書く」事、それだけです。

その繰り返しが、心に良い効果をもたらします。 ある世界では濁ったソウルジェムに輝きを取り戻す様な、またある世界ではサイコパス色相がクリアになる様な、そういった類いの働きがある、というイメージです。 少し胡散臭く感じはじめましたか？

必要なもの

• 新しいキャンパスノート
• ペン
• 毎朝の30分

前述の通り、必要な物は紙とペンと、毎朝すこしだけこの行為の為に割く時間です。 紙は、キャンパスノート等が良いでしょう。 ペンは書きやすいお気に入りのボールペンでも用意しましょう。 あわせて先行投資はせいぜい500円程度です。

時間は、慣れないうちはもっとかかるかもしれません。 （わたしもはじめた当初は1時間くらいかけていました） 会社にお勤めの方は、ちょっとだけ早起きする様にしましょう。

ルール

ただ紙に文字を書くだけで効果が得られたら苦労はないので、もちろん、ルールが存在します。 もっとも、ルールもなくただ紙とペンを渡されても何をすれば良いのかわからず困ってしまいますね。

1. 毎朝１ページずつ文章で埋めていくこと
2. ペンで手書きをすること
3. どんな内容を書いても良い
4. 誰にも見せてはいけない
5. 自分でも過去のページを読み返さない

大切な事は、このノートは「書き捨てる物」だという事です。 記録する為でも、覚えておく為でもない、ただアウトプットして捨てていく物なのです。 その意識で、その前提で書いていきましょう。

実は、「参考図書」においては毎朝書くページ数は3ページとあります。 しかしわたしは1ページだけ書き続けました。 理由は、「参考図書」が英語圏で書かれた物であるということがひとつ。 （日本語は英語に比べてより多くの情報をはるかに少ない文字数で表現できてしまいます） そして、3ページというボリュームは毎朝圧縮率の高い日本語で書き続けるにはハードルが高く、続かないだろうということがもうひとつです。

何を書けばいいのか

「どんな内容を書いても良い」と言われても正直困ってしまいます。 はじめのうちはページを埋めるのにかなりの時間を要するでしょう。

重要なポイントは、自分の脳裏に去来するイメージを、直接、素早くアウトプットする事です。

• 最近あった嫌なこと / 嬉しかったこと
• 好きな物 / 嫌いな物
• やりたいこと、やりたくないこと
• 面倒な仕事
• お気に入りの趣味

などなど、切り口は何でも構いません。 慣れてくればそのトリガーから芋づる式に文章が生まれるようになってくるでしょう。 「こんな事書いてて誰かに見られたらまずいのではないか、恥ずかしいのではないか」という事こそ優先的に書いていきましょう。 このノートは誰も、自分自身すら見返すことはないのですから。

検閲官の目を盗む

人は誰もが心の中に検閲官を飼っています。 （検閲官という表現は非常に言い得て妙で、参考図書の翻訳原文ママです） 脳裏によぎったアイディアを文章に出力しようとした時、「そんな事書いてまずいんじゃないの？」「そんな偉そうな事を貴方が書くのか？」「他の人が読んだらどんな評価をすると思う？」などと妨害してくるのが、心の検閲官です。 困ったことに、誰にも見せない前提の手記に対してですら、時折ダメ出しをしてきます。

彼らの目を盗む一番の手段は、速さだそうです。 思いついたそばから、素早く即座に文字に書き出しましょう。

字は丁寧に書く

「素早く」と書きましたが、折角なので字は出来るだけ丁寧に書きましょう。 きっと字が少しずつ綺麗になっていくでしょう。 ついでに、漢字で書けるところはちゃんと調べて漢字で書きましょう。

推定される効能

ノートに文章を書いているだけで、どんなハッピーな事が起こるのか。 ここで書いている効能は、私自身が実践した上で獲得した物を「恐らくこういう理屈だろう」と、心理学をかじってすらいない私が推測した物にすぎず、 必ずしも万人に同様の効果があらわれる事を保証する物ではありません。

理屈はよくわからないけれど私はこうだった。他の人はわからない。

身も蓋もありませんが、端的に言うとこういう事ですね。

しかし、効果の良し悪しは自分をどれだけ騙せるかが肝なのかもしれません。 必要な経費もきわめて少額ですし、ここはひとつ騙されたと思ってはじめてみる事をお勧めします。

心のデトックス作用

毎朝紙に頭の中身をアウトプットする事で、心の中のデトックス（解毒）作用が働き、その後の一日をゼロベースで送る事ができます。

例えば、悩み事や嫌なことがあってその事ばかりに考えがとらわれてしまい、解決策を見いだせないような時に、それを紙に文字で書き出す事で頭の中を整理する解決法があるそうです。そのメカニズムはこのように説明されていました。

1. 悩んでいる時は、そのアイディアが脳の大部分を占めてしまい、他の事が考えられなくなる。
2. 紙に書き出す事で、脳は「このアイディアは外部記憶媒体に記録されているので、覚えておく必要はない」と判断して、キャッシュから削除する。
3. 脳のリソースに空きが出来る為、対応策に考えを巡らせる事ができるようになる。

要するにこういった働きにより、心の中のリソースを解放する事ができるのだと考えています。 リソースに空きを作る事ができれば、その分リラックスして一日に臨む事ができるでしょう。

また、人間の体というのは、何かを体からアウトプットする事に快楽を得るように作られていると聞きます。 大声を出している時、運動してエネルギーを放出する時、排便等の瞬間、性的行為もそうです。体がそうであるように、心もそうなのではないでしょうか。

脳の呼吸

古い情報で圧迫されていては、他の事に回すリソースが無いので同じ事ばかりに考えを巡らせてしまいますが、 脳のリソースが解放されると、その空いたスペースに新鮮な情報やアイディアが湧いて入り込んで来る事ができます。 コンピューターのキャッシュのような説明の仕方になってしまいましたが、実際似たような物ではないでしょうか。

水泳の息継ぎも少し似ていると思います。 水中で空気を吐ききらないと、水の上に顔を出した時に十分な量の酸素を採る事ができません。 そこで、ここではこの働きを「脳の呼吸」と喩える事にしました。

自分自身を探検する

紙に文章を書いていくうちに、思わぬ自己発見に出会う事があります。 例えば、こんな具合に。

• 友人が成功したので羨ましい。つまりわたしはあの人のような事をやりたいんじゃないかな。
• あの人が嫌いなんだけど、なぜだろう。わたしが嫌う物とその理由を考えてみよう。
• やりたい事がある。けどやっていない。どうしてだろう。

自分自身を掘り起こしていくうちに、自分というキャラクターがおぼろげながら形作られていきます。 それを知る事で、少しずつ自分という人間の扱い方が上手になっていくような感覚をおぼえると思います。

特に、一見ネガティブに見える嫉妬の感情というのは重要なヒントになりえます。 羨ましいと感じるという事は、それが欲しい、それがやりたいという事です。 自分のやりたい事が見つからない人にとっては、大事な足がかりになるでしょう。

少し話が逸れますが、わたしは自分自身を自分自身と捉えず、人生という舞台に立ったひとりの役者と考える様にしています。 自分自身はその役者より少し後ろに立って、役者にどのように演じさせるか、また、この役者ならこの場面でどのような行動をさせたいかを考えているイメージです。 使役や制御といった感覚に近いかもしれません。 こういう考え方をしていると、嫌なやりたくない事を乗り切る時に少し気を楽に持てます。 実際にやるのは自分自身ではないのですから。 （そのうち役者から反逆が起きそうですが）

紙とペンである理由

パソコンやタブレットで因って生活をしている方にとっては、紙とペンはいささかアナクロに感じられるかもしれません。 しかし、デジタルへの入力では上に挙げたような効果は得られないか、得られても些少でしょう。

ひとつの理由として、パソコンやタブレットでは脳からの直接的な出力にはならないからではないかと考えられます。 紙とペンがダイレクトに素早く出力できる媒体であるのに対して、デジタルへの入力はそうではありません。 源泉が脳からの出力である事に違いは無いのですが、それが目の前の画面で実体化されるまでにいくつかのプロセスを踏む必要があり、（障壁と言ってもよいかもしれません） 源泉から結果までの距離が遠いのです。 キーボードを叩いたり、マウスを操作する入力行為もそのプロセスの一つです。 それらの手続きに手間取っている間に、あなたのアイディアは検閲官に見つかってしまうでしょう。

もうひとつの理由は、手で書く行為が原始的な創造行為であるという事です。 それ自体がクリエイティブな行為であって、かつ、さらなるクリエイティビティを呼び起こす可能性が期待できます。 ひょっとしたら、初等教育ですら紙とペンをスキップしてタブレットで学習する完全なるデジタルネイティブならばその限りではないかもしれませんが、 それは今後も生まれないか、生まれるとしても遠い未来の事のように思えますし、その未来が来ない事を願っています。

参考図書について

• 「ずっとやりたかったことを、やりなさい」
  
  著 : ジュリア・キャメロン
  
  訳 : 菅 靖彦

この本は、全ての人は創造的になるべく生まれてきているものだとして、 その創造性を呼び起こす為のツールとして「モーニングページ」を提唱しています。 そして本記事は、これを読んで実践したひとりのWebデザイナーの経験談にすぎません。

興味を持たれた方は是非書店で手にとってみてください。 そしてこの記事ではなく、この本に従って改めて実践してみてください。 先行投資が500円から2000円に増えるだけで、より創造的な体験が得られるでしょう。

大変ながらく横浜にお世話になり、先日までは東京都は荒川区で活動しておりましたが、 この度、神奈川県藤沢市に転居して新しいスタートをきりました。

TL;DR

• 藤沢市に移転しました。
• 生活環境が大きく改善されました。
• 生活習慣を大きく改善させているところです。
• 仕事ください（教育関連だと私が喜びます）

藤沢市という選択

なぜ藤沢市を選んだのかという理由は極めてシンプルで、そこがホームタウンであるという事です。 ただいま、藤沢市。

大学2年から実家を出て横浜に移り住み、およそ18年ほど横浜市内を転々としていました。 その後東京に住んでやろうじゃないかという事で荒川区に移住し、 更新を待たずに、つい先日の11月末に郷里である藤沢市へと戻ってきた次第です。

藤沢市は空と道が広く、海が近く、メインストリートを少し外れると、畑が沢山あります。 換言すると田舎なのですが、不便になるほどには田舎すぎず、程よく田舎です。 住環境として見れば、郷里贔屓ではありますが、最高だと思っています。

また、藤沢市は生涯教育に力を入れていて、そこにあやかれないかという狙いも少なからずあります。 ワークショップなども盛んに行われていると聞きます。 個人的に教育関連の事業に携わっていきたいという希望もあり、 このホームタウンで何かを始められないかと思っています。

移転の理由、環境のリセット

ここにきて移転を決めたのは、住処を含め、諸々の環境をリセットしたかったからです。

フリーランスにとっては住環境≒職場環境です。 住んでる場所や周囲の環境、そこでの習慣は、良い仕事をする為にはきちんと整備されなければなりません。 生活習慣は健康に直結するので、自営業にとっては文字通り生命線ですね。

横浜市や荒川区での住環境は決して悪い物ではなかったと思いますが、 どうやら自分の肌に合わなかったのだな、と思わせるくらいには郷里での生活がしっくりとはまった感覚を覚えます。

環境のリセットのために行った事

環境をリセットする為に、様々な事を試みました。

• 断捨離。とにかく古い物を捨てまくる。
• 家具を新しく買い揃える。
• より良い新しい習慣を身につける。

私は、物を捨てられない人でした。

その私が涙を飲んでものすごい量の家具や小物や衣類を捨てました。 新居で業者を呼んで全部持っていってもらったのですが、 引っ越しの際に運んだ荷物のおよそ三分の一が不用品でした。 過去一年間で一度も使わなかった物は不用品です。 「使うかもしれない」物は不用品です。 代替が効く物は不用品です。 不用品は全て捨てました。

新しい何かを取り入れようとする時、古い物が残っていると新しい物を入れる余地が無く飽和状態になってしまいます。 水泳の息継ぎと同じですね。 古い物は捨て、物を入れ替えて環境を新鮮にします。 新生活にそぐわない家具は捨て、新しく買ってゼロから部屋を構築しなおします。

たまたま新築のマンションに引っ越せたのは幸運でした。 古い影の全くない部屋でゼロからスタートする事ができるのは、とても良いものです。

より良い新しい習慣

「健康で文化的な生活」が新生活の一つのテーマです。

元々私は決まったルーチンワークを日々こなしていく事に喜びを感じる質で、 判を押したような生活をずっと送っています。 毎日決まった時間に決まった喫茶店で作業をして帰る。 似たような食材をいつものスーパーで買って、似たようなメニューで晩御飯を食べる。

規則正しい生活それ自体は良いのですが、その規則や習慣がそもそも歪んでいると、 健康的にも良くないですし、精神環境も汚れていきます。

そこで、決まったルーチンワークを、より良い新しい習慣にごっそり差し替える事にしました。

• 毎日ゴミ捨てをする。
• 毎日運動をする。
• 毎日読書をする。
• 毎日紙とペンで物を書く。

中でも最もはまったのが「毎日紙とペンで物を書く」で、 これは引っ越す前からはじめていて半年ぐらい続けています。 是非とも他の人にもお勧めしたい習慣なのですが、 この話は長くなるので別の機会にしましょう。

上３つの習慣はまだはじめて間もないのでどうなるかは分かりませんが、 もう見るからに心と体に良さそうな習慣なので、悪いようにはならないでしょう。

日々の運動は、ジムで水泳をはじめました。 もともと泳ぎはそんなに得意な方ではなかったうえに20年ぶりぐらいに泳いだもので、 はじめた当初は無様でしたが、少しずつまともになりつつあります。

まとめ

そんな経緯で、わたしは今藤沢市で活動をはじめています。 地域の活動などにも参加していきたい気持ちでいっぱいです。 どうぞよろしくお願いします。

Web制作の現場で「黒い画面」を使うことは、近年ではごく当たり前な事になってしまいました。 フロントエンドエンジニアの方はもちろん、マークアップエンジニアの方ならば抵抗は無いでしょう。 しかし、デザイナーさんには未だに「黒い画面」は苦手意識がある方も少なくないのではないでしょうか。 その苦手意識を払拭する為に、少しばかり「黒い画面」への理解を深めてみましょう。

1. デザイナーが触れる「黒い画面」
2. 「黒い画面」ことターミナルとは
3. 「黒い画面」の基本
4. 「黒い画面」の怖い話
5. Windows環境での「黒い画面」

デザイナーが触れる「黒い画面」

そもそもデザイナーが「黒い画面」に触れる事は数年前まではあまり考えられていませんでした。 黒い画面上の作業はあくまでもバックエンドエンジニアやプログラマーの領域であって、デザイナーが触れるのはPhotoshopやIllustratorといったグラフィカルなアプリケーションまでに留まっていたと思います。

ところがWebの技術が度重なる変化・進化を遂げ、JavaScriptやCSSをビルドするようになったり、Node.jsが台頭してきたりで、プロジェクトの「黒い画面」への依存度が一気に上がってきました。 マークアップエンジニアは勿論のこと、肩書がデザイナーの人間も「黒い画面」を触れるようになる必要が出てきたのです。

例えば、こんなケースであったり

人手不足でデザインに加えてマークアップもやる事になった。 CSSをビルドする為に「黒い画面」が必要だ。

また例えば、こんなケースもあるでしょう。

プロジェクトにデザイナーとしてジョインしたが、 マークアップエンジニアが作った画面をレビューする為に「黒い画面」でコマンドを叩かなければならない。

「黒い画面」ことターミナルとは

まず「黒い画面」とは何なのか。その正体について軽く触れてみます。

Macにおける黒い画面である「ターミナル」は、GUI（グラフィカルインターフェース）によらず、 CUI（キャラクタユーザーインターフェース）、つまり文字列のコマンドでコンピュータを直接操作する為の物であると理解しておけば良いでしょう。

例えばMacでファイルを探し出すのにFinderを使用しますが、これはGUIによる機能ですね。 ターミナルでは、CUIで謎の呪文こと、コマンドを打ち込む事でそれとほぼおなじ事をすることが出来ます。 （勿論CUIなので見た目はただの文字列です） Finderをはじめとした、私達が普段パソコン上で使っているGUIアプリケーションは、ターミナルで行える処理を視覚的に見やすい形、そして操作しやすい形でラッピングされているのです。

ちなみに、MacOSXは元々Unix系のFreeBSD由来のOSで、 Unix系のコマンドの多くがそのまま使用できるのはその為です。 （Windowsについては後述しましょう）

「黒い画面」の基本

まずは黒い画面を立ち上げて触ってみましょう。 Mac環境ならば「アプリケーション」 > 「ユーティリティ」 > 「ターミナル」と辿っていけば立ち上がります。 あるいは Spotlight 検索で “term” あたりまで入力すれば出てくると思います。

ここまで「黒さ」を連呼していますが、Macでのデフォルトは白ベース黒文字の「白い画面」になっています。なんとなく、怖さが少し和らぎますね。

コマンドを入力してみる

黒い画面への入力については、キーボードで文字を入力するだけなので難しいことはないでしょう。 試しに一つコマンドを打ってみましょう。

$ whoami

[your user name]

whoami コマンドは、現在ログインしているユーザーの名前を出力します。 貴方のユーザー名が表示されましたか？

「何処」で「何」を対象に「何」するか

コマンドを覚えていく前に、次の3つの事を意識するようにしてみましょう。

1. 現在どこのディレクトリにいるか
2. そこで何をするか
3. 何を対象に行うか

例えばこんなコマンドを打ったとします。

$ mkdir myfolder

上の例では、現在いるディレクトリの中に myfolder という新しいディレクトリ（フォルダ）を作成しています。

もう少し詳しく見てみましょう。 コマンドはコンピューターへの命令であり、文法で言うところの述語です。 基本的に、コマンドは英語の文法に則っていて、述語であるコマンドの後には目的語を指定します。

この目的語は「引数（ひきすう）」と呼ばれ、上の例では myfolder が引数に値します。 つまり、 myfolder という名前で、ディレクトリを作る命令（ mkdir ）を行ったわけです。

また、命令によっては目的語を持たない（あるいは省略できる）場合もあります。

$ # ユーザー名を出力するだけなので引数が必要ありません
$ whoami
$ # 引数を省略すると、ユーザーのホームディレクトリに移動します
$ cd

さらにまた、目的語を二つとる命令もあります。

$ # 目的語1（foo.txt）を、目的語2（bar.txt）として複製する
$ cp foo.txt bar.txt

ファイルやディレクトリを引数にする

先程言ったように、コマンドには目的語である引数を渡す事が多いのですが、 その引数となるのはファイル名やディレクトリ名がほとんどです。

$ rm ./needless.txt

上の例では、今いるディレクトリにある “needless.txt” という名前のファイルを削除しています。 ファイル名の前についている “./” は一体なんでしょうか？ これは「今いるディレクトリにあるファイル」という事を明示的に指定しています。

Unixのファイルシステムでは、ファイルの場所（パス）について次のような表現を用います。

• “.” … 現在のディレクトリ
• “..” … 一つ上のディレクトリ
• “/” … ディレクトリの境目
• 一番頭が “/” … ルートディレクトリからの絶対パス

つまり上の例では、「現在いるディレクトリ下にあるneedless.txt」を指定しているわけです。

ここで「”./”は要らないのではないか」という疑問が浮かんだのではないでしょうか。 その通り、”./” は省略でき、次のように表現しても同じ処理を行います。

$ rm needless.txt

省略できるのならば、なぜ例示でわざわざ “./” を付けたのかというと、その方が安心出来るからです。 ファイルを指定する時は、”./” や “../” からはじまる相対パスで表現する事をお勧めしたいです。

特に、上で例に挙げている rm コマンドはファイルやディレクトリを削除してしまう破壊的なコマンドです。 必ず “./” ではじめる事を意識すれば、現在いるディレクトリを誤ったり、朦朧としながら作業をしていて操作ミスをしたりして、処理してはいけないファイルを処理してしまう危険性をわずかばかりではありますが、和らげる事ができます。

$ rm /the/path/to/target # NG
$ rm target # NG
$ rm ./target # Good

「どのように」行うか（オプション）

多くのコマンドは、「オプション」を渡すことで挙動をコントロールする事ができます。 ここでは ls コマンドを例に上げてみます。このコマンドは、ディレクトリ内にあるファイルをリスト表示してくれます。

$ ls
bar.txt         directory       foo.html

何もオプションを渡さない場合、ただファイルの名前のみが羅列されます。 ファイル名だけだと情報が足りないので、l オプションを追加してみましょう。

$ ls -l
total 16
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html

色々な情報が詰まったフォーマットで出力されました。 さらにドット（”.”）からはじまる隠しファイルも表示する為に、くわえて a オプションを指定してみます。

$ ls -la
total 16
drwxr-xr-x@ 6 mach3  staff  204 12 12 16:19 .
drwxr-xr-x@ 8 mach3  staff  272 12 12 16:01 ..
-rw-r--r--@ 1 mach3  staff    0 12 12 16:19 .hidden
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html

またさらに、t オプションを追加して更新時間順にソートしてみましょう。 （デフォルトでは名前順です）

$ ls -lat
total 16
drwxr-xr-x@ 6 mach3  staff  204 12 12 16:19 .
-rw-r--r--@ 1 mach3  staff    0 12 12 16:19 .hidden
-rw-r--r--@ 1 mach3  staff  248 12 12 16:03 foo.html
-rw-r--r--@ 1 mach3  staff  212 12 12 16:03 bar.txt
drwxr-xr-x@ 2 mach3  staff   68 12 12 16:02 directory
drwxr-xr-x@ 8 mach3  staff  272 12 12 16:01 ..

オプションを指定するルールがお分かりいただけたでしょうか。 オプションは主に1文字の英数字や短い言葉で指定し、 ダッシュ（”-“）の後ろに続けて打ち込む事で複数のオプションを合わせて利用する事ができます。 （このルールに則らないコマンドも存在するのでご注意ください）

各々のコマンドは、それぞれのオプションを持っています。 とても全てを覚えきれる物ではないので、その説明は次回に持ち越す事にします。

「黒い画面」の怖い話

「黒い画面は怖くない」と言いたいところですが、残念な事に「黒い画面」は怖いのです。

GUIのアプリケーションで警告が発せられるような処理でも、「黒い画面」は警告を発してくれません。 GUIのアプリケーションなら行わないような危険な処理も、「黒い画面」は実行してしまいます。 良く知らないままにコマンドを実行して、環境を壊してしまうなんていう悲劇も往々にしてあり得る事です。

うまく動かないからネットで検索したコマンドコピペして実行したら、パソコンが起動しなくなった

ジョークみたいな話ですが、実際に私の観測圏内で起こった出来事です。

ネットで拾ったコマンドを調べずに実行しては絶対にいけません。 コマンドがどのような処理を行う物なのか、渡している引数は何なのか、どのようなオプションで実行されているか、コピーしたコマンドはつまるところどういう命令なのか、 それらを調べて理解したうえで実行しましょう。 そして、インターネットは怖いところだという事を肝に銘じておきましょう。

Windows環境における「黒い画面」

Windowsにおける「黒い画面」は「コマンドプロンプト」と呼ばれる物ですが、これはおすすめできません。 WindowsはUnix由来でない為、Macで使えるような基本的なコマンドも使用できず、そもそもコマンド自体が非常に少なく、使い勝手がよくないのです。 「他と違う」という事は、つまり問題が起きた時に調べても解決策にたどり着きにくいという事です。

いくつか代替の手段があるので、そちらを使うようにした方が良いでしょう。

1. Git Bash

Windows環境で開発作業を行うのならば Git for windows は恐らくインストールされているはずなので、 これにバンドルされている「Git Bash」を活用します。 インストールされてない場合は、インストールしましょう。Gitはもはや開発環境に無くてはならない存在です。

Git Bash は msys と呼ばれるエミュレータで動いており、いささかLinuxやMacとは使い勝手が違いますが、基本的なコマンドは使用する事ができます。 （msysは、昔なつかしのcygwinからのフォークです）

Git Bashのメリットは、Windowsにおける実行ファイル（.exe）が容易に呼び出せる点です。 ショートカット（.lnk）もちゃんと追随してくれるので、「好きな名前で好きなアプリを立ち上げる」なんていう設定も簡単にできます。（ここでは説明は割愛します）

$ # 現在いるディレクトリでエクスプローラーが立ち上がります
$ explorer .

2. Bash on Windows

Windows10ならば、Windows上でUbuntuが動作します。 Windows Subsystem for Linux（WSL）と呼ばれる仕組みで、まさにLinuxがWindows上で動作していると思って良いでしょう。

中身はUbuntuなので、apt で楽々パッケージを追加インストールできるのが大きな魅力で、 参考になる情報もネットで収集しやすいです。

• Bash on Ubuntu on Windowsをインストールしてみよう！ – Qiita

前編まとめ

• デザイナーも「黒い画面」が必要な時代になった
• 「黒い画面」の基本的な使い方を学ぶ
• 「黒い画面」は怖いので用法を守って正しく使う
• インターネットの情報は鵜呑みにしてはいけない
• Windowsでの「黒い画面」は Git Bash または Bash on Windows を活用しよう

後編では最低限覚えておくと捗るコマンドと使い方を書くかもしれません。

アップデートのきっかけ

LESSTESTERを見直すきっかけになったのは、StackOverflowで「バージョンが古い。5年前のバージョン。（意訳）」と言及されていたのを見かけた事。 実際は、Less v1.7.0が出たのが2014年2月でLESSTESTERアップデートが翌3月なので3年しか経ってない事をここに釈明しておきます。 しかし、Lessのバージョンがv2.7.2まで上がっている間ずっと放置してしまったのは反省しないといけませんね。

cf) https://github.com/less/less.js

本当はLessユーザーも希少な様子なので閉めようかとも考えましたが、 せっかく公式にも取り上げてもらっていた事ですし、 案件で得られた経験値を試すついでにまるっと作り直してみようと思いました。

そして出来たもの

新しくついた機能 :

• ドラフトが端末に保存できるようになりました
• Lessのバージョンを選択できるようになりました
• キーマップに sublime が追加されました
• リアルタイムコンパイル

新しくつけようと思ったけどやめた機能 :

• URLでシェアする機能（理由 : コストのわりに使われ無さそう）

活用した技術など :

• Vue.js – https://jp.vuejs.org/
• AWS S3の静的サイトホスティング
• AWS Route53 + CloudFront でSSLに対応
• （おまけ） さくらのメールボックス

感想

ゼロから組み直したにしては、AWSとVue.jsが大変便利だったおかげで短時間で完成しました。

Vue.js

現在進行系で進んでいるプロジェクトで使っているのですが、 低い学習コストのわりに高機能かつ使い勝手が良く、規模問わず動的なWebアプリケーションを作るのに大変便利です。

AWS S3

言わずと知れたS3さんは便利すぎる。 もう全部これでいいんじゃないでしょうか。

AWS Route53 + CloudFront

SSL対応がこんなに簡単で安価になるとは、時代を感じます。 CloudFrontは高機能である反面、デプロイと変更の適用で結構待たされるので、いろいろな設定を試す段階ではちょっと辛い部分はありました。

また、今回は使っていませんが API Gateway / Lambda / RDS あたりは触る機会がどんどん増えていくのではないかなと思っています。

さくらのメールボックス

SSL対応の際にドメイン所有者の確認のためメールが送られるので、それを受け取る為に使いました。 年額1000円程度で複数ドメインを使用できるのでかなりリーズナブルです。 メールサーバの構築はなにかと面倒なので、ぜひ利用していきたい選択肢ですね。

セキュリティ対策を強化したメールサーバー専用プラン【メールボックス】

まとめ

お買い物もホビーも開発もAmazonに依存する時代の到来です。 それぞれのリソースについては時間があれば追って使い方などを記事にまとめておきたいところです。