matobaの備忘録

育児しながら働くあるエンジニアの記録

もっともっと手を動かす時間を増やしたいと思った話

絵はすぐに上手くならない。って本を読んでいる。この本がものすごく面白い。

絵はすぐに上手くならない

絵はすぐに上手くならない

読んでいて、そりゃそうだ!と思うようなことがたくさんあった。 気づきもたくさんあった。書きます。

2つのうまさ

本に書いてあったことから学んだこと。

  • 絵には二つのうまさがある。
  • 1つ目は、技術的なうまさ。何が良くて何が良くないのかわかり、表現力が高いこと。
  • 2つ目は、引き出しの多さ。何かを描こうとした際に、すぐに描けること。

音楽やプログラミングでも同じような話があると思う。 そして、引き出しの多さは、制作のスピード感に関係があるとのこと。 レベルが低くてもすぐに描けないと情熱が薄れてしまうという話。 そして、僕は、音楽にしてもプログラミングにしても引き出しが少ないことに気づいた。

上手さと学校

本に書いてあったことから学んだこと。

  • 真実:絵が上手いから美大に入れた
  • 間違い:美大に入ったから絵が上手い

音楽でも、近いことが言えそうだあ、とか。色々、似たようなことを考えた。 環境は人を育てるけど、その環境に受け入れられるかどうかは人次第。

上手さと書きやすさ

本に書いてあったことから学んだこと。

  • 真実:絵が上手い人も必死で形をとって遠くから何度も眺めて形を整えながら絵を描いている。
  • 間違い:絵が上手い人は、いつも鼻歌を歌いながらササっと絵を描ける。

音楽とかプログラミングとか、映像とか、クリエイティブなことは全体的に同じことが当てはまりそうだなあと思った。

音楽とかプログラミングをやるときに、もっとサササッと作れるようになりたいと思ってたけど、そういうタイミング来ないんだ。。。という気持ちになった。そう言えば、すごい人もみんな必死な顔して音楽やプログラミングしてる。

デッサンと上達

本に書いてあったことから学んだこと。

  • 真実:デッサンをやったら上手くなる
  • 間違い:デッサンをやらないと上手くならない。
  • 真実:デッサンをやらなくても、他のトレーニング(たくさん絵を描く等)をすれば上手くなる。
  • 間違い:デッサンをやらずに、他のトレーニング(たくさん絵を描く等)をしなければ上手くならない。

デッサンは、絵を描くために使う能力を効率的にトレーニングの一つであって、絶対にやらなきゃダメなことではない。 ただし、何をやりたいかわからないなら、デッサンやる方が汎用性が高い。との話。

これも、音楽とかプログラミングで同じこと言えそうだなあ・・・と思った。 例えば、音楽なら、「音楽理論を勉強すべき」vs「譜面も読めない音楽家がいるしやる必要はない」の議論をたくさん見たけど、同じ話だと思った。

絵とトレーニング

本に書いてあって学んだこと

  • 間違い:いろんなスキルや工程があって、一つずつクリアして行くと最終的に絵が描けるようになる
  • 真実:いろんなレベルのスキルや工程がぐちゃぐちゃしていて、クリアとかない。
  • 現実:スキルを整理して、全体的にレベルアップしやすくしている。

ソフトウェア開発や音楽制作も同じかなーという気持ち。

レベルと作品制作

本に書いてあって学んだこと

  • どんなレベルであったとしても作品制作はすぐ始めること
  • 上手くなってから始めようとしても、自分で自分のことを上手くなったと思う日はない。
  • 勉強が終わってから始めようとしても、勉強は終わらない。

とりあえず、作ろう。という話。能書きはいらない。

トレーニングと作品制作

本に書いてあって学んだこと

  • 作品制作は、頭の中にある世界を描いて絵にする。
  • トレーニングは、目で見たことを絵にする。

僕、音楽にしてもプログラミングにしても頭の中にあるものを具体的にアウトプットするために、めちゃくちゃ時間がかかって、心折れそうになるんだけど、それってトレーニングが足りてないんだ。。。ということがわかった。 トレーニングします。

