Math Self ... （こだわりDIY職人）

AI アプリ - CreateMLだけで作ってみた

Fri, 21 Feb 2020 13:52:58 +0900

ビッグデータが流行ですが、”スモールデータ” ではだめなんだろうか？　Xcodeの Playgroundには AIモデルを生成する機能を備えている、これを使って実際にアプリを作成してみた。

学習システムには、Apple社が学習させた基本モデルが組み込まれているから、それを使って転移学習する仕組みらしい。ディープラーニングに解説されている、犬猫の画像分類なども、フォルダー別に各々画像を用意するだけで、手元の Macだけで簡単に AIモデルを生成することができ、生成したオリジナルモデルを自分のアプリに組み込むことができる仕組みだから Macが有れば容易に試すことができる。

作成したのは、AI がベストショットを自動で撮ってくれるアプリ

写真を撮るとき、誰しもがベストな一枚を願うものだ。これを AI化するための以下の方針を決めた。

・ベストショット = 素敵な顔の表情とする

・学習データ = 素敵な顔と、そうでないのを各20枚程度用意する (*)

・写真の判断に客観性はない

(*) 学習データ

2019.1.1 施行の改正著作権法によると、著作物を含むデータを元に機械学習によって学習済みモデルを開発することは適法となった、だから Web上の写真データを使って AIモデルを開発することは可能である。

このように、用意したのはビッグデータとは程遠い学習素材です。実際に学習させてモデルを生成してみると面白い。枚数の少ない画像を有効活用するための手段として CreateMLにも画像の回転、反転、拡大、切り取り、などの学習時のオプション設定ができるが、あれこれ試して分類精度を上げすぎるより、ここでは適当に低い方がいい結果が得られた。

（学習とテストの精度 - CreateML - ）

実際、色々試してみたが、90%以上の高精度より 60〜70%程度の方が良い結果が得られたが、この結果の確証はない。使った学習データのせい、あるいは考え方が間違っていたのかもしれない。元々、目標にした "ベストな写真” に客観性はない。App Storeからダウンロードして試して判断ください。

（iOS 12.0以降。iPhone、iPad、およびiPod touchで動作。）

App Store（無料、課金・広告なし）

電解コンデンサ１つでよみがえった 1Uサーバ

Wed, 26 Dec 2012 16:54:47 +0900

停電で起動しなくなった1Uサーバー

写真の 1Uサーバ（開発用途の公開サーバとして使用）は、2006年12月・大雪の朝の停電で停止した際に起動しなくなったが、下記の方法で応急的に修理したままになっている。先日メンティナンスの際に写真を撮る機会があったのでここで簡単に紹介する。このような修理方法もあるのだと知って頂ければ幸いである。ちなみに修理後はトラブルもなく正常に動作しているが、現在は新しい予備機を電源オフ状態で待機させている。

余談であるが、サーバに限らずメンテナンスなど連続運転していた物を止めると再起動しないことは少なくない。サーバの場合は止めた時にミラーデスクの一方が故障してしまうことや、電源部とかマザーボードがダメになっていることも多い。古い機種だとマザーボードに電解コンデンサが使用されていて、容量抜けなどが原因の場合も少なくない。運が良ければ、スイッチオンを繰り返すと起動する場合もある。

電解コンデンサは簡単には取り外せない

クローズアップ写真のように数個の電界コンデンサーの頭の部分がふくらんでいる（全部 +5V系）。容量抜けだろうから、これを交換すれば良いのだが、多層基板に取り付けられた部品は簡単には取り外せないし、きちんとした道具立てでないと基板を壊すはめになる。

無理に外さなくてもいい場合もある

コンデンサーが内部でショートしている場合はこの手は使えない。そうでなければ見てくれは悪いがこれで十分である。面倒だから4個分の合計より大きめの、10,000μF 1個で代用しておいた。電解コンデンサは高周波を扱うものではないから配線の引き回しは気にしなくてもよい。

（絶縁チューブに通して並列にハンダ付づけして取り付けただけ）

フォーカス位置の可変できる写真

Sun, 16 Dec 2012 12:12:31 +0900

ふつうのデジカメでフォーカス位置が変更できる写真を作ってみました。

写真のクリックした位置にピントが合います。但し、スマートフォン（iPhone, Androidで確認済み）だと QuickTimeムービーが表示されてしまうから、これはパソコン専用です。

