プログラマでありたい

おっさんになっても、プログラマでありつづけたい

エンジニアよ、越境しよう!!クラウド時代のエンジニア像

 Amazon Web Services クラウドネイティブ・アプリケーション開発技法のAppendixとして、「クラウドとエンジニア」をテーマに、クラウド時代のエンジニアのあり方について少し書きました。その趣旨としては、次のようなものです。

従来は、アプリケーション・エンジニアとインフラ・エンジニアという役割で分業することが多かったです。しかし、API GatewayやLambdaのような新しいサービスが出てくる現状で、果たしてそれを扱うのは誰なのだという問題がでてきます。

 図示化すると、次のような感じですね。
f:id:dkfj:20160421080159j:plain

アーキテクチャが変われば、エンジニアの役割も変わる



 今、Webの世界で一般的に見られるアーキテクチャはIntel LinuxサーバやWindowsサーバが普及してからのものです。せいぜい20年位の歴史だと思います。その前は、ホストを中心としたC/Sシステムなどが中心だったのでしょう。つまりプラットフォームが変われば、アーキテクチャも変わります。そして、アーキテクチャが変われば、エンジニアの役割も変わります。
 実は、今回アプリケーションをメインのターゲットにAWS本を書こうとしたのは、上記のモヤモヤっとした考えを文章化しようとしたのがキッカケです。社内のエンジニアとよく話しているのですが、インフラエンジニアがAWSのサービス群を使いこなすことによりアプリエンジニア抜きでソリューションを作ることも出来るし、アプリエンジニアがインフラ構築なしにシステムを作ることも出来るようになってきています。そうなると、両者の線引の意味があるのかとなります。
 もちろん高度に専門的なところは分業する必要があります。技術の細分化が進み、一人の人間が全てを把握するのは不可能に近くなっています。それでも、自分にインフラ・エンジニアやアプリケーション・エンジニアとラベルを貼るのをやめて、まずはいろいろやってみるのが良いのでしょうか?今回の本は、そのキッカケの一つになれるよう目指しています。実際、著者陣も執筆を機に、また一段と変わってきています。エンジニアの皆さん。越境しましょう!!

蛇足



 Amazon Web Services クラウドネイティブ・アプリケーション開発技法のAppendixに上記のようなことを書いています。ブログの会社として有名で、Developers.IOを運営するクラスメソッドさんの中の人がそれを読んで、次のような言葉を頂きました。

ちなみに付録前半を担当されたのはどなたでしょうか?うちのブログのポエム枠投稿してもらえませんかね?w

 本当に、ありがとうございますw立派なポエマー目指します。

See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました
クラウドネイティブなアプリ構築例。AWSのサービスを利用してスマホブラウザからAmazonのランキングを取得する
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリケーションをGitHubで公開しました

 Amazon Web Services クラウドネイティブ・アプリケーション開発技法は、本日発売です。それにあわせて、書籍中の説明で利用しているアプリケーションの全コードをGitHubで公開しました。

takuros/aws-application-book: Amazon Web Services クラウドネイティブ・アプリケーション開発技法のサンプルアプリ

サンプル・アプリケーション



 GitHubには、18個のサンプルアプリを格納しています。18個ですが、その中にはiOS,Android,JavaScriptもあるので、実数としてはもっと多いです。

03-01-s3-sample
03-04-dynamodb-sample
03-05-lambda-sample
03-06-CognitoSample/iOSApp
03-08-iot-sample
03-08-kinsis-sample
03-09-sqs-sample
04-01_PictureSharingApp
04-02_Android_Sample_App
04-03-AuthenticationService
04-04-APIGatewayStub/Lambda
04-05-DynamoDBAppleWatchHeatlhcareSample
04-06_AttendanceManagementApp
04-07_Android_Sample_App_For_DeviceFarm
04-08_KeywordCurationService
04-09-KinesisWithTwitter
04-10-ML-Curation-Service
04-11_CognitoSyncMemoApp

行数をカウントしてみると、3万行以上ありました。

$ wc -l `find ./ -type f`
  314886 total

追記:
よく見ると、30万行でした。
フレームワークのコードまでカウントしていたので、除外してみると次のような感じでした。

