Killersites.com - Web Design Resources

View Cart

Archive for the ‘Nerd Concepts in English’ Category

Building an Ecommerce Website – a Layman’s Perspective

Wednesday, March 25th, 2009

There are plenty of articles on how to build an e-commerce website. The problem is that they speak to web-nerds and not to the business people who want to build on online business.

This article speaks to those not so tech savvy entrepreneurs.

What we want to do:

The goal is to create an e-commerce website that builds a business using all the cheap and free tools available in the market today. One great thing about the nerd driven computer revolution, is the strong sense of community and desire to give opportunity to the masses.

Because of this freely available cheap and/or free technology, it is just so much easier today to start a business than it was just 15-20 years ago.

These are some of the questions this article will answer:

  1. What are the components of an e-commerce site, and how do you best get those components into your web site?
  2. What makes an e-commerce website successful?

(more…)

What are database driven websites – podcast.

Saturday, August 26th, 2006


podcast_icon

A quick podcast where I explain the basics behind what database driven websites are.

This podcast targets total beginners.

Database Driven Websites Explained.

Is HTML a scripting language?

Thursday, August 24th, 2006

I’ve seen this confusion come up from time to time – is HTML a scripting language?

Short answer: no.

Yes a nerd detail, but nonetheless, this is something that should be made clear.

THE DETAILS:

HTML is actually a markup language and not a scripting language.

Scripting implies decision making capabilities (the code can actually evaluate and take an action based on what it finds) – PHP, PERL, Ruby, Javascript are examples of scripting languages.

Markup languages create structure for a document … they only describe data. For example:

  • HTML
  • XHTML
  • XML

… but you knew that already.

[;)]

Stefan Mischook

3 Categories of Programming Languages

Wednesday, August 2nd, 2006

I wrote my first script back in 1996 – some really simple JavaScript that validated HTML forms and presented users with ugly ‘alert’ boxes when errors occurred.

I always wondered why on Windows, ‘alert’ boxes looked so ugly?

… they probably looked good on Macs though.

Since then, I’ve written software for business purposes in perhaps 8-9 languages. Over the years, I’ve come across many ways in which people classify languages:

  • Object Oriented vs. Procedural vs. Prototype
  • Scripting vs. Programming
  • Compiled vs. dynamic

… and many more.

Recently a more practical way of classifying languages has come to my attention – classifying languages by problem-domain or in other words, context.

  • System Languages
  • Architectural Languages
  • Application Languages

I like this list, because it really conveys a sense of practical use for a language. I’ve hammered out the details below:

System Languages

… best used to build operating systems, hardware drivers etc. Fast and gives you low level (close to the core) access to the computer. These languages are used when speed is critical.

These languages include:

  • C
  • C++
  • Assembler

Architectural Languages

… best used to build frameworks that support (make easy) application building. Not as fast (at run-time) as system level languages, but they provide a higher level of abstraction that makes writing software quicker and more productive.

These languages include:

  • Java
  • C#

Application Languages

… best used to build the actual business applications like web shopping carts/stores, connecting to databases and creating the screens for users to interact with the database.

These languages include:

  • PHP
  • Ruby
  • Perl
  • Python

These language all allow for extremely fast development.

Programmers are freed from the low-level details that you have to contend with when working with architectural and system level languages.

The fact that they’re all scripting languages (that don’t need to be compiled,) adds to the ease of use and speed of development.

MY POINT

It makes for an interesting way to look at languages … and our choice of what language(s) to use for a given project.

Stefan Mischook

WHAT ARE DATABASES – PART 1

Monday, July 3rd, 2006

WHAT ARE DATABASES?

Databases are programs that are built to store and manage information. You can think of a database as a virtual filing cabinet – with extra bells and whistles.

Types of databases:

There are several types of databases used today. The most common being:

1. Relational databases.
2. Object databases.
3. Flat file databases.

You can think of each type of database as a different way (conceptual and practical) to store and manage information.

Each type of database has its advantages and disadvantages. That said, by far, the most popular database type is the ‘relational database’. That’s why we concentrate on them here.

WHAT ARE ‘RELATIONAL’ DATABASES?

As I hinted at above, each database type has a different concept on how data/information should be stored and organized.

A relational database stores (and organizes) its data/information by creating relationships between different pieces of information (stored in virtual containers) that are … uh, related to each other.

To illustrate the point: if you had a brother, your mother would be the ‘key’ that forms the relationship between you and your brother.

With this analogy in mind, we can say that a relational database stores and tracks data by establishing relationships by using ‘keys’ (in this case, your mother) that are consistent between two pieces of information – you both have the same mother.

Popular relational databases include:

· MySQL (often used with PHP because it’s free)
· Oracle
· Microsoft SQL Server

WHAT ARE VIRTUAL CONTAINERS?

We all know that it’s much easier to store and find stuff/things (in your home) if you put the stuff into boxes and then label the boxes … much better than just leaving all your junk on the floor.

Though naturally a messy bunch, nerds have picked up on that fact, and realized that computer information should also be stored in boxes (virtual containers) that are labeled. In a relational database, we call these ‘boxes’: tables.

In a nutshell: the virtual containers in relational databases are called ‘tables’ and information is stored in tables.

MORE ABOUT TABLES

Database tables are virtual containers designed to hold and organize data. In many ways they look like spreadsheets where database tables have both rows and columns.

The difference between a spreadsheet (like Excel,) and a relational database table, is that the spreadsheet is designed (has built in capability) to manipulate data for the purposes of presentation – creating charts and reports etc.

Where on the flip side, a database table is designed (has built in tools/capability) to organize and maintain information and it can hold much, much more information than a spreadsheet.

So yes, you can store information in a spreadsheet, but it lacks many capabilities (and capacity) that you would find in a database.

We will learn more about the makeup of a table (purpose of the rows and columns) when we actually build one.

THE ‘RELATIONSHIPS’ IN RELATIONAL DATABASES

As I mentioned above, a relational database stores information in tables (the virtual containers) and then creates relationships/connections between the tables (and thus the data that is stored in the tables.)

This system/method of storing information (by creating relationships,) is efficient because of a few reasons; the most important being is that this style of storing information (in tables that are related to each other,) helps to prevent information from being duplicated needlessly.

A FUNDAMENTAL PRINCIPLE OF DATABASE DESIGN

One of the fundamental rules in database theory/design, is that information should not be duplicated:

… if you have multiple copies of the same information floating around, it takes up more disk space and can easily become a nightmare to organize.

By storing information in different tables, and linking that information to each other (that are related,) you avoid duplicating information. This will become clear when we actually build our first database … I know (that for now,) many of you are probably unclear about a few things … have faith, it will come!

Part 2 coming out soon …

Thanks,

Stefan Mischook

© 2009 - Killersites.com - All rights reserved
  • Hosting and domain name support:
  • (480) 624-2500

PayPal Customer Support: 1-888-221-1161

Killersites.com has been a PayPal Verified Merchant since 2001. We also accept payment via check or money order.

Please send payment to:

Killersites.com Inc. 4156 Dorchester #2 Westmount, Quebec Canada H3Z 1V1

The more you learn, the more you earn!

Subscribe to our newsletter
Unsubscribe