5 Sep
2014
5 Sep
'14
12:28 p.m.
Hi Tim,
You are on the right track. Every analysis engine we built since some years
now relies on using blocks so that you can transform any object into your
desired representation. This includes Roassal and Glamour. Using symbols is
a shortcut by implementing #value: method variations in Symbol.
So, the same example from Alex, could be written as:
| b |
b := RTDoubleBarBuilder new.
b points: RTSVGEntity withAllSubclasses.
b value1: [:class | class numberOfMethods].
b value2: [:class | class numberOfVariables].
b open
So, you can certainly use dictionaries. A good friend here is
Collection>>groupedBy: (in your case, you could do: "tasks groupedBy:
#category). I often use this as a first step, especially when working with
strings, but afterwards you want to consolidate the model. The interesting
thing here is that the smaller the block is, the smoother your model is.
Also, when you can use symbols, you likely got the simplest model you
could. A pretty nice side effect.
This pattern of using transformations that are lazily computed at runtime
based on the current object should make its way in any high level user
interface or analysis engine.
Cheers,
Doru
On Fri, Sep 5, 2014 at 12:04 PM, Tim Mackinnon <tim(a)testit.works> wrote:
It is very useful to see these examples - and that
looks great.
Now that I’ve got my paws on some simple (non code related) data - I’m a
bit at a bit of a loss at how best to express it to communicate interesting
things. I think there is a whole new world of visualisation and thinking
differently that I need to get my head around.
This example is a nice practical one that I could use to show some
insights.
As a more general question - when you are manipulating data in the field,
am I right in thinking there are little tricks/shortcuts that everyone uses
to arrange things such that you can easily visualise things - Or do you end
up modelling everything properly up front?
For example, I have a series of Tasks (that I can pull out of a tracking
system as JSon). This tool doesn’t model things very well (and this is
where the msg from Esug stuck in my head - we have malleable tools that can
do things more easily than others can).
So for example, the titles of the tasks have been entered with "XXXX: Some
description” - so XXX is a type of category (so its a string). I have
created a Task class to wrap the Json data and I created a method #category
to parse this out - but its just a string at the moment.
Now looking at your example, I could visualise the Y axis as being these
tasks (but they are strings) - so I would need to put them in something
that I can send the #valueX msgs to, to get the x values. I could put them
in a Dictionary with key “category” and value being the Task object. Can I
then use blocks for the #valueX msgs? as in: b value1: [ :task | task
estimate]; b value2: [ :task | task duration ]?
I’m trying to get a feel around how you guys work?
I have also just started reading the Roassal pdf and I guess the Moose pdf
as well - as I think its going to take me a while to figure out how to use
these tools like you guys have amazed me with.
Tim
On 5 Sep 2014, at 02:14, Alexandre Bergel <alexandre.bergel(a)me.com> wrote:
Hi!
Just to share the result of a 30 minutes coding session.
Charter has grown with a double bar charter.
| b |
b := RTDoubleBarBuilder new.
b points: RTSVGEntity withAllSubclasses.
b value1: #numberOfMethods.
b value2: #numberOfVariables.
b open
produces the following:
<Screen Shot 2014-09-04 at 9.10.30 PM.png>
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"