再構築時に「500 Internal Server Error」
再構築するとエラーになってしまう
December 27, 2005
Category: トラブルシューティング
Tags: Troubleshooting BerkeleyDB SQLite Database MovableType
大変なことになりました
わたしのMovableType(ムーバブルタイプ)…新規エントリを作成しても保存されなくなってしまいました。
しかも、サイトの再構築さえできない状態で、何が行ったのか分かりません。もう放心状態です
わたし…かなり環境をいじくりまわしました。
とりあえず、気を取り直してさっそく調査した結果、やっと原因が分かりましたぁ
原因
原因はデータベースにあったようです。
こちらの過去ログに同じ現象でトラブってる人がいました。わたしのカスタマイズで、余計なことやってしまったのかと思ってドキ×2でしたが、わたしが悪いわけではなかったようです
MovableType(ムーバブルタイプ)のデフォルトでは、バークレーDBというデータベースが使われるそうですが、このデータベースがくせ者らしく、エントリ数が増えると再構築時にサーバーに負荷がかかってしまい、サーバー側からエラーが出るとのことです。
エラーメッセージは、再構築時に「500 Internal Server Error」というメッセージがでたら、おそらくわたしと同じ原因だと思われます。
たかが、40弱のエントリくらいでパンクしないで欲しいです
対策1 - これからMovableType(ムーバブルタイプ)をインストールする人
これからMovableType(ムーバブルタイプ)をインストールする人は、MovableType3.2をSQLite対応でインストールするで説明していますので、参考にしてください。そうすれば、わたしみたいなトラブルを回避できます
データベースをインストール時からSQLiteを使用する為の手順を記載しています。
対策2 - 既にインストール済のわたしと同じ現象の人
この人( わたしも含む )は、現状のデータベース、バークレーDBからSQLiteに変換する必要があります。
変換方法は、腐女子のMovableTypeカスタマイズ感想文様を参考にさせていただきました。
ここでは、http://lala.com/mt の下にMovableType(ムーバブルタイプ)を構築したとして説明します。自分の環境に合わせて、適宜読み替えてください。
mt-config.cgiを開き、63、64行目のコメント「#」を外します。
以下のように変更します。
変更前
# ObjectDriver DBI::sqlite
# Database /path/to/sqlite/database/file
変更後
ObjectDriver DBI::sqlite
Database ./db/mtdb
次に、75行目にコメント「#」がついている人は外してください。
コメントを外さないと変換されないようです。
変更前
# DataSource /home/sites/lolipop.jp/users/lolipop.jp-cololipo7/web/mt/db
変更後
DataSource /home/sites/lolipop.jp/users/lolipop.jp-cololipo7/web/mt/db
保存した mt-config.cgi をサーバーにアップロードします。
アップロード後、mt/mt-db2sql.cgi をブラウザ上から起動すると、ファイルの変換が始まります。
最後に、
「Done copying data from Berkeley DB to SQL database! All went well.」
が表示されれば、変換成功です。
再度、mt-config.cgiを開いて75行目をコメント「#」して、サーバーにアップロードします。
変更前
DataSource /home/sites/lolipop.jp/users/lolipop.jp-cololipo7/web/mt/db
変更後
# DataSource /home/sites/lolipop.jp/users/lolipop.jp-cololipo7/web/mt/db
最後に mt.cgi をブラウザ上から起動して、変換されたことを確認してください。
変換されていば、エントリ数が以前の数になっているはずです。
エントリ数が元に戻っていない場合、各CGIファイルを700 ⇒ 755にして再度、mt/mt-db2sql.cgi を実行してみてください。
わたしの場合は、700では変換されませんでした。
エラーの原因を知る方法
mt-config.cgi の402行目に SafeMode という行のコメントを外して、以下のように変更した後、再構築することによりエラー内容が分かるようになるそうです。
変更前
# SafeMode 0
変更後
SafeMode 1
１度に再構築するエントリ数を変える方法
mt-config.cgi の228行目に EntriesPerRebuild という行があります。これを以下のように変更することにより、1度に再構築するエントリ数を変更することができます。
エントリ数を40 ⇒ 10に変更する場合、
変更前
# EntriesPerRebuild 40
変更後
EntriesPerRebuild 10
世の中、いろ×2詳しい人がいてホント助かりましたぁ
※こちらから環境設定ファイル( mt-config.cgi )についてのマニュアルを見ることができます。
SEE YOU
日付・時刻表示のformat属性 多言語式
言語別の日付フォーマットは、次のとおりです。
language="cz"
日付を、チェコ語の形式で表示します。（例: 23. Květen 2006 11:44）
language="dk"
日付を、デンマーク語の形式で表示します。（例: 23.05.2006 11:44）
language="nl"
日付を、オランダ語の形式で表示します。（例: 23 mei 2006 11:44）
language="en"
日付を、英語の形式で表示します。（例: May 23, 2006 11:44 AM）
language="fr"
日付を、フランス語の形式で表示します。（例: mai 23, 2006 11:44 AM）
language="de"
日付を、ドイツ語の形式で表示します。（例: 23.05.06 11:44）
language="is"
日付を、アイスランド語の形式で表示します。（例: 23.05.06 11:44）
language="ja"
日付を、日本語の形式で表示します。（例: 2006年05月23日 11:44）
language="it"
日付を、イタリア語の形式で表示します。（例: 23.05.06 11:44）
language="no"
日付を、ノルウェー語の形式で表示します。（例: Mai 23, 2006 11:44 FM）
language="pl"
日付を、ポーランド語の形式で表示します。（例: 23 maja 2006 11:44）
language="pt"
日付を、ポルトガル語の形式で表示します。（例: maio 23, 2006 11:44 AM）
language="si"
日付を、スロベニア語の形式で表示します。（例: 23.05.06 11:44）
language="es"
日付を、スペイン語の形式で表示します。（例: Mayo 23, 2006 11:44 AM）
language="fi"
日付を、フィンランド語の形式で表示します。（例: 23.05.06 11:44）
language="se"
日付を、スウェーデン語の形式で表示します。（例: maj 23, 2006 11:44 FM）
日付・時刻表示のformat属性 表現
<$MTEntryDate format="○○○"$>
○○○の部分は例えば
<$MTEntryDate format="%Y.%B.%d %k:%M"$>
*年月日*
%Y - 年の４桁表示。ex：2001
%y - 年の２桁表示。ex：01
%B - 月の完全表示。ex：September
%b - 月の省略形。ex：Sep
%m - 月の２桁表示。ex：09
%d - 日の２桁表示。ex：09
%e - 日の１桁表示。ex：9
*曜日・時刻*
%A - 曜日の完全表示。ex：Thursday
%a - 曜日の省略形。ex：Thu
%H - 時（２４時間対応）。ex：09
%k - 時（ 〃 ）１桁の場合はスペースが入る。ex： 9
%I - 時（１２時間対応）。ex：04
%l - 時（ 〃 ）１桁の場合はスペースが入る。ex： 4
%M - 分の２桁表示。ex：02
%S - 秒の２桁表示。ex：04
%p - AMまたはPM。
*その他*
%j - 通算日数を表す3桁の数字。ex：138
%x - 各言語の一般的な日付表記。ex：September 6, 2002
%X - 各言語の一般的な時刻表記。ex：4：31 PM
月や曜日、午前・午後の表記を各言語で表示する場合は、language属性で指定できます。
<$MTDate format="%A" language="jp"$>
とすると、「火曜日」と表示されます。
日付表示は和風に変更できるプラグインなどが配布されているので、そのうち試してみたいなと思います。
ゼロストラテジーの実際
こんにちわ。
夜な夜な書かせていただいております。
今日は、掲題のカテゴリを新たに新設いたしましたのでお知らせいたします。
ゼロストラテジーを始めてもう3年近くなるでしょうか。
そろそろノウハウをこちらに掲載して行きたいと思っております。
どのあたりからどういう処までを書くかはまだこれから決めて行こうと考えておりますが、
実際にどうやって営業をしていくかだとか、人脈を作っていくか、経理や行政書士との付き合い方など
細かい分野から、マインドの維持方法等を中心に掲載していこうと考えております。
私は果敢な挑戦が大好きです。
どんなにハードルが高くても、熱意と確信を持って大きな物に挑む姿は、
起業や創業でなくても感動的なことです。
果敢な挑戦は、感動的です。
ですが、一方で非常に落胆することもあります。
また、どんなにハードルが高いと、現時点では思えても、
確立を積み上げていくことで解消できます。
サラリーマンとファウンダーの大きな違いは、会社の土台から作らねばならないということです。
この土台をしっかりしたものにしなければ、大きなハードルは越えられないばかりか、小さなハードルでさえ躓き、
その日常は、ご自身のモチベーションやマインド、さらには人格まで蝕んでしまうことになります。
人間は、環境によって大きく変化します。
もちろん根本的な性格などは変わりませんが、いわゆる習慣が変わります。
次回から新しくノウハウを書いていきたいと思いますが、
ご要望やリクエストなどがありましたら、
コメントやメールでご連絡頂ければと思っております。
よろしくお願いいたします。
ダブルバーレル
この調査票の作成は意外と難しいものです。
掲題の言葉は1つの質問に対して2つ以上の質問や論点を含む質問のことです。
コレがあってはなぜダメなのか？
デザインについての評価を得たいのに、質問できる設問数を節約したいためにこんな質問票を作成した場合は、
正確な意図が汲み取れない。
Q あなたは●●という携帯電話をお持ちですが、そのデザインや機能に満足していますか？
・非常に満足している
・まあまあ満足している
・どちらともいえない
・やや不満
・非常に不満
これは完全にNG。
なぜなら、回答する側は、デザインについて回答すればよいのか機能に関して回答すればよいのか分からない。
結果、適当な回答をせざるを得ない。
また、この結果を受け取った側は、1つの設問で、デザインと機能の両方について聞いているので、
調査結果をどのように判断すればよいのかわからない。
不毛な設問以外の何物でもない。
なら正確にするならどうすればよいか？
分けるならば以下の2通り。
１、設問自体をデザインと機能の2つに分ける
2、マトリクス形式で聞く
１は言葉の通り。デザインを先ず聞き、機能に関しても同じ質問をする。
2は表形式で聞くということ。具体的には以下。
あなたは、●●という携帯電話をお持ちですが、そのデザインや機能について満足していますか？（SA：単一回答）
デザイン 機能
・非常に満足している ○ ○
・まあまあ満足している ○ ○
・どちらでもない ○ ○
・あまり満足していない ○ ○
・非常に不満 ○ ○
のような形だ。
調査票の作り方によっては、全く科学的な裏づけがない調査票になってしまう場合がある。
ぜひ、慎重になって作成をしたいもの。
人類3番目の革命と時代の移行
人類の革命の中で、大きな革命として３つある。
IT革命（情報革命）はその3番目に該当するといわれている。
まず、1000年をかけて農業革命。
そして、100年をかけて、産業革命。
情報革命は10年ほど。
今、国内ではITバブルと呼ばれる時期は過ぎ去ってしまった。
ビジネス上ではとても面白い時期だったが、それも去ってしまった。
今後、ITバブル以前のような時代に戻ってしまうだろう。
中々手に入れることが難しい、コミュニケーション能力や人脈などを持ちえた人々の時代になってくるだろう。
しかし、これは非常に面白くないこと。
これらを持ち得ない人々は、活躍にくくなった事を意味する。
経済を活性化させるには、「喚起」が必要だ。
喚起をさせるために、政府は貨幣の刷新をしたりする事を基本に経済市場に変化を加える。
2000円札などは結果失敗に終わったが、その施策の一環であった。
もちろん、IT革命のような喚起が常時起こっていたのでは、企業インフラが安定しないし、
個人的にもそれについていくだけのパワーが必要なので、たまったものではない。
中規模、小規模の喚起が常に必要なのだと思っている。
最近は、世界的な兆候として不景気だそうだ。
それは、従来のマーケティング手法が通用せず、プロシューマーのような手法を用い、
コンシューマーを巻き込んだマーケティング戦略をしなければいけない状況下にあることとを考えれば、
非常に良く分かる。
ユーザーがマーケティング戦略になれてしまった。
これである。
よく考えれば、政令都市などはマーケティングの主戦場である。
しかし、ここではマーケティング施策を構築している人々の生息地でもある。
また、オークションなどによって商売なれしてしまったユーザーでは、消費者がマーケティングを行っているなどの逆転現象が起こっている。
政令都市では、施策を練っている側、または関連してる側に対して消費行動を喚起させねばいけない場所なのである。
関連していることが多いことは、当然ながら慣れが広がれば、消費行動は鈍化する。
これまで、ターゲティングを中心とするマーケティングが行われてきたが、
恐らく、本来の形はそうではないだと感じる。
視点が変わるが、会社の存在価値は売上を上げることと、社会貢献であるといわれる。
この社会貢献に比重が置かれてきているのだと捉えていくべきなのだろうと思う。
電通をはじめとするマーケティング会社は、近年CGMというコンセプトの子会社を次々に立ち上げている。
これらは、これらの社会背景を大きく反映していることなのだと思われる。
インサイト
インサイト（ｉｎｓｉｇｈｔ）は直訳すると「洞察」。
コンシューマー・インサイトとも言われています。
インサイトとは「なんとなく行われている生活者の判断や行動、嗜好の核になる心理」のことです。
消費者の内心を探るために新しい調査方法がどんどん登場してきています。しかし有効的な調査方法は時代が変わるにつれて失われていきました。消費者行動から内心を読み取れる力が重要になってきています。
ドミナント政策
チェーン展開を行う際の、出店施策の1つ。
ドミナント出店、エリア・ドミナンス戦略とも言う。時に出店そのものを指すことがある。
dominant の元来の意味は優位・支配。
例えば、都二県等の限定した地域を対象とし、
集中的な出店や特定路線沿いに次々と出店し、
同一商圏内の競業他社や競合他店に比べて市場シェア率の向上獲得や独占を意図した出店戦略や出店計画を言う。
ファインディングス
どうやら、どのビジネス用語集にもないようだ。
だが、論文や、調査レポート、事業概要書に はこれらがそれとなく載っている。
「発見」
そのまんまだが、これをファインディングス、またはファインディングと呼ぶらしい。
また、ファクト・ファインディングスなどと、複合的に用いられる場合も多い。