トレーニングの種類

本に書いてあって学んだこと

  • 平面に書いてある絵を平面に写すトレーニング。比較的、簡単。線を描くスキルが必要。
  • 現実にある立体的なものを平面に書くトレーニング。比較的、難しい。線を描くスキルに加えて、構図を考えたり、陰影をつけたりするスキルも必要になってくる。

音楽だと、譜面に書いてある音楽をコピーするのと、流れている音楽を耳コピするのの違いかなあと思った。 プログラミングだと、ソースコードを写経する、仕様からコードを書く、要求から仕様を決めてコードを書く、とか段階がありそうだなあと思った。

終わり

全体的に、僕は、いきなり全部やろうとして、時間がかかりすぎてあっぷあっぷしてる感じがある。もっと下からレベルを上げていきたい。下積みを増やしたい。

プログラミングならソースコード写経のレベルをあげていこう。 音楽なら、譜面をコピーしまくろう。

もっと手を動かす時間を増やそう。

集中する時間はどうするのがよいか

朝の通勤時間に考えてたことを、書きます。

それは、集中する時間はどうなるのがいいんだろう?って話です。別に結論はありません。

集中する時間とは

ここでいう集中する時間は、1つのことに取り組んでいる時間です。

何かをはじめたら開始。別のことをはじめたら終了。別のことを考え始めても終了。です。

なぜ集中する時間を増やしたいか

なんとなく、仕事が早く進みそうに思うから。

と言うか僕は、複数のことを同時にやるとパフォーマンスがどんどん下がっていくようなので、同時にやることは一つに絞りたいです。

自分だけで完結せず並行してタスクが動くときは、jobリストを作って、定期的にそのリストをポーリングする方がストレスフリーですし、パフォーマンスあがります。これは人それぞれな気がします。

集中する時間の測り方

今のところ、アプリを使って測っています。

何かを始める前に、タイマーをスタートして、終わったらタイマーをとめる。

タイマーが動いているときは、一つのことしかできない。と考えてタイマーの開始ボタンを押します。別のことが気になってきたら、停止ボタンを押します。

つまり、タイマーが動いているときは、一つの事しかやってない。ということです。

このやり方だと、何をやるか、を決めないと集中を開始できないことになってます。

僕は、今、Togglというアプリで測っています。TimeCrowdというアプリでもいいかもしれません。もっと他に良いアプリがあるかもしれません。

集中する時間の増減

時間を測って分析すると次のようなことがわかります。

  • 合計でどれくらいの時間、集中したか
  • その集中時間がどれくらい長いか短いか
  • 集中している時間の割合はどうか
  • 全体のパフォーマンスと集中時間に関係はあるか
  • どんなタスクだと集中できたか

集中する時間の密度

集中する時間にも密度があるはず。

1つのことをやってるとき、ものすごく集中してることもあれば、とりあえず1つのことをやってることもある。

集中力には、集中度合いがあるはず。

集中力の総量

1人の人が1日に使える集中力の総量があるはず。

どれくらい集中しているかを集中度、と言うすると、1人の人が1日に使える集中力は、集中度と集中した時間の掛け算の積になると思う。

集中する時間の量

集中する時間は、多い方が良いのか短い方が良いのか。

1人が1日に使える集中力に上限があるとすれば、毎日その限界まで使う方が良いようなきがする。でも集中力って毎日上限まで使って大丈夫なのかな。

とりあえず、1日あたり適切な集中力のバランスがある気がす。

おわり

とりあえず時間がきたのでおわります。

まとまりのない文を読んでくれてありがとうございました。

では。

レベルがあがるってなんだろう

上手い。ってなんなんだろう?

何かしらのレベルの高さを示す言葉な気がする。

経験から考えてみて、音楽制作にしてもソフトウェア開発にしても、かけた時間とレベルが一致するわけじゃない。

例えば、僕より音楽制作に使った時間が少ない人が僕より音楽制作が上手いことはある。その逆もある。

つまり、同じだけ時間を消費しても上手くなり度合いが違う、という事。時間をかけてない人が上手いことはないので、時間とレベルには相関があるけど、他の要因も関係してると思う。

