kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

過去のcommitを修正したい時は、 `git commit --fixup` と `git rebase --autofixup` を使おう!

先に結論

  • 過去のcommitを修正したい時は、 git commit --fixup=#{commit番号} してから、git rebase --autofixup
  • --autofixup オプションは、 git commit --fixup した commit を自動的に fixup してくれる
  • git rebasefixup は、対象の commit を上の commit と結合させる命令

例えばこんな状態

* 8a66664 (HEAD -> refs/heads/branch) Add 02.txt
* c85bd12 Add aaa on 01.txt
* 7b24435 Add 01.txt
* a8bc429 (refs/heads/master) first commit
  • branch ブランチで、01.txt を作って、中身に 'aaa' を入れて、その後 02.txt を作った

ここで、01.txt に入れる内容は 'bbb' であったことに気づく!

さあどうする

ここで、 git commit --fixup の登場!

  • 引数に、修正対象のcommit番号を入れる
g ci --fixup=c85bd12
[branch 63cb5d4] fixup! Add aaa on 01.txt
 1 file changed, 1 insertion(+), 1 deletion(-)

すると、自動的にコミットメッセージが生成されて commit される

* 63cb5d4 (HEAD -> refs/heads/branch) fixup! Add aaa on 01.txt
* 8a66664 Add 02.txt
* c85bd12 Add aaa on 01.txt
* 7b24435 Add 01.txt
* a8bc429 (refs/heads/master) first commit

git rebase --autofixup

git rebase --autofixup すると、--fixup した commit をこんな風にいい感じにしてくれる

git rebase master -i --autofixup
pick 7b24435 Add 01.txt                
pick c85bd12 Add aaa on 01.txt         
fixup 63cb5d4 fixup! Add aaa on 01.txt 
pick 8a66664 Add 02.txt                

最終的なcommitログ

* 0423c38 (HEAD -> refs/heads/branch) Add 02.txt
* 362238a Add aaa on 01.txt
* 7b24435 Add 01.txt
* a8bc429 (refs/heads/master) first commit

c85bd1263cb5d4 が統合された!!

便利

2-3個 commit を重ねた後に、間違い気付いた場合にさっと修正できるのが気持ち良い!

追記

今回のような修正の場合は git commit --squash と、 git rebase --autosquash の方がよいかも

  • squash なので、圧縮後にコミットメッセージを修正できる

追記2

autofixup と、autosquash オプションを on にしておくと楽。

  • rebase 時に勝手に、 --autosquash --autofixup をつけてくれる

.gitconfig

[rebase]
    autofixup = true
    autosquash = true

参考

追記

first commit を rebase したい場合

git rebase -i --root 

git rebase/merge をそろそろキチンと理解する

なんなのかと

rebase

品質を落とす、品のない振る舞いをする

git rebase

つかいみち : ブランチにmasterの変更を取り込む

例えば、こんな感じに、 master と、branch_b がある場合...

* ac7957d Add 'd' in a.txt
| * 9aa15f9 (refs/heads/branch_b) Add 'c' in b.txt
| * b129f6c Add b.txt
|/
* 3d940b6 Add 'b' in a.txt
* 26ba7e0 Add a.txt
git checkout branch_b
git rebase master

git rebase master を実行すると、masterHEAD の上に、 branch_b が乗っかる感じになる

  • ブランチ分岐後に追加された変更 ac7957d の上に、 branch_b の変更が乗っかる
* a27055b (HEAD -> refs/heads/branch_b) Add 'c' in b.txt
* 7d45f1d Add b.txt
* ac7957d (refs/heads/master) Add 'd' in a.txt
* 3d940b6 Add 'b' in a.txt
* 26ba7e0 Add a.txt

上のような状態を fast-forward な関係にある という

git rebase --interactive

つかいみち : コミットの履歴を編集する

* afe1290 (HEAD -> refs/heads/make_01_txt) Add 'aaa' on 01.txt
* cccfaee Add 01.txt
* 183848b (refs/heads/master) first commit
git rebase -i 183848b

commit番号より上のcommitについて、 git rebase --interactive を行う

pick cccfaee Add 01.txt
pick afe1290 Add 'aaa' on 01.txt

# Rebase 183848b..afe1290 onto 183848b (2 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
  • pick commitを採用
  • reword 名前変更
  • squash 上のcommitと合体
  • fixup 上のcommitと合体(commitメッセージは捨てる)

こうする

reword cccfaee Add 01.txt
fixup afe1290 Add 'aaa' on 01.txt
  • この場合、 9f6ec01 は、上のcommitと合体
  • その上で、79f2ab0 のコミットメッセージを変更

すると、commitメッセージの変更画面が出るので変更する

* 4625879 (HEAD -> refs/heads/make_01_txt) Create 01.txt
* 183848b (refs/heads/master) first commit

