Akatsuki Hackers Lab | 株式会社アカツキ(Akatsuki Inc.)

Akatsuki Hackers Labは株式会社アカツキが運営しています。

【LT会】Akatsuki Geek Live開催レポート!

こんにちは、エンジニア採用担当の花田です。

この度、2/22(金)に学生向けLT会「Akatsuki Geek Live」を開催いたしました!

今回が初めての試みでしたが、30名を超える学生の方に集まっていただき、最高のLT会となりました!!この記事では、その様子を紹介いたします。

 

「Akatsuki Geek Live」とは...

学生エンジニアと、アカツキエンジニアが登壇するLT会です。今回は学生4名、アカツキメンバー4名の計8名が発表しました。その後、参加者全員で懇親会を実施し、交流の場を持ちました。

 

▼イベント概要はこちらから

aktsk.connpass.com

 

#なぜLT会を開催するに至ったのか

これまで学生の方にアカツキを知ってもらう機会として、会社説明会と座談会を開催していました。座談会での質疑応答は活発ではあったものの、より深くアカツキの技術やエンジニアメンバーについて伝える形にしたいと思っていました。

また、将来エンジニアとして活躍する学生のみなさんに登壇いただくことで、成果発表の機会や、他の学生の取り組みにふれて刺激し合ったり、同じ領域に興味を持っている方とのつながりの場を創ることで、可能性が開花するきっかけとなれば、という想いから企画しました。

 

#当日の様子

初めての開催ということもあり、参加者が集まるか心配しましたが、ふたを開けてみれば2度の増枠に。当日は32名が参加してくれました。また、学年不問で募集したため、4月からアカツキに入社する内定者や、20卒の内定者やインターン生、就職活動を迎える21卒の学生など多岐にわたるメンバーが集まってくれました。登壇順はくじ引きで決め、早速スタートです!

 

▼1人目:@sachaosさん(アカツキ)

「Goの静的解析ツールの作成と活用」

1人目は、アカツキメンバーから!Goによる静的解析のしやすさを発表してくれました。

f:id:kenji-hanada:20190227182712j:plain

発表資料

speakerdeck.com

 

▼2人目:@菱谷さん(アカツキ)

「今風トゥーンシェーディング」

2人目もアカツキから、新卒1年目の菱谷さんが、トゥーンシェーディングへのこだわりを熱く語ってくれました!

f:id:kenji-hanada:20190227183854j:plain

発表資料(speakerdeckには代理で登録しています)

speakerdeck.com

▼3人目:@tkhatotoさん(学生)

「Hack on Slash on Terminal」

3人目は学生枠からtkhatotoさん。会場から「このスライド見ていて楽しい!」と視覚的に楽しませてくれる発表でした!

f:id:kenji-hanada:20190227184515j:plain

 ▼4人目:@kawasin73さん(学生)

「俺はビッグエンディアンでテストがしたいんだ!」

4人目は学生枠からkawashin73さん!タイトルからも伝わってくる通り、掴みバッチリのキーワードから熱く想いを叫んでくれました^^

f:id:kenji-hanada:20190227185903j:plain

発表資料(speakerdeckには代理で登録しています)

speakerdeck.com

 

▼5人目:@大嶋さん(アカツキ)

「お父さんが教えるプログラミング教育」

アカツキから、子育て中のパパエンジニアとして、プログラミングの楽しさを伝えたいという想いが詰まっていました!特に「プログラミング的思考を料理で教える」というパートは非常にわかりやすく、参加者の多くがうなずきながら聞き入っていました。

f:id:kenji-hanada:20190227190634j:plain

発表資料(speakerdeckには代理で登録しています)

speakerdeck.com

▼6人目:@july1997さん(学生)

「MMOの作り方」

学生枠july1997さんがMMOの作り方というテーマで、クライアント、サーバ両方の観点から発表してくれました!

f:id:kenji-hanada:20190227192150j:plain

発表資料(speakerdeckには代理で登録しています)

speakerdeck.com

 

▼7人目:@Zepprixさん(アカツキ)

「Docker & ECSで構築するゲームアプリサーバーの話」

アカツキから新卒2年目のZepprixさんの発表。Docker & ECSを活用して管理コストを下げる話をしてくれました!

f:id:kenji-hanada:20190227192457j:plain

発表資料

speakerdeck.com

▼8人目:@acomaguさん(学生)

「RDF/OWLで始める人生イベントソーシング」

トリを務めるのは学生枠よりacomaguさん!RDF/OWLの「ゆるイイ!」理由を熱く語ってくれました。

f:id:kenji-hanada:20190227193151j:plain

発表資料

speakerdeck.com

 

熱のこもった8名の発表はあっという間に終わりました!

今回、登壇いただいた学生の方には、アカツキからプレゼントを贈り、続いて懇親会へ。

発表に刺激を受けたメンバーからの声や、同じ技術領域に興味を持っているメンバー同士での交流など、大いに盛り上がり、会を終えました。

