Node.jsを使ったアプリケーションのサンプル集にlernaを使うと便利だった
先日参加した技術書典でFitbitのClock Faceの作り方に関する本を出しました。サンプルコードを添えたのですが、そこで使ったlernaが今回のようなケースと相性が良いと感じたので紹介します。
今回のケース
1つのリポジトリに複数のNode.jsのアプリケーションを配置しました。そしてそれらは同じ devDependencies
を持っています。
複数のアプリケーションが存在していて
. ├── LICENSE ├── README.md └── packages ├── package1 │ └── package.json ├── package2 │ └── package.json ├── package3 │ └── package.json └── package4 └── package.json
それぞれのpackage.jsonに次のような記述がある
{ "name": "package1", ... "devDependencies": { "@hoge": "1.0.0", "@fuga": "~1.0.0", "@piyo": "^1.0.0" }, ... }
問題と思っていたこと
このようなサンプル集のリポジトリで各サンプルを動かしたい場合は、クローンしてきたあとにそれぞれのpackageのなかで npm install
を実行する必要があります。
単純に数が増えてくると手間だというのと、同じ依存関係を持つ .node_module/
が各package配下に重複してできてしまい、ディスク容量を圧迫してしまいます。
簡単にサンプルを実行可能な状態にして、重複する依存関係はよしなに参照するとかしてほしい。
lerna
lernaはmonorepo管理用のツールです。npmに公開するところまでサポートしてます。
今回はlernaの機能の一部を使って問題を解決します。
使い方
新規の場合
$ lerna init
で必要なものを作成できます。
. ├── lerna.json ├── package.json └── packages
packages
の中に各プロジェクトを配置します。
モジュールの追加
モジュールのインストールは各package直下だけではなく、プロジェクトルートで lerna
を使って行えます。
$ lerna add ${モジュール名} --dev
これで packages
配下のすべての package.json
に ${モジュール名}
が追加されます。各package直下で npm install ${モジュール名} --save-dev
したことと大体同じになります。
cloneしてきてから初期化
プロジェクトルートで次のように実行すればすべてのpackageを初期化できます。
$ lerna bootstrap
重複をまとめる
まず既存の node_modules/
を削除します。cloneしてきた直後だと不要です。
$ lerna clean
先程のbootstrapにオプションを付けて実行します。
$ lerna bootstrap --hoist
--hoist
オプションをつけることで、package共通で使うモジュールは プロジェクトルートの node_modules/
にインストールされます。各package配下では、 共通利用しているモジュールのみ node_modules/.bin/
にシンボリックリンクが生成され て利用可能になります。
プロジェクトルートの node_modules/
は lerna clean
では消去できないので注意してください。
今回のサンプルコードだと --hoist
オプションを使うことでディスク容量を半分以下に抑えられました。モジュールの種類や依存状況にもよりますが、 同じようなものを共通して利用するサンプル集のような場合だと、サンプル数が多ければ多いほど効果が出てきます。
- hoistなし
$ du -sch * 4.0K LICENSE 4.0K README.md 4.0K lerna.json 4.0K package.json 518M packages 518M total
- hoistあり
$ du -sch * 4.0K LICENSE 4.0K README.md 4.0K lerna.json 152M node_modules 316K package-lock.json 4.0K package.json 99M packages 252M total
--hoist
オプションを使うとファイル容量を節約できますが、前述の通りpackageから見たら通常 インストールされているモジュールの位置が異なるので lerna
で管理可能なもの以外で パスを参照している場合注意が必要です。
まとめ
lerna
はmonorepoの管理だけでなく、次の場合にも便利です。
- Node.jsのサンプル集を扱うとき
- サンプルの一括セットアップをしたいとき
- ディスク容量の節約がしたいとき
- まとめた場合共通モジュールの参照先が変わるので注意
参考
lerna/lerna: A tool for managing JavaScript projects with multiple packages. / GitHub
技術書典5でFitbit本を出すまで
技術書典5にサークルとして初参加しました。やったことや思ったことをつらつらと書きます。
参加の経緯や意気込みはこちらです。
執筆の流れ
スケジュール感などはこちらの記事を参考にしました。
執筆はRe:VIEWで行いました。と言っても何もわからない状態からだったので、「技術書をかこう! ~はじめてのRe:VIEW~ 改訂版」を一通り読んで、概要を把握しました。
読み終えて、リポジトリを作ってRe:VIEWでビルドしてみたのが8月の頭でした。
執筆環境
結構試行錯誤というか紆余曲折しました。
参考書籍ではAtomを使っていたのでAtomで環境を作ったのですが、重くてしんどかったのでIntelliJでできないか試しました。
.re
ファイルをいい感じに認識してRe:VIEW記法を補完してくれるものがなかったので、IntelliJは諦めました。
次に、プラグインがあったVSCodeを試すことにしました。
Atomより早くて調子は良かったのですが、見出しなどを作成したときに制御文字が挿入される問題があって、無駄にハマりました。
自分の入力の問題かもですが ^H
が挿入されて、Re:VIEWでビルドする際にエラーが起きていました。
それで嫌になってMarkDownで書けないか調べたりしましたが、無駄にハマるのも嫌だなと思いAtomに戻りました。
しかし結局重いのに耐えきれず、制御文字だけビルド時に気をつければ良いVSCodeで本格的に書くことにしました。
技術調査
意気込みでも書いたように、執筆駆動開発にしたので、まずは調査でした。ひとまず自分で作ってみないと話しにならないなと思い、作成しました。
これで作成からリリースまでの流れを掴みました。余談ですが一度リジェクトされました。
大まかな章立ては決めていたのですが、作ったことでどんな項目を解説しようかがより明確になりました。
もくもく執筆レビュー会参加
なかなか火がつかないのと、実際にやらないといけないことなどイメージが湧きにくい部分があったので、「もくもく執筆レビュー会」というものに参加しました。
当初は電子版のみの予定だったのですが、そこで物理本に触れることで気になってきて、作ることにしました。それに伴い真の締切というものを知り、いつまでに書き終えないといけないのかが明確になりました。
印刷
真の締切が近づいてきたのもあり、一旦印刷会社に連絡を取りました。
利用した印刷会社は「日光企画」さんです。選定理由は、技術書典の公式ページにも掲載されていたことと、オフィスが個人的に行きやすい場所にあったためです。
調べたところ、表紙が必要というのがわかりました。そもそも当初は電子版の想定で、「電子版やし表紙なんてないやろ」と思っていたのですが、電子版だろうが印刷版だろうが表紙は必要だってことにギリギリで気づきました。 もちろんデザイナーの方に依頼もしていなかったので、自分で作成しました。
トンボと言われる表紙のテンプレートをDLしてきて、その上で作成しました。 デザインワーク用のツールをSketchしかもっていなかったのですが、トンボのテンプレートが.psdと.aiしかなかったので、Sketchで無理やり開いて作成しました。
同様に入校時にも.psdと.aiを求められたので、こちらのツールで.sketchを.psdに変換しました。 日本語フォントが正しく表示されない問題があったので、文字はパスに変換して回避しました。
電話して諸々確認して、一度伺うことにしました。わりとゆるくて、電話を一度していたからかアポなしで大丈夫でした(いい大人はちゃんとアポをとろう)。
印刷所での確認
表紙と本文は別データで必要になります。自分のタイミングでは、表紙だけ先行入稿が可能なタイミングだったので、表紙のデータと、作成中の本文をPDFで用意しました。まだ内容的に入稿できる段階ではなかったのですが、入校前に気づける物があれば指摘してもらおうと思って用意しました。
古い古いUSBドライブを引っ張り出してきて、データを用意して日光企画さんに伺いました。
どのイベントで使う予定なのか、どんなサイズなのか、どんな形式で印刷するのかなどを確認します。特に印刷に関しては何も考えてなかったので、相談して決めました。印刷を考えているなら一度伺って相談するのがいろいろ安心だと思います。 当初はA4で本文もフルカラーで考えていたのですが、サイズに比例して値段が上昇するのと、本文フルカラーも値段が爆上がりしたので、A5で本文はモノクロにしました。倍以上異なります。サイズを変えるとページ数も変わるので注意してください。
どんなサイズや形式を決めたあとは、表紙データの確認を行います。ちゃんと注意に、一つのレイヤーにしないといけないとあったのですが、自分ができておらず指摘されました。背表紙の計算方法も教わりました。表紙のイラストの位置も、中央じゃなかったのでどこまでが印刷範囲なのかなど教わりました。背表紙の位置は本文のページ数によるので、本文のページ数も決まってないとやりにくいです。
本文データも途中だったのですが、お願いして確認してもらいました。ページの隅にあるページ番号(ノンブル)の指定が、本文の1ページめから目次も含めて最後まで通しの番号が振られていない(通しノンブル)と指摘されました。Re:VIEWでどうすればよいのか頭を悩ませたのですが、「技術書を書こう!」のリポジトリの layouts
や sty
をインポートすることで解決できました。
当日の本の搬入も、技術書典公認の印刷所だったため当日にサークルに持って来てくれるようにお願いできました。
入稿
入稿自体は今回のように直接データを持っていく形と、Webで入稿する形があります。印刷部数もギリギリまでチェック数を参考にして確認したかったので、本文の際も直接伺おうとしていたのですが、結局Webで入稿しました。入稿のタイミングによっては割安や割高になります。真の締切を基準に前後します。自分は2日遅れて15%割増で印刷をお願いすることになりました。日光企画さんでは、真の締切までに入稿できれば無料でポスター作ってくれるサポートがあるのでちゃんと締切に間に合わせるのはおすすめです。
真の締切を超える際は、予約が必要になります。自分の場合は2日遅れてますが、印刷所に持っていった際に予約をしました。予定では1日遅れのつもりだったのですが、間に合わなかったので電話で2日遅れでの入稿と伝えた感じです。
Web入稿のあとは電話が来ると思っていたのですが(フォームに電話番号と電話に出られる時間を入力するため)、印刷完了後にメールが来ました。印刷部数の最終相談を行おうと思っていたのですが、できなかったです。Web入稿を行う際に確認したいことがあればこちらから電話をかけて確認するのがおすすめです。
サークル設置準備
ポスターも作れなかったので、前日に自前でPOPを作成してコンビニで印刷しました。あと細かいものは100均で揃えました。当日持っていったものは以下です。
- 500円硬貨 x 20枚
- 1000円札 x 15枚
- ウエストポーチ
- マスキングテープ
- 鉄製のブックシェルフ
- 磁石
- ネームプレート
- ビニールのテーブルカバー
- A4印刷したPOP
- 大きめで全面ノリの付箋
- 黒マジック
設置したらこんな感じになりました。
設営完了。布あったほうが絶対良い。 #技術書典 pic.twitter.com/0xsnTQlN8M
— Shinya Sakemoto @技術書典5(う14) (@sakebook) October 8, 2018
本は当日、サークルテーブルの下に届けられていました。
「うぉぉ。本だ。。!」って感じがしました笑
50部で印刷をしたのですが、結果的に予備を含めて56部ありました。
サークル運営
ワンオペでした。 売り子がほしかったですが結果的に集められなかったです。一人だったので離席しないように飲食は最低限にしました。途中で技術書典に参加していた同僚が差し入れを持ってきてくれたのは非常に嬉しかったです。結果的に尿意も来ず、離席しないで済みました。逆に言うと、離席していないのでその他のサークルには全く回れませんでした。当日は絶対複数人で行ったほうがいいです。むしろその宛を先に見つけてから応募してもいいかもしれません。
混雑具合は前述の通りずっと席にいたのでわかりませんでした。ただ立地はよかった気はしてます。入場制限で段階的に人が入ってくるのがわかりやすかったです。
接客
卓上にPOPを置いておいたのですが、微妙だと思いました。理由としては、卓上に並べたPOPは目の前に来てくれた人しか目につかないし、目の前に来てくれた人はPOPを見るために目の前に来たわけじゃないから結局見られないからです。POPはあるけどPOPの内容を質問されたりしたのでそう思いました。POPを立体的に飾ることができれば効果があると思います。勉強会のスライドと同じようにフォントサイズも気をつけたほうが良いと思いました。遠目で気づいてもらうのが目的なので。
逆にA4用紙を組み合わせてデカデカと机前に垂らしたFitbitのデバイスはキャッチーさがあった気がしました。個人的には思ったより良くできたと思ったのですが、混雑具合を考えると下の方にあったので見えにくかったかもしれません。
事前のチェック数(当日朝に50超えたくらい)からして、人気のサークルではありませんでした。そのため来客も基本1体1になることが多かったです。立っての接客と座っての接客両方試しましたが、座ってたほうが人の視線がわかりやすいので見本を勧めやすかったです。話は始めたあとは座ってると距離があり、言葉が通りにくいので立って接客したほうが良いです。
立ち読み本というシステムがあったのですが、本が足りないかもと思い利用しませんでした。他のサークルでどの程度効果があったのか知りたいところです。
販売
初めの方は割と売れたのですが、後半になるほど失速していきました。全体のトレンドだったのかもですが、うちのサークルではそんな傾向がありました。最終的に45部売れました。
当日の購入層は、Pebbleユーザが半分くらいいました。FitbitがPebbleを買収した件で恨んでいる人や、乗り換え先を探さないとーって人ばかりでした笑。残った半分の半分(1/4)はFitbitユーザでした。Fitbitというキーワードで来てくれたのですが、対応してるデバイスを持ってる方は少なく、その中でも1/3くらいでした。「この本を買いに来ました」と言ってくれた方がいて、嬉しさで心が震えました。
購入された方の1/3くらいが後払いでした。千円札を15枚用意して、一万円とか五千円が来ても多分対応できるようにして、500円も20枚用意していましたが、準備万端過ぎました。後払いなら現金不要だし、一万円や五千円を使う人はいなかったです。今回は値段を500円にしていたのですが、500円の商品なら500円玉を10枚くらい用意すれば間に合いそうだなと思いました。もちろん販売部数によるので一概には言えないですが。
今回は500円という値段設定にしていたのですが、1000円と迷って500円にしました。 Fitbitを知らない人にも現地で知ってもらって購入しやすいように安い方を選択したのですが、狙った層にはアプローチできませんでした。当日のPOPや事前の宣伝で、そのあたりの意図を明確にして狙った層にリーチできるような宣言文句をするなど改善の余地がありそうです。
今回自分は参加表明のブログくらいしか宣伝できませんでした。サークルカットを早い段階で設定するのは目を引くので良いと思います。また、Tweetする際はリンク先に頼るのではなく、テキストに情報を詰めないと興味を引きにくいなと他の宣伝を見て思いました。
まとめ
月並みですが、サークル参加する場合は次の点に気をつけておくと良いと思いました。
- 売り子の確保
- 表紙の作成
- 事前の宣伝
- 当日の設営物の用意
ちなみに今回販売した書籍で、売れ残った印刷版と電子版はそれぞれbooth.pmで購入できるようにしてあるので興味があれば買ってください。
参考
初めて技術書を書いてみたので、始めから最後まで細かくレポートしてみる / DMM inside
技術書をかこう! ~はじめてのRe:VIEW~ 改訂版【C92新刊】 / BOOTH(同人誌通販・ダウンロード)
技術書典5 もくもく執筆レビュー会 ~進捗はそこにあるか~ / connpass
Photopea / Photopea | Online Image Editor
技術書典5にサークル(う14)として参加してFitbitのClock Faceに関する本を出します
タイトルの通りです。
2018/10/08に開催される技術書典5に、サークルとして参加します。
サークル概要
サークル名は「sakebook」で、配置は「う14」です。
内容は「FitbitのClock Faceの作り方について」です。
どうして参加したのか
前回の技術書典4に一般参加したときに、サークルの人とやりとりをして、あっち側になって来場者とコミュニケーションを取って本が売れたら楽しいなーと思ったので、参加することにしました。
どうしてそのテーマなのか
内容は普段触っているAndroidやiOSではなく、FitbitのClock Faceを作り方についてです。
もともとClock Faceは作りたいとは思っていたのですが、なかなかきっかけを作れなかったので、執筆駆動開発をすることにしました。
現在
鋭意執筆中です。いろいろと初めてなのでわからないことだらけですが、良い本になるように努めます。