すっきりした!

ちなみに

  • git rebase --interactive の時に、commitの順序の入れ替えもできるので便利です

git rebase のログを見る

git reflog
4625879 HEAD@{0}: rebase -i (finish): returning to refs/heads/make_01_txt
4625879 HEAD@{1}: rebase -i (fixup): Create 01.txt
4cdf15a HEAD@{2}: rebase -i (reword): Create 01.txt
cccfaee HEAD@{3}: cherry-pick: fast-forward
183848b HEAD@{4}: rebase -i (start): checkout 183848b
afe1290 HEAD@{5}: commit: Add 'aaa' on 01.txt
cccfaee HEAD@{6}: commit: Add 01.txt
183848b HEAD@{7}: checkout: moving from master to make_01_txt
183848b HEAD@{8}: commit (initial): first commit

git rebase を元に戻したい!!

HEAD@{0}〜HEAD@{4} までが、git rebase でやったこと

git reset --hard HEAD@{5}

直前の git rebase を戻したいのであれば

git reset --hard ORIG_HEAD

mergeやreset、rebase を行った直前の HEAD (べんり!!!!!!)

git merge

ブランチ make_01_txtmaster にマージする

* afe1290 (HEAD -> refs/heads/make_01_txt) Add 'aaa' on 01.txt
* cccfaee Add 01.txt
* 183848b (refs/heads/master) first commit

git merge --ff

fast-forward な関係ならば、マージコミット無しでマージする

git merge make_01_txt --ff
* afe1290 (HEAD -> refs/heads/master, refs/heads/make_01_txt) Add 'aaa' on 01.txt
* cccfaee Add 01.txt
* 183848b first commit

fast-forward な関係じゃない場合は?

* e838a79 (HEAD -> refs/heads/master) Add 02.txt
| * afe1290 (refs/heads/make_01_txt) Add 'aaa' on 01.txt
| * cccfaee Add 01.txt
|/
* 183848b first commit

マージコミットが作られる

*   33cd880 (HEAD -> refs/heads/master) Merge branch 'make_01_txt'
|\
| * afe1290 (refs/heads/make_01_txt) Add 'aaa' on 01.txt
| * cccfaee Add 01.txt
* | e838a79 Add 02.txt
|/
* 183848b first commit

git merge --no-ff

fast-forward な関係でも、マージコミットを作る

git merge make_01_txt --no-ff
*   4084ea5 (HEAD -> refs/heads/master) Merge branch 'make_01_txt'
|\
| * afe1290 (refs/heads/make_01_txt) Add 'aaa' on 01.txt
| * cccfaee Add 01.txt
|/
* 183848b first commit

それぞれどういう時に使うの?

この辺はプロジェクト毎のルール次第のような

  • ブランチをマージする時には、コミットを1個にsquashしてからマージするとか
  • 必ず、マージコミットを作る為に --no-ff をつけるとか

git cherry-pick

特定のcommitをカレントブランチの先頭に乗っける

こんな場合

* ac7957d (HEAD -> refs/heads/master) Add 'd' in a.txt
| * 9aa15f9 (refs/heads/branch_b) Add 'c' in b.txt
| * b129f6c Add b.txt
|/
* 3d940b6 Add 'b' in a.txt
* 26ba7e0 Add a.txt

branch_b9aa15f9 を、masterHEAD にのせる

git checkout master
git cherry-pick b129f6c
* f16c177 (HEAD -> refs/heads/master) Add b.txt
* ac7957d Add 'd' in a.txt
| * 9aa15f9 (refs/heads/branch_b) Add 'c' in b.txt
| * b129f6c Add b.txt
|/
* 3d940b6 Add 'b' in a.txt
* 26ba7e0 Add a.txt

参考

次回予告

git pull --rebase を理解する

(おまけ)

本記事の git log は以下のオプションで出力してます

git log --graph --oneline --branches --decorate=full

エイリアスにしておくと便利かも

DNSを良くわかっていない自分が浸透問題を理解するまでのはなし

そもそもDNSってなんだっけ?

DNSサーバは2種類

  • コンテンツサーバ (権威DNSサーバ)
  • キャッシュサーバ
    • コンテンツサーバの内容をキャッシュするサーバ

DNSは分散構成

ドメイン取得の流れ

DNSサーバが自身が知らないドメインを調べる場合

  • ルートサーバに問い合わせを行う
  • ルートサーバは、特定のゾーンとDNSサーバの組み合わせを持っているので、「そのゾーンならば、このDNSサーバに問い合わせろ」という回答をする
  • そのまま、本当にIPを持っているDNSサーバまでたらいまわしが行われる
[ルートサーバ] -> [コンテンツサーバ] -> .... -> [コンテンツサーバ]

