動的言語の問題点、大規模開発でテスト工数が増大

1 ：12/04/24 〜 最終レス ：12/05/30

　しかし、RubyとRailsの限界に気がついてしまったのです。Rubyのランタイムは
非常に遅いため、Rubyで作成したアプリケーションの納品をためらったことがあります。
Rubyはプロトタイプ作成用に使い、納品用にJavaで作りなおさなければなりませんでした。
　RubyとRailsのプロジェクトが数千行の規模を超え、チームに新しいメンバーを追加したときに、
動的言語の問題が明らかになって来ました。私たちは、コーディングの時間の半分をテスト作成の
費やさなければならなかったのです。Railsによって得られた生産性の向上は、テスト作成の作業に
失われてしまいました。作成したテストの多くは、Javaであれば不必要なものでした。テストの大半は、
リファクタリングによってメソッド名やパラメータの数を変更した際に、呼び出し元が
正しく変更されているかを確認するためのものでした。
また、Rubyでもチームメンバーが2名から4名であれば、メンバー間のコミュニケーションは
非常にスムーズでした。しかし新しいメンバーをチームに参加せせようとすると、
これまでチームで培ってきたノウハウを新しいメンバーにうまく伝えることが出来なかったのです。

2 ：

馬鹿な上司が「JavaからRubyへ」を読んで
Javaで作ったプログラムをRubyで書き直し
プロジェクトが大きくなりメンテナンス不能のなって
結局またJavaで書き直し

3 ：

数千行？

4 ：

数千行がRuby+Railsの限界ってこと？

5 ：

>>1
これは「Scalaプログラミング入門」3ページからの引用ですが、
RubyがJavaに比べて一方的に劣っていると誤解させる恣意的な引用ですね。
筆者はScalaがJavaとRubyの長所を併せ持つとしか主張していません。
そしてScalaが関数型言語でもある事を最も重要な事としています。
筆者の考えがより正確に伝わるように前後を引用します。
直前の記述：
1996年、Javaとの初めてのは、まさにお告げでした。
メモリの解放について悩まなくても済みます。Javaにはまともな例外処理機構があります。
一夜にして、私が作ってきたプログラムで発生した欠陥のうち、70%がすべて解決されたのです。
それから長い間、私はJavaを使いつづけ、愛してきました。
（中略：JVMはどんどん速くなった）
JVMが成熟してきたのに対し、Java言語は長年にわたり、成熟することができませんでした。
Javaの文法は停滞し、JavaのWebアプリケーションフレームワークは、どんどん肥大化してきました。
フィールドの定義や、フィールドをもとにHTMLフォームを生成するなどの単純なことを実現するだけでも、
JavaやXML、その他の設定ファイルに書かなければならない量はどんどん増えてきています。
ほとんどのプロジェクトでJavaを使っていましたが、Javaに対しての失望感は募っていくばかりでした。
（中略：ジェネリクス導入により、補完機能のあるIDEでないとコーディングできなくなった）
自分の中にあるアイデアを、よりシンプルに、より直接的に表現できるもっと良い方法がないだろうか？
私は答えを探し始めました。そして、RubyとRailsを見つけました。これこそ自由です。
Rubyでは、はるかに少ないコードで自分の考えを表現できます。
RailsはSpringMVCや、Hibernateなどその他の
「効率的な」Webフレームワークよりも、ずっとずっと簡単です。
RubyとRailsを使うことで、頭の中のコンセプトを、より短い時間でより多く実現できます。
C++からJavaへと乗り換えたときに似た、開放感を覚えました。

6 ：

直後の記述：
私は、新しい言語と開発環境を探し始めました。
Rubyの豊かな表現力と、Javaの高いパフォーマンスを併せ持つ言語を探していました。
そして2006年11月、出会ったのがScalaです。
Scalaは表現力とパフォーマンス両方を兼ねそなえているだけでなく、
それ以上の可能性を感じさせてくれたのです。
（中略：Scalaは高速でJavaと互換性がある）
最も重要な事は、Scalaはこれまでと違ったプログラムの方法や考え方を教えてくれたことです。
Scalaを知ったおかげで、バッファーや構造体、オブジェクトの割り当てや、
これらのメモリ操作について考えるのをやめました。
その代わり、私の作るプログラムのほとんどは、
インプットからアウトプットへの変換ととらえられることを学びました。
Scalaは、簡潔でモジュール化されたコードを、
メンテナンス可能な形でまとめられるツールを与えてくれました。
しかも、JavaやRubyを使う場合よりも、はるかに複雑なロジックを記述できます。
2年以上Scalaを使いつづけ、愛し続けた結果、後悔していることが1つだけあります。
それは大学時代にLispを学ばなかったことです。
大学院時代にプログラミング言語理論についてのコースをとっておくべきでした。

