SyntaxHighlighter

StackEdit CSS

2013年11月20日水曜日

高専プロコンに出場した話

 もう1ヶ月以上も前の話だが、高専プロコンに参加したので記録を残そうと思う。先に結論を言っとくと今回のプロコンはあまり良くなかった。面白くなかったからだ。
 自分のチームは「TasQ」というものを出した。自分はサーバー担当だった。技術的な話は別のエントリーで。

12月~5月上旬

 昨年は遅めに始めて失敗したので、ほぼ一か月前の12月あたりから構想を練り始めた。この時点で出た案は、飲食店での待ち時間を短縮するシステムだった(過去形)。5月までは構想も大体固まって実装も進んでいたが、そのシステムで予選通過できるかはっきり言って微妙だったので新しいのを提案したら通って白紙にな(ってしま)った。

5月上旬~プロコン予選締切

 新しい企画、今回提出した作品の案を練りつつ予選資料を作った。

夏休み

 夏休みはほとんどのメンバーが忙しくて実装が思ったより進まなかった。自分はというと他の大会のための作品を作るのに忙しくてプロコンは自分のところしか実装できずにさらにテストも十分にできなかった。それが原因で後々苦労してしまった。

秋休み

 プロコンの本選まであと2,3週間でそろそろ焦りが見え始めた。自分の担当であるサーバはほぼ完成していたが他のクライアントと動かしたらバグがいろいろ見つかって直す羽目になった。このあたりから8,9時に学校を出るようになってた(普通?)。

プロコン本選2週間前

 このあたりは地獄だった。他のクライアントも含めてバグが大量に見つかりなおかつまだ実装してない機能が多かったので毎日10時ぐらいまで学校に残ってた。

プロコン本選1週間前

 このあたりでだいたいバグも清掃して自分はプレゼン用のスライド作成に取り掛かった。だがここで想定外の事が起こった。自分たちは開発拠点として研究室を借りているのだが自分たちのマナーが悪かったせいで追い出される羽目になってしまった。場所はほかにもあるから大幅な影響はなかったが。

プロコン本選3日前~

 このあたりからデモ審査の練習を始めたがそこでバグが数点見つかった。ほとんどのバグは直したが残りのバグはもう気力がなかったのでデモ前日に回すことにした。だが前日は移動の疲れのせいかテンションがおかしくなってしまいほとんど実装できなかった。

プロコン1日目

 最初はプレゼンだ。自分はスライドのページを進める係で、プレゼンをしているのを横から眺める形だった。プレゼンは少々言い間違えがあったものの練習の甲斐あってかなかなか良かった。ただ、審査員の質問タイムで少々勘違いしてしまったところがあった。
 その後の一般公開は来てくれた人に説明した。後で思ったのだがそれの練習もすればよかった。あとは、他の作品を見て回ったりした。

プロコン2日目

 2日目は問題のデモ審査だ。2回のデモ審査、1回のマニュアル審査がある。1回目のデモ審査は決められた時間までに準備ができずにおそらく大幅減点。しかもデモ中に自分がミスをしてしまいあまり良くなかったと思う。2回目は審査員に機能が十分に伝わっていなかった。マニュアル審査は特に不具合がなく終われた。
 1日目に名刺()を配ろうと思ったのだが渡す機会がなかった。先生にそのことを言うと普通に渡してもいいと言われたので、2日めは作品を見に来たついでに名刺を配って回った。
 で、結果発表。結構手ごたえがあったので何らかの章は取れるだろうと思った。だが受け取ったのは敢闘賞。審査員の方がおっしゃっていたことから理由を考えてみた。

  • 作ったきりだった

     どこかの高専プロコンについてのエントリーにもあったのだが、作って終わりではなくその後のシステム自体の改良をしてなかったなぁと。今回の場合だと作った後消防署の方に話を伺ってそれをシステムにフィードバックをするということを怠っていた。自分は個人の作品も含めて作って終わりなので、こういうことも重要なのだと知った。

  • システムの完成度が不十分だった

     グループ全体が動けばいいやというポリシーだったので、少々不安定でも目をつむってた。その結果見た目は不細工で、システムも不安定だった。審査員の言葉を借りると、「製品」としてダメだったというわけだ。

 すごくどうでもいいが可愛い女の子がプレゼンをしたチームは入賞するというジンクスがあるようだ。個人的にはそれに名刺を作っていたチームも加えていいと思った。

何が面白くなかったの?

 メンバーの開発に対する姿勢だ。チームで一番声が大きい人が開発は仕事だと言ったせいかは知らないが、なんとなく「やらされている感」があった。そのせいかある機能が完成したらそれきりでそれ以上の改良をしようとしなかった。そしてその「やらされている感」というものはやる気の低減を招く(自分だけ?)。せっかくのプロコン、やっぱり創造的な活動をしたいっ!

