うさぎ組

ReSharperでは成功するけど、NUnit GUIでは失敗するときのチェックリスト(になる予定)

NUnit, ReSharper | 15:15 |

App.configがパスに通っていない。

テストプロジェクト直下にApp.configをつくっていて、テストでその内容を参照しているときにこの現象でハマることがあります。

ReSharper、TestDriven.NETはVS上から実行できるためか、この辺のパスを綺麗に解決しますが、NUnit GUIでテストを実行するときは出力ディレクトリにApp.configが存在しないと失敗します。

テストのDLLが「Foo.BarTest.dll」となるときは「Foo.BarTest.config」という名前でコピーする必要があります。

具体的には、次のコマンドをテストプロジェクトの「ビルド後イベント」に追加しておきます。

copy $(ProjectDir)App.config $(TargetDir)$(TargetName).config 

ツイートする

JenkinsのView(ジョブ一覧)を並べ替える方法

Jenkins | 09:14 |

Jenkinsのトップ画面にあるViewのジョブ一覧をはデフォルトだと名前順にならんでいます。

これを並べ替えたいときは各項目をクリックすれば昇順、降順となります。

上の写真の赤枠になっているところです。

項目を少なくしたい

Jenkinsのビューでカラムや項目を少なくしたり、少なくした上で並べ替えたいときは新しいビューをつくりましょう。

ビューのタブの「すべて」の右側に「+」があるのでクリックすると新しいビューを作成できます。

作成画面で名前を入力して、「リストビュー」を選択するとビューの変更という画面に遷移します。この画面で表示したい項目（カラム）を好きなように追加、削除できます。

あとは保存して、トップページからそのビューを開いて、並べ替えたいカラムをクリックするだけです。

ツイートする

Jenkins Plugin開発にはMaven3を使う

jenkins | 13:00 |

だいぶ前に使ってそれっきりだった開発環境でJenkins Plugin開発をしようとしたときに、なぜかPluginが有効にならない問題が発生しました。

結論から言うと、Maven-2.2.1ではなく、Maven-3.0.5を使えば解決しました。

経緯

1. Macで開発したJenkins PluginをBitBucketにリポジトリをつくってWindowsで開発をしようとした。
2. WindowsにはJenkins1.43x時代にPlugin開発した名残があったので、そのまま開発を継続した。以下はWindows上での話。
3. mvn installは成功する。
4. mvn hpi:runが失敗したが、~/.m2/settings.xmlが古いとのことでJenkinsのWikiにあるsettings.xmlに更新。
5. mvn hpi:runでJenkinsが起動するのでアクセス。
6. プラグイン管理のインストール済みにはインストールされていることを確認。
7. 設定画面に対象のプラグインの項目がない。

解決できた経緯

Twitterで困った困ったってツイートしていたら

ということで、Maven3にしたら解決できました。

MacはデフォルトでインストールされているのがMaven3なのでうまくいったのかもしれません。

ツイートする

JenkinsからRedmineのチケットをクローズとかするPluginつくったった

Jenkins, Redmine | 01:15 |

公開場所

BitBucket:【 BaseReality6thLayer / RedmineRest — Bitbucket】

バイナリ:【Dropbox - RedmineRest.hpi】

できること

ジョブが成功したときにコミットコメントに含まれているチケットを特定のステータスに更新します。

RedmineのREST APIを使って更新しにいきます。

コミットコメントは「close refs #12」みたいな感じです。複数のチケットを指定する場合は「close refs #12 #13」みたいな感じです。「close refs」までは固定です。

対象のRedmineと更新させたいステータスはJenkins全体とジョブの両方で設定できて、ジョブの設定が空文字の場合はJenkins全体の設定を使うようになっています。

インストール方法

バイナリをダウンロードして、Jenkinsのプラグインの管理 -> 高度な設定 と遷移し、「プラグインのアップロード」するからRedmineRest.hpiをアップロードしてください。

Jenkinsを再起動するとインストールされるはずです。

設定方法

1. RedmineのREST API有効化
   1. Redmine（たぶん）1.0以降であれば大丈夫です。REST APIを使うので、管理 -> 設定と遷移し、認証タブの「RESTによるWebサービスを有効にする」のチェックを有効にしてください。
2. Redmine REST APIアクセスキーのメモ
   1. 管理者ユーザーの個人設定画面から右側にある「APIキー 表示」をクリックして表示される英数字をメモしておきます。