7 ：

ああ、カルト宗教の文句に似てるんだな

8 ：

>>1
筆者の考えがより正確に伝わるように引用します。
「テストの大半は、リファクタリング」

9 ：

今カウントしたら、redmineの*.rbの行数が2万行なんだが、数千行ってどんだけ小さいプロジェクトなんだ？

10 ：

原文がどうなってるか知らんけど
数千→数万になったって意味じゃね？

11 ：

これ、上司が糞であって動的言語とか関係なくね？

12 ：

単に開発環境が変わったためのコストを払い切れなかったというケースだな
移行とかに慣れないうちはよくある

13 ：

これで言語（のユーザー）を煽れると思ってしまうということはつまりその人は働いたことがな

14 ：

>>8
Javaに対するEclipseのような修正漏れが限られているリファクタリングツールが
Railsにないからテスト工数が増大したという事ですね。
Ruby+Railsだと修正漏れの少ないリファクタリングツールを作るのは難しいですが、
今後ツールが自動的に修正できる範囲が増えれば必要なテストは減るでしょう。
つまり、Rails用リファクタリングツールの性能向上で解決できる問題だと思います。

15 ：

>>14
オブジェクト指向で何か修正したい場合
メンバーの継承と追加はできるが削除はできないというのが基本です
これはツールではなくパラダイムです
メソッド名やパラメータの数を変更するのも、ツールではなくパラダイムの問題です

16 ：

新手のruby disスレ。
そんなにrubyが憎いか。

17 ：

>>15
リファクタリングについて何も知らないのに「パラダイムの問題」と断言するのはどうかと思います。
内部構造を整理するために既存のクラスを修正するのがリファクタリングです。
メソッド名やパラメータ数を修正した時に呼出側も漏れなく修正されるかどうかはツールの問題です。
リファクタリング (プログラミング)
http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%95%E3%82%A1%E3%82%AF%E3%82%BF%E3%83%AA%E3%83%B3%E3%82%B0_%28%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%29

18 ：

YARVの登場で時代は変わったろ
いつの時代の人間だ

19 ：

>>17
> メソッド名やパラメータ数を修正した時に呼出側も漏れなく修正されるかどうかはツールの問題です。
言語の問題であることも多いよ。
RubyわからんのでPerlの例でいうけど、
たとえばPerlだと
{
　　package Class1;
　　sub new { ... }
　　sub foo { ... }
}
↑このfooというメソッド名を修正した時、
my $c = $flag ? Class1->new() : Class2->new();
$c->foo();
　　　↑ 呼び出し側のfooを変更していいかどうかなんて判別不可能だしね。
Rubyも変数に型がないから、同じじゃない？

20 ：

>>18
YARVはRailsの性能問題を解決しませんでした。
http://ja.wikipedia.org/wiki/YARV
> 2006年12月31日にRubyリポジトリにマージされ、
> 2007年12月25日にリリースされたRuby 1.9.0から、正式に組み込まれた。
http://www.rubyist.net/~matz/20070707.html
>じゃあ、速度の問題はこれで解決かというとそんなことはない。
>YARVになってもRailsの性能は改善されないからだ。
http://it.slashdot.jp/story/09/04/10/0421223/
>Twitter、Ruby on RailsからScalaへ
>　Twitter ではフロントエンド、バックエンド共に Ruby on Rails が使われていたが、
>　最近では大量のメッセージを処理できず「Fail Whale」出現の原因となったりしていた。

21 ：

>>17
断言が気に入らないようだが、宣言的なパラダイムをどう思う？
そもそも「修正する」というのは手続き的だよな

22 ：

>>19
静的型付言語のJavaが静的コード解析で修正箇所を特定できるのに対し、
動的型付言語でダックタイピングを採用したRubyと
黒魔術レベルの動的プログラミングを実現したRailsの組み合わせに対して
必要な修正を網羅するリファクタリングツールを非常に作りにくいのは確かですね。
それでもRailsのバージョン別のツールにするとか
ホワイトボックステストで実行フローを枝刈りするとか
ツールのアルゴリズムを工夫する余地はあると思います。

23 ：

