ナカザンドットネット

それって私の感想ですよね

マッハ新書できそうだったけどやらずにちゃんと書いたという話

最近、マッハ新書ってあるじゃないですか。

nlab.itmedia.co.jp

golden-lucky.hatenablog.com

実践してる人たちのツイートをリアルタイムで眺めながら、「はー、そういうのもあるのか」くらいに思っていたのですが、期せずして自分の手元にもマッハ新書を出版できる=12時間以内で最低限の思想を表明できるチャンスが巡ってきました。

しかし、結局マッハ新書的な形で出すのではなく、多少の時間をかけてそこそこボリュームのある記事を書くことを選びました。

このあたりの心の動きは来週くらいには忘れてしまっていそうなので、エッセイとして残しておきたいと思います。

続きを読む

Web最新技術がてんこ盛りのreact-native-domから目が離せない

パリで発表されていたReact向けプロダクトがあまりにも未来に生きていて興奮したので、紹介させてください。

目次

  • 目次
  • この記事のゴール
  • 想定読者
  • はじめに
  • 今回ベースとするソースコード
  • React Nativeは何をするツールか
  • Reactは何をするツールか
  • React DOMとReact Nativeの違い
    • Reactアプリケーションを描画するものたち
    • React DOMの役割
    • React Nativeの役割
      • 1. ネイティブ処理系の上でJavaScript処理系を動かす
      • 2. Reactを動かす
      • 3. Reactから渡された差分をネイティブViewに適用する
  • React Native DOMはどこがReact Nativeなのか
  • React Native DOMのやばいところ6連発
    • ReactからはReact Nativeに見えてるのがやばい
    • Objective-C実装をJavaScriptに書き直しててやばい
    • Web Workerまで使って2スレッド制を再現してるのがやばい
    • Yogaをwasm向けにポーティングしてるのがやばい
    • React DOMを使ってないのがやばい
    • 実はWebComponentsを描画してるのがやばい
  • React Native DOMはやばい
  • Donation Welcome!

この記事のゴール

この記事では、React Nativeの内部実装に関する予備知識がほとんどない人が、React Nativeが元々どういうものなのかをふんわりと理解した上で、React Native DOMがどのように変態かつ未来に生きているのかを分かったつもりになってもらうことを目的とします。

想定読者

  • ReactがわかるJavaScriptエンジニア
  • JavaScriptのマルチスレッド処理の実例に興味がある方
  • WebAssemblyの実例に興味がある方
  • React Nativeのソースコードを読んでみたいけど、JavaScriptならともかくJavaやObjective-Cを読むのはちょっと・・・と尻込みしていた方

はじめに

5月17, 18日に、パリでReact Europeが開催されました。

f:id:Nkzn:20180522084612p:plain

https://www.react-europe.org/

Reactに関する様々な知見が公開されたようですし、スケジュールを見た限りではReact Nativeに関するセッションも多めなように思われました。

中でも私の目を引いたセッションは、Vincent Riemerさん([twitter:@vincentriemer])の "Bridging React Native Back to its Roots" でした。動画↓とスライドがそれぞれ公開されています。

www.youtube.com

このセッションは「React Native DOMというプロダクトを作ってみたので、モチベーションと設計方針の紹介、それからデモをするね」というタイプのやつでした。

github.com

字面からなんとなく想像できるかと思いますが、React Native DOMは「React Nativeコードをブラウザ上で動かすためのライブラリ」です。

このへんのユースケースに興味があって調べたことがある方は「えっ、それReact Native for Webと何が違うの?」と思われたことでしょう。はい、私もそう思いました。

ちょうど、Cheap Dive into React Nativeを書いたおかげでReact Nativeのソースを読むのにも自信がついてきたところなので、「まあどうせYet Another React Native for Webでしょ」と思いながらReact Native DOMのソースを読み始めたのです。

そしたらまんまと度肝を抜かれたので、「こりゃみんなにどれだけすごいか伝えにゃいかん」と、こんな記事を書き始めた次第です。

