UIデザイナー不要説 / LSD LAB
2014/10/26 UIデザイナー不要説 最近UIについてもやもやしていることがあるので書く。間違った知識もあるかもしれない。 先日UI CrunchというUIの勉強会のようなものが開催され、僕はschooの動画配信を見ていたのだが、どうも根底に「UIデザインの重要性が日本では認知されていない」という共通認識が流れているように思える発表が多かった。デザイナー生存戦略やエンジニアとうまく付き合う方法等…。 僕も前のブログ(UID Lab)でそのようなことを訴えてきたので、あぁ、やっぱりみんな不安なんだなあと思ったが、逆説的に「僕らデザイナーが信じているUIデザインの価値なんて、本当は虚像なんじゃないか？」ということを疑ってみたい。 そもそも、なぜみんな「UIデザインが重要視されていない」と感じるのだろう？自分が日頃感じることを列挙してみる。 UIデザインが重要視されていないと思う理由 1.
何かのときにすっと出したい、プログラミングに関する法則・原則一覧 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外（サブコンポーネント含む）の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
デバッグより重要なもの : 404 Blog Not Found
2009年04月02日16:00 カテゴリCodeArt デバッグより重要なもの この話題、すっかり乗り遅れてしまった。 2009-03-22 - 未来のいつか/hyoshiokの日記 プログラミング入門書では、デバッグについて、ほとんど議論されていないし、仮にふれられていても、おざなりな方法というか、かなり邪険にあつかわれていたりする。プログラマの多くの時間がデバッグについやされていたとしてもだ。 あえていわせていただく。コードはデバッグできるだけはるかにましなのだ、と。printfを使うかどうかなんぞ、その問題と比べれば屁ですらないのだと。 デバッグよりもはるかに重要なもの、それはデータ構造の選定。 ここで一歩間違えると、バグが仕様化し、デバッグどころかバグにあわせてプログラムを書かねばならぬ羽目になる。 その最も顕著な例が、Unicodeだろう。最初の設計を間違えたおかげで、最新のソ
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
ひがやすを blog - ドメインモデルに対する日米の温度差
ドメインモデルに対する日米の温度差 ひさびさにみたなぁ、この話題と思いつつ、コメントします。 昔書いた自分の記事をすべて読み返したわけではありませんが、どこにもトランザクションスクリプトが良いと書いたことはないはず。 この話題に関する問題の根源は、ファウラーが トランザクションスクリプトは、単純だから単純なシステムには向いている。でも、複雑な問題を扱うには、真のオブジェクト指向であるドメインモデルを使ったほうが良い。としたところにあると思います。これが、そもそもおかしい。複雑なシステムを扱うには、ドメインモデルのほうが向いているというのは根拠がない。データと振る舞いを一つにまとめることがオブジェクト指向というのも単純すぎる。 別にオブジェクト指向はこうあるべきなんていまさら議論するつもりはありませんが、私の中でのオブジェクト指向は、「それぞれのオブジェクトがきちんと割り当てられた責任を果た
モデリング・リファクタリングのススメ
ビジネス・モデリングなどのモデリングを始めてはみたものの，なかなか上手くモデリングできない…そんな悩みを持っている方も多いと思います。そこで，今回はモデリングを上達させるための「モデリング・リファクタリング」という方法をご紹介します。 モデリング・リファクタリングとは 「モデリング・リファクタリング」とは筆者が考えた造語です。（すでに誰かによって提唱されているかもしれませんが）筆者が発明したものではなく，モデリングに慣れている方なら自然とやっているようなテクニックです。 もともと「リファクタリング」というのは，小さなプログラム（例えばクラス）を作るときに，プログラムの外側の仕様（使われ方）は変えずに，中身の構造だけを変えることです。 なぜそんなことをするかというと，とりあえず仕様は満たしていたとしても，中身が汚い設計のままでは，変更に弱く，保守性も悪いからです。そこで，小さなプログラムを作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IT化でいいじゃん - 2008年のはぶにっき
Efficient data transfer through zero copy