The relationship between a software system and the people who build and operate it does not get discussed enough in this industry. This read won't give you answers to the many questions we have yet to answer or discuss, but it presents the topic well enough that I hope it gets some of y'all to think a little more about it.
I'd go so far as to say that configuration details for specific runtime environments should never be the concern of the application/service/program itself. It's almost always a smell to me when I see "dev" "prod" "stage" "local" in code unless it's an abstraction over the configuration for some sort of logical runtime profile.
While this might be decent advice around the internal details of a Django application's settings, what's missing is a mention of who this approach is designed for. It appears geared for developers who work on the project because the internal details (module names like settings.local, settings.production) leak to the command line interface. This might be fine in some cases, but this advice is not universal. All apps have a configuration API and you might consider how that looks depending on who/what is running the application, even if it's people who work on the code.
I applied and had one brief interview with someone over video. Maybe it's just me, but I think it's reasonable to expect a follow up, possibly with some feedback, after an interview. But that didn't happen. Not the end of the world for me, but a detail I think that should matter to a company that touts a strong community horn.
Unrelated? I' beg to differ. More to the point, all systems have an access control model. It could be explicit or implicit depending on how the system is built. Regardless, it defines the barriers and boundaries between everything in the system.
The comment suggests that just by separating things in the popular sense of microservices results in a barrier to enforce separation of concerns. That's how I read it, at least, and I find that to be is misleading.
This is the crux I see around popular discourse of microservices. It's often presented without a broader context.
Stop off! Drop a bunch "microservices" into the same network without any access control and you don't have a physical barrier at all! In fact, it becomes even harder to have a clue as to what's interfacing with what unless you can observe your inter process traffic.
I've been using this website for years. It's been so long now that I can't even remember when Grant Skinner, the former Flash/ActionScript guru, released it. Nice to see it shared here.
ZeroTier tech is so promising, but it appears Adam is trying to do too much at once. For example, I never received the ZeroTier Edge box, or a refund, from the IndieGoGo campaign. It's frustrating, but I hope the ZeroTier succeeds in the long run.
Sounds like the words of someone who didn't grow up in a city, currently/recently lives/lived in one they dislike, and hasn't found happiness somewhere else.
Paired with an OpenResty reverse proxy I was able to set up a reasonably secure cluster back when X-Pack was prohibitively expensive and the AWS offering wasn't under their BAA.
Highly recommend visiting the Gropius House. It's a wonderful example of what modern residential architecture could, maybe should, be. What I appreciate most about it is the obvious restraint applied to the design and focus on functionality without sacrificing a unique aesthetic. It will certainly influence any structure I may be involved with building for my family.
The water can stay in the tubes for up to two weeks. She tried the Medela and the Phillips and while they were decent, ultimately felt the Naya was better for comfort.
Well that's a bit of a gross generalization, wouldn't you say?
Try to imagine for a moment that you might be over looking a very important feature of any breast pump: comfort. This is the main reason my wife chose this pump. It's the only pump on the market that doesn't use air. Air imposes a much different discomfort relative to the Naya, according to my wife. She's very pleased with the product. The price? Sure, expensive. We're lucky to be able to afford it. The app? Don't care about it. Consider us your exception.
The idea that Flask is only good for small apps is naive. Plenty of folks have built large, successful, production level Flask apps. All Flask does is act as the glue between Werkzeug and Jinja2 and give you some nice patterns like the app and request contexts. If you're a decent Python developer you're going to end up writing something very similar if you just start with Werkzeug.