監視とアラートとTwilio

概要

エキサイトの川崎です。

弊社の一部のサービスには通話機能があり、 その通話機能(以降 call systemと呼びます)をTwilioを使って作っています。

call systemを作成運用する上で、困ったこと/悩んだこと はいろいろあるのですが、 今回はcall systemのアラートについて書きます。

call systemをリリースしてからアラートにはたくさん助けられてありがたみも感じていますが、 どんな時にどんなものをアラート対象とすべきで、どのように通知すべきなのか今も迷走しています。 (本記事における「アラート対象」というのは、発生した際にメールやslackなど何らかの形で関係者に通知を送る事象のことです)

「やばそうなもの」はどこかに通知する or 出来るだけ自動化して対処すればいい程度の認識でいましたが、 唐突に、監視について教科書的な知識がない(っていうか監視の定義って何？アラートってそもそも何？な状態)のはまずいな、と感じて下記の本を読み始めました。 www.oreilly.co.jp

主にアラートメインの話が書いてある3章を読んでみた上で、学んだことや、その上でどんな対応したかを できる限り自分の言葉にして書いていきます。

当たり前だろな内容の予感もしますが、 あー確かにねと認識をお手伝いできたり、新しい視点や違う視点を提供できたらいいなと思います。

監視とは

あるものについて、その振る舞いや出力を確認し続けること。

本を読むまでは「悪いものを見つけること」だと思っていました。 「悪いものを見つけること」でも間違ってないとは思うのですが、 個人的にはこんな感じで捉えることでなぜかしっくり来ました。(字面のまんまじゃん)

監視している中で「やばい、動いてない」とはどういう状態か

ユーザがサービスを使った時に困る状態。

たまに、「問題がある」とか「やばい、動いてない」の定義が分からなくなることがあります。もしかして私だけでしょうか( ；∀；) そんな時上記の言葉を読むと頭を整理できて、 本当に問題があるのかを判定できるようになります。 これだけが定義じゃないと思うのですが、サービスはユーザが使うものなのでまずはこれ中心に考えることにしました。

例えば、「ユーザに電話をかけた」という出来事の記録に失敗することはぱっと見良くなさそうで、誰かに言いたくなりますが、 ユーザにとっては通話ができれば問題ないかもしれません。 (アラート対象とはせずにログに残す程度でいい)

アラートとは

監視してて、何かあった時に誰かに警告してくれる(いまだに不明瞭で草生えない)

アラート対象の種類

1. 緊急性が高くすぐに対処すべき事象

2. 確認はすべきだけど、緊急性が低くすぐに対処しなくてもいい事象

本で上記のような2種類が書かれていました。 この2つ+「何かあったら確認したいけど誰かに通知するほどでもない事象」の3つを明確に分けられていなかった私は、 このいずれかに意識的に分類してみることで、頭の中で整理がしやすくなりました。

例えば、通話できることで成り立っているサービスにおいて、 「通話ができない状態」は、大事故なのでアラート対象(すぐに関係者に通知すべき)、というのはすぐにわかりますが、 「原因不明の通話作成の失敗1回(もちろんユーザには適切な画面表示をしています)」はどうでしょうか。なんらかの問題に気がつけるきっかけなので、詳細確認はしたいですが、サービス全体において致命的ではありません、何これアラート対象？どうすべきなの？っていうかアラートってなんだっけ？と、こういうパターンでは毎回頭の中がごちゃごちゃになっていました。

「原因不明の通話作成の失敗1回」は「2. 緊急性は低い事象」と認識し、原因はよく調べたところいくつかのパターンを含んでいたので、一部のパターンはシステム改修で対応し、どうしようもないものは、ログに残すだけにして、関係者への通知は行わないようにしました。(場合によっては緊急性が低い用の通知場所に通知してもいいと思います)

もはや気持ちの問題ですね。その時に応じて頭を使うのは変わらないのですが、アラート対象の分類のしかたを1つ知っておくだけで頭の中の整理のしやすさがかなり変わりました。

アラートの精査

迷うならとりあえず入れておいて、現状をみて減らしていくのもアリ

(本に書いてあったかは謎。。。)

実際にやる前はそんな雑なことしていいかな、定期的に担当者(自分)Twilioのデバッガー見にいけばいいのでは？とモヤモヤソワソワしていて、 実際にやってみて「アリ！」って思えたので書いておきます。

call systemを使用しているサービスのことを考えると、call systemが安定した稼働をすることはかなり重要だったので、 何か問題があった時にすぐ気がつけるようにしています。

call systemリリース時には、

• 「アプリケーションがあげるエラー」
• 「サーバー自体のエラー」

の中で重要なものは当然アラート対象としつつ、何が起こるか未知数だった

• 「TwilioのDebuggerが上げてくれるエラー(これらのうちのいくつか)」

については全てアラート対象としました。 (とはいえ、大量に来たら迷惑すぎるので初期だけは1時間に1回まとめて通知にしていました。)

しばらく運用していると「TwilioのDebuggerが上げてくれるエラー」について、下記のようにいい感じに間引くことができました。

• call systemを使っているサービスに害がない→アラート対象から外す
  例) Warning 32015 - Twilio

• ユーザの環境依存で一時的に起こってしまうがcall systemとしては対処できない→call systemを使っているサービス側で対策を考えた上でアラート対象から外す
  例) Warning 32014 - Twilio、Error 52103 - Twilio

現状を知りながら適切なアラート設定ができたので、一旦アラート対象にして順番に対処する形にしてよかったです。 (いつ起こるかわからないものを、定期的確認しに行くのはしんどかったと思う)

おわり。

List.ofがJacksonでdeserializeできない話

こんにちは。 エキサイト株式会社の三浦です。

JavaにはJacksonというライブラリがあり、Javaコード上のデータをJSONに変換したり（serialize）、逆にJSONをJavaコード上のデータに変換したり（deserialize）してくれます。 今回は、このJacksonを使った時にある条件下で詰まった話をしていきます。

Jackson

Jacksonは、Githubのページで以下のように定義されています。

Jackson has been known as "the Java JSON library" or "the best JSON parser for Java". Or simply as "JSON for Java".

