libpq反省事項備忘

投稿日:

 自作の株式売買システムの改修で、反省事項があった。

 このシステムは各種言語の混成で書いてある。株価データをネットからタダでいただいてくる「スクレイピング部」はPerlで、その株価データを使って様々な指標を片っ端から売買試行する「シミュレーション部」はCで、売買指示を閲覧する「ユーザインタフェイス部」はPHPで、それぞれ書いた。株価データを格納するDBにはPostgreSQLを使用している。

 Cで書いた「シミュレーション部」をPostgreSQLにアクセスさせるのには、「libpq」を使っている。

 先日、取り扱い銘柄を増やすため、2500銘柄ほどのシミュレーションを行った。ところがその際、1000銘柄の処理を過ぎるあたりで、メモリリークのために異常終了してしまう現象に悩まされた。それまでは最大でも300銘柄くらいのシミュレーションしかしていなかったので、不具合が伏在したまま、わからなかったのである。銘柄数を一挙に増やしたために不具合が顕在化したわけだ。

 malloc()しているメモリは必ず開放しているし、ループ脱出などで未開放のままどこかへ飛ぶなんてこともしていない。

 だが、すぐに、libpqで大きなメモリオブジェクトを返すselectの後、PQClear()をしていないこと、つまり

PGresult *res;
sprintf(sqlstr, "select * from table where key='%s' order by col;", key);
res = PQexec(con, sqlstr);

などというくだりの後、処理が終わっても

PQClear(res);

……をしていないのが原因っぽいことには気づいた。早速処理の後にPQClear(res)を書き加え、

PGresult *res;
sprintf(sqlstr, "select * from table where key='%s' order by col;", key);
res = PQexec(con, sqlstr);
・
・(処理)
・
PQClear(res);

というふうにした。

 しかし、異常終了が1500銘柄のあたりまで伸びただけで、やはりメモリリークする。

 1か月ばかりも悩んだ後、deleteやinsertのような、いわば「かけ捨て」のsqlも、メモリオブジェクトを返していることに気づいた。そういう部分は、例えば次のように書いて済ませていたのだ。

sprintf(sqlstr, "delete from table where key='%s';", key);
PQexec(con, sqlstr);

 そこで、メモリオブジェクトを取っておいて、終わったらクリアするようにした。

sprintf(sqlstr, "delete from table where key='%s';", key);
res = PQexec(con, sqlstr);
PQClear(res);

 同様に、insertしているところもupdateしているところも、全部そうした。そうしたら、たちどころにメモリリークはなくなり、異常終了直前に起こっていたスラッシングらしい現象による速度の低下もなくなった。

 次に試したいのは、これを

sprintf(sqlstr, "delete from table where key='%s';", key);
PQClear(PQexec(con, sqlstr));

というふうに簡略に書いたらどうだろう、ということである。

やっとこさ縦書きを左右中央配置にする方法がわかった

投稿日:

 このブログはよく「縦書き」を使う。主として俳句を詠むためである。他に、経文や邦楽の歌詞を書きたいときにも使っている。

 これには、「<div style=”writing-mode: tb-rl; writing-mode: vertical-rl;”>縦書きにしたい文字列</div>」というふうに、スタイルシートを使う。

 ただ、記事の中央に文字列を配置したい場合に、どうも不自由していた。俳句は縦1行なので、「<div style=”writing-mode: tb-rl; writing-mode: vertical-rl; white-space:nowrap; margin-left:48%;”>縦書きにしたい文字列</div>」などとして誤魔化していた。

 ところが、左右のマージンを「auto」にすることで、左右中央に持ってこられることがわかった。つまり、「<div style=”writing-mode: tb-rl; writing-mode: vertical-rl; white-space:nowrap; margin-left:auto;margin-right:auto;“>縦書きにしたい文字列</div>」というふうに書くわけだ。

 過去の記事も全部このスタイルシートに置換した。スッキリした。

株式売買ユーティリティのメンテナンス

