タグ

ブックマーク / labs.gree.jp (12)

  • OAuth for Native Apps | GREE Engineering

    GREE Advent Calendar 9日目は @nov が担当します。 僕は GREE ではセキュリティ部に所属しており、社外では OAuth や OpenID Connect などの Identity 関連技術についての翻訳や講演などを行ったりもしています。 今日は GREE Advent Calendar ということで、Native App コンテキストでの OAuth の話を少し書いてみようと思います。 はじめに Native App を開発していると、Backend Server とのやりとりや Facebook Login や Google Sign-in などで、必ずと言っていいほど OAuth 2.0 というのが出てきます。 OAuth 1.0 と異なりリクエストに署名が不要だったり、Client Secret (a.k.a Consumer Secret) 無しでも

    OAuth for Native Apps | GREE Engineering
  • YAPC::Asia Tokyo 2015にいってきました | GREE Engineering

    ひさびさの投稿がイベントいってきましたエントリになりました、ふじもと (@masaki_fujimoto) です。 ということで、sponsoredしたらチケットをいただいたのもあって (いやそんな、してなくても多分いってたと思いますが)、21-22日に参加させていただきました。blogを書くまでがYAPCって1日で10回くらい聞いたので、もはやただの個人の感想文ですが、会社のblogのっとってつらつら感想かきます! よくわかるYAPCのまとめ 全体的なまとめがあちこちにあるので、もうすでに目を通されてるかたも多いかなーと思いますが、いちおリンクしてみます: YAPC::Asia Tokyo 2015 感想エントリまとめ YAPC::Asia Tokyo 2015 スペシャルレポート YAPC::Asia Tokyo 2015 #yapcasia 全セッション総まとめ さいしょにアピール:

    YAPC::Asia Tokyo 2015にいってきました | GREE Engineering
  • 適当勝手な技術トレンド予測 (2014年末版) | GREE Engineering

    tl;dr 去年も言われたので先に書いておきます。今年は(も)そんなに有用なエントリでもなく、脊髄反射で「1年後こんな感じかなー」という予測を、思いつきなテーマでつらつら書いてるだけです。 きっと1年後には、「あー外してるわー」とかとか自分で振り返れるので楽しそうですよねー、というのが主な目的なので、あんまりまじめに受け取らないでくださいなにとぞよろしくおねがいします。 はじめに (駄文且つ長め) ということで Merry Christmas! GREE Advent Calendar 25日目は、グリー株式会社でCTOをしておりますふじもとがお送りします。今年も育児休暇からオンラインゲーム開発、OpenStackまで、多種多様な24のエントリーがある中で、最後のエントリーをどんな内容にしたものか、と悩んでいたらはや12月も23日になってしまいまして、こんな素敵な冬晴れの日 (2014/1

    適当勝手な技術トレンド予測 (2014年末版) | GREE Engineering
  • HTTP2を試してみる | GREE Engineering

    初めまして、インフラストラクチャ部の後藤です。普段はChefを用いたサーバの自動構築環境の開発に従事しております。 今回は、近頃若者の間でも話題になっているHTTP2についてお話したいと思います。 2012年の末頃、HTTP1.1のセマンティクスを維持したままパフォーマンスを改善するという目的でHTTP2の仕様策定が開始されました。そんなHTTP2もワーキンググループ・ラストコールに向けて大詰めを迎えています。 現在最新版はdraft12となっており、すでに幾つかの実装が存在しています。HTTP2のwikiで確認できます。例えば、Google ChromeのCanaryビルドやFirefox Nightlyビルド では既にHTTP2が使用可能です。 またサービスとしては、twitter.com が対応しています。 HTTP2の特徴 HTTP2はGoogleの考案したSPDYと言うプロトコ

    HTTP2を試してみる | GREE Engineering
  • hhvmのExtension書いてみた | GREE Engineering

    みなさんこんにちは。hackしてますか? 今日はhhvmのC++拡張(Extension)について書いてみます。 前振り hhvmはfacebookが開発・公開しているPHPの処理系のうちの一つでC++で書かれており、linux上でのJITがサポートされており場合によってはとても高速にPHPアプリケーションを実行する事ができます。 勿論Native拡張を書くこともでき、既存のライブラリ資産の有効活用やどうしても速度が出ない部分の改善などが簡単に行えるので手段として知っていると便利です。 この記事をきっかけにhhvm Extensionのとっかかりになれば嬉しいです。 開発環境を作る 開発環境はlinuxの環境を整えましょう。 OSXやその他の環境でのビルドも対応しているのですがJIT未対応だったり予期せぬバグや地雷を踏む可能性が高いので積極的にOSXのバグフィックスを行ってフィードバックし

    hhvmのExtension書いてみた | GREE Engineering
    escape_artist
    escape_artist 2014/04/02
    書きやすそう
  • CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering

    Merry Christmas! GREE Advent Calendar もいよいよ最終日、25日目はグリー株式会社でCTOをしておりますふじもとがお送りします。 今日まで24人のGREE Engineersなみなさまにエントリを書いていただいたわけですが、思ったよりも多種多様な内容で、あらためていろいろな方面で素敵なエンジニアがいるなー、としみじみしてしまいました。いやしかしgitとchefの記事人気ですね、そして、「当然CTOはすごい記事書くんですよね」とプレッシャーをかけて楽しむ仲間たちに囲まれてぼくは幸せです、あーすごい幸せー。そんなプレッシャーの中、今までのエントリとはちょっと方向性を変えて、CTOの話でも書いてみようかと思います。なお、ぼくの趣味は多分問題解決です。 そんなわたくしふじもとは来年で、CTOっていう肩書きでお仕事をはじめて10年とかになるんですが、なかなか先輩と

    CTOとはなんなのか、あるいはエンジニアの生存戦略 | GREE Engineering
    escape_artist
    escape_artist 2013/12/25
    とても良い内容でした。
  • クライアントサイドJavaScriptのライセンス管理 | GREE Engineering

    最近シリコンウエハーもらって嬉しかったago(@kyo_ago)です。 このエントリはGREE Advent Calendar 2013 11日目の記事です。 今回はクライアントサイドJavaScriptにおけるライセンス管理の問題を取り上げたいと思います。 ライセンス管理の問題点 「使用しているライブラリのライセンス管理をどうするか」はクライアントサイドJavaScriptにかぎらず発生する問題ですが、クライアントサイドJavaScriptには以下の様な特徴があるため問題が複雑になります。 コードが結合、圧縮される場合がある クライアントサイドJavaScriptでは読み込みの速度を上げるため、使用しているライブラリの結合、圧縮を行うことがあります。しかし、この時誤ってライセンス文が捨てられてしまうことがあります。 ソースが外部に公開される クライアントサイドJavaScriptではソー

    クライアントサイドJavaScriptのライセンス管理 | GREE Engineering
  • SNSチームでのドメイン駆動設計の実践 | GREE Engineering

    こんにちは!グリープラットフォームでSNSの開発をしています、うきょーです! GREE Advent Calendar 2013 6日目です、よろしくお願いします! 今回は僕が所属するチームでの、ドメイン駆動設計を実践してきた過程をお話したいと思います。ドメイン駆動設計とは何か、については簡単に要所要所で説明していきますが、詳しくはで!また、ドメイン駆動設計そのものについての話ではなく、実践の一例となります。 スマートUIパターンからのスタート 今回僕のチームが扱っていたものはJavaScript製のクライアントアプリケーションで、APIから取得した情報を表示し、ユーザーの操作によってAPIを呼び出す、というごく一般的なものです。 ドメイン駆動設計にはアンチパターンとして、スマートUIパターンと呼ばれるものが存在します。簡単に言えば「見た目都合から設計やモデルを考えてしまった」という状況

    SNSチームでのドメイン駆動設計の実践 | GREE Engineering
  • GIF アニメ生成は本当に GraphicsMagick で行うべきか? | GREE Engineering

    具体的には以下のように使い分けると良いでしょう。 手早く GIF アニメを作りたい > GraphicsMagick Web のバックエンドで動かしたい > YoyaMagick YoyaMagick が使える環境ではない > ImageMagick 自分が今まで耳にした誤解を元に、ポイントを列挙します。 まず、ImageMagick の GIF アニメ生成に時間がかかる場合、その処理の大半は減色処理です。 ImageMagick の減色は主に減色専用のデータ構造を用いる為、Q8, Q16 (*2)による性能の違いは殆どありません。 実は、GIF アニメ最適化の差分フレーム抽出は、減色やGIF エンコードの時間に比べて殆ど時間が掛かりません。 差分フレームが小さい程、2枚目以降の GIF 画像が小さくなり、むしろ全体として処理時間が短くなります。 ImageMagick に比べて、Grap

    GIF アニメ生成は本当に GraphicsMagick で行うべきか? | GREE Engineering
  • Windows 版 PHP build ~ オレオレPHP | GREE Engineering

    クライアント基盤チームのよやです。こんにちは。 需要の少ない話で恐縮ですが、今回は WindowsPHP を自分で build する方法を紹介します。 昔、VC6 を使っていた頃に比べ VC9,10 + SDK で build 出来る今は作業が大変簡単になっています。 Unix 系OS で PHP 自体を改造したり、PHP extention を作って組み込む事に慣れていても、Windows では足踏みする事があると思いますが、この記事がその敷居を下げる一助になれば幸いです。 公式の build 手順は以下の場所に説明があります。 Build your own PHP on Windows + https://wiki.php.net/internals/windows/stepbystepbuild 公式 Wiki の build 環境に合わせ、Visual Studio 2008

  • PNG軽量化の減色と圧縮について | GREE Engineering

    このテーブルの番号は 1 Byte になっているため、0-255 の 256 個しか登録できません。そのため、画像で使用されている色が 256 個より多い場合は、なんとかして 256 個にしなくてはいけません。 この「なんとかして 256 色にする」というのが減色処理で、なるべく元の画像からの変化を分からないようにしながら色を減らしていくためのアルゴリズム実装です。(この記事では減色アルゴリズムについての説明は省略します。) テーブルを作成したら、画像のそれぞれのピクセルを RGB 形式からテーブルの何番目の色を使うかに置き換えます。 上図のように、1 ピクセルあたり 24bit 必要だった画像が 1 ピクセルあたり 8bit になったので、データサイズは大体 1/3 になります。 (パレットのデータに最大 3 Byte * 256 = 768 Byte 必要とか、同じように圧縮されないと

    PNG軽量化の減色と圧縮について | GREE Engineering
    escape_artist
    escape_artist 2012/11/05
    詳しい
  • 大規模インフラの監視システム | GREE Engineers' Blog

    こんにちは。インフラチームの ebisawa です。 今回はグリーのインフラにおける各種機器の監視がどのように行われているのかご紹介させていただきたいと思います。一般にサーバの監視というと、システムダウンを検出するための死活監視を意味する場合と、ネットワークトラフィック等のモニタリングのことを意味する場合とがあります。今回の監視は特に後者についてのお話です。大規模なインフラの監視には、やはり特有の課題があります。 どんなツールを使っているのか グリーではサーバの各種リソース使用状況をモニタリングしてグラフ化するためのツールとして、Cacti を利用しています。Cacti は、大変有名なツールなので皆様ご存知かと思いますが、バックエンドの RRDtool で作成したグラフを閲覧するための使いやすいユーザーインターフェイスを備えています。 http://www.cacti.net/ ツールの使

    大規模インフラの監視システム | GREE Engineers' Blog
    escape_artist
    escape_artist 2010/10/10
    『誰かが何らかの作業をし続けないと維持できない仕組みのシステムは、圧倒的な数の力の前ではすぐに破綻します。』
  • 1