3. Jenkinsからチケット自動更新するときの自動更新後のステータスのIDをメモ
   1. 管理 -> チケットのステータス と遷移し、更新後の状態にしたいステータスをクリックするとステータスの編集画面に遷移します。このとき開かれるURLの末尾が「issue_statuses/4/edit」などとなっています。この最後から2番目の数字(ここだと4)がIDになります。文字列でも指定出来るのですが、文字化けとか対処する必要がでそうなので、ID指定にしました。
4. Jenkinsでシステムの設定から「Redmine Rest」を設定する
   1. RedmineのトップページのURLと2と3でメモした値をそれぞれ「Redmine URL」「API Access Key」「Status ID」に設定します。「Project Name」は今の機能では設定する必要ないのですが、今後追加する機能（チケットの自動作成）などで使うので先に項目だけあります。
5. 自動更新したいジョブの設定でRedmine Restを有効にする
   1. ジョブの設定画面で「ビルド後の通知を追加する」から「Redmine REST」を選択してください。先の設定と同じ項目が出ると思います。ここで設定をすると、先の画面で設定した値が上書きされます。必要がなければ特に値を設定しなくても大丈夫です。

実行

ビルドを実行すればおkです。ただ、コミットコメントは「変更」から取得しているので、「前回のビルドとリビジョンに差のないビルド実行」はJenkinsが変更として検知しないので、今回のプラグインは動作対象外になります。

つまり、「新しいコミットにおいて、close refs #xxx となっているときにビルドが成功すればそのチケットを任意のステータスに更新する」という感じです。

現状とか今後

まだまだ追加したい機能があるのですけど、まぁとりあえず動くものを触ってもらえる人がいそうなので使いにくい状態ではあるけど、公開しました。

なので手動でちょこちょこと動かしたくらいしかテストしていません。動作に問題があれば連絡ください。直します。

今後追加したい機能は

「ユーザーが指定した正規表現でマッチ」と「更新後のステータス」を1セットにしていくつも指定できるようにする。

「ビルドのステータスによってチケットを作成する」

「チケットの作成、更新時に特定のユーザーをウォッチャーに追加する」

くらいをやりたいです。

たぶん今月中には実装して、正式にJenkins Pluginとして申請する予定です。

面倒な人は月末まで待っているほうがいいかも。

他にもBitBucketとかGitHubのIssuesと連携するPluginをつくろうと思っています。あとTracもいじってみたいですね。

ツイートする

Jenkinsでワークスペースの画像をジョブのトップ画面に表示する方法

Jenkins | 08:28 |

ジョブの説明を使う

ジョブには「説明」と呼ばれる領域があります。

ジョブの設定画面からも、ジョブのトップ画面からも編集出来ます。

ここにはHTMLを書く事ができて、それがそのまま、ジョブの名前のしたのあたりに表示されるようになります。

ワークスペースの画像を表示する

たとえばワークスペースには次のようなパスで画像ファイルがあったとします。

workspace/projectRootDirectory/build/report/report.png

この場合は次のように設定するといい感じです。

<a href="./ws/projectRootDirectory/build/report/report.png" ><img src="./ws/projectRootDirectory/build/report/report.png" height=200></a>

つまり

「.ws/対象のファイル」とすると、ワークスペースにあるファイルをさせます。

固定のファイルにしたいとき

固定のファイルにしたいときは、Jenkinsのホームディレクトリにある「userContent」ディレクトリに格納する事で対処できます。

環境変数JENKINS_HOMEのパスなどの、Jenkinsのwarが実際に展開されて実行されているディレクトリです。

ここにuserContentディレクトリがあるので、そこにいれます。

そのときは

「/userContent/対象のファイル」でさせるようになります。

まとめ

Jenkinsで画像を表示するのは説明の場所くらいしかいまのところなさそうです。

jsを使ったプラグインを作ってやろうとしていましたが結局すごく面倒で、そうするくらいなら、縮小表示を説明に表示して、クリックで元画像表示とかが楽だと後で気付きました。

ちなみにJenkinsでjQueryを使うのは少し骨がおれるので、jQuery Pluginを使うと多少できるようになるっぽいです。

ツイートする

プロジェクトに計画はあるのに、設計はないのだろうか？

PM | 10:11 |

昨日、PMI中部の勉強会に参加してきました。

