🎄Misoca、アドベントカレンダーやるってよ

先週に引き続きMisoca開発の黒曜です。

ほたるちゃん のCDデビューが決まったので、来年春が楽しみです。

🗓アドベントカレンダー

昨年に続き、今年もアドベントカレンダーをやってます。

f:id:kokuyouwind:20181213125401p:plain

今年は弥生株式会社ALTOAとの合同開催になってます。このブログでは見慣れないアイコンがいっぱいありますね。
カレンダーを立てたのは自分ですが、余ったところに入ろうと思っていたらあっという間に全部埋まっていました。

そんなわけで自分は不参加です。
ただ各人珠玉の非業務ネタで攻めていて開発ブログには誰も書いてなかったので、宣伝がてらこの記事を書いています。
もう半分終わってしまっていますが、まだ半分も残ってるということで…

どの記事も素晴らしいので、ぜひご一読ください。
個人的おすすめは、めっちゃバズって500はてブを超えたマルチカーソルを使わないVSCodeはただのVSCodeだ!です。

小ネタ: Terraformの結果をデスクトップ通知する

宣伝だけだと寂しいのでちょっとした小ネタを。

MisocaではTerraformを使ってAWSの設定をコード化して管理しています。

ただ terraform planterraform apply は地味に時間がかかり、ぼーっと待つには長いのですが他の作業をやると結果確認を忘れてしまったりします。

🖥terminal-notifier

そこでterminal-notifierを使って、planやapplyが完了したらデスクトップ通知を送るようにしました。

ついでにterraform-landscapeを使ってplanの結果を整形し見やすくしています。

結果、以下のようなエイリアスでわりと使い勝手良く利用できています。

alias tplan='terraform plan | bundle exec landscape | tee /tmp/plan.log; cat /tmp/plan.log | grep -E "^Plan|^No" | xargs -I{} terminal-notifier -title "Terraform Plan Finished" -message "{}" '
alias tapply='terraform apply -auto-approve | tee /tmp/apply.log; cat /tmp/apply.log | grep "^Apply" | xargs -I{} terminal-notifier -title "Terraform Apply Finished" -message "{}"'

ザ・ワンライナーですね。
なおこのスクリプトではlandscapeをbundler経由で入れている前提になっていますが、brewで入れているなら bundle exec は不要です。

実行例

実際にtplanして、変更がないとこんな感じの通知が来ます。

f:id:kokuyouwind:20181213132256p:plain

一方で変更があるとこんな感じ。

f:id:kokuyouwind:20181213132320p:plain

コンソールのほうを見ると、以下のように差分が確認できます。
今回はThorタスクを実行するRunCommand用SSM Documentの更新で、選択できるタスク名が増えたdiffになっています。*1

