Software lessons from a hybrid

About a month ago, I was in the camp of rolling my eyes at hybrids on the road. To me their motivation was to save the planet. Well, it’s a big planet and a few hybrids aren’t going to supplant the egregious impact of a single volcano’s eruption. But then I started calculating my monthly spend on gasoline. My oversized sport utility vehicle and my turbo-charged crossover were fun, but expensive.

It’s easy math; a hybrid with a pathetic 13-gallon tank can drive farther than both of my other cars combined. Even though nothing is really created equal, hybrids have advanced enough generations for most to be similar enough that the brand you buy is mostly preference and price. I do some serious driving, so I decided to treat this adventure like a science experiment.

The most Comprehensive Blend for Visual Studio training you will ever receive – for Free; you’re welcome!

November 2013, immediately after the release of Visual Studio 2013, I sat down for an all-day session with Unni Ravindranathan, the Senior Program Manager for Blend. Who better to walk through, not the new features of Blend, but all the core features of Blend – and the new features, too. In some cases, Blend for Visual Studio 2013 returned some of the features removed in Blend for Visual Studio 2012. But in many cases, it’s just candy tooling for the XAML developer.

Is this for you?

Do you want to see Blend in action and learn how to incorporate its bountiful power easily into your current projects? Windows 8 projects, you bet! Silverlight projects, you bet! Windows Presentation Foundation (WPF) projects, too? You bet! Blend is a tool for XAML developers, not just Windows 8 developers. In fact, in some cases, Blend does more for the Silverlight and WPF developer. So, enjoy.

Windows 8.1 design principles hand developers back their sanity

When the computer mouse was new, it was simple to use but unfamiliar to users. As a result, user manuals could not say “click the red X”. Instead, they had to say, “move the mouse on your desk to control the pointer on your screen”. The idea of the mouse was new – the conversation had to start several steps back. After the mouse was successfully socialized and established as an input modality, user manuals could confidently say “click the red X”.

Windows 8.1 says, “Forget all that Design Stuff from Windows 8.0”

WHAT DESIGNERS HAD BETTER KNOW ABOUT WINDOWS 8.1

Let’s be perfectly clear, the Windows Design Guidelines in Windows 8.1 are, at a high-level, identical to those in Windows 8.0. However, in their practical and tactical guidance they are so different, that idyllic Windows 8.1 apps would potentially fail Windows 8.0 Store Certification. These guidelines, now hardwired into Microsoft developers and designers, remain consistent and contrarian to the Windows 8.0 guidance.

Microsoft Design Principles

The 5 core principles of the Windows Style, or the Microsoft Design Principles are unchanged. They are: 1) Pride in Craftsmanship, 2) Fast and Fluid, 3) Authentically Digital, 4) Do more with Less, and 5) Win as one. They have not changed in practice or in theory.

Windows 8 Design is Calm

Across the Microsoft platform we have Windows Client, Windows Phone, Windows Server, Microsoft Xbox, and Windows Embedded. Each exists to address a specific type of device and user scenario. But what’s great is that each participates in the Windows Design Language.

What is the Windows Design Language?

The Windows Design Language is a set of principles that help designers and developers layout excellent apps and excellent user experiences. It drives consistency across apps and across the Microsoft platform. And, it is beautiful.

Note: The Windows Style varies from device type to device type. The Windows 8 style guide, for example, is only related to the Windows Phone style guide. It is not identical because the interface is distinct. Sometimes consistency is mistaken for uniformity. The flexibility within the Windows Style not only extends across device-types, but also to individual apps, letting developers innovate distinctive yet consistent apps.

Consider this image. It depicts four separate applications. Their UI is quite distinct. However, each of them has acute similarities that are prescribed by the Windows Design Language. In this case, specific to Windows 8, it is illustrating compliance to the Windows 8 Silhouette.

Windows 8 apps, what’s an Enterprise to do?

For decades, thousands of enterprises have run their business on custom, line-of-business systems. These can be Windows Forms, WPF, Silverlight, and even web-based Windows apps. These often include a desktop tier, some service tier, and a backend database. Millions, literally millions, of dollars have been invested into the creation and maintenance of these systems.

Should they all be rewritten?

Your first answer should be no, but that may not be your final answer. This is because no application should be rewritten without a compelling reason. Consider the development investment already made. Consider the user training investment already made. And, consider the deployment investment already made. None of that should be brushed away just because there’s a new, shiny toy. But there is more to consider than a simple version rev here. Windows 8 introduces new capabilities, new opportunities, and new scenarios that might turn your first answer on its head.

