Jetpack Navigationを使った画面遷移でFragmentとステータスバーのThemeを制御する話し

弥生モバイルチームのtijinsです。

MisoaアプリNavigationコンポーネントを導入してActivityとFragmentが複雑に絡み合った状況を改善しようと思ったのですが、アプリのデザインがActivity毎のThemeで定義されていて、単純にNavigationを入れると見た目が変わってしまう問題に行き当たりました。 ThemeをFragment毎にすれば同じ見た目を実現できるはずなのですが、ThemeもStyleも全くワカランって感じで1ヶ月近く悩んでいたので、1ヶ月悩んだ結果を紹介します。

この記事の概要

このブログでは、以下の内容を説明していきます。

  • FragmentにThemeを適用する方法
  • ステータスバーの色をFragmentのThemeで制御する方法
  • ステータスバーの文字・アイコン色をFragmentのThemeで制御する方法

f:id:tijins:20211206142128g:plain

ThemeとStyle

背景色や文字サイズなど、アプリの見た目を一括して設定できる機能です。
デフォルトのプロジェクト構成ではres/theme.xmlに保存されています。
theme.xmlで定義したThemeをAndroidManifest.xml<application theme="{theme}"><activity theme="{theme}">に指定する事で、アプリ全体やActivity毎の見た目を設定可能です。
ただし、Fragment毎に指定する機能は提供されていませんでした。

Themeの指定

themeはAndroidManifest.xmlで指定しました。
<application>に指定するとアプリ全体の背景色や文字サイズに適用されます。
<activity>に指定するとActivityの背景色や文字サイズに適用されます。
Android5.0以上ではレイアウトXMLのViewGroupにも指定可能です。
<LinearLayout theme="{theme}"><ConstraintLayout theme="{theme}">のように指定するとViewGroup内が適用範囲になります。

Styleの指定

StyleはThemeの適用範囲を1つのViewに限定したものです。
定義はThemeと同じでtheme.xml<style>で行います。
レイアウトXMLで<TextView style="{style}">のように指定しします。
ViewGroupに適用しても、Themeと異なり内側の要素に継承されません。

FragmentにThemeを適用する

FragmentのThemeをxmlで指定する機能は提供されていない為コードから指定します。
Theme(Style)をコンストラクタで指定可能なThemedFragmentを作成しました。
onCreateView()でLayoutInflaterを差し替えています。

// テーマの指定が可能なFragment
abstract class ThemedFragment(@LayoutRes val layoutRes: Int, @StyleRes val styleRes: Int) : Fragment(layoutRes) {

    override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? {
        // Themeを適用したContextを作る
        val themedContext = ContextThemeWrapper(context, styleRes)
        // Themeを適用したLayoutInflaterを作る
        val themedInflater = inflater.cloneInContext(themedContext)
        // レイアウトの生成に使用するinflaterを差し替える
        return super.onCreateView(themedInflater, container, savedInstanceState)
    }
}

// Fragment毎のレイアウトとThemeを指定する
class SampleFragment : ThemedFragment(R.layout.fragment_first, R.style.Theme_StyleSample_Red)
{
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        super.onViewCreated(view, savedInstanceState)
        //  Fragment固有の処理
    }
}

※サンプルコードはandroidxのFragmentを継承しています。

ステータスバーの色をFragmentのThemeで指定する

FragmentにThemeを適用する事例はすぐに見つかったのですが、ステータスバーの色が変わらない事に気づきました。
LayoutInspectorで調べると、Fragmentの描画範囲にステータスバーが含まれていませんでした。

f:id:tijins:20211206112233p:plain
fitSystemWindow="false"の時

試行錯誤の結果、以下でステータスバーの色を変更できる事がわかりました。
システムが描画するステータスバーの色を透明にする事で、ディスプレイ全体に広がったFragmentの背景色が、ステータスバーの色として表示されるという仕組みです。

  1. Fragmentの描画範囲をディスプレイ全体まで広げる
  2. ActivityのThemeで、ステータスバーの色(android:statusBarColor)を、透明(@android:color/transparent)にする
  3. FragmentのThemeで、背景色(colorPrimaryDark)を、表示したいステータスバーの色にする
    f:id:tijins:20211206134733p:plain
    ステータスバーの背景色を設定する

※サンプルは、下記の組み合わせで確認しています。

ライブラリ パッケージ バージョン
AndroidX androidx.core:core-ktx 1.7.0
マテリアルデザイン com.google.android.material:material 1.4.0

