6月25日(土)に、秋葉原・通運会館にて開催された「技術書典」に行ってきました。このイベントは、ITエンジニアなら誰でもお世話になるであろう「技術書」をテーマとする「技術書オンリーイベント」で、今回が初開催であるばかりか、おそらく業界でも初ではないかと思われる新しい試みです。 （上記写真は技術書典の会場となった通運会館） 会場にはIT系出版社から技術コミュニティまでの多種多様な出展サークルと、それらが頒布する書籍や冊子を買い求めるたくさんの来場者が集まりました。1日で約1400人が来場したという、熱量の高いイベントの模様をお伝えします！ 技術書典の主旨と内容 技術書典のWebサイトに、イベントの主旨が説明されていますので引用します。 技術書典とは、新しい技術に出会えるお祭りです。技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。技術書を中心として出展者はノウハウを詰め込み

はじめに ドキュメントを書くための言語としておそらく今一番ポピュラーなのは Markdown だと思いますが、 かっちりした仕様書やユーザーマニュアルなど、より本格的なドキュメント作成にはやや機能不足と感じることがあります。 私も以前、ドキュメントを Gitbook で作れないか検討したことがあったんですが 表を書くのがめんどくさかったり、図のキャプションなどに対応していなかったことから断念しました。 そこで、今回は Markdown よりも表現力の高い言語として知られる AsciiDoc を試してみます。 AsciiDoc は O'reilly でも採用されているほか、Pro Git や JavaScript Promise の本 などの非常に完成度の高い技術ドキュメントが AsciiDoc で書かれています。 （参考記事） ・テクニカルライティングの未来を先取り ー Asciidoc

