じまろぐ

めめ

Nuxtプロジェクト内で使われてないコンポーネントを探す

  • プロジェクトが進むと役目を終えた使わないコンポーネントが出てくる
  • 放置していくとどれが使っててどれが使ってないかわからなくなってくる
  • 使わなくなったコンポーネントの代わりに作られたコンポーネントの名前が似てると最悪みがある
    • 「このコンポーネントだろう」と思って変更してみたら「残念!そっちじゃありません!」みたいなやつ
  • 使わなくなったタイミングで削除するのがベストだけどそうもいかないのが現実

という感じで、使われなくなったコンポーネントを削除したい。

使われなくなったコンポーネントを見つける

webpackのプラグインでビルド時に使われていないコンポーネントが探せる。

unused-files-webpack-pluginを使って一覧を出す

github.com

nuxt.config.jsbuild.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でビルドしてるプロジェクトなら使えます

開業届を出しました

会社はやめてません。

副業はじめてました

半年前くらいから継続してやってく副業をやりはじめて、本業と並行して続けていけそうだったので開業届を出しました。

屋号は技術書典のときに使ったサークル名から「PONYHEAD」にしました。

現状2案件を受けてるので直近では受けられないですが、タイミングとご縁があったらお仕事のご相談まっております。

やってること

本業と同じくフロントエンドをやってます。JavaScriptが書きたいのです。

いま受けているのは2つ。

ウェルプレイドではWELLPLAYED JOURNALというesportsに関するメディアのお手伝いをしてます。esportsに関わる仕事やりたいな〜と思ってたので楽しくやっております。

wellplayed.media

SCOUTERではback checkというリファレンスチェックを行う新規サービス開発のお手伝いをしてます。HRテックに興味もあり、VueでごりごりSPAが書けて楽しいです。

backcheck.jp

エンジニア募集してるらしいです。

社会性を取り戻す戦い

フルリモートな会社に勉めて6年目になるんですが、どんどん外に出る回数も少なくなりこりゃいかんなと思い始めてたので、人との接点が増えて今のところよい感じです。

本業+副業2つという感じなのでわりとパツパツで時間の管理が大変ですが、その分だけ収入が増えたので頑張りたい所存です。

収めるぞ税を。

宇田川町あたりで作業してる日があるので渋谷近辺の人はランチのお誘いお待ちしております。

Vue.jsのrender関数(JSX)に思いを馳せた結果

この記事はVue.js #2 Advent Calendar 2018の18日目の記事です。

Vue.jsを使った開発では、特別な理由がない限り.vueファイルで記述するのが主流かと思います。.vueの場合、テンプレートの定義は<template>で行うことになるでしょう。

自分も何の疑問が湧くことなく<template>を使っていましたが、ある日ふとrender関数に思いを馳せ、いくつかの個人プロジェクトで試してみました。

本記事では、その試行錯誤から得た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を使ったrendercreateElementに変換される

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ファイルに定義した定数をコンポーネント内で使う場合、computeddataに割り当ててからでないと<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,
      },
    })
  },
  // ...省略
}

$emitdispatchなどに使うイベント名を定数にして、テンプレートで同じ値を参照して使うようにできます。

<template>ではcomputedでオブジェクトを返してv-onに指定することでできなくもないが、これ以外の方法があれば教えて欲しい。)

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,
  })
}

すべてはJavaScript

<template>を使わずに書いていると、<style>も削れないかな?と思ってしまうのが人間。

そんな願いを叶えてくれるのがvue-styled-components

github.com

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)に対する印象が少しでも変わったなら幸いでございます。

Nuxt.jsが気になるならNuxt.jsビギナーズガイドを読めばいいと思う

f:id:nakajmg:20181110032919j:plain

Nuxt.jsビギナーズガイドを著者の@potato4dさんよりいただきましたので、読んでみての客観的な感想を記しておきたいと思います。

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

ちなみますと、自分の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 ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

入門者じゃない人にこそ読んで欲しい「Vue.js入門」

f:id:nakajmg:20181013191832j:plain

Vue.js入門を@kazu_ponさんより頂きました。ありがとうございます。

