はてなブックマーク

今回もいっぱい売れましたねぇ...。 準備 きっかけ 今回は、「RubyKaigi 2025 で本屋を見て、楽しそうだった」という理由でお声掛けいただきました。ありがとうございます。もともと、Ruby 以外のイベントも勉強しに行きたかったので、大変ありがたかったです。 運営の皆様には、事前準備にもいろいろとご協力いただきました。この場を借りて御礼申し上げます。 オライリー様の本が多いだろうから、出版社に直販してもらったらどうか、など提案してはいたのですが、複数出版社に頼むのも大変だろうから、ということで、弊本屋にご依頼いただきました。 選書 選書は、SRE 関連の本をよく知らないので、だいたい運営の皆様や、声をかけた人にお任せしておりました。 SRE NEXT 2025/選書 - Google Sheets ご協力いただきました皆様にはありがとうございました。 基調講演のお二人の本「詳解

こう見ると、売れた冊数はだいたい開催規模に比例しているのがわかりますね。それはそう、って感じ。まぁ、たかだか4回なので、続けていくと傾向は変わりそうです(何度も出店してたらなかなか買わなくなるとか)。 準備 営業 今回は営業しました。ruby-jp Slack で「本屋さん要りませんか?」と聞いて、いいですね、と受け入れていただいた次第です。 選書 毎回、何か新しいことをやろうと思っていて、今回は選書を「オススメ本だけにする」ということにしました。私が欲しい本以外は、一切口を出さずに、参加者の方々からいただいたオススメの本だけ仕入れるというものです。 関西Ruby会議08/選書 - Google Sheets ご協力いただきました皆様にはありがとうございました。 仕入れ いつも出版社様から仕入れさせていただいております。新しい出版社様にお願いするときはいつもドキドキなんですが、今回はキーノ

ちょっと常軌を逸したジャンプがありますね。そんな感じでだいぶ規模が大きくなって、準備も大変でした。 前提 まず、いくつか前提を明記しておきます。 技術イベントで本屋をするのは、「そのイベントがより盛り上がってほしいから」であって、営利目的ではありません(see 本屋さんを開催する技術 / 動機 )。いや、お金は好きなので、増える分にはやぶさかではありません。 金銭的リスクはささだが負います。なので、赤にはしたくない。 ささだは RubyKaigi で登壇します(2回しました)。また、いくつか仕事がありました(そもそも勤務先の STORES の出張できている)。そのため、本屋店員をするのは難しそうでした。 準備 企画の提出 「本屋をやりたいんですがいいですか?」と運営に企画書を提出しました。 提出した企画書 RubyKaigi 2025 本屋企画の提案 本屋を趣味でやっているささだです。 R

本屋さんを開催する技術 の第2弾です。 2回目の本屋さんを東京Ruby会議12 で開催させていただきました。 Kaigi on Rails 2024 は2日開催でしたが、今回は 1日開催、長い休みが昼休み、休憩2回と、なかなか厳しい感じになりました。また、前回は "Ruby/Rails" 縛りという条件がありましたが、今回はなんでもよい、ということで、結果的に40点、合計99冊を持っていくことになりました。前回は16 点、65冊だったことを考えると、売り切るのはますます大変そうです。 結果として、66冊売れ、28冊返本し、5冊在庫として残りました。 準備 本の仕入れ 前述のとおり、「Ruby/Rails」縛りがなくなったため、選書をどうするか、という問題がありました。 結局、 笹田 東京Ruby会議12の運営・発表者 なんとなく声をかけた詳しそうな arton さん で行いました。また、セ

Kaigi on Rails 2024 で本屋さんを出店させていただきました。 やるよ、という宣伝記事: Kaigi on Rails 2024 で本屋さんをやります 本稿では、その振り返りを行います。 動機 動機は宣伝記事にあるように、「イベントを盛り上げるため」、そして「技術カンファレンスで本屋さんあるといいよね」という雰囲気を持っていただくことでした。自分が本屋さん好きなんですよね。知り合いがいなくて一人でも、本を眺めていると楽しい。同じ本を眺めている人と会話ができるとさらに楽しそう。 まぁ、あと若干の気分転換。 準備 書籍の仕入れ 本を売るためには本を仕入れないといけません。本を仕入れるにはいくつか手段があります(今回のためにいろいろ教えてもらいました)。 取次に売ってもらう 個人でもできるのは Foyer【ホワイエ】| 本の仕入販売サービス さん。 出版社に売ってもらう の2点が

