進化の先に理想のエンジニア組織がある─成長のジレンマを解消して進化するフューチャーの組織論 エンジニア組織が成長する際に直面するさまざまなジレンマを解消するうち、ホラクラシー型に進化したというフューチャー株式会社のエンジニア組織論を、宮原洋祐さんに聞きました。 ジレンマを解消しながら進化する組織 専門家とオーナーシップのトレードオフ 組織をリファクタリングしてホラクラシーに近く 組織の形が変わることでエンジニア個人も変わる チーム間の移動を容易にすることで成長を促す 進化の先にある理想のエンジニア組織 インターネットがビジネスに普及する以前から30年にわたり、日本を代表するさまざまな企業に向けたITコンサルティングを通して、企業経営の戦略システム開発を手掛けてきたITの専門家集団、フューチャー株式会社。 企業のパートナーとしてのIT構築を専門としていることから、エンドユーザーの目に触れる機

Ruby 2.7のここがすごい！ パターンマッチ、コンパクションGCなどをリリースマネージャーに聞いた 2019年12月25日にリリースされたばかりのRuby 2.7では、どのような機能がどういった経緯で採用されているのでしょう。リリースマネージャーのnaruseさんと、フルタイムコミッターのmameさんに詳しくうかがいました。 まつもとさんはとにかく忙しくて 実はすごいirbの改良 パターンマッチはRubyをどう変えるか キーワード引数は、端的に壊れていたのを大整理した 高速化に向けたいくつかの観点 Ruby 2.7で導入される「コンパクションGC」とは Ruby 3のビジョンは「静的解析」「並行並列」「JIT」 プログラミング言語Rubyには、クリスマス前後に新しいバージョンをリリースする伝統があり、2013年の2.1.0以降は毎年12月25日にメジャーバージョンアップが行われています

この記事はTeX & LaTeX Advent Calendar 2019の24日目の記事です。23日めはwtsnさんの記事でした。25日めは☃さんの記事です。 TeXの脚注は出力されない場合がありますね TeXはなぜ脚注を期待どおりに扱えないのだろう 脚注をMVL上で可視にすればよい ページ分割する箱にも脚注を入れたい yafootnoteの実装について（読まなくてもよい） まとめ 今年は3年ぶりにTUGに参加してきました。 TUGというのはTeX User Groupのことであり、TeX界隈の開発者とアドバンストな利用者からなる世界的なコミュニティです。 年に1回、地球のどこかで集まっていて、それもまたTUGと呼ばれています。 2013年には東京でも開かれました。 なお、今年はKnuthも参加しています。前回の参加は10年くらい前のことで、そのときはiTeXというネタ発表をしたことでも

昨日までの話をふりかえってみます。 構造化文書というと、どうしてもXMLタグの書式で構造を示すあの世界観が想起されやすい しかし、書式はあくまでも記法にすぎないと思うことにして、構造のほうだけ抽象データ型でかっちり用意するという世界観もありうる。これはPandocやDocutilsでいちおう成功を見ている このアドベントカレンダーでは、後者の世界観を「ライトウェイト構造化文書」と呼んでみました。 特にPandocの成功については、代数的データ型、パーサコンビネータ、パターンマッチを兼ね備えたHaskellに依拠する部分が大きかったのではないかなと個人的には思っています。 今日は、そんなHaskellでEPUBを作ろう、という話です。 PandocにはEPUB Writerもありますが、痒い所に手が届く感じではなかったので、自分で生成器を作ることにしました。 HaskellでXMLを扱う E

昨日の記事では「書籍のマクロな構造」について話しました。 このマクロ構造はPandoc構造には組み込まれていません。 そのため、Pandocで書籍を作ろうと思うと、どうしたってPandoc構造にない部分を扱う別の仕組みが必要になります。 素のPandocでは、「書籍のマクロな構造を扱える外部の仕組み」を託す先として、主にLaTeXを利用しています。 裏を返すと、LaTeXは、書籍のマクロな構造を扱える仕組みです。 それなら最初からPandocではなく、LaTeXで本を作ればいいのではないでしょうか？ この反論はもっともです。 実際、本を作るプロは黙ってLaTeXであったり、あるいはInDesignであったり、あるいはFrameMakerであったりを使います。 組版のプロの要求を実現するためには、これらのツールが持つ表現への自由度が必要だからです。 しかし原稿をもらう立場からすると、この高い

昨日まで何回かにわたり、多様なドキュメント形式の変換アプリケーションであるPandocのコアとなる仕組みを説明してきました。 特に、Pandoc構造とそれを生成するReader、生成されたPandoc構造を変換するPandocフィルターについて、少し時間をかけて紹介しました。 では、PandocのReaderとフィルターについて理解したところで、Pandocを使って本は作れるでしょうか？ いままでの説明には登場しませんでしたが、Pandocの出力側を担うWriterには、「PDF生成のためのLaTeX Writer」や「EPUB Writer」など、「本」を作るのに使えそうなものがあります。 それらWriterを制御するためのコマンドラインオプションはいろいろ用意されており、独自のテンプレートを指定することも可能です。 ただ正直なところ、これらのWriterは、吊るしの状態では売り物の本を

