[PDF] 調査報告書 平成２２年８月２０日 特許庁情報システムに関する調査委員会
調査報告書 平成２２年８月２０日 特許庁情報システムに関する調査委員会 目次 第１部 調査の経緯及び目的 ・・・・・・・・・・・・・ １ 第２部 事実関係の解明及び再発防止策について （事実解明チーム担当） ・・・・・・・・・・・・・ ３ 第１ 事実解明チームの調査方法等 ・・・・・・・・・・ ３ 第２ 事実関係 ・・・・・・・・・・・・・・・・・・・ ５ 第３ 法的検討 ・・・・・・・・・・・・・・・・・・・２２ 第４ 再発防止策の提言 ・・・・・・・・・・・・・３３ 第３部 特許庁情報システムの技術的検証及び今後 の開発に向けての提言（技術検証チーム担当） ・３８ 第１ 技術検証チームの目的、検証対象及び検証方法 ・３８ 第２ 最適化プロジェクトの概要 ・・・・・・・・・・４０ 第３ これまでの設計の経緯 ・・・・・・・・・・・・・４７ 第４ 「設計成果物」の技術的検証 ・・・・・・
Webサイトの制作スピードを、より向上させる目的で作られたスターターキット・99lime
結構参考になったので備忘録がてら ご紹介。Webサイトの制作スピードを より向上させるために、汎用的なUI を集めて、マークアップも綺麗な状態 で済むように設計されたスターター キット、というかフレームワークです。 制作スピードを向上させる目的で作られたHTML5フレームワークです。レイアウトだけでなく、汎用的なUIも備わっていて、class名1つ付けるだけでタブやスライドショーを実装出来るようになっています。 そういった仕様にする事で、シンプルで綺麗で可読性の高いソースを保てるように設計されていたりと、結構参考になるスターターキットですよ。フレームワークは自作してるので良い部分を組み込んでみようかなと思いました。 タブやドロップダウン、スライドショーなどを備えているだけでなく、class名1つで実装出来るようになっているので、綺麗なソースを保持する事が出来るようになっています。 いろいろ
Re: @kazuho: handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] - blog.nomadscafe.jp
handlersocket plugin や mycached を使えば memcached は不要か、それとも使うべきケースがあるか。考察せよ [10点] kazuho (Kazuho Oku) http://twitter.com/kazuho/status/21477219149 考えて答えてみる。 HandlerSocketやmycachedを利用し、MySQLへの接続数が数万単位で行えるようになったり、より多くのクエリ数が発行できるようになっても、memcachedは不要ではないし、使うべきケースもあります。 memcachedは単なるKVSではなく、ExpiresとLRUがついたキャッシュサーバです。キャッシュオブジェクトには期限を付ける事ができ、期限が過ぎたキャッシュは無効にされ、またアクセスがされていない不要になったオブジェクトは削除され、空いたスペースは新しいキャッシュオ
継続開発のススメ - Twisted Mind
概要 開発をすればリリースがあり、リリースが終われば開発があります。継続開発をする以上はリリースと開発の繰り返しです。 開発手法やリリース手段は沢山あるのですが、あまりしっくりくるものが無かったので自分でまとめてみました。 これで完璧というものは残念ながらこの世にないと思うので、これからも臨機応変に良い流れを作って行ければと思います。 この文章は以下のような構成になってます。書き殴りですみません。 バージョンの付け方 ソースコード管理とリリース タスク駆動 環境方針 定義 いくつか事前に定義しておかないと話しが訳わからなくなりそうなので。 バージョン管理には git を採用しています。 開発というのはコードを書く事だけを指してはいません。 ここでいうフレームワークは「自身で開発している」として扱います。そうしないとちょっと難しいので。 ライブラリは自身の開発とそれ以外があると思いますので、
1-byte.jp - CakePHPを使ったテスト駆動開発
ブログ初ポストはCakePHPを使ったテスト駆動開発です。 CakePHPはユニットテストとしてSimpleTestに対応しています。 SimpleTestをインストールするだけで、モデルやコントローラ、シェル、ルーティングクラスなどのユニットテストが出来るようになります。 今日はこのCakePHPとSimpleTestを使ってテスト駆動開発の流れを説明します。 ただ、僕自身テスト駆動開発を学んだのは去年のCake祭りなので、至らない点が多々あります。 もし何かあれば、コメントでご指摘ください。 今更感もありますが、この場を借りてCake祭りでテスト駆動の指導をしてくださった、@sizuhikoさんに感謝します。 開発手順 まずは開発手順を示します。少し細かいですが、テスト駆動では以下のような順で開発していきます。 設計する。 テストケースを書く。 テストケースをデバッグする。 コー
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
Googleのdesign docを眺めてみる - kenmazの日記
http://steps.dodgson.org/?date=20090705より。 Google社員によるWebKitのWeb Socketに関するdesign docがchromeの開発ML上で公開されている事を知った。 WebKit Web Socket design doc http://docs.google.com/View?id=dfm7gfvg_0fpjg22gh 鵜飼さんなど日本人Googlerによるdesign docらしい。 Googleの講演などでdesign docをよく書く文化があると言う事は知っていたが、実際に見るのははじめて。このdocの場合だいたい以下のような構成になっている。 目的 Web Socketでブラウザ＝サーバー間双方向通信のための新しいAPIを定義するよー 背景 Ajaxとかでブラウザ＝サーバーの双方向通信をよくやっているけど、httpを無理
CakePHPアプリケーションの基本的な設計指針 (1) - URL設計 - - ２４時間CakePHP
イントロダクション CakePHPはMVCデザインパターンを採用しており、基本的にこれに従った設計が基本となります。 しかし、ある程度開発が進んだところで、やっかいな設計の問題にぶち当たることは多いですよね。 そこで、よくある問題を取り上げて、設計の指針としてまとめてみることにします。 注：とても1回で書ききれるとは思えません。連載となる可能性が高いです。 URL設計 CakePHPのURLは、最初は独特に見えたかもしれません。 http://example.com/users/view/1 などよりも、http://example.com/user/hiromi2424 などの見栄えを期待していた方も多いのではないでしょうか。 しかし、だからといって以下のようなアクション、URLの呼び出し方は、後々に響いてきます。 <?php // Route Router::connect( '/us
［Google App Engine編］大量データの処理はかかる時間に注意
Google App Engineで大量データを処理する場合、特別な配慮が必要になります。処理時間の制限など、独特の制約に引っ掛かる恐れがあるからです。 大量データを扱うケースとして、テーブルのスキーマ変更、検索結果のダウンロードなど、データの一括処理という三つについて、それぞれの設計ノウハウを解説します。 スキーマのバージョンをフィールドに持つ 一つ目の設計ノウハウは、テーブルのスキーマを変更する際に効果があるものです。 稼働中のシステムにおいて、機能を追加・変更する際、テーブルのスキーマ変更が必要になる場合があります。スキーマの変更に備えて、Google App Engineでは、RDBベースの場合とは違った設計が必要になります。「スキーマのバージョンをフィールドに持つ」というものです。 Datastoreはそもそも、同じテーブル内で、異なるスキーマのレコードが混在していてもかまわない
そこそこ規模が大きくても何とかなるjavascriptの設計（URL dispatcherの薦め） | tech.kayac.com - KAYAC engineers' blog
弁当生活始めました。agoです。 以前のjavascriptの開発はサーバサイドと同じPGが開発することが多く、機能をファイル単位で分割してそのページで必要なファイルのみを読み込むと言うことが行われていました。 ただ、最近はサーバサイドとクライアントサイドの分業が進んだことや表示速度の兼ね合いもあり、単一ファイルに全体を記述しサーバサイドでは全ページでその一ファイルのみを読み込むような形になることが多いです。 単一ファイルの利点としてはサーバサイドの実装に依存せずに任意の機能を追加できることがありますが、欠点として機能毎の切り分けが難しくなると言う点があります。 jQueryを使用して$('.selector')で切り出す方法もありますが、マークアップの全体像を正確に把握できていないと不要なページで間違って実行されてしまう危険性もあります。 そこで、以下のようなJSを先に読み込み、各URL
ソーシャルゲームのためのMySQL入門その２ | BLOG - DeNA Engineering
こんにちはこんにちは。11インチMacBook Airが欲しくてたまらないiwanagaです。 前回の記事 が幸いにもご好評を頂けた様で非常にうれしいです。嬉しくなって、ついがんばって第２弾を書いてしまいました。引き続き、ソーシャルゲームでよく使われるテーブルタイプ毎にちょっとしたテクニックを紹介していきます。 今回はちょっとライトな感じ＆読み物になってしまっていますが「ユーザID単位で1つだけ持つデータ」と「パラメータなどのマスターデータ」についてご説明したいと思います。ちなみに次回はInnoDBのデータ構造の簡単な説明と複合プライマリーキーのデータについて、その次で紹介し損ねたちょっとマニアックなテクニックや性能管理のための手法を紹介することを予定しています。 その前に。。。 先日行われた JAPAN INNOVATION LEADERS SUMMIT で弊社松信が「ソーシャルゲームの
ソーシャルゲームのためのデータベース設計 まとめ - お笑いプログラマの技術メモ
ソーシャルゲームを作る時に参考になるデータベースやKVSの選定、設計などの記事やスライドのまとめ 2013-02-03追記 スライド ソーシャルゲームのためのデータベース設計 http://www.slideshare.net/matsunobu/ss-6584540 とあるアプリの開発運用(トラブルシュート) http://www.slideshare.net/takafumionaka/ss-5852561 PHPで大規模ブラウザゲームを開発してわかったこと http://www.slideshare.net/ketaiorg/php-4638298 Lampで作るソーシャルアプリの負荷対策〜アプリとインフラの調和のテクニック〜 (Klabさん) http://www.slideshare.net/klab/4-d6963726f736f667420506f776572506f696e
ke-tai.org > Blog Archive > OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」
OSC 2010 北海道の発表で使用したスライド資料「PHPで大規模ブラウザゲームを開発してわかったこと」 Tweet 2010/6/28 月曜日 matsui Posted in PHP, お知らせ | 7 Comments » 先日6月26日、札幌で「オープンソースカンファレンス2010 北海道」が行われ、無事終了することができました。 当日は来場者数が過去最高の約450名となり、閉会式は会場に収まりきらないくらいの大盛況でした。 ご来場者の方々、スタッフ・事務局の方々、本当にありがとうございました。 私も1コマセミナー枠を戴くことができまして、弊社で「ブラウザ三国志」というゲームのプログラム開発を行った際の苦労やノウハウなどをまとめた、「PHPで大規模ブラウザゲームを開発してわかったこと」という発表を行わせていただきました。 お越しいただけなかった方のためにも、その際に使用したスライ
[ThinkIT] 第5回：教科書的ではなく、現場にあったデータベース設計のコツ (1/3)
前回はデータベース設計をする際に誰もがぶつかる問題である、「列名に日本語を使うか？」「どのデータ型を使うか？」ということをテーマに取りあげました。今回も引き続き、データベース設計をする際に迷いやすい点をいくつか取りあげてみようと思います。 今回は前回と同様、SQL Serverのサンプルデータベース「Northwind」を元にして、データベース設計で迷いやすい点について考えてみましょう。図1は「Northwind」をER図にリバースした中から、エンティティ「商品」「商品カテゴリ」をサブウィンドウで表示したものです。 図1のように商品を分類するためにカテゴリコードをつけるエンティティ構造はよくあります。しかし実際の販売管理システムにおいては、このようなフラットなカテゴリ構造は不便です。なぜかというと、一般に商品カテゴリなどは表1のように階層構造で分類する必要があるからです。 01 ハードウェ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
