Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

グローバルなエンジニアを目指す為の入門的な話

765 views

Published on

YAPC::Fukuoka 2017 HAKATA トーク
「グローバルなエンジニアを目指す為の入門的な話 」

Published in: Internet
  • Be the first to comment

グローバルなエンジニアを目指す為の入門的な話

  1. 1. 0 グローバルなエンジニアを 目指す為の入門的な話 YAPC::Fukuoka 2017 2017-07-01 YU
  2. 2. 1 自己紹介 Yuichiro Nagaoka @yu_love_perl Perl5 / Mojolicious CGI/ PSGI Linux / Solaris Apache / MySQL YAPC ランチセッション(2014年 ) 初トーク (2017年 今回)
  3. 3. 2 この辺 シンガポール付近を対象とした ホスティングやシステム開発を行ってます。 日本 この内容を踏まえた話を何かしたい。
  4. 4. 3 特定の地域や国などを対象とする システム要件への対応を考えていく 本日のコンセプト
  5. 5. 4 国際化 i18n (internationalization) ソフトウェアを変更せずに様々な地域や言語に対応させること。 地域化 l10n (localization) 地域要素や翻訳を用いて特定の地域に対応させること。 m17n (multilingalization) 多言語化 g11n (globalization) グローバル化 この辺が対象 本日のコンセプト
  6. 6. 5 ・文字 / Character ・画面 / Template ・翻訳 ・TimeZone ・Perlsonal Information ・基本設計 ・インバウンド ・まとめ アジェンダ
  7. 7. 6 文字 / Character
  8. 8. 7 ・UTF-8 (1~3 byteが主) ・一部の国では4byte文字が登場 (日本、韓国、中国など) ・MySQL5.5以上ならutf8mb4使う。 (MySQL5.1つらい) ⇒ DBに持つかどうかは運用次第。 文字 / Character ホッケ (𩸽) ・サロゲートペア、絵文字、IVSなど ⇒ UnicodeにはUT8で処理が困難な文字がたくさんある。 UTF8の方で採用したい文字をホワイトリストにしていくことで 可能な限り要件を制御したい。
  9. 9. 8 ・日付 2017/06/25 (日本) Jun 25, 2017 (アメリカ式) 25 Jun, 2017 (イギリス式) ・単位 100,000円 $100.00 など ・住所 並び順が異なる、番地等が最初だったりする。 実装時は通常はできるだけパーツ化する。localizeされている物があれば使う。 用途が決まってない、固定化できない時はバラして実装するときも。 ex. 明瞭な場合 [% date_i18n %] ⇒ Jun 25, 2017 不明瞭な場合 [% mon %] [% dd%] , [% yy %] ⇒ Jun 25, 2017 文字 / Character
  10. 10. 9 画面 / Template
  11. 11. 10 ・海外の場合、日本よりも文字数が多い事が多い フォントサイズは一回り小さくする。 単語の折り返しに注意する。 (word-break: break-word 等) ex. 画面 / Template
  12. 12. 11 ・文字の流れが特殊な国がある。 CSSのdirection: rtlで対応 今年は2017年6月24日です ‫هو‬ ‫العام‬ ‫هذا‬24/06/2017 (日本:左から右) (サウジアラビア:右から左) ex. 画面 / Template
  13. 13. 12 翻訳
  14. 14. 13 翻訳の注意 基本的には英語をベースに展開していく。 日本語 ⇒ 英語 ⇒ ○○語 翻訳は自分では行えない事が多い。 必ず英語の段階で1回チェックする。 翻訳
  15. 15. 14 性別 ⇒ gender ⇒ XXX (○) 性別 ⇒ sex ⇒ YYY (×) 翻訳 いつのまにか意図しない翻訳に なっているかもしれません。 日本語は難しい。 特に単語レベルで翻訳した場合は注意。
  16. 16. 15 機械翻訳による翻訳は 検証の心強い味方 翻訳 ○ 男性 ○ 女性 ○ ชาย ○ หญิง 開発者の目線で1回はチェックしたい。 翻訳スケジュールがさみだれに組まれている時は要注意。
  17. 17. 16 併記の活用。 i18n化された環境の中では時には併記を使うことも。 お探しのページは見つかりませんでした。 Sorry ,Page Not Found 国や言語のいずれかが特定できないケースが出てくる。 共通エラー、セッションエラー、入り口の画面など ・URLでは判断できない。 ・ユーザの選択要素を判断できない。 ・コスト削減 翻訳
  18. 18. 17 ・多言語テンプレートを作る場合の注意点 部分的に言語を切り替えると可読性が悪くなることが・・ <table class="table[% lang %]" cellspacing="0"> <tbody> <tr> [% IF lang_jp %] <th>氏名(姓)</th> [% ELSIF lang_en %] <th>First Name</th> [% END %] テンプレート単位、CSS単位、で分けるなど 画面の用途を考える。 翻訳
  19. 19. 18 ・多言語テンプレートを作る場合の注意点 最後に翻訳していった場合に色々とスペースが足らなくなることがある。 文章が入る This is sentense. デザイン時の要件やスケジュール次第、可能であれば先に想定したいが… 翻訳 スペースが足らない、CSSで綺麗に表現できない場合は画像を活用する。
  20. 20. 19 Timezone
  21. 21. 20 国や地域ごとの標準時刻、時間帯を称して 「タイムゾーン」という。 ・UTC (世界協定標準時) ・JST (日本時間 Asia / Tokyo) Sun Jun 25 02:46:02 UTC 2017 Sun Jun 25 11:46:02 JST 2017 Timezone / 時差 9時間日本が進んでいる
  22. 22. 21 ・タイムゾーンを複数所持する国がある。 ・タイムゾーンは分単位から。 ・サマータイムを設置している国もある。 日本 東京 Asia/Tokyo (+09:00) マレーシア クアラルンプール Asia/Kuala_Lumpur (+08:00) クチン Asia/Kuching (+08:00) オーストラリア 南オーストラリア州 Australia/South (+09:30) クィーンズランド州 Australia/Queensland (+10:00) Timezone / 時差
  23. 23. 22 タイムゾーンは可能な限り1つにまとめて運用する。 Timezone / 時差 DBサーバアプリケーション サーバ Webサーバ ・各サーバのOSの時間 ・ミドルウェアの時間 ・アプリケーションが扱う時間 ・DBサーバに格納されるデータの時間 UTCで統一するか、現地時間で運用するかは要検討。 すべて現地運用なら現地時間の方が良い事も。(サマータイム除く) クライアント
  24. 24. 23 ex. シンガポールにあるサーバで タイのサービスを実施。 Timezone / 時差 DBサーバアプリケーション サーバ Webサーバクライアント Asia/Bangkok (8:00) Asia/Bangkok ⇒ Asia/Singapore (9:00) ・アプリケーションでサーバ時間に変換し所持。 ・画面などに返却する場合に、日時を現地時間に戻す。 上記を楽にできるように実装をできるとよい。 Asia/Singapore (9:00) Asia/Singapore (9:00)
  25. 25. 24 データベースで変換するとミスしやすい (個人的に) ・MySQLの場合、set session time_zone すると、 date time型は登録した時の時刻、 timestamp型は設定されたタイムゾーンで時刻を返す。 カラムが自動更新されている場合、さらに困難。 ・アプリケーション側の自動再接続の実装で set関数の効力を飛ばしてしまう事件。 ・そもそも必要なタイムゾーン設定が登録されてない。 Timezone / 時差
  26. 26. 25 運用でも注意するケースがある。 Timezone / 時差 ステージングサーバ (XXX) 開発サーバ (JST) rsync デプロイツール ・Text::Xslate ・Starlet ・ファイルのタイムスタンプを見るような仕組みでミス発生 (キャッシュファイル、ホットデプロイ) ・各種の監視の仕組みで注意
  27. 27. 26 Personal Information
  28. 28. 27 Perlsonal Information ・主に個人情報のこと。 ・国ごとに文化的傾向や法律など異なるため、注意する。 ・l10n的な要素で考えるべきことが多い。
  29. 29. 28 氏名 ・日本の場合 姓 名 ・海外の場合 ファーストネーム ミドルネーム ラストネーム ⇒ データベースカラムは3個以上必要。 Perlsonal Information
  30. 30. 29 氏名 ・インドネシアの場合 名 文化的傾向で苗字をもたない人が多い。 一般的なサービスでは分割して記入するようになっていることも。 ・Nama depan (前方向) ・Nama belakang ⇒ データベースカラムは必須項目にしてはいけない。 Perlsonal Information
  31. 31. 30 Perlsonal Information 性別 ・タイ 性別の種類が数多くある (18~40?) 第三の性は現在は多数の国で認められている。 性別を管理する場合、安易にフラグな実装にしない。 [% IF gender %] 男性 [% END %] (×)
  32. 32. 31 Perlsonal Information Eメールアドレス、電話番号 ・タイ メールアドレスは個人の所有率が高くない。 ショートメールなど利用している。 逆に電話番号は大半の人が持っている。 このような地域では本人認証する際など 音声受信などのサービスを代わりに使うと良い。 電話番号をキーにすることも一つの手段
  33. 33. 32 Perlsonal Information ここがポイント ・項目は安易に必須にしない ・型や属性の種類は幅を持たせる。 ・Eメールはキーにできないケースがある。 他にもいろいろな注意すべき要素があります。 ・住所項目の表示順 ・国民番号の利用頻度
  34. 34. 33 基本設計
  35. 35. 34 ちょっと長くなりましたが これまでの内容を元に基本設計を考えていきます。 基本設計
  36. 36. 35 どの単位でシステムを作るべきなのか考える。 ・国単位 ・言語単位 同時に複数の国や言語を対象とするか。 画面上など、システムによる多言語切り替えは必要なのか。 基本設計
  37. 37. 36 国や言語の単位を分けるときに便利なコード ISOコード 国 ・日本 ISO 3166-1の場合 numeric =392 alpha3 =JPN alpha2 =JP 基本設計 言語 ・日本 ISO 639-1 = ja ISO 639-2 = jpn
  38. 38. 37 言語 ・国に対する言語は複数。 ・英語は公用語 日本 日本語 マレーシア 英語 マレー語 基本設計
  39. 39. 38 ・URL 多国展開、多言語展開する場合にURLは重要。 ex. http://example.jp/APP_NAME/mys/eng/ http://example.jp/APP_NAME/mys/may/ ・国>言語>システム名 (国ごとにシステムをつくる場合) ・国>システム名>言語 (言語ごとにシステムをつくる場合) ・システム名>国>言語 (汎用的なシステムを作る場合) など色々なパターンが考えられる。 CDNの利用や運用も想定する必要あり。 基本設計 システム名 国 言語
  40. 40. 39 国、言語などのマスタ 多国展開、多言語展開する場合に動作対象国の定義が必要 ・国マスタ ・言語マスタ ・タイムゾーン ・Perlsonal Infomation 国や言語を紐付ける際のキーはISOコードを使うと便利 基本設計
  41. 41. 40 ・Personal Information 多国、多言語化する場合には、項目定義マスタを別途組む。 ex. ・項目の採用可否 ・必須チェック ・長さチェック ・マスタに含まれてるかのチェック ・表示順 ・エラーメッセージ マスタのキーはISOコードを使うと便利 基本設計 インドネシア 姓 任意項目 50文字 3番目
  42. 42. 41 ・Personal Information ex. i18n、l10nを想定した汎用化の例 国 ISO3166 言語 ISO639 基本設計 Personal Information 項目名 エラーチェック ISO3166 ISO639 項目名 JPN会員テーブル THA会員テーブル IDN会員テーブル MYS会員テーブル 共通マスタ系 各国系
  43. 43. 42 ・Personal Information 蓄積系のデータの入るテーブルは国単位で分けると良い。 テーブル構造は汎用的に、カラムは柔軟に。 対象地域が変わっても問題のない構造だとベター。 基本設計 項目名 カラム名 型 必須 KEY 会員SEQ m_seq not null PK 姓 f_name varchar(100) null ミドルネーム m_name varchar(100) null 名 L_name varchar(100) null メールアドレス email varchar(256) null IDX 電話番号 tel varchar(50) null IDX
  44. 44. 43 基本設計 i18n、l10nなシステムはできた。 G11n (グローバル)なシステムを目指す場合 さらに クライアントの環境 サーバの環境 を設計として取り入れた上で 構築する必要がある、大変。。。
  45. 45. 44 その他 考えていきたいこと。
  46. 46. 45 通信事情 ・海外のNWインフラは日本ほど安定していない事も多い。 ・ネットワークを多く使う仕組みや クライアントサーバ間の接続保持は逆にボトルネックになる事も。 ・日本は3000km、ブラジルなら面積は23倍。 距離が遠い場合はCDNを使うと良い。 実際に利用すると運用が難しい。 (キャッシュ回り、サービス周り、コンテンツ更新など)
  47. 47. 46 インバウンド ・インバウンド 外国人旅行者を自国へ誘致すること 2020年、オリンピックの影響があり、 インバウンド市場はおそらく全盛期に。 Webサービスの活性化が予想される。 主に日本運用を中心とした 国際的なシステムが求められる。 グローバルなエンジニア大活躍、のはず。
  48. 48. 47 皆さんグローバルなエンジニアを 一緒に目指しましょう。 o(_ _ )o ご意見・アドバイスなどあれば ツイッターなどでぜひください。 よろしくお願いします。 まとめ
  49. 49. 48
  50. 50. 49

×