• GiveUpInternet.com — As it says on the site, “Give Up Internet is a Humor Blog for Internet People and Developers.” While it’s technically not a web development blog, I love the posts on this site. Unlike a lot of other “humour” sites that post stupid things a lot of the time, it’s got actual funny posts. It’s one of the only humour blogs that I’m subscribed to.
• The CSS Ninja by Ryan Seddon— This is a great blog about nice little tricks that can be done in CSS. One of its focuses is doing things that previously required JavaScript, in pure CSS (no JavaScript whatsoever). This includes cross-browser CSS-styled checkboxes, a lightbox in pure CSS, and an easy way to preload images using CSS2.
• David Walsh’s blog — David is one of the core MooTools developers, and as such, he blogs mainly about JavaScript, and occasionally some PHP snippets. While, in my opinon, his posts on PHP are often messy , his posts on JavaScript are excellent.
• AdequatelyGood.com by Ben Cherry — If you’re interested in JavaScript (especially the nitty gritty of its internals), this is by far the best blog on the topic that I’ve seen. Ben has written detailed articles on a lot of unique features of JavaScript, including scoping and “hoisting”, and how it handles object to primitive conversions.
• Hallvord R. M. Steen’s blog and the Opera sitepatching blog — Hallvord is a developer for Opera Software. His blog covers the state of the web as it unfortunately is at the moment – Broken browser sniffer scripts, standards violations, and just general scripting stupidities. Things are definitely improving, but there’s a LOT of broken scripts out there. Opera has a file called “browser.js” that contains patches to make these broken sites work correctly in Opera. Hallford’s blog (and the Opera site patching blog) detail the things that Opera does to patch these broken sites. There have been some very interesting posts, including the horrible XML and XSLT on the Israeli rail website, how Google Docs used to print documents, and many others.

That’s all for now… I might eventually write another blog post like this. Or a proper blog post

Until next time,
— Daniel

The Bad Old Days

So where do we begin? In the old days, JavaScript wasn’t used very much at all. Browsers didn’t really support much JavaScript, so it was only used to add little bits of functionality to sites. The one site might have had a few little procedural functions for the whole site. Global variables were used everywhere, but as the scripts were very small, this wasn’t too much of an issue. Usability also wasn’t considered much of an issue, and there was no proper event model, leading to things like:

<a href="javascript:DoSomething();">Do something</a>

However, the JavaScript of today is something very different — It is everywhere, and is used for more than just trivial uses. On a normal website, a large amount of JavaScript might be used. Nowadays we even have web applications like Gmail and Google Docs which contain heaps of JavaScript for all their core functionality. There are a lot of web applications that are mainly client-side, with a very small server-side component. Because of this use of large scripts, we can no longer rely on unorganised scripts and use of global variables as in the past. Scripts written using these techniques of the past become very unmaintainable very quickly. Additionally, usability is a bigger issue today than it used to be, mainly due to the number of users on the Web (many of which have disabilities and require sites to be accessible).

So what can we do to improve our JavaScript? Well, let’s first see how we can neatly organise our JavaScript using…

Object Literal Syntax

You might be thinking, “what the heck is object literal syntax”? Simply put, it’s a simple syntax for creating a JavaScript object, added with the release of JavaScript 1.2 in June 1997. Here’s an example of an object created with this syntax:

var MyObject =
{
	myVariable: 123,
	hello: 'world'
}
alert(MyObject.myVariable) // alerts "123"
alert(MyObject.hello)      // alerts "world"

