RSS2.0

マルチブート環境で Fedora 29 をインストールする

fedora29.png
そろそろ頃合いかなということで手元の Linux 開発環境も、先日組んだ自作 PC に移行することにした。
すでに Windows がインストールされているマシンなので、恒例のマルチブート構成(EFI ブート)で Fedora 29 を追加でインストールした。
ビデオカードのドライバー設定などは毎回はまるので、作業の覚書きとして、詰まりそうな箇所のみ将来のために特筆しておく。

Fedora 29 のパーティションをカスタマイズする

Fedora 29 Workstation の Live メディアを USB メモリとして作っておき、それでブート後にインストールしていく。
インストールは画面に従って進めていけばいいが、パーティションのレイアウトだけは自分で決めたかったので以下のようにカスタマイズした(もちろんパーティションのレイアウトは自動で生成することもできる)。

fedora29_partitions.png
インストールするディスクが sdb だったので、パーティションは指定した順に /dev/sdb1 〜 /dev/sdb2 になっている。
デバイス    マウントポイント   サイズ   タイプ
/dev/sdb1   /boot/efi          200MiB   EFI パーティション
/dev/sdb2   swap               2GiB     swap
/dev/sdb3   /                  109.6G   ext4
近年の流れにのって EFI でブートするようにするため、200 MiB の /boot/efi パーティションを忘れずに先頭に置いておく。
メモリは 16 GB 積んでいるので swap パーティションを作る必要があるのか迷ったが、今までずっと作ってきたので今回もなんとなく作っておいた。
残りの容量はすべて何も考えずに / に割り当てた。個人の開発環境なのでこれくらいがちょうどいいかなと。

NVIDIA のビデオカードのドライバーをインストールする

毎回 Linux 環境を作る際に苦労するのがこの NVIDIA のビデオカード用ドライバーのインストールになる。せっかくいいビデオカードを積んでいるので綺麗な GUI でマルチディスプレイ環境を使えるようにしたいのだが、NVIDIA のドライバーは別途インストールしなければならないこともあり、面倒くさい。

続きを読む Linux  コメント (0)  2018/12/09 13:28:15

自作 PC のパーツが届き始めた

冬の大自作 PC 祭りに向けてポチッたパーツが届き始めました。
水曜日にポチって木曜の夜には受け取れているので、早い早い。
pc_parts01.jpg
わりとノリと勢いでポチった感があるのでこうしてパーツが届き始めた今でも、ちゃんと自作できるんだろうかと不安と言うか他人事と言うか、不思議な感覚でいます。
ま、たとえ失敗したとしても今使ってる PC が使えなくなるわけじゃないしね。

本日届いたのはドスパラさんで買ったビデオカード、マザーボード、メモリの 3 品。
ASUS CERBERUS-GTX1070TI-A8G (CERBERUS GeForce GTX1070Ti 8GB)MSI Z370 GAMING PLUS (Z370 1151 ATX)、G.SKILL F4-2400C15D-16GNT (DDR4 PC4-19200 8GB 2枚組) です。

ビデオカードはあいかわらず箱がでかいです。ケルベロスなんていうたいそうな名前がついているのもとてもビデオカードらしいところ。
ふー、実物の PC パーツを見てみると徐々にテンションが上がってきますね。

今回いろいろ参考にさせていただいているちもろぐさんいわく、マザーボードは CPU ソケットにピン折れがないかチェックすべしとのことでしたので、今日はまだ組み始めないものの、マザーボードの箱だけ開けてみることにしました。

pc_parts01_check_mother_board.jpg
こちらが MSI Z370 GAMING PLUS の CPU ソケットの様子です。
そんなに詳しいわけじゃありませんが、見た感じピンに折れているような箇所はありませんでした。
整然と並んでます。美しい。
続きを読む 雑記お買い物  コメント (0)  2018/11/15 22:47:51

2018 年冬の自作 PC チャレンジ

我が家にも Windows マシンがあるのですが、Adobe Photoshop に強いとか OpenGL に強いとかいう理由でビデオカードが Quadro になっています。
ところが最近はすっかりゲーム用途で使うことが多くなってきていて、一般的な PC ゲームを遊ぶ上では Quadro であるがゆえにグラフィック性能が犠牲となっています。
マシン自体はもういつ買ったかも忘れたくらいの代物です。まともな拡張スロットは PCI Express 2.0 x16 が 1 つのみで、ビデオカードを変えようにも対応しているビデオカードはそんなにありません。
そろそろ買い換えた方がいいだろうか、買い換えるならまた BTO か、しかし BTO だとマザーボードが拡張性が……

などと考えることはや数年。
今朝になってとうとう買い変える決意を固めました。

しかも自作 PC(初)です。

一通りのパーツはポチりました。
うまく組めるかはわかりませんが、ちょっと挑戦してみようかと思います。