長文で前提条件から細かく書いているので、ひとまず概要を知りたい方はQiitaの記事へどうぞ。

react-native-dom の何がすごいのか - Qiita

また、React Nativeのことはもうわかってるよ、という方は「React Native DOMはどこがReact Nativeなのか」の見出しを検索して、そこからお読みください。

続きを読む

FluxにはModelがないのではないかと思った覚書

Fluxを使い始めると「おっ、MV*に比べて頭が悪くても状態が壊れないぞ?」という感想になる人が多いと思うんだけど、その理由がふたつあるような気がしてきた。

ModelやViewModelについてはコンテキストが違う人から「それ違くない?」と言われそうな書き方になるかもだけど、思いつきを書きなぐってるだけなので勘弁してください。

1. 単方向データフローが分かりやすく、コードの複雑さの低下に寄与している

これは全くポジティブな要因。

2. FluxはMV*のModel相当の要素が図に含まれていないので考えることが減った

MV*は「Modelって書いてあるからには何かをModelと呼んでデータを突っ込まなきゃいけない」という意識が生まれやすかった(その責務分割が適切だったかは別として)と思う。

でも、FluxにはStoreとかいうViewModel*1みたいなものしかない*2と私は思っていて、MV*でModelと呼ばれていたものを定義させようとする意図は感じられません。

結果的に、Modelについて書いてないので考えるきっかけがなくなって、必要な脳内メモリの量が減った結果、「頭が悪くても〜」という感想になるのではと思いました。

文脈

文脈としてはこの辺の話から来ています。

まとめ

MV*はModel内の設計について定義していませんでしたが、FluxはModelの存在自体を私たちに押し付けてこない子なのでは、と思い始めました。Model相当のものがなくていいわけがないのですが、単方向データフローが強力すぎて、Model相当の部分があやふやでも、みんな何とかなっちゃってるんじゃないかな・・・*3

Model相当の部分を設計したFlux、業務で色々と試してみているので、どこかのタイミングで布教していきたいです。

補足をいただきました

この記事の本質を言語化し直してくれました。

nekogata.hatenablog.com

うん、StoreとVMの話は余計だったなという気持ちはあります。

おまけ

DroidKaigi 2018でベノワさんが紹介していたModel-View-Intentは限定的ながらModel相当の部分(Repositoryとか)にも言及している単方向データフローで、Fluxの単方向データフローしか見たことがなかった私にとってはかなり学びがあったので、興味があれば見てみてください。

speakerdeck.com

www.youtube.com

*1:VMを持ち出すと文脈がぼやけてしまいますが、Presentation Domain SeperationにおけるPresentationの中にいるということだけ伝わればOKです。

*2:StoreがViewModelに見えているのは僕の主観です。Modelだと主張したい方の思想を否定するものではありませんので、異論反論はご自身の主張を自分のブログか何かで展開してください。それはそれで僕も読みたい。

*3:Fat Controller相当のものがAction CreatorやReducerの中に増殖して見通しが死ぬほど悪くなったコードをたまに見かけるし書いたこともあります。

#技術書典 #技術書典4 参加してきました(電書&紙の再販情報アリ)

f:id:Nkzn:20180423164947j:plain

というわけで技術書典4に参加してきました!

経緯や意気込みは下記の通り。

blog.nkzn.info

blog.nkzn.info

ざっくりなにしてたの

実は、サークル参加とは別にスタッフやってました。朝6時に起きて、設営作業をしたり、見本誌の確認とかさせてもらってました(ここの人数が足りなくて駆り出された部分が強い)。

とはいえ11時にはリリースさせていただきまして、自分のサークルのほうに戻りました。スペースの設営やら見本誌対応やら、その後の店番をずっとしていてくれた、売り子の@には頭が上がりません。

実績どうでしたか

12時半になる前には100部が完売してました! 皆さん有り難うございました!

