httpとhttpsの違い
TLSの有無 言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2] デフォルポート httpは80、httpsは443です。[3][4] 権威性 以降の説明に入る前に前提を確認します。本稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。 Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5] どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではな
PNGファイル爆発しろ！
まえがき Web上で広く利用されるPNG(Portable Network Graphics)フォーマットは、デジタル画像を変化させずに小さいデータサイズへ変換する圧縮技術の一種です。PNGフォーマットはオリジナル画像を完全復元可能な可逆(lossless)圧縮ですから、JPEGフォーマットのように画像を歪めてしまう非可逆(lossy)圧縮ほどは小さくできません。それでもオリジナルのデジタル画像データの半分程度まではサイズ削減可能な画像圧縮アルゴリズムと言われています。[1] そげぶ いいぜ てめえが何でも思い通りに圧縮出来るってなら まずはそのふざけた幻想をぶち壊す!! （スペース都合によりAA省略） 本記事では、PNGフォーマットを画像データ圧縮(compress)用途で利用するのではなく、オリジナル画像データよりも遥かに巨大なPNGファイル を生成します。 PNGフォーマットでは任意
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
Mac の Docker の x86-64 エミュにプッツンした勢いで、余ったパソコンをリモート Docker サーバーにした
Mac の Docker の x86-64 エミュにプッツンした勢いで、余ったパソコンをリモート Docker サーバーにした ARM Mac で Docker Desktop や Lima を使っていて、 docker build --platform x86-64 .... や docker run --platform x86-64 .... が、いきなりクラッシュしたり、途中まで進むけど特定の箇所でコケたりで困ったことはありませんか。 私はしょっちゅう困ってます。いよいよ我慢の限界になり、部屋でホコリを被ってた x86-64 なパソコンを使ってどうにかすることにしました。 これはホコリをはたいてキッティング中の様子です。 前準備 x86-64 なCPUを搭載したパソコンを調達する Intel でも AMD でもどっちでもいいです。私は手元に転がってた Lenovo M75q-1 を
GitHub を使うなら通知くらいまともに設定してくれ
4 月から新入社員となって本格的にエンジニアとして生活し始めた方も多いかと思います．いままであまり GitHub を使っておらず，会社から要求されてはじめてまともに使い始めた方もいるかもしれません． そんな方々にお願いがあります． GitHub を使うなら通知くらいまともに設定してくれ あなたがこのタイトルを読んでピンときていないのであれば，あなたの通知設定はおそらく間違っています．GitHub は初期設定だと非常に多くの通知を送信します．それは GitHub 自身が通知ページで述べているくらいです． 通知はあなたが思う以上に大切な存在です．必要とする通知は人によって様々であり，それを見逃してはいけないため，ときに GitHub は必要以上の通知を送信しています．しかし，必要以上な通知を受け取ると，人は通知を見ないようになってしまいます． 個人開発ならそれでもよいかもしれません．しかし，あ
「こうしてスクラムが終わってしまう」前にすべきこと
こうしてふりかえりは終わってしまった / A Demise of a retrospective ふりかえりカンファレンスで一番面白かった発表資料です。 資料をざっくり要約すると ふりかえりは最初は順調に機能するがある段階で停滞し、次第に「効果が出ていないもの」と判断されて廃止されてしまう、という話です。 理由として最初は低コスト高リターンの課題を倒していけるが、それらをすべて解決すると残るのは「リターンはあるが、コストが高すぎて解決できない課題」と「コストは低いがリターンもほぼない課題」だけになります。 開発チームは前者を「コストが高すぎて解決できない」と忌避し、後者だけに打ち込んだ結果、リターンが出ずに振り返り事態を無価値を判断してしまうからです。 ふりかえりを廃止することでチームの成長は停止してしまうでしょう。 これを防ぐために「コストが高すぎて解決できない」課題を解決する方向に頑張
Chat GPT-4にDDDのドメインモデルを考えさせたら凄かった件
バックエンド兼インフラエンジニアのrevenue-hackです！ DDD(ドメイン駆動設計)でドメインモデル考えますよね？ その時にGPT-4にやってもらったらどうなんだろう？とふと思い、実際にユースケースからドメインモデルを作ってもらいました！ ↓記事移行しました！↓
ブラウザキャッシュの仕組み
はじめに 最近Denoをよく触っており、DenoのSSRフレームワークであるFreshのミドルウェア・キャッシュについて調べている際にブラウザキャッシュのEtagヘッダが使用されており、気になったのでブラウザキャッシュの仕組みについて調べてみました。 Etagの正体 Etagとは、ブラウザキャッシュの仕組みの中で使用されるHTTPレスポンスヘッダーでリソースの特定のバージョンに関する識別子のことです。 Etagがあることでウェブサーバーは、コンテンツが変更されていない場合はレスポンス全体を再送する必要がないので、キャッシュがより効率的になる。 ブラウザキャッシュの設定について ブラウザキャッシュを設定する際に必要なHTTPレスポンスヘッダーはEtagを含めて以下の通りです。 Expiresヘッダー Cache-Controlヘッダー Last-Modifiedヘッダー Etagヘッダー そ
Dockerについて網羅してみた（ハンズオンあり）
Dockerコンテナの概要と利点 コンテナでぐぐると、「仮想サーバー技術がうんたらこんたら〜」と出てくるが、それは忘れていいというのから衝撃を受けた。笑 それから入る情報が多かったので、（正直意味不だった） 一言で、コンテナとは「互いに影響しない隔離された実行環境を提供する技術」 もっとシンプルに考えていい。難しく考えようとしていた →システムの実行環境を隔離した空間のこと 例）システムAとシステムBは、コンテナがあれば例えば、共通のフレームワークをアップデートしたりしても互い影響はない コンテナの特徴は、「独立」していること（ここで言う独立とは単体で完結していること） １台のサーバーにシステムが複数あっても競合しないこと コンテナを実現するソフトの代表が「Docker」 DockerはLinux上で動作するソフトで、Linuxに「Docker Engine」をインストールするとDocke
iOS(16.4+)を含むブラウザでWeb Push機能を実装したメモ
はじめに 2023年3月末にiOS 16.4がリリースされたことで、ついにすべてのモダンブラウザユーザーに対してWeb Pushを送れるようになりました。 本記事は、筆者が個人開発しているWebサービスでWeb Push機能を実装したときに調べたことや行ったことをメモとして残すものです。Web Push機能の実装を検討されている方の参考になりましたら幸いです。 なお、筆者は外部サービスへの依存をなるべく減らしたかったため、FCMなどのプッシュ通知機能を提供してくれるものはなるべく使わずに実装したのですが、大変だったので基本的には素直にSaaS等を使った方がよいと思います。 注意事項として、筆者はバックエンドに専門性がありません。そのため、何か間違った記述があるかもしれません。特に暗号化周りは理解が甘い点があると思います。もし誤りを発見された場合は優しめに教えていただけると助かります。よろし
【ChatGPT】個人的お気に入りプロンプトまとめ
あなたは、プロの【その分野の専門家】です。 以下の制約条件と入力文をもとに、【出力内容】を出力してください。 # 制約条件： 【前提条件や決まりごと】 # 入力文： 【期待する出力結果や大まかな指示】 あなたは、プロのエンジニアです。 以下の制約条件と入力文をもとに、ブログ記事の内容を出力してください。 # 制約条件： ・重要なキーワードを取り残さない。 ・文字数は30000文字程度 # 入力文： Swaggerについて技術ブログに投稿する文章を書いてください。 構成は、Swaggerとは？、Swaggerのユースケース、Swaggerのメリットとデメリット、Swaggerの書き方（YAMLファイル）、Swaggerの実行方法、まとめです。 構成間で重複した説明は省くようにしてください。 読者がブログを読みながらSwaggerを触れるようにハンズオン形式などを取り入れて文章を作ってください
フロントエンド開発のためのテスト入門 - サンプルの紹介 -
昨年から執筆を続けていた書籍が 4/24 に刊行します。「フロントエンド開発のためのテスト入門」という本です。 書籍ならではのテストコード解説を目指して 次の投票結果は、書籍企画時に持ち込んだ筆者のツイートです。フロントエンドテストに関していえば、8 割近くの方が何かしら不安や不足を感じている、という結果になりました。 不安や不足の原因は様々なものがあるかと思います。そのうち、筆者が着目したのは「テスト手法の豊富さ」です。「単体テスト・結合テスト・E2E テスト、何をどれほど書けばよいのか？」という疑問は、フロントエンドに限らず、はじめて自動テストに取り組まれる方が通る関門ではないでしょうか。 自動テストを書くには「テスト対象」を明確にしたうえで、テスト対象に適したテストコードを書く必要があります。本書は、現場で書かれるものに近い「テスト対象 = アプリケーションコード」をサンプルとして用
PostgreSQLに関するNTTデータのSlideShareのスライドリスト
はじめに SlideShareの広告対策です。 更新履歴 2023/12/13 CloudNative Days Tokyo 2023の資料を追加しました。 2023/12/07 PostgreSQL Conference Japan 2023の資料を追加しました。 2023/11/16 NTTデータで以前使われていたSlideShareのスライドを追加しました。 2024/03/08 第45回PostgreSQLアンカンファレンス@オンライン、DEIM2024の資料を追加しました。 2024/07/09 OCHaCafe Season 8 #4、DSS Asia 2024、TiUG Meetup #2、第47回PostgreSQLアンカンファレンス@オンラインの資料を追加しました。 2024 pg_stat_activityの不可解な観測結果の謎 (第47回 PostgreSQLアンカン
リーダブルコードの要点整理と活用例まとめ
はじめに 最近コードレビューの機会が増えてきたので、「リーダブルコード」を読み直しました。 リーダブルコードを読んでいく中で要点を整理し、実務の現場でコードを書いたりレビューをする際にどのように活用していくべきかを自分なりにまとめてみました。 この記事を読むことで、リーダブルコードの要点の把握と実際の活用例を学ぶことができます。 この記事の主な対象者 リーダブルコードの要点をサクッと知りたい人 初級~中級者(実務歴1~3年目)の人 コードレビューの機会が増えてきた人 これまで我流でコードを書いてきた人 リーダブルコードについて リーダブルコードはあくまで「こう書きなさい」と押し付け口調ではなく「こう書いた方がもっとよくなるよ」といった丁寧な語り口で書かれています。 それを前提として要点や活用方法をまとめていきます。 1章 理解しやすいコード 優れたコードについて リーダブルコードで優れたコ
Docker一強の終焉にあたり、押さえるべきContainer事情
章立て はじめに Docker・Container型仮想化とは Docker一強時代終焉の兆し Container技術関連史 様々なContainer Runtime おわりに 1. はじめに Containerを使うならDocker、という常識が崩れつつある。軽量な仮想環境であるContainerは、開発からリリース後もすでに欠かせないツールであるため、エンジニアは避けて通れない。Container実行ツール（Container Runtime）として挙げられるのがほぼDocker一択であり、それで十分と思われていたのだが、Dockerの脆弱性や消費リソースなどの問題、Kubernetes（K8s）の登場による影響、containerdやcri-o等の他のContainer Runtimeの登場により状況が劇的に変化している。本記事では、これからContainerを利用したい人や再度情報
技術書は気に入った一節を見つけるだけでいい
ということで、私の例をいくつか出してみようと思います。 モノリスからマイクロサービスへ マイクロサービス・アーキテクチャの著者による、モノリスからの移行をガイドするような雰囲気のするこの本ですが、この本は第6章「終わり」にから、この一節です: 他人の事例から学ぶべき教訓があるのは事実だが、自分のコンテキストでうまく機能するアプローチを見つけるには、時間をかけなければならない。 これはあらゆるプラクティスに言えることで、私は事あるごとに「スクラムをそのまま導入するのは無駄だ」とか「守破離っていうやつは苦手だ」とか言い続けているんですが、それはつまり、先人のプラクティスは様々な状況（コンテキスト）があるなかで成功した事例であり、コンテキストが異なる現場に持ち込んでもうまく機能するかは未知なのです。なので、そのプラクティスが前提としているコンテキストとソリューションを理解しつつ、自分たちのコンテ
【仕様の読み方】HTMLの要素をどうやって学ぶか
<search>要素がHTML Standardに追加されました。私も初めて出会う要素になるわけですが、とても良い機会なので、私が要素を調べる際にどうやって調べて学んでいるのかを共有したいと思います。これは新しい要素に限らず、既存の要素の調査に応用できると思います。また、初学者はもちろん、マークアップを生業としている方にも参考になると思います。 新要素追加の経緯を調べる まずはHTML StandardのGitHubのPRからスタートするとよいでしょう。議論や更新はGitHubで行われています。たとえば、今回の<search>はAdd the <search> element #7320というPRによって更新されました。 そもそも更新自体のキャッチアップ方法はクローズされたPRを更新順にして確認してもいいですし、更新のみをツイートしている@htmlstandardのTLを確認してもいいと思
とってもやさしいフロントエンド入門
まず、新しいアイデアが提案されると、ステージ0の「Strawman」と呼ばれる段階に入ります。ステージ0のアイデアが価値のある提案として見なされ、大まかな形で問題点や解決策を説明できるようになると、ステージ1の「Proposal」と呼ばれる段階に進みます。そして、提案がある程度まとまって仕様の草案として認められると、ステージ2の「Draft」と呼ばれる段階に上がります。さらに細かいところまで練り上げられて、仕様がほぼ完成した状態になると、ステージ3の「Candidate」の段階になります。最後に、2つ以上のブラウザがその機能を実装していて、ECMAScript の編集者に承認されると、ステージ4の「Finished」と呼ばれる段階になります。 ステージ4に上がった提案は、毎年 6 月のタイミングで ECMAScript の新しいバージョンとしてリリースされます。リリースする際は、ECMAS
あなたのPythonを100倍高速にする技術 / Codon入門
はじめに Pythonは世界的にも人気のあるプログラミング言語ですが、実行速度については課題があります。Pythonの実行速度を高速化したい、という要求は根強く、これまでにも様々なツールや処理系が開発されています。 この記事ではMITの研究者らが開発したPythonを高速化するツール「Codon」について紹介します。 この記事を3行でまとめると： 高性能で簡単に扱えるPythonコンパイラ「Codon」 Pythonとの互換性がありながら、CやC++に匹敵する高速化を実現 実際にPythonコードが100倍速くなることを検証 Codonとは Codonは高性能なPythonコンパイラです。実行時のオーバーヘッドなしにPythonコードをネイティブなマシンコードにコンパイルし、シングルスレッドで10-100倍以上の高速化が実現できます。Codonの開発はGithub上で行われており、2021
大塚流フロントエンド開発の歩き方
フロントエンド開発は考えることが多い。とくに 0 -> 1 の場合だと、何からはじめたらいいのか？が全然わからず、途方にくれてしまうこともあるでしょう。実際、ぼくがそうでした。 そして、そういった情報はなかなか検索しても出てこない。設計方法や実装方法みたいなものはたくさんあるのに。なので、書いてみました。 これは、ぼくがいくつかのフロントエンド開発を経て「これを最初に知っていれば、もうちょっとうまくできたかも？あの失敗がなかったかも？？」をまとめたものです。 フロントエンド開発に不慣れな方の参考になれば、これ幸いです。 まずは仕事のゴールを確認する プロジェクトや各フェーズごとに仕事のゴールは異なるため「何をもって仕事が完了したと言えるか？」を確認する。たとえば、要件定義フェーズであれば「画面仕様書が完成する」とか、開発フェーズであれば「API結合試験がすべて完了し、バグチケットがすべてク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
