VSCodeを使った簡単なjsonダミーデータの作り方

はじめまして!Voicyのフロントエンドエンジニアのしーちゃんです。

今年の4月にVoicyに入社しました! まだ在籍期間は2ヶ月弱ですが、体感としては、4ヶ月くらい経ちました。 刺激的な人々に囲まれていて、毎日楽しく経験を積んでいます。

今回は、VSCodeを使った簡単なjsonダミーデータの作り方についてお話しします。 結論から言うと、マルチカーソルとvscode-randomを使うと非常に簡単にダミーデータを作れると言う話です。

間違いなどあればご指摘いただけると大変助かります!

はじめに

フロントエンドの実装の確認をしたいとき、ダミーデータが必要になることがあります。 私は以下の状況になったことがあります。

「フロントエンド、バックエンドで同時に開発を進めた。フロントエンドはできたけど、バックエンドが未実装。」

「フロントエンド単体でテストをしたい!」

そのような実際のデータを使えないときに、ダミーデータを作成しますよね。 VSCodeとその拡張機能を使えば、早ければ1分で様々なダミーデータが作れます。

作りたいダミーデータ

複数のユーザー情報のダミーデータを作成します。

[
  {
    "name": "Randall Armstrong",
    "birthDay": "30/10/2022 16:19:03",
    "country": "Pakistan",
    "mail": "zumofi@roleg.tf"
  },
...
]

使う機能

VSCode標準機能

直線上にマルチカーソルする

  1. Shift + option + ドラッグ

qiita.com

ショートカットキーで同じ文字列、数値などの範囲を全て選択してマルチカーソルにする

  1. 文字列を選択する
  2. command + Shift + Lを押下
拡張機能

vscode-random

文字列や、数値、日付などをランダムに入力できます。

  1. 入力したい位置にカーソルを合わせる
  2. コマンドパレットからrandomと検索する
  3. randomで入力したい文字列や数値、メールアドレスなどのパターンを選択する
  4. 指定したrandomな値が入力される

作り方

手順

  1. 作りたいデータの数だけ改行する
  2. マルチカーソルで複数行にカーソルを合わせる(Shift + option + ドラッグで複数行選択する)

  3. コマンドパレットからrandom: Nameを入力し、適当なデータを入力する

以下入力中の画像イメージです。

マルチカーソルでの入力

おわりに

今回はVSCodeを使った簡単なjsonダミーデータの作り方を紹介しました。 フロントエンドの開発において、ダミーデータは必ず使うと思います。

私はマルチカーソルの存在を知ってからVSCodeを好きになりました。 慣れれば、手早く大量のダミーデータが作成できるようになるので、ぜひ使ってみてください〜!

パーソナリティの復帰をSlackで把握できるようにした話

こんにちは! 株式会社Voicyでデータアナリストをしている翔斗です。

本日は「Voicyのパーソナリティが復帰してきた際にスラックで通知を入れるようにした」という話です。

背景

Slackを利用している多くの会社(もしくは個人)では、何かしら自動で通知されるよう設定してるところは多いと思います。 Voicyも類にたがわず、画像のようにいくつかの行動の際にSlackに通知を行っています。

放送を初めて公開した際・プレミアムリスナーを開始した際・リスナーがコメントした際etc

しかし、現在通知していた条件ではパーソナリティが開始した時は把握できるのですが、放送が減っていたり、久しぶりに復帰したりした時には目視でしか気付くことができない状態でした。

やりたいこと

Voicyに戻ってきてくれたPがいた際にその存在を社員に知らせる

Voicy にはパーソナリティサクセスというパーソナリティをサポートする部署があります。そこでは、パーソナリティが放送を始めたタイミングで「サポート終わり」という状態ではなく継続的にパーソナリティがどんな状態かを確認しています。 ただ、どうしても日々発信をしている人に目が行きがちで、やめてしまった人が戻ってきた事に気づかないことも多々あります。

そのため、一定周期離脱したパーソナリティが戻ってきてくれたことを通知で知らせようと考えました。また、日頃続けてくれているパーソナリティが急にやめた際などにも気づけるようにしました。

