【最速】google guice DI Framework【シンプル】

1 ：07/03/24

無かったので立ててみた。
http://code.google.com/p/google-guice/

2 ：07/03/24

鼬害

3 ：07/03/24

これなんて読むんだ？
juice→ジュースだから
グース？

4 ：07/03/24

pronounced 'juice'
って書いてあるじゃん。
ってかまたDIか。本気でDIいけてると思ってる奴どんだけ
いんのよ？流行で触ってみた、使ってみたじゃなくてさ。
心底、これはスゲーって思ってる奴いる？

5 ：07/03/24

DIなんてJavaが駄目言語であるがゆえに存在するものだからなあ

6 ：07/03/24

ＤＩいけてないって思うヤツに
プログラムを書かせてはいけない

7 ：07/03/24

>>4
普通に１００人規模の開発で使ってるんだが。。

8 ：07/03/24

>>4
DI無しでの単体テストなんてもう考えられないな。
DIは単体テストの為にあるって言ってもいいかも。

9 ：07/03/24

>>6
書き方が悪かったな。
ＤＩいけてると判断して使ってる奴がどれだけいますかー？
ＤＩいけてないと判断して使ってない奴がどれだけいますかー？
って事だけ。流行に躍らされてないで、DI理解して
DIDIって言ってる奴が何割いるのかと。

10 ：07/03/24

>>9
DIはいけてるが既存のフレームワークは最悪。
guiceはちょっとましになったかなという程度か。

11 ：07/03/24

DIなんて聞いたこともないわけだが。
まったく次から次へと焼き畑農業のようにゴミライブラリ撒き散らして悦に入っている
Java厨は本当に度し難いな。

12 ：07/03/24

まぁＣ/Ｃ＋＋何ぞでは、ＦＷ作る意味すらないからな

13 ：07/03/24

リフレクションが使いにくい言語にはDI適用は困難
ダックタイピングが有る言語にはDIは不要

14 ：07/03/24

DIってDLLみたいなもんだろ。
デバッグ情報含んだDLLをデバッガで動き見て
リリースモードのDLLにして納品みたいな。

15 ：07/03/24

>>14
違う予感
え、そうなの？
不安になってきた。

16 ：07/03/24

うさんくせぇ〜〜〜〜〜
Java開発を変える最新の設計思想「Dependency Injection（DI）」とは
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20050216/156274/?ST=develop&P=2

17 ：07/03/24

国際化対応もDLLにリソースぶち込んで、ロケール見て切り替えってのもそう？

18 ：07/03/24

なんだよＤＬＬって
Windows厨はでてけよ

19 ：07/03/24

soもDLLっていうが

20 ：07/03/24

EJBが糞過ぎてそれをどうにか他環境並みの疎結合に引き上げてくれる夢の新技術がDIってことか

21 ：07/03/24

ﾅﾆこのスレ
ＤＩわからん香具師は出てけ

22 ：07/03/24

>>14
DLLて。。
勘違いにも程があるな。少なくともぐぐってから書き込め

23 ：07/03/24

大して違わないことに気づいても無い奴よりマシだと思う

24 ：07/03/24

しかし徹頭徹尾無内容なスレだな。

25 ：07/03/24

DIなんぞやから語る事自体は悪い流れではなかろう
問題はこの煽り合いの流れが意地の張り合いで終わるのかどうか

26 ：07/03/24

スレタイにDIなんて入れるから中途半端なのが入ってくるんだ。

27 ：07/03/24

>>24
そうならないように、スピード比較結果を貼ってみる
１回目
Spring: 1,734 creations/s
Guice: 35,161 creations/s
S2: 18,395 creations/s
２回目
Spring: 1,776 creations/s
Guice: 37,202 creations/s
S2: 19,394 creations/s
３回目
Spring: 1,783 creations/s
Guice: 36,764 creations/s
S2: 19,164 creations/s
数字大きい方が速いって事で。
http://d.hatena.ne.jp/arumani/20070315/p2
スレの内容見るとこのネタじゃ盛り上がらなさそうだけど(´・ω・｀)

28 ：07/03/24

軽量で高速なDIコンテナは需要あるんじゃない？
うちじゃSpring使ってるけど、サーバ起動時の待ち時間は異常

29 ：07/03/24

つーかＤＬＬとＤＩを同じ基準で比較するバカどもウゼー

30 ：07/03/24

