シーマークの未来を一緒に作る仲間の募集プロジェクト始動!

三浦です。
突然ですが、採用プロジェクトを始動します。
ウチのような小さな会社が、この人材不足の時期に、優秀なエンジニアを採用することは、非常に難易度の高いことだと思います。
それでも一緒にシーマークの未来を作ってくれる仲間を探したいと思っています。
求人サイトの利用、人材紹介会社の利用、人づてでの紹介、自社HPでの募集など、色々と方法はありますが、現時点では、どうしていくかは未定です。こちらのブログでも具体的に情報を掲載していきたいと思います。

それはさておき、今回の採用プロジェクトにおいて一番大事なことは、「会社の未来を一緒に作る」ということに共感した人に、シーマークへ参加してもらうことだと思っています。
なぜなら、今回のプロジェクトは、エンジニアという労働力を得ることだけが目的ではなく、会社の経営、事業運営に一緒に携わっていく仲間を得ることだからです。
シーマークは、現在、全メンバーが、現場での実践的開発エンジニアであるとともに、経営、事業に関わる全ての判断に関わっていく組織運営へと移行していくことを目指しています。
どうか、そうした思いを共有できる人との出会いが得られますように。

ところで、お恥ずかしいことですが、このブログの読者は、ほんのごくわずかだろうと思っています。
ここで求人情報を掲載したり、応募の呼びかけをしても、まず反応は得られないことでしょう。
しかし、これからこのブログ上で私たちの採用プロジェクトの取組の進捗や試行錯誤(往々にして滞りや課題への直面という事態もあると思いますが)を綴っていくことにしました。
なぜなら、いつかウチに興味を持った人が、このブログを遡って読み、私たちが採用プロジェクトに込めた思いを感じ取ってくれることがあるかもしれないと思うからです。

さて、どうなりますことか。
恐る恐る、そしてわくわくした思いとともに、プロジェクトを始動します。

オフィス移転

大層ご無沙汰しておりました。
お陰さまで忙しく過ごさせていただいておりまして。。。
とまずは言い訳を(^_^;)

実は今年1月に長くおりました秋葉原の昭和通り近くのオフィスから引越をいたしました。
ご報告が遅れまして恐縮です。

引越し先のオフィスの目の前の景色はこちらです。↓

C360_2015-11-26-15-58-27-058

こちら超有名お蕎麦屋さん。
交通量の多い大通りを挟んで丁度向かい側になります。
ちょっと見にくい写真ですが、お分かりでしょうか?

神田まつやさんです。

1月中のお昼時は、毎日のように行列ができていました。
さすがに大人気ですね。
ちなみにこのお店のちょっと先には、やぶそばも。

新しいオフィスも居心地よく快適です。
靖国通り沿い神田須田町のcafe veloceのあるビルの2Fになります。
ビルの入口はveloceのある靖国通り沿いではなく、一つ曲がった道沿いになりますのでご注意ください。

お取引先の皆様、パートナーの皆様、お近くにお越しの際はお気軽にお立ち寄りください。
お蕎麦ご馳走します。
(すみませぬ。もりそば限定でお願いします)

NearRealTimeSearchの紹介