CLANNAD:kokuyou% tplan
~ module.ssm_documents.aws_ssm_document.RunThorTask
    content:   "type": "String",
                        "allowedValues": [
                          "list",
               +          "test:example"
                        ]
                      },
                      "executionTimeout": {
                        "type": "String",
                        "default": "3600",

Plan: 0 to add, 1 to change, 0 to destroy.

問題なさそうなのでtapplyすると以下のような通知が来ます。*2
[0m が残念感ありますが、まぁ実用上問題はないでしょう。

f:id:kokuyouwind:20181213132734p:plain

こうしてterraformの実行中はちょっとした他作業をしつつ、コマンドが完了したら即結果を確認、そのまま後続作業に取り掛かれるようになりました。

terminal-notifierは工夫次第で色々使えそうなので、ぜひお試しください。

📢宣伝

Misocaではアドベントカレンダーの記事を書きたい、もしくは参加しそびれて腹いせにワンライナーを書きたいエンジニアを募集しています。

www.wantedly.com

*1:タスク名は適当なものに変えてます

*2:通知が来たタイミングをスクショしそこねたので通知ログの画像を使ってます。このためtplanのと見た目が違いますが、ホントは同じように通知されています

SwitchRoleを使用してIAMユーザ管理を楽にする

Misoca開発チームの@kokuyouです。

最近新しいMac miniが届き、MacBook Proとの2台体制になったので、区別しやすいようマシン名をつけました。
MacBook Proのマシン名がKanon、Mac miniのマシン名がCLANNADとなっております。*1

f:id:kokuyouwind:20181122130446p:plain

f:id:kokuyouwind:20181122130454p:plain

これに対する某氏の反応がこちら。

f:id:kokuyouwind:20181122130508p:plain

はい。

🧑IAMユーザ増えすぎ問題

Misocaではサービスの開発・運用にAWSを活用しています。 この際に各環境の設定が混在しないよう、以下のようにAWSアカウントを分けています。

  • sandbox : 自由に各種設定を試せる砂場環境
  • development : 開発系のEC2やサービス設定を行う環境
  • production : 本番系のEC2やサービス設定を行う環境

これによって各リソースがどの環境のためのものかわかりやすくなり、「開発用の設定を弄ったら本番にも影響しちゃった!」という事態も防ぐことができます。
また「開発環境は自由に触れるが、本番環境は設定参照のみが可能」といった、環境基準でのIAMポリシーもシンプルに表現できます。

しかし、この運用では各環境ごとに全員分のIAMユーザを発行・管理する必要があります。
開発者が増えるごとに、IAMユーザの発行を3回行う必要があるわけです。

また開発者が利用する際も、AWSコンソールでIAMユーザを切り替えるたびにログインしなおす必要があります。
アカウント名が被っているとブラウザがパスワードを1環境分しか覚えてくれなかったりと、これもなかなか面倒です。*2

🎭 IAMユーザ集約とロール切り替え

そこで、ロールの切り替えを利用して他のアカウントのロールに切り替える方法を導入しました。

ログイン専用のAWSアカウントを新たに作成し、IAMユーザはこの環境にのみ作成します。 開発者はIAMユーザでログイン後、各環境のロールに切り替えることで、開発環境や本番環境での作業を行えるようになります。

ロールやポリシーの設定はClassMethodさんの記事を大いに参考にしています。

以下で導入手順を大まかに解説します。

既存環境へのロール追加

これまでは AdminDeveloper などのIAMグループを作成し、IAMユーザをグループに割り当てることで権限を管理していました。
これを置き換えるため、それぞれのグループに対応する切り替え用IAMロールを作成します。

「信頼されたエンティティ」には、ログイン環境のAWSアカウントIDを入力します。

f:id:kokuyouwind:20181122135242p:plain

ポリシーは、既存のグループについているものをそのまま選択します。 ただし「自分のMFAデバイスを設定する」などのIAM絡みのポリシーは必要なくなるので、そういったポリシーは省きます。

f:id:kokuyouwind:20181122135334p:plain

ロール名はグループとの対応がわかりやすいよう、同じ名前をつけました。
これについては、 SwitchRoleDeveloper などのように、SwitchRole用だとわかりやすい名前にしたほうが管理しやすいかもしれません。

f:id:kokuyouwind:20181128173212p:plain

ログイン環境の設定

続けて、ログイン用の環境からロール切り替えできるようにしていきます。

ロールの切り替えは sts::AssumeRole というアクションです。
先ほど開発環境に作ったIAMロールが arn:aws:iam::000000000000:role/Developer であれば、以下のようなポリシーを作ることでロール切り替えを許可できます。

f:id:kokuyouwind:20181128173829p:plain

ポリシー名は環境とロールのペアがわかりやすい名前にしておくと後々管理しやすいです。

以下の例だと開発環境(DevEnv)にある開発者ロール(DeveloperRole)で、用語が被ってしまい分かりづらいですね…

f:id:kokuyouwind:20181128174259p:plain

あとは、このポリシーを各IAMユーザに付与することで、そのユーザは該当ロールに切り替えられるようになります。

実際にロールを切り替える

ログイン環境に入り、アカウントメニューにある「ロールの切り替え」からアカウントを切り替えることができます。

f:id:kokuyouwind:20181128174838p:plain

成功すると、右上のアカウント表示が指定した名前と色に変わります。
今入っている環境がわかりやすいよう、一定のルールで名前と色を設定するのがおすすめです。

f:id:kokuyouwind:20181128175110p:plain

設定Tips

  • 1つのロールごとに対応する切替ポリシーをログイン環境に作り、それを束ねるグループを作ると扱いやすい
    • DeveloperグループにDevEnvDeveloprポリシーとProdEnvReadOnlyポリシーをアタッチする、といった管理ができる
  • ロール切替の情報入力はけっこう面倒なので、切替リンクをまとめておくと布教しやすい
  • IAMポリシー割当を弄るだけで好きな環境・好きなロールに切り替えられるので、ログイン環境のIAM権限は限られたユーザにのみ付与する

👍 SwitchRoleでよいところ

  • 当初の想定通り、環境の切り替えが非常に楽になった
    • 管理するログイン情報が1つだけで済む
    • 新しい人が入ったときも、IAMユーザを1つ作るだけ
  • ログイン環境のIAMだけ見れば「誰が何をできるか」が概ね分かるようになった
  • より弱い権限での動作確認がしやすくなった
    • 「管理者以外はこのバケットを見れなくしたい」といった設定をAdministratorアカウントで動作確認するのはなかなか難しかったけど、Roleを切り替えるだけでできるようになった

🤔 SwitchRoleの気になること

いま入っている環境が分かりづらい

右上のロール表示を見ればわかるんですが、あまり目立たないのでうっかり間違えそうになります…

特に大きいディスプレイで作業していると表示が小さくなるので見落とし率が上がります。

f:id:kokuyouwind:20181128182032p:plain

画面中央を注視して作業してると、ここはまず見ないですよね…

どうせならヘッダーの背景色も同じ色にしてくれるとわかりやすいんですが、そういった機能はないようです。

同じことを考える人はいるようで、AWS Extend Switch RolescolorAWSFrameといったChrome拡張を使えば多少はわかりやすくなります。

Roleの信頼するエンティティにIAMグループを指定できない

SwitchRoleに使うロールには信頼関係を設定できます。
ログイン環境のアカウントIDを設定した部分ですね。

f:id:kokuyouwind:20181128182813p:plain

GUIからはアカウント単位までしか設定できませんが、JSONを直接編集することでIAMユーザ単位でも信頼するエンティティを設定することができます。
「ログイン環境のkokuyouのみを信頼する」といった設定をしておけば、ログイン環境側のポリシーをどう弄ってもそれ以外のユーザは切り替えられなくなるわけですね。
この設定は複数のIAM Userがあるアカウントをスイッチ元として、クロスアカウント用IAM Roleを作るにも書いてあります。

とはいえ、ユーザ単位で信頼関係を管理するのは管理が大変そうです。 できれば「ログイン環境のAdminグループを信頼する」といった設定をしたくなってきます。

残念ながら、信頼関係に設定できるのはIAMユーザ、IAMロールのみで、IAMグループは設定できないようです。
アカウント単位で信頼してもさほど問題はないのですが、できれば最小限にしたいところですね。

🌈 今後やりたいこと

現状は手作業でIAMユーザを作ってSwitchRole用グループを割り当てていますが、この辺をterraformで管理してPull RequestベースでのIAMユーザ追加・IAMグループ割当ができると、手作業を減らせるうえ履歴も追いやすい形で残って良さそうです。

また、本番環境では「一部S3バケットのみアクセスできる」などのポリシーが設定されています。
しかし、他のポリシーと一緒に設定した状態で意図通り動くかは結構分かりづらく、都度手作業で確認しています。

こうした部分も、ロールごとにawspec でテストを書いてCIできるようにしていけると良いなと思います。

📢 宣伝

MisocaではAWSを使いこなしたいエンジニアを募集しています!

www.wantedly.com

*1:どっちもAIRじゃない、というのがポイントです

*2:Chromeでユーザを複数作り、それぞれのChromeユーザごとに別のIAMユーザでログインするという運用をしている人が多いようです

Rails 6.0 での新機能 Action Text を試してみた

id:eitoball です。秋ですね。読書の秋といいますが、先日、「われはレギオン」のわれらはレギオン 3: 太陽系最終大戦 (ハヤカワ文庫SF)を読み終えました。物語のテンポがよく、気持ちよく読むことができました。Sci-Fi小説が好きな方には特にお勧めします。(われらはレギオン1 AI探査機集合体 (ハヤカワ文庫SF)われらはレギオン2 アザーズとの遭遇 (ハヤカワ文庫SF) もあわせてお勧めします。)

先日、会社で同僚の何人かと一緒にDHHのAction Textを紹介するYouTube動画を見ました。( Alpha preview: Action Text for Rails 6 )見るだけではつまらないので実際に試したいと思います。

Action Text とは?

Action Text とは、Rails 6.0 で予定されている新機能の1つです。リッチテキストを編集・表示するコンポーネントをページ内に簡単に組み込むことができます。

Basecamp で開発されてきたものを gem として抽出したものです。リッチテキストの扱う部分の主な技術は、trix というJavaScriptライブラリです。これもBasecampで開発されたライブラリです。

Action Text を試してみる

Action Text をDHHの紹介動画と同じように試してみます。Rails 5.2 が使える環境を前提としています。他には、imagemagickとyarnが使えるようになっている必要があります。

アプリケーションの作成

アプリケーションを作成します。そして、作成したアプリケーションのディレクトリに移動します。

$ rails new sample
...
$ cd sample

開発版のrailsに更新

Active Storage で必要な機能が最新版にしかないので開発版のrailsに更新します。また、ついでにwebpackerを追加します。Gemfile を以下のように変更して、bundle install します。

diff --git a/Gemfile b/Gemfile
index 8692b33..5826e6d 100644
--- a/Gemfile
+++ b/Gemfile
@@ -4,7 +4,7 @@ git_source(:github) { |repo| "https://github.com/#{repo}.git" }
 ruby '2.5.1'

 # Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
-gem 'rails', '~> 5.2.1'
+gem 'rails', github: 'rails/rails'
 # Use sqlite3 as the database for Active Record
 gem 'sqlite3'
 # Use Puma as the app server
@@ -35,6 +35,7 @@ gem 'jbuilder', '~> 2.5'

 # Reduces boot times through caching; required in config/boot.rb
 gem 'bootsnap', '>= 1.1.0', require: false
+gem 'webpacker', github: 'rails/webpacker'

 group :development, :test do
   # Call 'byebug' anywhere in the code to stop execution and get a debugger console

そして、webpacker を使えるようにします。

$ bundle exec rails webpacker:install

そして、app/views/layouts/application.html.erb を以下のように変更します。

diff --git a/app/views/layouts/application.html.erb b/app/views/layouts/application.html.erb
index cf19a4b..c0e1732 100644
--- a/app/views/layouts/application.html.erb
+++ b/app/views/layouts/application.html.erb
@@ -5,8 +5,8 @@
     <%= csrf_meta_tags %>
     <%= csp_meta_tag %>

-    <%= stylesheet_link_tag    'application', media: 'all', 'data-turbolinks-track': 'reload' %>
-    <%= javascript_include_tag 'application', 'data-turbolinks-track': 'reload' %>
+    <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
+    <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
   </head>

   <body>

Action Text のインストール

Action Text をインストールします。Gemfile を以下のように変更して、bundle install します。

diff --git a/Gemfile b/Gemfile
index 5826e6d..5739b2d 100644
--- a/Gemfile
+++ b/Gemfile
@@ -37,6 +37,9 @@ gem 'jbuilder', '~> 2.5'
 gem 'bootsnap', '>= 1.1.0', require: false
 gem 'webpacker', github: 'rails/webpacker'

+gem 'actiontext', github: 'rails/actiontext', require: 'action_text'
+gem 'image_processing', '~> 1.2'
+
 group :development, :test do
   # Call 'byebug' anywhere in the code to stop execution and get a debugger console
   gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]

そして、Action Text を使えるようにします。

$ bundle exec rails action_text:install
...
$ bundle exec rails db:migrate
== 20181231000000 CreateActiveStorageTables: migrating ========================
-- create_table(:active_storage_blobs)
   -> 0.0047s
-- create_table(:active_storage_attachments)
   -> 0.0043s
== 20181231000000 CreateActiveStorageTables: migrated (0.0092s) ===============

== 20181231000001 CreateActionTextTables: migrating ===========================
-- create_table(:action_text_rich_texts)
   -> 0.0042s
== 20181231000001 CreateActionTextTables: migrated (0.0043s) ==================

ここで3つのテーブルが作成されます。テーブル名からaction_text_rich_textsにリッチテキストが格納されるようです。

Post モデルを作る

リッチテキストを格納するPostというモデルをscaffoldを使って作成します。

$ bundle exec rails generate scaffold Post title:string
...
$ bundle exec rails db:migrate
...

そして、この例のようにリッチテキストを追加できるように以下のように変更していきます。

diff --git a/app/controllers/posts_controller.rb b/app/controllers/posts_controller.rb
index 21c2d4e..d566eaf 100644
--- a/app/controllers/posts_controller.rb
+++ b/app/controllers/posts_controller.rb
@@ -69,6 +69,6 @@ class PostsController < ApplicationController
 
     # Never trust parameters from the scary internet, only allow the white list through.
     def post_params
-      params.require(:post).permit(:title)
+      params.require(:post).permit(:title, :content)
     end
 end
diff --git a/app/models/post.rb b/app/models/post.rb
index b2a8b46..6015acb 100644
--- a/app/models/post.rb
+++ b/app/models/post.rb
@@ -1,2 +1,3 @@
 class Post < ApplicationRecord
+  has_rich_text :content
 end
diff --git a/app/views/posts/_form.html.erb b/app/views/posts/_form.html.erb
index ed01b8b..caeb58d 100644
--- a/app/views/posts/_form.html.erb
+++ b/app/views/posts/_form.html.erb
@@ -16,6 +16,11 @@
     <%= form.text_field :title %>
   </div>
 
+  <div class="field">
+    <%= form.label :content %>
+    <%= form.rich_text_area :content %>
+  </div>
+
   <div class="actions">
     <%= form.submit %>
   </div>
diff --git a/app/views/posts/show.html.erb b/app/views/posts/show.html.erb
index 947ae98..6584299 100644
--- a/app/views/posts/show.html.erb
+++ b/app/views/posts/show.html.erb
@@ -4,6 +4,7 @@
   <strong>Title:</strong>
   <%= @post.title %>
 </p>
+<%= @post.content %>
 
 <%= link_to 'Edit', edit_post_path(@post) %> |
 <%= link_to 'Back', posts_path %>

has_rich_text とか form.rich_text_area が、Action Textによって追加されたメソッドです。

リッチテキストを編集する

Railsサーバーを起動して、実際にリッチテキストを編集してみます。サーバーを起動したら、http://localhost:3000/posts にアクセスして、"New Post" をクリックします。

$ bundle exec rails sever
...
[Webpacker] Compiling…
...

[Webpacker] Compiling… の表示から、webpacker が動作していることが分かります。

<%= form.rich_text_area :content %> と記述した部分にリッチテキスト用のウィジェットが表示されていると思います。ツールバーでテキストを太字にしたり取り消し線を追加することができます。また、画像はドラッグドロップして追加することができます。

f:id:eitoball:20181116131329g:plain
画像をドラッグドロップして追加する

最後に

動画と同じようにさっとリッチテキストに対応ができました。Action TextのGitHubのページには、Action Text is destined for inclusion in Rails 6, which is due to be released some time in 2019. と記載されています。来年のリリースが楽しみです。

採用

Misocaでは、RailsやRubyの新しい機能に興味あるエンジニアも募集しています。

www.wantedly.com

Misoca に必要なことを全て受入プロジェクトで学ぼうとしたら驚いた

こんにちは、@mallowlabs です。 10月から Misoca にジョインし、現在は東京からリモートワークをしています。 入社日に台風の影響で新幹線が止まってしまい、初日から休みそうになりましたがなんとか入社できました。

Misoca では入社後、受入プロジェクトに配属されて、仕事の進め方を学んでいきます。私の場合には、@zetta1985Misocaに必要なことは全て受入プロジェクトで学んだ という記事を熟読してからプロジェクトに望んだので進め方のイメージはあったのですが、それでもいくつか驚いたことがあるので紹介したいと思います。

ということで先に以下の記事を読んでおくと読みやすいです。 tech.misoca.jp

受入担当はフルリモート勤務

私は東京で働いていますが、受入プロジェクトのはじめの2週間は名古屋の Misoca のオフィスで働きます。 ですが、なんと受入担当はフルリモート勤務の方です。 Slack や Zoom を使ってやりとりし、ペアプログラミングも Slack で画面共有しつつ、Visual Studio Code の Live Share を使って行いました。

最初の印象としては「名古屋に滞在してるのに名古屋勤務の人と一緒に仕事しないの!?」と少し驚きましたが、Misoca はリモートでもオフィスでもどちらでも普通に働ける環境を作っているので、最初の段階でリモートを前提にした働き方を学べたのでとてもよかったです。

以前はオフィス勤務の人が受入をしていたようですが、リモートの人が受入をやってもいいよね?という感じでフルリモートの人も受入をやるようになったそうです。

1ヶ月プロジェクトの前に数日で終わる小さなプロジェクトがある

Misocaに必要なことは全て受入プロジェクトで学んだ ではいきなり1ヶ月のプロジェクトに配属されていたので、そういう心持ちでのぞみました。 ですが、実際には簡単なエラーメッセージの修正を行う小さなプロジェクトから始まりました。

このプロジェクトでは、GitHub を使った開発の進め方の説明や、ヘルプページの変更をどのように進めていくかなど、開発やリリースプロセスの学習をしました。 Ruby はもちろん GitHub を仕事で使うのも初めてだったので、基本的なところから確認ができました。

いきなり1ヶ月のプロジェクトをやるつもりで入社したので、こういうチュートリアルを兼ねたプロジェクトがあるのはとても助かるなと思いました。

受入プロジェクトで画面を変えることもある

Misocaに必要なことは全て受入プロジェクトで学んだ では

  • 実装難易度が低い
  • UIに影響を与えない(見た目の変更がない)
  • DBマイグレーションが必要
  • データマイグレーションが必要
  • 運用担当との調整が必要

といった特性が挙げられていましたが、私の場合には以下のような特性のプロジェクトでした。

  • 実装難易度が低い
  • UI を変更する
  • UI をどうするかは詳細は決まっていない(仕様の調整から始まる)
  • DB マイグレーションは必要
  • 運用担当との調整が必要

「受入プロジェクトなのでまずは裏側から触るのかー」と思っていただけにこれも驚きでした。 入社していきなりいろんな人との仕様の調整を行うのは正直大変でしたが、受入担当の方がリードしてくださったのでなんとかなりました。

「一つのやり方にこだわらず、いろいろやってみる」という Misoca の文化がこういうところにも出ているのだと感じています。

数日のプロジェクトでもふりかえりをしっかりやる

Misoca ではふりかえりをとても大切にしています。 前述のエラーメッセージを修正するだけの簡単なプロジェクトでも、プロジェクト終了後に「事後検証」と呼ぶ、「何か学びはあったか?」をふりかえるイベントを実施しました。

正直な印象として「こんなに小さなプロジェクトでも事後検証をするんだな」と思いながら参加していましたが、受入プロジェクトの中でわかりづらかったことや、不安に感じたことを共有したら、それが学びとして記録・共有され、それを解消するような対応(今回は esa 記事の修正や受入フローの改善)がすぐに行われました。

Trello で振り返り:

f:id:mallowlabs:20181107134329p:plain:w320

esa を修正:

f:id:mallowlabs:20181107134344p:plain

代表の豊吉が 「PDCAって本当にまわるんだ〜」 と何度も思うと言っていましたが、まさに同じ気持ちになり、Misoca のプロセス改善へのしっかりとした取り組みに驚きました。

まとめ

私が受入プロジェクトで感じた驚きを記事にしてみました。 受入プロジェクトを通して Misoca の常に改善していくやり方を体感でき、驚きつつも Misoca の文化やプロセスを学べたと思います。 受入プロジェクトについて @zetta1985 の場合とは少し違った角度から紹介できていれば幸いです。

採用

Misoca では受入プロジェクトだけでなく、プロセスや、そして世の中を改善していきたいエンジニアを募集しています!

www.wantedly.com

わかった気になれるKaggle入門

こんにちは。 開発者ブログに初めて投稿します。id:toyoshi です。 先週Misoca社のSlackの褒めチャンネルを紹介しましたが、私があそこで褒められたことがあるのは「Zoomでスペースを押してる間ミュートが解除されるようになるオプションを教えた」「アンケートの質問を考えるのが早い」の2点です。本来の仕事の方でも褒められていきたいです!

さて、今回のエントリでは先日社内で開催したKaggleの勉強会の内容を紹介します。やったことがないと難しそうなイメージのあるKaggleですが実は入門だけなら知識ほぼ0でも大丈夫なのです。このエントリを参考にぜひ入門してみてください。

今回のゴール

Kaggleでアカウントを作り、コンテストに参加して、予測を提出するところまでを目指します。 環境の準備なし、プログラミングなし、統計の知識なしでKaggleの予測提出までの流れがわかるようになっています。

そもそもKaggleとは

データサイエンスプロジェクトのコンペ(Competition)をやっているWebサービスです。AtCoderのデータ分析版。企業主催のコンペもあり賞金が出ることもあります。

どんなコンペがあるか

どんなコンペが開催されているのか一部を紹介します。

アカウント作成からコンペチャレンジの流れ

まずは全体を把握しましょう。下記のような流れになります。

  1. アカウント作成
  2. コンペを選んで参加登録
  3. 提供されたデータを使って分析・予測をする
  4. 予測を提出。点数・順位がでる。
  5. 納得いくまで3に戻る
  6. コンペの結果が出る
  7. 2に戻る

アカウント作成

さっそくアカウント作成から始めましょう。無料です。 Kaggle: Your Home for Data Science

画面の基本(グローバルメニュー)

Kaggleはコンペをやるためだけのサービスというわけでもないのでグローバルメニューに色々あります。簡単に説明します。

f:id:toyoshi:20181101193700p:plain

Competitions・・・コンペ一覧
Datasets・・・配布されているデータセット一覧
Kernels・・・公開されているJupyter NotebookのKernel一覧
Discussion・・・ディスカッションの場
Learn・・・各種情報

コンペを選んで参加登録

まずはコンペを選んで参加登録します。Kaggleには入門者向けのコンペ「Titanic: Machine Learning from Disaster」が用意されていますので今回はそちらに参加します。

まずはコンペ一覧ページから検索するなどしてタイタニックのコンペを開きましょう。

Titanic: Machine Learning from Disaster | Kaggle

f:id:toyoshi:20181101194621p:plain

「タイタニック:〜大惨事で機械学習を学ぼう 〜」という入門用コンペです。内容としては乗船者のリストから生存者を予測するというものです。

個人的には乗船者の直接の家族はまだ当然存命なので不謹慎な気もしますが「Join Competition」を押して参加しましょう。

コンペのゴール

乗船した人のリストを使って、誰が生き残ったかそうでないかを予測します。 簡単にいうと死んだかどうかを0と1で表したCSVを作ってアップロードすればよいです。簡単そうでしょう?

なんかわからんけどまずは提出だ!

テスト駆動開発におけるRED、GREEN、REFACTORの考え方にしたがって、まずはいい加減な内容でいいので予測を提出してみましょう。 例えばこんなデータはどうでしょうか

スクリーンショット 2018-10-17 10.44.53.png (66.1 kB)

zero_fill_submission.csv (3.3 kB)

これは全員生き残らない(Survived=0)という予測ですね。

First submission

画面右の[Submit Prediction]から提出します。 すると即座にスコアと順位が表示されます。これを提出するとスコアは0.626です。正解率62.6%という意味ですね。つまり全員死亡で提出したので、タイタニックからの生還者はおよそ38%(1-0.626)しかいなかったということがわかります。

さあ、おめでとうございます!

スコアはそれほど良くないし、順位は低いですが、Kaggleでアカウントを発行し、コンペに参加して、予測を提出するという当初の目的をもう達成しました。

もう少しだけましなデータを送信してみよう

提供されているデータのところに、女性が全員生き残ると予測した場合のCSVというのが用意されているのでそれも提出してみましょう。

f:id:toyoshi:20181101200103p:plain

するとさっきのよりスコアがよくなるはずです。おそらく0.626から0.765とか。映画「タイタニック」にも救命ボートに女性や子どもを先に乗せていたシーンがありましたね。

さらに進めてやるには?

当日の勉強会ではさらに決定木を使って予測するデモもやりました。今回はやりませんが皆さんはもうKagglerですのであとは好きなようにデータを料理して高みを目指してください。次に紹介するようなサイトでは決定木や、ランダムフォレストといった手法の使い方をとてもわかりやすく解説してくれていますので参考になるでしょう。

まとめ

このエントリではKaggleのアカウントをつくり予測を提出するところまでをやりました。環境の準備なし、プログラミングなし、統計の知識なしでKaggleの全体像が掴めたかと思います。

タイタニックの事例が入門問題として素晴らしいのは有名な事故なので推理がしやすいということです。今回紹介した女性や子どもの方が生存率が高いということ以外にも、タイタニック号沈没事故 - Wikipediaなどを見ると1等船室の方が2、3等船室より生存率が高いことがわかったりもします。他の人のKarnelをみてみると、名前の敬称から特別な敬称の人は生き残りやすかったのではという仮説をたてたり、家族が多いと逃げ遅れやすいのではないかといった仮説を立てている人もいました。

さらに次のステップに進むには他の人が公開しているKarnelを読んでみたり、以前紹介した📚最近弊社で買ったデータ分析入門書📚 - Misoca開発者ブログの書籍を手にとってみてはいかがでしょうか。

採用

Misocaではサービスの改善のため仮説を立てる時や施策の検証などでデータ分析を使っています。データドリブンな改善に興味のあるエンジニアの皆様をお待ちしております!

www.wantedly.com

褒めるチャンネルを作ったらポジティブなフィードバックが集まって来て嬉しくなった話

Misoca開発メンバーの北村です。

先日Misocaの有志で岐阜県の金華山にハイキングに行きました。私は3歳の長男を連れて参加。 金華山は登山口からの標高差が300mほどで、子どもも楽しめる良い山でした。*1 これからの季節は天気が良ければ冠雪した御嶽山や南アルプスを眺めることができそうです。

f:id:RKTM:20181014113220j:plain

さて、子ども連れの登山・ハイキングで避けたいのは、山で「疲れた」「怖かった」というネガティブなイメージが子どもの心に残ってしまうこと。継続的に山に親しんでもらうためには、その登山が良い思い出、成功体験として刻まれて欲しいものです。

そのために私が実践していることは、「褒める」ことです。

登山口が見えるようなところまで登ったら「あんなところから登ったんだよ、すごいね!」、下山したら山頂を振り返り「あんな高いところまで頑張って登ったね!えらいね!」と褒めます。おかげで、今のところはお山に行くことは長男にとっても楽しい遊びとなっているようです。


さて、Misoca開発者ブログを読んでいるみなさんも、褒められると嬉しいですよね?

Misocaでメンバーを褒めるSlackチャンネルを作ったよ

MisocaではSlackにメンバーを褒めるチャンネル#praiseチャンネルが存在しています。

開発メンバーだけでなく、誰だろうと褒めます。仕事に直接関係あろうとなかろうと褒めます。

今日はMisocaの褒めチャンネルの模様をご紹介します。

褒められると嬉しい

電話応対力の高い人はすごい。電話苦手なエンジニア勢からするとリスペクトです。アプリのテストもやってくれていつも感謝しています。

f:id:RKTM:20181024183703p:plain

f:id:RKTM:20181025163247p:plain

技術の悩みも相談してもらったら感謝。

f:id:RKTM:20181024181156p:plain

メインの仕事とは関係ない貢献も、拾って感謝。 f:id:RKTM:20181024175747p:plain

ビジュアルテスト、最高です

コード変更の前後で意図しない見た目の変更がないかチェックしてくれるビジュアルテスト。安心してリリースできます。 f:id:RKTM:20181025163441p:plain

ビジュアルテストの詳細はこちらから。 tech.misoca.jp

リファクタの現状分析と取り組み方が判りやすかった。

f:id:RKTM:20181024180312p:plain

下記記事で解説されている色分けや取り組み方について、ポジティブなフィードバック。 tech.misoca.jp

色々と褒め&感謝

モバイルエンジニアもサーバーに入ってコマンドを実行できるようになって、作業がスムーズに。 f:id:RKTM:20181026100637p:plain

1日に3praise獲得。MVPです。 f:id:RKTM:20181026100742p:plain

Misocaのパフォーマンスが改善しました。キビキビ動いて最高です。対応してくれてありがとう! f:id:RKTM:20181024182009p:plain

分担していこうという決意表明。

f:id:RKTM:20181024182126p:plain

ドキュメントを書くには手間がかかりますが、後からペイします。 f:id:RKTM:20181026101324p:plain

助け合い、大事

困ったら声を上げる➞皆が助ける、という流れ。

f:id:RKTM:20181024180756p:plain

助け舟を差し出せるって素敵。 f:id:RKTM:20181026101504p:plain

属人的な対応から、仕組みで改善していくきっかけへ

f:id:RKTM:20181026104727p:plain

自分で自分を褒めてもいいんですよ

いい仕事したら自分を褒めていこう。

f:id:RKTM:20181024181330p:plain

トラブルシュート、臨機応変に動かないといけないし、旗振り役を買って出るのはなかなかプレッシャーがあるから大変です。自分で自分を褒めたい(というか褒めた)。

f:id:RKTM:20181024184139p:plain

文脈がないと他の人にわからないので注意

理性とは?

f:id:RKTM:20181024180251p:plain

神?すごーい?

f:id:RKTM:20181024181524p:plain

最後に

皆さんの職場では、メンバーを褒めていますか?メンバーから褒められていますか?Misocaではこれまでご紹介してきた通り、活発に褒めたり褒められたりしています。

個人的に嬉しいことは、「誰も拾わないこぼれ球タスクで、自分も積極的にはやりたくないけど状況的に自分がやるしかないなー」というタスクを拾ったことを感謝されることです。貢献を評価してくれる人がいれば、気分良く働けます。

採用

Misocaでは、褒めたい/褒められたいエンジニアを募集しています!

www.wantedly.com

*1:金華山は低山と言えど、馬の背ルートなど、危険なルートもあるのでご注意ください

Android版Misocaのマルチモジュール対応

こんにちは!アバター化して可愛くなったこまたつです!!
この前オフィスに来たお客さんに「声はオッサン」て言われたのですが、最近ボイチェンカラオケにハマっていて声も可愛くなってきました。

みなさんのプロダクトはマルチモジュール対応してますか?

InstantAppやDynamicDeliveryなど、新たに追加される機能はマルチモジュール前提のものも多く、強めの圧を感じるようになってきましたね。
今回はMisocaのAndroidアプリでどんな感じにマルチモジュールの対応を行っているかを共有します。
ライブラリ以外のマルチモジュール初挑戦だったので理解の浅い部分が多いのですが、みなさんからの優しいつっこみお待ちしております。

Misocaは請求書作成をメインとしたサービスですが、請求書以外にも業務フローに合わせて見積書や納品書を作成できます。
Androidアプリでは先日のv3.0リリースでこの3種類すべてに対応しました。
文書はそれぞれ微妙に異なっていて、たとえば郵送ができるのは請求書だけという作りになっています。
そこで、次のようなモジュール構成を考えました。

f:id:komatatsu:20181019144328p:plain

これを考えたときには実はまだ見積書と納品書の機能は存在しておらず、ひとつのモジュールに請求書とログインなどの機能が入っている状態でした。
先行するiOS版に比べて機能的に貧弱ということもあり、ひとまず次の形で見積・納品書の機能を追加することにし、請求書の分離作業は後回しにしました。

f:id:komatatsu:20181019144921p:plain

これらの機能は新規に追加されるコードだったので穏便に分割することができました。
それと同時に新たな問題点が見つかりました。
アプリには取引先に紐づく各文書をタブで切り替えて見られる画面があります。

f:id:komatatsu:20181019144423p:plain

この画面があるせいで、処理を完全に分割するのが難しくなってしまいました。
この画面はbaseモジュールに入っていますが、baseを見積書や納品書のモジュールが参照しているため、逆向きの参照が入れられません。
またモジュールをまたぐ画面遷移とモジュール内の画面遷移でIntentの取得方法が変わり複雑度があがってしまいました。
コードを書くときはなるべくモジュールを気にせずに書ける様にしたいです。
これらはまだ解決方法を模索中ですが、ほかにも小さな問題をいくつか解決しました。

BuildFlavorsで設定したapplicationIdがBuildConfigから取れない

取れない(つらい)
仕方ないので activity.packageName を使うように書き換えました

AndroidManifestを分割しなかったのでテストがこける

全部appに書かれたままほっといたらInstrumentation Testがコケるようになってました。
モジュールごとに適切に分割することで解決しました。

proguardのminifyをかけると動かなくなる

packageは変えてないのですがentity類をbase moduleに移動したら、引数なしのコンストラクタが無いエラーが出るようになってしまいました。
entityは基本的にkotlin data classを使っているのですが、今まではGsonがUnsafeを使って処理していたものがminifyによってうまく動かなくなったみたいです。
一次対応としてproguardのルールを変更しましたが、ちゃんと引数なしのコンストラクタを作ってあげたほうが良さそうです。

そんな感じで、まだまだいろいろ問題が出てきそうな雰囲気を感じます。
モジュールの分け方も文書ごとに分けるのではなくもっと適切な分割方法があるのでは?などとissueを立てて議論しています。
アプリを成長させて行くためにも開発しやすい状態を作るのが重要だと思います。
ただ分割しただけでは何も始まらないので、これから試行錯誤を繰り返しつつ少しずつ馴染んで行きたいと思います。

採用

Misocaに興味のある方はぜひフォローしてくださいね