Free Style

もしかして前も似たようなこと書いてるかもしれないけどリマインドというか再整理ってことで。

個人運営ってことで有る程度は容赦してくれると非常に嬉しいところです。
かといって、一応ユーザーの要望は考慮しているつもりなんで、なんらかの
形でフィードバックできればいいなぁとか。
無論100%要望に応えられるとは限らないってことは了承していただけると非常に
助かるところです。

・ソーシャルブックマーク機能
外部連携ということでなんとかなるかなぁとか。

・HTMLタグ機能
次期アップデートで実装予定。

・ファイルアップロード機能
これも機能制限つきってこと導入予定。

・携帯絵文字対応
導入予定。

・SNS外への日記の公開機能いる
SNSの日記データに関しては、公開は見送り。
但し、blogデータに関しては外部に公開（早い話宣伝補助）できるようにする予定。

管理人ってどういうやつよっていうか得手不得手的なものがあるので、
コレ見て有る程度勘弁して欲しいなぁという言い訳的なエントリー。

何かしらサービスに必要だと思われる要素と自称スペック。

・企画力
★★☆☆☆

・運用力
★★☆☆☆

・設計力
★★★☆☆

・開発力
★★★★☆

・時間
★☆☆☆☆

・デザイン
★☆☆☆☆

うん、スペック不足…

ということで人材を募集してま（ｒｙ

最近もうBEMANI関係特化というかむしろそっちが（ｒｙ

まぁモチベーション低下とうか、成果物に対するレスポンスがあると
アップなんだろうなぁ（という期待

最近の主流というか開発ポリシーはデータマイニングしつつ、弱小サイトなので
PRにサーチエンジンと仲良くしていければいいなぁという方針。
で、そのデータ元は流行（？）のWebAPIでなんとかしちゃえ的な発想。

サービス的に二番煎じだろうが、システムはフルスクラッチでがんばっちゃえば、
まぁ技術的にも何か新しい発見がいいなぁというポジティブシンキングで。

十人十色って言うぐらいに人のニーズをくみ取るのが一番難しいですな。
そんな私のトレンドはネットショッピング。ひたすら買い物大好き。
コストパフォーマンスが良い物は大好きなのだが、コストとパフォーマンス
どっち重視するかっていうと、やっぱりパフォーマンス不足ってのが一番後悔
するので、ついつい…というのが玉に瑕。

と、脱線しちゃったけど…

■以下使えそうなWebAPIまとめ。

・全国の路線と駅名「鉄道路線一覧など」
http://www.mashupedia.jp/webapis/view/276228

・WikipediaとMeCabから解析「キーワード抽出API」
http://www.mashupedia.jp/webapis/view/196827

・緯度経度から調べる「Weather API」
http://www.mashupedia.jp/webapis/view/148193

・パソコンや家電の価格を比較「coneco.net Web Services」
http://www.mashupedia.jp/webapis/view/26830

・地球温暖化防止「バスでお出かけAPI」
http://www.mashupedia.jp/webapis/view/20974

・タグクラウドを自動生成「ZoomClouds API」
http://www.mashupedia.jp/webapis/view/10572

・高いカスタマイズ性「マピオンAPI 」
http://www.mashupedia.jp/webapis/view/8712

・コンビニがあれば「ネットプリント・サービス連携インターフェイス
http://www.mashupedia.jp/webapis/view/2451

・ローマ字変換「SumibiWebAPI」
http://www.mashupedia.jp/webapis/view/2387

・住所から緯度経度へ変換「クネヒト Geocoding API 」
http://www.mashupedia.jp/webapis/view/975

・連想検索エンジンで遊ぼう「reflexa Web API」
http://www.mashupedia.jp/webapis/view/196

・YouTube API
http://www.mashupedia.jp/webapis/view/100

・SimpleAPI「最寄り駅Webサービス」
http://www.mashupedia.jp/webapis/view/33

・簡単きれい「Kagami - Web2.0風 映りこみ（反射）画像API 」
http://www.mashupedia.jp/webapis/view/239

・ブログを斜め読みする「TSUBUAN」
http://www.mashupedia.jp/webapis/view/203

・吹き出しでサムネイル「websnapr 2.0」
http://www.mashupedia.jp/webapis/view/268

・最寄駅はひとつじゃない「緯度経度駅検索API」
http://www.mashupedia.jp/webapis/view/272

・ATMや駐車場も「ドコイク？Webサービス」
http://www.mashupedia.jp/webapis/view/947

