views:

179

answers:

8

Hi,

For our Intro to Web Development class, my team (4 students in total) was thinking of building a site like stackoverflow for our term project. What we envision is that everyone in our CS program including students from higher levels can have a common place to communicate and help each other.

I know that this sounds really big but we're going to make it as simple as possible. We talked about the requirements and these are

  • Login/User Authentication
  • Posting capabilities
  • User Registration
  • Some sort of a upvote/downvote system
  • rep system

What we're allowed to use is XHTML, CSS, Javascript, PHP and MySQL for the database.

I would like to ask if this seems feasible for the ~3 months that we have and if the technologies that we're allowed to use can be used to fulfill the requirements effectively (I'm specifically worried about the upvote/downvote and the overall rep system).

Thank you.

+1  A: 

XHTML, CSS, Javascript, PHP and MySQL are suitable to make a light version of this site (that you mentioned). In fact, you could create Stack Overflow as is with them. The old cases in the wild prove my point: Wikipedia, Facebook (front end at least), Digg, Yahoo, etc etc

alex
The hardest part is figuring out the schemas and how you are going to organize everything. If you had all of that planned out, it would take like 2 weeks to implement.
Chacha102
@Cacha102 I agree with you completely. I got the hang of them from experience. My first sites may have *worked* but had terribly confusing database schemas and code.
alex
A: 

"allowed"?

You'll end up with the best product (um, least unfinished product) if you can outsource as much low level stuff as possible to a library or platform. For instance, using google app engine means you can use python/django, and it takes care of registration/secure authentication for you via google credentials.

Dustin Getz
Considering it's a class on web development, I'm sure the instructors intent is to limit their reliance on outside code.
Chris
In addition to what Chris said, yes, unfortunately, "allowed." We can't really use available engines or systems especially not for the core requirements that we have.
Micheal Deer
+5  A: 

Sure, what you describe is fairly trivial. I would suggest, though, that you'll end up making it more complicated than you describe, and that's where you'll probably go wrong.

I suggest you spec out a very simple system (like you've written) and stick to it. Make sure it all works, and if possible has a nice build/testing environment, then add things once the baseline is done.

Noon Silk
+1  A: 

You may be interested in checking out some open-source Stack Overflow clones.

These are the ones that I am aware of:

Further to the comments below, please understand that these projects may not offer you perfect examples on which to base your technical decisions for your project and coursework. However I can only see the possibility of gaining benefits from checking them out, and understanding what approaches they take to solve the requirements you already identified.

I agree with Andy Hunt when he suggests in Pragmatic Thinking and Learning: Refactor Your Wetware to gain some experience first, then to learn the theory about it. The following excerpt from a review by Robert Delwood on this book outlines this chapter perfectly:

The traditional approach, the passive act of being taught, doesn’t work. In that regard, no one can “teach” us. We can be lectured all day about rock climbing but it doesn’t make us rock climbers. We have to “learn” and that is tied to experience. That’s why dreams seem so ethereal to describe: There is no experience.

Facilitating cooperation between the two modes begins with Hunt’s maxim, “Lead with R-mode; follow with L-mode.” R-mode only needs the most meager of information. Even doodling is helpful since it ties information to an experience. For producing results, take the writer’s adage “write drunk, edit sober.” Not to be taken literally, this stresses letting the creativity flow at first, then use logical processes to refine the work.

For learning, gain some experience first, learn more about it, and then dive into the experience.

Daniel Vassallo
I don't recommend this. You probably won't learn the best way to do it; I'd start from scratch and see what you can come up with from your own heads (reviewing various good ideas posted around the place). The idea is to learn, not to copy.
Noon Silk
@Silky: I can agree with your first point. Nevertheless, I cannot see how reading the source code of any working example can hurt the learning process. All my textbooks are filled with examples.
Daniel Vassallo
Daniel: You could learn bad practices; but also seeing the answer before you work out the solution really harms your ability to learn, in the future, IMHO.
Noon Silk
Silky: Hmm... yes you can see bad practices in any open-source project. However I trust the developers reading the code to judge what level of trust to give to any practice they identify. You can easily learn as much bad practice from "reviewing various good ideas posted around [any] place".
Daniel Vassallo
Daniel: I'm pretty happy to agree to disagree. And FWIW, I didn't downvote you.
Noon Silk
+1  A: 

The devil is in the details. Anything is doable in three months, as long as what you want to do can be done in three months ;)

I would imagine that a simple rep system wouldn't be too hard to implement. But as soon as you start adding reputationg graphing, tag statistics, badges, and all kinds of rule-based logic around it, the complexity balloons.

Keep your feature list simple and I would imagine that your team could implement a great looking project in three months.

womp
+1 for "Keep your feature list simple" (this is the key point i think).so "this seems feasible for the ~3 months"
ipat
A: 

Check "The Mythical Man Month" for your "if this seems feasible for the ~3 months" question :

"My rule of thumb is 
- 1/3 of the schedule for design, 
- 1/6 for coding, 
- 1/4 for component testing
- 1/4 for system testing."
ipat
+2  A: 

From the StackOverflow podcast, Jeff notoriously estimates everything taking 6-8 weeks. Apparently it took twice that long with 3-4 programmers. So while it sounds doable in 3 months the reality is that this was a startup with full-time resources who were obsessed with getting this done. I don't think you'd see any 40 hour weeks here, these guys were probably churning out code most waking hours. As a introduction to web development class project, I doubt you're going to be able to have that level of commitment, with other commitments such as your other subjects, drinking and chasing girls.

Its worth taking a look at what Jeff himself says about the time taken to write StackOverflow on his blog, Coding Horror: Code: It's Trivial and this analysis by Benjamin Pollack

You have a bit of an advantage here over the StackOverflow team - you don't have to solve the same problems - make it scalable, implement caching, build a community, make a viable business, etc.

So a really, really simplified version may be possible but cut down the scope to the core - you can always add more features later if you have time, but if you try to do too much you will end up with a mess of code that doesn't work at the end.

Chris Latta
A: 

The important thing to do is to make it into a real agile project, with a weekly delivery schedule. Complete, tested, documented, working code, every week. Every week, make a prioritised task list. Customer value first. Make it work without javascript first.

Stackoverflow itself took much more effort to build, as it has much more stringent scalability requirements, a fancy UI, and some processing-heavy functionality (full text search).

The easiest technology to build the functionality in would be Seaside.

Stephan Eggermont