データ型 - オラクル・Oracleをマスターするための基本と仕組み
(※1) Oracle 12c において、初期化パラメータ COMPATIBLE = 12.0.0.0以上、MAX_STRING_SIZE = EXTENDED でデータベースを構築またはアップグレードしておく必要がある。従来型と異なる表外格納形式、索引が桁あふれから特殊な方式になることもあってか現行のデフォルト設定ではない。(Oracle12c R2 時点) (※2) 上限が 4000 バイトの場合、UTF8(1〜4byte) 最短 1333 文字 AL32UTF8(1〜4,6 byte) Oracle 10g R2 (Unicode 4.0) では 最短 666 文字、Oracle 11g (Unicode 5.0) では 1000 文字となる。 Oracle 12c で 初期化パラメータ MAX_STRING_SIZE = EXTENDED で 構築している場合には 8191 文字が
MongoDBとRavenDBの違いから読み解く、ドキュメント・データベースごとの設計思想
MongoDBとRavenDBの違いから読み解く、ドキュメント・データベースごとの設計思想：特集：MongoDBで理解する「ドキュメント・データベース」の世界（後編） 前回の前編では、MongoDBを例にドキュメント・データベース（Document Database）の基本的な機能を見てきたが、いくつかMongoDB独自の考え方や特徴も含まれていた。今回の後編では、MongoDB以外のドキュメント・データベースとして「RavenDB」（インストールや基本的な使い方についてはこちらを参照）を見ていくことで、同じドキュメント・データベース同士での相違を簡単に確認したい。 いくつかのドキュメント・データベースを見ていくことで、同じ「ドキュメント・データベース」という共通の概念ではあるが、それぞれがどのような位置付けであるか、その相違を発見できるだろう（なお、ここではデータベースごとの機能比較表を
JSのMVCについて考えてみた ~ その2 テンプレートエンジンの分業とパフォーマンス - mizchi log
この前の続き。相変わらず思いつきでつらつら書いてて図とかまともなサンプルとかない。 JSのモデルには二種類ある フロントエンドである以上本質的にすべてビューだとも言える。 であるがゆえにあやふやにしないほうがいい。 ビューモデル UIの状態を示す属性。選択しているタブとか、開いているダイアログとか、そういうものの状態をDOMから読むのではなく、JSとして一度確定し、その結果をビューに反映すべきだ。激しく画面を組み替える場合はビューというグローバル変数はどこからも汚染される可能性がある。 データベースのローカルキャッシュ たとえば、a地点からb地点の距離をユークリッド距離を求めるのに、わざわざサーバーに問い合わせるのは無駄。普通に三平方の定理で計算すればいい。アクション性が高いものほど、ここの振る舞いは分厚くなる。いわゆるHTML5アプリはここを重点的にやるほどサーバーの負担が減り、サーバー
Webアプリケーションを高速化する50のトリック
MicrosoftのInternet Explorer PMであるJatinder Mann氏は、BUILD 2012でHTML5アプリとサイトを高速化する50のパフォーマンストリックというセッションで、Webアプリケーションを高速化する多くのチップスを提供した。 Mann氏が提供したアドバイスは、以下の6つの原則を中心に構成されていた。 1. ネットワークリクエストに迅速に応答する リダイレクトを避ける。上位1,000のWebサイトのうち63%は、リダイレクトを使用している。これらはリダイレクトをやめることによって10%のパフォーマンスを改善することができる。 メタリフレッシュを避ける。世界のURLのうち14%は、メタリフレッシュを使っている。 可能な限りユーザーの近くにあるCDNを使用してサーバーの応答時間を最小化する。 異なるドメインからのリソースをダウンロードすることによって、同時
コラボレーション・パターン ― 創造的コラボレーションのためのパターン・ランゲージ
創造的コラボレーションを実現するための共通言語を。 コラボレーション・パターンは、「創造的コラボレーション」の秘訣を言語化したものです。創造的コラボレーションでは、メンバーが高め合い成長しながら、個人には還元できないチームレベルの「創発的な勢い」に乗り、世界を変えるような成果を生み出します。そのようなコラボレーションのデザインにおける視点や方法をまとめたものが、コラボレーション・パターンなのです。ぜひ、みなさんのプロジェクトやグループワークに、ご活用ください。 ツイート コラボレーション・パターンは、毎日twitter配信をしています！ 創造的コラボレーションの秘訣をまとめた「コラボレーション・パターン」(Collaboration Patterns) を定期的につぶやいてくれるtwitter botを用意しました。感想やRT、大歓迎です！ぜひ、コラボレーション・パターン on Twitt
第7回 クライアントとサーバのコード共有を促進するデータベースアーキテクチャ | gihyo.jp
従来のWebアプリケーションでは、フロントエンドとバックエンドは完全にコードが分離しているのが普通でした。そして、フロントエンドとバックエンドでは扱う言語が異なるのも一般的です。フロントエンドではJavaScript、バックエンドではJava、Perl、PHP、Python、Ruby、などの言語を用いていたのです。こうしたフロントエンドとバックエンドの断絶があったことから、両者の間ではコードの共有が行われることはほぼありませんでした。エラーメッセージのような、両者で統一して取り扱うべきリソースを共有するのも一苦労でした。 しかしMeteorでは、サーバもクライアントもJavaScriptで記述するというアーキテクチャを取っていることから、サーバとクライアントの双方で多くのコードを共有することができます。特にMeteorは、クライアントとサーバでできる限り同様のコードが動作するよう考えられた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Charming Python: Functional programming in Python, Part 3
IBM Developer