【第二版】Houdiniで建築(入門編: ジオメトリ間のデータやり取り) - Qiita
はじめに はじめましてQiita。ドイツで建築学生をやっているTaroです。 Houdiniを触り始めたのは去年の11月頃です。 この1年、敷地,作品のモデリングからダイアグラム,図面生成に至るまで、建築に関わる様々なシーンで、Houdiniを活用しました。 しかしこの記事を執筆時点まで、ほとんど誰も建築界隈でHoudiniを使っている人がいないので、本当に手探り状態で辛い1年でした。 でもHoudiniが連れて行ってくれる世界は、そんな気持ちを吹き飛ばしてくれるエキサイティングなものでした。 この記事は、 "建築関係の人に、Houdiniを広めたい！" と思って書いたものです。 それゆえに、細かなTipとか技術的なことはあまり書かれていません。申し訳ありません。 この記事のターゲット 建築関係の方で、最近"Houdini"をよく耳にする方。 (この記事にたどり着いた時点で、仲良くなれそう
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
データ圧縮法概説 目次
最終更新日：2001年7月2日 第1章へ webmaster@snap-tck.com Copyleft (C) 2000 SNAP(Sugimoto Norio Art Production)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
