何にゃふ

何がにゃーんだふざけるな

技術書典5反省会

ちょっと遅くなったけどひっそり反省会。

f:id:mikesorae:20181014232401p:plain

こんな感じの本を作って売ってきた。

企画

いつも通り身内Slackで書きたい人を募集し、特にテーマは決めず各自好きなように書く内容を決めた。

  • Good
    • 特になし
  • Bad
    • 合同誌なのでテーマが揃ってないと宣伝も売り子もしづらかった。
    • 表紙もデザインで悩んだ。

進行管理

Google Spread Sheetでざっくり台割とスケジュール表を作成した。 スケジュールには初稿・校了・入稿やデザインのスケジュールなどを記入した。

  • Good
    • スケジュールどおりとは行かなかったものの、レビュータイミングを決めておいたので割と緊張感を持って作業を進められた。
  • Bad
    • 台割作ったはいいけど素人が宣言通りのページ数にするのは不可能だった。

執筆環境

前回までの遺産があったのでSphinxで書き始めたが、latexでいい感じにする方法がわからなかったので、途中からTechBoosterさんのサンプルがあるRe:VIEWに乗り換えた。

ビルド環境は前回までJenkinsを使っていたが、維持コストがもったいないので今回からGCPのCloudBuildにしてみた。 また、せっかくなのでビルドしたPDFをSlackに投げるようにした。

  • Good
    • すぐに最新版のPDFが見れるのでレビューするときにマーカー入れたり体裁チェックが捗った。
    • ビルド実行課金なので維持コストがぐっと下がった。
    • 基本的にsty追記するだけなのでlatexの調整が簡単になった(?)
  • Bad
    • めんどくさくてビルドバージョンをファイル名につけてなかったので、後のレビューとの紐づけ管理ができていなかった。

執筆作業/レビュー

色々慣れてきたのもあり、結構早いタイミングから執筆が開始できた。 レビュー用Spread Sheetを作成し、相互レビューでタイポや構成や日本語の指摘を行い、レビュー対応状況の管理をした。

  • Good
    • レビュー期間を長めにとったのもあり、日本語が変な箇所やタイポをかなり減らせた。
  • Bad
    • アウトラインレベルでの指摘があまりできなかったのでもう少し手前で一回レビュータイミング設けても良かった。
    • タイポや表記揺れが多かった。次からはTextLint的なものを入れたい。

デザイン

全部自分でやりたい欲があり表紙デザインもやったが今回もまとまりのないデザインになった。

  • Good
    • ClipStudioでイラスト作成、Sketchでレイアウトしてアートボードや素材の管理がいい感じにできた。
  • Bad
    • なんだかんだラフ描いてからデザイン完成まで二週間くらいかかった。
    • 色のセンスが足りないため全体的にコントラストがはっきりしないカラーリングになった。
    • SketchだとCMYKで確認しながら作れないので辛かった。

入稿

毎回手持ち搬入してたが辛かったので今回は現地搬入できる日光企画さんに依頼した。

  • Good

    • Re:VIEW使ったので簡単に奥付ができた。(Contactだけデフォルトで入ってないので指摘されて追加した)
    • 表紙を印刷所指定のトンボ付きフォーマットで入稿したのでいい感じに断ち切られてた。
    • 一回手元のプリンタで印刷チェックしてかすれてる箇所などを事前チェックした。
    • 今回から本文オフセットにした。仕上がりがかなり綺麗になった。
  • Bad

イベント当日

「あの布」を買おうと思ったけど早々に売り切れていた。 仕方なく手芸屋で買ったクロスなどを敷いてお茶を濁した。 POPデザイン・印刷をする余裕がなかったのでネット印刷でぱぱっとこんな感じの立て札を作った。

f:id:mikesorae:20181015000153j:plain

  • Good
    • 冊子は現地搬入にしたのでダンボール開けるだけで良くて楽だった。
  • Bad
    • POP小さすぎてみんな目を細めながら見てた。混雑時はすぐ近くから見てもらえるけど非混雑時も考慮すると2〜3m離れても内容がわかるようなものが望ましい。
    • かんたん後払いの要望が多かったのでやっておくべきだった。

まとめ

技術書典2、技術書典3と参加させてもらい、徐々に同人出版のノウハウが溜まってきた。 印刷物のクオリティ自体も初回に比べるとかなり高くなったと思うが、周りのクオリティも高くなってきて合同誌の限界を感じ始めたので、次回はまとまったテーマで一冊書けるように頑張る。

壁紙用Re:VIEW記法チートシート

技術書典向けにRe:VIEWを覚えようと思い立ち、自分用に壁紙用チートシートを作った