改良点というか問題点

  • 機能が多すぎた

     今回作ったのは通報のシステムで、ビデオ通話が中心だったのだがそれだけでは他の製品であったのであれよこれよと機能を詰め込んでいった。その結果、プロコン当日に使われなかった機能までも作ることになってしまった。当然それを作っている時間もあるわけで、その時間を重要な機能の改良に当てればよかったなと思う。

  • デザインを考えていなかった

     自分のチームは全員男だったことは関係ないが、デザインがデフォルトのパーツを配置しただけで、見た目が地味だった。動作する上では関係ないが「製品」として見るならば重要だろう。

  • ツールの周知ができていなかった

     今回タスク管理にRedmineを導入してみたのだが、使い方を周知できていなかったみたいで皆使っていなかった。また、ソースの管理にはGitHubを使っていたのだがこれも使い方を周知できていなかったみたいで一部のソースはGoogle Driveに置いてあった。これらのツールは使いこなせば開発が若干でも捗ると思うので次は周知を徹底したいと思った。

  • お互いの状況をあまり知らなかった

     お互いの状況がわからないと進み具合を合わせられずに、結合するタイミングがずれて時間が無駄になってしまう。今後は上でも述べたがRedmineなどのツールを使ってチーム内の状況の共有をしたい。
     また、少し違うかもしれないが2人のメンバーが夏休みに免許を取りに行くという事を知らずに計画を立てていたので、一番開発できるはずの夏休みにあまり開発できなかった。

  • 割と無計画だった

  • チーム内の温度差

     これは割とどうしようもない気がするのだが、自分のグループは1人のメンバーが頑張りすぎていて、(自分も含めた)他のメンバーは置いてけぼりを食らってしまった図となってしまった。技術力の差はともかくとして、意識の差というか。こういう時はその1人のメンバーが皆に合わせるではなく皆を巻き込んだらいいんじゃないかと勝手に思っている(あくまで理想)。ある時先生とこのことについて話したのだが、こういうのはいかに他のメンバーを、ちょっと雑な言い方だが言いくるめられるかという事らしい。具体的には、他のメンバーにそれを行うメリットを感じさせれるかという事らしい。

  • 1人にやることが集中していた

     例の頑張りすぎている子の話だが、頑張りすぎているせいか、資料、ポスター作成や連絡などがその子に集中してしまっていた。また、チームメンバーの数人が教えてくん状態で(ググりもしないので半分呆れていた)いつもその子に聞いていたので、さらに負荷がかかることとなってしまった。教えてくん状態はまずググることを徹底すれば軽減するはず。

感想

 来年のプロコンはちゃんとした開発手法を取り入れようと思う。今のところアジャイルを考えているのだがプロコンのような開発にアジャイルが向いているかわからないので他の開発手法も調べる。次の開発は楽しくしたいなーと思った。

2013年11月18日月曜日

Rubyの式をTeXのソースコードに変換するgem作った

ふと思い立って作ってみた。勢いでRubygemsにアップロードしてみた(初gem)。

GitHub

RubyGems.org

gem install ratex

説明

 最近レポートを書くのにStackEditを使っている。このエディタはTeXで数式が書けるのだが、このTeXが自分の肌には合わなく、Rubyで書けたらいいなぁと思ったのが動機。
 このgemはRubyの式をTeXの式に変換してくれる。例えば、

puts Ratex.generate{ f(x, y, t) == 2 * sin(pi / 4 * sqrt(x ** 2 + y ** 2) - pi / 2 * t) }

で、

$$f(x, y, t) = 2 \sin(\frac{\pi}{4} \sqrt{x ^{2} + y ^{2}} - \frac{\pi}{2} t)$$

