511–520 of 782 posts
Earlier quoted context omitted.
No, not unless you’re somehow able to make the team, the CTO and Tim feel good at the same time. If you figure that part out let me know.
But if Tim's work is so bad that you can prove it..... How can a boss dodge the proof? I guess Tim should be fired second, the boss should go first...
This is a business decision, reality has no influence here.
That's why they invented the term "Business reality".
Earlier quoted context omitted.
I think what was missed, in the article, is that the fundamental problem was centered around a shared architecture of destinations and shared code. You cannot possibly have every destination be a separate repo and then have the development lifecycle of your shared code be so active that it ultimately puts at risk the architecture of your entire organization. What makes shared code so perfect is having stability such…
> ... the fundamental problem was centered around a shared architecture of destinations and shared code. From an architectural perspective, there is absolutely no difference between a micro service and a library. The only real difference is in the dispatch mechanism. The problems around configuration management are the same problems we've had as programmers for decades. It's just that the people who are keen on micro…
I always tell people if you can't write and maintain a library then don't do microservices.
Earlier quoted context omitted.
No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.
We have these things. A better architect implies that one is trained in analyzing and producing these architectures using the science she/he was trained with: https://www.sei.cmu.edu/education-outreach/credentials/crede... The certificate means nothing, the training and instruction is priceless. Add to that things like TOGAF and a deep understanding of the current state of existing architectures and you'll understand…
Earlier quoted context omitted.
No we need science and theory to definitively define necessary architectures that are appropriate to certain use cases. An architect is just a another man with an opinion.
It's a bit like asking to replace medical doctors with science and theory. We need science and theory, and skilled architects who can apply it to the problem at hand.
Earlier quoted context omitted.
I’d still pick PHP between the two for usual web apps. There is beauty in the statelessness of PHP and also leverage on Nginx (+ Lua) for more critical and high-speed work. The issue I have with Node JS is that the entire ecosystem moves way too fast. However, when I need realtime interaction via WebSockets fe. it really feels like a good choice.
The notion that the node.js ecosystem moves way too fast is a time-traveling statement from, like, 2012. When it really was, in a lot of ways, true. But today it really has congregated on a relatively small set of best practices and the tools you see today are mostly the tools you would have seen two years ago. They're also mostly the same tools you would have seen five years ago, and plenty of people use "old" tools…
This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…
This is a classic case of not understanding micro services and trying to fit a problem around a tool. This sentence needs to be repeated for everything on the 'wrong end' of the hype curve. This is a classic case of not understanding NoSQL and trying to fit a problem around a tool. This is a classic case of not understanding OOP and trying to fit a problem around a tool. This is a classic case of not understanding dy…
This is a classic case of generally understanding
Turing completeness and eventually, inadvertently
implementing a half of Common Lisp in C anyway.
Earlier quoted context omitted.
This is a classic case of not understanding micro services and trying to fit a problem around a tool. This sentence needs to be repeated for everything on the 'wrong end' of the hype curve. This is a classic case of not understanding NoSQL and trying to fit a problem around a tool. This is a classic case of not understanding OOP and trying to fit a problem around a tool. This is a classic case of not understanding dy…
So what's the 'respectable end' of the veneration curve? Does it have an inverse sentence? This is a classic case of generally understanding Turing completeness and eventually, inadvertently implementing a half of Common Lisp in C anyway. Something like that?
Let me write a meta technology hype roadmap, so we can place these sorts of articles: * Old technology is deemed by people too troublesome or restrictive. * They come up with a new technology that has great long-term disadvantages, but is either easy to get started with short-term, or plays to people's ego about long-term prospects. * Everyone adopts this new technology and raves about how great it is now that they h…
I have been doing some tech advice jobs on the side to see what's going on in the world and it's really scary what I found. Only yesterday I was talking with the cto of a niche social networking company that has a handful of users and probably won't get much more who was telling me the tech they use; Node, Go, Rust, Mongo, Kafka, some graph db I forgot, Redis, Python, React, Graphql, Cassandra, Blockchain (for their…
No one above my pay grade seems to see a problem with this. But hey! REST! JSON! HTTPS! Pass the Kool-Aid!
[1] NAPTR records---given a phone number, return name information; RFC-3401 to RFC-3404
This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…
arguably they aren't close to each other in tiers of the stack, and don't really overlap. The sorts of libraries you might choose to use to do something could differ, (e.g. json processing - in the front end, you'd pick usability and security over a lower level more optimized transcoder for the api).
That said, I agree with your core premise- not understanding, and chasing a nail with a hammer, but geekily named repos per language just sounds like someone who doesn't understand how something git works...
This is a classic case of not understanding micro services and trying to fit a problem around a tool. At work, we have close to ~50 services(no one calls them microservices), but they do not suffer from this brittleness. We segregate our services based on languages. So, all C services go under coco/ , all Java services go under jumanji/ , all go services go under goat/ , all JS services go under js/. This means, ever…
Sharing schemas and contracts in a distributed architecture is a hard problem. The interesting thing is these are central to communication, so we should definitely talk as a team about them - if anything, that's probably the one thing if you had to choose what to talk about. Then the INTPs can scurry back to their holes and continue creating stuff while the ENFPs form a committee for the next pub walk. Full disclosur…
It just seems like it just creates an us vs. them ideology.