Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #10069 > unrolled thread

Standard Design and Development Methodologies

Back to article view | Back to comp.lang.java.programmer

Contents

  Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-19 19:42 +0000
    Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-19 21:22 -0500
      Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 16:55 +0000
        Re: Standard Design and Development Methodologies "Charles Hottel" <chottel@earthlink.net> - 2011-11-20 22:20 -0500
    Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-19 23:01 -0400
      Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 20:13 -0800
        Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 20:16 -0800
        Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-19 23:49 -0500
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-19 23:45 -0800
            Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-20 03:49 -0500
              Re: Standard Design and Development Methodologies Robert Klemme <shortcutter@googlemail.com> - 2011-11-20 13:58 +0100
              Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 08:32 -0800
                Re: Standard Design and Development Methodologies "Derek K. Wodenhouse" <dkw@none.of.your.biz> - 2011-11-20 18:24 -0500
          Re: Standard Design and Development Methodologies Patricia Shanahan <pats@acm.org> - 2011-11-20 03:27 -0800
            Re: Standard Design and Development Methodologies spk <jhic@speak.invalid> - 2011-11-20 09:54 -0400
              Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 08:33 -0800
              Re: Standard Design and Development Methodologies thoolen <th00len@th0lenbot.thorium> - 2011-11-20 18:30 -0500
        Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-20 09:35 -0400
        Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 17:18 +0000
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 10:30 -0800
            Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:23 -0400
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:51 -0500
          Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-25 20:07 -0800
      Re: Standard Design and Development Methodologies Novice <novice@example..com> - 2011-11-20 17:08 +0000
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-20 12:18 -0500
        Re: Standard Design and Development Methodologies markspace <-@.> - 2011-11-20 10:29 -0800
        Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 10:55 -0800
          Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-20 14:07 -0500
            Re: Standard Design and Development Methodologies Lew <lewbloch@gmail.com> - 2011-11-20 11:50 -0800
        Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:19 -0400
    Re: Standard Design and Development Methodologies Roedy Green <see_website@mindprod.com.invalid> - 2011-11-20 22:27 -0800
      Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-21 07:02 -0400
        Re: Standard Design and Development Methodologies Robert Klemme <shortcutter@googlemail.com> - 2011-11-22 18:52 +0100
          Re: Standard Design and Development Methodologies markspace <-@.> - 2011-11-22 11:37 -0800
            Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-22 14:27 -0800
              Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 22:06 -0500
                Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-26 21:16 -0800
                  Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:53 -0500
                    Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-12-04 21:25 -0800
                      Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:41 -0500
                        Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-12-05 19:58 -0800
            Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-22 19:57 -0400
              Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 22:04 -0500
                Re: Standard Design and Development Methodologies Gene Wirchenko <genew@ocis.net> - 2011-11-26 21:18 -0800
                  Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-11-27 08:34 -0400
                    Re: Standard Design and Development Methodologies Patricia Shanahan <pats@acm.org> - 2011-11-27 08:39 -0800
                      Re: Standard Design and Development Methodologies Martin Gregorie <martin@address-in-sig.invalid> - 2011-11-27 20:07 +0000
                    Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-02 21:48 -0500
                      Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-03 14:52 -0400
                        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-12-05 22:50 -0500
                          Re: Standard Design and Development Methodologies Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-06 07:21 -0400
        Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:54 -0500
      Re: Standard Design and Development Methodologies Arne Vajhøj <arne@vajhoej.dk> - 2011-11-25 21:47 -0500

Page 1 of 3  [1] 2 3  Next page →

#10069 — Standard Design and Development Methodologies

I have a very general question that isn't really even specific to Java but 
I'd appreciate your thoughts on this. 

I'm a Java hobbyist. I've been writing code in Java for a while because I 
like the language but haven't really used current standard design and 
programming methodologies in a formal way to develop my code, sticking to 
older methodologies that I learned long ago, like structured programming 
and structured design. I'm thinking of trying to get paying work as a full-
time employee in a company using Java but I think I'm going to have to 
acquire some new skills to be a credible candidate for a junior position in 
systems development. 

What are the standard design and development methodologies being used in 
systems departments these days and, ideally, where can I find tutorials for 
them, preferably free and online? 

I expect that I will have to get at least a working knowledge of a bunch of 
things, including OO Design, Patterns, and a dozen other things to have any 
chance but, as a Chinese philosopher once said "a journey of a thousand 
miles begins with a single step". I'd appreciate your help in building a 
list of the things that someone like your employer would want met to have 
before considering me for a junior position writing Java. 

-- 
Novice

[toc] | [next] | [standalone]

#10082