f:id:kenji-hanada:20190228114007j:plain

 

参加者のみなさん、お疲れ様でした!

次回は4/26(金)に開催いたします!今回参加した方も、初めての方も大歓迎ですので、熱い想いを持ったみなさんにお会いできることを楽しみにしています!

 

▼次回予約はこちらから

aktsk.connpass.com

Go用HTTP APIテストコードジェネレータを開発しているというお話

こんにちは、mizzy です。業務委託でアカツキさんのお手伝いをしています。お手伝いの一環として、aktsk/atgen という、Go用HTTP APIテストコードジェネレータを開発しています。

この記事では、Atgenの概要や開発の背景、今後の予定などについてご紹介します。


Atgen とは

HTTP API Test Code Generatorの略で、HTTP APIをテストするためのコードを自動生成する、Go製のコマンドラインツールです。

YAMLで記述されたテストすべきHTTPリクエスト/レスポンスと、Goで書かれたテストコードのテンプレートから、実際にテストを実行するためのコードを生成します。

atgen/example at master · aktsk/atgen に動かすことができるサンプルがありますので、READMEの通りに動かしてみると、どんなツールなのか掴んでいただけるかと思います。


なぜつくっているのか

Goはその性質上、コードが冗長になりがちです。特に、HTTP APIをテストする場合、リクエストを出してレスポンスをチェックする、という同じような記述のテストコードをたくさん書くことになり、更に冗長になってしまいます。

コードが冗長になると、コピペも多くなりますが、コピペした後に修正すべき部分の修正が漏れることもあります。テストが失敗すれば修正漏れに気づくこともできますが、通ってしまうと漏れに気づかず、誤った内容でテストしているがそれに気づけない、ということになりかねません。

また、テストコードが冗長だと、全体の見通しが悪くなり、どのエンドポイントがテストされていて、どのエンドポイントがテストされていないのか、把握するのが難しくなります。

そこで、同じようなコードを書く手間を省き、コピペによるミスを防ぎ、APIエンドポイントのどこまでをカバーできているのかを把握しやすくするために、Atgenを開発することにしました。


開発にあたって検討したこと

このツールが、なぜこのようなつくりになっているのか、はコードを読んでもわからないですし、作者の自分も忘れそうなので、ここに記録しておきます。

YAMLにしたがってテストを実行するのではなく、テストするコードを生成するのはなぜか

ツールの方向性として、YAMLに基づいてテストコードを生成するのではなく、直接テストを実行する、という方向性も考えました。しかし、一度テストコードに落とし込んでから実行することで、テストが失敗した場合に、該当するコードを直接読むことができ、原因を調査しやすいだろうと考え、テストを直接実行するツールではなく、テストコードを生成するツールにしました。

テンプレート処理にtext/templateを使わずにAST書き換えを行っているのはなぜか

AST書き換えをせずにtext/templateを使った方がツール自体の実装は簡単です。しかし、{{ .Var }}のようなtext/template記法がテンプレートコード中に入ると、Go的には不正な構文となるため、go fmt でエラーになるなど、ツールやエディタの言語サポート機能を活かせなくなり、テンプレートコードを書く時ににとても不便です。なので、 text/templateは使わずにAST書き換えで処理をする、という形にしました。

あと、私がAST書き換えを行うようなツールを一度作ってみたいと思っていたから、という理由もあります。

テスト対象のリクエスト/レスポンスの定義にOpenAPI準拠のYAML/JSONを使わないのはなぜか

Atgenを導入しているプロジェクトでは、swagger.yamlでAPIの仕様が定義されているので、これをテストの定義にも使い回せないか、と最初は考えました。しかし、仕様の記述とテストの記述は似ているようで違っていて、特に以下の点が異なると考えています。

  • リクエストやレスポンスのパラメータの違い
    • 仕様ではパラメータの型が定義されるが、具体的な値は定義されない
    • テストでは具体的な値を記述する必要がある
  • コンテキストの有無の違い
    • 仕様では各リクエスト/レスポンスが独立した形で記述される
    • テストでは、このパラメータでPOSTしてから、GETするとこういうパラメータが返ってくる、みたいな形で、複数のリクエスト/レスポンスの関連性を記述する必要がある

このような違いがあるため、OpenAPI準拠のYAMLでテストの定義までカバーするのは無理がありそうだ、と判断して、無理に寄せることはせずに、あえて別のフォーマットにしています。

また、Go用のツールなので、Goの慣習にしたがい、Goの機能を活かしたコードを生成できるようなフォーマットにしたい、という理由もあります。


実戦投入してみての所感