Fragmentの描画範囲をディスプレイ全体に広げる

Activityのルート要素をFragmentContainerViewにします

Activityのレイアウト

activity_main.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.fragment.app.FragmentContainerView
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:id="@+id/nav_host"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:name="androidx.navigation.fragment.NavHostFragment"
    app:defaultNavHost="true"
    tools:context=".MainActivity"
    app:navGraph="@navigation/nav_graph"/>

Fragmentのレイアウト

Fragmentのルート要素をDrawerLayoutにしてfitSystemWindow="true"を指定します。
(ルート要素がConstraintLayoutやLinearLayoutだとステータスバーの背景色が変わりません)

fragment_first.xml

<?xml version="1.0" encoding="utf-8"?>
<androidx.drawerlayout.widget.DrawerLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".FirstFragment"
    android:fitsSystemWindows="true">

</androidx.drawerlayout.widget.DrawerLayout>

f:id:tijins:20211206112231p:plain
fisSystemWindow="true"の時

Activityのテーマで、ステータスバーの色を透明にする

theme.xml
android:statusBarColor@android:color/transparentを指定します

    <style name="Theme.StyleSample" parent="Theme.MaterialComponents.Light.NoActionBar">
        <item name="android:statusBarColor">@android:color/transparent</item>
    </style>

Fragmentのテーマでステータスバーの背景色を指定する

colorPrimaryDarkでステータスバーの背景色を指定します

    <style name="Theme.StyleSample.Red">
        <!-- ActionBarの色-->
        <item name="colorPrimary">@color/red</item>
        <!-- ステータスバーの色  -->
        <item name="colorPrimaryDark">@color/red_status_bar</item>
    </style>

ステータスバーの文字を黒色にする

ステータスバーの背景色は変更できたのですが、今度はandroid:windowLightStatusBar="true"が反映されない事に気づきました。
android:windowLightStatusBar="true"はステータスバーの背景色が明るい色のときに使用するもので、ステータスバー上の文字やアイコンが黒色になります。

こちらもxmlでは指定できない為、Fragmentが遷移した際のイベントで、コードから動的に変更する事にしました。

Style値の取得

xmlで指定された値(true/false)をコードから取得するUtilityを作成しました。

object StyleUtil {
    fun getWindowLightStatusBar(context: Context, @StyleRes styleRes: Int?): Boolean {
        val themedContext = if (styleRes != null) {
            ContextThemeWrapper(context, styleRes)
        } else {
            context
        }
        val typedArray = themedContext.theme.obtainStyledAttributes(
                intArrayOf(android.R.attr.windowLightStatusBar)
        )
        val isLight = typedArray.getBoolean(0, false)
        typedArray.recycle()
        return isLight
    }

context.theme.obtainStyledAttributes()を使用すると、themeに指定されているstyleの値を取得可能です。

windowLightStatusBarの動的な変更

childFragmentManager.addOnBackStackChangedListener{}のイベントでFragmentに指定されたstyleを取得して、ステータスバー文字色を変更します。
findNavController().addOnDestinationChangedListener{}のイベントを使用したくなるところですが、DestinationChangedイベントが発生した時点では、まだ遷移先のFragmentが生成されていない為、スタイルを取得できません。

class MainActivity : AppCompatActivity(R.layout.activity_main) {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val navHost = supportFragmentManager.findFragmentById(R.id.nav_host)!!
        navHost.childFragmentManager.addOnBackStackChangedListener {
            val currentFragment = navHost.childFragmentManager.fragments.firstOrNull()
            val isLight = StyleUtil.getWindowLightStatusBar(
                    this,
                    (currentFragment as? ThemedFragment)?.styleRes
            )
            setLightStatusBar(isLight)
        }
    }

    private fun setLightStatusBar(isLight: Boolean) {
        if (isLight) {
            window.decorView.systemUiVisibility =
                    window.decorView.systemUiVisibility or View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR
        } else {
            window.decorView.systemUiVisibility =
                    window.decorView.systemUiVisibility and View.SYSTEM_UI_FLAG_LIGHT_STATUS_BAR.inv()
        }
    }
}

サンプルコード

https://github.com/tijins/ThemedFragment

まとめ

この記事は弥生アドベントカレンダー2021の13日目です。
ActivityとFragmentが複雑に絡み合ったアプリをリファクタリングにしてスッキリした新年を迎えたいですね。

お知らせ

弥生のモバイルチームでは、Android、iOSのエンジニアを募集中です!! herp.careers herp.careers

