Slashdot Mirror

I'm trying to grow a wiki for software developers, but it has a long way to go.

Frameworks are just another tool. They're only useless for the smallest of projects. Most web apps need a basic set of features, which any decent framework will easily provide, alleviating the nuisance of having to rebuild that functionality for each project.

Frameworks aren't a good tool for every project. That doesn't make them evil.

I agree. If you're going to volunteer code, then program what you need or enjoy.

Documentation is another area where you can contribute whatever you know best.

Agreed! We need more contributions to documentation.

That would make you a programmer. A software developer is often involved in more than just programming.

I wrote a Wiki page at work describing what (I think) WinSxS's motivation is, how it works and some of the problems it suffers from. I'd like to put it somewhere on the public internet - any suggestions?

Yes, DocForge. I would start by adding a new link or section to the Windows page. Feel free to contact me on my talk page if you'd like any help.

I wrote a Wiki page at work describing what (I think) WinSxS's motivation is, how it works and some of the problems it suffers from. I'd like to put it somewhere on the public internet - any suggestions?

Yes, DocForge. I would start by adding a new link or section to the Windows page. Feel free to contact me on my talk page if you'd like any help.

I wrote a Wiki page at work describing what (I think) WinSxS's motivation is, how it works and some of the problems it suffers from. I'd like to put it somewhere on the public internet - any suggestions?

Yes, DocForge. I would start by adding a new link or section to the Windows page. Feel free to contact me on my talk page if you'd like any help.

This is especially true of web development. To patch a web application you don't even need to transmit a patch to clients; just update the web server. It's so easy to patch that many sites let the public use the code before any testing is done at all.

I spent my first 10 years programming clients and servers for the financial industry. Now, as a web developer, I'm shocked at how hard it is to find programmers who strictly follow best practices.

In a corporation that would be a manager or business analyst. Since you're looking for a job, you can start as a business analyst, helping the business side of a company determine what software should be built and help run the project. At an entry-level position you'd basically help with communication and project management between the IT department and rest of the company.

That's where wikis with a more narrow focus come in. (Warning: plug) DocForge, for example, is focused on software development and allows original research. It's also not an encyclopedia, so notability isn't required and opinions can be posted. Some of the articles have been copied from Wikipedia (with the same open license) and have grown from there.

Or submit the articles to DocForge where original research is allowed. It's focused completely on programming and computer science topics. It hasn't grown large enough yet to breed overzealous editors, either.

I often use this simpler regex to validate e-mail addresses during form validation:

