並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 20 件 / 20件

新着順 人気順

サーバの検索結果1 - 20 件 / 20件

  • ブラウザキャッシュの仕組みについてまとめた

    Web開発において、ページの読み込み速度は非常に重要になります。 そのためにもブラウザのキャッシュは効率的なWebサイト運営に不可欠な機能です。 ブラウザのキャッシュには次のHTTPヘッダを設定することができます。 Expiresヘッダ Cache-Controlヘッダ Last-Modifiedヘッダ ETagヘッダ これらのキャッシュには強いキャッシュと弱いキャッシュで分類が可能です。 「Expires」「Cache-Control」は強いキャッシュであり、「Last-Modified」「ETag」は弱いキャッシュに分類できます。 強いキャッシュと弱いキャッシュ 強いキャッシュは設定された期間内は完全にローカルキャッシュを利用して、サーバーへのリクエストを行いません。 一方で弱いキャッシュはキャッシュされたリソースの検証が必要であり、ETagやLast-Modifiedヘッダを利用して

      ブラウザキャッシュの仕組みについてまとめた
    • ジャック・ドーシー、Blueskyからの離脱は「Twitterと同じ過ちを繰り返しているから」とインタビューで述べる | テクノエッジ TechnoEdge

      ガジェット全般、サイエンス、宇宙、音楽、モータースポーツetc... 電気・ネットワーク技術者。実績媒体Engadget日本版, Autoblog日本版, Forbes JAPAN他 Twitterの共同創業者で、現在は決済サービスBlockを率いるジャック・ドーシー氏は、最近Blueskyの取締役会から降りた理由として「(Twitterが犯してきた)あらゆる過ちを繰り返しているから」だと語りました。 ドーシー氏はTwitterの歴史のごく初期に、営利企業としての都合や、広告主など外部の力で運営方針を左右されることのない、オープンソースのプロトコルとしてのTwitterを構想していました。 しかし、Twitterが成長していくにつれ、違法コンテンツなどのモデレーションやユーザーのアカウント凍結といった対応が必要となり、オープンで分散したネットワークという方向性に舵を切るのは難しくなります。

        ジャック・ドーシー、Blueskyからの離脱は「Twitterと同じ過ちを繰り返しているから」とインタビューで述べる | テクノエッジ TechnoEdge
      • サーバーレスの次はなんなんだ

        はじめに この記事は、同人誌サークル「めもおきば」から不定期刊行している技術解説本「めもおきばTecReport」に書いたものを公開用に再編集したものです。 ⇒ めもおきばTecReport 2023.12 この記事のほかにも「私もSecHack365に参加したい!」や、「2023年振り返りと2024年技術予想」としてこんなキーワードを取り上げているので、気になったらぽちっとしてください! メガクラウドと特化型クラウド/ハイパーバイザーのSoC化/ライセンスとクラウドベンダー/イベント駆動型API/LLM時代のAIペアプロ力/生活必需品としてのGPU・NPU/Passkey/ウェブアクセシビリティ/リアルイベントの再開 サーバーレスの次はなんなんだ サーバーレスと呼ばれる技術ムーブメントが盛り上がり始めて8年近くが経ちました。各クラウドベンダーのFaaS(Function-as-a-Ser

          サーバーレスの次はなんなんだ
        • 北朝鮮、日本アニメ制作関与か サーバーからファイル―米分析:時事ドットコム

          北朝鮮、日本アニメ制作関与か サーバーからファイル―米分析 時事通信 外信部2024年04月23日10時10分配信 北朝鮮国旗(AFP時事) 【ワシントン時事】米国の北朝鮮分析サイト「38ノース」は22日、日本や米国のアニメ制作に北朝鮮のアニメーターが関与した疑いがあると明らかにした。北朝鮮が管理していたとみられるクラウドサーバーに、これらアニメの関連ファイルなどが保管されていたという。 北朝鮮技術者が成り済ましか IT業界団体に注意喚起―警察庁など 38ノースによると、関与が疑われるのは、7月放送予定のTVアニメ「魔導具師ダリヤはうつむかない」のほか、米アニメ「インビンシブル」などの作品。札幌市のアニメ制作会社の名前が入ったファイルもあったという。 サーバーからは、中国語や朝鮮語のコメントが記載されたアニメの画像などが見つかった。解析した米シンクタンク「スティムソン・センター」のマーティ

            北朝鮮、日本アニメ制作関与か サーバーからファイル―米分析:時事ドットコム
          • 自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理

            切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React

              自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
            • 社内で検知された悪性通信を調査したらドメインパーキングだった話 - NTT Communications Engineers' Blog

              こんにちは、イノベーションセンターの冨樫です。Network Analytics for Security プロジェクトに所属しています。 突然ですが皆さんはドメインパーキングというサービスを知っているでしょうか?詳細については後述しますが、以前イノベーションセンターの検証網でマルウェアに関する悪性通信が検知されたため通信先を調査したところ、ドメインパーキングだったことがあります。本記事ではこの調査を通して得られたドメインパーキングに関する知見とその調査過程を紹介します。また、今回紹介するドメインパーキングの悪用事例や外部インテリジェンスを活用した調査は基礎的な内容ですので、本記事は主に初学者の方の知見にしてもらうことを目的としています。 ドメインパーキングについて アラートの概要 Ursnif について 接続先についての調査 検知されたアラートの危険性について さいごに ドメインパーキン

                社内で検知された悪性通信を調査したらドメインパーキングだった話 - NTT Communications Engineers' Blog
              • LINEヤフー、韓国ネイバーとの委託関係を終了へ PayPayとLINEのアカウント連携も延期に

                情報漏えいを受け、LINEヤフーが韓国NAVERへの業務委託の終了を決めた。5月8日に開かれた2023年度通期・第4四半期決算会見で明かしたもので、LINEヤフーが2024年度中と進めていたLINEとPayPayのアカウント連携についても、社内のセキュリティガバナンス強化の優先を理由に計画時期を見直す。 LINEヤフーは、23年10月に不正アクセスによる情報漏えいが発生したと発表。情報流出は、同社と韓国の関連会社NAVER Cloud委託先企業の従業員PCがマルウェアに感染したことをきっかけに、NAVER CloudのADサーバも感染。その管理者権限や、LINEヤフーのADサーバの認証情報が奪取され、不正アクセス被害につながったとみられている。 この件に関し、LINEヤフーは24年3月に総務省から行政指導を受けており、同社は4月に報告書を提出。NAVERのシステムとの分離を進める他、「NA

                  LINEヤフー、韓国ネイバーとの委託関係を終了へ PayPayとLINEのアカウント連携も延期に
                • 開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog

                  こんにちは。Findy Freelanceの開発チームでエンジニアをしている2boです。 この記事では私が開発生産性を上げるために開発をする前に考えていることについて書きます。 ここで「開発をする前」というのは次のようなタイミングを指します。 PdMなどから新規施策の仕様について相談を受けたとき 起票された開発Issueを最初に確認するとき 自分がIssueを作成するとき なぜこのタイミングで考えるかというと、開発を進める上での方向性を間違える可能性を減らし後から軌道修正をしやすくするためです。 なおこの記事においては、開発生産性を「開発成果物の提供価値を投入リソースで割ったもの」とします。 いくら頑張って開発をしても、そもそもやるべきことの方向性を大きく間違えると提供価値が0に近づくため開発生産性が低下します。 特に開発が高速なチームで方向性を誤ると高速に間違った方向へ進んでしまうことに

                    開発生産性を上げるために開発をする前に考えていること - Findy Tech Blog
                  • WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が

                    WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が整っているわけではないです。 徳丸先生は、一般的な開発者には最低限どのレベルのセキュリティ知識を求められていますか? 回答の難しい質問ですが、ここは本音をさらけ出したいと思います。 私が「安全なWebアプリケーションの作り方(通称徳丸本)」を出したのが2011年3月でして、それから13年以

                      WEBアプリケーション開発者です。 特別セキュリティのスペシャリストになりたいというわけでないですが、アプリケーション開発者として徳丸本に記載されている内容レベルのセキュリティ知識はあります。 システムのセキュリティに関してはベンダーの脆弱性診断を通して運用しており、個人的にはセキュリティに関して何か困ったことがいままでありません。 ただ、ふと考えてみると「情報漏洩やサイバー攻撃が発生した際などの有事にどのような行動をとるべきか」という観点ではあまり自信がないなと感じました。社内でもそのような場合の指針が
                    • 「情シス担当者がいなくなってサーバーやネットワーク機器を管理する人がいないので皆さんで管理しましょう」→斬新すぎる管理方法だった

                      Shadowhat @shadowhat HAGIWARA Takahiro (仮想化プリセエンジニア) 主にNutanix、最近M365、時々Linux、稀にネットワークな日々 発言は個人の見解であり、所属する企業の見解や意見を代表するものではありません。 Nutanix Technology Champion 2018-2024 infraapp.blogspot.jp Shadowhat @shadowhat 「情シス担当者がいなくなって社内のサーバーやネットワーク機器を管理する人がいないので皆さんで管理しましょう。」 といって、社内全員にAdministrator権限のユーザ名とのパスワードを共有する斬新な管理方法を聞いた。 なお、SIでソフトウェア開発をやっている会社さんだそうで。。。 2024-05-08 09:04:29

                        「情シス担当者がいなくなってサーバーやネットワーク機器を管理する人がいないので皆さんで管理しましょう」→斬新すぎる管理方法だった
                      • 中高生600万人に無償でサーバー環境を提供、Xserver

                          中高生600万人に無償でサーバー環境を提供、Xserver
                        • 弊社サーバーのマルウェア感染に関する お詫びとお知らせ – Endless Corporate

                          この度、本社サーバーがコンピュータウイルス「LockBitランサムウェア 」に感染しました。 今回の不正アクセスの直接の原因は、セキュリティ強化の一環で FortiGate(統合型セキュリティアプライアンス)の設置を昨年に依頼しましたスターティア株式会社(https://www.startia.co.jp/)が設置の際に使用していた test アカウントを削除せずそのまま放置し、悪意のある第三者が test アカウントを使用して弊社のサーバーに侵入した事によるものとなります。 なお、現時点では、社内情報の流出の事実は確認されておりません。また、被害サーバーにはお客様情報は入っておりません。 関係する皆さまには、多大なご迷惑とご心配をおかけすることとなり、心よりお詫び申し上げます。 対応としましては、感染が判明した当該サーバーをすべてネットワークから遮断する対策を講じるとともに、弊社全部署で

                          • 巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32

                            (WIP まとまったら Qiita とかに上げるかも) TLDR; 「React と Next.js を比較」という記事で、 Next.js と比較できるのは「フレームワークなしで React を使うという選択肢」であって、「React そのもの」ではない。 ✅️ React を使うのに 「フレームワークあり」 vs 「フレームワークなし」 ❌️「React」 vs 「Next.js」 それはそうと、「create-react-app の機能・特徴」のことを、「React の機能・特徴」であるかのように書いてしまっている記事が多い create-react-app 自体が擬似的なフレームワーク(といえそう) そもそも、create-react-app は今は更新されてないので create-vite-app を使うべき フレームワークあり or フレームワークなし 【フレームワークあり】

                              巷の「ReactとNext.jsの比較」はここがおかしい、というか比較すること自体が微妙 - honey32
                            • Prisma ORMを2年運用して培ったノウハウを共有する

                              TSKaigi 2024 ref: https://tskaigi.org/talks/tockn

                                Prisma ORMを2年運用して培ったノウハウを共有する
                              • AWS Security HubとSlackを利用して、セキュリティ状況の監視運用を効率化したお話 - Uzabase for Engineers

                                はじめに 初めまして!ソーシャル経済メディア「NewsPicks」SREチーム・新卒エンジニアの樋渡です。今回は「AWS Security Hub」と「Slack」を用いて、弊社で利用しているAWSリソースの監視運用を効率化したお話です。 お話の内容 年々増加するサイバー攻撃に対抗するため、セキュリティ対策は日々重要度が増してきています。 そこで弊社で利用しているAWSのリソースに対して、各種セキュリティイベントの収集ができるAWS Security Hubを利用することで、セキュリティ状態の可視化と迅速な対応がしやすい運用を行い、セキュリティ状態の現状把握から始めることにしました。特にNIST CSFの「検知」部分の運用について整備した内容となっています。 NIST Cyber Security Frameworkについて 皆さん、「NIST Cyber Security Framewo

                                  AWS Security HubとSlackを利用して、セキュリティ状況の監視運用を効率化したお話 - Uzabase for Engineers
                                • 信号機に“異変”!? 更新先延ばし 撤去 新設見送り 背景には「コスト削減」 千葉の現場から | NHK

                                  私たちの生活に身近な「信号機」。全国に設置されているのは約20万基にのぼりますが、いま、“異変”が起きています。 各地で撤去が進み、新設の要望が通りにくくなっています。また、更新の目安を超えて運用されるケースも増加しています。 交通安全の「要」と言える信号機に、何が起きているのでしょうか。 (千葉放送局記者・池田侑太郎) 老朽化の信号機 更新を先延ばしに 2024年2月、千葉県市川市の県道の交差点で行われていたのは、信号機を更新する作業です。 古くなった赤・青・黄色の「灯器」や、点灯の調整を行う「制御器」などが新品に取り替えられました。 信号機の「制御器」 この制御器、設置されたのは25年前。しかし、国が故障の確率などから定めている更新目安は「19年」です。5年余り更新を先延ばしして、運用されていました。 作業員 なぜ? 更新先延ばしの背景は 千葉県内にある信号機は約8500基。このうち、

                                    信号機に“異変”!? 更新先延ばし 撤去 新設見送り 背景には「コスト削減」 千葉の現場から | NHK
                                  • 止まらないLinuxシステムを構築する_高信頼性クラスタ入門

                                    止まらないLinuxシステムを構築する!高信頼性クラスタ入門 クラウド、オンプレどちらの環境でも障害は不意にやってきます。 そんなときもサービスを継続提供するためのHAクラスタ。 今回は高信頼性を実現するクラスタの考え方の基本から、具体的にLinuxクラスタを設計/構築するコツについて解説します! こんな方にオススメ ・Linux初心者の方 ・Linuxが好きな方 ・高信頼性、高可用性クラスタに興味ある方

                                      止まらないLinuxシステムを構築する_高信頼性クラスタ入門
                                    • Go、Rust、Pythonで実装したAPIサーバーの負荷試験比較 - Qiita

                                      はじめに みなさん様々な言語でAPIサーバーを立てて負荷試験を実施したことはありますか。 私自身、業務でPythonのアプリケーションに対して負荷試験を実施した経験があります。 その際にPythonの速度観点の不安定さを目の当たりにしたと同時に、別の言語ではどのような違いが生まれるのだろうか、という疑問を持ちました。 そこで今回は、簡単ではありますがGoとRustとPythonでそれぞれAPIサーバーを立てて負荷試験をしてみます。 負荷試験対象のAPIサーバー 今回は(1) Hello, World!を返すAPI(2) ファイル読み込みAPI(3)1秒待ってから応答するAPIの3つを実装します。 (1)はAPIサーバー自体の応答速度の計測、(2)はメモリを消費する処理が生じた場合のAPIの応答速度の計測、(3)は待ち時間発生している時のAPIの応答速度の計測することが目的です。 (2)につ

                                        Go、Rust、Pythonで実装したAPIサーバーの負荷試験比較 - Qiita
                                      • TypeScriptとGraphQLで実現する型安全なAPI実装

                                        この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信(今回はこれをAPIと呼びます[1])などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取

                                          TypeScriptとGraphQLで実現する型安全なAPI実装
                                        • ぼくのかんがえたさいきょうのGo HTTPサーバー起動方法

                                          これまで何度か HTTP Server の Graceful Shutdown について記事を書きました。 Go 言語で Graceful Restart をする Go 言語で Graceful Restart をするときに取りこぼしを少なくする Go1.8 の Graceful Shutdown と go-gracedown の対応 最終的に Go 1.8 で Server.Shutdown が導入され、この件は解決を見ました。 しかし、最近「あれ?本当に正しく Server.Shutdown 使えている?」と疑問に思い、少し考えてみました。 というか ↑ の記事もまだ考慮が足りない気がする。 ぼくのかんがえたさいきょうの Go HTTP サーバー起動方法 とりあえず完成形のコード。 package main import ( "context" "log" "net/http" "os

                                          1