koboriakira.com

日本 6.5 初戦を勝ったことは、それだけで評価に値する。後半こそ崩壊しかけたが、前半は強者ぶりを見せつける展開だった。両SBの起用も当たりで、前半は良い流れをつくれて、後半は相手の攻撃に耐えしのぐことができた。

反省点は、結局のところ「澤がいないとき」ということで、おそらく4年間取り組み続けている課題だろう。澤がいるとき/いないときで、阪口の役割が大きく変わるのが辛そうだった。

個人的に面白かったのは2つあって、ショートパスからのビルドアップが2種類あることと、宇津木のオーバーラップ。

もう1度観る必要があるけれど、ビルドアップについては、(1)片方のサイドが1列ずつ上がるときと、(2)ボランチ(阪口)をどちらかのサイドに降ろして両サイドを1列上げるときがあった。

今回のような442でセットしてくる相手に対しては、(1)のパターンで、右の有吉と大野を1列ずつ上げた343のようなフォーメーションで攻撃するのが一番効果的かと考えた。見直そう。


山根 6.5 いくつかあったピンチを防ぎ、無失点で試合を終えることができた。CK時のミスはよくないが、信頼は勝ち得たのではないか。 有吉 7 今日一番の収穫は間違いなくこの選手。攻守ともに貢献し、90分を通して動けていた。パスの精度も高い。 岩清水 6.5 安定した守備だった。変なミスも少なかったし、ロングフィードも良いものがあった。 熊谷 6.5 安定した守備だった。最後のピンチは、彼女のプレッシャーで防げた面もあった。 宇津木 7 フィジカル、テクニックともに十分に発揮した。ドリブラーではないのだろう。鮫島と異なり、スピードで相手を置き去りにするようなプレイはしないが、前半は攻撃にもよく参加していた。

阪口 6 チームを落ち着かせるよう、いろいろなところに顔を出していた。澤が交代した後は、彼女がボールを落ち着ける役をすべきだったと思うが、上手く収めることができず、むしろ相手にチャンスを与える結果になった。相手のビルドアップから崩されたプレイは少なかっただけに、もう少し丁寧なボール回しができればよかった。

澤 6.5 貫禄のあるプレイだった。スイスの攻撃の芽を何度も摘み、的確なタイミングでFWを追い越すようなプレイもしていた。途中交代は決勝トーナメントまでを見据えたものだろうか。

大野 6.5 オーバーラップした有吉のカバーリングなど、守備でよく汗をかいていた。攻撃にも参加しようとしていたのだが、ほぼ空気扱いされていた。決定機のシュートはせめて枠に飛ばしたいところ。

宮間 7 試合を決めるPKを決めた。決定機を作りそうなパスも出していた。澤が交代した後は、彼女も攻撃の組み立てに参加すべきだったかもしれない。 安藤 7 裏に出るプレーを何度も繰り返し、PKまで勝ち取った。大儀見との連携もよく、決勝トーナメントまでに戻ってこないと日本はかなり痛い。 大儀見 7 PKに繋がるラストパスを出した。守備にも参加し、自陣まで戻ったり、攻撃を遅らせたりするシーンが何度もあった。

---菅澤 6 個人的には「可もなく不可もなし」。惜しいシュート以外は、とくに目立つプレーも無かった。大儀見と比較しても、安藤と比較しても、次点という感じ。 川村5.5 守備はとても良かったと思う。しかし、攻撃に関してはパスミスを連発し、ビルドアップが上手くいかず、結果的に日本の流れを失う原因になった。 川澄 ―難しい時間帯に入ったが、しっかりと守備のタスクはこなした。しかし、2度のパス(クリア)はどちらもインターセプトされており、仮に失点していたら川澄の交代は「失敗」だったことになってしまっていた。 ---スイス 5.5 「バッハマン」が急上昇ワードになったのは明らかだろう。彼女の個人技でいくつものチャンスが生まれた。しかし、決定機がそれぐらいだった原因は、ラストパスやクロスの精度の高い選手がいなかったことだ。運動量が半端無かったので無理な要望かもしれないが、4番の左SBのキックの精度が高かければ試合はわからなかった。11番のディッケンマンは少し物足りなさがあった。


AIZU ONLINE JUGDEというサイトで、諸先輩方のコードを拝見させてもらいながら勉強するエントリ。

今回の問題は「枠/Frame」というもの。

誰も解答していなかった…

今回は、誰もJavaで解答している人がいなかったので、自分で考えてみました。

