1989年ごろの大阪の地図

部屋の整理をしていたら古い神戸・大阪の地図が出てきました。発行は1989年2月となっています。大学生となってこちらに出てきたときに買ったものだと思います。30年以上前のものとあって今とは大きく違っている場所も多く、面白くてずいぶん時間をつぶしてしまいました。

まず目に付いたのは鉄道の路線図です。大阪地下鉄の路線図を見ると1990年の花博よりも前とあって長堀鶴見緑地線がありません。それより後に開業した今里筋線も当然ありません。堺筋線が動物園前駅までしかなかったり、ニュートラムが中ふ頭駅までで中央線とつながってなかったりするのもツボです。

京阪神広域の路線図で今と違うところを探すのも楽しいです。

グランフロントのない梅田。右上の扇町公園に移転前の大阪プールがあるのもポイント高いです。

まだ大阪球場のある難波。

ひとつ残念だったのは、1989年2月というと26区から24区への変更のあったときで、この地図はぎりぎり変更後のものだったということです。中央区になる前の東区と南区とか、北区に合併される前の大淀区とかの表示がある地図だったら良かったのになあという気もします。もしそうだったら買った当時には不都合があったかもしれませんが。

MacBookを新しい端末に移行してみた

もうIntel Macには戻れない。
マエダです。

先日、M2チップ搭載のMacBook Airに開発環境を移行してみました。

M2というからには現状一番スペックが高いのかと思ってましたが、M1 < M2 < M1 Pro < M1 Max < M1 Ultraというポジションのようです。
僕はグラフィック編集や動画編集ができるスキルは持ってないためM2で十分です。

これまで仮想環境をローカルで動作させたりしているとものすごい音がしていたこともありましたが、M2になってからは全く音がなくなり快適に利用できています。

利用に際してポイントは以下。

■ CocoaPodsはgemでなく、Homebrewでインストールすべし

こういった動作確認できるかできないかの問題は時間が解決してくれますが、現状brewでインストールしておけば正常に利用可能です。

sudo gem install cocoapods

brew install cocoapods

https://cocoapods.org/

■ Intel Mac用アプリもRosettaで互換できるかもしれない

すべてのアプリの検証は不可なため「かもしれない」としてますが、移行に不安な方もこういったものがあるんだなくらい知っておくと新しい端末に移行してみようと思えるかもです。

https://support.apple.com/ja-jp/HT211861

■ ローカルVMはMultipassが便利

vagrantを使ってきましたが現状正常動作できておらずこちらも時間が解決してくれると思いますが、UbuntuユーザーならMultipassというVMが非常にシンプルで便利です。

https://multipass.run/

移行するときにいろいろと作業に便利なシェル関連をコピペすることがあるかと思いますが、古い端末から新しい端末へのコピーは共有ドライブを利用したりしてましたがイマドキはドラッグ&ドロップでできてしまいます。

※ Apple公式からお借りしました。

https://support.apple.com/ja-jp/HT212757

こんなことができるなんて知らなかったし調べたこともなかったのでひとつの端末でどちらも操作できたときは失礼ながらバグったのかと思いました。。。

どんどん便利になってとても快適。

僕たちもワクワクするようなプロダクトを提供できるようがんばります!

[Solr] Atomic Updates による部分的な更新

Solrの更新は基本的に上書きです。更新する必要の無いフィールドの値もすべて指定して更新処理を呼び出します。たとえば以下のようなドキュメントがインデックスされているとします。

{"id":"1", "title":"タイトル1", "body":"本文1", "remarks":"備考1"}

remaksがrequired=”false”なフィールドだとすると、

{"id":"1", "title":"タイトル2", "body":"本文2"}

で更新すると

{"id":"1", "title":"タイトル2", "body":"本文2", "remarks":"備考1"}

ではなく

{"id":"1", "title":"タイトル2", "body":"本文2"}

になります。

ただし、更新対象となるドキュメントのすべてのフィールドが stored=”true” または docValues=”true” である場合には特定のフィールドだけを部分的に更新することができます。これを Atomic Updates と呼びます。

以下のスキーマ定義で

    <field name="type"     type="string"  indexed="true" stored="false" multiValued="false" docValues="true" useDocValuesAsStored="true"/>
    <field name="area"     type="string"  indexed="true" stored="valse" multiValued="false" docValues="true" useDocValuesAsStored="true"/>
    <field name="name"     type="text_ja"  indexed="true" stored="true" multiValued="false"/>
    <field name="address"  type="string"  indexed="true" stored="valse" multiValued="true" docValues="true" useDocValuesAsStored="true"/>
    <field name="address_p"  type="location"  indexed="true" stored="false" multiValued="false" docValues="true" useDocValuesAsStored="true"/>
    <field name="score"     type="pint"  indexed="true" stored="false" multiValued="false" docValues="true" useDocValuesAsStored="true"/>