On 11/19/2011 2:42 PM, Novice wrote:
> I have a very general question that isn't really even specific to Java but
> I'd appreciate your thoughts on this.
>
> I'm a Java hobbyist. I've been writing code in Java for a while because I
> like the language but haven't really used current standard design and
> programming methodologies in a formal way to develop my code, sticking to
> older methodologies that I learned long ago, like structured programming
> and structured design. I'm thinking of trying to get paying work as a full-
> time employee in a company using Java but I think I'm going to have to
> acquire some new skills to be a credible candidate for a junior position in
> systems development.
>
> What are the standard design and development methodologies being used in
> systems departments these days and, ideally, where can I find tutorials for
> them, preferably free and online?
>
> I expect that I will have to get at least a working knowledge of a bunch of
> things, including OO Design, Patterns, and a dozen other things to have any
> chance but, as a Chinese philosopher once said "a journey of a thousand
> miles begins with a single step". I'd appreciate your help in building a
> list of the things that someone like your employer would want met to have
> before considering me for a junior position writing Java.

OOA/OOD/OOP + design patters seems to be what to focus on.

GoF book
Code Complete
Applying UML and Patterns/Larman
Effective Java/Bloch

could be useful books to study.

Arne

[toc] | [prev] | [next] | [standalone]

#10102

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:4ec86452$0$288$14726298@news.sunsite.dk: 

> On 11/19/2011 2:42 PM, Novice wrote:
>> I have a very general question that isn't really even specific to
>> Java but I'd appreciate your thoughts on this.
>>
>> I'm a Java hobbyist. I've been writing code in Java for a while
>> because I like the language but haven't really used current standard
>> design and programming methodologies in a formal way to develop my
>> code, sticking to older methodologies that I learned long ago, like
>> structured programming and structured design. I'm thinking of trying
>> to get paying work as a full- time employee in a company using Java
>> but I think I'm going to have to acquire some new skills to be a
>> credible candidate for a junior position in systems development.
>>
>> What are the standard design and development methodologies being used
>> in systems departments these days and, ideally, where can I find
>> tutorials for them, preferably free and online?
>>
>> I expect that I will have to get at least a working knowledge of a
>> bunch of things, including OO Design, Patterns, and a dozen other
>> things to have any chance but, as a Chinese philosopher once said "a
>> journey of a thousand miles begins with a single step". I'd
>> appreciate your help in building a list of the things that someone
>> like your employer would want met to have before considering me for a
>> junior position writing Java. 
> 
> OOA/OOD/OOP + design patters seems to be what to focus on.
> 
> GoF book
> Code Complete
> Applying UML and Patterns/Larman
> Effective Java/Bloch
> 
> could be useful books to study.
> 
Thanks Arne. I already have Effective Java, although I haven't made the 
time to go through it yet. I'll have to track down the others and make time 
to work my way through them - and practice what they suggest as best I can!  





-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10135

"Novice" <novice@example..com> wrote in message 
news:Xns9FA37947FDBC3jpnasty@94.75.214.39...
> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:4ec86452$0$288$14726298@news.sunsite.dk:
>
>> On 11/19/2011 2:42 PM, Novice wrote:
>>> I have a very general question that isn't really even specific to
>>> Java but I'd appreciate your thoughts on this.
>>>
>>> I'm a Java hobbyist. I've been writing code in Java for a while
>>> because I like the language but haven't really used current standard
>>> design and programming methodologies in a formal way to develop my
>>> code, sticking to older methodologies that I learned long ago, like
>>> structured programming and structured design. I'm thinking of trying
>>> to get paying work as a full- time employee in a company using Java
>>> but I think I'm going to have to acquire some new skills to be a
>>> credible candidate for a junior position in systems development.
>>>
>>> What are the standard design and development methodologies being used
>>> in systems departments these days and, ideally, where can I find
>>> tutorials for them, preferably free and online?
>>>
>>> I expect that I will have to get at least a working knowledge of a
>>> bunch of things, including OO Design, Patterns, and a dozen other
>>> things to have any chance but, as a Chinese philosopher once said "a
>>> journey of a thousand miles begins with a single step". I'd
>>> appreciate your help in building a list of the things that someone
>>> like your employer would want met to have before considering me for a
>>> junior position writing Java.
>>
>> OOA/OOD/OOP + design patters seems to be what to focus on.
>>
>> GoF book
>> Code Complete
>> Applying UML and Patterns/Larman
>> Effective Java/Bloch
>>
>> could be useful books to study.
>>
> Thanks Arne. I already have Effective Java, although I haven't made the
> time to go through it yet. I'll have to track down the others and make 
> time
> to work my way through them - and practice what they suggest as best I 
> can!
>
> -- 
> Novice

Before reading GoF book I would suggest Head First Design Patterns. 

[toc] | [prev] | [next] | [standalone]

#10083

