Goのパッケージ構成の失敗遍歴と現状確認
この記事は Gunosy Advent Calendar 2017の5日目の記事です。前回の記事はGunosyのパーソナライズを支える技術 -ワークフロー編-でした。 GoでAPIを書くときの問題僕の在籍するGunosyはGoを昔（？）から本番採用しておりまして、ノウハウも潤沢に溜まっている企業だと言えます。 しかし、contextの扱いやベストなパッケージ構成、テスト、net/httpでAPIを書くノウハウなどなど、迷うことは多々あります。 これは弊社特有の事情ではなく、Goのサーバーサイドエンジニア全員にとっての問題です。中でも、パッケージ構成をどうすればいいのか（相互参照せずに快適に開発を進められるパッケージ構成とは）を見つけるのは結構難しく、各々のチームにお任せ、という状況です。 今回は上記の問題のうち、パッケージ構成に踏みこんで見たいとおもいます。会社でもよくパッケージ構成をどう
あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ | フューチャー技術ブログ
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
Gocon 2015 Summer のLTで発表した資料です。 Goのパッケージ構成で 試行錯誤してみた話
前回のSBackupに引き続き、Ubuntuでバックアップを行う手法を紹介します。今回のレシピは、SBackupでは充分でない場合や、リモートバックアップが必要な場合が対象です。 SBackupによるリモートバックアップ 前回SBackupの"Destination"でSSH/FTPサーバにリモートバックアップすることができる、とお伝えしましたが、この機能の詳細を見てみましょう。 図1 SBackupの"Destination" これはSBackupが作成するバックアップファイルを、リモートマシンに作成する、という機能です。 UbuntuのDesktop CDからインストールしたシステムが相手の場合、標準ではSSH serverとしての機能はインストールされていませんので、Synapticで"openssh-server"パッケージをインストールしてください。 図2 Synapticによる
Slim3では、ルートパッケージ直下がagileパッケージとfirmパッケージに分かれます。agileパッケージには、agileに開発する必要のある機能要件に応じたクラスが入ります。firmパッケージには、ユーザの要件には直接関係しない非機能要件に応じたクラス(一般的にはインフラストラクチャ層のクラス)が入ります。 例えば、ルートパッケージがtutorialの場合、次のようになります。agileとかfirmの名前はもちろん自由に選べます。 tutorial root package tutorial.agile agile package tutorial.agile.action agile package for action tutorial.agile.xxx agile package for xxx tutorial.firm firm package tutorial.fir
CTOのishkawaです。 この記事は10X アドベントカレンダー2023の3日目の記事です。 先日、サーバーサイドのメンバーを中心として、コードをどのように分割管理していくか話すオフサイトを実施しました。オフラインで1日中話していたこともあり、話題は色々な方向に進んだのですが、その中でもモノリス解体にトピックを絞ってシェアしたいと思います(他の話は他のメンバーが書いてくれるはず！)。 前提 10Xには4つの開発チームがあります(お買い物チーム、お会計チーム、お届けチーム、マスターデータチーム)。今年の4月にチーム分割が始まり、コードやデータのオーナーシップも各チームにアサインしてきました。 この組織移行によってオーナーシップ分割は進んでいるものの、依然としてモノリスのパッケージ(Dartのパッケージ)は大きいままで、ほとんどのコードがそこにある状態でした。領域ごとのディレクトリ分割は進
この記事はGunosy Advent Calendar 2015の16日目の記事です。 先日のeureka.goでも話があったように、弊社でもGoでAPIサーバーを作るときのパッケージ構成とリポジトリ構成が未だにしっくりこない現状です。。。 弊社のパッケージ管理方針（現時点） vendoringはしない（最悪の場合、forkする） gopkg.inを考慮しているライブラリは積極的にgopkg.inを使う
更新しました (2017/4/12) この記事を書いたときから大分時間が経ったので、最新版をこちらに書き直しました。 基本的な階層構造 AndroidでMVCを適用しようとすると、Activity/FragmentがViewとController両方の責務を担っていて綺麗にVとCを分離できず、もやっとしてしました。そこで、色々な資料やサンプルを見たところ、 http://www.slideshare.net/mokemokechicken/iosandroidmodel にある階層構造が一番しっくり来たのでこれをベースにパッケージ構造を考えることにします。 ユーザー操作に近い順に、以下の３階層に分類されます。 プレゼンター層 UIの制御やユーザーの入力に対する制御を扱う層。MVCでいうとVCにあたる。 ビジネス層 ビジネスロジックを扱う層。MVCでいうとMのうち抽象度の高い部分。 データ層
ちょうど二年前のアドベントカレンダーでこんな記事を書いていたようです。 現状はどうしてるのか当時を振り返りながらまとめようかなと思います vendoringについて 依存管理は、depを使ってます。（depが出るまではglide使ってました） 2年前にくらべると色々と便利になって普通に使っていけるようになりました。 当時はまだGo1.5とかでしたね... 主に使ってるライブラリ とりあえず以下使ってますという感じ goa gorm 詳細はこちら https://qiita.com/kyokomi/items/dcd8384a0a042d72d22d パッケージ構成とか もともとDDD本に出てくるレイヤードアーキテクチャを意識してたんですが、いつの間にかオニオンアーキテクチャ風になっていたようです。 現時点では、この形が自分の中ではベストかなと思ってます。 ├── application ├
Ubuntu(Debian）を何度もインストールしていると、パッケージのインストールコマンドを何度も叩いていて嫌になり、面倒だからdd して深みにはまったり。手抜きしてrsyncしてヒドい状態になったり。。。仕方ないので apt-get install XX -y をbashで書いたりしてました。 DebianのAptには、パッケージインストール一覧を保存する機能がある。 保存したインストール一覧を使って、パッケージをまとめて再インストール出来る機能がある。ときどき、パッケージのインストールやサーバーの設定をバイトに投げている事例や、複数台にddしている事例を見るが、パッケージ構成をパッケージ管理システムに任せた方がずっと楽が出来る。 aptのインストール済みパッケージ一覧 dpkg --get-selections > installed.list 出力例（抜粋 acl install
以前Androidのパッケージ構成について考えてみたという記事を書いたんですが、書いたときから結構時間が経って考え方が変わった箇所もあるので、再度まとめようと思います。 前提 アプリケーションのアーキテクチャには、MVVM with data bindingを採用しています。また、モデルは階層化アーキテクチャ（っぽい何か）を採用しています。 結論 こんな感じになりました。ここでは以下で説明する順に並べていますが、Android Studio上ではアルファベット順に並びます。 com.example.myapp |- di | |- scope | |- model | |- entity | |- usecase | |- repository | |- dao | |- net | |- ui | |- base | |- util | |- view | |- foo | |- bar
良いクラス構造を学ぶためには、複数の偉い人のソースを読むのが一番良い オブジェクト指向言語に限らず、どのようなプログラムを組むにしても、 クラス分割やモジュールの分割は再利用性・保守性を高める上で重要な点だと思います。 もちろん、iPhoneのアプリ開発だってそうです。 Objective-CでCocoa Touchフレームワークを使い始めておよそ1ヶ月、 ようやくこのフレームワークの作法やクラス分割のコツなどがつかめてきました。 まだまだ間違っているところが多数あるような気がしますが、現段階での自分のクラス分割法を晒してみます。 まずはグループ（Javaで言うパッケージ）の分け方から。 私はこんな感じで分けることにしました。ほとんど偉い人のパクりです。 Classes Libraries 各種ライブラリを配置する JSON ImageStore その他自分が作ったアプリのロジックもここに
RHEL8のパッケージ構成 - BaseOSとApplication Stream - 赤帽エンジニアブログ
Red Hatの平です。待ちに待ったRHEL8 Betaがリリースされましたね。 今回のRHEL8の大きな変更として、今までベースレポジトリ、Optionalリポジトリ、Extrasリポジトリなどで提供されていた数々のレポジトリが見直されて、BaseOSとApplication Stream(AppStream)の2つに分かれました。 BaseOSはRHEL8を構成する上で最小限必要となるパッケージが収録されております。AppStreamはOptionalリポジトリ、Extrasリポジトリなどで提供されていたパッケージが収録されています。 従来ではベースリポジトリやSoftware Collectionに含まれていたパッケージの一部もAppStreamに移動したものがあります。これらは約6.5GBのISOイメージに両方とも含まれています。 DVD-Rには最大でも4.7GBしか書き込めないの
前回もそうでしたが、golangの話と言いつつシェルスクリプトしか出てきません。このへんで出ているような話で同じようなことで大分ガイシュツネタです。 https://github.com/mattn/goveralls/issues/20 https://github.com/golang/go/issues/6909 やったのは以下。 go test -coverprofile=coverage.outが複数パッケージに対応しておらず動かないのでディレクトリを渡り歩いてそれぞれでcoverprofileを出力しながらひとつのファイルにマージする coverallsへの投稿はmattnさんのgoverallsを使う coverprofileを出力するスクリプトは似たようなの既にたくさんあるけどこんな感じ。go list使うのはmotemenに知見をもらった。 #/bin/sh set -e
クリーンアーキテクチャや DDD の戦術的設計、CQRS などを勉強して、現状自分が気に入っているアプリケーションのパッケージ構成をさらします。 実際に Java (Spring Boot) 実装してみて、自分としてはある程度納得感を持てた構成になります。 全体像 パッケージ構成の全体像は下図の通りです。 ディレクトリで表現すると以下のようになります。 . ├── application │ ├── external │ ├── query │ │ └── user │ │ ├── UserQueryModel │ │ └── UserQueryService │ └── service │ └── user │ ├── UserApplicationService │ └── UserGetOutput ├── domain │ └── mod
iOS、Android アプリを新規開発時にフォルダ（パッケージ）構成に迷うことが多くあります。 私も多くのプロジェクトを開発しましたが、現場によって違います。 その度にどの構成が良いのか迷ったり、調べたりして時間を消費してしまっていました。 また、同じことを調べてたりしていたこともあったので、この際、自分の知見をまとめ、経験をアップデートした方が効率が良いなと思い、まとめて公開しました。 まずは、どの構成が正解なのか真剣に考えたことがなかったので調査しました。 調査に関しては下記の事を調べました。・コーディング規約等でオススメされているフォルダ（パッケージ）構成 ・他の方がオススメしているフォルダ構成 ・アプリ開発のデザインパターン ・過去のプロジェクトを調査 調査の結果・他のコーディング規約、オススメ構成を調べたが、以外と異なる。 ・過去のプロジェクトを調査したが現場によって違う。 ・
Python パッケージ構成
This Python code defines a module with version 0.0.1 that exports functions bar and buzz. If run as a script, it defines a main function that currently does nothing and calls it. The code also includes setup instructions to build documentation and package the module for distribution.Read less
はじめての Go 言語のプロジェクトを AWS Lambda + API Gateway でやったのでパッケージ構成を晒すよ
はじめての Go 言語のプロジェクトを AWS Lambda + API Gateway でやったのでパッケージ構成を晒すよ
大規模開発の最適なパッケージ構成について
java package design (principle) あたりで検索すると色々出てきますが，よく参照されているのは http://javaboutique.internet.com/Case_Study/ http://www.surfscranton.com/architecture/ObjectO … http://homepages.dcc.ufmg.br/~fpereira/classes/p … http://butunclebob.com/ArticleS.UncleBob.Princip … http://www.st.informatik.tu-darmstadt.de/pages/l … http://staff.cs.utu.fi/staff/jouni.smed/doos_06/ … http://supportline.microfocus.com/Docu
パッケージ構成 【Okapi Project】
要約 Java 言語を使ってプログラムを作るとき、最初に考えなくてはいけないのがパッケージ構成です。ここでは Okapi Project が実際に利用しているパッケージ構成についてご紹介します。 目次 1.パッケージ構成とファイル構成 1.1.パッケージ構成 1.2..ファイル構成 1.2.1.ファイル名 1.2.2.ファイル位置 1.パッケージ構成とファイル構成 1.1.パッケージ構成 Okapi Project 内で利用する Java プログラムでのパッケージ構成を以下のように定めます。パッケージ構成は一般的に利用されているドメイン名の逆順を利用することで世界的に一意のパッケージ構成となることを目的としています。 表1.Okapi Project パッケージ構成 第 1 階層第 2 階層第 3 階層第 4 階層第 5 階層第 6 階層内容
Linux で現在の RPM パッケージ構成を引き継ぐには
CentOS や Fedora などの RPM ベースの OS で、RPM のパッケージ構成を一覧出力して、他のサーバに引き継がせるときには、以下のようにすればできます。 まず、パッケージの一覧を出力し、テキストファイルに落とします。 $ rpm -qa --qf "%{name}.%{arch}\n" | sort > list.txt 次に別のサーバに list.txt を持って行き、yum コマンドで install します。 # yum install $(cat list.text) もちろん新しいサーバにあらかじめ入っていた余計のパッケージは削除されませんので、差分をとって確認しましょう。 $ rpm -qa --qf "%{name}.%{arch}\n" | sort > list2.txt $ diff list.txt list2.txt
最新の考察 vermeer.hatenablog.jp レイヤーで論理的な役割を整理したので、次はパッケージです。 パッケージ概要 フォルダ構成例 boundedcontext ├─application │ └─service │ └─hoge │ ├─domain │ ├─model │ │ └─hoge │ │ hogeFactory │ │ hogeRepository │ ├─query │ └─rule ├─infrastructure │ └─datasource │ └─hoge │ entity │ repositoryImpl └─presentation └─hogeregister Presentation 画面（や コンポーネント）、スコープ（ConversationやFlow）の単位。 RestURIの単位。 実装技術単位ではなく、インタフェース単位でフォルダを
Amazon Linux（amzn-ami-pv-2012.09.0.x86_64-ebs）の初期のパッケージ構成 - memo.yomukaku.net
amzn-ami-pv-2012.09.0.x86_64-ebsに最初からインストールされているパッケージを確認します。 rpm -qa | sortの出力結果です。PyYAML-3.10-3.6.amzn1.x86_64 acl-2.2.49-6.9.amzn1.x86_64 acpid-1.0.10-2.1.6.amzn1.x86_64 alsa-lib-1.0.22-3.9.amzn1.x86_64 at-3.1.10-43.8.amzn1.x86_64 attr-2.4.44-7.9.amzn1.x86_64 audit-2.2-2.17.amzn1.x86_64 audit-libs-2.2-2.17.amzn1.i686 audit-libs-2.2-2.17.amzn1.x86_64 authconfig-6.1.12-10.16.amzn1.x86_64 aws-amito
こんにちは！これはGo3 Advent Calendar 2018、2日目の記事です。 1日目は、higasgtさんのredisを扱うコードをユニットテストするでした。 TL;DR Goのパッケージ構成は、標準パッケージでも複数パターンの構成が存在している 習う際は、いくつかのパッケージ構造を比較してどのように実装するかを決めるのが良い io と database/sql は有名な標準パッケージだがパッケージ構成のアプローチは異なる ioパッケージの構成について ioパッケージは io.Reader io.Writer をはじめとして有名なパッケージです。 Goを触っている人は ioutil.ReadAll() にお世話になった人も多いのではないでしょうか。 io ├── example_test.go ├── io.go ├── io_test.go ├── ioutil │ ├──
ol0ooSSIS のパッケージ構成 (dtsconfig) を使用することで、設定を外部ファイル上に設定することが可能となります。 今回の投稿では、パッケージ構成を使用して、接続マネージャーの情報を外部のファイルに設定する方法をまとめてみたいと思います。 ■接続マネージャーの情報をパッケージ構成で設定 今回はパッケージ構成を使用するために SSDT の SSIS のプロジェクトでは [パッケージ配置モデル] を使用しています。 以下のようなシンプルなデータフローを作成しています。 OLE DB ソース で SQL Server に接続して、フラット ファイル変換先のテキストファイルにテーブルの内容を出力するという流れになっています。 この時に以下の情報が接続マネージャーで設定されています。 ファイル名は環境固有になるということはないかも知れませんが、接続先やファイルの出力先の情報は開発環
パッケージ構成は、大まかに分けて３種類... One Package Repository自体を単一のパッケージとみなす Coverageが取りやすい Libraryなど、簡素な構成で済むものに向いている . ├── ctx.go ├── debug.go ├── error.go ├── handler.go ├── handler_func.go ├── jsonrpc.go ├── method.go └── parse.go Flat Package 各パッケージの責務を明確にし、分割を行う 機能ごとに分割しているイメージ Go言語の標準パッケージの構成に親しい考え方 階層を掘ったとしても、２階層ぐらいで落ち着く パッケージの責務を明確にし、お互いに疎結合を心がける Micro Serviceや、Middlewareなどに向いている . ├── ctx │ └── ctx.go
CentOSでパッケージ構成を別マシンにコピーする方法
セットアップ済みのCentOS環境にインストールされているパッケージを、別のCentOS環境にもインストールしたい場合があります。 そんな時は、まずパッケージ構成の「コピー元」となるCentOS環境で、以下のコマンドを実行しましょう。 rpm -qa --qf "%{NAME}\n" | sort > old_packages.txtこのコマンドは、インストール済みパッケージ一覧をソートして「old_packages.txt」に出力します。このファイルを、「コピー先」の環境に転送しておきます。 次に、「コピー先」では以下のコマンドを実行します。出力先ファイル名が違うだけです。 rpm -qa --qf "%{NAME}\n" | sort > new_packages.txt以下のコマンドを実行すれば、「コピー元」にインストールされていて、「コピー先」にはインストールされていないパッケージ
ol0ooSSIS のパッケージ構成 (dtsconfig) を使用することで、設定を外部ファイル上に設定することが可能となります。 今回の投稿では、パッケージ構成を使用して、接続マネージャーの情報を外部のファイルに設定する方法をまとめてみたいと思います。 ■接続マネージャーの情報をパッケージ構成で設定 今回はパッケージ構成を使用するために SSDT の SSIS のプロジェクトでは [パッケージ配置モデル] を使用しています。 以下のようなシンプルなデータフローを作成しています。 OLE DB ソース で SQL Server に接続して、フラット ファイル変換先のテキストファイルにテーブルの内容を出力するという流れになっています。 この時に以下の情報が接続マネージャーで設定されています。 ファイル名は環境固有になるということはないかも知れませんが、接続先やファイルの出力先の情報は開発環
Yasuo Higa [E-MAIL ADDRESS DELETED] 2008年 8月 19日 (火) 18:26:14 JST 前の記事 [Seasar-user:15428] [SAStruts]パッケージ構成の規約について 次の記事 [Seasar-user:15430] Re: [SAStruts] パッケージ構成の規約について 記事の並び順: [ 日付 ] [ スレッド ] [ 件名 ] [ 著者 ] ひがです。 > はじめまして、大屋と申します。 > > S2Strutsで動作しているアプリケーションをSAStrutsに移行することを検討してお > ります。 > ところが、パッケージ構成で以下の問題が出てきており、規約をどう扱うか悩んで > います。 > > 現状では、自社の規約に従い、 > <ルートパッケージ>.<サブパッケージ>.action.xxxAction >
(10)S2Flex2 java側のパッケージ構成 - hirossy javaとFlex2と。
今回からサーバーサイド(java)を少しだけ覗いてみます。 パッケージ構成は以下の通りです。結構多いです。とても全部読めそうにありません。 EnterpriseArchitectも出動させて、大変なことになってきました。 まだソースを全て読んだわけではないので以下の解説は信憑性があまりありません。現時点ではあくまでも予測です。ご注意。 ■org.seasar.flex2.core.format.amf ├─io │ ├─reader(.impl) │ │ └─factory(.impl) │ └─writer(.impl) │ └─factory(.impl) └─type(.impl) └─factory(.impl) AMF0の解析?部分だと思います。 io.readerパッケージのクラスがクライアントからのAMF0メッセージをjavaに変換しているのだと。 反対に、 io.write
FlashやFlex,(Ajax）,S2Flex2,ActionScript3,yui-frameworks,Akabanaプロジェクトなどのメモ帳 Max直前にTedさんのblogでFlex Builder 3の値下げについてアナウンスがありましたが アップグレード価格も含めた価格(米ドル)が公開されていました。 Adobe Flex™ Builder™ 3 Standard Edition - $249Adobe Flex™ Builder™ 3 Professional Edition $699 アップグレード Flex Builder 2 to Flex Builder 3 Standard Upgrade - $99 USFlex Builder 2 with Charting to Flex Builder 3 Professional Upgrade - $299 USTra
Teedaを使ったときのアーキテクチャは、Super Agileの時とEasy Enterpriseの時で違います。今回は､Super Agileのケースを書いてみます。サブアプリケーションの下に存在するクラスとルートパッケージの下に存在するクラスがありますが､使い分けは次の通りです。 サブアプリケーション配下(xxx.web.yyyなど。yyyはユースケースを表す。) ユースケース固有のクラス ルートパッケージのサブパッケージ配下(xxx.daoなど) 複数のユースケースで共通に用いられるクラス。 ユースケース固有のクラスは近くにまとまっていたほうが良く､ユースケースを横断するクラスは機能ごとにまとまっていたほうが良いという考えです。そうするとパッケージ構成は次のようになります。 xxx.web.サブアプリケーション Page, Dxo, DTOはここに入ります。 ユースケース固有のロジ
米EMC傘下のVMwareは米国時間の10月8日，サーバー向け仮想化ソフトウエアのスイート製品「VMware Infrastructure 3」の新たなパッケージ構成や機能強化について発表した。「VMware Infrastructure 3 Foundation」「同Standard」「同Enterprise」の3エディションを用意し，年内に一般リリースする予定。 Foundationは，サーバー向け仮想マシン・ソフトウエア「VMware ESX Server 3.5」，仮想インフラ管理ソフトウエア「VirtualCenter 2.5」，サーバー組み込み型ハイパーバイザ「VMware ESX Server 3i」から成り，統合バックアップ機能「VMware Consolidated Backup」やパッチおよびアップデート適用を自動管理する「VMware Update Manager」な
tl;dr; Goで複数パッケージ構成の場合何が問題か？ GitHubの場合 GitLabの場合 本題：GitLabで複数パッケージ構成のGoプロジェクトのカバレッジを集計したい .gitlab-ci.ymlのサンプル tl;dr; gcov + lcovが無難 Goで複数パッケージ構成の場合何が問題か？ Goでテストを実行する時に -cover をつけるとお手軽にカバレッジが集計できるのですが、1パッケージずつしか出力されないので複数パッケージ構成のプロジェクトの時にプロジェクト全体のカバレッジが集計できずに困ります。*1 $ go test -count=1 -cover ./... ok gitlab.com/sue445/tanuki_reminder 0.066s coverage: 77.2% of statements ok gitlab.com/sue445/tanuki_
LangChain v0.2 の パッケージ構成｜npaka
「LangChain v0.2」のパッケージ構成についてまとめました。 1. LangChain v0.2 の パッケージ構成「LangChain」のフレームワークは、複数のパッケージで構成されています。 2. langchain-core「langchain-core」には、様々なコンポーネントの基本抽象化と、それらを一緒に構成する方法が含まれています。「LLM」「VectorStore」「Retriever」 などのコアコンポーネントのインターフェイスはここで定義されています。サードパーティの統合は定義されていません。依存関係は意図的に非常に軽量に保たれています。 3. langchain「langchain」には、アプリケーションの「認知アーキテクチャ」を構成する「Chain」「Agent」「Retrieval strategies」が含まれています。 これらはサードパーティの統合で
2023.10.5追記: Goチームからプロジェクトの目的に応じたディレクトリ構造についてのドキュメントが公式に公開されています。 https://go.dev/doc/modules/layout Goでプロジェクトのフォルダ構成どうしよう、とググると見つかるStandard Go Project Layout。とはいえ、これはかなりコード量を増やしてしまう恐れがありますので、導入する場合のデメリットも考えておく方が良いです。 特に、プログラマーは、最初にみたプログラミング言語のフォルダ構成を親だと思う特性があり、Javaや.NETに影響されるとかなり細かくフォルダを切りたくなったり、package privateなど細かく可視性を制御しようとしたりして、なおかつ「privateのテストってどうすべきなんですか？」とか議論を始めたりもしますが、Go先生によればこれぐらいは1パッケージにフ
概要 DI Tool であるWireを利用した際の、Web API のパッケージ構成について考えてみました。 また、導入するメリットについてもあわせて記載しております。 github.com パッケージ構成 パッケージは下記の通りに組みました。ドメイン層込みのパッケージ構成に、provider パッケージを追加しています。 providerパッケージ配下に、wireを通してgenerateするコードを配置します。 パッケージ構成 . └── wire ├── main.go # package main ├── app # アプリケーション層 (ロジック) ├── handler # API Entrypoint ├── provider # Dependency 管理 ├── domain # ドメインモデル 管理 └── infra # データ層の実装 └── db # DB系実装 依
こんにちは。2017年11月にAndroidエンジニアとしてjoinした@katsutomuです。 前回のエントリーから、髪の毛はアップデートされておりません。そろそろ髪の毛切りに行ってさっぱりと4月を迎えたいと思っています！ さて今回は、パッケージ構成のリファクタリングについて紹介いたします。 初めに コネヒト社で開発しているママリ Android 版は、開発が始まってから 5 年以上経過しました。 開発当初からの歴史の中で、さまざまなコードを継ぎ足してきたママリ Android 版は、いくつもの改善ポイントを抱えています。この記事では、ようやくメスを入れられた 「目的のコードにたどり着くまでに時間がかかる」 という問題への取り組みを紹介します。 結論 まず、問題へ取り組んだ結果を紹介します。 対応としては、パッケージの構成を変更しました。 以下の画像は、ママリ Android 版の今ま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Goのパッケージ構成で 試行錯誤してみた話 ~ Gocon 2015 Summer
第5回 Ubuntuのバックアップ（2）：パッケージ構成の復元とリモートバックアップ・ddの利用 | gihyo.jp
HOT deployで嵌らないためのパッケージ構成 - ひがやすを技術ブログ
モノリス解体に向けたパッケージ構成 - 10X Product Blog
GunosyでのGoパッケージ構成の歴史 - Qiita
マイクロソフト、Windows 7のパッケージ構成と参考価格を発表
Androidのパッケージ構成について考えてみた - Qiita
クラスター社のGo製WebAPIのパッケージ構成について - Qiita
サーバの apt パッケージ構成を保存し再現したい - それマグで！
Androidアプリのパッケージ構成の個人的ベストプラクティス - kobakei's blog
ようやくiPhoneアプリのパッケージ構成/クラス設計のコツがわかってきました
複数パッケージ構成のgolangのプロジェクトのカバレッジを測定しcoverallsに投稿する | おそらくはそれさえも平凡な日々
自分が現状気に入っているアプリケーションのパッケージ構成をさらす - Qiita
【Xcode】【Andorid】ディレクトリ（パッケージ）構成 モダンでオススメ構成の調査結果
PS4「グランツーリスモSPORT」欧州でのパッケージ構成などを発表 収録される車種のグラフィックスを公開
パッケージ構成の考察 - システム開発で思うところ
標準パッケージから見るパッケージ構成のパターンの解説 - Qiita
SSIS のパッケージ構成を使用して接続マネージャーの情報を外部ファイルに設定 at SE の雑記
パッケージ構成 - web-technical-blog
SSIS のパッケージ構成を使用して接続マネージャーの情報を外部ファイルに設定
[Seasar-user:15429] Re: [SAStruts] パッケージ構成の規約について
Flex Builder 3の価格とパッケージ構成：nod::ぶろぐ:RIA::Flex/AIR/Flash
Teedaを使ったときのアーキテクチャ(クラス・パッケージ構成) - ひがやすを技術ブログ
VMware，「VMware Infrastructure 3」の新パッケージ構成を年内投入へ
Goで複数パッケージ構成のプロジェクトでもちゃんとカバレッジ集計する（GitLab編） - くりにっき
あなたのGoアプリ/ライブラリのパッケージ構成もっとシンプルでよくない？ | フューチャー技術ブログ
Wire を活用した Web API パッケージ構成 - Software Engineer Blog
Android版ママリアプリのリファクタ事情 ~パッケージ構成編~ - コネヒト開発者ブログ