片手間にui componentsの使用感を試そうとしてやってみたことのメモ

片手間フロントエンドの人が、ui componentsの使用感を試すためにやろうとしたことのメモ。

はじめに

試そうとしたのは、reactのui components。以下2つ。

  • evergreen
  • tableau-ui

evergreen.segment.com github.com

テキトーにこの2つを選んだ。特にこだわりはない。まだこれら2つを使うと決めたわけではなく選考対象に乗せて使用感を試そうとしたくらいのステータス。

ちなみに選定基準は以下の2つ。

  • CSS書きたくない。
  • できればtagを書くだけでおしまいにしたい(web components的な)

そこそこ良い感じになっていれば良くて、細かな調整ができなくても良い。 まぁどれを選んだかは本題ではない。

使用感を試すために手元の環境で実際に触ってみたいというのがこの記事の趣旨。

触る方法

ちなみになぜ触りたいかと言うと、storybookなどを覗いて例を見るだけだと正直使用感のようなものがわからなかったから。

そして手元の環境で触ると言っても2通りくらい方法があるかもしれない。

  • ビルドを許容する方法 -- とりあえずビルドしても良いけれど。手間を少なめにしたい。
  • ビルドを許容しない方法 -- ビルドしたくない。絶対にビルドしたくない。

前者と後者の違いはnpmの環境を作るかどうか。別の言い方をするとビルドを許容するかどうか。

ビルドを許容する方法

ビルドを許容する方法はparcelを使うのが楽そうだった。

npmが存在する環境で以下の様な感じにやっていく。今回はevergreen-uiの方を試す。参考になりそうなページはparcelのreactのレシピ

$ npm init
$ npm install --save react react-dom
$ npm install --save evergreen-ui
$ npm install --save-dev parcel-bundler

package.jsonに以下を追加する。

  "scripts": {
    "start": "parcel serve index.html"
  },

あとはindex.html,index.css,index.jsをテキトウに書いて動かす(後述)

$ npm run start

> parcel serve index.html

Server running at http://localhost:1234 
...
✨  Built in 11.20s.

初回とはいえ10秒も掛かるのは毎回コレを動かすのは辛くなりそう。

表示された (hello world)。

f:id:podhmo:20191211183107p:plain

細々と思ったこと

  • 10秒も待ちたくない

watch (ファイル監視してのauto build) の機能がありそう。ただしこれはこれで現在の自分ののエディタ設定と相性が良くないかもしれない。自動でファイルを保存する設定と相性が良くないかもしれない。

あるいははもう少しparcelの中を覗いて小さくしたくなるかもしれない。

files

このとき作ったファイルのgist

https://gist.github.com/podhmo/92114a4fb7d486b7cd0035c41493eb51

index.js

import React from 'react'
import ReactDOM from 'react-dom'
import { Button } from 'evergreen-ui'


ReactDOM.render(
  <Button>I am using 🌲 Evergreen!</Button>,
  document.getElementById('root')
)

index.html

<!DOCTYPE html>
<html>
  <head>
    <title>Evergreen sandbox</title>
    <link rel="stylesheet" href="./index.css" type="text/css" />
  </head>
  <body>
    <div id="root"></div>
    <script src="index.js"></script>
  </body>
</html>

index.css

body {
    padding: 5rem;
}

Makefileからの実行

毎回package.jsonを作ってnpm startとやるのもめんどうなので同一パッケージ上でやる方法も少し調べた。npm installすると ./node_modules/.bin/parcel が存在するようになるのでコレを直接使う。

00:
    ./node_modules/.bin/parcel start $@index.html
01:
    ./node_modules/.bin/parcel start $@index.html
02:
    ./node_modules/.bin/parcel start $@index.html
03:
    ./node_modules/.bin/parcel start $@index.html

こんな感じに雑に書いてあげるとmake 0000index.htmlを利用する画面を確認できる。

とりあえずで使用感を試すときには幅優先的に探索をしたいので1つ前の状態を共有して色々試せるという環境が欲しくなる。

ビルドを許容しない方法

今度はビルドを許容しない方法。正確に言えばビルドを許容しないと言うよりはブラウザで完結させたいというような意味。色々調べてみるとunpkgを使う方法が見つかった。

