無線LANの基本

そもそも

周波数が300GHz~3THzの電磁波を電波という。

周波数と波長

  • c = fλ より波長と周波数は逆の関係。
  • 波長が長いほど周波数は低く、波長が短いほど周波数が高い。

天候による影響

周波数が高いほど雨天による悪影響が大きい。
雨の日に1kmの減衰は

  • 10GHzで1db
  • 30GHzで10db
具体例:
  • 超長波(30MHz〜30KHz)では水中でも伝わるため潜水艦の通信に利用される。

直進性

ホイヘンスの原理と干渉から説明される。波長が長い波は障害物を回り込んだ地点での位相差が少ない結果強め合うからである。

  • 長波(周波数が低い)ほどよく回折する。低周波は障害物を回り込む。
  • 短波(周波数が高い)ほど直進性が高い。高周波は直進的に進む。
  • 短波〜中波は遠くまで送信することができる。
具体例
  • 潜水艦の通信用の超長波の送信施設は大規模になる。

伝送量

  • 高周波(短波)ほど信号の情報量を増やすことができる。
  • 低周波(長波)ほど信号の情報量が少ない。
具体例
  • 潜水艦の通信用の超長波は短いメッセージしか送信できない。

http://try.rikei-style.net/article/149815225.html

AWSの環境構築(EC2)

現在追記中

インスタンスの作成

  • コンソール画面からGUI経由で5分もかかわらず作成可能!

キーペア

  • キーペアをダウンロードは初回しかできないことに注意。

EC2インスタンスの確認

  • CLIで作成したインスタンスの確認が可能なはずがなぜかできない。
  • 結局コンソール画面経由で確認した。
aws ec2 describe-instances --instance-id  i-XXX

An error occurred (InvalidInstanceID.NotFound) when calling the DescribeInstances operation: The instance ID 'i-XXX' does not exist

EC2インスタンスへのアクセス

  • ダウンロードしたキーペアを用いてsshログインを行う。
  • ログイン時の@以下はコンソール画面で確認した「パブリックDNSIPv4)」もしくは「IPv4 パブリックIP」を指定する。
$ ssh -i AWS/test-key-pair.pem ec2-user@ec2-54-224-248-255.compute-1.amazonaws.com

