株式会社モバイルファクトリー の技術ブログ
全223件
こんにちは、ソフトウェアエンジニアの 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 : 運営負担を減らすのであれば、過去実装を使えば良かったかもしれないですが、魔が差しました