重力に縋るな

千種夜羽です

技術同人誌を作ったり頒布したりしている話

技術同人誌というものを作っているので,ちょっとその話をしておこうと思います. 要はOtakuAssemblyの話です.今更ですけどね.

あ,この話はOtakuAssemblyをやることになった経緯とか執筆環境の話なので, そういう話が気になる人は読んで下さい.

そういうのいいから技術の話しろよというそこのアナタ!

COVID-19騒動で家で暇してるそこのアナタ!

アナタにピッタリの技術同人誌がなんと通販で買えちゃうんです!(ダイマ) otakuassembly.booth.pm

電子版も完備!汚染されていない生のPDFが手に入ります!

あなたとOtakuAssembly,
今すぐダウンロー
*1

※Vol.2の物理本は現在入荷待ちなのでしばらくお待ち下さい(3/17現在)

OtakuAssemblyとは

2019年の5月頃にできた技術同人誌サークルです. たしか第15回自作OSもくもく会にいた大学1年生のオタク3人(@sksat_tty,@PG_MANA_,@Cra2yPierr0t)が完全にその場のノリと勢いでやるぞと言って気が付いたらやることになっていた,みたいな経緯だったと思います.たぶん.

まあ実はそれより前に@PG_MANA_に「一緒に技術同人誌書かないか...?」と誘われていたんですが, その時は僕も書いてみたいと思ってるけれどネタも微妙だしノウハウもないし金もかかるし何も考えずに特攻するのは無理があるだろみたいな話をどっかのフードコートと改札前で延々と終電ギリギリまで話した覚えがあります. 結局,実際はあんまり何も考えずに特攻したのでなんとも言えないんですけどね. とはいえあれでやろう!となっても長続きしなかったんじゃないかなあとも思います.

じゃあなんで自作OSもくもく会で急にやろう!となったかというと, 久しぶりに会ったからこの話の続きみたいなことをしてたんですよねたぶん. ただ,この時は近くにいた@Mopp_jpさんが「"書いてみたい"って言ってる奴は書かないんですよ〜」と煽ってくれたんですよね. @Mopp_jpさんは技術書典5,6,7で個人出展している強い人で,これにはめちゃくちゃ説得力がありました. そして,いつもTwitterで「これやりたい」「やりてー」とか言ってロクに成したことが無い僕にはとても刺さりました. 今書いてても刺さりますね.やっていきたい.

ということで「とりあえずやってみよう!」という気持ちになり,@PG_MANA_とたまたまその場にいた@Cra2yPierr0tを捕まえて引き入れて「やるぞ!」ということになりました. 完全にノリと勢いです.

ここらへんの話は@PG_MANA_氏もブログに書いてますね. pg-mana.net

ノリと勢いってやつは凄くて,翌日にこんな募集ツイートをしてしまうんですよね.

このツイートが界隈内でまあまあ伸びたんですよね. 金銭面や合同誌のボリューム的に,1~3人増えたらうれしいな. あわよくば経験者が来てくれるとうれしいな,と思ってこんなツイートをしたんですが, 何がオタクに刺さったのか数時間でオタクが10人くらい集まりました.は?

実際は消失したり原稿を落としたりするオタクがいたんですが(これは予想通り*2 ), それでも8人残りました.は?

そんなこんなでなんとか技術書典7に初参加し,『OtakuAssembly Vol.1』を無事頒布することができました. その後も技術書典8に参加し,イベント自体は中止になってしまったものの『OtakuAssembly Vol.2』を作ることができました(BOOTHで売ってるので皆さん買って下さい.頼ムッ).

OtakuAssemblyを支える技術

さて,技術同人誌を作るとなると,執筆環境が重要になってきます(要出典).

OtakuAssemblyでは大体以下のようになっています.

Re:VIEWについて

Re:VIEWを使っているのは主に次のような理由からです. あと僕の趣味*3

  • 原稿・設定ファイルがテキストファイル → Gitで管理できる
  • Docker Imageがある → CIが回せる
  • 技術同人誌を作ることを考えて作られている
  • 学習コストが低い
  • (あんまりやりたくないけど)いざとなればLaTeXを弄ってどうとでもできる