あけましておめでとうございます。大谷です。本年もよろしくおねがいいたします。
新年最初のエントリーはNearRealTimeSearchの紹介です。(
PDF版はこちら

1. NearRealTimeSearchとは
Solrを利用した検索サイトを作成するとき、多くの場合は登録するデータはバッチによる定期的な更新を行うようにするのが一般的です。これは、Solrのインデックスへの書き込みがトランザクションに対応していないことやインデックス更新を行なっている間の検索性能の劣化などが要因となっています。
ただ、最近では定時更新ではなく、よりリアルタイムに検索インデックスにデータの追加更新を反映したいという要件が多くなってきています。この要件に対応するために提案、実装されたものがNearRealTimeSearch(ほぼリアルタイム検索)と呼ばれる機能です(以降ではNRTと略します。)。
Luceneには2.9ですでにNRTが実装されていましたが、Solrにて利用できる形にするためにSOLR-2193で提案されました。

2. NRTの仕組み
NRTはLuceneのNRTを利用した仕組みになります。LuceneのNRTはインデックスの書き込みを行うIndexWriterから、Index検索のためのオブジェクトIndexReaderを取得することができるようになる機能になります。すなわち、インデックスがファイルに書き込まれる前の(メモリ上にあるインデックス)状態で検索が可能になることになります。
Solrでは、この機能を利用するためにこれまでコミット(commit)と呼ばれていた機能を以下の2つコミットとして再定義しました。

  • Hard Commit
    これまでのコミットと同義。停電からのデータロスをなくすためにfsyncを呼び出し、ファイルにインデックスを出力する。
  • Soft Commit
    新たに追加されたコミットの種類。インデックスの変更をファイルに反映せず、メモリ上に反映する。
    Soft CommitがNRTを利用するためのコミットとなります。ディスクへの書き込みは保証されませんが、ほぼリアルタイムに検索結果に反映がされます。

3. 制約事項
現在、NRTが利用できるのはtrunkである4.x系のみとなります。3.x系以前では残念ながら利用できません。
前述ですが、ディスクへ書き込みも保証されません。VMがクラッシュしたり停電が発生した場合は直前のHard Commitが実行された時点までインデックスの状態が戻ることに注意が必要です。
また、Soft Commitの仕組み上、レプリケーションによる同期が利用できません。こちらもHard Commit時点ごとにしかレプリケーションが動作しません。Soft Commitによるほぼリアルタイム反映についてはデータ更新対象となっているSolrサーバでのみ恩恵をうけることが可能です。

4. 利用方法
2で説明しましたが、Commitの新しいタイプとしてSoft Commitが追加されています。まずは、XMLによるコミット時の指定は次の様になります。

softCommit=”true”オプションを指定するとSoft Commitの動作となります。
管理画面のPendingDocsを見ると、Soft Commit前に更新したデータ件数がコミットされていない状態がわかります。ただし、Soft Commitは実施されていますので、検索結果には表示されます。
次は設定によるAutoCommitについてです。Solrではsolrconfig.xmlの設定によりAutoCommitが設定可能です。設定は次の通りです。

これまで同様、maxDocsによる指定とmaxTimeによる指定が可能です。

  • maxDocs
    直前のSoft Commitが実施されてから登録されたデータ数が指定された数に達した場合にSoft Commitが実行される。
  • maxTime
    データが登録されてから指定されたミリ秒経過するとSoft Commitが実行される。
    Hard Commitの設定についてはこれまでと同様のタグにて指定可能です。Soft Commitを毎秒、Hard Commitを数分おきとすることで、定期的にファイルにインデックスを保存しつつ、ほぼリアルタイムに更新を反映させるといった設定が可能になります。

5. 今後の展開
前述しましたがNRTは、マスタスレーブ構成(レプリケーション)には対応していません。マスタスレーブ構成についてはSolrのMLで話が上がりましたが、現在のレプリケーションの機能との併用は望めないようです。代わりにSolrCloudと呼ばれる別の新しい分散インデックスの機能が紹介されています。SolrCloudとはクラウドでの検索サービスとしてSolrを運用管理するために現状のSolrの拡張する機能です。
NRTについてはまずは、マスタスレーブでない環境で利用してみるのはいかがでしょうか。

参考:
http://wiki.apache.org/solr/NearRealtimeSearch
http://wiki.apache.org/solr/UpdateXmlMessages#Optional_attributes_for_.22commit.22_and_.22optimize.22
http://wiki.apache.org/solr/SolrConfigXml?#Update_Handler_Section
http://www.lucidimagination.com/blog/2011/07/11/benchmarking-the-new-solr-%E2%80%98near-realtime%E2%80%99-improvements/
http://lucene.472066.n3.nabble.com/NRT-and-replication-tt3422940.html
http://wiki.apache.org/solr/NewSolrCloudDesign

Solr勉強会第7回でlucene-gosenについて発表しました。

お久しぶりです、大谷です。

12/19(月)に開催されたSolr勉強会でlucene-gosenについて発表してきました。

lucene-gosenとは?
私がコミッターとして参加している形態素解析ライブラリになります。
Solr入門でサンプルとして利用していたSenがメンテナンスされなくなり、その後継のGoSenも出てきたのですが、こちらもメンテナンスがされなくなりと、
フリーで利用できる形態素解析器がなくなってきたところ、Lucene/Solrのコミッターの方々がGoSenを引き取り、公開した形態素解析器がlucene-gosenになります。
Solrのコミッターである関口さんの紹介で、今年の4月から私も微力ながら参加しています。
Solrでも簡単に利用できる形態素解析器となっていますので、どんどん利用してください。

発表資料
発表資料はこちらになります。簡単ですが、Solrのインデックスの作りから、lucene-gosenの機能の紹介まで入っていますので、参考にどうぞ。

あと、その他のセッションについてはこちらにログをのこしてありますので、参考までに。

既存サイトのスマートフォン対応とjQuery Mobile

iPhoneやAndroid等の携帯電話やタブレット端末向けのweb画面を作成するツールとして注目を集めているjQuery Mobileがついに11月に1.0版をリリースして正式版となりました。
正式版では、画面表示のスピードが大幅に改善されたとのこと。またカスタマイズしたデザインを簡単に作成するためのツールも公開されました。
「既存サイトのスマホ対応」というのが、今年は様々なところで聞かれた話題でしたが、jQuery Mobileはその課題を簡単にクリアできるツールとして初期のβ版のころから注目を集めていました。(弊社の既存サイトのスマホ対応のためにも、いろいろと研究というか、活用させていただいておりました)
AdobeのDreamweaverCS5.5が、html5およびcss3対応、さらにはβ版のjQuery Mobile対応ということでCS5からマイナー(?)ヴァージョンアップで発表されたのも今年の春でした。
jQuery Mobileの正式版のリリースで、既存サイトのスマホ対応がさらに促進されそうです。

既存サイトのスマホ対応を考える場合に、PC向けの画面をベースにするか、フィーチャーフォン向けの画面をベースにするかは、様々意見があるようですが、シンプルな作りで、開発のスピードを優先するならば、フィーチャーフォン向け画面をベースにした方が、やはり良さそうです。
またスマホ版を利用するユーザーの多くが、それまでフィーチャーホンで利用してきた既存ユーザーであるのであれば、UIを大きく変更せず、スムーズに移行して利用してもらうことにもメリットがありそうです。
そして、実際にスマホ版サイトを作成し、テストをして公開して実感することとして、概ねjQuery Mobileの機能に感謝しつつ、やはりAJAXの機能などに不安があることや、閲覧する環境(スマホで利用するブラウザの種別や設定)によって完全に同じ動作をしてくれるのかが不安な点があることも、実運用上は無視できません。
十分な開発期間と、多種多様な環境を用意して十分にテストができるなら、使える限りの機能を使いまわし、フィーチャーホンではとても実現できない高機能なUIを実現するというトライも考えられますが、まずは既存サイトのスマホ対応ということであれば。。。やはりこういう判断になるのかなーと。

以上、ひとりごとでした。