これはいま、おれの中にひとつわりと明確な答えがあって、それは "スーパーセンタートライアルに向かう途中の田んぼ道"です おれの住んでる田舎は、市の人口5万人とかなんで、かなりザコいんだけど、24時間営業のスーパーセンタートライアルを抱えている そんで俺はそっからチャリで5分程度のとこに住んでいる そうすっと、夜10時からでも、思い立ったらチャリに乗って、でけえスーパーで買い物ができるわけですよ まずこれはひとつの文化資本と言って良い　スーパー　って博物館だからさあ！ そんで、そこまで行く途中の道、これもまたいいわけ 中規模の川が近くにあるから、いまの季節、サワガニが地面を這い回っているんですよ まず、玄関からチャリまで歩く過程で、スマホのライトに照らされて、聞き取れるくらいデカい足音を立ててカニが逃げる、おれはウオっと思ってちょっとのけぞる、こういう体験が、よくわかんねえけど、ひとつの原体

昨日（もう日付余裕で回ってるので一昨日だな）Findy さん主催のイベントで話してきた。 speakerdeck.com 背景 近年「エンジニアは事業貢献してこそ」「エンジニアもユーザファーストでビジネス貢献」といった言説がIT界隈で増えて来ている感じがしている。 ……とたまたま昨日関連してるようなしてないような話をしている エンジニアとビジネスの距離感の難しさ｜ばんくし｜note という記事があったので書き出しを真似してみたんだけど。 昨今、ビルドトラップに陥るな、アウトプットじゃなくアウトカムに着目しろ、って言われることが増えてますよね。でも僕は逆張りして、アウトプットにまず着目しろという声を上げておきたいのです。 開発生産性（いろいろある*1）の話をするときに、ディスカバリーとデリバリーの 2 軸で考えるのはコモディティ化してきたと思う。でも、それによって、デリバリーの重要性が薄くな

イェーーーーイ！！！ 廃人ツイッタラーのみんな～～～～～！！ みんな大好き奢り奢られ論争の時間だよ～～～～～～～～～～！！！！ 奢り奢られ論争と言えば有史以来、1,500年に渡って壮絶な論争が繰り広げられておりいまだ決着が着いておりません。 11年もの永きにわたって我が国土を混乱に陥れた応仁の乱も、細川勝元が港区女子に奢らなかったことが原因であることは教科書で習った通りです。 この令和の時代に至っても男女それぞれの陣営にわかれ、血を飲み肉を食らう壮絶な死闘が繰り広げられておりますが、そろそろ！そろそろみんな仲良くしようや！な！おいちゃんが美味しいおもちを焼いたるさかい！ な！みんな仲良うしようや！お醤油の香ばしい香りがしてきよったで！ 〇「理屈」で考える場合 【前提条件】 この論争をまとめる上で前提条件を設定しておきたいと思います。 A 男女差別禁止 「男だからそうするべき」「女だからそう

転職しました。それに伴いいくつかChrome拡張機能をRubyMineプラグインを追加したのでご紹介 Next.js フロントエンドでNext.jsを使ってSPAで画面を構成しています。なので、Reactのdeveloper toolsでコンポーネントの中を見ながらデバッグをしたりしています。IDEのプラグインもデフォルトで入っているNext.js Supportのプラグインを使っています。この辺は変わり映えしないですね chrome.google.com GraphQL GraphQLを使い出したのがいちばん大きな変わったところです。集中してパフォーマンスチューニングをしていたときに、Chrome拡張機能に GraphQL Network Inspector をいれて確認していました。 chrome.google.com この拡張機能でいちばん便利だったのは、GraphQLのヘッダーとク

ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ 作者:Mark Richards,Neal FordオライリージャパンAmazon とても良い本だ！アーキテクチャのパターンは体系的に整理されているし、アーキテクチャを議論する上で、共通の語彙となり得る用語を解説している（コンウェイの法則や、凝集度など）。 後半は、リスクや、チームビルディング、交渉術まで多岐に渡るトピックを網羅している。 必要なことは全部書いてある...けれど、なんとなく初めてPMBOKを読んだときに抱いた感想...読み始めてからすぐに「果たしてこの本に書かれている通りの考え方に沿って振る舞えばアーキテクトになれるのか？」という気持ちになりはじめたところで1章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード

みなさんこんにちは。モバイル本部のマネージャーをやっている @huin です。 去る 1月22日 (土) 〜 1月30日 (日) に技術書オンリーイベント 技術書典 12 が開催されました。 技術書典は、仕事や趣味で触っている技術はもちろん、とてもニッチ (褒め言葉) なトピックの本も販売されていて「さまざまな技術の知見」が集まるとてもユニークで面白いイベントです。正直「こんなことやってる人いるの？」と思いながら新刊を眺めているだけでも楽しめます。 僕自身は物理で参加したことはないのですが、何年か前から気になる本を購入しています。今回は下記の4冊を購入しました (かなり実益寄りのラインナップ)。 techbookfest.org techbookfest.org techbookfest.org techbookfest.org さて、この技術書典ですが、昨年の夏に続いて今回も ヘイ とし

こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの

「STORES 予約」とはどういうシステムか STORES 予約 は、ウェブ上でかんたんにお店の予約ページを作成することができるシステムです。来店予約やオンライン接客など、予約受付から顧客管理まで予約業務を管理でき、来店したいお客さま（エンドユーザー）とお店（マーチャント）の営業時間や予約枠を調整できて便利です。このSTORES 予約 は、新型コロナウイルスのワクチン接種予約システムとしても利用いただいており、医療機関や地方自治体、それに職域接種をおこなう企業や大学が、ワクチン在庫数と接種数の一括管理や、接種状況をリアルタイムに把握するなどの予約管理にご利用いただいています。ただ、ワクチン接種予約システム専用ということではなく、他にもさまざまな予約シーンにおいてお使いいただけるシステムです。 技術的な面から解説すると、STORES 予約 はごく普通のRailsサイトです。ごく普通のというの

（こちらは hey Advent Calendar 12 日目の記事 と Engineering Manager Advent Calendar 2021 カレンダー2 15日目の記事です） 数年前のかつまたさん、元気ですか。私は2021年からきたかつまたです。こんにちは。 エンジニアリングマネージャー（以下、EM）になったばかりの君へ、今の自分からアドバイスを書きたくて手紙を書きました。 （本当は「EMになりたてのあなたに伝えたいこと」というタイトルで記事を書こうとしました。でも人にそんなアドバイスなどできる存在だろうかという気持ちがもたげてしまい、過去の自分に手紙を書くという逃げをしました。） 前提の共有 プロダクト開発をしていてチームのみんなの前提が揃っていることが大事なことはきっと感じていると思うから、この記事も簡単にだけど前提を合わせつつ手紙を書いていきます。 ■前提 書き手はソ

STORES のバックエンドエンジニアとして働いている @app2641 です。 今回はチームのコミュニケーション促進のために不定期おやつ会をしている、という話をします。 hey Advent Calendar 2021の9日目です。 チームの現状 チームとはメンバーがお互いに補強しあい、さまざまなプロジェクトを遂行して成果を生み出すための最小と単位とされています。hey においてもプロジェクトを進めるためにチームで計画と問題解決をしています。たいていは10人未満の職能横断型チーム構成で成り立っています。 現在所属しているチームもフロントエンド3人、バックエンド3人、デザイナー1人、プロダクトマネージャー1人の8人体制です。不定期にメンバーの入れ替えはありつつも、このようなチーム規模で機能開発を行ってきました。 コロナ禍の影響で hey でもチームメンバー全員がフルリモートで業務を行ってい

こんにちは。hey 株式会社 プラットフォーム本部 基盤グループの inari111 です。 私の部署は STORES 各プロダクトへ導入する共通基盤を開発しており、1つ目のプロダクトとして ID 基盤を Go で実装しました。 この記事では、その Go アプリケーションのアーキテクチャについて紹介したいと思います。 アーキテクチャ 開発するメンバーは MVC + Service の構成で Go を書いた経験がありました。 まず、以前と同じような MVC + Service にするか、フラット(レイヤーを作らない)にするか、レイヤーを分けるかを検討しました。 MVC + Service の構成で開発していたときは、ファットモデル、ファットコントローラーになってしまい、アーキテクチャを変更したいと考えるタイミングがありました。詳しくはこちらの登壇資料を御覧ください。 speakerdeck.

こちらになります kaigionrails.org スライドはこちら 動画がアップされたらそれもあとで貼ろうと思います。 発表内容について とりあえず15分にしとくかと軽い気持ちで Proposal を出したのですが、いざ採択されて話を整理しはじめてみるとボリュームが膨らむ膨らむ。全然15分では足りませんでした。 大風呂敷を広げた状態のマインドマップがこちら（一応、業務のこと色々書いてあるので拡大しても文字は読めない大きさにしてます）。 マインドマップ これをキュッと圧縮する作業が本当に大変でした。 当時のメモを読むとこういうことを考えてまとめていたみたいです。 やったことが類似事例として役に立つ一方で、類似しない仕事をしている人にも学びも持ち帰ってもらいたい やったことの多くを技術的負債との戦いが占めるので、結局、技術的負債との向き合い方、みたいなところで着地しそうだが、そこで終わりには

heyのテクノロジー部門セキュリティ本部のtyabeです。 セキュリティ本部は"STORES プラットフォームに内在するセキュリティリスクを適切にコントロールする"ことをミッションとして、社内の色々な人と協力しながら活動を行っているチームです。 社内で広く活動するに当たって、どのメンバーがどういった想いで活動しているのかもっと広く知っていてもらいたいと考え、社内向けに座談会を開催しました。 テーマ セキュリティの仕事を始めたきっかけ heyで目指しているセキュリティの在り方 事業を支えるセキュリティとは の3つのテーマをゆるく雑談する形式で実施したのですが、今回はその中の "heyで目指しているセキュリティの在り方" を記事にしました。 登場人物紹介 yoshio：社内向けセキュリティ施策全般を担当。今回のファシリテーター tyabe：主に雑務を担当。マネージャー yokoyama：主に脆

