It is probably a very familiar scenario for many who dabble in the open source realm, but still, when you start helping other developers solve other problems for other clients a thrill is involved. This is, in essence, the spirit behind The Kitchen.

Catching Up

For the uninitiated, jQuery is an open source javascript library that makes selecting and manipulating objects on the page dead easy, especially if you are used to CSS selector syntax. Scroll Follow is a plugin for this library that enables a DOM object to follow the page as the user scrolls.

We first released this plugin back in May. With the launch of The Kitchen I've been able to open a dialog with several of our Scroll Follow users expressing interest in moving the script on to bigger and better places and we're thrilled at this development (pun intended).

I was skeptical at first. It's not the kind of design solution I would often use. That's why there is a "kill switch" parameter. Hopefully though, by improving the script and using it judiciously, we can add value for users.

Coming Soon

We will soon be releasing version 0.3 of Scroll Follow. In this release I've added a user-requested parameter. Before, the animation was always relative to the top of the user's viewable area, but no longer! You will now be able to key off of the bottom of the window as well as the top.

I have also improved the logic in the script to try to keep the CSS fiddling to a minimum. We want Scroll Follow to work straight out of the box. . . or zip file as it were. To that end we are issuing a call for help! We are looking for a few good, or at least bored, individuals to help us test the current release candidate so we can squash any remaining bugs.

This is not a daunting task! What we need more than anything are the test cases we haven't thought of. It seems the simple things are what cause breakages most. We're sure you can do simple and we're hoping you can do breakage. Are you up for it?

Michael Phelps is a phenom, an athlete to whom few comparisons can be made. And, at the recent Beijing Olympics, Phelps went a perfect eight-for-eight in his swimming events. Eight races. Eight gold medals. Perfect. Well, sort of.

Constraint

Michael Phelps cannot hit a major league fastball. He can't hang on the track with Usain Bolt or tap out Anderson Silva. Michael Phelps is not the world's strongest man and he cannot leap tall buildings in a single bound. I bet he can't even put together a website. Irrelevant.

We don't care about these caveats because no one has ever suggested that he be anything other than a swimmer. Phelps stuck to the pool. He might have chosen other paths and become a good swimmer and a decent professional cheese grater, but then he wouldn't be selling mobile devices on national TV. He'd be grating cheese. We wouldn't be talking about him.

To be perfect you have to pick something to be perfect at. You must have constraint.

This is difficult for two reasons:

1. You want to do a lot. You want to make websites and multi-function dry-erase boards. You want to be a rancher and drive an Aston Martin. You want to be a star and have a private life. It's not a problem to have multifaceted interests but honestly, perfection takes an extreme level of commitment. If it didn't, I'd have more examples to use.
2. You don't always know at the start what you will be good at or even enjoy doing. This is an important point. Few people have the constitution to put perfection-level effort into something they don't derive some sort of pleasure from.

Effort

Effort is easy … to explain. Effort is what you give. It is what you sacrifice towards whatever perfection you are chasing. Phelps gave most of his life. He gives so much in training that he eats a 14,000 calorie a day diet and is still skinny. He gave most of his Olympic experience; for the first week, he did almost nothing but eat, sleep, swim, and interview.

Effort is hard to maintain for any number of reasons: distraction, boredom, disaster, monetary incentive. Anything that diverts focus is an enemy to perfection and since achievement takes so much effort you're going to face many enemies along the way.

Luck

Luck is the polar opposite of effort. Luck is effort's evil stepbrother or fairy godmother depending on what side of it you are on. Luck is what you get for free whether you want it or not.

Michael Phelps got the anatomically perfect swimmer's body. A too-big torso and too-short legs. Over-sized hands and feet and widely articulating shoulder and ankle joints. I'm not a swimming expert, but they say if you were going to build a swimmer this is what you would ask for. Yes, his level of effort is extraordinary, but his natural advantages put him over the top.

Of course, luck is often a matter of perspective. If Phelps had decided to pursue a career as a professional curler his physical proportions would be of little help to him. If you have been paying attention, you realize that we just made our way back to constraint which leads me to this overly simple conclusion:
Intelligent Constraint = Managed Luck.

Definition

The final yellow brick on our road to perfection is the most ethereal. You might say it's a cop-out or you might say it's intrinsic to our discussion. I'm saying it's going to come up.