特に最初の2つは大人数のオタクの原稿を管理するにあたってはマストだと思っています. 別に1人で作るならどうとでもできますし,そういう場合はどんなツールを使ってもいいと思います. WordでもAdobe系のツールでもいいでしょう. 執筆時点で体裁とかをあまり気にしないとかなら,Google Documentとかでもいいのかもしれません. 某satさんとかはそんなかんじでやってると聞いたことがあるような気がします.

しかし,OtakuAssemblyは執筆者2ケタの大規模サークル(?)です*4. そして執筆者が全員プログラマーでオタクなので, Wordじゃないと呼吸困難になって死ぬということも無いですし, Gitは使えると思っていいですし,Markdownなどにも慣れているでしょう. このような前提のもとでは,原稿をGitで管理することができるかというのはとても大きな利点となります.

まず,適当なリモートリポジトリを用意して,各自執筆したらcommitしてpushする,ということをするだけで,各位の進捗状況が簡単に確認できます. また,みんなcommitしとる,原稿書いとらんのお前だけができます.僕のことですが... あと,これは個人的にかなり重要だと思っているんですが,「家では書いたんすけど〜w」とか「PCが壊れちゃって〜w」が防止できます. まあ中高の部活の部誌と違ってOtakuAssemblyは原稿を書きたくて集まっている人たちなのでそんなことは無いと思いますけどね!(無いよね?) 「push忘れてた」はやめてください.自信無くていいからpushはしてくれ.

あとdiffを確認できるのがめちゃめちゃ良いです. 自分で書いていて確認できるのもそうですが,執筆用のブランチを切って編集用のブランチに適宜MRを出す,ということをやっていたので,校正・校閲がやりやすくて良いです. まあGitというよりはGitLabの良さかもですけどね.

さらに,そもそもRe:VIEWが技術同人誌を書くために作られたものであるというのも大きいです. 何も考えずにやっても標準でトンボ出してくれたりしますしね. ビルドして出てきたPDFも大体そのまま印刷所に投げつけられます入稿できます. 設定もyamlファイルでできるので,オラッA4にするぞみたいなcommitして,あとで「やっぱA4はアカンわ.revertしたろ.」みたいなことも簡単にできます. というか実際やった.

Docker Imageがあるのもとても良いです. LaTeXの環境構築してないPCでも作業できる,というのもありますが一番大きいのはCIで回せることです. 詳しくは後述しますがCIでPDFをビルドするのはいいぞ.

さて,これらの理由を見ると「LaTeXじゃあかんの?」と思う人もいるかもしれません. もちろん,Re:VIEWでもPDFを作るなら結局LaTeXを吐くわけですし,デザインや文字の配置に拘りたいならLaTeXと真剣に向き合った方が良いですし,それなら直接LaTeXを書いた方がいいかもしれません. ですが,OtakuAssemblyでは執筆者全員が生のLaTeXを書くようになることは無いと思っています.

何故かというと,意味分からんエラーメッセージを見たくないからです. あと意味分からんエラーメッセージを見たくないです(大事なことなので2回言った). 何を言いたいかというと,他の人が書いた原稿をpullしてきてビルドしたら意味分からんエラーメッセージがターミナルを埋め尽くした......みたいな事象を許容できるか?ということです. 僕は許容できません*5. また,執筆者に執筆に集中してほしいということがあります. 原稿を書け. 文章を思いついたらVimで自分の原稿のファイルを開いて書くだけ,という環境を用意しておくのはとても大事だと思っています. 原稿を書け.

