コラム, 小ネタ, 雑談

おはようございます。ライトノベル好きの新人ツチノコです。魔法少女育成計画のアニメ化が発表されましたね。

さて、少し前に発表された製品ですが、ロジクール MX Anywhere 2を発売日に買いました。
それでふと同僚がどんなマウスを使っているのか気になりデスクの上を眺めたところ、結構ロジクール製品がありましたのでとりあえず並べてみました。

IMG_20150917_141930

M545 M505 M525
VX Revolution M705 M950
iPhone6 MX Anywhere 2 MX Master

M705とMX Anywhere 2は僕の私物、他は同僚の物です。まさかVX Revolution(2006年発売)が出てくるとは…

M705→MX Anywhere 2と変えてみての感想ですが、いい点と悪い点があります。
よい
・軽くなった
・電池が充電式になり、携帯と同じくMicro USBで充電できる
悪い
・高速スクロールモードと通常スクロールの切り替えがM705では専用ボタンなのに対し、MX Anywhere 2ではホイールのクリックと統一されてない

なにかの参考になれば幸いです。

イカ適当に撮った写真です。
IMG_20150917_142032
IMG_20150917_141713

p.s. ユリシーズ面白いですね。

firefox, コラム, 失敗談, 小ネタ, 雑談

Firefoxの動作が重くなってきた。
ググってみると良くある症状のようで、改善方法としては

– SQLiteを最適化
– メモリを開放

というのが定番らしいのでやってみたけど残念ながら私の環境ではあまり効果は見られず。

さらにググってみると、このサイトを見付けた。

Firefoxをリフレッシュする – アドオン
https://support.mozilla.org/ja/kb/refresh-firefox-reset-add-ons-and-settings

このページを Firefox で閲覧している場合、この「Firefox をリフレッシュ」ボタンを直接クリックしてください

素直なのでとりあえず押してみたよ。
Firefoxがクローズしていろいろな処理が走って綺麗にリフレッシュ!!。
めでたしめでたし。

ではなくて、使用上の注意を良くお読みになってからお試しください、ってやつでした。
ボタンの上にこう書いてあるんですな。

注記: 拡張機能とそのデータは削除されます。

書いてあるとおり、拡張機能は全部なくなっちゃいましたよ。
ありゃあ。。。

とはいえ以下は保持されたままなので、実際に困ることは拡張機能がなくなるぐらい.

  • ブックマーク
  • 閲覧履歴
  • パスワード
  • 開かれているウィンドウ 、タブとタブグループ
  • Cookie
  • Web ページ上のフォームの入力補完情報
  • ユーザ辞書

Firefoxの設定ファイル自体は大幅に小さくなって、動作も軽くなった印象。

設定はデスクトップ上にバックアップされるので戻せることは戻せるんだけど、心機一転、拡張機能をあれこれインストールし直して、わりと今は快適にブラウジングできていますよ。

記念にとりあえずインストールした拡張機能を書いておきます。

 

ツリー型タブ (Tree Style Tab)

https://addons.mozilla.org/ja/firefox/addon/tree-style-tab/

タブを横に表示できるようになる拡張機能。大量にタブを表示するときにはとても便利。手放せない。
Firefoxが重いのは実はタブを開きすぎなだけ、という気もする。
Chromeでもこういう拡張機能のがあれば良いのになあ。

Firemacs

https://addons.mozilla.org/ja/firefox/addon/firemacs/

EmacsキーバインドでFirefoxを操作できるようになる。Emacsの人には必須。
Chromeでも、ちゃんとEmacsキーバインドになる拡張があれば良いのに。

Tab Mix Plus

https://addons.mozilla.org/ja/firefox/addon/tab-mix-plus/

タブの機能を拡張してくれて挙動のカスタマイズができる。
検索結果を新しいタブで開くとか、そういうカスタマイズをしている。
セッション保存機能もなにげに便利。

Googlebar Lite

https://addons.mozilla.org/ja/firefox/addon/googlebar-lite/

これを使って検索をすると、検索キーワードがツールバーに表示されてページ内検索ができるので便利。

S3.Google Translator

https://addons.mozilla.org/ja/firefox/addon/s3google-translator/

Google翻訳の機能、レビューを見ると良さげなので使ってみることにした。

All-in-One Gestures

https://addons.mozilla.org/ja/firefox/addon/all-in-one-gestures/

ネットサーフィンするときにジェスチャー機能はとても便利。

