koyachiの日記 - Joshua Schachter(del.icio.us)による大規模アプリケーション構築の注意点
del.icio.us/tag/del.icio.usを眺めていたらFlickrのときみたいに面白い資料を見つけたの紹介します。 Things to look out for when building a large application.というタイトルでサーバーサイドの管理等の話が中心かと思って読んでいたらそれ以外のインターフェース、実装すべき機能、spam対策、アプリケーションを如何に広めるかといった話にも触れていて面白いです。 以下にまとめてみました。 スケーリング 早期の最適化を避ける。SQLでスケーリングするのではなく、データを複数マシンに分散させる方法を考慮すべき。SQLプロファイリング重要。Nagiosがお勧め。 タグはSQLと相性がよくない。インデックシングの仕組みを理解し、その方針を決定する。最初の数ページに限定すれば小規模で高速なインデックスを保てる。 Apache
3年前の自分は別人、を他のひとにも当てはめてみる。 - naoyaのはてなダイアリー
自分の3年前を思い出すとまさに別人であり、5年後のことなんてわかるはずもない、なんてことを以前にもちょっと書きました。 はてなに入社して一年半ぐらいが経ちましたが、技術はもちろんそれ以外にもその間に得た物もの相当大きくてやっぱりその時と比較して今の自分は別人だなあと思います。 これは自分だけじゃなく、周囲を取り巻く人という人すべてがそうであって、そういう風に考えるといろんなものが見えてくる。 僕は近頃「初心者」という言葉の使い方に気をつけるようにしています。 特にウェブアプリケーションを作るなんて話で議論になると「初心者」という単語が良く出てきます。「初心者にもやさしい」とか「初心者でも扱えるように」とか。でも、初心者っていうのは3年後は初心者じゃない。上級者は3年後も上級者だろうけど。そして本当に初心者である期間はほんとに短い。だから「初心者にわかりやすい」みたいなところを中心に議論を進
RSSリーダーにもファッションセンスが必要: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 はてなについてずっと気になっていることがある。 ブログとオンライン型のRSSリーダーとソーシャルブックマークというサービスの組み合わせは最高だと思う。 だけど、なんであんなにセンス（端的にいえば、ファッションセンス）がないのだ！と。 たぶん、あのセンスのなさ（あるいは偏り）で、はてなは随分とターゲット層を狭めてしまっているはずだと思っている。実際、そのせいでいわゆるギーク寄りの人が集まる結果となってしまっているように見えるし、ブックマークで注目されるエントリーにもそちらの話題への偏りが見られる。 だから、僕はfeedpathに期待していたりもしていたわけだが、僕のその感覚はちょっとだけ正しかったらしく、feedpathの「最も使われるタグ」を見ていたりすると、よりマス的な言
ブラウザ幅に応じて変わるレイアウト | 秋元@サイボウズラボ・プログラマー・ブログ
via clagnut ブラウザの幅が狭いと2段、広いと3段になるようなページレイアウトをいくつか紹介している記事。 見てもらうのが一番早い。以下のページを開いて、ブラウザの幅を狭くしたり広くしたりすると、縦列の数が変化する。 UX MAGAZINE Redesign Notes 1: Width-based layout 著者自身のサンプルは、幅によってはあまり美しくならないが、何段にも可変にできる。 画面の大きな人でも小さな人でも、それなりのページが返せるというのはいいかもしれない。もっとも、逆に表示サイズがどうであれ同じレイアウトになることを望む人もいるだろうが。 日頃、だいたいブラウザの幅なんて一定で使ってるので、こういうレイアウトのサイトがかなり普及してたとしても気づいてないわけだが。こうやってブログで特集されてはじめて気づいた。僕は横にスクロールさせるよりはこっちの切り替えのほ
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
yohei-y:weblog: 良い URI の設計
URI は綺麗であるべき、と常々思っているんですが、よいページを発見しました。 Michael Eakes のこのエントリです。 Tanya Rabourn がリストアップしている文献一覧からエッセンスをまとめてくれています。 曰く、よく設計された URI とは 変らない(don't change) 人間が推測可能(are human guessable) 論理的(ファイルシステムを反映する必用がない) (are logical (no need to mirror a filesystem)) サイト構造をビジュアライズするのに役立つ(help visualize the site structure) 短い(are short) 小文字を使う(use lowercase) 予期されない記号を使わない(don't use unexpected punctuation) 問合せパラメータな
パスワードがいっぱい
新・闘わないプログラマ No.423 パスワードがいっぱい あるシステムのパスワードのポリシーが「セキュリティ強化のため」という名目で変更になりました。新しいポリシーは、 パスワードは8文字以上16文字以下 英字を少なくとも4文字、数字を少なくとも3文字、記号を少なくとも2文字含めること 同じ文字を3文字以上使用してはならない 同じ文字を連続させてはならない “abc”“5432”のように3文字以上連続させてはいけない 英独仏単語辞書と一致する部分があってはならない ローマ字と見なされるような部分があってはならない パスワードは3回間違うとロックアウトされる パスワードは14日に一回変更しなければならない 過去5回と同一、または類似のパスワードに変更することはできない パスワードを紙に書き留める等の、記憶以外の手段に頼ってはいけない (メモしていたことが発覚した場合にはアカウントを永久停止
大藤幹 『世界の「最先端」事例に学ぶ CSSプロフェッショナル・スタイル』 - モジログ
MYCOM BOOKS - 大藤幹 『世界の「最先端」事例に学ぶ CSSプロフェッショナル・スタイル』 http://book.mycom.co.jp/book/4-8399-1907-0/4-8399-1907-0.shtml 『Web Designing』誌に連載されている、大藤幹氏のCSS記事をまとめた本。 これは早く本になってほしいと以前から思っていたが、本になってみれば、連載に加えて特集記事などのオマケもついて、予想以上に充実した素晴らしい内容になっている。 この連載（本書）がいいのは、CSSの文法を教科書的に解説するのではなく、CSS界で名高いトップデザイナーが作ったサイトを題材に、そのCSSコードを実際に解析して、詳しく解説している点だ。 プログラミングでも、語学でもそうだが、文法を解説することが主眼の教科書は、「This is a pen」式の味気ない例文で学ばされることが
Macintosh Human Interface Guidelines (HI Guide)
Inside Macintosh: NEW: Aqua Human Interface Guidelines This document describes how to design your application for the Mac OS X user interface, known as Aqua. Primarily intended for Carbon and Cocoa developers娊ut also applicable for Java developers庪ho want their applications to look right and behave correctly in Mac OS X, this document provides examples of how to use Aqua interface elements. Click
〈 SL 〉: もう XML 言語を開発するな
Wednesday, January 11, 2006 もう XML 言語を開発するな Don’t Invent XML Languages by Tim Bray (Updated: 2006/01/09) XML の X は「拡張可能(Extensible)」という意味だ。自分の問題に応じて自分の XML 言語を開発できることをウリにしている。でも、僕は過去 2 、3 年の経験から、そうすべきではないことを悟った。本当に必要な時以外はね。今からそれを説明する。そして、もし本当に必要な時がくれば、関連文書のOn XML Language Design を読んで欲しい。 僕は最近ある XML 言語の開発を手伝っていたのだけれど、どうか話半分で聞いて欲しい。僕は言語デザインをメインでやっているわけではないし、僕がもし専門技術でなにか言えることがあるとすれば、それは主としてたくさんの異なる X
script.aculo.us - web 2.0 javascript
This is a bugfix release that bumps script.aculo.us to version 1.9.0. Most importantly, the included Prototype 1.7 provides performance and compatibility improvements with the latest browsers. One other fix is includes, that makes the script.aculo.us loader work better if you use script tags in the BODY of your page. Download at http://script.aculo.us/, or grab/fork the source at http://github.com
プログラミングとは経営判断の集積である - 分裂勘違い君劇場 by ふろむだ
ソースコードの一行一行は、経営判断そのものだ。 どの部分を汎用的につくり、どの部分をやっつけで作るか、そして、どの部分をパフォーマンス優先でつくり、どの部分を可読性優先でつくるかは、そのソフトウェアステムを使って今後どのようなビジネス展開をするか、ということと一体不可分だ。プログラマーは、絶え間なく改変されていく部分と、財産として今後も使われつづけそうな部分を意識しながらコーディングする。そして、ここでいう財産とは、プログラマが財産とみなすものであるだけでなく、同時に経営的・財務的な意味においても財産であり、会社のバランスシートの「資産」の項目に登場するような性質のものだということは、多くのエンジニアが漠然としかいしきしていないように見える。 「このルーチンは、時間がかかっても、汎用的なライブラリやフレームワークにしておこう」、とエンジニアが「なんとなく」決めたとき、実は、そのエンジニアは
クールなURIは変わらない -- Style Guide for Online Hypertext
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
参考になる CSS 集
テンプレートいろいろ 特定の文書構造とセットの CSS ばかり。まあ、「テンプレート」ですからね、私の不満はいちゃもんに過ぎないのでしょう。これからはスタイルシートでデザインする時代だ、なんていってみても、レイアウト用の div 要素などはたくさん書いても、本文のマークアップには無頓着な人がほとんど。だからきちんと HTML の主要な要素について装飾を指定したスタイルシートには需要がない。 個人的には、以下のリストに示すスタイルシート群の方がずっと「参考になる」と思うのだけれど……。 Appendix > CSS List - outsider reflex CSS カタログ 「言葉 言葉 言葉」スタイルシートギャラリー スタイルシートライブラリ - W.F.N. CSSギャラリー ちなみに私の書くスタイルシートは、自分が使わない要素の装飾についてまともな指定がなされていないので、あまり汎
お知らせ
タイトル・・[入門+実践] 要求を仕様化する技術・表現する技術 出版社・・・技術評論社 A5判／368ページ 価格・・・・定価 ２５８0円（＋税） ISBN4-7741-2523-7 発売・・２００５年１０月７日 都内大型店では９月末に並ぶようです ようやく、Software People vol.4（2004年の４月刊）で公開した要求の仕様化方法「要求の仕様化入門」が本の形にまとまりました。雑誌で公開したあと、読者の皆さんから大きな反響があり、急遽、内容と範囲を広げて原稿の作成に取り掛かったものですが、途中、私の本業であるSPIのコンサルティングが忙しくなったために、当初の予定より、６月以上も遅れてしまいました。 本書は、雑誌に公開した内容も、そのほとんどを書き直し、紙数の関係で雑誌では公開できなかった要求の表現や仕様化のテクニックもたくさん盛り込みました。事例もできるだけ多
オブジェクト指向は本当に「オブジェクト」指向か？ -INDEX-
[オブジェクト指向は本当に「オブジェクト」指向か？] ＩＮＤＥＸ １．オブジェクト指向かクラス指向か？ ２．人の身分をどうモデル化するか？ ２．１ 身分を関連の役割で表現したモデル ２．２ 身分を人から分離させたモデル ２．３ 人を「分類」したモデル ３．分類によるモデリング ３．１ 多重分類と動的分類 ３．２ なぜ多重分類、動的分類を実装できないのか？ ３．３ 分類によるモデリング ３．４ いつ分類によるモデリングをすべきか？ ４．まとめ ４．１ (再び)オブジェクト指向かクラス指向か？ ４．２ オブジェクトの世界は階級社会？ ５．参考文献 written by （株）オージス総研 オブジェクト第一事業部 開発技術コンサルティング室 平澤 章
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTMLクイックリファレンス
https://labs.cybozu.co.jp/blog/kazuho/archives/2006/02/utilizing_cache.php
OKボタンの位置はどこが適切?
Download Palettes Websmart Colorcube ePub eBook @WWW.MORECRAYONS.COM