サクサク読めて、
アプリ限定の機能も多数！
アプリで開く
この記事はGitHubの通知で「未読があるが通知一覧では表示されない」という謎の現象を解決する方法です。 問題の背景 先日、私のGitHubアカウントで以下のような現象が発生しました。 右上の通知アイコンに通知ありのマークがついている Notifications画面のサイドバーには1件の未読通知がある しかし、通知一覧には何も表示されない どうやら通知はycombinattoor/-coというリポジトリに関連しているようです。私には全然心当たりがないのですが、確認しようにもそのリポジトリは既に削除されて存在しません。 しばらくは気にせず使っていました。しかし通知アイコンに未読マークがついたままだと、いちいち通知画面を開かないと未読通知があるのかないのかがわからず非常に邪魔です。 そこで解決方法を調べました。 すると、同じ問題に直面している人がいました。 原因 あるリポジトリに関連する未読
#共有する 開発生産性カンファレンス https://dev-productivity-con.findy-code.io/2025 2025/07/03 Keynote: 開発生産性測定のトレードオフ 「グッドハートの法則」はもっと悲観的に捉えるべきだった はじめに：25年ぶりの来日と生産性への問題意識 25年ぶりに来日しました。かつて『エクストリーム・プログラミング（XP）』の本が日本の書店に平積みされているのを見て、とても嬉しかったことを覚えています。（サインしようとして店員に怪しまれ、逃げたという面白いエピソードもありましたが。） 今日は「開発生産性」について話します。より多く、より早く作れば生産性は向上するのでしょうか？ドイツには「物事を良くしようとして、かえって悪化する」という趣旨の言葉がありますが、まさにそれが生産性の議論で起きています。特にAIの登場は、この問題をさらに悪化
NVIDIA の CUDA は、AI・機械学習分野で広く採用されています。この状況下で登場した ZLUDA は、CUDA アプリケーションをAMDGPU 上で動作させる翻訳レイヤーです。その開発経緯は企業戦略や法的課題が複雑に絡み合っています。 ※ この記事は Claude 4 Opus との対話をまとめたものです。プロジェクトの誕生と技術的成果ZLUDAプロジェクトは 2020 年、ポーランドのエンジニア Andrzej Janik 氏によって開始されました。当初は Intel 在籍中に IntelGPU で CUDA アプリケーションを実行できるようにすることを目指していました。しかし、Intel はそのようなビジネスケースはないとして、このプロジェクトへの公式支援を拒否しました。その結果、2021 年 2 月に ZLUDA のコードはGitHub から削除されることとなり
こんにちは、Android アプリエンジニアの id:kk__777 です。『Inside GigaViewer for Apps』連載8回目は、出版社向けマンガビューワのアプリ版である「GigaViewer for Apps」（以下 GigaApps）のVRTから静的解析まで、Androidのテストについてお話しします。 GigaAppsUnitTestの歴史と現在 概要 アーキテクチャとUnitTestの基本方針 使用しているツール モッキングライブラリ コルーチンディスパッチャの差し替え アサーション（Truth + Expect） テストツールの変遷UIテストの取り組みVRT（Visual Regression Testing）の導入と運用 概要 Compose Preview を使ったVRT GigaApps特有の難しさUIプラグインによるPreviewの難しさ どう対
［速報］「GitHub Copilot Coding Agent」パブリックプレビュー。AIにIssueをアサインすると、解決に向け自律的にプログラミング マイクロソフトは日本時間5月20日未明に開幕したイベント「MicrosoftBuild 2025」で、GitHubのIssueをAIにアサインすると、解決に向けて自律的にプログラミングを行う新機能「GitHub Copilot Coding Agent」をパブリックプレビューとして発表しました。GitHub上のコーディングエージェントは、今年（2025年）2月に「GitHub Copilot Agent Mode」がプレビュー公開されています。これはタスクをVisual Sutido Code上の画面からプロンプトでGitHub Copilotに指示する形式でした。 参考：GitHub Copilot Agent Modeが登場。タ
こんにちは、2025/02からAndroidエンジニアとして入社したid:matsudamperです。GitHub Actionsで外部のactionを使用する時に、どのようにバージョンを指定していますか？ バージョンの指定方法とメリット、デメリット よく使われるactions/checkoutのREADMEのUsageでは以下のように書かれています。これでv4のタグが使用され、最新のv4.x.xに入った改善が使用側のコードの更新なしに使用する事ができます。 - uses: actions/checkout@v4 この書き方のメリットとデメリットは以下です。 メリット v4の間は勝手に更新され、新しいバージョンに書き換える手間が無い デメリット ビルドに再現性が無くなる 不具合が混入した場合、突然動かなくなる。後でRe-Runすると直っている。 actions/checkoutでもこれが
生成AIが爆速で実用的になっている最近、考えていることを記録しておきます。 この記事のすべては2025年2月27日時点での個人の見解です。 最終的なボトルネックは、すべて人間になると思います。生成AIを使えば爆速（人間比）でクソデカPRを量産できます。現状の延長線で考えると、AIはどんどん妥当なPRをつくるようになるでしょう。そうなると、そのPRをレビューする人間がボトルネックになります。人間はそんなに爆速でコードレビューできないからです。結局、AIが妥当なクソデカPRを量産できても、人間のコードレビューが追いつかないので、AIにあえて小さなPRをゆっくりつくってもらうという本末転倒な状況になるのではないか？と思っています。 しかし、そんな既存の固定観念を破壊して、「AIのコードレビューが『LGTM』と判定するならもうそれでいいんじゃないか？」という考え方にアップデートできれば、そのボトル
はじめに本当に悔しいし許せないし、エンジニアとして不甲斐ないです。2025年2月26日深夜にハッキングにあいました。どのように相手と繋がり、どのような手口でハッカーに資産を抜かれたか、コードベースで全てお伝えします。今後同じ被害に遭う方が少しでも減ることがあればこんな嬉しいことはないです。 コード解説、さらに対策案も書いていきます。もし他に良い対策案などあればコメントでご教示ください。ハッカーとのやりとりの流れハッカーとは Linkedin でブロックチェーンを使ったプロジェクトを手伝ってくれないかという連絡がりそこからやりとりが始まりました。そして移行の大まかな流れは下記のような感じです。 Linkedinでプロジェクトを手伝ってほしいと言う内容でDMがくるGithubリポを見て実装できそうか確認してほしいと言われる 自分のGithubアカウントを共有してプライベートリポジトリに
はじめにGitHub Actions (GHA)、便利ですよね。 便利なんですが、たまに「え、そんな仕様だっけ？」みたいなワナに遭遇します。そして毎回忘れてワナにハマってしまいます。 今後そんなワナにハマって時間を無駄にしないよう、ワナ仕様について網羅していきます。 対象読者GitHub Actions を使い倒したい方 割と大きめな規模のGitHub Actions を構成している方 初級編 run を複数行で書くときの記法 GHA というかYAML の記法です。いきなり GHA から外れてすみません 💦 が、よく忘れるので覚えておくと助かります。以下の 2 種類を覚えておけば、ほとんどの場合事足りると思います。 | は改行を改行として実行する
TOPフォーカス論文を書けなかった物理学者がOSS文化に救われた理由。元・京大助教がエンジニアになるまで【フォーカス】 レッドハット株式会社 シニアソフトウェアエンジニア 渡辺 優 1984年生まれ。2012年8月から2019年7月まで京都大学基礎物理学研究所で助教を務め、量子情報理論の研究に従事。2015年にGitHub上でsystemdへのPull Requestを送ったのをきっかけに、2016年から本格的にコミッターとして活躍するようになる。2020年5月から現職。systemdへの累計コントリビューション数は、レナート・ポッターリング氏に次いで世界で最も多い。 XGitHub趣味でsystemdにコミットしていたら、いつの間にか給料がもらえるようになった――。 自らの仕事について、このようにX上でつづっているのは、Red Hat社のシニアソフトウェアエンジニア・渡辺優さん。業務
こんにちは丸山@h13i32maruです。 私は20年前の高専3年ごろに、当時ハマっていたオンラインゲームのツールをHSP（Hot Soup Processorって今も開発続いててすごい！）で作って、自分のホームページに公開していました。ユーザは自分以外だと2〜3人しかいませんでしたが、すごく楽しかった記憶があります。これが私の個人開発の原体験です。それから現在に至るまで個人開発を続けています。 ここ数年で特に気に入っているのは、Jasper（GitHub用のIssue/PRリーダー）やTrickle（自分のアクティビティを書き留めるサービス）です。今は開発していませんがOSSとしてESDoc（JSのドキュメンテーションツール）というものも作っていました。最近だとMTG Playbookというマジック・ザ・ギャザリング用のオールインワンアプリを積極的に開発しています。この20年で大小合わせ
長年の運用で「Gemfileはこう運用すると上手くいった」という知見が蓄積されてきたので、ここに書き出してみておく。Bundler/OrderedGemsを有効化するRuboCopのBundler/OrderedGems Copを有効化する。 悪い例: gem 'puma' gem 'jbuilder' 良い例: gem 'jbuilder' gem 'puma' セクションを分けない 基本的に、独自の判断で空行を入れてセクションを分けたりしない。 ここで言うセクションとは「空行で区切られた１つのまとまり」のことである。Bundler/OrderedGems は、このまとまりの中で辞書順であることを要求する。 悪い例: gem 'aws-sdk-rails' gem 'aws-sdk-s3' gem 'graphql' gem 'graphql-batch' 良い例: gem 'aw
本記事のテーマはGitHub Actionsです。個人的に「もっと早く知りたかった！」と考えているグッドプラクティスを、厳選してお届けします。想定読者は次のとおりです。 普段GitHub Actionsを雰囲気で運用している人GitHub Actionsをコピペや生成AIで乗り切っている人 他者が書いたコードの意味をより深く理解したい人本記事でGitHub Actionsの基本は説明しません。グッドプラクティスを含めて基礎から学びたい人は、拙著『GitHub CI/CD実践ガイド』を読んでみてください。GitHub Actionsの基本構文から運用のコツまで、網羅的に解説しています。さて書籍紹介はこれぐらいにして、さっそく本題へ進みます。GitHub Actionsの設計指針GitHub ActionsはCI/CDや各種自動化で役立つ、汎用的なワークフローエンジンです。一般的に長期
GitHub Actions で CI している皆様、こんにちは。GitHub Actions 便利ですよね。使わない日がないというくらい毎日お世話になっています。 さて、CI といえば良く問題になるのが実行時間。 長い待ち時間は開発効率を下げますし、プライベートリポジトリだと Runner の費用も嵩んでしまいます。 時間を短縮する方法は色々ありますが、一手目によく行われるのが依存パッケージのキャッシュじゃないかなと思います。 例えばGo で開発していると、依存パッケージは ~/go/pkg/mod にダウンロードして保存されます。 これを CI 実行のたびにダウンロードしてコンパイルするのは時間とお金の無駄というものです。 幸い、GitHub Actions には CI の実行間でこういった依存パッケージを保存して再利用できるキャッシュ機能があります。 詳しくは以下のドキュメントを
技術記事は 個人ブログ へお引越ししました。 興味を持ってくださった方はZennではなくこちらをご購読いただければと思います🙏Dockerは公式にDockerfileのベストプラクティスを表明しています。 が、このベストプラクティスに沿っているかどうか？を人間がいちいちレビューしていくのは正直しんどい、というか現実的ではない… そこで「せや！静的解析したろ！」という時に便利なのがhadolintというライブラリです。 使ってみる 今回はVSCode拡張機能とGHAのCI時に静的解析してもらいたいと思います。 今回はちょうどメンテナンスしていない自分のリポジトリがあるので、これに対して静的解析をかけていきます。 まずはVSCode拡張機能で利用するための下準備として、hadolint本体をOSにインストールします。Macの場合はこちら。docker/php/Dockerfile:8
Googleは、オープンソースのプロジェクトにおいてメンテナが行っているさまざまな作業を、生成AIなどによる支援で軽減する「Project Oscar」を、インドのバンガロールで行われたイベント「Google I/O Connect Bengaluru 2024」で発表しました。 オープンソースプロジェクトには、Issueやプルリクエストやフォーラムでの質問などがコントリビュータから寄せられるため、メンテナはこれらに目を通して、不足している情報があれば指摘し、関連する情報があれば補足し、質問に返答するなど、コードを書く以外のさまざまな作業をしなくてはなりません。プロジェクトが大きくなればなるほど、こうした作業の負荷は大きくなっていきます。 これらの作業を軽減し、コードを書くという最も楽しい作業に多くの時間をメンテナが割けるように支援するのが「Project Oscar」だと説明されていま
やねうら王関連のドキュメントは、やねうら王のGitHubのWikiに整理して公開している。 やねうら王Wiki https://github.com/yaneurao/YaneuraOu/wiki ところが、このGitHubのWikiは、☆500以上獲得するまでGoogleにインデックスされない(Googleの検索結果に出てこない)のだ。 やねうら王のGitHubは8年目であるし、現在、GitHub Sponsors +FANBOXで1ヶ月20万円程度獲得している程度の規模感なのだが、昨日やっと☆500になったばかりである。(めでたい。やっとGoogleの検索結果に出てくる！) そんなわけで、平均的な個人のプロジェクトはGitHubで☆500なんでまず獲得できないので、(Google検索で引っかかって欲しいなら)GitHubのWikiを使うなというのが私からのアドバイスである。 その代わ
海外のセキュリティ企業「Phylum」はトロイの木馬化された「jQuery」がnpmやGitHub、jsDelivr のCDNホストで拡散している事を指摘しました。 jQueryを悪用したサプライチェーン攻撃の概要 Phylumは 2024 年 5 月 26 日以来、トロイの木馬化された jQuery のバージョンを悪用する執拗なサプライ チェーン攻撃者を監視しており、最初に npm でこのjQuery を悪用する亜種を発見しました。 そこでは、1 か月にわたって数十のパッケージで侵害されたバージョンが公開されていました。 調査の結果、GitHubや、jsDelivr の CDNホスト リソースでも、トロイの木馬化された jQuery のインスタンスを発見しました。 なお、今回解説されている内容は正規のjQueryへ、トロイの木馬が紛れ込んでいるのではなく、 悪意のあるユーザーがnpmや
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