https://res.cloudinary.com/mikesorae/image/upload/v1535848698/blog/review/Re_VIEW_CheetSheet.png

めんどくさいので自分の壁紙サイズしか作ってない。

間違ってるところがあったらごめんなさい。

変更履歴

2018/09/02

  • 縮小されてたのでオリジナル画像をCloudinaryに上げました。

コーチング研修とブログの話

最近会社でコーチング研修というのを受けている。 (コーチングが何かはまだ上手く説明できないのでこの辺の記事を見てください)

coach.co.jp

要は答えはあなたの中にある的なやつで、問いかけによって自己認知を促し、課題や改善策を見つけていくみたいなやつ。

プロコーチという方々がいらっしゃるんだけど、彼らは傾聴スキルに特化していて、とにかく人の話を聞くのがうまい。 なぜそう思うのか、どこに自分の原点があるのか、本当は何をやりたいのか、どうすれば実現するのかを、一つ一つ丁寧に掘り下げてくれる。

自分の場合は当ブログをご覧いただくとわかる通り、アウトプット習慣がないという課題があったので、とりあえず宿題として記事を書くことにした。 (本当はもう少し大きい枠での悩みがあったんだけど、とりあえず手をつけられるところから始めた)

ビバ締め切りドリブン

書いた記事はこちら

やはりお前たちのRepositoryは間違っている

タイトルは「Repositoryのアンチパターン」とかでも良かったんだけど、煽りタイトルで怒られるやつも体験してみたかったというのがありこれにしてしまった。 ほんとにホッテントリに入ってしまい今はビクビクしながら見守ってる。

今後はもう少し普通に業務で使ってる技術とか新しく使いたい技術についてぽちぽち投げていきたい。

近況など

サボってたのでブログちゃんと書く(ちゃんと書くとは言ってない)

近況

  • 技術書典4落ちた。とりあえず晴天をお祈りする。
  • 異動があってJavaからPlay/Scalaの世界になった。Scala DDDをやっていく。
  • ネイティブアプリもやっていく。
  • スクラムマスターもやっていく。

とりあえず今まで悩んでたことが異動によりほぼ解決・消滅したため精神衛生が良い。

osxでsphinxのmake latexpdfjaを実行するまで

技術書典2の原稿をsphinxで書こうと思いsphinx入れたはいいけどpdfのビルドで早速つまったのでメモ

前提条件

  • osx10.11
  • python3.5

準備

sphinxインストール

pip install sphinx

プロジェクト作成

sphinx-quickstart

設定は適当に入力

MacTex2016インストール

homebrewでMacTeXいれようとしたら404 not foundになったので公式から拾ってきて入れた。

以下のWikiを見ながらインストール MacTeX - TeX Wiki

tugの方は繋がらなかったので、以下のミラーサイトより適当に選んでDL https://texwiki.texjp.org/?MacTeX#mirror