ClickCutter AutoSearch

https://addons.mozilla.org/ja/firefox/addon/clickcutter-autosearch/

ページ中で範囲指定した文言を任意の検索エンジンでサクっと検索できるのはとても便利。

BarTab Lite

https://addons.mozilla.org/ja/firefox/addon/bartab-lite/

Firefoxの再起動時に全部のタブの再読みこみをしないようにする。タブを大量に開いて使っていると再起動時にとても重くなるんだよね。

ASnumber

https://addons.mozilla.org/ja/firefox/addon/asnumber/

インターネットに関する仕事をしている人にはとても便利な拡張機能。
ページ下部のステータスバーに、ウェブサイトがどこのASに置かれてるのかがわかったり、そのASのwhoisがすぐわかったりする。
ただ、Firefoxのステータスバーは最近は標準では表示されなくなってしまったので、、、、

Status-4-Evar

https://addons.mozilla.org/ja/firefox/addon/status-4-evar/

この拡張を入れるとステータスバーが復活してASnumberが使えるようになる。

DNS

秋深まりぼちぼち温泉につかりたいシーズンになってまいりましたが、皆様如何おすごしでしょうか。お久しぶりの酔っ払い系ツチノコです。

温泉といえば、


で有名な ENOG という新潟のネットワーク系のグループが存在しますが、そちらで DNS に関する話題をお話して来ましたのでそちらの話でもさせて頂きたいとおもいます。
(あ、本当は Echigo Network Operators’ Group の略で ENOG らしいです。)

 

唐突ですが、皆さんはDNSってお好きですか?

 

大概の管理者の方は

“BIND の脆弱性とかしょっちゅう出てめんどくせぇYo!”
“一度設定したら何となく動いてるYo!”

ってな感じではないでしょうか。

 

そんななんとなく動いているからなんとなく理解した様になりがちな DNS の振舞いの中でも特に誤解されている DNS の名前解決の動作に関するトピックです。

DNS には

  • ドメイン名とIPアドレス等のリソースレコード を紐付けるデータを持つ権威DNSサーバ
  • 端末から名前解決の要求を受け、権威DNSサーバに問合せを行うキャッシュDNSサーバ

のふたつが存在する事は皆さんご存知かとおもいます。

 

ここで皆さんに質問です。

端末が “酔っ払い.jp” というサイトに接続を行いたいとします。そこで下図の (2)(3) でキャッシュDNSサーバは “.” の権威DNSサーバ (root の権威DNS サーバ) に対してどういったクエリを送り、”.” の権威DNSサーバはどういう返答を返すでしょうか。

よくある答えは、”.” の権威DNSサーバには “.jp” の権威DNSサーバを尋ね (NSレコードを聞き) 、それらを返答として受け取る、というものでした。以下、一階層ずつ下の権威DNSサーバを尋ねるクエリを送っていき、最後の階層でIPアドレスを尋ねる (A/AAAAレコードを聞き)、という形ですね。

ENOG 会場、弊社のエンジニア向けの勉強会共にこれらの答えが大半をしめました。
でも。実は。

これらの答えは、実際の挙動とは異なります。

 

というわけで、答えはこちら。

ちょっと分かりづらいですね。

キャッシュDNSサーバは常に “酔っ払い.jp のIPアドレスは何?( Aレコード)” を常に問合せ続けます。”.” の権威DNSサーバにも、”.jp” の権威DNSサーバにも、実際に紐付けるデータを持つ “酔っ払い.jp” の権威DNSサーバにもです。常に “クライアントから要求された名前解決のクエリ” を送ります。

わざわざ、”.” の権威DNSサーバに次の階層である “.jp” の NSレコードを聞いたりは、しないんですね。

で、”酔っ払い.jp” の A レコードを直接知らない “.” の権威DNSサーバは “.jp” の権威DNSサーバなら知ってるんじゃない、という意味で Authority Section に NS レコードの一覧をいれて教えてあげます。

あとは、実際に紐付けるデータを持っている権威DNSサーバに辿りつくまで繰り返し、です。

 

ところが、現在 IETF の dnsop で提案されている DNS query name minimisation to improve privacy というインターネットドラフトで状況が変わるかも知れません。

上記のドラフトによると、現在の “クライアントが知りたいドメイン名のリソースレコードを root の権威DNSサーバから順番に引いていく” というやり方は、実はプロトコル上の要求ではなく、歴史的にそうやっているだけだ、というのです。