遅くなりましたが、読んだ感想を残しておきたいと思います。

Vue.js入門 基礎から実践アプリケーション開発まで

Vue.js入門 基礎から実践アプリケーション開発まで

感想の前に

自分は専業のフロントエンドエンジニアです。Vue.jsの使用歴は4年ほど。個人・案件を問わず多くのプロジェクトでVue.jsを採用した経験があるので、正直に言うと本書の対象からは少し外れてるかなと思います。

それでも本書からは得られるものがありました。

入門だけじゃない内容

タイトルこそ「入門」とついていますが、ページ数(460P)から想像できるように、カバーしている範囲がすさまじいです。

入門して終わりではなく、入門から修了までの道筋が記されています。よくある入門本にあるような「簡単な使い方はわかったけどこっからどうしたらいいの?」といった状態にはならないと思います。

整えられた情報たち

今までVue.jsで「これどうやるのかな?」と思ったときは、ドキュメントを見るか検索してそれっぽいものを探すかでした。

そうやって調べて知見を溜めていくのもいいですが、本書はそういったネット上に散らばっていたような情報が詰め込まれています。

情報を詰め込んでいるだけでなく、整理され、必要なタイミングで得られるようにしっかりと道筋が整えられています。

本書から始めると効率めっちゃいいと思います。

つまみ食いするように読める

入門する人は最初から、そうでない人は途中の章から読めるように章立てされています。

Vue.jsでSPAを作ったことがある人なら、8章からの「中規模・大規模向けのアプリケーション開発」から読んでもいいと思います。

入門する人も本書を最後まで一気に読み切る必要はなく、まずは1章から3章くらいまでを読めば、Vue.jsの基本的な使い方が把握できると思います。

個人的なオススメポイント

本書の個人的なオススメポイントはコラムです。

技術書には本線となるテーマが章ごとにありますが、コラムは本線に入れるとちょっとノイズになるような「知らなくても支障が出るものじゃないけど、知ってると周辺知識の理解が深まるもの」だと思います。コラムと合わせて前後の文章を読むことでさらに理解が深まります。

本書をすでに持っているけど読んでいないという人も、まずはコラムだけでも目を通してみると新しい発見があるかもしれません。

Vue.jsに興味があるすべての人にオススメできる圧倒的入門書

はじめにいったように、本書は入門から修了までをとてつもないボリュームでカバーし、解説しています。これから始める人も、すでに始めている人も、本書を読めば得られるものが確実にあると思います。

Vue.js入門 基礎から実践アプリケーション開発まで

Vue.js入門 基礎から実践アプリケーション開発まで

もしVue.jsに明るくないメンバーがプロジェクトに参加するようなときには本書を読んでもらえばいい、そんな本が出てきてくれて感謝の極みです。

技術書典5でVue.js本を出してみた振り返りとか

はじめてのサークル参加

技術書典4で一般参加して「なんか出す側のほうが楽しそうだなぁ」と思ってサークル参加してみた。

大変なこともあったけど、結果的にめちゃくちゃ楽しめた。

頒布したもの

Vueのコンポーネント設計の本。テストのしやすさという観点から、これまでVueを使ってきて感じたアンチパターン的な話と、コンポーネントの分類、テストのやり方なんかを書いた。BOOTHでDL版販売中です(宣伝)

ponyhead.booth.pm

本にするネタ

今回はVue Fes JapanのCFPに出して落ちたネタがあったので、それを本にまとめる形にした。

「売れる内容を考える」みたいなのはしなかったけど、興味を引くようにタイトルは何個か案を考えて最終的に「後悔しないためのVueコンポーネント設計」にした。

執筆環境

PDF生成のために執筆環境構築が必要になる。

はじめは自力での構築を試したが、つらくて挫折した。結局TechBoosterのリポジトリをcloneして使った。

github.com

レイアウトもそのまま使って(見た目にこだわる優先度が低い)設定ファイル、表紙、本文だけ自前のものにすればPDF生成までできて楽だった。ビルドは用意されてるdockerコマンドで。

エディタはVSCodeRe:Viewプラグインは次のやつを使用。