じゃあ、何が理由で違うんだろう。

というか、単純に、同じだけ時間をかけたのにAさんは上手くなって、自分は上手くならなかった。という状況は納得がいかない気持ちがある。

かけた時間が少なかったから上手くならなかった。という話なら、努力が足りない。という話になるし、努力の話になってくると、まあ納得いく気持ちがある。でも、時間じゃなさそう、となると、時間をかける気持ちが薄れる。

その理由がわからないと、また同じように時間をかけたのにあんまりレベルがあがらない状況になるんじゃないか、と思ってしまう。

そんなことを考えてたら、1つの本を見つけた。

絵はすぐに上手くならない

絵はすぐに上手くならない

買った。(まだ読んでない)

上手くなる。ということについて本1冊書いてるのは興味がある。

まだ目次をパラパラしただけだけど、いろいろ気になることは書いてありそう。

読み終わったら、感想をブログに書こうかなーという気持ち。

gitのrebaseを簡単に試して見た。

gitのrebaseがよくわかっていない部分があるので、勉強したいと思う。

このあたりを読んでも文章が長くていまいちしっくりこない。というか矢印の向きとか図形の定義がよくわからなかったり、何を見たらいいのかわからなくて戸惑う。

Git - リベース

最近、何となく進んできた理解では、rebaseは、「今使っているブランチを派生させる場所を変更するコマンド」というイメージになっている。

その理解が正しいのかを確かめたい。

まずは、ローカルに動作確認用のリポジトリを作る。

$ cd git-rebase-test/
$ git init
Initialized empty Git repository in /Users/mtb/work/git-rebase-test/.git/
$ ll
.    ..   .git

とりあえず、masterブランチに、ファイルを一つ作る。

$ echo test1 >> ChangeLog.txt
$ cat ChangeLog.txt
test1
$ git status
On branch master

Initial commit

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    ChangeLog.txt

nothing added to commit but untracked files present (use "git add" to track)
$ git add ChangeLog.txt
$ git commit -m "test1 commit"
[master (root-commit) 8296084] test1 commit
 1 file changed, 1 insertion(+)
 create mode 100644 ChangeLog.txt
$ git log
commit 82960845db034126e9ff913e7ed3bc30c2034165 (HEAD -> master)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:32:55 2017 +0900

    test1 commit
$ git branch -a
* master

ここから、ブランチを作ってチェックアウトする。ブランチ名は、 branch1 にしよう。

$ git branch branch1
$ git checkout branch1
Switched to branch 'branch1'
$ git branch
* branch1
  master

追記してコミットする。3回やろう。

$ echo branch1-1 >> ChangeLog.txt
$ cat ChangeLog.txt
test1
branch1-1
$ git add ChangeLog.txt
$ git commit -m "branch1-1 commit"
[branch1 000ab89] branch1-1 commit
 1 file changed, 1 insertion(+)
$ echo branch1-2 >> ChangeLog.txt
$ git add ChangeLog.txt
$ git commit -m "branch1-2 commit"
[branch1 42ea439] branch1-2 commit
 1 file changed, 1 insertion(+)
$ echo branch1-3 >> ChangeLog.txt
$ git add ChangeLog.txt
$ git commit -m "branch1-3 commit"
[branch1 ca1720e] branch1-3 commit
 1 file changed, 1 insertion(+)

ファイルの中身とgitのログを見る。ChangeLog.txtに3回のコミットが追加されている。

$ cat ChangeLog.txt
test1
branch1-1
branch1-2
branch1-3
$ git log
commit ca1720e8913b2e0a8ec7b8767eac9a8c326464fb (HEAD -> branch1)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:41:05 2017 +0900

    branch1-3 commit

commit 42ea439a6ba204468c0e037b640b36f08d5dbe0e
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:40:52 2017 +0900

    branch1-2 commit

commit 000ab898c73855aa0265025bd805ae052d38386a
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:39:57 2017 +0900

    branch1-1 commit

