Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Shopping Cart Project - interested?

by moltar (Novice)
on Feb 25, 2005 at 21:23 UTC ( [id://434654]=perlnews: print w/replies, xml ) Need Help??

Shopping Cart Project

Objective

Develop the best open source shopping cart software (SCS). The goal of SCS is to be robust, scalable, modular, easy to use and customize. SCS will be developed by the best programming practices available today. SCS will have complete separation of code, mark-up, presentation and supplemental functionality. SCS will obey guidelines for usability and accessibility. SCS will be search engine friendly.

Technologies

SCS will be coded in PERL and utilise the full power of mod_perl. SCS will follow strict guidelines of W3C for mark-up and user experience. SCS mark-up will be coded in XHTML and utilize CSS for style and presentation. JavaScript will be used to enhance user experience where appropriate.

Other technologies/frameworks/guidelines will include:

  • Apache (mod_session, mod_rewrite)
  • MySQL
  • C Language
  • XML / XSLT
  • RSS
  • SOAP / REST
  • I18N / L10N

Programming Practices

SCS will be coded strictly by XP (Extreme Programming) process.

SCS will be designed in MVC (Model/View/Controller) style. Full separation of business logic (controller) and display logic (view).

Call for Action

  1. Do you like to be on the edge of technology?
  2. Do you feel comfortable with technologies mentioned above?
  3. Are you a quick learner?
  4. Are you interested in this project?

If you answered "Yes" to at least one question, contact us now! We are seeking contributors with all sorts of expertise.

  • Wizard PERL developers
  • Efficient database designers
  • Apache masters
  • XHTML aces
  • Leading Project Leaders
  • Skilled GUI designers
  • Well-versed technical writers
  • Diverse Translators
  • Usability veterans
  • Accessibility specialists
  • SEO/SEM professionals
  • Experienced shoppers
  • Critics

Are you interested?

Replies are listed 'Best First'.
Re: Shopping Cart Project - interested?
by skx (Parson) on Feb 25, 2005 at 23:58 UTC

    Rather than focus on the technologies involved you'd be better at selling this if you wrote about the features you intend to support.

    There are a million and one projects hosted on sourceforge that have grandiose plans to take over the world, and no code to show for it. What makes you think you can do better?

    I'm not trying to put you off, or ruin your announcement, but unless you have features and at least a small idea how to do what you want you're going to get nowhere fast - and involving too many cooks at an early stage of the project is liable to land you in a real "designed by committee" mess.

    The best thing to do, IMHO, is to define what you want to achieve. Exactly.

    There are lots of existing shopping cart systems around - why don't they work for you? What specifically do you need that writing from scratch is better than adding missing features to an existing piece of software?

    Whilst you could come up with something revolutionary I'm sceptical based on what you've written thus far - the idea of a stable shopping card that is at the cutting edge of technology seems a little at odds.

    How do you plan to handle payment gateways? What do you want to use for the layout? How are you going to handle mutliple languages? All these and more are serious questions which you need to flesh out a little at least.

    Supporting mutple databases is good, but you should probalby start with one and add more support as time goes on - too much abstraction early on can be a killer.

    Steve
    ---
    steve.org.uk
Re: Shopping Cart Project - interested?
by Tanktalus (Canon) on Feb 25, 2005 at 21:46 UTC

    I think I can fill the role of minor critic ;-). A couple points/questions:

    • What role do you see C having in this? The most critical aspects here seems to be the webserver and database - both of which are already in C. If you're using perl at all, which you say you are, I'm not sure where else you plan on drawing the lines.
    • What platform(s) do you plan to support? If it includes Windows, is there a plan for this? I presume IIS support is right out.
    • Your choice of DB is interesting. Without attempting to start a flamewar on this, I'd like to point out that flamewars on choice of DB happen. Depending on how large you see this growing, you may be alienating many potential users. Are you planning to have a database-abstraction layer to allow Oracle, DB2, and PostgreSQL bigots all have their chance to implement drivers for their favourite database? How will that look?
    • Javascript seems to be a sore point around here sometimes... ;-)
    Ok, that's about all the critiquing I can do... ;->

      Thank you for taking your time to read and answer.

      • C might be used in the project. It could be used for driving a high traffic shop's front end or could be used for an API. This is not something I really want to do, but it's a possibility. I figured it will raise some discussion :)
      • I would prefer to support both Apache and IIS.
      • Database-abstraction layer is a great idea. And multiple database support was something I thought about, but did not include into the outline. I think all development will be done on MySQL anyways.
      • JavaScript use will be very limited. JS will be used to enhance user experience. No critical features will be written in JS.

        Thanks for your answers. I'm not sure how depending on mod_perl will work when trying to support IIS. The Javascript answer is disconcerting. Not because I'm anti-JS. Nor am I pro-JS. Just that my experience is that saying a feature will only be used for some things ends up getting it used for all things. Your JavaScript expert will want a feature that should be implemented in perl. But the perl guys don't have time, so the JS guy will just go ahead and implement it. I've seen that type of thing happen before - either it's too big of an itch to wait, or whatever. It can take a lot of project management skills to keep in line. In many ways, it's cheaper/easier to just discard JS use, or accept that it will be used for anything and everything.

        To be honest, I've never managed to get MySQL set up on my RHEL3 box. DB2, however, was easy. But maybe that's just me. Regardless, database abstraction is unlikely to be successfully accomplished on a single database platform. Just like developing a cross-platform Java tool ... and everyone develops it on Windows. (Seen that before, too.) Or even a cross-platform perl utility - and only running it on Linux.

