Firefox 5がリリースされましたね。
ただ、確認環境やアドオンの都合でバージョンアップ出来ないことも。。。
かくいうわたしも上記理由で、現在、複数バージョン共存という方法をとっています。
Firefoxの複数バージョンを共存させる方法ですが、すでにエントリーが各所で公開されています。
ので、説明はここではしません！
私はいつも小粋空間さんの「Firefox3とFirefox4の共存」を参照させていただいています。
他には以下などが参考になるかと思います。
Firefox3.5登場に備えて複数バージョン共存方法をおさらい
Win XP／Vista環境の方は、上記手順に沿えばOKかと思います。
Win 7では、小さな違いが1点。
冒頭で一度、Firefoxのプロファイルのバックアップをとるのですが、公開されているエントリーでは、Win XP／Vista環境のことが多いようなのです。
Win 7ではXP／Vistaとはプロファイル・フォルダの構成が異なっているため、記述場所に辿り着きません。。
（というのをいつも忘れてググっています。。。）
Win 7での格納場所は以下です。
C:\Users\ユーザー名\AppData\Roaming\Mozilla\Firefox\Profiles\
この場所が分かればあとは手順どおり。
無事、Firefox 5も我が手中に…！
以上、メモでしたー。
（ただ、そもそも、6週間おきに新バージョンとかなので、今後複数バージョン共存はキツイですね…ｺﾞﾆｮｺﾞﾆｮ）
参考：XP／Vista→Windows 7 完全移行マニュアル － ＠IT
jQueryで、”this”の親要素、子要素（子孫要素）を指定する記述方法のメモ、リライト版です。
（元々はこちら）
親要素
thisの親要素を取得
$(this).parent()
“親要素を全て返す
“記述です。
近いものとして、”ルートを除く先祖要素を全て返す
“parents()や、”開始要素から最も近い親要素を選択
“するclosest()もあります。
参：
parent([expr]) – jQuery 日本語リファレンス
parents([expr]) – jQuery 日本語リファレンス
closest([expr]) – jQuery 日本語リファレンス
jQueryで親要素のスタイル変更 : JSをつらつらとダラダラと書く
子要素・子孫要素
thisの子要素、もしくは子孫要素（ここでは<ul>）を取得
子要素
$(this).children("ul")
子孫要素
$(this).find("ul")
$("ul",this)
$(this).children("ul")
“直下にある子要素のみ
“を選択。”孫要素以下は対象外
“となります。
「”ul”」部分は絞り込みの条件式なので、この場合選択したい「ul」以外に子要素がなければ記述しなくても問題ないと思います。
参：children([expr]) – jQuery 日本語リファレンス
$(this).find("ul")
thisが持つ”全子孫要素から、指定条件式に合致するものを選択
“します。
直下の子要素だけでなく、子孫要素から条件（”ul”）に合うものを探すということですね。
参：find(expr) – jQuery 日本語リファレンス
$("ul",this)
公式の説明によると、”selector context is implemented with the .find() method, so $(‘span’, this) is equivalent to $(this).find(‘span’).
“とのことですので、行っている処理内容は、上のfind()と同じようです。
なので、子孫要素から条件に合うものを探すという処理になります。
参：jQuery(expression, context) – jQuery 日本語リファレンス
サンプル
自分のメモ用ですが、簡単なサンプルを書いたので載せておきます。
動作サンプル
また前エントリーのコメントにてmattari_pandaさんがつくってくださった計測用のサンプルもこちらにも載せておきます。（mattari_pandaさんご快諾ありがとうございます！）
速度測定サンプル
サンプルを見ていただければ、mattari_pandaさんのコメント内容にある、以下の点がわかるかと思います。
- “
$(‘ul’, this)はjQueryの中でfind()に展開しているようなので、今回のような場合はfindを使ったほうが若干ですがパフォーマンス的に良い
“
- “
$(this)を一回の処理の中で繰り返す場合はあらかじめ変数に入れておくと、処理の速度も速く
“なる
ご参考までに。
他参考URL：
jQueryでthisの子要素を取得するやり方いろいろ | Base Views
Thanks☆：
mattari_pandaさん、initiumさん、kzさん、understandardさん
以下おまけ
$("#dummy").css
上記のような記述は、”"以降、つまり範囲指定を省略しているようですね。
ドキュメント内から#dummyを探す、と。（jQuery 日本語リファレンスのサンプル3参照）
また、パッと見、似ていて私も誤解していたのですが、まったく違うので注意！
$("ul",this)
$("ul,this").css
後者は複数のセレクタを指定する記述です。
参：selector1, selector2, …, selectorN – jQuery 日本語リファレンス
最後に。
前エントリーよりは、リファレンス等を確認して載せてはおりますが、必ずしも上記の内容が正しいとは限りません。
不具合等の責任は負いかねますので、その点だけご留意いただければと思います。
私と同じようなjQuery初心者の方の参考になれば幸いです！
jQueryでよくつかう”this”の親要素や子要素を指定する記述をすぐに忘れてしまうので、メモ。
/* 110605 */
リライト版エントリーをアップしました。
そちらのほうがまだ見やすいと思いますので、、ご参照いただければ！
/* 110522 */
「$(“ul”,this).css」についてコメントにてご指摘いただきました！
エントリー内で、これは「間違い」と記述しておりますが、子孫要素を取得できる正しい書き方でした。
詳細についてはお手数ですが、コメント欄をご覧ください。
近々、コメントでいただいた内容も含めて、一度リライトしたエントリーを書こうと思っております。
/* 110131 */
子要素指定方法についての記述で、間違いをご指摘いただいたので、訂正しました。
親要素
thisの親要素を取得する。
$(this).parent().css
参：jQueryで親要素のスタイル変更 : JSをつらつらとダラダラと書く
parentのカッコを忘れてて、子一時間悩むとかもう止めたい…
子要素
thisの子要素（ここでは<ul>）を取得する。
$(this).children("ul")
$(“ul”,this).css
→これ、間違い（補足は後述）
$(this).find(“ul”)
→これも、間違い（補足は後述）
参：jQueryでthisの子要素を取得するやり方いろいろ | Base Views
※なぜ間違いだったのか
前述のそれぞれがどう違うのか、について。
$("ul",this).css
「ulタグ」と「自分」を〜する。（この場合はCSSを変更）
thisもほかの関係ないulも対象ってことですね。。
参：selector1, selector2, …, selectorN – jQuery 日本語リファレンス
上記説明は
$("ul,this").css
の場合について、でした。
$("ul",this).css
の正しい説明は、jQuery(expression, context) – jQuery 日本語リファレンスをご覧ください。
この記述では、thisの中からulを探す、つまりfind()のようなことを出来るようです。
$("#dummy").css
のような記述は、つまり”"以降を省略しているようですね。
つまりドキュメント内から#dummyを探す、と。（上記リンクのサンプル3参照）
他参考リンク
jQuery() – jQuery API
initiumさん、kzさん、understandardさん、ありがとうございました！
$(this).children("ul")
「自分」の中の「子要素」にある「ulタグ」を〜する
参：children([expr]) – jQuery 日本語リファレンス
$(this).find("ul")
「自分」の中の「子孫要素」にある「ulタグ」を〜する
子供も孫もひ孫(ryも探せるってことですね。
参：find(expr) – jQuery 日本語リファレンス
もっとちゃんと勉強しないとですね。
結論（？）
持つべきものは、偉大な先輩…☆
ぱんださん、ありがとうございました！！！
先日、チカッパからHetemlにサーバ変更した、このサイトですが、
あっさりチカッパにもどしましたー！！いえーい！
え？なんでかって？
チカッパ！レンタルサーバーは、ロリポップ！レンタルサーバー 『 チカッパプラン 』 として、新たにパワーアップして生まれ変わりました
―チカッパ！レンタルサーバー – サービス内容
ってサーバ変えた翌日に連絡きたからですっ！！！（なんの罠なの本当に…）
マルチドメインも無料で100コOKになって、データベースも最大5コで、容量も今の倍の30GB。
私にはこれで充分じゃないデスカー！
もうどういうことなんデスカー！
とはいえ、まだチカッパも解約しておらず、Hetemlは無料試用期間だったので、前回四苦八苦したデータベースのお引っ越しもすんなり（嘘）完了し、チカッパに舞い戻りました。
サーバお引っ越し練習も出来て、無駄銭も使わずに済んで、誠にめでたしめでたし！（？）
おわり。
勢いでサーバ変えたので、メモ。
（メモしながら作業しなかったので、どこか間違っていたらすみません。。）
理由
ペパボのチカッパ！を使っていたのですが、マルチドメインでいくつか運用してみたくなったこともあり（チカッパは追加料金かかるのです…）、勢いで同じくペパボのhetemlに変えてみることにしました。
ペパボにコダワリがあるわけではないのですが、
なので、ひとまず今回は一番簡単そう☆という理由で、heteml一択。
バックアップ方法
ブログ以外の静的なページ、WordPressのPHPファイルなど諸々一式は、FTPでローカルの任意フォルダにDL。
さて、問題はブログのデータベース。。。サーバ疎い、データベースなにそれおいしいの、な私なので、まずはどうしたらいいのかググりました。
同じようにチカッパ！からhetemlに移した方のエントリーによると、「WP-DBManager」というWordPressのプラグインを使ったとのこと。
データベース（ブログエントリーなどのデータの保管場所ですね）のバックアップ等の管理を行えるプラグインのようです。
私は、ブログ管理画面のプラグイン検索からインストールしましたが、
作者の方のサイトからDLして、FTPでアップすることも出来ようです。
インストールやデータベースのバックアップ方法は、「小粋空間」さんが詳しく解説されているので、参考にさせていただきました。
新サーバへのデータ移行方法
FTPでローカルに保存しておいたファイルをごっそりで新サーバにアップします。
WordPressのwp-config.phpの設定を適宜変更。
（新サーバのデータベース情報が必要なので、先に新しく使用するデータベース作成しておいたほうがよい）
「WP-DBManager」を使用するか、もしくはphpMyAdminからのインストールで、
バックアップしておいたデータを新データベースに。
サーバやDNSの設定変更
新サーバに独自ドメインの設定、DNSの設定を行います。
参考）レンタルサーバー「heteml」 – ムームー DNS への移行方法
旧サーバの独自ドメイン設定解除。
そして現在。
たぶん、大丈夫そうです（笑
第4回CSS Holic『コーダーとプログラマーの付き合い方』に行ってまいりました！
第1回から@dearheartsさんにお声掛けいただき、ちゃっかりw参加していたCSS Holicも気がつけば第4回。
今回は、初の試みとなるゲストスピーカーの方が！
しかも今、ノリに乗ってる「nanapi(ナナピ)」を運営する
株式会社ロケットスタートCTO、和田修一さん！
毎度、ATND参加表明が遅れ、補欠ギリギリなアタシですが（！）今回も何とか滑り込めたので、にやにやしながら参加して参りましたよ。
内容は以下のような感じでした。（ATNDコピペですけども）
第一部
「nanapi(ナナピ)」を運営する株式会社ロケットスタートCTO 和田修一さんに
サービス運営を通じて、コーダーとエンジニアの付き合い方をお話頂きます。
第二部
APIを使ったPHPライブコーディング講座。
第三部
こんなこと困ってます。これどうやるの？
恒例の持ち寄り質問タイム
第一部
第一部では、nanapiなどを例に挙げ、受託開発とサービス開発の違いから始まり、チームでの意識共有の大切さ、エンジニアの仕事とはどんなことなのか等、取っ掛かりやすいような話口で、でも要点をついてお話しいただきました。
ばばっと20分くらいでしたが、わかりやすいーさすがですね。
個人的に気になったコトとしては以下。（※メモなので、細かい言い回しは異なります）
- 受託開発：売上が決まっている、ゴールはクライアントの満足
サービス開発：売上が決まっていない、利益の最大化がゴール
- ゴールからのブレイクダウン（何をつくりたいか、ではなく、何のためにつくるか）
- 役職が違えば、目標が違う、というのは誤り
- 組織は小さいほど、ボトムアップでは崩れる
- エンジニアの仕事：データ保存＆呼び出し、が基本
- 仕組みを作り続けることが重要
- ユーザーの声を100%反映させるのは正しくない
あと、ディレクター向けのレベルの知識は知っておいてほしい、とのことでした。
それだけで、話がスムーズになるそうです。
そんな基礎向けのオススメ本はこちら（↓）だそう。
ただ、個人的にものすごくショックだったのは、まさに昨日（！）この本処分してしまっていたこと…！！！あー何という苦笑
ちょっとまた買おうかな…（無駄
第二部
さて、第二部はライブコーディング！
企業向けとして有料で公開しているnanapiのAPIを今回特別に使用させていただき、予め和田さんが用意くださっていた、サンプルページを参加者で実際にちょろっといじってみました。
APIから特定のジャンルの記事（nanapi用語でいうライフレシピ）をとってきて、そこからさらに検索したり、検索結果ゼロだった場合の表示を書いたりしましたよ。
みんな、表示される度に、それはそれは初めてインターネットに触れたときのようにキャッキャしてました笑
ただ、アタシは、持ち運べるのがしょぼいネトブしかなかったこともあり、、PCなしの超絶アナログで参加していたので（恥）、、お隣さんのPCガン見してましただけなんですけど…すみませんすみません。
や、でも、なんか面白かったです。というレベルの低い感想で申し訳ないですが、、
が！面白そうだな！って思えるかどうかってすごく大切だと思うので、これでいいんですよね。（？）
第三部
第三部は質問コーナーだったんですが、、めも追いつかなかった、というか消化不良気味なので、誰かまとめてくれるといいな、、という他力本願。
そしてメモの落書きだけ公開しておこう。これであってますかね。
今回は、あくまで、導入部分というか、表題どーり、エンジニアさんとの接点増やしって感じでしたかね。この話を聞いたり、ライブコーディングしてみて、今後、こっからどう広げていくのか、勉強していくのかという。
勉強会の類は何事もそうなんですが。
その一歩への敷居を下げるという意味で、プログラムやプロジェクト全体、Webサービスに関して、興味のわく内容だったなと思います。
これまでも時々拝見してましたが、nanapiのファンになりました（単純w）
3年後の上場を目指していらっしゃるそうですよ！！すごい！
サービスそのものも優れていますし、応援していきたいサイトのひとつです！
（主に恋愛と料理のレシピ、熟読します…！！w）
改めまして、ゲストの和田さん、主催のみなさま、ありがとうございました！！
次回Holicも楽しみですね！
最後にCSS Holic情報
