サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
自炊のコツ
blog.jnito.com
はじめに 僕は趣味でよくギター(エレキギター)を弾きます。 ですが、長年ずっと困っていたことがありました。 それはギターアンプのノイズです。 多かれ少なかれ、エレキギターを弾くときはアンプからノイズが出るものです。 しかし、僕の家のギターアンプからは明らかに異常な「キーン」というノイズが出ます。 実際どんな音なのかは以下の動画で確認できます。(うるさいのでボリュームには気を付けて!) www.youtube.com このノイズは以下のような特徴があります。 5〜6年前から急に発生し始めた 常時ノイズが出るわけではなく、たまに発生する ノイズが鳴り始めると鳴ったり止んだりを繰り返す ギターを変えても、アンプを変えても同じようにノイズが出る(なので、ギターやアンプの問題とは考えにくい) ギターを全くつないでいない状態でもノイズが出る(なので、ギターのピックアップがノイズを拾っているわけではない
はじめに 仕事用のMacを3年ぶりに買い換えました。MacBook Air M3 15インチ (2024)です。 ちなみに今まで使っていたのはMacBook Pro M1 13インチ (2020) でした。 なんで買い換えたの? 今まで使っていたM1 MacBook Proも大きな不満はなかったのですが、3年使ってきて「そろそろ買い換えてもいいかな?」と思っていたときに、M3チップ版のMacBook Airが発表されました。 www.apple.com M1→M2だとあまり変わらないかな?と思ってたのですが、M1→M3ならそれなりに速くなるんじゃないかと期待して「よし、買い換えよう!」と決めました。 (あ、ちなみに仕事用のMacは会社で購入してもらってます🙏) なんでAirなの?Proじゃないの? 仕事用で使うならAirじゃなくてProの方がいいのでは?と思う人もいるかもしれません。 僕
僕が翻訳しているRSpecの入門書「Everyday Rails - RSpecによるRailsテスト入門」は2014年2月に発売されました。 blog.jnito.com そう、発売からちょうど10年が経ったのです。 いつの間にか10年!僕も全然気付いていませんでした!! おかげさまで本書は何度となくアップデートを重ねつつ、RSpecの定番の入門書としてたくさんの人に読んでいただいています。 現時点での読者数はのべ6800人以上です。ご購入してくださったみなさん、本当にどうもありがとうございます! これまでの歴史 どういう流れで本書が翻訳され、現在に至ったのかを簡単にふりかえってみましょう。 2012年5月 原著「Everyday Rails Testing with RSpec」がLeanpubで発売 2013年10月 僕が原著を読み、その感想をブログに投稿 blog.jnito.co
お知らせ 僕が翻訳している電子書籍「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました🎉 すでに本書を購入されている方はLeanpubのサイトから最新版の電子書籍ファイルを無料でダウンロードできます。 https://leanpub.com/everydayrailsrspec-jp/leanpub.com 2024年版のアップデート内容 今回のアップデート内容は以下の通りです。 サンプルアプリケーションをRails 7.1 + Ruby 3.3 + rspec-rails 6.1で再作成 これに伴い、サンプルアプリのリポジトリURLも変更 新しいサンプルアプリのコードや挙動にあわせて、本書の記述を修正 リンク切れしていたいくつかのリンクを新しいURLに修正 Rails 7.1で作った新しいサンプルアプリケーションは以下のGitHubリポジトリ
はじめに:包丁が切れない! 僕は全然料理をしない(できない)んですが、妻は料理が大好きです。 しかし、包丁が切れないことに不満を持っていて、「包丁が切れない、新しい包丁が欲しい」とずっと嘆いていました。 もちろん、毎日使う道具なので新しい包丁を買うことぐらいは全然構わないのですが、新しい包丁を買う以外に、「包丁を自分で研ぐ」という選択肢もあります。 いや、いちおう簡易シャープナーはあるんですよ。こんなやつが。 グローバル スピードシャープナー GSS-01 グローバル(Global)Amazon しかし、妻曰く「シャープナーを使っても翌日には切れ味が落ちる」とのことです。 なので、シャープナーではなく、ダメ元でいいから砥石を使ってちゃんと自分で一度研いでみよう、という話になりました。 よし、YouTubeで勉強だ! 砥石で包丁なんて一度も研いだことがないのですが、とりあえずYouTubeで
はじめに 僕は自宅で長年WAKWAKというインターネットプロバイダを利用してたんですが、最近OCNに乗り換えました。 ・・・というだけなら「ふーん」で終わってしまうのですが、実は3ヶ月ぐらいかけて、 WAKWAK ↓ OCN ↓ BIGLOBE ↓ OCN とプロバイダを転々と切り替えながら、最終的にOCNを(しかもIPv6ではなくIPv4で)利用することに決めました。 このエントリではどういう経緯でこの結論に至ったのかを紹介します。 【もくじ】 はじめに 我が家のインターネット環境の紹介と、おことわり 用語の整理 困っていたこと:Amazon S3のファイルダウンロードが遅すぎる!! IPv6にしてもまだ遅い! iPhoneのテザリングだと夜でも3秒でダウンロードできるんですが? NTTの人が試しにOCNにつないだら、あれ?速い!! IPv4だと速いのに、IPv6だと遅いOCN・・・ 同
はじめに 前回のブログではWi-Fiの電波を安定させるためにルーターを壁掛けにした、という話を書きました。 blog.jnito.com 電波状況が改善したのは良かったのですが、それと引き換えに今まで使っていたNAS(Buffalo LS210D0201C)をつなげなくなってしまう、という問題が発生しました。 もちろん、壁付けしているWi-FiルーターにLANケーブルをつなげば引き続きNASが使えるのですが、配線がごちゃごちゃして美しくないのでそれはしたくないな〜と思いました。 このままNASを使うか、使わないか? ただ、NASの用途は非常に限定的で、家庭用に使っているMacBook AirのTimeMachineバックアップのストレージとして利用しているだけです。 加えて、MacBook Airはほぼインターネット専用マシンと化しているので、仕事用のMacとは違ってローカルストレージのフ
はじめに 最近Wi-FiルーターをNEC Aterm WX5400HPに買い換えました。 ルーターを買い換えたのはIPv6(正確にはIPv4 over IPv6)でインターネットができるようにするためです。 「IPv6にしたらネットが速くなるはずー😊」と思ったんですが、それ以前にルーターを買い換えてから妻や子どもたちから「ネットがよく切れる💢」「LINEがしょっちゅう送信エラーになる😡」と不満の声が上がりました(あらら)。 原因はよくわからないのですが、部屋の少し奥まった場所にWi-Fiルーターを置いてたので、「もしかして?」と思って試しに部屋の外にWi-Fiルーターを置いてみたところ、ネットの調子が良くなりました。 イメージ的にはこんな感じです。 以前使ってたASUSのWi-Fiルーター(RT-AC68U)だと部屋の中に置いてても問題なかったんですけどね。 ちなみにWi-Fiルータ
はじめに 先日、「コードが動かないので帰れません! 新人プログラマーのためのエラーが怖くなくなる本」という本が発売されることを知りました。 おお、これは気になる 👀 https://t.co/AVGT19OSQi— Junichi Ito (伊藤淳一) (@jnchito) 2023年9月6日 そしたらこの本の編集者さんが僕のツイートを見つけて「良かったらお送りしましょうか?」と連絡をくれたので、二つ返事で「はい!」と答えましたw というわけで、「コードが動かないので帰れません! 新人プログラマーのためのエラーが怖くなくなる本」を早々とゲット!わーい!😄 せっかく送っていただいたので、本書の簡単な紹介と感想を書いてみようと思います。 【もくじ】 はじめに 本書はどんな本? 本書の感想=プログラミング初心者の強くて優しい味方みたいな本! 薄い! 堅くない! 広く浅い! 本書にあえて注文を
はじめに 2023年9月9日に開催された大阪Ruby会議03で、基調講演(キーノート)を担当させてもらいました。 regional.rubykaigi.org 当日使った資料はこちらです。 発表のタイトルは"Enjoy Ruby programming, Enjoy Ruby community!"でした。 今回の基調講演ではちょっと攻めた取り組みとして、「Hotwireを使ったモーダルUIを15分で作る」というテーマでライブコーディングもしてみました。 www.youtube.com ライブコーディングには思わぬトラブル付きものですが、今回は何とかノートラブルで実装できました! 時間も15分以内(たぶん12〜13分ぐらい?)に収まりました〜😄 基調講演をするにあたって意識したこと 今回、基調講演を担当するにあたって「IT系カンファレンスの基調講演はどういうものであるべきか」を自分なりに
お知らせ 2023年9月9日(土)開催の大阪Ruby会議03で、僭越ながら基調講演をさせてもらうことになりました。 regional.rubykaigi.org 今回はめちゃくちゃ久しぶりのオフライン講演です! オフラインでお話しするのはたぶん2019年の富山Ruby会議以来ですね。 blog.jnito.com 大阪Ruby会議03のテーマは「Rubyで笑おう」です。 大阪で「笑い」と来たら、「もしかして漫才みたいな基調講演でも要求されるのか!?」と思いましたが、運営チームの人たちに確認したところ、「Rubyで幸せになってみんな笑顔になってほしい」という意味の「笑おう」らしいです。 2019年の大阪Ruby会議02から早4年。 長かったコロナ禍を乗り越え、大阪Ruby会議が復活します! 心の底から笑い合える日がまた来ることを願って、 今年のテーマは「Rubyで笑おう」としました。 Osa
お知らせ 僕が翻訳しているRSpecの入門本「Everyday Rails - RSpecによるRailsテスト入門」をアップデートしました。 leanpub.com 今回の変更点は以下の通りです。 Webdrivers gemがChrome 115以降をサポートしなくなったため、Webdriversの代わりにselenium-webdriverのChromeDriver自動ダウンロード機能を使うように本文の説明とサンプルコードを修正。(第6章および第10章) selenium-webdriverのChromeDriverの自動ダウンロード機能はRuby 3.0以上が必須であるため、本書の動作確認バージョンもRuby 3.0以上に変更。(第1章) GitHub上のサンプルコードも修正済みです。 github.com 今回のアップデートが必要になった背景についてはQiitaで説明しています。
はじめに 先日、こんなエントリを書きました。 blog.jnito.com 上の記事の中で、僕は「きれいなコードだけではすんなりコードが理解できないこともある」というような話を書きました。 もちろん、ある程度の規模になってくるといくらがんばっても「すんなり」では済まない場合も増えてくるけど、それでも最初に挙げた特徴を兼ね備えたコードとそうでないコードでは、開発効率に雲泥の差が出てくる。 僕が考える「良いコード」 - give IT a try きれいなコードを書くことはいつでも大事ですが、きれいなコード「だけ」では大きなコードを理解するのは難しいです。 そこできれいなコードを書くことに加えて、僕が意識しているコードを理解しやすくする工夫について書いてみようと思います。 ただし、ここで書く内容はあくまで僕が普段心がけていることです。 現場の文化やコードの規模や歴史、開発チームのスキルや人数、
こんなコードだとわかりやすい 僕が考える良いコードの特徴(条件)を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド(責務が1つしかないメソッド) DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
お知らせ レバテックLABさんの「キャリアを創る思考法」という連載コラムに「伊藤淳一氏が語る「僕の9年間の無名時代」。2023年版ITエンジニアの生存戦略【前編】」という記事を寄稿しました。 levtech.jp どんな話を書いたの? 僕を知ってる多くの人は「Ruby界隈で有名な伊藤さん」という認識かもしれませんが、僕はもともとJavaやC#をメインで使っていましたし、知名度が上がってきたのは現職のソニックガーデンに入社してからです。 それまでは僕も「完全に無名の、ただのエンジニア」でした。 とはいえ、無名エンジニア時代も自分なりに将来のキャリアを考えながら行動しており、もしかするとそれが今につながっているのかな〜という気もしています。 この寄稿記事ではそんな僕の「無名エンジニア時代」を振り返ってみました。 「まだまだ無名」と思ってる人にこそ読んでもらいたい この時代の僕を知ってる人はあま
注意:このエントリには性犯罪に関する話題が出てきます。苦手な方は閲覧を控えてください。 かなり昔の話なので、記憶があいまいな部分もありますが、覚えている範囲で書いていきます。 はじめに:僕はAくんと一緒に飛行機を見に行った これはたしか、僕が小学3年生、つまり9歳ぐらいだったときの話です。 僕は1977年生まれなので、たぶん1986年頃だと思います。 僕は大阪府豊中市で生まれ育ちました。 大阪国際空港(伊丹空港)がすぐ近くにあり、小さい頃から飛行機を見に行くのが好きでした。 そんなある日、同じクラスに転校生がやってきました。ここではその子をAくんと呼びます。 僕とAくんはすぐに仲良くなり、放課後によく一緒に遊びました。 僕は飛行機を見に行くのが好きだったので、「放課後、一緒に飛行機を見に行こう」とAくんを誘いました。 自転車を使えば5分か10分ぐらいで行ける場所です。*1 僕とAくんが遊び
「えっ、SQLite3ってこんな仕様なの!?」と最近ビックリしたことを紹介します。 たとえばこんな2つのテーブルがあったとします。 CREATE TABLE blogs ( id int primary key, title varchar(32) ); CREATE TABLE comments ( id int primary key, content varchar(32), blog_id int, foreign key (blog_id) references blogs(id) ); ポイントはcommentsテーブルのblog_idにはblogs(id)への外部キー制約が貼ってあることです。 もちろん、blog_idもblogs(id)も、どちらもint型です。 で、以下のようなSQLを発行します(blog_idの値に注目)。 -- blogsにデータを追加 INSERT
これはなに? 自動テストの初心者がテストコードを書くときに意識したことが方が良いことについて、僕が過去に書いた記事をまとめたものです。 RSpecでRailsのテストを書くケースがメインですが、自動テスト全般に役立つ知識も結構多いはずです。 <もくじ> これはなに? どんなテストを書けばいいのかわからない 可読性の高いテストを書きたい 不具合をちゃんと検知できるテストを書く RSpecの基本的な使い方を知りたい RSpecをもっと使いこなしたい MinitestとRSpec、どっちがいいの? MinitestをRSpecに書き直す 勉強会でみんなの悩みを聞いてみた まとめ どんなテストを書けばいいのかわからない 何をテストしたらいいの?どういうテストを書けばいいの?という基本事項をまとめています。 qiita.com バリデーションのテストって書くのは簡単ですが、本当に意味ある?っていう話
はじめに ちょっと前の話になりますが、今年の1月頃に妻が新型コロナにかかりました。 僕と息子と娘は去年の夏にコロナになったのですが、家族では妻だけがかからなかったので、「妻は無敵なんじゃないか」と話していましたが、第8波の大きな波からはさすがの妻も逃げ切れなかったようです……。 ちなみに去年の夏にコロナにかかった話はこちらにまとめています↓ blog.jnito.com で、我が家において妻がコロナにかかって自宅隔離になるというのは、かなりの痛手です。 なぜなら、家事の大半が妻に依存していたからです。 以前から「かよこ(妻の名前)がコロナになったらヤバいよな〜」という話は夫婦でときどきしてたんですが、ついにそのリスクが現実になってしまいました😱 というわけで、このエントリでは妻が戦線離脱して僕が一人で家事を回そうとしたときに初めてわかったことや感じたことをあれこれまとめてみます。 我が家
お知らせ エンジニアtypeさんでインタビュー取材を受けた記事が公開されました。 こちらの『若手エンジニアの成長を妨げる“受託脳”とは? 「受託開発でスキルアップできない」が大間違いな理由』というタイトルの記事です。 type.jp イントロダクションはこんな感じです。 「スピーディーに成長したいなら、受託開発より自社開発」そんなイメージから、受託開発を行う企業から自社開発企業への転職を目指す若手エンジニアは多いかもしれない。 だが、“チェリー本”の愛称でお馴染みの書籍『プロを目指す人のためのRuby入門』執筆者であり、ソニックガーデンのプログラマー・伊藤淳一さんと、同じくソニックガーデンで指折りのプログラミング力を誇る執行役員の遠藤大介さんは、その考えは「必ずしも正解とは言えない」と話す。 二人のエンジニアとしてのキャリアは15年以上。両者ともに、これまで受託開発の仕事を続けながら、現在
お知らせ Software Design 2023年3月号(現在発売中)の「ITエンジニアスキルアッププログラム」という特集に、「テクニカルスキルを磨く」という記事を寄稿しました。 どんな話が載ってるの? プログラマ・ITエンジニアとしてこれからどんどん成長していきたい初心者さん向けに、以下のような話を書きました。 技術をどう学ぶべきか プログラミング力以外にエンジニアとして必要とされるスキルは何か 学びをさらに深めるためには何をすべきか 勉強が苦しい・しんどい、と感じたときはどうすれば良いか etc スキルアップの方法についてはもっといろいろ書きたい内容があったのですが、限られた紙面なので「その中でも特に」と思う内容を厳選して記事にしています。それゆえ、結構「濃い」内容になっているので、「これからやってくぞ!」と思っているプログラマのみなさんにぜひ読んでいただきたいです。また、新人の指導
(この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました) 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト(TDD)で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする&機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO(プロダクトオーナー)に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
2023年2月3日に株式会社N2iさん主催の勉強会、Meets Professionalで「Qiita 1位のアウトプットの達人が語る、良質な技術記事を量産する秘訣」という発表をしてきました。 n2i-engineer.connpass.com 当日使ったスライドはこちらです。 講演の前半は「僕がなぜアウトプットするのか、なぜそれを続けられるのか」について、後半では「アウトプットが苦手なみなさんの背中を押す話」をしました。 また、講演が終わった後は参加者のみなさんからの質問に答えるQ&Aタイムもありました。 YouTubeでダイジェスト動画が公開されているので、当日見逃した方はこちらをどうぞ。 さらにログミーさんにて書き起こし記事も公開されています。 講演の後半に実施したQ&Aタイムの内容も書き起こしされていて、すごい充実度です! logmi.jp 全部4本あります。第2回以降の記事はこち
はじめに これは最近の話ではなく、去年の話なんですが、かなり大規模な自宅のリフォームをやりました。 リフォームしたおかげで雰囲気がガラッと変わって、すごく快適になりました。 本当は去年のうちにブログを書きたかったのですが、全然時間がなくてここまで伸びてしまいました(苦笑)。 まあ、ほとんど自宅自慢みたいなものですが、よかったら見てやってください。 トイレ(1階) 今回のリフォームでは水回りをリフォームしたいね、という話から始まりました。 なので、トイレとお風呂と洗面所がファーストターゲットでした。 1階のトイレはもともとこんな感じだったのですが・・・ こうなりました。 便器が浮いてるので掃除がラクです(ここは妻の強いこだわりポイント!)。 夜は床が柔らかく光るので、夜中トイレに起きてもまぶしくありません。 水栓は手を差し出したら自動的に水が出てくる自動水栓にしました(新型コロナ対策)。 ト
はじめに 先日、Twitter DMで以下のような相談を受けました。 突然のご連絡申し訳ございません。 僕は現在未経験でIT業界を目指そうか悩んでいるものです。 エンジニアについて調べていく中で伊藤さんの記事を読ませていただきました。 僕は高卒→飲食業勤務の24歳です。現在ITの学習は全くしておりません。 ですがIT業界に転職をしたいと思い、調べていくなかで未経験で入っても使いっぱしりのような形にされてしまってキャリアアップは狙えない、という記事を読んだりして怖くなってしまっている状況です。 もし可能でしたら実際に業界で活躍されてる伊藤さんに、本当の実態をお伺いできればと思い連絡させていただきました。 もし可能でしたら教えていただけるとありがたいです。 今回のエントリではこの相談のやりとりを質問者ご本人の許可を得た上で公開したいと思います。 僕の回答:身につけたスキルと選んだ会社によります
このブログ記事は動画バージョンがあります。動画で見たい方はこちらをどうぞ↓ www.youtube.com ちょっと前から「もやもや〜」と考えてることなんですが。 なんかここ数年、急にプログラマ(エンジニアと言われることが多いけど)の仕事が脚光を浴び始めた気がします。 「3K(笑)」から「お給料が良くて、自由に働ける、イケてる職業」に!? 僕がこの仕事を始めた頃(20年前)とか、ソニックガーデンに入社した頃(10年前)はまだ「プログラマ?おたくっぽい」「あー、3Kでしょ?きつい、帰れない、給料安いw」みたいな扱いだった気がします。少なくとも日本においては。 ところが、この5〜6年で急に「お給料が良くて、自由に働ける、イケてる職業」みたいなイメージに変わってきたんですよね。 それ自体はとてもいいことだと思うんですよ。自分の仕事が「3K(笑)」と馬鹿にされるより、「お給料がいい!自由!イケてる
はじめに ちょっと前に「「このバイブルに育てられた」駆け出しエンジニアだった頃に読み込んだ、学びの一冊をご紹介」というweb記事が話題になっていました。 type.jp たぶん、長年ITエンジニアをやっている人なら1冊か2冊はそういった「バイブル」があると思います。 そこでフィヨルドブートキャンプのメンターに「あなたが「このバイブルに育てられた」と思う一冊は何ですか?」という質問をしてみました。 なお、回答者はメンターだけでなく、アドバイザー(メンターではないが、受講生の学習状況を確認できる企業関係者)や卒業生も含まれています。 というわけで、以下がその回答です! 【もくじ】 はじめに メンターの伊藤淳一さん=「情熱プログラマー」 メンターのinoueさん=「リーダブルコード」か「アジャイルサムライ」 メンターのべーたさん=「猫でもわかるC#プログラミング」と「ノンデザイナーズ・デザインブ
フィヨルドブートキャンプのコードレビューでよく指摘してるシリーズです。 次のようなパンを焼くRubyプログラムがあります。 このプログラムはどういう工程を経てパンが焼かれるのか、ぱっと把握できますか? def main パンを焼く(粉, 水) end def パンを焼く(粉, 水) 焼く(パンを発酵させる(粉, 水)) end def パンを発酵させる(粉, 水) 発酵させる(パンを整形する(粉, 水)) end def パンを整形する(粉, 水) 整形する(パンをこねる(粉, 水)) end def パンをこねる(粉, 水) こねる(粉, 水) end main 上のプログラムは次のように書いても同じように処理されますが、工程の全体像がつかみやすいのはどちらでしょうか? def main 生地 = パンをこねる(粉, 水) 整形された生地 = パンを整形する(生地) 発酵した生地 = パ
はじめに みなさんもすでにご存じかもしれませんが、これまで無料で使えていたHerokuが有料化されます。 このあたりの話は以前、以下のエントリにまとめました。 blog.jnito.com そのときすでに「低額のEco DynoとPostgres Miniというプランが提供されるらしい」という話を書いていました。 ちょうど今朝、そのEco DynoとPostgres Miniが利用可能になったというアナウンスがあったので、さっそく移行してみました。 blog.heroku.com 移行の方法は結構簡単です。 上記の公式ブログを読むとだいたいわかると思いますが、このブログでも手順を解説しておきます。 免責事項 このエントリの手順や情報に何か致命的な間違いがあっても筆者は責任を取りません。 Herokuの公式ブログ・公式ヘルプの内容が正だという前提で読んでください。 その前に:Eco Dyno
次のページ
このページを最初にブックマークしてみませんか?
『give IT a try』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く