731–740 of 782 posts
Earlier quoted context omitted.
Nah... This one was clearly paralized while pressing a key. His browser must auto-post HN comments after a short while.
With the last sentence, we now award the best hypothesis to dictation. https://www.youtube.com/watch?v=LJfowXTXOfU
It's amazing how many stupid to the point of crazyness situations seem perfectly natural nowadays. Thank computers!
Earlier quoted context omitted.
What do you mean by model checking? Usually anything with the keyword "Design" like design patterns for microservices have no science or mathematics to back it up.
You may be technically correct, but I'd argue it's generally more useful what we do have: practical experience. When one says "we need better architects", to me that implies that our current architects are creating design patterns and reference implementations that are both 1) not practical, and 2) don't adhere to known-good best practices. Systems design in real life is an "artistic science": there are always known…
Nobody argues about which algorithm is better for sorted data sets: linear search or binary search. Theory already establishes one is faster than the other, but no theory establishes which architecture is better than the other.
Earlier quoted context omitted.
If deciding join order and what indexes to use sounds like your idea of a good time. It certainly isn't mine.
parameters could have default values or default heuristically chosen values if a default value isn't specified explicitly. Joins can be done imperatively as well. This leads to a language that is more clear and optimize-able by hand. x = binary_search(column_name=id, value=56, show_all_columns=True) y = dictionary_search(column_name=id, value=56, show_all_columns=True) z = join(x, y, joinFunc=func(a,b)(a==b)) The exa…
However, I think specifying the algorithms in the queries is really not a good idea. Your performance characteristics can change over time (or you might now know them at all yet when you start the project). With your solution, if you, e.g. realize later that it makes sense to add a new index, you'd have to rewrite every single query to use that index. With SQL, you simply add the index and are done.
Oh man, this is just the tip of the iceberg with Microservices. There is nothing Micro about them, they are so difficult to deal with that it becomes impossible to actually iterate or build user value and introduces loads of difficult to debug problems. We have architects here that dictate the design of the system but IMO they have not done the simplest implementation of anything. We have Kafka to provide ways of mak…
Ugh. Sounds like a severe case of resume-driven architecture. In my experience, you won't know whether you need microservices until you're on at least v2.0 of your application. By then, you have a better understanding of what your real problems are.
Am I understanding correctly that they had 3 engineers and >140 microservices? Microservices definitely have their own costs and tradeoffs, but 140 services and 3 engineers sounds like just a terrible engineering choice.
At the time we did the split, we had 140 destinations with ~8 engineers, of which roughly 3 full-time engineers spending most of their time just keeping the system alive.
Earlier quoted context omitted.
"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." Has it? I'm pretty sure if I were to ask what those best practices and tools are, I'd get a number of different answers.
React is more than five years old. webpack is six years old. npm is eight years old. nodejs is nine years old. Anecdotal, but I personally feel like things have stabilized a great deal.
It seems like splitting into separate repos was a rash response to low-value automated tests. If tests don't actually increase confidence in the correctness of the code they're negative value. Maybe they should have deleted or rewritten a bunch of tests instead. Which is what they did in the end anyway. >> A huge point of frustration was that a single broken test caused tests to fail across all destinations. When we…
We went through this painful period. Kept at it devoting a rotating pair to proactively address issues. Eventually it stabilized, but the real solution was to better decouple services and have them perform with more 9s of reliable latency. Microservices are hard when done improperly and there doesn't seem to be a short path to learning how to make them with good boundaries and low coupling.
Earlier quoted context omitted.
> It's hard to do right. This is correct; I'd argue doing microservices right is even harder than doing a monolith right (like, keeping the code base clean).
It is weird that they took on some problems so easy. Shared libraries is one point. To get them right for hundreds slightly different services is something I don't even want to think about. The only strategy I can come up with is to maintain them as if they're a 3rd party lib and cannot contain business logic. So you're forced to build solutions around them and not with them. Then there have been quite a few warnings…
Even so, imagine the chaos if frequently engineers/devs need to add code to one lib(the shared one), wait for PR approval, then use that new version in a different lib to implement the actual change that was needed? Thats seems to be introducing a direct delay into getting anything productively done...
Earlier quoted context omitted.
"SQL database usage is still an ongoing bummer, though." ... have you looked at Typeorm ( http://typeorm.io/ )?
I have, actually. This week has made me decide to move away from it. I have been using it, and filed an issue[0] asking them to document the schemas emitted by their entity-tree code; I was then told that I was doing it wrong and that I should use their code-first/synchronization feature and trust in their magic rather than writing my own explicit migrations which are informed by my (tbh, pretty extensive) understand…
Earlier quoted context omitted.
FTP workflows are so extremely widely used in today's world that it's inconceivable you think it's behind us.
Maybe in frontenddev/small companies/small largely static websites FTP pervades, but I'd argue that most developers that deal with any real complexity probably use some kind of source control system to 'share' files rather than some kind of FTP program. And I'd be very surprised if relative FTP usage hadn't decreased significantly over the last 3-4 years (But this is all quite anecdotal, and I could be wrong). Someth…