思考の軌跡

Instapaperとの連携に悩んだ結果、Evernoteアカウントを追加した件

2012-01-13T14:46:25Z

遅ればせながら、あけましておめでとうございます。今年もよろしくお願いします。

今日は「Instapaperという"あとで読む"サービスで読んだウェブページをどこかに保存しておきたい」と思いEvernoteとの連携をあれこれ悩んだ結果、ウェブページ保存用のEvernoteアカウントを追加しました。という他愛もないお話です。

はじめはPinboardに入れて満足していたが…

Instapaper では「Like」したウェブページを Pinboard というブックマークサービスに登録する機能があるので、初めはこれを設定して満足していたんですが…

PinboardにはURLとページのtitle, descriptionしか保存されないので、ページの内容から検索できない(ただし Bookmark Archive という有料オプションを申し込むことで全文検索が可能らしい)
サイトによってはタイトルが文字化けするのでタイトルによる検索も怪しい
ページの内容から自分でタグ付けすれば検索性は上がるが、面倒なのでタグ付けなどしない

といった不満が出てきました。

Evernoteに保存してみるが…

「タグ付け面倒なら全文検索してくれるEvernoteに入れればいいんじゃね？」と考えてInstapaperで「Like」したものをEvernoteに保存する設定もしたんですが…

保存先のノートブック、タグを指定できない

のが気に食わず。「Like」じゃなくて「Share」すれば指定できるんですが、3ステップくらい増えて面倒。「デフォルトのノートブックに保存されたっていいじゃないか」と考えることもできますが、自分で書いたノートと他人様のウェブページがごっちゃになるのは個人的にいただけない。

同じような"あとで読む"サービスの Read it Later も試しましたが…

Evernoteに保存することはできるがノートブックの指定はできない
Instapaperの「Like」のような1アクションで済まない

という理由から乗り換えもできず。

結果としてウェブクリップ用のEvernoteアカウントを追加することに

「Like」1アクションでEvernoteに保存したい
デフォルトノートブックに保存されて困らないようにしたい
自分のノートとは何かしら区別したい

なんて考えていたら「ウェブクリップ用のEvernoteアカウントを追加して、Likeしたらそこに保存すればいいんじゃ？」と思いつきました。

というわけで、

別のメールアドレスでEvernoteアカウントを追加
Instapaperで「Like」したウェブページを、追加したEvernoteアカウントのノートブックに保存されるよう設定
追加したアカウントのノートブックをメインのアカウントと「共有」

してみました。他にもっといい方法があるかもしれませんが、今のところうまくいっている気がします。

ところでアナタ、インプット術で終わってちゃダメですよ。もっと自分なりのアウトプットしないと…。

herokuでRedmine(1.2.1)を動かす(後編)

2011-08-24T05:22:35Z

前回はひとまずローカルでRedmineを動かしてみました。今回はさらにheroku用の修正を加えてデプロイしてみます。

herokuの制約

herokuでRedmine1.2.1を動かす場合、以下の制約が関係してきます。詳細は後ほど触れます。

書き込みできるのはtmp, logディレクトリ以下のみ
- Heroku | Dev Center | Read-only Filesystem
- 永続ストレージとしての保証もない
Redmine1.2.1が要求するRails2.3.11が動作するのはbambooスタック
- Heroku | Dev Center | Deploying Rails Apps
対話型のRakeタスクは実行できない
- Heroku | Dev Center | Interactive Rake Tasks

heroku gemをインストールする

アプリケーションの管理ツールを提供するheroku gemをインストールします。あわせてherokuアカウントのサインアップと公開鍵の登録がまだであれば済ませておきましょう。

$ gem install heroku

参考: Heroku | Dev Center | Installing the Heroku CLI

herokuに合わせた修正

herokuの制約に対応するため、以下の修正を加える必要があります。

1. plugin_assetsディレクトリをリポジトリに追加