On 11-11-19 03:42 PM, Novice wrote:
> I have a very general question that isn't really even specific to Java but 
> I'd appreciate your thoughts on this. 
> 
> I'm a Java hobbyist. I've been writing code in Java for a while because I 
> like the language but haven't really used current standard design and 
> programming methodologies in a formal way to develop my code, sticking to 
> older methodologies that I learned long ago, like structured programming 
> and structured design. I'm thinking of trying to get paying work as a full-
> time employee in a company using Java but I think I'm going to have to 
> acquire some new skills to be a credible candidate for a junior position in 
> systems development. 
> 
> What are the standard design and development methodologies being used in 
> systems departments these days and, ideally, where can I find tutorials for 
> them, preferably free and online? 
> 
> I expect that I will have to get at least a working knowledge of a bunch of 
> things, including OO Design, Patterns, and a dozen other things to have any 
> chance but, as a Chinese philosopher once said "a journey of a thousand 
> miles begins with a single step". I'd appreciate your help in building a 
> list of the things that someone like your employer would want met to have 
> before considering me for a junior position writing Java. 
> 
You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology. This is
of value primarily because it introduces a lot of common terminology.

Ultimately _every_ software development methodology (SDM) boils down to:

1. requirements analysis - understanding what the client needs you to do;
2. analysis & design - how you intend to meet those needs. See
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
we are talking Java, for general concepts;
3. implementation - actually write code;
4. testing - ensuring that your code, as written, satisfies the
requirements;
5. maintenance - nurturing the application over its lifespan.

How all the various approaches differ is how they break up and sequence
these activities. What really matters is that all these activities are
important.

It's probably best not to fixate on any given methodology. Just learn up
on the highlights of each, and keep in mind that all of them ultimately
boil down to requiring competence in the same skills. You'd be
interested initially in object-oriented analysis (OOA), object-oriented
design (OOD), and how to test your code (starting with unit testing and
perhaps functional testing).

Like Arne suggested, "Effective Java" by Bloch is a great book. So is
"Code Complete". IMO I wouldn't bother buying a copy of the GOF design
patterns book; borrow from a university library or locate a decent
website instead. Read some Martin Fowler
(http://martinfowler.com/intro.html). Don't get hung up on specific
methodologies (did I say that already?) - no project ever succeeded or
failed just because of what methodology a team used. Get some
familiarity with UML but don't go overboard with it.

My own specific suggestion - read
http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
also a good author). CRC is not just useful in agile.

If your understanding of persistence (databases) is not solid - in your
estimation, bone up on that.

If you don't have one already, select another OO programming language to
learn. You can make a lot more headway in learning all of the above if
you're not tied to one specific language. Just my opinion.

AHS
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#10084

Arved Sandstrom wrote:
> Novice wrote:
>> What are the standard design and development methodologies being used in 
>> systems departments these days and, ideally, where can I find tutorials for 
>> them, preferably free and online? 
>> 
> You could probably do worse than to read
> http://en.wikipedia.org/wiki/Software_development_methodology. This is
> of value primarily because it introduces a lot of common terminology.
> 
> Ultimately _every_ software development methodology (SDM) boils down to:
> 
> 1. requirements analysis - understanding what the client needs you to do;
> 2. analysis & design - how you intend to meet those needs. See
> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
> we are talking Java, for general concepts;
> 3. implementation - actually write code;
> 4. testing - ensuring that your code, as written, satisfies the
> requirements;
> 5. maintenance - nurturing the application over its lifespan.
> 
> How all the various approaches differ is how they break up and sequence
> these activities. What really matters is that all these activities are
> important.

There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published. 

Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.

As such an individual (as you should be, too), I have a toolbox of ways to look at a programming assignment - a kit of ontologies.  

First and most fundamental skill - to look it up.  Whatever the unfamiliar concept or skill, there is never an expert enough who's patient enough with time enough and communication talent enough to explain it for you.  You have to be able to do with fragments of advice (at best) and what you discover for yourself - through hard, hard study and very pragmatic experimentation.  A former mentor of mine trained me that any IT person spending less than 20% over and above their normal work time to study and practice was doomed to fall behind.

'Struth.

As for ontologies, the most useful ones I know are event-driven programming, object-oriented programming, MVC (model-view-controller), layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my own term for using the language of the problem domain (its nouns and verbs) to define your program structures.

There's one style trick that induces better code:  Keep it short.  After about 500 lines of code and comment (yes, and comment) your class should feel too large, and after about 700-800 lines you should be castigating yourself.  

The pressure to keep it short helps you think more clearly about structure.

And there's one mandatory, cross-methodology practice:  Javadoc the shit out of your code.  Document private and package-private methods and all static variables down to private.  The extra asterisk at the start of the comment block hurts nothing.

Don't use specious comments, the kind that repeat what the code already says:

  for (Foo foo : bunchOfFoos) // operate on each of the Foos

Pfeh!  If a person doesn't know what a for-each loop is, such a comment will not rescue them.

Do liberally comment anything that makes a maintainer go, "Hmm."

  // volatile: thread calling close() might not be same as called perform()
  private volatile boolean isStopping;