・コンビニがあれば「ネットプリント・サービス連携インターフェイス」
http://www.mashupedia.jp/webapis/view/2451

・Yahoo! 動画検索Webサービス
http://www.mashupedia.jp/webapis/view/14

・物欲がとまらなくなる「TilePlex API」
http://www.mashupedia.jp/webapis/view/293

・HTML2PDF.BIZ
http://www.mashupedia.jp/webapis/view/22

・単語を見つける「カケラの樹キーワード抽出XML-RPC API」
http://www.mashupedia.jp/webapis/view/364

チックなことをMERGEテーブル（MRG_MyISAM）を使ってやってみたので備忘録。

まず制限事項
・REPLACE構文が使用不可

ついでに圧縮テーブルの制限事項
・読み取り専用になる

構成としては

A
├A000
├A001
└A002

AはMERGEテーブルなので実データはない。
A000がアクティブテーブル、A001,A002はいわゆるアーカイブ。
なので、A001とA002は圧縮テーブルを使用してみる。

A000のデータが一定量を超えたらAXテーブルに移動して、MERGEテーブル
をリビルドするローテートの部分は手動か、別途シェルでも作成する
必要がある。

ローテートサイズは、テーブル構成やサーバ性能にもよるが、データサイズで200Mとか。

(200*1024*1024)/AVG_ROW_LENGTH=ローテートレコード数

以下AAテーブルを上記構成にした時の作業ログ。

mysql>SHOW TABLE STATUS LIKE AA \G

で、テーブル構成を調べられる。

※AAテーブルは500Mbyte、150万レコード、AVG_ROW_LENGTH:140
　分割レコード数は60万

mysql>CREATE TABLE A001 SELECT * FROM AA LIMIT 0,600000;

mysql>CREATE TABLE A002 SELECT * FROM AA LIMIT 600000,600000;

mysql>CREATE TABLE A000 SELECT * FROM AA LIMIT 1200000,600000;

myisampack -v A001
myisamchk -rq --analyze --sort-index A001.MYI
myisampack -v A002
myisamchk -rq --analyze --sort-index A002.MYI

※テーブルを圧縮した後に必ずインデックスをリビルドしておかないとエラーになる。
　参考速度：テーブルデータ:235M、インデックスデータ52Mの場合で37s,18s
　@CPU:Xeon5110*2,Memory:4G,HDD:SAS 15Krpm*2(RAID-1)

圧縮率は約50%程。

mysql>SHOW CREATE TABLE AA;

CREATE TABLE A (........) DEFAULT CHARSET=utf8
ENGINE = MERGE
UNION = (A001,A002,A000) INSERT_METHOD = LAST

※AUTO_INCREMENTは値指定無しでも自動的に最後尾に追加される

アクティブテーブルが閾値を超えた場合は、A003テーブルにローテート後、
MERGEテーブルを再構築（DROP、CREATE）する。

に機種変してました。

まず、携帯の用途
・メール、ブラウジングメイン
・通話はあまり使わない

選定基準は
・ワンセグ使わない
・カメラ綺麗だと嬉しい
・FeliCa必須（Mobile NanacoとかMobile Suicaとか）
・そろそろシャア専用な色が欲しい（フレアレッド）
・au端末値上げ怖いなぁ
・込み込みで5000円強というコスパの良さ（auポイント込み）
・W54CA（もしくはW61CA）が早くとも年明けになりそう。下手すりゃ来春…
・年割が104ヶ月なので今更他のキャリアはちょっと…
・W41CAより薄い
・赤いと3倍速な気がする

■W41CAと比較してメリット
・カメラ機能アップ

■W41CAと比較してデメリット
・若干もっさり
・メール周り劣化

ちなみに購入店は例によって楽天で。

auショップの半額近くだったので思わず飛びつく…

まぁいいことばっかってわけでもなく、auICカード対応なので最悪サブ機ってことでいいんじゃないかと。

色々調べてるとカメラ機能なかな高画質でびっくり。
癖ありまくりで使いこなせるまで時間かかりそうですが…

WINになってから、W21CA⇒W41CA⇒W53CAともうカシオに首っ丈なわけで。

EXLIMケータイってことで色々カメラ周り頑張ってみようと思うわー。

でもさっぱりカメラ関係に関しては詳しくないので教えて偉い人。
mixiあたりで調べたところ綺麗には取れるぽいのが救いだわー。

もっさりと言われてるけどW44Sのもっさり感より遙かにましなので
個人的には許容範囲内。
MSM7500チップ搭載端末は次回ということで。。。