【3月27日 「本当にPMは育成出来るのか？」(PMIJ中部 3月度定例会)(愛知県)】

その日いろんな意見を交換したり、懇親会でもたくさんの話を聞いていて疑問がでました。

「プロジェクトにはプロジェクト計画というものがあるのに、設計や実装といった言葉がないのはなぜなのか」

僕の意見も含めてその場で出たのは「チームビルディング」や「WBSの作成(PRODUCTバックログの作成)」などがそれにあたりそうだけど、ハッキリとはわからない。といった感じ。

経緯

なんでこういう疑問が出たかというと、大きくは2つあります。

1. 計画という言葉があると、テスト戦略 -> テスト設計 -> テスト実装 -> テスト実施 と思い浮かんだので、プロジェクトにはそれがあるのか気になった。
2. 本会での話で「目的を伝えきれずにタスクだけを渡してしまうことがあり、PMが行う目的の種類がわからなくなってしまうときがあった」という話。WBSの作成だけを言われてなんのためにやっているのかわからなくなってしまったり、目的を把握できていないので、やったことのあるタスクでしか解決方法を見いだせないなど。

設計という言葉がほしいわけではない

疑問に思っているだけで、「プロジェクト設計っていう言葉大切だよ！つくろうよ！」って思っているわけじゃないです。

なんでないのかなって思うのと、もしPMの目的やアクティビティをうまく表現できていないのであれば、計画(戦略策定) -> 設計 -> 実装 -> 実施 -> フィードバック という流れは自然かなって思いました。

まだ表現されていない他にもいろんな観点があると思うし、既存のPMに関して勉強不足な部分もたくさんあります。PMBOKとBABOKとソフトウェア工学系の書籍読んだだけの知識ですしね。。。

PMに限らずあるあるだと思った

アジャイルのプラクティスにあるユーザーストーリーなんかは典型的だなって思います。「顧客との会話を促す」ために「ユーザーストーリーをつくる」があると思うのですが、ユーザーストーリーをなんのためにつくるか意識できていないと、ペルソナの引っ張り合いになってしまったり、無駄に凝ったユーザーストーリーを作ってしまったり、いろいろとダメな行動につながる場合があると思います。

なので目的を意識するというのは重要なのだなぁと感じるとともに、それをうまく共有できる言葉作りは、曖昧さとかムダを抜いて、やりたいことに時間を費やしやすくするために重要だなぁと思いました。（これが標準化というものなのですかね。よくはわかりません。

まとめ

プログラミングでの設計パターンがたくさんオープンになりつつあり、テストでの設計パターンもいくつかオープンに考案されはじめました。情報アーキテクチャでも同様です。

同じようにプロジェクトの設計パターンというのもいろんな言葉でどんどんでているとは思うのですが、僕としてはなによりかにより「同じ目的について言及している気がするのに、別々で言っているから調べにくいよ！勉強しづらいよ！」って思うことがしばしばあります。（本音そこかよ！

どんなことをするのがプロジェクトの設計と言えるのかとか、どんな手段があって、いまないものはどんなものか？っていうのを考えながら勉強していきたいなって思いました。

もし、参考になる書籍やWeb情報や、勉強会などありましたら、教えていただけると非常に嬉しいです。

ツイートする

Groovy基礎勉強会開催報告 #GroovyBase

Groovy | 22:31 |

イベント募集ページ：【Groovy基礎勉強会 - connpass】

