Managing complexity and untangling my thoughts

ruby-talk
1

Sometimes I stare at the monitor and think: Is it too late
to change majors?

I'm about to start a rewrite of Tycho in my <sarcasm>copious</sarcasm>
spare time.

For those curious about this tool, see
   http://tycho.rubyforge.org
or the RubyConf slides at
   http://rubyhacker.com/tycho/slides

The basic paradigm is a hierarchy of categories, each consisting
of a pile of notes. But structuring the code in proper OO fashion
is nontrivial in my view.

I have spent much time scribbling on napkins and muttering MVC
jargon to myself, but to little avail. I'm confused and my
brain is itching.

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

Sometimes I perceive it as:
   - an object of a certain class
   - the actual text of the note
   - the text plus its metadata
   - the YAML'd version of the text+metadata
   - the key used to look up the record in the db
   - the text field in which the text is displayed
   - the parent widget to which that text field belongs
   - or something else.

I like the idea of composing an object of smaller objects --
for example, store all the GUI stuff in note.widget or
note.gui or something.

But then (among other complications) the note has a title
(note.title) which is also stored in the GUI (note.widget.title) --
these must be kept in sync. :confused: And so on.

What are your mental (or other) tools for dealing with this sort
of complexity?

Thanks,
Hal

2

Hi,

What are your mental (or other) tools for dealing with this sort
of complexity?

I don't know about tools for this. But you could use "tagging" ala
GMail to avoid having to use hierarchies of categories. It should
simplify the GUI and the database. I would use an RDBMS instead of an
OODBMS as well.

I'm not sure about the use of YAML for this. Because a "notes table"
in the database could use detailed fields like "title", "message",
"post_date", etc. Maybe use YAML for the message only? :slight_smile:

I wouldn't worry about MVC because unless you can share a running
server for the different "Views", the data in an RDBMS is enough to
allow for as many different "Views" as the time brings.

It's interesting, but WikiWikis are awesome as well. Maybe you could
create a "Desktop interface" to the Hiki project:
http://sourceforge.jp/projects/hiki

It uses the "file system" itself. :slight_smile: hehe

Cheers,
Joao

3

My recommendation would be fairly XP-ish: Don't worry about overall structure as much as getting features out. Evolve your code as you write it. Use lots of automated tests to make it safe for you to do radical changes mid-stream.

Most of the time, we don't have the luxury of knowing exactly what kind of software we want. And most of the time, getting to use it halfway changes our understanding of the problem.

So don't plan ahead. It's too easy to get AnalysisParalysis that way.

···

On Apr 21, 2005, at 5:57 PM, Hal Fulton wrote:

Sometimes I stare at the monitor and think: Is it too late
to change majors?

I'm about to start a rewrite of Tycho in my <sarcasm>copious</sarcasm>
spare time.

For those curious about this tool, see
  http://tycho.rubyforge.org
or the RubyConf slides at
  Tycho (01)

The basic paradigm is a hierarchy of categories, each consisting
of a pile of notes. But structuring the code in proper OO fashion
is nontrivial in my view.

I have spent much time scribbling on napkins and muttering MVC
jargon to myself, but to little avail. I'm confused and my
brain is itching.

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

Sometimes I perceive it as:
  - an object of a certain class
  - the actual text of the note
  - the text plus its metadata
  - the YAML'd version of the text+metadata
  - the key used to look up the record in the db
  - the text field in which the text is displayed
  - the parent widget to which that text field belongs
  - or something else.

I like the idea of composing an object of smaller objects --
for example, store all the GUI stuff in note.widget or
note.gui or something.

But then (among other complications) the note has a title
(note.title) which is also stored in the GUI (note.widget.title) --
these must be kept in sync. :confused: And so on.

What are your mental (or other) tools for dealing with this sort
of complexity?

Thanks,
Hal

Francis Hwang

4

Hal Fulton wrote:

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

[snip]

What are your mental (or other) tools for dealing with this sort
of complexity?

Duck typing :slight_smile:
If you do employ MVC the the data-centric note is not concerned with
the view-centric note. That's one thing less to worry about.
So how about a data-centric note that duck types to the appropriate
usage? e.g. #to_str, #to_yaml, #properties, #key etc. Then have the
view-centric note just reference (and delegate to) the data note.

