ナカザンドットネット

Android Developer's memo

#技術書典 #技術書典6 で資産管理本を頒布します(第1章無料公開あり)

技術書典6にサークル参加します

4/14に開催される技術書典6にサークル参加することになりました。

techbookfest.org

前回、前々回とReact Nativeの本を出してきましたが、今回は少し毛色を変えて、お金の本を出すことにしました。タイトルは「これでカンタン! ITエンジニアが実践するキャッシュレス時代の資産管理」です。

フィンテック関連ということで技術の本を謳っていますが、中身は ユーザーとしてマネーフォワードをがっつり使った人間の事例を紹介するぜ! という、プログラムが1行も出てこない読み物です。

f:id:Nkzn:20190409003532j:plain:w320
表紙

興味を持った方はサークルチェックをお願いします。

techbookfest.org

配置

け76にいます。周りに知り合いがいなさそうでビクビクしています。

f:id:Nkzn:20190409004521p:plain
け76

配布形態

あれ これ
サイズ B5
ページ数 52ページ
頒布価格 1000円(おつりオペレーションを極限まで軽くしたかった)
発行部数 150部(後日BOOTHとKindleで電子版を販売予定)
決済手段 現金、公式かんたん後払い、Kyash、Pixiv Pay、クレジットカード(Square Readerが間に合えば)

キャッシュレスと名のつく本で現金決済を中心にするわけには行かないということに、初稿を書き終えてから気が付いてしまった俺たちは。本当はCoineyでタッチ決済までサポートしたかったのですが、審査に時間がかかりそうなのでパスしました。

表紙について

今回も妻に作ってもらいました。各種キャッシュレス決済サービスが、マネーフォワードに集約されていくイメージです。鉄道網っぽくしました。

「情報の流れ」は東京メトロっぽく、「お金の流れ」はJRっぽくしてあります。伝われ。

執筆体制

今回は、社内でいつも資産管理の相談に乗ってもらっている、同僚であり友人のフロントエンドエンジニア、@_yukikayukiさんに声をかけて、紙面の8割方を書いてもらいました。なかざんは「はじめに」と「第1章 僕らは何度も失敗してきた」でエモ散らかす部分だけを担当して、あとは編集に徹しています。

自分が読みたい記事を書けそうな人に声をかけて書いてもらうムーブを、試験的に実施してみた形です。私のハンドリングがド下手だったので、@_yukikayukiさんにはめちゃくちゃ迷惑をかけた気がします(ごめんね)。

「はじめに」と「第1章」を公開します

そんなわけで、私が書いた部分は特に新しい情報もなく、単に対象読者と心を1つにするためにエモ散らかした儀式的なものでしかないので、この場を借りて事前公開します。

これで興味を持ってくれた方は、技術書典当日にお会いしましょう。150部刷っていくので、まあ売り切れることはないでしょう(フラグ)。当日来れない方は、後日このブログでアナウンスするはずのBOOTH/Kindle版電子書籍をご覧ください。


はじめに

本書は、いかに最小限の努力で、自分の家計や資産を可視化するか、という課題についての知見を共有するための本です。

2010年代の日本では、インターネットやアプリを活用した資産管理であったり、現金を必要としない決済手段(いわゆるキャッシュレス決済)が広く普及しました。これらは金融のためのテクノロジー=フィンテック(FinTech)と呼ばれ、ITエンジニアに人気の事業領域のひとつになっています。 お金は現代社会で生きるために必要なものです。それを扱うフィンテック分野のサービスは、やはり、市井の人々のために作られています。特別なスキルや地位を持った人のためのものではなく、普通の人のためのものです。

しかし、いくら使用者を限定しないとしても、インターネットサービスは、あくまでも道具です。道具とは、その道具が解決できる課題を解決するために使ったときだけ、私たちに恩恵を与えてくれます。まな板で肉を切っても、包丁を肉の下に敷いても、十分な機能が発揮できないのは想像できますね。道具の恩恵を受けるためには、道具の使い方を学ばなくてはいけません。

さて、フィンテックはITエンジニアのためのものではありませんが、ITエンジニアは「インターネットサービスがどのような使い方を想定して生み出されたのか」を察する能力には、ある程度長けています。また、裏側で使われている技術に察しがつけば、フィンテックの各種インターネットサービスを「詐欺かもしれない怪しいアプリ」ではなく、「現代の高度な技術によって実現された便利な道具」として、迷いなく導入する精神性も持っています。加えて資産管理やキャッシュレス決済への関心が高ければ、フィンテックを使いこなすための素養は高いといえるでしょう。

本書では、ITエンジニアである友人の@_yukikayukiが実践している、資産管理やキャッシュレス決済の活用手法について、 書かれたものです。彼は家計簿レベルの管理だけではなく、金融方面の資産についても、無理なく可視化して管理できるようにしています。もちろん、彼も(筆者も)会計や資産運用のプロフェッショナルではないので、そういった分野におけるベストプラクティスをご紹介することはできません。それでも、現代の多様な道具たちを、どんな目的で扱い、どう組み合わせるかという知見は、そこに打つ手が思いつかない人にとっては一定の価値があると考え、筆を取ってもらった次第です。

それでは、現代のITを駆使した資産管理について見ていきましょう。

本書が想定する読者

  • 現在家計簿をつけていないが、お金の流れが見えるようになりたい方
  • 現在家計簿をつけているが、他の人がどうやっているのか知りたい方
  • 過去に家計簿をつけていたことがあるが、日々増えていくレシートを記入・入力していくのが面倒になって諦めてしまった方

免責事項

本書に記載された内容は、情報の提供のみを目的としています。 したがって、本書を用いた家計管理、資産運用は、 必ずご自身の責任と判断によって行ってください。 これらの情報による家計管理、資産運用の結果について、 著者はいかなる責任も負いません。

第1章 僕らは何度も失敗してきた

エンジニアが改善の話をするのは、そこに課題があるからです。本書ではどんなことを課題として扱うのか、一緒に見ていきましょう。

まず、本章では、キャッシュレス導入以前の筆者が、どんな挫折をしてきたのかをお話しします。家計簿を付けるのが上手な読者の方には、やる気のないやつの泣き言にしか見えないと思います。残念ながら、この本は「やる気のないやつがやる気のないまま家計管理ができるようになる」本なので、ご容赦ください。

家計簿の管理に失敗してきた

挫折の歴史の一丁目は、家計簿の管理です。進学や就職を理由に人生初の一人暮らしを始めたとき、家計簿を付けることにチャレンジした人は多いのではないでしょうか。結果はどうでしたか?

そのまま習慣を身につけることができた皆さん、おめでとうございます。

習慣を身に付けられなかった皆さん、筆者のお仲間です。よろしくお願いします。本項では皆さんと一緒に古傷をえぐりながら、課題をみつけていきましょう。

