yuemori

Rails Developers Meetup 2018に進行協力・登壇しました


こんにちは。大阪スタジオの植森です。

Ruby on Rails の “現場の知見”に触れる Meetup

Rails Developers Meetup 2018が3/24(土)、3/25(日)の二日間に渡り開催されました。

Rails Developers Meetup 2018: Day 1

Rails Developers Meetup 2018: Day 2

弊社Aimingからは黒木(が発表、私植森(@wakaba260yen)がDay2の司会進行とPRスポンサー発表として参加しました。

二人とも大阪スタジオ所属で、このために東京まで足を運びましたが、それだけの価値のあるイベントでした。こうしたイベントに発表・運営協力の両面で参加できて非常に良かったと思います。

大阪中継会場の提供

弊社大阪スタジオを会場提供し、大阪へのLive中継も行われました。

当日はYoutubeでのLive配信があったのですが、大阪中継にも人が集まり、このイベントへの関心の高さが伺えます。

今回はRails Developers Meetup通じて初めてのAトラック・Bトラック同時開催だったのですが、大阪でも2トラック同時中継を試みました。中継をどうするかについては相談していましたが、やはり2トラックどちらも中継することでLive感を大事にしたいという気持ちもあり、こういった形での会場提供とさせていただきました。

手を貸してくれた社員と、こちら側の要望に応えて中継の手配をしてくれたオーガナイザーの方々のおかげで実現できましたが、結果として大阪会場に来ていただいた参加者の皆様にもご満足いただけたなら嬉しいです。

冴えてるRailsエンジニアの育て方

黒木()による、弊社で行っているRailsエンジニアの採用・教育の取り組みについての発表でした。

当日は私が司会を担当しているBトラックでの発表だったのですが、他のセッションに比べてもなお盛況だった印象です。

大阪会場のスタッフから話を聞いたところ、大阪側もほぼ満席だったとのことで、教育・採用に対しての関心の高さが伝わってきました。

弊社では採用の際にゲームプレイヒアリングシートというものに今までプレイしたゲームとそれに対する簡単な感想を書いて提出してもらっています。そうした取組みを紹介しつつ、教育の際に考えていることなどをお話させていただきました。

twitterでも弊社のゲーム会社らしい採用の目線や、ペアプロ、教育の取り組みなどに良い反響を頂けたと思います。

 

サービスクラス、その前に

PRセッションは、私植森(@wakaba260yen)の方よりサービスクラスの前に知っておきたいことをテーマに話をさせていただきました。

会社の方から「最後にPRしてもらえればなんでもいいよ」と言われていたので、PRセッションというよりもLTに近い雰囲気で話をしようと思い、こういう話になりました。

Day2はチームビルディングの話が多く、他のセッションが心に響く内容ばかりで、自分の話が皆さんの心に届くだけのパワーがあったかどうかは自信がありませんが、少しでも感じるものがあったら嬉しいです。

仰っていることは完全に同意で、「オブジェクト指向実践ガイド」の話をしながらのRubyでオブジェクト指向や設計についての話も本当はしたかったのですが、今回はちょっとエモい話をしたかったのでカットしました。

いつか機会があったらそういう話もしたいと思っています。

Rails Developers Meetup2018の司会を通じて

私はいつもは大阪側で中継スタッフをしていますが、今回は司会というポジションで参加しました。

司会についての感想は同じ日に別トラックで司会をされていた、みんなのウェディングの櫻井さんが熱い記事を上げられているので是非そちらを見てください。

オーガナイザーである平野さん(@yoshi_hirano )は、以前フリーランスとして大阪スタジオで働かれていたことがあり、その時のご縁もあってRails Developers Meetupのスタッフの一人として参加させてもらっています。

平野さんは本当にパワーのある人で、Rails Developers Meetupの初回からずっと走り続けて、一年もしないうちにこんなに大きなイベントにされてしまうなんて想像もしていませんでした。

Day2のセッションでしなもんさん( )によるバス因子の素晴らしい発表があったのですが、Rails Developers Meetupのバス因子は平野さんだと思います。平野さんの代わりなんてとんでもない、とは思いますが、進行や準備の協力など少しでも平野さんの負担を減らせられたら良かったと思います。

まあ、司会が終わった今となっては「楽しかったので是非次回もやらせてください」という気持ちなのですが。

まとめ

発表者の方々、ボランティアスタッフの方々、オーガナイザーの平野さん・秒速さん、そして参加者の皆様。

皆様のお陰であの楽しい二日間があったと思います。ありがとうございました。

We Are Hiring!

Aimingではエンジニアを募集しています。

セッションやこの記事を見て興味をもっていただけたなら、是非エントリーください!

https://aiming-inc.com/ja/jobs/


s-kuroki

Code Review Meetup #2に会場を提供しました&発表しました #codereviewmeetup


大阪スタジオのwebエンジニアの黒木です。

3/9(金)に開催されたCode Review Meetup #2に大阪スタジオのセミナールームを提供しました。

その名の通りコードレビューの話をする勉強会で、前回(東京開催)と今回はコードレビュー自動化サービスのSideCIさんが主催されました。(誰が主催しても良いというスタンスだとおっしゃられてました)

SideCI 角さんの発表

最初に行われたのは、SideCIのFounderの角さんの発表です。

角さんがSideCIを立ち上げるに至った経緯から、コードレビューサービスを運営しているからこそ見える、いろんな企業さんのコードレビューのあり方についてのお話で、非常に興味深く聞かせてもらいました。

LT

LTでは、Aimingから3名に加えて、飛び入りで1名、計4名が発表しました。

伝わるコードレビューのために(黒木)

焼肉とレビューの関係 〜難しいコードレビューのコツ〜

Qiitaにスライドが上がっています

oznor

ダブルレビューをやってみて

oznor

飛び入りの @whosaysni さんの発表

発表内容は公開されないということでしたので具体的な内容は控えさせてもらいますが、職場でレビュー文化を根付かせようと奮闘されているお話で、いろんなあるあるに共感しつつ聞かせてもらいました。

パネルディスカッション

角さんとLTの参加者で短めのパネルディスカッションを行いました。
参加者の皆さんからいろんな質問が出ました。皆さん、コードレビューの勉強会に来られるだけあって、コードレビューをチームに導入しようとしていて悩まれていたりしていて、非常に温度の高い話になっていたかなと思います。

まとめ

コードレビューの勉強会と聞くとニッチな感じもしましたが、チームで開発をやっていくには欠かせない重要な要素ですし、いろんなところでチーム開発に奮闘されている方が参加されていた、良い勉強会だったと思います。
また、出席率が100%だったそうで、その高さにSideCIの皆さんも驚かれていました。それだけ皆さん温度が高かったのだと思います。

宣伝

Rails Developers Meeting 2018でも会場提供&発表します!

来る3/24,25に開催されるRails Developers Meeting 2018でも、Aiming大阪スタジオで中継を行います。
中継会場の参加枠(1日目2日目)にはまだ空きがありますので、興味のある方は是非ご参加いただければと思います。
私も2日目に「冴えてるRailsエンジニアの育て方」というタイトルでお話させてもらいます。

Aimingは各種勉強会への会場提供をしています

東京本社大阪スタジオで勉強会に会場を提供しています。お気軽にご連絡ください。


菅野 明洋

第4回 Game Gatling LTに登壇してきました!


はじめに

初めての人は初めまして、前回の記事(社内でエンジニア読書会をやってみた!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2017年12月9日の土曜日に大阪で開催されました第4回 Game Gatling LTにて、スピーカーとして私と藤井が登壇させていただきましたので、レポートとしてまとめました。

GGLTとは

関西でゲーム開発に携わるエンジニア、デザイナー、プランナー等の人が集まり、ライトニングトークを行うイベントになります。

今回発表させていただいた内容について

今回の発表は、ミドルウェアの性能試験などの話になります。

■菅野明洋:我流ミドルウェア性能・障害試験の心得

■藤井章暢:仕事以外でプログラミングのモチベを上げる方法

私の発表ではミドルウェアの性能試験を中心に発表しました。今回は後進向けの教育を想定した作りにしております。
プロジェクトでミドルウェアを選定する場合、枯れていないミドルウェアを用いると情報が少ないケースが非常に多いと思います。その中で、少しでも多くのノウハウを積むための考えみたいな物をまとめてみました。ミドルウェアを適切に選定や使用できなかった場合は単純に開発・検証する以上のコストがかかるケースが多いため、きちんと精査していきたいと思います。

藤井の発表では、業務外でのプログラミング活動についての話を発表しました。
日々の情報収集などをどのように行うか、通勤途中の時間や休日をどう活かすかなどの実例の紹介になります。業務上で知識を得るのも重要ですが、課外活動や日々の行動改善で知見を得るのも重要かなと思います。
詳しくはスライドをご覧ください。

■発表中の様子

発表中の菅野

発表中の藤井

感想

今回は、登壇だけでは無く運営の参加にも挑戦してみました。
業務を行いながら並行で準備するのは大変でしたが、勉強会の裏側が見れて良い経験ができたと思います。

また、登壇については、やや時間配分を間違えて残りのページを話しきれなかったのが残念でした。次回はそのようなミスが無いようにしていきたいと思います。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。色々と面白い活動の話や、明日から実践してみようと思えるような話等が聞けて良かったです。
今後も皆様とこのような場で情報交換できると幸いです。


onose

Aiming Meetup #1 ゲームグラフィックス編 開催レポート


こんにちは!Aiming人事の小野瀬です。
今回は10月18日に開催されたAiming Meetup #1 ゲームグラフィクス編についてご報告いたします!

当日はたくさんの方にご参加いただきまして、
おかげさまでLTも大変盛り上がり、大盛況のうちに開催することができました。
お忙しい中お越しくださった皆様ありがとうございます。

Aiming Meetup

Aiming Meetupとは、勉強会のような堅い雰囲気ではなく、お酒を飲みながら比較的ラフな雰囲気でLT(LightningTalk)大会を行うクリエイター交流イベントです!

開催頻度はこれから1 ~ 2ヶ月に1回を予定しており、
「UI/UX」や「インディーゲーム開発」など、様々なテーマで実施していきます。

記念すべき第1回は「ゲームグラフィックス編」。
LightningTalkでは他社さまも含め総勢6名のクリエイターが登壇し、ゲームグラフィックスに関して熱弁を振るいました。
一部資料が公開されておりますので、ご興味がある方はご覧ください!




次回予告

次回のAiming Meetupは「UI/UX」をテーマに開催予定です。
興味がある方はconnpassのAimingグループのフォローをお願いします!

改めまして、登壇者の皆様、参加者の皆様ありがとうございました。


vivid_muimui

サーバーサイド勉強会(2017年5月)


東京スタジオのエンジニアの小山です。

この記事では、5月中に行われたサーバーサイド勉強会の内容を紹介したいと思います。
サーバーサイド勉強会の紹介や4月分の内容は前回の記事を見てください。
https://developer.aiming-inc.com/study/server_side_study_201704/

5/11 LT

月初のLTです。

今回は全体的に真面目な勉強ネタという感じではなく、ゆったりとしたものが多かったです。(公開できるスライドが少なくてすみません><)

記号でRuby

社内である日突然出された以下の問題の解説でした。

Ruby (2.3.x あるいは 2.4.x) で以下の条件の下に Hello という文字列を標準出力に出力するプログラム、
あるいはそのようなプログラムを出力するプログラムを書きなさい。

アルファベット、数字、スペース、\u007f 以上のコードポイントの文字を利用してはならない
つまり↓の文字のみを使ってよい
解答時に、レイアウトの都合でプログラムの意味が変わらない程度の改行の挿入は許可

!"#$%&'()*+,-./:;<=>?@[]^_`{|}~

(回答の例はこちらです。)

解説されている間はなんとか理解できている気がするのですが、魔術を説明されているようでとても難しかったです><
解説のスライドは公開できませんでしたが、ぜひ皆さん挑戦してみてください。ちなみに僕は解けませんでした!

5/18 code smellを検出するreekのチェック項目を読む

reekというコードスメルを検出するgemのチェック項目を読む回でした。

Reek is a tool that examines Ruby classes, modules and methods and reports any code smells it finds.

https://github.com/troessner/reek/blob/master/docs/Code-Smells.md
このページにチェック項目一覧があるので、上から順番に眺めていきました。

どれもチェック項目として納得いくものばかりですが、実際運用することを想定したときに、

  • 全部デフォルトだと厳しい
  • ケースバイケースなのでどこに基準を設定するのか難しい
  • 養成ギプスとしては良さそう

というのが全体的な感想でした。
あまりプログラムを書くことに慣れていない・Rubyに慣れていないという場合には設定するとメリットが大きそうです。そうでない場合には、Reekの設定のメンテコストや指摘箇所の対応コストが発生し、メリットよりもデメリットのほうが大きくなりそうという印象です。
ただ、こういうコードスメルがある事自体はちゃんと認識しておく必要があるので、たまに思い出したときに初心に返る気持ちで見直したいなと思いました。

5/25 react-rails の入門ハンズオン

@yhirano55によるreact-railsの入門ハンズオンでした。
@yhirano55がこのハンズオンのために用意した資料を見ながら進めました。react-rails gemに特化した内容ではなく、Reactに触れてみよう、ReactをRailsで使ってみよう、という内容のチュートリアルでした。
資料がとても良くできていて、1時間という短い時間でしたがとりあえず動かすことができて基礎も理解できました。恐る恐るレビューしていたReactのコードも今はちょっと読めるようになりました!
資料は口頭での解説がなくても十分できるようになっていると思いますので、興味ある方はぜひやってみてください。

おわりに

5月はGWがあったので3回分だけでした。
今月はReactのハンズオンが個人的にとても良かったです。Reactに関する情報は色んな所で見聞きしてはいましたが、実際に触ったことがなく、なんとなく怖いという印象を持っていました。ですが、今回実際触ってみると全然怖くないなって思いました!
情報を見聞きして満足するだけでなく、実際触ってみることが大事だなと改めて痛感した回でした。


水島 克

スマホゲームのUI仕様書


ゲームデザイナの水島です。

Aimingでは定期的に社内勉強会をやってます。

自分は若いプランナー向けにゲーム開発の基礎的な話をすることが多いのですが、新しいメンバーが増えてくると、何年か置いて同じ話を繰り返しすることもあります。手抜きといえばそのとおりなんですが、自分の中でも定期的に見直す良い機会だと思ってまして、今回もそんなお話です。

5年前に行った勉強会のスライド「企画が考えるスマホUIデザイン」は、現在27万viewと多くの方にみていただきました。

でもいま見返すと古いと感じるところも結構あります。当時はブラウザのソーシャルゲームからの移行期で、スマホネイティブのゲームも今ほど多く無かったため、いろいろ手探りの状態だったな~と思い出します。弊社の話でいうと、制作のパイプラインなんかは、その後だいぶ改善されたと感じてます。

そこで今回はもうちょっとテーマを絞って、UI仕様書について話してみることにしました。

スライドの中でも触れてますが、プランナーが書く仕様書の位置づけはチームによってバラバラ。しかも人によってはこだわりを持つ部分でもあるため、時に議論のたねになります。例えば、エクセル方眼紙のメソッドは宗教論争みたいになることもあって、傍から見てると面白い。

今回はもうちょっとマイルドに、「チーム毎に仕様書の項目の優先度をつけて書いてみてはどうか」という提案を盛り込んでみました。これが正解!というつもりもなく、選択肢の一つになるとよいかなと思います。

スマホゲームのUI仕様書

ちなみに5年前のスライドはこちらです。

企画が考えるスマホUIデザイン


菅野 明洋

社内でエンジニア読書会をやってみた!


はじめに

初めての人は初めまして!
前回の記事(第2回 Game Gatling LTに登壇してきました!)を見てくれてる人は、お久しぶりです!

大阪スタジオ インフラチームの菅野明洋です。
業務では、主に大阪スタジオのサービスインフラを担当させていただいております。

今回は、読書会を開いてみましたので、その話をまとめました。

読書会について

読書会は、集団で読書や読書に関するコミュニケーションを図るイベントです。
弊社では興味がある話題や本ごとに幾つかの読書会が開かれております。

開催してみた読書会について

今回は、SQLアンチパターンと言う本を題材にしております。
この本の読書会をするキッカケとしては、弊社の若手のエンジニアが最近読み始めたと言うことで話題に上がったことと、他のエンジニアと意見交換出来たら面白いと言う事で開いてみました。

読書会のルールについて

基本的に参加自由

  • 参加者は8〜12人程

開催時間

  •  定時後の45〜60分
    • 子育てで忙しい人も参加しやすくするために短めに設定
    • 経験上、1ページ2分換算で調整
  • 時間内(15〜20分程度)に章の全てを読みきれない場合は2日に分ける
    • 2日に分ける場合の例
      • 1日目にアンチパターンの問題点を黙読し他班に説明
      • 2日目にアンチパターンの解決策を黙読し他班に説明

用意したもの(書籍以外)

  • 付箋、筆記用具
    • 質問や意見を記入
  • ホワイトボード
    • 書籍の内容の説明や上記の付箋を並べるのに使用
  • キッチンタイマー(スマホアプリ)
    • 時間調整に使用

やり方

読書会の流れ

事前にやること

  • 読書会の日時、場所を決める

ステップ1(班分け)

  • 参加者を2班に分ける
    • 現在の決め方は座った席を順で分ける

ステップ2(読書フェーズ:アンチパターンの確認)

  • 各自担当箇所の章を黙読
    • 最近は読む際に付箋を配り、気になった点や質問したい内容を記入
    • ページ数に応じて変更しますが、大体15〜20分を目安にしています

ステップ3(説明フェーズ)

  • 読んだ箇所を別の班に説明
    • 説明する際は、図説する際はホワイトボードも使用
    • 章ごとに10分程度(計20分)の説明する

ステップ4(質問・討論フェーズ)

  • 全体を通して質問、討論を行う
    • 気になる点、分からない点を確認し解消する
    • 討論時にはアンチパターンに対してどのようにアプローチすべきなのか、他に方法が無いのかなど参加者の想いや考えなどのやり取り
    • 過去の話とかで盛り上がることもあります

読書会の様子

弊社の藤野がSQLアンチパターンの5章EAVについて説明している様子

読書会中に書き留めた付箋を集めてホワイトボードに貼っている様子(5,6章)

読書会中に書き留めた付箋を集めてホワイトボードに貼っている様子(3,4章)

ものすごく盛り上がっている時はホワイトボードにびっしり文字や図説が書かれていることもあったのですが、写真を取っていなかったため、現在記事を書きながら後悔しております。

読書会での試みと効果(参加者のフィードバック)

課題1:短時間で効果的に理解を深めたい

  • 対応策
    • 黙読後、読んでいない人に説明する
  • 効果
    • 説明する際に一度情報を整理するため、理解を深めやすくなった

課題2:質疑応答の敷居を下げる。意見を拾い上げやすくする

  • 対応策
    • 付箋を配布し、記入してもらう
  • 効果
    • 気軽に質問しやすくなった
    • 付箋を並べることで、他の参加者の質問(悩み)が見えやすくなる
    • 類似する意見があることで、他の参加者も同じ疑問を思っている等の安心感を覚える
    • 最初から質問・意見の数がわかるため進行の調整が楽になった

最後に

読書会を通して他のエンジニアと意見が交換できたので、とても参考になりました。
技術的な話のみだけではなく読書会の運用方法なども含め様々な意見を頂き、とても勉強になりました。今回の読書会では、まだ未完成な部分もあり進行が安定していないため、ブラッシュアップをしていかなくてはいけないと考えております。
毎回試行錯誤の繰り返している状態ではありますが、今後もこのようなイベントを続けて、より完成度を高めていきたいです。


vivid_muimui

サーバーサイド勉強会(2017年4月)



東京スタジオのエンジニアの小山です。

Aimingでは勉強会や読書会などがいろいろな形で行われているのですが、そのうちの1つにサーバーサイド勉強会という取り組みがあります。
この記事では、サーバーサイド勉強会自体の紹介と、4月中に行われたサーバーサイド勉強会の内容を紹介したいと思います。

サーバーサイド勉強会とは

サーバーサイド勉強会は、東京スタジオの主にrailsを書いているメンバーを中心とした勉強会で、週に1回1時間を業務時間中にとって行われます。(大阪スタジオでもサーバーサイドのメンバーを中心とした勉強会は行われています。)
内容や形式に関しては、「月初はLTを行う」というのが決まっていますが、それ以外は毎回違います。リリースノートを読んだり、ハンズオンをしたり、その時々で興味あるものホットなものをネタにやっています。

少し変わった取り組みとして、毎回常に Google Hangouts を使って社内のみですが配信をしています。忙しくて勉強会の会議室には行けないけど聞きたいという人や、大阪スタジオの人が見れるようにするためです。

参加人数は、会議室・Google Hangoutsそれぞれに10人弱ずつぐらいという規模で行われています。

4/6 LT

月初のLTです。LTの時間は5分でやっています。

  • Google Cloud Container Builderの話
  • ChainerRLを触ってみた話
  • UNIXコマンドの基礎
  • ズルいUI
  • 色の話
  • 美しい Slack 通知を飛ばす美しいコマンド
  • OSS Gateに参加した話

この記事を書くことになったのがLTの発表後だったため、公開できるように作られてないLTが多かったのですが、2つ公開できたので紹介します。

美しい Slack 通知を飛ばす美しいコマンド

https://rastamhadi.github.io/slides/slack_notification_command/

reveal-jsで表示されています. ?を押すとキーボードショートカット, sでスピーカーノートが表示されます

色の話


この回のLTは全体的にクオリティが高いものでどれも為になったのですが、個人的にUI/色の話がとても勉強になった回でした。
絵やデザインといった分野はとても苦手で避けてきたのですが、LTを聞いて頑張れば少しはできるようになるのでは?やってみよう、という気持ちができてきました。LTのあとの雑談で紹介された「ノンデザイナーズ・デザインブック」は速攻で注文し少しずつ読み進めてます!

4/13 Google Cloud Functions で Slack のスラッシュコマンドを作ろうハンズオン

https://cloud.google.com/functions/ 「Google のインフラストラクチャに基づくサーバーレス アプリケーション」

AWSでいうところのAWS Lambdaなのですが、そのCloud Functionsを使ってサーバーレスでお手軽にslackのスラッシュコマンドを作ってみよう、というハンズオンです。
ほかのサービスを連携したりせずに、ハードコードされたリストからランダムに選択しslackに返す、という実装をしました。

実際作られたものの一部が↓です。(どちらも僕が作ったものではありません>< )

シンプルな実装ではありますが、slackとgcpの画面をポチポチ設定して、少しのコードを書くだけでスラッシュコマンドが作成できて、本当にお手軽でした。
ハンズオンではやらなかったのですが、 Firebase Realtime Databaseを使ったスラッシュコマンドの作り方も紹介されました。

とてもお手軽だし便利で最高でした!
ですが、どんなスラッシュコマンドを作るかのアイディアが出ずに僕はまだ何も作れてないです!

4/20 Mastodonのコードリーディングとかアーキテクチャを覗いて見よう

流行りのMastodonのコードリーディングをする回でした。
https://github.com/tootsuite/mastodon
最初にMastodonがどういうものかという話がされ、rake stats -> Gemfile -> schema.rb -> modelを少し、という順に眺めていきました。
大半はGemfileを眺める時間に費やされましたが、知らないGemが多くrubyのエコシステムの充実さスゴイなと改めて思いました。

実装の詳細は全然見れなかったですが、「このgem知らなかった!便利!」とか「この書き方いいね」「この命名なるほど!」など十分有意義なコードリーディング回でした。

4/27 RailsGuideのActiveSupportのページ読み

RailsGuidesの「Active Support コア拡張機能」のページを上から眺めていくという回でした。
本家翻訳版

blank?tryなどのおなじみのが多いですが、上から順番に眺めていくと知らなかったものも結構ありました。
知らなかった中でぼくが便利そう!と思ったのは

この2つでした。

Object#instance_valuesはその名の通りinstanceのインスタンス変数をハッシュにして返してくれます。

class C
  def initialize(x, y)
    @x, @y = x, y
  end
end

C.new(0, 1).instance_values # => {"x" => 0, "y" => 1}

使う機会はそんなに多くはないかもしれないですが、ActiveRecordの#attributesと似た振る舞いですし色々使いみちはありそうです。

String#squishString#stripと似てるのですが、冒頭と末尾のホワイトスペースを除去するString#stripの挙動に加えて、文字列中の連続したホワイトスペースを一つに減らしてくれます。

" \n  foo\n\r \t bar \n".squish # => "foo bar"

RailsGuidesは全体通すとボリュームが多いですが、見るたびに既に見たことが有るページでも新しい発見があるので、定期的に読み直さなきゃなと改めて思いました。

おわりに

月イチでLTを行う現在の勉強会のスタイルなって半年ほどなのですが、正直なところLTのネタ出しは毎回苦戦しています。
ですが、
LTをする -> 勉強会・LTを通して新しいことを知る -> ネタ出しのために勉強する -> LTをする(最初に戻る)
という良いサイクルが自分の中に出来上がりつつあって、現在の勉強会のスタイルは個人的にとてもありがたいスタイルだなと感じています。

まだ勉強会で吸収することばかりですが、そのうち新しいものを伝えていく側になれたらと思っています!


藤井 章暢

クローバーラボ株式会社の方々と勉強会対決しました


こんにちは。
大阪スタジオ、クライアントエンジニアの藤井です。

去る3月11日(土)にクローバーラボ株式会社の皆さんと勉強会対決を行いました。
私も登壇させて頂きました!
今回はその内容と結果をレポートしていきます。

イベント名

激突! Aiming x CloverLab

ルール

4つの対戦項目(後述)で勝負を行いました。
発表の最後に参加者の皆様にAimingスタッフ・クローバーラボスタッフのどちらの内容が良かったかを投票していただき、その得票数を競うと言う内容でした。
持ち時間は1人15分でした。

対決項目(お題)

・クライアント
・インフラ
・サーバー
・開発環境

各発表内容のまとめを記載していきます。
続きを読む


勉強会・カンファレンスの運営スタッフとしての活動


大阪スタジオのwebエンジニアの富田です。

弊社の新卒採用サイトが公開されました!
私の写真も使われていて、ちょっとドキドキしてしまいます。

リクルートサイトの中でも記載されているのですが、Aimingでは社内・社外のコミュニティ活動が推奨されています。
今回は、大阪スタジオのスタッフが運営で関わっている、関西の勉強会・カンファレンスをご紹介したいと思います。


Game Creators Conferenceは、関西で最も大きなゲーム関連のカンファレンスです。

今年は、2/18に開催され、550枚のチケットが完売する盛況ぶりでした。
このカンファレンスの実行委員にエンジニアマネージャーの槙石が参加させて頂いています。

昨年の開催時は、サーバーエンジニアの山藤が登壇しエントリを書いています。


関西ゲーム勉強会は、過去11回行われている勉強会です。

前回は250名ほどご参加頂けました。
Game Creators Conferenceよりも、開発者の現場に近い部分の勉強会を目指し、参加者同士の交流を目的としています。

最近は規模が拡大し運営が大変になってきていますが、開催する毎に新しい出会いや達成感があります。

昨年、私が運営として参加した時のエントリです。


Game Gatling LTは、15名程が登壇し連続してLTを行う、若干特殊な勉強会です。

参加者は、多くのゲーム開発者の登壇を聞くことができ、登壇者もLTということであまり負担もなく、楽しんで頂いているかと思います。
過去2回開催し、いずれも好評でしたので、第3回も計画中です。

インフラエンジニアの菅野が登壇のエントリを書いています。


3/11(土)には、合同勉強会ということで、クローバーラボ株式会社様と「激突! Aiming x CloverLab」を開催します!
遊び心で対決形式になっています。どうなることか、とても楽しみです!

勉強会・カンファレンスの運営はあまり表に出ることはありませんが、コミュニティのメンバーの方々と協力しながら、開発者同士の交流のお役に立てれば!と思います。