サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
アメリカ大統領選
ohbarye.hatenablog.jp
表題の通りRailsにおけるdata migrationの手法や現在地についてKaigi on Rails 2024で発表してまいりました。 4年連続でスピーカーとして参加*1することができ大変光栄でした。また、後述するようにオフラインならではの稀有な体験ができ、楽しかったです。 今回の発表について 発表に用いたスライドは以下です。 今回はこれまでの発表とは違ったアプローチに挑戦してみました。これまでの発表が1つの課題やプロトコルについて深掘るスタイル(まぁ、発表って普通はこっち)だったのに対し、今回は収集する情報の幅を広くとりつつ特定テーマの現在地を半網羅的に示すというsurvery report風味な内容という感じ。 意図したアプローチではありつつも、スライドを作りながら「ちょっと浅すぎないか」「広く薄いこの内容は誰にとって面白いのか」とけっこう直前まで悩んでいた。特に一番伝えたい芯を
YAPC::Hakodate 2024に参加してきたので感想です。人生初の函館が良かったので観光成分も多め。 YAPCについて 前回のYAPC::Hiroshimaに続いて今回が2回目のYAPC参加です。YAPC::Hiroshimaではプロポーザルが通ったのですが今回は通らずでした。 出したプロポーザルはこちら 3Dセキュア温故知新: Web認証技術の発展が切り拓いた現在地 by ohbarye | トーク | YAPC::Hakodate 2024 #yapcjapan - fortee.jp。同僚の id:yutadayo がクレカ製造技術ネタでめちゃめちゃ強いのを出して大バズしていたので会社としては問題ない...が、個人としては悔しい! yuta.hatenablog.com 心に残った発表たちの個人的総括 ブース担当したり廊下で人と話したりでセッションは半分ぐらいしか聞けなかった
かねてより人間、とりわけ労働者や従業員をリソースと呼ぶことについて批判的な意見を聞くことがあった。 2018 Don't call people resources - Ben Linders 2021 社員を「リソース」と呼んではいけない――。 | d's JOURNAL(dsj)- 理想の人事へ、ショートカット 2022 人間をリソースと呼ばない方がいいと思う - ジムには乗りたい 加えて、これらの主張に対するカウンターを見たこともある。「問題の所在が不明瞭」「情緒的な意見のみで代替が示されない」「人材を人財と書くような言葉遊びでは」等々。俗っぽく言えばここにあるのは、「モノ扱いしないでほしい」vs「とは言っても経営管理上はヒト・モノ・カネ・情報はリソースでしょ」という対立である。 この件について「人間をリソースと呼ぶことの問題についてアカデミックな見解・理論はあるのか」「人間をリソー
自作の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つ目の本は『不老長寿メ
『プロジェクトマネジメント知識体系ガイド(PMBOKガイド)第7版』*1を読んだので書評を書いた*2。 プロジェクトマネジメント知識体系ガイド(PMBOKガイド)第7版+プロジェクトマネジメント標準: PMI日本支部 監訳 作者:プロジェクトマネジメント協会(PMI)一般社団法人 PMI日本支部Amazon "a cat reading pmbok (project management body of knowledge) in an old cozy cafe, illustration" by Stable Diffusion 動機 / 背景 当記事の筆者がPMBOKガイド第7版を読むに至った背景について。 PMBOK自体は認知してて、201x年に新卒で入ったSIerで「いつかはこれを読んでプロジェクトマネジャー資格を取れ」的なことを聞いて第4か第5版あたりを流し読みしたけどほぼ何も
最近食べて気に入ったチョコレートのうち自信を持って推薦できるものたち。 Guido Gobino イタリアトリノの老舗ジャンドゥーヤチョコレート専門店。 ジャンドゥーヤならここ。ジャンドゥーヤはナッツのペーストとチョコレートを混ぜたお菓子のことで、香ばしさと甘さの一体感が楽しめるのが特徴。 国内では高島屋オンラインなどで購入できる。 www.takashimaya.co.jp 箱がかわいい Frederic Blondeel ベルギーのショコラティエ 兼 焙煎士のFrederic Blondeelによるチョコレート。 複数の産地のカカオが楽しめるボンボンショコラのセットがおすすめ。特にGianduja / Noir (ベトナム産カカオ80%)、Earl Grey(トリニダード産カカオ55%)、Sea Salt(ペルー産カカオ70%)が気に入った。 焙煎力の良し悪しは正直素人舌ではわからない
先日に伊良コーラに出会ってからクラフトコーラのことが好きになった。ドクターペッパーやルートビアみたいな薬膳くささがたまらない。 原液を切らして飢えていたところ手軽に自作できるらしいことがわかったので 、以下の記事を参考に作ってみた。 mi-journey.jp 材料を集める まず材料を集める。 ...のだが、近所のマルエツやまいばすけっとにブラックペッパーやジンジャーパウダーはあれど、クローブやカルダモンなどのスパイスの原形が売っていない(ホールと呼ばれるやつ)。 SainEのような自分の生活グレードより上位のスーパーを活用してなんとか全て揃える事ができた。 S&BやGABANシリーズはいずれも100~300円ぐらいでお手頃なのだが、"スパイスの女王"カルダモンだけ廉価な小瓶が見つからず高かった(800円ぐらい)。 入手したスパイスたちを高貴な皿に盛り付けてみると... 百万倍も美しい!
個人サイト 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
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
掲題の通り、SmartBank, Inc に入社しました。 From: Quipper, Inc. To: SmartBank, Inc. smartbank.co.jp 2021 in review - valid,invalidに書いたとおり転職は2020年の出来事で、入社日は 2020-08-01。2021 の間違いではなく 2020 である。入社してから半年程度はステルスでプロダクト開発を行っていたため書くきっかけを見失ってしまい、以降ずっと執筆をサボっていた。 当記事は入社後 1 年半の振り返りではなく2020年のオファー受諾時や入社時に何を考えていたかを主に記述する。(が、結果として当時の期待やオファー受諾の決め手が概ね間違っていなかったことを追認することになった) 入社までの経緯 無職 前職の最終出社を終えたあと無職をしていた。有給消化だけでなく本当の無職期間を合わせて計 4
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の情報を取れるようになった。 記事中で紹
Idempotency-Key Header に関する調査と実装を半年ぐらい前に行ったので、そのとき参考にしたリソースと 2021 年 9 月時点で得られる最新情報をメモしておく。 前提: Idempotency-Key Header とは HTTP リクエストのうち冪等ではないとされるリクエスト*1を冪等にし、安全なリトライを可能にするための仕組みの 1 つ。 Jayadeba Jena, Sanjay Dalal, Erik Wilde 氏らによって 2021 年 11 月に仕様が提案された。現在は IETF のもと、インターネット標準化過程(Standard Track)にあり、IETF Meeting や GitHub issues にて議論が行われている。real world ではすでに多くの企業で類似する実装が行われている。 現状と今後 GitHub issues を見る限り論
今年の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があ
この数ヶ月で自宅のデスク環境を大きくアップデートしたので記録に残しておきます。 当記事がリモートワークないし家で作業する機会が多い人の参考になれば幸いです*1。 変更前後のようす Before 作業環境にこだわらずガジェットにも興味が薄い人間だったので聞く人によっては卒倒しそうな環境で2020末までずっと仕事や自宅作業をしていました。 変更以前の写真がなかったので当時の自宅のようすを超技術で再現すると、こうです*2。 すでに腰痛や肩こりを抱えている方、つまりHPが1桁台で状態異常の方が利用したら1ヶ月と持たずに身体が破壊されるのではと思える環境でしたし、かくいう私も何度か破壊されました。 破壊されつつも自宅に机やイスを設置するスペースがなかったので、リモートワークがメインになった2020年からも1年ぐらいこの環境で働いていました。まぁ、世間が急速にリモートワーク対応していった昨年の2020
6年近く前の話だが「Quipperに入社して業務をこなすにはどの程度の英語力が必要か?」という問に対し、こんな回答を貰ったのを覚えている。 技術的な課題を解くためにググってStackOverflowが出てきたときになんとか読める程度の英語力、ないしは読もうとする気概や胆力があれば大丈夫 後に自分が採用担当になった折りには同じ質問を受ける立場となり、リーディングに関してはおおむね同じ回答をしてきた。(リスニング・スピーキングは年やチームによって状況が著しく異なったので一概にこう、とは説明できなかった) 振り返れば「StackOverflowを読める程度の英語力」というのは英語運用能力の多寡というより、問題解決能力を示す良いベンチマークだなと思えた。 なお、StackOverflowはたまたま例として挙げただけなので「〇〇の公式ドキュメントを読める」など各分野における任意の主要な情報ソース源を
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人のどのような人をどのタイミングで採用すれば
次のページ
このページを最初にブックマークしてみませんか?
『valid,invalid』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く