ヒマをみつけてWeb開発
その場の思い付きを、ヒマをみつけてWebサイトにしてみるブログ

Javaと.NETのエンディアンの違いでCassandraの互換性崩壊( ̄□  ̄ ||

Friday, 4 June 2010 02:23 by sabro

昨日の件ですが、Javaと.NETでは、数値をバイト配列にした際の順序はやはり逆になるようです。バイト配列の格納方式はエンディアンといって、先頭から素直に並べるビッグエンディアンと、逆順に並べるリトルエンディアンがあります。

Javaの場合は常にビッグエンディアンとなり、.NETの場合は、CPUによって並べ方が変わるようです。x86系のCPUでは、リトルエンディアンになるみたいですね。.NETでは、BitConverterクラスに、IsLittleEndianというフィールドがあるので、それを見て、自前でバイト配列を並べ替えることで対処は出来るみたいです。

で、Cassandraemonで数値を格納するときにどうするか決めないといけないわけです。少なくともLongTypeのカラム名に格納する際は、ソートできるようにビッグエンディアンへの変換が必要ですね。他の場合はどうするか・・・。Thrift側でやってくれたらよかったんだが。

1、すべての数値を格納前にビッグエンディアンへ変換する

とりあえず、数値をToCassandraByte関数などでバイトへ変換するときは、常にビッグエンディアンにしてしまうというやり方がまず考えられます。このやり方だと、カラム名だけでなくカラムの値もビッグエンディアンになります。この方式のいいところは、Javaと相互運用が可能な点です。常にビッグエンディアンが格納されるので、Javaからも問題なく読みだすことができるはず。ただ、完全ではなく、数値を自前で野良バイト変換してCassandraへ格納した場合に、整合性が取れなくなることはありますね。

2、LongTypeのカラム名に格納するときだけビッグエンディアンへ変換

Cassandraemon側で、LongTypeのカラム名登録の場合だけ、自動でバイト配列を逆順にするやり方です。.NETから見た場合の相互運用性が高くなります。他の.NETクライアント、例えばhectorsharpなどから、カラム名以外は違和感なく値の取得ができると思います(そういえば、hectorsharpでは、この問題どうしてんだろ)。

3、自動的な変換はやらない

Cassandraemon側では一切変更を行わず、リトルエンディアン変換関数とかを用意しておき、LongTypeカラム名登録時は各開発者に自分で変換を行ってもらうやり方です。面倒ではありますが、どのカラムにどのエンディアンで格納されているかを開発者側が管理出来ると言うメリットがあります。ただ、値取得時に、このカラムはどのエンディアンかを意識して変換する必要もあるので、大人数での開発などでは混乱も起こるかもしれません。

以上、やり方考えてみましたが、どれにしようかなあ( ̄□  ̄ ) 個人的には1か3を考えてますが、みなさん希望とかありますでしょうか( ̄∇  ̄ )

Tags:   , , , ,
Categories:   .NET | Java
Actions:   Permalink | Comments (58) | Comment RSSRSS comment feed

Pebble2.1 リリース

Sunday, 20 May 2007 06:31 by sabro

 ごきげんうるわしゅう。NY 滞在が、6月半ばまで延長が決まって、げんなりの sabro です。

さて、いつのまにか、Pebble2.1 が、リリースされていたようです。こちらでは、試す環境がないので、開発者ブログを読んで調べたもののうち、気になる変更点をいくつかあげておきます。

  • 複数ファイル同時アップロード対応
  • Ajax への対応強化
  • about プロパティ(多分、自己紹介ページのようなもの?)追加
  • サイドバーにフィードリーダー機能を追加

主に見栄えに関わる変更点を挙げましたが、他にも、管理者向けの小さな機能向上が多い印象を受けました。

私は、デザインも変えたばかりであるし、今回は移行を見送ろうかと考えていますが、試した人がいたら、感想を教えてくださると助かります (^^)

Tags:   ,
Categories:   Tool
Actions:   Permalink | Comments (2) | Comment RSSRSS comment feed

自分が一番いいものを作れると主張する傲慢なフレームワーク

Sunday, 20 May 2007 05:27 by sabro

今、担当している Java Swing 案件のフレームワークは、ある意味すごい。○○Frame や、○○Button (○○は会社名略称)のように、Swing の全てのコンポーネントを、ラップしている。また、Swing にとどまらず、○○List や ○○Map 等の、コレクションフレームワークラッパーまである。ありとあらゆる標準 API をラップしているのだ。

ただ、自分は、以下の理由で、このフレームワークはダメだと感じる。

  1. 学習のコスト
  2. 費用対効果

ラッパーの作成は、継承または委譲で実装されているが、委譲に関しては面倒だったのか、全てのメソッド、フィールドが委譲されてないケースがあった。これでは、Java 標準 API に精通した熟練者であろうと、このフレームワークを使用する場合には、新たな学習をする必要がある。さらに、学習をしても、企業や部署が変わると、使用できないので、モチベーションが上がりにくい。

また、このフレームワークは、かなり多くのクラスをラップしているので、フレームワーク自体の開発コストは、そうとうなものだったと思われる。しかし、それだけの苦労に相当する効果が出ているかというと、とても、そうは感じられない。膨大なクラスのフレームワークは、学習するだけで膨大なコストがかかり、初めて使用した際は、工数が膨れ上がる。では、2回目以降の開発では、楽が出来るのかというと、JDKのバージョンも、そろそろ上げないといけないし、これからの案件では、このフレームワークは使われないという。

Effective Java 等の書籍を読めば分かるように、標準 APIというのは、非常に洗練されている。Jakarta Commons のように、大規模な開発を行い、さらにオープンにして、あらゆる企業で使用可能とするならともかく、一介の技術者が、その全てを改良してやろうと考えるのは、傲慢ではないだろうか。

一般開発者にとって優しいフレームワークとは、独自の作りこみを減らし、標準 API を積極的に利用して作成されたものなのだろう。フレームワーク開発者は、フレームワークを作って、一般開発者をそれに従わせるより、標準 API を利用してもらうための、Java レクチャードキュメントを用意するべきだ。

フレームワークという言葉には、ある種、華があるが、フレームワーク開発者という立場から一歩視点を広げ、ソフトウェア基盤技術者として、一般開発者の作業を楽にする方法を真摯に考えていくことが重要なのではないだろうか。

Tags:  
Categories:   Architecture
Actions:   Permalink | Comments (42) | Comment RSSRSS comment feed