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パッケージにフ
前回のSBackupに引き続き、Ubuntuでバックアップを行う手法を紹介します。今回のレシピは、SBackupでは充分でない場合や、リモートバックアップが必要な場合が対象です。 SBackupによるリモートバックアップ 前回SBackupの"Destination"でSSH/FTPサーバにリモートバックアップすることができる、とお伝えしましたが、この機能の詳細を見てみましょう。 図1 SBackupの"Destination" これはSBackupが作成するバックアップファイルを、リモートマシンに作成する、という機能です。 UbuntuのDesktop CDからインストールしたシステムが相手の場合、標準ではSSH serverとしての機能はインストールされていませんので、Synapticで"openssh-server"パッケージをインストールしてください。 図2 Synapticによる
Gocon 2015 Summer のLTで発表した資料です。 Goのパッケージ構成で 試行錯誤してみた話Read less
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
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
Gocon 2015 Summer のLTで発表した資料です。 Goのパッケージ構成で 試行錯誤してみた話
パッケージ構成 【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の単位。 実装技術単位ではなく、インタフェース単位でフォルダを
こんにちは！これは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 │ ├──
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第5回 Ubuntuのバックアップ（2）：パッケージ構成の復元とリモートバックアップ・ddの利用 | gihyo.jp
Goのパッケージ構成で 試行錯誤してみた話 ~ Gocon 2015 Summer
HOT deployで嵌らないためのパッケージ構成 - ひがやすを技術ブログ
モノリス解体に向けたパッケージ構成 - 10X Product Blog
マイクロソフト、Windows 7のパッケージ構成と参考価格を発表
GunosyでのGoパッケージ構成の歴史 - Qiita
Androidのパッケージ構成について考えてみた - Qiita
クラスター社のGo製WebAPIのパッケージ構成について - Qiita
サーバの apt パッケージ構成を保存し再現したい - それマグで！
Androidアプリのパッケージ構成の個人的ベストプラクティス - kobakei's blog
ようやくiPhoneアプリのパッケージ構成/クラス設計のコツがわかってきました
複数パッケージ構成のgolangのプロジェクトのカバレッジを測定しcoverallsに投稿する | おそらくはそれさえも平凡な日々
自分が現状気に入っているアプリケーションのパッケージ構成をさらす - Qiita
【Xcode】【Andorid】ディレクトリ（パッケージ）構成 モダンでオススメ構成の調査結果
Goのパッケージ構成で 試行錯誤してみた話 ~ Gocon 2015 Summer
PS4「グランツーリスモSPORT」欧州でのパッケージ構成などを発表 収録される車種のグラフィックスを公開
パッケージ構成の考察 - システム開発で思うところ
標準パッケージから見るパッケージ構成のパターンの解説 - Qiita