tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/898-why-use-robotlegs-more-elaborate-explanation-than-the-book-gives-neededRobotlegs: Discussion 2012-08-27T10:37:48Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T07:43:04Z2012-04-30T07:43:04ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Robotlegs' advantages are mainly felt in large projects, but
obviously when giving examples you need to restrict yourself to
small, simple applications otherwise it gets too complicated to
understand what's going on.</p>
<p>The benefits are two-fold:</p>
<p>1/ project setup: since RL follows the MVCS pattern it allows
and encourages you to structure your project in a decoupled and
organized way from the start. Where you see horizontal complexity,
I see a table-of-contents that tells me what the application does,
w/o the need to dive into the code (if classes are properly named
of course).<br>
Obviously it needs a little getting used to and requires a proper
understanding of the RL paradigm, but if you spend a little time on
examining what the several tiers are, how they are represented in
RL and how they communicate with each other, you'll get the hang of
it pretty quickly.</p>
<p>2/ and this is where RL really shines: maintainability,
scalability and flexibility (and a few other -bilities). When a
project really takes off use cases will change, technologies will
be swapped, scope will creep and unforeseeable problems will arise.
In my experience projects are like massive rivers that just keep on
thundering on, and will follow the path of least resistance. In
other words they grow, shrink and get stuck. RL helps you to easily
adapt your code to these new challenges. In RL you should always
aim not to rewrite parts, but to add new parts and swap the old
obsolete ones with the new relevant ones. Due to the way everything
is decoupled this is very easy to do.</p>
<p>RL is for "real" medium to large projects with distributed teams
and long timelines. Not necessarily so, but that's where it really
makes a huge difference.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T11:32:56Z2012-04-30T11:32:56ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Thanks Creyenders,</p>
<blockquote>
<p>Where you see horizontal complexity, I see a table-of-contents
that tells me what the application does, w/o the need to dive into
the code</p>
</blockquote>
<p>Yes! I love this description :)</p>
<p>Hi Michal,</p>
<p>The Mosaic app was built as a skeleton that implements some
functionality but is ready to become a much more sophisticated app
- there's a limit to what you can do for a book, but we wanted to
do something that was more realistic than a superficial micro app
that wouldn't really justify a framework.</p>
<p>I thought we'd explained that in the book, but I apologise if we
didn't make it clear - it was certainly our intention.</p>
<p>If you wanted to add printing, saving to a network, comments on
designs, versioning, "likes", colour palate export, automatic order
of supplies, pricing, quarter tile counts, special png-based tiles
with flowers on... or pretty much any other feature, you could do
so very easily (once you understand robotlegs).</p>
<p>Also if you wanted to redesign the front end to have a
completely different layout (for iPad for example) then you'd be
able to do that without touching anything except the view tier (and
as creyenders said, you'd add a new one, not change the existing
one).</p>
<p>Then you could continue to publish AIR for desktop, in-browser
swf and iPad versions each with a custom front end.</p>
<p>From your question:</p>
<p>"Most classes are less than 100 LOC"</p>
<p>yes... that's my aim. 60 is great, 100 is passable, 200 is a
problem (except in classes that process long XML, or have internal
styling, though even then I'm always looking to break things out
and usually find that I'm happier when I do).</p>
<p>It's a philosophy - many small, simple things, with defined
single purposes, tested fully, and wired together using consistent
rules and practices.</p>
<p>If you don't buy in to that philosophy then it wouldn't make
sense. For me, that approach has paid off. I'm now approaching 3
years into a huge and fast changing project (we release new
features weekly) and we haven't hit that point where the code
becomes brittle and hard to change yet.</p>
<p>You made an assumption about the time involved. Actually I built
most of this app in less than a day - I built it on my holiday in
Spain, because I'm doing a large mosaic on our house there and I
was finding the process of designing it on paper frustrating. To
me, a day felt pretty quick!</p>
<p>LOC is distorted for code that appears in a book, because you
are limited to around 80 chars per line (sometimes less, depending
on whether you also have annotations), and the code has to be
manually wrapped, so we put a lot of time into splitting things
over several lines that remain readable, where normally one 90
character line would have been more natural.</p>
<p>But, total LOC isn't a useful metric anyway.</p>
<p>Stats show that typically we spend less than 10% of our time
actually writing code, and more than 90% of our time thinking about
code and reading code. So - LOC doesn't really tell you much about
the time involved in a project, because a 50% increase in LOC would
have less impact than a 10% increase in time spent thinking about
the code / reading it.</p>
<p>One purpose of the 60-lines class is that you can see the whole
thing in your laptop text editor in one hit. No scrolling. Instant
mental digestion. As it turns out, it also leads to great
separation of responsibilities. We probably pushed the mini-classes
even harder for the book, because it meant I could reference a
whole class within a page of the book - and that mental "open,
read, close" process has been shown to be more useful to most
learners. Still, I've enjoyed working with the code in that
style.</p>
<p>hth, thanks for asking - it's an important point!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T16:47:24Z2012-04-30T16:47:25ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Thanks for the long and interesting answer. I agree with a lot
of stuff both of you said, but I think you misunderstood me a
little bit. I'm programmer with years of experience, so it's not a
question about "Why should I use RobotLegs over my badly designed
spaghetti code?" but "Why use RobotLegs over writing a well
designed object oriented code?".</p>
<p>So to re-iterate it, assume I already have a well designed code,
that achieves maintainability, scalability and flexibility (and a
few other -bilities). Deciding to use RobotLegs I trade code size
(which negatively affects maintainability) and performance
(plummets quickly in Flash, especially when you favour
over-engineered cluster of objects, which is inevitable with that
amount of classes and scales even faster than projects scope). What
are the gains?</p></div>Michał Dawidowicztag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T17:05:21Z2012-04-30T17:05:22ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>So, while RL makes you 'think less', it has a dangerous negative
effects. Instead of writing a well designed, efficient code, you
hide behind layers of abstractions until you arrive at something
moderately working.</p>
<p>To use the specific example of the Mosaic app, seeing it's
current features and features you write that could be added, it's
the very basic form of a pixel-art graphics editor. The whole
rendering (the 'view') uses 20 different classes and displays each
'pixel' as a separate object. If it used a simple bitmap and just
displayed it scaled up it would not only be much faster and
flexible, but also easier to maintain and scale.</p>
<p>And to clarify my post, my goal is not to bash your code or
framework. It's really popular, even got some awards, but I just
can't see the reason to use it at all and I really want to.</p></div>Michał Dawidowicztag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T17:18:38Z2012-04-30T17:18:38ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>I'm not speaking on behalf of anyone other then myself. But, if
you don't dig it, don't use it. If you are happy with the
architecture you currently use, and it satisfies your needs, then
awesome! For RL users, RL satisfies their use cases, and makes
their code easier to use and understand.</p>
<p>Apples and Oranges, they are both good, and neither is
necessarily "better" then the other, other then to those that love
one or the other :)</p></div>Jos Yuletag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T17:25:46Z2012-04-30T17:25:47ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Thanks for the clarification Jos, that's what I thought, but I
was afraid I'm missing on something.</p></div>Michał Dawidowicztag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T18:25:44Z2012-04-30T18:25:44ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Hello everybody,</p>
<p>There are very good answers at the top by Stray and Creyenders.
When you need to create projects that you will be responsible for
maintenance for sometime or there are quite some interactions
between views you will understand the need for a framework. However
if you are still asking why to use a framework you are not there
yet.</p>
<p>I strongly suggest to give it a try but not with the book
examples go with your own projects, you will see how it helps to
solve your everyday problems.</p>
<p>Bulent.</p>
<p>Note: I do not promise a rose garden, RL or any other framework
comes with their own problems, learning curves etc.</p></div>bulupetag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-04-30T21:24:00Z2012-04-30T21:24:00ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Hi Michal, one of the specific details of the mosaic app is that
each "pixel" as you call it, can be divided into quarters,
triangular quarters - my app actually does this (and it was stated
in the book that this was the intention), and this is why you can't
represent it as a bitmap.</p>
<p>Here's what the image looks like of the mosaic that I designed
with it and that I have almost finished tiling on my wall:</p>
<p><a href=
"http://yfrog.com/oc1r0vp">http://yfrog.com/oc1r0vp</a></p>
<p>As you'll see - it's necessary to display each 'tile' as a
separate object so that it can be further divided into the
triangles. And also so that you can - for example - have 'picture'
tiles - for example with a flower on, or a spot in the center.
These are requirements that I knew were there from the outset,
especially the triangles, hence not using a bitmap.</p>
<p>Robotlegs doesn't force you to make your code as granular as I
choose to make mine. And the example app is not "moderately
working" - the version I published with the book is "moderately
featured" because there is a trade off between adding features and
making it too difficult for the user to follow the examples through
the code base. One purpose of the app was to illustrate how you can
use Robotlegs to begin to build an app that has the capacity to
grow and be maintained.</p>
<p>As I said - we artificially further-divided the code and also
increased the number of lines in order to make the code more
suitable for printing. We also - for obvious reasons - had to
figure out how to make sure that between the two examples we
included every technique that a newcomer would need to be
introduced to. I'm not sure how many books you've written, but
writing code for books is slightly different to writing production
code, but we put a lot of effort into making sure our examples were
closer to the real world than much of the example code you see in
books.</p>
<p>I don't think I'm hiding behind layers of abstractions, but as
Jos said, nobody is holding a gun to your head to use the
framework. As you say - many jobs now request Robotlegs. Either
you're the only developer who can see how dumb we all are, or some
people are seeing merit in using it. I'll leave you to decide which
of those is more likely! (I'm not suggesting that you're dumb for
not seeing it, but that we can't all be using it out of stupidity -
so hopefully if you keep looking you'll start to see what we're all
seeing).</p>
<p>There are many, many examples of apps built with Robotlegs in
the examples section - perhaps you should forget the mosaic app, as
you're clearly distracted by the idea that there are simpler
solutions to the minimal set of features that I've actually
included in the demo, and look at other code instead. For obvious
reasons, unfortunately most of the code that gets written with
Robotlegs is in large applications that aren't open source.</p>
<p>hth,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-01T09:25:02Z2012-05-01T09:25:02ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Just to clarify too:</p>
<blockquote>
<p>so it's not a question about "Why should I use RobotLegs over my
badly designed spaghetti code?" but "Why use RobotLegs over writing
a well designed object oriented code?".</p>
</blockquote>
<p>I didn't assume you're writing spaghetti code. In fact, RL will
NOT save you from writing spaghetti code. Nothing will.<br>
I haven't become a better programmer by using RL (the tips and
techniques I learned from Stray, Shaun, Till and fellow RL-users
however DID make me a better programmer) and it's not the aim of
RL. It's not the aim of any framework AFAIK.<br>
It aims to take away the necessity of writing a lot of boiler-plate
code, to define an organizational structure for your code, to
define conventions that are independent of organization, culture
and background, to aid hooking up the various parts of your
application and to enable the mentioned -bilities.</p>
<blockquote>
<p>Instead of writing a well designed, efficient code, you hide
behind layers of abstractions until you arrive at something
moderately working.</p>
</blockquote>
<p>No, that's just plain wrong. You still write (and are
responsible for writing) well designed, efficient code. RL is not
meant to replace your brain. Just as you can push a nail into a
wall using just your fingers (if you're really patient and a ninja)
you can also decide to use a tool to make your life easier. Whether
you'll end up with a picture frame at the correct spot is up to
you, not the hammer.<br>
It's exactly the same with RL.</p>
<blockquote>
<p>[...] when you favour over-engineered cluster of objects, which
is inevitable with that amount of classes and scales even faster
than projects scope</p>
</blockquote>
<p>Again, the number of classes has nothing to do with complexity
or overengineering. On the contrary, the leaner and smaller my
classes are, the cleaner and more maintainable my code becomes in
my experience. It took me a while to accept, believe and experience
this, but it's an undeniable truth.</p>
<p>Overengineering has to do with adding levels of abstraction that
are not necessary.<br>
(Find a nice example here: <a href=
"http://thedailywtf.com/Comments/The-Enterprise-User-Agent.aspx">http://thedailywtf.com/Comments/The-Enterprise-User-Agent.aspx</a>)
But what does that mean: "not necessary"? When is something
overengineered?<br>
It depends on 2 factors:</p>
<ul>
<li>context</li>
<li>aim</li>
</ul>
<p>With context I mean: will it be developed as a team? Is it a
distributed team? What is the timeframe and work distribution, ie.
does it have a short and intense development time or is it spread
over months, maybe years? Will you see the end of it, or will you
set it up and move on? Are its dependencies (for instance remote
services) in development or stable and tried-and-tested? etc.</p>
<p>Aim: will the product target end-users? Or other developers? Is
it the first building block in a family of
products/modules/libraries etc.? Is it meant to be generic? Or is
it a very specific solution to a very specific use case? Will it
"live" on for years? Or is it a hit-and-run product?</p>
<p>The answers to all these questions determine whether something
is overengineered or not.<br>
In your opinion the mosaic example is overengineered, fine, maybe
it is. However, the context and aim (a book with learning examples
where abstraction is applied to the architecture, NOT to the
example itself (ie. Car extends Vehicle and honks)) were direct
triggers for the decisions made in the architecture and the
architecture should be judged by that context and aim.</p>
<p><strong>Anyway, RL doesn't enforce such an
architecture.</strong></p>
<p>In fact it doesn't enforce an architecture at all. There's no
requirement to use commands, actors and views. It's set up to aid
you if you DO want to, but it works perfectly without.<br>
If you're a MVC purist and want your controller to be exactly that,
a controller class, not a collection of commands, no problem. It's
up to you.<br>
Do you prefer MVP? Sure, why not.<br>
In fact, you don't even have to use it as an DI provider. If you
prefer the service locator pattern, again no problem.</p>
<p>RL allows for all of this.</p>
<p><strong>The problem with explaining the benefits of something
like RL is the same as trying to explain the benefits of
interfaces. As long as you don't use them you don't realize what it
<em>adds</em> to your coding toolbox. It doesn't replace anything.
It allows you to do things more easily and elegantly than before.
Just as you can program in AS3 w/o using interfaces you can survive
w/o using RL. But once you start using it you realize what it was
you were missing out on.</strong></p>
<p>And there are domains in which RL is definitely not the right
choice. I don't use RL for games. I use it for the system
surrounding the game ("pages", leaderboards, etc.) but never for
the game itself.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-01T20:01:39Z2012-05-01T20:01:40ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Have to agree with Michal.</p>
<p>In the Robotlegs documentation it says something like Robotlegs
solves problems that GLOBALS and SINGLETONS create. You really have
to ask who this crap is aimed at. I wonder what C#/C++/Python
developers would make of it.</p>
<p>The Flash community really goes bananas for this kind of stuff,
endlessly discussion Cairngorm PureMVC etc... And gosh when MVC
came out it was like the 2nd coming.</p>
<p>MVC is natural pattern that naturally arises if you have a brain
!!</p>
<p>Yes, a brain - look up from your iPad for just one second.</p>
<p>As for the Dependency Injection (tm) that occurs in Robotlegs,
it just magically inserts into one object, some other objects.
Great ... WTF for ? If the whole point of Robotlegs is so that you
don't think - there are more permanent solutions ... I can get you
a number on that !</p>
<p>If you take a Flash job you never know what the developer has
done. Has he used a framework ? Which one ? And how ? And that is
before you even look at the code. It's just one mess out of another
- forget about the AS3 / runtime documentation ... you have to look
at the goddam Robotlegs non-documentation with real live
non-working examples, and non-compilable source code available on
git.</p>
<p>I made a career on Flash ... but I just don't respect this kind
of non-engineering, non-thinking, laziness.</p>
<p>And the people who defend this kind of thing are the ones ( I
guess ) who think Globals and Singletons are the bees-knees ...
there you go, 90% of Flash devs offended !!</p></div>rideforevertag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-01T20:36:40Z2012-05-01T20:59:38ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>You seem to be confused about what Robotlegs actually is.</p>
<p>The DI container is only one aspect of Robotlegs. Mediator Map,
Command Map, View Map, shared event dispatching, modular
integration... these are partially enabled by the DI container, but
if you think that DI is what Robotlegs 'does' then you're a bit
confused. Automated-DI is the first principle, but it's not the end
of the story.</p>
<p>The whole point of Robotlegs is to reduce "WTF's per minute" -
which, as Uncle Bob says, is the only codebase metric that really
matters. It's not about not thinking, it's about not creating
confusion - those are pretty different. Those of us who use it
spend a hell of a lot of time thinking, but we're thinking about
the interesting, unique aspects of the problem that get the job
done, not wiring issues.</p>
<p>Anyway - you're only the 3rd person ever to have made me sad on
this forum. Thousands of other users have had respectful debates
about all sorts of things, but you're coming across like a troll.
That's not about the content of your opinion - I know some other
great developers who don't go for frameworks either. But really, is
the tone you used the one you want us to use to form our opinion of
you? The message coming through loud and clear is that you have no
respect for fellow developers.</p>
<p>Even if you feel that way, making that attitude public, when
many hundreds of users of this forum know many other people who may
one day be choosing whether to work with you / for you / give you a
job... well - that's an interesting choice.</p>
<p>I'm not sure you've offended 90% of flash devs - probably just
intelligent people who are embarrassed by your attitude.</p>
<p>Please try to engage in a less confrontational, more respectful
tone - whatever point you're making.</p>
<p>Thanks,</p>
<p>Stray</p>
<p>(Btw - I don't have an iPad. Or an iPhone. But if I did, it
wouldn't have any correlation to any other detail about me except
for disposable income and taste in electronics.)</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-01T22:50:40Z2012-05-01T22:50:40ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>Robotlegs is just an Open Source project, some code on the
internet, created and used by people who find this kind of thing
interesting. Why bash it?</p>
<p>It's like being invited to a party and then complaining about
the music - instead of just leaving.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-04T14:50:13Z2012-05-04T14:50:13ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>I think you gals and guys on the RL team have done wonderfully
presenting a clean set of patterns to follow that are easy to
learn, easy to maintain while providing a friendly guide when
developing. RL2 is looking great.</p>
<p>I feel compelled say thank you. So...thank you!</p>
<p>The fun thing about the world wide web are the ill-tempered
drive-bys--as insignificant as they usually are.</p></div>Ricktag:robotlegs.tenderapp.com,2009-10-18:Comment/156315182012-05-08T06:19:40Z2012-05-08T06:19:41ZWhy use Robotlegs? - more elaborate explanation than the book gives needed.<div><p>One very simple point that was probably missed as most of the RL
adoptee's have probably used this technique without thinking about
it anymore.</p>
<p>I recently did architectural design work for a large enterprise
app (1M+ rows of engineering data wasn't an uncommon requirement
with 140+ columns) for a global manufacturer of heavy equipment.
This isn't the point, the point is based on a team of 6 UI people,
and a dozen or so middle-tier and back-end developers, we were
actually able to work in <strong>parallel</strong> development.
This has NEVER occurred in my previous 10+ years of Flash/Flex/AIR
development.</p>
<p>So how did RL help to pull this off so easily? Simple really,
and that's the beauty of it - with the context doing all the wiring
of the IoC pieces, I was able to meet with the leads of both the MT
/ BE, to develop the API in what service methods go with what
parameters and eventual returns even though those services /
databases didn't exist. By creating a testing framework which
generated the VO/DAO on the fly, the 6 of us were able to advance
our gesture / application flow irrespective of real data. Once the
real service became available, it was A SINGLE LINE OF CODE, which
allowed us to swap out the generated code (typically a responder
for a service) for the real hookup.</p>
<p>This is certainly possible with other frameworks and other
languages, but every devotee of alternatives (that I have talked
with) has usually dealt with a very integrated puzzle of test code
sprinkled with production code.</p>
<p>I find this to be the single most valuable piece in the project
puzzle since man-hour effort is by far the biggest variable. Ways
to predictably work in parallel will always reduce the level of
effort to something more tangible, even in very large projects, and
even small ones.</p>
<p>-Hopefully this was enough a 'real-world' use of RL.</p></div>Mike