カテゴリー別アーカイブ: 勉強会

第55回 長岡IT開発者勉強会に参加しました #nds55

1件のフィードバック

第55回勉強会(2017/03/17) – 長岡 IT開発者 勉強会(NDS)
http://nagaoka.techtalk.jp/no55

テーマ「入門・初心者向け」

毎年恒例の春企画、新社会人・新入生に向けた入門者向けのテーマで発表お願いします。（まだ3月ですが）
特定のテーマにおける入門的なテーマでもOKです。もちろんテーマ外の発表も歓迎です。

に参加、発表してきました。

テックトーク

pythonはじめの一歩（コードとかではなく） by @civic

NDS主催のcivicさんの発表です。Python環境のハマらない作り方についてでした。

https://docs.google.com/presentation/d/1K6a1fBdQyD51k4EJrZyRsGsw5N1ftaTN7zn7TrqRm_A

Pythonは触る機会が今のところないのですが、Windowsは公式インストーラーがお勧めということですので、触る必要が出てきたらそうしようと思います。

個人的に面白かったのは、pythonのライブラリなどのパッケージ管理は、プロジェクト単位ではなく「仮想環境」単位ということでした。ほかのツールは、プロジェクトフォルダーの下に必要なモジュールを置くことが多く、なるほど文化の違いとは面白いものだ、と。

あわせて読みたい

長岡IT開発者勉強会 #nds55 に参加・運営してきました | civic site

長岡IT開発者勉強会 NDS #nds55 に参加・運営してきました

プロジェクトマネジメント入門 by hiro_ishibashi

ProjMのいしばしさんによる入門でした。

この一言に集約される気がしますね。

https://twitter.com/shinpei0213/status/974879238292619264

Docker for Mac/Windows ではじめる Kubernetes by @hayajo

はてなのはやじょさんのセッション。

個人的にはDockerはさわりはやってますが、その先は全く使ってないのでちょいとついてくのつらかったんですが、研修とかでAPサーバー・DBサーバーのセットをえいやって配るのに便利そうだなーと思いました。これは懇親会で直接聞いたら、そういう用途もよくあるということだったので、理解ずれて無くて安心。

なお、「Kubernetes」の発音は、はてなでは「クバネテス」が多数派だそうです。

はじめてのソフトウェアテスト技法 ー 同値分割・境界値分析編 by @kasacchiful

笠原さんのテスト入門第二弾。テスト技法の初歩的なところを説明していただきました。

「同値分割」の時に使えるツールに「同値図」というのが出てきて、これまで私はツリーでやってきたのでいい情報でした。連続値の分析には数直線、離散値には同値図が向いているとのこと。

質問で出た、「境界値自体が外部からの入力になる場合はどうしたらよいですか？」はとっても良い質問で、「ドメイン分割」や「デシジョンテーブル」で戦うという話でした（私もそう思います）。

きっとこれ、「現在の日時で～」みたいなのでも同じこと言えそうな感じですね。隠れた入力値をいかに割り出せるかがポイントでしょう。

アウトプットのすゝめ 〜春のエモを添えて〜 by @shinpei0213

猫型さんによるエモーショナルなセッション。

とにかく「やらなければ、はじまらない……」ということで、アウトプットするとこんなにいいことがあるよっていう熱い思いをぶつけてくださいました。

んで、おそらくぶつけられてる対象なんだと↓から読み取りましたので頑張る。

https://twitter.com/shinpei0213/status/974992557011648512

フリーランスで割と長くリモートでやってる僕が気をつけていること by @nemuzuka

片桐さんのリモートワークにまつわるあれこれでした。積極的にアピールすることや、全部残すとかがポイントなんですが、結局リモート関係なくやった方が職場環境よくなることがたくさんでした。あと、リモートワーク可能かどうかは組織による部分もかなり大きいとのこと。たしかに。

今後なにかしらそういう時が来たら全力で参考にさせてもらいたいと思います。

あわせて読みたい

長岡IT開発者勉強会(NDS)の第55回勉強会に参加してきた #nds55 – nemuzukaの「明日から本気出す」

Amazon Neptuneに入門してみる by @yuw27b

某大学の研究室勤務というWatanabeさんによる、AWSのマネージドグラフDBサービス「Neptune」の紹介でした。

昨年もNeo4jなどのグラフDBについて紹介してくださったのですが、商用で使い物になるグラフDBはあんまりなくて、今後本命になるかもしれないということでした。今のところ、まだプレビュー段階で、ごく一部のリージョンでしか使えませんし実践投入できないそうなのですが、ハマるところはありそうなので早くプレビュー取れるとよいですね。

質疑応答では、「プロパティグラフ」、「RDF」のどちらがどんな用途に向いているか、といった質問があり、「プロパティグラフ」はパス解析などができるが組み合わせ爆発に注意、「RDF」は問い合わせに使うSPARQLの都合でパス解析はできないのでノードの偏りなどの解析向きということでした。

新しい世界の学び方 by @masaru_b_cl

私のセッションで、テックな話題はいっぱいあるだろうからということで、誰でも使える「学び方」の紹介でした。

セッションで取り上げた「ラーニング・パターン」は実際とっても有用なので、個人・チームでぜひ読んでほしいです。

質疑では「何が原理原則かわからない問題」について聞かれ、「わかる」という感じだったのですが、そのあたりは有識者が手を差し伸べるのが一番早かろうといった旨を答え、公開したスライドにもちょっち反映させました。

アイコンフォントを手作りしよう by @gatabutsu

やまざきさんによる「ライブ・アイコンフォント作成」も含んだ面白いセッションでした。「長岡市の形をしたアイコンが欲しい」という無茶ぶりに、見つけた地図からアイコンフォントをフォトショップ、イラストレーターなどを駆使して何とかした話を紹介してくださいました。

なかなかにニッチな仕事ですが、手持ちの武器で何とかする姿は正直かっこよかったです。

LT

数年ぶりにJSを使った件 by @gonchan93

WSHでJScriptやることになったらprototypeとESとの違いにハマった話でした。

滅ぼしたい気持ちはわかるが、無理だ。

Blazor（.NETのWeb Assembly対応したSPAフレームワーク）について by @AILight

C# で Single Page Web Application が書ける Blazor が凄かった件 – Qiita
https://qiita.com/jsakamoto/items/20d4893f6c8cdb0356f6

でもちょっと話題になったBlazorについて。

「System.dllをGETしてる……！？」と皆さんから驚きの声が上がりました。

実際WebフロントエンドはXamarinもカバーできていない領域なので、.NETのWebフロントエンド開発の（来ないかもしれないけど）未来を感じます。

Azure開発の感想 by ToruAbe

初めて開発にAzureとVSTSとVSとC#使ってみた感想でした。

また一人VSの魅力に取りつかれてしまったか……

ながおか技術教育支援機構についてのお知らせ by masarunagai

かれこれ15年くらいやってる、小中学生向けにプログラミングを教える非営利団体の紹介から、タイトルの機構を立ち上げるというアナウンスでした。

昨年RoboCupで優勝した高専生はそのプログラミングイベントのOBだそうで、小さいうちから「楽しむ」ことを一番にやってきたといういいお話でした。

初めてを楽しもうよ by @84taka0310

今年度取り組んできた初めてのことの紹介。

各地のイベントにとりあえず飛び込んでみる行動力は素晴らしいです！

はじめてのAWS認定資格取得 by @kasacchiful

会社の都合でAWS認定資格を取ることになった顛末。

キオスク端末試験は地雷で、日本だと秋葉原会場が良いとのこと、承知。

懇親会

久々にお会いするメンツと主にお話ししてました。

  • はてなのはやじょさんのTLが超楽しそう
  • Rで始まるWebフレームワークの功罪
  • #rebuildfmで聞いたところだ！
  • インフラ勉強会が超面白い
  • 新潟価格と京都価格と東京価格

みたいなとりとめのないことを話しながら、楽しいひと時でした。

 

最後に

NDSは今回のトークセッションでもわかるように、非常に多様な話を気軽にできる場です。

ぜひ参加して、「あなたの」体験を話してみてください！

Niigata.NET 3.0を開催しました #ngtnet

コメントを残す

Niigata.NET 3.0 テックトーク＋ハンズオン ＆ .NET開発お悩み相談室 – connpass
https://ngtnet.connpass.com/event/69634/

先週土曜の11/18に通算4回目となるNiigata.NETの勉強会を開催してきました。

今年は
「アプリを作ろう! Visual C#入門」という本を書きました
のエントリで書いた通り、本を書いていたため、勉強会開催にかけるリソースが足りず、結局昨年の
Niigata.NET 2.1を開催しました #ngtnet
からちょうど1年ぶりの開催になってしまいました。

今回のテーマは、前回に引き続きテックトーク＋ハンズオンです。

プログラミング初級講座 C#編 – 反復 by @AILight

最初は恒例の@AILightさんによるC#のセッションです。「変数」、「分岐」に引き続き、今回は「反復」がテーマでした。

「反復」というと、私は次のようなものをイメージしていました。

  • for使うな
  • 基本はwhile
  • 原則foreach

もちろんこのことも触れられていましたが、今回のセッションで心に残ったのは次の3つでした。

反復は「前処理」、「後処理」とパックで行う

反復というとfor、while、foreachといった「ループ」本体に目が行きがちですが、実際に反復処理を行うときは、前処理の後にループ本体、そしてループが終わったら後処理がほぼ必ずあります。したがって、この前後の処理もループの構文の直前、直後にまとめて記載しておくことが重要とのこと。こうすることで、反復処理全体を簡単に移動させることができますし、なによりループ内部で使っているものが近くにあるので、コードが追いやすく、変なこともしにくいという効果があるそうです。

私自身もほぼ何の気なしにそのように書いてはいましたが、改めてそう言われるとなるほどなとうなりました。

ループ+switchで状態を変更させて処理を行える

パズル感があり、あんまり現在は進められる方法ではありませんが、次のようにループとswitchを組み合わせて、状態遷移で処理を行うというテクニックがあるそうです。

