TortoiseSVN 1.8.0 でクライアント認証ができず・・・

Subversionが1.8にアップデートしたので、TortoiseSVN 1.8.0を何も考えずクライアントPCにインストールした。作業コピーに変更があったみたいで、作業コピーを片っ端からアップデートアップグレードした。

・・・結果、「TortoiseSVN 1.7.7でクライアント認証が失敗する」の二の舞を踏むことに・・・orz

インストールする時一抹の不安が過ぎったけど、後先考えず、「エイヤ!」ってな感じで。結局、やっぱり失敗。

一応サーバーはCentOS 5でApache 2.2.3 + オレオレ認証局のSSL環境。TortoiseSVN1.7.12を使っていたときはちゃんとクライアント認証のプロセスが通ったが、またしても1.8.0に上げたら今度は固まったまま。subversion自体がダメなのか、それともTortoiseSVNの部分がダメなのか、調べるだけの知識がないので、もうお手上げ。

検索してみたけど、やっぱりリリース直後なのでバージョン1.8の情報が出てこない。

結局、Apacheの設定で、SSLクライアント認証を解除して、ダイジェスト認証に切り替えることで、事なきを得た。

・・・が、Windows7上でTortoiseSVN1.8.0をインストールすると、ダイジェスト認証すらなんか怪しい挙動をする。作業コピーの更新をすると、ユーザー・パースワード入力ダイアログが出るのですが、正しいユーザー名・パスワードを入れてもエラーになる、あきらめてキャンセルすると、今度は違うダイアログ(Windows7の資格情報のダイアログ?)が出てくる。なんかワケ分からない。

ダメもとで何回もユーザー・パスワードの入力をトライしてみると、認証された。

よく分からん。

とにかく、元に戻そうかと・・・思ったけど、十数個ある作業コピーのチェックアウト作業がメンドクサイので、Apacheの設定をこのままにして、バージョンアップを待つことにする。

サーバーがオレオレSSLだからダメなのかなー・・・・とか、CentOS5のApacheのバージョンが低いのが原因なのかなー・・・とか思ったけど、確かめようがない。

この際だから、サーバー上のSubversionのバージョンを1.6系列から1.7系列最新の1.7.10にソースからビルドしてアップデートした。念のため、レポジトリのダンプをとったが、こちらは何ら問題なくバージョンアップ完了。さすがにサーバー上のsubversionを1.8.0にする気がしない。。。

テーマやテンプレートを動的に変更

私的記録です。

WordPressで、サイトの「お知らせ」というカスタム投稿タイプを作成した時のこと。

たとえば他のサイトからインラインフレームで読み込ませるときは、特定のテンプレートに変更したい、という場合、template_includeというフィルターが使える。トリガーとして、URLパラメータになにがしらのパラメータを渡したときに切り替えるようにすれば上手くいきます。

また、ある特定のURLパラメータをつけてアクセスしたときは、別のテーマで表示したい! という、それって何の意味があるの?的なこともしたかったので、纏めてプラグインにした。

