git-svn
は使う必要がないと言う記事。
Git や GitHub で管理する WordPress プラグインを公式の SVN リポジトリに送る方法として git-svn
を使うワークフローが多く紹介されている。
これらの問題点は以下の通り。
git svn fetch
)際、一本の巨大なリポジトリ・ツリーを頭から検索するため、非常に時間がかかる。git-svn
の制限により、サブモジュールが扱えない。蛇足だが、上記最後の記事には 「公式リポジトリを単にリリース用に使うだけなら、せめて git rebase -i
か git merge -squash
でやってくれ」 という Otto さんの嘆き が書き込まれている(Otto さん は WordPress のプラグイン開発で有名な人)。
一方、Git / GitHub を主とする開発では、
SVN クライアントとして動作する git-svn
を使うと、git リポジトリと同時に SVN のリポジトリも同時に生成・管理することになるが、上記を前提とすれば、git-svn
を使う必要がない。
基本的には、公式サイトの記事 How to Use Subversion に書かれている手作業をスクリプトで自動化するイメージ。
現在見つけたスクリプトは以下の2系統。どちらもリリース・バージョンを GitHub に push する直前からの利用を想定している。バージョン番号に応じたタグ付けなど、ワン・コマンドによる自動化が可能。一時的に SVN リポジトリを作成するが、残す必要がないので、その都度削除するという潔さ。スクリプトの動作も軽い。
歴史を含めて既存の SVN リポジトリから git にクローンを作成する clone-from-svn-to-git.sh
と git で管理しているファイル群を SVN に上げる deploy-plugin.sh
がメイン。前者は git-svn
のインストールが必要だが、最初から GitHub で開発している場合には後者だけを使えば良く、git-svn
のインストールは不要。
assets
への転送、add-textdomain.php
や makepot.php
による言語ファイルの更新(Otto さんの記事 Language Packs 101 – Prepwork を参照)も含まれており、至れり尽くせりのスクリプト。
また、マークダウンで書かれた README.md を readme.txt に変換する readme-converter.sh
や、プラグインの zip アーカイブを作成する create-archive.sh
もあり、すべての作業内容が網羅されている。
詳しくは、以下の紹介記事を参照のこと。
deanc / wordpress-plugin-git-svn から派生したスクリプトで、サブモジュールや assets
の転送、途中で削除されたファイルなどの対応もサポート。
私はこのスクリプトを元に自分の構成に合わせて修正、利用した。
いずれにしても盲目的に実行するのではなく、自分の環境に合っているかどうか、スクリプトの各行を吟味して実行するが吉。さもないとトラブルの際、うろたえることになる。
またまた蛇足だが、Create Git Repositories for Plugins and Themes には公式リポジトリの GitHub 化が提案されている。WP.org のアカウントとリポジトリのアカウントを同一にしているのをどうするかが一番の問題点と見た。
]]>コマンドラインでは、pygmentize -L lexers
で一覧を出力。
1 2 3 4 5 6 7 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 6 |
|
1 2 3 4 |
|
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 7 8 |
|
1 2 3 4 5 6 |
|
1 2 3 4 5 |
|
rdiscount にしろ kramdown にしろ、Octopress のスニペット記述方法は4通り。
シングルのバッククォート `
で囲む。ちなみに、n個のバッククォートを表すには n+1個のバッククォート(と1つの空白)で囲むとのこと。
行頭をタブ、もしくはスペース4文字でインデントさせる。
3連のバッククォート ```
で囲む。
1 2 3 |
|
{% codeblock TITLE lang:LANG %}
〜 {% endcodeblock %}
で囲む。
忘れがちなのが {% ... %}
が解釈されてレンダリングされないようにする書き方。次の様に raw ブロックで囲む。
{% codeblock [タイトル] [lang:言語] %}
{% raw %}
{% ... %}
{% endraw %}
{% endcodeblock %}
ちなみに 3. と 4. は Pygment でレンダリングされる。
rake generate
時に Liquid Exception: invalid byte sequence in UTF-8 in atom.xml
というエラー。
どこかで日本語の扱いをヘクってると思われるが…
原因は色々あるんだろうけど、ウチの場合は markdown
を rdiscount
から kramdown
に変えることでエラーが出なくなった。
1
|
|
1 2 3 4 5 6 7 |
|
でもって bundle install
。あるいはいっそ
1
|
|
ただし Markdown パーサーを変えることになるので、方言には要注意。
]]>これを Octopress でも試してみた。
_config.yml
に以下を追加。
1 2 3 |
|
記事に {:TOC}
を書き込むと、その部分が目次に置き換わる(TOC
は Table Of Contents
の略)。
1 2 |
|
見出しに日本語を使うと、generate
時にエラーが出る。
Liquid Exception: incompatible character encodings: UTF-8 and ASCII-8BIT in atom.xml
この問題は、Issue #555 で報告されている。このパッチ の通り、
gems/jekyll-0.12.0/lib/jekyll/converters/markdown.rb
を対策する。
1 2 3 4 5 6 7 8 9 |
|
ただし force_encoding('utf-8')
が気に入られず、取り込まれていない。
とりあえずのモンキーパッチを当てる方法。
escape
メソッドで gsub
が未定義だということ。
/Users/****/.rvm/rubies/ruby-1.9.3-p374/lib/ruby/1.9.1/uri/common.rb:304:in `escape': undefined method `gsub' for ["Ruby", "jekyll/hyde"]:Array (NoMethodError)
from /Users/****/.rvm/rubies/ruby-1.9.3-p374/lib/ruby/1.9.1/uri/common.rb:638:in `escape'
from /Users/****/.rvm/gems/ruby-1.9.3-p374/gems/jekyll-0.12.0/lib/jekyll/post.rb:140:in `block in url'
...
common.rb
の該当箇所は、
str.gsub(unsafe) do
post.rb
の該当箇所は、
"categories" => categories.map { |c| URI.escape(c) }.join('/'),
どうやら、categories
に配列 ["Ruby", "jekyll/hyde"]
を指定しているの原因。
URI.escape(c)
の c
を明示的に String
に変換する。
"categories" => categories.map { |c| URI.escape(c.to_s) }.join('/'),
う〜ん、これでいいのかなぁ(いいわけない!)。カテゴリのアーカイブを作る時に Ruby/jekyll/hyde
になるように、ちゃんと考えなきゃ…。
.
├── _deploy/ # デプロイ時の静的ファイル群を保存しておく
├── _includes/ # 他からインクルードされるテンプレート部品
│ ├── asides/ # サイドバー用各種テンプレート部品
│ ├── post/ # 個別記事ページ用各種テンプレート部品
│ ├── libs/ # 小さなテンプレート部品
│ ├── js/ # 小さな js 部品
│ ├── css/ # 小さな css 部品
│ │ └── pygments/ # pygments 用 css
│ └── bootstrap-2.1.1/ # bootstrap の部品
├── _layouts/ # ページ用テンプレート
├── _plugins/ # 拡張用プラグイン(参考用)
├── _posts/ # 記事
├── _site/ # ここに一時的な静的ファイル群が作られる
├── assets/ # サイト用リソース
│ ├── bootstrap-2.1.1/ # 必要な bootstrap 部品をインクルードする
│ ├── css/ # 必要な css 部品をインクルードする
│ ├── js/ # 必要な js 部品をインクルードする
│ ├── ico/ # ファビコンなど
│ └── img/ # サイト用画像
├── blog/ # ブログ用テンプレート
└── project/ # プロジェクト用テンプレート
_config.yml
の設定url
、baseurl
GitHub プロジェクトページの場合は、次のように指定する。
url: http://USERNAME.github.com/REPOSITORY
baseurl: /REPOSITORY
paginate
、columns
トップページでの表示記事数と、先頭記事以外のカラム数。
date_format
使える書式は、Module: Liquid::StandardFilters — Documentation for liquid (2.2.2) (GitHub の Liquid バージョンと同じ) を参考に。
truncate_len
トップページで紹介する記事の表示文字数。
navbar_list
次のように {name, link}
のペアでナビゲーションバーのメニューを定義。
navbar_list:
- name: Blog
link: /
- name: Project
link: /project/
- name: About
link: /about.html
サブメニューは、dropdown: &dropdown
を使い、次のように定義。
navbar_list:
- name: Blog
link: /
dropdown: &dropdown
- name: Categories
link: /blog/categories.html
- name: Tags
link: /blog/tags.html
これ以上の多階層化は、_includes/navbar.html
に直接マークアップするのが吉。
またリンク部をハイライトするためには、テンプレート側の YAML ディレクティブ group
に、親メニューの name
を指定する。以下は、/blog/categories.html
の例。
---
layout: default
title: Archives
group: Blog
---
pygments_style
Pygments - Python syntax highlighter の Online demo で、カラーリングを確認するのが吉。
カラーリングに関しては、次のサイトもご参考。
excerpt
トップページ (index.html) で表示する、記事の要旨。
thumbnail
トップページ (index.html) で表示する、サムネイル画像。
comments
3rd パーティー製コメントシステムを有効にする。
published
true
で記事公開、false
で保留。
category
カテゴリは、配列 [...]
を使って複数指定可。この場合、左から順に親子関係となる。
tags
タグも配列を使用可能。カテゴリとは異なり、親子関係はない。
トップページ (index.html) の表示時、_includes/libs/truncate_xxxx
で以下の処理を実行する。
excerpt
の処理記事の YAML ディレクティブにコレがあれば、要旨として表示する。
<!--more-->
の処理safe: false
な jekyll 環境では、_plugins/postmore.rb
を使って <!--more-->
で分割した文字列の前半をレンダリングする。一方プラグインが使えない GitHub ページ上の jekyll では、次のように Liquid で、<!--more-->
から記事の終わりまでコメント化し、擬似的な more 機能を実現する。
{% if post.content contains '<!--more-->' %}
{{ post.content | remove:'-->' }}-->
{% endif %}
テキストとしては送られるが、高々数十キロバイトだろうから、目をつぶってもらうというわけである。
余談だが、次のような Liquid コードも試してみた。が、適当な1バイトの区切り文字 SEP
をセットできないのでダメ。何か良い案はないだろうか?
{{ post.content | replace_first:'<!--more-->', SEP | split:SEP | first }}
<--more-->
より手前を excerpt
とする postmorefilter
プラグイン 。<!-- more start -->
~ <-- more end -->
間をコメント化して excerpt
とする方法。excerpt
および <!--more-->
が共にない場合、先頭の truncate_len
だけ文字を表示する。GitHub 上の jekyll (バージョン 2.2.2) の場合、truncate
フィルタがユニコードに対応しておらず、単なるバイト数でカウントされてしまうため、日本語が文字化けする可能性がある。そこでかなりトリッキーな方法ではあるが、末尾の文字コードを調べ、適切な所で丸める処理を Liquid で実装した。
Template Data - mojombo/jekyll Wiki にある通り、テンプレートからは site.categories
(ハッシュ) や page.categories
(配列) などでアクセスすることが出来る。_includes/libs/list_categories
と _includes/libs/list_tags
にそれらの扱いを集約すると共に、両者をフラグで使い分ける仕様とした。
またカテゴリは、親子関係を表す配列で提供されるのが jekyll の仕様である。例えば、_post/1970-1-1-hello-world.md
の YAML ディレクティブに次のようなカテゴリが指定されていたとする。
title: "hello world!"
category: [parent, child]
もし、_config.yml
のパーマリンク設定が permalink: /blog/:categories/:title.html
であった場合、上記の記事は、次のように展開される。
/blog/parent/child/hello-world.html
コレのコンフィグレーションを色々できるようにしたことが複雑化の原因。不要なら一切を削除するのがお勧め。
assets/bootstrap-X.Y.Z/
下のファイルが、_includes/bootstrap-X.Y.Z/
下の部品をインクルードする構成とした。
例えば、assets/bootstrap-2.1.1/js/bootstrap.custom.js
は、次のように bootstrap の js 部品をインクルードする。
---
---
{% include bootstrap-2.1.1/js/bootstrap-carousel.js %}
{% include bootstrap-2.1.1/js/bootstrap-collapse.js %}
{% include bootstrap-2.1.1/js/bootstrap-dropdown.js %}
{% include bootstrap-2.1.1/js/bootstrap-tab.js %}
{% include bootstrap-2.1.1/js/bootstrap-transition.js %}
コレのポイントは、YAML ディレクティブが空でも jekyll がちゃんと処理してくれて、自分自身のファイル形式に変換してくれること。
css ファイルは、web-based Customizer から適当なモジュールを選択し、ダウンロードしたファイルで代用している。そのうち LESS をインストールし、モジュール化したい。
_config.yml
の設定。bootstrap
custom
を指定すると /assets/bootstrap-X.Y.Z/
のカスタムファイルを用いる。この場合、_includes/bootstrap-X.Y.Z/
から必要な部品をインクルードする。original
あるいはそれ以外では、BootstrapCDN にアップされているファイルを使う。
bootstrap_ver
バージョン X.Y.Z を指定。
bootswatch_ver
テーマファイルのバージョンを指定。
responsive_bp
ナビゲーションバーを折り畳みタイプにする、メディアクエリ上のブレーク・ポイント。assets/bootstrap-X.Y.Z/bootstrap-responsive.custom.css
に、この値をレンダリングする。
jquery_ver
本当は 1.8.x を使いたいんだけれど、私のスマホ (Optimus L-01D/Android 2.3) のネイティブなブラウザが落ちる。Firefox なら大丈夫。たぶんブラウザのバグ (だと思う)。
Rakefile
のエントリーpreview
rake preview
もしくは rake
で http://localhost:4000/ でのテストが可能。
post
新規投稿。次の書式が可能。
rake post title="title of my article"
rake post["title of my article"]
page
新規ページの作成。
rake page name="about.html"
setup_remote
記事の公開に git push
を使う場合の、リモートの設定。push
するリモート側のブランチは、Rakefile 中のグローバルなハッシュ CONFIG['deploy_branch']
で指定する。
deploy
setup_remote
で設定したリモートサーバに記事を git push
する。_site
に出来た静的ファイルは、プレビュー中にも変わってしまうため、_deploy
ディレクトリにコピーし、デプロイ用ファイルを確定させる。
Gemfile
関連gem 'jekyll'
RubyGems に現在公開されている jekyll は pygmentize ごとにプロセスを起動するため、処理時間がかかるとのこと (情報源:pygmentsが原因でjekyllが重くなってた - hokaccha.hamalog v2)。GitHub 上の最新バージョンを使う方が吉かも。
gem 'gsl'
jekyll のソースを読む限り、lsi: false
を指定すると、単に最新の記事数件を 「関連する記事」 とするだけである。lsi: true
だと、少しはマシになるらしいが、処理時間がかかる模様。gsl を使えば、10倍高速化できるとのこと (未確認)。
gem 'rake'
いつの間にか、システムにインストールしたバージョンを 0.9.2.2 に上げてしまったようで、Octopress が指定しているバージョン 0.9.2 と競合するようになった。Octopress 側を bundle exec rake ...
で対応しているが、そもそも各アプリごとに gem を分けた方が良いかもしれない。
[[ruby]最初に知っておけば良かったbundlerの使い方 rails編 | Into my web](http://kozo002.blogspot.jp/2012/01/rubybundler.html) |
Module: Liquid::StandardFilters - Documentation for liquid (2.2.2)
GitHub 上の jekyll バージョン で使える、Liquid 2.2.2 の標準フィルタに関するマニュアル。
30分のチュートリアルでJekyllを理解する
1ステップづつ、実例を交えながら解説されていて、Jekyll に関しては、ココが一番詳しい。プラグインの作り方がお役立ち。Jekyll Wiki Pluginsの説明ページを勝手に翻訳しました が分かり易い。
jekyll+github pagesでブログを作る « fragments
git、jekyll のインストール、jekyll bootstrap のインストールと構成、記事作成、GitHub への公開。pygments による Syntax highlight の説明アリ。
ruby と jekyll と jekyll-bootstrap で静的サイトを作る - KRAKENBEAL RECORDS
インストールから公開までの概要。末尾の参考文献がお役立ち。
Jekyll | CSS Radar | Mini Books For Front End Developers
jekyll の基本的解説。Rakefile の作り方がお役立ち。
LESS - CSSプリプロフェッサ | CSS Radar | Mini Books For Front End Developers
LESS の使い方を含む解説。less.js を使った開発時の使い方と、リリース用のコンパイル方法が解説されている。
Using Twitter Bootstrap with Jekyll - Brizzled
CSS の生成を自動化する LESS 用 Rakefile の書き方など。
別に SEO とか気にしてないんだけど、どういうキーワードで皆さんが 見てくれているかをあらためて知り、ちょっと幸せな気分 ♪
ウェッブマスターツールが指定する確認用ファイルを _deploy
ディレクトリにコピーし、リモートにプッシュすると、一時的にはうまくいく。
cd _deploy
git add google225275b4fc00ad7d.html
git commit -m "add google site verification file"
git push
GitHub だと、このファイルにアクセスできるようになるには、ちょっとタイムラグが ある感じなので、ちゃんとアクセスできるようになってから、「確認」すべし。
ただしこの方法では、次回記事をデプロイした時に確認用ファイルが消されてしまう。 Rakefile を書き換えれば良いのだけれど、お手軽には次の「別な方法」が簡単。
メタ タグ - ウェブマスター ツール ヘルプ に
従って、source/_includes/head.html
にメタタグを記述し、ページを再生成後、デプロイするだけ。
vi source/_includes/head.html
... メタタグ <meta name="google-site-verification" content="..." /> を挿入
rake generate
rake deploy
]]>Emoji って、英語になってるんだ! Manga と同じだネェ。日本のガラケー文化もなかなかじゃん。
ってことで、GitHub の Issues とかで使える絵文字出し方。例えば、「:smile:」とやれば 、プロジェクトが完成してお祝いしたいときには、「:beer:」で となるわけ。
最初のアナウンスは、2011年3月11日の GitHub Blog の記事。
どこで使えるでしょうか?的なコメントになっているが、要はコミュニケーション手段である Issues のコメント欄とか、Gist の Markdown とかで使える。
で、これの元になっているのが、arvida/emoji-cheat-sheet.com と、絵文字コードを簡単にコピペできるチートシート。
で、Gist に投稿すると、こうなる。
]]>Git - the stupid content tracker
の意味がよく分かる。
ということで、まずは用語の理解から。
blob
ファイルの中身を表すオブジェクト
tree
ディレクトリの中身の一覧とどのファイルがどの blob に対応するかを表すオブジェクト
commit
ルートツリーおよびすべてのメタデータへのポインタを含むオブジェクト
tag
特定のコミットへのポインタを含むオブジェクト
(出典:Pro Git - Pro Git 3.1 Git のブランチ機能)
上の図で、commit 直下の blob は、カレントディレクトリ .
と考えると分かり易い。
全てのオブジェクトには、フラットな構造のリビジョンがある。リビジョンからオブジェクトを指定可能。
SHA-1ハッシュ
オブジェクトの内容に応じて算出されるチェックサム。40字もしくは7文字程度の16進数で表す。
特定の commit オブジェクトを表すシンボルも使用可能。
HEAD(変更の基準となるコミットの名前)、
ORIG_HEAD(HEAD に対する変更を行う前の HEAD)、
FETCH_HEAD(git fetch
したリモート・リポジトリのブランチ)、
MERGE_HEAD(git merge
実行時のマージ元のコミット)、
CHERRY_PICK_HEAD(git cherry-pick
実行時のコミット)。
<refname>
master
、heads/master
、refs/heads/master
など。
<refname>@{<date>}
master@{yesterday}
、HEAD@{1 month 2 weeks 3 days 1 hour 1 second ago}
、HEAD@{1979-02-26 18:30:00}
など。
<refname>@{<n>}
n だけ前の参照。HEAD@{1}
など。<refname> の省略は現在のブランチ。
<rev>^ あるいは <rev>^<n>
<rev> から見て、commit オブジェクトを親→兄弟へと世代順・生成順にたどる場合の1番目、あるいは_n_番目のオブジェクト。HEAD^
は HEAD^1
と同じ。
<rev>~<n>
<rev> から見て、commit オブジェクトを直系の親だけをたどった場合の_n_番目の親。
<rev>{<type>}
指定リビジョンから参照できるオブジェクト。HEAD^{tree}
、v0.9^{commit}
など。type を省略すると?
<rev>{/<text>}
指定リビジョンからさかのぼり、commit メッセージに正規表現 text を含む最初のオブジェクトを参照する。
:/<text>
commit メッセージに正規表現 text を含む最初のオブジェクトを表示。:/!
で続けて検索。
<rev>:<path>
指定リビジョンの blob(ファイル)あるいは tree(ディレクトリ)を参照する。HEAD:README
、master:./README
など。
G H I J
\ / \ /
D E F
\ | / \
\ | / |
\|/ |
B C
\ /
\ /
A
A = = A^0
B = A^ = A^1 = A~1
C = A^2 = A^2
D = A^^ = A^1^1 = A~2
E = B^2 = A^^2
F = B^3 = A^^3
G = A^^^ = A^1^1^1 = A~3
H = D^2 = B^^2 = A^^^2 = A~2^2
I = F^ = B^3^ = A^^3^
J = F^2 = B^3^2 = A^^3^2
<object>
あらゆるタイプのオブジェクトの名前を表す。
<blob>
blob(ファイル)オブジェクトの名前を表す。
<tree>
tree(ディレクトリ)オブジェクトの名前を表す。
<commit>
commit オブジェクトの名前を表す。
<tree-ish>
tree、commit あるいは tag オブジェクトの名前を表す。
<commit-ish>
commit あるいは tag オブジェクトの名前を表す。
<type>
オブジェクトのタイプ。blob
、tree
、commit
あるいは tag
。
<file>、<path>
ファイル名。
<tag>
有効な tab 名。即ち refs/tags/<tag>
。
<head>
有効な head 名。即ち refs/heads/<head>
。
HEAD
現在のブランチの head。
一文字系:
-a
とか -h
とか。
単語系:
--all
とか --help
とか。
ファイル名の指定:
--
以降に指定することで、直前のオプション引数と区別する。
内部の実例を見ると、イメージがわき易いかも。
$ tree -F .git
.git/
├── COMMIT_EDITMSG
├── FETCH_HEAD
├── HEAD
├── ORIG_HEAD
├── branches/
├── config
├── description
├── hooks/
│ ├── applypatch-msg.sample*
│ ├── commit-msg.sample*
│ ├── post-update.sample*
│ ├── pre-applypatch.sample*
│ ├── pre-commit.sample*
│ ├── pre-rebase.sample*
│ ├── prepare-commit-msg.sample*
│ └── update.sample*
├── index
├── info/
│ └── exclude
├── logs/
│ ├── HEAD
│ └── refs/
│ ├── heads/
│ │ ├── gh-pages
│ │ └── master
│ └── remotes/
│ └── origin/
│ └── gh-pages
└── refs/
├── heads/
│ ├── gh-pages
│ └── master
├── remotes/
│ └── origin/
│ ├── HEAD
│ └── gh-pages
└── tags/
└── v1.0.1
$ git show-ref
0acbba3b5bd52b9e169077a997bcf5d5f37faa96 refs/heads/gh-pages
8403eb93d7e03ca02275d4027d9deadc51dfe37f refs/heads/master
8403eb93d7e03ca02275d4027d9deadc51dfe37f refs/remotes/origin/HEAD
0acbba3b5bd52b9e169077a997bcf5d5f37faa96 refs/remotes/origin/gh-pages
8403eb93d7e03ca02275d4027d9deadc51dfe37f refs/remotes/origin/master
934f4f895321735829e4d8339c5963f54327bcc1 refs/tags/v1.0.0
d43e1ccc84a3930597d50c0f8e6da614c0d05a5a refs/tags/v1.0.1
$ git cat-file -p HEAD^{tree}
040000 tree 67036e7bea736aa461bf7e737b74925db941999f PIE-1.0beta5
100644 blob 91b43a3e6572f2ffbe3b1d777d04104a976be686 README.md
040000 tree 8041e8916721cbe67da22fb03d668a8e2976d22a css
040000 tree 3857137c4df661ac2b60461ff6ec7e393b54c638 google-code-prettify
100755 blob 49b085dd91dfafe28507007e8eb4bac44b20080c index.html
040000 tree 436ea11960214eac6f68c3b0f935a078903d7062 js
結果は、どれも動作しない…
jekyll には site.categories
や site.tags
という Template Data があるが、単に Octopress に tags
が実装されていないだけだと思う。
ということで、3番目のコードを動くようにしてみた 。文字の大きさをログスケールで変えたりしていて、イイ感じ。
他にも検索してみると、台湾サイトの記事「あなたのOctopressの記事のカテゴリを高めるために」(by Google 翻訳)で、サイドバーにタグクラウドを作るコード(ライセンスは非表記)が紹介されているのを発見。中国系 Octopress サイトでは結構使われている様子。
で、試してみたが、rake preview
を実行時、3秒に1度 regenerate
してしまい調子が悪い。generate
時にテンプレートの HTML ファイルをダイレクトに生成しているため、preview
時の監視プロセスにより更新判断され、再 generate
されてしまうのだ。
ということで、この無限地獄を解消すべく、Octopress プラグインのルールに従って作り変えてみた。
{% tag_cloud [counter:true] %}
{% category_list [counter:true] %}
true
を指定する1 2 3 4 |
|
1 2 3 4 |
|
1 2 3 |
|
# list each of the sidebar modules you want to include, in the order you want them to appear.
# To add custom asides, create files in /source/_includes/custom/asides/ and add them to the list like 'custom/asides/custom_aside_name.html'
default_asides: [custom/asides/tag_cloud.html, custom/asides/tag_cloud.html, ...]
1 2 3 4 5 6 7 8 9 |
|
tagcloud
)に上記ファイルを追加したもの。自分の Octopress リポジトリ内でリモートリポジトリとして追加し、tagcloud
ブランチから追加すべきファイルをチェックアウトする(と出来るハズ)。作者に「GitHub に載せたんだけど、ライセンスとかどう?」と聞いたら、「MIT でいいよ」とのこと。
ただ Ruby という言語を触るのは今回が初めてなため、無駄の省き方も分かっていない。さらに、今回のようなプラグインを、Git という仕組みを使ってどうやったら本体にスムーズに導入できるのかも課題。
老練な Git 職人さん、白馬に乗った Rubiest さんに突っ込んでもらえると嬉しい :D
]]>この際だから覚えてしまうことにする。
たぶん何度も読み直すと思うので、ここにメモ。
sass/
├─ screen.scss # 全ての定義の始まりであり、終わり
├─ _base.scss # 各 base/* の読み込み
├─ base/
│ ├─ _utilities.scss # sass の関数など
│ ├─ _solarized.scss # コードスニペットの色定義
│ ├─ _theme.scss # テーマカラーに関する定義など
│ ├─ _typography.scss # 各 HTML 要素のフォントに関する定義
│ └─ _layout.scss # メディアクエリ、サイドバーの折り畳みなど
├─ custom/
│ ├─ _colors.scss # テーマカラーのカスタマイズ用
│ ├─ _fonts.scss # フォント種類のカスタマイズ用
│ ├─ _layout.scss # パディング、マージンのカスタマイズ用
│ └─ _styles.scss # その他のスタイルに関するカスタマイズ用
├─ _partials.scss # 各 partials/* を読み込み
└─ partials/
├─ _header.scss # ヘッダー部に関するスタイル定義
├─ _navigation.scss # ナビゲーションバーに関するスタイル定義
├─ _blog.scss # 記事に関するスタイル定義
├─ _sharing.scss # ソーシャルボタンに関するスタイル定義
├─ _syntax.scss # コードスニペット関連のスタイル定義
├─ _archive.scss # アーカイブ、カテゴリページのスタイル定義
├─ _sidebar.scss # sidebar/* の読み込み
├─ sidebar/
│ ├─ _base.scss # サイドバーの汎用スタイル定義
│ ├─ _twitter.scss # セレクタ "#tweets" の定義
│ ├─ _googleplus.scss # セレクタ ".googleplus" の定義
│ ├─ _pinboard.scss # セレクタ "#pinboard_linkroll" の定義
│ └─ _delicious.scss # セレクタ ".delicious-posts" の定義
└─ _footer.scss # フッター部に関するスタイル定義
1 2 3 4 5 6 7 8 9 10 |
|
1〜3行目は、Compass Reset Utilities の Mixin を利用するための設定。5〜10行目の読み込み順が重要。スタイル定義の優先順位が決まる。
sass/custom/
以下のファイルでカスタマイズする。
まずはテーマカラーの調整。
1 2 3 4 5 6 |
|
その他の細かなスタイルのカスタマイズ。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
|
サイドバーのツイッターを有効にすると、謎の右マージンが現れる。
原因は、サイドバー内側の幅が 260px に設定されているのに対し、フォローボタンに幅が指定されておらず、デフォルトの 300px となっていること。
source/_include/asides/twitter.html
で、フォローボタンの幅を data-width="260px"
と指定して解決(auto
に設定してもダメ)。
1 2 3 4 5 |
|
おそらく 本家のこのコミット で直ったと思う。
]]>source/_includes/head.html
の10行目付近から。
1 2 3 |
|
記事の YAML ブロック に description
か、記事から HTML を除いた先頭150字が <meta name="description" content="...">
に挿入される。
同様に keywords
で <meta name="keywords" content="...">
が挿入される。
1 2 3 4 5 6 7 8 9 |
|
ちなみにトップページの場合も、先頭記事が { content }
として参照されるのが、何だかアレな感じ。
記事の先頭150字以内に改行が含まれていると、content="..."
が改行されちゃうのもアレ(HTML 的には OK だから、気にすることないけどネ)。
そこで、plugins/octopress_filters.rb
(ソースコードの全体)の104行目付近 condense_spaces
に改行を削除するコードを追加。
1 2 3 4 5 |
|
Rakefile
102行目付近の new_post
エントリーで、上記を YAML ブロックに挿入する。
1 2 3 4 5 6 7 8 9 10 11 12 |
|
About Me
追加既にテンプレートが source/_includes/custom/asides/about.html
にある。色々なサイドバー・パーツを追加するのにも使える。後は _config.yml
49行目付近に指定するだけ。
1
|
|
1 2 3 4 5 6 7 8 9 10 |
|
各ボタンの言語設定、Facebook アプリケーション ID 設定などを追加する。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
適当な位置にはてブを追加する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Facebook、Google+1、Twitter をコメントアウトする。
1 2 3 4 5 6 7 |
|
Google+1、Facebook の言語設定と JavaScript の非同期読み込みコードを共通化してまとめる。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
|
facebook_like.html
には、作者のものと思われるアプリケーション ID が埋め込まれているが、このファイルは使わない。
1 2 3 4 5 6 7 8 9 10 |
|
本来これは _config.yml
で設定すべき事項。言語設定も含めて pull request するべきなんでしょうかネ。
gem update --system
で最新版にしておく。GitHub で username.github.com
の リポジトリを作成 しておく。
1 2 3 |
|
Initialized empty Git repository in /path/to/repo/username.github.com/.git/
1 2 3 |
|
[master (root-commit) a3bd2f1] first commit
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 README
1 2 |
|
Counting objects: 3, done.
Writing objects: 100% (3/3), 205 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:username/username.github.com.git
* [new branch] master -> master
Branch master set up to track remote branch master from origin.
とりあえず、ユーザーページ用リポジトリ username.github.com
と同じ階層にインストールする。
1 2 |
|
Cloning into 'octopress'...
remote: Counting objects: 5685, done.
remote: Compressing objects: 100% (2262/2262), done.
remote: Total 5685 (delta 3247), reused 5225 (delta 2933)
Receiving objects: 100% (5685/5685), 1.21 MiB | 435 KiB/s, done.
Resolving deltas: 100% (3247/3247), done.
1 2 |
|
Successfully installed bundler-1.0.21
1 gem installed
Installing ri documentation for bundler-1.0.21...
Installing RDoc documentation for bundler-1.0.21...
ちなみに、いちいち ri
とか RDoc
とかのインストールがうざい場合、RubyGemsでgemのインストール時に–no-ri –no-rdocをデフォルトにする - アインシュタインの電話番号 を参考に .gemrc
を設定する。
次はおそらく Gemfile
に書かれた gem を、依存関係含めてインストールしているのだと思う。
1
|
|
Using rake (0.9.2)
Using RedCloth (4.2.8)
...
Using bundler (1.0.21)
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.
そして、Rakefile のエントリー install
を実行する。
1
|
|
## Copying classic theme into ./source and ./sass
ここからは、公式サイトの Deploying to Github Pages With Github User/Organization pages の内容。
1
|
|
Enter the read/write url for your repository: git@github.com:username/username.github.com.git
Added remote git@github.com:username/username.github.com.git as origin
Set origin as default remote
Master branch renamed to 'source' for committing your blog source files
Initialized empty Git repository in /path/to/repo/octopress/username.github.com/_deploy/.git/
[master (root-commit) 314edb9] Octopress init
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 index.html
---
## Now you can deploy to http://username.github.com with `rake deploy` ##
Initialized empty Git repository
のパスが変だけど、_deploy
に .git
ができているのは確で、.git/config
を確認。
実行される内容は次の通り。
imathis/octopress
を指すリモート名を origin
から octopress
に変更origin
に設定master
から source
に変更_deploy
ディレクトリに、デプロイ用の master
ブランチを設定特に 4. 〜 6. 辺りの処理は、1. の入力に応じて自動的にデプロイ先のブランチが設定される(ユーザーページ用は master
、プロジェクトページ用は gh-pages
)。
そして、サイトの生成とデプロイ(後述の「6. 新規記事、新規ページの作成」も同じ)。
1 2 |
|
2つを一気に実行するには rake gen_deploy
を、まずはローカルでプレビューするという場合には rake preview
を実行後に http://localhost:4000/ にアクセスする。
公式サイトの Configuring Octopress を参考に、_config.yml
を設定。
公式サイトの Blogging Basics を参照。
rake new_post['post title']
記事のタイトルは、英語で。
source/
└── _post/
└── YYYY-MM-DD-post-title.markdown
---
layout: post
title: "post title"
date: YYYY-MM-DD hh:mm
comments: true
categories: [category1, ...]
---
ここで、title
を日本語にすれば良い。
rake new_page[my-new-page]
rake new_page[my-new-page.html]
source/
└── my-new-page/
├── index.markdown # rake new_page[my-new-page]
└── index.html # rake new_page[my-new-page.html]
---
layout: page
title:
date: YYYY-MM-DD hh:mm
comments: true
sharing: true
footer: true
---
Deploying to Github Pages には、ユーザーページ、プロジェクトページのそれぞれで、本体のリポジトリと統合する方法が推奨されている。
1 2 3 |
|
1 2 3 |
|
統合後は、ローカルの octopress
リポジトリは不要になる。
ただし、実際にやってみると次のようなデメリットもある。
source
ブランチで管理外だった _deploy
や public
などを、デプロイ先のブランチでも管理外にする必要アリ。(.gitignore
の再設定)。source
ブランチでの rake deploy
で デプロイ先のブランチが直接更新されるため、git fetch; git pull
でローカルに反映させる必要アリ。コンフリクトは例えばこんな感じ。
Auto-merging stylesheets/screen.css
CONFLICT (add/add): Merge conflict in stylesheets/screen.css
Auto-merging sitemap.xml
CONFLICT (add/add): Merge conflict in sitemap.xml
Auto-merging index.html
CONFLICT (add/add): Merge conflict in index.html
Auto-merging blog/archives/index.html
CONFLICT (add/add): Merge conflict in blog/archives/index.html
Auto-merging atom.xml
CONFLICT (add/add): Merge conflict in atom.xml
Automatic merge failed; fix conflicts and then commit the result.
こうなると手作業でコンフリクトを解消するか、次のようにしてローカルの内容を強制的にリモートで上書きしなければならない。
1 2 |
|
ということで特にユーザーページ用においては、Octopress リポジトリは単独で管理する、しかも非公開が好ましいと言うのが現時点での結論。
この目的にぴったりなのが Bitbucket というわけ。Git が使える上、リポジトリを非公開にでき、5人まで無料。個人利用であれば言うことなし。
Bitbucket のアカウント取得後にまずやることは、「Account settings」で SSH key を設定すること。Using SSH to Access your Bitbucket Repository を参考に。
次に Bitbucket に octopress リポジトリを作成し、リモートとして登録。
1 2 |
|
この段階で、リモートとして origin
、octopress
、bitbucket
の3つが登録されることとなる。これ以降、記事のデプロイは rake deploy
、原稿のバックアップは git push
でできるようになる。
本家の更新を取り込んでマージする。gems
の更新も忘れずに。
1 2 3 |
|
rake install
の時点で、.themes/classic
から source
にコピーされる。
site.変数名
でアクセスされる。source/
├── _layouts/ # トップページ、個別記事ページ、カテゴリアーカイブページのレイアウト
└── _includes/ # ページレイアウト用の部品
├── post/ # サイトのメタデータ、ソーシャルメディア、コメントシステム用部品
├── asides/ # テーマのサイドバー用部品
└── custom/ # カスタマイズ用部品(<head>、<header>、<navigation>、<aside>、<footer>)
└── _layouts/
├── default.html
├── page.html (layout: default)
├── post.html (layout: default, single: true)
└── category_index.html (layout: page, footer: false)
└── _includes/
├── head.html
├── custom/head.html
└── google_analytics.html
└── _includes/
└── custom/category_feed.xml
└── _includes/
├── header.html
└── custom/header.html
└── _includes/
├── navigation.html
└── custom/navigation.html
└── _includes/
├── article.html # post.html、index.html から
├── post/author.html # post.html、page.html から
├── post/categories.html # post.html、page.html から
├── post/date.html # post.html、page.html、index.html から
├── post/disqus_thread.html # post.html、page.html から
└── post/sharing.html # post.html、page.html から
└── _includes/
├── custom/asides/about.html
├── asides/recent_posts.html
├── asides/github.html
├── asides/delicious.html
├── asides/googleplus.html
├── asides/pinboard.html
└── asides/twitter.html
└── _includes/
├── footer.html
└── custom/footer.html
└── _includes/
├── after_footer.html
├── custom/after_footer.html # コメントのみ
├── disqus.html # after_footer.html から
├── facebook_like.html # after_footer.html から
├── google_plus_one.html # after_footer.html から
└── twitter_sharing.html # after_footer.html から
└── _includes/
└── archive_post.html # category_index.html、blog/archives/index.html から
├── index.html (layout: default)
├── atom.xml
├── blog/
│ └── archives/
│ └── index.html
├── sitemap.xml
├── favicon.png
├── images/
│ ├── bird_32_gray.png
│ ├── bird_32_gray_fail.png
│ ├── code_bg.png
│ ├── dotted-border.png
│ ├── email.png
│ ├── line-tile.png
│ ├── noise.png
│ ├── rss.png
│ └── search.png
├── javascripts/
│ ├── ender.js
│ ├── github.js
│ ├── libs/
│ │ ├── ender.js
│ │ ├── jXHR.js
│ │ └── swfobject-dynamic.js
│ ├── modernizr-2.0.js
│ ├── octopress.js
│ ├── pinboard.js
│ └── twitter.js
└── stylesheets/
└── screen.css
rake new_post['post title']
└── _post/YYYY-MM-DD-post-title.markdown
---
layout: post
title: "post title"
date: YYYY-MM-DD hh:mm
comments: true
categories: [category1, ...]
---
rake new_page[my-new-page]
rake new_page[my-new-page.html]
├── my-new-page/index.markdown # rake new_page[my-new-page]
└── my-new-page/index.html # rake new_page[my-new-page.html]
---
layout: page
title:
date: YYYY-MM-DD hh:mm
comments: true
sharing: true
footer: true
---
]]>通常はローカルに jekyll をインストールするが、GitHub Pages では必ずしも必要ないという話。
こちら に基本的な手順の説明。
ローカルな Ruby 環境に jekyll をインストール する
jekyll に必要な テンプレートファイル群 を構成し、_config.yml
や テンプレートファイル を設定する
YAML で記述した先頭ブロックの レイアウトとタイトル に続けて、 HTML、Markdown、textile のいずれかの記法を使って記事を書く
jekyll で HTML ページを生成し(jekyll --server --auto
)、ローカルで確認(http://0.0.0.0:4000/)、デプロイ(_site
に生成されたページ群を git 経由でリモートにコピー)する
一方 GitHub では、GitHub Pages 上に jekyll に必要なファイル群があれば、自動的に HTML を生成してくれるので、必ずしもローカルに jekyll をインストールしなくても何とかなる。 もっともローカルで最終的なレンダリング結果を確認するためにも、jekyll をインストールするに越したことはないが…
1ページだけの GitHub Pages なら、最小構成ファイル群は以下の通り。
1 2 3 4 5 6 |
|
次は、テンプレートファイル default.html
の例。
1 2 3 4 5 6 7 8 9 10 11 12 |
|
index.md
には default.html
の content
の中身を記述する。
1 2 3 4 5 6 7 8 9 |
|
index.md
以外にも、index.html
や index.textile
でも OK だが、先頭の layout
、title
が重要。これがないとレンダリングしてくれない。
css/styles.css
で装飾し、必要なら images
や script
、favicon.ico
などもお好みで。
そしてこれらファイル群を プロジェクト・リポジトリの gh-pages
ブランチに push する。
サイドバー付きページのテンプレートを、Initializr 2 をベースに構成する。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
1 2 3 4 |
|
1 2 3 4 5 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
|
Big Sky :: Jekyllで始める簡単ブログ
jekyll でブログを作るためのファイル構成が解説されている。
Jekyllによる静的 Webサイト構築入門
mojombo/jekyll の Wiki をかなりの範囲でカバーする、わかりやすい入門書。Windows へのインストール方法も解説されている。
GitHub Pagesで楽々ホスティング - Radium Software
Jekyll 用に構築された GitHub ユーザーページ用リポジトリ が参考になる。
ということで、名前のつけ方、変え方。
1
|
|
勝手に名前が付けられる。どんな名前を付けてくれるのか、結構楽しみだったりする。
1
|
|
当然、既に取得されているアプリ名はダメ。
次の3通りの方法。
1
|
|
1
|
|
1 2 |
|
ここに記したのは Mac (Mac OS X 10.6.8 Snow Leopard) での話です。Windows はそのうち確かめたいと思います。
heroku を利用する前提条件は次の3つ。
最新の ruby-1.9.3-p0
とか使っているけど、大丈夫そう。
ただし、プロジェクトに .rvmrc
があって rvm use 1.9.2
とか書いてあると
次のように怒られる。
WARN: ruby ruby-1.9.2-p290 is not installed.
To install do: 'rvm install ruby-1.9.2-p290'
この場合は、~/.rvmrc
に
rvm_project_rvmrc=0
とか書いておくと、プロジェクトの .rvmrc
を無視し、~/.rvmrc
の設定を使う。(参考:rvmrc files)。
各OS用パッケージが載っているが、以下で大丈夫。
$ gem install heroku
Fetching: term-ansicolor-1.0.7.gem (100%)
...
Successfully installed heroku-2.15.1
7 gems installed
heroku コマンドは、たびたびバージョンアップがなされるようなので、アップデートをチェック。
$ gem update heroku
Updating installed gems
Nothing to update
続いて SSH キーの証明書を発行 する。 SSH キーは GitHub での設定 と共用で大丈夫。
$ heroku keys:add
Enter your Heroku credentials.
Email: tokkonopapa@yahoo.com
Password:
Found the following SSH public keys:
1) github_rsa.pub
2) id_rsa.pub
Which would you like to use with your Heroku account? 2
Uploading ssh public key /Users/kiyo/.ssh/id_rsa.pub
1)
は GitHub for Mac の SSH キー(たぶん)。
heroku に上げたい Git リポジトリのディレクトリで heroku create
とするだけ。
$ git clone git://github.com/kei-s/github-preview.git github-preview
Cloning into 'github-preview'...
remote: Counting objects: 116, done.
remote: Compressing objects: 100% (67/67), done.
remote: Total 116 (delta 40), reused 101 (delta 25)
Receiving objects: 100% (116/116), 73.46 KiB | 16 KiB/s, done.
Resolving deltas: 100% (40/40), done.
$ cd github-preview
$ heroku create
Creating growing-winter-3139...... done, stack is bamboo-mri-1.9.2
http://growing-winter-3139.heroku.com/ | git@heroku.com:growing-winter-3139.git
Git remote heroku added
$ git push heroku
アプリ用 URL やリモートリポジトリの情報は、「My Apps → General Info」から参照できる。
]]>ただし私は、「Ruby ってどんな? gem って何?」というヒトなので、ここに書かれたことには間違いが含まれている可能性アリです。ご参照はソコソコに。
Xcode 3.2.6 and iOS SDK 4.3 for Snow Leopard からダウンロード、
xcode_3.2.6_and_ios_sdk_4.3.dmg
を実行。iOS SDK 4.3 は要らないので、インストールせず。
RVM: Ruby Version Manager - Installing RVM には、Single-User が推奨されているので、以下を実行。
$ bash < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)
.bash_profile
に RVM function を読み込ませるスクリプトを追加。
$ echo '[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # Load RVM function' >> ~/.bash_profile
第1のハマりは、これを .bashrc
に設定していたこと。.bach_profile
でないとダメ (bash の起動で .bashrc
を読み込まないのは Mac 特有?)。あるいは .bach_profile
に次を設定しておく(“.bash_profile”と”.bashrc”の使い分け)。
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
これがちゃんと設定されていないと、後半の rake install
で次のようなエラーが出る。
Could not find RedCloth-4.2.8 in any of the sources
Run `bundle install` to install missing gems.
Octopress は 1.9.2 以上が条件。rvm list known
とすると、1.9.3 があるので、最新版をインストールすることに。rvm コマンドには sudo は付けない。付けるのは Multi-User 用。
$ rvm install 1.9.3
デフォルトで 1.9.3 を使うように設定。
$ rvm use 1.9.3
また Installing RVM - Octopress によると、rubygems の更新も必要。
$ rvm rubygems latest
Octopress Setup に従いインストール。まず、Octopress のクローンを作る。
$ git clone git://github.com/imathis/octopress.git octopress
$ cd octopress
ここで次のようなメッセージが出現。
==============================================================================
= NOTICE =
==============================================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands. =
= =
= Examine the contents of this file carefully to be sure the contents are =
= safe before trusting it! ( Choose v[iew] below to view the contents ) =
==============================================================================
Do you wish to trust this .rvmrc file? (/Users/xxxxxx/github/octopress/.rvmrc)
y[es], n[o], v[iew], c[ancel]>
RVM が .rvmrc
の上書きを監視しているようだ。よくわからないまま y
を入力。これが間違えの元か? 作成された .rvmrc
には rvm 1.9.2
と書かれているが、とりあえずそのまま。
$ gem install bundler
$ bundle install
$
$ rake install
やばい、ここでエラー。
rake aborted!
no such file to load -- bundler/setup
『はじめる! Rails3』読者サポートページ の 「Ruby が複数インストールされた環境で発生する場合がある」 を元に、次を実行。
sudo gem update rake
再び rake install
。
Could not find rake-0.9.2.2 in any of the sources
Run `bundle install` to install missing gems.
え~、今 bundle で install したばっかりでしょう!? 再度 rake install
しても
$ bundle show rake
を実行すると、やはり bundle install
しろと言われる。両コマンド間で参照している環境変数が違う感じ?
で、前述の .rvmrc
を思い出す。試しに .rvmrc-
に退避してみたらあっさり OK。
結局、rvm をインストールした時の、次のメッセージに従い、~/.rvmrc
に rvm_project_rvmrc=0
を記述して、一件落着。
If you wish to disable the project .rvmrc file functionality, set
rvm_project_rvmrc=0 in either /etc/rvmrc or ~/.rvmrc.
現在は上記 ~/.rvmrc
への追加ではなく、rvm use 1.9.3 --default
を実行して .rvmrc
に
設定されている rvm 1.9.2
を無視する設定としている。
ところで、bundler って何? Ruby の世界は奥深そうなのでした ;-) 。
]]>