プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
プロダクトマネジメントクライテリア
プロダクトマネジメントを体系化したクライテリアです。企業がプロダクトを成功に導くために必要な要素を多角的かつ具体的に記載してあります。対象はプロダクトマネージャー個人ではなくプロダクトを取り巻くチームとし、プロダクトマネジメント全体をスコープにしています。
Goの正規表現が遅いって言う人がいたから、（速い）正規表現エンジンを作ったよ
はじめに 「Goの正規表現は遅い」 そんなふうによく言われていました。（最近はあまり聞かなくなりましたが） たとえば、↓の記事ではPythonの正規表現と比較して1.5倍くらい遅いという結果になっています： この話には「Goの正規表現は最悪時間が短くなるように安定したアルゴリズムを採用しているから」という回答があります： ↑の記事の比較では、GoがPerlに対して約10倍以上高速という結果が出ているので、「Goの正規表現は遅くない！はい、論破ー！」というわけですね。 なんでこうなるのかも↑の記事で説明されているとおりですが、Perl（などのバックトラック型エンジン）が入力長に対して指数関数的に実行時間が伸びていくのに対し、Goの正規表現エンジンは入力長に対して線形時間で実行時間が伸びていくアルゴリズムを採用しているため、入力が長くなると急激にGoのほうが有利になるからです： 一方で、入力が
Golangの正規表現の処理速度 - seven_901’s blog
概要 Golangで正規表現を扱うことになったので、ググったところgolangのサジェストワードに「遅い」というワードが出てきた。 なので、調査してみた。 Golangの正規表現 実装 pkg.go.dev 上記のサイトはGolangで正規表現を扱うときに使われるregexpパッケージの公式ドキュメント。 ドキュメントによる処理速度に関する記述では The regexp implementation provided by this package is guaranteed to run in time linear in the size of the input. (This is a property not guaranteed by most open source implementations of regular expressions.) と書かれており、ざっくり日本語
grep と sift を比較した - にょきにょきブログ
sift というツールがあります。 https://sift-tool.org/ sift は better grep なツールで、上記サイトのパフォーマンスによるとすべての場合において grep より速く、場合によっては 40 倍速以上のパフォーマンスを出すという、嘘だろ承太郎！？な状態なのでこの怪しい伝説を検証してみます。 https://sift-tool.org/info.html 環境 僕の環境はこちら。 CPU: Intel Corei7 4790 メモリ: 16GB ストレージ: SSD 256GB OS: Ubuntu 14.04 64bit インストール https://sift-tool.org/download.html から適切なアーカイブをダウンロードして解凍。 $ tar zvxf sift_0.3.4_linux_amd64.tar.gz sift_0.3.4
『Winny』の金子勇さんの失われたED法を求めて - Qiita
普段は「通知が迷惑かなー」と思ってブックマークしていただいている方に通知せず記事を編集しているのですが、この記事をブクマしていただいている方は続きが気になっている方だと思いますので通知させていただきます。 結論から言うと、この記事を読んだ @pocokhc (ちぃがぅ)さんという方が金子勇さんが書いたED法のサンプルプログラムを見つけてくださいました。 ちぃがぅさんの記事はこちら 自分で解明したかったという気持ちも無いことは無いですが、バズった時点で誰かが実装してくれそうな気はしていました。新卒からIT業界に入って4年目が始まったところですが、業務以外で初めて業界にコントリビュートできた気がして嬉しいです！ 追記ついでに、謝罪します。初回公開時に記事タイトル含め本文中で何か所か「Winney」と書いてしまっていた箇所がありました。失礼いたしました。誤字修正してあります。指摘してくださった何
GNU grep は /dev/null に出力すると、処理速度が異常に速くなる件について - Qiita
あ．．．ありのまま 今 起こった事を話すぜ！ 「おれは cat の方が grep "." よりも速いことを示すために、両方の出力を /dev/null に捨てたら grep の方だけ処理速度が異常に速くなっていた」 な・・・ 何を言っているのか わからねーと思うが おれも 何が起きたのか わからなかった・・・ 頭がどうにかなりそうだった・・・ 催眠術だとか超スピードだとか そんなチャチなもんじゃあ 断じてねえ もっと恐ろしいものの片鱗を 味わったぜ・・・ ん？ いや、超スピードを味わったぜ はじめに 何かのパフォーマンステストするときに、出力を画面やファイルに行うと速度が低下してしまうので、それを避けるために /dev/null に捨てるというのはよくある事だと思います。別件でとあるパフォーマンステストをしていたところ何やら不思議な結果がでてしまったので調べたのですが、どうやら GNU g
grepよりfind+xargsの方が速い｜ymzkjpx blog
■ プログラムにとって速さは正義だ。 プログラムは命令を実行するツールでありアートではないため、機能性が高く評価される。 例えば大量のファイルを対象に検索を行う際にコンマ1秒でも速く終わればどれほど嬉しいことか。それが100回も1000回も繰り返す使われるようなプログラムならなおのことだ。 先日、知人からgrep より find + xargsの方が速いとの話を伺ったので今日はその検証を行う。 まず手元に2500万文字のファイルを5つ用意した。この中に「test」という文字がいくつか含まれている。このファイルを5つ複製し、これらを検索する実行速度を評価する。 ファイルの文字数。このファイルが5つあり、その中から特定語を検索する。 textfile1.txt $ cat milchars.txt| wc -m 26116283 ■ 測定方法 mac（linux）でコマンドの実行速度を測る際は
ackを使おう! - tototoshi の日記
みなさんgrepしてますか!? 便利ですよねgrep。自分はLinuxを触りはじめたころ、 grepを使いこなせるようになれば一人前だ って言われて、なにいってんのこの人きもいとか思ってないですよ全然。 まあ今となってはgrepをそれなりに使いこんでるわけですよ。 $ find . -name "*hoge" -type -f | grep -v '\.svn' | xargs grep piyopiyo とかやってね。 なんかfind|xargs|grepとかまさにUNIX的ですよね。素敵やん。 簡単なコマンドを組み合わせてでっかいことやっちゃう？？みたいな？？ めんどくせーよっ!!! ってことで、ackを使いましょう。 ack昨日知りました。 で、今日、使いはじめて2日目。 とりあえず、公式(Beyond grep: ack 2.12, a source code search too
GNU grep 2.18リリース: 10倍速くなったと思ったら今度は200倍遅くなっていた | はむかず！
先日の記事 いまさらgrepが10倍高速化したのはなぜか が思わぬ閲覧数を稼いでしまい、トルコ語の知識を日本に広めるのに大きな貢献をしたような気がしますが、みなさんいかがお過ごしでしょうか。 実は先日の記事を書いた時にはすでに2.18がリリースされてたのだが、今回は2.17のときと違って日本の大手メディアが取り上げてなかったので、ついつい見落としていた。しかし実は2.18でも大きな変更が！！ リリースノート抜粋： grep -i in a multibyte, non-UTF8 locale could be up to 200 times slower than in 2.16. [bug introduced in grep-2.17] なんということでしょう。-iオプションでUTF8のときは2.17で10倍速くなっていたのだが、それ以外のマルチバイトロケールのときは200倍遅くなって
いまさらgrepが10倍高速化したのはなぜか – はむかず！
最近GNU grepコマンドの最新バージョンがリリースされ、速度が10倍になったとのアナウンスがあった。それを聞いて、なんであんな枯れた技術に10倍もの高速化の余地があったのだろうと不思議に思った人も多いだろう。 ニュース記事：grepコマンド最新版、”-i”で10倍の高速化 本家のリリースノート：grep – News: grep-2.17 released [stable] 今回のリリースでは正確には、マルチバイトロケールで、-iオプション（–ignore-case、つまり大文字小文字を区別しないオプション）をオンにした時の速度が10倍くらいになったそうだ。 なぜそんなに速くなったのか？逆を言えば今までなぜそんなに遅かったのか？ そもそも、多くの日本人にとって「大文字小文字の区別」というと英語のアルファベットか、せいぜいフランス語とかドイツ語とかのアクサン記号・ウムラウトがついたものく
原理原則から適切なgoroutineの数を考える
概要 動機 goroutineを使ってパフォーマンスを改善する際に、どれくらの数で並行処理すればいいのか分かりませんでした。そこで、そもそもどのような仕組みなのか調べ、どのような性質の仕事が改善されるのか計測して、適切な数を決めるための観点を整理しました。 要約 goroutineはカーネルスレッドとM:Nの関係になっています。そしてカーネルスレッドごとにgoroutineのキューがあり、Goのスケジューラが順次実行していきます。 IO-Boundな処理は、netpollerが別のカーネルスレッドで非同期でシステムコールを実行するので他のgoroutineをブロックしないようになっています。 goroutineの使用時には以下の観点を留意する必要が計測から分かりました。 goroutineを使う場合はコンテキストスイッチのコストとトレードオフになる CPU-Boundなgoroutineは
pipeエラーのハンドリング - Carpe Diem
概要 write: broken pipeといったクライアント側の強制的なコネクション切断でのエラーハンドリングをする際の知見まとめ。 環境 golang/go 1.13.3 事前知識 知っておくと良い知識を先に説明します。 そもそもpipeとは pipeはプロセス間通信をするための単方向のデータチャネルです。IOストリームを扱います。 読み出し側と書き込み側それぞれのfdを経由してプロセス間の通信を可能にします。 例えば親子プロセスで通信を行いたい場合、親プロセスでpipeを開きそれをforkして子プロセスを用意します。 ref: https://inzkyk.github.io/ocamlunix-jp/pipes.html そして親プロセスの書き込みfd・子プロセスの読み出しfdをそれぞれクローズすれば、以下のように子プロセス→親プロセスへ通信することができます。 pipeはシンプル
ripgrep は {grep, ag, git grep, ucg, pt, sift} より速い (翻訳) - inzkyk.xyz
これは Andrew Gallant 著 ripgrep is faster than {grep, ag, git grep, ucg, pt, sift} の翻訳です。英語版は UNLICENSE と MIT ライセンスのデュアルライセンスで公開されています。 この翻訳は UNLICENSE の許諾に基づいて公開されます。 この記事では新しいコマンドライン検索ツール ripgrep を紹介する。ripgrep は The Silver Searcher (ack クローン) の利便性と GNU grep の高い性能を併せ持つ。ripgrep は高速で、クロスプラットフォーム (Linux, Mac, Windows 用のバイナリが利用可能) で、Rust を使って書かれている。 ripgrep は Github で公開されている。 この記事では不可能なことを試みる: いくつかの有名なコ
Apple PayからFeliCa系決済サービスが消える日
米国でのリリースから2年、日本にApple Payが上陸したのは2016年10月のこと。当時、日本国内ではクレジットカードの“タッチ”による非接触決済が一般的ではなかったため、日本版Apple Payでは他国にはない特殊な仕組みが導入された。 日本国内における非接触決済といえば、FeliCaを使ったSuicaなどの「交通系IC」や「楽天Edy」、ドコモと三井住友カードによる「iD」、JCBの「QUICPay」、そして流通系事業者が提供する「nanaco」「WAON」といったサービスが主流だった。 日本版Apple Payにおいては、非接触によるリアル店舗決済のために交通系IC、iD、QUICPayを採用し、特に同サービスにクレジットカードを登録した場合にはiDまたはQUICPayのいずれかが非接触決済として利用可能とした。 他国では、例えばMastercardブランドのクレジットカードをA
図解 Go Slice Tricks | Folioscope
この記事はGo7 Advent Calendar 2019の記事です。 Go には Java や Ruby などのモダン言語のような slice を操作する関数は用意されていません。 Go では built-in 関数のappend()やcopy() と for 構文を組み合わせることで、他の言語にあるような slice 操作を実装できます。 この記事ではそれぞれの slice 操作を図解で解説します。 元ネタは Go 公式 Wiki にあるGo SliceTricks - golang/go Wikiです。 Slice の連結 a = append(a, b...) コピー先 a にコピー元の b の全ての要素をコピーします。 連結後の長さが cap(a) を超える場合は、新たな slice が作成されて a、bともにコピーします。 以降はappend()のコピー先には十分なcapがある
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - bayashi/xfg: Find paths anyway, then search for contents also, naturally.
マイナンバー法改正案が衆院通過 スマホにカードの全機能搭載 - 日本経済新聞
Git - gitignore Documentation
Cg125
カレントディレクトリパスの中のgitレポジトリに色を付けると便利