キー・ポイント株式会社の開発日誌

長らく更新していなかった、スタッフBlogですが、久々の更新です。

雪山大好き矢野です。

開発にあたって検証環境が必要なわけですが、ネットワーク云々担当の「トマト」君に
全てお任せ状態になっていました。。。

とういうことで、スタッフで4人1組のチームに分かれ、昨年10月末頃より「仮想サーバ構築しよう」大会が行われました。発表は先日1月7日に行われ、約2ヶ月で構築を行いました。

【大会のルール】
＊予算は1チーム10万円まで
＊部品購入は年内に完了させる
＊CPUは4コア以上
＊メモリーはDDR3の8GB以上
＊HDDは1TB以上
＊CD/DVDが読み込める
＊ケースは、スチールラックに載ること
＊電源は、電源効率80%以上
＊1から組み立てよう

【評価方法】

	項目	配分	採点方法	得点
1	外見・中身の美しさ	10%	審査委員の独断	10点満点
2	パフォーマンス	50%	パフォーマンス測定 (ランダムアクセスの速度を測定)	1位：10点 2位：7点 3位：3点 4位：1点
3	コスト	10%	コスト勝負	最安チーム10点で、他は500円毎に-1点
4	プレゼン	30%	審査委員の独断	10点満点

【サーバ構成】
＊リバースProxy1台
＊Webサーバ2台以上
＊DBサーバ1台
＊WordPressが動作すること

全くもって、パソコンを1から組み立てることは初めてだったので、
必要な部品やスペックは安田君(→自己紹介はこちらから)にお任せし、私はサーバの設定とチューニングを担当。
肝心な結果ですが。。。

1.外見、中身の美しさ
見事、4チーム共同じケースに　笑
差を付ける為にシールをお手製で作ってみましたが、あまり評価に差が着きませんでした。



2.パフォーマンス測定
チューニングをあれこれしたものの、残念ながら順位は最下位。
cacheを上手く設定したチームが1位でした。

3.コスト
すば抜けてお求め安い価格で構成したチームが1位！
500円毎に-1点の為、他のチームは見事0点に。

4.プレゼン
こちらもあまり差がでなかったのかと思いますが、コスト＆パフォーマンスの点差が
大きかった為、点数に影響がでなかったと思われます。。

サーバの設定やチューニングで苦労した点や試した点は
また改めて書きたいと思います。

こんにちは、常角です。
というか、初投稿なのではじめまして、です。

名前は、常角（つねずみ）と読みます。
ド田舎出身で、地元ではそこそこありふれた名前ですが、神戸に出てきてからは、弟たち以外に同じ苗字の人間に会ったことはないです。
加えて、大体初対面の人は「つねかどさん」と呼ぶので、毎回突っ込むのが億劫になります。（宅配の人とかに対しては、もう諦めています）

さて、記念すべき初投稿のネタなのですが・・・何にしよう。
考えてなかったので、書くことがないです。

では格好つかないので、以前仕事で使った、便利だと思ったSQL文を紹介します。
どんな事をするのかは、タイトルを見てね。
少しだけどういうことか説明すると、
DB上で、特定の値が重複しているデータが存在する場合、それを一つだけ残して、残りを削除するためには？という事です。

Delete t1
From 削除したいデータのテーブル t1
Where t1.IDなど数値系のフィールド(以下、【ID】とします) > (
Select Min(t2.ID)
From 削除したいデータのテーブル t2　（t1と同じテーブル）
Where
t1.重複の条件となるフィールドA = t2.重複の条件となるフィールドA
And (t1.重複の条件となるフィールドB = t2.重複の条件となるフィールドB
or (t1.重複の条件となるフィールドB Is Null And t2.重複の条件となるフィールドB Is Null))　・・・　※
And …
Having Count(*) > 1
)

t2のテーブルのほうで、重複したデータの一覧が取得されて、
t1のほうのWhere文の所で、そのうち1件だけを除外してくれるので、重複データの2件目以降だけを削除できます。
逆に、
Where t1.IDなど数値系のフィールド(以下、【ID】とします) > (
を
Where t1.IDなど数値系のフィールド(以下、【ID】とします) = (
に変えると、重複データを1件だけ取得してきますので、Select文などで、重複データを無視したデータの一覧を取得する時に便利です。

また、Where句で使うフィールが、Nullを許可しているフィールドの場合、「＝」だときちんと判定してくれないので※の部分のように、Is Nullをやってやらないとダメです。

IDの部分に使うフィールドは、ユニークな値を持っていて、必ず値が入力されているフィールドであれば、なんでもいいです。
そういった類の値が存在しない場合は、RowNum(ORACLE)で、番号を振ってあげればOKです。（SQLServerの場合は、Row_Number）
但し、これを使うと処理が半端なく重くなるので、1000件程度ならいいけど、1万10万になると、数十分数時間、それ以上になる可能性があるので、あまりお勧めできないです。
なので、DBテーブルを作るときには、ユニークIDを一つつけてやりましょう。
他、残す1件をどれにするのかは、最初にきちんと決めておかないと泣きをみるハメになるかもしれないので、その辺は注意しましょう。

・・・・・・

SQLって、勉強し始めた頃は何がなにやらさっぱりわからなかったんですが、理解し始めてくると、パズルみたいで面白いですよね？（僕だけ？）
複雑な抽出がうまくいった時とか、おもわず、「よっしゃ！」ってなったり。
まあ、それはSQLに限った話ではないんですけどね。

これからも、ちょくちょく書いていくことになる・・・と思いますので、その時はまたお付き合いいただけるとありがたいです。
次書くのはJavaかPHPか、あるいはAndroidか・・・あるいはそういった技術的なことから離れるのか。
まあ何かはわかりませんが。。。

こんばんは。
お久しぶり？いいえ、おとついぶりです。内田です。

今日、6月17日は、
WebFileが2003年6月17日にリリースされてから、
丸8年になる記念の日になります。

ということで。

じゃーん、ケーキでお祝いです。

昨年に引き続き、ケーキは近所の元町商店街にあるパオデロさん。おいしかったです、ぺろり。

最初はシンプルなWebFileでしたが、今ではWebFileファミリーも大いに増えて、
WebFile無料版、有料版、プレミアムサービス、ASP版、OEM版、
そして末っ子WebFile Liteが先日満1才を迎えました。

ケーキを食べながら、思い出話で盛り上がったり、
新入社員くんが「最初はこうやったんやねー」なんて話したり、
節目の日があると気が引き締まります。

みなさまに愛し愛されるサービスをご提供できるよう、
開発陣、サポート陣、がんばってまいります。

日々、便利で、使いやすい、
そして、より安全なサービスWebFileに、これからもご期待ください。

長文になりましたが、
最後に、WebFileに関わっておられる、お客様、販売店様に感謝します。
これからも、よろしくお願いいたします。