Archives

GitLab+JenkinsでTeXを自動ビルドして論文作成と精神を加速させる

Wordを使いながら、こう考えた。

量が増えれば処理が鈍る。画像を移せば落とされる。意地を通すはWordの方だ。とかくにMS帝国は住みにくい。住みにくさが高じると、安い所へ引き越したくなる。どこへ越しても住みにくいと悟った時、TeXが生まれて、GitLab+Jenkinsが出来る。

かの夏目青年は30にしてこのように悟ったわけであるが、今どきの大学院生である私もそのとおりであると思う。Wordを使わない理由は、

  • ページ数が増えると重い
  • 画像のレイアウトが思ったようにならない
  • 勝手にレイアウトを変える (OFFに出来ることは出来る)

など。論文の終盤でこのような理不尽の嵐にさらされて精神を病むものは後を絶たないと聞く。責任者に問いただす必要があるかどうかは別にして、現実を変えたいと願うならばTeXを使うと良い。TeXとは一言で言ってしまえば図とか文とか表を配置するための言語で、Knuth御大がムシャクシャして作ったものだ。

よしではTeXを使おうと思っても準備が必要で、ちょっとググるとLaTexだのpTeXだのXeLaTeXだの出て来て頭がフットーしそうになる。なのでここではそれを簡単に整理してみたい。まずTeXもLaTeXもpTeXもXeLaTeXも*.texファイルを扱うコンパイラで、その目指すところもすべて同じで、

  • 目標: *.texファイルから文書を作る

ことである。この「文書」というのが歴史的にDVIからPostScript、PDFへと変遷してきて、それぞれにコンパイラや変換ソフトが登場してきた。XeLaTeXなんかは*.texからPDFを直接作成できる。

もう一つの軸は多言語対応である。TeXは英語の文書をコンパイルするために作られたので、日本語の文書に対応するにはそれなりの拡張が必要になる。TeXの日本語拡張版がpTeXである。TeXの高機能版であるLaTeXの日本語拡張版はpLaTeXだ。さらにLaTeXの進化版のLaTeX2eの日本語拡張版のpLaTeX2eというものもある。だいたい重要な所をまとめると次の表みたいな感じになる。

tex-900x808

「XeTexとかLuaTeX使えば最強じゃね?」と思われるかもしれないが、そのとおりである。しかもこれらはフォントの指定も出来る。

しかしそれを阻むものがある。学会指定のスタイルファイルである。LaTeX2eもしくはpLaTeX2eに対応したテンプレートが配布されることが多いような気がする。本文のtex記法自体はだいたい使いまわせるので、

  • スタイルが指定されてない: XeLaTeX (LaTeXをサポートしたXeTeX)
  • スタイルが指定されている: みんなそれを使うしかないじゃない(pLaTeX2eが多い)

という具合である。なぜLuaTeXじゃなくてXeLaTeXなのかというと、LuaTeXがまだ評価版であるということ、そのために情報が少ないことが原因である (LuaTeXのバージョン1.0は2012年リリースが予定されていたがまだらしい)。

思わず Lua で LaTeX してみた ~LuaTeX で日本語しない件について~  [電脳世界の奥底にて] 

Differences between LuaTeX, ConTeXt and XeTeX – Stack Exchange

ではインストールから出力するまでにやることを書く。

1. インストール

texliveをインストールする。上述のコンパイラが全部インストールされるので便利。windows/mac/linuxそれぞれ利用可能。しかも編集&閲覧ソフトのTeXWorksも同梱される。macではTeXnicleの方がおすすめだけど。

Installing TeX Live over the Internet

2. スタイルを整える

いろいろググったりした結果できたXeLaTeXのファイル群をGitHubに置いておく。thesisとarticle-single、article-multiの2種類。thesisはchapter>section>subsection構成で、articleはsectionから始まる構成。article-multiはファイルを分散させてる。

Drunkar / tex-template

参考にしたのは以下のサイト

参考文献の管理にはBibTeXを、ソースコードのシンタックスハイライトにはmintedを使っている。

3. コンパイル

BibTeXを使っているので3回コンパイルしなければならない。

#!/bin/sh
mainfile=index
# for mac (add texlive path otherwise.)
PATH=/usr/texbin:/usr/local/bin:$PATH
ENGINE=xelatex
BIBTEX=bibtex

$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile
$BIBTEX $mainfile
$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile
$ENGINE -synctex=1 -file-line-error -interaction=nonstopmode --shell-escape  $mainfile

後TeXnicle用のエンジンはgistに置いた。

 Drunkar / xelatex_bibtex_minted.engine