こんにちは、STORES でテックブログワーキンググループをしている ushironoko です。2021年10月1日より、STORES Tech Blog は 名称を hey Product Blog と改めることになりました。 なぜ変わるか hey Product Blog と名前を改めた理由についてですが、端的に言えばテック以外の仲間のことを発信したいというものです。テックではない要素を含めたいならテックブログという看板は適さないと考えました。 元々 STORES Tech Blog は社外へ社内の技術知見などを発信し、少しでも興味を持っていただければ採用に繋がるのではないか、という採用ブランディングの目的で始め、今では多くのエンジニアに寄稿いただいています（週に何本か自主的に上がってくる）。 一方で、技術者とはいえ就職・転職をする際の関心事は「入社したあと自分がどんな働き方をするの

はじめに Basecamp社が公開しているプロダクト開発ガイド「Shape Up」の存在を知り読んでみました。 Basecamp社はプロジェクト管理SaaS Basecampの開発元で、以前は37 Signalsという社名でした。 Ruby on Railsの作者 David Heinemeier Hansson氏がCTOを務め、最近だと新機軸のメールサービス Hey を立ち上げています。 basecamp.com 特徴 Basecamp曰く「アジャイル開発でもスクラム開発でもない」、Basecamp社で15年近く試行錯誤して改善してきたやり方だそうです。 「6週間の開発サイクル」と「2週間のクールダウン期間」を繰り返して開発を進めます。 サイクルの途中で中断・見直しはせず、期間内にリリースに至らなかった場合でも期間延長はされません。 6週間は「何か意味のあるものを最初から最後まで作り上げ

こんにちは、hey 株式会社 CTO 室本部所属の id:hogelog です。 先日 RubyKaigi Takeout 2021 (9/9 - 9/11) が開催されました。Ruby 言語の開発者や利用者が集まり一年の成果を発表し盛り上がる、Ruby エンジニアの祭典です。今年の RubyKaigi も盛りだくさんの内容でしたね。個人的にもとても楽しく、エンジニアとしても刺激を受けいろいろな技術に取り組んでいこうと思えるイベントでした。 rubykaigi.org さて今回のエントリではそんな RubyKaigi というイベントに hey のエンジニアがどのように参加し、受け止めていたか紹介したいと思います。 hey は RubyKaigi Takeout 2021 のプラチナスポンサーです。 いきなりアピールしてしまいますが 今年のheyはスポンサーを頑張ってます！ - hey Pr

プログラミングPerl〈VOLUME1〉 作者:ウォール,ラリー,オーワント,ジョン,クリスチャンセン,トム発売日: 2002/09/01メディア: 単行本 何度も読み返す技術書の話題で忘れてはいけないのがPerlの作者であるLarry Wallが書いた「Programming Perl」。 この本、Perlというプログラミング言語に関する解説書である共に、定期的にブログなどで話題になる「プログラマの三大美徳(無精、短気、傲慢)」に ついて解説されている原典でもある。 この三大美徳…意外と原典ではストレートには語られていない点も興味深い。三大美徳の中身は散々語られているので、ここでは原典でどのような流れで語られているのか調べた。 Perl自体の人気もだいぶ下がっているし、日本語に訳されているのはPerl 5.6対応(20年前!)の第3版しかなく、2012年に出版された第4版は日本語には翻訳

はじめに STORES EC で SRE のエンジニアをしている秋元と申します。 サービスを運営していく上で障害の発生は避けて通れないところかと思います。 障害が発生しないように努力することはもちろんですが、今後も同様のことが起こらないようにしっかりと振り返りを行い対策を実施することも非常に重要になってきます。 今回は、EC 開発チームでの障害振り返りの取り組みについてご紹介させていただきます。 障害振り返りの取り組み EC の開発チームでは、障害の振り返りや対応策の実施の目的として以下を設定しています。 楽にサービスレベルの高い状態をキープできるようにすること これは、サービスレベルが高い状態を、開発効率をなるべく落とすことなく保てるようにしたい、という意味合いが込められています。 不具合が発生しなければサービスレベルは低下しないし障害の対応などで開発効率が落ちることもないので、どうした

hey で STORES（EC）や STORES レジのバックエンドエンジニアをしております、知花です。 先日“hey Talk” Engineers 新プロダクト「STORES レジ」を支えるエンジニアリングというイベントにて「GraphQL スキーマで支えるレジアプリ開発」というタイトルで、主に GraphQL スキーマを利用した開発の進め方について話しました。 今回はそのときに話した内容について書いていきます。 はじめに STORES レジではアプリ用の API として GraphQL を採用しました。API は EC（Rails）のコードベースに乗る形で実装しており、実装には graphql-ruby gem を利用しました。 そもそもなぜ GraphQL を採用したのかについてですが、プロジェクトが始まってまだ開発が始まっていないときに、アプリチームから「GraphQL 使ってみ