bouzuya.hatenablog.com

ぼうずやのにっき

2018-W49 ふりかえり

2018-W49 をふりかえる。

2018-W49 の目標 とその記事

目標。

  • ☑ mockmock.dev の時間の見直しのことを書く
  • ☑ bouzuya/purescript-react-basic-contacts 1.0.0 をつくる
  • ☐ bouzuya/yzrh 0.1.0 をつくる

記事。

目標。おおむね達成。 bouzuya/yzrh はコマンドラインオプションの解釈部分だけが進んでいるため未達成。

週の目標の確認 (2018-12-02) は「毎朝その日の計画を立てる」という日課に含めることで解決している。継続できるかは分からない。

つくったもの

2018-12-03/2018-12-09

今日は mockmock.dev #194 で purescript-react-basic-bbn-viewer 0.1.0 をつくった。

yzrh のコマンドライン引数の関連で PureScript の型レベルごにょごにょをしている。

よんだもの

2018-12-05 でいろいろと本を買ってしまったので読んでいく。いまは『エンジニアのための時間管理術』を読んでいる。

みたもの

(なし)

2018-05 から週 2 本の制限がある。今週は問題なし。

その他

ゲーム。 2018-10-14 からのダンジョンメーカーを続けている。あとは 2018-11-24 からの BLUE REVOLVER 。 BLUE REVOLVER は STAGE 5 のボスまで到達できているがクリアできていない。毎日 MISSION → STAGE SELECT → 通しで練習している。いまで 12 時間。 MISSION は STAGE 3 の途中まで。

体調。手首の痛みは先週 (2018-11-25) と変わらない。ストレッチは続いている。

育児。寝返りしそう。反り返ってねじることが多くなった。

「よんだもの」で書いたように『エンジニアのための時間管理術』を読んでいる。時間管理を見直したい。 2018-12-03 の mockmock.dev の時間の見直しもそうか……。今週から毎朝その日の計画を立てるようにしている。良い道具があると良いのだけど Google カレンダーに埋めている。

2018-W50 の目標

  • ☐ bouzuya/purescript-react-basic-bbn-viewer 1.0.0 をつくる
  • ☐ bouzuya/yzrh のコマンドライン解釈部分をつくる
  • ☐ GeoJSON を調べる

bouzuya/yzrh 進捗

bouzuya/yzrh 0.1.0 を目指したけどそこまで進めず。代わりにコマンドラインオプションの解釈部分の使用感は 0.1.0 になったと言えそう。

module Test.Bouzuya.CommandLineOption
  ( tests
  ) where

import Bouzuya.CommandLineOption (parse)
import Bouzuya.CommandLineOption.OptionDefinition (booleanOption, stringOption)
import Data.Either (Either(..))
import Data.Maybe (Maybe(..))
import Prelude (discard)
import Test.Bouzuya.CommandLineOption.ObjectToRecord as ObjectToRecord
import Test.Bouzuya.CommandLineOption.OptionDefinition as OptionDefinition
import Test.Bouzuya.CommandLineOption.OptionObject as OptionObject
import Test.Bouzuya.CommandLineOption.OptionValue as OptionValue
import Test.Bouzuya.CommandLineOption.RecordToArray as RecordToArray
import Test.Unit (TestSuite, suite, test)
import Test.Unit.Assert as Assert

tests :: TestSuite
tests = suite "Bouzuya.CommandLineOption" do
  test "usage" do
    let
      defs =
        { s: stringOption "str" (Just 's') "<STRING>" "string option" "default"
        , b: booleanOption "bool" (Just 'b') "boolean option"
        }
      argv = ["--str", "a", "-b", "foo", "bar"]
    Assert.equal
      (Right { arguments: ["foo", "bar"], options: { s: "a", b: true } })
      (parse defs argv)

https://github.com/bouzuya/yzrh/blob/7243dc90ded7df3e9681ddbd5a4464afbcb9f84e/test/Bouzuya/CommandLineOption.purs#L1-L29

こんな感じ。値でコマンドラインオプションの定義 (Record a) を渡す。その型に対応する Either String { arguments :: Array String, options :: Record b } を返す。

パッケージへの抽出は yzrh 完了後かな……。内部実装をまだかなり直さないとごちゃごちゃしている。

『エンジニアのための時間管理術』を読んでいる

『エンジニアのための時間管理術』を読んでいる。 2018-12-05 に買ったいろいろなものが届いて読んでいきたいのだけどこれを優先していく。