This advice might not fit your idea of what constitutes a "methodology", but for Pete's sake, think.  What does that "ology" suffix buy you but buzzword compliance?  The real need is for a _method_, a process by which you can produce effective, reliable, correct software on time to spec.  In the end it's all about your personal commitment and skill.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10085

Lew wrote:
> There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published. 

http://www.google.com/search?q=ISBN%20013590126X

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10086

On 19/11/2011 11:13 PM, Lew wrote:

> As for ontologies, the most useful ones I know are event-driven
> programming, object-oriented programming, MVC (model-view-controller),
> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my
> own term for using the language of the problem domain (its nouns and
> verbs) to define your program structures.

That last is also known as "programming in Lisp". ;)

[toc] | [prev] | [next] | [standalone]

#10087

Derek K. Wodenhouse wrote:
> Lew wrote:
>> As for ontologies, the most useful ones I know are event-driven
>> programming, object-oriented programming, MVC (model-view-controller),
>> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my
>> own term for using the language of the problem domain (its nouns and
>> verbs) to define your program structures.
> 
> That last is also known as "programming in Lisp". ;)

Trivially, since the technique applies irrespective of platform.

It's also known as "programming in /X/", where /X/ is any programming language.

Thank you for your useful observation.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10090

On 20/11/2011 2:45 AM, Lew wrote:
> Derek K. Wodenhouse wrote:
>> Lew wrote:
>>> As for ontologies, the most useful ones I know are event-driven
>>> programming, object-oriented programming, MVC (model-view-controller),
>>> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my
>>> own term for using the language of the problem domain (its nouns and
>>> verbs) to define your program structures.
>>
>> That last is also known as "programming in Lisp". ;)
>
> Trivially, since the technique applies irrespective of platform.
>
> It's also known as "programming in /X/", where /X/ is any programming language.

Not nearly as strongly. Lisps let you reify nearly any program 
abstraction, and build a bridge from the solution domain to the problem 
domain, expressing most of the business logic in problem domain terms. A 
common program design in another language consists of a problem domain 
focused library, plus an application layer atop that that contains the 
business logic but is still largely written in solution domain terms, 
with a sprinkling of problem domain nouns and verbs. A common program 
design in Lisp consists of a domain-specific language for the problem 
domain, in Lisp, and an application in that language with a sprinkling 
of generic-Lisp nouns and verbs (mostly lists and data structure 
traversals, and/or numbers and arithmetic -- much of which might be 
regarded as present also in the problem domain).

[toc] | [prev] | [next] | [standalone]

#10094

On 11/20/2011 09:49 AM, Derek K. Wodenhouse wrote:
> On 20/11/2011 2:45 AM, Lew wrote:
>> Derek K. Wodenhouse wrote:
>>> Lew wrote:
>>>> As for ontologies, the most useful ones I know are event-driven
>>>> programming, object-oriented programming, MVC (model-view-controller),
>>>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
>>>> own term for using the language of the problem domain (its nouns and
>>>> verbs) to define your program structures.
>>>
>>> That last is also known as "programming in Lisp". ;)
>>
>> Trivially, since the technique applies irrespective of platform.
>>
>> It's also known as "programming in /X/", where /X/ is any programming
>> language.
>
> Not nearly as strongly. Lisps let you reify nearly any program
> abstraction, and build a bridge from the solution domain to the problem
> domain, expressing most of the business logic in problem domain terms. A
> common program design in another language consists of a problem domain
> focused library, plus an application layer atop that that contains the
> business logic but is still largely written in solution domain terms,
> with a sprinkling of problem domain nouns and verbs. A common program
> design in Lisp consists of a domain-specific language for the problem
> domain, in Lisp, and an application in that language with a sprinkling
> of generic-Lisp nouns and verbs (mostly lists and data structure
> traversals, and/or numbers and arithmetic -- much of which might be
> regarded as present also in the problem domain).

It's also pretty easy to create DSL's in - say Ruby - so Lisp is not 
unique with respect to that.  One can go even further and call any Java 
library (in fact, _any_ library) a domain specific language.  The 
difference with Lisp is that it's basic syntax is trivial (sexpr) and it 
has Macros which can make special forms look like regular function calls 
by which means you can do things in this language which you cannot (or 
not as easily) in others.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#10099

On Sunday, November 20, 2011 12:49:39 AM UTC-8, Derek K. Wodenhouse wrote:
> On 20/11/2011 2:45 AM, Lew wrote:
> > Derek K. Wodenhouse wrote:
> >> Lew wrote:
> >>> As for ontologies, the most useful ones I know are event-driven
> >>> programming, object-oriented programming, MVC (model-view-controller),
> >>> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my
> >>> own term for using the language of the problem domain (its nouns and
> >>> verbs) to define your program structures.
> >>
> >> That last is also known as "programming in Lisp". ;)
> >
> > Trivially, since the technique applies irrespective of platform.
> >
> > It's also known as "programming in /X/", where /X/ is any programming language.
> 
> Not nearly as strongly. Lisps let you reify nearly any program 
> abstraction, and build a bridge from the solution domain to the problem 
> domain, expressing most of the business logic in problem domain terms. A 

