サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ストレッチ
ohbarye.hatenablog.jp
いろいろあり引っ越すことにした。 学生時代も含めるとこれが4回目の賃貸物件探しだ。過去の引越しも、その時々で良い物件を見つけられたと思っているのだが…どの体験もあまり満足度が高くなくて若干トラウマ感があった。 今回物件を探すにあたってこうした過去を乗り越えることにした。 はてブが集まっている人気記事などを読んでみると、どうやら引越しや賃貸物件探しの満足度が低い原因は「ネットで物件探しを済ませようとする」「良い不動産屋を探していない」ことなどにあるらしい。 特に 今回は良い物件を探すのではなく、良い不動産屋を探すという方向に考えを変えることができたのが良かった。 部屋探しは面倒、suumoやhomesで探しててもよく分からない、自分より物件探しのプロの不動産屋の方が物件探しは得意なんだからそこに任せたほうが結果的に良いだろう、なら任せられる人を探そうという感じ。 良い物件ではなく良い不動産屋
データ構造とアルゴリズムの学習の一環として『みんなのデータ構造』を読んだ。これまでで最も良いデータ構造の学習になった。 みんなのデータ構造 作者:Pat Morin発売日: 2018/07/20メディア: 単行本（ソフトカバー） 日本語訳がWebで公開されているので気になる方は無料で読める。が、著者や訳者や出版社応援の意味も込めて購入すると良いと思います。また、ラムダノート社のサイトから買うと紙書籍と電子書籍のセットがお得。 内容 データ構造とアルゴリズムに関連する本はアルゴリズム寄りのものが多いが、データ構造に焦点を当て続けていることが本書の特色。 内容の依存関係 p.21より 大学の教科書のように、正確性を優先したハードコアな内容。 アルゴリズムの内容も少しだがある。「11章 整列アルゴリズム」ではそれまでの章で学んだデータ構造がどのように使われるかを一瞥でき、「12章 グラフ」では深
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) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある 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 する際には
あまり声を大にして言っていなかったが、Engineering Managerになってからのほうが学習意欲が増して技術力が伸びたのではないかという自負がある— ohbarye (@ohbarye) 2019年3月26日 もう半年以上前だが、このツイートにそこそこFavが付いたのでもう少し丁寧に考えや経験を補足しようと思った。 僕が観測する界隈ではエンジニアがマネジャーになることに対するネガティブな印象として「コードを書けなくなる」「技術力が落ちる」といった意見を聞くことが多いので、いち反例として個人的な経験を挙げてみる。*1 どういうことか 僕がエンジニアリングマネジャーになったのは2017年で、今から約2年前。*2 過去に記事で書いたようにその頃は 「日常の業務を漫然と続けるだけで成長するフェーズは終わった」という焦燥感があった一方、目線の上げ方・課題の見つけ方・実行するための冴えたやり方
この半年間はソフトウェアエンジニアとしてのアウトプットに積極的になるよう意識的に行動してみたので振り返ってみます。長くなってしまったので3行でまとめるとこんな感じです。 成長と刺激を求めて OSS contribution や登壇やイベント運営を頑張ってみた 成長したかはわからないが、知り合いが増えたりして刺激を受けることが多くなった これからも続けていくが持続可能なペースにしたい この半年間、登壇とかイベント運営とかに積極的になるよう"試験運用-セルフコントロール-"してきたのでそろそろ振り返ってまとめたい— 広島の粗大ゴミ (@ohbarye) 2018年9月27日 だいたい2018年上半期の話ですが一部期間外の話もあります。 なぜアウトプットを増やすか 唐突ですが、現職では日常の業務を漫然と続けるだけで成長するフェーズは終わったのかなぁと思っています。新しく何ができるか、何をすべきか
プレゼンテーションレイヤ、いわゆるフロントエンドがクライアントサイドで実装・実行されるアーキテクチャ (注 1) において、管理画面/管理機能をあとから追加する際にどのような実装パターンがあるのかを整理してみます。 注 1: Presentation Domain Separation の実践の中でも、物理的にプレゼンテーションロジックとドメインロジックを分離しているアーキテクチャです。 用語の整理 プレゼンテーションレイヤ 三層アーキテクチャにおける、システムの利用者へユーザインターフェイスを提供する層です。本記事では"フロントエンド"とほぼ同義で使います。 OSI 参照モデルの第六層ではないです。 バックエンド Web API とは プレゼンテーションを持たない Web API (HTTP プロトコルを用いてネットワーク越しに呼び出すアプリケーション) とします。 プレゼンテーションレ
土日祝日などの勤務時間外にがんばって出した成果を「やっていき」「圧倒的当事者意識」などと手放しに称賛しない方が良いと思っている。 「いやー土日にがんばるなんてスゴイっすね〜〜〜」と褒められて気分良くなったりするんだけど往々にしてそもそも実現不可能なスケジュールの帳尻合わせに加担してしまっていたりする。そういうのは個人の頑張りで巻き返すのではなくいっそ破綻させた方が全体の教訓になるので好ましい。 こういう振る舞いを迂闊に繰り返すとだんだん周囲の期待値も変わってきて「休日で巻き返せる/巻き返してくれるからいっか」「今週末は働いてくれなかったのか…」となってくる。*1 ボランティア精神に近い個人の貢献は当たり前ではないことを共有し続けないといけない。 誤解しないようにしたいのが問題なのは「やり方」であって「出した成果」それ自体は尊いということ。「休日に対応したからゴミ」みたいなことは、ない。平日
まともな（信頼できる）ステージング環境を用意できてるウェブ系企業、肌感だけど5%以下という印象— たにみち (@ttanimichi) 2018年8月20日 このツイートを見て弊社は5%に入れるかどうかを考えてみたいと思った。 が、そもそも何をステージング環境と呼ぶか、何をもって"まとも（信頼できる）"と言えるのかわからないのでそこから考えてみた。 ステージング環境とは 本記事中では「アプリケーション、システムの動作や表示を試験するための環境」とする。 試験の対象は機能・性能・外部連携などの多岐にわたる。また、試験を行うのはサーバサイド開発者、クライアントサイド開発者、デザイナー、カスタマーサポート、プロダクトマネージャ etc.…と、これも多岐にわたる。 まともであるために、ステージング環境で実現したいこと 少なくとも自分の感覚では、以下を実現できるのであれば良い開発体験（Develop
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
かつての自分と全く同じ気持ちを持った質問者による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 - 応募直後のレジュメを見て下す判断や、面接の時間内での行われる会話の内容や質問は基本的に各自に委ねられている。事前に得られた候補者の情報から面接前に「今の採用方針は○○だから、こういうところを今回は見てみよう」「この経験を掘り下げてみよう」程度の認識合わせをすることはあるが、とりわけシステマティックな進行に沿っているわけではない。 そういうわけでこれまで数十名の候補者のレジュメを見て十数人程度の候補者と会ってき
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 による
海外と日本でのソフトウェア開発職の文化を振り返ってみた – reyabe – Medium を読んだ。 全体としてとても面白く読ませていただいた中で、特に気になるところがあったのでそれに関する所感を書いてみる。「エンジニアのチーム構成・組織構成」というパートだ。 ちなみに、どちらが良い悪いみたいな話でもなければ同記事に対する異論反論でもない、ということは初めに強調しておきます。 ヨーロッパの開発チーム構成 同記事の「エンジニアのチーム構成・組織構成」に以下のようにある。 それに対し、ヨーロッパの開発チームはよりプロジェクト・プロダクトを実現するための一時的なタスクフォースという意識の方が強いと思います。あるプロジェクトが完了して次に進む際にメンバーがシャッフルするのも普通で、場合によってはプロジェクトではなくタスク単位で、あるタスクをこなすスキルを持つエンジニアが必要であればその人が一時的
エンジニアリングマネジャーになってから技術力が伸びるパターン - valid,invalid[ねこ][エンジニア] アイコンのねこの画像は他にはないのですか2019/11/11 19:23 b.hatena.ne.jp id:turu_crane ねこ需要を見つけたので貼っていきます。古い携帯で撮った写真ばかりです。 名前は「なし」。 オーソドックスな寝顔 耳が折れているのがかわいい 相対的に大きさがわかる 眼が大きい 人の足に乗るのが好き 人の足に乗るのが好き2。特にジーンズを好む 人の足に乗るのが好き3。そのまま寝る 手を乗せる場所がほしい 頭に圧を感じながら寝るのが好き なぜこうなったのか覚えていない シッポがないとツチノコに見えるという説 添い寝目線 相対的に大きさがわかる2 ひねりを加える 人 寝ているときに頭に圧をかけても大丈夫 圧のかけ方を間違えた例 下方から撮ると脚長スリム
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 時点までに送られたメールについて、すべて一次回答はさせていた
review 待ちの Pull Request 一覧を Slack に定期的に通知する仕組みを作ってみた。 完成品 以下の画像は朝11時 JST に自分のチームのレビュー待ちリストを表示している様。Slack の絵文字で「いまレビューしてますよ〜」「merged!」みたいな表現をするのはエンジニアしぐさだ。 private repo だと味気ない（かつ業務情報なのでモザイクだらけだ）が、public repo の PR だと Slack が自動的に展開してくれるのでよりファビュラスに見える。 仕組み 3行で書くと… review-waiting-list-bot という Slack bot が Heroku にデプロイされている*1 メンションされると GitHub API を叩いてプルリクエストを収集し、まとめて Slack に post する 定期的に実行する仕組みは Slack のリ
近況報告です。4年7ヶ月勤続したQuipperを"退職"ります。 退職エントリですか？ これは退職報告ではありますが、一般的に期待されるような"退職エントリ"ではない気がしています。もう少しちゃんとしたやつは後ほど書くつもりです。 誰 @ohbarye です。"広島の粗大ごみ"と呼ばれることもあります。 在職中はRuby on Railsによるサーバサイド、React, TypeScriptによるフロントエンドを中心に学習サービスの開発をやってきました。長らくBtoC領域に携わっており、登録導線や決済システムやカスタマーサポート周りの開発・運用経験が長いです。また、必要に応じてスクラムマスターのような動きもした時もありました。 ここ2年半ほどは上記のような動きをしつつ、Engineering Managerとして組織設計・採用プロセス整備・評価制度策定・表出した組織課題への対応・会社主催の
iOSDC 2018 に参加しています。また、3日目の9/1に『サブスクリプションサービスにおけるIn-App Purchase再考』という発表をしました。 iosdc.jp 発表 資料 サーバサイドエンジニアとして In-App Purchase (IAP) とその他の決済手段を開発・運用してきた経験をもとに IAP を考えなおす、という内容です。 今回は比較する軸を「決済ゲートウェイ」としました。 決済ゲートウェイとしての機能・性能・サービス・サポート面においてAppStoreを選ぶことにはどのようなメリット・デメリットがあるのか。また、IAPを選択する前、運用する中ではどのようなことを考慮しなければいけないのか。これらの観点について考えてみました。 15分で63枚というボリュームになってしまったので発表では以下を省略しました。気になる方は資料でご確認ください。 開発〜テストまわりの比
マネジメントスタイルは対象となるメンバーだけでなく、時々の状況や幾つかの要因によって変えるべきものだという話です。 本記事は『HIGH OUTPUT MANAGEMENT』を読んだうえで自分の観測範囲と経験に照らし合わせた感想なので、詳細が気になる方は同書の第12章を読むことをおすすめします。 マネジメントスタイルとは まず、ここでいうマネジメントスタイルとは何か。 マネジャーが部下をマネージするやり方、というと同語反復が過ぎるので、イメージしやすいように極端な例を2つ出してみます。 マイクロマネジメントとは マイクロマネジメントとは、マネジャーが部下や従業員の業務を緊密に観察する and/or コントロールしようとするマネジメントスタイルである。 マイクロマネジメントは職場における自由の欠如を示すことから、一般的にはネガティブな含みを持つと考えられている。 https://en.wiki
OSSに貢献して￥6,000ぐらい貰えたのでその話をする。OSSがお金になった話 · Dとはちょっと違う。 contribution に対する tip として 0.00357757 BTC (≒ ￥6,000) 貰った— 広島の粗大ゴミ (@ohbarye) 2018年1月14日 tip4commit Tip4Commit — Kontribusi ke Open Source というサイトがある。 このサイトに登録しているOSSプロジェクトそれぞれのビットコインアドレスに応援という名目で寄付 (donation) ができる。 これだけだといわゆる"投げ銭"サイトなのだが、面白いことに、OSSへの contributor に対して蓄積されたコインの一部が報酬として支払われるのだ。 支払われる額は積まれた投げ銭残高のN%。この割合はOSSの管理者が決定できる。例えば bitcoin-ruby
Engineering Manager Meetup をやります - valid,invalidで宣言した通り Engineering Manager Meetup #1 をやりました。本記事では感想と振り返りを、イベント運営者と参加者の両視点から忘れないうちに記しておきたいと思います。 connpass.com 本記事の主な想定対象読者はイベントに参加されなかった方です。#em_meetup ハッシュタグ を目にして興味が湧いた方や、Engineering Manager Slack に入っているがイベントには来られなかった方々に""現場の様子""をお伝えするのが目的です。 （参加された方にとっては既知のことばかりかもしれませんが、イベントを追体験したり主催者の思考をのぞき見することで楽しめる可能性があります） 3行で要約すると 気づいたら6,000字以上も書きなぐっていたので要約しまし
掲題の通り、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
「転職が成功か失敗か決まるのは(退職|転職)エントリを書いた時じゃない、入社から半年経ってからだ」とうそぶきつつ大した振り返りもせず早2年… というわけで Quipper に転職してちょうど2年が経過したので自身のことを中心に振り返ってみる。 2年前 思えばよく採用されたな…と思う、タイミングが良かった。現在は採用のハードルが上がっているので今の Quipper に2年前の俺が応募したら不採用になるだろうなと思う。これはチームの成長の証左でもあるので良いことだ。 転職まで 当時の俺はSIer (システムインテグレーター) に勤務する新卒3年目の SE (システムエンジニア) で、1年目はちょっとした Java の研修というトンネルを抜けるとそこはテスト仕様書と人力テストの国…。技術力を高めたいと主張して色々仕事を振ってもらってもコードを書く時間は半分も無かった。日曜プログラマとしてたまにコ
元同僚と先日ビデオチャットしてるときに某社の某採用担当人事の方の話になり「あの方は良いですよ、"攻め"の採用人事ですから」という話になった。 その場では「たしかに"攻め"の人事は一緒に働きやすいですね〜」と話して「せやな」って感じで終わったのだが、このたび求職活動で色んな人事の方とやり取りする中で「あ〜この方は"攻め"側だろうな〜」と思うシーンがいくつかあった。 で、"攻め"ってなんなのかってことなのだが… タスクベースで仕事をこなしていくのでなく成果にコミットする。 ミッションや視座が文脈を意識せずにこなせるタスクレベルでなく数段高いところにあって、課題発見・解決の範囲が不確実性も難易度も高いところにある。 返信が早いとか丁寧とか誠実とかそういった振る舞いのウラに「なぜそうすべきか」が通底している。 「N人採用する」が達成したいことではなく「N人のどのような人をどのタイミングで採用すれば
たとえばRubyのちょっとしたスクリプトを試したいときにdocker run -it ruby等でirbを立ち上げて試したりするわけですが、よく使うdocker runやdocker execの -i, -t ってそもそも何なんだろうとふとした時に思いました。 そして、それぞれ何のためのオプションなのか、--helpを見ても「Keep STDIN open...? pseudo-TTY...?」ぱっと理解できなくて辛くなり。 -i, --interactive Keep STDIN open even if not attached -t, --tty Allocate a pseudo-TTY docs.docker.com 『なるほどUNIXプロセス』を読んでこのあたりの基礎知識が身についた気がしているので、「とりあえず付けておけばOKでしょ」ぐらいのふわっとした理解から「なぜ無いとい
壊れたルーティングの検出、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
次のページ
このページを最初にブックマークしてみませんか？
『valid,invalid』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
