タグ

softwareとdesignに関するtaloのブックマーク (7)

  • 仙石浩明の日記 「ソフトウェア開発」は「モノ作り」ではない

    いつのころからか、 ソフトウェア開発がモノ作りに喩えられるようになった。 典型的なのは、製造業(例えば自動車製造)と IT 業界とを比較して、 前者が高度にシステム化されているのに対し、 後者がまるで家内制手工業のようだ、という批判である。 日経ビジネス online の記事に次のようなくだりがあった: 「というより、何といいますか、経営トップからすると、 ITはとにかく非常識な世界だ、としか思えないのではないかなあ。 例えば大きなシステム開発プロジェクトに取り組むと、 すぐ100億円を投資する、という話になってしまう。 100億円の経常利益を出そうと思ったら当に大変。 ところが、100億円を投じたのに、期限までに完成しない、 出来上がってきたものが当初計画と違う、 直そうとするとさらに金がかかる。 こんなことが起きるわけですから、『一体なぜなんだ』と経営トップは思うわけです」 IT業界

    talo
    talo 2006/07/29
    設計を困難にしているのは、仕様がはっきりしないから。汎用的なコンポーネントなんて無理。良い設計は仕様ごとに異なる。
  • 習熟度でインターフェースをわけないということ - koyachiの日記

    はてなおやさんがあいかわらずいいことを言っています。この文章の質は最後のほうに書かれていることだと思いますが、その前振り(といったら失礼かも)もインターフェース的に重要です。 はてなブックマークをより使い易いように改良したいと思うけど、それは「初心者に使い易い」ようにする観点ではなく、あれはウェブを見るのが大好きな人たち向けのツールなんだから、初心者が成長してきたころに使うためのツールなんだと。 だから、「使い易い」というのと「初心者にわかりやすい」というのは別の話なんだ、そういう風に考えながら色々改善する。「初心者"にも"分かりやすい」のはもちろんベストですが、それが「初心者向け」に変化してしまって、やたらと説明文の多い設定画面だとか、最小限で済むはずのインタフェースが冗長になってしまったりとか、そういう罠にはまらないように。 naoyaのはてなダイアリー - 3年前の自分は別人、を他

    習熟度でインターフェースをわけないということ - koyachiの日記
  • Macintosh Human Interface Guidelines (HI Guide)

    Inside Macintosh: NEW: Aqua Human Interface Guidelines This document describes how to design your application for the Mac OS X user interface, known as Aqua. Primarily intended for Carbon and Cocoa developers娊ut also applicable for Java developers庪ho want their applications to look right and behave correctly in Mac OS X, this document provides examples of how to use Aqua interface elements. Click

  • OKボタンの位置はどこが適切?

    弊社業務状況のご案内 2020年7月から弊社はフレックスタイム制による毎日の出社勤務体制としていますが、状況により在宅勤務体制に変更する場合もあります。 なお、オフィスは宅配便や郵便物等の受け取りは可能です(10:00〜17:00)。 Pickup2020/04/05 Windows WPF用カラーモード編集ツールのリリース 話題のダークモードアプリ開発に向けたツールを開発しています。 ダークモードに関するデザイン情報を含めてのご案内です。 開く

  • お知らせ

    タイトル・・[入門+実践] 要求を仕様化する技術・表現する技術 出版社・・・技術評論社 A5判/368ページ 価格・・・・定価 2580円(+税) ISBN4-7741-2523-7 発売・・2005年10月7日 都内大型店では9月末に並ぶようです ようやく、Software People vol.4(2004年の4月刊)で公開した要求の仕様化方法「要求の仕様化入門」がの形にまとまりました。雑誌で公開したあと、読者の皆さんから大きな反響があり、急遽、内容と範囲を広げて原稿の作成に取り掛かったものですが、途中、私の業であるSPIのコンサルティングが忙しくなったために、当初の予定より、6月以上も遅れてしまいました。 書は、雑誌に公開した内容も、そのほとんどを書き直し、紙数の関係で雑誌では公開できなかった要求の表現や仕様化のテクニックもたくさん盛り込みました。事例もできるだけ多

  • Martin Fowler's Bliki in Japanese - ヒューメイン・インタフェース

    http://martinfowler.com/bliki/HumaneInterface.html Ruby界隈で「ヒューメイン・インタフェース」という言葉を何度も耳にした。 この言葉は、クラスのインタフェースを記述する際のrubyistたちの姿勢(attitude)の一部を表したものである。 APIの設計については、2つの異なる考え方を対比していくと面白い(もうひとつは最小インタフェースである)。 ヒューメイン・インタフェースの肝は、みんなが何をやりたいかを見つけ出し、何度も起きることを簡単に行えるためのインタフェースを設計することだ。 最小インタフェースとの明確な違いは、ヒューメイン・インタフェースの方が大きくなる傾向があるという点だ。ただ、ヒューメイン・インタフェースの設計者はインタフェースが大きくなることをそれほど気にしてはいない。 以上のことは、ヒューメイン・インタフェースで設

  • Martin Fowler's Bliki in Japanese - 最小インタフェース

    http://martinfowler.com/bliki/MinimalInterface.html 最小インタフェースとはAPI設計のスタイルである。 ここでは、ヒューメイン・インタフェースと比較していく。 最小インタフェースの背景にある考えは、クライアントが必要な機能をすべて提供できるようAPIを設計するが、仕事を成し遂げるための必要最小限のメソッドしか提供しないというものである(両者の違いについての例がヒューメイン・インタフェースにあるので参照のこと)。 ヒューメイン・インタフェースの主張はそちらのページに書いている。 ここでは、最小インタフェースの根拠について述べていこう。 インタフェースの習得には時間がかかる。 膨大なインタフェースを持つクラスはうまく使われることが少ないため、 最初の段階ではインタフェースは少なくしたほうがよいだろう。 インタフェースを小さく保ち、それらのメソ

  • 1