まえがき 再帰SQLを使うと、テーブルに一時的に名前を付けることで、再帰処理(ループ)を実現できます。どのように実行されるのか難しかったため図解してみます。 with句 メインクエリの中で同じサブクエリを何度も呼び出している場合に使われるのがwith句です。with句を使うとサブクエリに名前をつけることができるので、メインクエリから何度でも呼び出すことができます。便宜上、with句によって作られる一時テーブルをwithテーブルと呼ぶことにします。with句を利用したクエリは、以下のように評価が進みます。 with句を評価し、withテーブルを作成する メインクエリを実行する。 まずは簡単な例でwith句の使い方を見てみましょう。営業マンたちの月別売上を表す営業成績テーブルを考えます。 【営業成績テーブル】 名前 月 月次売上

このエントリは、GMSアドベントカレンダー2日目のものです。 昨日は、Hiroshi OdaさんのAWSでドキュメントサイトを最速で公開する方法。自動デプロイもあるよ！でした。 Node.jsで最も使われているフレームワーク「Express」。職場ではExpressを用いて開発しているのですが、自分にとってExpress内部が完全にブラックボックス化していました。こりゃまずい。ということで、Expressをソースコードから理解してみた際のまとめ記事です。 Expressは最小限で柔軟なアプリケーションフレームワークと言われていることもあり、他のフレームワークと比べてフレームワークの内部挙動を把握しやすいと思います。そのため、Expressを知らない、Node.jsを知らないという方でも、参考になるかと。 この記事を読破すると達成できること 天才が作った人気OSSアプリケーションフレームワー

背景 Kubernetes環境でGitOpsを導入するにあたり、Secretの扱いをどうするか、という課題に直面しました。 GitOpsでは、KubernetesのマニフェストファイルはGitで管理するので、工夫しないとSecretをそのままコミットすることになってしまいます。 Secretの値はbase64でエンコードされているだけなので、簡単にデコードできてしまうため、そのままコミットすることは好ましくありません。 そこで対応方法を調査した結果、SealedSecretというものを見つけ検証したので、本番環境でも有用な使い方をまとめることにしました。 準備 kubesealのインストール まず最初に、kubesealをインストールする必要があります。 手順は以下のリンクに載っているので、ぜひご覧ください。 sealed-secrets - releases ここでは、Macでの手順をご

背景・動機 IntelliJで開発するとき、依存ライブラリ(External Libraries)を手元に用意しておかないとジャンプとか補完とか便利機能が効かなくなる。シームレスにOSSの中まで覗きたいのに。 ただnpmならProject（intellijのProjectのこと。大体Gitのリポジトリ単位）のディレクトリ以下にしか影響を及ぼさないので問題ないのだが、 pythonのpipのデフォだと、全Projectから参照可能なinstallをするため、純粋な依存関係が見えにくくなる。 Project毎にpip installして、lib置き場がごちゃ混ぜに汚れるのはちょっと......（潔癖症） というわけで、IntelliJのinterpreterをDockerに繋ぐことで、コンテナ内のExternal Libraryを参照させてみた1。 方法 PyCharmでの開発でDockerを

protocol buffers のバイナリを眺めてみる protocol buffers を利用することで色々いい感じになります 複雑なことの必要がなく、簡単に利用することができます ですが、高速なシリアライゼーションの恩恵を受ける上で、protobuf のバイナリを1度眺めておくことで、効率的なモデルの設計ができるようになるかもしれません こちらの資料を参考にしています https://developers.google.com/protocol-buffers/docs/encoding swift-protobuf を使っています 検証に利用したコードはこちら protocol buffers の使い方 proto ファイルでスキーマを定義します syntax = "proto3"; message SearchRequest { string query = 1; int32 p

公式サイト https://protobuf.dev/ ふんわりとなんかセットしていなければデフォルトの0とかStringの空になったりするという知識しかなくて、そんなに詳しくないので、詳しくなりたい記事です。誤りがあれば教えて下さい。 そもそもoptionalとは Protobuf v3.15から使えるlabelのようです。 v3.0でoptionalは消えたけど、 v3.15でoptionalが復活していて、これが推奨されているっぽいです。 https://matsudamper.hatenablog.com/entry/2022/08/22/202726 https://qiita.com/disc99/items/a8ac2a264f322bc6d6e5 Optionalについてのproto3の公式説明 2つのどちらかの状態になる。 値がセットされていれば、明示的にセットされている

はじめに Protocol Buffersでは、Enumを宣言してGoのコードを生成すると、基本的には string ↔ int32 の対応関係が生成される。しかし、この string に使える文字種は、Specificationによると、 [A-Za-z_] の範囲に限られる。そのため、これ以外の文字種を使いたい場合は、他の方法で表現する必要がある1。 変換ロジックを外部に置くことも出来るが、その場合は各言語で実装することになるため、対応関係に差異が生じる危険性がある。そこで、オプショナルな値をProtocol Buffers側で宣言し、各実装でオプションの値を取得する方法を本記事では紹介する。 実際の例を考える 具体例が理解の助けになると思うので、色を表すEnum定義と、定義に該当するカラーコードを持たせる例について考える。本記事で利用するコードはリポジトリで公開しているので、必要に応

