サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
どうなる？Twitter
ohbarye.hatenablog.jp
先日に伊良コーラに出会ってからクラフトコーラのことが好きになった。ドクターペッパーやルートビアみたいな薬膳くささがたまらない。 原液を切らして飢えていたところ手軽に自作できるらしいことがわかったので 、以下の記事を参考に作ってみた。 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をレビューし
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人のどのような人をどのタイミングで採用すれば
あと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さん
1週間ぐらい前にバズっていた東京大学計数工学科の講義資料が大変面白そうだったので全てのハンズオンをやってみた。 tomomano.gitlab.io Webアプリケーション開発の実務経験があれば多少読み飛ばせる部分はあるのでだいたい半日程度、実行するコードを読み込んだとしても1日で完了できるボリューム。ハンズオンはやや腰が重いかもしれないが、細かく分けて実践することも可能なので興味を持った部分だけでも挑戦することをおすすめする。 実践的な内容 「1.1. 本講義の目的・内容」より。 本講義(計3回)の目的は，クラウドの初心者を対象とし，クラウドの基礎的な知識・概念を解説する． また， Amazon Web Service (AWS) の提供するクラウド環境を実例として，具体的なクラウドの利用方法をハンズオンを通して学ぶ． 特に，科学・エンジニアリングの学生を対象として，研究などの目的でクラ
※ (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 時点までに送られたメールについて、すべて一次回答はさせていた
なんやかんやあり、伸ばしたいスキルを整理したり自分のスキルセットの棚卸しをしたりしていた。また、最近は有給消化期間で暇なのでふだんの業務から離れた領域の学習をしてみたいと思い、基礎分野であるデータ構造やアルゴリズムやコンピュータアーキテクチャについて学んだりしている。 そんな中、漠然と「ソフトウェアにもっと詳しくなりたい」「基礎を学びたい」と思いつつもそもそも基礎ってなんだっけ？という問いがあり、色々調べていたら"情報専門学科におけるカリキュラム標準"という便利そうなものを見つけた。自分で場当たり的に学習計画を立てるよりは既存の体系立てられたカリキュラムを参考にするほうが良いだろう、ということで"掘-ﾃﾞｨｸﾞ-"ってみた。 この記事をエントリポイントに、カリキュラム標準J17 https://t.co/In8Y31P3u4 に辿り着いた / 他4件のコメント https://t.co/F
2017年6月〜2020年3月まで、Quipperという会社でEngineering Managerをやってみての振り返りです。 ここ数日こつこつと退職エントリを執筆していたのですがこのセクションが長くなりそうだったのと、単体で読まれても良さそうなので1エントリとして切り出しました。*1 マネジャーになった背景から失敗から学んだことから思いついたことをぐだぐだ書いていきますがはっきり言って個人の日記レベルなので野暮なツッコミはなしでお願いします。*2 というかこれは個人の日記ですよ〜。（ここまで防衛線） マネジャーになった背景 / 当初の役割 記憶が確かであれば2016年頃にQuipperにも評価制度が導入されたのですが、当時すでに世界に数拠点あったためCTO@Londonが全員を評価するのは難しくなっていました。可能な限り現地オフィスで現地メンバーを評価したほうが納得感も高い、ということ
アルゴリズムの学習の一環としてCourseraの "Algorithms, Part I" を完了した。 www.coursera.org 先日アルゴリズムに関する学習教材を探していた折、同講座に関する満足の声を見かけたのでやってみることにした。（英語のレビューは上記ページに載っている） Courseraで高評価な「Algorithms, Part I」を使った社内勉強会を開催しています - Hatena Developer Blog Coursera Algorithm Part I を受講し終えた - /var/log/kmb.log Coursera Algorithms PartⅠを受講しました | Futurismo 時間はかかったが全課題を及第点以上で完了できた!! "Algorithms, Part I" とは何か Princeton大学がCourseraで公開している、アル
データ構造とアルゴリズムの学習の一環として『みんなのデータ構造』を読んだ。これまでで最も良いデータ構造の学習になった。 みんなのデータ構造 作者:Pat Morin発売日: 2018/07/20メディア: 単行本（ソフトカバー） 日本語訳がWebで公開されているので気になる方は無料で読める。が、著者や訳者や出版社応援の意味も込めて購入すると良いと思います。また、ラムダノート社のサイトから買うと紙書籍と電子書籍のセットがお得。 内容 データ構造とアルゴリズムに関連する本はアルゴリズム寄りのものが多いが、データ構造に焦点を当て続けていることが本書の特色。 内容の依存関係 p.21より 大学の教科書のように、正確性を優先したハードコアな内容。 アルゴリズムの内容も少しだがある。「11章 整列アルゴリズム」ではそれまでの章で学んだデータ構造がどのように使われるかを一瞥でき、「12章 グラフ」では深
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
近況報告です。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
エンジニアリングマネジャーになってから技術力が伸びるパターン - valid,invalid[ねこ][エンジニア] アイコンのねこの画像は他にはないのですか2019/11/11 19:23 b.hatena.ne.jp id:turu_crane ねこ需要を見つけたので貼っていきます。古い携帯で撮った写真ばかりです。 名前は「なし」。 オーソドックスな寝顔 耳が折れているのがかわいい 相対的に大きさがわかる 眼が大きい 人の足に乗るのが好き 人の足に乗るのが好き2。特にジーンズを好む 人の足に乗るのが好き3。そのまま寝る 手を乗せる場所がほしい 頭に圧を感じながら寝るのが好き なぜこうなったのか覚えていない シッポがないとツチノコに見えるという説 添い寝目線 相対的に大きさがわかる2 ひねりを加える 人 寝ているときに頭に圧をかけても大丈夫 圧のかけ方を間違えた例 下方から撮ると脚長スリム
あまり声を大にして言っていなかったが、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としてどうだったか」についてフィードバックを貰えて非常に良い体験だ
次のページ
このページを最初にブックマークしてみませんか？
『valid,invalid』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
