速く書くのではなく間に合うようにする [プログラミング]
「nakagami さんはプログラム書くの速いので・・・」
と、仕事の中の会話の中で言われたことがあって、（うーん、なんかそれ違うなぁ）と思ったことがあった。書く速度でいったら普通だし、僕よりもっとちゃんと、速く書ける人はいっぱいいると思う。
僕が常に「間に合うようにするにはどうしたらよいか」ということを考えているのが、速く書けてると感じられているのではなかろうか。
仕事としてプログラムを書いている以上は、間に合わなければどんなに立派なプログラムでも意味がない、と思っている。
機能が足りなくても、テストが書いてなくても、さらに状況によってはバグがあっても（そのバグが把握できているのならば）間に合わない立派なプログラムよりも、間に合う不都合のあるもののほうが、100倍ましだ。
時には、不具合だらけで仕様も満たしていなくも、本当に大切な部分がかろうじて動いて、ビジネスとして破綻しないためには、どうすればいいだろうか？そんなことをいつも考えている。
僕が書くプログラムは時には粗雑で、その場しのぎで、
「こんなゲームじゃおもしろくないからダメですよ」
みたいに言われたこともある（実際それは作り直しになった）。
しかし、でき上がってみないとソフトウェアの評価なんてできなくて、そのダメなのだって、僕が形にしなかったら、ダメかどうかなんてわからなかったわからず、いつまでも、素晴らしいヒラメキで右往左往して完成しなかったろう。僕は、あのとき一旦完成したものがダメだしされたことで、僕のやり方は間違ってないと思うようになった。
今思えば、僕が社会人として最初に入った会社が工数管理に厳しくて、15分単位に作業時間を計測してた。
そして、その後に転職を繰り返すたびに「えっ、こんなにいい加減でいいの？」と思うことが多かった。ソフトウェアは、製造業とは違うので、最初の会社のあれはあれで色々と問題あったのだが、一方で、いわゆる Web 業界（特に自社サービスを提供している会社）は、理想ばかりを追求してると、何も進まないのではないかなぁ、と思うところ。
と、仕事の中の会話の中で言われたことがあって、（うーん、なんかそれ違うなぁ）と思ったことがあった。書く速度でいったら普通だし、僕よりもっとちゃんと、速く書ける人はいっぱいいると思う。
僕が常に「間に合うようにするにはどうしたらよいか」ということを考えているのが、速く書けてると感じられているのではなかろうか。
仕事としてプログラムを書いている以上は、間に合わなければどんなに立派なプログラムでも意味がない、と思っている。
機能が足りなくても、テストが書いてなくても、さらに状況によってはバグがあっても（そのバグが把握できているのならば）間に合わない立派なプログラムよりも、間に合う不都合のあるもののほうが、100倍ましだ。
時には、不具合だらけで仕様も満たしていなくも、本当に大切な部分がかろうじて動いて、ビジネスとして破綻しないためには、どうすればいいだろうか？そんなことをいつも考えている。
僕が書くプログラムは時には粗雑で、その場しのぎで、
「こんなゲームじゃおもしろくないからダメですよ」
みたいに言われたこともある（実際それは作り直しになった）。
しかし、でき上がってみないとソフトウェアの評価なんてできなくて、そのダメなのだって、僕が形にしなかったら、ダメかどうかなんてわからなかったわからず、いつまでも、素晴らしいヒラメキで右往左往して完成しなかったろう。僕は、あのとき一旦完成したものがダメだしされたことで、僕のやり方は間違ってないと思うようになった。
今思えば、僕が社会人として最初に入った会社が工数管理に厳しくて、15分単位に作業時間を計測してた。
そして、その後に転職を繰り返すたびに「えっ、こんなにいい加減でいいの？」と思うことが多かった。ソフトウェアは、製造業とは違うので、最初の会社のあれはあれで色々と問題あったのだが、一方で、いわゆる Web 業界（特に自社サービスを提供している会社）は、理想ばかりを追求してると、何も進まないのではないかなぁ、と思うところ。
素振りプログラミングのテーマ選び [プログラミング]
今年になって、仕事とは関係ない素振りプログラミングの重要性について書いた。
http://nakagami.blog.so-net.ne.jp/2013-01-06
経験を積み、仕事とは関係ない知識を得るという意味で、素振りプログラミングが必要と思っているが、せっかくなので、その成果が世の中で影響を与えられれば良いなぁ、と思っている。
自分の力量と余暇に割ける時間と、プロダクトの状況を考えて素振りプログラミングのテーマを考えている。有名だったり大規模だったりするプロダクトには参加している人も多いしし、みんな僕より詳しいし、せっかく何か作っても使ってもらえる余地が少ない。しかし、誰も使いそうにないものを作っても（自分だけが使えば良いでは）モチベーションが続かない。余暇の時間でやるのであれば、あまりに大規模なものは無理だが、かといって、あまりに手軽なものではチャレンジにならない。自分の能力ギリギリで、他人に評価されるものを作って、自分の能力ギリギリがアップしたら、もうちょっと高度なものが作れる。そんなふうにしていきたい。
例えば、 Firebird のデータベースドライバなら、僕にもなんとかなりそうで、かつ他にやってる人もいなさそう・・・とか。これが、 MySQL や PostgreSQL では同じようにはいかない。
僕には、 Web フレームワークを上手く作る自信もないし、Python の Web フレームワークは優秀なのが沢山あるのでそういうのは作らないだろう。
有名な Python のプロダクトのコミッターを目指すべく pull request を送るというのもいいとは思うんだけど、僕の英語力と、知識力では無理だろう。作る比率が多いほうがいい。
最近だと Pillow の python3 porting も、自分ならギリギリできそうで、ほかに誰もやらなさそうだったからチャレンジしてみた（実際には、やってた人いたけど）
http://nakagami.blog.so-net.ne.jp/2013-01-11
金曜の夜、会社の人と飲みにいった時に、そんな話になって「何を作るかは、いろいろ狙ってやってるんですよ」という話をしたので、自分の考える狙いどころについて書いておくことにした。
できることなら、だれも手を出してないテーマで成果を出せたところで大ブレイクとなるといいんだけど、そういうのって、論文のテーマ選びにちょっと似てるのかなぁ。学術の世界にいたことないのでよくわからないけど
http://nakagami.blog.so-net.ne.jp/2013-01-06
経験を積み、仕事とは関係ない知識を得るという意味で、素振りプログラミングが必要と思っているが、せっかくなので、その成果が世の中で影響を与えられれば良いなぁ、と思っている。
自分の力量と余暇に割ける時間と、プロダクトの状況を考えて素振りプログラミングのテーマを考えている。有名だったり大規模だったりするプロダクトには参加している人も多いしし、みんな僕より詳しいし、せっかく何か作っても使ってもらえる余地が少ない。しかし、誰も使いそうにないものを作っても（自分だけが使えば良いでは）モチベーションが続かない。余暇の時間でやるのであれば、あまりに大規模なものは無理だが、かといって、あまりに手軽なものではチャレンジにならない。自分の能力ギリギリで、他人に評価されるものを作って、自分の能力ギリギリがアップしたら、もうちょっと高度なものが作れる。そんなふうにしていきたい。
例えば、 Firebird のデータベースドライバなら、僕にもなんとかなりそうで、かつ他にやってる人もいなさそう・・・とか。これが、 MySQL や PostgreSQL では同じようにはいかない。
僕には、 Web フレームワークを上手く作る自信もないし、Python の Web フレームワークは優秀なのが沢山あるのでそういうのは作らないだろう。
有名な Python のプロダクトのコミッターを目指すべく pull request を送るというのもいいとは思うんだけど、僕の英語力と、知識力では無理だろう。作る比率が多いほうがいい。
最近だと Pillow の python3 porting も、自分ならギリギリできそうで、ほかに誰もやらなさそうだったからチャレンジしてみた（実際には、やってた人いたけど）
http://nakagami.blog.so-net.ne.jp/2013-01-11
金曜の夜、会社の人と飲みにいった時に、そんな話になって「何を作るかは、いろいろ狙ってやってるんですよ」という話をしたので、自分の考える狙いどころについて書いておくことにした。
できることなら、だれも手を出してないテーマで成果を出せたところで大ブレイクとなるといいんだけど、そういうのって、論文のテーマ選びにちょっと似てるのかなぁ。学術の世界にいたことないのでよくわからないけど
大元のリポジトリの修正を自分のリポジトリにマージしたい [プログラミング]
ここにある↓ことと同じようなことをしたい
http://bayashi.net/diary/2012/0714
本当は、やりたいことは逆で、自分のリポジトリに、別のリポジトリの変更をマージしたい
$ git clone git@github.com:nakagami/Pillow.git
$ cd Pillow
$ git remote -v
origin git@github.com:nakagami/Pillow.git (fetch)
origin git@github.com:nakagami/Pillow.git (push)
$ git remote add maint git://github.com/python-imaging/Pillow.git
$ git remote -v
maint git://github.com/python-imaging/Pillow.git (fetch)
maint git://github.com/python-imaging/Pillow.git (push)
origin git@github.com:nakagami/Pillow.git (fetch)
origin git@github.com:nakagami/Pillow.git (push)
$ git pull maint master
これで、自分のリポジトリの master に、大元のリポジトリの master をマージできた
http://bayashi.net/diary/2012/0714
本当は、やりたいことは逆で、自分のリポジトリに、別のリポジトリの変更をマージしたい
$ git clone git@github.com:nakagami/Pillow.git
$ cd Pillow
$ git remote -v
origin git@github.com:nakagami/Pillow.git (fetch)
origin git@github.com:nakagami/Pillow.git (push)
$ git remote add maint git://github.com/python-imaging/Pillow.git
$ git remote -v
maint git://github.com/python-imaging/Pillow.git (fetch)
maint git://github.com/python-imaging/Pillow.git (push)
origin git@github.com:nakagami/Pillow.git (fetch)
origin git@github.com:nakagami/Pillow.git (push)
$ git pull maint master
これで、自分のリポジトリの master に、大元のリポジトリの master をマージできた
素振りプログラミング [プログラミング]
いつの頃からか、業務とは関連のないプログラムを書いて公開することを自分の課題にしている。いわゆる素振り。素振りプログラミング。
若い頃は、業務以外の勉強といえば知識が足りてないので本を読むようにしてた。
最初の頃に勉強した Unix とかネットワークプログラミングのことはいまだに役立っている。
しかし、10年程前からは、本を読んで勉強しても使わなかったらそれっきり廃れる刹那的なものが多くて、こういうのに時間を使っても、それを役立てることができなきゃ意味ないな、というような状況になってきた。
ドキュメント和訳とか、勉強会を主催とか、イベント運営に参加するとか、いろんな取り組みはあると思うんだけど英語力もないし、博識でもないし、まぁプログラミングならできるだろうということで
意識的に素振りプログラミングに取り組むようにしてる。
自分でいうと仕事のプログラミングは、所謂 Web プログラミングなので、そこを外せば、素振りプログラミングで勉強になることはいっぱいある。
昨年の PyCon JP 2012 で「作る系の話が少なかったね」という声が多かったので皆さん、素振りプログラミングしましょう
若い頃は、業務以外の勉強といえば知識が足りてないので本を読むようにしてた。
最初の頃に勉強した Unix とかネットワークプログラミングのことはいまだに役立っている。
しかし、10年程前からは、本を読んで勉強しても使わなかったらそれっきり廃れる刹那的なものが多くて、こういうのに時間を使っても、それを役立てることができなきゃ意味ないな、というような状況になってきた。
ドキュメント和訳とか、勉強会を主催とか、イベント運営に参加するとか、いろんな取り組みはあると思うんだけど英語力もないし、博識でもないし、まぁプログラミングならできるだろうということで
意識的に素振りプログラミングに取り組むようにしてる。
自分でいうと仕事のプログラミングは、所謂 Web プログラミングなので、そこを外せば、素振りプログラミングで勉強になることはいっぱいある。
昨年の PyCon JP 2012 で「作る系の話が少なかったね」という声が多かったので皆さん、素振りプログラミングしましょう
Cython 入門 [プログラミング]
冬休みの課題として Cython の勉強をした。
ありがたいことに、増田さんがドキュメント和訳をしてくれている
http://omake.accense.com/wiki/CythonTranslation
.py のファイルを .pyx に拡張子を変更して
↓にある distutils のように Cythonモジュールをビルドするのようにすると
http://omake.accense.com/static/doc-ja/cython/src/quickstart/build.html
import できる *.so ファイルができて、これでだけで３割くらい速くなる。
ただ、全ての python コードが、この形式でビルドできるかは不明。かなりのパターンではできそう。
cdef って宣言して型定義をする↓と、３〜５倍くらいには速くなる感じ
http://omake.accense.com/static/doc-ja/cython/src/quickstart/cythonize.html
ただ、関数テーブル（item に関数が設定された辞書とか）は cdef って定義して python コードから呼び出すことはできないので、何でも cdef って宣言して高速化できるわけじゃない
いろいろ試行錯誤してみたけど、C 言語で書いたモジュールと同じ速度を目指すのは無理。
数値計算みたいなのは何十倍も速くなるかもしれないけど、 I/O が多い普通の python コードをチューニングしても 3 〜 5倍くらいかと思われ。C 言語で python モジュールを書いたのと比べて 1/2 〜 1/3 くらいの速度？
pure python で書かれている関数、メソッド呼び出しに時間がかかるようなので、ループしている内部の呼び出し先の関数・メソッドを cdef に置き換えていくと速くなる。辞書の参照は cdefで型定義している 内部でも python のコードでも同じコードになるようで、そういうのはあまり速くならない。結局のところ速くなりそうな部分と速くならなさそうなところはある。
ここ、3日ばかりの試行錯誤で、頑張って C の関数を呼んで高速化しようとして、ほとんど誤差範囲でがっかりしたことのほうが多いので、適当なところで諦めるのが、Cython を使った高速化で必要なスキルかな、と思ったりした。
もちろん、数倍のオーダーで速くなることもありがたいけど、C 言語のコードをリンクできることのメリットのが大きいのかな、という印象を受けた。
なんか、numpy とか OpenMP とか、数値計算で使うのに便利なことがいっぱいありそうなんだけど、今のところ自分が使うことなさそうなので、冬休みの入門終わり。
ありがたいことに、増田さんがドキュメント和訳をしてくれている
http://omake.accense.com/wiki/CythonTranslation
.py のファイルを .pyx に拡張子を変更して
↓にある distutils のように Cythonモジュールをビルドするのようにすると
http://omake.accense.com/static/doc-ja/cython/src/quickstart/build.html
import できる *.so ファイルができて、これでだけで３割くらい速くなる。
ただ、全ての python コードが、この形式でビルドできるかは不明。かなりのパターンではできそう。
cdef って宣言して型定義をする↓と、３〜５倍くらいには速くなる感じ
http://omake.accense.com/static/doc-ja/cython/src/quickstart/cythonize.html
ただ、関数テーブル（item に関数が設定された辞書とか）は cdef って定義して python コードから呼び出すことはできないので、何でも cdef って宣言して高速化できるわけじゃない
いろいろ試行錯誤してみたけど、C 言語で書いたモジュールと同じ速度を目指すのは無理。
数値計算みたいなのは何十倍も速くなるかもしれないけど、 I/O が多い普通の python コードをチューニングしても 3 〜 5倍くらいかと思われ。C 言語で python モジュールを書いたのと比べて 1/2 〜 1/3 くらいの速度？
pure python で書かれている関数、メソッド呼び出しに時間がかかるようなので、ループしている内部の呼び出し先の関数・メソッドを cdef に置き換えていくと速くなる。辞書の参照は cdefで型定義している 内部でも python のコードでも同じコードになるようで、そういうのはあまり速くならない。結局のところ速くなりそうな部分と速くならなさそうなところはある。
ここ、3日ばかりの試行錯誤で、頑張って C の関数を呼んで高速化しようとして、ほとんど誤差範囲でがっかりしたことのほうが多いので、適当なところで諦めるのが、Cython を使った高速化で必要なスキルかな、と思ったりした。
もちろん、数倍のオーダーで速くなることもありがたいけど、C 言語のコードをリンクできることのメリットのが大きいのかな、という印象を受けた。
なんか、numpy とか OpenMP とか、数値計算で使うのに便利なことがいっぱいありそうなんだけど、今のところ自分が使うことなさそうなので、冬休みの入門終わり。
今頃 Mac OS 10.6 Snow Leopard [プログラミング]
設定とか面倒で、もう３年も Mac OS 10.5 Leopard のまま頑張ってたけど、10.5 だと、アップデートされないソフトウェアが最近特に増えてきて不便だった。一時期 AppleStore での Mac OS 10.6 Snow Leopard アップグレードのメディア販売をやめてたらしいんだけど、今は販売が再開されてるので、ついに 10.6 にアップグレードすることにした
インストールメディアは、昨日、インターネットの AppleStore で SnowLeopard 購入 1700円。昨日の午前中に決済したら、今日の午前中にヤマト便が届いた。
10.5 をインストールしているのと同じ HDD で違うパーティションに10.6 をインストールしたが、途中で、ユーザーデータのコピー元を聞いてくれて、そこで別パーティションにインストールしてある以前の OS X も指定できるようになってた。TimeMachine にバックアップしたものからの復元はできるとは思っていたが、別パーティションにインストールしてある 10.5 のパーティションから復元できる
とは思わなんだ。
ここまでで、OS X 10.6 のインストールとデータの移行があらかた終わって、予想より大分楽だった。特に、無線LAN の設定とか面倒だなぁ、と思ってたので。これなら通常の週末の作業で移行できたので、もっと早くやっておけば良かった
・・・と思ったが、実は、こっから後が長かった。
次はXcode のインストール。
SnowLeopard 用の Xcode 4 を以前は配布していたようだけど、現在は
無料会員では ADC からダウンロードできないみたい。
野良で配布してるところもあるけど、それってダメだよね？
iOS の開発をするわけじゃないので、 Xcode 3 でも気にしない。
ADC で Xcode 3.2.6 をダウンロードしてインストール。
んでもって、↓ MacPorts。今日の時点で最新でダウンロードできるのは 2.1.2
https://distfiles.macports.org/MacPorts/MacPorts-2.1.2-10.6-SnowLeopard.pkg
MacPorts から git/mercurial インストール
sudo port install git-core
sudo port install mercurial
MySQL 5.5 インストール
sudo port install mysql55 +openssl +system_readline
sudo port install mysql55-server
sudo port load mysql55-server
cd /opt/local/bin/
sudo ln -s /opt/local/lib/mysql55/bin/mysql mysql
sudo ln -s /opt/local/lib/mysql55/bin/mysql_config mysql_config
sudo cp /opt/local/share/mysql55/support-files/macports/my.cnf /opt/local/etc/mysql55/my.cnf
sudo vi /opt/local/etc/mysql55/my.cnf
sudo mkdir -m 700 -p /opt/local/var/db/mysql55
sudo chown _mysql /opt/local/var/db/mysql55
sudo -u _mysql /opt/local/lib/mysql55/bin/mysql_install_db
sudo /opt/local/share/mysql55/support-files/mysql.server start
（起動確認＆接続確認）
デーモンとして起動するようにする
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql55-server.plist
ここまでで、やっぱり一日仕事になってしまった。３年に一回くらいならいいが。Snow Leopard も、もう大分サポートされてないので、来年はもう一回アップグレードしないといけないのかもしれない。
Lion 以降は、あんまり安定してないっぽい印象なので、これは安定しているってバージョンが出るまで Snow Lepard を使っていきたいと思っているのだが。
（追記）Mac Port について
http://www.key-p.com/blog/ohnishi/article.php?id=112
(2015-08-22追記）Yosemite にupdate した時のこと
http://nakagami.blog.so-net.ne.jp/2015-08-22
インストールメディアは、昨日、インターネットの AppleStore で SnowLeopard 購入 1700円。昨日の午前中に決済したら、今日の午前中にヤマト便が届いた。
10.5 をインストールしているのと同じ HDD で違うパーティションに10.6 をインストールしたが、途中で、ユーザーデータのコピー元を聞いてくれて、そこで別パーティションにインストールしてある以前の OS X も指定できるようになってた。TimeMachine にバックアップしたものからの復元はできるとは思っていたが、別パーティションにインストールしてある 10.5 のパーティションから復元できる
とは思わなんだ。
ここまでで、OS X 10.6 のインストールとデータの移行があらかた終わって、予想より大分楽だった。特に、無線LAN の設定とか面倒だなぁ、と思ってたので。これなら通常の週末の作業で移行できたので、もっと早くやっておけば良かった
・・・と思ったが、実は、こっから後が長かった。
次はXcode のインストール。
SnowLeopard 用の Xcode 4 を以前は配布していたようだけど、現在は
無料会員では ADC からダウンロードできないみたい。
野良で配布してるところもあるけど、それってダメだよね？
iOS の開発をするわけじゃないので、 Xcode 3 でも気にしない。
ADC で Xcode 3.2.6 をダウンロードしてインストール。
んでもって、↓ MacPorts。今日の時点で最新でダウンロードできるのは 2.1.2
https://distfiles.macports.org/MacPorts/MacPorts-2.1.2-10.6-SnowLeopard.pkg
sudo port -d selfupdate sudo port -d sync
MacPorts から git/mercurial インストール
sudo port install git-core
sudo port install mercurial
MySQL 5.5 インストール
sudo port install mysql55 +openssl +system_readline
sudo port install mysql55-server
sudo port load mysql55-server
cd /opt/local/bin/
sudo ln -s /opt/local/lib/mysql55/bin/mysql mysql
sudo ln -s /opt/local/lib/mysql55/bin/mysql_config mysql_config
sudo cp /opt/local/share/mysql55/support-files/macports/my.cnf /opt/local/etc/mysql55/my.cnf
sudo vi /opt/local/etc/mysql55/my.cnf
[mysqld] character-set-server=utf8 default-storage-engine = innodb [mysql] default-character-set=utf8
sudo mkdir -m 700 -p /opt/local/var/db/mysql55
sudo chown _mysql /opt/local/var/db/mysql55
sudo -u _mysql /opt/local/lib/mysql55/bin/mysql_install_db
sudo /opt/local/share/mysql55/support-files/mysql.server start
（起動確認＆接続確認）
デーモンとして起動するようにする
sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql55-server.plist
ここまでで、やっぱり一日仕事になってしまった。３年に一回くらいならいいが。Snow Leopard も、もう大分サポートされてないので、来年はもう一回アップグレードしないといけないのかもしれない。
Lion 以降は、あんまり安定してないっぽい印象なので、これは安定しているってバージョンが出るまで Snow Lepard を使っていきたいと思っているのだが。
（追記）Mac Port について
http://www.key-p.com/blog/ohnishi/article.php?id=112
(2015-08-22追記）Yosemite にupdate した時のこと
http://nakagami.blog.so-net.ne.jp/2015-08-22
開発手法だけでは解決しない [プログラミング]
最近は、アジャイルとかスクラムとか注目されているんだそうな。
開発手法でシステム開発が効率化されるならすばらしい。
でも、 XP とか UML とか、いろんなものが輸入されブームになって廃れていく。
今回も、 NTT 系の会社でスクラム導入ってことだけどあまり期待していない。
コンサル業が賑わって公開競争入札の入札条件になって、終わっちゃうんだろうなー。
ちょっと前のはやり言葉でいうと、コードの匂いがしない。
スクラムマスターの認定制度を作って、四択から正解を選ばせるような人間を生産しても、プログラムが書ける人が増える気がしない。スクラムってプログラミングに近いところにあるはずなのに。
いままでのこういう開発手法が、まったく意味のないものだとは思わない。
だけど、それって、高校の野球部でドラッカーのマネージメント手法を
取り入れたり、高度なイメージトレーニングを取り入れたりするのと同じじゃないかな。
そういうのが有効なのって、プロ野球の世界でしょ。
高校生には、走り込みやキャッチボールや素振りが必要なのと同じく、プログラマーには開発手法よりも前にプログラミング経験が必要なんじゃなかろうか。コーディングして、行き詰まって七転八倒して、話はそれからだ。
20年前と比べて、プログラミングに対する環境面でのハードルは凄く下がったけど、世の中のプログラマーは素振りが足りないように思う。
リファクタリングする前にリファクタリング対象になるプログラムをガンガン書こう。
趣味の（勉強の）プログラミングなら、喜んで車輪の再発明をしよう。
車輪の再発明のないところには新しい車輪は産まれないよ。
ひょっとして、よりよいプログラミングのための情報が多すぎて、プログラミングが始められないのかなぁ。セキュリティが・・・Web プログラミングだけがプログラミングじゃないよ。
開発手法でシステム開発が効率化されるならすばらしい。
でも、 XP とか UML とか、いろんなものが輸入されブームになって廃れていく。
今回も、 NTT 系の会社でスクラム導入ってことだけどあまり期待していない。
コンサル業が賑わって公開競争入札の入札条件になって、終わっちゃうんだろうなー。
ちょっと前のはやり言葉でいうと、コードの匂いがしない。
スクラムマスターの認定制度を作って、四択から正解を選ばせるような人間を生産しても、プログラムが書ける人が増える気がしない。スクラムってプログラミングに近いところにあるはずなのに。
いままでのこういう開発手法が、まったく意味のないものだとは思わない。
だけど、それって、高校の野球部でドラッカーのマネージメント手法を
取り入れたり、高度なイメージトレーニングを取り入れたりするのと同じじゃないかな。
そういうのが有効なのって、プロ野球の世界でしょ。
高校生には、走り込みやキャッチボールや素振りが必要なのと同じく、プログラマーには開発手法よりも前にプログラミング経験が必要なんじゃなかろうか。コーディングして、行き詰まって七転八倒して、話はそれからだ。
20年前と比べて、プログラミングに対する環境面でのハードルは凄く下がったけど、世の中のプログラマーは素振りが足りないように思う。
リファクタリングする前にリファクタリング対象になるプログラムをガンガン書こう。
趣味の（勉強の）プログラミングなら、喜んで車輪の再発明をしよう。
車輪の再発明のないところには新しい車輪は産まれないよ。
ひょっとして、よりよいプログラミングのための情報が多すぎて、プログラミングが始められないのかなぁ。セキュリティが・・・Web プログラミングだけがプログラミングじゃないよ。
プログラミングは上達するのか [プログラミング]
ふと、プログラミングは上達するのか？ということを考えた。
新卒で入った会社にアラキさんという先輩がいた。
どんなプロジェクトもいつもデスマで、３年くらいで辞めて別業界に転職した。
なんか、テクニックに走ったり、大量の define を定義したりで、ぱっと見凄い勢いでコーディングが進んでいるように見えたし、ちゃんとプログラムが書けてるように見えた。
ところが、最後はいつも行き詰まって、デスマ。納品したものがメタメタで、納品はしたものの、ほとんど動いてないものもあった。
ソースのぱっと見の見た目を気にするけど、プログラムの構造をシンプルに保ちつつ一貫したポリシーで組み立てる、ということがうまくなかった気がする。
なんとなく、アラキさんは、このまま何年続けても同じなんじゃないかなぁ、と思っていた。転職後、一回だけ会ったときには転職先で幸せそうにしてて、本当によかった。
キクチ君という後輩がいた。５年目くらいのところで、
「nakagamiさん。こんものが机の引き出しから発見されましたよ」
と持って来たのは、入社当初に僕が出した課題プログラムのプログラムリストをプリントした紙だった。
C 言語で、ディレクトリーツリーを辿ってファイル名やファイルサイズを出すようなものだったのだが、そのコードは、インデントが深くなりがちで関数の分割の仕方も微妙で、変数名の付け方もいまいちで、それでもまぁ新人が 200行程度のプログラムを動くように作れたからまぁ良しとしていた
しろもの。
「このころの僕の書くコード、こんなにひどかったんですねぇ」
という言葉を聞いて、キクチ君は上達したんだな。と思った。
キクチ君は、新人の頃のその課題をやっただけで、同じプロジェクトに関わったことはほとんどなかったんだけど、そういうことが言えるくらい立派になったのかと嬉しかった。
キクチ君の前後に何年も、新人の面倒を見たが、手取り足取り教えてもプログラミングが上達する人はするし、しない人は全くしない。
上達しない人は、結局やめちゃう。
僕も、最初の頃は、職業としてプログラマーの道を選んだ仲間なんだから、なんとか一人前になるように・・・
と頑張っていたが、最近は、ちょっと手助けしてダメそうなら、あっさり見限る冷たい人間になってしまった。
どんな人もプログラミングが上達する魔王の指導法があったら知りたい。
新卒で入った会社にアラキさんという先輩がいた。
どんなプロジェクトもいつもデスマで、３年くらいで辞めて別業界に転職した。
なんか、テクニックに走ったり、大量の define を定義したりで、ぱっと見凄い勢いでコーディングが進んでいるように見えたし、ちゃんとプログラムが書けてるように見えた。
ところが、最後はいつも行き詰まって、デスマ。納品したものがメタメタで、納品はしたものの、ほとんど動いてないものもあった。
ソースのぱっと見の見た目を気にするけど、プログラムの構造をシンプルに保ちつつ一貫したポリシーで組み立てる、ということがうまくなかった気がする。
なんとなく、アラキさんは、このまま何年続けても同じなんじゃないかなぁ、と思っていた。転職後、一回だけ会ったときには転職先で幸せそうにしてて、本当によかった。
キクチ君という後輩がいた。５年目くらいのところで、
「nakagamiさん。こんものが机の引き出しから発見されましたよ」
と持って来たのは、入社当初に僕が出した課題プログラムのプログラムリストをプリントした紙だった。
C 言語で、ディレクトリーツリーを辿ってファイル名やファイルサイズを出すようなものだったのだが、そのコードは、インデントが深くなりがちで関数の分割の仕方も微妙で、変数名の付け方もいまいちで、それでもまぁ新人が 200行程度のプログラムを動くように作れたからまぁ良しとしていた
しろもの。
「このころの僕の書くコード、こんなにひどかったんですねぇ」
という言葉を聞いて、キクチ君は上達したんだな。と思った。
キクチ君は、新人の頃のその課題をやっただけで、同じプロジェクトに関わったことはほとんどなかったんだけど、そういうことが言えるくらい立派になったのかと嬉しかった。
キクチ君の前後に何年も、新人の面倒を見たが、手取り足取り教えてもプログラミングが上達する人はするし、しない人は全くしない。
上達しない人は、結局やめちゃう。
僕も、最初の頃は、職業としてプログラマーの道を選んだ仲間なんだから、なんとか一人前になるように・・・
と頑張っていたが、最近は、ちょっと手助けしてダメそうなら、あっさり見限る冷たい人間になってしまった。
どんな人もプログラミングが上達する魔王の指導法があったら知りたい。
新しいサービスと古いサービス。新しい技術と古い技術 [プログラミング]
はてなのサービス使ってない（アカウントすら持ってない）ので実感はしてないが、始まった当初のはてなBlog の評判は悪かった。
でも、はてなダイアリーという似ていて成功しているサービスがあるのに、あえて同じようなサービスを開始しなくてはならなかった気持ちはよくわかる。
はてなダイアリーが今風でない（ブログっぽくない）デザインやUI を変えたいってのもあるけど、もうとっくに辞めてしまった人達の書いた古いサービスをメンテナンスするのって大変だし、たずさわっているエンジニアのモチベーションにも大きく影響する。
ユーザーが離れていくのは困るけど、かといってエンジニアあっての会社だし。僕は、多少ユーザーの乖離を招いても作り直すという選択を割と評価している。
本当は、サービスを維持しながらデータ移行とかできるといいんだけど、きっと、現行システムを知る人が、まったくいなくなってる、とかなんだろうなぁ
僕は、先人の責務として、目新しくてかっこいいものには飛びつかず、できるだけ無難な構成で、仕事をこなすことを目指してるし、それがプロの仕事だと思っている。新しいものに飛びついで、「僕は○○を導入しました」と声高に叫んで作りかけのまま転職していく。そういうことはないようにしたい。
・・・僕なりのプロ意識なんだけど、そういうの「新しいものにチャレンジしない」と受け取られることが多くて釈然としない。
でも、はてなダイアリーという似ていて成功しているサービスがあるのに、あえて同じようなサービスを開始しなくてはならなかった気持ちはよくわかる。
はてなダイアリーが今風でない（ブログっぽくない）デザインやUI を変えたいってのもあるけど、もうとっくに辞めてしまった人達の書いた古いサービスをメンテナンスするのって大変だし、たずさわっているエンジニアのモチベーションにも大きく影響する。
ユーザーが離れていくのは困るけど、かといってエンジニアあっての会社だし。僕は、多少ユーザーの乖離を招いても作り直すという選択を割と評価している。
本当は、サービスを維持しながらデータ移行とかできるといいんだけど、きっと、現行システムを知る人が、まったくいなくなってる、とかなんだろうなぁ
僕は、先人の責務として、目新しくてかっこいいものには飛びつかず、できるだけ無難な構成で、仕事をこなすことを目指してるし、それがプロの仕事だと思っている。新しいものに飛びついで、「僕は○○を導入しました」と声高に叫んで作りかけのまま転職していく。そういうことはないようにしたい。
・・・僕なりのプロ意識なんだけど、そういうの「新しいものにチャレンジしない」と受け取られることが多くて釈然としない。
伝家の宝刀「データ修正依頼」 [プログラミング]
昔、常駐先のとある（僕の担当とか関係のない）システムは、お金をあつかう大切なシステムで Oracle + Java + COBOL みたいな感じらしかった。そんでもって、それ専用の運用の人達が複数人いて「きっちり」運用していた。
僕は、いわゆる情報系で、扱うデータはお金が絡まず割と気楽にやってた。
そのシステムというのは開発と運用が平行して進んでいるんだけれども、いかんせん、要望にくらべて実装される速度が全然おいついてなかった。（まぁ、僕はうわさレベルでしか知らないんだけど）で、凄いのは、そこの運用の人達に
「データ修正依頼」
という紙をハンコ押して出すと、どんなデータも変更してくれた。簡単にいうと、 Oracle で SQL を直接実行して修正してるぽかった。（決まった形式のデータ修正には決まった SQL文があったんだろうけど、ひょっとしたら簡単なツールもあったのかもしれない）
本来は、データ入力をミスったときの緊急対応的に「入力間違えちゃった、ごめんね。直して」というような意味合いのもののはずだった。
しかし、貸し出しのスキームは存在するけど、それをシステムに入力する方法がない、という恐ろしい状況になっていて、でも、わざと誤った入力をして、それに対する「データ修正依頼」を出すという運用が、正式な手順として成立していた。
まさに、運用でカバーの極み。僕は、あれ以上凄い運用でカバーを見た事ない。
んで、そんとき思ったのは、お金の出し入れの件数は、そんなに多くなかったので
「 システムなんか作らなくて、全部『データ修正依頼』」
でいいんじゃねぇの、ってこと。
実際のところ、年に数件あるかどうかの貸し出しスキーマ（ひょっとしたらもうないかもしれない）に開発工数とお金がかかっていたので、全部とはいわないまでも・・・
最近、SQL文でデータ修正してるので、ふとそんなことを思い出した
僕は、いわゆる情報系で、扱うデータはお金が絡まず割と気楽にやってた。
そのシステムというのは開発と運用が平行して進んでいるんだけれども、いかんせん、要望にくらべて実装される速度が全然おいついてなかった。（まぁ、僕はうわさレベルでしか知らないんだけど）で、凄いのは、そこの運用の人達に
「データ修正依頼」
という紙をハンコ押して出すと、どんなデータも変更してくれた。簡単にいうと、 Oracle で SQL を直接実行して修正してるぽかった。（決まった形式のデータ修正には決まった SQL文があったんだろうけど、ひょっとしたら簡単なツールもあったのかもしれない）
本来は、データ入力をミスったときの緊急対応的に「入力間違えちゃった、ごめんね。直して」というような意味合いのもののはずだった。
しかし、貸し出しのスキームは存在するけど、それをシステムに入力する方法がない、という恐ろしい状況になっていて、でも、わざと誤った入力をして、それに対する「データ修正依頼」を出すという運用が、正式な手順として成立していた。
まさに、運用でカバーの極み。僕は、あれ以上凄い運用でカバーを見た事ない。
んで、そんとき思ったのは、お金の出し入れの件数は、そんなに多くなかったので
「 システムなんか作らなくて、全部『データ修正依頼』」
でいいんじゃねぇの、ってこと。
実際のところ、年に数件あるかどうかの貸し出しスキーマ（ひょっとしたらもうないかもしれない）に開発工数とお金がかかっていたので、全部とはいわないまでも・・・
最近、SQL文でデータ修正してるので、ふとそんなことを思い出した