But as stated by others - Make It Work before you Make It Right. You
might change your requirements, your understanding of the problem etc.
For example, you have a static category tree where notes are filed. As
my grad project, myself and another student made a bookmark sharing
application. Each bookmark had categories, but each user built his own
tree of categories for display...
Which creates a problem or the UI but actually simplifies the data
model.

HTH,
Assaph

5

Sometimes I stare at the monitor and think: Is it too late

> to change majors?

Me too :slight_smile:

> Make It Work before you Make It Right.

But it sounds like Hal already has it working and is now trying to make it right. Refactoring to patterns is part of XP development lifecycle, but sometimes knowing where to begin what will be large refactoring is tricky. It certainly pays to be incremental, but that still calls for design.

Not a tool, but a personal coping technique: I find reading source for the Eclipse project stretching and a valuable source of practical software pattern solutions to complex problems. Some of the brightest software developers of our era work on the project and it is a mine rich with insight.

Other worthwhile coping mechanisms include sleep, a shower, etc. :slight_smile:

> But then (among other complications) the note has a title
> (note.title) which is also stored in the GUI (note.widget.title) --
> these must be kept in sync. :confused:

Unless your widget simply renders (or adapts) the model, then there is no duplication and nothing to keep in sync.

John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford@pearson.com
http://pearsonedmeasurement.com

6

"Hal Fulton" <hal9000@hypermetrics.com> schrieb im Newsbeitrag
news:426821C2.3040705@hypermetrics.com...

Sometimes I stare at the monitor and think: Is it too late
to change majors?

I'm about to start a rewrite of Tycho in my <sarcasm>copious</sarcasm>
spare time.

For those curious about this tool, see
   http://tycho.rubyforge.org
or the RubyConf slides at
   Tycho (01)

The basic paradigm is a hierarchy of categories, each consisting
of a pile of notes. But structuring the code in proper OO fashion
is nontrivial in my view.

I have spent much time scribbling on napkins and muttering MVC
jargon to myself, but to little avail. I'm confused and my
brain is itching.

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

Sometimes I perceive it as:
   - an object of a certain class
   - the actual text of the note
   - the text plus its metadata
   - the YAML'd version of the text+metadata
   - the key used to look up the record in the db
   - the text field in which the text is displayed
   - the parent widget to which that text field belongs
   - or something else.

I like the idea of composing an object of smaller objects --
for example, store all the GUI stuff in note.widget or
note.gui or something.

But then (among other complications) the note has a title
(note.title) which is also stored in the GUI (note.widget.title) --
these must be kept in sync. :confused: And so on.

What are your mental (or other) tools for dealing with this sort
of complexity?

I'm sorry, I don't have the time to look deeper into this ATM. But one
thing about your post strikes me as odd: you mention "note.widget". This
sounds to me as if the model (note) contains view components (widget). I
think usually it's the other way round: the widget knows the model but the
model doesn't know anything about representation. So it would rather be
"note_widget.note" and this would also remove your problem with the title
synch: "note_widget.title" would look like this "class NoteWidgeg; def
title() note.title end end" (you probably could use delegation for this).

Just my 0.02 EUR....

Kind regards

    robert

7

I've read in the presentation that you're using YAML as a internal data
representation, including metadata.

I would definately recommend you to consider using a RDF model for that
(like Thunderbird and Firefox does). It would give you interoperable
capabilites and also a more flexible data model, and in the near
future, rules-based inferencing and more powerful searching.

My 0.02c

Demetrius

8

Hi Hal,

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

I don't think I understand this confusion. The note itself should
just be text in the end. If it's stored in several different places, shouldn't
you have a parent class which knows how to extract notes from the different sources
via interface classes? I would personally prefer to keep the notes
in one storage format and write interface classes to all classes that need to access the notes.

What are your mental (or other) tools for dealing with this sort
of complexity?

  I don't if I'm answering your question but thought you might like to know of other Ruby
PIMs. Seeing that your project is based on Infoselect features, I take
it you're aware of outliners (for more on them see http://www.chwhat.com/pages/otl.html\).
I've been actively using outliners for over two years, my current favorite being VimOutliner,
http://www.vimoutliner.org. Of the features you mention, it is definitely weak
in the searching and metadata areas.

