We adore and despise, we wage wars and revolutions, standing up for undefined principals on the basis of morals. Our guidance and drive derived from powers we worship, by invented beings we can never see. We build shelters and raise families to subconsciously justify our birth.

We are, after all, just animals.

We lust for one another, pouncing on selfish moments to indulge in primal instincts. We hunt our food through glass jungles, nearly tearing one another to shreds over concepts of property and territory. We use the world around us, as it consumes us for its sustenance.

We are, after all, just chemicals.

Our interactions filled with entropy, as we dodge the masses moving in flows through the streets. We bind together to create things unknown, in as much as we tear each other apart for undetermined causes. We attract and repel derivatives of our kind for reasons we don’t ever bother to question.

We are, after all, just atoms.

Individuals, clusters of odd and mysterious masses with composition too complex to even consider, and our being too elemental to understand ourselves. Our properties unique, yet nearly powerless without complex interactions, we drift through space seeking influence as our halos rise and fall with forces we can’t control.

We are, after all, just dreams.

Tags: creative, writing

I saw this as an opportunity not to absolve myself of guilt, but to seize an opportunity to communicate with the higher ups, to let them know exactly why I felt my actions were justifiable, and even so, necessary:

Where to start; so many reasons, yet the textbox yields only so much space.

First off, the technological backing of this site seems to be comprised entirely out of dot matrix printers handled by minimum wage, half-blind alcoholics who will, on occasion, deliver a request to someone who can begin to service a reply.

Honestly, for what the competing social network sites have managed, even with asynchronous calls, you can’t seem to handle on a daily basis with the most straight forward GET-driven request. Your code base has sucked too many times to remain enjoyable, purely on the concept of being unresponsive and apologetic for its incompetence, but never repaired.

Secondly, the implemented spam filters, if any, are a joke, and I would consider further an abortion, when compared to any other such system. In the recent past my usage experience consisted solely of clearing my inbox of automated requests to check out her “hot new super profile,” then promptly logging out, because accomplishing much more involves dealing with your half-assed barely operational back-end architecture.

Thirdly, your profile editors are an invitation for unwarranted remote code execution on the negative side of the spectrum, and an enormous resource drain on the positive side, as the only people to ever use the feature are fourteen year olds bent on either world conquest via worm, or over-stylized hyper shiny multi-layer transparency.

In conclusion, your operation has gone from one of the leading social networks, to a virtual cesspool of garbage, and I see no turning back. If anything, I wish that you not cease, nor improve what you do. But keep on keeping on, hoping that you will continue to attract generations of half-witted teenagers who will at the very least, stay off the rest of the internet.

Posted here because, I’m told, it’s relatively interesting or entertaining to read.

Tags: myspace

A Recent Picture, originally uploaded by Muta.

I haven’t had a good recent picture, so I’m going to post this one as I figure it looks nice.

I’m in no way implying that I’m perfect, and that whatever this article shapes up to be should be the definition, or law of clear code, but the guidelines here are ones that I use, and so far have proven useful to me and those who have chosen to adopt them.

I will subdivide this article into headings describing issues I see as being problematic areas and either proposing a solution, or commenting on a situation where a solution may not be so clear cut.

Paragraphing

Much like in English, blocks of code are not monolithic entities, in several cases a single function or method does several things to accomplish it’s goal, and many times readability increases dramatically if these things are separated into logical sections by whitespace. For a totally out of context example consider the following block:

SomeClass scObject = new SomeClass();
scObject->gatherInformation();
if(!scObject->infoValid()) {
    delete csObject;
    throw new someException();
}
RandomStaticClass::transformObject(scObject);
for(scObject::someIterator scIter = scObject->begin(); scIter != scObject->end(); scIter++) {
    arbitraryFunction(*scIter);
}
return scObject;

