Visual MASM Windows Assembly IDE Sneak Peek Video

I just published a sneak peek video about my Visual MASM IDE for Windows assembly programming. Take a look and let me know what you think.


Visual MASM Windows Assembly IDE Sneak Peek

Visual MASM IDE for Microsoft Macro Assembler

Well, I decided to work on my Visual MASM for Microsoft’s Macro Assembler in my spare time. This will be a full featured IDE for assembly programmers. I published an IDE for assembly programming many years ago back in 2001 called VASM but I never finished it.

With Visual MASM you can create MS-DOS and Windows applications for 16-bit, 32-bit, and 64-bit Intel and AMD processors. Visual MASM looks & feels in many areas like the Delphi IDE or Visual Studio.

This will be an ongoing process and I will update it when I have time. Creating assembly programs for Windows is actually easier than MS-DOS applications since you no longer have to re-create the wheel(s) anymore because Windows has thousands of API’s available for you.

If you are interested in learning assembly programming and maybe find out why you would want to do that, run over over to my new website and check it out at http://www.visualmasm.com.

VisualMASM_screen01

AWS Summit

I’m planning on attending the 2014 AWS Summit on March 26th in San Francisco. Amazon has put up a great agenda. If you are doing cloud-computing and especially with the AWS services, you should attend. I will see you there.

How to turn on Long Polling on an AWS SQS Queue

The following code snippet will allow you to configure an AWS SQS queue for long polling using the ReceiveMessageWaitTimeSeconds attribute. For more information about Amazon long polling, see here:

http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html

// 5. Set Queue attributes
// The API Version 2012-11-05 of Amazon SQS provides support for long polling. (.net sdk v2)
// In the AWS console, you can verify in "Receive Message Wait Time" value of the queue
SetQueueAttributesRequest setQueueAttributesRequest = new SetQueueAttributesRequest();
List<Amazon.SQS.Model.Attribute> attributes = new List<Amazon.SQS.Model.Attribute>();
Amazon.SQS.Model.Attribute attribute = new Amazon.SQS.Model.Attribute();
attribute.Name = "ReceiveMessageWaitTimeSeconds";
attribute.Value = "20"; // 0 to 20 Seconds, default is 0
attributes.Add(attribute);
setQueueAttributesRequest.QueueUrl = queueUrl;
setQueueAttributesRequest.Attribute = attributes;
_sqs.SetQueueAttributes(setQueueAttributesRequest);

How to create an Amazon AWS SNS Topic and an SQS Queue that subscribes to it

Creating powerful cloud-based systems in C# and the .Net framework are possible for a long time now. Architecting a messages based cloud-computing solution that can handle millions of requests per day is not an easy undertaking but much easier when you use Amazon AWS services.

I recently needed to create an Amazon AWS SQS queue programmatically that subscribes to an SNS Topic that was also created programmatically. I could not find any examples in C# so I decided to post this code from one of my cloud-computing systems that I had designed and hope others find it useful. This particular code was used to test the dynamic nature of a messages based backend that can expand and contract the number of SQS queues based on how many active EC2 instances (nodes) in the cluster are available.

This code also shows how to create a policy for the SQS queue so that it will receive the messages from the SNS service. If you do not set a correct policy, the queue won’t receive any messages nor any exceptions are thrown.

Declaration code:

        private AmazonSimpleNotificationServiceClient _sns;
        private const string SNS_TOPIC = "YourTopicHere";
        private string _AWSSNSArn;

