Location: Amsterdam, The Netherlands
Remote: Yes, but prefer onsite
Willing to relocate: No
Technologies: DevOps, Software Architecture, Openstack, HashiCorp stack, Salt, Ansible, Java, Go, Spring, Cassandra, Kafka, Docker (Certified Trainer)
Résumé/CV: cv.remmelt.com
Email: remmelt@hipcode.io
Languages: Dutch, English
Senior software engineer, strong DevOps and programmable infrastructure experience. Built and architected large scale web applications, online auction, messaging platform. I love building software, but I love even more to build bridges between people, and teams.
Great history about food, how cooking made us "human," links to religion, feminism, consumerism, and much more. Very insightful and at times heart felt. Not recommended if you don't eat food.
This stops short at all the really interesting stuff of microservices. Where's the service discovery? Failover? Secret storage? Communication?
Besides that, I don't agree with putting dependency injection in a microservice. Why bother? In a sense, microservices are a breath of fresh air, because they're supposed to "fit in one developer's head." If you're already adding layers of indirection, you're making the code harder to reason about for no good reason.
Yep - yet another half-baked project that someone is using for internet points. I'm really getting sick of people re-inventing the wheel poorly.
The number of available tools is really getting out of hand and I wish projects like this wouldn't suck away resources from established, functional projects.
I would even expect some out of the box management APIs to help upgrade the microservice with low to zero downtime, feature toggles, etc... A lot of these get built into each app typically but when you're creating many different microservices, the overhead of creating a service needs to be as close to zero as possible.
Technically, one way of solving this is to make sure that the acceptance criteria for any single micro service are clear. For example, you have to expose these REST endpoints; given data set A, respond in this way to these requests, etc.
To me, a micro services architecture implies that the development team is responsible for the entire life span of the service, from conception to replacement. This includes maintenance. Insert the devops buzz here as well.
When the given solution can no longer be maintained because of failing knowledge (or even interest?) by other devs, it should be replaced. This should be no harder than refactoring a large method, except on the scale of an entire service.
Non-technical benefits include expanded responsibility and shiny architecture can possibly attract better developers/engineers. I know this has worked for us.
I think it would be reasonable to somewhat limit the available choices, especially at the start of a project.
I'm very interested in the Arduino based pre amp. Do you have a page with your design that I can study? I was thinking about maybe integrating a Lightspeed Attenuator.
Most of all, I'd like the pre amp to automatically turn on the power amp (currently a Gainclone) when a signal starts coming in from the connected Airport Express.
Here's another arduino-based pre-amp. This one includes relay-based stepped attenuators and input selectors. The pcbs are all available as well as the schematics in case you just want to use it as a base for your own project.