Despite the hilarious naming, this simple block of code is pretty simple to understand. It creates an object, calls a method, verifies the information, performs some transformation then iterates something before returning the object to the caller. But in the reading of the code, there needs to be some concentration on behalf of the reader to separate these individual sections mentally before fully understanding their functions within the given context. In my opinion, and further in practice I find code in such close concentration more often than I care to count, and due to my already present mental breaking down of the sections I’ve chosen to adapt a practice of physically separating these sections into paragraph-like blocks based on function, transforming the above code, into the below code:

SomeClass scObject = new SomeClass();

scObject->gatherInformation();

if(!scObject->infoValid()) {
    delete csObject;
    throw new someException();
}

RandomStaticClass::transformObject(scObject);

for(scObject::someIterator scIter = scObject->begin(); scIter != scObject->end(); scIter++) {
    arbitraryFunction(*scIter);
}

return scObject;

The extra whitespace does nothing functionally, but it forces the separation of the logical sections for, in my opinion, easier reading.

Clever Only Commenting

The drive in programming has been for verbose commenting, and although I support this in most cases, such as documentation of methods and very complex sections, I don’t agree with the blanket statement, as the resulting code is far less readable than it could have been if comments were removed all together. I base my theory on the idea that people who write code are familiar with the language in which it was written, as well as with the science of software development in general. Like many people familiar with their field for developers many patterns are recalled instantly, and many algorithms are easily identified by their signature within a construct and any additional verbosity is simply noise surrounding signal.

To illustrate my point in psuedocode once more:

//Declare an integer
int i = 0; //It will be initialized to zero

//Loop 10 times
//Re-init i for style
for(i = 0; i < 10; i++) {
    doSomething(i); //Call doSomething() function with the current value of i
} //End of for(0..10) loop on i

//Create a new char pointer of size 10
char *cpBuffer = new char[10];
//Clear the section we just allocated
bzero(cpBuffer, 10);
//Pass the buffer to another method of a static class
//SomeStaticClass will use this buffer for subsequent static calls.
SomeStaticClass::setBuffer(cpBuffer);
//Return the buffer to the caller
return cpBuffer;

Although the volume and content of the comments seems almost comical, this example is not far removed from reality, mostly appearing in examples, but rarely making it to production code as well. My concern though, is not trivial even given these limitations, for if people are learning through such verbose examples there is a chance that it will considered kosher and used in projects outside the realm of hobby.

What I ask, is that the above code be compared to the code below by someone familiar with even the basics of the language:

int i = 0;

for(i = 0; i < 10; i++) {
    doSomething(i);
}

char *cpBuffer = new char[10];

bzero(cpBuffer, 10);

//SomeStaticClass will use this buffer for subsequent static calls.
SomeStaticClass::setBuffer(cpBuffer);

return cpBuffer;

Although the code is of trivial complexity, the verbose comments made very little impact on readability. In fact, I’m of the opinion that the latter example is much simpler to understand, and reads much faster than its comment-heavy brother.

The real point is that the second block is not stripped of all comments. The section passing the buffer to a static class is still prefaced with a comment explaining why the action is being taken. In this fictional example, that section of code stands out because its function is not as apparent as its surroundings, and as such it is explained with a simple statement.

This rule is harder to apply on a broader scale for several reasons. The use of “clever” blocks is relative to the skill and project familiarity of the team. Where seasoned developers can easily spot and track complex recursion, it may be considered clever by those who have not dealt with it constantly in a previous project, so the application of this rule may need to based on arbitrary set of standards which set the bar for what behavior is considered “clever” and deserving explanation, and by no means do I advocate the absence of full documentation on the project, including documentation of method actions, returns, and conditions. The statements I make here are touching only on comments made inline to explain small sections of code.

Variable Naming

A classic point, made in every single style guide I’ve ever seen, and yet still seems to be an elusive dream for the majority of functioning code on this planet.