Thus, I've been experimenting with representing outlines
as tables and treating outlines as a hierarchy of tagged notes. Having recently picked up ruby, I've
made a rudimentary database shell which syncs outlines with tables and is giving outlines the
metadata capability I want. It's very alpha and is based on RubyonRails' ActiveRecord modules giving
me the MVC flexibility. Let me know if you're interested. If you're fairly GUI-dependent, you
probably wouldn't find this interesting.

Gabriel

···

--
my looovely website -- http://www.chwhat.com
BTW, IF chwhat.com goes down email me at gabriel.horner@gmail.com

9

My most valuable mental tools are
1. Once and Only Once: Every bit of data should have a unique place in
which it is stored. This should be the definitive source if you need to
replicate it elsewhere.

2. Bottom Up Programming: Most clearly championed in Paul Graham's On
Lisp, I think, but essentially you grow your language up to meet your
problem

3. Don't Repeat Yourself: Not always easy to follow in practice, but Ruby
helps a lot.

In this specific instance, I'd start with the bare data - the text of
the note and any intrinsic (i.e. not related to the database as a whole)
metadata. Have a small class to store those. Then add methods to output
the data in a variety of formats, and parse a variety of formats to get
that data (essentially accessors). Then start thinking of extrinsic
properties (containers, parents etc) and actual GUI frontends.

As an example, your note title is part of the intrinsic metadata, and
would be stored in your note class. The GUI would need to query the note
for its title, using an accesor like #title

Note that storing extrinsic data like a parent inside a note can be
problematic - I'd recommend having a TreeNode class containing a note,
and storing the parent in that.

martin

···

Hal Fulton <hal9000@hypermetrics.com> wrote:

As one of the slides indicates, part of my confusion is different
ways of thinking about what a "note" is.

Sometimes I perceive it as:
   - an object of a certain class
   - the actual text of the note
   - the text plus its metadata
   - the YAML'd version of the text+metadata
   - the key used to look up the record in the db
   - the text field in which the text is displayed
   - the parent widget to which that text field belongs
   - or something else.

I like the idea of composing an object of smaller objects --
for example, store all the GUI stuff in note.widget or
note.gui or something.

But then (among other complications) the note has a title
(note.title) which is also stored in the GUI (note.widget.title) --
these must be kept in sync. :confused: And so on.

What are your mental (or other) tools for dealing with this sort
of complexity?

10

Sometimes I perceive it as:
   - an object of a certain class
   - the actual text of the note
   - the text plus its metadata
   - the YAML'd version of the text+metadata
   - the key used to look up the record in the db
   - the text field in which the text is displayed
   - the parent widget to which that text field belongs
   - or something else.

All of these things are present in your code. In my experience, the
relationships between such things become clearer when you draw a class
diagram.

11

I meant to respond to this earlier, but ...

I'm not exactly sure whether you are looking for ways to help handle
complexity in general, or specifically looking for a way to organize notes
(and similar) in databases, objects, classes, whatever. In either case:

I've tried quite a few systems (commercial or cobbled together) over the years
to try to take notes and keep them organized, struggling with fitting them
into a relational database or whatever the "paradigm" of the times suggested.

My conclusion: a free format database works best for me, better if it allows
you to include pictures, sketches, blobs, whatever, and allows a wide variety
of search criteria (boolean, proximity (both like in words within a specified
distance of each other, and something like soundex to deal with typos or
similar), ...). Better still if:
   * the content is indexed for faster searching (at least for common
searches)
   * arbitrary structure (tags) can be added or is implicit