そしてその後来てくださった皆さん! 見通しが甘くてホントゴメンな! まさかこんなに来場者多いとは思わんかったんや! 全部晴天が悪い!*1

その後、売り切れた時のために念の為に用意していたダウンロードカードさんも100枚超が売れまして、累計210部ほどになりました。

みんな本当にありがとうございました。

Boothで電子版のダウンロード販売を開始します

はい、というわけで、各所で予告しておりました通り、電子版の販売を開始します。お値段そのまま1000円です。

echigo-ya.booth.pm

Boothで紙版の受注販売を開始します(!!)

さて、こっちが本番です。紙版の再販にチャレンジします。ちょっとお高めの1500円です。

f:id:Nkzn:20180424151805p:plain

流石にもう一度、ちゃんとした印刷所を使って100部とかするのは精神的にしんどいので、1冊からのオンデマンド印刷ができる、製本直送.comさんに印刷をお願いするつもりです。

www.seichoku.com

技術書典4の現地で再販の希望をいくつかいただいて感激したので、こういう形で用意してみました。

これから試しに1冊刷ってもらって出来栄えを見るステータスなので、注文していただいてもちょっと待っていただくかもしれませんが、気長にお待ち下さい。

価格が上がってることについては、初めての試みということでかかる費用についてのリスクを多めに見積もった結果なので、勘弁してほしい・・・!

初めてのサークル参加を終えて

サークル側で同人誌即売会に参加するのは、TechBoosterでコミケのバックヤードをやらせてもらったときに経験済みでしたが、自分がメインとなって出るのは初めてでした。

気持ちが溢れすぎて長文になりそうなので、箇条書きします。

  • 売り子はいたほうが完全に楽
  • 完売は気持ちいい
  • 完売後に来た人たちには申し訳なかった
  • 色んな知り合いが来てくれて嬉しかった(@さんと初遭遇できたのが最大の収穫)
  • 次回もXamaritansとは隣になりたい(合同でネタタペストリーぶら下げようという話をした)
  • スタッフ業もサークル参加もやったおかげで早朝から夕方まで12時間くらいずっと技術書典をやっていられたし、技術書典を今までの3倍くらい楽しめた気がする
  • 完全に人生の中でも最高クラスの1日でした

というわけで最高でした! また今回みたいな技術書典やりたいな!

次回もサークル参加して部数リベンジしたいと思いました。現場からは以上です。

*1:でも次回も晴れて欲しい

#技術書典 #技術書典4 で「Cheap Dive into React Native」を頒布します

blog.nkzn.info

というわけで、2月に予告していたReact Nativeの本ができました。

タイトルは「Cheap Dive into React Native」です。Deep Diveと名付けるのはちょっと面の皮が薄くて無理だったので、ちょっとトーンダウンしてみました。

f:id:Nkzn:20180418152917j:plain

techbookfest.org

配置

き02にいます。XamaritansPEAKSに挟まれてます。

f:id:Nkzn:20180420155037p:plain

配布形態

あれ これ
サイズ B5
ページ数 88ページ
頒布価格 1000円(おつりオペレーションを極限まで軽くしたかった)

表紙について

妻と「オライリーベースで身も蓋もない感じにしよう」と相談しているうちにこうなりました。

どこからどうみてもなかざん本です。

みんな見つけてくれよな!

モチベーション

DroidKaigi 2018ではReact NativeのAndroid向けの内部実装を調べる機会をもらいまして、かなり深いところまで読ませてもらいました。しかし、カンファレンスという枠組みでの50分という限られた時間の中では、調べたことすべてを話すことはできませんでした。

せっかく調べたので、覚えているうちに全部アウトプットしたい!というのが最初のモチベーションです。

また、ここ1年くらいで実案件にReact Nativeを使う機会が多くなってきました。弊社のチーム開発に適した形で運用していく中で、やはり様々な知見が溜まってきています。こういうのはときどきアウトプットしていかないとお腹を壊すので、いい機会として使わせてもらいました。

