C# Tokyo ユーザーコミュニティのイベント - C# Tokyo オンライン「世界一わかりやすいClean Architecture」他 で発表した内容です。 動画の原稿はこちらに公開しています。 https://www.nuits.jp/entry/easiest-clean-architecture-2019-09 またサンプルコードやPowerPointファイルはこちらに公開しています。 https://github.com/nuitsjp/Easiest-Clean-Architecture あわせて御覧ください。
爆速開発を目指して NewsDigest を Flutter にリプレイスします JX通信社 Engineering Manager の @jazzsasori です。 最近アークナイツというソシャゲに課金してしまいましたが妻には内緒にしています。 弊社は NewsDigest という無料ニュースアプリを運営しています。 NewsDigest は記者が業務で愛用するほど、その圧倒的スピードに強みがある速報アプリです。また、一般的なニュース分野での速報に加えて、報道はされにくいが個人にとって価値の高い情報も to B 向けのリスク情報SaaS である FASTALERT と連携して即時に伝える、社会派ニュースアプリです。 現在 (2021/11) 500万ダウンロードを突破しており、今後もさらにユーザーを伸ばそうとしています。 なぜリプレイスを行うのか サービスとしては 2015年 にストア
テストしやすいGoコードのデザイン
テストしやすいGoコードのデザイン golang.tokyo #2 12 December 2016 Taichi Nakashima 言いたいこと 明示的であれ！ 2 whoami @deeeet / @tcnksm (GitHub) http://deeeet.com A PaaS Dev&Ops (Using go for CLI tool, API, Batch jobs) 3 OSS Tools gcli - The easy way to build Golang command-line application ghr - Create Github Release and upload artifacts in parallel Packages go-httpstat - Go package for tracing golang HTTP request latency
2020年度版おすすめ書籍 in マネフォ京都メンバー - Money Forward Developers Blog
TL;DR これはMoneyForward Kyoto Advent Calendar 2020の14日目になります。 担当は本年はこれが最後のアドベントカレンダーになる予定の luccafort です。 投稿記事5つはね…多すぎたよ。 開発メンバーが選ぶ、おすすめの技術書【2020年度】 - RAKUS Developers Blog | ラクス エンジニアブログが良さそうなので、マネフォ京都版を作りたくなり、やってみました！ ルール 以下の条件を満たしていれば技術書から一般書籍、あるいは漫画や雑誌でも何でもOKです！という緩い制約で募集しました。 2020年に読んだ/読んでいる/読もうとしている書籍 選んだ理由が書ける というわけで京都メンバーが普段どんな書籍や技術書に興味を持って読んでいるのか個人的に気になっていたので大変楽しみです！ みんなが欲しかった！簿記の教科書 著者名: 滝澤
GopherCon 2019 会場入口*1 こんにちは。シニアエンジニアの濱口です。 以前に下記の記事で掲載したGopherCon 2019への参加しましたので、イベントの様子や体験をレポートします。 techdo.mediado.jp プラン 会場はアメリカ カリフォルニア州 サンディエゴの、マリオット マーキスというホテルです。 イベントの日程は 7月24日から27日までの4日間のため、23日に出国し、28日に帰国しました。イベント本番は25日から27日まで3日間ですが、今回は24日のプレカンファンレンスにも参加をしました。 24日: プレカンファレンス 25日: セッション1日目 + ウェルカムパーティ 26日: セッション2日目 27日: コミュニティーデー プレカンファレンスはイベント本番とは別料金であり、内容は丸一日かけたワークショップなどです。今回メディアドゥから参加した私と
ビジネスロジックとは何か？
業務システムの設計/開発/運用の文脈での、ビジネスロジックについて考察してみたいと思います。 ソフトウェア設計についての本やブログ記事などで、「ビジネスロジックは重要である」ということは、何度も何度も言われていて常識になっていて否定する人はほとんど居ないと思います。この点については文字通りの意味で納得するところなのですが、「ビジネスロジック」というのは、何なのでしょうか？ 実際のところ ビジネスロジックとは何か？と問われて思いうかべる事は人によって異なるかもしれません。 要件定義書に書かれていることがビジネスロジック？ 基本設計書に書かれていることがビジネスロジック？ ○○テーブルの××カラムと□□テーブルの△△カラムを同一トランザクションで更新することがビジネスロジック？ あるページの○○ボタンをクリックしたら、行を削除するということがビジネスロジック？ どうも捉え所が無い感じです。 W
On layered architecture ? Layering is not a novel concept. It’s been around in the industry for more than a couple of years (some of you reading this document are probably younger than layering) and it’s one of the first architectural styles created. In short, layering is nothing more than dividing the concerns of your application into different layers, like in a cake, where the upper layers can t
今年の初め頃から少しずつアーキテクチャやDDDの勉強を初め、プロジェクトの中で手探りで実践してきました。 そのまとめと振り返りを兼ねて、Go言語でDDDとクリーンアーキテクチャを意識した実装を行う場合の簡単な実装例を記載していきます。 GoはJava等と違い完全なOOPを実現するような言語ではないので、あまりガチガチに追求しすぎるよりも、 ある程度妥協しながらGoの良さを活かしつつ落とし所を見つけて行くのが良いのではないかと思います。 未だ試行錯誤しながら実装しているものですので、ご意見/ツッコミ大歓迎です。 Domain Object エンティティや値オブジェクトといったドメインオブジェクトはデータと振る舞いから成るもので、 Goでは構造体とそれが持つプロパティ値、関数で表現します。 type Users struct { id int firstName string familyNa
達人出版会
［令和6年度］基本情報技術者 超効率の教科書＋よく出る問題集 五十嵐 順子 徹底攻略 データベーススペシャリスト教科書 令和6年度 株式会社わくわくスタディワールド 瀬戸美月 著 徹底攻略AWS認定SysOpsアドミニストレーター - アソシエイト教科書＆問題集［SOA-C02］対応 鮒田 文平, 長澤 美波, 日暮 拓也, 奥井 務, 渡辺 樹, 山下 千紗, 伊藤 翼 世界標準MIT教科書 アルゴリズムイントロダクション 第4版 第2巻 高度な設計と解析の手法・高度なデータ構造・グラフアルゴリズム Thomas H. Cormen, Charles E. Leiserson, Ronald L. … 問題解決の教科書 CITA式問題解決ワークブック 市岡 和之 はじめてのType-C電子工作 じがへるつ スッキリわかるJava入門 実践編 第4版 中山 清喬(著), 株式会社フレアリ
The API database architecture - Stop writing HTTP-GET endpoints
The API database architecture - Stop writing HTTP-GET endpoints Table of contents Introduction Data retrieval via PostgREST, data modification in the existing backend Compatibility with REST, CQRS and GraphQL Strategies for adapting existing architectures Adapting a monolithic system with a single backend Adapting (domain-driven) microservices with one or more databases Benefits of the API databas
Clean Architectureとは Clean Architecture(クリーンアーキテクチャ)とは，レイヤに内側と外側の関係性を持たせるアーキテクチャである． 「外側のレイヤは内側のレイヤだけに依存する」というルールを守ることによって，アプリケーションから技術を分離することが目的である． アプリケーションから技術を分離すると何が嬉しいのか ここでの「技術」とは，HTTPやcsv，MySQLなどのことを意味している． アプリケーションから技術を分離すると，技術を容易に変更できたり，テストコードを書くときに容易にモックできたりする． 例えば，出力をHTTPからcsvに変更したくなったときなどに容易に変更が可能である． 各レイヤの責務 Clean Architectureで提案されているレイヤ構造は以下の画像のようなものである． 内側から，Entitiesレイヤ，Use Casesレイ
If you are a master software engineer, you can stop reading. This post isn't for you. This post is for people who are like me, mediocre programmers who write messy code and create spaghetti architecture but are fascinated with the idea of building something clean, maintainable, and adaptable. Preface I don't usually buy computer books because they get outdated so quickly. Besides, I can find all t
テストケースを変えない工夫 | 品質向上ブログ
※本稿はソフトウェアテスト Advent Calendar 2020 24日目の記事です。 こんにちは、Magic Podの開発をしている脇坂です。好きなものは単体テストとリファクタリングとテニスです。 さて、今日はリグレッションテスト、機能テストの文脈で話をします。テストケースを変えない工夫というのは、継続的にテストケースを実行する上で必要不可欠なテクニックです。このテクニックは自動テストの文脈で語られることが多いですが、手動テストにおいても応用可能だったりします。 話すこと テストケースを変えるべきではない理由テストケースを変えずに済ませる工夫 話さないこと フレーキーテスト問題に対するシルバーブレッド非機能要件のテスト 目次 背景テストケースの変更単体テストの場合Web/Mobile E2Eテストの場合Webは詳細手動テストの場合Web/Mobile E2Eテスト自動化サービスの場合
Clojure x ClojureScript で深める Web 開発 (5) API 開発 トランザクション添え - Qiita
Git Repo ソースコードと原文が入ったレポジトリ https://github.com/MokkeMeguru/clj-web-dev-ja/tree/main/chap5 シリーズ Clojure x ClojureScript で深める Web 開発 (0) Clojure x ClojureScript で深める Web 開発 (1) Duct x Clean Architecture Clojure x ClojureScript で深める Web 開発 (2) 環境の構築 Clojure x ClojureScript で深める Web 開発 (3) API 作成入門 Clojure x ClojureScript で深める Web 開発 (4) Auth Clojure x ClojureScript で深める Web 開発 (5) API 開発 トランザクション添え C
サーバーサイド未経験の大学生が4日でGolang×CleanArchitectureのAPIを構築した話 - Qiita
【追記：2019/9/17】 記事で誤りがあった部分を修正いたしました。 またサンプルも正しいものに修正しておりますので、是非ご確認ください。 【追記:2019/9/10】 コメントでもご指摘を頂いておりますが、一部誤った内容が含まれております。 すぐに修正に取り掛かりますが、内容の修正まで今しばらくお待ち頂けますようお願いいたします。🙇♂️ また、今回多くの方に誤った内容をお伝えしてしまったこと、深くお詫び致します。 （多くのいいねを頂いており、ストックに登録して頂いている方もいらっしゃると思いますので、非公開にせず修正又は内容の削除で対応致します。） 先日インターンでソシャゲ用のAPIを作った時に、サーバーサイド未経験ながらGolang＆クリーンアーキテクチャ（的な）のAPIを構築しました。 特にインターンで用意されていた内容というわけではなく、個人の課題としてクリーンアーキテクチ
Webフロントエンドでも Clean Architecture に関する考察や実際のサービスへの導入の事例をよく見かけるようになりました。 n番煎じですが Clean Architecture をWebフロントエンドのアプリケーションに導入する際の考察をコードを書きつつしてみました。 サンプルコード はこちらにあります。 また、今回のコードを書くにあたり、 @ttiger55 さん、@pirosikick さんのエントリーやコードを参考にしました。ありがとうございます :) Pros/Cons コードを書いてみた上での結論を先に述べておきます。 Pros/Cons で言えば Pros の利点が多く感じられますが、結局のところ「ビジネス要件」がある程度固まっているか否かというソフトウェア側でコントロールしにくい箇所がボトルネックとなっているのため、ここをどう捉えるかは個人によって差が出そうか
Abstraction Actor Model Architecture AI Algorithms Anti Patterns Architectural Design Principles Architecture Decision Records (ADR) Azure Cloud Back Pressure Caching Clean Architecture Clean Code Cloud Best Practices Cloud Design Patterns Cloud Native Code Review Concurrency CQRS Data Driven Design Design Best Practices Design Patterns DevOps Distributed Locking Distributed Transactions & Saga Do
11+ Best Nextjs Templates & Themes in 2024 | Creative Designs Guru
React SaaS Starter Kit with Next.js and TypeScriptReact Templates for building SaaS applications with Next.js, TypeScript and Tailwind CSS. A SaaS Starter Kit with a clean architecture and a multi-tenant architecture.
My Favorite System Design and Software Architecture Books for Experienced Developers
My Favorite System Design and Software Architecture Books for Experienced Developers Disclosure: This post includes affiliate links; I may receive compensation if you purchase products or services from the different links provided in this article. Hello guys, System design and Software architecture are two important topics for coding interviews and also two important skill for Software developers.
クリーンアーキテクチャですが、hanami/hanami: The web, with simplicity. と出会ってから5周回くらいして、ようやく腹落ちしつつあるのでまとめてみます。 フレームワークを利用しつつ理解するのは難しい フレームワークを利用した場合、例の図のUsecaseの外堀をグルッと埋める形になります。MVCならController、View、Modelです。Hanamiの場合はRepositoryが来ます。個人的にはこの内側から3層目が全て一体化していると、どうしてもそれらが中心であるように感じてしまうんですよね。 そこでアプリケーションのそれぞれの責務を別のライブラリを利用して実装することを試してみました。 これです。 cc-kawakami/clean-architecture-minimal-app: A minimal Clean Architecture a
Clean Architectures in Python - Chapter 1 - A day in the life of a clean system
Must be my lucky day. Terminator 2, 1991In this chapter I will introduce the reader to a (very simple) system designed with a clean architecture. The purpose of this introductory chapter is to familiarise with main concepts like separation of concerns and inversion of control, which are paramount in system design. While I describe how data flows in the system, I will purposefully omit details, so
はじめに この記事ではVertical Slice Architectureと呼ばれるアーキテクチャパターンについて解説します。Vertical Slice Architectureはこの2,3年の間にいくつかのブログポスト[1][2][3][4]で言及されているアーキテクチャです。Clean Architectureに対する反省から生まれたアーキテクチャであり、機能（feature）に沿ってモジュール分割を行う点が特徴です。 まず、Clean Architectureについて説明してからVertical Slice Architectureについて説明します。最後に私のコメントとして、Vertical Slice Architectureに対する評価、Clean Architectureに対する評価、それから日本でVertical Slice Architectureが受容され得るかどう
はじめに はじめはシンプルだったコードも積み重なる機能追加や変更、バグ修正等などによって、徐々にコードが複雑化し、修正コストの増加や品質低下に繋がります。 これはある程度の規模を持つプロダクトでは至って自然なことであり、そうならないようにするためには意識して設計しなければいけません。 ここではコードを複雑化させないために普段意識している手法やパターンを紹介します。(DDDやClean Architecture成分多め) また本記事で登場するコードはJavaですが、Javaを知らなくてもある程度は理解できるかなと思います。 あと、割とまとまりもなく幅広い範囲でダラダラと書いてしまい長いです... 以下項目ごとのアンカーリンクとなっておりますので興味がある項目のみどうぞ。 getter/setterがよくない理由 デメテルの法則と尋ねるな命じよ(Tell, Don't Ask!) 関心の分離
この記事は GraphQL Advent Calendar 2020 14 日目の記事です。 前回の記事は @joe-re さんの 「ライブラリの実装からCursor-based paginationにおけるcursorのフォーマットのベストプラクティスを探る」 でした。 前置き GraphQLは2010年代後半に出てきた技術の中でも個人的に特に強力なアプリケーション実装パターンの一つだと思っているのですが、シンプルな実装なのに利用用途が豊富にあることと利用する立場が違うと全く印象を抱く事から全体像を掴みづらく、本来持つべきポテンシャルに対してまだ認知が広がっておらず利用されていないように感じます。 今回はサーバーサイドからの視点を中心にGraphQLを構築する要素を分解して解説するのとともに、それを利用した際にWebアプリケーション開発やそれに関わるエンジニアに起きうる変化について書いて
導入 お疲れ様です、ベイジでエンジニアをやっている天野です。 ベイジではWebアプリのビジュアルデザインやフロントエンド実装の案件が増えてきており、エンジニアは日夜設計に頭を悩ませています。今回は、その中で個人的に良いと感じたフロントエンドの設計について共有します。 注意点として、ベイジではモックアップ実装の案件が多く、サーバーサイドとの通信の部分に関しては実装しないことが多いです。よって本記事では、UIなどWebアプリにおけるViewの話が中心となります。 ディレクトリ構成 最初にディレクトリ構成を示すことで、本設計の概要をつかんでもらいます。 src // ルートディレクトリ ├─infrastructure // インフラ層。バックとの通信やデータ管理を担う │ ├─domain // APIのインターフェースの定義など │ ├─interface // データの通信処理 │ └─r
自分がフロントエンドのアーキテクチャを考える時に、特に意識していることについてまとめてみました。 改善するべき点が多いと思っていますが、自分の考えを整理する意味で書き残したいと思います。 ここで言う「アーキテクチャ」とは？ この記事では、アーキテクチャについて主にコード間の依存関係の観点で考えています。 「なぜ依存関係なのか」については、次の意識しているポイントで触れていきます。 意識しているポイント 捨てやすくする 書いたコードを捨てやすいようなアーキテクチャを目指したいと思っています。 なぜなら、最初から良い設計はできないからです。（まれにできる人もいますが、少なくとも自分はできないです） 開発を重ねて理解が深まることで、より良い設計が見つかります。 良い設計が見つかった時に、既存のコードの修正・削除が必要になりますが、それができないと実現（実装）できないことになってしまいます。 コー
Echo（Golang web framework）のディレクトリ構成の参考情報 - OSS「echo-sample」のコードリーディング - ryotaku's Tech Blog
TL;DR echo-sampleは、こんな構成だった TL;DR きっかけ echo-sampleの概要 ディレクトリ構成 個々の構成毎の役割 main.go 役割 詳細 route 役割 詳細 middleware 役割 詳細 handler 役割 詳細 db 役割 詳細 conf 役割 詳細 api 役割 詳細 model 役割 詳細 /db/ddl.sql 役割 詳細 参考リンク きっかけ 業務で、GolangとそのWebフレームワークのEchoで、APIサーバーを作る機会があったのですが、初めて触るのでディレクトリ構成で悩みました。 必要なのは、Clean Architectureなどでガッツリ分離する必要も無いくらいのシンプルな機能のみなので、OSSで程よい構成のお手本を探しました。 いくつかEchoを利用したリポジトリがある中で、echo-sampleが簡潔な構成で参考になり
プログラミングにおけるテスト｜erukiti
僕はQiitaとNoteそれぞれでブログを書いていて、それぞれコードがある技術的なものを前者、それ以外をNoteで書くという書き方をしてます。まぁもっと言ってしまうと、ポエミーなヤツはNoteに書くって感じです。 最近よく考えるテーマとしては、テスト（ここでは自動テストを指します）というものがあります。今日の記事はそんなテストに関するポエムというか、筆者の頭の整理のために書いたものです。 どうにもTDDは誤解を受けやすいTDD（テスト駆動開発）には色々な要素が巻き込まれしまっている分、誤解されやすいものです。 一番誤解されやすいのはテストファーストとの混同です。 最初に落ちるテストを書いて、それに受かるコードを書いて、コードをリファクタリングする、という工程はものすごくキャッチーで知名度が高いものですが、TDDにおいて必須要件ではありません。 そもそも、TDDにおいて、自信があるならテスト
この記事は @yushi_koga さんの Qiita - オブジェクト指向プログラミングとドメイン駆動設計を学ぶのに適切な書籍とおすすめの読む順番 の後追い記事です。 DDD を学ぶ上で手助けとなるものを書籍に限らず紹介します。 自分如きがこんなキュレーション記事を書いて良いのか？という気持ちに怯えつつ書きます。 上記の記事で紹介された書籍以外で OOP や DDD に言及しているものを紹介します。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 DDD と共に語られることの多いクリーンアーキテクチャの本。 OOP や設計原則、凝集性などについても学べる。 .NET のエンタープライズアプリケーションアーキテクチャ 設計原則、ドメインモデリング、CQRS などについて学べる。 （以前は Kindle 版があったのですが今は何故か無くなってました） 「実践ドメイン
やまかわアドベントカレンダー Advent Calendar 2023 - Adventar 1日目の記事だよ！ このアドベントカレンダーはノンジャンルだけど、買ってよかったものみたいなお題があるんで、じゃあ今年読んでおもしろかった本とか紹介してみようと思いました。 技術書も実用書もお話も漫画もとりまぜていってみましょう。 六人の嘘つきな大学生 www.kadokawa.co.jp 殺人事件じゃないミステリー。 1ページごとにどんでん返しがあるみたいなジェットコースター展開なので飽きることなく一気に読めちゃいます。楽しいよ。 読者への解けるかなという挑戦という正統派ミステリーとしてよくできているかっていうと、目指しているのはそっちではないかもしれない。 でもページめくるごとに急展開でもってかれるのは気持ちいいし、あと何より大事なこととして読後感とても良いです。だからおすすめ。 話題のミステ
TRACERYプロダクトマネージャーの haru です。 「設計」とは、単にシステムを構築するための作業ではなく、長期的に価値を生み出すための重要なプロセスです。 ソフトウェアが事業において長期的に価値を生み出すためには、ソフトウェア開発者が「設計にこだわる」*1ことが必要だと私は思います。 「設計にこだわる」とは、ソフトウェアから価値を生み出すためには設計はこうあるべきだという理想を持ち、それを実現し、やり続けることです。 本記事のテーマであるドメイン駆動設計（DDD: Domain-Driven Design）でいえば、その理想とは「事業戦略とソフトウェアの実装を結びつける」*2ことであり、開発者が事業や業務担当者と「同じ言葉」を共有し、現実の業務をソフトウェアにモデリングする（実装する）という活動を持続することです。 その対極にあるのが「動けば良い」という考え方です。自分が担当する機
Developing evolutionary architecture with AWS Lambda | Amazon Web Services
AWS Compute Blog Developing evolutionary architecture with AWS Lambda This post was written by Luca Mezzalira, Principal Solutions Architect, Media and Entertainment. Agility enables you to evolve a workload quickly, adding new features, or introducing new infrastructure as required. The key characteristics for achieving agility in a code base are loosely coupled components and strong encapsulatio
最近、DRY原則のやりすぎや安易な共通化は良くないと聞きます。しかしその解決策が後のことや目的、ドメインを考えるなど曖昧です。明確な基準はないのですか？
回答 (9件中の1件目) 単一責任の原則です。 Clean Architectureでは次の言い方をしています。 > 単一責任の原則(SRP)は、アクターの異なるコードは分割するべきという原則だ。 悪い例として出てくる図ですが、まずEmployeeクラスに3つのメソッドがあって、CFO、COO、CTOがそれぞれ使います。 それに対して「コードが重複しているから」とアルゴリズムを共通化しました。 そしてcalculatePayを使うCFOチームがregularHoursのアルゴリズムを変えました。するとreportHoursを使うCOOチームの使うデータが壊れました。 この単一...
はじめに 最近、ゼロスクラッチからiOSアプリの設計・開発をする機会がありまして、その構成を色々妄想しております そこで、ゼロからスクラッチでiOSアプリ開発をやるとしたら、どういう構成やツールを使うかなー、というのを妄想していて、自分なりの考えをまとめてみました。 誰向けの記事？ アプリ開発の勉強を一通り終えたんだけど、実際にアプリをゼロから作る場合にどういう作りにすればいいか悩んでいる初心者の人 ゼロから新しいアプリの設計を検討している人 既存アプリの構成を変更したい人 アーキテクチャ アーキテクチャ選定については、アプリの開発規模にもかなり依存すると思います。 規模が小さく、開発者の人数も少ないアプリなら、 MVC（Model - View - Controller） MVP（Model - View - Presentor） あたりが候補になるでしょう。 多少大きくなってくるのであ
はてなブログ独自の集計による人気記事のランキング。6月12日（日）から6月18日（土）〔2022年6月第3週〕のトップ30です*1。 # タイトル／著者とブックマーク 1 邦楽から影響を受けた台湾のバンドが多い件について - オトニッチ by id:houroukamome121 2 死なないために - 宮田昇始のブログ by id:miyasho88 3 「論文入門」というより「学問全般への入門」・小熊英二『基礎からわかる論文の書き方』 - そういちコラム by id:souichisan 4 山下達郎がサブスク解禁しないことを自分が現時点で100％支持する理由について - オトニッチ by id:houroukamome121 5 日本人にかかる性淘汰圧と、その行方を想像する - シロクマの屑籠 by id:p_shirokuma 6 PTAに3000円の寄付を強要されたという話につい
内製ソフトウェアアーキテクチャでレガシーシステムを刷新し技術的負債を削減するまでにやったこと - LIFULL Creators Blog
事業基盤ユニットアーキテクトグループのyoshikawaです。 今回のブログではLIFULL HOME'Sを構成するレガシーシステムのリアーキテクティングについて書いていきます。 2年前にリアーキテクティングプロジェクトが発足し、ソフトウェアアーキテクチャのベースにClean Architecture、言語にTypeScriptを採用し 新たなAPI(Backend For Frontend)を開発してきました。 「コードの品質」と「プロダクト開発エンジニアとのコミュニケーション」が鍵となっていた本プロジェクトですが、 このブログ記事では「コードの品質」を主題として取り組みをオムニバス的に紹介していきます。 この記事で伝えること 想定する対象読者 過去のブログの紹介 データフローに注目したLIFULL HOME'Sのシステム概観 リアーキテクティングプロジェクトについて アーキテクトチーム
チーム立ち上げから1年半で8名体制に。フロントエンドチームのみなさんに今とこれからについて聞きました - BASE Book（ベイスブック）
社長室の米田です。 今回は、フロントエンドチームのみなさんに座談会という形でお話を聞きました！ BASEでフロントエンドチームが発足したのは、2018年12月。かつてはフロントエンド専任のエンジニアがいなかったところから、いまではマネージャーを含めて8人のフロントエンドチームとなりました。 それぞれのメンバーが入社したきっかけ、いま携わっているプロジェクト、チームで取り組んでいること、いまある課題などを話してくれました！ （WFHの方針により、今回はオンラインにてインタビューを実施しました。） フロントエンドチームのみなさん まずはそれぞれ自己紹介をお願いします。前職でやっていたこと、BASEに入社したきっかけ、BASEでの印象的なプロジェクト、いま携わっているプロジェクトを教えてください！ 松原（写真2段目中央）：前職ではレストラン予約サイトのフロントエンド開発をやっていました。iOS開
関数型プログラミング言語"Clojure"が「私たち」と「あなた」にもたらすもの | 株式会社AGE technologies
こんにちは、株式会社AGE technologies CTOの黒川です。 この記事では、私たちがシステム開発のほとんど全ての場面で使用しているClojure（クロージャー）という言語について紹介します。大きく下記の3点をトピックとして、弊社のテクノロジースタックに理解を深めていただくことを目指します。 なぜClojureを選定したのか / Clojureが「私たち」にもたらすものClojureが「あなた」にもたらすもの未経験のチームメンバーがどうやって適応していったか前提私は、現代のシステム開発のユースケースにおいて、特定の言語でなければ実現できない機能はほとんど存在しないと考えています。とはいえ、「じゃあCOBOLでもいいよね」といった極論は必ずしもベターな解決方法ではなく、選定する技術に応じたトレードオフは理解しておく必要があります。 この前提に基づいて、本記事では私たちの技術スタック
リンク connpass: 【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 - connpass t-wadaさんの資料 実録レガシーコード改善 / Working with Legacy Code: the True Record - Speaker Deck 会社で、「t-wadaさんのこの発表すごいよかったですよ」と聞いたので興味が湧いて再放送を見ることにしました。Findyさん、t-wadaさん再放送ありがとう… 特に個人的に面白かったポイントを書きます。 ソフトウェア開発の三本柱には優先度がある ソフトウェア開発の三本柱は、Version Control, Testing, Automationの3つです。今回t-wadaさんが取り組んだコードはどれも備えていませんでした。優先度順に手をつけたいけどどこから手をつけるべきか。 ここでVersion Contro
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
世界一わかりやすいClean Architecture #csharptokyo
爆速開発を目指して NewsDigest を Flutter にリプレイスします - JX通信社エンジニアブログ
GopherCon 2019に行ってきました - Tech Do | メディアドゥの技術ブログ
Clean Architecture For React
GoによるDDD / Clean Architecture 実装 - Qiita
React + Recoil で Clean Architectureの構成を考えてみた
Go言語とClean ArchitectureでAPIサーバを構築する - Qiita
Clean architecture for the rest of us | Pusher tutorials
Webフロントエンド Clean Architecture 考 - Qiita
Awesome Software Architecture
小さなライブラリ群によるアプリでクリーンアーキテクチャをいい感じに理解する - Qiita
Vertical Slice Architectureについて
コードを複雑化させないために意識したいパターン集 - Qiita
GraphQLはサーバーサイド実装のベストプラクティスとなるか - Qiita
俺流フロントエンドのディレクトリ構成と設計の考え方 | techlab / baigie
フロントエンドのアーキテクチャを考える時に意識していること
ドメイン駆動設計を学びたい人にお勧めする書籍 + Twitter アカウント + α - Qiita
2023年こんな本がおもしろかった - またお前かよ！
「ドメイン駆動設計をはじめよう」は設計力で事業に貢献したい開発者のための実践ガイド - TRACERY Lab.（トレラボ）
今、iOSアプリをゼロスクラッチで開発する時の構成と利用ツールを考える - Qiita
今週のはてなブログランキング〔2022年6月第3週〕 - 週刊はてなブログ
【再放送】t-wadaさんが後世に残したい、実録レガシーコード改善 を見た感想