matobaの備忘録

育児しながら働くあるエンジニアの記録

ソフトウェア開発の観戦とエッセイ

読書 ソフトウェア開発 エッセイ

ちょっと古い本だけど、面白い本を見つけたので、書いておきます。

見つけた本はこちら。

BEST SOFTWARE WRITING

BEST SOFTWARE WRITING

  • 発売日: 2008/02/21
  • メディア: 単行本（ソフトカバー）

何が面白いか、を一言でいうと、普遍的な息の長いテーマを扱ってるところです。日本語版は2008年に出版されているけど、僕は今でも読む意味があると思っています。

いや、どうかな。とりあえず、僕は読んでいて楽しいと感じていて、ソフトウェアに関するエッセイが好きな人は読むと楽しめるように思います。と言うわけで読みながら読んでいる話を備忘録に書いています。

この本を読んだからと言って、何か新しいテクノロジーが扱えるようになるわけじゃないし、給料があがるわけでもないと思います。

なんというか、小説を読んだから何かができるようになるわけではない、という話に近い。ただ、この本を読むとソフトウェア開発者としての生活が、少し充実するかもしれません。

じゃあどんなことが書いてあるのか、という話になりそうなので、文章を一部引用して書いておきます。

プログラミングの世界では、毎日気付かれることなく戦争が行われている。それは人間とコンピュータサイエンティストの間の戦いだ。それはシンプルでルーズでしなやかで人間的なコードの書き方を望む人と、クリーンで明瞭ではっきりしていて正確なやり方でコードを書くことを望む人の戦いだ。それはPHPとC++/Javaの間の戦いだ。そしてかつてはCとdBASEの間の戦いだった。

この文章はP25に書いてあります。

今はPHPとC++/Javaの間の戦いではないと思いますが、近い対立はあるように思います。

その構図や議論を少し離れて見ながら、どうなるのかを考えながら見たり何かを応援するのは、楽しさがあります。

それは、おそらく、野球ファンがプロ野球を観戦する楽しみ方に近い気がします。

僕は、自分が使っている技術やシステム、サービスの開発背景や経緯、その途中の意思決定などなどの記録を読んで、ふむふむ、とするのは、割と好きな方ではありますが、その活動の亜種ですかね。

ソフトウェアやシステムは有機的にできていますが、その構成要素や仕組みを知って、ナルホド、という気持ちなる遊びです。

pytestで一時的に失敗を許可する

Python pytest ソフトウェア開発 ユニットテスト

誰かのための備忘録です。あと、日本語の技術記事を増やそうかな、とも思っています。

pytestでテストを書きつつ、コードを修正していた際、既存のテストが失敗することはあります。

で、たくさんテストが失敗しすぎて、結果が見にくいと感じることもあります。

そういうときに、一時的にあるテストケースのテストの失敗を許容する書き方があります。

import pytest

@pytest.mark.xfail
def test_func():
    assert False

こんな感じです。 @pytest.mark.xfail を書くと、「このテストは失敗する」ということをマークすることができます。

詳細は、ドキュメントをどうぞ。

docs.pytest.org

他にも pytest.mark.skip とか pytest.mark.skipif とかもあります。

例えば、先日紹介したpytest-watchでテスト回しているときに、リファクタリングの修正を入れたらテストが大量にこけるようになったて、テスト一つ一つに対して、修正を検討しないといけないんだけど、まとめて検討しにくいときに使ってたりします。

複数の問題が絡まっているときも、問題を一つずつ解消していきたいので、原因を確かめて、原因を認識したテストケースは修正を後回しにするために、xfailをつけたりしてます。

pytestでクラスやメソッド指定でテストを実行することもできますが、できればpytest-watchである程度の範囲をまとめてテストしながら修正していきたいので、そんな進め方をしてたりします。

ファイル更新時にpytestを自動実行する

Python ソフトウェア開発 ユニットテスト TDD

誰かのための備忘録です。

Pythonでテストを書くときに、pytestを使うことはよくあります。

で、ファイルを更新した後にpytestでテストを実行したいこともよくあると思います。

そういうとき、ファイル更新を検知して、自動でpytestを実行してくれるツールがあります。

pypi.org

使い方は簡単です。

pytestを実行している開発環境で、pip install してptwというコマンドを実行するだけです。

$ pip install pytest-watch
$ ptw

ptwを実行するとファイルの監視が始まります。

僕は、コードを書く際、技術的な課題が概ね解決できそうなイメージができたら「とりあえず、一気通貫の入出力だけ確認するユニットテストを書く。その後は、pytestを自動実行しながら良い感じにリファクタリングしつつ、細部のテストを追加していく」という進め方をすることがあります。

そういうとき、pytest-watchを起動しておくと、便利です。「さっきまで動いていたけど、いつの間にか動かなくなった」という問題を避けやすくなります。

dockerで開発している人は、以下の話が参考になるかもです。