端的に言えばJava用のJSONライブラリで、JSONとJavaコード上データの相互変換等をしてくれます。 例えば、APIでリクエスト元にデータを返す時にJavaコード上のデータをJSONに変換してから返したり、キャッシュ保存時にデータをJSON化してから保存し、逆にキャッシュからデータを取得する時にJSONをJavaコード上のデータに変換する、などで使われたりします。

大体のデータであればJacksonを使えば相互変換ができるのですが、実はまだ対応していない条件があります。 それが List.of です。

List.of と Jackson

List.of はJava9から追加されたメソッドで、immutableなリストを提供してくれます。 すなわち、 List.of で定義したリストは追加や削除、更新することができず、安全に取り扱えるため、非常に使い勝手がよいわけです。

List<String> sampleList = List.of("a", "b");

// 追加できない
sampleList.add("c");

ただ、残念ながらこの List.of はJacksonには対応していません。

// SAMPLE_KEYを使ってキャッシュする
@Cacheable(cacheNames = CacheKeyType.SAMPLE_KEY)
public List<String> getSampleList() {
    return List.of("a", "b");
}

このようにキャッシュをすると、キャッシュからデータを取得する時に Could not read JSON が発生します。 キャッシュデータを見ると以下のように保存されています。

["a", "b"]

一見問題ないように見えますが、実はJacksonではJSON化する際に変換元データの型も保存するようになっており、それをJSONから戻す際に使用するという仕様になっています。 List.of では型を保存してくれないので、Jacksonでは戻すことができないのです。

また、 List.of の使い方によっては型を保存してくれる場合もあるのですが、どうやら List.of で作られた型はまだJacksonで対応されていない型のようで、いずれにしろエラーが起きてしまいます。

解決方法

もっとも安易な解決方法は、 List.of を使わないことでしょう。 例えば上記であれば、 List.of の代わりに Arrays.asList を使うことができます。

// SAMPLE_KEYを使ってキャッシュする
@Cacheable(cacheNames = CacheKeyType.SAMPLE_KEY)
public List<String> getSampleList() {
    return Arrays.asList("a", "b");
}

こちらだとキャッシュでは、以下のように保存されます。

[
    "java.util.Arrays$ArrayList",
    ["a", "b"]
]

こちらであればJacksonに対応している型が保存されるため、Jacksonで問題なく戻すことができます。

可能であれば、

// 空リストを作るとき
Collections.emptyList();

// 1件だけのリストを作るとき
Collections.singletonList("a");

// 2件以上のリストを作るとき
Arrays.asList("a", "b");

とできると、空・1件のみのリストはimmutableになるのでおすすめです。

最後に

List.of は非常に便利ですが、このように落とし穴があるため気をつける必要があります。 状況に合わせて使い分けていきましょう。

なお、2021年9月6日現在では List.of がJacksonで使用できませんが、今後のアップデートで使用できるようになる可能性があります。 また、見つけられていないだけで、実は現状でも使えるようになる設定がある可能性もあります。

あらかじめご了承下さい。

Nimを使ってGUIアプリケーションを作成してみる

今回のあらすじ

前回の記事、「Nim言語を使って簡単に文章の類似度を計算してみる」の続きになります。
今回は文章の類似度を計算するGUIアプリケーションに挑戦していきます。

NiGUI

NiGUIは「cross-platform desktop GUI toolkit」ということで、
Windows, Mac, Linuxで動作するGUI用のライブラリです。
https://github.com/trustable-code/NiGui

アプリケーションを作成する

NiGUIのインストール

nimble install nigui

Macの場合

MacでNiGUIを利用しようとすると、
could not load: libgtk-3.0.dylib
と怒られることがあります。

その場合はbrewなどで必要なライブラリを入れてあげます。

brew install libgtk

準備

せっかくなので前回のコードを使いまわしましょう。
Nim言語を使って簡単に文章の類似度を計算してみるのコードを「ngram.nim」、
今回のコードを「nigui_test.nim」として以下のように保存します。

ngram.nimの中身

一応コピペができるように前回のコードをこちらに記載しておきます。
まだ読んでない方はぜひNim言語を使って簡単に文章の類似度を計算してみるを読んでみてくださいね！

import unicode
import tables
import math

proc createNGram*(n: int, text: string): seq[string] =
    ##
    ## n-gramデータを作成します
    ## 
    ## n: n-gramのnに当たる数値
    ## text: n-gramに分解（コーパス）したい文字列
    
    # マルチバイト文字列を扱えるようにテキストをルーン化する（Goとかにもある、アレ）
    let runeText = text.toRunes()

    # 何文字目まで連結させたかを保持しておく変数（Runeは1文字ずつ扱うため、indexでどこまで扱ったかをカウントしておく）
    var index = 0
    # n-gramで何文字ずつの文字列（コーパス）にするかを決めるためのカウント変数
    var cnt = 0
    # n-gramでの文字列を作成する際に利用するtmp変数
    var tmp: string

    while true:
        # cntがn-gramの指定文字数を超えたらそこで切り出す（安全のため<=としている）
        if n <= cnt:
            # resultは暗黙変数（nimでは返り値を定義すると自動的にresult変数が生成される）
            result.add(tmp)

            tmp = ""
            cnt = 0

            # n-gramの特性上一つ前の文字をもう一度利用するので、n-1をしている
            index = index - (n - 1)
            
        
        if text.runeLen() <= index:
            break
        
        # 1文字ずつ連結していく
        tmp = tmp & $runeText[index]

        cnt = cnt + 1
        index = index + 1


proc tf*(corpus: seq[string]): Table[string, int] =
    ##
    ## コーパスの中のTFを計算します
    ## 
    ## corpus: コーパスが格納されたseq配列を指定します

    for c in corpus:
        # 連想配列にその単語があれば1加算、なければその連想配列のキーを作成し、1を代入
        if result.hasKey(c):
            result[c] += 1
        else:
            result[c] = 1

