#xotech

XO Tech is proud to announce the NEW www.theknot.com! This is more than a redesign -- it’s a complete re-platform! Huge congrats to everyone at XO Group for this incredible effort. More to come about how we transformed not only our tech stacks but also our whole development process! Cheers all!

Meet Tian He

Introducing Tian He, our passionate, driven, and inspiring engineering lead. We sat down with Tian to find out what life at XO is like as for this incredibly busy team player.

XO: What exactly do you do here at XO?

TH: I'm the Engineering Lead for The Bump and The Nest. I’m responsible for making sure that the engineering team is continually delivering high quality products that are to spec and on time.

XO: What would you say your typical day is like?

TH: There isn't a typical day. Every day is really different because my priorities depend on the needs of my team.  We'll usually start with a 10-min standup in the morning where everyone talks about his/her progress. Then, it’s off to the races.  

I'll jump into a meeting with the product team to plan and strategize our product roadmap.  Then work with the Baby-Tech engineers to prioritize stories for our current sprint, help them remove any roadblocks stopping their progress, and occasionally brainstorm a work-around to a pesky engineering problem.  I might sit-in on some code reviews.  And at the organization level, I'll probably chat with our awesome recruiters Bec + Drew about what we can do to attract more engineering talent or meet with other engineering managers to talk about what actions we can take to improve our engineering process.  

The only thing that is constant is that I start the day with fruit + oatmeal at the XO Cafeteria.  

XO: What is the best part of your job?

TH: The best part of my job is definitely working with everyone at XO! We have such a friendly and supportive environment.  And everyone here is better than me at something and I get to learn from all of them.

XO: Where were you before XO?

TH: My previous experiences were pretty diverse. My first job coming out of college was in finance so I was in investment banking. I did that for two years. After that I did investing for one year in late stage startups. Then I started my own company Gojee in a technical and product role. I did that for three years before XO acquired us in March.

XO: Would you say your previous experience has helped you transition to XO Group?

TH: Definitely.  Each of those three experiences offered something different. I’ve found my experiences have built on top of each another. Working in investment banking gave me was this OCD level of attention to detail. One of the first things that I did when I joined The Bump was get everyone to focus on details. The first release of the Bump app after I joined didn’t involve increment features, it involved making small tweaks on alignment and font-size to make sure that when users opened our app, then know we spent time worrying about the smallest bit of details.

My second job was investing so that really taught me to think about every decision in terms of risk and reward. At the Bump, we’re easily working on 3-4 initiatives at a time and it’s important to prioritize. Sometimes the easy and quick things aren’t the things I should be doing. And sometimes, the urgent thing isn’t really that urgent at all.

My last experience before XO also taught me the most. It wasn’t until Gojee that I realized that some things don’t happen unless you make them happen through persistence and coordination. The biggest trick I learned is to ask the right questions and help people realize what needs to be done next.

XO: What was it like starting and transitioning from Gojee?

TH: Honestly, it has been pretty easy.  I’ve had to get used to having more resources and a nicer office. That’s kind of tongue-in-check. Having dedicated teams has allowed me to focus on the thing I love most, which is technology. At the same time, I do miss getting a chance to touch so many parts of the business all at once. I still get to in a lot of ways, just not as much as before.

The best part of the transition by far is that XO has an amazing culture. I did 5-6 internships and 3-4 full-time jobs out of college. XO is the top place in terms of culture.

XO: What do you look for in a prospective candidate?

TH: It depends on the role.  For junior positions I look for candidates with a lot of drive, a positive attitude, and general problem-solving skills. For more senior positions domain knowledge, good judgment, and the ability to work well with others becomes more and more important. Much of engineering requires team work and pragmatism so I think the best engineers have a good balance of internal drive, practical judgment, and collaboration/communication skills.

XO: What advice would you give someone who is interested in applying for a position at XO?

TH: Do it already!  XO's a great place to work. I’ve found a genuine, collaborative community and some of the nicest people to work with and learn from. I’ve also encountered some challenging engineering problems because we have to worry about scale and performance from day one so adhering to best practices is crucial. And what makes XO special to me is the culture. It makes me excited to come to work every day.

XO: How would you describe XO in one word?

Hi! In this,the first of a 2 series of posts, I would like to talk about the Amazon Simple Notification Service web service we use here at XO. What it is, how it works and how to configure it.

