思考のサルベージ(その６)
各工程で心がけたい思想を掘り起こしてみる
「単体テスト」について考えてみましょう。各工程のなかでは割と地味な作業ですが、この作業に割り当てられる時間は全体スケジュールに大きく響いてきます。
いつやるの？
V字モデルに従えば、
ですね。 ただ、私が経験した開発現場ではコーディング後にちゃんと単体テストの時間をとるところは少ないですね。実装がすんだらひとまず動かしそのまま結合テストへ、そしてBug対応が優先され、結局単体テストは後回しというケースが多いです。
何をどれだけやるの？
いろんな考え方があると思いますが、「単体テスト」を関数単位のホワイトボックステストと考えましょう。テスト項目は詳細設計書から作るということになります。ただそうなると、全ての関数に対して関数仕様書が必要です。詳細設計の期間にそれだけの事をする時間は正直ありません。結局時間の制約で、コードからテスト条件を起こして最低限カバレッジ100パーセントを目指すなんて本末転倒な作業になることが割と当たり前に起きますね。
ほんとの目的は？
当たり前のことですが前工程は後工程をスムーズに進めるためにあるということ。つまり、単体テストの目的は後工程の「結合テスト」に耐えうるように各関数、モジュールの品質を高めることにあります。
後付けの単体テストに意味はあるか？
本来の目的は果たせませんね。ただ、後工程に突入したとしても、関数、モジュール単位の「品質を高める」という作業は無駄ではありません。「ただの儀式」と考えて、やっつけ仕事にしないように心がけたいですね。
何か掘り起こせた？
- 本来の目的は「結合テスト」に耐えうるように各関数、モジュールの品質を高めること。
- 後付けになったとしても、各関数、モジュールの品質を高めるという目的は変わらない。
おしまい
V字モデルできちっとやれたら気持ちいいでしょうね。 いろいろなジレンマを抱えながら、多くの人がこれからも「単体テスト」に立ち向かっていくのでしょう。
Dask備忘録
はじめに
今回は、Daskを触ってみたので使い方を備忘録もかねてまとめてみます。
Daskとは
Pythonでデータ分析や機械学習をする際によく利用するライブラリがPandasですが、
Pandasで大容量データを処理すると、
- データがメモリに収まらない
- 基本的に単一スレッドで処理が行われるため処理速度が遅い
といった問題があります。
この問題を解決するのに並列・分散処理を行えるライブラリのDaskはよく利用されています。
Daskは主にNumPy、Pandas、PyToolzのAPIをもつデータ構造を提供しています。
| API | ベースパッケージ |
|---|---|
| Dask Array | NumPy ndarray |
| Dask DataFrame | pandas DataFrame |
| Dask Bag | PyToolz |
PyTorch超入門！
PyTorchを始めてみよう！
普段、TensorFlowで深層学習のソースを書いてた私……のはずなのですが、いろいろあってPyTorchを勉強する羽目（？）になってしまいました。が、
そもそもPyTorchなんてこれまでまったく触ったことないよ〜！！
これではあかん！！ということで、今回は勉強がてらPyTorchの超かんたんなプログラム（１００ステップ未満！！）を書いてみることにしました。
そのお題とは、、PyTorchで論理演算！！！
……って、なんてリソースの無駄使いなのでしょう(汗)
続きを読む初めての git-prompt
はじめに
git-worktree で複数のブランチを渡り歩いていると、今どこのブランチにいるのか？どんな状態なのか？がわからなくなることが多々あります。
プロンプトにブランチ名、状態を色で表現させる方法をご紹介します。git-prompt.sh のコメントの他、下記サイトを多分に参考にさせていただきました！
信号処理とMIPS・後編
ソフトウェアとMIPS
前編（信号処理とMIPS - Smile Engineering Blog）は、ハードウェアの性能を示すMIPS【Million Instructions Per Second 】について書きましたが、今回はソフトウェアのベンチマークとして書きたいと思います。
MIPS
コンピューターの処理能力を表す単位。コンピューターが1秒間に何百万回命令を実行できるかを示す。
前回も書きましたが、このような説明が多いです。
ソフトウェアの開発の要件として、信号処理では演算量（処理量）が必ず問われます。製品開発では、CPUをどれくらいのスペックにするかは言うまでもなく重要で、製品のコンセプトといっても過言でないでしょう。そのコンセプトを実現できるCPUを選定するのですが、売れる商品にするめにはコスト面も重要です。この辺の事情に非常に絡んでくるのがソフトウェアのリソースで、具体的には演算量とメモリサイズになります。
MIPS計算
そのソフトウェアが何命令か、Million Instructions Per Second なので1秒間に何百万命令か？ということですが、デジタル信号処理のソフトウェアを考えたとき、MIPS計算は次の式になります。
MIPS =命令数 × サンプリング周波数 / フレームサイズ ×
この時のフレームサイズとはサンプル数です。 FFT（高速フーリエ変換）を例にすると、FFT長（点数）がフレームサイズです。大きければ演算量もメモリも大きくなります。
続きを読む思考のサルベージ(その５)
各工程で心がけたい思想を掘り起こしてみる
「ハードウェアインターフェースの確認」を取り上げましょう。 組み込み開発では、ハードウェアもオリジナルというのが普通ですね。ソフトウェア開発側の視点でハードウェア機能の確認について考えてみます。
どんな機能が欲しいですか
開発のかなり早い段階で、ソフトウェアチームからハードウェアチームにどんな機能が欲しいか、どのように使いたいかを整理して伝える必要があります。まだ機能設計もできない状態でソフトと相性のいいハードウェアインターフェースを考えなければいけません。システム全体で「必要かもしれない」と思う機能については、遠慮なく要求しましょう。満額OKとならないかもしれませんが、要求を出さなければ、要不要の議論もできません。 ここで徹底的に議論しておかないと、こんな機能があればよかった、この機能はいらなかったと後で後悔することになります。
インターフェースの確定
ハードウェアのインターフェースが確定したら、念入りに確認しましょう。
- 実装合意した機能が記載されているか
- 使い勝手のよいインターフェースになているか
ソフトウェアと違い、ハードウェアは後工程での改修はできなくなります。問題点に気が付いたら早めに声をあげましょう。各種制約についてもしっかり確認しておきましょう。ハードウェアの制約でよくあるのは - 同時起動の制約 - レジスタ参照タイミングの制約 とかですかね。制約違反をしてしまうと、ハードを動かせなかったり、想定外の値をレジスタから読み込めなかったり、システムが正常に動作しなくなります。
逐次確認
設計工程、実装工程ではインターフェースを逐次確認しながら進めましょう。レビューの場で突き合わせをして、インターフェース違反、制約違反を発見し、バグを早期段階でつぶしておきましょう。テスト工程でハードウェアの絡んだ不具合を踏むとかなり厄介です。
何か掘り起こせた？
- 初期段階で徹底的に議論する
- ハードチーム、ソフトチーム間で常に情報交換できる環境を作る。
おしまい
組み込み開発は、ハード開発、ソフト開発の共同作業です。両者の関係が風通しの良いものになっているとやりやすいです。そのうえで、互いの主張を建設的に議論できると、より良いものができるんでしょうね。
