SD_24.3月号
ラフに読もう
ココネ
リヴリー作ってる会社の紹介色々
CRM
顧客管理システム マーケとか
SRE
Site Reliability Engineering
サービスの信頼性を高めるために、手動作業を減らしたり自動化を進めること
(ちなみに)DevOps
開発者と運用者が協力し合うことにより、リリースサイクルの短縮化を図ること
プレイングマネージャー
開発とマネジメントを両立する
用語解説
OpenTohu
Terraformをフォークして作られた
Terraform
IaCの一種
Infrastructure as Code
サーバーなどをコードとして表現すること
複製や設定の管理が楽でgit管理などもできる
terraformがオープンソースでなくなったので、それの代わりみたいなもの
ドメイン解体新書
DNSは操作する機会などが少ないわりに枯れた技術なので、一度覚えてしまえば流用できる
役割
IPでデータの送受信を行なっていて、IPアドレスがないと接続できない
昔はhosts.txtに全てのドメインとIPを記載して管理していたが今は多すぎる
解決するためのものがDNS
名前解決
FQDNからIPを取得するために必要なプロセスのこと
FQDN
完全修飾ドメイン名
例えば、「www.atmarkit.co.jp.」はホスト名「www」とドメイン名「atmarkit.co.jp」をすべて揃えたFQDNである。
example.comのAレコードを名前解決するとIPアドレスが返ってくる
なので、このIPアドレスに向けてリクエストを飛ばすことでサイトを閲覧できるというような感じで使う
DNSはドメインと紐づいたサーバーをクライアントのブラウザに教えてくれる
そのほか
ドメインに関する様々な情報を登録できる
所有の認証とか、メールへの署名検証とか。管理者しか編集できないので紐付け以外にも使える
リソースレコード
AとかTXTとか。
名前解決 = 大体はドメインのAレコードのIPアドレスのことを指す
重要なもの
A: 一般的。FQDNに対してサーバーのIPv4アドレスを紐づける時に使う
MX: メール用。webサイトを表示するためのものか、メールを受信するためのものかを使い分けられる
TXT: 自由な文言を登録できる。これを利用して設定時にTXTに入力してもらったりすることで、ドメイン所有者であるかどうかなどがわかる
CNAME: あるドメインを別のドメインにリンクさせる。例えばCDNを使う時には業者のサーバーへ迂回させる必要があるがそういった時に使う
NS: サブドメインの管理。サブドメインにこの値でサーバーを設定しておけば、後は設定されたサーバーで一括管理ができる
権威サーバとキャッシュサーバ
1つのDNSサーバに集約しないようにする仕組み
ドメイン所有者が登録したゾーン情報があるのが権威サーバ、それをキャッシュしたキャッシュサーバ
通常キャッシュ > なければ権威サーバに問い合わせの流れになる
1.1.1.1
Cloudflareの持つパブリックDNS(キャッシュサーバ)
ここに繋げば早いと噂があるが、実際は回線帯域に依存するのでそうでもない
ただ現状つないでいるキャッシュDNSのレスポンスが悪いなら、変えてもいいかもしれない
キャッシュサーバはTTLの秒数だけ権威サーバの情報を再利用できる
マネジメントのやり方
暗黙知と形式知
言語化されていないナレッジ / 図表などで表現されており言語化が容易なナレッジのこと
文章に起こすことで、
暗黙知を形式知に変えられ、言語化スキルも増える
マネージャーの役目
チームの生産性を高めること、メンバーの主体性を高めること
メンバーを納得させられる言語化スキルが必要である
確かに
ドメイン駆動設計DDD: domain-driven design
ソフトウェア設計の考え方の1つ
複雑な業務ロジックに焦点を合わせる
モデルに基づいて設計する
リファクタリングを頻繁に行う
業務ロジックと業務ルール
業務ルール
事業目標を達成するための行動を統制する決め事
売り上げ最大化、コスト低下のために色々行動すること。
ソフトウェアの外側にある。
業務ロジック
ソフトウェアそのもので表現された業務ルール
複雑な業務ロジックとは
ソフトウェアの中核になる
複雑でなければ、他者が簡単に真似ができるようになるので仕事になりえない。
しかしながら環境変化にも適用できるように、継続的な修正と拡張ができるようにしておく必要がある
この発展性を持たせることが DDDの重要な点の1つ
複雑な業務ロジックに集中する理由
開発にはやることがたくさんあり、その中から成果を出さなくてはならない
であれば複雑な部分に投下して設計した方がいいという考え方。
モデルに基づいた設計
モデルとは簡略化であり、抽象化
複雑なものを理解・整理するためにモデルを作る。これが目的となってはいけない
分析モデル
業務内容や要求を理解するモデル
業務内容を理解してルールを把握するために必要
設計モデル
ソフトウェアを実際に作るためのモデル
業務内容をソフトウェアに落とし込むためのもの
DDDは、分析モデルと設計モデルを一致させることに価値を置く。
そうすることで修正や拡張が楽になる
リファクタリングの実施
開発初期段階は、業務知識が圧倒的に不足しているため徐々に歪みが出る
複雑な業務ロジックの修正は、緊急度と重要度が高い。
なので業務知識のある人とソフトウェア知識のある人がモデルと設計の改善を繰り返して精度を上げることが大事。
LLM
大規模言語モデルのこと。pythonが関連することがほとんど