ETロボコンの利用の仕方

ETロボコン初参加してきました！

レポートはこの後に書きますが、是非、伝えたいことがひとつ！

ETロボコンはいいです。

こんなに割のいいモデリングの勉強会は他にないと思います。

何万も払ってセミナーに行くなら本気でETロボコンに取り組んだらいいと思います。

なんでもっと早く参加しなかったのか・・・。

www.etrobo.jp

年間スケジュールは、

・4月申込み

・6月くらいに技術教育

・地方での個別の勉強会も何回かあります

・10月地方大会

・11月決勝

ETロボコン2015年間スケジュール【ETロボコン2015公式サイト】

それで、今日は地方大会でした。

ETロボコンの利用の仕方

まず、技術教育の内容がいいです。

UMLのモデリング図の使い方がよく分かりました。

これまでも、一応、図がいろいろあるのは知っていました。

ダイアグラム別UML徹底活用 第2版 (DB Magazine SELECTION)

でも、クラス図とステートマシーンぐらいしか使っていなかった。

恥ずかしながら、

オブジェクト図って、なんで、あるんだろう？？いる？？

シーケンス図メンドクサイ。

くらいにしか思っていなかった。＾＾；

地方大会の特典審査は、ロボットの競争もありますが、モデリング審査がメインです。この大会は設計の大会なんです。

それで、地方大会での、モデリングワークショップがいい。

他の会社はどうか分かりませんが、自分の会社ではモデリングを完璧に出来る人はいないです。いろいろなチームのモデリング図に対して、審査員の人達がいろいろな観点から説明してくれます。

本当に参考になる！

最後に、懇親会。

今回は残念ながら参加出来なかったのですが、こんな感じで懇親会会場に各チームのモデリング図が張り出してあります。

そのモデリング図を眺めながらの懇親会になる訳です。

懇親会に残る人はそれほど多くない、それに比べてスタッフは多い。

審査員の先生を捕まえて、自分達のモデリングについて疑問に思っている事を聞きたい放題です。

これほど恵まれた勉強の機会はないと思います。それも、とてもいい質のいい講師の先生がいっぱい。

モデリング図も、自分達が何週間もかけて実際に作った図です。

セミナーみたいに数時間でちょちょいと作ったものではない。

しかも、講師がいっぱい。

今年は、時間がなくて（この言葉は使いたくないけど・・・）、本当にまったくETロボコンに取り組む時間を作ることが出来なくて、参加するだけで精一杯でした。

でも、ETロボコンの利用の仕方はよく分かった。

今度参加する機会があれば、本気で取り組んで、ガシガシ質問したいなぁ。

今日のレポート

今日の競技用のロボットです。

最初に試走会で、10分くらいテストできます。

会場はこんな感じ。

試走会の後、車検と呼ばれる、ロボットの検査があります。

その後、大会用の電池に入れ替えて、ロボットのコンフィグレーション。

いよいよ、本線スタート！

大会はこんな感じ。

自分達のチームの出番です。

ステージから見た会場。

合計2回走るのですが、

１走目は慌ててしまって、モータへの線が抜けて、一瞬で転倒・・・・。

2走目は、なんとかスタートたけど、ゴールまでたどり着かず・・・。

そんなこんなで初参戦の、結果は散々！

でも、楽しかった！

一緒に参加してくれた、会社の同僚に感謝です。

僕が時短勤務しているせいで、夕方には、まったく時間とれないし、

毎週水曜日朝７時～８時の朝活に付き合ってくれました。

SQiP研究会に木工教室になんやかんや忙しくて、週末も時間取れないし・・・。

本当に迷惑かけっぱなしだったのですが、でも、出れてよかった。＾＾

本当にありがとうございました。

legacycode.hatenablog.com

legacycode.hatenablog.com

legacycode.hatenablog.com

ソースコードの劣化を防ぐにはどうすればいいのだろうか？

昨日、「なぜ、ソースコードは劣化するのだろうか？」と言うことを考えてみました。

legacycode.hatenablog.com

昨日考えた事は、

ソースコードの性能：
新しい付加価値を追加するなど、新しいソースコードを作り出せる能力

ソースコードの品質：新しい付加価値を持ったソースコードの作りやすさ
保守性⇒変更をどれくらい容易に変更を行えるか？
可読性⇒ソースコードの読みやすさ

