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のファイルキャッシュに乗るため、実行時のコストを小さくすることができます。


一年後も崩れにくい服のたたみ方

数ヶ月着ないうちにタンスの中でグチャッとなったシワシワのTシャツ、たまに見かけることないですか?
このたたみ方を習得すると、1年後もタンスの中で畳んだときの姿のままで保存することができます。

今回は、Tシャツ、長ズボン、パーカーのたたみ方をご紹介します。

一年後も崩れにくい、Tシャツのたたみ方

① シワを伸ばして広げておいたら、上下から中心に合わせてたたみます
② 次に左右から中心に合わせてたたみます
③ ここがポイント!裾側に襟側を入れ込む!
④ 完成!
フリスビーのように壁に投げても崩れません。

一年後も崩れにくい、長ズボンのたたみ方

① 背面が下に来るようにおいたら、上下半分にたたみます
② お尻の飛び出た部分を折り込んでまっすぐになるようにします

③ 半分にたたみます
④ ウエスト側を3分の1を目安に内側へたたみます

⑤ ここがポイント!ウエスト側に反対側を入れ込む!
⑥ 完成!

ズボンも壁に投げても崩れませんでした。

一年後も崩れにくい、パーカーのたたみ方

① シワを伸ばして広げておいたら片側から中心に合わせてたたみ、そでにもシワが寄らないように裾に向かって広げてたたみます
② 反対側も同様にたたんだら、フードの形を整えます

③ 4分の1を目安に、裾側を中心へ向かってたたみます
④ 裾側の四角(黄色)のサイズになるようフード側もたたみます

⑤ ここがポイント!(3回目)裾側にフード側を入れ込む!
⑥ 完成!

きれいに畳む事ができました。ぜひ、お試しください。