proc cosineSimilarity*(text1: string, text2: string, ngramNum: int): float =
    ##
    ## 文章の類似度を調べます
    ## 
    ## text1: 1つ目の文章
    ## text2: 2つ目の文章
    ## ngramNum: 何gramにテキストを分解するか
    ##

    # 文章をそれぞれコーパスに分解します
    let text1Copus = createNGram(ngramNum, text1)
    let text2Copus = createNGram(ngramNum, text2)

    # text2のTF値を求めます
    let text2Tf = tf(text2Copus)

    # コサイン類似度の計算に必要な分子分母の変数
    var c = 0.0
    var m1 = 0.0
    var m2 = 0.0

    for t1c in text1Copus:
        # text2のコーパスにtext1のコーパスがあるかないかで類似度を計算することにします
        # text2のコーパスにtext1のコーパスがあれば1、なければ0を使います
        var n = 0.0
        if text2Tf.hasKey(t1c):
            n = 1.0
        
        # コサイン類似度に利用する分子分母の数値を計算
        c += (1 * n)
        m1 += 1 * 1
        m2 += n * n
    
    # コサイン類似度の計算
    if m1 == 0 or m2 == 0:
        return 0
    result = c / round(sqrt(m1) * sqrt(m2))

GUIの作成

NiGUIを使ってGUIを作成していきます。

import nigui

app.init()

# ウインドウの作成
var window = newWindow("テキストの類似度を計算する")
# ウインドウのサイズを設定
window.width = 600.scaleToDpi
window.height = 265.scaleToDpi

# ボタンなどを表示する領域の作成
var container = newContainer()
window.add(container)

# テキストエリアを作成
var textArea1 = newTextArea()
container.add(textArea1)
textArea1.x = 0
textArea1.y = 0
textArea1.width = 290
textArea1.height = 200

# テキストエリアを作成
var textArea2 = newTextArea()
container.add(textArea2)
textArea2.x = 310
textArea2.y = 0
textArea2.width = 290
textArea2.height = 200

# 類似度計算ボタンを作成
var calcButton = newButton("類似度の計算")
container.add(calcButton)
calcButton.x = 480
calcButton.y = 220
calcButton.width = 100
calcButton.height = 35

window.show()
app.run()

上記のコードを実行してみます。

$ nim c -r nigui_test.nim

すると、以下のような画面が生成されます。

これでGUIの基盤ができました。

ボタンを押したら類似度を計算し、表示させる

Nim言語を使って簡単に文章の類似度を計算してみるのコード（ngram.nim）を読み込みます。

import ngram

次にボタン押下時の処理を追加します。

# 類似度計算ボタン押下時の処理
calcButton.onClick = proc(event: ClickEvent) =
  let textArea1Text = textArea1.text
  let textArea2Text = textArea2.text

  # ２つの文章の類似度を計算
  let similarity = ngram.cosineSimilarity(textArea1Text, textArea2Text, 2)

  # メッセージボックスで、計算した類似度を表示
  window.alert("２つの文章の類似度は" & $similarity & "です。")

これで準備が完了です。
全体のコードを以下に記載いたします。

import nigui
import ngram


app.init()

# ウインドウの作成
var window = newWindow("テキストの類似度を計算する")
# ウインドウのサイズを設定
window.width = 600.scaleToDpi
window.height = 265.scaleToDpi

# ボタンなどを表示する領域の作成
var container = newContainer()
window.add(container)

# テキストエリアを作成
var textArea1 = newTextArea()
container.add(textArea1)
textArea1.x = 0
textArea1.y = 0
textArea1.width = 290
textArea1.height = 200

# テキストエリアを作成
var textArea2 = newTextArea()
container.add(textArea2)
textArea2.x = 310
textArea2.y = 0
textArea2.width = 290
textArea2.height = 200

# 類似度計算ボタンを作成
var calcButton = newButton("類似度の計算")
container.add(calcButton)
calcButton.x = 480
calcButton.y = 220
calcButton.width = 100
calcButton.height = 35

# 類似度計算ボタン押下時の処理
calcButton.onClick = proc(event: ClickEvent) =
  let textArea1Text = textArea1.text
  let textArea2Text = textArea2.text

  # ２つの文章の類似度を計算
  let similarity = ngram.cosineSimilarity(textArea1Text, textArea2Text, 2)

  # メッセージボックスで、計算した類似度を表示
  window.alert("２つの文章の類似度は" & $similarity & "です。")


window.show()
app.run()

動作

おわりに

さて、一通りソフトウェアの開発ができました。
Nimはなかなかおもしろい言語ですので、よかったらはまってみてください！
（Excite内でもはまっている人もいます！）

では、また次回！

Terraformの「Objects have changed outside of Terraform」について

こんにちは。 エキサイト株式会社の三浦です。

AWSやGCPで環境を構築するとき、Terraformを使用する方も多いかと思います。 今回は、Terraformでたまに起きる「Objects have changed outside of Terraform」について説明していきます。

Terraformとは

Terraformは、公式では以下のように紹介されています。

Terraform is an open-source infrastructure as code software tool that provides a consistent CLI workflow to manage hundreds of cloud services.

端的に言えば「クラウドサービス用のIaC」と言ったところで、AWSやGCPなどのクラウドサービスで環境構築する際に、Webコンソール上で作成するのではなくコードとして作成・管理することで、環境構築の再現性を担保したり、コード自体にドキュメントとしての意味を持たせたものになります。

Terraformを実行すると、コードで記述したサービスがクラウドサービス上に作成され、同時に初回実行であれば現在のサービスの状態を保存するための状態管理ファイルが作成されます。 2回目以降にTerraformを実行する場合は、状態管理ファイルを使用することで、前回の実行時との差分などを判定します。

基本的には、コードを全く変更せずに2回連続でTerraformを実行した場合、クラウドサービスの実態と状態管理ファイルの中身には差分は無いはずです。 ですが、たまに「変更された」判定が起きる場合があります。

Objects have changed outside of Terraform

コードが変更されていないにもかかわらず「変更された」判定が起きる場合、「Objects have changed outside of Terraform」というメッセージが表示されます。 このとき、原因としては以下の2点が考えられます。

1. Terraformを使わずに、以前Terraformで作成したサービスを変更した
2. それ以外

1の、「Terraformを使わずに、以前Terraformで作成したサービスを変更した」であれば話は簡単で、Terraformのコードを変更された後の状態に修正するか、もしくは修正せずにTerraformを実行することで現状のTerraformのコードの状態にサービス側を戻せば良いでしょう。 もしTerraform外で変更されるのが必然的な状況であれば、 ignore_changes という設定を使い、該当部分の変更をTerraform側で関知しないようにするのもいいかもしれません。

