雑記帳

ちょっとした文章とかメモ書きとか。

GroongaのRustバインディングを書いた

Rustがそろそろ1.0.0ということで最初のRustのリリースの時とだいぶ異なった言語になったらしい、
とのことで再度触れてみました。

触れる題材としてGroongaのバインディングを書いてみることに。

そうして出来上がったのが、Rust + GroongaでRuroonga(るーるんが)です。

(○[○]roongaの名前空間がそろそろ苦しい…。)

最近Rustにはcargoというパッケージマネージャが開発され、それが使われているとのことなのでCargoを使ったプロジェクトになっています。

バインディングを手で書いていたのですが、rust-bindgenがRustのHEAD(1.1.0-dev)で使えたのでRustをビルドしてrust-bindgenで作成しなおしました。

RuroongaはひとまずHaskellでのバインディングと同じように、
GroongaコマンドがRustから発行できること、までを目指して開発しました。

Ruroongaをつい先程Cargoのレジストリに登録したのでCargo.tomlに

ruroonga = "0.1.0"

と指定して使いはじめることができます。

haroonga-httpdを書いた話

前にGroongaのHaskellバインディングのHaroongaを書いたので、どうせならHTTP越しにGroongaを使ってみたいと思っていたらつい書いてしまったというお話。

Github – haroonga-httpd

内部でHaroongaに依存しており、Groongaをライブラリとして呼んで使っています。

WebアプリケーションのフレームワークにはScotty(HaskellのSinatraクローン)を使っています。ScottyはSinatraのAPIに似せて作られていますが、内部で使っているWAIがConcurrentなため、ScottyもちゃっかりConcurrentになっています。

GroongaのHTTPのインターフェースほどしっかりパラメータをパースすると言うことはしていないです。。。

http://localhost:3000/d/<Groonga command>

のようなURLでアクセスするとGroongaのcommandがharoonga-httpdの動いているマシンで実行され、結果がGroonga互換のjsonで返ってくるようになっています。

起動のさせ方はGithubのREADMEなどを見ていただけると。

HaskellでもちゃんとGroongaがライブラリとして使えていますね!!

MikutterInstallBattle with nokogiri 1.6.5 at develop branch

#mikutterinstallbattle with nokogiri 1.6.5

Homebrewでlibxml2を入れている場合は、OS Xのライブラリと競合しないようにkeg-onlyフラグが付けられている。

これは、Cellarには入れるが、system wideに参照する事ができない状態にしてインストールするという意味。

それを参照するには以下の記述をbashrcなどに加えれば良い。

export PKG_CONFIG_PATH=/usr/local/opt/libffi/lib/pkgconfig:/usr/local/opt/libxml2/lib/pkgconfig:$PKG_CONFIG_PATH

libffiは要らないかも知れない。

おしまい。

MroongaのWindows向けビルド

Groongaアドベントカレンダー22日目の記事です。

はじめに

MroongaはWindows向けにも提供されています。MroongaのWindows向けビルドはすんなりいく時もあれば、MaroaDBにバグ報告をしないといけない時も有ります。

Groongaの開発MLにMroongaのWindows向けビルドの協力者を募るメールにやってみたいです。と返信したのが始まりでした。

自動化を考える

Windowsに於いて、自動化を考える時にまず最初に思いつくのはRubyまたはPythonのようなLLを使う事です。これならば普段使い慣れているLinux上で動かしながらWindows固有の部分だけWindowsで動かして開発する事ができます。

しかし、自動化をするに当たって選択したのはPowerShellでした。

PowerShellはWindows7以降であれば標準で2.0以上がインストールされています。
自動化を考える要件として、なるべくOS標準のものを使い、追加でインストールを要求しないという要件がありました。PowerShellはまさにそれに合致していたのです。

自動化の要件

Mroongaのインストール自動化に必要なものは次の通りです。

  • Mroongaのzipパッケージをダウンロードする。
  • ダウンロードしたMroongaのパッケージをunzipする。
  • ビルドバッチが仮定する位置にソースを配置する
  • Mroongaが提供するビルドバッチを実行する
  • ビルドバッチが固めたzipを再度unzipする
  • unzipしたパッケージ内のMySQLサーバーを起動し、Mroongaストレージエンジンを登録する。
  • Mroongaを登録したパッケージを再度zipに固める。