そしてこの従来の振舞いですと、より上位の権威DNSサーバやそれらに到達するDNSクエリのパケットを覗き見できるネットワークの管理者は、ある程度エンドユーザの活動が推測できる、という事になります。

 

こりゃいけねぇ、ってなことで QNAME Minimisation という提案がなされているのですが、こいつの内容って、

  • “.” から問合せを始める際、一階層下の権威DNSサーバを尋ねる ( NS レコードを聞く )
  • 一番下の階層に辿りついたら実際に聞きたいリソースレコードを尋ねる

というものなのです。これって、さっきのよくある間違いと同じ事ですよね。

現在、Experimental RFC になる予定になっていますが、従来の挙動から変更しても特に互換性に問題がない為、メジャーな実装で機能が入るとあっさり普通の動作になったりするかも知れません。

 

というわけで、今日は DNS についてよく誤解されている振舞いと、将来的にそれが本当の動作になっちゃうかも、ってなお話をさせて頂きました。

詳細はこちらのスライドの中身もご覧頂ければとおもいます。

 

あ、そういえば新潟にはよく遊びにいくのですが、新潟市は古町にあるバー、Jazz Flash はホントおすすめですよ。先月はいきそこないましたが、年内にまた遊びにいこうかとおもってます。
では、また。

ICTSC

前編に引き続き第4回ICTトラブルシューティングコンテスト(トラコン4)、2日目の様子です。デットヒートを繰り広げるトップのWCDIと2位のコバゼミ。そこに思わぬ伏兵が現れます。(若干の潤色はありますが、ほぼ事実に基づいております。)

2015年8月30日(日曜日) トラコン4 二日目

07:00 : 初日より1時間早くコンテストが開始されるため、運営の学生集合時間も昨日より1時間早く繰り上げられた。二日目ということもあり、運営学生にも若干の余裕が感じられる。

DSC07776 DSC07777

08:30 : 参加選手の受付がはじまる。初日と同じく、受付開始直後から参加選手が会場入りしてきた。

DSC07785 DSC07783

09:00 : 二日目午前の問題が出題された。以下の3問である。

Q8. 経路情報が来ていない。

Q9. Redmineがアクセスできない!?

Q10. 同期できません!

Q8は明らかにネットワークの障害であることが推測できる。Q9もRedmineサーバのセキュリティ的不具合だ。Q10は問題タイトルからは想像できないが、ファイルサーバであるGlusterFSとSamba間でデータに食い違いが生じるというトラブルである。ネットワーク、セキュリティ、サーバインフラといったカテゴリをバランスよく織り交ぜている。初日のトップ2チームがここでも高得点をあげていたが、WCDIを追いかけるコバゼミがわずかに多くポイントを獲得し、昨日の差が縮まってきた。

12:00 : 午前の問題が終了し、参加選手たちはB1のカフェテリアへと昼食に向かう。運営学生は午後問題の準備に取り掛かると同時に午前問題の採点と集計作業を行っていた。すると集計担当の運営学生がある異変に気づく。午前問題の採点結果、現在トップのWCDIでも2位のコバゼミでもないチームが最も高い獲得ポイントを示している。そのチームとは、

ベトナムハノイ工科大学チーム「BKAlternative」だった。

スナップショット- 6 スナップショット- 5

初日の結果BKAlternativeはトップWCDIに対し18ポイントの差があり、総合順位としては同率で5位につけていたため、運営学生も特にマークはしていなかった。が、なんと二日目の午前問題終了時点で総合3位にジャンプアップしていた。2位コバゼミとの差は11ポイントである。二日目午後の問題は全て10ポイント問題であるため、少なくともコバゼミと順位が逆転する可能性は十分にある。運営の学生数人がNOC内を見回しコンテスト実行委員会役員の姿を探した。運よく、NOC入り口のそばの椅子に座り、運営の学生と談笑していた会長を見つけ、会長にこう聞いた。

「伊勢さん、ダブル受賞はOKですか?」

困惑した、そしてなぜか嬉しそうな学生の表情を見て、伊勢は即座に状況を察し、こう答えた。

「大丈夫だ、問題ない」 (ふ、ふるい・・・)