パソコンやスマホに家計簿アプリを入れたけど

流石に21世紀にもなって、若者がキャンパスノートで電卓を叩きながら家計簿を付けるという話もないですよね。元々がズボラな筆者ですから、実行するまでもなく挫折することが目に見えていました。

家計管理の最低ラインがExcelやGoogleスプレッドシート、もう少し便利にするなら、食費や水道光熱費といった費目が入力できるアプリを導入したいところです。

筆者は2005年に大学生になったとき、最初のチャレンジを始めました。当時はWindowsパソコンに家計簿アプリを入れていたと記憶しています。

さて、実際に管理を始めてみた筆者の前に立ちふさがったのはレシートの管理です。買い物をしたら、レシートを財布にしまっておいて、あとでアプリに手ずから入力します。

……筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね。みるみるうちに財布の中はレシートで溢れかえり、レシートを処理する気力が加速度的に減っていく悪循環が始まりました。

f:id:Nkzn:20190409002018p:plain:w320
溢れ出すレシート

もうレシートを処理することは諦めているのに、データを捨てるわけにもいかず、ただただレシートを限界まで財布に溜め込んでは、あるタイミングで諦めて分厚いレシートを捨てる。そんな生活を、10年くらい続けました。

レシートを撮影できるようになったけど

社会人になってから、家計簿の管理をZaimに写した筆者は、素晴らしいソリューションに出会いました。レシートの撮影です。

写真でレシートを撮影すると、レシートに記載された項目が自動で入力される機能は、入力を面倒くさがる筆者にとって、福音であるように思えました。項目名の精度はなかなか難しいようでしたが、金額の読み取りについてはそんなに悪い精度でもなく、筆者は再びレシートとの戦いを志したのです。

……筆者のようなズボラ野郎に、そんな作業が習慣化できるわけなかったんですね(1項ぶり、2度目)。

確かに、レシートからデータを入力する作業は、手入力するよりは圧倒的に効率化されました。アプリに組み込まれたOCR技術を扱ってくださった方々には頭が上がりません。それでも、筆者は習慣化できなかったのです。

これは筋金入りのズボラであり、もうこの類のアプローチを習慣化するのは難しいな*1、と感じつつも、財布にレシートを溜め込む生活はやめられませんでした。

クレジットカードは怖い

家計簿の失敗は、決済手段にも波及します。通帳や財布の中にあるお金は、どのくらい有って、どのくらい足りないのか把握しやすくなっています。

一方で、クレジットカード決済は、単独ではどのくらい使ったのかを把握する方法が、あまり便利ではありません。Webサイトでログインすれば、クレジットカードの利用履歴を見ることは可能ですが、わざわざログインしてまで見に行きませんよね。

クレジットカード決済でもレシートはもらえるので、本当はそれを使って家計簿をつければよいのですが、それができないのは前項で述べたとおりです。

クレジットカードは持っているし、ネット通販ではとても便利に使えます。しかし、家計簿の管理が伴っていない状況での利用は、単に家計のブラックボックスを増やすだけです。

f:id:Nkzn:20190409002015p:plain:w320
クレジットカードこわい

利用状況をリアルタイムで把握しづらいまま、クレジットカードを乱用するのは恐怖でしかないので、日常的な生活費の買い物に使うのは憚られます。

そんな具合で、クレジットカードとは距離を置きがちになっていました。

悪循環は続く

唯一購買履歴がデータ化されているクレジットカードは、履歴が見づらいせいで使う気にならない。

現金のデータはレシートにしかないけれど、レシートをデータ化するモチベーションはない。

それでも諦めきれなくてレシートは溜まる。溜まり続ける。

家計簿の管理が、どんどん遠ざかっていきます。

資産管理に失敗してきた

少し視点を広げて、家計の重要なファクターのひとつである、資産管理にも目を向けてみましょう。

人生を詰みづらくする上で、貯金、投資信託、株、FXなど、資産形成に取り組むのは大事なことです。インターネットの普及によって、個人が気軽に資産形成を始めるためのハードルは、極めて下がりました。筆者も、オンラインバンキングやオンライントレードの概念が現れてから早い段階で、アカウントを作成しています。

そんな中で、筆者はいくつかの失敗をしました。

オンライントレードの口座なんて滅多に開かない

まずは、オンライントレードの話をしましょう。

2000年代(いわゆるゼロ年代)に、デイトレード*2やスイングトレード*3が流行ったことがありました。この頃にオンライントレードのサービスにアカウントを開設した方は、多いのではないでしょうか。

しばらくやってみると分かるのが、そこそこマメな人でないと、デイトレードはおろか、スイングトレードも難しいということです。筆者は、だんだん飽きてきたのもあって、株を長期保有するスタイルに切り替えることになりました。

ここで問題になるのが、オンライントレードの口座を開かなくなるということです。株(や、2019年現在であれば仮想通貨など)は、値動きがあります。

おいくら万円の資産をそのとき持っているのか、という情報は、家計簿にとって意味のあるものです。しかし、それをいちいちWebサイトやアプリで確認して、家計簿につける習慣をもつことは、やっぱりこのズボラ野郎である筆者には、何よりも難しいことなのでした。

オンラインバンキングを開くのは振込のときだけ

オンラインバンキングは、私たちから記帳の手間を奪い去ってくれました。ズボラな人間には最高のツールです。

しかしながら、オンラインバンキングと同じく、残高を確認するモチベーションが少ないという問題が起きました。

口座がひとつしかないのであれば、ある程度頑張れるかもしれません。しかし、実際には、給与受け取り用の口座とは別に、実家との現金授受を行う口座があったり、さまざまな理由でいくつかの口座に資金が分散することがあります。

わざわざ家計簿にデータを反映させるためだけに、すべてのオンラインバンキングの口座を確認する手間はかけられません。

唯一のモチベーションとして、振り込みをするときだけは積極的にログインしますが、あまり頻度の多い作業ではありません。

でも、どの口座に、どのくらい残高があるのか、どのくらい貯蓄があるのかは、本当は知っているべきなのです。

どこにどんな口座があったかなんて、とうに忘れてしまった

資産形成をする上での管理作業は、オンライントレードやオンラインバンキングのおかげで、1990年代に比べて、格段に便利になったはずです。

しかし、やはり筆者はズボラなので、どこにどんな口座があったのかを、自分で覚えておくことができないのです。

なぜ失敗したのか

さて、ここまで失敗談というか、筆者のズボラっぷりをご覧いただきました。

どう考えても筆者に資産管理は向いていないのですが、ここまでチャレンジするのは、次の理念があるからです。

  • 子供の学費や自身の老後のために、資産形成をするべきである
  • 資産をはじめ、家計の状況は管理されるべきである

これらふたつのルールは、独り立ちした大人として、譲るわけにはいかないものです。しかしながら、同時に、認めなければならないことがあります。