https://github.com/joeyespo/pytest-watch/issues/91

と言いつつ、僕は、以下のページで紹介されているwatchdogを使いつつ、自分でdockerのテストコマンドを実行してたりします。

qiita.com

FeedlyというRSSリーダーを改めて使い始めた備忘録

情報収集

Feedlyを入れた。

Feedlyは、RSSリーダーの一種。

今更、RSSリーダー？と思う人もいるのかもしれないけど、改めて戻ってきた。

feedly.com

理由

Twitterが自分の中で、うまく機能しなくなった

なんとなく最近、Twitterを眺めていると、同じようなツイートばかりが流れてくるような気がしている。

自分がフォローしている人が流したニュースではなく、誰かと誰かの議論が流れてくる。

僕が見たいのはそれではない感じだった。

ニュース記事が流れてくる場所を作りたかった。

新しい情報が流れてくる場所が欲しい

繰り返しになるけど、新しい情報、ニュース記事とか各社のブログとか、がいい感じに流れてくる場所が欲しかった。

新しい情報が流れる場所をフォローしておかないと、だんだんよくわからないことが増えていくな、という気持ちがある。

とは言えて、最近、よくわからないと思うことが多すぎるとも思うので、情報を過剰摂取しすぎないように注意してはいるのだけど。

いろんなブログ記事の更新をフォローしておきたい気持ちがあって、それをやるならRSSなのかな、と思って、RSSリーダーを入れた。

あんまりRSSリーダーを知らない

実はRSSリーダーをそんなに調べていない。

とりあえず、次の条件を満たすものを探したらFeedlyにたどり着いた。

  • Webブラウザで管理できる
  • スマホでも見れる
  • Firefoxに拡張がある

余談

他の人はどんなふうにして、情報を収集しているのだろう、と思っているけど、なかなか話をする機会がない。

Gitで変更したファイルを変更前に戻す

Git/GitHub

Gitで変更したファイルを変更前に戻すコマンドのメモ。

以下のようにrestoreを使う。

git restore <filename>

とりあえず git stash とかで変更を一時待避したり、 git checkout -- <filename> していることもあるのだけど、別に待避する必要がない時はあるし、restoreの方が明示的だと思うのでこっちを使っていきたい。

ちなみに、コミットする前のファイルの話なので、コミットしている場合は、 revert や push前なら reset --hard を検討することになるのかと思います。

忘れるために記録を書く。忘れたときのために記録を書く。

エッセイ

Twitterで以下のような話をした。

この話をした後にこんなことを思った。

何となく自分が記録という概念についてわかっていないこと、もしくは忘れているようなことがあるように感じた。

何となく最近の自分は、ブログを書くモチベーションが湧かなくなっていることが気になっていた。あと、voluntas さんのブログ（主に時雨堂関係の情報）を拝見した際に「この記事は、どういうモチベーションとか、どういうタイミングで書こうと考えたのだろう？」と思ったことがあった。（対象読者や主旨が想像できないけど、重要な情報が書かれていると感じることが多いので）

で、もう少し考えていると、自分の中で「記録」という概念の意味がぼんやりしていることに気づいた。

そこで、「記録とは何か」を辞書で調べていると次のページにたどり着いた。

kotobank.jp

気になったのは以下の点。

なお近代では，記録と文書の概念上の混用がみられ，文書課の保存資料を記録と呼ぶこともある。

後、次の話も気になる。

著作物である典籍や，おのれの意思･用件などを相手に伝える目的で書かれたものを文書（もんじよ）とよぶのに対し，原則として自己(近親者あるいは所属の機関なども含む)の備忘のため書きとめたものを記録といい，主として日記類がこれに該当する。

だんだんわかってきたのが、自分の中で「文書」と「記録」の境界がボケているということ。

以前は、文章を書くと言えば、ブログに書くことが多かった。そしてブログに書くことは、備忘録だった。自分が調べたことや学んだことをメモする場所がブログだった。

ただ、次第に自分の文章が誰かに読まれることを意識するようになると、記録というより文書の側面が強くなっていった。ブログの記事もある程度は、想定読者を考えつつ、文章や情報を整えることが増えた。要は、ブログの記事が文書化していった。

すると、だんだんブログが書きにくくなっていった。そもそも誰かに何かを伝えたい時にブログが最も適切な手段になることはそう多くないと思う。不特定多数が見る可能性のある場所に想定読者を設定して書くのは、なんか違うような気がしてしまう。

そういう話をいろいろ考えて、まとめると、自分が忘れるための記録を残すために書いてないからブログを書きにくいと感じるんだなあ、と思い始めた。また、自分以外の誰かが忘れた時や知りたいと思った時に参照するために記録を残していると考えると、ブログを書く理由が自分の中で腹落ちした。

というわけで、しばらくはブログの更新がなかったけど、改めてブログを更新していきたいと思ったところでした。

追伸：ついでに、ブログのタイトルは「matobaの備忘録」に変えました。