それにしても2ヶ月たつのに5000円しか下がってないってもうちょいauショップがんばってくださいよーと思う罠。

10/18でbemani SNS一周年です。知ってた？

なんとか一年持ちました。当初はハードのスペック不足とか
で悩まされ、2回のサーバ移転をし、落ち着くまでに実に半年近く
かかったという正直苦い経験と火事場を乗り切ってたまった経験値
はプライスレス。

時間ないとかいいつつアンアンやってんじゃんとか耳が痛いので勘弁してね！

でまぁ、正直時間との戦いがきつかったりするので、予定が未定になりがち
だけどとりあえず年内の予定を立ててみるとします。

・bemani SNSリニューアル
・IIDX Score CS対応
・DM/GF Skiller対応

たぶんこんなもん。

さすがにIIDX15が出たら最優先でやります。

そして今後やりたいなーとか思っているイメージがこれ↓

別サーバだしとか考えると全然先が見えないわけなんですが、将来的にはやりたいなと。
認証部分をbemani SNSコアにして、各スコアとか…

あとはblogの方は主に、サーバ系情報でも書いていきたいなと。
いわゆるLAMP的な。
DBに関してはMySQL,PostgreSQL,Oracle辺りは押さえたい。
OSはきっとCent一択かな…4.5と5.0あたりで。

■変更点とか

・VNC
に対応

・互換性
Workstation6で作成された仮想マシンは互換性がないらしい。

・新対応
Windows Vista、RedhatES5に対応

・マルチモニタ表示機能
2台目のモニタで仮想マシンを表示

・USB 2.0デバイスをサポート
高速ストレージやiPodなどに対応

・バックグラウンド機能
バックグラウンドで仮想マシンを実行できる

個人的な使い方としては、ホストOSがWindowsの場合はWorkstation
ゲストOSがLinuxの場合はServerを使おうかなと。

ライセンス的にWorkstationだと外部に公開できないし、
ぶっちゃけServerでも割と事足りたりする。

Serverだとスナップショットが使えないが、仮想イメージごとコピっておけば
割と事足りるので問題ないし。

基本的にゲストOSはLinux系（CentとかFedoraぐらい）しか使うことないので、
Windows系を利用するって人には参考にならないかも。

DISK I/Oでボトルネックになっているケースに対する対策を考えてみる。
ということで、物理メモリを仮想ディスクとして利用できるRAMディスクの実験。

手軽に使えるmemcachedみたいなイメージで。

OSレベルでのファイルキャッシュで事足りることもあるかもしれないが、
明示的にメモリ内で処理できると幸せみたいなケースに有効かと思われる。

ハード、OS構成は下記。尚、ベンチマークツールはbonnie++を使用する。

CPU:Xeon5110*2
Memory:4G
HDD:144G*2(SAS,15krpm,RAID-1)
OS:CentOS4.4(2.6.9-42.0.10)

#wget http://www.coker.com.au/bonnie++/bonnie++-1.03a.tgz
cd bonnie++-1.03a
./configure
vi bonnie.h
------------------------------
>>#define MinTime (0.5)
<<#define MinTime (0.01)
------------------------------
make

# df -h
------------------------------------------------------------
Filesystem サイズ 使用 残り 使用% マウント位置
/dev/sda3 130G 44G 80G 36% /
/dev/sda1 122M 20M 96M 18% /boot
none 2.0G 0 2.0G 0% /dev/shm
------------------------------------------------------------

# mkdir /mnt/ram
# umount /dev/shm
# mount -t tmpfs -o size=512m tmpfs /dev/shm
# mount -t tmpfs -o size=512m /dev/shm /mnt/ram

./bonnie++ -u root -d /mnt/ram -s 500 -r 250

./bonnie++ -u root -d /tmp

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
500M 52244 99 865214 100 893525 99 55364 99 1863858 100 201366 208
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 272816 99 592291 97 320294 99 278214 100 521135 101 249569 100

read:1820M/s
write:845M/s

------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
cardinal 8G 40427 85 71808 24 23838 5 31428 58 62805 5 321.7 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 53228 97 327667 99 61305 99 55198 100 507259 99 63985 99

read:70M/s
write:61M/s

■総論
readで約26倍、writeで約14倍の速度がRAMディスクで測定された。
例えば、スレーブデータベースなどハードウェアレベルで冗長化された物に対しては、
利用できる可能性もあるかも。
後は、PEARのCache_Liteをmemcachedで行うより簡単に実装ができるような。