結果は、テストケースを半分ほど通過できましたが、後半(おそらく負荷が増える)になると時間制限にひっかかりました。やっぱり。 コードは下の通り。

学習

おおまかな流れ

  1. 各ピクセルの情報を取得する2. あとは、ひたすら全てのパターンの合計値を計算していく。力技全てのパターンを計算せずとも最大値を求める方法を考えたかったのだけれど、どうしても浮かばず。「必ず通るべきピクセル」とかを考えればよかったのだろうか。でもうーむ。

AIZU ONLINE JUGDEというサイトで、諸先輩方のコードを拝見させてもらいながら勉強するエントリ。

今回の問題は「バトンリレーゲーム/Baton Relay Game」というもの。

模範解答

以下、hs484さんのコードより。コメントアウトは、コボリが勝手に付け足しています。

学習

問題を見て、迷ったのは次の点。 脱落したあと、その脱落者を含まないように次の数をカウントできるかどうか。 自分だったら、

  • 「脱落したかどうか」の配列をつくって、カウントをすべきかどうか毎度処理する* 1回の操作ごとに配列を作り直す(脱落者を配列に入れないようにする)

の2つが浮かんだが、ベストには思えない。

おおまかな流れ

  1. 生徒のノードをつくる。生徒は、「自分の前後の生徒が何番か?」ということと「脱落していないか?」という情報をもつ2. 宣言された数に応じて、バトンを持つ生徒(cur)を動かしていく。
  2. 上の操作が完了したら、バトンを持つ生徒を脱落させ、その前後の生徒を関連づけさせる。
  3. 上記を繰り返し、最後に結果を出力処理の負荷の大きさは自分の考えた方法と似ていた。「宣言された数だけ繰り返し処理をしないようにできれば」と思ったが、今回はこれがベストか。

ただ、ノードを作ってグラフとして処理する方法は考えられなかった。たしかに点と線で考えられる問題なのだから、グラフで考えるべきだよなあ。そうすれば、上のように前後の関連づけも簡単にできる。

for文の様々な書き方の種類

Javaを学んでいくと、「こんな書き方もできるんだ!」と感じることが増えるが、なかでもfor文はいろんなパターンがある。今回はイテレータを利用したfor文を使っていた。while文で処理してもいいだろう。

下の2つは参考サイト。 Javaで使えるfor文の種類いろいろ at HouseTect,JavaScriptな情報をあなたに

イテレータと拡張 for文 | じっくり学ぶ Java講座


5年の休止期間を経て、M-1開催がついに発表されました。 昨年末、THE MANZAIはM-1を殺した―中川家から博多華丸・大吉までという記事を書いた人間からすると、今年のM-1はやはり注目度の高い大会になることでしょう。

しかし、それは同時に「2015年のM-1は楽しくなりそう」ということには直結しません。むしろ、コボリは最初愕然としていました。思わずツイートしてしまいましたが、

今冬復活「M-1グランプリ」資格は結成15年以内!(webザテレビジョン) - Yahoo!ニュース http://t.co/1ZvarFYyzn
最悪だー!!!!! もちろん見るけどさあ。

— コボリアキラ (@kobori_akira) 2015, 5月 23
15年にするってことは、結局2010年のM-1に出れたコンビでも出れる、ってことですからね。カナリアだって笑い飯だって出場できる。チャレンジ精神が全くないっすよねー。

— コボリアキラ (@kobori_akira) 2015, 5月 23
【どこよりも早い、2015年M-1出場者予想】http://t.co/9sbzBI5vFP

— コボリアキラ (@kobori_akira) 2015, 5月 23

こんな感じで(後述しますが、すこし誤解もありました。それでもあまり感想は変わらないですが)、非常に興奮したツイートをしていました(笑)。

今回は、上のツイート時よりは情報も集まったので、そこらへんをまとめつつ、2015年のM-1に対する視点のひとつを提示してみようと思います。

「結成15年以内」は失敗ではないか?

M-1が再開するにあたって、一番気にしていたのはそのルールでした。 『THE MANZAI』の「プロであれば結成年は関係ない」 というルールを受けて、M-1は何かしらの変更をしてくるか? ということです。 結果としては、結成からの年数以外は変わりませんでした。

出場資格はプロ・アマ・所属事務所を問わず、2人以上のコンビで結成15年以内(2000年1月1日以降結成)。賞金金額は1000万円。
「M-1グランプリ」詳細発表 出場資格がコンビ結成15年以内へ変更 (リアルライブ) - Yahoo!ニュース

