はじめに ナビタイムジャパンでは、アプリの継続的な開発・運用をスムーズに行うために「設計」を重視しています。本記事では、その「設計」を実現するアーキテクチャをいくつか紹介し、実際に現場で使われているアーキテクチャについて考察していきたいと思います。 アーキテクチャとは？ アーキテクチャとは、アプリを綺麗に開発・継続的に運用していくための設計方法です。この設計方法を考えずに開発すると以下の問題点が発生してしまいます。 クラスが肥大化し、コードを追いにくくなる ロジックの煩雑化、再利用性の低下 チーム開発における役割分担がしにくい 属人化が進み、引き継ぎにくい テストがしにくい 機能の追加、改修が困難 etc… チームでのアプリ開発はもちろん、個人でアプリを開発する時も、開発するアプリに規模や特性に合わせて適切にアーキテクチャを選ぶことが、アプリを継続的に開発・運用していく上で非常に重要です。
Clean Architecture提唱者 Robert C. Martin氏が登壇。オンラインイベント「Builders Box ON AIR ♯3クリーンアーキテクチャ」が開催
Sansan株式会社が運営する、エンジニアリング強化のためのプロジェクト「Builders Box」は、エンジニア向けオンラインイベント「Builders Box ON AIR」を、1月29日（金）に開催します。 ■開催概要 「Builders Box ON AIR」は、Builders Boxが企画する、世界に通用するエンジニアになるための知見を共有するイベントです。第3回目となる今回のテーマは「クリーンアーキテクチャ」です。 「Clean Architecture」の提唱者である、Robert C. Martin氏をゲストに迎え、エンジニアが押さえておくべきアーキテクチャやアプリケーションに最適なアーキテクチャとはどのようなものか等、広い視点で「クリーンアーキテクチャ」をテーマにお話しいただきます。 ■スピーカー紹介 Robert C. Martin（ロバート C.マーチン）氏 197
エクサウィザーズのTLが実践する、開発が遅くならないテストの書き方 - エクサウィザーズ Engineer Blog
この記事について この記事ではエクサウィザーズの介護記録AIアプリ「CareWiz ハナスト」(以下ハナスト)の開発スピードを維持するために、どのようにテストを書いているかをご紹介します。 内容としては基本的なことかと思うので、ハナスト開発ではどのような基本に則ってテストしているかという感じで読んでいただければ良いかと思います。 書いているのは誰？ この記事はハナスト開発チームのテックリードをしている原(@haracane)が書いています。 ハナストチームでは主にNode.js&TypeScriptでバックエンドAPIを開発していてテストにはJestを使っています。 ちなみにこれまではKotlin&JUnitやRuby on Rails&Rspecなどで開発＆テストをしたりしてました。 ハナストについて ハナストは簡単に言うと「音声入力で介護の記録をするアプリ」です。 以下の動画を見ていた
PythonでDI+モックを使いながら、Clean Architectureでアプリケーションを構築する - Qiita
PythonでDI+モックを使いながら、Clean Architectureでアプリケーションを構築するPythonFlaskDIPython3CleanArchitecture 業務でPythonを使ってウェブアプリケーションを実装する際、レイヤー毎に関心の分離を行いながら開発するために、Clean Architectureを導入することになりました。 チームメンバーへのナレッジ共有を兼ねて、漸進的型付けとDependency Injectionを用いながら、テスタビリティの伴ったアプリケーションを開発するためのプラクティスをまとめました。 今回はPythonを用いたサンプルを目的としているため、Clean Architectureの解説は簡易に済ませます。 (The Clean Architectureより引用) Clean Architectureはロバート・C・マーティンによって2
This article is also available in Korean. Can you imagine, UIKit is 11 years old! Ever since the release of the iOS SDK in 2008 we were building our apps with it. And throughout this time the developers were in a relentless search for the best architecture to use for their apps. It all started with MVC, but later we witnessed the rise of MVP, MVVM, VIPER, RIBs, and VIP. But something has happened
参考図書 – ピーコックアンダーソン
オブジェクト指向 ・アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 すばらしい本です。オブジェクト指向が詰まっています。 ・オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座 サンプルコードはjavaですが，最初にオブジェクト指向に目覚めるのに最適な本です。 ・Head Firstオブジェクト指向分析設計 ―頭とからだで覚えるオブジェクト指向の基本 マンガみたいな感じで読めて，オブジェクト指向について学べます。 ・Clean Code アジャイルソフトウェア達人の技 ・Clean Architecture 達人に学ぶソフトウェアの構造と設計 ・Adaptive Code ～ C#実践開発手法 ・．ＮＥＴのエンタープライズアプリケーションアーキテクチャ ・実装パターン 廃盤のため異常に高くなりすぎなので，様子を見た方がいい気がし
メリークリスマス🎄 こちらは GLOBIS Advent Calendar 2019 25日目の記事です。 自己紹介 こんにちは、@mshrwtnbです。1ヶ月ほど前にGLOBISに入社し、現在、GLOBIS学び放題のアプリ開発を担当しています。iOS版GLOBIS学び放題を使いやすくすべく、チームメンバーとともにゴリゴリ書き直しています。ご期待ください💪 直近まではソシャゲを主力とする企業で、複数サービスのアプリ開発、マネジメントをしておりました。 記事の目的 これまでのアプリ開発・運用の経験をもとに、アプリ開発着手からリリースまでにやっておくと後々役立つことをご紹介します。想定読者はサービス運用の経験が少ないアプリエンジニア1とします（経験を積まれている方に既視感強めの内容かと思います）。チョイスは独断と偏見です。他にやっておくと、便利そうなことがあればコメントいただけると幸いです
Checkstyleでクリーンアーキテクチャをチェックする - BIGLOBE Style ｜ BIGLOBEの「はたらく人」と「トガッた技術」
こんにちは、なおしむです。 私はシステム企画部でシステム全体のアーキテクトとレガシーシステムの改善開発をしています。 弊社ではドメイン駆動設計を使って開発をしています。 ドメイン駆動設計ではクリーンアーキテクチャのようなレイヤー構造でシステムを作ります。このレイヤー構造に従って設計・コーディングをするのですが、コードレビュー時に正しいレイヤー構造で作れているかをチェックするのが地味にめんどくさいです。。 現在のプロジェクトで、この地味で面倒なレイヤー構造のチェックをCheckstyleを使って自動化しているのでその方法を紹介します。 クリーンアーキテクチャのコードレビューはめんどくさい クリーンアーキテクチャとは、図のような円形のレイヤー構造のアーキテクチャです。 The Clean Architecture を参考に筆者が作成 クリーンアーキテクチャにはレイヤー構造の依存関係にルールがあ
本書では、Clean Architecture の観点から、React や Redux で構築されたアプリケーションの設計をとらえなおし、また、ときには新たな設計の提案を行います。 いままでは Clean Architecture があまり取り入れられてこなかった Web フロントエンド領域に対して、この手法を適用することを目指します。 本書が、React アプリケーション設計のその一歩先に到るための一助になれば幸いです。 試し読み：https://note.com/imamori/n/n5a7ebdbd4260 また、BOOTH でも販売しています。下記のページから購入できます。 BOOTH：https://archived-tech.booth.pm/items/2399644 英語版：https://www.amazon.co.jp/dp/B09FG94392 目次： 第1章 Cle
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、iOSアプリ黒帯の林 （@kazuhiro494949）です。 2019アドベントカレンダー2日目は、私がiOSアプリ開発を進めていく過程でどのようにクラス設計を行っているか紹介します。 普段の業務でなかなか理想通りに設計できないなと思っている方のお役に立てればと思います。 背景 iOSアプリ開発は、提供されているフレームワークをいかに使いこなすかという側面がとても強いです。 そのため実行結果の動きを触りながら常に試行錯誤して、心地よく動かせる実装を実現していかなければなりません。 一方、試行錯誤していく過程で記述したロジックは自然と増えていき、些細と言えないコード量になっていきます。 こういった部分ではユニットテスト
ビジネス開発部のバックエンドエンジニアの伊藤です。主にトクバイのビジネスサイドの開発を担当しています。 Shopify記事の影響もありしばらく前からモジュラモノリスが注目されるようになりました。 我々が開発しているトクバイではモノリシックに構築されており、各機能が密結合になりメンテナンスしづらくなっています。 今回、新機能プロジェクトを担当する上で各機能をモジュール分割・コンポーネント化することを試してみました。 Packwerk PackwerkはShopifyが開発しているGemで、Railsアプリケーションをモジュール分割する手助けをしてくれます。 USAGEに書かれていることを要約すると、大規模なアプリケーションは境界を作り境界間の依存関係をコードレベルで最小にしようということだと考えています。 後述しますが幾つかのエコシステム導入する事で、よりモジュラモノリス化を促すことができま
『Clean Architecture』における単一責任の原則とコンウェイの法則について - こまぶろ
要約 『Clean Architecture』における「単一責任の原則（SRP）」の説明において、アンクル・ボブはコンウェイの法則に言及している。コンウェイの法則によって補強されていると思われるSRPの主張は、2014年のアンクル・ボブのブログ記事において既に現れている。「変更の理由」を「人間」であると同定することは、アンクル・ボブにおけるSRPを一段階踏み込んだ主張にしている。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 作者:Robert C.MartinKADOKAWAAmazon SOLID原則との出会い ソフトウェア開発の世界には、「〇〇原則」や「〇〇法則」といったものが数多く存在している。その中でも、最も著名なものの1つが、SOLID原則であろう。SOLID原則とは、以下の5つの原則の頭文字をとったアクロニムである*1。 Ｓ：単一責任の原則（Sin
Scala関西Summit 2019に参加してきました #scala_ks - Unipos engineer blog
こんにちは！Fringe81 エンジニアの谷口です。2019年10月26日(土) - 27日(日)に開催されたScala関西Summit 2019に同期の大沼と参加してきました。 2019.scala-kansai.org Scala関西Summit Scala関西Summitは、Scalaをテーマとした関西で最大級の技術カンファレンスです。Scalaの導入事例やTIPSなどなどScalaに関わるあらゆる人を対象にしたカンファレンスです。 2日間の開催で、1日目は講演・ハンズオンdayです。講演は公募によって選ばれ、大変幸運なことに私のプロポーザルを採択して頂きました！ 2日目はアンカンファレンスdayです。当日の朝に参加者全員で何を話すかが決められます。1日目の会場のホワイトボードに挙げられた『こんなこと話してほしい！』について話せる人を募ってセッションのタイムテーブルを決めていきます。
2022年版実践WPF業務アプリケーションのアーキテクチャ【見積編】～ドメイン駆動設計＆Clean Architectureとともに～
現在、ドメイン駆動設計やClean Architectureなどが日本でも良く語られるようになり、広く受け入れられはじめています。技術的にはWindows Presentation Foundation（以下WPF）も .NET Frameworkだけでなく .NET上でも動作するようになりました。筆者もそれらを取り入れて開発しています。本稿ではマイクロソフトが架空の大規模多国籍製造企業を想定し公開している、サンプルデータベース「AdventureWorks」を題材に、グレープシティのコンポーネント「ComponentOne for WPF」や「SPREAD for WPF」を活用して業務アプリケーション開発をする際のアーキテクチャを紹介します。 はじめに さて、タイトルをみて疑問を持った方もいらっしゃるのではないでしょうか。「見積編？」と。 2018年4月に書いた「実践WPF業務アプリケ
話したネタ DIを勉強したい場合には何を参照する？ 書籍: Dependency Injection Principles, Practices, and Patterns Laravel Pimple 書籍: Clean Architecture 達人に学ぶソフトウェアの構造と設計 単行本 GoFデザインパターンは、なぜここまで普及したのか？ OOPを理解するきっかけになったため 差分プログラミングの誤解 継承には悪い面も多い 書籍: 増補改訂版Java言語で学ぶデザインパターン入門 OMT法とUML Don’t Repeat Yourself 原則 と 差分プログラミング 差分プログラミングは、継承以外の手法でも実現できる is-a と has-a 構造ではなくて、責務・振る舞いについてプログラミングする DIコンテナ と Main関数 継承があるデザインパターンの現代における利用価値
TypeScript ではじめる Clean Architecture / Let's start Clean Architecture with TypeScript
TypeScript ではじめる Clean Architecture / Let's start Clean Architecture with TypeScript
How to Learn Software Design and Architecture | The Full-stack Software Design & Architecture Map | Khalil Stemmler
Software Design and Architecture is pretty much its own field of study within the realm of computing, like DevOps or UX Design. Here's a map describing the breadth of software design and architecture, from clean code to microkernels. Update (March 18th, 2024): It's been about 5 years since I first wrote this article here, and - man, oh man. Basically, everything has changed. Allow me to explain. I
【感想】『Clean Architecture 達人に学ぶソフトウェアの構造と設計』：クリーンなアーキテクチャの探求＋至高のドーナツ＋豊富な昔話 - Rのつく財団入り口
「アーキテクチャのルールはどれも同じである！(ドヤっ)」 数々の書籍やアジャイルソフトウェア開発宣言、SOLID原則の提唱などで業界では有名なアンクル・ボブ(Uncle Bob)ことロバート・C・マーチンさんによる、よりよいソフトウェア・アーキテクチャと設計の追求の本。原著が2017年、翻訳が2018/8、その後ITエンジニア界隈でもかなり話題になりました。 実は去年一度読み始めたのですが、AWS認定を突破する！と決意したので例のタマネギ(あるいはドーナツ)にたどり着く前に中断。無事に３冠突破して戻ってきたので、今年の夏に改めてじっくりと最初から読むことができました。 アーキテクチャのルールはどれも同じである！という帯の煽りは極端ですが、要はコンピュータやエンジニアリングの進化の中で発見されてきた、時代を超えて通用する不変のルールもある、これらをアーキテクチャの観点から見ていこうという本で
ここ数年でClean Architectureはおなじみのアーキテクトとして親しまれるようになりました。 とりわけ単体テストを書く習慣が根付いているバックエンドで重点的に取り入れられているように見受けられますが、フロントエンドにおいても同様にClean Architectureを導入し、メリットを享受できます。 今回はフロントエンドにClean Architectureを導入する手順を、実際にコードを追いながら紹介していきます。 実際のコード 実際に書いたコードはこちらのGithubに公開しています。データを外部から取得するフローを表現するために、node.jsで実装されたモックサーバーも用意しました。 https://github.com/t-tiger/React-CleanArchitecture-Example 前提知識 Clean Architectureでおなじみの図と共に前提
「DDD をやっている」とは
脳内整理のため、つまり僕のためのポエム 自分の中で理解が一区切りついた感じがしたので、コミットしておく 「DDD をやっている」に対して感じていた違和感 DDD を始め ( させられ ) て以降感じていた違和感がある 僕にはこんなフレーズが頻繁に聞こえていた 若干文面は違うだろうが、弊社に限らないニュアンスだとは思う これらに対するモヤっとを解消したいのでいろいろ考え直してみた 曰く「DDD だと仕様とモデルが一致する」 第一印象 いや、テキストと絵は一致しないっしょ？ そもそも一致ってなにさ？ 仕様書を Java で書くってこと？ それとも実装を日本語でするってこと？ 曰く「DDD だと業務の文章でコーディングする」 第一印象 業務の〜もなにも文章は全部日本語じゃん？ そもそも、じゃあ DDD でなければ何の文章で実装していると仰るの？ 曰く「DDD だと変更に強い」 第一印象 DDD
サービス間連携のためのGraphQL APIをClojureで開発している話 - Opt Technologies Magazine
社内共有のマスタデータ基盤としてのGraphQL APIをプログラミング言語Clojureで開発している事例をご紹介します。 あいさつ 新規API開発の背景 現行システムの問題点: 共有データベース 解決策: データベースをラップするサービス 技術選定の経緯 API方式: GraphQL メイン開発言語: Clojure アプリケーションのアーキテクチャ設計 The Clean Architecture コードの全体像 resolver use case entity boundary 主な要素技術 アプリケーション構成の整理とライフサイクル管理: Duct GraphQL APIサーバ: Lacinia + Pedestal 入力バリデーション: malli DBアクセス: clojure.java.jdbc + Honey SQL テストとカバレッジ計測: clojure.test +
本書では、Clean Architecture の観点から、React や Redux で構築されたアプリケーションの設計をとらえなおし、また、ときには新たな設計の提案を行います。 いままでは Clean Architecture があまり取り入れられてこなかった Web フロントエンド領域に対して、この手法を適用することを目指します。 本書が、React アプリケーション設計のその一歩先に到るための一助になれば幸いです。 試し読み：https://note.com/imamori/n/n5a7ebdbd4260 また、BOOTH でも販売しています。下記のページから購入できます。 BOOTH：https://archived-tech.booth.pm/items/2399644 英語版：https://www.amazon.co.jp/dp/B09FG94392 目次： 第1章 Cle
初めまして。9月から10月にかけて、インターンとしてミラティブのバックエンド基盤に関わっていた、logicaと申します。 今回は、期間中に扱っていたある1つのタスクにフォーカスしながら、インターンを振り返りたいと思います。 割り当てられたタスク 背景 すぐに終わる想定だった 検証用環境で問題発生！ 管理画面へのログインができない タスクの続行 原因究明 403エラー CSRFトークン セッションの非永続性 対処 そもそもCSRFトークンは永続化するべきか セッション用Clientのみ、一定確率で値を返さなくする対応を止める 今回のタスクを振り返って 終わりに 割り当てられたタスク 比較的簡単な1つ目のタスクを終え会社の雰囲気にも慣れてきた頃、出された次のタスクは「開発環境のみ一定確率でmemcachedの値を返さないようにする」というものでした。 背景 Mirrativのバックエンドは設計
【感想】『マイクロサービスパターン 実践的システムデザインのためのコード解説』：前編 - Rのつく財団入り口
「未来はすでにここにある。まだむらなく流通していないだけだ」←グッとくる 最初のエモワードがSF作家ウィリアム・ギブスンの引用でイイ！ サイバーパンク2077遊んでみた～い……じゃなかった、CloudFoundry.comのファウンダーでありMicroservices.ioの運営者、経験豊富なソフトウェアアーキテクトであるクリス・リチャードソンさんによる『Microservices Patterns』の翻訳本。 タイトルのようにアーキテクチャパターンやデザインパターンのようにマイクロサービスをパターンで体系化し、サンプルストーリーを元にした事例やコード例、OSS紹介を交えつつマイクロサービスを実践する設計方法を探求した本となっています。 Java文化圏で長く活動してきた方とのことでサンプルコードはほぼJava、Springフレームワーク、ご本人らによるマイクロサービス用のフレームワークEv
Clean Architecture を毎日１章ずつ完読しました（PDF公開） - そこに仁義はあるのか(仮)
以前のブログで100日かけてエリック・エヴァンスのドメイン駆動設計を完読しましたと書きましたが、それに続いて Clean Architecture も完読しました！ 4/21から始まり、（家庭の都合で2日おやすみもありましたが）毎日１章ずつ、全34章を無事に完読しました 🙌 そして、今回もそれぞれの章で学んだことを毎日ノートにまとめてツイートしていきました。 Clean Architectureもかなり長い間積んでいた本だったので、やっと消費できてよかった…。 Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ) 作者:Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ,角 征典,高木 正弘ドワンゴAmazon ツイートはこちらのモーメントにまとめています。 今回は他の方のツイートも一緒にモーメントに追加していきました。 モーメントは100個までしかツイートを登録で
新しいフレームワークを学ぶならTodoMVCではなくRealWorldを参考にしよう - Runner in the High
よく新しいフレームワークを学ぶにはTodoアプリを作ってみるのがよい、と言われる。実際、Todoアプリを様々なフレームワークで作ってみたサンプルをまとめたサイトもあったりする。 ところが、実際に業務で作るようなアプリケーションはTodoアプリの範疇を超えている。とくにSPAにもなると、画面遷移やWebAPI連携、大規模な状態管理などなどの条件が増えるので、Todoアプリを作っているときには考慮できていなかった大変さが出てくる。 そこで参考になるのが RealWorld example apps と呼ばれるプロジェクト 端的に言うと、TodoMVCの大規模版。 規定のスペックに沿って、様々なウェブフレームワークで作られたアプリケーションのリポジトリがリストアップされている。 スペックについて "Conduit" is a social blogging site (i.e. a Medium
20 ways to become a better Node.js developer in 2020
Don’t be that ‘screwdriver guy’, enrich your toolbox, diversify yourself Short IntroI’ve compiled below 20 skills, technologies and considerations on choosing between them. Picking the right tools became one of our greatest challenges — the Node.js ecosystem has matured and present attractive options in almost every field. Vanilla or TypeScript? Ava, Mocha or Jest? Express, Fastify or Koa? or mayb
Popular Node.js patterns and tools to re-consider | Practica.js
Node.js is maturing. Many patterns and frameworks were embraced - it's my belief that developers' productivity dramatically increased in the past years. One downside of maturity is habits - we now reuse existing techniques more often. How is this a problem? In his novel book 'Atomic Habits' the author James Clear states that: "Mastery is created by habits. However, sometimes when we're on auto-pil
不定期刊行 PHP ニュース 2023年2月10日号｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
不定期刊行 PHP ニュース 2023年2月10日号 インフィニットループ仙台支社のプログラマー、いがらしです。 PHP 界隈の気になったことをまとめ、不定期に宮城県仙台市からお送りします。前回出したのは昨年 11 月 29 日でした。 ※ なお、画像のPHP ロゴは作者の Colin Viebrock さんによってリリースされ、CC BY-SA 4.0 でライセンスされているものです。 php-src / internals PHP 8.2 Released! PHP 8.2 がリリース現在は 8.2.2 まで出ている All PHP 7.x versions are now EOL PHP 7.4 のサポートが終了 PHP RFC: Readonly amendments PHP 8.2 で入った readonly class の修正提案の投票が終了非 readonly で継承可能にす
もはやChatGPTの話題がない日はありません。これまでの3回のAIブームとは異なり、AIの冬は来ないとされています。つまり、今のAIの流れを巻き戻すことができる人はいません。 そんな with GPT 時代において、フロントエンドエンジニアは、イマイマにおいては即死することはないけど、うまく振る舞わないと、数年後生き残れないかもしれないという状況は認識すべきです。 この記事ではフロントエンドエンジニアという観点に限定して with GPT 時代にどう生き残るかに焦点を合わせていきます。 ちなみにヘッダ画像は、Stable Diffusionさんに「サバイバル」というプロンプトだけ与えて生成した画像です。サバイバルできてなさそうですが、ちょっと可愛くてシュールです。 僕は「即座にAIが仕事を奪うことは、日本では二年以内にはない」けど、「AIによってアシストされたライバルによって、案件の数と
【感想】『ちょうぜつソフトウェア設計入門 ――PHPで理解するオブジェクト指向の活用』：圧倒的表紙詐欺からのちょうぜつ深い設計入門 - Rのつく財団入り口
#ちょうぜつ本 を読み進める前に言っておく! （AA略 2022/12刊行、エンジニア界隈でも話題になった本。著者の田中ひさてるさんがSoftware Design誌に連載した記事＋アドベントカレンダー掲載の話＋カラーページに同雑誌のちょうぜつエンジニアめもりーちゃんの連載分も掲載した、ソフトウェアの設計を深く深く追求した本となっています。 表紙のキャラはちょうぜつエンジニアめもりーちゃん(銀髪?ロング姫カットの右側の子)とゆにっとさん(緑髪ショートにマリンルックの左の子)をメインに、ちょうぜつ技術書らしからぬ表紙。 最初は「オッコンピュータ書籍に時々ある萌え絵の表紙でオタク系エンジニャ〜を釣るタイプの本でゴザルな。拙者こういう本もイケるクチでござるよデュフ〜」的なちょうぜつ軽い感覚で読み始めたのですが... #ちょうぜつ本 を読み進める前に言っておく! （AA略 ちょうぜつエンジニアメモ
【Webエンジニアど素人】が【3〜4年生】くらいになったら読むといい本を目的別にまとめた - Qiita
これってなんなの？ 【ど素人状態＝社会人になって初めてプログラミングを勉強したぜ！（特に新卒）】でスタートした方々が【３年生】ぐらいになったら読むと良い本まとめです。 「どんな目的で学ぶか？」＊「職種（バックエンド/フロントエンド/SRE・インフラ/データエンジニア/どの職種のエンジニアも）」で整理しました。 「【Webエンジニアど素人から３年生ぐらいになるまでに読むと良い本】を段階的にまとめた」の続編です。少しでも皆さまの学びと成長に貢献できると幸いです。 ”Webエンジニアど素人が、3〜4年生くらいになったら読むといい本”の段階的まとめ（一部外部記事あり） バックエンドエンジニア 「より整理・洗練されたコードに改善できるレベルになろう！」 リファクタリング(第2版): 既存のコードを安全に改善する (OBJECT TECHNOLOGY SERIES) レガシーコード改善ガイド Clea
こんにちは、CTOの鈴木です！前回のブログ執筆から気がつけばなんと2年経過！今回はスペースマーケットのメインであるWebサービスとアプリ部分の技術スタックについてまとめてみようと思います。 技術スタックについては定期的にまとめており、変遷については以下の記事に書いています。 2016年 スペースマーケットを支える開発環境とアーキテクチャ – 2016年秋編 2017年 スペースマーケットの技術スタック【2017年末版】 前回2017年からの差分としてわかりやすいように、新規追加は太字、撤退したものに関しては取り消し線をつけてみてます。それでは見ていきましょうー。 Web Frontend 言語 Javascript Typescript GraphQL 言語としては、Universal Javascriptを引き続き推奨し、プロダクト施策などに絡めてTypeScriptへの移行を進めていま
異業種からWeb開発者としての生き延び
現在、会社の技術横断組織のメンバー（主にフロントエンド担当）として技術支援（壁打ち的やレビュー）やエンジニアの評価制度・採用、組織を横断したエンジニアのコーチング・メンタリングなどエンジニア組織を良くするための課題解決にそこそこの裁量をもたせてもらって事業に携わらせてもらっています。 そんなことをしている私ですが、そもそも製薬業界（学位も薬学修士を修めています）から業界転職をしており、気がつけば6年ほど経っていたのと、最近は自分のキャリアについて聴かれることも増えたので一度、開発者目線で「どんなことを？どういうモチベーションで？こんなことになったんだっけ？」を少し振り返ってみようと思います。 ※1. 今の自分の視点から振り返りつつ、またカッコでたびたびツッコミを入れながら書いていきますので、文体の時系列に違和感があるかもしれませんがなるべく書いている時の自然な気持ちを大事にしたいのでご了承
『iOSアプリ設計パターン入門』が設計に悩む『非』iOSエンジニアも救ってくれる良書だった - フリーランチ食べたい
2019年1月15日に発売された『iOSアプリ設計パターン入門』が非常に良書だったので紹介します。自分は設計に対してある悩みを抱えていたのですが、この本を読んで一気に解決ました。 peaks.cc iOSエンジニア以外でも参考になるの？ この書籍を紹介された非iOSエンジニアは当然、 「iOS開発してないけど参考になるの？」 と思うでしょう。結論から言うとなります。 事実、自分は機械学習エンジニアでiOSアプリ開発はチュートリアル程度しか経験がないですが、タイトルに書いたように非常に救われました。 この本を読むきっかけは「会社で開催されている読書会の課題図書になったこと」でしたが、その読書会参加メンバー内にもiOSエンジニアは1人もいませんでした。それでも、みんなで話し合って「これにしよう」と決めたという経緯があります。 自分の悩み: 「パターンはわかった。でもどう使うの？」 まずどんなエ
TL;DR 株式会社グロービスに入社した。元気に生存中。押忍 はじめに 2019年4月1日から新卒エンジニアとして株式会社グロービスに入社しました。 普段は、グロービス学び放題というビジネスを動画で学べる学習サービスを開発しています。 hodai.globis.co.jp RailsやGraphQLを書いていることが多いです。GraphQL-Rubyを最新に保ちつつ、アプリやフロントのエンジニアが楽しく開発できるスキーマについて考えています。 人生の転機に読み返して、価値があるように出来るだけ省略することなく書いているので長々しい文章となっています。まあ、読みたい人は読んでという感じです。 グロービスとは 学生は、知見録というメディア。社会人は、MBAを思い浮かべるのではないでしょうか？ globis.jp mba.globis.ac.jp 他にも、ビジネス書籍の出版、ベンチャーキャピタル
子育てエンジニア Advent Calendar 2020 各方面のアドカレが賑わったり突如Railsがトレンド入りしたりして師走感のある今日この頃ですが、皆様いかがお過ごしでしょうか。この記事は、Adventarの『子育てエンジニア Advent Calendar 2020』の16日目の記事です。 adventar.org 15日目はなぶさんの 子育てをGoogle Homeを使って効率化する でした。えーこのアドカレは初参加になります。おっ子育て中の自分にドンピシャやないか……と思って参加させてきただきました。 月並みですが、コロナ下で夫婦(ほぼ)リモートでの子育ての一日や環境の話など書いてみようかとも思います。 子育てエンジニア Advent Calendar 2020 登場人物 平日の一日の流れ 起床 5:40 朝活の時間 6時過ぎ～7時前後 食事～保育園 7時～8時前後 始業前の
本記事は、Engineering Manager Advent Calenderの１日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
挨拶 新規事業開発チームにてプロダクトマネージャーを担当している冨成です。 GitHubやSNSではtominaritとして活動しています。 2018年の6月1日に入社してから公式サイトのリニューアルプロジェクトを完了させて以来、新規事業開発チームのプロダクトマネージャーとして奮闘しています。 もし当時のプロジェクトに関するブログ記事にご興味がある方はこちらからどうぞ。 前提 今のプロダクトチームはWeb Engineer 7人、 Native Engineer(iOS) 2人、Product Designer 2人、 Product Manager 1人となります。今では12人と大きくなったチームですが、去年のこの時期(MVP検証時期)ではまだ3人だったため、ここ1年で爆発的に人数が増えました。 当時は人数も少なく意思決定が早かったのですが、人が増えるにつれて様々な意見が飛び交うようにな
SwiftUIに適したアプリケーション設計を思考する
2019年はWWDCでSwiftUIが発表されて大きな話題となっています。 もちろんエウレカの中でもSwiftUIについて研究したり話し合ったりしています。 SwiftUIの登場により、いままでのiOSアプリ開発が変わることは確かだと思います。 その中でも特に私が関心を持っている部分として、 UIKitによるUIドリブンなプログラミングからSwiftUIによるデータドリブンなプログラミングになる というところです。 この変化がアプリケーションの状態管理をより強くできる可能性があると考えています。 そこで、SwiftUIを使ったときの設計について考えてみました。 結論までは到達していませんが、これまで考えてきたことを考察としてまとめます。 複雑化する状態の組み合わせを上手く管理するためにアーキテクチャを選択するフロントエンド(UI)を持つソフトウェアで最も気合をいれて取り組むべきと感じるとこ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
現場で選ばれているiOSアーキテクチャ - Qiita
Clean Architecture for SwiftUI
アプリ開発着手からリリースまでにやっておきたいこと10選 - Qiita
Clean Architecture for React：Archived Technologies
コードを書きながら同時に設計していくためのiOSアプリ開発方針
モジュラモノリスを試験運用している話 - ロコガイド テックブログ
49. GoFデザインパターンとDI + リファクタリング (後編) w/ twada | fukabori.fm
フロントエンドでClean Architectureを適用してみる(+サンプルコード) - Qiita
Clean Architecture for React：Archived Technologies
インターン中、タスクに付随する予想外のエラーと戦った話 - Mirrativ Tech Blog
with GPT時代にフロントエンドエンジニアが2年後に即死しないためのメソッド｜erukiti
スペースマーケットの技術スタック【2019年末版】 | スペースマーケットブログ
株式会社グロービスに新卒として入社して半年が経った - ストロングゼロは睡眠薬
【生活】コロナ下での子育てエンジニアの日常 - Rのつく財団入り口
エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita
Decision Making Guideline - スタディサプリ Product Team Blog