となる。わかりやすいよね!(強引

puts Ratex.generate{ f[n] == f[n - 2] + f[n - 1] }

$$f_{n} = f_{n - 2} + f_{n - 1}$$

となる。

仕組み

 今までの自分の知識をフルに活用した黒魔術バリバリのコードになっていると思う。詳しいことはQiitaのアドベントカレンダーに書こうと思う。

2013年11月7日木曜日

U20プログラミングコンテストに参加した話

 最近の活動としてU20プログラミングコンテストに参加して、そこでいろいろ得たものがあるのでそれを整理するという意味でこのエントリを書こうと思った。

提出した作品

「Cuick」(GitHub)というプログラミング言語。これは、速く書くことを目的としたプログラミング言語で、競技などの小規模なプログラム向けだ。バイナリコードではなく、C++のコードを生成する。開発言語はJavaで、パーサジェネレータにJavaCCを使わせてもらった。
速く書くために、

  • 糖衣(ショートカット)構文の充実
    →タイプ量の軽減や余計なことを考えずにすみ、速くなる
  • 覚えることは少なめに
    →調べる時間を減らすことで速くなる
  • デバッグ支援
    →デバッグの時間を軽減することで速くなる

という方針で言語仕様を決定した。

予選締切りまで

 原案を思いついたのはたしか6月ぐらいだと思う。最初はRubyとかPythonとかのLLの機能をつけた言語だったのだが、これだと存在意義がよく分からないので、目をつけたのが競技プログラミング。競技プログラミングは実装時間が重要なのでなるべく早くソースコードをかけるようなプログラミング言語を作ろうと考えた。
 7月半ばまでは言語仕様を考えた。なるべく早くソースコードをかける=>ソースコードが短くなることを考慮した。また、C++にはないデバッグ、テスト機能も考えた。@testは相談に乗ってくれた先生が元だ。また、このあたりから実装を始めた。とりあえずパーサーを作った。
 8月は夏休みなのだが自分は高専プロコンにも参加しているのでそっちとの兼ね合いをとるのが難しかった。高専プロコンを少しおざなりにしていたところがあったので、高専プロコンのメンバーにも怒られたりした。
 8月後半。締め切りの8月30日までにすべての機能を実装できないと悟ったので、バグを治すことにした。また、友人のアイデアでWeb上でもC++に変換できるようにもした(これはRubyのsinatraを使った)。締め切り当日まで予選資料を書いていたがなんとか間に合ってホッとした

最終審査会まで

 9月に入ってからは期末テストだったので、テスト勉強をしながら結果を待った。で、結果が来たときは結構嬉しかった(そのせいか勉強に身が入らずにテスト結果が微妙だったのは秘密)。
 最終審査会のプレゼン資料締め切りが9月後半で、テストが終わったのがその1週間前だったので普通に間に合うかと思ったが、高専プロコンも終盤でなかなか忙しかったので、あまり作成、練習時間が取れなかった。

最終審査会

 結論から言うと、もっとプレゼンを練習しておけばよかったと思う。
 自分は個人部門の最後だったので他の参加者のプレゼンを見ていたのだがあまり練習していなさそうな人が資料もなしにスラスラしゃべるのを見て、自分大丈夫かなぁと思っていたら見事失敗しましたよ。前に出たら緊張で頭真っ白になって原稿飛んだし、内容も内容で後から見たらここはこうしたら方がいいんじゃないかというところが何箇所かあった。緊張は練習すれば消えると先生が言っていたのを思い出した。内容も練習すれば問題点が見つかるものだと思う。
 また、Cuick自体の評価だが「ユニーク」とは言われたがそれ以上は言われなかった。色々理由を考えた。

  • アプローチが微妙だった

    審査員の方がエディタのスニペットや補完と違って学習コストがかかると仰っていた。それに自分はC++と構文を似せていると押し通したが、今考えるとプログラミング言語というアプローチが微妙なのかなぁと思ったり思わなかったり。

  • Cuickって結局何なのか

    審査員の方が仰っていたのだがCuickって実行環境としてなのか、ただ単にツールとしてなのかはっきりしない。確かに考えてみると中途半端な感じがする。だからなんだろうと思わなくもないが。同じ個人部門のFulynは実行環境だとはっきりわかった。

  • 競技プログラミングをよく知らない

    実は競技プログラミングはよくわからない(情報オリンピック予選落ちレベル)。すみません。よく知っている人に意見を聞けばよかったなぁと後悔する。とはいいつつもそういう人は周りにいないので聞けないが。

  • 目に見える具体的なデータが示せてない

    プレゼン前日にある問題をC++とCuickで解いてみたのだが、ぶっちゃけあまり時間が変わらなかった。問題によって個体差はあると思うが、正直Cuickの存在意義がわからなくなってしまった(ホビー言語としてなら十分面白いかも)

  • プレゼンがアレゲだった

というわけで、最終審査会当日はクタクタだった(東京までの移動もあるしね)。次の日は表彰式だが2時45分集合で、どうせなので東京観光していた。と言っても秋葉原に行っただけだがw 一人でぶらぶら移動するのが結構楽しくて、一人旅の面白さを知ってしまった気がする。

他の作品

 これはいいと思った作品が数点あるので感想を書いておく。

  • Arrow Judge

    オンラインジャッジを実現するためのオープンソースシステム。自分もオンラインジャッジシステムを作ったことがあるが、それよりも1枚も2枚も上手だった。例えば、セキュリティ対策だ。自分が作ったやつはセキュリティ対策は皆無だったが、Arrow Judgeはちゃんとセキュリティ対策をしておりすごいと思った。また自分で問題を投稿できるというところは使用場面もはっきりしておりいいと思った。

  • Fulyn

    OSECPU向けの関数型言語。関数型言語はよくわからないので、言語自体の感想は言えないが、まだ高級プログラミング言語がないOSECPU向けに作るのは少し興味が出た。プレゼンは全然わからんかったw

プレゼンを見ただけだがレベルが高いなーと思った。自分は彼らのようにはなれないが、自分の強いところを生かして彼らに並べるようになりたいなーと漠然と思ったわけですよ

感想

 今まで生きてきた中で一番濃い体験をしたと思う(小並感)。まず、自分より上の人と接したことでワールドというものを肌で感じたとこだ。井の中の蛙ってやつですよ。次に、自分はプレゼンが苦手だと決めつけていたがそれは練習してないだけだったということだ。
 こういう大会に出るといろいろ考えられて成長できるのでこれからもどんどん大会などの出場しようと思った。