おおざっぱに言うとここまで自動化すれば良い事になります。(欲を言えばGithubのリリースページまでアップロードする事でしょうか。)

これらの機能はPowerShelとそれから使えるコマンドやライブラリに備わっています。
一部.NET Frameworkの機能を拝借してきます。

  • Invoke-WebRequest # wget風のコマンドレット
  • [System.IO.Compression.ZipFile]::ExtractToDirectory # from .NET 4.5、unzip
  • cmd /c build-$vcVer-zip-32.bat # cmd.exe呼び出し
  • New-Item/Move-Item/Remove-Item
  • cmd /c .\bin\mysql.exe -uroot <$installSqlDir\install.sqlなど # cmd.exe呼び出し
  • [System.IO.Compression.ZipFile]::CreateFromDirectory # from .NET 4.5、zip

作成したPowerShell

これらの要件を満たすPowerShellを作成して、実際にリリースやnightlyパッケージのCIに用いています。

作成したPowerShellはこちらです。実行しているWindowsはWindows 8.1なので想定しているPowerShellのバージョンは4.0です。

次のような設定を書いたスクリプトを実行すると指定したVisual Studio向けにビルドが出来ます。

/powershell以下にビルドに用いるPowerShellが有るので、cloneしたディレクトリで作業する場合は以下のようになります。

# for VC++ 2010

$vcVer = "vc2010"
cd .\powershell
.\build-vc-core.ps1

# for VC++ 2013

$vcVer = "vc2013"
cd .\powershell
.\build-vc-core.ps1

参考

Windows PowerShell Reference

ZipFile メソッド|.NET Framework 4.5

その他

開発者向けの機能として、MinGWのpatchを使用し、patchesフォルダに含まれるパッチを自動で当てる機能がついています。

mikutterを使い始めて3年以上経っていた話

mikutterアドベントカレンダー21日目の記事です。

回想

mikutterは主にLinux向けのTwitterクライアントのため、
mikutterの為にLinux機のメモリを4GBから8GBにしたり、
mikutterを常に表示させておきたいがためにLinuxでデュアルディスプレイにした事を今でも覚えています。

丁度mikutterがRuby 1.8を切ろうとしていた時期なのでおよそ3年前くらいでしょうか。
(2011年11月の頃のようです。)

Linuxではmikutterが快適に動くため、
これまでWindowsばかり使ってきたのですが、メインマシンに入れるOSもUbuntu Linuxとなりました。
この時はまだUbuntu 10.04 LTSが出た時くらいで、ようやくLinuxでの生活が慣れてきた頃です。

あれからずっとUbuntu Linuxを使い続けてきました。Ubuntu Linux 12.04 LTSの頃に64bit版に乗り換え、より多くのメモリをmikutterに捧げる事ができるようになりました。この頃からEmacsを本格的に使い始めていたようです。

現在

思えばかなり時間が経っています。

mikutterを動かす用に新調したマシンは今は実験環境になっています。(今も正常に動かす事ができます)

mikutterの薄い本に寄稿したり、なんやかんやでRuby-GNOME2にコミットしたり、
回り回ってWindowsを使い始めたりしました(これは後ほど別のアドベントカレンダーにて)。

pluginを何個か作りましたが、timelineのfilterプラグインは未だに常用していて、
3.1になった今でも0.2向けのプラグインですが正常に動いています。

謎の後方互換性により最近はほとんど手を入れていませんが、ちゃんと動くようです。

mikutterは気軽にプラグインが書けるので、本体に無い機能でもそれを補えるプラグインが書けます。よいツイッタークライアントですね!

GroongaのArch Linux向けパッケージング

この記事はGroongaアドベントカレンダー20日目の記事です。

全文検索エンジンGroongaはいろんなOSやパッケージマネージャ向けにパッケージングされています。

Arch Linux向けパッケージング

Groongaは元々Arch Linux向けにパッケージングされていて、AURに古いものが登録されていました。
しかし、orphan(メンテナ不在)とマークされていたのでメンテナになってみました。

AUR にアカウントを登録してPKGBUILDを書きました。

書いたGroonga関連のPKGBUILDはこちらです。
また、PKGBUILD自体の管理はGithubでも行っています→https://github.com/cosmo0920/AUR-for-Groonga-family