$ cloc .
     411 text files.
     326 unique files.
     434 files ignored.

https://github.com/AlDanial/cloc v 1.66  T=0.58 s (439.7 files/s, 38461.9 lines/s)
--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
C/C++ Header                     87           3585           7976           2785
Java                             35            411            305           1800
Swift                            26            363            422           1191
JavaScript                       36            136            148           1102
XML                              38            113             17            994
JSON                             18              0              0            438
Groovy                            9             37             16            199
Bourne Again Shell                1             19             20            121
HTML                              3              2              0             98
DOS Batch                         1             24              2             64
Python                            1             11              8             38
Prolog                            2              4              0             30
--------------------------------------------------------------------------------
SUM:                            257           4705           8914           8860
--------------------------------------------------------------------------------


 今回紹介しているAWSのサービス群は、自分で触っているとその凄さが実感できるものが多数あります。また、環境を用意する手間も殆どないので、ぜひ本を片手にソースをダウンロードして、自分のアプリを作っていってください。面白いものができたら、PullReqお願いします。公開方法、検討します。

追記:内容の紹介も順次やっていきます。
エンジニアよ、越境しよう!!クラウド時代のエンジニア像


See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
エンジニアよ、越境しよう!!クラウド時代のエンジニア像
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

AWS Lambda+Node.jsのモジュールcheerio-httpcliでWebスクレピングをする

 先日の『Node.jsでスクレイピングするならば』の続きを書きました。全10回くらいのシリーズになる予定で、今回は一番シンプルな静的サイト/JavaScript不要なページに関するスクレイピングの説明です。cheerio-httpcliをAWS Lambdaで動かすところで、cheerio-httpcliの説明というよりlambdaでの動かし方がメインになっています。ちなみにcheerio-httpcliは、cheerioの拡張で、最近活発に開発されています。
 なお、AWS Lambdaとはなんぞやとと言う人に簡単に説明すると、Lambdaはサーバ不要のコンピュートエンジンです。ユーザーはプログラムをアップロードするだけで実行可能で、サーバのメンテナンスはAWS側が全てやってくれるという夢のようなインフラです。普通にサーバーを立ち上げるより安く便利なことが多いので、是非知っておくべきサービスです。

cheerio-httpcliの準備とソースの記述


 まずはLambdaにアップ用にcheerio-httpcliの準備をします。
プロジェクト用のディレクトリ直下にnode_modulesを作り、そこに関連モジュールをインストールします。

$ mkdir node_modules
$ npm install cheerio-httpcli

 次に、ソースを書きます。LambdaのエンジンがNode.js 4.3になってCallBackの利用を推奨されるようになっているので(このソースでは意味無いですが、)その文法に沿って利用しておきましょう。

'use strict';
let client = require('cheerio-httpcli');

exports.handler = (event, context, callback) => {
  client.fetch('http://www.google.com/search', { q: 'node.js' }, function (err, $, res) {
    console.log(res.headers);
    console.log($('title').text());
    let list = '';
    $('a').each(function (idx) {
      console.log($(this).attr('href'));
      list = $(this).attr('href');
    });
    callback(null, list);
  });
};

 cheerio-httpcliの解説としては、http://www.google.com/searchに引数pに対して、node.jsで検索した結果を取得しています。その習得結果、resからaタグのhref属性を抜き出しています。
 "exports.handler = (event, context, callback) "とcallbackの部分がLambada用に記述しているところです。その他の部分は、Googleの検索結果を取得するというソースを拝借しています。
ソースを記述したら、先ほどのモジュールごと圧縮してzipファイルにします。
※コールバック形式とプロミス形式をどう使うかは、また回を改めて説明します。

zip -r simple-scrape.zip simple-scrape.js node_modules/

AWS Lambdaの準備



 AWSマネージメントコンソールから、Lambdaファンクションを作成します。GUIなんてという硬派な方は、CLIからでも大丈夫です。Nameは、適当につけてください。今回は、cheerio-httpcli-sampleで作っています。Handlerは、「simple-scrape.handler」です。これは、simple-scrape.js内のhandlerを実行するということです。先ほど、export.handler作りましたよね。デフォルトのindex.handlerは、index.jsのexport.handlerを読み込むという意味です。Roleは、Lambdaの実行権限をつければ大丈夫です。そして、コードはUpload a .ZIP fileを選び、先ほど作ったzipファイルをアップロードします。
