2018年モバイルファクトリーアドベントカレンダー 12/3担当の id:yashims85 です。 前日は id:odan3240 さんの NuxtMeetUp#5 でnuxt-i18nを用いたwebサイトの多言語化について話してきました でした。 まえがき 2018年今日において、クロスプラットフォーム(以降: X-PF)界隈を改めて見てみると、大手各社がそれぞれアーキテクチャを提供をしており、X-PF戦国時代の様を呈しています。 今回はその中でもKotlin/Native(以降: K/N)とFlutterに絞って比較を行いたいと思います。 確認した環境はそれぞれ2018/12/03時点で最新である以下です。 Kotlin - 1.3.10 (Kotlin/Native Beta) Flutter - v0.11.13-beta 実のところ、両X-PFを触る前は何を書こうか迷っていたのですが、K/N、Flutter、及び他のX-PFを触ってみて感じるのは、どのX-PFにも長短があり現時点での銀の弾丸は無いという事です。 そこで、今回はKotlin/NativeとFlutterの比較を行いそれぞれの長短を把握してもらうことで、自分の状況にあったX-PF選びの参考にしてもらえたらと思います。 今回やらないこと Getting Started 各PFのGetting Startedが引っかかる部分も無かったので、そのとおりにやったら良いと思います 最強のX-PFはコレだ！ X-PFについて Android/iOSの両モバイルOSの登場以来、古今東西様々なX-PFが生まれては消えていきましたが、現在X-PF界隈に置いては、大手デベロッパーを背後に持つX-PFに淘汰されて来ています。 一例をあげてみましょう。 X-PF 主開発社 言語 特徴 Xamarin Microsoft C# X-PFとしての歴史、VisualStudioを使用した快適な開発環境、各PFそれぞれのUI実装 Unity Unity C# リッチコンテンツに強み、共通UI、独自ライフサイクル、ゲームエンジンベース ReactNative Facebook JS Reactと同じノリで作れる、共通UI Kotlin/Native JetBrains Kotlin AndroidStudioをIDEとして使用できる、各PFそれぞれのUI実装、まだBeta Flutter Google Dart Google系サービスならポン付け実装できる、独自ライフサイクル、基本は共通UI、まだBeta この中でもKotlin/NativeとFlutterはAndroidエンジニアにとって馴染みの深い2社が開発していることもあり、 気になっている方も多いんではないでしょうか？ Kotlin/Native 現在のAndroidの標準開発言語であるKotlinを開発したJetBrains社が主導で開発を進めています。Kotlin 1.3からBeta機能としてKotlin/Nativeが提供されています。 K/NはKotlinという言語に対してX-PF機能を付加するアプローチをとっています。 K/Nは以下のような特徴があります。 宣言を実装を分けることができる言語仕様と各PF用のビルドシステムによって実現 AndroidではJVM言語として、DalvikVM、ART上で実行される iOSではLLVMで機械語にコンパイルされ、iosのframeworkとして吐かれる frameworkにはK/Nコードのシンボルがヘッダファイルとして包含されているため、Swift側からもK/Nのコードを参照できる UIの共通化機能は提供されておらず、それぞれのPFで実装する必要がある Flutter Googleが主導で開発を進めています。こちらもBetaですが、Betaとは思えないほど機能やドキュメントが充実しています。 Flutterは純粋に開発環境の共通化を目的として作るアプローチをとっています。 Flutterは以下のような特徴があります。 Dartは滅びぬ！何度でも蘇るさ！ Android/iOSともに機械語にコンパイルし実行する UIパーツが多数提供されており、独自性の強いデザインを押し出さなければ爆速開発が見込める Reactに影響を受けたアーキテクチャ設計 各OSの機能とは遠い 開発環境 Kotlin/Native Flutter Android Studio / IntelliJ IDEA Android Studio / IntelliJ IDEA, VSCode 当然といえば当然ですが、どちらもAndroid Studioがそのまま使えるのが面白いですね。 どちらもBetaなので細かくは言及しませんが、現段階ではK/Nはディレクトリを作ったりbuild.gradleをいじったりと結構手作業で環境を構築する必要があり、若干の敷居の高さを感じます。 対してFlutterは、ASにPluginを導入するだけでFlutter環境をセットアップできるので、拍子抜けするほど楽ちんです。 またX-PF開発ではXcodeを触る時間をいかに少なくするかが鍵だと私は考えています。 この点においてもFlutterは現段階で一歩リードしており、Signing周りをポチポチするだけです。 対してK/NはBuildPiplineに手を加える必要があり、AppleのBuild周りの知識を要求されます。 言語 Kotlin/Native Flutter Kotlin Dart Kotlin/Native 言語的好みで言えば圧倒的にKotlinなのですが、X-PFを前提としたときK/Nは複雑性が上がり、可読性やメンテナンサビリティの低下につながる可能性があると感じました。 例えば、K/NではX-PF実現のために、1つのクラスを基本的には common に実装しますが、 必要に応じて宣言だけをcommonで行い、実装は Android iOS ... と複数のファイルに分割できるようになっています。 逆に、各PFの実装からcommonの処理を呼び出すこともできますので、きちんと設計を行わないと簡単にスパゲッティーコードを生み出すことができてしまいます。 また、非同期処理周りでも制約があり、現状ではCoroutineでの実装をおすすめしているようです。Rxなどは各言語の実装によるため異なる挙動を示す可能性があるためでしょう。 このへんの設計の難しさをクリアすれば、クライアントのみならずサーバともビジネスロジックを共有できるため、夢が無限に広がっていきます。 Flutter Flutterでは各PFの実装が処理の途中に挟まる事がないので、挙動の差異を気にする必要は最小で済むかなという感じです。 ドキュメント Kotlin/Native ドキュメントはありますが、ごちゃっとしていて全体像を理解するのに少し苦労します。とはいえ、不足していると感じるシーンは無く必要十分ではあります。 Flutter ドキュメントの整備度合いはFlutterに一日の長がありそうです。 Dart初心者に対してもEffectiveDartも準備されており、言語的マイノリティーに対してある程度の安心感があります。 周辺ライブラリ どんなライブラリが揃ってるかざっと見るのはawesome探すのが一番ですね。 Kotlin/Native Flutter awesome-kotlin-native awesome-flutter Kotlin/Nativeのawesomeが全然awesomeじゃないよ。。。 依存管理 Kotlin/Native Flutter Gradle Gradle どちらもASで開発できるので、必然的にGradleになるでしょう。わかる。 システム設計 まず、Kotlin/NativeやFlutterの特性を見ていく前に、プロダクト全体に対して与える影響をそれぞれ考えてみましょう。 Kotlin/Native K/Nは逆に設計に注力する必要がある、ある程度の規模が見込まれるプロダクトに向いています。 Clientだけでなく、サーバサイドまで1コードで実装できるのはとても魅力です。 K/Nは各PFで積み上げた資産やライブラリを有効活用しつつ、ビジネスロジックを共通化するアプローチをとれるとれるので、 システム設計の観点ではK/Nだから生まれる制約というのは特に無く、それぞれのPFの制約に依存する感じになります。 Flutter Flutterはミニマムで最速にリリースするのに向いています。 ただし、その分設計の自由度は少なく、他のアプリと差異を出すために特殊なことをしだすとFlutterのメリットは途端に消滅していく印象です。 サーバサイドについてもGoogleのサービスであれば一通りライブラリは揃っているけど、離れるほど少なくなる印象です。 サーバレスアプリケーションも(Googleのサービスベースなら)作りやすいんじゃないでしょうか。 ソフトウェア設計 それぞれのX-PFを採用したとき、それぞれどのようなソフトウェア設計が行えるでしょうか？X-PFは抽象化度によって、取りうるソフトウェア設計の幅に差が出てきます。 Kotlin/Native K/NではBetaになって日も浅いこともあり、めぼしい設計アーキテクチャは見当たらない印象です。 Pure-Kotlin向けならありますが十中八九JVMに依存しており、そのままK/Nで使用できるとは限らないため判別が付きません。 また、K/Nは言語の項目で言ったとおり設計の難しさがあり、特に多人数で開発するプロダクトでは注意が必要です。 基礎設計を行う時間を取れるプロダクトでは選択する価値がありますが、大規模でとにかくリーンというプロダクトではそれなりの負債を覚悟しなければなりません。 逆にそこがクリアできるのであれば、設計の自由度は高く、好きなように実装できると思います。 Flutter Flutterに関してはReactにインスパイアされたfluxアーキテクチャで実装されており、モダンなアーキテクチャを強制されます。 また、先行事例も多く参考を得やすいでしょう。 UI設計 UI設計に置いてはどういった長短があるでしょうか？近年の開発現場では非エンジニア職が直接UIの実装を行うシーンもしばしば見られます。 そうしたとき、UIの設計/実装のしやすさは判断基準の一つになります。 Kotlin/Native K/NではUIは各PFで実装する事になります。それぞれのPFに適したUI設計ができる反面手間ではあります。 現在Android/iOSともにGUIでデザインできる機能が備わっているので、それがそのまま利用可能です。 Flutter Flutterではレンダリングも独自で行っており、HotReloadに対応してるのが強みです。 UIパーツはWidgetという単位で公式/非公式問わず公開されており、ありものを拾ってくるのが容易です。 UIもコードで表現されるので、UIの修正が手間な印象を受けます。 ただし、Flutter自体がfluxアーキテクチャで動いており、そのへんの流れを知ってないと大規模なUI設計は難しい印象を受けます。 まとめ いかがでしょうか？個人的な印象としては K/Nは選択肢としては選択可能であるが、現段階では自由度が高い半面、開発難易度も高い。 Flutterは開発効率は高いが融通の効かない部分も多く、将来的に手詰まりになる可能性はある という印象を受けました。 まとめとしては、まえがきに書いた事の繰り返しになってしまいますが、X-PFにおいて銀の弾丸は無いので、 自身の開発内容にあった特性のX-PFを選択していきましょう。 明日は id:karupanerura さんの 「非TLS時代のセキュアなデバイス認証の思い出」 です。

