HTTPとRESTの基本 『網羅版：HTTPメソッドとレスポンスコード』 - Qiita
初めに 参考サイト：HTTP 意味論（共通基盤）RFC 9110 — HTTP Semantics 参考サイト：開発者向けのウェブ技術 > HTTP レスポンスステータスコード 参考サイト：Wiki HTTPステータスコード 参考書籍：Webを支えWebを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 参考書籍：オライリー・ジャパン RESTful Webサービス 各文献を元にまとめした。『3. HTTPレスポンスコード概要』以降は引用まんまに近いところもあれば、大幅に書き換えた・再構成した部分も多々あります。 この記事を書こうと思った切欠はステータスコードについて質問された時にちゃんと答えられなかったからです。 次は、これを元に RESTful API の設計の記事とか書いてみようと思います。 また、この記事は一応3部作です。特に第1部で
HTTPとRESTの基本 『網羅版：HTTPメソッドとレスポンスコード』 - Qiita
初めに 参考サイト：HTTP 意味論（共通基盤）RFC 9110 — HTTP Semantics 参考サイト：開発者向けのウェブ技術 > HTTP レスポンスステータスコード 参考サイト：Wiki HTTPステータスコード 参考書籍：Webを支えWebを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) 参考書籍：オライリー・ジャパン RESTful Webサービス 各文献を元にまとめした。『3. HTTPレスポンスコード概要』以降は引用まんまに近いところもあれば、大幅に書き換えた・再構成した部分も多々あります。 この記事を書こうと思った切欠はステータスコードについて質問された時にちゃんと答えられなかったからです。 次は、これを元に RESTful API の設計の記事とか書いてみようと思います。 また、この記事は一応3部作です。特に第1部で
Kubernetes 1.25: SIG Cluster Lifecycle の変更内容 - Qiita
Kubernetes 1.25 の CHANGELOG から SIG Cluster Lifecycle の取り組みについてにピックアップしました。 いつもより変更が少なく、落ち着いてきた感じがします。 主要テーマ (Major Themes) なし。 重大なアップグレードに関する警告 (Urgent Upgrade Notes) なし。 種類別の変更 (Changes by Kind) 廃止予定 (Deprecation) kubeadm: ConfigMap "kubeadm-config" の ClusterConfiguration.imageRepository に古い"k8s.gcr.io"が含まれていた場合、"upgrade apply/diff/node" 中にそれを新しいデフォルトである "registry.k8s.io" に置き換えます。ただし、更新の反映は "upgr
【まとめ】エンジニアを志すならば、まずやってみてほしいこと - Qiita
はじめに 「未経験だけど、エンジニアになりたい」という人に、僕がまずやってもらっていることを、この記事にまとめてみました。 「習得してほしい」というのももちろんですが、何よりも自分自身がエンジニアに向いているかを確かめる意味でも、これらを一通りこなすことがその試金石になるのでは...と考えています。 以下、やってみてほしいことと、その理由を書いていきます。それぞれ、無料で取り組めるサービスがあるものは、それも紹介していきます。 ブラインドタッチの練習 初っ端からプログラミングと関係ない感じですが、この業界に携わる上での根幹部分になると思ってます。 タイピングスピードは、あらゆるタスクの解決スピードを底上げしてくれます。コーディングはもちろん、ちょっとした調べごと、メールやチャットでの相談など、仕事のあらゆる場面で、僕たちはキーボードを触ることを求められます。 エンジニアに限った話ではないで
CKAとCKADに合格したので、その過程をまとめる - Qiita
背景 CKAとCKADが必要になったので、2週間ほど準備をして受験した。 それまでの流れをまとめておくことで、今後受験する方の役に立てればと思う。 受験前 受験中 受験後 の三つに分けて書きました。 試験そのものについて詳しく知りたい人は、 https://qiita.com/mochizuki875/items/a77d5c495d2fb99bd2f9 https://kakakakakku.hatenablog.com/entry/2021/03/24/091214 こちらの記事がお勧めです。 ただし、2022年7月から試験のプラットフォームが変わっているようでいくつか現時点(2022年10月)とルールが異なるようです。 自分のブラウザを使うわけではなく、リモートデスクトップ上のブラウザを使うのでブックマークやクリップボードの設定などは役に立たないです。 それに伴ってデュアルディスプレ
GoogleのShell Style Guideの邦訳 - Qiita
背景 (Background) どのシェルを使うか (Which Shell to Use) Bash は実行が許可された唯一のシェルスクリプト言語である。 実行可能ファイルは #!/bin/bash と最小限のフラグで始めなければならない。シェルオプションの設定に set を利用することで、 スクリプトを bash script_name として呼び出してもその機能を損なわないようにせよ。 全ての実行可能シェルスクリプトを bash に制限することで、全てのマシンにインストールされた一貫したシェル言語を得る。 これに対する唯一の例外は、コーディング対象によって強制される場合である。この1つの例として、Solaris SVR4 パッケージは、どんなスクリプトにも plain Bourne shell であることを要求する。 いつシェルを使うか (When to use Shell) シェル
史上最強のデータベース、SurrealDB - Qiita
SurrealDBというRust製データベースを知ったので紹介します。このデータベースはすごいです。リレーショナル、ドキュメント、グラフ、あらゆる種類のデータ構造を扱うことができ、かつインメモリ、単一ノード、分散環境、全てで動かすことができます。さらにHTTPやWebSocketによるアクセスと柔軟なユーザ認証、認可機能とがDB本体に内包されており、ブラウザから直に接続するWebDBとしても使えます。とにかくなんでもできる夢のデータベースといった感じです。 特徴 機能を挙げていたら多くなりすぎたので、特に面白い部分を挙げます。 配列やオブジェクトをネストした複雑なデータ構造を持てるのに、レコードリンクという機能によりリレーションに対応していてしかもSQLやMongoDBより簡潔にクエリが書ける。 スキーマレスで各レコードには任意のフィールドを持てるが、必要ならスキーマを定義することもできる
プログラマーのための原則（2 万字） - Qiita
はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』（1999 年）で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同
【MS Ignite 2022】Power Automate 関連の発表まとめ - Qiita
こんにちは、日本マイクロソフトの向井です。 10/12~14にMicrosoft Ignite 2022が開催されました。 こちらの記事は、Power Automate に関する以下のセッションの内容をまとめたいと思います。 「Power Automate を使用してクラウドでハイパーオートメーションを拡張する」 0. このセッションで発表されたこと Stephen Siciliano さんの発表 ・自然言語からフローを作成する ・式を自動で作成する Christy Jefson さんの発表 ・Excel のタブに自動化タブが追加 ・Power Virtual Agents のプロ開発者向け機能がプレビューに ・SAPの事前構築済みソリューションについて ・Automate Center of Excellence の構築 ・Hosted RPA bots がプレビューに 1. Steph
20代エンジニアのためのプログラマー勉強法 ～Matzがおくる「生涯エンジニア」になるためのプログラミングとの向き合い方～ - Qiita
20代エンジニアのためのプログラマー勉強法 ～Matzがおくる「生涯エンジニア」になるためのプログラミングとの向き合い方～新人プログラマ応援まつもとゆきひろ講演メモ 9/29(金)に開催された、サポーターズcolab主催のまつもとゆきひろさんの講演に行ってきました。 ↓講演情報 https://supporterz-seminar.connpass.com/event/96550/ 他にも多くの方がqiitaやはてなブログ等にメモを上げておりますが、個人的な記事作成の練習も兼ねて投稿させてもらいます。 ※聞きながらとった断片的なメモをもとに、話の内容を思い出しながら加筆しています。 そのため、見出しに対して内容の異なる箇所があるかもしれません。 ※10/2追記 思った以上に多くの方に見ていただいておりびっくりしてます。ありがとうございます。 特に公開するつもりもなく取っていた雑メモを基にし
Azure Fundamentals(AZ-900)：Azure の基礎: Azure のアーキテクチャとサービスについて説明する「Azure Virtual Machines(VM)」 - Qiita
Azure Fundamentals(AZ-900)：Azure の基礎: Azure のアーキテクチャとサービスについて説明する「Azure Virtual Machines(VM)」Azure初心者AZ-900 Microsoft Learnを用いたMicrosoft Azure Fundamentals(AZ-900)の試験内容をまとめる投稿です。 この投稿ではMicrosoft Learnで学ぶ内容をできるだけ簡潔にまとめております。 Azureの勉強を一から始める方の参考になれば幸いです。 今回の学習内容 ◆「Azure Virtual Machines(VM)」 ◇対応するMicrosoft Learn ラーニングパス Azure の基礎: Azure のアーキテクチャとサービスについて説明する ◇対応するモジュール Azure Virtual Machines について説明す
【Azure】約25時間の勉強でAZ900を取得したので、勉強方法やコツを共有してみる - Qiita
1.はじめに どうも、ARIの名古屋支社に勤務している愛知県民です♪ (/・ω・)/ 先日、うちのベビー（1歳1か月）から「AZ900とれよ」と言われた気がしたので、 早速勉強して資格を取得してきました！ そこで今回はAZ900を取得した勉強方法やコツについて記事にしたいと思います。 AzureやAZ900を勉強中の方の参考になれば幸いです。 (*^^)v
[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita
下記ドキュメントバージョンに関する注意点です。 バージョン番号のルールを定める：バージョン番号は、どのようにつけるかルールを定め、チーム全員が同じ理解で使用するようにする必要があります。たとえば、変更内容によって数字がどのように増えるか（major, minor, patch）、何桁で表現するかなど、具体的に決めておくことが重要です。 変更履歴を明確にする：どのような変更があったのか、それがどのバージョンで実施されたのかを明確にすることが必要です。これにより、何らかの問題が発生した場合に、どのバージョンから問題があるのか特定することができます。 ドキュメントの保存場所を一元化する：ドキュメントのバージョン管理には、ドキュメントを保存する場所を一元化することが重要です。それにより、異なるバージョンのドキュメントが、複数の場所に分散してしまい、誤ったバージョンが使用されることを防ぐことができま
![[Doc] 要件定義書テンプレート・要件定義書の書き方 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/d7d131e38e26f54466aece3306435a4c09990de8/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCRG9jJTVEJTIwJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgzJTg2JUUzJTgzJUIzJUUzJTgzJTk3JUUzJTgzJUFDJUUzJTgzJUJDJUUzJTgzJTg4JUUzJTgzJUJCJUU4JUE2JTgxJUU0JUJCJUI2JUU1JUFFJTlBJUU3JUJFJUE5JUU2JTlCJUI4JUUzJTgxJUFFJUU2JTlCJUI4JUUzJTgxJThEJUU2JTk2JUI5JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz01MjE0ZDhhMTY1ZjE1ODIxNGE5NzU4Njc3MTNjOTBmNg%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBzeWFudGllbiZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9MTc4MmM0MTlmNzhiYTJjNTk0ODYwZmExZDc0OWYzNjQ%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3Db088349e276a1ebcdb9dcf1e2d753094)
シェルスクリプト (bash, ksh, yash, zsh) で正規表現を使う方法のまとめ - Qiita
はじめに 一部の POSIX シェルには、シェル自体に正規表現対応の機能が含まれており、外部コマンドに依存せずに正規表現による比較を行えます。すべての POSIX シェルで使えるわけではありませんが、シェルに含まれている機能であるため環境の違いを気にする必要はなくパフォーマンスも良いというメリットがあります。しかし正規表現に対応している bash、ksh、yash、zsh で、実装にそれぞれ違いがあります。この記事ではその違いをまとめました。現時点でのそれぞれの最新版である bash 5.2、ksh 93u+m/1.0.3、yash 2.53、zsh 5.9 で動作確認しています。 なお POSIX 正規表現の話や、コマンド（POSIX コマンド・UNIX コマンド）で正規表現を使用する場合の注意点などは「シェルスクリプトの正規表現の詳細解説（令和最新版）〜 基本正規表現(BRE)と拡張正
【実務経験4ヶ月】はじめてのAWS設計・構築で学んだこと【AWS】 - Qiita
AWSの経験、4ヶ月が経ち、振り返ると大変貴重な経験を積ませてもらいました。 SESで本来は即戦力にならなければならないといけませんが 現場のPM、リーダーの方にはとてもお世話になっています。 いくつかタスクが割り振られていますがその中でとても濃い経験になったのは、やはり設計・構築のタスクです。 ある程度、SAAで知っていたものの、実践してみると全く違います。 構成図のパワポから必要なサービスを洗い出し、命名規則から一緒に取り組む経験ができました。 はじめてのAWS設計と構築で僕の覚えている範囲で学んだことをシェアしたいと思います。 どんな環境だったか 今回は開発環境の構築、踏み台サーバをパブリックサブネットに設置 プライベートサブネットに５つのサーバーを設置 もう一つのプライベートサブネットにRDSを設置する。 AZ障害を防ぎたいのでサブネット３つ×AZ２で作成する必要する。 極めてシン
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね？ ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか？ まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか？
DockerでメインフレームOSを動かす - Qiita
HHC01603I * HHC01603I * ************ **** ***** || HHC01603I * ** ** ** ** ** ||| HHC01603I * ** ** ** ** ** |||| HHC01603I * ** ** ** || || HHC01603I * |l _,,,---,,_ ** ** ** || || HHC01603I * ZZZzz /,'.-'`' -. ;-;;, ** **** || || HHC01603I * |,4- ) )-,_. ,( ( ''-' ** ***** || || HHC01603I * '---''(_/--' `-')_) ** ** ** || || |||||||||| HHC01603I * ** ** ** ||||||||||| Update 08 HHC01603I * The M
[Python]生命保険会社の苦情件数を棒グラフで表現 - Qiita
概要 最近、知り合いから生命保険を進められて加入しました。 でも、その保険会社は本当に信用できるのかな？？と思い、このサイトで苦情件数をみてみました。 苦情件数がたくさんあるし、保険会社もたくさんあってわかりづらい… Pythonのmatplotlibを使って苦情件数を棒グラフで表現してみました。 苦情件数（件）を棒グラフで表現 from bs4 import BeautifulSoup import pandas as pd import re import matplotlib.pyplot as plt import requests url = requests.get("https://www.seiho.or.jp/member/complaint/") url.raise_for_status() bs = BeautifulSoup(url.text, "html.pars
![[Python]生命保険会社の苦情件数を棒グラフで表現 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/2991e067381949b413c46912eabe5ff0115d538d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCUHl0aG9uJTVEJUU3JTk0JTlGJUU1JTkxJUJEJUU0JUJGJTlEJUU5JTk5JUJBJUU0JUJDJTlBJUU3JUE0JUJFJUUzJTgxJUFFJUU4JThCJUE2JUU2JTgzJTg1JUU0JUJCJUI2JUU2JTk1JUIwJUUzJTgyJTkyJUU2JUEzJTkyJUUzJTgyJUIwJUUzJTgzJUE5JUUzJTgzJTk1JUUzJTgxJUE3JUU4JUExJUE4JUU3JThGJUJFJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz0wMjY3ZTYyNDg2YzQ5MWY3MjBmYzFjODc0NWYxM2ZlZA%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwa3Vyb190YWtlJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzImdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1kMjgzM2Q0ZDg4NzgzNWM3YWU2MmI1YmY2YTgwNWQxYQ%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3D761d8470dcea1e956c3f75f4eaee0333)
【エンジニアリング組織論への招待】を10~15分で読めるように1万文字程度でまとめてみた - Qiita
■ はじめに エンジニアリング組織論への招待という本を読みました。 ジョブ理論 に続く名著でした。 理想に向けて、事業を最速かつ生産性高く成長させるには、「未来」と「他人」という2つの不確実性をマネジメントすることで、成し遂げられる ソフトウェア開発における不確実性のマネジメントには、不確実性に立ち向かえるチーム開発が何よりも重要である（ex. メンタリング、権限移譲、信頼関係、透明性） の2点を中心に、事業成長×組織の幸せに必要なフレームワークを提供してもらえるものでした。 ソフトウェア関連の事業やプロダクトに関わっている人（特にマネジメントしている人）は職種限らず読むと、みんな幸せになれそうなので、1人でも多くの人がこの概念に触れられるように、私なりの視点で雑多にまとめました。 （ちなみに著者の 広木さん - hiroki_daichi には個別にご連絡し、要約した本記事の公開許可は(
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
