2017/12/06

英語圏のIT系技術書ブランドについての雑感

この記事はpyspa Advent Calendar 2017の6日めのために書きましたが、アマゾンアソシエイト目的です。

『退屈なことはPythonにやらせよう』が出た

2017年にブレイクしたPythonの本といえば、オライリー・ジャパンから発行された『退屈なことはPythonにやらせよう』ですよね。

実はこの本、そのむかし、自分でも翻訳発行をひそかに検討していたのです。 当時の翻訳者候補の方とのDMをさかのぼってみたら、少なくとも2015年7月以前の話でした。 「非プログラマーでもプログラミングしようぜ」という趣旨で著された本書は、わたし自身の書籍企画の方向性によくマッチしていました。 それで本書に目を付けたのですが、いかんせん分量は多いし、Pythonは日本だと入門者向け言語としていまいち盛り上がらないし(当時の話です)、なにより例題があんまりぐっとこないねという話で、そのときは企画化をパスするという結論を出しました。 これは余談にして重要なポイントでもあるんですが、それから起きた出来事を思うと、このとき本書を自分が企画化しなかったのは別の意味でも正解でした。

それから数年たち、Pythonブームという絶好のタイミングで本書が日本語化され、たくさんの人に読まれるに至ったのは、掛け値なしにとてもうれしいことです(ほんとだよ)。 逃がした魚は大きい的な気持ちもないではないですが、ぶっちゃけると、オライリーという看板で出たことが本書の日本での普及にとってとても大きなことだったと思います。

さて、ここで「アレ?」と思う人がいるかもしれません。 「この本はオライリーなのに、オライリーの編集者じゃないおまえが企画を検討してたって、いったいどういうこと?」

オライリーの本はO'Reillyの本とは限らない

『退屈なことはPythonにやらせよう』の原書は、O'Reilly Mediaではなく、No Starch Pressという北米の出版社による発行です。

https://www.nostarch.com/

この出版社の名前を聞くのは初めてという人でも、コンピュータ書に関する情報を気にしている方なら、その発行タイトルのなかには知っているものが少なからずあるでしょう。 No Starch Press発行の本で翻訳されているものを、思いつく限りざっと並べてみます(もちろん全部ではありません(たぶん))。

そうそうたるラインナップですよね。 さらに面白いことに、No Starch Pressは『マンガでわかる統計学』などの英語版の出版社でもあります。

いまではこんなにすごいNo Starch Pressですが、もとはBill Pollockという人が立ち上げた小さな出版社でした。 2006年にBillさんに会ったころもまだまだ小さい出版社でしたが、この10年くらいで一気に魅力的なラインナップを増やし、いまではIT系技術書界隈でかなりの存在感を示しています。 ここでまた余談だけど重要なポイントとして、2006年にBillさんに『マンガでわかる統計学』の版権買ってよという話をするとき、「エディターです」と自己紹介したら、「おれはパブリッシャーだぜ」と冗談で返されたのが自分のなかではものすごい衝撃で、いつかおれもパブリッシャーって名乗るぞとぼんやり思ったのでした (もっともBillさんはぼくのことさえ覚えてない気がする)。

話をもどすと、上記のNo Starch Pressの翻訳書のなかには、『退屈なことはPythonにやらせよう』以外にも、いくつかオライリー・ジャパン発行のものが含まれています。 つまりオライリー・ジャパンから発行されている翻訳書は、必ずしも世界的な技術書ブランドであるO'Reilly Mediaのタイトルだけではないのです。 オライリー・ジャパンの中の人は、No Starch Pressをはじめ、さまざまな海外の出版社からこれはと思う良タイトルをO'Reilly Mediaに限らず探してきて翻訳発行しているわけです。 これぞO'Reillyというカバーだけど動物の版画でない本がけっこうあるのは(宇宙人までいる)、そういうわけなのです。

No Starch Press以外で、日本ではO'Reillyブランドの技術書として誤認されてるんじゃないかなと感じてる本としては、たとえばこんな例があります。

上記6点は、すべて原書出版社がちがいます。当ててみよう。Hayao(-ε-δ)‏ さんに教えていただいたのでアソシエイト効果がありそうなほうを追記しました。Hayao(-ε-δ)‏ さんありがとうございます!)

なお、逆のパターンである「O'Reillyの本がオライリーから出ているとは限らない」も真です。 ただし、最近はO'Reilly Mediaのラインナップの魅力が落ちてるのと、O'Reillyブランドで魅力的なのはオライリー・ジャパンがしっかり出してくるので、ほぼオライリー・ジャパンから出てきているように見えます。

動物だけではない英語圏の技術書ブランド

ここまで長々とアマゾンアソシエイトを張りまくってきましたが、ここからが本記事のタイトルでもある「雑感」です。

2017年現在の英語圏におけるIT系出版社のブランド地図は、たとえば2000年代前半のそれとはかなり変動しています。 2000年代前半は、その当時で創業20年くらいのイケイケO'Reilly Mediaに圧倒的なブランド力がありました。 しかし現在は、この記事でも一押しのNo Starch Pressはじめ、やはり中堅どころのManning Publicationsなど、現時点で創業20年前後を迎えている中小の出版社のほうがむしろ精力的に面白い書籍を生み出している印象があります。 彗星のごとく登場してあっというまに手堅い出版社となったPragmatic Bookshelfも、これから創業20年前後にかけて、もうひと化けするかもしれません。

