2006-06-01から1ヶ月間の記事一覧

docTestがちょっとおもしろげ。

オブラブのライトニングトークスで、 id:kikainekoさんが喋ってたdocTestが、発想的に面白そうだなぁ…と。 サンプルコードとしての意味合いを強く持つテストコードは、 ああいう書き方も悪くないと思ったり。 でも、これって要は、DbCじゃ……?…。 つまり、簡…

おれもおれも

マージンFXのひまわり証券さん、ニンテンドーDS Lite欲しい!

WebアプリケーションにおけるHttpSessionのアレとかソレ。

僕が、HttpSessionをやたらと使うテクノロジに懐疑的な理由をちょっとだけ。 実装上の話と設計上の話に分けて考えてみたり。 まずは、「JavaにおけるHttpSession」が、アレでナニな理由。 HttpSessionが、どの様に保持されるかは、APサーバの実装依存。 つま…

GoogleMapsを使ったサービス。

ゴリゴリとJavaScriptを書かずとも、サックリ出来て便利な感じ。 これなら、プログラマじゃなくても使えると思われ。 Michael TiemannとOSS勉強会 会場 オブジェクト倶楽部 2006 夏イベント 会場

ダブルブッキング

仕方ないさー。

プログレスバー。

まじめにやると、扱いが超難しいっぽい。eclipseのプラグイン書いてて思った。 はっきり言って、メインの処理とは全く関係ない*1 が。 UI的には、より現実的に動作すると、イイ感じ。 でも、微細に動いていても、見る側にとっての情報量は、 ある所から、余…

IPath から、IFileを生成する方法。

org.eclipse.core.resources.IContainer#getFile(IPath path);を使う。 org.eclipse.core.resources.IProject#getFile(String path); みたいなメソッドもある。 この辺をブン回すと、OS依存なパス記述から、開放される感じ。

結局JDTから逃げられない。

と言う訳で、逃げるの止めるます。 コードの自動生成周りばっかり触ってると、オカシクなりそうなので、別な所にイッテみます。 まずは、リソース周りのイベントに触ってみるます。 まず、超重要なクラス。 org.eclipse.jdt.core.JavaCore 今まで、こやつに…

気になっているけど、手が出せずにいるテクノロジがあるます。

それが、コレ。 UIE SDK 2.0 正式リリース 手が出せずにいる理由は、ケータイに近付きたくないからであります。 まぁ、だから僕の中でプライオリティが上がらないのですが…。 もう一つは、OSSじゃないから。 只、ケータイ電話向けのアプリケーション開発は、…

5.0

すんません。とりあえず無理であります。 細かい所で、余りに色々違い過ぎるので、心的負担が大きいです。 よって、ハイパーなプラグインの一つも、見つつ、こりゃすげぇ! ってな感じにならないと、NetBeans5.0には移行できねっす。次は、5.5だ。

ありゃま…。

NetBeansは、安定版が、5.0で、ベータ版が5.5じゃねぇですか…。 きしださんの話は、6.0がどーのっていってたような…。 まぁ、いいや。両方使って見るデスヨ。

そもそも、何故eclipseなのか。

答え。…何となく……。 それでは、マズいな…と。頭が硬化し始める兆候かもしれないと思ったり。 で、eclipseを手放せない理由をアレコレ頭の中でこねくりまわしてみたり。

コード自動生成

苦し紛れに、Google先生に聞いてみたら、こんなんでました。 Code Generation Network - Generators for Java

もっとで・た・・・・

自分専用としては、そこそこ使う気になれば、使えると思われ。 何が楽になるのかは激しく謎。 これ以上JDTのAPIに触るのはもう嫌過ぎ。 設計レベルでの、やり直しを開始します。

で・た・・

正直に言って嬉しい。 でも、素直に喜べないモロモロがあったり。

org.eclipse.jdt.ui.CodeGeneration

JDTに設定されたコメントを出力する為のユーティリティがガッサリ詰まってるます。 こいつだけは、使いたいなぁ…と思う今日この頃。

ガッサリインスパイアされた。

出来たコードがダサ過ぎる。 と言うか、これ以上複雑なコードを、今のコーディングスタイルで生成する気になれない。 正直、無理。 ちょっと、動かして見るけど、ITypeを使って、コードの自動生成は、まぁ、パスって事で。

org.eclipse.jdt.internal.corext.codemanipulation.GetterSetterUtil

本当はコイツが使いたかったりする。

org.eclipse.jdt.core.NamingConventions

JDT使って、コードを生成するなら、結構便利。 フィールド名やら、アクセサ名やら、色々インテリジェントに考えてくれる。

流行のアーキテクチャの話。

何となく、漫然とした意識がホァホァとしたけれども、 きっちりまとまらなかったり。 結局の所、アウトプットする事が重要って話に、脳内会議で決まりました。 ヲチが無い上に、まとまりもありません。(防御線) でも、文章だけはやたら長いです。

もっとJavaScriptがHTMLから消えるらしい。

数日前に見た時よりも、内容が濃くなってます。 他のライブラリやら、動作可能ブラウザやら、表まで登場しました。必見。 http://my-chunqiu.cocolog-nifty.com/html/javascript-behaviour.html 書きかけらしいので、毎日チェックするですよ。

org.eclipse.jdt.internal.ui.dialogs.TypeSelectionDialog2

これだ!。ダイレクトにコレが使いたい…。

CompletionProposalCollector

これか…?でも、似てるけど違う様な…。

JavaTypeCompletionProcessor

JDTの中で、超ゴリゴリにコーディングしてあるコヤツを使いたい…。 しかし、internalパッケージに入ってやがる…。

グラフ出ました。

何が、どう出ているのかは、謎ですが、進捗的なアレです。

HTMLからJavaScriptが消えるらしい。

これは、正直凄い。 http://bennolan.com/behaviour/ Ajaxなアプリの問題点は、折角Jspの悪夢から開放されたプログラマを、 新しい悪夢に突き落とす所だと思うですよ。 結局の所、JavaScriptによる制御コードと、表示の為のHTMLタグが混ざった状態になるんだ…

Object#equalsメソッド

軽い気持ちでオーバライドして、酷い目にあったですよ。 結局の所、TreeViewerに格納されるオブジェクトで、 equalsやhashCodeをオーバライドしたら、 IElementComparerの実装を作る事を念頭に置いた方がいいですよ。って事です。 まぁ、コンテキスト依存なe…

TableViewerを編集可能にするAPIってイマイチ。

イマイチな理由は、ITableLabelProviderとCellEditorとICellModifierの対応関係が超微妙。 一方で、indexベースに処理するのに、一方でStringのpropertyとかいう、 論理名ベースで処理するってどういう事? あ〜、何?表示は、別々だけど、 更新処理は同じ……

ぉゃ…

ツリービューの動作がオカシイ。 イベントから取れるインスタンスの設定が、何かオカシイ…。 いかん…。

何かがまちがっとる!

Treeで、カラムを表示して好きな所を編集したいだけなのに!なのに!こいつの好きな所編集したいだけなのに…。 酷い話もあったもんだ…。ゴリゴリですよ…。あ〜あ…。