Tokyo ComCamp 2016 powered by MVPsに参加してきた
2月20日にTokyo ComCamp 2016 powered by MVPsに参加してきました。
全体的にAzureなセッションが多かったかなと。
東京以外の会場でも面白そうなセッションがあったので、配信を見るという手もあったかな。
天気悪かったせいか、会場は結構空いてましたね。
目次
- 目次
- セッション1: デザイン(設計)にまつわるフォース
- セッション2: そろそろ(おまえらの)DevOpsについて一言いっておくか
- セッション3: Windows コンテナ 始動
- セッション4: DBA から開発者への情報提供
- 最後に
セッション1: デザイン(設計)にまつわるフォース
尾上さん(@ugaya40)のセッション。
資料は現時点(2/22)で公開されていませんが、とても勉強になりました。
これを聞くために参加したみたいなものですし(笑)
- デザインとはコンテキストにおけるフォースを調和させること。
- コンテキスト:デザイン大賞が取り巻く世界
- フォース:デザインが満たすべき要求
- 複数のフォールを解決するデザインは困難
- 品質特性同士の衝突
- 全体の利益と個人の利益の調整
- ゼロベースでは答えに到達できない。
- 必ず既存の形をベースにせざるをえない。
- 既存の形が適合していないフォースを見つけ、調整していく。
- パターンの適用は「より全体にかかわるもの」から「局所にかかわるもの」
- パターンについては、どんなフォース間を調整しようとしているのか。それが大事。
なるほど、難しい。という感じだったので、資料公開されたらもう一度読むしかない。
セッション2: そろそろ(おまえらの)DevOpsについて一言いっておくか
竹林さん(@changeworlds)のセッション。
ブログに記事が上がってました。
私の場合はセッション1で、牛尾 剛のお話を残念ながら聞かなったので、DevOpsとはどんなもんかと参加。
尾上さんのセッションでは、個人的にはDevOpsというワードに違和感とのお話もあったのですが(笑)
- 全体像を理解するためには原典に当たろう
- 英語も頑張ろう
- 企業においては、ビジネスを実現させることが目的のはず。
- ビジネスには変更が求められている
- 変更のRiskを現象させるためのDevOpsでは??
- なぜやるのか(why)が無い場合、自己満足に陥ることもしばしば
- whyから始めよう
- とくかく実践あるのみ
- 知識の段階:知る、わかる、できる
- 失敗しないと成長しない。そのためにも挑戦を。
セッション3: Windows コンテナ 始動
樋口さんのセッション。
最近、ちょこちょこNanoServerとか触ってたので、試しに聞きに行ってきた。
- InvokeVというHyper-VのコミュニティにFBにあるらしい。そこに資料も上がるそうな。
- ContainerとはOSが透過的に見る
- Windows Server Container : Server Core Base
- Hyper-V Container : Nano Server Base
- 後は細かいコンテナの話とデモ。
まだまだ新しい話&開発中の話なので、今後に期待ということで。
以前の資料が大体同じっぽいので、Link張っておこう。
セッション4: DBA から開発者への情報提供
小澤さん(@Masayuki_Ozawa)のセッション。
SQL Databaseを例にデモしながら解説。
DBA から開発者への情報提供のセッション資料を公開してみました。 https://t.co/n9z2gFoDqr #jccmvp
— Masayuki Ozawa (@Masayuki_Ozawa) 2016, 2月 21
- SQL Serverシリーズでは、SQL経由でほとんどの情報取得できるし、色々見ようぜ。
最後に
会場だったgloopsさん、おしゃれなオフィスでした。
結局Azure関連のセッションは聞くことなく、全体のトレンドに乗れないままの参加となりました。
とはいえ、こういう勉強会に来ないとなかなか触れないような話題も聞けて良かったです。
まずは自分の目の前で放置している諸々から手を付けていかねば(笑)
いずれは自分もフィードバックできる側に立てるといいなぁと思いつつ。。
WebRTC Conference Japan に参加してきた
WebRTCについては、ネットでちらっと調べたことあるくらいなもので使った経験もないまま参加してきました。
CodeIQさんの↓これで入場チケット頂いたというのがきっかけですね。
感想
特に1日目に関してはとにかく英語!英語!英語!って打ちのめされました。
同時通訳もあったわけですが、資料:英語、スピーカー:英語、同時通訳:遅延して日本語という状態では余計混乱する次第で(笑)
これは完全に実力不足なので、精進します。。
内容については、素敵なまとめをしてくださってるブログで確認した方がよいかと。
特別対談: WebRTCが切り拓く2020年のIoT
色々と印象的だったので、個別にメモ。
* Webの勢いがここ5年くらいで衰えていて、スマホに取られている
* PCについてはどんどんNativeからWebにサービスが移行している
* スマホはWebからNativeにどんどん移行している
* Internetの利点の一つはArchive
* 面白いのは、ニコ生のようにリアルタイム性に価値があるコンテンツがある。(コメント機能がそれを誘導しているともいえる)
* SMSでのコミュニケーションの在り方が、どんどんリアルタイムになっている。(非同期→同期へ)
* テレイグジスタンスはもっと流行って良い
* エンジニアはとにかく攻殻機動隊を読め!
終わりに
2日目はDev向けにずっといたのですが、1日目は理論寄り、2日目は応用寄りでとてもバランスが良かったです。
普段のフィールドとは違う分野でしたが、根っこの部分はそうそう変わらないなとも。
ただ質問できるだけの知識や経験をもって参加するともっとよかったなと思いました。
※そのためにはなにか作らねば(;^_^
2015年の振り返り
良い機会なので今年を振り返っておきます。
目次
ブログ始めました
一念発起して、ブログ始めてみました。
最初の頃は何とか更新していたのですが、年末に向かうにしたがって更新をサボってしまった(笑)
ただ、仕事やプライベートでやったことを纏めるのに改めて調べ直したり、サンプル書いたりして
かなり勉強になりました。
仕事
暗黒の炎上プロジェクトを続けたせいで、色々と消耗した一年でした。
得るものが少なく残業代を稼ぐだけの仕事でしたが、なんとかリリースできてよかったです。
退職します
というわけで、2015年12月31日付で現職を退職します。
来年からは取りあえず無職ということになりますが、人生頑張ります。
来年
メモだけでなくて、勉強会の参加レポやその他についても記事書いていけたらなと思っています。
少し(??)ゆっくりしたら再就職活動頑張ります。
c#からFirebirdのDBにアクセスした後、Exeの終了が遅い。その2。
Firebird Embeddedを使用した後、プロセスの終了が遅い件ですが、
その後色々調べたところ、似たような件で悩んでいる人はいるようでした。
ただ、解決にはいたっていないようです。
試しに FbConnection.ClearAllPools() がどれくらい効果あるのか試してみました。
結論から言えば、ConnectionをPoolしているときはそれなりに効果ありますが、
やはり3秒は超えられない。
なにかのタイムアウト待ちなのか、どうなのか。
環境
- Firebird Embedded 2.5.4
- FirebirdSql.Data.FirebirdClient 4.8.0
検証
前回利用したものの最後に、ClearAllPools と Connection作る時にPooling を true にする処理を追加。
static void Main() { var i = 0; var max = 2000; while (i < max) { var connectionBuilder = new FbConnectionStringBuilder(); //.....諸々 connectionBuilder.Pooling = true; using (var connection = new FbConnection(connectionBuilder.ConnectionString)) { connection.Open(); connection.Close(); } i++; } FbConnection.ClearAllPools(); }
FbConnection.ClearAllPools() を呼ぶ場合と呼ばない場合の2種類を用意して、時間計測。
FirebirdClient2 : FbConnection.ClearAllPools()を呼ぶ方。
FirebirdClient : FbConnection.ClearAllPools()を呼ばない方。
あまり厳密ではないですが、手元で何度かやってみたけど、結果は変わらず。
c#からFirebirdのDBにアクセスした後、Exeの終了が遅い
c#からFirebirdのDBにアクセスした後のExeの終了が遅いということがありまして、少し調べてみました。
結論が正しいのかわかりませんがメモとして残しておきます。
※検証甘いです。
環境
- Firebird Embedded 2.5.4
- FirebirdSql.Data.FirebirdClient 4.8.0
現象
諸事情で、A.exe → B.exe といった呼び出しが複数回あるようなアプリ構造がありました。
B.exeの終了が遅いので、全体の処理がとても緩慢な感じに。
ということで、ミニマムコードを。
static void Main() { using (var connection = new FbConnection(接続文字列)) { connection.Open(); connection.Close(); } }
これだけで、私の環境だとMainを抜けた後に3秒程かかりました。
ConnectionをOpenしなければ1秒未満です。
分析
まずは時間を。
var process = Process.Start(@"D:\tmp\FirebirdClient\FirebirdClient.exe); process.WaitForExit(); //ExitCodeでHHmmss形式で終了時間をReturnするようにして、 //DateTime.NowをHHmmss形式にしたので差分をとる。 var elapsed = Utility.Subtract60(DateTime.Now.ToIntTime(), process.ExitCode); Console.WriteLine($"Path: {path} / Seconds: {elapsed}");
ProcessMonitorで見てみると、
もしかして、また君ですか。
fb_trace_xxxには時折苦しめられておるのですが(笑)
解決策(??)
動作を見ている限り、fb_trace_xxxやfb_Lock_xxxなどのTempデータはNetProvider経由の場合、プロセス終了時にクリアされているようでした。
DelphiXE + FireDAC だと接続切っただけでクリアされていたような気がするんだけどなぁ。
ってなわけで、
[DllImport("kernel32", SetLastError = true)] private static extern bool FreeLibrary(IntPtr hModule);
手動でアンロードしてみる。
- FirebirdSql.Data.FirebirdClient → × (そりゃそうだよね..)
- fbembed.dll → ○ パリィ(°▽°)
static void Main() { using (var connection = new FbConnection(接続文字列)) { connection.Open(); connection.Close(); } UnloadDll(Path.Combine(Path.GetDirectoryName(Assembly.GetEntryAssembly().Location), @"fbembed.dll")); } [DllImport("kernel32", SetLastError = true)] private static extern bool FreeLibrary(IntPtr hModule); public static void UnloadDll(string path) { foreach (ProcessModule dll in Process.GetCurrentProcess().Modules) { if (dll.FileName.Equals(path, StringComparison.OrdinalIgnoreCase)) { FreeLibrary(dll.BaseAddress); } } }
これで良いのだろうか(笑)
動作に問題はなさそうなんですが、確かなことが分からず。
とりあえず、これで妥協してみようかなぁ。
試しにサンプル上げてみた。