Ideabout
a simple site for sharing ideas

 
   

 

 

tech tantra thursday
   - behind the cosmic curtain with Bill Eberle

prev/first       next/last       toc

 

for thursday june 16, 2011    ← prev    ( 3 )

Cosmic Encounter® Online at Facebook     illustration

 

Also, I realize we were definitely keeping track of some of these kinds of things in our design database for Cosmic Encounter® Online. That database guided our design and the content and subjects of our code, but the information and its actual organization in the database did not flow into the code for Cosmic in any organized way outside of the objects and many of the object attributes and, also, our controlled use of the encounter steps we had defined.

So far what I have is a sort of catalog of elements from my problem domain (reusing code) - 7 elements so far - and of possible areas to explore to come up with a strategy for creating a solutions or solutions. At some point, I'll have to decide that the cataloging is over and choose which direction I want to go in. But not just yet. For now, we're still cataloging possibilities.

And then there's . . . I have to admit there's a part of me that just wants to begin writing code to do some of this, starting from scratch, in my own way . . . one way to learn more about a programming question is to write a program which answers or explores ways to answer the question. We'll see.

An aside, something I just bumped into that's too good to not add to this article and to keep in mind:

“A language that doesn't affect the way you think about programming is not worth knowing” — Alan Perlis

which I found here. And, probably not an aside but germane, I'm poking around looking at Ruby on Rails and I see this:

The Rails philosophy includes several guiding principles:
  • DRY – “Don’t Repeat Yourself” – suggests that writing the same code over and over again is a bad thing.
    Ouch!
  • Convention Over Configuration – means that Rails makes assumptions about what you want to do and how you’re going to do it, rather than requiring you to specify every little thing through endless configuration files.
  • REST is the best pattern for web applications – organizing your application around resources and standard HTTP verbs is the fastest way to go.

So, maybe it's me. Can an old dog learn more tricks? Or will I find after all is said and done that . . .  in some cases repetition is not a bad thing. It's how things get done in the real world.

Hmmm. The fact that the core of Rails is based on the Model, View, Controller object model is interesting. I'll take some time and see what it is all about. And see how well it fits with my current knowledge of and respect for what a well designed database can do for you. This bit -

Models
A model represents the information (data) of the application and the rules to manipulate that data. In the case of Rails, models are primarily used for managing the rules of interaction with a corresponding database table. In most cases, one table in your database will correspond to one model in your application. The bulk of your application’s business logic will be concentrated in the models.

is especially encouraging. Ruby on Rails, a worthy philosophical opponent! What I mean is that I will have my own opinion about how well this language uses database technology. It really would help if I knew I was going to live for another 100 years or so. 30 or 40 (if I live past 100) will have to do.

Also, I haven't forgotten my gleam of an idea about orthogonal information and looking for ways to organize and analyze the specific elements of what it is I'm repeating vs what it is I'm changing.

Decisions. Decisions.

 

 

More to come . . .

 

 

Thanks. — Bill Eberle (for Cosmic)

 

for thursday june 16, 2011    ← prev    ( 3 )

 

Cosmic Encounter® Online at Facebook     illustration

 

 

 

events        prev/first        next/last        tech tantra

 

 

just thinking . . . for fun