問題は、2の「それ以外」の場合です。

「それ以外」の場合、考えられるパターンとしては

• 一度のTerraformの実行で複数サービスが作成されるとき、サービス作成順の関係で初回実行ではサービスの状態が完全には状態管理ファイルに反映されず、2回目の実行で「変更された」判定となってしまう
• 作成に改行文字などを使用するサービスの場合、環境ごとの改行文字の細かい違いによって、サービスで実際に保存されている文字列と状態管理ファイルに保存されている文字列が違っており、2回目の実行で「変更された」判定となってしまう

などが挙げられ、おそらく上記以外にも様々なパターンがあると思われます。

「それ以外」の例

もちろん可能であればこの表示が出ないようにTerraformを修正したいところですが、なかなか修正が難しいというのが現状だと思います。 こういった場合は、 terraform apply や terraform apply -refresh-only などで状態管理ファイルを更新するのが現状だと現実解でしょう。

最後に

初めてこういった差分が出ると、何かミスをしてしまったのかと思ってしまうのではないでしょうか。 そのような状況のときに、この記事が役に立てれば幸いです。

なお上記は Terraform v1.0.5 にて確認したメッセージなので、バージョンが上がることでメッセージが変わったり、もしかしたらこういった差分は起こらないようになっていく可能性があります。 あらかじめご了承ください。

sql serverのflywayの設定について

ご無沙汰しています。株式会社エキサイトの中尾です。

sql serverの本番のデータベースの定義をローカル環境のdockerに再現する際に罠にかかったのでその内容を記載します。

なお、復旧にはflywayを使用します。

やりたいことは以下です。

• ローカル環境にsql serverを立てる
• 本番環境のTBL定義を読み込ませる

です。

まず、TBL定義を持ってきます。MSSMSを使用してバックアップスクリプトから取得します。

ここまではうまくいきます。

ローカルに持ってきてflywayを実行するとエラーになります。

以下の対応をすると、flywayが実行されました。

• sql serverはdatabaseの実態をDATAフォルダにF:\SQL\DATA\XXXXX.mdf、LOGフォルダにF:\SQL\DATA\XXXXX.ldfに保存します。mac環境に存在しないディレクトリに向いているのでコメントアウト。

• PARTNER TIMEOUTをコメントアウト。

• ユーザのロールを作成する処理をコメントアウト。

mysqldumpみたいに一回でできたら嬉しいですが、難しいようです。

WITH句の使い方

エキサイトのしばたにえんです。 sqlのWITH句をこないだ初めて使いましたのでその使い方を紹介いたします。

• Sql Server
• MySQL (8.0以降)
• PostgreSQL
• Oracle Database (12c以降)
• Maria DB (10.2.1以降)

でWITH句を使用することができます。

使い方

以下のような商品販売テーブル(sales)があるとします

code	sales_date	item_count
A00003	2021-05-17 10:30:00.000	2
A00001	2021-05-17 10:20:00.000	3
A00002	2021-05-17 10:15:00.000	3
A00003	2021-05-17 10:10:00.000	4
A00001	2021-05-17 10:08:00.000	3
A00002	2021-05-17 10:05:00.000	3
A00001	2021-05-17 10:03:00.000	3

SELECT 
    * 
FROM
    sales;

このテーブルにcode毎にitem_countを合計した値も追加して取得する必要があるとします。

code	sales_date	item_count	sum_count
A00003	2021-05-17 10:30:00.000	2	6
A00001	2021-05-17 10:20:00.000	3	9
A00002	2021-05-17 10:15:00.000	3	6
A00003	2021-05-17 10:10:00.000	4	6
A00001	2021-05-17 10:08:00.000	3	9
A00002	2021-05-17 10:05:00.000	3	6
A00001	2021-05-17 10:03:00.000	3	9

-- WITH句を使わない場合
SELECT
    sales.*,
    sum_count
FROM
    sales
JOIN (
    SELECT
        SUM(item_count) AS sum_count,
        code
    FROM
        sales
    GROUP BY
        code
) AS sub_sales
ON
    sales.code = sub_sales.code;

これで取得することができますが、 JOIN句の中に、SELECT句があるので読みにくいです。

WITH句を使った場合

-- WITH句を使う場合
WITH alias AS (
    SELECT
        SUM(item_count) AS sum_count,
        code
    FROM
        sales
    GROUP BY
        code
)
SELECT
    sales.*, alias.sum_count
FROM
    sales
JOIN
    alias
ON
    sales.code = alias.code

WITH句にあるSQL文は、その後のSELECT句より先に実行されます。 WITH句を使わない場合に比べ、JOINにあるSELECT句が外に出るので見やすくなっています。

使う機会があれば使ってみるといいかもしれません。

gradleからgradle実行

こんばんは。エキサイト株式会社中尾です。

gradleからjibを実行する時引数でいろいろ指定すると思いますが、めんどくさいですよね？

※例ではspring.profiles.activeしか指定していません。

./gradlew jib -Djib.container.args=--spring.profiles.active=dev -Djib.to.image=$IMAGE

個人的にargsとか、環境ごとには変わりますが基本コマンド変わらないと思います。 ということ、私は以下のような形でgradleからgradleを実行します。

./gradlew apiAuthBuild -Ptag= bugfix/test

コマンドを実行する前に、aws configreは設定しています。 DOCKER_CONFIGを指定することでloginした際のcredentialsを別ディレクトリに保存ができます。

ext repositoryDev = hoge
ext repositoryNameApiAuth = hogehoge

task apiAuthBuild(type: Exec) {
    doFirst {
        def tag = getProperty('tag').replaceAll( "/","-" )
        def apiAuth = repositoryDev + "/" + repositoryNameApiAuth + ":" + tag
        def ecrLogin = "aws ecr get-login-password | docker login --username AWS --password-stdin " + repositoryDev
        environment "DOCKER_CONFIG" , System.getProperty("user.dir") + "/.docker"
        executable "sh"
        args "-c", ecrLogin + " && " +
                "./gradlew api-auth:jib " +
                "      -Djib.container.args=--spring.profiles.active=dev " +
                "      -Djib.to.image=" + apiAuth

    }
}

aws configreさえ設定していれば、ローカルからでもjenkinsからでもどこでも実行できて便利になると思います。 リリースコマンドはツールに依存しない形にするととても便利になると思います。