commit 82960845db034126e9ff913e7ed3bc30c2034165 (master)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:32:55 2017 +0900

    test1 commit

次は、masterブランチのChangeLog.txtに修正を加えよう。それぞれは、別のコミットにする。

  • ChangeLog.txt の先頭行に「ChangeLogs」を追加
  • ChangeLog2.txt に 「test2」
$ git checkout master
Switched to branch 'master'
$ vim ChangeLog.txt
$ cat ChangeLog.txt
ChangeLogs
test1
$ git add ChangeLog.txt
$ git commit -m "change logs commit"
[master 5f50b58] change logs commit
 1 file changed, 1 insertion(+)
$ echo test2 >> ChangeLog2.txt
$ cat ChangeLog2.txt
test2
$ git add ChangeLog2.txt
$ git commit -m "change log2 add"
[master f76437a] change log2 add
 1 file changed, 1 insertion(+)
 create mode 100644 ChangeLog2.txt

git logを見て見る。masterブランチに二つのコミットがついた状態になっている。

$ git log
commit f76437af8af7fd44e09170968aeb45f1771674b1 (HEAD -> master)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:47:51 2017 +0900

    change log2 add

commit 5f50b58689b86514224c4b2b59caa1a809954ea8
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:47:00 2017 +0900

    change logs commit

commit 82960845db034126e9ff913e7ed3bc30c2034165
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:32:55 2017 +0900

    test1 commit

banch1 は、commit 82960845db034126e9ff913e7ed3bc30c2034165 から派生したブランチだけど、新しく含まれている2つのブランチも取り込みたい。

こういう時にrebaseを使う。(多分。) 使って見る。

まずは、取り込みたいブランチにcheckoutする。そして、masterにrebaseする。 じゃあ色々ログが流れる。 ログを読むとわかるけど、masterのheadに戻って、そこから新しいコミットを適応していく。

$ git checkout branch1
Switched to branch 'branch1'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: branch1-1 commit
Using index info to reconstruct a base tree...
M   ChangeLog.txt
Falling back to patching base and 3-way merge...
Auto-merging ChangeLog.txt
Applying: branch1-2 commit
Using index info to reconstruct a base tree...
M   ChangeLog.txt
Falling back to patching base and 3-way merge...
Auto-merging ChangeLog.txt
Applying: branch1-3 commit
Using index info to reconstruct a base tree...
M   ChangeLog.txt
Falling back to patching base and 3-way merge...
Auto-merging ChangeLog.txt

修正後のファイルを見て見ると、無事にマージされている様子。

$ ll
.              ..             .git           ChangeLog.txt  ChangeLog2.txt
$ cat ChangeLog.txt
ChangeLogs
test1
branch1-1
branch1-2
branch1-3
$ cat ChangeLog2.txt
test2

ログを見てもそうなっている。

$ git log
commit 0e639b0330dfebc47e503f7eb6e95091169c2765 (HEAD -> branch1)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:41:05 2017 +0900

    branch1-3 commit

commit 3c301cf904baa9e61202c401b51270eb43668a60
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:40:52 2017 +0900

    branch1-2 commit

commit 02ebe3df591fefbab1d2d7d438aa40becef5526b
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:39:57 2017 +0900

    branch1-1 commit

commit f76437af8af7fd44e09170968aeb45f1771674b1 (master)
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:47:51 2017 +0900

    change log2 add

commit 5f50b58689b86514224c4b2b59caa1a809954ea8
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:47:00 2017 +0900

    change logs commit

commit 82960845db034126e9ff913e7ed3bc30c2034165
Author: mtb_beta <example@example.com>
Date:   Thu Nov 30 07:32:55 2017 +0900

    test1 commit

終わり

  • gitのrebaseを簡単に試して見た。
  • 当初抱いていた「今使っているブランチを派生させる場所を変更するコマンド」というイメージは、ある意味では間違ってないけど、厳密にいうと違う。
  • (多分、)指定したブランチのHEADから、現在のブランチに加えられたコミットを再適用するのがrebase。(ややこしい)
  • とはいえ、git reset ってなんだろう。とか HEAD って僕の理解で合ってるのかな。とか疑問はまだあるので、これもそのうち確かめたい。

