もともと、金曜日の夜は、ジュニアチームの練習計画説明会だったので、猪苗代に行くことにはなっていたのですが、
金曜日の夕方、仕事を終わらせてから怒涛の準備。

タイヤ交換、ウェアー取りなどの準備を約1時間ほどで終了させて、猪苗代へ向かいました。

26日の箕輪は、なかなか良かったです。
練習は午前中だけでしたが、その間、ザケることもなく、各チーム、各選手、じっくりと基礎練習に取り組んでおりました。

早くC線が乗れるようになるといいんですけどね。
ただ、今週は、お天気的にはあまり期待できない感じではありますが。

27日からはデコも乗れるみたいです。

いよいよ、今シーズンも始動しました！

諸事情、諸問題を抱えつつシーズンインした福島県の選手たちですが、いろんな障害に負けずに、元気に練習しましょう！

一緒にがんばろー！！

実は、昨日、感想文その2を書いたあとで、ある事を思い出したのです。

『もしドラ』の漫画が出ていたはずだ！

漫画版は、昨日まで、全く読んだ事がありませんでした。

漫画化の話は、以前、何かの記事で読んで知っていたのですが、手に取って読む機会には恵まれず、現在に至っておりました。

思い出したら、なんだか、無性に読みたくなってきて、本屋さんへれっつらゴー、と相成りました。

ありました、これです！1冊だけ残ってました(^_^;)

続きを読む

（所有している本の挿絵をデジカメで撮影したものを掲載しています。）

前回の感想文から、早いものでもう4か月が経過しようとしています。
その間、ブログの更新は一切ないというテイタラクでしたが、本業が忙しかったので致し方ありません。どうかご勘弁ください。

それにしても、『もしドラ』は、読み込めば読み込むほど、新たな解釈とか、登場人物の気持ちの変化とか、いろんな見方が出来る物語です。
新たな発見（あら探しとは言わないでおきます）も出てきます。

前回、まとまらなかった部分はまた書きます、という、中途半端な予告みたいな事を書いたので、
またまた、読書感想文的なものを書いてみます。

貴重な時間を割いて、これを読んでくださってるかたは、一通り、『もしドラ』を読み終わった、という方だと思いますので、ネタバレ的なものを避けたい方は、『もしドラ』を全部読んでからお付き合いください。

続きを読む

感想文なので、あえてアマゾンへのリンクとか入れてません。(*^^)v

これから『もしドラ』を読もうとしている方は、つづきはネタバレ注意でお願いします。

続きを読む

まず、更新が滞った『言い訳』から。

降雪不足で、予定よりシーズンインが遅れてしまった2010年12月。
このころは、本業がどんどん忙しくなっていった時期で、早朝から現場に出ていましたので、PCに向かう時間がほとんど取れませんでした。
とにかく、本業以外に使える時間が限られてしまっていたので、それをすべてスキー場にいる時間に充てていた感じです。

続きを読む

政権交代後は、彼ら在日アメリカ軍のことを『邪魔者扱い』する日本人も多かったように思う。そういう流れにしてしまったのはもちろんトップに立つ人たちが悪い。

それなのに、日本人を救うべく、地震直後から、空母まで投入して、非常に強くて温かみのある、頼もしい活動をしている彼らには頭が下がる思いだ。

たしか、イラクの時にブッシュ大統領を全面支持した小泉さんは、何かあったとき頼りになるのはアメリカ軍だけ、といったようなことを言っていた。まさに、今、その時なんだと思う。

続きを読む

私も被災してしまいました。

地震以降不通になっていたADSLがやっと復旧しました。

ですので、今、思っていることを、今のうちに綴っておきたいと思います。

続きを読む

どんな状態になるのかというと・・・

続きを読む

続きを読む

Movable Typeのデフォルトだと、結果は20件まで同じページに表示されますが、21件目以降へのリンクが自動生成されません。
つまり、21件目以降の検索結果が分からない、ということになります。

この『検索結果をページ分割して出力する手順』を以下に書き残す次第。

なぜ思い立ったかと言うと、このブログの検索結果の表示がおかしい事に気が付いたから。
ふつう、自分のブログの記事を自分では検索しませんよね。だから、今まで気が付かなかったのですが、検索結果が複数ヒットした場合でも、最初の1件しか表示されない、という、なんともお粗末な感じになっていたのです。もしかしたら、ご迷惑をおかけしていたかもしれません。ごめんなさい。

