サーバーレスを使っているとインフラをAWSが管理してくれるので、開発者・運用者目線からは、すでに “安全・安心” が得られていると言えなくもないですが、そんな中でいろんなサービス運用者やプロダクト開発者と会話してきた経験談を基に さらなる “安全・安心” を目指すお話しをさせて頂きます。
サーバーレスを “安全・安心” に使う / Serverless Security Pattern
サーバーレスを使っているとインフラをAWSが管理してくれるので、開発者・運用者目線からは、すでに “安全・安心” が得られていると言えなくもないですが、そんな中でいろんなサービス運用者やプロダクト開発者と会話してきた経験談を基に さらなる “安全・安心” を目指すお話しをさせて頂きます。
ts-patternでTypeScriptにパターンマッチングを持ち込み、より型安全な世界へ
0. はじめに 現代のWebアプリケーションの開発言語として、TypeScriptはファーストチョイスの一つです。特殊なケースを除き、フロントエンドの開発言語にはTypeScriptが選ばれるため、言語を統一するメリットを優先し、バックエンドにもTypeScriptが採用されるケースはよく見られます。 またReactがClass Componentを捨てFunction Componentを採用した事件が象徴するように、現代のプログラミングパラダイムのトレンドとして関数型プログラミングがあります。そもそもJavaScriptの出自は、関数型言語をブラウザに搭載できると聞いてNetscapeへ入社したブレンダンアイク氏が、オブジェクト指向言語であるJavaのような言語を会社から要求され、開発したというものです[1]。そのためか、JavaScriptは未だ関数型言語としては未成熟で、関数型プロ
8 AWS Serverless Patterns in Kafka-land
Photo by Thalia Tran on UnsplashKafka is a top-notch industry platform for streaming data processing at scale. No surprise that first-class citizens of Kafka world are 24/7-running producer/consumer applications (e.g. classical servers, k8s-pods, etc.). But what about the rapidly rising world of AWS Serverless ecosystem? Image credit: AuthorThe diagram above is a collection of workflows: Propagate
AWSアンチパターン集 AWS Expert Online 19
[レポート] AWS Data Exchange：クラウドでサードパーティのデータを簡単に見つけて購読する #ANT238 #reinvent | DevelopersIO (classmethod.jp)
マイクロサービス化を目指すなら移行パターンを学ぼう /「モノリスからマイクロサービスへ」を読んだ - kakakakakku blog
2020年12月に出版された「モノリスからマイクロサービスへ」を読んだ．本書はタイトルの通り「マイクロサービス移行」に関連するトピックにフォーカスしている．マイクロサービスを学ぶならこの本！とよく紹介している「マイクロサービスアーキテクチャ」の著者 Sam Newman の続編となる．原著「Monolith To Microservices」は，2019年12月に出版されている． 僕自身は技術講師として「マイクロサービス」に関連した研修を担当していることもあり，本書は絶対に読もう！と楽しみにしていた（原著は読もう読もうと積読していた😇）．今回は本書の翻訳を担当された島田さん (@snoozer05) とレビューを担当されたこまさん(@koma_koma_d) からご連絡をいただき，本書を献本していただいた．本当にありがとうございます！ モノリスからマイクロサービスへ ―モノリスを進化させ
ADOP (Application Domain Others Pattern)
TL;DR ADOP はヘキサゴナルアーキテクチャの実装パターンとして考えられます。 パターンという名前はそれに由来します。 あえて名付けた理由はこぼれ話をご確認いただけると幸いです。 ADOP の概要 ADOP (Application Domain Others Pattern) は中長期的に運用可能なコードへ誘導するアプリケーションアーキテクチャパターンです。 ADOP は次の特徴があります。 最小限のルールである 指針が明確である 特定の技術スタックに縛られない テスタビリティが確保される これらの特徴は、コードを自然と中長期的に運用可能なコードへ導きます。 まず、簡単にそれぞれがどういった意味を成すのかを確認してきましょう。 最小限のルールである どれほど完璧な作戦であっても、その実行が不可能であれば何の意味もありません。 プログラミングにおいてもそれは同じことで、制約を守るため
パフォーマンス分析に関するアンチパターン - 勘と経験と読経
いくつかの書籍に書かれたパフォーマンス分析に関するアンチパターンを整理してみた。ここに無いものでご存知のパターンがあればご教授いただきたい。アーキテクチャや組織のパターンはよく見るけど、対応手法に関するパターンってあんまり多くないのかも（もしくは単にアンテナ感度が悪いだけ？） 詳解 システム・パフォーマンス (Systems Performance: Enterprise and the Cloud)より 詳解 システム・パフォーマンス 作者: Brendan Gregg,西脇靖紘,長尾高弘出版社/メーカー: オライリージャパン発売日: 2017/02/22メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 第2章 メソドロジでいくつかアンチパターンが紹介されている(アンチではないほうのパターンも)。 書籍の内容の一部は、以下の翻訳記事および元ネタ記事と同様と思われる
A class-based enum pattern for JavaScript
In this blog post, we examine a pattern for implementing enums in JavaScript that is based on classes. We’ll also take a look at Enumify, a library that helps with the enum pattern. Implementing enums: first attempts # An enum is a type that consists of a set of values. For example, TypeScript has built-in enums and with them, we can define our own boolean type: enum MyBoolean { false, true, } Or
Serverless Microservices - Saga Transaction - Qiita
CloudNativeがここまで進化するとインスタンスの仮想化技術をベースとしたシステムなど使いたくなくなってしまいます。 私は新たにシステムを構築する際、必ずServerless Firstの考え方で設計をしていきます。 その中でAWS Lambda、Amazon DynamoDBを中心にMicroservicesの設計をしていくのですが、 ACIDの部分をどう対処するかが一番悩むところです。 今回はServeice間のTransactionに関する話を自分なりに整理していきたいと思います。 図1 Saga Design Pattern Sagaは複数のサービスにまたがるトランザクションを実装するためのマイクロサービスアーキテクチャパターンです。 複数のマイクロサービス間でデータ一貫性を実現するもので、Sagaには２つのパターンがあります。 1. Choreography-based S
コンテナのデザインパターンを学べる論文「Design patterns for container-based distributed systems」を読んだ - kakakakakku blog
2016年に USENIX Conference で発表された論文「Design patterns for container-based distributed systems」を読んだ．タイトルの通り，コンテナのデザインパターンがまとまっていて，これからコンテナ設計をする人も，既にコンテナを運用している人も，デザインパターンを学べるのは価値があると思う．一部ミスリードをしているかもしれない． Design patterns for container-based distributed systems 論文も公開されている． https://static.googleusercontent.com/media/research.google.com/ja//pubs/archive/45406.pdf パターン一覧 Single-container management pattern
Serverless Microservice Patterns for AWS - Jeremy Daly
Serverless Microservice Patterns for AWS Serverless microservices allow us to do some pretty amazing things. This post outlines 19 common patterns that are being used in production on AWS. UPDATE: I've started the Serverless Reference Architectures Project that provides additional context and interactive architectures for some of theses patterns along with code examples to deploy them to AWS. Chec
マイクロサービスの思想から捉える Backends for Frontendsとその類似パターン / Backends for Frontends and its similar pattern from the microservices perspective
UIT#3 The “Backends for Frontends” sharing
The Ruby Module Builder Pattern
There’s an interesting pattern I’ve discovered recently in Ruby that is very powerful, yet apparently not widely known or appreciated.1 I call this pattern the Module Builder Pattern. I’ve used it heavily in designing Mobility, a pluggable translation framework I released a couple months ago, and it served me so well I thought I should share what I’ve learned. At its core, the Module Builder is an
Go言語のFunctional Option Pattern - Qiita
オプション パッケージを作る際、柔軟性を持たせるためにオプションを持たせたい時がしばしばあります。 しかしオプションは知っての通り設定しないことが少なくありません。 単にコンストラクタに並べるようでは無用な複雑さをはらむことになります。 JavaなどではOptional Parameterなどのように、デフォルト値が指定できる機能があります。 機能の厳選されたgo言語ではそのような機能はありませんが、 "Self Referential Functions Design"というテクニックがあり、 それについての記事がRob Pike氏の記事を筆頭にいくつか説明されています。 オプションと相性が非常に良いため、合わせて"Functional Option Pattern"とも呼ばれています。 Dave Cheney氏の記事を参考におおまかに説明したいと思います。 様々な解決策 あるServe
GitHub - jbuberel/go-patterns
Go Examples of Common Patterns This is a collection of common design patterns translated into Go. The goal of this repository is to help programmers coming from other language communities understand how their favorite patterns can be reused in Go. We do not intended to be restrict this to the traditional GoF Design Patterns. We hope to include any language idiom you'd like to see re-implemented in
Google Sites: Sign-in
Not your computer? Use a private browsing window to sign in. Learn more
Go言語での構造体実装パターン
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン 実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数 エクスポートによるアクセス許可 インターフェースによるポリモフィズム 構造体によるポリモフィズム 構造体によるサブクラス・レスポンシビリティ 構造体による移譲 関数による移譲 以下、それぞれのパターンを解説していきます。 コンストラクタ関数 Go言語には構造体のコンストラクタがないため、構造
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - gvergnaud/ts-pattern: 🎨 The exhaustive Pattern Matching library for TypeScript, with smart type inference.
Rustのパターンっぽいやつメモ
GitHub - fbeline/Design-Patterns-JS: All the 23 (GoF) design patterns implemented in Javascript
