2年半ぶりの開発合宿に行ってきました！

こんにちはあるいはこんばんは
UUUMのシステムユニットの渋江です。
5/13(金)〜5/14(土)に開発合宿へ行ってきました！ 2019年秋以来、2年半ぶりの開催です。今回の目的はスキルアップとコミュニケーションです。リモートワーク中心で会うことが少なくなり、新入社員も増え、オフラインで会ったことのないメンバーもいました。この機会に親睦を深めようと思います！
この記事ではその時の様子をお届けします！

2022-05-23

静的解析ツール「RubyCritic」の紹介

おはようございますこんにちはこんばんは。
UUUMのシステムユニットのmatsumotoです。
先日、RubyCriticという静的解析ツールを導入しましたので紹介します。

RubyCriticとは?

RubyCriticはrubyコードを静的解析するツールです。rubygemで提供されています。

ファイル毎の複雑度や重複した記述などを指摘してくれます。

解析結果はブラウザ上で確認できます。

導入に至った経緯

自分が担当しているシステムには既にメジャーな静的解析ツールであるRubocopが導入されており、コーディング規約に準拠してるかのチェックは行えていました。
しかし、より可読性、保守性が高いコードを書くためにもコーディング規約のチェックに加え、ファイル毎の複雑度や重複箇所などもチェックされるようになると良いと思いました。

また、RubyCriticを導入する事によってレビュー前にコーディングの指摘を受ける事ができ、結果としてレビュワーの負担を軽減する事ができると思いました。

あと解析結果を表示するブラウザがとても見やすい点もRubyCriticを導入した理由の一つです。

導入方法

導入方法はとてもシンプルです。

まずはrubycriticのgemをインストールします。

Gemfile

group :development do
  gem "rubycritic", :require => false
end

bundle installを行えば※基本的には導入完了です。

※ 補足

自分がrubycriticを導入しその後実行した時下記エラーが発生しましたので共有します。

RailsアプリにDockerを導入している場合に起こりうる可能性があるエラーです。（自分が担当しているシステムにもDockerが導入されています。）

エラー文

ArgumentError: invalid byte sequence in US-ASCII
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/line.rb:22:in `delete'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/line.rb:22:in `render'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/code_file.rb:42:in `block in render'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/code_file.rb:39:in `each'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/code_file.rb:39:in `with_index'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html/code_file.rb:39:in `render'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:37:in `block (2 levels) in create_directories_and_files'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:36:in `open'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:36:in `block in create_directories_and_files'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:34:in `each'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:34:in `create_directories_and_files'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/generators/html_report.rb:21:in `generate_report'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/reporter.rb:9:in `block in generate_report'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/reporter.rb:8:in `each'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/reporter.rb:8:in `generate_report'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/commands/default.rb:29:in `report'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/commands/default.rb:19:in `execute'
  /usr/local/bundle/gems/rubycritic-4.6.1/lib/rubycritic/cli/application.rb:21:in `execute'
  /usr/local/bundle/gems/rubycritic-4.6.1/bin/rubycritic:10:in `<top (required)>'
  /usr/local/bundle/bin/rubycritic:23:in `load'
  /usr/local/bundle/bin/rubycritic:23:in `<top (required)>'
ERROR: 1

調査した事

Dockerfileを確認するとDockerhub上のRubyのimage（version 2.5.7）が使われていました。

そのイメージの詳細を確認するとデフォルトのエンコーディングがUS-ASCIIでした。

$ docker run -it ruby:2.5.7 bin/bash
root@49bf9357e1b3:/# ruby -e 'puts Encoding.default_external'
US-ASCII

なので上記エラーが出たようです。

export RUBYOPT=-EUTF-8すればエンコーディングを変更できます。

$ docker run -it ruby:2.5.0 bin/bash
root@6b9b22a6ce36:/# export RUBYOPT=-EUTF-8
root@6b9b22a6ce36:/# ruby -e 'puts Encoding.default_external'
UTF-8

対処方法

Dockerfileに下記コードを追加

ENV RUBYOPT -EUTF-8

これでエンコーディングを変更できエラーなくrubycriticを実行できます。

因みにMacにrbenv経由で入れたRubyの場合、デフォルトのエンコーディングはUTF-8になっています。

実行方法

$ rubycritic .

で実行できます。

実行後./tmp/rubycritic/直下に解析結果がhtmlで保存され、ブラウザが起動して閲覧することができます。

$ rubycritic app/controllers/api/v1

のように指定のディレクトリだけを対象にして実行することもできます。

その他オプションはREADMEのUsageに記載さされているのでご確認いただけたらと思います。

解析内容について

rubycriticを実行した結果は下記になります。