投稿日:

 標記システムはこの3月に手直しして、快調に動いている。

 しかし、この株価好調の折柄、どうも売買成績がそれほど良くない。

 毎日の売買シミュレーションの結果は、成績の良いものがテーブルに格納されて提示される仕組みだ。成績の悪いものは日々の値動きにより次第に排除されていく。ふと気づいてこのテーブルを見てみたら、銘柄数が減っている。はじめのうちは100社以上が残っていたが、今見ると70社ほどに減ってしまっていた。

 ははあ、これだな、と思い、先週から少し試行錯誤して、東証一部の貸借銘柄リストを1893社、東証のサイトから貰ってきた。これを対象銘柄テーブルに全部ブチ込んだ。

 前は自分の気に入った東証二部の銘柄も入れていたが、売買両方向でシミュレーションするので貸借銘柄でないと都合が悪い。東証二部の銘柄を混ぜると貸借銘柄でない銘柄を削除したりするのが面倒になることと、東証一部の貸借銘柄は信用の高い銘柄で自然、時価総額も高いということになるから、これも好都合だと思ったのだ。時価総額が高ければ、そう簡単には倒産などしない。以前は時価総額の高い順に上からリストを持ってきていたが、それはシミュレーションに時間がかかっていたから銘柄数を厳選するためで、最近は計算機を性能の良いもの(Corei7+メモリ32GBのデスクトップマシンのVM)に替えたので、この部分は気にしなくてよくなったのだ。

 株価データは無料を期するため、「Yahoo!株価」からトロトロとスクレイピングする仕組みである。ところが、約1900社の全部のダウンロードには50時間ほどもかかる。

 先週の土日からそれに手を付け、シミュレーションはようやく7.1(木)の未明、真夜中に起動した。

 ところが、朝までかかって1527銘柄ほどシミュレーションしたところで、停止してしまった。

 データにゴミでも入ったかな、と思い、一度スクレイピングした全部のデータを消去して、ダウンロードからもう一度取り掛かることにした。また改めて50時間以上かかる。

 しかし、今度も1526銘柄で異常終了してしまった。

 そんなことに、昨日の土曜日の早朝まで費やしてしまった。今まで最大の銘柄数は700銘柄くらいしか食わせたことがないので、そういうバグがあることがわからなかったのである。

 シミュレーション部分はCで書いてある。どこかにメモリの開放忘れでもあるのかな、とソースを読んでみるがそんなことはない。

 しかし、PostgreSQLへのアクセスにlibpqを使っているのだが、そのリザルトオブジェクトを開放していない場所が1か所あることに気づいた。ある銘柄の過去5年分の日足データを列挙するループに入る直前に「res = PQexec(con, sqlstr);」なんてことをやり、この「res」には過去5年分の日足データが入る。「res」をループ内で使うのだが、ループを出た後でこの「res」を開放しないまま、再び「res = PQexec(con, sqlstr);」が呼ばれるのだ。どうも、これを1500回も繰り返すとメモリリークを起こすようだ。

 そこで、日足データ列挙ループの出口を出てすぐのところに「PQclear(res);」というコードを足した。

 これでもう一度様子を見ることにする。

株式売買ユーティリティの改修

投稿日:

 先週16日に突然正常に動かなくなってしまった株式売買ユーティリティ。やっと手を付けることができた。

 案の定、十何年変わっていなかったYahoo!ファイナンスの仕様が変わったためであることが判った。返してくるHTMLに変な <span> タグや class が増え、まるで別物に変わっている。それに、GETの引数の仕様も変わり、以前のURLではデータを持ってこれなくなっていることも判った。

 株価データを切り出すためのマッチング・パターンを書き直し、変な <span> タグや classのサニタイズを強化した。それからURLも書き直した。

 動くようになったが、220社の株価データを全部取り直すのに数時間はかかる。

スクレイピングや奈良漬や「お前のようなアホ」や

