投稿者のアーカイブ
Git リモートリポジトリをガツンと巻き戻す
かなり悩んで時間がかかったのでメモを残しておきます。
前提条件として、基本、Git Flowベースで作業しています。
不幸なことにガンガン開発を進めていたdevelopブランチをmasterブランチの状態まで巻き戻すことに。masterブランチにはhotfixが入ってたりもします。
調べて調べて、悩んで、相談して、調べて、以下のような手順で作業することにしました。
hotfix前のdevelopまで戻す。
$ git reset --hard 巻き戻すコミットのハッシュ
リモートのdevelopリポジトリを同じ所まで巻き戻す。
$ git push -f origin HEAD:develop
そして、hotfixについてはmasterから対象のコミットをチェリーピックでマージしてリモートリポジトリにpush(Souce Treeでやりました)。
そして、開発者諸氏にdevelopブランチをリモートから取り直すように連絡(忘れずに！)
加えて、このプロジェクトでは開発用サーバーにdevelopリポジトリから
$ git pull -rebase
でデプロイしているので、開発用サーバーのdevelopリポジトリもローカルと同じコマンドでリセットしてデプロイしなおしました。
Mac基本のキ:アプリを32ビットモードで起動する
- 2015/01/05
- murave
@murave 「32ビットモードで開く」で回避(とりあえず)。Thunderbird.appを右クリックして「情報を見る」から設定。
— murave (@murave) January 5, 2015
仕事始めの朝に食らいまいした。あけましておめでとうございます。
今回のように64ビットアプリでトラブルにあったときに32ビットモードで起動すると回避出来たりすることがありますので覚えておくといいことがあるかもしれません。
そして忘れてずっと32ビットモードで暮らしてしまうかもしれません。使えないよりはいいですけどね。
設定方法はつぶやいてるとおりですが、わかりやすいようにキャプチャとってみました。
右クリックして「情報を見る」
そして「32ビットモードで開く」にチェック。
Nginxのリバースプロキシを設定していてlocationの優先順位で大ハマリ
社内システムを動かしていたApacheなサーバーが廃止されたのでNginxなサーバーに移行しました。
他の社内システムに相乗りして、URLに特定のサブディレクトリがついていたら動作を分けて背後のアプリケーション・サーバーにリバースプロキシで接続という構成です。
server {
#省略
#リバースプロキシの設定を追加
location /hoge/ {
proxy_pass http://127.0.0.1:3000/;
}
#省略
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
log_not_found off;
}
}
Nginxに上記のようなリバースプロキシの設定を入れたところプログラムは動作しているのに画像、css、jsが読み込めずに大ハマリしました。
勘がいい人は「他は省略しているのに残してある箇所」があやしいのに気づいてしまったと思いますが、その通り、アクセスログにも何も出ない、なぜだ？なぜなんだぜ？と調べていたらいらっしゃいましたよ、画像、css、jsの処理を全部もっていってるお方が。
location、正規表現の方が未指定の前方検索より強いので location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ に処理を全部もっていかれていたってわけです。Nginx で location の判定方法と優先順位を調べるがとても参考になりました。ありがとうございます。
正規表現よりも優先順位が高い書き方で指定すると解決しました。
server {
#省略
#リバースプロキシの設定を追加
location ^~ /hoge/ {
proxy_pass http://127.0.0.1:3000/;
}
#省略
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
log_not_found off;
}
}
Mac上に開発用Roundcubeをセットアップ
プラグインを作りたいので開発環境を手元に作ることにしました。
インストールについては弊社kosugiが書いた
を参考に作業しました。あまり問題は出なかったのですが、Roundcubeのバージョンがあがり設定ファイルの名称や扱いが変わったりしていたのでメモを残したいと思います。
あとはphpのビルトインサーバー(php -S)で手軽にやりたいな〜ってのと、Gmailのセキュリティ強化の影響、個人的趣味でデータベースがPostgreSQLだというのが異なる点です。
・PHPは以前の記事でPostgreSQL用のモジュールを入れた5.5.14。
- phpenv で入れた PHP に pdo_pgsql をインストール
- phpenv で入れた PHP に pdo_pgsql をインストール
・PostgreSQLのバージョンは9.3.5.0 (Postgres.app)
・メールサーバーはGmail利用する。
・Roundcube 1.0.2 (Complete)
■ データベース(PostgreSQL)準備
ダウンロードして展開したRoundcubeのディレクトリにあるINSTALLファイルを参照しながら準備します。
・pgAdmin3などでroundcubeユーザーを作ります。開発環境なので権限はザックリSUPERUSERにしときました。
・roundcubemailデータベースを作ります。
CREATE DATABASE roundcubemail
WITH OWNER = roundcube
ENCODING = 'UTF8'
TABLESPACE = pg_default
LC_COLLATE = 'ja_JP.UTF-8'
LC_CTYPE = 'ja_JP.UTF-8'
CONNECTION LIMIT = -1;
・準備用のSQLを実行。
#展開したRoundcubeのディレクトリで
$ psql -U roundcube -f SQL/postgres.initial.sql roundcubemail
■ ビルトインサーバー起動
#展開したRoundcubeのディレクトリで
$ php -S localhost:8000
PHP 5.5.14 Development Server started at Mon Sep 22 17:13:54 2014
Listening on http://localhost:8000
Document root is /Users/murave/roundcubemail-1.0.2
Press Ctrl-C to quit.
■ installerにアクセスして初期設定
今回だと http://localhost:8000/installer/ にアクセス。画面にしたがって設定していけばOKです。英語ですけど。
STEP2のCreate configで作成される設定ファイルの名称と扱いが以前とは変わっているようです。
config/config.inc.phpが直接作成されます。今回は編集する必要も特にありませんでした。一部(‘des_key)を*で伏せて引用します。
STEP3. Test configのキャプチャです。
■ Gmailについて
kosugiが書いている通りIMAP経由でのメール受信を有効にしておくのは大前提ですが、RoundcubeからGmailにIMAPでアクセスしようとすると「安全性の低いアプリ」として拒否されるかもしれません(拒否されなければ気にする必要はありません)。
この場合「Google アカウント: ログイン試行をブロックしました」というメールが来ていると思います。
このメールに書いてあるのですが、以下のページから設定を変更することができます。あまり良くないのですが今回は「安全性に低いアプリのアクセス」を有効にしてIMAP接続を確認しました。
https://www.google.com/settings/security/lesssecureapps
■ ログインして動作確認
http://localhost:8000/
にアクセス、ログインしてメールの送受信を確認して完了です。
phpenv で入れた PHP に pdo_pgsql をインストール
- 2014/08/23
- murave
実際は前の記事の前にやったんですけど、動かしたいソフトが使っていたのはpdo_pgsqlじゃなかったのでありました。
ということで、環境は前の記事と同じでPostgres.appを使用しててPostgreSQLのバージョンは9.3.5.0。対象のPHPのバージョンは5.5.14です。anyenvもからんでいるのでphpenv単独の場合とは少しディレクトリ構成が違う点にご注意ください。
以下の記事を参考に作業しました。
まずはpeclのサイトからpdo_pgsqlを取ってきて解凍。
$ cd tmp
$ wget http://pecl.php.net/get/PDO_PGSQL-1.0.2.tgz
$ tar zxvf PDO_PGSQL-1.0.2.tgz
$ cd PDO_PGSQL-1.0.2
ぺちぱいず(読み方不明)だ！
$ phpize
こんふぃぎゅあしてめいくしましょう。
$ ./configure --with-pdo-pgsql=/Applications/Postgres.app/Contents/Versions/9.3/bin
$ make
インストール内容を確認してから
$ make test
インストール。
$ make install
有効化するためにpdo_pgsqのためのiniファイルを作成。
$ vim /Users/murave/.anyenv/envs/phpenv/versions/5.5.14/etc/conf.d/pdo_pgsql.ini
内容。
extension=pdo_pgsql.so
php.iniに直接追加してもいいけどphp.iniがリセットされて泣いたりするかもしれないから分けておくといいと思う(経験者)。
確認。
$ php -i | grep pdo_pgsql
phpenv + php-build で php_pgsql を有効化したPHPをインストール
- 2014/08/22
- murave
開発環境のMacでPHPからPostgreSQLにアクセスできなくてアレレ〜となったので入れなおしました。その際のメモをまとめておきます。
Postgres.appを使用しており、PostgreSQLのバージョンは9.3.5.0です。
インストールしたPHPのバージョンは5.5.14。
anyenvもからんでいるのでphpenv単独の場合とは少しディレクトリ構成が違う点にご注意ください。
php_pgsqlを有効にするためにconfigure_optionを追加します。
$ vim /Users/murave/.anyenv/envs/phpenv/share/php-build/definitions/5.5.14
編集します。
configure_option "--with-pgsql" "/Applications/Postgres.app/Contents/Versions/9.3/bin"
install_package "http://php.net/distributions/php-5.5.14.tar.bz2"
install_pyrus
install_xdebug "2.2.5"
enable_builtin_opcache
configure_option “–with-pgsql” の行を追加しました。ここはPostgreSQLの導入状況にあわせる必要があります。
インストールします。
$ phpenv install 5.5.14
インストールしたPHPに切り替えて確認。
$ phpenv global 5.5.14
$ phpenv rehash
$ php -i | grep pgsql
VMware Fusion が入っている Mac での 仮想ディスク(vmdk)縮小
- 2014/08/08
- murave
- Mac
- VMware Fusion
放置していたら仮想マシンが肥大してディスクを超圧迫していました、夏。
そして、ディスクの残容量0と言われた立秋。
Vagrant で使用している Virtual Box の VM がいつの間にか60GBを超えており放置できなくなりました。
検索したところ Virtual Box のツールで .vmdk なファイルを .vdi に変換して縮小する素敵な記事が見つかりました。
Bureimono stdio.h: Vagrant とストレージ容量
でも考えたら、ボクのマシンには VMware Fusion が入っています。vmdkファイルを直接縮小できるよね、たぶん。前にやった気もするし。
ということで、調べて作業した際のメモです。 VMware Fusion は 5.0.5 です。
ゲストOSでゼロクリアを行います(root権限で作業)。
# dd if=/dev/zero of=zero bs=4k
# sync
# rm zero
vmdkファイルの縮小(defragment -> shrink)
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -d target.vmdk
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -k target.vmdk
60GB位あったvmdkファイルが10GB位になりました。
今回はディスクの残容量が少なくなりすぎていて vmware-vdiskmanager を動かすのに苦労しました。そんな状況になる前に対処するようにしないとですね。
md2reviewで箇条書きの入れ子に対応していただきました
- 2014/07/22
- murave
前の記事「md2reviewでMarkdownからRe:VIEWに変換すると箇条書きの入れ子は無視される」を見た@takahashimさんが即対応してくださいました！
md2review 1.2.0 で修正されています。
Markdownで書いた記事をRe:VIEWで利用するのがとても楽になりました。
以下、余談です。
修正されたソースコードを見てあまりの簡潔さに「マジすか！」と思いました。
前の記事、解析時にMarkdownの箇条書き入れ子の仕様について間違った認識をしていたために混乱していたようです(コードがクソなのは書捨てということで許して)。
@takahashimさんとやりとりしているときに教えていただいたのですが、入れ子のときには4スペースインデントしないとエンジンによっておかしくなることが多いそうです。
私は調査時2スペースでインデントしていたのでおかしなことになっていたというわけ(Mouではちゃんと表示されるので気づかなかった)。エンジンによるようですがインデントは4の倍数かタブにしておくのが良いようです。
md2reviewでMarkdownからRe:VIEWに変換すると箇条書きの入れ子は無視される
- 2014/07/17
- murave
※2014年7月頭の状況です(解決済です次の記事をご参照ください)。
MarkdownとRe:VIEWを知っている方しか見ない記事だと思うので細かい説明は抜きでいきます。
ソフトウェア技術者だと最近はMarkdownで資料を書くことが多いのではないかと思います。
私もそうなのですが、Markdownで書いたお資料を印刷する際に困っていました(客様に渡す報告書等)。
いろいろ試した結果Mou(Mac用のMarkdownエディター)で印刷していたのですが、フォントが中国系になるという不満点がありました。
そこでmd2reviewでMarkdownからRe:VIEWに変換してPDF化するというフローを試したところかなりいい感じに出力できたのですが、私にとっての大問題が判明しました。
そう、 「md2reviewでMarkdownからRe:VIEWに変換すると箇条書きの入れ子は無視される」 のです。
番号付き箇条書き(Decimal型)についてはRe:VIEW側が対応していないのでしょうがないのですが(個人的にあまり使ってないですし)、普通の箇条書き(Disc型)の入れ子は多用しているので大変厳しい。
そこで、改造して Pull Request 出したろう！と着手したのですが、
- md2review調査
- かなりの部分redcarpet依存であると判明。
- redcarpet調査
- 「メイン処理はCで書かれてるのかよ〜」と思いつつ読んだ結果、簡単には対応できそうもないと判断。なぜmd2reviewが箇条書きの入れ子に未対応なのか、納得する。
- 残念対応
- md2reviewで変換したRe:VIEWの箇条書き部分に入れ子の状態から挿入される空行に規則性があるようだったので、これを解析したらどうにかならないか？と思う。
- redcarpetにpostprocessというレンダリングの後処理を行うための仕組みがあったのでそこで処理してみた。
- 作ってみた結果、以下の問題がある残念なものが出来上がった。
- 入れ子2段までしか判断できないため3段以上は正常に動作しない。
- 箇条書きの最後のアイテムについては判断できないためとりあえずワーニングコメント#@warn(CONFIRM NEST!)を出力する(確認しやすくはなった)。
という残念な結果に終わりました。
残念対応ですが無いよりはマシですので公開しておきます。
md2reviewのreview.rbに以下のpostprocessを追加します。
def postprocess(full_document)
# レンダリング結果を解析して順番なし箇条書きのインデントを反映する。
# ただし2段までしか判断できないため3段以上は正常に動作しない。
# また、箇条書きの最後のアイテムについては判断できないため
# ワーニングコメント#@warn(CONFIRM NEST!)を出力する。
# 無効化するときは次の行のreturnを有効化する。
#return full_document
require 'set'
lf_del_set = Set.new
lf_ins_set = Set.new
pre_ul_flg = false
pre_emp_flg = false
ul_level = 1
lines = []
full_document.split(/\n/).each_with_index do |line, i|
if line == "" || line[0, 3] == " * "
if line == ""
if pre_emp_flg && pre_ul_flg
line = "\#@warn(CONFIRM NEST!)\n"
elsif pre_ul_flg
lf_del_set.add(i)
if 1 < ul_level
if lines[i - 1][0, 2] == " *" && lines[i - 2][0, 2] == " *"
lines[i - 1] = " #{'*' * (ul_level - 1)} " +
lines[i - 1][(ul_level + 2), lines[i - 1].length]
ul_level -= 1
lf_ins_set.add(i - 1)
end
end
end
pre_emp_flg = true
else
if pre_ul_flg && pre_emp_flg
ul_level += 1
end
line = " #{'*' * ul_level} " + line[3, line.length]
pre_ul_flg = true
pre_emp_flg = false
end
else
pre_ul_flg = false
ul_level = 1
end
lines.push(line)
end
if pre_ul_flg
lines.push("\#@warn(CONFIRM NEST!)\n")
end
ret_document = ""
lines.each_with_index do |line, i|
if lf_ins_set.include?(i)
ret_document += "\n"
end
if !lf_del_set.include?(i)
ret_document += line + "\n"
end
end
ret_document
end
以上まではほぼMarkdownで記述し改造版md2reviewで変換した後、箇条書き部分の入れ子が3段の箇所と箇条書きの最後をて修正したRe:VIEWファイルから出力したHTMLです(ソースコード掲載の箇所はハイライト表示の関係で書きなおしました)。
同じファイルから作ったPDFが以下のファイルです(単純なレポート用に調整した設定を使用しています)。
report.pdf
EPUBも作ったんですが、セキュリティ制約でアップロードを弾かれちゃいました。残念。
このように様々な出力が可能という利点はあります。
余談ですがEPUB出力するのはとても簡単です。PDF出力はLaTeX環境をつくらなければならないのでやや面倒でした。
baserCMS2系から3系への道(アップデートメモ)
オレはようやくのぼりはじめたばかりだからな
このはてしなく遠いbaserCMS坂をよ… 未完
という気持ちになるくらいイロイロとありましたが(２日かかってしまいました)、無事2.1.1から3.0.2へ移行できました。注意点のメモを残します。
まずは、移行作業の参考にさせていただいたサイト。
本家本元、
baserCMS開発ブログ『baserCMS 2.1系 から baserCMS３に移行する』
うっかりナスビさんでもお馴染み我流さんの、
我流天性 がらくた屋『baserCM2.1.2から 3.0.0へ移行を試してみたよ』
作業手順については上記、２つサイトを参考にすれば問題ないと思います。
移行作業で使用するプラグインは、現在、baserマーケットからダウンロード出来ます。
・DBマイグレーター(作業時バージョン1.0.3)
・アドオンマイグレーター(作業時バージョン1.0.1)
では、はじめに大事なことを。
普通に運用しているサイトであれば重要なのは１点。
「まず、3.0.0に移行するのだ！ 後のアップデートは3.0.0で動いてからだ！」
baserCMSユーザーズフォーラムの「2→3 の移行途中で /maintenance/index に強制リダイレクト」というトピックに書きましたが、DBマイグレーターの移行対象は(現状)、3.0.0のみだと思われます。
よって、一旦3.0.0で対応作業を行ってから以降のバージョンへのアップデートを行う、という手順で比較的容易に移行できると思います(移行用プラグイン優秀！)。
私が作業していた時には http://basercms.net/download/past から3系の旧バージョンがダウンロード出来なくなっていたのですが、素早く対応していただき、現在はダウンロード出来るようになっています。
私の最初の一日は3.0.2へのデータ復元後のメンテナンス画面への強制リダイレクトやデータベースアクセスエラーの原因を調べるのに費やされました。この情報で、みなさんの一日が守られればと思います。
以降はサイトの状況によってまったく異なってくると思いますので参考程度に。
弊社の場合はいろいろとカスタマイズしていたので様々な問題がでました。デバッグモードで動かし、表示されるNoticeを一つ一つ潰していきました。
・プラグインが無効化されずにサイト全体が死亡
DBマイグレーターで変換したデータを3.0.0に復元した後、なぜかプラグインが無効化されておらず、プラグイン周りでエラーが発生してサイトが死亡しました。データベース直編集でプラグインを無効化してエラーを回避しました。
・テーマヘルパーでエラー
テーマヘルパーはアドオンマイグレーターの変換では動作しませんでした。まずはテーマヘルパーを使用しているところをコメントアウトしてサイトが動作する状況にした後、デフォルトのヘルパーを参考に手作業で対応作業を行いました。
・カスタマイズしていたサイトマップでエラー
前の記事をご参照下さい。
・パンくず周りの変更に対応
古いテーマだとパンくず周りで「Not Found: …/elements/navi.php」といったNoticeが出てパンくずが正常に動作しません。3系に添付されているテーマの elements/crumbs.php をコピー、カスタマイズして対応するのが良いと思います。
・$bcBaser->paramsの値を直接参照していたところでエラー
反則に近いかもしれないのですが$bcBaser->params(2系の場合)中の値を直接参照して判定を行っていた箇所が結構ありまして、エラーとなりました。$this->BcBaser->params(3系の場合)の内容を調べて、同様の動作をするように書き換えました。3系のほうが情報が増えていて便利でした。
・3.0.0セットアップ時テーマのメールフォームと移行元メールフォームのフィールドが混在
これはプラグインが無効化されなかったときに直接データベースをいじって対応したのが原因かもしれないのですが(データ復元時にエラーが出ていたのかもしれない)、既存テーマのcontactメールフォームと移行元のcontactメールフォームのフィールド情報などが混在状態になってしまい難儀しました。既存テーマの情報をデータベースから直接削除するなどして対応しました。
以上、アップデートメモでした。