ソースコードを道具だと考えた場合、性能や品質を保つための使い方とメンテナンスの方法を考える必要がある。

使い方：劣化を最小限に防ぐようなソースコードの変更技術
メンテナンス：リファクタリング

劣化を最小限に防ぐようなソースコードの変更技術

について、少し考えてみたいと思います。

「劣化を最小限に防ぐようなソースコードの変更技術」として、一般的な考え方（？）が、「動いているプログラムは触るな」かもしれません。

「動いているプログラムは触るな」での、変更方針は、最小のソースコードの変更で変更を実現すること。
これなら、ソースコードの変更は最小限になって、ソースコードの劣化は最小に抑えられる。クーロンコードによって品質が良くなるという論文も、そんな考えから出てきているのかもしれません。

d.hatena.ne.jp

一見、「動いているプログラムは触るな」は、正しい方法に思える。

でも、なんか変ですよね。

ソースコードの品質：新しい付加価値を持ったソースコードの作りやすさ
保守性⇒変更をどれくらい容易に変更を行えるか？
可読性⇒ソースコードの読みやすさ

と考えた場合、「動いているプログラムは触るな」は、明らかにソースコードの劣化を引き起こす。

保守性も悪くなるし、可読性も悪くなる。

「動いているプログラムは触るな」は、ソースコードが紙媒体で、修正を加えると物理的に紙が痛む（消しゴムで消すとか）場合は正しいかもしれない、でも、ソースコードの品質を保つための変更方法としては適切ではない。

品質として何を選ぶかにもよる気もしますが。

ちょっと、「動いているプログラムは触るな」方式でソースコードを変更したらどんなことになるか？を考えてみたいと思います。

ソースコードは、物理的な構造を持ちませんが、論理的な構造を持ちます。
「動いているプログラムは触るな」方式で変更をすると、論理的な構造が崩れます。

論理的な構造は、本の構成みたいなもので、変更を繰り返すうちに、
１～10章あるうちの１章が全体の半分を占めてしまったみたいな感じになったり、
１～9章での話が、10章で実は全部嘘でしたみたない展開になったります。

イメージで言うとこんな感じです。

なぜ、「動いているプログラムは触るな」は根強い人気？

「動いているプログラムは触るな」で、ボロボロになったソースコードは、いたるとこに転がっている。
経験のあるプログラマーなら、「動いているプログラムは触るな」は、あまり良い方法ではないと、うすうす気が付いていると思います。でも、現在進行形で「動いているプログラムは触るな」方針で変更されている現実がある。

それは、なぜだろうか？

一つに、ソースコードの変更に対する技術が確立されていないと言うことがある気がします。ほとんどが、新しいソースコードを作るための技術で、ソースコードを上手く変更する手法といった本はあまり見たことない。

XDDP:派生開発に最適化した開発プロセス
ソースコードの劣化を最小限に抑えるようなプロセスを可能にする。
ただ、この劣化を最小限にと言うのは、コーディング技術ではなく、仕様漏れによる手戻りや、間違った箇所の変更など、無駄な変更を最小限に抑えると言う意味。

「派生開発」を成功させるプロセス改善の技術と極意

リファクタリング：
外部の振る舞いを保ちつつ理解や修正が簡単になるようにソフトウェアの内部構造を変化させること。

リファクタリングする（動詞）：
一連のリファクタリングを適用して、外部から見た振る舞いをの変化をなしにソフトウェアを再構築する。

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

ソースコードの劣化を防ぐ答えがここにありそうです。

ソースコードの劣化（保守性、可読性）を防ぎ、価値を生み出すソースコードを保つには、リファクタリングが必要なだと思います。

リファクタリングを常に実施しながらコーディングする方法としてはテスト駆動開発があります。

テスト駆動開発入門

既に劣化してしまったソースコードをリファクタリングする方法として、レガシーコード改善ガイドがあります。レガシコードと戦うプログラマのバイブルのような存在の本です。

レガシーコード改善ガイド (Object Oriented SELECTION)

じゃあ、テスト駆動開発してリファクタリングを日常的にすればいいじゃないかと思うのですが、やってみたことある人は分かると思いますが、ここの壁が大きいんですよね。

1年前くらに書いた、レガシーコードへの取り組み。

現場にテスト駆動開発を導入してソースコードを改善しようと悪戦苦闘していました。

