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を使い出した。個人で。
個人でものすごくゆっくり開発しているアプリケーションの開発を管理しようと思って。
もともと、BitBucketにプライベートリポジトリを作って、そこでちょろちょろやってたけど、もうちょっといい感じのプロジェクト管理ツール欲しい気持ちだった。
というか、一人で開発してるのに開発中のアプリケーションが複数あるという微妙な状況になっているのもあり、複数のプロジェクトを横断的に課題管理できるツール欲しかった。
今のところ、Jiraでスクラムモードみたいな奴を使ってる。
割といい感じな気がしている。
流れとしては、
気になった時に、バックログを積み上げる。 ポイントで見積もる。 スプリントにする。
みたいな感じ。
いいなと思うのは、バックログを積み上げた後に、スプリントするものを選ぶこと。そして、スプリントが始まったらバックログは見ない。スプリントの最中も、ボードを見ていて、同時に複数のストーリーが着手されたら危ないことがわかる。
特に僕の場合は、作業をしていると「あ、あれもやりたい」「これもやりたい」みたいなのがたくさん見えてきてしまって、混乱するから、それらをバックログに詰めて、今は見えない状態になってるのは精神的に安定する感じがある。
後、開発速度を上げたい気持ちから、知らず知らずのうちに、ついつい複数のタスクを並列化してしまうことがあるけど、これも良くない。
ボードを見ていると、複数のタスクが進行状態になっているのはよくないことに気付きやすい。開発速度というか、スピードに乗って進められるような仕組みなのがいいように思ってる。
あと、Jiraはバーンアウトチャートとかいろんな観点でレポートを出力できるみたいなので、いろんなレポート見ながら、自分の開発速度を、ふむふむ、とかしたいと思ってる。
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においた。
社内の勉強会で数理最適化の話を聞いた。
そこで数理最適化と機械学習は何が違うの？って話があった。
みたいな話を聞いた。
この話を聞いて、
『あー、機械学習って、確率と統計だし、確かに新しい問題とか未知の問題は解けないよなあ。』とか思った。
あと『数理最適化だと、解きたい問題があって、それに対する理論を作るから、データがなくてもできるなあ』とかも思った。数理最適化は、理論で問題を解くようなイメージで理解した。
改めて聞いたことを振り返りながら書いていく。
まず、数理最適化には、３つの重要な要素があるらしい。で、その３つの重要な要素は、
らしい。
名称が数学っぽくて、理解のオーバーヘッドになってるので、個人的な理解で言い換えると、
みたいなイメージ。
と言うのが今のところの個人的な理解。
この変数と目的関数と制約条件を元に問題がといていく。
この変数、目的関数、制約条件を元に問題を解いてくれるソフトウェアをソルバーと言うらしい。
class Solver: def __init__(self, 変数, 目的関数, 制約条件): pass def solve(self): pass
僕のイメージはこう言うイメージ。
それから数理最適化には、典型問題と言うのがあるらしい。
よくわかってないけど、典型的な問題だと思う。『これは、〇〇問題だね！』的な使い方をすると理解した。
多分、デザインパターンとかアーキテクチャパターンとか、みたいな何かなのかなと思って話を聞いていた。
典型問題には、比較的簡単な計算コストが低い問題もあれば、計算コストが高い問題があるらしい。
O(NN)の問題を解くのは無理です。みたいな話。
はい。
典型問題はたくさんあるらしいけど、すぐに理解するのは難しそうだなあという印象を受けた。
あとは、Qiitaに参考になる記事がたくさんあるよ、という話も聞いた。
個人的な感想としては、面白いし、もっと勉強したいなと思った。
機械学習は、データを使うことを前提としていて、ボトムアップなアプローチだけど、数理最適化は、知恵を使うことを前提にしていて、トップダウンなアプローチ。みたいな印象を受けた。
どっちがいいとかじゃなくて、バランスよく使えるようになりたいなあ、という気持ち
アジャイルな見積もりと計画づくりを読んでる。
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
今回は、５章を読んでいて思ったことを書く。
５章は、「理想日による見積もり」について書いていた。
理想日について考える前に、理想時間と現実時間について説明されていた。
理想時間とは、何かをするのにかかる時間のうち、周辺の作業を差し引いたものらしい。 それに対して、現実時間は、実際にかかる時間らしい。 誰かに見積もりを聞かれた時は、現実時間を答えるのが、良さそうという話も書いていた。
一般的に、理想時間の方が簡単で正確に見積もれるということも書いていた。 なぜ、現実時間の見積もりが難しいかというと、怪我とかアクシデントとか、偶発的な出来事で変化したり、チームの流儀や環境の影響を受けて、変化するからだという話。
スポーツ、例えば、サッカーとか野球の試合時間も同じように現実時間の見積もりが難しい。ロスタイムがどれくらいあるかとか、アクシデントがどうとかが説明されていた。ただ、テレビはスポーツを放送するときに放送時間を決めてそこに収めてくるという話が書いてあった。
そして、テレビがどうやっているのか、という話も説明されていたけど、インタビューとかコマーシャルを使って、時間を埋めたり、延長したりしていると書いてあった。
ただ、それに視聴者は驚かないという話もしていた。なぜ驚かないかというと、変化することを知っているから。しかし、ソフトウェアの開発では、締め切りが伸びると驚く。なぜ驚くかというと、ソフトウェアの開発でスケジュールが変化することを知らないからという話を書いていた。
なるほどなあ。
スケジュールはあくまで雰囲気だという話なのかなあ。よくわからん。難しい。
どっちにしても、スケジュールを守るように努力はした方がいいと思う。ただ、必ずスケジュール通りにならないということは理解しておいた方がいいんだろうなあ。と思ったりした。
それから本の中にソフトウェアの開発が伸びる理由は、まず見積もりの段階で、準備、割り込み、知らなかったことが出てきた場合の時間、などを見積もっていないからだと書いてあった。
あと、作業を担当ごとに細かく見積もるのはやめようという話も書いてあった。 なぜ細かく見積もるのをやめた方がいいかというと、細かく見積もりをしたら、それのメンテナンスや管理コストが膨らむし、それに見合うだけの成果が得られない、かららしい。
なるほど。
で、理想日で見積もる場合は、担当を分けずに、ストーリーで見積もった方がいいという話を書いていた。
ストーリーかー、
ふむー。難しい。
で、ここからは僕の感想がメイン。
難しいなあと思う理由について考えてみると、例えば、ストーリーを見積もって、それが１ヶ月かかります。という話になったとして、それって、いつ遅れているとか、進んでるということがわかるのかなあと思った。
スケジュールを計画してる一つの理由が、どれくらいで終わりそうかの目処を立てることだと思ってる。早く終わったら別のことをやりたいし、時間がかかりそうなら、別のことはできないなとか考える。
作業を分けずにストーリーで考えた方がいい、という話が書いてあったけど、ストーリーの単位で進める場合、ストーリーが終わりそうか終わらなさそうかというのは、何を指標にして考えたらいいんだろう。
んー、これまで、作業の数がどれくらい終わったか。というのを使って測っていたりしたけど、そうじゃなくて、全体の雰囲気で測ればいいのかな。
いや、ストーリーをどれくらい実現できているか、なのかな。
いやいや、ストーリーは実現できているかどうか、のTrue/Falseだから、一つのイテレーションで一つのストーリーが消化できるとして、達成できたかできなかったかになるのかな。
だとすると、ちょっと困ることがありそうだなあとか思う。
だって、一つのイテレーションが終わらないと、そのイテレーションでストーリーが実現できたかどうかわからないと、計画の立てようがないんじゃないかなあ。
と思ったけど、よく考えたら、イテレーションの中で、ストーリーが終わってもいいのか。
んー、毎日、計画をアップデートする必要なんかなくて、イテレーションの単位がスケジュールというか、全体の計画を見直しする機会ということになるのかなあ。
どうなんだろう。
よくわかんないなー、とぼんやり考えていた。
もしかして、チケット駆動開発のチケット、という単位と、ストーリーという単位は、似てるのかもしれないなあ