私たちは資産管理のために手を動かしたくない!!!!!

このことから目を背けるべきではないのです。レシートの撮影なんかしたくないのです。家計簿アプリの現金残高と、財布の中身を照らし合わせるなんて、もう嫌です。いろんな口座に散らばった資産や負債を取りまとめて、バランスシートを作るのはいいことですが、それを自分で作りたいとは言っていません。

家計は管理されるべきです。意思決定は筆者自身が行うべきです。ですがそれは、データを集めて見やすくする作業を自分でやらなければならない、ということを意味しないのです。

そこから目を背けてしまっていたから、無為に失敗を続けてしまっていたのです。

そうだ、僕らは楽がしたい

筆者が本当にやりたかったことを整理してみると、次のふたつだけだったことがわかりました。

  • 資産状況の把握
  • 資産状況に対するアクション(投資, 節約, 資産売買, 負債解消の優先順位調整など)

前者は把握したいだけなので、それに付随するすべての事務作業は余計なものだ、と言い切ってしまいましょう。後者に必要なやる気やコストについては、今も昔も大きくは変わりません。ここはやるべきこととやりたいことが一致しているので、問題ありません。やる気でカバーできます。

ただでも慣れない資産管理という分野を扱うのですから、瑣末な事務作業に時間を使わず、意思決定に時間を使うべきです。

本書は、そんなふうに考えたITエンジニアたちが実践した、資産管理の方法の本です。

特別なスキルは必要ありません。なんなら、過分なやる気も必要ありません。2019年現在に存在する便利なツールを、本来の目的のままに組み合わせるだけです。

さあ、楽をしましょう。

本書の目指すところ

今回はマネーフォワード MEという株式会社マネーフォワードが提供する家計簿・資産管理サービスを利用し、キャッシュレス生活を行いながら、自動で家計簿を作成できる環境を作るまでを扱います。


最後に

第1章で書いたとおり、私は家計簿に関して、そこそこ悔しい思いをしてきました。近年のフィンテックの高まりや、良き友人を得たことにより、その悔しさはだいぶ報われてきています。

もし、今でも悔しい思いをしている人がいれば、この本を読んで、何かの道しるべにしてもらえれば幸いです。

今回も最高の技術書典にしような! Enjoy!

余談:かんたん後払いアプリのメンテナしてます

今回もかんたん後払いのアプリを担当しました。これはマネーフォワード MEに連携されないのが残念だけど、頑張ってメンテしたから、みんな使ってくれよな!

blog.techbookfest.org

*1:のちに個人事業主を始めてみたところ、経費の月締めやレシートの管理がある程度習慣化できている自分に気が付いたので、明確に義務として与えられている作業ならやれることに気がつきました。モチベーションの置き方次第ではあるようです。

*2:1日の間に株を売り買いする手法

*3:1日よりは長いものの比較的短期で株を売買する手法

ニッチな本で宣伝を怠ると売れないという当たり前の話+α #技術書典

技術書典5が終わりました。

techbookfest.org

サークル参加の皆様、お疲れ様でした。楽しかったね。

来場者の皆様、ありがとうございました。楽しかったね。

おかげさまで、総来場者数が1万人を超える、大きなイベントとなったようです。

弊サークル「越後屋」も、新刊2冊を引っさげてお邪魔いたしました。 React Native for Webの薄い本と、Android入門本です。

echigo-ya.booth.pm

たった1日で基本が身に付く!  Androidアプリ開発超入門

たった1日で基本が身に付く! Androidアプリ開発超入門

さて、イベント自体は大成功だったと思いますが、弊サークルとしては大成功とは言い難い状況になったので、反省会を開きたいと思います。

前回よりかなり売れなかった

技術書典4では開会90分で、100部用意した紙の本が完売、という快挙でした(その後もダウンロードカードが100部ほど出たので、実質200部出ています)。

しかし、今回は100部+50部で用意した紙の本が、70部+32部ほど売れただけに留まりました。赤字ラインギリギリくらいなので、失敗というほどではないのですが、可もなく不可もなくくらいの成果です。

できたら同人活動はキャッシュフローを確保しながらやっていきたいので、改善していきたいところです。

今回の失速の要因となった点を考えていきたいと思います。

宣伝不足

といっても、要因の1つは火を見るよりも明らかだったりします。前回に比べて、全然宣伝をしていないのです。

前回は割とやれてた

技術書典4の際には、2度ほど宣伝のブログを打っていました。

日付 記事
2018-02-04 技術書典4にReact Nativeの薄い本を出します - ナカザンドットネット
2018-04-18 #技術書典 #技術書典4 で「Cheap Dive into React Native」を頒布します - ナカザンドットネット
2018-04-22 技術書典4本番

2度目のブログは本番の4日前なので、入稿直後くらいです。ちゃんと本番の数日前に宣伝をしたというのは効果があったと思われます。

4月の宣伝ブログを書く2日前の時点では、被チェック数が72程度でした。

これが、ブログを書いた翌日に、109まで伸びています。

ブログの内容が激エモだったのは実際あると思うのですが、宣伝の効果が適切に現れた部分もあるのだろうなと考えています。

当日には最終的に、249まで伸びていました。

今回は本当にダメ

さて、それでは今回はどうだったでしょうか。

  • 技術書典5に出るよという記事:書いてない
  • 本の内容の宣伝の記事:書いてない

ブログではまったく技術書典5や新刊について触れていません。

ここで死ぬほどもったいない点としまして、技術書典5の5日前の被チェック数は、技術書典4の6日前の被チェック数と同水準だったのです。

この頃の私は完売しないとも知らずに呑気なものです。

この時点で宣伝をババーンとやっておけば、もうちょっと伸びが見込めたのかもしれません……

実際にはまったく宣伝もしなかったため、緩やかに伸びていくばかりでした。

当日時点でも159となりました。

サークルチェックを付けたからといって来る人は意外と多くないので、やはり200とか300とかの数字がないと、前回ほどの集客は見込めなかったということだと思います。

地道な宣伝、普通に大事だよねというお話でした。

内容がニッチだった

これはまあ、反省点ではなくて世の摂理なのですが、ニッチなものはマスほどには人を呼び集められませんよねということで。

React Nativeというテーマ自体がそもそもニッチなのに、React Native for Webというニッチ・オブ・ニッチを攻めてしまった以上、集客につながらないのは当然でした。

技術書典4のCheap Dive into React Nativeは、ニッチながらもCRNA記事などが広く門戸を開いてくれていたので、そこまでニッチ感は強くなかったのですが、今回はもうレベル設定がめちゃくちゃです。わかるやつだけわかれ!の世界です。

前述のとおり、これについては反省していません。だって、書きたかったんです。私はReact Native for Webの話が書きたかったんです。だから良いんです。これで良いんです。

