[LRUG] Difficult second album

[Mark Burns]

Thanks Paul,

It's a good point, you're right. It's difficult to sketch out exactly how
much information to convey and at what level to pitch it at.

I like the siren call idea. If you see pattern A, you might want to try
solution B.
Solution D is also relevant, but maybe not until you start to get C
happening.

It would be good to express a few examples of well known maxims/idioms and
what issues these solve. Along with situations where they may not be
appropriate.

Maybe with examples simple enough that anyone can imagine the progression
through into larger and more complex systems, even if they haven't
experienced that progression first-hand.

Basically, I can't teach you Thai, Vietnamese or Japanese, but I could help
you learn to spot the differences between them. You can learn a few
greetings and recognize them when confronting them, but you're going to
need to do some self study to learn anything of value, and you'll need to
live there to be fluent.

I think I'd probably want to focus more on aspects of moving away from
monoliths if focusing on anything. Especially as that probably sounds
closer to that title.





On 28 October 2013 22:37, 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
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20131028/7d109b72/attachment-0003.html>