目的 一覧表に各シートの件数やタイトルを記入する 同一セル内でも行う方法 方法1：INDIRECT =INDIRECT($B5&"!F3") INDIRECTに「シート名!A1」みたいな文字列を投げ込むと、 「=シート名!A1」として扱ってくれるというネタ 参考資料 「excel関数 別シート参照」でぐぐる はてな？excelで別シートを参照するとき… http://q.hatena.ne.jp/1166860036 別シートへのセル参照をオートフィルで−INDIRECT関数 http://www.relief.jp/itnote/archives/001697.php 方法2：OFFSET =OFFSET(基準セル,行位置,列位置,行高さ,列幅) =OFFSET(A1,2,0) // こっちは2次元配列を書き換えてテスト項目表を作成するのに使った 参考資料 ＥＸＣＥＬでのセル座標を指定する数式について http://questionbox.jp.msn.com/qa2030149.html

業務でPOP3のメールボックスに来たメールから、 リターンメールだけ判別する仕事が出てきた。 そんな事出来んの？ 調べてみた エラーメール（リターンメール）の処理 http://www.mail-send.com/report110.html エラーメールの対処方法 http://help.ocn.ne.jp/ols/tr/mail/10015_trm_errormail.html エラーメールの説明（MAILER-DAEMON からのメール） http://www.tku.ac.jp/iss/guide/mail/tipsmail/mailerdaemon.html はてな「不達Eメールの処理ってどうやってるんですかねぇ？」 http://q.hatena.ne.jp/1129785217 それなりにできそう。 ただRFCの日本語訳が殆ど無いぞ… 英語も読めん地雷プルグラマの俺には無理だ…

目的 MySQLのインデックスに関して理解する。 - インデックスとはなんぞや？ - 使い方の学習 - 実際に使ってみる＆既存システムを覗いてみる インデックスとはなんぞや？ 検索が早くなる位しか知らないので、 何故通常の検索では遅いのか、何故インデックスを使用するのか。 その辺から勉強していきたい（今更） MySQLパフォーマンスチューニングのためのインデックスの基礎知識 http://d.hatena.ne.jp/kiyo560808/20101117/1289952549 レコードの数が増えるにつれ、 特定のレコードを見つけ出すのに必要な処理が増える。 これをO(n)問題という。 メリット 検索する時にインデックスのみを見て式を評価 高速化が期待出来る -デメリット 所持するデータを複数持つので容量が肥大化 書き込み(SELECT以外)のパフォーマンスが低下 速度に関して じゃあ実際の速度ってどうなの？ あんまり速くならないならデータを冗長化させる必要なんてないしね ソーシャルゲーム開発者なら知っておきたい MySQL INDEX + EXPLAIN入門 http://www.infiniteloop.co.jp/blog/2011/03/mysql-index-explain/ MySQL INDEX+EXPLAIN入門 のスライド5枚目 インデックスを使用すると、 SELECTに掛かる時間がレコードに比例せず一定 ( Д ) ﾟ ﾟ ただ、この最小単位が100万レコードってのが一つのキーになりそうだ。 1万程度までならインデックスを作成しない選択肢もあり得るのかもしれない。 でも、別にインデックス作ったからと言ってSelectが遅くなる訳じゃないので、 理由が無ければとりあえず作る位の考えでも良いのか？ 使い方の学習 上記サイトに書いてあった方法 ALTER TABLE foo ADD INDEX (id, name) 効果的な使い方のキモは上記2サイトを参考 - インデックスの作成時 - 選択性の高い項目をインデックスにする - 複合インデックスは先頭から順に部分インデックスとしても使用できる - インデックスサイズを増やさない・増えることによる影響