>>21
手続き的か宣言的かオブジェクト指向かというのはプログラムの設計の話です。
リファクタリングは無駄に複雑でわかりにくいコードを全体的に整理するという話です。
あなたは全然関係ない話をごちゃまぜにしています。

24 ：

>>23
あなたは「設計と全然関係ないことをするのがリファクタリングだ」と言っています

25 ：

>>22
余地があるのは、今のRubyのリファクタリングツールが貧弱なだけ。
少しはまともになるかもしれないが、まあ期待するだけ無駄でしょう。
Scalaのおかげで、コードを短く書くのに、動的言語である必要性はないのが証明されました。
これからは静的言語かつコードを短く書けるScalaのような言語が
主流になっていくでしょう。
プログラマだというのに、プログラミングを楽にするためにコンピュータの力を
生かせる言語を作ろうと発想が出てこないのが不思議でなりません。
Scalaは理想の言語ですね。

26 ：

「public static void mainなど、コンピュータに伝える約束事が多くて、
やりたいことが頭の中から逃げてしまう。簡潔さは力なのです」
http://toro.2ch.net/test/read.cgi/tech/1326687331/57

27 ：

コードは「人に読ませるために」あるんだよ
誰も読めないようなperlの魔法的記述の反省でもあるのに
なぜ性懲りもなく繰り返すのか
perl知らない素人じゃあるまいに

28 ：

>>26
ScalaでHello World
↓
println("Hello, world!")
これだけ。
public static void mainなどいらないのです。

29 ：

Smalltalkはテキストを読み書きすることにあまり興味がない
Perlはものすごく読み書きに詳しい
では、読み書きに詳しくない人に読ませるという立場はどこから出てきたのか

30 ：

高度にチューンされた静的言語に動的言語がどうやってもかなわないのは事実だが、
Rubyが遅いのは動的だからって短絡はほんといいかげんやめてほしい。
Rubyが遅いのは単純にまつもとやささだの技量不足ってだけの話しで、
やつらが作れば静的言語だって遅くなる。LuaやV8の実装者に申しわけなさ過ぎる。

31 ：

>>30
LuaやV8はRuby処理系ではないのに、速度差の原因は
言語仕様の違いではなく技量の差とどうやって判断したのですか？
Groovy++で@Typedをつけると型推論を行い静的型に基づいて最適化されます。
@Typedをつけない部分はGroovyと同じく動的ディスパッチや動的型付ができます。
@Typedをつけたかどうかで実行速度が数十倍違います。
コンパイラは同じだから、コンパイラ作者の技量の差などありません。
@Typedをつけると最適化しにくい言語仕様を切り捨てるのが速度差の原因です。
Groovy++
http://d.hatena.ne.jp/uehaj/20100225/1267106256
Groovy++、来襲
http://www.slideshare.net/touchezdubois/groovypp-attack-6229953

32 ：

>>31
> 技量の差とどうやって
動的という観点に絞れば、LuaやJavaScriptはRubyよりはるかに動的だからでＦＡ
> コンパイラは同じだから、コンパイラ作者の技量の差などありません。
それは１行目の話。型情報を使って最適化できる静的型が有利なのは当たり前。

33 ：

なぜ遅いって、jit積んでないからやろ

34 ：

それも技量や知識の無さの証左。

35 ：

コンパイル処理には時間がかかります。
さて、次の三つのうち実行時間が一番遅いのはどれでしょう？
１．コンパイル処理を実行開始前に完了しておく
２．コンパイル処理を実行開始時に行う
３．コンパイル処理を実行されるたびに行う

36 ：

このスレが下記スレの続きなら、
もっと一般的なスレタイの方が良かったのでは？
●過去スレ
やっぱり動的言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1306002146/
やっぱり動的言語では安全なソフトは作れない 2
http://hibari.2ch.net/test/read.cgi/tech/1306571666/
やっぱり動的言語では安全なソフトは作れない 3
http://hibari.2ch.net/test/read.cgi/tech/1308499587/
やっぱり動的言語では安全なソフトは作れない 4
http://hibari.2ch.net/test/read.cgi/tech/1316016777/
やっぱり動的型付け言語では安全なソフトは作れない
http://hibari.2ch.net/test/read.cgi/tech/1316887046/
やっぱり動的型付け言語は大規模開発で効率が悪い 2
http://hibari.2ch.net/test/read.cgi/tech/1319212872/
やっぱり動的型付け言語は大規模開発で効率が悪い 3
http://hibari.2ch.net/test/read.cgi/tech/1320832914/
やっぱり動的型付け言語は大規模開発で効率が悪い 4
http://hibari.2ch.net/test/read.cgi/tech/1321843683/
やっぱり動的型付け言語は大規模開発で効率が悪い 4
http://toro.2ch.net/test/read.cgi/tech/1321972779/

