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環境をつくらなければならないのでやや面倒でした。
Haxe/JSでGoogle maps APIをextern
- 2014/06/26
- aikawa
baserCMS2系から3系への道(アップデートメモ)
オレはようやくのぼりはじめたばかりだからな
このはてしなく遠いbaserCMS坂をよ… 未完
という気持ちになるくらいイロイロとありましたが(2日かかってしまいました)、無事2.1.1から3.0.2へ移行できました。注意点のメモを残します。
まずは、移行作業の参考にさせていただいたサイト。
本家本元、
baserCMS開発ブログ『baserCMS 2.1系 から baserCMS3に移行する』
うっかりナスビさんでもお馴染み我流さんの、
我流天性 がらくた屋『baserCM2.1.2から 3.0.0へ移行を試してみたよ』
作業手順については上記、2つサイトを参考にすれば問題ないと思います。
移行作業で使用するプラグインは、現在、baserマーケットからダウンロード出来ます。
・DBマイグレーター(作業時バージョン1.0.3)
・アドオンマイグレーター(作業時バージョン1.0.1)
では、はじめに大事なことを。
普通に運用しているサイトであれば重要なのは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メールフォームのフィールド情報などが混在状態になってしまい難儀しました。既存テーマの情報をデータベースから直接削除するなどして対応しました。
以上、アップデートメモでした。
baserCMS3系でのサイトマップカスタマイズ
bserCMS3系へのメジャーバージョンアップからはや半年以上、やっと弊社サイトを2.1.1から3.0.2へバージョンアップしました。
バリバリにカスタマイズしているので腰が引けていたのです。
旬を外していたり、イレギュラーなカスタマイズをやっていたりでバージョンアップにはかなり苦労したのですが、その話は次にとっておきまして、まずは以前書いた『baserCMSのサイトマップをカスタマイズ』のフォローを。
上記記事のコードですが、アドオンマイグレーター(http://barket.jp/products/detail.php?product_id=11)でテーマを変換しただけでは(やはり)動きませんでした。
少し修正が必要でしたので修正後の弊社のサイトマップのコードを置いておきます。参考にどうぞ。
BcBaser->sitemap() で呼び出す
*/
//ここから設定
//表示しないurl
$disables = array(
'/index_test',
);
//$inserts = array(before_url=>array(title, url),,,)
//before_urlの次に挿入url,titleで作成したアイテムを挿入
//ブログ、メールフォームなどpage以外を途中に挿入することが出来る。
$inserts = array(
'/sitemap' => array('新着情報', '/news'),
'/news' => array('お問い合わせ', '/contact'),
'/it-model/faq' => array('ダウンサイジングについてのお問い合わせ', '/contact_itmodel'),
'/roundcube/faq' => array('Roundcubeについてのお問い合わせ', '/contact_roundcube'),
'/kolab/faq' => array('Kolabについてのお問い合わせ', '/contact_kolab'),
);
//設定ここまで
//関数
$bcBaser = $this->BcBaser;
$outputPageItem = function ($recursive, $title, $url) use (&$bcBaser) {
?>
-
BcBaser->element('sitemap', array(
'pageList' => $pageCategories['children'],
'category_title' => $category_title,
'category_url' => $category_url,
'recursive' => $recursive+1
));
endif;
if($outputed_category_li):
$outputCategoryItemTail();
endif;
endforeach;
endif; ?>
ポイントは「$bcBaser = $this->BcBaser;」して$bcBaserを無形関数に渡して使用するところです。
『ぺちぱな。∞(えいと)』で Vagrant、HHVM、Hackして来た
muraveです。ご無沙汰しております。
もんきー(さる) 2014年5月17日(土)、
ぺちぱな。∞(えいと)〜Hackするのに悪いヤツはいない。HackとCrackを間違えるのに碌なヤツはいない〜
に参加いたしました。
Vagrant環境から構築して、HHVM(HipHopVM)用にPackegeしたBoxファイルを配布、PHPとFacebookがOSSとしてリリースした新言語Hackの比較までやってしまおうという意欲的な勉強会でした。
環境構築でのひっかかり(原因は使用ポートの衝突、CPUの仮想化支援がONになっていなかった等)はありましたが全員完走でした!
この勉強会の資料がすばらしくて(もちろん資料だけではないですけど)、懇親会でも@hideAki76氏を褒めちぎっていたのですが、この資料が公開されましたよ!ということをみなさまにも強くお伝えしたい。
つたない内容だけど公開。gitbookが素晴らしすぎた。 | ぺちぱな。∞(えいと) http://t.co/Dl51gufblz
— hideAki™ (@hideAki76) May 19, 2014
自習するにはHHVM用Boxの問題がありますが、HHVM用環境構築のプロビジョニングについても書いてあるのでどうになるんじゃないでしょうか。すばらしい。
HHVM、はやくdebian系じゃなくても気軽に動かせるようになるといいな。
長崎国体・大会アプリがリリースされました!
- 2014/05/16
- yoshida