It was a fun run.
-
-
And with Mongo under the hood, I expect this is entirely possible.
Serious question: is Mongo that bad? I've got no experience with it, and we're moving towards using it in our workplace.
I've been assured that it is "blisteringly fast for non relational data, and much faster than SQL in non-relational scenarios".
Are you implying that my experience is not going to be all rainbows and unicorns?
-
-
-
Serious question: is Mongo that bad?
I cannot hear about MongoDB without immediately thinking 'It's webscale!'. But seriously, it's pretty much like anything else: it's good at what it's designed for, and not good as what it's not designed for.Personally, if I was implementing, say, a simple blog, then a document store like MongoDB would likely be something I'd want to use; designing a forum though, and I'd be looking at something relational.
-
he would have done better to show some civility himself
HAHAHAHAHAHahahaHAHAhahAHAHa...
Oh, you were serious...
I agree, but the only way that would happen is if Jeff wasn't involved (which you already stated), or if he took mind altering drugs. I don't think that guy is capable of being anything other than a pompous dick, never mind civil.
-
@RaceProUK said:
They'll return.
How about they don't.
I'm afraid I can't control who runs bots; that's something you'll have to take up with the owners of those particular bots.
-
I don't think that guy is capable of being anything other than a pompous dick
Oh, I think he might be able to reach the dizzying heights of being a raging fucknozzle, but that might be a false impression I've received.
-
The problem is by the time we were exposed to it, it was already impossible-to-deal-with spaghetti code, because they do ZERO design. ZERO.
Everything they implemented was on a whim, most of them new buggy open source libraries they pulled in to the already-buggy core code.
"Failing to listen to users" is part of the problem, yes, but that's just a small slice of the general incompetence. They failed as software developers.
-
a simple blog
You'd be surprised how much relational data is involved in blogging.
Comments belong to a post, posts belong to categories, tags cross category bounds but group posts, posts might be grouped by month or year...
-
That's assuming I have all those features; if I just want something to post articles with, then a document store could be better suited.
-
because they
do ZERO design. ZEROfollow an "agile" workflow
Filed under: That's what agile means right? No planning, no documentation, just get stuff done!
-
As we've stated on this forum a million times, there are extremely specific use-cases for which Mongo is amazeballs and for which before Mongo existed, nothing really handled those cases. They are extremely few and far-between. (That said, I think the consensus now is that Cassandra is better in those cases too.)
The problem is when you take data that is obviously transactional and obviously relational and try to cram it into Mongo, then you're in for a world of hurt. Mongo isn't designed for that, and it doesn't do it well.
Whether it makes sense for your company to move to Mongo, we can't say without knowing what the product is. But: almost certainly not.
(And Mongo might-- might-- be faster than MS SQL at plain CRUD operations, the only way it's faster at querying is if you buy literally 4 times the hardware MS SQL requires. Regardless of whether the scenarios are relational or not.)
-
@DoctorJones said:
rainbows
believe me, you don't want rainbows.
Why not? Afraid of leprechauns? Or maybe you got lost on the way to Asgard too many times...Or did you mean this kind of rainbow?
No need to be scared, Ben, after all, closets are for clothes
-
I'm just saying that
is 
-
-
Personally, if I was implementing, say, a simple blog, then a document store like MongoDB would likely be something I'd want to use;
Not if your blog has multiple authors, categories, more than one page type, comments, revision history, hit counters-- those are all meaningful relations.
Plus eventual consistency would be awful for a blog's comment system the instant you got a decent amount of traffic. Although I understand Mongo drivers can turn that off now.
-
@blakeyrat said:
In principle? No. In practice? Almost always.because they
do ZERO design. ZEROfollow an "agile" workflow
Filed under: That's what agile means right? No planning, no documentation, just get stuff done!
-
-
Except they haven't gotten anything significant done in like 9 months, so that's not working either.
-
I have no practical experience with it because my only non relational stuff has to be related to relational stuff, and that's what SQL LOBs are for.
But like any right thinking developer, I can identify relational datasets. Forums are relational datasets.
-
Well, the 'get stuff done' part has always been optional with Real World Enterprise Software Projects.
As for Agile... well, it has some serious flaws, but really it's gotten a bad rap for the same reason the New Math did: most of the people trying to implement it don't understand it, don't want to understand it, and basically just do the same things they always did while pretending to follow the new plan. Unlike the New Math, which was mostly an attempt to apply 'new and interesting' (read: unfamiliar and confusing) mathematical concepts based more on airy theories than on real teaching practices, Agile is based mainly on the idea of 'do what works and don't fuck around with theory', but doesn't really consider the fact that different projects and teams need different approaches.
-
Even products that are initially perfect for the Mongo way of doing things, like Twitter, become more and more relational over time as they add more features. You want to add retweet tracking? That's a relation. Tweet analytics? Tons of relations there. Embedded media? More relations, especially if you de-dupe images and such. Notifying a user when they're mentioned? Relations.
-
I think Fox is an OK guy.
That is only because you have not read any of his posts.
But you people just seem to be far too easy to anger so I'm assuming he's not that bad.
WE ARE NOT EASILY ANGERED AND IT PISSES ME OFF THAT YOU WOULD SAY SUCH A THING!!!
Seriously though, I don't think that is the case. That guy is to the left of Lenin though and his ideals are seriously misguided. A Fox-led world would make 1984 look like a utopia of freedom.
-
Maybe we can keep a copy of the forum around, and whenever somebody is feeling like things are just a bit too good to be true, they can visit the backup and have their unfounded optimism crushed.
It'll also help against any withdrawal symptoms that may arise from not having list items renumbered and random md5 hashes appearing in posts.
But I'm so used to being told I'm wrong by the forum software when I post, that I don't know what I'd do with the intellectual freedom.
I'll probably make many mistakes when I post.
Possibly even be capable of being understood.
-
And then, everything will change. No more bots. No more cootie storms and isitme... website. No more meta/bugs bitching.
There will still be meta/bugs bitching. But their dev team does not seem like a group of cockholes, so we are a hell of a lot more likely to help them fix their shit when it happens.
-
Possibly even be capable of being understood.
Let's not go crazy. Let us at least stay partially grounded in reality.
-
But, I'm missing the third prong on my plug into the outlet of The Matrix.
-
their dev team does not seem like a group of cockholes
Let's put it this way: I reported a bug that someone PM'd to me and the admins yesterday and they fixed it before I could write a snarky comment as a response to that PM.
-
-
Even products that are initially perfect for the Mongo way of doing things, like Twitter, become more and more relational over time as they add more features. You want to add retweet tracking? That's a relation. Tweet analytics? Tons of relations there. Embedded media? More relations, especially if you de-dupe images and such. Notifying a user when they're mentioned? Relations.
That's a great insight.
NoSQL might scale with traffic, but it doesn't scale in complexity.
-
It's ok, you just use triggers to update the document record.
Because... that's a brilliant idea.
-
A Fox-led world would make 1984 look like a utopia of freedom.
-
Serious question: is Mongo that bad?
It has a history of [url=https://aphyr.com/posts/284-call-me-maybe-mongodb]crappy[/url] [url=https://aphyr.com/posts/322-jepsen-mongodb-stale-reads]behaviour[/url] and even the newest version comes with questionable defaults (for example 'local' read concern, which means a node can return data that hasn't been acknowledged yet and might be rolled back). There are better non-relational data stores around, e.g. RethinkDB.
Not if your blog has multiple authors, categories, more than one page type, comments, revision history, hit counters-- those are all meaningful relations.
You can find meaningful relations in a lot of (if not most) things. Choice of a data store is more of a question about consistency tradeoffs you can make for increased availability. I'd definitely default to relational DB, though, and only consider other options when there's definite need for them. Non-relational is a huge shift in mindset at least.
NoSQL might scale with traffic, but it doesn't scale in complexity.
Eh, complexity will grow, regardless of relational or not. Non-relational stores are much harder to use correctly, but might just be worth it, because at some point your perfectly relational data with strong consistency can be a thorn in your side and it doesn't really have to.
Not that using relational database immediately means you won't scale, they can handle a lot more than some people give them credit for.
Bit aside, I hate the term "NoSQL" a lot. People sometimes talk way too much about schemas and SQL. PostgreSQL in recent versions can be a decent schema-less document store, too (maybe better than Mongo). With SQL! I know I know, doesn't mean that now, etc.
-
You can even use MS SQL Server as a document store, as long as your documents are XML. I have no idea how well that performs, but it's been an implemented feature longer than Mongo has existed.
It's just not "trendy" because it doesn't use JSON.
-
Well, if you index it using keys based on the same XML, I can't image it would perform that much worse.
There are still indexing and storing challenges to noSQL solutions. People seem to pretend those go away for some reason.
Dealt with an obscure document based database RavenDB. It was hellish.
-
We use a continuous Delivery tool called OctopusDeploy.
They recently switched from Raven to SQL Server as a document store.
-
They recently switched from Raven to SQL Server as a document store.
It was the indexing?.... am I right?
We had a small document store, and indexing would literally never finish.
-
Actually, I am led to believe that it was customers who didn't want to have to deal with backups out of their normal database management channels or where policy prohibited Raven because raisins.
We haven't upgraded yet because getting a database created is a pain in my dick, but performance in the Raven version sucks megaballs.
-
Well, if you index it using keys based on the same XML, I can't image it would perform that much worse
Seems somewhat like a full text indexXML Indexes (SQL Server) - SQL Server
Learn how creating XML indexes on xml data type columns can benefit your application by improving query performance.
-
Oh and like with the New Math, Agile development works best when done by professional programmers who actually understand it well and are competent to begin with regardless of methodology. In other words, the people who had success with Agile we're successful because they were good programmers, not because they were using Agile. While Agile has its good points, it actually takes a good deal of effort to make it work, so treating it like a silver bullet for fixing a screwed up development process usually just makes a bad situation worse.
-
Agile is based mainly on the idea of 'do what works and don't fuck around with theory'
That must be why there are so many endless tracts - articles, blogs, websites, books - about the theory of agile and why there are so many different "offshoots" of agile with only tiny differences, each documented in excruciating detail.
-
That must be why there are so many endless tracts - articles, blogs, websites, books - about the theory of agile and why there are so many different "offshoots" of agile with only tiny differences, each documented in excruciating detail.
Naw, just a similar thing to what the Pharisees did to Leviticus law.
People don't like open endedness, so they fabricated a bunch of hard-lined rules in order to be able to check off a list.
The original Agile creed was much more of a spirit of ethics.
-
People don't like open endedness, so they fabricated a bunch of hard-lined rules in order to be able to check off a list.
Dead on target. One of the original tenets of Agile - the one almost everyone forgets about - was 'You aren't going to need it", that is to say, don't work on the parts of the design that are meant to be further down the road until you actually get to that point, don't anticipate need without planning out what it will impact, and don't add anything new until the current development iteration's code is working.
While the people who have heard this have usually taken this to mean, 'don't do any design work, just do everything ad-hoc', which not surprisingly almost exactly the opposite of what it was supposed to mean. The whole point of YAGTNI is planning - but planning done a step at a time, rather than swallowing the bowling ball, planning with an eye to keeping things open-ended, planning that focuses on having hooks for the later work rather than trying to tightly integrate with things that haven't been designed yet. It goes hand in hand with the idea of keeping things in tight iterations, doing one piece of the job, getting it working, the doing the next piece and not going any further until the current step is thoroughly working as it is now and usable enough get meaningful feedback from the client and users about what worked, what needs changing before the next iteration, and what needs to be added during the next one.
Doesn't sound much like most of what passes for Agile in practice, does it?
-
Doesn't sound much like most of what passes for Agile in practice, does it?
I work with protocol work, and there's an array of features that works with existing protocols, and one might argue that every new protocol needs all those features ported before it's usable, even if the new protocol works with devices that don't support those features.
It's better to port the used features first. Then wait until there is need.
-
Now, here's the thing: Agile approaches are suited best for a fairly small range of projects (which just happen to include many but not all web site designs - like with OOP, it caught on mainly because it happened to fit well with a particular set of problems that were becoming common at just the moment it started spreading), needs constant user feedback, and only really works if you have a shit ton of discipline. Does anyone else see where the problem lies in evangelizing this without regard for these facts?
-
Does anyone else see where the problem lies in evangelizing this without regard for these facts?
I'd argue that you can extend it to other projects, but only if you're willing to support a delivery pipeline, and have the capability of in-place upgrading.
That's why they invented this bastardized SAFe, that allows you to have agile development but still use forklift upgrading.
How did they replace the customer interaction?
Hallway testing.
-
forklift upgrading.
Yeah, that doesn't work so well in airliners, either.
Air Crash Investigation - America's Deadliest / Falling To Pieces – 44:41
— José Ataíde
-
A study by Moløkken-Østvold and Haugen[3] found that [the] set of control tasks in the same project, estimated by individual experts, achieved similar estimation accuracy as the planning poker tasks. However, for both planning poker and the control group, measures of the median estimation bias indicated that both groups had unbiased estimates, as the typical estimated task was perfectly on target.
So it's a process wherein people who know what they're doing talk people who don't know what they're doing into agreeing to estimate the same as the people who know what they're doing. As opposed to having the person who knows what they're doing do the estimate.
-
So, when do we get the massive front page article category about all the DiscoWTFs we found?
FTFY
Cyanide & Happiness (Explosm.net)
