モリユウキ|YM202110
AWS関連
Computer Science関係の記事まとめ
1ヶ月ほど更新停止していましたが、また再開したいと思います。 今回はそのご報告と、この1ヶ月で色々あり、考え方も少し変わったので自分なりに整理しようと思います。 怒涛の10-11月本当に色々ありました。。。 妻と長男が乗った自転車が車にぶつかられたり（軽傷です）、次男がなぜか右目周辺ばかり怪我したり（軽傷です）、初めて健康診断で引っかかったり（結局異常なし）。。。 そんなこんなで一度心身を落ち着けるため、一定の負荷がかかるnote更新をストップすることに決めていました
Amplifyではアプリケーション単位で環境変数を設定することが可能ですが、ここにアプリケーションで使用する外部の認証情報をハードコードしてしまうと、Amplifyへアクセス可能な人は誰でもそれを見れてしまいます。 認証情報はできるだけまとめて管理して、かつアクセスできる人を限定した方が良いのは周知の通りなので、今回はパラメータストアで管理して使用する方法についてです。 大きな流れは以下です。 パラメータストアに認証情報を格納する Amplifyの環境変数でパラメータ
AWSアカウントの内部で特定のアクセスキーが使われている箇所を探し出す必要があり、その手順を習ったので整理しておきます。 大きく以下の手順で探索しました。 CloudTrailのイベント履歴で探す CloudTrailで証跡を作成してCloudWatchに転送する CloudWatchでアクセスキーを使用したAPIコールを検索する それぞれ見ていきます。 CloudTrailのイベント履歴で探すまず、AWSリソースに対するAPIコールを確認するため、CloudT
最近、DockerコンテナとホストマシンのCPUアーキテクチャの違いから、特定の機能が動かないという事象が発生しました。これまでCPUアーキテクチャはあまり意識したことがなく、理解が浅かったので整理してみます。 理解するに当たって、以下の記事から多くを学ばせていただきました。 前提：起きていた違いアプリケーションがホストされているコンテナと、そのコンテナをホストするマシンのCPUアーキテクチャは以下のように違っていました。 【CPUアーキテクチャの違い】 Dockerコ
前回まとめていて、表題部分についても理解が甘いことが分かったので今回整理します。 Fast-Forward Mergeとはブランチをマージする際にマージコミットを発生させず、HEAD位置の変更（先に進んでいる方に合わせる(=早送り)）だけを実行する方法です。 以下のように、現在のブランチが指すコミットが、マージするブランチのベース（共通の祖先）コミットであり、かつその間に他のコミットがない場合に実行されます。 ○ = Commit◎ = HEAD○ -- ○ -- ○
Gitに関して少し理解を深める機会があったのでメモしておきます。 Gitとはまず簡単にGitの役割についておさらいを。Gitは、ソースコードのバージョン管理に広く利用されている分散型バージョン管理システムです。変更の履歴を追跡し、複数の開発者が同時に作業できるように設計されています。 CommitとはGitにおいて、Commitはプロジェクトの履歴における1つの「チェックポイント」です。ファイルやディレクトリの変更、追加、削除を含むプロジェクトの状態を、特定の時点でキャプ
最近ハッシュテーブルとかハッシュマップとかについて記事を書いていましたが、そもそもの一般的なハッシュについて理解を深めたのでメモしておきます。 ハッシュ化とはハッシュ化とは、元データ(文字列)をハッシュ値(文字列)に不可逆変換することを指します。意味不明な文字列に変換されるので、パスワードなど、変換前の文字列を知られたくない場合に用いられます。 ハッシュ化を実行する関数をハッシュ関数と呼びます。 参考ブログからの引用ですが、例えばmd5関数でハッシュ化すると以下のような
leetcodeでハッシュマップ実装の練習をしたのでアウトプットします。 お題は以下です。 入力値と答えの例は以下です。 -- Example１--------Input: nums = [2,7,11,15], target = 9Output: [0,1]Explanation: Because nums[0] + nums[1] == 9, we return [0, 1]. -- Example2--------Input: nums = [3,2,4], tar
leetcodeでハッピーナンバー判定を実装していて、表題のアルゴリズムの存在を知りました。 つまりは特定の処理を通じて「1」に行き着くか、無限ループに入ってしまうかどうかを判定する、というものです。 このお題に対して、まずは試行錯誤のうえハッシュセットを使って以下のように実装しました。わざわざハッシュセットを自作せずset()を使ってもパフォーマンスは同じだったのですが、まぁハッシュセットの問題だったのでこちらにしました。 class Solution: def
今日は色々とトラブルが起き、その火消しで新しいことを学んだのでアウトプットします。 Linuxのnohupコマンドは、ターミナルからログアウトした後もプロセスを継続して実行させるために使用されるコマンドです。 これは特にリモートサーバーで長時間実行するプロセスやスクリプトを扱う場合に有用です。リモートサーバーだと一定時間でログアウトされてしまい、nohupなしだと長時間かかるスクリプトの実行ができないケースがあるためです。 nohupとは"No Hang UP"の略で、
これまで機会がなく体型的に調べていなかった「デザインパターン」について、きっかけがあったので一度まとめておこうと思います。 デザインパターンは必ずしも設計の最適解ではないそうですが、実際に一通り見てみて、エンジニアとして抑えておくべき知見に満ちているなと感じました。最近学んでいるデータ構造とアルゴリズムもそうですが、基礎ほどしっかりとやるべきですね。 しっかり理解しながら進めているとなかなか時間がかかってしまっており、今回は「生成に関するパターン」のみです。 それでは整
こちらの続きで、ハッシュテーブルの1種であるハッシュマップをPythonで実装してみます。 本題に入る前に、まずはハッシュテーブルについて理解を深めたいと思います。 ハッシュテーブルの長所と短所長所 高速な検索、挿入、削除: 平均的な状況下で、ハッシュテーブルはO(1)の時間複雑度で検索・挿入・削除を行うことができます。これは、キーに対応する値を直接アクセスすることができるためです。 効率的なメモリ利用: ハッシュテーブルは、データを格納するために必要なメモリ空間
ハッシュセットは集合の中から要素を高速に検索するためのデータ構造です。既存のライブラリは色々あると思いますが、理解のため自作してみます。 ハッシュテーブルとはまず、元となるデータ構造であるハッシュテーブルに関してです。 ハッシュテーブルは、キーと値のペアを格納するためのデータ構造で、任意のキーに対して値を迅速に検索、追加、削除することができます。Pythonのdict型はハッシュテーブルの一種で、イメージしやすいと思います。 ハッシュテーブルは、ハッシュ関数を使用して、
バイナリツリーの走査方法の第4弾です。 バイナリツリーについて別で4本記事を書いています。 走査とは先頭から順にデータを見ていくことを指し、バイナリツリーを走査するアルゴリズムは主に４つあります。 このうちのLevel-order Traversalについてです。 レベルオーダー走査とは今回の幅優先探索（BFS：Breadth-First Search）またはレベルオーダー走査は、バイナリツリーをレベル別に探索する方法です。この探索方法では、ツリーの各レベルを順番に、左
バイナリツリーの走査方法の第3弾です。 バイナリツリーについて別で3本記事を書いています。 走査とは先頭から順にデータを見ていくことを指し、バイナリツリーを走査するアルゴリズムは主に４つあります。 このうちのPost-order Traversalについてです。 ポストオーダー走査とはポストオーダー走査は、バイナリツリーを巡る方法の一つで、ノードを「左→右→ルート」の順序で訪問します。この走査方法は、例えばバイナリツリーの削除機能において、ノードを削除した際にその子ノー
バイナリツリーの走査方法に関するまとめ第2弾です。 バイナリツリーについて別で2本記事を書いています。 走査とは先頭から順にデータを見ていくことを指し、バイナリツリーを走査するアルゴリズムは主に４つあります。 このうちのIn-order Traversalについてです。 インオーダー走査とはインオーダー走査は、バイナリツリーを巡る方法の一つで、ノードを「左->ルート->右」の順序で訪問します。この走査方法は、特にバイナリサーチツリーにおいて、ノードを昇順でアクセスするの