So does Java, C++, BASIC, Fortran, Ada, F#, Javascript, Forth, ...

> common program design in another language consists of a problem domain 
> focused library, plus an application layer atop that that contains the 
> business logic but is still largely written in solution domain terms, 

Hahaha.

> with a sprinkling of problem domain nouns and verbs. A common program 
> design in Lisp consists of a domain-specific language for the problem 
> domain, in Lisp, and an application in that language with a sprinkling 
> of generic-Lisp nouns and verbs (mostly lists and data structure 
> traversals, and/or numbers and arithmetic -- much of which might be 
> regarded as present also in the problem domain).

Language War!  Language War!  

I'm breaking out my popcorn.

Just so you know, you Lisp fanboys love to cause fights, but where's the money in programming, hm?

Go have fun in your playpen.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#10131

On 20/11/2011 11:32 AM, Lew wrote:
> On Sunday, November 20, 2011 12:49:39 AM UTC-8, Derek K. Wodenhouse wrote:
>> On 20/11/2011 2:45 AM, Lew wrote:
>>> Derek K. Wodenhouse wrote:
>>>> Lew wrote:
>>>>> As for ontologies, the most useful ones I know are event-driven
>>>>> programming, object-oriented programming, MVC (model-view-controller),
>>>>> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is my
>>>>> own term for using the language of the problem domain (its nouns and
>>>>> verbs) to define your program structures.
>>>>
>>>> That last is also known as "programming in Lisp". ;)
>>>
>>> Trivially, since the technique applies irrespective of platform.
>>>
>>> It's also known as "programming in /X/", where /X/ is any programming language.
>>
>> Not nearly as strongly. Lisps let you reify nearly any program
>> abstraction, and build a bridge from the solution domain to the problem
>> domain, expressing most of the business logic in problem domain terms. A
>
> So does Java, C++, BASIC, Fortran, Ada, F#, Javascript, Forth, ...

You're joking, right? Java programmers had to wait for Sun to add the 
foreach loop. Lisp programmers would have been able to add it 
themselves. Moreover, it can be reified and given a name and treated 
like other program data in Lisp.

> Language War!  Language War!
>
> I'm breaking out my popcorn.
>
> Just so you know, you Lisp fanboys love to cause fights, but where's the money in programming, hm?

Popcorn is irrelevant. Money is irrelevant. You will be assimilated. 
Resistance is futile.

;)

[toc] | [prev] | [next] | [standalone]

#10091

On 11/19/2011 8:49 PM, Derek K. Wodenhouse wrote:
> On 19/11/2011 11:13 PM, Lew wrote:
>
>> As for ontologies, the most useful ones I know are event-driven
>> programming, object-oriented programming, MVC (model-view-controller),
>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
>> own term for using the language of the problem domain (its nouns and
>> verbs) to define your program structures.
>
> That last is also known as "programming in Lisp". ;)

Why do you feel it is limited to Lisp? It seems to me to be generally
useful, regardless of the programming language. It is certainly useful
for design of Java programs.

Patricia

[toc] | [prev] | [next] | [standalone]

#10097

Patricia Shanahan <pats@acm.org>, wrote:
>On 11/19/2011 8:49 PM, Derek K. Wodenhouse wrote:
>> On 19/11/2011 11:13 PM, Lew wrote:
>>
>>> As for ontologies, the most useful ones I know are event-driven
>>> programming, object-oriented programming, MVC (model-view-controller),
>>> layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
>>> own term for using the language of the problem domain (its nouns and
>>> verbs) to define your program structures.
>>
>> That last is also known as "programming in Lisp". ;)
>
>Why do you feel it is limited to Lisp? It seems to me to be generally
>useful, regardless of the programming language. It is certainly useful
>for design of Java programs.
>
>Patricia

From: thoolen <th00len@th0lenbot.thorium>
Newsgroups: comp.lang.java.programmer
Subject: Re: toward null-safe cookie cutter Comparators
Followup-To: comp.os.os2.advocacy
Date: Fri, 18 Nov 2011 15:21:25 -0500
Organization: thingamajig
Message-ID: <ja6eo9$boj$1@speranza.aioe.org>
References: <hkuvb758inpkqmju7aeeln2nab28i0aue6@4ax.com>
<alpine.DEB.2.00.1111131750140.19917@urchin.earth.li>
<onl2c7hnvjaogv8ulhti0ius9hei4ce3mp@4ax.com>
<kudwq.20012$am1.18958@newsfe05.iad> <ja0t5t$kms$1@speranza.aioe.org>
<4ec5471f$0$22559$c3e8da3$e3f2c276@news.astraweb.com>
<14715296.1119.1321552560149.JavaMail.geo-discussion-forums@prnv30>
<4ec54bae$0$22559$c3e8da3$e3f2c276@news.astraweb.com>
<slrnjcanp7.fvg.avl@gamma.logic.tuwien.ac.at>
<23591489.9.1321566539494.JavaMail.geo-discussion-forums@prap37>
<4ec63f7e$1@newsgate.x-privat.org>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

