タグ

2006年7月20日のブックマーク (6件)

  • 誤植 - Wikipedia #定着した誤植

    この記事には複数の問題があります。改善やノートページでの議論にご協力ください。 信頼性について検証が求められています。確認のための情報源が必要です。(2008年3月) 雑多な内容を羅列した節があります。(2013年8月) 誤植(ごしょく)とは、印刷物における文字や数字、記号などの誤りのこと。 特に、企業名・商標・人名をはじめとする固有名詞や、数字の位取りの誤植が起こると、大きな問題となることがある。 もともとは活版印刷や写真植字で間違った活字を植字してしまうことを指したが、転じて印刷物全般やウェブサイト上の誤字や脱字、衍字についても「誤植」と呼ばれることがある。 あるスーパーの値札における誤植。「ラブライブ!」と書かなければならないところが「ラブラブ」になっている。 「おつまみ」のメニューであるが、画像下部の文章では「おつまみ」とするべきところを「おつみま」になっている。 当初の誤植とは、

    誤植 - Wikipedia #定着した誤植
    PoohKid
    PoohKid 2006/07/20
    「自分の著作が誰かに盗作されてもすぐわかるよう、こっそり誤植や誤記を忍び込ませておく著作者もいる。このような手法はソフトウエアの世界においてもなされている。」
  • Article 154 at 06/07/19 15:09:02 From: editors@objectclub.jp Subject: 【オブジェクト倶楽部: 2006-27号】

    PoohKid
    PoohKid 2006/07/20
    プロジェクトの半分は「頑張り係数」で出来ています(成分分析風)
  • Martin Fowler's Bliki in Japanese - ジャンケン見積り

    http://martinfowler.com/bliki/ThrownEstimate.html XPスタイルで計画を行っているのであれば、 見積りに関する開発者間の合意を素早くとる必要があるだろう。 こんなときは、ジャンケンで見積りだ。 ジャンケンで見積りを行えば、みんなの見積りが一致しているかどうかがすぐに分かる(一致してればそれを記入し、作業に入ろう)。 また、意見の不一致もすぐに分かる(一致してなければ、機能の詳細についてさらに議論を重ねる必要があるということだ)。 顧客が見積りの必要があるストーリーをまとめている。 以下は、それぞれのストーリーに対する基的な流れである。 顧客はストーリーの概要を開発者に手早く伝える。 開発者は顧客に質問し、ストーリーへの理解を明確にする。ここでは、どうやって実装するかといった技術的な議論はすべきではない。顧客の視点から見たスコープについて尋ね

    PoohKid
    PoohKid 2006/07/20
    これはいい、見積りには長年悩まされ、そして泣かされてきました
  • Martin Fowler's Bliki in Japanese - Cringelyをリファクタリング

    http://martinfowler.com/bliki/RefactoringCringely.html Robert Cringely による最近の記事が、リファクタリングコミュニティの中でちょっとした騒ぎとなりました。彼はリファクタリングを批判していたのです。Phlip はリファクタリングメーリングリストでの反応をいつになく神妙にまとめていました。 ……彼は読むつもりのないにレビューを書く「懐疑論者」のようだ。 確かに、Cringely がどれほどリファクタリングを理解しているか定かではありませんでした。リファクタリングのキーポイントが「振舞いを変えずに処理を変更する」だということは理解しているようでしたが……。彼が行ったのは、リファクタリングが適切に使われていない点について強調しただけなのです。 リファクタリングの誤用のひとつ目は、 これから変更しないコードをリファクタリングす

    PoohKid
    PoohKid 2006/07/20
    「リファクタリングはそういったデススパイラルから逃れる手段」今日、ひどいコードの改修をしてそう思った
  • Martin Fowler's Bliki in Japanese - CodeOwnership

    http://martinfowler.com/bliki/CodeOwnership.html コードの所有には、私が今まで見てきたものだけでも、いくつかの形がある。 ここでは大きく3つのカテゴリに分けてみた。 強いコードの所有では、コードはモジュール(クラス、関数、ファイル)などに分かれており、それぞれが一人の開発者に割り当てられている。開発者は自分のモジュールだけを変更することができる。他の開発者のモジュールを変更したい場合は、モジュールの所有者に頼んで変更してもらうことになる。または、パッチを書いて送りつける方法もある。 弱いコードの所有では、上記と同様、モジュールが各開発者に割り当てられているが、他の人のモジュールも変更してもよいという点で異なる。モジュールの所有者は割り当てられたモジュールに責任を持ち、他の人によって変更が加えられることに気を配る必要がある。他の人のモジュールに

    PoohKid
    PoohKid 2006/07/20
    俺のコードに触るなぁー!
  • 複雑な条件を文章で書くべからず ― @IT自分戦略研究所

    コミュニケーションスキルの土台となる図解言語。だが筆者によると、実はその裏に隠れた読解力、国語力こそがITエンジニアにとって重要なのだという。ITエンジニアに必須の国語力とはどのようなものだろうか。それを身に付けるにはどうしたらいいのか。毎回、ITエンジニアに身近な例を挙げて解説する。 ■実務的な国語力が必要とされている 前回「メタ情報とサマリーで『伝わる』ビジネス文」に引き続き、典型的な失敗のパターンから実務的な国語力を身に付けよう。 前回の記事で「こんな説明では分からない」10種類の失敗パターンを列挙した。以下のようなものである。 (1)メタ情報の欠落 (2)要点の分からない見出し (3)複雑な条件の文章表現 (4)分類を表さない名前 (5)過剰な言い換え (6)対称性のない表現 (7)指示代名詞の多用 (8)相互関連の分からない個条書き (9)時系列の乱れ (10)語感と実感のミスマ

    PoohKid
    PoohKid 2006/07/20
    仕様書からマトリックスをおこしてみると、埋まらない項目が結構あるんだこれが