修正可能なシステム その２ 背景－修正のジレンマ - ウィリアムのいたずらの、まちあるき、たべあるき
ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです（たま～にコンピューター関係も） シリーズ化してしまった？修正可能なシステム。 前回は、概要として、何をやるかについて書きました。 本来なら、その説明をするべきですが、その前に、どこが問題で、このような手順になっているのか？という背景の話をします。 ■データに関する修正をかける場合 問題は、データ構造に対して、削除、あるいは意味が変わったり、型が変わったりする修正で起こります。 （価格を、整数から実数へ、文字２バイトを１バイト、有効期間項目をなくすなど・・） この場合、修正後のプログラムを作るには、まず、データの構造を修正しないといけません。 とくに、データ構造に追加がある場合、追加しないと、プログラムが作れないので、追加します。そうすると、同時に項目を変えないといけない場合（つじつまが合わなくなるので）、削除や
機能から関係へ (arclamp.jp アークランプ)
建築には機能主義という言葉があります。 機能主義はモダニズム建築を代表する概念の1つで、アドルフ・ロース、オーギュスト・ペレ、バウハウスと言った名前が知られています。その次の世代としてはル・コルビュジエ、ミース・ファン・デル・ローエといった名前が有名でしょう。 時代背景から考えてみます。ロースが1870年生まれでミースが1887年生まれなので、19世紀末から20世紀初頭にかけて盛り上がった言葉だと言うことが分かります。19世紀末といえば産業革命が落ち着き、自動車など市民生活に機械が入り始める時期です。フォードが、かの有名なフォード・T型を市販したのが1908年10月のこと。フォードがT型の開発でもっと注意したのがフォード・システムに見られるような大量生産に適応させた車である点です。つまり、19世紀末から20世紀初頭というのは「機械による機械の大量生産」時代の幕開けともいえる時期だったのです
モデルは世界を表現していない (arclamp.jp アークランプ)
システム開発は情報のモデル化 システム開発とはなにか、と聞かれたら「情報をモデルとして扱うこと」と答えるようにしています。オブジェクト指向としてモデリングを説明すると、たとえば車であれば色や馬力といった属性と、走るや止まるといった振る舞いに分けることができるわけです。ソフトウェアというのは、情報という見えないものをモデリングすることによって扱えるようにする手法というわけです。 最近あらためて感じるのは、あくまでもモデルを扱っているに過ぎないんだなということです。以前は「オブジェクト指向であれば現実世界を表現できる」みたいなことをいっていたのですが実際には不可能なことです。モデルの中の車を”本当に”走らせようとしたらガソリンがエネルギーに変換されるところまでモデリングしないといけなくなります。そんなことはできないので「謎の力」に登場してもらうことでモデリングされた車は走ることができるように
プロセスこそアーキテクトのもの (arclamp.jp アークランプ)
ちょいとした事情で品質まわりの情報を調べていたのですがISO 9126-1（JIS X 0129-1）というのに初めて目を通しました（不勉強ですみません）。本物は、ＪISの検索ページで、「x0129」と入力するとでてきます。 で、品質とは何かというページがうまくエッセンスを抽出しています。まず品質をモデル化すると次のようにすることができます。 ※上記ページからの直リンク 右側の「利用時の品質特性」というのは特定の状況における利用者が感じる品質です。だから、状況や利用者が違えば変わってきてしまうもの。で、一般的な指標は「外部品質」と「内部品質」で、それぞれソフトウェアの動きと中身の構造のこと。 そして注目すべきは一番左側のプロセス品質でしょう。プロセスとは設計／開発のやり方や手順。さてJISのドキュメントから少し引用してみましょう。 プロセス品質（JISX0160に規定されているすべてのライ
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
企画屋さんは自分の仕事はデザインだと認識したほうがいいんだと思うよ：DESIGN IT! w-LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 いわゆる典型的な企画屋さんの仕事ってほんとに手におえないなって、最近つくづく感じます。 僕自身、どちらかというと企画を担当する仕事をしてますけど、そんな僕からみても、いわゆる企画屋さんの仕事って傍からみてても「おいおい、それじゃあ、いつまで経っても形にならないよ」ってくらい、実装のことを無視した仕事の進め方をしてたりします。 制約を知らない人たちそれでいて、そういう人たちに限って「自分はものづくりにかかわってる」みたいな顔したり「ユーザー視点がどうこう」とか言ったりします。客観的にみると、ぜんぜん、ものづくりの視点が欠けてるし、ユーザー視点のかけらもなくて単にあなたの思いつきを並べてるだけですよね、と思うことが多いんですけど。 とにかくアイデアベースだけなので、ものづくりが
計算不可能性を設計する (arclamp.jp アークランプ)
計算不可能性を設計する―ITアーキテクトの未来への挑戦は、社会学者の宮台真司さんとITアーキテクトの神成淳司さんの対談。まぁ、はっきり言えばデンパ系ですが個人的には気に入りました。 「計算不可能性を設計する」という主題は面白い問いかけです。デジタルなビットの世界では全てが計算可能になっています。 しかし、セカンドライフに感じるリアリティは計算不可能性があるからこそ。つまりセカンドライフを設計するというのは、そこで人間が起しうる計算不可能性を考えた上で、セカンドライフというアーキテクチャを設計するということをあらわしています。計算不可能性を許容しうる計算された世界とでもいえばいいのでしょうか。 だからこそ、セカンドライフという世界においてアーキテクトが与える選択肢は絶対です。 「アーキテクトの思想」とは、「社会システムのコンピューテーションを進めた際、利用者にどのような情報や選択肢を提供する
アプリケーション・サステナビリティ (arclamp.jp アークランプ)
アプリケーションを構築するために考える基本的な要素は3つだと思います。それがファンクショナリティ、ユーザビリティ、スケーラビリティです。 1.ファンクショナリティ（機能性）：アプリケーションが提供すべき機能そのもの 2.ユーザビリティ（使える性※）：アプリケーションの機能を、ユーザーが使えるようにする 3.スケーラビリティ（調整可能性）：ユーザービリティを低減させること無く、適切な数のユーザーに提供する ※ユーザービリティを「使いやすさ」と訳すと「ユーザビリティ＝使いやすさ」なんて誤訳をいつまで放置するのか？と言われてしまうので。 この3つは同時に実現されるべきものです。機能が良くても使えなくは意味がない。使えても提供できなくては意味がない。提供もできて使えても機能がヘボでは意味がない。 これがけっこう難しい。アプリケーションというと1.ファンクショナリティというのに目が行きがちで2、3を
それでも設定が大事な理由 (arclamp.jp アークランプ)
ひがさんのエントリ「規約ベースのフレームワークのほうが覚えることが増える? 」を読んでいて、ふとした気づき。 暗黙的な規約は直感的ではない 結論から言えば、僕は"暗黙的な規約（Tacit Convention）"ではなく"形式的な設定（Articulable Configuration）"が重要だと思っています。ちなみに、Tacit Knowledgeは暗黙知でArticulable Knowledgeは形式知のこと。 なぜなら"暗黙的な規約"は、ある意味で直感的ではないからです。 人間が情報に反応するためには、情報が何らかの形で形式化されていなくてはいけません。 たとえば何かの操作を方法を学ぶ場合を考えてみます。説明書というのは操作方法を形式化したものです。しかし、直感的ではない。それは操作対象そのものに触るわけではなく、絵などで遠まわしに説明されているからです。 一方、説明書なん
基盤技術にロック・オンされていないか？
ITアーキテクトを目指す多くの人々は、現在、プログラミングを主な作業として仕事に従事しているのではないだろうか。プログラミングを行う場合、Javaなど特定の言語のみを主軸としている人と、振られる仕事によって言語を切り替えるような、複数の言語を同時に操っている人とに分かれるだろう。今回はプログラミング言語を中心とした開発系の話が中心である。 ソフトウェアはある特定の環境でしか動作しない ソフトウェアはそもそも、特定の基盤技術の上（特定のハードウェアやOSの上ということ）で、特定のコンパイラを用いて、特定の言語を操作して構築するものだ。このうち、どれか1つでも“特定”という条件から外れた場合、そのソフトウェアは動作しない。それは、ハードウェアやOSから独立した特定のバーチャルマシン上で動作するJavaクラスファイルでも同じ話だ（例えば、PC-AT互換機であろうとも、Java SE 5.0仕様V
ITアーキテクトを実践する
ITアーキテクトという言葉が浸透し、『ITアーキテクトとは何か』という議論がさまざまなところで行われてきた。現在はその次の段階、すなわち『ITアーキテクトは実際に何をどうすべきなのか』という議論が戦わされる段階に入っている。 2005年に始まった『28歳から挑戦するITアーキテクト』は、主にITアーキテクトとは何か、その問題とは何かという面から、人間的な問題を中心とし、汎用的な内容に特化した内容をお送りした。具体的な内容ではなく、目の前の技術が変革しようとも長期的に役に立つような基本となるものを中心にお話ししたつもりだ。 しかし、そうした言説も目の前の課題を克服するきっかけとならなければ、ただのお説教となってしまう。なので、改めて、『実践篇』と銘打ち、ITアーキテクトを目指す若い方々の、目の前に立ち並ぶ無数の選択肢とその解決指針について、ITアーキテクトとしての視点で判断する指針をお伝えし
ITが建築から学べるものは多い - モジログ
arclamp.jp アークランプ: ITアーキテクトってなんだ？ http://www.arclamp.jp/blog/archives/000765.html ＜僕が考えたアーキテクトの仕事とは「提案したシステムがいかなるもので、どのような形であるべきかをクライアントとプログラマに示す」ことであり、それに必要な言葉を定義することが最初の作業となるわけです。 特にコールハースの「定義された言葉こそがデザインを可能にしている」という言葉は深いです。 結局、クライアントにしてみれば「なにができる」「どんな感じ」といったイメージでしか語ることができません。そうしたものを＜言葉＞として定義していくことがアーキテクトの役割なのかもしれません＞。 これはすばらしい一節。 「定義された言葉こそがデザインを可能にしている」って、いいフレーズだなあ。 最近のyusukeさんは建築を引き合いに出してITを語
ITアーキテクトってなんだ？ (arclamp.jp アークランプ)
arclamp.jp アークランプ ITアーキテクトが、ビジネス書とかデザインとか建築とかからシステム開発を妄想するブログ 某所でIT関連書籍の編集者に「あなたはITアーキテクトを名乗っておられるが、あなたはITアーキテクトをなんだとお考えですか？」と聞かれました。 そのときの僕の答えは「アプリケーションの"クライアントにとっての価値"を説明できる人」というものです。そのアプリが、どんなに技術的にださかろうとクライアントに、その価値を説明できればいいわけです。そういう説明責任がアーキテクトの任務だと思っています。アーキテクトがアーキテクチャーの勉強をするとか、そういうレベルは当たり前です。その上で何が必要かと聞かれれば、言葉にする力というわけです。 で、素材の美学―表面が動き始めるとき…という建築系の本を読んでいていい言葉を見つけました。第1章ではスピロ・コストフの「建築家」という本からの
WEB+DB PRESS「DI時代のアーキテクチャ設計入門/第1章、第2章」を寄稿 (arclamp.jp アークランプ)
WEB+DB PRESS Vol30（2005/12/22発売）の特集1「DI時代のアーキテクチャ設計入門」において、第1章と第2章を寄稿しました。共著はギガプライズ田中さんです（ブログ：天使やカイザーと呼ばれて）。 第1章は「DI時代のアーキテクト - ソフトウェアアーキテクチャを見据えた設計とは」。僕はアイデアのみで田中さんが執筆。アーキテクトに焦点を当て、プロジェクト開発での実装を実現するための開発のフレームワークが重要だと書かれています。具体的には規約をどのように運用していくべきかということですかね。ま、DIには一切関係のない内容のですが（ｗ、DIであればこうした運用に柔軟性が出るという指摘を行っています。 第2章は「DI時代のJava EE（J2EE）アーキテクチャ - DIの本質とその効果的な導入とは」。僕が執筆。個人的には良い感じに書けたと思っています（某記事での反省をいかし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
IBM Developer