いや、それは違う 日本語は決して曖昧な言語ではない。 日本語は一つの意味を表現するのに基本的に一つの単語で足りる。 対して英語の単語はおおまかなイメージを表現する程度のものなので、 固有名詞以外は物凄く曖昧で大雑把だ。 なので日本語よりよほど曖昧で不完全な言語になるはずだ。 [追記]英語の曖昧性を補填する では英語で曖昧でない文章を作る為にどうするか？ 主語述語の配置をきっちり守る 曖昧な名詞は修飾子を足して具体的にしていく あえて文を崩す事により、相手に違和感を持たせる→質問文と解釈する 細かな文法は省くが、だいたいこんな感じ。 配置と修飾で具体的な文章を作っていくわけだ。 対する日本語は倒置法があるように、主語や述語の順番を混ぜこぜにしてもあまり違和感はない。 精々エキゾチックに聞こえるくらいのものだ。 何故そんな日本語が曖昧な言語扱いされてるのか 以前そのことが書いてあるサイトがどっかにあったような…見つからない。 代わりに探していたら非常に参考になるサイトが見つかった 正確な曖昧性 こういう話を見かけた。「最近見かけませんでしたが、どうしたんですか。」と聞かれ、「三日間旅行していました。」と答えたら、変だと指摘されたアメリカ人がいるそうだ。そしてその指摘をした日本人は、そういう場合は「三日ほど旅行していました。」と答えるべきだと言ったそうだ。 ふむふむ、何故ぼかすの？ 日本語では焦点かどうかが文法的に重要だ。 例えば、「私は高杉です。」と「私が高杉です。」を比べると、後者は主語に「が」が付いている。これは「私」が焦点だからだ。つまり、「誰が高杉さんですか。」という質問に対して、「私が高杉です。」というように、「私」の部分が焦点だから「が」を使うのだ。逆に「あなたは誰ですか。」という質問には、「私は高杉です。」と答える。「高杉」が焦点で、「私」はすでに出てきた旧情報（これを主題という）だから「は」が付くのだ。 焦点が重要なんだ。 たしかに…日本語は1単語が重い意味を持つがゆえに、 焦点が分からない場合、全ての発言を気を張り続けて覚える必要があるわけか。 最初の質問に戻ろう。「最近見かけませんでしたが、どうしたんですか。」と聞かれた場合、当然何をしていたかが焦点になる。それ以外の情報は単なる付け足しである。だから答は「旅行していました。」で十分だ。 ここで語彙の助けを得れば良いのだ。期間に「ほど」を付けると、曖昧な感じがするのでそれが重要な情報には思えなくなる。「三日ほど旅行していました。」という文は「三日ほど」が動詞の直前に来ているが、「ほど」が付いているため重要には見えないのでそれが焦点と解釈されることはない。 なるほど〜！ 焦点を分かりやすくし、それ以外の箇所をあえて曖昧にするのか。 そうすることで、伝えたい大事な単語のやり取りを聞き逃す事がなくなるわけだ。 非常に参考になった。

結論 jQueryのセレクタは右側から評価する jQueryは長いセレクタの場合、右側から解釈するので、 ヒット数の多いものが右側に来ると非常に時間が掛かる。 // NG: li要素の一覧を先に取得するので、IDで絞った意味がない $("#conditions li"); // OK: このように使えばIDがconditionsのものから検索出来る $("#conditions").find("li"); 重い処理はキャッシュを使う 変数を宣言して、jQueryオブジェクトを保存することをキャッシュと呼ぶらしい。 例えば何度もhogeクラスの要素を使う場合、 下記のように書いておけばHTMLを全て検索する処理は一度で済む。 var $hoge = $(".hoge"); var $piko = $hoge.find(".piko"); 速度改善のきっかけ jQueryを使用しているページを業務内で触っていたが、 Tableの表示がものすごく遅い…という訳で CSSやJavascriptを修正して速度改善することになった。 条件 Excelの「ウィンドウ枠の固定」っぽい表示にする jQueryのライブラリを使用して実装すること カラムの動的な表示・非表示を行う チェックボックスを複数作成し、チェックが消えるとカラム非表示 ぐぐってみた JavaScriptコーディング等を書く上でのパフォーマンス確認事項３０ http://phpspot.org/blog/archives/2010/06/javascript_87.html JavaScriptに関しては良い感じだが、jQueryに関しては少ない。 幾つかの項目は可読性が犠牲になるので余裕があればで良いだろう。 jQuery(“ul > li”) のように使う。 jQuery(“ul li”) は広義すぎる jQueryは右側から解釈するのでどちらもNG 例ならjQuery(“ul”).children(“li”)、もしくはjQuery(“ul”).find(“li”)とするのが良いだろう。 jQueryを良くする25のTIPS http://blog.webcreativepark.net/2008/12/17-225630.html 最初に読む書籍としてはかなり良い。 口語が多いので十分理解できたら別のページがよさそう。 jqueryのセレクタを高速化する http://nex.xrea.jp/?s=1231 シンプルな結論だった

なぜ再帰問い合わせが必要になったか うちのブログがidとparent_idで木構造を表現しているが、 ぶら下がってる全ての記事一覧を取得したい。 それにはSQLで定義されているWith句を利用すれば良いが、 MySQLではまだ未実装らしい(2011/02時点) しかし、再帰問い合わせなんて単語を知らなかったので、 調査ついでにまとめてみた。 WITH句に関しての説明 新しい業界標準「SQL99」詳細解説 http://www.atmarkit.co.jp/fnetwork/tokusyuu/01sql99/sql99_1b.html ぐぐった結果 PHPとMySQLでツリー構造を扱う http://aratanuki.blog100.fc2.com/blog-entry-82.html これはPHPでクエリーを都度投げる方法。 この記事ではmysqli::prepare()を使っている。 これを参考に実装するならば、まず親記事の一覧を作成し、 「WHERE parent_id IN (親記事の一覧)」として記事の一覧を取得してくる感じか… 子要素を再帰的に取ってくるストアドプロシージャ http://blog.udzura.jp/2010/08/21/recursive-stored-procedure/ ストアドプロシージャ？ 一時的にテーブルを作成し、結果をどんどん投げ込んでから再度検索しなおす感じか？ 結論 MySQLで再帰問い合わせは難しい ブログに使うのは諦めた