f:id:dkfj:20160419011001p:plain
f:id:dkfj:20160419011007p:plain

 そして、Testで実行です。Eventの初期設定が必要ですが、引数を取らないプログラムになっているので、デフォルトをO.K.で大丈夫です。実行して、エラーが出ていないことを確認しましょう。
f:id:dkfj:20160419011313p:plain

 今回のソースは、ページタイトルとaタグを全て抜きだすというものです。実行結果については、抜き出す対象を絞り込む必要や、そもそもGoogleのbot対策など、いろいろカスタマイズするところがあります。ひとまずLambdaでcheerio-httpcliを実行の確認が出来たのではないでしょうか。次回は、cheerio-httpcliの使い方を、もう少し掘り下げて解説します。

まとめ



  • AWS LambdaでサードパーティのNode.jsモジュールを利用したい場合は、直下のnode_modulesにまとめて圧縮する
  • cheerio-httpcliは、0.3.0以降はコールバックとプロミスに対応している(未解説)

なお、AWS Lambdaの使い方については、4/20発売の本に詳しく書いています。主にモバイルアプリからの利用の仕方を中心としていますが、Lambdaの設定方法・権限付与などをこれでもかとサンプル込で解説しています。全部で600ページ超の大作です。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2016/04/20
  • メディア: 単行本
  • この商品を含むブログを見る


シリーズ目次:
Node.jsでスクレイピングするならば
AWS Lambdaでcheerio-httpcliを実行する

See Also:
『Rubyによるクローラー開発技法』を書きました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました


参照:
Node.js用のスクレイピングモジュール「cheerio-httpcli」の紹介 - Qiita

Node.jsでスクレイピングするならば

 昔、Rubyでクローラー/Webスクレイピングの本を書きました。今でもちょくちょくとスクレイピングのコードを書いたりはするのですが、実行基盤についてはサーバの運用管理が面倒くさいのでAWS Lambdaを使うことが多いです。そうなると、Lambdaは基本的にはRubyが使えないので、言語はPythonかNode.jsを利用することになります。Pythonもいいけど、今後のことを考えるとNode.js力を高めておきたいと考えています。ということで、Node.js縛りでスクレイピングの仕方です。

スクレイピング対象のページの種類



 私の中の勝手な定義ですが、スクレイピングには3種類あります。

1. 静的サイト/JavaScript不要なページに関するスクレイピング
2. 対話型サイト/JavaScript不要なページに関するスクレイピング
3. JavaScript前提のページに関するスクレイピング

下に行くほど、スクレイピングしづらくなります。

静的サイト/JavaScript不要なページに関するスクレイピング



 これが一番簡単です。HTMLを取得して、そのHTMLの中の特定のデータを抽出するだけです。利用するライブラリとしては、cheerio-httpcliあたりが良いです。

対話型サイト/JavaScript不要なページに関するスクレイピング



 対話型サイトとは、入力フォームやチェックボックスを利用してユーザが入力後にサブミットして遷移するサイトです。利用するプロトコルとしては、getではなくpostのイメージです。単純に検索条件を指定するだけであれば、postであってもパラメータを自分で付加して送ればいいのですが、認証等が絡むことが多いです。その際は、ライブラリ側もCookie等に対応してセッションを維持する必要があります。面倒くささのランクが1つあがることになります。
 こういった場合に利用するライブラリとしては、Mechanizeが定番になります。Node.jsというかJavaScript版としてmechanize-jsがあります。また、先に紹介したcheerio-cliも0.3.0以降は同様の機能が使えるようになっています。選択の悩みどころですね。

