はてなブックマーク

こんちはー、リファクタリング大好きなミノ駆動です。 私は初級〜中級向けのソフトウェア設計入門書『良いコード／悪いコードで学ぶ設計入門』（通称「ミノ駆動本」）を2022年4月に出版しました。 拙著はありがたいことに、さまざまな勉強会グループや企業さんでの輪読会で用いられていると聞きます。 この記事は、株式会社コドモン のエンジニアさんからお呼びを受けて輪読会に参加したレポートです。 召喚の儀（ことのはじまり） 「輪読会に召喚したい」的な雰囲気をTwitterで感知したので、私は次のようなツイートをしました。 僕は常にエゴサしているので、 #ミノ駆動本 の輪読会などで僕を召喚したい場合は、僕の名でツイートしていただけると、予定等にもよりますが召喚に応じます。 （※DMは相互フォロワー以外解放していないため） https://t.co/ljv8KnxcI6— ミノ駆動 (@MinoDriven)

こんちはー、リファクタリング大好きな ミノ駆動 です。 書籍『良いコード／悪いコードで学ぶ設計入門』 の著者です。 READYFORでアプリケーションアーキテクトとして務めています。 この記事は、8/20(土)に開催された オープンセミナー岡山2022 の登壇レポートと、そこで発表した 設計とチームビルディングの関係 について、弊社での活動を解説するものです。 登壇発表の概要 この登壇では、 私が昔勤めていた会社での失敗経験と反省 が、現職READYFORでの設計業務に活かされている旨を発表しました。 speakerdeck.com www.youtube.com 発表にあるように、チームの合意やリソース戦略が不十分なまま大規模な設計変更を無理に進めると、反発や軋轢が生まれます。 そして組織全体での設計改善が困難になります。 そうした失敗経験を反省し、その後様々な技術書での学びから、課題と

こんにちは、READYFORでVP of Engineeringをしております、いとひろです。 この度、めでたくREADYFORのOSSポリシーをGitHub上で公開しましたので、共有いたします 👏👏👏 github.com OSSポリシー策定の背景 READYFORでは、息をするようにOSSにコントリビュートをしている @kotarella1110（React Hook Formコアコントリビュータ）や @yuji_developer（自作gem多数、OSSにPRやissueで貢献）や @ksss（CRubyやmrubyに貢献、最近はRBS関連の活動多し）をはじめとする多くのエンジニアがOSS活動を行なっています。 かくいう私自身も、かつてはEclipse CollectionsというJavaのOSSライブラリのリード・コミッターをしていたこともあり、OSS活動に対しては非常に前向

システム基盤部の栗原です。 RubyKaigi2022楽しみですね。READYFORからは、私栗原から発表させていただくことになりました。 https://rubykaigi.org/2022/presentations/_ksss_.html 今回は皆様によりトークを楽しんでいただく為に、予習となる要素を集めました。 何を話すのか orthosesというライブラリーを作ったので使って下さい！というお願いをします。 orthosesは簡単に言うと、RBSの自動生成ツールです。 github.com 抱えている課題感 私は型を使った開発で得られる体験に魅せられています。コードを書いたその瞬間にバグに気づいて修正したり、複雑なロジックでもどの変数でどのオブジェクトが得られるのかエディタで確認しながら開発できるの最高だと思いませんか？ Rubyでもそれ、できるんです！！！ しかしながら、開発体験

こんにちは、READYFOR DevHR の関根です。 2022年4月26日（火）に開催されたイベント、『良いコード/悪いコードで学ぶ設計入門』著者トークに、READYFORのバックエンドエンジニア、仙塲（ミノ駆動 @MinoDriven）が登壇しました！ 登壇者について ミノ駆動 @MinoDriven エンジニアリング本部 システム基盤部 バックエンドエンジニア 仙塲 大也（ミノ駆動） READYFORに2021年4月に入社 仙塲のSNSその他のブログは以下となります。 Twitter：ミノ駆動 @MinoDriven Tech Blog：リファクタリング効果を促進する組織ビジョン「乳化」 イベント内容について 『良いコード/悪いコードで学ぶ設計入門』の著者自身（仙塲）のトークイベントです。 本書のコンセプトや特徴、読み手に身につけていただきたいスキルを解説いたしました。また、本書を通

