[LRUG] Difficult second album
james at billingham.net
Mon Oct 28 15:49:30 PDT 2013
I think I’d agree there. It’s pretty subjective/contextual to case and often people don’t realize the need for it.
I just moved into a CA-based brain science company & have spent a few months helping them realize an architecture where you don’t have 350 models & their related controllers in a single ridiculously slow app, so can relate to your thoughts.
Perhaps talking about it from a fairly abstract angle just explaining practically how a system can be distributed, then they’ll probably reach their own conclusions that it needs doing in the long term.
On Oct 28, 2013, at 10:37 PM, Paul Robinson <paul at 32moves.com> wrote:
> On 28 Oct 2013, at 17:22, Mark Burns <markthedeveloper at gmail.com> wrote:
>> I've been brewing the idea of talking about moving from Rails apps of the
>> scale of 15 minutes blog post through monoliths into services, with a view to separating completely and maybe replacing components (with eek, dare I suggest, maybe non-ruby components) with messaging and queues and the like.
> The problem with this as a talk is that you can't really teach anybody anything. Not because you can't teach anything, but because people only learn what is relevant to them, and it's probably impossible to structure a talk that is relevant to lots of people who are at this point in their app's life cycle.
> If I want to teach you how to use Rails to build a blog, well, OK, I can do that. I can give you Railscasts that show you how to use gems and how to do certain things. That's easy.
> And then you get to a point where you're on your own. You have to go back to the theory and the abstract stuff floating around in the community and look carefully at the problem domain and figure it out by thinking it through.
> Nobody can help you. You're on your own.
> So whilst your talk would perhaps be interesting and act as a siren call to those who are about to hit those problems that O'Reilly and Pragprog.com aint going to be able to help them out much for much longer, what they would expect from such a talk might only actually be given via a few weeks consultancy.
> I'm not trying to say don't do it, I'm saying reduce the scope a little if you want to make it a talk.
> And if you're not convinced, I'm happy to shoot the breeze about these ideas and others. I'm a CTO, have been a CTO, and consulted as a CTO after many years of working as a straight-up developer. The horror stories I could tell you about the exact moment we're talking about here... oh boy...
> Chat mailing list
> Chat at lists.lrug.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1455 bytes
Desc: not available
More information about the Chat