はじめに 本稿では技術文書の指南書で解説されている文書の問題点を RedPen で発見する方法について解説します。紹介する文書の問題点は以下の指南書で解説されている内容です（執筆者の敬称略）。 理科系の作文技術（木下 是雄） 数学文章作法（結城 浩） 文章の書き方（山本 和彦） 上記の指南書で解説されている問題点の多くはシンプルです。しかし残念ながら、指南書で解説されている文書の問題点はプログラムのコーディング規約ほど広く認知されていません。さらに問題点に注意しながら文書を執筆するのは簡単ではありません。たとえば、textlint を開発されている @azu_reさん は以下のように述べています。 あなたはIMEほど記憶能力が高くないが、IMEはあなたほど賢くない。 なので二つで作った文章には綻びが生じやすい。 それをtextlintやRedPenなどの第三者が見つける。 — azu (@

概要 RedPen は JJUG CCC 2016 Spring 「Javaでつくる技術ドキュメントのバリデーション環境」で紹介されていた文書校正用ツールで、CLIやWebサーバ上で動作します。今すぐ試してみたい場合は公式サイトに デモ用 Web ツール が用意されていますので、そちらを試してみるとよいでしょう。 また、RedPen は Java のライブラリとしても提供されており、自分のアプリケーションでこのライブラリが提供するドキュメントチェック・校正の機能を簡単に利用することが可能です。というわけで、今回はこの RedPen を Java ライブラリとして使ってみました。 要件 ソースコード に Lambda 式や Stream API が利用されているため、 Java8 が必要です。 Software Version

概要 「リクルートテクノロジーズ　オープンラボ」はリクルートグループのサービス開発やインフラの運用を手がけるリクルートテクノロジーズが主催する技術勉強会です。毎回テーマを設け、社内外から講師を招いて開催していく予定です。 第3回となる今回のテーマは Infrastructure as Code です。 Infrastructure as Code を大局的な視点から語る、という内容がメインで、実践的な内容は少なめです。Infrastructure as Code の過去と現在から、未来がどのようになっていくのかを考える、そういった場としたいと考えています。 ご興味のある皆様は是非ご参加ください。 時間 タイトル 発表者

Recruit Technologies Open Lab #03 の懇親会のページです。 本編のエントリはこちらからお願いします 食べ物や飲み物の用意の関係上、だいたいの参加人数を把握したいので、懇親会参加の方はこちらへエントリをお願い致します。参加するかもしんないって人はとりあえずエントリしといてください。そんなノリで大丈夫です。なお、参加費は無料です。 ※懇親会のみの参加はご遠慮下さいませ。

環境 Jenkins 2.8 Jenkins Warnings Plug-in 4.56 Redpen 1.5.5 モチベーション 最近、技術ドキュメントを GitBook を使って Markdown で書いている。 GitBook は当然 Git リポジトリが使えて、WebHook まで使える。 こうなってくると Jenkins で CI をして、校正結果をグラフにしたくなってくるので、 Jenkins と同じ Java で書かれた Redpen を使ってみている。 Jenkins Warnings Plugin の設定 まずは Jenkins Warnings Plugin にパーサーを追加する。 設定は以下のようにする。 名前 … Redpen リンク名 … Redpen 警告 推移レポート名 … Redpen 警告 正規表現 (.+):(\d+?): ValidationError

ATL の伊藤です。この度、RedPen version 1.6 をリリースしました。変更の目玉はRe:VIEW フォーマットのサポートとアノテーションによるエラー抑制です。 Re:VIEW フォーマットのサポート Re:VIEW は Markdown や Wki 記法 のようなマークアップ言語のひとつです。Re:VIEW をサポートしてほしいという意見は RedPen 開発当初から頂いていたのですが、やっと対応できました。 以下、Re:VIEW のホームページです。 https://github.com/kmuto/review/wiki Re:VIEW は表現豊かなマークアップ言語です。reSt や AsciiDoc に比べても機能（記法）が豊富に提供されています。その豊かな表現力から、多くの技術書籍 を含む本格的なドキュメントがすでに Re:VIEW で記述されています。書籍を出版す

ドキュメント作成システム構築ガイド[GitHub、RedPen、Asciidoctor、CIによる モダンライティング] 作者: 伊藤敬彦,吉村孝広,208出版社/メーカー: 技術評論社発売日: 2016/03/25メディア: 単行本（ソフトカバー）この商品を含むブログ (2件) を見る 読むに至った背景 現場や会社でのドキュメントをMicrosoft Office使っているが、更新が頻繁に入ると凄い手間。 チームでドキュメント作成・更新すると必ずコンフリクト*1が起きて、直すのに時間がかかる＆マージ漏れ発生の可能性大。 そんな作業に嫌気が刺していたので、システムチックにドキュメント整備したいと思って読んだ。 Microsoft Office製品はあまり好きじゃない。 いや、あえていおう！力スであると！ 奮起せよ！システムエンジニアたちよ！エクセルドキュメントからは脱せねばならない時にある

リクルートテクノロジーズアドバンスドテクノロジーラボの石川有です．2016年4月29日に技術評論社様より発売される「詳解 Apache Spark」を共著で執筆しました．技術評論社様，レビューをしていただいた皆様に厚く御礼を申し上げます．また日本で Spark のプロフェッショナルな方々にお声掛けして，各コンポーネントに精通した豪華な執筆陣を組めたことに感謝いたします． Apache Spark は分散処理のコア機能以外に，SQL インタフェースや機械学習やストリーミング処理などさまざまなコンポーネントを内包しています．そこで本書では各コンポーネントに精通した著者の分担での執筆と致しました．全体としては，基本機能の解説だけでなく，より実践的な使い方を示すことでより理解が深まるような構成となっています． 私は機械学習ライブラリ MLlib を普段追っかけていますが，本書では５章の「DataF

「することができる」とは 技術文書を読んでいると「することができる」「することが可能である」という表現を目にします。実はこの「することができる」という表現は冗長なため有害、つまり多用すべきでないという考えがあります。 気になって「することができる」についてGoogleで検索してみました。結果、「することができる」という表現について書いたブログ記事をいくつか見つけました。以下、発見したブログ記事の一覧です。 読みやすい文章の極意は「修飾語」にあり 読みやすい文章を書くために心がけたい１０のポイント 感性工学的テキスト商品学～書き言葉のマーケティング 列挙したブログ記事の全てで「することができる」を多用しないように警告しています。 「することができる」を自動で検知 私も「することができる」「することが可能である」のような冗長表現をできるだけ利用しないように気をつけています。「することはできる」

はじめに 今月は技術学習をしないからってブログを書いちゃダメってわけじゃないんですがどうも滞ってますね。今年はドキュメント作成をクールでエレガントに！というすこぶる曖昧なテーマを掲げて活動しています。以下の本を読みました。 ドキュメント作成システム構築ガイド[GitHub、RedPen、Asciidoctor、CIによる モダンライティング] 作者: 伊藤敬彦,吉村孝広出版社/メーカー: 技術評論社発売日: 2016/03/25メディア: Kindle版この商品を含むブログを見る ドキュメント作成システム構築ガイド githubでドキュメントを管理し、チームで開発する環境を整える。 次にredpenという構成ツールでドキュメントのテストをする。（赤ペン先生ですね。） そしてコミットが起きるたびにredpenが動くようにTravisでgithubと連携する。 できあがったドキュメントをasc

木戸です。入社して２ヶ月が経ちました。ブログの投稿本数も１１本（５．５／月）と比較的順調なペースで書いています。 社内のブログの執筆環境は人それぞれのようで、Wordpress で直接書いている人や、Mac で Markdown エディタを使って書いている人など様々なようです。 試行錯誤して、なんとなく自分にあったブログ執筆環境が整ってきたのでブログで紹介してみたいと思います。 参考になれば幸いです。 ブログ執筆環境要件 私のブログ執筆環境要件を以下にまとめました。 執筆 フォーマットは Markdown 形式で書きたい。 修正履歴を残したい Mac と iPhone の両方で書けるようにしたい。 Elasticsearch の記事は自動的に電子書籍化（PDF ePub）してまとめて読めるようにしたい。 文章の校正ルールの検査を自動化したい。 公開 WordPress へはそのままコピペし

前のブログでもちょっと書いたけど。 ドキュメント作成システム構築ガイド[GitHub、RedPen、Asciidoctor、CIによる モダンライティング] 作者: 伊藤敬彦,吉村孝広出版社/メーカー: 技術評論社発売日: 2016/03/25メディア: Kindle版この商品を含むブログを見る ドキュメントと仕様書(一緒か)、そして実装は常に一体であるべき、というのは基本的な考え方。 ドキュメントから実装が生成される、実装からドキュメントが作られる、というのは究極の理想だけど、もうちょっとドキュメント作成が簡単になればね、ということで購入。 主に内容はMarkdownやAsciiDoc、さらに著者らが開発に参加しているRedPenなどの使用方法の紹介。GitHubによるドキュメント管理の方法からgitの使い方まで書いてあるけど、簡単すぎるので省略。 一番しっかり読んだのはRedPenの使

Atom の Package linter-redpen を作りました。 以前もこのような RedPen を使った Package を書いていたので第二弾という感じです。 特徴 "何行目の何文字目" までナビゲート 以前作った redpen package は文書の問題箇所を列挙し、クリックすることで該当行にジャンプすることが出来ました。しかし、具体的な場所（何文字目）までのナビゲーションには対応出来ていませんでした。そこで Atom で使っている他の Lint 系 Package と同じようにピンポイントの場所までナビゲートしてくれるようなものを作りました。 他の linter-XXX ファミリーに準拠した形で linter service の API を使って実装しました。 redpen-server サポート RedPen にはサーバー機能があります。このサーバーには REST AP