Principles of Developing Own Apps

Recently, I have started a pet-project to develop a Windows Phone 7 application - just for the kicks. I needed something to drive me into learning Silverlight and phone programming, so the best way is to dream-up something and build it. The entire project revolves around one primary objective - learning, and of course, the secondary objective would be to have fun.

Over the course of this project, I have acquired many knowledge both technical and non-technical, and developed a set of principles to get me going. These principles is what I would like to share with you today.

Principle #1 - Be Positive

If you ever had an idea for an app and shared it with others, you may no doubt encounter this statement - "Hey! You know what? There is already an app for that." For the most time, that is the truth but that doesn't mean you should just stop or you can't come out with something better. The first version of iPhone is basically just a phone with nothing special and yet it can still be successful.

So, the best thing to do is to be positive. There are times where you can really have a great idea but because when you first deliver it to people, they will try to "relate it" to something they can understand or already have. In today's connected world, ideas are built on ideas so there is no need to be sad if all that hours you spent thinking that you had a great idea and you found out that someone in another part of the world has the same thoughts as you.

Principle #2 - Stay Focused

Some of the people whom you shared your idea with can be very supportive. Particularly, if you have it developed and opened it up to a group of close friends or 'testers'. They will provide you with valuable feedback and this is where sometimes it gets confusing. Due to the excitement, they will also provide you with their ideas adding on to your already existing requirements. Some may even be bold enough to tell you that you need to change the entire concept.

They are not wrong. They are simply trying to help. But sometimes it could be something that is missing in an app that they were using and they look to you to fill that void. We need to remember that when we are conducting a 'field test' or a 'usability test', we need to stay focus on the app that we are building. The objective is to assess whether it functions to our expectations i.e. easy to use, don't crash and etc.

We need to stay focused on our goals and not let it stray. Yes, we will be bombarded with better ideas and all sorts but we need to ask ourselves one thing - are those ideas aligned with our idea. If they are, put them in a nice-to-have list for future, if they are not, still keep them in a user wishlist but never stray from your original idea.

Principle #3 - Keep it Simple and Stay on Track

There are times when we will be over-excited on a technology that we found and we are obsessed in getting the best designs or results with it. We will go on and on with it continuously asking ourselves "Can I do this with it?", "Can I do that with it?", "What if I do that?" etc. We may also along the way discover more new technologies to "play with" and we become fixated with them and start dreaming up new features for our app. Without knowing, we have strayed away from our original path for our app.

Therefore, we need to constantly remind ourselves to keep it simple and stay on track. Deliver our app first! The other cool and exciting things can be done when the need arise. Yes, we may want the best things out there but it is more important to deliver a version 1.0 out first.

Principle #4 - Verify Your Concepts

There are times when we really thought that our concepts will work but sometimes they are limited by the technology. We will discover that certain technologies are really not as accurate or reliable as we hope them to be.

Therefore, it is important to verify our concepts to make sure that the technology works according to our expectations. Some technology limitations may completely distort the usability of the app or create additional problems for us. Verify and prototype concepts early to avoid any major code changes late in the production.

Principle #5 - Beware of the Investor

If you are building your app for fun like me, you may not have thought about what you may want to do with it - Release it for FREE or maybe hope that someone would buy it for USD 0.99 or perhaps make some donations to you? Then you may accidentally stumbled upon someone who are really supportive to your idea and willing to put in $$$ to help you materialize your dreams.

Then you start dreaming about being the next facebook, next Instagram and the next Draw Something. Snap out of it! The Investor is merely looking at how to monetize your work. While that is good, they may also start to suggest commercial features into your app. And... if you have accepted their $$$, it is very difficult for you to say NO.

Therefore, we need to Beware of the Investor if you are doing apps for fun. You need to ensure your idea is not strayed or polluted. Do you think facebook will be successful today if it was launched as "Social Networking and Marketing System - Enterprise Edition" ?

The Golden Principle of Developing Your Own App

All the above is what I have experienced during my almost 2 months of developing a silly stupid app (which I have yet to release). I have gone through all the above situations, from idea creation to development, each time feeling confused, sometimes feeling defeated and depressed but I have managed to develop a principle after each encounter to stay strong. As the saying goes, "What doesn't kill you will make you stronger".