昨日までの記事では、Pandocフィルターの基本と少しだけ実用味がありそうな例を紹介しました。 Pandocフィルターは、Pandoc本体の開発言語と同じくHaskellで書けますが、Pandocの内部動作を変えられるわけではなく、pandocコマンドによってJSONとして出力したデータを操作する仕組みです。 内部に組み込まれたLua処理系で実行できる新しいフィルターの仕組みもありますが、いずれにしてもpandocというコマンドに対する補助的な機構です。 一方で、Haskellというプログラミング言語から見ると、Pandocはライブラリでもあります。 つまりpandocコマンドとしてでなく、自分が書くHaskellのプログラムで読み込んでそのMarkdownのパーサだけを使う、といったことも可能です。 今日はそのような事例を紹介します。 XML原稿にあるMarkdownの島 先週、このアド

Python界隈でよく見かける構造化文書のための記法として、reStructuredText（以降はreSTと書きます）があります。 reStructuredText https://docutils.sourceforge.io/rst.html 軽量マークアップ言語などと呼ばれることもありますが、reSTはかなり高度な表現力がある記法です。 その記法をパースするために標準で使われているのはDocutilsという仕組みです。ただ、DocutilsはreST専用ではなく、他の記法のパーサを実装することもできるらしいです。 その意味でDocutilsは、Pandocと同じく、内部の抽象的なデータ構造へと記法を押し込めるツールだといえる気がします。 Docutilsについては『マスタリングDocutils』に詳しいので興味がある方は購入しましょう。 『マスタリングDocutils』 マスタリン

このアドベントカレンダーでは、先週まで、主にページメディアにおける「PDF」と「XML」の話をしてきました。 この2つ、それぞれ「Webブラウザでのレンダリング」と「HTML」に言い換えると、ウェブメディアの世界観と似ている気がしてこないでしょうか。 実際のところ、ウェブメディアとページメディアって互いに遠い存在ではなく、「平面に文字などを配置することを目的とした構造化文書」という視点に立てば、むしろ兄弟みたいなものです。 「Webブラウザへの表示がHTMLだけで済むわけないだろ、CSSやJavaScriptの役割を知らないのか」という指摘が聞こえてきそうですが、ページメディアにもそれらに相当するものは存在します。 というか、いろいろありすぎて、もはや収拾がついていません。 ページメディアでわりと標準っぽいのは、CSSの役割がXSL-FO、JavaScriptの役割がXSLTという、いわゆ

この記事は「書き手と編み手の Advent Calendar 2019」に参加しています。 adventar.org とある中堅出版社で10数年にわたり、2カ国語辞典（具体的には英和辞典と和英辞典）の編集という仕事をしてきました。「出版社」「編集」と一口に言っても、扱うジャンルはさまざまで、業務内容も実は会社によってかなり違っていたりします。とりわけ、辞書という出版物は限られた版元しか扱っていないので、あまり汎用性のある話はできないのですが、思うところあり、このあたりで少しまとめておきたいと思います。 三浦しをんさんの小説『舟を編む』は、映画化もされ今は文庫でも出ているのでご存じの方も多いと思いますが、国語辞書を刊行している老舗出版社の社員編集者を主人公とする作品です。これによって世間での辞書編集者のイメージが形作られた部分は少なからずあると思いますが、あれを読んで自分の仕事と違うと感じた

昨日は、ドキュメントの構造をプログラムのように実行できるというアイデアの話をしました。 具体的には、「ドキュメントの構造をS式で表現し（SXML）、そのタグをLispの関数と見立て、それを要素に関数適用する」というアプローチです。 たとえば、XMLで表したときに段落を意味する<para>のようなタグに対する変換処理は、こんな感じのLispの関数として定義できます。 (define (para arg) (print arg "\n\n")) 今日は、これをもうちょっと真面目に定義する部分と、これを評価する部分、それに実用的に使うためのフレームワークについて書きます。 以降、Lispの処理系としては、GaucheというSchemeの実装を使います。 Gauche https://practical-scheme.net/gauche/index-j.html ドキュメントをS式で書くの？ ま

今日まで延々と「PDFからテキストデータを取り出すのは大変」という話を続けてきましたが、その構造を見るにあたっては、 hpdft という自作のツールを使ってきました。 大変とはいっても、まあ実現困難な話ではなく、この程度のPDFパーザであれば趣味プログラミングで自作できる範囲です。 しかし、べつにわざわざ自作しなくても、「PDFからテキストデータを取り出す」ためのツールなら世の中にはすでにいくつもあります。 特に有名で昔からよく使われているのは、Xpdf由来のpdftotextでしょう。 pdftotext http://www.xpdfreader.com/ XpdfからはPopplerが分派しているので、Poppler版のpdftotextもあります。 また、pdfminerというツールもあります。 pdfminer https://www.unixuser.org/~euske/py