Jetpack ComposeのContentColorを活用する

こんにちは。エキサイト株式会社 Androidエンジニアの克です。

今回は、ContentColorを使って色の変更をシンプルにするお話をします。

まずは普通に要素を表示してみる

とりあえず適当なアイコンとテキストを表示するコードを用意しました。

Box(
    modifier = Modifier.fillMaxSize(),
    contentAlignment = Alignment.Center,
) {
    Column {
        Row(
            modifier = Modifier.padding(8.dp),
            verticalAlignment = Alignment.CenterVertically,
        ) {
            Icon(
                imageVector = Icons.Rounded.Android,
                contentDescription = null,
            )
            Text(text = "サンプル1")
        }
        Row(
            modifier = Modifier.padding(8.dp),
            verticalAlignment = Alignment.CenterVertically,
        ) {
            Icon(
                imageVector = Icons.Rounded.Android,
                contentDescription = null,
            )
            Text(text = "サンプル2")
        }
    }
}

こちらを実行すると次のような画面になります。

もしこの状態で「上側の要素の背景を黒くしたい」という要件が出てきたらどのようにするでしょうか。

単純にRowの背景を黒くしてみます。

---
Row(
    modifier = Modifier
        .background(Color.Black)
        .padding(8.dp),
    verticalAlignment = Alignment.CenterVertically,
) { 
---

アイコンとテキストは黒のままなので、当然ですが見えなくなってしまいます。

そのためアイコンとテキストの色も変えていきます。

---
Icon(
    imageVector = Icons.Rounded.Android,
    contentDescription = null,
    tint = Color.White,
)
Text(
    text = "サンプル1",
    color = Color.White,
)
---

これで要件を満たすことはできましたが、このやり方には下記のような問題点があります。

• 要素が増えた場合、全ての要素に色の設定をする必要がある
• 設定の漏れにより、意図しない表示になりやすい

ContentColorを使うようにすると、こういった問題を解決することができます。

ContentColorとは

既存で用意されているComposableの多くは、デフォルトでContentColorを参照するものが多いです。

@Composable
fun Icon(
---
    tint: Color = LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
)

@Composable
fun Text(
---
) {
    val textColor = color.takeOrElse {
        style.color.takeOrElse {
            LocalContentColor.current.copy(alpha = LocalContentAlpha.current)
        }
    }

例であげたものでは LocalContentColor.currentが使われています。

こちらは現在設定されているContentColorを参照するというもので、このContentColorを変更してあげれば自動的に要素に反映されるということになります。

ContentColorを使ってみる

先程のコードを、ContentColorを使用したものに変更してみましょう。

鍵となるのはSurfaceです。

SurfaceはBoxなどと同様に要素を配置できるものですが、名前の通り要素の下に敷くような用途で使用します。

Surfaceでは自身の色とともに、ContentColorを設定することもできるので今回はこちらを活用していきます。

公式のドキュメントでも、背景色の設定にはSurfaceを使用することが記載されています。

developer.android.com

要素の背景色を設定する際は、Surface を使用することをおすすめします。Surface は適切なコンテンツ色を設定します。Modifier.background() で直接呼び出すと適切なコンテンツ色が設定されないため、ご注意ください。

先程のコードをSurfaceに置き換えたものが下記となります。

Surface(
    color = Color.Black,
    contentColor = Color.White,
) {
    Row(
        modifier = Modifier.padding(8.dp),
        verticalAlignment = Alignment.CenterVertically,
    ) {
        Icon(
            imageVector = Icons.Rounded.Android,
            contentDescription = null,
        )
        Text(text = "サンプル1")
    }
}

要素自体に色を指定する必要がなくなったので、どれだけ要素が増えようとも困ることはありませんね。

最後に

個別の対応や同じコードの繰り返しを多用すると、仕様の変更に対応しにくくなったり人為的なミスが発生しやすくなります。 フレームワークが用意してくれている共通化できるような機能を積極的に活用していくようにしましょう。

第3回定期勉強会「PM先生 俺みたいになるな！！」

エキサイトの おおしげ です。

今月も定期勉強会が開催されたのでそれについて共有しようと思います。

過去開催分についてはこちらからどうぞ
tech.excite.co.jp
tech.excite.co.jp

「PM先生 俺みたいになるな！！」

今月は「PM先生 俺みたいになるな！！」というタイトルで、普段からプロジェクトマネジメントを行っているiXITメンバーによるプロジェクトマネジメント全般に関するお話でした。

主な内容として、

• プロジェクトマネジメントを初めて経験する場合のあるある
• それを防ぐためのPMBOKの紹介
• 過去に経験したプロジェクトマネジメントに関する大きなしくじり
• 実際にプロジェクトマネジメントを行っているメンバーからのお悩み相談

などがありました。

エキサイトとiXITでは自社開発もあれば受託開発もあって、大なり小なりプロジェクトマネジメントに関わっているメンバーは多数いるので、皆とても勉強になったようです。
やはり内容として堅苦しいものになってしまうかとも思いましたが、発表していただいたメンバーがわかりやすく楽しい発表にしてくれたのでとても盛り上がりました。
特に、あるあるの話のときは身にしみたり、しくじりの話のときはそれを反面教師にしたりと、コメント欄が一番盛り上がっていました。

また、PMBOKを知識として知らないメンバーもおり、今後のプロジェクトマネジメントに生かしていきたいという声もあがっていました。
もちろん知識として知っているだけでは意味がありませんが、実践に移すためにはそもそも知識として知っていなければできないので、それを知るための良い時間だったと思います。

お悩み相談は20分ほどの時間だったのですが、より具体的なコミュニケーションの取り方や見積もりの方法などについても言及があり、時間が足りないほどでした。
私自身、ビジネスサイドとコミュニケーションを密に取らないといけなかったり、見積もりを出さないといけなかったりと、今現在まさにという状況だったので、すぐさま取り入れようと思います。

お悩み相談、コメント欄、アンケートなどを見ても見積もりに言及しているメンバーが多かったので、見積もり特化の第二弾も開催されるかもしれません！

最後に

定期勉強会も第3回となりましたが、あまりテーマが偏らないように開催していこうと思っています。
今後とも様々な勉強会を開催していくのでよろしくおねがいします。

JavaでHTMLの不要なスペース・改行を削除する

こんにちは。 エキサイト株式会社の三浦です。

JavaでHTMLを構築するとき、タグ間などに存在する不要なスペースや改行を消したいと思ったことはありませんか？ 今回は、それらを削除する方法について説明します。

HTMLと不要なスペース・改行

例えば、以下のようなHTMLを作りたいとしましょう。

<div>
    <span>hello world!</span>
    <a href="https://sample/">sample site</a>
</div>

通常ならこれで問題ありませんが、それ以降のHTMLの整形処理などの関係で、不要なスペースや改行を削除したいと思ったことはありませんか？ 上記のHTMLなら、以下のような状態にしたい、というものです。

<div><span>hello world!</span><a href="https://sample/">sample site</a></div>

ですが、例えばThymeleafなどを使っている場合、こんな形式はあまりに可読性が低いと言わざるを得ません。 PHPのsmartyと呼ばれるテンプレートエンジンであればstripというタグを使うことができるのですが、Thymeleafにはそのような機能はありません。

そこで、今回はこの strip の機能を参考に、不要なスペース・改行削除処理を自作してみました。

スペース・改行削除処理

strip の機能は、

各行の先頭と終端にある 余分なホワイトスペースやキャリッジリターンが除去されます。

というものです。 つまり、

1. 改行文字ごとにHTMLを分解し、
2. それぞれをtrimする

事ができればいいわけです。

すなわち、以下の処理になります。

Pattern BREAK_PATTERN = Pattern.compile("\r\n|\r|\n");

String html = "整形したいHTML";
String strippedHtml = Arrays
    .stream(BREAK_PATTERN.split(html))
    .map(htmlLine -> htmlLine.trim())
    .collect(Collectors.joining());

ついでにタグ文字を取り除きたかったり、半角・全角スペースしか存在しない行は削除したいなどのカスタムな要望があれば、以下のように処理することもできます。

Pattern BREAK_PATTERN = Pattern.compile("\r\n|\r|\n");
Pattern TAB_PATTERN = Pattern.compile("\t");

String html = "整形したいHTML";
String strippedHtml = Arrays
    .stream(BREAK_PATTERN.split(html))
    .map(htmlLine -> TAB_PATTERN.matcher(htmlLine.trim()).replaceAll(""))
    .filter(htmlLine -> StringUtils.isNotBlank(htmlLine))
    .collect(Collectors.joining());

最後に

最初に書いたとおり、そもそもHTMLはこの程度のスペースや改行は気にする必要がないようにできています。 なので、Thymeleafにデフォルトで削除機能がないのは、ある意味当然と言えます。

可能であれば、そもそもこれらのスペース・改行を気にせずに済むような状態にコードを変更することを優先し、どうしようもない場合のみ今回のコードの使用を検討してみてもらえると良いかと思います。

Formでint型の変数には@NotNullは使えない

こんにちは、エキサイトのしばたにえんです。

知っている人なら当たり前のことかもしれませんが、Formでint型の変数には@NotNullは使えません。

早速ですが以下をご覧ください

SampleController.java

@RestController
public class SampleController {
    @GetMapping("sample")
    void get(@ModelAttribute @Valid SampleRequest sampleRequest, BindingResult bindingResult) {
        if (bindingResult.hasErrors()) {
            throw new BadRequestException(
                    bindingResult
                            .getFieldError("num")
                            .getDefaultMessage()
            );
        }
    }
}

SampleRequest.java

@Data
public class SampleRequest {

    @NotNull
    private int num;
}

http://localhost:8080/sampleにアクセス

<Response body is empty>

numがない状態でのアクセスなので@NotNullに引っかかってエラーになると思いますが エラーは表示されません。 クエリパラメーターで値が入っていない場合 numにはint型のデフォルト値が入りnum = 0となるため @NotNullには引っかからないのです。

対処法

@Data
public class SampleRequest {

    @NotNull
    private Integer num;
}

http://localhost:8080/sampleにアクセス

{
  "error": {
    "message": "null は許可されていません"
  }
}

numにはInteger型のデフォルト値が入りnum = nullとなるため @NotNullでバリデートされています。

業種交流LT会【クリエイティブ編】を開催しました 🎉

業種交流LT会【クリエイティブ編】を開催しました

エキサイトのあはれんです。

業種、部署、社歴を問わず交流できる場を創出することを目的とした業種交流LT会を開催しました 🎉

今回のテーマは「クリエイティブ」ということで、デザイナー職の方に登壇していただきました。

デザイナー職、エンジニア職、ビジネス職、またインターン生も参加してくださりました。最大参加人数は56名にも達し、多くのメンバーが参加してくれました。😊🎉

登壇内容

デザイナー職の方に、どんな仕事をされているのかを説明していただきました。

トンマナ作成のお話

トンマナ作成の話

6月にリリースされたリモート占いサービス「Maja(マーヤ)」でデザイナーをされている高橋さんに、 トンマナについて話していだきました。

トンマナとは...

「トーン＆マナー」の略でデザインやトーンの一貫性を保つための"ルール"として使われる。

「Maja(マーヤ)」では、チーム総出でサービスのミッション、ビジョン、バリューを考え、 それをもとにトンマナを決めたことで、迷いが発生せず、デザインがしやすかったそうです。

私はエンジニアとして「Maja(マーヤ)」に参加していましたが、トンマナ決めは、サービス理解をより深めてくれる機会になってよかったです。😊

maja.excite.co.jp

エンジニアよ UIについてもっと対話してくれ！

エンジニアよ UIについてもっと対話してくれ！

6月にリリースされた経営管理プラットフォーム「KUROTEN.（クロテン）」でデザイナーをされている新野さんに、 チームでやっているエンジニアとデザイナーとの対話の取り組みについて話していただきました。

デザイナーが作ったデザインとエンジニアがフレームワークを利用して実装したものに差分が出てしまう課題に対して、 デザインシステム勉強会の開催やデザインシステムを導入することで、解決に取り組んだそうです。

この発表を聞き、デザイナーの意図をまだまだ汲み取れていないと反省しました...。😨

デザイナー職ともっと対話を増やしてよりよいUXを目指したいと思いました！💪😤

lp.kuroten.jp

最近やっている仕事

最近やっている仕事

21卒デザイナーの山﨑さんに、最近の業務に関して話していただきました。

記事クリエイティブ制作やTシャツのデザイン制作を行っているそうです。 制作過程について説明していく中でイメージボード制作について以下のように話してくださりました。

ターゲット選定・要件定義などビジネス側と協力して決定した後、その成果物に合ったテイストの選定のためイメージボードを製作します。 ただ「可愛い」という言葉だけでも色々な種類の「可愛い」があるので、フェミニンな可愛さ・ガーリーな可愛さ・オーガニックな可愛さなどに分類分けしたイメージボードを提出して解像度を上げていきます

なんとなくの「可愛い」ではなく分類し解像度を上げてデザインしているので、 デザインさんはユーザに対して適切な「可愛い」を伝えられるのですね。😊

配属されて3ヶ月でUIについて学んだこと

配属されて3ヶ月でUIについて学んだこと

21卒デザイナーの鍜治本さんに、UIについて学んだことを話していただきました。

鍜治本さんも「KUROTEN.（クロテン）」のデザイナーさんでして、 「KUROTEN.（クロテン）」でのFigmaの活用方法について話していただきました。

紹介していただいたFigma運用方法が良かったので、 私のチームでもFigmaをより活用できるようにFigmaについてもっと勉強したいと思いました！

まとめ

業種、部署、社歴を問わず交流できる場を創出することを目的とし、開催したLT会でしたが、 アンケートで以下のような声があり、交流のきっかけをつくることができたのではないかと思いました。

• 他の業種の方のデザイン（UIなど）に対する愛や熱意あふれるプレゼンを聞いて、その領域に関して理解が深まりました。また、今後自分のエンジニアとしてのキャリアでも役に立ちそうな知識も多く得られたので良かったです。
• デザイナーと開発の対話が必要とおっしゃっていて、今回のLT会もエンジニアがデザイナーを理解する対話の一つだなと思いました！
• 他事業・他部署のデザイナーがどんなふうに仕事をしているか見れて楽しかったです！

今後もLT会のレポートを紹介していきますので見ていただけると幸いです。

最後に

エキサイトでは一緒に働いてくれる仲間を絶賛募集しております！

長期インターン、夏季インターンも歓迎していますので、興味があれば連絡いただければと思います🙇‍♀️

www.wantedly.com

JUnitのテストでDisplayNameを使い、わかりやすいテストを書こう

こんにちは。 エキサイト株式会社の三浦です。

皆さん、JUnitでユニットテストを書いていますか？ 今回は、@DisplayNameを使うことによってJUnitのユニットテストの可読性が上がるという話です。

ユニットテストの可読性の問題点

ユニットテストは、テスト対象が複雑になるほどコード量が多くなっていきます。 それは、検証するパターンが多かったり、テストのために用意するモデルやモックが増えていくためですが、その結果各ユニットテストのメソッドが何のテストなのか、ぱっと見ただけではわからなくなることがあります。

今回はそれを、DisplayNameというアノテーションを使うことで解決していきます。

DisplayNameの使い方と効果

DisplayNameの使い方は簡単で、テストメソッドにアノテーションとしてつけるだけです。

@ExtendWith(MockitoExtension.class)
public class SampleTest {

    @Test
    @DisplayName("サンプルテスト")
    void sample() {
        Assertions.assertEquals(
                true,
                true,
                "必ず成功する"
        );
    }
}

好きな文字列でテストメソッドに名前をつけることができるようになり、可読性が上がったかと思います。 また、テストに失敗した場合、

@ExtendWith(MockitoExtension.class)
public class SampleTest {

    @Test
    @DisplayName("サンプルテスト")
    void sample() {
        Assertions.assertEquals(
                true,
                false,
                "必ず成功する"
        );
    }
}

以下のようにログを表示してくれるため、失敗したメソッドを探し出すのも簡単になります。

SampleTest > サンプルテスト FAILED

最後に

ちょっとしたことですが、ぱっと見ただけで何をしているかわかるというのは非常に良いことです。 ぜひ使ってみてください。

ボイス＆トーンについて理解が深まった話

ボイス＆トーンについて理解が深まった話

こんにちは！課金サービスのデザイナーのSAZUKAです。

技術書より推理小説のほうが好きなんですが、先日読んだ「UXライティングの教科書」という本がおもしろかったので紹介します。

UXライティングとは

「UXライティング」という言葉自体あまり浸透していないと思います。読んで字の如くですが一言で説明するとこんな感じ。

「言葉や文章によるユーザーに与える様々な経験」

UXデザイン＝デザインによる経験、のように安易に理解されがちなんですが、実際はUXデザインはもっと広くて深い。カスタマージャーニーマップもユーザーアンケートもペルソナ作成なんかもUXをより良くするための手法です( ˘ω˘ )👆

だからUXライティングはUXデザインの中の1つだと考えるのが良さそう。

ボイス&トーン

参考書で何度も登場する「ボイス&トーン」という言葉があります。

• ボイス：私たちの声が一人一人異なるのと同じように、ブランドやサービスも個性として一貫性を持つこと。

• トーン：機械的ではなく人間味を持ったコミュニケーション、話し方。

いわゆるブランドやサービス自体の「ペルソナ」なのかなと思います。

いちばん腑に落ちたのが、オフラインで心のこもった接客を受ける場合、webサイトを訪れたときも同じように対人接客のようなおもてなしをするべきではという考え。

旅行先のホテルの接客はとても素晴らしいのに、申し込みサイトで全く歓迎する雰囲気のないページに無機質で機械的なテキストばかり並んでいたらギャップが生まれます。逆に予約時のボイス＆トーンを高めれば満足度もアップします。

「一貫性」は重要である

紹介されていたIKEAはオフラインもオンラインも同じユニークさを感じます。私自身も足を運んだことがありますが、オンラインショップとのギャップや違和感を全く感じないほど一貫されていると思いました。

例えば節水アイテムの紹介ページは「歯を磨いているときは蛇口を閉めましょう。「ちりも積もれば山となる」です。」いうテキストが書いてありますが、もしこれが「このシリーズの蛇口は節水できます」になっていたら全くIKEAらしさはなくなってしまいますよね( ˘ω˘ ;)💦

自分が今デザインを担当している「エキサイトお悩み相談室」（カウンセラーに電話相談できるサービス）なら、たとえば登録画面では「一歩踏み出してみませんか」「カウンセラーに話してみましょう」などの言葉を一言添えるべきなのかもしれません。

自分がユーザーだったら（サイトに来たとき）どんな言葉をかけてほしいか、これは忘れてはならないので念頭に置いておきます( ˘ω˘ )👆

ボタンにはユーザーがやること（行動）ではなく、ユーザーが得るもの（価値）を伝える言葉を入れるべき

自分が関わっているデザインで1つ紹介。昨年の話ですが、当時エキサイトお悩み相談室のカウンセラー詳細ページには「相談受付中」ボタンというものがありました。機能としては、カウンセラーが待機していていつでも相談可能な状態を表すボタンです。

カウンセラー詳細の改修前と改修後

これはステータスではないのか？ステータスをボタンにして良いのか？とジョインしてからずっと違和感を抱いており、チームで話し合いの末「いますぐ電話相談する」に変え、ステータスは上部に持ってきました。

結果はものすごい成果が出たわけではありませんが、悪くないものでした（ここでは数字は割愛させていただきます）

旧デザインの「相談受付中」というのは私たちサービス側の都合であり「今受付てますよ〜！」と店の前で呼び込みをしているような状態です。

一方、新デザインは「いますぐ相談したい」というユーザーの意思をそのままボタンにしています。（「カウンセラーに話を聞いてもらう」という言葉も良さそうですね。長いけど。）

また、旧デザインは「相談受付中か…ということは相談できるということね！」とユーザーに考えるという作業を与えてしまうので直感的ではありません。

ユーザーが「そのとき何をしたいのか」「何を求めているのか」をWHYし続けると、意外と拍子抜けするくらいシンプルな言葉に辿り着くかもしれません。

他にも紹介したい事例はありますが長くなってしまったのでまた今度書きます。

最後に

余談ですが、この前「UXライティングの教科書」をベースにしたオンラインセミナーに参加しましたが参加者が200名超えで驚きでした。日本でも注目されつつあるけどまだ浸透していないので新しく勉強するのもオススメです👌

OSSコミッターになってみよう

こんにちは、エキサイト株式会社エンジニアの伊藤（🐦 @motokiito2）です🙌

みなさんはOSSへのコミットに対して、どのようなイメージを持ちますか？

「つよつよなエンジニアがよくやってる！」

「敷居が高すぎるから自分には関係ない。。」

なんて思う方も、少なくないと思います。(自分も以前はこう思っていました)

ですが、この認識は間違っていて、きっかけさえあれば誰でもOSSコミッターになれるのです！

今回は、実際に私が最近OSSにコミットしたケースと流れを紹介したいと思います！

修正箇所を発見する

私は、業務で PHPのフレームワーク Laravel を利用しています。

あるとき、いつものようにコードに対して静的解析を実行したところ、phpstanで未到達コードの警告が発生しました。

警告が発生したのは、以下のようなコードでした

        if (is_null($this->request->old())) {
            return false';
        }

return false; 行には到達しないとの警告でしたが、デバッガでは確かに到達するので、どういうことかと調べたところ、

Laravel のコード src/Illuminate/Http/Concerns/InteractsWithFlashData.php の old() は、下記のような実装になっていました (Laravel 現行バージョンでは修正済みです)

    /**
     * Retrieve an old input item.
     *
     * @param  string|null  $key
     * @param  string|array|null  $default
     * @return string|array
     */
    public function old($key = null, $default = null)
    {
        return $this->hasSession() ? $this->session()->getOldInput($key, $default) : $default;
    }

お気づきでしょうか。

$this->hasSession() が false かつ、$default 引数が与えられていない場合にnull を返すことがあるにも関わらず、phpdocの表記は、@return string|array となっていますね。

要はphpdocの記述が間違っているだけなのですが、このレベルの間違いは、Laravelに限らずOSSではよくあることです。

気になる方は、自分がよく利用しているOSSのリポジトリを探して、コミットログを見てみてください！

修正する

修正箇所がわかったので、修正してみましょう！

(このあたりの手順はOSSによって異なる場合があるので、READMEやContribution Guideを読んでみてください。)

修正を行うために、まずはLaravelのリポジトリをforkします。

fork laravel

forkしたリポジトリをローカルにcloneしたら、修正用のブランチを切ります。

Laravelの場合は、Contribution Guideに

「master ではなく current LTS branch からブランチを切ってね！」

と注意書きがありました。

OSSによってルールが設定されているので、よく読んでおきましょう。

ルールに従っていないと、せっかくPRを出してもmergeされずcloseされてしまいます。

ブランチ名については、Laravelの場合は特に指定がなかったので、過去にマージされていたブランチ名を参考に fixDocInInteractsWithFlashData としました。

さて、今回の修正は非常に簡単で、該当箇所のphpdocの記述を修正するだけです。

    /**
     * Retrieve an old input item.
     *
     * @param  string|null  $key
     * @param  string|array|null  $default
     * @return string|array|null
     */
    public function old($key = null, $default = null)
    {
        return $this->hasSession() ? $this->session()->getOldInput($key, $default) : $default;
    }

修正が終わったので、コミットしてpushします。

コミットメッセージも、特にルールが設定されていなければ、過去にマージされたコミットを参考にすると良いと思います！

PRを出す

修正が終わったので、次はプルリクエストを出します。

プルリクエストの記述についてもルールが設定されていることがあるので、事前に確認しておきましょう。

今回は、Laravel の Contribution Guide に従い、merge先を current LTSである laravel:8.x に設定し、フォーマットに沿って修正内容等を記述しました。

実際のプルリクエストはこちらです。

github.com

ここまでできたら、後はプルリクエストが承認されることを祈りながら待ちます。

今回の場合は、修正内容が簡単なこともあり、半日ほどでmergeされました！

あとがき

今回は、実際に私がLaravelにコミットした際の流れをご紹介しました。

今回のような簡単な修正でも、OSSに貢献することができます。

このケースを知って、OSSコミットへの敷居が下がった方もいらっしゃるのではないでしょうか！

「自分でもできそう！やってみよう！」と思う方が一人でもいてくれたら嬉しいです👍