栗原(ksss)です。 新緑の季節になってきましたね。最近よく使う絵文字は🍀です。 READYFORでは貸与PCにて日々の開発を進めています。Apple社のMacBook Proを選択するエンジニアも多く、 「Apple M1チップの乗ったPCで開発できるのか、社の資産として購入・貸与していいのか？」といった問題がありました。 そして2022年4月中頃、長い戦いの末ついに対応完了となりました。 本記事ではREADYFORで行った"M1対応"の歴史を紹介したいと思います。 初期 2020年11月10日 M1発表 Appleが発表したCPU"Apple M1"*1は、後に"M1対応"という言葉も生み出すこととなりました。 ARMアーキテクチャーという、これまでRaspberry Piぐらいでしか使われていなかったCPUアーキテクチャーを採用しているため、多くのソフトウェアが未サポートだったA

こんにちは、リファクタリング大好きなミノ駆動です。 リファクタリングを主任務とするアプリケーションアーキテクトとして、弊社READYFORのエンジニアリングを推進しています。 ドメイン駆動設計に登場する 腐敗防止層 を用いたリファクタリングで、システムの変更容易性を向上したお話を解説します。 本記事の概要 イビツな構造を隔離する腐敗防止層を用いて技術的負債を解消 ふたつの橋作戦でリファクタリングの安全性を向上 設計技術書 『良いコード/悪いコードで学ぶ設計入門』 出版のお知らせ 背景 弊社READYFORのシステムは、モノリシックなRuby on Railsのサービスとして実装されています。 システムが解決したいドメイン（業務活動）にはさまざまなセグメントがあり、その中に審査オペレーションがあります。 審査オペレーションとは、クラウドファンディング実行者さんが申し込みを提出してからプロジェ

春ですね。先程、子供の保育園での最終登園を終え、万感の思いです。 システム基盤部の栗原(ksss)です。 この度、開発しているプロダクトのコードにRubyの型チェック機能を導入しました。 私が導入までに工夫したことを紹介したいと思います。これを読んでいる皆様のプロダクトにおけるRBS導入の参考になれば幸いです。 プロダクトとエコシステムをWin-Winに 社内の開発者にRubyの型に興味を持ってもらい、使ってもらうことができれば、フィードバックを得ることができます。 このフィードバックから開発体制を改善し、ひいてはツールの不具合修正や機能改善を提案することによって、Rubyエコシステム全体に貢献できます。 そうすれば、さらに開発体制が良くなる好循環が生まれると目論んでいます。 つまり最初の興味が大事なのです。 より興味を持ってもらうことを目的に、社内でRBSハンズオンを開催しました。 RB

はじめに こんにちは、READYFOR デザイナーの今野（@kyota）です。 こちらは READYFORアドベントカレンダー2021 の19日目の記事です。 こちらの記事では、READYFORのデザインシステムの負債に対してどのように戦っているかについて書いた内容となります。 なお、負債をキレイさっぱりしたぜ！という記事ではなく、まだ負債と戦っていて今後こうしていきたい！ということまでをまとめた内容となっています。 近年、デザインシステムを導入を多く見られるようになってきましたが、デザインシステムを運用後の課題についての情報はまだあまり無いかと思います。 そのため、デザインシステムを運用中の方や、これから導入を検討している方へ少しでも何かしらのヒントにしていただければと思います。 そして、もっといいやり方あるよ！などありましたら、コメントやTwitterなどにリプいただけると泣いて喜びま

この記事は「READYFOR Advent Calendar 2021」4日目の記事です。 Calendar for READYFOR Advent Calendar 2021 | Advent Calendar 2021 - Qiita フロントエンドエンジニアの吉井（@Takepepe）です。業務委託で READYFOR さんのお手伝いさせていただくようになってから、早いもので1年半が過ぎました。この期間中、3つの Next.js Application 立ち上げ・リリースに携わらせていただきました。 Cypress x BDD 現在携わらせていただいているのが「フロントエンド基盤SQD」という、READYFORプロダクト全般のフロントエンド課題をシューティングするスクワッドです。このスクワッドでの活動において、私が9月〜11月に取り組んだ課題が「テスト方針の見直し」です。 3つの N

