最近、cap deploy がしんどい。
こんな感じで、デプロイすると CPU の使用率が高まってしまう。Unicorn が暴走してるっぽい。シンボリックリンクとかはちゃんと置き換わってるんだけど、プロセスが古いままで、サイトの出力が新しくデプロイしたものに置き換わらない。こうなると cap deploy:restart とかやっても無反応で、ssh でログインして Unicorn を一旦停止し、手動で Lokka を再起動しないといけない。
拡散お願いしますアドベントカレンダー2012 に参加したとき、記事を公開してすぐサイトが落ちてしまって「やっぱりスモールマイクロインスタンスでは人気サイトポータルシットを運用するのは無理なのかな」と思ったのだけどどうもアクセスが集中して落ちたわけではないっぽい。
何なんだろう。
P_BLOG 使ってた頃から過去記事タイトルを一覧表示する機能は自分で自分の記事を読み返すときに重宝していて、この機能が欲しかったので作った。過去記事を全部一覧表示すると重いので一年分ずつ表示するようにした。便利。
ソースコードは以下。
ちなみにテストはありません。悪しからず。
一個前の記事で書いた「記事の更新時に updated_at ではなく created_at が更新されてしまう」問題、原因はプログラム側にあるのではなく、MySQL の設定の問題だった。
mysql> desc entries;
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
| id | int(11) | NO | PRI | NULL | auto_increment |
| user_id | int(11) | YES | | NULL | |
| category_id | int(11) | YES | | NULL | |
| slug | varchar(255) | YES | | NULL | |
| title | varchar(255) | YES | | NULL | |
| body | text | YES | | NULL | |
| type | text | NO | | NULL | |
| draft | tinyint(1) | YES | | 0 | |
| created_at | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP |
| updated_at | timestamp | NO | | 0000-00-00 00:00:00 | |
| frozen_tag_list | text | YES | | NULL | |
| markup | varchar(255) | YES | | NULL | |
+-----------------+--------------+------+-----+---------------------+-----------------------------+
12 rows in set (0.00 sec)updated_at と created_at の設定値が逆になってたのが原因。ALTER 文でカラムの情報を入れ替えておいた。
MySQL に流し込んだ Sqlite3 のデータを dump したやつの CREATE TABLE entries を見ると以下のようになってた。
CREATE TABLE `entries` (`id` integer PRIMARY KEY AUTO_INCREMENT, `user_id` integer, `category_id` integer, `slug` varchar(255), `title` varchar(255), `body` text, `type` text NOT NULL, `draft` boolean DEFAULT '0', `created_at` timestamp, `updated_at` timestamp, `frozen_tag_list` text, `markup` VARCHAR(255));なんでこれが created_at に対して更新時に現在時間を上書きし、 updated_at は作成時のみ現在時刻が入るようになるのかは分からない。
それにしても日頃 MongoDB ばかり使っていて、データにおかしなことがあるのはほぼ間違いなくコードのせいだと思う癖がついていることが今回よくわかった。データベースのスキーマを見てみるまでに3日くらい時間がかかった。とほほ。
一方でデータベース内のデータ構造のことをあまり考えなくてよく、開発のみに集中すればよい MongoDB はやっぱり便利だなと思った。規模がでかくなったり高速な読み書きをさばかなければならない状況だと MongoDB にも色々問題があるのでしょうけどね。
Lokka 、データベースはずっと SQLite で使ってたけど仕事で MongoDB を使っているため SQL 力の弱まりを感じてきたので MySQL に変えてみた。SQLite3 から MySQL への移行は意外と面倒くさくて、以下の Redmine の手順を参考にやってみた。
- Strip out PRAGMA lines
- Strip out BEGIN TRANSACTION; lines
- Strip out COMMIT; lines
- Strip out DELETE FROM and INSERT INTO the sqlite_sequence table
- Replace AUTOINCREMENT with AUTO_INCREMENT
- Replace DEFAULT ‘t’ and DEFAULT ‘f’ with DEFAULT ‘1’ and DEFAULT ‘0’
- Replace ,’t’ and ,’f’ with ,’1’ and ,’0’
- Replace “ with ` except in string values (otherwise it replaces all quotes in your text)
↑の通りにやっておおむねうまくいったんだけど、なんか過去の記事を編集して更新すると、updated_at カラムだけじゃなく created_at まで更新されてしまうっぽい。SQLite で使ってるときにはそんなことなかったんだけどなぁ。これは問題な気がする。DataMapper のバグかな。土日で余裕があったら調べてみる。
VM 上の Scientific Linux で Jenkins を動かしていて、テスト結果のグラフが表示できない問題に遭遇していた。出るエラーメッセージは以下のようなもの。
Graphics N/A
Unable to access X. You need to run the web container in the headless
mode. Add -Djava.awt.headless=true to VM.OpenJDK が原因らしい（jenkinsでGraphics N/Aが出た時にしたこと | ミラボ）。
OpenJDK をやめて Oracle の JDK に変えればいいらしいのだけど、 OpenJDK でもグラフ表示できている人はいるっぽいし、ソースから Java を入れるのが嫌なので OpenJDK で何とかする方法を探していた。
もろもろ情報をあさってみたところ、どうもフォントがないのが問題らしい。
Jenkins の wiki にあるとおりに /var/log/jenkins/jenkins.log を漁ってみたら、以下のようなエラーメッセージを発見した。
Caused by: java.lang.Error: Probable fatal error:No fonts found.これに対して公式 wiki には
Obviously graphics rendering needs access to font metrics. So check java /etc/java-6-openjdk/fontconfig.properties and install missing fonts. OpenJDK refers to DejaVu-Fonts. So type:
sudo apt-get install ttf-dejavu
とあるので、yum search dejavu して dejavu って名前がついてるフォントを片っ端から入れたらちゃんとグラフが表示されるようになった。
お困りの方はお試しください。
最近、会社でリーダブルコードを輪読したり、Fukuoka.rb で Eloquent Ruby を読んだりしていて、メソッドや変数名の長さやコメントについての議論を読む機会があった。
昨日、たまたま 37signals のブログを読んでいたら、Rails の作者である David Heinemeier Hansson もこのトピックについて書いていた。
自分は WEB+DB PRESS で ukstudio さんの書いた RSpec についての記事を読んで感化されて以来、ソースコード中のコメントはすべて悪で、はっきりしたメソッド名、変数名を使えばコメントはいらないという考え方を持っている。DHH もそのような考え方のようだ。
要点をかいつまむ。
多くのプログラマーは短い変数名やメソッド名を好む。短い命名は明確性や簡潔性を犠牲にしているとみんな気づいてるんじゃないかと疑ってるんだけど、実際のところ短い命名を採用したコードが多い。特に「一行は80文字まで」教の連中に。
しかし最近のプログラミング言語は表現豊かなのだから、短い命名にこだわる必要は無い。
extension を ext と略してあるのを見かけると嫌気がさす。アプリケーション固有の略語を作るのはもっとひどい。そんなの二ヶ月後には絶対忘れてる。
過剰に明瞭な名前は一見するとバカっぽい。処理内容よりもメソッド名の方が長いとかね。でも一発でやってる内容が分かることの前ではそのバカっぽさは霧消する。
最近の Basecamp のコードにはこんなのがある。
def make_person_an_outside_subscriber_if_all_accesses_revoked person.update_attribute(:outside_subscriber, true) if person.reload.accesses.blank? end def shift_records_upward_starting_at(position) positioned_records.update_all "position = position - 1", ["position >= ?", position] end def someone_else_just_finished_writing?(document) if event = document.current_version_event !event.by_current_creator? and event.updated_at > 1.minute.ago end endもし十分に明確な命名をしているのであれば、コードにコメントを書く必要がない。コメントというものは往々にして不明瞭な命名をしているコードの中で必要になる。コメント付きのコードはやばい臭いを放っていると思っといた方がいい。
リーダブルコードの中にも「名前は短いコメントだと思えばいい」というくだりがあるけど、基本的にあの本には「いいコメントを書け」と書いてあるような気がする。コメントそのものを悪いとみなしていない。
先々週読んだ Eloquent Ruby の Chapter 8. Embrace Dynamic Typing の中では Ruby という言語の特性も踏まえ、コメントはいらないと書いてあった。
例えば Ruby ではメソッド名の最後にはてなをつけてあると Boolean を返すという慣習がある。だからコードの中に「○×を判定し true/false を返します」というようなコメントはいらない。
def is_longer_than?(number_of_characters)
@content.length > number_of_characters
endEloquent Ruby は Chapter 1 でもコメントについて述べている。そこには「コメントを書くべき理由があるコードもある」と書いてある。そのコードの使い方を指南したコメントだ。「なぜそのようなコードを書いたのか」、「コード内で用いているアルゴリズムの説明」、「どのようにして高速化したか」というようなことは書くべきではないと言っている。この辺はリーダブルコードと正反対だ。リーダブルコードでは「なぜそのような実装にしたのか」を積極的に書くように奨励されていた。
ちょっと前にはてブでホッテントリに入ってた、ソースコード内のコメントでコードレビューをやるというやり方は最悪だと思う。売り物のコードの中でああでもないこうでもないと議論するなんて狂ってる。コードが修正されたときに議論の内容まで適切に修正されるとは思えない。下手をするとコメントとコードの内容が正反対になってしまうかも知れない。コードの背景についてはコード内に書かず、GitHub 使ってインラインコメントでやった方が良いと思う。
皆さんはどう思いますか？
だいぶ前の記事では Jekyll は Git の hook を使って公開してると書いてた。
しかし記事の本数が増えてくると、 jekyll コマンドで生成した静的なファイルも Git でトラックするのがだるいと感じるようになった。ので Rakefile に以下のような task を追加して、公開先のサーバーに rsync でファイルを転送するように変更した。
desc "Publish"
task :publish do
path = File.expand_path("_site")
if system("rsync -avz --delete #{path}/ portalshit:sites/tech.portalshit.net/_site/")
puts "Your blog was successfully published!"
else
puts "Something went wrong..."
end
endだいぶデプロイが手軽になった。