姿勢のお話

こんにちわ。
リエです。

職業病とも言えますが、ここ数年反り腰での腰痛やストレートネックでの首の痛み、肩こりに悩まされております。

整体などへ定期的に行くべきかと思いますが、中々行けず自分で少しでも改善できないかと思い最近寝る前に簡単なストレッチをするようになりました。
YouTubeに動画を出してくださっている方ありがとうございます🙏

長年蓄積されてきたものなので日々のストレッチでの劇的な改善変化は難しいと思いますが、ストレッチを始める前よりも少し腰や首の負荷が軽減されたなという体の変化を感じております。
変化を感じると毎日やろうというモチベーションへと繋がりますね。

寝る前の数十分。いつもはスマホを見てダラダラしてしまう時間をストレッチに当てることで入眠もスムーズになりました。最初はめんどくさいなと思っていましたが、今は逆にストレッチをしないと気持ち悪く感じるようになり三日坊主の私が数週間続いております。

体の調子をもっと整えれるようこれからもストレッチを続けます✊✨


経験の浅いプログラマーにVimを推奨すべきかせぬべきか

エディターは人それぞれですし歴史があり宗教戦争に発展するので他人にとやかくいうものではないと思います。でもそこに経験の浅いプログラマーが入ってきた場合は?この場合おすすめするかどうかは非常に悩みどころです。

遠い遠い昔の初めてプログラミングを行った専門学校の時代はPCに入っていたメモ帳での開発でした。当時のことを思い返せばよくもまぁ全角スペースすら見落としやすいメモ帳で100ファイル近くのファイルを管理してjavaで卒業作品にゲームを作ったなと思います。その後に最初の会社でEmEditorに出会いこんなに便利なエディターがあるんだと感動しEclipceの当時の重さに苦慮しつついつからかVimがおすすめと言われてVimを使い出しました。

vim

vimは便利です。慣れれば今でも十分使えるし使いやすいエディタだと思っています。大体のUnix系OSに入ってるので特にサーバーで作業する際とか緊急時の対応とかに助かります。軽いしターミナルだけで作業できるしマウスいらずで便利です。でもこれはvimを長年使っているから言えることです。

vimは最初のとっかかりに戸惑います。いろいろ操作やコマンドを覚えたり設定を行なったりプラグインを入れたりすればすごく使いやすいのですがそこまでいくのに時間がかかります。入ってすぐにいろいろなことを覚えないといけない状況でVimまで覚えることになると負担が大きいので基本的になしかなと個人的に思ってます。今ならもうvim以外のエディターで軽くてお手軽に始められて拡張性もよく使い勝手のいいものは既に出てるのでは?と考えてしまうことも多々あります。メモ帳代わりに使ってますがVSCode辺りがそれに近そうです。

自分の出した結論は基本的には推奨すべきでない。仕事に慣れて余裕ができて興味があってようやくレベルかなと・・・ターミナルだけで作業できてマウスいらずで便利なんですけどね

上記だけで終わるとアレなので自分がよく使っているコマンド等を記載して終わります。

1行削除の「dd」
1行コピーの「yy」
ペーストの「p」
末尾に移動する「$」
123行目へ移動する「123G」
特定の文字に囲まれている中を削除する「di’」「di”」
ビジュアルモードでの加工や範囲選択での置換
インサートモードから抜けるEscの代わりに「jj」
=などのインデントを自動で行ってくれる自動整形プラグイン
構文エラーチェックのシンタックスエラー検知のプラグイン

特に行番号への移動や行コピーや行削除、ビジュアルモードでの加工はよく使います。


Solr 8.10 で追加された Schema Designer UI

はじめに

Solr 8.10 で管理画面に Schema Designer UI が追加されました。
https://solr.apache.org/guide/8_10/schema-designer.html

  • ドキュメントのサンプルからスキーマを作ってくれる
  • スキーマをGUIで編集できる
  • 編集中のスキーマの設定でクエリがどんな動きになるか動作確認できる
  • 作ったスキーマに基づいたコレクションを作成できる

と至れり尽くせりです。

使い方

名前を付けて新しいスキーマを作る

スキーマの名前と、元になる設定の名前を与えて新しいスキーマを作成します。

ドキュメントのサンプルを与えてスキーマの設定を生成する

インデックス対象のドキュメントをテキストエリアに貼り付けるか、ファイルを指定するかして与えます。ドキュメントは1個でも解析してスキーマを作ってくれますが、ドキュメントを複数与えておけば、後でクエリの動作を確認するときに色々なパターンを試せます。

今回サンプルとして与えたのは以下のようなドキュメントです。