Amazon Simple Notification Service (SNS) provides a convenient means for distributing data between applications. SNS is organized in user created “Topics”. Applications that generate the data to be distributed are called “Publishers” and applications that will consume the data are called “Subscribers”. The later can be HTTP/s endpoints, email, SMS, Mobile Apps or Amazon Simple Queue Service (SQS).

Use case

As a use case, let’s say we have an application that manages user accounts. Now let’s suppose that we have other applications that need to be be “aware” of changes in user data. For example a newsletter mailing system, that would need to know when new users are created, their information updated or their accounts deleted. Or an analytics tool that creates reports on user statistics that manages it’s own database.

By using SNS, we can have these systems talk to each other in a loosely coupled fashion. The accounts managing application would be the publisher. Then the mailing and analytics systems would be subscribers to the SNS topic.

The publishing application can push user data changes to the topic in the form of messages by using one of the many SDK libraries (Ruby, .NET, Jscript, etc…) . The Subscribers can, for example,  wrap their API around http REST endpoints that will parse the incoming messages from the topic.

Creating an SNS Topic and Subscriptions

We can create SNS topics and subscriptions through the AWS console.

https://console.aws.amazon.com/console/home

This is our home screen to access all services in the AWS constellation. Let’s go ahead and click on “SNS Push Notification Service”

On the following screen, click on “Create New Topic”

We’ll call the topic “User_Data_Updates” . Click on “Create Topic”.

Take note of topic ARN:

arn:aws:sns:us-west-2:867544872691:User_Data_Updates

This key generated by AWS is the topic’s unique identifier, used by both publishers and subscribing applications.

Now, to add a subscription, click on “Create subscription”

SNS allows different types of subscriptions or “protocols”, such as http, https, sns, email or SQS queues. We will choose HTTP and enter the endpoint’s url. Finally, click on “subscribe”

The subscription will show up on the console with a status of “Pending confirmation”

Finalizing the subscription and message formats

In order for endpoints to begin receiving publisher messages, they need to “confirm” the Topic subscription to SNS.

Let’s talk a little about the message formats. SNS messages to subscribers come in 2 flavors:

-Subscription confirmation

-Notification

Subscription confirmations are sent only once, when an endpoint is subscribed to the topic. This is what the message looks like:

