自作の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で発表したので興味があればそちらの記事もご

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

6年近く前の話だが「Quipperに入社して業務をこなすにはどの程度の英語力が必要か？」という問に対し、こんな回答を貰ったのを覚えている。 技術的な課題を解くためにググってStackOverflowが出てきたときになんとか読める程度の英語力、ないしは読もうとする気概や胆力があれば大丈夫 後に自分が採用担当になった折りには同じ質問を受ける立場となり、リーディングに関してはおおむね同じ回答をしてきた。（リスニング・スピーキングは年やチームによって状況が著しく異なったので一概にこう、とは説明できなかった） 振り返れば「StackOverflowを読める程度の英語力」というのは英語運用能力の多寡というより、問題解決能力を示す良いベンチマークだなと思えた。 なお、StackOverflowはたまたま例として挙げただけなので「〇〇の公式ドキュメントを読める」など各分野における任意の主要な情報ソース源を

※ (2020-07-12 追記) 2020年6~7月の求職活動に伴う募集は終了しました。 令和2年6月1日より、ソフトウェアエンジニアとして"求職活動"を開始します。職務経歴書 (CV) を以下のページで公開していますので詳細はそちらをご覧いただければと思います*1。興味をお持ちいただけた方はCVに記載のメールアドレスにご連絡いただけると嬉しいです*2。 ohbarye.github.io ※英語版はこちらです: https://ohbarye.github.io/en/cv/ *3 ※ (2020-06-03 追記) メールでの返信には~3日を要しています。Twitter DMは本記事公開以前から無法地帯となってしまっているため確認しておりません。 ※ (2020-06-12 追記) 2020-06-12 21:00 JST 時点までに送られたメールについて、すべて一次回答はさせていた

近況報告です。4年7ヶ月勤続したQuipperを"退職"ります。 退職エントリですか？ これは退職報告ではありますが、一般的に期待されるような"退職エントリ"ではない気がしています。もう少しちゃんとしたやつは後ほど書くつもりです。 誰 @ohbarye です。"広島の粗大ごみ"と呼ばれることもあります。 在職中はRuby on Railsによるサーバサイド、React, TypeScriptによるフロントエンドを中心に学習サービスの開発をやってきました。長らくBtoC領域に携わっており、登録導線や決済システムやカスタマーサポート周りの開発・運用経験が長いです。また、必要に応じてスクラムマスターのような動きもした時もありました。 ここ2年半ほどは上記のような動きをしつつ、Engineering Managerとして組織設計・採用プロセス整備・評価制度策定・表出した組織課題への対応・会社主催の

TL;DR 現プロジェクトと近似した構成で素振り出来るよう Rails + PostgreSQL による backend と React + TypeScript による frontend を docker-compose で立ち上げる boilerplate 作ったhttps://t.co/iCqMc2TWrD— 広島の粗大ゴミ (@ohbarye) 2018年7月7日 github.com Motivation 最近は "Backend developer" と名乗ろうが "Frontend developer" と名乗ろうが、web application を開発するエンジニアとして求められる知識は広範囲にわたることを、改めて実感しなおしている。 自分の経験でいえば、ここ数年は Rails エンジニアとしてやっているのだが、最近は React.js と TypeScript による

土日祝日などの勤務時間外にがんばって出した成果を「やっていき」「圧倒的当事者意識」などと手放しに称賛しない方が良いと思っている。 「いやー土日にがんばるなんてスゴイっすね〜〜〜」と褒められて気分良くなったりするんだけど往々にしてそもそも実現不可能なスケジュールの帳尻合わせに加担してしまっていたりする。そういうのは個人の頑張りで巻き返すのではなくいっそ破綻させた方が全体の教訓になるので好ましい。 こういう振る舞いを迂闊に繰り返すとだんだん周囲の期待値も変わってきて「休日で巻き返せる/巻き返してくれるからいっか」「今週末は働いてくれなかったのか…」となってくる。*1 ボランティア精神に近い個人の貢献は当たり前ではないことを共有し続けないといけない。 誤解しないようにしたいのが問題なのは「やり方」であって「出した成果」それ自体は尊いということ。「休日に対応したからゴミ」みたいなことは、ない。平日

かつての自分と全く同じ気持ちを持った質問者によるurl - What is the etymology of 'slug'? - Stack Overflow（'slug' の語源は？）が気に入ったので抄訳。 python - What is a "slug" in Django? - Stack Overflowよりも質問の仕方が良い。 ちなみに今の自分が「'slug' ってなに？」と聞かれて説明するなら「ヒューマンリーダブルな ID」あたりが妥当な回答だろうか。 Q: ‘slug’ の語源は？ ‘slug’ は特筆すべき理由のない言葉なのか、それともやはり何らかの意味がある言葉なのでしょうか？あるとき私は会話の中でこの言葉を使用したのですが、「なぜ ‘slug’ って呼ばれているのか」と聞かれたときに私も意味を理解してないと気づきました。 もちろんそれがどのように使われているかは知って