そうした出版社に比べると、すでに40年近い歴史を持つO'Reilly Mediaは、経営規模で見ても大手出版社として網羅的なラインナップを擁し、中小出版社の書籍の発売元として流通を支える存在にまで成長していますが、発行書籍の面白さとかクオリティという点では最近ぱっとしないなというのが率直な感想です。 それに呼応するように、いま企画が好調なオライリー・ジャパンが、少なくとも翻訳書についてO'Reillyタイトル依存でなくなっているというのは感慨深いところです。 そういえばオライリー・ジャパンも、いまちょうど創業20年ちょっとですね。

一方、O'Reilly Mediaよりさらに老舗のPearsonや、そのハイエンドコンピュータ書籍のレーベルとしてのAddison-Wesleyは、タイトル数こそ多くないですが、IT系技術書出版社としての信頼感はいまなお顕在だなあと感じることがわりとあります。 タイトルに対する信頼感という意味では、The MIT PressやCambridge University Pressなどの大学出版系も依然として強くて、これからも日本語で読めるようにしていくべきだと思えるような本はこのへんの老舗出版社のものがますます多くなるのかも、と思っています。

精力的といえば、英国を拠点に爆発的にラインナップを増やして一気に存在感を増したPacktという出版社もあります。 Packtの特徴は、とにかく最速であらゆるIT系のトピックについて書籍の形をしたものをそろえるという戦略です。 そうしたラインナップ網羅主義は、ある意味ではO'Reilly Mediaが目指してきたところだとも思います。 ラインナップ網羅主義には、個別のタイトルの出来不出来をケアできないという面があるので、個人的には避けていきたい方向性ですが、いかんせん展開が速いので、Packtの傾向にも注目だけはしていこうと思っています。

今回のオチ

日本語圏におけるIT系技術書の状況については、あまり大きなことを言える立場にないですが、いろんな人たちの紆余曲折とか踏ん張りとか地道な出版活動とかあって、いろんなブランドが盛り上がったり、消えたり、地に落ちたり、新しく誕生したりしています。

そんななかで、この記事をここまで読んでアマゾンアソシエイトを踏まなかった方には、2017年に4つのタイトルを発売して始動したラムダノートというIT系技術書出版社の名前を覚えてもらえるとうれしいです。

2017/12/03

TeXでつくる『RubyでつくるRuby』

この記事はTeX & LaTeX Advent Calendar 2017の3日めのために書きましたが、宣伝目的です。

TeX & LaTeX Advent Calendar 2017の重点テーマは「TeXでつくるアレ」とのことですが、偶然にも2017年、よく似たタイトルの『RubyでつくるRuby』(遠藤侑介著)という本が出ました。 プログラミング言語を学ぶときの例題としてプログラミング言語をつくる以上に格好のネタはない、という趣旨の本です。

プログラミング言語をつくるというと、なにやら難しく聞こえるかもしれませんが、『RubyでつくるRuby』では、わずか150ページのなかにそのエッセンスを凝縮しています。 本文の理解を助けるかわいらしいイラストもフルカラーでふんだんに用意されているので、はじめてプログラムを書いてみようかなという人でも、おそらく(願わくば)読み通せる内容です。 電子書籍はなく、古き良き紙の本のみですが、電子版がいいという人はAscii.jpでもとになった連載が読めるので、そちらをどうぞ!

プログラミング言語の処理系が扱うデータは「木」

『RubyでつくるRuby』では、プログラミング言語Rubyで書かれたプログラムを処理して実行するプログラミング言語を、プログラミング言語Rubyでつくります。 つまり、本書の読者が書くことになるプログラムが処理するのは、Rubyのプログラムです。

Rubyに限りませんが、多くのプログラミング言語では、プログラマーが書いたプログラムを実行する前に、そのプログラムをまず「木」と呼ばれる種類のデータへと変換します。 この「木」は、その名のとおり樹木のような姿をしていて、「枝がのびる節」と「葉」があります。

このへんは、文章で説明するよりも、絵で見るほうがはやいでしょう。 たとえば、次のようなRubyのプログラム(四則演算だけですが)がどんな木になるかというと……

(1 + 2) / 3 * 4 * (56 / 7 + 8 + 9) 

こんな木になります。式で見るより、項どうしの演算の関係がわかりやすいですね。

本書の解説には「木」を扱う場面がたくさん出てくるので、説明文やコードに加えてこんな具合に木の絵をたくさん用意できれば、いま説明しているデータの姿がどんなようすなのか「ひとめ」でわかります。 なので、ぜひ木の絵はたくさん載せたい。

かといって、こういう木の絵をぜんぶイラストレーターさんに描いてもらうのもたいへんです。 描くほうだけでなく、間違ってないかチェックするほうもめんどくさい。 それなりの見た目で、なおかつ間違いなくプログラムの木を描くには、どうすればいいでしょうか?

そう、TeXを使えばいいのです。 実際、上に例として出した木もTeXで生成しています。

TeXで木を描く

というわけで、前置きが長くなりましたが、『RubyでつくるRuby』の木の絵をTeXでどう描いたかをちょっと紹介します。 書籍『RubyでつくるRuby』では、プログラムの木を、Rubyにおける配列表現からTeXで生成しました。 これなら手間もかからず、なにより作図にともなう間違いもありません。

tikz-qtreeパッケージの使い方

