RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのエンジニアブログ

Swiftのクロージャについて

はじめに

こんにちは。ラクスエンジニアのstrongWhiteです。
今回はSwiftにおけるクロージャの書き方をまとめようと思います。
クロージャJavaScriptなどを勉強した方は馴染みがあるかもしれませんが、初めての方は慣れるまで時間がかかるかもしれません。
なお、今回はSwift自体の説明を省きます。過去の記事でSwiftについて触れているので、気になる方はそちらをご参照ください。

クロージャとは

まずは前置きから。そもそもクロージャとは?ですが、簡単に言うと名前のない関数です。
文章にすると余計に混乱されるかもしれませんが、あえてまとめるなら以下のような感じでしょうか。

  • 自身が定義されたスコープ内で解決する関数
  • 実行結果を次の処理で続けて使用する関数を作成したい場合に使用

これを読んでも意味不明だと思いますので、後ほどサンプルコードを書いてみます。

コールバックとは

クロージャとは直接関係ありませんが、この後のサンプルコードにコールバック関数が出てくるので、コールバックとは?という方のためにあらかじめ解説しておきます。
コールバックとはあとで呼ぶという意味で、呼び出し先の関数の中で実行されるようにあらかじめ指定しておく関数をコールバック関数と言います。関数の中で別の関数を呼ぶイメージです。

実例(通常の書き方)

それではサンプルコードを見ていきましょう。まずは通常の書き方から。単純な文字列を出力するプログラムです。

func A() {
    print("RAKUS Developers Blog", terminator: "")
    B()
}
        
func B() {
    print("を読んでラクスを知ろう")
}
        
A()

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

実例(クロージャの書き方)

続いてクロージャを使ったサンプルコードです。処理内容は通常の書き方と変わっていません。

func A(title: String, callback: (String) -> (String)) {
    print(callback(title) + "ラクスを知ろう")
}

A(title: "RAKUS Developers Blog") { (blogName) in // <--クロージャ
    return blogName + "を読んで"
}

// 出力結果
// RAKUS Developers Blogを読んでラクスを知ろう

ややこしそうですが簡単に処理の流れを解説すると、関数Aの実引数titleの値がcallbackの引数になる=blogNameの引数になります。
そしてRAKUS Developers Blogを読んでが足された文字列がreturnされ、関数Aの処理でさらにラクスを知ろうが足され、最終的な文字列が出力されることになります。
高度な書き方に見えますが、Swiftをやっているとよく出てくる書き方なので覚えておいて損はないです。
このとき、関数Aのcallbackが前述したコールバック関数です。関数Aで呼び出されて初めて処理が行われます。

クロージャにすると何がよいのか?

最初に書いたように実行結果を次の処理で続けて使用する関数を作成したい場合に有効です。
例えば、ダウンロードしたCSVファイルを返す関数downLoadCsvがあるとします。サンプルコードでいうとdownLoadCsvは関数A相当になります。
downLoadCsvから返されたCSVファイルをもとに後続の処理を行いたい(例. CSVファイルをパースする)場合、クロージャdownLoadCsvの返り値を記述してあげれば実行結果を引き継げます。
慣れるととても使いやすく、記述もシンプルになるので、クロージャの書き方をぜひマスターしてみてください。

˚✧₊⁎❝᷀ົཽ≀ˍ̮ ❝᷀ົཽ⁎⁺˳✧༚ ← どのように見えますか? ~unicodeをざっくり知ろう~

はじめに

新卒3年目に突入しましたnorth_mkyです。
エンジニアをしていると一度はコンピュータでの文字の扱いについて考えることがあるのではないでしょうか。 今回は、かなりの国の文字をカバーしている符号化文字集合unicodeの特徴について書きます。

※今回はわかりやすさのために厳密性は求めない書き方をしている箇所があります。ご容赦くださいませ。

1. unicodeとは

符号化文字集合のひとつです。
...と書くと頭にはてなが浮かぶかもしれません。

文字というのは世界規模だとかなりの数が存在します。 ただ文字を集めただけではまとまり(ひらがな、漢字、ラテンなど)を表現することが難しかったり形や使われ方の違う文字の統一的に管理することが難しいため、「この位置にこの文字をおいておく」というように文字を系統的に定義し、管理しやすくしています。この位置のことを符号位置(コードポイント)といい、字に対して必ず一意の数値で表される符号位置が存在する、つまり字を数値に表せる「符号化」を行っているため、”符号化文字集合”といいます。

