サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
hackerslab.aktsk.jp
こんにちは、ゆのん(id:yunon_phys)です。この記事は Akatsuki Advent Calendar 2018 の22日目の記事です。 前日は@kackytwさんのDQNの学習速度を改善するでした。 Engineering Managerのjob descriptionを共有する流れ 近年、Engineering Manager(EM)業界が賑わってきています。特に2018年は非常に活発化した年でした。書籍としては、エンジニアリング組織論への招待とエンジニアのためのマネジメントキャリアパスという名著が生まれました。また、Engineering Manager Meetupが3回開催され、Slack workspaceでは12/22時点で268人となっています。EMのためのPodcast EM.FMも誕生し、総再生回数が10,000回を突破するなど、多くの方から注目を集めていま
この記事は Akatsuki Advent Calendar 2018 の15日目の記事です。 前回は sejimhpさんの、環境改善の必要性〜真っ白な Terminal から tmux へ移行〜 でした。 はじめに システムを運用する上で、安価で運用負荷の少ないバッチ処理を設計したいニーズは多いと思います。そもそもバッチ処理自体を極力除外したいのですが、日々の運用ツールなども含めると、どうしても実装しなければならない場面が出てきます。 本記事では 安く サーバレスで 並列性高く スケジューラでもイベントドリブンでも 実行できる、AWS上でのバッチ環境の実装の話をしたいと思います。 よくあるAWSのバッチ処理のアーキテクチャパターン AWSのバッチ処理のアーキテクチャパターンは Best Practice for Online Game Development on AWS が詳しいです。
この記事は Akatsuki Advent Calendar 2018 の 8 日目の記事です。 このブログでは初めましてになります。id:thinca です。今日は Vim の話…ではなく、お仕事用にごにょごにょしている Git の設定の話をしようかと思います。 背景 私のいるチームでは複数バージョン平行開発が行われており、それもあいまって Git リポジトリには各バージョンや staging、master など様々なブランチが存在しています。 そしてそれぞれのブランチから作業用のブランチを作るわけですが、Git では「あるブランチがどのブランチから派生したのか」ということは記録されていません*1。Git の構造を考えると記録されていないのは当然なのですが、これを記録するようにすると、様々な場面で活用できます。そこで私が普段している工夫を紹介したいと思います。 Git の alias 機
この記事は Akatsuki Advent Calendar 2018 - Adventar 1日目の記事です。 はじめに こんにちは。クライアントエンジニアのRiyaaaaaです。 皆さんは最近シェーダーを書いていますか? 私はあんまり書いていないですね。 長らく触れないと、カンが鈍りがちになりますよね。なので、定期的に簡単なものでも書いたり作ったりすることは脳の体操にも効果的です。 しかし、いざシェーダーを書こう!と思っても、ゲームエンジニアにとってはシェーダーはゲームやレンダラーと密接に結びついていて、手軽に何かを試すというのは難しかったりします。UnityやUnreal Engine4をわざわざ起動するのも億劫ですよね。 そんな時、GLSL(OpenGL Shading Language)をWeb上でコーディングできるサービスがオススメです。有名なところだとGLSL Sandbox
こんにちは、ライブエクスペリエンス事業部のポリック (id: poric_ries) です。 僕らのチームでは、Running LeanやSPRINTなどのメソッドを実際に導入し、僕らなりにカスタマイズしながら、新サービス「JOYMO(ジョイモ)」を作っています。 joymo.herokuapp.com 本ブログは、 「リーン・スタートアップはもう古い?企業内新規事業でよみがえるLeanな事業立ち上げ」 をテーマに、新規事業開発現場の”実践録”をシリーズで配信しています。 ▼配信済 #0.はじめに #1.走り出す前の準備 #2.やってはいけない!新規事業チームの最悪な1週間の過ごし方 ← 今回はここ ▼配信予定 #3.方法論をチューニングしながら走る! #4.走り慣れてきた!案外すぐにゴールできるんじゃね!と思ったら... #5.ターゲットを変えて再スタート! #6.ダーティー&セクシーな
こんにちは、ライブエクスペリエンス事業部のポリック (id: poric_ries) こと、赤堀です。エンジニアではなくビズの人間です。 さて、突然ですが、僕らのチームでは今こんなサービスを作っています。 joymo.herokuapp.com このサービスはまだベータ版の域を出ませんが、アイディアや検証の仕方について次のような反響をいただいています。 アカツキさんが検証しているお出かけプラン提案サービスいいなぁ。 ・結構調査に時間かかる、いい情報ない ・セレンディピティ感がある ・3パターン来るので幅が広い、組み合わせられる 簡易プロダクトをherokuドメインのままでFacebookの広告出すという検証方法がいけてる!https://t.co/CB9nOHgvkn— 木下 慶 (@kkino0927) 2018年2月26日 これずっと欲しいーってインサイトがあったので良いなあ。どんどん
この記事はAkatsuki Advent Calendar 2017の記事ではありません(!) こんにちは。エンジニアの天野です。 2017/11/30に弊社で開催したMeguro.rbの様子をレポートします。 Meguro.rbとは? Meguro.rb - connpass Meguro.rbはRuby地域コミュニティで、目黒駅付近の開発者があつまるRubyの地域コミニティです。 現在はLT大会を行っていて、Ruby初心者からコミッターまでの幅広い参加者が、実務に役立つネタからRubyの濃ーい話などを発表しています。 また、懇親会前に参加者全員で自己紹介をする時間を設けていて、懇親会で話すのが苦手!という方にも参加しやすいコミニティになっています。 運営は、会場を提供する会社がそのまま受け持つことになっており、今回、運営メンバーに声をかけていただき、弊社で開催する運びとなりました! ア
この記事はAkatsuki Advent Calendar 2017の4日目の記事です。 こんにちは、ゆのん(id:yunon_phys)です。この記事では、アカツキのVP of Engineering(以下、VP)として、どういったことに日々気をつけてエンジニア組織のマネージメントを行っているのかを述べます。 1. 組織をフラットに保つ 2. 全員で組織をつくる 3. ワクワクする個人目標を立てる 4. マネージメントをエンジニアリングの成れの果てにしない 5. カンファレンスに誰でも行けるようにする 6. エンジニアが主体となって採用をする 7. 量のために採用しない まとめ 1. 組織をフラットに保つ アカツキでは、1人1人の自主性を重んじていて、個人の行動を妨げるようなことを可能な限り排除します。この1つのhowが、組織をフラットに保つということです。階層構造の組織では、上司が部下
Unity Client Engineer の高木(id:Guji)です。 心機一転、4 月から Unity を使い始めた方も多いかと思います。 私も Unity の新卒研修を担当しており、新卒社員に Unity を教えています。 そんな中、私は正常に Android 向けにビルド出来たのですが、 新しく Unity をインストールした新卒達は何故かビルドが失敗してしまう事件が起こりました。 MacOS 上の Unity 5.6.0f3 で実際出ているエラーは以下の通りです。 Error building Player: CommandInvokationFailure: Unable to list target platforms. Please make sure the android sdk path is correct. See the Console for more de
17新卒エンジニアの森下です。 先日、人工知能系の国際学会に参加してきたので、そのレポートを書きます。 今回参加したのは次の学会です。 14th International Conference on Distributed Computing and Artificial Intelligence (DCAI'17) 投稿したのは自分の大学院の修論の内容なのですが、上司に聞いてみたところ快諾をいただき、参加することとなりました。 学会の様子 今回の学会はポルトガルのポルトにあるPolytechnic Institute of Portoという学校で開催されました。 さらに、4学会が同じ会場で開催されており、多くの方が参加していました。 ちなみに、ポルトは魔女の宅急便のモデルとなった街らしく、雰囲気がとても良い街でした。 セッションメモ ここからはセッションについてのメモです。 中でも業務
ライブエクスペリエンス事業部 エンジニアの高松(@shimpeiws)です。 React Conf 2017 現地レポート (1日目)に引き続き、React Conf 2017 2日目の様子をサンノゼの会場から直接お届けします!!! 1日目のセッションの録画がYouTubeにアップされていました! 1日分が1本の動画(8時間25分!)なので見るのに気合がいりますが、 昨日のレポートやスケジュールを見ながら、気になるセッションをぜひチェックしてみてください! http://conf.reactjs.org/schedule 食事 2日目の感想 Goodbye Flatland! An introduction to ReactVR and what it means for web developers (Michaela Lehr) 概要 メモ Realtime React Apps wi
ライブエクスペリエンス事業部 エンジニアの高松(@shimpeiws)です。 2017/3/13 ~ 14の期間で開催中のReact Conf 2017に参加するためにサンノゼに来ています。 React Conf 2017 つい数時間前に終わったばかりの1日目のレポートを現地からお送りします! 会場の様子 1日目の感想 Keynote (Tom Occhino, Jing Chen, Sebastian Markbage) 概要 Tom Occhino Jing Chen Sebastian Markbage A Cartoon Intro to Fiber (Lin Clark) 概要 メモ Next.js: Universal React Made Easy and Simple (Guillermo Rauch) 概要 メモ React + ES.next = ♥ (Ben Ileg
こんにちは、ゆのん(id:yunon_phys)です。先日、第二回エンジニアリングマネージャー勉強会にて、タイトルの内容についてLTをしてきました。結構多くの方に興味を持っていただいた内容で、折角なので文章にしてみました。 Management 3.0 Management 3.0によると、内発的モチベーション(同僚による感謝や、自分の能力がしっかり活かせている感)こそが生産性を上げるものだと主張しています。逆に、外発的モチベーションでは生産性が落ちると言われていて、いわゆる、ボーナスや評価などはマイナスにはたらくと言われています。 アカツキでは、誕生日メッセージやサンクスカード、1on1における対話、朝のGood&Newなど、既に内発的モチベーションを高める施策を実施していますが、もっと幸せに働ける職場に出来ないか、というのを常にメンバー自らが探し求めています。そういうわけで、Manag
アカツキ応援団、エンジニアリング・アドバイザーの能登です。 アカツキという会社は、そこに集まっている人たちがいちばんの特徴になっている、という僕の最初の印象、4年半前に感じた印象は今でも変わっていない。実際社内の何人かに会ってもらうと「予想以上にいい人たちが集まっていて、いい会社なんだなと思いました」と言ってもらうことが多い。ただ、そういう中にいる人たちの人物像って、どうにも会ってもらうまで伝わらないので、それだとウェブではうまく伝わらないということになってしまう。自分としてはそこにずっと歯がゆさを感じていたんだけど、もしかしたら長めのインタビュー記事を載せることで、そこが解消されるんじゃないか、と思って、自分でインタビューして公開してみることにしました。どれくらい意図通り人物像が伝わるかわからないですが、何事もまずはひとつやってみないとね、と思って。 アカツキエンジニアで一番最初に紹介し
この記事は Akatsuki Advent Calendar 2016 の6日目です。 はじめに こんにちは、アカツキでチーム開発マネージメントをしているゆのん(id:yunon_phys)です。 アカツキではアジャイル開発手法の一つであるスクラムを取り入れて、ソーシャルゲームの開発を小さなチームで取り組んできました。近年では、高品質かつ多くの機能を持ったゲームを短いスパンでリリースし続けることが市場として求められてきており、開発が年々大規模化してきています。このため、ユーザー価値を最大化しつつより開発がスケールするように、小規模チームから大規模チーム用に開発プロセスを拡張する必要性が出てきました。そこでこの記事では、アカツキの大規模チーム開発プロセスの取り組みを紹介します。 大規模開発における課題 開発規模が大きくなると、小さな規模で発生しなかった問題がいくつか出てきます。様々な問題のう
あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ。 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。自分が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 これはTeamGeekに載っている、Googleのチームビルディングの考え方です。アカツキでも、この謙虚・尊敬・信頼(HRT)の価値を重んじ、HRTの文化を作ることで、チームの人間関係を円滑にしています。 しかし、エンジニアチームを 幸せにする方法はこれだけでは足りません。 では、エンジニアチームを 幸せにするために必要なことは何でしょうか。 そう、カレーを食べることです。 エンジニアがチームとして働くうえで、謙虚・尊敬・信頼の価値を重んじ、カレーを食べることでチームビルディングの成功につながります。 発端 アカツキでは2週
はじめに アカツキでは開発にスクラムの要素を取り入れています。しかし、現状の開発のやり方に漠然とした不安がありました。その不安とは、例えば、もっと効率的になるんじゃないか、もっと良いやり方があるんじゃないか、このやり方はスケールしないのではないか、等といったことです。そこで第三者の目が必要だろうと、ryuzeeさんにアドバイスしていただくことになりました。 メンバーヒアリングからスクラムトレーニング実施へ まず現状をryuzeeさんに知っていただく必要がありました。そこで、アカツキの全メンバーを対象に、開発上困っていることを何でも相談出来る、アジャイル開発お悩み相談会を実施しました。また、一つのプロジェクトの振り返り(KPT: Keep Problem Try)にも参加していただき、観察していただきました。様々なプロジェクトから約20名ぐらい個別相談させていただいたり、KPTに参加していた
こんにちは、初めまして。 最近ようやく花粉症も治まってきたエンジニアのシモムラです。 2016年3月にアカツキとドリコムさんの間で社会人交換留学という取り組みを行いましたので、その内容を紹介します。 社会人交換留学について 社会人交換留学とは 、会社同士で社員を交換しあうという取り組みです。目的は会社同士の文化交流、そこから生まれる「気づき」をシェアすることにあります。 社員になると他社の開発現場を生で見る機会は殆どないので、参加者自身にとっても貴重な経験です。 ご存知の方もいると思いますが、社会人交換留学は去年ドリコムさんとピクシブさんの間で行われています。 その当時の記事については以下の通りです。これを読むと、大体の雰囲気はつかめるのではないでしょうか。 辞めずに転職?社会人交換留学 ドリコムのエンジニアが見た隣の芝生 - withnews(ウィズニュース) ピクシブさんに「社会人交換
はじめに Developpers Summit 2016で「大規模Redisサーバ縮小化の戦い」というテーマで発表してきました。 大規模Redisサーバ縮小化の戦い from Yuto Komai Redisのdumpファイルを取得して、それらをマージする方法や、Redis内で使用するdb数を増やせば、接続数も増えていく、といった話をしました。 特にAWS上でRedisを運用する場合、ElastiCacheの接続数上限は変更できないことは見落としがちなポイントなので、サーバを何十台もスケールアウトする人たちにとって役に立つノウハウが共有できたのではないでしょうか。 当日はネタスライドを山程仕込んで 会場は大爆笑だったのですが、slideshareではネタスライドは割愛しております。 今回のお話 デブサミのスライドでは、ほとんどの話が縮小についての話だったので、今回はRedisの信頼性につい
tl;dr Railsではコネクションプール数を設定していても、1スレッド辺り1コネクションしか持ちません。 発端 アカツキではRails + Unicorn + Nginx + MySQLの構成をAWSで運用しており、c3.4xlargeのインスタンス上で1台辺り64のUnicornワーカープロセスが実行される設定になっています。 ソーシャルゲームでは時にたくさんのアプリケーションサーバを並列稼働される必要がでてきます。特に年末年始の時期は平時の2-3倍のトラフィックが予想され、アプリケーションサーバを最大100台で稼働させる必要がありました。 Railsのdatabase.ymlのpool設定は5だったので、単純に考えると最大 100台 * 64プロセス * 5接続 = 32,000個の接続が常時貼られるのでは?MySQLのmax_connectionsの設定は大丈夫か?という議論があ
Delivering Happinessを会社の目的として掲げるZapposが、新しい組織構造としてホラクラシーを採用して以来、IT界隈でこの考え方が急速に注目を集めるようになりました。 ただ、日本語の情報がとても少なく、ホラクラシーについての誤解が飛び交うことが多いような気がしたので、一度周辺の話題をまとめてみようと思いました。 ホラクラシーとは ホラクラシー自体は、HolacracyOneという会社が展開している、組織の構造や文化を改善するための一連のシステムを指し示しています。 旧来のマネジメントで必ずといっていいほど発生する官僚主義や権限の集中化によるデモチベーション、無駄な会議、社内政治等の諸々の問題を解決する仕組みとして提案されています。 ホラクラシーでは、これまで当たり前であったピラミッド型の階層化された組織構造は使われません。 これまでの組織を船として例えれば、リーダー(船
背景 前回の記事で、resize2fsコマンドがどのように1秒未満での容量拡張を実現しているかを知るために、resize2fsコマンドのソースを調査しました。その結果、メタデータの一つであるGlobal Descriptor Tables(GDT)をカーネル内で更新しているからではないか、という示唆を得られました。今回は、実際にカーネルのコードを読んで、この示唆が正しかったことを見ていきたいと思います。 調査対象 今回も新しめのカーネルで調査しました。Amazon Linuxとは多少ソースが異なっているかもしれませんが、本質は大きく変わらないかと思います。 ファイルシステム: ext4 Linux kernel version: 4.1.0-rc7 前回の復習 前回調べたときから約1年空いてしまいましたので、軽く前回の復習をします。 ext4のファイルシステムでは、ブロックグループという単
エンジニアリング・アドバイザーの noto です。先月末から新規事業チームのエンジニアリングについてもお手伝いすることになりました。 アカツキでは今年 (2015 年) の夏より、従来のゲーム事業の枠を超えて、教育、ヘルスケア、「働く」などの領域を対象とした新規事業の検討・開発を開始しています。(新規事業に関するプレスリリース / 新規事業公式ページ) こういった領域では「作っては壊し、作っては壊し」のトライアル・アンド・エラーが繰り返されると想定されるため、技術の選択に失敗した場合でもリカバリできる可能性も高くなります。そのため、従来のゲーム事業に比べると新しい技術を取り入れるチャレンジがしやすいと考え、社内で使い慣れた サーバサイド: Ruby on Rails ゲームクライアント: C++, Cocos2d-x とは別の技術を導入し始めています。 サーバサイド サーバサイドについては
Elixirの基本型 以下の基本型があります。 - integer : 1, 0x1F - float : 1.0 - boolean : true, false - atom (symbol) : :atom - string : "Elixir" - list : [1, 2, 3] - tuple : {1, 2, 3} 演算 iex> 1 + 2 3 iex> 5 * 5 25 iex> 10 / 2 5.0 Elixirでは/は必ずfloatを返します。 整数の商や余剰を得るには、divまたはremを使用します。 iex> div(10, 2) 5 iex> div 10, 2 5 iex> rem 10, 3 1 このように、Elixirでは関数を呼び出すのに括弧を省略できます。 2進数や8進数、16進数は以下のように使用でいます。 iex> 0b1010 10 iex> 0o
Motivation クラスメソッドさんがDevelopers.IOにとても良い記事を投稿されていたので、Elixir版も書きたくなりました。 Elixirを始める 最近のソーシャルゲームでは、ユーザー同士によるリアルタイムマルチプレイがトレンドになってきました。 アカツキが最近リリースしたメザマシフェスティバルも、Node.jsによってマルチプレイが実装されています。 個人的にリアルタイムゲームサーバーの他の実装例が気になったので、調べてみることにしました Call of Dutyの実装言語であるErlangですが、このErlangのVM上で動作するElixirという言語があります。 筆者はErlangも関数型言語も知見が全く無いですが、学んだことをまとめていきたいと思います。 動作環境 今回使用した動作環境は以下のとおりです。 OS: MaxOS X 10.9.5 Elixir 1.0
2015/05/19(火)に、レバレジーズさんが主催しているヒカラボで、以下3つの発表をしてきました。 RoRとAWSで100,000Req/Minを処理する RoRとAWSで100,000Req/Minを処理する from aktsk 定常的に 100,000Req/Min くらいを処理しているインフラを構築した時に考えていたこと、失敗したことです。 特別なことをやっているわけではなく、スケールアウトを考え、負荷テストで事前に計測し、過負荷な状態をすぐに検知できるようにするといった内容ですが、それを楽に構築するためにやったことを共有しました。 Node.js実践非同期処理 Node.js 実践非同期処理 from kidach1 Node.jsで非同期処理を実装するとCallback Hellになりがちですが、PromiseやGenerator(+co)を使って保守性・可読性高く実装する
背景 アカツキが提供しているサービスはリリース前に必ずテストを行っています。テストでバグが見つかったときにこれを切り分けるため、発生時のログを探すことがあります。「クライアントアプリで明らかに表示がおかしい」とか、そういったバグなら問題ないのですが、クライアントアプリからでは見えないサーバー側のバグが起きていて、それが見逃されてしまう…なんてこともあるかもしれません。 ふと、「機械的にこれを検出できるといいなー、あとログを探るためだけに毎回SSHするのもめんどくさいなー」 と思い、手を動かしてみることにしました。 今回の要件 テスト環境でサーバーエラーが起きたのを機械的に検出して、すぐ知らせてほしい アクセスしやすいところに必要なログだけがあると嬉しい できれば簡単な方法でやりたい ツールの選定 アプリケーションの例外を検知して開発者に知らせてくれるものに、ExceptionNotifie
エンジニアリングオフィス(以下EO)の島村です。 先日、アカツキゲームスに所属しているエンジニアを対象にディナー(交流会)を開催したのでレポートをさせていただきます。 開催のきっかけ もともと、エンジニア組織としては隔週火曜日17~18時に「エンジニア定例MTG」という完全オンラインの全体ミーティングを開催しています。 そこではエンジニア全体への連絡( イベントの告知など)はもちろんですが、外部カンファレンス参加のレポートや、有志により技術共有発表があったりと、エンジニア主導で様々な情報が交換されています。 そこにEOのメンバーより、最近は出社して作業している人も増えてきており、せっかくの集まる機会だからエンジニア定例のあとの時間に横の繋がりを作るエンジニアディナーを開催しようという提案があり、実施することになりました。*1 *1:元々、エンジニアディナーという企画自体は以前より不定期で開
背景 アカツキで提供しているサービスでは、ほぼ全てにおいてAWSのRDS(MySQL5.6, InnoDB)を使用しております。 ソーシャルゲームでは多くのWriteがかかりますが、そのコストが気になったので調べてみました。 調べてみたこと 一言にINSERTといっても、COMMIT時に即テーブルスペースに反映されるような単純な処理ではありません。 例えばINSERTしたテーブルにセカンダリインデックスがある場合、そこに加えられた変更を反映しなければなりません。 ところが、INSERT時バッファプール内に該当するインデックスのページが無い時はこれをディスクから読みだす必要があり、非常にコストが掛かります。 InnoDBにはこれを抑えるための"Change buffering"という機能があり、今回はその解説をしたいと思います。 Change bufferingとは 変更を加えたページがバッ
次のページ
このページを最初にブックマークしてみませんか?
『Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く