Re: Shopping Cart Project - interested?
by stvn (Monsignor) on Feb 25, 2005 at 23:33 UTC

    One thing to add to the "Technologies" section:

    use as many CPAN modules as we can
    And one thing to add to the "Programming Practices" section:
    written using TDD
    Yes, this is sorta implied with XP, but "strict" XP is an ideal, and not always a reality, so best to be specific about TDD.

    And you should list a "security expert" in your list of contributors you are seeking. After all an insecure shopping cart is not very useful to anyone.

    And lastly, I have a few questions for you since you seem to be new around here.

    • What is this for? Is it just an open source project you have been itching to build? Is it for a specific project/business?
    • Is it open source? You do not specify, and if so, under what license?
    • Who are you? Tell us a little about yourself, so we know who we might be getting involved with. Your home node (moltar) only tells me that you are in Canada and just joined the side today.

    -stvn
      use as many CPAN modules as we can
      I'm not sure that comes across as you intend. That would imply that three pages of "use" directives is correct and wanted, many of them probably in the Acme namespace. {grin}

      Perhaps what you meant is:

      Prefer existing CPAN modules over handwritten code

      -- Randal L. Schwartz, Perl hacker
      Be sure to read my standard disclaimer if this is a reply.

        That would imply that three pages of "use" directives is correct and wanted,

        Why do that when you can use Acme::Everything ;)

        -stvn
Re: Shopping Cart Project - interested?
by gmpassos (Priest) on Feb 26, 2005 at 00:28 UTC
    Hello motivated man,

    So you are going to produce "The Best Shopping Cart Project".

    Well, is a interesting thing, but be careful about the best of best thing to do, use, etc...

    I think that the best advice that I can give you is the KIS concept. Keep It Simple!!!

    For example XP, well, are you going to make a virtual cooperation group or a live group working in the same job? As I understud is a virtual group, so, will XP work well? I think that CVS and a mailing-list is the best thing that you can use for a virtual process.

    What I really want to say is that technology exists to help, not to be the main target. So, make a list of the best technology is easy and interesting, but generally a technology is something complex and when you assemble a lot of technology you will have something even more complex, and something complexer than what the problem really is won't work, or at least will give us a hard and long work that is not economically viable (even for a free project, since time is money). So, start from the needs of the project, and for some problem that the project have, look for a technology easy and stable to resolve the problem, in the end you will have a small list of technologies to use, what is good.

    So, always keep in the mind the concept KIS. I do this all the time and it really works. I prefer to spend some days looking for an easy, simple and good way to resolve the problem than just start to work and stay some weeks working in some complex solution, since a complex solution is something that any human being can create easy. Actually humans like to make things complex, just look around (do you know exactly how all your things works?)

    Other thing, look around, always look around, even the simple things, actually specially the simple things. So, see other Shopping Cart Projects or any site with a Shopping Cart, and see what is interesting from the client/user side, see a nice interface, etc... Since the client/user will be who will say if what you have created is really good. But in your project the client is also the webmaster that will use your project and implement the Shopping Cart in some site, so, will not be easy.

    Humm, start looking amazon.com, and I can say to you that they use less complex technologies than your list.

    Well, for now is this. Note that this is an advice from someone that works giving this advices, that also did some comercial projects like that. So enjoy, since I will not send you the bill. ;-P

    Good luck!

    Graciliano M. P.
    "Creativity is the expression of liberty".

Re: Shopping Cart Project - interested?
by merlyn (Sage) on Feb 25, 2005 at 21:51 UTC

      That argument had as much merit the last time I heard it, when someone recommended PHP 4 over Perl.

      If you'd spent all of the time you've spent making snide remarks about MySQL giving the actual factual technical reasons why PostgreSQL is better than MySQL in those cases where it is, you'd have done a lot more to convince people.

      (Note to anyone else who wants to argue this: linking to MySQL Gotchas doesn't count for much in my book. Also be aware that I have used and still use MySQL, PostgreSQL, and SQLite.)

      Indeed: why any particular database product? or server?

      The answer is probably somewhere around "that's what hosting companies still offer", which is what a lot of people tell me when this topic comes up, but then they use all sorts of other advanced features that hosting companies usually don't support.

      --
      brian d foy <bdfoy@cpan.org>

        Because cross-database portability of SQL is still a myth. There are a lot of very, very similar flavours, and indeed the most basic of functionality is portable across dialects, however if you restrict yourself to factually portable SQL you'll very soon hit on limitations.

        OTOH, a lot of the differences in the DQL and DML areas which concern the set of features common to all database engines are only superficial, ie syntactical. So assuming the database queries are properly encapsulated away from the application in a module as they should be, it wouldn't be hard to abstract away the differences between databases into several flavours of this module, of which one can then be selected by a configuration parameter.

        What all that means is that it's preferrable to target a particular database at first and only refactor the business logic module that encapsulates the queries when time comes for that.

        Makeshifts last the longest.

      PostgreSQL? Why not?.. Everything is open for discussion! The plan is to build the best shopping cart. If PostgreSQL fits into that criteria, then I am all over it :)

Re: Shopping Cart Project - interested?
by jacques (Priest) on Feb 26, 2005 at 01:27 UTC
    Wizard PERL developers

    How about getting people who know how to correctly spell Perl?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlnews [id://434654]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2024-03-29 11:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found