unicodeの他にも符号化文字集合は世界の各地域で存在しています。 こと日本でいいますと文字として、「ひらがな・カタカナ・漢字・アルファベット」を使うため、それらの符号化文字集合の定義が必然となります。国内でこれらの文字に特化した有名な符号化文字集合JIS X 0208があります。

この符号化文字集合は単に字を符号位置という位置づけを付与し文字を定義し集めているだけなので、コンピュータで扱いやすい・処理されやすいよう更に特定のアルゴリズムで符号化をしていることが多いです。この符号化の種類のことを符号化方式といい、具体的には下記のように符号化文字集合を表現する複数の符号化方式が存在します。

符号化文字集合 符号化方式
unicode UTF-16, UTF-8...
JIS X 0208 Shift_jis, EUC-JP, ISO-2022-JP

と、少し長くなりました、話を元に戻しますとunicodeとは符号化文字集合の一つです。 webではデファクトスタンダードの符号化方式(文字コード)、UTF-8の文字はこのunicodeを符号化したものです。冒頭で述べた通り、unicodeは多くの国の文字をカバーしているのですが、それゆえに文字集合の表し方や字の定義の仕方に特徴があります。以下にその特徴を述べたいと思います。

2. unicodeの特徴

unicodeには大きな特徴が4つあります。

  • 特徴1. 特徴1. 4次元で一つの文字を表す
  • 特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)
  • 特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)
  • 特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴1. 4次元で一つの文字を表す

unicodeでは符号位置は4次元で表しています。 擬似的に表現すると下記のようになります。

characterSet[group(群)][plane(面)][row(区)][cell(点)] = 'あ'

unicodeでは各々の次元をおおよそ1バイト(0x00~0xFF)の範囲で表現しており、1文字を4バイトの符号位置で表現しています。 かなりの符号空間を用意しているわけですが、全世界で現在利用している文字のほとんどはgroup:0x00,plain:0x00の範囲に収まっています。 この範囲だけ特別にBMP(Basic Multiligual plane:基本多言語面)というように呼ばれています。

unicodeエスケープ表記で表されている文字で「u\3042」というように2バイト表記されているものは、BMPに属しています。

  • u\3042」=「group0x00/plane0x00の面にある、row0x30のcell0x42の符号位置」

ちなみにBMPにのれず、別のplaneにある文字として日本で使われている一部の漢字があります。 このplaneの文字を実装していないシステムだと文字がただしく表示されない事象が発生します。

  • 文字があるはずの場所が空白
  • □の中に×が表示されている文字になる

特徴2. 他の文字と組み合わせて使う合成用文字が存在する(結合文字)

unicodeでは複数の合成用文字(結合文字)を合成して1文字を表す、というのを実現可能にしています。 たとえば日本語の「ぱ」などの半濁音は合成用の半濁点がunicodeに存在するので、「は」+「 半濁点」で表現できます。(※他の符号化文字集合との変換性を考慮して合成用でない半濁点、そもそも「ぱ」だけで符号位置もあります、むずかしいですね...) ですので、たとえば「あ」に半濁点をつけるなど、文字として認識されていない文字を合成して1文字のすることがunicodeを用いれば可能になります。

特徴3. 同じ文字だが字体が異なる場合一つの字体に統合されている(統合文字)

漢字を用いる民族、として日本の他に中国・韓国・台湾がなどがありますが、同じ漢字の形で少し書き方が違うものが数多く存在します。(ex. 海|海) このような漢字はunicodeでは一つの字体に統合しています(統合文字)。

特徴4. 他の符号化方式との互換性のため追加した文字が存在する(互換文字)

特徴3で字体を統合している、といったものの、厄介な問題があります。 別の符号化方式では区別している文字らをunicodeに変換すると、その字体の違いが吸収され、もとの符号化方式での字体を再現することができない事象がおこります。 このような事象を解消するために他の符号化方式との互換性を目的として文字が追加されることがあります。追加したそれらは別途互換文字と呼ばれます。

3. unicodeは進化し続けている ~タイトル回収~

ざっくりunicodeについて特徴を述べたのですが、やはり「すべての文字を網羅する」のは非常に難しく、既存の符号化文字集合との互換性の対応は不可欠となっているようです。ですので、unicodeも進化していっています。最近は文字だけでなく、絵文字の追加も盛んに行われています。それに対してシステムが使っているunicodeのバージョンが異なると文字が表示されない現象がおこります。