技術勉強会の企画を立てよう!(初心者編)

この記事は弥生 Advent Calendar 2021の9日目エントリーです。

<登場人物>
 もくにゃん木曜日にテクノロジーを語ろうとすると現れるねこ
 あいざわ:リモートワーク中によくPCの接続が切れるエンジニア


<2021/10/14(木)>

 あ~もくテクが今月(10月)も無事に終わった~
 もくテク?
 毎月木曜日に開催している弥生主催の技術イベントだよ~

mokuteku.connpass.com

 隙宣伝にゃん
 それはさておき…

 再来月(12月)のもくテクの企画が決まらない!

 来月(11月)は決まってるのかにゃん?
 11月は大丈夫!いつも大体こんなサイクルで企画運営しているのです

 にゃるほど
 だから12月の企画を検討してるんだけど、オンラインで再開から早半年、ネタ切れしました
 もうちょっと頑張るにゃん
 毎月開催 意外大変也
 今まではどんな風に決めてたにゃん
 運営メンバーで集まって決めてたんだけど…毎月ともなるとマンネリ化してきて…

 仕方ない…もくにゃんが企画のコツを伝授するにゃん
 やった~!

 ネタがないって言っても、社内の話は日々色々聞いてるにゃんね?
 色んなチームが日々施策を打ちながら開発して、それを社員総会や全体会で共有してるからね
 それをストックして企画にすればいいにゃん

例:

 たしかに
 日々の積み重ねが大事にゃん
 でも今は何も残してないからストックがない…
 そういう時は社内で面白いネタを持っていそうな方に頼ったり、社内で募集するにゃん

例:

※CTL=Chief Technical Lead
参考記事:10年先の未来に向けて──弥生の開発プロジェクトを成功に導く“CTL”の役割|弥生株式会社

 た、頼れる~~!!
 あとは頑張るにゃん
 はい!

.
.
.
<1週間後>

 もくにゃん~!12月の企画が決まったよ~!
 よかったにゃん
 よ~しこの調子で先の企画もガンガン決めてくぞ~!
にゃ~ん


宣伝

① 弥生はもくテク運営の他にも自主的に参加できる社内活動があり、どこも活発に活動しています。
社内活動が好きな人は覗いてみてください!
herp.careers

② 記事の中でもくにゃんとあいざわが企画したイベントは、12/16(木)に開催します。
初学者~ベテランまで幅広い登壇者がAWSの話をします。
興味がある方は参加してみてください!
mokuteku.connpass.com

AWS Route53の加重ルーティング機能で本番インフラを無停止・段階的にECS環境に移行する

弥生 Advent Calendar 2021 6日目の記事です。

システム開発部Misocaチームエンジニアの mizukmb です。

クラウド請求書作成ソフトであるMisocaのインフラはサービス稼動開始からつい最近までAWS EC2を使ってアプリケーションを運用していましたが、この度Dockerコンテナ管理サービスであるECSに移行し、この移行作業がほぼ完了致しました 🎉

ECS移行に際しては長い時間をかけて準備や検証を行っており、開発者ブログで紹介したいネタがいくつかあるのですが、今回は実際にEC2で稼動するappサーバを無停止且つ段階的にECSに移行した方法について紹介したいと思います。

ECS移行前の状態と作業の概要

移行前のMisocaアプリケーションのインフラは複数台のEC2インスタンス上で稼動しており、各EC2インスタンスへのリクエスト振り分けはALBを使って制御していました。ドメインとALBの紐付けはRoute53のエイリアスレコードを利用しています。

移行後はEC2インスタンスが複数のECSタスクに、ALBもEC2用からECS用の新規ALBリソースに置き換わります。この移行作業の準備としてMisocaアプリケーションのコンテナ化やECSサービス・タスク定義の作成、ECS用のALBの用意を事前に行いました。

移行作業は以下の点を重視し、これらが実現できる方法について調べました。

  • サービスの停止時間を作らずに移行作業ができる
  • 一気にECS環境に切り替えるのではなく、カナリアリリースのように段階的にECS環境を本番に投入して負荷状況等を監視したい
  • 段階的に投入する事でECSもしっかり本番環境でサービスが提供できているという安心感を得たい 1
  • 万が一ECS起因の障害が発生したとしても影響を最小限にしつつ素早くロールバックできるようにしたい

こちらについてAWS Japan ソリューションアーキテクトの方に技術相談をしたところ、Route53の加重ルーティング (Weighted routing) 機能について教えていただきました。 2

Route53加重ルーティング機能について