unpkg.com

unpkg.com

unpkg is a fast, global content delivery network for everything on npm. Use it to quickly and easily load any file from any package using a URL like:

unpkg.com/:package@:version/:file

はい。

今度はindex.html一枚でやる方法を探してみる。evergreen-uiはちょっと例として適切ではなかったかもしれない。これを例にやろうとしたらめんどうだった。tableau-uiで試すことにする。

f:id:podhmo:20191211183154p:plain

具体的にどうめんどうだったかと言うと、jsのモジュールの種類としては以下の3つがあるらしいが、UMD形式のファイルがnpmリポジトリに直接入っているもの以外では手軽に扱うことができなそうだった。

UMDと言うと分かりづらいかもしれないけれど。全てのファイルを1つにまとめたもののこと。bundleされたもののこと。

詳しい話はこの辺りを参考にすると良さそう。

unpkg.com でtableau-uiを取り出そうとしてみる。

unpkgがいい感じに特定の形式のパスへとリダイレクトしてくれる模様。

$ http -b GET https://unpkg.com/@tableau/tableau-ui
Found. Redirecting to /@tableau/tableau-ui@2.2.1
$ http -b GET https://unpkg.com/@tableau/tableau-ui@2.2.1
Found. Redirecting to /@tableau/tableau-ui@2.2.1/./dist/tableau-ui.min.js
$ http -b GET https://unpkg.com/@tableau/tableau-ui@2.2.1/./dist/tableau-ui.min.js

ここで tableau-ui.min.js のものがUMD

index.htmlだけでhello world

unpkg.comを使うことでindex.htmlだけでhello worldすることができそう(中身は後述)。1つのファイルだけで済む。

基本的には以下の通り。

  • babel-standaloneを読み込んで、text/babel以下に書いたscriptタグのjsxを変換できるようにする
  • umd形式のものを読み込んでテキトウにprefix付きで使う (e.g. const Button = TableauUI.Button;)

細々と思ったこと

細々と思ったのは以下のようなこと

  • unpkg.comが重たい場合はキャッシュしたいかもしれない。
  • es6モジュールの形式のものも上手にhtmlを書いてあげれば上手くできたりしないんだろうか。
  • (babel-standaloneの形式が古くなったりすることはないんだろうか?)

files

gist

https://gist.github.com/podhmo/f2d623b474b8518f28f16d25d4172168

00index.html

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <style type="text/css">
      body {
          padding: 5rem;
      }
    </style>
    <script src="https://unpkg.com/react@16/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"></script>
    <script src="https://unpkg.com/@tableau/tableau-ui"></script>
    <script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>
<script type="text/babel" defer data-presets="es2015,react">
const Button = TableauUI.Button;

function App(){
  return <div>
    <section><h2>enabled</h2>
    <Button>I am using tableau-ui</Button>
    <Button kind="primary">I am using tableau-ui</Button>
    <Button kind="outline">I am using tableau-ui</Button>
    <Button kind="destructive">I am using tableau-ui</Button>
    </section>
    <section><h2>disabled</h2>
    <Button disabled>I am using tableau-ui</Button>
    <Button disabled kind="primary">I am using tableau-ui</Button>
    <Button disabled kind="outline">I am using tableau-ui</Button>
    <Button disabled kind="destructive">I am using tableau-ui</Button>
    </section>
</div>
}

ReactDOM.render(
  <App/>,
  document.getElementById('root')
)
</script>
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

misc

unpkgを手元で動かすのはどうするんだと調べてみた所。unpkg-serverなるパッケージがあるらしい。

この辺りのissueで紹介されていた。

-Self hosting? #98

コレを使ってunpkg.comの実行をwrapできないかとおもってテキトーなproxyをgoで書いた。こういうことが手軽にできるのはgoの強みだなーとは思う。今回は標準ライブラリしかまだ使っていない。

https://gist.github.com/podhmo/24e0cdb4d3a1288f59ba826f6925a09b

ただしまだnpmのregistryへのcacheが上手くできていなさそうで中身を見る必要があるかもしれない。

まとめ

ちょっとしたui componentの使用感を確認してみようとして幾つかのreactのui componentを試してみた。試す方法として以下2つの方法があった

  • ビルドを許容する方法
  • ビルドを許容しない方法