$ docker-compose run --rm web bundle exec rubycritic app/controllers                                                                                                                                                                                                                              11:47:35
Creating coda-develop_web_run ... done
running flay smells
...........................................................
running flog smells
....................................................................................................................................................................................
running reek smells
....................................................................................................................................................................................
running complexity
....................................................................................................................................................................................
running attributes
....................................................................................................................................................................................
running churn
....................................................................................................................................................................................
running simple_cov
....................................................................................................................................................................................
New critique at file:////coda/tmp/rubycritic/overview.html
Attempted to open file:////coda/tmp/rubycritic/overview.html and failed because Unable to find a browser command. If this is unexpected, Please rerun with environment variable LAUNCHY_DEBUG=true or the '-d' commandline option and file a bug at https://github.com/copiousfreetime/launchy/issues/new
Score: 53.79
open tmp/rubycritic/overview.html

RubyCriticは、以下のruby解析用Gemに依存しています。

flay
- コード同士の類似度が高い部分を検出し、共通化に役立ちます。
flog
- コードの複雑度が高い部分を検出します。
reek
- 臭いコード(smell)を検出します。
- smellは、reekのドキュメントによると、「コードが読みにくい、または保守しづらい場所を示唆するもの」とのことです。

解析結果の確認

Code: ソースコードごとの警告の数や複雑度や評価（Rating）が一覧表示されます。

CodeやSmellsで対象コードのリンクを押した際に開かれる画面。
コードの中に警告内容がインラインで表示され、警告名をクリックすると警告解説記事にジャンプします。

reekが検出するsmellについて

rubycriticはreekというコードの"臭う"箇所を検出するgemに依存していますが、そのreekが検出するsmellはデフォルトの設定だととても個性的かつ厳しすぎるくらい指摘されます。

なので使い勝手が悪い、また肌に合わない場合はカスタマイズすると良いかと思います。

リポジトリのトップにyamlファイル(.reekファイルまたはconfig.reekファイル)を置くことで、reekが検出する特定のsmellをカスタマイズして抑制することができます。

詳細はこちらに記載されています。

RubyCriticを導入した結果（感想）

レビューをいただく前に実装で不安な箇所があった際は、今回導入した解析ツールを走らせる事によって改善点の早期発見とともにレビュアーの負担を削減できました。

また解析結果を表示するブラウザのUIもとても分かりやすく、今後リファクタをするタスクに着手する際はとても助けになるかと思います。

2022-05-16

JetBrainsのDataGripを勧めてみる。

こんにちは。UUUMのシステムユニットの永井です。
Apex Legends シーズン13が始まりました。
今シーズンはマスター目指します。

はじめに

皆さんはデータベース管理ツールは何を使用していますか？
PHPならMySQL Workbench、PostgreSQLならpgAdmin 4、国産フリーソフトのA5:SQL Mk-2など様々あると思いますが、私は普段JetBrainsのDataGripというツールを使用しています。
ですので、今回はDataGripの便利な機能を何点か共有できたらと思います。

ざっくりDataGripとは

JetBrainsが出しているデータベースIDEです。2017年生まれくらいです。
とにかく色々なデータベースを管理することができます。

なので、DataGripを使えれば正直どこ行っても新しいツールを覚える必要ないです。

フリーソフトではありませんが、無料30日間体験版もあります。
またざっくり一年間支払いすれば、その製品に対して永久fallbackライセンス(購入時点のバージョンならサブスクしてなくても使える)も得られます。

詳しくは以下を参照してください。

サブスクリプションベースのライセンスモデル対-永久ライセンスモデル

年額払いなら2年目は20%割引、3年目なら40%割引もしてくれます。

便利機能

コードフォーマット

例えばWebアプリケーションでデータの出力内容がおかしくて、
デバックやログに表示された複雑な条件のズラーっと長いSQLを確認する必要がある場合、
コードフォーマットを使えばいい感じに見やすく整えてくれるので捗ります。

公式のGifです。整形前がもっと複雑でもいい感じに整形してくれます。

コード補完機能

JetBrains製のIDEを使った事がある人ならわかると思うんですが、コード補完が強力です。 DataGripでもがっつりコード補完してくれます。

特にありがたいなと思うのは、テーブルに設定されている外部キーを元にJoin句の補完候補を出してくれることです。

結合先のテーブルが多い時は候補も多くあげてきますが、
そんな時は、user_groupsというテーブルを結合させたい場合は、ugと入力すると候補絞ってくれます。

他にも色々と補完してくれます。 www.jetbrains.com

差分確認機能

任意のスキーマやテーブルの差分を確認することもできます。

DataGripの古いバージョンだと差分ビューアー内で、差分を修正するためのDDLを表示してくれてはいましたが、そのまま実行はできませんでした。
しかし最近差分ビューアーが改良され、ビューアー内で確認→実行できるようになったみたいです。

