Postfix で IPv6 無効化
Network で IPv6 無効化 していたので、Postfix が起動しなくなっていた。
- /etc/sysctl.conf
net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1
以下サイトより。
Postfixのぺーじ−ホーム
Postfix IPv6サポート
- /etc/postfix/main.cf
# inet_protocols = all inet_protocols = ipv4
これで Postfix 再起動で解決。
Effective Ruby
- 作者: Peter J. Jones,arton,長尾高弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/01/09
- メディア: 大型本
- この商品を含むブログ (13件) を見る
やっと全部読んだ。
正直あまり面白い本だとは思わなかったので、まだ自分のレベルに見合っていないのだと思う。
メタプログラミングとテストについては以下の本を読んだ方が良い。
- 作者: Paolo Perrotta,角征典
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/10/10
- メディア: 大型本
- この商品を含むブログを見る
PGroonga を試す
Ruby on RailsでPostgreSQLとPGroongaを使って日本語全文検索を実現する方法 - ククログ(2015-11-09)
最近ちょっと PostgreSQL が楽しくなってきたところ、ちょうどクリアコードさんのブログで全文検索、PGroonga のチュートリアル記事が出てた。
今回、PostreSQL 9.5 beta 1 で試したので、ソースからインストールした。
あとはまるきり手順通り。すごい簡単にできた。
※ 追記: task に :environment をつけること。
コマンド実行時につけるというのもあるようだが、素直にコード中に記述した方がよいと思う。
PostgreSQL 設計・運用計画の鉄則
内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 (Software Design plus)
- 作者: 勝俣智成,佐伯昌樹,原田登志
- 出版社/メーカー: 技術評論社
- 発売日: 2014/09/04
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
読んだ。最近、この本を読む前に、ストリーミングレプリケーションを試したばかり。
以下記事を読みながら試した。lets.postgresql.jp
期待通りの動作はしたのだが、正直ただ記事に沿って動かしただけで、ぼんやりしていた。
それがこの書籍を読んで、なるほど、そういうことかと合点がいった。
本番運用をするにあたり、どのように設計するのか、なにを監視をするのか
悩んでいたので、これは読んで良かった。
バックアップとリカバリについては、定期的に練習しないといざというときに余計な時間がかかりそうだ。
ITAC かなんかでも、定期的なリカバリの検証をしないといけないんじゃなかったっけ。
ほんと、やっとかないと自分が泣くことになりそう。
入門Redmine
入門Redmine―オープンソースの課題管理システム 第4版
- 作者: 前田剛
- 出版社/メーカー: 秀和システム
- 発売日: 2014/12/13
- メディア: 単行本
- この商品を含むブログを見る
読んだ。
いや、この本は「読んだ」で終わらせてはいけない。「使った」でないと。
著者は MyRedmine というサービスや、Redmine.JP を運営されている。
SlideShare にも Redmine 関連資料を上げている、Redmine 愛に溢れた方だ。
見所はやはり、3版には無かった Redmine を使った体験談。
「高専生が Redmine を使ってロボコンに挑んでみた」、なんてラノベか漫画であっても良いなぁ、と思った。
いや、ほんとにいいんじゃない?
Redmine、以前どこかで Trello の方がよい、みたいな話を聞いた。trello.com
Trello、確かに ToDo管理においてはとってもよい。その手軽さ、見やすさは Redmine を上回る。
ただ、言ってしまえば Trello はそこに特化しているので、個人的には Redmine の代替手段ではないと思っている。
Redmine の一番の強みは、過去/現在/未来の情報の一元管理、だと思ってる。
長期スパンの計画、過去のチケット情報、Wikiなどなど。
このあたりに魅力を感じず、今現在の、目の前のタスクをただこなせれば良い、ということであれば、
Redmine は 過剰なので、Trello を使えば良いと思う。
しかし、高専生でもやってることを、いい年こいた自分ときたら・・・。
UPDATE での Primary Key の更新について
達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)
- 作者: ミック
- 出版社/メーカー: 翔泳社
- 発売日: 2008/02/07
- メディア: 単行本(ソフトカバー)
- 購入: 54人 クリック: 1,004回
- この商品を含むブログ (78件) を見る
勉強中。
SQL って、コーディング規約とかあまり見かけないなので、どう書いていいか困る。
Kindle で買って、今何ページ目か分からないけど、6% まで。
今のところ、違和感がある文・説明が以下。
UPDATE sometable SET p_key = CASE WHEN p_key = 'a' THEN 'b' WHEN p_key = 'b' THEN 'a' ELSE p_key END WHERE p_key IN ('a', 'b') ;
p_key はプライマリキーなのだが、PostgreSQL と MySQL では重複エラーになる。
このことに対して、
本来、制約は文よる変更が終わった時点で施行されるものであるため、実行途中で一時的に重複が生じても問題はありません。事実、Oracle、DB2、SQL Server では問題無く実行できます。
とあるが、これは本当にそうなのか?UPDATE が完了されるまでは、現時点での状態に合わせてチェックされるのが普通かな?と思ったので、PostgreSQL と MySQL の挙動のほうが納得できる気がしている。
その他商用DBの方が独自の実装が多いような印象(ほんとに勝手なイメージだけど)がある。
何を正とするか、だけど、PostgreSQL なんかはSQL準拠頑張ってると聞いたこともあるし。
マニュアル見ても、指摘されている「おかしさ」については説明されていない。
https://www.postgresql.jp/document/9.4/html/sql-update.html
このコマンドは標準SQLに準拠しています。 ただしFROM句およびRETURNING句はPostgreSQLの拡張です。 UPDATEでWITHが使用可能であることも同様に拡張です。
たいしたことじゃないかもしれないが、モヤモヤするな。