ビルドを許容する方法では、もう少しビルドの時間を短くしたいとおもった。なので課題としてはparcelの中身を覗くことやwatchと現在のエディタ設定との折り合いを付ける事。

ビルドを許容しない方法では、UMD以外の形式でのui componentsを試す方法を調べたいとおもった。後はキャッシュしてもう少し早い感じでできないかを試したかった。もしくは手元でビルドする環境のdocker imageを作ってあげてそいつにproxyしてあげればどうにかなるのかなーなどとおもったりした。

それぞれのgistはこのあたり

blogとの付き合い方について あるいはなぜ自分がblogを書き続けているかについて

この文章は write-blog-every-week Advent Calendar 2019 の 7日目の記事です。

TL;DR

  • (ほぼ)毎週blogを書いている
  • advent calendarへの参加のついでに自分とblogとの付き合い方についてまとめてみた
  • 自分の頭の中を再現することを重要視しているらしい
  • What are you doing?

write-blog-every-week?

write-blog-every-weekとはその名の通り「毎週blogを書こう」という集まりです。基本的にslack上で活動しています。

このグループの発端は @kojirock5260 さんのこの記事で分かりそうです。

勢いで週一blog書くslackグループを作った

基本的には以下に書かれていることの通りです。

とりあえず細かいルールはなしで 週イチでblog書く。 書けてなければ煽る。 書いた際は褒める。

ちなみに最近はあまり煽る煽られるようなことが少なくなり。blogを書く。褒める。の2つだけになってきている感じはします(良いと思います)。

他のメンバーがどういう気持ちで参加しているかなどはこの記事あたりが参考になるかもしれません。

ちなみに、どんな人がいてどんなことを書いているかはこの辺りを覗いてみると良いかもしれません。参加メンバーの最新の記事の一覧が見られます。

自分とblogの付き合い方について

あまりこういう経験はなかったのですが、ちょうど良い機会だったので、とりあえず、自分自身のblogとの付き合い方のスタンスについて説明して見ようと思います。大まかにまとめると以下のようでした。

  • 色々な人がいるし、居て良い
  • 閉じた文章・開いた文章
  • 自分のblogは内向的な閉じた文章

ちょっと何を言っているのかわからないと思うので順に詳しく話そうと思います。

色々な人がいるし、居て良い

まず色んな人がいるは、blogを書く行為に対して求めるものが人それぞれで違うということです。まぁ当たり前ですね。

例えば人の種類を大雑把に外交的な人と内向的な人の2つに分けて話すことがありますよね。それに擬えて話すとすると、blogをどの立場の人に向けて発信しているつもりか?という立場の違いがまずあると思っています。

例えば以下の2つのようなイメージです。大雑把ですが。

  • 外交的なblog -- ブランディング。何らかの評価を得るための活動。他者のため。
  • 内向的なblog -- 頭の整理。自分のため。

この分け方で言えば、自分のblogは内向的なblogです。

閉じた文章・開いた文章

もう少し詳しく見ていきます。自分はblog記事の執筆という行為を「頭の中にあるものを何らかの外部表現に変換すること」というように解釈しているようでした。しかし実際のところはそのblogを書くという行為ももう少しステップがあるような気がします。

具体的には以下の通りです。

  1. 出力 -- 頭の中から外部表現への変換。
  2. 整形 -- 外部表現を想定読者に伝わりやすい形に変換
  3. 伝搬 -- 外部表現の中身を実際に普及伝搬させる

「出力」と「整形」の2つの違いが少しわかりにくいかもしれません。自分の頭の中にあるものをそのまま文章として出力することが「出力」だとすると、「整形」は自分だけに向けた文章を他の人にも向けた理解可能な表現あるいはより一般的な表現に整形したり編集したりする行為のことを指しています。

「伝搬」はblogの運用という風に言い換えられるかもしれません。マーケティングブランディング

外交的なblogという立場の人はこの「出力」「整形」「伝搬」の全てに重きを置いている一方、内向的なblogという付き合い方の自分はどちらかと言えば「出力」1つだけに重きを置いているという感じです。

開いた文章・閉じた文章

