執筆・編集のためのGit（GitHub）ワークフローを考えてみた
まとまった量の文章を執筆・編集するのにバージョン管理システムを使うことは、少なくとも技術文書においては特別なことではなくなりました。 原稿が汎用のテキストファイルの場合には、バージョン管理システムとして、GitやMercurialなどのソフトウェア開発用のツールを使いたいことが多いと思います。 実際、GitHubやGitBucketを利用して技術書やドキュメントの原稿を共同執筆するという話はとてもよく聞きます（知っている世間が狭いだけかもしれないけど）。 とはいえ文章の執筆・編集という作業には、プログラムのソースコードを開発する作業とは違う側面もいっぱいあります。 そのため、ツールとしてはソフトウェア開発用のバージョン管理システムを利用する場合であっても、そのワークフローについては、執筆・編集ならではの工夫が多少は必要なのかなと考えています。 もちろん、同じソフトウェア開発でもプロジェクト
技術書をクラウドファンディングで出版してみた
あきみちさんから、「IPv6本を出すということで、クラウドファンディングで協賛を呼びかけよう」（原文ママ）というアイデアを聞いたのは、TwitterのDMのやり取りを読み返すと2016年11月23日のことだったらしい。 DMには時刻が表示されないので正確な時間はわからないけど、その後のやり取りがいつの間にか11月24日になっているので、たぶんそういう時間帯だ。 それに対するぼくの最初の返答は、「それは既存の出版社だと面倒そうだ」（原文ママ）だ。 言外に「うち（ラムダノート）ならできるよ」が含意されていることは、起業前からいろいろ相談にのってくれていたあきみちさんには間違いなく伝わる。 とはいえ、そのころはまだ『プロフェッショナルSSL/TLS』も制作中だったし、直販ストアもなかったし、ラムダノートは胸を張って「出版社」と言える状態ではなかった。 そもそも、あきみちさんやぼくは技術自体という
JSONをTeXで組版する
昨今、ドキュメント技術の主戦場といったらウェブです（ワールドワイドなほう）。 ウェブ上ではさまざまな構造化テキストが飛び交っています。 まっさきに思いつくのは、HTMLをはじめとする、ブラウザがネイティブにレンダリングできる構造化テキストでしょう。 しかしブラウザにはJavaScriptという強力なプログラミング言語の実装が組み込まれているので、HTML以外の構造化テキストをサーバから取得して整形する場合も少なくありません。 そのようなデータ形式のひとつにJSONがあります。 最近のWebサービスでは、サーバからHTMLを送らずにJSONデータだけを送り、ブラウザがそれをJavaScriptで解析して画面表示をすべて動的に作っている場合もあるようです。 この場合にブラウザがやっていることは、ある種の自動組版だといえるでしょう。 そもそもブラウザによるHTMLのレンダリング自体が自動組版だと
k16's note: TeXと10年戦ってわかったこと
世間では「TeX」と一口に言われているけど、実際には3つの異なる側面があります。10年以上TeXで何かやってきたわけだけど、「TeXはアレ」の本質はこの3つがごちゃごちゃになってるとこかなと思ったりしているので、書いてみました。 マークアップ形式としてのTeX 組版エンジンとしてのTeX プログラミング言語としてのTeX TeXの話をするときって、これら3つが案外と区別されていないなあと感じることがあります。具体的には、組版エンジンとしての機能について言及している場面でマークアップ形式の話を持ち出されたり、マークアップの話をしているときに名前空間がないからダメといった感じでプログラミング言語として批判されたり、ようするに、あまり建設的ではない。 もちろん、TeXというエコシステムについて何か言うときにはこの3つが不可分で、それぞれを切り出して論じてもしょうがないんだけど、まあポエムなので気
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
