オンラインゲーム開発のいにしえの技術 | GREE Engineering
開発本部の堀口です。昨年は git による分散作業パターン を書き、つい先月は 札幌での講演 を行い、当文章ではゲーム開発の設計に関するネタです。 昔話交じりのポエムですが２０日目としてよろしくお願いします。 オンラインゲームとは 20 年ちかく前に Quake というゲームがリリースされ、一見すると単なる一人称視点のシューティングゲームにしか見えないが、プレイヤー自身の Quake の世界を公開し、来場者と遊ぶことができた。当時でいえば、自分のホームページに CGI 掲示板を設置するのと似ていたと思う。 Quake は、ゲーム世界のふるまいと世界の変化を伝える入出力が非常に良く分離されており、参加するプレイヤーはその世界の中に現れた自分の分身となるアバターの行動のみを制御し、アバターの目の代わりに世界の変化を、わずかな情報にしてプレイヤーに伝えた。プレイヤーの目の前にある端末では、その情
天下一InfluxDB勉強会開催してきました | GREE Engineering
こんにちは。ちょびえです。先日6/27(金)にDeNAさん会場にて天下一InfluxDB勉強会を開催してきました。当日はあいにくの悪天候ながら参加いただき有難うございました。また、会場を快く提供していただきましたDeNAさんに感謝申し上げます。 天下一InfluxDB勉強会 イベントページ きっかけはanatooのtweetにより始まりました 天下一influxdb勉強会の開催が待たれる — anatoo (@anatoo) May 29, 2014 もともとanatooとはPHPつながりで闇PHP勉強会など企画して頂いて参加させていただいていたのですが、今回は二人共InfluxDBに興味があるよね！ってことでInfluxDBの勉強会を企画・開催してきました。 本記事では天下一InfluxDB勉強会のレポートまとめ、という事で資料＋動画を簡単にまとめておこうかと思います。@sonotsさん
なめらかに動作するUITableViewのつくりかた
矢口裕也です。 Advent Calendar 10日目はiOSのUITableViewの話をします。 ぼやき iOSアプリを開発していると70%くらいの時間はUITableViewに費やしている気がしてきます。 UITableViewは非常にめんどうなものですが、パフォーマンスがシビアでかつユーザーの快適さに直結するものなので大いに手間をかける価値があります。 この記事ではガクガク処理落ちするUITableViewを例として改善していきながら快適なUITableViewのつくりかたを解説します。 目的 以下のケーススタディでは次の目的でコードを改善していきます なめらかに動くようにする ここでのポイントは実際速くなくてもユーザが快適に感じればOKである、ということです。処理速度が高速である必要はありません。 戦略 UITableViewでのパフォーマンス問題は次の2点であることが多いです
グリーのインフラに Chef を導入した話 | GREE Engineering
類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
git による分散作業パターン | GREE Engineering
分散バージョン管理を華麗に扱いたい堀口です。 GREE Advent calendar 2013 の 14 日目として参加させていただきます。 お二人に続き Haskell の話をしようかと思ったのですが、急遽無難な開発の話に変更しました :o Java や C++ には OOP の概念が必要であったように、分散作業の認識が薄いまま git や Mercurial を使うことは長期的に不幸をもたらします。 とあるプロジェクトにて、その一部を副産物のミドルウェアとして抽出すべく、アプリケーションと分離したい 不具合があったので原因を探りたいが、依存関係が複雑すぎるのでコードを読む量を減らしたい テストやレビュー、提案、リファクタの運用を強化したい よそのプロジェクトに迷惑を掛けないように、そこのツールを改良して使いたい。 いままで何気なく「こんなもんだろう」と思って手間をかけていませんでした
社内Haskellチュートリアルのススメ | GREE Engineering
こんにちは。インフラストラクチャ本部の竹辺(@beketa)です。 このエントリはGREE Advent Calendar 2013 12日目の記事です。 1. グリーでのHaskellプログラマ採用 Haskellを導入する企業が増えているようです。最近国内のメディアで紹介された事例だけでも Tsuru Capital様: http://itpro.nikkeibp.co.jp/article/Watcher/20131003/508622/ NTTデータ様: http://itpro.nikkeibp.co.jp/article/NEWS/20131126/520642/ の複数があり、すっかり実用的なプログラミングとして定着した感があります。 弊社でも2012年の中ごろから複数のプロジェクトでHaskellを使い始めており、昨年からは一部の商用サービスでもHaskellで開発したミド
Varnishでテストコードを書こう！ | GREE Engineering
はじめまして、サーバ基盤チームの田中祥平(@xcir)です。 最近入社しまして、チームではいわなちゃんと呼ばれています。よろしくお願いします。 入社してからGREEの配信システムをVarnish Cache（以下Varnish）に置き換える仕事をしていたのですが、少し前に問題なく山を超えました。 そこで今回利用したVarnishの特にテスト機能について紹介しようと思います。 なお、今回の説明に利用するVersionは3.0.3です。 Varnishとは VCLというドメイン固有言語をもち、キャッシュもできる高速リバースプロキシです。 if文が書けるので柔軟に記述しやすいという特徴があります。 たとえば/admin/以下に許可したIP以外からのアクセスは弾くと言ったことは以下のように記述できます。
ImageMagick 改造入門 (その参) 減色処理後編 | GREE Engineering
こんにちは。クライアント基盤チームのよやです。 減色処理の話の続きで、ImageMagick の改造についてお話します。 前回 > ImageMagick 改造入門 (その弐) 減色処理前編 ImageMagick 減色処理の３つのフェーズのうち２つ目にあたる「RGB 空間で分割された立方体の統合処理」で特に時間がかかっていたので、少し手を加えて高速化しました。 前回のこの図に相当する処理です。 ImageMagick の既存の処理 前回、説明した「RGB 空間で分割された立方体の統合処理」のより細かい解説です。 統合処理の詳細 既存の ImageMagick の減色処理では、quantize_error の小さい順にRGB色空間内の立方体を削除して、それらのひとつ親の立方体に統合する処理を繰り返します。 対応コード (magick/quantize.c) 望みの色数になるまで繰り返す (
ImageMagick 改造入門 (その弐) 減色処理前編 | GREE Engineering
こんにちは。クライアント基盤チームのよやです。 アバター等を表示する為に PNG や JPEG の画像を元に GIF アニメーションを生成する事がよくありますが、GIF は 256色までしか扱えない為、元画像が数万といった単位で色を使っていると減色処理に大変時間がかかります。そこで、ImageMagick の減色処理を改造して高速化した事例をご紹介します。 尚、一度に読む分量ではまとめ切れない為、前編と後編に分けました。前編は減色処理、後編はその改造について説明します。 プログラム構成では上の図の magick/quantize.c が減色処理に相当します。 まず、減色処理の一般的な話から始めます。 減色の利点 Web で見かける画像ファイルの多くは、1つのpixel(描画の最小単位)に対して、Red, Green, Blue が各々8bits で計 24bits(= 3bytes) 、透
SWFバイナリ編集のススメ番外編 (zlib 伸張) 前編 | GREE Engineering
こんにちは。アプリケーション基盤チームのよやと申します。 バイナリの目利きや書き換えを主な業務フィールドとし、1% でも多くのユーザの皆様にサービスをお届けする為、より良質のバイナリを探し求める毎日です。 SWF の番外編として zlib 伸張について２回のブログに分けて解説します。(圧縮処理は対象外です) 前編の今回は概要についてお話し、具体的な実装は後編で扱う予定です。 はじめに SWF フォーマットは zlib 圧縮を多用します。例えば、GIF/PNG 画像は独自画像形式(DefineBitsLossless の BitmapPixelData)に変換後 zlib 圧縮して格納します。 http://labs.gree.jp/blog/2010/12/1902/ SWFバイナリ編集のススメ第五回 (PNG) SWF バイナリの中の zlib 圧縮されたデータが怪しい場合に、zlib
Unity用BitmapFontRendererを公開します! | GREE Engineering
こんにちわ。エンジニアの坂本 一樹(@splhack)です。 4月12日/13日、ユニティ・テクノロジーズ・ジャパン合同会社様によりUnityアプリ開発者を対象としたイベント、「Unity アジア・ブートキャンプ・ツアー：東京」が開催されました。弊社も協賛させていただきました。 Unity、「Unity アジア・ブートキャンプ・ツアー：東京」を開催。「三国志コンクエスト」や「GREE」の事例から学ぶ開発のコツ この記事では、事例紹介のみ取り上げていただいたのですが、それ以外にも、GREEでのUnityアプリケーション開発環境、Unity in Depthといった内容をしゃべらせていただきました。 この内容についても、いずれこのBlogにて公開していきたいと考えていますが、 まずはセッションでの予告通り、Unity用BitmapFontRendererを公開いたします! https://gi
多人数開発で Git を使う場合の環境構築 | GREE Engineering
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
グリーの大規模分散ストレージ戦略(nanofs) Vol.2 | GREE Engineering
はじめに グリー株式会社でエンジニアをしておりますkgwsと申します。 今回は、前回に引き続き分散ストレージ(nanofs)のHTTPメソッド毎の処理を紹介させていただければと思います。 nanofsは5つのHTTPメソッド(GET、PUT、DELETE、HEAD、MKCOL)をサポートしております。今回は主なGET、PUT、DELETEの3つについてご説明させていただきます。 まずは構成のおさらい nanofsは、主に3つのプロセスで構成されております。 nanofsd(dispatcher) アプリケーションサーバからリクエストを受け取り実際に保存されているnanofsnに振り分ける 5つのHTTPメソッドをサポートしている(GET、PUT、DELETE、HEAD、MKCOL) データベース（KVS）に保存したデータの情報を送る queueに処理の指示を送る nanofsw(worke
大規模インフラの監視システム | GREE Engineers' Blog
こんにちは。インフラチームの ebisawa です。 今回はグリーのインフラにおける各種機器の監視がどのように行われているのかご紹介させていただきたいと思います。一般にサーバの監視というと、システムダウンを検出するための死活監視を意味する場合と、ネットワークトラフィック等のモニタリングのことを意味する場合とがあります。今回の監視は特に後者についてのお話です。大規模なインフラの監視には、やはり特有の課題があります。 どんなツールを使っているのか グリーではサーバの各種リソース使用状況をモニタリングしてグラフ化するためのツールとして、Cacti を利用しています。Cacti は、大変有名なツールなので皆様ご存知かと思いますが、バックエンドの RRDtool で作成したグラフを閲覧するための使いやすいユーザーインターフェイスを備えています。 http://www.cacti.net/ ツールの使
グリーの開発環境（歴史と概要） | GREE Engineering
こんにちは。グリーでインフラ的なお仕事をしているsotarokです。今回は、グリーの開発環境についてお話します。 グリーの開発環境 開発環境どうするか、という問題はエンジニアリングをしている会社であれば誰しも一度は悩んだことのある問題だと思います。開発環境の作り方は、会社やサービスの規模、事業の形態などによって様々ですし、割と小さな規模から「歴史的な経緯」を経て成長してくることが多く、これといったスタンダードがあるわけでもありません。 グリーでも初期の頃から、いくつかの経緯を経て現在の開発環境があります。これは、特に画期的な開発環境やスタンダードに合わせてつくったわけではなく、日々の業務のなかで、あれこれ困ったことやより便利にしたいことなどを解決していくうちに作り上げられたものです。 今回は、グリーの開発環境の移り変わりと、今後の開発環境づくりについてお話させていただきます。 初期の頃の開
グリーの大規模分散ストレージ戦略(nanofs) | GREE Engineering
はじめに はじめまして、グリー株式会社でエンジニアをしておりますkgwsと申します。今回は、グリー内で写真データの保存を行っている分散ストレージ(nanofs)を紹介させていただければと思います。 背景 弊社で運営させていただいている "GREE" ではユーザの写真や動画データを保存することができます。1億ユーザを目指すグリーは、ユーザの増加とともに写真や動画データは上限なしに増加していきます。またユーザの皆様の大切なデータを失うことは許されませんし、サービスを止めることも許されません。そんな状況の中、様々な技術や仕組みを使いサービスを運営してまいりました。 グリーのストレージの歴史は大きく分けて3世代がありました。 第一世代 第一世代ではアプリケーションサーバからNFSサーバをマウントし画像データを保存しておりました。簡単に導入できることと高価なサーバを使用すれば信頼性や安定性も保たれる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GREE Engineering
GREE Engineering
GREE Engineering
GREE Engineering