前の日 / 次の日 / 最新 / 2005-12

/home/pochi/ChangeLog / 2005-12-22

01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

2005-12-22 Thu

山手線人身事故 [生活]

恵比寿駅で人身事故。
山手線遅延しまくり。
3連休、クリスマス前の忘年会日和りの新宿は、
それはそれは混乱しておりました。
電車は寿司詰め状態。
ひどい目にあったよ。

Black Hat Japan 2005 [computer]

http://www.blackhat.com/html/bh-japan-05/bh-jp-05-main.html

この資料もWiki小話の宴会で見せてもらった。
すげー面白いよ。

- ロシアのセキュリティツールをひととおり紹介したあとで、
  翻訳サイトがあるから大丈夫!、とか言ってみたり
- CPUのしくみについてのセキュリティ的な話があったり
- TCP/IP の脆弱性について語っていたり
- SIP の問題について語ってたり

あまりにも面白いので全部印刷して保存しとこうかなあ、
などと思ってしまった。

資料は以下に置いてある。

http://www.blackhat.com/html/bh-media-archives/bh-multi-media-archives.html

でもね、参加はしないと思う。
だって同じ種族だと思われたくないじゃない。

安全なWebアプリ開発の鉄則2004 [computer]

http://www.nic.ad.jp/ja/materials/iw/2004/proceedings/T5.pdf

Internet Week 2004 の高木浩光氏の資料。
Wiki小話の宴会で見せてもらったけど、良くまとまっていて
すごくわかりやすかった。
Web にかかわる人(きっととても多いよね)は見といて損はないと思う。

2005年のものもそのうち公開されると思われる。

Wiki小話/Vol.4 - Wiki作成者が知っておきたいセキュリティ・トラック [computer][イベント]

http://wikibana.socoda.net/wiki.cgi?Wiki%be%ae%cf%c3%2fVol%2e4

行ってきた。
宴会にも参加。

インターネットに関わってる人なら多分一度ぐらいは
ウェブアプリケーションを作ったり設置したりしたことがあると思う。
わたしもいわゆるウェブアプリケーション屋じゃないけど、
必要に応じていろいろなウェブ CGI やらサービスやらを
作ったり設置したりしている。

そういう人にとって、こういうセキュリティの話は
正直なところ耳に痛すぎるのよね。

言い訳は以下のような感じか。

- だってえね、攻撃手法はどんどん増えてるし、、、
- 数年前は OK だったり常識だったりしたことが駄目になるし、、、
- セキュリティを意識しすぎると手が止まっちゃって、
  やりたいことができなくなっちゃうから、
  適当なところで妥協せざる得ないし、、、
- すべてのレイヤを全部自分でいじれるわけじゃないし、、、
- そもそも予算とかリソースとか確保できてなかったり、、、
- 取られて困るものはないし、、、

開発する側の気持ちを言えば、

- なるべく楽をして
- そこそこ安全に
- やりたいことをすみやかにしたい

と思うんだけど、理想は遠いのう。

ウェブアプリケーションを作ることになった場合の、
仕事上のチェックリストは以下のような感じかねえ。

- やりたいことを明確にする
- 守るべきものを明確にする
- 必要な予算を確保する
- 良い運用者を確保する
- 良いプラットフォームを選定する
- 良いフレームワークを選定する
- 良いプログラマを確保する

でもこんなことを、いちいち考えるより、
思いついたことを、えいや、で作って、
どうこれ?、と言うほうが楽しいよねえ、、、、、
自分ではそれなりにやってるつもりだけど、
それなりだしなあ、、、、
うーむ、うーむ、、、、

結論。
年末にセキュリティの話は暗くなるから良くない。


参考)
wakatonoさんの資料は以下に公開されています。
とても良くまとまっているので一読をお勧めするです。

wakatono さんの資料
http://d.hatena.ne.jp/wakatono/20051222

国分さんの資料は日記を見てればそのうち上がってくると思われ

国分さんの日記
http://www.devnull.jp/tdiary/

セールスフォース、サービスがほぼ終日停止 [computer]

http://japan.cnet.com/news/ent/story/0,2000047623,20093467,00.htm

稼働率99%以上、と言っても止まるときは止まる。
そもそも 99%というのは、わりと緩くて、
実は1年のうち丸3日止まっても、99%なのよね。

サブシステムも準備しといたほうが良いかのう。

デスクトップの生産性を上げる10のツール [computer]

http://blogs.itmedia.co.jp/koji/2005/12/10_fd94.html

- 情報を効率良く収集して整理するツール
- 思考の手助けをするツール
- 作業効率を継続的に向上する努力を助けるツール

このへんがあれば良いのかな。
反対に生産性を下げるツールは以下かのう。

- 時間を無駄に浪費するツール
   --> bloglines とか、ゲームとか
- 作業効率が悪いツール
- 思考の邪魔をするツール
   --> メッセンジャーとか、操作性が悪いツールとか


むむ!、ひょっとして、こういう仕事に役立つ系の話って、
仕事の定義が

- 大量の情報をインプットして、処理して、アウトプットする、

という、おそろしく単純なモデルになってたりするのかしら?
人を情報処理機械として見てる?
たしかに、うまく情報処理ができる人のほうが、
仕事ができる人のイメージに近いしなあ。

でもね、情報処理なんてものは、機械にできるだけ
まかせたいなあ、なんてことも思うんだよね。
怠け者だからな。

Ruby on Rails で良くお世話になる Scaffold の日本語化 [computer]

http://wota.jp/ac/?date=20051220#p01

Scaffold は Rails でアプリケーションを作るときに、
多分絶対お世話になるものだと思う。

