CodyReichert

I wrote a separate article about our thoughts on disposable email addresses: https://medium.com/@CodyReichert/the-case-for-and-against-di...

Depending on the nature of the service, you don't always want to block disposable emails. We built Identibyte to give us the flexibility to act on certain types of email addresses and provide a better experience depending on the type of user.

Hey all! We created Identibyte because it seems like every time we build a new product, we have to add a little code to make sure we're handling disposable email address accounts.

I love disposable emails, and I think it's great people use them to try out a service. We want to help companies (and anyone running a site with a signup form really), manage these better.

A lot of times users signing up with disposable emails don't need the time and attention that other users do - they just want to try out the product with little interruption. We encourage that!

Identibyte aims to helps the companies manage these accounts better. By pointing out information like this, you can focus your resources on the users who WANT and NEED it - instead of spreading everything evenly.

We've implemented this in our products by deleting disposable accounts after a certain time of inactivity. This helps us, and doesn't block people who just want to try out a product! Users who like the product almost always change their email to a real one.

I'd love to hear if this is something you would do, as opposed to completely blocking these signups?

Very well explained, thanks

You could have a second bot that posts a comment in the thread each time with something like: "See, this is why you shouldn't use hosted services for your core infrastructure." Lots of karma to be had there as well.

Yeah it's funny, my first thought was since I started using Arch, the most common thing I hear people say is that packages from AUR should be considered unsafe until you've read the PKGBUILD, at least. It's a good thing it gets brought up so much, unfortunately.

This specific point got me as well: I can't really get behind a company - especially a CDN company - telling people to break the specific because "no browsers don't do anything with it." That is, honestly, really bad advice and I can't take any of their other points seriously.

Agreed - they reason they "jumped-ship" was not to address the root issues. It was to address to hit on their vanity for working for a company that is currently in a bad light.

It says more about the individuals than it does about the company.

This is just you trying to get an answer you knew you wouldn't get.

"Connecting the world!" is indeed the job of almost all employees at Facebook. You can have a large majority of the company focus on this one goal, and also know that the byproduct of that goal allows you to expand another part of a bigger goal: to make more money on ads.

A company in a capitalist economy must make money, of course. No one is arguing that and no one is saying that Facebook doesn't want - indeed must - make money.

It's like asking an Uber driver what is job is: "to transport people!". Of course, that much is obvious. If you ask someone in the "growth" department (or whatever) what their job is - the description will necessarily be much different.

No that's perfect and it agrees with my thought that having an archive available online is valuable.

Just put up a sample issue page (as best I can for now) and I'll find some way to post them automatically as they're sent.

Thanks again!

Awesome, I love your newsletters!

Thanks for the tip - I'm finalizing the first issue right now so I'll get it on the site asap as an example. Makes sense :)

iirc, you make all of the issues available online after the fact, right?

Hey HN - I wanted to start this newsletter because, well, I spend a lot of time reading articles related to QA testing, new practices in automation, and just generally have a passion for correctness in software. So I figured I might as well send them out to anyone else that's interested :)

The first issue goes out tomorrow - would you mind giving me some thoughts on the landing page and description of the content?

AWS's status page is (unbelievably) reporting it now: https://status.aws.amazon.com/

1) Superintelligence. This is a really great read about the implications of AI, or general intelligence. It's really intriguing and brings up so many scenarios I've never thought about. Anyone interested in AI should definitely read this.

Similarly, On Intelligence is an absolutely brilliant book on what 'intelligence' is, how it works, and how to define it.

2) Hooked. Although it's very formulaic, Hooked provides a lot of good ideas and approaches on building a product.

3) REWORK. If you're a fan of 37 Signals and/or DHH, this is a succinct and enjoyable read about their principles on building and running a business.

Currently I'm reading SmartCuts and The Everything Store - both of which are great so far.

I'm about 75% of the way through SmartCuts and I love it! I really enjoy this type of format, but the people and stories Shane chose are just great. +1 recommendation.

Have you tried (or is an option for you) to use parallel builds?

Author here! This post goes over using Assertible to run automated smoke tests after deploying an app from Codeship.

Do you or your team have a similar approach to deployment testing?

The code for the tutorial is on GitHub: https://github.com/assertible/ruby-example

I've picked up several things on Noun Project - good to actually see that the designers get compensated for that, even if it is just beer money :)

To start things off, these are the ones I use daily:

- CircleCI for CI build status

- Coveralls for unit test coverage

- Assertible for integration tests status

For example: http://i.imgur.com/ZrKUK3t.png

Any new ones I should check out?

One of my favorite parts of this is that, after you import a Swagger, you can initiate the tests from CI - effectively validating your API backend after a deployment.

Interested to hear what other automation and testing can be done from a Swagger spec.

I'd be interested to know this as well. I've been solving this problem while building Assertible; generate a suite of API tests from a Swagger spec: https://assertible.com/blog/testing-an-api-using-swagger

We've been working on API test automation for a while and this is one of my favorite integrations so far.

The idea is that, after deploying from CI or a script, Assertible runs a series of integration/smoke tests against the app and reports the result back to GitHub via a status check.

Here's an example of a failing status check on a Go API: https://github.com/assertible/go-heroku-example/pull/5

Having immediate feedback on an actual live deployment has saved us a lot of time from manual testing.

Would love to hear your thoughts!

Another one for Google that's really interesting is their testing blog: https://testing.googleblog.com/

We created an integration with GitHub that automatically runs tests against a web service when a repository is 'deployed'. In short, this is how the workflow looks:

- Push code to GitHub

- Build and deploy code on CI

- Send a deployment event to the GitHub repository

- Assertible automatically runs tests on the web service

We've got some configurations with popular CI providers, like Travis and Wercker here: https://github.com/assertible/deployments

Would love to hear your thoughts on this!

It's in the works, and will be the greatest workflow of all time ;)

In all seriousness though, I'm loving Codeship and it's concept of "pipelines". Really looking forward to working with it more.

Author here - I'm planning a couple new guides with other CI/CD services (like Codeship). Any thoughts on what pipelines/workflows could use a good example?

Well he does use an Android, so it wouldn't surprise me if that was 100% correct.

More like, so you don't use a phone then?

Stripe allows you to store 'metadata' (key/value pairs of arbitrary data) with customers. Wouldn't that work for storing addresses?

https://stripe.com/docs/api#metadata

Hey HN, author here! This method of inlining CSS for email templates has been serving us well for a while now at Assertible. All of our emails are created with React components and then compiled down to static markup; with dynamic data injected via props.

I'm interested to hear some other ways people have achieved this, or answer questions for anyone looking to do something similar!

Hey, thanks for the feedback. In the future we hope to allow a bit more functionality before requiring an email to be verified! (FWIW, GitHub login does the verification for you).