/^[a-z0-9.!#$%&'*+\-\/=?\^_`{|}~]+@[a-z0-9.-]+\.[a-z]{2,4}$/i

I think it is time that we ask both major Presidential candidates to submit code samples. Bonus points will be awarded if they submit the code in Perl, Assembly, or FORTRAN.

I think blub would be most appropriate.

I think the more useful solution is multiple wiki's, each geared towards a more specific category of knowledge, and having the appropriate level of requirements for an entry to be considered valid.

That was exactly my thinking when I launched DocForge. Topics for programmers need to have a lot more information than a source like wikipedia can provide. We use some wikipedia articles as a starting point and expand from there. Sometimes opinions, especially pro / con arguments, are preferred for some articles because they provide much more insight than a flat reference. Plus we can collect subjective things like tips that don't belong on wikipedia.

I think this route of categorical wikis is very useful. But unfortunately, you're correct in that most will remain in the shadow of wikipedia for quite some time.

I think the more useful solution is multiple wiki's, each geared towards a more specific category of knowledge, and having the appropriate level of requirements for an entry to be considered valid.

That was exactly my thinking when I launched DocForge. Topics for programmers need to have a lot more information than a source like wikipedia can provide. We use some wikipedia articles as a starting point and expand from there. Sometimes opinions, especially pro / con arguments, are preferred for some articles because they provide much more insight than a flat reference. Plus we can collect subjective things like tips that don't belong on wikipedia.

I think this route of categorical wikis is very useful. But unfortunately, you're correct in that most will remain in the shadow of wikipedia for quite some time.

The part I have to work on now is making the site much more efficient to the average user (IE faster page generation times, fewer queries, etc)

Here's some performance tips for a starting point. Assuming no major database bottlenecks, be sure to look outside your code for quicker page rendering, starting with gzip compression and tweaking KeepAlive.

As for real load testing the only useful services I've found cost serious money.

The part I have to work on now is making the site much more efficient to the average user (IE faster page generation times, fewer queries, etc)

Here's some performance tips for a starting point. Assuming no major database bottlenecks, be sure to look outside your code for quicker page rendering, starting with gzip compression and tweaking KeepAlive.

As for real load testing the only useful services I've found cost serious money.

...having served as the leader of the Mambo development team during a critical period of its evolution...

The few times I looked into Mambo code it was horrible. Hopefully his Aliro code is much better.

When it comes to CMSs that I'm building myself, I prefer to use a custom or generic framework and build the CMS completely separate on top of that. As mentioned in this review, there is so much functionality that's generic to all web applications, like basic security. So using a solid base it makes more sense to build the CMS functionality separately.

- Listen to your end users. They're the reason you're writing the software. Even when they ask for something stupid, be sure to listen to their needs.

- Listen to other smart developers. Find the smartest experienced guy in your new team, or other similar teams, and pick up tips and feedback. There is a LOT that can easily be learned from other smart people's experiences. Ask questions, but don't be annoying. Following a few bloggers in your field can be helpful if you find the right ones, but an experienced person on your own team would be best.

- Read up on general best practices. Indent your code consistently, write comments, name variables and functions well, etc.

- Think about your code long term. Code is rarely used just once and never looked at again. Write it so it should last and be relatively easy for you to pick up a year later or for someone else to take over.

- Don't box yourself into one line of thinking. If you become religiously attached to one particular language, for example, you'll eventually stagnate. Learn the best traits of a variety of languages and systems. It'll make you a better all-around programmer.

There are other kinds of wikipedia branches. At DocForge we've branched many programming related wikipedia articles and made revisions. But they're not required to stand up to wikipedia's rules of being encyclopedic, fully referenced, or being neutral point of view. So it wouldn't be appropriate for most edits to also go back into wikipedia.

There are some details to Chrome's sandboxing implementation that limit its security benefits:

- The process limit is 20. Anything requiring an additional process once this limit is reached, such as opening another tab, will be assigned randomly to any of the existing 20 processes.

- Frames are run within the same process as the parent window, regardless of domain. Hyperlinking from one frame to another does not change processes.

There are also some problems where valid cross-site JavaScript doesn't work. Of course it's still only a beta. Some specific details are documented by Google.

Well, you can check my site's recent changes to see nothing gets through that contains external links, which are the only anonymous submissions protected with CAPTCHA.

Maybe your site's running some very common software. I have a Drupal site for example, that sometimes hit by bots that are obviously specifically written to attack Drupal sites. Or maybe your CAPTCHA implementations have already been broken, or aren't (pseudo-)random enough.

CAPTCHA is still useful for small to medium sites that aren't specifically targeted. Your average blog, for example, is only hit by random bots that try to get quick and easy posts. Only the largest sites like GMail need to find something better today.

For example, I use reCAPTCHA on DocForge to block the standard wiki spam bots. Since my site's not large enough to be under heavy attack very little gets through. Someday CAPTCHA may be so easy to break that everyone's at risk, but not today.

The complexity is as much in the software as the hardware. I've had some experience with this from the programming side and started a DocForge wiki page.

Why not just add your info to Wikipedia?

Actually, I just looked randomly at docforge's article on hash tables, and I can tell you the Wikipedia one is far more accurate and complete already.

I think the success of the project should be defined by how it achieves its goals (whatever you define those goals to be) and not in whether it kept with its original "spirit".

Wikipedia defines itself as the encyclopedia anyone can edit. Therefore it can't change without redefining itself. That won't happen without angering everyone.

The future is niche wikis. With smaller communities it's easier to keep it open and still watch for vandalism.

Part of the problem is that adding advertising to an existing site usually angers many regulars. And for an open wiki the initial reaction might be, "They're trying to make money of off other people's contributions!"

That's why I made it clear right from the start of DocForge that we plan on using advertising to support the wiki. All revenue will go to paying the bills and eventually anything extra will go to paying editors and writers. We'll also clearly mark advertisements and never have them within article content.

I think it might be too late for Wikipedia to add advertisements. It will hurt their image and they'll lose many contributors.

Oh, man, I gotta go blog about this right now!!!