前提知識

今までの通知はアプリ上で行動があった際などに直接Slackへ送られるものでしたが、今回行いたいのは、複数条件(変更可能性があるもの)の通知になります。 そのため、BQで通知対象になるパーソナリティの情報を入れたテーブルを毎日作成し、BQ上で定期的にSlackへ通知するようにしました。

過去にこちらでも記載しましたが、Voicyのデータ分析基盤はBigqueryになっています。 収録・再生アプリの行動ログやWebのデータ他スプレッドシートなどもデータレイクとしてBigqueryに集約しています。

行ったこと

  • テーブルの作成
  • cloud functionの設定
  • Pub/subの設定
  • cloud schedulerの設定
  • テーブルの定期実行

まずテーブルを作成します。

次にcloud functionを設定します。 トリガーをHTTPにしpython3.9で下記コードを入力します。(この時HTTPはcloudIAMの承認を必須にしてください)

from google.cloud import bigquery

def main(request):
    client = bigquery.Client()
    table_id = "テーブル名"
    # 射影するクエリ文を作成
    query = "クエリ"
    query_job = client.query(query=query)
    #スラック通知
    slack = slackweb.Slack(url="通知を送りたいSlackのチャンネル")
    try:
        for df in query_job:
            message = "メッセージ内容" 
            slack.notify(text=message)
    except Exception as e:
                print(e)
                pass
    return message 

requirements.txtには下記を入力します。

bigquery
slackweb

cloud functionの設定が終わったらPub/subの設定です。 配信タイプをpushにし、先ほど作成したHTTPをエンドポイントURLに入力します。 そして、外部から叩かれないように認証を有効にし、サービスアカウントを設定しサブスクリプションを作成します。

Pub/subの設定を済ませcloud schedulerを設定すればスラックへの通知は完了です。

今回は毎日9時に先ほど設定したpub/subを呼び出しています。

最後にテーブルの定期実行処理を済ませます。 そうすることで画像のように毎日9時過ぎに久しぶりに戻ってきてくれたパーソナリティが社員に知らされるようになりました。

感想

Voicyでは毎月何十人がチャンネルを開始しますが、全員が継続できるわけではありません。 声の発信が合わなかった人・忙しくてやめてしまう人・話すネタがなくなってしまった人、etc... さまざまな理由で放送が止まってしまう人がいます。今回Slackへの通知をして可視化したことで、想定以上に一度離脱しても戻ってきていることがわかりました。

戻ってきた人が可視化されたのをきっかけにパーソナリティサクセスと連携をとり、

なぜ戻って発信をしようと思ったのか?

どんなところが改善されると離脱せずに発信し続けられるのか?

など実際に戻ってきたパーソナリティに聞くこともでき、Voicyが良いプロダクトになるためのヒントがたくさん発見できたので今後の開発に活かしていこうと思います。

エンジニアにカルチャー醸成してもらうには

こんにちはエンジニアリングマネージャの山元です @yamagenii Voicyではエンジニア全員にカルチャー醸成をするための時間を週1時間ほどとってカルチャー促進をしています。 具体的な内容は以下です。

  • 「音声×テクノロジー×発信」でぶっちぎるチーム
  • 世の中にVoicyの技術をブランディングするチーム
  • エンジニア内部コミュニケーション活性化チーム
  • エンゲージメント非連続成長チーム

正社員のエンジニア全メンバーで取り組んでいます。 本記事ではなぜこの取り組みをしているのか、実際にどのように運用を開始したのかを説明します。

なぜ始めたのか

エンジニアが組織課題に自ら向き合って、自ら改善するというプロセスを体験することで、自分で組織を作る実感して欲しいと考えています。

Voicyの行動指針では「組織も一つのプロダクト。全員でアップデートを。」という行動指針があるのですが、組織は自分たちで成長させていくという考え方を大事にしています。 エンジニアとして働いていると、開発部分に視野が閉じがちで、組織開発はHRや総務など任せてしまいがちになり、組織自体の設計や雰囲気に批判が出ることもしばしばある事象かと思います。

