「PHP」カテゴリーアーカイブ

[メモ] Docker + Spress で静的サイトを作る

PHP製の静的サイトジェネレーター Spress を、Windows 上で Docker で実行しました。

ソース

PHP製の静的サイトジェネレーターSculpinを使ってみたのですが、開発が思ったほどアクティブでなさそうなのと、Spress が Sculpin の影響を受けた後継者である、みたいなことを言っている人がいたので、こちらも試すことにしました。

今回も、Docker Compose を使ったセットアップのメモを、Spress自身を使って静的ブログにしてみました。

SpressをDocker(+Compose)で動かす

しかし、日本語のタグやカテゴリーに対してファイルを生成しないので、非ヨーロッパ諸語に関してはSculpinよりも手入れが必要という印象でした。slugを作るところの関数が、UTF-8一般には対応しておらず、マッピングテーブルを使ってウムラウト等を消しているだけ。

明治150年だけじゃない! 毎年和暦のキリ番を祝いたい人のためのキリ番情報

今日のニュースより

菅官房長官は閣議のあとの閣僚懇談会で、「再来年は明治元年から150年を迎え、わが国にとっても一つの大きな節目だ。明治の精神や日本の強みを再認識することは極めて重要であり、明治以降の歩みを次世代に残すことが大事だ」と述べました。

官房長官 再来年の「明治150年」へ施策検討 | NHKニュース

2000年のときに江戸400年を祝った覚えないな。なぜ明治だけ?

はてなブックマーク – yamaisan のブックマーク – 2016年10月7日

年号はいっぱいあるのに、ってことですね。明治が好きで明治に戻りたくてしょうがない人が政治家に多いのかもしれません。

それはともかく、「年号はたくさんあるので、毎年何かしらキリのいい〇〇周年になってるのでは」と思い、計算してみました。前後10年ずつ20年分です。ソースコードはこちら

2006年(平成18年)は

2007年(平成19年)は

2008年(平成20年)は

2009年(平成21年)は

2010年(平成22年)は

2011年(平成23年)は

2012年(平成24年)は

2013年(平成25年)は

2014年(平成26年)は

2015年(平成27年)は

2016年(平成28年)は

2017年(平成29年)は

2018年(平成30年)は

2019年(平成31年)は

2020年(平成32年)は

2021年(平成33年)は

2022年(平成34年)は

2023年(平成35年)は

2024年(平成36年)は

2025年(平成37年)は

今年2016年は享保300年だそうです。暴れん坊将軍の時代ですね。そして、検索したら出てきました。享保300年を祝ってる人たち。明治だけじゃなかった!

造幣局 : 享保の改革300年2016プルーフ貨幣セット~貨幣の改鋳~の通信販売について

300年に一度の企画【享保の会 大感謝祭】開催のご案内 | ジャパントラディショナルカルチャーラボ

来年2017年は、応仁550年。応仁の乱も550周年というわけですね。

来年はまた、養老1300年でもあります。「養老」って年号だったんだ。関係ないけど養老の滝は今年60周年だそうです。

スーパー切りの良い年ということだと、来年の寛仁1000年や、2021年の治安1000年がとても切りがいいですね。「治安」なんて年号もあったんだ。

[メモ] Docker + Sculpin で静的サイトを作る

PHP製の静的サイトジェネレーター Sculpin を、Windows 上で Docker で実行しました。

ソース

サンプルのテーマを派生させて差分で日本語+自分用のテーマを作ろうとしたけど、theme の仕組みはまだ実験的です、とある通り、サンプルテーマもテーマ内のアセット読み込みに対応してなかったりまだまだでした。

セットアップのメモをSculpin自身を使って静的ブログにしてみました。

Home — Docker ComposeでSculpinを動かすブログ — ついでにサンプルテーマを日本語に

使えそうなら自分用で必要な Theme と Bundle を作っていこうかとも思っていましたが、他のツールも触ってみた方がいいかもという結論になりました。

ズンドコキヨシ問題をPHPとFSMで解く

先週一部で流行していたズンドコキヨシ問題

ランダムな結果の中から特定のシーケンスが出たら「キヨシ」を出し、終了する、という要件で、解き方はいくらでもあると思いますが、自分が考えたのは有限オートマトンを使ったもの

