設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/06 07:50 UTC 版)
軍人の子として生まれ、決して裕福な家庭ではなかったが、小学5年で美術に目覚めた。家系には美術の天分があったとしている。師範大付属高でも自身は他の多くの生徒同様、美術教師を志していたが、クラスで建築家を目指していた1人の同級生に影響を受けてクラスでは美術教師にも建築系の指導、試験を求めるようになった。 当時の台湾の大学で建築学部を設けていたのは成功大学だけだった。高校での美術指導が功を奏してか、同年に成功大学建築学部に合格した50名のうち、師大附属出身者は李を含めて5人を占めた。 大学では1年生から4年生まで一つの大家庭のような校風で昼夜を問わず学内のアトリエでデッサンに明け暮れて、収穫が多かったという。 青年時の李はスイスの建築家ル・コルビュジエ(1887-1965)を「建築作品は芸術家としての才気に溢れ、歴史を変えた一人であり、現代建築史の偉大な人物」と評し、自身の手本にしていた。 台湾に帰国後も「中国文化を知らずして、中国人の建築を設計することはできない」として、『中華建築』の思考を深めていく。中国の代表的思想家の牟宗三に入門し、儒学、仏学、老荘思想を学んで「最高の文化は宗教にほかならない」という境地に辿り着く。 中華と西洋の文化をぶつけあった成果物として「東王漢宮」や「大安国宅」を生み出した。李は「屋上部に中国古代建築の屋根を置いてみた」と語っている。宏国大楼(1989年)は李が「自己の中国建築意識を作品に反映できた」と初めて自認できるものとなった作品で、儒学に則った左右対称の外観と、天・地・人の三者の関係を物語る形状で、中国建築がもつ特色を「形式化」から「概念化」へ変えることを試みたという。 一方で21世紀になってからは雑誌『EGG』と国内の若手建築家が選定する『台湾で最も醜い建築物』に李の作品が数件ランクインするなど、世代の違いとはいえ不名誉な評価もある。
※この「設計思想」の解説は、「李祖原」の解説の一部です。
「設計思想」を含む「李祖原」の記事については、「李祖原」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/16 07:03 UTC 版)
「Scientific Linux」の記事における「設計思想」の解説
Scientific Linuxの第一の目的は、世界中の様々な研究所や大学のための一般的なLinuxディストリビューションを作り、かくして、同じような努力を減らすことにある。主要なゴールは、若干のマイナーな追加と変更を伴う形で、Red Hat Enterprise Linuxに全て互換性を持たせることと、Linuxの基礎を邪魔することなく、場所に応じたカスマタイズを簡単にできるようにすることである。Poseidon Linuxのような他のディストリビューションとは異なり、Scientific Linuxは、科学向けソフトウェアの大規模なコレクションは含んでいない。しかしながら、そのようなソフトウェアのインストールにはよく適合するようになっている。
※この「設計思想」の解説は、「Scientific Linux」の解説の一部です。
「設計思想」を含む「Scientific Linux」の記事については、「Scientific Linux」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/04 03:18 UTC 版)
近畿地方(京都、大阪)の長屋住宅は、中庭・通り庭・後庭を備えることを理想とする住宅様式である。しかし敷地が充分でない場合など、良好でない住環境となることも少なくない。 安藤自身がそうした住環境に長年住み続けて、生活にとって重要である通風、採光、日照などの確保を知悉していたことから、大胆なデザインによる革新的な住宅が着想された。敷地は間口2間、奥行き7間で14坪しかなく、施主の当初の意向など到底反映されないと考えた安藤は、長屋をすっぱり切り取ってコンクリートの箱を入れ、抽象的な芸術に近いような物にしたいと考えた。安藤曰く「単純ではあるけれども実際には単純ではない、物理的にはどれほど小さな空間であっても、その小宇宙のなかにかけがえのない自然があり豊かさがあるような住宅をつくりたかったのです。」と述べている。また、全体の約三分の一を中庭にすることで、建ぺい率60%でも敷地いっぱいに建てられる合理性もあると考えた。西洋的な環境の中に日本的感性を持ち込むため、日本建築で採用されてきた寸法を採用し、7尺5寸(約2.25m)という天井の高さを決めたとされる。内装材や家具などは天然素材を使用、床は石材、フローリング・家具は木材である。 批判的意見に対しては、「このあたりの小さな町屋の空間の記憶、生活の歴史や伝統、といった人間が生活する上で切ることのできない要素をかつての建物の形や材料を用いることで直接伝承するのでなく、リチャード・セラやケリーの絵ではないが、徹底的に抽象化していった幾何学的な四角い箱のなかに、人々が営々と住み続けていた町屋という伝統的な住まいや、自然に対する考え方、そういったものをすべて一気に封じ込められた」と述べている。
※この「設計思想」の解説は、「住吉の長屋」の解説の一部です。
「設計思想」を含む「住吉の長屋」の記事については、「住吉の長屋」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/05/10 04:23 UTC 版)
台湾で最初に手がけたのが長庚医院だった。そこで室内設計に携わり、そこで従来のオフィスや住宅とは異なる医療機関独特の建築用語や空間使用のあり方を習得したことは、他の大型公共施設でのコンペ獲得にも生きていると述べている。また国内外の多数の建築家、建築事務所と協業してきたことから、相手の専門分野、長所を吸収し、自己の知識へと昇華させてきた。フランスのチームと体育館の設計を担当したときは大型公共空間では避難通路を必ず設置することなどを学び、実践している。国を跨いだ協業によって違う分野の技術や経験を学ぶことができると考えるに至ったのは、滞在したサンフランシスコでチェン・カイコー(陳凱歌)の作品「さらば、わが愛/覇王別姫」に熱中する外国人を目の当たりにしたことや、映画監督アン・リー(李安)がハリウッドで成功を収めたこととし、劉は新しい協業スタイルを模索した。 「建築と映画産業は異なるチームが互いに技術を出し合うが、監督1人によって統括と協調がもたらされるという点でよく似ている」と述べ、劉も「華人の頭脳で外国人の業務を指揮する」というアン・リーのスタイル(李安模式)に辿り着いた。李安スタイルを実践する最初の機会が高雄市立図書館総館だった。構造設計はせんだいメディアテークで伊東豊雄と組んだ日本の竹中工務店、フランスの展示レイアウト担当チーム、イギリスの交通計画顧問が劉のユニットメンバーとなり、そのチームを率いることで中国伝統の天井構造が生み出されたと語っている。
※この「設計思想」の解説は、「劉培森」の解説の一部です。
「設計思想」を含む「劉培森」の記事については、「劉培森」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/11/17 07:03 UTC 版)
「X Window Systemプロトコルとアーキテクチャ」の記事における「設計思想」の解説
Bob ScheiflerとJim Gettysは設計にあたって、Xの基本原則を以下のように定めた(Scheifler/Gettys 1996)。 実際のアプリケーションでどうしても必要という場合以外は、新機能を追加するな。 システムが何でないのかを定義することは、何であるのかを定義するのと同じように重要である。あらゆるニーズに答える必要はない。むしろ、互換性を維持した状態で拡張可能にしておけ。 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシである。 問題が完全に把握できないときは、解決策も提供しないのが最善の方法である。 作業の10%について90%の効果しか得られないときは、単純な解法を使え。 複雑さは可能な限り分離せよ。 ポリシーよりも機構を提供せよ。特にユーザインタフェースのポリシーはクライアント側に任せておけ。 先頭の原則は、X11の設計中に「具体的アプリケーションがそれを必要としていることを知っている場合に限って、新たな機能を追加せよ」に修正された。X はだいたいにおいてこれらの原則に従ってきた。リファレンス実装は拡張性と改良を視野に入れて開発されており、1987年当時のプロトコルとほぼ完全な互換性を維持している。
※この「設計思想」の解説は、「X Window Systemプロトコルとアーキテクチャ」の解説の一部です。
「設計思想」を含む「X Window Systemプロトコルとアーキテクチャ」の記事については、「X Window Systemプロトコルとアーキテクチャ」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/05/27 06:21 UTC 版)
制定に当たっては、高等学校の教科書9教科(9冊)の延べ130万文字や天声人語(16万語)などの資料をn-gramデータとして集計してから用いた。また、実在の人間にとって「無理なく・すばやく」操作できる入力法を設計するために、女子大学生7名を対象として延べ約380万文字分の「指の運動特性」調査を行った。入力の過程で得た運動特性データは、配列を設計・選別するための打鍵速度データとして使われた。 新JIS配列は日本語入力の分野において、「数百万字クラスの大規模n-gramデータを、数百万打鍵クラスの大規模運動特性データによって仮想打鍵する」ことにより、無数に存在する配列候補から「各種の要求を満たす、評価の高い配列」を、現実的な設計期間で選び出せる設計手法が利用された先駆けでもある。 成果物による入力速度を客観的に評価・比較でき、かつ人間の動作能力を子細に渡るまで反映させることができることから、この考え方は後に設計された多くのかな入力法にも受け継がれている。 コンピュータの計算能力が向上するにつれて、事前の候補絞込みをなるべく避けて「より広い範囲の候補」から配列を選別することが可能となるため、さらに高い性能を持つ配列が見つかる可能性もある。しかし新JIS配列の設計時点では、コンピュータの計算能力が高くなかったために、無数に存在する配列候補のうち「高速に入力できる大まかな条件」を満たすグループのみを初期候補として選別し、その中から計算と手動評価によって配列を選び出している。
※この「設計思想」の解説は、「新JIS配列」の解説の一部です。
「設計思想」を含む「新JIS配列」の記事については、「新JIS配列」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/11/27 00:07 UTC 版)
「JavaとC++の比較」の記事における「設計思想」の解説
C++とJavaとの違いは、それら言語の歴史から辿ることができる。 C++はC言語の派生規格であり、手続き型プログラミング言語にクラス(抽象データ型)を導入し、静的型付けオブジェクト指向プログラミングを実現するために開発された。C言語の設計思想を維持・継承し、C言語の利点(機械語やアセンブラに準ずる高速性やハードウェア操作性など)を一切損なわないようにしているため、他のオブジェクト指向言語に比べてコードの実行効率や柔軟性を重視している反面、安全性は犠牲になっている。 Javaは当初、組み込みシステム上でネットワークコンピューティングに対応 (support) するために開発された。Javaは移植性があり、セキュアであり、マルチスレッド対応であり、分散であり、そしてC++よりも単純 (simple) になるように設計された。Javaの文法はC/C++プログラマに馴染みやすいものが選ばれたが、C/C++との直接的な互換性は維持されていない。 C++とJavaは開発の目的が異なるため、両者の方針とトレードオフに違いが生じている。 C++Javaネイティブコード マネージコード Cの (部分的な) 上位互換 C/C++との互換性はない プログラマを信頼する プログラマを守る ハードウェアに近い低レベル(下位レベル)機能を操作できる メモリを抽象化した型やオブジェクトを通してのみアクセス可能 簡潔な表現 明確な表現 明示的な型破壊を許可 型安全性 マルチパラダイム(手続き型、オブジェクト指向、総称型、関数型) オブジェクト指向、総称型、関数型 演算子多重定義 演算子の効果は不変 限られた範囲の標準ライブラリ (GUI、ネットワーク、マルチスレッドを含む)機能豊富で容易に使用できる標準ライブラリ 組み込み、パーソナルコンピュータ、ワークステーション 業務システム(Webフロントエンド、Webバックエンド)、携帯端末 C言語とC++は相互運用性が確保されており、C++からCのライブラリ(関数群)を直接利用することが可能になっている。なお、2018年現在のC/C++最新規格はそれぞれC11およびC++17だが、双方に独自の追加仕様が重ねられており、C言語に対する完全な上位互換性はなくなっている。ただし、互いの差異を埋めて互換性を向上するための機能追加もなされている。 また、JavaはC/C++との互換性はないが、ScalaやKotlin、Groovyといった後発のJava仮想マシン (JVM) ベースのABI互換言語との間で相互運用が可能になっている。
※この「設計思想」の解説は、「JavaとC++の比較」の解説の一部です。
「設計思想」を含む「JavaとC++の比較」の記事については、「JavaとC++の比較」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/26 14:54 UTC 版)
外見の特徴であるリアオーバーハングの長さの理由は二つあり、ひとつはマフラーをエンジンルームから遠ざけ、ルーム内の温度上昇を防ぎエンジン補機類の寿命を延長すること、もうひとつは空力性能の向上による高速走行時の姿勢安定性の向上のためである。副次的作用として、ゴルフバッグが搭載可能なトランクが用意され、スペシャリティーカーとしても高い実用性を有している。 当時のスーパースポーツの多くは車中心の考え方で設計されており、運転姿勢や快適装備などでドライバーに負担を強いる部分が多数あったのに対し、本車ではそれを考慮してドライバー中心のスポーツカーとすることを目標とした。 たとえばスタイリング上の特徴に、F-16戦闘機のキャノピーをモチーフとしたフロントウインドウがあり、従来のスーパーカーと比較して運転席からの視界が良好である。実際に運転席からの水平方向の視界は311.8度ある。
※この「設計思想」の解説は、「ホンダ・NSX」の解説の一部です。
「設計思想」を含む「ホンダ・NSX」の記事については、「ホンダ・NSX」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/03/26 23:32 UTC 版)
リッチ・ヒッキー (Rich Hickey)がClojure言語を設計した目的は、既存のJavaプラットフォーム上で動作して、並行コンピューティングができる、関数型のLISP系の言語を作ることである。 Clojure言語が並行コンピューティングを実現する手法は、不変(イミュータブル)な状態の連鎖という概念によって特徴づけられる。状態が不変であるため、ひとつの状態に対して複数の操作を並列に行うことができ、並列性という問題が「状態遷移の管理」になる。そのため、Clojure言語には、状態遷移に関して明確な定義をもつ可変な参照型がいくつか用意されている。
※この「設計思想」の解説は、「Clojure」の解説の一部です。
「設計思想」を含む「Clojure」の記事については、「Clojure」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/02/08 17:17 UTC 版)
「ライトニングネットワーク」の記事における「設計思想」の解説
ペイメントチャネルは、その参加者がブロックチェーンにトランザクションを公開することなく相互に資金を送り合うことを可能にする。これは協調性に欠ける参加者を罰することにより実現される。チャネルを開いたとき、参加者はファンディング(入金)をしなくてはならない(ブロックチェーン上のファンディングトランザクション)。CheckSequenceVerify や CheckLockTimeVerify などのタイムベースの拡張スクリプトがこの懲罰を可能としている。 ビットコインのブロックチェーン上にある十分大きなチャネルのネットワークがあること、およびビットコインの利用者達が少なくとも一つの開かれたチャネルを持つことによってこのグラフに参加していることを前提とすると、無限に近い額のトランザクションが内部で作成可能であろう。ビットコインのブロックチェーン上に早期に送信されたトランザクションだけが、非協力的なチャネルの相手方である。 ライトニングペーパーより Bitcoin Improvement Proposals(英語版)のCheckSequenceVerify(CSV) が、CSVとライトニングを用いたハッシュタイムロックコントラクトに詳しい。
※この「設計思想」の解説は、「ライトニングネットワーク」の解説の一部です。
「設計思想」を含む「ライトニングネットワーク」の記事については、「ライトニングネットワーク」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/04/03 05:59 UTC 版)
彼女は、ロシア構成主義の建築や美術の強い影響を受け、コンセプチュアルで空想的なものを現実空間に出現させ、見学・利用者に驚きを与えている。かつては、同じく脱構築主義者であるダニエル・リベスキンド同様に、実際の建築作品ではなく、建築思想の提唱者として、また過激なコンセプトを示した図面の製作者としてもっぱら知られていた。 無数の道路やパイプのようなラインがゆるやかに折れ曲がり交差し重なり合いながら高速で流れるイメージや、近未来的で巨大な有機体状の構造物などを描いたドローイングを特徴とする。 彼女のプロジェクトを担当した経験を持つ金田充弘(2012年当時アラップ東京事務所に在籍していた構造エンジニア)によると、「形へのこだわりはもとより、建築とファサードの融合が非常に大切」としているという。 一方でロンドンにある事務所(2015年7月現在)は古風なレンガ造りの外観となっている。東京(千代田区)にも事務所を持つ(2015年7月現在)。
※この「設計思想」の解説は、「ザハ・ハディッド」の解説の一部です。
「設計思想」を含む「ザハ・ハディッド」の記事については、「ザハ・ハディッド」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/11/09 10:19 UTC 版)
姚は1つの物件でも業者のストーリー、所有者のストーリーや思想があると考えており、建築に「カメラのレンズ(を通した視点)」と「(街の)ストーリー性」を反映している。 長年の友人であるTVプロデューサーの王偉忠(中国語版)は上海で姚の建築展に参観し「姚は建築を一つの舞台と考えている」との印象を受けたと述べている。かつてはニューヨークフィルムアカデミーで短期間だが映画を学んでいた。 建築家ではない兄弟も建築設計を学んでいたが、幼少時の両親が自由発想を許容していたからだと述べている。重病を患い週に1度しか登校できなかったときも、担任教師は姚に叱責や懲罰をしなかったといい、束縛なく育ったことが人生に影響を与えたと述べている。自宅療養中は辞典から漫画まで幅広く読書に耽った。高校時は美術に興味をもち、画廊に通っていたが、進学先の東海大学には美術学科がなく建築学科を選択した。当時は厳格な校風の国立台湾師範大学にしか美術学科がなく、自分には合わないと諦めている。 姚は自身が頻繁な海外渡航で使っている台湾桃園国際空港が好きではなかった。駅や空港の建築は流動性を優先し、刹那的な感覚に囚われるためとしている。高鉄彰化駅の設計を受けた際は、駅では一般的な柱のない開放感とは逆に柱を多用したデザインを取り入れた。当地の名産である花卉を意識し、駅舎を温室に、内部の柱を花やサトイモに見立てた。 後年烏鎮戯劇節(中国語版)を「東洋のアヴィニョン演劇祭」とすべく戯劇節発起人も務めた台湾の演出家頼声川は烏鎮の劇場こけら落とし公演のために友人だった姚に設計をオファーした。姚は頼の代表作品「如夢之夢(中国語版)」と烏鎮の18、19世紀の情景を思い浮かべながらデザインしたという。 台北の聯合報大楼は建て替えで姚の設計による聯合・大於へと生まれ変わったが、姚は初めて社を訪問した際に地下室の印刷工場が印象に残ったため、活版印刷の活字棚に着想を得てビル外観のデザインに応用した。
※この「設計思想」の解説は、「姚仁喜」の解説の一部です。
「設計思想」を含む「姚仁喜」の記事については、「姚仁喜」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/02/21 08:11 UTC 版)
ユーザインターフェースである画面、帳票、データベース、ファイルに関わる入出力は、ある決まった処理手続きを踏んでいる。従って個々のロジックをプログラマがコーティングするのではなく、コンピュータシステムによってソースコードを自動生成することが可能である。自動生成のためには、事前にデータディクショナリを中心としたリポジトリに、その入出力に関わる設計情報を事前に登録をして置く。自動生成の際には、その設計情報から、その入出力に適合したソースコードを自動生成することになる。また、業務アプリケーションは、オンラインの場合、データベースをメンテナンスする、問い合わせる、バッチの場合は、マッチングする、サマリする、データを編集する、帳票を出力するといった機能に分類することができる。このようなものをパターンとして部品化しておき、その部品を自動的に組み合わせることによって動作するプログラムを自動生成することが、可能になるといった基本的な考え方が、CANO-AIDの設計思想である。
※この「設計思想」の解説は、「CANO-AID」の解説の一部です。
「設計思想」を含む「CANO-AID」の記事については、「CANO-AID」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/08/08 03:45 UTC 版)
「X Window System」の記事における「設計思想」の解説
1984年、Bob ScheiflerとJim GettysはXの基本原則を以下のように定めた。 実際のアプリケーションでどうしても必要という場合以外は、新機能を追加するな。 機構が何でないのかを定義することは、何であるのかを定義するのと同じように重要である。あらゆる要求に答える必要はない。むしろ、互換性を維持した状態で拡張可能にしておけ。 1つでも例を挙げて一般化したほうが、全く例を挙げずに一般化するよりもマシである。 問題が完全に把握できないときは、解決策も提供しないのが最善の方法である。 10%の作業で望みの90%の効果が得られるときには、その解法を使え。 複雑さは可能な限り分離せよ。 方針よりも機構を提供せよ。特にユーザインタフェースについての方針はクライアント側に任せておけ。 先頭の原則は、X11の設計時に「具体的アプリケーションがそれを必要としていることを知っている場合に限って、新たな機能を追加せよ」に修正された。 Xはだいたいにおいてこれらの原則に従ってきた。参考実装は拡張性と改良を視野に入れて開発されており、1987年当時のプロトコルとほぼ完全な互換性を維持している。
※この「設計思想」の解説は、「X Window System」の解説の一部です。
「設計思想」を含む「X Window System」の記事については、「X Window System」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/11 02:27 UTC 版)
開発者のまつもとゆきひろは、「Rubyの言語仕様策定において最も重視しているのはストレスなくプログラミングを楽しむことである (enjoy programming)」と述べている。 Ruby には Perl や Python とは決定的に違う点があり、それこそが Ruby の存在価値なのです。それは「楽しさ」です。私の知る限り、Ruby ほど「楽しさ」について焦点を当てている言語は他にありません。Ruby は純粋に楽しみのために設計され、言語を作る人、使う人、学ぶ人すべてが楽しめることを目的としています。しかし、ただ単に楽しいだけではありません。Ruby は実用性も十分です。実用性がなければ楽しめないではありませんか。 — まつもとゆきひろ、Ruby プログラミング入門 まえがき 監修者よりのページ ただし、まつもとによる明文化された言語仕様は存在しない。Perlのモットー「やり方はいろいろある (There's More Than One Way To Do It; TMTOWTDI)」は「多様性は善 (Diversity is Good)」というスローガンで Ruby に引き継がれてはいるものの最重要なものではないとも述べており、非推奨な手法も可能にするとともに、そのような手法を言語仕様により使いにくくすることによって自粛を促している。 また、まつもとは『まつもとゆきひろ コードの世界 スーパー・プログラマになる14の思考法』でもRubyの開発理由を次のように述べている。 「なぜRubyを開発したのか」。そのように問われるときに、もっとも適切な答えは、Linux開発者であるリーナス・トーバルズの言葉と同じではないかと思います。『それがぼくには楽しかったから』 — まつもとゆきひろ、まつもとゆきひろ コードの世界 スーパー・プログラマになる14の思考法 P.9 また、英語圏の開発者の間ではMINASWAN (Matz is nice and so we are nice. 和訳: まつもとがナイスだから我々もナイスであろう) の標語が用いられている。 「Python、PHP、Perlでは静的型を導入しているため、Rubyも型を導入するべきでは」と長年言われているが、まつもとは「Rubyに型を取り入れたくない。DRY (Don't repeat yourself)ではないから」「型宣言することはコンピュータに使われているような気になる」と否定的であり、2019年5月現在Rubyに静的型が導入される予定はない。 クラス名はアルファベットの大文字から始めるという制約があり、日本語などの非ASCII文字のみでクラス名を定義する方法がない。この件についてまつもとは以下のように語っており、英語を共通言語として使うべきであるという立場を表明している。 2文字目以降は自由なので、もしどうしても日本語が使いたいのであれば、少々不自然にも見えますが、先頭だけ大文字の接頭辞をつけるのはどうでしょうか。しかし、私個人としては、日本語の変数名などを使うことは、そのプログラムを読む人の範囲を日本語が読める人に限定してしまうことになるので、ひどくもったいないのではないかと感じています。そこで、この点を積極的に改善する気にはなれないのです。
※この「設計思想」の解説は、「Ruby」の解説の一部です。
「設計思想」を含む「Ruby」の記事については、「Ruby」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/16 03:45 UTC 版)
「ドラゴンクエストシリーズ」の記事における「設計思想」の解説
第1作製作時、初めてRPGに触れるユーザーに対して、ユーザーが参考材料にするであろう海外のRPGはハードルが高すぎるという判断から、堀井自ら『ファミコン神拳』でRPGというゲームの説明をするなど、間口を広げる方針を取った。これはシリーズ全体の方針ともなり、実際に、第1作から『III』までの通称「ロト三部作」は、ファミコンで初めてRPGに触れるユーザーに対して、RPGの面白さ、奥深さを理解してもらえるように、実際にプレイしながらRPGのリテラシーを習得できるように意識して作られている。 ロトシリーズ以降もこの方針は貫かれ、『IV』製作後には今更方針を変えることもないだろうと判断したこと、万人向けに作っているため、難しすぎる謎は全部ボツにしていることを表明している。『X』でオンライン化が決まった際にも「いかに敷居を低くするか」が最初のテーマになっている。
※この「設計思想」の解説は、「ドラゴンクエストシリーズ」の解説の一部です。
「設計思想」を含む「ドラゴンクエストシリーズ」の記事については、「ドラゴンクエストシリーズ」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/12/27 00:54 UTC 版)
第三世代のビデオゲームでは、ゲームの仕組みに関するチュートリアルはまれであり、代わりにプレイヤーはそのステージのデザインによって新しいビデオゲームに適応していた。『メトロイド』、『ゼルダの伝説』、『スーパーマリオブラザーズ』などのファミコンゲームの最初のステージは、プレイヤーがゲームの仕組みを学びながら進められるように設計されている。スーパーマリオブラザーズは、マリオの主人公としての初の横スクロールゲームであり、宮本茂がデザインした最初のゲームのひとつでもある。スーパーマリオブラザーズの第1ステージでは、プレイヤーに無差別に障害物を突きつけるのではなく、ステージを進めながらプレイヤーに接するように導くことで、さまざまな危険やオブジェクトを紹介している。 宮本は、プレイヤーが「自分のしていることを徐々に自然に理解する」ために必要なすべてのものを含み、より自由にプレイできるようにして、「自分のゲーム」になるようにWorld 1-1をデザインしたと説明している。
※この「設計思想」の解説は、「World 1-1」の解説の一部です。
「設計思想」を含む「World 1-1」の記事については、「World 1-1」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2020/10/15 08:21 UTC 版)
人の心の動きこそが、豊かな精神性を育むものであり、建築空間に感動を生むような「しかけ」や、経験の場所を作ることが役目だと考え、建築を通じ、感動、癒し、喜び、哀愁などの人間の心の動きを呼び起こすものを創ることを目指している。自然と建築の関係をどう取り入れ、どう遮断するかを常に意識し、両者の接点をいかにデザインして、人の心を動かす「しかけ」をどのように創るかという点を最も重視している課題だと考えている。
※この「設計思想」の解説は、「大塚泰子」の解説の一部です。
「設計思想」を含む「大塚泰子」の記事については、「大塚泰子」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/10/09 05:10 UTC 版)
かつては以下のようなメリットがあると考えられた。 大きな翼面積を確保できる。つまり翼面荷重を小さく抑えられる(エンジンが重い上に非力で、なおかつプロペラの効率も悪い場合はその方が都合が良い)。 合計の翼面積が同じ単葉機と比べると、一枚あたりの翼を小さく(つまり強く)できる。 前後両方に大きな固定翼面があるため、ピッチ(縦ゆれ)方向の安定性が自然と良くなる。 しかし実際には、 前の翼が気流を乱すため後の翼の効率が落ち翼面積の割には揚力が得られない上に、前の翼の乱流により後ろの翼がゆすられ不安定なダッチロールが起こることがある。(近年のタンデム翼機は、この気流の乱れを避けるため、前後翼の縦方向の取り付け位置が、同列になっていないのが普通である)。 大きな翼面積を得たければ、主翼を複葉(や三葉)にすれば良い。また複葉の翼は桁構造によって強くできる。 ピッチ方向の安定性(と操縦性)を得るには尾翼もしくは先尾翼で充分である。
※この「設計思想」の解説は、「タンデム翼機」の解説の一部です。
「設計思想」を含む「タンデム翼機」の記事については、「タンデム翼機」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2017/12/26 17:07 UTC 版)
「Axiom (数式処理システム)」の記事における「設計思想」の解説
Axiom においては、オブジェクトはすべて型を持っている。型は数学的な「構造」であり、例えば環、体、多項式などがある。またデータ構造はリスト構造、木構造、ハッシュテーブルなど、計算機科学のものが実装されている。 関数は引数として型そのものを取ることができ、型はその返り値にもできる。たとえば Fraction という関数は引数として IntegralDomain を取り、その引数の分数からなる体を返す。また、有理数からなる大きさ 4 × 4 の行列のなす環は SquareMatrix(4, Fraction Integer) によって生成できる。その環での演算を行う場合、1 は単位行列、A^-1 は A の逆行列 (存在する場合) であると解釈される。 複数の演算が同じ名前を持つことができ、それらはオブジェクト指向プログラミングの場合と同様、引数と求められる結果の型によって区別される。 Axiom の拡張言語として SPAD と呼ばれるものがある。Axiom に実装されている数学的な知識はすべて SPAD で書かれている。Axiom の対話的実行環境は、SPAD の概ね全てを理解する。 SPAD はかつて A#、続いて Aldor という名前で開発されていた。後者は現在も、SPAD の代わりに Axiom から使うことができる。しかし Axiom とは異なるライセンスで公開されている。
※この「設計思想」の解説は、「Axiom (数式処理システム)」の解説の一部です。
「設計思想」を含む「Axiom (数式処理システム)」の記事については、「Axiom (数式処理システム)」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2021/08/15 02:47 UTC 版)
仕事の流れの阻害を最小限にすること、おもしろみのない作業を自動化すること、不要な設定変更をなくすこと、シンプルさに基づいた理性的な編集作業を達成することを目標にしている。この目標を達成するために必要のない慣習は守っていない。
※この「設計思想」の解説は、「Scribes」の解説の一部です。
「設計思想」を含む「Scribes」の記事については、「Scribes」の概要を参照ください。
設計思想
出典: フリー百科事典『ウィキペディア(Wikipedia)』 (2022/06/12 23:00 UTC 版)
公園内に植える樹木や植物についてはその土地に適した「自然木」でなければならない、人の眼を楽しませる花弁花樹を必要とする、とした。地域の自然特色を生かす設計手法に努めた。また公園内の園路は主要なものは3〜6間(5.45-10.91メートル)、細園路は1間(約1.82メートル)内外の幅員もたせること、坂道を設計する際は、かりに勾配が緩くても同一勾配を60間(1090.8メートル)以上続けてはならないので約30間(約545.4メートル)毎に2〜3間(3.64-5.45メートル)以上の平地若しくは緩勾配地を置くこと、を述べている。さらに公園の設備については運動器具をとりいれること、また外柵を堅固にすることを強調している。また公園の設計には経営の方針を最初から考えるべきであるとした。材料では、特に石は安価な相豆石を好んだ。
※この「設計思想」の解説は、「長岡安平」の解説の一部です。
「設計思想」を含む「長岡安平」の記事については、「長岡安平」の概要を参照ください。
「設計思想」の例文・使い方・用例・文例
- 設計思想のページへのリンク