木は、プログラムに限らずいろいろな場面に出てくるデータ構造なので、関連するTeXパッケージがわりとたくさん出そろっています。 そのなかで『RubyでつくるRuby』の木を描くのに選んだのは、 tikz-qtree というTikZベースのパッケージです。

https://ctan.org/pkg/tikz-qtree

この tikz-qtree パッケージを選んだ理由のひとつは、上下逆向きの木構造を手軽に描けることです。 木構造を描くときは、根を上にする(つまり本物の樹木でいったら上下逆)ことが多いのですが、本書の場合にはイラストにある本物っぽい木の絵とシームレスに読み替えてもらいたいので、根を下にして木構造を描ける機能が重要だったのです。

tikz-qtree のミニマルな例を示します。これは 2 * 4 というRubyプログラムの「木」の例です。

\documentclass[tikz,convert={outext=.png}]{standalone} 
\usepackage{tikz-qtree}
\begin{document}

\begin{tikzpicture}
  \Tree [.*
          [2 
           \node[draw]{4};
          ]]
\end{tikzpicture}

\end{document} 

\Tree[ ] のなかに、木を描いてきます。 [ ] を入れ子にすると、その中に書いたものが子どもの要素になります。 要素としてスペース区切りで値を書き込めば、それが葉になります。 子を持つ要素には、値の前に「 . 」をつけます。 上の例では、根にあたる「 * 」に「 . 」が必要です。 さらに上の例では、TikZの \node 命令がそのまま使えることを示すために、「4」のほうだけ枠をつけてみました( \node 命令なので末尾に ; を忘れずに!)。

上記を tree.tex として保存し、以下のようにpdflatexで処理すれば……

$ pdflatex --shell-escape tree.tex 

こんな絵が得られます。

この木の上下をさかさまにするには、 tikzpicture 環境に [grow'=up] というオプションをつけるだけです。

\documentclass[tikz,convert={outext=.png}]{standalone} 
\usepackage{tikz-qtree}
\begin{document}

\begin{tikzpicture}[grow'=up]
  \Tree [.*
          [2 
           \node[draw]{4};
          ]]
\end{tikzpicture}

\end{document} 

このままだと絵として味気ないので、色をぬったり、枠の形を変えたり、線の幅を調整したりするわけですが、そのへんはTikZの \node をごにょごにょいじるというつまらない話なので割愛します。 TikZのマニュアル(むかしは400ページくらいでしたが、いまでは1000ページ超)を片手にがんばってみてください。

TikZソースを木のソースから生成する

木の見た目を整えたら、毎回TikZを手描きするのはばかばかしいので、プログラムで生成するようにします。 『RubyでつくるRuby』で描きたいのはプログラムを表す木で、その木はRubyコードとしてはこんなふうな姿をしています。

["*", 2, 4] 

本当は、 2 とか 4 が何ものであるかを表すために、もうちょっとメタ情報がついていますが、だいたいこんな感じです。 (そもそも、配列でプログラムの木を表すのはあくまでも『RubyでつくるRuby』の中に限定した話で、じっさいのRubyではまったくべつの表現方法です。)

これはどう見てもS式なので、カンマを削除してGaucheで直接読み込んで変換し、 tikz-qtree パッケージを使った木を描くTeXソースを吐くようにしましょう。

(use srfi-13)
(use text.tree)

(define (deco-b b)
  #"\\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\\small ~b};")
  
(define (deco-l l)
  #"\\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\\mystrut\\smash{~l}};")

(define *before-tikz* "\
\n\\begin{tikzpicture}[grow'=up] \
\n  \\tikzset{ \
\n    every tree node/.style={font=\\ttfamily\\large}, \
\n    edge from parent/.append style={very thick}} \
\n  \\Tree ")

(define *end-tikz* "\n\\end{tikzpicture}\n\\clearpage\n")

(define *before-doc* "\
\n\\documentclass[tikz,border=10pt,convert={outext=.png}]{standalone} \
\n\\def\\mystrut{\\rule{0pt}{1.3ex}} \
\n\\usepackage{tikz} \
\n\\usepackage{tikz-qtree} \
\n\\usetikzlibrary{shapes.geometric,shadows}% \
\n\\begin{document}\n")

(define *end-doc* "\n\\end{document}\n")

(define (tikzqtree ts)
  (list *before-tikz* (mkqtree ts) *end-tikz*))

(define (mkqtree ts)
  (cond ((null? ts) "")
        ((pair? ts) (mkbranch
                      (car ts)
                      (map mkqtree (cdr ts))))
        (else (mkleaf ts))))

(define (mkbranch b l)
  (list "[." (deco-b (x->string b)) "\n " l "]"))

(define (mkleaf l)
  (list (deco-l (x->string l)) " "))

(define (main args)
  (call-with-input-file (cadr args)
    (lambda (p)
      (print
       (tree->string
        (list
         *before-doc*
         (map tikzqtree (port->sexp-list p))
         *end-doc*)))))) 

カンマをプログラムで削除しないのは、カンマなしならS式としてそのままreadできるからです。この手のユーティリティはコーディングが簡単なほうに倒してガッっと書いてしまうのが肝要だと思います。

実行結果

最初に紹介した、わりと複雑なかっこうをしている次のようなRubyの計算式について、プログラムの木を描いてみましょう。

(1 + 2) / 3 * 4 * (56 / 7 + 8 + 9) 

この計算式は、『RubyでつくるRuby』ではこんな感じの木(配列の配列)として表されます。

["*", ["*", ["/", ["+", 1, 2], 3], 4], ["+", ["+", ["/", 56, 7], 8], 9]] 

この一行をファイルに保存して、カンマだけエディタで削除し、先ほどのGaucheスクリプトで読み込むと……

$ gosh mktree.scm temp.rb > temp.tex 

こんな気持ちの悪いLaTeXのソースができます。

\documentclass[tikz,border=10pt,convert={outext=.png}]{standalone}
\def\mystrut{\rule{0pt}{1.3ex}}
\usepackage{tikz}
\usepackage{tikz-qtree}
\usetikzlibrary{shapes.geometric,shadows}%
\begin{document}

\begin{tikzpicture}[grow'=up]
  \tikzset{
    every tree node/.style={font=\ttfamily\large},
    edge from parent/.append style={very thick}}
  \Tree [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small *};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small *};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small /};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{1}}; \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{2}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{3}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{4}}; ][.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small +};
 [.\node[text=white,inner sep=4pt,drop shadow,fill={rgb:blue,5;white,1;green,1},draw,rounded corners]{\small /};
 \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{56}}; \node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{7}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{8}}; ]\node[text=white,inner sep=2pt,drop shadow,fill={rgb:green,6;white,1;black,4},draw,ellipse]{\mystrut\smash{9}}; ]]
