Keep your calendar in a plain text file. Calendar.txt is versionable, supports all operating systems and easily syncs with Android mobile phone. Download calendar.txt template How do I use calendar.txt? Open calendar.txt in any text editor and start filling in your events. Example Calendar.txtI've used calendar.txt for a while, and now I want to share it. Your new calendar in plain text: 2021-02-1
C言語にはbitfieldという機能がありますが、この機能にはさまざまな落とし穴があり、注意深く利用しても予期せぬバグや移植性の問題を引き起こす可能性があるとよく言われています。 実際、jpcertを確認すると複数の勧告が出ています。 EXP11-C. ビットフィールド構造体のレイアウトについて勝手な想定をしない INT12-C. 式中で使用される単なるintのビットフィールドの型について勝手な想定をしない CON32-C. 複数スレッドによる隣接データへのアクセスが必要な場合データ競合を防止する DCL39-C. 信頼境界を越えて構造体を渡すとき情報漏えいしない 私は先輩技術者から「とくに組み込みの分野においてC言語のbitfieldは使うべきではない」と教わって生きてきました。 本記事ではbitfieldの仕様や問題点、なぜ仕様を避けるべきか、緩和策や代替案について検討します。 目次
C/C++ の「ポインタ」は、難しいとか、実は簡単だとか、色々言われます。 ポインタについては規格に書かれています。この記事は、ポインタをより正確にイメージするため、規格に私の解釈を追加したものです。区別のため、C++23 草案 (N4950) の内容には節番号を付け、私の解釈は 斜体 で書きます。 私の解釈は以下の記事の影響を受けています。 ポインタとは、IDとオフセットの組 まず、ヌル以外のポインタは、以下の ID とオフセットの組 です。 ID：新しいオブジェクトが作られるたびに振られる、ユニークな値。 オフセット：オブジェクト先頭からのバイト数。 詳しく話していきます。 ID の割り振り 変数を定義するとオブジェクトが作られ (6.7.2)、各オブジェクトに固有の ID が割り振られます。たとえば、 と書くと整数 x と配列 arr が作られるので、x と arr にそれぞれ ID
Kyoto.なんか #6 で発表しました. speakerdeck.com 以下はその補足情報など. 仕様書中の出現頻度 null と undefined がそれぞれの仕様でどの程度使われているのかは, 仕様書中の出現頻度を見るだけでもある程度わかりりそうです. ということで ECMAScript 2024 と WHATWG の標準 (2024-09-07 時点) のうちいくつかの仕様書の中での出現頻度を見てみましょう. Spec #null #undefined ES2024 300 939 DOM 368 120 Fetch 276 10 HTML 1778 275 URL 98 9 見ての通り, 顕著に登場頻度に差があることがわかりますね. なお上記の null の出現数には WebIDL の nullable (T?) を含めていないため, Web 標準における実際の null の
What is coming next for OpenAPI, as v4.0 of the OpenAPI Specification gets closer to being released? What major changes are coming, how easy will it be to upgrade, and how do tooling companies feel about it? Recent History of OpenAPI OpenAPI has been around for a long time, but only hit the mainstream when OpenAPI v3.0 was released in 2017. It made it a whole lot easier to describe the majority of
OpenTelemetryにおいて、OTel CollectorのReceiverを開発するときやアプリケーションに計装をする際、MetricsのUnit（単位）にどんな文字列を指定すべきかよく分からなかったので調べてみました。 semconv OpenTelemetryにはSemantic Conventions（semconv）と呼ばれる規約があります。あるデータに対して異なる実装間で共通の名前がついていると便利なので標準を取り決めましょうといった趣旨のものです。Metricsにおいてはメトリック名や属性、単位といったデータについて規約が定められています。 opentelemetry.io semconvには一般的な規約と具体的な規約があります。具体というと、例えばHTTPに関する規約、AWSなどのクラウドサービスに関する規約、といった形です。「HTTPサーバのリクエストの継続時間を計
Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian
規格として C11 (n1570) を参照する。 注意: 途中に入れた図が崩れるようなら、半角・全角比が 1:2 になるようなフォントを使って閲覧してください。 現象 wandbox で実行 ソース: ( &printf)(" &printf = %p\n", &printf); printf (" printf = %p\n", printf); ( *printf)(" *printf = %p\n", *printf); ( **printf)(" **printf = %p\n", **printf); (***printf)("***printf = %p\n", ***printf); この現象を解説する。 関数呼び出し まず、関数呼び出しについての規定を見る。 The expression that denotes the called function shall have
まずはざっくり結論から これらは、モジュールの仕様を指します。JavaScriptファイルから別のJavaScriptファイルを読み込む仕組みのようなものです。 JavaScript界隈にもさまざまなモジュールの仕様・フォーマットがあります。その中で、cjsはCommonJSモジュール、esmはESモジュール、umdはUmdモジュールを指しています。 CJS Node.jsで採用されているモジュールシステム、CommonJSのことです。 CJSはそのままではクライアント(ブラウザ)で動かすことはできません。 サンプルコード const lib = require( "package/lib" ); function hello () { lib.hello( "Hello!" ); } exports.hello = hello; UMD Universal Module Definiti
What's a Feature Flag?Feature flags are a software development technique that allows teams to enable, disable or change the behavior of certain features or code paths in a product or service, without modifying the source code. What's OpenFeature?OpenFeature is an open specification that provides a vendor-agnostic, community-driven API for feature flagging that works with your favorite feature flag
Webを構成する重要な要素の1つであるHTTPは、その最新仕様で2層構造となり、バージョンに関係なく使えるSemanticsと、特徴の異なる通信仕様を定めたHTTP/1.1、2、3に分割されました。 さらに現在では、HTTPの上にあらためてUDPやIP、イーサネットなどのプロトコルを実装する提案が行われており、まさにHTTPは通信の全てを飲み込む勢いで進化しつつあります。 こうしたHTTPの最新動向の解説が、大手CDNベンダでエッジクラウドなども展開するFastlyが2023年11月8日開催したイベント「Yamagoya 2023」で同社シニアプリンシパルエンジニアの奥一穂氏が行ったセッション「HTTPが全てを飲み込む」にて行われました。 本記事ではこのセッションをダイジェストで紹介していきます。記事は以下の3つに分かれています。 HTTPが全てを飲み込む（前編）～HTTPの2層構造と、H
この記事はBuilding Red Hat Enterprise Linux 9 for the x86-64-v2 microarchitecture level | Red Hat Developer の翻訳です。 Red Hat Enterprise Linux 9 はこの記事で紹介されている x86-64-v2 アーキテクチャむけにビルドされています。 Linuxディストリビューションを構築する際、初期に決定する最も重要なことの1つが、サポートするハードウェアの範囲です。ディストリビューションのデフォルトのコンパイラ・フラグは、ハードウェア・プラットフォームの互換性にとって重要です。新しいCPU命令を使用するプログラムは、古いCPUでは動作しないかもしれません。この記事では、Red Hat Enterprise Linux (RHEL) 9のx86-64バージョンをビルドするための
structuredCloneは、JavaScriptにおいてオブジェクトのディープコピーができる便利な関数です。 従来ディープコピーの標準化された方法が無かったため、structuredCloneの登場はJavaScriptのユーザーにとって画期的なものです。あまりに画期的であり、その便利さも分かりやすいため、出たばかりの時期はTwitterでのJavaScript豆知識ツイートの常連でした。 現在はstructuredCloneのもの珍しさは無くなり、単純に便利なAPIとして受け入れられていますが、そのせいかstructuredCloneに対する理解も単純な人が出てきているようです。 そこで、この記事ではstructuredCloneがどのようなものなのか、どうしてそのようになっているのかについて、じっくりと説明します。 structuredCloneの歴史 筆者は自称世界一技術の歴史
前回の記事Go言語のcomparableには3つの意味があるにおいて、Go1.19までの言語仕様のcomparableと型制約のcomparableは指す範囲が異なるということを説明しました。たとえば、any型はGo1.19言語仕様上comparableですが、comparable型制約を満たしていませんでした。 このギャップをなくすProposalがacceptされそうです。今回はその内容を説明します。 追記 2023/02/23 このProposalは採用されて、Go1.20で実装されました。この記事の内容は基本的にGo1.20の言語仕様において正しいです。一部、言語仕様書が更新される前に記述した部分があるので仕様の用語をちゃんと使えてない部分があります。 言語仕様としての理屈にそれほど関心がない読者の人は要約だけ読めば十分だと思います。 要約 unionsをふくまないinterfac
こんにちは。株式会社メルペイのID Platformチームでエンジニアをしている @nerocrux です。この記事はMERPAY TECH OPENNESS MONTHの12日目の記事です。 はじめに WebAuthnについて 概要 システム構成 登録と認証 登録 認証 Attestation について Attestation検証の概要 AttestationObject のフォーマット AttestationObject の検証 1. AttestationObject のデコード 2. authenticatorData について 3. credentialPublicKey のパース 4. verificationData の準備 5. 証明書フォーマットの変換 6. 署名検証 Assertion について Assertion の検証 1. authenticatorData につ
url.js `B�y�U pJ�y�U /* href ┌────────────────────────────────────────┴──────────────────────────────────────────────┐ origin │ ┌────────────┴──────────────┐ │ │ authority │ │ ┌───────────────┴───────────────────────────┐ │ │ │ host resource │ │ ┌──────────┴─────────────────┐ ┌────────────┴───────────┬───────┐ │ │ hostname │ pathname │ │ │ │ ┌──────────────┴────────────┐ │ ┌──────┴───────┐ │ │ pro
The current Go language memory model was written in 2009, with minor updates since. It is clear that there are at least a few details that we should add to the current memory model, among them an explicit endorsement of race detectors and a clear statement of how the APIs in sync/atomic synchronize programs. This post restates Go’s overall philosophy and the current memory model and then outlines
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