使用ツール: DOF-Changeable Photos with an SLR

PickerVew によるメニュー選択 (3/3)解決篇

Mon, 12 Nov 2012 18:07:52 +0900

解決策はロジックを飛び越えて訪れるものらしい・・・？
もう面倒になって、タイマーのあら捜しをあきらめかけていた。そんな時ふとスレッドのことが気になりだした。UIPickerView も名前どうり UIだからメインスレッドで表示しているからである。そこに横槍を入れるならサブスレッドしかないだろう。早速やってみた。
最初 (1)不思議篇で示したピッカーの停止した時に呼ばれるデリゲードメソッドの次の行に移動させる部分 (太字) だけをサブスレッドで実行するのだ。


.....
.....
if (nowIndex_ == 0) {
    // 次の行に移動させる
    nowIndex_++;
    [picker_ selectRow:nowIndex_ inComponent:component
        animated:YES];
}

これで決まり！
きちんと書くとこんな感じ・・・


// 停止時のデリゲート
- (void) pickerView:(UIPickerView*)pickerView didSelectRow:(NSInteger)row
 inComponent:(NSInteger)component
{
    // 位置をキープするインスタンス変数
    nowIndex_ = row;
    // ドラムの表示 0の位置を index=0 と想定
    if (nowIndex_ == 0) {
        // 次の行に移動させる
        nowIndex_++;
        [self adjustPickerPosition:nowIndex_]; // 移動メソッドを呼ぶ
    }
}

// ドラムの移動メソッド
- (void)adjustPickerPosition:(NSInteger)row 
{
    NSLog(@"adjusted!");
    // サブスレッド
    NSOperationQueue *queue = [[[NSOperationQueue alloc]init] autorelease];
    [queue addOperationWithBlock:^{
        // 行の表示位置をデーターに合わせる
        [picker_ selectRow:row inComponent:0 animated:YES];
    }];
}

NSOperationQueueクラスを使用しているが、iOS 4以降は内部でGCDを使用しているため結果的には同じである (参照:「詳解 iOS 5プログラミング」) 。これでやっと決定打となった。

簡単に検証してみる
さて、せっかくだから逆方向に検証してみよう。手順は、この NSOperationQueueクラスの mainQueueメソッドで取得したキューを使って、このサブスレッドの中からメインのスレッドで実行してみたらどうなるか？これで最初の時と同じように上手く行かなくなれば理屈は成り立つ。


    .....
    .....
    // サブスレッド
    NSOperationQueue *queue = [[[NSOperationQueue alloc]init] autorelease];
    [queue addOperationWithBlock:^{
        // メインスレッドで実行
        NSOperationQueue *mainQueue = [NSOperationQueue mainQueue];
        [mainQueue addOperationWithBlock:^{
            // 行の表示位置をデーターに合わせる
            [picker_ selectRow:row inComponent:0 animated:YES];
        }];
    }];
    .....

さて、これは予想どうりに失敗する。これでメインスレッド同士の競合が原因であることの検証もできたが、ここから先の解析は力不足であるし追求しないことにする。

(おわり)

PickerVew によるメニュー選択 (2/3)試行錯誤篇

Sun, 11 Nov 2012 18:50:22 +0900

興味のない方は、ここはスルーして次の (3/3)解決篇へ移ってほしい。

マルチタッチイベントの競合の影響を疑ってみる
ピッカー本来の動作と、想定していなかったタップ動作が競合している可能性を疑ってみたくなった。そこで、ピッカーに Gesture Recongnizer のタップジェスチャーを登録し、さらに複数のジェスチャーを認識できるような設定をしておく。この状態でデレゲートメソッドが呼び出された時にドラムの位置をチェックするようにしてみた。


// タップジェスチャーをピッカーに登録 (viewDidLoadに設定)
picker_.userInteractionEnabled = YES;
UITapGestureRecognizer *tapGesture =[[UITapGestureRecognizer alloc]
    initWithTarget:self action:@selector(pickerTap:)];
[picker_ addGestureRecognizer:tapGesture];
[tapGesture release];

// 複数のジェスチャーの認識を許可
// (UIGestureRecognizerDelegateプロトコルのオプションメソッド)
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
    shouldRecognizeSimultaneouslyWithGestureRecognizer:
    (UIGestureRecognizer *)otherGestureRecognizer
{
    return YES; //許可
}

