kasei_sanのブログ

かせいさんのIT系のおぼえがきです。胡乱の方はnoteとtwitterへ

ハードリンクしたファイルはinode番号が同一値になる

inode とは

UNIX系ファイルシステムで使われているデータ構造

  • UNIXのファイルは、inodeと、実際のデータの組み合わせ
  • inodeには、inode番号と、ファイルのサイズなどの属性情報が格納されている

inode番号 とは

各nodeに与えられる任意の値

  • 各ディレクトリは、node へリンクを貼ることでファイルを管理している
  • node番号は ls -i で確認可能

ハードリンクを生成すると、どちらも同一のファイルを参照するため、node番号は同一値となる

$ ls -li aaa bbb
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 aaa
8610608681 -rw-rw-rw-  2 kasei_san  staff  221  8  2 11:28 bbb

ls-i オプションで、inode番号が確認できる

rm まめちしき

  • rm コマンドはファイルの削除ではない。ディレクトリから対象のnodeを外すだけ
    • unlink というコマンドもある(カーネルによっては rm のハードリンク)
  • 一つもリンクが無く、openされていないnodeは、その後削除される

EC2のリザーブドインスタンス。同一 Region 単位で取得できる最大数は20まで

f:id:kasei_san:20180908153036p:plain

Region 単位, Availability Zone 単位 それぞれでリザーブドインスタンスは最大20台まで

リザーブドインスタンスは Region 単位 と、availability zone単位 がある

  • Region 単位 : どの AZ で動かしてもよいが、AZ にインスタンスの空きがない場合、起動できない
  • Availability Zone 単位 : AZ の移動はできないが、予約したインスタンスはかならず確保できる

20台以上必要な場合は、サポートを通じて制限を増やして貰う必要がある

(自分が問い合わせたときには、本社に問い合わせる必要があるので2-3日かかると回答された)

EC2のvCPUは、物理コアをハイパースレッディングでCPUリソースを分割して仮想CPUとして提供している