From: kensi <kensi_kensington@zoonoses.de>
Newsgroups: comp.lang.java.programmer
Subject: Re: toward null-safe cookie cutter Comparators
Date: Thu, 17 Nov 2011 21:21:34 -0500
Organization: SICN
Message-ID: <ja4ffe$h7k$1@speranza.aioe.org>
References: <hkuvb758inpkqmju7aeeln2nab28i0aue6@4ax.com>
<alpine.DEB.2.00.1111131750140.19917@urchin.earth.li>
<onl2c7hnvjaogv8ulhti0ius9hei4ce3mp@4ax.com>
<kudwq.20012$am1.18958@newsfe05.iad> <ja0t5t$kms$1@speranza.aioe.org>
<icWwq.30836$Uw7.17222@newsfe02.iad>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

From: "Derek K. Wodenhouse" <dkw@none.of.your.biz>
Newsgroups: comp.lang.java.programmer
Subject: Re: Standard Design and Development Methodologies
Date: Sat, 19 Nov 2011 23:49:09 -0500
Organization: Occupy rec.arts.tv
Message-ID: <jaa0s6$br$2@speranza.aioe.org>
References: <Xns9FA29593FF4C2jpnasty@94.75.214.39>
<p4_xq.30508$Pm3.8310@newsfe12.iad>
<4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org


...take note of the supportive lead in by <lewbloch@gmail.com>.
"Lew" quit posting from an ISP when that service dropped 
Usenet. Around that same time Derbyshire switched back to
bell.ca., as his ISP of choice, despite his complaints about the service.
The coincidence warrants closer examination as it is classic
Derbyshire behavior to run "Spy V Spy" type roles in newsgroups
where the idiot believes the topic is known to him.

Then there is this;

Date: Sat, 26 Jul 2008 09:50:50 -0400
From: Lew <com.lewscanon@lew>
Organization: the real lewscanon.com
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
Newsgroups: comp.lang.java.programmer
Subject: Re: Missing Lew's posts but not the impostor?
References: <488a067a$0$3154$7836cce5@newsrazor.net>
<g6e9ab$f9o$1@registered.motzarella.org>
In-Reply-To: <g6e9ab$f9o$1@registered.motzarella.org>
Message-ID: <3t2dnVlpatUnthbVnZ2dnUVZ_oadnZ2d@comcast.com>
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 76.114.182.213


Daniele Futtorovic wrote:
> On 25/07/2008 18:59, Daniel Pitts allegedly wrote:
>> I'm seeing a lot of posts by the Fake Lew, and a couple of replies to 
>> apparently the original Lew's post, but it never made it to my news 
>> client.

...as Daniel Pitts is now reading CJLP perhaps a comment is in order
from that source. IS the Lew leading the Derbyshire sock for real, or an
imposter?
?
?
	SPACE MADE FOR CONTRIBUTIONS

__________________________________________________________

Of corse as per usual the OP's topic is yet another Debyshire troll.
Anyone require gill repairs?


From: Novice <novice@example..com>
Newsgroups: comp.lang.java.programmer
Subject: Standard Design and Development Methodologies
Date: Sat, 19 Nov 2011 19:42:07 +0000 (UTC)
Organization: Your Company
Message-ID: <Xns9FA29593FF4C2jpnasty@94.75.214.39>
NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org

From: Just Plain Nasty <jpnasty@nasty.com>
Newsgroups: rec.arts.tv
Subject: Re: William Shatner Warns Of The Dangers Of Turkey Fryers
Date: Fri, 18 Nov 2011 19:56:20 +0000 (UTC)
Organization: Your Company
Message-ID: <Xns9FA197FD4E916jpnasty@94.75.214.39>
References: <ja59al$iu7$2@dont-email.me> <4ec69cdc$1@news.x-privat.org>
NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org

[toc] | [prev] | [next] | [standalone]

#10100

Plonk, spk.

[toc] | [prev] | [next] | [standalone]

#10132

On 20/11/2011 8:54 AM, "spk", an obvious murphy sock, wrote:
NaN> Newsgroups: comp.lang.java.programmer

NaN> ...take note of the supportive lead in by <lewbloch@gmail.com>.

What does your directive to Shanahan have to do with Java, murphy?

NaN> "Lew" quit posting from an ISP when that service dropped
NaN> Usenet.

What does your pontification have to do with Java, murphy?

