Babylist - Oakland, CA | Full Time | ONSITE

At Babylist, we make having your first baby less overwhelming, more creative, sustainable, and most importantly more delightful. We have a large and rapidly growing user base of passionate parents-to-be who are making important purchasing decisions for one of the biggest events in their lives. We help parents-to-be in a time that's both exciting and stressful.

Our core product is our universal baby registry. Currently 20% of first-time expecting families in the United States actually create a baby registry at Babylist.com. We are expanding our reach through fantastic content and our own e-commerce.

Senior Software Engineer: Our backend/API are powered by Ruby on Rails, and front-end is driven by React/Redux. You would join an excellent product team of 4 software engineers, 1 designer, and 1 product manager.

Requirements:

- 5+ years of engineering experience with a proven track record of building consumer web applications or services.

- Expert-level fluency in at least one of Ruby, Javascript, Python, or another modern programming language.

- Bachelor’s Degree in Engineering, Computer Science or a related field preferred. You should be able to demonstrate superior understanding of CS fundamentals

- Experience designing and implementing scalable web services

- Experience with React/Redux a plus

I'd love to tell you more over the phone or in person. Contact me at august[at]babylist.com or see our jobs page for other open positions - https://babylist.com/jobs

https://cronitor.io started as a weekend project. I had an acute need for the product which enforced getting a working version quickly. After using the result of that first weekend hackathon in production for a couple of weeks my co-founder and I decided to put in another couple weekend afternoons and evenings to make it a saas product. We've been working on it part-time ever since.

I wrote more about it in an Indie Hackers interview a few months ago - https://www.indiehackers.com/businesses/cronitor

I really think you should write something about the purpose of the project & the stack used

This is cool! Please talk about the stack!

Mostly Python. Django for web app and rest API. The Falcon micro-framework for telemetry collection API.

The dashboard is a React SPA (since 2014!) that is powered entirely by our REST API so new features are always API-enabled.

Alerting rules are handled by a Python daemon that processes the event stream.

Healthchecks are dispatched by coordinators to Lambda workers in a half dozen regions around the world. We started using Lambda before the launch of great frameworks like Serverless so we had to roll our own lambda deployment tooling with Fabric and Boto.

We use several AWS services including Route53 for global latency-based routing, SQS and SNS, etc. You can check out our May AWS bill if you're interested in learning more: https://blog.cronitor.io/the-aws-spend-of-a-saas-side-busine...

Cronitor co-founder here. This is a great question! I would love to see others post some numbers here.

As Shane mentioned in the post 12.5% has been a consistent number for us as we have scaled up over the past couple years. That said, at this point I suspect we will see this percentage decrease a bit going forward. I'm basing this on intuiting that we're a bit over provisioned at the moment and won't have to scale our infrastructure linearly with user growth over the next year or two. Of course, that remains to be seen...

To add some more numbers to the conversation my full time job is CTO at a consumer facing tech company (Babylist.com) I just looked at our spending on IT/infrastructure for the last couple of months and it's around 1.5-2% of revenue.

Thanks. I guess there are economies of scale / barrier of entry costs involved that should reduce this ratio over time.

On a side note. When people talk about x-figures revenue, are they typically talking about x-figures monthly or yearly?

Thanks so much y'all! Sincerely appreciate the encouragement, and if there's ever anything we can do to help out/give back to such a wonderful community please don't hesitate to get in touch with us.

Thanks Jake! We'll definitely write some posts in the coming months about our architecture. We never intended to be running a high-availability service, and we have learned a lot of lessons along the way.

Thanks for the kind words! That just made my day!

I completely agree with this. My co-founder had a post[0] on HN yesterday in which he mentioned that our MVP made him cringe.

What he didn't mention is that that cringeworthy MVP was public for almost two months before we started showing it to people. It was out there with broken features, placeholder text, etc.

That made shippin easy. It was done on day 1 and then we were very motivated to make it actually do something useful since it was already public.

[0] https://news.ycombinator.com/item?id=13347307

I have this exact same problem. It's been something that has bothered me for over a decade. I'm really excited to see if these work for me!

I built https://cronitor.io after having an important cron job fail silently for several days. When I mentioned this problem to a friend his first response was "we just had a major issue with cron failing silently at my work too".

We decided to hack on it together, and we've since grown Cronitor from a tool built for our own needs into a small business with a couple hundred paying customers.

As someone about to write a cron job, what ways do you see Cron fail?

My assumption is that cron is robust and reliable, it's the job script itself that may fail silently and need monitoring, yes?

Yeah, I'd say your assumption is correct. However, other common ways that I've seen cron "fail" is for the cron entry to being installed in the wrong user's crontab, the permissions on a script changing such that it can't be executed, temporarily disabling or removing a cron job and forgetting to re-enable it, etc.

My favorite is forgetting a newline at the end of the crontab. I always put a warning at the bottom of my crontabs.

# Always end with a newline!

The most common failure I've seen is when people forget to use full paths in cron.

bash instead of /bin/bash (or similar)

There's other weirdness in cron-land too. Cron will completely ignore files containing "." .

The cron process can be killed by the oom_killer, resulting in missed crons. This may be aggrevated If the cron service is never respawned later.

I found where I used to work that cron jobs usually failed because they weren't adequately tested, so I tried using MAILTO but it didn't do what I wanted, so started putting something like (it's been a while):

45 5 * * * /bin/bash -eux -C /path/to/real/cmd >> /var/log/somefile 2&>1 | mail -S "/path/to/real/cmd... at 10.2.3.4 failed with details in /var/log/somefile" to-address < tail /var/log/somefile

...then test failures to make sure the email and everything worked as expected (like, mail might not be set up correctly on the box by default). And either overwrite /var/log/somefile with ">" instead of ">>" or use logrotate. Of course, the /path/to/real/cmd script, if a shell script, should have something like "set -eux" or at least "set -e" at the top (and be well tested), otherwise it won't always report failures and this has no chance of working.

I didn't (in mild use) see unreported failures after that, and it was really handy for problem diagnoses when something did go wrong thereafter.

But after any change I had to test carefully again every failure mode etc, because it seemed so easy to miss something that causes unexpected behavior. Maybe even had to wrap it in an "if" statement (single-line), "..else mail...".

It would be fun but time-consuming to automate those tests, maybe with shunit2 (or something named roughly like that), to rerun periodically and make sure ops didn't change the mail config to break this setup, or something.

I know that looks awful but I enjoyed it. It might just be easier to use your replacement. How did you advertise?

In case anyone ever reads that, too late for me to edit but: file 2&>1 | mail -S ...should be: file 2&>1 || mail -S ...or more likely the wrapped "if" mentioned.

also https://wdt.io/cron-monitoring.html , I think it's been awhile for awhile.