JavaScript前提のページに関するスクレイピング



 JavaScript前提のページとは、サーバサイドで画面を生成するのではなく、クライアントサイドから各要素を呼び出して動的にページを生成するタイプです。従来も画像やCSSをクライアントから呼び出してというところはあったのですが、最近は表示するデータ等をクライアントから非同期で呼び出してというパターンが増えてきています。スクレイピングという観点では、大変な場合が多いです。
 対処法としては、JavaScriptを解析してデータ部分を直接引っ張る方法と、スクレイピング側にブラウザ相当のものを用意して画面の生成をする方法があります。前者は認証認可含めて大変な場合が多く、後者はブラウザを利用するので通常のスクレイピングより多くのリソースを必要とします。Selenium+Firefoxで実現する場合もあるのですが、出来るだけ軽量に実行できるようにヘッドレスブラウザと呼ばれるCLIベースのものを利用することが多いです。代表格としては、WebKit ベースで作られたPhantomJSがあります。Node.js+Lambdaから使う際は、phantom-lambda-templateというモジュールもあります。これについては、回を改めて解説します。またPhantomJS以外では、Xvfbを利用してChromeやFirefoxなどの実ブラウザをCLIで使うという方法もあります。

まとめ



 スクレイピングの分類するだけで、結構な分量となりました。次回以降、それぞれの方法を順に解説してみようと思います。つづきは、こちら。
AWS Lambdaでcheerio-httpcliを実行する

JS+Node.jsによるWebクローラー/ネットエージェント開発テクニック

JS+Node.jsによるWebクローラー/ネットエージェント開発テクニック

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2016/04/20
  • メディア: 単行本
  • この商品を含むブログを見る

シリーズ目次:
Node.jsでスクレイピングするならば
AWS Lambdaでcheerio-httpcliを実行する

See Also:
『Rubyによるクローラー開発技法』を書きました
アプリケーションエンジニア向けのAWS本を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

Nexus 5Xを使って垣間見たスマホの未来

 深刻なAndroid力不足を感じて、個人所有の携帯電話をNexus 5Xに変更して半年くらい経ちました。会社から貸与されているiPhone6との併用です。入れているアプリは、iPhoneとほぼ同じなので使用頻度は少ないですが、最近NexusというかAndroidというか、Googleの恐ろしさ・凄さが解りました。


iPhoneとAndroidの決定的な違い



 iOS/Androidのどちらのスマホも、最近ではハードウェア・ソフトウェアともに成熟してきて大差がないというのが使い始めての感想でした。しかし、iPhoneとAndroidもといAppleとGoogleの決定的な違いが出てきました。Googleはユーザーの行動情報を全て把握して、サジェストしようとしてきているということです。
 誰でもそうであると思うのですが、PCでもスマホでも同じGoogleのアカウントを使っています。その為、Webでの行動履歴は全てGoogleに把握されています。そして、Nexus 5Xを持つことによりリアルでの位置情報も把握されるようになりました。(オフに出来ますが。)その為、Googleは高精度にユーザーの次の行動を予測できる様になっています。例えば、次のような感じです。

  • 出勤時間付近でスマホのGoogleを見ると、電車の時間が表示される
  • 退社しようとすると帰宅予定時間が出てくる
  • 隔週で通っている目黒直行の日も把握して、目黒の施設情報を出してくる

 たぶんそのうち、ふと飲みたくなって飲み屋を探そうとしたら、アプリで検索する前にGoogleがサジェストしてきますね。

スマホがアプリをサジェストする未来



 この一連の動きを見ると、次世代のスマホの在り方が見えてきます。ユーザーがアプリを選択するのではなく、スマホを触った瞬間に必要なアプリをサジェストするようになるのではと思います。もっと言うと、アプリという概念が必要なくなって、再びネイティブに統合されたブラウザアプリに戻るかもしれません。そして、その未来はAppleではなくGoogleが実現するでしょう。何故なら、Appleにはそこまでの情報はないから。
※一応補足すると、iPhoneにもアプリのサジェスト機能はあります。位置情報を元にしているらしく、ロック画面で左下の方に申し訳なさそうに出ていることがあります。

感想



 iPhoneの進化が止まったという話はよくされています。個人的には、現状の枠組みの中では既にやりきっているという認識の方が正しいのではないかと思います。そして、それを打ち破る可能性があるのは、AppleではなくGoogleではないかと感じています。
 あと、やっぱり使ってみないと解らないことは沢山ありますね。