正確な機能紹介についてはAWSドキュメントを読む事が最も良いので、ここではざっくりとした紹介をします。

Route53の加重ルーティング機能は、同一レコード名で登録し、重み (Weight) を各レコードで設定する事でその重みに応じた割合でリクエストを振り分けることができます。振り分け方法はラウンドロビン方式です。また、片方の重みを0にする事で設定したレコードへリクエストが振り分けられなくなり、もう片方のレコードに全てのリクエストが振り分けられるようになります。

例えば、 hoge.example.com への振り分けを EC2:ECS=30:70 としたい場合は以下のように重みを設定しそれぞれレコード登録します。

レコード名 ルーティングポリシー 重み ルーティング先
hoge.example.com 加重 30 EC2用のALBドメイン
hoge.example.com 加重 70 ECS用のALBドメイン

この重みを変更する事でリクエストの振り分ける割合を柔軟に設定が可能になります。

f:id:mizukmb:20211118152712p:plain

無停止・段階的に移行するための作戦

行う事はシンプルで、加重ルーティングで設定する各レコードの重みを編集して少しずつ EC2:ECS=100:0 な状態から EC2:ECS=0:100 にすれば作業は完了します。

MisocaチームではインフラをTerraformで管理しているので、Route53レコードの設定や重みの変更はTerraformコードを修正し、プルリクエストの作成とコードレビューを経て terraform apply を実行し適用するという流れでした。

重みの変更によるアプリケーションの停止時間は発生しないので、この値が間違っていないか十分注意していれば簡単に無停止・段階的な移行が可能になります。

実際の移行作業ですが、最初は EC2:ECS=95:5 の割合から始めて、1〜2日様子を見てECS側の重みを増やして EC2:ECS=70:30 にする。さらに様子を見てECS側の重みを増やして…といった作業を繰り返していき、約1週間程かけて EC2:ECS=0:100 な状態に移行し、サービスの稼動に影響が無い事を確認できました。

おわりに

MisocaのアプリケーションインフラのEC2からECSへの移行にRoute53の加重ルーティング機能を活用した話を書きました。

ECS移行に関する知見についてはまだまだあるので、できる限り開発者ブログで紹介したいと考えています。

弥生 Advent Calendar 2021 では弥生のエンジニアが様々な内容で記事を公開しますのでぜひ他の記事もチェックしてみてください!

採用

積極採用活動中です!!

herp.careers

付録:最初に考えてた作戦内容と却下理由

ALBのリスナールールではリクエストを転送するターゲットグループの重み付けができるため、最初はALBのレイヤで無停止・段階的な移行を進めるつもりでいました。

しかしながら、ECS環境のデプロイはCodeDeployのBlue/Greenデプロイメント機能を使っている関係からこの案は技術的に不可能である事がわかりました。理由ですが、CodeDeploy Blue/Greenデプロイメント機能を実行するとCodeDeploy内部でリスナールールに紐付くターゲットグループをBlueからGreenに付け替えるといった事を行っており、実質リスナールールの転送先はECSに固定されてしまうためです。

CodeDeploy Blue/Greenデプロイメント機能を使わなければこの案で進められますが、これのためにBlue/Greenデプロイを止めるのは割に合わないと判断したため却下となりました。


  1. もちろんステージング環境で検証していますが、やはり本番となると怖いものは怖いので安心感が欲しいのです

  2. 弥生ではAWS Japan ソリューションアーキテクトの方と定例会を行っており、AWSに関する技術相談がカジュアルにできる場が設けられています

システム横断プロジェクトの品質計画

こんにちは、カトです。弥生でQAエンジニアをしています。この記事は弥生 Advent Calendar 2021の5日目エントリーです。

結論

弥生は、昨年2020年に記帳代行支援サービスを開始しました。
記帳代行支援サービスは、複数のシステム・複数のソフトウェアで構成されるサービスです。
弥生ではシステム横断プロジェクトと呼ぶことが多い、シームレスなサービスの裏側のおはなしです。

私は、QAエンジニアとして、記帳代行支援サービスに関わりました。 「かんたん、あんしん、たよれる。」の裏側では、複数のシステム・複数のソフトウェアから成り立つサービスの品質をどのように見ていくのか、何をやって何をやらないのかを決める必要がありました。

そこで、各テストフェーズでどのようなテストをすべきかをまとめました。それがこちらです。 f:id:yayoikato:20211111155539p:plain 改めてまとめたものをみると、難しいことは何も言っていないように思えます。
しかし、これを作成するまでに、いろんなことがありました。

