Demanding Dev

Saturday, May 12, 2012

Within this post, I am going to give the steps to get a node application hosting the express framework up and running on the Cloud9 IDE.

Sign up for a Cloud9 Account! It's very easy, simply go to cloud9ide.com, and click on the sign up button:

Do all of the rigmarole for setting up the account, and eventually you will get to your Cloud9 Dashboard:

Click the big green button on the left navigation pane, and select "Create a new Project," enter a project name, select your favorite source share/control site, and finally click the big green Create. I choose Git for this guide.

The project will take a few seconds to clone:*note* if it takes longer than a few seconds, refresh your browser, I have noticed Cloud9 can hang up while cloning the project.

Once the cloning is complete, select the project in the navigation pane, and within the edit pane, click the big green "Start Editing" button. It will open the project in a new window.

*note* If you get a half loaded page, close the window, and click the "Start Editing" button again. I have notice the initial loading of the editor has some strange issues, probably due to caches not being loaded fast enough for the page or something to that effect. If you are still having issues, try clearing your browser cache, and running your browser in anonymous mode.

We now run the following command in the console text box at the bottom of the IDE:

npm install express

You will see the package installation details in the console output, and if you refresh the project files navigation pane, you will now see a folder called node_modules, containing the express modules files.

This just sets up the use of express module. One problem is that while we have installed express, we could just manually create all of the view controller crap, but lets get express to template all that out for us:

Within the Program Files pane, drill into the node_modules\express\bin folder

Double click the express file to open it in the editor pane.

Click the Run button, and the form should auto populate with all of the details to execute the express site installer, EXCEPT the folder location you want to keep the site information in. I installed my site into ./DemandingDev :

*note* if you are still unable to run the express site installer from the run pane, rename the express file to express.js. hopefully this work around will not have to be used for long. (per some great people on the cloud9 team, thank you!)We now have an express node app almost ready, BUT we still need to install dependencies. npm has an awesome feature to install all dependencies for you.

To prepare for installing dependencies, run the following command to generate the json file describing all the dependent modules:

We now run the following command to install all the dependencies (AKA Jade templates module):

npm install -d

We have all the components now installed!

And now the last step to get this express application up and running on cloud9. We need to change the hard coded setting from listening on port 3000, to use the port provided via the process.env.C9_PORT environmental property:

With this port setting, we can debug the app.js file within your express project directory. Make sure it is the active file in the editing pane!

Click the Debug button, then click the link that pops up in the command window:

You now have a functioning express node.js project up and running. I will periodically verify these steps work, and update this blog post if anything changes. Feel free to comment if you see a problem with my steps!

Saturday, May 5, 2012

In my previous post, I discussed the last line of defense in your application, exceptions. throwing your own exceptions lets you as the developer say "Woah! I want to stop this before it fails spectacularly, leaving me an awful mess to clean up."

Thats well and good, but the best solution is to integrate your validation as closely to the user input as possible. The faster a user know's what they are doing wrong, the better. That's where user experience development and basic input validation truly shine.

Validation controls like RequiredValidator and RegularExpressionValidator can help with both server and client side validation.

WPF can be directly integrated with your exception validation, but I would recommend using the IDataErrorInfo. here is a great article that describes how to implement this feature!

Lastly, the best way to solve strange validation issues is to design your UI in a way that naturally leads the user to enter valid input. Most call this the funnel of success, but a great place to read more about how to design a successful UI, I highly recommend reading Jakob Neilson's http://www.useit.com/ site. It may not look pretty, but it's content is exceptionally helpful when trying to understand why a radio button list might be better than a drop down list, or when you should decide what UI should be displayed.

Always keep validation of inputs in mind no matter what layer of an application you are working on, because whether your user is a PEBKAC mashing their face against a keyboard, or a brand new developer who just doesn't know how your library works, validation is the way we convey to them, hey, ID10T: Something is wrong.

Friday, November 19, 2010

Guess this is going to be a two parter! in part I, I will be discussing how to protect your business logic by actively throwing exceptions when validating. in part II I will discuss the standard, more passive validation techniques not using exceptions.

When dealing with any class, you have values, and those values will be stored in a class within member variables. Those variables are usually basic data types, like strings, dates, integers, etc. For almost any member variable, there is a subset of all the potential values that datatype can contain that are actually valid.

Determining if a given value is within this subset of valid values is what validation is all about. In this blog post I will discuss an aspect of validation I do not believe is very clear; when to validate.

What I mean when I say "when to validate" I mean, when do you notify other parts of the code that the provided value is not within the acceptable subset of the provided data type. validation can occur:

When the value is assigned
This is usually done via a property or method that encapsulates the variable. The code attempts to provide a value to the class via it's property, and the property checks if its an acceptable value. If it is not an acceptable value, the code throws an exception describing why the value is invalid. Numerous objects use exceptions to reject invalid values. For example, when dealing with an index based collection, passing a negative index, will result in an IndexOutOfRangeException being thrown.

this sounds like a great answer for validation, but it should be used as a last resort or make sure that your classes member variables are always within an acceptable value range. Methods the receive parameters or properties that are used in mission critical classes should always check if the values outside of what you'd expect be handled in this way. I consider these types of validations as Active Validation. Below are a list of existing exceptions you can use for active validation:

*note* This type of validation should be considered your LAST line of defense. Why? the very definition of exception is that at that point in the code, you have an exceptional scenario, you can't complete what the code is attempting to complete! this is the only place you should be dealing with a validation issue with an exception.

I've read a lot of different WPF validation articles, and I've come to my own conclusion that the most simple, but also flexible solution is to use the combination of the IDataErrorInfo interface on my business objects, and use converters and simple data type validators for data type conversions.

That being said, I've notice a significant number of example classes have not implemented a very good ValidationTemplate! I've seen the following Binding statement in the majority of the binding template examples I've seen:

Path=(Validation.Errors)[0].ErrorContent

Can you see what is wrong with this statement? Its the index based access o the Errors collection! This type of binding won't effect the functionality. It will actually work fine, but if you watch the output window with the index accessing solution, you'll notice as soon as you enter a valid value (which should be most of the time!) an exception is getting swallowed by the WPF framework! (as shown below)

Thursday, September 30, 2010

I don't know about any of you, but I've seen a lot of different data access components in the last couple years. Some people swear by ORM (Object Relational Mapping) suites like nHibernate, or use the Enterprise Library's data access application block. I've used both, but my experiences with both have been mixed.

So, I've decided, I'll write my own! My core concept I have in mind is that for every base business object, you should have an abstracted data access object. this object should handle all standard operations, such as Creating, Reading, Updating, and Deleting the given object (also known as CRUD). It should also provide the ability to get that object as a collection. Each of these methods can be provided additional parameters similar to how parameters are added to a command object. Once a CRUD call is made, the parameters are cleared, so that that new parameters can be added for the next call.

To define this concept, below is the interface describing what I expect any of these data access components to look like: