弐条海月の とはずがたり

そこはかとなく書き綴るブログなるもの

久々にアプリ開発…

Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」で開発した、ほぼ毎日仕事で使うアプリケーションに手を入れました。2011年秋以来手を付けていなかったアプリ。毎週金曜日にバグが出ていたのだけれど、テキストファイル内に数文字を追加するだけで済む軽微なバグだったことから「いつか直そう」と思いつつ毎週手作業で処理しておりました(笑)。今日は忙しいはずだったのが思わぬ展開で手がすいたため、久々に手を入れることにしたのでした。そんなお話。

このアプリは2つの機能を持っています。
1つ目はほぼ日替わりで変わる項目を選択すると、あらかじめ用意したIllustratorのテンプレートを、翌日の日付けの入ったファイル名にリネームして所定の場所に用意するというもの。私はそのファイルを開いてテキストを流したり画像を貼り付けたりしているのです。
2つ目は完成したIllustratorのファイルからコピーしたテキストを、プログラム上で整形処理し、画像があればそれもまとめてサーバーの所定の場所に保存する機能です。

慌ただしい朝の仕事が10時少し前に終わったので、そこから開発を開始したのだけれど…私のバージョン管理が甘かったせいで余計な作業が追加になってしまいました。それはソースの比較(笑)。

というのも、外部プラグインを多用していた過去のソースは参考にしながらも、できるだけ純正プラグインと自作モジュールを使ったソースに書き換える作業を途中までやっていたところ、新たにベースにしていたものより新しいバージョンのソースが見つかったからです(泣)。

すでに古いバージョンのまま途中まで手を入れており、新たに同じ作業をするのは面倒だったので、手を入れていた古いバージョンと、新しいバージョンのソースを並べて1行ずつ比較。無駄に長い750行くらいのソースを見終えたところで目が疲れたので昼食をとることにしました。

本気で開発に手を入れ始めたのは午後から。夕方からメインの仕事が忙しくなるので今日は完成には至りませんでしたけれども、普段の仕事とは違う思考を巡らせたからなのか、久々にプログラム開発の時間がとれてなんだかリフレッシュできたような気がしました。


テキスト管理アプリ、ほぼ書き直し…

いずれ仕事で使うことになるであろうテキスト管理アプリケーションの開発を始めています。開発言語はWindowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」。4月中旬あたりから現在の業務に日々のテキスト管理が追加されます。これを手書きによる作業からパソコン入力による作業に変換するためのプログラム群の開発のお話なのですが…。

完全に自社専用アプリのため汎用性はゼロなのだけれど、今までHSPの文字処理でやってきたことの集大成的なアプリになると思います。2月末から開発を初めておりますが進捗状況は2割強…といったところ。ある程度の仕様は私の中で決まっているものの、詳細の設計はいつものごとく後回し(笑)。実際にプログラムを組みながら進めているので、たまに組み直さねばならない事態におちいることもあるのです。とっても無駄なのですけれども。

今日は今まで進めてきたテキスト群の読み込みとリスト表示の部分を見直し、根底から書き直すことにしました。リスト表示する際の表データの区切りを通常使わないであろう「##」で区切っていたのだけれど、思ったより表データの項目が増えてきたので管理しきれなくなる可能性を考え、タグ区切りのXMLデータで管理する方式に改めたのです。

しかしながら、書き直すとなるとプログラムのほぼ最初からになるため面倒でした。これならば最初からXMLを処理する仕様にしておけばよかったと後悔しますね。実際にXMLで処理したほうが確実に欲しいデータを取り出すことができるので便利だし。なぜそうしなかったのだろう? XMLデータの出し入れに役立つ自作の文字処理関連モジュール「kurage_mod」があるというのに…先月末の自分を問いつめたい気分です(笑)。


検索アプリのバージョンアップ…2

前回は「HSP(Hot Soup Processor)」で開発した簡易データベースの仕事で役立つアプリケーションを開発して使っております。今回は、テキストファイルによる簡易データベース作成アプリに関連した検索アプリのバージョンアップのお話第2弾。

現行のアプリのバージョンはβ14。今回はβ15として途中まで開発をしておりましたけれども、データベースの読み込みに関して思いついたことを試すため、途中からβ16として開発を進めることに。よってβ15はリリースされない幻のバージョンとなりました(笑)。

実は以前にもデータベースの読み込み方法を変えたことありました。かつて開発したβ2のバージョンは、起動前に全データベースを読み込む仕様でした。しかし、これだと検索するつもりのない古いデータベースまで読み込むため起動に時間がかかりすぎる欠点がありました。簡易データベースが増える(新しい年を迎える)たび、データの読み込みにさらに時間がかかるので、やむなく元に戻した経緯がありました。

今回のβ16では、起動時に過去2年分のデータベースを読み込むことで起動にかかる負荷を軽減させつつ、古いデータベースを検索対象にする際にそのつどロードする方式に変更。これによって若干検索前の待ち時間が増加するものの、検索時にロードする方法に比べてはるかに時間を節約できます。

参考までに、検索範囲を1年間にすると…低スペックのパソコンでも旧アプリの3秒ほどに対し新バージョンでは2秒ほどと150%ほど高速化しています。検索範囲を2001年から2013年まで広げてみると、旧アプリでは30秒ほどかかっていたのが18秒を切るくらいまで目に見えて高速化しています。

