タグ

ブックマーク / future-architect.github.io (9)

  • 2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ

    最近はお客さんとの勉強会でDockerのドキュメントをつまみいして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事Pythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

    2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
  • 個人的docker composeおすすめtips 9選 | フューチャー技術ブログ

    記事は「珠玉のアドベントカレンダー記事をリバイバル公開します」企画のために、以前Qiitaに投稿した記事を一部ブラッシュアップしたものになります。 はじめにみなさん、docker composeを利用しているでしょうか? 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 この記事ではある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用docker-composeではなく docker composeコマンドも利用可能になっています。 Docker Desktopでは v3.4.0から利用可能で、基的にはコマンドの互換性あります。 ファイル監視による自動更新docker compose 2.20.0からCompose

    個人的docker composeおすすめtips 9選 | フューチャー技術ブログ
  • Prompt Flowでプロンプト評価の管理を行う | フューチャー技術ブログ

    今回はこのような表を自動で得られるようにすることを目標とします。 LLMには、追加学習による精度の改善だけでなく、入力するプロンプトの改善による精度向上の余地があります。 今回は、通常の機械学習の実験管理とは異なり、LLM, プロンプトの2変数のうち、LLMを固定します。仮に精度が向上した場合、それが「LLMを改善したから」なのか「プロンプトを改善したから」なのかが分からなくなってしまうからです。 プロンプトの評価プロンプトの評価に必要なもの以下の4つが全て揃えば大体どんな評価もできます。 最低限*印の項目があればそれなりの評価ができます。 質問文* LLMの回答* 理想の回答 コンテキスト プロンプトの評価指標例プロンプトの評価指標は、原則「プロジェクト・タスクによりけり」です。 ここでは評価指標を定めるための参考として、いくつか事例を集めたので以下にご紹介します。 事例(1): Pro

    Prompt Flowでプロンプト評価の管理を行う | フューチャー技術ブログ
  • gRPCがフロントエンド通信の第一の選択肢になる時代がやってきたかも? | フューチャー技術ブログ

    Go 1.19が8/2に早々にリリースされました。個人的にはGo 1.19よりも楽しみだったのが、サービス間通信とIDL(インタフェース記述言語)連載の中でご紹介したgRPCGo実装の新星、Connectのアップデートでした。そしてそれはやってきました。 詳しい内容は↑の記事を見ていただくとして、Connectがその開発元ブログの紹介記事で宣言していたのが次の2つのことでした。 Go 1.19が出たらconnect-goは1.0にして以後後方互換性を守るよ connect-webを出すよ 前者はまだ0.3だったのですが、connect-webはリリースされました。歴史のあるフロントエンドのコードジェネレータはTypeScript対応が後付けだったりするのですが、TypeScriptがファーストシチズンかつ、ネイティブというコードジェネレータなので、開発はかなりやりやすくなることが期待され

    gRPCがフロントエンド通信の第一の選択肢になる時代がやってきたかも? | フューチャー技術ブログ
  • SQLBoiler(とoapi-codegen)でつくるREST APIサーバ | フューチャー技術ブログ

    ライブリッツの筒井です。 GoのORマッパー連載、折り返して5日目です。 SQLBoilerを使用したDBスキーマ駆動なREST APIサーバの開発ワークフローを紹介します。 なぜSQLBoilerを選ぶのか?自分たちのチームでは、REST APIサーバを開発する際にはまずデータベースのテーブル設計から始めることが多いです。その次にAPI定義の設計へ入るのですが、既にテーブル定義は出来上がっているため、なんとなくSQL文が頭に思い浮かんだ状態でAPIのRequest / Responseを考えることになります。 ゆえにO/Rマッパに一番に求めるのは、「いかにストレスなく思い描いていたSQL文を実行し、Goの文脈に持ち込めるか」ということです。 この基準を元に、次のような観点からSQLBoilerを選定しています。 複雑なSELECT文でDSLに苦悩したくない前述の通り、我々の頭の中にはなん

    SQLBoiler(とoapi-codegen)でつくるREST APIサーバ | フューチャー技術ブログ
    morioka
    morioka 2021/08/01
  • どうしてHTML5が廃止されたのか | フューチャー技術ブログ

    フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。 しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯をまとめてみます。 HTML5とはWebサイトを作るときに必ず書くことになるHTML。Webサイトのコンテンツ、つまり中身や構造を作るために使うマークアップ言語です。 そして、その最近版として10年ほど前に登場したHTML5。当時は Webニュースなどで盛んに特集が組まれていましたが、このHTML5がついこないだ、2021年1月28日に廃止されました。 広義のHTML5 / 狭義のHTML5HTML5

    どうしてHTML5が廃止されたのか | フューチャー技術ブログ
  • サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ

    Pythonでお仕事する前提で、現在のところで自分が最適と考えるチーム開発のための環境整備についてまとめてみました。今までももろもろ散発的に記事に書いたりしていたのですが、Poetryで環境を作ってみたのと、過去のもろもろの情報がまとまったものが個人的にも欲しかったのでまとめました。前提としては次の通りです。 パッケージ管理や開発環境整備でPoetryを使う 今時はコードフォーマッター、静的チェックは当たり前ですよね? コマンドでテスト実行、コードチェックとか実行とかができる(CI/CD等を考えて) VSCodeでもコマンドで実行しているのと同じコードチェックが可能(ここコンフリクトすると困る) デプロイはDockerイメージ コンテナのデプロイ環境でコンテナに割り当てられたCPU能力を比較的引き出せて、スケールさせたら線形にパフォーマンスアップできるようなasyncioを前提とした環境構

    サーバーアプリ開発環境(Python/FastAPI) | フューチャー技術ブログ
  • 続・サーバーレス検索エンジン:巨大な静的ファイルを扱うケースについて考える | フューチャー技術ブログ

    大きくは外部ストレージサービス利用と、アプリケーションにバンドルしてしまう方式と2つにわかれます。バンドルはデータだけ更新ができないデメリットはありますが、お手軽です。Lambdaはレイヤーを使えば実行プログラムに対して後から追加とかできますが、容量制限が厳しめです。 オブジェクトストレージは比較的お手軽ですが、読み込みしたいライブラリがローカルのファイルシステム前提の場合は使えません。サーバーレスの方式によっては、一度ローカルのファイルシステムに書き出してから利用とかも可能ではありますが、Cloud Runでは8GB(ただし、おそらくtmpfsで書けば書くほどメモリを消費)、Lambdaでは500MBと容量に制限があります。 より巨大な学習済みデータを扱う場合はマネージドNFSサービス系のものを使うのが最終形でしょう。ファイルのサイズ制限もほぼ限界値ですし、ローカルファイルになるのでどん

    続・サーバーレス検索エンジン:巨大な静的ファイルを扱うケースについて考える | フューチャー技術ブログ
  • DockerでRUNをまとめた方が良いとは限らない | フューチャー技術ブログ

    TIG/DXの渋川です。 ソフトウェアの世界では、ツールや言語の進歩があって、もはや古い知識になっているにも関わらず、古い知識がベストプラクティスと呼ばれて蔓延し続けている例があります。Dockerだと「RUNをまとめよう」というのがそうです。かつてはこれは常に行うべきプラクティスでしたが、現代だとそうじゃないケースもあり、デメリットもあります。 https://www.docker.com/company/newsroom/media-resources 1. ただファイルが増えるだけのケースであれば気にしなくていい次の2つのファイルで実験してみます。ベースイメージに、10MBのファイルを作成するコマンドをふたつ並べたものです。 FROM debian:bullseye-slim RUN dd if=/dev/zero of=dummy1 bs=1M count=10 RUN dd if

    DockerでRUNをまとめた方が良いとは限らない | フューチャー技術ブログ
  • 1