1 - 40 件 / 61件
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
追記: 2022年1月11日 2:29 JSTにDoS脆弱性としてセキュリティアドバイザーが出されて、悪意あるバージョン(1.4.1や1.4.2)はnpmからunpublishされ、npmの最新は安全なバージョンである1.4.0へと変更されました。 Infinite loop causing Denial of Service in colors · GHSA-5rqg-jm4f-cqx7 · GitHub Advisory Database 2022年01月08日 に colors というnpmパッケージにDoS攻撃のコードが含まれたバージョンが1.4.44-liberty-2として公開されました。 GitHub: https://github.com/Marak/colors.js npm: https://www.npmjs.com/package/colors 問題についてのIssu
このDiff-SVCを簡単に実行できるGoogle ColabのNotebookが1月23日に公開停止となってしまったのです。ですので、前回紹介したやり方での実行はできなくなります。筆者はGoogle Colabからローカルにコピーしているのでこれまで通りに使えますが、新規に手軽にやろうという人への道は一時的にではありますが、閉ざされたことになります。 ▲さんかく筆者はGoogle ColabのNotebookをローカルに保存しているので現在も利用可能 なぜこういうことになったかというと、それは悪質な利用者のせいです。 自分の音源や、権利を所有する、許可をもらっている人物の声であれば問題ないのですが、前回言及したように、よく知られている歌手、セレブ、VOCALOIDなど既存のバーチャルシンガーの音源などを勝手にDiff-SVCでAI音源にし、歌わせたものを例えば「AIアリアナ・グランデが〜を歌った
※(注記)この記事は 2021年12月13日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。 これは、フィヨルドブートキャンプ Advent Calendar 2021(Part 1) 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR(プルリクエスト)を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方 まず、タスクを分解して TODO リストを作ります。 これから作業する内容がイメージで
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. Dismiss alert
プログラムの解説文章をソースコードに混在して表記し、そこから解説記事を生成する、文芸的プログラミングという手法がある。 文芸的プログラミングはソースコードに強く結びついた形でドキュメントを管理することができ、ソースコードの解説を記述するためには良い手法である。ただし、生成される解説記事はあくまでソースコードの記述順に沿ったものであり、プログラマの開発手順、実装順序に沿ったものでは無い。 ソースコードの解説は、そのコードが作られた順番に行われたほうが、プログラマの思考に沿って説明がされるので分かりやすい。そのような発想に基づいて提案された手法が、文芸的コミットだ。 コミットメッセージに、そのコミット内容を説明する文章を記述していくことで、コミットのヒストリーが解説記事になる手法だ。この方式だと、コミットというコードが改変されていく順番で解説ができるので、より分かりやすい内容にできる。 この方
便利なChatGPT いまさら言うまでもないことですが、ChatGPTはめちゃくちゃ便利です。特に日本語の文章、英語の文章、コードの校正に無類の強さを発揮します。私は学生時代は国語が得意だったのですが、ChatGPTは、私の国語力を大幅に凌駕していると思います。というかChatGPTは職業で日本語を書いている人をのぞくと、ほとんどの日本人よりも日本語が上手なんじゃないかと思います。 ChatGPTに校正してもらった日本語の差分が見たい さて、ChatGPTに文章校正をしてもらいましょう。 さきほどの文章をChatGPTを使って校正してもらいます。 違いがわかりますでしょうか? ChatGPTに修正してもらっても、パッと見て、どこが修正されたか、すぐにはわからないケースが多いと思います。日本語は、まだ比較的違いを把握しやすいですが、英文やコードでこれをやるときに、目視でdiffすると見逃しま
こういうツイートを見た。 Scala (or Java) で、jsonのdiffをpatchファイルみたいな感じでわかりやすいテキストで出力してくれるライブラリないかなあ。そしてjacksonに依存してないといいな— Arthur (@Arthur1__) 2024年1月13日 現代のプログラミングではJSONの差分を取ったり、逆にパッチを当てるということがよくある。可能ならそれがPretty Printできると良い。 JSONの差分をScalaで取る方法についていくつか調べてみたのでメモ。 JSONの差分をどう表現する? JSON Patch diffson diffsonでJSON Patchを生成する diffsonでJSON Patchを適用する diffsonでJSON Merge Patchを生成する diffsonでJSON Merge Patchを適用する JSON Pat
github の PR の diff 表示では、行ごとの diff に加えて、行中のどこの部分に差異があるのかを表示してくれます。例えば linux の PR から適当に拾ってきたこのページ などが具体例です。 今、コマンドライン上の diff においても、このように色付けができたら便利だろうと思い、その方法を探しています。 diff に色を付けようとして、見つかったパッケージは、 colordiff というツール で、これを使うと、例えば + の行は緑色、-の行は赤色といったように、行ごとに色を付与してくれますが、最終的に実現したい github 的な diff の再現において、「行中の差異の部分の表示」はやってくれていないな、と思っています。 質問 github の PR ページの diff のように、行中の差異の部分まで色わけしてくれるような diff を、ターミナル上で実現したいの
今日のお題 結局、CDKとTerraformどっちがいいんだろう、という宗教論争 それぞれをある程度触ってきた上での個人的見解を今後の自分のためにまとめます。 長くダラダラした記事なると思いますがご容赦を。 先に結論 CDK、非常にいいんだけれど、ちょっと辛いかも。 ずっと運用することを考えるとTerraformかな。 (2022年07月22日追記) ・・・と思っていたが、使い方によってはCDKの方が良さそうという人になってきました。 その内容は こちら そもそも、CDKとかTerraformってなんだ? 一言で言えば、Infrastructure as Code(IaC)のツールです。 AWSに限らず、GCPやAzureなど様々なクラウドサービスがありますが、これらのクラウドサービス上でコードによりインフラ管理を行う仕組みがIaCです。 これにより、コードさえあれば、どのアカウントにも同じ
最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは(クラウドしかできない)ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ
SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a
デザインとHTMLのズレを検出! Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ ウェブ制作において、デザインとHTML実装の一致はエンジニアとして当然求められるものです。とはいえ、デザインツールとブラウザ画面をにらめっこしながら確認するのも大変です。本記事ではNode.jsで動くヘッドレスブラウザのPuppeteerパペティアーを使ってデザインとのズレを検知するビジュアル校正テストの方法を紹介します。 ウェブ業界ではデザイン制作とHTML制作が分業である場合がほとんどです。ビジュアル校正テストを導入することで、HTML制作の品質向上に役立てられます。デザインとHTML実装が別の会社のようなプロジェクトでは、HTML実装時の品質保証の担保になりますし、デザイナーとフロントエンドエンジニアが近い組織でもコミュニケーション円滑化に役立つでしょう。ICS
preact なんとなく理解した記念ブログです。 もともと React を読むつもりが挫折したので慣れるために preact を読みました。 おかげで仮想 DOM の悲鳴が聞こえるようになりました。 preact とは React の軽量版・サブセットです。 公式では Fast 3kB React alternative with the same modern API. Components & Virtual DOM. と説明されています。 (p)react には、 状態を持て、書き換えも可能である 状態を書き換えるとそれに対応して HTML が書き換わる という特徴があります。 それがどのようにして実現されているのかを見ていきましょう。 前提となる知識 preact のコードリーディングを進める上では VNode というオブジェクトに慣れる必要があります。 これは JSX を仮想 D
ずっとgit logの内容を検索するときに-Sオプションを使っていたが、実は近いオプションに-Gオプションもあり、探したい内容によっては使い分けないとダメということを初めて知った... 詳しくはhttps://git-scm.com/docs/git-logの-Sと-Gのドキュメントを見てほしい。簡単にまとめると -Sは指定した文字列の出現回数が変わるdiffがあるcommitを検索する -Gは指定した正規表現がマッチする文字列がdiffにあるcommitを検索する ドキュメントの事例部分が結構わかりやすくて、以下のようなdiffがあった場合 + return frotz(nitfol, two->ptr, 1, 0); ... - hit = frotz(nitfol, mf2.ptr, 1, 0); -S frotzで検索をかけると、frontsの出現回数は変わってないのでマッチしない
こんにちは、よしこです。 先日、ローカルで見やすくGit差分を表示できるReviewItというOSSを公開しました。 こんなのあったら便利かなと思いつきで作ったツールでしたが、公開直後からとても好評です! まだリリースしてから10日なのですが、GitHub Starに650⭐️が集まったり、既に14件のPRがマージされたりと、盛り上がっていてとても嬉しいです! そんなReviewItなのですが、このたび名称を「difit」に変えることにしました! 経緯 先日、ReviewItと類似の商標をお持ちの会社様より、既存サービス名称との混同を招く懸念などがある旨をご連絡いただきました。(一方的な侵害通告のような形ではなく、柔らかい形でご連絡くださいました) 私としても商標まわりは全然調べられていなかったのと、少しでも外部にご迷惑をおかけする可能性のないすっきりした状態で運用していきたいなと思い、改
Swiss Army knife for developers A desktop app that helps developers in daily tasks Open source and cross-platform DevToys is free, open source and is privacy-focused on Windows, macOS and Linux! No need to use many untruthful websites to do simple tasks with your data. It comes with a set of 30 default offline tools, including: Json to Yaml and Yaml to Json converter Base64 Text & Image converter
English version is available here: https://blog.ryotak.net/post/homebrew-security-incident-en/ (公式インシデント報告はこちらから読むことができます: https://brew.sh/2021/04/21/security-incident-disclosure/) はじめにHomebrewプロジェクトはHackerOne上で脆弱性開示制度(Vulnerability Disclosure Program)を設けており、脆弱性の診断行為が許可されています。 本記事は、当該制度に参加し、Homebrewプロジェクトのスタッフから許可を得た上で実施した脆弱性診断行為について解説したものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 Homebrewに脆弱性を発見した場合は、
比較したいテキストやソースファイルをドラッグ&ドロップするだけで差分表示が可能なマージ機能搭載のMac用diffツール「JuxtaText」がリリースされています。詳細は以下から。 JuxtaTextはソースコードの差分やマージが可能なGitクライアント「JuxtaCode」を開発しているオーストラリア・メルボルンのYori Mihalakopoulosさんが新たに公開したMac用のDiffツールで、比較したい2つのテキストやソースファイルをドラッグ&ドロップするだけで差分を表示し、サイドバーから比較ファイルを素早く変更するこも可能です。 Compare and merge any text with this simple tool. Works intuitively with code, documents or any text-based content. JuxtaText –
プルリク、たいていmainブランチのHEADよりも古いのをフォークしてるけど、そういうなのを手元でレビューする時は git diff -r $(git merge-base HEAD main) とやると、共通祖先とのdiff... https://t.co/UstVHNFGmv
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. Dismiss alert
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 set -e # グローバルな状態を変える操作を行う git merge --no-ff --no-commit $main_branch || true # 結果をチェックしてexit codeを変数に入れる git diff --cached --exit-code --quiet ; code=$? # グローバルな状態をもとに戻す git merge --abort # 上位プロセスに結果を渡す exit $code スクリプト全体には set -e (コマンドが失敗するとシェルスクリプトが即座に終了する)を効
プログラミング初心者向けのTipsです。 まあ、タイトルに書いたとおりなんですが、プログラミング初心者は(というか、プログラマならみんな)git commitする前にdiffを自分でチェックするようにしましょう。 それはなぜか? しょーもないミスを自分で見つけるためです。 しょーもないミスというのは例えば、消し忘れのコメントや、デバッグ用に書き込んだprint文、無駄な空行、おかしなインデント、管理対象外とすべき一時ファイルや隠しファイル等々です。 def create @book = Book.new(book_params) puts @book.title # ほら、デバッグ用のputsが残ってるよ!! if @book.save redirect_to @book, notice: '登録しました' else render :new # インデントが1文字ズレてるよ!! end e
まだ色のないあじさい。 『ギークに銃はいらない』が発売されました。はい〜拍手〜 ギークに銃はいらない 作者:斧田小夜破滅派Amazonみんな買ったかな? うん、買ったよね!でももう一冊あってもいいんじゃないカナ!?!?(よくないだろ Youtubeでスペシャルコンテンツを配信しましたが、こっちではドキュメント管理の話を書こうかなと思います。近いうちにSpaceかなにかをやるかもしれない(まだわからない なぜ「ギークに銃はいらない」はGithubで管理する必要があったか? そもそもGithubってなによ!?って方もままおられるかと思いますが、簡単に言えばクラウドを使ってドキュメント(特にソースコードとか)を便利に保管するツールだよ!ってことを覚えておいてもらえればよいかと思います。厳密にいえばクラウドストレージとバージョン管理システムとそれのホスティングサービスはすべて違うもので、Githu
最近仕事でやっているプロジェクトの TypeScript のバージョンが 3.9。 そこそこ古くなっているのと、 TS は比較的気軽に上げて良くてバージョンアップの恩恵も高いパッケージなので、MTGが早く終わったスキマ時間で最新に上げてみることにした。 結果として tsc の設定を変えつつ $ diff -r ./before/ ./after/ を活用するとかなり楽に移行できたので、やりかたを残しておく。 手順 やり方を考える 一応社内に Renovate Bot が立っていて、かつそこから出ている Pull Request も存在したものの、流石にビルド成果物を比較しないままエイヤで上げるのは躊躇われる。 TypeScript のバージョンを上げて何かが壊れたことは経験としては一度もないが、一方でその経験則は根拠足り得ないので、一応アプリケーションへの影響を調査して、違いがないことを確
本記事は マイグレーションウィーク 6日目の記事です。 💻🖥 5日目 ▶▶ 本記事 🖥💻 初めに ITの変遷と思想の変遷 新たな問題 作ってみた DARS 何と呼ぶ??? コードはこちら 機能紹介の前に 3つの機能 diff conf html バッチ編 課題 ユースケース 最後に 得られた副産物 人間は間違える 初めに こんにちは、上田です。 2024年5月にネットコムに入社したばかりで社内ネタを持ち合わせていないので、作ってみたシリーズに乗っかってみました。 また、今回のテーマはクラウドマイグレーションということなので、オンプレミスからクラウドへITリソースを移行するに伴って人間の考え方がどのように移り変わっていくのか、という観点も交えながら論じていこうと思います。 ITの変遷と思想の変遷 まず、オンプレミスからクラウドへなぜ移行するのかを考えてみます。 クラウドのメリットをい
はじめに 差分というものは見やすいほうがよいですよね git-delta は差分のレイアウト、配色をいい感じに設定してくれるツールです 個人的にアツい言語、Rustで書かれています そんな git-delta を導入してみた記事です 本記事の環境 OS:macOS git version 2.31.1 delta version 0.7.1 構成 install dandavison/delta: A viewer for git and diff output 筆者の環境はmacなのでHomebrewを用います
はじめに これは Go 4 Advent Calendar 2020 8日目の記事です。 Goのテストにおいて、構造体を含めて型の値を比較したいという場合は往々にしてあります。ロジックの結果はなんらかの値として作用することが多いですから、型の値を比較したい、というのは自然です。私は型の値が等価であるかどうか判定するために、go-cmp というライブラリを使うことが多いです。 github.com しかしGoにおける等価性の仕様は決まっていますし、標準ライブラリの reflect パッケージにも DeepEqual という deeply equal, かどうか判定するメソッドがあります。そこで本記事ではなぜわざわざ go-cmp を使っているのかという理由と、go-cmp を使ったときにどのようにして使うか?という go-cmp の使う上でよく使う以下のTipsを提供したいと思います。 Ti
AWS アクセスキーなど、機密情報の git commit を防ぐ secretlint の紹介記事です AWSアクセスキーセキュリティ意識向上委員会って何? 昨今、AWSのアクセスキーを漏洩させてしまうことが原因でアカウントへの侵入を受け、 多額の利用費発生・情報漏洩疑いなど重大なセキュリティ事案が発生するケースが実際に多々起きています。 そこで、アクセスキー運用に関する安全向上の取組みをブログでご紹介する企画をはじめました。 アクセスキーを利用する場合は利用する上でのリスクを正しく理解し、 セキュリティ対策を事前に適用した上で適切にご利用ください。 tl;dr 開発をはじめる前に、次の手順を実行しよう シェルスクリプトの保存 次のシェルスクリプトを ~/.git-template/hooks/pre-commit として保存しよう。 #!/bin/sh FILES=$(git diff
2つのJSON文字列の差分をシンタックスハイライト付きで表示したいケースがありました。 Zennでも同じ差分かつシンタックスハイライトができますね。下のようなコードブロックがそうです。 Zennでは行頭に+や-をつけることで差分としてハイライトされるようになっています。 このようなシンタックスハイライトかつ差分ハイライトを、2つのJSON文字列の差分に対して行いたいと思いました。つまり、差分を表示したい箇所に明示的かつ静的にマークしていくのではなく、2つのテキストから動的に差分を計算して差分ハイライトを表示してくれる機能です。 この記事ではその方法を紹介します。 なお、僕がJSONの差分を表示したかったのでJSONで例を出しますが、好きな言語で、なんならプレーンテキストでも応用可能です。好きなだけdiff表示してください。 先出し結論 jsdiffでJSONの差分トークンを取得し、shik
github.com 背景 仕事でお世話になっているkayac/ecspressoの機能の中にローカルのタスク・サービス定義と現在使われている定義を比較して差分を出力してくれるものがある。 github.com これから加えようとしている差分をプレビューできるだけではなく、たとえばデプロイしようとしているわけでもないのに差分があればローカルの定義が古びていることがわかるのでCIに組み込めると便利。 しかし実際に使おうとすると困る点が見つかった。 たとえばタスク定義にイメージタグを書く際に {{ must_env 'IMAGE_TAG' }} のように環境変数を参照している時に「イメージタグ 以外 に差分がない」ことを確認するのが難しいということ。 理想的には image を無視したJSONの構造を比較して差分が出せると良い。あるいは出力されるdiffをパースして image の差分は無視す
Gitのおすすめエイリアス5選を読んで自分も幾つか晒してみようと思った。 シンプルなコミットログとグラフを表示する git l l = log --graph --decorate --pretty=oneline --abbrev-commit git log を利用するとコミットログからメッセージだったり、誰がコミットしたのか読めるけど殺風景だし、あまりどのブランチがどうマージされたのか理解しずらい。 単純なコミットメッセージとブランチの関係性をパッと知りたい時によく利用している。こんな感じで表示される。 人に優しい変更差分を表示する git dsf dsf = "!f() { [ -z \"$GIT_PREFIX\" ] || cd \"$GIT_PREFIX\" && git diff --color \"$@\" | diff-so-fancy | less --tabs=4 -
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. Dismiss alert
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. Dismiss alert
Goでの依存関係管理を行う際、go mod tidy はよく知られたコマンドです。このコマンドを使うと、モジュールファイル (go.mod や go.sum) に記載されている不要な依存関係を自動的に削除し、最新の状態に保つことができます。しかし、Go 1.19から追加されたgo mod tidy -diffは、その機能にもう一段の便利さを提供します。ここでは、go mod tidy -diffがどのように役立つかを見ていきます。 go mod tidy -diff とは? go mod tidy -diff は、通常のgo mod tidyと似ていますが、モジュールのダウンロードや実際のファイル変更を行わずに、どのような変更が発生するかだけを表示してくれるコマンドです。 通常のgo mod tidyでは、実際に不要なモジュールが削除され、新しい依存関係が追加されることがありますが、-di
diff-notebooks Notebookの差分をArtifactとして生成するdiff-notebooksをGithub Actionsとして公開しました。 github.com 想定する使い方はpull_requestをトリガーとするGithub Actionsへの組み込みです。 実行すると画面のようにNotebookの差分結果がArtifactとして保存されます。 中身はhtmlになっておりブラウザ上で開くとこのように差分を確認できるので、プルリクを受け取ったときのNotebookの差分チェックがGithub上の操作で完結します。 nbdiff-notebooksの中身 このGithub Actionsの中では、nbdiff-webで生成した差分のhtmlをファイルとして出力する自作ツールnbdiff-web-exporterを実行しています。 github.com nbdiff
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く