このことから,Re:VIEWの記法がとてもシンプルなのも重要だと思っています. まあまあMarkdownっぽいので,普段Markdownを書いている人なら,Re:VIEW フォーマットガイドを読めば難なく書くことができるでしょう. どうしても慣れなかったらある程度はMarkdownで書いてもらって(ただし派生記法をできるだけ使わず),md2reviewで変換する,といったこともできるでしょう. 実際何度かMarkdownで書かれた文書をRe:VIEWに変換してPDFにする,というようなことをやっていますが,変な記法を使ってなければそこまで大きな問題は起きないです. 正直#を=に変えるだけでも大体どうにかなると言っても過言ではありまs...流石に過言か.

記法のシンプルさだけで考えれば,原稿をMarkdownで書いてどうにかこうにかして*6PDFを作るのもアリだと思っています. ただ,Markdownは多くのオタクが普段から書き慣れているという利点はあるものの, その「書き慣れている」記法は得てして任意 flavored Markdownなので,「は?俺の知ってるMarkdownと違うんだが...」が発生するのではないかと思っています. もちろん凝ったことをしなければ何の問題も無いだろうとも思いますが. hikaliumさんがやっていたMarkdownで書いてSATySFiでビルド,とかは今後検討してみたいです.

GitLabを使った運用

リモートリポジトリにはGitLabを使っています. GitHubではなくGitLabなのは,organizationでもprivateリポジトリを作ることができる上, GitLab CIで簡単にCIを導入できるからです. 今ならGitHub Actionsがあるので,GitHubを使う選択肢もあると思います.

GitLabに"OtakuAssembly"というorganizationを作って,そこにprivate repositoryを生やしているだけです. 新規参入者には持っていなければGitLabのアカウントを作ってもらい,organizationにinviteした上で,執筆ネタが決まったら対象となるリポジトリでDeveloper権限を付与する,というようなことをしています.

また,主に編集作業の効率化のために,Git flow的なワークフローを採用しています.

具体的には,masterブランチは常に「リリース(=入稿)」できるもの,developブランチでは編集作業や設定の調整を行う,draftブランチでは各自が執筆する,というやり方をとっています. draftブランチは各自のIDに合わせてdraft/sksatみたいなかんじにしています. あと印刷所から怒られが発生するとhotfixブランチが生えます.わあい(白目).

なんでGitHub flowじゃないの?と思う人もいるかもしれませんが,「リリース作業」が行われることが数えるほどしか無いし,rebaseを行う必要性が微塵もないのでこれでええやろと思ってます. まあVol.1の時に僕がこれくらいしか知らなかったというのもありますが. とはいえこれでかなり上手く行っていますし多分Vol.3が出ることがあってもこれで行くんじゃないかと思います. あとmasterにマージした時のdiffのウオー俺達こんなに書いてたんだ感がいい.

なので,基本的には執筆者は自分のdraftブランチで執筆を行うだけです. そして,執筆に一区切りついたり*7,執筆が完了したりしたらdevelopブランチに対してMerge Requestを飛ばしてもらいます. MRの内容確認やマージは編集担当(基本的には僕)が行います. developブランチでは原稿を統合した時に不具合が起こっていないかチェックしたり,「今こんなかんじか〜」ってなったりします.

GitLab CIによるPDFのビルド

文書作成におけるCI,めっちゃくちゃ重要だと思っています*8. もうCIの無い文書作成はあんまり考えたくないぐらいです. いやもちろんある程度の規模の文書ならってことですけどね. でも,「今のうちに卒論で困らないように執筆環境とCI整備しておこうかなあ」と思うくらいには重要視してます. 常にビルドが通るように気をつける,ビルドが落ちるようになったらすぐに知ることができる,というのも重要ですが, それにより常に標準的な環境でビルドされたPDFを手に入れることができる,ということが大きいと思っています.

Re:VIEWで書こうが最終的にPDFを作るのはLaTeXの仕事なので,出力されるPDFは割とビルド環境にインストールされているLaTeX環境に左右されます. 特にフォントとかね.あとまあバージョンも人によって結構違うことがあると思います. そのような差異を考えなくてよくなるのは結構大きなメリットです. さらに,今外出してて環境構築したPC持ってないんだよ,みたいな時にもスマホからGitLabにログインすれば校正・校閲が可能!!!!!*9 あと,「今tag付けたやつのビルド結果を入稿して!」ができます.これも大きい. 「このcommitのビルド結果を手が空いてる人でチェックして!!」とかもね.