タイトルに書いた顔文字ですが、まさしく特徴でお話した結合文字を駆使して作られています。 私の環境ですと、chromeでは一部文字が表示できませんでしたが、safariではきちんと文字が表示されました。

chrome safari
f:id:northmky:20180417095732p:plain f:id:northmky:20180417095728p:plain

4. 終わりに

unicodeのざっくりした特徴を述べました。 何気なく単語として聞いているunicodeがどんなものなのか、掴めるようになりましたら幸いです。

5. 参考文献

今回の記事はこちらをとても参考にさせていただきました。
「第三水準漢字」「サロゲートペア」などの単語がどのカテゴリのどこに位置する話なのか、などがわかるかと思います。

アジャイル開発のプラクティスを取り入れてチームを成長させよう

id:radiocat です。スクラムマスターをやっています。 先月、社内のTechイベントの全社MeetUpで発表してきました。今回はその内容についてあとがき的にまとめてみました。

f:id:radiocat:20180409202902p:plain

終わらないスクラム

私達のチームでは、以前このブログでも紹介されているスクラムトレーニングを受講してスクラム開発を実践しはじめました。

tech-blog.rakus.co.jp

その経験を踏まえて得た知見や気づきを元に発表したのがこのスライドです。

speakerdeck.com

事前にトレーニングを積んでいたものの、実際にスクラムを実践してみるとうまくいかない事がたくさん出てきてスクラムイベントが思った通りに終わらない事態に陥りました。そんな状況を改善するためにスクラムコーチの吉羽さんにアドバイスを頂いたり、スクラムガイドや様々な書籍・資料を参考にして、スクラムイベントをきちんと終わらせるように取り組んだのが次のような内容です。

タスクの細分化

スクラムガイドには 作業の単位は1日以下 と書かれています。タスクの粒度が大きいと着手中の状態が長くなり、どの程度進んでいるのか、どれくらいで終わるのかの見通しがわかりづらくなります。そもそも見積もった時点で1日以上かかるということは細かい作業内容が充分イメージできていない事が多いため予定通り進まないことも多くなります。私達のチームでは見積もりが大きい場合は半日以下になるまでタスクを分解するルールにしました。

リファインメントの徹底

開発チームとプロダクトオーナーがしっかり会話してプロダクトバックログの内容を相互に理解しておかないと、何をどうやって実現するかが明確にならず半日以下のタスクに分解することも難しくなります。スクラムガイドにもリファインメントは プロダクトオーナーと開発チームが協力して行う継続的なプロセス であると定義されています。私達のチームでは リファインメント会議を毎週1回定期開催 するルールにしました。

デイリースクラムの改善

私達のチームではスクラムで開発を始める前から朝会で全員の進捗を確認していましたが、改めてスクラムで定義されているデイリースクラムの目的は何かを考えて朝会のあり方を見直しました。スクラムガイドには 自己組織化チームとしてスプリントゴールを達成し、スプリント終了までに期待されるインクリメントを作成できるかを毎日把握 するためのイベントと定義されています。そのためチームのリーダーが進行して進捗を確認するスタイルから開発チームが交代制で進行するルールに変更しました。

カンバンを検査の拠り所に

カンバンもスクラムで開発を始める前から導入していましたが、チームで意見を出し合って少しずつマイナーチェンジを繰り返しています。デイリースクラムを毎朝カンバンの前で行うため、カンバンもデイリースクラムの目的に沿っていることが重要です。チームの状態を検査し今後の状態が予測できる場にするためにより良い使い方を模索してきました。現在、私達のチームが実践しているスタイルは左からToDo、実行中、レビュー中、完了の順にレーンをわけて、優先度の高いタスクを上から順に並べています。右上にいくほどチームとして最も優先度の高いタスクであり、全員で協力して早く終わらせるようにしています。

むきなおりでチームの方向性を再確認

はじめからチームの進むべき方向性がきっちり定まっていて全員の認識が一致しているようなチームは稀です。私達のチームもはじめは手探り状態でどこかで不安を抱えながらスプリントを進めていたため、3回目のスプリントが終わった時に改めてチームの進むべき方向性を議論して目指すべき設計の方針や品質目標を再確認しました。

インペディメントの除去

