高専ロボコン関東甲信越地区大会と九州沖縄地区大会を見てきた
今年の関東は山梨県開催だったので堂々と関東「甲」信越大会*1を名乗れますね!!!…というのは置いておいて。非常に腹立たしいというか悲しいというか、そんな気持ちになったのでちょっとぶちまける。
歩行出来ない
もう2足歩行連続4年目ですよ。なんで歩けないんですか。しかも今回曲がれるようにする必要すらないのに。
機構に制御が追い付いていない
どうして運動学も知らないで閉リンクやってるんですか。閉リンクは駆動制御がきっちりしていないと使い物にならないんですよ。先生方誰か止めなかった(あるいは必要な知識へのポインタを示さなかった)んですか。いつだかの文化祭で私「運動学どうやってるんですか」って聞きましたよね、そこで誰一人として調べなかったんですか。
そもそも完成してない
論外。1週目だからとか言うな。
その反面…
一方、非常に完成度の高いマシンを作り上げてきた高専も当然いくつかあるので、全国大会には期待したいところですね。
ちゃんと自動制御のサポート入れれば最速4-5秒でタッチダウン成功できると思う。四国の某高専あたりは地区の段階で操縦訓練だけでそのレベルに到達してきそうだけど。
電波
開場で2.4GHz帯使うのはやめてくださいマジで。冗談抜きに。逆に携帯電話の規制はあんま意味ない(はず)なのでそこまで規制するのはやりすぎだと思う。あと27MHz帯とか40MHz帯とかは悪い話しか聞かないので可能ならば避けたほうがいいのでは。特に電波にする必然性が無いなら赤外線(38KHzはNG)が一番安定する気がする。たぶん。
10/11追記 455kHzの赤外線受光部は全部ディスコンのようなので、57kHzを使うかTPS703あたりの出力を自前でフィルタするかしないとダメですね。今TPS831とか在庫持ってる人はラッキーです。
全般的に
強いロボットが負ける原因は大体「操縦者のミス」か「整備のミス」なので、どうやってもリカバーできない前者の発生確率を減らすためになるべく自動制御を取り入れたほうがいいです。勝ち負け云々だけでなく、ロボットを扱う以上「機械屋だから制御わかんない」なんて言ってたらいつまでたっても半人前にすらなれない、という認識も持ってほしい。
プログラミングの魔導書 真・最遅レビュー
らんはくん(id:ranha)が最遅レビューを名乗っているので対抗して真・最遅レビューでも書こうかと思います。
出版の概要・購入方法についてはこの記事を読んでいる人なら当然予約済みであるはずなので省略して、個人的にオススメの記事を紹介します。
風とF#とメビウスの輪
のぶひさ先生(id:Nobuhisa)の記事。記事別人気投票とかやったらぶっちぎりでNo.1になるのでは、というくらい素晴らしい記事。テンポのいい文体でF#の魅力を次々に刷りこまれていきます。私はこの記事に感化されてF#を始める気になりました。F#いいかも!*1
D言語の設計とか進化とか
つけ麺おじさん(id:repeatedly)の記事。D言語はコミッタ達の発言を見ていても普及させたいのかさせたくないのか未だによくわからないのですが、どうやら最近はだんだんと安定に近づいて行っているようです。C++とはお互いに影響を与え合っていて、多くの機能が両方で使えるようになっていますが、CTFEやshared等C++には無い非常に便利な機能もあって非常に羨ましい限りです。「C++では進化が遅い!!!」と感じている人はD言語は最も有力な選択肢になると思います*2。
The Door To Dependent Types
きなば先生(Kazuhiro Inaba)の記事。「型」の概念は静的型付言語使用者には特になじみ深いと思いますが、静的に決まるはずの「型」を動的な属性である「値」に依存させようという話。C++erが読むとconstexprを使う時に「Dependent Type欲しい」と譫言のようにつぶやくようになるので要注意*3。菊池先生(id:kikx)の「証明支援系Coqの紹介」と合わせてお読みください。
Boostを使い倒してTwitterクライアントを作る
最後に、私の記事の紹介です。レビュアー様に幾度となく校正をして頂き、何とか衆目に耐えるレベルの記事に仕上がったと思います*4。特に「C++はあまり得意じゃないけど使わざるを得ない」人に読んでいただければ幸いです。ほかの雑誌や連載記事では「作ってみた」系の記事は書きにくいと思いますので、今後もたまにはこのような実践系の記事があるといいなと思います。個人的にはHaskellでGUIとネットワークが絡む(しかもWindowsでも動く)アプリケーションを作る的な記事が読みたいですね*5。
尚、PDF版だけで済ませようとしている人も、著者陣にサインをもらうために書籍版セットでの購入をお勧めいたします*6。
それでは皆様も魔導書と共に快適で楽しいプログラミングライフをお楽しみください。
Thanks for review: id:zakkas783 id:cpp_akira id:redboltz
Qt ＠福岡 第4回勉強会 で喋ってきました
T/O …と言いたいところだけど、いろいろ補足。
各コンテナのパフォーマンス差について
発表中に出したベンチ結果は1千万要素のint(つまり40MB)とかそういうレベルで、ようやく1sec以下の差になろうかという程度です。その程度の差よりは「楽に安全に使う」ほうが重要です。
# ベンチ結果はinline化を排除したりとかあるので、覚えてればそのうち公開します。STLだけの結果はそろそろstd::dequeについて語ろうか - kikairoya’s diaryを見てください。
例外安全について
C++に限らず、「失敗するかもしれない操作」を行う時にはすべての場面で例外安全の考慮が必要です。基本的な例外安全が提供されてないと、例外が飛んできたときに通常シーケンスへの復帰どころか、正しいエラー終了すら不可能になる場合があります。例外が規定されている言語を扱うすべてのプログラマはExceptional C++, More Exceptional C++を読まなければなりません(MUST)。
CoWについて
GC無しでCoWを安全に実装するのは非常に大変だし、出来たとしてもマルチコアでスケールしないのでCoWが必要になるまではしないのが正解です。
「行儀の悪いコード」について
発表中にも発言した通り、「古くはそれが一般的だったが最早時代にはそぐわない」という意図です。古くから存在しているQtの、当時のコードについて、当時のコンテキストを現代の視点で善悪付けることの愚は理解しているつもりですが、同じようなコードがもしもここ数年の間に新しく書かれていたとしたらそれは容赦なくdisります。
発表に使ったスライドはこちら。qtf4.pdf
VMware ToolsをLinux 3.0ゲストで使う
[open-vm-tools というので動きました。
手段に縛りをかけるのは筋が悪い
制御に縛りをかけたロボコンイベント: kirikuzudo blog since 2010
競技に於いて達成したいことはあくまでゴール・得点であって、手段の制限はゲームの適切な運用のためでしかない。
コントローラに何を使うとか、構造体の材質に何を使うとかはどうでもいいことで、やりたいことに一番適した手段を選択する能力のほうが重要(その意味で、昨今の二足歩行縛りは好きじゃない。二足歩行させるための二足歩行でしかなく、それによって何か得をするわけではない)。
せっかくゼロから組み上げるという経験をするチャンスをわざわざ潰すこともない。出来合いのものを使うだけなら誰でもできる。また、既に「制御を簡単にして機構で実現する」ではなく、「機構は単純にして制御で実現する」時代なので、あえてそれに逆らう理由もないし、実際コストを下げようと思ったら機構は簡潔にしないといけない。
純粋にアイディアだけで勝負したいのなら、もっと年齢が下の、小学校高学年か中学生を対象にしたほうがいい。
Linux2.6.39ゲスト上のVMWare-Tools用パッチ Patch for VMWare-Tools on Linux-2.6.39 Guest
https://sites.google.com/site/kikairoya/file-cabinet/vmtool_linux2_6_39.patch?attredirects=0&d=1
コンパイル通るようにしただけ。詳しい人いたらレビュー求む。
I don't know inside Linux, request for comment.
使い方: /tmp/vmware-tools-distrib/lib/modules/source/*.tar を展開して、パッチを当てて、元のとおりにtarにパックした後、通常通り./vmware-install.plを実行。
Usage: extract /tmp/vmware-tools-distrib/lib/modules/source/*.tar, apply patch, re-pack to tars, finally, do ./vmware-install.pl normally.
6/12追記
たまにIllegal Seekが出る。。。
