はてなブックマーク

S3データ格納時のサーバ側暗号化（SSE-S3、SSE-KMS、SSE-C）と、クライアント側暗号化（CSE-KMS、CSE-C）AWSS3kms S3バケットへのデータ格納時にサーバーサイド暗号化のキーを指定できますが、SSE-S3だのSSE-KMSだの紛らわしい用語が出てきて混乱したので、整理してみた記事です。 1. 用語解説 SSE Server Side Encryptionの略です。暗号化・復号をサーバー側で行う暗号化方式です。 CSE Client Side Encryptionの略です。暗号化・復号をクライアント側で行う暗号化方式です。暗号化・復号のキーには、クライアント側で管理するキーだけでなく、KMSのカスタマー管理キーを使用することもできます。 CMK Customer Master Keyの略です。CDKを暗号化するキーです。CMKは、KMS上では暗号化された状態で管

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

この記事では、私自身がバッチファイルを書く時に気をつけていることについて書きます。業務でバッチファイルと関わると「不可解な挙動に心が削られる」「試行錯誤で時間を溶かす」などしますので本来ならバッチファイルに近づかないことの方が先なのですが。 そうはいってもSIerの方などで、不本意にもバッチファイルを書かざるを得ない場面に遭遇してしまうことは少なからずあると思います。そんな人がバッチファイルの落とし穴にハマって貴重な工数を溶かさないことを願ってこの記事を書きました。 なお「環境変数の遅延展開」という言葉にピンとこない方は、@sawa_tsukaさんの素敵な記事「バッチファイル界の魔境『遅延環境変数』に挑む（おまけもあるよ）」を一読されることをオススメします。 まずは記号をおさえよう バッチファイルでは記号の扱いでドはまりすることが多いです。まずはじめに、どんな記号があるか押さえておきます。

「DOSバッチファイル」、嫌な響きですね...。 DOSバッチの作成依頼は、心の準備をしていないときに突然降って湧くもので、毎回毎回、for文の書き方をググってはハマり、環境変数の即時展開でハマり、「(の使い方が誤っています」「0の使い方が誤っています」等の言葉足らずのエラーに苦しめられる。こんな思い、二度としたくない。 でもいまさらDOSバッチの勉強なんてしたくない。 そんな時に備えて、DOSバッチでよく使うコードスニペットを用意しておきました。華麗にコピペで逃げましょう。 文字列操作等は関数化しています（結果の文字列は関数と同名の変数に格納されます）。勢いに乗って、Python的な文字列スライス関数（Slice）も作成しました。 @echo off setlocal rem ========================================================

C言語（C90）で暗黙の型変換が発生するケースを、思いつく限り網羅してみました。暗黙の型変換は「あ、忘れてた」となってハマることがしばしばあるため、備忘録の意味も込めて随時追加予定です（ある程度固まれば、コードレビューのチェックリストにも使えるかもしれない）。 全部で21パターンありました。 凡例 本記事のコード例は、直上のリスト文のみに付随するものです。この凡例は、以下例において、Hello world!を出力するコード例がリスト文「猫たちは大変にすばらしい存在である。」には関係しないことを示します。猫たち…。 猫たちは大変にすばらしい存在である。 printf関数を呼び出す。

はじめに C言語初心者には、なぜポインタが難しく感じられるのか。 ポインタの解説というと、しばしば「住所の書かれたメモを渡す」というアナロジーで説明されますが、ポインタという概念自体は、理解するのにそれほど難しいものではないと思います。 難しい理由は、以下の3点だと思っています。 そもそも記法が変態的で、人間の目に優しくない。 この変数には○○を指すポインタが格納されてて、○○もポインタで××を指していて…とか考えているうちに、頭がこんがらがる。 配列とポインタの奇妙な互換性に混乱する。 1は（まったく同感ですが）慣れが解決する問題であり、3については、配列には配列特有の読み方があるため、別の機会に書きたいと思います。 本記事では、上記の3点のうち、2の問題を軽減するためのコツについて、解説してみます。 対象読者 本記事が対象とする読者像は、以下です。 int n; int *p = &n

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

草 「それ海外だとアウトローですぅ」 「ここではない何処かに行きたいだけなら、それでもいいですけど（ドヤァ）」 「プログラミング言語に詳しくなるのは、もう生き甲斐のようなものなんです（ドヤァ）」 「来月からレポートしますぅ」 「レポートはしないですぅ」 「私は先に進みます（キリッ）」 クッソワロタwww この記事の背景 最近、仕事でバッチファイルを書かざるを得ないという不幸な場面に遭遇しているのですが、これがまた、ものすごくどうでもいいことでハマることが多々あり、思わず「このWindows、壊れてる！」と思ったほどでした。犠牲者を増やさないためにも、DOS文法の挙動を記録したメモを載せておきます。 （本記事を見てもらえば納得されると思いますが、DOSバッチの言語設計は「驚き最大の原則」を方針とし、その言語仕様は「実装」です。言語法律家というものが成立しえない、非常に平和な世界でもあります。

副作用完了点とは何か 家事ロボットに以下の作業を命令したとします。 庭に水を撒く。 料理を作る。 洗濯をする。 ロボットから作業完了の報告を受けた時点で結果を確認してみると、庭の芝生には水が撒かれ、料理も完成しており、洗濯も終わっています。 つぎに、以下の作業を命令したとします。 銀行に行ってお金を下ろす。 スーパーで食材を買う。 料理を作る。 ロボットが外出してしばらく経った後、ロボットからエラーの報告を受けました。「銀行でお金をおろすことだけできた」そうです。いったい何があったのか聞いてみると、 「最初に料理を作ろうとしたが、食材が無いので料理を作ることができなかった。つぎにスーパーに行ったが、お金が無いので食材を買うことができなかった。最後に、銀行に行ってお金を下ろすことはできた。」 という答えが返ってきました。 普通の人間なら作業の依存関係を考慮し、お金を下ろす→食材を買う→料理を