そのような考え方は組織の成長のボトルネックになると考えていて、「組織も自分で改善をしないといけない」という意識を醸成することで、組織の状態にも責任を持って組織をより良い状態にアップデートしていけると考えています。

エンジニア以外も全職種この考え方を大事にしています。

corp.voicy.jp

エンジニアとして組織状態を自らよくする責任感があると、テックブランディングにも副次効果が出てくると考えており、エンジニアそれぞれが「自分の組織をよくしたい」「発信しないと!」「ここ自動化できるかも!」と思ってもらうのは大事です。

エンジニアは改善意識が高いからこそ自分の組織を自分でよくして欲しいのです。

現実的にはそこまで時間が取れてないことは現実としてありました。 しっかりPJとして立ち上げて、進めることで「自分で改善できる」という意識を醸成していきたいと考えています。

どのように進めたか

PJメンバーの募集

PJとしては冒頭で紹介した4つの課題を決めてエンジニアメンバーに紹介して、自分たちがやりたい課題を希望を出してもらいました。

余談ではありますが、4つの課題で人が偏るかなと思っていたのですが、ほとんど偏らずばらけて希望が来たのは意外でした。

そこからリーダはチーム毎に決定をしてもらっています。リーダのいるチーム、リーダがいないチーム、もチームの意思決定をしてもらいました。

チームと「目的とゴールとKPI」のすり合わせ

基本的にマネジメントとして「どのようにやるか」までは言及しないように強く意識をしました。 その代わり目的とゴールとKPIを設計してもらって、そこをチームと握ります。 例えば「エンジニアブログを運営してね!」という形ではお願いせず、「外部発信でVoicyがテック認知が広がるためにはどうしたらいいかな?」という問いかけをしています。

今回の目的は「課題を見つけて、自ら解決する」ということを大事にしています。 Howまでこちらから指定してしまうと、なぜやるか?何をやるか?、という考え方が醸成されません。むしろなぜやるか?何をやるか?の部分に意識を向けることが課題解決では重要と考えています。

自分で考えるという時間がとても大事で、「目的とゴール」を出してもらって、擦り合わせるようにしました。

またエンジニアはKPIを達成するという習慣がつき辛い職業かと思います。 しっかり数値にコミットする力は重要と捉えており、「約束した行動をした上で、目的やゴールを達成する」というプロセスをエンジニアにも実施する力をつけて欲しくKPIも明確化しています。

まだまだ運用中!

これ自体は3月から運用を開始して、まだまだうまくいっている施策とは言えませんが、今回実際にチームの取り組みを紹介します

「音声×テクノロジー×発信」でぶっちぎるチーム

Voicyの中でも人気チャンネルになるべく継続的に発信しています! ぜひ皆さん聞いてみてください!

voicy.jp

世の中にVoicyの技術をブランディングするチーム

まずはこのテックブログをしっかり運営して、Voicyの技術を世の中に発信していきます! 乞うご期待!

tech-blog.voicy.jp

エンジニア内部コミュニケーション活性化チーム

エンジニアの内部のコミュニケーションを活性化するべく、元々運用されていた「エンジニア発表会」のリライトやその他エンジニア同士のコミュニケーション取るためのイベントを企画中です

corp.voicy.jp

エンゲージメント非連続成長チーム

継続的なイベントではなく、チームの生産性が最大化する大きめのイベントを仕込み中! 記事としても発信できたらいいな?というプレッシャーをかけておきます

最後に

いかがでしたでしょうか? 元々組織を自分たちで作っていく意識のついているVoicyのメンバーだからこそ立ち上がりはうまくいっている面もあり、メンバーには大変感謝をしています。

ただ色々な企業さんのエンジニアに聞いてみると「〇〇の課題を感じる」みたいな話はよくあると思っています。 そういった課題を自ら分析させて、改善をさせることは責任意識の醸成としても非常に重要と考えています。 昨今エンジニアのキャリアパスとしても技術のみでキャリアを築くのは難しくなってきた中で、チームプレイができるかの重要性が増しています。 他責でなく自責で、自ら良くするという機会を通して、自分で組織を良くするという意識をつけられればと思います。

