flake8 vim のプラグインのこと [プログラミング]
プログラマーという仕事にこだわりはない [プログラミング]
今は、たまたま仕事でコードを書いている。
お客さんやプロジェクトの総意として僕がプログラムを書くのが良いという、現状認識で、僕もそう思っているので異存はない。
ただ「俺は一生現役プログラマー」というこだわりでやっているわけではないので、いまだにプログラムを書いているのが、ちょっと不思議な気がする。
いつかまた、進捗管理をしたり、「えすいーさん」と呼ばれて、よろずパソコン相談みたいな仕事をすることもあるだろう。
「nakagami 君には、マネージメントしてもらうから、プログラム書かないで」
と明確に言われたのは 30歳前後だったが、あの頃の縛りは非常にきつかった。
なんせ、自分がやったほうが説明するだけの時間と比較しても早いのに自分で書いちゃいけないんだから。
若い人、協力会社さんに成長してもらうため、という説明をうけて頑張っていたが結局のところ、自分がコード書くくらいの時間かけて説明してもダメな人はそのすぐ辞めちゃうので、僕や会社の力にはならないまま終わっていたように思う。
あの頃は、みんながそれぞれ苦手な（未熟な）仕事をして地雷踏みまくってた。いまでも、世の中の平均って、あんなもんだと思う。
マネージメントする SEは単価は高くてプログラマーは安い、というのはだれかが決めたことだけど、それは発注する側も受注する側も無理な縛りが入っていて、だれも得しない気がする。
どっちも単価は同じ、ってことにして、その時々でやる仕事はいい具合に割り振ればいいのに
お客さんやプロジェクトの総意として僕がプログラムを書くのが良いという、現状認識で、僕もそう思っているので異存はない。
ただ「俺は一生現役プログラマー」というこだわりでやっているわけではないので、いまだにプログラムを書いているのが、ちょっと不思議な気がする。
いつかまた、進捗管理をしたり、「えすいーさん」と呼ばれて、よろずパソコン相談みたいな仕事をすることもあるだろう。
「nakagami 君には、マネージメントしてもらうから、プログラム書かないで」
と明確に言われたのは 30歳前後だったが、あの頃の縛りは非常にきつかった。
なんせ、自分がやったほうが説明するだけの時間と比較しても早いのに自分で書いちゃいけないんだから。
若い人、協力会社さんに成長してもらうため、という説明をうけて頑張っていたが結局のところ、自分がコード書くくらいの時間かけて説明してもダメな人はそのすぐ辞めちゃうので、僕や会社の力にはならないまま終わっていたように思う。
あの頃は、みんながそれぞれ苦手な（未熟な）仕事をして地雷踏みまくってた。いまでも、世の中の平均って、あんなもんだと思う。
マネージメントする SEは単価は高くてプログラマーは安い、というのはだれかが決めたことだけど、それは発注する側も受注する側も無理な縛りが入っていて、だれも得しない気がする。
どっちも単価は同じ、ってことにして、その時々でやる仕事はいい具合に割り振ればいいのに
やることを減らして、かつ早くできればよいという身もふたもない話 [プログラミング]
随分以前に
「効率よくこなしてできるだけ残業しないように」
と繰り返し言われていた気がする。あまりに昔過ぎて忘れかけているが多分最初の会社の課長。
誰も読まないようなドキュメントや形だけの納品物や必要のない会議になどの「やることを減らす」という方向には向かえばよかったけど、実際には「やることは（無駄なことも含めて）効率よく」ということなので、そんな虫のいい話はない。
そういう手間のかかって、頑張っている風に見える
「汗を書く」
手順をやめちゃうと、お客さんから
「手を抜いてる。何もしていない」
と評価されちゃうからなのではないかと。
会社は、無駄な仕事を減らしてできあがったプログラムの出来で評価してもらうように努力するべきだとは思うが、世の中そんな素晴らしい会社ばかりではない。（そして、お客さんも理解あるお客さんばかりではない）
あと、もう１つ「プログラムを早く書いちゃえばよい」という身もふたもない話がある。
時間かかる人はかかるし、早い人は早い。
その差はよく5倍とか20倍とか言われてて、それがほんとだったら、ある人が１ヶ月かかっちゃうものが、優秀な人なら１日でできちゃうことになる。
実際にどれくらいの差があるかは計測してないけど、「効率よく」したら残業が減らせるかどうかなんて微妙な差ではなかろう。少なくともプログラミングの世界で安直に「効率よく」という人は、あまり信用できない。あの時の課長の言う「効率よく」は「一心不乱に」くらいの意味だったのだろうか？結局よくわからない。
身もふたもない話すぎて、そういう見もふたもない話に正面から向き合う場面ってほとんど見かけない。
「効率よくこなしてできるだけ残業しないように」
と繰り返し言われていた気がする。あまりに昔過ぎて忘れかけているが多分最初の会社の課長。
誰も読まないようなドキュメントや形だけの納品物や必要のない会議になどの「やることを減らす」という方向には向かえばよかったけど、実際には「やることは（無駄なことも含めて）効率よく」ということなので、そんな虫のいい話はない。
そういう手間のかかって、頑張っている風に見える
「汗を書く」
手順をやめちゃうと、お客さんから
「手を抜いてる。何もしていない」
と評価されちゃうからなのではないかと。
会社は、無駄な仕事を減らしてできあがったプログラムの出来で評価してもらうように努力するべきだとは思うが、世の中そんな素晴らしい会社ばかりではない。（そして、お客さんも理解あるお客さんばかりではない）
あと、もう１つ「プログラムを早く書いちゃえばよい」という身もふたもない話がある。
時間かかる人はかかるし、早い人は早い。
その差はよく5倍とか20倍とか言われてて、それがほんとだったら、ある人が１ヶ月かかっちゃうものが、優秀な人なら１日でできちゃうことになる。
実際にどれくらいの差があるかは計測してないけど、「効率よく」したら残業が減らせるかどうかなんて微妙な差ではなかろう。少なくともプログラミングの世界で安直に「効率よく」という人は、あまり信用できない。あの時の課長の言う「効率よく」は「一心不乱に」くらいの意味だったのだろうか？結局よくわからない。
身もふたもない話すぎて、そういう見もふたもない話に正面から向き合う場面ってほとんど見かけない。
会社のしがらみを回避して実を取る、いんちきシステム [プログラミング]
昨日は、数ヶ月に１度開かれている以前の職場の人達との飲み会。
驚いたのは、辞めてから４年近く経過するその職場で、僕が片手間で書いたプログラムがまだ使われていて、昨日参加した人がメンテナンスしてくれているらしい。
なんのドキュメントも残してなかったので申しわけない気持ちでいっぱいだ。CSS も何もない Web1.0 なアレをもう５年以上使ってるのか。
もう、いつ頃最初のリリースだったのか覚えてないけど 10年近く使っているのかもしれない。
それのことをちょっと思い出している。
紙で提出されていた申請書を担当部署が保存。必要なら紙を探していたものを以下のように変更した
1. 申請者がイントラ上の Web のフォームから必要事項を入力（SQL Server にしまう）
2. 申請者がPDF のフォームフィールドに埋め込んだ申請書を印刷
3. 申請者が印刷した紙にハンコを押して（社内順番にハンコ押されて）担当部署に提出
4. 担当部署は必要な時に 1. で入力されたデータを検索
システム化という意味ではまったくダメで、本来はユーザーをちゃんと管理すべきなんだろうし、紙も廃止すべきなんだろう。きちんとした認証はなく電子的には誰が出したかは自己申告的な記入だけで認証、承認についてあくまでも「紙」で行うことに変わりなかった。
まぁ、でっかい Excel にみんなが記入しているようなもんだ。
担当部署としては、キングファイルにいっぱいある申請書類から必要な検索を素早くしたかった。（さらには 1. から 3.までにタイムラグがあるのだが、担当部署に紙が到着する以前にも検索したかった）
社内の内規上は引き続き紙で出せばよいことになっていて（内規を変更するのはもの凄く大変で、紙で提出している申請書のフォーマットや入力項目を変更するのさえも大変な仕事だった）
Web フォームから項目を入力するのはあくまでも担当部署のお願いという形だったが、申請者は、以前に申請したものの入力が再利用できるので、まぁ、使ってくれているという、微妙なものだった。
本来は関係部署にネゴしたり内規を変更したりしないといけなかったのかもしれないけど、最初に企画した担当者の人も、
「ダマでやっちゃってるんですよねー」
と言っていた。
実際、Web のフォームから入力する任意の入力項目で、紙の申請書の「欄外」に印刷しているものがあった。
結局のところ、誰も損する人がいなかったのでうまく回っていたいんちきなシステムだった。
試行錯誤が激しくて、開発を始めたときは最終的にあんな形になるとは誰も思ってなかった。
仕様を事前に決めて決裁をとってベンダーに発注してたら、きっとうまくいかなかったであろうあれが、こんなにも長く使われているのは感慨深い
驚いたのは、辞めてから４年近く経過するその職場で、僕が片手間で書いたプログラムがまだ使われていて、昨日参加した人がメンテナンスしてくれているらしい。
なんのドキュメントも残してなかったので申しわけない気持ちでいっぱいだ。CSS も何もない Web1.0 なアレをもう５年以上使ってるのか。
もう、いつ頃最初のリリースだったのか覚えてないけど 10年近く使っているのかもしれない。
それのことをちょっと思い出している。
紙で提出されていた申請書を担当部署が保存。必要なら紙を探していたものを以下のように変更した
1. 申請者がイントラ上の Web のフォームから必要事項を入力（SQL Server にしまう）
2. 申請者がPDF のフォームフィールドに埋め込んだ申請書を印刷
3. 申請者が印刷した紙にハンコを押して（社内順番にハンコ押されて）担当部署に提出
4. 担当部署は必要な時に 1. で入力されたデータを検索
システム化という意味ではまったくダメで、本来はユーザーをちゃんと管理すべきなんだろうし、紙も廃止すべきなんだろう。きちんとした認証はなく電子的には誰が出したかは自己申告的な記入だけで認証、承認についてあくまでも「紙」で行うことに変わりなかった。
まぁ、でっかい Excel にみんなが記入しているようなもんだ。
担当部署としては、キングファイルにいっぱいある申請書類から必要な検索を素早くしたかった。（さらには 1. から 3.までにタイムラグがあるのだが、担当部署に紙が到着する以前にも検索したかった）
社内の内規上は引き続き紙で出せばよいことになっていて（内規を変更するのはもの凄く大変で、紙で提出している申請書のフォーマットや入力項目を変更するのさえも大変な仕事だった）
Web フォームから項目を入力するのはあくまでも担当部署のお願いという形だったが、申請者は、以前に申請したものの入力が再利用できるので、まぁ、使ってくれているという、微妙なものだった。
本来は関係部署にネゴしたり内規を変更したりしないといけなかったのかもしれないけど、最初に企画した担当者の人も、
「ダマでやっちゃってるんですよねー」
と言っていた。
実際、Web のフォームから入力する任意の入力項目で、紙の申請書の「欄外」に印刷しているものがあった。
結局のところ、誰も損する人がいなかったのでうまく回っていたいんちきなシステムだった。
試行錯誤が激しくて、開発を始めたときは最終的にあんな形になるとは誰も思ってなかった。
仕様を事前に決めて決裁をとってベンダーに発注してたら、きっとうまくいかなかったであろうあれが、こんなにも長く使われているのは感慨深い
ノーチラステクノロジーの西鉄ストアの件 [プログラミング]
赤裸々な報告来た
http://www.publickey1.jp/blog/13/post_228.html
http://www.publickey1.jp/blog/13/post_229.html
最初にプレスリリースが打たれた時には
「基幹系をクラウドで Hadoop で Asakusa フレームワークで、ドヤ！」
って話だったので、ちょっと否定的な感情をもってしまった。
ここに来て本音の話で一気に共感が得られた。
- SQL をうまく書ける人が少ないので Hadoop （汎用機からの移行だからな）
- プロマネがどんどん病気になった
- 和製クラウドは実力不足で高い
- 別のクラウドを使おうとしていたが安定しないので、たまらず急遽 AWS に移行
自分が、以前に相手をしていたお客さんの企業文化が前例主義というか融通の聞かないほうだったのかもしれないけど、ノーチラスさんよりも、お客さんの西鉄さんが臨機応変に対応したのが偉かったなぁ、というのが率直な感想。
http://www.publickey1.jp/blog/13/post_228.html
http://www.publickey1.jp/blog/13/post_229.html
最初にプレスリリースが打たれた時には
「基幹系をクラウドで Hadoop で Asakusa フレームワークで、ドヤ！」
って話だったので、ちょっと否定的な感情をもってしまった。
ここに来て本音の話で一気に共感が得られた。
- SQL をうまく書ける人が少ないので Hadoop （汎用機からの移行だからな）
- プロマネがどんどん病気になった
- 和製クラウドは実力不足で高い
- 別のクラウドを使おうとしていたが安定しないので、たまらず急遽 AWS に移行
自分が、以前に相手をしていたお客さんの企業文化が前例主義というか融通の聞かないほうだったのかもしれないけど、ノーチラスさんよりも、お客さんの西鉄さんが臨機応変に対応したのが偉かったなぁ、というのが率直な感想。
最近勉強できてない [プログラミング]
最近勉強できてない。特に本を読んでない。
昔は、結構本読んだんだけど、最近は時間が取れないし集中力がない。
世の中、本を読んで知識ばっかりついて、でもそれが机上の知識で
実践されてない、っていうこともある。
そういうふうにだけはならないように、素振りは書かさないようにしてる。
http://nakagami.blog.so-net.ne.jp/2013-01-27-1
でも今は、知識が足りてない。Web で簡単に手に入るような Tips
みたいなのじゃなくて、もっと体系だった一貫した教養が欲しい。
若い勉強してる人の知識にとても敵わないことをひしひしと感じる。
・・・とばかりも言ってられないので、なんとかせんとな、と思う今日この頃。
どうしても、 Web とか Python とか RDBMS とかの知識に偏りがちだけど、そうじゃない新しいことを勉強しないといけない気がしてる。
若い頃はあんまり思わなかったんだけれども、最近になって僕も大学で情報系の専門教育受けておいたほうが良かったのかなぁ、と思わなくもない。「大学の勉強なんて役に立たない」なんて、とんでもない話だよ。
昔は、結構本読んだんだけど、最近は時間が取れないし集中力がない。
世の中、本を読んで知識ばっかりついて、でもそれが机上の知識で
実践されてない、っていうこともある。
そういうふうにだけはならないように、素振りは書かさないようにしてる。
http://nakagami.blog.so-net.ne.jp/2013-01-27-1
でも今は、知識が足りてない。Web で簡単に手に入るような Tips
みたいなのじゃなくて、もっと体系だった一貫した教養が欲しい。
若い勉強してる人の知識にとても敵わないことをひしひしと感じる。
・・・とばかりも言ってられないので、なんとかせんとな、と思う今日この頃。
どうしても、 Web とか Python とか RDBMS とかの知識に偏りがちだけど、そうじゃない新しいことを勉強しないといけない気がしてる。
若い頃はあんまり思わなかったんだけれども、最近になって僕も大学で情報系の専門教育受けておいたほうが良かったのかなぁ、と思わなくもない。「大学の勉強なんて役に立たない」なんて、とんでもない話だよ。
java.nio.ByteBuffer のことおぼえ書き [プログラミング]
とある Java のソースを読んで、いまいちよくわからない。
java.nio のクラスでのファイルの読み書きのことがわかってないからだということがわかってきたので、まずはその辺りをお勉強。
ByteBuffer とは？
http://yanchde.gozaru.jp/java/nio/using_byte_buffer.html
http://www.javainthebox.net/publication/200303JP29/ByteBuffer.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20060417/235453/
- Byte列を保持するバッファー
- バッファーのサイズ capacity と、読み書きできる限界 limit を別々に設定できる
- position を持っていて get() で（内部的に）インクリメントされてく
- 文字列を保持する版の java.nio.CharBuffer というのもある
java.nio.FileChannel のインスタンスの read(), write() にパラメータとして渡され、ファイルの読み書きのバッファーになる。 ByteBuffer に読み書きする長さが入っているので FileChannel の read(), write() に長さを指定するパラーメターはない。
http://www.javainthebox.net/publication/200303JP29/ByteChannel.html
読み込み、書き込みができたバイト数は read() write() の戻り値
http://itpro.nikkeibp.co.jp/article/COLUMN/20060424/236102/
ByteBuffer → CharBuffer →文字列変換
http://stackoverflow.com/questions/11202950/convert-a-part-of-bytebuffer-back-to-string
Byte列で読み取って CharBuffer に変換して、変換しきれないところはremainning() で取って来れるということなんだな、きっと。
なぜにこういうのが必要になったか？とか、ByteやChar の配列じゃだめなのか？というのはよくわかってないが、ライブラリの挙動としてはわかった。
java.nio のクラスでのファイルの読み書きのことがわかってないからだということがわかってきたので、まずはその辺りをお勉強。
ByteBuffer とは？
http://yanchde.gozaru.jp/java/nio/using_byte_buffer.html
http://www.javainthebox.net/publication/200303JP29/ByteBuffer.html
http://itpro.nikkeibp.co.jp/article/COLUMN/20060417/235453/
- Byte列を保持するバッファー
- バッファーのサイズ capacity と、読み書きできる限界 limit を別々に設定できる
- position を持っていて get() で（内部的に）インクリメントされてく
- 文字列を保持する版の java.nio.CharBuffer というのもある
java.nio.FileChannel のインスタンスの read(), write() にパラメータとして渡され、ファイルの読み書きのバッファーになる。 ByteBuffer に読み書きする長さが入っているので FileChannel の read(), write() に長さを指定するパラーメターはない。
http://www.javainthebox.net/publication/200303JP29/ByteChannel.html
読み込み、書き込みができたバイト数は read() write() の戻り値
http://itpro.nikkeibp.co.jp/article/COLUMN/20060424/236102/
ByteBuffer → CharBuffer →文字列変換
http://stackoverflow.com/questions/11202950/convert-a-part-of-bytebuffer-back-to-string
Byte列で読み取って CharBuffer に変換して、変換しきれないところはremainning() で取って来れるということなんだな、きっと。
なぜにこういうのが必要になったか？とか、ByteやChar の配列じゃだめなのか？というのはよくわかってないが、ライブラリの挙動としてはわかった。
（秘密だけど）プログラマーの勧め [プログラミング]
ほとんどの人が高校まで卒業する日本では、プログラミングに必要な数学は、ほとんどの子が学んでいるといってよいだろう。僕自身は高校の数学が必要になったのはこともあるが、ほとんどは中学までの数学で仕事はできるはずだ。
体力も使わないから年をとってもできる。
どう考えても、平均年齢 65歳の農業従事者よりも体力的に楽だ。
年齢も性別も国籍も学歴も差別なく働ける。
３年以上は経験年数もあまり関係ないので、産休、育休のあとだって復帰しやすいように思う。
介護の仕事よりは収入も良いようだ。
資源のない国で、いま一番お勧めの職業なんだけど、なんだか最近はあんまり人気がないらしい。
なんでかな。
体力も使わないから年をとってもできる。
どう考えても、平均年齢 65歳の農業従事者よりも体力的に楽だ。
年齢も性別も国籍も学歴も差別なく働ける。
３年以上は経験年数もあまり関係ないので、産休、育休のあとだって復帰しやすいように思う。
介護の仕事よりは収入も良いようだ。
資源のない国で、いま一番お勧めの職業なんだけど、なんだか最近はあんまり人気がないらしい。
なんでかな。
念力デバッグ [プログラミング]
いろんな開発の仕事をしていると、時にもの凄くデバッグのしづらい環境で開発しなくちゃならなくなることがある。
一番厳しかったのは、大昔、 HP-UX 9.05 で数値計算のプログラムでどこかでメモリを壊して OS がリブートする状態になってしまったときだ。
（今なら、どんなプログラム書いても OS がリブートすることなんてなかろう）
猛烈に再帰しているどっかがだめだと思うのだが、一度実行すると、 OS がリブートして fsck が走って再度、もとの状態にするまでに 15分くらいかかった。
幸い、ファイルシステムが壊れるようなことはなかったけど、どこかに print 文を入れて実行しても、１時間に4回しか実行できない。 これはヤバい。納期に間に合わない。
あの時は、最高に真剣にソースを読んで机上デバッグした。
以来、テストランしたりデバッガーを使ったりする前にできるだけソースコードを読んで理解しようとするようになった。
デバッガーを使うような場合でも、あらかじめソースコードを読んでおいたほうが捗る。
今までの周りの人も四六時中デバッガー使ってる人は仕事が遅かったし、仕事の早い人はソースコードを読んで考えてる。あの時、念力デバッグを強いられたのは非常に良かった
一番厳しかったのは、大昔、 HP-UX 9.05 で数値計算のプログラムでどこかでメモリを壊して OS がリブートする状態になってしまったときだ。
（今なら、どんなプログラム書いても OS がリブートすることなんてなかろう）
猛烈に再帰しているどっかがだめだと思うのだが、一度実行すると、 OS がリブートして fsck が走って再度、もとの状態にするまでに 15分くらいかかった。
幸い、ファイルシステムが壊れるようなことはなかったけど、どこかに print 文を入れて実行しても、１時間に4回しか実行できない。 これはヤバい。納期に間に合わない。
あの時は、最高に真剣にソースを読んで机上デバッグした。
以来、テストランしたりデバッガーを使ったりする前にできるだけソースコードを読んで理解しようとするようになった。
デバッガーを使うような場合でも、あらかじめソースコードを読んでおいたほうが捗る。
今までの周りの人も四六時中デバッガー使ってる人は仕事が遅かったし、仕事の早い人はソースコードを読んで考えてる。あの時、念力デバッグを強いられたのは非常に良かった
コードを書くのは僕でもできますよ [プログラミング]
人手が足りなくなると人が追加される。
それはいい。機能を分割して分担できるようにすれば人月の割り算とはいわないでも、トータルで完成する時間を短縮できる。
だけど
「○○さんに仕様を説明して実装してもらって」
というのは、もともといる人間にしてみたら、なかなかつらい。
機能を説明して実装してもらうと、微妙に、時にはまったく欲しいものと違うものができる。
なぜそれが必要かという要件にさかのぼって理解して実装してもらって、仕様に問題がないか、それがそもそも発注者（使用者）の意図しているものか、から考えて実装してもらわないと、もともといた人にのっては時間を食うばかりで時間短縮になっていない。
仕様の説明＋できたものの評価 > 自分で実装した場合の労力
昔に比べて仕様をきちんと決めて実装より見切り発車が多いのと、プログラミング言語の生産性が格段に上がっているせいだと思う。昔は、本当に、いわれた通りのものを C 言語で書きます、ってだけで職業として価値があったけど、プログラミング言語の表現力のアップもあって、それだけだと価値がなくなってきているように思う。
ひとことで言えば
「コードを書いてもらうだけでは意味がない。コードを書くのは僕でもできますよ」
ということだ。
最近の若い人達は、昔のプログラムを書くだけの人が役立つ場面がなくなって、若い修行の時期にも即戦力が求められて大変だなぁ、とは思う。
それはいい。機能を分割して分担できるようにすれば人月の割り算とはいわないでも、トータルで完成する時間を短縮できる。
だけど
「○○さんに仕様を説明して実装してもらって」
というのは、もともといる人間にしてみたら、なかなかつらい。
機能を説明して実装してもらうと、微妙に、時にはまったく欲しいものと違うものができる。
なぜそれが必要かという要件にさかのぼって理解して実装してもらって、仕様に問題がないか、それがそもそも発注者（使用者）の意図しているものか、から考えて実装してもらわないと、もともといた人にのっては時間を食うばかりで時間短縮になっていない。
仕様の説明＋できたものの評価 > 自分で実装した場合の労力
昔に比べて仕様をきちんと決めて実装より見切り発車が多いのと、プログラミング言語の生産性が格段に上がっているせいだと思う。昔は、本当に、いわれた通りのものを C 言語で書きます、ってだけで職業として価値があったけど、プログラミング言語の表現力のアップもあって、それだけだと価値がなくなってきているように思う。
ひとことで言えば
「コードを書いてもらうだけでは意味がない。コードを書くのは僕でもできますよ」
ということだ。
最近の若い人達は、昔のプログラムを書くだけの人が役立つ場面がなくなって、若い修行の時期にも即戦力が求められて大変だなぁ、とは思う。