試しにgithubから取ってきてコンパイルできたらOK.

$ git clone git@github.com:Drunkar/tex-template.git
$ cd tex-template/thesis
$ sudo chmod 755 build_xelatex.sh
$./build_xelatex.sh

とすればindex.texがこんな感じでできる。

article-single, artice-multiも同様。

 4. Jenkinsでやる

まずGitLabにリポジトリを作る。

Jenkinsにも同様のプロジェクトを作ってビルドスクリプトに上記のbuild_xelatex.shを貼り付ける。必要ならパスを追加する。

スクリーンショット_022814_120729_AM

pushでビルド開始するようにgitlab pluginとかを入れる。GitLabとJenkinsが同一サーバの場合は前回の記事を参照。

GitLabとGitLab_CIとかJenkinsを同一サーバで使う場合に必要な設定

GitLabとGitLab_CIとJenkinsはそれぞれ別のユーザーで実行することが想定されています。GitLab_CIに至ってはgitlab_ciユーザーに加えてビルドを実行するgitlab_ci_runnerユーザーも必要です。

アプリケーション想定ユーザー名(デフォルト)
GitLabgit
GitLab_CIgitlab_ci
GitLab_CI runnergitlab_ci_runner
Jenkinsjenkins

この状態でこれらを同一サーバーにインストールすると、GitLabからプロジェクトのコードをcloneするときにAccess denied になります。パーミッションエラーです。それぞれのアプリケーションはそれぞれのホームディレクトリ以下で動いているので, 同一サーバ内だとパーミッションエラーになるわけです。

別のサーバにインストールできればいいのですが、唯一虎の子のサーバしかないということも多々あると思います。そういうときには全部ユーザーgitで動かしちゃえばオールオッケーです。

GitLab_CI , GitLab_CI runner

  • config/database.ymlのユーザーをgitに (GitLab_CI runnerは無い)
  • /etc/init.d/gitlab_ciの
    • APP_USERをgitに
    • GitLab_CI runnerはさらにAPP_ROOTを/home/git/gitlab-ci-runnerに

変更すればオッケーです。

Jenkins

Jenkinsを別ユーザで動かす – kotaroito’s notes 

を参考にして、/etc/sysconfig/jenkinsでユーザーとホームディレクトリを変更し、/var/log/jenkins/, /var/cache/jenkins/の権限を変更します。

JenkinsでGitLabのプロジェクトをビルドするには、Jenkinsプロジェクトの設定を

スクリーンショット_022414_021836_AM-5

こんな感じにすることでcloneできるようになります。8079はGitLabを動かしているポート番号です。

ひとまず動くようになるまではこれでオッケーですが、JenkinsでGitLabへのpushを景気としてビルドするにはもうちょっと手間が必要です。JenkinsにはGitLabプラグインというのがあるのですが、Repository URLに書いたパスにhttpでアクセスすることでpushイベントを登録するみたいで、今回のように絶対パスでGitLabリポジトリを登録した場合はpushに反応してくれませんでした。ですのでJenkinsに直接curlすることでhookすることにします。

curl http://localhost:8088/job/hogehoge/build することでJenkinsのhogehogeプロジェクトがビルドできることをまず確認しましょう。8088はJenkinsの動いているポートです。

そのためにgitのhooks/post-update機能を使います。

cd /home/git/repositories/oreore/hogehoge.git/ でoreoreさんのhogehoge.gitリポジトリに移動し、hooks/post-updateを有効にします。

? mv hooks/post-update.sample hooks/post-update
? chmod a+x hooks/post-update
? vi hooks/post-update

hooks/post-updateは次のように変更します。ハイライトは追加した行

#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".

curl -s http://localhost:8088/job/hogehoge/build
exec git update-server-info

これでGitLabのhogehogeプロジェクトにpushするとcurl -s http://localhost:8088/job/hogehoge/build が実行されるようになります。

それでは素敵なおじさんライフを!

 

GitLab_CI「Jenkinsおじさんには勝てなかったよ…」

こんな即堕ち展開になるはずじゃなかったんだけど・・・

老獪J爺ことJenkinsの方が優れている点

  • パスを指定可能
  • 成果物を閲覧・ダウンロード可能: texコンパイルでpdfを見れる
  • プラグインが豊富
  • インストールも簡単: yumでできる

GitLabからのリポジトリ登録の手間はどっちもほとんど変わらない。同一サーバでの運用の苦労も変わらない(どちらも実行ユーザを作成することを想定しているため)。今回はtexをコンパイルしてpdfを見れるようにしたかったので、Jenkins翁の完全勝利だった。というか、現段階ではGitLab_CIの優れている点は無いと言っていいと思う。

