先日登壇したイベントにて、仕事で協業したモバイルエンジニアから「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アプリケーション開発業務でしょっちゅう書くわけじゃないけど、書き方を知っ

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

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 が使えたり、開発サポートが受けられ

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

プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 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

エラー検知・監視ツールであるところの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の

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

1週間ぐらい前にバズっていた東京大学計数工学科の講義資料が大変面白そうだったので全てのハンズオンをやってみた。 tomomano.gitlab.io Webアプリケーション開発の実務経験があれば多少読み飛ばせる部分はあるのでだいたい半日程度、実行するコードを読み込んだとしても1日で完了できるボリューム。ハンズオンはやや腰が重いかもしれないが、細かく分けて実践することも可能なので興味を持った部分だけでも挑戦することをおすすめする。 実践的な内容 「1.1. 本講義の目的・内容」より。 本講義(計3回)の目的は，クラウドの初心者を対象とし，クラウドの基礎的な知識・概念を解説する． また， Amazon Web Service (AWS) の提供するクラウド環境を実例として，具体的なクラウドの利用方法をハンズオンを通して学ぶ． 特に，科学・エンジニアリングの学生を対象として，研究などの目的でクラ

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

※ (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 時点までに送られたメールについて、すべて一次回答はさせていた

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

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

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

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

JSConf2019 記念すべき第一回の*1のJSConf Japanで『Migration from React Native to PWA』というタイトルの発表をしてきた。 登壇に関して 資料 発表では触れなかった余談は泣く泣く削ったトピックなので参照されると嬉しい。 今回は発表資料を作ったり練習する中で気をつけたことがあり、それは「負債や失敗といった否定的で強い言葉を使わない」ということだった。資料中でも発表でもReact Native単体での技術の良し悪しは述べていないし、2年前のReact Nativeを選んだという技術選定自体にも肯定的な態度をとっている。 当時の技術選定に携わりReact Nativeアプリの土台を作ってくれた開発者がいなければ今のビジネスも存在しない。彼/彼女らへの感謝の念は尽きないということ、運用中途での状況の変化によってチームに合わなくなったのでmigr

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

(異動的な意味で)今日で最後の1-on-1だった回があり、マネジャーとしてのohbaryeにまとめてフィードバックを貰えたのがとても良い体験だったので今後も折を見てやっていきたい 最初の1-on-1等でマネジャーへの期待を確認したりするけど継続的にフィードバックを貰いにいってなかったなと反省— ohbarye aka 広島の粗大ゴミ (@ohbarye) May 22, 2019 昨年9月にQuipperに入社した@ujihisaさんという方のEngineering Managerを9ヶ月のあいだ務めました。 5月末をもって彼のマネジャーが変わる*1ため、僕がEngineering Managerとして行う最後の1-on-1が行われたのが去る日令和元年五月二十二日。その中で「僕が9ヶ月間Engineering Managerとしてどうだったか」についてフィードバックを貰えて非常に良い体験だ