RubyKaigi 2024に参加できて本当に良かった - joker1007’s diary
RubyKaigi 2024に参加してきました。 今回参加までに紆余曲折あったので、一時は参加を諦めていたんですが、何とか無事参加することが出来ました。 2011年に初参加して以来休まず参加していたので、ついに連続参加が途絶えるのかと思ってましたが、無事連続参加を達成できて嬉しい限りです。 今回はそういう事情もあってか、コミュニティとの繋がりを強く感じることができたRubyKaigiでした。 色々思いが溢れてしまって、技術的に楽しかったこと、自分が嬉しかったこと、参加前の事情とか全部書いてたらえらい分量になってしまいました。気が向いたら目に付いたところだけ読んでくださいw 参加前 そもそも何があったかというと、大体去年の12月ぐらいから咳が止まらなくなり、更に年明けぐらいに高熱が出た上で咳が出続けている状態でした。 余りに咳が酷かったので、喉に傷が付いた後胃酸が逆流したりして声帯の近くに潰
偏りに満ちたWayland時代のLinux Desktopおすすめアプリ 2024 - joker1007’s diary
最近、wayland移行も大分安定して、デスクトップで利用するアプリも多少変化したので、最近利用しているものをまとめておこうと思う。 基本的にGNONEやKDE Plasmaみたいな重厚なデスクトップ環境は使わないタイプなので、そういうラインナップになっている。 開発で必須、みたいなやつはこの記事には余り入れてない。 ウインドウマネージャー Hyprland waylandで動作するタイル型ウインドウマネージャー。ヌルヌル動くのが気持ち良いだけでなく、機能的にもよく出来ている。開発が活発なのも良い。 waylandで画面共有のために利用されるxdg-desktop-portalのために独自実装を持っていてswayでは出来なかったウインドウ単位の画面共有が出来る。 という訳でwaylandのタイル型ウインドウマネージャーといえばswayがメジャーだが、最近はHyprlandを利用している。
20年Rubyを触ってきて初めて踏んだattr_readerのケツカンマ問題、あるいはdefの返り値がシンボルであることの問題 - joker1007’s diary
今日Rubyを書いていて、なんじゃこれと思った動作があった。 試しに以下のコードを実行してみて欲しい。 class Foo attr_reader :hoge, :fuga, def initialize(a, b) p a p b end end Foo.new 実行してみると分かるが、これには例外が出ない。 initializeで定義した必須引数はどうなったのか？ よくよく見るとattr_readerの引数の末尾に,がある。 つまり、このコードは分かりやすく書くと以下の様になる。 class Foo attr_reader(:hoge, :fuga, def initialize(a, b) p a p b end) end Foo.new このコードを更に分かり易く書くとこうなる。 class Foo def initialize(a, b) p a p b end attr_rea
rbsのtree-sitterパーサを書いて、neovimのシンタックスハイライトに利用する - joker1007’s diary
皆さん型書いてますか？私はそもそもRubyを書いていません！ とはいえ、最近Kaigi on RailsやRubyWorldとカンファレンスが続いていたので、ちょっとやる気を出してrbsを書くためのエコシステムに貢献しようと思い、rbs用のtree-sitterパーサを書いてみました。パーサ流行ってますからね。 github.com READMEにしたがってnvim-treesitterでパーサをインストールし、このリポジトリをneovimプラグインとしてインストールすれば、rbsのシンタックスハイライトがイカした感じになります。 しかし、しかしながらですね、これ半年ぐらい前に調べた時には誰も書いてなかったんですが、8割ぐらい書いた所で、既に別のtree-sitter-rbsがあることに気付いたんですよね……。 github.com まあ、せっかく作ったんで完全に同じ車輪の再発明だろうが、
Railsで秒間1000コミットを捌くにはどうすればいいのか (Kaigi on Railsのフリースペースより) - joker1007’s diary
先日のKaigi on Rails中の雑談として @ima1zumi さんから、RDBに対して秒間1000コミットぐらいで処理が詰まってる場合ってどうするのが良いのか、という質問を受けまして、雑談の中で色々答えてたんですが、せっかくだから記事にまとめておこうと思います。 ちょっとしたKaigi Effectって感じですね。 今回のKaigi on Railsのトークの中では、 数十億のレコードを持つ5年目サービスの設計と障害解決 by KNR - Kaigi on Rails 2023 の話なんかは割と関連がありますね。ユーザーの行動履歴というのは、ユーザー数 * N * タイムスパンで増えていくレコードなので、書き込みとデータ量が爆発しがちです。トランザクションで堅牢に処理しなければいけないケースもそこまで多くないので、RDBだと書き込みに対する処理が過剰なケースが多い。実際のところこの
RubyKaigi 2023 参加報告とちょっとエモい話 - joker1007’s diary
RubyKaigi 2023に参加してきました。 今回は長野県の松本での開催でした。 全体的な感想 今回は、会場のスポンサーブースの数や来場者が去年より格段に多く、かつてのRubyKaigiが戻ってきたことを強く感じました。 4, 5年ぶりぐらいに会う人も沢山居て、会う人会う人に「うおー、久しぶりです！」って言って回ってた気がします。 久しぶりに会う人と直接近況をやり取りできるのは、とても嬉しいことですね。 自分はあんまり写真撮らないタイプなのですが(食べ物と酒は除く)、今回は割と多くの #rubyfriends 写真を撮った気がする。 それぐらいはしゃいでいたと言えるのかもしれない。 (撮った写真を了解無く上げるのは、ちょっと気になったので写真は割愛) とにかく、色々な人にまた会えたのが嬉しかった。そういうRubyKaigiでした。 セッションについて 今回は、パーサー周りのトークが妙に
rubygem開発でSteepを使って型を書く時の現状のオススメ設定 (2023年3月版) - joker1007’s diary
Rails(というかActiveRecord)に型を付けるのは大変だが、Railsが絡まないrubygemにはそんなに苦労なく型が書けるので、これからgemを書く時には型を書きたいという人向けに今のところオススメの設定を紹介します。 というか自分が忘れるのでまとめておきます。 現状とはsteep-1.3.1, rbs-2.8.4を指します。 rbsは既に3系が出ていますが、一般利用者が型検査に利用する場合はsteepを使うはずで、steepはまだrbsの3系に対応していません。また、rbs-3.0で多少変わっているところもあるので、割と寿命が短い話かもしれません。 設定例 とりあえず結論から。Steepfileとrbs_collection.yamlを修正します。 Steepfile: D = Steep::Diagnostic target :lib do signature "sig"
ソフトウェアエンジニアとしての能力を高める方法について考えてみた - joker1007’s diary
早朝の寝る前ぐらいの時間にぼやっと下記の様なツイートしたらちょっと反応を貰ったので、取り留めは無いが自分なりに考えていることを書いてみる。 人を育てるのも仕事の内というのは完全にその通りなんだが、そこにドキュメントや本があるから読みます、触って作ってみます、生きたコードを読みます、以外に学ぶ方法なんかねえし、知らねえよ。ただやればいいだけの事に説明も何も無いんだよな……。マジ分からん……。— joker1007 (アルフォートおじさん) (@joker1007) March 2, 2023 タイトルは雑に書いたけど、能力を高めるというと範囲が広過ぎるので、技術的な意味でできる事が増える、ということをテーマとして話をしていこうと思う。基本的に自分の考え方の話なのでそこは御留意ください。 ツイートした通りで、状況や対象に依って割合は変わるかもしれないが基本的にそのためにやることは3つしかないと
RubyKaigi 2022に現地参加してきた - joker1007’s diary
今回、3年ぶりにオフライン開催されたRubyKaigi 2022に参加するために津まで行ってきました。今回はスポンサーでもスピーカーでもなく完全な一般参加者です。 （自分のTwitterは飯テロの画像なども含むため、センシティブなものを含む可能性があるチェックを付けているので画像を見る場合は自分で開いてくださいw) rubykaigi始まったわー。 pic.twitter.com/6B83FUwqh6— joker1007 (アルフォートおじさん) (@joker1007) September 7, 2022 カニミソ美味い。 pic.twitter.com/a7JT8NvkMO— joker1007 (アルフォートおじさん) (@joker1007) September 7, 2022 久しぶりにオフラインの大きなイベントに参加し、3年以上ぶりにRubyコミュニティの皆と再開しました。皆
Kafka入門 第1回 「そもそもKafkaとはなにか」 - joker1007’s diary
これは社内向けに書いた、Kafkaってそもそも何やねん、ということをメンバーに解説するための記事を一部編集して公開できる様にしたものです。 第2回以降では、Kafkaを利用したアプリケーション開発のノウハウについて解説していく予定です。そちらも社内の事情を除いた形で公開していくつもりです。 そもそもKafkaとは Kafkaはイベントストリーミングプラットフォームと呼ばれるミドルウェアです。 元々はストリームバッファと呼ばれてたと思います。 公式のドキュメントには以下の様に書かれています。 Kafka combines three key capabilities so you can implement your use cases for event streaming end-to-end with a single battle-tested solution: To publis
Kafka Streamsを本番運用する時に検討しておくべきconfigの設定値について - joker1007’s diary
Kafka Streamsをそれなりのデータ規模で運用していくとデフォルトの設定値では動作に困るケースがしばしば出てきます。 その中でも気にしておいた方がいい設定値について紹介していきます。 acceptable.recovery.lag これはあるタスクにおいてStateStoreとchangelogトピックのlagのどこまでを追い付いていると許容するかどうかを設定します。 デフォルト値は10000なんですが、KTableとかで外部からデータが放り込まれていてそれが結構なデータ量だと10000とか一瞬で越えてしまって、一瞬プロセスを再起動しただけでも追い付いていない、みたいな扱いになってrebalanceが即座に走ってしまう挙動になりました。 実際にデータが入ってくるペースを考慮した値に設定しておかないと、プロセスを再起動した際に余計なrebalanceやレストアが走って無駄な停止時間が
最近のjoker1007 - joker1007’s diary
Rubyist近況[1] Advent Calendar 17日目です。 仕事的な近況 最近、仕事で全然Rubyを書かなくなってきた。たまにRailsアプリの改修作業をやる程度で、今年書いた量で言うなら間違いなくJavaが一番多いだろう。 直近で書いたブログ記事を参照してもらえると分かり易いが、ここ1年ぐらいの自分の主戦場はKafkaとストリームプロセッサである。 Kafkaは非常に便利なミドルウェアだがメッセージキューの様でメッセージキューでなく、分散ストレージとして動作するがブローカー自体は余り分散の仕組みをコントロールする訳でもなく、クライアントライブラリ側で色々制御する様な仕組みになっているので、どういう活用の仕方をするものなのかイマイチ理解しづらい難しいミドルウェアでもある。 自分は完全に0から考えて必要だと思って調査してほとんどの仕組みを勝手に作ってしまったので性質も活用方法も
Kafkaに接続するJavaアプリケーションをGravitonインスタンスへ移行してパフォーマンスを改善する - joker1007’s diary
社内向けのドキュメントと兼用したので、前提とかメンバー向けの解説が含まれているので、前後のパフォーマンスの変化だけを見たい人は、下の方のグラフ画像までスクロールしてください。 gravitonインスタンスを活用するモチベーション ワークロードによる相性はあるが、特にマルチスレッド性能で既存のインスタンスより性能向上が見られる上にコストが安いため、うまくフィットすれば性能改善とコスト削減の双方でメリットがある。 また、周辺ハードウェアもアップデートされているため、エフェメラルストレージ付きのインスタンスのストレージサイズが増えているなどのメリットもある。 特に現時点ではr6gdインスタンスが利用したかった。 gravitonインスタンスを利用するためarm64アーキテクチャへの対応 gravitonインスタンスはarm64 (aarch64) アーキテクチャのCPUのため、既存のx86_64
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です
パーフェクトRails 増補改訂版の自身の担当分について - joker1007’s diary
長らく改訂版をお待たせしていたパーフェクトRailsがついに新しくなります。 私は、やはり人間は締切が近くならないと働かない、という極めて重要な事実を改めて学ぶことができたのが良かったと思っています。 そろそろ献本させていただいた本は届き始めている様で、ブログやTwitter等で紹介していただけて嬉しい限りです。 全体の解説や紹介はそちらに任せるとして、私は今回担当していた箇所が大きく変わったので、それについての感想や裏話を書こうかと思います。 前回担当していた箇所 前回は、基本的に終盤のRailsの基本機能を越えたアプリケーションを作る時に助けになる章を担当していました。 元々は、そういう仕事としてRailsアプリケーションを書く上で気にしておきたいこと、というのが書かれた本が余り無く、何とかそういう本を作りたいという思いがあったので、あの辺りの章を担当させてもらいました。 正解の無い部
RubyKaigi 2019で登壇してきました #rubykaigi - joker1007’s diary
4/18 - 4/20で開催されていたRubyKaigi 2019に参加し登壇してきました。 今回の登壇内容は「Pragmatic Monadic Programming in Ruby」というタイトルです。 スライドは以下。 speakerdeck.com 実装はこちらです。READMEの整備が全然出来てないのと、APIがまだ変わる可能性があるので、gemとして正式リリースするのはまだやってないのですが、近々ちゃんとリリースします。 github.com Ruby黒魔術師として、自分が良いなと思っているデザインパターンであるモナドを、Rubyの世界で理想的に表現するならどうなるかということを考えて発表テーマとしました。 今回、ASTがRubyレベルから簡単に触れる様になったので、それを活用してみたかったというのもあります。 内容としてはAST変換を駆使して、あるパターンの変数代入構文を乗
RubyConf 2018に登壇するためにL.Aまで行ってきた - joker1007’s diary
RubyConf 2018のRubyKaigi関連トラックに採択されたので、登壇するためにロサンゼルスまで行ってきました。 RubyKaigiトラックということで、内容はRubyKaigiの再演でした。 学生の時にめっちゃ貧乏だったのもあって、今迄海外に行く機会が全く無かったので、実はこれが初の海外旅行であり、当然ながら英語で発表するのも初めてだったので大分緊張しましたが、本番ではそれなりにウケたという手応えがあったので、今迄の登壇経験が上手いこと活きたんだろうと思っています。（後で松田さんとそらはーさんに、めっちゃ発音突っ込まれたけど……) 共同登壇者であるtagomorisさんには、トーク以外でも色々と滞在中にお世話になったので改めて感謝を！ありがとうございます！ 録画はあるらしいので、もうちょっとしたらyoutubeとかに上がるだろうと思います。 発表の仕方については、流石に普段英語
Asakusa.rbとは私にとってどんな場所なのか - joker1007’s diary
Asakusaの方面から来ました 今回、RubyKaigiに来た人は何度かこの画像を目にしたかもしれません。 昔からAsakusa.rbに良く参加している人が発表資料を作る時に、良く使われている画像です。 いかにもシンボリックでアングルが良い写真なので、これが定番として使われています。私とモリスさんも今回のRubyKaigiで使わせてもらいました。 最近のAsakusa.rbに良く参加していて、今回のRubyKaigiに登壇していたメンバーは私が覚えている限りで以下の通り。(id表記 敬称略) @tagomoris & me @hsbt @koic @spikeolaf @youchan @aycabta LT Speakers @tad @284km @youchan 全員の資料を見てないので、全ての発表でこの画像が出てたかは分からないですが、めっちゃ多いですね。1日二人以上のペース。(
俺史上最高のRubyKaigi 2018 - joker1007’s diary
仙台で行われたRubyKaigi 2018に参加してきました。 RubyKaigiは毎年最高のイベントなのですが、今年は総合的に今迄で最も良い体験ができたRubyKaigiでした。 実績解除 今回のRubyKaigiで初めてメインスピーカーとして登壇することができました。 私が初めてRubyKaigiに参加したのが、確か2011年で1stシーズンのFINALとして開催された時でした。 そして、その頃からずっとThe RubyKaigiのメインスピーカーというのは憧れの場であったのですが、7年の歳月を経て辿り着くことができたことを本当に嬉しく思っています。 今回の発表内容は「Hijacking Ruby Syntax in Ruby」というタイトルで話をさせていただきました。 Asakusa.rbで雑談してたのが切っ掛けで、@tagomoris さんと盛り上がってRubyのダイナミックな機能
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
