タグ

2005年8月29日のブックマーク (12件)

  • http://edit-real.com/esaka/archives/004171.html

  • Quality Assurance Software & Tools - Cross Platform Testing | Qt

    Axivion Architecture Verification Software architecture verification

    Quality Assurance Software & Tools - Cross Platform Testing | Qt
  • TheServerSide | Your Java Community discussing server side development

  • http://docs.codehaus.org/pages/viewpage.action?pageId=30857

  • Casinonic Australia – how to get much pleasure?

  • 日本IBM

    watsonx.governanceの提供を開始 責任ある、透明で説明可能なAIのワークフローを実現する生成AIのためのガバナンス・ツール 製品の詳細 無料評価版を試す このたびの令和6年能登半島地震で被災された皆様に謹んでお見舞い申し上げます。 令和6年1月1日に発生した能登半島地震により被災されたお客様向けの保守サービス特別対応 システム開発や運用に生成AIを活用する「IT変革のためのAIソリューション」により、生産性と品質の向上を実現

    日本IBM
  • プロローグ 秋葉原(あきはばら)の由来 | 秋葉原電気街振興会

    現在の秋葉原電気街のあたりは、江戸時代は下級武士の居住地域であった。「火事とケンカは江戸の華」と言われたように、当時は火事が多く、この秋葉原かいわいも江戸時代を通じて火災に悩まされていた。 1869(明治2年)の相生(あいおい)町の大火を機会に、当時の明治政府下の東京府は9000坪(約3万平方メートル)の火除地(ひよけち)を当地に設置し、翌1870(明治3年)年に、遠州(現在の静岡県)から火除けの秋葉大権現(あきばだいごんげん)を勧請(かんじょう)し、鎮火神社としてまつった。 当初は鎮火原と呼ばれたが、鎮火神社が秋葉神社(あきばじんじゃ:現在は台東区松が谷に移転)と改められると、「秋葉原(あきばはら・あきばっぱら)」と呼ばれるようになった。 現在、「あきば」と略されるのは、このあたりが語源となっている。 1890年(明治23年)に上野から鉄道が延長されて、新しく当地に駅が開設されることにな

    t-wada
    t-wada 2005/08/29
  • 楽々ERDレッスン 第1回:「お持ち帰りご注文用紙」編:CodeZine

    はじめに システム構築においてデータベース設計は不可欠です。そこで多くの方がデータベースの設計技法について書籍で学んだりするのですが、なかなか身についたと感じられないことも多いのではないかと感じます。 その理由は、実務で任せられる機会というのが少ないからというのが大きなものとして挙げられます。データベース設計というのは、やはり重要な箇所ですから自然と経験のある人に任せられることが多いのが実態です。しかもデータベース設計を担当するのはプロジェクト全体の中でもごく少数だけになりますから、なかなかチャンスが巡ってきません。 しかし、それを嘆いているばかりではスキルが身につかないのも道理です。そこで身近にあるものを何でも手当たり次第にデータベース設計のネタにしてしまうことで、コツコツと地力をつけていこうというのがこのシリーズの主旨です。 合言葉は、「表組みを見たらERDを描け!」 。では、

  • デザインの「悪い方がよい」原則 The Rise of "Worse is Better"

    デザインの「悪い方がよい」原則 The Rise of "Worse is Better" rpg@lucid.com 日語訳: daiti-m@is.aist-nara.ac.jp 私や Common Lisp と CLOS のデザイナーのほとんどは、MIT/Stanford 方式の設計に親しんでいる。 この方式の核心は、「正しい」やり方をせよ、という ことにつきる。デザイナーにとっては、以下の点をすべて正しく満たすことが 重要である。 簡潔性 デザインは実装と使用法の両面において単純でなければならない。 このとき、使用法が単純な方が、実装が単純なことより重要である。 正当性 デザインはすべての点において正しいものでなければならない。 誤りは許されない。 一貫性 デザインは一貫性を欠いたものであってはならない。一貫性を保つ ためには完全性は少しだけ犠牲にしてもよい。一貫性は 正当性と同

    t-wada
    t-wada 2005/08/29
  • How to Write Maintainable Code 日本語訳

    以下の文章は、Bram Cohen による How to Write Maintainable Code の日語訳である。 翻訳文書については、福盛秀雄さんと竹中明夫さんから誤訳の訂正を頂きました。ありがとうございました。 ソフトウェア技術者は、自分が書くコードがどのようにあるべきか分からず悩んでいる。よく知られたエッセイ「悪い方がよい」(訳注:日語訳)がその良い例である――どうして悪いほうがより良くなれるの? やっぱり悪いほうが悪いんじゃないの? さらにややこしいことに、「悪い方がよい」の話は、それが主張しようとしている内容とは正反対の議論の中で引き合いに出されることが多い。 問題は、みんながコードの「美しさ」を判断するのに非常に多様な、また往々にして相反する基準を採用していることだ。美的感覚よりも客観的な、コード品質に対する基準が明らかに必要である。 僕としては、メンテナンス性に

    t-wada
    t-wada 2005/08/29
  • なんでも継続

    Shiro Kawai まだ下書き Schemeの特徴をあげるときに、「継続」や「call/cc」が出て来ないことはない。 でも、R5RSのcall/ccの項をいくら読んでも、どうもよくわからない。 call/ccを使えばC言語のbreakみたいなのとか、コルーチンとかいう スレッドもどきとかが書ける、というのはわかったけど、一体そういうのが書けて 何が嬉しいのか、そこんとこがピンと来ないんだ。 今、そこにある継続 プログラミングの世界の概念には、禅の公案のようなものがある。 それを説明する文章はほんの一文なのに、最初に目にする時、 その文は全く意味をなさない、暗号のように感じられる。 だがひとたびその概念を理解すると、 その概念の説明は確かにその一文で説明されているのがわかるのだ。 そんな、「分かれば分かる」という禅問答の中でも 「継続」は最も謎めいたものの一つと言えるだろう。 文献を

    t-wada
    t-wada 2005/08/29
  • Beating the Averages

    普通のやつらの上を行け ---Beating the Averages--- 著者:Paul Graham Copyright 2001 by Paul Graham これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。 プロジェクト杉田玄白正式参加テキスト。 <版権表示> 和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。 (「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。 Copyright 2001 by Paul Graham 原文: http://www.paulgraham.com/avg.html語訳:Shiro Kawai (shiro @ acm.org) <版権表示終り> 文中、Eric Raymondの "Ho