スクラムガイドにはスクラムマスターはサーバントリーダーであり 、 メンバーが成果を上げるために支援や奉仕をするリーダー であると書かれています。スクラムにかぎらずソフトウェア開発において開発チームには様々な妨害要素が待ち受けています。近年のソフトウェア開発では、今まで使ったことのない新しい技術や外部のサービスを使うことも当たり前となっています。スクラムマスターはそのような要素を妨害リストとして洗い出し、それらを少しだけ先回りしたり、問題が小さいうちに手を打つことでチームが成果を上げられるように支援に徹しました。

2つの気づき

これらの取り組みを実践することで得た気づきは大きく2つです。

アジャイル開発のプラクティスは従来型の開発でも役に立つ

スクラム開発で取り組んだことは従来型の開発にも活かせることが多いと気づきました。実際にこのような手法は、従来型の開発プロセスの中にアジャイル開発のプラクティスを取り入れるということでハイブリッドアジャイルと呼ばれて実践されているようです。つい最近、日経SYSTEMSの最新号でもハイブリッドアジャイルをテーマにした連載が始まっています。

tech.nikkeibp.co.jp

改善の機会はスクラム開発のほうが豊富

スクラム開発では決まったタイムボックスでイテレーティブに開発を進めることによってアジャイル開発のプラクティスを取り入れるための検査・適応の機会がたくさん訪れます。アジャイル開発のプラクティスを実践して改善する機会はスクラムのほうが豊富にあると感じました。

終わらない学びと実践

スクラム開発でもそれ以外の開発プロセスでも、アジャイル開発のプラクティスは活用できます。そして、スクラムで開発する機会が訪れた時にはアジャイル開発のプラクティスを活用する機会は増加します。つまり、いずれにしてもアジャイル開発のプラクティスを取り入れて学びと実践を繰り返していくことがチームが成長していくための道筋の1つだとスクラム開発を通して学びました。スライドではそのようなアジャイル開発のプラクティスを取り入れるための情報源を幾つか紹介しています。

スクラムガイドによるとスクラム開発は 理解は容易習得は困難 とあります。私達もまだまだ終わりは見えていませんが、習得に向けて学びと実践を繰り返すことでチームがさらに成長できると思っています。

f:id:radiocat:20180409203832p:plain

「tig」をつかってcommitをきれいに分割する

f:id:FM_Harmony:20180404022333p:plain

はじめに

2年目のエンジニアになりました、FM_Harmonyです。 Rakus Developers Blogでは4回目の投稿です。

↓前回の記事はこちら tech-blog.rakus.co.jp