We need to understand that our ideas may not be great or workable, but maybe they can work as well. We will never know it if we never try. Yes, we will often be afraid that we will fail but think this - "It is OK to fail, but it is not OK to not try."

Finally, I would like to leave you with this golden principle which I have started practicing. It is no doubt that people will offer us ideas and suggestions, they may sound genuine, may or may not be aligned with our ideas, but we  need to have this in mind - "I am developing my app, if other people wants an app that behaves the way they wanted it, they can always build it themselves."

bigint and SQL Azure Data Sync

After attending my presentation on SQL Azure Data Sync, my DBA was a little disappointed when I mentioned that SQL Azure Data Sync does not currently support bigint data type. She kept telling me that it is important to have bigint support because a lot of our tables are using it.

I showed her the Supported SQL Azure Data Types web page that showed this (at the point of this writing)

She gave me a teary eye look and I said, "Why not we just test it out and see whether it supports it?" Off we went to setup SQL Azure Data Sync on a table that contains bigint columns and to our surprise - it worked! We have not tried other unsupported data types listed on the page but we are glad to discover that bigint is actually supported!

Nokia Lumia 800 Launch

Three Telcos under the Malaysian sky 
Seven point five the OS of Windows Phone 
Nine Nokia Stores are where to buy 
One phone each for us to bring home 


At the launch of Lumia where the excitement rise 
One phone to rule them all, one place to find them 
One App to bring them all and in the Marketplace binds them 
At the launch of Lumia where the excitement rise

I have always been a Nokia fan-girl and it would be interesting to see how Nokia fairs with its latest Lumia 800, their first Windows Phone 7 phone (I know it sounds a bit weird) in Malaysia. At the point of this writing, Digi has even thrown in a very good deal.

Nokia is also giving out lotsa freebies to the first 100 Lumia 800 customers at the launch on Feb 10, 2012 starting from 5:30pm at Pavillion (and other Nokia Stores).

Layered Architecture Solution Guidance 1.0.0.5

Finally got the time to post this. Layered Architecture Solution Guidance 1.0.0.5 is now available for download. This version comes with several enhancements and productivity improvements.

Delete Buttons - They are back! One of my developers have previously mentioned that the buttons were confusing but I noticed people deleting the whole class definition instead of using the Del key to remove an individual property/method. Therefore, I made a conscious decision to bring back the delete buttons :)

Re-order Properties/Methods - You can now re-order the property/method definitions before code generation.  Inertia and Momentum have an additional Sort option.

Add All Sources - There is now an option in the code generators to create definitions for all sources at once instead of requiring you to select and configure one-by-one. However, this will only use the basic configuration. This option is not available in Motion and Vector.

Momentum Enhancements - Momentum has been slightly upgraded to support the following features:

• Support for Schema
• New "Insert | Update | Delete | Select" method type.
• New "Standard CRUD Methods" method type that generates an extra Select All method.
• Option to generate "Load methods" to reduce code repetition. Please use with caution to avoid duplication.

Motion Enhancements - Motion has also been upgraded to support the following:

• More streamlined DAC method selection.
• Support for drag-and-drop of DAC methods to selection.

Other Code Generator Enhancements

• Inertia - Allows you to type in the data type for your properties. You can use this as a convenient way to map to your enumerations.
• Vector - Reorganized UI Layout.
• Velocity - Option to generate Workflow service configuration in host config.

SQL Azure Data Sync Preview

Was reading up on SQL Azure Data Sync and found out these interesting things:

At the time of this post, SQL Azure Data Sync (Preview) does not support bigint data type.
http://msdn.microsoft.com/en-us/library/hh667319.aspx

One need to be very careful when selecting the Conflict Resolution strategy. Apparently, both Hub or Client Wins will also result in some form of data loss if the resolution is not understood properly.
http://msdn.microsoft.com/en-us/library/hh667306.aspx

Finally, I think this is the most important and missing this one out would have caused a lot of issues (and $$$) later - Synchronization Loops.
http://msdn.microsoft.com/en-us/library/hh667312.aspx

MVP for Windows Azure

On January 2, 2012, I was awarded the Microsoft Most Valuable Professional (MVP) for Windows Azure. It is really an honor to be recognized as a Windows Azure MVP for my country. I will definitely continue to shower the developer community with my passion for technology and crazy ideas to build applications - particularly now focusing on Windows Azure. :)