// デレゲートメソッド
- (void)pickerTap:(UITapGestureRecognizer *)sender {
    // indexを取得
    NSUInteger index = [picker_ selectedRowInComponent:0];
    NSLog(@"タップ！ index : %d", index);    
    if (!index) index++;
        // ピッカーを進める
        [picker_ selectRow:index inComponent:0 animated:YES];
        nowIndex_ = index;
}

これで確認してみると、少しは改善されたような気もするが残念ながら決定打にはなり得ない。

ダメついでに少し荒っぽいことを試してみたくなった・・・
ふりだしに戻して、今度は逆に他の Gesture Recongnizer のタッチ解析を禁止してみたらどう反応するかやってみた。他にもっと気の利いた方法もあると思うが、以下の UIGestureRecognizer のサブクラスを作成した。


// *** MyFlagGesture.h ***
#import 
#import 
@interface MyFlagGesture : UIGestureRecognizer
@end

// *** MyFlagGesture.m ***
#import "MyFlagGesture.h"
@implementation MyFlagGesture

// ジェスチャーの開始
- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesBegan:touches withEvent:event];
}
- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesMoved:touches withEvent:event];
}
// ジェスチャーの終了
- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event
{    
    [super touchesEnded:touches withEvent:event];
    NSLog(@"GestureEnded!");
    // Recognized をセットすると親クラスにメッセージを送信する
    self.state = UIGestureRecognizerStateRecognized;
}
- (void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event
{
    [super touchesCancelled:touches withEvent:event];
}
- (void)reset
{
    [super reset];
}

// 他のジェスチャーの検出を禁止させる (オプションメソッド)
//  (Possible から遷移しようとする時に呼び出される)
- (BOOL)canPreventGestureRecognizer:
    (UIGestureRecognizer *)preventedGestureRecognizer
{
     return NO; // 禁止する (ディフォルトは禁止しない:YES)
}
// 他のジェスチャーの検出を禁止させる (オプションメソッド)
// (touchesBegan: を呼び出す直前に呼び出される)
- (BOOL)canBePreventedByGestureRecognizer:
    (UIGestureRecognizer *)preventingGestureRecognizer
{
    return NO;  // 禁止する (ディフォルトは禁止しない:YES)
}
@end

このクラスをインスタンス化してピッカーに登録してメッセージを受信できるようにする。


// MyFlagGesture のインスタンスを登録 (viewDidLoadに設定)
picker_.userInteractionEnabled = YES;
MyFlagGesture *gesture = [[MyFlagGesture alloc] initWithTarget:self
    action:@selector(pickerGestureFlag:)];
[picker_ addGestureRecognizer:gesture];
[gesture release];

// サブクラスからのジェスチャー完了メッセージを受け取る
- (void)pickerGestureFlag:(UIGestureRecognizer*)sender
{
    NSLog(@"MyFlagGesture Ended! (state = %d)",sender.state);
    // indexを取得
    NSUInteger index = [picker_ selectedRowInComponent:0];
    NSLog(@"タップ！ index : %d", index);    
    if (!index) index++;
        // ピッカーを進める
        [picker_ selectRow:index inComponent:0 animated:YES];
        nowIndex_ = index;
    }
}

ロジック的には、サブクラスのジェスチャーの終了時に呼び出されるメソッドは、ピッカーのドラムを回転して操作が終了してしまうともう呼び出されない。だから後は想定外のタップ動作だけに反応してくれるから上手く行く筈であるが残念ながらそうはならないところが悩ましい。
以上のいずれも問題の解決策にはならなかった。もうお手上げであろうか、もしこれで上手く行ったとしても少々複雑すぎるのも気になるが．．．。

（以下、(3/3)解決篇へ）

UIPickerVew によるメニュー選択 (1/3)不思議篇

Sat, 10 Nov 2012 12:11:22 +0900

これでも、60秒タイマーとして動作する（左側）
不思議に思って、試作プロジェクトを作成してピッカーを組み込んでいろいろと実験してみた（写真右側）。プログラミングやデバッグの参考になれば幸いである。

タイマーの設定方法
分の数値 0がグレーにしてあるように、この位置で停止することは想定されていないし、普通に操作している限りまずはこのようにはならない。しかし、1 --> 0 方向にゆっくり戻しながら、素早くタップを繰り返し 0の位置でそっと指を離すと再現できる。最初は難しいが、慣れるとすぐにできるようになるから興味のある方は実際に試しててもらいたい (なお、逆方向 59 --> 0 に移動しながらはできない) 。