37 ：

Java vs Ruby か
どっちも言語だから良い勝負だな

38 ：

http://attractivechaos.github.com/plb/plb-lang.png
Lua 50.5
LuaJit 6.8
http://attractivechaos.github.com/plb/

39 ：

>>35
>実行時間が一番遅い
日本語で頼む。

40 ：

>>35
３

41 ：

行ごとにコンパイルする場合、コンパイルしなかった行に文法違反があっても
すどおりしたようにみえる

42 ：

動的型付けってすごいよな
初めて見たときは衝撃だよな

43 ：

俺がはじめてみた動的型付け言語は
BASICだ。

44 ：

「動的」の対象が話者によって食い違ったままの隔離スレではあるが、せめて「実行時に型を動的に生成出来るか」ぐらいはチェックしようぜ。

45 ：

PHPでコードを書いてて、 $loginId を $loginid ってスペルミスして、デバッガで追いかけないと
それに気づかなかったり、rubyでendをうっかりendifって書いていて、ミスしたのはコードの
最初のほうなのに表示されるエラーの行番号はコードの最終行でミスを見つけるのが困難だったり
ほんと動的言語はダメだわ。

46 ：

camelCaseを止めて、variable_name形式にすれば少しはいいかも。
あとlint的なものを使えば、その手の間違いを検出できる場合もある。

47 ：

静的言語だと「文脈と間違え方から見ておそらくこの部分がこう書きたかったスペルミスだと思われます」とか言ってくれるのか
アホ

48 ：

Rubyはifだろうが繰り返しだろうがメソッド定義だろうが例外捕捉だろうが全部endだからな
動的かどうか全く無関係に区別は不可能
っていうか着色とキーワード改行インデントするエディタ使え

49 ：

>>47
静的型付け言語だと、変数の宣言が必須でコンパイルエラーになるから検出が容易

50 ：

誰が静的型付けの話をしている

51 ：

…とりあえず、「静的」「動的」のとこで語句区切るの今後一切禁止で

52 ：

定義厨はいいよ

53 ：

>>52
時間潰しでレス欲しいだけならVIPやニュー速や嫌儲へどうぞ

54 ：

>>47
IDEがサポートしてる静的言語ならエディタで入力した時点でそんな変数ないって指摘してくれる。

55 ：

動的型付でも動的定義でも、98％くらいは静的に（代入子で）定義された名前だろうから、
頑張れば大部分は検知できそうな気もするが、流行らないのはなんでだろう

56 ：

"login_id = param"のつもりで"loginId = param"と書いてしまったときの話だよ？

57 ：

全然違った。
"loginＩd = param"のつもりで"loginid = param"と書いてしまったときの話だよ？

58 ：

>>55
グローバル変数の使用状況を見れば、頑張らなくてもチェックできるんだが
グローバル変数が無い言語が流行っている

59 ：

Javaの視点で動的言語がダメだというのは、その通りなんだな
全然違う視点を持つと結果は変わってくるが
クラスベースOOとかJavaに近い動的言語はダメになる

60 ：

つーかミスをする人間は
動的言語を使うなという話。

61 ：

ミスをしない人間なら直接バイナリを書けるよな

62 ：

CにGCつけたら書ける
ただしGCが改良される度にソースの互換性がなくなる気がする

63 ：

>>60
使い物にならない言語という結論

64 ：

名前をトレースできないように出来る言語は総じてカオス
現行のほとんどの言語がやれちゃうのでどうしようもない
あきらめてスクリプト言語で作ろうぜ
俺は絶対にやらないけど

65 ：

ボイルの法則とかシャルルの法則とかボイルシャルルの法則とか
名前をつけても何も解決しないな

66 ：