ただし、まあアマチュアの出場についてはどうでもよいとしても(笑・ 第二の変ホ長調が出る可能性は残された)、「結成からの年数」の変更は重要です。というか、ここだけが勝負でした。

「15年」にした理由

結成からの年数を15年以内にした理由は、ざっくり言えば「 M-1のチャンスを失っていたコンビへの配慮 」です。

2010年大会までは出場資格は結成10年以内だったが、今大会の出場資格変更について「今回の復活まで5年のブランクがあります。出場資格をこれまでと同様に結成10年以内とした場合、現在結成11年目の方はラストイヤーの挑戦チャンスを失ってしまったことになります。それらのことも踏まえて今年は結成15年以内とする事にいたしました」と理由を説明。
「M-1グランプリ」詳細発表 出場資格がコンビ結成15年以内へ変更 (リアルライブ) - Yahoo!ニュース

上の発言を信じれば、「今回だけは15年でいこう」ということで、芸人あるいは芸人のファンにしてみれば「ありがとう!

これで僕たち(私のファン)もM-1に出れます!」という感じでしょうか。 しかし、だとしても個人的にはこの 「15年以内」は良策ではなかったと思います。 ### あらためて島田紳助の意図を思い出すあらためて、ですが、M-1は島田紳助により、2つの目的をもって創設されました。 Wikipediaを引用しながら書けば、ひとつは「単純におもろい奴を決めるコンテストをする 」こと。そしてもうひとつは、「 結果の出ないコンビの辞めるキッカケをつくる 」ことでした。

後者について、実際に辞めるべきかどうかは置いておくにしても、M-1の着想が「 若手目線」で行われていたことは事実です。そして、だからこその面白さがM-1にはありました。

たしかに現状のママでは、今年結成11年目のコンビはM-1に出るチャンスを逃します。しかし、これはミスリードもいいところで、彼らには一度も出るチャンスが無かったわけではない。結成5,6年目の頃は出場ができたわけで、そこでチャンスを掴めなかっただけです。

また、M-1だけがスターを生み出すわけではありません。チャンスを掴む芸人はその次代に応じてチャンスを掴んでいるはずです。

そういう意味で、「若手目線」を壊してしまった今年のM-1については、その _優しさのプラスよりもM-1らしさを失ったことのマイナスが大きい_と思っています。THE MANZAIとの差異化もしづらくなりましたし。

まとめに

というわけで、結成年数というのがM-1にとってかなり重要だということだけでもご理解いただければ幸いです。

最後にポジティブな話をすれば、笑い飯はすでに不出場を明確にしており、もしかすると暗黙の了解的に「M-1の空気」が作られていく可能性はあるかもしれません。

また、その他にも、THE MANZAIと同時期の開催によるネタ被りや、審査員の問題(とくに松本人志が座るかどうかは重要)。さらには「もし菊川怜がまたアシスタントを務めたらどうしよう」など、心配は尽きませんが、開催される限りはとにかく楽しいものになってくれればいいなあと思っています(笑)。 準決勝は見に行きたいな!


AIZU ONLINE JUGDEというサイトで、諸先輩方のコードを拝見させてもらいながら勉強するエントリ。

今回の問題は「ザ・スクエアーズ/The Squares」というもの。

模範解答

以下、sawfishさんのコードより(前回と一緒だ!

なんて人なんだ)。コメントアウトは、コボリが勝手に付け足しています。

学習

おおまかな流れ

  1. フィールドと避難者を設定する。向きを示す文字列の配列と、向きによる「次に進む方向」の配列をつくっておく2. まず、避難者それぞれについて、進行方向の確定をさせる。とりあえず「今向いている方向が進めるかどうか」から考え、それが無理なら問題文の通りに次案を検討していく3. 全員の進行方向が確定したら移動フェーズに入る。優先度(prio)を使いながら、同じ場所に避難者が着かないように移動させる。このとき、移動前の場所を床(避難者のいない場所)にしておくことを忘れずに4. それぞれの避難者について、非常口に立っていたら迷路から取り除く。
  2. まだ避難者が残っていれば、残った避難者だけで上記の処理を繰り返し行う。180秒(180カウント)したら強制的に終了。

優先度の処理の仕方

今回は、複数の避難者が同じ場所に移動する場合の対処に唸らされた。簡略すれば、それは「予約システム」のようなものだ。

方向付けが確定したとき、次に進むであろう場所に自分の向きを数値として入れておく。そうすると、2人目以降の数値が入るとき、どちらの数値(予約)を優先すべきか決められるわけだ。