Kubernetesの監視 クラスタの状態監視、CPU・メモリなどのリソース監視、各種クエリやアクセスのチェックなど、要点を挙げればキリのない分野なので、使用するツールによって作業の難易度が大きく左右されてきます。 今回、Pixieを導入してみて使い心地が良かったので、布教のために機能をいくつか紹介していきます。 アクセス直後の全体像 こんな感じのダッシュボードになっています。HTTPトラフィックの可視化は見ているだけでワクワクします。 Namespaceごとのリソース監視 Podのリソース使用状況やディスクアクセスも確認できます。 HTTPのログ監視 Redisのコマンドログ・トラフィックの可視化 他にも様々な監視用のテンプレートが用意されています😀 インストール方法 Kubernetesは導入済みと仮定して、Self-hostedではなくクラウド版Pixieのインストール手順のみ共有

"Service mesh data plane vs. control plane" by Matt Klein の日本語訳microservicesenvoyistioServiceMeshLinkerd この記事はEnvoyの作者であるMatt Kleinさんの以下の記事を Service mesh data plane vs. control plane 本人の許可をえて日本語訳したものになります。 Sure! Please credit me as the original author and link to the original article. Thank you! — Matt Klein (@mattklein123) 2018年5月30日 Envoyの存在を知って以降、service meshに関して興味を持ってあれこれと調べていたのですが、まだ発展途上中の分野の

マルチクラウド展開にまつわる既成概念を覆すより データ転送では、特に長距離の場合にレイテンシ（遅延）が問題になることがありますが、現在はすべてのクラウド・プロバイダーがそれぞれの物理インフラストラクチャを互いの近くに配置（専門用語では「コロケーション」）しているため、これはさほど問題となりません。この近接性（場合によっては同一コロケーション施設内の別の部屋）は、クラウド間のレイテンシがミリ秒単位であることを意味します。それに加え、クラウド・データセンター・リージョンは世界中で増加しており、クラウド・リージョン間の距離は縮まっています。 という事で、レイテンシ(遅延)について、まとめてみてみます。 ■ Agenda レイテンシ(遅延)とスループット(帯域幅) レイテンシと TCP の動作 帯域幅遅延積(Bandwidth-Delay Product) TCP Window Size の調整と

実は当初このテーブル辺りのindex数の制限はもっと高いと勘違いしていて、100index/テーブルで試そうとしていました。 検証環境 今回試験に当たっては、GCPUG Shared Spanner (スポンサーはメルペイさん)を使用させてもらいました。 自前で借りたら月7万円もするSpannerを、いつでもどこでも自由に使える検証環境です。非常に有難いですね。Spannerを試してみたいと思ったら是非ご利用ください。 テーブル定義 1. 基本テーブル 一般的には推奨されない、いわゆる列持ちテーブルです。 この基本テーブルでは、セカンダリindexはつけていないため、主キーを用いない検索は全てテーブルスキャンになります。 比較に使うindex付きのテーブルも、異なるのはindex定義のみで基本となる部分はすべてこれと同じです CREATE TABLE fighter_play_count

はじめに ChatGPT は実に様々なところで応用が拡大しています。特に膨大な情報から必要な情報を取り出すなど、これまで多くの時間を要していた作業が大幅に簡略化できることは、大きなブレークスルーになると思います。この能力を個人や組織が保持している様々な資料に対して活用するニーズも高まっているのではないでしょうか。そこで、そのようなユースケースに対応するシンプルなサンプルアプリを作成しましたので、本記事ご紹介しようと思います。 Azure OpenAI Documents Search App - Document Insight Warehouse なお、本記事ではこのアプリのセットアップの詳細については説明しませんので、そちらについては上記のリポジトリを参照して下さい。（不明点あれば気軽に Issue にあげて下さい！） アプリの概要 Azure OpenAI Documents Sea

【完全保存版】GPT を特定の目的に特化させて扱う (Fine-tuning, Prompt, Index, etc.)OpenAIChatGPTlangchainGPT-4LlamaIndex ChatGPT に代表される今日の AI ブームを牽引しているのは 大規模言語モデル（Large-scale Language Model, LLM） と言っても過言ではないでしょう。LLM とは大量のテキストデータを使ってトレーニングされた自然言語処理のモデルで、代表的なものに、GPT（OpenAI）、Llama（Meta）、PaLM（Google）があります。我々開発者は、事前学習されたこれらのモデルを使って簡単にアプリケーションを作ることができます。 LLM が遂行可能な言語的タスク LLM を使って行える言語的タスクには次のような種類があります： Classification: 感情やポジ