特にカスタマイズしなくても、MTのデフォルトだと20件までは表示されるはず。おかしいなぁ、と思って、検索結果テンプレートをチェックしても、特に問題なし。で、よくよく考えてみると、検索テンプレート内に後述するmt:SearchMaxResultsを記述していなかったのでした。チャンチャン。

これでとりあえずすべての検索結果が表示されるようになったのですが、ついでなので、検索結果ページをカスタマイズしてみようかと。完全に行き当たりばったりの思い付きです。

毎度のことですが、すべて自己流なので、詳しい人が見たら無駄なタグとか、間違ったソースを書いているかも知れません。一応は自分の環境での正常動作は確認済みですが、それ以上のテストは行っておりませんので、あしからずご了承ください。
その辺を踏まえた上で、今回は、以下の設定でカスタマイズしていきたいと思います。

1. デフォルトの20件表示を解除して、1ページに5件の表示で出力する。
2. 5件以上の検索結果があるときには、ページを分割して出力する。
3. 分割された各ページへのリンクを出力する。
4. このリンクは、前後最大5件の表示とする。例えば、20ページ中7ページ目だったら、2から12のみ表示するように出力する。
5. 検索結果が1ページに収まるときは、このリンクを非表示にする。

といった感じです。

mt-config.cgiの編集

mt-config.cgiの結構下の方に、

# The maximum number of results to return in a search. If this is a straight
# search, the number of results is per-blog--if you set MaxResults to 5,
# for example, that would mean a maximum of 5 results for each blog in your
# system. In a new comment search, this is the maximum number of entries
# with new comments.
#
#MaxResults 5

というところがあるので、
#MaxResults 5
のコメントアウトを解除して、
MaxResults 5
にします。

mt:SearchMaxResultsの挿入

言い訳になりますが、前述したように、MTは不親切なので、mt-config.cgiを編集しただけでは検索結果に反映されません。
検索テンプレートに、

<input type="hidden" name="limit" value="<$mt:SearchMaxResults$>" />

を追加してください。

場所は、

<input type="hidden" name="IncludeBlogs" value="<$MTBlogID$>" />

の行の下あたりで。これでやっと1ページの表示件数が反映されます。

検索結果ページを分割して出力する

ページ分割するには、検索結果テンプレートを編集していきます。

直接、検索結果テンプレートに書き足してもいいのですが、あとあとの編集のために、このページ分割出力関係をモジュール化しておくことにします。

検索結果テンプレートの、MTSearchResultsタグを閉じたあたりに、

<$MTInclude module="検索結果ページ分割リンク"$>（仮称。モジュールの名前はお好きにどうぞ）

と記入して、新しいモジュールを作成します。

このモジュールに、必要なタグを書き込んでいきます。

以下に見本ソースを書きましたのでご参考に。
このソースでは、検索結果の総ページ数を出力し、ページが分割出力（今回の設定だと、6件以上ヒットした場合）された場合には、ページ数の数字に各々のページへのリンクが付きます。
そして、直接各ページへ飛ぶリンクの前後に、前後1ページへリンクする『前』というリンクと、『次』というリンクも表示させます。

<div class="content-nav">
    <MTPagerBlock>
        <MTIfCurrentPage>
            <MTVar name="__value__" setvar="page_next" value="5" op="+">
            <MTVar name="__value__" setvar="page_prev" value="5" op="-">
        </MTIfCurrentPage>
    </MTPagerBlock>

    <mt:IfPreviousResults>

<a href="<$mt:PreviousLink$>" rel="prev" onclick="return swapContent(-1);">&lt; 前</a>&nbsp;&nbsp;

    </mt:IfPreviousResults>

    <mt:PagerBlock>

        <mt:IfCurrentPage>

            <$mt:Var name="__value__"$>

        <mt:Else>

            <MTIf name="__value__" le="$page_next"><MTIf name="__value__" ge="$page_prev"><a href="<$mt:PagerLink$>"><$mt:Var name="__value__"$></a></MTIf></MTIf>

        </mt:IfCurrentPage>

    </mt:PagerBlock> 

    <mt:IfMoreResults> &nbsp;&nbsp; <a href="<$mt:NextLink$>" rel="next" onclick="return swapContent();">次 &gt;</a>

    </mt:IfMoreResults>

</div>

検索結果が1ページで収まる場合の調整

上記のソースでは、分割された最初のページで『前』、最後のページで『次』は表示されないようになるのですが、検索結果が1ページで収まる場合（今回の設定だとヒットしたのが5件以下）に、リンクが付かないページ番号『1』が表示されてしまいます。