django girlsのチュートリアルを触っている。

django girlsのdjangoチュートリアルを触ってる。

herokuにdjangoアプリをデプロイするらしい。

herokuを初めて触った。

herokuでは、herokuのCLIを入れて

$ heroku login

とするとログインできるらしい。

Pythonだと、requirements.txtを置いとくと関連ライブラリをインストールしてくれるらしい。 あと、Procfile というファイルに、起動パスを書いて、 runtime.txtPythonのバージョンを指定するらしい。

gitリポジトリで次のコマンドを実行すると、gitリポジトリをherokuにpushできるようになる。

$ heroku create 

herokuにpushすると、先ほど配置した設定ファイルを読んで、Webアプリケーションを起動してくれるらしい。

へー

すごく簡単にDjangoアプリが公開できた。

なんか簡単にアプリを作って公開したいな。

管理しすぎ、というのはあるのかもしれない

うーん、なんかこれ、「管理しすぎ病」では?と思ったことがあった。

今日はそれについて、考えながら書きます。 なんか書きながら考えているのもあって、支離滅裂な文章でもあります。。

えっ、私、管理の時間多すぎ

そんなことをふと思ったことがあります。

んー、まあ、何が管理の時間なの?と言われると、モゴモゴしてしまう部分があるので、 もうちょっと具体的に考えたほうがいいんじゃないかなあと思ったりもします。(これは別の機会に考えます)

でも、なんとなく、自分の体感的に、管理のために使ってる時間が多くないかなー、とか思ったりするんですよね。

はい。

とはいえ、管理することで価値が生まれるのなら、管理したほうがいいと思います。

そんなことを考えていると、そもそも、なんで管理しようとしてたんだっけとか思いました。

なぜ僕は管理しようとするのか

うーん、なんでだっけ。 とりあえず、一人の人間が、管理していることってたくさんありますよね。

習慣的に管理していることもたくさんあります。管理していないこともたくさんあります。

仕事じゃなくて私生活の話をするなら、例えば以下のようなことも管理していますよね。

  • 朝ごはんを食べたかどうか
  • お風呂に入ったかどうか
  • 財布を持っているかどうか
  • 公共料金の支払いは、忘れていないか

習慣的に管理していることっていうのは、これまでの自分の動き方から自然に生まれているものだと思います。

その管理がやるべきであれば、やったほうがいいし、やらなくてもいいならやらなくていいと思います。

で、やるべきかやらないべきか、というのは、一つ一つ考えていったほうがいいような気がするんですよね。

管理は自己満足なのか

時々、管理は自己満足じゃないのかなあと思うときがあります。 僕は、誰かにも要求されていない管理をやっていることもあります。 その管理は、何かが起きた時にすごく役に立つし、何かが起きなかった時は大して役に立たなかったりする。

何でもかんでも管理すればいいという話ではないと思っていて、管理する必要のないことは管理しないようにしていますが、 それでも、人に言われていない管理は、自己満足なのかなあと思ったりします。

ただ、人に言われて始める管理って、なんか、すごい微妙なんですよね。 その人として最低限担保したい何かはないの?って僕は思ってしまいます。 その人として、大切にしたいことは管理したほうがいいんじゃないかなーとか。

だから、管理は、ある意味で自己満足なのかなあと思ったりします。ただ、自己満足の管理ばっかりじゃダメだろ、とかも思います。じゃあ結局のところなんなの?っていうと、自分のポリシーと求められていることに折り合いをつけていくのかなあとか。

効率的に時間を使いたい

管理すると、無駄がなくなります。無駄がなくなるってことは、効率的に時間が使える、ということにつながります。、、、、いや、繋がると思います。うん、多分無駄がなくなるし、、、本当?

管理すると本当に、効率的になるんでしょうか。いや、実は管理する時間そのものは無駄なんじゃないでしょうか。管理する時間が無駄だとすると、管理しないほうが効率的なんでしょうか。うーん。どうなんでしょう。