投稿日:

 昨年頃だったか。

 若い人――若い、と言ってもそこそこオッサンだが――とIT活用談義をしていて、この「スクレイピング」という言葉が出てきた。まるで初めて聞く言葉のような気がした。いや、必ずしも「初めて聞く」でもなく、聞いたことがないわけでもなかったのだが、耳慣れぬ言葉ではあった。しかし、その時の会話の文脈と、scraping という英語から意味はすぐに通じ、その若い人に「スクレイピングって、何ですか?」などと()き直さなければ解らないということはなかった。

 今で言う、この「スクレイピング」ということを私が最初にやりだした頃には、スクレイピングという言葉が抑々(そもそも)なかった。だから「無料自動収集」だとか「クローリングしてサニタイズして格納」だとかいうような言葉で表現していた。もっとも、私がしていたこと(他人の過去の言葉尻を(とら)えた掲示板での粘着荒らし行為(苦笑)だとか株価データの収集だとか、特定領域のニュース記事の巡回収集だとか)は個人的なくだらんことで、その仕組みを他人に説明する必要はまったくなかったから、わざわざ無料自動収集などという持って回った言葉を使う必要もほとんどなかったのだが。

 今は Python (など)の言語を用いれば、様々なライブラリやプラグインが豊富にあるらしく、Web を巡回してデータを(あさ)ることなど誰でも簡単にできるようである。しかし、私などがそうしたことを始めた頃には周囲にそういうことをしている人はおらず、ネットを(あさ)っても情報は少なく、いきおい、最初はTCP/IPのソケットから書き起こしたものを用い、次いで Perl・CPAN の「LWP」などという Web ライブラリを用いた。今も現役で稼働させている、株価を Yahoo! から取得するスクリプトは、Perl 内から「wget」を呼び出し、必要なデータを切り出す仕組みだ。

 全くのところ、こんなもの「手作りスクレイパー」もいいところである。フロントエンドのスクレイパーのみならず、現役で株価の分析に使っている自作プログラムは、私に幾許(そこばく)の利益をさながら点滴のようにしたたらせ続けてはいるものの、これなど古めかしいかな生の C で書いたもので、ソースコードの冒頭にはそれこそ「#include <stdio.h>」か、せいぜい「math.h」ぐらいしか書いていない。AI などとは程遠い実に簡単・単純なものでしかないのである。

 それらを動かし始めたのは20年前~15年前のことで、そこから(ほとん)ど進歩させていないし、私の IT 技能もほとんど進歩せず、停滞したまま、否、むしろ後退すらしている。

 私は、自分が必要としていることや自分がしたいことは、自分が理解できるコンピュータ技術やプログラミング技術を使って、大概(たいがい)のことならすぐにできる。だが、それを他人が使えるように工夫してやったり説明してやったりなど、面倒臭くて、もうしたくない。それに、当節流行のビッグデータだの AI だのということは、全然わからないしできない。覚えるのも、いまや奈良(なら)(づけ)のようになってしまっている私の脳味噌には荷が勝つから、もう億劫(おっくう)で、嫌だ。他人を使役できるような身分ではないから、自分にできない何かを誰かに肩代わりして貰えるような人望もないし、だいたい、そんな気がハナッから、ない。

 「お前が勿体(もったい)ぶって隠している、しょうもない、お前みたいなアホでもわかる計算機の秘密をとっとと教えろ!」みたいな、そんな、私をバカにした態度の輩に説明を求められ、それでも私は誠実に少し説明しかけるのだが、大概は私が10秒喋るか相手が100文字読むかしないうちに、もう面倒臭がられて説明は(さえぎ)られてしまう。テメェが説明を遮るのが理解できない原因なのに、「これだからコンピュータ屋は説明が下手糞だと言うんだ!ちったァ日本語を鍛えろ」などと吐き捨てられてしまう。そんな連中のお遊びの相手は、もうほとほと嫌だ。

 そんなアレやコレやが、最近の私の、人様から見れば無気力極まるITへの冷淡っぷりの、原因の幾つかなのだと思う。

20H2へのアップデートでBluetoothが使えなくなった場合の直し方

投稿日:

 Windows Update がかかり、半日以上もかかってやっとこさ完了した。「20H2」というバージョンである。

 これまでにも大きい Windows Update がかかった後によくあったことなのだが、上の Update の後、突然マウスが反応しなくなった。Bluetooth マウスだからで、こういう時、一連の Bluetooth モノはヘッドセット、キーボードなども全滅である。Windows を再起動しても直らない。「設定」画面の Bluetooth オン・オフボタンが無くなってしまっていてオンにもできない。デバイス・マネージャで確かめると Bluetooth Device が消失してしまっている。デバイス・マネージャの表示設定で「非表示デバイスを表示」にすると、Bluetooth 周辺機器が全部グレーアウトになって出てきてしまう。

 しかし、こうなってしまった場合の直し方は、実は簡単だ。

 UEFI あるいは BIOS セットアップ画面を出し、セットアップ・デフォルトをリストアして「Save changes & Exit」をかけるだけだ。一見、何の関係もないお(まじな)いのような操作に感じられるが、これは要するに、「ドライバキャッシュの使用などの迅速なブートの手段をWindowsに取らせず、一から清潔にブートさせる」ために一見関係ないように見えるこんな操作をするわけである。WindowsはUEFIあるいはBIOSのセットアップが変化していると判定すると前回の起動時の設定などを破棄して新たに読み直すわけであるが、UEFIやBIOSのどこが変わったかまでは見ないようで、そのため「単に Save Change するだけ」でよいようだ。

 同じことは、「一度セーフモードで起動し、なにも操作せずにもう一度通常起動する」というふうにしてもできる。だが、このほうが手数がかかるから、前述の方法の方が速い。

 ネットを(あさ)ると、似たようなことでお悩みの向きが多くいるようだ。そのような方は、上述の方法を試されては如何(いかが)