こんにちは、ソフトウェアエンジニアの id:odan3240 です。 モバイルファクトリー Advent Calendar 2018 2日目は、 NuxtMeetUp#5 でnuxt-i18nを用いたwebサイトの多言語化について話してきたので、nuxt-i18nの紹介をします。 発表資料は、こちらです。 speakerdeck.com nuxt-i18nとは i18nとはinternationalization(国際化)の略で、ソフトウェアを様々な国や地域に対応することを指します。vueでこのi18n対応を行う場合は、vue-i18nというライブラリを使用するケースが多いです。 nuxt-i18nは、 vue-i18n のtranslation機能をnuxtのモジュールとして提供しています。具体的には、このモジュールを導入すると、 I18n クラスのインスタンスや t 関数がinjectされます。 他にもi18nで対応する言語に応じたルーティングの自動生成や、SEO対策を行ってくれます。 nuxt-i18nの機能 vue-i18nにはないnuxt-i18nとしての機能を紹介します。 ルーティング自動生成 nuxt-i18nでは、対応したい言語に応じて自動的にルーティングを生成してくれます。 設定ファイルに、nuxt-i18nの設定を次のように記述します。ここでは日本語と英語の設定をし、デフォルトの言語は英語を指定しています。 index.vue, about.vue というpage があるとします(下図参照)。 すると、各言語をprefixにしたpathが生成されていることがわかります。今回の設定ではデフォルトの言語が en のため、 / にアクセスすると、英語ページの index.vue の内容が表示されます。 便利な関数 nuxt-i18nを導入すると、次の2つの関数がグローバルに展開されます。 localePath localePath 関数は言語に応じたpathを返します。 switchLocalePath switchLocalePath 関数は、指定した言語への切り替えを行います。 SEO対策 Webサイトが多言語に対応している場合、検索エンジンのクローラーにそのことを教えてやる必要があります。これを行うには hreflang 属性などで指定する必要があります。nuxt-i18nではこれらの属性を設定ファイルから自動的に生成してくれます。 ハマった点 ここでは実際にnuxt-i18nを導入してハマった点について紹介します。 SEO対策を有効にすると
 headタグ内が壊れる SEO対策用の属性を自動的に生成してくれると、先程紹介しましたが、この設定を有効にすると <head> タグ内のいくつかのタグが消え、開発者が用意したjsファイルやcssファイルが読み込まれないという問題が報告されています。 github.com 開発中にこの問題に遭遇し、調査を行いましたが原因が判明しませんでした...。 https://uniqys.net では、nuxt-i18nのseoフラグを無効化し、手動で hreflang などの属性を生成しています。 ルーティングの自動生成の戦略の少なさ nuxt-i18nでは prefix_except_default と prefix の2つのルーティングの自動生成の戦略が用意されていました。 対応する言語が ja と en で、デフォルト言語が en のとき、この2つの戦略は以下のようなルーティングを生成します。 しかし、webサイトとしてのあり方を考えると、この3つのパスに対して200を返して欲しくなります。 そこで、このすべてのpathに対して200を返す戦略を実装しPullRequestを投げたところ、マージされました。 github.com この戦略は https://qurage.app で実際に使用されています。 まとめ nuxt-i18nの機能を一部紹介しました vue-i18nを利用したtranslation機能 対応する言語に応じたルーティングの自動生成 対応する言語に応じたSEO対策用の属性生成 多言語化を行う必要のあるwebサイトを作成する場合にはnuxtとnuxt-i18nの使用を検討してはいかがでしょうか

