株式会社クリアコード > ククログ

ククログ


Rubyist Magazine(るびま)0053号に須藤へのインタビューが掲載

Rubyist Magazine(るびま)にはRubyist HotlinksというRubyistへインタビューする企画があります。0053号のRubyist Hotlinks 【第 36 回】はクリアコードの社長である須藤へのインタビューです。クリアコードのビジネスについてやOSS Gateの話題もあるのでご覧ください。それらの話題にそんなに興味のない方でもぜひご覧ください。聞き手・野次馬のみなさんのおかげで読み物としておもしろいものになっています。

須藤は2016年5月28日開催の東京Ruby会議11で話すのですが、発表者の自己紹介欄をRubyist Hotlinksへのリンクにするだけでよいので大変便利です。

るびま0053号はHotlinks以外にもおもしろい記事が揃っているので読んでみてください。過去の記事にもおもしろい記事はたくさんあります。バックナンバーもぜひお楽しみください。

2016-04-04

OSDNのファイルリリース機能をAPI経由で使うには

はじめに

「オープンソース・ソフトウェア開発/公開のために様々な機能を提供する無料サービス」の1つに、OSDNがあります。 かつてSourceForge.JPとして運営されていたので、そちらのほうに馴染みがあるかたも多いことでしょう。

OSDNへとブランド名称が変更されたのが2015年5月のことですから、新ブランドへ移行して、まもなく1年ということになりますね。 今年に入ってからのOSDNのトピックとしては、ファイルリリースのミラーの増強が行われたようです。そして、2016年2月からはAPIの提供がはじまりました。

今回は提供されているAPIのうち、リリースに関連した部分を以下の流れで紹介します。

  • OSDNのファイルリリース機能について
  • APIとクライアントライブラリについて
  • osdn-cliとは
  • クライアントライブラリの使い方

OSDNのファイルリリース機能について

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エクスプローラにて確認できます。

このAPIの提供に合わせて、それらを簡単に扱えるようなクライアントライブラリosdn-clientもリリースされています。 この記事を書いている4月時点で、Ruby/PHP/Pythonの3種類が提供されています。 OSDN Codeから各種言語向けのアーカイブをダウンロードできます。

クライアントライブラリの使い方については後述します。

osdn-cliとは

前述のクライアントライブラリ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つの観点から紹介します。

  • アクセストークンの設定(共通)
  • 参照系のAPIの使い方
  • 更新系のAPIの使い方
アクセストークンの設定

アクセストークンの設定は次のようにして行います。アクセストークンの値については、credential.ymlを参照してください。

OSDNClient.configure do |config|
  config.access_token = "(ここにアクセストークン)"
end
参照系のAPIの使い方

次の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
更新系のAPIの使い方

次の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することで、ファイルリリースシステム側へマッピングするという手も試してみたのですが、残念ながらエラーになるため使えませんでした。

2016-04-05

CygwinのOpenSSHサーバーに公開鍵を使ってログオンする方法

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によるファイルコピーや、zshgrepを使ったコマンドラインベースの操作を使えます。これは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-csshdを終了します。

ここまでが通常のOpenSSHのセットアップです。

公開鍵でログオンできるようにする

これまでの通常のOpenSSHのセットアップだけでは、公開鍵を利用したパスワード入力無しでのログオンができません。公開鍵を利用したパスワード入力無しでのログオンを実現するためにはsshdがパスワード無しでユーザーを切り替えられるようにする必要があります。パスワード入力が必要なのは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にログオンできると便利です。他にも便利な機会はあるでしょう。そんなときはこの方法を活用してください。

2016-04-08

Redmineで高速に全文検索する方法

Redmineで全文検索するとかなり時間がかかります。

クリアコード社内でもRedmineを使用しており、全文検索が遅いことは以前から問題視していました。

最近Redmineでの全文検索を高速に実行できるようになるプラグインを開発したので紹介します*1

リンク先を見てもらえばわかるとおり、PostgreSQLとMySQL(MariaDB)に対応しています。 それぞれPGroongaMroongaを使用しています。

このプラグインを使うと、デフォルトの全文検索と比較して以下のメリットがあります。

インストール方法

プラグインをインストールする前に、使用している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

タグ: Groonga | Ruby
2016-04-11

最小構成のFluent Loggerを作成するには

はじめに

クリアコードではFluentdというソフトウェアの開発に参加しています。Fluentdはログ収集や収集したデータの分配・集約などを行うソフトウェアです。

また、Fluent Loggerと呼ばれるFluentdへデータを転送出来る実装が各言語で公開されています。

Fluentdのv0.10とv0.12のイベントの転送の仕組みはForward protocolとして仕様化されています。登場したばかりの新しいプログラミング言語でFluent Loggerがまだない場合、この仕様に基づいて自分で実装する必要があります。

Forward Protocol v0

この記事ではFluentd v0.10とv0.12で用いられているForward Protocol v0を元に解説します。

Forwardプロトコル

Fluent Loggerでは次の3つのうちどれかを実装している必要があります:

  • Message Mode
  • Forward Mode
  • PackedForward Mode