Quipper のエンジニア採用には必ず候補者の同僚となる人*1が参加する。いつからかはわからないが自分が候補者として採用面接を受けた昨年の7月頃にはそうなっており、今では自分が採用側として履歴書を読み、面接に参加し、コードレビューを行うようになった。 コードレビューについては以下を参照。 Quipper のエンジニア採用プロセス コードテスト編 - @kyanny's blog - 応募直後のレジュメを見て下す判断や、面接の時間内での行われる会話の内容や質問は基本的に各自に委ねられている。事前に得られた候補者の情報から面接前に「今の採用方針は○○だから、こういうところを今回は見てみよう」「この経験を掘り下げてみよう」程度の認識合わせをすることはあるが、とりわけシステマティックな進行に沿っているわけではない。 そういうわけでこれまで数十名の候補者のレジュメを見て十数人程度の候補者と会ってき

前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には

いろいろあり引っ越すことにした。 学生時代も含めるとこれが4回目の賃貸物件探しだ。過去の引越しも、その時々で良い物件を見つけられたと思っているのだが…どの体験もあまり満足度が高くなくて若干トラウマ感があった。 今回物件を探すにあたってこうした過去を乗り越えることにした。 はてブが集まっている人気記事などを読んでみると、どうやら引越しや賃貸物件探しの満足度が低い原因は「ネットで物件探しを済ませようとする」「良い不動産屋を探していない」ことなどにあるらしい。 特に 今回は良い物件を探すのではなく、良い不動産屋を探すという方向に考えを変えることができたのが良かった。 部屋探しは面倒、suumoやhomesで探しててもよく分からない、自分より物件探しのプロの不動産屋の方が物件探しは得意なんだからそこに任せたほうが結果的に良いだろう、なら任せられる人を探そうという感じ。 良い物件ではなく良い不動産屋

海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。 全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。 ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。 ヨーロッパの開発チーム構成 同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。 それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的

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

2019年12月の冬休みに1週間程かけて"Let's Build a Simple Database"という、C言語でSQLiteのクローンを作るチュートリアルをやりました。この存在を教えてくれた同僚に感謝 :pray: cstack.github.io チュートリアルの内容 Richard Feynman先生の“What I cannot create, I do not understand.”という言葉が掲げられているように、データベースを作ることでデータベースをより深く理解することに主眼が置かれているチュートリアルです。 これは重要事項説明かつタイトル詐欺に関する謝罪なのですが… 残念ながらこのチュートリアルは完成しておらず、Part 13が2017-11-26に公開されたのを最後に更新が止まってしまっており、以下の13章しかありません。 Part 1 - Introduction

2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ

この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので3行でまとめるとこんな感じです。 成長と刺激を求めて OSS contribution や登壇やイベント運営を頑張ってみた 成長したかはわからないが、知り合いが増えたりして刺激を受けることが多くなった これからも続けていくが持続可能なペースにしたい この半年間、登壇とかイベント運営とかに積極的になるよう"試験運用-セルフコントロール-"してきたのでそろそろ振り返ってまとめたい— 広島の粗大ゴミ (@ohbarye) 2018年9月27日 だいたい2018年上半期の話ですが一部期間外の話もあります。 なぜアウトプットを増やすか 唐突ですが、現職では日常の業務を漫然と続けるだけで成長するフェーズは終わったのかなぁと思っています。新しく何ができるか、何をすべきか

あまり声を大にして言っていなかったが、Engineering Managerになってからのほうが学習意欲が増して技術力が伸びたのではないかという自負がある— ohbarye (@ohbarye) 2019年3月26日 もう半年以上前だが、このツイートにそこそこFavが付いたのでもう少し丁寧に考えや経験を補足しようと思った。 僕が観測する界隈ではエンジニアがマネジャーになることに対するネガティブな印象として「コードを書けなくなる」「技術力が落ちる」といった意見を聞くことが多いので、いち反例として個人的な経験を挙げてみる。*1 どういうことか 僕がエンジニアリングマネジャーになったのは2017年で、今から約2年前。*2 過去に記事で書いたようにその頃は 「日常の業務を漫然と続けるだけで成長するフェーズは終わった」という焦燥感があった一方、目線の上げ方・課題の見つけ方・実行するための冴えたやり方

データ構造とアルゴリズムの学習の一環として『みんなのデータ構造』を読んだ。これまでで最も良いデータ構造の学習になった。 みんなのデータ構造 作者:Pat Morin発売日: 2018/07/20メディア: 単行本（ソフトカバー） 日本語訳がWebで公開されているので気になる方は無料で読める。が、著者や訳者や出版社応援の意味も込めて購入すると良いと思います。また、ラムダノート社のサイトから買うと紙書籍と電子書籍のセットがお得。 内容 データ構造とアルゴリズムに関連する本はアルゴリズム寄りのものが多いが、データ構造に焦点を当て続けていることが本書の特色。 内容の依存関係 p.21より 大学の教科書のように、正確性を優先したハードコアな内容。 アルゴリズムの内容も少しだがある。「11章 整列アルゴリズム」ではそれまでの章で学んだデータ構造がどのように使われるかを一瞥でき、「12章 グラフ」では深

まともな（信頼できる）ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象— たにみち (@ttanimichi) 2018年8月20日 このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。 が、そもそも何をステージング環境と呼ぶか、何をもって"まとも（信頼できる）"と言えるのかわからないのでそこから考えてみた。 ステージング環境とは 本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。 試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。 まともであるために、ステージング環境で実現したいこと 少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験（Develop

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