サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
生成AIが爆速で実用的になっている最近、考えていることを記録しておきます。 この記事のすべては2025年2月27日時点での個人の見解です。 最終的なボトルネックは、すべて人間になると思います。生成AIを使えば爆速（人間比）でクソデカPRを量産できます。現状の延長線で考えると、AIはどんどん妥当なPRをつくるようになるでしょう。そうなると、そのPRをレビューする人間がボトルネックになります。人間はそんなに爆速でコードレビューできないからです。結局、AIが妥当なクソデカPRを量産できても、人間のコードレビューが追いつかないので、AIにあえて小さなPRをゆっくりつくってもらうという本末転倒な状況になるのではないか？と思っています。 しかし、そんな既存の固定観念を破壊して、「AIのコードレビューが『LGTM』と判定するならもうそれでいいんじゃないか？」という考え方にアップデートできれば、そのボトル
Rust +Docker +GitHub Actions = めちゃ遅い 以前、GitHub Actions 上のRust ビルドを高速化する記事を書いたけど、 今回はKubernetes 環境にスムーズに移行できるようDocker イメージ化するという要件も加わったことで、改めて試行錯誤する必要が出てきた。 それぞれに対するビルド速度の最適化は存在しているものの、３つ (Rust,Docker,GitHub Actions) すべてを満たすとなるとコピペで終わるほど情報がまとまってないし、見つけた Tips もちょっと古かったり、これというものは見つけられなかった。 公式ドキュメントを見ると正当進化していて新しいオプションが生えていたりしたので、賞味期限は短そうだけど、自分の試行錯誤の結果を残しておこうと思う。 成果としては 12 分 22 秒かかっていたRust アプリ
はじめに 最初に重要事項を発表します。私 Shougo はテキストエディタプラグイン開発に力を入 れていくために、github sponsors を有効にすることにしました。 これは大きな方針転換となります。これまでの私はオープンソース活動に対する寄付を 受け付けていなかったからです。なぜかというと、もっと自由にオープンソース活動を やりたかった、寄付を受けるとそこに責任が発生するのではないか、テキストエディタ との関係性が変わってしまうのではないかという懸念があったからです。 しかし、私もプラグイン開発を始めてからはやくも 10 年以上たちました。 昔とは完全に状況が変わってきています。プラグインやそれに使われる技術も複雑化、 高度化しかなり開発期間をかけないといけなくなりました。プラグイン開発に時間を費 すには資金が多いにこしたことはありません。 モチベーションの確保も課題です。通常の
GitHub は、毎日 5600 万人以上の開発者にサービスを提供し、2 億以上のリポジトリをホストしています。これらのリポジトリのごく一部を除いて、世界中の顧客に驚くべきパフォーマンスでサービスを提供しています。GitHub のような大規模なシステムでは、コードとアーキテクチャのずれというのは限界に達したときに初めて見つかるものです。例えば、何千人もの開発者が毎日同じリポジトリを更新するといったケースです。GitHub は、大規模なモノリポを使用する一部の顧客から、プッシュ操作が失敗するといったパフォーマンスの問題が発生しているというフィードバックを受けました。 そして、それはGitHub においても発生していました。 github/github はGitHub のモノリポですが、私達自身も時々プッシュに失敗することがありました。 調査を開始するにあたり、私たちは社内のチームや顧客
Git のリポジトリが大きくなると、新しい開発者がクローンして作業を始めるのが難しくなります。Git は 分散 バージョン管理システムとして設計されています。つまり、リポジトリとのやりとりを管理する中央サーバーに接続しなくても、自分のマシンで作業ができるということです。これが完全に実現できるのは、すべての到達可能なデータがローカルリポジトリにある場合だけです。 もっと良い方法があったらどうでしょうか？Git の全履歴にあるすべてのファイルのすべてのバージョンをダウンロードしなくても、リポジトリで作業を始めることができたらどうでしょうか？Git の パーシャルクローンやシャロークローンという機能は、こういったケースで役立ちます。その一方でこれらの機能にはトレードオフもあります。これらの選択肢は Git の分散という性質によってもたらされる可能性を少なくとも一つは壊してしまうため、こうしたトレ
しっかり調査してないですが、こういったCIサービスがほぼ存在しない時期にほぼほぼ最初に登場して、一時期明らかにデファクトスタンダードだったと思うので、昔からOSS活動している人ほど、とても多く利用してお世話になっていたと思うので、そういう人であればあるほど、この状況は、怒りではなく、悲しいというか残念というか、辛いと思うんですよね・・・。 今までありがとう・・・。 長年Travis CI使ってきたので、GitHub Actionsによって潰される(のかどうなるのかわからないけど)、の可愛そう、という気持ちが若干あるけど、とはいえ、こういうのよくある話な気はするな…— Kenji Yoshida (@xuwei_k) 2020年10月7日 買収されて方針変わったのかなと感じるところもありますし、OSSプロジェクトが無料で使っていても会社としては辛いのではという気もするので今までの感謝の気持ち
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 に
2017年にもうコンテナの未来・一つのカタチはもう確定したと言え、今更感があるものの、改めてDockerとコンテナについて。 今更こんなことを書くのは、情報が溢れてくる今こそ、正しく理解し、正しい順序で学習することが重要だと切に思うから。 内容についてのお断り How Toはかきません あくまでも2018年時点の私見 目新しい情報はない、2016年頃に書けたレベルDockerをこう使えとか、こうするのがいいとかの話ではなく、コンテナとDockerに関して大きな視点で現時点で私の考えを書きます。また、私自身はかなりのコンテナ推進派です。Dockerをよくわかっている人には意味のない記事となります。 コンテナ(Docker)のメリット 何故コンテナがいいのか、コンテナをある程度の学習コストを払ってでもやる理由 コンテナとDocker コンテナ技術はDockerが生まれる前から存在する技術で
Vim プラグインの歴史GitHub 以前 (〜2008年) 昔の話です。Vim script で拡張の機能を書いたらそのスクリプトをvim.org にアップして開発者同士で共有したり、ユーザがダウンロードして使っていたようです。いわゆる「プラグイン管理」の始まりなのですが、このときはまだ手動で行われていたようです。 例えば、こんな機能もVim script で書いた拡張です (autogroup などは考慮してません)。Vim 7 からVimball という機能がVim本体に同梱されて、それからはこれを利用するユーザもいたようです。vim.org からアーカイブされたスクリプトを持ってきて、:so % したり、気に入ったら runtimepath 以下に置いて自動読み込みしたり。その頃の plugins ディレクトリは混沌としていたようです。ペライチのスクリプトが無造作に転
PHPカンファレンス関西2016の基調講演です。
2025年08月14日プレスリリースプライム・ストラテジー株式会社との戦略的且つ包括的業務連携に関するお知らせ ～Web/アプリ開発力の強化による売り上げ拡大を目指して～プライム・ストラテジー株式会社と、Webシステム開発・アプリ開発、MAGATAMA Stack、KUSANAGI及び関連ソリューションの協業に関して、戦略的且つ包括連携を推進するため両社で協議に入ることを決議いたしましたのでお知らせいたします。 2025年07月02日お知らせ書籍「すぐわかる！ ぷよぷよプログラミング SEGA公式ガイドブック」2025年8月8日発売弊社のプログラミング教育「Monaca Education」を開発環境とした「ぷよぷよプログラミング」の書籍が技術評論社様から出版されることになりました。 2025年05月22日お知らせ「PHP Conference Japan 2025」開催を応援毎年開催され
AI & MLLearn about artificial intelligence andmachine learning across theGitHub ecosystem and the wider industry. GenerativeAILearn how tobuild with generativeAI.GitHub CopilotChange how you work withGitHub Copilot. LLMsEverything developers need to know about LLMs.Machine learningMachine learning tips, tricks, and best practices. HowAI code generation worksExplore the capabilities and be
8月17 jsPerf, JSPerfView を使った、JavaScript コードのベンチマーク計測とブログなどで計測結果を利用する方法 jsPerf とはJavaScript のコードスニペットに対してベンチマークを計測するサービスです。 一般的に、コードの速度を計測する際は console.time, console.timeEnd を使う事が多いと思いますが、 実行するたびに結果がブレたり、短い処理では正確な比較ができなかったりします。 jsPerf では何度か同じ処理を実行して最終的に一秒間に何回実行できたかをスコアにするので、実行時間が 1ms より小さい処理でも計測できたり、ブレがあっても大体のスコアが分かったりします。 このスコアを計算する部分は Benchmark.js というライブラリで書かれていますので、サーバサイドのJavaScript コードの速度を計測する
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
1リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
