リファクタリングして欲しい。と言われたが、リファクタリングに対する理解が浅く、何をすればいいのかわからなかった。
調べた。
続きを読む絵はすぐに上手くならない。って本を読んでいる。この本がものすごく面白い。
読んでいて、そりゃそうだ!と思うようなことがたくさんあった。 気づきもたくさんあった。書きます。
本に書いてあったことから学んだこと。
音楽やプログラミングでも同じような話があると思う。 そして、引き出しの多さは、制作のスピード感に関係があるとのこと。 レベルが低くてもすぐに描けないと情熱が薄れてしまうという話。 そして、僕は、音楽にしてもプログラミングにしても引き出しが少ないことに気づいた。
本に書いてあったことから学んだこと。
音楽でも、近いことが言えそうだあ、とか。色々、似たようなことを考えた。 環境は人を育てるけど、その環境に受け入れられるかどうかは人次第。
本に書いてあったことから学んだこと。
音楽とかプログラミングとか、映像とか、クリエイティブなことは全体的に同じことが当てはまりそうだなあと思った。
音楽とかプログラミングをやるときに、もっとサササッと作れるようになりたいと思ってたけど、そういうタイミング来ないんだ。。。という気持ちになった。そう言えば、すごい人もみんな必死な顔して音楽やプログラミングしてる。
本に書いてあったことから学んだこと。
デッサンは、絵を描くために使う能力を効率的にトレーニングの一つであって、絶対にやらなきゃダメなことではない。 ただし、何をやりたいかわからないなら、デッサンやる方が汎用性が高い。との話。
これも、音楽とかプログラミングで同じこと言えそうだなあ・・・と思った。 例えば、音楽なら、「音楽理論を勉強すべき」vs「譜面も読めない音楽家がいるしやる必要はない」の議論をたくさん見たけど、同じ話だと思った。
本に書いてあって学んだこと
ソフトウェア開発や音楽制作も同じかなーという気持ち。
本に書いてあって学んだこと
とりあえず、作ろう。という話。能書きはいらない。
本に書いてあって学んだこと
僕、音楽にしてもプログラミングにしても頭の中にあるものを具体的にアウトプットするために、めちゃくちゃ時間がかかって、心折れそうになるんだけど、それってトレーニングが足りてないんだ。。。ということがわかった。 トレーニングします。
本に書いてあって学んだこと
音楽だと、譜面に書いてある音楽をコピーするのと、流れている音楽を耳コピするのの違いかなあと思った。 プログラミングだと、ソースコードを写経する、仕様からコードを書く、要求から仕様を決めてコードを書く、とか段階がありそうだなあと思った。
全体的に、僕は、いきなり全部やろうとして、時間がかかりすぎてあっぷあっぷしてる感じがある。もっと下からレベルを上げていきたい。下積みを増やしたい。
プログラミングならソースコード写経のレベルをあげていこう。 音楽なら、譜面をコピーしまくろう。
もっと手を動かす時間を増やそう。
朝の通勤時間に考えてたことを、書きます。
それは、集中する時間はどうなるのがいいんだろう?って話です。別に結論はありません。
ここでいう集中する時間は、1つのことに取り組んでいる時間です。
何かをはじめたら開始。別のことをはじめたら終了。別のことを考え始めても終了。です。
なんとなく、仕事が早く進みそうに思うから。
と言うか僕は、複数のことを同時にやるとパフォーマンスがどんどん下がっていくようなので、同時にやることは一つに絞りたいです。
自分だけで完結せず並行してタスクが動くときは、jobリストを作って、定期的にそのリストをポーリングする方がストレスフリーですし、パフォーマンスあがります。これは人それぞれな気がします。
今のところ、アプリを使って測っています。
何かを始める前に、タイマーをスタートして、終わったらタイマーをとめる。
タイマーが動いているときは、一つのことしかできない。と考えてタイマーの開始ボタンを押します。別のことが気になってきたら、停止ボタンを押します。
つまり、タイマーが動いているときは、一つの事しかやってない。ということです。
このやり方だと、何をやるか、を決めないと集中を開始できないことになってます。
僕は、今、Togglというアプリで測っています。TimeCrowdというアプリでもいいかもしれません。もっと他に良いアプリがあるかもしれません。
時間を測って分析すると次のようなことがわかります。
集中する時間にも密度があるはず。
1つのことをやってるとき、ものすごく集中してることもあれば、とりあえず1つのことをやってることもある。
集中力には、集中度合いがあるはず。
1人の人が1日に使える集中力の総量があるはず。
どれくらい集中しているかを集中度、と言うすると、1人の人が1日に使える集中力は、集中度と集中した時間の掛け算の積になると思う。
集中する時間は、多い方が良いのか短い方が良いのか。
1人が1日に使える集中力に上限があるとすれば、毎日その限界まで使う方が良いようなきがする。でも集中力って毎日上限まで使って大丈夫なのかな。
とりあえず、1日あたり適切な集中力のバランスがある気がす。
とりあえず時間がきたのでおわります。
まとまりのない文を読んでくれてありがとうございました。
では。
上手い。ってなんなんだろう?
何かしらのレベルの高さを示す言葉な気がする。
経験から考えてみて、音楽制作にしてもソフトウェア開発にしても、かけた時間とレベルが一致するわけじゃない。
例えば、僕より音楽制作に使った時間が少ない人が僕より音楽制作が上手いことはある。その逆もある。
つまり、同じだけ時間を消費しても上手くなり度合いが違う、という事。時間をかけてない人が上手いことはないので、時間とレベルには相関があるけど、他の要因も関係してると思う。
じゃあ、何が理由で違うんだろう。
というか、単純に、同じだけ時間をかけたのにAさんは上手くなって、自分は上手くならなかった。という状況は納得がいかない気持ちがある。
かけた時間が少なかったから上手くならなかった。という話なら、努力が足りない。という話になるし、努力の話になってくると、まあ納得いく気持ちがある。でも、時間じゃなさそう、となると、時間をかける気持ちが薄れる。
その理由がわからないと、また同じように時間をかけたのにあんまりレベルがあがらない状況になるんじゃないか、と思ってしまう。
そんなことを考えてたら、1つの本を見つけた。
買った。(まだ読んでない)
上手くなる。ということについて本1冊書いてるのは興味がある。
まだ目次をパラパラしただけだけど、いろいろ気になることは書いてありそう。
読み終わったら、感想をブログに書こうかなーという気持ち。
gitのrebaseがよくわかっていない部分があるので、勉強したいと思う。
このあたりを読んでも文章が長くていまいちしっくりこない。というか矢印の向きとか図形の定義がよくわからなかったり、何を見たらいいのかわからなくて戸惑う。
最近、何となく進んできた理解では、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 reset
ってなんだろう。とか HEAD
って僕の理解で合ってるのかな。とか疑問はまだあるので、これもそのうち確かめたい。django girlsのdjangoのチュートリアルを触ってる。
herokuにdjangoアプリをデプロイするらしい。
herokuを初めて触った。
herokuでは、herokuのCLIを入れて
$ heroku login
とするとログインできるらしい。
Pythonだと、requirements.txt
を置いとくと関連ライブラリをインストールしてくれるらしい。
あと、Procfile
というファイルに、起動パスを書いて、 runtime.txt
にPythonのバージョンを指定するらしい。
gitリポジトリで次のコマンドを実行すると、gitリポジトリをherokuにpushできるようになる。
$ heroku create
herokuにpushすると、先ほど配置した設定ファイルを読んで、Webアプリケーションを起動してくれるらしい。
へー
すごく簡単にDjangoアプリが公開できた。
なんか簡単にアプリを作って公開したいな。
うーん、なんかこれ、「管理しすぎ病」では?と思ったことがあった。
今日はそれについて、考えながら書きます。 なんか書きながら考えているのもあって、支離滅裂な文章でもあります。。
そんなことをふと思ったことがあります。
んー、まあ、何が管理の時間なの?と言われると、モゴモゴしてしまう部分があるので、 もうちょっと具体的に考えたほうがいいんじゃないかなあと思ったりもします。(これは別の機会に考えます)
でも、なんとなく、自分の体感的に、管理のために使ってる時間が多くないかなー、とか思ったりするんですよね。
はい。
とはいえ、管理することで価値が生まれるのなら、管理したほうがいいと思います。
そんなことを考えていると、そもそも、なんで管理しようとしてたんだっけとか思いました。
うーん、なんでだっけ。 とりあえず、一人の人間が、管理していることってたくさんありますよね。
習慣的に管理していることもたくさんあります。管理していないこともたくさんあります。
仕事じゃなくて私生活の話をするなら、例えば以下のようなことも管理していますよね。
習慣的に管理していることっていうのは、これまでの自分の動き方から自然に生まれているものだと思います。
その管理がやるべきであれば、やったほうがいいし、やらなくてもいいならやらなくていいと思います。
で、やるべきかやらないべきか、というのは、一つ一つ考えていったほうがいいような気がするんですよね。
時々、管理は自己満足じゃないのかなあと思うときがあります。 僕は、誰かにも要求されていない管理をやっていることもあります。 その管理は、何かが起きた時にすごく役に立つし、何かが起きなかった時は大して役に立たなかったりする。
何でもかんでも管理すればいいという話ではないと思っていて、管理する必要のないことは管理しないようにしていますが、 それでも、人に言われていない管理は、自己満足なのかなあと思ったりします。
ただ、人に言われて始める管理って、なんか、すごい微妙なんですよね。 その人として最低限担保したい何かはないの?って僕は思ってしまいます。 その人として、大切にしたいことは管理したほうがいいんじゃないかなーとか。
だから、管理は、ある意味で自己満足なのかなあと思ったりします。ただ、自己満足の管理ばっかりじゃダメだろ、とかも思います。じゃあ結局のところなんなの?っていうと、自分のポリシーと求められていることに折り合いをつけていくのかなあとか。
管理すると、無駄がなくなります。無駄がなくなるってことは、効率的に時間が使える、ということにつながります。、、、、いや、繋がると思います。うん、多分無駄がなくなるし、、、本当?
管理すると本当に、効率的になるんでしょうか。いや、実は管理する時間そのものは無駄なんじゃないでしょうか。管理する時間が無駄だとすると、管理しないほうが効率的なんでしょうか。うーん。どうなんでしょう。
管理している状態のメリットを考えると、管理している対象の情報のCRUDが速くなるよなあと思いました。例えば、誰かに言われた指示を自分の中でリストにして管理していると、当たり前ですが、その指示に対応したのかどうかを確認して、更新していくのが速くなります。
管理のデメリットを考えると、データを整理する手間が増えることです。管理するためには、管理対象のアクションが行われた時に、ログを所定のフォーマットで書いておく必要があります。これがめんどくさい。所定のフォーマットで記録を残しておくためにスピードがダウンします。
だから、スピードアップするために管理をやっていたのに、管理することでスピードダウンするという事態が発生します。管理したから、効率的になるわけではないし、管理しないから効率が悪くないわけでもないです。
結局のところ、管理したいんじゃなくて、スピードアップしたいんですよね。
スピードアップということで考えると、評価するまでの時間が違うとスピードは違うよなあ、と思います。
100m走とフルマラソンの走り方が、同じじゃないように、効率的ということも様々な側面で考えられるような気がしています。
うーん、結局、どういう段階でスピードがあれば効率的って言えるんだろう。
とりあえず、仕事っていう意味でいうと、プロジェクト単位で、一番最速ということなのかなあ。あんまり先のことを考えても意味がないような気がするし。
でも、作業単位で最速を目指して動いていったら、結局プロジェクトもスピードアップしたとかある気がしてる。
ただ、プロジェクトの単位でひたすら効率化を目指したら大局的な視点はどうなるんだろう、とかも思ったりする。
じゃあ、結局どうしたらいいの?っていうのはわからない。あんまり長い範囲を最速にしても意味がないかもしれないし、意味があるかもしれない。(考え中
結局のところ話がよくわからなくなってきていますが、とりあえずまとめます。