はてなブックマーク

自作のRuby gemをHacker Newsにて紹介したところ、一晩でGitHub repositoriesに100以上のstarsが付いて驚いた。また、リアルタイムでは見逃したのだがHacker News Rankingで数時間1位におり、20時間ほどトップページに載っていたらしい。2024-05-26現在は落ち着いて195pt。 投稿はこちら Show HN: PBT – A property-based testing library for Ruby | Hacker News。 2024-05-22のdaily rankingでは11位だった。 何について投稿したのか pbtという自作のテストツールで、property based testingを並列実行するというアイデアを実証したもの。このツールについてはRubyKaigi 2024で発表したので興味があればそちらの記事もご

表題の通りRactorを用いたproperty based testingの並列実行についてRubyKaigi 2024で発表してきました。かつスピーカーとしての参加は初めてで、いろいろ稀有な体験ができて総合的にはめちゃくちゃ楽しかった。 発表内容について "Unlocking Potential of Property Based Testing with Ractor"という題で、property based testing（以下PBT）において発生する小さくて大量のタスクをRactorで並列実行させるというアイデアと仮説検証の結果を報告しました。 日本語のテキストで概要を知りたい方はTechouse社の記事をご参照ください。登壇者の自分が発信したどのテキストよりも丁寧にわかりやすくまとめてくださってます。この場を借りて感謝いたします！ developers.techouse.com

表題の通りYAPC::Hiroshima 2024にスピーカー、およびスポンサー企業の一員として参加してきました。最近はブログ不精となっていてイベントに参加しても記事を執筆せずにいたものの、YAPC参加者のすさまじい熱量にあてられたので久々に筆をとってみます。 自分とYAPCとbuilderscon YAPC初参加です。が、実はYAPCには思うところがありました。 YAPC::Asiaの後継として開催された（ですよね？）buildersconに2017, 2018, 2019と参加しており、このイベントからは過去にめちゃめちゃ感化されていたのでした。特に初参加のbuilderscon 2017に強く影響を受けてから僕は登壇やOSS活動を始めたので、勝手な思い入れがあるカンファレンスです。 「buildersconにもやがて登壇するぞ」と思っていたものの直近の数年は非開催となってしまったので

タイトルの通りSmartBank, Inc.に入社して3年が経過したので記念に整理。 SmartBankに入社して3年が経ちました 良い会社です— ohbarye (@ohbarye) 2023年8月4日 ちなみに前回書いたのは1.5年経過のタイミングで、だいぶ遅まきの入社エントリであった。 ohbarye.hatenablog.jp やってきたこと 半年なり1年なりの区切りをトリガーに書いていれば差分を書きやすいのだけど、その習慣がついていないのでやむなく、今回は3年分まとめて書いてしまおう。3年間でやってきたこと*1のうち公にしているものたち*2を並べるとたくさんあるが、もちろんほとんどはチームでやってきたことである。 カード発行会社かつ銀行のようなサービスで、対ユーザー向けの各種機能の開発 出金 / 送金 / 目的別口座 / ペア口座 / 支出管理 サブスクリプションサービスB/43

先日登壇したイベントにて、仕事で協業したモバイルエンジニアから「Web APIのドキュメントに使われ方の想定が添えられていてありがたかった」とフィードバックをもらった。 具体的にはX post (以下、tweet) に添付した画像のような感じで、Web API (以下、API) が呼び出される画面・タイミングの想定、レスポンスの使われ方の想定などをUIのスクショとともに記述する、というもの。 API設計時にこういう使われ方の想定を添えると認識揃えやすくてありがたい、とモバイルエンジニアに喜ばれました#B43_techtalk pic.twitter.com/XLB3g6fCLZ— ohbarye (@ohbarye) 2023年8月3日 他にもこんなのとか。 APIレスポンスの使われ方の想定を書いているようす このことについて思ったよりもイベント内外で反響があったので書く。 ドキュメントの

『研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ』を読んだ。ちょっとブームに乗り遅れたけどまぁ、本なんていつ読んでもいいものなので気にせず感想を書く。 研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ 作者:Jeremy Evans,角谷信太郎ラムダノートAmazon 想定読者層はあらかじめ示されているとおり中級〜上級で、Ruby初学者には厳しめ。RubyやRailsでのアプリケーション開発にそこそこ慣れてきた自称中級者が読むと知識の広がり幅が大きくて良さそう*1。 同じようなレベルの層に対してよく推薦される図書として『メタプログラミングRuby』があると思うのだけど、そちらよりは平易かつ実践的な内容が多いと感じた。 具体的にはDSLやプラグイン機構の作り方など、ふだんのWebアプリケーション開発業務でしょっちゅう書くわけじゃないけど、書き方を知っ

