Categories

最新コメント

meta-tags側のtruncateでは、スペース文字のところで切り詰めが行われます

wakairo @wakairo
最終更新

meta-tagsのv2.21.0で'truncate_on_natural_separator'の設定が追加されました。この設定を利用することで、スペース文字のところでの切り詰めを回避できるようになりました。このことを上のコメントに反映しました。

0
Raw
https://www.techtips.page/ja/comments/306
😄1
🔄1
🔧1

WingetUIはv3.1からUniGetUIに名称が変更されました

wakairo @wakairo

winget以外のパッケージ・マネジャーも多数サポートするようになってきたため、WingetUIをUniGetUIにちかぢか名称変更しますというアナウンスメントが2024/03/13に出ていました。

2024/07/03にバージョン3.1がリリースされ、リリース名が初めてUniGetUIになりましたので、名称変更が完了したものと思われます。

なお、バージョン3.0のリリースではWingetUIという名称でした。

0
Raw
https://www.techtips.page/ja/comments/305
🔧1
💯1

activerecordでは、firstを使った方が実装とSQLが揃って可読性が上がる

takuma_tech Takuma @takuma_tech

こちらの記事によると、activerecordでlastを使った場合、指定したorderを逆にして"LIMIT 1"とするSQLが発行されるそうです。

一方で、firstを使った場合、指定したorderはそのままで"LIMIT 1"とするSQLとなるので、railsのコードとSQLの対応関係が分かりやすくなります。

したがって、lastよりもfirstを使った方が実装とSQLが揃って可読性が上がるということがこの記事で主張されていました。 ご参考まで。

0
Raw
https://www.techtips.page/ja/comments/304
🔧1
💡1
❤️1

WingetUIにおいてVCRedistのアップデート通知が繰り返される問題とその解決策

wakairo @wakairo

問題

WingetUIにおいて、Visual C++ 再頒布可能パッケージ(Microsoft.VCRedist.2015+.x64)がアップデート可能であると通知されるので、WingetUIからアップデート操作をして成功と表示されたにもかかわらず、すぐにまたアップデートが可能であると通知されることが繰り返されました。

どうやら、アップデート成功という表示は嘘のようで、実際にはWingetUIからこのVCRedistのアップデートには成功していなかった模様です。

解決策

コマンドプロンプトから以下のコマンドを実行したところ、アップデート通知が繰り返されることはなくなりました。

winget upgrade Microsoft.VCRedist.2015+.x64

つまり、WingetUIからアップデートが上手く行かないときは直接wingetでアップデートすると問題が解決することがあるようです。

参考

本件と関係するかは分かりませんが、以前のコメントにあるように、かつてWingetUIのインストールにおいて"Microsoft.VCRedist.2015+.x64"に関連するエラーが存在していました。

0
Raw
https://www.techtips.page/ja/comments/303
😄1
🔄1
😿1

LLMからJSON形式の出力を安定的に得るノウハウ

wakairo @wakairo

Zodスキーマでプロンプト生成を行い構造化データを自由自在に扱えて、LLMプロダクト開発が圧倒的に効率化した話

「TypeScriptをデータ出力例として与えると、かなり忠実に従ってくれるようになる」などのノウハウが示されている。

0
Raw
https://www.techtips.page/ja/comments/302
💡1

LLMからJSON形式の出力を安定的に得るノウハウ

wakairo @wakairo
最終更新

ChatGPT(OpenAI)のAPIにはスキーマで指定したJSON形式の出力を確実に得るための機能であるStructured Outputsがありますが、他のLLMではJSONのためのこういった機能や設定がない場合もあるようです。

このTopicでは、LLMから安定したJSONを得るためのノウハウやLLMの出力したJSONが問題ないかチェックするためのノウハウを扱います。

0
Raw
https://www.techtips.page/ja/comments/301
❤️1

Pythonライブラリの作成に関する公式情報

kenicode SatoKen @kenicode

pyproject.toml[build-system]の指定が、サンプルプロジェクトではsetuptoolsである一方、チュートリアルではデフォルト扱いがhatchlingになっていて、両者で違いがあって興味深いですね。 公式(PyPA)としては、setuptoolsがまだまだ現役であることを認めつつ、今後はhatchlingを推していきたいということなのかな?

0
Raw
https://www.techtips.page/ja/comments/300

Pythonライブラリの作成に関する公式情報

wakairo @wakairo
最終更新

なるほど、Pythonのパッケージングに関して、公式情報に相当する情報があるのですね。勉強になります。

それから、言及されているチュートリアルとサンプルプロジェクトのどちらも設定を書くのがsetup.pyではなくpyproject.tomlなのですね。 自分でも少し調べてみたのですが、python.orgにあるガイドには、「(パッケージングの設定には)pyproject.tomlファイルを使うのが標準的な慣習です。」と書いてあり、Zennの記事でも「現在でも歴史的経緯から setup.py のみで設定を行っているプロジェクトは多く存在しますが、このような構成は現在では非推奨」、「setup.pyを設定ファイルの一部として用いる場合であってもpyproject.tomlは配置するのが現在の標準的なセットアップ方法」と書いてある記事を見つけました。

どうやら、Pythonパッケージにはpyproject.tomlを用意すべし、pyproject.tomlを起点にしてPythonパッケージをビルドすべし、というのが公式見解のようですね。コマンドラインからsetup.pyを直接実行するやり方はlegacy、つまり、廃止予定とのことですし。

0
Raw
https://www.techtips.page/ja/comments/299
🙋1

Pythonライブラリの作成に関する公式情報

takuma_tech Takuma @takuma_tech

Pythonのライブラリを自作するときに、フォルダ構成や設定ファイルの書き方について知りたくなることがあります。ライブラリを公開するかどうかやどの程度きっちり作るかなど状況は様々だと思いますが、ソフトウェアの規模が大きいときやあちこちから呼び出す関数を整備するときなどに、ライブラリやライブラリに準じるものを作成することはよくあることだと思います。そういうときにどういう作り方が行儀の良いやり方なのかを探していて見つけた情報が以下のものです。

Python公式サイトのパッケージングに関するチュートリアル

https://packaging.python.org/ja/latest/tutorials/packaging-projects/

Pythonの公式サイトである「python.org」に置いてある文書ですので、信頼できる情報なのだと思います。

PyPAのサンプルプロジェクト

https://github.com/pypa/sampleproject

Pythonでのパッケージングに関するとりまとめを行っている組織であるPyPAが出しているサンプルですので、信頼できるのではないかと思います。

0
Raw
https://www.techtips.page/ja/comments/298
🔧1

コメントを利用してコマンドを再利用する方法

kenicode SatoKen @kenicode

同じコマンドをパパッと使い回す方法として便利なときがあるかもしれませんね。

それから、.bash_historyを後から見たり検索したりするなら、こういうコメントが残っていると実は便利なのかも。

0
Raw
https://www.techtips.page/ja/comments/297