Ask this first

Use Expression Design to create a Windows 8 ‘Ratings’ control

If you are not aware of Expression Design, you are missing a powerful tool in your toolbox. Expression Design allows designers and developers to create original vector assets or edit existing, including those created in other tools (like those from Adobe).

An update to Expression Design 4 was recently released. You can download the June 2012 preview here. (learn more) As the capabilities of Design continue to bloom, in this article we’ll use the basic functions to create a vector-based ratings solution that anyone can add to their Windows application.

Windows 8: Making the case for Expression Blend

One of the coolest parts of the XAML designer in Visual Studio 2012 is that it is the same code base as the designer in Expression Blend for XAML. That’s right. Blend’s designer used to be better, but now Visual Studio developers are first class, too.

Windows 8: Does Metro even make sense to Microsoft Developers?

Metro is Microsoft’s design language. It is our specification for applications written for the Metro environment in Windows 8. But, fundamentally, it is our design language. What does that mean?

There is more to Metro than sharp edges and clean typography. Metro is a design language based on real design concepts, principles, and theory. Most of the documentation on the internet is explaining “what” Metro is – they are specifications. But there is very little on the “why”.

In a recent discussion with a colleague, we were discussing this. He started from a design point-of-view, understanding Metro’s core intents. I was trying to explain why engineers (like Microsoft developers) don’t necessarily understand why Metro is advantageous.

Mango Sample: Isolated Storage

Storing Windows Phone application data is a pretty normal requirement. If you want it to persist across sessions, or even phone reboots, you really have three options:

1. Save to the Cloud
2. Save to Isolated Storage
3. Save to Local Database

Each is right for certain scenarios. But in this article, I will ONLY walk through Isolated Storage. Isolated Storage is a file folder dedicated to your application. It’s size limited is the phone’s available space (be good). Interact with it like System.IO.Directory.

Common request: Can I read, write, or save to the Phone’s global folders instead of those specific to my application? No – get that into your head. Windows Phone doesn’t allow third-party applications to tinker with core phone asset.

Isolated Storage has two areas for you:

1. System.IO.IsolatedStorage.IsolatedStorageSettings This provides a simple name/value dictionary that serializes whatever you put in it. This might tempt you to put everything in it. But don’t. Use it for settings. If you have to persist objects, even small ones, use a storage file. Here’s an interesting discussion on use.
2. System.IO.IsolatedStorage.IsolatedStorageFile This gives developers a real File / Folder API. Organize objects into folders if you want. Then serialize your objects and save them to files. When your app restarts, they are still there. As a matter of practice, persist data as-you-go as it can take time (seconds) to save.

Side bar: Any data that you store in InsolatedStorage must be serializable, either directly or by using data contracts. No exceptions. More on contracts.

How to use IsolatedStorageSettings

Get the real code here.

How to use IsolatedStorageFile

Get the real code here.

Be sure to reference System.XAML.Serialization. This code is generic. This might be all you ever need for IsolatedStorage. Ensure path is unique for each object; otherwise, it’s that simple. Just copy, paste, and get programming.

Here’s a sample implementation:

Don’t Forget This

First: Any serializable object can be persisted to a file – large or small. Writing and reading will take time. Plan on this delay! The Phone will terminate applications if Load or Close take too long. So, Read outside of Load. And, Save along the way; keep Close fast.

Finally: There are many ways to serialize objects. You can use XML, binary, JSON, and much more. The choice is up to you. My samples use XML because it reliable, fast, and native. But, there’s nothing wrong if you pick another approach (for a reason).

Can WebForms run in ASP.Net MVC?

Let’s just jump to the answer: yes.

So, here’s my simple MVC project. I selected an “Empty” MVC project. I added my empty Controller/HomeController.cs (all the defaults, just add and close) and an empty Home/Index.cshtml view.

Is there a simpler MVC application out there? One controller, one empty view.

Then I added my /Sample.aspx. It just writes out the date. No changes to the configuration. No extra Attributes on the classes. Not a single change whatsoever. And does it run? Yes. Are their limits, possibly – but this answers the basic question I have heard developers ask.

Let’s take just a moment to discuss if this is a good idea.

1. I suppose it is possible that you already have built and tested WebForm assets. If they are stand-alone or independent, it might make sense to contain them in the MVC project.

Note: You always have the option to put them in a separate project and run WebForms like normal, but perhaps you are wanting to take advantage of a single-sign-on scenario.