See? Pretty simple. It’s a lot like a hashtable in other programming languages (such as C#, Perl, and arrays in PHP). One of the great things about JavaScript (and a feature that differentiates it from some other languages) is that you can store functions inside variables. We can use this to our advantage:

var MyObject =
{
	myVariable: 123,
	hello: function()
	{
		alert('Hello world ' + this.myVariable);
	}
}
 
MyObject.hello(); // alerts "Hello world 123"

See what we can do? Instead of having variables functions laying around all over the place, we can group them together into objects. This is a similar idea to namespaces in other languages, and is probably about the closest equivalent in JavaScript. When coding a site that uses JavaScript, my personal approach is generally to make one object per unique page that uses JavaScript. This keeps things nicely organised, and makes each page’s functions and variables self-contained.

Of course, we can also use proper classes to hold reusable components, but this is outside the scope of this post and will probably be covered in a future post .

Another modern technique is unobtrusive JavaScript…

So what is unobtrusive JavaScript?

In a nutshell, unobtrusive JavaScript is a coding technique that separates JavaScript from HTML in the same way that CSS is separate from HTML. Basically, with unobtrusive JavaScript, you have no JavaScript in the HTML at all, except for the <script> tag that loads the script file, and maybe a <script> tag to run an initialisation function. This means no onclick=”whatever()” attributes on any of your HTML elements. How do we add JavaScript click actions, then? Easy — Event handlers!

When using unobtrusive JavaScript, the JavaScript initialisation function “connects” the event handlers to all elements that need them. JavaScript event handlers are similar to that in other languages — Stuff throws events (such as click, mouseover, etc.), and functions can be set to run when these events are thrown. Previously, this was a little annoying, as Internet Explorer uses a different syntax to other browsers. However, today, there is no excuse, as JavaScript frameworks (such as MooTools and Prototype) and libraries (such as jQuery) make it really easy.

Another feature of unobtrusive JavaScript is that it involves progressive enhancement and graceful degradation. If the JavaScript doesn’t run (ie. if the user has JavaScript disabled), the user’s experience will still be acceptable. Maybe not as good as if they had JavaScript enabled, but still usable. We don’t rely on JavaScript, but we do take advantage of it if it’s available.  This usually involves adding event handlers (as mentioned above) that override the default action for links (that is, go to the URL they link to).

You might be confused by now (seems I ramble a lot in these posts), so let’s quickly jump to an example HTML file that shows some of the things we’ve mentioned so far:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<title>JavaScript Test</title>
	<script type="text/javascript" src="mootools-1.2.4-core-yc.js"></script>
	<script type="text/javascript" src="script.js"></script>
	<script type="text/javascript">window.addEvent('domready', UserList.init);</script>
</head>
 
<body>
	<table>
		<thead>
			<tr>
				<th>Username</th>
				<th>Tools</th>
			</tr>
		</thead>
		<tbody>
		</tbody>
			<tr id="user-1">
				<td>Daniel15</td>
				<td><a href="/user/1/delete" class="delete">Delete</a></td>
			</tr>
			<tr id="user-2">
				<td>Bob</td>
				<td><a href="/user/2/delete" class="delete">Delete</a></td>
			</tr>
			<tr id="user-3">
				<td>Mark</td>
				<td><a href="/user/3/delete" class="delete">Delete</a></td>
			</tr>
		</tbody>
	</table>
</body>

As you can see, absolutely no inline JavaScript, just some script loading, and setting the UserList.init method to run when the page loads. If JavaScript is disabled, clicking any of those “Delete” links will take the user to the corresponding delete page linked with the <a> tag. What happens if JavaScript is enabled? Let’s see! Here’s the corresponding JavaScript file:

var UserList =
{
	init: function()
	{
		// Connect up all the delete links
		$$('a.delete').addEvent('click', UserList.del);
	},
 
	del: function()
	{
		var user_id = this.getParent().getParent().id.substring(5);
		alert('Delete user ' + user_id);
		// Make sure the link doesn't go anywhere.
		return false;
	}
};

This is written using MooTools, but you could achieve a similar thing with another framework/library such as Prototype or jQuery. MooTools is just what I use

Notice the init function “connects” the delete links to the delete JavaScript function (which I named “del”, “delete” is a reserved word in JavaScript). So, when you have JavaScript enabled, instead of going to the URL specified in the link, the UserList.del method will be run. This example just pops up an alert box, but this could easily be changed to use an AJAX call to delete the user. See? Magic! It’s fully functional with JavaScript disabled, but JavaScript being enabled adds a lot of niceness.

And yes, I know, that script is messy and could be made better, it’s just an example.

Conclusion

In this post, I’ve shown how to use object literal syntax to group JavaScript functions and variables together, and unobtrusive JavaScript techniques to progressively enhance pages. The advantages of doing so include neater and more maintanable code, and graceful degradation if JavaScript is disabled (not possible with <a href=”javascript: … “> links. There might eventually be a follow-up post.

Hope this helped you

Until next time,
— Daniel

People in the first group:

• Have done their main programming study at University or TAFE OR are self-taught with just the basics, generally nothing about best practices. Generally, they’ve learnt just enough to get by, nothing more
• Will copy and paste code and be happy that it works, but might not really understand how it actually works
• Don’t really consider programming a hobby
• Might be considered “code monkeys” in some situations
• Generally need help with fixing odd bugs

And people in the second group:

• May have done a University course, but their main learning is self-taught
• Write applications, scripts, websites, whatever for fun (and might actively participate in open-source projects)
• Don’t copy and paste code very often. Instead, they learn from other people’s code, and then rewrite that code in their own style
• Consider programming one of their biggest hobbies
• Aware of some of the latest trends in software development
• Might often question things, like the ways people do things, and why code is written in a specific way (or is this just me?). Usually I do that just to learn how things are done.
• Can generally investigate and solve odd bugs pretty well

Anyone else agree with me? Personally I’m proud to be in the second group, the awesome group

Anyways, I’ll write another proper blog post, eventually. I started working recently, and will definitely have to blog about that

Until next time,
— Daniel

Now, let’s begin looking at what OOP actually means. At its core, the Object Oriented paradigm consists of classes and objects. A class is a “thing” or entity that has a purpose, and an object is an instance of this entity. For example, a Car would be a class, and my car would be an object (instance of the Car class).

Classes in C#

Before we can cover any of the OO principles with code examples, we need to go through some very simple code. A class in C# is made using the class keyword:

public class Car
{
	// ...
}

The “public” is an access modifier. The available access modifiers for classes in C# are:

• public – No restrictions on accessibility of the class. It can be used from anywhere.
• private – Can only be accessed by code in the same class.
• protected – Can only be accessed by code in the same class, or in a derived class (see inheritance, below).
• internal – Can be accessed by any code in the same assembly (basically, the same file), but not from another assembly.

Methods in the class are specified like this:

public virtual void StartCar()
{
	// ...
}

Like above, public is an access modifier. The virtual keyword means that this method can be overridden in child classes (this is explained under “inheritance” below). “void” is the return type. A method that returns void basically returns nothing (the same as void in languages like C#, or procedures [as opposed to functions] in Pascal and Visual Basic). Some common return types include string, int, uint (unsigned int), long, ulong, float (Single-precision floating point number, 4 bytes) and double (Double-precision floating point number, 8 bytes)

Core OO principles

With all that said, let’s jump into the core OOP concepts. There are three “pillars” of OOP; these are the core principles of Object Oriented Programming. These are Encapsulation, Inheritance and Polymorphism. In addition to these, there are several other core ideas.

Abstraction

An abstraction is basically an idea, something that we think about to simplify things. In our car example (which will be used throughout this portfolio), a Car is an abstraction.

Encapsulation, Inheritance and Polymorphism (the pillars of OOP) are all abstractions.

Object Composition

Object composition is basically a way to combine simpler objects into larger, more complex ones. This is known as a “has-a” relationship. For example, a Car object might contain an Engine, Wheels, etc. We don’t need to know how all these other smaller objects work, but only how to interface with them (this is directly related to Encapsulation, see below).

Encapsulation

Encapsulation is the “hiding” of internal details of a class. This makes the class “friendlier”, and hides all its internals from the user. For example, a “car” class in C# could look something like this:

public class Car
{
	public virtual void StartCar()
	{
		// Do whatever the car needs to do to start
	}
 
	// More class members here
}

We can use this class without knowing exactly how it starts the car, just that it starts it:

Car myCar = new Car();
myCar.StartCar();

This also ensures that code outside the class can’t access data that it shouldn’t be allowed to touch. Allowing free access to all fields (values that the object “knows”) could lead to data corruption, as the object could be in an unknown state. For example, the car could have a field that says how much petrol is left in its petrol tank. We want the car to know how much petrol is left, but we don’t want other classes to be able to just change this value. In C#, we use private variables for this purpose:

public class Car
{
	private int _petrol;
	// ...
}

We could then have a property to access this, and choose to only have a getter (no setter) for it, meaning that it can only be read:

public class Car
{
	private int _petrol;
	public int Petrol
	{
			get { return _petrol; }
	}
	// ...
}

Inheritance

Inheritance basically allows us to build new classes which are based on existing classes. The new (lower-level) classes inherit all the functionality of those above it, and can also add new functionality. For example, we cam make a SportsCar class that inherits from Car:

public class SportsCar : Car
{
	// ...
}

The SportsCar class will automatically have all the members that Car had (the petrol field, StartCar method, etc.), as well as any new members we define. To override a method in the Car class, we can use the override keyword. As long as the function is defined with “virtual”, this will work fine:

public override void StartCar()
{
	// ...
}

In fact, we could take this abstraction even further, and have a Vehicle class which the Car inherits from. Then we could have other vehicles (e.g. Bike, Bus, etc.) which all have common elements, and can be treated in the same way (polymorphism, described below)

Polymorphism

Polymorphism is the ability to access multiple different types of objects using the same methods. For instance, above, we defined SportsCar as a derived class of Car. We can treat SportsCar instances (objects) in the same way as we treat Cars, because the compiler knows that a SportsCar is a car:

Car myCar = new Car();
Car mySportsCar = new SportsCar();
myCar.StartCar();
mySportsCar.StartCar();

The two types of cars might start very differently, but they’re both called using the same StartCar method.

More OO stuffs

Constructors

A constructor is a function that’s called when an instance of the class is created. They’re usually used to set parameters at creation time. The constructor is a method with the same name as the class. For example, in our Car class, we could have something like this:

public class Car
{
	private int _petrol;
 
	public Car(int petrol)
	{
		_petrol = petrol;
	}
}

This means that when the Car class is created, we’d need to pass it one argument (not 0, not more than one).

Car myCar = new Car(100);

We can give a class more than one constructor. In this case, each constructor is differentiated by the number of parameters. If the class is created with one parameter, the constructor with one parameter is called. Same with if the class is created with two parameters, the constructor with two parameters is called.

public class Car
{
	const int DEFAULT_PETROL = 100;
	private int _petrol;
 
	// Default constructor
	public Car()
	{
		// They didn't pass a parameter, so assume defaults.
		_petrol = DEFAULT_PETROL;
	}
 
	public Car(int petrol)
	{
		_petrol = petrol;
	}
}

An example of using these constructors:

// This will create a car, calling the default constructor.
Car myCar = new Car();
// And this uses the constructor with one argument.
Car myOtherCar = new Car(50);

Interfaces

Interfaces are another core part of OOP in C#. An interface expresses a behaviour that a class may choose to implement. Unlike a derived class, any class may have as many interfaces as you like. For example, we could define a “IExplodable” interface:

public interface IExplodable
{
	void Explode();
}

This defines an IExplodable interface, with a single method (Explode). Interfaces are always abstract; we can’t create a direct instance of them. This means that we don’t use the interface directly, instead we have classes that use the interfaces. For example, we could make our SportsCar IExplodable:

class SportsCar : Car, IExplodable
{
	// IExplodable implementation
	public void Explode()
	{
		// ...
	}
}

This makes the SportsCar use the IExplodable interface.

We can treat anything that implements IExplodable in the same way (this is Polymorphism at work). For example, a function like this:

public void ExplodeIt(IExplodable thing)
{
	thing.Explode();
}

We can pass this any object that implements IExplodable:

SportsCar myCar = new SportsCar();
Bike myBike = new Bike();
Microwave mike = new Microwave();
Potato awesomePotato = new Potato();
ExplodeIt(myCar);
ExplodeIt(myBike);
ExplodeIt(mike);
ExplodeIt(awesomePotato);

Object design

Now that I’ve covered all the basics of object orientation, I thought I’d quickly mention some things about object design. There are several things that contribute to a good design:

• Don’t put all the functionality in the one massive class or method (“centralised”). Instead, spread the functionality across multiple classes and multiple methods. This eases development, makes testing easier (see unit testing, above), and also makes the code more reusable.
• Excessive coupling is not good, because it prevents the reuse of objects in other projects. Coupling refers to the degree to which each object relies on one of the other objects. If the objects all rely on each other too much, then changes in one will require a whole heap of changes in others, and they’re not as reusable.
• High cohesion is good. Cohesion refers to how strongly-related or focused the responsibilities of a single class are. If all the methods of the class tend to be similar, the class is said to have high cohesion. High cohesion leads to more readable code, and the likelihood of code reuse inceases. As an example, in the Car class, the methods (eg. StartCar, Drive, etc) all do something to the cat.

Culture

Talking about programming culture usually involves discussion of coding standards. Coding standards are important because we need to stay consistent throughout our code, so other developers are able to understand it. The main standards that are followed in C# (including those followed at Swinburne) include:

• Use an underscore at the start of private members of a class (e.g. _petrol in the examples above)
• Use camel casing for local variables and parameters. Camel Case is basically words stuck together, with each word except the first starting with a capital letter (e.g. myCar)
• Use pascal casing (like camel case, except with the first letter capitalised as well) for the names of Classes and Methods (e.g. Car, SportsCar)
• Use an I to prefix the names of interfaces (e.g. IExplodable)
• File names should be the same as the class name (e.g. Car.cs, SportsCar.cs)
• Use meaningful descriptive words for the names of variables, classes, methods, objects, etc. The names should be useful so we know what the class or method is without looking through all the code.

Well, that’s all for now. Hope this has helped someone

— Daniel

From the official Synapse site:

This project deals with network communication by means of blocking (synchronous) sockets or with limited non-blocking mode. This project not using asynchronous sockets! The Project contains simple low level non-visual objects for easiest programming without problems. (no required multithread synchronisation, no need for windows message processing,…) Great for command line utilities, visual projects, NT services

“Installing” it

Firstly, you’ll want to download the stable release of Synapse, and place them somewhere. At the time of writing, the latest Synapse version is release number 38. Once you’ve downloaded it, extract the files somewhere (it doesn’t matter where you extract them to, as long as you remember the directory name. I’d suggest to create a directory for all your Free Pascal library code). Next, we need to edit the config file, so that Free Pascal can find these libraries. Open your Free Pascal configuration file (on Linux, this is at/etc/fpc.cfg. On Windows, this should be in the directory you installed Free Pascal to). Search for this:

# searchpath for libraries

Right before that, add -Fu followed by the path to the directory you made earlier. In my case, I added:

-Fu/home/daniel/fpc

Using it in your code

In most cases, you’ll be using the TTCPBlockSocket class. This is included in the blcksock unit, so add this unit to the uses clause of your application:

uses blcksock;

Example

Connecting to a server

This is probably the most common way you’d use a socket — Connecting directly to another server. The functionality for this is contained in the TTCPBlockSocket class. Firstly, we need to define a variable to store the socket in:

var
	sock: TTCPBlockSocket;

And then we need to actually create the socket:

sock := TTCPBlockSocket.Create;

This creates a socket named sock that we’re able to use. The next step is to connect to the remote server, using the Connect method:

sock.Connect('66.79.183.71', '80');
// Was there an error?
if sock.LastError <> 0 then
begin
	writeLn('Could not connect to server.');
	halt(1);
end;

At this point, the connection to the remote server has been established, and we may send and receive data.

Sending Data

Sending data is done via the SendString method. Note that this is slightly different to some other languages; it does not add a carriage return and linefeed to the end of the line, you have to add this manually if required.

sock.SendString('GET /blog/ HTTP/1.1'#13#10'Host: www.daniel15.com'#13#10#13#10);

Receiving Data

There are several methods for receiving data, but the two main ones are RecvString and RecvPacket. RecvString reads a single string (terminated by a carriage return and linefeed) from the socket, and returns this string without the carriage return. RecvPacket reads all data waiting to be read, and returns it unmodified (all carriage returns and linefeeds will still be there). Both commands take one parameter: A timeout. If the socket doesn’t contain any data within this timeout, it returns a blank string.

buffer := sock.RecvPacket(2000);

Putting it all together

Here’s an example application that connects to a web server, does a simple HTTP request, and writes the response to the console:

program TestApp;
 
uses
	blcksock;
 
var
	sock: TTCPBlockSocket;
 
procedure Main();
var
	buffer: String = '';
begin
	sock := TTCPBlockSocket.Create;
 
	sock.Connect('66.79.183.71', '80');
	// Was there an error?
	if sock.LastError <> 0 then
	begin
		writeLn('Could not connect to server.');
		halt(1);
	end;
	// Send a HTTP request
	sock.SendString('GET /blog/ HTTP/1.1'#13#10'Host: www.daniel15.com'#13#10#13#10);
 
	// Keep looping...
	repeat
		buffer := sock.RecvPacket(2000);
		write(buffer);
	// ...until there's no more data.
	until buffer = '';
end;
 
 
begin
	Main();
end.

The loop is needed because the data may come in multiple packets.

Not that this is not really a good example, as there’s a HTTP library built-in to Synapse. The in-built HTTP library has several advantages, including the ability to use HTTP proxies. Perhaps I’ll cover that in a future blog post