2018-12-03 に『超一流になるのは才能か努力か？』を受けて mockmock.dev の時間を見直したと書いた。時間の管理をもうすこし考えたいと思っている。

読んでいく。

今日は寝坊した。夜が遅かったからだろう。さすがに子どもが寝てくれないような事態への対応は出てこないだろうな……。

日に日に寒くなっている。

『コモンズ』を読んだ

bouzuya/yzrh 。 RecordToArray をつくった。

レコードの各要素を Array a の a に変換してまとめる感じ。

目的を見失っている。

ローレンス・レッシグさんの『コモンズ』を読んだ。

『 CODE 』 (2018-11-18) の続きと言っても良さそう。どちらもコントロールについて書いてある。

『 CODE 』ではコントロールの方法に法・市場・規範・アーキテクチャがあること。そしてインターネットのアーキテクチャつまりコードによるコントロールは従来よりも厳格になってしまう可能性があること。法によるコントロールはコントロールしないためにも必要（要するにバランスが大切）といったことが書かれている。

『コモンズ』ではすべてをコントロールするのではなくものによってはコントロールしないことを提案している。所有権・財産権。すべてを誰かのものとしてコントロールする方向に進もうとしていることに対してコモンズつまり共有のものとして置くほうがより良い結果をもたらすといったことが書かれている。

メモ。コモンズ。共有地。誰かの許可なく利用できるもの。たとえば著作権で保護されたものは派生作品に対して著作者がコントロールを持っている。フェアユースなどもあり限定的なコントロールである（拡大され続けているのだけど……）のだけれど新しく何かが生まれること（この本ではイノベーションや創造性という単語で表現されていた）を阻害する。次に生まれる何かの入力として使えるようにする。自由な活動に対しての制約（誰かの許可つまりコントロール）を減らす。

ぼくが OSS のそばに居るのはこういう自由を感じられるからかもしれない。

何をしたのか分からない日

何をしたのか分からない日。前回は 2018-09-12 かな。

昨晩はなかなか寝つけなかったのだけど朝はきちんと起きた。ゴミを出したり朝食をとってミルクもあげて……。

『コモンズ』の次に読む本を考えていた。積んでいる本には目もくれず技術書出版ラムダノート株式会社で何冊か本を買った。『 OpenSSL クックブック』・『みんなのデータ構造』・『定理証明手習い』だ。勢いのまま技術評論社で『 OSS ライセンスの教科書』も買った。たぶん読めない。

そのあと調子が悪いので横になったら昼だった。睡眠時間が少ないからだ。

『コモンズ』を読む。アメリカのネットワーク業者の話には共感しづらくていけない。

bouzuya/yzrh は昨日いろいろ考えて決めた仕様・ API を今日みたらイケてなくてもやもやする。そも本体の仕様じゃなく command-line option parser の仕様ってのがずれてる。手が進まない。正確には書いては消しを繰り返している。

BLUE REVOLVER 。今日までで 10 時間くらい。 MISSION は STAGE 2 までを完了 (A+ ではない) 。通しで STAGE 5 のボスには到達できた。 STAGE 4, 5 の敵の配置を覚えるくらいの練習でもうすこし良くなりそう。ペース配分。 MISSION の最後にボスラッシュって不穏な文字が見えるのだけど。通しのラストにボムラッシュはさすがにないよね……。ポイントが溜まっていたので UNLOCK を一気に全部解除した。 CONTINUE も解除されたので無理やりでもクリアできるけど……。せっかくなのでノーコンティニューでクリアしたい。

書いてみるといろいろやっている。間に家事・育児がはさまる。

あとは育児か。子どもはそろそろ寝返りしそうだ。「決定的瞬間をおさめたい」そう思い動画を撮ると動かなくなる。カメラを構えると無表情にもなるし悪いやつだ。そういえばこの数ヶ月でぼくの人生で撮った枚数が二倍くらいになっていそうだ。

おしまい。

bouzuya/purescript-react-basic-contacts 1.0.0 をつくった / 『さよなら妖精』を読んだ

昨日のことだけど bouzuya/purescript-react-basic-contacts 1.0.0 をつくった。昨日 (2018-12-03) も書いた mockmock.dev #193 で 0.1.0 をつくったもの。

名前・住所・電話番号を登録するだけのアプリケーション。いわゆる todomvc よりも機能が少なく簡単なもの。追加・編集ができる。