NaN> Around that same time Derbysh!re switched back to
NaN> bell.ca., as his ISP of choice, despite his complaints
NaN> about the service.

Who is "Derbysh!re", murphy? There is nobody in this newsgroup using 
that alias.

NaN> The coincidence warrants closer examination as it is classic
NaN> Derbysh!re behavior to run "Spy V Spy" type roles in newsgroups
NaN> where the idiot believes the topic is known to him.

Who is "Derbysh!re", murphy? There is nobody in this newsgroup using 
that alias.

NaN> Then there is this;

What do your regurgitations of random news posts' headers have to do 
with Java, murphy?

NaN> ...as Daniel Pitts is now reading CJLP perhaps a comment is in order
NaN> from that source. IS the Lew leading the Derbysh!re sock for real, 
or an
NaN> imposter?

Who is "Derbysh!re", murphy? There is nobody in this newsgroup using 
that alias.

NaN> ?
NaN> ?

What do your question marks have to do with Java, murphy?

NaN> 	SPACE MADE FOR CONTRIBUTIONS

How ironic, considering your utter failure to contribute anything 
worthwhile to this newsgroup, murphy.

NaN> __________________________________________________________

What does that have to do with Java, murphy?

NaN> Of corse as per usual the OP's topic is yet another Debyshire troll.

What is a "Debyshire troll", murphy, and what does it have to do with Java?

NaN> Anyone require gill repairs?

What does your non sequitur question have to do with Java, murphy?

    "I had 'volunteered (years back) to support those who do endeavor
     to provide free Free Usenet access, support those who offered
     subscription based Free Usenet access, nothing more than
     cooperation expected in return for what has been many
     thousands of hours of work. I note most of those I joined with
     are either deceased, severely disabled, or plain ole' MIA..
     now it is my Time. ...

     You just read my last. ...

     For those who think they see me in future times I can only wish
     you severe Tinnitus in your dreams. For those who know me
     well (eMail, whatever) and see me, know I will be smiling also.
     It is to you I say "adieu mein frenz and adios .. grazie' [hugs]
     for all the Good Times! May you and yours always bear well
     with all Life brings you".

     /0ut"
       --murphy

http://www.uffnet.com/kookkamp/goodbye.htm

And some people wonder why I call them Famous Last Words.

P.S. You forgot to include a copy of your trademarked Lits o' Haet, 
murphy. Still suffering from memory problems, murphy?

[toc] | [prev] | [next] | [standalone]

#10095

On 11-11-20 12:13 AM, Lew wrote:
> Arved Sandstrom wrote:
>> Novice wrote:
>>> What are the standard design and development methodologies being used in 
>>> systems departments these days and, ideally, where can I find tutorials for 
>>> them, preferably free and online? 
>>>
>> You could probably do worse than to read
>> http://en.wikipedia.org/wiki/Software_development_methodology. This is
>> of value primarily because it introduces a lot of common terminology.
>>
>> Ultimately _every_ software development methodology (SDM) boils down to:
>>
>> 1. requirements analysis - understanding what the client needs you to do;
>> 2. analysis & design - how you intend to meet those needs. See
>> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
>> we are talking Java, for general concepts;
>> 3. implementation - actually write code;
>> 4. testing - ensuring that your code, as written, satisfies the
>> requirements;
>> 5. maintenance - nurturing the application over its lifespan.
>>
>> How all the various approaches differ is how they break up and sequence
>> these activities. What really matters is that all these activities are
>> important.
> 
> There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published. 
> 
> Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.
> 
[ SNIP good stuff ]

I hesitated to start talking about methods/"methodologies" in my first
post, since it was getting lengthy. Or as you've phrased it, key
features of successful methodologies. However I would agree that an
iterative approach is most suitable for most projects.

In that regard I'd caution the OP that waterfall is still popular and
common, and that a lot of shops advertise that they are iterative+agile
when in fact they are doing more, and smaller, waterfall projects. It's
not quite the same thing.

On the subject of "an individual who maintains the project architecture
and structures in his/her own mind", this often won't correspond to
titles or labels (like "architect"). Another way of looking at it is
that you should have an individual who is the "coordinator", who can
guide and plan the work of the individual domain experts - the developers.

AHS
-- 
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

[toc] | [prev] | [next] | [standalone]

#10104

Lew <lewbloch@gmail.com> wrote in
news:4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19: 

