追記: 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
Git は紛らわしいという評判です。用語や言い回しが意味するものと、そこから想像する挙動が違ってユーザーが混乱すると言われます。これは、git cherry-pick や git rebase のような「履歴を書き換える」コマンドに最も顕著です。私の経験では、この混乱の根本的な原因は、コミットは 差分 であり順番を入れ替えることができるという解釈にあります。しかし、コミットはスナップショットであって、差分ではありません! Git がリポジトリデータをどのように保存しているかを見てみると、Git を理解しやすくなります。このモデルを調べた後に、この新しい視点が git cherry-pick や git rebase のようなコマンドを理解するのにどのように役立つのかを探っていきます。 本当に深く 掘り下げたいのであれば、Pro Git という書籍の Git Internals の章を読むと
This page is obsolete. Please visit the development repository. このページは内容が古くなっています。開発サイトをご覧ください。 Table of Contents 目次 Summary Screenshot Document Summary 概要 DocDiff compares two text files and shows the difference. It can compare files word by word, char by char, or line by line. It has several output formats such as HTML, tty, Manued, or user-defined markup. DocDiffは2つのテキストファイルを比較してその違いを表示します。単語ごと
春の入門祭りの8日目です。 文字列の新旧の違いを表現する時によくdiffをとるとか言いますよね。そこで実行されるのが差分アルゴリズムです。差分のアルゴリズムって結構知れば知るほど難しいやつです。「より良い差分」という基準が、状況によって変わるからです。ヒューリスティックなやつです。例えば、HTMLの説明の文章を書いていたとします。タイトルをテーブルに書き換えてみたとします。 どちらも間違ってはおらず、この差分を元にパッチを当てたりも可能です。ただ、読んだ時の読みやすさが違います。 これはもちろん前者と答える人の方が多いでしょう。だって、タグという意味の塊が維持されていますからね。 これは究極的にはわかりやすいdiffというのは「意味」を理解しないと作れないということを意味します。これがdiffは簡単なようで難しいと書いた理由です。もちろん、ほどほどの工数で、ほどほどの見た目のdiffも作成
最近GoでCLIツールを作っていますが、JSONが良いとなんとなく思っています。 続編も公開しました（追記：2019年10月2日）。 CUEを試して見る 設定ファイルフォーマット近年、設定ファイルを書くプレーンテキストのフォーマットとしては次のようなものが多いかと思われます。 XML 多くのプログラミング言語において標準ライブラリで扱える（ただしNode.jsにはない） XMLスキーマ、XSLTなどの周辺ツールも揃っているが、記述が冗長になりがちで、敬遠されがち。 ini QtやPythonの標準ライブラリで扱える 深い階層や配列を扱うのが苦手 JSON ほとんどのプログラミング言語で標準ライブラリに入っている 特にフロントエンドのJavaScriptでは追加のライブラリを利用する必要がなく、速度も早く、gzipすればファイルサイズもかなり小さくなる。T 閉じかっこが必要、コメントがつけら
tl;dr 先頭 8000 バイト以内に NUL が有ったらバイナリファイル。 Gitの実装 Gitの内蔵diffは FIRST_FEW_BYTES だけ検索するようになっている。 https://github.com/git/git/blob/6e0cc6776106079ed4efa0cc9abace4107657abf/xdiff-interface.c#L187 #define FIRST_FEW_BYTES 8000 int buffer_is_binary(const char *ptr, unsigned long size) { if (FIRST_FEW_BYTES < size) size = FIRST_FEW_BYTES; return !!memchr(ptr, 0, size); }
patch 8.1.0363 にて diffopt オプションに internal という値が追加され、デフォルト値となりました。これまでは diffopt=filter という値がデフォルト値になっており差分表示を行う際には外部コマンドの diff が使われていました。今回入った diffopt=internal により Vim の内部に実装された処理により diff の表示が行われます。diff コマンドがインストールされていない OS の場合はとても便利になりました。 これまでも Vim の diff 表示は便利に使われてきたのですが、中には diff モードに入った事を契機にキーをマップしたり便利な設定をされていたかもしれません。その際これまでは外部コマンドによるフィルタ処理が行われていたので FilterWritePre や FilterWritePost というイベントが発火し
こんにちは、鈴木です。 20 万行を超えるアプリケーションのほとんど全てのソースコードを変更し、テストを行わずに本番リリースしました。 「それってテストいるんですか？」問題 いきなりですが質問です。ソースコードを 1 バイトでも変更したら再テストする必要はあるでしょうか。「絶対に再テストすべき」という方もいれば、「状況によるしケースバイケースかな・・」という方もいらっしゃると思います。 ケースバイケースと考える方は、どのような場合にテストを行わなくて良いと考えるでしょうか。例えば、コメント内の誤字を修正した場合はどうでしょうか。ローカル変数の名前を typo していたので修正した場合、デッドコードを削除した場合はどうでしょうか。 こんなことがありました ある日、Python のソースコードを眺めていると、「# $Id」のような CVS 時代のコメントがありました。いまやソースコードは Gi
追記 その後、optex だけを使ってより汎用的なインタフェースで実装しました。今から使うんだったら、こちらの方がいいと思います。 MS Office ドキュメントや PDF ファイルを grep したり diff したりする - Qiita 追記2 greple の -Mmsdoc モジュールは、1.04 (2020-09-23) から optex -Mtextconv のコードを利用するように変更されています。なので、今はどちらを使っても同じ結果になります。optex を使うと、指定したすべてのファイルを変換してからコマンドを実行するので、多くのファイルを指定すると時間がかかります。-Mmsdoc モジュールの場合は、都度変換しながら処理します。 MS のドキュメントを端末で操作する マイクロソフトという会社は別に嫌いではないが、ソフトウェアさえ作ってくれなければいいのになあと思う。そ
ストーリー by hylom 2016年11月29日 21時01分 少なくともGitHubのみに依存しないのは正しいと思う 部門より Redditで「This is why Linus doesn't accept PRs from GitHub」（LinusがGitHubからのプルリクエストを受け付けない理由がこれだ）という画像が話題になっている。 ここで言われている「Linus」は、もちろんLinuxの開発者であるLinus Torvalds氏。この画像は、GitHub上のLinuxのリポジトリに対する「Delete duplicate word "long long" in Introduction」（イントロダクション中でダブっている「long long」という単語を削除）いうプルリクエスト。これに対し、ほかの開発者からが「long long」は単語がダブってるわけではなくそういう
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
海外事業向けのiOSアプリケーション開発を担当している西山(@yuseinishiyama)です。クックパッドは現在、海外複数カ国に向けてサービスを展開しています。 XcodeにはInterface Builderと呼ばれる、リッチなGUIを持ったデザインツールが付属しており、これを用いて画面のレイアウトを構成することが主流となっています。弊社ブログでも、iOS開発でstoryboardとxibをうまく使い分けるプラクティス等の記事で、GUIベースのレイアウトについて触れています。しかし、現在私が担当しているプロジェクトでは、Interface Builderを用いずに、レイアウトの大半をコードで記述しています。 今回は、コードベースのレイアウトを実装していく中で得た知見を、以下の3つの部分に分けて共有したいと思います。 Interface Builderを用いたレイアウトとコードベースの
こんにちは、白ヤギでは下手の横好き的なPythonistaのシバタアキラです。 カメリオのような複雑なオンラインサービスを開発提供していく上では、様々な開発言語からミドルウェアそしてハードウェアやモニタリングに至るまで、様々な計算技術を応用しています。開発言語自体はあくまで手段であって目的ではないので、自分たちのマインドシェアの中でも小さくあるべきと思っています。一方で、未だにvim vs emacsなんていう些細な選択肢に関しても「戦争」が起こる様に（起こってない？）なんだかんだいって、ツールというのはエンジニアにとってもデータサイエンティストにとってもとても大切なモノです。 昨年PyConJPのスポンサー（今年もやります！）をして以来、Pythonコミュニティーでコアに活動されている方々とお付き合いさせていただく機会も増え、また自分でもPyData.Tokyoというデータサイエンスに特
UPDATE(2015/09/26):この文書はDeprecatedという単語の使い方が雑なのでDeprecatedになりました。 こちらの記事を参照した方が得るものがあるかと思います。 qiita.com 新しいAPIの誕生より、APIの滅びの方が好きです。なぜならそこには失敗があり、学びがあるからです。 developer.apple.com …とか適当に言ってみましたが、iOS9のAPI Diffは、Swift2.0絡みの変更点（主にNSErrorに対応するenumの追加と、後述するビットマスクの扱いの変更）だらけで、本当に変わった場所がどこなのか分かりにくいので、ちゃんと調べてないです。 AudioUnitがOSXに追いついたCoreAudio周りが熱いような…。CFunctionPointerの魔窟だったCoreMIDIなんかは刷新と言っていいレベルで変わっていますね。でも今のA
4月から都会でOLとして働き始めたので, OL的windowsの事務処理環境を手探りで作ってみました. OLとWindows 事務処理といえばOffice, 当然Windowsで行うことになります. 今時のOLは家ではLinuxを使っているはずなので, 自然とシェル環境で困ることになります. Windowsが本当にわからない linuxコマンド使いたい（DOS音痴） Cygwinは嫌い MinGW+MSYS にしてみたい(けど未だによくわかってない) 事務PCなので, 大掛かりな環境は入れたくない（入れられない） WSL ? そもそも Windows7 なので（ry） などのモチベーションから 色々見ていてcmderが良さそうだなと思ったのですが cmder.net 所属機関でフィルタされて落とせなかった（つらい）ので, ConEmu + msys bash の組み合わせで端末環境を整える
第61回 Cocoa勉強会関西で“Swift 1.2 The long-awaited language updates”と題して発表した、Swift 1.2の主だった（おもしろい）変更点の紹介です。 if let Swift 1.2で最も改善されたのはif文です。if letでOptionalをunwrapできる機能が大きく向上し、複数のOptionalを同時にunwrapできるほか、unwrapされた値について条件を加えることができるようになりました。 例えばcondition: Boolが真でふたつのOptional<Int>がnilではなく、大小関係にも条件がある、という条件を表してみます。 Swift 1.1 let condition = true let aNumber: Int? = 3 let anotherNumber: Int? = 7 if condition {
目的はわかったけどどうしてこの変更で達成できるの？がわからない、文脈が抜け落ちている Diff というのがある。唐突な Diff、と呼ぼう。 唐突な Diff との戦いには二種類ある。 一つは自分が唐突な Diff を作らない、という戦いで、ちょっと込み入ったバグ修正など、変更する箇所は少ないがそのぶん意図がわかりづらくなる場合。自分はバグの原因を解明する過程で関連するコードを読み込んでいるので「流れ」を把握できているが、レビュアーが Diff そのものから全体像を思い描くのは難しい。リグレッションテストを追加してもやはり文脈なしでは説明不足だ。そういうときはコメントを丁寧に書き、場合によっては関連コードのリンクを添えつつステップを順に説明したりする。これにはそれなりに手間と時間がかかる。 もう一つは唐突な Diff に出会ったときちゃんと質問する、という戦いで、「なんだこれは？」と言いた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