marketplace.visualstudio.com

本文を書く

とにかく書く。お仕事で技術文書をそこそこ書いているのもあって、執筆自体が全く苦ではないのでスムーズに完了した。

CFPを出すときに練りまくったので、構成と内容の流れみたいなのはちゃんとできたかなと思う。CFPを書くときは次のやつを何回も読んだ。

blog.builderscon.io

今回本にした内容は、自分の経験から感じていたことや考えていたことを文章に起こす形だったので、無理なく書けた気がする。

ただ構成とかページ数の関係で削った内容がぼちぼちあるので、それはまたの機会に発散したい。

表紙を作る

表紙はにイラストを書いてもらった。

f:id:nakajmg:20181009153525p:plain

かわいいでしょ。

入稿する

本文と表紙ができたらあとは入稿するだけ。

今回は技術書典のバックアップ印刷所であるねこのしっぽさんを利用した。イベント当日にブースまで本を運んでもらえるの超楽なので助かった。

プランは「ねこスパーク」という締切遅めだけどそこそこ安いやつ。

入稿はまず申し込みフォームからページ数やサイズを入力、利用するプランを選択して申し込み。

その後、本文だけのPDFファイルと、表紙と背表紙をそれぞれPSDファイルでアップロード。アップロードしたファイルで印刷してOKですよ、というの印刷会社に伝えるUIがあるので入稿完了状態にする。

入稿完了後「コードブロックがはみ出してるけどこれは意図してるやつですか?直しますか?あと表紙用のPSDのサイズがちょっと合ってないから少し拡大しますか? 」と確認の電話があった。

修正して再度アップロードして入稿完了の報告をWebで。その後もう一度電話があり問題ないとのことで無事印刷に進めた。

細かいところまで見てくれて大変助かった。また次もお願いしたいと思いました。

DLカードの準備

冊子のほかにPDFのダウンロード版も用意した。

印刷は名刺の印刷でググって出てきたとこに適当に決めた。

printsta.jp

入稿用のテンプレートがアプリケーションごとにあったので楽だった。

printsta.jp

表面に光沢のある用紙を選択したけど、出来上がりを見てマットなやつで角丸とかにしたほうがよかったかな?と思った。

DLカードの表面は表紙をそのまま使って、裏面にPDFをDLするためのURLとQRコードとZipファイルを解凍するためのパスワードを書いた。

個人名刺もついでに作った。

PDFファイルを置く場所

よくあるDropboxで〜ユニークなURLを〜みたいなのがめんどくさそうだったので、BOOTHにパス付きzipファイルを置いて0円でDLしてもらう運用にした。

ponyhead.booth.pm

下書き状態があるので、あらかじめ商品を登録してURLを決めておいて、そのURLをDLカードの裏面に印刷し、当日の朝に公開した。

技術書典の次の日からBOOTHでDL版を買えるようにしたかったので、あらかじめページを作っておいて次の日に公開処理だけすればよい状態にしておいた。BOOTH使いやすい。

事前に準備したもの

サークル向けガイドラインを読んで、ブースの設営に必要そうなものを準備した。

techbookfest.org

以下持ちこんだ物

  • お釣り(1000円札40、5000円札2)
    • 頒布物の価格は1000円のものだけ
  • 見本誌を立てるやつ*2
    • 見本誌を取ってもらいやすくするように2つ
    • 冊子売り切れたときには完売札を立てた
  • ポスター吊るすやつ
  • 机に広げる布
    • 布はあったほうが圧倒的にサークル感が出る
  • スケッチブック
    • 見本誌マークや完売札を作ったり、いろいろ使える
  • マッキーのセット
  • ハサミ
    • スケッチブックで書いたものを切り取る
  • 養生テープ

見本誌立てはなんとなく2つ用意していったけどわりと正解だったぽい。見本誌を結構読んでもらえた。

(自分の文字を書く能力はレベル1のまま止まってるので、全部妻に書いてもらった)

決済方法

今回使えるようにしたのは次の3つ。

  • 現金
  • 技術書典かんたん後払い
  • pixiv Pay