Railsの起動時にRails Enginesがpublic/plugin_assetsディレクトリを作成しますが、herokuではpublic以下に書き込み権限がありません。Engines.public_directoryを書き込み権限のあるtmp以下に変更することもできますが、plugin_assetsディレクトリはプラグインに含まれる画像などがコピーされる場所なので、ブラウザから参照可能なpublic以下である必要があります。
そこで.gitignoreから以下の行を削除し、ローカルで作成されたディレクトリをリポジトリにコミットしておくことにしました。

/public/plugin_assets

2. session_store.rbをリポジトリに追加

通常の手順でRedmineをデプロイする場合、generate_session_store Rakeタスクでクッキーストアセッション用のsecret値を設定しますが、herokuではこのRakeタスクを実行できません。(これも権限のないconfig/initializers以下にファイルを書き込もうとするから)
今回は リポジトリを第三者に公開しない という前提で、ローカルに作成済のconfig/initializers/session_store.rbをリポジトリにコミットしておくことにします。

# .gitignoreから以下の行を削除
/config/initializers/session_store.rb

3. Attachment.storage_pathをtmp以下に変更

Redmineにアップロードしたファイルの保存場所Attachment.storage_pathも、書き込み権限のないfilesディレクトリがデフォルトなので変更しておきます。config/initializers以下にパッチを置いて、ひとまずtmp以下に保存することにしました。

# config/initializers/change_storage_path.rb
storage_path = File.join(RAILS_ROOT, 'tmp', 'files')
Attachment.storage_path = storage_path
FileUtils.mkdir_p(storage_path) unless File.exist?(storage_path)

なお上記の対応だとcache_classes = falseなdevelopmentモードではRAILS_ROOT/filesを示し続けるのでご注意ください。

※これではファイルアップロードの対応として不十分

前述のとおり tmp以下は永続ストレージとして保証されていません 。上記の対応では「一時的にファイルのアップロード、ダウンロードが動作するように見える」だけです。ファイルアップロードを使う場合は、S3などの外部ストレージに保存するよう改修する必要があります。

参考: Heroku | Dev Center | Uploading Files to S3

コミット

以上の修正をローカルリポジトリにコミットしておきます。コミット対象は以下です。

.gitignore
config/initializers/change_storage_path.rb
config/initializers/session_store.rb
public/plugin_assets/

herokuにデプロイ

アプリケーションの登録

まずherokuにアプリケーションを登録します。実行環境であるスタックは、Redmine1.2.1の要件(Rails2.3.11とRuby1.8.7)に合わせてbamboo-ree-1.8.7を指定します。

$ heroku create --stack bamboo-ree-1.8.7

herokuリポジトリにpush

ローカルリポジトリにコミットした内容をherokuリポジトリにpushします。今回は1.2.1-for-herokuというローカルブランチで作業した内容をherokuのmasterブランチにpushするので、以下のように指定します。

$ git push heroku +1.2.1-for-heroku:master

毎回指定するのが面倒な場合は、以下の設定を追加しておけば省略できます。

$ git config --add remote.heroku.push +refs/heads/1.2.1-for-heroku:master
$ git push heroku

タイムゾーンの設定

今回はデータベースに日本標準時で時刻を保存することにします。
heroku実行環境でタイムゾーンを確認したところPDT(太平洋夏時間)でした。

$ heroku console
>> Time.now.zone
=> "PDT"

このままだとデータベースに記録される時刻もPDTになってしまうので、環境変数TZを設定しておくことにします。

$ heroku config:add TZ=Asia/Tokyo
$ heroku console
>> Time.now.zone
=> "JST"

なおUTCで保存する場合は、config/environment.rbに以下の設定を追加したうえでRedmineのユーザー毎にタイムゾーンを設定する必要があります。

config.active_record.default_timezone = :utc

データのセットアップ

run:rakeサブコマンドでRakeタスクを実行し、データベースのスキーマと初期データを設定します。前述のとおり対話型のRakeタスクは実行できないので、環境変数で言語(以下の場合はja)を指定する必要があります。

