curl --tlsv1.2 https://github.com/hoge.keys
--tlsv*
オプションで、通信に使用するTSL/SSLのバージョンを指定できる
- TLS 1.0 は脆弱性があるため、無効になっているサイトが多い(githubとか)
- しかし、古いバージョンのcurlにはバグがあり、TLS 1.0 でしかアクセスできないらしい
--tlsv1.2
など、オプションで TSL のバージョンを明示することで、TLS 1.0 以外も使用可能
curl --tlsv1.2 https://github.com/hoge.keys
--tlsv*
オプションで、通信に使用するTSL/SSLのバージョンを指定できる
--tlsv1.2
など、オプションで TSL のバージョンを明示することで、TLS 1.0 以外も使用可能UNIX系ファイルシステムで使われているデータ構造
各nodeに与えられる任意の値
ls -i
で確認可能例
$ 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 のハードリンク)
Region 単位
, Availability Zone 単位
それぞれでリザーブドインスタンスは最大20台まで
20台以上必要な場合は、サポートを通じて制限を増やして貰う必要がある
(自分が問い合わせたときには、本社に問い合わせる必要があるので2-3日かかると回答された)
オプションでハイパースレッディングをOFFにしたり、物理コア数を減らしたりできる(料金は変わらない
ハイパースレッディングとは、従来CPUのコア一つに一つしか搭載していなかったコードを実行する装置を複数搭載してコードの処理能力を向上するものである。これにより、ハイパースレッディングを備えたCPUではホストOSから実際搭載しているコア数より多くのコアを搭載しているよう「論理的に」見えることとなり、実コア数より多くのスレッドやプロセスをOSが同時に実行できるようになる。
社内勉強会のおかげで無事合格できました!
以下について、実務経験あり
以下のルートで勉強しました
合格対策本を読む → 模試を解く → 知らない分野のBlackBeltを読む
まずは合格対策本をざっくり読んで、自分の知識が浅いところを覚え直しました
合格対策 AWS認定ソリューションアーキテクト - アソシエイト
ギリギリにやるよりは速いうちにやったほうが良いです!!
問題数こそ本番より少ないですが、出題傾向が分かるので、何を勉強すべきかが明確になります!
スライドは先頭半分だけ読めば十分です
総括するとやってよかったと思っています、ただし無駄だったなぁと思うことも少々...
まずは試験範囲が似ていて取りやすいという、AWS認定 デベロッパー - アソシエイトを、問題の知識が頭から抜けないうちに取ろうかと考えています
その後は1ランク上の AWS 認定ソリューションアーキテクト – プロフェッショナル を目指したいと思います
この方の記事がとても参考になりそうです
AWS認定 デベロッパー - アソシエイトに合格したら、この記事に書かれていた、Jayendra's Blog の対策記事でも翻訳しようかな...
言いたいこともなくはないけど、自分の実力の底上げ&証明になるので取って損はない資格と感じました
特に経験の薄い若手の人こそ、取ると信頼感が増すのではないかと思います
社内勉強会の皆さん本当にありがとうございました!!
インフラ神 id:critical-alert の神インフラ知識に本当に助けられました...! 🙇🙏🙇🙏🙇
弊社フィードフォースが不定期に行っているLT大会です
くわしくはこちら
かせいさんもひさびさに参加して、unicodeに元号 ( ㍾, ㍽, ㍼, ㍻ ) ってあるけど、来年の次の元号はどうなるの? というお話をしました
Enclosed CJK Letters and Months
に ンに○
が無いのは、どの文字コードにもなかったためらしいですンに○
を新元号にすれば、Enclosed CJK Letters and Months
にも角が立たずに万事解決!自分としては次の元号は U+337A
(IU) で、その次は U+3370
(㍰) で良いと思うんですけどね
BMPの中でも、ちょこちょこ開いているところはあるのですが、他の言語の領域なので、あんまり日本の都合で使うのは良くないといった感じですかね...
U+0870〜089Fとかは開いているし、直前の文字のCJK漢字っぽいので、このへんは使えそうな気がします...!
このあたりもよかったらどうぞ!
やっていることは、 依存しているオブジェクトを注入するようにする なので、「依存オブジェクトの注入」の方が訳としてただしいのでは? という議論がある
あと、自分が読んでいるオブジェクト指向設計実践ガイドでも「依存オブジェクトの注入」が採用されているので、こちらを使う
オブジェクト指向設計実践ガイド ~Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
依存性が高いオブジェクトを内包している時。そのオブジェクトを外部から注入するように修正する
具体的にはこんなコード(オブジェクト指向設計実践ガイドより)
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
のためだけに、rim
と tire
が Gear#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でした