内容

記事の内容に合わせて、本の中身や思い出話をお話していきます。

  • 技術書典のiOS版後払いアプリ開発を支えたcreate-react-native-app
  • React Native で Android と Web の同時開発にチャレンジした話
  • WebマークアップエンジニアがRNやってみた(寄稿)
  • ReactAndroid Internals

技術書典のiOS版後払いアプリ開発を支えたcreate-react-native-app

blog.techbookfest.org

技術書典の公式後払いアプリのiOS版をcreate-react-native-appで作りました。私が!作りました!

ejectしない縛りの中で得られた、CRNA/Expoの知見を大放出します。CRNAでプロダクションリリースまで持っていった事例はあまりないはずなのでいい経験になりました。

備忘録として、ここ3週間の出来事を書いてみましょう。

日付 出来事
3/13 わかめさんから無茶振りをもらって面白そうやなと思い快諾
3/27 本業のデスマにより原稿もアプリも白紙のままここまで到達(開発開始)
4/2 リリースに向けた証明書周りの準備を開始(主に達人出版会さんに色々お願いするやつ)
4/4 なんとなく完成したのでTestFlight審査に提出
FGO第二部開幕
4/5 本審査提出
4/7 1度目のリジェクト(カメラパーミッションの指摘。本に書きました)
4/8 FGO第二部第一章クリア(感想は本のあとがきに)
4/9 そろそろフル可処分タイムで作業しなくてもいい気がしてきたので自分の本の執筆を開始
4/10 2度目のリジェクト(サインアップへの動線の指摘。本に書きました)
4/11 審査通った
4/15 パブリックリリース&公式ブログ告知&ゼロデイ障害対応(ごめん)
4/17 本書き終わった
4/18 入☆稿

……うん、よくこの状況で90ページも書いた。偉いぞ俺。*1

4/4〜8の可処分時間の使い方については思うところがないわけでもありませんが、私もFをGOしたかったし、許してくれという気持ちでいっぱいです。*2

謝辞

とはいえ、この短期間でアプリを作れたのは、僕の功績というのはかなり少なめです。

僕が手を付ける前にデータモデルの設計と通信周りのベース開発を7割くらい済ませていてくれた@さんと、素敵なAndroidアプリ版を真似させてくれた@の功績がほとんどだと思っています。自分一人でゼロから作っていたら、こんな時間では到底作れなかったと思います。ありがとうございました。

React Native で Android と Web の同時開発にチャレンジした話

React Native for WebやStorybookを使って、ネイティブとWebの同時開発にチャレンジした事例を紹介します。

qiita.com

こいつをプロダクションで使うために設計レベルで実用性を高めた話です。記事の中身は思想の話が多めになってしまったので、Qiitaと併せて読むと実践的になりそう。

WebマークアップエンジニアがRNやってみた

同僚のWebマークアップエンジニアをReact Nativeのプロジェクトに巻き込んだら結構良い感じだったので、エッセイを書いてもらいました。 RNの裾野の広がりを感じられるいい記事です。

ReactAndroid Internals

React NativeのAndroid向け実装について掘り下げた記事としては、おそらく現時点の日本で一番深くまで潜ったものになっていると思います。Androidエンジニアがこれを読むとReactAndroidがちょっとだけ読めるようになるかもしれません。

  • JavaScriptをどうやって動かしているのか
  • JavaとJavaScriptはどうやって通信しているのか
  • ReactからはReact DOMとReact Nativeがどのように見えているのか
  • どこのレイヤーの処理がどこのスレッドで動いているのか
  • requireされた画像リソースはAndroidアプリのどこに配置されるのか

こんな感じのことを書きなぐった40P超の大作です。

DroidKaigiのディレクターズ・カット版と言ったな。あれは嘘だ。

半分くらい書き直したぜ! DroidKaigiで興味を持った人が更に楽しめる内容になっていると思います。

電書版について

