コンポーネントの分類について考えたことをまとめた
どのようにコンポーネントを分類していくか 個々のコンポーネントがが単一の責任のみ負っている状態であれば、コードの見通しも良くなる上、後々のメンテナンスも容易です。 まずは「複数の関心ごとを１つにまとめない」という原則（単一責任の原則）から分類の指針を考えていきます。 フロントエンドにおける関心ごとですが、大別すると APIとの接続 View（表示とイベント実行） 状態管理 以上３つに集約されるのではないでしょうか。 では、これらの関心ごとをどの様に切り分けていけば良いのか考えていきます。 APIとの接続 まずはAPIとの通信ですが、こちらはコンポーネントの外で管理した方が良いと考えています。 各コンポーネントに通信に関わる処理がベタ書きされている状態だと、エンドポイントの変更等に弱くなり、通信処理の再利用も面倒です。 それに、「フロントの状態管理 / 表示」と「外部との接続」はそれぞれ別種
Docker Desktopの代替方法 - Windows and Mac編
はじめに 新方針でDocker Desktopが大企業での利用の場合は商用ライセンスの使用が必要になるようです。新料金体系は8/31から実施ですが、2022年1月31日まで猶予期間があります。 個人やスモールビジネス、あるいは教育やOSSプロダクトなどは継続して無料版のPersonalを利用できるようですが、従業員数250人以上/年間売り上げ10億円以上の会社が対象になるようです。今見てる限りだと部署とかチームみたいな契約の単位では無く会社規模なので、大きな組織に所属してるともれなく対象になりそうですね。 $5/userからなので基本的には運用性も含めて払う方が楽だと思いますが、金額の大小にかかわらず予算を取るのが大変な組織や会社自体はデカくても部署がインキュベーションなので予算が基本無い、とか色んなパターンもあるかと思います。 ちょうど、手元のPCでここ最近 Docker Desktop
Kubernetesの仮想クラスタについてとりとめもなく語る
KubeCon EU 2021というイベントが先日行われ、その基調講演の中でRed Hatの人によるThe Hybrid Control Plane という短いセッションがあった。 内容をかいつまんで紹介すれば、①Kubernetesのコンテナ管理機能をコンテナに限らず汎用的に使えるように拡張したら、②リソースやクラスタの管理で生じる問題が解決できるのではないか？という問いかけだ。 ①Kubernetesのコンテナ管理機能とは、マニフェストファイルによる宣言的な設定や、状況に応じて自動的にコンテナが再配置されるリコンサイルループによる自動調整機能だ。説明はKubernetesがいかに自動化の考え方を変えたか?という記事が詳しい。 ②リソースやクラスタの管理で生じる問題とは、マルチテナントやマルチクラウドを考えると分かりやすい。複数の動作環境、複数のチームを横断的に監視、管理するための組織が
How I Dockerized my Next.js website?
Learn how to use Docker to create images for development and production. Imagine that you have developed a full fledged working application and want other developers to contribute to the project. Now if the application consists of different components like UI, running server, database etc. The new developer should install the exact configuration of the entire stack on to his/her system before star
Storybook First な開発のススメ
Storybook first な開発とは Storybook での呼び出され方を意識しながらアプリケーションコードを書くことをそのように呼んでいます。 道具に設計がひきづられるのはアンチパターンと言われそうな気もするのですが、コンポーネントのカタログを整備していくことは、コンポーネントが良い感じに再利用可能な形で分離できるということでもあり、やっていくとむしろ正道に近づいていくと思います。 Storybook First のコンポーネント設計や型定義をすると、パーツに限らず Storybook でカバーできる範囲が広がり、ページそのもののサンドボックスを作れます。 そして API がない状態でもデータを使って開発ができたり、特定のスナップショットの再現やタイムトラベルに近いことも可能になるというメリットがあります。 つまり、ただのコンポーネントカタログとしてではなく、開発のためのサンドボ
KubernetesのDockershim廃止における開発者の対応 - inductor's blog
はじめに 今朝に書いたブログが思ったより反響が大きくて、「Dockerが死んだ」という勘違いをされている方も多かったので追加でエントリーを書きました。 blog.inductor.me 決してそんなことはないので、対応が必要なケースを見ていこうと思います。 はじめに 対応が必要ではないケース Kubernetesを使わない人たち 本番はKubernetesでも、開発にDocker Composeを使っているデベロッパーの開発環境 対応が必要なケース 開発環境でも手元でKubernetesを利用する人たち NVIDIA DockerをKubernetesで使っている人たち Kubernetesワークロードの中で「Docker in Docker」や「Docker APIに依存した処理」を動かしている場合 Dockerの機能を使ってこれまでやっていたことについて 対応が必要ではないケース Ku
Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ - Cloud Penguins
今話題のこれ。 kubernetes.io これに関しての日本語情報として、 @inductor が相当詳細に記事を書いてくれている。 blog.inductor.me blog.inductor.me にも関わらず、未だに完全に間違った解釈をしている人が多く観測される。記事をちゃんと読めば理解できるはずなのだけど、たぶんタイトルしか読んでいない。 タイトルしか読まないのであれば、あえて強めのタイトルにしておけば目にはつくかなと思い、改めて書いてみることとした。 Dockerは非推奨じゃないし、これからもバンバン使え まず @inductorが解説しているとおり、k8sを使っていない人には全く関係のない話なので、今まで通りDockerを使って良い。 が、もう一つ誤解を解いておきたいのが 自分の環境でDockerを使ってイメージ作成し、Kubernetesにデプロイしている人にも、今回の件は
1年間の本番運用でわかったコンテナがチーム開発にもたらしてくれたもの/container-brought-to-team-development - Speaker Deck
Japan Container Days v18.12での発表資料です
コンテナを丸裸にする方法（モニタリング、ロギング、デバッグ）と関連ツールの紹介 #reinvent #CON320 | DevelopersIO
今回のre:Invent2017でも、コンテナ関連について、かなり重要な新サービスやアップデートが多数発表されましたね。 【速報】AWSのマネージドKubernetesサービス、Elastic Container Service for Kubernetes(EKS)が発表されました！ #reinvent ｜ Developers.IO 【速報】新サービスAWS Fargateが発表されました！！ #reinvent ｜ Developers.IO そんななか、改めてコンテナの中身のログを取得してデバッグするための手法について解説したセッションに参加したので、その内容をご報告いたします。 CON320 - Monitoring, Logging, and Debugging for Containerized Services セッション概要はこちら。 As containers beco
Amazon EC2 Container Service(ECS)のデータモデルについて整理した | DevelopersIO
はじめに Amazon EC2 Container Service(以降ECS)はAmazon EC2上でDockerコンテナを稼働・管理するためのサービスです。私は最近ECSをよく触っており社内外の啓蒙活動も行っているのですが、「TaskとServiceってどう違うの？」「ECSのデータモデルがよくわからない」といったフィードバックを何度かもらいました。今日はECS学習のとっかかりとして、ECSで使われる概念について整理してみました。 概念 Task 前述の通り、ECSはDockerコンテナを起動、管理するためのサービスです。Dockerのベストプラクティスとして、基本的には1コンテナ1サービスであることが公式に推奨されています。 It is generally recommended that you separate areas of concern by using one ser
"Docker is NOT Container." ~ Dockerとコンテナ技術、PaaSの関係を理解する
1. "Docker is NOT Container." ～ Dockerとコンテナ技術、PaaSの関係を理解する レッドハット株式会社 中井悦司 / Etsuji Nakai Senior Solution Architect and Cloud Evangelist v1.3 2015/01/28 2. 2 "Docker is NOT Container." ～ Dockerとコンテナ技術、PaaSの関係を理解する 自己紹介 中井悦司（なかいえつじ） – Twitter @enakai00 日々の仕事 – Senior Solution Architect and Cloud Evangelist at Red Hat K.K. 企業システムでオープンソースの活用を希望される お客様を全力でご支援させていただきます。 昔とった杵柄 – 素粒子論の研究（超弦理論とか） –
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