勝手にロジックを推測してみる
ドラムを回転して 0の位置で指を離した場合はつぎの行に強制的に移動させる。この辺は基本的にはだれが考えても同じのはず。


// 停止時のデリゲート
- (void) pickerView:(UIPickerView*)pickerView didSelectRow:(NSInteger)row
 inComponent:(NSInteger)component
{
    nowIndex_ = row;   
    // ドラムの表示 0の位置を index=0 と想定
    if (nowIndex_ == 0) {
        // 次の行に移動させる
        nowIndex_++;
        [picker_ selectRow:nowIndex_ inComponent:component animated:YES];
    }
}

これで、実際に試してみると意図した動作をすることがわかる。タイマーと同様にエンドレスのドラムを実現しないと逆方向は確かめられないないが、これだけでも解決すべき問題点の再現には十分だろう。

さらに推測をふくらます
この状態でタイマーをスタートしてから、キャンセルして戻ってくると 0 --> 1になっている。あるいはこの状態でアプリを終了してから再起動しても 0 --> 1に設定されている。多分タイマーを起動した時や、プログラムがバッググラウンドに遷移する際に呼ばれるデリゲードなどに、下記のようなコードが追加されているのだろう。


// 試作の場合は inComponent:0
[picker_ selectRow:nowIndex_ inComponent:1 animateed:NO]

これでも実用上は問題ないが問題点は未解決のままである。

（以下、 (2/3) 試行錯誤篇、(3/3)解決篇へ）

これでもOK！ miniDVテープの修理

Fri, 14 Sep 2012 11:29:42 +0900

分解した miniDVテープ

現役を引退してしまった miniDVですが、撮りだめたテープの中に貴重なコンテンツが保存されていることも多いのではないでしょうか。この際パソコンに移してDVDに焼いておいた方がいいですね。

私は、手持ちのビクターのハンディカム（Victor GR-DV1）からパソコンにキャプチャーする途中でエラー（E03）が発生。急いで止めて、テープを取り出したが残念ながらテープ絡んではみ出してしまった。あきらめの境地で、ググってみると修理は２千円以上は取れれるらしい。いつものDIY精神で分解してテープはすぐに整えたが、組み立てる段階になって、２時間余り奮闘したものの３個の部品がどうしても元に収まらない。

深夜近く、もう諦めの境地で思い切って部品を余らせたまま外見上は元どうりに組み立ててみた。組み立てみて改めてこれらの小さな３つの部品の役割に気づいた。


　1. 録画プロテクトのON/OFF（スライドノブ）
　2. ゴミの侵入を防ぐ（プラスチックの片）
　3. テープの前蓋を閉じる（バネ）

どうやら、丁寧に扱えばキャプチャーするだけなら無くても良さそうな物ばかりだ。思い切って、この状態でハンディカムに入れるとローディングも正常、再生も問題なく動作する。まずはメデタシとなった。

余った？３つの部品

さて、このままキャプチャー続行してもよいが身内に連絡したら、SONYのハンディカムを現存しているとのこと。またエラーは困るから、これを送ってもらうことにした。キャプチャーはお預けとなった。

（参考）分解したテープはSONY製で細いプラス・ドライバーだけでケースは簡単に分解できる。しかし、手持ちのPanasonicのテープは、ネジ類が全く見当たらないので簡単には分解できないらしい。

UI 操作と競合しないスレッドによるタイマー表示

Sat, 21 Jul 2012 11:22:04 +0900

画面にUIPickerと、NSTimerを使ったタイマーを配置した場合、カウント中にピッカーを回転させるとその間カウンターの表示が停止する。これは、NSTimer、UIViewの表示がともにメインスレッドで動作するからです。
これを回避するには、タイマーのカウント部分を別のスレッドにすることですが、カウンターの更新部分はUI にアクセスすることになる（ ...メインスレッドに用意したメソッドを呼び出す）あまりすっきりしない。iOS 4 から導入されたGCDならメインのUI にアクセスできるから扱いやすい。これを直接利用してもよいが、NSOperationQue もGCDが使われるようになっているからこれを使ってテストしてみたが、動作は快適である。

