Could someone care to elaborate what are the main differences between Consul and Istio?
What would be the primary reasons to choose one service mesh over the other?
Well, I don't know how mature the service mesh aspects of Consul will be now, but the rest of it is a very mature product that provides a distributed K/V store like etcd and also provides service discovery via either REST or DNS.
Consul is not a service mesh. At its core it's a distributed key-value store which is commonly used for service discovery, configuration management and healthchecks.
As someone who has spent some time inside the Windows 10 environment working on UWP applications, I always thought that Xamarin would someday be my goto whenever I have the opportunity to dive into Mobile development.
I am comfortable with C# and I have always felt happy writing in XAML.
But looking into Flutter, I think it's undeniable how smart this project truly was. Even if it isn't backed by a popular programming language, since Dart obviously does not fall on that category.
Let’s see if it’s smart 10 years from now. Cross platform toolkits that draw their own widgets tend to have a hard time keeping up longer term and Google isn’t really known for the constance regarding project management.
If they “only” pull another AngularJS -> Angular transition. and it’s already a bad thing. If they abandon it, ouch!
C# & XAML UWP layer with Xamarin for mobile. The company behind it has been using for a few years to produce apps and recently open sourced it. I'm intrigued and weighing it against Flutter for my next bit of mobile experimentations.
Its definitely an important quality to be able to sweet talk and create pleasant relationships with the other colleagues.
But for myself it becomes really hard to do so with people, with whom my relationship might have downgraded, which in a working environment can have a serious impact in your progression, your evaluations and how much respect other people actually give you.
On the tech side, I have also felt that most people don't want to talk about anything related to tech, or when they do it's rather vague and blank, without properly backing up there convictions.
It would be nice to be able to share experiences with other employees regarding their favorite programming languages, opinions on the new X/Y/Z language, what could be done to improve our project, and so on. But most conversations don't evolve to any of that, it's mostly making fun of each other (on a nice way), flirt, sports and gibberish.
I am currently trying to gain knowledge after work on different topics such as: Docker, Kubernetes, services exposed by Cloud Providers (Azure on my case) and how to manage/deploy them, but I don't think anyone from my team would ever be interested in talking about it, which simply makes me feel like I am on a place where I don't belong.
This post resonates deeply with me, explaining exactly how my experience at some points as been working with people.
I am still in the early stages of my professional career, so I am nowhere near a stage where I think I am even close to know pretty much anything to the standards that I have mentally set for my self.
But I have found the share amount of employees, which just bloat confidence in anything they say, even if it is the wrongest thing in the entire Universe.
Always prefer to lower the bar around the quality of code, translating into more problems with future requirements, readability and so on. The reason? Self-preference to bad habits, but also the "no time" excuse, which in some cases might be the appropriate choice, but in others simply translates onto an obvious lack of ambition, but also a mind-blowing lack of respect for the programming art.
And I say this knowing that I am nowhere near the level which I want to be and very far away to actually produce code that I can consider to have met the standards of anyone with level of expertise in the same subject.
You are so lucky! You have a huge chance to note the experiences of the author, and _change course_ now before you end up unemployable years down the road! (like the author, who is going to be one of those aging coders who can't seem to get a job)
The author clearly seems to know computers, but in general from reading his post, he is a bad engineer. He collaborates poorly, he offers solutions without context, and does dangerous things without even realizing it. (eg: the use of BATCH without consideration for the negatives of such)
One thing to realize is you are holding an absolutist view of programming as an immutable art form. Programming computers is an engineering discipline. It exists to serve an external purpose - help people, make money, solve problems in the real world. Like every engineering discipline, it involves a trade off. Marking off your coworkers as "obvious lack of ambition" and "lack of respect" in their efforts based on your own judgement of their coding skill is intensely disrespectful. That's the kind of attitude that is inherently pre-judgemental and is what can get you fired, not hired or just edged out.
Having worked with truly intelligent individuals, one thing I have noticed is their endless humility and lack of ego. They are kind, think well of others and endlessly question their own intelligence. The author falls short on every metric.
Something to try to wrap my head around later!