[svlug] moin moin vs wiki

[Chris Miller]

On 12/29/06, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Chris Miller (lordsauronthegreat at gmail.com):
> > If there's already a lot of work done in MoinMoin, I'm not going to
> > start making my own solution.  If I start to help, it'll be on the
> > MoinMoin approach.
>
> Well, there's a hundred-some hand-ported pages in the prototype at
> http://gemini.starshine.org/SVLUG/ , i.e., 90%+ of the site has been
> reimplemented in Moin.  I did almost all of that personally despite
> having zero acquaintance with the markup language at the time, just to
> get some momentum behind something actually _happening_.  Because
> nothing _was_, until this past March.
>
> (I mentioned that the project was "launched" two years ago -- but that
> refers only to our administration's decision that they wanted a wiki
> transition to happen.  Nothing actually _occurred_ until Heather offered
> development space and created two pages, followed by my creating the
> others.)
>
> The current and perhaps sole significant hurdle, at the moment, was that
> I hit a roadblock in trying to get MoinMoin running as a FastCGI
> back-end process on our Linode virthost, IP 64.62.190.98.  LightTPD
> (correct spelling; this time for sure!) is running and theoretically
> (not tested) ready and willing to talk to that back-end.
>
> You feel like tackling that?  It might be simple, and I just haven't
> gotten back to it.  Please let us know on volunteers at lists.svlug.org, if
> so.

I know nothing at all about CGI, so I'd probably break something right
off the bat.

> A number of other basic service configuration things are needed on both
> that and our other development server, over at Via.net (IP 157.22.20.228),
> but that plus copying the data over and doing a "flag day" probably
> aren't a lot of work.
>
> > PHP is an extremely dynamic language.
>
> But bloody unlikely to help make a project "smaller" in any meaningful
> sense (and I hope you didn't mean just lines of your own code).  Thus my
> point.

I try to use the object-oriented features as much as possible to make
the whole thing more streamlined.  If everything goes according to
plan, when I finally get a job I'll be a professional programmer, so
my whole job is about making all things "code" work.

> > I think the project fiascos you're familiar with are generated by a
> > genuine phobia of hard work (ie. actual coding, not making pretty UML
> > diagrams).
>
> Actually, more just the long-term lessons of project management.
> Significant software projects take time, and results are uncertain.
> (Fred Brooks is my Jedi, mon.)

It's always difficult to begin a project from a coding point of view,
but making a pretty UML diagram is the worst possible thing you could
do.  UML and flowcharts look real pretty, but they are more often than
not the exact opposite of what you will need.  The only way to get a
project started is to actually make a main.cpp and start working.
Generate any diagrams and stuff as you go, but don't get stuck to some
cursed "master plan" that 6 months later turns out to be a horribly
misguided design which is actually unimplementable.  I've built some
pretty dang pretty diagrams, then I'll come to the keyboard and an
hour later the flowchart is in the trash.  I spent more time thinking
about it on paper to get it wrong to spend less time coding it and
getting it wrong and then make a few changes to get it right.

A very good and extremely wise programmer friend of mine once said
something to the effect (I think the email got accidentally filed in
/dev/null) "Quit with the stupid UML crap and go code!"  My own
experiences seem to confirm this, so for now I'm accepting it.

-- 
==  ==  ==  Ƒ 5 |) 3 |/  ==  ==  ==
==    ( 0 |) 3    \|/ 4 |2 |2 | 0 |2    ==
==  ==  7 | |\| µ Ж    6 µ |2 µ  ==  ==