PHP製の静的サイトジェネレーター Sculpin を、Windows 上で Docker で実行しました。
サンプルのテーマを派生させて差分で日本語+自分用のテーマを作ろうとしたけど、theme の仕組みはまだ実験的です、とある通り、サンプルテーマもテーマ内のアセット読み込みに対応してなかったりまだまだでした。
セットアップのメモをSculpin自身を使って静的ブログにしてみました。
Home — Docker ComposeでSculpinを動かすブログ — ついでにサンプルテーマを日本語に
使えそうなら自分用で必要な Theme と Bundle を作っていこうかとも思っていましたが、他のツールも触ってみた方がいいかもという結論になりました。
Javaの講義、試験が「自作関数を作り記述しなさい」って問題だったから
「ズン」「ドコ」のいずれかをランダムで出力し続けて「ズン」「ズン」「ズン」「ズン」「ドコ」の配列が出たら「キ・ヨ・シ！」って出力した後終了って関数作ったら満点で単位貰ってた— てくも (@kumiromilk) March 9, 2016
ランダムな結果の中から特定のシーケンスが出たら「キヨシ」を出し、終了する、という要件で、解き方はいくらでもあると思いますが、自分が考えたのは有限オートマトンを使ったもの。
まずはPHPでFSMを扱っているパッケージを探します。Packagist でFSM で検索。ダウンロード数が多いパッケージをいくつか見てみて、使い方が好みなものを選びます。今回は Stagehand_FSM を選びました。業務ならここでパッケージの中を精査するんでしょうけど、まあここでは省略します。
{
"require": {
"piece/stagehand-fsm": "2.4.*"
}
}
Composer で持ってきて呼び出します。楽ちんですね。
require 'vendor/autoload.php';
use Stagehand\FSM\StateMachine\StateMachineBuilder;
ドキュメントにありますが、ステートマシンのインスタンスを作り、状態と遷移と開始(や終了)を与えて動かすだけ。
ということで、与えるデータを作るために、次はズンドコキヨシ問題の遷移図を考えます。”online FSM editor”で検索すると、ブラウザで遷移図を描けるページが見つかりました。これは便利。
(間違いがあり、画像を差し替えました。@qckanemoto さんありがとうございました。)
あとは図を基に状態と遷移を与え、それぞれの状態で「ズン」や「ドコ」、あるいは「ドコキヨシ」を表示させれば完成です。
今回のチャレンジを最短の手数で解くだけなら、必ずしもFSMみたいなものを使う必要はないでしょう。ただ、遷移図や遷移表みたいなものを書いて、それをただコードに落とし込む、というのは、抜けを減らせる安心感があります。
# 図を間違うこともありますし、コード化するときに間違うこともありますけどね。テスト書いてないので、業務レベルなら失格です
もし、キヨシが出る条件が頻繁に変わるとか、ズンとドコを使って新しい曲を作りたいとか、同じコードのデータ(遷移表)だけをさまざまに切り替えて別の動作をさせたいとか、そういう方向に仕様の変化が予想される場所なら、使うといいのではないかなと思います。ゲーム系のプログラマーはたぶんこういうの日常的に使ってるのでは。
あとは、描いた遷移図や遷移表からそのままJSONなりの定義が出力できて、それを直接食わせたら動くライブラリ、みたいなものがあると、もっと楽で間違いもないんだろうなあ、と思いました。さらに手間を掛けるならそういうツールやライブラリを探すか、作るかするんでしょうね。
https://www.youtube.com/watch?v=c0H_qGSJKzE
WordPress のサーバ再構築をする必要があり、標準のXMLエクスポート形式であるWXRファイルを読み込ませたところ、最新のWordPressを使っているのにも関わらず以下のような警告が出てきます。
( ! ) Strict standards: Declaration of WP_Import::bump_request_timeout() should be compatible with WP_Importer::bump_request_timeout($val) in C:\Users\akky\OneDrive\services\akimotojp\blog\wp-content\plugins\wordpress-importer\wordpress-importer.php on line 38
バグ報告もされているのですが、これがなんと2年も前のもの。ずっと直ってないというわけです。
直し方がわかってないわけではなく、現時点のバージョンなら、wp-content/plugins/wordpress-importer/wordpress-importer.php 1110行目の
function bump_request_timeout() {
を
function bump_request_timeout($unused) {
などとするだけです。
わかってるなら配布してるオリジナルを直してよ、と思うところですが、バグチケットの中でリード開発者により「まれにしか使わないインポートの警告を消すためだけに、500万人の管理者にアップデートさせるのは『アップデート疲れ』(update fatigue)もあるのでやりたくない」という結論が出されていました。
そして、他の重要な修正も入るなら喜んでプラグインの更新を掛けるよ、と、未解決のインポート周りのチケットリストを紹介することで返答を結んでいます。
そんなに気になるなら他の重要なバグ直せば一緒に直るよ、なんていう返しもあるのかあ、と変なところで感心しました。
インポート機能を全員が使うわけではない、というのは確かにその通り。インポート作業をするぐらいの利用者なら警告の意味も読めるし、これが実害のない警告に過ぎないこともちょっと検索すればわかるかもしれません。
しかしそれでも、推奨された最新バージョンを使って、標準で動かして警告が出てしまうのは、それこそ500万ユーザーを誇るならカッコ悪いように思うですが。警告を見た人の多くはそれが何かを調べ、対処するなり無視するなり判断するという時間を取られていますし。
WordPress Importerプラグインの一番新しいバージョンも5ヶ月前に出ており、このチケットが切られた2年前より後に修正を含めるタイミングはあったみたいだし。
# 他にStrict Standardsを外すという解決法もなくはないですが、PHP 7 も見えているこの時期にそんなことをするのは当然オススメできません。