btmup Blog

EC サイトを構築するために「MakeShop」という ASP を使用しているのですが、やっぱり普通にホスティングを借りてガシガシ作るのとは勝手が違います。
色々と分からなかったり詰まったり「あー、こういうことできないのね、残念」的な部分が出てきたので、とりあえず走り書きメモ。

あ、いろいろ書いてますが、批判とかではないですよ。
敢えて言うなら「要望」とか「ちょっとした意見」として捉えてもらえれば幸いです。
基本的には高機能なので、デザインとかサイト構造とか細かい部分にこだわらなければ全然問題ないと思います。
念のため。

では、いざ。

Continue reading

7/18（土）に開催された「CSS Nite in OSAKA, Vol.17 powered by KAGOYA Internet Routing」に参加してきました。
参加というか、まぁ勉強ですね。
非常に盛り沢山な内容で、色々吸収できましたよ。

これまではアップルストア心斎橋で無料セミナーを行ってきた「CSS Nite in OSAKA」。
今回は大阪産業創造館（産創館）に会場を移し、普段よりも数段大きな規模で有料版として行われました。
14 時半頃に開演し、4 つのセッションのあと休憩を挟んでさらに2 つのセッション。
終演は 19 時半ですから、計 5 時間という大ボリューム。
もうお腹いっぱいです。

Continue reading

えぇっと、色んなサイトを見ていて「あれ？　意外とみんな知らない？」と思ったことがあるので、サラッと書いておきます。
「んなことくらい知っとるわ！」という方は優しくスルーしてください。

一つ前の階層とルート

まずはおさらい。

HTML で一つ前の階層を指定するときは「../（ドット ドット スラッシュ）」と書きます。
例えば、

<a href="../index.html">一つ前の階層のトップページへ</a>

みたいな。

また、ルートのパスを指定するときは「/（スラッシュ）」のみを書きます。
例えば、

<a href="/index.html">トップページへ</a>

でトップページに戻れる訳です。

この2つは、どのサイトでもよく使われています。
特に前者は使わないワケにはいかないですからね。
（たまに全部を絶対パスで指定してるサイトもありますが）

同一階層

で、意外に使われていないのが「./（ドット スラッシュ）」。
これは、同一階層を指定する書き方です。
例えば、

<a href="./index.html">同一階層のトップページへ</a>

と書けば、同一階層のトップページへリンクできます。

しかし、このように書いているソースを見かけることは稀です。
その理由を考えてみると、恐らく最も大きいのは「書く必要がないから」。
つまり、

<a href="index.html">同一階層のトップページへ</a>

で問題なく動作します。
一つ前の階層を指定する場合（「../」）とは違い、「書かなくても良いんだから書かなくて良いじゃん」となってるんではないかと。

実際、僕も以前まではそうでした。

ただ、今となっては「書いたらいけない場合を除けば、書いた方が良い」という考えになっています。

「./（ドット スラッシュ）」を使おう！　の理由

僕の考えが変わった理由は、大きく二つ。

一つは、見た目に分かりやすいこと。
ソースをザーッと眺めていて、どこが同一階層でどこが別の階層か、ということを判別しやすくなります。
まぁこれは慣れとか気分的なものでしょうから、個人的なものかも知れません。

もう一つは、検索／置換がやりやすくなったこと。
これが個人的には非常にデカい！
DreamWeaver などのソフトを使っていれば気にすることではないのかも知れませんが、基本的にエディタで手打ちの僕にとって、検索／置換のしやすさは全体の作業効率に関わります。

例えば、「一つ下の階層にファイルをコピーして使う」場合、<a>タグのリンクから画像のリンクから js ファイルや css ファイルなんかのパスについても、（相対パスを使用していれば）一つずつ階層を追加してやる必要があります（「../」は「../../」に、等）。
こんなとき、同一階層の指定に「./」を使っていれば、一括で検索／置換できるので非常に楽なのですね。
もし「./」を使っていなかったら、「src=”」で検索したり「href=”」で検索したりしないといけなくなるワケです。
これはしんどい。だけでなく、ヌケやミスの原因にもなります。

注意点としては、「./」から「../」への置換は最後にすること。
「../」を「../../」にしようとしたとき、カブってしまうからです。
（もちろん「../../」がある場合は、そちらを先に「../../../」にしましょう）
（っていうかここまで深い階層を指定することがあんまりないか）

まとめ

サラッと書くつもりが結構長くなってしまいましたが、要するに、「./」って書いた方が実はハッピーになれるんじゃね？　ってことが言いたかっただけです。

もし「書かない方が良い理由」とかがあったら教えてください。

気が付いたら全然更新してなかったので、ここらで軽めの話題を一つ……。

»WordPress | 日本語 » WordPress 2.8.1 日本語版リリースのお知らせ

まぁ、それだけです。
わざわざここで紹介するまでもないことですが……。

何だか最近バージョンアップのスパンが短くなってる気がします。
元々こんなもんなんでしょうか。
2.9 も開発機能の優先順位に関するアンケートを実施してたりしてますし、今年中にもリリースされそうな勢いですよね。
（2.8 のときは、同じようなアンケート（08年12月）からリリースまで約半年でした）

個人的には、MU との統合（というか複数ブログの管理機能）をぜひ実現して欲しいところなんですけど。

データベースからコンテンツを取得するときに、その条件などを指定する「query_posts()」。
非常に便利、というか「使わないとやってられん」的な超定番関数です。

この query_posts()、一度指定した条件はその後のループでも引き継がれます。
それはそれで使いやすいときもあるのですが、「異なるカテゴリーの記事一覧を同一ページに表示」なんてときには逆に困ってしまいます。
ループごとに別の条件を指定しても上書きはしてくれないようで、最悪の場合、表示すらしてくれません。
（例えば、メインコンテンツ部分に新しくループを入れて query_posts() で条件を指定したら、その前まで表示できていたサイドバーのリストが消えてしまったりします ← 体験談）

そこで、ループごとに新しく条件を指定できるように、前のループで指定した条件をクリアする必要があります。
その方法は意外と単純で、以下の一文を追加するだけ。

<?php query_posts($query_string); ?>

この一文を、クリアしたいループの後、もしくは次のループの前（要するにループとループの間のどこか）に記述することで、query_posts() の条件をクリアすることができます。

「$query_string」とは、ページごとの標準の条件が入った変数ですので、クリアというより「デフォルトに戻す」という表現の方が正確かも知れません。

参考サイト

• 同じ記事が重複して表示される。query_posts の条件をクリアする方法 | 空が好きな人のメモ帳
• WordPressのツボ｜WordPress テンプレートタグ一覧
• 【BLOG】-creocordens-. - query_postsの条件をクリアするには？