\end{tikzpicture}
\clearpage

\end{document} 

これをコンパイルすると……

$ pdflatex --shell-escape temp.tex 

冒頭に掲載したような、こんなきれいなpngファイルが得られるというわけでした。

まとめ

『RubyでつくるRuby』を読むと、このような「木」がプログラムそのものだということがわかります。 このように生成された図だけでなく、hirekoke画伯描きおろしカラーイラストも豊富に掲載された『RubyでつくるRuby』をいますぐ買おう!

繰り返しになりますが、電子版はラムダノートでは出版していないものの、Ascii.jpでもとになった連載が読めます。ぜんぶ無料!

2017/08/21

LLイベント2017の「第2プログラミング言語鑑定団」で鹿野が話したことまとめ

プログラミング好きにもいろいろあって、仕事で使ってる道具をもっと知りたいという人もいれば、自分が使ったことない道具の話を知りたいという人もいれば、道具はなんでもいいから面白い話がしたいという人もいます。 久しぶりに参加したLLイベントは、そんな多様なプログラミング好きが「全員がアウェーな立場」で交流するという、貴重で面白い機会でした。 実際、「LL」の1つめのLには去年までは「Lightweight」という意味があり、その単語が示す特徴をもった言語のイベントのようにどうしても見えてたんですが、今年からはそういう区切りも公けになくし、Lは「Learn」の意味になったとのことです。

そのLLイベント2017で、「第2プログラミング言語鑑定団」というセッションに出させてもらいました。 司会の小山さんが「Teratail, Yahoo知恵袋などから、それらしい質問をかき集めてマージ」した6パターンの「次に学ぶ言語は何がいい?」に対し、鑑定団の一人としてお勧め言語を紹介せよというのがミッションでした。 ぼく以外の鑑定団のメンバーは、ささけんさん高野さん高橋さん。一癖あるすごいITエンジニアばっかりだー。このメンバーが集まるというだけで、LLイベントすごいって気持ちになりました。

いっぽう、ぼく自身はただの書籍編集者です。 自分の仕事に必要な道具を作ったり環境を整えたりはするけどエンジニアというわけではないし、プログラミングは好きで勉強はするけど研究者ではないし、 本職ではない人間になんという無茶ぶりかと思って最初は躊躇したのですが、たぶん、この記事を書かせてもらったことをきっかけに声をかけてもらえたんだろうなあ。

employment.en-japan.com

なお、上記の記事は「ElixirとRustとHaskellにちょっと興味がある人向けの紹介記事を各界の第一人者に書いてもらおう」という企画の前フリなので、そういう目線でやさしい気持ちで読んでもらうと幸いです。 ElixirRustはすでに公開中。今月中にHaskellも公開される予定です(宣伝)。

ほかの鑑定団の回答

そもそもブログで自分の回答を書くつもりはなかったんですが、ささけんさんがさっくりと自分の回答をまとめて公開したので、まとめざるを得なくなった。

[高野さんと高橋さんが何か公開されたらリンクはる予定地]

鹿野はどんな言語を勧めたか

想定質問は事前に見せてもらってたのですが、じゃあその質問に対して何を答えることが求められてるんだろうというのは、正直なところ当日になってもわからなくて、会場に着くまでは「ちょっとまずいかもなあ」と暗い気持ちでいました。 で、それを一緒に来ていた同僚に愚痴ったところ、「お勧め本を紹介したらいいじゃん」という画期的な入れ知恵をしてもらい、その路線でいくことに決めたのでした。

質問1

文系の大学4年生のときにプログラミングが好きになり、独学で C と Java の初歩を学びました。卒業後Web 制作会社に入社し、HTML, CSS,JavaScript を習得しました。Web周辺だけでは将来が不安なので、次に何を学ぶべきか考えています。アドバイスをいただけないでしょうか。

この質問を最初にみたときは「知らんがな」という思いしか去来せず、サイコロでも投げて決めろと言いたかったのですが、言語じゃなくて書籍であれば紹介すべきものがすぐに思いつきました。 五十嵐先生の『プログラミング in OCaml』です。なので、回答は「OCaml」にしました。