var state = 0;
for (; ;) // 無限ループ(かわいい)
{
  switch (state)
  {
    case 0:
      Console.WriteLine("Header");
      state = 1;
      break;
    case 1:
      if (!recordExists)
      {
        state = 2;
        break;
      }
      Console.WriteLine("record");
      break;
    case 2:
      if (recordExists)
      {
        state = 0;
      }
      else
      {
        state = 3;
        break;
      }
      Console.WriteLine("Footer");
      break;
    case 3:
      Console.WriteLine("Summary");
      state = 4;
      break;
  }
  // state = 4
  break; // ループ終了
}

まず使うこともないでしょうが、いざというときの「腕力」として覚えておこうと思いました。

コレクションの要素とindexを同時に使うときはSelect((element, index) => …)を使う

反復処理を行うとき、コレクションの要素とindexを同時に扱いたいケースがたまにあります。

そんな時私はこれまで、次のようにループの外でindex用変数を宣言してやっていました。

var index = 0;
foreach (var element in collection)
{
    Console.WriteLine($"element: {element}, index: {index}");
 index++;
}

しかし、LINQの要素とindexを取るSelectメソッドを使ってからforeachすることで、ループの外での変数宣言が不要になるとのこと。

foreach (var item in collection.Select((element, index) => new { element, index }))
{
    Console.WriteLine($"element: {item.element}, index: {item.index}");
}

構文自体は知っていましたが、これまでそんなに使っていなかったので、今後は積極的に使っていこうと思います。

アプリ開発ハンズオン by @masaru_b_cl

「アプリを作ろう！ Visual C#入門」のじゃんけんアプリをネタに、本を見ないでやってみようというハンズオンをしました。資料はこちら。

当日はラウンド制まではたどり着かず、代替全員があいこならもう一回勝負するというところまで出来たら時間切れになりました。

参加者の皆さんの様子を見ていると、普段仕事で作成するアプリと違い、ゲームは「状態」を強く意識しないといけなかったり、画像をリソースを使って扱ったりしないといけないため、案外手こずっているようでした。

そんななか、何とかは私は著者の面目を守り、スライドの説明後に超速でコーディングして何とか一つの実例コードを書き上げることができました。セッションの最後では、そのコードをもとに開設＆コードレビュー会を行いました。

その際説明させてもらったのは、次のような内容です。

  • コントロールのプロパティ直接扱っちゃダメ、絶対！
    • いったん変数に受ける
    • これによりメソッド切り出しが容易になる
    • さらに他の型に追い出すことも容易になる
  • 勝敗判定は次のような感じでやると良い
    • まずグー、チョキ、パーを0,1,2でも列挙型でもよいので一段抽象化する
      • PictureBoxコントロールのImageプロパティで判断してはいけない
    • 判定は次の順
      • プレイヤーと敵の手が一緒ならあいこでreturn
      • 愚直に勝ちパターン3つをor判定
        • プレイヤー：グー && 敵：チョキ
          or プレイヤー：チョキ && 敵：パー
          or プレイヤー：パー && 敵：グー
      • 勝ちでなければ負け
  • グー、チョキ、パーの画像は何らかのテーブルで管理
    • グー、チョキ、パーを指定すると取れる
    • 例では配列を使った
      • 列挙型をキーとするDictionaryだと実行時例外が起きなくてよいのではというアドバイスあり

あと、書籍では実装しなかったのですが、じゃんけんを始めた後、敵の手が次々とランダムに変わりルーレット状になるようにも実装しました。これにはTimerコンポーネントを追加し、次の要領でやりました。

  • スタートボタンが押されたらプレイヤーの手を消してからタイマー開始(Enabled = true)
  • タイマーのTickイベントハンドラーで敵の手をランダムに表示
  • プレイヤーが手を選んだらタイマー停止(Enabled = false)
  • あいこならプレイヤーの手を消してからまたタイマー開始
  • 勝ちか負けなら手を選べなくしてスタートボタンを押されるまで待機

やってみるまでは、非常に簡単なアプリなのでどれだけ盛り上がるかちょっと不安だったのですが、実際にはそれぞれの人でやり方やプログラミングスタイルが異なったり、持っている知識レベルに差があるため、手が止まってしまう箇所がいろいろあって都度アドバイスして直してもらったりと、結構充実した時間となりました。また別テーマでハンズオンをやってみるのもよいなと思えた貴重な時間となりました。(ハッカソンもできたらやりたい)

.NET開発相談室

アプリハンズオンが思いのほか楽しく時間を延ばしてやってもらったので、今回は.NET相談室は取りやめにしました。ただ、次やるときは事前に相談したいことを出してもらってからやるようにしようかなと思いました。

懇親会