Core C# code:

            // 1. Create an Amazon SNS topic
            AmazonSimpleNotificationService sns = new AmazonSimpleNotificationServiceClient(RegionEndpoint.USWest1);
            _AWSSNSArn = sns.CreateTopic(new CreateTopicRequest
            {
                Name = SNS_TOPIC
            }).CreateTopicResult.TopicArn;

            // 2. Create the Amazon SQS In-Queue, will ignore it if it already exists
            AmazonSQS sqs = AWSClientFactory.CreateAmazonSQSClient(RegionEndpoint.USWest1);
            CreateQueueRequest sqsRequest = new CreateQueueRequest();
            sqsRequest.QueueName = General.IpAddressAWSFriendly;
            string queueUrl = sqs.CreateQueue(sqsRequest).CreateQueueResult.QueueUrl;
            GetQueueAttributesRequest getQueueAttributesRequest = new GetQueueAttributesRequest();
            List list = new List();
            list.Add("QueueArn");
            getQueueAttributesRequest.AttributeName = list;
            getQueueAttributesRequest.QueueUrl = queueUrl;
            GetQueueAttributesResponse response = sqs.GetQueueAttributes(getQueueAttributesRequest);
            string queueArn = response.GetQueueAttributesResult.QueueARN;

            // 3. Configure the Amazon SNS topic to publish to the SQS queue
            sns.Subscribe(new SubscribeRequest
            {
                TopicArn = _AWSSNSArn,
                Protocol = "sqs",
                Endpoint = queueArn
            });

            // 4. Set the queue policy to allow SNS to publish messages
            ActionIdentifier[] actions = new ActionIdentifier[2];
            actions[0] = SQSActionIdentifiers.SendMessage;
            actions[1] = SQSActionIdentifiers.ReceiveMessage;
            Policy sqsPolicy = new Policy()
                .WithStatements(new Statement(Statement.StatementEffect.Allow)
                                    .WithPrincipals(Principal.AllUsers)
                                    .WithResources(new Resource(queueArn))
                                    .WithConditions(ConditionFactory.NewSourceArnCondition(_AWSSNSArn))
                                    .WithActionIdentifiers(actions));
            SetQueueAttributesRequest setQueueAttributesRequest = new SetQueueAttributesRequest();
            List attributes = new List();
            Amazon.SQS.Model.Attribute attribute = new Amazon.SQS.Model.Attribute();
            attribute.Name = "Policy";
            attribute.Value = sqsPolicy.ToJson();
            attributes.Add(attribute);
            setQueueAttributesRequest.QueueUrl = queueUrl;
            setQueueAttributesRequest.Attribute = attributes;
            sqs.SetQueueAttributes(setQueueAttributesRequest);

Amazon AWS wins contract for CIA to host on AWS’ Cloud – Yeah!

I have been working with Amazon AWS Cloud web services since its beta introduction back in 2006 and still totally love it and use it today. When I heard about the news that Amazon won the contract to host CIA’s operations in the cloud, I was super excited and another confirmation that NO ONE knows cloud computing better than Amazon, not even IBM, the sore looser in the bidding process.

When it comes to service offerings and the rich capabilities and great SDK’s offered by Amazon AWS, Microsoft’s Azure, Google, IBM, and others do not come even close. Period!!!

http://techcrunch.com/2013/10/07/amazon-web-services-wins-again-in-battle-to-build-the-cia-and-nsa-cloud/

To get started, go to http://aws.amazon.com

The State Design Pattern vs State Machine

Background

Design patterns in software development are an essential tool to excellent software creation. Being able to identify patterns while observing source code, is an essential skill that is acquired over a period of years of object oriented software development practices. Over the years, I’ve seen patterns being implemented that only have the name of the pattern in file names but hardly represent the actual pattern the way they were intended to be used. Also, I have seen state machines being used instead of state design patterns at the costs of horribly complicated software that is hard to maintain. There is no reason to use state machines anymore when you are using an object oriented programming language.

One of the best sources about software design patterns is the “Design Patterns: Elements of Reusable Object-Oriented Software” book by the Gang of Four. Still, it is the bible of design patterns after all these years. There are many other sources and books but the blue book by the Gang of Four is the fundamental one that all seasoned architects and developers should have mastered.

