ウイルス・スパイウェア検査・駆除 用ツール Dr.WEB CureIt! を無償配布中！
なんと島根県でもセキュリティキャンプが開催される。1月27日。
本家キャンプとは違い、参加対象も限定されていないので セキュリティに関心のある人やWebサービスを公開している人は なるべく*1みんな参加した方がよい。
今回も初日午前中の講師。RubyとRailsの概要について。 会場がどの駅からも遠い。都会の人は歩くなあ。 私みたいな田舎者はドアツードアで車を使っちゃうから足が鈍ってて。
今回は出席者が多くて(25名)ちょっと緊張した。 Railsもろくに使えない私でいいのか、という気もしないでもないが、 言語設計者自身から講義を受ける機会はなかなかないということで、 土産話にはなるようだ。 優れた言語設計者が優れた講義を行うとは限らないのだが。
まあ、納得してもらえるならいいか。
東京支社に移動。Rubyとコミュニティ支援などについて社外の人と打ち合わせ。 もしかしたら、本格的な支援が受けられるかもしれない。 ただ、我々「コミュニティ」側が組織体制が脆弱なので 経済的支援を受けても活用できないかもしれない点を改善する必要がある、かも。
その他にもいろいろと面白そうな話が出た。 今後はスケーラビリティ(いつも強調している生産性のではなく、性能の)も 重要になるかもしれないなあ。今のうちにいろいろ調査・研究しておく必要があるかも。 その辺は私(たち)では絶対的に経験値が足りないので、 いろんな人に聞いたり、教えてもらったりする必要があるだろう。
再びトレーニング会場へ。 立食形式で懇親会。
毎回トレーニング初日の夜に懇親会をするのだが、 きまってその後に質問が活発になったりして、 トレーニングが円滑になる。信頼関係は大事だ。
今回は会議室ひとつ借りて立食形式にしたのだが、 非常によかった。今までの居酒屋などでの懇親会も 食べ物はすごく良いのだけれど、席が固定されてしまうと 移動が面倒で話が進まない。立食形式だと いろいろな人と話はできるし、面白い話もたくさん飛び出すし、 今まで懇親会の中でも最良と言ってもよかったと思う。
担当の人に「次回からも立食にしましょう」とお願いしたのだが、 「会場の手配が難しくて、なかなか」とのことであった。 都内で立食形式で安くしあげられるところを調べる必要があるかな。
「なぜJavaを学ぶ価値があるのか」という話。
プログラマ、システムエンジニアを職業とするならJavaは学んでおいて損はないでしょう。
「需要があり供給が不足しているから」
というのは理解できる。まったくもって正当な話だ。
しかし、その結果、
自分もそうしてジャバラーになったのです。
最初の現場には、経験２年以上のジャバラーはいませんでした。 それはそれは悲惨な開発になりました。
今考えるとバグだらけ、つくりもいい加減、 訳の分からないところでリフレクション。 もちろんまともにソースレビューできる人はいません。 それでも企業の基幹システムになってしまいました。
ということであれば、不幸なことだ。なにかが間違っていると思う。 おそらく間違っているのは個別のプログラマではなく、 もっと上の方で。
そのような不幸をこの世からなくせるか。 もし可能ならば、どうやって？
最上さんのところから。
最後のページより引用
今注目しているのはマルチコアへの対応です。これからプロセッサがコモディティになってきます。それほど遠くない将来に，机の上のパソコンでも64コアや 128コアのプロセッサが珍しくなくなる。そうすると，プロセッサコアへのタスクの割り当てはスレッドなんかでは不可能になる。自動化するしかなくなります。プログラミング言語で並列性をどこまで活用できるか。CやRubyのような手続き型言語ではなく，関数型言語が生きてくるかもしれません。単にmapとreduceを加えれば良いのでは？と思ってしまった。
うーん、そうなのかなあ。Rubyのような言語においてmap/reduceが持つ可能性を あまり深く考察していないので、はっきりしたことは言えないんだけど。 それでできるっていうんなら、上記の発言は単なる私の不見識ですね。
もうちょっとmap/reduceについて勉強する必要があるかな。
もうひとつ、
マクロが無い言語ではプログラムしたくないと考える私のような人間からすると、Rubyにマクロを入れることを拒絶し続けることは前から不思議だった。マクロは言語作者の意図を超えてプログラミングのスタイルを変更してしまう可能性がある。これも同じくスタイルを破壊される事への忌避感が原因なのかも知れない。
こっちは当たりかも。マクロというのは要するに言語ジェネレータなわけで、 これを入れてしまうと言語はメタ言語になってしまい、 「その言語で書かれた」というプログラムを読解するヒントが少なくなってしまう。 それを嫌っているのは確かにある。
メタ言語が必要だったり便利だったりするケースは確かにあるけど、 日常的に使うものまでメタ言語だと、私の脳に優しくないので、 日常言語としてデザインされたRubyにはマクロは不要である、ということではないかと。
まあ、発言の背後の意図を憶測されることはまつもとさんにとっては迷惑かも知れないけど。だけど私も言語を作っている身としては、私のmap/reduce当然、マクロ当然という考え方のどこかに欠陥があるのかも知れないと、考えて理由が知りたいのだ。
理由は上の通り。繰り返すとmap/reduceについては不見識。 マクロについては日常的にメタ言語を扱うのは私が疲れるから。
背後の意図の憶測が迷惑なってことはない。どんどん憶測していただきたい。 違ってればそういうし。
*1 ところで、私の周辺は「なるべく」の代わりに「なるたけ」とよく言うんだけど、これって方言じゃないよね、きっと
方言かどうかはわかりませんが、福岡のわたしの周りで一番多いのは「なるべく」です。
次に「なるだけ」、その次に「なるたけ」です。
どれを使っても難なく通じます。
「なるたけ」、広辞苑には載ってました。
>おそらく間違っているのは個別のプログラマではなく、もっと上の方で。
>そのような不幸をこの世からなくせるか。もし可能ならば、どうやって？
やっぱりプロジェクトマネジメントじゃないですかね.
開発言語の経験が長くてもバグはいっぱい入り込むし.
リスク管理や品質管理がきちんと実施されるかどうかが重要だと思います.
おっしゃることはとても納得できるのですが、それは同時に
* 企業の基幹システムが
* ろくなプロジェクトマネジメントなしに
開発されていることを意味しますよね。
そんな恐ろしいことが日常的に発生しているということなんですね。
それはそれは不幸なことですね。
>そんな恐ろしいことが日常的に発生しているということなんですね
割と日常なんじゃないでしょうか？
金融関係で何年も開発してきた会社の人たちに開発をお願いしたんですが、できあがったのものはボロボロのゴリゴリ。
必死に直してるところなんですが、今までどういうもの作って提供してきてたんだ？と思うばかりです。
>開発言語の経験が長くてもバグはいっぱい入り込むし.
全てのプログラマーが、こうだと思われていない事を、お祈りいたします。
>リスク管理や品質管理がきちんと実施されるかどうかが重要だと思います.
わたしは、この事以上に重要な事があるような気がしています。
map/reduceとparallelismってそんなに安直な関係なんですかねぇ。
大学時代にparallelismをカジった私には素直には受け入れられません。
> そんな恐ろしいことが日常的に発生しているということなんですね。
断言しますが日常的に発生しています(^^;;;
原因の根幹は丸投げと人月制でしょうね.
無能で期間がかかるほうが儲かるという状態でスキルの向上があるわけがない.
>わたしは、この事以上に重要な事があるような気がしています。
同意です。業界全体をどうレベルアップさせていくか、
非常に難しい問題だと日々感じております。
＞ マクロが無い言語では・・・
「マクロ」を広くとらえれば、on Rails のような仕組みも マクロと言える。
（Rubyにもマクロはある）
ソースの上で手軽に使えるマクロを、綺麗な作法で使いこなすことは出来なかったので、on Rails みたいな方向に行ったのでは。
マクロで充分なら Ｃや Ｃ＋＋ はもっと平和のはずだ。
複雑なマクロ／テンプレートはデバッグしにくいです
ここでマクロといってるのはLispマクロを念頭に置いてるんで、あんまり広くとらえすぎちゃうと論点がボケちゃいます。
「Rubyにもマクロはある」とか「マクロで充分ならCやC++のマクロはもっと平和」とかは、かなりムリのある主張に聞こえます。
田辺さん。ご同意いただき、真に有難うございます。