プロのプログラマとは？
リンクにあるエッセイの中では、著者の「プロのプログラマとは？」という問いの答えが書かれているが、かなり同意。
とくに、「キャリアに責任を持つ」という内容では、自分の成長は自分で責任を持つということが書かれていて、若手に限らず、中堅（という年代）でも足りない人がうちの会社には多い。
休日などに技術的な勉強をすることを薦める（風潮から指示できないｗ）のは、「ブラックだ！」みたいなことを叫ぶ人がいるが、まさに「自分のキャリアに責任を持っていない」人たちだと思う。
プログラマは創造的な職業で、常に最先端を追い求めていないと「過去の人」にすぐになってしまうのに、会社の就業時間内でしか技術に接したくないという。
医者、弁護士はいうに及ばす、画家や音楽家、料理人、美容師など、創造的な仕事では、仕事が終わってから勉強を重ねて、ようやく一人前になれるというのに、、、技術が嫌いなら仕事変えれば？と思ってしまう。
「休み？休みなんか要るんですか。だって勉強は労働じゃないでしょう」
ということを話したらしいけど、この言葉には衝撃が走った！！
確かに、勉強は自分のためで、だからこそ自分の成長につながるわけだけれども、どこか労働と同じように考えてしまっていた自分がいたから。
「勉強」というものの考え方一つでも、トップランナーとの差を見せつけられたと思いました。
clang de coverage!
clang でカバレッジ計測
clang+llvm と CppUTest を使って、組み込み向けのUT環境をつくろうとしているが、カバレッジ計測を行う場合は、CppUTestも clang+llvm でコンパイルしておかないと、リンクできなくなる！？
- CppUTest → gcov をリンクしようとする
- テストコード → clang_rt.profile-xxx をリンクしようとする
という状況になる模様。
CppUTestの組み込み機能を利用せずにカバレッジ計測を行えばいいのかもしれないけど。。。
まずは CppUTest の使い方を勉強しているので clang+llvm は諦めるかな。
ほとんどのライブラリでは影響が無いのだろうけど、こういったコンパイラのミスマッチによるリンクエラーが出る可能性があるということは clang+llvm を利用する上では意識する必要がありそう。
- gcov のみリンクした場合
/path/to/source/xxxx.c:(.text+0x232): `llvm_gcda_start_file' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x258): `llvm_gcda_emit_function' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x26c): `llvm_gcda_emit_arcs' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x28d): `llvm_gcda_emit_function' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x2a1): `llvm_gcda_emit_arcs' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x2c2): `llvm_gcda_emit_function' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x2d6): `llvm_gcda_emit_arcs' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x2f7): `llvm_gcda_emit_function' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x30b): `llvm_gcda_emit_arcs' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x310): `llvm_gcda_summary_info' に対する定義されていない参照です /path/to/source/xxxx.c:(.text+0x315): `llvm_gcda_end_file' に対する定義されていない参照です
- clang_rt.profile-x86_64 と gcov をリンクした場合
/opt/toolchains/clang+llvm/lib/clang/3.7.0/lib/linux/libclang_rt.profile-x86_64.a(GCDAProfiling.c.o): 関数 `__gcov_flush' 内: GCDAProfiling.c:(.text.__gcov_flush+0x0): `__gcov_flush' が重複して定義されています /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcov.a(_gcov.o):(.text+0x20d0): ここで最初に定義されています clang-3.7: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [tests/console_test] エラー 1 make[1]: *** [tests/CMakeFiles/console_test.dir/all] エラー 2 make: *** [all] エラー 2
- clang_rt.profile-x86_64 のみリンクした場合
/opt/toolchains/cpputest/lib/libCppUTest.a(MemoryLeakWarningPlugin.cpp.o): 関数 `_GLOBAL__sub_I_65535_0__Z44cpputest_malloc_location_with_le ak_detectionmPKci' 内: /home/workbench/public/workspace/cpputest-3.6/include/CppUTest/TestFailure.h:113: `__gcov_init' に対する定義されていない参照です /opt/toolchains/cpputest/lib/libCppUTest.a(MemoryLeakWarningPlugin.cpp.o):(.data+0xc0): `__gcov_merge_add' に対する定義されていない参照です /opt/toolchains/cpputest/lib/libCppUTest.a(CommandLineTestRunner.cpp.o): 関数 `_GLOBAL__sub_I_65535_0__ZN21CommandLineTestRunnerC2EiPPKcP10T estOutputP12TestRegistry' 内: ...
cmake 使ってみた
しばらくおいたままになっていたけど、 cmake を使ってみました。
とりあえず、プロジェクト構成は以下のようにしました。
cmake_sample/ + product/ | + main.c | + CMakeLists.txt + test/ | + main1_test.cpp | + main2_test.cpp | + CMakeLists.txt + CMakeLists.txt
実行モジュールのコードは product/ ディレクトリに配置し、テストコードを test/ に配置しました。
- cmake_sample/CMakeLists.txt
# 使用する cmake のバージョン.
cmake_minimum_required(VERSION 3.1)
# プロジェクト名.
project(embryoshell)
# バージョン番号.
set(MAJOR_VERSION "0")
set(MINOR_VERSION "0")
set(BUILD_VERSION "0")
set(SERIAL "${MAJOR_VERSION}.${MINOR_VERSION}.${BUILD_VERSION}")
# テストを有効にする.
enable_testing()
# プロダクトコードディレクトリ.
add_subdirectory(product)
# テストコードディレクトリ.
add_subdirectory(test)
add_test(test01 test/test01_test)
add_test(test02 test/test02_test)
- cmake_sample/product/CMakeLists.txt
# 使用する cmake のバージョン.
cmake_minimum_required(VERSION 3.1)
# プロジェクト名.
project(cmake sample)
# ソースファイル.
file(GLOB SOURCES *.c)
# リリースビルドでのコンパイルオプション.
set(CMAKE_C_FLAGS_RELEASE "-Wall -Werror -Wextra -O2")
# デバッグビルドでのコンパイルオプション.
set(CMAKE_C_FLAGS_DEBUG "-Wall -Werror -Wextra -g -pg -O0")
# 実行モジュールの作成を指示.
add_executable(sample ${SOURCES})
# リンクするライブラリを指定する.
target_link_libraries(sample
edit
ncurses
)
- cmake_sample/test/CMakeLists.txt
# 使用する cmake のバージョン. cmake_minimum_required(VERSION 3.1) # プロジェクト名. project(embryoshell) # リリースビルドでのコンパイルオプション. set(CMAKE_C_FLAGS_RELEASE "-Wall -Werror -Wextra -O2") # デバッグビルドでのコンパイルオプション. set(CMAKE_C_FLAGS_DEBUG "-Wall -Werror -Wextra -g -pg -O0") # 実行モジュールの作成を指示. add_executable(test01_test test01_test.cpp) add_executable(test02_test test02_test.cpp)
これで、テストを googletest や cpputest を使って実施できれば、モダンな環境に近づくかな？
プログラマが知るべき97のこと > 見られて恥ずかしいデータは使わないこと
見られて恥ずかしいデータは使わないこと - プログラマが知るべき97のこと では、一時的と思って適当な（社会的には不適当な）データを成果物に埋め込んじゃうことが書かれています。
ここまで大事になったことは無いけど、一時的と思ってたコードが残ったままになっているコードはよく見かけます。
#warning とりあえず失敗させるけど、これでよい？
とか、入った製品コード。。。コンパイルのたびに表示されるけど、他社部分のレガシーコードだから、だれも触らない。
こういった、誰が見ても問題になりそうなパターンは別として、コーディング中は（特に調子が良い時は）ハイになっているので、あとから見返すと「こっちのほうが良かったな」というような実装を選択していると思う。
こういったコードは、レビューなどで検出することになると思うけど（動作上は問題ないので静的解析でも指摘されない）、レビューまで検出が遅くなると、コードを修正することが難しくなることも多い。（デバッグ後とかだと、構造は変えたくなくなるので）
ペアプログラミングが検出のタイミングとしては一番良いと思うけど、うちの会社では導入できなさそう。
あとは、自分で検出できるように、一区切り書ききったタイミングでセルフレビューすることを習慣にするしか無いのかな？何か、ツールなどあれば良いのだけど。
RasPi2は2017年じゃなかったのかよ！？
Raspberry Pi 2 Model B発売。4コア化&1GB RAMでWindows 10も対応、6倍高速 - Engadget Japanese
なにこれ！？ほしい。
でも、まだRasPi B+ですら、買ったまま触れていないというのに。。。メジャーバージョンアップは2017年と聞いていたから、完全にノーマークで、2ヶ月前にRasPi B+を購入していたのでした。
こうなったら、RasPi2を買う前にRasPi B+を遊びつくしてやるぜ！（白目）
エンジニアの文章管理について
コードの管理については、コンパイル時チェックや静的解析で自動的に間違いを指摘する構造がある程度と整っているが、仕事でコードを作成する前には必ず行われる設計書などの文章については、未だにWordで作成して人の目でチェックして、「です、ます。と だ、である。が混在している」などのコードの品質には影響しない部分の指摘に時間を費やすという状態から１０年以上変わっていないとです。（少なくとも、私の会社では）
文章についても、コードと同じように管理できないかと思って、
- doxygen によるAPIリファレンスの生成を通して、コードと文章管理の一体化
- pandoc によるフォーマット変換で、コンテンツ作成・チェック負荷の軽減（Markdownで作成して、納品向けpdf/Wordへの自動変換。チェックはテキスト差分で確認できる）
- 上記作業をCIに組み込んで成果物の自動生成
を考えていたのですが、静的解析に該当する部分が穴になっていました。
最近、 RedPen: 文書チェックツール という文章の構成チェックを自動的に行えるツールについて知ったのですが、かなり期待しています。
というのも、安心の日本製なのです！
最初に上げた、「です、ます」調などの表現についての指摘が機械的に行うことができれば、当然人のレビューではコンテンツに集中することができるようになります。
まさに念願のツールです。CIにも組み込みたい。
ということで、 RedPen: 文書チェックツール を全力で応援していこうと思います。