以下のデータが入っているとします。

$ curl -s 'http://localhost:8983/solr/osaka_shisetsu4/select?omitHeader=true&q=*%3A*'
{
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"10",
        "name":"軽自動車検査協会大阪主管事務所",
        "area":"住之江区",
        "score":10,
        "address":["住之江区南港東3-4-62"],
        "address_p":"34.6164939,135.4382107",
        "_version_":1709611640162353152,
        "type":"官公庁"}]
  }}

Atomic Update で部分的に更新します。

[{
    "id":"10",
    "type":{"set":"官公庁1"},
    "address":{"add":"すみのえくなんこうひがし3-4-62"},
    "score":{"inc":3},
}]
  • type の「官公庁」を「官公庁1」で置き換え
  • address (multiValued)に「すみのえくなんこうひがし3-4-62」を追加
  • score の 10 に 3 を加算
$ curl -s 'http://localhost:8983/solr/osaka_shisetsu4/select?omitHeader=true&q=*%3A*'
{
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"10",
        "name":"軽自動車検査協会大阪主管事務所",
        "area":"住之江区",
        "score":13,
        "address":["すみのえくなんこうひがし3-4-62",
          "住之江区南港東3-4-62"],
        "address_p":"34.6164939,135.4382107",
        "_version_":1709615534472953856,
        "type":"官公庁1"}]
  }}

add の代わりに add-distinct を指定すると、その値が含まれていないときだけ追加されます。

multiValued のデータから値を削除することもできます。

[{
    "id":"10",
    "address":{"remove":"すみのえくなんこうひがし3-4-62"}
}]

正規表現を使って複数削除することもできます。

[{
    "id":"10",
    "address":{"removeregex":"すみのえ.*"}
}]
$ curl -s 'http://localhost:8983/solr/osaka_shisetsu4/select?omitHeader=true&q=*%3A*'
{
  "response":{"numFound":1,"start":0,"numFoundExact":true,"docs":[
      {
        "id":"10",
        "name":"軽自動車検査協会大阪主管事務所",
        "area":"住之江区",
        "score":13,
        "address":["住之江区南港東3-4-62"],
        "address_p":"34.6164939,135.4382107",
        "_version_":1709616620606849024,
        "type":"官公庁1"}]
  }}

オーストラリア料理

こんにちは。開発担当のマットです。

今、日本に住んでいますけれども、オーストラリア生まれ育ちで、このあいだ、家族と会うためにオーストラリアに一時的に帰国させていただきました〜 (行きも帰りも2週間の隔離をやりましたので、ご安心くださいw)

オーストラリアに行っている間、日本で中々食べられないオーストラリア料理や調味料を食べれて、この記事でそれらを日本人の皆様に紹介したいと思います。

ミント・ゼリー

英名: Mint Jelly

Author: Jeremy Keith from Brighton & Hove, United Kingdom

ミント・ゼリーはその名の通り、ミントから作られるゼリーです。
実はミントよりも、リンゴ酢と砂糖がメインな具材ですけれども、ミントをちょっと入れるだけでミントの味が勝ちますね。
デザートではなく、ラム肉や焼き野菜の上にちょっと乗せる調味料です。

実は一年前、親戚の畑の一部がミントにはびこっていましたので、採りに行って自分で作ろうとしました。家中がミントの匂いに覆われ、最終的に酸っぱくなりすぎて、あまり美味しくないものをできてしまいました。
でも、美味しいミント・ゼリーを食べたら、抜群に美味いです。

日本人も絶対好きな味だと思います。

ミート・パイ

英名: Meat Pie

Author: Finbar.concaig

毎日の朝食に、ミート・パイを食べるオーストラリア人は少なくないと思います。

オーストラリアのパン屋さんに行くと、食パンの次に多いのはパイです。
多くの味があります。ビーフのパイは代表的ですが、カレー・チキン、ステーキ・マッシュルームなど、多くの種類はあります。

一度、贅沢をして、「和牛ステーキ・ブルーチーズ・マッシュルーム」のパイを食べたことがあります。
最高に美味しかったです。

オーストラリアですので、必ずケッチャプをたくさん掛けます。
ちなみに、オーストラリアで「ケッチャプ」の言葉は決して言いません。「トマト・ソース」と呼びます。

