1. Yes, for Gold members definitely
2. Under what circumstances? Same as the article 'throw to the community' idea? As in: if someone posts a poor question or a bad answer then we allow the community to edit and correct it?
2. Under what circumstances? Same as the article 'throw to the community' idea? As in: if someone posts a poor question or a bad answer then we allow the community to edit and correct it?
Well... No, i don't think that would work, at least not as the forums currently operate. Chances are, by the time any post worth saving has been thoroughly down-voted, it'll be out of sight - an edited question would merely be ignored, and anyone looking to edit an answer would have simply posted their own, corrected answer.
I'm tempted to say "any post can be edited by any (sufficiently privileged) user at any time"... this appeals to my desire to correct typos and remove grocer's apostrophe's, as well as my bright-eyed-optimist's notion that the vast majority of CPians would use it for good (or... just possibly... a rascally desire to abuse it in The Soapbox). I can think of a couple of compromises though:
Yet Another Voting Option: vote-to-edit. After a sufficient number of "edit" votes, a post would enter "Mob Mode" - sig and username would disappear, anyone can edit for any reason at any time. I don't really care for this option much, as to be useful it would require Roving Bands of Good Samaritans trudging through the forums voting on, then cleaning up, poorly-phrased questions (and again, the barrier to entry is higher for editing an existing answer than just posting a new one, so why not just post a new one). A history + rollback feature would be pretty much essential to avoiding drive-by vandalism here.
Assist-mode: any (sufficiently-privileged) user can edit any post at any time... After which, their name is listed next to the original authors (ex: Re: Content Collaboration upgrades :bob:Chris Maunder (assisted by Shog9)
). A short history + rollback feature would be nice here just to get an idea of what editors were actually up to, but not absolutely necessary.
Semi-OT question for you: is there a way of keeping track of posts that move? So if i'm replying to a post in Web Dev and it gets moved to ASP.NET, my reply would follow it once i get around to actually submitting the forum? And... permalinks to a post in one forum would actually still be permanent in that they'd automatically take me to the post's new home?
These facts that you've laid out totally contradict the wild ramblings that I pulled off the back of cornflakes packets.
is there a way of keeping track of posts that move? So if i'm replying to a post in Web Dev and it gets moved to ASP.NET, my reply would follow it once i get around to actually submitting the forum? And... permalinks to a post in one forum would actually still be permanent in that they'd automatically take me to the post's new home?
I think the short answer is "yes". I will check though
Again most of the updates in the latest upgrade to the system (though I keep thinking of it as "The System") involves behind the scenes stuff that most of you will never notice or use but which will ensure everything stays working and doesn't go bump in the night.
Though we are now reporting the number of times an article is bookmarked. I know - we're getting a little crazy. We also moved the SQL category from the main C++/.NET site to a sub-site of its own because with over 1,800 database related articles we felt it was time.
Besides that we're still hard at work on:
- A new form of content. We'll it's a very old form with a new spin for us
- Our advertising system. Hey - it pays the bills and we want to ensure it's relevant to you guys
- A new service for the community
- More tweaks to the Job Board
- Lots and lots of work on performance and stability
- A lot of internal introspection as we re-question our basic architecture and design philosophy to ensure we're not doing anything obviously dumb.
First off, I wanted to thank you once again for help with article publishing.
On the topic of changes being done on CodeProject, I wonder what is being done about the rating system.
Rating system on CodeProject is the only thing that annoys me and many other publishers, because it is so biased, counterfeited and mainly not in any way objective.
I won't mention my articles this time, but as I browse through the fresh articles by other people I way too often wonder what is going on with the rating when a good article is getting 1 for it. Most importantly, the rating of 1 is given not in tandem with the general opinion, but way against it, which means that normally you won't see 2 and rarely 3 points for the article (mostly 5 and 4), but then some people seem to just love giving 1 to articles. Needless to mention, this is a hit in the balls for the author.
If CodeProject is to be taken more seriously and prosper further, you guys must reconsider the rating system altogether.
These are the tips of what a good rating system is:
A proper rating system will not allow giving an article a rating below average without providing a text explanation as to why the author thinks the article deserves the bad rating.
Rating of any article must provide access to details about all the CodeProject accounts that gave the rating, so people see who gives a particular rating.
A statement should be made visible, saying that if you think the article deserves rating below the current average (or just bad rating), try to contact the publisher before giving your rating.
And a publisher must have the right and the way to enquire about a ridiculous rating to be reviewed, once the article's popularity reaches a certain level.
Items 1 and 3 are as done by EBay, for instance, while items 2 and 4 are essential for CodeProject.
I really hope that you guys make some changes there, for I do like publishing here and reading the website, I just want you to grow in the right direction and to be able to attract more talents who might also be very upset about CodeProject rating as it is today.
We (as a community) have discussed the rating system for many years and here's what the consensus boils down to:
1. It requires time to effectively provide a representative rating for an article. Statistically there will always be those who vote it up or down, but eventually the weight of legitimate votes will outwiegh spurious votes.
2. Forcing a comment with each vote will result in lots of "asdf" comments. You can't force someone to comment - you can only encourage
3. Exposing the identities of those who vote will lead to retaliatory voting
Item 3 in your list isn't applicable to CodeProject because where eBay is a 1:1 relationship per item, CodeProject is a 1 to many relationship so I'm not sure the "contact the author before voting" will work in the same instance (ie you're not trying to work out why a business transaction went wrong - you are just voting on how well you like an article)
I don't see how 4 will work given my point 3 above
Having analyzed what you just said, I see how it can be improved avoiding all these problems:
Only when someone wants to give a vote below the current average he must provide a textual explanation that will be visible to the Article’s author. If such voter puts abra-cadabra into the comment, the Article Author once he saw it can mark it as “Invalid Vote, Staff Attention Required”. Somebody from CodeProject will review such votes, and if seen justified, the voter will lose a point for this and get a warning via email or something, while the vote will be removed.
One of the hardest things to do in software development is know when enough is enough. You can write code by looking at your immediate needs and then, every 5 minutes when you realise you need something else, extend the code. This produces wonderful spaghetti code. Or you can sit down and walk through all your possible scenarios that your code will ever need to deal with and design it to be infinitely flexible.
The correct approach is somewhere in between these two extremes: design it so that it covers all your business needs plus the future business needs to the extent to which you can predict, while ensuring, as opportunties present themselves, that you write your code flexibilty and generically enough so that if something unforeseen does come along it's not overly painful to adjust.
We have been working quite extensively on another feature that we've been looking to do for ever and have come up on this classic problem of where to stop designing and where to start coding. Fortunately our work has been made sigificantly easier by a design decision we made 2 years ago: Everything will be modular, everything will be database driven, and every item that we need to store and reference will be referred to by two simple IDs: its type ID and its unique ID within the set of objects within that type.
If we wish to add rating to a new object (say, a Widget) then we merely need to define a type ID for the Widget type, and then all widgets will have their own ID starting from 1. The rating module doesn't care if it's attaching ratings to Widgets or Gadgets or whatever. It just wants to know what object ID and Type ID it's storing a rating for and will do it. The same goes for forums, for bookmarks, for watches - for everything.
It was a simple and fairly trivial decision to make right at the beginning and, when we had almost no code written seemed overkill ("why not just have Article_Bookmark link tables?" "Why not store the rating row ID within the Article table?") but by abstracting out the entire notion of objects in our system and always working on the principle of "You do not, and should not, need to know any specifics about the object you are dealing with" it's meant that creating and plugging in new modules is seamless.
It's not so much that we're bored, but releases of new products and new technologies is quite common place now.
Way back in the year of the flood when I was given my first coding assignment I was handed a Dos 2.0 manual. No instructions. Just an alphabetical listing of Dos Commands. These were the days when the superintedent of your building was also a sysop for AOL and BBS's was the communication medium of the day.
Heck I remember when HyperLinks and WYSIWYG were hot new technologies!! These were the days when getting a 40MB (Yes, MEGAbyte) disk meant you had to partion it into two smaller disks because we were still waiting for Dos 4.0 to break the 32Megabyte barrier. Today, my father-in-law carries pen drive that's got 4 times the storage capacity of the Wang computers (Remember Wang?) I used to backup everynight.
We're not bored. It's just that the west has been discovered and has been settled. We've had our gold rush (dot coms) and now we're settling in and building a whole new civilation.
Remember, there was a time when only geeks (remember when geek was a bad thing?) new who Bill Gates was.
We've come a long way, and it may be some time before a new discovery is made that fundamentally challenges what we know computing to be. Anyone see my 5.25" floppy?
For the past few weeks we've been concentrating on tweaking the current additions such as the Job Board, the bookmark/watch system, and the My CodeProject page. We've also been spending a ton of time on cleaning up small bugs that have backlogged, a few wish-list items that fell neatly into what we are currently working on, and a bunch of boring admin stuff that's actually kinda cool for us, but a non-event for you guys.
We've also started on two new big projects, one of which will be a general service to the IT community, and the other will be something that is incredibly complicated, big, powerful, time consuming, and probably frustrating to build yet none of you will probably notice any difference at all (at least that's the plan). Deep down, though, we'll all be happier.
While we still have a few obvious bugs outstanding we've had to balance the number of members affected by them, and the effect on those members, against the number of members who will benefit from us improving other areas. It's always a juggle but going on emails it seems we're close to finding that balance.
So: not a huge amount to say except that you should know that deep in the bowels of The Code Project there's a lot of stuff going on. Every few days you see something pop out of this, and we're hoping to continue that trend for a while.
We've had the ability to bookmark articles for ages, and recently added the ability to bookmark other items such as forums and member profile pages. We then added the ability to Watch an item, which means it gets bookmarked and will appear in the Watch windows in your My CodeProject[^] page.
We've now extended this to allow you to publicly recommend your bookmarks so that others viewing your profile will see which items (articles, forums, forum posts etc) you like the best.
Maybe useful, maybe just an interesting but of trivia about those of you you hang out wiht on the site. Enjoy anyway!
The latest update today is mainly concerned with stability and with enhancements to the Job Board and Message system.
Our error tracking reporting system has been much improved but our error rate has declined to the point where we don't actually get to use it that much. The delicious irony. Most of the errors we do see are the occasional null ref error, a view state error or an internal value check error that goes along the lines of "OMG!! The value was less than 0!!1!" which we ignore because the system will handle this correctly anyway, and the cause of such values is usually a malformed URL.
2. Job Board.
More tweaks to the layout, to features, and to the explanations of things like Coupons. Lots of additions to admin on the backend, which is probably of no interest to anyone reading this, but it certainly makes our life easier.
3. Message Boards
The drop-down menus are now more sensible but I've still yet to fix up the message board listings in the pages themselves. At the moment they are a little random.
The other big change, apart from a little optimisation and stability, are the big buttons that allow you to say that an answer to your question was helpful. The reason for this will be clear as soon as we have completed one last piece of the puzzle. The puzzle being "Why is SQL using an index scan instead of an index seek when it's happy to use the index seek when the query is executed directly but not when the query is inside a stored procedure".
Oh yes, our dinner parties are full of crazy exciting talk.
One of the hardest things to do when developing software is to look at your creation from with the eyes of a newcomer. Does it make sense? Is it overwhelming? Can I work out how to use it? Can I find stuff?
I had one of those moments a while ago while creating a Press Release[^] and realised that it was difficult to track the growing number of features we're adding to The Code Project. As an author you want to have access to your list of articles. As a user looking for answers to questions you want to keep track of the messages you have posted. As a company posting a Company Profile[^], and maybe a press release you want to keep track of these, and as an advertiser you want to get access to the latest stats on your ads.
So My CodeProject [^]was born. A single page that lists those items that relate directly to you. Forums, articles and authors you want to watch; your company listings and press releases, links to your messages and your articles, and a ton more to come.
The page itself auto-refreshes by default every 15 mins (though you can change this easily enough) and will stop refreshing when it stops seeing mouse movements on the page. There's no point in refreshing a page if no one is there to watch it.
The next step will be more information on forum participation, then a few bits and peices based on a new service we'll be rolling out soon. Obviously more customisation and personalisation is a must, but we're always open for suggestions and would love to hear what you'd like to see on that page.
One of the things we've been focussing on is storing and displaying more information on what's been going on around the site. Page views, voting history and downloads are 3 major areas we've been working on and as a test we're now exposing page view graphs for members who are gold and above. All they need to do is visit their articles and scroll to the bottom to get a technicolour (well, orange and gray) view of just how popular they are.
Maybe it's useful, maybe it isn't, but it doesn't hurt to give these things a shot.
I've had a couple of questions about the membership level system and why levels have changed.
First we had the 'Woohoo! Platinum!' bug which, we're sorry to say, we had to fix. Actually it was a member-wide bug that gave everyone, for a few, happy days, 1 level higher than they were.
Then we made another change which sent a lot of Gold members back to Silver. We did this because we needed a way to reward members for participation and not just for being a member a long time. The issue we face is that we are trying to hand off more and more of the policing around CodeProject to the community so we need a reasonably large group of members who are active and whom we can trust to act responsibly. We thought that Gold members would be perfect for this but we found there were a lot of gold level members who were gold merely because they'd signed up a couple of years ago and were misusing the trust we'd placed in them.
We rejigged the system so that Gold required participation and it's since worked out really well.
Overall I feel it was the correct thing to do because the member level system should not be simply a reward for not wandering off into the sunset. It should be recognition of participation.
We've made a bunch of changes, some useful, some mere eye candy that actually just lessen the load on the servers (think Ajax), and some you will not even be aware of.
Here's a quick rundown of what's been going on in the last week or so:
The vote histogram (old news, but something I've wanted forever)
Ajax voting on articles
Ability to delete/rename files associated with your articles
The simplified question/answer voting in the forums. We'll be extending this in the next couple of weeks
Replicated database servers. Replicated with our own special sauce, though, so there isn't the usual lag problem that replicated database servers have. Added to this is database monitoring tied directly into the webservers. Speed, redundancy and automatic failover. All I can say is woot.
The usual quick fixes left, right and centre.
The new sites! Having the ability to partition out our data into new sites was a design goal of the rewrite and we can now have a sub-site up and running in minutes. We want to expand our offerings but we want developers to feel they have a home of their own.
Tables of Contents now have a simple article filter. Just start typing and articles that don't match the text will be removed from the listing. Still a few improvements to do on this.
The article moderation system. This seems to be serving its purpose nicely but the side effects (highlighting the bad articles) has been an interesting learning experience.
The biggest problem with a site that churns out an enormous amount of data is in ensuring that a user finds exactly the information they need. There are a number of ways in which this can be done:
1. A good search engine tuned to the needs of your users
The standard SQL Server full text search does not handle "C++" very well so care must be taken to ensure that you do some magic to handle specific cases like this. Further, providing ways to specifically limit searches (eg filter by attributes) will mean that search results are filtered, and not merely ordered by, the attributes of the content the user is after.
2. A well planned Taxonomy and guidance trails
Breaking the content up into Chapters, sections and subsections that make sense and will allow the majority of users to intuitively find the material they are after is not as important as a good search engine (Google has trained us well) but is important once similar content to the target content has been found. Provide the means to trace back up a level (or more) so the user can then find material near the material they may have stumbled upon
3. Provide the means for your users to promote material
While ratings and reviews are inherently subjective and open to abuse they are invaluable in allowing a user to determine within an order of magnitude of confidence which of the 10 results they are looking at they should investigate first. One developer's gem could be another developer's "Not Another Article On..." cry of frustration. It really depends on which article the developer found first, and in this respect ratings are even more subjective in that they are not only audience-dependant but also time dependant. Two articles on the same topic immediately one after the other will have a very different voting pattern to the two articles posted months apart.
The way in which a rating is displayed is extremely important as well. A straight number doesn't mean anything. A number that relates to the number of times an article has been rated, as well as it's actual rating provide more feel for what the general populace feels, and a rating that provides information on the distribution of the ratings provides yet more information, since ratings well outside a standard deviation show up and can be mentally discarded by the reader.
Guiding the way in which your readers vote will allow you to use the rating values more effectively. Previously we used the "Vote 1 to 5" method for all posts indiscriminately but we've not moved to a "Good Question/Bad Question", "Useful Answer / Unhelpful Answer" options that makes it clear as to the feedback we are after.
4. Feed the data back into the system
Once you have a good search engine and taxonomy you need to feedback the work your readers have done into your system. Our search results are based not just on keyword relevance but on the popularity of an article, and at the bottom of each article we provide lists of similar top rated articles. Our Good Question / Bad Question system will (hopefully) train members to either form their questions better, or ignore questions that are posed by those unwilling to show any initiative themselves. We can then ensure that the better-posed questions will get more of the attention of members looking to help out.
One thing I've been trying to find the time to do is write up this whole rewrite thing we've been doing. Unfortunately we've all been doing silly hours with our little trial by fire but I do need to get the ball rolling:
some whacky and amusing things we found:
- SQL Server, IIS and the ASP.NET framework are possessed.
- Using development settings instead of production settings is a Bad Thing.
- Storing session state in a SQL database can be a performance killer. Especially when the database is an old P4 test harness machine 40 km away from the webserver. That was an interesting experience in scream therapy.
- Always check your indexes. Especially the ones that absolutely positively are not and cannot be fragmented. They will be the ones most in need of attention.
- 20,000 users hitting your application is wonderful load testing. We did load test but our testing machines did not generate the load you guys can generate
- no matter how many ways you check code there's always an angle that you haven't looked at. We're finding errors in 10 mins of being on that we couldn't find from 3 months of beta testing. This is just nature.
- Do not take error message reported by the .NET framework at face value. For instance: a SQL command timeout can actually be caused by a web server timeout. Strange but true and it caused us no end of frustration
CodeProject.com : C++ MVP
Last Visit: 15-Dec-19 6:08 Last Update: 15-Dec-19 6:08