> Arved Sandstrom wrote:
>> Novice wrote:
>>> What are the standard design and development methodologies being
>>> used in 
>  
>>> systems departments these days and, ideally, where can I find
>>> tutorials 
> for 
>>> them, preferably free and online? 
>>> 
>> You could probably do worse than to read
>> http://en.wikipedia.org/wiki/Software_development_methodology. This
>> is of value primarily because it introduces a lot of common
>> terminology. 
>> 
>> Ultimately _every_ software development methodology (SDM) boils down
>> to: 
>> 
>> 1. requirements analysis - understanding what the client needs you to
>> do; 2. analysis & design - how you intend to meet those needs. See
>> http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
>> since we are talking Java, for general concepts;
>> 3. implementation - actually write code;
>> 4. testing - ensuring that your code, as written, satisfies the
>> requirements;
>> 5. maintenance - nurturing the application over its lifespan.
>> 
>> How all the various approaches differ is how they break up and
>> sequence these activities. What really matters is that all these
>> activities are important.
> 
> There's a comprehensive little pamphlet reviewing various software
> development methodologies called /Wicked Problems, Righteous
> Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
> when first published. 
> 
> Its main conclusion, after a very neutral overview of the extant pet
> theories, is that successful methodologies rest on two key features:
> an individual who maintains the project architecture and structures in
> his/her own mind, and iteration. 
> 
> As such an individual (as you should be, too), I have a toolbox of
> ways to look at a programming assignment - a kit of ontologies.  
> 
> First and most fundamental skill - to look it up.  Whatever the
> unfamiliar concept or skill, there is never an expert enough who's
> patient enough with time enough and communication talent enough to
> explain it for you.  You have to be able to do with fragments of
> advice (at best) and what you discover for yourself - through hard,
> hard study and very pragmatic experimentation.  A former mentor of
> mine trained me that any IT person spending less than 20% over and
> above their normal work time to study and practice was doomed to fall
> behind. 
> 
> 'Struth.
> 
> As for ontologies, the most useful ones I know are event-driven
> programming, object-oriented programming, MVC (model-view-controller),
> layers (Law of Demeter), and "noun-and-verb" modeling.  That last is
> my own term for using the language of the problem domain (its nouns
> and verbs) to define your program structures. 
> 
> There's one style trick that induces better code:  Keep it short. 
> After about 500 lines of code and comment (yes, and comment) your
> class should feel too large, and after about 700-800 lines you should
> be castigating yourself.  
> 
> The pressure to keep it short helps you think more clearly about
> structure. 
> 
> And there's one mandatory, cross-methodology practice:  Javadoc the
> shit out of your code.  Document private and package-private methods
> and all static variables down to private.  The extra asterisk at the
> start of the comment block hurts nothing. 
> 
> Don't use specious comments, the kind that repeat what the code
> already says: 
> 
>   for (Foo foo : bunchOfFoos) // operate on each of the Foos
> 
> Pfeh!  If a person doesn't know what a for-each loop is, such a
> comment will not rescue them. 
> 
> Do liberally comment anything that makes a maintainer go, "Hmm."
> 
>   // volatile: thread calling close() might not be same as called
>   perform() private volatile boolean isStopping;
> 
> This advice might not fit your idea of what constitutes a
> "methodology", but for Pete's sake, think.  What does that "ology"
> suffix buy you but buzzword compliance?  The real need is for a
> _method_, a process by which you can produce effective, reliable,
> correct software on time to spec.  In the end it's all about your
> personal commitment and skill. 
> 

Thanks Lew, lots of sound advice in your remarks! I totally agree with 
your distinction between a methodology vs. a method; my original question 
was not ideally worded. 

I'm trying to figure out what kinds of things an interviewer from the 
technical side of the shop - as opposed to HR - is going to expect. I'm 
not sure how open-minded they will be to someone who wants a job but 
doesn't seem to have much prior contact with specific methodologies so I 
was hoping to get a list of the key methodologies. But that was probably 
misguided since I expect they will be relatively open-minded as long as 
you have the main SKILLS of each stage of the development process, even 
if they don't use whatever formal methodology you might know. So, even if 
you've never seen a UML diagram before but have done some other kind of 
diagram that conveys the same basic information, they will accept you 
anyway and recognize that you will be easily able to start doing UML 
instead of whatever you have been doing. Or is all that wishful thinking? 


-- 
Novice

[toc] | [prev] | [next] | [standalone]

#10108

Novice wrote:
> Lew wrote: 
>> There's a comprehensive little pamphlet reviewing various software
>> development methodologies called /Wicked Problems, Righteous
>> Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
>> when first published. 
>> http://www.google.com/search?q=ISBN%20013590126X 
> 
> I'm trying to figure out what kinds of things an interviewer from the 
> technical side of the shop - as opposed to HR - is going to expect. I'm 
> not sure how open-minded they will be to someone who wants a job but 
> doesn't seem to have much prior contact with specific methodologies so I 
> was hoping to get a list of the key methodologies. 

Add Agile to the list in /Wicked Problems.../ and you'll have that list.  Also, is there one on Wikipedia, perhaps, as Arved Sandstrom wrote: 
> You could probably do worse than to read 
> http://en.wikipedia.org/wiki/Software_development_methodology.
>  This is of value primarily because it introduces a lot of common terminology. 
?

-- 
Lew

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web