本項は Berkshelf Workflow (2014/05/27) の和訳です。 この記事(訳注:原文)は https://sethvargo.com/berkshelf-workflow/ からのクロスポストです。 Berkshelfは2つの基本的な仮定に基いて動作します。 それぞれの Cookbook は個別にパッケージ化されてバージョン付けされた構成物である。 依存関係APIを公開および、または Berkshelf API によってインデックス化できる中央集権的な構成物ストアを持つ。 それぞれの Cookbook はインフラストラクチャの個々の単位であり、そのように扱われるべきです。 2つ以上の Cookbook を繰り返し実行する必要のある状況が連続してあるとしても、それらの状況はとても稀なものでしょう。 この記事では、BerkshelfとGitHubのフローを用いるような状況
弊社では開発には主に Rails を使うのですが、いくつかのサイトでは WordPress を使っています(この kray.jp もそうです)。 先日その内の一つをアップデートしたのですが、今後のアップデートをし易くするために、運用手順を一新してみました。 今回はそれを紹介したいと思います。 before 以前はサイト全体を git リポジトリにコミットして、それを capistrano でデプロイする、という手順で運用を行っていました。 これには以下のような問題がありました。 WordPress コア、プラグインのアップデートがしにくい WordPress やプラグインのアップデート時に、データベースを更新する場合があるため、本番環境でも管理ページから更新する必要があります。 そのため、アップデート作業は各環境で行わなければならず、リポジトリ管理との相性がよくありません。 デプロイにコマ
2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。本件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 本件に関する詳細は、プレスリリースをご確認ください。
http://csswizardry.com/2014/07/hacks-for-dealing-with-specificity/ 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約4時間前 Harry Robertsがブログで、CSSのプロジェクトをうまくスケールさせるためには、詳細度の影響をうまく抑えて、メンテナンス性を高めることがポイントだと解説しています。 どれだけ思慮深くソースの順や継承関係を整理しても、詳細度がトリガーになった上書き起きると、それまでの努力が台無しになる。詳細度のタチが悪いのはオプトアウトできないこと。 であるが、その悪影響をうまくコントロールする策としては、 CSSにおいてセレクタとしてIDは使わないこと。クラスを使うことを上回るメリットはない。そもそも、IDでできることはクラスで
Bitbucketのprivate repositoryとJenkins使ってCIできる環境を作った。 主に以下の記事を参考にすれば解決だったが、自分用にメモを残す。 URL: http://qiita.com/ka_/items/acd019118eab298101f6 【環境】 Jenkins JenkinsはさくらVPSのCentOS 6.3上で動いている。 ※yumでインストールしたので、OS上にJenkinsユーザが追加されている状態 Git Pluginは既に追加済み。 ※インストール時、以下のURLを参考にした http://snickerjp.blogspot.jp/2013/10/yum-Install-Jenkins.html http://futurismo.biz/archives/1348 Bitbucket Gitでprivate repositoryを作成済み
参考:http://oss.fulltrust.co.jp/?p=537 ↑のサイトの方が最新版のDockerを動かす方法についてこちらに載せておられるそうです. 以降は全部rootで実行する. リポジトリの設定とdocker-ioのインストール # wget -P /etc/yum.repos.d http://www.hop5.in/yum/el6/hop5.repo # yum install xz -y # yum install docker-io -y 起動スクリプトの作成 /etc/init.d/lxc-docker このファイルを配置し,下記コマンドを実行する. なお,↑のファイルではrepositoryの保存場所を/shareに変更している (デフォルトだと/var/lib/docker に作成される.デフォルトに戻すのであれば,start 及び restartのところの
以前の記事だと最新版のDockerは利用できません。 また、現時点の最新版は0.6.6ですがまたすぐ新しくなるかもしれませんけど。 名前付きのコンテナやDockerファイルで指定したポートをdocker runの時に上書きできたりするので最新版を利用したい場合はこちらの手順でDockerの最新版を使いましょう。 https://github.com/sciurus/docker-rhel-rpm のものを利用してますがそのままの手順だと無理ですので若干変更しています。 時間かかるのとコンパイルが面倒であればダウンロードしてインストールすればすぐにDocker0.6.6が利用できるでしょう。 ①SELinuxの無効化 sed -i.bak "s/\(^SELINUX=\).*/\1disabled/" /etc/selinux/config ②IPforwardの設定 sed -i.b
このページではvimエディタにより自動的に作成される、 スワップファイル、バックアップファイル、viminfoファイルがどのような役割を持ったファイルであるか、 ファイルの出力先を変更するには、ファイルの生成を止めるには、どうすればよいか、 について説明します。 (Windows, Mac) 概要 このページではvimエディタにより自動的に作成される、 スワップファイル、バックアップファイル、viminfoファイルがどのような役割を持ったファイルであるか、 ファイルの出力先を変更するには、ファイルの生成を止めるには、どうすればよいか、について説明します。 .swpファイルはどのような役割をもったファイルか .swpファイルはスワップファイルと呼ばれています。 スワップファイルはアプリケーションのクラッシュに備えて、 vimエディタでの編集開始時に作成され、編集後に削除される編集情報の記録フ
この記事は Vim Advent Calendar 2012 286日目の記事です。 :NeoBundleLazy に autoload機能が搭載されたのは、このAdventCalendarが始まって間もなくのことでした。 「立て!立つんだビムー!」 - sorry, unimplemented neobundle.vim の遅延処理で Vim の起動を高速化する - C++でゲームプログラミング これはVimの鈍重な立ち上がりに喘いでいたプラグイン重層派が、Vim本来の軽量な立ち上がりに立ち返り、スパルタンに対する反攻の狼煙を上げるかのように見えました。 しかしLazy autoloadを手に沸き上がる重装派に、恐るべき困難が待ち構えていたのです。 [設定がすごく面倒くさい] NeoBundleLazy設定の書式 NeoBundleLazy <リポジトリ名>, {'autoload':
vimの起動時間はvim --startuptime /tmp/vim.logみたいにすると/tmp/vim.logに細かくログが出る。BenchVimrcを使うと.vimrcの行単位で処理時間がわかるようになる。 今までvimの起動に300msくらい掛かってて特に気にしてなかったんだけど、ふとEDITOR="vim -u NONE" git commit --amendしてみたら、いつもの起動に一拍置く感じがなくなって一瞬で起動してユーザーエクスペリエンスがかなり変わったので軽量化してみようと思った。 とはいっても既にそこそこチューニングしてあるし、100ms以下になるくらい速くするには入れてるプラグインを削る必要があって、そこまでして速くしてもあまり意味がない。gitのコミットメッセージの編集では-u NONE(素のvim起動)でもまあ充分だけど、普通にファイルを編集したいときはないと
はじめに: 「素のVim」から「プラグイン付きのVim」へ Vimを使い始めた当初、僕は.vimrcの設定だけで実現できる機能に限定した方が「ポータブルなVimスキル」になる気がしていたので、プラグインは全く使わずに「素のVim」を使っていました。 しかし、Vimを使って実務でRailsを開発し始めるとそんなことも言ってられなくなりました。 やはり素のVimだけでは限界があります。 Vimを使って効率よくRailsを開発するためにはプラグインに頼らざるを得ません。 ネットの情報などを参考にしてあれこれプラグインを入れてみましたが、これは手放せないというプラグインもあれば、思ったほど使わなかったというプラグインもあります。 今回の記事では前者のような「これは手放せない!」と僕が考えているプラグインに限定して紹介していきます。 また、後半ではプラグインを使わない.vimrcの一般的な設定につい
カーソル位置のコンテキストによって自動的にバッファの filetype を切り替える precious.vim ですが、indentLine を使用していると filetype を切り替える度に indentLine のハイライトが消えてしまいます。 これは以下のように設定することで回避する事が可能です。 augroup precious-indentLine autocmd! " precious.vim が filetype を切り替える度に indentLine をリセットする autocmd User PreciousFileType IndentLinesReset augroup END これで precious.vim が filetype を変えても indentLine のハイライトはそのままになります。
最近、精力的にPostgreSQL関連の検証や技術情報の公開をしている日本HPさんから、「PostgreSQL Internals」という技術文書がPDFで公開されました。 日本HP ITサービス「HP OPEN SERVICES」 http://h50146.www5.hp.com/services/ci/opensource/ 上記ページの下の方に「PostgreSQLエンジニア向け!ストレージ内部構造および内部動作検証報告」というタイトルのPDFファイルをダウンロードすることができます。 PostgreSQLエンジニア向け!ストレージ内部構造および内部動作検証報告 http://h50146.www5.hp.com/services/ci/opensource/pdfs/PostgreSQL_Internals.pdf 章レベルで目次を抜き出すと以下のような内容になっています。 本文
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 デメテルの法則 別名最小知識の法則。デメテルは、豊穣の女神。アスペクト指向などの研究であった「デメテルプロジェクト」に由来。 基本的な考え方は、任意のオブジェクトが自分以外(サブコンポーネント含む)の構造やプロパティに対して持っている仮定を最小限にすべきであるという点にある。 単純化して説明すると、オブジェクトの"メンバーのプロパテ
How to Quit Multiple iPhone Apps Simultaneously in iOS with Multitouch If you ever need to quit out of more than one app on the iPhone, or quit a bunch of apps quickly in iOS, using a handy multitouch swipe gesture at the iOS multitasking screen is enough to quit apps simultaneously. This works really well to quickly clear out the multitask bar of all running apps if you need to for whatever reaso
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く