既存プロジェクトのテストコードとほぼ同等なコードをこのツールで生成できるようになったので、生成したテストコードをCircleCIで回すようにしてみました。実践投入してまだ間もないですが、現在のところの所感は以下の通りです。

  • テスト定義をYAMLで記述することで、テスト項目全体の見通しがよくなり、APIエンドポイントのどこまでカバーされているのか、把握しやすくなる。
  • 見通しがよくなることで、レビュアーがレビューしやすくなり、テストの間違いや漏れを見つけやすくなる。
  • 反面、前処理などテストによって微妙に処理が異なるところがあり、ひとつのテンプレートで吸収しようとすると、ifでの条件分岐が多くなり、コードの見通しが悪くなる。
  • 書き換えのためのルールを把握してテンプレートコードを記述しないといけないので、普通にテストコードを書くよりも面倒。
  • このように、テスト項目のメンテナビリティは向上するが、コードのメンテナビリティは低下する。
  • が、テストは書くことよりもメンテナンスすることの方が大変なので、トータルで見ると運用コストを下げてくれそう。
  • テスト項目のメンテナビリティを保ちつつ、コードのメンテナビリティをいかに下げるか、という方向でツールを改善していくのが今後の課題。

今後の予定

まだツールとしては発展途上で、やることはたくさんありますが、以下の様な方向で考えています。

  • ドキュメントの充実
    • 特に書き替えルールがわかりにくいので、その辺りを重点的に。
  • 使い方をわかりやすくする
    • YAMLだけでできる範囲を広げ、できるだけコードを書く量を減らす。
  • OpenAPI準拠YAML/JSONとの連携
    • OpenAPI準拠YAML/JSONとテスト定義YAMLを突き合わせ、テストされてないエンドポイントを出力する、といった機能

または、もっと違う方向性で実装しなおした方が良いのでは、とも考えています。というのも、Atgenは汎用的に使えるようにするため、テスト対象のAPIサーバのコードには一切関知しない、というスタンスで実装しています。ですが、APIサーバのコード内で定義されている型などをうまく利用した方が、よりわかりやすい形でテストコードが書けます。とは言え、テストコードジェネレータが特定のAPIサーバのコードに依存してしまうと、汎用性が失われてしまいます。これを解決するために、テストコードジェネレータではなく、テストコードジェネレータの開発を支援するライブラリとして実装する、といった方向性もあるのではないか、とぼんやりとですが考えています。


謝辞

ツールの実装にあたって、tenntenn さんによる Go AST に関する Qiita 記事motemen さんによる GoのためのGo がとても参考になりました。この場を借りてお礼を申し上げます。

開発環境インフラを ECS 移行している話

 この記事は Akatsuki Advent Calendar 2018 の24日目の記事です。 前回は id:NeoCat さんのElixirのサーバアプリケーションをDatadog APMでトレースするでした。

はじめに

はじめまして、運用中ゲームタイトルでサーバーエンジニアをしている守屋と申します。 私の所属するチームでは AWS EC2 上でサーバーサイドの運用を行ってきました。サービスリリース当初からの様々な改善の積み重ねの結果、近頃はインフラ障害も少なくなり、安定した運用が実現しています。しかし安定した運用が実現すればサーバーエンジニアの仕事は終わりなのでしょうか?安定しているとはいえ既存インフラには様々な技術的な負債が蓄積されています。我々サーバーチームは既存インフラを設計から見直し、新環境へ全てを移行する一大決心を下したのです。

続きを読む

ElixirのサーバアプリケーションをDatadog APMでトレースする

この記事は Akatsuki Advent Calendar 2018 の23日目の記事です。 前回は id:yunon_phys さんの、エンジニア組織の責任範囲の透明性をRACI図で高めてみた でした。

はじめに

アカツキではElixirを使ってゲームのAPIサーバを開発・運用しています。 ゲームのAPIサーバは、大量のリクエストを低いレイテンシで捌くことが要求されるため、Erlang VMの高いスケーラビリティが利用できるのは効果的です。加えてRubyなどを書き慣れている人にとっつきやすいElixirの文法も魅力です。

とはいえ、その性能を引き出すためには、やはりアプリケーションのパフォーマンスチューニングは不可欠です。 その際、"Don't guess, measure" という言葉の通り、どこを改善すれば良いかを知るための良い計測ツールが必要になります。

これまでRuby on Railsのアプリケーションでは、計測・監視のためにNew RelicをAPM (Application Performance Monitoring) ツールとして使っていたのですが、現在New Relicでは公式にはElixirはサポートされていません。*1

そこで今回は、インフラの監視に利用していたDatadogにAPMも統合できることを期待して、Datadog APMを利用してみることにしました。

Datadog APMでは単なる集計値のみならず、タイミングの記録にも対応しており、下記のように個々のAPI内の処理内容をフレームグラフとして見ることも可能なため、性能改善には有効そうです。

f:id:NeoCat:20181215201740p:plain

*1:コミュニティによるライブラリは開発されていますが、Phoenixを前提としているものが多いようです。後述の通り、今回の対象アプリケーションはPhoenixを使用していないため、採用は見送りました。

続きを読む

エンジニア組織の責任範囲の透明性をRACI図で高めてみた

こんにちは、ゆのん(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回を突破するなど、多くの方から注目を集めています。*1

*1:このPodcastはエンジニアリング組織論への招待の著者である広木さんと、私がやっています

続きを読む