転職しました。それに伴いいくつか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章の最後の方に出てくる「ソフトウェアアーキテクチャの法則」が出てきて、「そうだよなー」という気持ちに。 ソフトウェアアーキテクチャはトレード

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

はじめに 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 使ってみ

テクノロジー部門、STORES ECでフロントエンドエンジニアをしている @daitasuです。 私たちのチームでは、会社全体での人事制度で設定する目標とは別に、チーム内で独自にクオーターごとの目標設定と振り返りをしています。 チーム内での目標設定と振り返りを1年ほど続けてきたので、なぜこの取組を始めたのか、実際やってみてどうだったかを書いていこうと思います。 チームの位置づけ UI改善チームとは hey内では、全プロダクト横断的なテクノロジー部門という棲み分けがあり、その中にSTORES ECの開発を進めるECの部隊があります。 私たちフロントエンドチームは、ECのエンジニアチームの中の1つとなっています。 hey社のEC本部では、フロントエンドチームはUI改善チームと呼ばれています。 フロントエンドチームの構成 フロントエンドチームは、大きくプロダクト開発のチームと基盤改善のチームに分

チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー

フロントエンドエキスパートチームのlacolacoです。 この記事ではアプリケーション監視プラットフォームのSentryをClassiの中でどのように活用しているかを少し紹介します。Sentryの運用に悩んでいる方の参考になれば幸いです。 Sentryの用途 Classiでは大きく2つの目的でSentryを利用しています。ひとつはアプリケーションのエラーの監視（以後エラー監視と呼びます）、もうひとつはWebフロントエンドのパフォーマンスの監視（以後パフォーマンス監視と呼びます）です。 Sentryは多くのプログラミング言語用にSDKがあり、Classiでは主にJavaScriptとRubyのSDKを利用してフロントエンド・バックエンド両方のエラー監視を行っています。パフォーマンス監視は最近利用しはじめたのですが、バックエンドではもともとDatadogによる監視をしていたので、Sentryの

はじめに hey.connpass.com 「企画側と開発側で深く議論して優先順位決めるの難しいなー」と課題を感じていたところ、heyさん主催の勉強会を見つけたので参加してきました。 tl; dr; 「やらなければならないもの」はやった先に何が得られるかを明確にすることで、着手順を明確にできたり、取り組むモチベーションをあげることができる。 工数大・リターン大のものはロードマップ積む、工数小・リターン中のものは手が空いた時にやっていく。 職種間を超えて意思決定をするには腹落ちしてもらえるまできちんと伝え合う努力をする必要がある。heyでは随筆のような長文ドキュメントをしたためる文化があり、それを活用している。 LT① 「STORES 決済における【攻めの安定性】」 プロダクト開発で考えなければならないことは2つあり、バランスを保たなければならない。 やりたいこと やらなければいけないこと

業務委託で STORES の開発をしている @inouetakuya です。 先日 STORES のフロントエンドチーム内でクライアントサイドのバリデーションについて見直す機会があり、特にバリデーションエラーのデータ型をどうするかについての議論が興味深かったので、共有させていただきます。 背景 議論の背景について簡単に触れておくと、STORES のクライアントサイドでは、バリデーションのライブラリとしてこれまで joi-browser を使ってきました。 しかしながら、本家の Node.js 版の joi がブラウザ対応したことにより joi-browser が deprecated になったことを受けて、今後も joi を使い続けるかを検討したところ、 joi-browser と joi の最新バージョンとの間で API の差異がいくつかあり、joi-browser から joi への乗

僕はRubyで開発をする時は毎回Pryを使うくらいの熱狂的Pryユーザーだったのだが、PryはGemfileに書いてないと binding.pry できなくて不便。任意のgemをdefault gem化するgem default コマンドも作ったのだが、これをやるのすら面倒だと思っていた。 ある日、nobuさんがRubyに binding.irb という機能をいれた。Pryがdefault gemになるのを待つよりPryで僕が使う機能をIRBに全部移植してしまった方が早いのではないかと思い、4年前からPryの機能の移植活動を始め、今日僕がよく使う機能を全て移植し終えた。 その記念に、この記事ではIRBのPry互換の機能を紹介する。昔 今更聞けないpryの使い方と便利プラグイン集 という記事を書いたんだけど、この中で僕が毎日のように使うコマンドは全てIRBに移植したので、それを紹介する本稿を

Noteからの転載 —- 設計書は、現在、または過去、未来をつなぐコミュニケーションツールなので、そのコミュニケーション設計をどうするか？って話を抜きに、どう書くべきか？そもそも書くべきか？みたいな議論を始めてしまうと、会話が成立しないことが多いですよね 必要な抽象度だって全然違ってくるし— magnoliak🍧 (@magnolia_k_) 2021年2月6日 これが設計書です！と言われて見せられたものが、あからさまに個人的なメモを超えるものでない場合、「この文書は誰とのコミュニケーションを目的としましたか？」と聞くと良いのではないかっていう みんなオレオレ正しい設計書理論があるので— magnoliak🍧 (@magnolia_k_) 2021年2月6日 設計書になにが書かれているべきか、コードの世界と違ってあまりコンセンサスが得られた回答を見たことが無い気がする。 かなり大きめの

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・

