月別アーカイブ: 2015年7月

SQLServerエージェントが使用するアカウント

SQLServerエージェントを使用すると、
時間を指定して、exeファイルが実行できます。

この設定を行う際の注意することがあり、
スケジュール実行するexeが外部ファイル(例えばログファイルなど)に書き込みを行う場合や、
フォルダ内にファイルを生成する場合には、
SQLServerエージェントが対象となるファイルやフォルダに対して、
アクセス許可を有する必要が有ります。

アクセス許可の編集は、対象のファイルやフォルダのプロパティで行えますが、
その際、必要になる情報としてユーザー名が必要になります

通常のユーザーであれば、ユーザー名が分からなくても、
アクセス許可の編集画面でユーザーの検索が可能なので、問題は有りませんが、
SQLServerエージェントが使用するログオンユーザーは上記の検索では表示されません。

では、どの様にSQLServerエージェントのユーザーを確認するのかというと、
「SQLServer構成マネージャー」を使用します。

WS000000

これはSQLServer構成マネージャーを起動し、左側のペインからSQLServerのサービスを選択した画面です。
右側のペインにSQLServerが使用しているサービスが表示されています。
この最下行に「SQL Serve エージェント(MSSQLSERVER)」があり、その隣の列にログオンという列が有ります。
このログオン列に記載されている内容がサービスが使用するログオンアカウントであり、
アクセス許可で使用するユーザー名となります

WS000002

WS000003

調べたログオンアカウントをアクセス許可のユーザー検索で名前の確認をすることで、
アクセス許可にユーザーの追加が可能になります

追加後は、他のアカウント同様に権限の設定を行います。

情報処理技術者試験

2週間ほど前より、情報処理技術者試験の秋季試験の申し込みが開始されています。
私自信は、学生時代より基本情報技術者試験を過去5回受験してきていますが、恥ずかしながら、未だ合格できていません。
午前問題があと何点だけ足りなかった、午後問題があと何点足りなかったなど、そのときの試験にもよりますが、午前問題が足りずに不合格だったことが多いように思います。

合格するための勉強法として、学生時代に叩き込まれた内容

●午前は過去3年分くらいの過去問を押さえる
●午後は過去問はもちろん、問題集をといて問題に慣れる
●午後は問題ごとの時間配分を確実に守ること

このような内容を中心に勉強してきました。

午前問題もそうですが、午後問題は特に問題を解く時間を守るようにして、時間が立ってしまったら次の問題を解くようにしていました。
時間配分を守らずに行ったときは、結果が一番よくなかった気がします。

しばらく受験もしていないので、予定がなければ、今回久しぶりに受験しようかなと考えているところです。
そのためには、もちろん勉強しないといけないですが・・・。

試験日:平成27年10月18日(日)
受験料:5,100円

詳細はIPAのホームページに掲載されています。
https://www.jitec.ipa.go.jp/1_02annai/h27aki_exam.html

個人でのインターネット申し込みは、8月21日(金)の20時までとなっています。
私も受験するなら、忘れないうちに申し込みをしないといけないですね。

