東京で4月15～16日という日程で、Unite Japanという米Unity Technologies主催のカンファレンスが開催中だ。ゲーム開発は属人性を伴っているものであることを痛感させられたセッションがある。イレギュラーズアンドパートナーズの山本一郎氏が、ゲームエンジンのUnityが普及したがために起きている「炎上案件」にどのように対処するべきかを語った講演だ。同社は、トラブルを抱えたソーシャルゲーム開発プロジェクトの「炎上案件」が発生している場合の処理作業を業務の一つとして行っている。 Unityはゲームエンジンとして、日本では前年対比で500%という驚異的な売上を出し、世界でアメリカに続く、第2位のライセンス契約が結ばれているまでの大成功の状態にある。一方で、「Unityだから、安い、早い、簡単に開発できる」という思い込みも広がっている。優れたゲームエンジンを使えば、優れたゲームが

SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を

このページはコミュニティーの尽力で英語から翻訳されました。MDN Web Docs コミュニティーについてもっと知り、仲間になるにはこちらから。 ` �᪪View in English `R�᪪Always switch to English オリジン間リソース共有 (Cross-Origin Resource Sharing, CORS) は、 HTTP ヘッダーベースの仕組みを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。ウェブアプリケーションは、自分とは異なるオリジン (ドメイン、プロトコル、ポート番号) にあるリソースをリクエストするとき、オリジン間 HTTP リクエストを実行します。 オリジン間リクエストとは、例えば https://domain-a.com で提

プログラミング言語の「型」の定番書と言われる Types and Programming Languages (通称 TAPL) の翻訳本が、ついに 3 月 26 日に発売されます。 型システム入門 −プログラミング言語と型の理論−posted with amazlet at 13.03.01Benjamin C. Pierce オーム社 売り上げランキング: 598 Amazon.co.jpで詳細を見る (↑アフィリエイトなのでクリックするなよ！) (個人的に) 読んで欲しい人たちへ 「型」の教科書ということで、わりと Ruby の対極にあるような内容ですが、Ruby ユーザ (動的型付き言語しか知らない人) にこそ読んで欲しいと思ってます。 PHP しか知らない人が PHP の良さを語るのが滑稽なように *1 、型がないことのメリット・デメリットを語るには、本気で型がある言語の考え方を