こんにちは。バックエンドエンジニアの安本です。 弊社も、新しいサービスはPRODUCTIONでECSが動いております。 現在は、既存の動いているサービスのECS化移行に向け取り組んでいますが いろいろ考えることが多く、各社の記事を参考に四苦八苦しているところです。 Herokuから ECSに 移行した - pixiv inside ダウンタイムなしでEC2からEKSへ移行しました！ - Tech Inside Drecom ECS化検証の一環として、ecspressoに触れたので、マストドンをデプロイしたコードを共有します。 ecspressoとは やったこと サンプルコード Railsとsidekiqを別Serviceで起動させる デプロイフロー 準備 関連リソース構築 ECRにマストドンimageをpush タスクの作成 サービスの作成 ログの確認 ecspresso 既存サービスの取

こんにちは。READYFOR でフロントエンドエンジニアとして働いている菅原（@kotarella1110）です！ 嬉しいことに、READYFOR のプロダクト開発組織は急拡大中で、正社員の人数は 2019年7月時点では8名でしたが2021年4月現在は29名になりました 🎉 その反面、組織が大きくなってくると「我々はどこに向かってるんだっけ？」「あの人、最近はどんなことに取り組んでいるんだろう？」といった「見えないこと」が増えてきます🤔 この「見えないこと」を減らすために、READYFOR では毎月「プロダクト開発本部会」を開催しています。 プロダクト開発本部会では、必要な全体周知（組織やプロダクトの方針等）や月替わりプレゼンテーションを行っています。 本記事はこのプロダクト開発本部会の月替わりプレゼンテーションで発表した内容になります。 はじめに 以前 READYFOR で初主催とな

こんにちは、リファクタリング大好きなミノ駆動です。 2021年4月にREADYFOR株式会社にジョインしました。 概要 本記事は、なぜ私がREADYFORへのジョインを決断したのか、背景理由を記したエントリ記事です。 READYFORはサービス開始から約10年が経過。システムに相当な技術的負債が蓄積しているため、今後スピーディーにサービス拡大するためには負債解消が目下取り組むべき重要課題となっております。その課題解決のために私は誘われたわけですが、リファクタリングが十分に効果を発揮するには、設計技術面以外の様々なハードルを乗り越えなければなりません。 READYFORの組織ビジョン「乳化」が、ハードルを解消し、リファクタリング効果の大きな促進に貢献すると考えたため、ジョインを決断しました。 本記事では、技術的負債やリファクタリングにまつわる一般的な問題構造を解説した上で、READYFORが

こんにちは！エンジニアのtoyocです。みなさん『シン・エヴァンゲリオン劇場版』は観ましたか？僕は公開初日、仕事前に観に行ってきました！とても（あらゆる感想がネタバレになるので省略）でしたねー。 さて、突然ですが、READYFORには、 “evangelion” の名を冠したソースコードがたくさんあります。 “evangelion” の名を持つソースコードたち 実はこれらは、2015年に公開した「エヴァンゲリオン20周年公式 ロンギヌスの槍を月に刺すプロジェクト（以下「本プロジェクト」）」ページのソースコードです。 2015年に公開した「ロンギヌスの槍を月に刺すプロジェクト」 READYFORの他のプロジェクトページをご覧になった方はお気づきかと思いますが、かなりデザインや仕様の異なるプロジェクトページになっています。 今回は、2015年当時フロントエンドのコーディングを担当した僕が「ロン

2021年2月5日に、READYFOR主催としては初となるオンライン技術勉強会、【実践！フロントエンド分離戦略】を開催しました！本記事では、当日の様子と各セッションの内容を振り返ってみたいと思います。 readyfor.connpass.com 当日は実に最大240人を超える視聴者が参加してくださり、Twitterでもご好評の声をいただきました。当日の様子はこちらのTogetterでも空気感が感じられると思うので、ぜひご覧になってみてください。 togetter.com 1. READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話 まずはフロントエンドチームのエンジニアリングマネージャー岡村（@resqwork）による、「READYFORのフロントエンドを2019年末から全体像を構想してどうしていくか検討した話」です。 2019年8月に岡村がジョイン

こんにちは。READYFOR（レディーフォー）で CTO をしている町野です。 READYFOR Advent Calendar 2020 の25日目の記事になります。 はじめに 早いもので、2019年に READFOR に CTO に参画して、もうすぐ２年が経とうとしています。当時まだ10名に満たなかった開発チームは倍以上の人数になり、おかげさまで全社の社員数も100名を超える規模にまで成長しました。 組織が一定の規模を超えてくると、その規模に合わせた組織の構造化が必要になってきます。この記事では、READYFOR のプロダクト開発体制をご紹介しつつ、組織設計において必ず問題になる「境界マネジメント (boundary management)」について思考を巡らせてみたいと思います。 ミッションと専門性で分かれる組織単位：Squad & Chapter READYFOR では現在、Spo