// タイマーの更新（テストコード）
- (void) countUpdate
{
　NSOperationQueue *queue = [[[NSOperationQueue alloc]init] autorelease];
　[queue addOperationWithBlock:^{

　　while (1) {
　　　NSOperationQueue *mainQueue = [NSOperationQueue mainQueue];
　　　[mainQueue addOperationWithBlock:^{
　　　　// カウントアップ
　　　　count_++;
　　　　// 再生時間を更新
　　　　countLabel_.text = [NSString stringWithFormat:@"%d", count_];
　　　}];
　　　[NSThread sleepForTimeInterval:1.0f];
　　}
　}];
}

参考：
　詳解 iOS 5 プログラミング

CALayerを使わない、UIViewアニメの停止/再開

Fri, 20 Jul 2012 10:25:44 +0900

UIViewのアニメーションはサンプル例も多く作りやすいが、アニメーションの停止、再開をコントロールしたい場合、CALayerを扱ううことになって面倒になるようである。
目的にもよるが、例えばボタン等のUI部品の点滅アニメーションの場合は、CALayerを扱わなくても容易に実現できた。

// 点滅アニメーション
-(void) flashAnimation:(BOOL)start
{
　[UIView beginAnimations:nil context:NULL];
　[UIView setAnimationDuration:0.3f];
　[UIView setAnimationCurve:UIViewAnimationCurveLinear];

　if (start) {
　　// -点滅開始-
　　[UIView setAnimationDuration:0.8f];
　　[UIView setAnimationRepeatCount:1000];
　　[UIView setAnimationRepeatAutoreverses:YES];
　　[button_ setAlpha:0.5f];
　} else {
　　// -点滅停止-
　　[UIView setAnimationBeginsFromCurrentState:YES];
　　[UIView setAnimationRepeatCount:1];
　　[button_ setAlpha:1.0f];
　}
　[UIView commitAnimations];
}

参考サイト：
http://stackoverflow.com/questions/6893181/how-to-flash-a-button-on-ui-thread

Xcode4.x で 1st. iPod touchをテストする

Thu, 19 Jul 2012 12:10:03 +0900