このうち、Fluent loggerの実装によく使われているのがMessage modeと呼ばれる形式です。現在のところPackedForward対応を謳っているFluent logger実装は多くありません。*1

この記事ではMessage modeでの最小構成のFluent Loggerの作り方について解説をするため、Message modeに絞って解説します。

Message modeとは

Message modeは一度に一つのイベントのみを送ることができます。また、そのイベントの中身は次の通りです。

  • タグ
  • Unix時間
  • レコード
  • オプション

このうち、オプションは必須ではありません。そのため、タグ・Unix時間・レコードをひとまとめにしてForwardプロトコルを実装しているサーバーに送ることが出来ればよい、となります。

また、送る形式はJSONまたはmsgpackのどちらかを選択する事ができます。

Message modeでイベントを送るには

ここまででMessage modeでイベントを送るための形式が分かりました。実際にMessage modeでイベントをForward protocol v0を実装したサーバーに送る際には接続の種類や、接続の切断まで仕様から読み解く必要があります。 では、その仕様を見てみましょう。その仕様はFluentdのWikiの以下の部分に書かれています:

OptionとResponseの節でMessage modeでoptionを送らない場合はForwardプロトコルを実装しているサーバーは接続を切る動作をします。 なので、Message modeで送る際には以下のような流れでFluent LoggerはForwardプロトコルを実装するサーバーにイベントを送ります。

  1. Forwardプロトコルを実装しているサーバーにTCPで接続する
  2. タグ・Unix時間・レコードを含むイベントをForwardプロトコルを実装しているサーバーに送る
  3. Forwardプロトコルを実装しているサーバーとの接続を切る

という流れになります。また、TCP接続は毎回Forwardプロトコルを喋るサーバーから切られるものとしてロガーを実装してください。

おわりに

Fluent Loggerに最低限必要な機能には何があるかを解説しました。以上はForwardプロトコルに載せてイベントを送る際に最低限必要な事柄です。 この方針で実装されたFluent Loggerはネットワーク上の問題やアプリケーションの異常によるログの消失を抑える工夫がなされていないため、これらを抑える工夫が必要になります。 その工夫については次の機会に解説します。

*1 例えば、 Fluency | GitHub はPacked Forwardを実装しているのを確認しています。

タグ: Fluentd
2016-04-22

WEB+DB PRESS Vol.86特集「1年目から身につけたい! チーム開発 6つの心得」の全文公開が始まりました

約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は以下を再利用の条件として定めています。

  • BY:作者名を明記すること。例えば、作者名を勝手に書き換えて自分1人の著作であると言ったり、著者不明の公共物と言ったりして再配布することはできません。
  • NC:実費も含め、対価を得ないこと。例えば、紙に印刷した物を配布するときにコピー代を受け取ったり、有料の電子書籍として販売したりすることはできません。必ず無料で配布する必要があります。
  • SA:同一の条件で配布すること。例えば、内容を改良した物を配布する時に「この改良版に対する変更は禁止します」のように新しい条件を付け加える事はできません。内容を変更した版も、元の版と同じ条件で再配布する必要があります。

言い換えると、これらの条件に則った使い方であれば、完全に無許諾での再利用が可能です。 例えば以下のような利用方法が考えられます。

  • 社内での研修資料として無料で配布する。
  • 有料のセミナーで資料として使う。(対価を得てはならないのは資料自体の配布についてなので、セミナー自体の参加費用を求める事は問題ありません。一方で、セミナー内で資料を印刷した物が必要な人には追加で100円を支払ってもらう、というような形だと、資料の配布自体に対価が発生している事になるため不許可となります。)
  • ツールの移り変わりなど、最新の状況に合わせて内容を更新した物を公開する。
  • 「これ以外にももっと大事な事がある!」と思う内容を新しい章として追加して公開する。
  • 「ここ、凄く良い事言ってる!」と思う部分を抽出して、発展させた新しい記事を書き、公開する。(※その場合、「SA」の条件があるため、発展版の記事も同一の条件で再配布する必要があります。)

また、著作権法上の「私的利用」や「引用」の要件を満たす使い方であれば、いわゆるフェアユースにあたるため、上記の諸条件は適用されません。例えば以下のようなケースが該当します。

  • 手元に置いておくために、印刷して保存しておく。あるいは、ページをダウンロードして自宅のファイル共有サーバに保存しておく。
  • 自分で書いた記事の中での意見の補強材料として、あるいは反対意見の紹介として、この記事の一部を引用する。また、その記事を有料の電子書籍として販売する。

なお、これらはあくまでこちらへご連絡をいただかずに再利用される場合の条件です。 例えば有料の電子書籍としての販売などをお考えの場合は個別の対応が可能ですので、お問い合わせフォーム等にてご連絡下さい。

まとめ

WEB+DB PRESSの特集記事「1年目から身につけたい! チーム開発 6つの心得」が公開されました。 再利用しやすいライセンスを設定していますので、広くお使いいただいて、良い開発・良いコミュニケーションの促進に役立てていただければ幸いです。

2016-04-28

«前月 最新記事 翌月»
タグ:
年・日ごとに見る
2008|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|