2004-11-17
■ [stock]アホだ。。。
http://messages.yahoo.co.jp/bbs?.mm=FN&action=m&board=1006473&tid=8wmnc0ba9a9&sid=1006473&mid=232
Yahooファイナンスの検索で
「○んこ」って打つとここに飛ぶねw
ちなみにこの○んこ株は、現在、
信用売が増えて株主喚起銘柄(←はじめて見た)になってます
http://www.tse.or.jp/glossary/gloss_k/chuikanki.html
試しにいろいろ試してみたらこんなのもあった。
どらくえ→9684 スクエニ
ぽけもん→7974 任天堂
どうてい→4331298C メリルリンチ・ワールド債券F為替変動低減型 (これは"動低"にかかってるのね。。。)
■ Advanced JBoss Class Loading
http://www.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases
(via http://d.hatena.ne.jp/neverbird/20041117#p3)
めも
■ [tech]Tomcatのクラス置き場
いつまでたってもあやふやなのでメモ。
(CommonとSharedってどっちだっけ?)
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/class-loader-howto.html
Common Tomcatと個々のWebアプリで利用する共通クラス Catalina Tomcat内だけで利用するクラス Shared 個々のWebアプリ(Tomcatでなし)で利用する共通クラス
複数のWebアプリで利用する共通クラスはSharedに置きます(あるいはTomcat起動時のクラスパスに追加)。
もちろん、個々のWebアプリのクラスはWEB-INF/lib or classesに。
Bootstrap
|
System
|
Common
/ |
Catalina Shared
/ |
Webapp1 Webapp2 ...
CatalinaとShared/WebAppXはクラス階層が異なると。
■ [tech]TomcatのWebAppClassLoader差し替え
ContextのLoader要素で指定可能
<Context>
<Loader loaderClass="hoge.MyLoader"/>
</Context>
デフォルトのWebAppClassLoaderを継承したい場合は、Catalinaにおく
(システムクラスやCommonだと作ったクラスからWebAppClassLoaderが見えないし、ShareだとCatalinaから見えない)
で、差し替えて何をするのか知らないけど。。。
■ [stock]マーサ・スチュアート
http://www.kyoto-np.co.jp/news/flash/2004mar/06/CN2004030601000282J1Z10.html
http://allabout.co.jp/children/ikujinow/closeup/CU20040921A/
■ [tech]Tomcatのオートリロードはデフォルトで15秒間隔
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/loader.html
checkInterval
The number of seconds between checks for modified classes and resources, if reloadable has been set to true. The default is 15 seconds.
どうりで長く感じるわけだ。手動リロードの方がいいと思う僕。
■ [tech]Tomcat5.5プチ新機能 コンテキストファイル置き場
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/changelog.html より
New default configuration mechanism for web applications, replacing DefaultContext. This uses a shared context file located in conf/context.xml. (remm)
%TOMCAT_HOME%/conf/context.xml にデフォルト設定がかけるようになってます。
The container will now always process a /META-INF/context.xml resource, unless the webapp has a specified external context file. (remm)
WebアプリのMETA-INF/context.xml にコンテキスト設定が書けるようになっています。
そういえば、Tomcatのサーバ固有設定で、Webアプリに一緒に含めてデプロイって感じでなかったですな。
なお、5.5新機能ではないですが、5.0からコンテキストの記述は、%TOMCAT_HOME%/conf/Catalina/localhost/ 以下(正確にはエンジンのディレクトリうんぬん)のXMLファイルに書きます。
server.xmlに書いても動きますが、removeしにくいのでやめときましょう。
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html
This method allows dynamic reconfiguration of the web application, since the main conf/server.xml file cannot be reloaded without restarting Tomcat. Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place <Context> elements directly in the server.xml file. Instead, put them in the META-INF/context.xml directory of your WAR file or the conf directory as described above.
あれ?server.xmlに書いとくとサーバ再起動しないとリロードできないってことは、
コンテキストファイル書き換えて、Webアプリの再起動で反映されるんですな。
そういえばSysdeoのプロパティー変更(ログの出力先とか)も再起動なし反映されたかも。。。
■ はてなの書式で
カッコ付()のURLはどう書けばよいのだろうか?
カッコがエスケープされる例↓
http://neverbird.sourceforge.jp/cgi-bin/ja/hiki.cgi?(JBoss)JBoss%A4%C8JMX
■ [tech]JMXって
しばらく僕知らないというスタンスでしたが、JDK5やTomcatでもJMX、JMX言い出すと、少しは知っとかないといかんかなーとおもって少し調べる。
http://neverbird.sourceforge.jp/cgi-bin/ja/hiki.cgi
JMX(Java Management Extensions)は、 Javaからネットワーク上のハードやソフトを管理、監視するための仕様です。MBean(Managed Bean)とはJMXで定義されたJavaBeanによく似た軽量コンポーネントです
MBeanはJMX用のコンポーネントなんすな。しかし、JMXって、アプリケーションサーバ作る人やクライアントツール使うような人が利用するような技術で、どうもなじみがない。
JDK5で標準準拠になったのは、JMXのクライアントの実行にJARが別にいらなくなったって利点なのかな。
http://www5.airnet.ne.jp/sakuraba/java/laboratory/J2SE1.5/MonitoringAndManagement/JMX/JMX1.html
■ ブターンタバコ全面禁止実現
http://www.keicho.com/world/bhutan2004-9.html
とタバコを吸いながら思った。
JTの株下がるかな?いや関係ないみたいですね。
http://antitbc.exblog.jp/980383/
■ 地震保険
http://www.mof.go.jp/jouhou/seisaku/jisin.htm
地震のニュースを見ていて、ふと地震保険って保険として成り立つのかなぁとふと思った。
保険会社がさらに保険をかけているのか、あるいは国が助けてくれるのか?
http://www.daimon-mikishi.jp/kokkai/k-kiji/030424.htm
首都圏直下型地震というのもそろそろ来るかな。。。
http://www.bousai.go.jp/jishin/chubou/shutochokka/
■ [tech]麻疹(ハシカ)とでざぱた
http://d.hatena.ne.jp/taichitaichi/20041116#p1
taichiさんがハテナ登場の模様。
思い起こせば、Javaを覚えたてのころは継承を乱用し、GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、と思う今日このごろなコードもかつては作ってしまった気もします。
ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
新しい設計技法、言語、ツールを知ると使いたくなるというのは、技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。あと、伝染性がある上に発病期間までに時間があったりすることも。ちゃんとテストして(使ってみて)、これは行けると踏んでから、まずはリスクの少ない部分から適用していきましょうと(予防接種)。
生産性と品質に対して何の寄与もしないどころか、
足を引っ張るだけのフレームワークにハメられた僕は別な何かが見える様になったと思います。
開眼フレームワークですな。。。
# 村山 『私の場合はGoF本を読んでからJavaに入ったので,継承の乱用の危険性は既に承知済みでした.でも,いまだに実装継承の危険性も知らない人って結構いるんですよね...』