バインディングをコード書いてやらなあかんのがなー
Springで定義したのをGuiceで運用するってのがいいのかなーｗ

31 ：07/03/24

>>28
個人的には、DI定義XMLが無い所がかなり気に入ってる。
リファクタリング手軽に出来るしね。

32 ：07/03/24

>>31
へー。実例とかあったら見てみたい。

33 ：07/03/24

悪りい、ここにドキュメントあったわ
http://code.google.com/p/google-guice/w/list

34 ：07/03/24

jarを(dll)をどうロードするかでしかないんだから
こんなものありがたがってる奴らはドカタだわな

35 ：07/03/24

>>34
いいからコボラーは引っ込んでろ

36 ：07/03/24

>>34
むかしはファクトリのコードを手で書いてたんだから、かかなくて良くなりゃ
それに越したことはないと思うんだけど。

37 ：07/03/24

だが、バインディングコードを書く時点で「コードを書く」こと自体は従来と同じ（戦略はともかく）
アノテーションのみだったらまだ違うけど

38 ：07/03/24

春休み明けに立てればよかったのに

39 ：07/03/24

ユーザガイドざーっと読んでみた。とりたてて目新しいことは無いな。
>>37
コードでもバインディングできますよ、ってだけで基本アノテーションのみ
じゃないの？

40 ：07/03/24

まったくだな、>>38みたいな盲目な人間が消えてくれる

41 ：07/03/24

ソースをざーっと読んでみた。とりたてて目新しいことは無いな。。
googleは何でこれ作ろうと思ったんだ？？

42 ：07/03/24

作ったアプリの中からスピンオフしただけだろ
企業発のコードなんざ大抵そうだ

43 ：07/03/24

へー、そういうものなのね。

44 ：07/03/24

>>39
いや。バインディングのコードは必ず必要。

45 ：07/03/24

簡単なDIだけでいいなら不要だけど
多分それじゃもの足りんよねー

46 ：07/03/24

>>41
思うに、実行速度を早くしたかったのかと・・・・
Springの定義から作ったものをGuiceに上で高速に
動かしたいんじゃないの？

47 ：07/03/24

>>41
バインディングがコードで書けると
jUnitで単体テストが書けてとても嬉しいよ。
XMLの場合、結合しないとテスト出来なかったから。

48 ：07/03/24

オリは逆にDJUnitでコードバインディングみたいにコーディングしてダミーのクラスとか入れ込んでたけど
XMLで定義できたらなぁとか思ってたｗ

49 ：07/03/24

>>47
ん？手でmockをセットすればテストできるけど、そういう話じゃないよね？

50 ：07/03/24

ちら裏スマン
4月から超ファイヤープロジェクトに放り込まれそうだ。
ってか、燃えカスしか無いかも。。。
漏れは製造系の会社のIT分門で、9ヶ月前ぐらいにIT系の会社から
社内SEとして転職。で、問題のプロジェクトは工場で使う生産系の
システムを外部に請負で発注。テストもてきとうで、少し前から触るとなんか出る
って感じでやばいのがどかどか出てきた（ってか根幹の仕組み自体が破綻してるみたい）。
検収上げなきゃ良いじゃんって思ったけど、こっちの期末処理の関係で
3末で検収ださなあかんのだとｗｗｗ
保守契約は無し。構築中にスキトラ受けて自分らでやる予定だったみたい。
で、どうするかなーと思い、BLだけ切り出してきてDIでくっ付けなおそうかと。
BLの部分はJavaの基礎と最低限のライブラリの知識で作れるようにして
業務を知ってる社内のエセSEをちょっと鍛えて作ってもらうと。
数億の仕組みだから1人じゃどうにもならんので、人海戦術使うならこんな感じかなと。
立て直るかはプロジェクトの進め方で7割は決まると思っていて
やり方は色々あると思う。ただ、バグを1つ1つ潰してたら、きりが無い
という噂が流れてきてるから、上記みたいな事を考えてる。
まだ自分で蓋を開けてないから変わるかもしれないけどね。

51 ：07/03/24

フルスクラッチするなら幾らでもやりようがあるがノー
結局そうした方がいい場合が多いんだけどねー
目先の予算やら何やらでお茶を濁すと結局は本質的な問題が
解決されずにグダグダするだけだったりして・・・

52 ：07/03/24