研鑽Rubyの話 研鑽Ruby出ましたね。 レビューに参加させてもらってコメントさせてもらいました。主に実装周りと性能周り。本書についてはいくつか素敵な書評が出ているのであまり書きませんが、なるせさんが書いていた やりたいことに対していくつもの書き方がある "There is more than one way to do it" なRuby において、『研鑽Rubyプログラミング』はきっとまだ行くべき道を見定められない人の助けとなることでしょう。 という表現はまさに的を射た書評だと思います。Jeremy 流の書き方のご紹介。いろんな書き方を知るのは良い勉強になります。ただ、素直にすべて鵜呑みにするとまずそうな本だと思うので、自分や人の意見を確認しながら、批判的に読むと良いと思います。まぁ、どんな本でもそうかもしれませんが。 Ruby を研鑽した話 で、Rubyの性能に興味のあるパーソンと

Shopify の Ufuk さんが、Twitter で Shopify が Ruby 3.2 に成した貢献を連投されていたので、許可をえて訳したものをまとめておきます。誤訳などあればご指摘ください。なお、訳はDeepL さんの力を借りて行いました。というかだいたいそのまんまです。 いやぁ、スゴイ成果ですね。 Ruby 3.2 のクリスマスリリースが近づいているので、とても興奮しています。実際、3.2 には非常に多くの優れた機能があり、リリース日が待ちきれませんでしたが、われわれはすでに Shopify のお店のすべてのリクエストに対してデプロイしています。 すべての詳細について詳しく説明させてください🧵 訳注:棒グラフY軸が 0.9 から始まっているのに注意。See also: グラフの描き方 まず一番楽しみにしている機能はYJITです。Ruby 3.2のYJITは、プロダクションレデ

はじめに シェルスクリプトから jq コマンドを使う記事はいくつも見かけますが、あまりにも面倒でよくない書き方ばかりが見つかるのでベストプラクティスをまとめました。 この記事は「詳細解説 jqコマンドとシェルスクリプトの簡単で正しい使い方 〜 データの流れを制するUNIX哲学流シェルプログラミング」の要約版です。詳しい解説やもう少し高度な使い方を知りたい方、シェルスクリプトの考え方についてはリンク先を参照してください。リンク先は長すぎたので、こちらはとりあえず使いたい人用に簡潔にまとめました。(あと、いつも qiita を使っているので zenn を使ってみたかった) 👎 ダメな書き方 よく見かける書き方ですが、コードの見通しが悪く、メンテナンス性が低く、パフォーマンスが(かなり)悪く、特定の場合に不具合が発生する書き方です。 for item in $(jq -c '.items[]'

はじめに 物事を上達するためには反復を、というのはよく聞きますが、もちろんプログラミングでも大事なのかと思います。とくに自分は「一を聞いて十を知る」ような器用なことはできないので、何度も何度もプログラムを書いて、試していました。 このような反復を支援するためには、できるかぎり「書き始めるコスト」と「実行して確認するコスト」は低い方がいいと思っています。書き始めるのがだるいと、そもそも「ちょっと書いてみようかな」となかなか思わないですし、実行するための手数が多いと、「書いて→結果を確認」の回数が減ります。 本稿では、この「書き始めるコスト」と「実行して確認するコスト」を下げる私が20年くらい行っている工夫についてご紹介します。 筆者が Ruby が好きなので、Ruby の例が多いですが、別に Ruby に限った話ではありません。 プログラミング言語による違い たとえば、C 言語ですと、プログ

VSCode 用の拡張 Ruby's rstfilter extension をリリースしましたので宣伝です。 この拡張を使うと、 rstfilter を起動(Ctrl+Alt+S)するたびに、開いている Ruby スクリプトを保存して実行 各行に実行結果を表示(出力は下の OUTPUT に表示) マウスポインタをおくと式の結果を表示 という単純な機能です。ふつう、ちょっとずつ結果を確認するには、p/pp を書いたり、irb/pry/debugger などを使った REPL を使うのが一般的だと思うんですが、実行したり print を書いたりするアクションを一切せず、「保存」だけで結果を確認、しかも各行の結果がわかるのがウリです。 Ruby の結果を確認したい入門者の方 アプリやライブラリを書き始めた方 テストを書いている方 (ruby コマンドを実行するのも面倒な方) などに便利かもしれ