I don't know the man, but I suspect he doesn't consider himself perfect. I doubt he thinks his Olympic performance was perfect. In fact, he looked disgusted after winning the 200 meter butterfly during which his goggles filled up with water. He said afterward (paraphrasing), "I think I can go faster." To the rest of the world, however, his Olympics were perfect and that is because the rest of us defined perfection differently.

Definition is the goal we are striving for. It is the metric we are going to test our accomplishments against and if you're doing this thing right you'll never achieve your own definition. That doesn't matter really. Putting all that effort into a properly constrained goal means you can achieve perfection in the eyes of others, if you're lucky.

Currently Image Plane posts saved data to URL via the HTTP POST method. Currently Image Plane posts the entire Base64 encoded image (after transformations), but when designing the example class I had to account for the fact that I might have to someday support just a list of transformations (for the server to duplicate rather than receiving the entire image again). I also would have to support more than 1 output engine (despite the fact that I myself would just be using GD).

In designing my interface I like to make a quick list of operations and objects I will be expected to perform (no, this isn't a waterfall document, the list can be broad but I need a general idea of where I'm going):

1. Set a filename (and by proximity, output directory and type)
2. Select an output engine (either for performance reasons or simply support)
3. Constrain image sizes
4. Set certain image options (JPEG quality, possibly PNG transparency)

Now since I know I needed to support multiple output engines, I'm guaranteed to use the Adapter pattern. So now we have to split up our tasks among two classes.

Since our Adapter classes will each be very different internally (since they have to emulate and mimic features with different libraries) we'll want to keep them as small and clean as possible. Stepping through the list above we can see that 3 and 4 are obviously a best fit for our Adapter class since they deal directly with the actual image processing. All 2 really happens to be is a setOutputEngine(Adapter_Interface $engine) type method, however you can make it fancier by accepting a string for the engine and finding and instantiating the engine manually, but that's implementation side. Item 1 could be construed as belonging with the image processing but in reality it does not. Setting the output location and type is universal to all libraries, infact it really has nothing to do with image processing.

