WhatThreadsafeRailsMeans - スレッドセーフな Rails ってどういうこと?
WhatThreadsafeRailsMeans - スレッドセーフな Rails ってどういうこと? 目次 この文書について Q/A: スレッドセーフな Rails ってどういうこと? Q: Rails がスレッドセーフになるってどういうこと？ Q: なぜこれが重大なの? もう 複数プロセスで shared-nothing なRailsのアーキテクチャで 並列性はあるんじゃない? Q: じゃあ Ruby や Ruby EE, Rubinius みたいなグリーンスレッドの実装は, スレッド対応の恩恵は何もないの? Q. なるほど, じゃ JRuby みたいなネイティブスレッドの実装はどうなの ? Q: それってすごいの? スレッドセーフな Rails ってどういうこと? この文書について "Q/A: What Thread-safe Rails Means" の日本語訳です http://
dpinfo.html
目次 はじめに Abstract Classパターン Abstract ClassパターンRuby版 (by 助田雅紀さん) Balkingパターン Before/Afterパターン Futureパターン FutureパターンRuby版 (by 助田雅紀さん) Generation Gapパターン Hook Operationパターン Hook OperationパターンRuby版 (by 助田雅紀さん) Immutableパターン Marker Interfaceパターン Monostateパターン MonostateパターンRuby版 (by 助田雅紀さん) MonostateパターンPerl版 (by 宮川さん) Null Objectパターン Null ObjectパターンとSingletonパターン Producer-Consumerパターン Sharableパターン Singl
BrewersCapTheorem - ブリュワーの CAP 定理
BrewersCapTheorem - ブリュワーの CAP 定理 目次 この文書について ブリュワーの CAP 定理 - Amazon と eBay のクールエイド ブリュワーの(CAP)定理 一貫性 (Consistency) 可用性 (Availability) 分割耐性(Partition Tolerance) 定理の重要性 図解で証明 CAP と折り合う 1. 分割耐性を諦める 2. 可用性を諦める 3. 一貫性を諦める 4. BASE に跳ぶ 5. 問題をかわして設計する まとめ 参考文献 ブリュワーの CAP 定理 この文書について "Brewer's CAP Theorem - The kool aid Amazon and Ebay have been drinking" の日本語訳です. http://www.julianbrowne.com/article/view
EfficientJavaScript - Dev.Opera - 効率的な JavaScript
EfficientJavaScript - Dev.Opera - 効率的な JavaScript 目次 この文書について 効率的な JavaScript ECMAScript eval や Function のコンストラクタを使うのはやめよう eval を書き換えよう 関数を使いたいなら function を使おう with を使うのはやめよう 性能を決める関数で try-catch-finally を使うのはやめよう eval と with は隔離しよう グローバル変数を使うのはやめよう 暗黙のオブジェクト変換に気をつけよう 性能を決める関数で for-in を使うのはやめよう 文字列は累積スタイルで使おう プリミティブの操作は関数呼び出しより速い setTimeout() や setInterval() には文字列でなく関数を渡そう DOM 再描画と再フロー 再フローの回数をでき
WritingTestableCode - テストできるコードの書きかた
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
Net::FTPの練習
朝、ふと思い立ってNet::FTPの練習をしてみようと思う。 perldoc cpan でCPANの使い方を調べ、 perl -MCPAN -e shell; と実行してみると、cpan> というプロンプトが現れるので、 CPANのインタラクティブモードに入った(ようだ)。 そこでおもむろに、 install Net::FTP と入力すると何やらごちゃごちゃと表示されてCPANからダウンロードを試みる。 しばらくすると自分でテストをはじめOKだよ、と言われる。 次に、 perldoc Net::FTP と入力してモジュールの使い方を調べる。 試しにホームページのindex.htmlをgetしてみる。 以下のようなスクリプトを書く。 use Net::FTP; $ftp = Net::FTP->new("my.host.name", Debug => 1); $ftp->login("myl
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
[結] 2007年6月 - 結城浩の日記 - ルートの無限入れ子クイズ
目次 2007年6月30日 - 無料プレゼント（『数学ガール』＋「時をかける少女」主題歌）を発送しました / 2007年6月29日 - 仕事 / 2007年6月28日 - 『数学ガール』アマゾン在庫切れ→復帰 / 2007年6月26日 - 数学ガール / 2007年6月25日 - 月末繁忙期 / 2007年6月24日 - まつもとゆきひろさんと対談しました / 2007年6月22日 - 完全な準備という幻想 / 2007年6月21日 - 高校二年生の感想文『数学ガール』 / 2007年6月20日 - 私信 / 『数学ガール』へのメッセージ(10) : 友人との会話が思い出そのものです / 2007年6月19日 - ルートの無限入れ子クイズ（解答編） / 2007年6月18日 - サイドフィードさんからメールをいただいた話 / 『数学ガール』へのメッセージ(9) : 何とも懐かしい気持ちにな
[結] 2007年5月 - 結城浩の日記 - 自動書記
目次 2007年5月31日 - 5月も終わりですね / 2007年5月28日 - 『数学ガール』再校読み、カバーデザインなど / 2007年5月27日 - 日経ソフトウエアで新連載「かんたんWebレシピ」がはじまりました / 2007年5月25日 - 月末繁忙期 / 2007年5月22日 - 今日は何をやったっけかな / 2007年5月21日 - 結城浩のYahoo!日記を更新 / 2007年5月20日 - 日曜日 / 2007年5月18日 - 『数学ガール』の初校読み合わせ / 2007年5月17日 - 本のために祈る / 2007年5月16日 - 校正は続く / 仕事 / 2007年5月15日 - コメントspam / 2007年5月14日 - 仕事 / 2007年5月11日 - 私信 / 『数学ガール』初校が出てきました / 2007年5月9日 - spam対策 / 仕事 / 自動書
はてなダイアリーライター（略称：はてダラ）
はてなダイアリーライター（はてダラ）は、 ローカルに作った 2004-08-19.txt のようなテキストファイルを、 はてなダイアリーの日記として自動書き込みするコマンドラインツールです。 ご連絡: (2009-09-12) スクリプトをGithubで管理はじめました。(hatena-diary-writer) ご連絡: (2009-08-04) はてダラがhttpsなページでうまく動かない 目次 詳細目次 はじめに インストールと基本的な使い方 「はてダラ」スクリプト本体のダウンロード コマンドラインオプション 設定ファイル ちょっとしたコツ よくある質問(FAQ) 「この環境で動きました」情報 関連ツール: はてダラスプリッタ(hws.pl) 更新履歴 関連リンク 作成メモ ぜひ、感想をお送りください 詳細目次 詳細目次 はじめに インストールと基本的な使い方 「はてダラ」を動かすの
Web日記を書く心がけ
Web日記について。 「結城浩の日記」もそうだけれど、Web上で公開されている日記は非常に多い。 個人でWebページを持つ場合、 仕事ででもない限り、そうそう書くネタはない。 そんな中で更新頻度を上げ、 リピータに楽しんでもらうためのよい方法が「日記」である。 やっぱり毎日（あるいは週に数回でも）更新されているページは 頻繁に訪れたくなるものだ。 日記を書く心がけ、 などというものは各人が考えればよいわけだが、 私がどう考えているかを少し以下に書く。 正直な気持ちを書く。 建前ばかりとか（まあそれも大事ですが）、 人の受け売りだけが書かれていると、読者もやっぱりつまらない。 正直な気持ち（うれしいとか、かなしいとか）をそのまま出しちゃった方がいいように思う。 文章の体裁はあまり気にしないこと。 少しくらいねじれた文章があってもあまり気にしない。 それよりは、勢いというか、生きている感じとい
[結] 2007年4月 - 結城浩の日記 Yahoo!ブログ連載、結城浩のYahoo!日記（コミュニケーションのヒント）が始まります
目次 2007年4月30日 - affiliate.amazon.co.jpの証明書が期限切れのようです / 2007年4月29日 - 今日という一日 / 2007年4月28日 - Yuki::CGIを使って「Yahoo!ブログ」のRSSを表示するWebアプリを作る / 2007年4月27日 - 仕事 / 2007年4月26日 - Web連載を使って試みる文章の書き方 / 結城浩のYahoo!日記、オープン！ / 2007年4月25日 - 仕事 / 2007年4月24日 - 家 / 書くのは楽しい / 2007年4月23日 - Tie::DBI / 『Java言語で学ぶリファクタリング入門』の読者さんから / はてな経由でいらした読者さんへ、読み物はこちらにあります / 仕事 / 結城浩のYahoo!日記への反応 / 2007年4月22日 - 日曜日 / 励ましの言葉 / 2007年4月2
技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
練習問題 / 自分のもっともよいものを惜しみなく与えよう
私が書くプログラミングの書籍には練習問題がよく登場する。 そして必ず解答がつく。 なぜかというと、解答がないと独学している読者が困るから。 解答はヒントだけではいけない。 出来不出来はさておき、ちゃんと解答になっていなければならない。 なぜかというと、読者が困るから。 それから、読者を「出し抜こう」とする問題はよくない。 著者は読者に対して優越感を感じるために本を書くのではないからだ。 著者は読者に何かを伝えようとして本文を書く。 そしてその「何か」が伝わったかどうかの確認のために練習問題を書くのだ。 練習問題は知識の確認のためだけにあるのではない。 練習問題を解くことは新たな何かを学ぶ機会でもある。 練習問題を頑張って解いた人、解こうとした人の頭は活性化している。 その状態になっている人には、新しい情報・新しい知識を伝えやすい。 それに頑張った読者には「ごほうび」があってしかるべきではな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