ここまで文章を読んできて 違和感 などを感じたりしませんでしたか?

もし感じたとしたら、それはおそらくある特定の概念を指すときに利用する言葉をより一般的な表現に直せていない部分があるからだと思います。極論を言えば、自分にだけ向けられた自分だけが分かる言葉を使って綴られた文章だからです。これを「自分語」を使っていると表現することにします。

「自分語」は、今、この記事のためだけに作られた自分語です。少しトートロジーっぽいですが。一般的には「1者言語」と呼ばれているらしいです。1人しかユーザーの居ない言語というわけですね。ちなみにもう少し範囲の広がった家族のみで通じるような言語などを「ハウスワード」や「2者言語」と呼ぶようでした(あまり詳しく調べていないのでもう少し正確な表現が後になって定まるかもしれません。その場合は後で追記などするかもしれません)。

余談はこの辺にして、この言葉に当てた分類の類推をより範囲を拡大して文章に当てはめると、誰に向けた文章か?ということになります。

また「有難う御座いました」という表記を「ありがとうございました」という表記に変換することを「漢字をひらく」と表現するようなのですが。ちょうど冒頭の外交的・内向的というペアとネットワークが開いている・閉じているという感覚が近しいと感じたので、この分類を当てはめて以下の様に便利に使っています。

  • 閉じた文章 -- 自分ないしは仲間内だけに通じる特殊なエンコーディング
  • 開いた文章 -- 一般的な消費者がデコード可能な表現に変換されたもの

つまり、自分にだけ向けた閉じた文章を、読み手一般に分かるような表現やより自然な表現つまり開いた文章に変換する行為のことを「整形」と表現していたのでした。

もう少し言葉を変えると、文章は、頭の中にある何かを内部と表現するとすると、実世界という外部に出力された結果(媒体)と見做すこともできそうです。より一般化して「文章」を「外部表現」と表記することもあったりします。

わかりやすくたとえるなら、作曲と編曲の関係に近いかもしれません。頭の中で発生した曲を再現可能な形式に出力するのが作曲だとしたら、売れる表現あるいは耳馴染みの良い形に合わせるようなアレンジを加えるのが編曲というような意味合いです。

自分のblogは内向的な閉じた文章

改めて今までの事柄をまとめると、自分のblogは内向的な閉じた文章ということになります。

一方で、日常的にコードを書くような人なら、こういう言葉が耳をかすめると思います。「N日後の自分は他人」と。これについてはおそらく後で触れます。

自分にとってのblog

先程までで自分とblogの間の関係性についてはまとめてみたので、今度は自分にとってのblogとは何か?についてもまとめてみることにします。

備忘録

自分にとってこのblogは何か?と聞かれたら、おそらく一言「備忘録です」と答えると思います。この備忘録とは以下の様な意味です。一応辞書を引いてみます

忘れたときの用意に用件などを書きとめておく帳面。メモ。

そうそう、忘れたときのためのメモです。

コレをもう少しまじめに解釈すると以下の2つの場合があります。

  • すぐに忘れてしまうもののメモ
  • すぐに忘れてしまいたいもののメモ

どちらも同じで頭のリソースは有限なので外部出力しておきたいという意味なのですが、取扱の仕方が少し違います。前者はよくあるリスクに備えての予防策的な運用で、後者はどうでも良い些末な出来事など忘れてしまって綺麗な頭の状態で考えていたいというより積極的な運用といえるかもしれません。

備忘録なので思い出せれば良いということです。記事単体の質それ自体よりはソレが出力されるまでのコストにより意識を割いているような気がします。例えばこれには精神的コストも含まれます。なのでなるべく手軽な付き合い方が良いということになります。

つまり自分にとってblogとは外部記憶装置というわけです。一方でコレを上手く利用するために必要な能力というものもあります。

備忘録に期待しているのは「再現」すること

blogが外部記憶装置だとすると、blogを書くという行為を、内部表現の外部化と表せるかもしれません。また、過去の自分がやっていたことを思い出すという行為は、外部表現を読み込みその当時の内部状態ないしは視界を再現すると表せそうです。

ここで必要になるのが、頭の中にあるものをblog上に落とし込む能力です。これを高めたいあるいは維持しておきたいと思っているようでした。