あらかじめ断っておくと、ぼくはOCamlを実用してるわけではありません。 OCamlのコードをいじったのは、『型システム入門』を作ったとき、OCamlで書かれた原著者ビルド環境を日本語pLaTeX向けに改修したときくらいです。 ですが、この本は、OCamlを使うつもりがとくにない人でも、独力でプログラミングを学んできたような人であれば、読むといいことがたくさん書いてあると思っています。 具体的には、OCamlというプログラミング言語でのプログラムの書き方だけでなく、どうしてそういう機構になっているのかがいちいち詳しく解説されており、プログラミング言語の理論についても味見できるようになっています。 この質問者はWeb周辺の技術を追いかける以外の勉強をしたいようだし、そういう意味でもぴったりではないかと思いました。

質問2

文系大学に通う学生ですが、昔からゲームが好きで、将来はゲームクリエイターになりたいと考えています。そうはいってもプログラミングはまだできないし、特筆したスキルもありません。ゲームクリエイターに関する書籍を読んで、将来こんなゲームを作りたいと夢を膨らませています。私がゲーム開発者になるためにはどの言語から学ぶのがよいでしょうか?

ゲーム作りたいといってる時点で、プログラミング言語を選んでる場合じゃなく、むしろどのゲームエンジンを使ってみればいいかという話なんですよね。 なので、回答は「Unity」か「Unreal Engine」にしました。

書籍として紹介したのは、『Unreal Engine 4で極めるゲーム開発』です。無責任にも自分では読んでないんですが、渋川さんが激烈に勧めているので間違いないでしょう。

質問3

Web制作会社でサーバサイドを開発しているソフトウェアエンジニアです。現在使っているプログラミング言語はRubyでフレームワークはRailsです。最近世の中でAIや機械学習がブームになっていて、私もそちら方面のスキルを磨いてより高度な作業をできるようになりたいと考えています。AIや機械学習を使いこなすのに最適なプログラミング言語は何でしょうか?

機械学習で縛られてる設問なので、Pythonからは逃げられないような気がします。ということで、回答としては「Python」。

でも、たぶんPythonを学べばどうなるものでもなく、線形代数なんかを地道に復習したほうがいいような気もします。 そのへんからかみ砕いて解説されているという点で、書籍は『ゼロから作るDeep Learning』をお勧めにしました。

質問4

SIerとして大手案件の2次下請けを仕事にしています。主に使っている言語はJavaでフレームワークはStrutsです。噂ではStrutsにもSIerにも未来はもう無いそうで、転職して他の仕事もできるようになりたいのですが、これまでJavaしか使ったことがないのでどうしたら良いか分かりません。これから学ぶのならば、なるべく長く役に立つ技術が良いと思うのですが、何がよいでしょうか。

「長く役に立つ」といったら、これまで長く使われてきた実績があり、これからもそう簡単に消えることはないであろう言語しかないだろうということで、「Common Lisp」か「Haskell」と回答しました。

書籍はそれぞれ『実践Common Lisp』と『すごいHaskell』を紹介。このへんは我田引水させてもらいました。

質問5

プログラミング初心者です。Webサイト作成のためにPHPの学習中ですが、他の言語にも興味があります。しかしなかなか難しいのもあって効率的なプログラミング学習法はないかと頭を悩ませているところです。そこで、おもしろそうと興味を持てば学習がはかどるのではと考えました。面白いプログラミング言語とその理由を教えてください。

面白いプログラミング言語といったら、とりあえずこれを押さえておけということで、「Brainfuck」です。 とはいえ、Brainfuckでプログラムを書くんじゃなく、好きな言語でBrainfuckを作ってみたらという提案をしました。 やっぱり、プログラミング言語ってこういうことなんだという実感を得るには、なんでもいいから作ってみるのがいちばんで、そのためにもBrainfuckの実装には一度は挑戦してみると楽しいと思います。

というわけで、お勧めした書籍は『Rubyで作る奇妙なプログラミング言語』。

質問6

インフラ運用エンジニアをしています。使える言語はシェルです。仕事ではたくさんのOSSを使用していますが、これらは書かれている言語がC,PHP,Python,Ruby,Node.js,Javaなど多岐にわたります。最近は自動化がブームですが、OSSを使って自動化をやっていくために、どのような言語を学ぶのがよいでしょうか。

OSSのツールを利用していくのに知っておいたほうがいい言語で、質問に出ていないものといって思いつくものは、「Go」しかありませんでした。 というわけで書籍としては『プログラミング言語Go』です。

いま思い返すとPerlとかLuaという選択肢もありえましたが、やっぱりあの場でお勧めする言語としてはGoしかありませんでした。 なぜなら、Goはラムダノートから近日中に新刊が出る予定だからです。 アスキーjpで連載していた「Goならわかるシステムプログラミング」の書籍化です! 昨日のLLイベントでも「低レイヤをかじることの重要性」は何度か強調されていて、そのたびにCやアセンブラというキーワードが出ててましたが、いまならそれこそGoで楽に学べます。 そういう趣旨で好評の連載に、著者の渋川さんが少し話を追加して、10月くらいに出せるように頑張って制作中。お楽しみに(宣伝)。

質問7(会場からの飛び入り質問)

小学三年生の息子がプログラミングをはじめるのに、Scratchのほかにどんな選択肢がありますか?

