最近、CodeZine：Reflectionを利用して再帰的にオブジェクトの内容を文字列化する の記事がよく紹介されているのを見て、それならば、と、昔作ったコードを晒します。
XMLSerializer.java
Encoder.java
オブジェクトへの復元ができるのがキモです。
どんなものかは過去の記事にて。queue の日記 - Java オブジェクト <-> XML変換
sidebar.jp での applet との通信や、サーバ上でのオブジェクトの保存/復元、及びデバッグログなどで使っています。
本当はこれも含めた各種ライブラリをアップデートして公開したいところですが、公開すると API を弄りにくくなるということでへろっています-_-。
上記はソースだけの公開ということで、切り貼りして使ってもらおうが一向に構いません。
また唐突にプログラミングネタ。
愛・蔵太の気ままな日記:「正義の人」になってはいけないより。
当たり前のことなのだが、「不正」を告発するにはまず「不正」が存在しなければならない。ありもしない「不正」を糾弾することは出来ないからだ。だからこそ「不正」を告発しようとする人たちは「不正」を待望するようになる。これは多分必然的なメカニズムだと僕は思う。僕たちは「不正」に依存せずに「正義」の側に立つことが出来ない。
すばらしい文章です。
元記事はDead Letter Blog:2002-Julyだそうで、みな、すごい軽やかな文章群です。後でじっくり読もうと思います。
このタイトルは煽りですが、個人的には、このタイトルでも真であると思います。偽善を認識して偽善してるほうがよっぽどいい。
私には見難くてしょうがないんですが。
もちろん何でもかんでも文中括弧書きが見やすいと思っているわけではないですけれど、文末やページ下に脚注が載ってても、脚注の記述対象を確認するのが億劫で元の文脈を取り戻せないので読むのが嫌になる人です。
HTML での脚注ならリンクと ALT+←で行って戻ってくることが大幅に楽になっているのでまだいいのですが、私の場合、それでもあまり読む気になりません(*)。脚注だけで2-3行を超えるくらいの分量になる場合は仕方ないですが。
*:HTML は紙媒体と違って１ページの分量がばらばらなので、脚注が５つも６つも、ということが往々に起こりますが、読むのがとても苦痛です。…と思ったら、いまどきの HTML での脚注は title 属性に脚注本文を入れたりしていて、マウスオーバーで読めるようになっているみたい。これは知らなかった。便利^^;。気づかれないと悲しいですねぇ。
脚注を文章の左右に配置するのはかなり嬉しい手法です。とにかく、今読んでいる本文の位置と脚注の関係を見失ったり、確認するのに視点を動かさなければならないようなものが嫌いなんです。
でも論文をはじめとして、本文中にこういった補足事項が含まれることを嫌う人のほうが多いようです。
なんででしょう…？(純粋に質問)
用語の一般的な説明などは、それを既に知っている人にとっては不要な情報なので脚注を使うのが適していると思います。
紙媒体であれば、URL なんかもそこをわざわざ読みはしないので脚注でしょう。
そうではないもの、特に著者の主張が含まれる補足的事項はできるだけ脚注にはして欲しくないのです。皆さんはどうでしょう？
私はこの記事でもしているように、()書きがさすがに辛いと思ったときは、なるべく近い段落の直後に記すようにしています。このような書き方がどれくらい見難いと思われているのかにも同様に興味があります。ちなみに、雑誌記事などに寄稿したときはこの記事のような書き方をしていてもしっかりページ下部の脚注に移動されますが^^;。
檜山さんへの言及というわけではありませんが_o_。 ってなわけですが。私は今は引用したりおいらクリップでピックアップする記事に古いも新しいもありません。おかげで、言及されることは少なくなりましたけど^^;。 この問題についての意見を久々に見てふと思ったのは、「みんなものすごい勢いで話題を消費していっているわけだけど、ほんとに消費されちゃってることが多い」ってこと。 インターネット上ではよく、「そんなのはウン年前から言われている」とか「そんな古い話題を」といった意見を見かけたりするわけで、まぁ実際そこで議論し尽くされていたりすることもあるのですが、その経緯と結論と原因をきちんと理解している人は、これらの言葉を発する人の何割くらいでしょう？ その話題が過去にあったことだけが頭に残っていて、それだけで「私はもうその話題は知っている」と言わんばかりに「いまさら」と言ってしまったりすることはないでしょうか？ 消化吸収するのは大変です。そのわずかながらの助けになるのは日記だったりするんですが、自分の言葉を少しでも多く書いておかないと、それを見てどう理解したかは結局忘れられていくんですよねぇ。 せめて「知っているだけ」のことと「(自分なりにであっても)理解した」ことを自分の中で区別していくようにしたいものです。 (追記) 2004/06/11現状のblog界隈のやり取りや言説の流れるさまを見ると、2、3日程度の期間で発生するスパイク・ブームの連続・重畳が主たる様式であり、同一のテーマが継続的／持続的に議論され、時間をかけて合意（あるいは決裂や破綻）に至るようなプロセスはあまりないようです。
人々は目新しさを求めているのでしょう。一瞬の盛り上がりを楽しみ、次の瞬間には別の波を探しているのでしょう。
昔ここにぽろっと書いたことですが、その空気は悲しいかな、当時の自分にすらあったわけです。
ま、それでもでも、書くけどさ。
タイトル変更。及び関連リンク。
検索つまみ食い文化による偏向思想の植え付け
自分がつい相手にレッテルを貼ってしまう、という問題以外に、「自分*たち*がレッテルが貼られていることにする」ことによって、味方をふやそうという意識もあるのだなぁ、と思った。
「自分」が言われているのに自分に対して言われたのではないことにしてしまおうという意識か…。
すぐに団体や特定の思想全般を批判されたかのように振舞う人、気をつけましょう。
なんていっても当人たちには無駄ですけど、そういう人もいるということをそうでない人が理解しましょう、ってことですね。当然、そうでないと思っている人がそうならないように注意することを含めて。
ウォーターフォールの利点、というか、私がよいと思うところは、実は大多数である(理解力/向上心/責任感的に)信頼できない開発者が混ざっても何とかさせようとした方法論であることです。
欠点は、実際には手戻りが当たり前なのに、手戻りのための手続きコストを下げる策がなく、(そのため終盤になると仕様変更に異常に拒否的になってしまい)最終的には顧客の要求を全て満たすことができないため顧客を満足させにくいことです。
いわゆるアジャイル(この言葉、何を意味してるかよく解らないので好きではありません)だと、Win-Win になれる可能性が高いのですが、全員に「考える」というスキルを要求するのでまさしく大規模な開発現場ではまず成功しないと思っています。
当然自分のプロジェクトでは「考える」ことができると確信している人しか加えないですけど^^;。
(追記)
「考えさせるな」について補足すると、ウォーターフォール(に限らず比較的多くのソフトウェア工学的)は、プロジェクトメンバーの最低レベルに合わせて作られるのが普通で、なんというか、そのいわゆる最低レベルに当たる人が中途半端に「考える」と、ひずみが出てしまう、という点と、できる/意欲ある人が「考える」と、多数の「うまく考えられない人」がついていけなくなったり、それを真似した結果悪い影響が出てしまったりすることを懸念した結果、意欲ある人まで「考えるな」と言ってしまうようなことが起こるのだろうと思っています。
どちらの方法論も、プロジェクトのメンバーの立ち位置をどちらか一方に集約することが前提になっているため、「通常の」ばらばらの能力の人たちが集まったプロジェクトにおいては、どちらの方法にしてもおかしなところが出てきてしまいます。
ということは、メンバごとにスタンスを選べればよいのではないか？と短絡的に考えられるわけですが、「考える」ことにあまり意欲がなかったり、向いてないと考えられる人が、自ら受動的スタンスを選んだとしても、本当にそれがしたいわけではないので、結局あんまり良い成果には結びつかなかったりします。
私だったら、やっぱりその人が一番好きなことの中でそのプロジェクトに役に立ちそうなことを探すのに一番集中するかな。まぁ既に方法論の話から逸脱してますが^^;。ただ、これを踏まえて言えば、「メンバーの気質に合わせて方法論を切り替える」ようにする、というのが自分なりの答えです。大規模プロジェクトに対する答えにはなっていませんが、大規模であっても、基本的な考え方は変わらないです。
