【第二版】Houdiniで建築(入門編: ジオメトリ間のデータやり取り) - Qiita
はじめに はじめましてQiita。ドイツで建築学生をやっているTaroです。 Houdiniを触り始めたのは去年の11月頃です。 この1年、敷地,作品のモデリングからダイアグラム,図面生成に至るまで、建築に関わる様々なシーンで、Houdiniを活用しました。 しかしこの記事を執筆時点まで、ほとんど誰も建築界隈でHoudiniを使っている人がいないので、本当に手探り状態で辛い1年でした。 でもHoudiniが連れて行ってくれる世界は、そんな気持ちを吹き飛ばしてくれるエキサイティングなものでした。 この記事は、 "建築関係の人に、Houdiniを広めたい！" と思って書いたものです。 それゆえに、細かなTipとか技術的なことはあまり書かれていません。申し訳ありません。 この記事のターゲット 建築関係の方で、最近"Houdini"をよく耳にする方。 (この記事にたどり着いた時点で、仲良くなれそう
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
うさださくら
このサイトは " servers " （ http://servers.ghost.ai/ ）によって運営されています。servers では随時サーバを募集しています。 このページはリンクフリーです（リンクにあたって許可を必要としません）。 ルートページ以外のhtmlに直リンクしても構いません。 SSTP 技術は 2000/12/23 より Web 上で全ての仕様が公開されています。 Direct SSTP 技術は 2001/4/14 より Web 上で全ての仕様が公開されています。 ヘッドラインセンス技術は 2000/11/28 より Web 上で全ての仕様が公開されています。 その他あらゆる仕様は公開されているので今さら自分が考えたと言っても遅い。 SHIORI とか起動中ずっと喋りまくるとか見たくないサイトを無理矢理ジャンプさせて見させるとかおすすめリスト作るとかその程度の発想で特許
redmineを使ったチケット管理の失敗のさせ方 - 文系プログラマによるTIPSブログ
Redmineを使ったチケット管理をしている方必見！ジワジワとredmineを壊して失敗させていく方法を公開しちゃいます。 チケット管理のアンチパターンとベストプラクティス - Javaプログラマのはしくれダイアリー こちらの記事の便乗ですが、私の今までのチケット管理経験から「こうすると失敗するよ」という実例を挙げてみようと思います。私はほぼredmineしか触っていないので、今回はredmineでのお話となります。 ※ 冒頭の記事と被る内容も多々有りますが、気にせず列挙していきます。 ※ 主にSI業界に関するチケット管理のお話です。 ※ 大規模プロジェクトは想定していません。多くても20人以内程度を想定した記事です。 これであなたも無事、失敗できる！ 進捗率をユーザの裁量で更新させる 対象バージョン「なるはや」 チケットの内容が途中から変わる 増殖するプロジェクト固有のトラッカー 「本日
C99の仕様
長い歴史を持ちながら、依然として人気の高いC言語。その最新仕様の情報にキャッチアップするための連載スタート。今回は1999年に策定された「C99」を取り上げる。 連載 INDEX 次回 → C言語（以降、単にC）はDennis Ritchieによって1969～1973年の間にベル研にて開発されたプログラミング言語である。長い歴史を持つと共に非常にポピュラーな言語で、プログラマーでCを知らない人はまずいないと言っていいだろう。プログラミング言語のシェアを調査しているTIOBEでも、ここ最近は常に1、2位を占めている。 Cの言語仕様は今から25年近く前である1989年に初めて規格化され、これは一般に「ANSI-C」と呼ばれている。ANSI-Cは長らくCの言語仕様のスタンダードの位置を占め、世の中の大半のプログラマーは、このANSI-Cに慣れ親しんでいることだろう。しかし、実はCの言語仕様はその
OpenSearch - Wikipedia
OpenSearchはシンジケーションとアグリゲーションに適する形式で検索結果を発行することを可能にする技術群である。これはウェブサイトと検索エンジンが標準的でアクセス可能な形式で検索結果を発行する方法である。OpenSearchはAmazon.comの子会社A9によって開発され、最初のバージョンである、OpenSearch 1.0は2005年5月のWeb 2.0においてジェフ・ベゾスにより公開された。OpenSearch 1.1のドラフトバージョンは2005年11月から12月にかけてリリースされた。OpenSearch仕様はクリエイティブ・コモンズ・ライセンス下で、A9によりライセンスされている。 概要[編集] OpenSearchは以下から構成される: OpenSearch Descriptionファイル: 検索エンジンを特定し、説明するXMLファイル。 OpenSearch Quer
プログラマーは皆、常に秘密や嘘を抱えている - totopon114689の日記
プログラマーは皆、常に秘密や嘘を抱えている。 これは間違いない。 基本的には誰にも話さないが、 （家族や友人などプログラムを知っていない人間に話しても分からない、という事もある） プログラマー同士の飲みの席などで、過去の笑い話として酒の肴になる事はある。 秘密や嘘の傾向には幾つかのパターンがある。 1) 仕様があいまいな場合の適当なコーディング 仕様があいまいな機能を実装する場合、想定していたものよりもプログラム量が膨大になる事はよくある。 また、細かいパターンや想定外のケースに対し、どのようにプログラム的対処を行うべきか？ 洗い出しているとキリがない場合もある。 仮に事前に洗い出していたとしても、 「ケース自体は洗い出せているが、具体的にどのようなエラーメッセージを表示すべきか？」 などといった、その先がまたあいまいになっている場合もある。 このような場合、本来であれば決裁権のある人間に
同じ開発チームの「批評家」とどう接すべきか悩んでいる
同じ開発プロジェクトのメンバーに、頭でっかちで、口は達者だが、まったく手を動かそうとしない、いわゆる「批評家」な人が居る。その人とどう接したら良いのかわからず、悩んでいる。（以下、「先生」と呼ぶ） 先生はあまり技術スキルが高く無かった。先生が担当する部分のシステム仕様や、そのシステムに関連するスキルの習得状況が芳しくないことと、そもそも基本的なプログラミングスキルも、低いとは言わないが、安心してまかせられるレベルではない、ということが分かってきたため、最終的には、スキルが求められる部分については、分割して他の人が分担して持つことになった。 先生はそれなりに時間ができ、スキルアップのために技術書を読み始めたようだった。それはとても良いことなのだが、どちらかというと、はじめての◯◯、とか、猫でもわかる◯◯、等を読むべき技術スキルだったにも関わらず、読み始めたのがデザインパターンやリファクタリン
ゲームサウンドの容量を減らすには 〜ステレオ／モノラル編〜 - スタジオ・サニーサイド
ラジオ体操で全身筋肉痛。こんにちは。banです。 えーちょっと今回から方針を変えまして、 サウンドが専門外のゲームクリエイターに、ゲームサウンドの取り回しのアレコレを知ってもらう、 というようなテーマで色々書いてみたいと思います。 ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ※ ゲームの音屋の仕事に常時ついて回るのが「容量」「データサイズ」という問題ですね。 今はゲームの容量も肥大化して、昔のゲームでは必須だった爪に火を灯すがごとき容量倹約はせずとも良くなりましたが、 ダウンロード配信という新たな事情も発生してますので、すいません！容量減らして！という要望は時々あったりします。 最近も、とあるプロジェクトでクライアント様から 「サウンド容量をどうにか減らしたいんですが、どうすればいいですか？」 という相談を受けたことがあったのですが、 サウンドファイルの基本的な知識があれば、 音屋でなくとも容
[悪徳商法？支店]: エンジニアのモチベーションを根こそぎ奪う！たった７つの魔法の言葉
１．テスト書かなくていいので、工数減らしてください。 ソフトを作る以上、なんらかのテストは必要です。実行して結果を見るとか、ブラウザで表示するとか。その確認を楽にするためにテストを書くのに、テストを書かないからといって工数が大幅に減るわけではありません。そして、いざバグが発生したりすると、切り分けのために工数が必要になり、「テストが無い部分のチェックの必要」や「不安」がエンジニアのモチベーションを削って行きます。 結局のところ、「バグが発生しないことを前提に」スケジュールが組まれるだけです。 ２．とりあえず動けばいいです。 とりあえず動いたとして、特定の条件で発生する致命的なバグを許してくれるのか許してくれないのか、要求側の胸三寸です。実験レベルと商用レベルでは考慮すべき障害のレベルや影響範囲が異なるのですから、何を求めるのか明確にしないと、ソフトウェアは動きません。なぜなら、コンピュータ
糞ゲーはだいたいこういう流れでプロジェクトが進む。
とりあえずプロデューサが作りたいゲームを語る。酒の席だったりする。 それを何となくプランナに伝えて営業用資料を作る。この過程で何度も何度もあーでもないこーいうつもりでもないと言いながらもできあがる資料は抽象的でなんとなくそれっぽい絵とどこかで見たようなシステムに独自っぽい名前を付けてるだけのすっからかんなペラい物になる。本音を言うと「ポケモンを作る」と言われる方が楽だ。「作りたい本人が説明できない、今までにないような独自のゲーム」を作る事になるとバグとか糞とか以前に完成しない。 そのペラい資料をもって営業に行くがすんなりは決まらない。この間はいい感じだねって言ってたじゃんって展開も。そのまま下にも同じ事を言われる。 決まらないがとりあえず作り始めてとデザイナとプログラマに投げられる。とりあえずジャンル名くらいしか決まっていないので色々聞きながら作ってみる。もちろん面白いとかつまらない以前の
誰も幸せにならない「クリエイターかるた」が話題に - ゴールデンタイムズ
など、リアルすぎて見ているこっちが苦しくなってくるものも。 読んだ人からは 「おいやめろ、心が痛い」「胃がギュッてなる」 といったコメントも寄せられていた。 こうして今日も、クリエイターたちの尊い自己犠牲によって 社会はつつがなく回っているのであった……。 http://nlab.itmedia.co.jp/nl/articles/1205/15/news102.html 秀逸な札 抜粋 デザイナー あ アウトラインで来た文字原稿 え 絵は描けません。 か カッコいいのつくってくださいとりあえず こ コンペなのに校正がある さ 寂しいから余白埋めてください せ SECOM解除しなきゃ… そ 素材ファイルがjpg な なるほどですねが口癖 ひ 開くと落ちるファイル み 「皆これくらいできるよ？」 ろ ロゴ画像.ppt 映像制作者 あ 明日っていうのは
ＲＦＣ日本語版リスト
リンク上の問題や追加情報があるようでしたらどしどし連絡してください。 インターネットに散らばるＲＦＣの 日本語訳（和訳）のリンクリストを作りました。 多分、同じ翻訳で、コピーが複数あると思えるのはまとめて１行にしています。 （高橋邦夫さんが訳したＲＦＣ１８５５はあまりにもコピーが多いので一部のリンクのみ掲載しています） 同じＲＦＣを、多分別の人が翻訳したと思えるのは別の行にしています。 時代の流れでなくなったページもあります（場所が変わって見つかっていないだけかもしれません）。 [日本語訳]が付いていない所はそんなページと思ってください。 ソースにはコメントとしてＵＲＬを残してあります。 いずれかのアーカイブを探せば見つかるかもしれません。 これらの日本語訳は完全なものとは限りません。 間違って翻訳していたり、 途中だけ翻訳されてたり、翻訳の途中で中断・中止してる事もあります。 翻訳の公開
データ圧縮法概説 目次
最終更新日：2001年7月2日 第1章へ webmaster@snap-tck.com Copyleft (C) 2000 SNAP(Sugimoto Norio Art Production)
CGファイル概説 目次
最終更新日：2001年5月1日 第1章へ webmaster@snap-tck.com Copyleft (C) 2000 SNAP(Sugimoto Norio Art Production)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