小学生にプログラミングを教えるときって、ビジュアル言語じゃない形でコンピュータの開発環境に触れる機会も必要だと思ってるんですよね。 かといって、汎用言語はそこそこ覚えないといけないことが多くてつらい。 そこで、覚えることが最小限で、コンピュータの生っぽいところを意識できる言語があればいいんですが、その条件を満たす言語はSchemeくらいしかありませんよね(異論は認める)。 というわけで「Scheme」をお勧めしました。

参考書籍はもちろん『計算機システムの構造と解釈』です(いまおもうと『Scheme手習い』という手もあった)。

2017/06/21

編集というサービスの内容(技術書編)

技術書の編集者が原稿に対して何を提供するものなのか、整理してみた。順番には意味があります。

  1. 原稿をDTP担当者が作業できるデータにする
  2. 誤字脱字、非標準的な表記を直す
  3. 表記を統一する
  4. 文法の間違い、不適切な言い回しを直す
  5. 構成の不備、内容の間違いを指摘する
  6. 構成の不備、内容の間違いを直す
  7. 冗長な内容、文脈から外れる記述を欄外に追い出したり、段落構成を手直ししたりする
  8. 段落や文を、文脈に合わせた相に書き直す
  9. 行間をうめる
  10. 解説画像やイラスト、索引などのメタ情報を作る
  11. 原稿を書く
  12. 【番外】企画する

どこまでやってほしいか、できるか、追加料金がいくら必要なのかというのを、著者・版元編集者・下請け編集者の間ではっきりさせると、みんなが幸せになる気がする。(だいたい編集外注するときって「編集作業一式」の「ページあたりの単価」になりがちで、しかしその「一式」には上記のような幅があるわけだから、人によって高いとか安いとか感じ方がいろいろ変わってしまうよね……。)

本として書店に並ぶまでに必要な作業は上記のほかにもいっぱいあり(装幀の企画と手配、権利、印刷製本、流通に関連するいろいろな仕事などなど)、上記に挙げた編集業務を担当編集者がぜんぶやるべきという話ではないはず。

たとえば、上記のうち5までは担当編集者が直接やるけど、残りは外部の査読者だったり編集者だったりを雇うことにするとか、あるいは、そこは著者の仕事であると最初から割り切る(ということを著者との間で同意しておく)ほうが、結果的に読者が手にする本にとって最善というケースもあるかもしれない。

なお、弊社では上記のすべてに対応した編集業務の受注が可能です。お気軽にご相談ください。

2016/12/30

2017年賀状

年賀状書いた。

%!PS
<< /PageSize [285 420] >> setpagedevice

/setrandcolor {% def
    /r1 {rand 5 mod 3 div} def
    /r2 {rand 4 mod 4 div} def
    /r3 {rand 3 mod 4 div} def
    r1 r2 r3 setrgbcolor
} def

/f {% def
    dup dup dup
    4 mod 0 eq {(2) 4 1 roll -1 0 rmoveto} if 
    4 mod 1 eq {(0) 3 1 roll -3 0 rmoveto} if 
    4 mod 2 eq {(1) 2 1 roll -3 0 rmoveto} if 
    4 mod 3 eq {(7 ) -5 0 rmoveto} if
} def

/i 4 def

/lineto-chars { % def
  /ex x def /ey y def
  /y exch def /x exch def
  /d x ex sub dup mul y ey sub dup mul add sqrt def
  /R y ey sub x ex sub atan def
  R rotate
  { d 0 le % ifelse
    { exit }
    { setrandcolor 
      /ra rand 5 mod 3 div 10 mul 22 add def
      /Georgia-Bold findfont
      [25 0 0 ra 0 0] makefont setfont
      i f show
      /i i 1 add def
      /d d 7 sub def }
  ifelse
  } loop
  0 R sub rotate
} def

1 1 20 { % for
  /n exch def

  newpath
  0 0 moveto
  135  45 moveto
   85 140
  110 165
  110 130 curveto
  0 0 moveto
  150 130 moveto
  155 190
  210 140
  130  40 curveto
  flattenpath
  {/y exch def /x exch def}{lineto-chars}{}{} pathforall
  gsave
  
  32 230 moveto
  0.9 0.1 0.2 setrgbcolor
  /Georgia-Bold findfont [90 0 0 100 0 0] makefont setfont
  (2017) show
  
  grestore
  showpage
} for

2017 by Keiichiro Shikano on Scribd

PSの解説でよく登場する、パスに沿った文字列描画の簡易版です。 まずflattenpathしてカレントパスをlinetoの配列に変換したあと、各linetoが描く直線がX軸になるまで回転→linetoの長さまで数字を順番に書く→回転を戻す、を繰り返しています。 どのへんが簡易版かというと、グリフを書き終わったポイントは当然ながらオリジナルのパスからはずれているのだけど、そこへ戻す処理をさぼっています。そのため、ベースになるパス(ハート型)よりも文字列の描く図形のほうが肥大していく、それもフォントや処理系によってずれ幅がけっこう違ってしまう、という緩い仕様です。 このコードはWindowsのDistillerに合わせてあります。 gsだと、なぜかずれがもう一回り大きい。

過去のやつ。

2016/12/24

JSONをTeXで組版する

昨今、ドキュメント技術の主戦場といったらウェブです(ワールドワイドなほう)。 ウェブ上ではさまざまな構造化テキストが飛び交っています。 まっさきに思いつくのは、HTMLをはじめとする、ブラウザがネイティブにレンダリングできる構造化テキストでしょう。

