Making a (non-WTF) commercial website



  • First a bit about myself. I'm a student, studying for a bachelor in game- and media programming. I know Python, Perl, Java, C++ and JavaScript, and I know how to write HTML and XML documents. But that's pretty much it as far as my expertise goes, so that's why I'm posting this.

    Besides studying, I've been hired to work out a solution for a commercial website. It's a small family business project (don't worry, I didn't get hired for my family ties), done mostly as a community favor.
    At the moment the website is in quite a sorrowful state. Customers have to write down the order number, then get in touch with the management to get the total including shipping costs before finally paying via PayPal.
    For the solution I'm going to make, they would like to keep track of their inventory so they can update their website with what they have in stock, so naturally I've suggested a database. I would also like to use the database to store the customer orders. However, I don't know squat about SQL other than the WHERE clauses and other optimization techniques I've picked up on TDWTF. Hopefully I won't make too many WTFs as I learn it.

    Anyway, here's how I imagine the result should be:
    The webpages are served through CGI scripts, polling a MySQL database for the inventory counts, item prices etc. for the relevant category. The user can add items to his/her cart, which is saved in a cookie. When the user checks out, he/she is shown the total cost and is prompted to enter the shipping address and his/her credit card details before the order is saved to the database. I assume the CC details are usually forwarded to the bank immediately instead of being stored in the database out of security reasons.
    All the orders can then be viewed on an admin page, so that the order can be processed.

    Now, the only reason I'm going with MySQL is because I've heard about it, it's free, and it's better than MSSQL. Are there other alternatives, and how suitable would they be? Also, how should I split up the tables? Should I put items from all categories in one big table and use a WHERE clause, or should I make one table for each category?
    And about the shopping cart, is there a better way rather than using cookies? Could it be a good idea to store the cart along with the IP in the DB, automatically cleaning up entries older than X days?
    Does anyone here know how CC billing works, and would care to fill me in on the details? And how do I make that page encrypted?
    What is the best way to find out the shipping costs?
    And last but not least, how many man-hours do you think it will take to get this project completed?

    Thanks!



  • @Faxmachinen said:

    Now, the only reason I'm going with MySQL is because I've heard about it, it's free, and it's better than MSSQL. Are there other alternatives, and how suitable would they be?

    If there is a golden hammer for database problems, it's postgres. mysql would be the golden shoe; it's a passable network storage server, and a lousy RDBMS.

     

    The right solution to your problem is probably to deploy oscommerce. The world does not need yet another half-arsed custom-built web storefront.



  • @asuffield said:

    The right solution to your problem is probably to deploy oscommerce. The world does not need yet another half-arsed custom-built web storefront.

    That's very true. Congrats on your 2000th post by the way.



  • "Now, the only reason I'm going with MySQL is because I've heard about it, it's free, and it's better than MSSQL."

    I'd do a little more research.



  • @hunterjrj said:

    I'd do a little more research.

    Out of all the search terms I've put into google so far, postgres has yet to make an appearance on the results page. And even if it did, a string of garbage would probably make more sense to me than the specifications. I don't know about you, but I'd rather ask someone who knows than just hit "I'm Feeling Lucky".

    Congrats on your first post by the way. I hope you're proud of it.



  • Did I mention Postgres? No experience with Postgres here and as such, no advice regarding its usage. I was implying that you should do a little more research on MySQL before you declare it inferior to MSSQL. You'll find the opposite to be true. And you may find that the tools offered by it and the .NET platform will make your project (and subsequently your life) easy. I'm no Microsoft evangelist, but in my professional experience I have found that it the tools they offer very useful.

    Microsoft SQL Server 2005 is offered in an "express" edition as are the development tools. Check them out.

    And one last point - if your app will be developed for and maintained by "family", give them a solution on a platform they are familiar with. Again, it will make your life easier, unless you are interested in having 100% responsibility for 100% of the application's lifetime. No fun. If they are familiar with Windows, develop the solution for it, and use the tools that make the most sense for that platform. Same advice goes for any other platform.



  • Oh look, MS marketing spiel. I bet it's the same shilling company.

     

    The platform you're deploying to is the web. Windows is irrelevant.



  • Was that a serious comment? If so, it really sheds some light on your level of experience in professional software development. Think: backups, updates, general maintenance. Mom and pop being responsible for it at some point during the apps life cycle. I don't know about you, but my mother and father certainly could not untar a file and edit conf files with vim and the like. Hell, they have trouble unzipping files. But double click an installer? Sure. They are business owners without alot of time on their hands to mess around. They need a solution that is simple for them to deal with when problems inevitably arise.

    Your target audience may be utilizing the application via the web, but what lies underneath the presentation layer is quite a bit more important when professionals (or even knowledgeable people) aren't readily available to deal with issues as they arise. And, like it or not, the fact of the matter is that most people out there who have used a computer have used some incarnation of Windows and may not be quite as intimidated using it as opposed to using a terminal window of some sort.

    Another point that I'd like to make is that the initial poster mentioned that he is in a gaming/media development track in school. Would it be a bad thing for him to develop this application on the platform that he will most likely be using when he gets out of school? How many professional games do you know that are written in Python on FreeBSD using Emacs? Lets get serious. Visual C++ is the standard and is a Microsoft product. If he chose to develop his solution with MS products he'd be getting real world experience with the tools he'll be using down the road anyway.

    Lastly, look in the address bar. .aspx files? You must be surrounded by shills.



  • @hunterjrj said:

    Was that a serious comment? If so, it really sheds some light on your level of experience in professional software development. Think: backups, updates, general maintenance. Mom and pop being responsible for it at some point during the apps life cycle. I don't know about you, but my mother and father certainly could not untar a file and edit conf files with vim and the like. Hell, they have trouble unzipping files. But double click an installer? Sure. They are business owners without alot of time on their hands to mess around. They need a solution that is simple for them to deal with when problems inevitably arise.
     

    People who have trouble unzipping files have no business dicking around with essencial systems. Allowing them beyond the web interface provided by the app is just going to end in tears. I don't know what you think they will do when confronted with a problem. How can someone who doesn't even know what a database server is resolve a problem with one?

    If they don't have the time or experitise to deal with problems they have to pay someone else to do it. Pretending they can be a sys admin just because they can click around in explorer, install a program or two and use word is not a solution.



  • It's almost funny how somebody can quote that marketing gunk with a straight face as if they almost believed what they were saying. I particularly like the way he suggested writing a web application in C++. Only a marketdroid could come up with that one.

    How many professional games do you know that are written in Python on
    FreeBSD using Emacs? Lets get serious. Visual C++ is the standard and
    is a Microsoft product.

    All serious game development companies know that the MSVC compiler is a piece of shit which generates slow code, which is why most of them use Intel's compiler.



  • I'm not going to spend too much more time arguing here. The fact is that if you have professional experience dealing with community-level or mom-and-pop-level operations , you'll understand what I'm talking about. Often those kinds of operations have limited funds and cannot afford to hire people to administer their systems. Usually, its the developer who winds up supporting the app. And as a developer who is busy with school (as our first poster is) do you want to be bogged down walking a non-technical person through an involved process? Not likely. And if you are forced to, you want to minimize fuss. You have choice - you can choose a non-Windows platform, which obviously has MANY merits from a technical stand-point, or you can choose a Windows solution which also has technical merits but has the added benefit of being somewhat accessible to those of us who aren't spending our time in command shells and IDEs.

    Now I'm making assumptions here, not limited to that the fact said developer will not be able to access his client's systems when he needs to. I'll concede that if he is taking care of the systems himself then the stability and cost involved with open-source tools create a compelling argument for their usage. However, if he will be responsible for maintaining the system over the phone or via email or snail mail or whatever, choosing a platform that is accessible to largest number of people makes sense, especially considering his time and stress levels.



  • @asuffield said:

    It's almost funny how somebody can quote that marketing gunk with a straight face as if they almost believed what they were saying. I particularly like the way he suggested writing a web application in C++. Only a marketdroid could come up with that one.

    How many professional games do you know that are written in Python on
    FreeBSD using Emacs? Lets get serious. Visual C++ is the standard and
    is a Microsoft product.

    All serious game development companies know that the MSVC compiler is a piece of shit which generates slow code, which is why most of them use Intel's compiler.

    Wow. This is really getting out of hand. You missed my point by about about a mile and a half.



  • @hunterjrj said:

    And as a developer who is busy with school (as our first poster is) do you want to be bogged down walking a non-technical person through an involved process? Not likely. And if you are forced to, you want to minimize fuss.
    That quote there is the exact reason he would be using the FOSS oscommerce, and a LAMP (or WAMP) stack, he doesn't have to reinvent the wheel, there is presumably a large community they can ask who are fully willing to help out with any problems they have. writing something in C++ when a viable solution is already available is a stupid argument. Also the advantage of a LAMP stack is he can setup SSH if need be, although Win XP/Server do have RDP and Remote Assistance they tend to be significantly slower than SSH; from experience over a 100mb/s LAN link; obviously worse over a 1mp/s (presuming) WAN link. Also the use of Linux saves them the cost of having to buy a copy of Win Xp/Server/Vista just to host a website, personally I would use a Linux server built from a minimal distribution, less services/daemons == less possible attacks of opportunity.



    Of course Microsoft has a community help center as well, although last time I used it I ended up with 500MB of spam messages in my inbox within 10 hours.



  • Thank you for an intelligent response, although I'm not sure where people are getting the idea that I suggested writing a web app in C++. My comment was pushing the idea of gaining experience using MS's dev tools, which are unified, and thus writing a web app using the .NET platform would give him experience in Visual Studio which could/would help in his future projects.

    One of the major problems that I personally encountered over and over again in my first couple of years in of professional software development was gaining access to the server in question when a problem arose. This was back in 99/2000, when broadband was widely available in the area I was in. Despite that, time and time again there would be access problems and walking people through performing the correct procedure to fix said problem was a chore. Even worse, when I entered the realm of enterprise software development quite a few of the organizations that I dealt with were just as poorly equipped to deal with problems as were the mom and pop shops. I'm speaking about organizations whose revenues exceed 50+ million per year. It is quite shocking to me to see the lack of skill present in people who are responsible for systems that drive large businesses.

    So with that said, and taking your point into consideration, I'll boil my argument down to its essence: Use tools that will make your life easier. If thats .NET, great. If its an existing solution with a few modifications, great. Just realize that software development isn't just about the code, or what platform gets used, or how much of an idiot you can make other forum posters look like. When systems go into production, the human factor dominates. Anything you can do to make the life of the person supporting the production system easier will benefit you ten fold.



  • 1. You do not EVER store anything in the cookie that is relevant to how the server-side of things work, EXCEPT for the session token. You do not store the shopping cart in the cookie. You do not store pricing information in the cookie. You do not store login details in the cart. Quite literally the ONLY thing that EVER goes into the cookie is the ID token of the user's session on the server.

    Remember that anything in the cookie will be round-tripped for every hit on the site, and once it's on the user's computer, it's utterly under their control. You might think it's neat to store "200 inch plasma screen. Cost $50,000.00. Shipping $500.00" in the cookie. But once the user gets their hands on it. It'll be "200 inch plasma screen. Cost $0.00. Shipping $0.00" and then your site is dead and someone's feeding your face to your ass.

    To store your required persistent data, you put it into the session. Or whatever the server you end up using calls it. It'll be stored purely server-side, and the user will never see what's in there, except as mediated by your site.

    2. Don't even start talking about database schema design until you've checked into everything else. There's no point in building up a complete e-commerce solution for your needs, and then finding out that UPS/FedEx/Whoever refuse to give you an account. Same for credit card processors. Fancy store, but "oops. we can't accept Visa/Amex/MC". Not very useful at all.

    Read up on the PCI standards. They'll dictate somewhat how your back-end system will have to built. If you can't comply with PCI, then you're not getting a merchant account and not getting access to a card processor's system. 

    3. If you don't know how to encrypt a page, or even the technical name for it (SSL, look it up), then you're so in need of education you shouldn't even be shopping for shipping/credit card accounts. Learn to crawl before you try to walk/run/fly. 

    4. I'm assuming that this will be a fairly low-volume site, with maybe a few thousand hits a day. In which case it doesn't matter, really, what database you end up using. Unless you're up at the Amazon levels, they're all "fast enough" for most practical purposes. It boils down to whether the server offers you the features you need. With proper care and coding, a simple flat text file could be enough. Not practical, not very useful, but it could work.

    Again, until you know exactly what your requirements are, don't start shopping for a DB server. You're not at the level when this becomes relevant. You're still trying to decide between walking, biking, or driving. So don't start shopping for the car yet, because you might up just needing a new pair of shoes. 

    5. As was mentioned earlier. Why do you have to build your own wheel from scratch? There's plenty of free/opensource/commercial e-commerce systems out there. And even then, why do you have to do it all yourself? Why not check into something like Amazon's merchant services? You could end up spending MONTHS of real time building/debugging/testing your system, when you could spent a day or two configuring Amazon's stuff and be up and running.

    Again, you're at the conceptual stage of all this. Don't start digging into the nittygritty of e-commerce until you're SURE that other solutions that are already available will not work. 

     

    As for how long it takes, I had to build a solution for a client from the ground up, because that's how they wanted it. It had enough oddball requirements that adapting another solution would have taken about as long anyways. Thankfully it was small-scale. One card processor (authorize.net), one shipping agent (UPS), a single product (the company was doing a market test to see if demand was there to scale up to selling more), and even then, it took about 2 months and several complete re-writes of the web front-end before they were happy. 

    So, remember... learn to crawl before walking. You're trying to fly with a heavy load of lead on your back. 



  • @MarcB said:

    There's plenty of free/opensource/commercial e-commerce systems out there.

    Well, about three ones of note, anyway. And oscommerce is what pretty much everybody uses these days (ever notice that there's more than a few thousand web stores out there which all look more or less the same? That's oscommerce running the default theme. It's everywhere)



  • @asuffield said:

    That's oscommerce running the default theme. It's everywhere
     

    Yeah, it's pretty ugly too. I looked at that festering pile of crap for a few minutes because a client wanted a simple store-front without having to build/buy one

    Even just getting it installed brought out a whole load of HOLYWTFOMGZORZBBQ!!1111 moments. #1 was that OSCommerce out-of-the-box REQUIRES that php's register_globals be turned ON. There's a patch to fix that (it's all of about 50 lines long), but it's not official, not part of the oscommerce distro, and only mentioned in a few posts on the oscommerce forums.

    Brilliant high quality design, that....

     

     



  • @MarcB said:

    3. If you don't know how to encrypt a page, or even the technical name for it (SSL, look it up), then you're so in need of education you shouldn't even be shopping for shipping/credit card accounts. Learn to crawl before you try to walk/run/fly.

    Actually, now it is called TLS.  http://en.wikipedia.org/wiki/Secure_Sockets_Layer

    Ever notice how everybody says "Not to be pedantic" right before they are?



  • @GalacticCowboy said:

    Ever notice how everybody says "Not to be pedantic" right before they are?
     

    Common formula in English (dunno about other languages.):

    I'm not trying to be negative but...

    I don't mean to be rude but...

    I'm not rasist but...

    I'm not the violent type, but hearing these....


  • You do make some good points MarkB, if a bit patronizingly. I do realize I have a lot to learn, I just have to figure out where to start.

    Thanks for the pointers so far.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.