Rubyist Magazine(るびま)にはRubyist HotlinksというRubyistへインタビューする企画があります。0053号のRubyist Hotlinks 【第 36 回】はクリアコードの社長である須藤へのインタビューです。クリアコードのビジネスについてやOSS Gateの話題もあるのでご覧ください。それらの話題にそんなに興味のない方でもぜひご覧ください。聞き手・野次馬のみなさんのおかげで読み物としておもしろいものになっています。
須藤は2016年5月28日開催の東京Ruby会議11で話すのですが、発表者の自己紹介欄をRubyist Hotlinksへのリンクにするだけでよいので大変便利です。
るびま0053号はHotlinks以外にもおもしろい記事が揃っているので読んでみてください。過去の記事にもおもしろい記事はたくさんあります。バックナンバーもぜひお楽しみください。
「オープンソース・ソフトウェア開発/公開のために様々な機能を提供する無料サービス」の1つに、OSDNがあります。 かつてSourceForge.JPとして運営されていたので、そちらのほうに馴染みがあるかたも多いことでしょう。
OSDNへとブランド名称が変更されたのが2015年5月のことですから、新ブランドへ移行して、まもなく1年ということになりますね。 今年に入ってからのOSDNのトピックとしては、ファイルリリースのミラーの増強が行われたようです。そして、2016年2月からはAPIの提供がはじまりました。
今回は提供されているAPIのうち、リリースに関連した部分を以下の流れで紹介します。
OSDNでのリリースは、ファイルリリースガイドにあるように基本的に3つの要素から構成されています。
ただし、リリースの下に追加できるのは、ファイルのみという制約があります。ディレクトリを追加するようなことはできません。
類似のサービスであるSourceForge.netと大きく違うのがこの点です。SourceForge.netでは、ファイルリリースのために、frs.sourceforge.netというサイトが用意されています。 frs.sourceforge.netでは、所定のディレクトリへとアップロードしたディレクトリツリーはそのまま公開されるようになっています。 OSDNのような制約がないので、rsyncでアップロードできます。
上記制約で問題にならないケースがほとんどだと思われますが、例外もあります。 それはプロジェクトがパッケージのリポジトリを提供しようとしている場合です。 aptやyumを使って簡単にインストールできるようにdebパッケージやrpmパッケージのリポジトリを提供しようとすると、リポジトリのディレクトリツリーがOSDNのこの制約にひっかかります。
プロジェクトWeb*1配下に置くという裏技がありますが、これはネットワークの帯域的な問題およびファイルシステムリソース的な問題を起こしかねないので、やってはいけないことになっています。 OSDN側で問題は認識しているものの、下記のチケットをみる限り残念ながらこの制約に関して進展はなさそうです。*2
どんなAPIが提供されているかは、APIエクスプローラにて確認できます。
このAPIの提供に合わせて、それらを簡単に扱えるようなクライアントライブラリosdn-client
もリリースされています。
この記事を書いている4月時点で、Ruby/PHP/Pythonの3種類が提供されています。
OSDN Codeから各種言語向けのアーカイブをダウンロードできます。
クライアントライブラリの使い方については後述します。
前述のクライアントライブラリosdn-client
を利用したコマンドラインツールです。
APIの使用例として参考になることでしょう。Rubyで実装されています。
以下のようにして、gemとしてインストールすることができます。
% gem install osdn-cli
インストールが完了すると、osdn
コマンドが使えるようになります。
osdn login
を実行すると、ブラウザでアプリケーション連携確認画面が表示されます。
許可すると、認証コードが表示されるので、ターミナルにて、認証コードを入力します。
% osdn login
Access following URL to get auth code;
Type your auth code: (ここで認証コードを入力)
クレデンシャル情報については、~/.config/osdn/credential.yml
として保存されるようになっています。
% cat ~/.config/osdn/credential.yml
---
access_token: (ここにアクセストークン)
expires_in: 86400
token_type: Bearer
scope:
- profile
- group
- group_write
refresh_token: (ここにリフレッシュトークン)
expires_at: 2016-04-02 15:56:29.336425089 +09:00
このあと説明するクライアントライブラリでは、上記のアクセストークンを使います。
クライアントライブラリの使い方を次の3つの観点から紹介します。
アクセストークンの設定は次のようにして行います。アクセストークンの値については、credential.yml
を参照してください。
OSDNClient.configure do |config|
config.access_token = "(ここにアクセストークン)"
end
次の4点について説明します。
プロジェクト情報の取得には、get_project
を使います。
api = OSDNClient::ProjectApi.new
proj_info = api.get_project("プロジェクト名")
p proj_info
パッケージ情報の取得には、list_packages
を使います。
api = OSDNClient::ProjectApi.new
packages = api.list_packages("プロジェクト名")
packages.each do |package|
p package
end
後述するファイル情報取得では、パッケージ固有のIDをpackage.id
として引数に渡します。
リリース情報の取得には、各パッケージのreleases
を参照します。
api = OSDNClient::ProjectApi.new
packages = api.list_packages("プロジェクト名")
packages.each do |package|
package.releases.each do |release|
p release
end
end
後述するファイル情報取得では、リリース固有のIDをrelease.id
として引数に渡します。
ファイル情報の取得には、get_release
を使い、リリース情報のfiles
を参照します。
api = OSDNClient::ProjectApi.new
packages = api.list_packages("プロジェクト名")
packages.each do |package|
package.releases.each do |release|
release_info = api.get_release("プロジェクト名", package.id, release.id)
p release_info.files
end
end
end
次の4点について説明します。
パッケージの作成には、create_package
を使います。
package = api.create_package("プロジェクト名", "パッケージ名")
リリースの作成には、create_release
を使います。
package = api.create_package("プロジェクト名", "パッケージ名")
release = api.create_release("プロジェクト名", package.id, "リリース名")
リリースはパッケージにひもづいているので、パッケージ固有のIDをpackage.id
として引数に渡します。
ファイルの作成には、create_release_file
を使います。
package = api.create_package("プロジェクト名", "パッケージ名")
release = api.create_release("プロジェクト名", package.id, "リリース名")
open("ファイル") do |file|
file_info = api.create_release_file("プロジェクト名", package.id, release.id, file)
end
ファイルはパッケージとリリースにひもづいているので、パッケージ固有のIDをpackage.id
、リリース固有の値をrelease.id
として引数に渡します。
ニュースの作成は、create_news_0
を使います。create_news
ではないことに注意してください。
api.create_news_0("プロジェクト名", title, body)
ニュースは、パッケージやリリースとは独立しているのでタイトルをtitle
、本文をbody
として引数に渡します。
今回は、OSDNのファイルリリース機能をAPI経由で使う方法をパッケージ/リリース/ファイルの参照と作成に焦点をあてて紹介しました。 もし、リリース時のファイルのアップロードを自動化したいというときには、APIの利用を検討してみるといいかもしれません。
*1 プロジェクトWebとはhttps://(プロジェクト名).osdn.jp/としてアクセスされるもののこと
*2 .htaccessでrewriteすることで、ファイルリリースシステム側へマッピングするという手も試してみたのですが、残念ながらエラーになるため使えませんでした。
mingw-w64を使うことにより、GNU/Linux上でWindows用のバイナリーをビルドすることができます。GNUビルドシステムを使っている場合でもできますし、CMakeを使っている場合でもできます。(CMakeを使っている場合はRuby-GNOME2が指定しているようなオプションを指定するとビルドできます。)
GNU/LinuxでWindows用のバイナリーをビルドしていると、Windows上での動作確認もできるだけGNU/Linuxを使って実施したくなります。
その方法の1つにrdesktopを使ってGNU/Linux上からWindowsのデスクトップにアクセスする方法があります。rdesktopを使う方法は直接Windowsを使ったときと同じことをできることがメリットです。ただ、GNU/Linux上での操作感は失われます。
別の方法としてCygwinでOpenSSHサーバーを動かしてGNU/Linuxからログオンする方法があります。この場合、Cygwin上で実行するため、直接Windowsを使ったときと異なるケースがでてきます。たとえばパス区切り文字で違いがでます。一方、scp
によるファイルコピーや、zsh
やgrep
を使ったコマンドラインベースの操作を使えます。これはGNU/Linux上からの操作をしやすくなるので非常に便利です。たとえば、make && scp xxx.exe windows-host:
と実行すればビルドに成功したらそのままバイナリーをWindowsホストにコピーします。
通常のOpenSSHのセットアップでGNU/Linuxからログオンできるようになります。しかし、公開鍵を使ったパスワード入力無しのログオンはできません。パスワード入力が必須です。これでは前述の「ビルドに成功したらそのままバイナリーをWindowsホストにコピー」のために毎回パスワードを入力しなくてはいけなくて不便です。
ということで、公開鍵を使ったパスワード入力無しでログオンできるようにするOpenSSHのセットアップ方法を説明します。
まずはsetup.exe
を使ってopenssh
パッケージをインストールします。
その後、「管理者権限で」Cygwinのターミナルを起動してssh-host-config
を実行します。
途中、次の質問があるので、それぞれ「(yes/no)」の右側に書いている値(「yes」だったり「no」だったり)を入力します。「CYGWIN for the daemon」のところは空でよいです。「Create new privileged user account ...」も「no」で大丈夫です。OpenSSHサーバー用に新しく特権ユーザーを作成しない場合はSYSTEMユーザーがOpenSSHサーバーを実行します。
*** Query: Should StrictModes be used? (yes/no) yes
*** Query: Should privilege separation be used? (yes/no) no
*** Query: Do you want to install sshd as a service?
*** Query: (Say "no" if it is already installed as a service) (yes/no) yes
*** Query: Enter the value of CYGWIN for the daemon: []
*** Query: Do you want to use a different name? (yes/no) no
*** Query: Create new privileged user account 'HOST_NAME\cyg_server' (Cygwin name: 'cyg_server')? (yes/no) no
*** Query: Do you want to proceed anyway? (yes/no) yes
これでOpenSSHサーバーsshd
をサービスとして起動する準備ができました。
ただ、このまま起動してもファイアウォールで止められて外からアクセスできません。外からアクセスできるようにファイアウォールの設定をします。
同じターミナル(管理者権限のターミナル)でsshd
を起動します。
% sshd -Dd
そうするとWindowsがポートが開いたことを検知してファイアウォールの設定に関するダイアログを表示します。ここで適切なネットワークに対してsshd
のポートを開放します。
ファイアウォールの設定が終わったらCtrl-c
でsshd
を終了します。
ここまでが通常のOpenSSHのセットアップです。
これまでの通常のOpenSSHのセットアップだけでは、公開鍵を利用したパスワード入力無しでのログオンができません。公開鍵を利用したパスワード入力無しでのログオンを実現するためにはssh
dがパスワード無しでユーザーを切り替えられるようにする必要があります。パスワード入力が必要なのはsshd
がユーザーを切り替えるためということです。
パスワードなしでユーザーを切り替えるためにLSA(Local Security Authority)認証という仕組みを使えます。いくつか欠点はありますが、SSHで接続してCygwin上で作業する分には困らないでしょう。
このあたりの詳細はCygwinが提供するSwitching the user contextというドキュメントを参照してください。前述の欠点についても説明があります。
LSA認証を有効にするには管理者権限のターミナルでcyglsa-config
を実行します。途中で「yes/no」を聞かれるので「yes」と答えてください。
% cyglsa-config
...
Are you sure you want to continue? (yes/no) yes
...
Windowsを再起動するとLSA認証が有効になります。
これで公開鍵を利用したパスワード入力無しでのログオンができるようになりました。公開鍵のコピーにはssh-copy-id
が便利です。もし、WindowsホストのIPアドレスが192.168.0.16
の場合は次のようにすれば適切なパーミッションでWindowsホストへ公開鍵をコピーします。なお、このときはパスワードを使ってログオンします。
% ssh-copy-id 192.168.0.16
ssh-agent
を使えば次のコマンドでパスワード入力無しでログオンできます。
% ssh 192.168.0.16
パスワード入力無しでログオンできるようにCygwinのOpenSSHサーバーをセットアップする方法を説明しました。前述のCygwinのドキュメントなど英語での情報はありますが、日本語でのまとまった情報はなかったのでまとめました。
GNU/Linux上でクロスコンパイルしているときはSSHでWindowsにログオンできると便利です。他にも便利な機会はあるでしょう。そんなときはこの方法を活用してください。
Redmineで全文検索するとかなり時間がかかります。
クリアコード社内でもRedmineを使用しており、全文検索が遅いことは以前から問題視していました。
最近Redmineでの全文検索を高速に実行できるようになるプラグインを開発したので紹介します*1。
リンク先を見てもらえばわかるとおり、PostgreSQLとMySQL(MariaDB)に対応しています。 それぞれPGroongaとMroongaを使用しています。
このプラグインを使うと、デフォルトの全文検索と比較して以下のメリットがあります。
pgroonga -mroonga
のようにマイナスを付けるとpgroongaは含むがmroongaは含まないというものも検索できるプラグインをインストールする前に、使用しているRDBMSに合わせてPGroongaまたはMroongaをインストールしておいてください。
インストール方法は以下の通り簡単です。PostgreSQLでもMySQLでも同じ方法でセットアップできます。
$ cd redmine/plugins
$ git clone https://github.com/okkez/redmine_full_text_search.git full_text_search
$ cd ../
$ ./bin/rake redmine:plugins:migrate RAILS_ENV=production
最後にRedmineを再起動すれば、今までと同じように右上の検索ボックスを使って高速に全文検索できます。
他には以下のようなプラグインがあります。
Redmineで全文検索を高速に実行する方法を紹介しました。
*1 Redmine本家にも登録しました https://www.redmine.org/plugins/full_text_search
クリアコードではFluentdというソフトウェアの開発に参加しています。Fluentdはログ収集や収集したデータの分配・集約などを行うソフトウェアです。
また、Fluent Loggerと呼ばれるFluentdへデータを転送出来る実装が各言語で公開されています。
Fluentdのv0.10とv0.12のイベントの転送の仕組みはForward protocolとして仕様化されています。登場したばかりの新しいプログラミング言語でFluent Loggerがまだない場合、この仕様に基づいて自分で実装する必要があります。
この記事ではFluentd v0.10とv0.12で用いられているForward Protocol v0を元に解説します。
Fluent Loggerでは次の3つのうちどれかを実装している必要があります:
このうち、Fluent loggerの実装によく使われているのがMessage modeと呼ばれる形式です。現在のところPackedForward対応を謳っているFluent logger実装は多くありません。*1
この記事ではMessage modeでの最小構成のFluent Loggerの作り方について解説をするため、Message modeに絞って解説します。
Message modeは一度に一つのイベントのみを送ることができます。また、そのイベントの中身は次の通りです。
このうち、オプションは必須ではありません。そのため、タグ・Unix時間・レコードをひとまとめにしてForwardプロトコルを実装しているサーバーに送ることが出来ればよい、となります。
また、送る形式はJSONまたはmsgpackのどちらかを選択する事ができます。
ここまででMessage modeでイベントを送るための形式が分かりました。実際にMessage modeでイベントをForward protocol v0を実装したサーバーに送る際には接続の種類や、接続の切断まで仕様から読み解く必要があります。 では、その仕様を見てみましょう。その仕様はFluentdのWikiの以下の部分に書かれています:
OptionとResponseの節でMessage modeでoptionを送らない場合はForwardプロトコルを実装しているサーバーは接続を切る動作をします。 なので、Message modeで送る際には以下のような流れでFluent LoggerはForwardプロトコルを実装するサーバーにイベントを送ります。
という流れになります。また、TCP接続は毎回Forwardプロトコルを喋るサーバーから切られるものとしてロガーを実装してください。
Fluent Loggerに最低限必要な機能には何があるかを解説しました。以上はForwardプロトコルに載せてイベントを送る際に最低限必要な事柄です。 この方針で実装されたFluent Loggerはネットワーク上の問題やアプリケーションの異常によるログの消失を抑える工夫がなされていないため、これらを抑える工夫が必要になります。 その工夫については次の機会に解説します。
*1 例えば、 Fluency | GitHub はPacked Forwardを実装しているのを確認しています。
約1年前に執筆した記事の全文が、技術評論社Webサイトの開発者向け記事のコーナーで公開され始めています。
全7章を短期集中連載の形式で順次公開していく予定で、本稿執筆時点では第6章までが公開済みとなっています。(5月2日追記:現在は全章を公開済みです。)
特集は全7章ですが、各章の紹介である第1章を除いた第2章から第7章までが、タイトルの「6つの心得」に対応しています。
前半の第2章から第4章は、 「チームで開発する際の、プログラムそのものの良い設計」 をテーマにしています。
一般に、開発者向けで新人さんなどを対象にした記事というと、GitHubなどのサービスやGitなどの個別のプロダクトの使い方を紹介する物が多いのではないでしょうか。 これらの章では敢えてその方向には振らずに、サービスやツールに依存しない一般的な知見の紹介に努めています。
開発者向けのサービスやツールは流行り廃りが激しいため、ともすれば、トレンドを追う事だけに振り回されてしまうというような事に陥りがちです。 しかし、ここで述べている基本的な設計の仕方や考え方についての理解を深めれば、いたずらにトレンドを追わされるのではなく、目指す設計や開発の仕方をサポートするための物として、トレンドの中から適切な道具を選び取っていけるようになるでしょう。
後半の第5章から第7章は 「開発やメンテナンスにおける、チーム内での良いコミュニケーション」 をテーマにしています。
チーム開発は文字通り「チームでの作業」ですから、チームメンバー同士でどのように連携するかが大切になってきます。 どんなに有能なメンバー達を揃えていてもコミュニケーションが取れていなければ期待したような成果は上げられません。
後半の章では、チームメンバー間でのコミュニケーションを円滑にし、より良い形で作業を進められるようにするための、考え方や施策を紹介しています。 新しいメンバーをチームの一員として迎え入れ、お互いの長所を活かし合って最大限のパフォーマンスを引き出すための最初の一歩として、これらの事が役に立つのではないでしょうか。
この特集記事を公開するにあたって、本文と画像はすべてクリエイティブ・コモンズのライセンスを設定しました。 ライセンス種別はCC-BY-NC-SAです。
クリエイティブ・コモンズは作品の使い方について許可する利用形態をあらかじめ明示するライセンスで、CC-BY-NC-SAは以下を再利用の条件として定めています。
言い換えると、これらの条件に則った使い方であれば、完全に無許諾での再利用が可能です。 例えば以下のような利用方法が考えられます。
また、著作権法上の「私的利用」や「引用」の要件を満たす使い方であれば、いわゆるフェアユースにあたるため、上記の諸条件は適用されません。例えば以下のようなケースが該当します。
なお、これらはあくまでこちらへご連絡をいただかずに再利用される場合の条件です。 例えば有料の電子書籍としての販売などをお考えの場合は個別の対応が可能ですので、お問い合わせフォーム等にてご連絡下さい。
WEB+DB PRESSの特集記事「1年目から身につけたい! チーム開発 6つの心得」が公開されました。 再利用しやすいライセンスを設定していますので、広くお使いいただいて、良い開発・良いコミュニケーションの促進に役立てていただければ幸いです。