n番煎じ、今更ながら…。 ChatGPTは過去遊びでしか使ったことがなかったのですが、 今、超長文SQL群を改修してまして、何重にもなった副問合せと集計関数を読み解くのに疲れて…ChatGPTに手を出しました。 そして、 え！！ChatGPTやばい！！ 介護は必要だけどすぐ形にしてくれるしなんなら私より知識あるわ！！ 只今、職を失いました！！ ってなったので、この衝撃を書き残しておこうと思います。 やりたいこと 作るSQLの要件はざっくり、 dba_hist_sysstatから、physical readsなど各統計情報のvalueの増分値を取得する 統計情報種別毎・1日毎に、1ヶ月間集計 日時判別のために、dba_hist_snapshotと結合する valueには累積値が入っている。ただし、インスタンス再起動があるとリセットされる。 つまり、「累積だから」と直前のスナップショットのva

こんにちは！逆瀬川( https://twitter.com/gyakuse )です！ 今日はLangChainの使い方について書いていこうと思います。 ChatGPT API の欠点について LangChainについて書く前に、ChatGPT APIの使いづらい部分をまとめていきたいと思います。 これを考えておくと、なぜLangChainが必要であるかということがわかり、さらに今後どのような機能が搭載されうるか/されるべきかということがわかります。 ChatGPT APIを使う際の難しい部分は一般的に以下のようにまとめられます。 プロンプトの共通化や管理が面倒くさい 最近の事実をベースとした質問-応答が難しい 最大の入出力合計が4096トークン(約3000字)であるため、長い情報を持たせることがしづらい ExcelやCSV、PDF等を直接読み込ませることができない 出力の処理のチェーンの

はじめに 近年、深層学習を用いた自然言語処理技術の進展が目覚ましいです。 その中でも、GPT-3をはじめとする大規模言語モデル（LLM）には大きな可能性を感じています。 最近ですと、AI技術者以外にも大きなインパクトを与えたChatGPTが記憶に新しいでしょう。 今後もLLMの進化は止まらないと予想されており、私たちもどうやって活用するかを具体的に検討すべきフェーズに入ったのではないでしょうか。 しかし、LLMを実業務に適用するとなると、越えなければならない課題がいくつも出てきます。 今回は、以下にあげた第2・第3のハードルを越えるために役立つlangchainというライブラリをご紹介します。 第1のハードル：機密データの扱い LLMはOpenAPIのGPT-3等、モデル自体は公開されておらずWebAPIだけが提供されているというパターンが多いです。 そのため、機密データを社外に送信すると

対象となる個々のPodのIPアドレスが直接帰ってくるService DNSラウンドロビンのイメージ ロードバランシングするためのIPアドレスは不要 StatefulSetがHeadlessServiceを利用している場合、Pod名でIPアドレスを引くことができる（Kubernetesの設計的に、StatefulSet内の各Podを直接指定するのはナンセンス） セットアップ HeadlessServiceのデプロイ apiVersion: v1 kind: Service metadata: name: sample-headless spec: type: ClusterIP clusterIP: None ports: - name: "http-port" protocol: "TCP" port: 80 targetPort: 80 selector: app: sample-app

プログラミング言語が2-圏として考えられるということについてソースから訳出した。(2023.2.22) 動機 最近、chatGPTにいろいろ尋ねるのが流行っているらしい。Haskellで有名なモナドの概念がなぜ導入されたか尋ねている人を見かけて、そういやそういう記事見たことないなと思ったので適当に調べた。 一次ソース 元ネタは以下のマイナーだと思われる文献 An abstract view of programming languages Eugenio Moggi教授のあんま読まれてない方の論文 Denotational Semantics Peter D. Mosses教授のこの論文（2部あって後半の方） 邦訳があり邦訳で読んだ。 プログラミングのモナド発見の経緯 プログラミングのモナドはなんか包んだり抜き出したり見たいな感じの概念で知られてますが、プログラミングの概念をモジュール化す

前振り 全国の暗号を使うエンジニアの皆さんこんにちは。今日は暗号移行とRSA暗号の話をしたいと思います。まず暗号を利用している皆さんであればCRYPTRECの「電子政府推奨暗号リスト」のことはご存じですよね！（言い切るw） CRYPTRECから2022年7月（昨年夏）に暗号強度要件（アルゴリズム及び鍵長選択）に関する設定基準（PDF直リンク）が公開されました。この中では暗号のセキュリティ強度で各種暗号と鍵長が整理されています。セキュリティ強度はビットセキュリティと呼ばれるビットサイズ（共通鍵暗号の場合のビット長）で区分されます。暗号アルゴリズムが違ってもセキュリティ強度で比較ができるということですね。例えば現在一般的に良く使われているセキュリティ強度は112ビットセキュリティが多く、これにはデジタル署名であればRSA暗号の2048ビットやECDSAのP-224等が含まれます。今日は公開鍵暗

分析のためにSQLを使う際、window関数はとても便利です。一方でとっつきにくい考え方や、情報が少なかったりしてどうしても敬遠してしまいがちです。例を交えて簡単にまとめてみたいと思います。 window関数とは PostgreSQLの公式ドキュメントには以下のように説明があります。 A window function performs a calculation across a set of table rows that are somehow related to the current row. This is comparable to the type of calculation that can be done with an aggregate function. But unlike regular aggregate functions, use of a wind