Rails を勉強して、最初にびっくりするのが、
scaffold による、超簡単ウェブインターフェイスの生成。
データベースを作って、scaffold を generate するだけで、
一通りのデータベース操作ができるようになっちゃう。
Rails 流行るわけだよなあ、と思うよ。

ただ、この日記に書いてあるように、
わりとみんなが、おもしれー、っていじってるけど、
日本語化のスタンダードみたいなものは、
ないような気がするんだよね。
今はみんな試行錯誤している段階で、たしかに熱気はある。
その熱気がちゃんと回っていくと良いなあ、
第2の Zope にならなきゃ良いなあ、と思うですわ。

新山さん FreeBSD をいじる [computer][ネタ]

http://tabesugi.net/memo/cur/cur.html#201834
http://tabesugi.net/memo/cur/cur.html#220005

ようするに FreeBSD を一言でいうと「非常に完成度の高い、
自動アップデートつきの Slackware」というところである。
というか、そもそも Slackware が *BSDっぽいんで、逆なんだけど。


正直な話、Fedora や SUSE から入ってまともに UNIX の
概念を身につけられる人がいるとは思えない。


まあそうかも。

FreeBSD は個人的には、サーバ用OSとしては一番手に馴染んでるなあ。
仕事用に使う場合には、運用をどうするかが最大の問題なんだけど、
運用者が確保できるのであれば、FreeBSD はとても良い選択肢だと思う。
Linux をディープに触って、なんか駄目駄目じゃん、と感じた場合の
乗り換え先としても需要はまだまだあるんじゃないかなあ、と思うね。
(用途によるけど)

ちなみに新山さんは、以下のサイトを見ればわかるけど
いろいろと面白いものを書いてたり、いろいろ作ったり、
すごく実績がある人ね。

http://www.unixuser.org/~euske/

Document の「どうでもいいもの」シリーズとかは
普通の人にもお勧めできる。

http://www.unixuser.org/~euske/doc/index.html#aho

うらにわにはにわにわにはにわにわとりがいる
http://www.unixuser.org/~euske/doc/niwatori/index.html

じつはこの文には 800通り以上もの意味の取り方があります…

徹夜をしてはいけない理由 [コラム]

http://blog.livedoor.jp/lalha/archives/50061915.html

わりと寝不足気味なんだけど、
よほどのことがない限り家に帰って寝るようにしてる。
寝てないと、頭がはたらかなくなるからねえ。

ここに載っているチャートはわりと面白いかも。
身体的症状は II と III の間ぐらいまではいったことがあるな。
精神的症状は I ぐらいまで。
心に比べて体が弱すぎるのだな。
運動せねばのう。

対話型システムの設計原則 - ウェブアプリケーションのユーザインターフェイス [computer]

http://www.atmarkit.co.jp/fwcr/rensai/usability06/01.html

- 可逆性と制御権の確保:試行錯誤を容易にし、
  ユーザーを応答者ではなく主体的な操作者として扱う。
- フィードバックの提供:すべての操作に対する状態と変化の提示。
- エラーの回避:早期のエラー検出による致命的エラーの回避。
- 一貫性:操作手順の統一、用語の統一、視覚表現の統一、
  オブジェクトの振る舞いの統一。
- 短期記憶負担の低減:情報量や選択肢を制限し、
  その場で十分に判断できるようにする。
- ショートカットの用意:キーボード、マクロ機能、スキップ。
- 業務への適合:ワークフローやタスクの特性に適合させる。
- 個人への適合:個人の目的やスキル特性に適合させる。
- 学習支援:オンラインチュートリアル、ヘルプ。


RFP 作成に使えるな。

Referrer (Inside): [2006-06-02-4]

Wikipedia がもたらす新しい「真実」 [コラム]

http://japan.cnet.com/column/pers/story/0,2000050150,20093396,00.htm?ref=rss

Wikipedia は、多くの目と多くの手があれば、
少数の専門家よりすごいんだよ、
ということを一般の人にわからせた事例の1つだと思う。

事例があると、人に説明しやすいんだよね。

次に欲しいのは、ちょっとしたコードがあれば、
多くの目と多くの手よりもすごいことができるんだよ、
ということのわかりやすい事例かな。
一般の人にとってわかりやすい、というのは案外難しい。

2021 : 01 02 03 04 05 06 07 08 09 10 11 12
2020 : 01 02 03 04 05 06 07 08 09 10 11 12
2019 : 01 02 03 04 05 06 07 08 09 10 11 12
2018 : 01 02 03 04 05 06 07 08 09 10 11 12
2017 : 01 02 03 04 05 06 07 08 09 10 11 12
2016 : 01 02 03 04 05 06 07 08 09 10 11 12
2015 : 01 02 03 04 05 06 07 08 09 10 11 12
2014 : 01 02 03 04 05 06 07 08 09 10 11 12
2013 : 01 02 03 04 05 06 07 08 09 10 11 12
2012 : 01 02 03 04 05 06 07 08 09 10 11 12
2011 : 01 02 03 04 05 06 07 08 09 10 11 12
2010 : 01 02 03 04 05 06 07 08 09 10 11 12
2009 : 01 02 03 04 05 06 07 08 09 10 11 12
2008 : 01 02 03 04 05 06 07 08 09 10 11 12
2007 : 01 02 03 04 05 06 07 08 09 10 11 12
2006 : 01 02 03 04 05 06 07 08 09 10 11 12
2005 : 01 02 03 04 05 06 07 08 09 10 11 12
2004 : 01 02 03 04 05 06 07 08 09 10 11 12

最終更新時間: 2021-03-02 14:20