# マイグレーション
$ heroku run:rake db:migrate

# 初期データの投入
$ heroku run:rake REDMINE_LANG=ja redmine:load_default_data

なお上記2つのRakeタスクを使わず、ローカルデータベースの内容をコピーする方法もあるようです。

参考: Heroku | Dev Center | Importing and Exporting Your Data

ブラウザで開く

以上でデプロイ完了です。openサブコマンドを使ってブラウザからアクセスしてみてください。

$ heroku open

セキュリティ設定

くれぐれもadminユーザのパスワード変更をお忘れなく。プライベートに使う場合はAdministration – Settings – Authenticationメニューから以下の設定をしておくとよいでしょう。

“Authentication required”を"ON"
“Self-registration”を"disabled"
“Lost-password”を"OFF"

対応していないこと

今回の作業では以下について触れていません。必要に応じて設定してください。

メール送信の設定
- Redmine – EmailConfiguration – Redmine
- Heroku | Dev Center | Sending Email from Your App
データのバックアップ
- Heroku | Dev Center | Heroku PG Backups

おわりに

「なんとなく動く」まではそれほど時間がかかりませんでしたが、Redmine(とRails)の仕様とherokuの制約を調べていくと「これでは不十分」となることが後からみつかりました。何事もそうですが、採用するプラットフォームの仕様をきちんと把握することが重要ですね。

herokuでRedmine(1.2.1)を動かす(前編)

2011-08-19T15:50:15Z

プライベートで Redmine を使いたくなったので heroku で動かしてみることにしました。 fluxflex を使った方が手軽なのかもしれませんが、自分なりにherokuの仕様やgitのワークフローを理解したかったのでまとめておきます。

制約

(8/21追記)
今回紹介する手順では、ファイルのアップロード・ダウンロード機能が完全には動作しないという制約があります。あらかじめご了承ください。

方針

まずherokuにアップすることを意識しつつ、ローカルでRedmineを動作させてみます。具体的には以下に留意します。

Gitを使って作業する
- herokuへのデプロイに必要
gemのインストールは bundler を使う
- herokuではbundlerを使ってgemがインストールされる
- 参照: Managing Gems

Redmine本家のインストールガイドを参照しながら作業することにします。

準備

以下を準備します。インストール方法などはお任せします。

Ruby
- バージョンは1.8.7
- RedmineはRuby1.9をサポートしていない(バージョン1.2.1時点)
Git
SQLite3
- ローカル動作用DBMSとして
- MySQL, PostgreSQLでもかまいません

ソースコードの入手

公式なミラーではないそうですが githubのリポジトリをcloneします。

$ git clone https://github.com/edavis10/redmine.git
$ cd redmine

herokuに合わせた追加修正が必要なので、最新バージョンのタグからブランチを切って作業します。

$ git checkout -b 1.2.1-for-heroku 1.2.1

gemのインストール

前述のとおり、herokuではgemのインストールにbundlerを使うのでインストールしておきます。 rvm などをお使いの方はその前に設定をどうぞ。

$ gem install bundler

Gemfileに以下を記述し、

source "http://rubygems.org"

gem "rake", "0.8.7"
gem "rails", "2.3.11"
gem "rack", "1.1.1"
gem "i18n", "0.4.2"

group :development do
  # お使いのDBMSに合わせたものをどうぞ
  gem "sqlite3", "1.3.4"
end

インストールします。

$ bundle install

Rails2.3でBundlerを使うための修正

以下に従ってソースコードとGemfileを修正しておきます。

Gemfileには以下を追記しました。rubytreeとcoderayはvendor/gems以下に含まれているので、pathオプションを指定して参照させています。追記が済んだら`bundle check`を実行してgemの参照に問題がないか確認しておきましょう。

