類似のソフトウェアとして、Puppet や Ansible といったものもあります。こういったインフラ自動化まわりのソフトウェアについてはペパボの宮下さんの インフラ系技術の流れ が参考になります。 Chef in グリー さて、グリーでのChefまわりの構成をご紹介します。下図が全体の構成です。 開発環境 開発は各個人のマシン上で仮想マシンを立ち上げて行なっています。クックブックの開発では、クックブックを開発する人が serverspec でテストを書くようにしていて、構築後のサーバが期待通り動くことをテストしています。一つのクックブックでも設定値などの条件によって動作が変わってくるため、test-kitchen を用いて複数の条件（ランリストやノードのアトリビュート（以下、「アトリビュート」）などの組み合わせ）でテストを行っています。 また、一部仮想マシンを使う必要がないテスト（att
実際に関係者から聞いた話なのだが、いま、底辺のソーシャルゲーム会社は大変なことになっているらしい。底辺じゃない会社もそれなりに大変なものかも知れないが、底辺の会社はそれどころの騒ぎではないようだ。 まず、プログラマーの力量に合っていない。 「ソーシャルゲーム(の開発を)舐めんな」みたいな話は大手の開発会社のプログラマーからよく聞くが、人数がある日突然何万ユーザーも増える。このへんの流入する人数の調整が利かない。 もともと何十万人規模の接続をさばくには、MMORPGなどのオンラインゲームよりもシビアであり(普通、MMORPGでもワールドがわかれていて、1つのサーバーの常時接続人数は数千人規模に収まるので)、大人数になったときにうまくスケールアウトするように設計するためには、ゲームシステム自体がそのへんを考慮してうまく練られていないといけない。 ところが、底辺ゲーム会社だと、社長がそのへんの理
LWF LWFは、独自ファイルフォーマットに基づくアニメーションエンジンであり、Flashコンテンツから変換したアニメーションデータを、UnityとHTML5で再生できます。 ※ GREE Platformではサポート対象外となりますので、詳細は「github」のWebサイトをご参照ください。 概要 主な特徴 Flash プレーヤーに近い挙動により、Flash 開発経験者の学習負担を大幅に軽減。 Flash アーティストがエンジニアリングなしに、アニメーションおよびユーザーインターフェースを作成可能。 既存の Flash プレーヤーでは不可能だった、自由で高度なインタラクションが提供可能。 ユーザーインターフェース用とアニメーションエフェクト用といった、複数の「LWF」データを同時に再生・制御可能。 詳細については、次のWebサイトをご参照ください。 GitHub：GREE／LWF 「LW
継続的インテグレーションを始めるための基礎知識：グリーはいかにしてJenkinsを導入したのか（1）（1/2 ページ） 本連載では、グリーのサービス開発において導入している継続的インテグレーション（Continuous Integration、以下、CI）と、CIツールであるJenkinsの導入について3回に分けて説明します。Jenkinsのインストールといった“手順”よりも、CI導入の“モチベーション”や“進め方のポイント”を中心に説明します。 グリーの開発と継続的インテグレーション SNSやソーシャルゲームなどを運営するグリーでは、数百名の技術者が日々さまざまな機能やサービスを開発し、リリースしています。このような規模、リリース頻度での開発を支えるには数多くの工夫や仕組みが必要です。この中でも最も大きな仕組みの1つにCIが挙げられます。 グリーでは、開発にCIを本格的に導入し始めたのは
こんにちは。クライアント基盤チームのよやです。 減色処理の話の続きで、ImageMagick の改造についてお話します。 前回 > ImageMagick 改造入門 (その弐) 減色処理前編 ImageMagick 減色処理の３つのフェーズのうち２つ目にあたる「RGB 空間で分割された立方体の統合処理」で特に時間がかかっていたので、少し手を加えて高速化しました。 前回のこの図に相当する処理です。 ImageMagick の既存の処理 前回、説明した「RGB 空間で分割された立方体の統合処理」のより細かい解説です。 統合処理の詳細 既存の ImageMagick の減色処理では、quantize_error の小さい順にRGB色空間内の立方体を削除して、それらのひとつ親の立方体に統合する処理を繰り返します。 対応コード (magick/quantize.c) 望みの色数になるまで繰り返す (
2013年7月。現状について ウチではもう大作ソシャゲは引き受けていません。オリジナルも新規開発の予定はありません。大半の業務を以前のような普通のウェブ案件に戻しました。ソーシャルゲームしか開発したことのない従業員への再教育に忙しい。以前に作ったオリジナルは黒字である限り運営を続けます。イベントやカード追加も行います。新機能などを入れることはないでしょう。会社としてはあまり力を入れていません。もうソーシャルゲームは短納期案件しか受けなくなったので業界の関係者ともあまり関わらなくなりました。既に俺の知っている情報は古いかもしれませんし、今後更新されません。ソーシャルゲームはオンゲだから人口が命だと以前に何度も繰り返しました。しかし、その人口で我々は結局大手には勝てなくなりました。とくに大手の抱える有力IPには全く太刀打ち出来ません。今オリジナルでブラウザのカードゲームソーシャルゲームを開発す
「感性に頼りすぎないゲーム設計というのを心がけている」「企画・開発はもちろんのこと、分析や事業戦略まで手を出しつつやっていく」など、これまでのゲーム作りの方法論を覆すという制作体制をとっているGREE、彼らはどのようにして数々のトップセールスを誇るプロダクトを作り上げているのでしょうか？ 日本最大のゲーム開発者向けカンファレンス「CEDEC2011」にて、これまでのゲーム機業界での手法との対比を交えながらGREEが「セールスランキングNo.1プロダクトの作り方」というタイトルで、ソーシャルゲームの未来への展望について講演を行いました。 講師は過去にフロントミッションシリーズ、FFシリーズなどを手がけ、今年スクウェア・エニックスを退社してGREEに入社した土田俊郎氏、そしてソーシャルゲーム初期の名作「釣り★スタ」のプロダクトマネージャーを努めた岸田崇志氏の両名です。こちらの濃密な講演の全内容
こんにちは。インフラの sotarok です。 先日から Git 関連の話をしている通りですが、社内で Git を使い始めています。 今日は、Git を使った日々の開発〜リリースまでのフローや、そうしたものの運用と、それをサポートするために作ったツール git-daily の紹介をしたいと思います。 ソフトウェア開発とウェブ開発の違い いやウェブ開発も広義のソフトウェア開発なのですが、ここでいうソフトウェア開発とは、クライアントアプリケーションやライブラリのようなものを指すと思ってください。 実際、ウェブ開発をしている方は感じていることだとは思いますが、両者の開発フローはかなり異なるものです。もちろん社風や開発の方針等によって色々あるとは思いますが、主に次のような特徴が挙げられると思います： ソフトウェア開発 アプリケーションはクライアントで動作する リリース間隔は比較的長く、次のバージョ
こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