MPVolumeViewは、シミュレーターで表示されないので実機での確認が必須となる。iOS 5.1.1 の iPhone 4S, iPod touch (4th）とも問題なかったが、手持ちの初代 iPod touch (iOS 3.1.3) での動作確認にに手間取ったのでメモを残す。（開発環境は、Xcode 4.3.3）

1. まず Xcode 4.x を iOS 3.x に対応させるのに下記のサイトが参考になった。
http://akamatsu.org/aka/2012/03/26/ios-3-1-3-compatible/

2. アプリを実機に転送してもUIVew が正しく表示されない（viewDidLoadがコールされない）、この対応には下記のサイトが参考になった。
http://homepage2.nifty.com/GREIF/xc_column.html

3. 最後にミスったのは、No Volume Available が表示されるのみで、肝心なボリュウームのスライダーが出てこない。これに関しては、このサイトに突き当たるまで気づかなかった。言われてみれば当然です、焦った、、！
http://www.mail-archive.com/cocoa-dev@lists.apple.com/msg41546.html

1U 自宅サーバー（追伸その2）

Sun, 08 Jul 2012 20:56:23 +0900

監視用の温度計の追加

　自宅サーバー運用開始からまる3年が経過しましたが、この間ミラーリングのHDを一回交換したのみでトラブルもなく連続運転しています。先日、秋葉原に立ち寄って際に同じ温度計を入手し、吸入、排気部に個別にセンサー部を配置して同時に監視できるようになりました。

今年も早くから真夏日が続いていますが、サーバー君も毎日頑張ってくれています。

1U 自宅サーバー（追伸その1）

Wed, 30 Dec 2009 16:21:09 +0900

自宅サーバーの紹介から半年が経過しました。サーバー君は猛暑も無事乗り切ってノントップで運用中です。いよいよ、2009年も終わろうとしていますが、真夏の温度データなどを追伸として紹介します。

最も心配した夏場の温度上昇

　元々一番の心配事は空調の無い環境での夏の温暖化対策でした。前稿のように、縁の下からの自然の冷気を頼りに騒音対策の関係もあって小さなスペースに収納したこと、さらに収納エリアの排気も十分でないことでした。当地は全国的にも猛暑日が比較的長い地域ですが、幸い今年は比較的少なかったものの、それでも図に示したようにサーバー君にとっては大変な日々だったことが想像できます。データにある期間以外も同じような日々が約２ヶ月以上に渡って続いていました。

使用した温度計

　温度の計測に使用した温度計は、秋葉原で２千円少々で求めた、商品名「デジタル表面温度センサモジュール」というもので、サーミスタ部分と本体が約３メートルの細い線で分離されたタイプを使用しました。

　写真のように、センサー部分を目的の位置にビニールテープで仮止めておき、本体はサーバー室の蓋の隙間から引出して外にぶら下げて置くことで何時でも簡単に見ることができます。本来は、温度計を２つ用意して常時２箇所が見れると便利ですが、趣味の自宅サーバーですから今回は同日に一つのセンサーをサーバーの前面と後面の排気口を何回か移しかえては測定しました。サーバー室内の温度は30分もすれば定常化しますから、労をおしまなければ十分です。

計測データについて

　正確な日付や時間は、繁雑になるためグラフの目盛りから省略してあります。気象台発表の気温は35度程度の環境での概要データとして参考程度に見てください。グラフから現サーバーの内部の温度上昇分は約９度であることがわかりますが、多分これは季節によって大きく違わないはずですから、サーバーの監視のデータの目安として利用できるかもしれません。

1U 自宅サーバー（4/4）

Wed, 29 Jul 2009 10:56:25 +0900

前回は、階段下の 1U 自宅サーバーのエアーフローについて縁の下からの吸気口や階段のファンの位置関係などを図解で紹介しました。最終回は数点の写真を交えて自宅サーバーの締めくくりとします。

写真

（左より : 空気の吸入口、ケーブルの引込み、サーバー置場の蓋）

空気の吸入口

　サーバー前面の下から上を向いている円錐形をした物体は、洗濯機の排水用フォースの取り付け口の部分です。塩化ビニール材で弾力性があって、この中にフィルターの材料を押し込んでいますが扱いやすいし、一番の見つけものだと思っています。排水フォースその物は直径は一定（ 4cm弱）ですから、この部分は洗濯層の底部の取り付け導入部分の径に合わせて、適当にカットできるように作られている部分です。

　径の小さい床との取り付け部分は、これもホームセンターで見つけたちょっとした部品です。それほど広くない間隔で押入れの中などにハンガーの棒を取り付けるような用途に使う両端金具です。3箇所にネジ止めができ、通過穴の径が塩ビの小さい方とピッタリ合っていたため使用しましたが、縁の下からネズミ？　が入ってこないように薄手の金網を挟んで床にネジ止めしました。

　なにぶんにも、夏場はサーバーにとって救いの冷気取り入れ口ですから、中間の空いている部分にもう一つ追加した方が良いかもしれません。縁の下からファンで吸入していませんが、サーバーの前面から吸い込むエアーフローにお任せです。

ケーブルの引き込み

　階段下に都合よくケーブルの配管はないし、となりのリビングから直接引き込むのはこれも気がひけるものです。当初からの悩みの一つでしたが、思いつきでやってみたところ上手い具合にいきました。どの状況下でも都合よく行くとは思えませんが、こんな手法も有るという例として紹介しておきます。

　まずサーバー置き場の引き込み口の穴を先にあけておきます、次にリビングの壁の照明用のスイッチ部分をそっくり前へ引出したままにしておき、その後ろの空間（内部とリビング側の 20センチ足らずの板の隙間）から先に開けた引き込み口の穴の方を目がけて、細いメッセンジャー（適当なものがないので被覆付きのステンレスワイヤーを使用）を押し込んでいって探り当てるのです。

　十分な長さを入れ込んだところで中に回って、懐中電灯でワイヤーが付近へ着ていないか確認するのですが、簡単には成功しません。途中であきらめなければ 3メートル程度の距離ならメッセンジャーは通過できるはずです。...まさに運ですね。

　LANケーブルの苦労と比べると、手前の電源コンセントは、ちょうどリビング側と背中合わせの位置にしましたから簡単です。

サーバー置き場の蓋

　この写真の角度では見えにくいのですが、このような半固定式の蓋で通常は密封してして、これも騒音対策の一つなっています。　取り付け構造は目的が音の遮断だけですからかなり手抜き工作をしています。上下だけは簡単な溝を設けていますが、左右は少し大きめにしておいてグーと押し込む感じです。

　最初にも少しふれましたが、中に高価なフエルト布などを張っているより、蓋、扉、戸、などの効果は絶大です。空間に余裕があれば、例えば数センチの隙間を設けて階段に沿って天井を二重にしてみたり、内部の左右も同じように少し隙間を設けてさらに板で密封するように囲えば、耳をかざしても物音一つしなくなると思います。しかし、現状でも知っていて深夜にそっと耳をすませば判る程度の仕上がりです。何も知らされていなければおそらく気づかないはずです。ただ階段室だけは別です、誰にでもすぐにわかります。

「1U 自宅サーバー」と題して 4回にわたって紹介しました。最も心配な温暖化も、今のところ屋外では 30度以上（先日は最高34度を記録）の夏日が続いたりしていますが、階段の排気ファンのところに取り付けた温度計は最大で28度位におさまっています。サーバー置き場の密閉用の蓋の表の面にももう一つ温度計が付けてあります。
　家族の安心のため階段の換気用のファンの真上の付近には火災報知器も取り付けてあります。

1U 自宅サーバー（3/4）

Sat, 25 Jul 2009 19:35:13 +0900

前回は、1U 自宅サーバーの設置場所として、どこの宅でも利用価値の比較的少ないと思われる、階段下の低い部分という手段もあることを知っていただくため、写真等をまじえて紹介しました。

サーバー置き場の換気

　設置場所の容積は、約 0.5立方メートル、ミドルタワー型ケースの約10倍もありこの空間の換気に 12センチのファンが適当であるとは思えないが、それなりの効果はあるであろうと勝手に思っているだけです。

　当初は、ホームセンターで見かけたパイプファン（直径 10センチのトイレの換気扇？）も検討してみたが、このファン自体の騒音がうるさいので取り止めた。結論として、1Uの後方から噴出される風量はかなりな量であるから、とてもバランスがとれているとは思えないし、いずれにしてもいい加減である。なお、ファンはソニーが開発したという流体動圧軸受を採用した 1800rpm/12V 静音タイプである。スイッチで電圧切替が可能な電源アダプターを使用して夏場は 9V、その他は 6V で駆動するつもりでこのようにしている。

エアーフロー

　空気の吸入口に関しは良いアイディアが浮かばないなま、4月の中旬に DIY工事だけはスタートした。階段室の横は、リビングで夏場はエアコンが入っている時間も長いからここから吸入することも考えてみたが、当然ながら騒音がリビングへ逆流してくるし DIY工事も簡単ではない。あれこれと思い巡らしながら、作業中にふと気づいたのは縁の下の空気がひんやりしていることである。

　この辺は乾燥地であると、かつて近所の方に聞いたこともある。結論として、通気・換気は図のような構造となった。このまま夏場が乗り切れればまずは、めでたしメデタシです。

以上、今回は 1U自宅サーバーのエアーフローの一例として簡単な図で紹介しました。次回はもう少し細部の写真を用意し、具体的に見てもらう予定です。

1U 自宅サーバー（2/4）

Tue, 23 Jun 2009 10:30:18 +0900

すこし間が空いてしまいましたが、1U自宅サーバーの続編です。30度を超える夏日が続いていますが、クーラーなしの環境でファンのみでサーバー君も頑張っています。

設置場所

　自宅の何処に設置するか？　前からいくつかの候補の一つとして考えていた、階段下の最も低い部分 6段分を拝借することにしました。下の踊り場から数段目位までは、何処のお宅でも収納場所として利用価値が低いため家族からの反対も少ないのではないでしょうか。しかし、肝心なのは騒音です、家族のストレスの原因になったりしては大変です。騒音、特に 1Uサーバーの場合は空冷ファンの風を切る音が半端ではなく、どんな結果になるか検討もつきません。で、結果的には知らせなければ来客の誰も気づきませんし、階段上の部屋は寝室ですが深夜でも気になったことは一度もありません ...まずまずは成功です。

設置の様子（写真）

　階段の4段目に取り付けたパソコンケース用（12ｃｍ）換気ファンと、階段下に設置したサーバーの様子。階下のサーバー室は、普段は前面には半固定式の蓋を取り付けて密閉されており、これは、ほこり対策と騒音には抜群の効果を発揮してます。内部一面に張ったフエルト布は騒音には予想したほどの効果はありませんでした。写真の 1U サーバー2台の内、常時運転しているのは1台のみです。

以上、今回は設置場所の紹介のみです。次回はサーバー君の温暖化対策などを紹介します。