現在、会社の技術横断組織のメンバー(主にフロントエンド担当)として技術支援(壁打ち的やレビュー)やエンジニアの評価制度・採用、組織を横断したエンジニアのコーチング・メンタリングなどエンジニア組織を良くするための課題解決にそこそこの裁量をもたせてもらって事業に携わらせてもらっています。 そんなことをしている私ですが、そもそも製薬業界(学位も薬学修士を修めています)から業界転職をしており、気がつけば6年ほど経っていたのと、最近は自分のキャリアについて聴かれることも増えたので一度、開発者目線で「どんなことを?どういうモチベーションで?こんなことになったんだっけ?」を少し振り返ってみようと思います。 ※1. 今の自分の視点から振り返りつつ、またカッコでたびたびツッコミを入れながら書いていきますので、文体の時系列に違和感があるかもしれませんがなるべく書いている時の自然な気持ちを大事にしたいのでご了承
TL;DR 株式会社グロービスに入社した。元気に生存中。押忍 はじめに 2019年4月1日から新卒エンジニアとして株式会社グロービスに入社しました。 普段は、グロービス学び放題というビジネスを動画で学べる学習サービスを開発しています。 hodai.globis.co.jp RailsやGraphQLを書いていることが多いです。GraphQL-Rubyを最新に保ちつつ、アプリやフロントのエンジニアが楽しく開発できるスキーマについて考えています。 人生の転機に読み返して、価値があるように出来るだけ省略することなく書いているので長々しい文章となっています。まあ、読みたい人は読んでという感じです。 グロービスとは 学生は、知見録というメディア。社会人は、MBAを思い浮かべるのではないでしょうか? globis.jp mba.globis.ac.jp 他にも、ビジネス書籍の出版、ベンチャーキャピタル
Clean Architecture と React を組み合わせるデモアプリが eduardomoroni/react-clean-architecture というリポジトリにあったので、コードを覗いたら勉強になった。 Clean Architecture を大づかみに理解する よく出てくる図。 私の理解している限りでは、 Clean Architecture において重要なのはモジュールの依存関係に規律を導入することで、中でも「重要なビジネスルール」を中心に依存関係を整理することであると思っている。 SOLID原則とか小難しい用語がたくさん出てくるけど、要するにそれはモジュールをどう分割するか、モジュール同士をどう結合するかに関する原則で、Clean Architecture を実践的に導入しようとしたら必要になってくるものだろう。 でも上の図を理解するだけだったら、もっとシンプルに説
イベント参加申込はこちら 「Developers.IO 2016」は、クラスメソッド株式会社の技術ブログ『Developers.IO』をそのまま現実化するイベントです。2015年3月、2016年2月に開催し、それぞれ400名、657名のお申込みをいただきました。今年は、ツアー形式で各地を回っていきます。第一弾は大阪です。 大阪で取り扱うトピックはAmazon Aurora、Scala、Play Framework、OpenIDなどです。運営はゆるく、内容は濃く、「やってみた系技術ブログ」らしい内容になる予定です。 Developers.IO 2016 – シリーズ – #cmdevio2016 Developers.IO 2016 イベントフォトレポート セッション内容 Amazon Aurora の活用 〜 低コストに高可用性とハイスケーラビリティを実現 〜 Amazon Aurora
本記事は、Engineering Manager Advent Calenderの1日目です。 はじめに エンジニアリングマネージャ(EM)と呼ばれる職務を設置する企業が増えてきました。 私たちの主催したイベントEOF2019でも700名近い方に参加していだき、また多くの方にご協力いただき成功裏に終わることができました。 EM Meetup/EM.FMなどのムーブメントの中心の一翼を担わせていただき、その高まりを感じる一方で不安も感じます。このエンジニアリングマネージャという職務は非常に多岐にわたるケースが存在していますし、必要だとされるスキルもまちまちです。そして、多くの場合、その企業のステージや状況ごとに求めるものは違います。また、求めていることを明文化することすらされていないケースも存在します。 このことから、エンジニアリングマネージメント自体が一時的な潮流として消費され、消えていっ
子育てエンジニア Advent Calendar 2020 各方面のアドカレが賑わったり突如Railsがトレンド入りしたりして師走感のある今日この頃ですが、皆様いかがお過ごしでしょうか。この記事は、Adventarの『子育てエンジニア Advent Calendar 2020』の16日目の記事です。 adventar.org 15日目はなぶさんの 子育てをGoogle Homeを使って効率化する でした。えーこのアドカレは初参加になります。おっ子育て中の自分にドンピシャやないか……と思って参加させてきただきました。 月並みですが、コロナ下で夫婦(ほぼ)リモートでの子育ての一日や環境の話など書いてみようかとも思います。 子育てエンジニア Advent Calendar 2020 登場人物 平日の一日の流れ 起床 5:40 朝活の時間 6時過ぎ~7時前後 食事~保育園 7時~8時前後 始業前の
2019年1月15日に発売された『iOSアプリ設計パターン入門』が非常に良書だったので紹介します。自分は設計に対してある悩みを抱えていたのですが、この本を読んで一気に解決ました。 peaks.cc iOSエンジニア以外でも参考になるの? この書籍を紹介された非iOSエンジニアは当然、 「iOS開発してないけど参考になるの?」 と思うでしょう。結論から言うとなります。 事実、自分は機械学習エンジニアでiOSアプリ開発はチュートリアル程度しか経験がないですが、タイトルに書いたように非常に救われました。 この本を読むきっかけは「会社で開催されている読書会の課題図書になったこと」でしたが、その読書会参加メンバー内にもiOSエンジニアは1人もいませんでした。それでも、みんなで話し合って「これにしよう」と決めたという経緯があります。 自分の悩み: 「パターンはわかった。でもどう使うの?」 まずどんなエ
挨拶 新規事業開発チームにてプロダクトマネージャーを担当している冨成です。 GitHubやSNSではtominaritとして活動しています。 2018年の6月1日に入社してから公式サイトのリニューアルプロジェクトを完了させて以来、新規事業開発チームのプロダクトマネージャーとして奮闘しています。 もし当時のプロジェクトに関するブログ記事にご興味がある方はこちらからどうぞ。 前提 今のプロダクトチームはWeb Engineer 7人、 Native Engineer(iOS) 2人、Product Designer 2人、 Product Manager 1人となります。今では12人と大きくなったチームですが、去年のこの時期(MVP検証時期)ではまだ3人だったため、ここ1年で爆発的に人数が増えました。 当時は人数も少なく意思決定が早かったのですが、人が増えるにつれて様々な意見が飛び交うようにな
TAB viewing: Different Tabs for Different Viewing Standard View for showing update of the people you follow You can get 20-200 tweets with setting in Setting > Preference Color Coordinated so you can tell the difference between replies and tweets Reply View that allows you to see only those who are @replying to you Direct Message View that allows you to see your twitter inbox Filtering View which
登壇した.ちょととまとまらないのでまとまらないまま公開します🙇 登壇のモチベーション 去年の3月に上京してきて,関西とは比較にならない数の勉強会が開催される中でドキドキしながら参加した初めての大規模な勉強会がng-japan 2015そしてDroidKaigi 2015だった.当時は登壇者を見て「いつもインターネットで見る人だ…!実在したんだ…!!」「なんてレベルの高い環境なんだ…!」と強く感動したのを今でも覚えている.同時に「自分もあそこに立てるようになりたいな」みたいなことを思った. また,上京してからはコミュニティに還元するという意味も込めて月1回以上はどこかで登壇するのとアウトプットを増やすのは意識していた.この1年の集大成としてDroidKaigi 2016という,ある意味はじまりのイベントで登壇できればこれ以上はないという気持ちで登壇するに至った. CPFへの応募 いざpro
2019年はWWDCでSwiftUIが発表されて大きな話題となっています。 もちろんエウレカの中でもSwiftUIについて研究したり話し合ったりしています。 SwiftUIの登場により、いままでのiOSアプリ開発が変わることは確かだと思います。 その中でも特に私が関心を持っている部分として、 UIKitによるUIドリブンなプログラミングからSwiftUIによるデータドリブンなプログラミングになる というところです。 この変化がアプリケーションの状態管理をより強くできる可能性があると考えています。 そこで、SwiftUIを使ったときの設計について考えてみました。 結論までは到達していませんが、これまで考えてきたことを考察としてまとめます。 複雑化する状態の組み合わせを上手く管理するためにアーキテクチャを選択するフロントエンド(UI)を持つソフトウェアで最も気合をいれて取り組むべきと感じるとこ
Clean Architectureとは Clean Architecture(クリーンアーキテクチャ)とは,レイヤに内側と外側の関係性を持たせるアーキテクチャである. 「外側のレイヤは内側のレイヤだけに依存する」というルールを守ることによって,アプリケーションから技術を分離することが目的である. 上の図で提案されているレイヤ構造をもとにしてpackage構成に落とし込んだものが以下の図である. ここで,実線は依存,点線は実装を表している. このpackage構成について,サンプルコード付きの解説をここでしているので,もし興味があれば読んでください. しかし,このpackage構成では次のような問題がある. 1. データの整合性を保つために複数モデルを扱うような処理はどこに置くのか? 2. ドメインモデルに持たせるべきではない処理はどこに置くのか? それぞれ,詳しく説明していく. データの
こんにちは。Sansan Android エンジニアの @rockwillj です。 はじめに もともと Java エンジニアな私が Android 未経験で Sansan に入社してからおよそ1年半が経ちました。 2年以上アプリ開発をしている人からしたら、まだまだ圧倒的に経験は足りてないですが、ようやく Android アーキテクチャについて自分なりのベタープラクティスっぽいものが見えてきた気がします。ただの気のせいかもしれないけど、もしかしたら共感してくれる人もいるのではと思い、今の自分の考えを軽くまとめておこうと思います。 ※ 注:理想的なアーキテクチャ論を語りたいのではなく、現実的なベタープラクティスについて話せればと思います。色々と突っ込みどころもあるでしょうが、できれば優しい心で読んでいただけると助かります 前提条件 どのような開発体制でどのようなアプリを作るかで適切なアーキテ
Implementations filter by tag aiohttp Akka API Platform Axon Framework Azure Functions Azure SQL CakePHP Catalyst Ceylon Clear Clojure CoffeeScript Compojure Couchbase CouchDB Crystal C# Django .NET Dropwizard Elixir ES6 express.js Finatra Finch Fintrospect Flask Flyway F# Gin Go kit Golang GORM GraalVM Gradle Grape gyokuro Hanami Hapi.js Haskell Hexagon http4k immutant Java Java EE Javalin JavaSc
Overview上記の記事で解説した通りまだPreview版ですが、Kotlin/Nativeでも遂にバックグラウンドスレッドが利用可能になりました。 この記事では、CoroutinesのFlowを使って俺の考えた最強のKotlin Multiplatform Project(MPP)設計を語ります。 ※ タイトルはネタです。設計なんてサービスによって変わります。(今回はそれなりに大きなサービスを想定しています) ※ 設計は宗教です。異教徒の人は暖かく見守って下さい。宗教戦争ダメ。ゼッタイ。 ※ Kotlin/Nativeはβ版です。さらにCoroutinesのバックグラウンド対応版はPreview版です。半年後には気が変わってるかもしれません。 ※ Clean Architecture, MVVM, MVP等の一般的な設計論は知っている前提で話します。 今回のサンプルはこちらにあります。
以前 iOS/Android 開発を経験した際に知った Clean Architecture を、Ruby/Rails な API サーバー開発に適用してみた。 Clean Architecture といえば以下の図を元にした説明が多いが、 以下の記事を参考に、今回は Data/Domain/Infra/Presentation レイヤーで分けてみる。(これが一番しっくり来ました) まだMVC,MVP,MVVMで消耗してるの? iOS Clean Architectureについて 最終的なディレクトリ構造 Rails のルールに則り、controllers だけは app 配下に配置している。 app/ controllers/ layer/ data/ entity/ repository/ domain/ model/ translator/ usecase/ view_model/
はじめに おばんです、実家の大掃除を終え、ようやくブログ執筆に戻ってこられた田中です。 さて、今年も残り数時間です。今年もいろいろなイベントに参加して、多くの人と会い、話してきました。おかげでまた楽しい一年を過ごせました。構ってくれた方々ありがとうございました、また来年も仲良くしてください。 昨年から引き続き東京二年目な私ですが、東京ではiOS関連の様々なイベントに参加してきました。今回は自分の観測する範囲でiOSコミュニティとその流れについて考えていることをまとめます。具体的に数字に基づく話ではないので、ただの一意見として、紅白に飽きた頃に読んでください。 以下のトピックについて触れていきます。 ブログを書く人が増えた気がする 飽和している発表の場 iOSの設計に関する話題が落ち着いた iOSのテストに関する話題が一般化しつつある 地方に目を向けた流れ 観測範囲として参加したイベントはだ
3月2日から3月4日にかけて、try! Swift Tokyo 2017というSwiftの技術カンファレンスが開催されました。 タイミング的な問題で個人でチケットを買ったのですが、会社の業務として参加してきました。 https://www.tryswift.co/tokyo/jp Swiftも昨年9月13日にバージョン3.0がリリースされどんどん改善が進んでいます。Swift Programming Language Evolution 多くのiOS開発者がSwift 2.3からマイグレーションを行う必要がありましたが、 今までのObjective-CやCocoa系フレームワークのルールをひきづっていた様々な規則などが削除されたり、swift standard libraryのように洗練されたりし、よりモダンになりました。 そんな中、世界中からSwift開発者が会場に集まり、言語仕様やアプ
Vim Vixen では Clean Architecture 風の設計をしており、扱うモデルやレイヤー毎にクラスを作成します。 現在はクラス数が 100 を超えて、クラスにインスタンスをいちいち渡したり、インスタンスの作成と管理が面倒になってきました。 そこで Vim Vixen では Dependency Injection (DI)コンテナを導入することにしました。 いろいろ探してみると、すでに JavaScript/TypeScript 用の DI コンテナがいくつか存在するようです。 その中で(巨人の肩に乗るつもりで)Microsoft の「TSyringe」という軽量 DI コンテナを採用しました。 https://github.com/microsoft/tsyringe TSyringe はデコレーター(Java のアノテーションのようなもの)で DI するクラスを指定した
この記事はiOS2 Advent Calendar 2017の8日目の記事です。 私事で恐縮ですが数ヶ月前に株式会社Globeeという会社のCTOに就任しまして、今はabceed analyticsという教育系アプリを開発しています。前職ではHadoop系を活用したログ収集基盤やログ解析基盤を担当していたので分野的には割と大きく変わりました。 さて、弊社のような小規模なスタートアップでは開発速度が重視されるため、自動テストがどうしても疎かになりがちです。 しかし個人的には小規模なスタートアップであっても、いけると思ったプロダクトならテストコードは書くべきだと考えています。理由はシンプルで、テストコードを書いた方が長期的に見て開発速度が上がるからです。 というわけで今回は弊社開発のアプリに自動テストを導入した時の考え方について話します。「うちはこうしている」などのアドバイス・ツッコミがありま
やりたかったこと Go言語を使用したDIパターンについて学ぶ Clean Architectureの実装について学ぶ gomockを使ったテストを実装する DI(Dependency Injection)パターンとは DIパターンはよく「依存性の注入」と言われていて”???”ってなってたけど「依存されるオブジェクトの注入」だと理解しました。このパターンを利用して、依存関係逆転の原則(DIP)を実現することができます。 Go言語でDIの実現方法 依存する実装を定義したinterfaceをつくり、そのinterfaceをstruct(構造体)のフィールドとして持たせます。その構造体に依存することで、DIパターンを実現可能です。 具体的な実装はこのサイトを参考にしました。 ・morikuni blog -GoにおけるDI Clean Architectureについて この説明は多くの方が解説して
最初に テスト駆動開発(以後TDD)の存在を知って、自分で取り入れてみてから、自分の開発は良くなったと思っています。 TDDを人におすすめしよう! と思って本を読んだり色々と調べていたりするうちに、 TDDは死んだ とか、テスト全部書かなくても...と言われていることを知りました。 それでも自分はTDDで開発するのが好きだし、自分には合っていると思うので、自分がTDDを愛する理由を書いてみたのがこの記事です。 若干ポエム寄りになっているかもしれませんが、ご容赦いただけると幸いです。 前提としていること TDDの基本的な流れとして、タスク細分化→Red/Green/Refactoringのループを回す、であること 実践者は初心者であり、実装にまだ不慣れであること(内容についての言い訳ではなく、そういう人がTDDを実践した事で感じた事を書いたという意味) TDDではなく自動テストによる恩恵も含
Firefox Focus is private browsing as an app: It automatically blocks ads and trackers, so you can surf the web in peace. When you’re done, a single tap completely erases your history, cookies, and other local data. Protecting you from invasive tracking is part of Mozilla’s non-profit mission, and Focus’s built-in tracking protection helps keep you safe. It also makes websites load faster! With Foc
Do you resonate with any of the following? Do your view controllers become massive and hard to understand, fix bugs, and add new features? Okay, you moved the business logic to the models. But now your models become too fat. Does your app use one gigantic storyboard? Have you ever wasted 4 hours to try to reproduce a bug, and then a week to fix it? And still going nowhere? Ready to just monkey pat
実際の学習の流れ AWS認定『ソリューションアーキテクト- アソシエイト』(SAA)を攻略したので振り返るエントリの2回目です。1回目のふりかえりのエントリ、思いのほか多くのアクセスを頂きありがとうございました。当ブログのブクマランキングNo.5更新です。 今度は実際の学習に直接関わるところを、流れとして振り返ってみます。 実際の学習の流れ 参考書による学習 公式提供のリソースを参照する AWS Technical Essentials 1 AWS Technical Essentials 2 Developing on AWS 3冊目の本でまとめ学習 ネット上の問題集で学ぶ おまけ:各種数値も集計しておく 公式模試を受ける サンプル問題(見ませんでした) 受験日程を正式に決める Udemyの講座で学ぶ 当日まで無事に過ごす(予定) 試験会場の話 試験当日 試験会場へ テストセンターでの受
こんにちは、自宅でのリモート環境が整って音楽制作が捗りそうな soe-j です。 アンドパッドには5月に入社しました。 入ってすぐ「良い取り組みだなあ」と思ったのが、毎朝開催されている「10min勉強会」でした。 いろんな企業さんで行われているかもですが、今回はアンドパッドではどんな感じで実施されているのか紹介できればと思います。 毎朝の文化 現在のタイムテーブルはこんな感じ。 毎日、朝会が始まる11時の直前まで開催されています。 なるべく時間が被らないように開催されるので、気になるものを選んでハシゴすることもできます。 データ分析 9:00〜 k8s 9:30〜 Vue.js 10:00〜 Flutter 10:30〜 30分置きなのはバッファで、これが詰め込む限界かと思います。 (9時前も空いてるじゃないかって?) 以前には、Monolith to MicroServicesというテー
Androidのテストとかちゃんと取り組んだことないので知見を得るために行ってきました。 (もしかしたらあとで追記するかも) コードレビューをより良くする Danger x Android 今日の発表資料です。 皆でDanger使いましょう! https://t.co/KbYCNaRgDi #android_test_night— とし (@tarappo) 2017年9月21日 感想 Webhookは結構やってるけどここらへんの取り組みはまだしていないのでやってみたくなる reviewのコメントでチェックがかかる機構は緊急時にすっ飛ばすとかもできるので便利そう Androidのテストを効率的にするために考えたこと (スライドなさそう) テストの効率化にあたり、どう自動化をしたか、何を優先的にやっていったかという話でした。 感想 古くなったテストコードを捨ててイチから作り直すという決断。
はてなブックマーク数による人気記事のランキング。7月28日(日)から8月3日(土)〔2019年8月第1週〕のトップ30です*1。 # タイトル/著者とブックマーク 1 東京から1泊2日で行けるおすすめ温泉チャートを作りました - いつか住みたい三軒茶屋 by id:takachilog 2 初心者が無料で勉強できる良教材いろいろまとめ - orangeitems’s diary by id:orangeitems 3 15年間務めた会社に退社を切り出したら史上稀にみるクソ展開になった(後編) - 放浪軍師のアプリ開発局 by id:roamschemer 4 Amazonが怪しい中国製品で埋め尽くされている中、僕たちはどうやってまともな商品を見つけたらいいか - 俺の遺言を聴いてほしい by id:hideyoshi1537 5 【イベント】ドラクエ映画をドラクエ5小説作者が提訴。その理由
前回の記事の続きです。 katsuki.hatenablog.com 上記事の内容を一言で表すとエンジニアの成長戦略として自分の階層を把握した上で学習内容を選択することが大事 というものです。 当記事では、戦略階層ごとにエンジニアの職位をプロットし、各階層で具体的に求められる責任範囲と、学習すべき書籍について整理してみました。 戦略の階層 役職 責任範囲 書籍 世界観 創業者 ビジョン, ミッション, コアバリューの策定どのような会社にしたいかどのような世界をつくりたいか ザ・ビジョン 進むべき道は見えているか 政策 取締役 会社全体の舵取り、方向性、カルチャーづくり長期戦略、市場の策定 ビジョナリー・カンパニー ― 時代を超える生存の原則その他経営戦略の本etc 大戦略 CTO, VPoE, プロダクトマネージャー サービス全体の技術基盤, アーキテクチャー選定エンジニア組織構築, 採用
【追記(2020/06/08)】 本投稿に頂いたコメントを基に加筆しました。以下に挙げた項目に対して加筆し、加筆した部分は【追記】と記載しています。 View Presenter / View Model 【追記(2020/05/31)】 同期の子から貰ったコメントを基に加筆しました。以下に挙げた項目に対して加筆し、加筆した部分は【追記】と記載しています。 SOLID原則 Form Request 新卒研修で「Laravelを使ってアプリケーションを自分で作ってみよう。」という趣旨のコーナーがあり、同期がやっていることを真似てClean Architectureを導入してみるも、無事、爆死することに成功しました。この投稿は、爆死するまでに得た知見についてまとめたものです。 この記事を読むことで得られる知見 投稿の要旨を載せておきます。 MVCアーキテクチャに愚直に沿うと、Fat Contr
おばんです、実家から送られてくる食材や食べ物、また友達からおすそ分けしてもらう実家から送られた野菜などにとても生かされています田中です。 食材本当にありがたい。 はじめに この記事は先日登壇させていただいたiOSオールスターズ2の発表内容と関連した内容となっています。 合わせてお読みいただけると幸いです。 イベントに関してはこちらになります。 [イベントレポート] iOSオールスターズ2最速レポート! #eventdots | Developers.IO [登壇レポート] iOSオールスターズ2に登壇させていただきました! #eventdots | Developers.IO ソースコードはこちらになります。 ktanaka117/MVPTwitterSample 今記事の目標 今回の記事はクリーンアーキテクチャになじみのないiOSエンジニアの方を対象に、iOSアプリをクリーンアーキテクチ
自己紹介 さくらインターネットではシニアフロントエンドエンジニアをやっています。代表作は「NES.css」というファミコン風CSSフレームワークで、エイプリルフールには「さくらのINFRA WARS」というゲームの企画開発をしていました。 話さないこと 本記事ではソフトウェア設計ということで、以下の設計・アーキテクチャに関しては話す予定はありません。コンポーネント設計や CSS 設計に関しては過去に記事やスライドを公開していますので、気になる方はそちらを参考にしていただければと思います。 コンポーネント設計 加速するコンポーネント設計入門 / Component Design as an Accelerator コンポーネント指向時代のmargin戦略 / Rethinking the relationship between Components and Margins CSS設計 OO
はじめに こんにちは、iOSエンジニアの牟田です。 2019年に登場し界隈を賑わせたSwiftUIも3歳になり徐々に業務でも扱いやすくなってきていますね(もちろんまだまだ課題は山積みですが)。 また、2021年にはSwift Concurrencyの登場により非同期処理のパラダイムシフトが起こりました。 ウェルスナビでも重い腰を上げてSwiftUIとSwift Concurrencyをベースとした設計の検討を始め、ようやくその目処が立ったので共有します。 現状のアーキテクチャ ウェルスナビでは初期リリースから5年以上経過しており、その間に追加された時期によって画面のアーキテクチャがバラバラ(ある画面ではMVP、別の画面ではMVVM、またある画面ではClean Architecture etc...)という課題がありました。 そこで複数実装されていたアーキテクチャの中から最も相性の良かったS
目次 Clean Architectureとは Clean Architectureというと、以下の図が大変有名です。 Clean Architectureの目的は関心の分離で、 これを達成するために意識すべきことが各レイヤーの依存性です。 関心の分離によりコードの可読性が向上したり、変化に強い設計になります。 この辺のメリットやClean Architectureの詳細に関しては参考記事に載っていますのでそちら参照ください。 上記の図では、円の外側から内側に向かって矢印が向けられていますが、これが依存の向きで、 外側から内側への依存は可能ですが、内側から外側は不可能です。 言い方を変えると、内側で宣言したモノを外側から呼ぶことはできますが、外側で宣言したモノを内側から呼ぶことはできないという話です。 この記事では依存の向きに注意しながら コードを紹介していきます。 各機能に関して 各機能
はじめに こんにちは。 株式会社Nexceedにて、学生フルスタックエンジニアとして働いてる若造です。 Railsでサービス開発を行っているのですが、 サービス拡大に伴って、Railsのレイヤーきれいに分けたいなぁって思いまして、 クリーンアーキテクチャなどを参考にして、Railsのアーキテクチャを考えてみました。 参考リンク Clean Architecture 達人に学ぶソフトウェアの構造と設計 Rails:Service層を運用して良かったところ、悪かったところ 中規模Web開発のためのMVC分割とレイヤアーキテクチャ Ruby/Rails + Clean Architecture で API サーバーを実装してみる Rails Viewの表示のためにDecoratorを用意してHelperとModelを助ける 実務で学んだRailsの設計・リファクタリング Rails 4 でバリデ
static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。 インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。 ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux
前回の「2022年版実践WPF業務アプリケーションのアーキテクチャ【見積編】~ドメイン駆動設計&Clean Architectureとともに~」では、見積時に考慮が必要なアプリケーションアーキテクチャの着眼点や、その具体的な検討内容について記載しました。今回はいよいよ「設計編 機能要件の実現」ということで、見積が承認され、開発が開始して以降のフェーズに入ります。開発が開始して以降、アーキテクチャに対して影響を与える要件として「機能要件」と「非機能要件」の2つがあります。これら2つの要件からはじまって、アーキテクチャを設計していくひとつの方法をお伝えします。 前提条件 本稿はWPFアプリケーションのアーキテクチャ設計について記載したものです。見積編を前提に記載しているので、まだ未読であればそちらからお読みください。 本稿にはサーバーサイドの設計も一部含まれていますが、見積編にも記載した通り、
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く