　　 　 　 　 　.,　i!　/　　ﾊ　　　　,　　　i!　 　 ヽ　 V　　 |　　　　 |　i
　　　　l　 　　i!　l　,　 ＿,.ﾍ　V　　＼　 {ヾー- _',___Ｖ　　|　　　　l|　|
　　　　il　__.ｨﾁ "| i!￣　　 ﾊ　'.,　　　＼ ' ,　　　　ヾー __i!　 　 　i|　|
　　　　.!￣　 |　 ,ｨ≦三ﾐ､　 ',　＼　　 　 i｀,ｨfゞ三ミ､　 ',.|　　　 , |　|
　　　　 !　　 i|. ,'/　,'´}:｀ヽ.　 　 　＼　 　|　.,'´}:｀ヽ ヾ.,　',!　　 / i|　|
　　　　 ,.　　 ! {{' 　{´:::::::::}.　 　 　 　ヽ.　i!　{;´:::::::::}　 }}　}　　/　i|　|
　　　 　 ,　i　i! ゞ　 ゝ;;;;;ソ,　　 　 　 　 ヽ!　 ゝ;;;;;ソ　 ﾘ' ,'　 / 　.i|　|
　　　　　,　l､ ',　　　　　　　　　　　　　　　　 　 　 　 　 /　,ｲ　　.i|　|
　　　　　 , i! ヾ.　 /////////　　　　 　 ///////　　/／　　 　.l|　|
　　 　 　 ﾍ! .{ .｀　　　　　　　　　　 !　 　 　 　 　 　 /'/　;i　　　 i|　|
　　ﾊ 　　　,　｀∧　　　　　　　　　　　　　 　 　 　 　 / ノ,'　 　　 |　|
　　 ﾊ　　 　',　　 ヽ　　　　　　　__　 __　　　 　 　 　/　 / ./　 　 |　|
　　　ﾍ　　　 V　　 ヽ.　　　　 ,´ ＿＿ ヽ　　 　 　.ｲ　 /／　　i|! .|　|
　　　 ﾍ　　 　V　 .i!　 ヽ.　　 　´　 　 ｀　　 　 ィ　　 /´ i!　　 l|　i|　|
　　　　 ヽ　 　 ',　 i! 　 　| ＞　　　　 　 　＜ |　　　　　 |　　　i! .i!　|

67 ：

動的型付け言語の一番の問題は・・・
静的型付けのC++なら、この程度の関数は何も気にせずに使えるけど、
http://ideone.com/xcxjC
動的型付けのJavaScriptだと、この程度の関数でも気をつけて使わないと駄目な代物になる事。
http://ideone.com/lbcaB

68 ：

お兄ちゃん、型付け型付けとうるさいけど自分のお部屋を片付けられないんだね・・・

69 ：

>>68
現実には型付けがなくて片付けられないんだよ

70 ：

誰が面白いこといえと

71 ：

>>67
でっていう
ライブラリ側は全て静的言語でやって（速度も速いし）
その速度の速いライブラリを動的言語から呼び出したり、
型情報とかいちいちつける意味のない
実装コードは動的言語でさっさとやるんだよ

72 ：

「intとか核のめんどくせぇ！」っていうなら型推論使えよvarとか

73 ：

ミスを指摘されるのを嫌う人間が好んで使うらしい

74 ：

コメントを付けなくちゃいけない規模になったら
もう動的型付け言語ではやっちゃいけないってことなんだよ。
この変数は○○型です。なんて
コメントをつけ出したら末期。

75 ：

システムハンガリアンでおk
と言うかシステムハンガリアンが活きるのって
CやJavaやC#じゃなくて動的言語だよなあ

76 ：

C++ with Boostにシステムハンガリアンで脳死

77 ：

動的言語なのにシステムハンガリアンって、悪いところ取りになってないか。

78 ：

動的言語でも、この変数には互換性のない型を
いれても正常に処理しますってのは無いんだから。

79 ：

疑わしきは罰せずってのが有る
つまり、コード自体のミスよりも
悪いコードに罰を与えようとする側の判断ミスの方が深刻な問題になる

80 ：

テストの大半は、リファクタリング

81 ：

>>1
予想通りで笑った

82 ：

>>77
動的型付けだからシステムハンガリアンが必要になるんじゃないの？
違う型突っ込んでもシステムがエラーを拾うわけじゃないんだろうけどさ

83 ：

>>71
> ライブラリ側は全て静的言語でやって（速度も速いし）
> その速度の速いライブラリを動的言語から呼び出したり、
> 型情報とかいちいちつける意味のない
> 実装コードは動的言語でさっさとやるんだよ
ブラウザだと逆になってしまいそうだな。
ライブラリは速いJavaScript、それを使うユーザーは静的型言語から変換。
どうしてこうなった

84 ：

ブラウザがＶＭ向け中間コードのI/Fを公開していないという欠陥

85 ：

これ
動的言語はダメだ　ってふうに勘違いされやすいけど
そうじゃなくて
今まで静的言語でプログラム開発していた部分に
やっと動的言語が1歩踏み込んだけど、まだ色々と足りなくてダメだったね
ってだけだからね
いずれにしよ、小規模なプログラム開発では動的言語に静的言語が勝てるわけないから
そのうち大規模開発でも動的言語は使い物になると思うよ
今は、「え？別に動的言語で大規模開発できるでしょ？」って無理して発言する事ではなく
「なぜ出来ないのか？」「どうすればいいのか？」　それを考える時期

86 ：

uyがまともなこと言うなんて、どうなってんだこの世の中。

87 ：

「小規模なプログラム開発では動的言語に静的言語が勝てるわけない」
からどうして
「大規模開発でも動的言語は使い物になると思うよ」
につながるのかが、さっぱりワカラン。

88 ：

クソコテuyが初めてまともなこと言った。
世界が滅びる兆しのようだ。

89 ：

愛されてるな

90 ：

心配しないでも、動的言語の問題点は関数型言語が克服したよ。
動的言語に近い簡潔さで型安全なプログラムが書ける。
動的言語：小規模書き捨てスクリプト
関数型言語：中規模少数精鋭
静的手続き型言語：大規模ドカタ開発
こんな感じで棲み分けされるよ。

91 ：

関数型の時代は来ないと思うよ
概念が中途半端

92 ：

中途半端ってことは、何らかの軸の中間辺りに関数型が位置するって意味になるが
その軸の両端には何の概念が来るんだ？
中途半端さが理由で流行らないってことは
中途半端でない概念をベースにした言語は流行ってるのか？
ってここまで書いて気付いたがuyかよ

93 ：

両端は、アマチュアの趣味と、プロのぼったくり

94 ：

真ん中はアマチュアのぼったくりか。
やっかいだな。

95 ：

うわぁ頭悪そう

96 ：

彼らは人間ではない。また、動物でもない。
だが、その醜い身体の中には正義の血が隠されているのだ。

97 ：

OO　＜　関数型　　＜＜　　俺様

98 ：

↑クズ度の指標です

99 ：

動的言語ってのは実行時に決めることが多いんだけど
本当に実行時じゃないと決まらないことって少ないんだよね。
実はコードジェネレータでコンパイル時に定義ファイルなどから
コードを動的に生成するだけで十分ってことが多い。

100read 1read

1read 100read

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

【消しゴム】MONOを使ってみるスレ4【じゃない】 (150)
◆◇◆dbMAGICってどうよ？◆◇◆ (802)
【入門】Common Lisp その9【質問よろず】 (306)
Eclipse統合M32【Java/C++/Ruby/Python/Perl】 (878)
【GUI】wxWidgets(旧wxWindows) その5【サイザー】 (429)
Androidプログラミング質問スレ Part22 (364)
--log9.info------------------
アメリカズカップ (802)
マリーナについて語れ【2隻目】 (427)
船外機、２ストと４スト適してるのはどっち (403)
日産のクルージングボートの魅力を語る (379)
お前ら小便・大便どうしてる？ (152)
クルーザー持ってる香具師の職業は？ (255)
【岡山県】関西高校ボート部 (406)
ＭＪ−ＦＸ　MJ-VX について　 (228)
【野球】星野日本代表監督がヨットの五輪入りを批判 (305)
おまいらの船は無事でつか？ (146)
リビエラ３７コンバーチブル盗まれました (187)
ＪＥＴ屋について語ろう《関西圏》 (239)
船の電装について語るスレ (366)
MerCruiser マークルーザー★α Bravo メンテナンス (518)
領海侵犯 (185)
■■■５ｔ限定廃止いつ？最新情報スレ■■■ (410)
--log55.com------------------
【社会人】ところでアナタってどんな人？1263人目
もの凄いｽﾋﾟｰﾄﾞでｶｯﾌﾟﾙの質問・相談に答えるｽﾚ 485
【テンプレ】男の人に質問 214問目【必読】
恋人と別れたい人のスレ　part41
【ホルモンバランス】PMS Part7【崩壊】
セックスレスなカップル8
【ｶｯﾌﾟﾙ】チラシの裏92枚目【ｶｯﾌﾟﾙ】
【ｶｯﾌﾟﾙ】チラシの裏95枚目【ｶｯﾌﾟﾙ】