どアホ

投稿日:

 オノレは自分の家族にも使わせられんような出鱈目を世界中に売り(さば)いとったンかいッ。

 「だからこそやっぱりジョブズは偉いッ!」みたいな筆致も我慢がならない。こんなものを有難がっていてどうする。

日本ITストラテジスト協会を退会

投稿日:

 正会員として加入していた「日本ITストラテジスト協会」(JISTA)を退会することにした。

 日本ITストラテジスト協会は、情報処理技術者試験のうちでも最難関をもって知られる「ITストラテジスト」試験の合格者を中心に組織された協会で、全国組織である。会員の相互研鑽や情報発信、ITの普及への貢献など、様々な活動を行っている。

 私は8年前、ITストラテジスト試験に合格したことを機に入会し、一時期は大分熱心に活動に参加していた。しかし、最近4年ほどはあまり参加していなかった。

 このところJISTAは新型コロナウイルス蔓延の影響下にも関わらず、オンラインでの月例会開催などを通じて順調に入会者が増え、全国で800名を超す会員を擁するほどになった。そのこともあってか、協会内では「これまでの『任意団体』を脱却し『法人化』するに()かず」との動きが盛り上がった。縷々(るる)万端(ばんたん)(あい)(ととの)い、きたる2月から社団法人化されることとなった。

 社団法人となって法人格を獲得すれば、これまで困難であった「財産の管理」もできるようになり、また、実費以外は会員の持ち出し・持ち寄りで行われていた運営事務にも報酬が出せるようになる。運営や組織もより明確化するなど、よいことが多いのだ。それに、社会への情報発信力などもこれからより強化されることだろう。()(はか)るに、ゆくゆくは出版や人材育成、情報発信の事業などを通じて利益を上げ、管理し分配することも可能になるだろう。

 私は退会するが、これまでの月例会、テーマ別ディスカッション、毎年のオープンフォーラムを通じた自分の識能の向上や、会員の方々、それもIT業界でそれと知られるメンバーの方々とのあたたかい交流など、思い出は尽きない。

 協会におかれて、今後も益々盛会とされるよう祈念するものである。

マイクロソフトに(あさ)られる

