slashnode.

This set of articles serves to act as a introduction to not just programming in C++, but programming in general. They assume no previous knowledge; my aim is to write the articles such that anyone with a computer, internet access and an interest in computing should be able to read and understand them.

These articles are targeted mainly towards those who want to achieve a deeper understanding of programming, rather than just learning by the basic monkey-see, monkey-do ‘Hello World’ school of teaching.

“Why start learning programming with C++?”, you might ask. There are a few good reasons for this:

• C++ contains some of the best features of all the programming languages.
• C++ contains some of the worst features of all the programming languages. Why is this important? Because one of the most important things to learn when becoming a programmer is how to adjust your programming style to the language you are programming in, and this includes avoiding bad practices and/or features that the language may support.
• C++ allows us to interact at a ‘low level’ with the computer. That is, when we write code in C++ we are very close to what is actually happening in the hardware (as opposed to other languages that may simplify or dumb-down some aspects of the programming). Although this makes programming in C++ difficult (some may say frustrating) at times, ultimately it gives the programmer more control over what is happening and gives us a better understanding of how computers actually work.
• C++ supports object oriented programming. Object oriented programming is a style of programming that has been used as ‘best practice’ for decades now. It allows us to write bigger, more complex programs using less code that is more reliable.
• The syntax and control structures of C++ form the basis for a number of popular programming languages. Learn C++ and you’ll quite easily understand code in Java, C#, PHP and many other languages with little or no further education.

Before learning how to program in C++, it would be helpful to think about how a computer actually works. Computers have been constructed using the same basic architecture for decades. The architecture, known as the Von Neumann Architecture, looks something like the following:

Von Neumann Architecture

It includes:

• Input devices; used to provide input to the computer. This includes things such as a mouse and keyboard.
• Output devices; used to display output from the computer to the user. These devices are things such as printers and monitors
• External storage; used to provide “long-term” storage. This may include a hard disk, optical drive (CD burner) or USB flash drive.
• Memory; used for “short-term” storage. Memory is used to hold data the computer needs at the moment. This may include the operating system routines (for example, Windows or Mac OS X code) as well as the currently executing program (for example, the browser program code you’re using at the moment to surf pages on the internet).
• Control Unit; controls what the computer is doing at the moment and what it will do next. Basically a big list of commands the computer is going to execute, in the order they are going to be executed.
• Arithmetic Logic Unit; basically a really fast calculator. The Arithmetic Logic Unit, or ALU, executes the commands fed to it from the Control Unit.

This is (from a high-level) how most computers are constructed – and have been constructed since the invention of the computer. When we want to instruct the computer to do something, we need to provide ‘instructions’ which are fed by the control unit to the ALU. These instructions are written in something called Assembly Language, or ‘Machine Code’.

This language consists of numerically coded operations which represent basic arithmetic procedures like addition, subtraction and multiplication. They also provide basic data manipulation operations for moving information around the system. It is these basic principles upon which every computer program ever written is based. From these humble origins we derive CGI movies, MP3 audio technology and social media web applications.

As you can probably imagine, it takes A LOT of number crunching to create something like the latest 3D rendered movie. While very basic applications can be written in machine code, as the complexity of our applications increases, it quickly becomes quite infeasible to operate entirely in machine code. This is where our high-level languages come into the picture.

High level languages, like Java, Python, C and C++ allow us to write code using easily understood symbols. This human-readable code is then converted into machine code by something called a compiler. The human readable code typically consists of:

• Keywords; words that instruct the compiler what you want to do
• Variables; word used to represent a unit of data

Don’t worry if these definitions aren’t clear at the moment. They will become obvious in lessons to come. Read over the content in this article, and when you think you have a rough understanding of it all, you can advance onto the next step: installing the compiler and writing your first C++ application. To be continued…

Handling user access control can be a real pain for those just starting a website. We want to provide a secure, reliable solution – but most people don’t have the time to research all the nuances and subtleties of log-in systems to produce a sufficient solution.

I’m going to present a solution I’ve recently used on a small-scale site. It uses PHP and MySQL to achieve the basic functionality of validating a username and password against a database and then either permitting or denying access to a website based on the success / failure of this validation.

