とある休日 娘「ねぇ、パパ！」 娘「switchやろ〜！」 ワイ「おお、ええで！娘ちゃん！」 ワイ「Switchやろう！」 ワイ「ほな、テレビをつけて・・・」 娘「テレビ？」 娘「何を言っているの、パパ？」 娘「TypeScriptのswitch文のことだよ？」 ワイ「ファッ！？」 switch文で何をしたいのか 娘「今ね、ショッピングサイトを構築してるところなの」 ワイ「ほうほう」 娘「それでね、手広く儲けようと思って」 ワイ「おお、ええやんか」 娘「個人ユーザーだけじゃなく、法人ユーザーも登録できるようにしようと思うの」 ワイ「なるほどな」 娘「言語はTypeScriptを使っているんだけど」 娘「ちょっと聞きたいことがあるの」 ワイ「おう、なんでも聞いてや」 あいさつ関数を作っている 娘「ショッピングサイトにログインしたときに・・・」 個人の場合 → 「無職 やめ太郎さん、こんにちは
This list is a collection of component patterns for React when working with TypeScript. See them as an extension to the TypeScript + React Guide that deals with overall concepts and types. This list has been heavily inspired by chantastic’s original React patterns list. Contrary to chantastic’s guide I use mainly modern-day React, so function components and – if necessary – hooks. I also focus exc
2024/3/24に開催されたObject-Oriented Conferenceでの登壇資料です。 https://ooc.dev/2024/
1990年代にオブジェクト指向分析・設計の方法論がめちゃ流行ったことがあります。 ただ、そのブームが終わって、後続となるような方法論が流行ることはありませんでした。 で、なぜなのか考えていたのですけど、オブジェクト指向方法論のウリは分析段階で出てきたオブジェクト(といいつつクラス)がコードにそのまま引き継がれるというものでした。ようするにオブジェクト指向方法論というのはコードのスケッチを書いて詳細化していくというものだったのです。 しかしながらこれは、スケッチとして書いた分析・設計が間違っていればコードも間違うわけで、強くウォーターフォールの性質をもつものでした。 結局のところスケッチの妥当性というのはコードを書かないと検証ができません。分析・設計段階で見出されたクラスが妥当かというのは、コード書かなければわからなかったのです。逆に、コードを書けば妥当かどうかわかります。であれば、最初から
『ドメイン駆動設計』のモデル要素のひとつとして「集約」があります。 アプリケーションの対象となる事業活動の仕組みや決め事をソフトウェアで表現する技法のひとつとして集約の考え方はとても役に立ちます。 集約パターンはデータベースのデータ整合性の視点での説明されることが多いようです。しかしデータ整合性の文脈で集約を理解しても、ドメイン駆動設計の中核の関心事である「ドメインの複雑さ」を理解しドメインの知識をクラスで表現するためにはあまり役に立ちません。 この記事では、集約パターンをドメインロジックを表現するモデルの構成要素として効果的に利用するためのヒントを提供したいと思います。 集約はデータ操作の道具ではありません。集約はビジネスルールにもとづくドメインロジックのモデリングと実装の手段です。ここがわかるとドメイン駆動設計の理解が一気に進むと思います。 どうして集約がデータ整合性の話になってしまう
こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ
あなたがさっきまで読んでいた技術的に役立つ記事は、10年後も使えるでしょうか？ほとんどの場合でいいえ はじめに 短期的に効果的な手法や知識は、ソフトウェア開発の分野において、急速に価値を失う傾向があります。この現象は、私たちが何を重点的に学ぶべきかを示唆しています。最も重要なのは、第一に基本的な原理・原則、そして第二に方法論です。特定の状況にのみ適用可能な知識や即座に結果を出すテクニックは、長期的には有用性を失う可能性が高いです。これは、技術や手法が時間とともに進化し、変化していくためです。 learning.oreilly.com 「API Design Patterns」は、このような考え方を体現した書籍です。しかも480 ページもあります。本書は単なる手法の列挙ではなく、Web APIデザインの根幹をなす原則と哲学を探求しています。著者のJJ Geewax氏は、APIを「コンピュータ
こんにちは、NE会社で働いておりますきんじょう(@o0h_)がお送りします。 弊社ではPHPを用いてアプリケーション開発を行っています(Ruby, Go, Javaも領域によっては利用しております) さて、つい先日のことですが、社内にいるメンバーから「デザインパターンについて、勉強してみてるんだけど・・・」「ちょっとついていくのが難しくて」「どうしたらいいですかね？それとも、先にやっておくべきことが他にありますか？」なんて雑談をしました。 なるほど、コレは頻出質問になりそうだな・・・という気持ちにもなったので、今回はこの場を借りて「デザインパターン[1]、その前に〜個人的に思ったことをツラツラと〜」でお届けしていきたいと思います。 「デザインパターンを(から)勉強してみる」ことの、オススメ/オススメナイ いちおう、今回は「リーダブルコードくらいは読んでいる」「デザインパターンの勉強をしてい
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 エンジニアが英語力が必要な本当の理由を知ってますか？英語でしか存在しないドキュメントを読むため？違いますね。ずばり、センスの欠片も感じられない変数名やメソッド名を付けないようにするためですよ。あれやるやつマジ許さん。 2024-05-23 18:16:07
Object-Oriented Conference 2024で発表した資料です。 https://fortee.jp/oocon-2024/proposal/b31c9818-3cb8-4350-adfe-cbc839cdf829 ビジネスの専門知識（ドメイン）を中心に据えたドメイン駆動設計に…
関連リソース Agent Design Pattern Catalogue: A Collection of Architectural Patterns for Foundation Model based Agents 【論文紹介】LLMベースのAIエージェントのデザインパターン18選 基盤モデルを用いたAIエージェントの設計パターン The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey は、「AIエージェントのアーキテクチャ」について、シン
この文章みてください。 オレはもう20年以上システム業界にいるけどな、その長い経験から言うと、オブジェクト指向なんてものは、理論としては面白いけど、およそ実用的とは言い難いものだな。まぁ、例えばGUIのコンポーネントとかはオブジェクト指向に基づいて作られているようだから、そういうツールとかを作る人には必要なものなのかもしれない。しかし君たちがいずれ作ることになる業務アルゴリズムにはまったく無縁のものだと思ってもらって間違いない。どうもこの業界、オブジェクト指向でなければダメ、というような風潮がまかりとおっているけどな、オブジェクト指向なんか本当に使っている人はほとんどいないよ。オレも少し勉強してみたけど、カプセル化とかポリ何とかとか、どうにも利点が理解できなかったね。実際、実業務で使ったことなどないしな…… 「またお前、オブジェクト指向の話をしてるのか」と思ったかもしれませんが、2010年
今回の記事はオブジェクト指向プログラミングにおける設計の基本、「SOLID原則」について。 ある程度プログラミングの文法を知っていれば、動作するコードを書くことは可能です。しかし、より良いコードを書きたいのであれば、文法の知識だけではなく、設計に関する知識も必要になってきます。 特にUnityでは、適当にコードを書いていくと目も当てられないようなスパゲッティーコードが容易に出来上がります。「とりあえずシングルトンにすりゃいいや！」みたいなノリで「何とかManager」クラスを作りまくった結果、「あれ？この処理どこに書いたんだっけ？」という状況になったこと、誰しも一度はありますよね…？ 今回は、そんなクソk…良くないコードを書かないための設計原則である「SOLID原則」について紹介します。記事内のコードはC#で記述しますが、言語に関わらずSOLID原則は広く応用の効く考え方なので、是非とも覚
ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用 作者:田中 ひさてる技術評論社Amazon 予約してまで買ったものの、なかなか時間が取れず、読めていなかった『ちょうぜつソフトウェア設計入門――PHPで理解するオブジェクト指向の活用』をようやく読み終わりました。 筆者である田中ひさてるさん自身で描かれた表紙の可愛らしさからは想像もできないハードな内容なので、一気に読もうとすると「分かった気」になるだけで全然理解していなかった、ということになりがちなので、3回くらいぐるぐる読むといいと思います（そうです、この本は本文もイラストも丸っと同じ人が書いているのです！！）。 目次 第1章 クリーンアーキテクチャ 第2章 パッケージ原則 第3章 オブジェクト指向 第4章 UML（統一モデリング言語） 第5章 オブジェクト指向原則 SOLID 第6章 テスト駆動開発 第7章 依存
第0章. なぜ Scala を使うのか？ はじめに 本稿は、John C. Mitchell 氏らによる Concepts in Programming Languages を基に自身の見解を交え、私がなぜ Scala を好んで使うのかを論じた記事になります。 プログラミング言語の歴史 本題に入る前に、プログラミング言語の歴史について紹介します。 年代 言語・イノベーション 1950 Fortran and Cobol 1960 Lisp and Algol 1970 Abstract data types (Simula, C, SQL) 1980 Objects (Smalltalk, C++) 1990 Java, JavaScript, Python, Ruby これは、年代ごとに開発された言語およびイノベーションを表にまとめたものになります。ただし、この表には欠けている事柄があり
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
ありがちな仕様とコードを題材に、よくないコードに立ち向かうための整理術を紹介します。 この Book にはデザインパターンや DDD やオニオンアーキテクチャや関数型プログラミングなどは一切登場しませんが、それらのエッセンスと日常のコーディングにおいて求められる基礎的な考え方の説明が含まれています。 この Book の内容は、特定の業務領域やプログラミング言語・フレームワークには限定されません。 Laravel でも RoR でも Spring でも React でも Nuxt.js でも、きっと役に立つはずです。 逆にこの本にはクラス設計のべき論や OOP vs FP のような議論は含まれません。 画一的なコードの良し悪しの定義は難しいですが、何かしら得るものがあったと感じてもらえたらうれしいです。
本スライドはオブジェクト指向プログラミング（OOP）を理解しているバックエンドエンジニアの方向けに、フロントエンドのコンポーネント指向を解説することで、フロントエンドを開発するための足がかりを作ることが狙いです。OOPとの違いを意識することで、フロントエンド特有の設計思考を身につけましょう。Reactと…
どうもoreoです。 今回はモダンなJavaScript開発環境で役立つデザインパターンを紹介します。 この記事は、JavaScript Patterns WorkshopとPatterns.devを参考にしています。 有名な「Java言語で学ぶデザインパターン入門」などでは、古典的な23個のデザインパターンが紹介されていますが、JavaScript Patterns WorkshopではPatterns.devをベースとして、モダンなJavaScriptにおける6つのデザインパターンについて言及されています。この記事ではそれらについてまとめてみたいと思います！ ※本記事中のコードは、JavaScript Patterns WorkshopとPatterns.devから引用させていただいております。 1 Design Patternsとは？ デザインパターンとは、ソフトウェア開発で繰り返し
ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に
はじめに 最近オブジェクト指向とデザインパターンについて学び始めたので、勉強しつつ記事にまとめていきたいと思います。 初回はSOLID原則についてです。SOLID原則はオブジェクト指向プログラミングにおいて、開発者にとって読みやすく、メンテナンスが可能なプログラムを作成しやすくするために考えられたルールです。 この記事では、オブジェクト指向プログラミングの重要な開発原則であるSOLID原則について皆さんが想像しやすいマリオのクラス実装を例に解説していきます。 1. S (Single Responsibility)：単一責任の原則 クラスは単一の責任を持つべきと言う原則です。 ここでの責任というのは、オブジェクトが持っている機能のことです。 一つのクラスができる機能（責任）が複数あると、クラス内部の関数が強い結合を起こす可能性が高ま理望ましくありません。 次のマリオクラスを見てみましょう。
DDDからOOPのプラクティスを学ぶのではなく、OOPのベストプラクティスをスタイルガイド本で学んでDDDに活かそう
それじゃあまりにも天才しかできないだろうということでニーモニックというのを持ったアセンブリ言語ができた 多分当時の人の中にあった議論は、こんなの1と0の羅列に名前つけただけだろ、なんかいいことあんの？という人たちと、まさにブレークスルーだ世界が変わるとエキサイトした人たちだろう。 色々あったが、人にも読めるソースをアセンブリ言語に変換してくれるCが出来た。 多分このときも単なるアセンブリのスーパーセットだろ？なんか意味あんのか？っていう人たちと、やばいレベルでプログラミング書きやすくなったとエキサイトする人たちに分かれたことだろう。 その後Javaが登場してオブジェクト指向が花開いた。 このときも、構造化プログラミングに毛が生えた程度のもんだろ？何が嬉しいんだ？という人と、オブジェクト指向なら何でもできる！とエキサイトした人たちで溢れかえったことだろう。 Java以降のIT界隈ではもはやオ
2022/5/14に開催されたTechFeed Conference 2022の5分LTでの登壇資料です
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 追記: 振り返りを書いてみました～ -- ここから元記事 別題: 抽象化って言葉もう。。 社内の記事にて、オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) | アラン・シャロウェイ, ジェームズ・R・トロット, 村上 雅章 |本 | 通販 | Amazonを紹介してもらいました。 取り上げられた、共通性／可変性分析の解説を見て、はっと思うことがありポエムを仕立てました。 共通性／可変性分析 共通性／可変性分析については、書籍を読むかググって頂けると良いですが、社内記事が良かったので引用させて頂きます。 問題
パンダとおくだが、Web業界の当たり前を「これって本当にそうだっけ？」と問い直すラジオを配信しています Value Object（値オブジェクト）は3種類あった Value Object（値オブジェクト） の意義と使い所がわからなかった。そこで調べてみたらなんと3種類あった。面白かったのでその調査過程を紹介する。 なお、現在では DDD の意味での Value Object がメインであること、またこれは自転車置き場の議論であり、DDD Quickly の Value Object の章を読む方が有意義であることを先に記しておく。 1. Data Transfer Object 1つ目は、Data Transfer Object（DTO）の意味だ。これは PoEAA に少しだけだけ出てくる。かつてのJava界隈の一部では（？）DTOのことを Value Object と呼んでいた。だが、現
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき
画像をウェブページの作成や資料作成用に編集する際は、「画像をリサイズ」「名前を変更」「フォルダを移動」などの複数の処理を行う必要があります。無料で公開されているソフトウェア「chaiNNer」を使えば、複数の処理内容を数珠つなぎにしてワンクリックで実行できるとのこと。日々の繰り返し作業が楽になりそうだったので、実際に使い方を確かめてみました。 GitHub - chaiNNer-org/chaiNNer https://github.com/chaiNNer-org/chaiNNer まずは、リリースページにアクセスしてchaiNNerのインストーラーをダウンロードします。今回はWindowsで使いたいので、「chaiNNer-0.14.2-x64-windows-setup.exe」をダウンロードしました。ファイルサイズは90.7MBです。 ダウンロードしたインストーラーをダブルクリック
列挙型、JavaでいうならEnum型、使っていますか。使わないわけにいきませんよね。 でも、Enumを使っていたせいで辛い目にあったことありませんか。ないですか。それならきっともうすぐに辛い目にあうと思います。 Enumはすべてのプログラマに等しく辛みを与えてくれるからです。そんな辛みについて、ちょっと一緒に直視してみましょう。 エムスリーエンジニアリンググループ、Unit1（製薬企業向けプラットフォームチーム）三浦(@[email protected]) [記事一覧 ]がお送りいたします、エムスリー Advent Calendar 2023の6日目です。 アプリケーションプログラミング上の辛み 1. 既存のif文が偶発的に意図しない方に倒れる 2. switch文に至っては「どちらでもない」で処理不発に アプリケーションプログラミング上の対策 1. 分岐条件をEnumに持たせる 2. swi
2023/5/10(水)に開催されたTechFeed Experts Night#18での登壇資料です。 https://techfeed.io/events/techfeed-experts-night-18
1- Backend API Service 2- Hosting Microservices 3- Backend and Frontend Service 4- CloudFront with Regional API Gateway 5- Backend and Frontend Service using Single CloudFront Distribution 6- Storage First 7- APIs hosted by the backend service and frontend content hosted in S3
Introduction Participation If you are interested in contributing to this book, check out the contribution guidelines. News 2024-03-17: You can now download the book in PDF format from this link. Design patterns In software development, we often come across problems that share similarities regardless of the environment they appear in. Although the implementation details are crucial to solve the tas
JSConf JP 2021 で登壇した資料です #jsconfjp #jsconfjp_b Links: [Active Recordから考える次の10年を見据えた技術選定](https://speakerdeck.com/yasaichi/architecture-decision-for-…
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」です
フロントエンド開発は一般的に複雑性との戦いです。放ったらかしにしておくとますます複雑になり、変更するのが難しくなります。これまでにも、このような複雑さをどうにかして制御しようとして、Atomic Designをはじめとした様々な設計手法（デザインパターン）が考えられてきました。 しかし、React / Next.js を使ってチーム開発を行う際に、現状のデザインパターンでの運用では「どうもうまくいかないな」と思う場面に多々遭遇しました。そのような経験を踏まえて、「コンポーネントをどのように設計するか」「どのようにディレクトリを分けるか」を徹底的に考え、新しいデザインパターン「Tree Design」にまとめました。 Tree Design はまだまだ仮説段階です。今後弊社チームで運用していく中でブラッシュアップする予定です。しかし、他のフロントエンド開発チームがデザインパターンを再考する際
DHHの Dependency injection is not a virtue(2013) という記事は有名ですが、ちゃんとした日本語訳が意外とないようなので、書き出してみて思ったことを要約してみた。[1] Rubyのエンジニアの中には、何も考えずに他のモデルのnewを書いてる人の割合が多いという（コードレビュー時のヒアリングによる）体感があり、また8年前の記事なので経験の浅い人は読んだことがない人もいると思う。該当する方は是非読んでほしい。 全部読む時間が無い人は要約へ. 原文と訳文 In languages less open than Ruby, hard-coded class references can make testing tough. If your Java code has Date date = new Date(); buried in its guts,
インスタンスとオブジェクトは混同しがちで区別がようわからんになりがちです。 とりあえず某所で説明したものを再構成します。 ※2022/12/10追記: クラスに対するのはインスタンスになるべき(たとえばクラス変数とインスタンス変数)なので、ちょっと修正するべきですが、このエントリはそのまま残してます。 クラス・インスタンス・オブジェクト クラスをインスタンス化(実体化)したものがオブジェクト(物)です。 実際に在るものはクラスとオブジェクトで、インスタンスはそれらの関係です。colorsやsportsが並んでるツリーが「オブジェクト」で、右のパレットに並んでるTreeが「クラス」、Treeからみたときのツリーが「インスタンス」ということになります。 ここでツリーはオブジェクトでもインスタンスでもあります。 このように、同じものをオブジェクトともインスタンスともいうことができるので混同してし
The content is based on Patterns.dev - a free online resource on design patterns and component patterns for building powerful web apps with vanilla JavaScript and React. The patterns covered on this website and in the workshop can guide you when facing a problem other developers have encountered many times before, but are not a blunt tool for jamming into every scenario. The goal is to raise aware
TL;DR データ指向プログラミング(DOP) とは、データとコードを分割してアプリケーションを設計・実装するプログラミングパラダイムのこと。 DOPの実装は、以下の原則に従う。 コードとデータを分離する 汎用的なデータ構造でデータを表現する データをイミュータブルなものとして扱う データスキーマとデータ表現を分離する 個人的にDOPは、バックエンドを宣言的プログラミングっぽく書くための現実的な解だと捉えています。実装の詳細は翔泳社より出版されている「データ指向プログラミング」をご覧ください。 はじめに こんにちは、株式会社CHILLNNという京都のスタートアップにてCTOを務めております永田と申します。 最近、エンジニアコミュニティでオブジェクト指向の定義に関する議論が行われているのを見かけます。Java育ちの自分にとって、オブジェクト指向の権威性を揺るがすような議論はかなり衝撃的だった
ソフトウェア開発者にとって、堅牢でテスト可能で拡張性があり、保守性の高いオブジェクト指向のソフトウェアシステムを設計することは重要です。 そこで登場するのがSOLID原則です。 SOLIDは、ソフトウェア開発中に生じるかもしれない特定の問題を解決するために5つの設計原則が組み合わさったセットです。 この記事では、SOLID設計の原則について詳しく学んでいきます。 具体的には、SOLID原則が何を意味しているのか、各部分がそれぞれ何を表しているのか、また実際のプログラム例を挙げながら現役のプログラマーが説明します。 さらに、JavaScriptを使ってこれらの原則を実装する方法も紹介します。 SOLID設計原則とは？ 単一責任原則 (SRP) Open/Closed原則 リスコフ置換原理 (LSP) インターフェース分離原則 (ISP) 依存関係逆転の原則 最後に SOLID設計原則とは？
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
