Thanks for the report, this should be fixed now!

Yep fixed!

We've adjusted it so that the CLA can now be viewed without signing in.

Sorry about that!

WorkOS (https://workos.com/) if you need to support single sign-on (SSO) for your app.

SSO is free, and they offer other enterprise-focused features, like directory sync and audit trails.

How would that compare to keycloak?

I'm not familiar with Keycloak. I glanced at their docs briefly, and it looks like Keycloak manages your users for you?

WorkOS only handles SSO, so all of our users are still stored in our own database. This is one of the big reasons we went with WorkOS as opposed to something like Auth0 or AWS Cognito.

Yes. This is exactly what we do at work.

It makes sure that you never pass a `LocationId` where a `UserId` is expected; the type system literally will not allow it.

You can also use Fable (https://fable.io/) to compile F# to JS.

Dark looks really cool. When I heard about it before my initial reaction was a huge "nope", but after watching the videos I'm curious to try it out.

It's amazing just how little friction there is for you to get an API endpoint backed by a datastore up and running. That being said, there are a bunch of unknowns. Having my entire application, even down the language it's implemented in, being proprietary is a little scary.

Will definitely be looking forward to playing around with this. Just as soon as I get my signup email ;)

You might want to check out the serverless framework.

It's not remotely as unique as you seem to think, as even that framework is just one of many.

https://serverless.com/

The problem I have with this style of validation is that it doesn't "make illegal states unrepresentable". If the validation is not run then it is still possible for instances of `ContactData` that violate the business rules to enter the system.

  > Our reservation business requires that contact data entities are only accepted if all of the following conditions are satisfied:
  >
  > - The e-mail address is valid
  > - The phone number is valid
  > - Either e-mail address, or phone number, or both are present

In this case, all of the above rules can be encoded into the type system itself. Here's how I would approach this particular problem:

  struct PhoneNumber(String);
  
  impl PhoneNumber {
      fn new(value: String) -> Result<Self, ValidationError> {
          if is_valid_phone_number(value) {
              Ok(Self(value))
          } else {
              Err(ValidationError)
          }
      }
  }
  
  struct EmailAddress(String);
  
  impl EmailAddress {
      fn new(value: String) -> Result<Self, ValidationError> {
          if is_valid_email_address(value) {
              Ok(Self(value))
          } else {
              Err(ValidationError)
          }
      }
  }
  
  enum ContactData {
      PhoneOnly(PhoneNumber),
      EmailOnly(EmailAddress),
      PhoneAndEmail {
          phone: PhoneNumber,
          email: EmailAddress
      }
  }

This approach, when applied alongside Rust's modules and visibility modifiers, would make it impossible for any of these types to be in an invalid state.

Here is what I'm going to focus on in 2018:

- Work less, achieve more

- No alcohol

- Read more

- Write more

- Practice my Mandarin

- Produce 1 song/week (https://weeklybeats.com/)

- Continue to make one thing every day

You know what, screw it, I'm joining weekly beats. Thanks for this. I always wanted to learn to produce music, let's try it.

Gotta make 5 beats a day for 3 summers :)

F#

Goodbye JavaScript: Introducing our CSS API Client (https://blog.algolia.com/js-is-dead-all-hail-css/)