現在開催中の“Xbox E3 2014 Media Briefing”にて、Ubisoftが「Assassin’s Creed Unity」のライブデモを実施し、搭載が噂されたキャンペーンの4人Co-opを提示。オープン環境な1789年のパリを舞台に、市民を先導しつつターゲットを暗殺するため宮殿に潜入する4人のアサシンによる協力プレイをお披露目しました。
本日開催された“Sony E3 Press Conference”にて、PS4版のリリースがアナウンスされ、その後Xbox OneとPC版の発売も報じられたRockstar Gamesの「Grand Theft Auto V」ですが、新たにRockstarが公式サイトを更新し、次世代コンソールとPC版特有の改善要素に関する具体的なディテールを明らかにしました。また、PC版には映像制作用の高度な編集エディタを搭載することが判明し注目を集めています。 遠景描画距離の向上 より精細なテクスチャディテール より濃密な交通量 高解像度対応に伴う舞台の再創造 新たな野生生物 天候表現とダメージエフェクトのアップグレード その他、多数の新要素 これらの改善は“Grand Theft Auto Online”にも適用される。さらに、広範囲な新ジョブや新たな武器類、ビークル用の楽曲、新しい物件、プレイヤーカ
Touch Arcade の記事によると、Apple は広告に関する規約を厳密に運用し始めたようだ。 以前から「アプリダウンロードを促進するために、ゲーム内アイテムの提供を行う行為の禁止」という規則があったが、これを理由にリジェクトされたアプリが出現し、話題を集めている。 厳格にこの規約が運用されるとどうなるのか考えてみよう。 ヘイデイでは、動画を見ると課金アイテムのダイヤモンドが手に入る。しかし、報酬を与えて広告を見せているのでアウト。 訂正： 記事の公開時、「規約を発表」とありましたが、「すでにある規約を厳密に運用し始めた」の誤りでした。 申し訳ありません。 調べ直した詳細についてはこちらをご確認ください→Appleのアプリ内広告などに関する規約厳格化の続報。すでにリワード付き広告のリジェクトを実施中。 また、Twitterで共有するとスタミナが回復する、などの仕組みもアウト。 これか
TL;DR JSON Schemaを使ってこういうことが実現可能になった。 ダミーAPIサーバの提供 ドキュメントの自動生成 APIクライアントの動的定義 APIサーバのバリデータの動的定義 APIサーバのレスポンスの自動テスト JSON Schemaとは JSON SchemaというのはあるJSONのデータ構造を記述するための方法および書式の仕様で、 JSON SchemaもJSONで記述される。 これを利用すれば、リソースベースの(=RESTfulライクな)APIの仕様が簡便に記述できる。 例えば、我々のAPIはレシピとユーザというリソースを扱っていて、 それぞれCRUDのAPIを備えており、レシピはidとtitleとdescriptionという属性を持つ、 という旨をJSON Schemaで表現できる。 なんで最近ちょっと流行ってんの Mobile First、 Service Or
リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の３つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から： なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build Cloud Speed up your image buildsTestcontainers DesktopLocal testing with real dependenciesTestcontainers CloudTest without limits in the cloud See our product roadmapMORE resources for developers
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build Cloud Speed up your image buildsTestcontainers DesktopLocal testing with real dependenciesTestcontainers CloudTest without limits in the cloud MORE resources for developers
Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build Cloud Speed up your image buildsTestcontainers DesktopLocal testing with real dependenciesTestcontainers CloudTest without limits in the cloud See our product roadmapMORE resources for developers
2014-06-09 phaという大罪 Web 乙武がある日「これまで五体不満足な障害者として生きてきましたがこれからは引っ込めていた手足を伸ばして健常者として活動していきます。みんなよろしくね」とか言い出したら顰蹙を買うどころの話ではないと思うが、実際にそういうことを言い出す者がいるのだから驚きだ。 DMM.make - 熊野MAKE日記 - 家をつくる・１ はじめまして、phaです。僕は一時期は京大卒ニートとして「インターネット最高！ネットがあれば生きていける！」とか言ってネットでいろいろ活動したり （遊んでいただけだけど）、ネット好きのギークが集まってシェアハウスに住む「ギークハウスプロジェクト」というのを立ち上げたりしていたんだけど、35 歳になったのをきっかけにニートの肩書も外し（ニートの年齢制限は35歳）、今はたまに文章を書いたりする仕事もするようになり、最近は田舎でお金を使わ
［速報］Docker Hub発表。ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。Dockerのプラットフォーム化を推進 Dockerの開発元であるDocker社は、Docker 1.0の発表とともに、Dockerを基盤としたアプリケーションの開発、配布、実行のための一連の機能を備えたサービス「Docker Hub」を発表しました。 関連：［速報］コンテナ型仮想化のDocker 1.0がリリース。Dockerはコンテナエンジンからプラットフォームになると宣言 Docker Hubは、GitHubやBitbucketなどのソースコード管理ツールと連係して自動的にコードをビルドする機能や、AmazonクラウドのAWS Elastic BeansTalkやGoogle Compute Engine、Rackspace、Red HatのOSなどと連係してアプリケーションをデプロイ
［速報］コンテナ型仮想化のDocker 1.0がリリース。Dockerはコンテナエンジンからプラットフォームになると宣言 Linux上のコンテナ型仮想化の実装として話題を集めていたDockerが、正式版となる「Docker 1.0」のリリースを発表しました。6月9日（日本時間で今日6月10日）から2日間サンフランシスコで開催中のイベント「dockercon14」において発表されました。 OS上に複数のユーザー空間を作り出すコンテナ型仮想化は、物理サーバ上に仮想サーバを作り出すハイパーバイザ型の仮想化よりも軽量で起動も高速だという利点を備えています。 DockerはLinuxにおけるコンテナ型仮想化の実装として人気を集めており、Red HatがDockerのための軽量OS「Red Hat Enterprise Linux Atomic Host」の開発を表明。AmazonクラウドもAWS E
シニアエンジニアによるガラケー大戦回顧録に参加した
シニアエンジニアによるガラケー大戦回顧録 : ATNDに参加した。 この会合の主旨としては、当時の邪悪で不自由極まりないガラケーの開発姿勢が、如何に悲惨で惨めで肥溜めの中の蛭のようなものだったかを、非公開の会合で語ろうというものだ ガラケーの開発では、技術的に誤っている手法が実に多く使われていた。なるほど、不自由で貧弱なガラケーの実装が規格準拠しておらずバグだらけだったこともあろう。それにしても、ガラケーとは関係がないサーバーの中だけで完結する場所におけるクソもあった。何故そんなことになってしまったのか。 理由は、情報が公に出せず、したがって共有されなかったことだ。情報が共有されないため、表立って議論や相談が出来ない。その状態でかろうじて見つけたちっぽけな情報を元に、技術的に極めて劣っていながらも、何とか動くものを作り出していた。そして、その動くものを、正しいやり方だと勘違いしていたのだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