ただし開発環境とステージング/本番のテーブル比較して確認したいだけの時に、間違えてExecute押してしまうと惨事なので、
最低限本番環境の接続設定は読み取り専用にしておくといいです。

pleiades.io

ダイアグラム生成機能

全体又は任意のテーブルを選択してダイアグラムを確認できるのもいい点だと思います。
また、生成したダイアグラムは以下の形式でエクスポートできるようになったので、サードパーティツールとの互換性が確保されたとのことです。

yEd の .graphml
JGraph の .drawio
Graphviz の .dot
Graphviz の位置情報付きの .dot
Mermaid の .md
Plantuml
IDEA の .uml

ただし、ER図を書いて、それを元にDDLや定義書を作成してくれる機能はない(たぶん)ので
今後のアップデートで追加してくれないかなと思います。
因みにそういった事やりたい人はA5:SQL Mk-2 がオススメです。

どんな人にオススメ？

こんな人にオススメです。

JetBrains製のIDEを使った時ある人。→ 使用感同じです。
All Products Pack もってるけど使ってない人 → もったいないので使ってください。
色々なDBに接続する必要がある人 → ツール切り替えしなくて済みます。cross-DBMSが使えるので、PostgreSQL データベースから SQL Server へすべてのテーブルを簡単にコピーとかもできるらしいです。
多機能すぎて使いこなせない人 → データベースを管理する上で基本的な操作などをサポートしてくれるので十分利用価値あると思います。

さいごに

今回はDataGripを紹介させていただきました。
他にも便利機能あるので、ぜひ一度使ってみてください！

pleiades.io

また、UUUMではエンジニアを絶賛募集中です！
https://www.wantedly.com/projects/861137

2022-05-09

自己研鑽補助ってなに？

UUUMのシステムユニットのしだです。
GWが明け、久々の仕事で何から手をつけるんだっけ？　となっている方も多いのではないでしょうか。私もそうです。
2022年はなんと今日から7/18まで祝日がありません。どうにか日々を乗り切りましょう。

はじめに

UUUMのシステムユニットは勉強会・輪読会が盛んで、週に3、4回、もしかしたら毎日なにかしら開催されているのではないかなという状況です。
もちろん全てに全員が参加しているわけではありませんが、チームで開催されたり、個人が宣言して有志で集まって開催されたり、結構自由に行われています。
社内だけではなく、社外のセミナーや勉強会に参加される方も多く、自主的に学ぶことに意欲の高い人が多くいる印象です。

私が以前いた会社では、私のいた部署はもちろん、システム部でも特に勉強会などはなく、恥ずかしながら外部セミナーなどに参加する発想自体がありませんでした。完全に、自身の文化資本にない状態ですね。
本を読むことは頭にあっても、身銭を切るにあたって一番良さそうな本はなんなのか、金額的にどうなのかなど調べていると、もうネットでいいかとなってしまったり。
そういった人間でも、業務に関連する本をなんやかんや毎月買って読んでいたり、社内外の勉強会やセミナーに参加するようになりました。
単純に、業務時間内に勉強会が開催されていることや、学習意欲の高い人たちがたくさんいるから影響されたのも要因ですが、私にとって一番影響があったのが、自己研鑽補助という制度でした。

ということで、自主的に学ぶ文化形成に寄与しているんじゃないかと思われる、自己研鑽補助について紹介します。
ちょうど前回sawada_yさんが『Udemyの動画と書籍については、自己研鑽補助の制度を利用し購入しました』と書いていましたが、その制度がこちらです。

自己研鑽補助とは

エンタメに触れ、情報を集め、体感すること、ビジネススキルに繋がることなど常に感度を高め、自己研鑽に励む社員を会社がサポートする制度で、毎月利用上限を1万円とし、ビジネススキル向上やエンタメ情報収集のための書籍購入などを経費申請できるUUUM独自の補助制度です。

全社的なルール

全社的には、下記の用途で利用OKとされています。（※2022年5月時点）

サブスクリプション(サブスク系映像、ニュースコンテンツ等)
書籍購入(ビジネス書籍、マンガ、雑誌、新聞)
セミナー参加(セミナーへの参加)
資格取得、教材購入(スクール・資格取得、教材の購入等)
ビデオ・コミックレンタル
映画鑑賞
ステージ・音楽鑑賞(コンサート、芸術鑑賞等)
その他(上記項目以外アミューズメントパーク等)

システムユニットでのルール

システムユニットでは業務内容を考慮し、以下のルールで運用されています。

