TopHatenarとHatenarMapsのDB！
TopHatenarとHatenarMapsとは 本連載では、さまざまなサービスで利用されているデータベースやその仕組みについて紹介していきます。第1回は、Webアプリケーションである「TopHatenar（http://tophatenar.com/）」と「HatenarMaps（http://hatenarmaps.com/）」を取り上げ、そのデータベース構造とデータアクセス手法を中心に、アプリケーションの裏側について解説を行います。 まずTopHatenarとHatenarMapsとは何かを紹介します。この2つのWebアプリケーションは、ともに大手ブログサービス「はてなダイアリー」のユーザー動向を把握するツールとして、筆者が開発したものです。 TopHatenarは、はてなダイアリーの全ブロガーを、「RSSフィード購読者数」と「ソーシャルブックマーク獲得数」の2つの指標に基づいて順位
オレ様に課せられた制約はあまりにも多い - 梶本裕介の過去の日記
オレ様に課せられた制約はあまりにも多いリレーションを正規化してはいけないSQLではNUMBERとVARCHAR以外の型を使ってはいけない結合はできるだけ避けることテーブルとクラスのフィールドは1対1に対応してなければいけない論理値を表す名前はFlagで終わらなければならない列挙値を表す名前もFlagで終わらなければならないページの遷移はJSPに記述しなければならないビジネスロジックも出来る限りJSPに記述するのが望ましいメソッドは出来る限り分割しない再利用するメソッドは1つのユーティリティクラスに纏めなければならないユニットテストを書いてはならないコメントとして編集日と編集者名を残さなければならないJDK1.3
これは・・・ - ぐるぐる～
梶本裕介の日記 どっかで聞いたことのある状況だw なぜそうなっているかを経験を元に予想。 リレーションを正規化してはいけない 欲しいデータは一つのテーブルにあるべきという信念。 SQLではNUMBERとVARCHAR以外の型を使ってはいけない DBMSの型とホスト言語の型の不一致による問題を避けたかった。VARCHAR*1しか使っていないプロジェクトもあったくらい。 結合はできるだけ避けること 結合によるパフォーマンスダウンを恐れている。正規化してはいけないなら、ある意味妥当かもしれないが・・・ テーブルとクラスのフィールドは1対1に対応してなければいけない O/Rマッピング的なツールの制約か何か？ 論理値を表す名前はFlagで終わらなければならない プレフィックスがダメならサフィックスを使えばいいじゃない 列挙値を表す名前もFlagで終わらなければならない プレ(ry ページの遷移はJS
第5回 クロスサイト・スクリプティング対策も忘れずに
最近問題となっているWebサイトの改ざんは，サイトの改ざん自体が目的ではなく，改ざんされたコードを参照した一般ユーザーを危険なサイトに誘導して，マルウエアを導入することを最終的な目的としている。この目的のため，HTMLのIFRAME要素やSCRIPT要素が利用される場合が多い。 先に説明したように，SQLインジェクションのぜい弱性を利用してデータベースの内容を，これら要素を使った内容に書き換えることが可能な場合がある。それでも，その内容をそのまま表示するかどうかはサイトの作りによって異なる。 一般的にデータベース中の「<」などの特殊記号をそのまま表示するとクロスサイト・スクリプティングのぜい弱性（XSS）の原因となるので，表示の際にこれらの文字をエスケープすることが行われる（図1）。 現実には多くのサイトにおいて，SQLインジェクションによって挿入されたIFRAME要素やSCRIPT要素が
便利なツール Emacs らくらく入門/meadow
Last Update: "2007/01/28 21:18:55 makoto" (準備中) Meadow Windows で Emacs Windows で Emacs を使うにはいくつかの方法があります。その中では、 日本語や、描画などを考えて Meadow を使うのがおすすめです。 http://www.meadowy.org/meadow/wiki/ 残念ながら本書では時間と紙面の関係で、Meadow の情報は割愛しています。 特に設置関係は分量が多くなってしまうので含められませんでした。 そこで、この画面でその分を補っています。 Meadow の版と Emacs は だいたい次のような関係になっています。 Emacs-21.3 と 21.4 には大きな違いは ありません。 Meadow 1.0 -> Emacs-20 Meadow 2.00 -> Emacs-21.2 Mead
要求の「誤り」を正す知恵
仕様バグの三つ目は「誤り」である。要求に漏れも重なりもない状態になっても，その要求自体が間違っていれば，使いにくいシステムができてしまう。間違いとは，例えば「部門間のデータ連携に不整合があり，面倒な手作業が発生する」「入金済みの金額を集計したいのに，契約済みの金額が集計される」といったものだ。 こうした要求の誤りを発見し，修正する知恵を学ぼう。 あり得ないモデル図 要求の誤りは図に表れることがある。「（DFDとE-R図を要求定義の標準モデルと位置付けているが）誤りがあると，『そんなことあるはずがないだろう』というおかしな図になっている。さらなる改善の候補が見えてくることもある」（住生コンピューターサービス 品質保証部 品質保証グループ長 小浜耕己氏）。 例えば，データがストアされているのに，どこからも参照するプロセスがないものがある。「データをストアするからには，何かしらの目的があるはず。
育成も考えて適材適所の配置を（260～266日）
前回に続き、プロジェクト編成の諸問題を取り上げる。目前の仕事を見てメンバーの配置を考えるだけでなく、新人や後継者の育成についてもローテーションを含めて真剣に考えることが、チームワークの強化につながってくる。 技術的に優れていても管理力に欠ける設計者がいる。大きなプロジェクトはいくら技術力があっても、自分一人で、全部をまとめることはできないため、どうしても取りまとめ力や管理力が必要になるのは当然だ。ほとんどのSEや設計者は、技術的経験を積むに従って、管理力も何とか付けられるように指導していかねばならない。 しかしなかには、どうしても管理には向かないが、技術面では優れた力を持つ人材もいる。こういう技術者に無理に管理させると、部下の仕事がやりにくくなり、やがてはモラールの低下につながってしまう。こうした人材は、本来の良さを十分発揮してもらえるよう、管理面は別のスタッフが補う工夫をしたほうが、組織
進捗度把握の主流は原価比例法
さらに課題となるのが、見積もりの精緻化だ。工事契約に関する会計基準では、成果の確実性を認める条件として「プロジェクトの『原価』と『収益』、『進捗』を信頼性をもって見積もれること」としている。 特に難しいのが売り上げを決める『進捗』の把握だ。実態と進捗度がずれて赤字案件になると、損失の見積もり額を工事損失引当金として計上しなければならない。 アンケートでは進捗の把握にどのような方法を採用するかを尋ねた。その結果「原価比例法」を採用すると回答したベンダーが、予定を含め25社以上あった。これは全体の6割強に当たる。このほか「EVM（アーンド・バリュー・マネジメント）」との回答が6社、「未定」を含む「検討中」と回答したのは6社だった（図2）。 原価比例法はプロジェクト開始時に原価総額を見積もり、実際にかかった原価から進捗度を把握する代表的な方法だ。工事契約に関する会計基準にも挙げられている。 一方
第5回 分散による「多段連携」 ～ 大規模開発への応用 | gihyo.jp
企業においてフリーソフト／オープンソースソフトを導入しようとすると、以下のような意見に反対されることがあるのではないでしょうか？ 大規模開発では使えないんでしょ？ そこで今回は、大規模開発における構成管理を効率よく運用するための、Mercurialのリポジトリ分散性を活かした、幾つかのアイディアについて説明したいと思います。 中央集約形式の問題 ある程度以上の規模の開発の場合、事前に（あるいは開発を進めながら）取り決めたI/Fを介して連携する複数の部位に全体を分割し、複数のチームがそれぞれの担当分を開発する、という進め方をするのが一般的です。 このような開発体制を採用した場合、単一サーバが全ての要求を受け付ける中央集約形式のCVSやSubversionでは、サーバの応答性能低下が懸念されます。 図1 フラットな構成 また、全ての開発者が同様にメイントランクにアクセスしていたのでは、他拠点の
Kent Beckの「Implementation Patterns」での一番気に入ってる箇所 - 未来を愛すべきこと-Javaやったり技術書読んだり
「Implementation Patterns」で一番気に入ってるのって下記の2行かもしれない。 ・コストの総計 = 開発コスト + 保守コスト ・保守コスト = 既存コード理解のコスト + コード変更のコスト + テストのコスト + デプロイのコスト 当たり前のことなんだけど、「コードを1行直すだけだから簡単でしょ！」とか言ってしまう人間がいる以上、この式はちゃんと胸に刻んでおこうと思う次第です。
Twitter/Jaiku/複数アカウント対応のミニブログクライアント「MMMMB」を作ってみた - むぉむぉ.jp
ウレタン系高反発マットレスでよく言及されるのが密度です。それを頑張って分かりやすく説明してみます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Google Code Archive - Long-term storage for Google Code Project Hosting.