ローカライズ文言管理ツール hoshi 0.8.0 をリリースしました
シンプルな仕組みで様々なワークフローに適合させることができるローカライズ文言管理ツール hoshi 0.8.0 をリリースしました。
hoshi についてはこちらの記事をご覧ください。
今回の主な変更は2つあり、一つはhoshi version形式でのパブリッシュです。これはフレーズメタデータを後工程で利用してツールを作る際に、全バージョンがマージされたデータが必要となるためです。これによりフレーズデータにキー以外のモデル名などを付与して、コードを自動生成させるといったワークフローを実装することができます。 また、プレフィクスを付与する運用においてプレフィクスが埋まってしまった場合に一度そこまでを全マージした上でカウントを巻き戻すという運用も見越しています。
もう一つはプロジェクト全体構成の整理です。 元々hoshiはhoshi Editorを中心としたGUIの環境をスタートラインに置いていましたが、実際はCLIのほうが進化が早く、hoshi-cliをhoshi本体とし、Editorを周辺ツールの立ち位置にする方が良いという考えに至ったからです。 また、CLIとEditorがかなり密に結合されていたので、npm workspaceでのマルチパッケージモノレポにプロジェクト全体を整理しました。
変更内容
- hoshi version 形式でのpublishに対応
- [Breaking Change] コンポーネントの名前を変更
- hoshi-cli → hoshi
- hoshi -> hoshi Editor
- プロジェクトの構成を npm workspace 形式のモノレポに変更
- その他バグ修正
ダウンロードはGitHubからどうぞ。
新しいローカライズ文言管理ツール hoshi を作っています
これまで担当してきたプロジェクトでは、たびたびローカライズ文言の管理に頭を悩ませることがありました。
もちろん日本語のみ対応すればよいプロジェクトであればソースコードにべた書きというという手もあり、時間がないプロジェクトでは実際にそうしてきましたが、本来ビューにある純粋なリソースであるので、単一言語でも文字列リソースとして管理されるべきだと考えています。
ローカライズ文言管理をプロジェクトに導入しようする際に、スプレッドシートベースの管理などいろいろ試してきましたが、どのプロセスも最終的にしっくりきませんでした。また、SaaSの導入も費用対効果の面で推し進めることがしづらいという課題があります。
これらの問題をまとめて解決できないまま数年過ごしてきたのですが、昨年新しいプロジェクトに入った際に思いついた方法があり、この方法を実現するための文言管理ツール hoshi を開発しています。 このツールはまだ未完成ではありますが、現在のプロジェクトで導入して一定の成果を上げつつあります。
この記事ではhoshiを作るに至った背景と、hoshi使った文言管理プロセスを紹介します。
続きを読むUkam 0.3.1 をリリースしました
C28セレナNissanConnectナビのAlexaをradiko受信機にする
2023年6月にセレナe-POWER LUXIONに乗り換えていた。セレナに新しく設定された最上位モデルで、一定条件下でハンドルから手を離せるプロパイロット2.0が搭載されたモデルだ。
もともと2018年末からセレナ e-POWERに乗っていたけど、5年の残クレで買っていてちょうど2023年末が買い換え時期だったり、納期が長期化していたというのもあったため、2022年末に先行予約ができるようになった頃には予約を入れていた。*1
結果的にかなり早めに納車されることとなり、お店で2番目のLUXION予約で、最初に納車されたLUXIONとなったらしい。
正直プロパイロット2.0はいらなかったのでLUXIONにする必要はなかったのだけど、ヘッドアップディスプレイがほしいと思い、迷う理由が金額しかなかったのでそれで決めることにした。
セレナのメーカーオプションナビはアリアやエクストレイルについているのと同系統の、日産の中では現状最上位クラス扱いのものがついている。 ここにAlexaが入っていて、ハンドルのボタンを押すことでAlexaの機能を使えるように設定できる。
うちではAlexaを家でradikoエリアフリー受信専用としてヘビーに使っているが、セレナのナビでもスマホ操作なしでナビの音声操作だけで再生ができるので非常に便利に使っているので、どのように使っているかまとめてみようと思う。
NissanConnectナビをWi-Fiにつなぐ
*1:納期長期化がなければ、そのあとに出る予定が見えてた他車と相見積もりのつもりだった。
Ukam - Re:別のディスプレイに表示されているウィンドウを強制召還するmacOSアプリ
以前、別ディスプレイにあるウィンドウを現在のディスプレイに移動させるmacOSアプリを作りました。
どういうアプリだったかというのを再度説明しておくと、マルチディスプレイ環境でMacを使っているときに、あるディスプレイを別の入力に切り替えてて表示されていないときに、別のディスプレイから見えないディスプレイのウィンドウを引っ張り出すというもの。
これを作ったのが2年以上前になることが驚きだったのだけど、自分の生活には手放せないものになっていました。 作った時点ではメニューが出てくるだけの素朴な作りだったのですが、それだけ手放せないものになっているのであればと、少し思い立ってここ数週間でもう少し見た目良く作り直しました。
Mac App Storeにあげるつもりでちょっと気合い入れて権限許可ダイアログとかも作ったけど、そもそもプライベートAPIも使っているし、他のアプリのウィンドウをアクセシビリティ経由で操作するのでサンドボックス化できないのでストアのガイドライン的にNGど真ん中なのでした。(しかもTestFlightの外部共有審査に出して気づいた)
よければ使ってみていただければと思います。
ReactでGoogle Maps JavaScript APIを組み込む
React+TypeScriptでGoogle Mapsを組み込んだページを作る際、これまではreact-google-mapsのようなライブラリを組み込んで実装してきました。 久しぶりにGoogle Mapsを使ったReactアプリケーションを作るにあたって現在の状況を調べてみたところ、公式のドキュメントにReact アプリケーションに Map と Marker を追加するというページがあり、@googlemaps/react-wrapperというものを使って組み込む方法が紹介されていました。
これまでサードパーティーのラッパーライブラリを使ってきた際、Google Mapの細かい制御をしようとした際に結局Google Mapsのインスタンスを直接操作することになりがちだったこともあり、より公式に近い方法があるのであればそちらに乗り換えたほうがいいと考え、このガイドを参考に実装してみました。