Togetter：【2013/03/09(#GroovyBase)Groovy基礎勉強会 - Togetter】

スライド

感想

名古屋以外での基礎勉強会は初めてだったのですけれど、無事におわってよかったです。

JGGUGの方達をはじめとして、たくさんの方にご支援いただいてうまくいきました。

僕はGroovyのザックリとしたお話を発表という形にして、個々のGroovyの基礎について他の発表者が担当してくださいました。

僕はちょこちょことGroovyを2年くらいつかっている感じなので歴史と言っても経験があるのは1.7.xとか1.8Betaくらいで、それ以前の情報はブログとかがメインで調べた感じです。

実際に1.7.xの頃にググると1.5以前のものがそれなりに多かった印象です。

Groovyはそのツールの利便性もあって、ASTと実装を比較しながら追えるのがいいところなのですが、発表者がほとんどASTについてふれながら仕組みの解説をしていたのがGroovyならではだなぁと思いました。

わけわからない系の話は結構少なかったとは思うのですが、知らないところもたくさんあったり、他の方がこれからよりGroovyを使いこなすエントリポイントにはなったなら幸いです。

資料リンク

id:orange_clover さんのブログがいい具合にまとめてくれています。

【Groovy基礎勉強会 に参加してきました。 #GroovyBase - みちしるべ】

最後に

発表してくださった @uehaj @pocketberserker @mike_neck @kiy0taka @nobeans @nobusue @ touchez_du_bois

準備を手伝ってくださった @inda_re @y_sumida @orange_clover

ありがとうございました！

また、翌日のNagoya.Testing にも会場をお貸しいただいたOracleさん本当にありがとうございました。当日もたくさんお手伝いいただきまして。

また、何かの機会にGroovyのイベントを開催できたらいいなって思います。

ツイートする

プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について

Test | 23:44 |

以前にGistに書いていたのですが、忘れそうなのでリンク貼りつつ、転載しておきます。

【プログラマーが「テストを書く」といい、テストエンジニアが「テストをする」という理由について.md】

はじめに

ここに書かれているのは、「主目的」であって、プログラマーもしくはテストエンジニアが「他のことを考慮していない」という意味ではありません。あと、僕の解釈なので一般論というわけではないないです。

プログラマー：「テストを書く」

プログラマーは基本的に「テストを書く」というと思います。実際に書いているんですけど。これ、手動テストしかなかった時代は、どうやって言っていたのかわかりませんけど、これは非常に的を得ていると思うのです。プログラマーの主眼は「要求を設計し実装すること」にあります。そしてその意志はプロダクトコードとなって表現されます。そう、プロダクトコードというのは、表現手段なんです。なので、彼らにとってテストコードというのはあくまで「要求を設計し実装すること」のある表現手段であり、それがプロダクトコード以外であるということにすぎないのではないでしょうか。

プログラマーはあふれるその思いをコードに表現する事が楽しみです。主目的である「要求を設計し実装すること」をテストというフィールドにおいて実施するというのは若干の矛盾をはらんでいて、やっていることは、「要求を設計し実装すること」をしながら確認がとれるものとして、テストコードという手段をとった。くらいのイメージです。

テストエンジニア：「テストをする」

テストエンジニアは基本的に「テストをする」というと思います。実際にはテストを書くんですけど。プログラマーはプログラミングが楽しいとは言うんですけど、コーディングが楽しいという人はあまりいないと思います。つまり、分析、設計、実装がプログラミングという言葉に含まれていて、それが本分であり、楽しいという意味です。テストエンジニアも「テストコード、テスト実施のみが楽しい」というよりは「分析、設計、実装」が楽しいと思っていてそれは「テスティング」と言っています。日本ではあまりテスティングという言葉が一般的ではないのですが。

「コーディング」が「プログラミングの一部」であるように、「テストを書く」というのは「テスティングの一部」にしかすぎません。そして、プログラミングというスタイルとテスティングというスタイルでは目的や視点が違うので、自然とテストが異なってきます。それは狙う場所だったり、量だったり、方法かもしれません。

まとめ

プログラマーは「プロダクトの設計、実装」のためにテストをするのが主目的なので、「テストコードを書く」というのは「プログラミングの一部」であり、プログラミングの一表現手段であるが、テストエンジニアは「テストの設計、実装」におけるテストをするので、「テストをする」つまり「テスティング」という言葉を使う事が多い。

どちらがよいわるいというのではないですが、目的によって言葉が違ってくる例だと思いました。テストエンジニアが考えるテストとプログラマーが考えるテストの違いについてイメージできないと「どっちでもいいじゃん」って思う人がいるとは思います。 でも、きっとそれは「コーディング」と「プログラミング」を一緒にされて嫌な思いをするプログラマーがいるように、「テストを書く」と「テストをする」を一緒にされて嫌な思いをするテストエンジニアがいるとでも思ってくだされば幸いです。

ツイートする

アジャイルなテストの見積もりと計画作りの開催ご報告 #NagoyaTesting

Test | 07:56 |

イベント:Nagoya.Testing in Tokyo 3 -アジャイルなテストの見積りと計画づくり- #NagoyaTesting on Zusaar

Togetter:Nagoya.Testing in Tokyo 3 -アジャイルなテストの見積りと計画づくり- #NagoyaTesting - Togetter

スライド

事前準備、当日と大きな問題もなく無事に終了致しました。皆様ありがとうございました。

やりたいっすねー。といってすぐに定員にまでうまったのでビックリでした。

感想

演習前に言ったテストプロセスを体験するということをほとんど全てのグループが達成出来ていたのが一安心でした。テスト仕様が何かという事であったり、ソフトウェアテストの役割について説明が不足していたのでそこで結構難しかったのは僕の説明が不足していたのだと思います。すいません。

アジャイルなテストとは

ソフトウェアテストがアジャイルであるというのは、ライトウェイトに実行できるものであり、変更を受け付けるようになっていることだと僕は思っています。

そのためにはある程度わりきったテストの区切り方や見積もりをしなければいけません。

そこで僕はテスト観点やテストスイートといったものを軸に戦略をたてます。

また、プロダクトバックログのようなリストではなく、あくまで自分が構築しようとしているアーキテクチャを塗りつぶしていくイメージでテストをおこなう感じです。

なので、テスト観点|テストスイート毎にテストを実施することがメインなときも、それぞれをうすく何度も塗り重ねてテストする場合もあります。

現実的にはかけられるコストであったり、それこそ現在の品質によってかわります。

いくつかパターンはあるので、それはまた次の機会にでも発表しようかと思います。

演習のゴールとは別に重要視したこと

僕があの日何度も言ったのは、「そのテストをすることでどんなリスクが減るのか説明できなければいけません」ということでした。

なんとなく単機能のテストをしているくらいなら、よっぽど品質が悪くない限りバグは出ないはずです。バグの出ないテストは優先順位が低くなるはずですが、もし、そのテストを優先順位の高いものとして扱うなら理由があるはずです。

なぜでしょう？

それに答えられないなら、きっとそのテストは優先順位が低いか、説明ができていないだけかです。

僕はこれに気付いたときに「プロセスやツールに縛られている自分がいる」と感じました。

説明できないアクティビティやアウトプットをプロとして行ってはいけないと強く思うようになりました。

そして、ソフトウェアテストは最もリリースに責任が強くなりがちなアウトプットです。

僕が全てを出来ているなんておこがましいことは思っていませんが、そうありたいという感じです。

とてもいい一日だった

質問も活発にでてきてすごく楽しかったです。また、運営のスタッフさんもとてもがんばってくださって助かりました。本当に。

演習のスタッフさんのサポートも非常に助かりました。一番いいのは、各グループに一人がつきっきりという状況でちょいちょい見て上げるという方向かもしれません。次回からは人数を減らしてその方向でやってみたいですね。（SCMBC的な演習

本会ではなかなか言えなかったアジャイルなソフトウェアテストであることの現実的な例や品質モデルのメリットデメリット、テスト観点の難しさや存在意義についてなどを本田さんが質問してくださって話しました。本田さんや周りの方は実はこれが聞きたいという事だったので、次回から盛り込もうかなぁと思いました。（言いたかったけど、講演の時間が短すぎたり、テスト界隈的に言っていいのか怪しいラインとかとか

懇親会ではなんかいろんな人がLTしていて、こわい話はほとんどなかったですね。最後に僕が「今のテスティングフレームームワークはまぢダメですね。時代遅れですわー。」という話はしました。

次回

夏くらいに1度名古屋で5名くらいでやりたいなーって思っています。完全に「kyon_mmによるアジャイルテスティング体験コース」というスタイルで。

最後に

お手伝いしてくださった @kaori_t_spica @yui_tang @mocha_cocoa @megascus @y_sumida @pocketberserker @cadm2

演習では @oota_ken @goyoki @koyaman2

本当にありがとうございました。

あと、参加者としてだけどガンガンやってくれた、KENさん、本田さんも助かりました。

会場提供してくださったOracleさんいつもいつもありがとうございます。Oracleさんがいないとこういったことを開催もできないですしね。

僕個人のスポンサーになってくださったPhantomTypeさんもありがとうございました。

また、なにか機会があれば皆様よろしくお願い致します。

ツイートする

ネットに転がっているGroovyスクリプトを直接実行する

Groovy | 23:12 |

ネットワーク上にあるGroovyスクリプトを直接実行できます。

groovy https://gist.github.com/kyonmm/5187373/raw/ghello.groovy

Groovyがインストールされている環境で上のコードを実行すると、SwingでHello Worldがでてくるはずです。

（実はこれは100文字程度でSwingが書けるというGroovyの素晴らしさの宣伝でもある。

Groovy1.8.3からの機能のようです。

Windows7とMac OSXで動作を確認しました。

動作するときは、一旦ダウンロードしてきたGroovyスクリプトをローカルで実行するイメージです。

なので、カレントディレクトリは実行時のディレクトリになります。

これ、めっちゃ便利なのでJenkinsの設定どころか、いろんな設定をGroovy化しておけばいいのではないかと思ってきました。

なにがいいたいかというと、Chefクローンとかつくれるのではなかろうかという。

個人的にはJenkins系ですね。はい。

ツイートする

#HDIfes でテストの入門的な話をしてきた。

test | 00:33 |

イベントページ

HDIfes #01「価値のためのテスト」 - UXDx開発xゲーム 情報交換会

スライド

http://goo.gl/vWaF3

イベントについて

イベントページみてください。

発表の感じ

先人が作り上げて来たソフトウェアテストや品質といったもののエントリポイントをいくつかとりあげてみました。

テスト系の人がいない中で、テストの話をするというのは結構チャレンジングでした。

今回参加した人達がソフトウェアテストについて共通して悩むとしたらテストがうまくいっているかいないかの基準がわからないといったことだと思い、それらの助けになるようなテストの手段以外のところを出来るだけ話として盛り込みました。

他の人達の発表がテストの手段(発表内では目的や効果についても言及されていました)の話が多かったのでバランス的には少しとれたのかなぁと思います。

スライドでも意味はなすのですが、項目それぞれに対する僕の考えは基本的に発表しながら喋っているのでそこらへんは参加した人とか、僕にあったときにでも聞いてください。

補足

このイベントで他の方達がたくさん話されていた○○テストというのは、僕が話したテストタイプやテストタイプの実装手段の話になります。

ソフトウェアテストの体系的な言葉に当てはめるという行為が不慣れかもしれませんし、業界で分断されていると感じるかもしれませんが、個人的には「それはテストを勉強していない人のいいb（ry」とかまぁまぁありますが、のほほんと流しておきました。

全体的に、きょんくんの話は計画的にできるテストばかりだなぁという印象を持たれた方もいるかもしれませんが、それはたぶん僕の伝え方が不足しています。すいません。

テスト戦略の策定やテスト設計はヘビーにもライトにも行えるものです。ソフトウェア開発においてWordで設計書を書くか、ホワイトボードで済ませるかのように。

あとソフトウェアテストにはこの資料で話していないテストがたくさんあるわけで、レビューや探索的テストやモデルベースドテストなど様々です。

【TDDを明確に定義する - うさぎ組】、【TDDを明確に定義する 2 - うさぎ組】の話は結構よかったみたいで安心しました。

まぁ個人的には2012年でもかなり出来のいい記事だったのであーいった反応は嬉しいです。

イベント自体

他の方の発表は目新しいといったものはなかったのですが、一度も話した事の無いような業界の人達の生の声を聞けたというのがとても大きな経験になりました。

もちろん発表はどれも面白かったです。

ほとんど知らない人だったので、大丈夫かなぁと思っていたのですが、発表者は話しかけてもらい易いという利点が効いたようでいろんな方とお話ができてとても楽しかったです。

知らない方からは発表についての質問とかもされたり、逆に数少ない知り合いからは【TDDの自殺 #kyon_mmAdvent - うさぎ組】について質問を受けたりしました。

TDDの自殺の話をするとどうしても僕が考える次のテスティングフレームワークの話になってしまうので、そろそろ実装しないといけないなーって思う機会が増えました。僕のブログ読んでいる人からはだいたい質問受けるのよね。とってもありがたいことです。

またこういった機会があるととても嬉しいです。

最後に

今回のイベントを企画してくださった、DevLOVE HCDValue IGDAの皆様本当にありがとうございました。

また、僕を発表者に指名してくださった@chachakiさんありがとうございました。話した事の無い名古屋のうさみみエンジニアに講演を依頼する心象お察し致します。僕はとても嬉しかったです。

あと、当日の懇親会で出してもらったおにぎりが美味しかったです。つくってくれた人ありがとうございました。

会場をお貸しいただいた、国立情報学センター様もありがとうございました。

ツイートする