しかしブラウザにはJavaScriptという強力なプログラミング言語の実装が組み込まれているので、HTML以外の構造化テキストをサーバから取得して整形する場合も少なくありません。 そのようなデータ形式のひとつにJSONがあります。

最近のWebサービスでは、サーバからHTMLを送らずにJSONデータだけを送り、ブラウザがそれをJavaScriptで解析して画面表示をすべて動的に作っている場合もあるようです。 この場合にブラウザがやっていることは、ある種の自動組版だといえるでしょう。 そもそもブラウザによるHTMLのレンダリング自体が自動組版だという見方もできますが、それよりさらに抽象化した、JSONを原稿とする自動組版という考え方です。 必ずしもページ全体をJSONから表示していなくても、たとえばJSONデータから表を生成してdiv要素に差し込むといった局所的な組版もありえると思います。

ブラウザとJavaScriptでできることがTeXでできないはずがない

というわけで、TeXでJSON組版をしてみました。 題材としては、CTANの各パッケージのJSONクエリとかも考えたのですが、残念ながらCTANではパッケージの詳細説明の項目にプレーンテキストではなくHTMLが直書きされている場合があるようです。 TeXで扱うのにHTMLタグは邪魔でしかありません。 まさかCTANともあろうものが、TeXでJSONデータを利用することを考えていなかったなんて。

それに、どうせならもっとクリスマスらしい題材にしたいところです。 クリスマスといえばホワイトクリスマス、ホワイトクリスマスといえば雪だるま。雪だるまを組版するなら天気予報でしょう。 OpenWeatherMapという会社のサイトで天気予報をはじめとする気象データをJSONにより取得できるので、これを組版していきましょう。

天気予報JSONデータの取得

まずはデータの取得です。TeXからHTTPリクエストを発行する汎用の手法はないので、cURLでもwgetでも好きなものを使ってください。 OpenWeatherMapでサインアップしてAPPIDを手に入れれば、たとえば下記のようなURLによって、東京の5日後までの3時間おき予報データが取得できます。

