並び順

ブックマーク数

期間指定

  • から
  • まで

161 - 200 件 / 3687件

新着順 人気順

github-actionsの検索結果161 - 200 件 / 3687件

  • GitHubのリリースノートを自動化する仕組み

    GitHub のAutomatically generated release notesを使ってリリースノートの内容を PR に基づいて自動生成するフローを作りました。 今までは、コミットメッセージのルールであるConventional Commitsとconventional-github-releaserを使って、コミットからリリースノートを自動生成していました。 他の人の PR でも、squah merge でコミットメッセージを書き換えることで、リリースノートに反映されるようにしていました。 ただ GitHub に仕組みは違うけどほぼ似たことをするAutomatically generated release notesという機能が実装されているので、これをベースに移行しようと思って、そのワークフローを作っていました。 リリースノート自動生成テクニック - mizdra’s bl

      GitHubのリリースノートを自動化する仕組み
    • 大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog

      ニッチな話題ですが、業務におけるCI/CDの現場では避けることのできない大規模リポジトリと戦うためのgit cloneのテクニックを紹介します。 この記事はDeNA Advent Calendar 2020の10日目の記事です。 CI/CDマニアの@Kesin11です。SWETではCI/CDチームの一員として、CI/CDの啓蒙活動やJenkinsを必要とするチームのサポートなどの業務を行っています。 はじめに おそらくどこの会社でも1つぐらいは巨大なリポジトリが存在しているかと思いますが、歴史あるリポジトリはgit cloneするだけで数分を要し、checkout後のリポジトリサイズがGB単位になることも珍しくないでしょう。業務で古くから存在するプロジェクトのリポジトリを触ったことがある方はきっと経験があるかと思います。 git cloneを実行するのは最初のセットアップ時だけなのであまり

        大規模リポジトリで高速にgit cloneするテクニック - DeNA Testing Blog
      • 失われた「フリーソフト」の哀愁と、今を生きる開発者への願い。 - Zopfcode

        かつて、窓の杜や Vector へウキウキでダウンロードしに行ったような「フリーソフト(フリーウェア)」たち。これら「フリーソフト」たちの中には、利用についての明示的な許諾がないソフトが多く存在する。 これらの公式な入手手段が生きている間は何も問題はない。しかし最近は、サイトが閉鎖されるばかりか、連絡先すらわからず困るケースが多くなっている。このように公式の配布手段が失われると何が困るのか。そこには大きく2つの問題がある。再利用の許諾を欠くことと、ソースコードがないことだ。 2022/12/29 追記: unasuke が「コードを公開する側」から見て同じ話題を解説した記事を公開しているので、私の記事とは別な視点が欲しい、あるいは疑問を持った方がいれば是非こちらも参照して欲しい。 blog.unasuke.com 問題1. 再利用の許諾がない(あっても曖昧) 再利用の許諾が書かれていなけれ

          失われた「フリーソフト」の哀愁と、今を生きる開発者への願い。 - Zopfcode
        • GitHub Container Registry 入門 - 生産性向上ブログ

          github.blog 9/1 に GitHub Container Registry がパブリックベータとして公開されました。GitHub が提供する Docker レジストリサービスです。 この記事では、GitHub Container Registry についていろいろ調べたり動かしたりした内容をまとめます。 目次 注意事項 背景 Docker Hub と GitHub Container Registry GitHub Packages と GitHub Container Registry 料金 organization での GitHub Container Registry の有効化 試してみる パーソナルアクセストークンの作成 イメージの push イメージの権限変更 認証なしで public イメージの pull イメージの削除 GitHub Actions から Git

            GitHub Container Registry 入門 - 生産性向上ブログ
          • GitHub Actions ことはじめ - tech.guitarrapc.cóm

            GitHub Actions 以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリを GitHub Actions に移行したけど、記事にしようとまとめてたらやった内容以上に調べることになってめちゃめちゃ時間かかった。 目次 目次 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id

              GitHub Actions ことはじめ - tech.guitarrapc.cóm
            • JAMスタックを実現する国産サービス「Kuroco」正式リリース。GitHub Actionsでビルドし、Webホスティング、APIサーバなど提供。月額1100円分まで無料

              JAMスタックを実現する国産サービス「Kuroco」正式リリース。GitHub Actionsでビルドし、Webホスティング、APIサーバなど提供。月額1100円分まで無料 kurocoは当初、いわゆる「ヘッドレスCMS」と呼ばれる機能を提供するWebサービスとして登場しました。 今回、これにGitHub Actions連携機能とWebホスティング機能などが追加されたことにより、「JAMスタック」を実現する機能が一通り揃うことになりました。 ヘッドレスCMSとJAMスタック 一般にCMS(コンテンツマネージメントサービス)は、WordPressやMovableTypeなどがよく知られています。これらはコンテンツを入力すると、あらかじめ設定されたHTMLのテンプレートにコンテンツを組み込んでWebサイトを構築してくれます。 ヘッドレスCMSとは、この一般的なCMSから、Webサイトの構築機能

                JAMスタックを実現する国産サービス「Kuroco」正式リリース。GitHub Actionsでビルドし、Webホスティング、APIサーバなど提供。月額1100円分まで無料
              • Herokuにあった個人アプリを軒並み対応した - くりにっき

                背景 やったこと1. 廃止 やったこと2. GCPに移行 ユースケース図 URLベースで見たユースケース図 実行環境で見たユースケース図 実際にGCPに移行したアプリ達 Cloud Run Cloud Functions AppEngine GCP移行した全てに共通してること やったこと3. CircleCIに移行 付録A. 道のり 付録B. 調査メモ(移行時に参考にしたドキュメントやサービスなど) 無料プラットフォームがまとまってるドキュメント ElephantSQL (PostgreSQL) PlanetScale (MySQL) Redis Enterprise Cloud 付録C. Redisを雑にFirestoreに置き換えたらクラウド破産しかけた 2022/09/22 20:45ブコメレス 背景 Herokuの無料プラン終了のため10個以上あった個人アプリを1ヶ月くらいかけて色

                  Herokuにあった個人アプリを軒並み対応した - くりにっき
                • GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです | DevelopersIO

                  GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです アクセスキー、撲滅してますか? ナカヤマです。 目黒方面より、以下のような福音が聞こえてきました。 何がどのくらい最高かと言いますと! GitHub Actions に AWS クレデンシャルを直接渡さずに IAM ロールが使えるようになることがまず最高で! クレデンシャル直渡しを回避するためだけの Self-hosted runner が必要なくなるところも最高です!!✨✨✨ https://t.co/IUQmfzkIB0 — Tori Hara (@toricls) September 15, 2021 元ネタはこちら。 Ok I blogged about it. That's how excited I am. 1. Deploy this CFN templ

                    GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです | DevelopersIO
                  • カスタム GitHub Actions 超入門

                    Oracle Exadata Database Service on Cloud@Customer (ExaDB-C@C) - UI スクリーン・キャプチャ集

                      カスタム GitHub Actions 超入門
                    • エンジニアとして2020年に関わった技術をまとめる - バーチャルおりばーハウス

                      potato4dとうなすけが2020年に使用した技術をそれぞれフロントエンドエンジニアの目線とサーバーサイドエンジニアの目線から書いてくれていたので、私も感化されて記述していこうと思う。d.potato4d.me blog.unasuke.com 私自身は2020年、本業としてFringe81(2020年12月で退職)でサーバーサイドをメインで触り、業務委託としてBlack Inc.でフロントエンドに近い開発をしていた。(あと数社お手伝い) どちらかというとサーバーとフロント、両方の立場から多角的な意見を言えるような立ち位置で仕事を行っていた年になる。 また本業においては情報処理安全確保支援士として活動を始めた年になった。社内のセキュリティ向上を目標としていた。 qiita.com qiita.com 今回は仕事で触れていた技術について、できる限りまとめていく。 --- 言語 TypeSc

                        エンジニアとして2020年に関わった技術をまとめる - バーチャルおりばーハウス
                      • パーシャルクローンとシャロークローンを活用しよう

                        Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか?Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか?Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ

                          パーシャルクローンとシャロークローンを活用しよう
                        • マネジメントとしての意思決定振り返り - Konifar's WIP

                          Engineering Manager Advent Calendar 2023 15日目の記事です。 KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。 体系的な話は HIGH OUTPUT MANAGEMENT や エンジニアリング組織論への招待、エンジニアリングマネージャーのしごと といった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。 KyashでEngineering Managerとしてやってきたこと / やっていくこと - Konifar's WIP Engineering Managerをやめた - Konifar's WIP 先に書いておくと、綺麗にうまくいった / いっているという話は

                            マネジメントとしての意思決定振り返り - Konifar's WIP
                          • 真面目にOSSを公開する際にやってみたこと・意識したこと

                            先日初めて真面目に自分のコードを OSS として公開する機会があり、色々試行錯誤したのでまとめます。 何を公開した? Vue Word Highlighter という Vue.js のコンポーネントライブラリを公開しました。 機能はとても単純で、文字列と検索クエリを渡すと検索クエリに合致した文字をハイライトする(<mark>タグ又は任意のタグ囲む)というものです。 自分なりに良い感じに使えるコンポーネントが出来たので、せっかくならば多くの人に使ってもらいたいと思い以下で記載する諸々をやってみました。 公開までにやってみたこと 🗒 READMEをちゃんと書く OSS の顔と言ったら README なので、ひと目でちゃんとしてそうな OSS 感を出すために README は整備しました。 ロゴを作る Google Font で良さそうな書体を探し一部をハイライトしただけの単純なものですが、ラ

                              真面目にOSSを公開する際にやってみたこと・意識したこと
                            • GitHub資格認定プログラムが一般ユーザも利用可能に | gihyo.jp

                              2024年1月8日、GitHubはこれまでGitHub/Microsoftの従業員とパートナーのみが利用可能であったGitHub Certifications(資格認定)プログラムを、世界中のすべての顧客も利用可能とすることを発表した。1月8日から誰でも登録サイトにアクセスしてGitHub Certificationsの学習と認定試験の準備を進めることができる。 GitHub Certifications are generally available -The GitHub Blog 利用可能な認定プログラムは以下の4種。 GitHub Foundations Certification GitHubプラットフォームの基本的な概念とGitHub製品を初めて学ぶ人向け。gitの使用方法からリポジトリ管理、コミット、ブランチ、マージ、プロジェクト管理などのGitHubコア機能をひと通り学習で

                                GitHub資格認定プログラムが一般ユーザも利用可能に | gihyo.jp
                              • あなたの組織に最適なコンテナデプロイ方法とは?〜ECSにおけるデプロイ最新機能てんこ盛り〜

                                AWSにおけるコンテナワークロード運用のデファクトスタンダードの地位を確立したECS。 デプロイ方法も進化を続け、CodeDeployとALBで連携したB/Gデプロイやカナリアリリースにも対応し、そのデプロイにおける柔軟性はEKSに勝るとも劣りません。 そんなECSですが、手段が豊富になったこともあり現状「そもそもうちの組織としてどんなデプロイ方法が最適なのか?」を選択するのが難しくなっています。 このセッションでは、ECSのデプロイ機能を紹介しつつ、マルチアカウントでの運用、リリース承認プロセス、IaCとの連携方法、GitHub Actionsも含めた最新動向を全てお伝えいたします。

                                  あなたの組織に最適なコンテナデプロイ方法とは?〜ECSにおけるデプロイ最新機能てんこ盛り〜
                                • jestでDBありのテストを高速化する

                                  課題link お手伝いしているシステムでNestJSを採用しているバックエンドのテストが遅いという課題があったので対処した。 前提link フレームワークDBテストランナーその他 テストの総数は700弱。 最終結果link 最終的には2段階の改修を経てローカルのテストが3倍速程度高速化した。 # before Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 total Snapshots: 0 total Time: 925.063 s Ran all test suites. Done in 926.48s. # ts-jestを@swc/jestに置き換えた Test Suites: 145 passed, 145 total Tests: 2 skipped, 681 passed, 683 t

                                    jestでDBありのテストを高速化する
                                  • GitHub Actionsと"仲良くなる"ための練習方法

                                    CI/CD Conference 2023 #CICD2023 https://event.cloudnativedays.jp/cicd2023/talks/1766

                                      GitHub Actionsと"仲良くなる"ための練習方法
                                    • 個人的Rails開発環境構築2024

                                      新規でRailsプロジェクトを始める時の個人的な環境構築についてまとめる。前提とする条件等は下記。 規模: ~中規模 開発者数: 個人 利用シーン: PoC作成・スタートアップ立ち上げ・並の業務アプリ開発等 基本戦略 利用シーン的に「思い立ったらすぐアプリの開発ができる」という感じの運用がしたい。極力セットアップで悩みたくないから必要なミドルウェアなどは全部Dockerでインストールできるようにして立ち上げれば終わり、の環境を作る。その環境の中で色々とコマンドを叩いたり、rails newやrails gなどでRailsアプリを作成していく。 この辺のRailsの初期セットアップの手間を出来るだけ省きたいのでtemplateとなるリポジトリを作成し、そこからcloneしてくるだけでOKにする。 フロントエンドはReactなどを使わずをRails標準のerbとHotwireを軸に開発する。開

                                        個人的Rails開発環境構築2024
                                      • 「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ

                                        要約:OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない?』と訊ね、次に『継続的にメンテナンスしてくれるの?』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など

                                          「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ
                                        • 2020年に作ったソフトウェアや開発技術をふりかえる - laiso

                                          概要 よくある年末っぽい日記の記事です。 だいだいこれどうりのバランスでソースコードも書いてる 言語はなんでもいい時はNode.jsで書く。移植性が高いので。複数人でメンテしそうな時はTypeScriptを採用し、プライベートの時は型を完全に無視する PHPはほぼLaravel。ビジネスのみの関係 Swiftはそんなに書いた記憶がないけどアプリのメンテをしてたと思う Vueも仕事で使っていたけど最近はReactに傾いてる Objective-Cは書いてない グラフに含まれてない部分だとAndroidアプリでKotlinを使って、データ分析でPythonを書いた このグラフは GitHub Profile Summary Cards っていう便利ツールを使わせてもらって自動生成している。 記録方法 コードを書く時はおもむろに ~/tmp 以下にディレクトリ掘ってIDEを開きはじめるので実質そ

                                            2020年に作ったソフトウェアや開発技術をふりかえる - laiso
                                          • そろそろオープンデータを無秩序に管理するのは卒業したいので📦データを管理するパッケージマネージャを開発した【ツール開発】 - Qiita

                                            今回はdim(オープンデータパッケージマネージャ) v1.0のリリースに伴って開発したツールの紹介をしたいと思います。 オープンデータもパッケージマネージャ(apt、npm、gem、pipなど)と同じようにnpm install xxxxxのような形でオープンデータをインストールして管理すると良いのではないかという話です。 以前のバージョンに関しては以下の記事で紹介 【個人開発】パッケージマネージャーの考えを流用してオープンデータ管理ツールを作ってみた話 以前の記事を読んでいてv1.0からの変更点に関して読みたい方 dim v1.0 変更点 オープンデータを無秩序に管理するのはやめたい ソフトウェアやライブラリの管理は世の中様々な体系化された方法が確立されつつあります。ソフトウェアであればaptやbrewなど、ライブラリであれば言語ごとにnpmやgemなどが存在します。しかし、データに関し

                                              そろそろオープンデータを無秩序に管理するのは卒業したいので📦データを管理するパッケージマネージャを開発した【ツール開発】 - Qiita
                                            • 今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog

                                              しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち

                                                今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog
                                              • We updated our RSA SSH host key

                                                SecurityWe updated our RSA SSH host keyAt approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. At approximately 05:00 UTC on March 24, out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com. We did this to protect our users from any chance of an adve

                                                  We updated our RSA SSH host key
                                                • Rubyの開発を支える技術 - クックパッド開発者ブログ

                                                  こんにちは、遠藤(@mametter)です。RubyKaigi Takeout 2020お疲れさまでした。 現在クックパッドには、フルタイムでRubyの開発をしている人が2人います(笹田と遠藤)。 それぞれ、Ruby 3の目標である並列性と静的解析の実現をメインミッションに据えて活動していますが、実はそれ以外にもRubyの開発を支えるための活動をいろいろやっています。 今回は、遠藤が関わっている範囲で、「Ruby開発者会議を支える技術」「Ruby開発のリモート議論を支える技術」「Rubyの品質を支える技術」についてざっと紹介してみます。 1. Ruby開発者会議を支える技術 Rubyに対する機能提案などの議論は、原則として、バグトラッカ上で行われます。 しかし、設計者であり最終決定権を持つmatzの多忙などの理由で、それだけでは議論が停滞してしまうのも事実です。 そこでRubyでは、開発促

                                                    Rubyの開発を支える技術 - クックパッド開発者ブログ
                                                  • 1クリックで始めるGitHubリリース as a ブログ

                                                    GitHubリリースという、GitHubでタグに対してリリースノートを書ける機能があります。 このリリースノート機能は、パーマネントリンクもあるし、Markdownも書けるし、画像もアップロードできるし、絵文字でリアクションもできるし、RSSもあるし、通知機能もあるし、GitHub Discussion連携すればコメントも書けるし、全文検索もついてくるしこれブログとして使えるんじゃないかと思いました。 そういう発想から、GitHubリリースノートをブログとして運用するためのちょっとしたブログシステムを作って使っています。 次のリポジトリが実際に動いてるものです。 azu/book-review: 本を読んだ感想を書くブログです。 リリースの一覧を見ると本の感想の記事が並んでいます。 Releases · azu/book-review Release 伴走型支援: 新しい支援と社会のカタチ

                                                      1クリックで始めるGitHubリリース as a ブログ
                                                    • GitHub Actionsをローカルで実行する(nektos/act) - くらげになりたい。

                                                      GitHub Actionsを試すときに、いちいちコミットしないといけないのがめんどくさいので、 ローカルで確認できればな〜と思い、色々調べたときの備忘録。 Dockerを立ち上げてローカルで実行できるのがあった...(*´ω`*) ・nektos/act: Run your GitHub Actions locally 🚀 使ったサンプルはこれ(*´ω`*) # ./github/workflows/build.yml # ./github/workflows/test.yml name: Act Sample on: release: types: [created] jobs: build: runs-on: ubuntu-latest steps: - run: | echo "MY_ENV_VAR = ${{ env.MY_ENV_VAR }}" echo "MY_2ND_EN

                                                        GitHub Actionsをローカルで実行する(nektos/act) - くらげになりたい。
                                                      • Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました - スタディサプリ Product Team Blog

                                                        こんにちは。 SRE の @suzuki-shunsuke です。 Terraform の CI を AWS CodeBuild (以下 CodeBuild) から GitHub Actions + tfaction に移行した話を紹介します。 これまでの Terraform Workflow (CodeBuild) 弊プロダクトの Terraform の CI に関しては過去の記事でも何度か紹介していますが、 元々 CodeBuild 上で CI を実行していました。 かつては CircleCI 上で実行していましたが、 CodeBuild に移行しました。 blog.studysapuri.jp CodeBuild に移行した理由は大きく 2 つありました。 Security 永続的な Access Key を発行することなく AWS のリソースを管理できる GCP に関しても Wor

                                                          Terraform の CI を AWS CodeBuild から GitHub Actions + tfaction に移行しました - スタディサプリ Product Team Blog
                                                        • Deno 1.0

                                                          Dynamic languages are useful tools. Scripting allows users to rapidly and succinctly tie together complex systems and express ideas without worrying about details like memory management or build systems. In recent years programming languages like Rust and Go have made it much easier to produce sophisticated native machine code; these projects are incredibly important developments in computer infra

                                                            Deno 1.0
                                                          • Web Speed Hackathon 2021 miniでほぼ満点を出しました

                                                            gzip圧縮だとあまり圧縮できていなく、スライディングウィンドウが小さいせいかなと思ったのですが、実際に大きさがかなり違うみたいなので、それが原因としてありえそうです。 Gzip uses a fixed size, 32KB window, and Brotli can use any window size from 1KB to 16MB, in powers of 2 (minus 16 bytes). This means that the Brotli window can be up to 512 times larger window than the deflate window. Results of experimenting with Brotli for dynamic web content - The Cloudflare Blog AudioContextの

                                                              Web Speed Hackathon 2021 miniでほぼ満点を出しました
                                                            • 社内のソースコードをGitHub Enterprise にとりまとめてる話 - NTT Communications Engineers' Blog

                                                              みなさんこんにちは、社内のエンジニアが働きやすくすることを目標にする Engineer Empowerment プロジェクトの @Mahito です。 この記事は、NTT Communications Advent Calendar 2021 2日目の記事です。 今回は社内のソースコードを GitHub Enterprise にとりまとめる活動とそこで遭遇した課題と解決方法についてお話します。 背景 きっかけは「NeWork のソースコードが見たい」という私の思いつきでした。 これを私が言い出した 2020 年当時、NTT Com ではソースコード管理の方法に決まりはなく、各プロジェクトの判断でバラバラにソースコードリポジトリが導入されていました。ちなみに、私が社内で見かけただけでもソースコードのホスティング先には以下のようなものがありました。 GitHub (Team plan) Git

                                                                社内のソースコードをGitHub Enterprise にとりまとめてる話 - NTT Communications Engineers' Blog
                                                              • jQuery 4.0.0 BETA! | Official jQuery Blog

                                                                jQuery 4.0.0 has been in the works for a long time, but it is now ready for a beta release! There’s a lot to cover, and the team is excited to see it released. We’ve got bug fixes, performance improvements, and some breaking changes. We removed support for IE<11 after all! Still, we expect disruption to be minimal. Many of the breaking changes are ones the team has wanted to make for years, but co

                                                                • GitHub Actionsで次のリリースにどんな変更が含まれるかを可視化する - Lento con forza

                                                                  この記事は はてなエンジニア Advent Calendar 2021 の16日目の記事です。昨日は id:masayosu の はてなにおけるCloudNative推進会の活動について でした。 サブ会という仕組みで専門領域における情報共有や深い議論ができるようになっていて、僕もスマート会*1に所属しています はてなではリリースブランチへのマージPRの管理にgit-pr-releaseをよく使っています。 git-pr-releaseは現在のリリースブランチのheadとの差分にあるPull Requestを一覧して、リリース前にチェックできます。このgit-pr-releaseはとても便利で、git-flowのようなブランチ戦略に非常にマッチしています。 一方、リリースブランチのないGitHub Flowのようなブランチ戦略を取った場合、リリースブランチが作られないため、マージ先のブラン

                                                                    GitHub Actionsで次のリリースにどんな変更が含まれるかを可視化する - Lento con forza
                                                                  • フロントエンドのテスト構成について考えてみた in 2023

                                                                    はじめに この記事では、 フロントエンドの開発において意義のあるテストはなにか? それらをコスパよく実現するためにはどうすればよいか? について考えて、作った構成を紹介します。 前提 下記の技術スタックを利用していますが、これ以外のスタックでも応用可能な仕組みが多いと思います。 Next.js Storybook playwright msw msw-snapshot (拙作) 注意事項 この記事の構成は、まだまだ実験的な機能だったり怪しい技術が一部採用されています。 msw-snapshot 拙作のライブラリであって、動作が怪しい可能性がめっちゃあります。 Next.js の testmode playwright + msw を実現するために必要でした。 まだまだ全然まともに動かないかもしれません。(サンプルリポジトリの単純なテストは動いた) サンプル 下記のリポジトリにサンプルを用意

                                                                      フロントエンドのテスト構成について考えてみた in 2023
                                                                    • GCP の Application Default Credentials を使った認証 - ぽ靴な缶

                                                                      公式ドキュメントで説明されているけど、同僚に何度か説明する機会があったり、作る必要のないサービスアカウントキーを目にすることも多いのでまとめておく。 認証情報が登場しないアプリケーションコード 例えば以下のコードで Secret Manager に保存したトークンを取得することができる。SecretManagerServiceClient にサービスアカウントキーを渡さずとも動作する。 const {SecretManagerServiceClient} = require('@google-cloud/secret-manager'); const client = new SecretManagerServiceClient(); (async () => { const [secret] = await client.accessSecretVersion({ name: 'proj

                                                                        GCP の Application Default Credentials を使った認証 - ぽ靴な缶
                                                                      • Notionでのドキュメント管理の何がつらいか - パルカワ2

                                                                        Notionでドキュメントを書いてる。ドキュメントは書く、共有する、読むなどユーザーそれぞれ色々なシナリオがあり、そのシナリオそれぞれでつらみがある。 Notionに限らずすべてのサービスは使っていればつらいところはあると思っていて、つらいとはいえNotionから別のドキュメント管理サービスに乗り換えたいという気持ちは全くなく何がつらいのか考えNotionでなにか出来ることはないか考えたり、つらみを共有することで知見を得たい。 検索がつらい フロー型とストック型の情報が入り乱れる 検索をする時はストック型の情報を探すことが多い。例えば、リリース作業手順ドキュメントを探したいときに「リリース 作業 手順」で検索するけど日報や議事録などは検索から除外したい。 Notionの検索には、FilterでPageの指定が出来るのでそれを駆使するしかない。Pageの指定をした場合、Pageの配下は検索対

                                                                          Notionでのドキュメント管理の何がつらいか - パルカワ2
                                                                        • 9割を自宅で完結?Jamstack を学んで開発環境をイチから作ってみた話 | IIJ Engineers Blog

                                                                          イラストレーターの妻が「ポートフォリオサイト欲しい」と言い始めたので、面白そうだと思い開発を開始しました。 静的サイトなら Jamstack ってのがイイらしいと最近よく聞くものの、何かはわからないので勉強してみて、巷の Jamstack 構築環境をできる限り自分の家の中に作ってみます。 結論から言うと適材適所なのですが、皆さんもコーポレートサイトやブログなど「これって Jamstack がハマるんじゃないかな」と思える箇所があると思います。 是非、検討する材料としてこの記事をご覧ください。 Netlify 社が定義した JavaScript + API + Markup (JAM)  の構成を Jamstack と呼ぶようです。 まずは Jamstack の何が嬉しいか、見ていきましょう。 従来の Web サイト 従来の構成でサーバサイドがレンダリングした Web サイトを表示するまでの

                                                                            9割を自宅で完結?Jamstack を学んで開発環境をイチから作ってみた話 | IIJ Engineers Blog
                                                                          • TypeScript エラー処理パターン - Object.create(null)

                                                                            M 年前にも N 年後にも人類は同じ話をしている. まとめ エラーの発生方法は throw と return に大別できる throw には簡潔さ, return には明瞭さと型安全性といった特徴がある どちらの方法がより適しているかはプログラムの規模, エラーの種類, ハンドリングの方法などが判断の材料になる 実際にどちらの方法を使うかは上の判断材料と, フレームワークやプロジェクトのコーディング規約なども合わせて複合的に決めるのがよい エラー発生方法の分類 まず前提として, 関数から呼び出し元にエラーを伝える方法は以下の 2 つに大別できます. 逆にこの記事ではこれ以上の具体的な方法についての議論はしません. throw エラーを throw して呼び出し元に伝える方法です. 例えば以下のようなものが当てはまります. throw new Error("...") Promise.rej

                                                                              TypeScript エラー処理パターン - Object.create(null)
                                                                            • GitHub Codespaces 雑感

                                                                              GitHub Codespacesをちょっと試した。 初期導入時にハマりどころも多いけど、真面目に設定しておけば、普通にCodespacesの環境だけで開発することは十分できそうだなと感じた。リポジトリ単位で環境を用意するのが基本で、多くのリポジトリに対して毎日のようにレビューをしたりPull Requestを出したり、みたいな開発フローには綺麗にはまらないと思うけど、普通に仕事で単一のリポジトリに対してだけ作業する用途であれば上手くはまると思う。Zoomで会議しながら重い処理を実行していても影響が無いのは良かった。Zoomで会議しながら重い処理を回すべきではないという意見もある。 Codespacesの利用の流れ Codepsacesを利用するときの流れについて。まず、予め .devcontainer/devcontainer.json を配置したリポジトリを用意しておく。Codespa

                                                                              • GPT-3.5-turbo を Fine-tuning して GPT-4 相当の性能を獲得する - DROBEプロダクト開発ブログ

                                                                                はじめに 結論 背景 課題 Fine-tuning とは? Data の準備 Fine-tuning を実施 結果 おわりに 参考 はじめに こんにちは、DROBE の都筑です。 みなさん LLM 使っていますか。今回は GPT-3.5-turbo の Fine-tuning の事例を紹介します。 結論 GPT-4 を利用して得られたデータを使って GPT-3.5-turbo を Fine-tuning する事で、特定のタスクに関しては GPT-4 相当の性能が出る事が確認できた GPT-4 利用時点で使っていたプロンプトをそのまま使った場合の性能が一番高く、token 節約のためにプロンプトの省略をすると性能が劣化した 背景 LLM を利用したサービスの開発において、OpenAI を利用する場合にはモデルの選択肢がいくつかあります。2023年9月現在では、GPT-4 と GPT-3.5-

                                                                                  GPT-3.5-turbo を Fine-tuning して GPT-4 相当の性能を獲得する - DROBEプロダクト開発ブログ
                                                                                • CI/CD方針、テスト・QA方針と連動する三分類ブランチ管理方針で、開発での高品質と高スピードの両立を支える - 千里霧中

                                                                                  最近の開発では、CI/CD、自動テスト、継続的テストが当たり前となっていますが、その影響で、それらのCI/CD方針、テスト方針と、Git等のバージョン管理のブランチ方針をどう連携させるかが、定番の課題になっていると感じています。 今回は、このブランチ方針、CI/CD方針、テスト方針を連携させて、開発の品質とスピードを向上させるアプローチについて解説します。 結論から言うと、要点は以下の二つとなります。 バージョン管理のブランチ方針は、CI/CD方針、テスト・QA方針と不可分であり、連携を考えながら方針立てする必要がある ブランチ方針の工夫で、CI/CD、テスト・QAの開発インフラリソース消費を削減でき、本当に重要なポイントに開発インフラリソースを投入できる。これにより、限られたリソースでの高品質・高スピードの両立を支えられる 背景:開発インフラの進化が全てを解決すると楽観視していた発展期

                                                                                    CI/CD方針、テスト・QA方針と連動する三分類ブランチ管理方針で、開発での高品質と高スピードの両立を支える - 千里霧中