タグ

diffとqiitaに関するslay-tのブックマーク (5)

  • 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
  • LinuxでもっともF-wordなコミットを探す(git以降編) - Qiita

    tl; dr: 近年のLinuxはそれほどファ●ックではない。最大の"F値"は25で、単一のファイルに集中していた。 もくてき ファッ●クと言えばLinuxの風物詩と言える時期もあったが、最近は落ちついてきた印象はある。それでも fuck コマンド やメーリングリスト等では言及は有る。 では、それを印象付けるような出来事としては何があったのだろうか。今回、コミットログおよびそのソースコードdiffにおけるF-wordの登場回数を F 値 (F value) と定義し、最もF値の高いコミット(the most F-valued commit)を探してみることにした。 (ソースコードdiffにおける登場回数であるため、F-wordを削除したコミットも高いF値が与えられることに注意する) 全てのコミットを git show する 最近シェルスクリプト代わりにCMakeを使っているので今回もCMa

    LinuxでもっともF-wordなコミットを探す(git以降編) - Qiita
  • Jupyter Notebook ファイルのままdiffをとったり、マージしたり出来るツール nbdime - Qiita

    Jupyter Notebook の問題点 Jupyter Notebook は、ソースコードとアウトプットが一つの ノートブックファイル.ipynb で管理・実行することができるので、非常に便利です。しかし、その代償として、.ipynb ファイルにはソースコード以外のメタデータやアウトプットデータが含まれる為に、ソースコード部分の差分が非常に分かりにくくなってしまいます。 jupytext等で、.pyファイルにエクスポートして diffを取ることも考えられますが、.pyファイルが増えてしまい、来の .pyファイルと混じって、これはこれで管理しづらい。 結構困った問題です。 ノートブックdiffツール nbdime ノートブックのままdiffをとったりマージしたり出来ないかと思っていたところ、nbdime というツールでばっちりそれができるらしい。 Github リポジトリ https:

    Jupyter Notebook ファイルのままdiffをとったり、マージしたり出来るツール nbdime - Qiita
  • ファジングと統計学 - Qiita

    Whitebox Fuzzingはある入力に対してプログラムを実行した際、実行されたコードフロー上の全てのロジックを記録し、他の新たなフローを生成するための条件をSMTソルバで導く事で次の入力を生成する。いわゆるSymbolic Executionがこれに分類される。 Greybox Fuzzingの部分的な情報というのはかなり曖昧な定義だが、多くはプログラムを実行した際のカバレッジ情報が使用される。これを特にCoverage based (Greybox) Fuzzingと呼ぶ。 例えばAFLはある入力を実行した際に通ったエッジカバレッジを観測し、今まで見たことの無いエッジを通るとその入力を優先的に保持するようになっている。 FCS(Fuzzing Configuration Schedule) さてでは題のシードスケジューリング問題について説明する。 VALENTIN J.M1によれ

    ファジングと統計学 - Qiita
  • Gitで日本語長文のdiffをとる方法 - Qiita

    (この記事はここからの転載です) 課題 日語の長文をgitで管理していると、ほんのちょっとの変更でもdiffでは行丸ごと変更されたことになり、変更点がよくわからないことがある。 二泊三日で小説を書く過激なイベントNovelJam 2018参加作品である高橋文樹氏の「オートマティック クリミナル」は、GitHubを使って執筆されている。小説では、git diffの欠点がはっきりでる。高橋氏は参加レポートで、こう書いている。 あと、今回得た重要な知見なのですが、Githubではある程度以上テキストが長くなってくると、数文字の調整で全部差分として判定されたりするので、小説には向いてないかなーと思いました。小説は行の移動とかがよく発生するので、GithubじゃなくてGitとの相性かもしれません。 普通にdiffを取る 確かに、普通にdiffをとるとその通り。コマンドラインで「オートマティック ク

    Gitで日本語長文のdiffをとる方法 - Qiita
  • 1