今回の大会では始めてThe Showdown in Japan(以下TSJ)プロジェクトを導入していた。TSJとは海外に拠点を持ち、現地の学生を新卒社員として採用している協賛企業が、関係の深い現地大学の学生をこのコンテストに招聘し、世界各地の情報系学生達による競争と交流を通じて国際的に相互切磋琢磨してもらう事を目的としたプロジェクトだ。今大会ではクリエーションラインがカンボジア・プチサストラ大学から、オルトプラスがベトナム・ハノイ工科大学からそれぞれチームを招聘し2チームのTSJ枠参加があった。今回の表彰では優秀、最優秀賞のほかにTSJ賞を用意し、これらTSJ枠参加のチームの中で最も高得点を獲得したチームに送られる事になっている。つまりカンボジアかベトナムのどちらかのチームがTSJ賞を受賞する事になる。もし、この2チームのうち、どちらかが、優秀、最優秀賞を受賞すると、TSJ賞とのダブル受賞となるわけだ。

DSC07520 DSC07522

13:00 : 二日目午後、最後のコンテストフェーズの開始である。まずは3問のうち以下の2問が出題された。

Q11. 公開鍵認証でsshができません・・・・

Q12. Proxy再構築

Q11はネットワークセキュリティ問題。そしてQ12はProxyサーバの性能問題に見せかけたネットワーク障害問題である。特にQ12は当該サーバだけではなく、ネットワーク全体の性能に影響が出ているため、平行して他の問題を解こうとしてもレスポンスが遅く、どのチームも苦労していたようだ。

13:30 : ここで、本コンテストの最終問題、いうなればラスボス問題が出題された。

Q13. 犯行予告が来ました。

この問題では各チームが所有するWebサーバを乗っ取るという声明がredmineのチケットとして送りつけられ、犯行予告から数十分後、実際にWebサーバが乗っ取られる。参加選手はその原因を突き止め乗っ取られたWebサーバを取り戻すというミッションである。この最終問題は運営学生が企画し、基本部分を作成した後、実行委員(社会人サポータ)である川畑と黒崎が味付けし仕上げたラスボスである。

DSC08366

しかし、ここに運営学生の辛辣かつ綿密に組まれた罠があった。Webサーバの乗っ取り手法としては、サーバをクラックしてアカウントを奪い、コンテンツを差し替えるというのではなく、ネットワークの構成情報を改ざんして同じURLに対し、全く別のサーバへとアクセスを誘導するのである。したがって、各チームのバックボーンネットワーク自体が侵食されているため、他の問題に対しても影響が発生する。出題されてから数十分後に乗っ取りを開始するという理由は、それまでに先の二問を解決するか、もしくは解決のメドをつけておく必要がある。しかも先の2問のうち、Q12もネットワークの障害問題であるから、少なくともQ13の乗っ取りが実施される前にQ12を解いておく必要がある。しばらくして幾つかのチームからQ11の回答が提出されてきた。WCDIはここでも満点。コバゼミも満点を出して差を開かせない。そしてBKAlternativeも満点である。トップ3チームの差は縮まりも開きもしない。

DSC07859 DSC07877

14:30 : Q13による乗っ取りが開始されてから十数分後。まだどのチームからもQ12とQ13の回答が報告されていない。最終フェーズの問題は少し意地悪すぎたか?といった反省とも、やったぜ感とも取れる言葉がNOC内で聞こえた。二日目午後の問題の回答期限は15:30、残り1時間である。運営学生は固唾を呑んでスコアボードを見つめている。そんなNOCの静寂の中、Q13の採点を担当している川畑が突然奇声を発した!

「ひぅげあぁぁぇぇーー!最終問題、ベトナムチームが満点出しやがった!」

NOC内がどよめく。

「まじかーぁぁ」 「ひぃぃぃー」 「うぇえええー」 「げぇぇぇー」

トップWCDIとBKAlternativeの差がいきなり5ポイントに縮まる。BKAlternativeは残すところあとQ12のみ。WCDIとコバゼミはQ12とQ13が残っている。こうなって来ると、残りの問題次第ではもうどのチームが優勝してもおかしくない!

運営学生達、なぜか異常な盛り上がりを見せる。

15:30 : 二日目午後の問題が終了した。参加選手たちは協賛セッションと表彰式の会場である1Fのロビーへと移動を開始する。運営の学生達は最終的な採点の集計を行った。

結果は劇的だった。

WCDIはQ12、Q13をノーポイントで終了したが、コバゼミは4ポイントを加え得点数としてはWCDIと同点となり、同率首位に躍り出た。BKAlternativeは残念ながらQ12をノーポイントで終了し、トップとの5ポイント差を縮めることができず、3位で本コンテストを終えた。