[C#] 開発メモ クラス検索のパフォーマンスについて

現在開発中のC#のプロジェクトで静的フィールドのメモリ内に
リストを持ち、必要に応じてメモリのリストよりクラスを検索して
返しているロジックがあります。

この検索ロジックですが、List<T>で持っており、LINQのwhere句で
検索を行っています。

もし遅いようであれば、リストをSortedListを使うなり、ListのBinarySearch
を利用することで対応しようと思っていたのですが、せっかくなので
多めのテストデータを使ってパフォーマンステストを実施してみました。

ここでデータは予めソートされていることを前提とします。

先に比較結果を記述します。

[リストへ100,000件追加]
List型(1回目):0.234秒
List型(2回目):0.234秒
List型(3回目):0.218秒
SortedList型(1回目):1.093秒
SortedList型(2回目):1.125秒
SortedList型(3回目):1.171秒

[100,000件から1件のレコードを1,000回検索]
List型(LINQのwhere句)(1回目):51.312秒
List型(LINQのwhere句)(2回目):51.171秒
List型(LINQのwhere句)(3回目):51.093秒
List型(BinarySearch)(1回目):0.015秒
List型(BinarySearch)(2回目):0.015秒
List型(BinarySearch)(3回目):0.015秒
SortedList型(1回目):0.015秒
SortedList型(2回目):0.015秒
SortedList型(3回目):0.015秒

この結果を見る限り、利用するならリストへの追加、検索の
ともに速いList型のBinarySearchがよさそうです。

ただ、ここでは1レコードを取得するテストを行いましたが
実際のプロジェクトでは範囲検索でリストを取得する処理も
行っているので、若干工夫が必要になりそうです。

ちなみにSortedList型でLINQを使って同じように検索すると
53.062秒と遅くなりました。LINQを使う場合はSortedListにしても
変わりはないようです・・・

参考までにテストの際に使用したソースを以下に記述します。

[検索するクラス]
public class Table
{
public String Key1 { get; set; }
public String Key2 { get; set; }
public String Key3 { get; set; }
public String Key4 { get; set; }
public String Key5 { get; set; }
public String Value { get; set; }
}

[比較用クラス]
public class TableCompare : IComparer<Table>
{
public int Compare(Table x, Table y)
{
if (x.Key1 != y.Key1)
{
return String.Compare(x.Key1, y.Key1);
}
if (x.Key2 != y.Key2)
{
return String.Compare(x.Key2, y.Key2);
}
if (x.Key3 != y.Key3)
{
return String.Compare(x.Key3, y.Key3);
}
if (x.Key4 != y.Key4)
{
return String.Compare(x.Key4, y.Key4);
}
return String.Compare(x.Key5, y.Key5);
}
}

リストへの追加処理

[List型]
List<Table> lstTable = new List<Table>();
for (Int32 i = 0; i < 100000; i++)
{
Table table = new Table();
table.Key1 = “1”;
table.Key2 = “2”;
table.Key3 = “3”;
table.Key4 = “4”;
table.Key5 = String.Format(“{0:00000}”, i);
table.Value = i.ToString();
lstTable.Add(table);
}

[SortedList型]
SortedList<Table, Table> slstTable = new SortedList<Table, Table>(new TableCompare());
for (Int32 i = 0; i < 100000; i++)
{
Table table = new Table();
table.Key1 = “1”;
table.Key2 = “2”;
table.Key3 = “3”;
table.Key4 = “4”;
table.Key5 = String.Format(“{0:00000}”, i);
table.Value = i.ToString();
slstTable.Add(table, table);
}

検索の比較

[List型(LINQのwhere句)]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table table = lstTable.Where(m =>
m.Key1 == “1”
&& m.Key2 == “2”
&& m.Key3 == “3”
&& m.Key4 == “4”
&& m.Key5 == String.Format(“{0:00000}”, key))
.FirstOrDefault();
}

[List型(BinarySearch)]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table tableKey = new Table();
tableKey.Key1 = “1”;
tableKey.Key2 = “2”;
tableKey.Key3 = “3”;
tableKey.Key4 = “4”;
tableKey.Key5 = String.Format(“{0:00000}”, key);

Int32 index = lstTable.BinarySearch(tableKey, new TableCompare());
Table table = lstTable[index];
}

[SortedList型]
for (Int32 i = 0; i < 1000; i++)
{
Random rm = new Random(i);
Int32 key = rm.Next(100000);

Table tableKey = new Table();
tableKey.Key1 = “1”;
tableKey.Key2 = “2”;
tableKey.Key3 = “3”;
tableKey.Key4 = “4”;
tableKey.Key5 = String.Format(“{0:00000}”, key);

Table table = slstTable[tableKey];
}

VRゴーグル「GearVR」を触ってみた

Oculus Rift を筆頭にVR(仮想現実)コンテンツ用のデバイスが一般的になりつつある。

そのデバイスのひとつである「Gear VR(Androidスマホがそのままゴーグルとして使えるデバイス)」の体験コーナーが

福岡のヨドバシカメラに設置されていたので実際に触ってみた。

image

Oulus Riftと比べて、まずは良い点。

  •  軽い
    • かなり軽い。首を大きく動かすコンテンツもあるので軽いほうが疲れにくい。
  • ケーブルレス
    • Oculusの接続ごちゃごちゃに比べてとってもスマート。首を動かすときの邪魔にもならない。
  • 画質が良い(ように感じた)
    • Oculus Riftの時に感じた、画面のドット感のようなものが気にならなかった。
  • 単体で動作可能
    • Oculus Riftのように別途PCの用意がいらない。完全に単独で動作させることが可能。

続いて、悪い点。

  • 稼働時間
    • 単体で動作する反面、バッテリーに依存することになる。
      充電しながら動作させることも出来るのかもしれないが、せっかくのケーブルレスのメリットが犠牲になる。
  • 性能の限界
    • 本体となるAndroid端末の性能に依存する。用意されていたデモ用コンテンツ程度であれば動作に問題がないが、より作りこんだコンテンツを用意する際は注意が必要。
  •  メガネをかけた人には向かないのかもしれない。
    • これはOculus Riftの時にも感じたことだが、メガネをかけている人はそのままメガネの上から装着することになり、メガネの形状によってはうまく体験できない。

やはり後発だけあって、Oculus Riftより優れている点が多く感じた。

問題は端末単体で購入が難しく、回線契約が必須となる点である。

 

開発者としては選択肢が増えることは嬉しい事なので、

メリット・デメリットをケースに合わせて使い分けたい。