gem "rubytree", "0.5.2", :require => 'tree', :path => 'vendor/gems/rubytree-0.5.2'
gem "coderay", "0.9.7", :path => 'vendor/gems/coderay-0.9.7'

database.ymlの設定

お使いのDBMSに合わせてconfig/database.ymlを記述してください。

# sqlite3用
development:
  adapter: sqlite3
  database: db/development.sqlite3

初期データの投入など

用意されているRakeタスクを実行します。

$ rake generate_session_store
$ rake db:migrate
$ rake redmine:load_default_data

ローカル用の設定は以上なので動作確認してみます。

$ script/server

ローカルリポジトリにコミット

ここまでの作業内容をローカルのリポジトリにコミットしておきます。以下のファイルがコミット対象になるかと思います。

Gemfile
Gemfile.lock
config/boot.rb
config/environment.rb
config/preinitializer.rb

$ git add .
$ git commit

herokuへのデプロイについては次回まとめたいと思います。

nanocのautocompileが遅いのでguard-nanocを使ってみる

2011-07-26T04:28:22Z

このブログで使っている nanoc にはautocompileというコマンドがあるのですが、どうにも遅いので guard-nanoc を使ってみることにしました。

経緯

nanocはYAMLなどのデータとテンプレートを組み合わせてHTMLを生成するツールで、このブログもnanocを使って構築しています。

nanocには

ページの生成を行うcompile
ローカルでウェブサーバを立ち上げるview
ウェブサーバを立ち上げつつ、リクエストされたページを再生成するautocompile

といったコマンドがあります。

autocompileを実行しておけば「HTMLテンプレートを修正してブラウザをリロードすれば表示確認ができる」ので便利なのですが、このサイトではページの依存関係が複雑なせいか、再生成にだいぶ時間がかかるようになってしまいました。かといって「ウェブサーバはviewで起動しておいて、テンプレートを修正するたびにcompileを実行」というのは面倒です。

そこでファイルの更新監視ツールである Guard と、nanoc用拡張の guard-nanoc を使ってみることにしました。

インストール

インストールはREADMEのとおりで済みました。私の環境はOSXなのでrb-fseventも入れています。

$ gem install guard
$ gem install rb-fsevent
$ gem install guard-nanoc

Guardfileの作成

gemをインストールしたらinitサブコマンドでGuardfileという設定を記述します。これはguard-nanocのREADMEにある内容だと警告が出るので、watchの引数を正規表現に修正しました。

$ cd /path/to/nanoc_site
$ guard init nanoc

Guardfileの内容