次のような濃密な議論ができた時間でした(しれっと

https://twitter.com/84taka0310/status/931819903601885184

次回に向けて

開催ペースが落ちてしまったので、何とか年2回ペースをキープしたいところです。ひとまず5月くらいを目途に、またやっていこうと思います。

あわせて読みたい

第53回 長岡IT開発者勉強会に参加しました #nds53

コメントを残す

第53回勉強会(2017/09/30)「○○プラットフォームについて」 – 長岡 IT開発者 勉強会(NDS)
http://nagaoka.techtalk.jp/no53

に参加してきました。今回のテーマは「〇〇プラットフォームについて」（テーマ外のスピーチでも大丈夫）でした。

テックトーク

WebプラットフォームとしてのWordPress by nomeshi

WordPressはこのblogでwordpress.comを使ってるくらいで実際に現場でどのように使われているか知らなかったのですが、やはり相当のシェアがあるんですねぇ。

セッションではプラグインの使い方や次世代の記事エディターとしてGutenbergが紹介されました。Gutenbergはwordpress.comにも来て欲しい。

デモでは、自作プラグインとして猫画像を表示するものを見せていただきました。詳細はこちらをどうぞ。

WordPressのGutenbergに自作のブロックを追加する（実用性は無し） – Qiita
https://qiita.com/shin1kt/items/8e797074b3fff18f8234

IoTプラットフォーム・工作でスーヴィード（低温調理） by @civic

低温調理器を買うと高いので自作した話です。すでにv1はあったのですが、温度を見て単純にスイッチをON/OFFするだけのため、温度の揺らぎがあるので、それを是正するためにあれこれした話でした。

質疑応答の中で「自作電子工作機器は危険が怖い」というのに対し、「電流のヒューズじゃなくて温度ヒューズ(高温になると電流遮断)を使うといい」というアドバイスがあって、NDS最高かよってなりました。知見はあるところにはあるもんですね。

「音楽制作プラットフォームの話」か「GUI app on ブラウザプラットフォームの話どっちか」改め「音楽理論」by しんぺい a.k.a. 猫型蓄音機

NDSはプログラミングなどのテック菜花氏以外に天気とか地形などの教養を学べるセッションもOKなのが特徴ですが、最近なかったのでブッコんできたとのこと。

とある周波数の音を区別しやすく名前を付けている(例：44HzがA(ラ))とか、音階(スケール)、調性の話から始まり、和音(和声)の種類、仕組みや不安な音、安心な音など、わかりやすく説明してくださいました。

このセッションのパワーワードは「音楽はデザインパターン」でした。プログラマー各位は向いていると思うということなので、各位やっていきましょう！

なお、猫型さんが作曲した曲や歌は、SoundCloudで聞けるそうです。

https://soundcloud.com/shinpei0213/

(おお、wordpress.com、SoundCloudも埋め込めるのか)

Terraformで構築するマルチクラウドプラットフォームインフラストラクチャ by hayajo

越後の誇るインフラスペシャリストであるはやじょさんのセッション。

「Infrastructure as Code」を体現するHashiCorpのツール「Terraform」の紹介でした。名前は聞いたことがあったのですが、どんなものかは知らなかったのですよね。

基本的なコンフィグファイルの書き方に合わせて、様々なサービス、製品(AWSとかAzureとかをはじめとしたクラウドサービスや、ChefやDocker、GitHubなど)に対するプロバイダーを使ってインフラを表現することで、実行計画を見たり、構築したり、マイグレーションしたり、まとめて破棄したりと、確かに便利そうでした。

とはいえ、自動化ツールはなんでもそうですが、再実行すればするほどリターンが大きいものなので、簡単なものはWebコンソールからポチポチの方が速かったりすることもあるそう。この辺はバランスですね。

C#で始める、Windows プラットフォーム 開発効率向上化プロジェクト by AILight

これまで仕事で取り組んだ「共通化」の話を惜しげもなくしてくださいました。

共通化というとよくあるのはライブラリレベルを思い浮かべますが、そうではなく「販売管理システム」のデータモデルから共通化し、10年かけて練り上げ、負債ではなく資産として成長させてきたという話でした。

このあたり、正直いわゆる「直ユーザー」相手に仕事をしていないと、案件ごとに使う技術がそろえられないのでまず無理なのですが、それでも非常に「正しい」と思える話でした。

あと、驚いたのは、サードパーティのコンポーネントを排するため、帳票コンポーネントも自作しているということ。入力コントロールやグリッドコントロールくらいなら私も作りましたが、さすがに帳票までやろうとは思えませんでした。完全に頭おかしい(ほめ言葉)。

イベントログとの付き合い方 by gonchan93

最後はWindowsのイベントログの紹介。

WindowsのイベントログはテキストベースではなくバイナリでがっつりOSの仕組み使って書き出すので、少し扱いにくい部分もありますが、ログファイルの置き場所とか考えなくてよいのは強いです。テキストベースでエクスポートしようと思えば、JScript等を使ったWSHやPowerShell、C#などのプログラムで結構お手軽にできますし。

ただ、標準のビューアーだけはもうちょっと軽くならんかなぁ……

LT

私含めいろいろと。私はというと、

「アプリを作ろう! Visual C#入門」という本を書きました

で紹介したように本を書いたので、その紹介を行いました。レビュアーを募ったらほとんど手が上がらなくて泣きそうでしたが、最終的に2名の方に引き取っていただけました。改めて御礼申し上げます。上がってくるレビューを心待ちにしております。

まとめ

毎度のことながら、NDSはこの「ごった煮感」がたまりません。最近通常セッションのスピーカーをやってないので、またネタ仕込んで登壇したいところです。

そして、次は12/2(土)に開催予定とのこと。その日の懇親会は毎年恒例NDB(新潟・長岡 IT開発者 忘年会)も開催ということで、しっかりYAuth通して参加したいと思います。

みなさんも楽しい勉強会ですので、ぜひおいでください。

第51回＆第52回 長岡IT開発者勉強会に参加しました #nds51 #nds52

コメントを残す

の2つの勉強会に参加してきたので、片方はだいぶたっちゃいましたが、「レポートを書くまでが勉強会」ということで、思い出して書きます。

第51回

「データに関わる何か」というテーマで、プログラミングではない話も含め色々聞けました。

当日の様子は次のtegetterからどうぞ。

第51回勉強会 テーマ「データに関わるなにか」(2017/03/25) #nds51 まとめ
https://togetter.com/li/1094088

Vue.jsから始めるDOMにデータを持たせないアプリケーション開発への第1歩 by @nemuzuka

最初は片桐さんのVue.jsの話。Webフロントエンド戦国時代の現在、React、Angulerなどと並んで人気のあるライブラリですね。

諸事情により途中からしか観れなかったのですが、「コンポーネント指向」なところまでちゃんと紹介されていてよかったです。データバインディングの書き方も、個人的にはKnockoutよりもシンプルで好みです。

ReactとかAnglerとかみたいに結構大きめに投入するのは最初の心理的ハードルが大きいですが、Vue.jsはデータバインディングだけでも、jQueryだけで頑張るより楽になるケースも多いと思うので、最初に取り組むにはよいと思います。

RDBMS のトランザクション分離レベルやレプリケーションとか。あと苦労話。 by bell-miya

もうタイトルそのまんまです。

元々RDBMSに慣れていて、その感覚で新たなRDBMSに取り組んで失敗した話とかそんなのが聞けて、活きた話が聞けました。

グラフ構造データを扱うはなし：グラフデータベース、RDF、可視化など by Yu Watanabe

http://yuw27b.github.io/slide/graph-data

「大学の非常勤エンジニア + フリーランス」という珍しい肩書のYu Watanabeさんの、グラフデータベース「Neo4j」をメインとして話で、個人的に今回一番面白かった。

SIerに勤務している関係もあり、プロジェクト運営におけるタスクのクリティカル・パスの分析や、PERT図などの扱いに使えそうだなという感想を持ちました。ぜひ今後取り組んでいきたいところ。グラフ構造を扱う専用ミドルウェアがあるなら、自分でコード書くのがんばるよりぜってい良いですからね。

入門系の本を一冊も読まずにデータサイエンスの世界に足を突っ込んでみる by sakapun

最近（？）流行りのデータ分析の概要と、Python等で使えるツールの紹介でした。PandasやJupyter Notebookなど、

#rebuildfm で聞いたところだ！

ってのがたくさんで、大変面白く聞けました。

PostgreSQLのデータ型 by @civic

NDS代表civicさんの発表です。

PostgreSQLは結構変わったデータ型がいっぱいある印象でしたが、他のRDBMSでも取り入れられてきているそうで、あんまり差がなかったとかｗ

範囲データ型とかSIerな文脈では便利そうな感じを受けましたが、データドライバー（プロバイダー）側の対応が整備されているわけではないので、取り扱いには注意が必要そうです。

Let’ LINQing! by @masaru_b_cl

私の発表です。LINQPadを使ったデモも交えながら、LINQを使った簡単なデータ処理を紹介しました。

スライドにも書きましたが、データ処理では@sakapunさんの発表で紹介されたpython系のツールが主流です。しかし、対象データの規模や組織のスキルセットなどを考えれば、C#およびLINQを用いたデータ処理は、そこそこ有望な選択肢の一つだと思います。

当日使ったLINQPadのファイルは以下のGitHubリポジトリに置いてありますので、ぜひ試してみてください。

https://github.com/masaru-b-cl/nds51-linqpad-files

LTs

既に3ヶ月経ってあんまり記憶が無くて感想が書けません。申し訳ないです……

懇親会

ビアバッシュ形式で開催されました。ずっと@nemuzukaさん、@AILightさんとしゃべってた気がする……

 

第52回

「初心者向け」というテーマで、様々な入門？的なセッションが聞けました。オーディエンスが初心者じゃないのではというツッコミもありましたが、そんなことないよ！

当日の様子は次のtegetterからどうぞ。

第52回勉強会 テーマ「初心者むけ」(2017/06/17) #nds52 まとめ
https://togetter.com/li/1120966

はじめてのC#プログラミング by @AILight

最初はMS MVPの石野さんによる、C#プログラミングの紹介でした。諸事情により途中から観たのですが、マシン語やアセンブリからC#に至る道も紹介していて、おっさんホイホイでした。

後半のC#の話に入ってからは、順次、分岐、反復について、石野さん自身のスタイルも紹介しながら、バグの入り込まないプログラムの書き方につながり、良い話でした。

https://twitter.com/neko_gata_s/status/875951636178272256

なんてかんたんなJavaEE by @civic

NDS代表であるcivicさんによる、最近のJavaEEの紹介でした。

がセッション聞く前の印象でしたが、最近は「Payara」というJavaEEコンテナサーバーなどで実装されている、Micro Profileというものがあり、ASP.NET MVCバリに軽量にWeb APIが書けるのはちょっと新鮮でした。

そして、JVMで動くということはJVM言語ならOKなので、最近話題のKotlinや関数型パラダイムを取り込んだScala、スクリプト言語のGroovyなど、好みの言語で動かすこともできるので、結構さっくりと書けてしまいそうです。

文字コードとプログラミング by @gonchan93

諸事情によりスライド途中で終わっちゃったんですが、文字コードについての恨みつらみが詰まったセッションでした。

がすべてで、Unicode使わないとつらい話とかJava等の言語での文字の扱いについてとか、「初心者向け？」という内容ではありました。

結果、大多数の認識が

https://twitter.com/neko_gata_s/status/875964116145287168

になるという異例の事態に。

Netcatを使おう by @hayajo

チョー便利なネットワークコマンドツールNetcatの紹介です。

Netcatとは「ncコマンド」のことで、多くの実装がありプラットフォームによって採用する実装がバラバラらしく、今回はその中のNcatを紹介してくださいました。

ncatは初めて知ったのですが、ネットワーク系ツールのクライアントにもサーバーにもなり、さらに自身をプロクシとして動かすこともできて「組み合わせ次第で可能性は無限大！」でした。その分使いこなすにはひらめきが必要そうですが、小さな部品を組み合わせるというUnix-wayを体現していて、好感が持てました。ncatはWindows版もあるそうで、覚えておくと役立つ機会もありそうです。

正直「初心者向け…？」レベルではありましたが、良いセッションでした。

なお、今回のパワーワードがこちら

怖くないし役に立つ設計原則の話 by @neko_gata_s

スライド公開はないそうですが、DRY原則から始まり、プログラミングの基本的な設計原則はそれぞれ関わり合っているので、「一つだけを考慮するのではなく全体のつながりを見てコードを分けていこうな！」というメッセージが最高でした。

説明にはRubyっぽいコードを用いていたのですが、間違ったDRYコードのクソな点を説明し、本来目指すべきだったDRYコードを提示しての説明は、プログラミング言語を覚えて次に行こうとする人にはちょうど良い感じだったと思います。

ご本人の思いなどは、こちらのエントリをどうぞ。

第52回NDS(長岡開発者勉強会)で「怖くないし役に立つ設計原則の話」を発表してきました – 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

はじめてのソフトウェアテスト by @kasacchiful

笠原さんによるまさに「初心者向け」のテストの話です。ソフトウェアをテストするとはどういうことなのか、どういう切り口でテストを考えていけばよいのか、どうやってテストケースと考えればよいのか、といった基本的な部分を押さえていて、非常に良いセッションでした。

そして、「『バグ』は曖昧な言葉」、「テスト観点はテストの目的に応じた品質特性を見ている」、「テストが品質を上げる割合は少ない」、「テストは最後の砦」、「テストがうまくなると設計がうまくなる」など、パワーワード満載でした。資料公開が待ち遠しいです。

今日から使えるCSSパターン by @yuw27b

第51回に引き続きWatanabeさんの登場です。

個人的に身に着けたCSSの知見について紹介していただきました。フレームワークやOOCSSから入り、BEM（Block Element Modifiler）→ECSS（Enduaring CSS）の考えを取り入れた形に今は落ち着いているとのこと。

私自身はあんまりがっつりとCSSを書くことはないのですが、いざ書く必要に駆られたときに、あんまりうまいこと設計できていないと感じていたので、BEMなどのコンポーネント化されたCSS設計手法は、非常に参考になり、ECSSについても学んでみようかなと思いました。

なお、ご本人の思いなどはこちらのエントリをどうぞ。

NDS第52回勉強会に行ってきたよ – yuw27b’s blog

はじめての修羅場 by @hiro55bs

「明日修羅場にPMとして放り込まれたら？」という胃が痛いセッションｗ

結局のところ銀の弾丸はないので、現状把握→上と握る→ステークホルダーと調整→タスクのトリアージ→無駄の削減を進めていくしかない感じで、ああ胃が痛い（2回目）

早く修羅場が終わるといいですね……

LTs

LTは今回私入れて3本でした。

フリーランスの始め方(初心者向け) by @nemuzuka

安心と信頼の片桐さんによるフリーランスの始め方。

「1. フリーランスになります。以上。」とのこと。

会社員からフリーランスになって、一番気を付けないといけないのは税金と社会保険だなぁと思いました。まる。

「新人研修の作り方」のその後 by @masaru_b_cl

私のLTは第41回での無茶ぶりLTで話した「新人研修の作り方」のその後の問題、改善点などをお話ししました。スライドは公開しませんが、また機会を改めてちゃんとまとめて詳しく説明できる機会を持てたらとは思います。

なお、質問でいただいた当社新人研修のテキストは、次の4本を公開しています。ライセンスはCC-BY-SAですので、ご自由にお使いください。

インターネットの契約から開通まで by @kam1nchu

なごやちほーからこの4月に新潟にいらっしゃったということで、速いインターネットを用意するお話でした。

IPv6のため「だけ」にひかり電話を契約して使わないとか、UNIからケーブル引っこ抜いてYAMAHAのルーターにさすとか、やばい人が新潟に増えました！（褒めてる）

懇親会

今回もビアバッシュ形式で楽しみました。前回の反省も踏まえ、今回は一応全テーブルに顔を出すことに成功しました。あと、ねんがんのはやじょさんとがっつりお話しするのも、たぶん実績解除できたかと思います。

まとめ

NDSはテーマを絞らない分、ごった煮感、カオス度が非常に高くてとても面白いコミュニティです。新潟近郊の方だけにとどまらず、首都圏の方も新幹線で2時間しないで来れますので、ぜひおいでください（ついでに新潟のおいしいお酒と料理も楽しめますよ！）。

それはそれとして、私としてもまたNiigata.NET開催に向けて「狂気」と高めていかないとなと、決意を新たにしました。

次回も都合がつけばぜひ参加したいと思います！

Niigata.NET 2.1を開催しました #ngtnet

1件のフィードバック

Niigata.NET 2.1 テックトーク＋ハンズオン ＆ .NET開発お悩み相談室 – connpass
https://ngtnet.connpass.com/event/41607/

先週11/19（土）に今年2回目となるNiigata.NET勉強会を開催しました。今回は従来のテックトークに加え、参加者の皆さんにも手を動かしてもらおうと、ハンズオン形式のセッションも取り入れてみました。

（当日の様子はこちら）

 

プログラミング初級講座 C#編 – 分岐 by @AILight

最初のセッションは、新潟が誇るMS MVPの石野さんによる、シリーズもの第3弾です。if、switchといった「分岐」を扱う言語機能についてフォーカスし、初歩的な内容から紹介していただきました。

その中で印象的だったのは「分岐がないことが分岐の良い条件である」といったような雰囲気の言葉でした。

ともすると、分岐というものはいわゆるスパゲティコードになってしまいがちなものです。特に初心者、初級者のうちは、いわゆる設計書に書かれたロジックをそのまま表現しようとして、様々な条件が入り組み、深くなったif分を書いてしまうものです。

こういったif文、switch文を「いかに減らすか」が、分岐を扱うキモだと石野さんは主張されました。

その為に、if文をどうやって減らすかということを、コード例を用いて説明しました。その方法は主に以下の通り。

  1. 配列等を使ったジャンプ
  2. 「条件」でなく「データ」に着目

配列等を使ったジャンプ

引数が0->5のような値だとして、それに対応する値を返すような場合、それは引数をインデックスとみなして配列を用いて目的の値を返すようにすることで、if文をなくすことができます。

変更前
int SomeMethod(int value)
{
  if (value == 0)
  {
    return 5;
  }
  else if(value == 1)
  {
    return 10;
  }
  else if (value == 2)
  {
    ...
  }
  ...
}
変更後
if SomeMethod(int value)
{
  return new [] { 5, 10, ... }[value];
}

何かしらの値のテーブルを使って対応する値を返すようなケースでは、案外使えるケースはありそうです。

「条件」でなく「データ」に着目

小規模なアプリでメニューを作る際、ユーザーの情報を条件にif文を連ねて必要なメニューを表示するようにすると、条件の追加、変更に弱くなってしまいます。それを解決するため、「ユーザー情報」側にどのメニューを表示するかの判断を委譲し、メニューを構築する側ではそれを利用するだけにします。

変更前
if (user.IsHoge)
{
  // A機能メニューに追加
}
else if (user.IsFuga)
{
  if (user.IsPiyo)
  {
    // B機能メニューに追加
  }
  else
  {
    // C機能メニューに追加
  }
}
変更後
if (user.UseA)
{
  // A機能メニューに追加
}
else if (user.UseB)
{
  // B機能メニューに追加
}
else if (user.UseC)
{
  // C機能メニューに追加
}

このように「データ」を主体に構築することで、条件の追加、変更に強くなります。

 

先日リリースされたC# 7では「型スイッチ」機能などでさらに分岐のパターンが増えます。こういったものを使うにも、基本的なif、switchは押えておいた方がよいでしょう。

 

ASP.NET MVC開発体験 by @masaru_b_cl

私のセッションです。asp.net/mvcからアクセスできるASP.NET 5のチュートリアルを、会場の皆さんとやりながら簡単にASP.NET MVCの説明を行いました。

一緒に進めていくので、それぞれ進み具合が違い、ある程度余裕を持って進めていたので、MVCのCとVまでしかできませんでした。それでも、Cでリクエストを受け取って処理して返す、VはRazorで書く、Vの編集と確認はリビルド不要、くらいは説明できたので良しとしましょう。

実際、今回のセッションの裏テーマは「公式チュートリアルやろうぜ」でした。

大抵のメジャーなプラットフォーム、フレームワークは公式がチュートリアル用意してあることが多いです。もちろん英語なわけですが、「うわっ、英語怖い！」を乗り越えて読んでみると、実際は中学英語範囲の構文で読めますし、重要なのはコードなので万国共通のため、あんまり問題ありません。

それを避けてわざわざどこの馬の骨ともわからない人が書いた日本語blogエントリを読んだり、公式以外のチュートリアルを見ても、情報が古かったり、環境構築が大変だったりして、すんなりいかないことが、個人的には多いと感じています。

その点、公式チュートリアルは必要十分な情報をコンパクトにまとめてあることが多いです。一例として、某レールに乗るフレームワークのチュートリアルは、環境の違いかうまくできなかったんですよねぇ。でも、公式のやつは引っかかることもなくできたという経験があります。

ぜひ、未知のプラットフォーム、フレームワーク、ライブラリは、まずは公式チュートリアルから入ってみることをお勧めします。

あと、今回@circled9さんが前日にリリースされたばかりのVisual Studio for Macでぶっこんできて、「強い」と思いました。（ありがとう！）

 

.NET開発相談室

Niigata.NETの恒例コーナーにしていこうと目論んでおりますｗ

前回主催側がしゃべりすぎたため、今回は参加者の皆さんに多くしゃべってもらおうと思ったのですが、なかなかうまくネタを引き出せないものですね。それでも、なんとか四苦八苦してネタを絞り出し、あーだこーだ言える機会が持てたのは良かったです。

ただ、イベント終了後に「string型の変数の初期化をnullでやるのと空も時でやるの、どっちがいいんですかね？」みたいなことを聞かれ、「それをさっきの相談室で言ってもらえたら！」って思ったので、次回は「こんなのでいいんですよ」ってのを、もっと言ってかないとなぁと思った次第です。

 

そんな感じで、第3回の勉強会を終えました。今後はなんとか最低でも年2回ペースで開けるよう、いろいろと動いていきたいと思います。あと、主催側じゃないスピーカーの確保もぜひ。

 

なお、Niigata.NETでは「中の人」も募集しております！別にスピーカーをやれというわけではなく、イベント運営に必要な会場設営、受付、懇親会の手配など、色んな雑事の一部をお手伝いしていただけたらと思います。やってもいいよという方は、この記事へのコメント、Twitterでのメンション、ハッシュタグ#ngtnetを付けたつぶやきなど、何らかの手段でお知らせください。

テスト駆動開発（TDD） in .NET #ngtnet by @masaru_b_cl

コメントを残す

はじめに

このエントリは2016/5/7に開催したNiigata.NET 2.0で行ったセッションを再構成したものです。

 

ライセンス

クリエイティブ・コモンズ・ライセンス
この 作品 は クリエイティブ・コモンズ 表示 – 継承 4.0 国際 ライセンスの下に提供されています。

 

Agenda

 

テスト駆動開発（TDD）とは

テスト駆動開発とは、Kent Beck（ケント・ベック）が提唱した開発手法です。彼の著書であり、「原典」とも呼ばれる「テスト駆動開発入門」（http://www.amazon.co.jp/dp/4894717115）（残念ながら絶版。再販望む！）にはこのように書いてあります。

「動作するきれいなコード」、ロン・ジェフリーズのこの簡潔な言葉は、TDD（テスト駆動開発）の目標である。動作するきれいなコードは、あらゆる理由で価値がある。

それでは、どのように「動作するきれいなコード」を目指していくのでしょう？

 

TDDの進み方

まず、「動作するきれいなコード」にたどり着くには2つの道があります。一つはきれいなコードを書きながら動作するように直していくもの。もう一つは動作するコードを書きながらきれいに直していくものです。

（図は日本におけるTDDの第一人者である「和田 卓人（@t_wada）」さんのスライド「ＴＤＤのこころ」より拝借しています。）

TDDはこのうち後者の「着実に一歩ずつ進む道」をとります。つまりまず動くようにしてからきれいにしていきます。なぜこの道かというと、何はともあれ「動作」していなければ、製品としての価値はないということが一つです。

他に、この「動かない」→「動く」の線を超えるときに多くの「気づき」が得られるということもあります。フィードバックは早ければ早いほど修正が容易ですので、まずは動くように書き、フィードバックを得て素早く修正していくのがTDDということになります。

 

TDDのサイクル

TDDはこの着実な道を次のようなサイクルで進んでいきます。

  1. 次の目標を考える
  2. その目標を示すテストを書く（テストファースト）
  3. そのテストを実行して失敗させる(Red)
  4. 目的のコードを書く
  5. 2で書いたテストを成功させる(Green)
  6. テストが通るままでリファクタリングを行う(Refactoring)
  7. 1～6を繰り返す

そしてこの手順を小さく回すことで、素早いフィードバックを得ることができます。

これをTDDの界隈では「黄金の回転」と呼んでいます。これはくるくると回りながらどんどんと高みを目指していくイメージから、荒木飛呂彦先生の「スティール・ボール・ラン」に出てくる「黄金の回転」が連想されるため、このように呼ぶようになったそうです。

（スティールボールラン、荒木飛呂彦著より）

 

動作するきれいなコード

では、「動作するきれいなコード」とは何でしょう？それは原典の該当箇所の原文を見ればわかります。

「動作するきれいなコード」は「Clean code that works」であり「Beautiful」ではないのです。つまりは整頓されたコードがきれいなコードであるということになります。

とはいえ、もう少し具体的な指針が欲しいところです。そこで、「きれい」なコードとは何かを知ることのできる書籍をいくつか紹介します。

まずは「リーダブルコード」です。サンプルコードはC#など.NET言語ではありませんが、「リーダブル≒読みやすい」コードを書くためのテクニックに「名前」を付けて完結にまとめているため、最初に読む1冊としては最適です。

次に「リファクタリング」です。コードの挙動を変えずに構成を直す「リファクタリング」のテクニックについて網羅的にまとまっています。「きれいなコード」にどのように直せばよいのかを学ぶのによいでしょう。なお、この本もTDD入門と同じく一度絶版になりましたが、オーム社により再販されています。

これまでの2冊は実際のコードに近い話でしたが、「きれいな」コードは「きれいな」設計から生まれます。そのため、オブジェクト指向プログラミング言語を使ったアプリケーションの「設計」に関する原則を学ぶことも重要です。それを学ぶための書籍を2つ紹介します。

まずは「C#実践開発手法」です。これはその名の通り、C#を使っていわゆる「SOLID原則」と呼ばれるような設計原則を、実際にどのように使えばよいのか実例とともに紹介しています。こういった分野の書籍には「アジャイルソフトウェア開発の奥義」がありましたが、コードがJava（もしくはC++、Smalltalk）だったので、C#でコードが読めるというだけでも本書はありがたいです。もちろん、内容もより新しいものになっています。

そして、オブジェクト指向プログラミング言語の設計原則について学ぶなら「Head First デザインパターン」がおすすめです。本書のタイトルは「デザインパターン」となっていますが、実際はSOLID原則やハリウッド原則といった基本原則を学ぶのに最適な本だと私は思っています。サンプルコードはJavaですが、C#を知っていればそれほど苦も無く翻訳して読めるでしょう。

また、きれいなコードは既存のライブラリ等との統一感も重要です。特に.NET Frameworkは標準ライブラリが巨大なので、勝手なルールでライブラリを作ってしまうと、利用者が混乱してしまいます。

そこで、標準ライブラリの設計ガイドラインを知るために、「.NETのクラスライブラリ設計」も強くお勧めします。この本は単にライブラリ設計のガイドラインが書いてあるだけでなく、過去の失敗についての.NETの中の人の議論が掲載されていることもおすすめポイントの一つです。

 

TDDの目的

さて、こういった書籍などを参考にしつつも「きれいなコード」を目指すことがTDDの目標であることはすでに述べたとおりです。では、目標のさらに先にある「TDDの目的」はなんでしょうか。それは、一言でいうと「健康」です。

TDDはテストを書きますが、それは大きな目的を実現するための手段でしかありません。TDDで目標とするのは「動作するきれいなコード」は、すなわち「変化に対応」しやすいコードであるともいえます。

変化に対応しやすいコードは、言い換えれば不安が少ないコードだともいえます。ユーザーの要望をかなえるためには、コードを変化させなければいけませんが、「動作するきれいなコード」ならば、安心して変更することができます。

そして、この「不安が少ない」状態を一言で表せば、それが「健康」であるということです。

そして、「健康」なコードは不安が少ないため、開発者自身の「健康」にもつながります。一人一人の開発者が健康なら、チーム全体も「健康」であり、ひいては開発、運用している製品、サービスとその開発者、ユーザーなど関係者全員の健康にもつながります。

この大きな目的のために、まずは目標として「動作するきれいなコード」を維持するよう、TDDを行っていきます。

 

.NETにおけるTDD

TDDがどういうものかわかりましたが、.NET開発においてTDDをどのように進めていけばよいのでしょうか？次の4つの項目に焦点を当て、順に説明していきます。

  • テスティングフレームワークおよびサポートツール
  • ソリューション構成
  • テストコード
  • テスト実行

 

テスティングフレームワーク

まずは、.NETで使える主なテスティングフレームワークをいくつか紹介します。

まず最初は「MSTest」です。MSTestはVisual Studioに標準搭載されたテスティングフレームワークで、現在はExpress Editionでも使用できるため、お手軽さはNo.1です。

次は「NUnit」です。JUnitをはじめとした、いわゆるxUnit系列の正統派オープンソーステスティングフレームワークで、MSTestがＶＳの下位エディションに搭載されるまでは、デファクトスタンダードでした。

最後は「xUnit.net」です。上記2つより新しく、テストコードの書き方等を一から見直したテスティングフレームワークで、MSのASP.NETチームなどでは、最近のオープンソースプロダクトのテストに使用されています。

ではどのテスティングワークを選べばよいのでしょうか？個人的にはMSTestかNUnitをお勧めします。

MSTestは何といってもVSを入れれば入っているというお手軽さが一番で、必要最小限の機能はあるので、入門には最適だといえるでしょう。また、NUnitは歴史があることもあり、Web上の日本語情報も多く、MSTestよりは高機能（パラメタライズド・テストなど）です。

サポートツール

次にサポートツールについて見ていきましょう。まずは「テストアダプター」です。

MSTestは標準でVS上からテストを実行することができますが、その他のテスティングフレームワークは、専用のテストランナーを使う必要がありました。それを改善し、VSからテストを実行できるようにするのが、「テストアダプター」です。

テストアダプターを導入すれば、NUnitやxUnit.netのテストコードも、VS上から実行して結果を確認できるようになります。

また、テストコードの書き味を改善するため、「Chaining Assertion」というライブラリもお勧めです。

Chaining Assertionはテストコードの書き方を、A.Is(B)の形式で書けるようにします。MSTestの他、NUnitやxUnit.netにも対応しています。後で実例を出すときに、Chaining Assertionを使ったコード例を使って説明します。

 

ソリューション構成

次にTDDを行うソリューションの構成を見ていきましょう。.NETでTDDする場合、テスト対象プロジェクトとテストプロジェクトの複数プロジェクト構成にするのが一般的です。

まずテスト対象プロジェクトは*.exe形式の実行ファイルや*.dllのクラスライブラリどちらでも大丈夫です。ただ、クラスライブラリにする方が一般的ではあります。

そして、テストプロジェクトが別になるため、テスト対象の型は原則publicとします。internalな型についても、テスト対象プロジェクトにアセンブリ属性InternalsVisibleToを使い、テストプロジェクトに対してのみ公開することもできます。

次にテストプロジェクトですが、MSTestを使う場合は「単体テストプロジェクト」を選択します。他のOSSテスティングフレームワークを使う場合は、クラスライブラリプロジェクトを作成した後、使用するテスティングフレームワークへの参照を追加します。

 

テストコード

次にテストコードの構成を見てみましょう。今回はMSTest+前述のChaining Assertionを使ったテストコードについて説明します。


using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace Test.MSTest
{
[TestClass]
public class UnitTest1 //テストクラス
{
[TestInitialize]
public void SetUp() { /*テスト初期処理*/ }
[TestCleanup]
public void TearDown() { /*テスト後処理*/ }
[TestMethod]
public void TestSomething()
{
//テスト主処理
“実際の値”.Is(“期待する値");
}
}
}

view raw

TestCodeStructure.cs

hosted with ❤ by GitHub

まず、MSTestのテストクラスであることを示すため、TestClass属性をクラスに付けます。テストクラスはpublic出なければならないことに注意してください。

次に、実際のテストを行うメソッドにはTestMethod属性を付けます。テストメソッドもpublicとし、戻り値はvoid、引数はなしとします。テストメソッドは必要な数だけ複数個作ってかまいません。テストメソッド内では、実際の値と期待値が等しいことを、Isメソッドを使い検証します。

この他、それぞれのテストメソッドが実行される前に毎回実行したい処理、例えばテスト対象オブジェクトの初期化などは、TestInitialize属性のついた、いわゆるSetUpメソッドに書きます。同様に、テストメソッド実行後に毎回実行したい後処理は、TestCleanup属性のついた、いわゆるTearDownメソッドに書きます。

 

テスト実行

こうして作成したテストコードは、Visual Studio上から実行すると、「テストエクスプローラー」にテストメソッドごとに成功、失敗、そして失敗ならその失敗した箇所の情報が表示されます。

このようにして、VS上でテストを行っていきます。

 

TDDの実例

それでは、実際にTDDを行っている様子の実例を見せましょう。今回はFizzBuzzを題材として使用します。作成したコードは、GitHubにアップしているので、併せて参照してみてください。

 

設計

まず最初に行うのは「設計」です。作成するプログラムの仕様を元に、ざっと設計して必要と思われるタスクをToDoリストとして作成します。最初にこの工程を行うことで、事前の目標付けとともに、仕様であいまいな部分やどのようにテストを行うのかといった不安要素をなるべくなくします。

 

最初のテスト作成

ToDoリストを作成したら、その中から一つ選び最初の「失敗する」テストを作成します。今回は「正の整数の場合、その数値を文字列で返す」を選び、このことをテストするために「引数が1の場合、”1″を返す」ことを確認するテストコードを書きます。

この時、自分が「最初のユーザー」となり、使いやすいAPI設計を考えることが重要です。それには、型名やメソッド名、引数の名前や型、戻り値の型など、様々な観点があります。

今回はまずテスト対象プロジェクトFizzBuzzとテストプロジェクトFizzBuzz.Testを作成し、FizzBuzz.TestプロジェクトにFizzBuzzTest.csを追加してFizzBuzzTestクラスを作成しました。なお、テスティングフレームワークにはMSTestを使い、Chaining AssertionをNuGet経由でインストールしています。

PM> Install-Package ChainingAssertion


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace FizzBuzz.Test
{
[TestClass]
public class FizzBuzzTest
{
[TestMethod]
public void 引数が1の場合文字列で1を返す()
{
// arrange
var fizzBuzzer = new FizzBuzzer();
// act
string result = fizzBuzzer.Say(number: 1);
// assert
result.Is("1");
}
}
}

view raw

FizzBuzzTest.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/af2891d63f95b2ea60c88e643b335d0ca14159bd/FizzBuzz.Test/FizzBuzzTest.cs）

.NET開発で最初のテストコードを書く時のポイントは以下の通りです。

  • 戻り値の型を明示する
  • 引数の型を明示する
  • 名前付き引数で引数名を明示する

こうしておくことで、次のフェーズを行う際、VSの機能を使ってコードを自動生成できます。

またこの他、テストコードは適宜日本語で書くことで、その意図がわかりやすくなることもあります。特にC#はメソッド名に使える文字が限られているため、日本語の表現力に頼るのは理にかなっています。

 

最初のテスト失敗

テストコードを作成したら、テストを実行して失敗することを確認します。ここではテストの役割のうち「正しく失敗する」ことを確認することが重要です。

なお、「最初の失敗するテスト」の失敗にはコンパイルエラーも含めてよいです。この段階ではFizzBuzzerクラスは無いのでコンパイルエラーになるはずです。

 

仮実装（Fake It）

テストが正常に失敗することを確認したら、いよいよテスト対象コードの実装に入ります。まず最初に行うのは、「仮実装（Fake It）」です。仮実装とは「テストが成功する最速の実装」のことで、リテラル定数を使ってテストが成功するように書いてしまいます。最初に作成したテストコードであれば、戻り値として”1″を返せば、テストが成功するはずです。

一見意味がないようにも見えますが、この手順には失敗しようのない状態で「テストが正しく成功する」ことで、テストの妥当性を担保するという目的があります。もし仮実装でもテストが失敗するようなら、その後本当の実装にしてもテストが成功するわけはないのですから。

VSで仮実装を行う際、まずはテストコードからテスト対象クラスを生成します。コンパイルエラーとなっているFizzBuzzerクラスの箇所でCtrl+.キーを押し、「新しい型の生成…」を選択します。

generate-class

そして、表示された「型の生成」ダイアログにて、「種類」にclass、「場所」にFizzBuzzプロジェクト、そして「ファイル名」に”FizzBuzzer.cs”を指定して「OK」ボタンをクリックします。

generate-class-02

すると指定した通り、FizzBuzzerクラスがFizzBuzzプロジェクトのFizzBuzzer.csファイルに作成されます。


namespace FizzBuzz
{
public class FizzBuzzer
{
public FizzBuzzer()
{
}
}
}

view raw

FizzBuzzer.cs

hosted with ❤ by GitHub

次に、FizzBuzzTest.csに戻り、コンパイルエラーとなっているSayメソッドの生成を行います。Ctrl+.を押し、「メソッド ‘FizzBuzzer.Say’ を生成します」を選択します。

generate-method

すると、未実装のメソッドSayが生成されます。


using System;
namespace FizzBuzz
{
public class FizzBuzzer
{
public FizzBuzzer()
{
}
public string Say(int number)
{
throw new NotImplementedException();
}
}
}

view raw

FizzBuzzer.cs

hosted with ❤ by GitHub

テストクラスで引数名、型、戻り値の型を明示していたことで、それに合わせたシグネチャでメソッドが生成されます。

最後に、Sayメソッドが1を返すように仮実装すれば終了です。


using System;
namespace FizzBuzz
{
public class FizzBuzzer
{
public FizzBuzzer()
{
}
public string Say(int number)
{
return "1";
}
}
}

view raw

FizzBuzzer.cs

hosted with ❤ by GitHub

(https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/b89706c18621ab0302e3fe524539281e0a4cdd39/FizzBuzz/FizzBuzzer.cs)

この時、FizzBuzzTest.csファイルのSayメソッド呼び出しか所でAlt+F12を押すことで、「定義をここに表示」すると便利です。

peek-definition.jpg

 

最初のテストの成功

 

テストを実行し、成功することを確認します。Ctrl+R, Aキーを押すことで、すべてのテストを実行できます。

success-first-test.jpg

無事テストが成功しました。

 

リファクタリング

テストが成功したので、今度はリファクタリングです。テストが成功する状態を保ったまま、コードを整理します。言い換えれば、挙動を変えずに構造を改善するということです。

なお、テストコードを整えるのもリファクタリングの一つです。ここでは、テストコード内で明示した型や引数名を取り除いてみましょう。


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace FizzBuzz.Test
{
[TestClass]
public class FizzBuzzTest
{
[TestMethod]
public void 引数が1の場合文字列で1を返す()
{
var fizzBuzzer = new FizzBuzzer();
fizzBuzzer.Say(1).Is("1");
}
}
}

view raw

FizzBuzzTest.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/42483eb7eaa217d80440a026572ffd211bb3ddab/FizzBuzz.Test/FizzBuzzTest.cs）

コードを変更したら、テストを実行して成功することを確認しておきましょう。

 

次の失敗するテストを追加する

先に進むため、「小さな一歩」となるような新たなテストを追加します。この時、先ほど仮実装したメソッドにて、同じ仕様を満たすもう一つのテストコードを追加することで、実装1点に対してテスト2点の「三角」で進めることを「三角測量」と呼びます。今回の例でいえば、「正の整数の場合、その整数を文字列にして返す」という仕様に対して、最初に作った1を”1″にして返すテストに加え、2を”2″にして返すかどうかを確認するテストを追加することで、三角測量を行います。

 


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace FizzBuzz.Test
{
[TestClass]
public class FizzBuzzTest
{
[TestMethod]
public void 引数が1の場合文字列で1を返す()
{
var fizzBuzzer = new FizzBuzzer();
fizzBuzzer.Say(1).Is("1");
}
[TestMethod]
public void 引数が2の場合文字列で2を返す()
{
var fizzBuzzer = new FizzBuzzer();
fizzBuzzer.Say(2).Is("2");
}
}
}

view raw

FizzBuzzTest.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/f21f34237754464babe6e6746a7f52df94295f4b/FizzBuzz.Test/FizzBuzzTest.cs）

 

すべてのテストを実行

テストを追加したらすべてのテストを再実行し、追加したテストだけが失敗することを確認します。もしこの時複数のテストが失敗するようであれば、それは良くない設計であることを示す臭いです。「良くない」とは仕様でなく内部実装に対してテストしている、責務分割が不十分で一つの変更があちこちに影響するような作りになっている可能性が高いのです。

failure-second-test

無事2つ目のテストだけが失敗しました。

 

テストが成功するまで修正

あとは、失敗した2つ目のテストについて、テストが成功するまで実装を行います。このとき、仮実装で使用した定数、リテラルを、引数や変数を使うように直します。サンプルでは、Sayメソッドの引数numberを文字列にして返すようにします。


using System;
namespace FizzBuzz
{
public class FizzBuzzer
{
public FizzBuzzer()
{
}
public string Say(int number)
{
return $"{number}";
}
}
}

view raw

FizzBuzzer.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/f21f34237754464babe6e6746a7f52df94295f4b/FizzBuzz/FizzBuzzer.cs）

 

修正後にテストを実行し、2つのテスト両方が成功することを確認します。

success-second-test

 

再びリファクタリング

2つのテストで共通で使っているfizzBuzz変数をフィールドにしてSetUpメソッドで初期化したり、整数が整数の文字列を返すテストは一つあれば十分なので、一方を消したりします。


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace FizzBuzz.Test
{
[TestClass]
public class FizzBuzzTest
{
private FizzBuzzer fizzBuzzer;
[TestInitialize]
public void SetUp()
{
fizzBuzzer = new FizzBuzzer();
}
[TestMethod]
public void 引数が正の数の場合文字列でその数を返す()
{
fizzBuzzer.Say(1).Is("1");
}
}
}

view raw

FizzBuzzTest.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/f3ffd123918d51a20a2e6cb8b4892097a9adccbe/FizzBuzz.Test/FizzBuzzTest.cs）

テストを実行し、成功することを確認します。

 

ToDoリストを更新する

ここまでで事前に作成したToDoリストの最初の仕様の実装が終わったので、完了したタスクを消してしまいます。

 

次のテストを追加する

今度は別の仕様について実装していこうと思うので、次のテストを作成し、追加します。3の倍数のテストを追加してみます。


using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
namespace FizzBuzz.Test
{
[TestClass]
public class FizzBuzzTest
{
private FizzBuzzer fizzBuzzer;
[TestInitialize]
public void SetUp()
{
fizzBuzzer = new FizzBuzzer();
}
[TestMethod]
public void 引数が正の数の場合文字列でその数を返す()
{
fizzBuzzer.Say(1).Is("1");
}
[TestMethod]
public void 引数が3の倍数の場合Fizzを返す()
{
fizzBuzzer.Say(3).Is("Fizz");
}
}
}

view raw

FizzBuzzTest.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/f4b7c5a74d3ccada1787a583b96ab66d613705e4/FizzBuzz.Test/FizzBuzzTest.cs）

 

明白な実装

実装が自明である場合、仮実装をスキップしてしまっても構いません。これを「明白な実装」と呼び、イメージとしては開発スピードアップのため、ギアをあげるイメージです。今回は引数を3で割った余が0の時に”Fizz”を返すよう実装します。


using System;
namespace FizzBuzz
{
public class FizzBuzzer
{
public FizzBuzzer()
{
}
public string Say(int number)
{
if (number % 3 == 0)
{
return "Fizz";
}
return $"{number}";
}
}
}

view raw

FizzBuzzer.cs

hosted with ❤ by GitHub

（https://github.com/masaru-b-cl/ngtnet2-fizzbuzz/blob/da6c8c0288634b67789fcfa17965bf4ff761910c/FizzBuzz/FizzBuzzer.cs）

 

以上のような手順を繰り返して、ToDoリストの項目を全部消したら、実装が完了したということになります。

 

TDDの指針

最後に、TDDを行う上でのいくつかの指針を紹介します。

 

いつTDDを行うか

まず、「いつ」TDDを行えばよいのかというと、それは「不安」を感じたとき、ということになります。例えば、ライブラリの使い方に自信がなかったり、第三者の実装が信用できない時など、開発に関連する不安があれば、それをテストで保護してあげるのです。

ただし、今作成しているのが「使い捨て」のコードであれば、TDDを行わない方が良いこともあります。テストコードを作成しても、そのテストが数回しか実行されないようであれば、テストはただのコストでしかありません。

その他、GUIのコードについてはTDDを行いません。GUIの自動化テストを作成するには非常に手間がかかり高コストな作業です。しかし、GUIは一番ユーザーに近いところであることから、変更が頻繁に起こります。そうすると、せっかく作ったテストもすぐに変更しないといけなくなってしまいます。

また、トライ＆エラーであれこれ試すような時もTDDは向いていません。ただし、あれこれ試した結果、確定した実装に対してテストを書いても問題ありません。「テストファースト」にはこだわらなくても大丈夫です。

 

どんなテストが良いテスト？

一般的に「良い」とされるテストの特徴に「F.I.R.S.T」と呼ばれるものがあります。

  • Fast（高速）
    テストの実行がすぐ終わること
  • Independent（独立している）
    他のテストへの影響がなく、任意のテストメソッド単体でも実行可能であること
  • Repeatable（繰り返し実行可能）
    何度実行しても同じ結果となること
  • Self-Validationg（手動での検証がない）
    テストコードのみでテストが完結していること。
  • Timely（テストファースト）
    最初にテストを書いていること

これら5つの特徴には優先度があり、特に重要なのはIとR、続いてF、S、Tです。少なくともIとRだけは考慮したテストを書きましょう。

 

どのようにテストを行うか

ToDoリストを元にどのようなテストを行えばよいのかについては、各種のテスト技法を参考としましょう。基本的なテスト技法として、同値クラス、境界値分析くらいは考慮したテストを書きましょう。

 

既存コードがある場合

「テストがないコードはレガシーコードだ！」のキャッチコピーでおなじみの「レガシーコード改善ガイド」を参考に、小さく初めて少しずつ範囲を広げていきましょう。

 

最後に

最後に大事なことですが、TDDはあくまで「センス」ではなく「スキル」です。訓練次第で誰でも習得画家のなものなのです。たまに「テストが書けるようになったらTDDをやってみよう」みたいなことを聞くことがありますが、「できるようになったら始める」というのは永遠に始めることはできません。まずは始めてみて、うまくいかなければ直せばよいのですから。

また、本来はチームを巻き込んだ形TDDができるのが理想ですが、まずはあなた一人でも始めることができます。やってみて、良いものであれば他の人に勧めて、徐々にTDD人口を増やしていきましょう。

そして、TDDによって安心を得て、「健康になりましょう」

 

参考資料

 

Niigata.NET 2.0を開催しました #ngtnet

コメントを残す

Niigata.NET 2.0 | テックトーク＆.NET開発お悩み相談室 – Niigata.NET | Doorkeeper

GWの終わりの5/7（土）にNiigata.NETの第2回勉強会を開催しました。

今回は前半は普段のテックトーク、後半は参加者の皆さんから普段の開発で困ったことなどについて、みんなで考えようなお悩み相談室としました。前回は初回ということで遠方よりご参加いただいたりと半ばお祭りでしたが、今回は地元参加者のみでの比較的少人数での会となりました。

テックトーク

考える、プログラミング初級講座 C#編 by @AILight

1つ目のテックトークは、越後が誇るMS MVPである@AILightさんによる、「変数」に絞ったC#入門でした（資料はアップされていないようです）。始めるまえに「時間が読めない」と公言していた通り、1時間半を超える大規模セッションになりましたf(^^;

ポイントを絞って振り返ってみます。

まず、C# ステップアップに大切なこととして次の3つを挙げています。

  1. 言語仕様を学ぶ
  2. ランタイムを学ぶ
  3. 短く書くようにする

C#の言語仕様については、最近はコードネームRoslynこと「.NET Compiler Platform」がオープンに開発が進んでいることもあり、ちょっと追うのが大変です。C# 5.0までくらいなら、VSのインストール先に入っているので、まずこちらで確認して、最新仕様は別途「C# によるプログラミング入門」などのサイトで確認するとよいと思います。

VS2015なら、言語仕様は以下のフォルダーにあります。

C:\Program Files\Microsoft Visual Studio 14.0\VC#\Specifications\1041\CSharp Language Specification.docx

次に変数の使い方として以下の3つを挙げています。

  1. 宣言
  2. 代入
  3. 参照

これらについて、実際の「自分のルール」含めて、変数名やvar使うか問題、多次元/ジャグ配列の宣言と初期化などについて語ってくれました。それらの中で、私も真似しようかなと思ったルールが一つあって、それは「変数名略すな」です。

よくこんなコードを書いてしまいがちです。


var client = new HttpClient();
client.～

ですが、ただの「client」ではもし今後HTTPSクライアントが増えたらどうするのか？といった視点から避けるべきという主張でした。その代わり、


var httpClient = new HttpClient();
client.～

のように、型名をcamelCaseにしたので良いのではということでした。

こんな感じで、「変数」だけでこれでもか、これでもかと大いに語ってくださいました。

テスト駆動開発（TDD） in .NET by @masaru_b_cl

私のセッションです。内容はスライドを参照ください。後日補足を加えて別途エントリにもまとめるつもりです。

私のセッションもデモ入れたりして少し長くなってしまいました。やはり資料をぎりぎりに作成するのはだめです……。

質疑応答は記憶している範囲ではこんな感じでした。

  • DB絡んだテストはどうするのか？
    • SetUp等でDB接続してデータをこしらえてテストしている
    • FastであることよりもIndependentでRepeatableな方が価値が高いので問題なし
  • いわゆる「単体テスト」に流用できないのか？
    • TDDのユニットテストは「開発者テスト」であり、品質保証を目的とするテストとは違うもの
      • 流用できる部分もあるかもしれないがそれほど多くない
    • 品証の単体テストは、単一コンポーネントというよりは各種コンポーネントを組み合わせて「ユースケース」を元に設計する
  • privateなメソッドのテストはやるのか？
    • privateなものはpublicなメソッドを通じて行う
      • privateなものは実装に近すぎて簡単にテストが壊れるため
    • そのためTDDもユースケースを考慮したテストを行う方がよい
    • もしprivateなメソッドをテストしたくなったら、単一責務の原則に従い責務分割のチャンス

 

.NET お悩み相談室

そして、今回のメインだったはずが、テックトークでだいぶ時間が押してしまい、30分くらいしかできませんでした。

出た話題としてはこんな感じだったかと。

  • 現在WinFormsのクラサバアプリを型付DataSet+TableAdapterを使って作っているが、EFにした方がよいのか？
    • MSのリソースはEFに集まっている
    • DataSetのように非接続型アクセスするには、ひと工夫必要
  • .NET関連の最新情報キャッチアップはみんなどうしているのか？
    • 最新情報を追っている人をSNS等でウォッチする
    • MSのドキュメント、チュートリアルを参考に手を動かす

時間がなかったので、正直消化不良気味でした。ぜひリベンジしたい。

 

全体を通じて

今回は参加者が地元の方だけということもあり、比較的おとなしい印象でした。また、TwitterをはじめとしたSNSのアカウントも持っていないような人が大半なのか、#ngtnetのTLは大変寂しいものになってしまいました。

今後に向けては、幹事の@AILightさん、@84taka0310さんとも相談していきますが、講師と生徒のような関係ではなく、もっと参加者の皆さんにガツガツ来てもらえるようなコミュニティにしていくため、何ができるか考えていかなくてはと思いました。地元の中小SIベンダーの一社員といった人に、どうやって動機づけしていくかは、地方コミュニティはどこでも同じ悩みを抱えているかもしれませんね。

 

次回について

少なくとも年2回の開催を目指すため、次回は10月あたりを予定しています。また日取り等決まったら告知します。

Niigata.NETを開催してきました #ngtnet

1件のフィードバック

Niigata.NET 2015-10 – Niigata.NET | Doorkeeper

先週土曜日の10/10に、新潟県初（？）の.NETな勉強会を開催してきました。

イベント運営について

会場について

今回の会場は「まちなかキャンパス長岡」を利用させていただきました。この施設は、長岡市民が非営利目的でこういったイベントのために利用する場合、なんと無料で利用できます。

なんと、無料で利用できるのですよ！！！（大事なことなので二度言いました。）

ただ、この好条件のため非常に競争が厳しく、予約開始となる３ヶ月前の月初には、朝一で電話してもなかなか繋がらずに大変でした。なんとか繋がったらすでに最初に狙っていた部屋は予約で埋まっていましたし。今後もこの会場を使うのであれば、こういった事情も考慮して何はともあれ会場を抑えるのが重要となっていきます。

会場の広さについては、少し手狭だったと反省しております。Max30人の会議室に22名の参加があったため、3人掛けテーブルにきっちきちに座っていただかないといけませんでした。やはり狭くパーソナルスペースを守れないため、少し不快な思いをさせてしまったのではと思います。申し訳ありませんでした。次回はもう少し広い部屋を検討します。

参加者募集について

最初は全然人が集まらなくて、スピーカーと関東の重鎮の方々しかいないという状況がしばらく続きました。そのため、自分の職場に声をかけてみたり、石野さんのパワーによりいろいろ調整していただいたりした結果、最終的には22名もの方にご参加いただけました。

私もtwitterやfacebookを中心にアナウンスはしてみましたが、普段リーチしない層にいかにイベントがあることを届けるかが今後の課題となります。

また、今回Doorkeeperを使ってイベントおよびその後の懇親会の参加者登録を行っていただきましたが、Doorkeeperの操作ミスなのか、事前に登録されていなかった方が１名いらっしゃいました。これは正直しょうがないことなので、運営側はこういった事態もあるということを想定しておく必要があると認識する良い機会となりました。

また、懇親会については当日になってかなりの人数増加があり、懇親会会場と幹事をお願いした方にご迷惑が掛かってしまいました。同じくDoorkeeperから事前のリマインダーを送るなどはしていましたが、返答必須としていたわけはないので、今後は変更がなくとも確認を行っていく必要性を感じました。

当日の進行について

最初は良かったのですが、セッションの中で参加者の方とのやり取りが結構発生したこともあり、それぞれ少しずつ時間が伸びてしまったため、LTを予定していた山Pさんの分を削ることとなってしまいました。セッション中に参加者との意見交換が起きることは、個人的には良いことだと思っていますので、やはりもう少し余裕を持ったスケジューリングと、セッション時間を事前にもう少し取り決めるなどして、今後は回避していきたいと思います。

ちなみに、このスピーカーと参加者の意見交換については、「内輪でなんかやってる」感が出てしまうという面もあります。特に今回は関東からいらっしゃったマスターの方々は勉強会慣れしており、こういったことに抵抗がないのですが、初めて参加したような方には異質に見えたかもしれません。こういった事態については、コミュニティとしてどういう方針で行くのか、改めて議論して今後の運営に反映させていこうと思います。

MSノベルティについて

今回MVPである石野さんを通じて、マイクロソフト様よりノベルティをいただきました！本当にありがとうございました！

この他、MSマークの入った金太郎飴も大量にいただきました（写真なし）。見た目がかわいいだけでなく、美味しいと家族にも好評でした。

ビッグなノベルティである「プログラミング Windows 第6版 上」2冊は、石野さんと私相手の壮絶なじゃんけん大会の結果、上記の片桐さんと@ma_2_iさんが獲得されました。おめでとうございます！

http://twitter.com/ma_2_i/status/652763225075904512

セッションについて

業務アプリケーション開発を支える.NET技術（@masaru_b_cl）

私のセッションです。

前半のNuGet、MSBuildについては、その利点を伝えられたかなと思います。後半の実装面については、急に難しくなって参加者を置いてきぼりにした感がありましたので、もう少し必要性や実装方法のわかりやすさを伝えられる説明の仕方を検討する必要があります。

なお、MEF、WCFのサンプルはこちらから参照ください。

masaru-b-cl/ngtnet-2015-10 – GitHub

このイベント最初のセッションということもあり、参加者の皆さんとやり取りしながら進めることを意識していました。関東勢の皆様には本当にやいのやいのとご協力いただき、感謝しております。覚えている範囲で、どんなやり取りがあったか書いておきます。

  • NuGetは便利そうだけど、ローカル環境でも使えるのか？
    • ファイルサーバー上の共有フォルダーをリポジトリーとすることができる
  • MSBuildをコマンドラインオプションでターゲット指定して実行しないのか？
    • あくまで実行はbatファイルで行い、その中でターゲット指定などオプションを切り替えるのはありだと思う
      • なるべく誰でもできるようにするため
  • WCFの非同期処理のTaskの対応状況は？

Windows10体験記 ― これ、どうやって動いてるの？（@84taka0310）

山Pさんのセッション。

途中懐かしのWindowsとの対比が出てきたり、Spy++で最新のWebブラウザーであるMicrosoft Edgeに潜ってみたりとなかなか面白かったです。

個人的なツボはこちら。

アプリしか作れないけどAzureに触ってみた（@nemuzuka）

片桐さんのセッション。

VPSで動いているApache->Tomcat->Scala->PostgreSQLなサービスを、BizSparkを利用したAzure Web Apps -> Azure VMな環境に乗せ換える話で、個人的には今回一番面白かったです。

特に仮想ネットワークの辺りは、以前私もちょっとだけ触ってみてよくわからなくて挫折したこともあったので、こうやって設定すればよいのかと非常に勉強になりました。

今回は特殊な事情によりAzure VMを使わざるを得ないため、BizSparkのAzure利用無料枠をオーバーしてしまったそうですが、ぜひ無料枠で収まる構成でリベンジしていただき、その成果を公開していただけたらうれしいです。

大人の基礎C#（@AILight）

もう一人の主催であるMicrosoft MVP for Visual Studio and Development Technologies（長い）の石野さんのセッション。

C#という言語の歴史と、最近のモダンで便利な機能の紹介＆デモでした。我々のようなC#erには良いおさらいに、未経験or初心者には新鮮に映ったのではないでしょうか。

また、C#の話だけでなく、どのようにプログラミングを上達させていくかということにも触れていて、初心者の方には良いとっかかりとなったと思います。「エアコン」クラスを設計してみるなどは、さらに進めてインターフェースの理解などにもつながるので、ぜひ私もお勧めしたいです。

ただ、イベント時間自体が押していたこともあり、資料の半分くらいしかできなかったことは残念でした。ぜひ次回に続きを行っていただけることを心待ちにしております。

LTについて

石坂さん

つい先日リリースされたVS2015 Update 1 CTPおよびC# Interactive（CSI）の話でした。なんとデモしようとしたらCSIが動かないというトラブルが発生！これは実際に自分で動かしてみないといけませんね。

CSI自体は「ようやく」といった感じで心待ちにしていた人も多そうです。LINQPadと併せて活用していきたいですね。

石坂さんにはこの他、うなぎパイとお菓子のお土産までいただき、本当にありがとうございました。

間島さん

Windows女子部の方によるAzure VMにマインクラフトサーバーを立てて遊ぶ話でした。

そんなWindows女子部のイベントが開かれるようですので要チェック！

Windows女子部IT秋祭り ~電子工作のワークショップお申込み枠~｜EventRegist（イベントレジスト） 

柏崎ワロタロさん

JavaScript+WebGLを使った「動く壁紙」を、TypeScript+WebGLに変換後、TypeScript->C++とコンバートしてAndroidアプリなどにした話でした。

あ…ありのまま 今　起こった事を話すぜ！（ｒｙ

実際のコンバートに際しては、TypeScript内にコメントでメタ情報を埋め込み、DSLを構築していた感じでした。なんというか、突き抜けていますね（褒めてます）。

近江さん

Azure StorageのData Movement Libraryの内部動作について、どうやって高速化しているか紹介してくださいました。残念ながら、これから本題というところで時間切れとなってしまいましたが、一般的な高速化戦略について簡単に知ることができてよかったです。

[※追記]
ご自身のblogに解説エントリが掲載されました。

Niigata.NET Page Blob Download 最適化 — Kyrt Blog

懇親会について

懇親会は「十字路」で執り行いました（幹事のいしばしさん、ありがとうございました）。このお店は8種の越後の地酒が飲み放題に含まれるという太っ腹ぶりが素晴らしく、関東勢へ大いに振る舞わせていただきました。

懇親会では各自様々な話題に花咲き、楽しいひと時を過ごせていただけたものと思います。私としても、マスター各位と深い話ができて非常に良かった。

二次会は「煉瓦亭」に移動し、「コードレビューを含んだコーディングイベントはどうか？」、「git bisect便利だよ」、「業務アプリなら各プロジェクト単位でリポジトリ化してNuGetでつなぐのが良い。デバッグシンボルはNuPeekで配る」など、さらに濃いい話で最高でした。そんな話をしていたら、こんなトラブルもありましたが…

http://twitter.com/hidori/status/652831948042276864

ともかくも、こういったガチ話、特に.NETでは普段なかなかできないので、とっても楽しい時間を過ごすことができました。皆さんありがとうございました。

今後の活動について

まだ白紙状態ですが、定期開催することを目指して石野さんをはじめとした県内.NETerと相談しつつ、できる範囲でゆるゆると行きたいと思います。今後ともご協力をいただければ幸いです。

Niigata.NETを開催します！

コメントを残す

Niigata.NET 2015-10 – Niigata.NET | Doorkeeper

ついに新潟県に.NETコミュニティが誕生しました。その誕生を記念して、最初の勉強会を開催します！

Niigata.NETとは

.NETを始めとして、Microsoftの製品、テクノロジー、サービスについて、新潟県のIT開発者を中心とした情報交換を主な目的とするコミュニティです。

というわけで、新潟県初（？）の.NET勉強会を開催します！皆さま、お誘いあわせの上、こぞってご参加ください！

第41回 長岡IT開発者勉強会に顔出してきた #nds41

2件の返信

第41回勉強会(2015/04/11) – 長岡 IT開発者 勉強会(NDS)

に参加したかったのですが、子守の事情により最後だけ顔出してきました。

イベントの様子は以下のtogetterからご覧ください。

#nds41まとめ – Togetterまとめ

 

LT

私は到着後にLTを無茶振りされ、スライドもなんにも用意してなかったのですが、「新入社員研修の作り方」で一本しゃべってきました。この内容はまた別の機会にちゃんとまとめようと思います。

ハイライト

https://twitter.com/2G_KSK/status/586804553531596800

 

懇親会

終了後は会場を「いさり火」に移し、懇親会です。今月で新潟を離れる@neko_gata_sさんを全力で送り出してきました！私もすでにアラサーからミドルサーティにクラスチェンジしたので、今後の身の振り方を考えるのに良い、熱くて濃い話をできてとっても良かった。

というような感じで、楽しく過ごせました。

 

宣伝

長岡IT開発者勉強会ではゆりかごからミサイルまでゆるーい感じで参加者を大募集中です。
イベントスケジュールはこちらをチェック！

長岡 IT開発者 勉強会(NDS)