(今回はこちらを使わせてもらいました。 http://ftp.riken.go.jp/pub/CTAN/systems/mac/mactex/MacTeX.pkg)

ダウンロード終了後、pkgファイルをクリックしてインストールするとlatexが利用できるようになる。 (PATHが追加されるので、一度ターミナルを開き直す等で環境変数を読み込み直す必要あり)

pdf作成

sphinxのドキュメントルートで以下のコマンドを実行

make latexpdfja

以上でbuild/latex/下にpdfが出力できるようになった。

原稿がんばるぞい

実践実践DDD

DDD本を買って初めて読んでから5年くらい。 実務で実験的に導入を始めて3年くらい。 チームメンバーとDDD本の輪読を始めて5ヶ月くらい。 実験プロジェクトでドメイン層の実装を始めて3ヶ月くらい。 実践DDDを読み始めて2ヶ月くらい。

「何となく良さそうな気はするけど、本当に実務で使えるのかよ」みたいな気持ちを抑えながらもDDDの勉強を続けて、 最近ようやく中規模のプロジェクトで導入するチャンスを迎えた。

まだまだ設計段階だけど、既存プロジェクトと新規サービスのシステム境界の設計に「境界づけられたコンテキスト」を使ったところ 思った以上にスッキリした設計になって驚いた。

実験的に戦術的DDDの導入には成功してたので、チームメンバーにコンテキストマップを見せたところかなりの共感を得られた上、 明確なサービス境界と実装イメージまで持てたので、今までやってたことが無駄じゃなかったということが実感できてかなりテンションが上がった一日だった。

明日からシステム設計がんばるぞい。

create-react-appが生成したファイルを読む

今更ながらreact入門をしてるんだけど、webpack周りとか分からないことが多いのでちょっとずつ勉強している。

今日は簡単にreactアプリの雛形が作れるcreate-react-appが生成してくれたプロジェクトで

npm run eject

した時に生成されるファイルを読んで、何をやってるのかを調べた。

準備

npm i -g create-react-app
create-react-app react-app
cd react-app
npm run eject

上記を実行すると以下のようなファイルが生成される。

~/D/s/react-app ❯❯❯ tree -I node_modules
.
├── README.md
├── config
│   ├── env.js
│   ├── jest
│   │   ├── CSSStub.js
│   │   └── FileStub.js
│   ├── paths.js
│   ├── polyfills.js
│   ├── webpack.config.dev.js
│   └── webpack.config.prod.js
├── package.json
├── public
│   ├── favicon.ico
│   └── index.html
├── scripts
│   ├── build.js
│   ├── start.js
│   └── test.js
└── src
    ├── App.css
    ├── App.js
    ├── App.test.js
    ├── index.css
    ├── index.js
    └── logo.svg

これらを一つずつ眺めていく。

ディレクトリ構成

config

その名の通り設定ファイルが置いてある。

public

そのまま公開する静的コンテンツを配置するところ。

scripts

npm runコマンドで実行するスクリプトの実体が置いてある。

src

ビルド前のcssやjsファイルが置いてある。

logo.svgがなぜここにあるのかは今のところ不明。

package.json

依存ファイル、scriptsコマンドの設定や、babel, eslint, jestの設定が書いてある。

あんまり特筆すべきことは無さそう。

configファイル

config/env.js

環境変数設定用。

localの環境変数にREACT_APP_*, NODE_ENV, PUBLIC_URLという名前の環境変数があればハッシュマップに詰めて返す。

config/jest/

単体テストで使うファイルモックか何かの設定っぽい。 よくわからなかったので、おいおい調べる。

config/paths.js

webpackで使うモジュールやindex.js等のパスを設定している。

module.exports = {
  appBuild: resolveApp('build'),
  appPublic: resolveApp('public'),
  appHtml: resolveApp('public/index.html'),
  appIndexJs: resolveApp('src/index.js'),
  appPackageJson: resolveApp('package.json'),
  appSrc: resolveApp('src'),
  yarnLockFile: resolveApp('yarn.lock'),
  testsSetup: resolveApp('src/setupTests.js'),
  appNodeModules: resolveApp('node_modules'),
  ownNodeModules: resolveApp('node_modules'),
  nodePaths: nodePaths
};

resolveApp(path)はアプリのディレクトリからの相対パスに変換してくれる関数。 webpack.configではここで設定したパス変数を使って設定を行っている。

config/polyfills.js

実行環境にPromiseとかFetchとかObject.assignがなければpolyfillを設定してくれる。

config/webpack.config.dev.js, config/webpack.prod.js

webpackの設定が書かれたファイル。

NODE_ENVで切り替えられるのかと思ったけど、デフォルトでは

  • npm run start - > config/webpack.config.dev.js
  • npm run build -> config/webpack.config.prod.js

で決め打ちっぽい。(要検証)

scripts

scripts/start.js

npm run startで呼び出されるscript。

開発用ビルドと開発用サーバの起動を行う。

真面目に読んで一個一個書こうかと思ったけど思ったより長かったので割愛。

主にコンパイル結果のハンドリング(メッセージ出力等)、historyApiFallbackやhttpProxy等のミドルウェアの追加、webpackサーバの起動を行っている。

前述の通りstartはdevelopmentモードで決め打ちになっているので、webpack.config.dev.jsに記載された設定でビルドされる。

scripts/build.js

npm run buildで呼び出されるscript。

productionに配置するためのファイルをビルドする。

実行するとbuildディレクトリ下に本番デプロイ可能な静的ファイルが出力される。

scripts/test.js

npm run testで呼び出されるscript。

実行すると以下のようなpromptが表示される。

Watch Usage
 › Press a to run all tests.
 › Press o to only run tests related to changed files.
 › Press p to filter by a filename regex pattern.
 › Press q to quit watch mode.
 › Press Enter to trigger a test run.
  • a: 全てのテストを実行
  • o: 変更されたファイルのみテストを実行
  • p: 正規表現でフィルタされたファイル名のテストのみを実行
  • q: ウォッチモードを終了
  • Enter: 最後に実行したテストを再実行(?)

一度実行するとwatch状態になるので終了したいときはqを押す。

scriptの中ではNODE_ENV='test'でjestを実行してるだけのよう。

全部読みきれてないけど、webpackやnodeの作法が学べるので良い勉強コンテンツだなと思った。