結果的に獲得点としては同率首位となったWCDIとコバゼミであるが、本コンテストでは第1回から優秀、最優秀の同率首位を認めず、得点数が同じ場合でも順位を決めるためのタイブレークシステムを用意していた。つまり得点以外の要素(詳細は割愛するが、過去のコンテストでは回答時間、回答内容の正確性、満点の数、平均獲得ポイント数、ノーポイントの数など各回によって異なる)により、最終的にはWCDIが1位で最優秀賞、コバゼミは惜しくも2位で優秀賞を受賞する事になった。

八王子 DSC08123

そして当然の事ながらBKAlternativeはTSJ賞を受賞した。後で彼らに話を聞いてみたところ、メンバーの中にCisco NetRidersという全世界的な学生ネットワーク技術コンテストのベトナムチャンピオンがいるということだ。どうりでコバゼミ以外どのチームもゼロポイントだった最終問題で満点を叩き出すわけだ。そして、自分達がわずか5ポイントの差で総合3位であったことを知り、次回も必ず参加し、そして必ず優勝すると宣言した。今回、初日午前をノーポイントで終了してしまった原因としては、コンテストの勝手がわからず、また言葉の問題も大きかった事だろう。次回、再び挑戦するならば、これらのハンディキャップをなんらかの形でクリアし、万全の状態で望んでくるはずだ。

DSC08128

そうなると次回ベトナムチームが優勝する可能性は非常に高い。

それを迎え撃つ日本の学生達。日本を発祥とし、日本のお家芸(?)であるこのコンテストのトップを死守できるのか?勝てるのか?大丈夫か?

学生 「大丈夫だ、問題ない」

DSC08196

ICTSC, イベント, インフォメーション

こんにちわ。ツチノコブログ2回目のibuchoです。

このブログのエントリーでも幾つか書かれているのでご存知かもしれませんが、先日の8月29日、30日に開催されたDMM.com Labo ツチノコ杯 第4回ICTトラブルシューティングコンテスト(略してトラコン4)の模様をドキュメンタリータッチでご紹介します。(若干の潤色はありますが、ほぼ事実に基づいております。)

2015年8月29日(土曜日)

08:00 : 朝8時、トラコン4本選会場である工学院大学5Fに設置されたNOCルームに運営学生全員が集合した。2週間前から毎晩夜遅くまでコンテストの準備に追われていた運営の学生達だが、昨夜だけは18:00に作業を終え、今日に向けて十分な休息を取り万全の体調で参加選手を迎える事にしていた。始めに運営リーダの森から本日の予定、担当、シフトの確認、残作業、問題の準備等が伝えられ、各自それぞれの役割に従って会場やサーバ、プログラム、採点表の確認など、おのおのあらかじめ割り当てられている作業へと散っていった。

DSC07399 DSC07397

09:00 : 会場である5Fフロアはさながら嵐の前の静けさであり、案内看板、受付の準備も完了し、あとは出場選手を迎え入れるだけである。

DSC07406 DSC07410

運営学生はリラックスしている風を装っているが、心なしか表情に緊張の色が見え隠れしている。

DSC07544 DSC07538

09:30 : 受付開始と同時に参加者がぞくぞくと入場してくる。各参加者は受付で学校名、チーム名を申告し、運営学生に案内されコンテスト会場へと進む。そして各チーム毎のテーブル上におかれたゼッケンを手に取りコンテストに望む準備をする。チームの仲間と会話し作戦を確認する者、テーブル上に設置されている機器をチェックする者、ブラウザを開き何かを調べ始めるもの、ネットワーク技術の教科書を開き復習をする者など、さまざまである。そしてコンテスト開始10分前には全チームが集合し、ザワザワしながらコンテストの開始を待っていた。

DSC07424 DSC07448

10:00 : 会場正面の演題に運営チームリーダーの森が立ち、コンテストの開始を高らかに宣言した。

DSC07453 DSC07454

コンテストのルール、注意事項などが告知され、続いていよいよ初日午前の問題が出題される。出題は各チームにあらかじめ提供されているredmine上にチケットという形で出題されるため、会場内で問題がアナウンスされるということは無い。各チームは一斉に端末でredmineを開き、チケットとして発行された問題を確認しはじめる。初日午前の問題は以下の3問であった。

Q1. Webサーバを構築してくださいな。

Q2. スイッチ間を冗長化してほしい。

Q3. VPNの構築の件について。