同人誌は書きたいものを書かなきゃ意味がないんです。入門書を書いた人は入門書が書きたかったから書いたんです。そうじゃないものを書いた人はそれが書きたかったから書いたんです。「好きなものを書く」。こればっかりは同人活動の根幹を支える概念なので、誰にも文句は言わせません。

これに関しては反省する気がないので、次回はしれっと『Anatomy of React Native DOM』みたいな、今回以上のどニッチを攻めていく可能性があります。ご期待下さい。

反省会おわりです。

技術書典5でやったこと

それでは最後に明るい話題として、技術書典5に対して私が貢献したことについて並べておきたいと思います。

  • 朝から会場設営のスタッフやってました
  • 開会ギリギリまで技術季報をトートバッグに詰める作業をやってました
  • 閉会後は会場撤収のスタッフやってました
  • 公式後払いアプリのAndroid版も担当しました

サークル参加しながらスタッフするの、当日の充実感が半端ないです。体力的に翌日に死ぬので、オススメはしません。

あとね、後払いアプリのAndroid版ね。

blog.techbookfest.org

ふと気づいたらAndroid版もReact Native(というかExpo)で私がやることになってました。2ヶ所ほど軽微な改修を入れるだけでAndroid対応ができたので、そこのところはやっぱりExpoよくできてんな、という気持ちでした。

もともとTypeScriptで作ってあったので、何回かあった仕様変更にも比較的容易に応えられたのはとてもよかったと思います。

まとめ

技術書典6はもっとちゃんと宣伝しようと思いました。

今更ながら宣伝ですが、今回の新刊をBOOTHで出してあるので、技術書典に来れなかった皆さん購入を頼みます〜!!🙏

echigo-ya.booth.pm

「たった1日で基本が身に付く! Androidアプリ開発超入門」という本が出版されます

来る9月21日(金)に「たった1日で基本が身に付く! Androidアプリ開発超入門」という本が技術評論社さんから出ることになりました。電子書籍版もあります。

たった1日で基本が身に付く!  Androidアプリ開発超入門

たった1日で基本が身に付く! Androidアプリ開発超入門

人生初の商業向け単著です! しんどかった。世の中の単著erの皆さんすごい。

いろいろ思い出があるので、出版にあたってのあれこれを書いてみようと思います。

どんな本なの?

プログラミング未経験者やAndroid未経験者の方が、本の内容で手を動かしながら(いわゆる「写経」をしながら)Java言語やAndroid Studioの使い方を学んでいく本です。

初学者向けの本にするにあたって、次の3点を工夫しています。

  • Android Studioを日本語化して、できるだけ解説に英語が出てこないようにする
  • Java言語についての解説は最低限にする
  • レイアウトはGUIエディターのみで行う

余計な前提知識を求めると、躓いてしまう方もいそうだったので、できるだけ前提知識を求めずに、学びたいことをストレートに学べるようにした形になります。

Android Studioの日本語化

Android Studioを日本語化したおかげで、解説の中で出てくる文言の多くを日本語にすることができました。

見慣れないアルファベットの単語が入り混じった文章はコンテキストスイッチが多くなりそうなので、良い取り組みだったと思います。だからといってカタカナが大量に出てくるようになったのが良かったのかというと怪しいですし、ScrollViewのようなクラス名はそのまま表記しているので、どのくらい読みやすさに寄与したのかは、読者の感想を待ちたいところです。

Javaを説明しすぎない

本書はプログラミング未経験者を対象にしているため、Java言語についての解説も行いました。写経していく中で登場する、変数やメソッドといった最低限の要素だけを解説しています。

思い切った点として、クラスについての解説をほとんどしていません。クラスの書き方を解説し始めると際限なく話題が膨らんでいくためです。

自作のクラスを活用せずにAndroidアプリを作っていくと、自然とFat Activityになります。それ自体は後々に問題を引き起こす可能性はあります。ただ、それが問題になるくらいにコードをたくさん書けるようになった人なら、本書ではなくもっと別の本がフィットするようになっているはずです。

この「たった1日で」シリーズの良さは薄さや手軽さです。「Android Javaの正しさ」を語り過ぎないようにしたつもりなので、読者がサクサク読み進められたらいいなと思います。

レイアウトエディターはデザインモードのみ

レイアウト作成の解説は、レイアウトエディターのデザインモードのみで行いました。レイアウトの解説にXMLは登場しません。ここは筆者のこだわりです。

XMLを書きながらプレビューを見るスタイルも筆者は好きですが、初学者時代を思い出して見ると、JavaとXMLを行ったり来たりするのは地味に心が折れそうになるポイントだった記憶があります。

現代のAndroid Studioには、ConstraintLayoutを用いた、そこそこ実用的といえるWYSIWYGなレイアウトエディターがあります。これならば心理的な障壁が幾分か低くなるのではないかと考え、全編で採用しました。ドラッグ&ドロップで制約を付けていく作業については、限られた紙面の中で、できるだけ丁寧に解説したつもりです。アプリ開発の醍醐味のひとつ、レイアウト作成を楽しく体験してもらえればと思います。

余談として……本書はAndroid Studio 3.1.4向けに書いたので、Android Studio 3.2で導入されたナビゲーションエディターを用いた画面遷移の定義は盛り込めませんでした(そもそも画面遷移を取り扱う紙面の余裕もなかったのですが:-p)。2019年に似たような本が出てくるときには、是非ナビゲーションエディターの解説も含まれていてほしいなあと思います。

執筆の経緯

技術評論社さんで刊行しているたった1日で基本が身に付く!シリーズのAndroid Studio版を作ろう、という企画が先にあり、1月に知人を通じて声がかかりました。まさに降って湧いたようなチャンスだったので、最低限の調整だけを行って、ほぼ二つ返事でOKしました。

それまでに書いたことがあった中で最も長い本は、88Pの技術書典4本でした。

blog.nkzn.info

200ページ超の執筆は初めてだったので、かなり不安もありました。とはいえ、ここまで大きいチャンスは滅多に来ません。多少自信がない程度で逃すわけにもいかなかったのでした。

当初の予定では5月くらいまでに書き上げて、7月刊行くらいのスケジュールを引いていた気がしますが、筆者の遅筆が原因でずるずると延びて、8月入稿となりました。関係者の皆さんにはご迷惑をおかけしました。

執筆の体制

執筆の体制については、ざっくりと次のような感じです。

  • 編集プロダクションとのやり取り
    • GitHubとSlackでIssue管理と連絡を行う
  • 執筆環境(メンタル)
    • 集中できるようにネットカフェに入り浸る
  • 執筆環境(システム)
    • VivlioStyleでMarkdown+CSS組版で書いた
    • Macで書きたいがためだけにVPNを張ってリモートデスクトップを設定した
    • 初稿の差分管理はGitで行う
    • 以降の校正作業はPDFベースでコメントを付ける

日本語の文章の差分管理にもGitを使うのが有用なのは、プログラマーの間では認知されてきていることですね。

