このブログ、a8ネットが運営するファンブログを利用しています。

1. 登録（無料）で維持費もかからず、ずっと無料で使えてます
   
2. しばらく放置（ブログ投稿がない）すると勝手に広告が表示される
   
3. httpsに対応している（2022年7月に対応しています）

   ずっとhttpのままだったので、別のブログに移動しちゃおうかと思っていました。対応してくれてよかったです。

   
   
4. 投稿システム自体は古めの感じです。慣れると気になりません。

↓興味のある方はこちら↓

A8.netの公式ページ

ファンブログで投稿しているとスパムコメントやトラックバックが増えてきます。ブログの設定でOFFにすることができます。ONの場合、承認後表示するモードが有効にできます。このブログはコメント、トラックバック共にONで承認後表示するにを入れています。

スパムは後からやってきます。アクセスがある記事を狙ってきます。スパムはコピー商品へリンクを送るようなものが多いです。

→承認後表示するがおすすめの設定ですよ。


→SNS主流な状況です。トラックバックもOFFでいいと思っています。

ブログが育ってくると、スパム（自動的にどこかの怪しげなショッピングサイト系が多いです）コメントがたくさん入ってくるように。

初めはIP禁止、禁止URL、禁止WORDとかでガードすることを試みていますが、スパムはIPを変え、URLを変えやってくるので追いついていけなりました。


現在は、気がついたときにある程度削除。という手動でやっていますが、ここにも罠があります。
ファンブログのコメント一覧（承認待ちコメント一覧）は承認削除保留という選択をコメント毎に設定し、削除する操作（実行）になります。

デフォルトが承認なんです。一覧には20件ぐらい表示されるんですが、一つ一つ承認を削除に切り替える操作が必要なんです。スパム相手にはとても不親切な設計だと思っていますよ。デフォルトの指定もできないし・・・


こんな時、一覧表示された20件を承認から削除に一括で変更するスクリプトを使って、楽しています。

var elms = document.querySelectorAll('#cms-MainCommentList select');
for( var i=0; i < elms.length; i++ ){ elms[i].value = "do_delete"; }

1. ブラウザの右クリック操作のメニューで検証（Chrome）や要素の詳細を表示（Safari）を選択することでDevToolやWebインスペクターが表示できます。
   
