タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
モノレポにすべきか、レポジトリを分割すべきか
先日 フロントエンドの Monorepo をやめてリポジトリ分割したワケ というブログがバズっていた。そのおかげか、Twitter でもモノレポに関する言及がちょこちょこあった。一家言あるドメインなので書きたい。ただの一家言(a.k.a お気持ち)なのでぜひ皆さんの意見も聞いてみたい。 tl;dr 別に自分はどっち派とかではなく、どっちも選ぶ。強いて言うならリポジトリ分割派で、依存更新がしんどくなったら monorepo 派。 免責 モノレポに対する一家言を書きたいだけであって、内容自体はフロントエンドの Monorepo をやめてリポジトリ分割したワケ と全く関係なく、そのブログで述べられている施策については何も言及しません。ただ一つ言及するとしたら肉の部位がコードネームに採用されているのは良いと思いました。🍖🍖🍖 モノレポにしたくなる状態の前提にあるもの 前提は元記事と同じように
全エンジニアが知っておくべきGithubレポジトリTop28【2023最新版】 - Qiita
この記事はNuco Advent Calendar 2023の18日目の記事です。 はじめに 本記事ではGithubレポジトリTop28を紹介します！ Githubレポジトリは日々の業務や学習に役立てることが可能です。必要な機能や学習教材は、無料で利用出来る高機能なものがあるのなら積極的に利用して役立てるべきです。 以下の内容に分けて合計28個のGithubレポジトリを紹介します！ 開発用Githubレポジトリ 学習用Githubレポジトリ QOL高めのエンジニアとして日常を過ごしたい方は参考にしてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog;
Gitで開発していて、あるサブディレクトリ以下を別のレポジトリに移行したいと思うことがある。今回はそういうことをしてみたのでメモ。 まずGitHubにそのようなやり方の指南がある（Splitting a subfolder out into a new repository - GitHub Docs）。大体これで良いのだけれど、このやり方だとサブディレクトリのpathがそのままになってしまうという問題がある。大抵のケースで、あるサブディレクトリを別のレポジトリに分割したいとなった時、そのサブディレクトリがレポジトリルートに来てほしい。 そういう場合はGit Filter Repo — Splitting a Subfolder Into A New Repository | by Edward Ezekiel | Mediumにも紹介されているようにgit filter-repo --s
GitHub - nekoruri/readcgi: 2001年の2ch閉鎖騒動の際のread.cgi CVSレポジトリをGit化したものです。脆弱性等も当時のままですので歴史的資料としてお使いください。
A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?
RHEL/CentOSから標準より新しいパッケージをインストールするためのレポジトリ4選(AppStream /RHECL/EPEL/IUS) | DevelopersIO
RHEL/CentOSから標準より新しいパッケージをインストールするためのレポジトリ4選(AppStream /RHECL/EPEL/IUS) RedHatは同じバージョンのパッケージが10年間保証されるため、安定運用に向いています。ただし、システムによっては、より新しいバージョンを利用したいことがあります。 そのようなパッケージを提供するレポジトリとして、Red Hat Software Collections(RHSCL)/EPEL/IUSを紹介します。 Red Hat Enterprise Linux (以下RHEL)/CentOS のパッケージは基本的に10年メンテナンスされるため、枯れて安定している一方で、より新しいバージョン・ソフトウェアを利用したいために、レポジトリを追加することがあります。 そのような目的に使えるレポジトリとして、以下の4つを紹介します。 AppStream
今、バージョン管理システムといえば Git です。しかしながら、Linux Kernel のコミッターの負担を軽くすることに最適化されたために、スナップショットとしての確実性・ツール規模・ユーザインタフェイスなど必ずしも完璧とはいえません。Google開発者 martinvonz 氏による新バージョン管理システム Jujutsu は Git との互換性を維持しつつ、そんな問題へ対応したツールです。本書では Jujutsu のメリットや、必要最小限のサイクルをまわせるようになるまでの簡単なオペレーションを解説します
全く初めての言語を扱うとき、その言語の一般的なやり方がわからないことが多い。これまでは書籍を読むことに加え、その言語をよく知る人に「どのレポジトリが参考になりますか？」と聞いて回り、参考になるレポジトリから一般的なやり方を理解していた。 ChatGPT(GPT-4)が出たことにより、ネット上の記事や参考レポジトリを調べ回らなくても一般的なやり方をChatGPTに直接聞くことができるようになった。一方で学習内容が2021/9までしかないため、その参考コードが古い情報を含んでいることが多い。 これらの問題を解決するため、ChatGPTに参考コードを出してもらった上で参考となるレポジトリもいくつか一緒に聞いてみると便利だった。今回はその紹介をする。 GitHub Actionsでpytestを動かしたいケース 例えばGitHub Actionsでpytestを動かしたいと考えた時、僕自身はPyt
こんにちは、Fundsチームの @convto です。Kyashでは銀行入金やコンビニ入金などの残高の入出金に関わる部分の開発をしています。 Fundsチームではその業務の性質上多数の外部ベンダとやり取りをしています。 それぞれベンダごとに仕様なども異なるため、その接続部分のいくつかはマイクロサービスとして切り出されています。 Fundsチームの管理しているサービス間の通信でgRPCを導入する際、今後の社内の別サービスなどにも汎用的に使えるようなproto管理レポジトリを構築したのでその紹介をしたいと思います。 proto管理レポジトリで満たしたい要件について はじめに、他社の事例も参考にしつつ、自分たちがprotoを管理するにあたってどのような要件を満たせれば良いのか整理しました。 他社の事例を調査したところ、以下のような構成が多かったように思います。 名称は app-proto や p
GitHub - atsuya/constitution-of-japan: このレポジトリは、現在の日本国憲法、そして現在の日本国憲法に対して日本国憲法改正案がどのような変更点を含むのかを理解するためのものです
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.
あるレポジトリを別のレポジトリのサブディレクトリへ履歴付きで移動する - $shibayu36->blog;
あるレポジトリのサブディレクトリ配下を別のレポジトリへ履歴付きで移行する - $shibayu36->blog; の逆バージョン。 あるレポジトリでずっと開発していたが、やっぱりモノレポの中に入れたいとなって、履歴付きでモノレポの特定のサブディレクトリ配下に移動したい時があった。たとえば https://github.com/shibayu36/go_todo_app の履歴をすべて https://github.com/shibayu36/go-playground のgo_todo_appディレクトリに移したいみたいなケースだ。この時コミット履歴としてはgo-playgroundのgo_todo_app/配下で初めから開発していたかのように移したい。 この解決策として Gitのサブツリーのマージについて - GitHub Docs にあるように、サブツリーマージという方法も取れる。しか
Amazon Linux 2 ExtrasレポジトリのNginx、トピック名が「nginx1」になりました | DevelopersIO
AWSチームのすずきです。 Amazon Linux 2 は extras レポジトリ を利用して Nginxパッケージを利用する際に指定するトピック名、 「nginx1.12」から「nginx1」に変更される更新がありましたので、お知らせします。 Amazon Linux 2にExtrasレポジトリからNginxをインストールする nginx1 amazon-linux-extras の トピック として 「nginx1」が追加されました。 info $ amazon-linux-extras info nginx1 nginx1 recommends nginx # yum install nginx install 2019年10月時点では、インストールされるNginxのバージョンは1.12.2。 トピック「nginx1.12」利用時と同じバージョンでした。 $ sudo amazo
はじめに GitHubでレポジトリを作成すると最初に作成されるREADME.md。 デフォルトのまま放置していたりしませんか？ README.mdはレポジトリの顔です。 ここを整えておくことで、レポジトリのクオリティをぐっと上げることができます。 しかし、README.mdに何を書いたらいいのか、わからないという人も多いと思います。 この記事ではおすすめの構成をまとめます。 README.mdの読者はだれか？ まず、誰に向けてREADME.mdを書くのかというところから考えることから始めましょう。 README.mdの読者は大きく分けてユーザと開発者の２種類います。そのレポジトリを閲覧するひとはユーザが多いのか、開発者が多いのかを想定してどちらをメインで書くか決めると良いでしょう。 README.mdは英語で書くべき？ 有名OSSはすべて英語でREADME.mdが書かれているため、当然英語
Pytorch-lightning+Hydra+wandbで作るNN実験レポジトリ - Higu`s diary
Kaggle Advent Calender2020の 11日目の記事です。 昨日はhmdhmdさんのこちらの記事です! 2020年、最もお世話になった解法を紹介します - Qiita 明日はarutema47さんの記事です! (後ほどリンクはります) 本記事では、深層学習プロジェクトで使用すると便利なライブラリ、 Pytorch-lightningとHydraとwandb(Weights&Biases)について紹介したいと思います。 対象読者 Pytorchのボイラープレートコードを減らせないか考えている 下記ライブラリについては聞いたことあるけど、試すのは億劫でやってない 書いてあること 各ライブラリの役割と簡単な使い方 各ライブラリを組み合わせて使う方法 各ライブラリのリファレンスのどこを読めばよいか、更に勉強するにはどうすればよいか また、上記3つのライブラリを使用したレポジトリを
TL;DR 巨大なモノレポはパッケージ間の依存関係に気を付けないと、変更が思わぬ所に波及して保守が大変だって？ DeepFlow 株式会社製ツール guardian を使って、Haskell モノレポのパッケージ間の依存関係が抽象化や意味論的な境界を侵犯していないかチェックしよう！ この度 OSS 化したので、巨大 Haskell モノレポの依存関係管理に困っている皆さんは是非試してみてください。 GitHub Action もあるよ。 はじめに - 巨大モノレポを保守する悲しみ 大量のパッケージから成るモノレポ[1]を管理するのが大変だというのは、あらゆる言語で共通の悩みであろうと思われる[2]。 こうしたモノレポというのは、「CIで全部ビルドできるようにしておく」というだけでは不十分で、ある箇所への変更が必要以上の部分のリビルドを惹き起こさないようにしないと、開発サイクルが全然回らずに
今いるレポジトリのPR一覧をpecoで絞り込んでcheckoutする便利コマンド作った - $shibayu36->blog;
OSS活動とか仕事をしてる時に、PRをチェックアウトするのだるいなと思っていた。そこで「今いるレポジトリのPR一覧をmodified順に出力し、pecoで選択したものをcheckout」出来たら便利だろうということで作った。 できたもの やり方 まずhubとpecoをインストールしておく。 zshを使っているならこんな感じで定義し、 function peco-git-recent-pull-requests () { local selected_pr_number=$(hub pr list --limit 40 --sort updated --format "%pC%>(8)%i%Creset %t (by @%au)%n" | peco | sed -r 's/^ +#([0-9]+).*$/\1/') if [ -n "$selected_pr_number" ]; then
Go Modules でインターネット上のレポジトリにはないローカルパッケージを import する方法 - Qiita
この記事は 株式会社 ACCESS Advent Calendar 2019 16 日目の記事です。 昨日は、@Momijinnさんが楽しげな記事を書いてくれました。 今日は、すこしマニアックな話になってしまいます。 go mod でインターネット上のレポジトリにはないローカルパッケージを扱いたいときに、go.mod の replace directive を使えばいいらしいことは分かったのですが、やってみると色々とハマったので、その時に学んだことや調べたことを記録したいと思います。 ここで記述する内容は、 go 1.13 のバージョンを前提としています。 結論 Go Modules でインターネット上のレポジトリにはないローカルパッケージを import する方法 まずはじめに、結論だけ知りたい人向けに、どうすればいいのかを記述しておきます。 以下のようなファイル構造を用意して、 sam
GitHubが値下げ、非公開レポジトリへのアクセス人数を無制限に - BRIDGE（ブリッジ）テクノロジー＆スタートアップ情報
GitHub CEO Nat Friedman Image Credit: GitHub Microsoft傘下のGitHubは、顧客企業拡大に向けた施策としてプライベート・レポジトリにアクセスできるコラボレーターの数を無制限へと変更した。このようなモデル転換は、GitHubのライバルGitLabと同様である点において、注目すべき動きだといえる。 レポジトリとは、プロジェクトのファイルや修正履歴が保存される場所のことである。昨年までGitHubは特定のユースケースに合わせていくつかの有料プランを提供しており、これらのプランではパブリック・レポジトリとプライベート・レポジトリが無制限に利用だった。一方、無料プランのユーザーはパブリック・レポジトリとオープンソースプロジェクトにしかアクセスできなかった。しかし本アップデートにより、現在ではこの制限が撤廃されている。 つまり、これまで無制限のプラ
概要 Githubにて、過去に作成、PUSHしたレポジトリを削除してしまった後、復元する方法を整理しておきたい。 削除済みのレポジトリの復元方法は他にもあるが、今回は、Githubサイトでの復元方法をメモっておきたい。 手順 ①Githubサイトにログインし、右上にある自分のアイコンをクリック→Settingをクリック ②左メニューのレポジトリをクリック ③Deleted repositoriesをクリックすると、過去に削除したレポジトリのリストが出てくる。 ④復元したりレポジトリをリストから探し、Restoreボタンを押して、復元完了！
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
AWSで動くRHEL 7のレポジトリ名称がいつの間にか変わっていた件について(RHUI2->RHUI3) - のぴぴのメモ
RHEL7にdockerをインストールしようとして、二年前に確認した手順でセットアップしようとしたらうまくいかず、2時間ぐらい唸っていたら、いつの間にかRHUIがバージョンアップしてレポジトリ名称がごっそり変わっていたらしい。 access.redhat.com 変更例 以前のExtrasリポジトリ名称: rhui-REGION-rhel-server-extras 今のExtrasリポジトリ名称: rhel-7-server-rhui-extras-rpms もう無駄なところでハマるから、メジャーバージョンの中でこう言う変更するのやめてほしい。
% npm i audited 1292 packages in 5.692s 113 packages are looking for funding run `npm fund` for details found 2 high severity vulnerabilities run `npm audit fix` to fix them, or `npm audit` for details vulnerabilities を訳すと「脆弱性」です。やばいですね。 npm audit コマンドを使うと、脆弱性に問題のあるパッケージを一覧できます。 % npm audit === npm audit security report === ... (中略) found 25 vulnerabilities (2 low, 23 high) in 1293 scanned package
今まで1人で小さい案件のフロントエンドを担当していましたが、引き継ぎや研修などで何人か入ってきたので、ヒューマンエラー防止に今まで試してみたかったGithubのpre-pushの設定をしてみました。 今回設定したのは master, developにpushする場合は ’本当にpushしますか？’ という確認が入る。yesと入力しないとpushを中止する。2. pushをする前にdevelopブランチからmergeするか確認が入る。noと入力した場合のみスキップ。コンフリクトした場合はpushを中止。 3. pushをする前にユニットテストを実行する。noと入力した場合のみスキップ。テストに落ちたら ‘落ちたけどpushしますか？’ という確認が入る。yesと入力しないとpushを中止する。 4. pushをする前にE2Eテストを実行する。noと入力した場合のみスキップ。テストに落ちたら
GraphQL APIを使って、特定のGitHub Teamが持つレポジトリ一覧を一発で取得する - $shibayu36->blog;
最近 merged-pr-statを使ってマージされたPR情報を集計したり、レビューの偏り具合を可視化するスクリプトを書いたりしていた。この時自分のチームが使っているレポジトリをどう一覧化するかに困っていた。もともとはひとまずスクリプト上でハードコードしていたが、これだとメンテが面倒。 よくよく考えてみると、GitHubのTeamでレポジトリのアクセス権限を管理してるんだから、それを使えばよいのでは？と思って調べてみたら、GraphQL APIを使ったら一発だったのでメモ。 GraphQL APIを使ってGithub Teamが持つレポジトリを取得する こんなクエリを書いたらいい。org-name1やteam-name1のところは適宜置き換える。 query { organization(login: "org-name1") { team(slug: "team-name1") { re
Dockerfileでプライベートリポジトリからレポジトリをclone。 わかります？？ 以下の記事を参考にしました。 vsupalov.com 通常このように書けばいいと思われがち。 というか自分はこれでいいと思っていた。 ARG SSH_PRIVATE_KEY RUN mkdir /root/.ssh/ RUN echo "${SSH_PRIVATE_KEY}" > /root/.ssh/id_rsa # [...] RUN rm /root/.ssh/id_rsa やっていることはいたってシンプル。 SSH_PRIVATE_KEYとしてコンテナ作成時に秘密鍵を渡すだけ。 甘い。甘すぎるよkimoton。 何がまずいの？？ 試しに上記のやばいDockerfileを使用して、以下のようにイメージを作成してみる。 SSH_PRIVATE_KEYはdocker buildコマンドの実行時に-
Elasticはオープンソースの力を信じており、コミュニティの重要性を理解しています。コミュニティを最優先することで、可能な限りすぐれたプロダクトを生み出し、ユーザーに届けることができます。Elasticセキュリティが掲げる2つのコア目標は、脅威を大規模に停止させること、そしてすべてのアナリストに武器を供給することです。本日Elasticは、新しいGitHubレポジトリ、elastic/detection-rulesを開設しました。セキュリティコミュニティと共に作業し、より大規模な脅威を停止するためのレポジトリです。 Elasticセキュリティによる検知エンジンのリリースで、Elastic Stackに自動の脅威検知機能が搭載されるようになりました。初回のリリース以降、Elasticセキュリティインテリジェンス＆分析チームは50以上のルールを検知エンジンに追加し、Linux、macOS、W
AWS CDK v2でECRのレポジトリを作ってコンテナイメージをpushし、Lambdaで実行してみた | DevelopersIO
AWS CDK v2でECRのレポジトリを作ってコンテナイメージをpushし、Lambdaで実行してみた データアナリティクス事業本部の鈴木です。 Rancher Desktopをインストールしたローカル環境からAmazon ECRにコンテナイメージを準備して、AWS Lambdaで実行してみたので、試した内容をまとめてみました。 検証の内容 今回は簡単に、以下の3点を確認しました。 AWS CDKでECRにレポジトリを作成する。 dockerコマンドでECRのレポジトリにコンテナイメージをpushする。 コンテナをLambdaで実行する。 ECRのレポジトリにコンテナイメージを上げておくと、Lambdaはもちろん、ECSやSageMakerなどのさまざまなサービスによりコンテナを利用することができます。 今回はその例の一つとして、簡単ではありますが、レポジトリの作成からLambdaでの実
Antora で AsciiDoc 形式のドキュメントが保存されたレポジトリからドキュメントサイトを生成してみる - かんがるーさんの日記
Translate to English https://translate.google.com/translate?sl=auto&tl=en&u=https%3A%2F%2Fksby.hatenablog.com%2Fentry%2F2021%2F01%2F21%2F101651 概要 記事一覧はこちらです。 AsciiDoctor は AsciiDoc 形式のドキュメントから HTML ファイル等を作成するためのツールですが、Antora は AsciiDoc 形式のドキュメントが保存されたマルチレポジトリからファイルを取得してドキュメントサイトを生成するためのツールとのこと。TOC を作るだけでなく HTML ファイルを含めてサイト全体を作ってくれるらしい。 AsciiDoctor を使った方がよいのか Antora を使った方がよいのか少し悩みましたが、よく見ると開発している人
3行で説明 最近 Gitで管理してたデータから情報が漏れて関連の大きめのインシデントが複数あった org-secretsは、コンテナ経由で動作し、環境を汚さず、管理しているすべてのレポジトリに含まれる機密情報をチェックできる ユーザ単位 or オーガニゼーション単位 GitHub, GitLab, BitBucket, Gitea対応 org-secretsはコンテナイメージで動作していて、様々なオプションが指定できる 最近公表されたインシデント 少し前に公表されたClassiさんのリリースによると、昨年発生した情報窃取は、Gitレポジトリに(AWSの)機密情報が含まれていたことが原因とされています。具体的な攻撃と対応については、該当のリリースを読むとわかります。 mercariさんも、GitHubで管理しているソースコード経由でインシデントが発生しました。※ GitHubで情報をどのよう
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JPCERT/CC、フィッシングサイトのURLデータセットを公開、GitHubレポジトリで
君のレポジトリを領域展開 - 次世代バージョン管理システム Jujutsu の世界
Terraformのレポジトリ、 ディレクトリ構成どうする？/Terraform repository, directory structure What should I do?
ChatGPTに参考となるレポジトリをいくつか聞くと便利 - $shibayu36->blog;
proto定義や成果物の管理用レポジトリを構築した話 - Kyash Product Blog
イケてるレポジトリのREADME.mdには何を書くべきか - Qiita
Guardian で巨大 Haskell レポジトリの依存関係を正気に保つ
(備忘録) Githubにてうっかりと削除したレポジトリの復元方法 - Qiita
JFrog、Kubernetes開発者コミュニティ向けのセキュリティに特化したHelmレポジトリを無償提供
久しぶりに使うレポジトリの脆弱性報告が有りまくったので npm package をアップデートをしてスッキリする
GitHooksのpre-pushを共有してレポジトリを健全に保つ
Dockerfileでプライベートリポジトリからレポジトリをclone - ばいばいバイオ
Elasticセキュリティ、検知ルールの公開レポジトリをオープン
管理するGitレポジトリに含まれる機密データをチェックする
www.youtube.com
blog.livedoor.jp/y_name
qiita.com/mkc1370
www.nikkei.com
gendai.media
rinsimpl.com