>目先の予算やら何やらでお茶を濁すと結局は本質的な問題が 
>解決されずにグダグダするだけだったりして・・・ 
まったくです。でも4月からの予算枠も当然取ってないですとｗｗｗｗ
って事で、社内要員でなんとかするしかなさそ。
1年以上やってるプロジェクトだから、なんとか活かせる部分は
活かして短期決戦に持っていきたい。

53 ：07/03/24

∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵。∴∵
∴∵∴∵:。∴∵∴∵∴: --─-　∴∵∴∵∴∵∴∵
∴∵゜∴∵∴∵∴∵　 （___ ）（___ ）　>>50∵∴∵　゜
∴∵∴∵∴:∵∴∵_　i/ ＝　＝ヽi　∴∵∴∵。∴∵∴
∴∵☆彡∴∵∵ ／/[||　 　 」　　||]　∴:∵∴∵∴∵:∴∵
∴∵∴∵∴∵　/　ﾍ　| |　 ____,ヽ | |　∴:∵∴∵∴∵:∴∵
∴ﾟ∴∵∴∵ ／ヽ ﾉ　 　 ヽ＿＿./　　∴∵∴∵:∴∵∴∵
∴∵∴∵　 く　 /　　　 　三三三∠⌒＞　∴:∵∴∵:∴∵
∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∴∵∵∴∵∴∵
　　 ∧∧　 　∧∧　　∧∧　 　∧∧
　　（　　 ）ゝ （　　 ）ゝ（　　 ）ゝ（　　 ）ゝ　ムチャしやがって・・・
　　 i⌒　/ 　 i⌒　/ 　i⌒　/ 　 i⌒　/
　　 三　 |　　三　 |　　三　 |　　三 　|
　　 ∪ ∪　　∪ ∪　　∪ ∪　　∪ ∪
　　三三　　　三三　　三三　　三三

54 ：07/03/25

全然チゴタ

55 ：07/03/25

コレクションへのDIとかってGuiceではどうすんかしら？
そこは直接書かないとアカンみたいな希ガス
■　Spring
　<bean id="test1" class="test.Test1" singleton="true"/>
　<bean id="test2" class="test.Test2" singleton="true"/>
　<bean id="test3" class="test.Test3" singleton="true"/>
　<bean id="testFactory" class="test.TestFactory" singleton="true">
　　<constructor-arg>
　　　<map>
　　　　<entry key="test1" value-ref="test1"/>
　　　　<entry key="test2" value-ref="test2"/>
　　　　<entry key="test3" value-ref="test3"/>
　　　</map>
　　</constructor-arg>
　</bean>
　TestFactory testTactory = (TestFactory)beanFactory.getBean("beanFactory");
　Test test = testTactory.getTest(key);
　test.process();
　　

56 ：07/03/25