管理している状態のメリットを考えると、管理している対象の情報のCRUDが速くなるよなあと思いました。例えば、誰かに言われた指示を自分の中でリストにして管理していると、当たり前ですが、その指示に対応したのかどうかを確認して、更新していくのが速くなります。

管理のデメリットを考えると、データを整理する手間が増えることです。管理するためには、管理対象のアクションが行われた時に、ログを所定のフォーマットで書いておく必要があります。これがめんどくさい。所定のフォーマットで記録を残しておくためにスピードがダウンします。

だから、スピードアップするために管理をやっていたのに、管理することでスピードダウンするという事態が発生します。管理したから、効率的になるわけではないし、管理しないから効率が悪くないわけでもないです。

効率的とは何か

結局のところ、管理したいんじゃなくて、スピードアップしたいんですよね。

スピードアップということで考えると、評価するまでの時間が違うとスピードは違うよなあ、と思います。

100m走とフルマラソンの走り方が、同じじゃないように、効率的ということも様々な側面で考えられるような気がしています。

  • 作業単位でのスピードアップ(短期的)
  • 成果物単位でのスピードアップ(中期的)
  • 戦略単位でのスピードアップ(長期的、大局的)

うーん、結局、どういう段階でスピードがあれば効率的って言えるんだろう。

とりあえず、仕事っていう意味でいうと、プロジェクト単位で、一番最速ということなのかなあ。あんまり先のことを考えても意味がないような気がするし。

でも、作業単位で最速を目指して動いていったら、結局プロジェクトもスピードアップしたとかある気がしてる。

ただ、プロジェクトの単位でひたすら効率化を目指したら大局的な視点はどうなるんだろう、とかも思ったりする。

じゃあ、結局どうしたらいいの?っていうのはわからない。あんまり長い範囲を最速にしても意味がないかもしれないし、意味があるかもしれない。(考え中

まとめ

結局のところ話がよくわからなくなってきていますが、とりあえずまとめます。

  • なんでも管理すればいいという話ではない。
  • 管理することで価値が生まれるなら管理しよう。
  • 同じ管理にしてもやるべきかやらないべきかは、一つ一つ考えていこう
  • 管理はある意味で自己満足だけど、それだけではダメ。バランスを考える。
  • 効率的、がなんなのかを考えるのは難しいし、今後もう少し考える。

Jira Softwareを使い出した。

そういえばJira Softwareを使い出した。個人で。

個人でものすごくゆっくり開発しているアプリケーションの開発を管理しようと思って。

もともと、BitBucketにプライベートリポジトリを作って、そこでちょろちょろやってたけど、もうちょっといい感じのプロジェクト管理ツール欲しい気持ちだった。

というか、一人で開発してるのに開発中のアプリケーションが複数あるという微妙な状況になっているのもあり、複数のプロジェクトを横断的に課題管理できるツール欲しかった。

今のところ、Jiraでスクラムモードみたいな奴を使ってる。

割といい感じな気がしている。

流れとしては、

気になった時に、バックログを積み上げる。 ポイントで見積もる。 スプリントにする。

みたいな感じ。

いいなと思うのは、バックログを積み上げた後に、スプリントするものを選ぶこと。そして、スプリントが始まったらバックログは見ない。スプリントの最中も、ボードを見ていて、同時に複数のストーリーが着手されたら危ないことがわかる。

特に僕の場合は、作業をしていると「あ、あれもやりたい」「これもやりたい」みたいなのがたくさん見えてきてしまって、混乱するから、それらをバックログに詰めて、今は見えない状態になってるのは精神的に安定する感じがある。

後、開発速度を上げたい気持ちから、知らず知らずのうちに、ついつい複数のタスクを並列化してしまうことがあるけど、これも良くない。

ボードを見ていると、複数のタスクが進行状態になっているのはよくないことに気付きやすい。開発速度というか、スピードに乗って進められるような仕組みなのがいいように思ってる。

あと、Jiraはバーンアウトチャートとかいろんな観点でレポートを出力できるみたいなので、いろんなレポート見ながら、自分の開発速度を、ふむふむ、とかしたいと思ってる。