Beginning Django E Commerce
398 pág.

Beginning Django E Commerce

DisciplinaProgramação I24.794 materiais282.206 seguidores
Pré-visualização50 páginas
security very seriously and have secure servers 
hosting our site, we\u2019re protecting them by not keeping their credit card data where it may be breached. 
If you\u2019re determined to store credit card data because you simply feel that you must, at least make 
sure you never store or retain the card verification value (CVV) anywhere on your system, in addition to 
encrypting the data. 
Search Engine Optimization 
Search Engine Optimization is a weird area of web development because while we have some general 
guidelines to follow, nobody really knows the exact rules by which we\u2019re playing. In Bang the Drum 
Slowly, the characters play a game called \u201cTEGWAR\u201d \u2013 The Exciting Game Without Any Rules. The 
characters always entice some poor sucker to play with them, without mentioning what \u201cTEGWAR\u201d 
stands for, and the rules of the game always shift so that our poor sucker loses his money to the others. 
The odds aren\u2019t stacked against us quite as much in the SEO world, but it can feel pretty close. It\u2019s a 
place where the more knowledgeable are always uncertain, and prefer to rely on testing. Take everything 
anyone tells you with a grain of salt, as the whole area of SEO is fraught with misinformation. My advice, 
if you\u2019re just starting out, is to go straight to the information provided by the biggest search engine: 
Google. You can read Google\u2019s guidelines for SEO at their webmasters page:
Besides this, make sure that every page on your site that you would like to have crawled by Google is 
linked to from somewhere on your site, and make sure each page has a unique title tag and relevant 
content. I\u2019ll cover SEO in more detail in Chapter 11, and in various places throughout the book. 
Where you are going to end up deploying your application, and how you plan to handle all of the various 
components, is something you should be aware of up front. If you\u2019re deploying to the Google App Engine, 
some of the code you write for your models may be much different than the code you\u2019d normally write. 
During development, all of your project\u2019s components are probably going to be on a single 
development machine, like the desktop you may be sitting in front of right now. That one machine will 
have your database engine, Django code, style sheets, JavaScript files, images, and any other media on it. 
When you deploy your site into production, however, these different things are logically split out onto 
separate machines to maximize the efficiency you get out each one. You\u2019ll probably end up having at 
least one for your database server, one for serving your web pages, and another for static content, such 
as style sheets and images. 
Throughout this book, we\u2019re going to construct things so that when production time comes, we\u2019ll 
have a minimum of fuss getting all of the items ported over into their respective areas and still allow 
them to communicate with one another. I\u2019ll cover deployment more in Chapter 15. 
Business Requirements 
E-commerce is very much rooted in business. To create good software that accommodates the 
business process, it\u2019s helpful to have a little bit of background. Whether you\u2019re starting out doing 
some consulting work for a company looking to go online or trying to take your own sole 
proprietorship onto the web, knowing some of the basics will help you make some fundamental 
decisions about how to architect your application. 
I know you picked up this book because it\u2019s a programming title. You may have very little interest in 
learning any kind of business background. Most of what I\u2019m going to cover in this section is pretty 
elementary, and it\u2019s not at all comprehensive. My hope is to provide you with enough basic information 
that you can potentially ask your clients more informed questions, get the creative juices flowing, and 
provide one or two catalysts for brainstorming sessions. If not that, I hope that this helps you think 
critically about what you need to develop for yourself. 
 Of course, if you already know this stuff, or if you\u2019re strictly a programmer with a vow never to take 
any business classes, you can skip to the next chapter and get started creating your Django site. 
Accounting & Auditing 
It\u2019s hard to run any business without maintaining an accurate set of books, both for internal and external 
reasons. You\u2019ll need to keep a set of books so that you have some idea of where your company is, and 
where it\u2019s been, financially, so that you can devise some kind of strategy about where it\u2019s going. 
Furthermore, if you want to scare up capital by going public and issuing stock, you need to release 
financial statements so that your investors can decide whether or not your company is a safe 
investment. If you\u2019re publicly traded, you may need auditors to come in at least once a year to check for 
misstatements, either intentional or accidental, in your accounting records. 
Accurate financial statements are of paramount importance to everyone, and since a lot of your 
information will likely be tracked by your application, you should figure out what information you want 
to collect and how you want to collect it.
One of the main things you\u2019ll be tracking is your sales. (You are selling something, aren\u2019t you?) There 
are two principles you need to be aware of in deciding how to track your sales that will be of importance 
to any auditors or other accounting folk reviewing your books. First, there is the revenue recognition 
principle and the matching principle. Generally, you should recognize and record your sales after you\u2019ve 
performed all necessary business functions you need to order to earn them. With e-commerce, this is 
typically at the point when you\u2019ve packaged and shipped off the goods to the customer. You also want to 
match the record of your expenses with the corresponding sale. 
Typically, this becomes an issue on December 31st, the end of the fiscal year for most companies. 
Imagine a company that sells Twinkies online, in bulk. On December 31st, at 10PM, some person who\u2019s 
sitting at work on New Year\u2019s Eve (for some reason we can\u2019t figure out) ordering Twinkies for their 
business. They order $9,000 worth, and the company that\u2019s selling them has an e-commerce system in 
place that records these sales on December 31st. 
On January 2nd, two days later, the packaging and shipping crew arrives energetic and ready to 
work, punches in, and starts to process the orders. They ship off these $9,000 worth of Twinkies, the 
original cost of which was half that, $4,500, and then they punch out and go home for the day. (Workdays 
are short in my imagination.) 
The problem here is that the cost of the Twinkies (the $4,500) was recorded in one fiscal period, and 
the sales ($9,000) were recorded in the prior period. This makes the bottom line of the first year look 
$4,500 better than it should have, at the expense of making the next year look that much worse. And 
that\u2019s not even factoring in packaging costs, shipping costs, or the wages you had to pay your workers to 
come in and ship them. 
This may sound like a small problem (what\u2019s a measly $4,500, really?), but when auditors come in 
and test these kinds of things, they\u2019ll probably check your sales records and make sure that all of them, 
especially those close to the year-end cutoff, have corresponding shipping records. They find that you 
missed this $4,500 worth of cost. It doesn\u2019t bode well for how good you are at running things, and will 
cause them to look deeper and charge you more. Also, lots of companies do this intentionally: they 
record lots of sales toward the end of the fiscal year that should be recorded in the next year, to make the 
current one look better, a practice called