I did not. If I had known what would happen when we tried this we would have skipped the process entirely. Our staff (roughly 125) was so confused and it wasted a lot of time communicating about it, then trying to roll it back, etc.
The domain lock process was an absolute fiasco at our company. I think this could work if you did this at the time your company launched, but the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place.
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've been very happy with Northflank's blend of ease-of-use with configurability when you want it. (We're running BYOC AWS.) Running several workloads and it's the best preview-environment-per-PR setup I've encountered across PaaS options.
The scoreboard running all the way around the circumference of the cup was awesome. My dad worked in RI for a few years as a kid and we went to a bunch of games at McCoy. I didn't realize until I was older how many long-time big leaguers appeared in that game!
This is really a huge bummer. It was a fantastic service and made it easy to run a "two-person approval" system on all kinds of access and infra changes without building something blocking or bureaucratic.
We moved off of Heroku in late-May/early-June of this year. It took a few weeks of half-time work for one person to make everything happen. We were already using Docker in CI, so we didn't need to spend much time making our app work in Docker for production. We paid the $500 for Porter's "white glove" migration service because we figured it would be useful to be able to get quick feedback about choices and changes.
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.
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
I've been using Depfu for a while and I think it handles some of the biggest pain points with Dependency spam.
- 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.
`git push heroku main` doesn't work if your repository is large enough (not sure if this is raw file sizes or the Git data size). Some of our apps can't be redeployed using this method, we have to use the build workaround which has its own set of issues.
This doesn't work if your Git repo is above a certain size. Some of our apps (fortunately not production) haven't been able to deploy since the incident.
We switched two weeks ago and the drop was a bit more than half the total time we had with Webpack in development and a bit bigger drop in production builds.
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.
Pre-IPO the venture is likely not profitable, so you'd be getting a share of zero. Companies that are VC-backed are going to be held to an expectation of a big payoff, and will be in general discouraged from offering incentives that uncouple employee incentives from an exit. If I understand this right, it's part of why founders have started to be allowed to sell some of their vested shares at funding events, it gives them some more financial runway as the company's timeline stretches out (you don't want the optics of the CEO of your $50m series C to be eating peanut butter and ramen, etc.)
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.
They moved a bunch of it to Github out of PullReminders yesterday. I would go to your personal settings in GH and look at "Scheduled Reminders", which is where the old PullReminders functionality got moved. It's possible it's only there for pre-acquisition users, but that's where it should end up if it's generally available now.