Nakano as a Service nakanoasaservice

After Cline - あるいは語りえぬ者について語ろうとする時代について

この資料は以下のイベントの登壇用の殴り書きです

今までの資料を引用して話すので、この資料はアウトラインです。

あなたのプロジェクトに Frontend Ops を。

Full Plan: 1ヶ月 120万
- 秘密保持契約を行い、ソースコードを分析し、改善を行います
- 現在受付可能なのは、1月以降です
- 調査費用は50万~になります
Lightweight Plan: 外部計測のみ 50万
秘密保持契約抜きで外部からの監視を行います

文責 mala

経緯:

免責:

PostgreSQLなどの既存のRDBMSはスキーマを持つ。スキーマがあることは良いことだが、このスキーマのライフサイクルはアプリケーションコードのライフサイクルと乖離しがちで、結果として以下のような問題が発生する。

特に自動化をしない場合はマイグレーションをデプロイとは別に行う必要が発生する。これにより、
- シンプルに作業が面倒。
- 承認フローが追加で必要になる。または、デプロイはレビューの管理下に置かれているのにマイグレーション側が適切に管理されないなどのミスマッチが起きる。
マイグレーション忘れ、マイグレーションのリバート忘れのリスクがある。

Bicep を用いて、コードとリソースの一致を保証することは ARM Template の現在の性質ではできない。Microsoft は Deployment Stacks と呼ばれる仕組みで改善を検討している。
Bicep は、Complete modeを使うとコードとリソースが一致することがある程度保障できる。IaCとして使うなら Complete 一択。(それでもずれる)
Completeでは、最後に適用したBiepデプロイでリソースが決定されるので、Bicep スコープは狭く維持する。このため、ResourceGroup を target scopeにするのがいいだろう。Bicepを分ける = ResourceGroupをライフサイクルで分けることになる。

bicep は、ARM Template の DSLでARM Templateに変換される。あくまでDSLなので、デプロイを含めた仕様、制約はARM Template に準じる

この記事はTSG Advent Calendar 2020の14日目の記事です。昨日の記事はJP3BGYさんのPXE BootとIntel DCIを用いたLinux Debug環境でした。

カリー＝ハワード同型対応ってかっこいいけど、何のことだかよくわからない。わたくし昆布の現時点での（偏った）理解を、疑似コードを交えて説明していきます。ほぼ備忘録です。

直観主義論理（自然演繹）の命題とTypeScriptの型との間のカリー＝ハワード同型対応を考えます。

Wikipediaでは次のように書いてあります。

	/**
	* My Portable RAG
	* $ pnpm add sqlite-vec @ai-sdk/google ai
	* SQLite Vector Search + Google AI Embeddings
	*
	* Required environment variables:
	* GOOGLE_GENERATIVE_AI_API_KEY=your-api-key
	*
	* Usage:
	* # Index text content

	import { makeOperation } from '@urql/svelte'
	import { authExchange } from '@urql/exchange-auth'
	import { Auth } from 'aws-amplify'
	import produce from 'immer'
	import { set } from 'lodash'

	const amplifyAuthExchange = authExchange({
	addAuthToOperation: ({ authState, operation }) => {
	if (!authState?.token) {
	return operation