こんにちは、PGroongaの開発やサポートをしている堀本です。

この記事では、PGroongaのインデックスを設定しているにも関わらず、 シーケンシャルサーチで検索が実行されてしまう時に確認すべきポイントを紹介します。

PGroongaはPostgreSQLで高速に全文検索するための拡張ですが、 PGroongaのインデックスを設定しているのに、検索が速くならないことがあります。

色々な原因が考えられるのですが、よくあるケースとしては PostgreSQLがPGroongaのインデックスを使用せず、シーケンシャルサーチで検索が実行されていているケースです。

以下では、なぜシーケンシャルサーチが選択されるのか、PGroongaのインデックスを選択して 検索を実行するにはどうしたらいいかを解説します。

最初に、シーケンシャルサーチで検索が実行されているかどうかを確認します。 その後に、シーケンシャルサーチで検索が実行される原因とその解決方法を4つ記載します。

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思ってなにか試したりしましたが、あいかわらず、今でも実質1人でApache ArrowのRuby対応をしています。何度目かの「もっと仲間を増やさないと！」という気持ちになったので、最近の活動を紹介して仲間を増やそうと試みます。

1年とか半年とか前の話になりますがAzure Blob Storage関連のこともがんばっていたことを思い出したので紹介します。

USearchに入門中の阿部です。

入門することにした経緯などはUSearchに入門する準備をご覧ください。

ということで、前回に入門する準備をしたので今回は入門したいと思います。

記事に登場するコード例はmain-devブランチの113a7862f80bf2eb347c559da8487c4be05a5cc4時点のコードを利用しています。

システム管理者にとって、セキュリティインシデント発生時など、原因究明・問題解決のために必要な情報をすばやく収集・分析する必要があります。

Windowsにおいては、イベントログが監視や監査という観点からは重要なログといえるでしょう。 Windowsイベントログにもいくつか種類があり、セキュリティ監査の観点からはアカウントの ログオン等の情報が得られるので、Windowsのセキュリティイベントログが保存されていると有用です。¹

そこで、まだそこまでしくみを整備できていない人のために、今回はいざというときに備えてWindowsのセキュリティイベントログを収集・保存しておく方法を紹介します。

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思ったりなにか試したりしましたが、あいかわらず、今でも実質1人でApache ArrowのRuby対応をしています。何度目かの「もっと仲間を増やさないと！」という気持ちになったので、最近の活動を紹介して仲間を増やそうと試みます。

統計情報関連のこともがんばっていたことを思い出したので紹介します。

Apache Arrowの開発に参加している須藤です。現時点でapache/arrowのコミット数は1位です。私はRubyでデータ処理できるようになるといいなぁと思ってApache Arrowの開発に参加し始めました。同じような人が増えるといいなぁと思ったりなにか試したりしましたが、あいかわらず、今でも実質1人でApache ArrowのRuby対応をしています。何度目かの「もっと仲間を増やさないと！」という気持ちになったので、最近の活動を紹介して仲間を増やそうと試みます。

そのために選んだ話題がJRubyなのはちょっとアレな気もしますが、最近「がんばったな！」という気持ちになったのがこれだからしょうがない。

開発したソフトウェアを簡単に導入してもらえるようにするための工夫として、debやrpmといったパッケージを用意し、パッケージを含むリポジトリから インストールできるようにするということがよく行われています。

debやrpmといったパッケージを提供する側にとっては、提供したパッケージを問題なく更新できるように、（パッケージの一部だけ変更したものを用意するなどして）パッケージ更新時の挙動を検証したくなることがあります。

今回はそんなときのために、debおよびrpmの内容を一部書き換えてパッケージを再作成する方法について紹介します。

当社のOSS開発サポート事業では、企業におけるオープンソースに関連したお困りごとの解決のために、開発への協力、研修の実施など、様々なお手伝いをしています。

去る4月18日、頂いたご相談に基づき、Webサービスを自社開発・運営しておられる企業のTechouseさまにおいて、新人研修の一環としてOSS Gateワークショップを実施しました。 参加された方による体験記の記事がすでにTechouseさまの開発者向けブログで公開されていますので、ワークショップがどのような様子だったかはぜひそちらをご覧下さい。

本記事では開催側の視点から、何を期待し、どのように効果を測定したか、どのような準備を行ったかをご紹介します。 OSS開発に関わってみたいけれどもうまく進められておらず困っている、当社のOSS開発サポートで具体的にどのようなサポートを受けられるのかを知りたい、とお考えの企業さまに参考にして頂けましたら幸いです。

（本記事に掲載の写真画像はTechouseさまからご提供を頂いた物で、CC BY-SA 4.0およびGFDLの適用外となります。記事を再利用される際は、写真画像を省いてお使いください。）

IISでリバースプロキシの設定をしている阿部です。

先日、IISでリバースプロキシの設定をする方法を説明しました。

今回は少し進んだ設定方法としてヘッダ情報を転送する設定（nginxのproxy_set_header相当の設定）について説明します。 IISでリバースプロキシ設定で、バックエンドにヘッダ情報を転送したい方の参考になると思います。

プロジェクトに関わる情報の散逸を防ぐためには、情報を可能な限り一箇所に集約しておきたくなるところです。 複数人が関わるソフトウェア開発プロジェクトでは、ソースコードのGitリポジトリー、イシュートラッカーのチケットやWiki、ファイル共有サーバーなど、情報の置き場所が複数あると、人によって情報の置き場所がばらけてしまうリスクがあります。 「ファイルはすべてGitリポジトリーに集約する」と運用が定まっていれば、プロジェクトにファイルを追加するときも探すときも迷わずに済みます。

ただ、セキュリティを重視すると、「電子署名のための秘密鍵や、サービスの管理画面にアクセスするためのパスワード、関係者のプライバシーに関わる情報などのような機密情報だけは、バージョン管理システムのリポジトリーには集約できない」というジレンマが生じます。 多くのオープンソース開発プロジェクトのように、リポジトリーを公開する運用を取っている場合に、生の機密情報を格納しては駄目なのは分かりやすいでしょう。 しかし、非公開のリポジトリーであっても、「ゾーン分けによるセキュリティ¹を過信してはいけない」と「分散バージョン管理システムのリポジトリーはその特性上、一度入れてしまった情報を完全に消去するのが難しい」という2つの理由から、生の機密情報は格納するべきではありません。 では、こればかりは諦めるしかないのでしょうか？

本記事ではこのジレンマの解決方法として、公開・非公開を問わず、バージョン管理システムのリポジトリーに機密情報を集約しつつ安全な状態を保つ方法を紹介します。