ついでにリゾルバの話

  • アプリケーションからドメイン問い合わせがあると、DNSに問い合わせを行って回答してくれるサービス
  • linux 系だと /etc/resolv.confDNSサーバのIPを書く
    • 社内DNSサーバだったり、プロバイダのDNSだったり、 8.8.8.8 だったり

参考

DNSのレコード

DNSに格納されている情報を レコード という よく使うレコードはこんな感じ

  • Aレコード : ホスト名と、IPv4アドレスのマッピング
  • AAAAレコード : ホスト名と、IPv6アドレスのマッピング
  • CNAMEレコード : 別名を定義
    • 1つのIPアドレス複数のホスト名を持たせたい時(バーチャルホストとか)
    • あと、www.test.com と、test.com どちらでもアクセス可能にしたい時とか?
  • NSレコード : あるゾーンについてのDNSサーバの問い合わせ先
    • 自分のゾーンの場合、自分のホストが書かれている
    • たらいまわし
  • MXレコード : あるドメイン宛てのメールをどのホスト名に渡すかのマッピング
  • PTRレコード IPv4アドレスと、ホスト名のマッピング
    • Aレコードの逆。逆引きDNSで使用
  • SOAレコード : 自分が管理しているゾーンに関しての情報

ついでに、DNSを設定する時によく聞くTTLって何?

TimeToLive

  • コンテンツサーバが設定する、キャッシュサーバがそのデータを保持して良い時間
  • 単位は秒
  • DNSのデフォルトのTTL値は86400秒(24H) らしい

DNSが浸透するってどういうこと?

DNSサーバを引っ越して、Aレコードも変更した時に、引越し先のIPアドレスにアクセスされるようになるまで時間がかかる様子

何でそんなことが起こるの?

こんな流れで、親DNSサーバの中で DNSサーバのNSレコードが延々とキャッシュされつづける ため

前提

  • ドメイン : www.example.jp
  • DNSサーバ : ns-old.example.jp
  • 前提知識 : 自分が権威を持っているゾーンのNSレコードには、自分自身を書く

引越前、旧DNSサーバのゾーン情報を親DNSサーバはキャッシュしている

DNSサーバのキャッシュ

www.example.jp. 10 IN A 192.0.2.1
example.jp. 100 IN NS ns-old.example.jp.

10秒後、Aレコードのキャッシュが切れて、NSレコードのキャッシュが残っている状態になる

DNSサーバのキャッシュ

example.jp. 90 IN NS ns-old.example.jp.

この時に、www.example.jp について問い合わせが発生

  • DNSは、NSレコードのキャッシュを元に DNS に問い合わせを行う
  • DNSは、古いIPを返す
  • その内容でAレコードがキャッシュされる
  • その後、 NSレコードのTTLがリセットされる!!!!!!

DNSサーバのキャッシュ

www.example.jp. 10 IN A 192.0.2.1
example.jp. 100 IN NS ns-old.example.jp.

元に戻ったよ!

これが延々と繰り返されると、親DNSサーバはいつまでも旧DNSの情報をキャッシュしつづけてしまうよね...

なんでTTLをリセットとかするの?

  • DNSプロトコルに違反している訳ではない
  • おそらくは無駄な問い合わせをなるべくしないようにするため?

正しい方法

DNSサーバを立てた後に、親のNSレコードを切り替える前に、 DNSサーバの自ゾーンのNSレコードを新DNSサーバに切り替えておく

  • DNSサーバはどちらにせよ、新DNSサーバに問い合わせに行くことになるため、上記の問題は発生しない

あと、 bind9.2.3では、TTLをリセットしないように実装が変更された

まとめ

浸透なんてないんだよ! 単なる設定のミスで古い情報がキャッシュされつづけるだけだよ!!

次回予告

  • digコマンドの使い方について説明する

参考

Rails高速化のためのパフォーマンスチューニングに役立つツール 8個+α

これは何?

レスポンスタイムが遅くて辛いけど原因が特定できないときに役立つツールをまとめてみました

  • Rails以外でも使えるものも一緒くたに書いているけど、気にしない!

やらないこと

それぞれのツール詳細な説明

  • 気が向いたら個別記事を書く

環境

New Relic

パフォーマンス監視サービス

  • 運用フェイズ
  • アクション実行時にどの処理にどれだけ時間が掛かったかをメトリクス収集してくれる

参考


以降のツールは基本的には開発、テスト時に使用するやつです


rack-mini-profiler

パフォーマンス計測ツール(gem)

  • アクション実行時に、ブラウザにレンダリングに掛かった処理の時間を表示してくれる

参考

bullet

N+1問題検出ツール(gem)

  • アクション実行時に、N+1問題があるとポップアップやログで警告してくれる

