playnowbot

Auxbuss: There is effort in creating a queue. A tiny amount of effort — one line in a while loop. You jest, surely? Don’t write your own queue! There are a bunch of great queueing servers out there. I suspect you didn’t mean that, but instead meant that there’s a while loop which talks to the queueing server – redis or whatever, as you note. So, I think you’re undervaluing the effort required in configuration and daemon management: you need to install your queue manager (not hard), and then configure it to work the way you want.

That bit is hard, because you have to understand the queue software and how its config works and what that means: do you want the queue to be preserved if the queue manager crashes? How do you configure your software to do that? To restore the queue after a dirty restart? All of this stuff is possible: none is trivial. Redis is better than this at most because Salvatore works really really hard on this particular aspect, but you still have to understand it quite well to configure it right.

That’s why, for example, running the queue purely in memory isn’t a good idea – you don’t just lose the message you’re working on, you lose all messages in the queue on any crash, which is not ideal at all. Basically, I’m of the opinion that using the right tools for the right job is, of course, the right thing to do but using a very powerful tool to meet a very simple need is often extremely difficult exactly because you have to work out how to configure all the power out of the tool so that it only meets your simple use case! I should note, here, that I have known form with thinking “this project doesn’t need anything complex like Django, I’ll just lash something together” and then six months down the line realising that the project is still going, is more complex now than it was then, and I wish I had the django admin lying around. So there is a reasonable case for using something with way more features than you need now, because you might need them later and adding them later will be really hard. This idea is in direct contravention to the whole “keep it simple, stupid” approach, and deciding where the boundary lies is something that I’m working on getting better at myself! Sil: This idea is in direct contravention to the whole “keep it simple, stupid” approach, and deciding where the boundary lies is something that I’m working on getting better at myself!

Stuart Langridge On Twitter: This Is Pretty Cool For Macbook Pro

My tag line is: obsessed with simplicity. As I mentioned earlier, I regard the CSV solution as more complex. My day job is, basically, helping businesses get out of the mess they’ve created. Typically, a business that has become successful without any focus on the quality of their software (by which I chiefly mean maintainability) and that now finds itself painted into a corner (where the limiting factor has become the ability to adapt their software). After lack of tests, the biggest problem I encounter is home brewed solutions to problems that have grown out of all proportion to the original use and on which the whole system depends. You probably know the rest of the story: no-one knows how deep the rabbit hole goes, and no-one want to touch it. On that basis, when developing, I practice a kind of “YAGNI, but you probably will”.

Stuart Langridge On Twitter: This Is Pretty Cool For Mac Free

If the overhead to provide vastly more flexibility and functionality is very small, then it’s worth doing from the outset. I should add that we are considering redis here, which I regard as ubiquitous nowadays. Auxbuss: There is no need to turn of redis’ persistence. I think we may be talking at cross-purposes here. Let me try and explain what I mean a different way. If you already know and like redis, sure, definitely use it! But if you’re coming at this from the perspective of “do I need to use a queue?

Which queue?” then you don’t know whether to pick redis, or beanstalkd, or rabbitmq, or SQS, or celery, or, or,. And you don’t know whether redis has persistence enabled by default, or whether beanstalkd does, or whether rabbitmq does and you don’t know how to find that out without a relatively deep dive into the documentation for each of those systems, which is a lot of work and you don’t know how to ensure that the queue server starts on boot, and restarts on crash, and restores its data automatically in both of those situations, and how to configure how much memory it uses, and As I say: redis does a pretty good job of sensible defaults for most of these things. But if you’re not already a semi-experienced redis user, you don’t know this. And even if you are, you don’t know it about beanstalkd, and so you don’t know how to choose which is best for your current project. I think that there is a huge amount of sheer decision paralysis which comes from not knowing anything about an area and having to choose between all the different possibilities there.

Stuart Langridge On Twitter: This Is Pretty Cool For Mac Lyrics

That’s quite a terrifying experience, for most people. I don’t think that using redis is overengineering. But I do think that it’s difficult to get to the stage where you know enough about it to be confident that it’s actually doing what you want, and normally getting to that stage involves getting bitten a bunch of times when you thought it was doing a thing and actually it isn’t. As noted, Salvatore really cares about the default experience and so works hard on this; others don’t anywhere near as much. I guess we’re miles off topic now I pretty much agree with what you’ve said, though I believe you overstate the complexity, and I don’t share your view about the complexity of learning redis.

It’s a k/v store with tons of extras; learn them as you go. (Geez, beanstalkd, folk I talk to keep bringing that up.) For sure, knowledge and experience is a bonus. However, asked a question, and I suggested a solution. I’m more than happy to extend that to knowledge sharing. I genuinely wish more folk in our business asked questions and persisted. If everyone goes through trial and error on each problem, then progress will be excruciatingly slow. At bottom, I’d prefer (wish?) folk didn’t revert to CSV (or even flat file) solutions as the default “simple” solution.

I don’t believe they are, in most cases. (Caveat: CSV solutions are valid, especially for exports for users requiring spreadsheet data, and slow moving, large datasets that can be compressed. And yup, flat files are cool too. I use them ).