こんにちは。食べログでAndroidアプリのテックリードをしているsadaです。 今回は食べログAndroidアプリの自動テスト戦略についてご紹介したいと思います。 目次 そもそもテストコードはなぜ必要なのか テストコードにおいて大事なこと 自動テストの信頼性 できるだけ早い段階で検出する 継続的な保守 食べログAndroidアプリの自動テスト戦略 テストコードを書く文化を根付かせる 一番欲しいフィードバックを考える バランスよく積み上げられる 実際進めてどうなったか まずはSmallテスト主軸に 次にMediumテストでカバー範囲を広げる 今後の展望 Largeテストを作り、手動テストを減らしていく フィードバックを早める テストの信頼性をより高める まとめ そもそもテストコードはなぜ必要なのか まず自動テスト戦略のお話をする前に、テストコードがなぜ必要なのかについて考えてみましょう。
Next.js + TypeScript + Recoil + Herp社ESLint Config でReactチュートリアルを作る。
制作したもの 概要 React のチュートリアルの三目並べを Next.js 12 + TypeScript + Recoil + @herp-inc/eslint-config の構成で、新しめの記述を取り入れた形に書き直してみた。 （上記のリポジトリにすべてのコードを掲載した。） コンセプトは、 TypeScriptの型チェックと厳しめのESLintルールでバグが起きづらい形にし、スケールしても内部品質を担保。 Next.jsで作ることにより、ブラウザでのパフォーマンスと開発体験の向上 である。 改良したいポイント React のチュートリアルの三目並べ（マルバツゲーム）の公式サイトに掲載されている元のコードは以下である。 この code に関して、以下のような課題が考えられる。 React の書き方が、現在では非推奨のクラスコンポーネントである。（関数コンポーネント + React
freeeカードチームの開発(Go)から得た学びベスト5 - freee Developers Hub
この記事はfreeeアドベントカレンダー2023の19日目の記事です。 こんにちは！freeeカードチームのmattsunです。freeeカードUnlimitedの開発運用をしています。私は1年前にfreeeに入社しfreeeカードチームに所属しています。これまでの自分のエンジニアとしてのキャリア（10年強）を通してみても、今のチームではPRレビューやリファクタなどからの学びが多いなぁと感じます。個人的に学びがあったことやチームとしての知見が深まったもののうち、ベスト5（私の主観）をまとめます。 freeeカードシステムは、フロントエンド(TS,React)・BFF(RoR)・Backend(Go)で構成されており、Goでの開発比率が多いことから、本記事はGoのコードに関する言及が多いです。freee社全体をみるとRailsで開発されたシステムも多いですが、Goで開発しているサービスもある
山奥の砦（八王子市）からminneのiOSチームでアーキテクチャや開発環境を色々と見ているjoshです。SwiftUIとCombineが発表されたWWDC 2019から、SwiftUIとUIKitの混在状態を前提としたminneアプリに最適なアーキテクチャについて検討・議論した結果、最近色々と決まったので、紹介したいと思います。 まず、アーキテクチャ決めの目的ですが、テストしやすい形で迷わずに開発でき、機能開発を効率よくしつつ、今後の保守や変更も楽に行い、生産性と品質を上げることです。minneは特徴として、ネットワーク通信の多いアプリで、Universal Linksやプッシュ通知など、数多くの起動経路を持っています。また、minneマーケットプレイスの作品をさまざまな購入方法で提供しているので、開発をする中で特にその周りで不具合が出ないように日々開発しています。作家、購入者・ゲストごと
2017年11月 原著発売 『Clean Architecture A Craftsman’s Guide to Software Structure and Design』 2018年7月 日本語訳発売 『Clean Architecture 達人に学ぶソフトウェアの構造と設計』 2018年〜2019年 ソフトウェア設計界隈でCAが流行 2019年夏 新規プロダクト開発で、CAを採用 振り返って みる 2021年1月 プロダクトのリリース 〜2024年現在 継続開発中
re-why-the-clean-architecture-does-not-fit-with-web-frontend.md
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
挨拶 こんにちは。2023年04月に入社した、minne事業部エンジニアの@kazuです。 この度、弊社GMO ペパボ(以下、ペパボ)では2022年に引き続き、今年も日本のTest-Driven Development(TDD) の第一人者である @t_wada さんをお招きしてTDDワークショップを開催しました。前回：『t_wadaさんによるTDDワークショップを開催しました』 なぜTDDワークショップを開催しているのかについては、こちらの記事『ふつうの開発と TDD ワークショップ』で詳しく説明していますのでご覧ください。 さて、それでは今回のTDDワークショップで何をしたのか、どんな気づきがあったのかなどについて、参加パートナーからそれぞれお話ししてまいります。 具体的な研修内容 概要 ワークショップは、事前に各参加パートナーが基調講演/ライブコーディングの動画を予習し、動画内でのラ
クリーンアーキテクチャをパン工場で説明する【Go】
はじめに 本記事は技術書典16(2024)で一部執筆させていただいた「CA Tech Lounge note #2」のクリーンアーキテクチャとパン工場を元に、一部抜粋＆変更したものです。 本記事の対象読者 本記事では、クリーンアーキテクチャを全くわかっていない筆者が、一度個人開発したものをクリーンアーキテクチャにリファクタリングしていく過程で学んだことをまとめていきます。そのため、以下のような読者を想定しています。 クリーンアーキテクチャを聞いたことがあるけどわからない人 コードは書くけれどアーキテクチャを意識したことはない人 アーキテクチャを意識して開発したい人 クリーンアーキテクチャを一度学んでもピンと来なかった人 Goが好きな人！ リファクタリング前の筆者の状況 バックエンド歴は半年弱ほどで、実務経験としてはPythonで簡単なAPIを実装するアルバイトのみになります。アーキテクチャ
みなさまこんにちは、グリー株式会社でCTOをやっておりますふじもと (@masaki_fujimoto) と申します。 今回は1週間後に控えたGREE Tech Conference 2022の宣伝も兼ねて、1年ぶりくらいにソフトウェアについてつらつらと書いてみます。というか、なにはなくとも10/25 (tue)、来週開催のGREE Tech Conference 2022にぜひぜひご参加ください。ひさびさにオフラインでも開催しますので！ あとついでに、1年くらい前からデジタル庁というところのCTOも兼ねさせていただいてまして、なんかやっぱりあれこれ質問いただくことも多いので、そのあたりどうよ、みたいなところもついでに少しだけ触れてみたいと思います (なんかGREE Engineers' Blog、というところで書くにはちょっとコンテキスト違うかなとも思うのであくまでおまけ、ってことで..
iOSプロジェクトに対してモジュール分割しながらSwiftUIを部分適用している事例 - Mirrativ Tech Blog
こんにちは、クライアントエンジニアの竹澤(@to4iki)です。 MirrativのiOSチームでは、開発効率の最大化を狙い以下に取り組んでいます。 データフローの単方向化 (Fluxアーキテクチャの強制) 宣言的UIによるView実装 (SwiftUIの部分適用) 責務分割 (モジュール分割) 今回の記事では、どのような構成でSwiftUIを適用し始めたか、また、MirrativのiOSプロジェクトの構成やプロダクト特性の課題感からセットでモジュール分割を進めている点を紹介します。 背景 前提となるプロジェクト構成 導入に向けて決めたこと SwiftUIでどこまで実装するか 本体アプリではなくSwiftPackageを活用する 垂直分割するか水平分割するか 方針やTipsを明文化し育てる 新規開発部分のUI開発をFeatureモジュールで行う SwiftPackage: SwiftUI.
特定保健指導"フィッツプラス"事業を支えるモノリシック Rails + VIPER Swift アーキテクチャ - メドピア開発者ブログ
みなさんこんにちは。フィッツプラス開発エンジニアの福本（@terry_i_）です。 早いもので入社して半年が経ちました。普段はRailsを中心に色々と書いてます。 リモートワークが長く続いていることもあって、最近は自宅の開発環境を（過剰に）整備するのがマイブームです。先日はlogicoolのPCスピーカーを買いました。所得がゴリゴリ削られていってツラい。 さて今回は、これまで忙しくて紹介する機会のなかったフィッツプラスの事業概要や、アーキテクチャおよび使用する技術についてお話しします。 アーキテクチャに悩むエンジニアの方の参考になったり、皆さんのフィッツプラスへの事業理解が深まれば幸いです。 特定保健指導とは？ アーキテクチャ モノリシック Rails ActiveModelSerializers OpenAPI Houston(プッシュ通知) Banken(権限管理) VIPER Swi
はじめに RustでWebアプリケーションのGraphQLバックエンドを実装してみました。その中で、できるだけClean Architectureに沿うように実装してみたので、得られた知見を公開してみたいと思います。 資料に基づきできるだけ正確な記述を目指していますが、誤りもあるかもしれません。また実装から少し時間を空けて執筆しているので、忘れている部分も多く不正確なことが書いてあるかもしれません。 Clean Architectureとは 以下のブログでRobert C. Martin（通称Uncle Bob）によって提唱されたアーキテクチャです。 その後本人により書籍も出版されました。日本語にも翻訳されています。 歴史について簡単に 多層アーキテクチャ (Multitier architecture) というものはかなり昔から考えられていたようです。初出についてはよくわからないのですが
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
【LT参加レポート】「Goと面と向かう」というテーマで発表してきました！ - カミナシ エンジニアブログ
初めまして。株式会社KAMINASHIでPMをやっている@gtongy1です。 弊社ではサーバサイドの言語としてGoを活用しています。 自分はカミナシに入って約1年ほどになりますが、カミナシは創業して以来サーバーの言語はずっとGoを使って開発しています。 カミナシではちょうど自分が入ったタイミングで新規プロダクトの開発を開始していて、このプロダクト内でもGoが大活躍してます。 改めて成長する事業に寄り添い柔軟に形を変えられる、Goの魅力をひしひしと感じます。 発表の内ではそんな自分がGoとどう向き合い、課題を解決していったのかを話してきました。 スタートアップで自分はGoとどう向き合ってきたか 僕の好きな本の「UNIXという考え方」で語られている スモールイズビューティフル 一つのプログラムには一つのことをやらせる できるだけ早く試作を作成する この3つが自分の中でGoを利用する理由に合致
GitHub - amitshekhariitbhu/go-backend-clean-architecture: A Go (Golang) Backend Clean Architecture project with Gin, MongoDB, JWT Authentication Middleware, Test, and Docker.
A Go (Golang) Backend Clean Architecture project with Gin, MongoDB, JWT Authentication Middleware, Test, and Docker. You can use this project as a template to build your Backend project in the Go language on top of this project. Before creating this project, I have gone through more than 20 projects related to the Go(Golang) Clean Architecture on GitHub. Thanks to all those projects, I learned a l
プロダクトエンジニアリング部の海老澤です。 普段は LIFULL HOME'S の賃貸部門のフロントエンド開発をしています。 近年、LIFULL の開発部門では「開発生産性」という言葉が取り沙汰されるようになりました。 LIFULL HOME'Sの主要リポジトリは10年以上運用され続け、今も多くの開発者によって日々改修され続けています。 長い年月の中で小さな設計ミスも積み重なって大きくなり、ちょっとした実装でも入念な調査が必要となり開発生産低下の要因となっていました。 また10年以上前に採用したフレームワークで稼働しているため、今ではドキュメントを探すのも一苦労という具合です。 そこで主要開発部門では「自部門の機能はマイクロサービスへと切り離し、各々で面倒を見る」という方針になりました。 賃貸部門も同様に機能の切り離しを始め、先日「物件詳細ページ」のマイクロサービス化を行いました。 今回は
SOLID原則で考えるReact設計
こんにちは、株式会社スタメンでオンラインサロンFANTSのフロントエンドエンジニアをしている@0906kokiです。 今回はSOLID原則の5つの設計原則を、Reactのコードをベースにして解説できればと思います。 SOLID原則とは？ SOLID原則とは、ソフトウェアを柔軟に、メンテナンス性を高く設計するための5つの原則となります。 Robert C. Martinによって、5つの原則の頭文字をとってSOLIDという名前が付けられました。5つの原則とは以下の通りです。 SRP: 単一責任の原則 OCP: 開放閉鎖の原則 LSP: リスコフの置換原則 ISP: インタフェース分離の原則 DIP: 依存性逆転の原則 元々、SOLID原則はJavaなどのオブジェクト指向プログラミングに対して、メンテナンス性の向上や分かりやすいプログラムを担保するために提唱された原則ありますが、オブジェクト指向
モバイル開発マネージャー厳選！キャリアアップの必読書10選 - RAKUS Developers Blog | ラクス エンジニアブログ
はじめに ラクスが開発する楽楽精算は、東京開発統括部の楽楽精算開発部が担っています。 楽楽精算のiPhone（Swift）& Android（Kotlin）対応のモバイルアプリ開発を担当しているのが、モバイル開発課です。 本記事では、楽楽精算のモバイルアプリ開発案件を担当しているモバイル開発課のマネージャーが厳選した 「モバイル開発を軸に、キャリアをステップアップするために役立つ書籍」をご紹介します。 それぞれの書籍に推薦コメントを記載していますので、是非ご参考になさってください。 はじめに モバイル開発でおすすめの書籍 Androidを支える技術<Ⅰ・Ⅱ> iOSアプリ設計パターン入門 Androidアプリ設計パターン入門 プロダクト開発・アジャイル開発でおすすめの書籍 プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける プロダクト開発の罠：エンジニアの最大稼働率が生む遅延と
はじめに @june29 と申します。2021年5月からminne事業部のシニアエンジニアリングリードを担当しています。 「ペパボの採用目的2021」というムーブメントに乗っかって、この記事ではminne事業部の様子を紹介します。Webアプリケーションやモバイルアプリケーションの開発に携わるソフトウェアエンジニアが主な想定読者です。ペパボやminne事業部でのお仕事がどんなものか、少しでも興味を持ってもらえたらうれしいです。 minneの事業と組織 minne(ミンネ)は、ハンドメイド作品を「買いたい人」と「売りたい人」をつなぐ国内最大のハンドメイドマーケットです。iOSアプリ、Androidアプリ、Webブラウザからご利用いただけます。 すでに多くのみなさんにご利用いただいている状況ですが、今後も老若男女あらゆる立場の人にもっともっと楽しんでいただけるよう、ライフスタイル領域全般の素敵な
【感想】『Clean Craftsmanship 規律、基準、倫理』：ボブおじさんの熱い職人魂本 - Rのつく財団入り口
オレたちのUncle Bobが帰ってきた！ ITエンジニアが読むべき名著にオールタイムで名前が上がるCleanシリーズ。作者はアジャイルマニフェストのその場にいた一人でもあるロバート・C・マーチン御大、通称Uncle Bob。→Wikipedia: Robert C. Martin, プログラマが知るべき97のこと 『Clean Agile』に続く本書は、クラフトマンシップをもったプロのエンジニアであろうという在り方をメインに述べ、過去の一連の本で述べられてきた主張も含めた集大成的な本になっています。 おおお...あのシリーズに続きが出た...ということで震えながら読んだので以下読書記録です。 オレたちのUncle Bobが帰ってきた！ 第I部 規律 第1章 クラフトマンシップ 第2章 テスト駆動開発 第3章 テスト駆動開発応用 第4章 テスト設計 第5章 リファクタリング 第6章 シンプ
はてなブックマークのブックマーク数が多い順に記事を紹介する「はてなブックマーク数ランキング」。3月3日（月）～3月9日（日）〔2025年3月第2週〕のトップ30です*1。 順位 タイトル 1位 人類はもう生成AIに勝てないと痛感したDeep Researchの使い方 #ChatGPT - Qiita 2位 退職代行業者撃退マニュアル 3位 エンジニアってなんか性格悪い人多くね？ 4位 リュウジさん「金沢駅近辺でここいっとけって美味しいお店教えてください」→おでん、すし、ラーメンなど、みなさんおすすめの金沢グルメが集結 美味しそうな料理の写真も盛りだくさん - Togetter [トゥギャッター] 5位 おすすめの音楽サイトを延々と紹介していく記事 | 仁義なき音楽巡り 6位 １０億円かけた虐待判定ＡＩ、こども家庭庁が導入見送り…ミス６割で「実用化困難」 : 読売新聞 7位 クレカの表現規制
リモートワーク環境での勉強会、みんなどうしてる？VOYAGE GROUP の読書会について紹介します！ - CARTA TECH BLOG
こんにちは！fluct でインターネット広告配信のお手伝いをしている @jewel_x12 です！今日は VOYAGE GROUP における、リモートワーク環境での勉強会について書きます。 VOYAGE GROUP では以前から勉強会を実施しています(例えばReactハンズオンなど)。部署や若手・シニアを問わず、社内バーの AJITO 等に集まってワイワイやっていました。COVID-19の状況が収まらない今のご時世ですと、AJITO でワイワイってのはできなくなっています。 なので勉強会もオンラインでせざるを得ない状態です。そんな中、みなさんはどうやって勉強会を進めてますか？VOYAGE GROUP ではリモートワーク環境でも社内勉強会が活発に行われているので、その様子を紹介できたらと思います。 社内では論文読み会などの勉強会も行われていますが、読書会だけでもたくさんあったので、今回は読書
An interface is not an interface - Recent thoughts about clean coding - spacelyのブログ
Introduction Recently I've had to work on code which seemed to be based on clean architecture, but after a while I concluded that it is probably not and it made me think about clean coding in general and the principles of clean architecture in particular. Is it about a set of rules, and we are guaranteed to achieve cleanness as long as we follow them? Or is it about abstract principles, which we c
ここ半年ほど、仕事で Flutter アプリを 0 から作り直しています。 ちょうど今年の個人的なテーマを「アーキテクチャ」に据えていたこともあり[1]、またその一環として 「Clean Architecture 達人に学ぶソフトウェアの構造と設計」 （以下：クリーンアーキテクチャ本）を読んでいたこともあり、この作り直しでは「アーキテクチャ」をしっかりと自分の頭で考えながら作ろうと決めて取り組んできました。 アーキテクチャについて頭を悩ませながら実装を進めること約半年、ようやくアプリが形になるとともにある程度知見も溜まってきましたので、その知見を一般化した内容をこの記事にまとめていきたいと思います。 注意 この記事は、「Flutter アプリのアーキテクチャはこれがベストプラクティス！」という類の記事ではありません。あくまで 私の目の前の要件ではこれが最適と判断した という一例の紹介になり
【感想】『読みやすいコードのガイドライン―持続可能なソフトウェア開発のために』：Kotlinでモダンなコード指南 - Rのつく財団入り口
リーダブルコード的な本が新たに登場っす！ (しかもKotlinなの) 読書記録と感想です。著者の石川宗寿さんはLINEでご活躍中のシニアエンジニア。元は2019年に公開されたプレゼンテーション「Code Readability」を元に書籍化されたとのことで、モダンな大規模開発やコードレビューやリファクタリングで得られた現場の経験を通して、可読性の高いコードを大テーマに知見が詰まった一冊となっています。 リーダブルコード的な本が新たに登場っす！ (しかもKotlinなの) 第1章 可読性の高いコードを書くために 第2章 命名 第3章 コメント 第4章 状態 第5章 関数 第6章 依存関係 第7章 コードレビュー まとめ：Kotlinを題材にした2020年代のモダンなコード指南の書 おまけ リンクと関連書籍 読みやすいコードのガイドライン -持続可能なソフトウェア開発のために 作者:石川 宗寿
Clean Agileを読んだ Clean Agile 基本に立ち戻れを読んだ。 www.amazon.co.jp 筆者はClean CodeやClean Architectureの書者であるボブおじさんことRobert C. Martin氏で、アジャイルの提言者の一人である（ということを本書を読んで知った）。 私自身はアジャイルやXPについては大学在学時に数冊読んだことがあり、また実際に現職でもいくつかのチームではアジャイルの手法を用いて仕事を行っている。とはいえアジャイルについてなんとなくしか把握しておらず、またボブおじさんの新作（以前にClean Code、Clean Coder、Clean Architectureの3冊を読んだことがある）ということで購入して読んでみた。 学んだこと アジャイルの成り立ちとその概念 アジャイルのプラクティス アジャイルとそれを取り巻く誤解について
【登壇資料】「Software Design 定期購読のススメ」というタイトルで「おすすめの技術書 LT会 vol.3 #itbookslt 」に登壇しました | DevelopersIO
おすすめの技術書 LT会 vol.3 #itbookslt とは 株式会社ラクスが運営するエンジニア向け勉強会のひとつで、今回は「おすすめの技術書」がテーマの LT 大会です。 登壇資料 今回はそちらに3分 LT で登壇させていただきました。 タイトルは「Software Design 定期購読のススメ」です。 感想 前回 LT 大会に登壇してから半年も空いてしまったので緊張しました。（声震えてましたよね……？） 私自身が Software Design を定期購読したのは実は去年ですので一緒に読む人を増やしたい、たまに弊社のメンバーが寄稿しているので応援したいそういった意味を込めて紹介させていただきました。 また他の登壇者が紹介していた本は「Googleのソフトウェアエンジニアリング」や「Clean Architecture」や「Web APIの設計」や「Design It!」などがあり
お疲れさまです！FE（フロントエンド）チームリーダー 兼 JIRA職人 兼 残業警察の辻です。 チームでjQuery→React/TypeScriptのリプレースプロジェクトを進めています。技術的なチャレンジはもちろん、大規模かつ長期プロジェクトゆえの不安と日々戦っています。 ・このプロジェクトはちゃんと進んでるの？このまま進めていいの？ ・成果が出るまでに時間がかかり、チーム外からは何もやってないように見えてない？ ・残業すれば初期計画スケジュールに間に合うけど、どれくらい頑張ったらいいの？ ・初めてのパターンだけど書き方これであってる？今後もこれに合わせる？ ・リプレース中にもどんどん技術が変わっていってキャッチアップが大変 ・チーム外から突然の依頼があったけど、優先度どうしよう...これらの不安と戦うため、いつでもプロジェクトの状態がわかる状態、いつでもチームに相談できる状態、個人依
はじめまして。2023年4月に新卒として株式会社ZOZO(以下ZOZO)に入社しました、財部彰太(たからべ しょうた)と申します。 この記事では、現在私が所属しているZOZOTOWN開発本部ZOZOTOWNアプリ部にて2022年5月から2023年3月までの期間で参加した内定者アルバイトについての話をさせていただきます。参加した理由、結果、そしてアルバイトを通して知った会社・チームの素敵な点を紹介させていただきます。ZOZOに興味がある人、内定後の動きに不安がある人、そもそも新卒でエンジニアとして働くか迷っている人、色々な人に読んでいただけたら幸いです。 内定者アルバイトとは 私が内定者アルバイトに参加した目的 ZOZOでの内定者アルバイトとは 実際にアルバイトをした部署、チームの話 なぜZOZOTOWN Androidチームにしたのか ZOZOTOWN Androidチームはどんなチームな
扱わないこと この記事では具体的なReactディレクトリ/コンポーネント設計を扱いません。具体的なデザインパターンも扱いません。 では、何を紹介するのか？ Reactの思想とSOLID原則を用いると、どのようにReactディレクトリ/コンポーネント設計を考えることができるのかを考察したいと思います。 SOLID原則はいかなるシステム開発においても転用できる原則だと思います。 更に、Reactディレクトリ/コンポーネント設計は複雑になりがちで、TypeScript、状態管理ライブラリ、CSS、コンポーネントライブラリ、フェッチライブラリ、テストライブラリと考えることが多く、ケースバイケースだと思います。よって、具体的な解を持つよりも、抽象的な考え方を理解したほうが良いと思いました。 よいディレクトリ/コンポーネント構造はなんだろう？ シンプルに以下の2点だと思います。 見つけやすい 変更に強
あけましておめでとうございます！ Findy Tech Blog編集長でソフトウェアプロセス改善コーチの高橋（@Taka_bow）です。 昨年2月末にスタートしたFindy Tech Blogが、なんと総PV数30万を突破しました！ ここまで成長できたのも、記事を読んでくださる皆さんのおかげです。本当にありがとうございます。 今日は2024年、特に人気を集めた記事をいくつかの視点からピックアップしてご紹介します。技術のトレンドから生産性向上テクニックまで、きっと皆さんの関心に響く記事が見つかるはずです。 それでは早速、ふりかえっていきましょう！ 2024年下期トピックス ITmedia NEWSの「IT企業デスクツアー」に取り上げて頂く 「修行をした話」から広がった新しい試み 【2024年】年間総PV数ランキングTop3 第3位 第2位 第1位 【2024年】はてなブックマーク数Top3
クリーンアーキテクチャのUsecaseはなぜControllerへ値を返すのではなくOutput PortとしてPresenterを呼び出すのか - Runner in the High
何を言っているのかと言うと、みんな大好きクリーンアーキテクチャの右下に図示されているFlow of Controlのこと。 黒線が引かれているということは、つまりUsecaseの中でOutput Portのインターフェイスを持つPresenterの関数なりが最終的に実行されるということである。 ここで湧き上がってくる疑念は「UsecaseがPresenterを呼び出さなくてもControllerに返り値とかで値を返して、Controller経由でPresenterに渡して実行しても同じなんじゃないの？」である。つまりOutput Portというインターフェイスそのものを撤廃してControllerにPresenterを使わせるアイデアである。たしかに、仮にこの方針で行ったとしても依存の方向が壊されることはない。 Software Engineeringでは同様の質問がかなり盛り上がっている
新規でAndroidアプリを作る際に役立った考え方 #famm年賀状2022 #android #kotlin - Tech Blog
こんにちは、Androidエンジニアのtsutouです。 今年は夏ごろから去年iOS版をリリースしたFamm年賀状アプリのAndroid版を開発し、無事リリースすることができました。 play.google.com 半年ほどで新規アプリをリリースまで持っていくのは大変でしたが、外部のメンバーと協業し、吸収できたポイントがたくさんありました。 その時に役立った知見/考え方を共有できればと思います！ どんなアプリ？ Fammで使っている写真を加工して使ったり、好きな文字を印字して、簡単に年賀状が注文できるアプリです。 マイデザイン機能や宛先登録機能で、再注文もしやすい設計になっています。 ぜひ！今年は年賀状を！ 😙 さまざまなテンプレートがあり、写真の穴のパターンも膨大にあるので、開発者側から見るととても画像の加工周りが1番の壁になりそうだなという印象で、実際にそうでした。 まず、設計的な部
CA.unityはサイバーエージェントが運営するUnityをテーマにした勉強会です。サイバーエージェントのサービス開発者と社外の開発者を交えて、Unityに関する知見を共有します。とりすーぷ氏からは、設計とアーキテクチャについて発表がありました。 アーキテクチャの目的はコストの最小化 とりすーぷ氏：「Unityにおける設計パターン」というタイトルで発表します。よろしくお願いします。 私は、とりすーぷという名前でいろいろと活動をしています。Microsoft MVPを2018年から継続で受賞しています。ありがとうございます。最近『UniRx/UniTask完全理解』という本を出したので、もしよければ手に取ってみてください。 今回は、設計とアーキテクチャに触れたいと思っています。10分の発表に対して、調子に乗って100枚を超えるスライドを作っちゃって、絶対に10分では終わらないので、発表はだい
はじめに こんにちは。クラシルのAndroidアプリチームのテックリードのうめもりです。 皆さん、Gradleのモジュール機能は活用していますか？ソースコードの依存の方向をモジュール単位で強制出来ることでアーキテクチャーの制約を強制しやすかったり、並列ビルド・差分ビルドの局所化によるビルド高速化を期待できたり、大規模なAndroidアプリを作るにはとても役に立つ機能ですよね。 そんな役に立つ機能ですが、実際どうやって活用していけばいいか分からなくて導入に踏み切れない方や、導入してみたがいまいち恩恵が感じられない、そんな方もいらっしゃるのではないでしょうか。 ところで、Androidアプリを開発してきた皆さんなら一度は聞いたことがある言葉にClean Architectureというものがあると思います。 引用: クリーンアーキテクチャ(The Clean Architecture翻訳) |
【連載 第8回】QAがfreeeカードUnlimitedのスクラムチームメンバーとして取り組んでること - freee Developers Hub
こんにちは、freeeでQAエンジニアをしているymty（ゆもつよ）です。この記事はfreeeカード Unlimited の開発の裏側について紹介する連載の第8回目（最終回）になります。 今までの連載の中で、freeeカード Unlimitedのアーキテクチャーやインフラといった技術的な側面や、若い優秀なエンジニアや、EMからエンジニアにロールチェンジした敏腕エンジニアが取り組んでいること、そしてEM（エンジニアリングマネージャー）がどのようにチームに関わっているかといった話題がありました。 【第1回】freeeカード Unlimited の開発の道のり 【第2回】freeeカード Unlimited での非同期通信の設計と実装 【第3回】EMから再度エンジニアとしてプロダクト開発に挑戦して学んだこと 【第4回】freeeカード Unlimited でのClean Architecture
TypeScriptによるGraphQLバックエンド開発 ──TypeScriptの型システムとデータフローに着目した宣言的プログラミング - TECH PLAY Magazine
一休のSaaSサービス「RESZAIKO」開発チームは、フロントエンド開発における時系列に基づく状態遷移、宣言的プログラミングをバックエンド開発に採用。開発時のアーキテクチャやコンテキストのギャップを軽減するチャレンジに挑んだ。その取り組みやアーキテクチャについて、CTO伊藤直也氏が語った。 きっかけは、フロントエンドとバックエンドの技術的関心事のギャップ 株式会社 一休 執行役員 CTO 伊藤 直也氏 今回のイベントで、「RESZAIKO」のバックエンドチームでチャレンジした開発手法について語ってくれたのは、株式会社一休のCTOを務める伊藤直也氏だ。伊藤氏はまず、今回のTypeScriptでのGraphQLバックエンドを開発するに至った背景を、「フロントエンドとバックエンドの技術的関心事と開発スタイルのギャップ」だと切り出す。 例えば、フロントエンドがReactで開発した場合、React
エクサウィザーズのTLが実践する、開発が遅くならないテストの書き方 - エクサウィザーズ Engineer Blog
この記事について この記事ではエクサウィザーズの介護記録AIアプリ「CareWiz ハナスト」(以下ハナスト)の開発スピードを維持するために、どのようにテストを書いているかをご紹介します。 内容としては基本的なことかと思うので、ハナスト開発ではどのような基本に則ってテストしているかという感じで読んでいただければ良いかと思います。 書いているのは誰？ この記事はハナスト開発チームのテックリードをしている原(@haracane)が書いています。 ハナストチームでは主にNode.js&TypeScriptでバックエンドAPIを開発していてテストにはJestを使っています。 ちなみにこれまではKotlin&JUnitやRuby on Rails&Rspecなどで開発＆テストをしたりしてました。 ハナストについて ハナストは簡単に言うと「音声入力で介護の記録をするアプリ」です。 以下の動画を見ていた
【DDDを志して3年経ったら「DDDの皮を被ったクリーンアーキテクチャ」になった話】というタイトルでDevelopers Summit 2024夏に登壇しました。 ▼登壇資料 本記事では「登壇内容」、「登壇した経緯」、「登壇内容への自分自身の振り返り」の順でまとめていきます。すでに登壇を聞いていただいたり資料を見ていただいた方は、後半の章から読んで頂けますと幸いです。 登壇内容 どんな発表？ よくある取り組みや設計ルールに対して 「無視していること」 「遵守していること」 「バランスを取っていること」 をそれぞれ事業・組織・プロダクト特性などの観点から説明します。 つまり アーキテクチャ論でよく聞く「要はバランス」の具体例を徹底的に解説します！ 私がアーキテクチャを学んだ経緯 CTOが「要はバランス」と言いたくなるアーキテクチャ論を、スタートアップの立ち上げを通して学んできた経緯を話しつつ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 「理解容易性」は「保守性」の観点の1つとして重視され、多くの原則や技法が紹介されているが、断片的かつ多様であり、全体像を理解することは難しい。 抽象度は高いが、体系的に観点を整理する事で、その理解の助けとなれば幸いである。 定義 「理解容易性」を簡単に言えば、「理解のしやすさ」であるが、その意味から掘り下げると、「思考する量」と言い換えることができる。 本記事では理解容易性を「思考量の少なさ」と定義し、7つの観点に整理した。 先に要約およびチェックリストを記載し、概略を記載した。 後に詳細で理解のため、各観点毎の説明と個別の原
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
食べログAndroidアプリの自動テスト戦略 - Tabelog Tech Blog
SwiftUI時代におけるminneのリアクティブアーキテクチャ - Pepabo Tech Portal
やってみてわかった クリーンアーキテクチャの勘所 | ドクセル
twadaさんによる2023年度版TDDワークショップを開催しました - Pepabo Tech Portal
オブジェクト指向のはなしとGREE Tech Conferenceのおしらせ | GREE Engineering
RustでClean Architectureを実装してみる
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
LIFULL HOME'S 賃貸物件詳細ページの基盤刷新について - LIFULL Creators Blog
採用目的2021 minne編 - Pepabo Tech Portal
今週のはてなブックマーク数ランキング（2025年3月第2週） - はてなブックマーク開発ブログ
【Flutter】アプリ全体のアーキテクチャを0から考えて作り直した話
Clean Agileを読んだ - 読書メモ
不安に強い食べログFEチームの働き方｜食べログ フロントエンドエンジニアブログ
ZOZOTOWN Androidチームで内定者アルバイトをした話 - ZOZO TECH BLOG
React公式&SOLID原則からReactディレクトリ/コンポーネント設計を考察⚡
2024年ふりかえり！Findy Tech Blogの人気記事まとめ - Findy Tech Blog
万能なアーキテクチャは存在しない Unityのプロジェクトにあわせたアーキテクチャの“育て方”
Clean Architectureで考えるAndroidのモジュール設計 - dely Tech Blog
DDDを志して3年経ったら「DDDの皮を被ったクリーンアーキテクチャ」になった話
理解しやすいコードの書き方～理解容易性の7つの観点～ - Qiita