ページ白化防止
ページ白化防止施策で毎日一行は書こうと思いました。
ぶっちゃけ、毎日書かなくても、
<MTEntries lastn="7">
って、index.htmlのテンプレートを修正しておけば、過去X日分ではなく、最新のXエントリ分となりますので、問題ないんじゃないかと(笑)
« 前のページ | 2ページ目/全4ページ | 次のページ »
1 2 3 4
ページ白化防止施策で毎日一行は書こうと思いました。
ぶっちゃけ、毎日書かなくても、
<MTEntries lastn="7">
って、index.htmlのテンプレートを修正しておけば、過去X日分ではなく、最新のXエントリ分となりますので、問題ないんじゃないかと(笑)
ああ、MT2.661が勝手にPINGしてくれるかどうかのテスト。→しないぽいぞ。ということですが、TrackBack AutoDiscoveryをonにすると、勝手にTrackBackPingをするらしいぞ。
「BLOGの設定→BLOGの設定」とか、そんなメニューのどこかにあってそれのon/offでそういう動きが違うらしい。よくわからずにonにしてたよ(笑)
この前、サーバーのトラブルが頻発していたときから、調子悪かったわけです。
奥さんに聞いてみたら、どうやら、「エントリの編集」の一覧には載ってこないエントリが含まれていて、ソレが悪さをしているらしい。「EntryのSearch」からいろいろ検索すると、不思議なエントリが多数発見される。コレが原因か!と、ぼこぼこDelete。そして、とりあえず、問題はなくなったらしい。
ありがと、奥さん。きみのおかげだ。
しかし、そもそも、なんでこんなことになるんだろう。たぶん、多数作られるBerkeley DB のファイルの一つだけが壊れたとか、巻き戻ったとか、そういう話なんじゃないかという気はするんだけど、そもそも、トラブル当時に更新してないぞ?という、気分。
なんにしても、巻き戻るのなら、きれいに巻き戻ってほしいので、ちゃんと、RDBMSなものにしたほうがいいのだろうか?SQLiteでもいいからやっておこうかなぁ。シリアライズのオーバーヘッドが無い分速いらしいし。
MySQLとか、Postgresで、MovavleTypeのバックエンドにするのはいいんだけど、データベースの管理者は、面倒だな。バックアップに責任持たないといけないし、バージョンアップの影響とか考えないといけないし……めんどくさそう……。
というわけで、SQLiteでやってみようかと、DBD::DQLite-1.07をインストールしてもらう。さんきうけんとさん。
で、自分のMovabletypeのディレクトリごと、別ディレクトリにコピーして、3.151にupgradeしたうえで、mt-db2sql.cgiを動かして、移行。ところが、日付まわりが、変。すごく変。
1400-79-66 30::なんて、表示になってしまってかなり謎。2005-03-08 13:43:58がそういうふうに変換されてしまっているらしい。RDBMSなので、ふにっとして、検索してみると、1400796630ちう形で登録されている。なんだ、こりゃ。
1970年起点の秒数かと思ったけど、それよりも、10年分くらい大きい。なんだろう……
で、新規に3.151で環境作ってみたんだけど、同じ。バグっぽいなぁ。でも、個人ライセンスは、サポート無し。なんだよな。ただ、「動かない」というのは、致命的だから、報告した方がいいんだけど、対応してくれるかどうかも、わからない……。どうしようかね
さすがに動かないってのはないんじゃないの?ってことで、ちょっと、google様にお伺いを立てて、ぐるぐるしてみた。
英語で検索したりしつつ、ぐるぐる。なんと、問題なく動かして移行している人がいる!
よく読むと、DBD::SQLite-1.0.8じゃないと、だめらしい。なるほど……。それはそうと、ちゃんとトランザクションを利用してなかったのね。MTって……。InsertのたびにCommitしてたのか……。まぁ、プログラムは楽だけど、それって、僕がRDBMSっぽいものをもとめて、Berkeley DBから移行しようとしている意味がないんじゃないだろうか?
あとは、NetBSDのpkgsrcのDBD::SQLiteが1.08になるのを待たないとダメだな……。いや、自分で自分ローカルにインストールしてもいいんだけど……。
解決のメドが立ったですよ>とがしさん
NetBSDのpkgsrcのDBD::SQLiteが1.08になるのを待たないとダメだな……。などと言っていたら、けんとさんが、あっという間にインストールしてくれた。さんきう。
というわけで、検証環境で移行手順を試してみたところ、懸案だった日付の問題は出ず、移行できた。
とはいえ、実際に移行するには、2.6から3.1へのアップグレードにともなう、いろんな問題が発生していて、そっちの解決をする必要があって、なかなか、めんどうだな。
というわけで、MT3.151-jaへのアップグレードと、SQLiteへの移行やっちゃいました。とりあえず、2.661からのアップグレードとSQLiteへの移行の手順は、
で、終了です。
おいらの場合には、mt-db2sql.cgiを実行したタイミングで、おかしなエラー(NULLが許されていないフィールドにNULLを入れようとしました)が発生しました。ちょっとしたプログラムを書いて、もとのdbの中をのぞいてみると、確かに、該当フィールドには値が入っていなかったので、そのエラーを回避する値を挿入するようにmt-db2sql.cgiを書き換えたりしましたけどね……。
あとは、3.1系のテンプレートへの変換作業とか、CSSも3.1標準にあわせる形に変更したりとか、したほうがいいんだろうなぁ……。
それから、考えてみれば、3.x系からのライセンスでは、1 Author + 3 Weblogが無償個人ライセンスで認められている範囲なので、「blogpet用の別Authorはライセンスの範囲内か?」という課題が大きく残ります。てか、それ、問題ないのか?
たぶん、MT3の限定個人ライセンス(無償)を利用して作成しているブログで、blogpetを利用する場合には、制約があるというのは、間違いないと思う。
問題あるのは、Blogpetに、別途AuthorIDを与えて、エントリ・コメントを書かせたりする場合ですかね。AuthorIDを与えなければ(書き込みさせなければ)問題ないでしょう。あるいは、Blogpetに、自分のIDを与えてしまう、というのも手ですかね。
要するにそういうことで、blogpetを別Authorとしてweblogに投稿させるのは、ライセンス違反ということだとおもう。
限定個人ライセンスは、無償で利用可能ですが、利用できるユーザー数(ウェブログ投稿者数)は1、ウェブログ数は3に制限されています。ウェブ構築業者が、本ライセンスを用いて顧客システム開発やインストール代行を行うことはできません。またサポートなど、有償ライセンス向けのサービスは、限定個人ライセンスでは利用できません。
ただ、別Authorにすることで、blogpet用のユーザーに割り当てる権限を少なくしておき、万が一そのユーザーとパスワードの組み合わせが漏れた場合にも、被害を最小限に食い止める。というリスクヘッジができるので、blogpetを使うのであれば別Authorにしたい。というのが、人情。
ぶっちゃけ、8400円出せば、5ユーザ(投稿者)のライセンスが買えるのだから、買ってしまってもいいんじゃないか?という気がする。ただ、なぁ、「そこをなんとかなりませんか?2.6の時はできていたんだから……」と、Sixapart.jpに頼み込むというのもありかなぁ……。どっちかっていうと、もう遅いだろうな。困ったね。
問い合わせてみた。
やはり、別Authorを作る場合には、「限定ライセンス」の範囲を逸脱しているので、個人向け通常ライセンスへの移行が必要らしい。
とりあえず、pet用のアカウントを削除し、blogpetが投稿しないように設定する。それでは、blogpetを設置する意味が半減してしまうが、やむを得まい。同じアカウントで投稿させる手もあるので、少し、考えることにしよう。
せめて、8400円が、4000円くらいで、かつ、将来のバージョンもずっと使えるライセンスなら、買うのになぁ。Becky!と同じだから。
ちなみに、現状のライセンスでは、8400円のライセンス料金に対して、
アップデートの定義
製品の「アップデート」は、現在のバージョンに対して小規模な機能の改良又はバグ修正を行うことを意味します。 アップデートのリリースは、バージョン番号の小数点以下の変更によって確認できます。例えば、X.1からX.2のように変更されると、アップデートされたことを意味します。「アップデート」又は「アップグレード」の何れかへの指定は、Six Apartが決定するものとします。
アップグレードの定義
「アップグレード」は、製品の大規模なリリースのことで、新機能やソフトウエアの主要な機能性を向上させる改良を取り入れることを意味します。 アップデートのリリースは、バージョン番号の小数点以上の変更によって確認できます。例えば、4.Xから5.Xのように変更されると、アップデートされたことを意味します。「アップデート」又は「アップグレード」の何れかへの指定は、Six Apartが決定するものとします。
と、なっていて、アップデートは無償、アップグレードは割引。らしい。微妙に高いような気がするな。やっぱ。Becky!は、4000円で1.xから2.xへも無償だったしなぁ……
いや、さらば。ってほどでもないのですけどね。使うのやめました。
これまで使っていたmt-bk1.plがbk1のリニューアルにより、動かなくなってしまっていたこと。その作者である河野さんがbk1を退職すること。また、氏がblogの中で、
最後に、updateを約束していたmt-bk1.plですが、XMLデータの取得方法について公開を検討してもらっています。すでに機能としては存在していて、bk1はてなや「簡単リンクくん」などはこの機能を使っていますから、いずれブリーダー向けに公開されると思います。
と、自分が作ったものであるのに、他人事のように書いていること。これらの理由から、mt-bk1.plを使うのがいやになったんだと思う。
同様のpluginはmt-isbn.plやaws.plなど、あったわけですが、使い方も簡単で、すごく楽だったので、mt-bk1.plを使ってました。新bk1への対応を待ち望んでいたのですが、なんともいえない気分です。
ただ、河野さんには、河野さんにしかわからないblogからは読み取れない苦労があったのだと思う。それは、非常にわかるような気がするし、だからこそ、こういうエントリになったのだと思う。河野さんを責めてもしょうがないしけれど、今まさに、これまで使っていたユーザーは私を含め困っているわけで……。まぁ、bibidで記述しているユーザーさんは問題なく使えているはずですが……。
しかし、同じように本文中にISBN:XXXXXXXXXXXXって書くだけで、書籍の画像つきの内容に変換してくれるものって、無いんですよね。というわけで、Net::Amazonモジュールを使って、画像のURLを取得してくれるものを作成しましたです。
ただ、mt-bk1.plを書き換えたモノなので、ソースがあまりにもそのまま過ぎて、公開できないなぁ。とか、思うのですが、公開しちゃいます。
Net::Amazonモジュールが必要なので、別途インストールする必要があります。自分でインストールできる、サーバーの管理者にインストールを依頼することができる、あるいは、こにしにサポートさせることができる。そういう技術のある人だけ使ってください。