2. １）ここのコンソール(Chrome）、下の入力可能エリア（Safari）にコピペすることで動作します。
   

   【注意点】承認したい内容でも、一括で削除を選択します。

   
   

   コメント一覧、トラックバック一覧で動作します。

   
   
3. ２）上から順に20件確認して、削除しても問題ないかを確認します。
   
4. ３）下に表示されている「実行」ボタンを押します。
   
5. 以降は1）〜3）の繰り返しです。

   無心にやっているとミスがあるかもしれません。スクリプトを実行を忘れて（承認状態）で実行してしまった。２）の手順で先頭が削除になっていることをついでに確認しておくと防ぐことができます。

   
   

↓1行にまとめています。コピペで簡単に実行できます
var elms = document.querySelectorAll('#cms-MainCommentList select');for( var i=0; i < elms.length; i++ ){ elms[i].value = "do_delete"; }

まとめ：少し負担が減ります。

２０回の承認→削除の切り替え操作が減ります。内容を確認し、問題がなければ実行する流れでいけるので負担は減っていますよ。

一覧20件ではなく、100件、1000件選べるようにしてほしいですね

Xcodeを利用したmacOS用アプリで通知を利用したい場合があります。

Macの通知センターでは、見逃した通知を確認したり、ウィジェットを使って予約、誕生日、天気、最新ニュースのヘッドラインなどをデスクトップから直接確認したりできます。
https://support.apple.com/ja-jp/guide/mac-help/mchl2fb1258f/mac

目につきやすいメリットがあります（見逃すことは当然ありますね）。


UserNotifications（詳しくは→ https://developer.apple.com/documentation/usernotifications）を使う方法が正当です。タイトルやアイコンを自由に設定できるメリットがありますが、デメリットも感じています。

1. Xcodeのアップデートで利用方法が変わることがある。
2. セキュリティが強化され、追加の許可設定が必要なことがある

AppStoreに登録して公開するようなアプリではなく、自分用プログラムですので、もっと簡単な方法がない？あります

osascript（Apple Script）を使うことで通知できます。
この方法にはデメリットがあります。通知表示のアイコンやタイトルはスクリプトエディタです。
これを回避したい場合は、Swift標準方法のUserNotificationsを使うしかありません。

【macOS】swiftプログラムからmacOSの通知センターへ表示する簡単な方法のソース例

以下のようなメソッドを用意して呼び出すだけです。

    func macOSへ通知(_ message: String){
        let task = Process();
        task.executableURL = URL(fileURLWithPath: "/usr/bin/osascript")
        task.arguments = ["-e", "display notification \""+message+"\""]
        do{try task.run()}
        catch{print("exception")}

    }

• osascriptはmacOS標準のコマンドです。man osascriptでマニュアルを読むことができます。
  
• macOSへ通知("メッセージ")と呼び出すことで通知センターにメッセージが表示されます。
  
• macOSへ通知("メッセージ\nメッセージ")でメッセージを改行できます。

簡単に通知できました

Google Search Consoleでわかる順位やキーワード（QUERY）は、APIで取得することができます（詳しくは→https://developers.google.com/api-client-library）。APIで日々サイトのデータを収集（python3）、まとめ（php）ています。スケジューラーやクーロンで実行し、気になった時だけ参照する程度だとサーバー側の変更に気が付かず対応が遅れてしまうことがありますよね。これは本当にそのパターンです。

Traceback (most recent call last):
  File xxx in <module>
 webmaster=googleapiclient.discovery.build('webmasters','v3',credentials=credentials)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/googleapiclient/_helpers.py", line 130, in positional_wrapper
    return wrapped(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/googleapiclient/discovery.py", line 235, in build
    "name: %s  version: %s" % (serviceName, version))
googleapiclient.errors.UnknownApiNameOrVersion: name: webmasters  version: v3

UnkonwAPINameOrVersionエラーが発生するようになっていました。
2020 年 12 月 9 日（水）に発表されたGoogleの資料（https://developers.google.com/search/blog/2020/12/search-console-api-updates#discovery-doc-migration）を見ると解決できました。

管理しているpythonソースコード上では以下のような修正でgoogleapiclient.errorsは無くなりましたよ。

#webmaster=googleapiclient.discovery.build('webmasters','v3',credentials=credentials)
webmaster=googleapiclient.discovery.build('searchconsole','v1',credentials=credentials)

wp-jsonってご存知でしょうか？最近のワードプレスに標準装備されているAPIです。

1. HTTP ベースの REST API
2. サイトのユーザー、投稿、タクソノミー、その他のデータに対してシンプルな HTTP リクエストを送信することで、取り出したりアップデートすることが可能
3. デフォルトで有効

wp-jsonの厄介なポイントは

個人的にとても面倒だと思っているのは、認証不要でもアクセスできるエンドポイント（URL）が存在することです。把握しきれません。

また、wp-jsonへのアクセスはデータベースに対するクエリーが発生し、このクエリーがキャッシュされていない場合とても重いところがとても嫌です。

wp-jsonへアクセスしてくるのはbingbot（microsoft）

bingbotは新しいことが大好きなのようで、wp-json経由で情報を取得することを試みます。bingbot以外にもduckduckgoや怪しげな攻撃者が利用していることを確認しています。エンドポイントの実例は以下のような感じです。

• /wp-json/wp/v2/tags/521
  
• /wp-json/wp/v2/users/
  
• /wp-json/wp/v2/posts/3882
  
• /wp-json/wp/v2/pages/2213

Googleがこのwp-jsonにアクセスした実績は今の所ありませんでした。

そもそも、sitemap.xmlにも記載していないURLへのアクセスなので攻撃に等しいんじゃないかと思いますよ。＞ bingbot

wp-jsonへのアクセスをガッツリ遮断する

同様のことは、ワードプレスのactionやfilterなどでも可能だと思います。PHPで判断するコストが発生するので、初めの段階でアクセスしないように.htaccessで除外しています（↓の例ではwp-jsonで始まるURLはトップページにリダイレクト）。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-json(.*)$ https://サイト/ [R=301,L]
</IfModule>

まとめ：wp-jsonは閉じました。

.htaccessでwp-json系へのアクセスは全部トップページに遷移するようにしました。これでwp-jsonは無効になっています。

wp-jsonを利用できなくするデメリットは？今の所ありません。
ご自身で導入しているプラグイン、テーマ等でwp-jsonを利用しているパターンもあるかもしれません。こういった場合、wp-jsonは有効にしておく方がいいですね。

sqlite3データベースのファイルサイズは114,570,240バイト、テーブル数は1件だけです。ファイルサイズはそこそこあるんですが、１テーブルのみのデータベースで960件ぐらいの登録数です。この程度ならケア不要かと思っていたんですが、間違いでした。

SQLite3 1000件未満のテーブルでselectに1.78秒かかる

1. sqlite3のバージョンは3.7.17。
   
2. スキーマはこんな感じです

   
   CREATE TABLE tbl( pk INTEGER NOT NULL PRIMARY KEY, 
   sts, model,year, post_id, time, lapse, 
   mokuji, html, error_reason, fatal_reason );

   
   
3. 問題になったのは「select * from tbl order by time, year desc」の発行です。
   約1.78秒かかりました。サーバーの負荷が高い場合は30秒近くかかることがありました。
   
4. どうすべきか？処理の見直し、EXPLAIN QUERY PLANを使って調査、原因追求して対処するしかないですね。
   処理自体見直しましたが、これといっておかしな部分はありませんでした。
   

1000件未満のテーブルでselectに1.78秒かかる原因はUSE TEMP

SQLite3は「EXPLAIN QUERY PLANコマンド」でSQLの問題点（というかどんな感じに処理しているのか）を見つけることができます。（詳しくはこちら＝＞https://www.sqlite.org/eqp.html）

調査中データベースに変更を加える事になるので、対象のデータベースファイルをコピーしたものを利用しています。

1. PKが効いているパターンはこんな感じにシンプルな結果になります。

   explain query plan select * from tbl;
   0|0|0|SCAN TABLE tbl (~1000000 rows)

   
   
   
2. 遅いSQLはB-TREEのテンポラリを使ったソートを使っていることがわかります。

   explain query plan select * from tbl order by time, year desc;
   0|0|0|SCAN TABLE tbl (~1000000 rows)
   0|0|0|USE TEMP B-TREE FOR ORDER BY

   このUSE TEMPを消すことができれば速く改善できます。
   
   
3. インデックスはtime,yearは不正解でした。

   sqlite> create index idx_1 on tbl( time, year );
   sqlite> explain query plan select * from tbl order by time, year desc;
   0|0|0|SCAN TABLE tbl (~1000000 rows)
   0|0|0|USE TEMP B-TREE FOR ORDER BY
   sqlite> drop index idx_1 ;

   結果は変わりません。
   
   
4. order句に指定しているすべてを対象にします。time,year descが正解です。

   sqlite> create index idx_1 on tbl( time, year desc);
   sqlite> explain query plan select * from tbl order by time, year desc;
   0|0|0|SCAN TABLE tbl USING INDEX idx_1 (~1000000 rows)

   USE TEMPが消えました。
   

まとめ：indexを適切に設定することで改善できます。EXPLAIN QUERYは万能ではないです

phpで「$開始=array_sum( explode(' ', microtime() ));処理;echo array_sum( explode(' ', microtime() )) - $開始;」とmicrotime関数を利用すると精度の高い実行時間を計測することが可能です。

↓で1.78秒かかっていました。EXPLAIN QUERY PLAINで見つけたindexで0.088秒に改善することができました。

            $results = $db->query("select * from tbl order by time asc,year desc"); 

今回の知見：データベースファイルサイズが大きいと、USE TEMPを利用するパターンは速度的な影響をモロに受けることがわかりました。



EXPLAIN QUERY PLANはクエリがデータベースインデックスを効果的に利用しているのか？、インデックスを設定することで速くできるのか？という視点で調査する場合に使えるコマンドです。

PHPプログラムをcronでスケジュール実行しています。PHP7からPHP8にアップグレードすることで速度アップするメリットがあるようなので気軽にPHP8に変更しました。ひっそりとPHPプログラムが異常終了していました。



変数の初期化忘れは致命的・・・

Xcode Version 13.4、macOSアプリでの話です。久しぶりにWKWebViewを利用したアプリに着手、実行したらURLリクエスト（webview.loadメソッド）でInvalid connection identifierエラーが出て何も表示されないアプリになりました。

プロジェクトのプロパティを変更することで解決できます。
「Singing ＆ Capabilities」→AllのApp Sandboxを探します。
Network項目の「Outgoing Connections(Client)」がチェックされていることを確認します。
→これをチェックすることで接続できるようになりました。

前からこの設定あった？Xcode ＋ Swiftの環境は変化が激しいので情報アップデートが必要ですね。

Rakuten Web APIで商品アイテム検索するPHPプログラムを利用しています。PHPのfile_get_contents関数でWeb Requestしています。
リクエスト部分するソースは↓こんな感じです。

数あるレンタルサーバーの中でエックスサーバーがとてもいいと思うポイントは「満足度が高い」ところです。

1. 【契約者に優しい対応】以前に契約した古いサーバーでも自動的に最新サーバーに移行してくれた（数時間のストップあり、ユーザーはほぼ何もしなくてOKでした）。
   
   
2. 【速い】サーバー自体素早いレスポンス（Google PageSpeed Insightsでサーバーの応答性に関する問題は発生しづらいです）
   
   
3. 【満足】継続する増強 KUSANAGI対応、転送量上限無制限化

ずーっと使い続けても「速い」が維持されるところがいいですよ。

続きを読む...

ご存知のようにmacではXcodeを使ってiPhoneの実機デバッグが無料で出来ます（従来実機デバッグは有料範疇でした）。気軽に作ったアプリを手持ちのiPhoneで動かすことができます。

macとiPhoneをUSB(Lightning)接続することでアプリをデバッグすることができます。Xcodeのインストール、証明書の発行などいくつかのハードルがありますね（いずれも無料です）。

デバッグを繰り返しているとXcodeデバッグ実行開始した際、ある日突然「Unlock iPhone to Continue」というダイアログが表示されデバッグ実行できない状況になることがあります。

通常iPhoneがロック画面になっている状況でこのメッセージが表示されます。

問題なパターンは、「ロックが解除されホーム画面が表示されている状態でも『Unlock iPhone to Continue』で実行できない」場合です。
「Unlock iPhone to Continue」でググるとたくさんの情報が出てきます。リセットする方法などもありましたが、これやらないでください。このパターンには当てはまらないと思います。

Unlock iPhone to Continueでアプリが起動できない、初めにやるべき処置は、再起動です

デバッグに使っているiPhoneの電源を一旦OFF後、再度電源ONにしてください。

これだけで、元に戻ります。

戻らないパターンは確認できていませんが、もし、これでダメならXcodeを再起動してみてください。これでもダメならmacの再起動を試してみてください。全部ダメー＞別の方法をお試しください。

再起動は、初めにやるべき改善の可能性がある最も簡単な方法です。

デバッグ中にLightingケーブルを抜いたりすることが多かったです。こういう場合に、iPhone内部で動作中のデバッグ用プロセスの何かが残っている、それがこの「Unlock iPhone to Continue」ダイアログの表示を引き起こしていると推測しています。

再起動することで、不要なプロセスをクリーンできます。