個人的に面白い取り組みだった、CSS組版とリモートデスクトップについて掘り下げます。

CSS組版

今回の本は編集プロダクションのリブロワークスさんと一緒に作ったのですが、リブロワークスさんではVivlioStyleというCSS組版のツールにMarkdownを組み合わせた執筆環境を用意してくれています。

f:id:Nkzn:20180906232000p:plain

libroworks.co.jp

Atomにプラグインを入れておけば、実際の本と同じような見た目でプレビューしながら、執筆を行うことができます。

ReVIEWにもリアルタイムプレビューを行うツールはあったので、執筆体験としては既知の(素晴らしい)ものでしたが、こちらのほうがより実物に近い形で実現されていたので、楽しく執筆できました。

リモートデスクトップ

今回の本はWindows向けなので、Android Studioの動作確認やスクリーンショットの撮影はWindows上で行う必要がありました。一方で、私は普段Macを使っており、指が最もスムーズに動くのはMacです。Emacsキーバインドに指が汚染されているし、XKeymacsは好みじゃないので仕方ないですね。

Android Studioの操作がWindowsに準じたものになるのは問題なかったのですが、Atomで日本語を入力していくときにWindowsのお作法に縛られるのは嫌でしたし、Windows上に快適な環境を作り上げる労力を払うのも嫌でした。

仕方がないので、MacからWindowsマシンにリモートデスクトップでアクセスし、Android Studioを触ることにしました。Windows側で撮影したスクリーンショットは自動でDropboxのフォルダに入るようにして、ほぼリアルタイムでMac側に共有されるようにしました。

また、前述のとおり、ネットカフェでの作業が多かったため、自宅の外からでもWindowsマシンに繋がるよう、VPNを設定しました。これで快適な執筆環境の完成です。

f:id:Nkzn:20180906233450p:plain

この環境ができるまで、なかなか文章を書き始められなかったので、担当さんをやきもきさせてしまって非常に申し訳なかったです……

グランドスラム達成

ここは本の内容と関係ないです。

今回の出版のおかげで、これまで本の形で執筆してきたものリストが次のようになりました。

タイトル 出版年月 出版 形態
はじめる! Corona SDK 2011年7月 達人出版会(商業) 電子書籍(単著)
TechBoosterの同人誌 随時 TechBooster(同人) 紙・電子書籍(共著)
Effective Android 2013年8月 達人出版会(商業) 電子書籍(共著)
Effective Android 2014年1月 インプレス(商業) 紙(共著)
Cheap Dive into React Native 2018年4月 越後屋(同人) 紙・電子書籍(単著)
たった1日で基本が身に付く!
Androidアプリ開発超入門
2018年9月 技術評論社(商業) 紙・電子書籍(単著)

この表を読み換えてみると、なんと、(商業|同人)、(電子|紙)、(単著|共著)の組み合わせを全パターン網羅しているのです。

  • 商業・電子・単著(Corona SDK)
  • 商業・電子・共著(Effective Android)
  • 商業・紙・単著(たった1日で)
  • 商業・紙・共著(Effective Android)
  • 同人・電子・単著(Cheap Dive)
  • 同人・電子・共著(てくぶ)
  • 同人・紙・単著(Cheap Dive)
  • 同人・紙・共著(てくぶ)

グランドスラム達成は言い過ぎかも*1ですが、ちょっとした達成感があります。

この7年間、いろいろ書いてきたんだなあ、としみじみしてしまいますね。本を書く楽しさを教えてくれた皆さんには感謝するばかりです。

今後も、機会を見つけて本を書いていきたいと思いますので、よろしくお願いします。

まとめ

妻や編集さんに助けてもらいながら、何とか本を書き上げることができました。この規模になってくると、とてもじゃないですが自分の力だけでやりましたとは言えません。本づくりって色んな人の力で成り立ってるんだなーと思いました。

筆者がAndroidをやり始めたときにも、多くの書籍に助けられました。私の本が、現代の初学者の助けになれば、望外の喜びです。この本で入門した読者が5年後くらいにDroidKaigiで登壇してたりしたら泣くので、そういう方がいれば5年後にお声がけください。

書店にPOPとか持ち込んだら置いてもらえるのかな……

*1:紙媒体の雑誌連載とかはしたことないですしね

React Nativeの光と闇について喋ってきました #上越TechMeetup

f:id:Nkzn:20180723164831j:plain

7月21日(土)に新潟県上越市で行われた、上越TechMeetup#2に参加してきました。

jtm.connpass.com

町家を改装したイベントスペース「高田小町」で、総勢15名での、和やかな雰囲気での開催となりました。

なんでいったの

主催の五十川さんがRNの話を聞きたいということでお呼ばれしました。上越は地元なので、地元で行われるIT勉強会にお呼ばれなんて、テンションがダダ上がりになる事案です。

個人的なところとして、2010年ごろに上越である程度の規模のIT勉強会を開催することを諦めて新潟市で開催していたという事情がありまして、自分が諦めたことを実現した勉強会を是非応援したいという気持ちもありました。

なにしたの

React Nativeの光と闇というタイトルで講演してきました。スライドは次のとおりです。

www.slideshare.net

細かい内容は後述します。

他の方の発表

印象に残ったお話だけ。

writer.appの話

f:id:Nkzn:20180723163347p:plain

https://writer-app.com/

自動文字起こしのWebアプリです。実用上のニーズから生まれているので、使いやすさはピカイチとのこと。

FirebaseやGCPをモリモリ使っているのは楽しそうだなあと思いました。

EventEmitterの話

@さんから。ブラウザの文脈にEventEmitterを持ち込むと、Reactで小さいアプリを作るときにpropsのたらい回しとかしないで済むことがあって良いよ、というお話でした。

序盤は「えー、いうてEventEmitter氏、大規模に乱用するとプロジェクトが崩壊するじゃないですかー」と思いながら聞いていました。途中で当人から「まあ、規模が大きくなってくるとReduxとかのほうが管理しやすくなるんですけどね」という話があったので、安心して聞いていられました。

SOC2の話

クラスメソッドの植木さんから。↓の裏話について。

classmethod.jp

ISMSなんかも「面倒くさそうだなあ」と思いながら傍から見ていたのですが、これは輪をかけて面倒くさいやつのようです。

「おおお、そこまで監査するんだ偉い」みたいな気持ちで聞いていましたが、自分たちではあんまりやりたくないですね・・・。

React Nativeの光と闇

ざっくりとした内容としてはこんな感じです。