Perl › 読み物 PHPやPerlやRubyやPythonなどのスクリプト言語に対して、変数に型がないということを否定的にとらえる人もいるかと思います。特にC言語やJavaなどの静的言語を使ってきた人にとっては、型がないということが不安材料として目に映ることが多いのではないかと思います。 けれども、型がないということは、本当に素晴らしいことです。型がないことによって、たくさんの面倒から解放されるからです。 どのような型の値でも代入できる まず基本的なこととして変数に型がなければどのような型の値でも代入できるということです。つまり、受け取るときに、どのような型の値を受け取るのかを意識する必要がありません。 my $str = 'Hello'; my $num = 1; my $nums = [1, 2, 3]; my $person = {age => 2, name => 'taro'

POST /transactions ↓ PUT /transactions/123 ↓ PUT /transactions/123/committed 「Webを支える技術」p278より引用 実際のシステムでは、より複雑な処理、たとえば複数のリソースにまたがった変更をひとまとまりに扱う、いわゆるトランザクションが必要になるケースもあるでしょう。 主にCollection & Member Resource パターンを用いたトランザクションの実装。 ウィザードなどにも適用可能で、モデルでないリソースになりうる。 例 http://qa.atmarkit.co.jp/q/2555#answer_15110 の id:moro さんの回答より引用 やり方はいろいろありますが、データインポートなど複数のリソースに影響を及ぼす、バッチ的な動きをさせたい場合には「トランザクションリソースを作る」とい

こんにちは、増田です。 今回は"依存性反転の原則"についてObjective-Cで解説します(Objective-Cは筆者が好きな言語です)。 私はこの原則を理解する前は依存関係がスパゲティ状態になったプログラムを書いていました。 プログラムの処理はそうめんのように道筋の立った分かりやすいコードを書いたとしても、依存関係がスパゲティであることがよくあります。そのようなコードを書くと、一箇所を変更するために既に動いているところをいじらなければならず、この際のテストにかかるコストはとてつもなく膨大になってしまいます。 モジュール間の依存は必ずしも悪になるというわけではないですが、「意図して依存を残す」という意識がないと後で痛い目を見ます。依存性を残すところ、断ち切るところを意図してプログラムを組むことができるようになれば、何かしらの変更を迫られた際、変更箇所だけのテストでシステム全体の正常な動

ソフトウェア開発の難しさ ソフトウェアの開発プロジェクトに少しでも関わった人は誰でも知っていると思うが、ソフトウェア作りで最も難しいのは「スケジュール通りにソフトウェアを完成させること」である。 バグがなかなか修正できず泥沼にはまってしまったり、変更され続ける仕様のために当初立てたスケジュール表がまったく役に立たなくなってしまったり、スパゲッティコードに頭を抱えたりということはよくある。出口の見えない状況でソフトウェアエンジニアが過酷な労働を強いられる状況を「デスマーチ」（⁠death march）と呼ぶが、そんな言葉が存在すること自体が、ソフトウェア作りの難しさを表している。 ソフトウェアの開発は「生産活動」ではあるのだが、建物を建てる、料理を作る、野菜を育てる、ハードウェアを組み立てるなどの生産活動とは大きく違うのだ。 建物の場合で言えば、明確に定義された「設計図」がある。そして、その

32bit/64bit両対応のコードを書いていると，よく printf() で引っかかります．"%d"のような"書式"がややこしいからです． というわけで，変数の"型"と"書式"の対応を，表で整理してみました． 型 書式 注意事項 ssize_t %zd size_t %zu intmax_t %jd uintmax_t %ju ptrdiff_t %t signed char %hhd unsigned char %hhu short int %hd unsigned short int %hu int %d unsigned int %u long int %ld unsigned long int %lu long long int %lld unsigned long long int %llu int32_t %PRId32 以下，#include が必要(下記参照) uint3

The data types supported by Windows are used to define function return values, function and message parameters, and structure members. They define the size and meaning of these elements. For more information about the underlying C/C++ data types, see Data Type Ranges. The following table contains the following types: character, integer, Boolean, pointer, and handle. The character, integer, and Boo

先日識者の方に色々教わったのでメモっておきます。知ってそうで知らない、元々よくわからない、そういう方に向けてまとめてみました。 僕がSIにいた頃は大抵｢基本契約｣と｢個別覚書｣ってのがありました。納期とかお金とかそういうのは個別覚書に書かれたりしていました。 開発の契約体系 ｢仕様策定〜開発まで｣と｢保守運用｣で別契約にすることが多い。 ｢仕様策定フェーズ｣で1つの契約にして、別に新しく契約を締結しなおせるほうが望ましい。リスクが低減できる。 仕様策定までは準委任、開発は請負、保守運用は準委任という契約が多い。 ちなみに準委任は｢事務作業の代行｣という意味合い。委任は｢法的効力がある作業｣の代行。サムライビジネスは後者が多い。 別に運用が事務作業とイコールじゃないけど、成果を問わないタイプの契約の場合は役務提供という位置づけになる。 かといって契約で｢僕らのコンサル案を僕らが実施し成果が出

(2014/6/3 追記) MailCatcher がおすすめです。 MailCatcher (追記おわり) メールをどこにも送らずHTMLで保存するSMTPサーバ mocksmtpd.rb - こせきの技術日記 が評判よかったので、気をよくしてgithubでgemを作ってみました。 http://github.com/koseki/mocksmtpd/ インストール方法 $ gem sources -a http://gems.github.com $ sudo gem install koseki-mocksmtpdgem本体を最新版にしといたほうがいいかもしれません。 使い方 一番簡単な使い方。 # 設定ファイル、ディレクトリを作成。 $ mocksmtpd init # コンソールモードで起動。 $ cd ./mocksmtpd $ sudo mocksmtpdinitで設定ファイ