「メカメカリンクで設計しよう」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
メカメカリンクで設計しよう（番外編）： のしのし歩く！ テオ・ヤンセンのビースト機構 今回のお題は、テオ・ヤンセンのストランドビースト。たった1つの動力で、さまざまなリンクを作動させて、まるで動物が歩くようなリンク機構について解説する。（2012/4/25） メカメカリンクで設計しよう（11）： マジックハンドなど面白動作の多節リンクたち 最終回は、多節リンクの解説。マジックハンドや譜面台など、皆さんもおなじみの面白いリンク機構が登場する。（2012/3/9） メカメカリンクで設計しよう（10）： おもちゃで解説。回転＆スライドを自在に操る方法 リンクをうまく使えば、回転＆スライドが自由自在。おもちゃの機構を見ながら、動きの変換を見ていこう。（2012/2/20） メカメカリンクで設計しよう（9）： スライダー穴を工夫して、計画通りの動作でニヤリ リンクとスライダー、どちらから操作しても狙
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
初めてのデータベース設計 記事一覧 | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
東大 理学部情報科学科／大学院情報理工学系研究科｜情報科学科NAVIgation
3年生の冬学期になると、名物の「CPU実験」が始まります。ミッションは「半年かけてできるだけ速いコンピュータを作れ」。 4〜6人に分けられた各チームに、FPGA基板と道具がいくつか配られ、それから翌年3月に開かれる発表会までの間に、与えられた課題プログラム（例年はCGプログラム）が動くように独自のコンピュータを設計・製作します。 CPUはもちろん、コンパイラ、アセンブラやCPUシミュレータなどのツールまでを分担して設計・実装するので、学生実験としてはかなり難しいものですが、実験を通してコンピュータの原理を根底から体得できます。また、半年にわたるプロジェクトワークがたいへん貴重な経験になります。 この楽しい実験の様子を紹介しましょう！ NO.1CPUを作る NO.2コンパイラ、 ツールを作る NO.3動作をテストする NO.4【ミニ知識】 コンピュータの動作原理
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
Unix Philosophy と Node.jsのモジュールの作り方 - from scratch
The Art of UNIX Programming 作者: Eric S.Raymond,長尾高弘出版社/メーカー: アスキー発売日: 2007/06/19メディア: 大型本購入: 4人 クリック: 91回この商品を含むブログ (62件) を見る TL;DR Unix Philosophyにおいては、「一つのことをうまくやり、協調する仕組みを持つ」という事が大事 Node.jsのモジュールにおいても同じで、「一つのことをうまくやる、Stream APIで協調する」と良い 「一つのことをうまくやる」にはどうするのが良いのか、ということで substack のモジュール実装例 Simple と Easyの違い ちょっと今回長くて文字が多いので、最初と最後にまとめを用意しました。時間がない方はこれを読むだけでもいいかと。 Unix Philosophy さてさて、Unix Philosoph
機構と方針の分離 - Wikipedia
機構と方針の分離[1]とは、計算機科学における設計原則の1つ。機構（操作の認可と資源配分を制御するシステム実装部分）は、どの操作を認可するかやどの資源を割り当てるかといった決定を行う際の方針を表すべきでない（あるいは過度に制限すべきでない）という考え方である。 主にセキュリティ機構（認証と認可）に関して議論されるが、様々な資源配分問題（CPUスケジューリング、メモリ割り当て、Quality of Serviceなど）にも当てはまる考え方であり、オブジェクト抽象化全般に関わる課題でもある。 機構と方針を分離すべきだと主張した計算機科学者として Per Brinch Hansen がいる[2][3]。 1987年の論文で Artsyらは「機構と方針を極端に分離」させたオペレーティングシステムの設計技法を論じた[4][5]。 Chervenakらは2000年の論文で、「機構中立性」と「方針中立性
Unix思想 - Strategic Choice
Unix思想とは、Unix文化が伝承している、優れた設計やプログラミングを行うための、実践的で経験に根付いた「技」のことです。Unix哲学とも呼ばれています。ただ、それらは公式的なメソッドや標準のなかではなく、「ことば」にならない半分無意識の知識のなかにありました。いわゆる形式知ではなく暗黙知であったこの「知」を、エリック・レイモンドさんが書籍「The Art of UNIX Programming」で17個の原則としてまとめてくれています。プログラミング・設計の際の「心がけ」として自分にインストールすべく、写経します。一覧モジュール化の原則明確性の原則組み立て部品の原則分離の原則単純性の原則倹約の原則透明性の原則安定性の原則表現性の原則驚き最小の原則沈黙の原則修復の原則経済性の原則生成の原則最適化の原則多様性の原則拡張性の原則Unix思想のまとめ参考The Art of UNIX Pro
アーキテクチャ設計の難しさについて - arclamp
アーキテクチャについては、以下のパワポを見て頂くとして。 なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423 from yusuke suzuki アーキテクチャ設計を要約すると「"何をやるか"と"どうやるか"のバランスを取る事」となります。 "何をやるか"というのは"システムのミッション"のことであり、ソフトウェア品質モデルで言うところの"利用時の品質"、つまりはシステムのユーザーが何を達成したいのかということです。これは「このシステムが動き出した時、どんな価値を生み出すべきか」を考えることになります。 次に"どうやるか"というのは、2つの話があると思っています。1つめは"静的な構成"としてのどうやるか。2つめは"動的なプロセス"としてのどうやるか。 "静的な構成"というのはクラス構成であり、設定ファイルの構成であり、フレームワークの構成であり、つまり、システ
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!
「プログラミング経験のない人がソフトウェアの設計をすること」の是非について、どう考えますか？ もしかしたら、このブログの読者であれば、プログラミングが出来ないのにソフトウェア設計をするなんてありえない！という意見の方が多いかもしれません。私もそういう意見ではあったのですが、色々な人と話をするにつけ、どこか違和感を感じていました。 その違和感の正体を探るべく、ソフトウェア設計とプログラミングについて考えてみました。そこでわかったことは「ソフトウェア設計」について、人それぞれに捉え方が違うために、話が通じないことがあることから産まれた違和感だったということです。 この記事では、私の考える「ソフトウェア設計とは何か」について書きました。 ソフトウェア開発はすべてが「設計」である モノづくりにおいて、大きく工程を２つに分けるとしたら「設計」と「製造」に分けることが出来ます。何をどう作るかを決めるこ
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト容易性のためのシステム設計