技術・ビジネス書・小説系の書籍や雑誌可
紙・電子書籍のマンガは「マンガでわかるRuby」など、ノウハウ系のもののみ可
映像系円盤（DVDなど）は、レンタルのみ可
映画（劇場・配信）・ステージ・芸術鑑賞など可

※記載がないものは全社ルール適用（サブスクリプションや資格取得など）

具体的にどう利用しているか

私自身は主に、システム関連の知識を得るための本を買ったり、業務知識に関連する本を買うことに利用しています。
会社からの補助が1万円まであるからと、比較的高額な書籍も含めて買う習慣がつきました。
先にも書いたとおり、自分で買うとなると、あれもこれも買う余裕がないので選りすぐりの1冊を求めて探す時間が発生してしまうんですよね。
迷って探している時間は、気軽に買って読み終わる時間と同じかもしれない。そういった意味でも、かなりメリットの大きい制度だと思っています。
そして、買えば読むので、結果的に業務外の時間でも業務の学習をすることが増えました。

これが私だけなのか、みんなそう思っているのか、そもそもどれくらいの人がこの制度利用しているのかが知りたくなったので、システムユニット内でアンケートを取ってみました。

アンケート結果

有効回答数は18件、システムユニット全体で40人ほど在籍しているので、およそ半数に回答いただきました。
設問は下記の通りです。

自己研鑽補助、毎月使ってますか？
使わないことがある方は理由を教えて下さい
使っている方、使用用途を教えて下さい（複数選択可）
自己研鑽補助があったからやったこと・買ったものがあれば教えて下さい
- 例：受験料を補助申請できるから〇〇資格を取った、技術系書籍は補助があるから気軽に買うようになった、毎月映画を見る習慣ができた、など
自己研鑽補助を利用して得たもので、自分にとってよかったもの
- 得たものの具体的な内容（書籍の場合は書籍名、体験・経験の場合は概要など）と、よかった理由を教えてください

自己研鑽補助、毎月使ってますか？

毎月使っている人が12名、基本的に使っているも含めると16名で、全体の88.9％が利用している状況です。
「利用していない」も選択肢として設けていましたが、0でした。
全社では利用率が7割程度らしいので、システムユニットは比較的利用率が高いと言えそうです。

利用しない理由

回答6件のうち、申請忘れや締切によるものが3件、あとは主体的な理由です。
その他でいただいたうち、「前月の本を読み切れていないため」という回答があって誠実な人だなと感心しました。
私は積ん読することへのためらいが一切ないので、読んだかどうかに関わらず欲しい本はとりあえず買ってしまいます。

利用用途

予想通り、ほぼ全員が技術系書籍の購入に利用していました。
全社的にはエンターテインメントに関する補助という側面の強い制度ですが、システムユニットではかなり実務に即した利用が行われているのが見て取れます。
とはいえサブスクリプションや映画などにもかなり利用されているので、業務以外にもいい影響がありそうです。

自己研鑽補助があったからやったこと・買ったもの

ここは自由記入枠で、回答が15件ありました。
項目内に理由を複数記載してくださっていた方もいたので分割した上で、大きく分けて以下の通りの内容です。

技術書を買うようになった（10件）
技術以外も含めた学習（4件）
サブスクで音楽や動画に触れる（3件）
資格取得・受験（2件）

技術書を買うようになった、には、以前と比較して何冊も買うようになったも含んでいます。
頂いた中には以下のようなコメントもありました。

自身が持っているスキル領域以外に対して気軽にチャレンジするようになった

どうしても自身の業務に関わることが優先になりがちですが、会社から補助があることで、ちょっと他のことも試してみようという気になれるのは確かにそのとおりです。

オーディオブックを聞くようになり、ランニングが続くようになった

これは副次的な効果ですが、健康にも寄与している例ですね。

自己研鑽補助を利用して得たもので、自分にとってよかったもの

ここも自由記入枠で、回答が12件ありました。
いくつかコメントをピックアップします。

毎月技術書を買おう、読もうという気になれる

技術書を買うハードルが下がった。ちょっと高い分たまに1冊買う程度だったのが、すすめられたものを気軽に買えるようになった。

学習習慣がついた

このあたりは私が感じていたのと同じく、この制度によって習慣に影響があった例ですね。
また、それに加えてこういったコメントもありました。

技術的な成長はもちろん、美術館鑑賞など興味の幅が広がった

英語が以前より流暢に読めるようになり、業務でドキュメントを読むときに役立っています。また、 人から勧めてもらった映画などでコミュニケーションに役立ちました。

こちらは自身の業務スキルのみではなく、人とのかかわり合いや自身のプライベートにも影響があった例ですね。
さらに、具体的に書籍名などを上げてくださった例もありました。