ここで大切なのは、欲しい能力はたしかに言語化能力なのですが、質の高い表現を求めてウンウンと唸りながらクオリティの高い記事の執筆を行うと言った種の言語化能力ではないです。通じれば良い程度のフォーマットで忘れないうちに書ききるための能力です。大切なのは再現できることです。saveとloadが上手くできればそれで良いという感じです。

そんなわけで(そんなわけで?)基本的にblogの記事を書く時には、当日その場で記事を書き上げて公開しています。下調べなどをしたりすることはありますが記事の下書きを書いて寝かせるというようなことはしていません。

意外と文章は書かないと書けなくなるような体感もあったりするので、どうでも良さそうな内容の記事でもなるべく書ききって公開していたりします。15分から30分くらいでどうでも良い記事が書けるという状態は維持したい気持ちがあります。この辺りにwrite-blog-every-monthに所属することのメリットがあるように感じています。

求めていたのは「瞬発的な文章化能力」

たしかに言語化能力の向上や維持を期待してblogの執筆を継続しているのですが、その能力は結果からみてのそれ、つまり成績みたいなものがあってそれが上がった下がったで一喜一憂するものというよりは、どういう体験を継続したいか?ということのような気がしています。

もう少し自分が何を望んでいるかの詳細について頭を巡らせていこうと思います。

一般的によく見られるような言語能力というと暗に以下を含んでいるような気がします。

  • 予測や計画を上手に行う能力(なぜか含みがち)
  • 決められた事項やルールを適切な言葉で表現できる能力
  • 不確かな表現から相手の意図を汲み取って理解できる解力
  • 相手を意に沿うように動かすために言葉を弄する能力
  • 詳細な事項を漏れなく記述し長期間メンテするドキュメンテーション能力
  • 必要以上にことを大きく見せたり、自分へのダメージを最小限にするために言葉をコントロールする能力

この辺は含んでいないです。繰り返しますがこの辺は含んでいないです。

とりあえず言語能力ではなく言語化能力なのでwrite性能だけです。出力されるフォーマットの多様性にも対応する気は無いので最悪1つのフォーマットで出力できれば良いです(自分語の閉じた文章)。

また基本的に自分の記事は書き捨てです。ある時点でのスナップショットです。それ自体にすべての情報を含んでいないのでスナップショットの断片程度かもしれません。何かのドキュメントのようにメンテし続けるような種の記事でもないです。つまりストック情報ではなくフロー情報です。

自分にとっては、自分の自分による自分のためのそこで文章を綴ったときの頭の状態が再現可能な文章が備忘録です。そこで求める能力は言葉にするなら「瞬発的な文章化能力」とでも言えば良いのかもしれません。ただし韻を踏んだり雅であったりする必要は全く無いです。

理想的な話 DRYとWET

ここからは理想的な話、今はできていない行為の話もしておきます。自分自身がblogに求めているものは「頭の中の再現」だったわけですが。この頭の中を以下2つのものに分けることができそうです。

  • DRY -- ある事柄を再現するための手続きの記述
  • WET -- ある心理状態や思い出当時の気持ちを再現するための手記

実はこのDRYやWETの分類は自分が考えたものではないです。@otiai10さんという方がこの2つの言葉を使って2つのblogを書いているようでした。 。