Windows Azure is now ISO 27001

I am just going to parrot this from the Windows Azure Team Blog. Windows Azure is now ISO 27001 certified and more importantly it complies with the ISO/IEC 27001:2005 ISMS requirement standards. This is a good start and a great milestone to gain the confidence of ISO 27001 companies (like my current) to leverage on Windows Azure.

The next step would be to see SQL Azure getting certified. Getting SQL Azure certified will be the most important key point to address the data concerns of most companies when moving into Cloud solutions. Looking forward to see that happen.

MVC and Layered Architecture

Throughout the years of promoting Layered Architecture on .NET, I have occasionally came across the question on how to integrate the Model-View-Controller (MVC) Architecture into Layering. MVC provides clear separation of data and UI logic concerns coupled with the benefits of high testability. Layered Architecture provides a scalable, extensible, maintainable and highly adaptable distributed design for applications. With such advantages from both architectures, who can resist them? :)

Back then, there weren't any sophisticated MVC tools in Visual Studio, the closest was the Smart Client Software Factory (SCSF) and Web Client Software Factory (WCSF), but both were using rather complicated implementations. But today, VS 2010 provides us with ASP.NET MVC web application templates which effectively raises the need to answer the integration question even further.

Before I discuss the integration ideas, I would like to first share with you my personal perspective of the MVC architecture. Firstly, MVC is an out-dated (but good) architecture. Many sites will tell you that MVC is not new and it has been around since SmallTalk. Why I say it is out-dated is because it was not designed for today's service-oriented distributed architectures (something that can be fixed when merged with Layering).

Secondly, I view MVC as a "micro-pattern" for developing UI applications and Layering as a "macro-pattern" that can house multiple micro-patterns (not just limited to MVC). Therefore, I truly believe that MVC can be integrated into Layering to leverage on modern day distributed environments.

Finally, I felt that the out-of-the-box ASP.NET MVC templates in VS2010 are encouraging a monolithic approach. Ok, I admit that I think most of the OOTB VS templates are *evil*, simply because their focus is on RAD and promoting the adoption of a specific technology without looking at the complete architecture. Some developers have already realized this and have started to decouple their Data Layers to a Data Service, but that still leaves them with a "client/server application" at best. Do take note that all these problems I highlighted are not the fault of the developers but more on the project templates.

I shall reserve my ideas to fix those templates to another post, but right now, I will provide the high-level concepts of merging the two architectures to get the best of both worlds. There are two models which I have came up with and I will start off with the first one which I conveniently termed it as the Bridged Model.

If we dissect both architectures, we can easily identify components of similar responsibilities regardless of the term that is used. In MVC, the Model is used to ferry data, the View is used to display/capture data and the Controller is used to process logic and co-ordinate the flow between Views. In Layered Architecture, the Business Entities are used to ferry data, UI Components are used to display/capture data and the UI Process Components are there to co-ordinate the UI (and connect to the service back-end) - Notice the similarities?

In the Bridged Model, the key to connecting both architectures lies in the Controller component of the MVC and the UI Process Component (UIPC) of the Layered Architecture. By connecting the Controller to the UIPC, we treat the entire MVC portion as a UI layer (or component) sitting on top of the UIPC. This strategy has the benefit of making the Controller more lightweight as most of the application and service-communication logic is delegated to the UIPC. It is also good for multi-UI platform applications which may allow Desktop, RIA and mobile clients to share the same UI processing logic.

If you are integrating a MVC web application to an application with existing UI components calling a service back-end, then the Bridge Model will make most sense.

While the Bridge Model works in connecting the two architectures, it may seem less elegant if we only have a single UI platform. In that case, we may not want the performance overhead of the Controller-UIPC relationship and to remedy it, we can adopt the Integrated Model.

In the Integrated Model, the Presentation Layer components are being replaced completely with the MVC components. The responsibility of the UIPC is unified into the Controller, eliminating one level in the UI and therefore, improving the performance of the application.

Whether to use the Bridge Model, Integrated Model or not at all, is depending on your choice and the projected application growth. If you are dead-sure that your application will not grow, then the monolithic approach presented by the OOTB templates will work just fine. Otherwise, if you share the same thoughts like me i.e. "All applications has the potential to grow, no matter how small they are", then it may be wise to look at the integration models from the start.

