b-windPowerd by iddy.jp
自称ＩＴアーキテクトの自堕落な日常を綴る日記です。
技術ネタを書こうと始めた日記なのに、文房具ネタの方が多いというのが目下の悩み。
Yahoo!GoogleでランクアップするためのSEO完全計画(水野 貴明)
現在の SEO 周りの話題はどうなっているのか？が知りたくて SEO 解説本を買ってみた。
表紙を見る限り何が何でも検索結果を上げてやる！的な内容に見えるが意外に丁寧かつ好ましい形での対策方法が書かれている。
とても読みやすく好感は持ったが、逆に細かいテクニックなどはほとんど無く「基本」の列挙だけで終わってしまっている。
残念ながら自分には特別役に立ち沿うには無いが、初心者に「SEO ってなに」と聞かれた場合には割りとオススメできそうだ。
契約書の書式文例77―作成頻度の高い契約書式をそのまま使える形で紹介! (Do BOOKS)(石井 逸郎)
ソフト契約と見積りの基本がよーくわかる本―実践・ソフト取引契約文書作成の手引き (How‐nual Business Guide Book)(谷口 功)とある縁でサイトの作成をする事になった。で、契約書の作成。
まぁ個人同士の話なので大げさにする必要もないのだが、やっぱりお金のかかわる話なので筋は通しておきたい。
で、参考にしたのがこの２冊。契約書の書式文例77の方は契約書全般にかかわる諸注意が少しと文例集。判子とか収入印紙の辺りの説明が参考になる。あと、他の形の契約書も見れてそれぞれにポイントとなる点が注記されているので、文例どおりではない場合に応用が利く。
今回主に参考にしたのはソフト契約と見積りの基本がよーくわかる本の方。厳密にはソフトウェア開発じゃないけど、考え方はかなり近いので。こちらは文例は少ないけどその分細かいところまで掘り下げて説明してあるので、この業界で働くなら読んで損はない。実際に作成する機会はなくても作成された契約書にそって仕事をするわけだから。
あとは相手と話し合って具体的な部分をつめていかなきゃ。
ここ暫く居心地のいい休憩所*1と化していた本店が今日で一時閉店となっています。
せっかくなので閉店間際までいたんですが、なぜか突然３０分ほど閉店時間延長。すでに客もほとんど引いているというのにこのてきとーさはさすがナガサワです。
一部商品は売れ残ったら捨てるしかないようで、かなりお得な値段のものも有りました。一通り買いあさった後、帰るときには社長以下そうそうたるメンバーでお見送り。
３月１７日にはリニューアルオープンするわけですが、自分的には面白くない場所になりそうです。それでもたぶん行くけど。
*1 おいこら
これ底の刻印を見れば分かるんですが、PLUS かるヒットの色違いＯＥＭ品なんですよね。
実際使ってみると普通のステープラーとは違い、押し込むとあるところからいきなりカクンといきなり閉じられる。
でざいんはこっちの方がすきだし、使い勝手もいい。非常に満足、といいたいところだが一つ重大な欠点が。
なんのことはないこっちと間違えていたのだ。
つまりフラットクリンチではありません。どうりでやけに安いと思ったんだよなぁ。
それぞれ一気に乗り換えたものだから、使い勝手にまだちょっと戸惑っている。
特に Livedoor Reader でピンを立てた後一気に開く時に「この機能を使うにはポップアップブロックを解除してください。」という警告が出るのがどうにもならない。
もちろん Firefox の設定では許可にしているし、起動して暫くは問題ないのだけれど、どうも新規タブかウィンドウを開く数に制限があるような感じ。
Tab の設定は TabMix Plus を入れているのだけどそれらしき設定は見当たらず。
やっぱりここは about:config をいじらなければならないのだろうか。
オブジェクト指向Perlマスターコース―オブジェクト指向の概念とPerlによる実装方法(ダミアン コンウェイ)
今手元に無いので確認できないが、似たような手法は オブジェクト指向Perlマスターコースにも載っていた。たぶん。
詳しくは、上掲のPerl Best Practicesをご覧あれ。
[perl - Inside-out Objectより引用]
でも _ （アンダーバー）で始まる変数はいじらないという紳士協定の方が Perl っぽくて好きだけどね。
それはそうと、Perl Best Practices 欲しい。でも高いなぁ。
ちょっと思うところあったので。
担当の男性は非常に若く、私よりも一回りは若い感じでしたが、ひとつずつ私の話を聞きだし、私の深層にある条件を引き出し、私を驚かせました。それを書き留めて、彼は候補をいくつか用意して提案すると約束しました。
[永住の地を求めてより引用]
これ、どんな職業にも言える大事な事だと思うんです。
一部の例外を除けばお客様は普通素人。上から見下しているような言い方になってしまうが、自分の欲しているものが分かっているとは限らない。分かっていてもそれを正確に言葉として表現できる人は少ない。
プログラマーなどの業界では営業が取ってきた案件を仕様通りにただ作成することを是とする雰囲気があるように感じられてしまう。
極論すればプログラムを組めばたいていの事はできる。言われたとおりの物を作るのは楽だがそれがユーザーにとって本当に欲しかったものとも限らない。
ユーザーの置かれた環境。立場。さまざまなものを含めてベストを提案していきたい。そんな風に考えています。
それはそうと、いい場所が見つかるといいですね。
暫く時間があまり取れなかったのもあって相当量の未読記事が。とりあえず片っ端から読んでいく。
ＤＭ系は除いたとしても数百件のレベル。アルファギークと呼ばれる人たちは数千件の FEED を捌いているらしいけど、どうやってるんだろう？
自分の場合、いろんな分野に興味があるのと読み漏らしがあるともったいないと思って大半の記事は全文読んでいる。
livedoor Reader に移行してからはだいぶマシになったけど、どうしてもニュースサイト系の記事が大量すぎて捌けない。
しかも結構同じ感じの記事が紹介されている事も多いので、このあたりどうにかして省略できないものか。
ナガサワ本店がリニューアルオープンしたので早速行ってきました。
まず感じたのは結構広いので何がどこに有るかさっぱり分からない。入り口近くにフロアガイドは欲しいかと。それと入り口はジュンク堂側からしかないんですね。微妙に入るのに遠回りしないといけません。
あとちょっと通路が狭いかな。まぁその分以前よりたくさんの商品が並んでるんですが。
さすがにオープンセール初日とあってたくさんの人だかり。レジもフロアの大きさの割りに２台しかないので*1始終込み合っていました。
多数のセール品があるのと、一応粗品をもらえるのでタイミングが合えば行ってみると面白いかもしれません。
チラシはもらったんですが、なぜか Web にはセール情報は無し。このあたりはナガサワの弱いところかな。もっと積極的に使えばいいのに。
自分的に興味があったのは、セール限定で入荷した、LAMY バルーン ローラーボール。現在日本では取り扱いが無いので店頭においているところはほとんど無いはず。リフィルが専用なのでいままで購入を躊躇していたのですが、ナガサワで手に入るなら買ってもいいかも
*1 一応奥にもあるらしいですが、使っていませんでした。
ブルーウォーター (21st century ver.)
不思議の海のナディアの主題歌「ブルーウォーター」が 森川美穂自身の手でセルフカバーこれは買わねば
ちなみにオリジナルはこんな感じ。
言いたい事は分からないでも無いし、特に反論も無いのだけど根拠として提示されている部分があまりにも乱暴に思った。
PostgreSQLの場合ストレージの読み込み単位がデフォルト8KByteになっている.これはある1レコードを読み込んだ場合,そのレコードのあるディスクの位置から8Kを必ず読むということを意味する.
その結果意味のないReadが発生することになり,DB内のキャッシュがかき消される結果になってあまりうまくない.PostgreSQLが8Kを読むのはテーブルスキャンなどの時に先読みなどを行いたい為だが,今回の様なケースではそれが裏目に出ているということになる.
[最速配信研究会 - 2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要)より引用]
デフォルト値が全ての用途に適しているとは限らないのは当然。残念ながら PostgreSQL ではページサイズはコンパイル時に決まってしまうが、変更は可能だ。
テーブルとインデックスは全て、固定サイズ（通常8キロバイト。サーバのコンパイル時に異なるサイズを設定可能）のページの集まりとして格納されます。
[52.3. データベースページファイルより引用]
また、ファイルシステムを使用した場合と比較しているが、
その一方2chのデータストレージ(?)の実装は1スレ1datファイルという実に男らしい設計になっている.これは一見原始的に見えるかもしれないけれど,データがディスク上に常に連続しているため,データのローカリティの確保という点ではとても優れている.
[最速配信研究会 - 2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要)より引用]
これもおかしい。2ch.net は確か FreeBSD を使用していたと思うが、標準の UFS では デフォルトでブロックサイズは 16KB。
-b block-size
ファイルシステムのブロックサイズをバイト単位で指定します。 2 のべ
き乗である必要があります。デフォルトサイズは 16384 バイトであり、
可能な最小サイズは 4096 バイトです。最適なブロックとフラグメント
の比率は 8:1 です。他の比率も可能ですが、お勧めできませんし、お粗
末な結果となるかもしれません。
[On-line Manual of "newfs"より引用]
Linux で ext2 だと 4KB になる。
データブロックのサイズは、ほかのブロックと同じ1024、2048、4096bytesのいずれかの値である（通常、デフォルトでは4096bytes）
[ブロックアルゴリズムとext2より引用]
ちなみに手元の dat ファイルで計算してみると 73 ファイル平均 12KB 最大 269KB 。１ファイルだからといってフラグメンテーションが起こらないわけではない。
最後に１スレッドを１カラムにと言う提案をしているが、
RDBMSでこれをやろうと思うと,1スレの全データを1カラムに格納するという手がある.
create table message_boards(id serial,
title varchar(256),
body text
);
これなら1スレッドのデータはディスクの連続した領域に格納されるので,上記のような無駄なメモリ使用は発生しない.
[最速配信研究会 - 2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要)より引用]
これまたダウト。PostgreSQLは固定長のページサイズ（通常8キロバイト）を使用し、複数ページにまたがるタプルを許しません。そのため、大規模なフィールド値を直接格納できません。大規模なフィールド値を圧縮したり、複数の物理的な行に分割したりすることで、この限界はなくなりました。
[52.2. TOASTより引用]
ページサイズを超えた分に関してはバックエンドで自動的に分割されます。結果、「ディスクの連続した領域に格納される」保証はありません。
本当は分かってて書いているかもしれないけれど、誤解を招くような説明はやめてほしいなぁ。
なお、結論としてはやはり現状の 2ch.net に RDBMS は向いていないと考える。スレッドをまたいだ検索・表示の必要性が無いためディレクトリ・ファイル名を INDEX とするだけで十分であり、かつ最も早いからだ。
とはいえそれを CGM 全般と捉えるとこには違和感を感じる。2ch.net 方式ではスレッドを跨いだリアルタイム検索はそのままでは実現しにくい。あくまで 2ch.net に特化した形式だと考える方が妥当であろう。