仕事で Netlify にデプロイしたSPAの読み込みが遅いので原因を調査してほしい、という依頼を受けてウェブパフォーマンス調査を行った。顧客から許可をもらって、この記事ではNetlifyに対してどういう調査をしたのかを書く。 結論だけをまず書くと、NetlifyのCDNのファイル配信パフォーマンスは日本国内からだと非常に悪い。パフォーマンスを改善させるためには、Netlifyに直接アクセスさせるのではなく、前段に他のCDNやキャッシュサーバを挟んだりするほうがいいだろう。 調査の前提 日本国内からのみの調査 サイトには静的なファイルをデプロイしているのみ 該当するNetlifyにデプロイしたSPAをブラウザで試しに開いてみると、確かに初回の読み込みのパフォーマンスがめちゃくちゃ悪い。 Chrome Devtoolsを開いてネットワークタブでどういうふうにリソースの読み込みを行っているのか

「なんかアプリでインシデント起きてエンジニアがどこかで対応してるらしいよ」 「インシデント時のお知らせって誰がどうやって出すんだっけ？」 「インシデントの復旧作業って今どれくらい終わってる？」 「あのインシデントって振り返りしたっけ？」 「似たようなインシデント、前も対応したような、していないような」 このような会話に覚えはありませんか？ FiNC Technologies社 (以下FiNC) では今まで インシデント対応をしていても自チーム内で対処しようとしてしまい、他の人が気づけないインシデント対応の仕方にフォーマットがなく、迅速な対応やお客様への報告ができないインシデントの振り返りが実施されず、インシデント時の知見が共有されないという問題がありました。 それらの問題を 気が付きやすく、シェアしやすくする = 統一のチャンネルで情報を整理し、そこにシェアしやすい空気を作る何をすべきかわ

よいコミットメッセージとはどういうものだろう？ - chiastolite’s blog に対するアンサーソングです chiastolite.hatenablog.com 必要であればWhyを補足するためのContextを書く 元エントリだとコミットメッセージの話だったけど僕はPRで実践してもいいと思います。*1 起点となるURLを明記する レビューで指摘されたのであればPRのコメントのURL issueのURL アプリケーションエラーであればSentryなどのエラートラッキングシステムのURL GitHub外のタスク管理ツール（例：redmineやBacklogやTrelloなど）に修正概要が書かれているのであればそのURL チャットのやり取りが起因ならSlackなどのパーマリンク 公式ドキュメントのURL CIがコケているのであればCIのビルドのURL チーム開発していればコミットやP

tl;dr なぜ「私たちは」これをしたのか？の理由を書こう コミットメッセージといえば t_wada さんのツイートがよく引用されている コードには How テストコードには What コミットログには Why コードコメントには Why not を書こうという話をした— Takuto Wada (@t_wada) September 5, 2017 自分もこの考えに賛同してるので、コミットメッセージにはWhyを書くし書いて欲しいと思う。 では「Whyを書く」とはどういうことだろう？ 「レビューで指摘された内容を反映した」 みたいなコミットメッセージを何度か見て頭をかかえたことがある。 「なぜこのコードを書いた」の理由ではあるので日本語としては間違っていないコミットメッセージではあるのだが、決してこの内容は欲しい情報ではない。 これならレビューで指摘された内容をコピペしてもらったほうがあり

以前、PHPカンファレンスで運用しやすい気づける管理画面という発表*1しましたが、今もこの考え方を大事にしながら日々サービスの運用、開発をしています。 その中で、最近思ったことがあったのを社内kibelaにポエムってあったのですが、普通に公開できる内容だったのでここにちょっと加筆して投下しておきます。 サービスに大きく影響与えるような大事な情報ってありますよね。たとえば広告配信サービスだと広告の単価設定です。そのような項目の設定作業を画面からぽちぽち１つずつ変更するのは大変なのでCSVで一括で変更できる機能をいい感じに開発すると喜ばれるという場面は管理画面を開発している人にはよくある話だと思います。そして、「この項目も設定できるようにしたい」という声がでてきて、CSVからいろんな項目が設定できる便利機能へと発展していったりすることも。 しかし人間はミスをするものです。一括変更のため変更され

こんにちは、12月からSmartHRにジョインしましたエンジニアの @h1kita です！ 入社して3週間がたちましたが、入社して1週間後にはガンガンコードを書いていけるようになりました。 今回は私が入社してから経験した、開発がスムーズに進められる助けになった、よかったことについていくつか紹介したいと思います。 前提 私の配属されたチームではバックエンドが Ruby/Ruby on Rails, フロントエンドがES2015/Reactで実装されて、私自身それらの経験はありました 私含めた、5人のチームでスクラム開発を行っています ウェルカムモブプロ 🎉 入社後すぐに、開発におけるルールや設計、各クラスやモジュール、コンポーネントについて学べたのがモブプログラミング（以下「モブプロ」）です！ 環境構築は済ませたけれど、まだコードを見れていないときにモブプロで入社を歓迎してもらいました！（

Svelte採用記 - 位置情報と可視化の会社で、全社の標準技術スタックに選ぶまで / Svelte Japan Online Meetup #3