オプションでハイパースレッディングをOFFにしたり、物理コア数を減らしたりできる(料金は変わらない

ハイパースレッディングって何

ハイパースレッディングとは、従来CPUのコア一つに一つしか搭載していなかったコードを実行する装置を複数搭載してコードの処理能力を向上するものである。これにより、ハイパースレッディングを備えたCPUではホストOSから実際搭載しているコア数より多くのコアを搭載しているよう「論理的に」見えることとなり、実コア数より多くのスレッドやプロセスをOSが同時に実行できるようになる。

ハイパースレッディング・テクノロジー - Wikipedia

AWS 認定ソリューションアーキテクト アソシエイト(2018) に合格したので勉強方法について語る

f:id:kasei_san:20180902184634p:plain

社内勉強会のおかげで無事合格できました!

f:id:kasei_san:20180902180845p:plain

内訳

f:id:kasei_san:20180902180930p:plain

合格前の自分のステータス

以下について、実務経験あり

  • EC2, ECS, S3, RDS(MySQL), Elastic Beanstalk, CloudWatch, IAM, Lambda, DynamoDB, VPC

どんなふうに勉強したの?

以下のルートで勉強しました

合格対策本を読む → 模試を解く → 知らない分野のBlackBeltを読む

合格対策本を読む

まずは合格対策本をざっくり読んで、自分の知識が浅いところを覚え直しました

  • 合格対策本は2018年版より前のテストに沿って書かれていますが、変わらないところも多いので、やっておいて損は無いです

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

合格対策 AWS認定ソリューションアーキテクト - アソシエイト

模試を解く

ギリギリにやるよりは速いうちにやったほうが良いです!!

問題数こそ本番より少ないですが、出題傾向が分かるので、何を勉強すべきかが明確になります!

  • 自分は答えをさらっと言えるまで暗記しました

知らない分野のBlackBeltを読む

AWS クラウドサービス活用資料集 | AWS

スライドは先頭半分だけ読めば十分です

  • どのスライドも分量があるので辛いですが、後半は具体的な事例になってくるので、試験対策に限れば読む必要はないです

受験してどうだった?

総括するとやってよかったと思っています、ただし無駄だったなぁと思うことも少々...

良かったこと

  • 試験勉強で得た知識で、コストの削減など自分が運用しているサービスの改善提案ができたこと
  • 社内勉強会++
    • わからないことをすぐ聞くことができた
    • 次々と合格者が出たので、凄いプレッシャーがかかって合格できた

悪かったこと

  • 多分使わないであろうサービスの知識も詰め込む必要があること(AWS CloudFormation とか...)
  • 2018年前半の仕様を元にテストが作られているので、その時の仕様で回答する必要があること (2018/07に改善された S3のコレとか)
  • テストの日本語の翻訳が微妙なこと。英語版も見ることができるので、そっちも読むと良いかもです

これからどうする?

まずは試験範囲が似ていて取りやすいという、AWS認定 デベロッパー - アソシエイトを、問題の知識が頭から抜けないうちに取ろうかと考えています

その後は1ランク上の AWS 認定ソリューションアーキテクト – プロフェッショナル を目指したいと思います

AWS 認定ソリューションアーキテクト – プロフェッショナル をどう勉強する?

この方の記事がとても参考になりそうです

qiita.com

AWS認定 デベロッパー - アソシエイトに合格したら、この記事に書かれていた、Jayendra's Blog の対策記事でも翻訳しようかな...

jayendrapatil.com

総括

言いたいこともなくはないけど、自分の実力の底上げ&証明になるので取って損はない資格と感じました

特に経験の薄い若手の人こそ、取ると信頼感が増すのではないかと思います

社内勉強会の皆さん本当にありがとうございました!!

他の弊社合格者の記事

critical-alert.hatenablog.com

インフラ神 id:critical-alert の神インフラ知識に本当に助けられました...! 🙇🙏🙇🙏🙇

社内LT大会(FFLT)で、元号の文字コードについて話してきました

FFLTとは

弊社フィードフォースが不定期に行っているLT大会です

くわしくはこちら

developer.feedforce.jp

かせいさんもひさびさに参加して、unicode元号 ( ㍾, ㍽, ㍼, ㍻ ) ってあるけど、来年の次の元号はどうなるの? というお話をしました

発表資料

頂いた感想

f:id:kasei_san:20180902142803p:plain

ン に ○ を新元号に!

  • Enclosed CJK Letters and Monthsンに○ が無いのは、どの文字コードにもなかったためらしいです
  • ンに○ を新元号にすれば、Enclosed CJK Letters and Months にも角が立たずに万事解決!

次の次の元号がどうなるのかは気になる

自分としては次の元号U+337A (IU) で、その次は U+3370 (㍰) で良いと思うんですけどね

4桁だと開いているとこはもう殆ど無いのですかね?

BMPの中でも、ちょこちょこ開いているところはあるのですが、他の言語の領域なので、あんまり日本の都合で使うのは良くないといった感じですかね...

U+0870〜089Fとかは開いているし、直前の文字のCJK漢字っぽいので、このへんは使えそうな気がします...!

文字コードたーのーしー

ダウンロード.jpeg

このあたりもよかったらどうぞ!

Dependency Injection 依存オブジェクトの注入 についてのおぼえがき

Dependency Injectionって「依存性の注入」じゃないの?

やっていることは、 依存しているオブジェクトを注入するようにする なので、「依存オブジェクトの注入」の方が訳としてただしいのでは? という議論がある

little-hands.hatenablog.com

あと、自分が読んでいるオブジェクト指向設計実践ガイドでも「依存オブジェクトの注入」が採用されているので、こちらを使う

依存オブジェクトの注入 ってどういう時の使うの?

依存性が高いオブジェクトを内包している時。そのオブジェクトを外部から注入するように修正する

具体的にはこんなコード(オブジェクト指向設計実践ガイドより)

class Gear
  attr_reader :chainring, :cog, :rim, :tire
  def initialize(chainring, cog, rim, tire)
    @chainring = chainring
    @cog = cog
    @rim = rim
    @tire = tire
  end

  def gear_inches
    ratio * Wheel.new(rim, tire).diameter
  end
  # ...
end
Gear.new(52, 11, 26, 1.5).gear_inches

このコードのどこが問題なの?

ギアのインチを計算する Gear#gear_inches が、Wheel依存した状態 である

結果的に以下のような問題が発生する

  • 変更時のコストが高い
    • 例えば Wheel.new のためだけに、rimtireGear#initialize に渡されている。そのため、Wheel.new の引数が変わったら、Gear は大幅に変更が必要になる
    • そもそもここに Wheel があることを知らなければ、修正が必要なことにも気が付けない
  • 再利用性が低い
    • Wheel 以外のオブジェクトからギアを計算したい時、別のメソッドが必要
  • テスト実装のコストが高い
    • テストを書く時に、Wheel オブジェクトのことを考慮する必要がある

じゃあどんなふうに直したら良いの?

こんなふうに、Gear に対して外部から、diameter を呼べるオブジェクトを注入してあげれば良い

class Gear
  attr_reader :chainring, :cog, :wheel
  def initialize(chainring, cog, wheel)
    @chainring = chainring
    @cog = cog
    @wheel = wheel
  end

  def gear_inches
    ratio * wheel.diameter
  end
  # ...
end
Gear.new(52, 11, Wheel.new(26, 1.5)).gear_inches

こうすれば、 Gear は、Wheel に依存しなくなり、 wheel については #diameter さえ実行できればどんなオブジェクトでも良くなる → ダックタイピング

なので、Wheel が変更されてね影響は少なくなるし、テストするときも簡単な mock を作れば良いだけになる

蛇足

むしろ、「依存性オブジェクトの排除」とか言ったほうが意味が通じそう、という話を会社のQiita::Teamでした

DynamoDB の capacity unit おぼえがき

概要

  • read/write capacity unit という単位でユーザがテーブル毎にcapacityを設定する
  • 実際の使用量とは関係なく 設定した、read/write capacity unit に比例した金額が請求される

capacity unit とは

1 capacity unitは、以下の通り

write

1秒に1回 1KBの書き込み

read

以下のいずれか

  • 1秒に1回 4KBの強力な整合性のある読み込み
  • 1秒に2回 4KBの結果整合性のある読み込み(書き込みが反映されないことがある)

参考: 読み込み整合性 - Amazon DynamoDB

補足

  • writeもreadもサイズを超える場合、それだけ capacity unit が消費される
  • capacity unit以上の通信が発生した場合、蓄積されて開くまで待たされる

capacity unit の料金

25 read/write capacity unit/month までそれぞれ無料

それ以降は、東京リージョンなら以下の通り

  • write: 0.000742USD/1capacity unit hour
  • read: 0.0001484USD/1capacity unit hour

reserved capacity

1年or3年単位で read/write capacity を先払いすることで割引を受けられる

最低単位は 100 capacity unit/hour

参考