GitLab CIではDocker Imageを簡単に突っ込めるのもとても良いです. Docker Imageには超有名なvvakame/reviewを用いています.

github.com

Re:VIEWのバージョン指定が簡単にできて良いんですよね. ちなみにOtakuAssemblyではVol.1ではversion 3.0,Vol.2ではversion 4.0のRe:VIEWを使っています. 新しいもの好きなので.

ただ,Vol.2の割と後半の方で「siunitxが欲しいんだが......」というオタクがいたので,急遽超虚無Docker Imageを作って差し替えました. まあマジでtexlive-scienceをインストールしてるだけですけどね. github.com

Docker Hubとか使ったこと無くて焦りましたね. でもこれ作ってDocker Image差し替えたら上手く行ったのでやっぱりDockerとGitLab CIは偉大ですね.

あと,Vol.1の時はGitLabのPDFビューアがなんかバグッててページの順番がぶっ壊れたかんじの表示になっていて, Web上でPDF見て校閲したい時かなり厳しい気持ちになっていたんですが,Vol.2の時にはこの問題は修正されていたみたいです. ありがとうGitLab!!!一生付いていきます!!!!!(普段はソースコードGitHubに上げながら).

Slackへの通知

OtakuAssemblyでは,連絡には主にSlackを用いています. というかSlackしか使ってません. なんなら執筆者のほとんどとはTwitterとこのSlackでしか繋がりがありません. 最近流行りのSNS採用・リモートワークってやつですね(?)*10

なので,各位のcommit状況の確認やCIの状況の確認のため,GitLabからSlackにwebhookで通知を飛ばすようにしています. f:id:sksat:20200318021011p:plain

こういうスクショ出すとたまに「スッコココすき」って言われてふふってなります. 名付け親なので(?). スッコココくん,CIをfailさせると顔真っ赤にして怒ってくるんですよ.かわいいですね. f:id:sksat:20200318022229p:plain

あと,Vol.2の執筆中の一時期Issueとかの通知を#vol2(Vol2全般のチャンネル)に飛ばすようにしてみたんですが, Issue上でメモとかするとそれも全部通知が行くのでちょっとウザかったのでやめてしまいましたね. open/closeだけ選別して送れたら良さそうなんですけど.

編集作業について

査読があると......うれしい!!!!うれしくないですか?僕はうれしいです. ということでOtakuAssemblyでも一応それっぽい活動をしています. 最近知ったんですが,僕は編集長だったらしいです.

前述したように,校正・校閲はMRが出たら編集担当が行います. 誤字脱字の指摘や表現の修正の提案はdiffを見てMR上のコメントとして行います. まあ編集担当も執筆者の一人であるというバグがある上に僕の執筆速度が大体一番遅いので終盤になってくると頼む〜〜〜〜手が空いたオタク誤字脱字チェックやってくれ〜〜〜〜となるんですけどね(オイ).

なんで進捗ヤバい時期って重なるんですかね.不思議ですね.

あと,Vol.1の時は誤字脱字もコメントで飛ばしてたんですけど, Vol.2では明らかな誤字脱字はわざわざコメント飛ばさず編集担当がdraftブランチにcommitしちゃっていいかと思うようになりました. しょうもないtypoの指摘に文意の確認とかが埋もれても嫌ですからね. そうじゃないんやってことだったらrevertすればいいですし. まあ適宜pullしてもらう必要がありますが.

ちなみにVol.1ではめっちゃギリギリまで原稿の調整や修正をしたり*11,手の空いた人間全員で読み直しや誤字脱字チェックしたりしてVol.1は〆切45分前入稿という偉業(偉くない)を達成しました.

そしてVol.2は〆切15分前を達成しました!(は?)