『検索結果は1ページしかありませんよ』というメッセージだと理解してもいいのですが、結果が1ページで収まるのであれば、この『1』は必要ないような気がします。
お好みになってしまいますが、この『1』を消すために、mt:unlessタグを使用して、結果が1ページの時には、リンクを出力しないようにします。
mt:unlessを反映させたソースがこちらです。

<div class="content-nav">

    <MTPagerBlock>

<mt:getVar name="__value__" setvar="result_number" />

        <MTIfCurrentPage>

            <MTVar name="__value__" setvar="page_next" value="5" op="+">

            <MTVar name="__value__" setvar="page_prev" value="5" op="-">

        </MTIfCurrentPage>

    </MTPagerBlock>

<mt:unless name="result_number" eq="1">

    <mt:IfPreviousResults>

<a href="<$mt:PreviousLink$>" rel="prev" onclick="return swapContent(-1);">&lt; 前</a>&nbsp;&nbsp;

    </mt:IfPreviousResults>

    <mt:PagerBlock>

        <mt:IfCurrentPage>

            <$mt:Var name="__value__"$>

        <mt:Else>

            <MTIf name="__value__" le="$page_next"><MTIf name="__value__" ge="$page_prev"><a href="<$mt:PagerLink$>"><$mt:Var name="__value__"$></a></MTIf></MTIf>

        </mt:IfCurrentPage>

        <mt:Unless name="__last__">&nbsp;</mt:Unless>

    </mt:PagerBlock> 

    <mt:IfMoreResults> &nbsp;&nbsp; <a href="<$mt:NextLink$>" rel="next" onclick="return swapContent();">次 &gt;</a>

    </mt:IfMoreResults>

</mt:unless>

</div>

一応、このソースが今回設定したカスタマイズの完成形ということになります。

あとは、細かい調整をお好みでカスタマイズすれば完了ですね。
例えば、数字を少し大きく表示させたければテキストサイズを変更してみるとか、センタリングしたければcenterタグなどで整えるとかすればよろしいのかと。

主要な記事は、『KIEMO.blog』へ移植されました。

再構築に伴いまして、サーバー内を整理したいので、過去ログ倉庫を閉鎖する方向で考えています。

このブログに移植されていない記事は、ここ数年、ほぼ全くと言っていいほど訪問者がいない記事です。
ですので、削除してもさほど問題はないだろう、という判断です。

過去ログ倉庫閉鎖日時　：　2010年9月1日（水）　04：00　（予定）

上記日時をもちまして、このブログ、日本キーモWeb以外の過去記事と、旧ブログ時代の過去ログ倉庫を削除しますので、ここにお知らせしておきます。

2010/09/01　予定通り、過去記事倉庫は閉鎖されました。

お問い合わせはメールフォームからどうぞ。

────────────────────────────────────
□■豪華賞品が合計1,000名様に当たる！　　　　
　　　　　　　　　「サントリー 水のなるほどクイズ 2010」はじまる！□■
────────────────────────────────────
サントリーの環境や品質への取り組みに関するクイズを解いて応募すると、
抽選で合計1,000名様に「ザ・プレミアム・モルツ」「サントリー天然水」など
素敵な賞品をプレゼント。

▼ご応募はこちらから

　【第1回締切】7月25日（日）
　　　※第2回締切：8月22日（日）　最終締切：9月12日（日）
　　　※お一人様につき、各回1回ずつご応募できます。

また、ブログをお持ちの方には「金麦」または「ＤＡＫＡＲＡ」が当たる、
Wチャンスもありますよ。

皆様のご応募をお待ちしております！、とのことです。

続きを読む

トクー！トラベル

今一度、西村社長の心意気をおさらいしてみたいと思います。

その前に、この記事は、クーコム株式会社Webページより引用させて頂いた部分が多数ありますので、あらかじめ明記しておきます。

ご存知の方もいらっしゃるかと思いますが、トクー！トラベルの出発点は、「空いている部屋を利用して安価な旅を提供したい」という想いをその名に表した「あき宿倶楽部」にあります。

「どうして一泊二食しかないの？」
「平日はガラガラなのに何故こんなに高い料金設定なの？」
「旅行代理店の手数料が高すぎるのでは?」
「何故パッケージ旅行は安く個人旅行は高いの？」
旅行をするたびに、いつもこのような思いを抱いていました。
ユーザーを無視し、業者間だけですべてを決めてしまうような、古く歪な業界の体質を、何故誰も変えようとしないのだろうか。

【クーコム株式会社のWebページより引用】