牛肉コロッケなどが好きな方なら、ミート・パイを気に入ると思います。

パヴロヴァ

英名: Pavlova

Author: William Brawley

メレンゲのケーキを焼いて、その上に生クリームとフルーツを乗せるデザートです。
メレンゲの味付けもできますし、フルーツを好きなものにできますので、各家族に「ウチの味のパヴロヴァ」ってありますね。僕はレモンメレンゲにキウィフルーツが好きです。

もともとロシアのバレーダンサーの家庭のレシピだったそうですが、オーストラリアとニュージーランドで流行りまして、そこからオージー・ニュージーのデザートを代表するヒットになりました。

日本でも流行ったら大人気になると思います。

ベジマイト

英名: Vegemite

Author: Tristanb

僕の心の中でベジマイトは日本の納豆の役割を果たしています。
日本人の中でも納豆の好き嫌いはありますが、外国人に「納豆を食べれますか?」と聞くことが多い。
ベジマイトも同様。オーストラリア人の中にも好き嫌いは多いけど、「オーストラリア人しか食べられないでしょう…」のイメージが付いている物ですね。

味自体は苦いです。
イースト菌と野菜のエキスから作られているスプレッド(パンに塗るもの)です。

青汁とか、濃い味噌の味が好きな方なら、日本人の中でも好きな人はいるかと思いますが、おそらく99%の日本人はベジマイトを食べたら「嫌い」というと思いますw

まとめ

他にもたくさんありますが、この記事を書くと、お腹がペコペコになってしまいました。
冷蔵庫にあるベジマイトを久しぶりに出して、サンドイッチでも食べようかな。

ソフトウェアの開発担当として、毎日コツコツ、近くにいるエンジニアさん達からも、インターネットの方々からも、色々なことを学んで、自分の力を磨き上げることは仕事です。
私生活にでも、食生活にでも、近くにいる人と外国からも、良い知識を学んで、新しい料理を作ってみたりとかして、日常を少し豊かにすることはいいかもしれませんね。

[Solr] Stored フィールドと DocValued フィールド

Solr の検索処理の要は転置インデックスです。転置インデックスは概念的には以下のようなデータ構造になっています。

キーワード文書ID
製品文書1,文書3,文書4
部品文書2,文書5,文書6

転置インデックスを使うことで、「部品」を含む文書の文書IDが2と5と6である、といったことを効率良く調べることができます。ただし、利用する機能(ソート、ファセット、ハイライティング)によっては特定のドキュメントに含まれるキーワードを調べるためのデータ構造があると効率が良いことがあります。それが DocValues です。

DocValues は以下のようなデータ構造です。

フィールド名文書ID→フィールド値のマップ
name{“文書1″:”製品1”, “文書2″:”部品1”, “文書3″:”製品2”, “文書4″:”製品3”, “文書5″:”部品2”, “文書6″:”部品3”}
price{“文書1”:1000, “文書2”:100, “文書3”:2000, “文書4”:3000, “文書5”:200, “文書6”:300}

すべての文書(あるいは特定の文書セット)における特定のフィールド値をまとめて取得できるデータ構造となっています。

たとえば name:部品 という検索で price フィールドを対象にファセットを作るとします。
この場合、転置インデックスによって「部品」を含む文書IDが2,5,6であることが分かり、それぞれの price フィールドの値が 100,200,300 であることが効率よく調べられます。
DocValues を使うには、対象としたいフィールドの定義で docValues=”true” を指定します。

文書IDからフィールド値を調べるためのデータとしては、フィールド定義で stored=”true” を指定することで格納されたフィールド値も利用できます。stored のデータ構造は以下のようなものです。

文書IDフィールド名→フィールド値のマップ
文書1{“name”:”製品1″, “price”:1000}
文書2{“name”:”部品1″, “price”:100}
文書3{“name”:”製品2″, “price”:2000}
文書4{“name”:”製品3″, “price”:3000}
文書5{“name”:”部品2″, “price”:200}
文書6{“name”:”部品3″, “price”:300}

特定の文書IDに紐づくすべてのフィールド値を一括して取得できるデータ構造となっています。

stored=”true” かつ docValues=”false” なフィールドに対してソート、ファセット、ハイライティングといった処理をするために、DocValues に近いデータ構造が FieldCache として Java ヒープ上に作られます。FieldCache は実行時に作られるもので、キャッシュデータが揃うまでに時間が掛かるとかJavaのヒープ使用量が大きくなるとかいった欠点があります。

それに対して DocValues はインデックス作成時に同時に作られます。OSのファイルキャッシュに乗るため、実行時のコストを小さくすることができます。