1年間に比べたら、今はずいぶんと改善された気がします。 

legacycode.hatenablog.com

今日は、時間がなくなったので、次回、なぜ、リファクタリングが選択されずに、「動いているプログラムは触るな」が選択されるのか考えてみたいと思います。

なぜ、ソースコードは劣化するのだろうか？

ソフトウェアの開発中にソースコードの劣化と言う話をよく聞きます。

『ソースコードの劣化』とは何を意味しているのだろうか？ということを考えてみたいと思います。

ソースコードは、コンピュータへの指示書のようなもので、コンピュータはそのソースコードに従って動きます。（厳密にはコンピュータは直接ソースコードを理解出来ないので何段階かの翻訳が入ることになるのですが、それは省略します）

プログラマーとは、ソースコードを書くことを職業としている人です。
ソースコードは、パソコン内にあるデジタルなファイルなので、物理的な紙などと違って、時間の経過よって色あせるとか文字が見えなくなるといった物理的な劣化はしません。

では、何が劣化するのでしょうか？

ちょっと、『劣化』とは？について調べてみます。

kotobank.jp

ソースコードの劣化とは、ソースコードの性能・品質などが低下して以前より劣ってくること。

ところで、ソースコードの性能とは何でしょうか？

これはソースコードを使う目的を考えれば、分かります。

今のソースコードを使って、新しい価値を持ったソースコードを作り出すことです。

ソースコードの性能：
新しい付加価値を追加するなど、新しいソースコードを作り出せる能力

その場合の品質とは何でしょうか？

品質 - Wikipedia

「本来備わっている特性の集まりが、要求事項を満たす程度」

こっちの方が分かりやすいかもしれません。

ソフトウェア品質 - Wikipedia

「品質とは誰かにとっての価値である」

その道具としての機能が、それを使う人の要求をどれくらい満たしているか？ということだろうと思います。

プログラマが、今のソースコードを使って、新しい付加価値を持ったソースコードを作り出したいと言う要求を、どれくらい満たすか？
その尺度として保守性と可読性がよく使われます。

ソースコードの品質：新しい付加価値を持ったソースコードの作りやすさ

保守性⇒変更をどれくらい容易に変更を行えるか？
可読性⇒ソースコードの読みやすさ

ソースコードの性能・品質は、なんとなく分かりました、それでは、

いつ劣化が発生するのでしょうか？

先に説明しましたが、ソースコード自体はデジタルなものなので時間が経過しても劣化はしません。

ソースコードが劣化が発生するのは人がソースコードを使用する時、つまり、ソースコードを変更する時です。

ソースコードはコンピュータにとっては指示書で、コンピュータがソースコードをいくら使っても劣化しません。

なぜ、ソースコードが劣化するのか？
それは、人がソースコードを変更するからです。

ソースコードが劣化する時：

人が今あるソースコードを使って、新しいソースコードを作り出す時

なぜ、ソースコードが劣化するのか？

人がソースコードを変更するから 

劣化を防ぐには？

では、どうすればソースコードの劣化を防ぎ、ソースコードの性能を保つことが出来るのでしょうか？

そこで、少し無理はありますが、ソースコードを新しいソースコードを生み出す道具と考えてみたいと思います。
ところで、他の道具はどうやって劣化を防いでいるのでしょうか？

車の場合は、車検、走行前の点検、など定期的にメンテナンスを行います。
また、日常的にどんな運転をするかも、劣化に影響します。

どんな道具でも長く使おうと思うと思うと、劣化を防ぐために使い方やメンテナンスをする必要があります。

使い方：劣化を防ぐような運転技術
メンテナンス：車検、日常点検

ソースコードの性能や品質を保つために、どんな、使い方、メンテナンスの技術があるでしょうか？

例えば、こんな感じでしょうか？

使い方：劣化を最小限に防ぐようなソースコードの変更技術
メンテナンス：リファクタリング

ソースコードのメンテナンスを考えると、

・いつメンテナンスするのか？
・どこまでメンテナンスするのか？
・どのようにメンテナンスするのか？

など、ソースコードのメンテナンス計画を立てる必要がある気がしますが、ソフトウェア開発現場で、ソースコードのメンテナンス計画を立てる話を聞いたことがありません。

ソースコードを道具として考えた場合、メンテナンスするという概念がなければソースコードが劣化するのは当然な気がします。