序文 "Amazon Web Services クラウドネイティブ・アプリケーション開発技法 "

 前作の『Amazon Web Services パターン別構築・運用ガイド』の序文の一部に次のような文章を書きました。

 クラウドという言葉が一般的になってから、もう何年も経とうとしています。当初は、不慣れな従量課金やセキュリティへの不安から、採用する企業はごく一部の企業に限られていました。しかし、クラウド自身の進化と、それを取り扱うユーザ・企業・コミュニティの成長とともに、多くの企業がクラウドを検討・導入するようになりました。そして最近では、クラウドファーストという考え方のように、システムの導入の際はまずクラウドで実現できないかという考え方が当たり前になりつつあります。今では更に考え方が進み、クラウドネイティブという名のもとに、クラウドを前提としたアーキテクチャ・設計が採用されつつあります。

 この文章を書いていた当時は、2014/2015年の年の瀬でした。私の実感としては、ようやくクラウドファーストという考え方が定着してきて、(第一候補として検討するかは別に)インフラの選択肢の1つとしてクラウドを検討するというのが当たり前のようになってきました。Google Trendsでみると次のようなグラフになっています。
f:id:dkfj:20160315075304p:plain

 一方でその頃の海外では、クラウドネイティブの名の元にクラウドのサービス前提で如何に効率よく低コストで信頼性の高いシステムを構築するかの議論が活発にされていました。この流れはいずれ日本にも来ると確信していましたが、後2〜3年は掛かるのではと予想していました。ところが、AWSがLambda,API Gatewayと矢継ぎ早にサービスを展開したお陰もあって、予想以上に早く普及しそうな気配を感じます。Google Trendsのグラフを見ても、注目が集まっているのが解ります。
f:id:dkfj:20160315075903p:plain
f:id:dkfj:20160315075725p:plain

クラウドネイティブを追いかけている人たち



 一方で、クラウドネイティブ・或いはマイクロサービス/サーバレスといったアーキテクチャを追いかけている人たちは誰かと見てみると、元々AWSの構築に携わりAWSに習熟していた人たちが中心です。担当レイヤーでいうと、インフラエンジニアと呼ばれる人が多いように思えます。
 API GatewayやLambdaは、インフラエンジニアとアプリエンジニアの垣根を壊す破壊的イノベーションです。そして、そのイノベーションは、アプリエンジニアが直接利用し始めた時に、真価を発揮するのではと思っています。そういった意味で、今回の本はアプリエンジニアがクラウドを触ったらというテーマになっています。

本書の執筆陣



 今回の執筆陣は、基本的にアプリエンジニアです。前作の著者である私と佐藤も書いていますが、どちらもアプリエンジニアとしての経験を積んでいます。他のメンバーについては、特にモバイルアプリとフロントエンドアプリ(JavaScript)を得意としている人間を集めています。そういった意味で、アプリエンジニアが、AWSに入門するにはちょうど良いのではと思います。実際、執筆者たちも今まで以上にAWSのファンになっていきました。

まとめ



 『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』の序文を載せて反響を見ようと思ったのですが、書いたと思っていた序文が書いていませんでした。考えているのは、上記のようなことなので、急いでまとめます。


Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

Amazon Web Services クラウドネイティブ・アプリケーション開発技法 一番大切な知識と技術が身につく

  • 作者: NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴
  • 出版社/メーカー: SBクリエイティブ
  • 発売日: 2016/04/20
  • メディア: 単行本
  • この商品を含むブログを見る

See Also:
アプリケーションエンジニア向けのAWS本を書きました
Amazon Web Services クラウドネイティブ・アプリケーション開発技法の目次
『Rubyによるクローラー開発技法』を書きました
『Amazon Web Services パターン別構築・運用ガイド』を書きました

ドキュメント作成システム構築ガイドを読んだ

 気になっていた『ドキュメント作成システム構築ガイド』が、Kindle版になっていたので読みました。最近の私の関心テーマおよび課題とマッチしていたので、なかなか興味深かったです。

本書の内容



 本書の概要は、Amazonさんには下記のように公開されています。

