並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 5 件 / 5件

新着順 人気順

browserの検索結果1 - 5 件 / 5件

  • FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 レバテックラボ(レバテックLAB)

    FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 2024年5月7日 ダットジャパン株式会社 「エアホッケー@GAMEPACK」ブラウザ版 開発ディレクター/プロジェクトマネージャー 新田 大手ゲーム会社にて約7年ゲーム開発に携わった後、2020年に、建設分野を中心にソフトウェア開発を手がけるダットジャパン社に入社。エンジニアとしての知見やスキルを生かし、プロジェクトマネジメント・営業・マーケティングなどを幅広く担当。今回は「エアホッケー」の主人公である「ゆうた」のアイコンにて出演。 ダットジャパン株式会社公式サイト 2000年ごろから2010年代にかけて、富士通・FMVシリーズのパソコンには購入時のバンドル(同梱)ソフトとして「GAMEPACK(ゲームパック)」というミニゲーム集が付属していました。中でも「エアホッケー」は、現在でもYouTu

      FMV同梱「エアホッケー」がブラウザ版で復活した経緯とは?ソースコードもない状態からの移植秘話 レバテックラボ(レバテックLAB)
    • Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io

      Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛

        Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
      • Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog

        Cookieの改訂版仕様 rfc6265bis について、その変更点をざっと眺めていく はじめに SameSite属性 Cookie名プレフィックス (Cookie Name Prefixes) __Secureプレフィックス __Hostプレフィックス 非セキュアなオリジンからの Secure属性の上書きを禁止 nameless cookieの許容 Cookie名、Cookie値の上限長の指定 Expires属性の年が2桁の場合の処理の指定 Max-Age/Expires の上限 その他 今回入らなかった機能 はじめに Cookieの仕様は『RFC 6265: HTTP State Management Mechanism』として標準化されています。 そのCookieの仕様の改訂版が『rfc6265bis』と呼ばれているもので、現在標準化作業が進められいています。"SameSite属性"

          Cookieの改訂版仕様 rfc6265bis の変更点 - ASnoKaze blog
        • HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか(と思ってブラウザ拡張を作ってる)

          HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか(と思ってブラウザ拡張を作ってる) これまでの何年間か、Webアクセシビリティまわりのことをやってきた中で、「Webアクセシビリティに取り組む」上でいろいろな障壁を感じてきました。 「なぜWebアクセシビリティをやるのか」の理解を得る・得てもらうまでの障壁 イノベーター層・アーリーアダプター層な開発者(エンジニアやデザイナー)が取り組みを始める上での障壁 マジョリティ層が取り組みを始める上での障壁 今回はこの3つめの「マジョリティ層が取り組みを始める上での障壁」の話です。 残りの2つについては、私が執筆に参加したWebアプリケーションアクセシビリティが網羅的なガイドになってくれるはずです。しかしコイツは内容的にも物理的にもゴツすぎる問題があると思っていて、導入編としては見えにくい、読みにくい

            HTMLを直接読み書きせず、スクリーンリーダーも使わずに、アクセシビリティを向上させられないだろうか(と思ってブラウザ拡張を作ってる)
          • Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io

            Intro Referrer-Policy は、送信される Referer の値を制御することが可能だ。 このヘッダの副次的な効果をよく理解していないと、「no-referrer にして送らないのが最も安全だ」という誤解を生むことになる。 では、複数あるポリシーの中でどのような観点で、どのディレクティブを採用するのが良いのだろうか? 前提として前回の記事の「リクエストの出自をチェックすることは現代の実装のベースプラクティスである」という点を踏まえて考えてみる。 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io https://blog.jxck.io/entries/2024-04-26/csrf.html Referer とアナリティクス Referer は、リクエストに対してその前のページの URL を送るところから始まった。 GET / H

              Referrer-Policy の制限を強めると安全になるという誤解 | blog.jxck.io
            1