PMBOK 第7版。高いので補助がなかったら絶対自主的に買わなかったと思うので。

「闇の西洋絵画史」山田五郎さん独自の視点で西洋絵画の主だったモチーフを解説してくれます。ちょっと高い

PMBOKは私も補助を利用して購入しました。
現在輪読会でこの本を読んでいますが、かなり高額なので補助がなかったら輪読会で読む本に上がらなかったのではないかなと思います。

「闇の西洋絵画史」、面白そうだなと思ってピックアップしてしまいました。業務とは直接関わりませんが、こういう本も気軽に買えるのがありがたいところです。（とりあえず1巻買いました）

まとめ

アンケートの設問がいまいちでしたね……特に最後2つは似たような内容になってしまったので、意図が明確な質問を考えるべきでした。
そんな反省点はありつつも、回答内容を見るに、身も蓋もない話で恐縮ですが、お金面での補助は学習習慣にかなり影響があると言って良さそうです。
かつ、この制度は用途を業務勉強のみに限っていないところが肝なんじゃないかなと感じました。
技術書を買って勉強する合間に、サブスクで映画を見てリフレッシュしたり、楽しみにしていた小説の新刊を読むとか、そういう余地があることで、業務も頑張れる。
ワークライフバランスという言葉自体はあまり好みませんが、結果的にそこに寄与する制度なんじゃないかなと思いました。

さて、そんなわけで、こういったユニークでありがたい制度もありつつ、勉強会なども盛んなUUUMのシステムユニットではエンジニアを募集しています。
気になる方はぜひ。 www.wantedly.com

2022-05-02

【GAS】GoogleDrive内のcsvファイルをスプレッドシートに一括インポートする

こんにちは、UUUMシステムユニットの sawada_y です。第2回オンラインハッカソンにて、シェルスクリプトを使用して月次作業を自動化したことについて発表させていただきました。その後、別の月次作業においてもGASを使用して自動化することができましたので、そのことについて書きたいと思います。

はじめに
自動化する前の作業内容
自動化した後の結果イメージ
要件
コード内容
最後に
参考にしたもの

はじめに

担当業務の中で月次でGoogleDriveにあるcsvファイル(50~60位)をスプレッドシートに手動でアップロードするという、とても面倒な月次作業がありました。そこで、GAS(Google Apps Script)を使用してGoogleDriveにある複数のcsvファイルをスプレッドシートに一括でインポートすることができたので、そのことについて書きたいと思います。※GASの環境構築についてはまとめて下さっている記事が多数あったので、省略します。

自動化する前の作業内容

Google Driveに格納されている複数のcsvファイルをスプレッドシートに手作業で1つ1つインポートする作業を月次で行なっておりました。csvファイルの種類については最近になって増えてきて、その数50~60ファイル程度になっています。ポチポチと1つ1つファイルを選択して[データをインポート]を押すというイメージです。

これは面倒。。。

ということでこの作業を自動化することにしました。

自動化した後の結果イメージ

GoogleDriveの指定フォルダにcsvファイルを格納しておいた状態で

スクリプトを実行すると、複数のcsvファイルがスプレッドシートに一括でインポートされます。

要件

結果をイメージできたところで、具体的に要件を整理します。

Google Driveに格納された複数のcsvファイルを該当のスプレッドシートに一括でインポートしたい
1つのファイルの内容が1つのシートに反映されるようにする。(50ファイルあったら、合計50シートになる)
それぞれのファイルの内容が、特定のシート名(そのファイルの一部が名前となっている)のシートに反映されるようにする
- ex)13tokyo_2202.csvなら13tokyoという名前のシートに、11saitama_2202.csvなら11saitamaという名前のシートに反映されるようにする。(細かいですが、前月のスプレッドシートのデータが残っていることを前提にそのデータをクリアにしてから反映するようにします)
特定のシート名(そのファイルの一部が名前となっている)のシートがなければ、特定のシート名(そのファイルの一部が名前となっている)のシートを新たに作成しそこに反映されるようにする。

コード内容

上記の要件を満たした、GASで記述したスクリプトを以下に記載します。初学者向けにコードの内容を書いたコメントアウトも細かめに記載しております(参考にさせて頂いた記事のコードを読み解くのに時間がかかってしまったので)。このスクリプトを実行すると、[2.実行イメージ]のようにインポートされます。

// 書き込む対象のアクティブなスプレッドシート(スクリプトにバインドされているシート)を取得
let ss = SpreadsheetApp.getActiveSpreadsheet();