GoのORMのSQLBoilerでIN句の使い方と2通りの方法について

こんにちは!株式会社Voicyでバックエンドエンジニアをしているたーふーと申します。
簡単に自己紹介をさせていただくと、自分は去年の9月にVoicyに入社したので、入社して半年くらいになります!

今回はGoのORMであるSQLBoilerでWhereInの使い方とその2通りの方法についてお話しできればと思います!

自分自身Goを実務で利用したのはVoicyに入社してからなので歴は浅いのですが、、
その中でSQLBoiler関連の情報が少ないように感じた経緯があり、今回この記事を書かせていただきます。

なので同じような方の参考になれば幸いです!もし興味があれば是非ご覧ください!!

続きを読む

【Android】開発ビルドアプリで課金テストするためにやること

経緯

開発ビルドアプリでGoogle play アプリ内課金のテストをする上で躓くことがありポイントをまとめました。

公式ドキュメント

結論

  • Google Play に開発ビルドアプリを登録する
  • 自社のサーバーとGoogle間の購入フローを含めたシナリオを開発ビルドアプリで検証するには限定したユーザーにのみ managed Google Play に公開する
  • 限定公開アプリでテストするためのGoogle Workspace アカウントを準備

課金形態

Googleが提供するアプリ内課金の形態は以下の2種類があります。

  • 1 回限りのアイテム購入
  • 定期購入

「1 回限りのアイテム購入」は、ゲームのガチャなど、都度消費することを目的とする場合の消費可能アイテムと、広告の非表示やアップグレードなど、一度の購入で無期限に利用する場合の消費不可アイテムにわかれます。

「定期購入」は、オンライン雑誌や音楽ストリーミング サービスなど、ユーザーがキャンセルするまで自動的に更新され、繰り返し利用できるコンテンツの利用権を提供する場合に用います。

アプリ内課金で購入できるVoicyの特典

Voicyでは以下のコンテンツや特典をアプリ内課金で購入できます。

  • パーソナリティへの差し入れ
  • プレミアムリスナーへの参加権
  • 過去のプレミアム放送

「プレミアムリスナーへの参加権」向けコンテンツをWebで先駆けて販売していました。 Webが採用しているクレジット決済代行システムの仕様に伴い、モバイルでの販売形態はアイテム購入としています。

マルチ環境でアプリをビルドする

Androidアプリで開発環境、本番環境を切り替えるにはProduct Flavorを設定しています。 アプリケーション ID は環境別に一意である必要があり、開発環境のアプリケーションIDには".debug"といったSuffixをつけています。