POST / HTTP/1.1 x-amz-sns-message-type: SubscriptionConfirmation x-amz-sns-message-id: 165545c9-2a5c-472c-8df2-7ff2be2b3b1b x-amz-sns-topic-arn: arn:aws:sns:us-east-1:123456789012:MyTopic x-amz-sns-subscription-arn: arn:aws:sns:us-east-1:123456789012:MyTopic:2bcfbf39-05c3-41de-beaa-fcfcc21c8f55 Content-Length: 1336 Content-Type: text/plain; charset=UTF-8 Host: example.com Connection: Keep-Alive User-Agent: Amazon Simple Notification Service Agent {  "Type" : “SubscriptionConfirmation”,  "MessageId" : “165545c9-2a5c-472c-8df2-7ff2be2b3b1b”,  "Token" : “2336412f37fb687f5d51e6e241d09c805a5a57b30d712f794cc5f6a988666d92768dd60a747ba6f3beb71854e285d6ad02428b09ceece29417f1f02d609c582afbacc99c583a916b9981dd2728f4ae6fdb82efd087cc3b7849e05798d2d2785c03b0879594eeac82c01f235d0e717736”,  "TopicArn" : “arn:aws:sns:us-east-1:123456789012:MyTopic”,  "Message" : “You have chosen to subscribe to the topic arn:aws:sns:us-east-1:123456789012:MyTopic.\nTo confirm the subscription, visit the SubscribeURL included in this message.”,  "SubscribeURL" : “https://sns.us-east-1.amazonaws.com/?Action=ConfirmSubscription&TopicArn=arn:aws:sns:us-east-1:123456789012:MyTopic&Token=2336412f37fb687f5d51e6e241d09c805a5a57b30d712f794cc5f6a988666d92768dd60a747ba6f3beb71854e285d6ad02428b09ceece29417f1f02d609c582afbacc99c583a916b9981dd2728f4ae6fdb82efd087cc3b7849e05798d2d2785c03b0879594eeac82c01f235d0e717736”,  "Timestamp" : “2012-04-26T20:45:04.751Z”,  "SignatureVersion" : “1”,  "Signature" : “EXAMPLEpH+DcEwjAPg8O9mY8dReBSwksfg2S7WKQcikcNKWLQjwu6A4VbeS0QHVCkhRS7fUQvi2egU3N858fiTDN6bkkOxYDVrY0Ad8L10Hs3zH81mtnPk5uvvolIC1CXGu43obcgFxeL3khZl8IKvO61GWB6jI9b5+gLPoBc1Q=”,  "SigningCertURL" : “https://sns.us-east-1.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem”  }

Notice the following 2 headers:

x-amz-sns-message-type: SubscriptionConfirmation

x-amz-sns-topic-arn: arn:aws:sns:us-east-1:123456789012:MyTopic

The first header tells our application that SNS is awaiting a subscription confirmation. The second header has the topic’s ARN.

To confirm the subscription, the endpoint needs to send an HTTP GET request to the “SubscribeUrl” included in the message’s request payload.

Therefore, our endpoint needs to identify both the topic arn (to make sure it is the right topic) and the subscriptionConfirmation message.

Once the GET request is issued, we can verify that the subscription is confirmed, by seeing on the console that the topic assigned a Subscription ID to the endpoint.

Once the endpoint is “subscribed”, messages will start being sent to it. This time, they will be of type “Notification” and this is what they will look like:

POST / HTTP/1.1 x-amz-sns-message-type: Notification x-amz-sns-message-id: da41e39f-ea4d-435a-b922-c6aae3915ebe x-amz-sns-topic-arn: arn:aws:sns:us-east-1:123456789012:MyTopic x-amz-sns-subscription-arn: arn:aws:sns:us-east-1:123456789012:MyTopic:2bcfbf39-05c3-41de-beaa-fcfcc21c8f55 Content-Length: 761 Content-Type: text/plain; charset=UTF-8 Host: ec2-50-17-44-49.compute-1.amazonaws.com Connection: Keep-Alive User-Agent: Amazon Simple Notification Service Agent {  "Type" : “Notification”,  "MessageId" : “da41e39f-ea4d-435a-b922-c6aae3915ebe”,  "TopicArn" : “arn:aws:sns:us-east-1:123456789012:MyTopic”,  "Subject" : “test”,  "Message" : “test message”,  "Timestamp" : “2012-04-25T21:49:25.719Z”,  "SignatureVersion" : “1”,  "Signature" : “EXAMPLElDMXvB8r9R83tGoNn0ecwd5UjllzsvSvbItzfaMpN2nk5HVSw7XnOn/49IkxDKz8YrlH2qJXj2iZB0Zo2O71c4qQk1fMUDi3LGpij7RCW7AW9vYYsSqIKRnFS94ilu7NFhUzLiieYr4BKHpdTmdD6c0esKEYBpabxDSc=”,  "SigningCertURL" : “https://sns.us-east-1.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem”,  "UnsubscribeURL" : “https://sns.us-east-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:us-east-1:123456789012:MyTopic:2bcfbf39-05c3-41de-beaa-fcfcc21c8f55” }

Notice that now the “message-type” header has a value of “Notification”.

The message’s actual data is now present on the “Message” key on the payload.

We can test the endpoints by manually publishing to the topic. On the console, click on the “Publish” button. Fill in the form, and click on “Publish Message”.

Then verify with whichever debugging / monitoring tool you are using, that the messages indeed are arriving.

With these simple steps, we can very quickly create distributed architectures that allow our systems to be loosely coupled. We can dynamically allocate resources to consume data in different ways, with ease, without the need to modify other participating systems.

On my next post I will get into the details of implementing http endpoints that subscribe to an SNS topic.

Thank you for reading and see you on my next post!

ABOUT THE AUTHOR

Alexander Copquin

It's Thirsty Thursday here at XO Group, and the XO Tech team is no stranger to mixing it up in the game room.  We often take breaks and blow off some steam with some heated and often epic ping pong and foosball matches.  The vintage arcade games are a new and welcomed treasure.

If that isn't enough, 4:30PM is our Thirsty Thursday happy hour, we have two pretty awesome beers on tap at the bar this month - Dogfish Pumpkin Ale and Harpoon Oktoberfest.