function Import() {
  // getFoldersByIdでフォルダを取得
  let folder = DriveApp.getFolderById("格納フォルダのID");
  
  // ドライブの指定フォルダの全てのファイルのコレクションを取得
  let files = folder.getFiles();
  // ()内の条件式がtrueの間、{}内の処理が実行
    // hasNextで次のファイルが存在していたらtrueを返す。全て処理をしていればfalseを返す(未処理の場合、true。処理が終わればfalseとなる。)
  while (files.hasNext()){
  // nextで未処理の次のファイルを取得
  let file = files.next();
  // ファイル名を取得
  let fileName = file.getName();
  // _で区切って配列にする
  let fileNames = fileName.split('_');
  // 0番目から最後の要素以外をアンダーバーでくっつけたシート名にする。(13tokyo_2202.csvというファイル名なら13tokyoが返ってくる。)
  let sheetName = fileNames.slice(0,fileNames.length - 1).join('_');

  // ファイル名から抽出したシート名のシートがあるか判定
  let sh = ss.getSheetByName(sheetName);
    if(sh == null)
    {
      // なければ、引数の名前の新しいシートを挿入し、取得
      ss.insertSheet(sheetName);
      sh = ss.getSheetByName(sheetName);
    }
    else
    {
      // あればシートの値や数式や書式をクリアする
      sh.clear()
    }

  // getBlobでBlobオブジェクトとして取得(Blobとはデータの内容を操作したり、データを交換する為のオブジェクト)
  // getDataAsStringでブロブをエンコーディング。charset(文字コード)による文字列として取得
  let data = file.getBlob().getDataAsString("UTF-8");
  // 文字列データcsvを区切り文字 delimiterで分割して二次元配列を取得
  let csv = Utilities.parseCsv(data);

  // セルA1からCSVの内容を書き込む
  // getRangeで書き込む範囲を指定(開始セルは1行目の1列目、書き込み行数は配列数、書き込み列数は1次元配列の要素数)
  // setValuesは配列を対象のセル範囲に入力するメソッド
  sh.getRange(1,1,csv.length,csv[0].length).setValues(csv);
  }
}

コードの細かい内容はコメントに書いておりますが、ざっと以下のことを行っています。

書き込むスプレッドシートを取得
csvが格納されているフォルダを取得し、そのフォルダ内の全てのファイルを順番に処理していく
ファイル名から一部抽出したものをシート名とする。
- 13tokyo_2202.csvなら13tokyo、11saitama_2202.csvなら11saitamaをシート名として抽出。また、13_tokyo_2202.csvと途中で (ハイフン)がついていても 2202だけ削除し13_tokyoだけ抽出できるようにしている
抽出したシート名のシートが既にあればクリアしてから、csvの内容を書き込む
抽出したシート名のシートがなければ、その名前で新しいシートを作成し、csvの内容を書き込む

最後に

簡単なスクリプトにはなりますが、月次でインポートする作業を手動で行う手間と間違うリスクを少しばかり削減できたので、やって良かったなと思いました。ただ一旦インポートできた!という段階なので、より使用・管理しやすいように今後改良していきたいと思います。

参考にしたもの

(Udemyの動画と書籍については、自己研鑽補助の制度を利用し購入しました。)

2022-04-11

MySQL DBインスタンスバージョンアップの進め方

みなさんこんにちは！UUUMシステムユニットのぶちです。

桜の季節ですね。4月になり新しい環境に変わった方もいらっしゃるのではないでしょうか。実はUUUMのサービスの中にも新しいバージョンに生まれ変わっていた DB がいました🌸

はじめに
対象の DB 環境
事前に準備したもの
- バージョンアップ情報ドキュメントの作成
- 作業チェックリストの作成
作業内容
さいごに

はじめに

少し遡り雪解の候、 MySQL のメジャーバージョンアップを実施しました。具体的なオペレーションについては素晴らしい記事が世の中に多数ありました(大変お世話になりました)。

本記事では、実作業レベルの具体的なバージョンアップ手順については述べません。

サービス提供やステークホルダーとの擦り合わせなどの観点で実施した、周辺業務を主題に記載します。

対象の DB 環境

今回のバージョンアップ対象の環境について軽く触れておきます。

AWS RDS に構築している DBインスタンス
レプリカ無し
MySQL 5.6 から 5.7 へのアップグレード
アプリケーションのテストカバレッジは向上途中

事前に準備したもの

バージョンアップ情報ドキュメントの作成

作業全体像の把握と他メンバーへの共有を主目的として、バージョンアップ手順を作成しました。最終的に把握した項目は以下の通りです。

DB について

バージョンアップ後に変更される仕様の概要
DB のみで必要なダウンタイム
公式バージョンアップドキュメント等の情報
事前構築すべきリソース( Parameter Group 等)

アプリについて

テストの必要な機能

バージョンアップオペレーションについて

バージョンアップ作業内容
万一バージョンアップ失敗した場合の切り戻し

