来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
![マルチコア時代のサーバ設計について - Happy Hacking Diary](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
来年も作りたい!ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Health Insurance High Speed Internet Work from Home Healthy Weight Loss Best Penny Stocks Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
以下の文章は、Martin Fowler による Domain Logic and SQL の日本語訳である。 データベース指向ソフトウェア開発者とメモリ上(in-memory)アプリケーションソフトウェア開発者との間のギャップは、ここ数十年、徐々に広がってきている。このギャップが原因で、データベースの機能(SQLやストアドプロシージャ)をどのように扱えばよいのかという議論が数多く巻き起こっている。ここでは、ビジネスロジックを SQL に置くべきか、それともメモリ上のコードに置くべきかといった問題について、主にパフォーマンスと更新性の観点から考察を行う。考察には簡単な例を使うが、SQL クエリはしっかりとしたもの(rich SQL queries)を用いるので悪しからず。 エンタープライズアプリケーション(訳注:以下、EA)構築に関する本(私の近著『P of EAA』など)を読むと、ロジッ
高木浩光氏からの批判の一つは、数値リテラルをシングルクォートで囲むことに対する論拠のあいまいさであったように思う。 「性能的にも不利だし」 < 性能の影響は皆無。問題はそこではなく、挙動がSQL仕様で定義されているか。 以下にもう少し掘り下げて考察してみよう。 SQL仕様でどう定義されているか? 以下のようなSQLで、列IDがint型であると仮定しよう DELETE FROM DOCUMENTS WHERE ID=1 この数値リテラル1をシングルクォートで囲んだ場合の動作はどう規定されているか? DELETE FROM DOCUMENTS WHERE ID='1' 今手元にJIS SQLなどの規定がないので記憶に頼って書くしかないが、このような場合は、varchar型などの文字型から、int型への「暗黙の型変換」が実施される。つまり、'1'という文字列は、1という数値(整数)に変換されてか
っぽいですね。 Djangoはコメントにもらったこのページに「一つのオブジェクトには一つしか主キーを指定できません」て書いてあります。 SQLObjectも主キーは1つしか対応してません。なのでTurboGearsも無理。 http://ymasuda.jp/python/sqlobject/doc_0.7/SQLObject.html 「SQLObject は複数カラムからなる主キーをサポートしません (この仕様は恐らく今後も変わらないでしょう)」だそうです。 うーん、既存スキーマが自然キー使っちゃってる場合ってまだまだありそうなんですが、そうするとPython系はいきなり選択肢から外さざるを得なくなりますねえ。 この辺は技術じゃなくて、ロビー活動(ていうか要件調整)で既存スキーマに依存しなくてもよいようにするしかないですね。でも既存スキーマをいじらなければいけない状況もあると思うと、R
Webサーバーも順調に増えた、となると次はデータベースが悲鳴を上げる頃です。データベースの増設と行きましょう。 はてなではデータベースにはMySQLを利用しています。MySQLは組み込みでレプリケーションをサポートしているので、これを使わない手はありません。レプリケーションを行い、マスターDBのコピーであるスレーブDBサーバーを作り2台構成にします。 レプリケーションは、データベースを複数台に増やし、且つその複数のデータベースが保持するデータを同期させるための仕組みです。レプリケーションされたデータベースのうち、元々あったデータベースが親、それ以外が子という親子関係になります。 親はマスター、子はスレーブと呼ばれ、マスターへの更新処理と同じ処理をスレーブに伝播させることでデータの同期が行われます。実際にはマスターからスレーブへ処理が伝播するのではなく、スレーブがポーリングを行ってマスターと
ページが見つかりません。 目的のページは、移動または削除によって無効になっている可能性があります。申し訳ありませんが、検索またはリンク先よりお探しください。
Rails 勉強会に参加した。前半は、RSpec 後半は ActiveRecord に関するセッションだった。 たまたま二つとももろはしさんオーナーのセッションだった。 RSpec に関しては、もろはしさん熱い布教活動(?)を受けた。私の理解では、RSpec は JUnit のようなテストユニットに似ているが、Behavior Driven Development (BDD) という考え方に基づいて作られており、テストというより仕様を機械的に記述することを目標にしているようだ。思想的な背景はよくわからないが、アジャイル開発におけるテスト駆動開発を思想的に純化させたもののように思える。なかなか興味深かった。 もろはしさんは、ActiveRecord の関連テーブルがらみでいろいろ不明な点を持っていたらしく、それを検証するのがセッションのメインとなった。たしかに私にとっても、has_many,
Hibernateは業務用アプリとかで出てくる、楽観的ロック機構を標準でサポートしていますので、その機能を試してみました。楽観的ロックとは、複数のトランザクションが同じrowを更新しようとしたときに、それを検知する仕組みです。検知とは、先勝ちしたり、後勝ちしたりといろいろあるみたいですが、後にコミットかけた方で例外が発生する、が一般的なのではないでしょうか。 実装方法は対象のテーブルにバージョンカラムを設けて、更新されたらインクリメントされるようにしておきます。で、それぞれのトランザクションが更新するときに、検索時のバージョンの値と、更新時のテーブルのバージョンの値を見比べて、同じだったら誰も更新されていない、違ったら誰かが更新している、ということを検知するわけです。 対象テーブルの情報 † さて実験ですが、複数のトランザクションである同じrowを検索してきて、それをそれぞれのトランザクシ
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)(「ICANNがレジストラとして認定した企業」一覧(InterNIC提供)内に「Japan」の記載があるもの)を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く