This is a great solution for most small-to-medium scale websites. A small disclaimer – this solution should not be used for websites or scenarios involving sensitive information. If you want further information about developing a solution for such an environment, leave a comment and I’ll point you in the right direction.

So let’s begin! The first step in the process is to create the table to house the credentials of our users. Enter the following into either a MySQL console window, or the SQL tab in PhpMyAdmin:


CREATE DATABASE database_name;

USE database_name;

CREATE TABLE IF NOT EXISTS `tbl_user` (
`username` varchar(20) NOT NULL,
`password` varchar(32) NOT NULL,
`email` varchar(20) NOT NULL,
`last_login` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`id` int(11) NOT NULL AUTO_INCREMENT,
`is_deleted` tinyint(1) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `username` (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;


A couple of things to note:

• User IDs are automatically generated by using an AUTO_INCREMENT.
• The password field is 32 characters long. This is to accommodate an MD5 checksum (more on this later).
• We’ve imposted a UNIQUE constraint on the `username` field. This means the database won’t allow us to insert a username if an entry already exists in the database for that username.

Before we can use the log-in script, we need to create some username / password combinations. I’m going to do this using SQL, but it wouldn’t be too hard to write a PHP script to achieve the same thing with a visual interface. The sytax is as follows:


INSERT INTO `tbl_user` (`username`, `password`, `email`) VALUES
('username', MD5('password'), 'user@domain.com')


You’ll notice that the MD5 checksum is used. By using the MD5 checksum instead of the password itself, we avoid displaying the plain-text password.

Now with the database created and our users inserted, we need to create three PHP files.

• A configuration file to house our database settings
• A PHP file for the log-in page
• A password protected page

We’ll name the first ‘config.php’, and it will contain the following:


session_start();
define("DB_HOST","database_server");
define("DB_USERNAME","database_user");
define("DB_PASSWORD","database_password");
define("DB_NAME","database_name");
$path = "http://www.yourdomain.com/"; // Root folder of your website


Obviously you need to replace “database_server”, “database_user”, “database_password” and “database_name” with the respective values for your database configuration. The next file will be the log-in page. We’ll name this ‘index.php’, and it should contain the following:


<?php
require_once("config.php"); // Load database settings

// Redirect the user if already logged in
if (isset($_SESSION["userid"]))
header( "Location: ".$path."admin.php" ) ;

// Retrieve username and password POST values if they were sent
$username = "";
if (isset($_POST["username"])&&($_POST["username"]!=""))
$username = $_POST["username"];
$password = "";
if (isset($_POST["password"])&&($_POST["password"]!=""))
$password = $_POST["password"];

// If username and password were sent, validate against the database
$status = "";
if ($username != "" && $password != "") {
$db = mysql_connect(DB_HOST, DB_USERNAME, DB_PASSWORD);
mysql_select_db(DB_NAME,$db);
// Execute the query. Note we use mysql_real_escape_string to avoid SQL injection attacks
$result = mysql_query("SELECT id,username,email FROM tbl_user WHERE username='"
.mysql_real_escape_string($username).
"' AND password=MD5('".
mysql_real_escape_string($password)."') LIMIT 1");

if ($row = mysql_fetch_assoc($result)) {
// If user successfully validates, redirect to the
// password protected page
$_SESSION["userid"] = $row["id"];
$_SESSION["username"] = $row["username"];
$_SESSION["useremail"] = $row["email"];
header( "Location: ".$path."admin.php");
} else
$status = "Wrong username or password";
mysql_close($db);
}

// Set error messages if appropriate
if (isset($_GET["failed"])&&$_GET["failed"]=="1")
$status = "Wrong username or password";
if (isset($_GET["loggedout"])&&$_GET["loggedout"]=="1")
$status = "Logged out";
?>
<!doctype html>
<html>
<head></head>
<body>
<form id="login-form" method="post" action="<?php echo $path; ?>">
Please provide your log-in details<br/>
<div style="color:#ff0000;">
<?php
// Insert error text if there is a message
if ($status != "")
echo ''.$status.'';
?>
</div>
Username: <input type="text" name="username" /><br/>
Password: <input type="Password" name="password" /><br/>
<input type="submit" value="Submit" />
</form>
</body>
</html>


Now that we’ve created our log-in script, we need a page to redirect the user once they have successfully logged in. We’ll use ‘admin.php’ for this:


<?php
require_once("config.php");

// Redirect the user if they are not logged in
if (!isset($_SESSION["userid"]))
header( "Location: ".$path."?failed=1" ) ;
?>
<!doctype html>
<html>
<head></head>
<body>
Logged in!
</body>
</html>


We can log the user out by using the ‘session_destroy()’ PHP function.

Anyone who has used Google Analytics for form-based Goal Tracking has probably been pleasantly surprised by how easy it is to set up. Simply enter the URL of your “Thank You” and click save – done. It even includes the option to match only the first part of a URL, meaning no tricky regular expressions if you need to ignore query string parameters!

But what if you want to track something a little more difficult than a form submission, for example, button clicks? Or what if you have a form without a “Thank You” page (eg: most AJAX forms)? This is slightly more difficult using Goal tracking. You could do something tricky, like dynamically load an invisible IFrame – but isn’t that just a little convoluted to achieve something that should be trivial? Shouldn’t there be an easier way?… There is, and it’s called “Event Tracking”.

Event Tracking allows us to specify when we want a certain behaviour (such as form submission, button press, etc) to be logged via JavaScript. The call is made on a page with your Google Analytics code on it. You use the “pageTracker” object and the “_trackEvent” function, as described below.


_trackEvent(category, action, label, value);


Where:

• category : the name you want to use for a group of events (ie: “Contact form”)
• action : the name of the action you are tracking (ie: “Form submit”)
• label : (optional) string to provide additional information about the particular event instance
• value : (optional) an integer value for the event (default = 1)

We can use this function anywhere we can call it from JavaScript. For example, to track button presses we can use the following:


<button onclick="pageTracker._trackEvent('Button','Press');">Track event</button>


… or to track a form submit:


<form onsubmit="pageTracker._trackEvent('Details form','Form submit'); return true;">
...


… or to do something more complex, possibly even with conditional logic. For example, we could track


<script type="text/javascript">
function validateNumber (inputVar) {
if (!isNaN(inputVar)) {
pageTracker._trackEvent('Data field','data saved');
return true;
}
return false;
}
</script>


Great stuff. You’ll probably notice, however, that your tracked Events don’t appear under the “Goals” heading in Google Analytics. Instead you’ll find your Event Tracking stats under, “Content” and then “Event Tracking” (see image below). Happy tracking!

Event Tracking in Google Analytics

Stop Skewing your Google Analytics Stats

Do you have Google Analytics on your site?

You probably answered “Yes” to this question. If not, you should probably stop reading and do something about it now.

If so, you’re probably familiar with a problem that has plagued just about every project I’ve been involved with to date. So you get your website up and running and start to see traffic trickling in. One day you open up your Analytics dashboard and notice a spike. 10 unique views! Sure, it’s not incredibly substantial – but you’ve only had the website up for 2 weeks and already you’re seeing results.

You call your content writer to spread the good news. He picks up the phone and mirrors your elation:

“That’s great news! I was actually just thinking of the site – I’m was at my friend’s house yesterday showing it to them and…”

But “Wait a minute”, you think to yourself. That would count as a unique page-view, wouldn’t it? Ok, so we’ll correct and say we’ve really had NINE unique visitors… But really, how many different computers has your content writer visited the website on? Now that you mention it, what about that time yesterday when you opened the website at work during your lunch break? These are all unique browsers, with unique cookie caches, right?

That unique visitor count is getting smaller by the minute. So what’s the solution to the problem?

One way would be to set-up IP-based filtering on your Analytics account.

If you work from a static IP address this is perfect. Set up 1 rule in Analytics, hit ‘Save’ and you’re set. No more skewed Analytics statistics as a result of page-views executed from that machine. For most people, however, this is not an option.

Those using a dynamic IP address – that is, an IP address that changes each time your internet session is renewed – would have to add a new IP to the filter list every time they visit the site. Not ideal.

A much better solution is adding a ‘Cookie’ based filter. That way the Analytics script looks for a specific cookie on each machine before counting it as a page view. If the machine HAS the cookie, it isn’t counted – otherwise, it is.

So we can set the cookie in our browser and be done with it, right?… Well, not exactly. What about if we usually use Chrome, but want to check the CSS works in Internet Explorer? What if we do a system clean up which involves clearing our browsing history and temporary internet files? What if want to check on the site while at work, at the library or a friend’s house?

Another solution is to add a page on the website which automatically adds the cookie to the browser upon visiting it, and then take steps to ensure the average user doesn’t stumble upon it. This way, whenever we want to check on the site we just need to navigate to this page, let the code set the cookie and then navigate back to the site. As an added precaution we can request a password from the user prior to setting the cookie – this will REALLY ensure that a normal user won’t inadvertently set the cookie and stop their traffic being measured.

The first step in employing this strategy is to set up the filter on your Analytics account for the website. You can do this from the ‘Analytics Settings’ page by adding a new filter, selecting ‘Exclude’, ‘User Defined’, ‘Case sensitive: No’ and providing the cookie value. See Analytics Help for more details.

The next step is to create the page that will set the cookie. The key aspect of the page is that it must load the Google Analytics script, and it must include the JavaScript directive:

javascript:pageTracker._setVar('test_value');

… where ‘test_value’ is the value of the cookie. The cookie can be any text string, as long as it matches up with the value set in the Google Analytics filter above.

My password-protected version of this code, written in PHP, is supplied below (Note: no warranty, liability or support of any nature supplied for this code.).

<?php
$gaCode = "";
$cookie = "";
$password = "somepassword";
?>
<!DOCTYPE html>
<html>
<head>
<title> </title>
</head>
<?php if (!isset($_POST["p"])) { ?>
<body>
<form method="POST" action="">
<input type="password" name="p" /><br/>
<input type="submit" value=">" /><br/>
</form>
</body>
<?php } else if ($_POST["p"]==$password) { ?>
<body onload="javascript:pageTracker._setVar('<?php echo $cookie; ?>');">

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("<?php echo $gaCode; ?>");
pageTracker._trackPageview();
} catch(err) {}</script>
</body>
<?php } ?>
</html>

So for one of my website projects I wanted to create a very basic content management system (of sorts). The plan was to have a header and footer template class, and include these from the ‘index.php’. The bit between the header and footer (‘content’) would then be pulled from another file, depending on the URL.

The basic set-up for this kind of CMS is that all requests are sent to one script, which handles working out which files need to be included based on the request URL. If we’re using Apache as our web server, we can do this easily enough using the .htaccess file.

A htaccess file (also known as a distributed configuration file) allows you to configure your web-server on a per-directory basis. One of the handy features of the htaccess file is that we can invoke server-side modules. We can use the mod_rewrite module to redirect or rewrite certain URL requests.

So to set-up our CMS, we need to rewrite all requests to any file on the server to ‘/index.php’. A first attempt at this might be:

# Turn rewriting on
Options +FollowSymLinks
RewriteEngine On
# Redirect requests to index.php
RewriteRule .* /index.php

This looks OK, until you think about what will actually happen. We’re redirecting ALL requests to ‘index.php’ – including requests to ‘index.php’… They call this infinite loopage in the biz’. Our next (and much better attempt) would be:

# Turn rewriting on
Options +FollowSymLinks
RewriteEngine On
# Redirect requests to index.php
RewriteCond %{REQUEST_URI} !=/index.php
RewriteRule .* /index.php

This will work well – unless you have things like images, stylesheets, JavaScript or generally any other files we’ve come to expect in a rich internet experience. We can fix this by also excluding requests to these filetypes from the rewrite:

# Turn rewriting on
Options +FollowSymLinks
RewriteEngine On
# Redirect requests to index.php
RewriteCond %{REQUEST_URI} !=/index.php
RewriteCond %{REQUEST_URI} !.*\.png$ [NC]
RewriteCond %{REQUEST_URI} !.*\.jpg$ [NC]
RewriteCond %{REQUEST_URI} !.*\.css$ [NC]
RewriteCond %{REQUEST_URI} !.*\.gif$ [NC]
RewriteCond %{REQUEST_URI} !.*\.js$ [NC]
RewriteRule .* /index.php

And there you have it! A (useful) .htaccess file used to redirect all requests to the index.php file! Now for that CMS…