あと直前の誤字脱字チェックの時マジで@hsjoihs氏が有能of the humanでした. ありがとうございました. Vol.2では@hsjoihs氏の章が無いのに「監修」になっているのはそういうわけです.

また,Vol.2では新規参加の@coord_e氏がバチクソ誤字脱字や違和感のある文章の指摘・修正活動を行ってくれてとてもありがたかったです. やっぱり文章のクオリティを上げたいと思ってくれる人間がいるととても良いですね.

その一方で,技術同人誌における文章のクオリティってどうやって担保・向上させたらいいんだろうなあという気持ちに最近なっています. エディタースクールとか,そこらへんが出してる本とかもあるみたいなので,そういう分野も個人的に学んでみたいですね.

一応,最低限の注意事項はREADMEに書いていたんですが,執筆者のオタクのうちどれくらいがこれを気に留めて書いてくれていたんですかね.

あと,中高の部活での部誌とか,OtakuAssembly Vol.1, Vol2でそこそこ他人が書いた文章をチェックしたことから思うのは,「人々,他人に読ませることを意識して文章書かないがちでは?」ということです. これはもちろん自戒も込めての思いですけどね.

良い文章が書けない.なんとかしたいですよね.貴重な時間と精神力をたくさん使うのは惜しいですが,2人とも仲良しです.きっと成功しますよ.

技術書典7

こんなこと言ってたけど売れるかめちゃくちゃ不安でした.

当日の売り子は@PG_MANA_と僕で申請して,疲れたら適宜他のオタクと交代するか〜,と思っていました. ずっと売り子するのは疲れる,というのもありますが,そもそもこちらが自分でも技術同人誌を作りたいと思う程度には技術同人誌というものが好きなので,他のサークルの本も買いに行きたいんですよね. 交代ができるのは人数が多いサークルの利点ですね.

さて,そんなこんなで準備をして会場に向かったんですが,現地納品にしていたので物理本がどんな出来なのかは誰にも分かりませんでした. 会場に入り,OtakuAssemblyが配置された机を発見し,そこにある段ボール箱を開けると...

マジで「本じゃん」って思いましたね.本じゃん.

その後アワアワしながら初めての設営をしました. 設営後はこんなかんじになりました.

どのように設営を行うかはかなり悩みました. 何しろほぼ全員同人誌即売会での出展経験皆無でしたからね. まあ大体僕が勝手にやったんですが. 設営に関しては主にコミケとか例大祭とかのオタクのブログを参考にしました. たまに技術書典のオタクも書いていたりしますが,割とちょろっとしか書いてないことが多い気がします.

あとは,これまで技術書典4,5,6に「買う側」として参加していたのですが, その中でやや不満に思っていたことなどを踏まえて,できるだけ「買う側」の人が困らないように, 且つ,近くを通った時に目に留まるように,ということを意識していました.

「おしながき」とかんたん後払いのQRコードを上に吊る,というのもその1つです. 売る側は大体座ってるか中腰かが多いと思うんですが,買いに来る人たちは全員立って歩いてるんですよね. しかも技術書典はめちゃくちゃ込む(午前中は特に)ので,行く前から目を付けているサークルでもなければ,結構素通りしてしまいます. 僕は個人的にはできるだけ全部のサークルを見ようと思って周るようにしているんですが,それでもパッと見て内容が分かる情報が無いと後回しにしてしまうんですよね.

あと,「かんたん後払い」は人々がウカツに予定外の本を買う悪魔の最高のサービスなので, これを使わない理由はありません. ここで使うQRコードは事前に運営からデータを貰える他,小さめの紙に印刷されたものとそれを立てるためのなんか食玩とかにありそうな組み立て式の厚紙でできた台が当日配られます. もちろん配ってくれるのは親切だなあと思うんですが,正直あれは小さいし台も微妙だと思っていました. ちょっと改善したような気はしますが前をよく覚えていないので比較ができない.

