Strong agree. We were using Fargate nodes in our us-east-1 EKS cluster and not all of our nodes dropped, but every coredns pod did. When they came back up their age was hours older than expected, so maybe a problem between Fargate and the scheduler rendered them “up” but unable to be reached?
Either way, was surprising to us that already provisioned compute was impacted.
I'm a software engineer specializing in building stable, scalable consumer-facing websites and refactoring large codebases. Looking for consulting or contract work, working solo or with a team. Some previous projects:
- Built a comprehensive CI ecosystem for a 30+ app polygot environment using Jenkins, Docker and Github. Reduced test suite run time in their monolith from 25 minutes to 10.
- Refactored the real time auction draft system for a fantasy sports company to increase stability and support four times as many users without additional hardware.
Indeed - I've hiked almost 3k miles carrying an umbrella. Worn rain gear is a compromise between breathability and waterproofness - even if you keep the rain out, you'll sweat and it's trapped inside. Umbrellas keep rain off you, are very breathable, and double as sun protection when it's really hot. Only downside is when it's windy and rainy, so it's nice to have a poncho too.
I'm a software engineer specializing in designing and building stable, scalable consumer-facing websites and refactoring large codebases. Currently, I'm helping clients with dev ops problems like setting up web apps to scale for 10x more traffic, profiling/optimizing slow code paths, and building analytics pipelines with AWS.
Before that, I was a principal engineer at Vox Media, and worked on some notable projects:
I'm a software engineer specializing in designing and building stable, scalable consumer-facing websites and refactoring large codebases. Currently, I'm helping clients with dev ops problems like setting up web apps to scale for 10x more traffic, or building analytics pipelines with AWS.
I'm a software engineer specializing in designing and building stable, scalable consumer-facing websites and refactoring large codebases. Currently, I'm helping clients with dev ops problems like setting up web apps to scale for 10x more traffic, or building analytics pipelines with AWS.
Before that, I was a principal engineer at Vox Media, and worked on some notable projects:
We used to have this problem, but I think Slack added a feature to fix this. Our general room is now locked so that people can't post into it, but everyone is still a member.
I notice that you use www.theverge.com in a number of the screenshots for Javelin. The writers at The Verge, the developers that build the site, the designers that make it beautiful - are all paid through ad revenue. Please consider at least adding the ability to whitelist sites if you are going to bundle ad block.
*Full disclosure - I am a developer at Vox Media, the publisher of The Verge.
More often than not, the slowness end users experience is problems in the front end - not the database. Think uncompressed assets, cache misses, or unused javascript and stylesheets. It's very likely most pages in your application are (or should) be served entirely from cache, so end users will benefit much more from front end optimizations.
Seconding this. I've been doing something similar using OpenResty[0] and Redis. Handles millions of page views a day on a pretty low end server without breaking a sweat. Documentation on OpenResty is kinda tricky to wade through, but man is it lightweight and fast.
Welp, I had no idea about the int64 business. Probing on this, but it does seem like it changes things quiet a bit.
UPDATE: After updating go from 1.0.2 to 1.1, this matches my results - it now takes about 2 minutes, 47 seconds to run through the input (and Code Jam confirms the output is correct). This seems like a significant detail to me, so I'll update the post.
Hey everyone, thanks for all the input on this. As I mentioned in the post, programming competitions aren't my forte, and I have a lot to learn in that arena. All the feedback on how this should have been done more efficiently is great.
In the future, I obviously need to work on coming up with better algorithms for solving these kinds of problems, but I'll probably continue to try and use Go because it's nice to have that fallback to sheer speed when my algorithm isn't great.