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

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

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

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

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

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

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

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

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

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

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

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

買った。（まだ読んでない）

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

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

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

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

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

$ 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に３回のコミットが追加されている。

$ 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 から派生したブランチだけど、新しく含まれている２つのブランチも取り込みたい。

こういう時に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.txt にPythonのバージョンを指定するらしい。

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

$ heroku create 

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

へー

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

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

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

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

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

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

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

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

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

はい。

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

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

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

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

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

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

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

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

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

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

管理は自己満足なのか

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

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

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

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

効率的に時間を使いたい

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

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

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

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

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

効率的とは何か

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

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

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

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

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

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

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

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

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

まとめ

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

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

Jira Softwareを使い出した。

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

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

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

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

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

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

流れとしては、

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

みたいな感じ。

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

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

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

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

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

djangoのミドルウェアってなんなんだと思った

djangoのミドルウェアってなんなんだ。って思った。

とりあえず書いてみた。

こんな感じ。

class MyLoggingMiddleware(object):
    def __init__(self, get_responce):
        self.get_responce = get_responce
        print("MyLogging Middleware init")

    def __call__(self, request):
        print("pre-call:{}".format(request))
        responce = self.get_responce(request)
        print("post-call:{}".format(request))
        return responce

ここを参考にした。

Middleware | Django documentation | Django

なんとなく、書いてみたら雰囲気分かった。

python manage.py runserver で動作を確かめた。 よく分かってないけど、 __init__ が2回呼ばれてる様子だって、それの理由はよく分かってないけど、とりあえず、 __call__ の雰囲気はわかった

ソースはgithubにおいた。

github.com

数理最適化の話を聞きました

社内の勉強会で数理最適化の話を聞いた。

そこで数理最適化と機械学習は何が違うの？って話があった。

• 機械学習は、過去のデータを使って問題を解く。
• 数理最適化は、モデルを使って問題を解く。

みたいな話を聞いた。

この話を聞いて、

『あー、機械学習って、確率と統計だし、確かに新しい問題とか未知の問題は解けないよなあ。』とか思った。

あと『数理最適化だと、解きたい問題があって、それに対する理論を作るから、データがなくてもできるなあ』とかも思った。数理最適化は、理論で問題を解くようなイメージで理解した。

改めて聞いたことを振り返りながら書いていく。

まず、数理最適化には、３つの重要な要素があるらしい。で、その３つの重要な要素は、

• 変数
• 目的関数
• 制約条件

らしい。

名称が数学っぽくて、理解のオーバーヘッドになってるので、個人的な理解で言い換えると、

• 変数は、変えられること。
• 目的関数は、価値観のバランス。
• 制約条件は、変えられることの中で倫理的にやって良い範囲。できる範囲。

みたいなイメージ。

• 変数を洗い出す時は、何を変化させられるのか、を考える。
• 目的関数を考える時は、変えられることの変えやすさを、考える。
• 制約条件を考える時は、変化させられるのかことで、まあやったとしてもここまでかなー、と言うのを考える。

と言うのが今のところの個人的な理解。

この変数と目的関数と制約条件を元に問題がといていく。

この変数、目的関数、制約条件を元に問題を解いてくれるソフトウェアをソルバーと言うらしい。

class Solver:
    def __init__(self, 変数, 目的関数, 制約条件):
        pass
    def solve(self):
        pass

僕のイメージはこう言うイメージ。

それから数理最適化には、典型問題と言うのがあるらしい。

よくわかってないけど、典型的な問題だと思う。『これは、〇〇問題だね！』的な使い方をすると理解した。

多分、デザインパターンとかアーキテクチャパターンとか、みたいな何かなのかなと思って話を聞いていた。

典型問題には、比較的簡単な計算コストが低い問題もあれば、計算コストが高い問題があるらしい。

O(N^N)の問題を解くのは無理です。みたいな話。

はい。

典型問題はたくさんあるらしいけど、すぐに理解するのは難しそうだなあという印象を受けた。

あとは、Qiitaに参考になる記事がたくさんあるよ、という話も聞いた。

個人的な感想としては、面白いし、もっと勉強したいなと思った。

機械学習は、データを使うことを前提としていて、ボトムアップなアプローチだけど、数理最適化は、知恵を使うことを前提にしていて、トップダウンなアプローチ。みたいな印象を受けた。

どっちがいいとかじゃなくて、バランスよく使えるようになりたいなあ、という気持ち