光パート

  • Reactはレイアウトツリーの差分更新が得意なライブラリだよ
  • React NativeはReactの得意分野をネイティブビューの更新に持ち込んだやつだよ
  • AndroidとiOSの同時開発ができるのは嬉しいね
  • react-native initで作ったプロジェクトはXcode/Android Studio経由でビルドすることが多いよ
  • デモ:ハロワとちょっとしたLive Reload
  • React NativeはC++処理系の上で動くJavaScriptCoreの上で、バベったJSを動かしてるよ
  • JSとC++の間の通信方式はWebKitが担保してるので素性がいいね
  • C++とObj-C/Javaの間の通信もそれぞれのOSで普通のやり方があるので素性がいいね
  • デモ:create-react-native-app(Expo)でQRコードリーダーを作る
    • デバッグ時に突如コンソールに現れるQRコード
    • カメラパーミッションの請求も、カメラプレビューの配置も、読み込んだQRコードのデータ受け取りも、Expoならサクサクやれちゃう
    • JANやIMEIのバーコードも読めちゃう
    • ねっ、簡単でしょ?
  • Expoクライアントアプリが色々隠蔽してくれてます
  • 活用事例

闇パート

  • 万人にオススメできるわけではない
  • 無理を通した帳尻合わせを、腕力で何とかしている部分がある
  • 腕力の例
    • エラーメッセージを読む力
      • JSC, Android, iOSのエラーメッセージが混在するので、メンバーの誰かはそれを読めないとしんどい
    • ビルドする力
      • リリースビルドするときは、JS文化圏、Android文化圏、iOS文化圏のそれぞれのお作法を押さえておく必要がある
      • なお、Expoは知らないままビルドしても何とかなる部分が多い
      • Expoは楽なんだけど、本来のやり方を知らないままでいくとトラブったときに身動きが取れなくなるので、やはり本来のお作法を知っている人間はいたほうがよい
    • ストアにリリースする力
      • Google Play ConsoleとかAppStore Connectを使うのは同じ
      • 何にせよAppleの審査員とは闘う
    • バージョンアップする力
      • RN自体のバージョンアップが結構しんどい
      • アップグレードコマンドも失敗することがある
      • マジiOSお前
      • 困ったらreact-native initから環境構築をやり直したほうが早いというのが現状

光と闇のはざまで

  • 技術選択は組織と事業に見合ったものを選ぶべき
  • 普段使っている、責務が小さいライブラリなら、組織や事業との相性を深く考えなくてもリスク少なめで採用できたりする(失敗しづらい)
  • RNはメリットもデメリットも大きいので、よく考えないと採用しづらい
  • Airbnbは結果的に去ってしまったけれど、どんな組織と事業にマッチしそうなものなのかを僕らに考えさせてくれた
  • メリットは最大限享受して、デメリットを可能な限り回避したり打倒したりできる、そんな組織や事業で採用したいですね
  • もしあなたが目指す組織・事業の途上でRNが役立てられそうなところがあったら、使ってみてください

感想

「光と闇」なんて大風呂敷を広げてしまったせいで、自分の中での意見のバランス調整が大変でした。闇パートを先に仕上げたのですが、気持ちがネガティブになってしまい、なかなか光パートを書き始められないという事故があったり。

僕はRNの話をするときに一番怖いのは、オーディエンスが「React Nativeは銀の弾丸である」と思って、誤ったワクワクを持って帰ることです。そのため、普段から闇の話を多めにすることにしていますが、おかげで「お前はRNが嫌いなのか?」と言われることもあります。そうじゃないのです。闇って言っちゃってますが、実際には解決すべき課題たちなのです。課題を解決するためのコストがメリットに対してめちゃくちゃ軽いならば、限られた条件において銀の弾丸っぽいものになることはあると思います。結局は組織と事業にマッチするかどうかです。

とはいえ心配ばかりしていてもReact Nativeの良いところが世の中に伝わらないんだよなあ、とも思っていたので、今回は思い切って光の話もしてみました。Webの人がブラウザ上ではどうやっても獲得できないQRコード読み込みを、超サクッとやってみせるというデモをしただけですが、刺さる人には刺さったんじゃないでしょうか。

また、ノージャンルのIT勉強会だったので、オーディエンスにどの程度の知識を要求したらいいのかという点でもかなり迷いました。ざっくりとReactという概念を先に説明することで、なんとかJSに普段触れ合っていない人向けにも理解度を上げられたのではないかと思います。

今までRNの話は東京でコンテキストの近い人たち向けに喋ることが多かったわけですが、今回の資料作りで新潟向けの難易度調整みたいなところが分かってきた気がするので、今後はもうちょっと県内でも喋ってみたいです。

懇親会

写真を取り忘れましたが、ビアバッシュでした。おしゃべりしてたらほとんど食べてない(いつものこと)。

うちこういう仕事すること多いんだけど、RNマッチすると思う?みたいな話をちらほらもらいました。

総括

f:id:Nkzn:20180723164930j:plain

主に現地の上越や、新潟県内からの参加者が多い感じでしたが、長野や石川からの参加者もおり、上越地方ならではの顔ぶれという感じの特色あるイベントになっていたと思います。

10年前にこのイベントがあれば私は新潟市に移住しなかったかもしれないもしもの話をしても詮無いことなのですが、是非育ってほしいイベントです。

今後とも発表を中心に、応援していけたらと思います。

Android Studioを立ち上げるのが億劫になってコマンドラインだけで済ませたAndroid出身React Nativeエンジニアの指の動き

AndroidエミュレータでRN製アプリのデバッグをしようと思ったのですが、なんとなくAndroid Studioを立ち上げてエミュレータを起動してRunボタンを押すのが億劫になってしまい、指の赴くままにコマンドラインからアプリを起動してみました。

何も考えないで指を動かしただけなので、もっと良い方法があるかとは思います。読んでもよく分からなかった人は真似せずAndroid Studioを起動してください。

エミュレータを立ち上げる

エミュレータの作成はAndroid Studioを通したほうが楽ですが、作成済みのエミュレータはコマンドラインからでも起動できます。

$ $ANDROID_HOME/tools/emulator -list-avds # 作成済みのエミュレータ一覧を出す
Nexus_5X_API_26
Pixel_API_24
Pixel_C_API_25
$ $ANDROID_HOME/tools/emulator @Pixel_C_API_25 # エミュレータを指定して起動する
emulator: emulator window was out of view and was recentered

emulator: ### WARNING: /etc/localtime does not point to /usr/share/zoneinfo/, can't determine zoneinfo timezone name
emulator: ### WARNING: /etc/localtime does not point to /usr/share/zoneinfo/, can't determine zoneinfo timezone name

本来は $ANDROID_HOME/tools にはPATHを通してあるので、ただ emulator と打つだけでも起動できますが、説明のために冗長にしてあります。

これでエミュレータの起動を待ちます。

bundlerをスタートしておく

最終的には react-native run-android を使うので、そのときに一緒にbundlerを立ち上げてもらえるのですが、諸々の事情でyarn startに単純なstart以外にも処理を仕込んである場合などがあると思います。うちの場合はキャッシュに悩まされてつらかったことがあったので --reset-cache を必ず付けるようにしてたりします。