最初は「まとめて処理すればいいのに」と思っていたが、ここの処理を理解して、方向付けと移動を分けて処理する大切さを理解した。

ArreyDeque

これまでArrayListとHashMapしかコレクションフレームワーク(コレクション=オブジェクトの集合を操作するために用意されたJava標準のAPI。今知った・笑)を使っていなかったが、ArrayDequeというのもあるようだ。

ArrayDequeは、両端キューとも呼ばれ、先頭末尾の双方から要素を出し入れできるキューの実装です。ArrayDequeを利用することで、キュー(FIFO:First
In First Out)やスタック(LIFO:Last In First Out)といったデータ構造を表現できます。 ArrayDeque |
Javaコード入門

アナロジーとして、ロケットペンシルのようなものか。真ん中の処理はできないが、1個ずつ取り出しつつ、目的の番が来たらそれを処理して、もう一度戻したり(あるいは捨てたり)できるイメージ。

メソッドは、offer()で末尾に登録し、poll()で先頭を取得and削除する。

今回の例では、これで避難者の脱出処理を上手に行うことができる。たとえば、5人いる中の2人目が脱出した場合、次の処理からは4人で行える。これはメモリの観点からも良いのかもしれない。

ちなみに、TreeMapという、勝手にソートしてくれるHashMapもあることを知った。便利そう。


Javaについて、基礎中の基礎は終わったような感じがしてきた。 しかし、まだ自信というほどのものはない。それは主に、「知ってる技が少ない=メソッドやクラスに関する知識が足りない 」ことと「 アルゴリズムのパターンを知らない 」ことが原因かと思っている。

そう悩んでいたところ、 AIZU ONLINE JUGDEというサイトに当たった。このサイトでは、いろんな言語に関する練習問題を多く載せてくれている。

難度は「“Hello World”を出力しなさい」という簡単な問題から、よく練られたアルゴリズムが要求されるような問題まで、いろんなレベルの問題が揃い、独学の身にとっては嬉しい。

さらに、このサイトは他の人の書いた(正解の)コードも公開されているため、これが非常に勉強になる。

というわけで、諸先輩方のコードを拝見させてもらいながら勉強してみようと思う。今回の問題は「錬金マスター/Wrought Gold Master」というもの。

模範解答

以下、sawfishさんのコードより。コメントアウトは、コボリが勝手に付け足しています。

学習

おおまかな流れ

  1. アイテムのインスタンスを作り、そのインスタンスの中にレシピリストを作り、必要なアイテム(インスタンス)を登録する。
  2. 指定されたアイテムについて、「レシピが存在しなければ、購入金額が最低費用」、「存在するなら、素材ごとの最小費用の合計を最小値」とする非常にシンプルな処理。自分だったらItemクラスとRecipeクラスを作ってしまいそうだ。たしかに、必要な素材はアイテムの情報として登録すべきだろう。

インスタンスの作成方法

まず気になったのが、下の箇所。

Item item = getItemInstance(br.readLine());itemTable.put(item.name, item);自分がインスタンスを作るときは、たいてい配列でインスタンスを作っていたのだが(item[0]みたいな)、模範解答では、

「itemインスタンスを生成する」→「マップにアイテムの名前とインスタンスを登録する」→「itemインスタンスを生成する」→「マップに登録」

の繰り返しでインスタンスを生成し、コントロールできるようにしている。これをすることで、(例えば今回のように)名前からあるインスタンスを持ってくることができるようになる。すごい。

また、2回目にitemインスタンスを生成するとき、1回目に生成したitemインスタンスを上書きするものだと思っていたが、どうやらそういう訳でもないらしい。

「new Item」とコードを書くぐらいだから、きっと新規作成なのだろう。

三項条件演算子

if文の省略について、そろそろ勉強してもよいだろう。単純な処理はこういった1行で済むコードで済ませておきたいところ。

条件式 ? 式1 : 式2 「式1」は、条件がtrue出会った場合。「式2」はfalseの場合。

StringTokenizerクラスについて

レシピをつくるときに、StringTokenizerクラスを使っているのも勉強になった。これは入力された文章を半角スペースごとに区切ってくれるクラスメソッド(?)だ。これまで、標準入力を読み取って、その文字列をsplitメソッドで分けて処理していたが、このような方法もある。

ちなみに、nextToken()で次の文字列(トークン)を取得し、countToken()で残りの文字列の数を取得できるよう。