axiosでGraphCMSのデータ取得
{ posts { title } }
jsから
const endPoint = "https://api-apeast.graphcms.com/v1/xxxxxxxxxxxxxx/master" const authToken = "xxxxxxxxxxxx" const res = await axios.get(endPoint, { params: { query: `query { posts { title } }` }, headers: { Authorization: authToken } }) console.log(res.data)
※ フロントから叩く場合はfunctionsとかかませてtokenは環境変数で。
Nuxtプロジェクト内で使われてないコンポーネントを探す
- プロジェクトが進むと役目を終えた使わないコンポーネントが出てくる
- 放置していくとどれが使っててどれが使ってないかわからなくなってくる
- 使わなくなったコンポーネントの代わりに作られたコンポーネントの名前が似てると最悪みがある
- 「このコンポーネントだろう」と思って変更してみたら「残念!そっちじゃありません!」みたいなやつ
- 使わなくなったタイミングで削除するのがベストだけどそうもいかないのが現実
という感じで、使われなくなったコンポーネントを削除したい。
使われなくなったコンポーネントを見つける
webpackのプラグインでビルド時に使われていないコンポーネントが探せる。
unused-files-webpack-pluginを使って一覧を出す
nuxt.config.js
の build.plugins
に追記する。
const { UnusedFilesWebpackPlugin } = require('unused-files-webpack-plugin') export default { // 省略 build: { plugins: [ new UnusedFilesWebpackPlugin({ patterns: ['src/**/*.vue', 'src/**/*.js'] }) ], } }
patterns
はビルド時に使われてないファイルをフィルターするオプション。
['src/**/*.vue', 'src/**/*.js']
を指定すると、 src/
ディレクトリ内でビルド時に使われてない .vue
と .js
ファイルが一覧で出力されるようになる。
build の実行
nuxt build
を実行すると、次のような出力が得られる。
... Entrypoint app [big] = aaa5230fc2fc8d2d7264.js a4af7f6bc00ce5633bbf.js b2deabd0e786c068c1e3.js 9d7368b9e3e8d6ddd2a4.js WARNING in UnusedFilesWebpackPlugin found some unused files: src/components/lp/AppFooter.vue src/components/lp/ShareButtons.vue src/components/lp/SocialLinks.vue src/components/organisms/AppFooter.vue src/components/organisms/AppPage.vue src/modules/generate_route.js ...
ここに出てきたファイルを ビルド時に使われてない = 不要
とみなして削除。
実際は使ってないけど import
されてるファイルは出てこない
使わなくなったけど、使われているコンポーネントから import
されてる場合、使われてないファイルとしてはでてこない。
たとえば次のような場合
<script> import AppFooter from '~/components/lp/AppFooter' export default { layout: 'lp' } </script>
AppFooter
は使われてないけど import
しているコンポーネントが使われているのでunusedではなくなる。ESLintなりでチェックして潰していきましょう
Nuxtプロジェクトじゃなくても
unused-files-webpack-pluginは名前の通りただのwebpackのプラグインなので、webpackでビルドしてるプロジェクトなら使えます
開業届を出しました
開業しました
— じまぐ (@nakajmg) 2019年3月12日
会社はやめてません。
副業はじめてました
半年前くらいから継続してやってく副業をやりはじめて、本業と並行して続けていけそうだったので開業届を出しました。
屋号は技術書典のときに使ったサークル名から「PONYHEAD」にしました。
現状2案件を受けてるので直近では受けられないですが、タイミングとご縁があったらお仕事のご相談まっております。
やってる(やってた)こと
本業と同じくフロントエンドをやってます。JavaScriptが書きたいのです。
ウェルプレイドではWELLPLAYED JOURNALというesportsに関するメディアのお手伝いをしてます。esportsに関わる仕事やりたいな〜と思ってたので楽しくやっております。
※ 2019年半ばくらいで契約終了しました。
ROXXではback checkというリファレンスチェックを行う新規サービス開発のお手伝いをしてます。HRテックに興味もあり、VueでごりごりSPAが書けて楽しいです。
エンジニア募集してるらしいです。
ランチでもどうすか?
— まさあき (@masaakikunsan) April 1, 2019
https://t.co/96kl1YOojL #bosyu #エンジニア
エンジニアの体験副業を募集開始してみました!
— kotamat | SCOUTER CTO (@kotamats) 2019年4月2日
興味ある方はお気軽に御連絡ください!ランチとかでも大丈夫です。
体験副業からSCOUTERで働いてみたいエンジニア募集!
https://t.co/8BJX64Er32 #bosyu #エンジニア
社会性を取り戻す戦い
フルリモートな会社に勉めて6年目になるんですが、どんどん外に出る回数も少なくなりこりゃいかんなと思い始めてたので、人との接点が増えて今のところよい感じです。
本業+副業2つという感じなのでわりとパツパツで時間の管理が大変ですが、その分だけ収入が増えたので頑張りたい所存です。
収めるぞ税を。
宇田川町あたりで作業してる日があるので渋谷近辺の人はランチのお誘いお待ちしております。
Vue.jsのrender関数(JSX)に思いを馳せた結果
この記事はVue.js #2 Advent Calendar 2018の18日目の記事です。
Vue.jsを使った開発では、特別な理由がない限り.vue
ファイルで記述するのが主流かと思います。.vue
の場合、テンプレートの定義は<template>
で行うことになるでしょう。
自分も何の疑問が湧くことなく<template>
を使っていましたが、ある日ふとrender
関数に思いを馳せ、いくつかの個人プロジェクトで試してみました。
Vueのrenderについて思いを馳せてる
— じまぐ (@nakajmg) 2018年6月29日
本記事では、その試行錯誤から得たrender
関数についてのあれこれを記しています。
<template>
がコンパイルされるとどうなるか
render
関数の前に、まずは<template>
がコンパイルされるとどうなるかについて目を向けてみます。
.vue
の<template>
をコンパイルした結果どのように変換されるのか、あまり知らずにVue.jsを使っている方もいるかと思います。意識せずとも使えますし、別に知らなくても特に問題となるようなものでもありません。
<template>
はcreateElement
を使った関数になる
たとえばApp.vue
の<template>
を次のように定義します。
<template> <div id="app"> <HelloWorld/> </div> </template>
これがコンパイルされると、次のような関数に変換されます(見やすいように整形してます)。
var Appvue_type_template_id_54d52fb2_render = function() { var _vm = this; var _h = _vm.$createElement; var _c = _vm._self._c || _h; return _c("div", { attrs: { id: "app" } }, [_c("HelloWorld")], 1); };
このように<template>
はcreateElement
でVDOMを作成する関数へと変換されます。
変数名のAppvue_type_template_id_54d52fb2_render
から、これがApp.vue
の<template>
をrender
にしたもの、と読み取れます。
render
といえば、render
関数ですね。
render
関数の基本
render
関数は<template>
と同じく、Vueコンポーネントにテンプレートを定義するためのものです。
簡単なコードは次のような感じになります。
export default { data() { return { msg: "hello render function"} }, render(h) { return h("div", {}, this.msg) } }
render
関数は引数にcreateElement
を受けるので、それをh
という名前にして使うのが一般的な作法です。
render
関数がコンパイルされるとどうなるか
render
関数で定義したものをコンパイルするとどうなるでしょう。
次のrender
は前述した<template>
の例をcreateElement
を使ったものに置き換えたやつです。
export default { render(h) { return h("div", { attrs: { id: "app" } }, [h(HelloWorld)]); } }
これをコンパイルすると次のようになります。
var Appvue_type_script_lang_js_ = ({ render: function render(h) { return h("div", { attrs: { id: "app" } }, [h(HelloWorld)]); } });
コンパイルされる前と一緒になりました。render
関数でcreateElement
を使って定義されたテンプレートは、変換の必要がない(そのまま実行できる)ということになります。
【ネタ】ビルド速度を突き詰めるとcreateElement
!?【真似しないで】
これは計測もしてない完全な推測ですが、いろいろなものを犠牲にしてもいいなら、ビルドの速度を速くするだけのために<template>
を捨ててcreateElement
にする、みたいなのも考えられるかもしれません。
考えられないし絶対やらないですけど。
宣言的vs命令的
.vue
の<template>
は宣言的にテンプレートを記述できるのが特徴であり、一つの利点です。render
関数はこれと逆を行くもので、関数によってDOMを組み立てるように命令を記述します。
では命令的な記述が必ずしも宣言的なテンプレートに劣っているか?と言われると全くそうではないと思います。それぞれにメリデメがありますし、何を選択するかは使う人に委ねられているでしょう。
ただしcreateElement
をそのまま使ってテンプレートを定義するのは実用に耐えるものではない(めんどくさいし読みづらい)と思います。
createElement
は現実的じゃないけどJSXは結構いける
render
関数ではJSXが使えます。JSXでの記述は、createElement
以上<template>
未満レベルで宣言的であると思います。
ちなみに、Vue CLI V3で作成したプロジェクトはBabelのプリセットに@vue/app
が指定されていて、この中にJSXを使うのに必要なものが入っているので、パッケージの追加インストールなしにJSXが使えます。
export default { render(h) { return <div id="app"> <HelloWorld/> </div> } }
JSXを使ったrender
はcreateElement
に変換される
render
関数でcreateElement
を使った場合は、コンパイルされても変化はありませんでしたが、JSXを使っている場合はcreateElement
を使った関数に変換されます。
次のコードは上記JSXの変換結果です。
var Appvue_type_script_lang_js_ = ({ render: function render(h) { return h("div", { attrs: { id: "app" } }, [h(HelloWorld)]); } });
前述したcreateElement
を使ったrender
関数と同じものに変換されました。
render
with JSXの可能性を探る
「VueでJSX使うくらいならReact使えばよくない?」みたいなことを何度も見たり聞いたりしますが、そんな単純な話ではないと思います。
Vueの書き味やエコシステムといった部分に乗っかりつつ、要所要所でテンプレートをJSX(render
関数)で書くのは何もおかしいところはないと思います。
JSX(render
関数)の可能性を探るために、<template>
を使わずにJSXだけを使ってアプリケーションを作成してみました。そこから得た知見?と感想をまとめておきます。
JSXとcreateElement
は共存できる
属性やイベントを細かく指定したい場合、JSXで書くよりcreateElement
のほうが記述しやすい場合があります。JSXとcreateElement
は共存できるので、次のような書き方もできます。
render(h) { return <div id="app"> <HelloWorld/> {h("div", {}, "hoge")} </div> }
JSXで書いているとピンポイントでcreateElement
を使いたい場面もでてくるかと思いますので、覚えておいて損はないです。
render
でしかできないこと
render
ではできて、<template>
ではできないことがいくつかありました。
components
に登録せずコンポーネントを使える
import
したコンポーネントを<template>
で使う場合、components
またはVue.component
で登録しないと使えません。
render
関数はJavaScriptのスコープにいるので、import
したコンポーネントは登録せずに使うことができます。前述しているrender
関数の例ではHelloWorld
コンポーネントを使ってますが、components
に登録せずに使っています。
import HelloWorld from './components/HelloWorld.vue' export default { render(h) { return <div id="app"> <HelloWorld/> </div> } }
使うコンポーネントが増える度に、わざわざcomponents
に登録する手間がrender
ではありません。
別ファイルの定数をそのまま使える
前述したコンポーネントと同じ話ですが、別の.js
ファイルに定義した定数をコンポーネント内で使う場合、computed
やdata
に割り当ててからでないと<template>
からは参照できません。
render
関数ではimport
した値はそのまま使えます。
import constants from './constants' export default { render(h) { return <div id="app"> {constants.message} </div> } }
イベントなどをすべて定数にする
<template>
で@customEvent
な記法をするときに、このcustomEvent
の値を変数を参照する形で定数にしたい、と思っていろいろ試したができませんでした。
render
関数では次のように記述できます。
import Channel from "../components/Channel.vue" import types from "../store/types" import events from "../variables/events" export default { name: "Channels", render(h) { return h(Channel, { class: "Channel", on: { [types.REACTION_TO_MESSAGE]: this.reactionToMessage, [events.CLICK_REACTION]: this.reactionToMessage, }, }) }, // ...省略 }
$emit
やdispatch
などに使うイベント名を定数にして、テンプレートで同じ値を参照して使うようにできます。
(<template>
ではcomputed
でオブジェクトを返してv-on
に指定することでできなくもないが、これ以外の方法があれば教えて欲しい。)
vueのtemplateでv-onのイベント名を変数に入れた文字列で指定する方法ってあるっけ?computedでオブジェクトにしてからの指定はできるんだけど直接参照する書き方がわからん。render関数でやるみたいに全部定数化したい
— じまぐ (@nakajmg) 2018年10月30日
render propで<div>
を挟まない
HOCに代わるパターンとしてrender propが市民権を得つつあります(もう得た?)。
Vueでrender propをする場合、スコープ付きスロット(scoped slot)を使うことになりますが、<template>
はルート要素として<slot>
を許容しないので、<div>
で挟む必要があります。
render
関数であれば、次のように記述することで綺麗にrender propできます。
render(h) { return this.$scopedSlots.default({ message: this.message, }) }
Vueの文脈で"renderless component"というワードがあるんだけど、どう見てもrender propsなので別の名前つけないで欲しいと思いました
— じまぐ (@nakajmg) 2018年12月13日
すべてはJavaScriptに
<template>
を使わずに書いていると、<style>
も削れないかな?と思ってしまうのが人間。
そんな願いを叶えてくれるのがvue-styled-components
JSX+vue-styled-componentsを使うと、もはや.vue
にする必要もなく.js
ですべてを記述できます。
import styled from 'vue-styled-components' import HelloWorld from './components/HelloWorld.vue' const Wrapper = styled.div` padding: 1em; font-size: 1.5em; text-align: center; ` export default { render(h) { return <Wrapper> <HelloWorld/> </Wrapper> } }
ただし、ここまで来るとさすがに「これVueでやる必要あるか〜???」という声が自分の中から聞こえてきます。
(この組み合わせ、別に推奨してるわけじゃないです。)
Vue 3.0が来たらワンチャン?
Vue 3.0ではTypeScript対応が強化されるとのことなので、.tsx
で書くのがわりと普通な状況も来そうだなと予想しています。そうなるとJSX+vue-styled-componentsも候補にあがってもおかしくないのかなと思います。
おわりに
いろいろと書きましたが、Vueのrender
関数(JSX)に対する印象が少しでも変わったなら幸いでございます。
Vueのtemplateとrender、どちらも一長一短という感じだ。結局適材適所みたいなとこに落ち着く
— じまぐ (@nakajmg) 2018年10月28日
Nuxt.jsが気になるならNuxt.jsビギナーズガイドを読めばいいと思う
Nuxt.jsビギナーズガイドを著者の@potato4dさんよりいただきましたので、読んでみての客観的な感想を記しておきたいと思います。
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発
- 作者: 花谷拓磨
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2018/10/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
ちなみますと、自分のNuxt.js経験は0.10系からで、個人/業務を問わず採用した経験があります。
超実践的ビギナーズガイド
まずこの本を一言で表すとしたら超実践的ビギナーズガイドです。
本書ではフレームワークの解説にありがちな「それドキュメント読めばよくない?」的な、機能を羅列して紹介するようなことをしていません。一貫してアプリケーションを作りながら機能を覚えていくというスタイルを取っており、手を動かせば動かしたぶんだけ強くなれるような内容になっています。
作っておしまいではなく、アプリケーションをデプロイする方法についても数パターン紹介されています。
また、Nuxt.jsだけではなく、FirebaseやJestといった、実際に使う機会が多そうなライブラリも一緒に学べます。
Nuxt.jsのポテンシャルを知れる
Nuxt.js公式のAPIのドキュメントを見るとわかるように、Nuxt.js独自の機能はそこそこ数があります。しかしながら、これら機能の中にはドキュメントを読んだだけでは便利さに気づけないような機能もあります。
自身の経験として、Nuxt.js使い始めのころは「middlewareってこれいつどこで必要になるの?誰向け?」な状態で、Nuxt.jsの持つポテンシャルを十分に理解していませんでした。middlewareの強さは、実案件で必要になった機能を実装するのにあれやこれやと調べたうえで使ってみてやっとのことで理解しました。
本書ではパブリックなAPIからデータをfetchして表示したり、認証の機構を追加したり、プラグインを使ってみたりと、実際に作りがちなアプリケーションを例にNuxt.jsの機能を解説しています。その過程で「こんな機能を実装したい場合にはNuxt.jsのこれを使えばよくて実装方法はこうですよ」というのを簡潔に、段階的に理解できます。
本書を読みきればNuxt.jsの全容をほぼ知っている状態になれると思います。
テストも書けるようになる
本書ではVueコンポーネントやVuexストアについてのテストについても書かれています。これらテストについては、本質的にいうとNuxt.jsではなくVue.jsのテストですが、どういった指針で何をどうテストするかについて、コンパクトにまとまった内容で学べます。
Nuxt.jsを使ったプロジェクトをはじめるとき、もしVueコンポーネントのテストを書いたことがない人がいても、本書を読んでもらえばきっと大丈夫です。
個人的お気に入りチャプター
テストについて書いてあるのもビギナーズガイドらしからぬ(?)ポイントでとてもよいのですが、自分の個人的なお気に入りは最終チャプターの「最新情報キャッチアップのススメ」です。このチャプターは次のような内容になっています。
- 関連情報のキャッチアップ方法
- ドキュメント翻訳への貢献方法
- 関連するSlackやDiscordチャンネルの紹介
ライブラリやフレームワークは1回覚えておしまい、とはいかないのが現実です。更新に合わせて新しい機能を調べたり、困ったときに検索したりと、都度都度アクションが必要になります。しかし情報にアクセスする方法と、その必要性に気づけないままだと、そういったアクションも起こせません。
最終チャプターでこの道標を提示することで自走できるように後押しをする、そんな著者の気づかいが表れているかのようなチャプターです。本書の底本でもある「Nuxt tech book」でも同様の内容について触れられていますが、これを商業本の単独チャプターとして乗せる心意気にあっぱれでございます。
ちょっとでもNuxt.jsに興味があるならオススメ
はじめに触れたとおり、本書はNuxt.jsの超実践的なビギナーズガイドです。もしNuxt.jsを使ってみようかなと思ったら、まずは本書を読みながら一通りの機能を試してみてください。
本書を読んだあとにNuxt.jsを実戦投入すれば、まるで強くてニューゲームのような状態で開発に臨めるでしょう。そんな本でした。
Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発
- 作者: 花谷拓磨
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2018/10/17
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
入門者じゃない人にこそ読んで欲しい「Vue.js入門」
Vue.js入門を@kazu_ponさんより頂きました。ありがとうございます。
遅くなりましたが、読んだ感想を残しておきたいと思います。
- 作者: 川口和也,喜多啓介,野田陽平,手島拓也,片山真也
- 出版社/メーカー: 技術評論社
- 発売日: 2018/09/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
感想の前に
自分は専業のフロントエンドエンジニアです。Vue.jsの使用歴は4年ほど。個人・案件を問わず多くのプロジェクトでVue.jsを採用した経験があるので、正直に言うと本書の対象からは少し外れてるかなと思います。
それでも本書からは得られるものがありました。
入門だけじゃない内容
タイトルこそ「入門」とついていますが、ページ数(460P)から想像できるように、カバーしている範囲がすさまじいです。
入門して終わりではなく、入門から修了までの道筋が記されています。よくある入門本にあるような「簡単な使い方はわかったけどこっからどうしたらいいの?」といった状態にはならないと思います。
整えられた情報たち
今までVue.jsで「これどうやるのかな?」と思ったときは、ドキュメントを見るか検索してそれっぽいものを探すかでした。
そうやって調べて知見を溜めていくのもいいですが、本書はそういったネット上に散らばっていたような情報が詰め込まれています。
情報を詰め込んでいるだけでなく、整理され、必要なタイミングで得られるようにしっかりと道筋が整えられています。
本書から始めると効率めっちゃいいと思います。
つまみ食いするように読める
入門する人は最初から、そうでない人は途中の章から読めるように章立てされています。
Vue.jsでSPAを作ったことがある人なら、8章からの「中規模・大規模向けのアプリケーション開発」から読んでもいいと思います。
入門する人も本書を最後まで一気に読み切る必要はなく、まずは1章から3章くらいまでを読めば、Vue.jsの基本的な使い方が把握できると思います。
個人的なオススメポイント
本書の個人的なオススメポイントはコラムです。
技術書には本線となるテーマが章ごとにありますが、コラムは本線に入れるとちょっとノイズになるような「知らなくても支障が出るものじゃないけど、知ってると周辺知識の理解が深まるもの」だと思います。コラムと合わせて前後の文章を読むことでさらに理解が深まります。
本書をすでに持っているけど読んでいないという人も、まずはコラムだけでも目を通してみると新しい発見があるかもしれません。
Vue.jsに興味があるすべての人にオススメできる圧倒的入門書
はじめにいったように、本書は入門から修了までをとてつもないボリュームでカバーし、解説しています。これから始める人も、すでに始めている人も、本書を読めば得られるものが確実にあると思います。
- 作者: 川口和也,喜多啓介,野田陽平,手島拓也,片山真也
- 出版社/メーカー: 技術評論社
- 発売日: 2018/09/22
- メディア: 単行本(ソフトカバー)
- この商品を含むブログを見る
もしVue.jsに明るくないメンバーがプロジェクトに参加するようなときには本書を読んでもらえばいい、そんな本が出てきてくれて感謝の極みです。
技術書典5でVue.js本を出してみた振り返りとか
はじめてのサークル参加
技術書典4で一般参加して「なんか出す側のほうが楽しそうだなぁ」と思ってサークル参加してみた。
大変なこともあったけど、結果的にめちゃくちゃ楽しめた。
頒布したもの
Vueのコンポーネント設計の本。テストのしやすさという観点から、これまでVueを使ってきて感じたアンチパターン的な話と、コンポーネントの分類、テストのやり方なんかを書いた。BOOTHでDL版販売中です(宣伝)
本にするネタ
今回はVue Fes JapanのCFPに出して落ちたネタがあったので、それを本にまとめる形にした。
「売れる内容を考える」みたいなのはしなかったけど、興味を引くようにタイトルは何個か案を考えて最終的に「後悔しないためのVueコンポーネント設計」にした。
執筆環境
PDF生成のために執筆環境構築が必要になる。
はじめは自力での構築を試したが、つらくて挫折した。結局TechBoosterのリポジトリをcloneして使った。
レイアウトもそのまま使って(見た目にこだわる優先度が低い)設定ファイル、表紙、本文だけ自前のものにすればPDF生成までできて楽だった。ビルドは用意されてるdockerコマンドで。
エディタはVSCode。Re:Viewプラグインは次のやつを使用。
本文を書く
とにかく書く。お仕事で技術文書をそこそこ書いているのもあって、執筆自体が全く苦ではないのでスムーズに完了した。
CFPを出すときに練りまくったので、構成と内容の流れみたいなのはちゃんとできたかなと思う。CFPを書くときは次のやつを何回も読んだ。
今回本にした内容は、自分の経験から感じていたことや考えていたことを文章に起こす形だったので、無理なく書けた気がする。
ただ構成とかページ数の関係で削った内容がぼちぼちあるので、それはまたの機会に発散したい。
表紙を作る
表紙は妻にイラストを書いてもらった。
かわいいでしょ。
入稿する
本文と表紙ができたらあとは入稿するだけ。
今回は技術書典のバックアップ印刷所であるねこのしっぽさんを利用した。イベント当日にブースまで本を運んでもらえるの超楽なので助かった。
プランは「ねこスパーク」という締切遅めだけどそこそこ安いやつ。
入稿はまず申し込みフォームからページ数やサイズを入力、利用するプランを選択して申し込み。
その後、本文だけのPDFファイルと、表紙と背表紙をそれぞれPSDファイルでアップロード。アップロードしたファイルで印刷してOKですよ、というの印刷会社に伝えるUIがあるので入稿完了状態にする。
入稿完了後「コードブロックがはみ出してるけどこれは意図してるやつですか?直しますか?あと表紙用のPSDのサイズがちょっと合ってないから少し拡大しますか? 」と確認の電話があった。
コードブロック、一行が長いと割とすぐにはみ出す(印刷所からの電話で気づいた😳
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年9月28日
修正して再度アップロードして入稿完了の報告をWebで。その後もう一度電話があり問題ないとのことで無事印刷に進めた。
細かいところまで見てくれて大変助かった。また次もお願いしたいと思いました。
DLカードの準備
冊子のほかにPDFのダウンロード版も用意した。
印刷は名刺の印刷でググって出てきたとこに適当に決めた。
入稿用のテンプレートがアプリケーションごとにあったので楽だった。
表面に光沢のある用紙を選択したけど、出来上がりを見てマットなやつで角丸とかにしたほうがよかったかな?と思った。
DLカードの表面は表紙をそのまま使って、裏面にPDFをDLするためのURLとQRコードとZipファイルを解凍するためのパスワードを書いた。
個人名刺もついでに作った。
PDFファイルを置く場所
よくあるDropboxで〜ユニークなURLを〜みたいなのがめんどくさそうだったので、BOOTHにパス付きzipファイルを置いて0円でDLしてもらう運用にした。
下書き状態があるので、あらかじめ商品を登録してURLを決めておいて、そのURLをDLカードの裏面に印刷し、当日の朝に公開した。
技術書典の次の日からBOOTHでDL版を買えるようにしたかったので、あらかじめページを作っておいて次の日に公開処理だけすればよい状態にしておいた。BOOTH使いやすい。
事前に準備したもの
サークル向けガイドラインを読んで、ブースの設営に必要そうなものを準備した。
以下持ちこんだ物
- お釣り(1000円札40、5000円札2)
- 頒布物の価格は1000円のものだけ
- 見本誌を立てるやつ*2
- 見本誌を取ってもらいやすくするように2つ
- 冊子売り切れたときには完売札を立てた
- ポスター吊るすやつ
- 机に広げる布
- 布はあったほうが圧倒的にサークル感が出る
- スケッチブック
- 見本誌マークや完売札を作ったり、いろいろ使える
- マッキーのセット
- ハサミ
- スケッチブックで書いたものを切り取る
- 養生テープ
見本誌立てはなんとなく2つ用意していったけどわりと正解だったぽい。見本誌を結構読んでもらえた。
#技術書典 設営完了。 こ32 でお待ちしてます pic.twitter.com/2RAFWxnYbD
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月8日
(自分の文字を書く能力はレベル1のまま止まってるので、全部妻に書いてもらった)
決済方法
今回使えるようにしたのは次の3つ。
- 現金
- 技術書典かんたん後払い
- pixiv Pay
圧倒的に現金が多かった。お釣りの千円札をかなり用意したけど、1万円札or5千円札を出してきた人は合わせて6人くらいでほぼ使わなかった。参加者の人もお釣りがでないように崩してきてる感あってやさしい世界。
かんたん後払いは70部くらい。かんたん後払い用のQRコードは運営側で用意してくれていて、スタンドとして立てられるようになっていて大変よい感じだった。感謝。
pixiv Payは圧倒的に認知が少ないのか、使ってくれたのは6人だった。この利用人数だとサークル側としてはオペレーションが複雑になるだけなので、次回はなしかな〜?といったところ
被チェック数
自サークルの配置場所はこ32
。サークルリストを見るとわかるんだけど、リストの下から9番目の位置。500近いサークルがある中でめっちゃ後ろの方にあるので、サークルリストからサークルカットでのチェックに頼ると伸びが悪いだろうなと思った。
ということでこのリストからのチェックはあまり重視せずに、Twitterからの流入で被チェック数が伸びるといいなと思って何回かつぶやいた。
Vueコンポーネントの設計とか分類とかテストについて書いたやつを出しまーす https://t.co/OnfFiyIBYQ#技術書典 pic.twitter.com/MmgeL59Tgv
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年9月12日
#技術書典 Vueのコンポーネント設計の本出します。設計に合わせて何をどうテストするかについても書いてます👐
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年9月26日
サークルチェックもよろしくおねがいします👇https://t.co/OnfFiyIBYQ pic.twitter.com/Ui8xnWJ9bX
月曜日は #技術書典 よろしくおねがいしますhttps://t.co/OnfFiyIBYQ pic.twitter.com/vP5ETDJODF
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月6日
つぶやくときは#技術書典
のハッシュタグをつけて、出すものの内容とサークルページへのリンクをセットで。
被チェック数の推移
被チェック数は開催3日前くらいまではゆるやかに伸びて、そこから一気に増えた。
- 9/12: 15
- 9/27: 50
- 10/2: 77
- 10/4: 103
- 10/7: 181
- 10/8: 270
最終的な被チェック数は270。
これは読めない。読めないが、この伸び方は理解できる。
前回自分が買う側で参加したとき、サークルチェックしたのは前日の夜&当日の朝だった。早めにチェックしてるのは多分サークル参加する人たちで、一般参加の場合は直前にチェックするのが合理的な行動っぽい。
印刷の部数
今回は250部刷った。初サークル参加だし、Vue.jsというテーマに絞っていたので、自分のなかではかなり冒険した部数。
印刷の部数を決めたのが開催日の10日前くらいで、そのときの被チェック数が50。
被チェック数が50の段階で部数を250に決めたのはいくつか理由があって、一番大きいのは次の記事を読んでなんか大丈夫そうと思ったから。
- 気持ち的に印刷代だけ赤字にならなければいいかなと思ってた
- 100刷るより200くらい刷ったほうがコスパよくなる
- 250刷ると70ちょっと売れれば赤字ラインを超える
- 在庫出たら出たでそのとき考える
という感じで、赤字じゃなければもうどうなってもいいやと思った。10日前で被チェック数50あるなら70以上はまぁ売れるでしょとかなり楽観的だった。
当日の結果
開始45分の時点で赤字ラインを乗り越え、14:30に冊子244部(見本誌とか自分用で6部)が完売。1分に1冊以上なペースで息つく暇もない感じで冊子が売り切れた。
見本誌を見ずに買ってくれる方もぼちぼちいたけど、見本誌を読んで買ってくれる人のほうが多かったかなという印象。この結果をみるに、Vue.jsというテーマの引きは結構強いんだなと認識を改めた。
冊子がなくなったあとはDLカードのみに切り替え。17:00の閉会までで30枚くらい。やはり物理本は強く、「冊子ないのか〜残念」となる人が多かった。
最終的な頒布数は合計で275部。すごい。
冊子がなくなったペースをみるに、たぶん物理本は400刷ってもちょっと余るくらいで済む感じのやつだったのかなと推測。
BOOTH公式のこのアナウンスがあと数日早かったら300部にしてたかも。
10/8(月・祝) #技術書典5 会場にて、サークル様の多めに持ち込んだ作品を【BOOTH倉庫に無料発送できる窓口】を設置します🙌
— BOOTH公式@技術書典5 ス03 (@booth_pm) 2018年10月1日
倉庫への「保管申込」を済ませ、梱包した荷物に「保管ID・品番」を明記し「荷物作業スペース」へお持ちください!
会場でスマホからも申込み可!https://t.co/tS021S3KDa pic.twitter.com/pcTAnYY1l5
DL版
技術書典の翌日朝にBOOTHでDL版の販売を開始した。
#技術書典 にだしたVueコンポーネントの本、Boothで販売開始しました📚https://t.co/YUErV3b8DJ
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月9日
とりあえず出すけどそんな売れないだろう、と思ってたけどそこそこのペースで売れててびっくりしている。
BOOTH、わりと売れててビビる
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月9日
いろいろな人に届いてる感じで嬉しい。BOOTH使いやすいし、技術書が売れる土壌が育ってる気がする。
次回へのあれこれ
- 書きたいことは書ききる
- 入稿してから「削ったあれやっぱ無理やりねじこんでもよかったな〜〜〜」はもったいない
- 多少構成が崩れても書きたいことを書こう
- サークル参加の申し込みをした段階から準備する
- 当選してから書きはじめると少し苦労するぞ
- 落ちたら誰かのとこに委託するくらいの意気込みで
- 見本誌は透明なカバーつけるといいかも
- 「見本誌」マークをテープで貼ったら表紙剥がれて悲しい
- というか表紙の仕上げをツルツルのやつにしたほうがいいかも
- 名札作っていったほうがよさそう
- ただでさえアイコンと顔が一致しないので認知してもらうためにもあったほうがいい
次回サークル参加するとしたら
- Slackクライアントの作り方
- Functional Vue.js
のどちらかをテーマにしようかなと考え中。
TweetDeck風Slackクライアント作成中。最低限見れるとこまで進んだ。作りたいもの作るの楽しすぎる pic.twitter.com/kYaIQxzTEm
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年8月29日
「Functional Vue.js」というワードが頭に浮かんできたので怪文書のネタに入れておこう
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年9月20日
おわりに
とにかく楽しかった。終わったあとに妻と飲んだビールは最高においしかった。
渋谷に戻って乾杯🍻おつかれさまでした😁 pic.twitter.com/sImLWTXx96
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月8日
ブースに来てくれたみなさまありがとうございます。戦利品の写真に自分のが写ってると嬉しいですね。ブースに来てくれた人の中に「これを買うために技術書典きました」と言ってくれた人がいて、なんだよ最高のイベントかよと思いました。
購入報告とか感想とかありがとうございます
Twitterで購入報告とか感想を書いてくれてる人がちらほらいて感無量でございます。ありがとうございます😭
自分の中で「Vue.jsのエキスパートとして開発をやっている人」みたいなのを初めて観測したのがじまぐさんなので、じまぐさんが本を出してると2秒くらいで買ってしまった
— potato4d (@potato4d) 2018年10月9日
サク読みした。今はじめての中規模Vue案件で結構このバッドパターンを知らずにやってる部分が多いのでありがたい(>_<)
— ナユ / to-R Inc. (@nayucolony) October 9, 2018
後悔しないためのVueコンポーネント設計 @nakajmg 読了。僕が半年かけて泣きながら学んだことが全部書いてあるので、まだVueやってない人がこれ読んだら実質半年若返ると思う pic.twitter.com/h8lbCF7n0M
— しゃべる椎茸 (@tottokotkd) October 8, 2018
現地で買って拝読しました!実務からの指針が丁寧に書いてあってとても参考になりました。ありがとうございました!
— こにふぁー (@konifar) October 9, 2018
技術書典行けなかったので買ってみた!ちょうど本業・副業両方でVueを使うので、これを機にちゃんとしたコンポーネント設計のベストプラクティスを身につけたい。 https://t.co/P7bif7aUGn
— Ken Shimizu@移住したい系エンジニア (@kaonash_) October 9, 2018
ちょうど今VueでWebアプリ作ってて、どんな設計にするのが良いか悩んでいたところ、ピンポイントな本が...!
— 堤 健 (@tsutsu_ken) October 9, 2018
公式ドキュメントでは言及されていない、痒いところに手が届く感じで、めっちゃ勉強になりました! https://t.co/5NdM08hBvW
戦利品。
— paichi (@paichi81) October 8, 2018
「後悔しないためのVueコンポーネント設計」はほぼほぼテストの本で勉強になるわー#技術書展5 pic.twitter.com/70Pt2WQNjP
読んだ。常にテストを意識した作りになるようなTipsが散りばめられてました。作者のコンポーネントの分け方、テストケースの考えを知れて面白かったです。 #技術書典 #技術書典5
— 山口さんちのいがにん (@IganinTea) October 8, 2018
後悔しないためのVueコンポーネント設計 | PonyHead https://t.co/Xx2FfsRe5s #booth_pm
「後悔しないためのVueコンポーネント設計」
— さがっと (@sagattosaga) 2018年10月8日
めちゃいい!
筆者の実際のコンポーネントの分け方や、テスト方法が凄くわかりやすくまとめられていて参考になる!
こういう本がたくさん出るといいなぁ〜。 pic.twitter.com/HawRm4RhwO
こういう感想とか反応がもらえるとめちゃ嬉しいし、書いてよかったな〜。
自分のに限らず、本を手にした人たちは一言でもいいので感想をつぶやくと著者の人がめっちゃよろこぶと思います。
自分がゲットした本については別途感想を書きます。
技術書典の戦利品😁 pic.twitter.com/WRMFDg6u94
— じまぐ📚技術書典 こ32📚 (@nakajmg) 2018年10月8日
おつかれさまでした。