先週 2016/5/24-25 の2日間、日本マイクロソフト公式技術イベント「de:code 2016」（デコード2016）が開催されました！ 今回の de:code は、例年よりずっと参加者の数が多く、 また、Microsoft 最高経営責任者(CEO) サティア・ナデラが来たこともあり、すごーく盛り上がりました！ Linux&Macを使ったデモ、そしてOSS系のセッションが多かったのも特徴ですね。 私も登壇し、アプリ開発ツール Xamarin(ザマリン)についてのセッションを持ちました。初めての有償イベントでの発表で、とても緊張しました＞＜ その時の経験などをここに書いておこうと思います！ (「de:code って何？」という方：以前、紹介漫画を描いたのでぜひご覧ください。「C#ちゃんが３分解説☆今年のde:codeは行くしかない！」) あ、さっきトイレで挨拶した人だ。すごい方だったん

注意 本件記事ですが、私の不適切な行動（拾ったスクリプトを検証なく走らせる）が原因です。「dockerは（特に何もしなくとも）危険」との誤解を皆様に与えた点、ご迷惑をおかけいたしました。申し訳ございません。 拡散されている記事を削除するのはさらなる誤解を招きかねないと思いましたので、冒頭に注意を付記しております。以下の記事は、「自分が何してるかをきちんと検証できないとセキュリティホールを生み出す」という意味で参考にして頂ければ幸いです。 追記 Twitterやはてブで言及いただきました皆様、ありがとうございます。 本件はpullしてきたイメージが悪意ある開発者によるものかどうかにかぎらず、不適切な設定をしていると起こり得ます。 ※コメント欄に質問への回答という形で、私がそのときに走らせていたイメージの一覧を挙げておりますが、どのイメージも評判あるものだと思います。 皆様におかれましては「あ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

AWSのリソース構成をServerspecのようにテストできる "awspec" をつくりました。 github.com 例えばEC2インスタンスであれば、以下のように書けます。 describe ec2('my-ec2') do it { should exist } it { should be_running } it { should_not be_stopped } its(:instance_id) { should eq 'i-ec12345a' } its(:private_ip_address) { should eq '10.0.1.1' } it { should have_security_group('my-security-group-name') } it { should belong_to_vpc('my-vpc') } it { should belon

はじめに みなさん、DRY原則はご存知でしょうか？ DRY = Don't repeat yourselfの略で「繰り返しを避けること」という意味ですよね。 良いコードを書くための重要かつ基本的な原則なので、みなさんよくご存知だと思います。 ですが、DRY原則はテストコードを書く場合は必ずしも最善にはならない場合があります。 他の人が書いたテストコードを見ていると、テストコードにDRY原則を適用したために、かえって悪いコードになっているケースをときどき見かけます。 この記事ではなぜテストコードをDRYにすると良くないのか、ということを説明します。 追記：タイトルを変更しました @t_wada さんのコメントを受けて、タイトルを見直しました。 「テストコードはDRYを捨ててベタ書きする」 => 「テストコードの期待値はDRYを捨ててベタ書きする」 【注意】この記事は画一的なテストコードの書き

上海で働くさすらいのゲームデザイナー/ディレクター。日本語、中国語、英語、名古屋弁のマルチリンガルということになっている。 ファミコンの初代スーパーマリオブラザーズには優れたUXを作りあげるためのヒントがたくさんあります。 今回の記事では、スーパーマリオの１－１に散りばめられた「ユーザーに新しいことを自然に覚えてもらう工夫」を紹介します。 新規コンテンツの「色々覚えるのめんどくさい問題」 新しいコンテンツでは、ユーザーにいかに使い方や遊び方を理解してもらうかが非常に大きな課題です。 クリエイターは「新しくて誰も見たことがないものを作りたい！」と思うものですが、ユーザーにとってみればコンテンツを初めて利用するときの面倒くささがその斬新さに比例して大きくなっていきます。最初の「覚える」段階のUXが悪ければ、その先にどれだけステキな体験が待っていたとしても、そこに到達する前に多くのユーザーは離脱

今は世界でも評判の高い日本車ですが、日本車が世界で売れ始めたのは 1970年代の“オイルショック”がきっかけです。 オイルショック前には日本車なんて、おもちゃみたいなモンだと思われてた。 ところが石油がいきなり高騰したため、車無しでは生活できないアメリカ人の多くが、燃費の悪いアメ車を “緊急避難的に” 手放し、日本車に買い換えたんです。 そして「石油が高いから仕方なく買い換えた日本車」が、「実は品質もアメリカ製より優れてるじゃん！」と気がついた。 オイルショックがなければ、日本車が世界で売れ始めるタイミングはもっとずっと遅かったでしょう。 とはいえ、「オイルショックがあったから日本車が今の地位を築いた」のではありません。 オイルショックは“突然訪れたチャンス”ではあったけど、それによって消費者に「たとえ石油が安くなっても、日本車のほうがいいかも！」と思わせたのは、日本車の実力です。 もし「