並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 626件

新着順 人気順

RESTfulの検索結果1 - 40 件 / 626件

  • 【2020年】AWS全サービスまとめ | DevelopersIO

    このエントリは、2018年、2019年に公開したAWS全サービスまとめの2020年版です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。 こんにちは。サービスグループの武田です。 このエントリは、2018年、2019年に公開した AWS全サービスまとめの2020年版 です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。どちらがいいのか正直わからないので、フィードバックなどあれば参考にさせていただきます。 2020-01-08 リクエストがあったためAmazon Mechanical Turkを追加。 2018年まとめ 【2018年】AWS全サービスまとめ その1(コンピューティング、ストレージ、データベー

      【2020年】AWS全サービスまとめ | DevelopersIO
    • ChatGPTを最強の学習ツールにする方法 - Qiita

      こちらの記事は随時追加更新していきます 記事の内容 何かと話題のChatGPTですが、今回はこのChatGPTをプログラミング学習として活用し、 「最強の学習ツール」にしてしまおうという記事になります。 内容を書き換えれば、英語学習などにも置き換えることができます。 筆者の関連記事 ChatGPTはそのチャット内で質問した内容を記憶しそれによって回答が異なるケースがあります。 もし、意図した回答が得られない場合などは「New chat」から新たに質問するなどの工夫が必要です。 そして、ChatGPTからの回答内容はあくまでも一つの例であるという認識で向き合いましょう。 アジェンダ 登録方法 質問のコツについて ロードマップ(カリキュラム)を提案してもらう ふんわりとした内容を具体的にしていく 更に深掘りして手順を教えてもらう 「何がわからないかわからない」状態をなくしていく 次のレベルアッ

        ChatGPTを最強の学習ツールにする方法 - Qiita
      • パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary

        最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です

          パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
        • Web APIを手作りする時代は終わった?

          ::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh

            Web APIを手作りする時代は終わった?
          • スプレッドシートをWeb開発の万能ツールに変えるおすすめサービス厳選まとめ! - paiza times

            どうも、まさとらん(@0310lan)です! 今回は、Googleが提供しているスプレッドシートを表計算ではなく、Web開発の即戦力になる万能ツールへと変えてしまうサービスを厳選してご紹介しようと思います。 スプレッドシートのデータを活用して、Webコンテンツを作成したりデータベースとして活用するなどさまざまな開発手法に応用できるので、ご興味ある方はぜひ参考にしてみてください! ■スプレッドシートのデータを即座にAPIで提供する! 【 SwiftSheet 】 SwiftSheetはExcelやスプレッドシートなどで管理しているデータを、即座にRESTful APIとしてホスティングしてくれるのが大きな特徴です。 CSVで保存したファイルをアップロードするだけという簡単な操作のため、ユーザー登録や課金などは一切不要です。 たとえば、お店のリストをスプレッドシートで管理しているとします。 こ

              スプレッドシートをWeb開発の万能ツールに変えるおすすめサービス厳選まとめ! - paiza times
            • 【入門】インフラやるなら知っておきたいトピックのリンク集 - Qiita

              インフラをやるうえで知っておきたいトピックを独断と偏見で選んでリンク集をつくりました. HTTP HTTP入門 [BurpSuiteJapan]HTTP基礎入門 RESTful API Web API入門 RESTful API 入門 KVS key-valueストアの基礎知識 KVS 超入門 - footmark NoSQL HBaseの概要とアーキテクチャ | Think IT(シンクイット) Oracle Cloud Hangout Cafe - 明解! NoSQLの勘所 - Speaker Deck データベース 2018-11-データベース / 2018-11 database - Speaker Deck SQLをはじめよう - 初心者でもわかる、構文とデータ取得の基本 - エンジニアHub|若手Webエンジニアのキャリアを考える! RDBとNoSQLにみるDB近現代史 データ

                【入門】インフラやるなら知っておきたいトピックのリンク集 - Qiita
              • AWSを学べるゲーム「AWS Cloud Quest日本語版」ソリューションアーキテクト編が登場

                Amazon Web Service(AWS)は、ゲームを通じてAWSを学べる「AWS Cloud Quest」シリーズのソリューションアーキテクト編となる「AWS Cloud Quest: Solutions Architect」日本語版が登場したと発表しました。 AWS Cloud Questは、オリジナルの英語版では以下の7つのロールに合わせた学習カテゴリのゲームが提供されています。 クラウドプラクティショナー ソリューションアーキテクト サーバーレスデベロッパー 機械学習 セキュリティ データ分析 ネットワーク この7つのうち、日本語版としては一番目のクラウドプラクティショナー(クラウドを実践する人)編となる「AWS Cloud Quest:Cloud Practitioner」のみ提供されていました。 今回新たに二番目の「AWS Cloud Quest: Solutions Ar

                  AWSを学べるゲーム「AWS Cloud Quest日本語版」ソリューションアーキテクト編が登場
                • RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ

                  ※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便

                    RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
                  • Smart UI パターンが再評価される世界 - id:onk のはてなブログ

                    設計ナイト2020 を受けて、今どんなアーキテクチャを選ぶべきかという話をしたくなったのだ。 kichijojipm.connpass.com 設計ナイトで高ぶった結果1時間コースの発表資料が完成したので供養場所を探しています。聞いてくれ!!!— Takafumi ONAKA (@onk) 2020年11月1日 お前誰よ 2000年代前半に SI 2000年代後半にブログ、SNS 2010年代にソーシャルゲーム 2020年代に UGC サービス をやってきた人間。数百万〜数億行のデータ、月間数千万〜数十億 imp 程度を主戦場にしています。 今日の話 DDD と PofEAA から学ぶパターン/アンチパターン Rails によって発見された、密結合で速く走れるソフトウェア 今求められているアーキテクチャ 昂ぶって 15,000 字ぐらい書いてしまった。 DDD と PofEAA から学ぶパ

                      Smart UI パターンが再評価される世界 - id:onk のはてなブログ
                    • TCPとQUICの比較

                      ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見

                        TCPとQUICの比較
                      • Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO

                        こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容(項目) REST とは何か リソースを中心とした API 設計の整理 HTTP

                          Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
                        • フルスタックエンジニアになるためのモダンな8つのプロジェクト - Qiita

                          こんにちは、たかとーです。 今日は8 Projects with modern designs to become a Full-stack Master 2020の日本語訳記事です! *当記事は、Thuさんの許可を得て翻訳しています。 ブログでも読めます! 8 Projects with modern designs to become a Full-stack Master 自分のスキルを磨くためのプロジェクトを探していますか?新しいアイデアを思いつくのに行き詰っていませんか? 開発者として、私たちはコードを書くのが大好きですが、デザインやアイデアを見つけるのが難しいことがあります。 こんにちは、Thuです。ここ数ヶ月、私はデザインや要件を含む8つの実在するプロジェクトの作成に取り組んできました。 私は、あなたがスーパースターなフルスタックデベロッパーになるために必要な全てのスキルを鍛

                            フルスタックエンジニアになるためのモダンな8つのプロジェクト - Qiita
                          • GitHub - techschool/simplebank: Backend master class: build a simple bank service in Go

                            This repository contains the codes of the Backend Master Class course by TECH SCHOOL. You can also find it on Udemy at this link. And don't hesitate to join Tech School's Discord group to chat directly with me and other students. In this course, you will learn step-by-step how to design, develop and deploy a backend web service from scratch. I believe the best way to learn programming is to build

                              GitHub - techschool/simplebank: Backend master class: build a simple bank service in Go
                            • [書評] ハッキングAPI ―Web APIを攻撃から守るためのテスト技法

                              サマリ ハッキングAPI―Web APIを攻撃から守るためのテスト技法(2023年3月27日発売)を読んだ。本書は、Web APIに対するセキュリティテストの全体像と具体的なテスト方法を記載している。ペンテスターは、APIの検出、APIエンドポイントの分析、攻撃(テスト)を行う必要があり、そのために必要な情報がすべて記載されている。また、実習のためのツールと「やられサイト」を複数紹介し、具体的なトレーニング方法を解説している。単にツールやサイトの使い方の説明にとどまらず、本格的なペネトレーションテストの考え方を説明している。 本書の想定読者はAPIのペネトレーションテストを実施するペンテスター及びペンテスターを目指す人であるが、API開発者やウェブアプリケーション脆弱性診断員にとっても有益な内容を多く含む。 重要事項説明 本書の監修者の一人(洲崎俊氏)と評者は知人関係にある 評者が読んだ書

                              • 【2021年】AWS全サービスまとめ | DevelopersIO

                                こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2021年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2021年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの?」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2020年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 205個 です。 まとめるにあ

                                  【2021年】AWS全サービスまとめ | DevelopersIO
                                • 【2021年】 技術書好きプロエンジニア達が紹介する40選 - RAKUS Developers Blog | ラクス エンジニアブログ

                                  こんにちは、技術広報のyayawowoです。 皆様、お気に入りの技術書はありますか? 今回は、弊社主催で開催している「おすすめの技術書LT会」にて、エンジニア/デザイナーの皆さんに紹介いただいた技術書を一挙公開します! おすすめの技術書 LT会 - vol.1 おすすめの技術書 LT会 - vol.2 積読が増える可能性がある、エンジニア/デザイナーが厳選した技術書が盛り沢山…お読みになる際は覚悟ください! ラクス開発メンバーが選んだ技術書は以下をご確認ください。 ・開発メンバーが選ぶ、おすすめの技術書【2020年度】 - RAKUS Developers Blog | ラクス エンジニアブログ 入門シリーズ 『C++プログラミング入門(湯田幸八)』 『ドメイン駆動設計入門』 『実践SQL教科書』 『ソフトウェアデザイン 2021年3月号』 『独習C 新版』 『PHPの絵本 第2版 Web

                                    【2021年】 技術書好きプロエンジニア達が紹介する40選 - RAKUS Developers Blog | ラクス エンジニアブログ
                                  • GraphQLの全体像とWebApp開発のこれから - Qiita

                                    TL;DR GraphQLはクライアント側とサーバー側の双方の複雑化を解決するために利用されてる フロントエンドにとってGraphQLはHTTP上で動く信頼できる唯一のリソースとして振る舞う フロントエンドの状態管理のベストプラクティスとしてのApollo Client クライアントファーストなAPI, GraphQLはWeb APIのベストプラクティスになり得る クラシックアプリケーションを改修することなくGraphQLとモダンフロントエンドで今どきのアプリを作れる はじめに GraphQLは非常に良く出来たソフトウェア(の仕様)ですが、複数の側面を持つことからすぐに理解することが難しくまだ日本ではあまり受け入れられていない印象があります。GraphQLを端的に何と言われると "全てのフロントエンドのためのAPI BFF" なのですが、それだけで理解出来る人はなかなか居ないように思います

                                      GraphQLの全体像とWebApp開発のこれから - Qiita
                                    • Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita

                                      はじめに 私の職場では、WebAPIの仕様書をWordで書く習慣があったのですが、2018年頃にSwaggerで書くように切り替わったので、そのように変化した経緯を書きます。 何かの参考になれば幸いです。 ちなみに、こちらの記事と同じ職場です。 Wordな職場にMarkdownを定着させるためにやった4つのこと Swaggerとは? Swaggerとは、REST APIの仕様を定義するためのフォーマットです。その周辺技術も含めて、Swaggerと呼ばれます。以下の記事が非常に参考になりますので、詳細を知りたい方はご参照ください。 Swaggerの概要をまとめてみた。 Swagger 導入失敗 2016年頃のある日、上司から「世の中にはSwaggerというものがあるらしい。調べてもらえる?」と指示されました。 調べてみたところ、Swaggerがあれば、WebAPIのドキュメントサイトも作れる

                                        Wordな職場にSwaggerを定着させようとして失敗したけど結局定着した話 - Qiita
                                      • ソフトウェアエンジニア社長として起業してから会社清算するまでの4年間の振り返り (中編)|Takahiro Ikeuchi

                                        前編では、起業に至るまでの前職での経験と起業の動機、最初の事業立ち上げ未遂までの振り返りを行いました。今回の中編では、次に行った事業の話をメインに振り返りたいと思います。 第二期 : B2B SaaS 事業の立ち上げ 〜 モダン・ヘルプデスク SaaS を求めて最初に計画した事業が凄い勢いで頓挫したショックから立ち直ったのは、2016年早春のことでした。当時、最初の事業が失敗した理由は以下の2つだったと考えました。 ・業界から見ると僕は部外者であり、人脈もなければ仕事をした実績もない。→ 自分の体験に根付いておらず、僕がやる蓋然性が薄かった。 ・事業推進の面で、作品をいかに巻き込めるかというビジネス・ディベロップメント側の比率が大きすぎた。→ 自分の強みはプロダクトのつくりこみにあると考えた。 とにかく自分の得意領域に寄せて勝負しようということで、そこで取り組むことにしたのが B2B Sa

                                          ソフトウェアエンジニア社長として起業してから会社清算するまでの4年間の振り返り (中編)|Takahiro Ikeuchi
                                        • Reactチュートリアル2:レビューサイトを作ろう

                                          本資料について 本資料は日本大学文理学部情報科学科の開講科目「Web プログラミング」の教材として作成されました。本資料は下記のライセンスの範囲内で、当授業以外でも自由にご利用いただけます。 対象読者 本資料は、以下の教材を学習済み、もしくはそれと同等以上の知識を持っていることを前提としています。 React チュートリアル:犬画像ギャラリーを作ろう 基本情報技術者試験レベルの関係データベースの知識 本資料で学ぶこと 本資料では以下の内容を学びます。 Express と Sequelize による API サーバー開発 React と API サーバーの連携 Cross-Origin Resourcer Sharing React によるルーティング Auth0 によるユーザー認証 Heroku による API サーバーの公開 ライセンス この作品はクリエイティブ・コモンズ 表示 4.0

                                            Reactチュートリアル2:レビューサイトを作ろう
                                          • 1人でデスクトップとモバイル両方で動いて同期するアプリをどうやって作ったか

                                            こんにちは、個人アプリ作家のTAKUYAです。InkdropというクロスプラットフォームなMarkdownノートアプリを1人で開発しています。このアプリはmacOS、Linux、Windows、Android、iOSで動作します。ご存知かもしれませんが、この5プラットフォームにアプリを対応させるのは簡単ではありません。しかしながらパワフルなフレームワークを活用すれば、それも不可能ではありません。それらに頼るだけでなく、プロジェクトを持続可能に保つための開発戦略も必要となります。本記事では、僕がこれまでどのようにして開発して来たのかシェアしたいと思います。 あなたは1人で開発しているのではないクロスプラットフォームなアプリの開発は、往々にして多くの予測不能かつ再現不能な問題を伴います。自分の環境では正しく動いていた機能が、他の環境では思うように動かない。例えば、最近僕もそういう問題を経験しま

                                              1人でデスクトップとモバイル両方で動いて同期するアプリをどうやって作ったか
                                            • ソフトウェアアーキテクチャ入門

                                              はじめに 今回の記事では、ソフトウェアアーキテクチャの入門的な内容を解説する。 対象とする読者 ソフトウェアアーキテクチャを勉強するエンジニア アーキテクチャに関して全くわからない初心者 タイトルで気になったひと ソフトウェアアーキテクチャとは? ソフトウェアのアーキテクチャは、システムの主要なコンポーネント、それらの関係(構造)、およびそれらがどのように相互作用するかを記述する。ソフトウェアのアーキテクチャとデザインには、品質属性、人間のダイナミクス、デザイン、IT環境など、多種多様な寄与要因が含まれる。アーキテクチャは、品質、保守性、パフォーマンス等のような全体的な成功に影響を与える重要な決定を含む。 ソフトウェアアーキテクチャの主な目的は、アプリケーションの構造に影響を与える要件を特定することだ。良好なアーキテクチャは、技術的な解決策を構築する際のビジネスリスクを削減し、ビジネス要件

                                                ソフトウェアアーキテクチャ入門
                                              • ホテルの客室検索APIのアーキテクチャ設計時に考えたこと

                                                作ったもののイメージ ホテルの客室検索APIとは、チェックイン日やその他の条件を入力として受け取り、マッチするホテルの客室を返すものです。以下の画像はExpediaのものですが、赤枠で囲っている部分(他にもたくさんある)が入力になります。2022年4月頃に無事リリースされました。 この検索APIを構築を任された際に、何を考えて設計していったのかを以下に示していきます。 顧客からの要望 顧客の会社は当時エンジニアがおらず(やりとりしている社長は元エンジニアだが)、これまでも私と仕事をしたことがあったので依頼が来ました。顧客と密にコミュニケーションを取りわかったのは、以下のような要望でした。 このAPIは自社サービスとして第3者(要契約)に使ってもらえるようにしたい 完全に一般公開ではなくちゃんと契約を結ばないと利用できないようなもの 検索条件を柔軟に、かつ使いやすい感じで指定できるようにした

                                                  ホテルの客室検索APIのアーキテクチャ設計時に考えたこと
                                                • HTTP検索条件、GETにするか?POSTにするか? | フューチャー技術ブログ

                                                  はじめにTIG DXユニット 1真野です。 RESTfullとかRESTishな方針でWebA PIの横断検索を設計する際にチーム内で方針について議論したやり取りの備忘記事です。 注意としてB2C向けなWeb APIを提供するというよりは、主に企業間または企業内部で使われるようなAPIの設計のバイアスがあります。LSUDs(Large Set of Unknown Developers)かSSKDs(Small Set of Known Developers)で言えば、確実にSSKDs脳で記事が書かれています。 REST API広く使われているため日本語記事も多数です。実践RESTful HTTP - InfoQ や、0からREST APIについて調べてみた など良さそうな記事が沢山でてくるの読むと良いでしょう。一般的な設計方法はやや古いですがWeb API: The Good Parts

                                                    HTTP検索条件、GETにするか?POSTにするか? | フューチャー技術ブログ
                                                  • 2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC engineers' blog

                                                    こんにちは! Tech KAYAC Advent Calendar 2021 7日目を担当する荒賀(@ken39arg) です。 カヤックのエンジニアブログには2008年にPHPを使ったガラケー関連の記事を書いたのが最初になります。 それから10年以上たち、ガラケーも弊社でのPHPのプロジェクトもほぼなくなり、メンバーもかなり入れ替わり、私自身も20代だったのがついに40歳になりました。そんな私にとってこのアドベントカレンダーは私は今でもここにいるよというPingのような役割になっているため、年に一度若者に混じってアドベントカレンダーに参加しております。 例年ですと、趣味のマラソンなどに関する実績も書いているのですが、昨年同様、今年も続くコロナ禍により多くの大会が中止となったためこちらに関しては特に特記すべき実績はありません。ただ2020年に走るはずだった東京マラソンは権利は移行を続けてお

                                                      2021年サーバーサイドのエンジニアが使ってよかったもの10選 - KAYAC engineers' blog
                                                    • 2022年に読んでよかったO'Reilly書籍をまとめた

                                                      はじめに 本記事では、私が2022年に読んでよかったO'Reillyの技術書とその要点を簡潔に解説する。本記事の内容はあくまで一個人の見解にすぎないので、参考程度に。今後O'Reilly関連の技術書を購入する上で、少しでも参考になるものがあれば幸いだ。 リーダブルコード 読みやすいコード、質の高いコードを書く上で重要な原則が体系的にまとめられている。プログラミング初心者から上級者まで幅広く使える。プログラミングを学ぶ上で重要な原則(例:制御フロー、論理式など)やその書き方をこの1冊でまるごと学べる。本質的な内容と具体的なテクニックが両方ともまとめられていて読みやすい。何回も読み直して普段の開発に活かすべき重要な書籍である。 データ指向アプリケーションデザイン アプリケーションの設計・開発における原則を図解やソースコード付きで丁寧に解説されている。今後のアプリケーション開発における原則をデー

                                                        2022年に読んでよかったO'Reilly書籍をまとめた
                                                      • AWS、言語やプロトコルに依存しないインターフェイス定義言語(IDL)「Smithy」をオープンソースで公開

                                                        AWS、言語やプロトコルに依存しないインターフェイス定義言語(IDL)「Smithy」をオープンソースで公開 クラウド時代のアプリケーションは、複数のソフトウェアがAPIを通じて連携するアーキテクチャが主流になると考えられています。そのため、さまざまなソフトウェアにおいて正確かつ確実にAPIを実装することの重要性が高まっています。 AWSは、このAPIを定義する言語、およびその定義からAPIを実装するコードを生成するツールからなる「Smithy」ベータ版をオープンソースとして公開しました。 SmithyのWebサイトから、その説明を引用しましょう。 Smithy is a protocol-agnostic interface definition language and set of tools for building clients, servers, and documentat

                                                          AWS、言語やプロトコルに依存しないインターフェイス定義言語(IDL)「Smithy」をオープンソースで公開
                                                        • RESTful API との比較で GraphQL API を作ることの難しさ|qsona

                                                          上の資料でも書いてるんですが、要点を言うと以下のようなことを主張している。 API の設計手法として、以下の2つのパターンが考えられる ・Resource-based API ・Usecase-based API Usecase-based というのは要はクライアントの要求にそのまま沿った形で API を作るということだ。しかし、UI やその他クライアントの要求というのは変わりやすいものなので、そのたびにいちいち API を変更しないといけないとか、API に一貫性がなくて使いにくいとか、1つの endpoint で多数の要求に対処する "神API" が作られてパフォーマンスが悪化する、というような問題が起こる。 したがって、注意深く RESTful API を設計すると Resource-based になる。ここで言っている Resource というのはテーブル設計にやや近いが、そのまま

                                                            RESTful API との比較で GraphQL API を作ることの難しさ|qsona
                                                          • コンテナ・セキュリティ入門 脆弱性 - Qiita

                                                            コンテナイメージのレジストリでは、脆弱性検査の実装が当たり前になっている。企業でKubernetesなどコンテナを使用するにあたって脆弱性対策がどれほど重要なものか理解するために、脆弱性検査や、関連する国際的な標準について整理した。 脆弱性(ぜいじゃくせい)とは 脆弱性とは、プログラムの動作の不備を悪用される情報セキュリティ上の弱点である。つまり、ソフトウェア上の問題が原因となって生じた欠陥であり、セキュリティホールとも呼ばれる。当然、ソフトウェア開発者は、脆弱性を産まないように細心の注意を払ってコード開発を進めるが、開発者が利用するオペレーティングシステムのライブラリやパッケージに含まれることもある。そのような事情から、開発者の責任範囲外に原因がある場合も多くある。 潜在的な脆弱性を突いた新たなクラッキングの手口が、時間の経過ともに発見される。そのことから、開発当初はコードに脆弱性は無い

                                                              コンテナ・セキュリティ入門 脆弱性 - Qiita
                                                            • におうコードの問題集でWEBエンジニア総合力の向上を目指す - 技術書LT&懇親会【Caraquri Tech Night #1】 - このすみノート

                                                              「技術書LT&懇親会【Caraquri Tech Night #1】」で、LTプレゼンをしました。 オススメの技術書を紹介し合って、気づきや知見を増やすイベントです。 caraquri.connpass.com 私は本が好きなので、定期的に書店に足を運んでいます。 今回のイベントでは、技術系同人誌についてプレゼンされる方が多かったです。 におうコードの問題集 私は「におうコードの問題集」について発表しました。 におうコードの問題集とは? 「におうコードの問題集」は技術書典で頒布されているシリーズ作品で、過去に3作が頒布されています。 技術書典4: リファククタリング 〜バリエーションに立ち向かう編〜 技術書典5: セキュリティ 〜セキュリティホールに立ち向かう編〜 技術書典6: 設計 〜ソフトウェア設計に立ち向かう編〜 におうコードとはなにか? 「におうコード」とは、脆弱性・バグ・保守性が

                                                                におうコードの問題集でWEBエンジニア総合力の向上を目指す - 技術書LT&懇親会【Caraquri Tech Night #1】 - このすみノート
                                                              • 令和時代のページネーションを考える (REST API編) - Sweet Escape

                                                                今回はバックエンドAPIでページネーションをどうやるかについての話なので、よくある無限スクロールUIのようなフロントエンド側の実装に関する話はしない。あくまでもAPI、もっと言えばRESTfulなAPIのリクエスト・レスポンスにおけるページネーションの話。 本気で深く考えるというよりざっくり検討したときの話です。 はじめに REST APIを実装するにあたってリスト系のAPIを提供する場合に必須といっても過言ではないのがページネーション。大量のリソースをレスポンスする場合にそれらを一気に返してしまうことは応答速度、転送量、クライアントサイドでの扱いづらさなどなどに繋がるので必須と言える。 最近、新たなAPIを開発するにあたってページネーションをする必要があったこともあり、今回はこのページネーションをどうやって提供するか整理して改めて検討してみた。 前提 TypeScript Nest.js

                                                                  令和時代のページネーションを考える (REST API編) - Sweet Escape
                                                                • すぐにAPIを体験!public-apis 100以上のJavaScript axiosサンプル集

                                                                  はじめに このページは、プロトアウトスタジオのAPIにつなげる授業に関連して、よりAPIの多様さ、広がりを深掘りします。 まだ、JavaScriptに慣れていなくても「なるべくシンプルにAPIを体験する」ことを目指して、 public-apis というフリーで使えるAPIを集めてリストにしているサイトから、手順が少なくAPIにつなげられるシンプルに取得できるものを中心に、直接取得できるURL・Node.js axios await/async ソースコードを一つ一つトライしています。 慣れてきたら、自分で public-apis のサイトを直接読んでみて、巡ってみましょう! APIピックアップ数 最終更新日 2020/6/8 104 個のAPIをピックアップ中! 参考資料 public-apis の豊富なAPIリストをベースにAPIつなげていきます。 ピックアップルール 手順が少なくAPI

                                                                    すぐにAPIを体験!public-apis 100以上のJavaScript axiosサンプル集
                                                                  • フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと

                                                                    フロントエンドのデベロッパーが2021年に向けて何に注目すべきかを紹介します。 特に上級職や転職など、ステップアップを目指す人は要チェックです! 10 Things Front-End Developers Should Learn in 2021 by Simon Holdorf 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 1. フレームワーク 2. 静的サイトジェネレーター(SSG) 3. JAMstack 4. プログレッシブウェブアプリ(PWA) 5. GraphQL 6. コードエディタ/IDE 7. テスト環境 8. クリーンなコード 9. Git 10. ソフトスキル 終わりに はじめに 2021年は、フロントエンドの開発がテクノロジー業界で最もホットなトレンドの1つになることは間違いないでしょう。フ

                                                                      フロントエンドのデベロッパーが2021年に向けてチェックしておきたいこと
                                                                    • 【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita

                                                                      はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています

                                                                        【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
                                                                      • 【感想】『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』:Lambdaで本格サービス開発まで - Rのつく財団入り口

                                                                        サーバーレスアプリケーション開発ガイド Lambda関数を用いたサーバーレス開発をもっと知っておこうと思って読んだ本の感想です。2018年4月刊行、サーバーレスの主要サービス解説にコードはPython、のみならずフロントはVue.jsを使った本格開発まで、実践的な内容が詰まった本です。 作者は現Amazon Web Services Japan所属のKeisuke69こと西谷圭介さん。Twitterでもよくお見掛けします。(@Keisuke69) サーバーレスアプリケーション開発ガイド Chapter1 サーバーレスアプリケーションの概要 1-1 サーバーレスアプリケーションとは 1-2 ユースケースとアーキテクチャパターン 1-3 サーバーレスアプリケーションのライフサイクル管理 Chapter2 Amazon Web Services(AWS)利用の準備 Chapter3 インフラを自

                                                                          【感想】『Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド』:Lambdaで本格サービス開発まで - Rのつく財団入り口
                                                                        • 『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索

                                                                          はじめに 現場で役立つシステム設計の原則を知りたいと思っていたのですが、丁度現場で役立つシステム設計の原則について言及されている書籍があったので読みました。 gihyo.jp ある程度知名度のある書籍で、QiitaやZenn等でまとめられている方がいらっしゃるのですが、自分のアウトプットとして、感想も交えてまとめていきます。 全体の話 この書籍の雰囲気や見通しを立ちやすくするために、参考書籍の一覧を抜粋して紹介します。 『エリック・エヴァンスのドメイン駆動設計ソフトウェアの核心にある複雑さに立ち向かう』『新装版リファクタリング既存のコードを安全に改善する』『SQLアンチパターン』『エンタープライズアプリケーションアーキテクチャパターン』『エクストリームプログラミング』 システム設計の全般を対象にしているのですが、ベースの思考としてはオブジェクト指向プログラミングから発展して、ドメイン駆動設

                                                                            『現場で役立つシステム設計の原則』を読みました - 人間のあるべき姿の探索
                                                                          • GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.

                                                                            Architecture styles define how different components of an application programming interface (API) interact with one another. As a result, they ensure efficiency, reliability, and ease of integration with other systems by providing a standard approach to designing and building APIs. Here are the most used styles: SOAP: Mature, comprehensive, XML-based Best for enterprise applications RESTful: Popul

                                                                              GitHub - ByteByteGoHq/system-design-101: Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
                                                                            • 【2022年】AWS全サービスまとめ | DevelopersIO

                                                                              こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2022年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2022年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの?」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2021年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 223個 です。 まとめるにあ

                                                                                【2022年】AWS全サービスまとめ | DevelopersIO
                                                                              • RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ

                                                                                ※この投稿は米国時間 2022 年 12 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。 オンラインで、組み立て式のテーブルを注文したとします。ところが、パッケージを開けてみると、組立説明書が入っていません。完成品がどんなものかはわかっていても、それぞれのパーツをどう組み立てればいいのか、まるでわかりません。設計が不十分な API を使うコンシューマ開発者も、同じような経験をしているといえます。適切に設計された API なら、容易に見つけ、検索してアクセスし、使用することができます。高品質の API は、コンシューマ開発者がアイデアをひらめき、新しいユースケースを作り上げる手助けになってさえくれます。 もちろん、API 設計を改善する方法はあります。たとえば、RESTful のプラクティスに従うなどです。しかし、お客様が知らず知らずのうちに、ちょっとした不便

                                                                                  RESTful のウェブ API 設計で避けるべき 6 つのよくあるミス | Google Cloud 公式ブログ
                                                                                • ChatGPTプラグイン の作成方法|npaka

                                                                                  1. ChatGPTプラグインの作成手順「ChatGPTプラグイン」の作成手順は、次のとおりです。 (1) APIの実装 (2) マニフェストファイルの作成 (3) OpenAPIドキュメントの作成 2. マニフェストファイルの作成2-1. マニフェストファイルの基本構成「マニフェストファイル」は、「ChatGPTプラグイン」のメタデータを記述するファイルです。APIのドメインの「/.well-known/ai-plugin.json」でホストします。 「マニフェストファイル」の基本構成は、次のとおりです。 { "schema_version": "v1", "name_for_human": "TODO Plugin", "name_for_model": "todo", "description_for_human": "Plugin for managing a TODO list.

                                                                                    ChatGPTプラグイン の作成方法|npaka