202001¶
危険物取扱者¶
- 甲種 6,600円,乙種 4,600円(複数類同時受験の場合も類ごとに),丙種 3,700円
- 甲種受験資格
- 次の4種類以上の乙種危険物取扱者免状の交付を受けている者
- 〇第1類又は第6類 〇第2類又は第4類 〇第3類 〇第5類
- 次の4種類以上の乙種危険物取扱者免状の交付を受けている者
- 試験詳細
- 甲種危険物取扱者試験
- 5肢択一で,試験時間は150分
- 危険物に関する法令:15問
- 物理学及び化学:10問
- 危険物の性質並びにその火災予防及び消火の方法:20問
- 乙種危険物取扱者試験
- 5肢択一で,試験時間は120分
- 危険物に関する法令:15問
- 基礎的な物理及び基礎的な化学:10問
- 危険物の性質並びにその火災予防及び消火の方法:10問
- 科目ごと60%以上で合格
- 甲種危険物取扱者試験
- x類とは
- 第1類 塩素酸塩類,過塩素酸塩類,無機過酸化物,亜塩素酸塩類,臭素酸塩類,硝酸塩類,よう素酸塩類,過マンガン酸塩類,重クロム酸塩類などの酸化性固体
- 第2類 硫化りん,赤りん,硫黄,鉄粉,金属粉,マグネシウム,引火性固体などの可燃性固体
- 第3類 カリウム,ナトリウム,アルキルアルミニウム,アルキルリチウム,黄りんなどの自然発火性物質及び禁水性物質
- 第4類 ガソリン,アルコール類,灯油,軽油,重油,動植物油類などの引火性液体
- 第5類 有機過酸化物,硝酸エステル類,ニトロ化合物,アゾ化合物,ヒドロキシルアミンなどの自己反応性物質
- 第6類 過塩素酸,過酸化水素,硝酸,ハロゲン間化合物などの酸化性液体
- 感想: 甲種とるのがよさそう.乙種全類と甲種では差がある.
- 最短合格の価格感
- 乙種4つ取る: 4600 * 4 = 18400
- 甲種1回: 6600
- 免状新規発行手数料: 2900
- 合計: 25000 + 14500 = 39500
- 好奇心と実用性,受験のしやすさ等をあわせて,3,5類はmustで自動決定,ほかには4類,6類がよさそう.
- 最短合格の価格感
- 既に乙種の一部の類の免状を所持する者が未取得の乙種の他の類を受験する場合は,試験科目の「危険物に関する法令」と「基礎的な物理学及び基礎的な化学」の全部の問題が免除となり,試験時間は35分となる.
- 注意点: 電子申請では複数受験の申込みはできないので,複数受験を希望する場合は書面による申し込みをする必要がある.
- 東京の場合4類を除いて2種類まで複数受験できる.最短でも甲種までは4回受験する必要がある(ex. 4 + 3,5 + 6 + 甲種)
- 免除が受けられることから,上記(3,5と6は互いに交換可)の順序で受けるとよさそう.4類合格することで「危険物に関する法令」と「基礎的な物理学及び基礎的な化学」が以降の乙種試験で免除になり,「危険物の性質ならびにその火災予防及び消化の方法」のみの受験で済む.
- 免除を受ける場合や受験資格を得るためには前提となる資格の免状を取得済みであることが必須.合格しているだけではだめ.
- ref: 危険物取扱者 - Wikipedia
- ref: 一般財団法人消防試験研究センター
- 2020日程
試験日 電子申請開始 締切 書面申請開始 締切 試験科目
2/22(土) 12/16 1/7 12/19 1/10 4類
2/29(土) 1/6 1/17 1/9 1/20 甲種
3/1(日) 1/6 1/17 1/9 1/20 4類
3/7(土) 1/13 1/24 1/16 1/27 4類
3/20(金) 1/27 2/7 1/30 2/10 1,2,3,5,6類,丙種
3/23(月) 1/27 2/7 1/30 2/10 4類
3/29(日) 2/3 2/14 2/6 2/17 4類
組織に的確に情報伝達をする¶
- 自衛隊の訓練指示に学ぶ
- 日時,気象状況,人数,役割,実施内容,装備,事前準備,特記事項,その他状況に必要な情報等を1枚のフォーマットにまとめる.別紙は許容される.
髪を切るときのtips¶
- "ツーブロ,右分け,ワックスなし,まとまるといい" を要望とするとめんどくなくていい.
標準報酬月額¶
- 標準報酬月額は,いつどのように決まるのですか.|日本年金機構
- 目先的には4-6月の給与が少ない方が保険料,年金等の負担が減るが,長期的には年金納付額も増えると給付額も増えるのでどちらがいいかはわからん.
- 4-6月の残業ではなく給与支給により計算されるので,当月残業が翌月給与支給となる場合は3-5月の残業にかかってくる.
Jest · 🃏 Delightful JavaScript Testing¶
- いまどきのjsテストフレームワークらしい.
大規模なデータ処理におけるkeywords¶
- elasticsearchオープンソースのElastic Stack(Elasticsearch,Kibana,Beats,Logsatsh)でリアルタイムな検索と分析 | Elastic
- hadoop Apache Hadoop
- apache kafka Apache Kafka
- messages queue
- scalable
- 分散ストリーミングプラットフォームです.「Pull型」「高スループット」などの特徴があり,ストリーミングデータパイプライン構築に利用できます.分散環境において「高スループット」かつ「低レイテンシ」で,大規模データを高速に取り込み配信できるメッセージングシステムです.
- オープンソースのビッグデータ処理ツール / Apache Kafkaとは
- apache hive Apache Hive TM
- DWS software
- hadoop上で動く.
- SQLライクなHiveQLを用いる.
- HDF/HDP
- HDFS
- apache spark Apache Spark™ - Unified Analytics Engine for Big Data
- クラスタコンピューティングフレームワーク
- hadoopは拡張性, 安定性が高い.scaleable, stable.
- sparkはhadoopが苦手なリアルタイム処理につよい.
- リアルタイムの高速処理が求められるデータはSparkで,メモリ以上のデータを処理する場合はHadoopを利用するなど使い分けるとよさそう.
- 場合によってはHadoopのMapReduce100倍速い.らしい.
- dell elastic cloud strage
- ref: 分散処理に入門してみた(Hadoop + Spark) | キャスレーコンサルティング株式会社
software test¶
- エンドツーエンドテストの自動化は Cucumber から Turnip へ
- Gherkin(Cucumber/Turnip)のススメ:使った方が良い理由〜RailsでのTurnip導入方法 - さかなソフトブログ
- テストツールやキーワード
- gherkin
- Cucumber
- Turnip
- RSpec
JAXAにまなぶ成功基準¶
成功基準(サクセスクライテリア)作成ガイドライン 2010 年 11 月 30 日
宇宙航空研究開発機構
チーフエンジニアオフィス
1. 本文書の目的
本資料は「JAXA 技術プロセスガイドライン」の一部をなすものとして,成功基準作成に
おける指針となることを目的とする.
2. 成功基準とは
成功基準とは,『ミッション目標に対する達成の度合いを計るための基準』である.ミッション目標には科学・利用・技術実証といった様々な種類が存在するが,いずれの場合の成功基準も JAXA が国民に対して宣言するものである.成功基準は機構として定めるものであるため,経営審査(プロジェクト準備審査及びプロジェクト移行審査)において経営的視点から審査される.ミッションを提案する者は,ライフサイクルの終わりまでを見通し,関係者との合意を得て総合プロジェクト的な視点から成功基準を作成し,MDR や SDR 等の本部審査を受けておく必要がある.成功基準は,予め定められた時期(例えば定常運用終了時など)にミッションの達成度合いを評価する際に参照される.また,ライフサイクルの途中における大きなシステム仕様の変更,あるいは不具合などが発生した際の判断のために参照される.
3. 成功基準に記載すべき事項
- ① ミッション目標
- 一つのプロジェクトに複数のミッションがある場合にはそれぞれに対応した目標を設定する.
- ② 各目標に対するサクセスレベル(ミニマムサクセス,フルサクセス,エクストラサクセス)
- ミッション全体を俯瞰した上で,JAXA の責任で実施する成功基準を,可能な限り定量的に記載する.
- ③ 各基準に対する達成判断時期・実施主体(必要に応じ)・設定根拠(別文書可)
4. 関連資料
- 別紙1:成功基準作成における留意点
- 別紙2:サクセスレベルの目安
- 別紙3:SAC プロジェクト評価の視点に基づく成功基準
- 添付1:過去の衛星の成功基準例
- 添付2:宇宙開発に関するプロジェクトの評価指針 (参考資料4-1)
【参考 1】 成功基準作成における留意点
- a. ミッション目標の設定
- 国民への成果の還元を考慮し,具体的なエンドユーザを特定する.例えば利用衛星ならば,いかに社会に受け入れられて有効に使われるかという視点を持つ.
- 複数のミッションがある場合にはそれぞれに対応するミッション目標を制定し,優先順位づけを行う(複数ミッションの場合は,それぞれの相互関係もしくは独立性を明確にしておくこと).
- b. 成功基準の制定
- ミッション全体を俯瞰した上で,JAXA の責任で実施する成功基準を制定する
- ミッション範囲の明確化
- 他機関と合同でミッションを達成する場合には,その役割分担と責任分担を明確にしておく.
- 利用ミッションや科学ミッションの場合は,基本的にはミッション成果項目が成功基準となるが,技術実証も同時に行う場合はそれも成功基準となりえる.
- 技術実証ミッションの場合は,技術実証項目が成功基準となる.
- c. 定量的な表現(数値目標)とする
- d. 達成判断時期をできる限り明記する
- e. 基準を制定した考え方の根拠を明記する (別文書可)
- f. 成功基準は,SAC のプロジェクト評価を受けることを考慮する
- 開発費用が概ね 200 億円を越えるプロジェクトの場合,「SAC プロジェクト評価」の対象となるので,その際の評価の視点を把握しておく.(別紙3と添付2参照)
- SACにおける報告は,国民への宣言と等価であるとの認識を持つ.
- g. 成功基準の制定及び改訂はシステムズエンジニアリング推進室長通達第 19-1 号「プロジェクトマネジメント実施要領」 第 6 条(ミッション要求書の作成)に準じた手続きで実施する.改訂にあたっては,国民への宣言を変更することに相当するという認識を持った上でステークホルダの承認を得る必要がある.
成功基準の雛形(The Template of Success Criteria)
+----------------+-----------------------------------+-----------------------------------+-----------------------------------+
| Success Level/ | | | |
| Mission Target | Minimum Success | Full Success | Extra Success |
+----------------+-----------------------------------+-----------------------------------+-----------------------------------+
| 1 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx |
| Note.1 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 |
+----------------+-----------------------------------+-----------------------------------+-----------------------------------+
| 2 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx |
| Note.1 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 |
+----------------+-----------------------------------+-----------------------------------+-----------------------------------+
| 3 | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| xxxxxxxxx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx | Attainment Judgment Time: xx/xx |
| Note.1 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 | (Responsible Organization) Note.2 |
+----------------+-----------------------------------+-----------------------------------+-----------------------------------+
↑ ↑定量的な表現とする.Note.3
↑ミッション全体を俯瞰した上で,JAXAの責任で実施するミッション目標を制定
- Note.1: ミッション目標を優先順に並べる
- Note.2: 実施主体が JAXA の場合は特に記載しなくてもよい
- Note.3: 定量的な基準を設けたその根拠を示しておく (別文書可)
【参考2】 サクセスレベルの目安
<<サクセスレベルの目安>>
- フルサクセスの目安 (100 点(優)のイメージ)
- 予定していた要求を満たし,計画通りの成果を得る.
- (ア) 「ユーザ要求を実現する」場合の成功基準例:定常運用期間を全うし,ミッション要求書にあるユーザ要求を満たす
- (イ) 「JAXA の実施主体範囲が技術開発である場合,或いは技術開発自体がミッション目標である」場合の成功基準例:定常運用期間を全うし,開発仕様書にある主要な技術要求/システム要求を満たす.
- ミニマムサクセスの目安 (60 点(可:合格)のイメージ)
- フルサクセスには至らないが最低限のミッション要求を満たす. 衛星の縮退モードなどとは必ずしも連動しない.
- (ウ) 「ユーザ要求を実現する」場合の成功基準例:過去のデータと同程度のものが取得できた場合,短期間でも何らかの有意義なデータが取得できた場合 etc
- (エ) 「JAXA の実施主体範囲が技術開発である場合,或いは技術開発自体がミッション目標である」場合の成功基準例:重要な機器単体の動作が確認できた場合,複数ある機器の一つが機能した場合 etc
- エクストラサクセスの目安 (100 点越え(秀)のイメージ)
- (オ) フルサクセスを越えて成果を得る.
[ZBX-17036] fix: insufficient cast in zbx_read() and unstable statement - ZABBIX SUPPORT¶
- bug patchしたつもりだったが,色々手助けしていただいて結局跡形ない形で修正してもらった.
- C言語全然わかってない.
- ただのbug reportになったが,いい経験だった.
てにをは¶
- てにをは.うん.てにをは.
Midnight Commander¶
GitHub - NSO-developer/nso-5-day-training: This training was prepared by Cisco IT Network Engineers for other network engineers. It requires no background in NSO, YANG, Python or anything else.¶
仮想ディスクイメージについて. ova, ovf, vmdk, ...¶
- OVA(Open Virtual Appliance)
- OVFパッケージをtarでアーカイブしたものだと思えばいい.
- なので,
tar -xf hoge.ova
すると下記のovfのファイル群が得られる.
- なので,
- OVFパッケージをtarでアーカイブしたものだと思えばいい.
- OVF(Open Virtualization Format)
- OVFパッケージ には,常に記述子ファイル( *.ovf )が含まれる.
- OVFファイルはXMLで記述される.
- 記述子: 記述子ファイルにより,その仮想マシンの仮想ハードウェアが定義される.このファイルには仮想ディスク,サービス,およびゲストオペレーティングシステムに関する記述や,ライセンス契約書(EULA),アプライアンス内の仮想マシンの起動および停止手順,サービスのインストール手順などの情報が含まれる.記述子ファイルの拡張子は,.ovf である.
- マニフェスト: パッケージに含まれる各ファイルのSHA-1ダイジェスト値で,パッケージの破損を検出する.マニフェストファイルの拡張子は,.mf である.
- 署名: パッケージに含まれるX.509証明書の公開キーで署名されたマニフェストのダイジェスト値で,パッケージの所有者の検証に使用される.署名ファイルの拡張子は,.cert である.
- 仮想ディスク: OVFは,ディスクイメージの形式についての仕様ではない.AOVFパッケージには仮想ディスクを構成するファイルを含むが,その形式は仮想ディスクをエクスポートした仮想化製品により異なる.XenServerで作成するOVFパッケージでは,Dynamic VHD形式のディスクイメージが使用される.VMware製品やVirtual BoxのOVFパッケージでは,ストリーム最適化のVMDK形式が使用される.
- このうち,記述子と呼ばれるファイルがOVFファイルを指す..
- このファイルがどういう役割を持っているかというと,仮想マシンのconfiguration(CPU, Memory, NIC, GuestOSの種類, etc...),ストレージ,ネットワーク構成,その他メタデータ等がxmlで記述されている.
- OVFファイルがあれば,あるVM(群)の構成を構築することが可能ということである.ただしこのovfにはディスクイメージは含まないため,その他の手段でディクスイメージを提供する必要がある.具体的にはvmdk等が挙げられる.
- OVAパッケージにはこの記述子(ovf)とイメージ(vmdk, etc...)のほか,マニフェストファイル(.mf)と署名ファイル(.cert)が含まれることが多いようである.
- OVFファイルとOVFパッケージは似て非なるもので,OVFパッケージにはOVFファイルが常に含まれるが,場合によっては上記のマニフェスト,署名,仮想ディスクが含まれ,これをtarでarchiveしたものがovaと呼ばれるファイルとなる.
- マニフェストファイルはovaに含まれる各ファイルのsha-1ダイジェストが格納されており,ファイルの破損を検知する目的で利用されるようだ.
- また,署名ファイルにはマニフェストファイルをX.509証明書の公開キーで署名したダイジェスト値が記載されており,所有者(distributor)の検証が行えるようになっているようだ.
これらの記述子,マニフェスト,署名,仮想ディスクがtarでarchiveされたのがovaと呼ばれるファイルとなる.
vmdkをqcow2に変換する¶
qemu-img
コマンドを利用して実行できる- how to get:
sudo apt install qemu-utils
- how to get:
qemu-img convert [-f format] [-O output_format] <input_image_file> <output_image_file>
- 引数はそれぞれ下記の通り
- QCOW2 (KVM, Xen):
qcow2
- QED (KVM):
qed
- raw:
raw
- VDI (VirtualBox):
vdi
- VHD (Hyper-V):
vpc
- VMDK (VMware):
vmdk
- QCOW2 (KVM, Xen):
- ref: OpenStack Docs: イメージ形式の変換
- ex.)
- イメージが分割されていない場合
qemu-img convert -p -f vmdk -O qcow2 *.vmdk hoge.qcow2
- イメージが分割されている場合
qemu-img convert -p -f vmdk -O qcow2 *-s???.vmdk huga.qcow2
- ref: Open Virtualization Format(OVFとOVA)
- ref: QEMUで作成可能な仮想ディスクファイルフォーマット 比べてみた - Qiita
トポロジ/グラフの描画をするのに便利そう¶
PCEP Overview - TechLibrary - Juniper Networks¶
- PCE 〜MPLSネットワークのSDN化を本気で実現する"唯一の"方法〜
- MPLSの複雑なラベル計算をRouterとは別のコンピュータ(Controller)で行うしくみ.
- JANOG33 MPLSトラフィックエンジニアリングチュートリアル - Cisco systems. Shishio Tsuchiya
冗長化に対する基本方針の決め方のサンプル¶
- 品質目標、故障の基準とは?というのをちゃんと考える.
用語定義¶
- 故障
- 筐体故障,リンク故障,電源故障等を含む.
- 筐体の一部機能の喪失は筐体故障に含む.
- 災害等による拠点機能の喪失は故障に含まない.(DRは実施しない) など.
機器群にクラスをもたせる¶
- Class1:
- 1つの故障が起きた際に機能を継続できる.
- すべての1つの故障においても動作継続が可能な冗長構成をとる必要がある.
- Class2
- 1つの故障が起きた際に機能を縮退して動作を継続できる.
- Class3
- 1つの故障が起きた際に機能が喪失する.
ポリシ¶
- 各機器自体のクラスは?リンクのクラスは?というのを決める.最もクラスが低いところがその系のクラス.