app/build.gradle

    productFlavors {
        development {
            applicationIdSuffix ".dev"
            ...
        }
        staging {
            applicationIdSuffix ".stg"
            ...
        }
        production {
            ...
        }

支払いフロー

支払いフロー

上記が特典を購入する画面の大まかな処理フローになります。 4番の購入情報をGoogle Playへリクエストする際、production ID(またはSKU)を渡します。

開発ビルドアプリで、ライセンステスターを使用してアプリ内課金のテストを行うと、以下のような表示になります。

error dialog
課金ダイアログでエラー
開発環境ではproduction IDを本番のそれにinterfixをつけており、Google Play Consoleでは本番のみのproduction IDを登録していて、開発ビルドアプリGoogle Play Consoleでアイテム登録したアイテム情報が取得できません。

// 開発環境のproduction ID
jp.voicy.application.dev.tier2
// 本番環境のproduction ID
jp.voicy.application.tier2

Playストアには本番ビルドのアプリのみ登録しており、本番でのみ課金フローの確認を行うというのはリスキーですし、自社サーバーで実装した Google Play Developer API の Acknowledge(支払いを承認する処理)や Verify などのGoogle との結合部分を検証する必要があったため、Google Playストアに開発ビルドアプリを公開することにしました。

注:Googleと自社サーバーの結合部分(上記支払いフローの11番以降)の課金フロー検証を本番環境のみで行い、開発ビルドアプリではライセンステスターでの検証で十分な場合は開発ビルドアプリを公開する必要ありません。

限定公開のアプリを公開する

Playストアに登録して公開しない状態で課金フローを検証できることを期待しましたが、だめでした。 ここがハマったのですが、公開しないとやはりアイテム情報が取得できないようです。

また、一般ユーザーに開発ビルドアプリを公開するわけには行かないため限定公開にします。 限定公開についてもハマったのですが、内部テスターやbeta版リリースでも"課金ダイアログ"でエラー表示となります。

調査したところ、managed Google Playに開発ビルドアプリを公開する必要があります。

managed Google Playとは

企業とその社員のみに限定公開されたアプリを入手するためのストアです。 おもにインハウス向けの業務用アプリなどで利用します。

managed Google play

managed Google Play でアプリを公開し開発ビルドアプリで課金テストを行うには

  1. Google Workspace(旧G suite)にログインし、組織を追加後顧客IDをコピーします。

  2. Google Play Consoleで限定公開するアプリの managed Google Playを有効にします。 設定 > 詳細設定 > managed Google Play にて1でコピーした顧客IDを登録します。

  3. Androidの端末設定で仕事用プロファイルを有効に設定する Google Workspace のデバイス > モバイルとエンドポイント >設定 >Android設定で仕事用プロファイルを有効にします。この設定を行うことで社用アドレスをAndroid端末に追加すると「仕事用プロファイル」の追加を求められるようになります。

  4. 開発ビルドアプリを managed Google Play で入手する

Android端末からGoogle Workspace アカウント(社用アドレス)を一旦削除後、再度アカウントを追加

Android Device Policyを削除して、再度Android Device Policyをインストール
します Android Device Policyをインストールすると自動的に仕事用プロファイルが追加されます


仕事用プロファイル削除はここを見てね!
- 設定>パスワードとアカウント>仕事用 >仕事用プロファイルを削除
 仕事用のペインを開き、鍵アイコンのついたPlayストアで開発用アプリを検索してインストールします。GooglePlayの購入ダイアログを起動すると価格情報が取得できます。

仕事用ファイルを追加した端末の アプリ一覧

まとめ

最後まで読んでいただきありがとうございます! iOSで先駆けてアプリ内課金実装してくれたためほぼほぼ機能の詳細設計もつまずくことなく実装できたのですが、今回の記事にした内容はGoogleの中の人に問い合わせたりWorkspaceの担当者に聞いたり、ストアの設定がアプリに反映されるまでラグがあったりと大変時間を要してしまい、予定していた工数を大幅にオーバーしてしまいました。

これから同じように開発ビルドでしっかりと課金フローを確認したい方の一役変えれば嬉しいです。

speakerdeck.com

iOS/Android別々で開発しているVoicyアプリの処理を揃えるために始めたこと

この記事はVoicyアドベントカレンダー14日目の記事です。
誰がなんと言おうと14日目の記事です。

いよいよ寒くなってきましたね!みなさまいかがお過ごしでしょうか。
私はBiSHの解散を聞いて数日落ち込んでいます。
Voicyはオフィスが道玄坂にあり、BiSHの所属事務所も道玄坂にあるので、いつかばったり出会してしまうのではないかと通勤時はいつもそわそわしてしまいます。

というわけで本日の記事は私ほーりー(@horitamon)の担当です!
VoicyのAndroid版アプリの開発を担当しています。
最近は社内でバンドを組んだり?、そのTシャツが制作されたり?と、精力的に音楽活動も行っています。

今年のVoicyアプリも新機能のリリースが盛りだくさんだったわけですが、その中で私がVoicy4つのアプリの処理を揃えるためにはじめたことについて語っていきます!
技術的な細かい点については別記事で語ることにして、今回はそれぞれの目的や、やってみての気付きを中心にまとめていきます。

続きを読む