こんにちは、コーポレート・コミュニケーション室 シニアエンジニアの id:kfly8 です。 モバイルファクトリー Advent Calendar 2018 1日目は、 モバファクの社内勉強会について紹介します。 社内勉強会は会社ごとに色々なカラーがあると思いますが、モバファクの場合「業務時間に1日1時間、自由形式」で運用しています。 1日1時間 毎日2部屋予約しておき、いつでも気軽に勉強会開催できるようにしています 開催ネタが無ければ、開催しない日もありますが、だいたい何かやっています 直近の11月の開催数は11回、10月は14回、9月は16回だったようです 自由形式 勉強会の開催形式は、開催する人の好きにしてもらっています 例えば、講義、LT会、読書会、ワークショップなどの形式があります 直近だと、次のような書籍の読書会や、 VueFes のフィードバック、HPCの行列積計算の話、結婚式プロフィールムービーの作り方の話がありました:D オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー 翔泳社 Amazon UXデザインの教科書 作者: 安藤 昌也 丸善出版 Amazon カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで 作者: 市谷 聡啓 , 新井 剛 翔泳社 Amazon なぜ勉強会をするのか？ 成長のため、スキル向上のため、です。 勉強会なので「成長」は当たり前の答えかもしれませんが、 成長することは、例えばプロジェクトが捗ったり、将来やりたいことが実現の助けになったりと、良いことずくめです。 勉強会で成長促進出来るのであれば、良いことだと思っています。 成長のために、気づきは大切です。 勉強会参加者に気づきがあれば良いですが、多くの場合、主催者の方が気づきが多いです。 開催ネタを言語化し、フィードバックを得ることで、効率的に気づきを得られます。 こういったアウトプットの効用については、はてなさんの はてなエンジニアに期待する「アウトプット」 に綺麗にまとまっています。 どんなネタが良い？ 主催者が、知りたいこと、関心のあることが良いネタだと思います。 むしろ「良いネタを話さないといけない」と縛られないで欲しい、 アウトプットをせず、気づきの機会を失う方が良くないと思っています。 例えば、業務に「今」必要なことに縛られる必要もないです。 むしろ、投機的に勉強していくことの方が大切で、その方が将来の変化に対応できると思っています。 また何か特定のスキルを身につけることや、職種の対象も限定していません。 例えば、ディレクター、デザイナーの話を、エンジニアが聞いたりと、異なる職種間で話すことで得られる気づきがあると思っています。 勉強会の文化 そもそも、アウトプットして、お互いに話すことって楽しいですよね。 大げさですが、そういう文化が良いと思っています。 私が新卒入社して8年くらい経ちますが、それ以前からこんな感じでやっているようです。 (開催ハードルが上がり、開催が少なかった時期もあったり色々変化はあるのですが、それは別の機会があれば...) お金を支払えば、研修を実施することもできるかもしれませんが、 そうではなく、自分たちがどうありたいか、何が良いと思うか、 自由に発想できる場が、モバファクの社内勉強会です! モバイルファクトリーは、技術好きなエンジニアを募集しています。

