Vagrantfileで使うプラグインを定義する - Qiita
プロジェクトで利用するプラグインを明示しておきたい プラグインのインストールを自動化したい Vagrantで任意のGemをたくさん利用したい などの目的のために、vagrant-multiplug というVagrantのプラグインをつくりました。このプラグインをインストールした状態で、利用するプラグインの名前が定義されたVagrantflieを読み込むと、vagrant up や vagrant provision などのタイミングで自動的にプラグインをインストールしてくれます。 インストール 手元の環境に vagrant-multiplug をインストールします。 使い方 Vagrantfileの中で config.plugin.add_dependency(name, version = nil) という風に利用するプラグインを定義できます。今回は、例としてプロビジョニングツールの1つ
bashのTips色々 - Qiita
概要 bashの記法は独特なものが多く毎回ググってしまうのでまとめて(と言いつつまとまりがないですが。。。)おこうと思います。 ある程度まとまってからpostしようとか思ってたらごちゃごちゃになっちゃいました。 bashで使えるという意味なのでposixシェル共通のネタも混ざってます。 随時更新します。参考になれば幸いです。 参考 man bash リファレンスマニュアル Advanced Bash-Scripting Guide カッコ色々 bashでは色々なカッコがありますが、よく違いが分からず使っていたりするのでまとめてみます。 []と[[]] []はtestコマンドのaliasです。[[]]じゃないとできないこととしては、以下のようなものがあります。 空白を含む文字列をクォートしなくてOK var='abc 123' # []の中だとクォートしないとエラーになる [ $var =
Gitでやらかさないための事前予防策 - Qiita
Gitでやらかした時に使える19個の奥義を書いてやらかしたときになんとかリカバリできるようにした。 今回は、そもそもやらかさないようにしたいよねっていうお話。 コミット編 .gitignoreを細かく指定しておく .gitignoreを指定しておけば余計なファイルをコミットしちゃうことを予防できます 過去に似たようなプロジェクトがあるのならそれを流用しましょう。 ないのであれば.gitignore.ioで生成してそれをカスタムしましょう。 ワイルドカード指定やディレクトリまるごとの指定は副作用ある可能性があるので慎重に。 コミットメッセージのフォーマットを決めておく コミットメッセージのフォーマットを決めておけば書き直したいということも減ります コミットメッセージをやらかして直したいと思うことはよくあります。 そういうのって案外コミットメッセージが自由すぎることが問題だったりします。 ある
nginxのリクエストボディのバッファリングに関する問題とその改善策 - Qiita
nginxのデフォルトの動作ではクライアントから受け取ったリクエストボディをメモリにバッファリングするようになっています。 このメモリバッファのサイズはclient_body_buffer_sizeで変更することができ、リクエストボディのサイズがこのバッファのサイズを越えた場合はclient_body_temp_pathにファイルとして書き出されます。 ログレベルがwarn以上の場合はエラーログにa client request body is buffered ...という警告が出ます。 2015/03/29 14:02:20 [warn] 6965#0: *1 a client request body is buffered to a temporary file /etc/nginx/client_body_temp/0000000001, client: x.x.x.x, ser
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
React 雑感 - Qiita
3/22 (日) の rebuild.fm で React の話をしようと思っているが、その前に頭を整理するために React 雑感。雑感なので殴り書き。 React はこれ一つで複数の課題を解決しようとしている。そのため、人と議論してると話のコンテキストがぶれやすい。ざっくりは フロントエンドのプログラミングパラダイムを、サーバーサイドのような富豪的なスタイルに変える コンポーネント (雑に言うと独自タグ) 指向で UI を組み立てる ステートレスコンポーネントやメッセージパッシングで疎結合性を高めることにより、イベントの依存関係地獄を解消する。また結果的にテスタビリティを高める あたりだろうか。 React というと最初に目につくのは VirtualDOM だけれども、VirtualDOM は 1 や 3 を達成するために障害となった技術的課題を解消するためのテクニックであってそれ以上
Perl、Python、PHP、Rubyについて - Qiita
今更ながら、比較というか、意見を述べる。ただの自己満足と私的見解。 誕生の歴史的経緯 それぞれの言語が作られた経緯と目的を知ることは、その言語を使う意味で重要であると思う。 Perl前の時代 Perl前の時代、世の中にはC言語のようなコンパイル言語しかなく、コンパイルせずに処理ができるのはシェルやsedやawkぐらいしかなかった。ちょっとしたテキストを自動的に処理したいが、C言語とかで本格的に作成するような物ではないとき、人はみんな、シェルスクリプトとしてUNIXのコマンドを並び立てて処理していた。sortやtestなどの便利なコマンドがUNIXには用意されていたし、ちょっと複雑な処理でもsedやawkを駆使しして、何とかできていた。 しかし、シェルと言ってもBourne Shell系とC Shell系の二つがあったり、同じUNIXコマンドでもOSによってオプションが異なるなど、移植性が低
海の向こうにあるZabbixサーバの表示をWebサーバのチューニングだけで高速化する - Qiita
海外で展開しているサービスがある関係上各サーバの監視に利用しているZabbixサーバも海外にあるのですが、ほとんどチューニングされておらず、ZabbixのWebUIの画面をロードするのが遅くて遅くてしょうがないので頑張ってチューニングしてみた時の話です。 また、チューニング前後でダッシュボードのロードにかかった時間を計測してみました。 準備 まず、Google ChromeのDeveloper Toolsでキャッシュを無効にします。 チューニング前の状態 ZabbixはよくあるApache+mod_phpによる構成です。この状態でZabbixのダッシュボード(dashboard.php)にHTTPSでアクセスするとブラウザ左下のステータスバーにページのロードにかかった時間が表示されます。 2.7秒かかっています。すごく遅いです。体感でわかるくらい遅いです。 Zabbixが定期的にポーリング
C言語分かってなかった (I Do Not Know C) - Qiita
Dmitri Gribenko氏によるBlog記事 "I Do Not Know C" より訳出。原文および訳文のライセンスは CC BY-SA 3.0 に従う。 この記事の目的は、皆に（とくにCプログラマに）「C言語分かってなかった」と言わせることです。 C言語の死角は思っているよりも身近にあり、よくある単純なコードですら 未定義動作(undefined behavior) を含む可能性があると示したいと思います。 記事は質問に対する回答の形をとります。全ての例示コードは別々のファイルに分かれていると考えてください。 （訳注：Qiita/Markdown表現の制約から、読中ネタバレ防止のため文章順序を変更しています。前半には質問のみを、後半には質問と回答の対を訳出しました。） 質問編 1.
共通化でモチベーションと効率が低下した話 - Qiita
自分は普段ソーシャルゲームの開発に関わっていますが、群雄割拠のグリモバ全盛期にその開発を効率化するために社内ではいろいろな取り組みがなされました。そのひとつにアプリ別ではなく機能別のチームを作るということがありました。結果としてそれは失敗だったと言えるのでそのことについて書いていきます。 背景 当時のソーシャルゲームの主流はカードゲームで、クエスト・レイドをこなしつつガチャで引いたカードを合成して強化していくスタイルが一般的でした。そしてその多くがシステムはほとんど同じで見た目だけを変えた「柄替え」アプリでした。 その中で行われたのが二つの共通化です。 コードの共通化 今までのアプリでは元のアプリのソースからフォークするなどして別のプロジェクトとして独立させそれに対して各チームが開発を行うと言う感じでしたが、今回の共通化ではゲームのコアとなるロジック部分をサブモジュールとして分離し、各アプ
GCEのライブマイグレーションのすごさをまとめてみた #gcpja - Qiita
Google Cloud Platform (GCP)の英語ブログに、Google Compute Engine (GCE)のライブマイグレーション機能について解説記事がポストされた。個人的にもいくつかの大規模な案件でこの機能の能力に触れて、GoogleまじGoogleだなと思わされたし、GCPチームで実際に作った人たちと会うととても誇らしげに説明してくれる。熱いのだ。そこで、上記ブログ記事＋個人の経験をもとに簡単にまとめてみたい。 なお、以下の内容は個人の感想です！ Heartbleedバグの時もVM再起動なし GCEでは2013年12月より、ライブマイグレーションを利用したTransparent Maintenance（自動メンテナンス）という運用を開始している。これはつまり、VMを動かしたまま同一ゾーン内の別のサーバーへ移動することで、ハードウェアやホストOSのメンテナンスを勝手にや
OpenRestyのre.matchとstring.matchの性能差 - Qiita
OpenRestyで正規表現を利用する場合、 高機能なre.matchを利用したくなりますが Lua純正のstring.matchと比較してどの程度性能に差があるのかを調べてみました。 環境 Dockerfileを公開しているので、こちらで再現できると思います。 サーバ EC2: t2.medium ベンチマークコマンド re.matchがOpenRestyのコアライブラリのため HTTP経由でベンチマークを取っています。 cというパラメータを付けると正規表現のループ回数を指定できます。
consul membersの結果でbash補完する - Qiita
consulでホストを管理してる状態で、bash-completionでのsshの補完候補にconsul membersの結果を使いたかったんです。個別にsshすると最近は若者にdisられるそうですが、それはそれこれはこれとして… /etc/bash_completion の _known_hosts_real の定義を以下のように置き換えるととりあえずできました。共通のを上書きしたくなければ個別に .bash_profile などで再定義すればよいですね。 _known_hosts_real() { local members=$(consul members -status=alive | awk '!/Node/{printf("%s ", $1)}') COMPREPLY=( $( \ compgen -W "$members" \ ${COMP_WORDS[COMP_CWORD]
Chef-soloからItamaeに完全移行した話 - Qiita
※2016/04/24 追記 昨年末にItamae meetupで話した時のスライドリンクを追記しました。 Databag > itamae-secret の話やConsul連携の話が追加されています。 http://www.slideshare.net/tsuyoshitorii5/itamae-meetup-vol1public 現在自分が運用管理しているChef-soloプロビジョニングの仕組み 1 を Itamaeに移行した時のお話をしようと思います。 管理規模としては大規模ではなく、小〜中規模的なところかと思います。 （ロールによってレシピ切り分けたり、環境毎にレシピ用意したりなど…） 最初に: Itamaeについて https://github.com/itamae-kitchen/itamae 軽量なChef と考えればよいでしょう。 Chefの複雑さを取り除き、必要十分な部
consul-templateのイベント発火トリガーについて調査した - Qiita
ざっくり説明するとconsul-templateとは consulの様々なイベントを検知して 「テンプレート更新」 ＞ 「任意のコマンド実行」 してくれるツールです。 今回実現したかったのは consul-kvsの変更をトリガーにしてほげほげする ことです。 最初はconsul-templateがどういう条件でイベント発火するのかよくわからなかったのですが、 ドキュメントをよく見たらその辺りの仕様が記載されていたのでメモしておきます。 どういう条件でwatchしているのか？ 何の事はない話で、基本的には 読み込むテンプレート内で利用している値が変更されたかどうか を見ているようです。 素晴らしいですね。（※一部例外あり） 例: kvsのキーの値を監視する場合 以下のようなテンプレートで key を参照するだけでよいです。
Fluxフレームワーク Arda が気になる10の理由 - Qiita
Help us understand the problem. What is going on with this article? どうも、@armorik83です。 Fluxフレームワーク"Arda"、皆さんご存知ですか? 概念や思想を含めて大々的に発表されたのは、おそらく2015年2月16日（記事掲載時点でおととい）という新たなOSSです。 開発者は@mizchi氏。Qiitaの中の人 (Kobito)、魂が震えてる人、Reactの人として有名かと思いますが、個人的にはAngularJSが嫌いな人という認識です。 今回、そんなmizchiさんが開発されたフレームワーク"Arda"をあえて取り上げたい衝動に駆られたので、興味のある方はお付き合い下さい。 動機 気になった理由の前に、ここに至った動機を前置きします。ここ長いです。例のアレな感じです。 思い出話 私は2013年秋からAng
Go のクロスコンパイル環境構築 - Qiita
Go でクロスコンパイル Go の特徴であるクロスコンパイルの便利さと、その方法はよく語られますが、意外に「そのための準備工程」が知られてない気がしたので、ここで再度クロスコンパイル自体の便利さと、クロスコンパイル方法、そしてその準備方法を書いておきます。 クロスコンパイルの旨味 Go は、 1 つのソースコードから様々な OS 向けのバイナリを生成するクロスコンパイルをサポートしています。しかも、対象の OS が無いとビルドできないわけではなく、例えば Mac で Windows 用、 Linux 用、 Plan9 用のバイナリを一気に生成するといったことができます。 しかも、 32bit マシンで 64bit 用のバイナリを生成することもできます。 "Write Once Run Anywhere" でお馴染みの Java との違いは、 Java の場合は Class ファイルという形
Docker公式のmysqlイメージを使いつつ初期データも投入する - Qiita
メモです。 Docker公式のmysqlを使いつつ、初期データ投入するのに 少し手間取ったのでメモします （全部自前で書けばいいじゃん…というのは置いといて） ディレクトリ構造 ざっくりこんな感じを想定。 APP_ROOT/ app/ db/ setup.sql > create文とかinsert文とか fig.yml fig/ app/ Dockerfile mysql/ Dockerfile > ここから /app/db のSQLを使いたい ... やりたいこととしては、 app用とfig用のディレクトリがあって、 mysql用Dockerfileからapp用のディレクトリ配下にあるSQLファイルを使って 初期テーブル作ったりデータ投入したい。 実現している方法 fig/mysql/Dockerfile FROM mysql:5.6 # utf8サポート RUN { \ echo '[
VagrantでDockerが動く環境を一撃で作る - Qiita
メモです。 boot2dockerを使わず、 vagrant上に普通にVM立ててDocker使える環境を一撃で用意するコマンドです。 （VMはubuntu14.04） 一撃でインストール wget https://raw.githubusercontent.com/phusion/baseimage-docker/master/Vagrantfile && vagrant up vagrant ssh ... $ docker run busybox echo 'Hello Docker!' Unable to find image 'busybox:latest' locally df7546f9f060: Pull complete ea13149945cb: Pull complete 4986bf8c1536: Pull complete 511136ea3c5a: Already
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gitでやらかした時に使える19個の奥義 - Qiita
