コネヒト開発者ブログ

コネヒト開発者ブログ

potatotips #64に参加・LTしてきました

こんにちは!エンジニアの柳村です。

2019/8/27に開催されたpotatotips #64 に参加・LTしてきました。

potatotips.connpass.com

今回の会場はReproさんでした。 代々木駅から出てすぐの好立地で、おしゃれな内装でしたよ(写真を取り忘れました・・

iOS関連の発表について簡単にレポートします。

Object指向でFatViewControllerをなくす

@coffeegyunyuさん

StoryboardにObjectを配置してViewControllerの代わりにこちらで処理をさせる方法についてでした。StoryboardのObjectってなんに使うのかあまりわかってなかったのですが、ようやく使い方が判明してすっきりしました。

コントロールセンターとたたかう

@5mingame2さん

ゲームの操作中にコントロールセンターがでてきちゃうのを防ぐ方法について紹介されていました。ブースでいろんな人に試遊してもらって想定外の操作がされていないか観察するという試みはとてもいいなと思いました。

Conditional Content in SwiftUI

@yanamura_

SwiftUIで条件によってViewを出し分ける方法となぜその方法だとうまくいくのかについてお話しました。 私の個人のブログのほうでも書いてますのでよろしければご参照ください。

ちなみにママリではまだSwiftUIは使ってませんが、移行していきたい気持ちです!

iPhoneでFeliCaを読み取ってみた

@tanakasan2525さん

いろんな種類のFeliCaの読み込みを簡単にするライブラリをつくられたそうです。FeliCaの読み込み使ったアプリを作るのが楽になる便利ライブラリのようでした。

DIKitで人間がクラス間の依存関係解決するのを終わらせる

@yuuxenoさん

DIKitで依存関係の実装コードを自動生成することについて紹介されていました。人の手で実装するとどうしてもミスはしてしまいがちなので自動化できるところは自動化していくというアプローチはとてもいいなと思いました。

SwagGenのススメ

@yuta24さん

<<資料は公開されたら反映します>>

OpenAPIで書いたAPI定義からSwagGenを使ってコードの自動生成について紹介されていました。swagger-codegenと比較してtemplateが良い感じのようでした。

macOS アプリを2年ぶりにメンテしたら原型がなくなった話

@AkkeyLabさん

個人で開発していたmacOSのアプリをFluxを採用したりAnalyticsを導入したりして書き換えた際のTipsを紹介されていました。Firebase AnalyticsがMacアプリには対応してないというのは意外でした。

Flutter Pluginを作る

@konyavicさん

ReproのSDKのFlutter対応版をつくられたときのtipsを紹介されていました。Cordovaとかと比べるとFlutterのpluginはとても簡単につくれるとのことでした。

さいごに

わたしは子育てがあって最近はなかなか勉強会に参加できないのですが、久しぶりに参加してLTしたり懇親会でいろんなひととお話したりできてとても楽しかったです!また、参加できないときもpotatotipsはLT資料をアップロードしてくださる発表者が多くてとても助かっています!

ここで突然のお知らせです!

なんと、きたる2020年2月には弊社コネヒトにてpotatotips #67が開催予定です!!!

ぜひLTしにきてくださいね!お楽しみに!!!

コネヒトはiOSDC Japan 2019に協賛いたします!

こんにちは、iOSアプリエンジニアのあぼ(@suxisuxido)です!

本日は、iOSアプリ開発者の祭典iOSDC Japan 2019に協賛するお知らせです。

コネヒトはiOSDC Japan 2019に協賛いたします!

iOSDC Japan 2019に、シルバースポンサーとTシャツスポンサーとして協賛いたします。Tシャツがどんな仕上がりなのか、今から楽しみでワクワクです!

iosdc.jp

スポンサーするにあたって、コネヒトは「人の生活になくてはならないものをつくる」というミッションを掲げているので、技術コミュニティについても同様に、サポートして一緒に盛り上げていくことができたら、と思っております。*1

イベント概要

  • 開催 2019年9月5日(木)~9月7日(土)
  • 場所 早稲田大学 理工学部西早稲田キャンパス63号館
  • 対象 iOSおよび関連技術のエンジニア
  • タイムテーブル https://fortee.jp/iosdc-japan-2019/timetable
  • 主催 iOSDC Japan 2019 実行委員会 (実行委員長 長谷川智希 @tomzoh ) / WASEDA-EDGE人材育成プログラム

iOSアプリ開発者の興味がわくような発表テーマが目白押しなので、チェックしてみてください。メインの発表だけでなく、9月6日(金)と9月7日(土)は、突然思いついたネタをその場で発表できるようなアンカンファレンスが開催されます。また9月6日(金)のLT終了後、よくあるアルコール片手の懇親会ではなく「茶会」という形で参加者同士が交流できる企画もあるそうです!楽しみです!

iOSDCトークンはこちら!

#コネヒトとiOSDC

iOSDCチャレンジで使うトークンです!すごく楽しそうな企画ですので、まだの方はチェックしてみてください。

iOSDCには私とiOSアプリエンジニアのyanamuraが参加予定ですので、会場でお会いした際にはぜひお話しましょう!

Kotlin Fest 2019に参加しました!

2017年11月にAndroidエンジニアとしてjoinした関根です! 2019年8月24日に開催されたKotlin Fest 2019に参加してきました! 今回の記事では、私が聞いた公演を感想をおりまぜて紹介させて頂きます。

f:id:katsutomu0124:20190827142731p:plain

弊社はスポンサーとしての参加に加え、改めて学ぶContractsという内容で弊社富田が登壇をさせていただきました。 余談ですが、スポンサー参加や登壇への弊社の意思の一端が現れたこちらの記事を是非とも合わせてお読みください!!

tech.connehito.com

オープニングセッション

さて、肝心のKotlin Festは、長澤太郎さんの挨拶とSvetlana Isakovaさんのオープニングセッションで幕が上がりました。

Svetlana IsakovaさんはJetBrains所属のエンジニアであり、世界で1番Kotlinに詳しい一人です。 そんな彼女からKotlinの新機能について紹介をしていただきました。 スライドを読み進めていくと、Contractsも紹介がありました。Contractsという機能は、富田の講演テーマでもあり、実際に当日はこのオープニングセッションでも言及しご紹介いただきました! Svetlanaさん誠にありがとうございました!!!

Kotlin コルーチンを理解しよう 2019

最初は、弊社でも今後の利用を検討しているCoroutineを理解するべく、八木俊広さんによる講演を聴講しました。

Kotlin Coroutineの基礎をわかりやすく解説していただいたことに加えて 設計の方針とCoroutineのテストのアプローチまで幅広くお話を聞けました。 特にCoroutineのテストはブロッキング処理が絡むこともあり、実践的なアプローチの内容が聞けて非常に学び深かったです。 八木さん、貴重なお話をありがとうございました!

改めて学ぶContracts

続いて、応援の為、富田の講演を聴きに行きました。

speakerdeck.com

本人はとても緊張をしていたようですが、蓋を開けてみれば非常に好評を頂き、会場には笑いが溢れており流石の富田という講演でした。 当日の登壇のために社内2回のリハーサルをして臨んだのですが、社内メンバーからのFBも反映されており、限られた時間の中で、最後まで手を抜かずに良いものを届ける富田の人柄を再認識しました。 ちなみに余談ですが、社内のランチイベントでは、Kotlin Fest当日の講演のように彼の話でメンバーは笑わせてもらっています。 トミーさん登壇お疲れ様でした!(社内ではトミーさんと呼ばれています)

サーバーサイドKotkinでGraphQLをやってみよう

続いて、弊社でも度々話題になるGraphQLについて学ぶべく、しらじさんによる講演を聴きに行きました。

speakerdeck.com

GraphQLの基礎からKotlinでの記述方法に加え、プロダクションで必要になる認証情報の扱い方など導入に到るまでのガイドラインのようなお話でした。 個人的に、印象的だったのが、GraphQLでのテストについてクラスを綺麗に分けることが前提なのでmockすればOKという結論が印象的でした! 聴講者を巻き込みながら、会場を盛り上げるしらじさんの講演は得るものが多く楽しく学ばせて頂きました。 しらじさん、貴重なお話をありがとうございました!

フロントエンドもKotlinで書きたい! -WebページをKotlin/JSで作った軌跡-

普段フロントエンドを触る機会が少ないので興味を持ち、にしこりさぶろ〜さんの講演を聴きに行きました。

speakerdeck.com

Kotlin/JSには無知識で参加したのですが、サンプルアプリをもとに解説していただいて丁寧でわかりやすい講演でした。 すでにKotlin/JSで2つのサイトを作られていて、導入する上での注意点などにも触れて頂き、非常に説得力の高いお話でした Kotlin/JSはまだまだ情報が少ないので、みんなでアウトプットして行こうというメッセージはコミュニティを活性化する大事なメッセージだと思いました。 にしこりさぶろ〜https://blog.hatena.ne.jp/connehito/connehito.hatenablog.com/edit?entry=26006613406773967#さん、貴重なお話をありがとうございました!

Kotlin/Nativeはなぜ動くのか

最後に、Kotlin1.3の目玉の一つと言えるKotlin/Nativeの中身を理解するために荻野陽太さんの講演を聴きに行きました。

speakerdeck.com

ネイティブバイナリに変換される過程をステップごとに解説するお話で、学問的な内容に感じておりましたが、丁寧に解説していただいたおかげでよく理解できました。 今回のお話の内容の理解が深まったことで、個人的な学びに加え、Kotlin/Nativeの様なプラットフォーム非依存の技術の知識を社内に持ち込めるきっかけを頂きました! 荻野さん貴重なお話をありがとうございました!

Kotlin Festに参加して感じたこと

その他、聴講以外の感想に触れて本記事を終了したいと思います。

スタッフの運営スキルが高い

まず感じたことはKotlinFestに関わるスタッフの運営スキルが高いことでした。 誘導が非常に丁寧で、会場の移動もスムーズに行うことができました。 また富田の登壇時もアテンドも非常に真摯にご対応いただきました。 スタッフの皆様、当日お疲れ様でした!ありがとうございました!

コミュニティ運営を愛している

クロージングの際に、主催の長澤 太郎さんから案内があり、Kotlinコミュニティの主催者を壇上にあげ、1分間のアピールを募るという時間がありました。 JKUG以外のKotlinコミュニティを盛り上げていこうと言う長澤さんのメッセージと、それを暖かく迎える参加者の皆様から、Kotlinとコミュニティを盛り上げていこうと言う愛を感じられた一幕でした。 長澤さんを初めとした主催の皆様と参加された皆様。当日はありがとうございました!

最後に

改めて、主催の長澤さんを初めとした運営の皆様、登壇者の皆様、当日参加された皆様、本当にお疲れ様でした! 次回は私も登壇をできる様に精進いたします!また来年よろしくお願いします!

swift-formatで自動コード整形

こんにちは!エンジニアの柳村です。

前回SwiftFormatの導入について紹介しましたが、今回はswift-formatについて紹介します。

ここではappleのほうのswift-formatの使い方を紹介していきます。ただこちらはSwift 5.1以上に対応しているので、Swift 5.0向けにgoogleのforkのほうのswift-formatの使い方も紹介しますがこちらはあまりオススメできません。

インストール

各プロジェクト個別にswift-formatをインストールすることを前提にします。もしグローバルにインストールしたい場合はmintもしくはNSHipsterのforkをhomebrewでインストールしてください。

プロジェクトのルートディレクトリで以下を実行してswift-formatを実行可能な状態にします。

※ 事前にxcode-selectなどでXcode11を指定してください

$ git clone git@github.com:apple/swift-format.git swift-format
$ cd swift-format
$ swift build -c release
$ cd ..

設定

以下のコマンドを実行してデフォルトのフォーマットの設定を.swift-formatに書き出します。

$ swift-format/.build/release/swift-format --mode dump-configuration > .swift-format

swift-format実行時にこの.swfit-formatに書いた設定に基づいてフォーマットされます。 デフォルトはこのようになっています。

{
  "blankLineBetweenMembers" : {
    "ignoreSingleLineProperties" : true
  },
  "indentation" : {
    "spaces" : 2
  },
  "lineBreakBeforeControlFlowKeywords" : false,
  "lineBreakBeforeEachArgument" : true,
  "lineLength" : 100,
  "maximumBlankLines" : 1,
  "respectsExistingLineBreaks" : true,
  "rules" : {
    "AllPublicDeclarationsHaveDocumentation" : true,
    "AlwaysUseLowerCamelCase" : true,
    "AmbiguousTrailingClosureOverload" : true,
    "AvoidInitializersForLiterals" : true,
    "BeginDocumentationCommentWithOneLineSummary" : true,
    "BlankLineBetweenMembers" : true,
    "CaseIndentLevelEqualsSwitch" : true,
    "DoNotUseSemicolons" : true,
    "DontRepeatTypeInStaticProperties" : true,
    "FullyIndirectEnum" : true,
    "GroupNumericLiterals" : true,
    "IdentifiersMustBeASCII" : true,
    "MultiLineTrailingCommas" : true,
    "NeverForceUnwrap" : true,
    "NeverUseForceTry" : true,
    "NeverUseImplicitlyUnwrappedOptionals" : true,
    "NoAccessLevelOnExtensionDeclaration" : true,
    "NoBlockComments" : true,
    "NoCasesWithOnlyFallthrough" : true,
    "NoEmptyAssociatedValues" : true,
    "NoEmptyTrailingClosureParentheses" : true,
    "NoLabelsInCasePatterns" : true,
    "NoLeadingUnderscores" : true,
    "NoParensAroundConditions" : true,
    "NoVoidReturnOnFunctionSignature" : true,
    "OneCasePerLine" : true,
    "OneVariableDeclarationPerLine" : true,
    "OnlyOneTrailingClosureArgument" : true,
    "OrderedImports" : true,
    "ReturnVoidInsteadOfEmptyTuple" : true,
    "UseEnumForNamespacing" : true,
    "UseLetInEveryBoundCaseVariable" : true,
    "UseOnlyUTF8" : true,
    "UseShorthandTypeNames" : true,
    "UseSingleLinePropertyGetter" : true,
    "UseSpecialEscapeSequences" : true,
    "UseSynthesizedInitializer" : true,
    "UseTripleSlashForDocumentationComments" : true,
    "ValidateDocumentationComments" : true
  },
  "tabWidth" : 8,
  "version" : 1
}

設定項目についてはdocumentに説明が書いてありますがruleについては詳細にかかれていないのでルール名から察するしかありません。

実行

以下のコマンドでコードをフォーマットできます。

$ swift-format/.build/release/swift-format -r ソースコードのフォルダのパス -i
  • -r で指定したフォルダ内を再帰的にswiftのファイルを探します。個別のファイルを指定したい場合は-rは不要です。
  • -i を指定するとswiftのファイルをフォーマットします。(これを指定しないとコンソールにフォーマット結果が出力されるだけです)

その他のオプションについては以下をご参照ください。

OVERVIEW: Format or lint Swift source code.

USAGE: swift-format [options] <filename or path> ...

OPTIONS:
  --configuration         The path to a JSON file containing the configuration of the linter/formatter.
  --in-place, -i          Overwrite the current file when formatting ('format' mode only).
  --mode, -m              The mode to run swift-format in. Either 'format', 'lint', or 'dump-configuration'.
  --recursive, -r         Recursively run on '.swift' files in any provided directories.
  --version, -v           Prints the version and exists
  --help                  Display available options

POSITIONAL ARGUMENTS:
  filenames or paths      One or more input filenames

実行してみるとわかりますが、プロジェクト全体にかけると結構遅いです。(ママリだと1分かかりました)

また、exclude directoryとかの指定ができないので3rd Partyのソースコードなどがあった場合に特定のディレクトリのみを除外するといったことができません。

これではちょっと頻繁に実行するのはちょっと厳しいです。

そこで以下のように差分のあるswiftのファイルのみをswift-fomatに食わせるようなスクリプトをprojectのbuild phasesやgitのprecommit hookに設定するといい感じになると思います。

$ git diff --name-only | grep .*\.swift$ | xargs swift-format/.build/release/swift-format -i

まとめ

Swift 5.1以降に限定されますがswift-formatでフォーマットできました。

swift-formatは2019年8月現在まだreleaseは一つもされてないのでまだこれからといった感じはしますが、ママリのアプリではXcode11およびSwift 5.1に対応するタイミングくらいに導入しようかと考えています。

------✂------✂------✂------✂------✂------

オマケ:Swift 5.0でswift-formatを使いたい場合

Swift 5.1でやる場合との違いはインストールです。

インストール

googleのswiftのforkの特定のコミットを利用します。

$ git clone git@github.com:google/swift.git swift-format
$ cd swift-format
$ git checkout 74995aa1473b213977a14c0cb477ce89875ee27b
$ git submodule update --init
$ swift build -c release
$ cd ..

あとはSwift 5.1の手順と同じです。

実行結果

ただappleのと比べると実行結果には違いがあります。(5.0で動かすために古いコミットを指定しているのが原因なのですが)

例えばRxSwiftのインデントがこんな感じになってしまいます。。 たぶん不具合でrespectsExistingLineBreaks の指定が効いていないのではないかなと思います。

-        cameraButton.rx.tap
-            .flatMapLatest { [weak self] _ in
-                return UIImagePickerController.rx.createWithParent(self) { picker in
-                    picker.sourceType = .camera
-                    picker.allowsEditing = false
-                }
-                .flatMap { $0.rx.didFinishPickingMediaWithInfo }
-                .take(1)
-            }
-            .map { info in
-                return info[.originalImage] as? UIImage
-            }
-            .bind(to: imageView.rx.image)
-            .disposed(by: disposeBag)
+        cameraButton.rx.tap.flatMapLatest { [weak self] _ in
+            return UIImagePickerController.rx.createWithParent(self) { picker in
+                picker.sourceType = .camera
+                picker.allowsEditing = false
+            }.flatMap { $0.rx.didFinishPickingMediaWithInfo }.take(1)
+        }.map { info in
+            return info[.originalImage] as? UIImage
+        }.bind(to: imageView.rx.image).disposed(by: disposeBag)

あと@unknown default@unknowndefault になってしまうバグがあってコンパイルに通らなくなってしまったりするのでお気をつけください。

コネヒトは技術コミュニティになくてはならない開発組織を目指すために「ス・マイル制度」をはじめました!

こんにちは!CTOの@itoshoです。いきなりですが、今日はコネヒトで新たに発足した「ス・マイル制度」のお披露目をしたいと思います!

tl:dr

  • ス・マイル制度という新しい取り組みをはじめました!
  • 目的は…
    • 技術コミュニティに貢献したい
    • そのためにコネヒトらしい手法でアウトプットの支援を実現したい
  • コネヒトらしい手法とは…
    • アウトプットに対して、マイルという報酬を個人ではなくチームに発生させる
    • マイルはチームの共有資産として誰でも自由に使うことが出来る
    • マイルをどう活用すれば、チームが成長するかを全員で議論する

ス・マイル制度のロゴ

ス・マイル制度とは?

一言で言うと、アウトプット支援的な制度なのですが、従来のアウトプット支援制度と違うのはアウトプットに対して、直接インセンティブを払うのではなく、一度「マイル」という形で開発部*1に貯金される点です。そして、ス・マイル制度ではその貯めたマイルを誰でも自己研鑽のために自由に使うことが出来ます。

例えば、あるエンジニアがOSSにコントリビュートをすると一定のマイルが貯まります。そうすると別のエンジニアはそのマイルを利用して、海外のカンファレンスのチケットを買うことが出来るようになります。

f:id:itosho525:20190821230230p:plain

ス・マイル制度で実現したいこと

このス・マイル制度は、僕がCTOに就任する少し前*2から構想を練り始めた制度です。コネヒトは以前からアウトプットを推奨しており、KotlinやCakePHPのコントリビューターが在籍しています。しかし、推奨はしていたものの、特に会社として目に見える形で支援していたわけではありませんでした。ですので、CTOになったタイミングで会社としてちゃんとアウトプットを支援・評価したいと思ったのが、ス・マイル制度を立ち上げたきっかけです。

また、これまでコネヒトは多くのOSSの恩恵を受けたり、他社の事例を参考にしたりすることで、サービスを成長させてこれたと言っても過言ではありません。ですので、技術コミュニティや他社に「恩返し」したいと強く思いました。そして、コネヒトが得たものを技術コミュニティに還元出来れば、それをもとに技術コミュニティが発展し、技術コミュニティが発展すれば、それにより更にコネヒトも成長するという、Win-Winのループをつくることが出来るのではないか?と考えました。

コネヒトは「人の生活になくてはならないものをつくる」というミッションを掲げています。その中で、開発組織としても技術コミュニティや他社になくてはならない開発組織をつくることがス・マイル制度のゴールになります。

f:id:itosho525:20190821230121p:plain

制度設計時に気をつけたこと

順番が逆

ス・マイル制度で意識したことはコネヒトらしさです。そのために制度は一人で考えず、メンバー全員の意見を聞くようにしました。*3その中で、当初ス・マイル制度は、アウトプットに対して直接金銭的なインセンティブを払うというシンプルなものを考えていました。しかし、何人かのメンバーから「アウトプットを支援すること自体は良いがインセンティブの順番が逆ではないか?」という意見をもらいました。

これはどういうことかと言うと、技術コミュニティに貢献するためには、何らかのアウトプットが必要になります。そして、アウトプットをするためには、学習=インプットが必要になります。しかし、(ものにもよりますが)インプットには一定お金がかかる場合があります。ですので、アウトプット後にお金があるのではなく、アウトプットする前(=インプットをしたい時)にお金があるべきではないかというわけです。

お金のモチベーションは長続きしない

また、ほとんどのメンバーから金銭的なインセンティブは大きなモチベーションにはならないという意見も貰い、確かにダニエル・ピンクのモチベーション3.0ではないですが、お金のモチベーションは長続きしないと考え、最終的に「マイル」という形で、マイルをみんなの共有資産とすることで、お互いを支え合いながら、必要な時に必要な支援が受けられるように設計しました。

更にアウトプットの価値や、組織として何に投資するべきかを全員で議論するために、アウトプットは申請制にし、そもそもアウトプットとして認められるか?認められる場合、どれぐらいの価値があるか?というのをメンバーが承認する形にしています。*4

インプットについては、他薦を認めつつ、こちらもメンバーの申請制にしており、申請すれば自由に使える純粋な福利厚生ではなく、そのインプットによって、期待される成果やアウトプットなどを約束するようにし、その使途を議論出来るようにしました。

こうして、最終的にとてもコネヒトらしい制度が出来たと自負していますが、このような制度をつくる時は、他社の制度やHowをそのまま輸入するのではなく、自分たちのカルチャーにアジャストした形にしないと上手くワークしないということを改めて学びました。

早速盛り上がっているよ!

ス・マイル制度運用を開始してから、1ヶ月弱が立ちましたが早速多くのアウトプットが申請〜承認されています。ちなみに、管理ツールは内製しているのですが、この管理ツールは先日ブログでも紹介した「社内ツールをCakePHP4でつくりました」ツールになります。

ス・マイル制度は制度をつくることがゴールではなく、運用を開始してからが本番だと思います。ですので、運用ルール自体も今後継続的に改善していく必要があると考えています。そのため、運用に関しても僕一人ではなく、コアとなる運用メンバーを中心に開発部全体で行っています。ス・マイル制度の本当の評価や価値は今後生まれてくるものだと思いますので、また時々進捗などをお知らせ出来ればと考えています。

f:id:itosho525:20190821230523p:plain

最後に

現代のソフトウェア開発がOSSや技術コミュニティと切っても切り離せない関係にある中で、企業が金銭的な見返りや打算抜きに技術コミュニティと手を取り合っていくことの重要性はこれからますます高まっていくと僕は考えています。というわけで、ス・マイル制度が、企業と技術コミュニティをお互い持続可能な形で支え合う取り組みに出来るようこれから大切に育てていきたいと思います。そして、コネヒトを技術コミュニティになくてはならない笑顔があふれる*5開発組織にしていくぞ!

*1:開発部はコネヒトでエンジニアとデザイナーが所属する組織です。

*2:CTOに就任したのは2019年の6月。

*3:多数決で決めれば良いものではないので、最終的な意思決定はCTOの僕が行っています。

*4:もちろん、最初は判断基準がないと困ると考えたので、例えば、広報立ち会いの登壇は50000マイルというようなベースとなる基準表を用意しています。

*5:ちなみに、ス・マイルのスにはスペイン語で「あなたの」という意味も込めています。

SwiftFormatで自動コード整形

こんにちは!エンジニアの柳村です。主にママリのiOSアプリの開発を担当しています。

今回はSwiftFormatの導入についてお話します

背景

コネヒトではSwiftはraywenderlichのswift style guideをコーディングのスタイルガイドとしてコードを書いています。

ですが、各開発者が全てのスタイルガイドを覚えているわけではなく、ときどきスタイルガイドからはずれていたりインデントや改行が他のコードと不一致だったりしてコードレビューで指摘したりするといったことがありました。

レビューではコーディングスタイルを気にするよりももっと他のことに注意を払ってレビューすることに力を注ぎたいのでコードフォーマッターを導入してみることにしました。

フォーマッターの選定

Swiftのコードフォーマッターはいくつか存在しています。

まずは試しにcocoapodsに対応していて導入が楽なSwiftFormatにしてみました。

なぜcocoapodsがよかったかというと、フォーマッターのインストールはhomebrewなどを使って各自の環境にインストールするという手段もありますが、複数人で開発を行う場合に各自のインストールしているバージョンに違いが発生する恐れがあります。cocoapodsにしておけばインストールされるバージョンが固定されるので意図しないバージョンが使われてしまうといった恐れがなくなるメリットがあるからです。

設定

cocoapodsでインストールして、Debug Configurationでビルドした際に自動でフォーマットするように設定していきます。

Podfile

   pod 'SwiftFormat/CLI', :configurations => ['Debug']

Project

XcodeのTarget->Build Phasesに以下を追加します

if [ $CONFIGURATION = "Debug" ]; then
"${PODS_ROOT}/SwiftFormat/CommandLineTool/swiftformat" .
fi

.swift

.swift-versionがなければ作成しSwiftのバージョンを記載します。

5.0

.swiftformat

.swiftformatにルールを記載することでデフォルトのルールを変更することができます。

デフォルトのルールのままだとdiffがすごいことになったので以下の一部のデフォルトのルールをdisableにしました。

--disable trailingCommas, strongOutlets, unusedArguments, hoistPatternLet, blankLinesAroundMark

おわりに

このように導入はさっくりとできてしまうので、気軽に試せるのでおすすめです!

次回はswift-formatの使い方について紹介したいと思います、お楽しみに!

機械学習と人が協力してママリのコミュニティを支えているよ、という話をしました

f:id:taxa_program:20190809124049p:plain こんにちは!MLエンジニアの野澤(@takapy0210)です。

今更ですが東京喰種トーキョーグールというアニメを最近見始めました。
内容はもちろん面白いのですが、OPの歌い出し「教えて 教えてよ 〜」部分の声質がとても印象的で、どうにか真似できないかと練習しているところです。

さて、今回はこちらの勉強会でもLTさせていただいた「機械学習と人が協力してコミュニティを支えているよ」という話をしようと思います。

目次

LT資料

下記が資料です。

speakerdeck.com

以降、スライド内容を抜粋しながら進めていきます。

ママリ内での課題

ママリとは、全国のママがお互いに悩みを相談し合うことのできるQ&Aサービスです。
ユーザの熱量がとても高く、運営としてもコミュニティの雰囲気をとても大切にしています。

真摯な悩みを投稿するユーザが多くいる一方で、下記のように不適切な投稿をする人がいるのも、また事実です。

f:id:taxa_program:20190809124215p:plain
不適切な投稿例

このような中でコミュニティを健全な状態に保つためには、不適切な投稿は運営側で検知し、然るべき対応を行う必要があります。しかし、1日の投稿数が数千件を超える中で、全てを人間が目視チェックするのは現実的ではありません。

そこでママリでは、不適切な投稿を検閲するために機械学習を用いています。

f:id:taxa_program:20190809124754p:plain
ママリでの機械学習活用事例

機械学習と人が協力しているってどういうこと?

現在の検閲フローでは、機械学習モデル(以降、モデル)が「不適切な確率50%以上」と推論した投稿に関して、人間が目視チェックするようになっています。 f:id:taxa_program:20190809125736p:plain

なぜ、モデルの推論結果のみで処理せず、最終的に人間がチェックする必要があるのでしょうか。

今回の例に出したような「簡単に稼げる方法教えますよ」等の質問であれば、わざわざ人間がチェックする必要もないと思うのですが、例えば下記のような質問はどうでしょう。

f:id:taxa_program:20190809130101p:plain

この質問では「簡単に稼げる方法教えますよ」という意味の一文が入っているものの、実際は不適切な投稿ではなく、ユーザが抱えている悩みであることが見て取れると思います。

このような投稿をモデルで推論したときに、「誰でも簡単に稼げます!安心安全!今なら初期費用ゼロです!⭐未経験者歓迎⭐」という部分の影響で、不適切な投稿として判断されてしまう可能性があります。

f:id:taxa_program:20190809150943p:plain

そのため、冒頭でも述べた通り「不適切な確率50%以上と推論された投稿については、人間の目視チェックを通して対応する」というフローになっているわけです。

こうすることで、50%未満と推論された投稿については、人間の目視チェックが不要となり(=コスト削減)、機械学習が苦手とする微妙なニュアンスをもった投稿の対応に人間が注力できるようになります。

そして上記のように、機械学習と人それぞれの良いところを生かし合うことで、コストを削減しつつ、コミュニティを健全な状態に保つことが可能になっている、というわけです。

モデルについて

現在運用しているモデルについても少し触れたいと思います。

ママリ内には多くのテキストデータが存在しており、そのデータをコーパスとしてgensimを用いて単語の分散表現を計算しています。

f:id:taxa_program:20190809161150p:plain
単語の分散表現をgensim.word2vecを使用して計算

下記に、gensim.word2vecを用いて言語モデルを作成するコード例を載せておきます。
word2vecのオプションについてはこちらに分かりやすく掲載されているので、気になる方は見てみてください。

from gensim.models import word2vec
import multiprocessing

cpu_count = multiprocessing.cpu_count()  # CPUのコア数を取得する
corpus = word2vec.LineSentence('corpus.txt') # コーパスの読み込み

# 学習
model = word2vec.Word2Vec(corpus, 
                          size=200, 
                          window=5, 
                          hs=1, 
                          min_count=5, 
                          sg=1, 
                          iter=5,
                          workers=cpu_count
                         )

# モデルの保存
model.save('w2v.model')

この言語モデルは、例えば、単語の類似度を測ることが可能だったりします。
試しに、ママリのコーパスで学習させたモデルに対して、「夫」の類似単語TOP10を出力してみます。

# 夫 と類似している単語
model.wv.most_similar(positive=['夫'])

>>>
 ('主人', 0.9211037158966064),
 ('旦那', 0.8511199951171875),
 ('旦那さん', 0.7135452032089233),
 ('ダンナ', 0.6880300641059875),
 ('私', 0.6779747009277344),
 ('妻', 0.642198920249939),
 ('実父', 0.6189703941345215),
 ('わたし', 0.6182470321655273),
 ('父', 0.6118142604827881),
 ('お互い', 0.5914695262908936)

「お互い」という単語が出てくるあたり、コミュニティサービスから作ったモデルならではに感じますね。

そして、上記で得られた単語の分散表現をネットワークの入力として、双方向のLSTMを用いてモデルを構築しています。

f:id:taxa_program:20190809161511p:plain
ニューラルネットワークの概要

下記は実際にモデル構築に使ったコードの一部です。
ネットワーク自体はシンプルな構成になっており、出力層の活性化関数にsigmoidを用いることで確率を出力しています。
また、emb_matrixに上記で学習させた単語の分散表現を渡すことで、ネットワークのEmbedding層に初期設定しています。

# モデルの一部
def build_model(emb_matrix: np.ndarray, input_length: int):
    model = Sequential()
    model.add(Embedding(
        input_dim=emb_matrix.shape[0],
        output_dim=emb_matrix.shape[1],
        input_length=input_length,
        weights=[emb_matrix],
        trainable=False))
    model.add(Bidirectional(LSTM(64, recurrent_dropout=0.15)))
    model.add(Dropout(0.25))
    model.add(Dense(64))
    model.add(Dropout(0.3))
    model.add(Dense(1, activation='sigmoid'))
    return model

今後取り組んでいくこと

先にも述べた通り、現在ママリでは1日に数千件の質問が投稿され、学習に使えるデータは日に日に増加しています。
このような場合、最新のデータでモデルを定期的に更新することは、モデルの精度を維持・向上させるためにとても重要だと考えています。

しかし現在は、このモデル更新を全て手動で実施しているため、「機械学習基盤イケてるでしょ?」とは言い辛い状態です。(とはいえ、全てAWSのサービス内で完結しているため、手順フローを踏襲すれば誰でも/いつでも更新できる状態ではあります)

今後はこの手順を自動化すべく、AWSの各種サービスを組み合わせながら、自動更新フローを構築していく予定です。

最後に

今回はママリでの機械学習活用事例についてお話しました。

機械学習は、解決したい課題によってはとてもインパクトのあるものになり得ますが、課題の種類によっては、機械学習をフル活用するよりも、人間と機械学習お互いの長所を活かし合うことが大切だと考えています。

今後も、機械学習を使うことを目的とするのではなく、あくまでも課題解決の手段として活かせる部分には存分に活かしサービスグロースに貢献していければと思っています!

最後の最後に(告知)

すみません、最後にちょっと告知させてください...!

今月末に開催されるAWSの下記イベントで登壇する予定です。
当日はコミュニティサービスにおいて、どのようにAWS×自然言語処理を活用しているかというお話する予定です。
ご興味のある方いましたら、ご参加お待ちしております!
ml-loft.connpass.com

また、すでに満席となってしまっていますが、下記イベントでもLTする予定ですので、参加者の皆さまよろしくお願いします!
globis.connpass.com