書籍『数学ガールの秘密ノート／式とグラフ』サイン本情報 - [結] 2013年7月 - 結城浩の日記
目次 2013年7月27日 - 「数学ガール」を読み始めてから，楽しくて止まらなくなって…（読者さんの感想） / 2013年7月26日 - Knuth先生から小切手をいただきました！ / 2013年7月23日 - CodeIQでアルゴリズムの問題を出しています（賞品あり） / 2013年7月20日 - 数式とお話ができるようになった気がします（『数学ガール』読者さんの感想） / 2013年7月17日 - 書籍『数学ガールの秘密ノート／式とグラフ』刊行中！ / 2013年7月12日 - 書籍『数学ガールの秘密ノート／式とグラフ』サイン本情報 / 2013年7月10日 - 書籍『数学ガールの秘密ノート／式とグラフ』はもうすぐ刊行！ / ぜひ、感想をお送りください 日記一覧 2013年7月27日 ■ 「数学ガール」を読み始めてから，楽しくて止まらなくなって…（読者さんの感想） 2013年7月27
うねりコード - 【アンチパターン】遠くから見ると、画面上でコードがうねっている。
うねりコード - 【アンチパターン】遠くから見ると、画面上でコードがうねっている。 【アンチパターン】遠くから見ると、画面上でコードがうねっている。 http://www02.u-page.so-net.ne.jp/xa2/senoh/98-03-c.htm#98-03-17 にあったのですが、もうないようです。 Google Cache http://www.google.com/search?q=cache:iLHk_SecF7oC:www02.u-page.so-net.ne.jp/xa2/senoh/98-03-c.htm+&hl=ja&ie=UTF-8&inlang=ja#98-03-17 に残っていたものを引用します。 98/ 3/17 (火) うねりコード 大学時代に私の同期のN村がモニタを見ながら、「悪いコードは遠くから見てもわかるんだよ、ほら、うねってるだろ」と言っていた
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
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
Web版「数学ガール」: 数学ガールのアンビグラム
ミルカさんシリーズは、 『数学ガール』として書籍化されました。 書籍版では、 Web未公開の章が多数含まれ、 また、Webで公開している分も、 はるかに読みやすく、わかりやすく再構成されています。 これまで公開していた内容はWeb版として継続して公開しますが、 ぜひこの機会に書籍版をお読みください。 饒舌なミルカさんと、寡黙な「僕」との数学的対話です。 回を追うごとに長くなり、数学の割合が減り、ラブコメ率が高くなっているという噂もありますが、 数学的内容はいたって真面目、きわめて真剣です。 《理系にとって最強の萌え》目指してがんばっております。 1. ミルカさん (2004年) 「回転」についての対話。 2. ミルカさんの隣で (2005年) 差分と微分についての対話。 離散系バージョンの関数探しも合わせてどうぞ。 3. ミルカさんとフィボナッチ数列 (2005年) フィボナッチ数列の一般
WebHooks - Web hooks
WebHooks - Web hooks 目次 この文書について Web hooks Web hooks この文書について "Web hooks" の日本語訳です http://blogrium.com/?p=70 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... このあいだ, ウェブアプリケーションの生態系に関するあるすごいことに僕は気がついた. それからというもの, 僕は頭の良い人とあうごとにその考えをぶつけてきた. ブログにも書こう書こうと思っていたけれど, あいにく僕はきちんとしたブロガーではなかった. とある事情があって, ようやくその話を書くことにした. そのアイデアは, 僕がウェブフック(web hooks)と呼んでいるものだ. すごく簡単なサーバサイドの仕組みで, ウェブアプリケーションのユーザが自分のデータを自分の好きなようにできる. 開発者は,
ECMAScriptHarmony - ECMAScript Harmony
ECMAScriptHarmony - ECMAScript Harmony 目次 この文書について ECMAScript Harmony 要旨 詳細な声明 ECMAScript Harmony この文書について "ECMAScript Harmony" の日本語訳です https://mail.mozilla.org/pipermail/es4-discuss/2008-August/003400.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... s/渡し/私/ しました。 s/geter/getter/ しました。 JavaScript の標準化を主導する Ecma の 第 39 技術委員会 (TC39) で, この一年間不 和が続いているのは公知の事実です. 一部のメンバーはECMA-262 の第四版である ES4 を推しています. また別のメンバーは既存の
はてなの伊藤直也さんにお会いする - [結] 2009年1月 - 結城浩の日記
目次 2009年1月31日 - 土曜日 / 2009年1月30日 - 金曜日 / 2009年1月29日 - 『数学ガール』と『数学ガール／フェルマーの最終定理』がダブルで増刷になります / 木曜日 / 2009年1月27日 - リファクタリング入門 / 火曜日 / 2009年1月26日 - 月曜日 / 2009年1月25日 - 日曜日 / 2009年1月24日 - 土曜日 / 2009年1月23日 - 金曜日 / 『プログラマの数学』が増刷になります！ / オバマさんの演説 / 2009年1月22日 - 木曜日 / 2009年1月21日 - よよPさんの「数学ガール」の着うた(R)/着うたフル(R)がドワンゴさんから配信中！ / 水曜日 / 2009年1月20日 - 火曜日 / 2009年1月19日 - 月曜日 / 2009年1月18日 - 週刊東洋経済の書評欄に『数学ガール』が載る予定
バグレポートはこう書け - バグレポートのための単文集
バグレポートはこう書け - バグレポートのための単文集 バグレポートのための単文集 send-pr とか bugzilla に投げるときとか、なんて書いて いいのかわからんのよね。 というわけで、とにかくいろんな文章をまとめてみる。 心構え バグレポートの目的は何か? バグを伝えることである。 よりよい英語を書くのが目的ではない。拙い英語でもいいから、 とにかく書け。ネイティブスピーカーなら、変な英語でもそれはそれで通じる。 日本語ネイティブは FreeBSD-users-jp:72469 を理解できるっしょ? それと同じ。 I'll take a look at this, as inetd is my problem. (inetd のバグレポートを受けて) inetd の件は俺が仕込んだバグなので、このレポートの面倒みるよ 異議なーし No objection from me. 2台
HowGoogleEarthReallyWorks - Google Earth の <ほんとの> 仕組み
HowGoogleEarthReallyWorks - Google Earth の <ほんとの> 仕組み 目次 この文書について Google Earth の <ほんとの> 仕組み パート1 終幕: 3D の仮想地球を描画する 基本 より良いフィルタリングを持ち込む さあ本題に入ろう Google Earth の <ほんとの> 仕組み この文書について RealityPrime > How Google Earth [Really] Works の日本語訳です。 推敲添削歓迎: 誤訳、タイポ、不統一、そのほか ... 有名サイト HowStuffWorks.com の記事 "How Google Earth Works" を読んだら, この記事が "それがどれだけスゴいか" や "その使い方" を書くだけで "それが(ほんとは)どんな仕組みで動いているのか" を説明していないこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと
TheC10kProblem - 「C10K問題」（クライアント1万台問題）とは、ハードウェアの性能上は問題がなくても、あまりにもクライアントの数が多くなるとサーバがパンクする問題のこと 目次 この文書について C10K 問題 関連サイト まず読むべき本 I/O フレームワーク I/O 戦略 1. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と レベル・トリガ型の完了通知を利用する. 伝統的な select() 伝統的な poll() /dev/poll kqueue() 2. 各スレッドが複数のクライアントを受け付ける. そしてノンブロッキング I/O と 変更型の完了通知(readiness change notification)を利用する. kqueue() epoll リアルタイム・シグナル fd 単位のシグナル (Signal-per-fd)
QualityImprovementInFreeSoftware - Free Software における品質改善: リリース管理を中心に
これまでの問題 リリース管理はあまり組織化されておらず, リリースの更新はたまにしか実施されなかった. こうした問題とロードマップの欠如から, 凍結(コード・フリーズ)の発表が唐突にされることも多かった. 組織化されていないリリースの常として, 新しい予定外のブロッカーがリリース・プロセスでみつかった. それも遅延を招いた. 予定外の遅延があると, ソフトウェアは長期にわたって凍結される. Debian 3.1 の場合は一年以上凍結された. このリリースが公開に至った時にはすでに多くのコンポーネントが古くなってしまい, ユーザの要望に合わなくなっていた. Debian が過去のリリースで何度も深刻な遅延に至ったという事実は, プロジェクトのイメージを損ねた. Debian は進みが遅く締切を守れないと思われている. これは開発者やユーザ・コミュニティの不満にもつながっている. 対策 プロジ
[結] 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
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 再描画と再フロー 再フローの回数をでき
国立科学博物館のシアター360は楽しい - 結城浩の日記
目次 2007年1月31日 - 『Java言語で学ぶリファクタリング入門』好調です / 2007年1月30日 - 第2章に進む / 微熱 / 2007年1月28日 - 朝 / 2007年1月27日 - 仕事 / 第1章に戻る / 2007年1月25日 - 仕事 / 2007年1月24日 - 『Java言語で学ぶリファクタリング入門』はおすすめです / 仕事 / 『Java言語で学ぶリファクタリング入門』サンプルプログラム公開 / 2007年1月23日 - 悩みどころ / 2007年1月22日 - 大手術敢行 / うにゃうにゃいいながら構成を検討 / 仕事 / 2007年1月21日 - ゆるりと過ごす / 2007年1月20日 - 仕事 / 2007年1月19日 - かなり形になってきた / プリントアウトして読み返す / 2007年1月18日 - 頭からじっくり書く / まだまだ仕事だって
WhoWritesWikipedia -
WhoWritesWikipedia - 日本語訳 目次 Wikipedia を書いているのは誰? コメント 日本語訳 (spam来襲で凍結しています) "Who Writes Wikipedia?" http://www.aaronsw.com/weblog/whowriteswikipedia の日本語訳です。 面白い記事と翻訳OKをくれた Aaron さんに多謝 添削歓迎。 コメントの付け方とかの流儀がよくわかりません。教えて詳しい人! Wikipedia を書いているのは誰? 僕が最初に ジンボウ・ウェイルズ(Jimbo Wales) に会ったのは、講演のために彼がスタンフォードに来たときだった。ウェイルズは Wikipedia の歴史、技術、文化について語ったんだけど、一つ気になることを言っていた。「Wikipedia は多くの人々に支えられているという考えがある」彼は言った。「
日記を書く心がけ
otsuneさんの文章を読んで、いろいろと思った。 私はこのhyuki.comの日記をどんな規範/規準で書いているのだろう。 顔文字は少なく。使うのは、 (^_^) , (^_^; , *^_^* , φ(._.) くらい。 フォントいじりは基本的にしない。 （笑）などはあまり使わない。でも（冗談）などは使う。 「某」は極力使わない。たとえば「某巨大掲示板」などと書かずに「２ちゃんねる」と書く。 できるだけ他の人の気持ちを害さないように書こうと思うが、害さないことを最優先にはしない。 大胆に語り、間違ったら謝る。 話を下品に落とさない。自分の奥さんや子供に読まれて恥ずかしいことは書かない。 「こんなことを書いたら偽善的だと思われないだろうか」と思わずに、書きたいことを書く。 書いた後、できるだけ読み返す。 悪いものを責めるよりも、良いものを褒めるほうに時間を使う。
[結] 2006年6月 - 結城浩の日記:モノクロ画像がカラーに見える錯視
目次 2006年6月25日 - 長男と完全数談義 / 2006年6月23日 - ティナからの手紙 / 2006年6月20日 - 無神論者との対話 / 2006年6月18日 - 父の日 / 2006年6月16日 - ソフトウェアは、私たちの想像よりもずっと複雑 / 2006年6月14日 - 仕事 / 2006年6月13日 - 無限羽の鳩と無限個の巣 / 仕事 / Haskell / 読書 / 2006年6月12日 - 仕事 / 2006年6月10日 - モノクロ画像がカラーに見える錯視 / 日記ダイジェストを更新 / 2006年6月8日 - www.textfile.orgのお引っ越し / 2006年6月5日 - 仕事 / 2006年6月4日 - 今日の一日 / 2006年6月3日 - 誤植 / 2006年6月1日 - 仕事 / ぜひ、感想をお送りください 日記一覧 2006年6月25日 ■
弱点の指摘が応援になる文化
otsuneさんの文章にあった、 あと殺伐系というかオープンソース文化に毒されているので、「改善点や脆弱点を指摘すること」は「攻撃」では無いんだけど。 そうではない一般的な義理人情やビジネス常識からすると違うんだろうなぁ。 という部分を興味深く読みました。 確かに、オープンソースやフリーソフトウェアの文化では 「バグの指摘」は「攻撃」どころか「応援」である場合が多いと思います。 それでちょっと思ったのは、Webの世界ではもっとすごくて、 内容がどうであれ「言及（リンク）」がすべて応援になることも多いかもしれませんね。 度を越せばslashdottedのようにサーバの負荷になってしまう場合もあるとはいえ。 公開されているWebサイトにとって、 「批判的な文脈でリンクされること」よりも 「誰からもリンクされないこと」のほうがずっとつらいに違いありません。 otsuneさんの文章(2004-11
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
校正の実例 - 文章を書く心がけ3 結城浩