個人的にはその内容も考え方もとても好意的に見ていて隠れて尊敬していたりしています。DRYが乾いた無味乾燥な出来事ということとDRY (= Don't Repeat Yourself)と多重定義されている感じで小洒落てますね。

ちなみに補足しておくと、先程のDRYとWETの意味は自分自身の勝手な解釈のまとめであって元の意味合いからは少し歪んだものになっているかもしれません。

WETな方々 (ジメジメしているという意味合いじゃないです)

基本的に自分の記事はほぼDRY一辺倒なのですが、本当はこの文章もWETな媒体の方に書きたいなと思っていたりしています。ただWETなもの一般が基本的に苦手なんですよね。。

(例えばゲームで最初に3つのうちから好みのものを選んだりだとか、好きな色はなんですか?みたいな問いに答えるだとか、自分に向き合うこと一般がとても苦手だったりします)

そんなわけでWETな状態のdumpが上手にできる人を尊敬していたりもします。例えば @otiai10 さんもその1人です。

あと心情の言語化という意味で尊敬している人がもう2人居ます。

@shinpei0213 さんと

@Piro_or さんです

shinpei0213さんはその時そのタイミングで自分自身がどの様に考えているのかをdumpするのが上手な印象です。Piro_orさんはある問題について自分はこう考えるということの表明とその背景説明がとても上手な印象です。

自分自身はどちらの部分のdumpも基本的にはおざなりになっている状態だったりします。

理想の話

ちなみに言語化という意味で一番尊敬している人は @shiroさんだったりします。GaucheというSchemeの処理系を作っている人なんですが、SICPとか読んでいた頃からわりと遠くから眺めてすごいなーと尊敬していたりしていました。

文章だけでなく一緒に付いてくる思考実験などもとても面白くてすごいなーと思ったりしていました。

blogの内容について

これまでblogと自分の関係性、自分にとってのblogの存在意義、についてまとめたので、次はblogの内容についてもまとめてみようと思います。

以下が自分自身のblogに求めているものです。先程までに挙げたものを繋げたものに幾つか新しいものが加わっています。

  • 自分の頭の中にあるものを言語化したい
  • これはドキュメンテーションスキルでも計画のための能力でもない
  • 言語化できているなら再現できるはず。再現できたとはなにか?
  • 再現のための練習とは何か?
  • どうやって練習をしているか?

どうであれば言語化できたと言えるのか?

基本的には自分の頭の中の具現化をしたいわけですが、幾つかの場合では自分の理解の具現化ということになります。どうであれば言語化できたと言えるのでしょう?

ここでの理解ができたとは、ある何らかの行為を成功させることを指します。仮想的な何らかの処理系をイメージしてもらって、それを実行したら望みの結果が手に入る、という状況を自分自身を何らかの処理系に見立てて可能にするみたいな意味です。

最も丁寧で抽象度が低い状態の例の1つは「手順書が作成できた」というような状態です。本当はもう少し粒度に違いがあるのですが、すごく丁寧で具体的な一例はそれです。

書きたいものはドキュメントではない

それでも作りたいものはドキュメントではないのです。体験のログのようなものです。説明ではないのです。日々メンテされるような権威のある意味や仕様を表明するものではないのです。「こういうときにこうだった」と言うような記録です。

そして学習のログであるという所も大切です。あるいは途中段階の進捗報告です。

とはいえ、過去の自分は他人でもあるわけです。あんまり雑な表現でも何を言っていたのか当時の状況を思い出すことができません。修飾のための語彙などは自分自身であるのである程度一貫性を持っていそうな気がしますが、特定のツールの名前や用語などは覚えておきたくありません。それこそ備忘録なので。名前だけ分かっても検索などひと手間加えるのがめんどくさい、あるいはその時参照したかった関連が一対多で1つに定まらないということもあったりしそうです。

そんなわけで出力のための精神的コストは安く抑えようとしているものの、なるべく利用する言葉へのリンクなどは欠かさず付けているつもりです。参考文献のリストまでは凝って付けてはいないです。

スキルは「再現性」のalias?

個人的にはスキルのことを「再現性」の言い換えだと思っているところがあります。例えばある場所に所属していた人が別の場所に移動した時に、以前の場所で手にしていた体験や仕組み行為や環境が「再現」できるかということをスキルだと思っているようです。それ以外は基本、頑張りと運です。

あるいは、何かの概念を獲得したとは、その概念が組み合わされたネットワークの一部を自分の実装に置き換えてそれでも尚動作が継続されるというようなことを指しています。例えばの一例としては、あるフレームワークのある機能を独自の実装に差し替えてそれでも動くというのがある機能を理解したということになるような気がしています。あるいはその機能の最小限を定義することがその機能という概念の獲得ということになるのだと思っています。

例えば、エラーの解消などについても同様のことが言えるかもしれません。手元の環境の複雑な依存の中で何らかのエラーが発生したとします。そのエラーを解決するために例えばどこかのフォーラムで質問してみることになると思います。そのとき求められるのは、同様のエラーが再現する最小限のサブセットです。この最小限のサブセットが作れるかと自分自身が書いたコードの意味を理解しているかがだいぶ近しい関係にあるように思います。大げさに言えば再現できれば半分解決できたようなものです。

そういうわけで、何かを再現しようとする行為を一種の学習だと認識しているところがあります。

学習の練習の学習

とはいえ、再現性と言った所で、既にカタログに書かれているような手順をなぞるだけだったり、それこそ手順書の通りに実行していくのは退屈で死にたくなります。労です。ツール労です。労はお仕事だけで十分です。そんなことに余暇の大切な時間を消費したくはありません(個人の意見です)。

加えて、自称でも良いのですが何か天啓を得たというようなエバンジェリストでもないですし、どこかの熱心なファンやフォロワーというわけでもありません。あの種の人々には尊敬の念もありますが、どこか異世界の人間だなというような感覚を覚えます。そのような人々の場合は、例えば、環境の変更などがあったタイミングで、今も尚同様の動作をするかなどの検証をしたりするのかもしれません。あるいは単純に新機能にワクワクして動作を試してみたりだとか。まぁ無理です。同じような行為をなぞる事はできそうにありません。

ログを残したいということは学習したいということなのですが。ログを残す価値があるとは現在と未来で差分が出るということです。何か差分が欲しいですよね。

差分を手にするために

ブログに何を書こうか?と考える時に、ときどきジョハリの窓の変形を使っていることに気づきました。

ジョハリの窓というのは学校で習うような有名なやつです(ちなみにこの辺で絵や図を用意する行為が「整形」というやつですね。やりません)。本来は自己に対する、他者あるいは自分の理解への表ですが、以下の様なものです。

  • 1 . 解放の窓(自分は分かっている、他人は分かっている)
  • 2 . 盲点の窓(自分は分かっていない、他人は分かっている)
  • 3 . 秘密の窓(自分は分かっている,他人は分かっていない)
  • 4 . 未知の窓(自分は分かっていない,他人は分かっていない)

これを例えば以下の様な形に変形します。

  • 1' . 既知の窓(自分は知っている,知っている人はいる)
  • 2' . 自分にとっては未知'の窓(自分は知らない,知っている人はいる)
  • 3' . 探索結果の窓(自分は知っている,知っている人が見つからない)
  • 4' . 未知の窓(自分は知らない,知っている人が見つからない)

キモは4'から3'の横のラインと2'から1'の横のラインです。4'ではなく2'を選ぶことも意図的です。コレは誰も知らないものの一部は難しい研究対象になってしまう可能性があるからです。スキルを伸ばしたいという意味での再現を試みたい場合には、必ず成功できることが確約されたものの追試をやってみるのが良いです。

あるいはもう少し再現の方法を変えて、あるブログの記事を読んで、自分が理解した時に、「その記事を頼ることなしに同様の記事を構成する事は可能か?」というようなことを考えていきます。あるいは特定のOSSのissueにたどり着いて解決した時に、あるいは特定のOSSの実装コードにたどり着いた時に。「それへの依存を無くしてそれでも尚再現することが可能か?」ということを試すのが理解の醸造に良いような気がしています。

大学の学部で古典的な問題を扱うという話に近いかもしれません。

もちろん、厳密に言えば、以下の部分を気にする必要があります。

  • (厳密に言えば、知っている、理解している、利用できる、応用できる、体得しているというような段階が存在している)
  • (厳密に言えば、知っている・知らないの以前に実現可能性の話がでてくる)
  • (厳密に言えば、知っている人が見つかるという言葉の度合いも異なる)

本当は4'から3'をやりたいですよね。。

それなりによく書けたかもと感じた今年の記事の例

最後に自分にとっての良い記事の例を挙げておこうと思います。どういう記事を書きたかったかあるいはどういう記事を書くような人と付き合いたいと思っているかの参考になるかもしれません。

そこそこ丁寧に表現できたなーと思う記事はこのあたりです。

あと、それなりに自分自身の思考内容をdumpできたかなと感じたのはこのあたりの記事です。

とはいえ軽いものがあっても良いし。実際そういうものがたくさんあるべきです。そういう記事は後々カロリー高めの記事を書くための弾みを付けてくれるような気がします。

完全な備忘録としてはこの辺りをたまに自分で見返したりしてました。