As developers, we are not bound to the rules of algebra and as such are free to use variable names that exceed the scope of single letters. But simply giving a descriptive name does not solve the problem. As seen in earlier examples here, I’m a fan of hungarian notation, but even that can get far out of hand. Although a great idea, the concept of 10-odd letter prefixes are just as frightening as none at all, and as all good things should be used in moderation:

for(unsigned int uiTempIndexVariable = 0; uiTempIndexVariable < 10; uiTempIndexVariable++) {
    SomeStaticClass::updateDataIndex(uiTempIndexVariable);
}

As demonstrated, the abuse of this suggestion is more harmful than simply its omission, further the use of Hungarian notation is subject to taste, but my personal reasons revolve mostly around seldom visited regions of code. Given a block of code in which variable declarations are either at class scope, or are off-screen during an edit, type prefixes as well as descriptive names are a very useful reminder as to what can, and should be done with data, and despite the fact that you may be the original author, several months from creation the specifics of code drift from memory.

Yet as to most, there is an exception which I’ve demonstrated with the loop above. I see no point for short-scoped loop indexes, or return stores to have names more descriptive than ‘ret’ or the familiar set of ‘i, j, k, l’ and so forth. If a variable lives no longer than it’s declaration, or simply used in a tight scope the name is often times glossed over in reading, and this process should not be disturbed as it would aide in nothing but the degradation of reading speed with no benefit to clarity.

Useful Commit Messages

As a developer, one easily falls into a deep respect for source control. It will allow you to fix your mistakes, and to work on a team without the utter destruction of sanity, but even that wonderful system can be reduced to a useless heap of data with careless human intervention. As you should be familiar with, every commit to any source control system requires a “Commit Message” or a short blurb describing what changes have been made that made the commit worth happening. And as often the case, shortcuts are taken. Yet unlike all other areas of laziness, commit message shortcuts aid in no way to the reduction of work. Quite conversely, they add work to later cases.

Most reduced commit messages read with the finesse of statements such as “stuff” or “some changes” or even more often, yet equally useless “”, the blank string. But by using these non-informational descriptions work is created further down the line, when it comes time to decipher what “stuff” was changed, or what one was thinking when one changed the code to the tune of “”. And as most humans would agree, a one line message such as “Fixed typo in variable names” is much easier, and not to mention faster to read than a diff.

Tags: programming, c , code, style

Essentially, all the trackbacks orginated from a single provider: inhoster.com

This host, from the best of my understanding contains no legitimate customers, and serves only as a cover for countless spammers running an innumerable number of spam bots. Lucky for me, and potentially the metaphorical us the trackbacks originated from a very narrow host of addresses. After several attempts, and filtering with a moderation queue my current blocklist and moderation filter contain just three entries, which for your convinience I will post here:

85.255.114
85.255.119
85.255.113

Feel free to add these to your block lists, or at the very least your moderation filter to stop these potential bastards from wasting your juicy bandwidth.

Tags: spam, trackback, inhoster

Now, many books, articles and various other sources of information on the topic exist, so why should I create another one?  Mostly to blend the line beteen refference and tutorial, as well as intermix the topics of TCP/IP, which are essentially required knowledge for functioning applications.  But in reality, the only reason I’m writing this is for my own amusement, so if something comes from it, good for all, if not, then still good for me.  If during the course of this article, you notice a mistake, either technical, gramatical or pretty much any other case, please leave me a comment, I will review it, and while weeping silently for hours, correct it and attempt to bring honor back into my life.

So without much more rambling, we’ll move ahead to a definition of the problem at hand.

Sockets at its core, is an API that allows easy access to the networking components of your enviornment, in its distilled form a socket is just a file handle, but instead of being bound to disk I/O operations, it is directed to a different process, which may or may not reside on the same system.  To understand at least the fundamentals of this concept without getting into the details of low level IP frames as most books would, I will simply explain the relevant parts of this exchange.

