どこでも動くWebフレームワークをつくるYAPC::Kyoto 2023 2023-03-19 Yusuke Wada
GitHub Actions上のRustアプリのDockerイメージビルドを高速化する - blog.endflow.net
Rust + Docker + GitHub Actions = めちゃ遅い 以前、GitHub Actions 上の Rust ビルドを高速化する記事を書いたけど、 今回は Kubernetes 環境にスムーズに移行できるよう Docker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、３つ (Rust, Docker, GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていた Rust アプリ
github sponsors を有効にしたことと、これからのプラグイン開発について
はじめに 最初に重要事項を発表します。私 Shougo はテキストエディタプラグイン開発に力を入 れていくために、github sponsors を有効にすることにしました。 これは大きな方針転換となります。これまでの私はオープンソース活動に対する寄付を 受け付けていなかったからです。なぜかというと、もっと自由にオープンソース活動を やりたかった、寄付を受けるとそこに責任が発生するのではないか、テキストエディタ との関係性が変わってしまうのではないかという懸念があったからです。 しかし、私もプラグイン開発を始めてからはやくも 10 年以上たちました。 昔とは完全に状況が変わってきています。プラグインやそれに使われる技術も複雑化、 高度化しかなり開発期間をかけないといけなくなりました。プラグイン開発に時間を費 すには資金が多いにこしたことはありません。 モチベーションの確保も課題です。通常の
GitHub における大規模なモノリポのパフォーマンスの向上
GitHub は、毎日 5600 万人以上の開発者にサービスを提供し、2 億以上のリポジトリをホストしています。これらのリポジトリのごく一部を除いて、世界中の顧客に驚くべきパフォーマンスでサービスを提供しています。 GitHub のような大規模なシステムでは、コードとアーキテクチャのずれというのは限界に達したときに初めて見つかるものです。例えば、何千人もの開発者が毎日同じリポジトリを更新するといったケースです。GitHub は、大規模なモノリポを使用する一部の顧客から、プッシュ操作が失敗するといったパフォーマンスの問題が発生しているというフィードバックを受けました。 そして、それは GitHub においても発生していました。 github/github は GitHub のモノリポですが、私達自身も時々プッシュに失敗することがありました。 調査を開始するにあたり、私たちは社内のチームや顧客
パーシャルクローンとシャロークローンを活用しよう
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
今までありがとうTravis CI、さよならTravis CI - xuwei-k's blog
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
CircleCI (Performance Plan) vs. Github Actions - Diary
CircleCI (Performance Plan) vs. Github Actions 結論: CircleCI を買おう 現在ユビレジでは CI は CircleCI (Performance Plan)と TravisCI を使っていて、 CircleCI: サーバーサイド(いろんな言語がある) Web フロントエンド(Rails アプリのなかで webpack が動いていたり、 create-react-app で作られたペラっとしたものがあったりいろいろある) TravisCI: iOS アプリ というような感じで使い分けている。 Performance Plan なんだから iOS のも Travis から引っ越せばいいんじゃねえの?と思わんでもないのだが、 Travis の annual 課金がまだ残ってる iOS の CI と TravisCI と CircleCI に
2018年なぜ私達はコンテナ/Dockerを使うのか | iret.media
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベル Dockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。 Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
最近の Vim プラグインマネージャにおける選択肢 - Qiita
Vim プラグインの歴史 GitHub 以前 (〜2008年) 昔の話です。Vim script で拡張の機能を書いたらそのスクリプトを vim.org にアップして開発者同士で共有したり、ユーザがダウンロードして使っていたようです。いわゆる「プラグイン管理」の始まりなのですが、このときはまだ手動で行われていたようです。 例えば、こんな機能も Vim script で書いた拡張です (autogroup などは考慮してません)。 Vim 7 から Vimball という機能が Vim 本体に同梱されて、それからはこれを利用するユーザもいたようです。vim.org からアーカイブされたスクリプトを持ってきて、:so % したり、気に入ったら runtimepath 以下に置いて自動読み込みしたり。その頃の plugins ディレクトリは混沌としていたようです。ペライチのスクリプトが無造作に転
Composerを速くするために必要だったもの // Speaker Deck
PHPカンファレンス関西2016の基調講演です。
アシアル株式会社 プレスリリース - Webサイトにニコニコ機能を設置できるWebサービス『ニコニコこめんと』を提供開始
2024年05月17日プレスリリース高校生が明日をちょっと良くする「第２回全国商業高校Webアプリコンテスト」の開催が決定！公益財団法人全国商業高等学校協会の後援を受け、全国の商業科目を履修する高校生を対象にした「第２回全国商業高校Webアプリコンテスト」（以下、本コンテスト）を開催いたします。 2024年04月01日お知らせ教育分野の展示会「EDIX東京2024」に出展します大学DXソリューションのご紹介で出展いたします。 【開催日】2024年5月8日（水）～10日（金）【開催場所】東京ビッグサイト【出展場所】教育DXエリア：小間番号2-50 2024年02月05日メディア掲載弊社代表の田中が共著した「Web検定 Webリテラシー」公式テキストの第4版が2月13日発売仕事でWebに関わるすべての人が、適切に業務を遂行できるためのWebリテラシーを身に着けているかを問う資格試験「Web検定
How we keep GitHub fast
EngineeringHow we keep GitHub fastThe most important factor in web application design is responsiveness. And the first step toward responsiveness is speed. But speed within a web application is complicated. Our strategy for keeping… The most important factor in web application design is responsiveness. And the first step toward responsiveness is speed. But speed within a web application is complic
jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 : document
8月17 jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 jsPerf とは JavaScript のコードスニペットに対してベンチマークを計測するサービスです。 一般的に、コードの速度を計測する際は console.time, console.timeEnd を使う事が多いと思いますが、 実行するたびに結果がブレたり、短い処理では正確な比較ができなかったりします。 jsPerf では何度か同じ処理を実行して最終的に一秒間に何回実行できたかをスコアにするので、実行時間が 1ms より小さい処理でも計測できたり、ブレがあっても大体のスコアが分かったりします。 このスコアを計算する部分は Benchmark.js というライブラリで書かれていますので、サーバサイドの JavaScript コードの速度を計測する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
githubからのcloneが遅かったら ~/.ssh/config にコレ書いたら改善する
大規模 JavaScript その設計と実装と現実
Yahoo!はYSlowをオープンソース化した