タグ

関連タグで絞り込む (63)

タグの絞り込みを解除

schemaに関するsh19910711のブックマーク (252)

  • Iceberg で Amazon Athena をデータウェアハウスぽく使おう

    sh19910711
    sh19910711 2024/06/22
    "Iceberg: データの編集・削除が可能 + タイムトラベル / メタデータを元にパーティション構造を把握 + より精度の高いパーティショニング / Schema Evolution: 古いスキーマとの互換性を維持しつつスキーマを変更"
    リンク

  • 契約による設計とテスト駆動開発で大きいタスクを楽にする - shallowな暮らし


    こんにちは。id:shallow1729です。先日一ヶ月ぐらいの工数のかかる大きめのタスクを担当しました。そのタスクは機能に関連するテーブルやエラーになる条件が多く、初めはどこから手をつけたらいいか分からない状態でした。今回紹介する契約による設計とテスト駆動開発は自分がうまくとっかかりを見つけて手を進める上ですごく役に立った開発手法です。うまく実装を進められない時とかに思い出してもらえたらと思います。 大きいタスクの難しさ これはエンジニアとしての経験則ですが、規模の大きい機能の開発はたとえそこにアルゴリズム的な困難さを伴わなくても難しいものになるように思います。 もちろん全体のアーキテクチャを考えるには設計手法の理解が必要ですし、関連するツールが増えるとそれらの理解が必要だったりするので技術的な課題に直面しやすいというのも事実だと思いますが、実際に開発をしている中でそういう技術的な課題感
    契約による設計とテスト駆動開発で大きいタスクを楽にする - shallowな暮らし
    sh19910711
    sh19910711 2024/06/21
    "契約による設計 + 擬似コードを書いて + モジュールごとに擬似コードをベースに自動テストを実装 / 設計能力が問われる仕組みについてもメインのロジックと分離して考える事ができるので筋道が立ちやすく" 2020
    リンク

  • ChatGPTとPydanticでかんたん契約書解析 - MNTSQ Techブログ


    こんにちは、MNTSQでアルゴリズムエンジニアとチームマネージャーをやっている平田です。 MNTSQでは自然言語処理を使って契約書を解析したり検索したりする機能を開発しています。 契約書解析には、次のようなタスクがあります。 秘密保持契約等の契約類型に分類 契約締結日や契約当事者等の基本情報を抽出 条項︵第1条, 第2条, ...︶単位で分解 本稿では、これらの契約書解析タスクをGPT-4oに解かせてどんな結果になるか見てみます。 ざっくりやり方 GPT-4oのAPIを呼び出すところ ここではAzure OpenAIのGPT-4oを使います。Microsoftのサンプルコードほぼそのままですが、一応貼り付けておきます。 from openai import AzureOpenAI client = AzureOpenAI( api_version="2023-05-15", azure_e
    ChatGPTとPydanticでかんたん契約書解析 - MNTSQ Techブログ
    sh19910711
    sh19910711 2024/06/21
    "契約書解析: 秘密保持契約等の契約類型に分類 + 約締結日や契約当事者等の基本情報を抽出 + 条項（第1条, 第2条, ...）単位で分解 / GPT-4oの出力からJSON文字列を抽出し、Pydanticのデータモデルでバリデーション"
    リンク

  • Great Expectations（GE） によるノートブック型環境（Databricks）でのデータ品質保証方法のまとめ - Qiita


    Great Expectations︵GE︶ によるノートブック型環境︵Databricks︶でのデータ品質保証方法のまとめPythonSparkデータ分析DatabricksGreatExpectations 概要 本記事にて、Great Expectations︵GE︶ によるノートブック型環境︵Databricks︶でのデータ品質保証方法を共有する。GEがツールの概要を提示した上で、コードとその実行結果を提示する。 実行コードとその出力結果を Github に配置してあり、次のリンクで確認が可能。 Great Expectations とは Great Expectations (GE) とは、データに対する検証、ドキュメント化、および、プロファイリングにより、データ品質の保証と改善を支援する OSS の Python ライブラリである。データに対する品質保証条件︵GEではEx
    Great Expectations（GE） によるノートブック型環境（Databricks）でのデータ品質保証方法のまとめ - Qiita
    sh19910711
    sh19910711 2024/06/20
    "Great Expectations: 生成されるドキュメントは、下記の項目が表示される HTML ファイル + 静的サイトとしてホストすることができる / spark データフレームでも実行できる + パフォーマンスに課題" 2022
    リンク

  • JSONのSpecをしっかり書く - Qiita


    はじめに APIの仕様をSwagger/OpenAPIで書くケースは増えてきました。これはAPI提供側と利用側の取り決めなので、これさえしっかり書いてメンテしていけば、独立して開発できるようになります。 というのはいささか理想が過ぎるようにも思えます。というのもSwagger/OpenAPIでは仕様、特にやりとりするJSONのデータの仕様を書ききるのは難しいためです。一応型としてきっちり定義できるように、スキーマ定義の部分は仕様が膨らんできていますが、その延長線上にはそれこそメンテ不可能な、過去人類が通ったスペックモンスターの規格を生み出してしまわれそうです。 もう少し上手いやり方は無いものでしょうか?そこでJSON Specというものを作ってみました。どんなAPIでもサーバサイドでは、受け取るパラメータやJSONのバリデーションはしっかり書くはずです。これを利用して、APIのテストにも
    JSONのSpecをしっかり書く - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Swagger/OpenAPIでは仕様、特にやりとりするJSONのデータの仕様を書ききるのは難しい / それこそメンテ不可能な、過去人類が通ったスペックモンスターの規格を生み出してしまわれそう" 2019
    リンク

  • OpenAPI Generatorで自分好みのpythonクライアントライブラリを生成する方法 - Qiita


    自己紹介 yuji38kwmt 名古屋のAIの会社でAIやってないエンジニア WebAPIをどう実行していますか？ curlコマンドですか？ curlコマンドはつらくないですか？ pythonで実行したくないですか？ WebAPIをPythonでどう実行していますか？ APIドキュメントを見ながら、自分で実装していますか？ 似たようなコードがたくさんあって、飽きませんか？面倒でないですか？ あなたが実行したいWebAPIは何で定義されていますか？ OpenAPI Specification︵OAS︶ですか？ OASで定義されているなら、あなたは幸せです。なぜならOASからソースを自動生成できるツールがあるからです。 OpenAPI Specification︵OAS︶とは？ REST APIを記述するための言語です。 以下、﹁OAS﹂と略します。 The OpenAPI Specifica
    OpenAPI Generatorで自分好みのpythonクライアントライブラリを生成する方法 - Qiita
    sh19910711
    sh19910711 2024/06/18
    "openapi-generator-cli: pythonファイルだけでなく、ドキュメントやテストコード、設定ファイルなど、ライブラリに必要なファイル一式が生成 / mustache記法で記載されたテンプレートファイルを修正して、カスタマイズでき" 2019
    リンク

  • Responderでスキーマ駆動開発: Swagger UIの表示までやってみる - Qiita


    スキーマ駆動開発とは 簡単に言うと、先にAPIのスキーマ (request, responseの型やフィールド名の定義)を決め、それに伴ったドキュメントとモックの生成をシステマティックに行った上で内部の実装を行う開発手法です。(参考: チームのWeb API開発を最適化するSchema Driven Developmentの解説＆実装例) pythonのwebフレームワークであるresponderでスキーマ駆動開発をやってみたいと思います。 以下の様なSwaggerが見れるようになるのがゴールです。 responder PythonのモダンなWeb フレームワークです。 ボリューム感的にはflaskやbottleのようなマイクロフレームワークです。 以下の様に書いて、$ python xxx.py のように実行するだけで、JSONを返すAPI serverが起動します。 import re
    Responderでスキーマ駆動開発: Swagger UIの表示までやってみる - Qiita
    sh19910711
    sh19910711 2024/06/18
    "ドキュメントとモックの生成をシステマティックに行った上で内部の実装を行う / responder: ボリューム感的にはflaskやbottleのようなマイクロフレームワーク + GraphQL、OpenAPI schemaの自動生成などモダンな機能を備え" 2019
    リンク

  • OpenAPI3 + OpenAPI generator でgolangサーバ・TypeScriptクライアントの実装を試す - Qiita

    OpenAPI3 + OpenAPI generator でgolangサーバ・TypeScriptクライアントの実装を試すGoTypeScriptswaggerOpenAPIOpenAPIGenerator 昨今のマイクロサービス化の流れに伴い、サービス間の情報のやり取りのルールをスキーマとして定義してクライアント、サーバーの開発を行うスキーマ駆動開発が取りた出されている。 今回はOpenAPI3(旧Swagger)をスキーマ駆動開発のツールの一つとして取り上げたが、意外と踏み込んだHello Worldの記事が少なかったので書いた。 対象読者 最近swaggerやOpenAPIという言葉を聞いて試してみたいが導入に悩んでいる人 普段からAPIを使用した開発を行っているがOpenAPIを使ったことがない人 Dockerや特定プログラミングをある程度まで習熟している人 OpenAPIとは

    OpenAPI3 + OpenAPI generator でgolangサーバ・TypeScriptクライアントの実装を試す - Qiita
    sh19910711
    sh19910711 2024/06/18
    "コードジェネレータがなければ、究極的にはスキーマはただのドキュメントと何も変わらない / 内部利用向けのAPIの定義に使うかと聞かれると微妙 / コードジェネレータの質が言語によってまちまち" 2020
    リンク

  • ぼくがかんがえたさいきょうのRails API開発環境 - Qiita


    今やっているバイトでRails APIを作成しています。 APIを作成する際に、以下のような問題点が出てきました。 APIのdocumentがないとフロントエンドの開発者が開発しづらい documentを書くのにopenapiを採用するが、文法を覚えるのに一苦労するし、見づらいので書き忘れが生じる。 API responseの構造に開発者間で違いが出てしまう。 実際のAPIとdocumentの挙動が違うのに修正を忘れてしまう 結論 結論から言うと、これらの問題を解決するために以下のようにしました。 APIのPRを出す時にopenapiでdocumentを書く。 SpotlightStudioを使ってopenapiを書く。 responseの形はJsonAPIに従い、gemにfastjsonapiを導入する。 committeeというgemを使って実際の挙動とopenapiに書かれていること
    ぼくがかんがえたさいきょうのRails API開発環境 - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Spotlight Studioを使ってOpenAPIを書く / 文法を覚える必要がありませんし、タイポしてエラーが出ることもありません / APIのresponseの形にもルールがないと、フロントエンド側で取り扱いが難しく" 2020
    リンク

  • swagger-php で書く Annotation テンプレ3種 - Qiita

    この記事は、温かみのある手作業で swagger-php の annotation を書かなければいけない人向けに、コピペで使えるannotationを提供する目的でまとめます。 単なる key value 表現のannotation 出力例 { "id": "1", "name": "サンプル太郎", "email": "example@hoge.com", "created_at": "2006-04-13T14:12:53+09:00" } /** * @OA\Get( * tags={"Common"}, * path="/api/user", * @OA\Response( * response="200", * description="success", * @OA\JsonContent(ref="#/components/schemas/user_responder")

    swagger-php で書く Annotation テンプレ3種 - Qiita
    sh19910711
    sh19910711 2024/06/18
    "温かみのある手作業で swagger-php の annotation を書かなければいけない / tags は swagger-ui で見るときに整理されて見えるので便利 / 慣れてしまうとパターンも少ないので案外サクサクかけます" 2020
    リンク

  • PythonのWebフレームワーク「FastAPI」とTypeScript・OpenAPIで、型つきでWebアプリを作ってみる - 機械学習WebAppのための技術スタック - Qiita

    PythonのWebフレームワーク「FastAPI」とTypeScript・OpenAPIで、型つきでWebアプリを作ってみる - 機械学習WebAppのための技術スタックPythonTypeScriptMachineLearningOpenAPIFastAPI Intro Pythonで実装した機械学習や画像処理をバックエンドにしたWebアプリをサクッと作るための技術スタックとして、FastAPI+TypeScript+OpenAPIを紹介します。 モチベーション PythonでサクッとWebサーバ（APIサーバ）を立てたい 今まではFlaskを使ってたような用途 「Pythonで」 機械学習・画像処理のサービスなので 「サクッと」 バリデーションとか楽したい サーバ、クライアント共に型の保証が欲しい 機械学習や画像処理のアプリはパラメータが多くなりがち・一貫した慣習が無いのでミスしやす

    PythonのWebフレームワーク「FastAPI」とTypeScript・OpenAPIで、型つきでWebアプリを作ってみる - 機械学習WebAppのための技術スタック - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Pydanticによるスキーマ定義 + FastAPIでのサーバサイドの定義から、OpenAPIを経由してフロントエンドライブラリを生成 / 生成先言語としてTypeScriptを使う。サーバサイドと一致した型定義を利用" 2020
    リンク

  • LoopBack4の概要 & Examples validation-appを動かしてみる - Qiita


    Node.js TypeScript/ES2017で実装された主にAPI向けのWEBフレームワークです。 IBMが買収したStrongLoopの開発しているOSSで、MITライセンスで公開されています。 TypeScriptのDecorator(アノテーション)でDependency Injectionの定義を行ったり、Modelのプロパティに付与することでOpenAPIのドキュメントを生成することが可能です。 self-hostedのREST API Explorerがあり、Modelを書いたらすぐに参照できるので、コードとドキュメントが必ず一致します。 また、CLIが用意されており、基本的なコードを生成したり、Exampleをインストールすることが可能です。 https://loopback.io/index.html https://github.com/strongloop/loo
    LoopBack4の概要 & Examples validation-appを動かしてみる - Qiita
    sh19910711
    sh19910711 2024/06/18
    "LoopBack4: IBMが買収したStrongLoopの開発 + TypeScript/ES2017で実装された主にAPI向けのWEBフレームワーク / Modelのプロパティに付与することでOpenAPIのドキュメントを生成" 2020
    リンク

  • GraphQL Meshを使ってみる - Qiita


    この記事は、Ateam LifeDesign Advent Calendar 2022 カレンダー1の4日目の記事です。 はじめに GraphQLは今や、フロントエンドからデータフェッチする手段として用いられるメジャーな技術です。 今回はバックエンドとしてのGraphQLサーバーだけでなく、gRPCやREST APIなどもGraphQLのクエリを使ってリクエストできるかつ、それらの複数のAPIをまとめて1つのGraphQLサーバーとして利用できるようにするための技術であるGraphQL Meshについて紹介します。 複数のバックエンドAPIに対し、1つのGraphQLサーバーを構築しようとすると、APIの仕様を読み良き、スキーマやリゾルバを作成して、など多くの工数が必要となりメンテナンスも大変になってきます。 ここで紹介するGraphQL Meshを使うことでそれらの問題を解消し、複数サー
    GraphQL Meshを使ってみる - Qiita
    sh19910711
    sh19910711 2024/06/18
    "REST APIとしてSwagger Petstore、GraphQL APIとしてSpaceX / .meshrc.yamlという名前のファイルを作成し、そこにそれぞれのAPIについての設定を記述 / REST APIの定義のdescriptionを読み取って反映され" 2022
    リンク

  • Django + Strawberryで作るGraphQLサーバ - Qiita


    この記事はDjango Advent Calendar 202210日目の記事です。 はじめに 今年は仕事が変わったのもあって、Djangoに触る機会が減りました。全くDjangoを触らなくなったのではなく、細々と自分のサイトで使っているのですが、Django + StrawberryでGraphQLサーバを作ると楽だぞという話をします。 PythonのGraphQL事情 PythonのGraphQLと言えばGrapheneが有名です。Graphene-Djangoも触ってみて良い感触でしたが、開発が活発ではなくDjango 4.0の対応が遅れていたため(今は対応しています)、一時期はDead Project?というIssueが立つほどでした。 そこで代わりに見つけたのがStrawberryです。Strawberryの特徴 Python 3.7から採用されたデータクラス(datacla
    Django + Strawberryで作るGraphQLサーバ - Qiita
    sh19910711
    sh19910711 2024/06/18
    "PythonのGraphQLと言えばGrapheneが有名 / Strawberry: Python 3.7から採用されたデータクラス(dataclasses)にインスパイア / GraphiQL UIを内蔵していて、簡単に動作確認ができます" 2022
    リンク

  • GraphQL Ruby でクエリの複雑度をレスポンスヘッダで応答する - Qiita


    概要 GraphQLでクエリをしたときにそのクエリの複雑度がどの程度だったのかを把握したくなることがあります。 この問題を解決する手段として複雑度をHTTPレスポンスヘッダで応答できるようにしてみます。 このAPIデザインがどの程度一般的なのかはちゃんとわかっていないのですが、Contentful の GraphQL Content API にはレスポンスヘッダで複雑度を応答するデザインが含まれていましたので特別に異常なことではないでしょう。 コード 複雑度の計算をするアナライザとして GraphQL::Analysis::AST::QueryComplexityが標準で提供されていますので、これを継承してアナライザーを実装します。OverseQueryComplexityComplexityAnalyzer をクラスを作り、#result メソッドをオーバーライドし 、ここではGra
    GraphQL Ruby でクエリの複雑度をレスポンスヘッダで応答する - Qiita
    sh19910711
    sh19910711 2024/06/18
    "GraphQLでクエリをしたときにそのクエリの複雑度がどの程度だったのかを把握したくなる / Contentful の GraphQL Content API にはレスポンスヘッダで複雑度を応答するデザインが含まれ" 2022
    リンク

  • GraphQLを活用したスキーマ駆動開発を体験した話 - Qiita


    概要 会社でGraphQLを導入するにあたり、スキーマ駆動開発を取りいれた開発を行ってみました。 実際にどのような開発を行ったのか、またやってみてどうだったかをご紹介できればと思います。 一度下記LTにて紹介した内容について少し加筆や修正を行った記事になります。 GraphQLにおけるスキーマ駆動開発 GraphQLを導入する利点の1つとして﹁スキーマ駆動﹂が実現できることがあります。 スキーマ駆動開発についてはこちらのqsonaさんの資料が詳しいです。 GraphQLを構築する方法として、コードファーストとスキーマファーストの2つのアプローチがあります。 コードファーストは、APIのスキーマをGraphQLのコードで定義してスキーマを生成する方法です。スキーマを定義するために、GraphQLの型を定義し、それらの型を組み合わせて、クエリを定義します。 スキーマファーストは、APIのスキー
    GraphQLを活用したスキーマ駆動開発を体験した話 - Qiita
    sh19910711
    sh19910711 2024/06/18
    "バックエンド側のAPIの実装が終わるまでフロントエンドの手が空いてしまったりと「実装待ち」のような時間が少し発生 / スキーマ駆動開発を導入した結果としてその時間が減った" 2022
    リンク

  • pureなjsでGraphQLのrequestを投げる方法（Lambda@Edgeなど） - Qiita


    Lambda@EdgeからとあるエンドポイントにGraphQLのqueryを実行したい場合がありました。 Lambda@Edgeにはレイヤーをアタッチすることができないので、Lambdaのランタイムに組み込まれている方法でhttpリクエストを飛ばす必要があります。 ︵正確にはコードとライブラリをまとめたzipが1MB以下に収まるのであれば、そのzipをデプロイすることでサードパーティのNodeライブラリも利用することができるようになりますが、実装時点では調査が足らず不可能だと思っていました。詳しくは下のリンクをご参照ください。︶ 今回はとある事情から、ランタイムとしてNode.jsのv16系を利用していました。 Nodeのhttpクライアントライブラリとしてはaxiosやnode-fetchなどがよく使われますが、Node16にこれらは組み込まれていません。 Node.jsのv18系を使え
    pureなjsでGraphQLのrequestを投げる方法（Lambda@Edgeなど） - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Lambda@EdgeからとあるエンドポイントにGraphQLのqueryを実行したい / ランタイムに組み込まれている方法でhttpリクエストを飛ばす必要があり / GraphQLのquery実行の方法が分かりづらかった" 2022
    リンク

  • 【フロントエンド】GraphQLを導入する時はFragmentを理解しよう - Qiita


    はじめに GraphQLを用いたフロントエンド開発は多くなってきているように思います。 フロントエンドから柔軟にデータを取ってくることができるということは、今までバックエンドが担保してきていた部分をフロントエンドが担わないといけなくなった ということを意味します。 保守性をちゃんと考えないといけない。 ということですね。 今回は、Fragmentについての話 Fragmentとは？ GraphQLにおけるFragmentとは複雑なクエリを小さくまとめ上げるために生み出されました。 これはとてもComponentの概念に似ていますね。 僕たちはComponentという小さな単位に分割し、それを組み合わせることで複雑なアプリケーションを構築しています。 これと同じです。 データをFragmentという小さな単位に分割し、複雑なクエリを役割ごとに分割してやろう。 という話です。 どうやって実現す
    【フロントエンド】GraphQLを導入する時はFragmentを理解しよう - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Fragment: 複雑なクエリを小さくまとめ上げる / 親のクエリで子のfragmentを呼び出し + データをFragmentという小さな単位に分割し、複雑なクエリを役割ごとに分割 / 共通化: 保守性を上げる時もあれば、下げる時もあります" 2022
    リンク

  • MSWを用いたStorybook・テスト上で使うGraphQLモックサーバーの運用 - Qiita

    Storybook上でコンポーネントの挙動をみたいけど、データ取得に失敗した際の挙動は確認できない。。。みたいな悩みはありませんか？私はあります。 今回はGraphQLを用いたデータ取得を行うコンポーネントに対して、mswを用いることによってデータ取得の結果に応じたコンポーネントの振る舞いをStorybook上やテスト上で確認出来るようにあれこれする内容になっています。 GraphQLのアドカレというよりStorybookのアドカレかもしれない 概要 本記事では以下の内容を取り扱います。 MSWを用いたGraphQLのモックサーバーの運用 StorybookとMSWを組み合わせたコンポーネントのカタログ化 テスト上でのモックサーバーの運用 Query・Mutationのモックを出来るようにし、実際にStorybookやテスト上でモックすることでどういったことが出来るようになるのかという内容

    MSWを用いたStorybook・テスト上で使うGraphQLモックサーバーの運用 - Qiita
    sh19910711
    sh19910711 2024/06/18
    "MSWを用いたGraphQLのモックサーバーの運用 / StorybookとMSWを組み合わせたコンポーネントのカタログ化 / mswを用いることによってデータ取得の結果に応じたコンポーネントの振る舞いをStorybook上やテスト上で確認" 2022
    リンク

  • SupabaseのGraphQL機能を使ってNext.jsで簡単なアプリを作ってみる - Qiita


    どうも、SupabaseでDevRelをしているタイラーです！ SupabaseはPostgreSQLをフル活用したBaaSで、バックエンドを1から構築しなくてもサクッとPostgreSQLを使ってアプリを構築できるサービスです。基本的には各種クライアントライブラリーを介してSupabaseに用意されたエンドポイントをコールしてデータを読み書きする形になるのですが、実はSupabaseはpg_graphqlというPostgreSQLの拡張機能開発していて、それを通じてGraphQLの機能も提供しています。Supabaseが提供しているGraphQLエンドポイントはSupabaseのRLSも使えて、セキュアなアプリが簡単に作れます。 そんなpg_graphqlのv1.0が最近リリースされたこともあって今回はせっかくなのでGraphQLを使って簡単なアプリケーションを作ってみようかなと思いまし
    SupabaseのGraphQL機能を使ってNext.jsで簡単なアプリを作ってみる - Qiita
    sh19910711
    sh19910711 2024/06/18
    "Supabase: サクッとPostgreSQLを使ってアプリを構築できるサービス / Supabaseはpg_graphqlというPostgreSQLの拡張機能開発していて、それを通じてGraphQLの機能も提供" 2023
    リンク
  • 1 2 3 4 5 6 7 8 9 10 次のページ

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.