As most are aware, most communication on modern networks takes place over IP, the protocol on which TCP, UDP and a short bus full of other acronyms ride.  This protocol defines what is called a “Frame” or a “Packet” in the header of this bit of data is relevant information about the source, destination, and various flags that may be set for a specific chunk of data.  I will cover this in detail in a later article, complete with a diagram, but for now we will only concern ourselves with the source, and destination addresses.

Those more in the know, without specific knowledge will begin screaming about “ports” which, at this layer do not exist, yet.

The source and destination addresses are 32-bit fields each (in IPv4, 128-bit in IPv6) which determine where this IP frame is going, and to whom the receiving host should reply.  The actual path the packet takes would be better described in a different article, as volumes have been written and millions have been made determining the answer to that question placing it far outside the scope of this introction.

On top of the IP frame, sit the aforementioned acronyms of UDP, TCP and several others.  It will be at this point, that I will break convention, and convinience and discuss the lesser known UDP.

UDP, or ‘User Datagram Protocol’ is a stateless and simple protocol with very light overhead.  It is with this that I will describe the importance of ports, before suddenly removing myself from the subject to lunge at the actual libraries and ritual incantations involved in getting a networked application off the ground.

The TCP and UDP protocols define what is known as a “port” on top (or more correctly, below) of the IP defined “address” to determine the final resting place of a frame of data.  Both protocals have a combination of a “source port” and a “destination port” fields, both 16-bits in length.

The reason for “ports” to reside on top of an existing address structure is to make multiple streams of communication possible.  While I find this often described with metaphors, I will leave the creative thinking to the reader, while I fall back on a plain and simple explanation.  On a host, there are potentialy very many streams of communication with one or many hosts.  While it is obvious, with the prior mention of a source and destination address, how a host may know from which remote host a packet arrived, it is a far more challenging problem to simply “guess” what the hell the remote host is on about in that specific packet.  The system of ports allows the trafic to travel to the host marked with a numeric representation of where it must go.  The received packet is filed into a specific port, which a program has opened for that specific application to process.

Now knowing the basics, I can introduce the first, and arguably most important data structure in use in socket programming. sockaddr_in.  It is defined in the <netinet/in.h> header and looks like this:

struct sockaddr_in {
    uint8_t sin_len;
    sa_family_t sin_family;
    in_port_t sin_port;
    struct  in_addr sin_addr;
    char sin_zero[8];
};

Knowing what we already know, some of those fields become obvious, but even in those lie quirks, and “historical reasons” so let’s go through them one by one:

uint8_t sin_len: This is the least annoying, and most straight forward of the fields, containing simply the length of the struct, this is usually set with a sizeof(struct sockaddr_in)

sa_family_t sin_family: This specifies the family of the socket, for almost all applications, this value will be set to AF_INET which covers TCP and UDP protocols, but in rare cases, which I wont cover unless I get to them, this value may be different. (IPv6 requires AF_INET6, but also requires a different structure because of the address size and other members, this may be covered in detail at a later article)

in_port_t sin_port: This is a 16 bit value in network byte order containing the port of this socket.

struct in_addr sin_addr This is the binary address of the remote host, a 32 bit value. This is also the first case of “historical reason.” If you note, this is not a simple type, but a struct. On the other side of the struct, is this gem:

struct in_addr {
    in_addr_t s_addr;
};

It is within this struct, that the value for the address is actually set in network byte order.

char sin_zero[8]: As the name implies, this field is filled with zeros.

Now if you’ve paid attention, you have noticed a mention of something called “network byte order.” This concept becomes very significant in this field as all computers communicating across a network expect it.

Network byte order may be better recognized as “big endian” byte order. This would not be such a problem, had byte orders been a standard among architectures, which is not the case. Intel machines use the oposite “little endian” order. The distinction is that numbers in excess of 1 byte in length are stored with either the highest order byte first (in the lowest memory location) in big endian, or the opposite in little endian.

While binary information can be sent across a network in the native byte order, you will run into problems communicating across different architectures that expect the byte order to be different, and will interpret the numerical data in a very different way.