投稿日:

 このブログへのアクセスが先般から急増していることを先日書いた。記事には「落ち着いてきた」と書いたが、実はその後、アクセス数は以前の倍ほどに高止まりのまま推移していた。

 記事の内部のリンクがあまりクリックされないこと、検索エンジンからの流入がそれほどないこと、アクセス元が米国であることなどから、恐らくは検索エンジンのクローラであろう、と推測はしていたが、面倒臭くて確かめてはいなかった。

 ところが、この金・土、そして日曜の今日、以前の3~4倍ほどのアクセスが殺到している。ブログ開設以来のアクセス数の最高記録を軽く突破してしまった。同じように記事の内部のリンクがクリックされたり、検索エンジンからの流入はそれほどない。勿論、このブログの人気化などでは決してない(苦笑)。

 もしハッキング、クラッキングの類だったりしたら嫌だな、と思い、サーバのログを確認してみた。そうしたら、「13.66.139.0」からのアクセスが大半を占めていることが判った。

 そこで、「13.66.139.0」って、どこのアドレスかな、と whois を引いてみたら……

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2020, American Registry for Internet Numbers, Ltd.
#
NetRange:	13.64.0.0 - 13.107.255.255
CIDR:	13.64.0.0/11, 13.104.0.0/14, 13.96.0.0/13
NetName:	MSFT
NetHandle:	NET-13-64-0-0-1
Parent:	NET13 (NET-13-0-0-0-0)
NetType:	Direct Assignment
OriginAS:	
Organization:	Microsoft Corporation (MSFT)
RegDate:	2015-03-26
Updated:	2015-03-26
Ref:	https://rdap.arin.net/registry/ip/13.64.0.0
OrgName:	Microsoft Corporation
OrgId:	MSFT
Address:	One Microsoft Way
City:	Redmond
StateProv:	WA
PostalCode:	98052
Country:	US
RegDate:	1998-07-10
Updated:	2017-01-28
Comment:	To report suspected security issues specific to traffic emanating from Microsoft online services, including the distribution of malicious content or other illicit or illegal material through a Microsoft online service, please submit reports to:
Comment:	* https://cert.microsoft.com.  
Comment:	
Comment:	For SPAM and other abuse issues, such as Microsoft Accounts, please contact:
Comment:	* abuse@microsoft.com.  
Comment:	
Comment:	To report security vulnerabilities in Microsoft products and services, please contact:
Comment:	* secure@microsoft.com.  
Comment:	
Comment:	For legal and law enforcement-related requests, please contact:
Comment:	* msndcc@microsoft.com
Comment:	
Comment:	For routing, peering or DNS issues, please 
Comment:	contact:
Comment:	* IOC@microsoft.com
Ref:	https://rdap.arin.net/registry/entity/MSFT
OrgTechHandle:	MRPD-ARIN
OrgTechName:	Microsoft Routing, Peering, and DNS
OrgTechPhone:	+1-425-882-8080 
OrgTechEmail:	IOC@microsoft.com
OrgTechRef:	https://rdap.arin.net/registry/entity/MRPD-ARIN
OrgAbuseHandle:	MAC74-ARIN
OrgAbuseName:	Microsoft Abuse Contact
OrgAbusePhone:	+1-425-882-8080 
OrgAbuseEmail:	abuse@microsoft.com
OrgAbuseRef:	https://rdap.arin.net/registry/entity/MAC74-ARIN
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/resources/registry/whois/tou/
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/resources/registry/whois/inaccuracy_reporting/
#
# Copyright 1997-2020, American Registry for Internet Numbers, Ltd.
#

 実に簡単なことで、CIDRブロック13.64.0.0/11、即ちマイクロソフト社、MSNのクローラーからのアクセスであることがわかった。

 しかしそれにしても、なんで今更、MSNがこのブログなんか(あさ)るんだろう??

「メッセージと画像(xxKB)をダウンロード」

投稿日:

 Windows10付属の「メール」を使用している。

 仕方なく使っているのであって、好きで使っているわけではない。実に使いづらく、気に入らない事の多いアプリなのだが、「Outlook Express」が添付されなくなり、「Windows Live Mail」もサポートされなくなった今、もう、どうしようもこうしようもないのでこれを使っているわけだ。

 気に入らないことだらけのこの糞アプリだが、時々憤激してしまうのが、「メッセージと画像(xxKB)をダウンロード」と表示されたまま、いつまでもウィンドウ上部の動作確認アニメーションが左から右へ流れ続け、肝心のメッセージは一向に表示されない、という現象が頻発することだ。

 しかも、この状態で1日くらい待っても、まったくメッセージを見ることができない。何かの登録確認メールでこの状態になると、お手上げである。登録確認メールには期限があり、悠長に待っていると取り消しになってしまうからだ。

 ところが、ふとしたことでこれを回避する操作が見つかった。左の画像がそれである。

 一見、まったく関係のない、ウィンドウ右上の「…(三点)メニュー」を操作すると、「名前を付けて保存」というメニューが出て来る。これをクリックするのである。

 クリックすると、「まだメッセージのダウンロードが済んでいません。保存するとおかしくなります」というような意味のスットコドッコイな警告が出るのだが、ところが、そのメッセージが出たあと、何日待とうが見ることのできなかったメッセージが、何事もなかったかのようにヒョイと表示されるのである。

 ネットでこの「Windows10メールアプリのメッセージがいつまでたっても表示されない」件を検索すると、同じようなことで悩んでいる方がたくさんいて、Q&Aサイトなどに多くの質問と回答があるのだが、回答がどれもこれも的を外しており、決定打に欠け、実に残念であった。しかし、上のような操作でメッセージを見ることができるようであるから、同様の症状でお悩みの向きは、是非試してみて頂きたい。