iOSDC Japan 2019に行ってきました

こんにちは、Studyplus iOSチームの明渡(id:m_yamada1992)です。

iOSDC Japan 2019(2019年9月5日〜7日)にiOSチームのうち2名(大石、明渡)で参加いたしました。 なお、費用については下記のスポンサー枠1名 + 弊社の 勉強会・カンファレンス参加補助 で参加させていただきました。

私自身ルーキーズLTにプロポーザル提出してたのですが、残念ながら不採択だったので参加補助を利用。 iOSDC初参加初登壇は叶わなかったものの、めげずに来年以降もまたチャレンジしたいなと思います！

iOSDC Japan 2019 にスポンサード

iosdc.jp

スタディプラスはシルバープランでスポンサーとして、トートバック内にノベルティ提供をさせていただきました。 参加した方は、弊社ロゴ入りを付箋をゲットしたはず。

感想

参加メンバーそれぞれで記載いたします。

明渡

当日参加したセッションの中で、とても印象に残ったセッションについて感想を記載いたします。

Heart of Swift @Yuta Koshizawaさん

fortee.jp

正直なところ、このセッションの内容をほとんど知らなくても、なんとなく書いてなんとなく動くアプリをSwift言語をもって作れてしまう。実際、私がそうでした。

JavaやPythonなど他の言語も少々書いていたことがありますが、Swiftがなんとなく書きやすくて好きだなと感じていた根拠が凝縮された内容で、Swiftにより愛着が湧きました。

Reference SemanticsよりValue Semantics、プロトコルは型としてより制約として使うことを優先して検討するというお話は今後積極的に意識しながらソースコードを書く所存です。

色の難しい話に負けない体づくり60分 @ しもとりさん

fortee.jp

先日のtry! Swift Tokyo 2019で発表のあったアクセシビリティのためのカラーコントラストをきっかけに、ありとあらゆる理解を投げ出したくなる色にまつわる事柄を分かりやすくまとめあげたお話。 自分は上記の発表を聞いた際に「色に関する基準の存在を知ったので、ダークモード対応時もこれをもとになんとかできるだろう」と細かい話を理解するのは諦めてました。

なので、これだけ掘り下げて理解して、しかも発表用に情報を整理してまとめあげるって凄まじいなと尊敬の念を覚えました。

尊敬の念止まりにせず、自分も得た知見で少しでももやっとした点は積極的に掘下げていかねばなと反省しました・・・

なお、こちらのセッションの内容はダークモード対応時にフル活用させてもらうだろうなと想像してます。

すべての人のためのアクセシビリティ対応 @akatsuki174さん

fortee.jp

アクセシビリティ対応をすると発生する恩恵、対応するには具体的に何をすればよいのか、そして対応を進める上での具体的なアクションまで言及していたお話。

弊社のStudyplusのiOS版を文字サイズ変更してざっと確認してみたところ、textStyle設定済みで可変表示される箇所とそうでない箇所が入り混じっていました。

根本的に文字サイズが可変することを想定していないレイアウトもそこそこあり、それらも見直しながらだと気が遠くなり着手するのが恐ろしい・・・

ですが、今回得た知見をもとに気づいたところから少しずつチーム内にIssueを起票するところからやってみたいなと思います。

利用ユーザーが元気な若年層多めのアプリなのでどうしても優先度は上がらない気がするのですが、議論するタネがあるのとないのとじゃ大分違うはずなので。

全体的な感想

今年3月のtry! Swift Tokyoに続き、初参加した技術カンファレンスでした。 どこからこんなに湧いてきたんだろうという参加者数に圧倒されたり、協賛している企業さんがずらりと並ぶブースに圧倒されたり。

自分は真面目に参加しなかったんですが、iOSDCチャレンジという某隠れネズミキャラクターを探し歩く様子を彷彿とさせるイベントでめちゃめちゃ盛り上がってたりしましたね。圧倒されっぱなしでした。

前夜祭で職場から参加しに向かう際、 「技術カンファレンスはお祭りだよ。楽しんでおいで」 と先輩エンジニアのかたに声かけてもらったんですが、文字通りお祭りだったなぁと思います。

大石(id:k_oishi)

素晴らしいセッションばかりでしたが印象に残ったセッションの感想です。

ライブラリのインポートとリンクの仕組み完全解説

fortee.jp

ライブラリのリンクについては、iOSでCarthage使っている人ならかならず遭遇する謎のビルドエラーで馴染深い話題かと思います。 このセッションでは複数あるライブラリの形式が説明され、インポートとリンクがどのように行われるかという興味深い解説を聞くことが出来ました。 また、実用できそうで良いと思ったのが発表資料の最後のビルドエラーでの問題解決YES/NOチャートです。 ライブラリ導入時のエラーが発生した際に使用できる内容で大変参考になりました。

実機の管理とおさらば！AWS Device FarmでiOSのテストをしよう！

