サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
円安とは
golden-lucky.hatenablog.com
ほぼすべての個人が専用の情報端末を持ち歩く社会でありながら、印刷製本された「紙書籍」というパッケージの形で知識や物語に接することを好む人がまだまだ十分に多く、その小売りに特化した店舗が「書店」として成立できていた2024年、それでも年々縮小する需要の前に小規模な書店はすでに次々と姿を消し、紙書籍を求める人たちの受け皿として役割を果たしていたのは都市部に残された大型書店だった。それら大型書店の広大な店頭には無数の紙書籍が並び、しかもそれは毎日のように増大していく。なぜなら紙書籍は、それを生み出すことを生業とする出版社にとって、たとえ読者の手に渡ることがなくても流通に載せさえすれば収益になる商材でもあったからだ。産業の末路である。 紙書籍を好む人の多くは大型書店が好きだったと思う。コンセプトが明確でエッジを効かせた小規模書店への憧れはあるけれど、必ずしも選書や店主が個人のバイブスに合うとは限ら
本記事は、ラムダノートで発売している『定理証明手習い』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。そもそも定理証明とか自分には関係ないしっていう人も多いと思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。 「ラムダノートの本の読み方(私論)」シリーズはこれで第3回なのですが、前回からは丸1年も空いてしまいました。この間に『実践プロパティベーステスト』を出版し、プログラムの挙動を検証する本について語れることが増えたので、そのあたりの世界観自体から話を始めていきたいと思います。 テストケースを手作りして挙動を確かめる 性質からテストケースを自動生成するプロパティベーステスト プログラムの性質を値によらず「証明」する 証明してみよう 続きは『定理証明手習い』で 現実的な効能? テストケースを手作りして挙動を確かめる 配
2023年、Twitterは名目上消失しました。 ずっとMastodonとFacebookに馴染めなくて困っていたのですが、Blueskyのアカウントを作れたことでなんとか救われました。 いまのところBlueskyは自分にとって「居心地がいいSNS」になっています。 Blueskyの居心地をよくするうえで自分にとって役立った機能として「フィード」と呼ばれるものがあるので、これについてpyspa Advent Calendar 2023 - Adventarの一記事として書かせてもらおうと思います。 フォローするアカウントを増やすの難しい プラットフォームが押し付けてくる投稿は微妙だけど… タイムラインをアカウント単位で作るものといつから錯覚していた? 「本とかを読む」フィードを作った フォローするアカウントを増やすの難しい SNSで自分がふだん目にするコンテンツの大半は「他のアカウントをフ
本記事は、ラムダノートで発売している『RubyでつくるRuby』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。また、この本は当社の本のなかでも過小評価されているところがあると思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。 本書『RubyでつくるRuby』を買った人にも、まだ買っていない人にも、とにかくまず意識してほしいのですが、この本はRubyの解説書ではありません。 じゃあなんの本かっていうと、これは「そもそもプログラミング言語でプログラムを書くって、なに?」という根本的な問いへの取り組み方を教えてくれる本です。 もう一度言いますが、この本はRubyの解説書ではありません。なので、「Rubyを使うつもりはなくて、PythonとかJavaScriptが好き」っていう人や、「それらのプログラミング言語をいままさに
本記事は、ラムダノートで発売している『プロフェッショナルSSL/TLS』を買っていただいた方向けに「読んで」とお願いするための「私家版、読み方のおすすめ」です。本なので、どう読んでもらってもいいんですが、「買ったはものの積読になっている」という方の背中を押せればと思います。 この本は、プロトコルであるTLSの解説書であると同時に、「インターネットで安全にやっていく」ための感覚のベースラインを与えてくれる本です。 そういうつもりで、まずは第1章を読んでみてください。 知ってる話も知らない話もあると思いますが、20ページくらいしかないので、とりあえず読みましょう。 ここを読むと、現代のTLS以前の古典的な暗号、ハッシュ、認証について、安全かどうかを考えるためのフレームワークが得られます。 カタログ的ではないので、そういうのは期待しないでください。 なお、現在のバージョンには「認証付き暗号」とい
2015年12月に自分で出版社を立ち上げたとき、うっすらと決めていた覚悟は、「ひとまず10年は続ける」でした。 それまで15年くらい、技術系版元として歴史も規模もそこそこある出版社で企画編集をやっていたので、「だいたい何部くらい売れれば一人なら食っていける」といった程度の雑な算段はあったものの、かっちりした事業計画があったわけでもなく、「まあ、しばらくは前職の退職金を食いつぶしながら最初の何冊かを作ればいいかな」などと気軽に考えながら、むかし作った本の読者だったり有識者レビュアーだったりでお世話になっていた時雨堂という会社に遊びにいき、そんな浮ついた起業計画を雑談のつもりでしたら、社長の @voluntus に「お金出すよ」と言われ、「えっ」って戸惑っているうちに税理士さんを紹介してもらい、定款ができて、気づいたら ラムダノートという出版社 ができていました。 あれから満7年。2022年1
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
「納得」欲 パソコンやブラウザ、あるいはスマホで使うアプリケーションを作っているとき、自分がやっている「プログラミング」という行為にどこまで「納得」できているでしょうか? 「プログラミングという行為への納得」、ちょっと耳慣れない概念ですよね。実をいうと、さっきこの記事を書き始めたときに思いつきました。プログラムを書いていると、エラーみたいな露骨な躓きがない場合でも、なんかもやもやすることがあります。このもやもや、少なくとも自分は、以下のような側面で一定の「納得」に至っていないことが原因であるような気がしています。 アプリケーションの仕組みをデータ構造やアルゴリズムの言葉で説明しきれるぞ、という側面での「納得」 意図通りの挙動になることに設計レビューやユニットテストや動作検証を通じて確信が持てるぞ、という側面での「納得」 コードがコンピュータやネットワークという物理的な装置の上でどう処理され
(pyspa Advent Calendar 2021 17日めの記事です。昨日は@aodagによる「swayでwayland」でした。swayよさそうと思ってapt installしたらbusterにはなかったので、bullseyeに上げている間に書いています) 大学を出てニートをしていた時分には、リンゴ1個で昼ご飯を済ませることがあった。 そこだけ切り取るとアメリカの小学生っぽいけど、父方の実家である弘前の叔母がリンゴを箱で送ってくれて、でもすでに家族の団欒でリンゴを食べるような機会もなく、悪くなる前にがんばって毎日1個ずつでも食べていた、というのが実態に近い。 バイト先で昼休みにリンゴを丸かじりするのは、片手で済ませられるし、一人で過ごしたい自分の性にも合っていた。 就職して自分の家族をもってからは、わざわざ自分でリンゴを買って食べることもあまりなくなった。 20代までに一生分のリン
自作キーボードを始めるとお世話になるQMKというファームウェアがあります。 キーボードは要するにスイッチなので、「どのスイッチが押されたときにどのキーの情報としてPCに伝えるか」を制御する必要があるのだけど、これはキーマップと呼ばれる情報をATmegaやARMのマイコン向けにコンパイルすることで開発します。そのための開発環境を提供してくれるのがQMKという感じ。 で、自作キーボードといってもたいていはキットを使うわけで、そういうキットの多くにはデフォルトのキーマップがあるから、そのデフォルトのキーマップをターゲットのマイコン向けにコンパイルしてそれをインストールすれば事足ります。 QMKには、代表的な自作キーボードのキット向けのデフォルトのキーマップもあらかじめほとんど用意されているので、そのキーマップに手を加えることで自分の好きな設定のキーボードに調整することも可能です。 調整というと、
かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう仕事をしていました。 誰もが自分のSNSを持ち、ブログのプラットフォームで記事を公開し、中には自分で印刷製本して本の形にして売買している現代、「自分で文章を書いて世間に出す」のに出版社は不要です。いわんや編集者をや。 自分は出版社を作り、そこで編集者をやっているので、この「出版社も編集者も不要」という世界で何をすべきかという問題についてよく考えます。毎度たどり着くのは「必須ではないけど不要というほどでもない」という答えなんだけど、特に「不要というほどでもない」に対する根拠をあまり明確にしてきていない気がするので、少し言葉にしてみようと思います。
本って「紙に情報を印字して束ねたもの」っていう点ではどれも見た目が似ていて、そのため「本」という単一の群が存在するかのように扱われがちな傾向があると思う。 でも、とくに商品として見ると、本はジャンルごとにぜんぜん別物だ。 ジャンルごとに「購入しよう」という意思をもって本を見る人、つまり「潜在読者」が違うから、作り方も売り方もまったく変わってくる。 それでも「紙に情報を印字して束ねたもの」が一つの市場で扱われているのは、やはり「流通させやすいから」っていう側面が大きいんだろうな。 というか、流通のために「紙に情報を印字して束ねる」という形に情報を押し込めているといっても過言ではない。 まあ、もちろんこれは過言であって、情報を人間が扱いやすい形にしたものを基準にして流通を考えた結果が現在だから、現在はそういうものに適した流通になっているだけなんだろうけれど。 自分たちが「紙に情報を印字して束ね
設立からあっという間に5年が経過し、さらに出版で収益が出るようになってから4年が経とうとしている(最初の1年間ちょっとは何も本を出していなかったので)。 既刊の点数も10を超えた。 なんとなく、この第5期は、気づいたら出版社としてのトンネルを1つ抜けた一年だったように思う。 第5期は、2本の新刊単行本と、1本の『n月刊ラムダノート』を発行した。 『徹底解説 v6プラス』 『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』 『n月刊ラムダノート Vol.2, No.1(2020)』 新刊2冊は、思いがけず企業さんとのタイアップという形で実現した企画だった。 といっても、どちらも著者を見ればわかるように、技術を解説する本という点で妥協はない。 むしろ「第三者視点では外に出ることがあまりなかった情報」を書籍という形で世に出せたことが個人的には大きいお仕事だった。
今ではプログラミングできないわけではないけど、そういえばプログラミングは完全に独学と言っていい。 いや、大学では数学をやっていたので、FortranとかLispはちょっとやった。 なので「完全に独学」といったら嘘になる。 それでも、いま仕事で使っているコンピューターの知識は、基本的にすべて書籍を通して独学したものだ。 そこで、自分が何の本を読んでプログラミングを実務で使えるくらいにはなれたのか、アフィリエイトと宣伝を込めつつちょっと振り返ってみてもいいかなと思って走り書きしてみる。 テキストフィルターを書きまくるとこから始めるといいと思う プログラミングぜんぜんやったことない人が「プログラミング完全に理解した(ダニング・クルーガー的な意味で)」という実感の端緒を得るまでには、まず「テキストフィルタを書きまくる」のがわりと近道だと信じている。 コンピューターを使うことがインターネットを使うこ
もう10年間、ほぼ毎年PostScriptのプログラムを手書きして年賀状を作ってきたわけだけど、いつも年賀状を出しているのは親戚などの非コンピューターな人たちが大半なので、PostScriptでプログラマティックにデザインを生成している面白さはわからないし、もうプログラムとしてのネタ性をデザインに向けなくてもいいだろうということで、今年はデザインには一ミリも努力せずプログラムだけ工夫してみました。年賀状っぽいPDFを出力しつつPostScriptのコードとしてはQuineになっているというプログラムです。*1 << /PageSize [420 285] >> setpagedevice /SaucerBB.ttf findfont 140 scalefont setfont 1 0 0 setrgbcolor /a (\(<< /PageSize [420 285] >> setpage
「日本の専門書は安い、もっと高くあるべき」という意見があります。 この意見の背景には、専門書の価格はその価値で決まるかという観点と、出版社は専門書でどう利益を出せるかという観点があるような気がします。 ここでは、それぞれの観点について、個人的に「それって実際のところはどうなの」と思う点を書きだしてみます。 なお、両者の観点は本来は独立に議論できるものではないであろうこと、そもそも自分が観測できる範囲での意見を書きだすだけなので客観性のある議論でもないことに注意してください(自分は主に理工書、さらに言うとコンピューターに関する書籍で仕事をしています)。 専門書の価値で専門書の価格を決められるか 専門書の収益構造と価格設定 インターネットの時代に専門書の需要はあるのか 専門書の価値で専門書の価格を決められるか 専門書の価格は、そもそも「価値」が何なのかという点に立ち返ると、わりと身もふたもない
半年ぶりの新刊です。『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』です。紙とPDFがセットになった直販サイトはこちら。 Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち(紙書籍+電子書籍) https://www.lambdanote.com/products/engineers-in-voyage さて、今回の新刊、いろいろ疑問を呼ぶタイトルかもしれません。 「なぜ VOYAGE GROUP?」 「なぜ t_wada?」 「なぜ宇宙船?」 「答えは本書で!」と言って済ませることもできるのですが、ここで少し「個人的」なふりかえりをして何となく答えた気分になっておこうと思います。 なぜ VOYAGE GROUP? なぜ t_wada? なぜ宇宙船? で、結局のところどういう本なの? 気合い入ってます なぜ VOYAGE G
「2つのgitリポジトリがあって、その片方をもう一方に取り込みたい」という状況を考えます。依存ライブラリのソースを自分のプロジェクトで保持したい、といった状況が典型的でしょう。 この場合、通常は git submodule を使うと思います。 git submodule であれば、他のプロジェクトを履歴ごと自分のソースの一部として管理できて、かつ双方の履歴をきれいに分離できます。 Git - Submodules ただ、双方の履歴が分離できるということは、双方の履歴を混ぜられないということでもあります。そのため、 git submodule は、他のプロジェクトのソースに自プロジェクト独自の変更を加えて管理するといった用途には向かないように思います。ではどうすればいいだろうか、という試行錯誤の記録です。 git submodule で取り込む 「Aのcloneにおけるsubmoruleへの
「本の編集者は何をしているのか」を書こうとしていて、もう何か月もまとまらなので、とりあえず「出版社が何をしているのか」を書いておきます。 素朴な出版社のイメージ=中間搾取者 出版社そのものは販売網ではない 販売網への窓口は出版社の機能のごく一部 出版社=売り物の本の専門家 まとめのようなもの 素朴な出版社のイメージ=中間搾取者 とくに出版業界に興味がない人からみた出版社のイメージって、おおむね「著者と読者の間にいるやつ」という感じだと思います。 絵にするとこんな感じ。 著者の立場からすると「本を出すときにお世話になる会社」で、読者の立場からすると「著者が書いた本を書店で買えるようにしてる会社」ですね。 この絵のイメージで出版社を捉えると、「原稿から本を作るコストはかかるだろうけど、中間にいるだけで本の売り上げの大部分が懐に入るのか。やはり既得権益は強いな」という印象を抱くのではないでしょう
ラムダノートという出版社を作って4年が経ちました。 www.lambdanote.com 去年に引き続き、今年もちょっとふりかえりをしてみます。 この記事はラムダノートの技術 Advent Calendar 2019の25日めのエントリーです。 第4期(2018年12月~2019年11月)のふりかえり 『n月刊ラムダノート』はじめました 今年は『n月刊ラムダノート』という不定期刊行誌を3月に発行し始めました。 去年のふりかえりで第4期の目標として掲げていた「単発の本じゃない形で濃い技術情報をお届けする新企画」は、これのことです。 ぶっちゃけ、技術書、読むの大変じゃないですか? 正直なところ、作るほうもかなり大変です。 技術書に限らず、いま出版社が次々に新刊を出しているのは、半ば商売を維持するためという構造的な側面があります(それだけが理由ではないです)。 読む人も作る人もさまざまな無理感を
昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の話で締めくくろうと思います。 現在、日本の出版事業の中心は、「版元」「取次」「書店」という3者(いわゆる業界三者)が担っています。 メーカーと小売りの間に卸しがいるという構造は特別なものではありませんが、業界三者がちょっとだけ他と違うところがあるとしたら、書店と版元との柔軟な直接取引が少なく、取次-書店間、取次-版元間での委託取引が中心になっていることです。 この構造を支えているひとつの柱は再販価格維持制度による書籍の定価販売なんですが、この構造のおかげで、日本はかなり書店の数が多い国であり続けました。 2000年代初頭には全国で2万店くら
この記事は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というネタ発表をしたことでも
昨日の記事では「書籍のマクロな構造」について話しました。 このマクロ構造は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の島 先週、このアド
Pandocフィルターの便利さと限界が見えてきたところで、最後に実用的かもしれない例を1つ紹介します。 Markdown原稿に索引のエントリを指定するための「記法」を考えてみる話です。 どういう記法にするか そもそもMarkdownの方言で索引に対応してるものはないと思うので(まじめに先行事例を調べていないのであるかもしれない)、記法から考えないといけません。 どんな記法ならMarkdown原稿中に索引を挿入してもうざくならないでしょうか。 まあ、どんな記法であれテキスト原稿中に索引を挿入していくと、読みにくくなったりgrepしにくくなったりするのは必然なのですが、そのへんの工夫は過去にもいろいろやってきたので、この記事では「Markdown原稿にふさわしい索引の記法を何かしら考える」ことに集中します。 まっさきに思いつくのは、LaTeXの索引コマンドをそのままLaTeX原稿中に投入するこ
ラムダノートという出版社を作って4年が経ちました。 www.lambdanote.com 去年に引き続き、今年もちょっとふりかえりをしてみます。 この記事はラムダノートの技術 Advent Calendar 2019の25日めのエントリーです。 第4期(2018年12月~2019年11月)のふりか…
昨日の記事では、PandocのReaderを自分で作り直す話をしました。 いうまでもありませんが、ReaderはPandocの一部なので、改造Readerを使うためにはPandocをソースから自分でビルドする必要があります。 ところがPandocというのは、Haskellで書かれているうえに、かなり巨大で依存関係がめんどくさいソフトウェアです。 GitHubからソースをcloneしてくれば誰でもビルドできるとはいえ、Haskellの開発経験がまったくないと、ビルドできる環境を整えるだけでもなかなか大変でしょう。 Readerを改造するしか手のうちようがない機能追加や修正については何ともなりませんが、Pandoc構造に押し込まれたコンテンツを他の記法として書き出すときに標準とは違うことをしたいだけなら、Pandocをソースからビルドしなくても済むような裏口が昔から用意されています。 それが今
Python界隈でよく見かける構造化文書のための記法として、reStructuredText(以降はreSTと書きます)があります。 reStructuredText https://docutils.sourceforge.io/rst.html 軽量マークアップ言語などと呼ばれることもありますが、reSTはかなり高度な表現力がある記法です。 その記法をパースするために標準で使われているのはDocutilsという仕組みです。ただ、DocutilsはreST専用ではなく、他の記法のパーサを実装することもできるらしいです。 その意味でDocutilsは、Pandocと同じく、内部の抽象的なデータ構造へと記法を押し込めるツールだといえる気がします。 Docutilsについては『マスタリングDocutils』に詳しいので興味がある方は購入しましょう。 『マスタリングDocutils』 マスタリン
次のページ
このページを最初にブックマークしてみませんか?
『golden-luckyの日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く