これはREADYFOR Advent Calendarの19日目の記事です。 こんにちは、READYFORでバックエンドエンジニアをしている斉藤です。 この記事では私がREADYFOR入社時からコツコツと進めてきたRuby on Railsアプリでコードカバレッジ30%から50%にするためにやったことを時系列に紹介したいと思います。 みなさんはちゃんとテストを書いていますか？ 開発が忙しすぎて後回しになってしまうなんてことは良くあるかと思います。 しかしスタート間もないサービスだとそこまで困ることはないかもしれませんが、数年経ってくると色々な弊害が出てきます。 リファクタしたいけどテストがないから怖くてできない その場しのぎの継ぎ足しの変更を続けどんどん複雑なコードになっていく ちょっとしたコード変更にも時間がかかるようになる 明らかに不要そうなファイルやコードあるけど確信が持てず削除でき

こんにちは、READYFORでVP of Engineeringをしております、いとひろ（ id:itohiro73 ）です。 本記事はREADYFOR Advent Calendar 2020の記念すべき第一日目です。今年はREADYFORがアドベントカレンダーに初参戦！メンバー一同完走目指して頑張ってまいりますのでどうぞよろしくお願いします。 さて、READYFORでは「誰もがやりたいことを実現できる世の中をつくる」というビジョンのもと「想いの乗ったお金の流れを増やす」というミッションに取り組んでいます。そのために大切にしている価値観が「乳化」という概念です。本記事ではこの乳化という概念と、その状態を目指すためのいくつかの取り組みについて説明します。本記事は今年の夏に開かれた デブサミ2020夏 の講演内容に加筆修正したものになります。 READYFORでは、 「組織の中にエンジニアリ

はじめに こんにちは！READYFORでフロントエンドエンジニアをしております、江面（ @neripark ）と申します。 最近は主に Next.js （TypeScript）を用いたSPA開発に従事しております。CSS設計、コンポーネント設計、Netlify などが好きです！ 本日はタイトルにもある通り、既存のRailsアプリケーションにCSSコーディング規約を導入したお話をしようと思います！ 既存のプロダクトのCSSで苦労している方の参考になれば幸いです。 これまでのREADYFORのCSS READYFOR は2011年にスタートした、日本初のクラウドファンディングサービスです。 その中身は Ruby on Rails で組まれた標準的なモノリシックWebアプリケーションで、サービスの成長とともに、機能開発も重ねられていきました。 その流れの中で、いろいろなエンジニアがいろいろな文脈

こんにちは、エンジニアリングマネージャーの岡村です。 社員全員テレワークの環境にも慣れてきて、ワークフロー改善と共にREADYFORの開発環境も日々改善しております。 概要 StorybookをNetlifyへホスティングすることで、PR単位でデプロイされるためデザインの確認・レビューがとても楽になったので紹介です。 導入の背景 READYFORのアーキテクチャ上もっとも有効だった ざっくりREADYFORのフロントエンドアーキテクチャはReact On RailsとElements(UI Library)で構成されており、デザイン手法にAtomicDesignが採用されています。 Elements(UI Library)はDesignSystemの一部として構成され、ドメインに依存しないコンポーネントはElementsへ開発しています。 そのため、確認をする際にはElementsのコンポ

こんにちは。READYFOR 株式会社で SRE として働いている ジェダイ・パンくず🚀 と申します。 突然ですが、皆さんの現場ではインフラのテストの仕組みは導入済みですか？我々はまだ出来ていません(笑)。 READYFOR では IaaS として AWS を、IaC として Terraform を導入しているのですがコードのテスト・コードによってデプロイされた状態のテストを何かしらの仕組みを使って実践したいなぁと考え、今調査している最中です。 今回は Terraform のテストを書くツール Terratest について調べた内容を皆さんに共有したいと思っています。また AWS の状態をテストする仕組みとしてよく知られている Awspec との比較も行っていきたいと思っています。 必要になるモノ 事前に必要になるソフトウェアの一覧です。 Golang (requires version