並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 81件

新着順 人気順

diffの検索結果1 - 40 件 / 81件

diffに関するエントリは81件あります。 gitgithubツール などが関連タグです。 人気エントリには 『自由民主党: 日本国憲法改正草案-2012-04-27 by atsuya · Pull Request #1 · atsuya/constitution-of-japan』などがあります。
  • 自由民主党: 日本国憲法改正草案-2012-04-27 by atsuya · Pull Request #1 · atsuya/constitution-of-japan

    Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community. Pick a username Email Address Password Sign up for GitHub By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails. Already on GitHub? Sign in to your account

      自由民主党: 日本国憲法改正草案-2012-04-27 by atsuya · Pull Request #1 · atsuya/constitution-of-japan
    • 首相の被爆地あいさつが広島・長崎で酷似するのは仕方ないのか約25年分調べた|松本健太郎

      菅義偉官房長官は11日の記者会見で、広島と長崎の平和式典での安倍晋三首相のあいさつが酷似していたことに関し、やむを得ないとの認識を示した。「哀悼の気持ちや唯一の戦争被爆国としての立場を申し上げるのは両式典でどうしても同じような内容になる」と述べた。そんなアホな話あるかい。 と思いつつ、安倍首相に対する心理的嫌悪感だけで拒否反応を示すのは良くないと考えて、過去遡れる分だけ遡って広島・長崎の「被爆地あいさつ」文を比較してみました。 分析手法恣意的に判断するのは良くないと思い、なるべくロジカルに広島・長崎のあいさつ文のdiffを取りました。diff自体はこちらのWEBページで差分を見ています。 例えば2020年あいさつ文は以下のように表示されました。 左側が広島、右側が長崎です。 青いマーカー線は、広島(長崎)あいさつが長崎(広島)あいさつと比べて登場しなかった文章です。なるほど、2020年の安

        首相の被爆地あいさつが広島・長崎で酷似するのは仕方ないのか約25年分調べた|松本健太郎
      • コミットはスナップショットであり差分ではない

        Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと

          コミットはスナップショットであり差分ではない
        • colorsなどのnpmパッケージに悪意あるコードが含まれている問題について

          追記: 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

            colorsなどのnpmパッケージに悪意あるコードが含まれている問題について
          • バージョン管理ツールのGitでよく使用するコマンドを1ページにまとめた便利なチートシート -GitSheet

            GitSheet Gitでよく使用するコマンドをまとめたチートシートは、こちら。 サイトでは「Copy」ボタンをクリックすると、コマンドがコピーできます。 GitSheet チートシートの作成者に許諾を頂いたので、各説明を意訳しました。 Gitのブランチ操作 git branch すべてのローカルブランチを一覧表示します。 git branch -a リモートおよびローカルブランチを一覧表示します。 git checkout -b branch_name ローカルブランチを作成し、切り替えます。 git checkout branch_name 既存のブランチに切り替えます。 git push origin branch_name ブランチをリモートにプッシュします。 git branch -m new_name 現在のブランチの名前を変更します。 git branch -d branch

              バージョン管理ツールのGitでよく使用するコマンドを1ページにまとめた便利なチートシート -GitSheet
            • 一周回って、人間が読み書きする設定ファイルはJSONが良いと思った | フューチャー技術ブログ

              最近GoでCLIツールを作っていますが、JSONが良いとなんとなく思っています。 続編も公開しました(追記:2019年10月2日)。 CUEを試して見る 設定ファイルフォーマット近年、設定ファイルを書くプレーンテキストのフォーマットとしては次のようなものが多いかと思われます。 XML 多くのプログラミング言語において標準ライブラリで扱える(ただしNode.jsにはない) XMLスキーマ、XSLTなどの周辺ツールも揃っているが、記述が冗長になりがちで、敬遠されがち。 ini QtやPythonの標準ライブラリで扱える 深い階層や配列を扱うのが苦手 JSON ほとんどのプログラミング言語で標準ライブラリに入っている 特にフロントエンドのJavaScriptでは追加のライブラリを利用する必要がなく、速度も早く、gzipすればファイルサイズもかなり小さくなる。T 閉じかっこが必要、コメントがつけら

                一周回って、人間が読み書きする設定ファイルはJSONが良いと思った | フューチャー技術ブログ
              • 破壊的でヤバいAI歌声合成「Diff-SVC」がGoogle Colabでの公開停止。一部ユーザーがセレブや商用音源を勝手に利用で自主制限(CloseBox) | テクノエッジ TechnoEdge

                このDiff-SVCを簡単に実行できるGoogle ColabのNotebookが1月23日に公開停止となってしまったのです。ですので、前回紹介したやり方での実行はできなくなります。筆者はGoogle Colabからローカルにコピーしているのでこれまで通りに使えますが、新規に手軽にやろうという人への道は一時的にではありますが、閉ざされたことになります。 ▲筆者はGoogle ColabのNotebookをローカルに保存しているので現在も利用可能 なぜこういうことになったかというと、それは悪質な利用者のせいです。 自分の音源や、権利を所有する、許可をもらっている人物の声であれば問題ないのですが、前回言及したように、よく知られている歌手、セレブ、VOCALOIDなど既存のバーチャルシンガーの音源などを勝手にDiff-SVCでAI音源にし、歌わせたものを例えば「AIアリアナ・グランデが~を歌った

                  破壊的でヤバいAI歌声合成「Diff-SVC」がGoogle Colabでの公開停止。一部ユーザーがセレブや商用音源を勝手に利用で自主制限(CloseBox) | テクノエッジ TechnoEdge
                • コードより先にコミットメッセージを書く

                  これは、フィヨルドブートキャンプ Advent Calendar 2021(Part 1) 13日目の記事です。 未経験からフィヨルドブートキャンプでプログラミングを勉強し、2021年3月から Tebiki 社でエンジニアとして働いている masuyama13 です。 入社当初、PR(プルリクエスト)を作成する際にコミットの整理に毎回かなり時間がかかるのが悩みでした。試行錯誤の結果、この悩みを解消することができたので紹介します。 それが、コードより先にコミットメッセージを書くという方法です。 コミットメッセージを先に書くやり方まず、タスクを分解して TODO リストを作ります。これから作業する内容がイメージできたら、コミットメッセージを一つ考えます。エディタなどにコミットメッセージを入力します。コミットメッセージが書けたら、それを常に意識しながらコーディングを進めます。作業中にコミットメッ

                    コードより先にコミットメッセージを書く
                  • GitHub - banga/git-split-diffs: Syntax highlighted side-by-side diffs in your terminal

                    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

                      GitHub - banga/git-split-diffs: Syntax highlighted side-by-side diffs in your terminal
                    • データベースのドキュメント管理を自動化した話 - estie inside blog

                      こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie(オフィス探しサービス)とestie pro(不動産事業者向けデータプラットフォーム)の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する

                        データベースのドキュメント管理を自動化した話 - estie inside blog
                      • 文芸的diffでソースコードを解説する - ABAの日誌

                        プログラムの解説文章をソースコードに混在して表記し、そこから解説記事を生成する、文芸的プログラミングという手法がある。 文芸的プログラミングはソースコードに強く結びついた形でドキュメントを管理することができ、ソースコードの解説を記述するためには良い手法である。ただし、生成される解説記事はあくまでソースコードの記述順に沿ったものであり、プログラマの開発手順、実装順序に沿ったものでは無い。 ソースコードの解説は、そのコードが作られた順番に行われたほうが、プログラマの思考に沿って説明がされるので分かりやすい。そのような発想に基づいて提案された手法が、文芸的コミットだ。 コミットメッセージに、そのコミット内容を説明する文章を記述していくことで、コミットのヒストリーが解説記事になる手法だ。この方式だと、コミットというコードが改変されていく順番で解説ができるので、より分かりやすい内容にできる。 この方

                          文芸的diffでソースコードを解説する - ABAの日誌
                        • ChatGPTの時代になって、GUIで差分を取れるmeldが便利な件 - Qiita

                          便利なChatGPT いまさら言うまでもないことですが、ChatGPTはめちゃくちゃ便利です。特に日本語の文章、英語の文章、コードの校正に無類の強さを発揮します。私は学生時代は国語が得意だったのですが、ChatGPTは、私の国語力を大幅に凌駕していると思います。というかChatGPTは職業で日本語を書いている人をのぞくと、ほとんどの日本人よりも日本語が上手なんじゃないかと思います。 ChatGPTに校正してもらった日本語の差分が見たい さて、ChatGPTに文章校正をしてもらいましょう。 さきほどの文章をChatGPTを使って校正してもらいます。 違いがわかりますでしょうか? ChatGPTに修正してもらっても、パッと見て、どこが修正されたか、すぐにはわからないケースが多いと思います。日本語は、まだ比較的違いを把握しやすいですが、英文やコードでこれをやるときに、目視でdiffすると見逃しま

                            ChatGPTの時代になって、GUIで差分を取れるmeldが便利な件 - Qiita
                          • gitのdiff-highlightを使い始めた - りんごとバナナとエンジニア

                            git log -p や git diff などで差分を見るとき、行単位での追加/削除は表示されるが、行の中のどこが変わったのかは表示してくれない。例えば行の中の一単語を書き換えただけで、しかもその行が長い場合、どこに差分があるのか目で探すのが結構大変だった。 しかし先日、 diff-highlight という便利なモジュールが提供されていることを知り、早速導入してみた。 diff-highlightとは github.com gitコマンドの、行単位での差分を探す動作のポストプロセスとして実行され、同じ行の中の差分をハイライトしてくれる。 例えば、行の一部分だけ変えたときの git diff は、今までこんな感じだった。 それがこうなる。差分がわかりやすい。 diff-highlightの設定 この機能は gitコマンドに同梱されているため、インストールは不要。設定作業のみで使える。 ま

                              gitのdiff-highlightを使い始めた - りんごとバナナとエンジニア
                            • ターミナルの diff で、github のように、行の中で具体的に差分がある部分に色付けをしたい

                              github の PR の diff 表示では、行ごとの diff に加えて、行中のどこの部分に差異があるのかを表示してくれます。例えば linux の PR から適当に拾ってきたこのページ などが具体例です。 今、コマンドライン上の diff においても、このように色付けができたら便利だろうと思い、その方法を探しています。 diff に色を付けようとして、見つかったパッケージは、 colordiff というツール で、これを使うと、例えば + の行は緑色、-の行は赤色といったように、行ごとに色を付与してくれますが、最終的に実現したい github 的な diff の再現において、「行中の差異の部分の表示」はやってくれていないな、と思っています。 質問 github の PR ページの diff のように、行中の差異の部分まで色わけしてくれるような diff を、ターミナル上で実現したいの

                                ターミナルの diff で、github のように、行の中で具体的に差分がある部分に色付けをしたい
                              • JSONの差分を取ってJSON Patchを得るにはdiffsonがおすすめ - Lambdaカクテル

                                こういうツイートを見た。 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

                                  JSONの差分を取ってJSON Patchを得るにはdiffsonがおすすめ - Lambdaカクテル
                                • AWS CDKとTerraformどちらを使うのが良いのか? - Qiita

                                  今日のお題 結局、CDKとTerraformどっちがいいんだろう、という宗教論争 それぞれをある程度触ってきた上での個人的見解を今後の自分のためにまとめます。 長くダラダラした記事なると思いますがご容赦を。 先に結論 CDK、非常にいいんだけれど、ちょっと辛いかも。 ずっと運用することを考えるとTerraformかな。 (2022/07/22追記) ・・・と思っていたが、使い方によってはCDKの方が良さそうという人になってきました。 その内容は こちら そもそも、CDKとかTerraformってなんだ? 一言で言えば、Infrastructure as Code(IaC)のツールです。 AWSに限らず、GCPやAzureなど様々なクラウドサービスがありますが、これらのクラウドサービス上でコードによりインフラ管理を行う仕組みがIaCです。 これにより、コードさえあれば、どのアカウントにも同じ

                                    AWS CDKとTerraformどちらを使うのが良いのか? - Qiita
                                  • 個人的によく使うGitエイリアス、zshキーバインド - 本日も乙

                                    最近、リモートワークということもあり、ペアプロというかAWS、GCPなどの操作をする際に一緒に画面を見ながら作業する機会が多いです。若手の同僚がターミナルソフトを起動してコマンドを実行するのですが、傍から見ているとエイリアスなりキーバインドなりを使えば効率的に操作できるのにと思うことがあります。 最近はGUIで操作することが多いのでターミナルソフトでコマンド操作することがあまりないのかもしれませんが、私は少し前までは(クラウドしかできない)ITインフラエンジニアをやっており、プログラミングよりもコマンド操作するのが圧倒的に多かったため、ちょっとしたことならGUIよりもターミナルで操作することが多いです。Windowsを使っていますが WSL2 + Ubuntu 20.04 LTSで開発環境を整えているため、操作に不自由はほとんどしません。 この手のエイリアスやzshなどのオススメ設定はググ

                                      個人的によく使うGitエイリアス、zshキーバインド - 本日も乙
                                    • Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog

                                      SREチームの橋本です。今回はステージング環境の運用でありがちな本番との差分に対処する試みを紹介します。 背景 ステージング環境について、例えばIT用語辞典では ステージング環境とは、情報システムやソフトウェアの開発の最終段階で検証用に用意される、実際の運用環境と変わらない環境のこと。 と説明しています。検証用ですから、インフラ面で言っても本番環境となるべく一致した構成であってほしいということになります。 しかし実際にはさまざまな経緯(ステージング環境を後から立てたり!)から、たとえTerraform管理していたとしても差異が発生してしまうことがあります。 こうしたとき、その差異を検出する一つの方法としてはTerraformの.tfファイルを比較することですが、これにもいろいろな書き方がありえます。 例えばaws_db_proxy_endpointはterraform-provider-a

                                        Terraform管理されたステージング環境・本番環境の差異を検出したくて頑張っている話 - KAYAC engineers' blog
                                      • デザインとHTMLのズレを検出! Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ - ICS MEDIA

                                        デザインとHTMLのズレを検出! Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ ウェブ制作において、デザインとHTML実装の一致はエンジニアとして当然求められるものです。とはいえ、デザインツールとブラウザ画面をにらめっこしながら確認するのも大変です。本記事ではNode.jsで動くヘッドレスブラウザのPuppeteerパペティアーを使ってデザインとのズレを検知するビジュアル校正テストの方法を紹介します。 ウェブ業界ではデザイン制作とHTML制作が分業である場合がほとんどです。ビジュアル校正テストを導入することで、HTML制作の品質向上に役立てられます。デザインとHTML実装が別の会社のようなプロジェクトでは、HTML実装時の品質保証の担保になりますし、デザイナーとフロントエンドエンジニアが近い組織でもコミュニケーション円滑化に役立つでしょう。ICS

                                          デザインとHTMLのズレを検出! Node.jsとPuppeteer活用のビジュアル校正テストで実装時のケアレスミスを防ぐ - ICS MEDIA
                                        • Difftastic, a structural diff tool that understands syntax

                                          Difftastic is a CLI diff tool that compares files based on their syntax, not line-by-line. Difftastic produces accurate diffs that are easier for humans to read.

                                          • preact コードリーディング

                                            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

                                              preact コードリーディング
                                            • 人生を豊かにする文字列diff入門 | フューチャー技術ブログ

                                              春の入門祭りの8日目です。 文字列の新旧の違いを表現する時によくdiffをとるとか言いますよね。そこで実行されるのが差分アルゴリズムです。差分のアルゴリズムって結構知れば知るほど難しいやつです。「より良い差分」という基準が、状況によって変わるからです。ヒューリスティックなやつです。例えば、HTMLの説明の文章を書いていたとします。タイトルをテーブルに書き換えてみたとします。 どちらも間違ってはおらず、この差分を元にパッチを当てたりも可能です。ただ、読んだ時の読みやすさが違います。 これはもちろん前者と答える人の方が多いでしょう。だって、タグという意味の塊が維持されていますからね。 これは究極的にはわかりやすいdiffというのは「意味」を理解しないと作れないということを意味します。これがdiffは簡単なようで難しいと書いた理由です。もちろん、ほどほどの工数で、ほどほどの見た目のdiffも作成

                                                人生を豊かにする文字列diff入門 | フューチャー技術ブログ
                                              • git logの内容を検索する-Sと-Gの違い - $shibayu36->blog;

                                                ずっと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 logの内容を検索する-Sと-Gの違い - $shibayu36->blog;
                                                • GitHub - dandavison/delta: A syntax-highlighting pager for git, diff, and grep output

                                                  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

                                                    GitHub - dandavison/delta: A syntax-highlighting pager for git, diff, and grep output
                                                  • csvdiff - CSVに特化した差分ビューワー

                                                    MOONGIFTはオープンソース・ソフトウェアを紹介するブログです。2021年07月16日で更新停止しました CSVファイルは今なおシステムの中で現役ばりばりに利用されています。様々なシステムから出力されるCSVファイルに対して、差分を確認したいと考えることはないでしょうか。通常の差分表示では、CSVのようなフォーマットではうまく表示できないかも知れません。 そこで使ってみたいのがcsvdiffです。CSVに特化した差分表示コマンドです。 csvdiffの使い方 普通にコマンドを打ったところです。追加された行、修正された行が確認できます。 $ csvdiff asof.csv asof2.csv # Additions (1) + 20160525 13:15:00.075,AAPL,98.65,10,NASDAQ,98.55,98.56 # Modifications (19) - 20

                                                      csvdiff - CSVに特化した差分ビューワー
                                                    • HomebrewのCaskリポジトリを介した任意コード実行

                                                      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に脆弱性を発見した場合は、

                                                        HomebrewのCaskリポジトリを介した任意コード実行
                                                      • A Swiss Army knife for developers.

                                                        Free, open source and offline DevToys works entirely offline! No need to use many untruthful websites to do simple tasks with your data. 28+ tools are available, including: Json to Yaml and Yaml to Json converter Base64 Text & Image converter JWT encoder and decoder Text comparer Hash generator and more are coming! See the whole list here. Go faster with Smart Detection DevToys can automatically d

                                                          A Swiss Army knife for developers.
                                                        • 20,000+行のmanifestをリファクタリングして分かったKustomizeの美しきアーキテクチャと拡張性 / Kustomize deep dive

                                                          #CNDT2021 で Kustomize の話をしたときの資料です。

                                                            20,000+行のmanifestをリファクタリングして分かったKustomizeの美しきアーキテクチャと拡張性 / Kustomize deep dive
                                                          • Kazuho Oku on Twitter: "プルリク、たいていmainブランチのHEADよりも古いのをフォークしてるけど、そういうなのを手元でレビューする時は git diff -r $(git merge-base HEAD main) とやると、共通祖先とのdiff… https://t.co/UstVHNFGmv"

                                                            プルリク、たいていmainブランチのHEADよりも古いのをフォークしてるけど、そういうなのを手元でレビューする時は git diff -r $(git merge-base HEAD main) とやると、共通祖先とのdiff… https://t.co/UstVHNFGmv

                                                              Kazuho Oku on Twitter: "プルリク、たいていmainブランチのHEADよりも古いのをフォークしてるけど、そういうなのを手元でレビューする時は git diff -r $(git merge-base HEAD main) とやると、共通祖先とのdiff… https://t.co/UstVHNFGmv"
                                                            • プログラミング初心者はgit commitする前に必ずdiffを自分でレビューするクセを付けよう - give IT a try

                                                              プログラミング初心者向けの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

                                                                プログラミング初心者はgit commitする前に必ずdiffを自分でレビューするクセを付けよう - give IT a try
                                                              • bashとzshの違い。bashからの乗り換えで気をつけるべき16の事柄

                                                                bashからzshに乗り換えるユーザーを対象に16の違いをまとめました。MacOSもbashからzshに変更になりましたので、zshを使い始めるにあたってのポイントを解説していきます。 はじめに zshとは? 2019年、WWDC19の基調講演でApple社は次にリリースする「MacOS X Catalina」より標準のシェルを「zsh」に変更すると発表しました。そして現在、Macを購入したり最新のバージョンにアップデートしてターミナルを開くとbashではなくzshが起動します。 もともとMacOS Xは当初tcshであったのがv10.3 Pantherよりbashに変更された経緯があり今回それがzshにさらに変更された形になります。 こうなった経緯としてはbashのライセンスとセキュリティによる事情があります。MacOS Mojaveまでに搭載されているbashはバージョンが3で実はこれ

                                                                  bashとzshの違い。bashからの乗り換えで気をつけるべき16の事柄
                                                                • GitHub - Wilfred/difftastic: a structural diff that understands syntax 🟥🟩

                                                                  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

                                                                    GitHub - Wilfred/difftastic: a structural diff that understands syntax 🟥🟩
                                                                  • 「Visual Studio」にようやく差分表示(Diff)が実装へ? ~叩き台となる拡張機能が公開/ファイル同士だけでなく、クリップボードとの比較も可能

                                                                      「Visual Studio」にようやく差分表示(Diff)が実装へ? ~叩き台となる拡張機能が公開/ファイル同士だけでなく、クリップボードとの比較も可能
                                                                    • いかにして文芸領域はバージョン管理システムの認識を獲得をしうるか - あたし、めりーさん。今、あなたが心の中にいるわ。

                                                                      まだ色のないあじさい。 『ギークに銃はいらない』が発売されました。はい~拍手~ ギークに銃はいらない 作者:斧田小夜破滅派Amazonみんな買ったかな? うん、買ったよね!でももう一冊あってもいいんじゃないカナ!?!?(よくないだろ Youtubeでスペシャルコンテンツを配信しましたが、こっちではドキュメント管理の話を書こうかなと思います。近いうちにSpaceかなにかをやるかもしれない(まだわからない なぜ「ギークに銃はいらない」はGithubで管理する必要があったか? そもそもGithubってなによ!?って方もままおられるかと思いますが、簡単に言えばクラウドを使ってドキュメント(特にソースコードとか)を便利に保管するツールだよ!ってことを覚えておいてもらえればよいかと思います。厳密にいえばクラウドストレージとバージョン管理システムとそれのホスティングサービスはすべて違うもので、Githu

                                                                        いかにして文芸領域はバージョン管理システムの認識を獲得をしうるか - あたし、めりーさん。今、あなたが心の中にいるわ。
                                                                      • set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット - Islands in the byte stream

                                                                        課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 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 (コマンドが失敗するとシェルスクリプトが即座に終了する)を効

                                                                          set -eのもとで特定のコマンドの終了ステータスを変数に入れるシェルスクリプトのスニペット - Islands in the byte stream
                                                                        • 成果物の Diff をまとめてとって TypeScript のアップグレードを円滑にした - potato4d

                                                                          最近仕事でやっているプロジェクトの TypeScript のバージョンが 3.9。 そこそこ古くなっているのと、 TS は比較的気軽に上げて良くてバージョンアップの恩恵も高いパッケージなので、MTGが早く終わったスキマ時間で最新に上げてみることにした。 結果として tsc の設定を変えつつ $ diff -r ./before/ ./after/ を活用するとかなり楽に移行できたので、やりかたを残しておく。 手順 やり方を考える 一応社内に Renovate Bot が立っていて、かつそこから出ている Pull Request も存在したものの、流石にビルド成果物を比較しないままエイヤで上げるのは躊躇われる。 TypeScript のバージョンを上げて何かが壊れたことは経験としては一度もないが、一方でその経験則は根拠足り得ないので、一応アプリケーションへの影響を調査して、違いがないことを確

                                                                            成果物の Diff をまとめてとって TypeScript のアップグレードを円滑にした - potato4d
                                                                          • イケメンdiff viewerのDeltaを入れてみた

                                                                            はじめに 差分というものは見やすいほうがよいですよね 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を用います

                                                                              イケメンdiff viewerのDeltaを入れてみた
                                                                            • go-cmpを使う理由とTipsの紹介 - 技術メモ

                                                                              はじめに これは Go 4 Advent Calendar 2020 8日目の記事です。 Goのテストにおいて、構造体を含めて型の値を比較したいという場合は往々にしてあります。ロジックの結果はなんらかの値として作用することが多いですから、型の値を比較したい、というのは自然です。私は型の値が等価であるかどうか判定するために、go-cmp というライブラリを使うことが多いです。 github.com しかしGoにおける等価性の仕様は決まっていますし、標準ライブラリの reflect パッケージにも DeepEqual という deeply equal, かどうか判定するメソッドがあります。そこで本記事ではなぜわざわざ go-cmp を使っているのかという理由と、go-cmp を使ったときにどのようにして使うか?という go-cmp の使う上でよく使う以下のTipsを提供したいと思います。 Ti

                                                                                go-cmpを使う理由とTipsの紹介 - 技術メモ
                                                                              • アンチパターン “ゴールが延び続けるスクラム”

                                                                                チームやプロジェクトを率いる立場で意識していることの1つに、「メンバーがタスクをやり切ったと継続的に感じられる仕組み作り」がある。特にスクラムを採用している場合は ”前に進んでいる感” を継続的に醸成していく事も欠かしてはいけないと思っている。ただ現実にはこの観点は悪気なく疎かになってしまうケースが(自他共に)多いという感覚がある。 Pull Requestレビューを例にしてみる。2週間スプリントのアジャイルチームでとあるプロジェクトの主担当として開発をリードしているエンジニア氏。仕様検討・周囲との調整・実装を頑張ってPull Request作成まで漕ぎ着けた。エンジニアは一旦ココで”仮達成感”に浸る(と、個人的に思っている)。そしてレビュワーにレビューを依頼して、反応を待つ。のだが。。。 スプリント1: 「進捗してます」「pullreqレビューをassignされたエンジニア程、別件で忙し

                                                                                • GitHub - trailofbits/graphtage: A semantic diff utility and library for tree-like files such as JSON, JSON5, XML, HTML, YAML, and CSV.

                                                                                  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

                                                                                    GitHub - trailofbits/graphtage: A semantic diff utility and library for tree-like files such as JSON, JSON5, XML, HTML, YAML, and CSV.

                                                                                  新着記事