[
{"id":"10","type":"官公庁","area":"住之江区","name":"軽自動車検査協会大阪主管事務所","address":"住之江区南港東3-4-62","address_p":"34.6164938333333,135.438210722222"},
{"id":"11","type":"官公庁","area":"住之江区","name":"大阪陸運支局なにわ自動車検査登録事務所","address":"住之江区南港東3-1-14","address_p":"34.6190439722222,135.442191833333"},
{"id":"12","type":"官公庁","area":"住吉区","name":"住吉税務署","address":"住吉区住吉2丁目17番37号","address_p":"34.6109641111111,135.491388722222"}
]

生成されたスキーマの画面です。
JSONでフィールド名を与えているのでフィールド名が正しいのは当然として、サンプルの内容を解析してフィールドタイプもそれなりに妥当なものを選んでくれます。
たとえば上のように、緯度経度を値に持つ address_p フィールドに対して location タイプが選ばれています。

スキーマの設定を変更する

設定を変更することもできます。 住所を格納する address フィールドに対して string タイプが選ばれていましたが、ここでは形態素解析をする text_ja フィールドに変更しました。

Analyzer の動作を確認する

形態素解析をするフィールドでどのような解析が行われるか動作確認ができます。

クエリの動作を確認する

現在のスキーマの設定でクエリがどのように動くかを確認できます。

このときクエリの対象となるのが、最初に与えたサンプルドキュメントになります。今回はドキュメントを3件(id が 10, 11, 12)与えたので、全件検索で3件ヒットしています。

area フィールドを対象としたファセットで「住之江区」が2件、「住吉区」が1件となることも分かります。

変更前の設定との差分を確認する

元になった設定(_default)からの、現在の設定の変更点を表示します。

作成したスキーマを利用してコレクションを生成する

生成した設定は Zookeeper のツリー上に保存されますが、この設定を利用して一気にコレクションを生成することもできます。


LUUPしてみた

日々、世の中の状況が変わってきてますが相変わらずのマイペースでいきましょう。
マエダです。

RIDE YOUR CITY – 街じゅうに好きがみつかる-
『LUUP』https://luup.sc/

みなさまご存知でしょうか。
ちょっとの移動がとってもラクになるシェア電動キックボードサービス。
※ TBS系列「がっちりマンデー」で見たやつやん。

大阪市内では東西の移動が徒歩・バス・タクシー以外でちょっとしにくくてレンタサイクルサービスを利用していたんですがついに大阪市内にもLUUPが来てました。

今年の4月にはリリース出てたのに視野の狭い僕はこんな近くに展開されていたなんて全く気づいてませんでした。
https://luup.sc/news/2021-04-02-osaka/


■ 使い方

かんたんなので割愛させていただきます。

注意点としては「LUUP全然使ったことあるぜ!」みたいな顔して意気揚々とQRコードスキャンしたら運転免許証画像アップロードと交通に関するテストを受けてねとあったので、登校前にイチャイチャしながらトークしている高校生カップルを横目に必死におじさんが設定登録をする時間もUXのひとつでしたね。

■ 感想

「チャリでええやん。」いや愛知県出身としては「ケッタでええが。」
と思うところもありますが、自転車と違う都会的な移動手段を選択している自分に酔えます。
おじさんなので年齢的に気恥ずかしさを覚えつつ、たたの移動を『たのしい』ものに変えてくれる。
そんな体験ができました。

一通の道路やちょっと怖くなったら押して徒歩もできるので今度はもっと精神的に余裕をもって街じゅうに好きを見つけてみます。

交通ルールを守って安全にたのしみましょう。


[Solr]更新の際に _route_ パラメータは指定しない方が良い

今回は小ネタです。

SolrCloud でとある検証をしているときに不思議な現象に気付きました。

ドキュメント1を追加
→ 全件検索でドキュメント1がヒットする
→ ドキュメント2を追加
→ 全件検索でドキュメント2だけがヒットする
→ ドキュメント3を追加
→ 全件検索でドキュメント3だけがヒットする
→ …

要するに、新しいドキュメントを追加するとそれ以前のドキュメントが消えるという現象です。

いろいろ試すうちに、あるスクリプトを使って更新した場合にこの現象が発生し、別のスクリプトでは発生しないことが分かりました。2つのスクリプトを比較することで、問題が起こる方では update の際に _route_ パラメータを指定していることが分かりました。

コレクションを CREATE するときに _route_ パラメータを指定していれば update のときに _route_ を指定する必要はありませんが、どのフィールド値でルーティングしているのかが分かりやすいように明示的に _route_ を書いたのが仇となったようです。

ログを見ても _route_ パラメータ有りの場合と無しの場合とで目立った違いは無く、どうしてこうなるのかを調べるにはソースを深く追っかけてみるしかなさそうです。