http://api.openweathermap.org/data/2.5/forecast?q=Tokyo,jp&APPID=0000000000000
参考までに、取得できるのはこんな形のJSONデータです。
{"city":{
  "id":1850147,
  "name":"Tokyo",
  "coord":{"lon":139.691711,"lat":35.689499},
  "country":"JP",
  "population":0,
  "sys":{"population":0}},
 "cod":"200",
 "message":0.0103,
 "cnt":37,
 "list":[
    {"dt":1482483600,
     "main":
       {"temp":9.94,
        "temp_min":8.84,
        "temp_max":9.94,
        "pressure":1015.88,
        "sea_level":1017.11,
        "grnd_level":1015.88,
        "humidity":71,"temp_kf":1.1},
     "weather":[
       {"id":802,
        "main":"Clouds",
        "description":"scattered clouds",
        "icon":"03n"}],
     "clouds":{"all":36},
     "wind":{"speed":6.71,"deg":318.003},
     "rain":{},
     "sys":{"pod":"n"},
     "dt_txt":"2016-12-23 09:00:00"},
     ...

JSONデータのTeXによるパーズ

JSONデータを取得できたら、パーズします。JSONを読むパッケージが見当たらなかったので、ざっくり再帰下降パーザを書きました。TeXは関数型言語なので、素直に書けますね。

公開APIは以下の3つ。

\readJson #1 #2
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータが格納される
\readJsonValueById #1 #2 #3
第一引数に渡したコントロールシーケンスに、第二引数に渡したJSONデータの、第三引数の名前に対応する値が格納される
\showJsonValueById #1 #2
第一引数に渡したJSONデータの、第二引数の名前に対応する値が入力に残る

ちょっと例を見てみましょう。青字になっているのがJSONデータです。

\documentclass{article}
\usepackage{jsonlite}

\begin{document}

\readJson{\json}{{"id":[1,2,3], "class":"foo", "data":{"id":"456"}, "info":"Is this a text?"}}
\readJsonValueById{\jsonId}{\json}{"id"}     %=> expl3 sequence
\readJsonValueById{\jsonData}{\json}{"data"} %=> id:456

\readJson{\jsonJsonData}{{\jsonData}}
\showJsonValueById{\jsonJsonData}{"id"}      %=> 456

\end{document}

天気予報JSONデータを表組する

OpenWeatherMap社から提供される天気予報JSONデータから、都市名、予報の時刻、予想天気、予想気温を取ってきて、LaTeXの表として組みましょう。 各時刻の予報は、"list"という名前の配列の各要素になっているようです。 この配列に対するmapで、表の各行を整形するという戦略にします。 実はjsonliteパッケージではJSONの配列をexpl3のシーケンスとして保持するので、シーケンス用のmapが使えます。

\NewDocumentCommand{\showForecast}{ m }{%
  \begin{longtable}{ l | c | r}
    日時 & 空模様 & 気温 \\\hline
    \endfirsthead
    日時 & 空模様 & 気温 \\\hline
    \endhead
    \seq_map_function:cN #1 \format_forecast:n
  \end{longtable}
}

TeX言語のくせにシーケンスとかmapとか、お前はなにを言ってるのだ、という感じかもしれませんが、2016年にもなればそういうものなんです。 そもそもTeXは関数型言語なのだからシーケンスに対するmapくらいできないはずがありません。

あとは、\format_forecast:nを書いていくだけなんですが、 OpenWeatherMap社のデータで"weather"がさらに配列になっていたりして無駄にめんどくさいので解説は省略します。 jsonliteパッケージと同じディレクトリに完全なコードを置いてあるので参考にしてください。

天気記号のサポート数がそこそこあるDejaVuSansを使いたかったので、XeLaTeXで実行してみた結果がこれです。DejaVuSansの☃はどことなく品がいいですね。

ところで、Brzozie(ブジョジェ)という地名がどこなのか気になった人がいるかもしれません。ブジョジェはポーランドの湖水地方で、バホテク湖があるところです。来年のTUG2017は、このバホテク湖で毎年開催されているBachoTeXというイベントと合同で5月に開催されることになっています。なんとか参加するぞ。

そしてこの記事は、第五回となるTeX&LaTeXアドベントカレンダーの24日めの記事です。 昨日はアセトアミノフェンさん(この記事を見てDejaVuSansを使うことを思いつきました)、明日の最終日はZRさんです。

2016/12/03

独立系出版社をやるという覚悟について

カナダ最大の都市であるトロントから北に向かって1時間ちょっと、荒野だか畑だか牧場だかよくわからない広大な土地を走り抜けたところに、エリンという小さな村があります。 19世紀に開拓された当時からメインストリートであったと思われる道が、川の蛇行している部分を堰き止めるように貫いていて、その両脇だけで主な商圏が形成されているような素朴な村です。

そんな小さな村に、なんと出版社があります。 その名もThe Porcupine’s Quill。 直訳すると「ヤマアラシの針」ですね。 言うまでもなく独立系の出版社で、大手からは陽の目を見るのが難しいカナダ発の文学者やアーティストの作品を手掛けているようです。

今年の7月、この《ヤマアラシの針出版》を訪問する機会がありました。 世界中のTeX関係者が集まるTUGという会合があるんですが、2016年の開催地がトロントで、その一環として《ヤマアラシの針出版》の見学会が組まれていたのです。 トロントからエリン村まで農道(もしくは牧道)を延々とかっ飛ばし、パン屋さんの前でマイクロバスを降りると、その何軒か隣の靴屋みたいな建物が《ヤマアラシの針出版》の本社でした。

SDIM0346

こんなカナダのど田舎に本社を構えているというだけで十分に話として面白いんですが、この出版社、他の多くの出版社と違って、印刷から製本まで本づくりのすべてを自前でやっています。 それも、ドイツ製のオフセット印刷機やら製本機やらを社内に一式すべて用意し、経営者であるティムさんと奥さんのエルクさんが手作業で本を作っているのです。 ちなみに、やや出来過ぎ感がありますが、お二人の姓は「インクスター」さんといいます。

これが、さっきの建物の地下にあるHeidelberg Kordというオフセット印刷機。とてもよく手入れされていて、油でてかてかしています。インクが香ばしい。

SDIM0336

こちらは建物の1階に実装されている、本をかがるための機械。ファンシーな窓の鎧戸と陽光のせいで博物館の展示物っぽいけど、むちゃくちゃ軽快に稼働します。

SDIM0333

正直なところ、訪問前にはそれほど大きな期待はしていませんでした。 自分とは畑違いの文芸系の出版社っぽいし、そもそも出版社の仕事なんてどこも大差ありません。

しかし実際に《ヤマアラシの針出版》でティムさんから「どういう考えで本を企画し、作り、それを売ってきたか」を語ってもらい、ビンテージな機械が力学を駆使して本を作り上げるようすを目の当たりにすると、いちいち唸りっぱなしでした。 出版社っていうのは、こんなふうに本を作って売るっていう仕事であり、その骨格がまさにいま自分の目の前に展開されてるんだなと。

  • 出版社の仕事なんて、確かにどこも大差ないけれど、誠実にやっていくと結局は「モノづくり」になるんだよなという気持ち。
  • 電子書籍もいいけど、モノとしての物理は単純に強いなという気持ち。
  • 年間ノルマで本の形を整えなくても、こんなふうに、やりたい人がやりたいように出版をやれるのが健全だよなという気持ち。
  • ぼくも、完全に同じやり方ではないかもだけど、こんなふうにして本にかかわっていくぞという気持ち。

なにをかくそう、ぼくも自分で出版をやりたいと思って、昨年2015年の12月1日にラムダノート株式会社という会社を作りました。 今年2016年の7月にThe Porcupine’s Quillを訪問して、自分が仕事としてやりたいことは「本を作って買ってもらうこと」なんだなと再確認しました。 来年2017年の2月ころには、最初のタイトルとして、TLSの関連書を発行する予定です。 年が明けてしばらくしたら直販サイトで予約できるようにする予定(予定)なので、ご期待ください。

そういえば、この最初のタイトルは翻訳ものなんですが、原書を発行しているロンドンの出版社もやっぱり独立系出版社でした。 そっちもそっちで4月に訪問してたくさん刺激を受けたので、翻訳発行後にあらためてどこかで話ができればいいなと思います。

なお、この記事はラムダノート株式会社の設立にあたって出資して頂いた株式会社時雨堂の社長になんか書けといわれ、pyspaアドベントカレンダー2016のエントリーとして書きました。pyspaには脱サラする直前からずっと癒されてきました。でも、昨日はイアンさん、明日はモリヨシさんだし、あきらかに場違いな記事だろこれ。