Last login: Wed May 16 05:25:41 2018 from 1.73.38.185

       __|  __|_  )
       _|  (     /   Amazon Linux AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-ami/2018.03-release-notes/
6 package(s) needed for security, out of 7 available
Run "sudo yum update" to apply all updates.

デフォルトのユーザ名は以下を確認 docs.aws.amazon.com

AWSの環境構築(S3)

S3(Simple Storage Service)へのファイルのアップロードはCLI経由で行うため、最初にCLI環境の構築が必要。

S3の概要

S3はその名前の通りオブジェクトストレージ。

  • 99.999999999%(ナイン・イレブン)の耐久性を実現する。
  • S3は単純なKVS(Key-Value型データストア)であり「ディレクトリでファイルを管理する」従来のファイルサーバの仕組みと異なる。
  • 従量課金制。
  • 容量制限なし。

S3の用語

バケット

  • オブジェクトの保存先。
  • 作成可能なバケット数は1アカウントあたり最大で100個まで。
  • バケット名はグローバルでユニークな必要あり。

オブジェクト

  • S3に格納されるファイル。
  • 上限5T。

キー

  • オブジェクト固有の識別子(オブジェクトの名前)。
  • オブジェクトにはウェブサービスエンドポイント、バケット名、キー、(およびオプションでバージョン)を組み合わせることで一意にアクセスすることができる。

CLI環境の準備

  • アクセスキーおよびシークレットアクセスキー*1を生成する。
  • aws-cliをインストールする。
$ sudo pip install awscli

CLI環境の設定

aws configureコマンドを実行し、アクセスキー・シークレットアクセスキー・デフォルトリージョン・デフォルト出力形式を設定する。

# aws configureコマンド実行後は設定した内容が表示される。
$ aws configure
AWS Access Key ID [********************]: 
AWS Secret Access Key [********************]: 
Default region name [ap-northeast-1]: 
Default output format [text]: 

# .awsディレクトリが作成される。
$ ls .aws
config      credentials

バケットの作成〜オブジェクトのアップロード例

# パケットの作成
$ aws s3 mb s3://test0515
make_bucket: test0515
$ aws s3 ls
2018-05-09 00:11:30 test-croudtrail-bucket
2018-05-15 15:03:15 test0515

# オブジェクトのアップロード
$ aws s3 cp icon.png s3://test0515/icon
upload: ./icon.png to s3://test0515/icon

権限の設定

https://s3.console.aws.amazon.com/s3/にアクセスしてオブジェクトに読み取り権限を付与した。

アップロード確認

ブラウザでhttp://test0515.s3.amazonaws.com/iconにアクセスすると画像が表示された! f:id:okn-yu:20180515152713p:plain

バケットの削除

バケットを削除する際は最初にオブジェクト自体を削除しておくことが必要。オブジェクトが存在するバケットを削除しようとすると失敗する。

# 失敗例
$ aws s3 rb s3://test0515
remove_bucket failed: s3://test0515 An error occurred (BucketNotEmpty) when calling the DeleteBucket operation: The bucket you tried to delete is not empty

# オブジェクトの削除
$ aws s3 rm s3://test0515/icon
delete: s3://test0515/icon

# バケットの削除
$ aws s3 rb s3://test0515
remove_bucket: test0515

# バケットが削除確認
$ aws s3 ls
2018-05-09 00:11:30 test-croudtrail-bucket

参考

gihyo.jp www.task-notes.com

*1:シークレットアクセスキーが表示されるのは初回のみ。もしシークレットアクセスキーを忘れた場合は再度アクセスキーの生成からやり直す必要がある。

AWSのアカウント管理

AWSのアカウント管理は複数機能あるためまとめた。現在加筆中。

ベスト・プラクティス

  • ルートアカウントはアクセスキーおよびシークレットアクセスキーを利用しない(ルートアカウント自体を普段利用しないため問題ない)。

認証の種類

記載中

ベーシック認証

  • IDとパスワードをサーバに送信することで認証する。
  • IDとパスワードが漏洩した場合は第三者によるなりすましが可能となる。
  • パスワードを暗号化した場合でもリプレイアタックの恐れがある。

チャレンジ・レスポンス認証

  • サーバ側から送信されたランダムな値をもとに、IDとパスワードをMD5でハッシュ(ダイジェスト)化して送る。
  • Basic認証では防げなかった盗聴や改竄を防ぐために考案された。
  • 認証の度に利用する擬似乱数が異なるためリプレイアタックのリスクを軽減できる。

ダイジェスト認証

  • チャレンジ・レスポンス認証のHTTP上での実装例。

バイオメトリクス認証

Gitコマンドチートシート(commit/push取り消し)

焦らず少しづつマスターしていこう!!

commitの取り消し

resetとrevertの2通りが存在する。revertのほうが安全ではあるが不要な履歴がログに残ってしまう。resetはその逆。

  • resetはcommit履歴および修正履歴自体が削除される。
  • revertはcommit履歴および修正履歴自体が残る。

resetコマンド

【コマンド】
git reset [オプション]  <コミット>

オプション一覧

  • --hard:HEADの位置、インデックス、ワーキングツリー全てを対象
  • --mixed:HEADの位置、インデックスを対象
  • --soft:HEADの位置みを対象
【実行例】
# ワーキングツリーおよびインデックスはそのままで直前のコミットのみを取り消す
$ git reset --soft HEAD^

pushの取り消し

  • reset後にpushしようとするとローカルリリポジトリのほうが古いため怒られる。
  • -fオプションで強引にコミットしてしまう。
【実行例】
# ワーキングツリーおよびインデックスはそのままで直前のコミットのみを取り消す
$ git push -f <リポジトリ名>

参考

qiita.com

汚いソースコードの分類と対策

「綺麗なソースコードはどれも似ているが、汚いソースコードは千差万別だ」by トルストイ
  • 「良いソースコードは短いけど理解に時間がかかるソースコードではなくて、長くても理解するまでにかかる時間が短いソースコード」というのが私の哲学です。
  • たまには逆向きに汚いコードの特徴と対策を整理してみました。

関数名や変数名が不適切なケース

  • 公式のコード規約に沿うことである程度は解消できる

処理全体概要が見えないケース

コードを読んでも結局何をしたいのかの全体像が見えない。これには複数の可能性が存在しそれぞれ有効な対処方法が異なる。

レイヤーの異なる処理が混在している場合

  • モジュール化を行いファイルを分割する。1ファイル中にレイヤーの異なる処理が混在しないようにする
  • 処理毎にファイルが別れていてかつ個別のファイル内部の処理は非常に簡単を目指すべき。
  • これは単一責任の原則によくマッチしている。

処理対象のデータの具体例が見えない場合

  • コードだけから中身を推測するのは無理
  • コメントに大まかな処理の流れや入出力結果の例を記載する

スパゲッティコード

その場しのぎで継ぎ足し処理が原因の場合

  • 後付で処理を付け足していくと、ifやelseがあちこちの処理に散在するスパゲッティコードになる。
  • 対策としては実装の最初の段階から各処理のスコープを意識して設計する。
  • 修正する場合はリファクタリングが必要となる(最悪の場合はソースコードの書き直しとなる)。