圧倒的に現金が多かった。お釣りの千円札をかなり用意したけど、1万円札or5千円札を出してきた人は合わせて6人くらいでほぼ使わなかった。参加者の人もお釣りがでないように崩してきてる感あってやさしい世界。

かんたん後払いは70部くらい。かんたん後払い用のQRコードは運営側で用意してくれていて、スタンドとして立てられるようになっていて大変よい感じだった。感謝。

pixiv Payは圧倒的に認知が少ないのか、使ってくれたのは6人だった。この利用人数だとサークル側としてはオペレーションが複雑になるだけなので、次回はなしかな〜?といったところ

被チェック数

自サークルの配置場所はこ32サークルリストを見るとわかるんだけど、リストの下から9番目の位置。500近いサークルがある中でめっちゃ後ろの方にあるので、サークルリストからサークルカットでのチェックに頼ると伸びが悪いだろうなと思った。

ということでこのリストからのチェックはあまり重視せずに、Twitterからの流入で被チェック数が伸びるといいなと思って何回かつぶやいた。

つぶやくときは#技術書典ハッシュタグをつけて、出すものの内容とサークルページへのリンクをセットで。

被チェック数の推移

被チェック数は開催3日前くらいまではゆるやかに伸びて、そこから一気に増えた。

  • 9/12: 15
  • 9/27: 50
  • 10/2: 77
  • 10/4: 103
  • 10/7: 181
  • 10/8: 270

最終的な被チェック数は270。

f:id:nakajmg:20181009143359p:plain

これは読めない。読めないが、この伸び方は理解できる。

前回自分が買う側で参加したとき、サークルチェックしたのは前日の夜&当日の朝だった。早めにチェックしてるのは多分サークル参加する人たちで、一般参加の場合は直前にチェックするのが合理的な行動っぽい。

印刷の部数

今回は250部刷った。初サークル参加だし、Vue.jsというテーマに絞っていたので、自分のなかではかなり冒険した部数。

印刷の部数を決めたのが開催日の10日前くらいで、そのときの被チェック数が50。

被チェック数が50の段階で部数を250に決めたのはいくつか理由があって、一番大きいのは次の記事を読んでなんか大丈夫そうと思ったから。

note.mu

  • 気持ち的に印刷代だけ赤字にならなければいいかなと思ってた
  • 100刷るより200くらい刷ったほうがコスパよくなる
  • 250刷ると70ちょっと売れれば赤字ラインを超える
  • 在庫出たら出たでそのとき考える

という感じで、赤字じゃなければもうどうなってもいいやと思った。10日前で被チェック数50あるなら70以上はまぁ売れるでしょとかなり楽観的だった。

当日の結果

開始45分の時点で赤字ラインを乗り越え、14:30に冊子244部(見本誌とか自分用で6部)が完売。1分に1冊以上なペースで息つく暇もない感じで冊子が売り切れた。

見本誌を見ずに買ってくれる方もぼちぼちいたけど、見本誌を読んで買ってくれる人のほうが多かったかなという印象。この結果をみるに、Vue.jsというテーマの引きは結構強いんだなと認識を改めた。

冊子がなくなったあとはDLカードのみに切り替え。17:00の閉会までで30枚くらい。やはり物理本は強く、「冊子ないのか〜残念」となる人が多かった。

f:id:nakajmg:20181009162723j:plain

最終的な頒布数は合計で275部。すごい。

冊子がなくなったペースをみるに、たぶん物理本は400刷ってもちょっと余るくらいで済む感じのやつだったのかなと推測。

BOOTH公式のこのアナウンスがあと数日早かったら300部にしてたかも。

DL版

技術書典の翌日朝にBOOTHでDL版の販売を開始した。

とりあえず出すけどそんな売れないだろう、と思ってたけどそこそこのペースで売れててびっくりしている。

いろいろな人に届いてる感じで嬉しい。BOOTH使いやすいし、技術書が売れる土壌が育ってる気がする。

