ダイソンとロックウェルと (通算５０記事目 特集） - skyexのエアロダイナミズムAero dynamism of Skyex
プロフィール skyex 見果てぬ夢を形にするスドリームデザイナーIt is Sdream Designer in shape as for the faraway dream. :yoichi takahashi ダイソンが扇風機を出したという。 それも"翅の無い扇風機"である。昨年秋に発表があったが 日本では冬に向かう時期だったのでしばらくして話題は途絶えた。 季節は めぐり、、、再び、必要になる季節が到来したので最近また露出度は高まってきている。 出典：ダイソン社 ＨＰより。 ”翅がなくて風が出る！”という、マジックにも似たこれまでにない”発明的スタイリング”には少々驚いた。 ”翅が無い”と言うと”かの国では問題になりそうであるが、翅は姿形を変えてちゃんとあることを暴露しておこう！。 円形リングを支えているベースの中にダイソンお得意のインペラー（扇車）が収まっていて、圧縮空気を作りだ
Wiki処理系を作る前に知るべきこと／考えるべきこと - 檜山正幸のキマイラ飼育記 (はてなBlog)
Wiki構文（Wiki記法のルール）は山にようにイッパイあります。 「新たにもう1つ構文を付け加えても別にいいだろう」と考えるか、「これ以上新しい構文を増やしてはいけない」と考えるかは人によるでしょう。僕は、「集約・統合してWiki構文を減らすべきだ」と考えています。それで、標準的なWiki構文としてWikiCreole 1.0を採用し、KuwataさんがCreoleパーザーを実装しています。 ところが、WikiCreoleの構文記述が曖昧過ぎてサッパリわからんのです。Kuwataさんもイライラしている様子。このような状況はWikiCreoleに限りません。たいていのWiki構文の記述はイイカゲンです -- いやっ、仕様書があるだけでマシなのです。イイカゲンな仕様に適合した（conformantな）処理系を作れと言われてもそりゃ困りますわな。 WikiCreole仕様の曖昧さは以前にも話題
建築エコノミスト 森山高至『綾波の部屋は本当に打ち放しなのか？１』
建築エコノミストTwitter mori_arch_econo 以前から気になっていたことに、新世紀エヴァンゲリオンに登場する綾波レイの部屋は 本当にコンクリート打ち放しなのか？というものがありました。 知り合いのアニメマニア、漫画オタクの方々からも 綾波の部屋は殺風景でよい、とか 綾波の部屋みたいになんにも置かないのが理想とか で、彼らはみな綾波レイの部屋はコンクリート打ち放しと思っているんですね。 私の記憶では鉄板張りのような気もしていたのですが、この休み中に検証してみました。 とすると面白いことがわかったんです。 続いて、綾波がシャワーから出てきたシーンです。 ここにも丸いヘッコミがありますね、これはセパ穴といってコンクリート打ち放し建築につきものなので、 きっとみなさんそうコンクリート打ち放しだと判断しているんだと思います。 ところがですね、どうやらこれらの映像を見るかぎりこの内装
技術のエッセンスは，設計 - わさっきhb
技術（あるいは工学）のエッセンスは何か？ 科学と技術の違い？ - 発声練習 リンクされている複数の文章で，答えがシンプルに書かれています．設計（デザイン）です． 外国ではテクノロジーに関する教育は、10〜12年程度が基本で、テクノロジーに限らずその本質である設計についてやその周辺である労働、それからテクノロジーが社会にどういった影響を与えたかという歴史までみっちりと教育している。 科学研究費事業仕分け問題を教育で解決する現時点でのたった一つの最適解 - 技術教師ブログ 『Standards for Technological Literacy』を翻訳した桜井宏氏によると、この本の大部分を占める内容こそ、日本の技術教育に足りない内容という。詳しくは邦訳をお読みいただきたいが、例えば、「技術と科学との違い」「技術の本質はデザイン（設計）にある」「デザインとは相反する複数の要求あるいは制約のバラ
何が「エンジニア的」なのか? - 表道具
「エンジニア主導で作ると、動いたところで満足してしまう。『ちゃんと動いているから、あとは使う人が分かってくれるだろう』と、考えをストップするところがあった。本当は、動いたものを説明して分かってもらい、使ってもらうところまで来てやっと完成なのに」 近藤社長「未熟だったと思う」 はてなが目指す“脱IT系” (1/2) - ITmedia News http://www.itmedia.co.jp/news/articles/0812/24/news044.html 技術者ドリブンってことが、一般の人たちが使えないものを作ることだとしたら、それはプログラマとしてものすごく悲しいことだし、理想がものすごく退化しているように思う。もし技術者的発想ってものがそういうものだとしたら、技術者的発想に価値なんてないと思うんだけど。だって技術者しか使えないんでしょう？ エンジニア的発想は危険な気がしている -
Commercial Hand Dryers
You can update your contact preferences at any time in the Keep in touch section of Your Dyson. If you have a Your Dyson account, you can log in below to manage your contact options.
オブジェクト指向システム分析設計入門
はじめに この本はオブジェクト指向技術を利用してソフトウェア開発することを目指す技術者および管理者のために書かれた本です。プログラムのコードや難しい数式などを排除してあり，図と文章によって基本概念や適用技術を平易に解説しています。オブジェクト指向技術を数学(形式)ぬきで探求する試みといえるでしょう。 本来，オブジェクト指向技術を，瓶から瓶へ水をもらさぬように，正確に伝えるには，数学(型理論)を必要とします。数学的形式化が行われていないと，オブジェクト指向で表面化する問題の議論がかみ合わず空転することが多いからです。あの時はこうだっだ，この時にはああだったと経験則の披露になりかねないのです。やはり何かしらの形式化は必要でしょう。しかし，数学的形式化の苦しみときたら並大抵ではありません。特に，後述するインヘリタンス(継承) や並列などが絡んだあかつきには残酷なのです。私だけかもしれません
アンインテリジェントデザイナー
インテリジェントデザインに対して、アンインテリジェントネットワーク(Unintelligent Design Network, Inc.)がインテリジェントデザイナーは馬鹿であるというジョークを飛ばしたり、Dr. Mark Perakhが「1個部品をはずしたら壊れるようなIrreducible Complexityはデザイナーが出来が悪い証拠」と言ったりと、アンインテリジェントデザイナーという批判は既に、多くなされている。 これに対して、インテリジェントデザインの数学担当Dr. William A Dembskiは反論している。しかし、自爆方向に反論しているようなのだ。 William A. Dembskiは「Intelligent Design is not Optimal Design(インテリジェントデザインは最適デザインではない)2000/02/02」というネット上の記事で次によう
失敗学会 は 事故 不祥事 など過去の 失敗 や 事例に学び、解決を考える 失敗学 を実践する
特定非営利活動法人「失敗学会」は、広く社会一般に対して失敗原因の解明および防止に関する事業を行う。
わたしが知らないスゴ本は、きっとあなたが読んでいる: モノの見方が確実に変わる「フォークの歯はなぜ四本になったか」
モノの見方が確実に変わる一冊。 フォーク、ナイフ、クリップ、ジッパー、プルトップなど、身近な日用品について、「なぜそのカタチを成しているのか」を執拗に追求する。日ごろ、あたりまえに使っているモノが、実は現在のカタチに行き着くまでに途方も無い試行錯誤を経たものだったことに気づかされる。 いわゆるデザインの定説「形は機能にしたがう（Form Follows Function）」への論駁が面白い。著者にいわせると、「形は失敗にしたがう（Form Follows Failure）」だそうな。もしも形が「機能」で決まるのなら、一度で完全無欠な製品ができてもいいのに、現実はそうなっていない。モノは、先行するモノの欠点（失敗）を改良することによって進化していると説く。これが膨大なエピソードを交えて語られるのだから、面白くないわけがない。 たとえば目の前のフォーク。そのカタチ・大きさになるまで延々と進化の
「ソフトウェアは工業製品ではない」、Rubyのまつもと氏が講演 － ＠IT
2009/04/10 ソフトウェアは工業製品ではない――。Rubyの生みの親としてしられるまつもとゆきひろ氏は2009年4月9日、InfoQ主催のイベント「QCon Tokyo 2009」の基調講演で、ソフトウェアと何であり、何でないのか、それはどういう性質のものであるのかを雄弁に語った。 コードとは設計である 「ビューティフルコード」と題した基調講演を行ったまつもと氏は、2007年に共著者の1人として出版した同名の書籍に書いたエッセイに込めた思いを、次のように語る。 「世界に冠たる日本の製造業のノウハウを適用することで生産性を上げることができるに違いないという発想がありますが、ソフトウェアは工業製品ではない。そうした誤解を正していきたい」。 ソフトウェア産業界では、よくエンジニアが何十万人足りないということが言われる。しかし、まつもと氏は、これは工業生産と同じ方法論を当てはめることから来
肉厚と抜き勾配をおさえるべし！（1/3） － ＠IT MONOist
機械設計の基礎知識から、3D CADによるモデリングやCAE解析、3Dプリンタ活用といった実践スキルまでをカバーする、メカ設計技術者のスキル向上を支援する情報フォーラム
オブジェクト指向設計（2008年度）
コンテンツ 第1章 基本的な用語 第2章 オブジェクト指向開発 第3章 設計の問題し 第4章 オブジェクト指向設計の原則 第5章 単一責任の原則 第6章 Visitor パターン 第7章 LSP、DIP、ISP 第8章 パターン技術 第9章 ユースケース 第10章 実例 第1章 基本的な用語 第2章 オブジェクト指向開発 オブジェクト指向開発 オブジェクト指向分析 機能外要求 User インタフェース Student クラスとTeacher クラス Student クラスのソースコード Teacher クラスのソースコード 演習2-1 UserLocator クラスのソースコード 演習2-2 演習2-2 の解答 Teacher.java UserLocator.class 第3章 設計の問題 演習3-1 演習3-1 の解答1（返却値を利用した方法） 演習3-1 の解答2（条件分岐による方
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist
組み込みソフトウェア／ハードウェア開発における技術力の向上、改善・最適化などを幅広く支援する“組み込み開発エキスパート”のための情報フォーラム
デュアルプログラミングとエクソシストゲーム - 檜山正幸のキマイラ飼育記 (はてなBlog)
ここ何年か考えているテーマのひとつが「カジュアルなフォーマルメソッド（語義矛盾は承知）」なんですよ。一連の{テスト(Test), 仕様(Specification), 振る舞い(Behaviour/Behavior)}駆動開発なんて動きは、カジュアルなフォーマルメソッドなんだと僕は捉えているわけですが、もう一歩踏み込んで欲しい感じ、隔靴掻痒の不満もあります。 そこでメイヤーに戻って「契約駆動」とか、あるいは「検証駆動」なんて言葉も使ってみたけど、ナントカ駆動には食傷気味。"Offencive Programming"は、「攻撃的プログラミング」と訳されると真意がまったく伝わらないし、、、 紆余曲折の末、「デュアルプログラミング」って言葉を使うことに（暫定的だけど）決めました。そしてエクソシストゲームは、デュアルプログラミングを説明するために案出した“極端化した比喩”です。 内容： 設計（仕
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: 自己デザインする生命―アリ塚から脳までの進化論: J.スコットターナー (著), 長野敬 (翻訳), 赤松眞紀 (翻訳): 本
フォークの歯はなぜ四本になったか 実用品の進化論 （平凡社ライブラリー 693）
[オブジェクト指向設計原則] - Strategic Choice
ソフトウェア設計私論
プログラム仕様記述論