はじめまして。コーポレート・コミュニケーション室の id:kfly8 です。 このたび、モバファクの技術ブログをはじめることになりました！日頃の開発で得られた知見など書いていければと思っています。 どうぞよろしくお願いします。 先日、研修の一環で、社内ISUCONを開催しました。ここでは、簡単に様子の紹介と問題を作るにあたって考えたことを述べます。 ソースコードはこちらです。 GitHub - mfac/mfac-isucon 課題アプリケーション 課題は、地図上にメモを残す、位置情報を使ったアプリケーションでした。具体的には次のようなことができます。 テキストのメモを位置情報と紐づけ投稿できる メモの閲覧ができる 投稿順 メモに紐づけられたハッシュタグと関連したメモ メモの位置情報のご近所 メモに絵文字でリアクション 実装の概要について書きます。フロントエンドはVue.jsでSingle Page Application(SPA)な構成にし、地図の表示にはOpenStreetMapとleaflet.jsを利用しています *1 。バックエンドで用意した言語は、PerlとGolangの2つです。サーバは ConoHa のVPSを利用しました。ConoHaはシンプルな使い勝手で使いやすいですね！ 初期データは、メモを約10万件程度用意し、それに紐づくリアクションを同程度用意しました。 テーマ・背景 今回、弊社で社内ISUCONを開催した際、気軽に参加しやすくする為、チームでなく、1人参加としました。また普段の開発の振り返りになるように、とっつきやすいような問題設定を考えました。具体的には次のようなことを考えました。 構成は簡素にする サーバは1台構成にする 迷い道を減らす為、アプリケーションの振る舞いは少なくする 競技の体裁を保つため、位置情報関連記述の知識によって、優劣が発生しないようにしたい 近傍探索の問題をまじめに（？）解く必要がないようにする→データを小さくしてしまう *2 参考実装では、余計なことはせず、mysql の buffer pool に載せるで十分解でした。 本物のISUCONでは避けているような「データをメモリに乗っけておしまい」「言語選択による差異が出る」という状況が起きやすい問題設定だったと思いますが、社内ISUCONだったのでそれも一興とし許容しました。 また、運営の負担を減らす為に、次のようなことを考えました。 *3 フロントエンドの実装を共通にする ビジネスロジックは、SQLに寄せることで、言語移植を簡単に済ませる 認証なしのSPA構成にして、ベンチマーカーのシナリオ実装を json.Unmarshal するだけに寄せる こういったことは運営側になってはじめて気づくことができ、面白かったです。 社内ISUCONの様子 実際の社内ISUCONの様子はこんな感じでした。 社内ISUCON初代チャンピオンの様子。 寿司の様子。美味しい。 これは今日行われた社内ISUCONの様子です pic.twitter.com/r9VvVJxn4d — odan (@odan3240) 2018年9月11日 まとめ 社内で、地図にメモを残すアプリケーションのISUCONを実施した ISUCONは、運営側を体験することでも気づきが得られる ISUCONは楽しいですね！ モバイルファクトリーは、技術好きなエンジニアを募集しています。 *1 : ベンチマーカーが外部サービスに負荷をかけない為に、SPA構成だったことは都合がよかったです *2 : データが大きい場合のデータの間引く方法の一例はこちらを参照 2015年のYAPC::Asia のランチセッション で紹介しました *3 : 運営負担を減らすのであれば、過去実装を使えば良かったかもしれないですが、魔が差しました