事象
あるタイミングから何故かある人だけセッション管理が行えてない振る舞いが起きる。
なお、URLにはその人だけJSESSIONIDが表示されていた。
原因
クッキー前提で作成されているJavaアプリケーションであったが、
それの受け渡しがうまく行えていないため。
URLにJSSESSIONIDが表示されているのは、クッキーの受け入れができないため、
URLリライティング方式に切り替わったため。
smtp4devでTLS通信のメールテスト実施方法
smtp4devとは
インストール方法
- 上記サイトにアクセス
- 右側のReleasesカテゴリ内のLatestアイコンをクリック(2022/5/14時点3.1.4が最新)
- Assetsから利用するプラットフォームに沿ったモジュールをダウンロード
- 任意の箇所に配置
(補足)
- ネットにはsmtp4dev v2系の情報が多いので、内容読み分ける必要有
- 実行には.net Frameworkが必要
- コンテナ版も用意されている
実行方法・利用方法(Windowsの場合)
- Rnwood.Smtp4dev.exe を実行
- メールの確認はブラウザからアクセス(デフォルト：http://localhost:5000)
- 利用したいプログラムから、smtp4devに対してメール送信すればOK(デフォルト：localhost:25)
本題：TLS通信を行う方法
smtp4devの設定方法
- appsettings.json というファイルを編集する
- TlsModeというプロパティをStartTls or ImplicitTlsに変更
・StartTlsなのかImplicitTlsなのかは、本番で利用するメールサーバーを想定して設定
- HostNameをlocalhostではなく、ホスト名にしなければならない
・後述する自己証明書が生成される際にホスト名で生成されているため
- Port番号は特段変更の必要はない
・どこかと被るのであれば変更する必要がある程度
- smtp4devは自己証明書を保持しているので、それを利用する必要がある
・Javaの場合は、keytoolを使ってキーストアに自己証明書を登録する必要有
・Pythonの場合は、cerファイルをpemなどに変換する必要有
VSCodeで簡単なプレゼン資料を作成する方法
文法概要
--- marp: true theme: gaia class: - invert --- # A - A1 - A2 --- # B - B1 - B2 ---
- marp:trueでプレビューがプレゼンモード、falseだとマークダウン形式
- themeやclassのところは好み(最低marpのところがあればいい)
- 保存するファイルの拡張子は.mdで無いと駄目かも
ショートカット(よく忘れる…)
| キーアサイン | 効能 | 補記事項 |
|---|---|---|
| Ctrl + Shift + v | プレビュー表示 | |
| Ctrl + Shift + p → export → Marp: Export Slide Deck...を選択 | PDF等出力 | 右上のアイコン(△)押下も可 |
文法詳細(これをよく忘れる...)
主要どころ
・リンク(Markdown記法だがよく忘れる…)
[リンクテキスト](URL "マウスホバー時文言")
・画像(これもよく忘れる…)
・ピリオドをリンクとして認識させない方法
.
・空白行を書く
<br>
画像関連
・拡大率調整
・センタリング
・空白区切りで複数指定
・サイズ自動調整
・背景として利用
但し、画像のサイズ指定には一部制約がある。
qiita.com
Tips
Markdown Lintの特定ファイルを対象外にする方法
ファイル保存場所で対象外にする方法
(当時嵌った内容と共に)
yoneyore.hatenablog.com
参考リンク
本家
なんとかキャンを思い出してしまう(色がしまりんの髪の色を彷彿させる)
Marpit: The skinny framework for creating slide deck from Markdown
良さげな解説
最初の導入部分から解説してくれている
【VS Code + Marp】Markdownから爆速・自由自在なデザインで、プレゼンスライドを作る - Qiita
プロパティの説明を色々書いてくれている
Marp(Marpit) - Qiita
文法の部分で参考にさせて頂いた
Marp のすゝめ
Markdown記法チートシート
Markdown記法 チートシート - Qiita
PowerPoint出力せずにVSCode上でプレゼンモードにする方法
gonkunblog.com
ドメインの関心事からアーキテクチャ特性への翻訳
P69 表5-1 ドメインの関心事からアーキテクチャ特性への翻訳 より
| ドメインの関心事 | アーキテクチャ特性 |
|---|---|
| 合併・買収 | 相互運用性、スケーラビリティ、適応性、拡張性 |
| 市場投入までの時間 | アジリティ、テスト容易性、デプロイ容易性 |
| ユーザー満足度 | パフォーマンス、可用性、耐障害性、テスト容易性、デプロイ容易性、アジリティ、セキュリティ |
| 競争優位性 | アジリティ、テスト容易性、デプロイ容易性、スケーラビリティ、可用性、耐障害性 |
| 時間と予算 | シンプルさ、フィジビリティ |
本書には、アーキテクチャの優先度を順番で付けるのではなく、
いくつか重要なものを羅列形式の方が調整・議論しやすい点の説明があった。
また、上記の様な経営層の考える単語をアーキテクチャ特性に翻訳する表が逸脱であった。
この様な対応関係はなんとなく意識はしていたが、ここまで整理する考え方が無かった。
P57 4章 アーキテクチャ特性
言葉の定義
P57 4章 アーキテクチャ特性 より
アーキテクチャ特性とは、問題領域とは独立した、システムの重要な側面だ。
ソフトウェアのそうした特徴を非機能要件と呼ぶ組織も多い。
しかし、非機能要件という用語は否定表現だ。
そのため、著者らはその表現を好まない。
(中略)
よく使われる別の用語に、品質特性がある。
しかし、著者らはこの表現も好まない。
この用語だと、設計よりも事後に行う品質評価の印象が強いと感じるからだ。
私たちが好んで使うのは、アークてくちゃ特性という用語だ。
なぜなら、この用語が、アーキテクチャやシステム全体の静甲に不可欠な関心事を、その重要性を損なうことなく表していると考えるからだ。
まさしく同じ様な印象をこれら用語に感じていた。
私もアーキテクチャ特性という用語を推していきたいと思った。
アーキテクチャ特性とは
P58 4章 アーキテクチャ特性 より
- ドメインに依らない、設計に関する考慮事項を明らかにするもの
- 設計の構造的な側面に影響を与えるもの
- アプリケーションの静甲に不可欠か重要なもの
アーキテクチャ特性リスト
運用特性
- 可用性(Availability)
- 継続性(Continuity)
- パフォーマンス(Performance)
- 回復性(Revoverability)
- 信頼性/安全性(Reliability/Safety)
- 堅牢性(Robustness)
- スケーラビリティ(Scalability)
構造特性
- 構成容易性(Configurability)
- 拡張性(Extensibility)
- インストール容易性(Installability)
- 活用性/再利用性(Leverageability/Reuse)
- ローカライゼーション(Localization)
- メンテナンス容易性(Maintainability)
- 可搬性(Portability)
- アップグレード容易性(Upgradeability)
横断的特性
- アクセンシビリティ(Accessibility)
- 長期保存性(Archivability)
- 認証(Authentication)
- 認可(Authorization)
- 合法性(Legal)
- プライバシー(Privacy)
- セキュリティ(Security)
- サポート容易性(Supportability)
- ユーザビリティ/達成容易性(Usability/Achievalibity)
ISOでの定義
ISO / IEC 25010で定義
図と各項目の説明が記載されている(英語)
iso25000.com
パフォーマンス効率
- 時間的挙動(応答、処理時間、スループット)
- リソース利用率
- 容量(設定された最大限度を超えるかなど)
互換性
- 共存可能性
- 相互運用性(複数のシステムとの連携)
信頼性
- 成熟度(通常の使用において信頼性要件を満たしているかどうか)
- 可用性
- 耐障害性
- 回復性
セキュリティ
- 機密性
- 完全性
- 責任追跡性
- 立証性
- 認証可能性
保守容易性
- モジュール性
- 再利用性
- 分析容易性
- 修正容易性
- テスト容易性
可搬性
- 適応可能性
- インストール可能性
- 置換可能性
機能適合性
- 機能的完全性(機能が、特定のタスクとユーザーの目的をすべてカバーしている度合い)
- 機能的正確性(製品やシステムが必要な精度正しい結果を提供する度合い)
- 機能的妥当性(機能が指定されたタスクや目的の達成を容易にする度合い)
ISOでは定義されているが、本書ではアーキテクチャ特性としては扱わないと整理している。
(非機能ではなく、機能要件であるという考えという解説と理解)
トレードオフと少なくとも最悪でないアーキテクチャ
P66～P67 4.2 トレードオフと少なくとも最悪でないアーキテクチャより
アーキテクトがシステムを設計する上で、あらゆるアーキテクチャ特性を最大限に活かせることはほぼない。
ほとんどは、アーキテクチャ決定は競合する関心事間のトレードオフと帰着する。決して最善のアーキテクチャを狙ってはいけない。
むしろ、少なくとも最悪でないアーキテクチャを狙おう。アーキテクチャ特性が多すぎると、あらゆるビジネス上の問題を解決しようとする汎用的なソリューションにつながる。
そうして作られたアーキテクチャは、扱いにくい設計となり、うまく機能することはほとんどできない。
このことが示唆しているのは、アーキテクトはアーキテクチャをできるだけイテレーティブに設計するように尽力すべきということだ。
雑記
4章自体はとても短い章(P57～P66)であり、書いている内容も指針としての内容である。
とはいえ、ITアーキテクトに持つべき考え方などをとても分かりやすい言葉で纏めてくれている。
また、列挙した項目については、本書内では解説文を記載してくれている。
Chrome マイチートシート
| ショートカットキー | 効能 | 補記事項 |
|---|---|---|
| Ctrl + u | HTMLの表示 | |
| Ctrl + h | 履歴の表示 | |
| Ctrl + j | ダウンロードの表示 | |
| Ctrl + l | アドレスバー入力 | Alt + Dと同じ |
| Shift + Esc | Chromeタスクマネージャーの表示 | |
| Ctrl + Shift + Delete | 閲覧履歴データを消去するの表示 |
![[クローム] メッセンジャーバッグ BURAN III/ブラン 3 (現行モデル) 24L 防水 両肩仕様 メンズ BLACK](https://m.media-amazon.com/images/I/4110X8qGSPL._SL500_.jpg "[クローム] メッセンジャーバッグ BURAN III/ブラン 3 (現行モデル) 24L 防水 両肩仕様 メンズ BLACK")
