I was thinking the same; there are so many articles explaining the basics.
For me it would be more helpful to start off with a real-life scenario where the mentioned method can be applied and even might excel compared to other methods; bonus points if you also explain what properties of the method make it so very well-suited for the specific real-life scenario.
There are so many methods in data science / machine learning and from what I remember from my university days one of the difficult tasks was to know when to use which method, depending on the properties of your data and on what you want to achieve; additionally, sometimes you also need to optimize/improve the method's hyperparameters and that's almost a whole separate discipline by itself.
Nonetheless, the posted article contains a lot of valuable information for a beginner, so it's definitely a good start.
> I don't think I'd add it there, isn't it handled by firewall / infrastructure than app directly?
Although most DDoS attacks happen on the layers 3, 4, and 6 of the OSI model, your application still has to be hardened against resource exhaustion and other DDoS attacks.
For example, if you have a REST endpoint that starts a complex query which might return a large result given some specific query parameters (e.g. your limit parameter is not bound, so I can set limit=1000000), running 10000 requests against it from different hosts (malicious or not) may bring down your database server.
Looks good from a first look at it, congrats on launching it!
Just checked if you mention bounces and saw that you track bounces; how does your app show / keep track of the bounces and more importantly of the bounce rate in general?
I'm mentioning this since Amazon SES will place your account under review if your bounce rate is 5% or greater; you can find a few useful links on this comment thread: https://news.ycombinator.com/item?id=21955614
Best of luck with your app!
Disclaimer: I was responsible for the implementation of an e-mail notification system using Amazon SES.
You can subscribe to post backs from SES. These post back tell you message-by-message if a message was delivered/bounced.. so "simple" process of storing the results. Need to track the unique message ID, some you might get multiple responses for the same message (e.g. delivered, then marked spam)
There might also be a CLI call to get summary stats.
Exactly, that's what we did with our solution, too; we maintaned our own bounce list with a TTL that we kept up-to-date by subscribing to SNS notifications generated by SES.
My question was aimed towards the bounces feature presented on the app homepage [0]; if you ignore (or don't realize the importance of) the bounce rate you might shoot yourself in the foot.
No, this is not the way to handle this. Please read up on how you must treat bounces on AWS SES or you face an account stop/closure. E.g. you MUST remove addresses from future sending once they permanently bounce.
Offering a software solution without offering a feature for correct bounce handling is just naive.
Your features list is a bit misleading, then. On your app's homepage you specifically mention the tracking of bounces as part of the app's features.
I'm all for launching early and so on, but I have a feeling that this is a rather important feature to simply be omitted in the beginning, especially in regard to Amazon SES and their handling of exceeding bounce rates.
I think openness to experience is only one part of the equation. There are other parts, e.g., what are your goals? How do you deal with your emotional state if the experience doesn't go your way? And many more. It's quite complex.
There is a treatment called exposure therapy [0] which actually is used to threat anxiety and for one helps with emotional processing.
Good point! Sadly, I don't have access to the Harvard study (https://pubsonline.informs.org/doi/10.1287/mksc.2019.1200), so maybe someone with access to it could check it, but the linked article might be misleading in some aspects (depending on the results of the study shown in the paper).
From the study's abstract:
> A preregistered field experiment indicated that diners were 21.1% more likely to buy a bowl of chicken noodle soup when a sign revealing its ingredients also included the cafeteria’s costs to make it.
From the linked article's sub-title:
> Sales of a chicken noodle soup increased 21.1% when people were shown the costs of making it.
The study's abstract mentions that they were more likely to buy a bowl of chicken; it's not mentioned that they actually bought it.
> People said they were 14.2% more likely to buy this chocolate bar when they were shown the version with a cost breakdown
Surely that cannot be correct. Possibly 14.2% of the people who were asked said that they would be "somewhat" more likely to buy X with more data stuck to its label (does any data improve sales? Did they A/B the label by adding random info?). This is very different from them acting upon it though.
Actually, the figure 14.2% does not even appear in the research article. The experiment was between two groups of random Mechanical Turk workers: one group was not shown the cost breakdown while the other group was. The workers answered how likely they were to buy the product on a scale from 1 to 7. If you calculate the average increase from one group to the other, sure enough the number you get is 14.2% but it is not a probability.
There's even a third option when you bet on people: The company can get acqui-hired by a bigger fish who's already a big presence within the almost same problem space.