今年に入ってから毎日やったことをGoogle Calendarに記録するようにしており、5ヶ月続いているので習慣化できてきた。 やったことを書くと言っても大それたことではなく、生活をちゃんとやっているな〜と自分で認められるようなこと、日記を書くほどでもないことを箇条書きにしているだけ。*1 ランニングや筋トレをした RSSリーダーに溜まっている記事を消化した 行ったことのない店に行った コーヒー豆を買った 楽器を弾いた 他にもクラフトコーラを作ったとか、図書館に寄ってレコードを聞いたとか、なにか新しいことをやったとか ほとんどはやったあとに事後で記入しているが、翌日や週末にやりたいことを前もって書くこともある。 実際のようす。Tasksとして登録している 始めたきっかけは昨年末に読んでいた2つの本で、異なる目的で似たような手法を紹介していて面白そうだと思ったから。 1つ目の本は『不老長寿メ

個人サイト https://ohbarye.github.io/ のビルドツールをwebpackからViteに移行した。 まぁ、移行と大げさに言っても、元々vanilla JSとSassでちょっと動きと装飾を付けただけのペライチページなのだけど。 実質ただのリンク集 理由 State of JS 2021のビルドツール部門でViteが1位になっていたが利用したことがなく気になっていたため。手元にある最小のフロントエンドプロジェクトが個人サイトだったのでplaygroundとして試してみた。 https://2021.stateofjs.com/en-US/libraries/build-tools より Viteとは Vite公式を斜め読みした。ランキング中だと経験あるビルドツールがwebpack, Parcel, Rollupあたりで止まっていたのでそこからの差分で理解すると... es

2021年はこんな風に生活していましたというログと、2021年に買ったものなどの近況報告です。 仕事 2020年に転職していた。 2021年はプロダクトのリリースに始まり、予想もしていない角度での急成長までが目まぐるしく、少人数スタートアップならではの醍醐味がある。一体感、納得感、自由と責任等々を求めるタイプには非常に向いている環境だと思う。このあたりの話も含め、近くに転職ブログの体裁で書き残しておきたい*1。 業務 ソフトウェアエンジニアとして、メインでは事業を伸ばすための機能追加を、サブでは内部オペレーションの改善のための多様な開発をした。 細かいことは書かないが数字で言うと... 582本のpull requestsを出した 1,095本のpull requestsをレビューした (dependencies updateを含むと) 1,581本のpull requestsをレビューし

CI完了したら通知するやつ、macOSだと `gh run watch && osascript -e 'display notification "run is done!" with title "Terminal"'` みたいなのでデスクトップ通知出せて便利そう / “Work with GitHub Actions in your terminal with GitHub CLI - The GitHub Blog” https://t.co/WyoKK8mRUX— ohbarye (@ohbarye) 2021年4月16日 Work with GitHub Actions in your terminal with GitHub CLI - The GitHub Blogにてアナウンスされた通りGitHub公式CLIのghでworkflowの情報を取れるようになった。 記事中で紹

今年の6月頃にDEV Airdropという「全世界のOSS開発者に総額2億3000万円を配布」するキャンペーンに応募していた*1。 OSS contributionの多寡によって対象となるかどうかやトークンの配布量 (≒金額) が決まる仕組みのため、まったく受け取れない可能性あるかなと思っていたが、100DEVトークンを受け取ることができた。 2021-09-05 時点では 1DEV が￥600 ~ 630 相当のため、100DEV は ￥60,000 ~ 63,000 相当*2。 ref https://coinmarketcap.com/currencies/dev-protocol/ DEV Airdropとは キャンペーンページは以下。 airdrop.devprotocol.xyz DEV Airdropの前に、まず"Dev Protocol"というDeFi protocolがあ

marmelab.com A frontend Framework for building data-driven applications running in the browser on top of REST/GraphQL APIs, using ES6, React and Material Design. Previously named admin-on-rest. Open sourced and maintained by marmelab. React Admin 管理画面を作るのに最適化された React アプリケーションフレームワーク France のMarmelab社によってメンテナンスされている OSS がコア Enterprise Edition もある OSS として公開していない便利な private modules が使えたり、開発サポートが受けられ

プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ

