サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
golden-lucky.hatenablog.com
近年、出版社でも原稿管理にGitの導入が進んでおり[要出典]、GitHubのようなWebサービスへの需要が高まっている[要出典]。 これに伴い、WebブラウザでGitHub上の原稿に対する特定のコミットを開き、そこに行コメントを残すといった利用も増えている[要出典]。 以下に例を挙げる。 この「特定のコミットに対して行コメントを残す」機能は、ワープロソフトの編集履歴ツールと同じ感覚で原稿に局所的なツッコミを入れられるという点で大変に使い勝手が良い。 しかし難点が一つあって、GitHubのWebページではこのコメントを一覧で表示できない。 そのため、コメントに気付かずスルーしてしまうという、文書の編集において最悪の事態を招くことがある。 ただ、一覧表示する術がまったくないかというとそういうわけでもなく、GitHubが公開しているREST API v3経由で取得できる。 Comments |
昨日までの話を整理します。 ドキュメントのXMLによる表現は、プログラムの抽象構文木に相当し、ドキュメントの意味構造を示したものであった なので、XMLの構文をS式で表せた すると、XMLの要素名がLispにおける関数、要素がその関数への引数に見えた そこで、要素を材料としてシリアライズした文字列を返すように、要素名で関数を定義した。その際、要素の中には別の要素名を持つ要素が入れ子になっていることがあるので、それらは再帰的に処理するように定義した。 こうして、ドキュメントのXMLをLispの評価器で直接実行できた そして、そのためのフレームワークとして、xml2texという自作のアプリケーションを紹介しました。 XMLからTeXを生成する専用機に見える名前が付いているけど、これは命名を失敗したと思っていて、xml2texは、いわば、XMLをつぶす機械を作る機械です。 XMLをつぶして好きな
昨日は、ドキュメントの構造をプログラムのように実行できるというアイデアの話をしました。 具体的には、「ドキュメントの構造を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式で書くの? ま
昨日は、ドキュメントとは木であり、その木はXML、さらにいうとXMLアプリケーションとして形作られる、という話をしました。 一般にドキュメントは、生のままの構造として読み手に与えられるものではありません。 ドキュメントの構造が何らかのXMLアプリケーションであれば、本来はそのスキーマに従って解釈し、しかるべきスタイルを適用することになります。 ここで、しばしば厄介になるのは、XMLアプリケーションのスキーマを正しく扱うのはなかなか大変だということです。 そもそも、プロプラなXMLアプリケーションだと、スキーマの定義が手に入らない場合もあります。 そういった「野良XMLをどうやって扱うか」が今日からの話題です。 でもその前に、昨日の記事の最後で紹介したSXMLについて雑に補足しておきます。 XMLをSXMLに引き写すことで見える景色 さて、昨日はSXMLという技術を紹介しました。 SXMLの
よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言及される「構造とスタイルの分離」における「構造」です。 昨日までの話ではPDFにもドキュメント構造というのが出てきました。あれは、この「構造とスタイルの分離」というときの「構造」とは別物なので注意してください。 たぶん、PDFのドキュメント構造には、「ドキュメントを表すデータ構造」くらいの意味合いくらいしかありません。 一方、ドキュメントの話において「構造とスタイルの分離」というときの「構造」は、もうちょっとこうなんていうか、セマンティックな話です。 データをどう構成するかではなく、ドキュメントで表したい意味をどう構成するか、という話。 し
今日まで延々と「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ごとにカスタムなテキスト取り出し」の話をするつもりだったのですが、その前に文字とコンテンツストリームについて落穂拾いをしておくことにしました。 というのは、昨日までの記事への反応を見ていて、この本のことをちょっと思い出したからです。 John Whitington 著、村上雅章 訳 『PDF構造解説』(オライリー・ジャパン、2012年5月) この本、PDFのドキュメント構造を知りたい人が最初に読むにはぴったりだと思います。 自分で簡単なPDFを手書きしながら「PDFの中身がどうなっているのか」を学べるように書かれているので、ドキュメント構造やコンテンツストリームの雰囲気を手軽に体験できる良書です。 しかし、この「自分で簡単な
昨日までで、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のページに表示されるコンテンツはPDFのドキュメント構造を掘っていくと手に入れることができて、それはこんな姿をしているぞ、というところまで話が進みました。 $ hpdft -r 66 NML-book.pdf [ /Filter: /FlateDecode /Length: 381.0, q .913 0 0 .913 0 595.276 cm q 462.33906 0 0 655.95015 -3.064 -652.208 cm /Im24 Do Q 1 G 1 g BT /F1 12.4811 Tf 125.585 -462.55 Td[(#1)]TJ /F2 13.2657 Tf 19.932 0 Td[<0b450a3a0c2403c3029403bb0715037103cd03bb029403ef03da03bf03bd0377062c0ac5>] TJ
昨日は、PDFの本来の用途は「人間がPDFをビューワーで開いて読む」ことなので、そこから文字を抜き出すのは一筋縄ではいかない、という話をしました。 ではどうすればPDFファイルの中からテキストを取り出せるの、というのが今日の話の出発点です。 まず昨日の記事で、「PDFには国際的な規格があり、これはAdobeから『PDFリファレンスマニュアル』という形で無償で入手できる」という話をしたことを思い出してください。 昨日は話のついでみたいな感じで書きましたが、実を言うと、このリファレンスの中に、「PDFファイルの中に書き込まれているグリフを表示するための情報からUnicodeなテキストを取り出す手法」がちゃんと書いてあるのです。 具体的には、『PDFリファレンスマニュアル第6版』の §5.9 "Extraction of Text Content"に、その情報が一応整理されています。 ただし、言
PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵(「グリフ」)をコンピューターで扱えるような「文字」にする方法です。 これには2つのアプローチが考えられます。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る PDFファイルの中身を解析してテキストを抜き出す このうち2つめの話は明日以降にして、今日は1つめの話をします。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法 この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を「視覚的に読む」ということです。 これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ(文字の形)をページ上に表示するための汎用の仕組
「うちの学校でもついにプログラミングの授業が始まったよ」 「それは興味深いね。どんなふうに教えてるの? やっぱりScratchとか?」 「Scratch? ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ」 「え?」 「小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ?」 「あるかないかでいったら、あるよ」 「プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ」 「プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…」
日本語圏におけるHaskellの解説本には、これまで4回の波がありました。 それを思い出しながら、最後に『プログラミングHaskell 第2版』の紹介をします。 第1波 第2波 第3波 第4波 『プログラミングHaskell』が改訂されます 第2版ではプログラミングにおける型の理解が深まると思う ここで買えます 第1波 Haskell解説本の1つめの波は、2006年、『入門Haskell』と『ふつうのHaskell』が出版された頃にありました。 このうち、『入門Haskell』は(おそらく)日本初のHaskell本です。 『入門Haskell』(2006年) 『ふつうのHaskell』(2006年) 『ふつうのHaskell』は、書名だけを見ると「特殊な言語」であるHaskellを「ふつう」に説明している本であるように思えるのですが、実はそうでもなくて、淡々と部品の説明をしていく感じの内容
『n月刊ラムダノート』の話をいろいろしたいのだけど、どこから話せばいいのかわからないので、Lispの話をします。 昔、といってもほんの10年ちょっと前のことですが、日本でLispが流行った時期がありました。 「プログラミング言語のパワーには絶対的な差が存在する。その頂点に立つのがLispだ」と言って憚らない『ハッカーと画家』という本が2005年に出版され、それを読んだ多くの人が「よろしい、ならばLispだ」と思ったのです。 まあ、ほかにもいろいろな理由があったのだろうし、流行に関係なくLispを使い続けている人はたくさんいたし、いまでもぼくを含め多くの人がLispを日常的に使っているけれど、『ハッカーと画家』の影響によるちょっとしたLispブーム、というのは確かに起きていたと思います。 で、この『ハッカーと画家』を翻訳したのが川合史朗さんでした。 その当時、ぼくは同書を企画した部署にたまた
ここでいう「技術書」というのは、「IT系の技術周辺を扱った本」のこと。この意味における「技術書」の界隈では、近年、「技術書典」という同人誌即売イベントが年二回のペースで開催されている。これは文字通りの祭「典」で、わずか6時間という短い開場時間に、数百人からなる同人誌の書き手とその作品を貴ぶ1万人の買い手が集結する。 IT系の技術ではソフトウェアが占める役割が大きく、ソフトウェアというのは技術的な変化が激しい。そのため、技術に関する情報を伝える手段にも、俊敏性とか即応性が求められる。紙の書籍というのは、一般にはそういう性能が低い、リジッドなパッケージである。それなのに紙の同人誌が技術情報の手段として尊ばれるのは、一見すると不思議な現象ではる。技術情報のアウトプットが目的であれば、自分ではてなブログに書いたり、Qiitaに書いたりでいいのでは? にもかかわらず同人誌の書き手と読み手が尽きないと
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
TeXのフォントまわりについては、以下の3点が意識して語られるといいなと思う。 TeXのフォント環境の理解は難しい。なぜなら、フォントに関する深い知見はもちろん、今となっては古臭いTeXのディレクトリに関する知識も必要だから 今となってはどうしようもない古臭い設計を、TeX Liveが現代的なインターフェースでラップしてくれているので、ぼくらは古臭いTeXの知識がなくても日本語PDFが作れる 古臭い設計を捨て、現代的なOSのフォント環境で動かすことを前提に開発されている新しいTeXもある(LuaTeXやXeTeX) 1については、特効薬がない。TeX Wikiに書いてある部分もあるけど、たとえばTEXMFLOCALが何かとかを知るには、まずKpathseaについて知る必要がある。つまり、texdoc Kpathsea とかする。Webブラウザで見るなら Kpathsea: A librar
はじめに みなさん、EPSファイル、使ってますか? 近年、(La)TeXの文書作成においては、「EPSファイルを使うな」というマナーが確立しています。 マナーにはデフォルトで抗っていくということで、この記事では、現代的なLaTeX環境におけるEPSファイルの可能性を探りたいと思います。 もちろん、「EPSファイルを使うな」は、実際にはマナーではありません。 技術的な根拠があるベストプラクティスのひとつです。 したがって、この記事の真の目的は、以下の2点だといえます。 ベストプラクティスをマナーへと貶めないために技術的な背景を知る 条件があえばEPSファイルにもまだまだ使い道があることを示す コンピュータサイエンスには、"All problems in computer science can be solved by another level of indirection"(「コンピュー
ラムダノートという出版社を作って3年が経ちました。 www.lambdanote.com この12月から、会社としては第4期に突入です。 3年もすれば中学生は高校生になるわけで、それなりに感慨があります。 そこで、pyspaアドベントカレンダーという場を借りて、ちょっとふりかえりをしてみることにしました。 本の紹介はよくやるけど、会社の紹介はあまり積極的にやってないので、そのつもりで書いたものです。 第1期(2015年12月-2016年11月) 出版社なので本を作って売りたいわけですが、本は自然には生えてきません。 前の会社に在職中から独立に向けた準備を進めるような計画性があればよかったのですが、本当になにも準備しないまま音楽性の違いで辞めたので、起業した最初の年は当然ながらラインナップがゼロでした。 そんな状態でも起業に踏み切れたのは、時雨堂の@volantusが凄腕の会計事務所を紹介し
「そういえば前職でこの話を業務ブログに書いてたな」と思った話があって、検索したところ、ひっかからない。トップページからリンクをたどっても見当たらない。いやな予感がしてもうちょっと調べたら、過去の記事がぜんぶ、しれっとなかったことになっていた! 幸い、Internet Archivesではまだ残っていたので、自分が書いた文章のうちあとで参照したくなるやつを拾っておいた。『すごいHaskell』のサイン会の写真とか、たぶん日本のコンピュータサイエンス史にとって貴重なはず。 2015年6月23日 Kent Beck+角征典『エクストリームプログラミング 』完全新訳、6月26日発売 2015年2月26日『基礎からわかるTCP/IP ネットワークコンピューティング入門 第3版』、今日発売! 2015年2月23日『新装版リファクタリング ―既存のコードを安全に改善する―』のここがすごい (「ITエンジ
本記事は、ラムダノートで発売している『RubyでつくるRuby』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。また、この本は当社の本のなかでも過小評価されているところがあると思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。 本書『RubyでつくるRuby』を買った人にも、まだ買っていない人にも、とにかくまず意識してほしいのですが、この本はRubyの解説書ではありません。 じゃあなんの本かっていうと、これは「そもそもプログラミング言語でプログラムを書くって、なに?」という根本的な問いへの取り組み方を教えてくれる本です。 もう一度言いますが、この本はRubyの解説書ではありません。なので、「Rubyを使うつもりはなくて、PythonとかJavaScriptが好き」っていう人や、「それらのプログラミング言語をいままさに
マッハ新書、β版で電子版を先行発売して紙を売り出すという、ここ10年来の英語圏における一部技術書の動向が、日本語圏では技術書界に先立って新書という形で、トップダウンかつボトムアップに再発明されたものという感じがする(ポジティブな感想です)。 ここで、トップダウン的というのは、著者からという意味。ボトムアップ的というのは、読者からという意味。 日本の出版をめぐる業界構造は、著者と読者が不在で、両者の間を出版社、取次、書店からなる三角形が取り結んでいる。 読者が支払った書籍の対価は、その三角形の中でぐるっと回遊し、その一部が著者に還元される。 もちろん、形式的なお金の流れは読者→書店→取次→出版社→著者なんだけど、この三角形の中でお金を回遊させることで、「コンテンツという水物をパッケージングして全国に配信する」という難事業に伴ういろんなリスクを回避してきたわけだ。 マッハ新書では、この三角形を
立ち上げのころからよく知っている電子書籍の出版社直販サイトが昨日で販売を中止し、ハードDRMがかかっていないPDFが主な商品だったので購入済みの本が読めなくなるということは原則としてないんだけど、しばらくしたら購入済みの本のダウンロードもできなくなるので、保存していたハードディスクが飛ぶなどしてバックアップもなけば事実上再入手は困難になる。 このような状況になること自体は、同じような出版社直販サイトをやっている人間として言うべきことでないのは承知のうえだけど、ある程度は仕方がないことだと考えている。というか、そうした事業継続が困難になるリスクをゼロにしようとしていたら、何も始められない。ぶっこんで本を作って売っているので買ってください、と言い続けるだけである。買ってください。 www.lambdanote.com で、こういう話があってもなくても常に考えてる問題として、完全に平のデータをダ
理工書のタイトルに「入門」が多いのは出版社の編集者が売れるからという理由で入門でないものにも入門とつけたがるからだ、という頻出の話題をまた見かけたので、当事者を対象としてツイッターでアンケートしてみた。 理工書のタイトルを考える立場の人(編集者もしくは著者)が「入門」というキーワードを書名につけるとき、何を目指しているかを知りたいです。— keiichiro shikano λ♪ (@golden_lucky) 2018年1月5日 125票って、最後の選択肢の37%を割り引いても当事者以外の思惑がかなり紛れているような気がするけど、それでも「売れるようにするため」という選択肢がこんなに多いとは思わなかったよ。。 ぼく自身はわりとタイトルに「入門」ってつけるのを躊躇しないほうだけど、素朴に「実践的な話とか応用例には踏み込んでない、あくまでも入門です」を示す記号として捉えている場合がほとんどだ
note.mu 言いたいことは、すごくよくわかる。でも、残念ながら、「読まれるテキストとは、読み飛ばせるテキストである」というのが圧倒的に正しい。だから、「読まれるテキスト」を考えるなら、元記事のように、「読み飛ばせるテキストにするにはどうするか」っていうのをスタートにしたほうがいいとおもう。 読み飛ばせるテキスト、ぜんぜん悪いものじゃないよ。読み飛ばすような内容もないのが、悪いテキスト。ちなみに、内容がないけど読み飛ばせないテキストっていうのが最高ですね。 そもそも、段落をちゃんと構成しなきゃいけないのは「読み飛ばせる」ようにするためだ。そういう構成ができているテキストを読むっていうのは、情報を取り入れるための最速な手段だといえる。 「あ、これ、ちゃんと分かりたいし、ちゃんと読まないと絶対に分からないやつだ」という人は、読み飛ばしたあと、読みなおしてくれる。だから、そのときに困らないよう
blog.jnito.com 同書の制作の舞台裏がとてもよく伝わってくる、すばらしい記事だった。 すごくよくまとまっているので、未読だけど書籍本体もしっかり書かれているのだろうなと感じた。 で、制作の舞台裏があまりにも伝わりすぎたので、おれにもひとこと言わせてという気持ちが抑えられず、2点だけ突っ込ませてほしい。 まず、「紙の本の制作は完全にウォーターフォール」という文字列を見て、どうしようもなくアンビバレントな感傷に飲み込まれてしまった。 というのも、まさに「おれたちの紙の本づくりはウォーターフォールではない」という発表を、いまを遡ることちょうど10年前にしていたから。 イテレーティブでインクリメンタルな技術書の作り方 from guest38a0d4 www.slideshare.net あれから10年間、それなりに商業的にも成功するタイトルをイテレーティブかつインクリメンタルに作って
名が知れている人であれば出版社を使わずに自分で印刷製本して流通させたほう儲かるかもよという記事(もはや出版社より同人誌のほうがいい時代じゃないですかねっていう|yuukee|note)があって、人やジャンルによってはもちろんそうだよね、西野氏の話が引き合いに出されてるから、そういうジャンル(どういうジャンル)の本だと特にそういう傾向あるよねと思って読んでたら、なんと「技術書とかハウツー本」が想定されていたらしく、まさにその技術書というジャンルで、これは西野氏がやったような無料公開みたいなのが数十年前から事例としてあったようなジャンルで、そのジャンルで出版社(編集者じゃないよ)をやっている身としては、おまえいま「技術書とか」って適当に言ったろ、という気持ちになりました。 そこそこの出版社で3000部とか印刷してすぐに重版がかかる本は、3000部がぜんぶ売れたから重版するんじゃなくて、市中在庫
ある出版社が電子書籍の直販サービスを一方的に打ち切るというニュースが今日あり、自分は前にその出版社で編集者をしていて、打ち切られることになった電子書籍の直販サービスにもわりと近いところにいたし、たぶんぼくが作ったいた本は、その電子書籍の直販サービスでいまだにとてもよく売れているはずで、それなのにどうやら著者や訳者に一切の連絡もなく打ち切られたらしく、まあ、一カ月前にくだんの直販サービスを立ち上げたぼくの先輩であるフルスタック編集者がやめたことを考えると、遅かれ早かれこうなるのは目に見えていたので、このニュース自体にまったく驚きはなかったんだけど、こうやってその日がくると、あのときの編集チームを社内政治にからめてつぶした人たちにはほんとうにあきれるし、当時のポジティブな気持ちとか、誇らしさとか、楽しさとか、そういうのを思い出してしょっと憤慨するし、でも、こうしてぼくは自分で編集チームをまた持
このページを最初にブックマークしてみませんか?
『golden-luckyの日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く