続きを読む 雑記お買い物  コメント (0)  2018/11/14 21:41:42

python の pip でインストールできる自作モジュールを作ってみる

Java にはライブラリの依存性を管理するためのつーるとして Maven や Gradle がありますが、Python の世界にもパッケージ管理ツールとして pip があります。コードの規模が大きくなってくるとモジュール化は避けては通れない課題なので、今回は pip を使って、Python での自作モジュールの作成と呼び出しをしてみようと思います。

自作モジュールを用意する

まずは作業をするための自作モジュールのディレクトリを作り、その中に移動します。ディレクトリはなんでもいいですが、わかりやすいようモジュール名と同じにしておきます。
$ mkdir libhollow
$ cd libhollow

このディレクトリ内に、自作モジュールのためのファイルを用意します。
ディレクトリ内に、さらにモジュール名と同じディレクトリを作成します。
$ cd libhollow
そしてこのディレクトリ内部に __init__.py を作成します。中身は空でよいので touch コマンドで作ります。
$ touch libhollow/__init__.py
同じくモジュールに含める Python のコードも入れておきます。ここでは libhollow/jackolantern.py というファイル名で、以下の Python コードを置いておきます。
# -*- coding: utf-8 -*-

def call():
    print "Trick or Treet"
Python コードの内容としては、"Trick or Treet" と表示される call() を定義しているだけです。

ここまで見てくると、これが通常の Python パッケージの作りかたと同じであることに気づくかもしれません。Python に、sys.path 上にあるパッケージを import させるには、まずパッケージ名のディレクトリを作ってソースコードを置き、いっしょに __init__.py もいれておく必要があります。pip でインストールできる自作モジュールを作る際にも、モジュールのコードや __init__.py は同じようにモジュール名のディレクトリ内部に置いておくことになります。
続きを読む python  コメント (0)  2018/11/02 13:02:57

ElasticSearch でインデックス時と全文検索時で異なる analyzer を設定する

前回は ElasticSearch が全文検索クエリを処理する際の分かち書きのしくみについてふれました。ElasticSearch ではさまざまな種類の tokenizer を中心に analyzer を設計することができ、この analyzer が実際に文字列の単語分割を行ってくれます。
ElasticSearch ではインデックスに格納するドキュメントの内容(フィールドの値)と、全文検索クエリの検索キーワードに対して分かち書きが行われますが、この 2 つに対して異なる analyzer を適用することができます。今回は、インデックスにドキュメントを格納する際の転値インデックス作成時と、検索キーワードを渡した全文検索クエリでの検索時とで、異なる analyzer を利用してみたいと思います。

インデックス時と全文検索時の analyzer の単語分割結果を確認する

ElasticSearch では、インデックスにドキュメントを格納する際の転値インデックス作成時に適応される analyzer と、全文検索クエリで渡される検索キーワードに適用される analyzer を設定できます。となるとインデックス時と全文検索時に動作している analyzer の処理結果をそれぞれ確認したいということになると思います。まずはじめにこれらの分かち書きの結果を確認する方法についてみておきます。
続きを読む ElasticSearch  コメント (0)  2018/10/12 17:43:15

ElasticSearch の全文検索での analyzer について

前回の ElasitcSearch での文書検索についての記事の中で、ElasticSearch の中核となる機能である全文検索クエリについて触れました。
ElasticSearch の全文検索クエリでは、文書を単語に分割する分かち書きという工程を経て、その単語が含まれる文書が検索されます。しかし、はたして何を単語とみなすかというのは難しい問題です。普段人間が使っている言葉の種類は国や言語、時代によって膨大な量になりますし、常に新しい言葉、失われていく言葉が存在しています。また同じ言葉でも文脈や使われる分野によって意味が変わったり、1 つの言葉なのに文字で表現しようとすると何通りも書き方があったりします。現時点ではあらゆる単語を分かち書きできるような技術は残念ながら存在していないので、全文検索を適用したい分野にあわせてどのように分かち書きしていくかを自分で設計していく必要があります。
ElasticSearch では単語分割は analyzer によって処理されます。この analyzer には単語分割に関わる言語処理機能を必要に応じて組みあわせて使えるようになっています。今回はこの analyzer がどのように分かち書きを行っていくのか、ElasticSearch の analyzer による言語処理機能の具体例を見ていこうと思います。

analyzer による単語分割の流れ

ElasticSearch における analyzer は、分かち書きする文字列中の各文字を追加/変更/削除する character filtercharacter filter から受け取った文字列を実際に単語に分割する tokenizertokenizer が分割した単語の列から単語単位で追加/変更/削除する token filter の 3 つによって構成されています。analyzer には必ず 1 つの tokenizer が設定されていなければなりませんが、character filter と token filter はオプションとなっていて、任意の数を設定することができます。

