はてなブックマーク

ちょっと常軌を逸したジャンプがありますね。そんな感じでだいぶ規模が大きくなって、準備も大変でした。 前提 まず、いくつか前提を明記しておきます。 技術イベントで本屋をするのは、「そのイベントがより盛り上がってほしいから」であって、営利目的ではありません（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 コマンドを実行するのも面倒な方） などに便利かもしれ