Any wiki suggestions?
Mar. 16th, 2008 01:34 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Time for the next bit of tech for work: I'm looking for a good wiki. CommYou probably needs a couple of wikis -- one on the internal development server on "how you build this thing", and one on the soon-to-be public server for documentation. (I'm leaning towards a wiki for my documentation, since it allows me to open it up to trusted members of the community to help out. In general, one thing I think LJ's done right is getting the community involved.)
Anyway, there are about six million wiki platforms out there, so I'm curious whether my friends have any suggestions of good ones. My needs include:
Opinions? Eventually I'll probably switch over to using Querki, but I really can't afford the month needed to get that project bootstrapped right now...
Anyway, there are about six million wiki platforms out there, so I'm curious whether my friends have any suggestions of good ones. My needs include:
- I'm more interested in ease of maintenance than most other features: I'd like something that's fairly easy to get configured up and running.
- I don't think I need massive power and complexity -- my needs are pretty straightforward. Some straightforward way to include images would be Very Useful, though. (This is an aspect that many wikis fall down on.)
- It needs to be stylable, but that mostly means that I should be able to apply CSS easily.
- I lean slightly towards something based on JVM/MySQL, since those will certainly be installed and working on the servers, but I'm open to Perl/PHP/whatever, so long as it's a common platform.
- Decent access control is utterly crucial, so I can open editing up to specific members of the community while keeping admin privs locked down. This is *not* going to be editable by the general public, so some kind of group management would be helpful.
- The ability to shove all the wiki framing out of the way would be Very Nice: for purposes of the average reader, I'd prefer that it look a bit more like a conventional web page.
Opinions? Eventually I'll probably switch over to using Querki, but I really can't afford the month needed to get that project bootstrapped right now...
(no subject)
Date: 2008-03-17 01:10 am (UTC)I wouldn't actually *recommend* Java at this point, mind. It was a good language in its day, but it stopped being cutting-edge about ten years ago, when "object oriented" stopped being new and cool. Java has become an irritatingly stodgy language, with the result that it's been thoroughly lapped by C#. (Which is by no means perfect, but is at least making a credible effort to keep up with the times.) Java is the great bastion of object-orientedness as a religion, with the result that it has pretty much completely missed the functional revolution. (Much less the declarative/pattern-based one that's gradually coming down the pike.)
But the JVM is another story. That's just a platform, and it's a fairly decent one -- perhaps not quite as good as the CLR, but good enough for most purposes. And there are *lots* of languages on it, some of them just fine. For example, I'm likely to move my active development over to Groovy pretty soon: that looks to be a reasonably modern and sensible language. I mean, it's not that Java is a *bad* language, it's just missing a bunch of important features -- Groovy appears to add those in. The nice thing about the JVM is it has a colossal installed base and a huge number of libraries; pretty much all of those languages can use pretty much all of those libraries. That's why I chose it as the basis for CommYou: I can have my library cake and eat the languages I want.
So I can understand the viewpoint, but I'd caution you to remember to keep the tool and its users separate. It is entirely possible to use it to produce good code -- it's just a bit more effort than it should be. The fact that it has become one of the entry-level languages just demonstrates how much staying power it has developed, and that staying power is almost always because it provides the junior engineers with enough capability to get their work done. That's not a bad thing, per se, so long as you don't let it limit you...