バージョンアップ後の注意事項について

不要なリソースの処理(旧DBやオペレーション用に構築したものなど)
IaCの修正
モニタリング対応

この中で特に、「万一バージョンアップ失敗した場合の切り戻し」は大切だと感じています。その理由は2点あります。

まず、当然のことですが、メンテ時間の延長はユーザーの予定を狂わせる可能性があります。サービスの信頼性や継続性は事業を継続する上で非常に重要な要素です。

また、切り戻しが必要な場面に遭遇する時点で、既に想定外の事態と対面していることでしょう。事前に準備しておけば、想定外の上さらに想定外のオペレーションを重ねず済みます。

勇気ある撤退の判断も視野に入れられるよう、可能な範囲で準備はしておきたいですね。

作業チェックリストの作成

正直手間がかかるため、チェックリストまではやらないケースも多い印象はあります。ですが作成することで受けた恩恵があったため記載しておきます。

バージョンアップのオペレーションを、実作業レベルでスプレッドシートにリストアップしました。実際に利用した項目(と作業サンプル)を以下に記載します。

実施チェック	手順No.	概要	予定開始時刻	備考欄
ぶち	1	Terraformからメンテイン	18:00	-
ぶち	2	DBスナップショット取得	18:05	-

特に「実施チェック」と「予定開始時刻」は記載して良かったです。

「実施チェック」は、作業分解することのメリットがありました。まず各メンバーに分担できるレベルに落とし込むため、作業が明確になります。また分担の結果全員が作業者として関わることになるため、事前の打ち合わせを同じ目線で細かく議論することができました。

「予定開始時刻」は、タイムマネジメントと実績としてのメリットがありました。現在の作業が予定時刻に対してどの程度順調か理解できる上、今後類似作業が生じた際の参考値になります。

もし次回があれば、実績の精度を上げるため「作業完了時刻」を追加してもいいかもしれません。

作業内容

開発環境でバージョンアップの実施

準備した内容を踏まえ、実際にオペレーションを行いました。この時点で、バージョンアップがプロダクトに対してどう影響するのかを判明させました。

実施結果を受けて、ドキュメントに必要事項があれば追記します。

今回は、念のため主要機能を手動テストするようチェックリストに追加することになりました。全機能の手動テストは現実的に不可能に近いため、事業的なインパクトの大きい部分を重点的に確認するようにしました。

サービスダウンの事前周知

作業チェックリストからバッファを含めた所要時間を見積もり、関係者にダウンタイムをアナウンスしました。

本番環境でバージョンアップの実施

ここまでの流れを踏まえて作業を実施します。準備の甲斐もあり、予定より早めに完了できました。

バージョンアップ後の残タスク処理

一番気を遣う作業が終わり安心しがちですが、ここでミスすると大変なことになる可能性があります。

例えば DB を Terraform で構築している場合、新しいものに修正しないと差分として認識されます。バージョンアップのやり方次第では、修正しないまま誤って apply してしまい、、、という状況の発端になりかねません。

また、 DB は比較的コストが大きくなりがちな部分だと思います。利用しなくなった古いインスタンスなどは折を見てコストのかからない形にしましょう。

そしてもう一つ。一定期間は予期しない挙動をしていないか普段よりモニタリングに気を遣うと良いと思います。

さいごに

今回担当したバージョンアップは、概ね以上のように実施しました。

こうした業務の一部を取り上てげも様々な進め方があると思います。当然組織やシステム構成に応じて必要な対応は異なりますが、安全性を高める取り組みは大切だと感じています。

また、今回はプロジェクトやチームにとっても良い方法を模索しながらの業務だったため、組織で取り組むという点でも勉強になりました。

本ブログが何かの参考になれば幸いです。

2022-04-04

BIツール (AWS QuickSight)の活用紹介

UUUMシステムユニットエンジニアの5n4wasa6です。

先日、実家に帰った際、ふきのとうやタケノコが生えており、春を感じる今日この頃です。大きなイノシシにも遭遇して戦々恐々としております。

はじめに

UUUMでは現在、中期IT計画というプロジェクトが進行しており、社内の各種サービスの連携や点在しているデータ(Excelやスプレットシートでの管理)を集約しマスタ化して、社員の業務効率化を図ろうとしております。

私が携わっているHerokura（ヘロクラ）というサービスでは、主に、Ruby (Ruby on Rails), JavaScript (Vue.js)を使用しております。

インフラ周りはAWSで構築しており、CI/CDはCircleCI (一部 Github Actions)を活用してます。

Terraform (IaC化)やサーバレスでの実装 (Lamdba)も行っております。

Herokura（ヘロクラ）の一部で、BIツールを活用して会社のKPIを全社員が認識できるような実装があるので、今回そちらをご紹介します。