その他friso(中国語向けトークナイザー)とgroonga-tokenizer-frisoのパッケージも登録しました。

AURに登録してあるGroongaパッケージの制限

他のディストリビューションではinitスクリプトやsystemdのUnitファイルが追加されていることがあります。

これに当たるスクリプトを含めていないので、
現在のAURからGroongaをインストールする方法だとデーモンとしてGroongaを起動することはできません。

AURのパッケージのインストール方法

AURに上がっているパッケージは公式リポジトリではないので、
pacmanのラッパーであるyaourtを使ってインストールすることになります。

yaourtをインストールすると以下のようなコマンドでインストールできるようになります。

% sudo yaourt -Sy groonga

また、Mroongaも登録されているため、

% sudo yaourt -Sy mroonga

とするとMroongaをインストールすることが出来ます。
ただし、MariaDBも含めたソースからのビルドとなるため、かなり時間がかかります。

インストールが終わった段階でMroongaをMariaDBにインストールするためのコマンドが表示されるのでそれに従えばMroongaのインストールが完了となります。
これは上手いやり方が見つからなかったためこのようにしています。。。

参考

AUR―Arch User Repository
PKGBUILD
AUR Metadata/mkaurball

その他

Arch LinuxでPKGBUILDをすぐに検証できるようにVagrantfileも用意しました。
vagrant up するとyaourtとpkgbuild-introspectionが既にインストールされた状態のArch LinuxのVMが起動するようになっています。
Arch Linuxをインストールした実機がなくてもすぐに試せます。

すごいcronとしてのJenkins

毎日ビルドなり、決まった時間にnightlyのバイナリをcurlでアクセスして取ってきたいなんて思った事はありませんか?

ありますよね。

そうなると*nix系の人ならcronを使う事になるのでしょうが、cronには親切なUIというものが付いてないですし、そもそもWindowsじゃ動きません。

そうなるとJenkinsの出番です。

Jenkinsとは一言で言うと親切なUIがくっ付いたスゴいcronです。
これを使わない手は有りませんね。

という事で、いくつか使ってみています。

使用例

一つ目:Mroongaのnightlyのバイナリを1ヶ月間分保存した上で決まった時間にアクセスして取りにいきたい。

そのジョブに使っているスクリプトはこちらです:https://github.com/cosmo0920/curl-daily-job-for-mroonga

その他、Jenkinsの定時に実行する設定が必要です。

二つ目:OSXまたはLinuxで”cabal install yesod yesod-bin”を実行して正常終了するか見たい。

そのジョブに使っているスクリプトはこちらです:https://github.com/cosmo0920/haskell-install-check-CI

こちらはOSXでは直接

cabal sandbox init

した後に、

cabal install yesod yesod-bin

しています。
が、Jenkinsを立てた時期とマシン事情によって、Linux向けの”cabal install yesod yesod-bin”のジョブにはDockerを使っています。

CIが失敗したときのDockerコンテナの残骸はどうやって処理しているんでしょうかね。気づいた時に手動で

docker rm `docker ps -a -q`
docker images | grep "<none>" | awk '{print $3}' | xargs docker rmi

な感じで削除しています。

三つ目:Jenkinsのslaveを立ててmasterとは異なるOSでのCIを行いたい

それに使っているスクリプトはこちらです:https://github.com/cosmo0920/PowerShell-for-Mroonga-building

WindowsのJenkins slaveを立てるにはJenkins slave agentをJNLP経由で接続すると楽です!

また、WindowsでのCIを行う際にはpowershell pluginを使うとpowershellでJenkinsのCIが行えるようになるのでCIが楽しくなります。

色々なJenkinsの使い方を試してみるとCIが楽しくなるかもしれません。

hsenvで複数の切り替え可能なghc環境を整える

RubyでいうrbenvのようなツールはもちろんHaskellにもあります。hsenvですね。

これは$HSENV_ROOT/bin/activateスクリプトにより独立したghc環境を作るものです。

rbenvの時とは少し作法が違うので注意してください。

hsenvの場合は、hsenvを実行したディレクトリに.hsenvが掘られ、そこにghc環境が新たに作成されます。使い方によってはcabal sandboxと被ってしまいますが、今回は異なるghc環境の切り替え用途で使ってみます。hsenvは$PATHで指定されているディレクトリに既に有るものとします。

