サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
中東情勢
golden-lucky.hatenablog.com
今ではプログラミングできないわけではないけど、そういえばプログラミングは完全に独学と言っていい。 いや、大学では数学をやっていたので、FortranとかLispはちょっとやった。 なので「完全に独学」といったら嘘になる。 それでも、いま仕事で使っているコンピューターの知識は、基本的にすべて書籍を通して独学したものだ。 そこで、自分が何の本を読んでプログラミングを実務で使えるくらいにはなれたのか、アフィリエイトと宣伝を込めつつちょっと振り返ってみてもいいかなと思って走り書きしてみる。 テキストフィルターを書きまくるとこから始めるといいと思う プログラミングぜんぜんやったことない人が「プログラミング完全に理解した(ダニング・クルーガー的な意味で)」という実感の端緒を得るまでには、まず「テキストフィルタを書きまくる」のがわりと近道だと信じている。 コンピューターを使うことがインターネットを使うこ
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って
かつては出版社の中に編集者という職業があって、著者に執筆を依頼したり、そうして書いてもらった原稿を取りに行ったり、誤字脱字や「てにをは」を矯正したり、漢字や送り仮名の表記を出版社のルールに従って統一したり、それを印刷製本する指示を出したり、そういう仕事をしていました。 誰もが自分のSNSを持ち、ブログのプラットフォームで記事を公開し、中には自分で印刷製本して本の形にして売買している現代、「自分で文章を書いて世間に出す」のに出版社は不要です。いわんや編集者をや。 自分は出版社を作り、そこで編集者をやっているので、この「出版社も編集者も不要」という世界で何をすべきかという問題についてよく考えます。毎度たどり着くのは「必須ではないけど不要というほどでもない」という答えなんだけど、特に「不要というほどでもない」に対する根拠をあまり明確にしてきていない気がするので、少し言葉にしてみようと思います。
ラムダノートという出版社を作って3年が経ちました。 www.lambdanote.com この12月から、会社としては第4期に突入です。 3年もすれば中学生は高校生になるわけで、それなりに感慨があります。 そこで、pyspaアドベントカレンダーという場を借りて、ちょっとふりかえりをしてみることにしました。 本の紹介はよくやるけど、会社の紹介はあまり積極的にやってないので、そのつもりで書いたものです。 第1期(2015年12月-2016年11月) 出版社なので本を作って売りたいわけですが、本は自然には生えてきません。 前の会社に在職中から独立に向けた準備を進めるような計画性があればよかったのですが、本当になにも準備しないまま音楽性の違いで辞めたので、起業した最初の年は当然ながらラインナップがゼロでした。 そんな状態でも起業に踏み切れたのは、時雨堂の@volantusが凄腕の会計事務所を紹介し
ある出版社が電子書籍の直販サービスを一方的に打ち切るというニュースが今日あり、自分は前にその出版社で編集者をしていて、打ち切られることになった電子書籍の直販サービスにもわりと近いところにいたし、たぶんぼくが作ったいた本は、その電子書籍の直販サービスでいまだにとてもよく売れているはずで、それなのにどうやら著者や訳者に一切の連絡もなく打ち切られたらしく、まあ、一カ月前にくだんの直販サービスを立ち上げたぼくの先輩であるフルスタック編集者がやめたことを考えると、遅かれ早かれこうなるのは目に見えていたので、このニュース自体にまったく驚きはなかったんだけど、こうやってその日がくると、あのときの編集チームを社内政治にからめてつぶした人たちにはほんとうにあきれるし、当時のポジティブな気持ちとか、誇らしさとか、楽しさとか、そういうのを思い出してしょっと憤慨するし、でも、こうしてぼくは自分で編集チームをまた持
半年ぶりの新刊です。『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
「本の編集ではテキスト原稿のバージョン管理しか勝たん」という信念を押し通してきて、そろそろ20年近くになりました。厳密には19年くらいだと思うので、タイトルは誇張です。 久しぶりに編集者にとってのバージョン管理に言及したくなったので書いてみました。 目次です。 なんで「テキスト原稿のバージョン管理」の話をしなくなったか 「誌面レイアウトしたPDFとか紙に赤字を入れる」で編集するのもう無理… そこでテキスト原稿のバージョン管理 具体的にどうすればいいのさ 前提からつらつら書いていたらやたらに長くなりそうだったので、全部捨てて書き直したのに、それでもそれなりに長くなってしまった。 最後の節に書いた「 「原稿の移り変わり」を管理するのではなく、「原稿にありうる無数の可能性」を管理する 」というヒントだけでも持ち帰ってもらえればうれしいです。 なんで「テキスト原稿のバージョン管理」の話をしなくなっ
「うちの学校でもついにプログラミングの授業が始まったよ」 「それは興味深いね。どんなふうに教えてるの? やっぱりScratchとか?」 「Scratch? ああ、プログラミング言語のことか。プログラミング言語は使わなくていいんだよ」 「え?」 「小学校で学ぶプログラミングっていうのは、プログラミング言語を覚えさせることが目的じゃないからね。システム思考力とかロジカルシンキングって聞いたことあるだろ?」 「あるかないかでいったら、あるよ」 「プログラミング言語みたいなのは、単なる技術だ。それは仕事で必要な人だけが覚えればいい。子どもたちに教えるべきことは、プログラミング言語みたいな技術じゃなくて、システム思考やロジカルシンキングの延長といえるプログラミング的思考なんだよ」 「プログラミング的思考っていうのが、システム思考やロジカルシンキングとどう違うのか、いまいちよくわからないんだけど…」
PDFからテキストを取り出すのは、意外と大変です。 それにはいくつかの理由があるのですが、もっとも根本的な点で真っ先に解決が必要になるのは、人間が雑に文字としてみなしている絵(「グリフ」)をコンピューターで扱えるような「文字」にする方法です。 これには2つのアプローチが考えられます。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る PDFファイルの中身を解析してテキストを抜き出す このうち2つめの話は明日以降にして、今日は1つめの話をします。 PDFビューワーでファイルを開いた状態から何とかしてテキストを読み取る方法 この方法は、言ってみれば、人間もしくは人間のように振る舞うソフトウェアによりPDFビューワーの表示を「視覚的に読む」ということです。 これはPDFの本来の使い道に即した手法です。 PDFというのは、グリフ(文字の形)をページ上に表示するための汎用の仕組
「2つのgitリポジトリがあって、その片方をもう一方に取り込みたい」という状況を考えます。依存ライブラリのソースを自分のプロジェクトで保持したい、といった状況が典型的でしょう。 この場合、通常は git submodule を使うと思います。 git submodule であれば、他のプロジェクトを履歴ごと自分のソースの一部として管理できて、かつ双方の履歴をきれいに分離できます。 Git - Submodules ただ、双方の履歴が分離できるということは、双方の履歴を混ぜられないということでもあります。そのため、 git submodule は、他のプロジェクトのソースに自プロジェクト独自の変更を加えて管理するといった用途には向かないように思います。ではどうすればいいだろうか、という試行錯誤の記録です。 git submodule で取り込む 「Aのcloneにおけるsubmoruleへの
昨日まで何回かにわたり、多様なドキュメント形式の変換アプリケーションであるPandocのコアとなる仕組みを説明してきました。 特に、Pandoc構造とそれを生成するReader、生成されたPandoc構造を変換するPandocフィルターについて、少し時間をかけて紹介しました。 では、PandocのReaderとフィルターについて理解したところで、Pandocを使って本は作れるでしょうか? いままでの説明には登場しませんでしたが、Pandocの出力側を担うWriterには、「PDF生成のためのLaTeX Writer」や「EPUB Writer」など、「本」を作るのに使えそうなものがあります。 それらWriterを制御するためのコマンドラインオプションはいろいろ用意されており、独自のテンプレートを指定することも可能です。 ただ正直なところ、これらのWriterは、吊るしの状態では売り物の本を
ほぼすべての個人が専用の情報端末を持ち歩く社会でありながら、印刷製本された「紙書籍」というパッケージの形で知識や物語に接することを好む人がまだまだ十分に多く、その小売りに特化した店舗が「書店」として成立できていた2024年、それでも年々縮小する需要の前に小規模な書店はすでに次々と姿を消し、紙書籍を求める人たちの受け皿として役割を果たしていたのは都市部に残された大型書店だった。それら大型書店の広大な店頭には無数の紙書籍が並び、しかもそれは毎日のように増大していく。なぜなら紙書籍は、それを生み出すことを生業とする出版社にとって、たとえ読者の手に渡ることがなくても流通に載せさえすれば収益になる商材でもあったからだ。産業の末路である。 紙書籍を好む人の多くは大型書店が好きだったと思う。コンセプトが明確でエッジを効かせた小規模書店への憧れはあるけれど、必ずしも選書や店主が個人のバイブスに合うとは限ら
「納得」欲 パソコンやブラウザ、あるいはスマホで使うアプリケーションを作っているとき、自分がやっている「プログラミング」という行為にどこまで「納得」できているでしょうか? 「プログラミングという行為への納得」、ちょっと耳慣れない概念ですよね。実をいうと、さっきこの記事を書き始めたときに思いつきました。プログラムを書いていると、エラーみたいな露骨な躓きがない場合でも、なんかもやもやすることがあります。このもやもや、少なくとも自分は、以下のような側面で一定の「納得」に至っていないことが原因であるような気がしています。 アプリケーションの仕組みをデータ構造やアルゴリズムの言葉で説明しきれるぞ、という側面での「納得」 意図通りの挙動になることに設計レビューやユニットテストや動作検証を通じて確信が持てるぞ、という側面での「納得」 コードがコンピュータやネットワークという物理的な装置の上でどう処理され
日本語圏におけるHaskellの解説本には、これまで4回の波がありました。 それを思い出しながら、最後に『プログラミングHaskell 第2版』の紹介をします。 第1波 第2波 第3波 第4波 『プログラミングHaskell』が改訂されます 第2版ではプログラミングにおける型の理解が深まると思う ここで買えます 第1波 Haskell解説本の1つめの波は、2006年、『入門Haskell』と『ふつうのHaskell』が出版された頃にありました。 このうち、『入門Haskell』は(おそらく)日本初のHaskell本です。 『入門Haskell』(2006年) 『ふつうのHaskell』(2006年) 『ふつうのHaskell』は、書名だけを見ると「特殊な言語」であるHaskellを「ふつう」に説明している本であるように思えるのですが、実はそうでもなくて、淡々と部品の説明をしていく感じの内容
2023年、Twitterは名目上消失しました。 ずっとMastodonとFacebookに馴染めなくて困っていたのですが、Blueskyのアカウントを作れたことでなんとか救われました。 いまのところBlueskyは自分にとって「居心地がいいSNS」になっています。 Blueskyの居心地をよくするうえで自分にとって役立った機能として「フィード」と呼ばれるものがあるので、これについてpyspa Advent Calendar 2023 - Adventarの一記事として書かせてもらおうと思います。 フォローするアカウントを増やすの難しい プラットフォームが押し付けてくる投稿は微妙だけど… タイムラインをアカウント単位で作るものといつから錯覚していた? 「本とかを読む」フィードを作った フォローするアカウントを増やすの難しい SNSで自分がふだん目にするコンテンツの大半は「他のアカウントをフ
昨日までこのアドベントカレンダーでは、PDFの内部の話から始めて、XMLという構造化文書の話、Pandocで記法を変換する話、EPUBで本というパッケージを作る話というように、徐々にレイヤを上げてきました。今日と明日はさらにレイヤを上げて、出版社の立場の話で締めくくろうと思います。 現在、日本の出版事業の中心は、「版元」「取次」「書店」という3者(いわゆる業界三者)が担っています。 メーカーと小売りの間に卸しがいるという構造は特別なものではありませんが、業界三者がちょっとだけ他と違うところがあるとしたら、書店と版元との柔軟な直接取引が少なく、取次-書店間、取次-版元間での委託取引が中心になっていることです。 この構造を支えているひとつの柱は再販価格維持制度による書籍の定価販売なんですが、この構造のおかげで、日本はかなり書店の数が多い国であり続けました。 2000年代初頭には全国で2万店くら
本記事は、ラムダノートで発売している『プロフェッショナルSSL/TLS』を買っていただいた方向けに「読んで」とお願いするための「私家版、読み方のおすすめ」です。本なので、どう読んでもらってもいいんですが、「買ったはものの積読になっている」という方の背中を押せればと思います。 この本は、プロトコルであるTLSの解説書であると同時に、「インターネットで安全にやっていく」ための感覚のベースラインを与えてくれる本です。 そういうつもりで、まずは第1章を読んでみてください。 知ってる話も知らない話もあると思いますが、20ページくらいしかないので、とりあえず読みましょう。 ここを読むと、現代のTLS以前の古典的な暗号、ハッシュ、認証について、安全かどうかを考えるためのフレームワークが得られます。 カタログ的ではないので、そういうのは期待しないでください。 なお、現在のバージョンには「認証付き暗号」とい
「日本の専門書は安い、もっと高くあるべき」という意見があります。 この意見の背景には、専門書の価格はその価値で決まるかという観点と、出版社は専門書でどう利益を出せるかという観点があるような気がします。 ここでは、それぞれの観点について、個人的に「それって実際のところはどうなの」と思う点を書きだしてみます。 なお、両者の観点は本来は独立に議論できるものではないであろうこと、そもそも自分が観測できる範囲での意見を書きだすだけなので客観性のある議論でもないことに注意してください(自分は主に理工書、さらに言うとコンピューターに関する書籍で仕事をしています)。 専門書の価値で専門書の価格を決められるか 専門書の収益構造と価格設定 インターネットの時代に専門書の需要はあるのか 専門書の価値で専門書の価格を決められるか 専門書の価格は、そもそも「価値」が何なのかという点に立ち返ると、わりと身もふたもない
本って「紙に情報を印字して束ねたもの」っていう点ではどれも見た目が似ていて、そのため「本」という単一の群が存在するかのように扱われがちな傾向があると思う。 でも、とくに商品として見ると、本はジャンルごとにぜんぜん別物だ。 ジャンルごとに「購入しよう」という意思をもって本を見る人、つまり「潜在読者」が違うから、作り方も売り方もまったく変わってくる。 それでも「紙に情報を印字して束ねたもの」が一つの市場で扱われているのは、やはり「流通させやすいから」っていう側面が大きいんだろうな。 というか、流通のために「紙に情報を印字して束ねる」という形に情報を押し込めているといっても過言ではない。 まあ、もちろんこれは過言であって、情報を人間が扱いやすい形にしたものを基準にして流通を考えた結果が現在だから、現在はそういうものに適した流通になっているだけなんだろうけれど。 自分たちが「紙に情報を印字して束ね
「本の編集者は何をしているのか」を書こうとしていて、もう何か月もまとまらなので、とりあえず「出版社が何をしているのか」を書いておきます。 素朴な出版社のイメージ=中間搾取者 出版社そのものは販売網ではない 販売網への窓口は出版社の機能のごく一部 出版社=売り物の本の専門家 まとめのようなもの 素朴な出版社のイメージ=中間搾取者 とくに出版業界に興味がない人からみた出版社のイメージって、おおむね「著者と読者の間にいるやつ」という感じだと思います。 絵にするとこんな感じ。 著者の立場からすると「本を出すときにお世話になる会社」で、読者の立場からすると「著者が書いた本を書店で買えるようにしてる会社」ですね。 この絵のイメージで出版社を捉えると、「原稿から本を作るコストはかかるだろうけど、中間にいるだけで本の売り上げの大部分が懐に入るのか。やはり既得権益は強いな」という印象を抱くのではないでしょう
マッハ新書、β版で電子版を先行発売して紙を売り出すという、ここ10年来の英語圏における一部技術書の動向が、日本語圏では技術書界に先立って新書という形で、トップダウンかつボトムアップに再発明されたものという感じがする(ポジティブな感想です)。 ここで、トップダウン的というのは、著者からという意味。ボトムアップ的というのは、読者からという意味。 日本の出版をめぐる業界構造は、著者と読者が不在で、両者の間を出版社、取次、書店からなる三角形が取り結んでいる。 読者が支払った書籍の対価は、その三角形の中でぐるっと回遊し、その一部が著者に還元される。 もちろん、形式的なお金の流れは読者→書店→取次→出版社→著者なんだけど、この三角形の中でお金を回遊させることで、「コンテンツという水物をパッケージングして全国に配信する」という難事業に伴ういろんなリスクを回避してきたわけだ。 マッハ新書では、この三角形を
本記事は、ラムダノートで発売している『RubyでつくるRuby』を買っていただいた方に「読んで」とお願いするための「私家版、読み方のおすすめ」です。また、この本は当社の本のなかでも過小評価されているところがあると思うので、「気になるけど買ってない」という方に興味を持ってもらうことも目的としています。 本書『RubyでつくるRuby』を買った人にも、まだ買っていない人にも、とにかくまず意識してほしいのですが、この本はRubyの解説書ではありません。 じゃあなんの本かっていうと、これは「そもそもプログラミング言語でプログラムを書くって、なに?」という根本的な問いへの取り組み方を教えてくれる本です。 もう一度言いますが、この本はRubyの解説書ではありません。なので、「Rubyを使うつもりはなくて、PythonとかJavaScriptが好き」っていう人や、「それらのプログラミング言語をいままさに
2015年12月に自分で出版社を立ち上げたとき、うっすらと決めていた覚悟は、「ひとまず10年は続ける」でした。 それまで15年くらい、技術系版元として歴史も規模もそこそこある出版社で企画編集をやっていたので、「だいたい何部くらい売れれば一人なら食っていける」といった程度の雑な算段はあったものの、かっちりした事業計画があったわけでもなく、「まあ、しばらくは前職の退職金を食いつぶしながら最初の何冊かを作ればいいかな」などと気軽に考えながら、むかし作った本の読者だったり有識者レビュアーだったりでお世話になっていた時雨堂という会社に遊びにいき、そんな浮ついた起業計画を雑談のつもりでしたら、社長の @voluntus に「お金出すよ」と言われ、「えっ」って戸惑っているうちに税理士さんを紹介してもらい、定款ができて、気づいたら ラムダノートという出版社 ができていました。 あれから満7年。2022年1
よく知られているように、ドキュメントには「構造」があります。 WebページではHTMLとCSSにより構造とスタイルを分離するべきとか、Wordでは書式設定をスタイルとして定義して使うことで構造とスタイルを分離するべきとか、ドキュメントの「べき」論で必ず言及される「構造とスタイルの分離」における「構造」です。 昨日までの話ではPDFにもドキュメント構造というのが出てきました。あれは、この「構造とスタイルの分離」というときの「構造」とは別物なので注意してください。 たぶん、PDFのドキュメント構造には、「ドキュメントを表すデータ構造」くらいの意味合いくらいしかありません。 一方、ドキュメントの話において「構造とスタイルの分離」というときの「構造」は、もうちょっとこうなんていうか、セマンティックな話です。 データをどう構成するかではなく、ドキュメントで表したい意味をどう構成するか、という話。 し
昨日までの話を整理します。 ドキュメントのXMLによる表現は、プログラムの抽象構文木に相当し、ドキュメントの意味構造を示したものであった なので、XMLの構文をS式で表せた すると、XMLの要素名がLispにおける関数、要素がその関数への引数に見えた そこで、要素を材料としてシリアライズした文字列を返すように、要素名で関数を定義した。その際、要素の中には別の要素名を持つ要素が入れ子になっていることがあるので、それらは再帰的に処理するように定義した。 こうして、ドキュメントのXMLをLispの評価器で直接実行できた そして、そのためのフレームワークとして、xml2texという自作のアプリケーションを紹介しました。 XMLからTeXを生成する専用機に見える名前が付いているけど、これは命名を失敗したと思っていて、xml2texは、いわば、XMLをつぶす機械を作る機械です。 XMLをつぶして好きな
昨日の記事では、PDFのコンテンツストリームから文字を読めたことにして、その文字をテキストとして再構築する話をしました。 今日は昨日までの話の締めくくりとして、「PDFごとにカスタムなテキスト取り出し」の話をするつもりだったのですが、その前に文字とコンテンツストリームについて落穂拾いをしておくことにしました。 というのは、昨日までの記事への反応を見ていて、この本のことをちょっと思い出したからです。 John Whitington 著、村上雅章 訳 『PDF構造解説』(オライリー・ジャパン、2012年5月) この本、PDFのドキュメント構造を知りたい人が最初に読むにはぴったりだと思います。 自分で簡単なPDFを手書きしながら「PDFの中身がどうなっているのか」を学べるように書かれているので、ドキュメント構造やコンテンツストリームの雰囲気を手軽に体験できる良書です。 しかし、この「自分で簡単な
設立からあっという間に5年が経過し、さらに出版で収益が出るようになってから4年が経とうとしている(最初の1年間ちょっとは何も本を出していなかったので)。 既刊の点数も10を超えた。 なんとなく、この第5期は、気づいたら出版社としてのトンネルを1つ抜けた一年だったように思う。 第5期は、2本の新刊単行本と、1本の『n月刊ラムダノート』を発行した。 『徹底解説 v6プラス』 『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』 『n月刊ラムダノート Vol.2, No.1(2020)』 新刊2冊は、思いがけず企業さんとのタイアップという形で実現した企画だった。 といっても、どちらも著者を見ればわかるように、技術を解説する本という点で妥協はない。 むしろ「第三者視点では外に出ることがあまりなかった情報」を書籍という形で世に出せたことが個人的には大きいお仕事だった。
はじめに みなさん、EPSファイル、使ってますか? 近年、(La)TeXの文書作成においては、「EPSファイルを使うな」というマナーが確立しています。 マナーにはデフォルトで抗っていくということで、この記事では、現代的なLaTeX環境におけるEPSファイルの可能性を探りたいと思います。 もちろん、「EPSファイルを使うな」は、実際にはマナーではありません。 技術的な根拠があるベストプラクティスのひとつです。 したがって、この記事の真の目的は、以下の2点だといえます。 ベストプラクティスをマナーへと貶めないために技術的な背景を知る 条件があえばEPSファイルにもまだまだ使い道があることを示す コンピュータサイエンスには、"All problems in computer science can be solved by another level of indirection"(「コンピュー
『n月刊ラムダノート』の話をいろいろしたいのだけど、どこから話せばいいのかわからないので、Lispの話をします。 昔、といってもほんの10年ちょっと前のことですが、日本でLispが流行った時期がありました。 「プログラミング言語のパワーには絶対的な差が存在する。その頂点に立つのがLispだ」と言って憚らない『ハッカーと画家』という本が2005年に出版され、それを読んだ多くの人が「よろしい、ならばLispだ」と思ったのです。 まあ、ほかにもいろいろな理由があったのだろうし、流行に関係なくLispを使い続けている人はたくさんいたし、いまでもぼくを含め多くの人がLispを日常的に使っているけれど、『ハッカーと画家』の影響によるちょっとしたLispブーム、というのは確かに起きていたと思います。 で、この『ハッカーと画家』を翻訳したのが川合史朗さんでした。 その当時、ぼくは同書を企画した部署にたまた
次のページ
このページを最初にブックマークしてみませんか?
『golden-luckyの日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く