■　Guice
　@Singleton
　public class TestFactory{
　　Map<String,Test> map;
　　static{
　　　Injector injector = Guice.createInjector();
　　　map = new HashMap<String,Test>();
　　　map.put("test1",injector.getInstance(Test1.class);
　　　map.put("test2",injector.getInstance(Test2.class);
　　　map.put("test3",injector.getInstance(Test3.class);
　　}
　　public TestFactory(){}
　　・・・
　}
　TestFactory testTactory = injector.getInstance(TestFactory .class);
　Test test = testTactory.getTest(key);
　test.process();

57 ：07/03/25

>>56は間違ってるけど適当に脳内補完してくださいｗ

58 ：07/03/25

>>56
こんな感じになる希ガス
　public interface IfItems {
　　Map getItems();
　}
　public class ItemsMock implements IfItems{
　　public Map getItems(){
　　　マップ作る処理
　　}
　}
　public class MyModuleMock implements Module {
　　public void configure(Binder binder){
　　　binder.bind(IfItems.class).to(ItemsMock.class)
　　　　　　.in(Scopes.SINGLETON);
　　}
　}
　public class ItemProcessorImpl impletemts IfItemProcessor {
　　private IfItems mItems;
　　public void process(){
　　　mItemsを使った処理
　　}
　　@Inject
　　void injectItems(IfItems inItems){
　　　mItems = inItems;
　　}
　}
　
　Injector inj = Guice.createInjector(MyModuleMock.class);
　IfItemProcessor ip= inj.getInstance(ItemProcessorImpl.class);
　ip.process();

59 ：07/03/25

間違ってた
Injector inj = Guice.createInjector(MyModuleMock.class);
　　↓
Injector inj = Guice.createInjector(new MyModuleMock());

60 ：07/03/25

むむむ・・・・
ちなみにやりたいことは、
　switch(key){
　case 1:
　　　// １の時の処理
　case 2:
　　　// 2の時の処理
　case 3:
　　　// 3の時の処理
　}
のような、ある条件に応じて処理が分かれるロジックを
コマンドパターンで解決しようとしているところで、
条件と処理の関連付けをDIで解決しようとする場合に
どうすりゃいいのかのー？ってことなんだなこれが
Springなら<map>でそれができるんだけど、同じことをやろうと
すると>>56のようにマッピングは自力で書かんとイカンだろなー
っというところだがどうなんだろう？
Mapを使わなくても条件と処理の関連付けがコーディング
しなくても出来ればいいなと
で、>>58だと、条件と処理のｾｯﾄ（＝ItemsMock）と、
条件に応じた処理を実行するコンテキスト（＝ItemProcessorImpl）の
依存関係がDIで解決されているように思うのだが、だとすると
そこは悩ましいところではないんです
違ってたらすみません。

61 ：07/03/25

>>60
なるほど。それならこれでいけるかな。
ただ、その処理やるならkeyとクラス名を紐付けといてリフレクションで呼んだ方が楽かと。。
　public interface IfCommand {
　　public void exec();
　}
　public OneTimeExecCommand implements IfCommand{
　　public void exec(){何かの処理}
　}
　public TwoTimeExecCommand implements IfCommand{
　　public void exec(){何かの処理}
　}
　public class MyModule implements Module {
　　public void configure(Binder binder){
　　　binder.bind(IfCommand.class).to(OneTimeExecCommand.class)
　　　　.annotatedWith(OneTimeExec.class).in(Scopes.SINGLETON)
　　　binder.bind(IfCommand.class).to(TwoTimeExecCommand.class)
　　　　.annotatedWith(TwoTimeExec.class).in(Scopes.SINGLETON)
　　}
　}
　pulic class CommandProcessor {
　　private @Inject @OneTimeExec IfCommand oneTimeExec;
　　private @Inject @TwoTimeExec IfCommand twoTimeExec;
　　public process(){
　　　switch(key){
　　　case 1:
　　　　oneTimeExec.exec();
　　　case 2:
　　　　tweTimeExec.exec();
　　　}
　}

62 ：07/03/25

むむむむむむ・・・・・
っていうか、switch文で解決しようとすると、条件が増減したりすると
ソコのコードを書き換えなきゃでしょ？
switch文を書かないようにすることが主目的なんだけどなー
条件と処理のマッピングが設定で出来れば条件の追加はコーディング不要になるでしょ
少なくともMapなどのコレクションでの解決は、コレクション要素の追加だけで
修正が出来るからいい解決方法かな？と思ってるんだけどね
Springの場合は<map>に<entry>を追加するだけでいいんだけど
Guiceは要素を追加するコードは書かなきゃならんようだなー

63 ：07/03/25

あと>>60はこうでした
　switch(key){
　case 1:
　　　// １の時の処理
　　　break;
　case 2:
　　　// 2の時の処理
　　　break;
　case 3:
　　　// 3の時の処理
　　　break;
　}

64 ：07/03/26

>>62
あ〜ようはCommandインスタンスのMapをインジェクションしたいと。
それならProviderでラッピングしてやれば出来るけど
Springより面倒だね(´・ω・`)

65 ：07/03/26

>>1
ｲﾀｲｿﾞ

66 ：07/03/29

とりあえず日本語の情報源っぽいもの
Users Guide翻訳
http://d.hatena.ne.jp/shot6/20070320#1174359874
なんか色々試してるブログ（のリンク）
http://www.wikihouse.com/arumani/

67 ：07/03/31

よし
XML定義ファイルからModuleを自動生成して登録する拡張を作るぞ

68 ：07/03/31

>>67
わかった
ならおれはOGNL実装する

69 ：07/03/31

SpringのXMLファイルをそのまま使ったらまずいかしら？

70 ：07/03/31

>>69
お！それいいね！

71 ：07/03/31

>>50
javaのお仕事ってこういうのが多いのかね？

72 ：07/04/01

XMLでbindの定義したのを読み込んで、Module内でバインディングしようとしたら
bindする型をはっきりさせないと遺憾からXML定義による自動バインディングは
できんかった・・・
バイトコードいじれば出来るのかしら？
しかしそれはメンドイ
やはりXMLからModeuleクラスを作るようにしよか・・・

73 ：07/04/01

>>72
おまいは本気でxmlで定義しようとしてるのか！？
あぁ。。４月１日か。。

74 ：07/04/01

バインド定義をコーディングするのはオレてきにメンドイ

75 ：07/04/01

続きはWebで・・・・
http://d.hatena.ne.jp/guiceex/
（ここもWebだが）

76 ：07/04/01

>>74
なら、SpringかSeasar使えと。。
Guiceの利点はxmlを使わない所にある。

77 ：07/04/01

コードでバインディングめんどいかー？エディタで補完効いて快適じゃん。

78 ：07/04/01

コードをゴリゴリかくのメンドイし、どうバインディングされてるかわかりにくいのが良くないと思う
最終的にはExcelで定義したバインディング仕様からModuleクラスが作れればいいかなと・・・・
まぁ挫折してもエイプリルフールってことでｗ

79 ：07/04/01

>>78
１０年程PGや設計やってきて出した俺的結論としては
PGのコード記述するのに、外部ファイルや自動生成系は使うなだな。
自動生成やるにしても、最初の１回だけで後は使わない。
理由は単体テストがやりにくい・リファクタリングが自動で出来ないのと、
管理がめんどいから。
自動生成で作成したJavaソースはいじらないってルール作っても、
従わないヴァカがいっぱいいるんだよ世の中。
78はまだ若そうだが、いずれ分かるようになるさ。

80 ：07/04/01

マダマダ若いなｗ
１５年この業界にいてフレームワークを作り続けてきた俺の結論は
ドキュメント＝実行モジュールになるのがもっとも生産性が高いってこと
幾らプログラム作ってもドキュメント化されないと保守できない
システムのメンテナンスは同じ人間がやれるわけでもないし、
新しい人間がスグに使えるようになる必要もあるのだよ
プログラマからすれば自分の作業が問題なければそれでいいカモしれんが
それじゃいかん

81 ：07/04/01

>>80
ま〜理想で言えばそうだが、現実は違うわなw
ドキュメント書くだけでJavaソース作ってくれる
某G○nってツール使った事あるんだが、パフォーマンス糞だったぞ？
いくら生産性高くて(特殊なツールで生産性高いとは言えなかったが。。)
シス方と開発がウハウハでもユーザー不在なのはどうかと。
ドキュメント書くのはSEの仕事だから、
PGはJavaDocさえきっちり書いとけばいいんじゃね？

82 ：07/04/01

ドキュメント＝実行モジュールと考えるからよくない。
実行モジュール＝ドキュメントと考えればいいんだ。
つまり、ソースがそのままドキュメントになる。
guiceは、メソッドがinとかtoとかになってるんだが、
英語が母国語な人にとっては、
このソースはドキュメントっぽく読めるんじゃないだろうか。

83 ：07/04/01

>>81
1から10までってのは難しいと思うけど、インターフェイスの部分て言うのは
わかりにくいからドキュメント化したいし、バグの温床でもあるからねぇ。
例えばエンティティクラスやStrutsのActionFormのようなデータインターフェイス
は自動生成して、データの転送はリフレクションを使ったプロパティコピー
ユーティリティのようなもの（commons-beanとか）でコードを極力書かない
ようにしたほうがバグも少ないし生産性も高い。
Guiceの場合はGuiceとアプリケーションのインターフェイスであるModule
を自動で作ったりバインドしたりする方がそのインターフェイス間での問題が
少なくなるし、どんなバインディングしてるのかが第3者にもわかりやすくなる。
>>82
Hibernateもそうだけど、
　hoge.createSQLQuery(...).
　　　　.addEntity(.....)
　　　　.setString(....)
　　　　.list()
見たいな続けて書くのがはやってるね。
こういうプログラムを書のは面白いと思うけどｗ

84 ：07/04/01

>>82
ドキュメント＝実行モジュールも
実行モジュール＝ドキュメントも同じ意味なんぢゃ。。
ソースがそのままドキュメントになるのは同意。
ただ、実装のソースじゃなくてTDDなjUnitテストケースのソース(javaDoc付き)だが。
ちなみに、
>英語が母国語な人にとっては、
>このソースはドキュメントっぽく読めるんじゃないだろうか。
この考え方はCOBOLやSQLに取り入れられてる。

85 ：07/04/01

よかったらおためしくだされｗ
http://d.hatena.ne.jp/guiceex/20070401

86 ：07/04/03

guice使えるよguice

87 ：07/04/03

Springは使うインターフェースがドキュメントにかかれてないとわからないけど
Guiceはモジュールを見るだけだから一目瞭然でわかりやすいな
ドキュメントが常に最新のコードをあらわしているわけではないという法則があるから
これはうれしい

88 ：07/04/03

ふうん

89 ：07/04/04

結局、俺はリファクタリングが利くのが一番いけてるところだと思うな。
XMLの書き間違い、規約の間違いみたいなものは、ビルド時に発見されるので
単純だけど問題解決に時間がかかってしまうケアレスミスみたいなのが減る。
これはプログラマの精神安定的な観点からも非常にいいことだと思う。
もっとも、リファクタリング(の自動化サポート)の価値については
Javaを使ってるさらにIDE族(多分Eclipseが最大勢力)だけしか、
価値が分かってない気がするので一般のプログラマーには
あんまりありがたみが分からないだろうなーってのも事実。

90 ：07/04/04

>>89 参考になる。
メモメモφ。

91 ：07/04/04

Springだとどのインターフェースでアクセスすればいいのかがわからないために
仕様書眺めて使うようなタイプになっちまう
>>89
タイプセーフってのは大きいよ
コンパイルが通るだけでもモジュール定義とか失敗してないのがわかるわけで
IDEのサポートがないならなおさら重要
あと実装ベースでDIする場合モジュール定義がいらないので手軽な疎結合にも十分な価値がある
おもにJavaSE側でGUIクライアント側で使う場合や小規模実装にすばらしく重要

92 ：07/04/04

>>89
だな。コンパイラがチェックしてくれるのはかなり大きい。
IDEが使える環境ならxmlもチェックしてくれるが、
使えない環境では実行時にしか分からないのが痛い。
IDE使っててもリファクタリング何それ？な奴が殆どだけどな

93 ：07/04/06

いいよGuice

94 ：07/04/06

>>92
一番はありえないだろjava使ってたらさ…とまじれす

95 ：07/04/06

×一番はありえないだろjava使ってたらさ…とまじれす
○一番下はありえないだろIDEでjava使ってるならさ…とマジレス

96 ：07/04/07

>>95
いや、ありえる。
リファクタリングとユニットテストの関係を分かってない奴だと、１度動いたソースを修正することに抵抗が在る奴らが多い。

97 ：07/04/07

リファクタリングって別にIDEでの一部の機能だけをさすわけじゃないから
動いてるソースをいじるのは誰だって抵抗はあるだろ

98 ：07/04/07

つーか
Guiceがリファクタリングにコレまで以上に貢献しているってわけでもないような・・・・

99 ：07/04/07

>>97
jUnitできちっとテストコード書いてる
テストファースト信者なおれは抵抗ないがな

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

【】configure大嫌い【RMS】 (482)
UnicodeとUTF-8の違いは？　その2 (711)
国産オープンソースDIコンテナSeasar2 その16 (460)
【統計分析】機械学習・データマイニング【集合知】 (844)
JavaScriptスレ2 (316)
リファクタリングをただのコード修正と思ってる人へ (267)
--log9.info------------------
Miles Davis 電化マイルススレッド Part 29 (365)
高田馬場イントロ (495)
＜福岡ブルーノート＞今年８月末で閉店へ (761)
Steve Kuhn に胸キューン (255)
渡辺香津美（笑） (930)
ジョン・コルトレーンを語る【part8】 (671)
--------秋田のジャズ事情-------- (575)
ジャズをヤル女が増えた?? (183)
阿部薫 (292)
Joe Pass (342)
おすすめのジャズの曲教えろ・・いや教えてください (289)
小曽根真について語れや！Part2 (363)
名古屋　ＪＡＺＺ (390)
山口県のジャズを語れ (116)
アート・ペッパー・アダムス (180)
★☆ジム・オルークですよ☆★ (338)
--log55.com------------------
猫の虐殺事件報道は集団ストーカーのでっち上げ
１億総活躍社会（新三本の矢）は可能か？
【偏向報道】ＴＢＳが「放送法遵守を求める視聴者の会」を批判
産経新聞・パラオ・住田良能・日本青年社・米田建三
産経新聞論説顧問 飯田浩史　原子力担当
藤井聡･京大教授｢大阪では大阪都構想批判が難しい｣
☆理科系の報道（ゲノム編集・ブロックチェーン等）
朝日新聞はどうかな？