> When I develop java software (I guess this holds for everything else as
> well though), I have this basic development process set up. Starting
> from scratch, we start with some idea of the basic abstractions, write
> interfaces, then unit tests. Compile. Doesn't work. Write a bit of
> implementation. Compile. Doesn't work. Write a bit more. First test
> green. etc etc. Every now and then, a "unit" is complete. Everything
> glues together using some common pattern (ie IoC, factories, servlet
> setup, xml config, little bit of scripting). Step through it all with a
> debugger to verify behaviour is as expected. Maybe profile a little.
>
> When I try to get to work on gump, it is just not clear how to start,
> and how to go from there. For example, lets say I want to write a
> <magic/> tag like steve requested. Where do I start, how do I test
> things, etc.
> So that's not just "how it works" but also "how do I change it".
>
> concrete question: what is your development process?
I think this is a good question, so please bear with me answering it as
fully as I can. Insights will hopefully help us move Gump forward...
Your above description seems realatively close to mine (for a new project
from scratch), although I'm not great about abstractions/interfaces, I think
in terms of models/players. I tend to have a long term goal/ideas that I am
working towards, but I can't really say I'm good at knowing what point I'm
at in a roadmap, things tend to be quite fluid. I tend to refactor a lot; I
look for re-use and I try to whittle that out of where it is, to share it. I
believe in good practices, good interfaces, good separations, but I think I
tend to allow them to fall by the wayside (since all the code is typically
in my head). I typically need good folks to criticise what I've done for me
to 'see the light' with these issue. I can code, I am not a great designer.
My code typically works, although it isn't beautiful (I typically describe
it as 'fluffy' .. i.e. straightforward, perhaps even if bloated, definately
not cryptic/tight).
With Python and Gump, things are different though. I took on somebody else's
codebase, in a language I didn't know, and I slowly morphed it. I've tried
to get things to work, despite not really understanding what was there,
despite not having a local environment to fully test with. I think this
environment has dominated my thinking; I tend to look for simple changes I
can make and unit test locally, but which I can debug (via CVS, on a remote
server) within short time (at worst the length of time of a Gump run), so I
don't break the Gump's out there. I realize this is limiting, and it has
been challenging, and I think it has disallowed me stepping back and making
bold/brave changed. The two times I've separated out to a branch I've been a
lot happier w/ the amount I can get done, with the boldness of the changes.
Only at these times do the unit tests really help out as they ought. Only
these times do I really step back and try to think big picture.
Basically, I code incremental changes into Gump, that is about all I have
done. I do know that not changing the Gump metadata ('cos of users, 'cos of
traditional) has limited big changes. Further, I don't think I ever
consciously set out to design a 'Gump Engine', although I've tinkered with a
few concepts along the way. For me, the Pythonic XML metadata to model
objects code was 'a foundation of sand' for a long time, since I couldn't
grok how to change it (every attempt hampered or broke it). With the DOM
interface (which isn't beautiful, but functional) I now feel that Gump is
simple (fluffy ;-) and I feel there is finally a basis we can easily
understand and build upon.
Another insight, I feel, is I think that although we all know that Gump 'can
really be something new', none of us quite know what or where it is going.
I've felt that there is power in the data that Gump generates accross
multiple projects, perhaps some opportunity to find some 'cross cutting
concerns' (right word?) within that data. As such, I've focused on trying to
present that data (via HTML) to see if some view of snippet became
singularly valuable. I spent some time generating dependencies diagrams (via
SVG) with different thickness/colour graphs, in the hope of visual insights.
Both these two ran into performance problems (with Forrest/Batik/Python) and
as such have been a struggle (lost in profiling) than a consistent
experiment building upon results. Basically, I don't think either of these
have had their opportunity yet, and I think there is work to do here.
Perhaps daft, but I feel I am (finally) just starting with Gump. I finally
think the codebase is ready for some work by this community (perhaps despite
me ;-). I beleive I finally understand the interactions and needs of code
players, in order to help design/develop a reasonable code base. I am more
than willing to share whatever I have with others here, so we can pool
strengths. [I think we have a fascinatingly eclectic set of
folks/interests/styles on this team, and I want Gump to be open to all those
benefits.]
It seems (to me) that if we can mature the context tree and the runner's
interactions with actors via event (and perhaps requests) then we can start
to allow more extension points w/o unreliability. If we teach folks how to
extend the metadata, and wire metadata changes to extensions, then I think
we have a suitable framework for extension. [As I said before, I'll work on
wiki pages for changes.] When we get to that point, I feel we'll have the
basis for auto-discovered (or workspace described) plug-ins for core aspects
(updaters|builders) and also core result processors (notification,
documentation, stats, whatever).
That said, this is just the fluid state I am in, in my current mental
roadmap -- I could easily see Gump turned on it's head, focus more on
shared/public webapp-based workflows, or focus on local end-user usage/GUIs,
or whatever. I'll do whatever I can to attempt to ensure I don't get in the
way of other's visions, and Gump is open to all.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