2. If you are making the switch to MVC you might not be able to afford the development cost or time for your entire application. This might be another argument to mix technologies.

Note: In the end, this is all the ASP.Net framework. This is fundamentally why this works out of the box. However, adopting MVC is typically a pattern decision – and you should defend it.

Here’s my conclusion on this brief discussion. MVC is a fun way for developers who are sick of web development to have a new tool. It has some IoC and Unit Testing benefits, I realize. But a mixed environment can’t be a long term, ideal solution. But it’s a nice choice in the short term.

An Service Oriented (SOA), multi-tier implementation of the Microsoft Entity Framework (EF4) using WCF Data Services

Using the Entity Framework is Microsoft’s latest Data Access technique. Hopefully, they will settle on this one for a few versions. The version of the Entity Framework in .Net 4 is the first real version, if you ask me. The problems with predecessors are sick. Good work guys.

The Entity Framework lets you use LINQ syntax to access your data with a robust mapping engine to use across various data sources. LINQ allows you to create controlled, in-code queries against your data sources without requiring stored procedures or lots of code.

The Entity Framework allows you to, optionally, use code generated Self-Tracking Entities, for example, that have the ability to track their changes. Code generated entities allow you to introduce your own enhancements to the entities without worrying about screwing up the Entity Framework.

The Entity Framework allows you to break out the Model into a separate project, and your entities into a separate, reusable project.

Introducing ADO Data Services. It isn’t new, but now it’s native. It’s a WCF Service that enables LINQ queries on the client. Data Services isn’t super-documented right now. So custom query strings, and reusing entity types on the client isn’t straight forward.

There’s a bug in how types are reused on the client. And the techniques to use custom query strings and security in Data Services isn’t clear.

Data Services really lets you use a service oriented architecture with EF. But, to be fair, it even lets you use it with LINQ 2 SQL (LinqToSQL). LinqToSQL is not deprecated, but you should consider it deprecated in your own head. Just start using Entity Framework and thank me later.

Blah, blah, get to it already!

Okay, I hope these short screen casts help you. Let me know!

1. How do you create an EF model in a stand-alone, reusable assembly – and then consume it in a simple WCF Data Service?

Watch the video | Get the code

2. How do you extract the entities from the model, and move them to a stand-alone, reusable assembly – and then consume them?

Watch the video | Get the code

3. How do you use the Data Service and enable the service reference to properly reuse the entity types on the client?

Watch the video | Get the code

4. How do you introduce a custom SQL connection string when using a data service? Is it really this difficult?

Watch the video | Get the code

In case you wanted to know, I use VS 2010, and SQL 2008. I’m inside Windows 7 Ultimate, but I don’t think those details matter so much. I hope these casts help you. Honestly, I created them to help me remember the little tricks necessary to get it all to work – in six months ;)

Next to figure out: How to save data back to the database without an error?!

Then to figure out: Simple Security with Data Services

[Update 6/2/10] As the architect of our current project, I had to make the call to drop using Data Services. EF is just fine. The delays we hit trying to get simple tasks working killed us. Fortunately, we dedicated a sprint to validate Data Services. I believe, until the WCF team fixes the known Service Reference bug, Data Services is useless.

I asked:

1. Why can’t Data Services support the SQL [time] data type?
2. Why can’t Data Services have used Include(), like EF, instead of Expand()?
3. Why can’t Data Services’ Expand() use “Child.GrandChild” syntax like EF Include() instead of a just-to-be-different “Child/GrandChild” syntax?
4. Why can’t Data Services attach and update with EF syntax?
5. Why can’t I query against an Expanded child collection/navigation property?
6. Why can’t Data Services just work? There was so much promise!

Some of those gripes, to be fair, might be a result that ODATA was the result of a standards committee and, maybe, EF needs a little hit on the head instead. Uniformity, guys!

Also, I saw where WCF Data Services (actually ODATA) was written up in MSDN magazine this month (June 2010). The article never makes this point, but it’s clear to me based on my experience and the documentation and samples I see: ODATA is good as a simple “read” operations, but complex reading or simple writing isn’t where is should be. Not at all.

So, it’s “wait for Service Pack next” for us…

Stacking User Controls in WinForm applications

If this is not your current pattern, then reconsider your current pattern. This pattern is very reliable and well proven.

The idea is simple, your windows application has more than one screen to display to your user. You encapsulate functionality in user controls (typically better than a form – not always). You surface user controls to the user when they click a button or interact with the UI. Yes, it’s that simple.

How to you manage those controls in your application?