$ mkdir ~/.haskell
$ cd ~/.haskell
$ hsenv --ghc=<ghc tarball>.tar.gz

とする事により、新たなhsenvによるghc環境が~/.haskell/.hsenv以下に作成されます。

例えば、ghc-7.8.2をhsenvを使った切り替え可能なghc環境としてインストールするとしたら次のようになります。

$ wget https://www.haskell.org/ghc/dist/7.8.2/ghc-7.8.2-<architecture & OS type>.tar.gz

としてghc-7.8.2のtarballをダウンロードしておき、

$ mkdir -p ~/.haskell/hsenv/ghc-7.8.2
$ cd ~/.haskell/hsenv/ghc-7.8.2
$ hsenv --ghc=<path to ghc-7.8.2 tarball>

とすると~/.haskell/hsenv/ghc-7.8.2の下にghc-7.8.2環境が作られます。

$ source ~/.haskell/hsenv/ghc-7.8.2/.hsenv/bin/activate

とすればこの作成した環境に切り替えられます。

これを、例えば~/.bash_aliases~/.zshenvなどに

alias hsenva='source ~/.haskell/hsenv/ghc-7.8.2/.hsenv/bin/activate'

みたいにしておけば環境の切り替えも楽に行えます。hsenvaはhsenv activateの略のつもりです
今回はghcを一つだけhsenvでインストールしたのですが、例えば

$ ~/.haskell/hsenv/ghc-<version>

のようなバージョニングルールを決めておけば、
複数のhsenvでインストールしたghc環境がどれがどれだったか分からなくなる事がなくなると思います。

hsenvにより新しいghc環境を作成した後、cabal sandbox init後に依存ライブラリを入れるようにすればより快適なHaskell開発環境が手に入ると思います。お試しあれ。

Ansibleでketerのデプロイ環境を整える

Ansibleを触って、keterでのデプロイが出来るまでのAnsible playbookを作成してみました。

目標:AnsibleでサーバーへHaskell開発環境を入れずにketerの環境を作成する。

Yesodのデプロイツールのketerサーバーで実行する段階ではネイティブのバイナリの実行ファイル(ELF)です。

Yesodのデプロイ環境をketerで作成するとプロダクションサーバーに一切開発環境やインタプリタやコンパイラを入れること無くアプリケーションを動かせる、ということになっています。

とってもセキュア!

そうして出来上がったのがこちらのplaybook: ansible-playbook-for-keter-deploy

このplaybookを動かすにはhostへの対象サーバーの記述と、binaryディレクトリへketerのELFバイナリを置く必要があります。

ついでにserverspecでserverの状態を確認するテスト書きました。

  • gcc, clang, ghc等の開発ツールを誤ってインストールしていないか
  • keterがサービスとして動いているか
  • avahi(bonjour) daemonが動いてホスト名の名前解決が行えるか

等のserverspecを書いてあります。(が、テストをどうやってCIするか悩んでいるのでCIはまだしてないです)

Yesodのデプロイ作業はいくらscpで<<Yesod App Name>>.keterをプロダクションサーバーに投げつけるだけとは言え、そこまでの環境を用意するのがめんどくさかったのですが、Ansibleのplaybook化してしまえばYesodのアプリケーションをデプロイするまでの作業がかなりラクになりそうですね。

新宿Scala座2014年3月号に参加してきた

新宿Scala座に参加してきました。

普段自分の時間を使って書く時はHaskellやらRuby(のC FFI)やらを書いている訳ですが、何を思ったかScalaに手を出してしまいました。

Scala始めて間もないのでScalaを書く時にはまったこと、というタイトルでスライドを作りました。

Scalaを書いていて結構OOPだなーと思っていると実はScalazがあるよ!みたいなことだったり、かなりBattery includedな感じだったりと、どうしても重厚なものになってしまうのは仕方ないのかなぁとか。

あと、最近はdispatchの新しいものが出たこともあり、dispatch-classicと新しいdispatchの情報が混在していてやめてくれーって感じでした。

Scala、もっと使っていきたいですね。

フォロー

新しい投稿をメールで受信しましょう。

現在1,328人フォロワーがいます。