昨日までで、PDFからテキストを取り出すにあたり、グリフから文字を手に入れるところまでを説明しました。 いや本当のことを言うと、まだ全然説明できてないんです。 でも、文字の話ばかりしていても先に進めないので、今日は（可能な場合には）PDFから文字を入手できるものとし、そこからテキストを再構築する話に進みます。 文字については改めて明後日にでも補足記事を書くかも（このシリーズはいちおう今日と明日で終わる予定）。 PDFオペレータを読むとグリフを置く場所がわかる 昨日に引き続き、次のようなテキストセクションで考えます。 グリフから文字の解決は済んでいるということにして、TJオペレータの引数は文字そのものに置き換えました。 BT /F1 12.4811 Tf 125.585 -462.55 Td [(#1)] TJ /F2 13.2657 Tf 19.932 0 Td [(代数的データ型とパター

PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵（「グリフ」）をコンピューターで扱えるような「文字」にする方法です。 これには2つのアプローチが考えられます。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る PDFファイルの中身を解析してテキストを抜き出す このうち2つめの話は明日以降にして、今日は1つめの話をします。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法 この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を「視覚的に読む」ということです。 これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ（文字の形）をページ上に表示するための汎用の仕組

「Markdown+CSS/TeXで冊子本を作ってみた」に参加してみた connpass.com 2019/11/16 訂正 訂正いただきました箇所、打ち消し線と + 記号で大体わかるように、なっているといいな、しました。 開始前 記事中のAmazonのリンクはアフィリエイトにしていますので嫌悪感を抱かれる方は気をつけてください。 アンテナハウス株式会社*1様主催のセミナーに参加してきました。以前『PDFインフラストラクチャ構造解説』のPOD（Print On Demand）本を買ったときに存在を知り、ウェブサイトの「XMLに命をかけてくれ」というエピソード紹介が印象に残っていました。大規模、構造的ドキュメント用のソフトウェアに強みのある会社という理解です。 PDFインフラストラクチャ解説: 電子の紙PDFとその周辺技術を語り尽す 作者: 小林徳滋出版社/メーカー: アンテナハウスCAS電

いつもご来店ありがとうございます。計算機好きのための技術解説情報誌『n月刊ラムダノート』のNo.3ができました。 季節の深まりを思わせる濃い紫のNo.3は「パターンマッチ」のミニ特集です。 代数的データ型とパターンマッチの基礎（κeen 著） パターンマッチin Ruby（辻本和樹 著） No.1やNo.2に比べて記事数は1本減ですが、ページ数では1.5倍の120ページ、価格は同じ1500円（PDFのみは1000円）です。 「パターンマッチって要するに条件分岐の一種でしょ？」、「動的型付きの言語にパターンマッチなんて入れて何のメリットが？」、「後付けで制御構造を入れるのってマクロがあるLispならともかくRubyだとどこまで現実的なの？」などなど、パターンマッチと聞いて思わず反応してしまうすべてのプログラミング言語好きの方にお勧めします。 どこで買えるの？ 『n月刊ラムダノート』のお求めは

「うちの学校でもついにプログラミングの授業が始まったよ」 「それは興味深いね。どんなふうに教えてるの？ やっぱりScratchとか？」 「Scratch？ ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ」 「え？」 「小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ？」 「あるかないかでいったら、あるよ」 「プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ」 「プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…」

『n月刊ラムダノート』の話をいろいろしたいのだけど、どこから話せばいいのかわからないので、Lispの話をします。 昔、といってもほんの10年ちょっと前のことですが、日本でLispが流行った時期がありました。 「プログラミング言語のパワーには絶対的な差が存在する。その頂点に立つのがLispだ」と言って憚らない『ハッカーと画家』という本が2005年に出版され、それを読んだ多くの人が「よろしい、ならばLispだ」と思ったのです。 まあ、ほかにもいろいろな理由があったのだろうし、流行に関係なくLispを使い続けている人はたくさんいたし、いまでもぼくを含め多くの人がLispを日常的に使っているけれど、『ハッカーと画家』の影響によるちょっとしたLispブーム、というのは確かに起きていたと思います。 で、この『ハッカーと画家』を翻訳したのが川合史朗さんでした。 その当時、ぼくは同書を企画した部署にたまた

おそらく先がない5つのプログラミング言語、といういろいろと怒りをかいそうな記事だが、どうせワタシが愛する C 言語なんかがまたやり玉に挙がってるんだろうと見たら、一番最初に Ruby が挙がっている…… この記事は TIOBE や RedMonk のプログラミング言語ランキングに Dice 独自の求人票情報を加味してるようだが、Ruby は落ち目という認識らしい。うーむ。 それ以外には Haskell、Objective-C、R、そして Perl が挙げられていて、この手の記事の定番といえる Perl、Swift 誕生後やはり定番である Objective-C はそうですかという感じだが、ビッグデータの時代に人気を高めた R 言語ですら、Python に追いやられつつあるというのはそうなんでしょうね。 それにしても Ruby が先がないという意見には異論が出るだろう。ネタ元は Slashd