そんな事情から、 run-android とは別にbundlerを実行しています。ターミナルのタブをひとつ占有させてあげる感じですね。

$ yarn start
yarn run v1.5.1
$ node node_modules/react-native/local-cli/cli.js start --reset-cache
Scanning folders for symlinks in /path/to/rnapp/node_modules (51ms)
 ┌────────────────────────────────────────────────────────────────────────────┐
 │  Running Metro Bundler on port 8081.                                       │
 │                                                                            │
 │  Keep Metro Bundler running while developing on any JS projects. Feel      │
 │  free to close this tab and run your own Metro Bundler  instance if you    │
 │  prefer.                                                                   │
 │                                                                            │
 │  https://github.com/facebook/react-native                                  │
 │                                                                            │
 └────────────────────────────────────────────────────────────────────────────┘
Looking for JS files in
   /path/to/rnapp


Metro Bundler ready.

Loading dependency graph, done.

エミュレータのデバイス名を確認してrun-androidする

エミュレータとbundlerの準備ができたら、あとはアプリを起動するだけです。

react-native run-android にdeviceIdオプションを付けると、インストール先の実機やエミュレータを指定できるので、先程起動したエミュレータのdeviceIdを調べるところから始めます。

$ $ANDROID_HOME/platform-tools/adb devices # エミュレータや実機のdeviceIdを調べる
List of devices attached
emulator-5554   device # これがエミュレータのdeviceId
$ npx react-native-cli run-android --deviceId emulator-5554 # Androidでアプリを起動する
npx: 41個のパッケージを4.999秒でインストールしました。
Scanning folders for symlinks in /Users/y.nakagawa/dev/an-lite-app/packages/app/node_modules (46ms)
JS server already running.
Building the app...

adbでdeviceIdを調べると、大抵はemulartor-5554が出てきます。面倒であれば調べずに決め打ちでemulator-5554を指定してもいいのかもしれません(というかよくやります)。

コマンドが react-native run-android ではなく npx react-native-cli run-android は特に意識の高い話ではなくかなりズボラな話で、何だか面倒になってreact-native-cliをグローバルにもdevDependenciesにもインストールしなくなった*1ので、このときだけ使えればいいやというモチベーションで使っています。この方法の問題として、yarn startとrun-androidで使っているcliの実装が違っているけどいいの?という話はあって、いつか痛い目を見そうな気はしています。

まとめ

Android SDKのemulatorやadbといったコマンドの動きが指に染み付いている人間はこういう変な起動の仕方をすることがありますが、こんなことを新しく覚えるために学習コストを払うくらいなら素直にAndroid Studioを立ち上げたほうが賢明だと思うので、どうしてもやってみたい方以外は真似するのはオススメしません。

*1:たまにしか使わないし・・・

React NativeをWebに持ってくることの意味

React Native for Webは、React NativeをWebに持ち込む試みです。

しばしば、こういった試みに対して「わけがわからない」「本末転倒である」といった意見を見かけますが、筆者は妥当な試みであるという印象を持っています。ちょっと頭の中にあるものを出してみようと思います。

ブラウザはGUIアプリケーションプラットフォームではない

まず前提となっている思想として、 WebブラウザはGUIアプリケーションプラットフォームではない 、というものがあります。ブラウザは元々ドキュメントビューアであり、Webページで情報を閲覧するためのソフトウェアであり、アプリケーションのランタイムではなかった、という立場です。

HTMLもCSSもJS(vanilla jsね)も、綺麗でセマンティックでインタラクティブなWebサイトを作るための進化を遂げましたが、元々がドキュメントビューアなので、アプリを動かすためのフレームワークとしては無理が残ります。

巨大な配列データのリストを省メモリで表示できる仕組み、ユーザーの言語や地域の設定に合わせて自動で表示言語を切り替える機能など、AndroidやiOSであれば当然持っている機能はブラウザには搭載されていません。ダウンロード処理や非同期処理を伴うならばぜひ使いたいプログレスバーも、インジケータ(ぐるぐる)も、標準では搭載されていません。

ブラウザで同じようなことをしたいと思ったら、人気っぽいJavaScriptライブラリやCSSフレームワークを選定し、導入する必要があります。これは「ドキュメントビューアを頑張ってGUIアプリケーションっぽく動かすための作業」です。頑張りの大半をライブラリ製作者が担ってくれているために実感しづらいですが、筆者はそう思っています。

これはブラウザがGUIアプリケーションプラットフォームとして劣っているという話をしたいのではなく、そもそもドキュメントビューアなので、GUIアプリケーションが作りづらいのは自然なことである、という話です。divもspanもul/liも、それらを装飾するCSSも、GUIのレイアウトを組むことに特化した作りをしているわけではないのです。

Flexboxについて

ちょっと主張がブレるように思われるかもしれませんが、Flexboxはアプリ開発に向いているなあ、と思っています。Webサイトを作っていく上でも役立つので、別にアプリ開発のために作られた機能というわけでもないと思うのですが、AndroidのLinearLayoutやiOSのStackViewなど、類似の機能がアプリ開発の現場では欠かせない状況になっているので、これが登場したときには本当に嬉しかった・・・

React DOMはGUIアプリケーションフレームワークではない

ブラウザそのものがGUIアプリケーションプラットフォームでないのであれば、何らかのフレームワークを噛ませることで、ある程度GUIアプリケーションを作りやすくなりそうですよね。筆者はしばらくの間、「React DOMを使ったらブラウザをGUIアプリケーションプラットフォームであるかのように扱える」と思っていました。

さて、現実を見てみましょう。

Reactは、DOMをいくらかの単位で切り分け、コンポーネントとして扱わせてくれます。Reactは、データの更新に対するDOMの更新を最低限に抑えてくれます。Reactのおかげで、複雑なインタラクションを最低限のコストで管理できるようになりました。

これで、どんな複雑なWebサイトでも構築できます!

…………………………

……………………

…………

……やっぱりGUIアプリケーションのフレームワークという感じではないぞ……?

「ドキュメントビューアを頑張ってGUIアプリケーションっぽく動かす」ためのコストを下げてくれる存在であることは間違いないのですが、レイアウトを組むために必要な頑張りの方向性は、楽になっただけで(これはこれでもちろん重要なんですが)、あまり変わっていません。

React NativeはGUIアプリケーションプラットフォームの抽象である

AndroidやiOSはGUIアプリケーションプラットフォームです。React Nativeは両者の上でGUIアプリケーションを構築させるためのツールを用意するにあたり、AndroidやiOSにあったものを共通化する形で「GUIアプリケーションを作るなら大抵こういうのが必要でしょ」というコンポーネント群やモジュール群を用意しました。

