16224」と評価する。16384」が答えとなる。組み方自体は個人個人でバリエーションはありますが、計算式としては結局同じことをやっていたはずです。動作確認中にバグを発生させた人はいませんでした。結局、最後まで解けなかった2人のうち、1人は「AZ=52、BA=28」となってしまう不具合を解決できなかったそうです。1人は完全に問題を読み間違えていたらしく、実際のExcelファイルを読み込んで、ファイル内に書きこまれた値と列名をマッピングするプログラムを書こうとして時間が足りなくなったそうです。う〜ん、すごい勘違い・・・。最終手段として用意しておいた「コメントで逃げる」作戦を選択したメンバーは誰もいませんでした。これを使う人はいないですよね〜。おいらとしても使ってほしくないです、ほんまに。ちなみに、「これまで全く同じプログラムを書いたことがありますか?」という質問に対しては、全員がNOと答えました。(おいらはその昔、VBAで作ったような気がしますが。)ただ、問題を解く際に基数変換の知識を応用した、と答えたメンバーは何人かいました。投票&開票結果さて、全員の解説が終わり、いよいよ投票によるベストプログラマの選出です!ドキドキドキ・・・。今回の優勝者は誰でしょう??優勝者は・・・前回と同じAさんでした!2冠達成です!2位も前回と同じMさんでした。3位は前回欠席していたKさんです。いうわけで、1位と2位は前回と同じプログラマが選ばれる結果となりました。獲得ポイントを見ても、1位28点、2位23点、3位10点なので、1位と2位のメンバーは3位のメンバーにかなり差をつけています。前回と同じく、ごちゃごちゃしたプログラムよりも、ぱっと見、シンプルで洗練されているように感じるプログラムの方が、高い評価を得ています。(ある意味当然ですけどね)それから、このコンテストが前述した「目的」を実現するのに役立っているかどうかもアンケートしてみました。これについてはほぼ全員からYESという回答をもらいました。ムダにはなっていないようなので、とりあえず安心しました。後編(第2問)でも改めて投票を行い、ランキングを付ける予定です。Aさんはこのまま3冠を達成するのか?ちょっと興味深いポイントです。前編のまとめ今回こそは全員が時間内に解答できるように、じっくり策を練ったつもりだったのですが、結果は期待と大きく外れてしまったので、ちょっとヘコみました。「これはどう見ても楽勝でしょ」と思うぐらいのレベルじゃないと、全員が初見で時間内に解答するというのは難しいのかもしれません。あと、出題者であり、すでに別の言語で解いたことのあるおいら自身が終始苦戦してしまったというのも、個人的には痛かったです。解答時間中に嫌な汗をいっぱいかいてしまいました、ホント・・・。そんな反省点はありますが、見方を変えればFizzBuzzみたいな簡単すぎる問題よりも、ちょっと難しくて時間が足りない問題ぐらいの方がスリリングで面白いのかもしれません。一応、コンテストですから。問題が難しいと他人の書いたロジックが即座に理解しにくくなる、という弊害も垣間見えました。後編が残っているので、前編のまとめはこれぐらいにとどめておきます。今回は上位3人のプログラムとおいらが書いたプログラムを載せておきます。前回と同様、コンテストで使用したスライドも載せておきますので、ご参考までにどうぞ。1位の人が書いたプログラム最初にハッシュを手書きで作ってしまっているのが少し気になりますが、それ以外はかなりシンプルにまとまっていると思います。"$answer\n";2位の人が書いたプログラム最初にコメントを書いてからプログラムを書いていったそうです。こちらはハッシュではなく、ord関数を使ってアスキー文字コードを取得しています。個人的にはこちらのアプローチの方が洗練されていて好みです。3位の人が書いたプログラムこちらはハッシュでもord関数でもなく、文字列とindex関数を使っている点がユニークです。同じ問題なのにそれぞれアプローチが全然異なっていることがよくわかります。"$result\n";おいらが書いたプログラムアプローチが違うという点では、おいらもかなりアプローチが違います。Test::Moreを使ってテスト駆動開発(TDD)しました。テストしやすいように、メインロジックはモジュールとして別ファイルにしてあります。いやTDDで作ってたのもおいらだけだったなあ・・・。ループ処理ではなく再帰を使ってメインロジックを実装しました。再帰を使った理由はまず最初にF#でこの問題を解いたからです。F#ではリストを使った再帰処理が面白かったので、Perlでもそのアプローチをそのまま採用しました。'XFD');当日使用したスライドこんな感じのスライドでメンバーに説明してました。動作確認のスライド(P20)以降は第1回とほぼ同じですね。Itoあわせて読みたい第1回社内プログラミングコンテストの様子をまだチェックしていない方はこちらをどうぞ。tryまた、後編の様子はこちらでどうぞ。*2:上限なしというのは、Excelと同等とは言ってもIVやXFDまでではなく、それ以上の値も許容すること、という意味です。実際のプログラムではデータ型やメモリの制約があるので、完全に上限をなくすのはほとんど不可能です。「上限はXFDとする」のように書くと、「3桁の場合の計算式、2桁の場合の計算式、1桁の場合の計算式」みたいな柔軟性のないロジックを書く人がたまに出てくるので、こういう注釈を付けました。Qiitaに「【短命に終わった】国...2015-02-09CodeIQに「ビンゴカード作成問題」を出題しました。会社で紹介した正規表現の入門的なテクニックをこっちにも載せ...2010-08-25ビジネスロジックをストアドに埋め込むのは避けるべきストアドの中のビジネスロジックは読みにくいです。はてなブログPro株式会社ソニックガーデンで働くRubyプログラマ。2017年11月に「プロを目指す人のためのRuby入門」を出版。blog)はてなブログをはじめよう!JunichiItoさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。