僕が知っているメンテナンス計画に近いもの

テスト駆動開発

実装の前に単体テストを先に各開発手法。
１．テストを書く⇒テスト赤（テストNG）
２．コードを書く⇒テスト緑（テストOK）
３．リファクタリング⇒テスト緑（テストOK）を保つ
１～３を繰り返す。コードを書く＝リファクタリング。
常にメンテナンスしながらコードを書いていく。
1行新しいコードを書くたびに、メンテナンスを行う。

テスト駆動開発の場合には、

テスト駆動開発入門

XDDP

派生開発を制御するための技術

変更要求仕様書、トレーサビリティマトリックス、変更設計書の3点セットにより、効果的なレビューを可能にし、ソフトウェア改造時の混乱を防ぐ。

XDDPにリファクタリングを制御方法も触れられている。
・リファクタリングプロジェクト

　プロジェクト開始前にリファクタリングだけをしてしまう。
・小さなリファクタリング

　今回変更する変更箇所に限定したリファクタリング

「派生開発」を成功させるプロセス改善の技術と極意

以前読んだ本では、今日の作業を始める前に、前日のコードの整理から始めるということをしていて印象に残っています。

30日でできる! OS自作入門

ソースコードを劣化させないためには、各現場にあったメンテナンス計画を立てる必要がある気がします。

・いつメンテナンスするのか？
・どこまでメンテナンスするのか？
・どのようにメンテナンスするのか？

そんな、ことが大切でないかな？と考えています。

ETロボコンに出よう！ ようやくここまでやってきたよ 試走会１

今年のチャレンジとして参加することにしたETロボコン。

会社で同好会を作って、今年2月ごろから、ぼちぼちと活動していたロボコン部。

僕が時短勤務をしている影響で、活動は朝7時から会社の会議室です。

legacycode.hatenablog.com

 先週、日曜日、試走会に行ってきました。

試走会というのは、本番のコースでの練習走行です。

会場は京都コンピュータ学院。ステージの上にあるのがコースです。

コースはこんな感じ。

出場チームが思い思いにロボットの試走を開始。

もちろん、僕たちのチームも。

ちなみに、競技に使うロボットはこんなんです。

こいつは、立ち上がってコースを自走します。

みなさん、コースの明るさを測ったり、長さを測ったり。

仕込んだアルゴリズムを試したり。

今年の2月からぼちぼちと始めていたはずが、典型的な学生症候群で試走会1週間前くらいから慌てて本気で頑張り始めた、我がチーム・・・。

僕も試走会2つか前に慌ててコードを読んで、動作原理を理解した・・・。

いや～、もっと、早くからコード読んどけば、いろいろ試せたのだが、と後悔しても時間は戻らない。

でも、まあ、何事もやってみるのが一番手っ取り早い。

ドキドキしながら試走会に参加したけど、まあ、大体、大会のレベルも分かったし。

とりあえず、今は、締め切りが迫っているモデル図の完成を急がないと。

とりあえず、スタートラインに立てたのでOK。

巨人の肩に乗る方法を学びに SQiP研究会に行ってみた

 今年一年、SQiP研究会に行くことにしました。

www.juse-sqip.jp

１５日（金曜日）が第１回目でした。

この研究会は、午前が講義で、午後が分科会になっています。

午後の分科会は、いろいろ選べるのですが、僕は第６分科会派生開発を選びました。１回目が終わった感想などを書いてみたいと思います。

よかったこと

午後の分科会が特によかったです。（勿論、午前も勉強になりましたが）

第１回目は、自己紹介をした後に、自分の職場の問題を上げて、こんな問題をこの研究会で解決したいと、研究員から発表していきます。

研究員の問題に対して、主査、副主査、アドバイサーが、質問して話を聞き出して、ぶった切るような感じでした。

本当に、その切り方が、爽快。

切れる刀とは、こんな刀なんだろうなぁ、と、ただ、関心。＾＾；

主査、副主査、アドバイサーの問題解決のアプローチの一面を見れただけで参加してよかったと思えました。

問題を解決できる人は、こんな考え方をするのかと、とても、参考になりました。

後、現場は違っても、同じような悩みを抱えていることを改めて実感。

自分が感じた問題解決のための力