askSam was the best thing I found for most of this in the Windows world (but
wasn't quite as good for dealing with (i.e., importing or indexing)
pre-existing documents.

When I first switched to Linux, nobody (I asked) could recommend anything
similar. Then I found wikis which do have similarities. Now I'm
working/hoping to build something more askSam combined with (or based on) the
wiki idea.

Re the arbitrary structure: in askSam, if text contains something like
"Address: <an address>", you can search for records which contain a specific
address. To be more askSam like you can define fields with square brackets,
e.g. Address[ an address] and search those fields. ATM, I can't remember any
difference in functionality between the two approaches, but there may be one.
(I haven't done much with askSam since I started my Linux conversion about 5
years ago.)

regards,
Randy Kramer

···

On Thursday 21 April 2005 05:57 pm, Hal Fulton wrote:

What are your mental (or other) tools for dealing with this sort
of complexity?

12

Robert Klemme wrote:

I'm sorry, I don't have the time to look deeper into this ATM. But one
thing about your post strikes me as odd: you mention "note.widget". This
sounds to me as if the model (note) contains view components (widget). I
think usually it's the other way round: the widget knows the model but the
model doesn't know anything about representation. So it would rather be
"note_widget.note" and this would also remove your problem with the title
synch: "note_widget.title" would look like this "class NoteWidgeg; def
title() note.title end end" (you probably could use delegation for this).

I'm sure this makes sense. My original code was not written from an MVC
perspective.

Hal

13

Dema wrote:

I've read in the presentation that you're using YAML as a internal data
representation, including metadata.

I would definately recommend you to consider using a RDF model for that
(like Thunderbird and Firefox does). It would give you interoperable
capabilites and also a more flexible data model, and in the near
future, rules-based inferencing and more powerful searching.

I had planned to write helper code to export trees to XML and other forms.

I'm ignorant of RDF. Can you explain the benefits in a little more
detail?

Thanks,
Hal

14

Francis Hwang wrote:

My recommendation would be fairly XP-ish: Don't worry about overall structure as much as getting features out. Evolve your code as you write it. Use lots of automated tests to make it safe for you to do radical changes mid-stream.

+100

Regards,

···

--
Bil Kleb
http://fun3d.larc.nasa.gov

15

Randy Kramer <rhkramer@gmail.com> writes:

My conclusion: a free format database works best for me, better if it allows
you to include pictures, sketches, blobs, whatever, and allows a wide variety
of search criteria (boolean, proximity (both like in words within a specified
distance of each other, and something like soundex to deal with typos or
similar), ...). Better still if:
   * the content is indexed for faster searching (at least for common
searches)
   * arbitrary structure (tags) can be added or is implicit

Hal now probably has a chicken-and-egg problem, because that is rather
similar to what he wants to write, no? :slight_smile:

···

regards,
Randy Kramer

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

16

SEMANTIC KNIGHT:
     None shall pass without formally defining the ontological
     meta-semantic thingies of their domain something-or-others!

HACKER:
     What?

http://lists.xml.org/archives/xml-dev/200504/msg00260.html

Cheers

···

On Apr 22, 2005, at 16:25, Hal Fulton wrote:

I had planned to write helper code to export trees to XML and other forms.

I'm ignorant of RDF. Can you explain the benefits in a little more
detail?

--
PA, Onnay Equitursay
http://alt.textdrive.com/

17

I wasn't clear on that, but if so, I'd suggest he try askSam (maybe an early
version, like 3.0--ignore the wordprocessor fluff) and then think about a
Linux workalike.

Which is basically what I am trying to do, using wiki(s) as sort of a
(temporary) back end.

regards,
Randy Kramer

···

On Monday 02 May 2005 08:10 am, Christian Neukirchen wrote:

Randy Kramer <rhkramer@gmail.com> writes:
> My conclusion: a free format database works best for me, better if it
> allows you to include pictures, sketches, blobs, whatever, and allows a
> wide variety of search criteria (boolean, proximity (both like in words
> within a specified distance of each other, and something like soundex to
> deal with typos or similar), ...). Better still if:
> * the content is indexed for faster searching (at least for common
> searches)
> * arbitrary structure (tags) can be added or is implicit

Hal now probably has a chicken-and-egg problem, because that is rather
similar to what he wants to write, no? :slight_smile:

18

LOL!
Thanks for sharing that. I didn't realize that was how I felt until I saw it so aptly put. :slight_smile:

···

On Apr 22, 2005, at 8:33 AM, PA wrote:

SEMANTIC KNIGHT:
    None shall pass without formally defining the ontological
    meta-semantic thingies of their domain something-or-others!

HACKER:
    What?

xml-dev - Re: [xml-dev] Monty Python REST joke

--
(-, /\ \/ / /\/