実装は名前のとおり PureScript と lumihq/purescript-react-basic を使っている。 SSR はおろか永続化も CSS さえない。

今回の挑戦はコンポーネントのネストとデータのやりとり。……と言ってもほとんど React のままだった。 halogen などとは違って react-basic はほとんど Effect Unit でなんとかするっぽい。

次は Async / SSR / CSS あたりを試していこうかな。 CSS の適用と README へのスクリーンショットの追加を検討しても良さそう。いまひとつ映えないので。

米澤穂信さんの『さよなら妖精』を読んだ。

解説で「日常の謎」というジャンルを知る。ミステリーでも殺人事件などを伴わない日常の中にある謎を解くもの。小市民シリーズや古典部シリーズがそれらしい。『さよなら妖精』もそれ。

ユーゴスラビアから来たマーヤと過ごした二ヶ月を回想してそれを受けて冒頭（そして最後）の謎に挑む。謎解きがやや物足りなく感じた。

mockmock.dev の時間の見直し

mockmock.dev の時間の活用方法について考え直した。そのことについて書く。

mockmock.dev はオンラインもくもく会だ。制限がほとんどない会。基本は毎週日曜日 13:00-15:00 だ。 Slack へやることを書いてもくもくして結果報告する。もうずいぶんと回をかさねている。 2018-12-02 のもので #193 になっている。 3 年を超えていることになる。ぼくは最初期からだいたい参加している。

考え直すことになったきっかけは 2018-11-22 の『超一流になるのは才能か努力か？』を読んだこと。その前に読んだ『「経験学習」入門』も影響しているかもしれない。どちらの書籍も内容はほとんど関係ない。ただ結果として「練習の効率が悪いんじゃないか」と思いはじめた。前者で言うところの「目的のある練習」ができておらず「愚直な練習」になっているのではないか。後者で引用されていたところの「よく考えられた実践 (deliberate practice) 」ができていないのではないか。そう思いはじめた。

目標は mockmock.dev の 2 時間をうまく活用できたと感じられるものにすること。せっかく毎週 2 時間を確保しているのだから活かしていかないともったいない。成果・効率を上げていきたい。

特に変わったことをするわけではない。基本的にはいつもと同じ。「やってみてふりかえることで変えていく」 (2018-01/2018-03 方針 (2017-12-31)) や 「やってみる・ふりかえる」というシンプルなサイクル (2018-11-10) 。これらを踏まえたうえで。 mockmock.dev にうまくはまった仕組みを考える。毎週 2 時間という枠にぴったりくるようなものを……。

でつくってみた仮のものが↓。特に意識した点は「目標を明確にする」「挑戦をすこしだけ含む」「わかりやすい成果を残す」あたりだ。

mockmock.dev bouzuya ルール (v1)

  • 2 時間で 0.1.0 をつくる
  • 新規のみ改修なし
  • アプリケーションのみライブラリなし
  • 挑戦（新しく試すもの）を含める
  • もぐもぐはなし
  • 事前に仕様の概要を確定する
  • 事前にアプリケーションを作成するのはなし
  • 事前にライブラリを作成するのはあり
  • 事後に 1.0.0 まで持っていく（時間外）

説明する。毎週新規のアプリケーションをつくる。 mockmock.dev の時間はその 0.1.0 をつくる。次の週までに 1.0.0 にしておく。事前準備しても良いけど開始は mockmock.dev を基準にする。いままでにやったことがない要素をひとつは含めることで成長を感じよう。そんな感じ。

2014 の「 1 日 1 Hubot スクリプト」や 2015 に「週ぶり」という取り組みをしていた。それらとところどころ似ている。

2 時間でできるものは知れている。でも 2 時間をうまく使えばそこそこいける。 Hubot スクリプトを書くくらいの軽い気持ちでアプリケーションをつくっていきたい。これらは分かりやすい成果を残すことができる。質より量。量が質になることもある。

週を単位とする点で週ぶりは似ている。ただそこに mockmock.dev という「集中」すべき短い (濃い) 時間を置いている点や「挑戦」を含む点で異なる。週ぶりは「素振り」から来たものなので繰り返して慣れるためにある。挑戦でそこに変化を加えたい。週ぶりの良くなかった点のひとつはだれてしまったところにある。集中・変化を組み込んでだれないようにしていきたい。

うまくいくかはわからない。やってみてふりかえることで変えていく。