fortee.jp

以前、私が所属していた会社で過去にAndroidエンジニアを担当されていた白山さんのセッションでした。 まず、良いと思ったのがセッションの構成です。 前半がXCTestとXCUITestを使ったユニットテストの基礎を解説しつつ、後半がAWS Device Farmを使用した自動テストの実行方法の解説となっていました。 この構成によってユニットテストや自動テストにそこまで詳しくない方へのフォローをしつつ、うまくAWS Device Farmの話題に繋げていました。 AWS Device Farmの概要が理解できましたし、発表方法のテクニックとしても参考になったセッションでした。

セッション終了後に白山さんに質問した内容は以下のとおりです。

• 200USD/月で使い放題の使い放題のプランについて 250USD/月で1デバイススロット割り当てられ、1端末使ったテストが使い放題となる →複数同時実行したい場合は250USD * デバイススロット数のお金がかかる
• テストが実行されるまでの待ち時間 基本的に待ち時間はない、OSとデバイスの組み合わせが希少な端末は開始まで多少待つことがあるかも

個人開発のアプリが輝くために

fortee.jp

資料 https://speakerdeck.com/ahiru/for-personally-developed-apps-to-shine

LTにて個人開発向けで有益なノウハウが共有されました。 広告費がかけられない個人開発でダウンロード数を増やすためのASO対策を知ることが出来ました。 主なポイントは以下のとおりですが、それ以外にも貴重なノウハウがありましたので興味のあるかたは資料をご覧ください。

• タイトル・サブタイトルの両方にメインワードを入れる
• キーワードにひらがな、カタカナ、漢字を含めて検索ワードの表現揺れ対策
• 高評価してくれそうなユーザーにレビュー誘導を出す

私自身の個人開発のアプリにもすぐに取り入れられるものが多いと感じました。

TBD

fortee.jp

Podcastでお馴染みRebuild.fmにレギュラー出演されている@hakさんとiOSDC実行委員長@tomzohさんによるセッションです。 まず、セッションはiOSに全く関係ありません。 過去の家庭用ゲーム機を振り返って画面の表示形式や音声の出力形式、入力機器などの技術の進化を語り合うという内容でした。 最近、色々な言語で家庭用ゲーム機のエミュレーターを実装するのが流行っていたりしますので、スプライトの表示方法やスキャンラインの仕組みなど楽しく聞くことが出来ました。 ゲーム好きには丁度良いセッションでした。 すでに動画が公開されていますので、興味のある方はご覧ください。

お試しとして動画を1つアップしました。アンカンファレンス枠で企画として開催した @hak さん & @tomzoh の「TBD」を公開しました。 #iosdchttps://t.co/kaceLa79qq

— iOSDC (@iosdcjp) September 11, 2019

iOSDCチャレンジ