実際やってみたところ,そこそこの人が吊った方のQRコードを使ってくれていたように思います. ただ,「アレッかんたん後払いのQRコードどれですか?」と何度か聞かれたので, QRコードもう少し小さくして「かんたん後払いはこちら」の文字をもう少しデカくした方が良かったかなという反省もありました.

これらの準備は以下のようなIssueを立ててやったりしました. f:id:sksat:20200317222732p:plain

ただ,当日朝バタバタしながらスマホからGitLabのIssueをポチポチするのは厳しさがあったので, 持ち物リストは紙とかにしておいた方が良さそうです.

そして一般参加者の入場が始まり,大量の人間が入ってきて「あ〜これで同人誌即売会あるあるの近くのサークルだけ売れてくやつが見られるのかな」とか, 100部は刷りすぎたかなあ......とか思っていました. でもポツポツ売れていくんですよね.めっちゃ嬉しい.嬉しいな.あれ......なんかめっちゃ売れるんだが......?

気が付いたら100部あった『OtakuAssembly Vol.1』は18部になっていました. 元々10部くらい売れたら頒布状況ツイートをしようと思っていたんですが,そんなことをする暇は全くありませんでした.やべえな. 本は何箱かの段ボール箱に入っていて,それぞれの本は5冊ごとくらいに紙テープでまとまって入っていました. なので,常に大体10部くらいが机の上に載っている状態を維持していたのですが,あまりにも売れ行きが良いので, 隣にいた@PG_MANA_に「オイ早く次の束くれ」「次の箱開けといて」「一々出してたら間に合わないから次机に載せるやつ椅子に置いておいて」とか言ってました. ツイートなんかできるわけねえ.

そしてゼエゼエしながらツイートした5分後には9冊に......

んでもってその6分後には物理本完売です.どうなってるんだ. あまりにも早く売れていったので,事前にオタクから頼まれていた取り置きを完全に忘却したり*12,予備分として付いてきた4冊も売ったり,後で執筆者の分ねえじゃん!となったりしました.

その後は電子版のダウンロードカードを配ったり,なんか急に生えてきた『The Zen Book』を展示したりしてました.

金が生えると→→→うれしい!!!!!!!

国会図書館への納本

技術書典7では物理本があまりに早く売り切れてしまったため,その後割とすぐ『OtakuAssembly Vol.1』を増刷しました*13. 増刷分はBoothで売りました. この増刷によってようやく執筆者が自分が書いた本を手に入れることができました(ウケる).

ということで余剰在庫が発生したので,前々からやりたいと思っていた(そして売る時完全に忘れていた)国会図書館への納本をすることにしました.

なんと自分で作った同人誌を国会図書館に納本するとなんと国民の税金を使って半永久的に黒歴史を保存してくれるんですよね.すごい.

というか,そもそも義務なんですよ.

納本制度」とは、図書等の出版物をその国の責任ある公的機関に納入することを発行者等に義務づける制度のことです。わが国では、国立国会図書館法(昭和23年法律第5号)により、国内で発行されたすべての出版物を、国立国会図書館に納入することが義務づけられています。

納本された出版物は、現在と未来の読者のために、国民共有の文化的資産として永く保存され、日本国民の知的活動の記録として後世に継承されます。

www.ndl.go.jp

みんなも出版した黒歴史を現在と未来の読者のために,国民共有の文化的資産として永く保存し,日本国民の知的活動の記録として後世に継承しよう!!!!!!!!!!

納本はとても簡単にすることができました. それまで国会図書館を使ったことがなかったのでその場でIDを発行してもらい, 荷物をロッカーに突っ込んでビニール袋に『OtakuAssembly Vol.1』を入れて*14中に入りました. 中はいいかんじの県立図書館をめちゃくちゃパワーアップした,みたいなかんじでした. あと入館とか検索用端末使うのとかに貰ったIDカード使うのオタク心が擽られてとても良いですね.

