記事更新時間を減らすために私が工夫している６つのこと*二十歳街道まっしぐら（FC2ブログ時代）
私のサイト更新の仕方についてのエントリーです。 サイトを最近始めた方、もっと記事を素早く書きたい方に参考になればと思います。 とは言っても、以下の内容は私のサイトでの更新スタイルなのでみんながみんなに合うとか限りません。 多少工夫して更新していますので、紹介したいと思います。 もっとこうすれば早く更新できるよ！っていうのがあれば教えてください。 うちのサイトの記事はおおかた１５分～２５分で書いています。 更新しようと思いったってから記事完了までの時間です。 何も工夫せずに更新すると下手すると１時間以上かかります。 個人的に「なるべく早く更新したい」と思っているので色々と工夫を凝らしたら約２０分で更新できるようになりました。 それでは以下に工夫したところをいくつか紹介します。
| ＾＾ |秒刊SUNDAY | WEB開発者がSleipnirを絶対に使ってはいけない７つの理由
2009年04月29日 WEB開発者がSleipnirを絶対に使ってはいけない７つの理由 カテゴリ：WEBデザイン Sleipnirは使いやすい、すばらしい･･･などと絶賛するユーザがいますが、果たして本当にそうなのでしょうか、私はそれは有り得ないと断言します。 ◆読む前に WEB標準だの、コーディングだのAcidだの･･･訳がわからない方は、そのままSleipnirを使っていてOKです。 判りやすく言うと、SleipnirはアナログSafari、Firefoxなどは地デジぐらいの違いがあります。 という説明をしますので、開発者以外の方には『ふーん』程度に思っていてください。 では。 １：表示結果がWeb標準でない。 上の写真は、左から『Firefox、Safari、IE6、Sleipnir』をAcidという確認ツールで見比べた結果です。 Firefox、Safariについてはほぼ同じ
デッドロックを回避するための方策
DBアプリケーションを作成する際、デッドロックを回避するために考慮すべき点のまとめ。 ここに書くことは、今までの経験 (Oracle) を思い出し、「こうすればコーディング時点でデッドロックを回避出来るんじゃないか」と、捻り出したので、多少間違いがあるかもしれません。 後日、PostgreSQLにて検証してみようと思います。 1. 同一トランザクション内の複数テーブルアクセス デッドロックの説明でもっともわかりやすい基本的な例として引用されるパターン。 例えばA, Bというテーブルがあるとき、二つのトランザクションで トランザクション1 : A -> B トランザクション2 : B -> A の順にテーブルの更新アクセスをしていると、同時にアクセスされた時にデッドロックとなる。 （実際は同一レコードに対してアクセスした場合） 対策： ・ コーディング規約として、同一トランザクション内のテー
SQL Serverで「デッドロック」を回避する
ロックの仕組み（その2）－オブジェクトのロックタイプ 前回「第27回 トランザクションの一貫性を保証するロック」は、トランザクションの4つの分離レベルの説明をしました。今回は、この分離レベルを実現するデータベースサーバのロック機構に触れてみましょう。実際にどのような仕組みでデータベースサーバがロック制御を行っているかを理解することで、トランザクション機能を利用した際に起こりやすい問題点を、あらかじめ予測できるようになると思います。 今回は、初めに、ロックの状態を取得するシステムストアドプロシージャ「sp_lock」の定義を若干拡張した「sp_lock_detail」ストアドプロシージャを作成しましょう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
5.6. テーブルの変更