当日までに間に合えば、紙版のおまけに電書版も付けられればと思っています。

また、後日Boothで電書版のダウンロード販売も始めたいので、技術書典に来れなかった方はそちらをお待ち下さい。

というわけで

さあ、お祭りだ! 私は好きにした! 君たちも好きにしろ! みんな楽しもうな!

*1:実はCodeZineの連載も並行で書いてたのでもっと書いてる

*2:オマージュです。

React NativeをWeb IDEで試せるExpo Snackしゅごい

本来ならばAndroid StudioやXcodeを導入しなければWorldにHelloすることも難しいReact Nativeですが、create-react-native-appを使うことでnpm/yarnのみで実行できる環境が構築できます。

この魔法のような環境づくりの立役者がExpoなわけですが、実はExpoにはWeb IDEがあることをご存知でしょうか。その名をExpo Snackと言います。

↓こんな感じでブラウザ上でコードを書くと、すぐに動作を確認することができます。

組み込みプレビューはappetize.ioが使われています。これも大概謎の技術なんですが、DeviceFarmとかRemote TestKitに類似の技術を使ってるんですかね。React Native for Webのようなイミテーションではなく、本当にネイティブのシミュレータや実機で動かしている画面をストリーミングしている形だと思います。

Web IDE

ちゃんとExpo Snackで開くと次のようなWeb IDEっぽい見た目になります。

f:id:Nkzn:20180316235159p:plain

左側のファイルエクスプローラからファイルを追加して、モジュールを作ることもできます。

f:id:Nkzn:20180316235337p:plain

また、package.json(モドキ)にdependenciesを追加することで、外部ライブラリも取り込めるので、かなり色々できそうです。今回のサンプルのReact Navigationも、後から追加したライブラリでした。

f:id:Nkzn:20180316235539p:plain

ただ、何でも追加できるというわけではなく @expo/ をプレフィックスに持つExpo向けライブラリや、JSのみで実現されているライブラリだけしか使えないことには留意してください。Expoをejectせずに使うときのルールと同じで、ネイティブコードを含むライブラリは適用できません。

実機での動作

create-react-native-appでExpoを使う時と同じように、QRコードとExpoアプリによる実機デバッグの手段も用意されています。Web IDEの右上から「QR Code」を押すことで呼び出せます。

f:id:Nkzn:20180317000103p:plain

ちゃんと実機で動いていますね。

f:id:Nkzn:20180317000121j:plain

裏側について考えてみる

これどうやって繋げとるん?と不思議になりましたが、Expoアプリの実行履歴を見る限りでは、expo.ioから持ってきているようです。実際、パソコンと同じネットワーク上に実機がいなくても、問題なく表示できました。サーバー側でビルドしてくれてるんですかね・・・

f:id:Nkzn:20180317000804p:plain

デバッグ中の実機をスリープさせたり復帰させたりすると、Web IDE側に通知が出てきているので、リアルタイムで更新をかけるための何かがありそうです。

f:id:Nkzn:20180317001100p:plain

f:id:Nkzn:20180317001107p:plain

DevToolsで見てみると、PubNubによるロングポーリングで通知を受け取っている感じでした。

f:id:Nkzn:20180317001909p:plain

PubNubってCorona SDKの全盛期に対戦ゲームとかの情報をリアルタイムに同期できて便利だよね的な、今でいうAWS CognitoとかFirebase Realtime Databaseみたいな文脈で使われてたやつだっけ・・・(うろ覚え)

ハンズオンに有用かも

ハンズオンイベントを開くと、多くの場合次のようなトラブルが起きます。

  • Windowsでうまく動かない
  • 事前にHelloWorld相当のところまで進めてきてねって言ってるのに何も準備してこない(そしてセットアップしてるうちにその日が終わる)
  • みんながこぞってツールのインストールをするもんだからネットワーク帯域が枯渇する
  • Windowsでうまく動かない
  • そもそもパソコンを持ってこない(実話)