The Microsoft Patterns & Practices Composite UI Application Block addresses this in their Smart Client guidance (see here). But this is very out of date. And their block, though effective, is a lot of overhead for something you can manage in around 30 lines of code.

This has nothing to do with the event model or command pattern. Both of those are fully supported because all we are doing here is handling our user controls. All we are doing is responding to the user’s request for content. And there’s plenty of room to customize this to your own uses.

Here’s the run through.

1. A user clicks a button (button_click()) or somehow starts
2. Button_Click() calls LoadControl()
3. LoadControl() searches for your user control using GetControl()
4. GetControl() looks in panelContainer’s control collection
5. If the control is not found, LoadControl() creates & adds it
6. If the control is found, LoadControl() references it
7. The User Control is brought to the front of the container
8. [/end]

If you want to add your controls through design time, this approach does not care. You can do that. But if you don’t then this supports that, too.

I have seen these controls implemented with a custom interface (to recognize them) and a Activate() method to alert them they were selected.

The sky is the limit insofar as variations. But the core functionality is exactly as I have illustrated below. Look at how simple it really is:

Get the code here: http://www.codepaste.net/9jbzui

A Word on Usability and UI design

A recent discussion reminded me of an old UI/usability principle that users prefer a layout they already know.

The idea is that users don’t want to learn your product. They want your product to be like products they have already learned.

For this reason, developers often feel the urge to copy the Office look and feel. And, why not? MS spent $Ms on usability testing.

Remember how everyone hated the ribbon when it first came out? Now, it’s hard to find software that doesn’t have a ribbon UI.

Applications that look like Outlook are a dime-a-dozen, but that doesn’t mean they’re bad. It means users understand them.

There’s more you can copy for success. Windows has familiar layout. Consider the windows explorer, users already know it.

Remember, when you are designing your application, don’t try to be too original. Crazy layouts and stupid colors are your vanity and not a favor to the user. Be creative, yes, but be familiar, too.

Our database naming conventions

A messy database is a real nightmare. Modeling a schema is easy; everybody knows that. But creating a model that is both complete and simple – that’s hard. There are libraries full of books written to help you decide your approach. Good luck.

[Simple is the Best Design]

But naming conventions in a database are very important. Poorly named objects overcomplicate queries, burden developers, and make everyone hate you forever.

Here are our conventions for database objects:

.Net development has rightly stopped using Hungarian notation (prefixing objects with type indicators like strName and dteBirth). But for databases, prefixes still serve a vital role. 

Like .Net development, our overarching rule is to avoid abbreviations. Never abbreviate, with three exceptions:

1. 1) if the full word is ridiculously long (like MiscellaneousAttributes could be MiscAttributes), or
2. 2) if the full word is commonly misspelled (like MassachusettsUsers could be MassUsers), or
3. 3) if the abbreviation is more recognizable than the full word (like KentuckyFriedChicken could be KFC).

I understand you may have your preferences. These are ours. With them, I can guess within 99% of exactly what objects are just by seeing their case. Cool.

Note: every object is prefixed except the database itself. We never do anything like dbDatabase because that’s just stupid.

Prefixes (all prefixes are lower case):

Example	Standard	What is it?
tb_Users	tb_ prefix	Table
UserName	Pascal Case	Column
up_User_Insert	up_ prefix	Stored Procedure
v_Users	v_ prefix	View
fn_UpdateUsers	fn_ prefix	User Function
syn_Users	syn_ prefix	SQL Synonym
idx_Users_001	idx_ prefix	Index
@userName	@ + Camel Case	func, proc Parameter
@UserName	@ + Pascal Case	Local variable
LINK2Database	LINK2 prefix	Linked Server

Additional rules:

1. Tables are always plural (tb_Users, never tb_User)
2. Columns are in Pascal Case (UserId, FirstName)
3. Primary Keys are single columns whenever possible
4. Primary Keys are named with the table (tb_Users.UserId)
5. Primary Keys end with Id (UserId, not Key or Pk)
6. Foreign Keys end with Fk (UserFk, never Id, Key or Pk)
7. Stored Procedures never use the sp_ because this is a known SQL Server performance problem
8. Stored Procedures are named up_NOUN_VERB such as up_User_Insert or up_User_Search or up_User_Delete, not up_Delete_User or up_DeleteUser or up_UserDelete.
9. Triggers are named tr_TABLE_ACTION such as tb_Users_UpdateSecurity, not tb_UpdateUserSecurity
10. Index names don’t really matter. But if we want to conform them we use idx_TABLE_TYPE_COLUMNS like idx_Users_Clustered_LastNameFirstName. If the number of columns is too long, then idx_Users_Clustered_001

