PostgreSQLでauto_explainを使ってどのクエリが遅いか把握する - $shibayu36->blog;
ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log
Elasticsearchのインデックス定義を設計する手順 - $shibayu36->blog;
Elasticsearchを使おうとすると、まずアプリケーションの仕様にしたがってインデックス定義やマッピング定義を設計しなければならない。これはMySQLを使っていてスキーマを考えるフェーズに相当する。 この時、考えることが非常に多く、いろいろなドキュメントを参照し設計したので、今回はその手順について書いていきたいと思う。 インデックスやマッピングが何かという話は、次の記事を参考に。 Elasticsearchチュートリアル - 不可視点 Mapping and Analysis | Elasticsearch: The Definitive Guide [2.x] | Elastic また対象とするElasticsearchのversionは記事執筆時点の安定版の2.3.5とする。 今回サンプルとする例 実際のプロジェクトを参考例にすることは流石にできないので、今回はブログの記事を検索
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
プロジェクト単位でElasticsearchのローカル開発環境を作成する - $shibayu36->blog;
最近Elasticsearchを触っていて、まずはローカル開発環境を作ることになった。ただ、Elasticsearchはバージョンがかなり変わり、別プロジェクトと利用したいバージョンが異なっていたので、プロジェクト単位で使い分けるにはどうすればよいかを考えた。 やりたいこと プロジェクトごとにElasticsearchのバージョンを切り替えられるようにしたい MySQLだったら同じようなものにmysqlenvなどがある また、他の人が一瞬で環境を整えられるようにしておきたい 利用するプラグインなども含めて一瞬で バージョンを上げる時もローカル環境なら簡単にあげたい 作戦 Elasticsearchはここ からダウンロードして、特定のディレクトリに展開するだけでも利用できる そこでプロジェクトルートのelasticsearch/ディレクトリ以下に展開し、ここに展開したバイナリを利用するように
自分流Elasticsearch入門 - $shibayu36->blog;
【2016/09/10追記】 勉強しなおして、Elasticsearchの知識についてさらにまとめた記事を書いたので、そちらを参照してもらうと良さそうです。 blog.shibayu36.org 最近Elasticsearchの勉強をした。ただ、入門のためどのような資料が適しているかを知るのが大変だった。そこでどのように勉強したかについてメモをしておく。少しまとめエントリー的なノリになりそう。 Elasticsearchの概念を知る 全文検索技術の基本を知る Elasticsearchのドキュメントのたどり方を知る の順に学習を進めていった。 Elasticsearchの概念を知る Elasticsearchの学習を始めようとした時に、まずは基本からということで以下の本を読んでいた。 高速スケーラブル検索エンジン ElasticSearch Server (アスキー書籍) 作者:Ｒａｆａｌ
「強いチームはオフィスを捨てる」を読んだ - $shibayu36->blog;
強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 作者:ジェイソン・フリード,デイヴィッド・ハイネマイヤー・ハンソン早川書房Amazon 最近リモートワークへの知識に興味が湧いてきたので、ひとまず強いチームはオフィスを捨てるを読んだ。元々はリモートワークについての思い込みがあり、そのためリモートワークの難しさのほうに目が行き過ぎていたのだけれど、この本を読んでみて少し中立よりになれたように思う。そういう面で今の時期に読むには非常に良かった。リモートワークの知識だけというより、普通に働いていても参考になる知識も得られた。 リモートワークを始めたいけど何から始めたらいいかについて分からない人には最適な本。ただし良い本であるという一方で、少しリモートワーク礼賛の傾向があるので、そこは一歩引いて読むと良いのかなと思う。とはいえ、ただ褒めているというだけでなくて、きちんとメリット
pecoを使い始めた - $shibayu36->blog;
なんかpercol最近いきなり流行ってるなーと思ってたら、percolのgo版pecoがいつの間にか出てて流行ってた。ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog;みたいな感じで、昔からpercol使っててまあいいかと思ってたけど 設定ファイルが分かりやすい brewで簡単に入れることが出来る そこそこ開発されてる というメリットもありそうなので乗り換えようとしてみている。 https://github.com/peco/peco pecoのファイル運用 前と大体同じ感じでやる。基本的にこういうツールは自分でいろいろ作りたくなってきて、設定が増えてきて破滅するので、ファイルを置くディレクトリを決めておいてそこに置いておくことにする。 .zshrc : 決めたディレクトリのファイルの全ロードと、キーバインドの設定 ~/.zsh
nginxのproxy設定ファイルも自動テストしよう - $shibayu36->blog;
最近nginxでリバースプロキシの設定を書いているんだけど、設定のたびに本番に緊張しながら反映していた。さらにその副作用として、nginxのファイルはリファクタリングされないという問題があった。 そこで反映する前にバグ等が見つかるようにnginx設定のテストを書きたいと考えた。今回はperlでテストを書いた。 どういうテストをしたいか やり方によってnginxの設定ファイルの分割の方法は違うのだけど、例えば以下の様なnginxの設定があり、それが別のファイルのhttpコンテキストの中にincludeされているという分割で考える。この時、この設定ファイルに書かれた内容が正しく動いているかテストを書きたい。 upstream app1 { server app1.host; } upstream app2 { server app2.host; } server { listen 8080;
cron周りのベストプラクティス読んだ - $shibayu36->blog;
WEB+DBのPerl Hackers Hubで書かれていた「cron周りのベストプラクティス」を読んだ。かなり参考になった。 経緯としては読みたいって呟いたら感想よろしくと言われたので慌てて読んだ。 @shiba_yu36 「読んだ」なら言ってもいい— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジに謝られても…— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジになって感想エントリを書いてください。— songmu (@songmu) 2014年2月24日 特に参考になったこと batch.pl batch.plは非常に良いと思った。というのもcronとかのスクリプトで非常に簡単な事をやっている場合は適当にplファイルを作っちゃって登録するんだけど、得てしてそういうのはテストが無くてバグってて、しかもcronのロ
ターミナル版anything的なpercolをzawの代わりに試してみた - $shibayu36->blog;
emacsを使っているとterminalでもanything的にいろいろやりたくなるんだけど、そういう時にこれまでzawというツールを使ってきた。 https://github.com/zsh-users/zaw zaw.zshで最近移動したディレクトリに移動する - $shibayu36->blog; zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog; zaw結構便利なんだけど問題点もある。 読み込む行数が増えてくると遅くなる 履歴検索で10万行とか行くと動かないので致命的 zshに完全に紐付いてしまって、気軽には使えない で、この前YAPCでid:moozさんと話してて、percolという便利ツール作ってると聞いたので、試してみた。 percolとは 紹介記事などがあるので、それを参考に。 https://github.com/mooz/pe
vagrantでCentOSのVMを立ちあげて、ネットワークが遅い時に試すこと - $shibayu36->blog;
最近PrePANのcarton 1.0化を進めるため、vagrant、chef、knife、AWSなどにはまりまくっております。今回はその中でvagrantにchefを適用しようとしたら全く終わらなくて、それについて調べたことについて話します。 PrePANの開発環境でvagrantを使っていたりするのですが、そのVMに対してchefを適用してみたところ、固まってしまって動かない(厳密に言うとすこしずつしか動かない)という状態になりました。そこでいろいろ調べてみると、IPv6とDNSの関係でネットワークの疎通が遅くなっていたという事がわかりました。 詳しくは Slow networking (due to IPv6?) on CentOS 6.x · Issue #1172 · hashicorp/vagrant · GitHub を見てもらうと分かると思いますが、IPv6で名前解決に行く
zawを使って最近更新したブランチをチェックアウトする - $shibayu36->blog;
仕事でgit使っていてレビューとかしていると、どうもgitのブランチ切り替えがだるくなってくる。それで、zawで更新日時順でブランチが並んでいて、選択するとgit checkout出来ればすぐにブランチ切り替えが出来て便利ではと思いやってみた。 bindしたキーを押すと、更新日時順でブランチが表示されて、Enterを押すとチェックアウトする。更新日時順なので数回キーを押すだけで、チェックアウトしたいブランチに辿り着けることが多い。zawを使っているので絞り込みも出来る。 インストール zawを使っていれば、導入は簡単。 まずzawのsourceのディレクトリに以下のファイルを置く。もしくは適当なところに置いて、zawのloadの後にsourceを使ってloadする。 https://github.com/shibayu36/config-file/blob/master/.zsh/zaw-
elispをpackageとel-get両方で管理する - $shibayu36->blog;
関西Emacsに行って、elispをちゃんとpackage管理みたいなので管理しないとなあという機運が高まったので、管理の方法を見なおしてみました。 これまでの管理方法としては、 基本的にはelispをcurlで落とし、git管理 最近はel-getを使ってみていた という感じにしていました。 しかし、el-getは結構はまるところがあったり、elispをあまり使えない身としてはなかなか厳しいところがありました。そこでpackage.elにしてしまおうかなと思っていました。 ただし、package.elにも一つだけ問題があって、MELPA等に登録しないとpackage管理できないということです。そのため、個人でちょっと書いてgithubにおいてあるelispをpackage管理できません。 そこで以下の様な方針で管理することにしました。 基本的にはpackage.elを使う package
vagrant upの実行が終わらない話 - $shibayu36->blog;
最近AWSとかvagrantとかchefとか勉強していて、vagrantを使っていたのだけど、はじめからハマったのでメモ。 起こったこと vagrant upすることでVMが立ち上がるのだけど、以下の様なところまで言って全く起動しなくなった。 [default] VM already created. Booting if it's not already running... [default] Clearing any previously set forwarded ports... [default] Forwarding ports... [default] -- 22 => 2222 (adapter 1) [default] Creating shared folders metadata... [default] Clearing any previously set ne
vagrantでVMを一度に複数台立てる - $shibayu36->blog;
以前、#kyotopm 04 Hackathonを開催して、Cinnamonの並列化に取り組んでいました - $shibayu36->blog; でも少しだけ触れましたが、vagrantでVMを一度に複数台立てるのをちょっとだけ試したのでメモ。 vagrantはMulti VMに対応していて、設定を少し書けばvagrant upするだけで複数のVMを立てることが出来る。Multi-Machine | Vagrant by HashiCorp あたりが参考になる。 precise32でまっさらなサーバを立てる 例えばpreciese32を使って、まっさらのサーバを2台立ててみる。以下の設定を書いてvagrant upするだけで良い。 Vagrant.configure("2") do |config| config.vm.box = "precise32" config.vm.box_url
Kansai.pmに行ってCinnamonというデプロイツールについて発表しました - $shibayu36->blog;
http://www.zusaar.com/event/476003 に参加して来て、前作ったデプロイツールであるCinnamonについて発表して来ました。 発表したこと 以前capistranoの奥深さに毎回ハマっているのを怒りを覚えて、もっとシンプルなデプロイツールであるCinnamonをantipopさんと一緒に作ったのでその発表をしてきました。それなりに好印象っぽかったので、発表してよかったです。 スライド Cinnamon - simple deploy tool from Yuki Shibazaki デモで使ったサンプルコード https://github.com/shibayu36/cinnamon-deploy-sample 簡単に紹介すると CinnamonはMinimumというのと、Role x Taskというのを思想として持っている Minimum : デプロイの方
direx.elでgitプロジェクトのディレクトリツリーを表示する、またはdirex-project.elの紹介 - $shibayu36->blog;
emacsにはdirex.elという非常に便利なdirectory explorerがあります。これによって、ディレクトリのツリー構造が表示され、diredよりも便利にdirectoryを辿ることが出来るようになりました。 しかし、デフォルトでは自分にとってはいろいろと不便なときもありました。 ~/myprojects/Sample-Project/script/app.psgiを触ってる時に、direxを起動すると、~/myprojects/Sample-Project/scriptのディレクトリからのツリー構造が表示される。実際は~/myprojects/Sample-Projectからのツリー構造が表示されてほしい ~/のツリー構造が開かれている状態で、~/myprojects/Sample-Project/script/app.psgiからdirexを起動すると、~/のツリー構造の
emacsの正規表現をもっと便利に使う - $shibayu36->blog;
emacsで正規表現を使って置換したいみたいな要求はそれなりにあると思いますが、それをやろうとするとemacsの正規表現のバックスラッシュ地獄みたいなものに遭遇することがよくあります。そんな時に使いたいtipsを少しだけ紹介します。 re-builderを使う emacsにはre-builderというものがあって、書いている正規表現のマッチ状況をリアルタイムにプレビューすることが出来るツールが存在します。M-x re-builderして、いろいろ書いてみると現在のマッチ状況がプレビューされます。 実行中にC-c C-wすればその正規表現をコピーでき、C-c C-qで終了出来ます。emacsにはいろいろな正規表現syntaxがあるので、C-c C-iで切り替えもできます。 詳しくは以下の記事を見るとよいでしょう。 Emacsの正規表現編集モード re-builder とややこしいバックスラッ
http://shibayu36.hatenablog.com/entry/2012/12/29/001418#mc?u=ainame
ふとemacsの設定どのくらいになっているのかなーと思って行数数えたら wc -l init.el inits/* | grep total 2303 totalと、とんでもないことになっていたので、これまでどんな設定してたか思い出すことも兼ねて、emacs設定大掃除をおこなってみました。そこで「これは捨てられないなー」と思った設定を淡々と書いていきます。 ちなみに実際の設定ファイルはhttps://github.com/shibayu36/emacs/tree/master/emacs.d を御覧ください。 init-loader.el emacsでinit-loaderを導入してみた - $shibayu36->blog; の記事でも書きましたが、init-loaderは便利です。最近の構成としてはinit.elにはinit-loaderの設定だけ書いて、inits以下に全部設定置いて
zaw.zshで最近移動したディレクトリに移動する - $shibayu36->blog;
zshでanythingのような事ができるzaw.zshが便利だったので、いろいろ調べていたら最近のディレクトリに移動するというのも出来たので、紹介。 cdr まずzshを最新の4.3.15にすると、cdrっていうコマンドが出来てます*1。これを使うと最近行ったディレクトリに移動することができます。 .zshrcには以下のような設定をしておくと良いです。 autoload -Uz chpwd_recent_dirs cdr add-zsh-hook add-zsh-hook chpwd chpwd_recent_dirs zstyle ':chpwd:*' recent-dirs-max 5000 zstyle ':chpwd:*' recent-dirs-default yes zstyle ':completion:*' recent-dirs-insert both zaw-src-
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