サークル的なものでもいいから、自由に自分の好きな旅行を楽しめるサービスをやってみたい、と、まさに一ユーザーの視点でスタートしたのが「あき宿倶楽部」でした。

西村社長の挑戦は、パソコン１台に電話１台、10万円ほどの資金を元に、自宅マンションの一室からはじまりました。
当初は、旅行業の経験もないままにスタートしたため、宿と何を交渉するべきかわからず、専門用語も全く理解できず、大変苦労されたそうです。

創業当初から多くの困難はありましたが、「新たな旅を創造する」という強い想いのもと、「会費制での仕入れ値販売＋直前予約＋泊食分離」という旧来の旅行業界に無いビジネスモデルで、業界のしがらみに左右されず、常にユーザーの目線で物事の是非を判断し正しいと思えることのみを追求し続けてきました。その結果、テレビをはじめラジオ・新聞・雑誌など多くのマスコミに取り上げていただき、旅行者様・お宿様にもご支持を頂き、順調に業績を伸ばすことができました。

【クーコム株式会社のWebページより引用】

その後、空き部屋だけにとどまらず、パッケージツアーやレンタカー・国内高級ホテル旅館・ビジネスホテル・海外ホテル・オプショナルツアーなど様々な商材を追加して、名称通り旅行全体をお得に利用できるサービスへと拡大していったそうです。

ユーザーを無視した旅行代理店及び宿の業界慣習を、ユーザー側の意見が反映されたユーザー本位なものへと改善するために、旧来の旅行代理店のような高額なコミッション制ではなく一定安価なユーザー会費制を採用し、航空会社では当たり前なのに、宿の業界では全く行なわれていなかった直前販売などの新たな販売手法を取り入れて宿側の収益を上げると共に、ユーザーの直前安価な旅行を実現できるサービスを提供しています。

また、「１泊２食」は、日本では当たり前、というか基本なんですが、実は、世界的にみると日本にしかない歪な仕組みなんだそうです。
これを、「泊」と「食」に分離し、明朗な料金体系にしたそうです。
この挑戦は、宿だけではなく、レンタカーやパッケージツアーの仕入れ値販売・海外ホテル・オプショナルツアーにおいても、旧来にない販売手法により、様々なことにチャレンジして来たそうです。

今までにないこの新たな試みは、多くのユーザーの支持を受け、成功を収めます。

これに対して業界の反応は、決してよいものではなかったそうです。

業界関係者からは、「ユーザー様から会費を頂いて運営する仕組みなどうまくいくはずがない」と言われたそうです。

宿からは、「直前割引は早い時期に買っていただいたお客様に申し訳が立たない」「値崩れを起こす」「安売りはしたくない」「泊食分離をしたら誰も食事を取らなくなる」「旅行代理店からのクレームが怖い」などの声が聞かれました。しかし、その全てが、お客様を無視し、マーケティングを旅行代理店に一任した結果ゆえの意見なのです。

「直前割引は、、、」
⇒どの業界でも不良在庫を少なくし、イールドを上げる施策を当たり前に行なっております。

「値崩れ、、、」「安売りは、、、」
⇒旅行代理店に一任していることが一番の値崩れであり収益悪化の原因なのに・・・。

「泊食分離、、、」
⇒誰も取らない食事を押し付けることがユーザー離れの要因なのでは・・・？

全くもってお客様のほうを見ていない発言なのです。
成功している有名な経営者でも、「直前で2割引き・・・2割の利益も出ていないのに、そんなことをしたら潰れるよ」といいます。全室2割引で売ったらそのとおりですね。 代表的な言い訳ですが、マーケティングのことを理解していない証拠なのです。

それもこれも旅行代理店による「集客は代理店、運営は宿」という施策の影響が長い間続いたからなのです。その結果、宿は独自のマーケティングを忘れ、お客様の意見を聞かず、営業といえば"旅行代理店詣で"となってしまったのです。

確かに、バスで連日何十台も押し寄せた時代を体験し、個人のお客様にシフトできないシステムになっているのは否めません。
しかし、どれだけ時間がたっても時代に対応したシステムに移行できないのは、日本の旅行業界全体にとっても大きな損失なのです。
さらに、旅行代理店の横並びのサービス発想から、どこでも同じツアーが売られているのも業界全体が発展しない理由です。