Design patterns are programming language neutral. What they convey and solve are concepts that can be applied in any object oriented programming language such as C#, C++, Delphi, Java, Objective-C, etc. It is these concepts that one should master. Once the concepts are mastered, it is fairly straightforward to identify opportunities to use and apply them. At that point, it is simply a matter of language syntax.

In this article, I will discuss the State Design Pattern. I will discuss the state design pattern on how it can be used in a fairly complex scenario and demonstrating this with sample C# code. I will also discuss using the state design pattern instead of using a state machine. I will not go into the details of how to create state machines, rather I will concentrate on the much more modern State Design Pattern. I picked a complex scenario because I believe that a more complex scenario can teach several things at once. It will demonstrate the combination of different scenarios and answer more questions this way.

The State Design Pattern:

I would summarize the State Design Pattern as follows:

“The state design pattern allows for full encapsulation of an unlimited number of states on a context for easy maintenance and flexibility.”

From a business side of things, this is worth a lot of money. There is no reason anymore NOT to use the state design pattern even in very simple state scenarios. You can get rid of switch statements (C#), for example. It buys you flexibility because you won’t be able to predict the future and requirements changes (I’m pretty sure about that).

The State Design Pattern allows the context (the object that has a certain state) to behave differently based on the currently active ConcreteState instance.

Image

Let’s take a closer look into the parts that make up the state design pattern.

Context Object

Context is an instance of a class that owns (contains) the state. The context is an object that represents a thing that can have more than one state. In fact, it could have many different states. There is really no limit. It is perfectly fine to have many possible state objects even into the hundreds. It is coming to have context objects with only a handful of possible states, though.

The context object has at least one method to process requests and passes these requests along to the state objects for processing. The context has no clue on what the possible states are. The context must not be aware of the meaning of these different states. It is important that the context object does not do any manipulation of the states (no state changes). The only exception is that the context may set an initial state at startup and therefore must be aware of the existence of that initial state. This initial state can be set in code or come from an external configuration.

The only concern that the context has is to pass the request to the underlying state object for processing. The big advantage of not knowing what states the context could be in is that you can add as many new states as required over time. This makes maintaining the context super simple and super flexible. A true time saver and a step closer to being rich beyond your wildest dreams (almost).

State

The state class is an abstract class. It is usually an abstract class and not an interface (IInterface). This class is the base class for all possible states. The reason why this class is usually an abstract class and not an interface is because there are usually common actions required to apply to all states. These global methods can be implemented in this base class. Since you can’t do any implementation in Interfaces, abstract classes are perfect for this. Even if you do not have any initial global base methods, use abstract classes anyways because you never know if you might need base methods later on.

The State class defines all possible method signatures that all states must implement. This is extremely important to keep the maintenance of all possible states as simple as possible. Since all states will implement these methods signatures and if you forget to implement a new method, the compiler will warn you at compile time. An awesome safety net.

ConcreteState

The ConcreteState object implements the actual state behavior for the context object. It inherits from the base State class. The ConcreteState class must implement all methods from the abstract base class State.

The ConcreteState object has all the business knowledge required to make decisions about its state behavior. It makes decisions on when and how it should switch from one state to another. It has knowledge of other possible ConcreteState objects so that it can switch to another state if required.

The ConcreteState object can even check other context objects and their states to make business decisions. Many times, an object may have more than one context object. When this happens, a ConcreteState object may need to access these different states and make a decision based on active states. This allows for complicated scenarios but fairly easy to implement using the state design pattern. You will see an example later in this article that shows multiple context objects and their states and the need to work together.

The ConcreteState object also is capable of handling before and after transitioning to states. Being aware of a transition about to happen is an extremely powerful feature. For example, this can be used for logging, audit recording, security, firing off external services, kicking of workflows, etc. and many other purposes.

The ConcreteState object allows the full use of a programming language when compared to state machines. Nothing is more powerful in abstract logic and conditionals   coupled with object orientation as a computer programming language compared to state machines and their implementations.

As you add new methods to the abstract base class over time, each ConcreteState class will need to implement that method. This forces you to think from the point of view of the current state.

How should state ConcreteStateA react when this method is called?”

As you implement the behavior for a method, you can be rest assured that this is the only place in the entire system that will handle this request when ConcreteStateA is the active state. You know exactly where to go to maintain that code. Maintainability is king in software development.

Summary

To summarize, you will need a context and a few states that ideally derive from an abstract base class to create a flexible state solution. If you got switch statements or a lot of If statements in your code, you got opportunities to simplify by using the state design pattern. If you are using state machines, you got an awesome opportunity to simplify your code and safe time & money. Just do it!

Example

The example I created demonstrates the use of the State Design Pattern and how it can be used with multiple context objects working together. It is a fictitious hardware device with a door.

The device can be powered on or off. Specifically, the device has an operations mode that can be in the following states:

  1. Idle
  2. Busy
  3. Powering Down
  4. Powering Up

The door represents a physical door on the device. The door can be in the following states:

  1. Opened
  2. Closed
  3. Locked
  4. Unlocked
  5. Broken

To make it a little more complicated, the device can be in different hardware configurations. These configurations can be changed at run-time of the device. The following configurations are available:

  1. Production Configuration
  2. Test Configuration

The operation of the device depends on the different individual states as well as a combination of the states listed above. The more combinations that are possible, the more complicated it would be to maintain this using traditional Switch or If statements. You could use a state machine as well but it will not buy you the flexibility and ease of use when compared to the state design pattern. Feel free to add brand-new states and try to experiment with it.

Breaking it Up

No matter how complicated software projects are, the way to tackle them successfully is to break them up. This is especially true in object oriented software development. Breaking things up into smaller, manageable pieces allows a focused effort in understanding the problem domain. It is coming to zoom into the smaller parts and then zoom back out again to a 10,000 foot view and vice versa. You do this many times. Look at the big picture, then break up the picture into smaller parts, look at the smaller part and so forth. Object orientation is a natural fit to model real-life scenarios that contain things, people, processes and their behaviors to interact with each other.

Let’s break up the things that we do know in this example. It looks like we have 3 things:

  1. Device
  2. Door
  3. Configurations

Behavior

It is important to recognize that there is most likely a certain behavior between these things. This behavior is probably driven by certain business or operational rules. The power of object orientation is being able to capture this behavior inside classes. Since an object generally consists of roughly 50% data and 50% behavior, we must take care of the behavior part of objects. Over time, this behavior might change because requirements may have changed. Again, this is where object orientation shines when it is done correctly. 

TypicalObjectComposition

So, we can assume that Device is on its own. It represents a physical device from the real world. The door is part of the device and can’t live on its own. The device has a door. So, it looks like we have this:

  1. Device with a Door
  2. Configurations

We also have a set of configurations. These configurations change the operation of the device but are not necessarily part of the physical device. So, we could model configurations on a class by itself. However, since we know that a device can be either in a test configuration or a production configuration, these actually represent operational states. We also know that certain operations or states of the door might behave differently based on the current configuration. So, there is no need to create a separate configuration class and instead model the configurations as states themselves. If we decide to add another type of configuration later on, it will be easy to add.

We have two major parts: Devices and their configurations. We will model each part with their own class. The Device class will contain a Door class (Device has a door):

Both the Device and Door classes inherit from the DomainObject class. The DomainObject class is a convention that I’ve accustomed to use over the years. A base domain object class contains behaviors and features that are shared across all domain objects. For example, my DomainObject class usually implement a read/write string Name property. This name can also be optionally passed into the constructor. When you model real world things, it is very common that these things have names. So, I end up having a Name property in my base DomainObject class. You will see later how this is used.

Code

Let’s start writing some code and implement everything. The example we are building is a console application that sets several states to test the Device’s behavior. It will look like this once the output displays on the screen:

Image

First, lets create the DomainClass, the base class for all domain objects.

</pre></pre>
/// <summary>
 /// Base class for domain objects that provides basic
 /// functionality across all objects.
 /// </summary>
 public class DomainObject
 {
 public string Name { get; set; }

public override string ToString()
 {
 return Name;
 }

public DomainObject()
 {
 }

public DomainObject(string name)
 {
 Name = name;
 }
 }
<pre>

The DomainObject class implements a Name property of type string that allows you to conveniently give an object a name since most objects in real life have names. This is the base class for all domain classes.

Next, we implement the Device class. The Device class contains a Door object. In this scenario, the Device class is the context (the owner) to the operations mode and the possible configurations. The operations mode is represented with the ModeState class. The different kind of configuration states are kept track in the ConfigurationState class.

The Initialize() method is used to setup the different kind of states for the current instance of a device. This is the place where the context (the Device) now needs to be aware of what states are actually available. Notice also that within the method we are setting the operations mode to Powering Up and at the end of the method we set it to Idle.

</pre>
/// <summary>

/// The Device class is the owner of the different states

/// that the Device can be in. The Device is alos the

/// owner of actions (methods) that can be applied to the

/// states. In other words, Device is the thing we are

/// trying to manipulate through outside behavior.

/// </summary>

public class Device : DomainObject

{

// Device has a physical door represented by the

// Door class.

private Door _door;

&nbsp;

// Device only knows about generic actions on

// certain states. So, we use the base classes of

// these states in order execute these commands.

// The base classes are abstract classes of the

// states.

private ConfigurationState _configurationState;

// The current mode that the device is in.

private ModeState _modeState;

&nbsp;

public Device(string name) : base(name)

{

Initialize();

}

&nbsp;

public Device()

{

Initialize();

}

&nbsp;

private void Initialize()

{

// We are starting up for the first time.

_modeState = new ModePowerUpState(this);

&nbsp;

_door = new Door(this);

&nbsp;

// The initial configuration setting for the

// device. This initial configuration can come

// from an external configuration file, for

// example.

_configurationState = new ProductionConfigurationState(this);

&nbsp;

// The door is initially closed

_door.DoorState = new DoorClosedState(_door);

&nbsp;

// We are ready

_modeState.SetModeToIdle();

}

&nbsp;

public Door Door

{

get { return _door; }

set { _door = value; }

}

&nbsp;

public ConfigurationState Configuration

{

get { return _configurationState; }

set { _configurationState = value; }

}

&nbsp;

public ModeState Mode

{

get { return _modeState; }

set { _modeState = value; }

}

}
<pre>

The ModePowerUpState class is one of the ConcreteClass implementations of the State Design Pattern. Let’s take a closer look on how it is implemented.

</pre>
public class ModePowerUpState : ModeState

{

public ModePowerUpState(ModeState modeState)

{

Initialize();

this.Device = modeState.Device;

}

&nbsp;

public ModePowerUpState(Device device)

{

Initialize();

this.Device = device;

}

&nbsp;

private void Initialize()

{

Name = "Powering Up";

}

&nbsp;

public override void SetModeToPowerUp()

{

// We're in powerup state already

}

&nbsp;

public override void SetModeToIdle()

{

// Switch to Idle state

this.Device.Mode = new ModeIdleState(this);

}

&nbsp;

public override void SetModeToBusy()

{

// Can't set mode to busy, we're still powering up

}

&nbsp;

public override void SetModeToPowerDown()

{

// We're busy, but we allow to power down.

&nbsp;

// Cleanup any resources and then set the state

this.Device.Mode = new ModePowerDownState(this);

}

}
<pre>

The first thing to notice is that it inherits from the ModeState abstract base class. This would be the abstract base class for all mode states in state design pattern. The following operation modes are possible for this device:

  1. Powering Up
  2. Powering Down
  3. Busy
  4. Idle

Each of these possible modes are represented as individual ConcreteState classes.

An important fact is that one of the constructors takes an abstract representation of a mode: public ModePowerUpState(ModeState modeState)

This constructor is very important since it will allow the object to set the context (the owner) by using polymorphism. Setting the owner via:

</pre>
this.Device = modeState.Device;
<pre>

allows the pass in different kind of modes and always have access to the context. Once we have access to the context, this instance can now manipulate the Device’s mode. It can also manipulate any other properties or call methods on the Device.

Since the ModePowerUpState class inherits from the abstract ModeState class, it needs to implement all abstract methods that are declared in the ModeState class. The abstract ModeState class declares the the following abstract methods:

</pre>
public abstract void SetModeToPowerUp();

public abstract void SetModeToIdle();

public abstract void SetModeToBusy();

public abstract void SetModeToPowerDown();
<pre>

The ConcreteClass ModePowerUpState only needs to actually implement the methods that would make sense. Here the Idle and PowerDown state would make sense.

Lets look at the states for the Door of the Device. Remember that the door can be in the following states:

  1. Open
  2. Closed
  3. Locked
  4. Unlocked
  5. Broken

The abstract State class for the door states looks like this:

</pre>
public abstract class DoorState : DomainObject

{

protected Door _door;

&nbsp;

public Door Door

{

get { return _door; }

set { _door = value; }

}

&nbsp;

public abstract void Close();

public abstract void Open();

public abstract void Break();

public abstract void Lock();

public abstract void Unlock();

&nbsp;

/// <summary>

/// Fix simulates a repair to the Door and resets

/// the initial state of the door to closed.

/// </summary>

public void Fix()

{

_door.DoorState = new DoorClosedState(this);

}

}

The possible states are represented in the abstract methods:

</pre>
public abstract void Close();

public abstract void Open();

public abstract void Break();

public abstract void Lock();

public abstract void Unlock();
<pre>

We can also find a global base method named:

</pre>
public void Fix()
<pre>

This Fix() method is meant to be called by any of the derived ConcreteState classes in order to bring the Door to an initial Closed state (when it has been been fixed after it was broken).

When you download this example source code, you can take a closer look at all files. But, let’s take a look at the more interesting DoorUnlockedState concrete state class:

</pre>
public class DoorUnlockedState : DoorState

{

public DoorUnlockedState(DoorState doorState)

{

Initialize();

this.Door = doorState.Door;

}

&nbsp;

public DoorUnlockedState(Door door)

{

Initialize();

this.Door = door;

}

&nbsp;

private void Initialize()

{

Name = "Unlocked";

}

&nbsp;

public override void Close()

{

// We can't close an already locked door.

}

&nbsp;

public override void Open()

{

// Can't open a locked door.

}

&nbsp;

public override void Break()

{

// To simulate production vs test configuration

// scenarios, we can't break a door in test

// configuration. So, we need to check the

// Device's ConfigurationState. We also want to

// make sure this is only possible while the

// device is Idle.

//

// Important:

// ==========

// As you can see in the If statement, we can

// now use a combination of different states to

// check business rules and conditions by simply

// combining the existence of certain class

// types. This is allows for super easy

// maintenance as it 100% encapsulates these

// rules in one place (in the Break() method in

// this case).

if ((this.Door.Device.Configuration is ProductionConfigurationState) &&

(this.Door.Device.Mode is ModeIdleState))

{

this.Door.DoorState = new DoorBrokenState(this);

}

}

&nbsp;

public override void Lock()

{

this.Door.DoorState = new DoorLockedState(this);

}

&nbsp;

public override void Unlock()

{

// We are already unlocked

}

}

Take a close look at the Break() method. This is where it gets interesting and demonstrates the use of more than one set of states that are not related to each other. In this case, the state needs to check that the device is in a certain configuration as well as in a certain operations mode before it can set the door state. In order to access these conditions, the state needs access to both contexts,

Because this scenario only allows to break the door when the device is in a production configuration and the operations mode is idle, both conditions are verified by using the state class definitions:

</pre>
if ((this.Door.Device.Configuration is ProductionConfigurationState) &&

(this.Door.Device.Mode is ModeIdleState))

{

this.Door.DoorState = new DoorBrokenState(this);

}
<pre>

By simply chaining class definitions in your comparisons, you get clean compile time validations when compared to string or similar comparisons. The code is fairly easy to read and to expand upon.

Remember that one of your goals is encapsulation when you use object orientation. You have one central place to maintain your code for a certain state that you need to modify or when you need to create a brand new state.

Conclusion

Using a State Design Pattern over Switch and If statements and over State Machines is a powerful tool that can make your life easier and save your employer time & money. It’s that simple.

You can download the source code here. (https://s3.amazonaws.com/StateDesignPattern/DeviceWithStateDesign.zip)

About the Author

Thomas Jaeger is a Solutions Architect and an industry expert for over 21 years in 7 different industries when it comes to software development in general, cloud-based computing, and iOS development. He is a passionate, fanatic, software designer and creator. He lives against the status quo because, in his opinion, creative and innovative solutions are not created following a linear approach but come, in part, from broad experiences in ones life and from an innovative mind. 

B7 Tool Update – Backup on Amazon S3 and 7-Zip

I updated my B7 tool for Amazon S3 and 7-Zip. You can now create buckets and upload files. You can still use it as a command line tool as well. I also re-did the user interface to what I believe a more user friendly version. This tool is free. Please let me know what you think.

Download B7 here.

To get started with Amazon S3 storage, click here.

B7 - Backup to Amazon S3 and 7-Zip

B7 - Backup to Amazon S3 and 7-Zip

The HTML5 Hype vs. Native Application Performance (Again)

The latest buzz is all about HTML 5 and how it will improve our lives as architects, developers, companies, consumers of HTML5 applications and whoever else is getting sucked into this.

I’ve been doing professional software development for over 21 years now.  Over those years, I’ve used many different technologies. HTML 5 is just another “technology”. First of all, let me clarify in simple terms: HTML 5 is NOT a new technology. HTML 5 is based on existing technology called JavaScript, CSS 3 and HTML. None of these are new. What is new is the way it is being presented and marketed.

You see, I take the stand of delivering the best user experience to the consumer. What I mean by best user experience is this:
1.    Your users should “love” to use your software
2.    Your users should feel connected to your software
3.    Your software should accomplish what it said it would do for them, all the time
4.    Your software should do all things extremely fast
5.    Your software should look and feel top notch and professional, nothing less

As you can see from the list above, there are emotional connections between great software and their users. When you have human feelings involved with something as technical as software, you have subjective views on what great software means depending on who you ask. In addition, since most software is created for consumers, you will have to deal with emotional connections of your software and the consumers. You cannot afford to ignore your consumers’ feelings and perceptions of your software.

When you look at the industrial industry, physical objects such as a piece of furniture, a toaster oven, a recording device, etc. have aesthetics to them that triggers an emotional connection between the consumer and the physical object. Some consumers like a particular furniture and some others don’t. But, what is common between the different types of consumers is that they have a emotional connection or not. They like or don’t like a certain type of couch, for example. The design efforts that went into creating a successful piece of furniture maybe based on many factors.  Great designs are aesthetically pleasing and functional at the same time.

For example, look at the success of the iPhone or iPad. Here are devices that not necessarily have brand new technology inside them; but, they are packaged and presented in a way that is aesthetically pleasing to a lot of consumers. Moreover, they perform really fast and do it well all the time (disclaimer: nothing is perfect).  They both feel snappy. They both are easy to use and the content layouts (the user interface) are well thought out. They both are a total hit for Apple.

What would the iPhone or iPad be like if it had an Android or a Windows user interface? Would it still be a hit? Would consumers still love them? Would they buy them? Even worse, what if, both, the iPhone and iPad only had a Web Browser interface? How would consumers have reacted with their purchasing power?

What the iPhone and iPad have both in common is “fast” user feedback. This fast user feedback is, for the most part, is accomplished with native applications that take advantage of the device’s hardware. By native applications, I mean applications that are compiled into machine code for ultimate performance. In case of iPhone and iPad applications, this means that these applications have been developed with Objective-C on the Cocoa framework for iOS.

I’m certain that Steve Jobs had his hands in the user interface design decisions. I’m also certain that he would NEVER accept slow performing applications. If this is the case, I agree with Steve Jobs 100%. I agree because I believe that performance of software is even more important today than it was 20 years ago.

Software is created for people, most of the time. Consumers are spoiled with instance gratification. Consumers expect software to be fast. Consumers expect to get results, fast! People have less time and are doing more at the same time. Slow performing software is bad quality software, period. As a software creator, why would I want to settle for bad quality software? If you create the best software and want to make a living at the same time, you must create software that allows consumers to feel that emotional connection.

With that being said, when I hear things like HTML 5, I see Deja vu. I have seen this with Java, Visual Basic, .Net, ActiveX, Silverlight, etc.
These “new” technologies were created for many reasons and not one of them was created with the consumers in mind. These technologies such as HTML 5 were created with the intention to make things easier for the developers and the companies these developers work for.

The more abstract these technologies are, the more layers there are between the device and the output or user interfaces. The more layers there are, the slower the performance of the software. This principle has not changed in decades no matter how fast the hardware becomes.

At the end, the consumer can clearly see a difference in natively compiled software that was created for that native operating system and software that has these layers of translations that made it so simple for the developer.

This convenience for the developers costs dearly for the company who is selling the software in the long run. If a company truly cares for its target audience, then they better make sure that the emotional connection between the software and the consumer exists. The best way to do this is not to go the easy and lazy route but go the extra mile and develop the software in a computer programming language that has a native compiler. I can think of C++ or Delphi, for example.

Update 2012-04-09: Betting $1 Billion On Instagram, Facebook Backs Away From HTML5

http://www.sfgate.com/cgi-bin/article.cgi?f=/g/a/2012/04/09/businessinsiderbetting-1-billion-on.DTL

Backing up with 7-Zip compression and Amazon S3 with the B7 Tool

There are cases when I want to automate backing up certain file and folders with 7-zip but never found a good tool to do so. There are plenty of backup systems out there. I just want to backup a folder, compress it with 7-zip, and then send it off to Amazon S3 as the backup medium. All this automatically and on a regular basis.

So, I created my own backup tool to do just that. I call it B7 for “Backup with 7-Zip”. You can run this tool via command line only to automate the process. If you do not specify any command parameters, the Windows GUI will display. In the GUI mode, you can see all of your Amazon S3 buckets (folders) and their contents. You can do simple management of these buckets and bucket items.

B7 is still work in progress and I may make changes and improvements as time goes on and if I have time available to do so. I hope you find this tool useful. It surely helped me with managing some simple backups.

Download B7 here.

To get started with Amazon S3 storage, click here.

B7 Main Screen

B7 Tool

IMPORTANT:
==========
Make sure you update B7.ini with your access and private keys from Amazon S3 before using B7.

Usage
=====
To run B7 via command line parameters, do this:

B7 bucketName folderAndFilePattern [outputFile]

bucketName = the name of the Amazon S3 bucket where the backup file should be uploaded to
folderAndFilePattern = the full path e.g.: C:\APPFOLDER\DATA\*.*
[outputFile] = the compressed output file (optional). If you do not specify an output file, a unique backup file is created for you. It looks similar to this: 2012_01_25_11_38_F00684EE-6C03-4462-885F-4A6B2E95DE48.7z
The output file can be opened with 7-Zip or any other tool that supports the 7-Zip compression.

Follow

Get every new post delivered to your Inbox.