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
恵比寿駅で人身事故。
山手線遅延しまくり。
3連休、クリスマス前の忘年会日和りの新宿は、
それはそれは混乱しておりました。
電車は寿司詰め状態。
ひどい目にあったよ。
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
でもね、参加はしないと思う。
だって同じ種族だと思われたくないじゃない。
http://www.nic.ad.jp/ja/materials/iw/2004/proceedings/T5.pdf
Internet Week 2004 の高木浩光氏の資料。
Wiki小話の宴会で見せてもらったけど、良くまとまっていて
すごくわかりやすかった。
Web にかかわる人(きっととても多いよね)は見といて損はないと思う。
2005年のものもそのうち公開されると思われる。
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/
http://japan.cnet.com/news/ent/story/0,2000047623,20093467,00.htm
稼働率99%以上、と言っても止まるときは止まる。
そもそも 99%というのは、わりと緩くて、
実は1年のうち丸3日止まっても、99%なのよね。
サブシステムも準備しといたほうが良いかのう。
http://blogs.itmedia.co.jp/koji/2005/12/10_fd94.html
- 情報を効率良く収集して整理するツール
- 思考の手助けをするツール
- 作業効率を継続的に向上する努力を助けるツール
このへんがあれば良いのかな。
反対に生産性を下げるツールは以下かのう。
- 時間を無駄に浪費するツール
--> bloglines とか、ゲームとか
- 作業効率が悪いツール
- 思考の邪魔をするツール
--> メッセンジャーとか、操作性が悪いツールとか
むむ!、ひょっとして、こういう仕事に役立つ系の話って、
仕事の定義が
- 大量の情報をインプットして、処理して、アウトプットする、
という、おそろしく単純なモデルになってたりするのかしら?
人を情報処理機械として見てる?
たしかに、うまく情報処理ができる人のほうが、
仕事ができる人のイメージに近いしなあ。
でもね、情報処理なんてものは、機械にできるだけ
まかせたいなあ、なんてことも思うんだよね。
怠け者だからな。
http://wota.jp/ac/?date=20051220#p01
Scaffold は Rails でアプリケーションを作るときに、
多分絶対お世話になるものだと思う。
Rails を勉強して、最初にびっくりするのが、
scaffold による、超簡単ウェブインターフェイスの生成。
データベースを作って、scaffold を generate するだけで、
一通りのデータベース操作ができるようになっちゃう。
Rails 流行るわけだよなあ、と思うよ。
ただ、この日記に書いてあるように、
わりとみんなが、おもしれー、っていじってるけど、
日本語化のスタンダードみたいなものは、
ないような気がするんだよね。
今はみんな試行錯誤している段階で、たしかに熱気はある。
その熱気がちゃんと回っていくと良いなあ、
第2の Zope にならなきゃ良いなあ、と思うですわ。
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 ぐらいまで。
心に比べて体が弱すぎるのだな。
運動せねばのう。
http://www.atmarkit.co.jp/fwcr/rensai/usability06/01.html
- 可逆性と制御権の確保:試行錯誤を容易にし、
ユーザーを応答者ではなく主体的な操作者として扱う。
- フィードバックの提供:すべての操作に対する状態と変化の提示。
- エラーの回避:早期のエラー検出による致命的エラーの回避。
- 一貫性:操作手順の統一、用語の統一、視覚表現の統一、
オブジェクトの振る舞いの統一。
- 短期記憶負担の低減:情報量や選択肢を制限し、
その場で十分に判断できるようにする。
- ショートカットの用意:キーボード、マクロ機能、スキップ。
- 業務への適合:ワークフローやタスクの特性に適合させる。
- 個人への適合:個人の目的やスキル特性に適合させる。
- 学習支援:オンラインチュートリアル、ヘルプ。
RFP 作成に使えるな。
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