chocolablog ver 0.8 にアップデートしました
Python 製自作ブログの chocolablog を ver 0.8 にアップデートしました。前回のバージョンアップは 2014 年 11 月 3 日でした。2 年と 3 ヶ月ぶりくらいですね。
その間特にリリースを迫られるような理由もなかったのですが、最近になって大きめの追加機能を実装することになりました。
……こうやって趣味で書いてるコードを日の当たる場所に出すというのも随分ひさしぶりな感じがしますね。
以前よりも家でコードを書くことが減っているのこともありますが、まああまり後先考えずに書きたいコードを書いていこうかなと思っています。
そして恒例の謎スクショ。
この手の記事は毎回何の画像を貼ろうかすごく悩みます。
ver 0.8 の追加機能
フロント側・マルチクライアント対応に伴う URL 構造の変更
・jquery のバージョンを 3.1.1 にあげた
chocola 記法の機能拡張
・コードタグのシンタクスハイライトに javascript 用を追加
システム管理画面側
・マルチクライアント対応
・記事の作成日時を指定できるようにした
改修した不具合
・chocola 記法のコードタグ内に [ や ] を記載できない
マルチクライアント対応しました
chocolablog ver 0.8 での目玉機能の 1 つになります。1 つの WEB アプリケーション上で複数のブログを構築できるようにしました。実は数ヶ月前からこの機能だけ先行アップデートしていて、Google さんには新しいばっちり反映されているのですが、ブログの URL が変わっています。この機能の実装は某所からのリクエストによるものです。大したプログラムでもないですし、そんなニーズがなかったのでブログの数だけコードをデプロイする仕組みになっていたのですが、1 つのコードで複数のブログが動作できるように修正しました。
DocumentRoot はブログ毎に分かれますが、コードベースは共有されているため、リリース時にはそこのコードだけアップデートすれば、全ブログがバージョンアップされることになります。ここは今回の要望を解決するにあたって外せなかった部分です。chocolablog が必要とされる場面としては、デプロイスクリプトが使えるような高尚な環境は想定していないので、コードベースが分かれているとアップデート作業だけで死んでしまいます。
データベースをどうするかは悩んだのですが、今のところブログを横断する機能は存在しないので、分けることにしました。ブログ単位で sqlite3 のデータベースファイルが分かれていたほうが、負荷分散を考えるといいかな、という判断です。すべてのブログから記事を検索するというような機能には、まだ必要になるかもわかりませんが、RDB より適したプロダクトが世の中にありますしね。
日時指定して記事を書けるようにした
chocolablog ver 0.8 でのもう 1 つの目玉機能になります。記事を書く時に作成日を指定できるようにして、その日付がくるまではその記事は公開されない、という感じです。実はこれがいままでできませんでした。というのも、chocolablog は機能も使い方もシンプルであることを基本思想としているので、記事は書きあがったタイミングで公開されればそれでいいと思っていたのです。日々のできごとやポエムなんかを書き綴るならそれでも良いのでしょうが、特定の日のためにあらかじめ準備しておきたいという用途では機能不足でした。ビジネス用途の WEB アプリでは、記事のチェックや承認でも下書き的なステータスが要求されたりします。chocolablog ではそこまでかしこまった要望があるわけではありませんが、1 週年記念日にあわせて記事を公開したいなんていうことはまああり得るので、機能追加することにしました。
記事の表示条件を変えるということで、機能の地味さに比べると影響範囲がめっちゃ広かったです。それも、失敗すると見えてはいけないデータが見えてしまう系の修正なので無駄に神経を使いました。そのうちに実際に使ってみることになるので、こっそりバージョンが下がってたなんて事態にならなければいいなと思っています。
粛々とリファクタリングしています
chocolablog ver 0.7 で DB まわりのフレームワークを刷新しましたが、その時に作った新しい API への切り替えを 100% やりきれたわけではありませんでした。主要でない部分にはまだ古い API を使っているコードが残っていて、ver 0.8 ではそういう取り残されたコードを書き換えるという作業を暇を見つけては進めていました。そして、今の時点でもすべてが done ではありません。chocolablog のリリースは新機能や不具合改修が必要となる場面で行っているので、リファクタリングの状況はバージョンによってまちまちだったりします。コードの書き直しはやりたくなった時にやりたいだけやって、リリースのタイミングでそこまでの成果がアップデートされていく感じです。今回は記事の作成日時指定機能が要求されていたので、その機能が仕上がった時点がリファクタリングでの区切りになっています。あくまで趣味プロダクトなので、リファクタリングが完了しなければリリースしてはいけない、なんて決まりはありませんからね。
そしてこちらが現在の単体テストの状況です。
前回はカバレッジレポートによそのモジュールが紛れ込んだりしていたので、今回はうちのモジュールだけカバレッジを取るようにしてみました。chocodb と libchocola のカバレッジが上がってきています。
ステートメントベースでカバレッジを測ってみると、単体テストで動作していないコードが明確にわかるのでとても便利です。よくあるパターンは、一見カバレッジレポートでは網羅されているようで、実は大してテストケースが書かれていないというコードを見つけたりするパターンです。そういうコードはたいてい条件分岐文の一部だけがテストされていて、異常系やレアな分岐が網羅されていません。単体テストをしっかり書くと、その都度出来上がったテストケースでカバレッジを見直すので、普通条件の一部だけをテストする、ということはないからです。
綺麗なカバレッジレポートを視覚的に確認できるというのも、テストケースを書く上ではポイントが高いです。赤くなっているステートメントを減らそう、せっかくテストケースを書いたんだから漏れのないようにテストケースを充実させよう、カバレッジレポートが白くなった or カバレッジが何 % 上がったのがわかる、という流れは、単体テストをする動機付けとしては十分ありだと思います。
もちろん単体テストの常として、カバレッジレポートは評価基準にはならないというのは前提としてあります。意図した動作になっているかの責任はテストケースにあるわけで、単体テストによってそのコードが実行されたかどうかには品質はあらわれません。
が、生真面目にやろうとするととても面倒くさい単体テストのモチベーションとしては、カバレッジレポートは良いガジェットになると思います。全体で見てみるとたいしたカバレッジではないにも関わらず、数値がちょっと上がっただけで、楽しくなってレポートを公開してしまいたくなるくらいですから。1 種のゲーミフィケーションです。
chocolablog 開発 コメント (0) 2017/02/13 19:59:53