guard 'nanoc' do
  watch(/^config.yaml/)
  watch(/^Rules/)
  watch(/^layouts\//)
  watch(/^content\//)
end

監視と自動コンパイル

設定は以上なので、startサブコマンドを実行してguardを起動します。監視対象になっているcontent以下のファイルなどを更新すると、compileが実行されてページが再生成されます。autocompileよりも「待たされる感」がないので快適です。

$ guard start

Growlによる通知

Growl によるポップアップ表示にも対応しています。

growl gem と growlnotify がインストールされていればデフォルトで表示されます。表示したくない場合はguardの起動時に “--notify false” と指定するか、環境変数GUARD_NOTIFYにfalseを設定しておけばよいです。

AppEngine(Python)のテスト環境を整える

2011-05-06T05:20:07Z

前回までに引き続き、今度はAppEngineのテスト環境を整えてみたいと思います。

noseを導入する

nose を使うことで、

unittest.TestCaseを継承しなくてもテストコード扱いしてくれる
自分でテストスイートを作らなくてもよい

といったメリットがあるようなので導入してみます。

pbp.recipe.noserunner というbuildout用のレシピが公開されているので、buildout.cfgにtestというパーツを追加してみました。

[buildout]
parts =
    gae_sdk
    gae_tools
    app_lib
    test
(中略)
[test]
recipe = pbp.recipe.noserunner
extra-paths = ${gae_tools:extra-paths}
working-directory = ${buildout:directory}/app

bin/buildoutを再度実行すると、bin/testというスクリプトが追加されるので、ためしに以下のコードを追加してテストを実行してみました。

app/test/lib/foo_test.py

import unittest
from foo import Foo

class TestFoo(unittest.TestCase):
    def test_foo(self):
        f = Foo()
        self.assertEqual('foo', f.foo())

app/lib/foo.py

class Foo:
    def foo(self):
        return 'foo'

うまく動いたようです。

$ bin/test
.
----------------------------------------------------------------------
Ran 1 test in 0.013s

OK

NoseGAEを使う

noseにはAppEngine用の NoseGAE というプラグインがあるので合わせて導入してみます。これは主に、

機能テストを書ける
Datastoreなどを利用したテストを書ける(AppEngineのSDKをロードパスに追加してくれる)
AppEngine上で利用できないはずのライブラリ(socketなど)を無効にしてくれる(sandbox化)

といったメリットがあるようです。
buildout.cfgのtestパーツを以下のように修正してみました。(eggs, defaultsの指定を追加)

[test]
recipe = pbp.recipe.noserunner
extra-paths = ${gae_tools:extra-paths}
working-directory = ${buildout:directory}/app
eggs =
    distribute
    nosegae
defaults =
    --with-gae
    --gae-lib-root
    ${buildout:parts-directory}/google_appengine

なるべくbin/dev_appserverと同じ参照にしたいと考え、eggsの指定は最低限にしてみました。distributeを指定しないとNoseGAEプラグインが有効にならなかったのですが、これでよいのかちょっと自信がないです。
--gae-lib-rootオプションは指定しないと/usr/local/google_appengineを参照してしまうので、buildoutで用意したSDKのパスを指定しています。
noseの--whereオプションを使う場合は、--gae-applicationオプションでapp.yamlのあるディレクトリを指定する必要があるようです。(詳細はNoseGAEのソースを参照)

これでDatastoreなどに依存したコードのテストも実行できると思います。buildoutを使えばNoseGAEを使わなくてもロードパスの調整はできるので、sandbox化以外のメリットをあまり実感できていませんが…。
あと今後はVersion 1.4.3のSDKから追加されたTestBedを使っていきたいと思っています。( 参照 )

続・OSX(10.6)でAppEngine(Python)の開発環境を整える

2011-04-27T16:36:16Z

前回の続きです。今回は.gitignoreの設定とSDKのバージョン変更をしてみます。

.gitignoreの設定

前回の作業の成果をgitリポジトリに入れておきたいと思います。ですがこの中にはbuildoutがダウンロード・作成したライブラリやスクリプトが含まれています。これらは環境毎に用意するものなので、リポジトリ管理対象からはずしておきます。(bootstrap.pyやbuildout.cfgなどをコミットしておけばいいはず。)

以下内容の.gitignoreファイルを用意してみました。「tipfyのプロジェクトテンプレートに含まれるファイルはコミットし、buildoutが用意するものは除外する」という意図で書いています。

.installed.cfg
*.pyc
app/lib/dist
bin/*
!bin/README.txt
eggs
var/downloads/*
!var/downloads/README.txt
var/parts

OSX(10.6)でAppEngine(Python)の開発環境を整える

2011-04-21T16:59:13Z

Google AppEngine(Python)を以前からちょこちょこいじっていますが、環境構築について手探りな状況が続いていました。ですがエキスパートPythonプログラミング読書会に参加させていただいて知識を得られたので、あらためて開発環境を整えてみたいと思います。

Pythonのバージョン

手元の環境(MacOSX Snow Leopard)にはデフォルトでPythonがインストールされていて、そのバージョンは2.6.1でした。

$ python --version
Python 2.6.1

AppEngine実行環境のPythonはバージョン2.5(※)なので、開発環境もそれに合わせる必要があります。OSXでは /System/Library/Frameworks/Python.framework/Versions 以下に過去のバージョンもインストールされているので、今回はこれを使ってみます。
(※ Googleのドキュメントを参照すると2.5.2とあります)

(4/24追記)

上記インストール済みPythonはバージョン2.5.4だったため、以下からOSX用のパッケージ(バージョン2.5.2)をダウンロード・インストールして使うことにしました。このパッケージは /Library/Frameworks/Python.framework/Versions 以下にPythonをインストールするようです。

http://www.python.org/download/releases/2.5.2/

buildout

環境変数PATHを自分で調整することでPythonのバージョンを切り替えることもできますが、ここでは構成管理ツールである buildout を使うことにします。
buildoutを使うメリットとして以下が挙げられます。

依存ライブラリをシステム領域とは別に用意できる(システム領域を汚さない)
依存ライブラリの管理を自動化
Pythonインタプリタの切り替え

tipfy

AppEngineのSDKにはwebappというフレームワークが含まれていますが、今回は tipfy を使ってみます。
tipfyはAppEngine用に作られたフレームワークで、はじめからbuildoutでの環境構築を考慮した形式で配布されています。

環境構築

前置きが長くなりました。 tipfyのサイトから"do-it-yourself archive"をダウンロード・展開して、projectディレクトリに移動します。

$ wget http://www.tipfy.org/tipfy.tar.gz
$ tar xvf tipfy.1.0b1.tar.gz
$ cd project

buildoutの環境を用意してくれるbootstrap.pyが含まれているので、これを バージョン2.5のPython で実行します。

$ /path/to/python25 bootstrap.py --distribute

binディレクトリにbuildoutというスクリプトが作成されます。このスクリプトのシバンを見ると、先ほど指定したバージョンのPythonと紐づいていることが確認できます。続けてこのbuildoutを実行します。

$ ./bin/buildout

buildoutは設定ファイルbuildout.cfgの内容をもとに環境構築を行います。tipfyが提供するbuildout.cfgには以下があらかじめ定義されています。詳しくは appfyレシピのドキュメントを参照するとよいでしょう。

AppEngine SDKのダウンロード、展開
開発サーバ起動スクリプトなどをbinディレクトリに用意
依存ライブラリのダウンロード

これで環境は整いました。binディレクトリに dev_appserver スクリプトができているはずなので、これを実行してブラウザからアクセスしてみましょう。Hello Worldが表示されるでしょうか。

$ ./bin/dev_appserver
$ open http://localhost:8080/
$ open http://localhost:8080/pretty

Hello, World!

bin/dev_appserverやbin/pythonも、bin/buildoutと同じくPython2.5で実行されるようになっています。またライブラリを参照するパスも調整されているので、もしシステム領域にバージョン違いのライブラリがインストールされていたとしても問題にならないはずです。buildout様々ですね。

課題

とりあえずHello Worldは表示されましたが、さらに以下を改善したいところです。

SDKのバージョンが最新ではない
本エントリ執筆時点の最新SDK はバージョン1.4.3ですが、tipfyに含まれるbuildout.cfgの指定は1.4.2になっています。
テストツールを導入したい
テストツールの nose と、そのAppEngine用プラグイン NoseGAE も合わせてセットアップされるようにしたいです。

これらについてはまた後日まとめてみようと思います。

参考にさせていただいたページ

RSSリーダー→Instapaper→Pinboardという情報収集の流れが心地いい

2011-04-19T04:02:44Z

RSSリーダーで情報を集めて、読んで面白かったものはブックマーク。こういったやり方は昔からのものと思いますが、iPhoneなどのスマートフォンが当たり前になってきて、さらに個人個人で好みのやり方を選べるようになってきましたね。
私も最近iPhoneアプリをいくつか使って情報収集をしているので、そのやり方を紹介してみたいと思います。まぁ、目新しい内容はないかもしれませんが…。

最近のやり方に落ち着いた経緯

私は以前、以下のように情報収集していました。

昼休みに会社のMacで
Googleリーダーを開き
気になる記事をタブで開き
片っ端から読む
面白い記事ははてなブックマークに登録

ですが、以下の変化を経てiPod touchで通勤時間中にチェックするようになりました。

光ポータブルをレンタルして外出時もネットにつながるようになった
- SIMはb-mobileSIM U300
はてブからPinboardに乗り換え、Instapaperを使うようになった
- Delicious終了に備えて、Pinboardを使いこなす！ | ZONOSTYLE を読んだのがきっかけ
iPod touchを買い換えてiOS4を使えるようになった
- (後述のDelibarが要iOS4)
昼休みは貴重な作業時間と考えRSSのチェックをやめた

使っているiPhoneアプリ

現在私が情報収集用に使っているiPhoneアプリは以下です。

RSSリーダー: Reeder

RSSリーダーアプリのReederを使って、Google Readerに登録したフィードを購読しています。購読といってもこのアプリで読むわけではなく、気になる記事はいったんInstapaperに送ります。ReederはInstapaperへの送信を非同期（送信中も他のフィードを読むことができる）にできるので、待たされなくて良いですね。

twitterクライアント: TweetList

twitterやっていますが、フォローするより非公開リストに登録して読むことが多いです。そんなリスト閲覧中心な私はtwitterクライアントとしてTweetListを使っています。
やはりツイートに含まれるURLも、その場で開くのではなくInstapaperに送信します。こちらはReederと違って送信が終わるまで待たされてしまうのがちょっと残念。

ウェブページ閲覧: Instapaper

で、Google Readerやtwitterから収集したウェブページはInstapaperでまとめて読みます。記事以外の部分（広告など）を取り除いてくれるので余計な情報に触れないで済みますし、通信量も抑えられるので閲覧もスムーズになりますね。
またInstapaperで"Like"したページはPinboardにブックマークされるように設定しています。あと今回の話題からは少しそれますが「あとで試してみよう」なんて思った記事については、このアプリからToDoアプリにタスク登録しています。

ブックマーク: Delibar(Pinboardクライアント)

最後にPinboardのiPhoneクライアントとしてDelibarというアプリを使っています。Instapaperから"Like"すればPinboardにブックマークされますが、タグの設定などはされません。なのでこのDelibarからタグを設定しています。

まとめ

以上のようなかんじで、Instapaperと連携アプリを組み合わせることで

RSSやtwitterから収集したウェブページを
Instapaperでまとめて効率よく閲覧し
気になるものはそのままブックマーク

という流れができてとても心地よいです。
まぁインプットばかりで満足しては意味がないので、もっとアウトプットにつなげないといけませんな。

保育園に0歳児を1年間預けてみた感想

2011-04-13T11:10:00Z

すっかり新学期の季節ですね(ちょっと過ぎてしまいましたが)。我が家でも娘を保育園に預け出してちょうど1年が経ちました。そこで0歳児を初めて保育園に預けた感想をまとめておきたいと思います。

小さい子供を預けることに不安はなかったか？

4月の時点でまだ満7ヶ月だった娘を預けることに不安がなかったと言えば嘘になりますが(入園希望を出す時期はもっと前ですし)、実際にやってみないと分からないので預けてみました。1歳児から預けると倍率がさらに高くなりそう、と思ったのも理由のひとつです。(去年の4月たった2人で始まった0歳児クラスですが、3月までに7人となり、1歳児から入れたのは3人でした)
あくまで結果論ですが、なんとか無事に1年間通えてホッとしています。

病気はつきもの

たくさんのお友達と接するからか、病気はたくさんしました。風邪、とびひ、ヘルパンギーナ、手足口病、ロタウィルス…。1週間なにもなく登園できた週の方が少なそうです。まぁこれは仕方ないですね。

何かしら思うようにいかないことはある

入園当初は離乳食を食べさせるのに時間がかかり、歩くようになったら抱っこをせがまれ、自分で色々できるようになるとわがままが始まり…。大人のペースが通用しない理由はその時々、何かしらありますね。
保育園に預けるのが遅くなって会社を遅刻してしまうこともありますが、余裕を持って行動するしかないですね。(会社の皆さんごめんなさい…)

じいばあをおおいに頼る

妻の実家まで徒歩圏内という場所に住んでいるので、おじいちゃんおばあちゃんには大変助けていただきました。特に先日の地震のときは私も妻も職場から帰れず、おじいちゃんにお迎えを依頼。そのまま夜遅くまで預かってもらいました。
病み上がりの時に預かってもらうこともしばしばでしたから、そばに住んでいなかったら保育園に預け続けるのは難しかったかもしれません。感謝しています。

1歳児ってけっこう色々できる

自分の記憶がないので1歳児がどんなことをできるか分かっていませんでしたが、簡単なパズルとかできるようになっていて「けっこう色々できるんだな」と関心しました。
あとよく保育園から制作を持って帰ってくるのですが「1歳児ってこんなもの作れるのか」と驚かされます。もちろん1から10まで自分で作っているわけではありませんが、1歳児にできる部分をやらせて作品作りに参加させてくれる保育園って、なんだかすごいなぁと思ったしだいです。

苺。唐辛子ではないはず。

何はともあれ感謝

ふりかえってみると、そもそも保育園に入れられたこと、元気に1年間通えたこと、両親や先生方など周りの方にお世話になっていることなど、感謝しなくてはいけないことだらけですね。
まぁ子供を持つってそういうものかもしれませんが、あらためて感謝の気持ちを確認しつつ、これからも子供を通じたおつきあいの中で恩返しできたらなぁと思っています。

ブログをWordPressからnanocベースに移行しました

2011-03-31T11:24:00Z

あの地震以降はじめての投稿になります。被災された方々に心よりお見舞い申し上げます。
さて、今日はブログを WordPress から nanoc というRubyで書かれたHTML生成ツールベースに移行したのでお知らせしたいと思います。

移行した理由

WordPressは充分な機能を備えていてよいと思うのですが、以下の不満を感じるようになり移行を考えていました。

ふだん使わないPHPで書かれていて、修正するのが面倒
プラグインやテーマが豊富にあるが、欲しいものを探すのが面倒
設定項目の一部がデータベースに保存されていて、なんだか見通しが悪い

乗り換え先

乗り換え先の条件として挙げたのは以下です。

Ruby(かPython)で書かれている
レンタルサーバで動く
ローカルで動作確認ができる

toto なんかも良さそうだなと思ったのですが、Rubyで書かれたHTML生成ツールの nanoc を使うことにしました。「使ったことがある」「どんなことができるか試したい」というのが主な理由です。

nanocについて

nanoc はYAMLなどのデータとERBなどのテンプレートを組み合わせてHTMLを生成するツールです。事例としては Redmine.JP Blog などがあります。独自のRubyコードを追加して拡張することも可能です。(たとえばページングなどは自分でコードを書いて実現しています。)

同じようにnanocでブログを公開されている方がいたので参考にさせていただきました。

その他の要素

自分は絵心がカケラもないので Open Designs で公開されているデザインを使わせていただきました。
完全に静的なHTMLにしてデータベースなどは使っていないので、コメントは DISQUS を使ってみました。移行途中でfacebookがコメントシステムを発表したのですが、こちらの方がアカウント選択の幅があって良いかなと。
あとは少々javascriptを使っています。

手に入れたものと手放したもの

Rubyベースにしたので今後修正するときもストレスにならないはず。自分で追加したコードはRSpecでテストを書いています。あと静的なHTMLなのでレスポンスも速い、かな。
WordPressのプラグインで実現していたiPhone・携帯電話用の表示切り替えはあきらめました。まぁ、いいやと…。

これから

ストレスの少ない環境ができあがったので、さぁどんどんと投稿していかないとですね。
というわけでこれからもよろしくお願いします。