タグ

2006年2月17日のブックマーク (11件)

  • 川o・-・)<2nd life - MigemizeExplorer が便利すぎる件

    http://www12.plala.or.jp/yoshi223/MigemizeExplorer/ 今更ですが、使ってみたら超便利だったので紹介。普段キーボードを使ったexplorerでファイルを選択をする時は、頭文字の英数を打って目的のファイルの近い場所まで移動して選択したりしてます。日語ファイル名の場合はより面倒です。そんなときMigemizeExplorerを使うとファイル選択がとても簡単になります。 Migemoはみなさんご存じのローマ字で日語インクリメンタルサーチできるツールで、使ったことがある人はわかると思いますが、いちいちIMEを立ち上げずとも日語を検索できるので大変便利です。その Migemo 検索を簡単にexplorerからできちゃうようにするのが MigemizeExplorer です。 MigemizeExplorerを立ち上げればexplorerのどこから

    川o・-・)<2nd life - MigemizeExplorer が便利すぎる件
    stfh
    stfh 2006/02/17
  • 木暮 仁:「経営と情報」に関する教材と意見

    経営情報システム,情報技術,情報セキュリティ等の授業教材, 情報システムの費用対効果,情報システム部門の運営等への主張, 歴史Javascript等の趣味・・・などを掲げています(since 1996.11.18)。 著者:木暮 仁(自己紹介)(hitoshi@kogures.com) サイトマップはありません。右の(サイト内検索)に「経営戦略」,「情報化投資」などの キーワードを指定してください。 リンクはご自由にどうぞ。ディレクトリは予告せずに変更しますので,リンク先はできるだけ https://www.kogures.com/ にしてください。 Web教材(webtext) 文系大学生対象の授業テキストです。当然こちらは客観的な記述にしています。社会人のIT分野初心者のかたもどうぞ(more)。 私の主張(opinion) 経営者,CIO,情報システム部門長を対象に,私の意見を掲げ

    stfh
    stfh 2006/02/17
  • ENIAC誕生60周年--2人の科学者が作った怪物コンピュータ

    1946年2月、J. Presper EckertとJohn Mauchlyは世界に向けて、「ENIAC(Electronic Numerical Integrator and Computer)」を公開した。世界でも最も早い時期につくられた電気式計算機のひとつとして知られるENIACは、1秒間に5000回の加算を行うことができた。ENIACの処理速度は、それまでに開発されたどの機器よりも、はるかに速いものだった。 2人は自分たちが歴史を変えるような何かを生み出したことを理解していた。だが、この画期的な発明を人々にどう伝えるかという問題があった。そこで、2人は電球に数字を書き込み、その「半透明の球体」をENIACのパネルにねじ込むというアイディアを思いついた。電球がぴかぴかと点滅する様子は、このコンピュータの原景として、その後も長く人々に記憶されることになった。 このちょっとした演出は、E

    ENIAC誕生60周年--2人の科学者が作った怪物コンピュータ
    stfh
    stfh 2006/02/17
  • Fullauto Bookscanner - a scientist's toy box

    サービス終了のお知らせ いつもYahoo! JAPANのサービスをご利用いただき誠にありがとうございます。 お客様がアクセスされたサービスは日までにサービスを終了いたしました。 今後ともYahoo! JAPANのサービスをご愛顧くださいますよう、よろしくお願いいたします。

    stfh
    stfh 2006/02/17
  • 情報システム事故(4)東証システム問題を考える(前編)

    テレビや新聞などのマスコミは,昨年11月以来,続発する東証のシステム・トラブルについて,その責任を追及する報道を続けている。そしてさまざまな人たちが,それぞれの立場で,東証の問題を指摘している。しかし,「どうすればよいのか」という根的な解決策は出てこない。「あまりにも多くの問題が複雑に絡み合っており,即,解決するのは難しい。まずは時間が必要だ」というのが,金融分野やシステム分野における関係者・有識者の音ではないだろうか。 金融とITを専門分野としてきた筆者は,多くのマスコミ関係者から東証の問題について,コメントを求められてきた。ただ,筆者は東証のシステムの詳細を知らないため,コメントするのは基的に避けてきた。 ただ少なくとも言えるのは,一連の「東証システム問題」は,東証固有の問題から発生したわけではない,ということだ。 いまさら誰が悪いと責任追及するのは建設的ではない。まずは問題を洗

    情報システム事故(4)東証システム問題を考える(前編)
    stfh
    stfh 2006/02/17
  • SourceForge, Slashdot 内部構造群解 〜世界最大のオープンソース開発ネットワークのテクノロジー〜 Slashdot 編

    [ English / Japanese ] SOI Asia Project

    stfh
    stfh 2006/02/17
  • 「2倍速い」Intel CPU搭載の新しいiMacをイジってみた

    新しいiMacは、Macintoshで初めてIntelプロセッサを使ったマシンだ。この20インチモデルを1週間ほど使うことができたので、その速度を中心にiMac G5と比較しながらレビューしてみた。 なお、Mac OS X 10.4.5がリリースされたが、このレビューはそのリリース前に執筆したものなので、OSは10.4.4だ。10.4.5でどう変わったかはチャンスがあったらまた調べてみたい。 見た目にはかわりのない新しいiMac――違いは2カ所 見た目には、新しいiMac(以下iMac Intel)はiMac G5と全く変わりがない。内蔵されたiSightカメラも、リモコンの取り付け位置もみんな一緒だ。 こうやって並べてみてもどっちがiMac Intelかわからない(手前がそう)。液晶の写りかたも同じだ。 外からわかる違いは2カ所。ひとつは、背中の外部ビデオ端子。iMac G5では独自コネ

    「2倍速い」Intel CPU搭載の新しいiMacをイジってみた
    stfh
    stfh 2006/02/17
  • 分裂勘違い君劇場 - 劇的に生産性を向上させるメタオブジェクト技術とRuby on Railsの陳腐化の宿命(Java、C#)

    ■この記事で取り上げているトピックハイライト■ なぜ、メタオブジェクトを自分自身で使いこなせるようになると、日常のプログラミング生産性が大きく向上するのか? なぜ、メタオブジェクト技術を使うと、分散オブジェクト、Rails、DI、ORマッピング、Webサービスなどの、大きく生産性を向上させる仕組み自体を自分でつくれるのか? C#のどのメタオブジェクト機能をどのように使えば、簡単に「C# on Rails」を作れるのか? なぜ「Ruby on Rails」は陳腐化してしまう運命にあるのか? 「Ruby on Rails」を陳腐化させるアーキテクチャとはどのようなものなのか? ■構成■ まず、Ruby on Railsと同様のフレームワークを、C#で作ったとしたら、どのようになるのかという例題を通して、メタオブジェクト機能、つまり、リフレクション、カスタム属性、CodeDOM、パーサジェネレー

    分裂勘違い君劇場 - 劇的に生産性を向上させるメタオブジェクト技術とRuby on Railsの陳腐化の宿命(Java、C#)
  • 2 repeat or not 2 repeat : 404 Blog Not Found

    2006年02月17日00:03 カテゴリPsychoengineering一日一行野郎 2 repeat or not 2 repeat That's the question. 分裂勘違い君劇場 - 「同じことを2度しないようにする」というプログラマの習性が、逆に生産性を大きく下げている この記事で主張しているように「同じことを2度しない(Only and Only OnceあるいはDRY:Don't Repeat Yourself)」と無条件で考えてしまうと、逆に生産性が大きく低下するケースがたくさんある。分裂勘違い君も指摘しているように、実は「繰り返さない」という選択には、「繰り返さないための仕組みを作る」というコストが伴う。 例えばフィボナッチ数のことを考えてみる。1, 1, 2, 3, 5, 8という数字を見せられて、「次に来るのは何?」と聞かれたら、わざわざ perl -le

    2 repeat or not 2 repeat : 404 Blog Not Found
    stfh
    stfh 2006/02/17
  • わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その5)

    ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント=契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから(結果、後から手直しが多発する)だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日語に書き直さなければならないか、疑問に思うだろう。 当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ

    わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え(その5)
    stfh
    stfh 2006/02/17
  • 分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由

    それから、これは個人的な意見ですが、プログラマはコンピューターの扱いになれているから、そうでない人が使うためのインタフェースを設計することができない、みたいな話をときどき耳にしますが、僕はそれに懐疑的です。インタフェースをうまく設計できない人というのはプログラマに限った話じゃない。それは「プログラマは営業ができない」と乱暴にまとめてしまうのと同じようなこと。 たぶん、プログラムができるかできないかということと、インタフェースをうまく設計できるかできないかというのはあんまり相関がないように思います。むしろコンピュータの世界では、プログラマは頭のなかで思い描いたインタフェースを実現する手段を最も良く知っている部類の人で、インタフェースを作るセンスさえ持ち得れば、それ作るのにもっとも適した人たちなんじゃないかと思います。 知り合いの会社では、半期ごとだかクオーターごとだかに、その期に、もっとも優

    分裂勘違い君劇場 - エンジニアの方が優れたユーザインタフェースデザインができる理由
    stfh
    stfh 2006/02/17