Linux ドライバで、ioctl をつくっている。ハマったところ。・コマンドは _IO、_IOW、_IOR、_IOWR の用意されたマクロを使ってつくる。 単なるユニーク値でいいんだろー、と思ってやってたら、思わぬところでつまづいた。 前述のマクロを使わないでいたら、 …

結果を見よ。特にレジスタの中身は。 セットしたからといって、セットされてるとは限らない。 セットする手順が決まっていたり。プロテクトがかかっていたり。 コントロールレジスタにセットしたことがステータスレジスタにちゃんと反映されているか、とか。…

www.youtube.com 私の頭の中でずっとここ数年炎上している課題は、 ソフトウェアのプロフェッショナリズム（職業感）についてだ。 （中略） だって、この社会はソフトウェアなしにはもはや成り立たない。 （中略） でも、ソフトウェアはきれいに書かれてはい…

"「質v.s.スピード」という概念は根本的に間違っている" "質v.s.スピードという二律背反の関係は、局所的なものでしかない。大域的には、片方を犠牲にした場合、知らぬうちにもう一つも犠牲にしている" https://t.co/jfZK5juCU6— Takuto Wada (@t_wada) Febr…

以前にも書いたと思うけど。 やっぱりコードにふれていないと。情報量が違う。 どんなふうなつくりになってて、品質がどの程度で（ざくっと傾向でいいので）、 どんな感じで動いてて、ここまでは大丈夫で、など。 状況がある程度わかっていたら、 お客さんと…

qiita.com例年この時期には、新入社員が入ってきて 「コメント書きなさいよー」って話をするわけですが、でも そのうちなれてきたら、 「コメントなくても読めるコードを書けよー」と言いたいです！ 最初のうちは "コードを説明するためのコメント" を書いて…

うまく名前をつけることは、「究極の設計」ではある（と私は思う）けれど。 ここではもっとカンタンなお話として。 （上位の）設計書からそのまま名前を引用しようとすると、 コードにうまくマッチしないときがある。 なぜならば、設計書に書かれるものは「…

新しい言語をおぼえるときの、参考書の選び方がいつも難しい。 もう長いこと、この業界で仕事してるわけだし、 いまさら、クラスがどうだ、データ型がどうだ、ってところから書いてあっても 読まないムダなページなわけである。 そのために分厚いごっつい本…

takaking22.com 基調講演の話の内容が詳しく書いてある。サンキュー！ モブプログラミングはどうすれば一つのチームが一緒に効率よく働くことができるかということを探求する過程で発展してきました。一旦始めてみると、我々はモブプログラミングが次のよう…

「ちゃんと」という言葉をよく使う。 今回も、「美しく」とか「きれいな」とか使ってみようかと思ったけども やっぱりしっくりこなかったので。 さて。 ちゃんとしたコード書きたいと思うし、ちゃんとしたコードで書いてほしいと思う。 でも、もしかしたら、…

なんでもかんでもコメント書けばいいわけじゃない。 見ればわかるじゃん、ていうことまで書く必要はない。 でもそのさじ加減は、少し経験を積まないと、わからない。 それは言葉にしてもなかなか伝わらない、・・・ように思える。 コメントがいるってことは…

まだうまく「キーワード」化できていないのだけど、 消える前に書き残しておく。 そのうち整理して、ちゃんと言語化したい。ノウハウや観点にしたい。 デバッグのコツ。というか「やり方」。 もっと言えば「プログラミングという行為」について。 推察せよ、…

設計とは、 「なぜそうなのか」の理由付け・意味付けになるもの、だと思う。だから、自分のコードに対して 「なぜそうなのか」が答えられないようでは、プログラマとは言えないと思う。 そこに意思はあるのか？と思う。ただ単に動くものが作れるだけで、それ…

ひさしぶりにコードを書いている。 当初思ってたより時間がかかってて。思うようにいかないなーと思うと、そこばっかりを一生懸命やってしまう。 なんどもなんども試してみて、うまくいったりいかなかったりを繰り返している。手を休めて「さぁどうしようか…

codezine.jp ちょー良記事です！ 単にペアプロの導入事例というだけでなく、 品質と開発手法のこと等、いろいろ考えさせてくれます。それから、何かを変えていくのには、たいへんはパワーがいることだと改めて思いました。 でもそのくらいでやらないと、何も…

www.facebook.com メロンパンにはメロンクリームが入っている、と叫びたい！ 私は通称メロンパンを「コッペパン」と呼ぶ文化圏で育ちました。 こっちきて、関西だから言い方違うのかなー、くらいにしか思ってなかったんだけど。さて、組込みのお仕事が長く続…

設計時は、システムを俯瞰的に見ており、 大きなふるまいのほうに目が行きがちである。 そして、コードになるときの姿を思い描きながら設計するのは、 かなり粒度が小さくなってからだ。しかしそれでも、実際にプログラムに落とし込むのとは違うのだ。コード…

関数をつくるということは、 システムの中の／世の中の「こと」「もの」をどう捉えてどう表すか、ということだ。処理の複雑さ・煩雑さや、量の多少ではなくて、 抽象度のレベルや粒度を変えながらものごとをとらえて考えよう、ということだ。大きくとらえて…

ときどき、すごくややこしい if 文に出会うときがある。 たくさん if があるんだけど、よく見ると、else 側の処理は同じようなことばかり書いてあったりして、「これ、ちゃんと整理してまとめれば、すっきりするんじゃない？」みたいなの。 確かに間違いでは…

仕様書に書いてあることは、そのままコードに落としたい。そのためにも、仕様書とコードを１対１で対応させたい、と思う。つまりは、「仕様書のここは、このクラス／モジュールに書いてあります」としておきたい。そして、その中身は、 「2-3章の機能は、こ…

「似たような処理だから」とコピペするのではなく、 同じところはどこなのか、違うとこはどこなのかよく見て、 それから、データとロジックを分けて見る見方ができれば、 コードの共通化と、差分の持たせる方法が見つかるはずだ。 そしてこれはオブジェクト…

さて。先日のアジャイルラジオの感想です。まずは共同所有のこと。正直、ひとのコードを積極的に「さわる」ことはないです。 コードが見れる環境にあるし、コードレビューもするけど、 「直す」「変える」のは抵抗あるな、と思う。こういうことをすることに…