The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
From: Bryan Bishop <kanz...@gmail.com>
Date: Sun, 23 Sep 2012 12:19:06 -0500
Local: Sun, Sep 23 2012 1:19 pm
Subject: Re: Thingiverse, et al.
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 logic. > may eventually result in a software fork. But in the absence of a
Are 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 sites? > 0) A channel for news, announcements, and project updates, with
Having 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 allows
I agree mailing lists are nice things.
> 2) Open Discussion Forums. For support and user discussion
What is the difference to a mailing list?
> 3) A wiki-ish repository of information. I imagine each project
How 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 wiki
Most 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 not
Wordpress 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 a
That'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. For
These 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 schematics
I 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 automated
That doesn't mean you shouldn't do it anyway.
> nightly builds to see if something broke a dependency. - Bryan
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.
| |||||||||||||