サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
衆院選
karino2.github.io
最近、SNS向きでは無い話題、というのが随分増えたと思う。 自分はプログラミングの専門家と言って良いと思うのだけれど、 プログラムに関する間違った情報などは定期的にSNSで流れて来る。 そしてそうした事にいちいち反論するのはいかにも無駄な事に感じられてやる気がしない。 以前kzysもインターネットで誰かが間違っていることを気にしない - blog.8-p.infoと言っていたが、 同じような話だろう。 こうした事をSNSで反論していくのが無駄だ、という事に同意があるとして、 ではどうすべきか?と言えば、一専門家としては正しい事を発信するのが良い、と思う。 そうした事はSNS以外の場でやるのがいいんじゃないか。SNSでやると反論しているのと同じになってしまうので。 それをSNSでやるのと、例えばblogでやるのは同じではないか?という気もするが、これは違うと思う。 SNSでは、発言のコンテキ
インターネットでは、最近は個人の発言は自分の場所で行うのがメインになっているように思う。 昔は掲示板とホームページがあって、掲示板のようなものは共通の場所で何かを話し合って、ホームページとかで個人の場として何かを話していたと思うのだけれど、 前者がだいぶ減ってきている。今でもissueとかではそういうコミュニケーションがあるが、 そういうのは一部のプログラマしかしてない事に思う。 自分の場で自分の好きなように、良識の範囲内なら何を言っても良い、という安心感が、発言を促す結果、更新が多くなって、そうしたサービスに人が集まる、という事なんじゃないか。 自由に発言出来るのは良い事のようにも思うし、皆が発言する方がいい気はする。 ただ、インターネットのサービスが、いつも自分の場で発言する、という事を強めている結果、自分の無知さに対する謙虚さを持つのが難しくなっているように思う。 最近、ブランシャー
あおぞらAndroid教室でツアーとかGetting Startedとかリファレンスを読んでいけるようにする為に、 技術文書の読み方、というのを考えてみたい。 はじめに考えてる事 自分はあまり技術文書を何らかの手法に従って読んでいる訳で無く、またそうすべきともあまり思っていない。 好きに読んだらいいと思うし、自分の方法が何か特別優れていて人に伝えるべきだという気もしない。 一方で、大学とかに行ってないプログラム素人に技術文書を読ませると、 速度にも内容の消化具合にも大きく問題があり、そこには読み方の問題があるように見える。 だからプログラムを教える事の一貫として、技術文書の読み方を教える必要はあるようにも見える。 現実問題として明らかに遅さに問題があるので、なんとか出来るならしたい。 ライブラリやフレームワークや言語を学ぶのに技術文書を読む機会は多く、それら特有の特徴もいろいろあるので、
あおぞらAndroid教室でプログラム素人にプログラムを教えていると、 プログラムの解説を読むのがすごく遅い、という事に気づく。 自分にとってプログラムの本を読むのは娯楽なので、 あんまり早く読もうとはしていないし、 その結果として自分はプログラムの本を読むのがそんなに早くも無いと思っている。 だが、その自分と比較しても何倍も遅い。 なので自分(や普通のプログラマ)がプログラムの本を読む速度が早い理由を考えてみたくなった。 構造の予想と内容の予想 例えば今、【書籍】CppConcurrencyInActionを読んでいる。 けれど、読んでいる内容は文字の半分以下なんじゃないか。 普通のプログラマは、プログラムの本を全部は読んでないよな。 章のタイトルを見て、節のタイトルなどを見て、そこで何が書いてあるのかとかを予想して、 適当にパラパラ見つつサンプルコードとかはちょっと時間を掛けて見て、
以前podcastなどでも言ったが、最近友人知人を集めてAndroidアプリ開発を教えている。 最初は普段ダベってる友人が、今の仕事低賃金なのでAndroidのアプリ開発を覚えてプログラマになりたい、とか言ってきた。 年齢的には自分と近い年齢なのでそれなりに探す必要はあるだろうが、 まぁ探せばありそうだし、どのみちプログラムには興味あったのでやってみたい、との事。 普段カフェやファミレスでダベってるのをプログラム教えるのに変えるのは別にいいよ、と思ったので、やってみた。 で、共通の友人に「最近あいつにアプリ開発教えててさ〜」と言ったら「何それ、俺も習いたいんだけど?」とか言い出して、 別に二人でも三人でもあんま変わらんしいいぜ、と言って、これだとどこか市の施設とかでやる方がいいか、と探したら無料で使えてホワイトボードもある所があったので、 そこで教え始めた。 で、そんな話を親族にしてて、小
「karino2のあおぞらAndroid開発教室」のトップページです。 以下の再生リストのコンテンツと連動しています。 このコースは、基本的には以下の二つが交互に進む感じになっています。 Androidの勉強 kotlinというプログラム言語の勉強 Androidの方には「Android側」と記述してあります。区別が曖昧なものもありますが、目安にどうぞ。 AndroidStudioを触ってみる Android側 最初の一歩、TextViewとButtonを使ってみよう! Android側 EditText、チェックボックスなどを使ってみる この辺まで終わったら、プログラム言語の方の勉強を少しする方が良い。 プログラムをkotlinで学ぶ、前篇 ここから少しプログラム言語の勉強をする。 算数で挫折した人向けのJavaScript入門を6.3までやる 「算数で挫折した人向けの、JavaScri
空港で暇なので何か文章でも書こうという事で。 podcastなどでも度々話をしているが、ここ1年くらい掛けてお仕事で作っていた独自言語が割と使えるようになった。 リリースまでにはまだやる事がそれなりに残っているが、2年弱くらいで作ったとは言えそうだ。 これはコレクションからUnitTestのライブラリからパーサーから全て手作りで、結構大掛かりであり、実装の面でも色々な工夫が入っているし、 そもそもに実現しているものも、自分が作らなければ類似のものは無いくらいには新規性のあるものだ(独自言語なので当たり前だが)。 こういう、結構大きくて、自分が作らなければ世の中に無いものが、たった一人で生み出せる、というのは、結構凄いことだよなぁ。 一方で、2年くらい仕事でずっと一人で何かを作り続ければ、相当なものが作れる人は、世の中にはそれなりにたくさんいるんんじゃないか。 自分と同世代のプログラマの友人
宿に長期滞在している都合で、いろいろな仕事の人と話をする機会がある。 そうして思うのは、自分は割と意義のあると思える仕事をしているなぁ、という事。 これはプログラマという仕事の良い所なんじゃないか。 今やっている仕事は一発当てよう系の仕事で、当てられそうだという意味では無い。 当たらなければまぁみじめな失敗に終わると言えるし、 その結果はあまり意義のあるものでも無い。 だがやってみないと分からないと思えるような事はやれていて、 何度やっても箸にも棒にもかからないという感じでは無い。 これは標準的なプログラムの仕事の範疇と言って良いと思う。 特別凄い事でも無いが、特別恵まれてない事でも無い。 まぁ普通の範囲で多少恵まれている方かな、くらいか? 待遇や労働環境を考えると、普通くらいかもしれない。 だが、40代で何かアウトプットに意義を感じる仕事をするというのは、結構恵まれてるよなぁ。 自分のや
fsharp-lessonで抽象データ型を定義する段になり、 抽象データ型の解説をリンクしようとした所、 どうも良い解説が無い。 仕方ないので自分で解説を書く事にする。 この記事では抽象データ型、Abstract Data TypeをADTとも略します。 この記事は初心者向けの話なのでベテランは読む必要はありません。 データ型を考える 抽象データ型(Abstract Data Type)とは、 データ型の拡張と考えるのが良い。 抽象データ型を考えるには、まず抽象じゃないデータ型を見てみるのが良い。 という事で単なるデータ型を考えよう。 データ型というのは、ようするにintとかfloatとかの事です。 データ型というのは、それを使って変数を定義したりして、プログラムを書くのに使います。 int x = 0; int SomFunc(int b) { ... } float y = 0; fl
karino2の暇つぶしプログラム教室のF#編のページです。 理論上がりの人が機械学習屋になってPythonでとりあえずコードは書けるようになった、くらいの人で、 そろそろプログラムって奴を本格的にやってみるか、と思った人を対象に、karino2が暇つぶし程度にプログラムを教える、という事をやるサイトです。 機械学習屋になりたい人向けではなくて、すでになっている人に対してのプログラムの教室です。機械学習は扱いません。 姉妹サイト: karino2の暇つぶしプログラム教室 C言語編(通称c-lesson) モチベーションや背景など モチベーションとか背景とか 進め方 適当に課題をやってもらいつつgitterで質問に答えたり添削したりして、 たまに補足したり説明した方がいいと思う事は本を紹介したり説明をしたり動画を作ったりします。 とりあえず始める人はgitterで自己紹介くらい簡単にしてくれ
TeFWikiとは、ローカルのプレーンテキストのテキストファイルに、マークダウンとWikiLinkを使ったWikiです。名前の由来はTExt File WIKIから。 特徴 単一フォルダ内のプレーンテキストのみ、メタデータ無し markdown + 大かっこによるWikiLink (ex. [[何かのリンク]]) モダンなCSSによるレンダリング (bulma.css) スマホとPCのアプリ PC版webサーバー要らずの単独のアプリ(ElectronでMacとWindowsで動作確認済み) Android版はネイティブアプリ 共有手段は特に用意しないので、クラウドストレージのフォルダsyncのアプリを別途使う(自分はAutoSync for Google Driveを使っている) スクリーンショット PC版 Android版 ダウンロード 今の所、PC版(Mac, Windows)とAnd
緊急事態宣言が延長された時に、弁当も飽きてきたので新しい弁当屋とかを開拓しようとしていたら、高齢者向け配食サービスのポスターが貼ってあるのを見かける。 見ていたら、中の人にパンフを渡される。どうも配食のふれ愛という所らしい。 これを導入してみたら素晴らしく良かった上にいろいろ考えさせられた、という話。 システム 一食500円で弁当が送られてくる。最初に曜日と昼、夕のどれかを指定すると、毎週送られてくる、という仕組みで、 欲しい時に頼むような柔軟性は無い(前日までに頼めばキャンセルは出来るらしい)。 何故か日曜日だけは指定出来ずおやすみの模様。 祝日とかは平気。 なんか安すぎる気がするんだが… 高齢者向けというが、別に年齢制限は無いとのことなので、導入してみた。 自分は祝日含め、月〜土の昼、夕をすべて頼む事にした。 すると、毎日9:00〜10:00あたりに弁当を二つ持ってきてくれる。 弁当の
自分はF# での開発は、基本的にfsx上でM-Enterしながら開発している。 ちょっと動作を確認、とかじゃなくて、プロジェクトの最初から最後の直前までずっとfsx上からしか実行しない。 ビルドも動作確認目的でしかしない。めんどくさいので最後までProgram.fs書かない事もある。 普通emacsとかでスクリプト言語開発するとみんなこういうスタイルだろうからあまり言及する必要無いか?と思ったが、 jmukとkzysがF# 触ってみてるのを見て、一応簡単に自分がどう開発しているか、と、ちょっとしたワークアラウンド的な事も解説してみようかと思って書いてみる。 fsharp scriptとfsの関係とかもちょっと入門者にはわかりにくいし(自分も良く分かってない)。 前提条件: F# の開発環境 今のところMac Bookで書いてます。 .NET Core SDK VS Code VS Code
F# はOOPも出来るぜ、ってみんな言うし、WPFとかFormsとかASP.NETとかやる人にとってはそこらへんが全部ちゃんと書けるのがすごい重要なのも良く分かるのだが、 F# for Fun and Profitでも最初はOOPするなと言っているし、 実際自分も一ヶ月くらいF# で結構なコードを書いたが、一回もclassは定義していない。 .NETのライブラリを呼ぶのでnewしたりメソッドを呼んだりはするのだけれど。 という事で言うほどOOPしなくね?と思うのだった。 特にコマンドラインでの雑用をメインとする自分みたいな人はほとんどクラスを定義する事は無いんじゃないか。プログラムの規模が小さいという意味では無くて、intrusiveなライブラリを使わない、という意味で。 で、代わりに使うのは何か?と言えばmoduleだと思う。 moduleとは何か? moduleは何かと言うと、C++と
F#にはレコード型がある。レコード型はCの構造体みたいなものだが、 みたいなものという時にはいつも違いが重要になるもので、レコード型もその例に漏れない。 なお、F#に限らずMLにそもそもある概念だった気がするからML派生言語には全部ある気もするが、あんま詳しくないのでF#の話をする。 レコード型は基本はimmutableで変更は出来ない。代わりに部分更新したオブジェクトを新しく作れる。 この辺は最近のJSにも入っているので良くある概念と思う。 さらにハッシュ値とかequalityとか使いそうなものは勝手に生成される。そういうもの。 kotlinのdataクラスとかも似ているが、向こうはvarも指定出来るところはちょっと違う。 ただ基本的な考え方は同じものだ。実際dataクラスも全部valにする事が多くて、実質同じ使い方をする。 という事でここではkotlinのdataクラスも含めてレコード
PCとスマホでメモを共有したくていろいろ渡り歩いたが、どれも気に食わないので自分で作る事にした。 GooglePlay: てきすとでっき 個人的には究極のメモアプリが出来たんじゃないかと思っている。 以下背景として考えている思想的な事などを。 追記: PC版も作った github: electron-textdeck 追記: ローカルのファイルを指定してsyncする方が良さそう GoogleDriveのファイルを直接指定すると、以前は割と長いことそのurlが使えたのだけれど、2021-09-03現在、数日単位で無効になるように変更されたっぽい。 SO: Persisted SAF URI from Google Drive changes after a few days, content is unreachable という事でローカルのファイルを指定して、Google DriveとはA
以前MacとWindowsの両方で使う雑用コマンドライン言語にF#はどうだろう?などと書いたように、F#を使ってみているが、なかなか良くて気に入った。 VS Codeでの開発環境が良い まずVS Code+Ionideが良く出来ている。 インテリセンスは早いし書いてる途中のエラーもガンガン見つけてくれる。 文法的な間違いもツールチップでだいたい解決していけて、 使いながら学習していける感じがある。 以前試したgolangのLSより断然良く出来ている(最近のgolangは良くなってるかもしれないが)。 .NET Coreのインストールも特に手間取らずあっさり出来るし、 環境設定もハマらない。良い。 MacでもWindowsでも特に問題なく使える。 こういうのはMSは良い仕事をするね。Javaよりずっとわかりやすい。 環境が割と成熟していてセットアップとかのストレスが無いのが良い。 言語周辺の
在宅勤務などでリモートでやりとりする事が増えた結果、これまであまりチャットをやっていない人とテキストでチャットをする機会が増えた。 自分はまぁまぁチャットをしてきた方だと思うので、自分的に気をつけた方が良いと思う事を書いてみる。 不慣れなせいで不要にテレカンなどをしたがるのはなくしたいな、という動機。 ようするに、原則としては待たないでバンバン送ってあとから訂正する、というのが結論なのだが、それをもう少し具体的に。 時間をあわせると良い場合(今回のお題) テキストのチャットの良い所には時間をあわせなくても出来る、という所があるが、時間をあわせてはいけない、という訳でも無い。 リアルタイム性の高いやりとりをしたい場合は、時間をあわせて行う方がいい。この時は時間をあらかじめ決める方が良い。 始める時間だけでなく終わる時間も目安程度で良いので決めた方が良い。 リアルタイム性の高いやりとりをしたい
ブログを書き続けるのは、ある種の能力を必要とする。 才能とか技能という程凄い何かでは無いと思うけれど、続けられない人というのは確かに居るし、それは最初の段階でなんとなく分かる。 ただ今となってはどちらかといえばロートルなメディアなので、能力というよりはタバコを吸うかどうか、みたいな物かもしれない。 とにかく。ブログを書く能力、みたいな話はweb日記とかが流行ってた頃はしていた気もするが、昨今はブログ自体がすたれているので、それをやる能力なんて話をみかける事は無くなった気がする。 ブログを続けるには、一つの記事の書くコストを上げすぎない必要がある。 コストを上げすぎない為にはいろいろと方法があると思うが、自分的に重要なのは、出来の悪い文章を受け入れる、という事。 もう一回見直せばもうちょっと良くなる時でも、そのもう一回の見直しをやらない。 結果として多少出来は悪いが、その分の労力を次の記事に
みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して
はじめに このkotlin lessonではhttpにはfuelを使ってもらっている。 だからコルーチンというかawaitResponseResultとかを使ってもらっている。 で、コルーチンの解説なんて死ぬほどあるだろうから適当にググって適当に書いてください、と言った所、皆なんか全然分かってない感じのコードを書いてくる。 何故だ?解説とかあるだろ?と思って自分でもググってみると、「確かにこれじゃ入門者は使えないな…」というのばかり。 という事で、あまり分かってない人がとりあえず使うのに必要となる事だけを解説してみます。 hello worldとかでは無くて、そういうのを動かした後に読む文書です。 この文書を書こうと思ったきっかけ こんなコードが来ました(多少解説の為に変更しています)。 詳細はいいとして、putContentInnnerはsuspend関数で中にawaitResponse
プログラムの入門としての抽象化の話をします。ベテラン向けじゃないんで、ベテランの人は読んでも新しい事は無いと思います。 データ分析界隈だと、数学や物理などで抽象的な事というのには良く出会ってきた経験を持つので、抽象的な物は得意な方だ、という人は多いと思うし、実際そうだと思う。 ただ、プログラムの抽象化は違う部分もあるので、一度プログラムの抽象化という物を初心者の気持ちになって学んでみる機会は必要とも思う。 ここではそんな話をしてみる。 カプセル化 プログラムの抽象化と言えばカプセル化なのだが、いまいち良い解説が無いので自分で書く事にする。 一般的な事は知らないけれど、プログラムにおいては、抽象化の定義は「情報を落とす」事となっている。 全ての情報を持っている所から、特定の情報だけにする事でアクセスする「口」を定める訳だ。 だからだいたいの抽象化は物を「削る」のだけど、一つだけ例外がある そ
前から書こうと思っていた、ALPを支える技術の感想です。二ヶ月くらい遅れですが(^^; まず本題の前にこのシリーズの感想から。 なかなか面白かった。 主義主張には同意しかねる部分は多いけれど(特にTizenやWindows Mobileが駄目だったからただリリースしても駄目だった、という結論)、結局どちらが正しいかを知る方法は無いので、多様な意見という事なのでしょう。 このシリーズで面白いな、と思ったのは、第三期では内部の人が意外と意義とか面白さを持ってやっていたように見える所。 これは結構意外でした。 もっと「俺は全然駄目だと思ってたけど仕方なかったんだ」みたいな内容になるのかと思っていたので、中は中でいろいろあったんだろうなぁ、と。 外から見ると一期も二期も三期もなくずっとぐずぐずやってて何も出ない、という印象だったのだけど、結構違いはあるんですね。 実際たけしさんは5年くらいやってた
以前Tensorflowの本を探してた事を覚えてた編集さんが、「最近Tensorflowの本を出したので良かったら読んで見てください」と言って献本してもらった本。 今の自分がTensorflowについて学べる本がこの世に存在するとは思えないのだけれど、この本の評判は機械学習の本としてそこそこ良さそうで、ちょっと気になっては居た。 今年前半は小難しい本を読んでばかり居たのでここらで息抜きに軽く普通の本も読みたいと思ってた所なので、読んで見る事にする。 なお、私はたぶんそもそもに対象読者じゃない気がするので、このブログのポストを読む時はそのへんは差し引いてください。 開幕の前提にいまいち同意出来ない この本は、プログラマのツールボックスに新しく機械学習を追加しよう、という前提で書かれている。 でもこの前提がもはや成立しないんじゃないか。 これは機械学習を、まるでサービス開発の一手法として必要に
karino2の暇つぶしプログラム教室のC言語編のページです。 C言語の入門書くらいは読んだがそこから先が良くわからん、という人向けに、 暇つぶし程度に教える、という事をやるサイトです。 あらすじ twitterでプログラム教えてもいいって言ったら教えてほしいという人がいたので教える事にする。 少し話を聞いたところ、 まずはC言語でちゃんとプログラム書く事を教えてほしい C言語の本などは読んでいて、ArduinoやRasbherryPiなどの経験はちょっとある 大学院生だがCS系の専攻では無い という感じらしい。 進め方 適当に課題をやってもらいつつgitterで質問に答えたり添削したりして、 たまに補足したり説明した方がいいと思う事は本を紹介したり説明をしたり動画を作ったりします。 とりあえず始める人はgitterで自己紹介くらい簡単にしてくれると嬉しいです。 課題は https://g
第一回 簡易PostScriptインタプリタを作ろう やる事 ハッシュ、線形リスト、スタックの実装 簡単なインタープリタの実装 言語はPostScriptのサブセット 実行可能配列(関数リテラル相当)、ifelse、repeatくらいまで 3000行くらい。 PostScriptのサブセットを実装してみたいと思います。 最初はForthを実装しようとしたのですが、制御構造の実装がやや面倒なので、 その辺がよりシンプルで美しいPostScriptに変更します。(その歴史的な理由でフォルダ名などはforth_modokiになっています。すみません)。 PostScriptは触るとすぐわかるけど説明するとややこしい言語仕様なので、作りながら言語仕様自体の説明はしていきます。 なお、PostScriptは全く知らなくてもOKです。 この回の狙い 簡単なパーサーの書き方を学ぶ 言語の処理系を実装する
第一回でそれなりの規模のCプログラムを書いて標準的なデータ構造を学びました。 第二回はQEMUを使ってARMのバイナリを動かしたり、バイナリを生成したりディスアセンブルしたりするコードを書きます。 OSの無い環境でプログラムを動かす事で、C言語の土台の理解を深める事を目的とします。 QEMUのベアメタル環境を使えるようになる nm, readelf, objcopy, objdumpなどのコマンドに慣れ親しむ 簡単なARMのアセンブリを理解する 簡単なアセンブラとディスアセンブラを作る Cコンパイラの吐くアセンブリ言語を調べる事でC言語の理解を深める(これは第三回にしました) 何故アセンブラと逆アセンブラを作るのか? C言語を勉強しよう、という時に、なんだか関係ない別の言語に見えるアセンブラ言語を学ぼうというのは「なんでよ!?」と思うかもしれません。 そこでここではまず、今回QEMUを使っ
去年の4月くらいから、論文を読む事が出来るようになった、という気がしている。 もう一年以上前の話なんだが。なんとなくその事をブログに書いてなかったな、と思ったので、ここに書いておく。 論文を読む、というのは、みんなやっている、と主張はするものだ。 ちゃんと理解できているかは怪しいものだが、 一方でその区別もそんなにはっきりとはしていないので、 誰が論文は読めて誰が読めてないのかもよく分からない。 論文の分野にもよるからますます一概には言えない。 ただ、機械学習の仕事では論文を読むのは重要な日常業務の一つで、 この能力が明らかに不足している人というのはかなり居る。 明確な境界を決めるのは無理だけれど、明らかに足りてない場合は明白に分かるし、皆が言う程はこの能力は簡単な物では無い。 実際、自分も2015年ころには、この論文を読む能力が低くて困っていた。 2017年の4月頃には読めるようになった
GoodfellowのDeep Learningという本を、5/20から読んでいて、6/28現在、無事読み終わった。 関連論文なども大量に読まないと理解出来ないように書かれている、ある意味イジワルな本なのでかなり大変だったが、得る物も大きかった。 せっかくなので全体的な感想を書きたい。 関連エントリ GoodfellowのDeepLearning本を読む 読んでる間の計算とかメモ、感想など(膨大) 9章まで読んだ段階の、Goodfellow本の感想 上記の1は、日本で一番長くGoodfellow本について何か書いた物になってると思う。世界でも一番じゃないか?それはさすがに無いか? この本は、単体ではわざと分からないように書かれている 最初に強調したい所はここ。 この本は一見すると線形代数とか確率論とかback propagationとか解説しているので、他の本を参照しなくても一通り分かるよ
次のページ
このページを最初にブックマークしてみませんか?
『なーんだ、ただの水たまりじゃないか』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く