タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
Linuxディレクトリ構造とファイルの種類 Linuxのディレクトリ構造もまともに把握できないまま開発をしていたのでこの機会に勉強してみました。 Linux入門者は、まずLinuxの構造について先に習得し、Linuxに適応するのに早いです。 Linuxファイルシステム構造 [全体構造図] 🚩me/はただのユーザー名の例として認識してください。 / (root) 最上のディレクトリであるルートディレクトリを意味。リナックスのすべてのディレクトリたちのスタート地点。すなわち、すべてのディレクトリを絶対経路で表記する際にこのディレクトリから始める必要がある。 /bin /binフォルダはBinary Folderの略で、OSの最小限の正常な駆動のため、すべてのユーザーが使用する実行ファイルが入っているフォルダ。 つまり、基本的なコマンドが保存されたディレクトリで、cat、chmod、chown
※この記事は、Speee Advent Calendar12日目の記事です。 昨日の記事はこちら tech.speee.jp お疲れさまです、インフラとCICDを愛するデジタルトランスフォーメーション事業本部開発基盤グループの西田和史(@k_bigwheel)です。最近はGitHub ActionsのWorkflowファイルのCue化を進めています。 本日は、開発基盤グループで採用しているTerraformのディレクトリ構造となぜそうしているのかについて書きたいと思います。 開発基盤グループで採用しているTerraformのディレクトリ構造の例 いきなりですが、うちで採用しているディレクトリ構造の例が以下です。 /aws /system-alpha /root-modules /production-account /account-unique /production1 /staging
こんにちは。 株式会社ココナラのシステムプラットフォーム部でインフラ・SREチームのチームマネージャーをしているよしたくと申します。 前回はインフラ・SREチームの主に組織的な部分を紹介しましたが、今回はより技術的な取り組みを一部紹介します。 ココナラではクラウドリソースの管理にTerraformを利用しています。今回このTerraformリポジトリのディレクトリ構造を見直すこととしたので、どのような考え方・ポリシーで構成を考えたのかを本記事で紹介します。 修正前の状態 自分が関わる前はどのような構成だったかというと、以下のような状態でした。 terraform ├── service1/ │ ├── common/ │ ├── development/ │ ├── production/ │ └── stg/ ├── service2/ │ ├── production/ ├── ser
ブログ記事に「ディレクトリ構造」を載せるときは tree コマンドを使っている．ディレクトリ構造が深すぎるときは tree -L で深さを指定できるし，不要なディレクトリがあるときは tree -I で除外もできる．今まで書いたブログ記事にも多くディレクトリ構造を載せてきた😆 tree.nathanfriend.io tree.nathanfriend.io を使うと tree コマンド風のディレクトリ構造をウェブサイトで簡単に生成できる．そのままコピーしてすぐブログ記事に貼れるのは便利〜👏 今まで同じようなツールを実装しようと思ったこともあったし，今後は tree コマンドと併用してみようと思う． tree.nathanfriend.io . └── Edit me to generate/ ├── a/ │ └── nice/ │ └── tree/ │ ├── diagram!
SQLアンチパターン第2章を自分なりに噛み砕く。 階層構造とは いわゆるTree Strcture(木構造)。 例として上げるのであれば、 Reditのコメント ファイラ(フォルダ・ディレクトリ) . WindowsのExplorer . MacのFinder。 Shell ブログのカテゴリ DOM Tree ここではフォルダを想定する。 隣接リスト(Adjacency List) Tree-Structure/adjacency_list at main · teitei-tk/Tree-Structure · GitHub 単純に考えると、各フォルダに親のフォルダを参照させるやり方が想定される。 しかし、このままだとフォルダ構成が深い場合、単一のSQLで取得することが難しい。実際に見てみる。 フォルダ構成は下記 table CREATE TABLE IF NOT EXISTS `adj
こんにちは！フルサポート開発チーム兼 Embedded SRE の高畑（Sorarinu (@int_sorarinu) / Twitter）です。 最近、スノーボードだけでなくキャンプにも手を出してしまった結果、どんどん沼にハマっていっている私ですが皆さまいかがお過ごしでしょうか。 先日のシルバーウィークで 3 連休それぞれキャンプに出かけていたのですが、両日とも台風の影響で生憎の大雨となり雨濡れ耐性が格段に向上してしまいました。 さて今回は、弊社でも利用している Terraform のディレクトリ構成について、改めてベストプラクティスってなんだっけというものを考えてみたのでご紹介いたします。 事の発端 今ではマイクロサービス化も進み、各サービスそれぞれで Terraform のコードが増えてきている状態となっています。 既存の Terraform では変数（ creation フラグ）
DMMグループ Advent Calendar 2019 4日目の記事です。 この記事では、弊チームの一部プロダクトで採用したリポジトリパターンについて紹介します。 リポジトリパターンについて リポジトリパターンとはビジネスロジックとデータ操作のロジックを分離し、データ操作を抽象化したレイヤに任せるデザインパターンのことです。 リポジトリパターンでは、DBの操作や外部APIによるデータ取得等のデータソースへのアクセス部分は Repository インターフェースから完全に隠蔽されます。 そのため、アプリケーションはデータソースがDBであっても外部API静的ファイルであっても、それを意識することなくデータ操作を行うことができます。 ディレクトリ構造 今回採用したディレクトリ構造の例です。 app |--Console |--Exceptions |--Http | |--Controller
理想的なツリー構造 3階層の構造を作ることで情報を整理しやすくなります。ツリー構造と言われてイメージしにくい場合は「家」「棚」「引き出し」を思い浮かべるとわかりやすいかもしれません。 家 – ドメイン 棚 – ディレクトリ 引き出し – ページ 家（ドメイン）の中に棚（ディレクトリ）は何個でも置くことができます、棚の中の引き出し（ページ）も何個でも作ることができます。しかし、家（ドメイン）に決められたテーマは守らなければなりません。 棚の数が少なく、情報が整理整頓できないとダメですし、棚があっても引き出しが足りないと情報がスカスカなサイトに仕上がってしまいます。 ドメイン、ディレクトリ、ページには「親・子・孫」の関係を持たせ、次のような狙いでキーワードを選定することで、ユーザーにもわかりやすいツリー構造になるはずです。 WordPressの設定方法 下記の記事でWordPressの設定方法
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
2021年に、Next.jsをベースにWEBサイトを構築したので、どんな構成で構築したのかメモしておきます。 ディレクトリ構成についてはいろんな意見があり、それぞれが強い意見を持っていると思います。僕もこれが一番いい、という趣旨ではなく、あくまで一つのパターンとして参考にしてもらえたらと思います。 今回の背景は以下の要素です。 数人のエンジニアしかいない小さなスタートアップ、スピードの速い環境PMFしていないため、捨てる可能性・変更する可能性があるディレクトリ構造と方針今回、前提として極力アーキテクチャを入れない決定をしました。 その目的は「新規メンバーの参入障壁を下げる」ことです。プロジェクト初期に様々な方にアドバイスをもらったのですが、そのときに聞いた考えをまるっと参考にしました。 具体的には、DDDのようなアーキテクチャ論は用いず、ディレクトリ構造は一般的な構成＋featureディレ
先日、中規模AWSシステムを０から構築する機会がありました。構築中、コードが長くなったり、ファイルが多くなったり、関数が多くなったり悩みのつきなかったディレクトリ管理でしたが、自分なりに最適解を導いたのでここに記録しておきます 前提 dev（開発）とprd（本番）でわかれてます。環境差異が非常に多く、共通化できる項目が少なかったため、次回も新たにディレクトリをきるほどのモジュール化は不要と考えました。またセキュアな環境のため、サービスによってはコードが非常に長くなりました。そういった項目は２つくらいにならわけてもよさそうなので、ファイル分割の余地がありそうなものには★をつけています。 ディレクトリ #必須の４ファイル tfstate.tf provider.tf output.tf terraform.tfvars #IAM系 セキュアな環境ほどコードが長くなりやすいです。 iampoli
追記: こちらの記事も書きました！ ディレクトリ構造いろいろ ディレクトリ構造って結構悩みますよね。NestJSに限らずいくつかパターンを上げてみたいと思います。 Rails型 僕が最初に学んだディレクトリ構造です。 ├── controllers │ ├── userController.ts │ └── chatController.ts ├── services │ ├── userService.ts │ └── chatService.ts ├── models │ ├── user.ts │ └── chat.ts └── configs ├── presentations │ ├── userController.ts │ └── chatController.ts ├── usecases │ ├── userService.ts │ └── chatService.ts
インストール時に、特に指定していなければ、通常は、 C:\Becky!\ログオン名 というディレクトリ（フォルダ）に格納されますが、できるだけ管理しやすい場所（Cドライブ以外）をおすすめします。 どこに格納されているか、わからない場合は、次の手順で探してください。
BLOG ブログ ホーム ブログ dart-sass 採用に伴い scss ディレクトリ構造を考える scss でファイルを呼び出す際に使っていた【@import】は廃止され、代わりに【@use】【@fowerd】を使うように推奨されています。 なので【dart-sass】を採用します、それに伴って scssディレクトリ構造 や ファイルの紐付け に関してをルール化しようと思います。 dart-sass 環境準備 私は通常、指定がない限りタスクランナー(gulp)を使用して構築しています。 gulp を使用する場合であれば【gulp-dart-sass】【gulp-sass-glob-use-forward】各々のパッケージをインストールする必要があります。 gulp-dart-sass gulp-sass-glob-use-forward scss ディレクトリ ┣━ style.scs
CDKのことを良く知らなかったので，作りたいstackごとにcdk init してしまったWindymeltです。おっちょこちょい。仕事でCDKをいじっています。 さて，package.jsonがstackごとに生成されるのは困るので，1つのディレクトリにまとめる作業をするかたわら，CDKのディレクトリがどういう構造になっているのか勉強しました。 CDKにおいて，具体的にどのファイルがどういう過程を経てデプロイに至るかについて，日本語で解説された資料があまりないと感じ，初学者である自分には大変だったので，メモを整理して残すことにしました。サンプルは動かせるようになったけれどより詳しく仕組みを知りたい人の参考になれば幸いです。 構成 binとlib: AppとStackの記述場所 キホンの処理フロー npmによるタスクランナー TSのビルド 生成されるJSの役割 cdkコマンドによるappの
ディレクトリ構造の違いを理解する WindowsPCに慣れた方であれば、まずPCを立ち上げて何らかのファイルを操作したいとき、Cドライブがあって、場合によっては内蔵のDドライブがあり、外付けしているHDDのEドライブがあり…と、そのようなイメージで使用していることでしょう。 Linuxの場合は、Windowsとはかなり事情が異なり、すべてのディレクトリとファイルがルートディレクトリ配下に置かれることになります。UNIX系OSは、「FHS（Filesystem Hierarchy Standard）」というファイルシステムの階層標準が定められているのです。 Linuxファイルシステムの階層標準 「FHS」は、Linux（などのUNIX系OS）の標準的なディレクトリ構成を定めた標準仕様です。
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