出力例

2009-08-25 20:40:17[INFO] N+1 Query: PATH_INFO: /posts;    model: Post => associations: [comments]·
Add to your finder: :include => [:comments]
2009-08-25 20:40:17[INFO] N+1 Query: method call stack:·
/Users/richard/Downloads/test/app/views/posts/index.html.erb:11:in `_run_erb_app47views47posts47index46html46erb'
/Users/richard/Downloads/test/app/views/posts/index.html.erb:8:in `each'
/Users/richard/Downloads/test/app/views/posts/index.html.erb:8:in `_run_erb_app47views47posts47index46html46erb'
/Users/richard/Downloads/test/app/controllers/posts_controller.rb:7:in `index'

参考

activerecord-cause

クエリの実行箇所をログに出力してくれるツール(gem)

bulletで分からないような、ビューのループの中で直接モデル読んでるみたいなヤバイ箇所を速やかに見つけるためのものです。

出力例

D, [2015-04-15T22:13:46.928908 #66812] DEBUG -- :   User Load (0.1ms)  SELECT "users".* FROM "users"
D, [2015-04-15T22:13:46.929038 #66812] DEBUG -- :   User Load (ActiveRecord::Cause)  caused by /Users/joker/srcs/activerecord-cause/spec/activerecord/cause_spec.rb:16:in `block (3 levels) in <top (required)>'

参考

stackprof & stackprof-webnav

a sampling call-stack profiler for ruby 2.1+ (gem)

  • メソッドの実行時間をメトリクス収集
  • stackprof-webnavで、収集結果をリストアップして見やすくしてくれる
  • 処理が早いので、運用フェイズで使用しても殆どボトルネックにならないらしい

出力例

参考

rack-lineprof

行単位のベンチマークツール(gem)

  • 行単位に処理に掛かった時間を表示してれる
  • 重い処理はハイライトしてくれる。便利!
  • stackprof は、処理時間の収集。rack-lineprof は特定の処理について見たい時に、みたいな使い分け?
    • stackprofで十分かもしれない

出力例

参考

rails_best_practices

静的解析ツール(gem)

  • Rails Best Practicesに沿わないコードを指摘してくれるツール
  • CIと組み合わせるべき
  • Always add DB index とかが発見されるとパフォーマンスに直結するはず

参考

module Benchmark

ベンチマークモジュール(Ruby標準)

  • 怪しいと思った部分を Benchmark.benchmark で囲むと、ベンチマークが取れる
  • 修正前/後でどれだけ処理が軽くなったか確認する時などに

参考

その他

rails-perftest

  • Rails4で本家から分離されたgem
  • パフォーマンス計測ツールらしいけど、記事が殆ど無い...?

SQL auto explain (Rails4で削除済)

Rails同梱の、処理が遅いSQLを自動的に通知してくれるツールだったけど、Rails4で削除された

ActiveRecord::Relation#explain は残っているらしいので、個別に怪しい処理をirbからexplainするのがよいかもしれない

考えていること

  • rack-mini-profilerbullet はアクションを実行した時に遅い部分を見つけるツール
  • テスト実行時に、一緒にパフォーマンス計測をして、遅い処理を見つける方法ってないものだろうか?
  • フィーチャーテスト実行時に、一緒にパフォーマンス計測とか???
  • ボトルネックを見つけたら、その部分についてはパフォーマンステストも実行する。とかが現実的なのだろうか?

TODO

参考

ツール紹介

パフォーマンスチューニングの実践

2015振り返り

本当は2015年にやりたかった...

Keep

ニンジャ学会!

  • 自分主体で何かをするということに抵抗が無くなった
  • 素晴らしい内容の本ができて、色々な方に喜んで頂けた
  • リーダーシップについての知見を得た
    • 独断で引っ張って良い。むしろそうすべき
    • 会社で小さいチームのリーダーをしていて、引っ張り方がわからなかったのが解決した
    • 自分が楽しい! と思うことと実業務の課題がリンク
  • 自分の自己評価の回復
    • これだけ素晴らしい内容の本を作れる自分も素晴らしいのでは...? と思えた
    • 自分1人だけで本を作ったら、多分これはなかった。合同誌ならでは!
  • ついでに知見をblogに書いたらtwitterがバズった
  • 学生時代からやりたかった、「自分主体で同人誌を作る」というタスクが終わった...
    • やっとこさ、学生時代から背負ってきたものを下ろせた気がする

会社に価値を提供できるようになってきた

いまさらかよ

  • ごめんなさい
  • とはいえ、ただタスクをこなすだけではなく、「会社に提供できる価値」と言うものを意識できるようになってきたと思う
  • こっちについても、自分主体で何かするということに抵抗が無くなった
  • 「業務改善の為にこれを導入したい」「この作業面倒くさいから自動化したよ!」など

blog再開

  • 10月以降あんまり書いてないけど、なんだかんだで 37 記事
    • 基礎的な内容なので、バズったものはない
  • こんなのを書いて、勉強すべきことの方向性を考えていた
    • 習得したいことメモ - kasei_sanのブログ
    • 丁度レガシーなプロジェクトから外に出て、色々新しい技術を学ばなければならない時だった
    • 随分色々やりたがってる
      • 案の定半分くらいしかできてない
    • 定期的に必要なスキルの見直し、棚卸しはしたほうが良いと思った

Problem

前半の迷走っぷり

  • 2015前半は電子工作にハマって、PICをかじっていた
  • まぁ趣味だから良いのだけど、それが仕事とリンクしたり、他との広がりがそこまで伸びるものでもないということを、自覚しながらやってしまった気がする
  • サイバーサングラスの成功を引っ張りすぎた感
  • 後、本当に習得すべきスキルからの現実逃避というか...
  • 5月のニンジャ万博でそれを一区切り出来たのは良かったと思う

自分の市場価値についての不安を払拭出来ていない

  • ついにプログラマー限界年齢に!
  • 不安に思って色々勉強をしていたが、それで不安がとれたか? というと、そんなことは無かった
  • 2016年は、この辺もうすこし掘り下げたい

防衛機制

  • 高ストレスや、プレッシャーがある時に、防衛機制を働かせてそのことに気づかずに面倒なことになったりした
    • 0か1か思考
    • 思考に柔軟性が無くなる
  • それに気づけたのはKeep
  • 防衛機制 - Wikipedia
    • 合理化(rationalization)
    • 知性化(intellectualization)

Try

  • 習得したいことのメモ 2016版を書く
  • 市場価値を上げる方法についての知見をまとめて実践する
  • 認知行動療法の本を読む

これだけやれば大丈夫!! 合同誌を作るための主催者チェックリストを作った

これはなに?

2015年の冬コミにて、ニンジャスレイヤーの合同誌「ニンジャ学会」を作りました

各メンバーの活躍により素晴らしい内容の本になり、無事完売もしたのですが、

自分自身、合同誌の取りまとめをするのは初めてで、色々と手間取ることが多かったので、今後の為にチェックリストを作ってみました

合同誌を作る予定の人も参考にできるように作ったつもりですので、よかったらご参考にどうぞ

前提条件

  • 本の内容と、参加予定のイベントは決まっている
  • 主にコミケ向けです

最初にこころがけ

  • 主催者の独断で決めるべし
    • メンバーと相談する場合も、最初に主催者案を話してそれに合意を取るという形にする
    • 意見から求めると中々決まらず大変(特にweb上だけで相談する場合)
  • ただし お金のことについては、全員の合意をきちんと取ること
    • トラブルの元になるので、ここはしっかりと
  • 手の内は明すべし
    • ただ「こうする」と伝えるのではなく、「こう考えているので、こうする」など、自分が何を考えて何を目指しているのかを明確にする
  • 複数のことを同時に相談しないこと
    • 大体前の話題が有耶無耶になります
  • ここに書いてあることを一人で全部やろうとしないこと
    • 燃え尽きます
    • その道のプロがメンバーにいたらお願いする
    • いなくても、手分けしてやってもらおう!
  • 気負い過ぎないこと
    • 後手後手でもまぁなんとかなります
    • メンバーもサポートしてくれるよ!
  • 楽しんで!!

メンバー募集前に決めること

  • □ : 参加メンバーに掛かる費用/報酬
    • お金のことは一番最初に告知/同意を取ること
    • こういう費用がかかるよという説明ができるように
      • サークル参加費と印刷費を折半するとか
    • 具体的な金額については今後詰めるということを説明すればよい
  • □ : 参加メンバーにお願いすること
    • 大抵は本文と、自己紹介テキストくらいなはず
  • □ : 本文以外に募集したいメンバー(必要ならば
    • 表紙/イラストなど
  • □ : 参加メンバーの上限(あれば

参考 : 費用/報酬の例

ニンジャ学会の場合

  • 売上-費用の差額をメンバーで割った額をイベント終了後に精算
  • 印刷された本2冊
  • イベント終了で一旦〆て、委託については後日相談

リスク/リターンを分散した

他のサークルで見た例

  • 費用、売上は主催者持ち。参加メンバーには本を1冊

主催者にリスク/リターンが集中するタイプ

メンバー募集前に決めておくとよいこと

メンバー募集中に決めても良い

  • □ : メンバー募集のしめきり
  • □ : 頒布後のメンバー作成分の原稿の扱い
    • 他の同人誌に寄稿してよいか? webで公開して良いか?
    • ニンジャ学会の場合、イベント終了あと半年したら自由にしてよいとしたはず(うろ覚え

メンバー募集の告知の時にやること

  • □ : 立ち上げ告知の為のtwitterアカウントやwebサイトの用意
    • メンバー募集後は、頒布情報の告知先になる
  • □ : メンバーの募集方法を決める
    • blogのコメント、メール、DMなど
  • □ : 告知してメンバーを募集
    • 鉄は熱いうちに何度も打つのが良いです
    • なんかのイベントで話が出たならば、1週間以内に告知したほうが広がり方も参加人数もだいぶ違うはず
    • みんなもイベントの時の勢いで参加してくれる

メンバーが集まったあとにやること

  • □ : メンバー間の連絡方法を決める
    • メンバー全員が使い慣れているツールの方が良い
    • PC、スマホ両方でつかえるツールが良い
    • ニンジャ学会の場合、twitterのグループDM
      • 手軽
      • 複数の話題を並行にすると混乱するという弱点が...
  • □ : メンバー間の連絡方法をメンバーに告知
  • □ : 制作物をやり取りする方法を決める
    • ニンジャ学会の場合、COREDRIVE
      • 無料
      • 全員がtwitter使いだったので、twitterアカウントでログインできたのが決め手
  • □ : 制作物をやり取りする方法をメンバーに告知
  • □ : おおよその作業しめきりを決める
    • 印刷所確定前にざっくりで良いので決めておく
    • ノンブルを振ったり目次を作ったりする必要があるので、ギリギリにはしないこと!
  • □ : 作業しめきりをメンバーに告知
    • おおよそであり、印刷所確定後に詳細が決まる旨も通知する
  • □ : 提出フォーマットを決める
    • 各メンバーが作成できるフォーマットにすること
    • プレーンテキスト? pages? PhotoShop?
    • 必ず最後に編集者が手を入れる必要が出てくるので、編集可能なフォーマットにすること!
  • □ : そのフォーマットを使えないメンバーの為の代替え案も考えておく
    • メンバーからその旨連絡があってからでも良い
  • □ : 提出フォーマットをメンバーに告知
  • □ : 落選の場合どうするかをメンバーに告知
    • 「落選したら考える」でも良い

メンバーが作業しているあいだにやること

  • □ : 出納帳の用意
    • この辺からそろそろお金のことが出てくるので用意しておく
    • googleスプレッドシートがオススメ
      • 共有できる
      • 複数のPCからチェックできる
  • □ : 印刷所の検討
    • 経験者が居る場合、その人が使ったことがある会社の方がトラブルは少ないはず
    • クレジットカードが使える方が、販売後に現金を支払うことになるので便利
    • ニンジャ学会の場合、栄光印刷でした
      • 最初に話題に上がったから
      • クレジットカードが使える
      • 早割がある
  • □ : 印刷種別の検討
    • 決めることが多いので、他メンバーのこだわりがない限りは主催者の独断でさっさと決めること!
    • 本のサイズ(B5? A5?)
    • 綴じ方向(右綴じ? 左綴じ?)
    • 表紙つや有り? マット加工? 箔押しなどの特殊加工はする?
    • 表紙、本文の紙の種別など...
  • □ : 奥付の作成
    • タイトル、発行日(イベントの日)、発行者、連絡先、印刷会社
  • □ : サークルカットの作成
  • □ : イベント参加登録
  • □ : イベント参加登録した旨を外部に告知
    • これ以外にも、何か進捗がある毎に要所要所で告知をすると熱量が下がらないので良い
    • メンバーの士気も向上する
    • 主催者も楽しい!!

印刷関係の色々

  • □ : 印刷所を独断で仮決定する
    • 印刷部数、締め切りの見積もりの為に必要
  • □ : 頒布価格を独断で仮決定する
  • □ : ページ数を独断で仮決定する
    • メンバー1人あたり4ページで... みたいな感じで
    • 同人誌の場合、表紙+裏表紙で+4ページなので注意すること
  • □ : 印刷部数を決める
    • メンバー数 x 渡す冊数も考慮
      • ニンジャ学会の場合、9人 x 2冊で、18冊だったので意外に大きかった
    • 委託もだしたいならその分も考慮
    • 経験者がいればそれに従うのが吉
    • 仮決定した印刷所の場合、それでいくら位になるのかメンバーに告知
    • また、仮決定した頒布価格の場合の損益分岐点もメンバーに告知
    • 全員の合意を取ること
  • □ : 頒布価格、印刷費、印刷所を決める
    • 全員の合意を取ること
  • □ : 最終締め切りを決める
    • ある程度はバッファを考えておくこと
  • □ : 最終締め切りをメンバーに告知

ぽつぽつ原稿が上がってきたころにやること

  • □ : 表紙を作る
  • □ : 掲載順序を決める
    • こだわりがなければ50音順で
  • □ : 上がった原稿を各メンバーで見て確認
    • 誤字脱字はないか?
    • 内容、フォーマットに不備はないか?
    • 印刷上はみ出てしまうところはないか?
  • □ : 上がった原稿の一部を外部に告知
    • 他の人の原稿を使う場合、告知に使ってよいか確認すること
    • 定期的にちょこちょこ上げることで、熱が保たれる
  • □ : まえがき、あとがきが必要なら作る

締め切りが近づいてきたらやること

  • □ : まだ上がっていないメンバーのフォロー
    • 個別にメッセージを送ること
    • いつまでにできそうか、予定だけでも教えてもらうこと
    • 何か障害があればこちらで手伝えるか確認すること
  • □ : 真の締め切りの告知
    • ここまでにいただけないと編集作業が間に合わないという日時を告知
    • とはいえ一方的にならずに、柔軟に対応すること
    • 一緒に作業をしているという気持ちで

原稿が揃ったらやること

  • □ : 印刷価格をメンバーに告知
    • ここで最終的なページ数が確定するので
  • □ : 目次の作成
  • □ : ノンブルづけ
    • 本文は3ページ目から!
  • □ : 自己紹介の編集
  • □ : 原稿ファイルを作成する
    • 印刷所毎に求められているフォーマットにすること
    • ニンジャ学会の場合、本文はPDF、表紙はTIFF
  • □ : 原稿ファイルの確認
    • 全メンバーに目を通してもらうこと
    • 乱調落丁はないか?
    • 誤字脱字はないか?
    • 目次間違いはないか?
    • ノンブルは正しいか?
  • □ : 作成環境の確認
    • 原稿ファイル作成に使用したアプリのバージョンを印刷所に報告する必要がある
  • □ : 印刷所に発注
    • 部数、綴じ方向、発送場所/日時に間違いがいないことを、発注情報のスクリーンショットを取ってメンバーと確認するとよい

イベント前にやること

  • □ : 売り子として参加できるメンバーを募集
    • 朝一で設営に参加(サークルチケットの数で上限がある
    • 途中から参加
  • □ : 売り子の予定、都合を確認
    • 何時頃には買い物に出たい
    • 最初に買い物した後に合流したいなど、ざっくり把握しておく
  • □ : 後から来た売り子との入れ替えについてざっくり決めておく
    • サークルはそんなに広くないので4人が限界
    • 3人以上来たら、誰かが抜けるなど
  • □ : 設営に参加メンバーとの集合場所、時間を決めておく
    • ニンジャ学会の場合、国際展示場駅左側の待ち合わせエリア
    • サークルチケットを渡している場合、サークル集合でも良いかも
  • □ : 打ち上げの有無の告知
    • よっぽどの大人数でない限りは予約はしなくて良いと思う
    • 後からメンバーが合流したり、混雑具合で終わる時間も変わったり
  • □ : 値札を作る
  • □ : 100円ショップで値札を立てる奴を買ってくる
  • □ : ポスターなどアピールするものを作る
    • とりあえず表紙をA4で印刷するだけでもよい
    • どんな内容なのか簡単に説明したA4くらいの紙も
  • □ : テーブルに引く布を買う
    • コミケの場合、45x90cmなので、前後に垂らす為に、2m位あれば十分
  • □ : 手元を隠せるようなものを用意する
    • お釣りや、販売部数をチェックする紙を隠せるもの
    • 今回無くてちょっと困った
    • 100円ショップの棚に布をかぶせると良いかも
  • □ : お釣りを作っておく
    • 600円で頒布する場合、100円玉を20枚くらい
    • 500円で頒布する場合、500円玉を10枚くらい
  • □ : お釣りを入れるものを用意する
    • ニンジャ学会の場合100円ショップのタッパー
  • □ : 売上を入れるものを用意する
    • 1000円冊などお釣りにはならないお金を別にいれるもの
    • ニンジャ学会の場合100円ショップのファスナー付き袋にチェーンを付けて、テーブルに繋いでおいた
  • □ : 簡単に実際のサークルの設営のイメージを掴んでおく
    • 設営の手伝いに来てくれた人に指示できるようにしておく
    • 家の机で実際に作ってみて写真を撮ると良いかも
  • □ : 取り置き依頼の方のためのチェックリスト
    • お名前、部数、引き渡し済
  • □ : メンバーに本を渡すためのチェックリスト
    • お名前、引き渡し済、打ち上げ参加有無
  • □ : サークルや同人イベント初参加の人に注意事項を説明できるようにしておく
    • 特にお金の渡し方とか
    • ニンジャ学会の場合は以下の様なしおりを用意した ニンジャ学会サークル参加のしおり_-_Google_ドキュメント_-_Vimperator.png
  • □ : 見本誌票の準備
  • □ : (コミケの場合)サークル証に情報を書いて判子を押しておく
  • □ : 自分達のサークルの位置をチェックした地図
    • これを持って行かなくて少し困った...
  • □ : 赤字/黒字の場合の渡し/支払い方法を決めておく
    • 振り込み、郵便小為替など
  • □ : 書店委託を出すならばコンタクトを取って、見本となるデータを渡しておく
    • 後日、何部送ってくれと連絡がきます

その他イベントに持っていくもの

色んなサークルさんがblog等で教えてくれているのでそちらも参考に

  • □ : はさみ、カッター
  • □ : 布ガムテ、両面テープ
  • □ : ペン、マジック
  • □ : 付箋紙、ノートなど書くもの
  • □ : クリップボード(売上票やメモを挟む
  • □ : ティッシュ、ウエットティッシュ
  • □ : お菓子、ティッシュ、ペン等をいれられる箱的ななにか
    • すぐ取り出せるようにするととても便利
  • □ : 行動食、飲み物
    • あると便利
  • □ : ゴミ袋
  • □ : 100円ショップで売ってる頑丈な紙袋
    • 本を取り分ける時や、郵送時に包むのに便利

当日、設営時にやること

  • □ : メンバーと合流
  • □ : 入場
  • □ : 印刷物に問題がないか確認
  • □ : チラシをまとめる
    • 大体自立する大きめの紙袋があるので、そのままゴミ袋にすると便利
  • □ : スタッフさんが来たら、見本紙とサークル証を渡す
  • □ : 設営作業
    • 設営完了したら写真を取って告知すると良い
  • □ : 委託分、取り置き分、メンバーの分の本、+5冊くらいを先に分けておく
    • 後からやったら、少々辻褄が合わなくなって慌てました
    • なんかあったときの為に予備をとっておくと良いです
      • 完売後に世話になった人が来たとか、取り置き漏れとか
  • □ : 意識合わせ
    • 購入数チェックの入れ方
    • 取り置きチェックの入れ方
    • 売上、お釣りを入れる場所
    • 後から来た売り子さんへの引き継ぎ方法
  • □ : 隣のサークルさんにご挨拶
    • 本を交換した場合、何冊交換に出したかメモしておく

当日、イベント中にやること

  • □ : 楽しもう!!
  • □ : 後から来たメンバーへの引き継ぎ
  • □ : 自分も遠慮なく買い出しや食事に行きましょう!
  • □ : ずっと売り子をやっているメンバーに声をかけて、買い出しや食事に行けるように
  • □ : 各メンバーに本を渡す

当日、イベント後にやること

  • □ : 完売したら拍手!
  • □ : 余ったらメンバーに分配する量を増やしたり、委託の量を増やしたりして在庫を調整する
  • □ : 販売数の確認
  • □ : サークルの片付け
    • ポスターなどの紙ものは処分したほうが荷物が減って良い
  • □ : 在庫や、委託分、当日来れなかったメンバー分の本を一旦自宅に郵送
    • サークルの物品もまとめて郵送すると便利
  • □ : お金は一旦預かって持ち帰る
    • 疲れた脳で計算しても大体よいことにはなりません
  • □ : 打ち上げ

イベント以降にやること

  • □ : お金の計上
  • □ : 経費-売上の確認
  • □ : 各メンバーに渡す/払ってもらう金額を告知
  • □ : 書店委託を出す場合、書店に本を送付
  • □ : イベントに来れなかったメンバーの本を送付

以上です、これだけやればまぁなんとかなります。 楽しんで!!

Amazon Route 53 ってなんぞ? 特徴と料金をメモ

特徴

料金

  • 25ホストまで、0.5USD/月
  • 25個以上、0.1USD/月

クエリ毎の料金

通常のクエリ

  • 10億クエリまで 0.4USD/100万クエリ/月
  • 10億クエリ以上 0.2USD/100万クエリ/月

レイテンシベースクエリ

アクセス元から最もレイテンシが低いリージョンを自動的に選んでそこに誘導してくれる

  • 10億クエリまで 0.6USD/100万クエリ/月
  • 10億クエリ以上 0.3USD/100万クエリ/月

  • レイテンシ : デバイスに対してデータ転送などを要求してから、その結果が返送されるまでの遅延時間のこと

  • 複数リージョンにおんなじアプリを展開していることが前提
  • なんかすげえ!!

Geo DNS クエリ

設定したルールにもとづいて、ユーザを設定したリージョンに誘導する

  • 10億クエリまで 0.7USD/100万クエリ/月
  • 10億クエリ以上 0.35USD/100万クエリ/月

レイテンシベースと違って、自分で誘導の為のルールを設定する

参考