There are special rules for cross reference tables.

1. Names should include the parent table’s name
2. Names should include the static term “cross”
3. Names should include the child table’s name
4. They always have a primary key called CrossId
5. Many to One = tb_Groups_cross_User (in all reality, this should never happen – use One to Many).
6. One to One = tb_User_cross_Group (singular child)
7. One to Many = tb_User_cross_Groups (plural child)
8. Many to Many = tb_Users_cross_Groups (all plural)

An example schema would be:

dbo.tb_Users
dbo.tb_Users.UserId int primary key
dbo.tb_Users.FirstName varchar(50) not null
dbo.tb_Users.LastName varchar(50) not null

dbo.tb_Groups
dbo.tb_Groups.GroupId int primary key
dbo.tb_Groups.Name varchar(50) not null

dbo.tb_User_cross_Groups
dbo.tb_User_cross_Groups.CrossId int primary key
dbo.tb_User_cross_Groups.UserFk int
dbo.tb_User_cross_Groups.GroupFk int

Optional idea. One thing we have enjoyed is grouping similar objects together with a preceding keyword. Something like tb_Configuration_SecuritySettings and tb_Configuration_General. This helps them to be near each other in the UI – which can help users understand dependencies. The reason this is optional is because of the prevalent use of schemas which accomplish the same thing. So, you can decide how you want to do it. Note that there is no special naming standard for schemas.

I more vigorously defend database naming standards than I do .Net code standards. Both are important. But databases seem to live forever and code comes and goes. We all share the database, while code is often isolated. It’s better to be a jerk about the database, I have found. When you aren’t everyone eventually will suffer – including the customer.

Our standard C# naming conventions

Everyone has their own coding standards. The most important thing is that you have standards – and if you are part of a team that you share and obey standards. Standards help developers on the team during development and during maintenance. Be consistent, and if you can – be smart about it.

The MSDN conventions are the source of my personal conventions. I thought I would share my preferences around case. This is how my developers standardize their code and a few of the rules we use. Just by looking I can come guess within 99% of exactly what objects are just by their case.

You might have your own preferences, but at least be consistent.

This just happens to be what I like and use:

Example	Standard	What is it?
m_JerryNixon	m_ prefix, Pascal Case	Class member variable
_JerryNixon	_ prefix, Pascal Case	Local variable
JerryNixon	Simple Pascal case	Property
OnJerryNixon	On prefix, Pascal Case	Event
JerryNixons	Plural Pascal Case	Enumeration
JerryNixon()	Simple Pascal case	Method
jerryNixon	Simple Camel Case	Method parameter
JERRYNIXON	Upper case	Constant

Our overarching rule is – no abbreviating. And although there are a few more rules, I like to keep them slim. Developers like freedom.

The 8 key responsibilities for Business Analysts on software projects

[edited 09/08/09]

 

The tension typical between developers and Business Analysts is mitigated with clear responsibilities. Sometimes, the developer *is* the Business Analyst; that’s not wrong, just uncommon on larger projects where the role is usually a dedicated resource.

Let’s consider the job of a dedicated Business Analyst (BA):

1. Extract: A BA determines the Requirements by extracting them from business (and government) policies and, when possible, the current or future end users.

1. Anticipate: A BA casts a vision to the Product Owner so she can anticipate Requirements that are not yet needed or have not yet been considered (like security).

1. Constrain: A BA constrains the user’s whims – functions geared to trends, individuals, or outdated processes – and focuses users on the core business needs.

1. Organize: A BA organizes disparate requirements into correlated categories for to manage and communicate Requirements with technical, left-brained resources.

1. Translate: A BA translates business Requirements into technical Requirements (not solutions); abstracting business complexity away from technical resources.

1. Safeguard: A BA safeguards the needs of business and system users in the development process by verifying functionality, accuracy, and completeness.

1. Simplify: A BA advocates simplicity all the time – especially in implementation, making the system useful but continually focusing on day-to-day ease of use.

1. Verify: A BA knows the use cases best. They advocate the users, verify the system against Requirements, and must reject implementations that don’t hit the target.

Someone discovered you can build the acrostic SAVE-COST. I didn’t plan for that, but it’s handy. Generally, I am on the developer side of the house. But when a BA handles those eight things well, we all just get along. If you know what I mean.

 

Have a nice day.