There are several cheap MDM solutions for Apple devices that I would rather pay for than be dependent on this. (We've used SimpleMDM and love them.)

We had some AWS experience from running our backing services (RDS, Elasticsearch, Memcached, Redis) on AWS despite doing compute on Heroku for a long time, but we'd never done EC2 or EKS for deployments on AWS. Despite having been on Porter now for months, I'd say we still don't know or really need to know a ton about k8s, but we are familiar with some basics around pod sizing, healthchecks, deployments, etc.

I think Porter does a lot to put themselves out as as destination for people leaving Heroku. I'm not sure if this would have been more work to do something like Render, but I was very pleased with the timeframe, hours spent, and the ease of cutting over.

We have a monolith that handles ~50k/min traffic at peak use as well as a couple very tiny services that do some accessory stuff. All the apps are Rails apps.

One of the reasons that we chose Porter over other options is that we really liked their setup for Preview Environments, which are an important part of our workflow here. The experience of running preview apps on Porter is notably better than on Heroku, where we started to see a lot of unreliable behavior on app launch that resulted in the app being unusable and the only fix was to close and open a new PR .

On the whole this was a really positive experience for us. We're seeing better performance, we're paying less (in Porter + AWS compute combined) than we did for Heroku Enterprise, and our ability to deploy mid-day when we're under load is better than it was before. I've spent most of my 12 years or so of Rails development working on Heroku (and we had been on Heroku for almost six years), so we had some fear around moving to unfamiliar tooling, but this has been a big win for us.

Senior Full-Stack Engineer (Rails, Typescript)

CommonLit is a 501(c)3 non-profit whose mission is to improve the educational and economic outcomes of students through better literacy and critical thinking skills. Our non-profit's application supports millions of students in the United States and around the world with a rigorous, high-interest literacy curriculum in English & Spanish.

Our small (nine-member) engineering team works in a collaborative, high-trust environment where we ship high-quality software to power CommonLit's curriculum and to assist teachers in assessing their students growth. As a Senior Engineer you'll lead significant technical projects, contribute your own code, review teammates' work, and advance CommonLit's mission. You'll act as a force-multiplier for your teammates' work in addition to your own high-leverage contributions.

Our team is a group of life-long learners. We value sharing new ideas, lifting each other up, and building performant, reliable software that teachers can rely on in the high-stress classroom environment.

Responsibilities:

As a Senior Software Engineer your work will include: * Writing high-quality Ruby and Typescript code and tests for our Rails monolith * Reviewing your teammates' work in our code review workflow * Researching technical ideas for upcoming projects * Mentoring and helping level-up less experienced engineers * Deploying and operating our application

Qualifications: * 5-8+ years of web development experience with some of that time spent on a Rails production application * Experience working with a modern JavaScript framework (React, Vue, etc.) * Ability to work comfortably in SQL (we use PostgreSQL & Redshift) * Experience dealing with performance and scaling issues * You have a commitment to improving equity of opportunity for students of color

Location: Remote-US or Washington, DC

Pay: $150k-$210k

Apply at: https://www.commonlit.org/en/careers/senior-full-stack-softw...

- Package releases don't get PRs in their first 24 hours unless they are for security issues, so you don't get noise if there's a yank or a quick patch for a bug in the latest release

- You can set development (or production!) packages to only update once a week

- Packages that are known to have a very frequent release cadence (AWS SDK subcomponents, looking at you)_get pushed to a much slower PR pace so that you only update them 2x/month, etc.

- This might be fixed now, but it had much nicer auto-merge behavior for releases that passed CI.

- With Yarn, it can run `yarn-deduplicate` after updates to trim down shared dependency bloat.

FWIW we still use Dependabot for security patches only because they seem to get picked up a few hours earlier. We also have much tighter lock rules on some JS packages which seem to make breaking changes on patch/minor releases.

Our bundle got noticeably smaller, but we chalked that up to esbuild not polyfilling for as early a target as we had been with babel-loader.

I do think profit sharing would be a good lever for a bootstrapped company that is already profitable and wants to give key employees skin in the game.

Comments URL: https://news.ycombinator.com/item?id=20615039

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=12131081

Points: 5

# Comments: 0