golang で zsh history を SQL 的に活用する - tellme.tokyo
僕は開発中、zsh のヒストリー補完の機能をよく使います。具体的には次のような場面が多いです。 多用するコマンド 結局開発中に使うのはエディタ (vim) と git サブコマンドに集中する ちょちょいと ^N (↑) で履歴をさかのぼる alias がイケてない場面 「エディタで .zshrc 開いて追加してリロード」が面倒で後回ししがち そして登録せずに終わる の繰り返し… うろ覚え程度のコマンドの alias 名はもはや思い出せない 結局エディタ開いて見直したり、^R で遡ることに挑戦する 長いコマンド列になるとき 引数が多いとき、多段のパイプで繋いだとき 例えば、複数のパラメータを与えたときの curl コマンド Ctrl-r (history-incremental-search-backward) よるヒストリーサーチが便利なのはよく知られたことですが、それに加えて peco
イベント駆動型サービス実行基盤としての Service Worker - Qiita
当初は better AppCache1 として開発が始まった Service Worker2 ですが、ページとは独立したライフサイクルを持つことでイベント駆動型のサービス3実行基盤としての色合いが強くなっています。本記事では、イベント駆動型のサービス実行基盤とは何なのか、そこへと発展していった流れについて紹介します。 なお本記事は Service Worker の使い方を紹介するものではありません。Service Worker をある程度理解している開発者を想定読者としています。また、本記事はすべて私の個人的な意見や調査に基づくものであり、所属する組織、団体とは一切関係ありません。前置きおわり。 AppCache、そして Service Worker へ 冒頭でも述べた通り、Service Worker は当初 better AppCache として開発が始まりました4 5 6。AppC
闇のDevOps DevOpsと業績評価 – ところてん – Medium
ここから、DevとOpsが協力すればより効率的になる＝DevOps、という言葉が生まれました。 当時は大企業においてはDevとOpsが分かれていることが当たり前だったのです。そして、大企業における当たり前が、当たり前ではないことに気付き始め、DevOpsを実現するためのツールができ始めたころでもあります。 ではなぜ、大企業ではDevとOpsが分かれているのが当たり前だったのでしょうか？ ハードウェアの時代その昔、産業の主役はハードウェアでした。 そのため、多くの企業はハードウェアを作ることに対して最適化が行われました。 ハードウェアには研究開発、製造、運用サポートといった大きな区分けが存在します。そして、それぞれの仕事において要求する人材レベルは異なります。 加えて、大量生産された製品の運用サポート（設置作業員、サポートセンタ）には、大量の人員が必要になってきます。 したがって、組織を研究
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