一応定義どおりに analyzer の構成要素を説明するとこうなるのですが、感覚としては、中心となる tokenizer が単語分割しやすいように tokenizer の前処理 / 後処理として必要なフィルターを設定していく、くらいで良いと思います。ElasticSearch にあらかじめ組み込まれているビルトインの token filter には、どちらかというと character filter としてあるべきなのではと思うものもあったりします。また高機能な tokenizer には、他のビルトインのフィルターと同等の機能を内包していたりするものもあります。
続きを読む ElasticSearch  コメント (0)  2018/10/11 19:07:40

ElasticSearch で文書を検索をしてみる

ElasticSearch で提供されている代表的な文書の検索機能には、全文検索クエリと Term ベースクエリがあります。全文検索クエリは、検索時のキーワードが含まれているるドキュメントを探し出すための検索クエリです。一方 Term ベースクエリは、検索時のキーワードが完全に一致するドキュメントを探し出すための検索クエリになります。

よくある検索エンジンのようにキーワードが含まれている WEB ページを探すというような用途では全文検索クエリが適していますが、ユニークなキー値のようなものをキーワードにして、そのキー値が割り当てられている文書を探すような用途では Term ベースクエリが適しています。全文検索クエリではあらかじめ文書が単語に分割されて、その単語に対して検索が行われますが、Term ベースクエリでは文書が単語に分割されず、キーワードと完全一致するかで検索されます。ユニークなキー値で検索を行う場合、そのキーワードの一部分ではなくすべてが完全に一致するドキュメントを検索しなければならないので、Term ベースクエリの方が適していることになります。

今日はこの全文検索クエリと Term ベースクエリについて、実際にインデックスを作りながら試していきたいと思います。

検証データを用意する

前提として、今回は以下のインデックスを使うものとします。
$ curl -XPUT http://localhost:9200/samurai -H "Content-type: application/json" -d '{
  "settings": {
    "number_of_replicas": 0,
    "number_of_shards": 1,
    "analysis": {},
    "refresh_interval": "1s"
  },
  "mappings": {
    "_doc": {
      "properties": {
        "name": {
          "type": "keyword"
        },
        "description": {
          "type": "text"
        }
      }
    }
  }
}'
このマッピングでは、name フィールドは keyword 型、description フィールドは text 型としています。

また、このインデックスには以下のドキュメントを入れておきます。
$ curl -XPOST http://localhost:9200/_bulk -H "Content-type: application/json" -d '
{ "index": { "_index": "samurai", "_type": "_doc" } }
{ "name": "真田昌幸", "description": "甲斐国の武田信玄の家臣となり信濃先方衆となった地方領主真田氏の出自で、真田信之、真田幸村の父。" }
{ "index": { "_index": "samurai", "_type": "_doc" } }
{ "name": "真田信之", "description": "真田昌幸の長男。徳川家康の養女を妻としていたため関ヶ原の戦いでは東軍につき、江戸時代には松代藩藩主をつとめた。" }
{ "index": { "_index": "samurai", "_type": "_doc" } }
{ "name": "真田幸村", "description": "真田昌幸の次男。豊臣家臣の大谷吉継の娘を妻としていたため関ヶ原の戦いでは西軍につき、父真田昌幸とともに戦死した。" }
{ "index": { "_index": "samurai", "_type": "_doc" } }
{ "name": "石田三成", "description": "豊臣政権の五奉行の一人。秀吉の死後、徳川家康を倒すため決起するが、関ヶ原の戦いで敗れ、その後処刑された。" }
{ "index": { "_index": "samurai", "_type": "_doc" } }
{ "name": "徳川家康", "description": "豊臣秀吉の天下統一後に台頭した武将で、関ヶ原の戦いに勝利し、江戸幕府を開いた。" }
'

続きを読む ElasticSearch  コメント (0)  2018/10/10 20:00:43

ElasticSearch 6.4.2 をさわってみた

データを全文検索するためのエンジンである ElasticSearch を触っていきたいと思います。全文検索というと WEB ページや文書のキーワード検索として広く利用されていますが、最近では RDB への参照性能を改善するため、代替手段として使われる場面も多いようです。RDB から適切なタイミングでデータを同期してやる必要があるものの、複数のテーブルやデータベースから必要なデータのみを集約して参照させるという用途では、RDB よりもはるかに高速にアクセスでき、RDB とは切り離した擬似的な参照系として構築できる点が評価されているようです。
ElasticSearch も他の分散システムと同じくノードを複数台用意したクラスター構成をとることができますが、今回は手始めということで、シングルノード構成での環境構築からやってみたいと思います。

ElasticSearch をインストールする

