なぜ脱OSSが増えているのか？
はじめに TerraformやVaultを開発するHashiCorpは自社製品をOSSのMPL(Mozilla Public License v2.0) から、ソースコードは公開するも一部の利用に制限があるBSL(Business Source License) への変更をアナウンスしました。 これは2018年のRedisを皮切りにMongoDBやCockroachDB、ElasticSearchなど多くのプロダクトで進められている脱OSSの流れです。商用のオープンソース[1]と言われてしまうこともある最近のこの動きの理由は何故なのか？ という点を以下の動画で解説しました。 動画中では尺の都合で端折った個所も多いので、こちらの記事の方にもまとめておきたいと思います。 OSSとは？ OSSの定義 まず、OSS（オープンソース）とはなんでしょうか？ これはRMSのフリーソフトウェアを源流とする
パスワードはおしまい！ 認証はパスキーでやろう
はじめに パスワードは古来より認証に良く使われる方法ですが、その運用の難しさからセキュリティの懸念とその対策としての運用の複雑さ（複雑で長い文字列、90日でパスワード変更など）が要求される大きく問題をもった仕組みです。 その根本的な解決策としてFIDO Allianceを中心に推進されている 「パスワードレス」 が注目されています。これはPINや生体認証とデバイス認証を使ったMFAからなっており、フィッシングやパスワード流出に強い上に、ユーザも複雑なパスワードを覚えなくて良い、という大きなメリットがあります。最近はこの流れでPassKeyというものが登場し、Apple/MS/Googleのプラットフォーマが対応したことで、本格運用に乗せれるフェーズになってきました。というわけで以下に解説動画を作ったのですが、動画中で時間の都合で触れきれなかったところや、JavaScriptによる実装のサン
その例外、いつキャッチするの？
はじめに 最近、若手のコードレビューをしていて例外の使い方を教える機会があったので、ブログの方にもまとめたいと思います。今回はバッチ編。オンラインだとまた少し違う観点があると思います。また、言語はJavaを前提していますが考え方は例外機構をもつ言語ならあまり変わりません。 TL;DR 例外は原則キャッチしない。バッチは速やかに殺せ 個別箇所でログを出さずに必要な業務情報はExceptionを入れ子にして乗せる 長いバッチのためにはスキップもやむなし 原則、例外はキャッチしない JavaにはErrorとExceptionが存在し、OutOfMemoryErrorとかプログラム上ではどうしようもないものがエラー、ファイルが存在しない(FileNotFoundException)とかプログラム側でハンドリングするもの、と教科書では習うと思います。なのでException系はキャッチするものと、と
はじめに 以前からユニットテスト/単体テストという言葉は使いづらい、と感じており今回も旧Twitterで「テストを実行時間ベースで分類する良い言葉ないかなー」と呟いていたところ、「テストサイズのSMLって考え方があるよ」と教えて戴きました。 だいたいは教えてもらったt_wadaさんの記事にすべて書いてあるのですが、自分の整理も含めて動画にしたので、その補完記事となります。 TL;DR 単体テストのバベルの塔は既に崩壊 CI/CDでの継続的テストには時間ベースのテスト分類が重要 UT/IT/E2EではなくSMLによるテストサイズがCI/CDには合う それは単体テストか結合テストなのか？ 自動テスト、手動テストに関わらずテストの分類として単体テストと結合テストという言葉は一般的です。 ITQBではTest Levelsという言葉で定義されていますし、以下のようなV字モデルの対応表はみんな知って
【ソフトウェア設計】モジュールをどう分割するのか？
はじめに 前々回や、前回に引き続き、ソフトウェア設計の指針に関する話をしたいと思います。 関数やクラス、そしてサービスなどシステムの塊の単位をモジュールと呼び、モジュールを作る事で、認知負荷を下げ複雑性と戦うという話をしてきました。では、モジュールは「いつ」分割するのが良いでしょうか？ また、他にも共通モジュールを不用意に作ってしまって苦労した人も多いのでは無いでしょうか？ 今回はそのあたりの話をしていきます。 TL;DR 以下があればモジュール設計を見直す 単純な要件/普段の利用に対して、タイプ量や約束事が多い 共通モジュールが「使われ方」に依存する モジュールの役割を一言で説明できない コード管理や性能/データ整合性など利用に際してのペナルティが高い 分割 is NOT 正義 - FizzBuzz Enterprise Edition 複雑性を排除するためにモジュール分割をすることは重
【ソフトウェア設計】例外処理を考える
はじめに 最近書いてるソフトウェア設計シリーズです。今回は例外に関して。以前、以下のような記事を書いたのですが、もう少し深堀して書いてみました。 ちなみにソフトウェア設計シリーズは他には以下を書いています。 モジュールになぜ分けるのか？ モジュール、依存、そしてカプセル化 モジュールをどう分割するのか？ 簡潔さは力なり？ 予測可能な振る舞いと簡潔さについて ドキュメントとしてのコメント TL;DR 例外は「原則」キャッチしない 業務例外や必ずハンドリングさせたい例外はOptionalなど戻り値の方が便利 だいたい以下の図が言いたい事のすべて 例外処理とは？ 「例外処理(Exception Handling)」は言語に依らず普遍的な関心事です。端的に言えば例外処理は異常やシステムの動作に不備が発生した際の特別な分岐処理です。リカバリやリソースの解放、あるいはユーザへの通知などがありますね。
今年の書初めコーディングはAITuberを創る！
はじめに あけましておめでとうございます。去年は何といってもAIの年でした。ChatGPTやStableDiffusionが2022年末に登場してから、想像を超えてAI周りが進化しましたね。今回は年の初めという事もあり、前から興味のあったAITuberを作ってみる事にしました。 「AITuberを作ってみたら生成AIプログラミングがよくわかった件」 って本も買ったし。LLM部分だけでは無く、OBSやYouTubeのコメント取得などAITuberに必要な内容が一式揃っていて非常に参考になりました。 また、私はプログラミングは多少できますが、イラストや音楽に関しては全くスキルの無い人間です。そのためそのあたりに関してはStable DiffusionやSunoAIの力を借りて作っているので、結果的にオール生成AIという感じですね。そのあたりも含めて記事にまとめたいと思います。 TL;DR 素の
はじめに Linuxの良い所の一つにsuやsudoと言った特権管理の仕組みがあります。普段は通常アカウントで入って、例えばインストールなどの特権作業が必要な時だけsu/sudoで一時的な権限昇格が可能ですし、/etc/pam.dで誰がどのユーザにスイッチ出来るかなどは細かく制御できます。 一方で、クラウドの権限管理は悩みの種で、誤操作が怖いので普段はRead Onlyの権限にしておきたいのですが、手軽に権限を昇格する方法がありません。なので、別の管理者ユーザを作って、そちらでログインしなおしたり、それを半自動化するCyberArkやBeyondTrustといったPAM系ソリューション、あるいは最近流行りのCIEM(PAM機能を持つもの)を導入する必要がありました。 Azureでは結構以前からPIM(Privileged Identity Management)がネイティブで組込まれており非
【ソフトウェア設計】モジュールになぜ分けるのか？
はじめに 最近、APoSD(A Philosophy of Software Design)を読んで、ソフトウェア設計に関して色々思う事が出来たというか、整理してみたくなったので、記事にまとめてみました。なお、APoSDの言葉を多用はしていますが解説記事という分けでは無く、自分の考え方の言語化にしっくり来たので使わせてもらってるという感じです。 TL;DR モジュールとは関数/クラス/サービスなどの何等かの機能のまとまり 良いモジュールは複雑性を隠蔽する 複雑性を隠蔽しないモジュールの価値は低い モジュールとは？ プログラムは正しく動くことがまず何より大事ですが、その次というかほぼ同じくらい大事な事が読みやすく拡張しやすいことですよね？ コードは圧倒的に読みものなので、どう読みやすく、つまり理解しやすい状態にしておくかは重要な事です。APoSDでは複雑性が低いコード、という言い方をしていま
はじめに ChatGPTの肝になる機能の一つが Function Calling です。これはLLMで質問の内容を解析して、必要な関数を呼び出すというものです。 「必要な関数」 をどのように判定しているかといえば、それは関数の説明文から判断します。今までもキーワードに応じて何かの処理をするようなプログラムは良くあったと思いますが、LLMの強力な言語処理能力を使うことで 「呼び出すべき関数」 と 「適切な引数」 を自動的に判定してくれます。SiriやAlexaみたいなツールが簡単に作れちゃいます。 今回はそのFunction callingをLangChain経由で使って天気予報APIをAITuberの「紅月れん」から呼べるようにしたので、その試行錯誤等を載せておきたいと思います。 なお、AITuber自体の作り方やLLMに関する全般的な話は下記の記事で取り扱っていますので、良ければ読んでみ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ユニットテストってもう言わない！ CI/CD時代のテスト分類に最適なテストサイズという考え方
クラウドでもsuが出来る! GCPにPAM(特権管理)がついに登場
LangChainとFunction callingで天気予報APIを呼び出す