Take note that although I used Web Application in the context of the discussion, these concepts can be equally applied to any type of MVC application i.e. the SCSF implementation of MVC/MVP.

LASG = A framework?

I was approached by a developer to comment about the usage of some frameworks in his project. After providing my comments, I told him that I do not use the frameworks that he had mentioned and he immediately said, "Oh! I forgot, you only use LASG". I was stunt for a moment. Probing further, I managed to discover how LASG was being perceived (somewhat wrongly) by some developers in the community.

Firstly, I discovered that the developer had compared LASG with MVC (some had previously compared it with ADO.NET Entity Framework). MVC and EF are both "code-frameworks" that share the same goal as LASG which is to simplify software development but uses a completely different category of approach. I would say, MVC and EF are what (true and real) code-frameworks should be.

LASG is not a code-framework but only a simple (humble) automation tool. It does not contain any APIs or Application Blocks that requires a developer to learn or use. It is just a combination of project templates and code-generators that simplifies development tasks. These tasks can very well be hand-coded if one wishes to do it. Therefore, I feel that getting started with LASG is (should be) much simpler and easier as compared to learning a code-framework.

To prove a point, you can completely disassociated LASG from your Solution and Project templates at any time and your code will still compile and run. You can uninstall LASG from your machine after you have generated all the code and your code will still compile and run. [Warning: If you disassociate LASG from your projects, you will not be able to re-associate it back. Hey! It has feelings too you know! :p].

I also understand that this confusion is also partially my fault. For the veterans who knew me previously, I wrote a RAD framework called Paladin and to accelerate the adoption, I developed a simple code-generator on top of the framework. That was the time when people proclaimed that Paladin was a code-generator but I refuted and said it was a framework. Now almost 10 years after that, I created something simpler like LASG and people now have the perception that it was something complex like my previous attempt. *HeHe*

So, is LASG still a framework? If I follow Microsoft Patterns & Practices' (or the industry) terminology, LASG is somewhat like a software-factory - a very basic one I would say (All great things start with a baby step). Afterall, it does provide guidance and recipes to build software and you can adapt it to any compatible code-frameworks (if you are creative enough). If we must have the word "framework" attached to it, I will call it an "Architecture Framework".

Still confused? Why don't you download it first and then tell me? ^_^

Sharing Code Between .NET and Silverlight

Recently, I have some time to look into the solution for sharing code between .NET and Silverlight again. It was an annoyance which everyone of us (including developers around the world) discovered, where we can't reuse our .NET classes in Silverlight. Any attempt to add reference to our .NET assemblies will land us the following error message:

"You can only add project references to other Silverlight projects in the solution."

If you are developing layered or multi-UI applications that involves Silverlight, then you would have encountered this error. This is not really a bug but actually is by design since both Silverlight and .NET don't share the same runtime. This is indeed bad news for those of us who try to follow proper architecture design practices since we are unable to share our entity classes.

If you packed everything to one WCF service, then you shouldn't have any problems because the "Add Service Reference" option in Visual Studio would have generated replicas of the entities into the Silverlight project. However, if you have separate services i.e. a WCF service to handle standard calls and a Workflow Service that runs workflows and both requires the same set of entities, then you will immediately run into issues because the replicas generated on both service references will not be compatible.

There is currently no out-of-the-box intelligent solution for this issue. This is a tooling limitation - I blame it on svcutil.exe. Most developers after several futile attempts will just try to manually replicate the entity classes to their Silverlight projects. This will solve the add reference issue but will introduce code inconsistencies should the entity classes are updated in future.

Fortunately, Visual Studio provides us with the "Add As Link" feature to allow us to share the same code files across multiple projects. However, this is somewhat a pain as well since we need to keep the projects synchronized when we add/remove items.

By luck, I came across this handy Visual Studio Extension - Project Linker which was part of the PRISM project. This neat tool allows us to "link" Visual Studio projects together keeping them fully synchronized so that we can have projects that share the same code base but target different platforms. It was originally designed for sharing code between WPF and Silverlight. You can also check-out the documentation here - very useful when you need to "unlink" projects ;)

So there we have it. Not a very elegant solution but at least it helps reduce the redundancy and ensure synchronization of our code.