On Sun, Sep 23, 2012 at 12:04 PM, Ray Dillinger wrote:Okay. Wordpress is notorious in the web development community for its
> On 09/22/2012 05:45 PM, Bryan Bishop wrote:
> > On Sat, Sep 22, 2012 at 6:59 PM, Ray Dillinger wrote:
> >> Please mention a specific reason for your objection. I might
> >> agree heartily with you, if only I knew what the problems were.
> > Are you a programmer? Let me know what level I need to explain this
> C and C++ and various LISPS and shell scripting languages, but haven't
security blunders. Additionally, the architecture doesn't promote good
application programming practices. People try to shoehorn it into each
situation even when it doesn't really make sense, especially through
the theme and plugin APIs that mix content, presentation, and business
> may eventually result in a software fork. But in the absence of aAre you judging "better" just by the sheer number of bloggers that use
> better alternative, I don't see a reason to not start with the
> available software off the shelf.
wordpress, versus the <500 people who run git-backed hardware hosting
> 0) A channel for news, announcements, and project updates, withHaving a place to post RSS isn't a big issue these days. If you were
> backchannels for discussion-of and feedback-to. This is the
> role I'd been considering WordPress a good fit for. Each
to release a website with just this feature, it wouldn't have much of
anything to do with hardware.. just saying. Wordpress can definitely
do RSS, but so can a million other things. RSS isn't going to enable
more hardware, it's just a nice-to-have on a website, and it
definitely makes sense, but not as a central focus.
> 1) Mailing lists with webby archives, and a web-form that allowsI agree mailing lists are nice things.
> 2) Open Discussion Forums. For support and user discussionWhat is the difference to a mailing list?
> 3) A wiki-ish repository of information. I imagine each projectHow about just put the wiki in a repository, like all the other sane
version-controlled wikis? ikiwiki comes to mind, but github wiki pages
are also in a repository. Or, erm, at least, bitbucket's wikis are.
> control was more naturally (and more easily) tied to a wikiMost wikis are insane like that. I don't recommend mediawiki because
> than to a discussion forum or announcement channel anyway,
> which is why I'm not too concerned about integrating WP with
> git. Wikis have their own revision control built-in, so
of it. For example, diyhpl.us/wiki is a git-backed wiki if you want to
play around with that.
> 4) Revision control -- git is certainly a lead contender but notWordpress doesn't offer that.
> the only contender.
> 5) Bug database -- needs to be integrated with source control,Why not use github issues? (Actually, a few years ago I would have
> wiki, and mailing lists, but also have its own face. This is
> probably the most challenging part of the web design.
recommended bugseverywhere, except development stopped, and for some
reason nobody other than me cares about tracking issues inside your
version control repository.)
> The problem with that approach is "lock-in"; if you change aThat's not a problem because of server-side URL rewriting. Just make
> component, all the extant URLs that point at pages generated
> by that component no longer work, because the new component
> is unlikely to generate the same set of URLs. Sometimes,
sure you document the before/after URLs when you are making big
changes. But your users will hate you if they have to memorize a new
set of URLs or URL formats. (Google Groups, I'm looking at you.)
> I favor the straightforward and simple; "serial ID tags"I disagree with this approach strongly because it makes it harder for
> for every chunk of content (or at least every URL target) on
> the whole site. Every single update to anything would get
> a unique serial number from a central counter, and these
me to memorize URLs.
> These we would use to build redirection tables. ForThese are trivial issues solved by modern web frameworks. You
> every URL, we'd record the serial number of the document
> it points to. Then when a new component takes over some
> role, after all the "content migration" that doesn't respect
> any integration with other components, we can find the URLs
shouldn't be concerned with this _at all_.
> There's a QA problem with build plans and schematicsI have some code in http://diyhpl.us/cgit/skdb or
> that's familiar from cookbooks, but which we don't see with
> conventional computer software. Finding out whether a build
> plan or recipe actually works can't easily be automated.
https://github.com/kanzure/skdb in that direction, but I agree it
remains largely unsolved.
> You can't easily write a test suite, nor do automatedThat doesn't mean you shouldn't do it anyway.
> nightly builds to see if something broke a dependency.
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.