いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。｜Fritz | Lead Product Manager @ Mercari
いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。 こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。 PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。 ということで、今回は ・ 良い仕様書がもたらす 5 つの効果 ・ 仕様書の重要性が増していく 2 つの理由 ・ 仕様書に含めたい 14 の項目・実戦編 ・ 仕様書作成時に心に留めたい 3 つのこと ・ 具体的な仕様書サンプル（
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
API 設計: gRPC、OpenAPI、REST の概要と、それらを使用するタイミングを理解する | Google Cloud 公式ブログ
※この投稿は米国時間 2020 年 4 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。 ほとんどのソフトウェア デベロッパーがご存じだと思いますが、API 設計には RPC と REST の 2 つの主要なモデルがあります。モデルに関係なく、ほとんどのモダン API は、なんらかの方法で同じ HTTP プロトコルにマッピングすることによって実装されます。また、RPC API 設計では、RPC モデルの範囲から外れずに HTTP から 1 つまたは 2 つのアイデアを採用することが一般的になっています。これにより、API 設計者に提示されるオプションの範囲が広がりました。この投稿ではこれらのオプションについて説明し、どれを選ぶか決める際に役立つガイダンスを提供します。 gRPC は RPC API を実装するためのテクノロジーで、HTTP 2.0 をその基盤
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。 「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。 レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている
ワクチン予約のクソシステムについての私見
5/18 追記色々情報が出てきたので答え合わせ。 前提として、 接種番号は自治体が発番する。そのため、このシステムは、入力された接種番号が正しく存在する番号かどうかさえ確認するすべはない（形式的に間違っている番号はわかる）。 接種番号は自治体が発番するため、接種番号と接種者の情報を紐付けられるのは自治体のみ。接種番号に対応する郵便番号や生年月日も、このシステムはわからない。 接種券は、このシステムが開発着手する前から印刷されていた。チェックディジットやハッシュは、その時点で接種番号の仕様に含まれていなかった。 大規模接種会場の予約システムなんて話が裏で進められ始めたのが今年の1月。接種券の印刷・送付の通達が出たのは去年の12月。 その通達では、券番号として、自治体内で一意であることしか定められていなかった。 このシステム、ひいては大規模接種の目的は、早期にワクチン接種を完了させること。 し
JavaScriptの仕様はECMAScriptで、ECMAScript 2015（ES2015）、ECMAScript 2016（ES2016）...というように毎年進化を続けています。 これまでの仕様はES2021でした。 本日6月22日、ES2022は正式仕様として承認され、ES2022が最新仕様となりました。 22.06.2022 Ecma International approves new standards - Ecma International ブラウザ対応も完了しており、全モダンブラウザ（Google Chrome・Firefox・Safari・Microsoft Edge）でES2022の全機能が使えます。 本記事では、ES2022すべての新機能を紹介します。「何が使えるようになったのか？」「どうしてそれが必要だったのか？」が、できるだけわかりやすいように解説しました
あくまで有効日数はW3C仕様の名目上のステータスであり、参考情報にしか過ぎないわけですが、HTML5とそれよりも前に策定された(X)HTML仕様は、2018年3月に一斉に廃止され、HTML Review Draftと入れ替わるタイミングでHTML 5.1とHTML 5.2が同時に廃止されました。Second Editionを含んでいますが、HTML5シリーズがいずれも勧告から3年で廃止されているのは何とも興味深いところではあります。 また、古い話ですが、当時HTML5のEditorを務めていたHixieことIan Hickson氏が2008年に「HTML5の完成は2022年ごろになる」と発言していたことがありました（HTML5の完成は2022年！？ | Web標準Blog | ミツエーリンクス）。2012年にW3CとWHATWGのHTMLが分裂[1]し、結局今年になってWHATWG HTM
はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の
2019年9月5日，日本最大のゲーム開発者会議CEDEC 2019の2日めにバンダイナムコ研究所の森口明彦氏から，「芯（シン）・遅延対策2020 〜ヒトのスペックから導かれる安定性重視とフレームレートのベストプラクティス」と題する講演が行われた。 ゲームの体験で大きな問題になりうる「遅延」については，CEDECでもたびたび取り上げられ，森口氏も何度かCEDECで講演を行っている。遅延はプレイヤーの操作から画面に反映されるまでの時間差のことを指すものだが，今回の講演では，プレイヤー側の事情に踏み込んでどの程度の対策が必要とされているのか，どの程度の対策があれば十分なのかなどについて定量的な分析と考察が披露されたので，そのあたりを中心に紹介してみたい。 ゲームの処理サイクル（左）と人間の処理サイクル（右）。それぞれが一定の周期で処理を進めている 人間に対する視覚や聴覚の処理は小脳の運動中枢の一
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
Intro 10 年ほど前に同じことを調べたことがある。 なぜ html の form は PUT / DELETE をサポートしないのか? - Block Rockin' Codes https://jxck.hatenablog.com/entry/why-form-dosent-support-put-delete 当時は全くの素人で、素人なりに調査はしたが、ほとんどが推測の域を出ない結論だった。 この問題についてあらためて記す。 仕様策定の経緯 表題の通り、 <form> の method には GET と POST しかサポートされていない。 HTTP には他にも PUT や DELETE といったメソッドもあるのに、なぜサポートされていないのかという疑問から始まった。 仕様が決定した経緯は、以下に残っている。 Status: Rejected Change Descriptio
W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」（分散型識別子）の仕様が勧告に到達
W3C、中央集権的な管理を不要にする「Decentralized Identifiers (DIDs)」（分散型識別子）の仕様が勧告に到達 World Wide Web Consortium (W3C)は、「Decentralized Identifiers (DIDs) 」（分散型識別子）バージョン1.0（以下、W3C DID）の仕様が勧告に到達したと発表しました。 W3C press release: "Decentralized Identifiers (DIDs) v1.0 becomes a W3C Recommendation" "This new type of verifiable identifier... will enable both individuals and organizations to take greater control of their onl
先日、このようなツイートを書きました。 久しぶりの JavaScript クイズ。 JavaScript において NaN === NaN の結果は次のうちどれになるでしょうか？ — Takuo Kihira (@tkihira) September 7, 2021 答えは 4 の「状況によって上記以外もありうる」です。でも、2 や 3 を選んだ方も、もはや正解だといって差し支えないと思います。 解説が長くなったので、ブログ記事にまとめました。 そもそも NaN とは NaN は “Not a Number” を意味する数値です。数値なのに「Not a Number」というのは違和感があるかもしれませんが、数値表現することが出来ない状態を保持するために便宜的に用意された数値、というようなものです。 NaN は、浮動小数点演算において数値では表現出来ない計算をしようとすると登場します。例えば
Kazuho Oku on Twitter: "HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn"
HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
「実はUSB Type-C端子には表裏がある」 Twitterで話題の豆知識、PC周辺機器メーカーに詳細を聞いた
「USB Type-C端子には、実は表裏が存在する」という豆知識が、Twitterで話題です。どちら向きで挿しても接続できるのがType-Cの利点だけど、表か裏かで違いが出る……？ 他のUSB規格とは異なり、表裏のどちらからでも挿せるType-C端子（画像はWikipediaより） Type-C端子にはピンが2列に12ずつ配されています。基本的には同じ役割を持つピンがペアとなって点対称で配列されているため、裏返しでも接続できるわけですが、話題を呼んだツイートは「完全な対称ではない」と指摘。確かに、Type-Cの規格を確認すると、片方の役割が若干異なる、特殊なペアが1組みられます。 Type-C端子（オス側）のピン配列（画像はWikipediaより）。A2とB2のように同系統のペアが点対称形で配されているが、A5とB5のみ、B5がA5とは別の役割も担う特殊な組み合わせとなっている（B6とB7
仕様起因の脆弱性を防ぐ！開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク
<search>要素がHTML Standardに追加されました。私も初めて出会う要素になるわけですが、とても良い機会なので、私が要素を調べる際にどうやって調べて学んでいるのかを共有したいと思います。これは新しい要素に限らず、既存の要素の調査に応用できると思います。また、初学者はもちろん、マークアップを生業としている方にも参考になると思います。 新要素追加の経緯を調べる まずはHTML StandardのGitHubのPRからスタートするとよいでしょう。議論や更新はGitHubで行われています。たとえば、今回の<search>はAdd the <search> element #7320というPRによって更新されました。 そもそも更新自体のキャッチアップ方法はクローズされたPRを更新順にして確認してもいいですし、更新のみをツイートしている@htmlstandardのTLを確認してもいいと思
以下はMostafa Gaafarによる記事、7 New Exciting JavaScript Features You Need to Knowの日本語訳です。 7 New Exciting JavaScript Features You Need to Know JavaScript ( ECMA Script ) は進化する言語であり、たくさんのproposalやアイデアが出番を待ち受けています。 TC39 (Technical Committee 39) という委員会がJavaScript標準と新機能の定義を担当しています。 そして今年は彼らの活動が活発になっています。 以下は、現在ステージ3にある提案の一部の紹介です。 ステージ3は完成する直前の段階です。 これはつまり、この機能がブラウザやその他のJavaScriptエンジンにすぐに実装されることを表しています。 実際、以下の
逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
Goの言語仕様書精読のススメ & 英語彙集
この記事について Go言語公式から提供されているThe Go Programming Language Specificationという文章があります。 実際のThe Go Programming Language Specificationのページ画面 この文章、個人的にはじっくり読んでみると結構得るものが大きいな、と感じるものです。本記事では The Go Programming Language Specificationって何が書いてあるの？ 読んだら何がわかるの？ 読むときにはどういうところに注目したらいいの？ 英語難しいから単語教えて！ という疑問に答えながら、The Go Programming Language Specification精読の布教を行います。 The Go Programming Language Specification とは？ The Go Prog
処理中のPOSTリクエストを別のサーバで引き継ぐPartial POST Replayについて - ASnoKaze blog
なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。 スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。 やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。 「HTTP Partial POST Replay」では、ユーザの接続
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
現在、 JavaScript の MIME タイプは2006年4月に公開された RFC 4329(www.rfc-editor.org) にて text/javascript (OBSOLETE) application/javascript (COMMON) text/ecmascript (OBSOLETE) application/ecmascript (COMMON) の4つが定義されています。 この RFC 4329 では text/* の2つは OBSOLETE 扱いな一方で、 JavaScript を呼び出す HTML の仕様では HTML5 以降、 <script> 要素の type 属性を省略することが推奨 されたうえで、省略時の値は text/javascript である とされました。 このように RFC 側と HTML 側で矛盾が生じる事態が長い間続いています。 実
はじめに gcc v12.1において、C++の正規表現ライブラリstd::regexに、正規表現のバリデーションを改善するパッチ(以下"改善パッチ"と表記)が取り込まれました。改善パッチによって、これまではバリデーションにひっかからなかった不正な正規表現文字列が"正しく"不正なものと認識されて例外が発生するようになりました。 これだけ聞けばいいことだけのように思えるかもしれませんが、実はそうでもなかったりします。経験豊富なかたであれば見た瞬間ゾッとしたかもしれません。本記事では、この一見問題なさそうな改善パッチによって発生しうる問題、および、その具体的例について紹介するとともに、この手のパッチを当てるかどうかは難しい判断になるという知見を共有します。 結論 改善パッチによって発生する問題 発生条件 gcc v12.1以降、あるいは改善パッチをバックポートされた任意のバージョンを使ってC++
IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利
みなさん、Optional Chaining使ってますか？ 私は先日出たTypeScript 3.7 Betaを小さいプロジェクトに導入して使ってみました。これはとても快適ですね。 例によって、Optional ChainingはECMAScriptに対するプロポーザルの一つです。つまり、もうすぐ入りそうなJavaScriptの新機能です。プロポーザルはたくさんの種類がありますが、その中でもOptional Chainingはその高い有用性からこれまで多くの注目を集めてきました。Optional Chainingは2019年6月のTC39ミーティングでStage 3に上昇し、いよいよ正式採用が近く期待も高まってきたところです。TypeScript 3.7にも導入されたため、TypeScriptユーザーの方々は11月上旬に正式リリースが予定されているTypeScript 3.7を今か今かと待
JavaScriptの文字列や配列は最長でどこまで格納できるか、気にしたことはありますか？関数は何個まで引数を取れるのでしょうか？ブロックのネストは何段まで？ この記事では、そんな素朴な疑問に答えてみます。 テストに使った環境は、 macOS 12.3.1 (Arm64) Node.js v17.7.2 Firefox Nightly 102.0a1 (2022-05-29) です。当たり前ですが、この記事に載せる数値は環境によって変わる可能性があります。 テストに使ったスクリプト類は https://github.com/minoki/javascript-limits に置いてあります。 文字列の長さ まずは文字列の長さです。 規格には The String type is the set of all ordered sequences of zero or more 16-bit
最速攻略！ Reactの `use` RFC
皆さんこんにちは。最近のReact界隈で話題になっているのは次のRFCです。 そこで、この記事ではさっそくRFCを理解することを目指します。 ただし、このRFCはSuspenseに深く関わるものです。SuspenseはReact 18でもう正式リリースされていますから、この記事ではSuspenseは前提知識とします。もしまだSuspenseをよく知らないのであれば、ぜひ次の記事で学習してください。 また、RFCはあくまでReactの新機能のアイデアを公開するものであり、これが必ず実装されるとは限らない点にご注意ください。例えば、過去にはuseEventというRFCが注目を集めていましたが、意見が集まった結果としてそのRFCは実装されずにクローズされました（RFCが無駄だったというわけではなく、再度検討してよりアイデアがブラッシュアップされることになります）。 新しい use API このR
2020年1月に入社し、SWETの仕様分析サポートチームに加わったtakasek（@takasek）です。 仕様分析サポートチームでは、社内のプロダクト開発に対する形式手法の活用可能性を模索しています。当ブログでも、継続的に形式手法に関する情報発信をしています（形式手法 カテゴリーの記事一覧）。 この記事では、加入3か月を経てようやく形式手法の輪郭が掴めてきた私の視点から、学習前後での理解の変化について振り返ります。想定読者として学習前の私と近い属性——すなわちコンピュータサイエンスや数学の専門教育を受けておらず、主に現場での実務と自習に頼ってきたソフトウェアエンジニアを想定しています。 形式手法を学ぶ前の認識と疑問 ソフトウェアエンジニアとしての私の一番の興味関心は設計手法です。設計は、なんらかの解決したい問題に対して、ある一面を切り取った構造（モデル）を与え、そのモデルを解決の機構に落
WebAssemblyがW3Cの勧告に到達。「WebAssembly Core Specification 」「WebAssembly Web API」「WebAssembly JavaScript Interface 」の3つ
W3Cの WebAssembly Working Groupは、Webブラウザ上でネイティブコードに近い実行速度で高速に実行できるバイナリフォーマット「WebAssembly」の仕様が勧告に到達したことを発表しました。 今回勧告になったのは、WebAssemblyに関連する3つの仕様です。 1つ目はWebAssemblyのバイナリファイルを実行する仮想マシンの仕様を定義した「WebAssembly Core Specification」。これは一般的なマイクロプロセッサの動作を模倣するような作りにすることで、WebAssemblyのバイナリファイルでプロセッサのネイティブコードに近い実行速度を実現するようになっています。 2つ目の「WebAssembly Web API」は、さまざまなプラットフォームでWebAssemblyを利用可能にするため、WebAssemblyバイナリファイルのシリ
TFCon で発表する Node.js 最新動向です。
Go プログラミング言語仕様
Go プログラミング言語仕様 本文書は，The Go Programming Language Specification version 2021/02/10 のなんちゃって日本語訳である． 原文ソース：https://github.com/golang/go/blob/master/doc/go_spec.html 訳文ソース：https://github.com/hiwane/gospec-ja．誤訳・誤字脱字などは issue かプルリクで https://hiwane.github.io/gospec-ja/ 訳注 valid/invalid は有効/無効, legal/illegal は正当/不当と訳す． letter と character を区別するため，letter は英字，character は文字と訳す． signed/unsigned 符号付き，符号なし sourc
最近のC言語と、次期C標準(C23)
C言語といえば古い言語なイメージですが、その重要性はまだまだ落ちていません（多分）。重要な言語だからこそ、今もひっそりと進化を続けています。この記事では、そんなC言語の最近の動向を紹介します。 まずはC言語の前世紀の標準であるC99、現行の標準であるC11/C17を振り返り、その後に未来の標準であるC23に触れます。 C99 C99では色々追加されました。ここでは一部のみの紹介とします。 _Bool _Complex C++の std::complex とメモリ上での互換性がある（C++11以降）。 可変長配列（VLA） 可変長引数マクロ 浮動小数点数の強化 十六進表記 筆者による関連記事：浮動小数点数の16進表記 fma 筆者による関連記事：FMA (fused multiply-add) の話 #pragma STDC FENV_ACCESS, #pragma STDC CX_LIMI
おはようございます ritou です。 久々に「解説付きスライド全公開」的なやつをやります。 先月、チーム内でID連携のための標準化仕様に関する勉強会(私が一方的に話す会)を行いました。 が、実際はだいぶグダグダになってしまい、これはその後色々付け足してるうちに別物になってしまった資料です。 内容としては、ID連携のための標準化仕様にどのようなものがあるかを知ってもらうための「入門編」のような立ち位置で作りました。 OpenID Connect(やSAMLのような) ID連携のための標準化仕様を紹介しようと思うと、ついつい個別にシーケンスやリクエスト/レスポンスの説明を始めがちですが、初学者が気になるのはそんな細けぇことではないでしょう。 まずは「この仕様で何ができるようになるのだろう」「この仕様では何を実現したいんだろう」と言うところから理解していくのが良いのではないでしょうか。 そこで
HTML 文書内に <meta charset="UTF-8"> を書いていますか? 書いているとしたら、その必要性を問われた時に理由を説明できますか? 実は私も勘違いしていた部分があり[1]、改めてまとめてみました。 <meta> による文字エンコーディング指定の歴史 Content-Type ヘッダーと <meta> の関係性と優先度 <meta> が必要なケース <meta> で文字エンコーディングを指定するデメリット <meta> による文字エンコーディング指定の歴史 § まず基本的なおさらいをします。<meta charset="UTF-8"> は HTML5 で登場した新しい記法で、 HTML4 以前は <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> などという長くて覚えにくい書き方をしてい
なぜ JavaScript の [1, 2, 3] + [4, 5, 6] は '1,2,34,5,6' なのか
先日次のツイートを見かけた。 I have been writing Javascript since roughly 1997 but it still manages to occasionally do something that absolutely shocks me pic.twitter.com/JyYOo4wGOu — mcc (@mcclure111) January 11, 2022 JavaScript では [1, 2, 3] + [4, 5, 6] の結果が "1,2,34,5,6" であり、この挙動が直感に反しているというツイートである。 実際のところ筆者も直感に反していると思う。しかしこの挙動は至って ECMAScript の仕様通りである。 この記事では、なぜこの挙動が ECMAScript の仕様に従っていると言えるのか仕様を引用して説明する。 大雑把な
![なぜ JavaScript の [1, 2, 3] + [4, 5, 6] は '1,2,34,5,6' なのか](https://cdn-ak-scissors.b.st-hatena.com/image/square/e11bede1e8a8f416112d241a038b3d49ef7aa4f8/height=288;version=1;width=512/https%3A%2F%2Fsosukesuzuki.dev%2Fimg%2Flarge-logo.jpeg){kind=logo}
拙著「プロフェッショナルIPv6」で、IPv6がリンクにおいて1280オクテット以上のMTUを要求していることに関して「最小MTU」という表現をしており、その表現が間違っているのではないかというご指摘をいただき、その点について調べなおしました。 その過程で、そもそも関連する部分で自分が間違って理解していたことに気がつきました。 その間違いを発信していたという恥を晒す内容ですが、せっかくなのでブログの記事として共有することにしました。 IPv4におけるデータグラムのサイズに関して IPv4の仕様が規定されているRFC 791では、IPv4ヘッダのTotal Lengthに関して、以下のように書かれています。 Total Length: 16 bits Total Length is the length of the datagram, measured in octets, includi
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
設計書・仕様書のレビュー方法を定めたJIS規格登場 チェック体制を標準化しやすく
正式仕様リリース！ JavaScriptの最新仕様ES2022で追加された「全」新機能
W3C発行のHTMLがすべて廃止された日 | フロントエンドBlog | ミツエーリンクス
スケールする要求を支える仕様の「意図」と「直交性」 - Qiita
［CEDEC］脳の動作クロックは33Hz？ 人間のスペックに適合させたゲームの遅延対策とは
なぜ HTML の form は PUT / DELETE をサポートしないのか? | blog.jxck.io
JavaScript クイズ解説: NaN === NaN の結果はどうなる？
【仕様の読み方】HTMLの要素をどうやって学ぶか
JavaScriptのエキサイティングな新機能7選 - Qiita
Web のセマンティクスにおける Push と Pull | blog.jxck.io
JavaScript の MIME タイプが `text/javascript` に統一されようとしている
「バグを意図的にバグのまま残す」という選択肢がある
0.0.0.0/8のIPアドレスなどを利用可能にする提案仕様 - ASnoKaze blog
そろそろJavaScriptに採用されそうなOptional Chainingを今さら徹底解説 - Qiita
JavaScriptの上限・限界値 - Qiita
「418 I'm a teapot」が永久欠番（？）に ～25年前の発行されたジョークRFCの後始末／【やじうまの杜】
ゼロから学んだ形式手法 - DeNA Testing Blog
スマートホーム共通規格「Matter」発表。Amazon、Google、Apple参加
Node.js 最新動向 TFCon 2022
ID連携の標準化仕様紹介とセキュアな実装のためのアプローチ ~ 2021 - r-weblife
`<meta charset="UTF-8">` を書く必要性があるケースとデメリット
インターネットプロトコルにおけるパケットサイズに関して:Geekなぺーじ
shiho.nk.awe.jp
note.com/masaki0115
www.print-gakufu.com
renatusclinic.jp
designtext.net
learn.microsoft.com