特にコンポーネント群には嬉しいものが多いです。基本となるViewText以外にも、ぐるぐるを出してくれるActivityIndicatorや、巨大な配列データを省メモリでリスト表示できるFlatList、挟めばスクロールさせてくれるScrollView、進捗を表示するProgressBar/ProgressView、引っ張って更新のRefreshControlなど、 「無きゃ無いでどこかから調達してくるなり自作なりするけど、あるなら嬉しい」 が揃っています。もちろん足りないものもあるので自作することもありますが、GUIアプリケーションを構築していくにあたっての最低限のベースとしては充実していると思います。

この抽象はAndroid/iOSをベースに生み出されたので、AndroidとiOSでしか有効でないものと思われがちですが、実際にはプラットフォームを限定しない抽象化を行っているため、react-native-windowsreact-native-macosといった、他のプラットフォームの抽象化にも成功しています。

React Nativeは「あらゆるGUIアプリケーションプラットフォームを抽象化するフレームワークである」と言えるのではないかとすら、筆者は感じています。

React Native for Webがブラウザに持ち込んだもの

Webブラウザ上でGUIアプリケーションを構築しようとした場合にも、React Nativeの「GUIアプリケーションを作るなら大抵こういうのが必要でしょ」というコンポーネントのラインナップは、やはり有効です。

React Native for Webは、ネイティブアプリをブラウザ上で再現しようとしたものではありません。React Nativeが提唱したGUIの抽象化を、Webアプリケーションの世界でも使えるようにした、ブラウザ向けのReactコンポーネント&便利モジュール集ライブラリです。

React Native本家のテクノロジスタックとは異なり、次の図のような構成になっています。

f:id:Nkzn:20180529203426p:plain

たまたまReact Nativeと似たようなラインナップのコンポーネントが、たまたま似たような名前のpropsを持っていて、たまたまReact Nativeと似たようなスタイルを持っている、ただそれだけです。スタイルやpropsに関する思想をReact Nativeに寄せてあるだけで、ライブラリとしてはmaterial-uiOnsen UIに近いとすらいえるでしょう。

コンポーネントが便利

というわけで、ただのブラウザ向けReactコンポーネントとしてみた場合に、どんなコンポーネントがあるかというと、

  • ぐるぐるを出してくれるActivityIndicator
  • 挟めばスクロールさせてくれるScrollView
  • 進捗を表示するProgressBar
  • 引っ張って更新のRefreshControl

こういうのが普通に使えるわけです。便利ですね。

スタイル周りも良い感じ

GUIアプリケーション、特にモバイルでの動作を意識したスタイルが最初から効いています。

例えばScrollViewには次のような特性があります。

  • 細かい設定をしなくてもScrollViewの中には慣性が効く
  • 細かい設定をしなくてもScrollViewの中身がオーバースクロールする

例えばこういうの↓を書いただけで、画像が縦にズラッと並んで、慣性スクロールも聴いて、一番下まで行ったらちょっとオーバースクロールもさせてくれるわけです。

<View>
  <ScrollView style={{flex:1}}>
    <Image />
    <Image />
    <Image />
    ...
  </ScrollView>
  <Text>画面下部に固定のテキスト</Text>
</View>

このへんはMobile Safariに苦しめられたことがあったので、地味に嬉しいです。

また、React NativeではレイアウトにFlexboxを採用しているのを踏襲して、次のような特性も持っています。

  • 常に display: flex が効いてる
  • flexDirection のデフォルト値が column (縦並び)

毎回 display: flex を書かなくていいのは完全に楽ですし、モバイル向けのアプリではアイテムを上から下に並べることが多いことから、flexDirectionを指定する機会が減るのも助かります。

TouchableOpacityでタップ表現もラクラク

TouchableOpacityは「タップイベントに応じて囲んだ内側のViewの透明度を変えるフィードバックを表現する」ためのコンポーネントです。

<TouchableOpacity onPress={() => { /* タッチイベント */}}>
  <View /> // 自作のボタンっぽいもの
</TouchableOpacity>

上記のようなコンポーネントを作った場合、内側のViewには一切タッチイベントに関する設定を行わなくても、簡単なフィードバックを実装することができます。

f:id:Nkzn:20180529200955g:plain

他にもいろいろあるけど

GUIアプリケーションを作る際に便利なあれこれが詰まっています。

React Native本家とコードの共通化、みたいな文脈もないわけではないですが、それよりも、単純にWebアプリ開発を便利にしてくれるツールだと思ったほうが気楽に試せると思います。

触ってみたくなった方向けに、create-react-app上にReact Native for Web環境を置いたボイラープレートを用意しておいたので、触ってみてください。

github.com

プロダクション事例が強すぎる

実は、PWAの事例として有名なTwitter Liteは、React Native for Webの事例でもあります。

Twitter LiteはReact Nativeによるネイティブアプリ版が存在するわけでもなく、純然たるWebアプリです。

こういった活用ができる程度には、React Native for WebはWebアプリ開発の文脈で有用なものであると筆者は考えます。

作者のnecolasも語ってた

https://twitter.com/necolas/status/983769332411805697

↑から始まる一連のツイートで、React Nativeそのものやfor Webの可能性について語っています。アツいです。

まとめ

React Native for Webは、React Nativeによって抽象化された「モバイルアプリ開発の当たり前」をブラウザの世界に持ち込んでくれる存在です。

単純にWebアプリ開発の負担を軽減してくれるところもありますし、ネイティブアプリ開発の出身者が初めてWebアプリ開発に携わったときに経験しやすい「えっ、こんなことも自分で工夫しないといけないの」を、いくらか軽減してくれる効果も期待できます。

ScrollViewなどを単独で使うこともできるので、皆さんのWebアプリの一部に取り込んでみてはいかがでしょうか。

余談:React系のアプリケーションフレームワーク

Reactベースでありながらまったく別のコードベースで開発が進められているフレームワークたちを挙げてみます。

  • React Native
    • Android, iOS向けのGUIアプリケーションフレームワーク
    • ネイティブ実装部分を差し替えただけのサードパーティ実装もある
      • react-native-windows(Windows)
      • react-native-macos(macOS)
      • react-native-dom(ブラウザ)
    • この辺の話は先日の記事が詳しい
  • React Native for Web + React DOM
    • ブラウザ向けのGUIアプリケーションフレームワーク
    • React Nativeのコンポーネントを模倣している
  • React 360
    • VRアプリのためのGUIアプリケーションフレームワーク
    • React Nativeのコンポーネントを模倣している
  • Ink
    • ターミナルのためのCLIアプリケーションフレームワーク
    • 独自の生態系を構築している

はい、Inkをオチに使いたかっただけです。

<Color green>
  {this.state.i} tests passed
</Color>

f:id:Nkzn:20180529205525g:plain

完全に独自の生態系ですよ・・・この発想はなかった・・・

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

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

nlab.itmedia.co.jp

golden-lucky.hatenablog.com

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

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

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

続きを読む