次回へのあれこれ

  • 書きたいことは書ききる
    • 入稿してから「削ったあれやっぱ無理やりねじこんでもよかったな〜〜〜」はもったいない
    • 多少構成が崩れても書きたいことを書こう
  • サークル参加の申し込みをした段階から準備する
    • 当選してから書きはじめると少し苦労するぞ
    • 落ちたら誰かのとこに委託するくらいの意気込みで
  • 見本誌は透明なカバーつけるといいかも
    • 「見本誌」マークをテープで貼ったら表紙剥がれて悲しい
    • というか表紙の仕上げをツルツルのやつにしたほうがいいかも
  • 名札作っていったほうがよさそう
    • ただでさえアイコンと顔が一致しないので認知してもらうためにもあったほうがいい

次回サークル参加するとしたら

  • Slackクライアントの作り方
  • Functional Vue.js

のどちらかをテーマにしようかなと考え中。

おわりに

とにかく楽しかった。終わったあとに妻と飲んだビールは最高においしかった。

ブースに来てくれたみなさまありがとうございます。戦利品の写真に自分のが写ってると嬉しいですね。ブースに来てくれた人の中に「これを買うために技術書典きました」と言ってくれた人がいて、なんだよ最高のイベントかよと思いました。

購入報告とか感想とかありがとうございます

Twitterで購入報告とか感想を書いてくれてる人がちらほらいて感無量でございます。ありがとうございます😭

こういう感想とか反応がもらえるとめちゃ嬉しいし、書いてよかったな〜。

自分のに限らず、本を手にした人たちは一言でもいいので感想をつぶやくと著者の人がめっちゃよろこぶと思います。

自分がゲットした本については別途感想を書きます。

おつかれさまでした。

ねこちゃんと泊まれる旅館で癒やしと学びを得てきた

f:id:nakajmg:20180924235917j:plain

湯河原にあるまいきゃっとという旅館でねこちゃんと一晩を過ごしてきた

www.mycat-yugawara.com

この旅館では併設されている猫カフェのねこちゃんを部屋に招いて一緒に泊まれる。控えめにいっても最高の体験&経験だった

ねこちゃんのトライアル

ねこちゃんと一緒に泊まれるというのは、ねこちゃんをレンタルするというわけではなく、あくまでもお試しで共同生活を体験してみるというやつ。ねこちゃんの糞の世話なんかもやる必要がある

今我が家では真剣にねこちゃんを飼うことを検討しているので、ねこちゃんとの生活がどういうものかを少しながら体験できて大変よかった

宿泊当日の流れ

  • 15時までにチェックイン
  • 併設されている猫カフェでトライアルするねこちゃんを決める
  • 18時~翌朝9時までねこちゃんと一緒に暮らす

旅館はすべて素泊まりで食事などの提供はなし。ねこちゃんのトライアル開始時間以降は部屋にねこちゃんしかいない状況にはできないので、18時までに外で済ますか、外で買ってきて部屋に持ち込むかのどちらか。

自分の場合、14時半に旅館に到着、猫カフェでねこちゃんを決めて、16時~17時30くらいまで熱海駅前を観光してた。熱海までは電車で10分。

トライアルの記録

今回2匹のねこちゃん、あらしくんとよしのちゃんをトライアルした。2匹は姉弟

最初は警戒してかごの中からあまりでてこない

f:id:nakajmg:20180924235758j:plain

わりとすぐ慣れてきて遊んでくれる

f:id:nakajmg:20180925000233j:plain

f:id:nakajmg:20180924235805j:plain

f:id:nakajmg:20180924235912j:plain

ちゅーるすごい

f:id:nakajmg:20180924235915j:plain

かわいい

f:id:nakajmg:20180924235923j:plain

朝背中に乗られる

f:id:nakajmg:20180925000747p:plain

ねこちゃんのいる暮らし

めちゃくちゃ幸せな時間だった。今回トライアルしてみて、ねこちゃんがいる暮らしがどんな感じなのかの具体的なイメージが掴めた。ねこちゃんにも性格がいろいろあるとか、糞はリアルなニオイがするとか、寝てると乗ってくるとか顔舐めてくるとか。

夫婦ともによい感触が得られたので、次の引っ越しの際には、ねこちゃんを迎え入れるのにかなり前向きになれそう。