壊れたルーティングの検出、routing specを自動化するroute_mechanic gem を作って公開しました。この gem の紹介と内部実装の話を書きます。 rubygems.org 背景 Rails 開発者のうちの N% は、Rails application のルーティングを検証するために以下のようなコードを書いたことがあるかもしれません。 Rails が提供する assertions を使うなら: assert_routing({ path: 'photos', method: :post }, { controller: 'photos', action: 'create' }) rspec-rails なら: expect(:get => "/articles/2012/11/when-to-use-routing-specs").to route_to( :cont

「名前をよく聞くが実態がよくわかっていないものリスト」にいたPrismaだが、official tutorialが5分で終わるというのでやってみた。 www.prisma.io "5分"!? と思ったがPrisma SchemaとPrisma Clientの説明が中心で、ORMの書き味を見てみる程度の内容なのでそんなものかもしれない。 補足説明を読んだりしながら進めたので5分以上かかったが、まったく追っていないJS/TS界のORMの進化をキャッチアップできてだいぶ面白かった。 学んだこと Prisma 2はただのORM まず、Hasuraと同列のプロダクトだと誤解していたけど違っていた。Prisma 2はただのORM。 同列に語られがちだったのはどうやら今はメンテナンスモードに入っているPrisma 1の頃の話で、GraphQL DSLでデータモデルを定義したり、GraphQL APIサー

エラー検知・監視ツールであるところのSentryが提供するRubyのSDKにsentry-ravenというgemがあります。 このgemを利用するとごくわずかなコードの記述をするだけでSentryに対してイベントを送信することができます。イベントにはユーザーが定義したカスタムタグや実行環境を含む多様な情報を含めることができ大変便利です。 begin some_dangerous_code! rescue => ex Raven.capture_exception(ex) end # とか if record.unknown? Raven.capture_message("Found suspisious data") end 上述のようなコードを見た/書いた方も多いと思います。しかしながら特定条件下では上記のような Raven.capture_*メソッドの呼び出しの内部でRack envの

ISUCON10にソロチームBPM200で参加し、最終スコア770で予選敗退しました。通過スコアには大きく届きませんでした。 戦略 ソロなので時間は絶対に足りない、という前提のもと予めフォーカスするポイントはある程度決めておきました。 大方針としてはなるべく1台で勝負する、ということ。複数台構成に持っていくのは自分のスキル的に時間がかかりそうだし、過去問で素振りしてたとき、問題によってはアプリケーションレイヤでの改善に絞ってもそれなりに伸ばせると思ったため。今回もそうだと良いな〜と思ってましたが…現実は非常。 また、普段使わない解析ツールをインストールしたりログ設定を行ったりするのにかける時間もないため、それなりに手慣れたNewRelicでボトルネックの推移を見ながらチューニング対象を決めていく、というのも予定していました。 やったこと 環境準備 ssh設定確認したりgit initしたり

元同僚と先日ビデオチャットしてるときに某社の某採用担当人事の方の話になり「あの方は良いですよ、"攻め"の採用人事ですから」という話になった。 その場では「たしかに"攻め"の人事は一緒に働きやすいですね〜」と話して「せやな」って感じで終わったのだが、このたび求職活動で色んな人事の方とやり取りする中で「あ〜この方は"攻め"側だろうな〜」と思うシーンがいくつかあった。 で、"攻め"ってなんなのかってことなのだが… タスクベースで仕事をこなしていくのでなく成果にコミットする。 ミッションや視座が文脈を意識せずにこなせるタスクレベルでなく数段高いところにあって、課題発見・解決の範囲が不確実性も難易度も高いところにある。 返信が早いとか丁寧とか誠実とかそういった振る舞いのウラに「なぜそうすべきか」が通底している。 「N人採用する」が達成したいことではなく「N人のどのような人をどのタイミングで採用すれば

あとN+1回寝るとISUCONです。私はいま予選突破の夢を見つつNew Relicを素振っています。 本記事ではNew Relicの説明は特にしません。また、Rubyで実験しててちょっとハマったところを掘り下げたログが実はメインです。 (2020-07-22追記) 本記事を書いたときには気付いていなかったのですが同じことを公式のWebinarでも行うようでした。（7月30日開催｜せっかく無料なのでISUCONでNew Relicをスッと使う方法）RubyだけでなくGo, Pythonの設定の話やその他盛りだくさんなので期待!! New Relic meets ISUCON New Relicは業務で過去に使っていて大変便利だったのでISUCONもこれぐらい楽にメトリクス見てぇな〜と思っていたら、自腹契約して使うという道もあったのだということをISUCON9優勝の白金動物園mirakuiさん