知識の共有 => 掲示板、検索
個人の共有 => ブログ
人間関係の共有 => SNS
感情の共有 => twitter
2010年8月27日金曜日
2010年7月14日水曜日
前後の文脈は汲まれない。
twitterって脊髄反射を多分に助長するサービスだと思う。
でもwebの世界全体が徐々にそうなっていっている、できるだけoutput filterを通さずに脳にて出力されたデータをなるたけナマのままwebに留めるよう進化しているのだ。
ソーシャルグラフは既に電子化された。
本能のままを、これまでは外には出されないと思っていたものを永続的に保持されることで、理性を最大限働かせることと本能自体の去勢を押し付けられ、人はより進化していくのだ。
と酔ったら思った。
でもwebの世界全体が徐々にそうなっていっている、できるだけoutput filterを通さずに脳にて出力されたデータをなるたけナマのままwebに留めるよう進化しているのだ。
ソーシャルグラフは既に電子化された。
本能のままを、これまでは外には出されないと思っていたものを永続的に保持されることで、理性を最大限働かせることと本能自体の去勢を押し付けられ、人はより進化していくのだ。
と酔ったら思った。
あるふぁぶろがー達は一般人を啓蒙する方法を模索している
いつも自分の思考では及ばない事を気づかされたり、ある分野に精通している人が書いているブログで時々違和感を感じる。
その人たちがブログを初めたころと書き方が違う。または、当人と同じ専門の人にはこの人は真面目に書いていない、というのが解かる体で、おちゃらけてざっくばらんに文章を記述しているブログがある。
勝手に察するにその人たちはブログを始めた頃は人に伝える意思が弱いか、またはどういうタイプの人にこの文章が刺さるのかということをあまり意識して書いてなかったのだと思う。
そしてそブログに人気が出るにつれ、自分が思っていたより読者にその真意が伝わっていない事を知り、さらに伝播できる方法を模索しているのではないかと思った。
でも考えて見れば当たり前だ。
その人たちは、人より優れた文章を書けるから人気になったのだ。
感覚の問題だと思う。
一般人の感覚が無ければその目線に立って伝えるのは難しい。頭のいい人たちはそうでもない人たちがどういうプロセスで考え結論を出すのかをシミュレートできない。
であれば、その橋渡しをすることが可能なタイプの人間にすごくニーズがある気がする。
まあプロモーターであったりつまるところの広告屋かそれか。
日本語のブログで上位1000くらいをまとめて、カテゴライズ、ピックアップ、解説してくれるサービスがあれば人気が出そうな気がした。
その人たちがブログを初めたころと書き方が違う。または、当人と同じ専門の人にはこの人は真面目に書いていない、というのが解かる体で、おちゃらけてざっくばらんに文章を記述しているブログがある。
勝手に察するにその人たちはブログを始めた頃は人に伝える意思が弱いか、またはどういうタイプの人にこの文章が刺さるのかということをあまり意識して書いてなかったのだと思う。
そしてそブログに人気が出るにつれ、自分が思っていたより読者にその真意が伝わっていない事を知り、さらに伝播できる方法を模索しているのではないかと思った。
でも考えて見れば当たり前だ。
その人たちは、人より優れた文章を書けるから人気になったのだ。
感覚の問題だと思う。
一般人の感覚が無ければその目線に立って伝えるのは難しい。頭のいい人たちはそうでもない人たちがどういうプロセスで考え結論を出すのかをシミュレートできない。
であれば、その橋渡しをすることが可能なタイプの人間にすごくニーズがある気がする。
まあプロモーターであったりつまるところの広告屋かそれか。
日本語のブログで上位1000くらいをまとめて、カテゴライズ、ピックアップ、解説してくれるサービスがあれば人気が出そうな気がした。
2010年4月7日水曜日
日本のオープンソーシャル(携帯)
共通項
・SAPは課金で無いと儲けが望め無さそう。・課金可能な価値を提示できるのは今のところゲームのみ。
・ユーザからのinputはSAPにあまり渡したくない。CGMとしてのコンテンツはにぎっていたいから?携帯キャリア公式EMA関連”健全なインターネット”の為?
mixi
・ゲームはあまり重視したくない。・ただゲームがSAPにとって利益を確立しやすいモデルで、ユーザ受けがいいのもわかっている。
・ゲーム以外でヒットするコンテンツが出てきて欲しいが、現状では難しいだろうと思って悩んでいる。
mbga
・ゲームで課金、と割り切っている。・オープン化の流れに乗っただけで正直Open Socialとかいらなくね?的ポジション
・自社のゲームだけでも充分おいしいです系
GREE
・今いそいで作ってるよ!!・基本的にはゲーム路線?それ以外のソーシャルアプリもOKな感じ。
まとめ
・appleのappstore状態。・現状、携帯からSAPが取得できる情報でゲーム以外のアプリ作れってそれは無理。
・もっとオープンなプラットフォームが出てきてそっちにかっさらわれるんじゃないかと思う。
・プラットフォーム側はガワに徹して、メインのコンテンツをSAPに委ねるような感じ。
2010年4月6日火曜日
自分の感想を明確にする前にはてなブックマークを開くな
・ニュースやブログのエントリーを読んだあと、自分で自分の感想を決める前にはてなブックマークを開かない事。
・自分の知見の範囲外のことに関してはそれに限らない。
・自分の知見の範囲外のことに関してはそれに限らない。
2009年10月6日火曜日
XFSについて
centos5.1~3あたり
正しいのかも良くわかんない。
-lはログセクション、-dはデータセクション。それぞれのセクションのオプション詳細に関しては後述。
ファイルシステムのスーパーブロックに対する書き込み競合が減少する。指定しても特に問題なさそう(今後はこちらがデフォルトになるかも?)
centos5.3、kernel-2.6.18-128.x、kmod-xfs-0.4.2, xfsprogs(-devel)-2.9.4.1ではエラーに。。。
カーネル2.6.17あたりからデフォルトでwrite-barrierがオンになった。ファイルシステムの安全性を高める為のものだが、ハードウェアRAIDでbbu(Battery Backup Unit)があれば、2重のキャッシュになるので必要ない。
bbuが無い場合、予期しない電源ダウンなんかでデータが失われる(さらにファイルシステムが壊れる可能性もある?)可能性があるが、 barrierな状態だと結構パフォーマンスが落ちるので、危険性を理解したうえでoffにしておくのがいいかな。(もちろんonにできればそれに越した 事は無いが。)
on LVMの時は、LVM側でごにょごにょしてくれるので必要ない、が1年ほど前に調べた感じではあまり性能は良くないようだった。もっともWEBサービス用 途で言えば、dbサーバはレプリケーションだし、ストレージサーバはdrbdなり使うだろうし、スナップショットとれるという点を考えてもLVMを使うメ リットは無さそう。
この辺最近で言えば仮想化にとって食われた感じなのかな。
raidでストライピング(raid0, 5, 6)している場合、ストライプサイズとXFSを最適化する事によりパフォーマンスがあがる。ソフトウェアRAIDの場合はよろしくやってくれるので指定する必要がないらしい。ハードウェアRAIDの場合のみ
raidのストライプサイズ(チャンクサイズ)を512byteを1ブロックで計算したユニット数。
例えばストライプサイズが64KBなら、128
ストライピングを構成する物理hdd数(多分)。sunitを指定した場合はセットで指定する。sunitの倍数で以下が目安
raid1, 0, 10は、sunit * hddの数(raid1, 10はhddの数/2~hddの数)
raid5は、sunit * (hdd - 1)
raid6は、sunit * (hdd - 2)
正しいのかも良くわかんない。
特定のデバイス(パーティション)をXFSでフォーマット
# mkfs.xfs -f -d sunit=128,swidth=512 -l sunit=128,lazy-count=1 /dev/sda5
-lはログセクション、-dはデータセクション。それぞれのセクションのオプション詳細に関しては後述。
XFSのマウント
# mount -o nobarrier,sunit=128,swidth=512,noatime /dev/sda5 /home # vi /etc/fstab /dev/sda5 /home xfs defaults,nobarrier,sunit=128,swidth=512,noatime 1 2
lazy-countについて
ファイルシステムのスーパーブロックに対する書き込み競合が減少する。指定しても特に問題なさそう(今後はこちらがデフォルトになるかも?)
centos5.3、kernel-2.6.18-128.x、kmod-xfs-0.4.2, xfsprogs(-devel)-2.9.4.1ではエラーに。。。
nobarrierについて
カーネル2.6.17あたりからデフォルトでwrite-barrierがオンになった。ファイルシステムの安全性を高める為のものだが、ハードウェアRAIDでbbu(Battery Backup Unit)があれば、2重のキャッシュになるので必要ない。
bbuが無い場合、予期しない電源ダウンなんかでデータが失われる(さらにファイルシステムが壊れる可能性もある?)可能性があるが、 barrierな状態だと結構パフォーマンスが落ちるので、危険性を理解したうえでoffにしておくのがいいかな。(もちろんonにできればそれに越した 事は無いが。)
on LVMの時は、LVM側でごにょごにょしてくれるので必要ない、が1年ほど前に調べた感じではあまり性能は良くないようだった。もっともWEBサービス用 途で言えば、dbサーバはレプリケーションだし、ストレージサーバはdrbdなり使うだろうし、スナップショットとれるという点を考えてもLVMを使うメ リットは無さそう。
この辺最近で言えば仮想化にとって食われた感じなのかな。
sunit, swidthについて(データセクション)
raidでストライピング(raid0, 5, 6)している場合、ストライプサイズとXFSを最適化する事によりパフォーマンスがあがる。ソフトウェアRAIDの場合はよろしくやってくれるので指定する必要がないらしい。ハードウェアRAIDの場合のみ
sunit
raidのストライプサイズ(チャンクサイズ)を512byteを1ブロックで計算したユニット数。
例えばストライプサイズが64KBなら、128
swidtch
ストライピングを構成する物理hdd数(多分)。sunitを指定した場合はセットで指定する。sunitの倍数で以下が目安
raid1, 0, 10は、sunit * hddの数(raid1, 10はhddの数/2~hddの数)
raid5は、sunit * (hdd - 1)
raid6は、sunit * (hdd - 2)
su,sw
- d、データセクションでは、上記の簡易版のsu,swでの指定ができる。suはそのままストライプサイズ(上記で言えば64K)、swはhddの数を指定できる。
参考
- mkfs.xfsマニュアル
- wikipedia - XFS - ストライプアロケーションについて
- hwRAID10におけるXFSのストライド割り当てには難があるらしく、ブロック入力のパフォーマンスが低下
- マウントオプション
2009年9月13日日曜日
ウェブサービスと使い方
gmail
メール全般。他のメールサービスも転送してgmailで確認する。
必要にあわせて、「+hoge」
フィルタでDM系はガンガン即アーカイブ
ラベリングは確実に必要なもののみ(登録関連とか、買い物とか)。友達、家族みたいなラベルはつけない。
livedoor reader
面白そうなフィードがあれば取り合えず登録。リスト表示は星別で、星の数で優先度を決める。基本的に全て読みきる必要ないと割り切って、とりこぼしても拾わない、めんどくさくなったら飛ばす感じで斜め読み。
最近は本当に読みたいフィードはgoogle reader辺りで分けるべきかな、と考え中。
picasa web
携帯で撮った写真に位置情報をくっつけて登録。maps上に表示できるようになるので(設定が必要ですが)、それを見て楽しんだりがっかりする。
google site
個人的なまとめサイト。todoリストとか、欲しい物とか、調べた情報とかについて記録。他サービスへのハブ的な役割も果たす(ただのリンク集)。
はてなアンテナ
webマンガの更新チェック
はてなブックマーク
自分にとって重要性が高い、情報が体系だってまとめられている、検索にひっかかりにくい、を目安に追加する。必要な情報って結構複数のサイト に断片化して記述されていることが多く、それらを全てブックマークするよりgoogle siteとかにまとめちゃった方が後で参照しやすいじゃんと思い始めてからあまり使ってない。
はてなダイアリー
アウトプットは大事らしいので。
remember the milk
todo管理。あまり自分の肌に合わないらしく、使おうと思うことは何度もあるんだけど続かず。todoが必要になるとローカルのnotepad++に作る事の方が多い。
良くわからないけど流行ってるらしいのでとりあえず。
tumblr
webのスクラップ。
他
銀行のサイト
証券会社のサイト
ドメインとホスティングサービスのサイト
クレジットカードのサイト
登録:
投稿 (Atom)