例えば、Ａ社が発売したパッケージツアーが人気になると、即他社が一斉に真似をし、さらに安価な価格で販売する。
その結果、価格競争だけが残り、ユーザーにしてみれば、中身不在のまま、この商品は19,800円なのか18,800円なのかという違いだけを
見せられていることになります。
宿泊施設は、お客様は大量に来るが全く利益が出ないところまでディスカウントをすることになり、そのうち地域まで飽きられ、人が離れ、ついに経営破たんに追い込まれる・・・。
通常の片道航空料金くらいで行けてしまうこの「エアー往復＋ホテル＋観光」というあり方は、これまた日本特有の観光資源を無視した
価格競争のみの一時的大量送客パッケージ旅行なのです。

大量送客ができていた高度成長期の日本であればまだしも、消費者の行動が変わり、個人旅行が主体となった現在でも、宿側のエージェント依存が変わらないということが、観光業界低迷の大きな要因なのです。

【クーコム株式会社のWebページより引用】

そして、私がすごいなと思ったのが、ユーザー向けであるはずのWebページ内で、加盟宿泊施設を募集していることです。

そして、そこには、こう書かれています。

宿の経営者としてではなく旅行者の立場に立ってお考え下さい。

少し気になってきたあなた、ちょっとクーコム株式会社のWebページをのぞいてみませんか？
こちらからどうぞ。
クーコム株式会社　http://www.tocoo.jp/

続きを読む

JavaScriptのお勉強が今一つなものですから、作ろう作ろうと思ってずーっと放置してあった作りかけのツールがありました。

それが、このペナルティーポイント計算ツールです。

計算が結構ややこしいというか、式がとっても長くなってしまうので、面倒になって途中でやめてそのままになっていたんですね。

久々に存在を思い出し、残りの部分を作ってみた、という訳です。

何とか形になったので、ポイント解説のページからポップアップするように上げておきました。ペナルティーポイントの説明の後にリンクがあります。

レースポイントにこのペナルティーポイントを足した数字がリストの基準になりますので、ややこしい計算式ではありますけど、一応、理解していた方が何かと良いと思います。

とりあえず、お知らせまで。

この時、エントリーが多くなってくると再構築時に500エラーが出てしまう事があります。

そしてこの現象の原因として下記が考えられます。

1. サーバのパフォーマンス低下
2. サーバのメモリ量不足

大多数の個人ユーザーはレンタルサーバー会社のホスティングサービスを利用しているかと思います。
一つのサーバーを結構な人数でシェアしているわけです。
で、この複数名で共有しているレンタルサーバでは、CPU やメモリ等の事実上のスペックがマシンを占有する人数や使用頻度に反比例して低下していきます。

そのために、サーバーが混んでいるときには再構築の成功率が低下してしまうのです。

この現象を少しでも回避するために、mt-config.cgiの内容を書き換えるのが結構有効な手段です。

mt-config.cgiをエディターで開くと、

# When rebuilding individual archives, Movable Type splits up the rebuilding

# process into segments, where each segment consists of rebuilding N entries.

# The default value for N is 40, so by default, MT will rebuild 40 entries at

# a time, then move on to the next 40, etc. You can change that value globally

# here; for example, if you have a very stable server, you might wish to just

# get it all done with in one batch.

#

# EntriesPerRebuild 40

というところがあります。

どういう事を言っているのかというと、

個々のアーカイブを再構築するとき、Movable Typeはセグメントごとに再構築プロセスを分けます。

このとき、各々のセグメントはN値でエントリを再構築することから成り立っています。

Nのデフォルト値は40なので、デフォルトで、MTはまず最初に40のエントリを再構築し、そして次の40エントリ、さらに次、というプロセスを取ります。

ここの設定でグローバルにN値を変えることができます。

たとえば、非常に安定したサーバーで運営しているのであれば、すべてのエントリを1つのバッチで再構築することもできます。

といった感じの意味の事が書いてあるのです。

つまり、デフォルトではいっぺんに40エントリーずつ再構築する仕様になっているのですが、これではサーバーの負担が大きいために実行できず、500エラーを返されてしまう、という訳です。

これを、10なり、15なり、自分の環境でエラーが出ない値まで下げてやると、結構な確率で500エラーは出なくなります。

上記の

#EntriesPerRebuild 40

のところを

EntriesPerRebuild 10

くらいの値にしてあげるとよいのではないかと。もちろん、20辺りで一度試してみてもいいでしょう。

それにしても、『たとえば、あなたが強力なサーバーを持っているなら、N値を増やしたいと思うでしょう』って言うのは少々・・・な感じもします。

もちろん、これ以外の原因もありますので、絶対500エラーが出なくなる、という訳ではありませんけど、この『N値設定』一度お試しください。