As I understand the process, here's how to design a new application:
- Decide what the general purpose of the application will be.
- Decide in a general sense what "use cases" you want to support.
- Decide what persistent datastore, and what algorithms, will be
needed to implement those "use cases". For RDBS applications,
the persistent datastore consists of tables in a RDBS, so at
this point you define the table layouts and relationships, at
least for the minimal/essential use cases. (UML diagrams are
nice for this task, but neither necessary nor sufficient.)
- Write code for the critical algorithms that you don't know 100%
for sure will be feasible. Get them out of the way early so that
you won't have to worry that down the line you'll discover your
whole application can't be finished because of a "show-stapper"
and all your work to that point has been wasted.
- Plan an overall implementation schedule, the essential components
first, then the extra optional features later after you have
some customers asking for them.
- Now start filling in the details of the design as you write code
to implement the minimal working system first, then when that's
working you simultaneously try to attract beta testers and add
code to implement more features.
Note that http://TinyURL.Com/NewEco is at the stage of having a
working minimal system already and now coding additional features
while trying to attract beta testers for what's already up&running.
If you see something wrong with what I said there, don't just say
"it's all wrong", but show how smart you are by offering your
alternative idea of how a new Web-serverside software application
should be developed from concept to production.
<snip lots of bullshit>
Understanding the process and being able to do it are two entirely
different things.
You may be able to quote (or paraphrase) from a book. But you obviously
have no idea how to create a design.
And no, I am not going to donate my time to you. I am not your sucker.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstu...@attglobal.net
==================
Well that's exactly what I've been doing. For example, consider the
new surveys/polls feature of NewEco, where I first conceived the
basic idea and posted in http://TinyURL.Com/NewEco, and then about
a week ago I moved the text into http://TinyURL.Com/EcoSur and
began fleshing out the design more and more and then began
implementing it. If you can't see the parallel between my general
understanding of the process (two articles ago in this thread) and
what I actually do (listed in EcoSur on an almost daily basis),
then perhaps you can explain what is non-parallel between the two.
> You may be able to quote (or paraphrase) from a book.
No, actually I composed those steps in software development out of
my own mind, based on what I've actually been doing, after many
years experience doing sorta that but refining the methodology and
better understanding the overall methodology in recent
years/months. I don't recall *ever* seeing any book that listed the
step even remotely like I described them. Standard software
programming classes at De Anza College, starting with C, teach a
*different* set of steps, emphasizing detailed subroutine call-tree
diagrams before the first line of code is written, which I find
*not* the best way to develop new kinds of software, although
possibly slightly useful when trying to solve elementary homework
exercises in such beginner classes.
> But you obviously have no idea how to create a design.
What I created in http://TinyURL.Com/NewEco for the overall system
and general implementation plan, and what I created in
http://TinyURL.Com/EcoSur for this one new feature (surveys/polls),
sure looks to me like two designs, one being a small detailed part
of the other overall general plan. What part of that don't you get?
You really are in sad shape. Not only are you incapable of competent
designs (as evidences by multiple of your updates), you are incapable of
understanding that your skills are lacking. I've tried to explain, but
your ability to comprehend is also sorely lacking.
The bottom line is - your "design" sucks, will be difficult to implement
and almost impossible to maintain.
I can see why you haven't been able to get a job for 20 years. I don't
know of anyone who would want someone with your attitude, either.
So far I'm not having any problem implementing my design. Several
times I had a difficult decision working out the details of parts
of the design itself, and was hoping others would brainstorm with
me, but nobody ever offered help with the design, so I figured it
out myself, and then as soon as I had the design decision clear in
my mind the actual PHP/MySQL coding was almost trivial to grind
out. PHP really is an easy language to program, not as easy as
Lisp, but easier than Java. The languages themselves are pretty
much interchangeable for these kinds of applications. The
difference in ease is that Lisp has Read-Eval-Print loop where I
can type a new line of code in context of what came before and
immediately verify both syntax and semantics, whereas with PHP I
need to type the code blindly then save edit to disk then start up
FTP and upload the edited file to server then switch to Web browser
and re-load Web page before I can see if I even got the syntax
right much less the semantics, and with Java it's an hour of OOP
crap before I can even try the first line of code in a new class.
So if I have a really bad design that makes you believe it'd be
really hard to implement code, but in fact I have no trouble
coding my design, then my PHP/MySQL coding skills must be an order
of magnitude better than yours.
More likely, you're just flat-out wrong about my design being so
bad it can't easily be implemented. My design is rather easy to
implement if done in an incremental fashion, code one part at a
time, don't try to write the whole application in one sitting, get
just one or two new use cases implemented and debugged per workday.
By the way, I'm thinking of maybe implementing an add-on for
Twitter that will track threads both forward and backward in time.
Backward is easy. Forward is where the design-fun begins. I'm not
going to challenge you to guess my proposed algorithm, because I
already tweeted the answer earlier tonight.
<another huge amount of similar bullshit snipped>
Gee, I wonder why no one volunteered? Skip that - I already know.
And what's taking you so long? Someone who really knew what they were
doing would have this done in a couple of weeks max. There's nothing
complicated about it.