コモディティは動く標的で、世界はめまぐるしく変わってる [プログラミング]
18コア36スレッドのCPU が動かせる 2ソケットマザーボードがアキバで売られてるそうな
http://akiba-pc.watch.impress.co.jp/docs/news/news/20140913_666711.html
２つで 36コア 72スレッドということになる
SATAの規格を超える Read/Write 速度の SSD もかなり安価で買えるようになってきたみたい
http://akiba-pc.watch.impress.co.jp/docs/news/news/20140920_667794.html
FreeBSD で PostgreSQL を使った時のマルチコア性能が上がったそうな
http://news.mynavi.jp/news/2014/07/17/259/
DDR4 メモリはまだまだ高そうだけど、あと１年くらいしたら 128G くらいのメモリを
上記のマザーボードに積むっていうのも「コモディティ」になってくるんじゃないかと思う。
やっぱアキバってすごいな。
今まではサーバーをいっぱい並べて Hadoop で処理するのがはやりだったけど、
（そういう方法じゃなきゃできないこともある一方で）
サーバーの性能が向上することで、いままで OSS の RDBMS でできなかったことができるようになるんじゃなかろうか。
基幹システムのバッチを Hadoop で短縮、とか「すげー」と思ったけど、
あれはあれで壊れるところ多くて、ノードのメンテナンスとか大変そう。
これからまた先祖帰りして、 OSS の RDBMS で処理するシステムが増えるのかも。
今まで24時間で終らなかった日時バッチが30分くらいで終るようになったりしたら・・・
そして、それがアキバで売られてるパーツをくみあげたようなマシンで動かせる。
Oracle とか、Hadoop とか、自分には縁がないと思っていたような豪勢なもので構築されていた大規模システムに、自分も関われるかもしれない、と思うと、いくつになってもドキドキするわ。
http://akiba-pc.watch.impress.co.jp/docs/news/news/20140913_666711.html
２つで 36コア 72スレッドということになる
SATAの規格を超える Read/Write 速度の SSD もかなり安価で買えるようになってきたみたい
http://akiba-pc.watch.impress.co.jp/docs/news/news/20140920_667794.html
FreeBSD で PostgreSQL を使った時のマルチコア性能が上がったそうな
http://news.mynavi.jp/news/2014/07/17/259/
DDR4 メモリはまだまだ高そうだけど、あと１年くらいしたら 128G くらいのメモリを
上記のマザーボードに積むっていうのも「コモディティ」になってくるんじゃないかと思う。
やっぱアキバってすごいな。
今まではサーバーをいっぱい並べて Hadoop で処理するのがはやりだったけど、
（そういう方法じゃなきゃできないこともある一方で）
サーバーの性能が向上することで、いままで OSS の RDBMS でできなかったことができるようになるんじゃなかろうか。
基幹システムのバッチを Hadoop で短縮、とか「すげー」と思ったけど、
あれはあれで壊れるところ多くて、ノードのメンテナンスとか大変そう。
これからまた先祖帰りして、 OSS の RDBMS で処理するシステムが増えるのかも。
今まで24時間で終らなかった日時バッチが30分くらいで終るようになったりしたら・・・
そして、それがアキバで売られてるパーツをくみあげたようなマシンで動かせる。
Oracle とか、Hadoop とか、自分には縁がないと思っていたような豪勢なもので構築されていた大規模システムに、自分も関われるかもしれない、と思うと、いくつになってもドキドキするわ。
遅れるのは毎日少しずつ [プログラミング]
ソフトウェア開発だけじゃなくて、家を建てるでもビルを建てるでもそうだと思うけど、遅れはある日突然やってくるものじゃない。
全体の 1/10 の工期が過ぎたら 1/10、半分過ぎたら 1/2 はできてないといけないはずだ。
おそらく、いろいろな仕事の進め方があって、
「全体の半分の工程が進んで詳細設計書はできてるけどコードは、まだ書き始めてません」
というやり方は、それはそれでありなんだと思う。
でも、今の自分のやり方だと 1/10 なら 1/10、 1/2 過ぎたら半分できてないとおかしい。
今風に言えば、アジャイル？でも、なんか昔からこっそりこんな感じでやってた気がする。
そして、半分というのは、基本的な機能はできていて評価できる程度には完成していて、ところどころ不具合があるとか、瑣末な機能ができてないとか、見た目が適当とか・・・。それで 1/2 できたかな、というイメージ。
そこから実際に使う人に評価してもらってあーでもない、こーでもないと調整すると、工数的にはちょうどいい感じ。最初に
「え、もう動かせるの？できるの早いですねー（見積もり間違ってたんじゃないの？）」
と言っていた人も、あーだこーだ言って手直しした結果、ちょうどの工数でできる。
僕の感覚では、だいたい動いているはずの時期に
「今は全体の工期の半分なんで、コーディング完成してるわけないじゃないですか」
と、動くものがまったくできてない場合、僕だけが焦るのはよくあること。
全体の 1/10 の工期が過ぎたら 1/10、半分過ぎたら 1/2 はできてないといけないはずだ。
おそらく、いろいろな仕事の進め方があって、
「全体の半分の工程が進んで詳細設計書はできてるけどコードは、まだ書き始めてません」
というやり方は、それはそれでありなんだと思う。
でも、今の自分のやり方だと 1/10 なら 1/10、 1/2 過ぎたら半分できてないとおかしい。
今風に言えば、アジャイル？でも、なんか昔からこっそりこんな感じでやってた気がする。
そして、半分というのは、基本的な機能はできていて評価できる程度には完成していて、ところどころ不具合があるとか、瑣末な機能ができてないとか、見た目が適当とか・・・。それで 1/2 できたかな、というイメージ。
そこから実際に使う人に評価してもらってあーでもない、こーでもないと調整すると、工数的にはちょうどいい感じ。最初に
「え、もう動かせるの？できるの早いですねー（見積もり間違ってたんじゃないの？）」
と言っていた人も、あーだこーだ言って手直しした結果、ちょうどの工数でできる。
僕の感覚では、だいたい動いているはずの時期に
「今は全体の工期の半分なんで、コーディング完成してるわけないじゃないですか」
と、動くものがまったくできてない場合、僕だけが焦るのはよくあること。
OSSフリーライドけしからん？いえいえフリーライドしてくださいお願いします [プログラミング]
時々、 OSS フリーライドけしからんという話を聞くけど、世の多くのソフトウェアが OSS として使えるようになってきた今では、使ってもらえる OSS は勝ち残ったごく一部で、
「フリーライドしてください。お願いします」
という心情の開発者は多いのじゃなかろうか
例えばこれ↓
http://www.firebirdnews.org/?p=9361
「Version 0.9.3 で windows で新しいプロトコルで使えるようになった」
っぽいことが書いてあるけど、
「数ヶ月前の修正で windows で動かなくなってしまっていた」
のが本当のところ。
Issue があがったのですぐ直した。別に修正が難航していたわけでもなんでもない。
https://github.com/nakagami/pyfirebirdsql/issues/50
「えーー、言ってよ！」
という感じ。
こんなこと結構あって、きちんとリリースしたつもりが、追加したファイルをアップロードしてないおかげで全然動いてないまま数ヶ月放置されてたこともあるので、今回のように特定のプラットフォームで動かなくて気づかなかったくらいは大した問題ではない。
目玉の数が十分あればいいんだけど、作ったら誰もが使うような OSS なんて、そんなに簡単に書けるもんじゃない。
こんなもの作ったら多くの人がフリーライドしちゃう。（そして僕にも実装できる）・・・というテーマがあったら教えて欲しいものである。
「フリーライドしてください。お願いします」
という心情の開発者は多いのじゃなかろうか
例えばこれ↓
http://www.firebirdnews.org/?p=9361
「Version 0.9.3 で windows で新しいプロトコルで使えるようになった」
っぽいことが書いてあるけど、
「数ヶ月前の修正で windows で動かなくなってしまっていた」
のが本当のところ。
Issue があがったのですぐ直した。別に修正が難航していたわけでもなんでもない。
https://github.com/nakagami/pyfirebirdsql/issues/50
「えーー、言ってよ！」
という感じ。
こんなこと結構あって、きちんとリリースしたつもりが、追加したファイルをアップロードしてないおかげで全然動いてないまま数ヶ月放置されてたこともあるので、今回のように特定のプラットフォームで動かなくて気づかなかったくらいは大した問題ではない。
目玉の数が十分あればいいんだけど、作ったら誰もが使うような OSS なんて、そんなに簡単に書けるもんじゃない。
こんなもの作ったら多くの人がフリーライドしちゃう。（そして僕にも実装できる）・・・というテーマがあったら教えて欲しいものである。
業務の効率化をしたら課長の仕事が大変なことになった話 [プログラミング]
もうだいぶ時が経ったのでもう少し話してもいいだろうと思う思い出話。
開発の仕事として過去最大級に大変だった現場の話なのだが・・・
http://nakagami.blog.so-net.ne.jp/2010-06-19
http://nakagami.blog.so-net.ne.jp/2012-09-29
今回は、その開発過程の話でなくてできあがったものの話を書いておく。
生命保険に入るためには色々な書類を出す。その紙を査定担当者が見て、生命保険に加入させられるかどうか査定していた。それを、新システムでは紙をスキャンして電子的に決済ワークフローに乗せて
査定を回そうというものだった。
生命保険に入ろうとすると、加入したい人が書いた申請書の他に、健康診断をした医者の診断書とか収入証明書とかあって、それも来る順番がいろいろなのに来たところから査定するとか、システム的な難しさはあるのだけど、それはさておき、どうもその頃同業他社でそういうイメージワークフローの導入がはやったっぽいのである。
業務の効率化をして、査定部署で余った人員を営業にと、そういうもくろみだったようだ。
開発途中に親切にしてくれた査定担当の若い女性達について
「あの人達、このシステムできたらリストラされて営業にまわされちゃうんだよ。」
というようなことを言われた。
さて、苦労はしたものの、１ヶ月平行運用というところまでこぎ着けた。
査定担当者も、今まで紙でバラバラっと見て確認してたのに、パソコンで画像を拡大したり移動したりして大変だろうなぁと思ったのだけれどももっとも大変そうなのは課長だった。
何しろ、査定結果全ての承認印を電子的に押さないといけないのだが、その操作が煩雑なのである。
紙であれば、（書類を見ないで）紙をぱらぱらっとめくって課長印の欄にぽんぽんっと押印すれば良かったのだが、新システムになったらアイコンをクリックして開かないといけないし、査定者のコメントとか画像をスクロールして一番したまで持っていかないとハンコ押せないようになっていた。
（細かい操作は覚えてないが、とにかく承認の操作が非常に煩雑であった）
新システムになったら課長は一日ハンコを押し続けなくてはならなっくって、ハンコを押すためには、ろくに書類を見ている余裕がなくなった。いや、それどころかハンコ押すだけしかしてなくて残業しまくってたみたい
形式的には
「部下からあがってきた査定結果の書類を全部見て承認しないといけない」
となっていた業務をそのままシステム化したら、あんなになった。
本当は、「部下からコメントがあがったものだけ書類見て、他は見ないで承認していた」んだろう。
開発の最後で僕は現場を離れたので、あのシステムで業務がうまく回るようになったかどうか知らない。
しかし、あの課長のハンコだけは、システムと内規を変えないことにはどうしようもないだろうなぁ、と思っている。
「そしてまあ、手動でやってたことを規定にそってシステム化しようとしたら大変になった。そんなような話はよくあるよね」
という話を今日した。
作る方としては「それじゃうまく業務が回らんだろうなぁ」と思うことはあるが、関係者を説得するのは難しいし、作るほうだってやってみないと分からない部分もあるし（運用者のスキル等の要素もあるし） いったん作って運用して直していくしかないと思っている
開発の仕事として過去最大級に大変だった現場の話なのだが・・・
http://nakagami.blog.so-net.ne.jp/2010-06-19
http://nakagami.blog.so-net.ne.jp/2012-09-29
今回は、その開発過程の話でなくてできあがったものの話を書いておく。
生命保険に入るためには色々な書類を出す。その紙を査定担当者が見て、生命保険に加入させられるかどうか査定していた。それを、新システムでは紙をスキャンして電子的に決済ワークフローに乗せて
査定を回そうというものだった。
生命保険に入ろうとすると、加入したい人が書いた申請書の他に、健康診断をした医者の診断書とか収入証明書とかあって、それも来る順番がいろいろなのに来たところから査定するとか、システム的な難しさはあるのだけど、それはさておき、どうもその頃同業他社でそういうイメージワークフローの導入がはやったっぽいのである。
業務の効率化をして、査定部署で余った人員を営業にと、そういうもくろみだったようだ。
開発途中に親切にしてくれた査定担当の若い女性達について
「あの人達、このシステムできたらリストラされて営業にまわされちゃうんだよ。」
というようなことを言われた。
さて、苦労はしたものの、１ヶ月平行運用というところまでこぎ着けた。
査定担当者も、今まで紙でバラバラっと見て確認してたのに、パソコンで画像を拡大したり移動したりして大変だろうなぁと思ったのだけれどももっとも大変そうなのは課長だった。
何しろ、査定結果全ての承認印を電子的に押さないといけないのだが、その操作が煩雑なのである。
紙であれば、（書類を見ないで）紙をぱらぱらっとめくって課長印の欄にぽんぽんっと押印すれば良かったのだが、新システムになったらアイコンをクリックして開かないといけないし、査定者のコメントとか画像をスクロールして一番したまで持っていかないとハンコ押せないようになっていた。
（細かい操作は覚えてないが、とにかく承認の操作が非常に煩雑であった）
新システムになったら課長は一日ハンコを押し続けなくてはならなっくって、ハンコを押すためには、ろくに書類を見ている余裕がなくなった。いや、それどころかハンコ押すだけしかしてなくて残業しまくってたみたい
形式的には
「部下からあがってきた査定結果の書類を全部見て承認しないといけない」
となっていた業務をそのままシステム化したら、あんなになった。
本当は、「部下からコメントがあがったものだけ書類見て、他は見ないで承認していた」んだろう。
開発の最後で僕は現場を離れたので、あのシステムで業務がうまく回るようになったかどうか知らない。
しかし、あの課長のハンコだけは、システムと内規を変えないことにはどうしようもないだろうなぁ、と思っている。
「そしてまあ、手動でやってたことを規定にそってシステム化しようとしたら大変になった。そんなような話はよくあるよね」
という話を今日した。
作る方としては「それじゃうまく業務が回らんだろうなぁ」と思うことはあるが、関係者を説得するのは難しいし、作るほうだってやってみないと分からない部分もあるし（運用者のスキル等の要素もあるし） いったん作って運用して直していくしかないと思っている
コードレビューで「これ難しくない？」しか言ってない [プログラミング]
今の職場で初めて開発のフローの中でやると決めてコードレビューをしている。
・・・とは言っても
「ここは線形に検索すると時間かかるからハッシュでー」
とか
「O オーダーがー」
とか言ったことない。
ほとんどの場合
「これ（ちょっと便利な記法を使ったクールな書き方？）難しくね？」
とか
「関数名の get_XXX って set じゃない？」
「変数名（いかにも辞書で引きましたみたいな）単語 xxxx って、わかんなくね？」
みたいなこと。
レビューって、コードの添削というよりは、コードが誰かの所有物になって他のひとには直せない、ということがないように共有するためじゃなかろうか。だから、ほんとは一人と言わず多くの人がお互いにレビューするといいと思うんだけど時間に限りがあるので、それはなかなか難しいなぁ、というのが実感。
ほんの少しのコードレビューすらできない状況のほうが多いのが現実なので、世の人は自分のところはやってないからダメだ、と単純に思わないほうがよいと思う。決して（コードレビューさえなければ、もっと早くでき上がるのに）と思わないわけではない。
したほうがいいけど、会社の偉い人が工数の削減を期待してるとすると悲しい結果になると思う。
コードレビューしなくても、誰かが書いたところは別の人が直すみたいにコードの担当みたいなのを作らずガンガン修正していけば同じ効果が得られると思う。
レビューしなくても、コードの所有↓がないように気をつければそれでよいのでは。
http://nakagami.blog.so-net.ne.jp/2010-03-22
結局、コードレビューって、やるかやらないかではなく、どの程度やるかって話かと思う。
・・・とは言っても
「ここは線形に検索すると時間かかるからハッシュでー」
とか
「O オーダーがー」
とか言ったことない。
ほとんどの場合
「これ（ちょっと便利な記法を使ったクールな書き方？）難しくね？」
とか
「関数名の get_XXX って set じゃない？」
「変数名（いかにも辞書で引きましたみたいな）単語 xxxx って、わかんなくね？」
みたいなこと。
レビューって、コードの添削というよりは、コードが誰かの所有物になって他のひとには直せない、ということがないように共有するためじゃなかろうか。だから、ほんとは一人と言わず多くの人がお互いにレビューするといいと思うんだけど時間に限りがあるので、それはなかなか難しいなぁ、というのが実感。
ほんの少しのコードレビューすらできない状況のほうが多いのが現実なので、世の人は自分のところはやってないからダメだ、と単純に思わないほうがよいと思う。決して（コードレビューさえなければ、もっと早くでき上がるのに）と思わないわけではない。
したほうがいいけど、会社の偉い人が工数の削減を期待してるとすると悲しい結果になると思う。
コードレビューしなくても、誰かが書いたところは別の人が直すみたいにコードの担当みたいなのを作らずガンガン修正していけば同じ効果が得られると思う。
レビューしなくても、コードの所有↓がないように気をつければそれでよいのでは。
http://nakagami.blog.so-net.ne.jp/2010-03-22
結局、コードレビューって、やるかやらないかではなく、どの程度やるかって話かと思う。
動かして確認します [プログラミング]
過去、いろんな環境で見かけたんだけど、担当の人が作った機能について
「こんなデータを入力したらどうなるの？」
みたいな質問すると
「テストします」
ってすぐ言うひといるんだけど、
「そのまえに、こういう風になるだろう、っていう予想あるでしょ？」
って言っても、
「テストしてみないとわかりません」
って言われちゃう。
いやいやいや、自分で作ったんだからわかるやろー
そもそも、作る前から「こういうデータが入力されたら、こういう結果になる」
ってことを想像しながら作るでしょ。
そのデータは不正なデータなのかどうか、不正なデータは入るのか、入らないのか・・・
そういう人のやるテストって、自分の書いたプログラムから想像力を働かせて網羅的に、というより、とにかく沢山やるって感じで、気がつくとテストばっかりしてる。
そのテスト、なんのためにやってるの？っていうのも納得のいく回答が得られず、なんとなく不安だから、、って感じ。
周囲からは、「しっかりテストをしてる」っていう評価だったりするんだけど、なんか納得いかないんだよねー。
この納得いかない感じは、うまく説明できないけど、何かっていうと「しっかりテストをして品質を保ちます」っていうベンダーになんとなく不安になるのと同じ理由だな。
「こんなデータを入力したらどうなるの？」
みたいな質問すると
「テストします」
ってすぐ言うひといるんだけど、
「そのまえに、こういう風になるだろう、っていう予想あるでしょ？」
って言っても、
「テストしてみないとわかりません」
って言われちゃう。
いやいやいや、自分で作ったんだからわかるやろー
そもそも、作る前から「こういうデータが入力されたら、こういう結果になる」
ってことを想像しながら作るでしょ。
そのデータは不正なデータなのかどうか、不正なデータは入るのか、入らないのか・・・
そういう人のやるテストって、自分の書いたプログラムから想像力を働かせて網羅的に、というより、とにかく沢山やるって感じで、気がつくとテストばっかりしてる。
そのテスト、なんのためにやってるの？っていうのも納得のいく回答が得られず、なんとなく不安だから、、って感じ。
周囲からは、「しっかりテストをしてる」っていう評価だったりするんだけど、なんか納得いかないんだよねー。
この納得いかない感じは、うまく説明できないけど、何かっていうと「しっかりテストをして品質を保ちます」っていうベンダーになんとなく不安になるのと同じ理由だな。
八百屋の値切り交渉のような工数算出に屈しない勇気 [プログラミング]
（愚痴じゃないです）
「実装見てないけど（よくわからないけど）もっと早くできるだろう？」
新卒で働き始めてからそれこそ無限に聞いたセリフ。
ある程度プログラムをわかっている人が、
「そこ、そんなにかからないんじゃん？」
っていう素朴な疑問というか、この見積もり通らないんじゃないかという不安。
「いや、そこ元々の想定と違うんで・・・」
と、いろいろ説明しても、やっぱりよくわかってもらえないことはある。
新人の頃に課長に言われたりすると、
「そんな（に早くできる）もんかな」
と思って従ったが、最近は、こと「工数」について譲ることはほとんどない。
もちろん、見積もりを間違う場合もあるが、実装者に近い人間の長めの見積もりのほうが、経験あるといいつつ詳細にコードを読んでない人間の直感よりも正確に思う。
いろいろな事情があって、もっと早く完成させたいとかもっとコストを下げたいとかいうことはあるだろう。でも、工数は工数として算出する必要がある。リスクを取ったり、利幅を圧縮したりする、ということで認識してもらうべきものであって、ベースとなる工数は安易に減らしちゃダメだと思う。
「残業休出して頑張ればできるけど、工数は減らせません。もしくは、見込みが違ったが赤字になるけど、それでもいいですか？」
みたいな。
何か機能を減らすとか作業を減らすことなく、八百屋の値切りのように利得はそのままに
「もうちょい短くならない？」
って言われたときに頑張る気持ちはわからんでもない。
嫌われたくないとか、無能と思われたくないとか。
あと、自分でやったらもっと早くできるけど、っていうのもあるかも。
でも、一旦見積もってしまった工数は一人歩きして、他の人がやることになったときに全然時間が足りなくなると迷惑かける。
一旦八百屋の値切り応えてしまうともっと安くできるんじゃないか、となってしまうし、自分の中の基準もぶれてしまって、よくわかんなくなってくると思うんだよね。
そんなこんなで工数は意固地なほどに、簡単には減らさないようにしてる。
それは、考えてやってるというより、直感的に、ここで安易に減らしちゃいけない、って感じてるってほうが近いかな。
辛い目にあってるからだろうか？（それほど辛い目にあってないつもりなんだけど）
工数を安易に「値切る」ことに抵抗があるので、リフォームとか車買うとか、本来価格交渉があたりまえの場面で値切ったりでいない。これも職業病かなぁ。
「実装見てないけど（よくわからないけど）もっと早くできるだろう？」
新卒で働き始めてからそれこそ無限に聞いたセリフ。
ある程度プログラムをわかっている人が、
「そこ、そんなにかからないんじゃん？」
っていう素朴な疑問というか、この見積もり通らないんじゃないかという不安。
「いや、そこ元々の想定と違うんで・・・」
と、いろいろ説明しても、やっぱりよくわかってもらえないことはある。
新人の頃に課長に言われたりすると、
「そんな（に早くできる）もんかな」
と思って従ったが、最近は、こと「工数」について譲ることはほとんどない。
もちろん、見積もりを間違う場合もあるが、実装者に近い人間の長めの見積もりのほうが、経験あるといいつつ詳細にコードを読んでない人間の直感よりも正確に思う。
いろいろな事情があって、もっと早く完成させたいとかもっとコストを下げたいとかいうことはあるだろう。でも、工数は工数として算出する必要がある。リスクを取ったり、利幅を圧縮したりする、ということで認識してもらうべきものであって、ベースとなる工数は安易に減らしちゃダメだと思う。
「残業休出して頑張ればできるけど、工数は減らせません。もしくは、見込みが違ったが赤字になるけど、それでもいいですか？」
みたいな。
何か機能を減らすとか作業を減らすことなく、八百屋の値切りのように利得はそのままに
「もうちょい短くならない？」
って言われたときに頑張る気持ちはわからんでもない。
嫌われたくないとか、無能と思われたくないとか。
あと、自分でやったらもっと早くできるけど、っていうのもあるかも。
でも、一旦見積もってしまった工数は一人歩きして、他の人がやることになったときに全然時間が足りなくなると迷惑かける。
一旦八百屋の値切り応えてしまうともっと安くできるんじゃないか、となってしまうし、自分の中の基準もぶれてしまって、よくわかんなくなってくると思うんだよね。
そんなこんなで工数は意固地なほどに、簡単には減らさないようにしてる。
それは、考えてやってるというより、直感的に、ここで安易に減らしちゃいけない、って感じてるってほうが近いかな。
辛い目にあってるからだろうか？（それほど辛い目にあってないつもりなんだけど）
工数を安易に「値切る」ことに抵抗があるので、リフォームとか車買うとか、本来価格交渉があたりまえの場面で値切ったりでいない。これも職業病かなぁ。
どんどん書こう [プログラミング]
思うに、アジャイルとかチケット駆動とか TDD とか、開発手法についてのあれこれや、プログラミング言語や Web Application Framework についての情報が溢れているせいか知らないけど
「なんでもいいからとにかくもっとコード書こうよ」
と思う。
下手くそに書くと、やれ○○に外れてるから、とかそういうこと言われないようにということかもしれないけど、とにもかくにも書かないと始まらないという面が忘れられてるような気がする。
プログラミング言語もフレームワークも、みんなが使っているようなそこそこのものを選択してとにかく書き始めることが大事なんじゃないかと。
「プログラマーになりたい」という未経験の人は PHP で掲示板でいいよ。
僕の実感では、成功しているプロジェクトっていうのは当初の予想よりも長く開発が続いていくもので、３年も同じプロジェクトで機能を拡張していくと当初の予想とは似ても似つかないものができ上がっている。
そして、かならず途中で大きく書き直さないといけなくなっている。
そもそも「それは、当初の設計と違うのでできません」と言っていたらそこで終わっていたんだろうな。
だから、再利用できるパーツとか（大事なのかもしれないけど）いくら慎重に設計しても、うまくいったプロジェクトほど、そういう当初の設計やコードは役に立たなくなっていて、書き直しているように思し、それは不可避だと思う。
僕が新卒で働き始めた最初の３年くらいは、そういう「あたり」プロジェクトで、とにかく日々その場しのぎでコードを書いてたら３年後には、当初には誰も予想してなかったような大規模で、当初は誰も知らなかったような予想外の機能が売りになってた。
事前のマーケティングよりもまずは動く実装を。
ああいう経験を最初にできたのは本当に良かったと思う。
「なんでもいいからとにかくもっとコード書こうよ」
と思う。
下手くそに書くと、やれ○○に外れてるから、とかそういうこと言われないようにということかもしれないけど、とにもかくにも書かないと始まらないという面が忘れられてるような気がする。
プログラミング言語もフレームワークも、みんなが使っているようなそこそこのものを選択してとにかく書き始めることが大事なんじゃないかと。
「プログラマーになりたい」という未経験の人は PHP で掲示板でいいよ。
僕の実感では、成功しているプロジェクトっていうのは当初の予想よりも長く開発が続いていくもので、３年も同じプロジェクトで機能を拡張していくと当初の予想とは似ても似つかないものができ上がっている。
そして、かならず途中で大きく書き直さないといけなくなっている。
そもそも「それは、当初の設計と違うのでできません」と言っていたらそこで終わっていたんだろうな。
だから、再利用できるパーツとか（大事なのかもしれないけど）いくら慎重に設計しても、うまくいったプロジェクトほど、そういう当初の設計やコードは役に立たなくなっていて、書き直しているように思し、それは不可避だと思う。
僕が新卒で働き始めた最初の３年くらいは、そういう「あたり」プロジェクトで、とにかく日々その場しのぎでコードを書いてたら３年後には、当初には誰も予想してなかったような大規模で、当初は誰も知らなかったような予想外の機能が売りになってた。
事前のマーケティングよりもまずは動く実装を。
ああいう経験を最初にできたのは本当に良かったと思う。
flake8 vim のプラグインのこと [プログラミング]
プログラマーという仕事にこだわりはない [プログラミング]
今は、たまたま仕事でコードを書いている。
お客さんやプロジェクトの総意として僕がプログラムを書くのが良いという、現状認識で、僕もそう思っているので異存はない。
ただ「俺は一生現役プログラマー」というこだわりでやっているわけではないので、いまだにプログラムを書いているのが、ちょっと不思議な気がする。
いつかまた、進捗管理をしたり、「えすいーさん」と呼ばれて、よろずパソコン相談みたいな仕事をすることもあるだろう。
「nakagami 君には、マネージメントしてもらうから、プログラム書かないで」
と明確に言われたのは 30歳前後だったが、あの頃の縛りは非常にきつかった。
なんせ、自分がやったほうが説明するだけの時間と比較しても早いのに自分で書いちゃいけないんだから。
若い人、協力会社さんに成長してもらうため、という説明をうけて頑張っていたが結局のところ、自分がコード書くくらいの時間かけて説明してもダメな人はそのすぐ辞めちゃうので、僕や会社の力にはならないまま終わっていたように思う。
あの頃は、みんながそれぞれ苦手な（未熟な）仕事をして地雷踏みまくってた。いまでも、世の中の平均って、あんなもんだと思う。
マネージメントする SEは単価は高くてプログラマーは安い、というのはだれかが決めたことだけど、それは発注する側も受注する側も無理な縛りが入っていて、だれも得しない気がする。
どっちも単価は同じ、ってことにして、その時々でやる仕事はいい具合に割り振ればいいのに
お客さんやプロジェクトの総意として僕がプログラムを書くのが良いという、現状認識で、僕もそう思っているので異存はない。
ただ「俺は一生現役プログラマー」というこだわりでやっているわけではないので、いまだにプログラムを書いているのが、ちょっと不思議な気がする。
いつかまた、進捗管理をしたり、「えすいーさん」と呼ばれて、よろずパソコン相談みたいな仕事をすることもあるだろう。
「nakagami 君には、マネージメントしてもらうから、プログラム書かないで」
と明確に言われたのは 30歳前後だったが、あの頃の縛りは非常にきつかった。
なんせ、自分がやったほうが説明するだけの時間と比較しても早いのに自分で書いちゃいけないんだから。
若い人、協力会社さんに成長してもらうため、という説明をうけて頑張っていたが結局のところ、自分がコード書くくらいの時間かけて説明してもダメな人はそのすぐ辞めちゃうので、僕や会社の力にはならないまま終わっていたように思う。
あの頃は、みんながそれぞれ苦手な（未熟な）仕事をして地雷踏みまくってた。いまでも、世の中の平均って、あんなもんだと思う。
マネージメントする SEは単価は高くてプログラマーは安い、というのはだれかが決めたことだけど、それは発注する側も受注する側も無理な縛りが入っていて、だれも得しない気がする。
どっちも単価は同じ、ってことにして、その時々でやる仕事はいい具合に割り振ればいいのに