アプリケーションの開発手順,製品のユーザマニュアルなど,ドキュメントの多くはエンジニアによって作成されています。ドキュメントの品質が低い場合,読み手が誰であっても内容の理解に時間がかかります。ドキュメントは簡潔で内容を正確に伝えるものでなければなりません。エンジニアにとってドキュメント作成は避けて通れません。いまやドキュメント作成はコーディングと同様にエンジニアに必要な技術なのです。本書は,ソフトウェア開発の技法に基づいてドキュメント作成を支援するシステムを構築します。このシステムではGitを用いたバージョン管理,GitHubによる共同編集,RedPenによる品質チェック,CIツールによる継続的改善などを利用します。応用としてAsciidoctorによるドキュメントのスタイル調整について解説します。Webでの公開に耐える品質はもちろん,技術文書の電子出版においても役立つ内容となっています。。

 主に技術文章を公開する人向けとあるのですが、実は対象とする読者層は多いのではないでしょうか。技術文章の範囲には、設計書等も含まれるからです。どこの現場でもあると思いますが、設計書の記述・保守については悩まされる問題だからです。

私の目的



 設計書も対象と言ったものの、私自身はその辺りにフォーカスして読んでいません。主に著書の執筆環境の改善です。またどちらかと言うと、今後挑戦しようと思う Amazon Kindle ダイレクト・パブリッシング(KDP)の為の環境作りです。また本書自体も、論文等の公開文章を前提としていると思います。

 現在、私は下記のような流れで書いています。

1. Markdownで記述
2. GitHubで管理
3. Markdownの原稿を元に確認
4. DTP出稿
5. 校正
6. 出版

 1〜3の部分については、全く問題がないです。4と5の部分が問題ありです。

 まずDTP出稿です。DTPとはDesktop publishingの略で、原稿と図表を組み合わせて印刷可能な状態にすることです。一般的に書籍のページとして見る状態にするというイメージですね。ここの部分については、現在大手の出版社とやっていることもありお任せ状態です。しかしKDPをしようと思うと、この工程を自分で行う必要があります。現状のMarkDownからの変換では、表現力・調整力不足で何らか対策が必要です。
 次に校正です。校正というのは、確認と修正です。DTPを元に確認して修正するのですが、この反映をどこにするのかが問題になります。基本はDTP済みのものに対して修正することになるのですが、そうすると元の原稿との乖離が出てくる。元原稿も修正するとなると二重管理になるという課題があります。

 この課題を解決するには、原稿からDTP化するシステムを作るしかないかなと考えています。過去にも幾つか模索したことはありますが、MarkDownの表現力では現状は難しいという結論です。そこでSphinx+reStructuredText(reST)かなと思っていました。

今回の知見



 本書で中心的に取り上げられたAsciiDoc+Asciidoctorも良さ気に見えました。Sphinx+reSTと比較してどちらを採用するか考えてみます。あと文章のフォーマットチェック(赤ペン先生?)であるRedPenは良さそうですね。JavaScript版もあるみたいなので、API化して他システムと連携することも出来そうです。これは試してみます。そして、夢のKindleダイレクト・パブリッシングで、自費出版です!!

ドキュメント作成システム構築ガイド[GitHub、RedPen、Asciidoctor、CIによる モダンライティング]

ドキュメント作成システム構築ガイド[GitHub、RedPen、Asciidoctor、CIによる モダンライティング]


See Also:
「Amazon Web Services パターン別構築・運用ガイド」の執筆環境
Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理


以下、目次です。

目次

(目次)
第1部 モダンなドキュメント作成
 第1章 ドキュメンテーション入門
 第2章 利用するツールの準備
 第3章 Markdownによるシンプルなドキュメントの作成
 第4章 GitHubによるドキュメントの管理
 第5章 RedPenによるドキュメントの自動チェック
第2部 本格的なドキュメントの作成
 第6章 AsciiDocによるドキュメントの作成
 第7章 Asciidoctorによる出力フォーマットへの変換
 第8章 Asciidoctorによるスタイルの調整
 第9章 ドキュメント作成システムの構築
Appendix1 AsciidoctorのHTMLスタイル設定