おさいふ携帯電話なるものに機種変更をしてみました。ちょっと固定費が増えたと思いますが、ビジネスチャンスをとらえるためには、多少の投資も必要ではないかという判断をしたのです。
携帯電話用ソフトウェアの購入し直しとか、設定し直しとか大変そうです。せっかく使い方に慣れてきたのですが、また一から学習しなおしです。これまではジョグダイヤルだったのですが、新しい機種にはありません。ちょっと使い慣れるまで時間がかかりそうです。
おさいふ携帯電話なるものに機種変更をしてみました。ちょっと固定費が増えたと思いますが、ビジネスチャンスをとらえるためには、多少の投資も必要ではないかという判断をしたのです。
携帯電話用ソフトウェアの購入し直しとか、設定し直しとか大変そうです。せっかく使い方に慣れてきたのですが、また一から学習しなおしです。これまではジョグダイヤルだったのですが、新しい機種にはありません。ちょっと使い慣れるまで時間がかかりそうです。

まちに待っていたダイヤブロックのマスターカードが到着しました。なんとなくかなり待たされたような気がするのですが、これでようやくDiablock master clubへの作品投稿ができるようになりました。まぁ、権利を得たからどうだ、というわけでもありませんが…
さて、こういったWebサイトへ作品応募するために、ある商品を購入する必要があるというのはアイデアとしては悪くないのですが、もう少し応募方法を簡素化してシステム的に対応できるようになるといいのになぁ、と思いました。値段の高いマスターセットを購入して、手紙による登録が必要だというのは、少々時代遅れの感じがあることを否めません。もっとうまくやれば、ダイヤブロックをもっとみんなが欲しいと思うような展開の仕方があるような気がして、仕方がありません。
オープンソース的な考えに立つと、色々な作品の作り方というのを広く公募して、それを発表する場所を提供する、その作り方をデータベース化して簡単に検索できるようにしておく、といったことをサービスとして提供して、それを見るのが楽しい、それを参考にして自分の作品を作ってみたい、と思わせてファンを増やしていくということを考えるべきだと思います。ダイヤブロックは300円くらいから入手できるものもありますし、その少ない部品を使っていろいろなバリエーションのある作品を作らせて、応募させるのもひとつの方法でしょうし、作り方まで写真にとらせて応募させるのもひとつの方法でしょう。応募された中で、かっこいい作品については製品化を検討することもできます。結構、色々な展開を考えることができるのではないでしょうか。.Sのアイデアなどは、ダイアブロックで昔から実現できていたものをやられてしまった、という感じもあります。ブロックは単純な素材であるが故に、無限の可能性を持っているといっても言い過ぎではありません。
ちなみに、LEGOは日本語公式サイトは見当たりませんでした。英語公式サイトはLEGO.com: The Official Web Site of LEGOというのがありました。マリオとか著作権的にはちょっと気になる作品もあったりします。
ここまで書いてみて、よく考えたら、自分で作った作品を自分のサイトで公開していけばいいだけのような気もしてきました。CLUB LEGOというようなページも世の中にはあるようですし。ダイヤブロック版のページはGoogleでちょっと探してみましたが、見当たりませんでした。自分としては、これだけ柔軟に色々利用できて、創造心を刺激するおもちゃというのは、なかなかないので、ちょっと意外でした。もっとファンがいてもおかしくないのですが、以外とマイナーなのかもしれません。おもちゃやには必ずLEGOとダイヤブロックのコーナーがあるのですが、不思議ですね。
.Sに「ゼビウス」と「ゼルダの伝説」が追加されたらしいです。スーパーマリオは持っているのですが、いい飾りになっています。見かけたら買ってしまうかも。
nekopさんに教えてもらったキーワード “class garbage collection” で説明を発見しました。(多謝>nekop)
Java Forums – Static class garbage collection にそのまま書いてあります。某書籍に書いてあった例は片手落ちで、普通のシステムクラスローダを使ってCLASSPATHからロードされたstaticフィールドを持つクラスについては、Javaアプリケーションが終了するまで勝手にアンロードされることはないとのことです。これは、システムクラスローダがそのクラスへの参照を保持し続けるからです。
独自のクラスローダを使うアプリケーションでは、気にする必要があります。TomcatなどのServlet/JSPコンテナではWebアプリケーションのロードをリロードを独自に行う必要があるので独自のクラスローダを使っています。
実際のものは調べていませんが、もしTomcatが用意しているクラスローダが動的なクラスローダで、必要なときしかTomcatがこのインスタンスを生成しないとすると、クラスローダがガーベッジコレクトに回収される場面がでてきます。すると、そのクラスローダからロードされて、クラスローダからしか参照されていなかった「staticフィールドを持つクラス」は、参照していたクラスローダがいなくなるため、どのクラスからも参照されなくなってしまいます。このため、回収される可能性があるわけです。つまり、WebアプリケーションでSingletonクラスを使おうとすると、Servlet/JSPコンテナが用意しているクラスローダの実装によっては、問題が発生する可能性があるわけです。この危険性を避けるためには、Webアプリケーションの主となるServletクラスからSingletonクラスのインスタンスをstatic参照するようにしておけば、参照オブジェクトのルートセットから辿れるようになるので、ガーベッジコレクトへ回収されることはありません。
本当はこの動作確認を簡単に行える方法があるといいのですが、JavaVMのモニタリングが必要そうなので、ちょっと難しそうです。
(簡単な解説を書いてみたけど、間違えていたら指摘してもらえると助かります)
どうやら、必読らしい。とりあえずリンクだけしておく。
ここ数日は、このサイトの構築をしているのですが、仕事でもWebサイトの移行をしています。仕事の方が気合をいれてやっているので、ちょっと懲りすぎてしまいました。単純なカスタマイズだけではすまなかったので、PHPコードも読みながらテーマを自作してみました。おかげさまで、WordPressはかなりカスタマイズできることがわかりました。ちょっと心配なのはバージョンアップのときに対応が少し大変かもしれないな、という点です。テーマファイルはかなり書き換えましたし、wp-includeにあるプログラムも若干修正しています。セキュリティ的な観点からいうと、こういうところはできるだけさわらないようにするか、本家へこういった関数で扱えるようにして欲しいという要望を投げるのが正しい姿だと思います。
こういった苦労をしてみると、新しいWebサイトへ移行するのは面倒ですが、移行作業とともにデータをきれいにしたり、前は気づいていなかったことに気づけたりするので、やはりそれなりの価値はあるようです。また、年齢を重ねるとともに、新技術への興味が薄れてしまいがちなのですが、こういう作業をすると普及している技術についての自分のポジションを確認することができます。
ということで、毎日はやりたくありませんが、半年に一回ぐらいは「まとめ」の意味も含めて、やってみるのが良さそうです。こうやって手に入れた技術を活かす機会に、いつかはめぐり合えると思いますし。
テーマをかえてみたのですが、謎な現象が発生することが判明して、もとに戻しました。入力したタグが消されて別のものに置き換わってしまうのです。PHPファイルをのぞいてみましたが、どこが変わっているのかさっぱりわからなかったので、あきらめました。少しずつ自分で改良していくのが近道になりそうです。