タグ

ブックマーク / qiita.com (803)

  • AWS Lambda:API GatewayとApplication Load Balancerの違い - Qiita

    AWS Lambdaを使ってサーバーレスでWeb APIを作る場合、Lambdaの呼び出し元としてAPI Gateway (API GW) もしくはApplication Load Balancer (ALB) のどちらかを選択することになる。この選択基準となる両者の違いを整理した。 API Gateway特有の機能 当然ながら、ALBではAPI Gatewayのリクエスト検証、データマッピング、アクセス制御、SDK生成といった機能は使えない。 プロトコル・ポート番号 API GWは443番でのHTTPS (TLS 1.2) のみをサポートする。(VPC Endpoint経由での呼び出しはできるが、この場合でもHTTPSのみとなる。) ALBは任意のポート番号でのHTTP/HTTPS(TLSバージョンも選択肢がある)をサポートする。 実行可能時間(タイムアウト時間) API GWは最長29

    AWS Lambda:API GatewayとApplication Load Balancerの違い - Qiita
  • LambdaのオーソライザーでBASIC認証を追加する【言語不問】 - Qiita

    前回作成したサーバーレスLaravelですが、BASIC認証を付与しようとしたら躓きました。 API Gatewayを経由すると、WWW-Authenticateヘッダーがx-amazn-remapped-www-authenticateに置き換えらます。その結果BASIC認証を求めるポップを表示できず無条件で401 Unauthorizedエラーだけを表示するWEBになります。 つまり問題はLambdaではなく、API Gatewayです。ALBでURLを設定すればこの問題はありません。ALB経由のLambdaを使ったサーバーレスLaravelのBASIC認証は通常のLaravelと同じです。53eda06 API Gateway経由でもBASIC認証を導入するには以下のように変更します。 別途新規のLambda関数を作成し、API Gateway上にオーソライザーとして登録する。 オー

    LambdaのオーソライザーでBASIC認証を追加する【言語不問】 - Qiita
  • 要件定義|3分で読める非機能要件について - Qiita

    はじめに エンジニアのみなさま、日々の学習当にお疲れ様です! また記事まで足を運んでいただき当に感謝です。 約3分程度で読めるので最後まで読んでもらえると幸いです。 要件定義関連の記事の投稿をしました。時間あればぜひ読んでみてください。 今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。 非機能要件|6項目について 1. 可用性 システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており

    要件定義|3分で読める非機能要件について - Qiita
  • UIコンポーネントの大きさは外から制御しよう - Qiita

    昨今のフロントエンド向けUIライブラリでは、コンポーネントの設計が重要です。この記事では、コンポーネントのスタイリング、その中でもとくにコンポーネントの大きさに関わるコンポーネント設計について考えます。 私の考える結論は、むやみに大きさを指定できるpropを生やさずに、CSSで外から大きさを制御できるようにしたほうがいいです。 コンポーネントの大きさを制御したい UIの一部分を再利用可能なコンポーネントとする場合、同じコンポーネントがさまざまな場面で使えるのが望ましいでしょう。コンポーネントが提供する機能にもよりますが、場面に応じてさまざまな大きさでコンポーネントを使用できたほうがよいこともあります。 具体例として、このようなコンポーネントを考えてみましょう。例はReactで示しますが、この記事の内容はReactとは関係ありません。 const Card: React.FC<React.P

    UIコンポーネントの大きさは外から制御しよう - Qiita
  • 「よーしパパ、Ollama で Llama-3-ELYZA-JP-8B 動かしちゃうぞー」 - Qiita

    はじめに こんにちは、KDDIアジャイル開発センターのはしもと(仮名)です。 エンドレス水出しコーヒーの時期になりましたね。 今回は、Ollama を使って日語に特化した大規模言語モデル Llama-3-ELYZA-JP-8B を動かす方法をご紹介します。 このモデルは、日語の処理能力が高く、比較的軽量なので、ローカル環境での実行に適しています。さあその性能は如何ほどに!!!!????はやくAIは俺から仕事を奪え。 Llama-3-ELYZA-JP-8Bとは Llama-3-ELYZA-JP-8Bは、ELYZA社が開発した日語に特化した大規模言語モデルです。Meta社の「Llama 3」シリーズをベースに、日語での追加学習を行っています。80億パラメータという比較的小さなモデルサイズながら、「GPT-3.5 Turbo」や「Claude 3 Haiku」、「Gemini 1.0 P

    「よーしパパ、Ollama で Llama-3-ELYZA-JP-8B 動かしちゃうぞー」 - Qiita
  • 社内Wikiを改善して、開発体験をより良くする - Qiita

    はじめに ◆この記事は何? 社内Wikiの改善方法について紹介する記事です。 ◆この記事のねらい 社内Wikiを改善することで、チームの生産性や品質を向上させ、開発体験をより良くするのがねらいです。 先に結論 「ルール」ではなく「ポリシー」を設ける 「Working集」と「アーカイブ集」をつくる ページごとに目的を書く 大切な思考法 「中途半端なドキュメントは中途半端な文化を生む」 「誰でもできるは誰もやらなくなる」 社内Wikiのよくある課題 皆さんの社内Wikiで次のような課題を感じたことはありませんか。 情報が散乱 更新中のページがそのまま メンテナンスされていない構造 多くの人が作成・編集できる社内Wikiは、改善の意志がないと上記のような状態になりがちです。 最悪の場合、開発体験の低下につながります。 良い社内Wikiとは 良い社内Wikiの必要条件は以下の通りです。 開発体験を

    社内Wikiを改善して、開発体験をより良くする - Qiita
  • draw.io (diagrams.net) の細かいテクニック - Qiita

    みんな大好き draw.io (diagrams.net) の細かいテクニックです。 ちなみに、2020年2月あたりから、セキュリティ上の理由でサイトのドメインを diagrams.net に名称変更し始めているので、アクセス先はこちらに変更したりしましょう。 非圧縮XML形式のデフォルト化 ダイアグラムをファイル保存すると、デフォルトでは圧縮されたXMLになっていますが、これだと差分の確認・バージョン管理がしづらいです。 メニューの「拡張 (Extras)」->「圧縮 (Compressed)」のチェックを外すと非圧縮形式になるので、新しいファイルを作るたびにこれを実行しても良いのですが、忘れないように非圧縮XML形式をデフォルトにすると良いでしょう。 メニューの 拡張 (Extras) -> Configuration で開く設定ダイアログに以下を記載すると、アプリの再読み込み以降は非

    draw.io (diagrams.net) の細かいテクニック - Qiita
  • エンジニア生存戦略2024 - Qiita

    はじめに 新社会人の皆さんもそうでない皆さんもこんにちは。 この記事を読む方々は将来に漠然とした不安を抱えている方かと思いますが、いかがでしょうか?わたしは抱えています。 このエントリーでは、そんな不安を払拭するための生存戦略を考えます。 考察に利用するデータは政府が公開している信用できるデータを利用していますが、わたしの個人的考察については必ずしも正しいとは限りませんがそのつもりで読んでいただければと思います。 まずは情報収集 戦略を考えるには現在の状況についての情報をできるだけ多く集める必要があります。情報が足りていない状況で何かを判断するのは大変危険です。例えば最近は見かけない広告で 『フルリモート週3日出社副業で80万円収入』 といったものがありましたが、情報がなければ、それがどのような性質のものかを判断することもできないかと思います。 最近ではWebでググったり、ChatGPT

    エンジニア生存戦略2024 - Qiita
  • 自社データ × ChatGPTで社内AIを構築するRAG ツール|Doox β版をリリースしました - Qiita

    TLDR 社内のデータを元に質問への回答を LLM が生成する仕組み(RAG)を構築するためのサービスを開発しました。 β 版として無料で公開しているので是非使ってみてください。 サーバーレスな構成で Next.js を動かしている。技術のキャッチアップは大変だ。 背景 仕事をしていると社内の規定 / 製品情報 / 過去の履歴 .. などに関する問い合わせは日常的に発生するものだし、その工数は結構ある。通常は Wiki を作ってナレッジを共有するが、結局「近い人や担当に聞く」という行為はなかなか減らない。 色々な企業が、社内のデータを元に質問への回答を LLM が生成する仕組み(RAG)を独自に開発しているようで、技術ブログとかに書いている方も多い。 社内向け RAG の構築を SaaS プロダクトで提供したら各社の社内の問い合わせ工数と独自に RAG を構築するコストを下げられて嬉しいん

    自社データ × ChatGPTで社内AIを構築するRAG ツール|Doox β版をリリースしました - Qiita
  • 安全なAndroid OS環境を子供世代に。アプリ、サイトを適切にペアレンタルコントロールする方法。 - Qiita

    今や老若男女問わずスマートフォン(スマフォ)は生活の必需品になりつつあります。しかしながら、いきなり子供世代にスマフォを無防備に渡すことは、80歳のペーパードライバー祖父にフェラーリをプレゼントするようなものに違いありません。 私はかねてよりiOSもAndroid OSもアプリ開発等携わってきた経緯があるものの、普段使いではiOSを比較的好み子供世代にも使い古しのiPhoneを主にあてがってきました。 この記事では対応が難しいLINEアプリへの対応方法も含めて(有料アプリが必要ですが……)ご紹介して参ります。 1.iOSのペアレンタルコントロール iOSにはスクリーンタイムという標準のペアレンタルコントロール機能が付加されていて、主に次のような機能を使うことになると思います。 休止時間➡1日の使用時間制限(一括も、曜日毎も可能) App使用時間の制限➡アプリごとの使用時間制限(アプリごと、

    安全なAndroid OS環境を子供世代に。アプリ、サイトを適切にペアレンタルコントロールする方法。 - Qiita
  • RAGの実装戦略まとめ - Qiita

    それでは以下、簡単なデモを含めながら個別に説明していきます。 1. ハイブリッドサーチ こちらは、性質の異なる複数の検索方式(例えばベクトル検索とキーワード検索)を組み合わせて検索精度を向上させる手法になります。 各検索方式単体の場合に比べ、性質の異なる検索方式を組み合わせ、ある種いいとこ取りをする事で、検索性能の向上が期待できます。 今回はBM25でのキーワードベースの類似度検索と通常のベクトル検索を組み合わせていきます。 BM25について簡単に説明しておくと、文脈や文章構造は完全に無視した上で、文書内の単語を全てバラバラに分割し、文書内の各単語の出現頻度と文書間におけるレア度を加味した特徴量を算出します。 つまり、特定の文書内の各単語の数をカウントしてヒストグラムを作れば、似たような文書には同じような単語がよく出るはずなので(同じようなヒストグラムの形になるので)、類似度が高くなる性質

    RAGの実装戦略まとめ - Qiita
  • たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita

    はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう!』 『今までモック使ってたけど意外とモック使わなくても書けるね!』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 前提の話: この記事の旨は「テスト書きにくいプロダクトコードも依存関係を排除すれば楽にテスト書けるよ」なので、それ設計的にアウトでは?リファクタリング耐性低くない?みたいな話は度外視してます。

    たった2つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
  • 新規サービスの検索システム立ち上げ時に考慮すること - Qiita

    例外はたくさんあるのでこちらの表はあくまでも参考です。 バッチ更新の場合はcrontabやAirflow、Rundeckなどのワークフローエンジンが使えます。 一方、リアルタイム更新ではAWS KinesisやGCP pub/sub等を活用したり、Apache Beamなどを用いたりしてデータパイプラインを構築することがあります。 アイテムの特性と検索時のクエリ 検索対象となるアイテムの特性と検索する際にどのようなクエリが想定されるかを考えます。 全文検索エンジンを使っているので、基的にはテキストにより表現されているとは思いますが、どのようなフィールドが存在するか、テキスト以外の検索項目などを洗い出します。 クエリに関しても基は「キーワード」ですが、整理したアイテム情報に対してどのようなクエリで問い合わせが可能かを考えます。 システムとして「誰」が検索結果を取得するか、検索結果をどの程

    新規サービスの検索システム立ち上げ時に考慮すること - Qiita
  • いつか起業したいエンジニアへ - Qiita

    はじめに 34 歳のとき、勤めていた会社の経営が傾き早期退職を促されたのを契機に独立しました。その後、41 歳で Authleteオースリート 社を設立しました。諸般の事情で現在も Authlete 社の代表取締役という肩書きを持っていますが、経営者的な仕事は他の人に任せ (参照: シリコンバレーのプロフェッショナル CEO を迎えて米国市場に挑戦する日のスタートアップの話)、50 歳目前の現在もプログラマとしてコードを書き続けています。 Authlete 社設立 (2015 年 9 月) から 8 年半弱経過したものの、まだまだ小さな会社で道半ばであるため、起業家として何か語るのは時期尚早ではあるものの、軽い体調不良が長引く中、『自分のエンジニアとしてキャリアを振り返ろう!』という記事投稿キャンペーンを見かけ、生きているうちに子供世代のエンジニアの方々に何か書き残しておこうと思い、文章

    いつか起業したいエンジニアへ - Qiita
  • GPTが人知れず既存の名刺管理アプリを抹殺していた話 - Qiita

    抹殺は言い過ぎかもしれませんが簡易な名刺管理アプリであれば自作で十分という時代がきていたようです これで紙の名刺からはきっとバイバイできるでしょう! この記事執筆以降claude3 opus, GPT-4oの発表があり、ますます途中でOCRを入れる意味が薄くなったものと思われます 私もGPT-4oを早速試してみたいと思います! 名刺管理アプリ作ってほしいといわれた それは2/22のお話。 ことの発端は別の部署からかかってきた一の電話でした。 新規事業の部署でいろいろな取引先様と付き合いがあるものの、紙の名刺が非常に多く管理に困っているとのことのことです。 私は小売業に勤務しているしがない一社員で、現在Eコマースの戦略立案に関する部署に所属しています。 電話先の方は、以前一緒の部署で勤務したことがある方です。現在新規事業のプロジェクト推進をしており、冒頭のような課題感を持っているため既存の

    GPTが人知れず既存の名刺管理アプリを抹殺していた話 - Qiita
  • 私が独学をして、マジ神だと思うサイトおよび他 - Qiita

    初めに 私は独学でプログラミングその他について勉強をしていますが、基的に知識を得るために金はかけません。調べれば何とかなるので。 私がプログラミングを始めるにあたって自分に投資したものは安いノートパソコンとマウスのみで合計金額は14600円(ノートパソコン14000円、マウス600円)ですね。 もちろんいいものはお金をかけなければ手に入りません。しかし、いいものというのはある程度のレベルにならなくては持っていても意味がほとんどないと思います。 実際にプログラミングの勉強を独学で始めると、なかなか教材を見つけることができず、え?こんないいサイトあったの!?もうちょっと早く見つけときゃあよかった!というものがめっちゃありましたので、これから独学でプログラミングの勉強をしたいという方に向けて、少しでもお役に立てたらと、紹介をしたいと思います。 というわけで、今回は私が感謝する神サイトおよびその

    私が独学をして、マジ神だと思うサイトおよび他 - Qiita
  • チームトポロジーから組織の現時点を知る - Qiita

    はじめに 私自身EMとしてこれまでチームコラボレーションの課題にあたるケースをいくつも経験してきました。 スクラムをやったらいいんじゃないか、リアーキテクチャーを考えて、サービス分割したらいいんじゃないかとか、色々と模索が考えられている中で、当にそれって根解決になるのか?そもそもその手法は何を解決するのかしっくりこないと感じることがありました。 そういった課題にどのようなアプローチしたらいいか悩んでいたときに、『チームトポロジー』に出会い、これは一つの道標として使えると感じました。 自分達の課題は、開発手法でも、アーキテクチャーでもなく、組織構造に根原因があるんじゃないか、そこから手を付けないといけなかったんじゃないかと考える機会となりました。 チームトポロジーとは何か こので書かれていることは、組織編成において、"どのようなチームがより効率的か"というのがフレームワークとして体系

    チームトポロジーから組織の現時点を知る - Qiita
  • オブジェクト指向は業務システムで本当に不要なのか? - Qiita

    主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった(ORMのインピーダンスミスマッチの影響が大きくなった) 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の3点に集

    オブジェクト指向は業務システムで本当に不要なのか? - Qiita
  • Airflowはすごいぞ!100行未満で本格的なデータパイプライン - Qiita

    はじめに ワークフローを作成、実行、監視するためのプラットフォーム「Airflow」が、近年人気を集めていて、多くの企業に利用されています。Airflow Summit 2022 のようなグローバルイベントも開催されるようになり、世界中から2000人以上のコントリビュータ(私もその1人)が貢献しているアツいプロジェクトです。 この記事で Airflow を使う意味と主要コンセプトを説明します。最後に、100行未満で実装できる格的なデータパイプラインの実例をお見せしたいと思います。 Airflowとは 概要 Airflowは ワークフロー を作成、実行、監視するためのプラットフォームです。ここで言う「ワークフロー」は、依存関係にある複数の タスク を、下図のように繋いだ形で、パイプラインとして実行していくものと思ってください。 Airflowを使うと、より早く、よりロバストなワークフローが

    Airflowはすごいぞ!100行未満で本格的なデータパイプライン - Qiita
  • htmxとは何なのか? その背景にある思想について - Qiita

    先日、Qiitaに投稿された一つの記事が注目を集めました。 元記事では、htmxというJavaScriptライブラリが英語圏で認知を獲得しているとして、インストールの仕方から使い方について公式のドキュメントの全体にわたって簡単に説明が行われています。 さまざまなプラットフォームでこの記事に対する反応を観察してみると、どちらかというと懐疑的な見方のほうが優勢のように見受けられます。ただ、多くのコメントは誤解に基づいているように見受けられました。「JSが要らない」といった元記事のミスリードによるところも大きそうですが1、なぜhtmxが大きく支持を得つつあるのかを理解するには、背景情報を含めて理解することが必要です。 htmxは、最近の複雑化するフロントエンド技術に対する単なる逆張りではありません。これまで30年ほどのあいだウェブ上のシステムを支え続けた「ハイパーメディア」の持つ強力さに今一度目

    htmxとは何なのか? その背景にある思想について - Qiita