  |
はてなキーワード: ルーティングとは
なんでスチムーに書かないのかって？顕名で残したくないからだよ！
さっそくいってみよう！
おすすめできるか？→今はまて。いろいろ不具合やゲームバランスの問題があってある程度以上発展させることが難しい。半年後なら安心して楽しめるかも。正直今は先行レビューくらいのクオリティ
もともと都市シミュレーション系のゲームが好きで楽しみにしていたので俺は楽しむことができた
できる都市もディテールに凝っていて、車からの景色を眺めると田舎から都市へシームレスに風景が変わっていきおおーってなる。俺はわざわざOBSで録画しちゃったもんね
達成レベル最高のメガロポリスに到達するまでのプレイ時間はだいたい100時間くらい。メガロポリス到達時点の人口は30万人くらい。日本の政令指定都市が50万人以上だからメガロポリスという名称には少し違和感がある
道路と線路が引き放題、曲げ放題→CSの魅力といったらこれでしょうと思う。時々日本の高速の複雑なジャンクションのことが話題になるけど、あれに勝るとも劣らないキチガイジャンクションが作り放題ですよ。俺は絶対住みたくない笑
不具合さえなければ永遠に遊べる盆栽ゲー→今作はいろいろ不具合があって成長に限界があるけど、それさえなければ永遠に手を入れることができる盆栽ゲー。ヌルっと遊びたいエンジョイ勢から細部にこだわるみなさんまで時間が無限に溶ける。渋滞対策とかはこれの極みで、丁寧に丁寧に遅さの原因を取り除いてスムーズに流すことができる快感を覚えると時間が無限に溶けていく。俺みたいなマイルドアスペ過集中ガイに与えると寝食を忘れてやる。これ老人ホームに入れたら老人が幸せのままにポックリ逝くんじゃないか
Clipperが使えない→Clipperってのはゲーム内のTwitterみたいなSNSなんだけどこれが全く意味がない。住民が一部でも不満をもったらバカバカ投稿されるので、ある程度都市が大きくなるといちいち聞いてらんないとなって最終的には表示をオフにしてしまう
ラジオが英語→ゲーム内にラジオがあって、交通事故や停電があるとしゃべってくれるんだけど英語なので日本人にはきつい。BGMのように音楽も流してくれるんだけど、数曲しかないので結局これもオフにしてしまう
小学校と公園が大量にできる→就学率の向上と住民の満足度を向上させるために異様に小学校と公園を建設することになる。１つの小学校あたりの定員が1500人で、いやもうちょっといけるだろという日本人の感覚から少しズレがある。ほんと１つの通りに１個小学校と３つの公園があるような感じになってゲームバランス的にこれはどうなん
カメラ機能がイマイチ→機能がやたら複雑でスクリーンショット１枚取るのに一苦労。俺は断念してOBSでやったw
車の方向転換がイマイチ→CS1からだけど、車の方向転換や車線変更が意味不明におおげさ。で後続の車がつまってあっというまに渋滞発生。高速道路で４レーンまたぎ車線変更とかバックして切り返しとかしないでしょっていう
公共交通のツールがイマイチ→１つの道路に複数の路線が走っていると路線を選択するのがわかりずらい。いったん作った路線に停留所を加えるとルーティングがおかしなことになることがある。路線から停留所を削除することができない。変更の反映にタイムラグがあり、変更結果を確認しようとして実車ビューにしているとその車や電車が突然消えたりする（その後車庫から新たに生成されて出てくる）
もうボロボロ出てきてるんだけど気を長くして修正を待とうというか俺は待つ
パフォーマンスの問題→これはいろいろな人が書いているので割愛。開発元も最優先で取り組んでるので現状待つしかない
住民が異様にゴミを捨てる→プレイエリアの20%程度をゴミ捨て場が専有するようになって夢の島もびっくりのゴミだらけ都市ができあがる。これおかしいだろという指摘がある
https://steamcommunity.com/app/949230/discussions/0/3937895474112080034/
郵便処理施設のバグ→郵便局の上位施設に郵便振り分け施設というのがあるが、それがまともに機能しないので郵便が貯まりまくる。で、郵便がうまく動いていないと住民の満足度がバカ落ちして都市から住民が逃げていく。最終的に発展が不可能になる。お前らそんなに郵便好きかよメールでいいだろうが
https://steamcommunity.com/app/949230/discussions/0/3877095833479248137/
どうせ官主導ではうまく行かない。だが、理想論をぶち上げる意味はあるだろう。
※計算基盤を自作するのは非常に重要で、そうしないと、GPUクラスタ内での並列化や通信ネットワーキングなど、ChatGPT を動かすためのコアの機能を獲得することができない。正直、ここを外資に握られてたらどうしようもないんじゃないか。
NTTが満を持して出してきたIOWNというネットワークサービスが予想通りがっかりだったので解説しておく
そもそもIOWNって何？っていう話については恐らくNTTの社員でも誰一人答えられないので割愛したいが
発端は電気によるネットワークルーティングに限界が来ていることから始まっている
このままではルーター1機に原発1台という時代になりそう、というのはよく言われた話だ
IOWNは光を使ったルーティングを行い、End-To−Endで電気を使わずに光だけで通信すること（All-Photonics Network: APN）が構想の発端である
電気によるルーティングには遅延が発生することもあって「大容量・低消費電力・低遅延」の3つが特徴として挙げられる
1Gbpsしか無かったのに10Gbpsが登場すれば「大容量になった！」となるだろう
IOWNは100Gbpsを提供してくれる
ちなみに今でも企業向けに100Gbpsの専用線サービスは存在している
なのでIOWNは何も大容量サービスではないのだ
ただ、IOWNにおけるNTT側の性能目標はIOWN1.0で従来の1.2倍なので
まぁ実効速度として1.2倍という意味だと思えばこの100Gbpsも妥当かもしれない
また、IOWN2.0では6倍になるとのことなので600Gbpsが実現できるのであろう
ローンチで現行より劣っているのは残念に他ならないが安全側に倒したと思えば分からなくも無い
低消費電力は我々にはほとんど影響がなく、NTT社内の話なので「知らんがな」という感じなのだが
低消費電力でランニング費用を抑えることができているはずなので提供価格も下がるはずである
さて、IOWN1.0の提供価格は月額198万円とのことである
現在提供されている100Gbpsの専用線サービスも198万円である
これも資料を見るとIOWN1.0では1.0倍とのことなので妥当な価格である
IOWN2.0では13倍（倍とは？）とのことなので価格も大幅に下がってくれるだろう
逆に現状では一切電力効率は良くなっていないのに同価格で出してきてくれていることは良心的ですらある
ということで大容量・低消費電力に関しては現行と同等もしくは劣っているIOWN1.0だが
遅延に関してはIOWN1.0で1/200を目指している
これはIOWN4.0まで1/200なのでこれより下がることはなく、逆にIOWNの目指している低遅延をローンチから体験できるということになる
さて、低遅延になって誰が嬉しいのかはさておき、現状では東京ー大阪間で15msぐらいである（往復）
これが1/200になると75μsとなるのだが、東京ー大阪間の光の伝搬遅延だけで5msはあるのでいくらIOWNでも光の速度は超えられない
なので機器遅延の10msのみが1/200となるとすると50μsとなり、往復遅延は5.05ms、ほぼ5msぐらいになる
実際に実証実験では8msを実現できたとのことなので大変速くなっているのだろうが
15msが8msになったのを「1/200」と言われるのはモヤッとする
そのせいなのか、「IOWNが提供できる低遅延の価値」という資料では、「映像処理やコーデックに関わる部分を省略できるので実質1/200」という言い方に変えている
つまりは大容量であることを活用して非圧縮で送信すればコーデック部分の処理遅延を減らせるとの主張である
コーデックの遅延は製品にもよるが200〜800msぐらいある
また、超低遅延のコーデックなら10msを実現できるらしい（使ったことはないが）
伝送遅延なんて無視できるほどコーデックの遅延は大きいので非圧縮であれば確かに遅延が1/200になるような体験ができるだろう
ただしそれは従来の100Gbpsネットワークでも実現できる
特にこの手の非圧縮による低遅延化というのは10Gbpsのネットワークを研究する際によく使われた方便で
4K映像を非圧縮で送ると6Gbps消費するため10Gbpsにしましょう、という論法なのだ
それが今の時代では、8K非圧縮は72Gbps消費するから100Gbpsにしましょう、という話なのである
ちなみに8Kで120Hzなら144Gbps必要なのでまだまだご飯を食べられるのだろう
問題なのはこの非圧縮リアルタイム映像伝送はほとんど使われていないということである
コーデックが進化することでコーデックにかかっている遅延は無視できるようになり
特に高精細映像であるほど圧縮率が高くなるのでネットワーク負荷のコストの方が問題になるのだ
なので実際の利用で非圧縮伝送はほとんど用いられておらず、主にネットワークの試験で用いられているのが現状である
まぁこの辺はさておいたとしても、結局はIOWNの実現した大半の価値である低遅延の部分は従来でもやっている技術であって真新しいことではない
それでも従来の100Gbpsでは15msだった遅延が8msになったとなれば1/200とまではいかなくても価値があるだろうか
遠隔での演奏を実験した際の記事が興味深く、8msの遅延ということは3m程度離れて演奏したことになる
この2mに価値があるのだろうか
また、人間の脳のクロック間隔は30msであるという研究結果がある
15msが8msになることで人間に対して何か価値があるのかは甚だ疑問である
問題なのはIOWNではこれ以上遅延が短くなることはなく、既に限界ということだ
光の速度の限界なので当たり前ではあるのだが
限界まで突き詰めても我々のネットワークを介した体験は一切変化しないということを証明してしまったのだ
普通の演奏では低遅延にほぼ価値がないので、エクストリーム分野のe-Sportsとの相性を模索しているように見える
確かにe-Sportsをやっているような人たちは60fpsの1フレームを競っていると言われている
そのためIOWNもe-Sports会場を繋ぐような使い方を例としてあげているのだが
そもそもe-Sportsのゲームソフトウェアは5msだとか8msとかの中途半端な遅延を考慮してゲームを作っているのだろうか
同じL2の下で対戦を行うことが前提なら普通は2〜3ms程度の遅延を前提に設計するので5msでは遅い
逆に遠隔での対戦を考えれば10ms以上の遅延もあり得るのでそのように設計するが
ジャンケンゲームを作るときに2〜3ms程度までなら同時に開示するが
10ms以上なら1秒待ってから開示するような作りになっていると思えば分かりやすいかもしれない
もちろんゲームによってはこの数msで価値が生まれる場合もあると思うが、あまり数は多くないように思える
結局のところ、IOWNは大容量かつ低消費電力、つまりは低価格のサービスとして進んで行くだろう
End-To-EndでIOWNが必要か、と言われると明確に答えはNOで
10Gbpsですら全然普及が進んでいないのに100Gbpsの大容量ネットワークはそもそも必要ない
一方でデータセンタ間のインフラネットワークとしては非常に価値が高い
データのレプリケーションなどを考えれば遅延など1msでも短い方が良いのだ
特に災害が多い日本では地理位置分散をさせることは非常に重要で
そういったデータセンター間のネットワークとして大容量・低消費電力・低遅延なネットワークは非常にありがたいものとなる
こうしたインフラとしての重要性は明確に求められているのにもかかわらず
「IOWN」と標榜してまるで次世代のネットワークであるかのように喧伝しているのは、一体どのような呪いがかかっているのか興味深いところではある。
実際ちゃんと大学行ってれば少なくとも偏差値50以上はあるような人たちだと思う
ある程度の読解力と根気と周辺知識を自分で調べて補うような能力がないとこんな文章は読めるようにならない
お客様独自のドメイン名を使用して、GraphQL エンドポイントにアクセスできます。 AWS AppSync では、お客様の AWS AppSync API でカスタムドメイン名を使用して、GraphQl エンドポイントとリアルタイムエンドポイントにアクセスすることができます。AppSync でカスタムドメイン名を作成するには、所有するドメイン名を提供し、ドメインをカバーする有効な AWS Certificate Manager (ACM) 証明書を示すだけです。カスタムドメイン名を作成すると、アカウントで利用可能な AppSync API にドメイン名を関連付けることができます。AppSync が提供するドメイン名にマッピングするように DNS レコードを更新した後、新しい GraphQL エンドポイントとリアルタイムエンドポイントを使用するようにアプリケーションを設定することができます。アプリケーションを更新しなくても、カスタムドメインの API アソシエーションをいつでも変更できます。AppSync がカスタムドメインエンドポイントでリクエストを受信すると、関連する API にルーティングして処理します。
シェアウェア（という表現はおいておいてのやつ。https://anond.hatelabo.jp/20230124045812）の記事が面白かったので、自分の得意分野の領域でいろいろ紹介します。
基本的に、SaaSのサービスは便利だけど、あれもこれもと契約していったらサブスク破産するので、
もともとownCloudっていうDropbox代替があったんだけど、そこから分派して今も機能開発が続いている。
興味深いのはLAMP構成なので、VPSや自宅サーバーじゃなくても、レンサバで動くのがいいよね。
データ保存領域はオブジェクトストレージ（S3互換）も利用できるので、例えばWasabiなんかと契約してお安く済ませてしまうのも全然アリかと。
最近はカンバンシステムって、単体で使うんじゃなくていろんなアプリの中で使われる印象なので、今更Trelloだけ使いたい、なんてニーズはないかもだけど、
そこまで複雑でなく小規模なプロジェクトとかだと、意外とTrelloだけでいいよね、みたいなこともあるかな。
そういう時は、これを使うといいかも。
ちょっとUIの雰囲気が違うだけで、まんまSlackです。絵文字の追加もできるし、APIもあるし。人によって好き嫌い分かれるスレッド機能も、まあ、あのスレッド機能のまま。
n8nと書いてnodemationと読ませるらしい。初見殺しすぎんだろ。
ZapierやIFTTT、無料枠あるけど、あれもこれもやり出すとすぐ無料枠埋まっちゃうので、これ結構いいと思うんだけどな。
kintone使ってる会社増えてると思うんだけど、まだまだ1ユーザー1500円ってのは高いので、零細企業は導入し辛いと思う。
で、それの代替になるのがExment。UIがkintoneとは少し違うので代替と言い切れないかもしれないが、
やれることはkintoneのソレと全く同じなので、用途代替はできる。
開発も日本企業なので、UIも日本語化されている。LAMP構成なので、レンサバでも動くよ！
そもそもAirtableって何やねんって人もいるかもしれないけど、kintoneとGoogleスプレッドシートをいいとこ取りして、Trelloとガントチャートを足した感じ。
これもまあまあいい感じでZoom再現してます。Zoomの方が新機能の追加早いけど、Jitsiも頑張って追いついている感じです。
ただ、やる内容が複数人でのリアルタイム動画配信なので、サーバースペック・回線スペックはまあまあ必要なので要注意。
こちらは使ったことないんだけど、よりオンライン授業向けらしい。
最近よく見かけるようになった、オンラインミーティングとかの予定をブッキングさせるSaaS。
あれのはしりがCalendlyで、日本でもいくつかそれのSaaSができてますね。
あれらも無料枠だと1カレンダーだけしかできなかったりするんだけど、これなら好きなだけブッキングさせられます。
ECサイトとか、Webマーケティングを重視してるサイトによくある、画面右下に吹き出しアイコンがあって、チャットウインドウがぴょこっと出てくるやつ。
日本ではWeb接客とか言われてるけど、あれの代表的なSaaSがIntercom。Zendeskは、どちらかというと内部ツール向きかな。
これのOSS版がChatwootとPapercups。自社サイトにWeb接客入れたいけど、費用抑えたい、って時にどうぞ。
この手のツールがないと仕事にならないという人も多いと思います。
これまでだとRedmineがそれのOSS版的立ち位置でしたが、さすがにイマドキあのUIはないなぁ、と。
OpenProjectは、Microsoft Projectの代替をイメージしてるみたいですが、
ガントチャートにカンバンがデフォルトで使えるので、BacklogやAsanaの代替にはちょうど良いでしょう。
ただ、そんな高度なことしてるわけではないのに、サーバーの要求スペックはちょっと高めなのでご注意を。
UA廃止でGA離れが始まってるとも聞きますが、疎開先として有名。
PHPで動くので、PHPやWordPressでできたサイトに一緒に入れちゃってもいいと思う。
HeadlessCMSは、データ表示を持たず、フロントエンドへAPIを通じてデータを渡すタイプのCMSのこと。
このジャンルでは、SaaSだとContentfulが有名だけど、OSSでもいろいろある。
Node.js製。歴史があるので、結構いろんなことができる。
WordPressのGutenbergエディターを取り込んだプラグインなんかもある。
User認証も持ってるので、CGM的なサイトを作ろうと思ったらできなくもない。
これもNode.js製。利用できるDBが幅広く、既存のデータベースも活用できる。
なので、既にPostgresSQLとかでデータを持ってるんだけど、
非エンジニアにもデータを触らせるためのフロントエンドが欲しい、ってニーズに良いかも。
PHP製。SQLiteとMongoDBで利用可能。MySQL/PostgreSQL使えないのがちょっと残念。
近年、本腰入れて自社ECサイトをやろうと思うと必ず選択肢に上がるShopify。
インテグレートパートナー向けのエコシステムも充実してるので、取り組み始めるエンジニアやシステム会社も多い。
ヘッドレスコマースや越境ECには向いているものの、これをセルフホストしたい、というニーズに応えたのがmedusa.js。
ざっと見てみただけだけど、モダンな構成で、今時のフロントとバックエンドを分けた構成でやりたい、というのには向いている。
プラグインにmedusa-marketplace.jsというのもあり、Amazon的なマーケットプレイスも実現可能。
昨年、Adobeに買収され、デザイナーたちを驚愕させたFigma。
先日はAdobe XDが終了のお知らせとなり、UIデザイナーたちの不安は募るばかり。
そんな提供企業に振り回されたくないなら、このPenpotでUIデザインしよう。
Figmaほど機能実装はされていないが、まあまあ一通りのことはできる。
Figma代が嵩むとお嘆きの制作会社なんかは、一考の余地あるんじゃなかろうか。
企業によっては、コンタクトフォームをたくさん作りたいという会社もある。
人材採用のフォームを職種別に細かく分けたい（しかも頻繁に募集職種が変わるとか）
Google Formで大体解決しそうだけど、それをGoogleに頼りたくないならこちら。
まあまあ機能豊富なので、人によってはGoogleFormよりもこちらを好むかも。
DockerベースのWebメールUI。送受信に必要なものを、丸っとDockerで用意してくれているので便利。
HubSpotは、いわゆるMarketing AutomationとCRMを一体にしたツール。無料枠もあるが、かなり限定されている。
MauticはMarketing Automationよりの機能が多く、ユーザーのサイト上での回遊をビジュアル化してくれたりする。
SuiteCRMはザ・CRMという感じ。SalesForceをデフォルトで使う感じに近い。
ツールが分かれてしまうのは辛いところだけど、それぞれにAPIがあるので、うまく繋げられると強力なツールになってくれるはず。
Webサービス作ってると、メールの通知や一斉配信などがあると思う。
通常これらはSendGridや、AWS SESなどで処理すると思うが、これらにもOSS代替がある。
PostalはDockerでメール周りのもの全部用意してくれているので、かなり楽。
WordPressをモダンにしたような感じで、EC機能もデフォルトでついてる。マルチサイトも標準。
Jimdo/Wix代替と書いたが、もちろん自分のサイトをMicroweberで作ってもいいが、
自前ホスティングして、JimdoやWixのようなサービスを始めることもできる。
テンプレートをいくつか作っておいて、Stripeを仕込んでおけば、今日からあなたもJimdo/Wixのような事業を始められるわけだ。
JImdo/WixとSTUDIO/Webflowは一緒くたに語られがちだが、明確な違いがある。
前者はプリディファインドなブロックをGUIで構成するのに対し、後者はDOM要素ベースで構築していく。
つまりよりHTML/CSSによる細かなデザインコントロールがしやすく、Webデザイナーが親しみやすい。
それのOSS版がWebstudio。まだアルファ版だが、フロントエンドはそれなりによくできているので、
バックエンドを自前で用意してStripeを仕込んでおけば、今日からあなたも（以下略
Facebookなんか使わねーよ、っていう人も多いかもしれないが、
特定のコミュニティの中でコミュニケーション取るには、FacebookのUIと機能は優れていると思う。
なので、サークルとか同窓会、あと自治会とかPTAなんかにもいいんじゃないだろうか。
Netflixの代替って、Amazon Primeとかじゃねーの、と思われるのかもしれないが、そうではなくて、
あなたがNetflixみたいな商売したいならこれを使うといいよ、というのがJellyfin。
いや、そんな商売しないよ、と思うかもしれないが、
使いようによっては、おじいちゃんおばあちゃん向けの子供動画配信サービスとして構築するとか、
Stripeと連携して、劇団やバンドのオリジナルの配信サイトを構築するなんかも面白いと思う。
今更誰もYouTubeやVimeoの後追いをしようとはしないでしょうが、
複数のユーザーから動画のアップを受け付けて、それを閲覧したい用途もあると思う。
例えば、軽音部で複数のバンドが練習風景を録画したのを定期的にアップしたりとか。
学習塾で、授業の録画を授業ごとにアップしていったりとか。
ZoomやGoogle Meetのような双方向ではなく、一対多の一方通行配信。
個人的には、企業のウェビナーツールとしての可能性を感じる。（Zoomのウェビナープランとか高いもん）
１つのメールアドレスを複数人で運用したい時のツールがメールワイズとRe:lationどちらも日本のSaaS。
FreeScoutはOSSだけど、海外製。一応日本語化もされてるっぽい。
ECサイトの顧客問い合わせや、営業チームのプライマリー対応なんかに良いと思う。
Bubbleってなんぞ？ という人のためにお伝えしておくと、ノーコードベースのWebアプリ開発ツール。
データエンティティを設計したら、自動的にCRUDを作ってくれて、フォームを配置するというような感じ。
Bubbleはそれ系の老舗で、歴史が長い分ノウハウも溜まっており、連携できるサービスも多い。
ただ、ベンダーロックインされるし、季節的なキャンペーンとかでは、アプリを使用しない期間もサブスク費用がかかる。
Budibaseは、Bubbleの思想に一番近い感じ。凝ったUIが必要なければ、ざっくりコレでなんでも作れちゃう。
AppSmithも同じような感じだが、これはDBをあらかじめスキーマ定義しておかないといけないところが若干不便かな。
ToolJetはルーティングURLの概念がなく、本格使用を諦めたんだけど、最近アップデートしたらしいので、そこのところどうなってるかまた確認しときたい。
他にもこの手のやつあったら、いろいろ教えて欲しい。単純に好きなので。
何もしたくない。
仕事なんてしたくない。金も上記ができればそれ以上はいらない。
そうか、今それがいつまでも続かないかもしれないから焦っていろいろ手を出してたんだ。
アニメ、漫画、ゲームをだらだらする生活の維持を第一目標、仕事を限界まで減らすことを上位の目標として
努力すべきだったのか。
達成するためのルーティングができてない。
プログラマとして頑張ることだけでも給料をより多く取得する、自分でアプリを書いて稼ぐ方向等様々だな。
給料路線だと現状の分析と代表的な給料上昇方法である転職時の推測を行う必要がある。
そこに安定動作、PVが稼げる、課金をたくさんしてくれる...
といった縛りみたいなものを追加していくとどんどん難しくなる。
L2はL2全体に、L3は個別にブロードキャストができるって感じで
ルータはいろんなプロトコルを柔軟につなげるためにソフトウェアメインで速度が出ない、
L3はTCP/IPメインでハードウェア的に処理できて高速だけど、他のプロトコルが通せない
って感じであってる？
Web技術なのにクソマ野郎どもはWindowsでも動くのか、AppleのWindows対応はクソだからみたいに言ってて「？」となった
お前らそういうとこやぞみたいな
https://developer.apple.com/videos/play/wwdc2022/10092/
WebAuthnのページのときにChromeがQRを表示するからそれをiPhoneで読み込む(この中に使い捨ての暗号キーが入ってる)
→iPhoneは顔認証したらBluetoothのアドバタイザで応答する(こんときにリレーサーバ、ルーティングIDを暗号する)
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
なんかの機能追加というタスクがあるとまずタスクを分割してTODOアプリに登録する
こんな感じ。できる限り1タスク1～5分くらいで終わる量に分割する
1メソッドが大きい場合は例外処理のみ、DB登録部分のみ、メール送信部分のみとかそれだけでもタスクを分ける。
30秒で終わるようなことでもタスクとして独立してたら分けて登録する
「30分あれば上から12個こなせるな」とか見積もりして該当タスクに印をつけて30分タイマーで都度タイムアタックする
タイムアタックが終わると5分ほど休憩。見積もってた分が30分より早く終わってもその時点で休憩。5分くらい？
Youtube見たり在宅だったらえっちぃビデオ見たり音楽聞いたり好きなことをする。
終わったらまた30分分のタスクを見繕ってタイムアタック。それの繰り返し
ちなみにSlackで問い合わせとか来た場合はその時点で返信より前にTODOとして登録。何故ならそうしないと絶対返信忘れるから。
https://anond.hatelabo.jp/20210617075257
上がってるような基本（元増田に上がってるやつの倍ぐらい）が全部立ち上げからできて
2〜3個プロジェクト経験したらテックリードの素養が既に身についてそう。
プロジェクト的にもどっちかが弱いと
Rails/DjangoにjQuery+Bootstrapみたいな構成や
Amplify/FirebaseにVue/Reactみたいな構成も全然あるので
面接はなんとか抜けてもらうとして、
チーム開発での最低限の目標としては、
成果物から、指導、学習コスト、レビューコスト、技術的負債、マネジメントコストを引いた分が正になっていれば
ひとまず「チームに居ていい人」と見なされそう。
チーム的に良くても、経営層にそれで許されるかはわからんのでその辺の立ち回りも上手いことやるとして、
一旦は、正の生産性を目指してほしい。
以後、ブコメで誰一人一ヶ月でできるって言ってなくて笑うので、
一ヶ月というのは無視して、三〜六ヶ月程度をイメージしつつ書いていく。
似たような言語なのでどっちからやってもいいし、両方同時にやってもいい。
どっちかしかやらないならJavascriptがおすすめ。後ででてくる、Flaskは適当にExpressとかに置き換える
現場だとほぼTypescriptなので、Javascriptはある程度慣れたらTypescriptに移行したほうがいい。
どちらも、Python2とES2015以前の記法というレガシーがネット上に転がってるので参考にしないように注意。
・一貫性があって
・正しい書き方がされた
お手本プロジェクトをなにか(githubや書籍など)で手に入れて読むべき。
おそらくフレームワークに乗っかっているので並行して進めることになる。
話の流れで先にこっち
現在のコーディングのグッドプラクティス、デザインパターンはフレームワークの形をしている。
なので、ReactとVueをその思想から理解しきれれば、プログラミング言語の潮流の最先端に追いつけるはずだ。
TypescriptもVue.jsも書き方をどこまで取り入れるかが使用者の裁量に任されてるし、
開発でVueとReactのどっちを使うかはチーム次第なので、
一旦React+Typescriptでガチガチに書かれたコードプロジェクトを拾ってきて、必死で解読するのがいいと思うなー。
2割ぐらいわかった気になればチーム入ってから(React, Vueどちらだったとしても)動けそう。
パッケージとかテスト、タスク＆デプロイ辺りもこのタイミングで拾ってきたプロジェクトを使って学ぶ。
バージョン管理とコンテナの思想が優れているのは自明なので、これらはツールと見ていい。
そして、後からプロジェクトに入った人がプロジェクトの流儀に沿って使う分には難しいことはなさそう。
採用に来た人がgitとかわかってるとチーム開発経験者だなーって思うし、知らないと未経験者なんだなーって思うし、
そういう意味ではチーム開発の経験があるかどうかの試金石にはされてそう。
構築できる、ではなく、触れる程度で良さそう。
gitはプロジェクトの流儀によると書いたが、git-flowのイメージ図を理解して運用できるのがよい。
https://qiita.com/KosukeSone/items/514dd24828b485c69a05
こういうのができるんだなーって言うのを知っておいて、調べつつ書ければ十分。
あとはシェルスクリプトとかって思ったけど同様のことはPythonでもできそう。
地味にSSHでログインした先の環境だと、vimが主要なテキストエディタになるので
vimを最低限触ることだけ要りそう。もういらないかもって思ってたんだけどなー。
→ ファイル開いて入力モードに切り替えて書き込んで保存して終了
細かく書いたが、LPIC-1の範囲がほどよくまとまっているのでそっちを参照するとよい。
これが意図なら
この辺の機能を持った小規模Webアプリを作ってHerokuでデプロイすれば一旦完成とみなしてよさそう。
コード書き写しただけにならないようには注意しつつだけど、長く見て5人日ぐらい？
慣れると1日あればいけると思う。
フレームワークもなんでもいい。
Djangoとかでも各コンポーネントがどんな働き方してるか程度はわかるだろうしそれで十分。
余力があれば複数個触ってみたり、人から勧められたらそっちでも。
最近はサーバーレス&NoSQLが流行ってるのでFirebaseとかもやればいいと思う。
に尽きる。
計算量を気にしなかったせいで線形検索メソッドとfor文を組み合わせて
それらに対して分散や非同期処理で解消しようとするとか、
ちょっとでもアルゴリズムを触った人ならアホらしいなって思うような行為を
計算量を意識するだけなら、AtCoderのABCのC〜D問題辺りが解ければ十分。
有名な脆弱性や攻撃手法は、ほとんどフレームワーク等で解決手段が用意されている
のでアドリブをせずに正しい書き方でやれば良い。
開発現場でもセキュリティリスクがある箇所を1から自前で実装することを経験が浅い者にはやらせないので、
ただただ、フレームワークが正しいとしているやり方をなぞるのが良い。
開発の勉強のやり方としては、
・正しいコード見本を手に入れること
この辺りの習慣があればやってけんのかな、
その他、チーム開発って面では
TeamGeek（人間性）とかインプットしておくと共通言語が増えて嬉しい。
この方向で進めてけば、その途中で正の生産性≒足引っ張らないぐらいになれるので、
そしたらやってけるんちゃうーって感じ。
取り上げた技術は、本格的な開発でも役に立つもので、最も学習コストが低いものを選んだ。
重要度が低いものは載せていない。たとえばHTMLとCSSなんてググりながら書けば全く問題ない。Bootstrapなどのフレームワークも全くやる必要はなく、仮に就職先で使っていたら覚えればいい。
逆に言えば以下に挙げる技術は、そもそも概念自体がプログラミングにとって普遍的なものであり、（基礎的な部分を）調べながら使うようではエンジニア失格ということ。
基本的に現在では、バックエンド・フロントエンド・運用保守全てができないエンジニアに価値は無い。
以下に挙げた技術（①⑤⑥は他の言語やフレームワークで代替可能）が身に付いていなければまともな企業に就職することは難しい（もちろん、下らない業務システムを下請けで作ってる底辺企業には入れるだろうが）。
経験者でも、これらができない/わからないのは、相当恥ずかしいことだと思った方がいい。
特定の言語やフレームワークの書き方を知っていること自体に意味は無い。
重要なのは、他の言語やフレームワークにも共通する基礎を理解すること・保守性やセキュリティなどの品質を高める使い方ができること。
この2つは習得が容易だし、今覚えておけば向こう10年腐ることはないだろう。
基本的な構文や、よく使う標準ライブラリは勿論、高階関数・クラス・非同期処理等の発展的な機能も知り尽くしていなければならない。
言語のみではなく、パッケージ管理、単体テスト、タスクランナー等の周辺ツールの使い方も熟知している必要がある。
また、「リーダブルコード」や「コードコンプリート」に書いてあるような良い作法も身に付ける必要がある。
Gitを使えないのはプログラマーとして論外。細かい機能は調べればよいが、
多くの場合、本番環境やテスト環境はLinuxサーバーであるから、以下のような基本的な概念と使い方を知っておく必要がある。
環境構築、CI、デプロイなどは、現在コンテナを使って行うことが当たり前になっている。
これも細かいことをすべて覚える必要はないが、Dockerfileの書き方や、docker-composeの使い方などは知っておかなければいけない。
Flaskは、数あるWebフレームワークの中で最も簡単。本当に呆れるほど簡単で、Pythonさえ書ければすぐにアプリを作れる。
フレームワークを覚えること自体が重要なのではなく、Web開発の基本を習得することが重要。HTTP、ルーティング、データベース、SQL、認証、セッション管理などは当然すべて覚える。
データベースは、就職したらMySQLやPostgreSQLなどを使うことが多いかも知れないが、今はPythonの標準ライブラリにあるSQLite3を使えば十分。
作ったアプリを公開したければ、「Heroku」などにデプロイするのが良いだろう。
ブコメで指摘をいただきました。HerokuではSQLite3は使用できないようです。公式のドキュメントに従ってPostgreSQLを使用して下さい。
SQLite3はファイルにデータを持てる簡易DBなんだけど、Herokuにデプロイしてもストレージ的な使い方はできないから、結局PostgreSQLを使う必要あるから注意してね。（DAOを丸ごと書き換える羽目になる）
参考: https://devcenter.heroku.com/ja/articles/sqlite3
今の時代、フロントエンドをフレームワークなしで作るのはただのバカ。
2021年現在、実用的なフロントエンドのフレームワークはReactとVueしかない。Vueの方が少し簡単なのでこちらを選んだが、JavaScriptをしっかり理解しているなら大差は無い。
フロントエンドには膨大なパッケージ群があって全部覚えるのは大変だが、とりあえずまずはVueを完璧に使えればいい。Webpackの設定などは既存のものを流用すればいい。
アルゴリズムは全てのコンピュータ技術の基礎であり、絶対に知っていなければならない。
高速フーリエ変換のような高度な数学は必要ないが、クイックソートや木構造のような基本的なアルゴリズムは当然、その性質を知っていなければならない。
それらは言語の組み込み関数や標準ライブラリでも使われており、理解していなければ、それらの機能を正しく使うことができない。
また、プログラムを読み書きする際には、そのコードの計算量を見積もれなければならない。
セキュリティは言うまでもなく学ばなければならない。
有名な脆弱性や攻撃手法（XSS・SQLインジェクション・CSRFなど）が何だか理解していて、その対策を実装できなければならない。
各種暗号化技術や署名などについても、実装の詳細は知らなくていいが、共通鍵暗号や公開鍵暗号などの特性は理解する必要がある。