GitLab-6.5 + GitLab_CI-4.2でもうJenkinsおじさんに頼らない

前回の記事でGitLabをCentOSにインストールしました。今回はGitLab_CIをインストールして継続的インテグレーション生活をはじめます。GitLab_CIは出始めのころの導入記事しかなかったのでちょと大変でした。

公式で推奨されている方法は、

  • gitlab -> ユーザー “git”
  • gitlab_ci -> ユーザー “gitlab_ci”
  • gitlab_ci_runner -> ユーザー “gitlab_ci_runner”

とそれぞれにユーザーを作る方法ですが、今回は両方とも1つのサーバに入れるので、全部ユーザー “git”によって操作させることにしました。じゃないとパーミッションとかで困ります。あと”gitlab_ci_runner”ってのは要はビルドスクリプトを実行するアプリで、gitlabを含めて3つのアプリをインストールすることになります。動かすポートは、

  • gitlab -> 8079
  • gitlab_ci ->8080

としてます。特に意味はありません。

ではまずgitlab_ciのインストールから。手順は公式のやり方に則りますが、ユーザーが”git”なのでちょとだけ変更が必要です。また前回同様”?”は”#”を表してます。

1. データベースの準備

いきなりですがデータベースを作っておきます。

? cd /home/git/
? mysql -u root

mysql> CREATE DATABASE IF NOT EXISTS `gitlab_ci_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql>  GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlab_ci_production`.* TO 'git'@'localhost';
mysql> exit

 2. インストール

? sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ci.git
? cd gitlab-ci
? sudo -u git -H git checkout 4-2-stable
? sudo -u git -H cp config/application.yml.example config/application.yml
? sudo -u git -H vi config/application.yml

ソースをとってきてapplication.ymlを次のように書きかえます。gitlabのサーバアドレスと、gitlab_ciのポート番号を変更しています。

defaults: &defaults
  allowed_gitlab_urls:
    # Replace with your gitlab server url
    - 'http://localhost:8079/'

  ## Gitlab CI settings
  gitlab_ci:
    ## Web server settings
    host: localhost
    port: 8080
    https: false
...

puma.rbもちょっとだけ変更

? sudo -u git -H cp config/puma.rb.example config/puma.rb
? sudo -u git -H vi config/puma.rb
    * application_path = '/home/git/gitlab-ci'に変更

ソケットとプロセスのファイルを作成

? sudo -u git -H mkdir -p tmp/sockets/
? sudo chmod -R u+rwX  tmp/sockets/
? sudo -u git -H mkdir -p tmp/pids/
? sudo chmod -R u+rwX  tmp/pids/

データベースをセット

? sudo -u git -H bundle install --without development test postgres --deployment
? sudo -u git -H cp config/database.yml.mysql config/database.yml
? sudo -u git -H vi config/database.yml
    * gitlab_ci_productionのユーザーを"git"に、
    * パスワードをmysqlのユーザー"git"のパスワードに変更

? sudo -u git -H bundle exec rake db:setup RAILS_ENV=production
? sudo -u git -H bundle exec whenever -w RAILS_ENV=production

502 errorにならないようにパーミッションを変更

? chmod -R o+x /home/git/gitlab-ci/

initスクリプト

? cp /home/git/gitlab-ci/lib/support/init.d/gitlab_ci /etc/init.d/gitlab_ci
? chmod +x /etc/init.d/gitlab_ci
? vi /etc/init.d/gitlab_ci
    * APP_USER="git"に変更
? service gitlab_ci start

nginx用のファイル

? sudo cp /home/git/gitlab-ci/lib/support/nginx/gitlab_ci /etc/nginx/sites-available/gitlab_ci
? sudo ln -s /etc/nginx/sites-available/gitlab_ci /etc/nginx/sites-enabled/gitlab_ci
? vi /etc/nginx/sites-enabled/gitlab_ci

gitlab_ciは次のような感じで変更します。ユーザー名とポートですね。

...
upstream gitlab_ci {
  server unix:/home/git/gitlab-ci/tmp/sockets/gitlab-ci.socket;
}

