Home > アーカイブ > 2012-09
2012-09
いまどきの技術本執筆環境 – 「CakePHP2実践入門」
共著で執筆に参加した「CakePHP2 実践入門」が2012/09/29に出版されました。
2007年に執筆した「CakePHPガイドブック(共著)」から数えて4冊目の書籍執筆となるのですが、執筆の方法やコラボレーションのツールも大きく変わりました。執筆を終えて一息ついた今、執筆環境を振り返ってみたいと思います。
2007年と今回の執筆環境をざっくりと比較するとこんな感じでした。
原稿執筆 | 原稿提出 | 連絡 | issue管理 | CI | |
---|---|---|---|---|---|
2007年 | Word | FTP | ML | ML | なし(Wordで確認) |
2012年 | Vim + Marked | Github | Facebookグループ | Github | Githubリポジトリをpollingして、Markdown+独自マークアップをHTMLにコンバートなど。 |
原稿執筆
原稿は Vim で書いて、Marked のプレビューを確認するという形で進めました。
Vim
原稿の形式は、Markdown+独自マークアップのプレーンテキストだったので、執筆陣は各自好きなツールを使うことができました。
Vim は普段から使っていて慣れていますし、技術本ということでソースコードを読んだり書いたりする場面が多いので同じエディタ上でそれができるのは楽でしたね。
Markdown ということで当初は専用のエディタなども試したのですが、やはり「書く」という行為に関しては手に馴染んでいるものが一番です。
Marked
Marked は Markdown 形式で書かれたファイルをプレビューするツールです。Marked でファイルを開いておくと元ファイルが変更されるとプレビュー側も連動して更新されます。
あくまでプレビューに特化したツールなので任意のエディタと組み合わせて使用することができるのが良いですね。
実は Vim + Marked の組み合わせが気に入ったので、この blog も同じ構成で書いています。
以前は Word だったので、プレビューという点では問題無いのですが、ソースコードが書きにくかったり、差分が取りづらかったりしていました。当時はそれが当たり前だと思っていましたが、やはりプレーンテキストで書けるのは慣れてる分、楽でした。
原稿提出、issue管理
Github
原稿提出やissue管理にはGithubを使いました。
執筆陣は各々原稿を書いて、Github へ push して原稿を提出するという流れでした。
git のメリットは言わずもがなですが、こちらも日常でソースコードを push するのと同じ感覚で原稿を提出できたのは良かったです。さらに原稿がプレーンテキストということで、差分を確認したり、変更履歴を見たりというのもお手のものでした。
今回は章ごとに執筆者が決まっていたので、conflict することも無いだろうということで、ブランチ分けはせずに master へpushしていました。
原稿の修正依頼や査読結果などの issue 管理も Github で行なっています。
Github の issue 管理では、commit ログに issue no を記載することで issue チケットから commit にリンクを貼ることができるので、issue に関する修正が明示できて、これは便利でした。
本書のサンプルコードもGithub上で公開する予定ですので、書籍を購入された方はご参照下さい。
連絡
編集の方、執筆陣との連絡には Facebook グループを使いました。
ML でも良かったのですが、メールより気軽に投稿、返信ができたのでやりやすかったです。返信するほどではないけど同意や見たことを現したい時に「いいね!(Like)」で反応できるのは手軽で便利ですね。
ただ Facebook グループだとどうしても過去の発言が流れて行ったり、一つのトッピクについてコメントが大量についたときに見づらかったりするので、もし次回があればchatworkなど別のコラボレーションツールの方が良いかもしれません。
CI
CI 的な機能もいくつか用意しました。
Githubのリポジトリをpollingしており、定期的に自動実行されます。
- PHPコードの自動lint(安藤さん作)
- 原稿中のソースコード自動抽出(安藤さん作)
- 原稿をHTMLへ自動変換、変換ブラウザで閲覧可能に(鈴木さん作)
- 原稿の規約(マークアップや一行文字数等)を検証して、エラーログを出力(鈴木さん作)
特に鈴木さんが用意してくれた原稿をブラウザで確認できるツールはかなり便利でした。書式エラーなどがログとして確認できるので、これを活用して原稿の修正を行いました。いずれ公開されると思うので乞うご期待を。
今にして思うと Jenkins でこういったツール群を管理しても良かったですね。
普段のシステム開発と同じリズムで原稿を書く
今回利用したツールはどれも普段のシステム開発で利用しているもので、ソースコードを書くのと同じリズムで執筆を進めることができました。
執筆期間中に度重なるCakePHPのバージョンアップ(2.0 -> 2.1 -> 2.2)があり、リスケを余儀なくされましたが、原稿のデグレや issue の取りこぼしもなく、無事に書店に並べることができました。
CakePHP は、公式ドキュメントである cookbook が充実しており、和訳も少しづつ進んでいるのですが、日本語で書かれたまとまった情報を望む声が多くありました。この本はそういった機運を受けて執筆されました。みなさんのCakePHP開発の一助になればと思いますので、一度手にとって頂ければ嬉しいです。
最後に、セキュリティ章について丁寧な査読、ご指摘をして頂いた徳丸浩さんにお礼を言いたいと思います。本当にありがとうございました。
- コメント (Close): 0
- トラックバック (Close): 0
ついつい気になるFacebookやTwitterを見れなくしてみた
TwitterやFacebookは楽しいし便利なんですが、つい見過ぎてしまうのが玉にキズです。PC で作業中はもちろんのこと、外出中でもスマートフォンでついつい見てしまいます。
常に見る必要は全くもって無いので、外出時に持ち歩くデバイスからはアクセスできないようにしてみました。
1. Facebook / twitter に接続できないようにする
まずは、いつも持ち歩く MacBook Air から。
/etc/hosts に以下を追記して保存します。これで www.facebook.com / twitter.com に接続できなくなります。
% sudo vim /etc/hosts 127.0.0.1 www.facebook.com 127.0.0.1 twitter.com
2. スマートフォンからアプリを削除
スマートフォンからも Facebook / Twitter クライアントアプリを削除しておきます。
3. でも投稿はしたいし、Reply や DM くらいは見たい
外に出て何か見つければ投稿したいのが人の常。そんな時に便利なのが yabmin というサービス。
メールを使った Twitter クライアントで、メールを送信するだけで投稿したり、Reply や DM がメールで送られてくるという優れもの。
Twitter アプリを開くとついついタイムラインを見て時間が過ぎてしまうから、投稿だけできるというのは便利。
Facebook でもこういうサービスがあると嬉しいな。
Facebook / Twitter は、ほどほどに付き合うのが肝要ですね。あーすっきり。
- コメント (Close): 0
- トラックバック (Close): 0
スタートアップがWebサービスのMVPを作るのに役立つ9個のTips
- 2012-09-03 (月)
- Webサービス
WebサービスのMVP(必要最小限の製品)を作るのに参考になるTipsがあったのでご紹介。
via How To Create A Minimum Viable Product | TechCrunch
1. Facebook
会員情報を一から作らずに Facebook を利用しましょう。
Facebookユーザでない人をどうするか?という指摘もありますが、元エントリにある「いまどきFacebook使っていない人は保守的だから、(自分たちが作っている)新しいWebアプリは使わないだろう。」という考え方は一理ある気がします。
2. Twitter Bootstrap
手間をかけずにそれなりの見た目になり、レスポンシブにもなるので、素早くサービスを作るために活用したいですね。
3. クラウド
最近は使うのが当たり前になってきたクラウドです。初期費用無料で、従量課金なのは先が不明確なスタートアップ向きです。
元エントリでは、Amazon S3 や heroku が紹介されています。
IaaS の自由度も良いのですが、できるだけ手間を省くという意味では、やはりデプロイやスケールアウト(アップ)が容易な PaaS が向いてると思います。
4. jQuery
まあこれも普通ですね。スタートアップに限らず多くのWebアプリケーションで使っています。
5. コアの機能にフォーカスする
余計な機能は作らずにサービスとしてコアな機能をまず作ってリリースします。まさに必要最低限の製品(MVP)です。
元エントリでは、実装しようとする機能が必要されているかどうかを確かめる方法として、新機能のリンクだけを用意しておいて、それをクリックした人が何人いるかで判断する方法が紹介されています。
MVP の概念は「リーン・スタートアップ」が参考になります。
6. SaaS
それぞれのニーズに特化した SaaS があるので、それらを活用しましょう。
元エントリでは目的に応じたSaaSが紹介されています。海外のサービスばかりなのですが、考えてみると日本ではこういったサービスは少ない気がしますね。これは提供するチャンス?
請求
ユーザサポートチャット(ライブチャット)
フォーム
ウェブ解析
ユーザサポート
データ解析
7. 動画
百聞は一件にしかずです。
サービスの内容や機能をテキストで詳細に書くよりも、実際に使っている動画を見せる方が遥かに分かりやすいです。
最近は色々なサイトで製品紹介の動画が使われていますが、有名なのはDropboxですね。この動画を公開して、ベータ版の予約数が5000から75000に増えたそうです。
クォリティの高い製品紹介動画を自分たちで作るのは大変なので、できれば専門の業者さんに依頼したいとことです。Quora に色々な業者さんの動画と費用が載っていて参考になります。
Where do most startups get their product demo videos made? How much do they cost? – Quora
日本でもこういった動画を作ってくれるところがあると嬉しいですね。
8. Internet Explorer
何かと話題(と手間を)を提供してくれる Internet Explorer ですが、コストと時間を節約するならいっそのこと Internet Explorer 対応をやめてしまうのも手です。
特に製品のターゲットユーザが先進的なユーザなら、chromeやFirefox を使っているでしょうから、全体のシェアよりもこれは合理的な判断かもしれません。
9. 今、必要な機能に絞る
作る側としては便利な機能はどんどん盛り込みたいところですが、本質では無い機能(例えば、ユーザ退会や何か登録の削除など)は初期リリース時は実装せずにメールで依頼してもらって、運営側で対応するという方法も考えられます。
どれだけ使われる機能かも分からないので、ユーザが増えて運営の手間がかかってきた段階で実装する方が良いでしょう。
コアに集中する
ざっと見ると、ライブラリやインフラなどは良く利用しますが 6. の SaaS はウェブ解析以外はあまり使っていませんね。サービスとしてコアな部分以外はできるだけこういった外部のものを利用して効率良くリリースしていきたいです。
- コメント (Close): 0
- トラックバック (Close): 0
Home > アーカイブ > 2012-09
- 検索
- フィード
- メタ情報