So we have a nice delegation of tasks to our objects we can start building. First things first, after creating our main shell class we create an interface (since things are so wildly different amongst image processing engines there's not much we can replicate so an interface will work better here as opposed to inheriting an abstract class) for our Adapter class.

The adapter class is going to need to do a few things. Specifically its going to need to load from a string (base64 encoded), set a few options (preserveTransparency and setOutQuality, for jpegs), and save the image data.

<?php
interface ImagePlane_Output_Interface
{
	/**
	 * @param string $data base64 encoded image
	 * @return ImagePlane_Output_GD fluent interface
	 */
	public function loadFromString($image);
 
	/**
	 * @param bool $bool
	 * @return ImagePlane_Output_GD fluent interface
	 */
	public function preserveTransparency($bool = true);
 
	/**
	 * Only really used for JPEG
	 *
	 * @param int $quality
	 * @return ImagePlane_Output_GD fluent interface
	 */
	public function setOutQuality($quality);
 
	/**
	 * @param string $outFile output location
	 * @param string $type Image type
	 * @return bool
	 */
	public function save($outFile, $type = ImagePlane::TYPE_JPEG);
}
?>

In our primary class we are probably best splitting up the outfile into 3 separate segments. We should force good filenames by making the user put in the output directory, output name, THEN output type. This way we can easily fix our filenames, check directory problems, and enforce output type (and proper extensions) without having to hack through pathinfo results only to find the user specified some weird extension for a type that we didn't account for. Plus this leaves us open to in the future specifying multiple output files without having to include directories on all them, or specifying multiple output types again without having to retype the entire filename.

<?php
class ImagePlane
{
	/**
	 * ImagePlane is passing in final transformed image via base64 POST
	 */
	const INPUT_POST = 'post';
	/**
	 * CURRENTLY NOT IMPLEMENTED BY IMAGEPLANE
	 */
	const INPUT_TRANSFORMATIONS = 'transformations';
 
	//Image Types
	const TYPE_JPEG = 'jpg';
	const TYPE_PNG = 'png';
	const TYPE_GIF = 'gif';
 
	/**
	 * Output engine
	 *
	 * @var ImagePlane_Output_Interface
	 */
	protected $outputEngine;
 
	/**
	 * Output directory
	 *
	 * @var string
	 */
	protected $outDirectory = null;
 
	/**
	 * Output name (without extension)
	 *
	 * @var string
	 */
	protected $outName = null;
 
	/**
	 * Output type
	 *
	 * @var string
	 */
	protected $outType = null;
 
	/**
	 * Create new ImagePlane instance using a certain output engine
	 *
	 * @param ImagePlane_Output_Interface $outputEngine
	 */
	public function __construct(ImagePlane_Output_Interface $outputEngine)
	{
		$this->setOutputEngine($outputEngine);
	}
 
	/**
	 * Set the image output directory
	 *
	 * @param string $directory
	 * @return ImagePlane fluent interface
	 */
	public function setOutDirectory($directory)
	{
		if( !is_writable($directory) )
		{
			throw new Exception("Output directory is not writeable");
		}
 
		$this->outDirectory = $directory;
 
		return $this;
	}
 
	/**
	 * Get the image output directory
	 *
	 * @return string
	 */
	public function getOutDirectory()
	{
		return rtrim($this->outDirectory, '\\/');
	}
 
	/**
	 * Output filename (without extension)
	 *
	 * The filename is automatically stripped of any characters other than 'A-Z',
	 * '0-9', '_', and '-', and are replaced with a dash.
	 *
	 * @param string $name
	 * @return ImagePlane fluent interface
	 */
	public function setOutName($name)
	{
		$this->outName = preg_replace("/[^[:alnum:]_-]+/", '-', $name);
 
		return $this;
	}
 
	/**
	 * Get the output filename (without extension)
	 *
	 * @return string
	 */
	public function getOutName()
	{
		return $this->outName;
	}
 
	/**
	 * Set output type.
	 *
	 * Valid options are:
	 *  - ImagePlane::TYPE_JPEG
	 *  - ImagePlane::TYPE_PNG
	 *  - ImagePlane::TYPE_GIF
	 *
	 * @param string $type
	 * @return ImagePlane fluent interface
	 */
	public function setOutType($type)
	{
		if( !in_array($type, array(self::TYPE_PNG, self::TYPE_JPEG, self::TYPE_GIF)) )
			throw new Exception("Invalid Type");
 
		$this->outType = $type;
 
		return $this;
	}
 
	/**
	 * Get the output type
	 *
	 * Valid returned types will be:
	 *  - ImagePlane::TYPE_JPEG
	 *  - ImagePlane::TYPE_PNG
	 *  - ImagePlane::TYPE_GIF
	 *
	 * @return string
	 */
	public function getOutType()
	{
		return $this->outType;
	}
 
	/**
	 * Process ImagePlane input
	 *
	 * @param array $data
	 * @param string $type ImagePlane::INPUT_POST (default) or ImagePlane::INPUT_TRANSFORMATIONS
	 * @return bool
	 */
	public function process($data, $type = self::INPUT_POST)
	{
 
	}
 
	/**
	 * Set output engine
	 *
	 * @param ImagePlane_Output_Interface $outputEngine
	 */
	public function setOutputEngine(ImagePlane_Output_Interface $outputEngine)
	{
		$this->outputEngine = $outputEngine;
	}
 
	/**
	 * Get the output engine object
	 *
	 * @return ImagePlane_Output_Interface
	 */
	public function getOutputEngine()
	{
		return $this->outputEngine;
	}
}
?>

You can see that on my set* functions I return the $this variable. This is called the fluent interface, and it allows you to make calls like $object->method()->method()->method(); which makes for compact, and in some cases, semantic code.

You can see that spending just a little bit of time we now have an easily alterable utility class to process uploads from Image Plane with a very low footprint for the actual end user:

<?php
require_once '../php/imageplane.php';
spl_autoload_register(array('ImagePlane','autoload'));
 
$imagePlane = new ImagePlane(new ImagePlane_Output_GD());
 
$imagePlane->setOutDirectory(dirname(__FILE__))
                ->setOutName("IPOutput")
                ->setOutType(ImagePlane::TYPE_JPEG)
                ->process($_POST);
?>
 

Now obviously this literal code snippet presents security issues but they can be tackled. Firstly the above code snippet can easily be moved inside an if block checking for authentication credentials (like an $acl->isLoggedIn() or similar), as well as checking for tokens via the otherData input variable as described in the documentation.

Stay tuned, hopefully I'll be posting more in the future on OO design and provide more complex design topics in the future.

In the mean time if you want an excellent, classic book, I suggest you grab a copy of Design Patterns: Elements of Reusable Object-Oriented Software by The Gang of Four.

This post is cross-posted from my personal blog here.

Already, ambitious adversaries are attempting alternatives to Net Perspective's achievements. But a better brainchild beats them back. Certainly, counted among our cleverest creations is the contemporary cropping tool Image Plane. Don't doubt its dynamic to deliver image data directly to any dedicated web server. "Effortless easy", "An extremely elastic edifice", are a few expressions elocuted to its excellence. Forget forever those foolish, fidgety, and fragile ways of fielding full size images and find this fresh flash file. Graciously, give it a go.

Handling how Image Plane output is sized, (width and height) is wholly in the hands of heady developers; however, happy admins have a hold on how images are cropped. Imagine Image Plane implemented into any internet admin system, and it becomes an invaluable instrument to even inexperienced individuals. Just a juicy gem.

Kindly, visit the kitchen and kick it around. Likely, you will love it's light file size, even though many tools and manipulators allow you to make multiple output images. Net Perspective knows the needs of nerdy developers and designers, and our hours of occupational labor originate from our own need for cropping options. Practicality is what put Image Plane into practice and pushes the Net Perspective team to perfect its potential. Quite quickly our quality creation will become the quintessential control to your quiver. Rest assured that reliable support remains ready to registered purchases. So seriously consider securing your copy from our store. Thank you for taking the time.

Use this new utility well and you'll usually underestimate its usefulness. Verily a vast vocabulary reveals the veritable verdict to its versatile variform output. Xhosa to Zanzibar will set aside xenophobia to examine this Xanadu. We wish that you are willing to welcome it. Your yearly yields may yet convince you.  Zealots who reach zen know this is no zeitgeist it is an image zooming zion, so zip on over.

Stale: Bad for Bread AND Books

My lack of satisfaction derived from the absence of dynamic figures in the book. I won't get into spoilers, but it is hard for me to imagine living through such a fantastic series of events and being totally unchanged in character.

A good story is one that focuses primarily on the people (vampires, trolls, ants, whatever). The events that unfold are important, but not nearly as important as the life-changingness of these events on our heroes. This same principle should always apply to designers.

Opportunities

One of the interesting side effects of working in the web industry is the broad education we receive from the variety of clients we work with. (I know far more about extracting oil from the ground than is probably strictly necessary.) We are given golden opportunities every project to produce a new product for a new client. Constant reevaluation is crucial to simply stay with the curve.

At the end of it all, when one project is finished and a new one is about to begin, are you the same designer you were? Have your new educational experiences expanded your understanding of your craft? In short, have you changed? If not, you may not be doing your job.

Beginnings

Net Perspective is currently located in Systek Computing on Texas Avenue in College Station, Texas. For those of you not familiar with College Station, it is home to the main campus of Texas A&M University. How did Net Perspective come to reside in a studio in Systek Computing?

Systek Computing is an IT firm formed back in 1999, from which time the company had offered web design as an additional service to many of its existing clients. Never had web design been taken seriously until myself, Carol Paull, coupled with my colleagues R.A. Ray and Daniel Cousineau joined the web development team. In 2008, we decided to branch off our web development services into a new company, Net Perspective LLC.

Branching Out

Net Perspective has become a vital web presence agency here in the Brazos Valley offering our services to local companies in addition to businesses in Houston, Austin, even to San Francisco. We really need an office space to accommodate the growth of our business and brand ourselves in the community.

Tired of the façade of buildings here in College Station, we don’t want to be in just another center. We want our office space and the building we are in to represent our unique style and youth. So our silent investors decided to purchase an empty lot close to our current home to build that eclectic architecture.

Luckily Net Perspective web development team is composed of talented individuals Ryan Bland, Jim Gibbs, and of course R.A. Ray who have all had formal training in design and architecture. With their skills and input coupled with working with an architect of our choice, I’m sure we will be able to design a building that leaves a mark here in College Station and represents our style. So check back from time to time to get an update on the progress of our new home.

A Case Study in Failure

What follows is a picture taken outside of our College Station office. It is also an example of a failure at both ends of the creativity wealth spectrum.

The failure here began long ago, before the parking lot was even completed. Whether it is the fault of the painter of the lines, the constructor of lot itself, or a law-maker that callously dictated strict widths I am unable to say. Nor does it matter. The fact is that someone in the chain lacked the brain flexibility to properly dimension and we were left with this bastard half-space.

Someone had a creativity deficit. Or, more likely, someone refused to spend some creativity to solve this obvious problem. After all, what is creativity but the ability (or process depending on context) to apply a solution to a given problem?

Unfortunately, sometimes creativity gets in the way of applying the appropriate solution. Our intrepid friend above certainly was able to solve his little problem but few, I think, would consider the result 'appropriate'.

Get A Context Clue

Our example is innocuous to be sure, but to me it is a visual reminder of a very common challenge to designers. As people who choose to work in an industry where liberal expenditure is expected we must always be cautious not to let what we want to say get in the way of what our clients need to say.

This guy doesn't think we should impose contextual constraints upon ourselves:

And to see such talented [designers] jump on the bandwagon created by boring blogoholics, who care more about the words on a page than how it actually looks, is pathetic.

Interesting. I was under the impression that what is said and how it is presented were irrevocably intertwined. In fact, I'm enamored of the idea. When it comes to designing for the web, context is everything. We must be judiciously applying our creativity to best affect the "words on the page."

In my time with Net Perspective (and our previous existence), I've completely dreaded live deployment days because yes, they were full days. An entire day dedicated to waiting for FTP uploades to finish, chmod'ing directories (because Plesk hates me), setting up databases, and testing. All of this despite the fact that we do periodic staging deployments on the same server!

I guess a lot of thanks goes out to Pro PHP: Patterns, Frameworks, Testing, and More by Kevin McArthur. While this book felt more like a Zend Framework tutorial, it did provide a brief introduction to two utilities I use here at work. One of which we care is our focus for the moment: Phing.

Phing is a build environment based on Ant which should be familiar to those in Java world. For those not familiar, Phing uses XML based build files with tags representing tasks and task groupings. At Net Perspective, I use Phing build scripts for everything from packaging up tarballs of utilities we've published (simple jQuery plug-ins, etc.) to automating the live deployment of client sites. I'm particularly happy with the latter as my deployment time has been reduced from a few hours to between 10 minutes max (for a brand new, fresh upload) and about 30 seconds (for an update).

Basic Phing usage is pretty self explanatory, however you may wish to search Google for Phing tutorials or read my post linked above.

Furthermore, my build scripts make use of custom command executions requiring both the execution environment to be *NIX based and for you to read this article on using rsync over ssh without a password (using pre-shared keys).

Setup

I start out with 2 files: build.properties and build-live.xml. I separate live deployment from the default build.xml Phing uses as, even though I harp on automation, live deployments should be manually triggered.

The file build.properties will be our configuration. If you set it up right, you can use the same script for all your projects as long as you alter the build.properties file accordingly. In it I create a few keys that will be necessary.

copy.live.dir=/path/to/site/on/remote/machine
 
copy.live.chmod="${copy.live.dir}/any/directory"
 
copy.live.chown=user
copy.live.chgrp=group
 
db.live.host=localhost
db.live.user=localuser
db.live.pass=localpass
db.live.name=localdb
 
progs.mysql=/usr/bin/mysql

You'll notice the properties copy.live.chown and copy.live.chgrp. A problem I encountered is Apache tends to get finicky about web file ownership, so I set this property to whatever user and group would be set after using FTP to upload. This way the final results of the build script will look as if you used FTP (but you didn't, because you're smarter than that).

With my build.properties set, I'll be begin with my build-live.xml. I start out with the basics:

<?xml version="1.0" encoding="UTF-8"?>
<project name="Local Project" default="dist" basedir=".">
       <tstamp />
<property file="./build.properties" />
</project>

The <tstamp /> initializes the ${DSTAMP} and ${TSTAMP} properties and the <property file="./build.properties" /> obviously includes our build.properties file.

Continuing along I create my default build target dist to just reference a few external targets:

<target name="dist" depends="copy,clean,chmod">
</target>

Upload

Now we begin the fun part, assuming you've already followed the link above about setting up a pre-shared ssh key, we can create our copy target which will be responsible for uploading new/changed files to the server:

<target name="copy">
       <exec command="rsync -aCz -e 'ssh -i /path/to/ssh/preshared/key' ${project.basedir}/path/to/local/files remoteuser@remoteserver:${copy.live.dir}/httpdocs/" escape="false" />
</target>

The key awesomeness is obviously our rsync command. Our particular variant contains the -C flag which ignores CVS/SVN type files (in particular, .svn folders) and omits the -v verbosity flag.

Cleanup

Next we need to build a clean target that will clear any compiled/cache directories, set ownerships, and generally clean house:

<target name="clean">
       <echo msg="Clearing Compiled..." />
       <exec command="ssh -i /path/to/ssh/preshared/key remoteuser@remotehost rm -rf ${copy.live.dir}/httpdocs/delete/contents/*" escape="false" />
       <echo msg="Changing PROJECT_STATUS to live..." />
       <exec command="ssh -i /path/to/ssh/preshared/key remoteuser@remotehost &quot;sed -r -i 's/define\(\W*''PROJECT_STATUS''\W*,\W*''(.+?)''\W*\);/define\( '\''PROJECT_STATUS'\'', '\''live'\'' \);/g' ${copy.proof.admin.dir}/path/to/config.file.php&quot;" escape="false" />
</target>

Here in our first exec task, rather than running rsync, we use ssh and our pre-shared key to run a command on our remote machine. In this case an rm -rf to clear our a particular directory (could be a /cache, /compiled, depends on your setup). In our second exec task you'll notice some uglies involving parenthesis escaping, however what we are essentially doing is running sed on the remote machine to flip a configuration value. What we do is maintain the configuration for all stages of deployment so that to change between the 2 or 3 stages it is just a single constant being changed.

Ownership

Finally we need to set ownerships of all the files so that Apache will play nice:

<target name="chmod">
       <echo msg="Setting Ownership..." />
       <exec command="ssh -i /path/to/ssh/preshared/key remoteuser@remotehost chown -R ${copy.live.chown}:${copy.live.chgrp} ${copy.live.dir}/path/to/dir/*" escape="false" />
       <echo msg="Setting Write Permissions..." />
       <exec command="ssh -i /path/to/ssh/preshared/key remoteuser@remotehost chmod 777 ${copy.live.chmod}" escape="false" />
</target>

Here we just use ssh and our pre-shared key to execute chown to match owner and group to that of what the particular site uses (or apache:apache) and to 777 certain folders (like upload folders, etc.).

Concluding Remarks

Using the rsync over ssh and one-line ssh techinques above you can do more complicated tasks like DBDeploy on a live server that denies external access to its databases (PROTIP: rsync the db folder, build.properties, and a copy of the build script containing the migrate task to a folder outside of the publicly visible httpdocs and use the ssh trick to invoke Phing and the migrate task).

If you have your application set up appropriately you can modify the upload tasks to have rsync use the --delete flag to ensure perfect synchronization (files deleted locally are deleted remotely as well). A caveat is if you do not ignore generated content directories (like user uploaded images), those will be deleted as well.

And finally, even if you dislike Phing as a build environment, since I'm manually passing commands you could feasibly convert all my commands to a simple .sh script or apply them to any other build environment you desire.

I Don't Live to Write, But…

The written word is probably the articulate human's most powerful tool for idea conveyance. Generally free as it is, in the best cases, from aesthetic bias, tonal slanting, and other trappings of the spoken word, these objective little marks have the power to influence ideas and ideals for centuries or even millennia. It's a wonderful system.

This isn't the world I live in really. In my world, someone else is usually doing the writing and my job is to get you to read it or buy it and, we hope, respond to it. My role is to help tell someone else's story.

This project therefore, is enormously cathartic. Here I get to tell my story, which really means our story, as much with the visually communicative as the textual. Designing for oneself is quite revealing and not a little autobiographical.

Setting Sail

The maiden design for this site is unlike anything I've constructed before. The layout is almost purely typographic, the inspiration for which comes in no small part via Jason Santa Maria's recent redesign of his own blog. Not that I'm trying to do what he is; our purposes are too dissimilar. But, that which is both beautiful and might someday be considered revolutionary should be lauded. So we laud.

And also we design, and develop, and build, and grow for these are the things for which we were reared. In time we hope to make this almost inherently obvious.

Company blogging is something I used to regard as a lame attempt of a marketing department to seem hip or cool. Engagement and actual interaction with their target audience was the furthest thing from their mind, as it seemed that these marketing people saw blogs as this magic new fad where potential customers came out of nowhere to read just because it was a blog. For a while this may have been partially true; however, these marketers soon learned their folly as traffic never materialized and their 'blogs' were poked fun at by the masses.

A few blogs stand as a shining example to corporate blogging. In these blogs I find frank discussions of marketing methods, internal insights to design and engineering decisions, and informative posts that not only help me in my own endeavors, but show off the competency and creativeness of the individuals that make up the company in question.

I wanted to show off too!

As a result, I'm proud to present to you the Net Perspective company blog. You can expect to hear from myself on programming and server side related issues, from R.A. Ray on design related topics, and you may even hear occasionally from our team on topics of interest.

For now you can follow us by subscribing to our RSS feed, or you can follow our company on a few social networks like Twitter, Plurk, Last.fm, and Facebook.