f:id:yayoikato:20211129220845p:plainf:id:yayoikato:20211129220910p:plainf:id:yayoikato:20211129221331p:plain:w120
本当に、いろんなことがありました……?

背景

U字プロセス

弥生の製品開発の多くは、開発プロセスとしてU字プロセスを取り入れています。
(参考:エンジニア採用|採用情報|弥生株式会社f:id:yayoikato:20211129090958p:plain
このU字プロセスは、弥生入社時に導入研修で学びます。日々の業務でもプロセスに準拠しているかどうかを判断基準としています。
弥生のエンジニアには浸透しているプロセスです。

f:id:yayoikato:20211129222805p:plain:w200
「いつもの感じでよろしく」で、だいたい伝わる

システム横断プロジェクトで発生したこと

記帳代行支援サービスにおいても、「いつもの感じでよろしく」で済むものだと思っていました。
ところが、「そっちのシステムでテストしてると思ったからこっちでは見てないよ」「そっちでもやってるの?こっちのシステムでテスト終わってるよ」などなど、いろいろなトラブルが発生します。

特に、問題になったのが2点。

  • システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまう
    結合テストでは、単一のサービスを対象にしたを実施するため、連結するサービスはダミーシステムを使ってテストしています。 このため、個別のシステムとしては動作していても、いざ連結してみると想定していた挙動にならないことが発生し、テストを中断せざるを得ないことがありました。

  • 準備や設定が複雑なシステムを除外して、システムテストを実施してしまう
    システムテストは最終テストフェーズであり、リリース間近におこなうため、期日に追われています。 設定が複雑だったり、準備工数がかかったりする手順は、前フェーズでテストしているはずだから大丈夫だと思って省略させてしまいがちでした。 省略に根拠がないので、システムテストが貧弱になっていきました。

これらの問題を解決しなければいけません。

奮闘

文章にしてみた

どのフェーズのテストで何をしなければいけないのか、品質計画として文章化していきました。

f:id:yayoikato:20211129225201p:plain:w300f:id:yayoikato:20211129225209p:plain:w300
一生懸命つくった品質計画書のイメージ

確認が必要なときには、集まってミーティングをしました。
フェーズごとに実施するテスト内容を品質計画で明示する前と明示した後で比較すると、各段に認識齟齬がなくなりました。
しかし、品質計画として書いてあるから全員が熟読している、というわけではありません。途中参加で読めていない人もいるし、読んだけれど忘れてしまったという人もいます。
そのつど確認をしていましたが、もう少しよりどころになるようなものが必要だと思うようになりました。

図にしてみた

「よりどころになり、これを見れば責任者に細かく確認をとらなくても安心して確認できるようなものがほしい」と思ってつくったのが冒頭の図です。
もう一度貼っておきます。
f:id:yayoikato:20211111155539p:plain この図をつくって共有したところ、記帳代行支援サービスに関係するメンバーそれぞれがこの図を見ながら会話ができるようになりました。

問題になっていた2点に対しては、このような変化がありました。

  • システム間のインターフェース誤りにより、統合テスト開始直後にテストが中断してしまっていた
    Aさん:「統合テストの前に連携テストする必要がある。いつ頃テストできそう?」
    Bさん:「〇月×日にテストアップ可能になる予定。」
    Aさん:「両システムがテストアップして、連携テスト後に、統合テスト開始ですね。」
    ⇒システム間のインターフェースに着目した連携テストを実施することで、統合テスト開始直後の中断がなくなりました。

  • 準備や設定が複雑なシステムを除外して、システムテストを実施してしまっていた
    Aさん:「心配だから統合テストで2つ先のシステムまで確認しておく?」
    Bさん:「対象のシステムと直接連携していないシステムは、統合テストの確認対象じゃないよ。」
    Cさん:「システムテストで確実に実施するよう申し伝えておこう。」
    ⇒システムテスト内容が明確になり、最終フェーズとして有効なテストができるようになりました。

結果

「記帳代行支援サービスのテスト、どう考えればよいの?」というときに、よりどころになる図ができました。
そして、この品質計画の図は、記帳代行支援サービス以外でも複数のシステム・複数のソフトウェアから成り立つサービスでのテストを考えるときに使える内容になっています。

私は、2019年から記帳代行支援サービスに関わり、2020年にサービスの開始、2021年には記帳代行支援サービスのバージョンアップに立ち会いました。
まだまだ記帳代行支援サービスは進化していきます。しかし、私がQAエンジニアとして記帳代行支援サービスに関わるのはここまで。

私は、QAエンジニアとして別のサービスに参画し始めました。記帳代行支援サービスでつくった品質計画の図をさらに進化させ、今以上に弥生の資産となる品質計画をつくっていきます。



お知らせ

弥生では「弥生会計」に限らず、さまざまな製品・サービスに関わることができます。
一緒に、弥生の製品・サービスの品質を追求してみませんか?

herp.careers

テクニカルリーダーになってシステムの解像度が上がった話

この記事は弥生 Advent Calendar 2021の2日目の記事です

自己紹介

弥生の白井と申します。SMARTの推論という機械学習機能のテクニカルリーダーを担当しています。

家では1歳の息子を溺愛しています!!

テクニカルリーダーについて

入社してから今までエンジニアとして働いていたのですが、今年10月から初めてテクニカルリーダーをやることになりました。

弥生のテクニカルリーダーの役割には、開発計画の立案と実行、プログラム品質の管理(レビュー)、エンジニアのチーミング、適用技術の決定などがあります。

役割に伴う責任が大きくなる分、必要な権限も与えられます。今回はその与えられた権限によって見える世界が広がったという話です

f:id:yayoi_shirai:20211115140340p:plain
広がる・・・世界が・・・

与えられた権限について

前提として、SMARTはAzureのApp ServiceというWebアプリ用のPaaSで動いています。App ServiceはOSをLinuxに指定することもでき、推論エンジンはLinuxのApp Serviceで動いています。

(ちなみに弥生の他のサービスではAWSを使用しているものもあります)

AzureはAzureポータルという管理画面(AWSだとAWSマネジメントコンソール)があるのですが、開発環境であっても一般のエンジニアにはAzureポータルへのアクセス権がありませんでした(ここはチームによって運用は異なるかもしれません)

テクニカルリーダーになることでAzureポータルへのアクセス権が与えられ、他にも監視系サービスのアクセス権など様々な権限が与えられます。

テクニカルリーダーの権限で見えた世界

テクニカルリーダーの権限でシステムの裏側を見ることで、システムのアーキテクチャをより深く理解できるようになりました。

例えばアプリケーションログを確認することによって、Webアプリがデプロイ後にどのように動いているかを知ることができました。

デプロイ直後のアプリケーションログを確認すると、LinuxのApp Serviceでは裏側でLinuxのDockerコンテナを作成し、そこにデプロイされたWebアプリをのせて動かしていることがわかりました。

他にもLogic Appsで定期実行スケジューラを組んで運用していたり、アプリケーションログをログ可視化用のElasticsearchに転送するために、一時的にBlobストレージに保存している処理などを目で見て確認することができました。

システムへの解像度が上がることでレベルが上がった気がする

システムのアーキテクチャの理解が深まったことで、システムへの解像度が一段と上がったような気もします。

例えば本番環境で謎の事象が発生した時でも、どこを調べればいいのかある程度検討がつくようになり、調査の目処が立てやすくなりました。 以前は闇雲にありとあらゆるログを確認してエラーが出ていないか調査していましたが、全体像を理解して調査ポイントを絞り込むことで、不必要な調査に時間をかけてしまうことが減りました。

他にも少し難しい事象を再現したり新しい機能を試すときに、モックを作ってささっと検証する、といったことがスムーズにできるようになりしました。

作業がうまくいったとき、自分のエンジニアとしてのレベルが上がった気がする!なんて思ったりしました。

f:id:yayoi_shirai:20211115140534p:plain
レベルアップ!!!

エンジニアがシステムのアーキテクチャを理解できるようになるために

私は権限を手に入れたことでシステムのアーキテクチャをより理解できましたが、本来これはエンジニアだった時に理解したかったな~とも思いました。

よくよく設計書を見ると書いてあることだったりするのですが、目で見て確認できるかできないかは理解度に大きく影響すると感じました。セキュリティの都合上全てのエンジニアがAzureポータルを見れるようにすることは難しいのですが、なんとかならないものかと悩んでいます。

今後は他のエンジニアにもうまく伝えられる方法がないか考えていきたいと思います!

宣伝!!来年2月に推論チームでもくテクやります!!

mokuteku.connpass.com

弥生は月に1度、木曜日に技術イベント「もくテク」を開催しています (現在はリモートイベントで開催しています)

イベントページはまだ出来ていませんが、来年2月に推論(機械学習)がテーマの会を企画しています!

機械学習のサービス運用に興味のある方、弥生の研究開発に興味のある方など、誰でも大歓迎です!ぜひお気軽にお越しください!!!

弥生では一緒に働く仲間を募集しています。

herp.careers

QuickSightでかんたんに視覚化

この記事は 弥生 Advent Calendar 2021 の1日目の記事です。

よくできてる

こんにちは、3年間育てていた観葉植物のうち、ひとつがフェイクだと分かったgarusanです。
質感が違うなぁって思っていたら、素材も違っていたんですよね。でもよくできてます。

そんなショックを悟られないようにデータ分析について考えていたところ、 エクセルで行っていた集計をQuickSightに置き換えてみたら、結構かんたんにできることが分かりました。 本日はそんなQuickSightについて紹介します。こちらもよくできてます。

QuickSightって?

AWSが提供しているBIサービスです。 S3に配置したデータ、AthenaやRDSで抽出したデータを読み込んで、かんたんに視覚化できます。

視覚化してみよう

今回は、とあるcsvファイルのデータをQuickSightで視覚化してみます。

使用するデータ

日付型や数値が含まれるデータを用意しました。
へッダーあり、カンマ区切りのデータでUTF-8でエンコードしています。

植物 日付 葉っぱの枚数 お世話 観察結果
植物A 2018/03/31 10 購入 ふわふわしてる
植物B 2018/03/31 10 購入 ふわふわしてる
植物C 2018/03/31 10 購入 ふわふわしてる
植物D 2018/03/31 10 購入 ふわふわしてる
植物E 2018/03/31 10 購入 ふわふわしてる
植物F 2018/03/31 10 購入 つるつるしてる
... ... ... ... ...

データセット作成

データはS3に配置することが多いのですが、今回はcsvファイルをそのままアップロードしてみます。
一般的な形式の日付データは、フォーマットの指定不要で自動変換して読み込みます。よくできてます。

f:id:garusan:20211129145426j:plain
アップロードデータ

データ加工

もし、自動変換できなかった場合は文字列型として読み込まれます。

f:id:garusan:20211129190728j:plain
自動変換できない日付データ
そんなデータも西暦の日付形式であれば、フォーマットを指定することで変換できます。わざわざラムダを作成してデータ変換しなくても変換できることは大きなメリットです。
f:id:garusan:20211129191916j:plain
フォーマットを設定
f:id:garusan:20211129192103j:plain
変換完了
ちなみに和暦や和風月名は対応していません。弥生晦日→03/31の変換はさすがにダメでしたね。
f:id:garusan:20211129192747j:plain
対応は西暦のみです

視覚化

最後に視覚化です。今回は折れ線グラフを選択し、X軸、値、色に各項目をドラッグ&ドロップします。

f:id:garusan:20211129201228j:plain
折れ線グラフを選択し、X軸を日付に設定
データセットとグラフの関連付けが終わりました。ここまでくればほぼ完成です。
f:id:garusan:20211129201651j:plain
設定完了
後は細かい体裁を整えます。デフォルトで設定されるグラフタイトルがちょっとアレなのでそれらしく変更し、日付の表示形式も変更します。
f:id:garusan:20211129210517j:plain
タイトルと日付の表示形式を変更

よくできてる

ビジネスデータを分析する場合、各サービスから取得するデータは日付フォーマットやエンコードも様々です。クセの強いデータは加工処理が必要になりますが、よくある日付フォーマット指定や数値の集計程度の加工であれば、ラムダやETLツールによる変換処理を作成せずにQuickSightだけでかんたんに視覚化が可能です。よくできてます。

弥生では一緒に働く仲間を募集しています。

herp.careers

もくテク「2021年秋のLT大会」を開催しました!

こんにちは、カトです。

11月の第3木曜日といえば、何の日でしょうか?
そうです、ボージョレ・ヌーヴォーの解禁日です。11月18日(木)、弊社オフィスではこんなイベントを開催していました。

そして、同日。11月18日(木)は、もくテクの開催日でもありました。

イベント盛りだくさんの1日です。

ボージョレ・ヌーヴォーに、もくテクを添えて

今回のもくテクのテーマ

2021年秋のLT大会

今回のもくテクは、日々の業務で得られた知見についてのLT!
弥生では10以上のチームに分かれて新卒~ベテランが一緒になり、開発を行っています。
今年もそれぞれのチームで新しい技術や施策の導入が進みました。

各発表者の開発で得られた生の声をお楽しみいただこうということで、21卒の新卒3人から、勤続20年を超えるベテランまで、新しい技術や施策の導入のLTをしました。


発表者と発表内容はこちらをご覧ください。


10月のもくテク開催報告ブログ9月のもくテク開催報告ブログでは、セッションの内容をご紹介しています。今回11月の開催報告は、セッションの内容ではなく、舞台の裏側のお話しです。
LTの時間では話しきれなかったこと、じっくりみなさんに読んでほしいことは、個々にブログを書いてもらうことにします。
指針No.25:社会人の勉強は、アウトプットがゴールなのです。
もくテクに参加されたみなさんは覚えていますか?入社1年目の王さん&竹内さんの発表『目指せ、精明強幹!! ~社会人の心得~』で紹介していた書籍、入社1年目の教科書 | 書籍 | ダイヤモンド社 の指針の1つです。
何度でもゴールを決めちゃいましょう。

ちょっと違う気がしますが、細かいことは気にしない、気にしない。

発表者の裏話

早々に資料作成に着手する人、アイディアが降ってくるのを待つかのように直前まで資料作成には着手しない人、準備の仕方にも個性が現れていました。
準備を見ていて、面白いなと思った内容をご紹介します。

開催がオンラインならリハーサルもオンラインで

今まで、発表のリハーサルは、対面やZoomミーティングで実施していました。
対面やZoomミーティングで実施することで、その場ですぐに改善点を修正できるというメリットがある一方、発表者とレビューアーのスケジュールを合わせなければいけない、発表者自身が確認することができないというデメリットがありました。
そんなデメリットを解消すべく、Zoom録画機能を使って発表を録画してレビュー依頼をする発表者がいました。

私は、録画でのリハ―サルにレビューアーとして参加しました。
自分の都合のよいタイミングで動画を確認できました。「メモを取っている間に聞き逃したかもしれない」「何か違和感があるけれどなぜだろう」といった時に、一時停止や戻って聞き直すことができました。録画でのリハ―サルは、参加しやすいと感じました。
対話をしながら構想を練る場合は時間を共有して進めた方がメリットが大きくなります。発表練習の場合は、録画機能での確認が発表者・レビューアーともに非常に有効です。
発表者それぞれが、場面に合わせて工夫しながら準備を進めていました。

リハーサル動画のイメージ(※画像はイメージです。)

運営の裏話

オンサイト開催の時には、「開始時間に間に合わず遅れて参加する人にも本編をしっかり聞いてほしい」「場をあたためる意味合い」といったアイスブレイクの位置づけで会社紹介をしていました。
このため、オープニングの資料作成にあまり時間をかけていませんでした。
しかし、オンラインになってからのもくテクは、一味違います。

「いつもどおり」ではない会社紹介

弥生という組織やその中の人たちに興味を持っていただけるよう、運営メンバーはオープニングやクロージングにも力を入れています。
前回10月のオープニングでは、AWARD受賞をご紹介。今回11月のオープニングでは、弥生 22 シリーズの発売や、最新のユーザー数をご紹介。
10月・11月ともにクロージングでは採用イベントのご紹介をしています。
もくテクは、弥生の開発メンバーによる発表だけではなく、弥生の「今」を共有するイベントになっています。
ぜひ、オープニング・クロージングも楽しみに参加していただければと思います。


それでは、ここまで読んでいただいたあなたに。

3つのご案内

ご案内1:次回もくテクのご案内

次回の開催は2021年12月16日(木)です。
テーマは「AWS学習イベント DevAxのご紹介」!

弥生が2021年6月~9月に実施したAWS学習イベント「DevAx::Academy Monoliths To Microservices」についてご紹介します。
弥生のエンジニア向けに100人規模で実施した大型の技術研修イベントの概要と、学んだことの具体例の発表です。
ぜひ、各発表者が研修で得た知見についての生の声をお楽しみください!

詳細のご確認や、参加お申込みはこちらのイベントページから、よろしくお願いします。
mokuteku.connpass.com

ご案内2:アドベントカレンダーのご案内

今年もやります、弥生 Advent Calendar 2021! 弥生グループで働くエンジニアが業務に関係あること・ないこと、色々書いていきます。 12月1日(水)から始まります。ぜひご覧ください。

qiita.com

ご案内3:採用に関するご案内

弥生では、いっしょに働く仲間を募集しています! herp.careers https://herp.careers/v1/yayoi/QNC85w1I4sZeherp.careers

ここまで読んでいただきありがとうございました。
それでは、また次のブログでお会いしましょう!