まずはPHPでFSMを扱っているパッケージを探します。PackagistFSM で検索。ダウンロード数が多いパッケージをいくつか見てみて、使い方が好みなものを選びます。今回は Stagehand_FSM を選びました。業務ならここでパッケージの中を精査するんでしょうけど、まあここでは省略します。


{
"require": {
"piece/stagehand-fsm": "2.4.*"
}
}

Composer で持ってきて呼び出します。楽ちんですね。


require 'vendor/autoload.php';
use Stagehand\FSM\StateMachine\StateMachineBuilder;

ドキュメントにありますが、ステートマシンのインスタンスを作り、状態と遷移と開始(や終了)を与えて動かすだけ。

ということで、与えるデータを作るために、次はズンドコキヨシ問題の遷移図を考えます。”online FSM editor”で検索すると、ブラウザで遷移図を描けるページが見つかりました。これは便利。

zundokokiyoshi_FSM
(間違いがあり、画像を差し替えました。@qckanemoto さんありがとうございました。)

あとは図を基に状態と遷移を与え、それぞれの状態で「ズン」や「ドコ」、あるいは「ドコキヨシ」を表示させれば完成です。

FSMを使う意味

今回のチャレンジを最短の手数で解くだけなら、必ずしもFSMみたいなものを使う必要はないでしょう。ただ、遷移図や遷移表みたいなものを書いて、それをただコードに落とし込む、というのは、抜けを減らせる安心感があります。

# 図を間違うこともありますし、コード化するときに間違うこともありますけどね。テスト書いてないので、業務レベルなら失格です

もし、キヨシが出る条件が頻繁に変わるとか、ズンとドコを使って新しい曲を作りたいとか、同じコードのデータ(遷移表)だけをさまざまに切り替えて別の動作をさせたいとか、そういう方向に仕様の変化が予想される場所なら、使うといいのではないかなと思います。ゲーム系のプログラマーはたぶんこういうの日常的に使ってるのでは。

あとは、描いた遷移図や遷移表からそのままJSONなりの定義が出力できて、それを直接食わせたら動くライブラリ、みたいなものがあると、もっと楽で間違いもないんだろうなあ、と思いました。さらに手間を掛けるならそういうツールやライブラリを探すか、作るかするんでしょうね。

ワードプレスのインポートツールで警告が消えない問題

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

wordpress-importer-caution

バグ報告もされているのですが、これがなんと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 も見えているこの時期にそんなことをするのは当然オススメできません。

weca.mp – 島でPHPの開発合宿

面白い開発合宿の案内が流れてきたのでご紹介。この業界、泊り込みのイベントを「キャンプ」となぞらえることは良くありますが、今回企画されたPHPの開発合宿We Campは本当のキャンプ場で開催されます。しかも場所は島。

wecamp-island

オランダのデ・クルート島。地図によれば、フェルウェ湖という湖の中に浮かぶ島のようです。宿泊は「豪華な」テント。トイレ・シャワー完備。

イベント内容ですが、当日集まった中からランダムな5人でチームを組み、コーチの助言を受けながら新しいものを開発するということ。技術を高めるのももちろんですが、チーム開発やチーム管理なども鍛えられる機会になると。

また、「人生は仕事と技術だけではない」ということで、ただ缶詰になって開発するだけではなく、昼間のボートやカヌー、夕方からのいろいろなアクティビティも予定されているのだとか。

開催は8月25日から29日の5日間。参加料は食事や往復のボート代も含めて375ユーロ。現時点での残り参加枠は24人分だそうです。PHPの開発者でこの夏冒険してみたい人、オランダまでどうでしょう? オランダでのイベントですが、サイトも全部英語ですし、このあたりのイベントは周辺の国からも参加があるでしょうから、英語で大丈夫だと思います。

僕は家事等あってちょっとオランダまでは行けそうにないですが、ちょうど個人的(←会社とは無関係のイベントです)にも野外での開発会を考えていて、明日第一回を行うところだったので、自然の中での開発会がどんな成果を作り出すのか、興味がありますね。

# こちらの開発会は、告知が遅くなってしまったのでまだ参加者が少ないです。明日木曜昼に東京で時間のある方はぜひ