Zero To Production #2: Learn By Building An Email Newsletter

栏目: IT技术 · 发布时间: 4年前

内容简介:Zero To Productionis a book that I will be writing in the open, publishing one chapter at a time on this blog. If you’d like to be notified when an episode comes out you can subscribe to the mailing list:The Foreword stated that

Zero To Productionis a book that I will be writing in the open, publishing one chapter at a time on this blog. If you’d like to be notified when an episode comes out you can subscribe to the mailing list:

Chapter #2

    • 1.1. Problem-based learning
    • 1.2. Course-correcting
  1. What Should Our Newsletter Do?
    • 2.1. Capturing requirements
  2. Working In Iterations

1. Our Driving Example

The Foreword stated that

Zero To Production will focus on the challenges of writing cloud-native applications in a team of four or five engineers with different levels of experience and proficiency.

How? Well, by actually building one!

1.1. Problem-based learning

Choose a problem you want to solve.

Let the problem drive the introduction of new concepts and techniques.

It flips the hierarchy you are used to: the material you are studying is not relevant because somebody claims it is, it is relevant because it is useful to get closer to a solution.

You learn new techniques and when it makes sense to reach for them.

The devil is in the details: a problem-based learning path can be delightful, yet it is painfully easy to misjudge how challenging each step of the journey is going to be.

Our driving example needs to be:

  • small enough for us to tackle in a book without cutting corners;
  • complex enough to surface most of the key themes that come up in bigger systems;
  • interesting enough to keep readers engaged as they progress.

We will go for an email newsletter - the next section will detail the functionality we plan to cover.

1.2. Course-correcting

Problem-based learning works best in an interactive environment: the teacher acts as a facilitator, providing more or less support based on the behavioural cues and reactions of the participants.

A book, published on a website, does not give me the same chance.

I truly appreciate feedback on the material - please reach out to contact@lpalmieri.com or send me a DM on Twitter .

Providing feedback is, at this stage, a tangible way to contribute to Zero To Production .

2. What Should Our Newsletter Do?

There are dozens of companies providing services that include or are centered around the idea of managing a list of email addresses.

While they all share a set of core functionalities (i.e. sending emails), their services are tailored to specific use-cases: UI, marketing spin and pricing will differ significantly between a product targeted at big companies managing hundreds of thousands of addresses with strict security and compliance requirements compared to a SaaS offering geared to indie content creators running their own blogs or small online stores.

Now, we have no ambition to build the next MailChimp or ConvertKit - the scope would definitely be too broad for us to cover over the course of a book. Furthermore, several features would require applying the same concepts and techniques over and over again - it gets tedious to read after a while.

We will try to build an email newsletter service that supports what you need to get off the ground if you are willing to add an email subscription page to your blog - nothing more, nothing less.

2.1. Capturing requirements

The product brief above leaves some room for interpretation - to better scope what our service should support we will leverage user stories .

The format is fairly simple:

As a …,  I want to …,  So that …

A user story helps us to capture who we are building for ( as a ), the actions they want to perform ( want to ) as well as their motives ( so that ).

We will fulfill three user stories:

  • As a blog visitor, I want to subscribe to the newsletter, so that I can receive email updates when new content is published on the blog;
  • As the blog author, I want to send an email to all my subscribers, so that I can notify them when new content is published;
  • As a subscriber, I want to be able to unsubscribe from the newsletter, so that I can stop receiving email updates from the blog.

We will not add features to

  • manage multiple newsletters;
  • segment subscribers in multiple audiences;
  • track opening and click rates.

As said, pretty barebone - nonetheless, enough to satisfy the requirements of most blog authors.

It would certainly satisfy mine for Zero To Production itself.

3. Working In Iterations

Let’s zoom on one of those user stories:

As the blog author,  I want to send an email to all my subscribers,  So that I can notify them when new content is published.

What does this mean in practice ? What do we need to build?

As soon as you start looking closer at the problem tons of questions pop up - e.g. how do we ensure that the caller is indeed the blog author? Do we need to introduce an authentication mechanism? Do we support HTML in emails or do we stick to plain text? What about emojis :scream:?

We could easily spend months implementing an extremely polished email delivery system without having even a basic subscribe/unsubscribe functionality in place.

We might become the best at sending emails, but nobody is going to use our email newsletter service - it does not cover the full journey.

Instead of going deep on one story, we will try to build enough functionality to satisfy, to an extent , the requirements of all of our stories in our first release.

We will then go back and improve: add fault-tolerance and retries for email delivery, add a confirmation email for new subscribers, etc.

We will work in iterations: each iteration takes a fixed amount of time and gives us a slightly better version of the product, improving the experience of our users.

Worth stressing that we are iterating on product features, not engineering quality: the code produced in each iteration will be tested and properly documented even if it only delivers a tiny, fully functional feature.

Our code is going to production code at the end of each iteration - it needs to be production-quality.

3.1. Coming up

Strategy is clear, we can finally get started: the next chapter will focus on the subscription functionality.

Getting off the ground will require some initial heavy-lifting: choosing a web framework, setting up the infrastructure for managing database migrations, putting together our application scaffolding as well as our setup for integration testing.

Expect to spend way more time pair programming with the compiler going forward!

Zero To Productionis a book that I will be writing in the open, publishing one chapter at a time on this blog. If you’d like to be notified when an episode comes out you can subscribe to the mailing list:

Book ToC

The Table of Contents is provisional and might change over time. The draft below is the most accurate picture at this point in time.

  1. Getting Started
    • Installing The Rust Toolchain
    • Project Setup
    • IDEs
    • Continuous Integration
  2. Our Driving Example (this blog post)
    • What Should Our Newsletter Do?
    • Working In Iterations
  3. Sign Up A New Subscriber
    • Application Scaffolding
    • Our First Integration Test
    • Reading Request Data
    • Adding A Database
    • Persisting A New Subscriber
  4. Publish A Newsletter Issue
    • Writing A REST Client
    • Mocking Third-Party APIs
  5. Logging
    • The Facade Pattern
    • Logging Levels
    • Log Setup
  6. Reject Invalid Subscribers
    • Result
    • Modeling With Types #1
  7. Survive Delivery Failures
    • Simulating API Errors
  8. Tracing
    • Structured Logging
    • Spans
    • OpenTelemetry
    • Jaeger
  9. Send A Confirmation Email On Sign Up
    • Migrating Your Database
    • Modeling With Types #2
    • Handling Confirmations
    • Send Newsletter Only To Confirmed Subscribers
  10. Metrics
    • Prometheus
    • Grafana
  11. Send Emails Asynchronously
    • Adding A Message Broker
    • Enqueueing Tasks
  12. Fulfilling Email Tasks
    • Adding An Actor Queue Worker
    • Basic Retries
    • Failure Injection
    • Idempotency
  13. Benchmarking
    • Cargo bench
    • Criterion
    • Load testing

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

阿里巴巴Java开发手册

阿里巴巴Java开发手册

杨冠宝 / 电子工业出版社 / 2018-1 / 35

《阿里巴巴Java开发手册》的愿景是码出高效,码出质量。它结合作者的开发经验和架构历程,提炼阿里巴巴集团技术团队的集体编程经验和软件设计智慧,浓缩成为立体的编程规范和最佳实践。众所周知,现代软件行业的高速发展对开发者的综合素质要求越来越高,因为不仅是编程相关的知识点,其他维度的知识点也会影响软件的最终交付质量,比如,数据库的表结构和索引设计缺陷可能带来软件的架构缺陷或性能风险;单元测试的失位导致集......一起来看看 《阿里巴巴Java开发手册》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具