さて、弊社ではビアバッシュというイベントを行っています。(ビアバッシュ・・・?という方はコチラ
今回はその際に私が発表したことについて、補足も踏まえつつまとめたいと思います。 テーマはtigでcommitをきれいに!です。

続きを読む

JaSST'18 Tokyo 参加レポート

3月初旬に開催されたJaSST'18の参加レポートです。 [読了時間 8分]

JaSST Tokyo とは

国内最大級のソフトウェアテストシンポジウムです。

JaSST'18 Tokyo

JaSST Tokyo の昨年と今年のベストスピーカ―賞の傾向(2017年2018年)から、プロセス改善に注目が集まっている感もありますが、今回の JaSST'18 Tokyoの目玉はやはりなんといっても、Google ジョン・ミッコ氏の Flaky Test だと思います。

以下では、ミッコ氏による2つのセッション

を取り上げて、今回参加できなかった方でも、Google社の先進的な取り組みについて概要を把握できるよう、ポイントを絞ってお伝えしたいと思います。(ブログに掲載することについては、ミッコ氏の許可を得ております。ありがとうございます!)


基調講演 セッション A1「Advances in Continuous Integration Testing at Google」、基調講演者チュートリアル G5「How to identify test flakiness in your test result data テスト結果からテストの不安定性(test flakiness) を読み解く」

講演資料 が公開されていますが、 語彙の事前知識や質疑できる場などがないとなかなか理解しにくい箇所もあると思います。 まず、趣旨(引用)とキーワードを簡単に整理した後に、セッションの要点をお伝えします。

趣旨

  • より効果的なテストのスケジューリングとは
  • コストの削減方法
  • 不安定な自動テストへの対処(Flaky Test)

キーワード

  • SETI (Software Engineer, Tools and Infrastructure)
    • テストインフラを開発する役割
      • 8~10人のチームに1~2名のSETIアサインされる
  • RTS (Regression Test Selection)
  • Transition
    • テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移すること
  • Edge
    • テスト結果がPASS→FAIL または FAIL→PASSへと状態遷移したチェンジリストの断片
  • Greenish
    • テスト成功(グリーン)のような状態
    • 確信ではなく確率
  • Flaky Test
    • 不安定なテストのこと
      • テスト結果が非決定論的
      • 同じコードリビジョン、同じ入力と設定、においてテストが成功したり失敗したりする

Googleの自動テスト(概観)

  • 420万の独立したテスト
    • その16%は何がしかのFlakyさを持つ
  • 1日あたり1億5000万のテスト実行数
    • 平均して各テストが毎日に35回実行される
  • 1万3000以上のチーム
  • テスト実施の99%は成功する
  • テスト結果がPASS→FAILに遷移したテストのうち、84%はFlaky
    • テスト失敗の16%だけが欠陥を意味していた
  • テストの 1.23% だけがソフトウェアの欠陥を見つけている
    • 変更頻度が多いファイルは欠陥が埋め込まれやすい
    • 開発者が3人以上修正したソースは欠陥が埋め込まれやすい
      • 1人より2人がよい
      • 3人より2人がよい
    • 言語によって欠陥の埋め込まれ度合いが異なる

なんというか規模が桁違いですね!

RTSはなぜ必要か

テスト実行数を削減するため

  • テスト実行の99.8%は、テスト結果の遷移を引き起こさない
  • テスト結果の遷移を引き起こすような0.2%のテスト実行だけで十分なことになる
    • もし完璧なアルゴリズムがあれば、すべてのテストを流し続ける必要はない

Greenishという概念がなぜ必要か

テストの量、実行回数ともに莫大で、全てを実行しきれないため

  • RTSだけでは問題が多い
    • 依存関係グラフを元にした回帰テスト対象の選定(RTS)を行っても、コアモジュールへの些細な修正がほぼ全体に影響するため、一定期間のマイルストーンでのスケジューリングにおいて全テストを実行することになりがち
  • マイルストーン間は、プロジェクトの状態は決定的ではない(inconclusive)
  • 全テストを実行することによる「グリーンの確信」に代わり、「グリーンの確率」を提供している
    f:id:maskondo:20180330152612p:plain
    図1. Greenish
    • 図1で、大きい緑●が「グリーンの確信」
    • 図1で、モスグリーン四角が「グリーンの確率」
  • チームにとってはリスクを持ってリリースすることになる

遷移を見つけるまでの時間を節約することを重視 しているようです。1日経てば「過去」であり内容を忘れている、と。

Flakyという概念がなぜ重要か

テスト結果が成功から失敗に状態遷移したときでも、その84%が誤報であるため

  • システムの問題なのに、開発者にテストが不合格だったと通知がくることで調査する時間が無駄になる
  • マシンリソースの 2~16%をFlaky Testのために消費している
  • 全てグリーンでないとリリースしないため、リリースの妨げになる
  • 無視すべきでないときもある
    f:id:maskondo:20180330155635p:plain
    図2. Flaky
    • 図2で、Flakesはテスト結果が非決定論的に成功したり失敗したりするFlaky Test

Flakyなテストがあると、テスト失敗が常に欠陥を意味するとは限らなくなってしまう のです。狼少年のような存在ですね。

Flaky Testへの対処

Flaky Testを検出することで、開発者にはテスト結果に添えて「Flakyである」という旨も一緒に伝えることで、調査コストを抑える

  • Flakyさは不可避(Inevitable)との見解
    • Flakyさを除去するのと同程度には新たなFlakyさが埋め込まれる

Flaky なテストを単に無視したり削除するという考え方について、休憩時間にミッコ氏に直接尋ねることができました。不安定なテストはまだバグを捕まえるために価値があるので無視したり削除したりしてはならない(意訳)とのことでした。

Flaky Testの検出方法

テスト結果(PASS/FAILのバイナリ値のみ!)を残すだけで、Flaky Testへの洞察が得られるそうです。 特殊な操作は必要なく、単純なクエリで推定できるところがポイントです。

  • Google では テスト結果を2年間記録を残し続けている

    • PASS/FAILのバイナリ値のみ
    • Googleでは *unit.xml ファイルは残していない(が残しても構わない)
  • テスト結果の遷移であるTransitionやEdgeに着目して、経験則を育てている

    f:id:maskondo:20180330152621p:plain
    図3. Edge

    • 履歴を共有(同じタイミングで成功・失敗すること)する他のテストの数が多い場合はFlakyではない
      • ライブラリ起因などの明確な理由がある可能性が高い
    • テスト結果の遷移が多いテストは、Flakyと判断できる
      • 例えば、1日に30回もテスト結果が遷移するテストがあった場合に、開発者がそれほど頻繁に直したり壊したりをしたとは到底考えられない

チュートリアルで Flaky Test の検出を実際に Google BigQuery を使って行いましたが、とても簡単でした。


感想

自動テストへの長年の取り組みの成果として、もし自動テストを全て流せるなら「確信(100% Confident)」があるという土壌があった上で、テスト実行の運用をいかに効果的に行うか? という次元のお話でした。 確信(100% Confident)に代わる何かが必要な状況で、ビッグデータ解析を活用するところがグーグルらしいですね。 クロージングパネルでも話されていた「アメリカでは大企業、中堅企業において自動テストは既に当たり前であり、より効果的な運用についてその興味が移っている」といった言説が印象的でした。

React Native + Expo で お手軽 Hello World!

f:id:FM_Harmony:20180314175546p:plain

はじめに

こんにちは! FM_Harmonyです。 Rakus Developers Blogでは3回目の投稿になります。

↓ 前回の記事はコチラ tech-blog.rakus.co.jp

先日、React Nativeを使ったスマホアプリ開発についての勉強会に参加しました。 なので、今回はその時学んだこと + 後から自分で調べたことについてまとめました。

この記事が、「Reactやってみたいなー」という方の参考になれば嬉しいです。

前置き〜スマホアプリの分類

いわゆるスマホアプリは大きく分けて2種類あります。*1

  • Webアプリ
    ブラウザ上で動作するアプリケーションです。 HTMLやCSSなどを使って開発します。
  • ネイティブアプリ
    スマホ上で直接動作するアプリです。 例えば、Android向けアプリだったらAndroid Studioを使って開発します。

今回お話しするのは、ネイティブアプリの開発についてです。

React Native とは?

React Nativeとは、ネイティブアプリをJavaScriptとReactでビルドするためのフレームワークです。 素のJavaScriptのみでアプリ開発を行うことができます。

特徴としては、アプリケーションの更新を即座に反映させることができることがあります。 ビルドしなおさなくても、読込みし直すだけで変更を確認することができるので開発速度の向上につながります。

Expoとは?

端的にいえば、React Nativeでの開発をサポートするツールです。 博覧会じゃありません もともとはExponentという名前だったそうです。

Expoの特徴はいくつかありますが、一つは基本的にiOS/Androidアプリの区別をすることなく開発を進められる事が挙げられます。 Expoはネイティブ層を隠しているので、両者の違いを意識しなくて済む・・・らしいです。

さらに、実機での検証が簡単に行えることも特徴の一つです。 これについては、またあとで触れたいと思います。

Hello World をやってみる

それでは、ExpoでHello Worldをやってみましょう。 今回のゴールは、スマホの画面にHello World!と表示させることです。

なお、作業はmacOSで行っています。 Windowsでもできますが、説明は省略します。

環境構築

まず、開発環境を構築しましょう。 Expoで開発を行うためには、以下のものが必要になります。

  • npm(もしくはyarn)
  • Node.js
  • watchman
  • create-react-native-app

この内、watchmanとcreate-react-native-appについて説明します。

  • watchman
    これがないとアプリケーションを動かすことができません。 Homebrewでインストール可能なので、やっておきましょう。
$ brew install watchman
  • create-react-native-app
    プロジェクトを作成する際に必要です。 こちらはnpmでインストール可能です。 インストールの際には、グローバルオプションを付けておきましょう。
$ npm install -g create-react-native-app

プロジェクト作成

では、次にプロジェクトを作成します。 次のコマンドを実行すると、カレントディレクトリ直下にプロジェクトのひな形が作成されます。

$ create-react-native-app HelloWorldApp

サンプルを確認してみる

プロジェクトが完成したら、すぐに動かすことができます。 先ほど作成されたプロジェクトのディレクトリへ移動して、以下のコマンドを実行してみます。

↓npm の場合

$ npm start

↓yarn の場合

$ yarn start

起動に成功すると、大きなQRコードが表示されると思います。
QRコードが表示されています(読み込みできないように一部塗りつぶしています) f:id:FM_Harmony:20180314163451p:plain

ExpoではこのQRコードスマホ上で読み込むことで、簡単に動作確認を行うことができます。 ただし、QRコードの読み込みには専用のアプリケーションが必要です。
iOSならExpo CliantAndroidならExpoをそれぞれマーケット上で検索すればすぐ見つかるはずです。

では、今回はiOSQRコードを読み込んでみましょう。 アプリの読込後に、画像のような画面が表示されていれば成功です。

↓ アプリの画面(諸事情によりエミュレータ上で動かしています)
f:id:FM_Harmony:20180314164324p:plain

Hello World!

上の画像にも書いてありましたが、アプリケーションはApp.jsを編集することで変更が可能です。
そこで、アプリを読み込んだままApp.jsを開いてみましょう。

すると、<View> ... </View>で囲まれたブロック内に、<Text>...</Text>のようにタグで囲まれたコードがあるはずです。 この部分を次のように変更して保存します。

... の部分は変更しないでください

<View style = {...}>
  <Text>Hello World!</Text>
</View>

実機を確認すると、画面が自動的に変更されたことが確認できます。

Hello World! になっている!
f:id:FM_Harmony:20180314165903p:plain

ということで、ExpoでHello Worldができましたね!
今回は簡単な例でしたが、Expoを使うと簡単、かつお手軽にスマホアプリ開発ができることが分かりました。

困ったところ

今回、この`Expoを触ってみて幾つか困った点があったので紹介します。

アプリが起動できない!

プロジェクトの作成も完了し、さてどんな風に動くのかなとアプリを起動させたところ・・・

↓こんなエラーが出ました。
f:id:FM_Harmony:20180314152405p:plain

そこで調べた結果、watchmanが必要なことを知ったのでした。

実機で動かせない!

簡単に実機で動作確認できることがExpoの売りですが、自分の場合実機での確認ができませんでした。
実機で動作確認するためには、作業用PCと実機が同じネットワークにある必要があるのですが、どうもそこのところで上手くいかなかったようです。

QRコードを読み込んでも、こういう画面が出てきてしまう。
f:id:FM_Harmony:20180314153342p:plain

なので、そういう場合はエミュレータで動作確認しましょう。

macOSの場合、XCodeに付属しているエミュレータを利用することができます。 アプリケーションを立ち上げた後に、iボタンを押せばiOSエミュレータ上で動作確認が行えます。

ただし、その場合はxcode-select -s /Application/Xcode.appみたいな感じで、コマンドを実行しておく必要があります。 これは、XCodeコマンドラインツールを指定しているらしい*2です。

感想

なんといっても動作確認の手軽さがすごく便利です。 ビルドのわずらわしさから解放されるだけで、かなりサクサク開発が進むなあと感じました。

あと、今回は残念ながらできませんでしたが、実機での動作確認がQRコードを読み込むだけだというのもお手軽で魅力的です。

私が今回のテーマについて勉強しようと思った理由は、「Reactってよく聞くし始めてみようかな」くらいの軽いものでした。 なので、こういう手軽なところからアプリ開発に親しみつつ、Reactについて勉強することで効率よく学習できそうだと思いました。


*1:この他にもハイブリッドアプリと呼ばれる、両者を掛け合わせたものもあります

*2:この辺りはまだ勉強中です・・・

WindowsにMeCabを入れてPHPで動かしてみる

はじめに

新卒1年目エンジニアのkasuke18と申します。
先月に開催された社内の技術交流会ビアバッシュの発表の中でMeCabについて触れた発表がありました。
ビアバッシュ...?という方はこちらをご参照ください。

そのMeCabに興味をもちましたので、今回の記事ではMeCabWindowsに導入して使ってみます。以下は私の環境でインストールしたときのものなので、ディレクトリなどを随時読み替えてください。

まずはサンプル

形態素解析とはどのようなものかを確認するサンプルを作成、HEROKUにデプロイして公開しています。まずは触って動かしてみましょう!

MeCabとは

MeCabオープンソースの日本語の形態素解析エンジンです。(公式ページ
OSはUnix系でもWindowsでも使用可能ですが、私用のPCがWindowsのため、今回はWindowsMeCabを導入しました。

MeCabの導入…の前に

WindowsMeCabを導入するといっても、単純にWindowsに入れるというわけではありません。もちろん公式にはWindowsインストーラが用意されているので、単に利用するだけならそれを使用することが一番早いです。
しかしインストーラでインストールされる標準の辞書が古く、新しい単語に弱いので、より適切に形態素解析を行うなら新語に対応した辞書が必須です。その辞書の導入がインストーラからインストールした場合は難しいので、今回は別の手段を用いました。
それがWindows Subsystem for Linuxというものです。

Windows Subsystem for Linuxとは

簡単に言うと、Windows上でLinuxが動かせるよ!といったものです。 対応するLinuxディストリビューションUbuntuOpenSUSE1などです。(公式DOC参照)
今回は使用するディストリビューションとしてUbuntuを選択しました。

Windows Subsystem for Linuxの導入

こちらのQiitaの記事が詳しいので、そちらをご確認ください。

MeCabの導入

さて、前置きが長くなってしまいましたが、いよいよMeCabの導入です。
といっても特段難しい手順ではありません。以下のコマンドを実行すれば導入できると思います。

sudo apt update
sudo apt upgrade
sudo apt install make automake autoconf autotools-dev m4 mecab libmecab-dev mecab-ipadic-utf8

導入したので動作確認を行います。以下のコマンドでMeCabが実行できます。

mecab

正しく実行されると入力モードになりますので、何かを入力し、改行してみましょう。改行で形態素解析が行われ、結果が表示されます。

f:id:kasuke18:20180325214534p:plain
図1. MeCabコマンドを実行

新語対応の辞書(mecab-ipadic-NEologd)を使う

前述のとおり、標準の辞書は古いので新語に対応していません。新語に対応した辞書が必要で、その辞書の一つにmecab-ipadic-NEologdというものがあります。mecab-ipadic-NEologdははてなキーワードのダンプデータなどをもとに毎週月曜日と木曜日に更新されます。はてなキーワードの単語の豊富さを考えると、業界用語などの特化した単語を除き、基本的にはmecab-ipadic-NEologdで事足りるでしょう。

mecab-ipadic-NEologdの導入

GitHubのREADMEに丁寧に手順が記載されています。さらに英語だけでなく、日本語で書かれたREADMEも用意されているので、至れり尽くせりです。 以下にコマンドのみ記載しておきます。

sudo apt install git make curl xz-utils file
sudo sed -i -e 's%/lib/mecab/dic%/share/mecab/dic%' /usr/bin/mecab-config
git clone --depth 1 https://github.com/neologd/mecab-ipadic-neologd.git
./bin/install-mecab-ipadic-neologd -n -a

導入したので動作確認を行います。以下のようにMeCabコマンドの-dオプションを使用することでmecab-ipadic-NEologdを辞書とした形態素解析を実行できます。

mecab -d /usr/share/mecab/dic/mecab-ipadic-neologd

正しく実行されると入力モードになりますので、何かを入力し、改行してみましょう。改行で形態素解析が行われ、結果が表示されます。

f:id:kasuke18:20180325215344p:plain
図2. mecab-ipadic-NEologdを使ったMeCabコマンドの実行

MeCabPHPから使用する

上記の手順でMeCabを用いた形態素解析が可能になりましたが、PHPなどの各種スクリプト言語からの使用するには面倒です。そこで各種スクリプト言語向けにバインディングされたものがありますので、それを利用します。今回はPHPを使用しますが、公式には用意されていないので、このphp-mecabを利用します。

php-mecab導入のため、以下のコマンドを実行しましょう。

cd /usr/local/src/
git clone https://github.com/rsky/php-mecab.git
cd php-mecab/mecab
phpize
./configure --with-php-config=/usr/bin/php-config --with-mecab=/usr/bin/mecab-config
make
make test
make install

導入後、PHPで使用するためにextentionファイルを作成します。

echo 'extention=mecab.so' > /etc/php/7.0/cli/php.d/mecab.ini

これでPHPからMeCabを使用するための準備が整いました。サンプルコードを以下に示しますので実際に動かしてみましょう。

<?php
dl('mecab.so');
$option = array('-d', '/usr/share/mecab/dic/mecab-ipadic-neologd');
$t = new \MeCab\Tagger($option);
$str = 'すもももももももものうちにももはいくつあるでしょう';

echo $t->parse($str);

エラーなく実行できると以下のような結果が得られます。

f:id:kasuke18:20180325215402p:plain
図3. mecab-phpを用いたサンプルコードの実行

おわりに

この記事ではWindowsMeCabを入れてPHPで動かすまでの手順を紹介しました。私が試してみたときはphp-mecabを入れるときに詰まりましたが、MeCab本体を入れるところまでは全く詰まらずに進められました。PHPなどで使うことを考えず気軽に形態素解析を行うという点では、MeCabはちょうどいいのかなと感じました。

参考文献


  1. よろしければこちらもご一読ください。 「openSUSE」で始める初めてのLinuxデスクトップ

Copyright © RAKUS Co., Ltd. All rights reserved.