弊社で活用しているBIツール

弊社では、BIツールとしてTableauやAmazon QuickSightを活用しております。

Tableauは、Youtubeの再生数やトレンドなどさまざまな分析に活用しております。

Amazon QuickSightは、前述の通り、社内のKPIを全社員が認識できるよう、実装/活用しております。

Amazon QuickSight選定の経緯

当初グラフ描画は、JSライブラリで実装することを検討しており、以下３つが候補に上がっておりましたが、単純なグラフ描画をサンプル実装して、事業部側の反応を見るということだったので、chart.jsを採用することになりました（一部Vue-good-table利用）。

chart.js
Google Charts
Highcharts

chart.jsでも描画そのものには大きな問題はなかったのですが、データが増えるにつれストレスなく描画することが辛くなっていきました。また、今後運用するに当たって簡単に手間なく事業部からの要望や開発側から提案ができる必要があるため、BIツールの検討が始まりました。

弊社内で利用していたTableauと、Amazon QuickSightの比較になりましたが、価格優位であるAmazon QuickSightで検証することに決まりました。

Amazon QuickSightの設定

QucikSightの各種設定は公式ドキュメントを見るのがベストです。

こちらの動画もわかりやすかったです。

データセットを作成することからスタートするのですが、RDSやS3、Salesforce、ファイルアップロード（csv, tsv, json)、etc...のデータから作成することが可能になっております。

自動更新の頻度は、最短で１時間毎なので準リアルタイムで描画が可能と言ったところでしょうか。

データは、「直接SQLを記述するパターン」と「テーブルを紐づけていくパターン」があるので簡単に作成することが可能です。

直接SQLパターン

f:id:always_protein:20220401113613p:plain — SQL

紐付けパターン

f:id:always_protein:20220401134518p:plain — 結合設定

f:id:always_protein:20220401113040p:plain — 全体

紐付けパターンの場合、「計算フィールドを追加」ボタンから新しいフィールドを作成することができます。さまざまな演算子が用意されているので、こちらから欲しいデータ（描画したい項目）を作成することができますが、個人的には直接SQLを書いてしまった方が早いかなと思います。

f:id:always_protein:20220401114021p:plain — 計算フィールド

データセットが作成できたら、分析タブから描画したいグラフパターンを選択していきます。

f:id:always_protein:20220401135221p:plain — グラフ描画 (分析)

作成できたらダッシュボードへの公開をして設定は終了です。

アプリケーションからAmazon QuickSightの呼び出し

AWS SDK for Ruby V3を使用して、Amazon QuickSightのダッシュボードを呼び出しています。

RoRの実装

各Controllerからget_dashboard_embed_urlを呼び出す

require "aws-sdk-quicksight"

class Provider::Quicksight
  def initialize
    @client = Aws::QuickSight::Client.new(
      region: Settings.aws[:region],
      access_key_id: Settings.aws[:access_key_id],
      secret_access_key: Settings.aws[:secret_access_key]
    )
  end

  def get_dashboard_embed_url(dashboard_id, user_arn, identity_type = "QUICKSIGHT", namespace = "default", additional_dashboard_ids = nil)
    @client.get_dashboard_embed_url(
      {
        aws_account_id: Settings.aws[:account_id].to_s,
        dashboard_id: dashboard_id,
        identity_type: identity_type, # IAM or QUICKSIGHT or ANONYMOUS
        session_lifetime_in_minutes: 60,
        undo_redo_disabled: false,
        reset_disabled: false,
        state_persistence_enabled: false,
        user_arn: user_arn,
        namespace: namespace,
        additional_dashboard_ids: additional_dashboard_ids
      }
    )
  rescue StandardError => e
    logger.error(e)
  end
end

Vueの実装 (Vue2)

クリックするボタン部

<template #graph>
  <div ref="embeddingContainer" />
  <v-button v-if="isDisplayGragh" class="btn btn-success" text="グラフ表示" @action="getQuicksightUrl" />
</template>

クリックアクションからの非同期処理

methods: {
    getQuicksightUrl() {
      handleHttp
        .get(this.$appRoute.quicksight_api_v1_report_sales_costs_path())
        .then((ret) => {
          this.embedDashboard(ret.data.url)
        })
        .catch((err) => {
          this.$toasted.error(err)
        })
    },

    embedDashboard(url) {
      const containerDiv = this.$refs.embeddingContainer
      const options = {
        url: url,
        container: containerDiv,
        scrolling: "no",
        height: "800px",
        width: "1000px",
        footerPaddingEnabled: true,
      }
      QuickSightEmbedding.embedDashboard(options)
      this.isDisplayGragh = false
    },
  },