ああ納本の話するの忘れてましたね. 館内を見回しても特に納本の案内などは見当たらなかったので,先人のブログ記事に従い,受付で「すみません,技術同人誌の納本をしたいのですがどのようにしたらよいでしょうか?」と聞いてみました. そしたらちょっとびっくりした顔してから「少々お待ち下さい」って言われて,受付の代わりをする人が来てその人に「こちらです」って言われて付いていったら明らかに立ち入り禁止エリアっぽいところに行くんですよね. めっちゃいい. かなり日本国民としてのユーザーエクスペリエンスが良いので日本国民の皆さんにはぜひ同人誌を出版して国会図書館に納本して頂きたいですね. あ,あと立ち入り禁止エリアから出る時は一人だったので「勝手に立ち入り禁止区域に入ってこっそり出てきた一般人」ごっこができます. 誰かに咎められたらどうしようとか思った.

納本自体はとても簡単で本を渡して書類1枚書くだけです.

その後,こんなものが届きました.

それからしばらくするとNDLに『OtakuAssembly Vol.1』が掲載されました. やったぜ.

id.ndl.go.jp

新刊の『OtakuAssembly Vol.2』も近いうちに納本しに行きます. 国民共有の文化的資産ですからね(?).

あと,国会図書館とは関係ないですがOtakuAssembly Vol.1,Vol.2共にISDN: 国際標準同人誌番号というものを登録しています. これはまあISBNのパロディなのですが,結構ちゃんと運営されていて登録もスムーズにできますし,オプションを選択するとそれっぽいバーコードも出力してくれます. Vol.1の時はへ〜こんなものがあるのかと思って刷った後に登録してみたんですが,バーコードが出ると知ってVol.2では絶対にこのバーコードを入れて「「「本」」」にしてやろうと思っていたんですよね. まあ結局入稿数時間前まで忘れてたんですけど. でも印刷所からの怒られ後に表紙の再入稿ができたのでちゃんと裏表紙にこのバーコードを突っ込むことができました. 気になった君はOtakuAssembly Vol.2の物理本を手に入れて裏表紙を見てみよう!本だぞ!!!*15

isdn.jp isdn.jp

技術書典8

はい.中止になってしまいました.残念ですね. まあ仕方ない.仕方なくはあるんですがもう刷ってしまったのでオタクの財布が大変です!!!買ってくれ!!!!!

通販

今買うって言った?なんと通販で買えます.皆さんもウカツに買ってください.

techbookfest.org

otakuassembly.booth.pm

※Vol.2の物理本は現在入荷待ちなのでしばらくお待ち下さい(3/17現在)

おまけ:限界commit log selection

*1:これをやりたかっただけです

*2:オタクは信用できないので

*3:実はAC入試の自己推薦書はRe:VIEWで書きました

*4:こういう書き方するとヤバいな...

*5:もちろん,LaTeXを生で使う場合でも,適切にブランチを切りCIを回しておけば流石にこんなことは起きないと思います.たぶんね.でもマージした途端に大崩壊,みたいな可能性は否定できないと思うんですよね.特に各々が好き勝手にパッケージ導入とかやっちゃうと.まあこれも適切な運用をすれば大丈夫でしょうが,オタクは信用なりませんし,オタクは信用なりませんし,オタクは信用なりませんし,何より「気をつけて運用する」ということは精神的にまあまあ大きなコストです.

*6:pandocとかで

*7:これが難しいんですけどね...

*8:AC入試の自己推薦書でももちろんCI回してましたよ!!!!!面接はfailしましたけどね!!!!(溢れ出る学歴?コンプ)

*9:社畜か?

*10:でも,そういう考え方するとGitLabのム〜ブが参考になったりするのかな?とか思ったりしますね.知らんけど.

*11:直前に300pに抑えないといけなくなったりしたのは辛かった......

*12:このオタクには見本誌を渡してgot kotonakiしました

*13:儲かったので

*14:国会図書館内には基本的に物の持ち込みはできません.どうしても持ち込みたい物はその場に用意されているビニール袋に入れて持ち込む必要があります.

*15:まあ僕もまだ現物は見てないんですけど......