• 正しい情報を集める力（聞く力）
• 整理する力
• 分類する力
• 引き出しの多さ（自分の経験、知識とつなげる力）
• 実行する覚悟

研究員が話す、ぐちゃぐちゃに絡み合った問題を、まず、解きほぐしていきます。

それには、聞く力と整理する力が必要。

本当に、問題を解きほぐす力が、すごいなぁと思いました。

ちゃんと聞く、違和感があればすぐに質問する。

それで、問題をどんどん整理していく。 

その問題を、これと、これは、違うと丁寧に分類する。

そして、いろいろ混ざっている問題から、純粋な問題を一つ一つ丁寧に取り出していく。

分類した問題を、自分の経験や知識とつなげる。

本当に、引き出しが多い。

知識を沢山知っている人は、結構いる気がします。

でも、その知識を、ちゃんと使いこなせているかと言うと、怪しい。

技術者として、ちゃんと年を重ねるとこんな姿になるんだと、ちょっと感動しました。

そして、最後にとても、重要な言葉を頂きました。

「常に背中に拳銃を突きつけられているつもりでやりなさい」

正しく分析出来ても、実行力がないと何の意味もない。

これを聞いた時には、内心では、大げさなとも思ったのですが。

拳銃と言うと、物騒ですが、結局、問題から逃げない姿勢と言うことなんでしょうね。その積み重ねが、今の自分を作る。

その意識の積み重ねが、今の姿を作ったのかと思うと、この言葉の重さを感じます。

巨人の肩に乗る

「巨人の肩に乗る」、よく使わる言葉ですが、なかなか乗りこなすのは難しい。

そんなに簡単に載せてくれる巨人は少ない気がします。

乗ったのはいいけど、しがみついているのが精一杯とか。

乗ったのはいいけど、操作の方法が分からないとか。

乗ったのはいいけど、暴走して自爆したとか。

乗ったのはいいけど、もう、すでに動かないとか。

乗ったのはいいけど、降りれないとか。

でも、自分の今の状態は、そもそも、

巨人にどう登ればいいのか分からない！ 

今年１年で、巨人の肩に乗る力をつけたいと思います。 

乗ってみないと、操り方も分からない。＾＾；

レゴ部 ようやくロボット動いた

レゴマインドストームの大会、ETロボコンに 参加すべく、２月から活動スタートしたレゴ部。

２週間に１度の頻度で、朝７時～８時で会社で活動しています。

ＥＴロボコンに出よう！ - 道草道

今日で活動４回目。

動かした、ロボットはこれ。

前についているのは、色センサ。

こんな感じの黒い線の上を自走するプログラムを最初に作って見る予定です。

まず、何するか？

・白と黒を識別するセンサーの動作をテスト

・簡単なアルゴリズムを実装

　１．黒なら右に動く

　２．白なら左に動く

フィーリング的に動きそうなきがするが？？

・白と黒を識別するセンサーの動作をテスト

黒い色の識別の確認。

黒なら目がぐるぐる。

白なら目がぐりぐり。

ここまで、意外と素直に動いた。

さすが直観ベースのプログラミング環境です。 

大人のレゴ ３ ブロックを組み立てるプログラミング 1 - 道草道

・簡単なアルゴリズムを実装

　１．黒なら右に動く

　２．白なら左に動く

実装結果がこちら。

あまり文法に慣れていないので、間違っている可能性あり。

いざテスト。

走り出した。

暴走中（笑い）

本当は、線の上を走ってほしいのですが。。。

でも、まあ、ほんの少しでも、続けていれば前に進むのを実感中です。 

レガシーコードの変更は急いではいけない

仕事の話です。

社内の工場で使うソフトウェアを作る仕事をしています。

最近、お仕事をしていただいている派遣さんに、ひたすら我慢して単体テストを書いてもらっています。

そこと、そこを、ちょろっと直せば修正は済むのは、分かっています。

でも、どうやってテストしますか？

どうやって、既存の振舞いを変えていないことを証明しますか？

今後も、手動でテストし続けるつもりですか？

品質を確保して速いのは素晴らしいですが、速いだけなのは意味がない。

なので、急いではいけない。

まずは、単体テストを書きましょう、と言って我慢してもらっています。

そのうち効果が出ますから、と。

ここは、がまん、がまん、がまん。

やると決めたら、あとはやるだけ。

と、自分に言い聞かせている、今日この頃。