server {
  listen 8080;         # e.g., listen 192.168.1.1:80;
  server_name localhost;
  root /home/git/gitlab-ci/public;
...

これでnginxを再起動後、ポート8080にアクセスすれば、

スクリーンショット_021614_050908_AMやりました。

gitlabのユーザ名とパスワードでそのままログインします。すると、gitlabで作ってるプロジェクトの一覧が出てきます。

スクリーンショット_021614_051326_AM“Add”をクリックするだけで連携可能。刺し身にタンポポをのせるより遥かに簡単です。

と思いきや、”runner”をインストールしろと言ってきます。不穏です。

スクリーンショット_021514_104115_PM_021614_051603_AM

言われた通りにインストールしたいところですが、全部ユーザー “git”ができるもんと言っているので多少の変更を行います。

1. ソース取ってきてbundle install

? cd /home/git
? sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ci-runner.git
? cd gitlab-ci-runner/
? git bundle install

楽勝です

2.  セットアップ

GitLab CIの”Runners”ってとこをクリックするとこんな画面になります。

スクリーンショット_021514_104735_PM_021614_052458_AM

 

このtokenを使ってセットアップします。

? sudo -u git -H CI_SERVER_URL=http://localhost:8080/ REGISTRATION_TOKEN=<token> bundle exec ./bin/setup

うまくいくと秘密鍵が作られて、

Runner registered successfully. Feel free to start it!

って表示されます。

3. initスクリプト

? sudo cp ./lib/support/init.d/gitlab_ci_runner /etc/init.d/gitlab-ci-runner
? sudo chmod +x /etc/init.d/gitlab-ci-runner
? vi /etc/init.d/gitlab-ci-runner
    * APP_ROOT="/home/git/gitlab-ci-runner"に変更
    * APP_USER="git"に変更

で、? service gitlab-ci-runner start でスタートします。

さあではいよいよビルドします。gitlab_ciのダッシュボードからAddしたプロジェクトをクリック > Settings で詳細設定画面を開きます。ここが一番大事なとこですが、Advanced Settings > GitLab url to projectを見て下さい。”http://localhost:8079/ユーザー名/プロジェクト名.git”となっていることと思いますが、これを直接リポジトリの場所を指すように変更します。つまり、”/home/git/repositories/ユーザー名/プロジェクト名”にします。で、セーブ。

スクリーンショット_021614_030344_AM_021614_053140_AM

次にgitlabの方でプロジェクトのSettings > Servicesを見ると”GitLab CI”のところにチェックが入っていると思います。これをクリックして、”Test settings”ボタンをクリックすると、テストのビルドが走ります。またgitlab_ciに戻ってプロジェクトを見てみると、

スクリーンショット_021614_053934_AMおー、ようやくビルド出来ました。それでこれからはgitlabにpushするたびにビルドスクリプトが走るはず、だったんですがそこが何故か走りません…ローカル同士故の問題っぽいですがまだよく分かりません。

とにかく導入までは行けたし一定時間ごとのビルドは出来るのでなんとかはなるかなー

追記: 次の記事も御覧ください -> GitLab_CI「Jenkinsおじさんには勝てなかったよ…」 

GitLab-6.5をCentOS6.4に導入する

(2014/08/10追記) Packageが提供されて、もっと簡単にインストールできるようになりました! → Omnibus GitLabをCentOSにインストール

GitHubクローンのGitLabの最新版6.5(Community Edition)をCentOS6.4に導入します。

コード管理のためにgitは必要不可欠だけど、GitLabがあるとコミット頻度が可視化されたりしてよりモチベーションが上がるのでより良いです。

公式サイトによると必要なのは

  • ruby 1.9.3+
  • git 1.7.10+

らしい。これらはもうすでにインストールされてるものとします。ググって下さい。ちなみに僕の環境では

  • ruby-1.9.3-p429
  • git-1.8.3.4

を入れてました。手順は公式のInstallationに従います。

  1. ユーザーの追加
  2. GitLab shellのインストール
  3. データベースの設定
  4. GitLabのインストール・起動
  5. nginxで振り分け

てな具合です。あと次のページもかなり参考になりました。
継続的インテグレーションツール「GitLab CI」を Amazon Linux にインストールしてみた | Developers.IO

以下の操作は全部rootになってやります。”?”は”#”と読み替えて下さい。コメントアウトされてしまうので?にしてます。

 1. ユーザーの追加

gitlabの操作をするユーザー “git”を追加します

? adduser -c 'GitLab CE' git

おわり

 2. GitLab shellのインストール

? cd /home/git
? sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-shell.git -b v1.8.0
? cd gitlab-shell
? sudo -u git -H cp config.yml.example config.yml
? sudo -u git -H vi config.yml    // 何か変更することがあれば。
? sudo -u git -H ./bin/install

 3.  データベースの設定

今回はmysqlを使います。postgresqlのやり方も公式サイトには書いてます。ユーザー “git”を作って、gitlabhq_productionデータベースの操作権限を与えます。

? mysql -u root -p
mysql> CREATE USER 'git'@'localhost' IDENTIFIED BY '$password';
mysql> CREATE DATABASE IF NOT EXISTS `gitlabhq_production` DEFAULT CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`;
mysql> GRANT SELECT, LOCK TABLES, INSERT, UPDATE, DELETE, CREATE, DROP, INDEX, ALTER ON `gitlabhq_production`.* TO 'git'@'localhost';
mysql> exit

 4.  GitLabのインストール・起動

? cd /home/git
? sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 6-5-stable gitlab
? cd /home/git/gitlab
? sudo -u git -H git checkout 6-5-stable
? sudo -u git -H cp config/gitlab.yml.example config/gitlab.yml
? sudo -u git -H vi config/gitlab.yml

gitlab.ymlにはポートの設定があります。デフォルトは80で、サーバで使うアプリケーションがGitLabだけならそれでいいですが、まだいろいろ追加する予定なので変えます。大概8080とかにすることが多いようです。

...
  ## GitLab settings
  gitlab:
    ## Web server settings
    host: localhost
    port: 8079
    https: false
...

8079にしてみました。(特に意味は無い)

続いてlogやプロセスID、ソケットを格納するディレクトリを作ります。

? sudo chown -R git log/
? sudo chown -R git tmp/
? sudo chmod -R u+rwX  log/
? sudo chmod -R u+rwX  tmp/

? sudo -u git -H mkdir /home/git/gitlab-satellites

? sudo -u git -H mkdir tmp/pids/
? sudo -u git -H mkdir tmp/sockets/
? sudo chmod -R u+rwX  tmp/pids/
? sudo chmod -R u+rwX  tmp/sockets/

? sudo -u git -H mkdir public/uploads
? sudo chmod -R u+rwX  public/uploads

unicornの設定ファイルをいじる

? sudo -u git -H cp config/unicorn.rb.example config/unicorn.rb
? sudo -u git -H vi config/unicorn.rb    // 何かいじりたければ

? sudo -u git -H cp config/initializers/rack_attack.rb.example config/initializers/rack_attack.rb

ユーザー “git”のgit設定を追加

? sudo -u git -H git config --global user.name "GitLab"
? sudo -u git -H git config --global user.email "gitlab@localhost"
? sudo -u git -H git config --global core.autocrlf input

データベースの設定ファイルをいじる

? sudo -u git cp config/database.yml.mysql config/database.yml
? sudo -u git -H vi config/database.yml
// githq_prodyctionのユーザーがgitになっていることを確認
// パスワードを3で設定済みのものに変更
? sudo -u git -H chmod o-rwx config/database.yml

gemsのインストール

? sudo -u git -H bundle install --deployment --without development test postgres aws

ようやくgitlabのセットアップ

? sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production

“Do you want to continue (yes/no)?”と聞かれるので秒速でyes

上手く行けば

    Administrator account created:

    login.........admin@local.host
    password......5iveL!fe

と出るはず。最初のログインはこれで行うので忘れずに。ってもググれば出ますが。

で起動!のまえに、/home/git以下のパーミッションを全部変えちゃいましょう。これしないと後でnginxが tmp/sockets/gitlab.socketでpermission deniedやらなんらやらで502 bad gatewayになります。バッドエンドです。

? chmod -R o+x /home/git/

起動スクリプトをコピーして、

? cp lib/support/init.d/gitlab /etc/init.d/gitlab
? cp lib/support/init.d/gitlab.default.example /etc/default/gitlab
? chkconfig gitlab on
? cp lib/support/logrotate/gitlab /etc/logrotate.d/gitlab

チェックして問題なければ

? sudo -u git -H bundle exec rake gitlab:env:info

起動します

? service gitlab start

assetsのコンパイルもしておきます

? sudo -u git -H bundle exec rake assets:precompile

 5.  nginx

nginxのインストールはどうにかしてやって完了しているとします。gitlabはdebian系がメインターゲットらしくて、/etc/nginx配下にsite-availableとsite-enabledという2つのディレクトリがあります。バーチャルホストの設定ファイルが全部site-availableに置いてあって、有効にしたいものだけsite-enabledからシンボリックリンクを張るというやり方が想定されていてとても便利なのでこれを採用しようと思います。

まずは/etc/nginx/nginx.confに次の行を加えます

...
http {
    include       mime.types;
    include /etc/nginx/sites-enabled/*;   // この行を加える
    default_type  application/octet-stream;
...

それであとは2つのディレクトリを作って、

? mkdir /etc/nginx/site-available
? mkdir /etc/nginx/site-enabled

gitlabの設定ファイルを次のようにします

? cp lib/support/nginx/gitlab /etc/nginx/sites-available/gitlab
? ln -s /etc/nginx/sites-available/gitlab /etc/nginx/sites-enabled/gitlab
? vi /etc/nginx/sites-available/gitlab
...
    server {
      listen 8079;           // 8079で受ける
      server_name localhost; // ここも変更
      server_tokens off;     # don't show the version number, a security best practice
      root /home/git/gitlab/public;
...

nginxも起動して終了!

? chkconfig nginx on
? service nginx start

スクリーンショット_021214_113520_PM

UI綺麗なサービスってなんか全能感ありますよねー。

ちなみに修論でメインだったプログラムのコミット頻度はこんな感じだった。

スクリーンショット_021214_113612_PMうーんこの

Pythonでプロセスを監視して終了したらgmailを使ってメール送信する

ps ax | grep hogehoge | grep -v grep

に”hogehoge”が含まれてるかを確認して無かったらgmailを送信する。

# -*- coding: utf-8 -*-
import commands
import sendGmail
from datetime import datetime
from datetime import timedelta

if __name__ == '__main__':
    arg = ""
    while len(arg) == 0:
        arg = raw_input("input substring of process name: ")

    INTERVAL   = timedelta(seconds=5)
    from_addr = "<FROM_ADDR>@gmail.com"
    passwd = "<PASS>"
    to_addr = "<TO_ADDR>@gmail.com"
    title = arg + " end."
    body = ""

    previous = datetime.now()
    while True:
        if datetime.now() - previous > INTERVAL:
            result = commands.getoutput("ps ax | grep "+ arg + " | grep -v grep")
            previous = datetime.now()
            if arg not in result:
                    msg = sendGmail.create_message(from_addr, to_addr, title, body)
                    sendGmail.send_via_gmail(from_addr, to_addr, passwd, msg)
                    break;

sendGmail.pyは以下のページまんまです。

独学Linux | Python スクリプトでGmail経由のメールを送信する方法

#!/usr/bin/python
# -*- coding: utf-8 -*-
import smtplib
from email.MIMEText import MIMEText
from email.Header import Header
from email.Utils import formatdate

def create_message(from_addr, to_addr, subject, body):
    msg = MIMEText(body)
    msg['Subject'] = subject
    msg['From'] = from_addr
    msg['To'] = to_addr
    msg['Date'] = formatdate()
    return msg

def send_via_gmail(from_addr, to_addr, passwd, msg):
    s = smtplib.SMTP('smtp.gmail.com', 587)
    s.ehlo()
    s.starttls()
    s.ehlo()
    s.login(from_addr, passwd)
    s.sendmail(from_addr, [to_addr], msg.as_string())
    s.close()

if __name__ == '__main__':
    from_addr = "<FROM_ADDR>@gmail.com"
    passwd = "<PASS>"
    to_addr = "<TO_ADDR>@gmail.com"
    title = "title"
    body = "hongyaaa"
    msg = create_message(from_addr, to_addr, title, body)
    send_via_gmail(from_addr, to_addr, passwd, msg)

プロセス監視のツールとかありそうだけどよく分からん…目指せじょうよわ脱却

ec2上のRedmineでプロジェクトを管理しよう!人生という名のp(ry

前回はBitNamiのインストーラを使いましたが、今回は普通にインストールします。

※2013-10-23追記:このやり方だとredmineのdevバージョンがインストールされるみたいなので、svn利用に変更しました。あと2.3.3でも大丈夫っぽいのでそっち使ってます。

インストールしたいのは、

  • Ruby
  • Redmineと必要なbundle
  • redmine_backlogs: v1.0.5    ←    ruby: 1.9.3, Redmine: 2.2.4 or 2.3.2が必要
  • nginx
  • MySQL

です。バージョンの指定がハマりどころですが、言われたら直すの繰り返しでもなんとかなります。

ec2を立ち上げてsshで接続するまではドットインストールのAmazon Web Services入門の#5までを参考に。

まずはいろいろ必要なものと、nginx、MySQLをインストールします。ec2でルートになるには”sudo su”でオッケーです。

$ sudo su
// 注: #はコメントアウトされてしまうので代わりに?を用いてます。
? yum -y groupinstall "Development Tools"
? yum -y install openssl-devel readline-devel zlib-devel curl-devel
? yum -y install mysql-server mysql-devel
? /etc/init.d/mysqld start
? yum install -y nginx
? service nginx start

Ruby 1.9.3のインストールはここを参考にしました。

? yum -y install libxml2-devel
? yum -y install libxslt-devel
? cd /tmp
? wget http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz
? tar zxvf yaml-0.1.4.tar.gz
? cd yaml-0.1.4
? ./configure
? make
? make install

? cd ../
? wget ftp://core.ring.gr.jp/pub/lang/ruby/1.9/ruby-1.9.3-p392.tar.gz
tar xzf  ruby-1.9.3-p392.tar.gz
? ./configure --with-opt-dir=/usr/local --enable-shared --enable-option-checking
? make
? make install

/usr/local/bin/にインストールされてしまったので/usr/bin/にシンボリックリンクを張ります

? mv /usr/bin/ruby /usr/bin/ruby18
? ln -s /usr/local/bin/ruby /usr/bin/ruby
? ruby -v
    ruby 1.9.3p392 (2013-02-22 revision 39386) [x86_64-linux]

rubygemsとbundleのインストール

? wget http://rubyforge.org/frs/download.php/76729/rubygems-1.8.25.tgz
? tar xzvf rubygems-1.8.25.tgz
? cd rubygems-1.8.25
? ruby setup.rb
? gem -v
    1.8.25
? yum -y install ruby-irb
? gem install rdoc
? gem install bundler

やっとredmineのインストールです。場所はBitNamiを真似て/opt/に置きます。

? cd /opt/
? svn co http://svn.redmine.org/redmine/branches/2.3-stable redmine-2.3
? mv /opt/redmine-2.3 /opt/redmine
? bundle install --path vendor/bundle --without development test rmagick postgresql sqlite

以降のMySQLとかnginxとかの設定は下のページのまま行えばよいかと思います。

さくらVPSで nginx + MySQL + Unicorn + Redmine の運用 | コードを舐める日々

そんで、僕の場合は既にRedmineを使っていたデータがあるので、公式情報を参考にしてそれのリカバリをします。filesディレクトリを置き換えて、DBにバックアップしてたdumpをブッ込めば完成です。

backlogsのインストールはredmineのインストール後、公式の通りにやればできます。

Redmine Backlogs :: Installation

あと、Redmineはそのままだと限りなくダサいので、テーマをインストールすると良いと思います。だいたい見た感じではredminecrmのテーマがかなりいいデザインです。crm用のプラグインも提供されてますが、必要ないのでテーマだけもらいます。

http://redminecrm.com/pages/redminecrm-theme

ダウンロードしたzipを/opt/redmine/public/themesに展開して、管理> 設定> 表示> テーマで変更できます。

backlogsの使い方やその心は@ITの連載がいい感じです。

かんばん!~もし女子高生がRedmineで「スクラム」開発をしたら

これからredmine上でいろんなサービスとの連携とかできたら楽しそうだな―と思います。

amazon ec2でRedmine(BitNami編)

あープロジェクト管理してーわー
そんなお前 見込みアリ

というわけでRedmineを使いたいです。でも余分なパソコンはありません。

でも実は誰でも1台だけ無料で使えます。そう、amazon ec2のマイクロインスタンスならね。

しかしRedmineのインストールはRubyのバージョン指定とかなんやらでやたらと面倒臭いです。以前試行錯誤の果てにec2上でnginx+unicornで動かしていたのですが、もうちょっと設定の過程をすっきりさせたくて再インストールしようかなというところでさっそうと現れたのがBitNamiです。

http://bitnami.com/

なんでもワンクリックでRedmineやwordpressやjenkins等々をec2上に構築してくれるというではないですか。

このページの”Cloud Server”のとこをクリックするだけの簡単な構築作業です。

とはいえこれだけだと余りにも過程が不透明なので、インストーラーを使ってインストールしてみます。

まずec2のマイクロインスタンスを立ち上げてsshで接続するところまではドットインストールのAmazon Web Services入門の#5までを参考に。

マイクロインスタンスのメモリは613MBしかなく、RedmineのBitNamiインストーラを使うには2GBぐらい要るよと言われるので、まずはスワップ領域を確保します。

$ sudo dd if=/dev/zero of=~/swap.0 bs=1024 count=1048576
    1048576+0 records in
    1048576+0 records out
    1073741824 bytes (1.1 GB) copied, 28.9288 s, 37.1 MB/s
$ sudo mkswap ~/swap.0
    スワップ空間バージョン1を設定します、サイズ = 1048572 KiB
    ラベルはありません, UUID=c54b30ec-1727-423e-8f55-ce585a2cffe9
$ sudo swapon ~/swap.0

スワップ領域を1GB確保しました。インストールにはこれで充分でした。確保できていることを確認します。

$ sudo swapon -s
    Filename				Type		Size	Used	Priority
    /home/ec2-user/swap.0                   file		1048572	0	-1

そしたらインストーラをとってきて実行するだけです。超簡単。

$ wget http://bitnami.com/redirect/to/24967/bitnami-redmine-2.3.3-1-linux-x64-installer.run
$ chmod 755 bitnami-redmine-2.3.3-1-linux-x64-installer.run
$ sudo ./bitnami-redmine-2.3.3-1-linux-x64-installer.run

設定に関していろいろ聞かれますが、”English”と”Y”で答えとけば問題ないでしょう。Redmineの通知用のメールアドレスを登録したい場合はインストール中にできます。

これでインストールは終了です。簡単すぎて涙が出ます。

redmineのルートは/opt/redmine-2.3.3-1/になります。MySQLとか必要なものは全部この下にインストールされます。なのでデータベースにアクセスするには、

$ sudo mysql -uroot -p -S /opt/redmine-2.3.3-1/mysql/tmp/mysql.sock mysql

みたいな感じになります。面倒ですね。

普通に使う分にはこれで問題ないのですが、こういうローカルなインストールはなんか気持ち悪くて、バージョンの変更とかいうときに非常に面倒じゃないかと思って、結局またnginx+unicornを使うことにしました。それに関しては次の記事で。

シーケンサ:時間軸補助装置

ミュージックシーケンサー (Music Sequencer) は、演奏データを再生することで自動演奏を行うことを目的とした装置、およびソフトウェアをいう。(Wikipedia)

kaossilatorみたいなのを想像してもらえるといいです。僕がいいたいのはループシーケンサのことで、ある一定の区間を自動的に繰り返すことで、動的な音楽の編集を可能にする装置です。

ループシーケンサは簡単に音楽がつくれます。iPhoneアプリだとFigureなんかが簡単でおもしろいです。

シーケンサは「ろくろ」だな、とふと思ったのがこのエントリのきっかけです。

ろくろはあのぐるぐるまわるやつですが、あれって要は鑑賞者が器のすべての面を鑑賞する体験をループさせているわけです。

ろくろによって、縦方向のプロポーションを見ながら直感的に形状を修正することができる反面、回転体(に近い形状)しか操作できないという弊害が生まれます。そこがループシーケンサと異なるところです。

なぜろくろの場合はこうした制約が生まれるのかというと、音楽の場合は鑑賞に要する時間を基本的にはそのままループさせているのに対して、ろくろは回りこんで鑑賞するという行為にかかる時間を圧縮しているからです。ろくろを少しずつ回転させてそのつど形状を修正する場合は、ろくろを用いないのと同様の形状が制作可能ですが、高速で回転させると、高速で形状を修正するということを人間はできないので、細かい修正が不可能になります。でもそのかわり、縦方向のプロポーションを直感的に操作できます。

 

ここまでを要すると、

  • ループシーケンサ/ろくろは鑑賞に要する時間軸を自動再生することで直感的な操作を可能にする。
  • 時間軸を加速すると人間の鑑賞体験は加速できないので、通常の時間軸による制作より失われるものがある。

です。僕はまがりなりにも建築学を専攻しているので、誰もが簡単に直感的に操作できる建築におけるシーケンサとかを夢想するのですが、建築における時間軸を含む体験とは

  • 形状の体験
  • 日較差の体験:温度、湿度、風、輻射、明度分布
  • 年較差の体験:「温度、湿度、風、輻射、明度分布」の一日における分布、季節感
  • 過去較差の体験:ライフステージにおける環境との関係、過去の記憶(日較差、年較差におけるものを含む)

みたいな感じだと思うのですが、もし環境装置とかが発展して温度、湿度、風、輻射、明度分布とかを一瞬で切り替えて体験できる部屋ができたとしても、ここにはある問題が残っています。

それはさっき人間側の体験が差異を前提にしており、皮膚感覚においてはそれを純粋に実感するには長い時間を必要とするということです。

ろくろは視覚による体験を加速しただけだったので、それを操作するときの精度が問題になったのでしたが、皮膚感覚(暑いとか寒いとか)のために時間を加速させても、真に暑い・寒いと感じることはできません。それは、真夏にクーラーがガンガン効いた部屋から外に出るとちょうど暖かいけど、ずっといるとやっと暑くなってくるという体験からもわかると想います。

えーとつまり5感のうちで皮膚感覚情報の直感的操作のためには、その皮膚感覚に長い間さらされている時の体験を一瞬で呼び出さなければならないのです。

そんなことができたら精神と時の部屋ができてしまいそうな気がします。

まー可能な道としては、このぐらいの気温のときは統計的にだいたい暑いと感じているとかの普通の方法しかないのですがそれはホントに普通のアプローチですね。

うむつまり誰かのがんばりを期待します。