チョー簡単(^^; WordPressってホントよく出来てますね~。

<?php
/*
Plugin Name: Switcher for Theme or Template
*/

/************************************************************
 動的にテーマやテンプレートを変える
 すっごい手抜きサンプル
************************************************************/
add_filter('template_include','DynaChange::Template');
add_filter('stylesheet', 'DynaChange::Theme');
add_filter('template', 'DynaChange::Theme');

class DynaChange
{
  public static function Template($template)
    {
      //URLパラメータにchtmp=プレフィックス があれば、
      //現在のテンプレートファイル名にプレフィックスを付けた
      //テンプレートファイルに切り替える。
      //適当サンプルのため、子テーマには対応していない。
      if(!empty($_GET['chtmp']))
        {
          $name = str_replace(STYLESHEETPATH . '/', '', $template);
          $template = STYLESHEETPATH . '/' . $_GET['chtmp'] .'-'. $name;
        }

      return $template;
    }

  public static function Theme($stylesheet)
    {
      //URLパラメータに chth=テーマ名 があれば、
      //そのテーマに切り替える。

      if(!empty($_GET['chth']))
        {
          $theme = wp_get_theme($_GET['chth']);
          if($theme->exists())
            $stylesheet = $theme->Template;
        }
      return $stylesheet;
    }
}
?>

説明要らないっすね~。

Vista以降では安易にスレッドを作るな!?

■2021年8月3日
gistにコードを移すとき、コピペした時に文字化けしてたところとか io_completion_port_xp.cpp/io_completion_port_vista.cppを諸々修正


LinuxやBSDなどのUNIX互換のOSと違って、Windowsではスレッドを起こすのは普通に行われてることだと思います。で、スレッドを起こすには、CreateThread API もしくは、Cランタイムライブラリの_beginthreadex関数を使うことになります。

が、一方でスレッドを生成するのではなく、スレッドプールを利用する、というケースもあり、パフォーマンス的な事を考えれば、むしろこちらの方が多いかもしれません。

Windows 2000/XPなどのNT5.x系では、QueueUserWorkItem APIというスレッドプールに関するAPIが使えます。。。けど、はっきりいって、このAPI、よほど簡単なロジックでないと使えません。いったんこのAPIでキューに入れてしまうと、もう手が出ません。外からキャンセルできないし、強制終了させようとしてもTerminateThread APIは使っちゃだめ!ですし・・・。
結局、ちょっと凝ったことさせようと思ったら、自前でI/O完了ポートを駆使してスレッドプールを実装する他なかったと思います。

しかし、Windows Vista以降のNT6.x系のWindowsでは、より進化したスレッドプールAPIが追加されています。もはや、Vista以降のWindowsで、CreateThreadや_beginthreadex関数を使ってスレッドを起こすコーディングはダサイといわざる得ません(^^;;;

というか、CPUがデュアルコアは当たり前、マルチコアがデフォルトってな状況の中で、これからはメニーコアだ! っていう時代なので、アプリケーション開発者側が、コア数のことまで考えて組む・・・とかもう無理!そんなのは限られたスーパープログラマーしかできんわ(笑) ってことです。

だから、CreateThread APIや_beginthreadex関数でスレッドを起こす前提のロジックでコーディングしちゃだめ。ってことに。

ただ・・・スレッドを作ってそこにウィンドウを作成する、というようなケースには向きません。とどのつまり、プロセス開始から終了まで生存するようなスレッドの場合、スレッドプールに処理を投げる意味はありません。あくまで、一つのスレッドの生成・削除が頻繁に行われるケースや、スレッドの生存期間が短いケース等でスレッドプールの恩恵を受けることができると思います。

ま、今更ですが(^^;;; この新たに追加されたスレッドプールなAPI群は、スレッドの生成と管理をすべてWindowsが肩代わりしてマシンに積まれているCPUの数(コア数?)と負荷状態に応じて最適な性能を発揮できるようになっているようです(・・・なっているはずです)。

例えば、ちょっとしたユーティリティアプリなんかで、単純な処理を非同期(並行)処理させる場合、TrySubmitThreadpoolCallbackもしくは、CreateThreadpoolWork/SubmitThreadpoolWorkでほとんど事足りると思います。

CreateThreadや_beginthreadexのあの引数の多さにうんざりすることが無くなり、スレッドハンドルを管理するコード、同期のためにイベントオブジェクトを作成して待機するようなコード諸々を実装する手間が大幅に軽減されます。ヒャッホーーー!

当然ですが、上記はXPでは実行できません。

他にも、タイマーオブジェクトを利用した関数の繰り返し処理、jscriptでいうところのsetTimeout / setIntervalメソッドみたいな、一定時間毎にコールバック関数を実行してくれるCreateThreadpoolTimer APIや、カーネルオブジェクトがシグナル状態になったらコールバック関数を実行してくれる CreateThreadpoolWait API、ReadFile/WriteFileなどのI/O非同期処理に利用できるCreateThreadpoolIo API。

一連のスレッドプールに関するAPIは非常に強力で、使い勝手もいい。デフォルトのスレッドプールの動作が気に入らなければ、カスタマイズしたスレッドプールを利用することもできる。

自分的に便利だと思ったのが、ReadFIle/WriteFileでI/O非同期処理に利用できる、CreateThreadpoolIo/StartThreadpoolIo。
今まではI/O完了ポートで通知を受け取って・・・というようなコードを書いてましたが、Vista以降のOSに限定すれば、これらのスレッドプールAPIを使うことでコード量が減ります。

ReadDirectoryChangesW APIを使ったディレクトリへの変更を監視するコードをスレッドプールを使ったコードに強引にリプレースしてみました。

まずは、昔作った、WindowsXPで動作する、IO完了ポートとワーカースレッドを単純に作って利用したバージョン。

要点は、スレッドを作成して監視が終了するまで待機。ReadDirectoryChangeW APIの非同期処理が完了するとIO完了ポートのキューにI/O完了パケットが追加され、ワーカースレッドのGetQueuedCompletionStatus APIが制御を戻すことでReadDirectoryChangeW APIの処理結果のデータを得て、再びReadDirectoryChangeW APIをコールし非同期処理を継続します。

続いて、上記をVista以降のスレッドプールのAPIを利用したバージョン。

あまり違いがないように思いますが、スレッドを何個作るべき?だとか細々とした調整などが不要になり、何より_beginthread関数などのプリミティブなAPIを使わなくても良くなりました。以前なら、スレッド処理をラップする、なんらかのクラスライブラリが必須だったと思いますが、ちょっとしたツールを書くときはこれらの新しいスレッドプールなAPIを使えば良くなりました。

ま、ちょっとしたツールを作るにはC#を使えば済む話で、わざわざC++を使う必要性があるとは思えませんが・・・。ま、要するに自己満です(^^;;;

WORDPRESSプラグインのテンプレート

私的記録。

WordPressのテーマやプラグインは便利ですよね。
既存のプラグインを組み合わせて使うと、あら不思議、それなりにWEBシステムが出来てしまうではありませんか(^_^;)

あまりにも便利なので、自分でも足りない機能を作ってしまいたい、と思うのは当然でしょう。

というわけで、プラグインをすぐ作れるようにスケルトン的なテンプレートを記録。

Add Html Code

このスケルトン・プラグインは、wp_head,wp_footerのアクションを登録するプラグインである。
要するにテーマのヘッダとフッタに好きなHTMLコードをインジェクトするプラグイン。

このスケルトンは4つのファイルで構成されています。

■プラグイン本体 (addhtml.php) まずはこれがないと。

<?php
/*
Plugin Name: Add HTML code for WordPress
Description: Add head or foot html code
Version: 1.0
Author: Kenji Nakagawa
License: none
*/

//start up!
require_once(dirname( __FILE__ ) .'/addhtml-common.php');

if(is_admin())
{
  require_once(dirname( __FILE__ ) .'/addhtml-setting.php');
  AddHtmlCodeSetting::register(plugin_basename(__FILE__));
}
else
{
  require_once(dirname( __FILE__ ) .'/addhtml-doaction.php');
  AddHtmlCode::register();
}

?>

以下、これまで散々関数名のバッティングに悩まされてきたので、片っ端からclass作って、staticメンバ関数に放り込んでます。

■共通変数と関数 (addhtml-common.php)

<?php
class AddHtmlCodeCommon
{
  protected static $options;

  protected static function unescape($str)
    {
      $str = str_replace("\\\"","\"",$str);
      $str = str_replace("\\'","'",$str);

      return $str;
    }
}

?>

■設定管理ページ (addhtml-setting.php)

<?php
class AddHtmlCodeSetting extends AddHtmlCodeCommon
{
  private static $plugin_file;

  public static function register($pfile)
    {
      self::$plugin_file = $pfile;
      // addon check
      if ( !function_exists( 'add_action' ) )
        {
          echo "I'm just a plugin, not much I can do when called directly.";
          exit;
        }

      add_action('admin_menu', __CLASS__.'::option');
      add_filter( 'plugin_action_links', __CLASS__.'::action', 10, 2 );
    }

  public static function action( $links, $file )
    {
      if($file !== self::$plugin_file)
        return $links;
      
      array_unshift( $links, '<a href="options-general.php?page=addhtmlcode">設定</a>');
      return $links;
    }
  
  public static function option()
    {
      add_option('addhtmlcode');
      add_options_page('Add Html Code設定', 'Add Html Code', 10, 'addhtmlcode', __CLASS__.'::options_page');
    }

  public static function options_page()
    {
      // フィールドと設定項目名のための変数
      $opt_name = 'addhtmlcode';
      self::$options = get_option($opt_name);

      // ユーザが何かの情報を投稿したかどうかをチェックする
      // 投稿していれば、このhiddenフィールドの値は'Y'にセットされる
      if($_POST['action'] === 'update')
        {
          // 投稿された値を読む
          self::$options = array();
         
          self::$options['header']  = $_POST['header'];
          self::$options['footer']  = $_POST['footer'];

          // データベースに値を設定する
          update_option( $opt_name, self::$options);

          // 画面に更新されたことを伝えるメッセージを表示
          echo '<div class="updated"><p><strong>設定が保存されました。</strong></p></div>';
        }

      self::$options['header'] = self::unescape(self::$options['header']);
      self::$options['footer'] = self::unescape(self::$options['footer']);

      // 設定変更画面を表示する
?>
<div class="wrap">
<div id="icon-options-general" class="icon32"><br></div>
<h2>Adding HTML Code</h2>
<p>
 ※ヘッダー、フッターに任意のHTMLコードを挿入します。<br>
 このプラグインを適用させるには、テンプレートヘッダ(header.php)・フッター(footer.php)にそれぞれ、
 wp_head(),wp_footer()を記述する必要があります。
</p>
<form name="form1" method="post" action="<?php echo str_replace( '%7E', '~', $_SERVER['REQUEST_URI']); ?>">
<?php wp_nonce_field('update-options'); ?>

<h3 class="text-box-title">ヘッダー&nbsp;<span>&lt;head&gt;タグ内に挿入されます。</span></h3>
<textarea name="header" class="text-box"><?php echo self::$options['header']; ?></textarea>

<h3 class="text-box-title">フッター&nbsp;<span>&lt;/body&gt;直前付近に挿入されます。</span></h3>
<textarea name="footer" class="text-box"><?php echo self::$options['footer']; ?></textarea>

<p class="submit">
<input type="hidden" name="action" value="update">
<input type="hidden" name="page_options" value="header,footer">
<input type="submit" name="Submit" value="設定を更新する">
</p>

</form>
</div>
<style type="text/css"><!--
form { padding: 1em; margin-top: 1em;}
.text-box { display: block;width: 80%; height: 10em; margin-bottom: 3em;padding: 0.5em;}
.text-box-title { margin-bottom: 5px;}
.text-box-title span { font-size: 80%; color: green;}
--></style>
<?php
    }
}

?>

■実際の出力 (addhtml-doaction.php)

<?php
class AddHtmlCode extends AddHtmlCodeCommon
{
  public static function register()
    {
      // addon check
      if ( !function_exists( 'add_action' ) )
        {
          echo "I'm just a plugin, not much I can do when called directly.";
          exit;
        }
      
      self::$options = get_option('addhtmlcode');
      
      add_action('wp_head', __CLASS__.'::add_header');
      add_action('wp_footer', __CLASS__.'::add_footer');
    }

  public static function add_header()
    {
      echo self::unescape(self::$options['header']),"\n";
    }

  public static function add_footer()
    {
      echo self::unescape(self::$options['footer']),"\n";
    }
}

?>

知らなかった

perlで、use strict; してても$aと$bってmy or ourせずに使っても、
未定義エラーを吐かないんですね。。。知らんかったー。
といっても$a,$bなんていう変数名は僕的に滅多に使わないので、
別にどうでもいいっちゃ、いいんですがね^^;

PHP5はClassを定義して、OOPなコードが書けるので、修正や機能追加しやすいように依頼されたコードをクラスで書いて渡した。もし機能の追加・既存メソッドの修正があったら、ファイルを一個追加して、修正・変更が必要なクラスを派生させて(継承して)新しいクラスを作ればソースファイル管理もラクになるだろうし・・・と思ったんだよねぇ。

でも実際は違った。どうやらその人はPHPを「まともなコードが書ける人」じゃなくて、単に「PHPの文法が分かってるだけの人」なんだというのがやっと分かった。知らんかった-。

その人は、渡したファイルのクラスのメソッドを直接修正してるし・・・何のためにクラス化したんだよ orz
渡すとき、「変更があったら該当クラスを継承させて使ってねー」とか言っておくべきだった。

誰が、どの言語を、どの程度知っているのか、全く分からん!