公式サイトのダウンロードページから ElasticSearch の最新版をダウンロードします。現時点での最新版は 6.4.2 でした。Linux 向けには rpm パッケージが公開されていたので、これを使うことにします。
ダウンロードした rpm パッケージをインストールします。
# rpm -ivh elasticsearch-6.4.2.rpm
ElasticSearch をインストールすると、/etc/elasticsearch/elasticsearch.yml として設定ファイルが作られます。シングルノード構成の場合には特に elasticsearch.yml を編集しなくても動くのですが、複数ノード構成でクラスターを組む場合には書き変えてやる必要があります。

インストールした ElasticSearch は、systemctl start コマンドから起動できます。
 
# systemctl start elasticsearch.service
また、自動起動を有効化する場合は systemctl enable しておきましょう。
# systemctl enable elasticsearch.service

続きを読む ElasticSearch  コメント (0)  2018/10/09 20:05:50

Kafka Manager を構築してみたら Kafka 2.0.0 は対応していなかったお話

Kafka でクラスター中のノード(Broker)やパーティション、トピックを WEB ベースで管理するためのツールとして、Kafka Manager というものがあるそうです。
公式ページである Github リポジトリには、README.md 中に実際の WEB の UI が載っていました。表示されている情報としては、Kafka にバンドルされている kafka-topics.sh や kafka-consumer-groups.sh 等から取れるもののようですが、統計的に可視化されていたり、更新処理までできるようです。

Kafka Manager を構築する

公式ページからはバイナリや rpm パッケージ等は配布されていないようなので、自分でビルドしていきます。
まずは Github からソースコードを clone しておきましょう。
$ git clone git@github.com:yahoo/kafka-manager.git
ブランチは特に何も考えずに master を使うことにします。

ソースコードを取得したら、ビルドツールの sbt からビルドすることができます。
$ ./sbt clean dist
ビルドすると target/universal/ ディレクトリ配下に kafka-manager-1.3.3.21.zip ができあがります。これが Kafka Manager の実行バイナリを固めた zip ファイルです。

これを展開すると、bin ディレクトリ下に kafka-manager という実行バイナリがあります。これを使うと Kafka Manager が起動します。
$ bin/kafka-manager -Dkafka-manager.zkhosts=localhost:2181 -Dhttp.port=8080
システムプロパティ kafka-manager.zkhosts には Kafka の Zookeeper のホストを指定します。今回は localhsot で Kafka クラスターが動いているという前提で、同じマシンの Zookeeper を指定しました。 http.port 値は Kafka Manager 自体の待受ポートです。8080 ポートを指定しているので、http://localhost:8080 にアクセスすれば Kafka Manager を使うことができます。
続きを読む Kafka  コメント (0)  2018/10/05 19:54:32

コマンドラインから Sudachi で形態素解析してみる

日本語を品詞に分割する形態素解析器については、以前試してみた Mecab の他に、最近では Sudachi の評判がよいようです。それならばひとまずは触ってみようということで、今日は Sudachi をビルドして日本語の文章を形態素解析してみました。

Sudachi をビルドする

Github にてソースコードが公開されているので、 これを clone してきてビルドしてみます。
$ git clone git@github.com:WorksApplications/Sudachi.git
$ cd Sudachi
リポジトリには辞書をビルドするためのファイルもコミットされているので、サイズはそれなりに大きいです。lex なので字句解析器ですね。辞書自体は UniDic を使っているようで、ビルド時にダウンロードしている様子がビルドログから伺えます。
Sudachi は Maven プロジェクトなので、package ゴールまで実行すればビルドできます。
$ mvn clean package

実際に Sudachi を動かすにはビルドした jar ファイルを叩くのですが、そのままビルドしただけではもろもろの設定が足りていません。必要な設定ファイルのサンプルは src/main/resources/sudachi.jsonsrc/main/resources/sudachi_fulldict.json として置かれているので、これをベースに設定をしていきます。
systemDict 値には Sudachi が利用する辞書のパスを指定します。リポジトリ上では辞書ファイルの名前だけが書かれているので、このパスの辞書にアクセスできるディレクトリで jar ファイルを実行するか、systemDict 値自体を正しく指定し直す必要があります。Sudachi の辞書自体は、ビルドすると target ディレクトリに system_core.dicsystem_full.dic として生成されます。また同時に、圧縮された zip ファイルとしても、sudachi-0.1.1-SNAPSHOT-dictionary-full.zipsudachi-0.1.1-SNAPSHOT-dictionary-core.zip 等としてビルドされていました。

ここでは以下の内容の sudachi_fulldict.json を my_sudachi_config.json という名前でカレントティディレクトリにコピーし、以下の内容に修正しました。
続きを読む Sudachi  コメント (0)  2018/10/04 20:41:21
プロフィール HN: ももかん
ゲーム作ったり雑談書いたり・・・していた時期が私にもありました。
カレンダー
<<2018, 12>>
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345