ただし弊害もあって、検索開始後にデータベースを読み込まない代わりに、検索範囲を変更した際にまだ読み込んでいないデータベースがあれば読み込むことになるので検索できるまでの間、少し待つことになります。それでもトータルしても以前よりは早いです。

現在は2人にテストをお願いしています。自分でも使ってみて、過去2年分のデータベースくらいは操作ウィンドウが出る前に読み込む仕様にすれば、さらに体感速度が速くなると思いました。起動時にデータベースの更新を行う仕様なのだけれど、そのついでにロードもしてしまおうと思います。そうするともっと体感速度がアップするはず。関連部署の会議が来週火曜日にあるので、それまでにβ17として開発を終えるつもりです。


検索アプリのバージョンアップ…

Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」にて仕事で役立つアプリケーションを開発して使っております。今日は、先日更新したテキストファイルによる簡易データベース作成アプリに関連した、検索アプリのバージョンアップのお話。

仕事で生成される1日に数十のテキストファイルを1ファイル1行に変換、1年ごとに1つのテキストファイルにまとめ、簡易データベースとして保存しているのだけれど、それを対象にテキストの全文検索ができるアプリを作って使っております。自画自賛ですが便利なアプリで、関連部署にも使ってもらっており、今やそれがなくては仕事が成り立たないほどです。

今回のバージョンアップは1年半ぶりになりますね。ずっとβ版としてリリースしておりますけれども、過去2回のバージョンアップはUbuntuに対応させるためのOS判別やらバグ修正にとどまるので、アプリの根幹である検索まわりの変更はデータベースの仕様を変更した2009年以降では初めてのことになります。

アップデートに至る経緯は先日、すでに1年前にサポートを打ち切った古いテキスト検索システム用の簡易データベースをサーバー上から削除したのだけれど、その後社内の2人から「テキスト検索アプリが動かない…」という声を聞いたからです。聞けばデータベース変更前の古いテキスト検索アプリを使っていたことが判明。現行版のβ14を渡すもエラーが出て動作せず。「私も同じものを使っているし、OSは違っても自動で判別する機能があるので大丈夫なはず」と自分のマシンで確かめてみると…あれ?自分の環境下でもエラーが出てる(笑)。

調べてみると…サーバー上の古いデータベースを削除した際に、動作を確認するためにサーバー上に残してある設定ファイルまでも削除してしまっていたことが判明。どうせなら…とソースを見直してバージョンアップすることにしたのでした。

バージョンアップの主な内容は、サードパーティー製の外部プラグインを用いず標準のプラグインのみでソースを書き直したこと。そのほかにも細かい内部処理は見直しましたけれども、β13になった際に動作速度がかなりアップしていたので、さらなる速度アップにはいたりませんでした。さらに検索速度をアップさせることはできないだろうか…と考えていると、ふとひらめいたのが検索開始時のデータベースの扱い方を変更する方法。次回はそのことについて書こうと思います。


HSPで作ったアプリの不具合…

Windowsで動作するインタプリタ型プログラム言語「HSP(Hot Soup Processor)」にて開発した、簡易データベースの更新アプリに不具合が見つかったので手直ししているのだけれど、なかなか思うようにいかず難儀しております。昨年夏に致命的なバグが見つかったため、シンプルな処理をめざして大幅にソースを書き換えてからはうまいこと動作していたのに残念です。そんなお話。

アプリの機能としては、1日に数十と作成されるテキストファイルにタグを付けて1日単位でまとめ、それを1年毎のファイルとして保存し、検索用のデータベースとするというもの。見つかったバグは、新しい年に変わってから発生していたものでした。

新しい年に変わって今年用のデータベースファイルが作成されたのにもかかわらず、実際にデータベースの内容は保存されていたのは昨年のものに追記されていたというのです。検索アプリのほうで去年のテキストを検索しても、今年のファイルも顔を出すことからバグが判明。

とりあえず応急処置として今年のデータベースを削除すると自動でデータベースを作り直す機能があるので、それを使いつつ、
昨年のデータベースを開いて今年の内容を手動で削除しました。

で、ソースを見直してみると…あらかじめ取得したデータベースを検索している部分が、置換など文字処理に特化した自作モジュール「kurage_mod」のバージョンアップで命令の名前を変えていたのにそのままだったことがバグの一因であったことが分かり、その部分を修正。

ほかに、日付を取得する別のプログラムにも不具合が及んでいることが分かったため、そちらも書き直すことにしました。こちらのアプリは今日の日付、明日の日付、明日が休日の場合は翌営業日の日付を取得するアプリ。こちらを自作モジュール「kurage_mod」の新命令を使って書き直すと…日付と曜日の処理が簡単にできたので195行のソースが97行になりました(笑)。

あとは、毎日使ってみて不具合が出たら修正することにしますが…本体の検索アプリのほうもバージョンアップしたいですね。今年はかなり忙しい年になりそうなのだけれど…時間はあるかな?ちょっと心配です。


固定ページ

最近の投稿

カテゴリー





カレンダー

2020年7月
 12345
6789101112
13141516171819
20212223242526
2728293031  

過去の日記はこちら

キーワードで検索