問題文の内容は漠然としている。たとえばQ1の問題文は以下のようになっている。

新入社員「それなんですか?」
上司「これは俺が昔遊んでたサーバさ。CentOSが大好きでね。ちょうどいい、勉強用に使いなさい。まずはWebサーバを構築してみようか」
新入社員「やったーーー!がんばります!」

報告事項 :実際に行ったWebサーバの構築手順

これのどこがトラブルシューティングなのか?と誰もが思うだろう。過去にトラコンに参加したチームにとっては見慣れた問題形式だが、初出場のチームにとっては問題の意図が全くわからず、何を要求されているのか、何と答えると正解なのか混乱したはずだ。通常学校で出されるテスト、資格試験などの問題には必ず回答があり、問題文からどのような知識、解法手順を要求しているかが予測できる場合が多い。学生は問題を読み、授業や講義で学んだ知識を元に問題が要求している回答を探すといった対応をする。つまりクイズやパズルを解く事と同等なのだ。

DSC07471 DSC07467

しかし、実際の現場において、回答のある問題などあるはずがない。トラコンで出題される問題は正に現実に起こっているトラブルや上司や顧客から依頼、指示された作業を実施する様をモデルとしている。この問題形式は運営の学生が独自に発案し作成したものであるが、参加選手にとっては答の無い問題という実際の現場で直面する状況を経験する非常に良い機会であろう。

11:59 : 午前の問題の回答制限時間が近づく。その時、コンテストの成り行きをNOCで見守りながら各チームの回答の採点を行っている学生達がざわついた。15チーム中、1チームだけ3問全部満点の回答を叩き出したチームがいる。

日本工学院八王子専門校チーム「WCDI」である。

WCDI-1 WCDI-2

通常初日午前というのはコンテストの勝手がわからず、問題に取り組むというよりは機器や回答方法などの環境を把握するだけで精一杯であり中々正解を出す事は難しい。実際、他のチームはノーポイントか、せいぜい正解が1問だけだったが、チームWCDIは全問完璧な回答を出して初日午前をダントツトップで駆け抜け、このままポール・トゥ・ウイン、先行逃げ切りをぶちかます勢い。ロレンソか。

13:00 : 昼休みが終了し、各チームが再び所定のテーブルに着座した所で初日午後の問題が出題された。

Q4. ときどきサーバにつながりません!

Q5. 残りのスイッチの設定は任せた!

Q6. Redmineの意図しない挙動の調査について

Q7. 新しい営業所

これまた問題タイトルからは内容が全くわからないが、サーバの脆弱性が攻撃されていたり、あらかじめコンフィグレーションされている設定が間違っていたりといったトラップが仕込まれており、参加選手はサーバ、機器類のログや設定を調査しながら原因を突き止め、トラップを修正もしくは回避しつつ依頼された内容を解決していかなければならない。

午前問題をトップでクリアしたチームWCDIはまたもや4問中2問で満点を叩きだした。しかし、ここで急速にWCDIに迫るチームが出現する。

関西大学大学院チーム「コバゼミ」だ。

コバゼミ1 コバゼミ2

チームコバゼミは前回(トラコン3)から参戦して初出場で優勝を勝ち取った、いわばディフェンディングチャンピオンチームである。前回は学部4年生の関西大学としての出場だったが、チームメンバ中の数名が大学院へ進学し、今大会ではゼミの新たなメンバーを加え大学院チームとして参戦した。チームコバゼミはチームWCDIと同じく4問中2問で満点を叩き出した。しかもWCDIがノーポイントだった問題でも得点を獲得し、いきなりWCDIに肉薄してきたのだ。

17:00 : 初日午後のコンテストが終了。結果的にトップはチームWCDIが死守し、ついでチームコバゼミが5ポイント差で2位に着けていた。問題の得点は5ポイントと10ポイントの2種類が用意されているため、1問の差で同点になるか、もしくは順位が逆転する可能性もある。初日の結果により2日目には俄然これら上位2チームによるデットヒートが展開されるだろうと、運営の誰もが予測しつつ、初日夜に予定されている懇親会へとなだれ込んだ。(出張握り寿司付き)

DSC07683 DSC07714

しかし、初日を終了した時点でトップ2チームのWCDIとコバゼミの背後から静かに忍び寄るチームがあった事を関係者、そして運営さえ誰も気づいていなかったのである。

(後編へ続く)

DSC07774 DSC_8296

PAGE TOP