The functions that exist to convert from native to network byte orders and back are defined along side with the rest of the sockets library in the header <arpa/inet.h>. These functions are as follows:

unsigned long htonl(unsigned long)
unsigned short htons(unsigned short)
unsigned long ntohl(unsigned long)
unsigned short ntohs(short)

They all follow the same naming convention, and follow the same rules of use. They accept an integer, either a long, or a short, and covert it into the same type, but in network byte order. These functions still exist on big endian architectures, but they do nothing. Even if you are writing your code on one of the big endian architectures and don’t forsee deployment on other architectures it is still good habit to use these calls.

The naming convention for the conversion function is as follows: h or n, stands for “host” or “network” byte order, where host is the native computer’s byte order, then the word “to” implying a conversion, followed by another, and opposite letter stating the order to convert to, followed by a letter specifiying wether the call will convert a short, or a long integer.

For example, let’s take htons():
It begins with an h, so it accepts the native or “host” byte order, and the final two letters are: ns. The fact that it would convert to network byte order is obvious, because it accepts the opposite, and because it notes so in the final two letters with the n and the type is specified with the final letter s which dictates that it accepts, and returns a short (16-bit) value.

Armed with all of this knowledge we are finaly able to fill out a full sockaddr_in structure. This is useful in several cases such as the bind(), connect() calls.

First, we have to define it. This is simple enough, we just declare it and give it a name:

struct sockaddr_in saPeer;

The next step, which is usually the easiest, and least painfull way to make sure sin_zero is filled is to zero out the entire structure. Adding a call to bzero() from <strings.h> will take care of this:

struct sockaddr_in saPeer;
bzero(saPeer, sizeof(struct sockaddr_in));

We also need to set the sin_len field to the size of the sockaddr_in structure. This accomplished simply by calling sizeof() with the type of the data:

struct sockaddr_in saPeer;
bzero(saPeer, sizeof(struct sockaddr_in));

saPeer.sin_len = sizeof(struct sockaddr_in);

And now we have to fill in the fields, the structure we’re filling now will be used to recieve a connection on port 9000 from any interface the host has available, so we will use a special constant: INADDR_ANY in the sin_addr field. When we cover writing a client, we will revisit this section to show how this structure is used in outgoing connections.

The first thing that we will set is the procol family in the sin_family field. The family you will be using most of the time for standard network applications is AF_INET. This family includes TCP, UDP and RAW sockets.

struct sockaddr_in saPeer;
bzero(saPeer, sizeof(struct sockaddr_in));

saPeer.sin_len = sizeof(struct sockaddr_in);
saPeer.sin_family = AF_INET;

Progressing down the datastructure, we can now set the address, and the port. Remember to use network byte order for values originating from the host’s architecture:

struct sockaddr_in saPeer;
bzero(saPeer, sizeof(struct sockaddr_in));

saPeer.sin_len = sizeof(struct sockaddr_in);
saPeer.sin_family = AF_INET;
saPeer.sin_addr.s_addr = INADDR_ANY;
saPeer.sin_port = htons(9000);

If you notice, I warned against using the host’s byte order while at the same time using a constant without passing it through an htonx() funxtion. This is because constants defined by the library are formatted to already be in the required byte order, and most of the time the contents of those constants are of no importance to people not messing with the actual TCP/IP stack of the operating system.

To review: In this section we see an explanation of the basic concepts required to grasp the construction of the base datatype in use, the sockaddr_in structure. We saw an overview of byte orders, and their role in network programming, and then using all of the collected knowledge built a sockaddr_in structure that could be used to write a network server.

In the next part of this series we will be picking up at this very point, and use the structure we constructed to write a simple echo server capable of accepting one client at a time.

Tags: network, bsd, sockets, programming

And now it’s back up on a new host, with everything that was ever here deleted.

Isn’t that FUN?

Update: Added tags, and LJ crosspost (HI!)

Tags: first, back, cyberwang