iOSDCの会場や公式サイト、スポンサー企業の事前ブログや企業ブースなどに隠されているトークン(#で始まる文字列)を自分のプロフィールページに入力するとスコアが加算され参加者が表彰されるというイベントがiOSDC開催中にありました。

このイベントの目的はスポンサー企業のブログを参加者に見てもらう、企業ブースをしっかり回ってもらうという意図があったと思うのですが、それなりに機能していたように感じました。 会場やWebサイトでリアルタイムのランキングが表示されており、上位の方々がすごいことになっていました。 私の成果も念のため共有いたします。

• 瞬間的にトップになった図

• 最終的な順位

面白い試みだと思いましたので次回も期待したいと思います。

全体的な感想

今回は自社がスポンサーしていることもあり、前夜祭から参加しやすく、最終日までフルで参加することが出来ました。 その結果、これまでのiOSDCよりカンファレンスを楽しめたと思います。 懇親会でもたくさんの方とお話する機会があり美味しい食事とビールを楽しむことが出来ました。 そろそろ私も登壇する努力をしたいと思います。

さいごに

登壇してくださったスピーカーのみなさま、運営スタッフのみなさまのご尽力があってこそ、不自由なく楽しい時間を過ごせたと思っています。どうもありがとうございました！

来年も無事開催されるようでしたら、是非とも参加したいと思います。

Google Developers ML Summit Tokyo : Human-Centered Machine Learningに参加しました

こんにちは、Androidエンジニアの若宮(id:D_R_1009)です。 先日、Google社で開催されたGoogle Developers ML Summit Tokyo : Human-Centered Machine Learningにインフラエンジニアの菅原(id:ksugahara08)と共に参加してきました。

events.withgoogle.com

今日は、それぞれの感想とスタディプラス内の機械学習への取り組み状況について、簡単にお伝えできればと思います。

Google Developers ML Summit Tokyo

Google I/O 19で発表されたPeople+AI Guidebookを解説し、補助してくれる会でした。 機械学習をプロダクトへ取り込む際に考えることや、導入のステップなどを聞くことができたように思います。

pair.withgoogle.com

有志の方による日本語訳 : 人にうれしいAIのためのUXデザインガイド（People + AI Guidebook）

すてきなピンバッチ

また9月17日にはワークショップも行われていたのですが、今回はML Sumit Tokyoのみの参加です もっと機械学習に取り組めるようになったら、デザイナーの方と一緒にワークショップに参加したいと思います。

developers-jp.googleblog.com

感想

以下、参加した2名の感想です。

若宮(id:D_R_1009)

機械学習熱が最近高まってきたので参加してきました。

個人的に面白いな！ と思ったのはMLとMaterial Designのセッションです。 Object DetectiveのLive Camera用に新しくMaterial Designのパーツが追加されただけにとどまらず、ユーザーが「自然」に感じられるように操作を作っていくかは、日々の開発で活用できそうだなと感じました。 またちょっと敷居が高く感じていたMaterial Themeのカスタマイズについて、少し理解が進んだようにも思います。

全体を通して「ヒト」と「AI」の関わり方をGoogleが模索していることについて考える、非常に面白いサミットだったように思います。 AIやDataの透明性を示すことは、開発者ではなく利用者としても考え続けるテーマだと思いました。 ML KitなどでAIをアプリに組み込むか、それともバックエンドのサービスが利用するのかはわかりませんが、常々考え続けていきたいなと思います。

菅原(id:ksugahara08)

弊社サービスでもMLの利用を見越して、参加してきました。 （前日のPyConJP2019スタッフで疲れて少し寝坊しました笑）

今回のテーマは「公平性」「透明性」だったと思います。 いかに、エンドユーザーに差別意識を持たれないような公平なサービスを作るべきかという倫理観にも近い話を聞けてとても貴重な知見を得られました。 もちろん万人に受け入れられるサービスは難しく、コストと精度のトレードオフという話もあります。また、十分なデータを持たないことで意図しないバイアスがかかってしまうこともあるかもしれません。

それでも諦めずフィードバックから改善していく大切さ、エンドユーザーに説明をする透明性の大切さを聞けて学ぶ喜びでした。 次回もできれば参加したいと思います！！

スタディプラスの機械学習取り組み状況

最後に、スタディプラスが今機械学習へどの程度取り組んでいるかを簡単にまとめたいと思います。

弊社の状況としては、機械学習の学習を有志(12名ほど)が始めたところになります。 会社のSlackにチャンネルを作成し、昼休みの時間を利用して週2~3回集まって自習の時間を作っています。

きっかけはML Study Jams Vol.3です。

events.withgoogle.com

業務や家庭の事情などがあるためなかなか時間の確保が難しいのですが、１コースを大半が修了できそうな状況になってきました。 このコースで学んだことをベースに、機械学習を業務にどう取り入れていくかを考えられればと思っています。

終わりに

二週間ほど前に「この日にサミット参加したいです！」と相談したところ、快く送り出してくれたチームの皆様に感謝！

builderscon 2019に行ってきた

今回は8/29~31に開催された builderscon tokyo 2019 へ行ってきた感想を書きます。

参加メンバーの写真

はじめに

buildersconへの参加は2年連続です。昨年の感想はこちらになります。

tech.studyplus.co.jp

またスタディプラスは昨年に続きbuildersconのスポンサーとして、ネームカードスポンサーとウォーターボトルスポンサーとして協賛をさせて頂きました。

感想

buildersconのセッションはバリエーションに富んでおり、どの発表も大変興味深いものでした。その中でも参加した4名がそれぞれ印象に残ったセッションの感想を書かせて頂きます。

島田

Open SKT: メルペイ開発の裏側

speakerdeck.com

4階層アーキテクチャによる基本的な構成の説明から、高い信頼性を求められる決済サービスでどういった観点を重要視して、そのためにどう仕組みを作っているが興味深かった。決済システムの一貫性を保つための一般化したエラーハンドリングの考え方と、共通モデルのTry,Confirm,Cancelによる状態確保するための仕組みは参考になった。 また、メルカリとメルペイでの開発の考え方の違い。サービスの特性による求める安定基準に違いから来るものが興味深かった。特に開発フローでのレビューの差異等が参考になった。

RDBのトラブルの現場を追え！

speakerdeck.com

DBのトラブルとして考えられるケースの説明。全体を通してMySQL、PostgreSQLのそれぞれの勘所・差異の説明は興味深かった。 スロークエリのあるあるの対応や原因の切り分けには納得。不正データ(制約で守られていない)に関してはPostgreSQLとMySQL8から出来ること(チェック制約)が参考になりました。 ユーザー情報のテーブル設計に関しては普段感じている課題感に対してひとつ知見も得る事が出来て、面白かった。 最後の「 DBは同じ話が30年前からある」は、知見が陳腐化する速度がそこまで速くなく、どこでも利用する技術なので強みとなりやすいというのは、なんか良かった。

大石

ランチセッション「キーボードは好きですか？」

speakerdeck.com

私自身趣味で活動している自作キーボードに関するセッションをおいしいランチを食べなから聞くことができました。 このセッションでは最近ブームとなっている自作キーボードに関する内容でしたが、発表者がCorne Keyboardの設計者でもあり、大変濃い内容を聞くことができました。 また、発表資料が現在の自作キーボード文化をまとめた資料性の高い内容となっていますので、自作キーボードに興味のある方はぜひご覧ください。 弊社でも自作キーボードのもくもく会を定期開催していますので、この資料が役立つことと思います。

個人的に参考になった点

• キーボードの種類(私は40%キーボード信者)
• メカニカルスイッチの解説(Lubeに関する解説も良い)
• メカニカルスイッチの構造、フランケンスイッチ(自分で作るのは大変なので触ってみたい)

コンパイラをつくってみよう

speakerdeck.com

「コンパイラをつくってみよう」というタイトルのとおり、発表者がライブコーディングでフルスクラッチのコンパイラを実装するという内容でした。 このコンパイラはGo言語で実装してアセンブリを出力するシンプルなものですが、ライブコーディングで少しずつソースコードの解析とコンパイラを実装する流れを見ることができました。 時々コンパイルエラーが発生するのですが、その際はギャラリーからエラー個所のアドバイスがあり、ギャラリー参加型のセッションという楽しい雰囲気となっていました。 この発表を聞いて自分でも簡単なコンパイラが作れそう、アセンブリ言語を扱うのも楽しそうという印象を受けました。

カンファレンス全体の感想

私がこれまで参加していた特定のプラットフォームの開発者のカンファレンスと異なり、ハードウェアやメーカー系の話題のあるカンファレンスで大変興味深く思いました。そして、まだまだ自分の知らない分野や勉強できることがあると感じましたので、機会があればまた参加したいと思います。 イベントの運営スタッフの方々、登壇者の方々、スポンサーの方々に感謝いたします。

田口

ブロックチェーン時代の認証

speakerdeck.com

ブロックチェーンについては正直ほとんど知らないことばかりだったのですが、興味本位で聞きに行きました。 自分のようにブロックチェーンについての知識が乏しい人にも詳しい説明がなされた発表で、大変助かりました。

現在のWebサービスは中央集権的であり、プライバシーやデータが提供される側で完全に管理されている状態で、ブロックチェーンの登場でそれが非中央集権的に、個と個のやり取りで管理されるようになってきているという話が印象的でした。現在のWebとブロックチェーンがお互いの課題感をお互いに解決できる未来を妄想するとわくわくしますね。発表者のrmanzokuさんもとても楽しそうに話していたのが印象的でした。

Web Componentsによる段階的AngularJS脱出作戦

docs.google.com

AngularJS、つまりAngularの1.x系のバージョンが2021年6月30日でEOLを迎えるので、今のうちから脱却に動いていこうという話でした。 弊社でもAngularJSで作られたプロダクトが動いているため、少しでも脱却するために得るものがあればと思い参加しました。

まず最初に、Web ComponentsがSafariでもサポートされていること、Polyfillまで見ればIE 11でもサポートされていることに驚きました。恥ずかしながら、もっと未来のことかと思ってました。 Web Componentsの仕様の一つであるCustom Elementsを使って、言葉通り段階的にAngularJSアプリケーションを書きかえていく話でした。 Angularでは公式でCustom Elementsをサポートしているパッケージ(@angular/elements)が出ており、アプリケーションの一部をCustom Elementsで書き換えるといったことが可能で、それを利用して少しずつAngularJSから脱却していくやり方を実際のデモを通して見れました。 このやり方は発表者であるlacolacoさん自身が考案し試行段階ということです。今後どうなっていくか気になるので、注視していこうと思います。

山下

現代フロントエンドに欠かせないwebpackとBabelを理解しよう！

speakerdeck.com

最近webpackerのバージョンアップをする機会があり、その際設定ファイル等の変更でbabelやwebpackのドキュメントを見ながら苦しんだため、是非聴きたいと思い聴いてきました。

前半はbabelやwebpackについて誕生の背景やコンセプトなどの説明、後半は内部実装を見ながら処理の流れのを追っていくという内容でした。 前半の説明がわかりやすく、個人的にはbabelがどのような流れでコードを変換し各処理にどのパッケージやプラグインが必要かを、変換されないパターンも交えながら解説してくれていて理解が深まりました。ただ、後半は内容が難しくまだまだ勉強が必要だと感じました。 また、今後babelやwebpackをどう学んでいけばよいかという質問に対して、公式ドキュメントを読みましょうという回答をされていました。babelやwebpackに限った話ではないですが、ついサボりがちなため公式ドキュメントを読み学んでいきたいと感じました。

ウォレットアプリ「Kyash」の先 〜「Kyash Direct」のアーキテクチャ〜

法人向けの決済プラットフォームKyash Directの開発についての内容でした。 既存Kyashのアーキがある中でスクラッチ開発を判断した経緯や、MicroservicesとMonolithどちらにするかをそれぞれメリット・デメリットを挙げどのように判断したかなど、開発を進める上で非常にためになる内容でした。 Microservicesでいくと決めた後も、サービスの分割方法、サービス同士の連携方法、DBの持ち方などについて、過去の経験や教訓、未来に起きるであろう課題の解決のしやすさを考慮しながら進めている点について見習わなければと感じました。 単に新しい技術を取り入れるだけでなく、自分たちのサービスや環境を考慮した設計をしていくことの重要性を感じた発表でした。

最後に

多種多様なセッションを聞く事ができ、buildersconのキャッチフレーズ「discover something new」とおり新たな知見を得ることが出来、大変有意義な時間となりました。 来年もまた参加とスポンサー等での協力が出来たらと考えています！

Rubyアプリケーションのメモリ使用量上昇問題をjemallocを使うことで解決しました

こんにちは、スタディプラスの栗山(id:shepherdMaster)です。
今回はRubyアプリケーションのメモリ使用量上昇問題をjemallocを使うことで解決した話です。

Rubyアプリケーションのメモリ使用量上昇問題

弊社ではRuby on Railsをメインで使っていますが、Rubyアプリケーションを長時間稼働させていると、次第にメモリ使用量が増えていく問題に悩まされていました。
これは、Rubyのメモリ領域の断片化によって引き起こされるそうです(参考)

puma worker killerによる定期的な再起動

この問題に対応するため、 puma_worker_killerという定期的にpumaのworkerをrestartさせるためのgemを使用し、メモリ使用量が上昇するのを抑えていました。
しかし、puma worker killerの実行のタイミングでたまにNo connection poolエラーが発生することがあり、調査や修正を試みていたのですが解決にはいたらない状態でした。

一筋の光、jemalloc

そこでpuma worker killer以外の解決方法を探すことになり、候補として上がったのがjemallocです。
jemallocを使うとメモリ領域の断片化を減らしてくれるということで実際に導入してみました。

EC2インスタンス上で運用しているサービスに関しては、Rubyビルド時にjemallocを有効化するオプション(RUBY_CONFIGURE_OPTS=--with-jemalloc)をつけてjemallocを有効化しました。

AWS Elastic Beanstalk¹上で動いているサービスに関しては、Rubyのビルドオプションを指定することが難しそうなので、LD_PRELOADを使った方法を取りました。
(LD_PRELOADを使った方法は手軽ですが、そのサーバーのすべてのアプリケーションに影響がでるので注意が必要です。幸い私達の場合、特に問題は出ませんでした。)

jemallocが有効になっているかの確認方法

Rubyビルド時にjemallocを有効にした場合

$ ruby -r rbconfig -e 'puts RbConfig::CONFIG["MAINLIBS"]'
-lz -lpthread -lrt -lrt -ljemalloc -ldl -lcrypt -lm

-ljemallocが表示されれば有効化されています。

LD_PRELOADを使った場合

Rubyアプリケーションのpid(pumaで動かしていればpumaのpid)を指定してメモリマップを確認し、jemallocへのパスが表示されれば有効化されています。

$ sudo strings /proc/10289/maps  | grep jemalloc
7f59e5ff8000-7f59e6028000 r-xp 00000000 103:03 12712                     /usr/lib64/libjemalloc.so.1
7f59e6028000-7f59e6227000 ---p 00030000 103:03 12712                     /usr/lib64/libjemalloc.so.1
7f59e6227000-7f59e6229000 rw-p 0002f000 103:03 12712                     /usr/lib64/libjemalloc.so.1

導入結果

メモリ使用量

12:00あたりまではpuma worker killerを15分起きに実行していたのでグラフが小刻みに上下しています。 その後12:00過ぎからpuma worker killerを2時間起きに実行するように変更しました。これによりメモリ上昇が起こっているのが分かります。
そして15:00あたりからjemallocを有効にした結果メモリ使用量が大きく下がりました。約3割減です 🎉 またその後メモリ使用量も上がることなく安定しています。
jemallocによりメモリ使用量の上昇を抑えられることが分かったのでpuma worker killerをその後取り除きました。取り除いた後もメモリ使用量は安定しています。

ありがとう、jemalloc 🙏

レスポンスタイム

Load AverageとCPU使用率に関しては変化がありませんでしたが、レスポンスタイムは気持ち速くなったようにみえます 😊

まとめ

jemallocを導入することでRubyアプリケーションのメモリ使用量が上昇しつづける問題を解消することができました。 これほど効果がでるならもっと早く導入しておけばよかったなと思ってます。
Rubyアプリケーションのメモリ使用量上昇にお困りでしたら、ぜひjemallocをお試し下さい。

---

1. 弊社は歴史的経緯からAWS Elastic Beanstalkを使っていますが、不便な点が目立つので脱 Elastic Beanstalkを計画中です↩

Kotlin Fest 2019に参加しました

こんにちは、Androidチームの若宮 (id:D_R_1009)です。

Kotlin Fest 2019(2019年8月24日)にAndroidチームの3名(若宮、中島、隅山)で参加してきました。

kotlin.connpass.com

昨年度に参加した時のブログはこちらです。昨年に引き続き 勉強会・カンファレンス参加補助 を利用し参加させていただきました。

tech.studyplus.co.jp

当日の様子

会場が品川駅港南口方面だったので、品川駅の某所で待ち合わせて会場に入りました。 Peatixを利用したチケットの確認も大変スムーズで、待ち時間なく会場入りすることができました。スタッフの皆様に感謝。

blog.jetbrains.com

JetBrainsさんのブログの通り、会はたろうさんの挨拶から始まりSvetlana Isakovaさんの「Kotlin Fest 2019基調講演」となりました。 朝一番にこんなに面白いものを聞いてしまっていいの!? と驚きつつ、Kotlin Festが始まったんだなーと感じていたのを覚えています。

たろうさん

twitter.com

Svetlana Isakovaさん

twitter.com

当日の思い出

以下、3名それぞれの当日参加感想となります。

若宮(id:D_R_1009)

昨年参加できず、今年は参加できることが決まった日から楽しみにしていました。

KotlinはGoogle I/O17でAndroidの正式採用言語になることが決まってから触り出しているので、おおよそ2年ほど触っていることになります。 最初は var と val の使い分けに混乱するほどでしたが、関数を引数とするなど徐々にKotlinに慣れ今ではなくてはならない言語となっています。

今回のKotlin FestではContractsが業務に生かせそうだな、と感じました。 アプリのモジュール化が進むにつれ、Utilクラスや拡張関数にContractsの利用するべきシーンが出てき始めたのかな、と感じています。 資料をもとに勉強し、活用していきたいと思います。

個人的な関心としては、Reactを使ったSPAの開発に取り組んでいるので、Kotlin MPPを利用したReactアプリ開発にチャレンジしてみたいなと。 Kotlin JSは発表や資料を読んでも、まだまだ開発途中っぽいなと感じました。ですが、今から開発に飛び込むとそれはそれで楽しそうだなとも！

全体的に「Kotlinを使うのは楽しいな」と感じる瞬間が多かったです。 懇親会も含めて、Kotlin Festは想像の数倍楽しかったです！ また来年も参加したい！

中島

結論から言いまして、とても実りの多い体験となりました。

オープニングセッションであるSvetlana Isakovaさんの基調講演から、Kotlinの開発体制や精神だけでなく今後の新機能についてまで盛りだくさんの情報量でした。 特に、幅広いユースケースで使われそうな Contracts および ImmutableCollections について興味をそそられました。

午後からのセッションも 佐藤 隼さんの「Kotlinの型実践入門」 や 富田健二さんの「改めて学ぶContract」 といった関連の強いものを聴講することで、より理解を深められたと感じられました。 特に Contracts は既に公式(1.3.50)拡張関数の内26メソッドに利用されているとのことで、自分でも積極的に使っていこうという気概が生まれました。

また「Kotlinの型実践入門」ではNothing/Nothing?型のユースケース、恥ずかしながら不勉強のまま放置していたジェネリクスなどについても色々勉強できたと思います。 セッションの最後にちらっと触れられていた、SAM変換問題に対する新しい型変換の開発についても、今後もKotlinの動向からは目を離せないと改めて思いました。

懇親会では普段あまりお話しできない、Android以外でKotlinを使っている方々との情報交換が色々とできてこれもとても有意義な時間だったと感じました。 Androidをやっていると静的型付けが基本ですし自分は他の経験言語でも同様だったので、型が明記されない言語からKotlinに変更した時の体験談などを聞けたのも楽しかったです。

最後に、聴講したセッション以外で特に気になったセッションが 八木俊広さんの「Kotlin コルーチンを 理解しよう 2019」 です。 資料を後から読みましたが非常に内容が濃く、自分があまり細かく理解しないで使っていたんだなと思い知らされました…。 Rxでいう通信処理のzipなど、単純な通信処理から少し外れたものをどう実装するのが本来正しいのか、しっかり把握できた気がします。

隅山

今回Kotlin Fest初参加でしたが、オープニングセッションでのSvetlana Isakovaさんの講演から始まり、全体的にKotlinの盛り上がりを感じることができました。既存のコードを壊さず、モダンに保つようアップデートとフィードバックを繰り返すことで言語をブラッシュアップしていることを知り、今後のKotlinにも非常に期待が持てました。 セッションは全体的に勉強になりましたが、特に勉強になったのが「コルーチン」と「Contract」でした。

コルーチンは業務で使っているのですが、何となくでしか理解できていないことをKotlin Festを通じて感じました。 例えば、スレッドよりコルーチンの方が軽量であることは知ってましたが、スレッドは1MB~2MBほどメモリを使うのに対してコルーチンは1KB程度のため、コルーチンを積極的に使うべきだと思いました。設計面では「コルーチンスコープとアプリケーションライフサイクルを合わせる」「suspend関数とコルーチンはメインセーフティを考慮する」と発表されていたため、今後はそこを気をつけながら開発していきます。

Contractは初見でしたが、isNullOrEmpty()でチェックした後からNonnullで扱えるようになるのはContractのおかげということがわかり、Contractの有り難さを感じました。 Kotlinでの開発中にいきなりNullableの値がNonnullで扱えるようになったりと、何気なく使えていて非常に便利である機能がContractでした。Contractは関数の振る舞いをコンパイラに適用することができるため、関数書く際はContractも考慮していきたいと思いました。

まとめとしては今回のKotlinFestを通して、自分の知識の抜け漏れを補たり、Kotlinへ熱意を感じることができたため非常にいい経験となりました。

終わりに

今年は1名がLT登壇申し込みに終わってしまいました。 来年こそは、弊社からも登壇していきたいなと感じています。

日本Kotlinユーザグループのみなさま、素敵なFestをありがとうございました！

スタディプラス第一回自作キーボードもくもく会

自作キーボードを社内で始めたきっかけ

先日、本ブログにてキーボードに関する記事「突撃！隣のキーボード Studyplus 2019」を書きましたが、その執筆の最中に社内のキーボード好きの熱が高まり、今回、有志で集まってのもくもく会の開催となりましたので、その様子をご報告します。

当日の様子

参加者は4名でしたが、それぞれキットやキーボード関連のパーツ、道具を持ち寄り自作キーボード作成や関連作業を行いました。
各メンバーが撮った写真とあわせてご紹介します。

みんなでワイワイ半田付け

アクリルプレートをレーザーカッターで切ってきた冨山氏

Let's Splitが映える！！

Lube(キースイッチの潤滑)体験コーナー

菅原さんが訳あってキースイッチのはんだを吸い取り中。全てのキースイッチを取り外す頃にははんだ吸い取りを完全に理解していたように見えました。※大石談

当日は社外から自作キーボード好きな方が参加！！！とても滑らかな打ち心地！！！
(Corne + NovelKeys Cream Switch + SPRiT Designs MX 35sのスプリングに交換)

参加者のコメント

• 大石(id:k_oishi) 前回作成したTreadstone32のスイッチの交換とPlanckを冨山さんに譲るためにキースイッチを外してパーツの状態に戻す作業をしました。
  前回、Treadstone32で難しいはんだ部分をがんばった図は以下のとおりです。USBコネクタ部分はさらに難しいですが、こちらもなんとか成功しました。

とりあえず完成したTreadstone32 スイッチはRosélios(67g)とSakurios(62g)の組み合わせ

キーキャップはEnjoypbt GrayScale keycaps set

各自、異なる作業をしていましたが、共通の話題でわいわいしたり、アドバイスをしたりされたりと、すごく盛り上がってよかったです。
積みキットやキーボードの引き取り先を探すにもちょうど良いイベントと思いました。
SPRiT Designsの交換用スプリングが大量にありますので、次回はスプリング交換もやってみたい所存です。

• 菅原(id:ksugahara08) Slackのチャンネルでは大石さんに色々な情報を教えて頂いて順調に沼に沈んでます！！
  　　ｽﾞﾌﾞﾌﾞﾌﾞ…うわっ、あっ、うわぁぁあっぁ…
  　　　　....::::;;;;( ;・ω・);;;;::::......
  今回は遊舎工房さんでWoody Zincを一目惚れで購入し、もくもく会に参加、いや企画！！
  無心になってはんだ付けしていると時間を忘れるくらい没頭してしまいました。
  まだ未完成なので次回には完成させたいと思います！！

• 冨山(id:atomiyama) 初自作キーボードのLet's Splitがついに完成．PCBの注文からケースのカットまで全部やってみてなんとか完成しました！！！！！（嬉しい）
  あと譲り受けたPlanckも組んで完成！！！！
  ただ完成した直ぐそばからケースを作り直したい欲に駆られています。

• 山﨑
  非エンジニアのド素人。
  どれくらいド素人かというと
  職種→しがない総務労務担当っす(・∀・)
  ダイオード→なんか懐かしいやつだ！…何だっけ？(・∀・)ﾀﾞｲｵｰ…ﾁｮ､ﾓｳｲｯｶｲ
  ハンダゴテ→中学生ぶりにみたー(・∀・)ｽｹﾞｰｽｹﾞｰ
  というレベル。
  約3カ月前にキーボードが手作りできることを知り、ZINCが可愛かったので取り敢えず沼に片足突っ込んでみることを前日に決意。
  この日は都合により13:30〜15:30までの作業。昨日の今日で開始だし、道具も部品も全く揃っていないので、今日できる作業を取り敢えずやるという感じ。
  やったこと→ケースの組み立て、プレートにダイオードをはめて固定
  教えてもらったブログに「マスキングテープで固定するとよいよー。」と書いてあったので、途中マスキングテープを買いに行ったが、可愛いマスキングテープがたくさんあり迷ったため時間を食う。
  本日の収穫

  • 大師匠・大石さんは道具を見ただけでamaz●nの限定品とわかるくらいのマニアっぷりである。
  • キースイッチのバネの強度を変えることも可能らしい。
  • 部品揃えないといけない。
  • なんか楽しい(・∀・)

最後に

参加者全員でもくもくしつつ、時にはキーボードに関する話をしながら作業していると、時間が経つのがあっという間でした。
普段の業務では一緒に仕事をしたことがないメンバーもいましたので、そういう意味でも良い機会になりました。
途中で遊舎工房へキースイッチなどの部品を購入しにいくメンバーもいましたが、御茶ノ水という比較的近い立地なのが素晴らしいですね。

今回、参加メンバーではなかった人からも興味を持ってもらえたようなので、参加者が増えると嬉しいです。
次回の自作キーボードもくもく会を開催予定ですので、その時はまたレポートしたいと思います。

スタディプラスを支えるインフラ技術

はじめに

スタディプラスには学習管理SNS「Studyplus」と教育機関向け学習管理サービス「Studyplus for School」の2つのサービスがあります。

今回は、社内では「本体」と呼ばれている「Studyplus」のAPIシステムである、コードネーム「steak」を中心にしたインフラ環境を紹介します。

構成

Studyplus本体は「steak」を中心とした複数のサブシステムで構成されており、関連するサブシステムをVPCで区切って管理しています。 「steak」を始めとした各サブシステムはRuby on Rails + Pumaで運用しています。

サーバー構成の概要図

利用中の主なAWSのサービスは以下になります。

• EC2
• RDS
  • Aurora
  • MySQL
• ElastiCache
• S3
• CloudSearch
• Athena

構成管理 

基本的にインフラ関連の設定はコード化するようにしています。 スタディプラスでは構成管理には主にPackerとAnsibleを利用しております。

Packer+AnsibleでAMIを作成してEC2のサーバーを構築する際に利用します。 AWSサービスの構成管理やEC2の環境構築にもAnsibleを利用しています。

また、サイロ化を防ぐため開発エンジニアが各自実行できるようにしています。

環境

環境を以下の3つに分けて運用しています。

• cage：開発者全員が共有する開発環境
• stag：本番DBに接続しており、主にリリース前にアプリケーションの最終チェックをする環境
• prod：本番環境

CI/CD

CIはCircleCIを利用しており、以下のような運用となっています。

1. エンジニアがPull Requestの作成
2. CircleCIにテスト
3. レビューを経て、エンジニアがmasterブランチにマージ

デプロイに関してはSlackからHubotを経由してJenkinsでデプロイをしています。

1. SalckでHubotにコマンドと変数を受け渡す
2. JenkinsのJobを実行して対象にデプロイを行う

開発エンジニアの要望もあり、テスト、build、deployのパイプラインはこのような形になっています。

blue/greenデプロイ形式に則っており、リリース規模や影響度を見てカナリアリリースを行うこともあります。

デプロイイメージ図

監視・検知

• サーバーのメトリクス監視にはMackerelを利用しています
• アプリケーションのエラー検知にはSentryを利用しています
• ログ収集にはAmazon Elasticsearch Serviceを使っておりkibanaで確認できるようになっています
• OnCallはMackerelにTwilioを設定して、担当者に連絡が飛ぶようになっています

改善・挑戦

以下は、今年取り組んだ改善と今後1年以内に取り組んでいきたいと考えているインフラ関連の活動内容です。

• 今年取り組んだ改善活動
  • RDS監視強化(パフォーマンスインサイトによるボトルネックの可視化)
  • CircleCIのPerformance Planを導入
  • 複数システムのRubyとRailsのバージョンを最新バージョンへ更新
  • jemallocの導入(Railsアプリケーションのメモリ上昇を抑えるため)
• これから取り組みたい事
  • Cloud Native化
    • EKS等のコンテナ導入
    • サーバーレス化
  • SREチームとしての活動推進
    • 監視・ログ基盤の整備
    • ポストモーテムの整備
    • SLI/SLOの設定

現状では、まだ手作業や自動化する余地があり、安定したサービスを提供するために出来ることはあります。 その中で運用負荷を軽減する事を考えたり、モダンな思想・ツールを取り入れたりしています。