何度か主催した経験で言うと、これらのトラブルは必ず起きるものなので、参加者の啓蒙やドキュメントの整備といった方向で撲滅しようとするのは(無駄ではないものの)割と無理筋な印象です。ハンズオンをどうしても成功させたいならば、次のどちらかの方法が良いと私は考えています。

  • めっちゃ強いインフラと環境構築済みのパソコンを用意して使わせる(どうしても持参したい人は自己責任で頑張れ)
  • Web上のIDEやコンソールだけを触ってもらう

前者は数万円払ってどこかのコンピュータ室で受講するOracleセミナーとかそういう感じのアレで見かけるやり方ですし、後者はGoogle Cloud Shellのハンズオンが典型的でしょうか。

さて、Expo Snackを使った方法は後者にあたります。Expoアプリが入ったAndroidかiOSの実機は必要になります*1が、まあこのご時世なのでスマホを持ってないという人もあまりいないでしょう。React Nativeハンズオンの勝算を高められる選択肢のように感じられます。

実はリリースまで持っていける

右上に「Export to XDE」というボタンがありまして、これを押すとExpoプロジェクトを手元にダウンロードできます。

f:id:Nkzn:20180317004614p:plain

試してないけど、XDEに読み込ませればアプリをexpo.ioにデプロイできそうですし、expコマンドでiTunes Connectにアップロード可能なバイナリを作るようなこともできるんじゃないでしょうか。

まとめ

Expo Snack使うと最低限の環境構築がめちゃくちゃ簡単にできるので、少なくともハンズオン目的でならガンガン使っちゃっていいと思います。

趣味のアプリ開発とかに実用できるかというと、補完とかあんまり効かないみたいなので、ちょっと苦しいのでは・・・という気持ち。でもそれはVSCodeとかと比べて不便というだけなので、頑張ればアプリ一本作れるのでは・・・?という感じもします。

RNの裾野を広げる良いツールだと思ったので、今後積極的に採用していきたいです。

宣伝

最近会社でReact Nativeを前提としたReactエンジニアの求人を始めたので、新潟でReact Native書くぜっていう稀有な方がいればよろしくお願いします。Reactが分かればAndroidやiOSの経験はなくても大丈夫です。

*1:今回試した限りではappetizeは利用制限がかかりやすかったのであまり期待しないほうがよさそうな気がしました

WebとAndroidのレイアウトシステムにまつわる寸劇(妄想)

Android Studio 3.2で、GridLayoutがレガシー扱いされるようになりました。一方で、オワコン扱いされていたような気もする(個人の感想です)TableLayoutは生き残っています。

レイアウトシステムの世代交代に関する妄想劇

勝手な想像なんですけど、こういう流れが垣間見えた気がしました。


Web「tableでレイアウトを組む時代は終わった。BootstrapのGrid System便利やろドヤ」

Android「いいなそれ! TableLayoutなんてもうやめにしよう! GridLayout作ったから使おうぜ!」

Web「Bootstrapみたいなサードパーティのやつを使わずに、Web標準でflexboxっていうのできたからそっち使おうぜ便利だし」

Android「いいなそれ。ConstraintLayoutも十分便利だけど、FlexboxLayoutも作ったからみんな使おうよ」

Web「ところでCSS Grid Layoutっていうの作ってみたんだけどどうかな」(微妙にAndroidのGridLayoutとAPIが似ている)

Android「複雑なものはConstraintLayoutとFlexboxLayoutがあれば問題ないし、軽微なものはやっぱりTableLayoutでいいな。GridLayoutはオワコンにしようか」

Web「えっ」


CSS Grid Layoutに未来はあるのか。これからもレイアウトシステムからは目が離せませんね。

※ CSS Grid LayoutがAndroidのGridLayoutから何らかの着想を得てAPIを組んだのかどうかは知りませんし、たぶん違うんじゃないかなと思います。ただ、こうだったら面白いなという妄想です。