New Year, New Look – Design

Here is an interesting quote, which highlights our design philosophy:

Without good design, it is easy to miss the point
– Bjarni Wark

As a small start-up company, our need to project the branding/messaging is key both as a means to show the differentiating value we bring to our clients & as a message which will resonate with them if they had an opportunity to just glance over it once.

After a lot of debate, the simplest mission statement we could craft is:

We Deliver High Quality Software
– IT.Wox Mission Statement

This statement captures our area of work (namely Software Development), our approach (of Delivery) & what the client can expect in the whole process (High Quality).

Needless to say – our whole design now revolves around this message.

The Offerings

Limited as our team is, we cannot (& will not!) promise to do everything under the sun. Rather our focus is simple & plays to our strengths:

  • Consulting: which applies to one-off point-in-time help to our client needs for Architecture, Design & Development of Applications (usually web/mobile or hybrids). We bring over 20+ years of experience in this space & can help guide our clients for simplest to complex enterprise-grade implementations.
  • Development: which applies to our own development efforts, be it Open Source Software or custom Software Products (to be announced soon!) and/or custom development for our clients. We are hands-on technical team with skills in .Net & NodeJS platforms.

Our belief is that a company is successful if it has both Consulting & Development offerings. On one hand, Consulting exposes you to different & unique experiences with a constant need to quickly assess situations & provide solutions within a pre-defined timelines based off your past experiences/knowledge. On the other hand, in-house Development gives us the technical depth to dig deep & have our own arsenal of tools & techniques to offer when our clients approach us with their specific needs.

The Design

We feel our new site captures the mission statement & our current offerings really well.

Capture

Our mission statement really pops out with our service offerings following with clear Call-To-Action buttons inviting the visitor to contact us.

The site is responsive. We are using the excellent Bootstrap CSS framework for the responsive behavior & alignment of various components. JADE view engine delivers the HTML over ExpressJS web-server. We did think about Angular/React/Flux/(you name it…), but at this point we kept the over-all development complexity to a minimum by sticking to plain-old HTML renderings.

While the page content was intentionally kept spartan to avoid information overload, this layout allows us to expand the number of widgets on the UI & gives us an ability to show-case various items in the future in a dashboard-y way.

Contacts

One important addition to the UI is the Contact Widget:

Capture1

This widget will be visible on most of the screens in the new design, albeit with few modifications of the title to make sense in the different page contexts like so:

Capture2 Capture3

This allows our visitors to reach out via email and/or via our Twitter account for any question and/or comments in a consistent manner. Over a period of time, we hope to add a LinkedIn, Facebook & Chat/IRC links here.

While having an email contact for support is no-brainer, we did debate including the Twitter account up there. We look at Twitter as a social communication “headliner” rather than a discussion forum. However it might help promote the brand by having few tweets going out at the current stage. Time & experience will give us better understanding of this design decision.

Blog

Blogging is going to be key for us to show-case some of the interesting happenings around IT.Wox. Besides the title of our Blog is pretty cool (IMO):

Capture4

Needless to say, it had to be part of our home page.

We currently pull in the 3 latest postings from our blog & show up on the UI.

Ideally we would have liked to pull in content based off a specific tag and/or set of tags (e.g.: pull content which has been tagged “IT.Wox” on the blog). Or take it a step further & pull content based off the visitor’s browsing history (e.g.: pull content on “.NET” if the user has been searching on that term & we have Google and/or some other social behavior tracking software provide that context).

While the whole behavior tracking seems cool, we need to be cognizant of visitor privacy (which is a whole different post at a later time). Besides, what if the user has been searching for furniture during this holiday season & lands on this site out of some twist of fate? Do we show him a blank in the blogs as we (usually) will not have any content related to furniture?

So, the choice was simple – pull by tags at a later date (when we build up sufficient content) & till then latest 3 postings it is.

Feedback

At this time, this site contains the bare bone minimum amount of content & information needed. Over the coming months, we will expand both the content & the functionality of this site to better fit our needs. However, we are confident that the current design should hold for most of our use-cases & would love to hear your comments/feedback about this new look.

Is there any aspect of this site we should have styled differently? Do you like/hate it? Feel free to sound off in the comments & continue reading the remaining parts of this series.

Read the Series:

New Year, New Look

The IT.Wox site has been dormant for a while & the site had gone stale.

Just in time for the New Year 2016, time to refresh & reboot!

So, here’s presenting the new look site: www.itwox.com

The Goals

  • Highlight what IT.Wox stands for (aka. motto/USP/theme)
  • Highlight the services/products of IT.Wox (aka. what we do)
  • Highlight some interesting aspects of the site (via Blog, News, Social etc.)
  • Support mobile & desktop browsers (gracefully degrade, where possible)

The Subtle Text

Being that we are a start-up (of 2 people, part-time!), the design had to be done in-house or rather by your’s truly. With $50.00/year (or less!) operating budget, the site has to deliver a message on a budget!

However, we need to support latest “web presence” requirements:

  • A mobile-first website
  • Branding & messaging
  • Social media presence
  • Site Analytics
  • Communications & interactions with web visitors
  • Modern web development standards (build – test – deploy)
  • Source control, Issue Tracker & Build Management
  • Scalable Infrastructure
  • Legal needs like privacy policy, disclaimers etc.

The Subtle-er Text

This site is an expression.
Of what we can do, of how we can do it & our whole philosophy/approach to the business of IT as it applies to consulting & development. It is an expression of our vision of a company & what we hope to achieve.

This site is an experiment.
Of technology, design & integration of various components which are needed for modern web development. In that sense, this site is not finished (& might never be!), we hope to keep it going forward each cycle to the next version with better improvements to reflect our current understanding & thinking about this business.

This site is an experience & instruction.
Of the details needed for running & maintaining a simple web site. While the scale is small/micro, the complexity & approach is still the same as any of the large site/applications out there. We will surely learn – from our experience, feedback from this site & other channels, to make it better. However, we could also be a source of knowledge for other developers out there & starting out on similar endeavors.

The Next…

In the following few weeks, we hope to post some of the interesting aspects of this site, few implementation details & hope you will read along and/or provide comments where due.

Happy New Year!

Read the Series:

Using MEF with Common Service Locator

“The Managed Extensibility Framework (MEF) simplifies the creation of extensible applications. MEF offers discovery and composition abilities that you can leverage to load application extensions.” – (mef.codeplex.com)

“The common service locator library contains a shared interface for service location which application and framework developers can reference”  – (commonservicelocator.codeplex.com)

Wow!

How to get them both working together, is as below.

NOTE: I am assuming that the reader is aware of Dependency Injection pattern & the Common Service Locator.

The Steps:

  1. Download the CommonServiceLocator_MefAdapter.4.0.zip file & extract the MefServiceLocator class written by Glen Block
  2. Create a new ASP.Net MVC 2.0 Web Application Project
  3. Include the MefServiceLocator class into this project
  4. Open the Global.asax.cs file
  5. Make the following code change in the Application_Start event:
    protected void Application_Start(){     
    
        RegisterDIContainer(); 
    
        AreaRegisteration.RegisterAllAreas();     
    
        RegisterRoutes(RouteTable.Routes);
    
    }

  6. Write the RegisterDIContainer method as:
    protected void RegisterDIContainer(){
        var catalog = new AggregateCatalog(     
    
            new AssemblyCatalog(Assembly.GetExecutingAssembly()),     
    
            new DirectoryCatalog(Server.MapPath(“~/Plugins”))
        ); 
    
        var composition = new CompositionContainer(catalog); 
    
        composition.ComposeParts(this);
    
        var mef = new MefServiceLocator(composition);
    
        ServiceLocator.SetLocatorProvider(() => mef);
    }

     

  7. With this in place, you are now good to do:  

    var controllers = ServiceLocator.Current
            .GetAllInstances<IController>();

Code on…

Extending ASP.Net Memberships with Access Points – Part 2

In part 1 of this series, we described a way to simplify our code to abstract some of the role-based implementation which the ASP.Net Memberships & Roles gives us.

In this part, we will explore the extensions needed in the SQL Server database to have additional table which will help store the data needed to implement this concept.

The Data Model Changes

Access Point Data Model

The above diagram shows the extension needed to the data model to support the additional functionality.

Table Name Purpose
aspnet_AccessPoints This is a master table of all the access points defined in the application (by ApplicationId). The “Value” column can store any value associated with that Access Point.
We will see the use of this field in a future article where we will explore some of the advanced techniques of Access Points
aspnet_RoleHavingAccessPoints This is a simple Role to Access Point mapping table. Using this table we will be able to link a Role to one or more Access Points.
The “Value” column is present here to override the default value in the aspnet_AccessPoints table with a different value for a specified Role
aspnet_UserHavingAccessPoints This is a table which maps the users to Access Points. We will use this table to grant special permissions to a single user.
For example: Consider a situation where all users in role “Editor” should be able to edit articles on your blog, but for use John Doe, who is in the Editor role, also need permission to approve comments.
Usually, we will create a different role for this & assign John Doe to that role.
But in the Access Point implementation, we will use this table & have an entry to map John to that Access Point.
The “Value” column in this table is used to override those of the aspnet_AccessPoints and aspnet_RoleHavingAccessPoints table values. In effect, you can give specific values to Access Points at a user, role or Access Point level with the same order of priority.

With these changes in place, we are now ready to start writing some code to expose this functionality & start seeing some benefits of this technique. We will cover this in part 3 of this series.

Happy Coding!

All articles of this series:

  • Part 1 – an introduction to the Access Point concept
  • Part 2 – database changes needed to enable Access Points
  • Part 3 – code to enhance the ASP.Net Memberships and Roles
  • Part 4 – some common usage patterns and advantages
  • Part 5 – a simple UI implementation to show use of Access Points
  • Part 6 – an admin console to manage Access Points

Extending ASP.Net Memberships with Access Points – Part 1

The beauty of ASP.Net is that some of the core framework components can be replaced by custom implementations by writing the appropriate Provider classes by using the Provider Model.

In the following series of article, I will show a customer implementation of the ASP.Net Membership Providers to extend the Memberships.

Reason of extension

The current Membership implementation is role-based i.e. the user should be in a role to be able to access a feature of your application.

For example, if we have a page with some UI elements whose access depends on role assigned to the user, we can imagine to write code as below:

bool has_access_role1 = this.Page.User.IsInRole("Role1");
bool has_access_role2 = this.Page.User.IsInRole("Role2");

if(has_access_role1) { 
    // do something with Role 1...
}

if(has_access_role2){
    // do something with Role 2...
}

There are a couple of important but subtle assumptions being made in this code snippet:

  • There is an assumption of knowing all the Roles, their names & behavior in the application
  • The implementation and responsibilities of that Role are baked into the application and if there is any future change in this, the code will also need to change

While this is acceptable in most scenarios, I would prefer having another level of abstraction which will remove some of these assumptions and code dependencies.

Introducing Access Points

The implementation I am showing below called as “Access Points” provides this abstraction and is a concept I have been working with in some of my other projects.

  • Each protected element is associated with a single entity called “Access Point” which has is a simple boolean (TRUE|FALSE)
  • Access Points are assigned to a Role or a User
  • When an Access Point is assigned to a Role, the User get assigned to that Access Point by virtue of being assigned to the Role
  • When an Access Point is assigned to a User, it an additional permission which can be set per-user basis

With this implementation, we should be able to re-write the above code sample as below:

var has_access_point1 = (this.Page.User as IAccessPointAware)
                .HasAccessPoint("AccessPoint1");
var has_access_point2 = (this.Page.User as IAccessPointAware)
                .HasAccessPoint("AccessPoint2");

if(has_access_point1){
    // do something...
}

if(has_access_point2){
    // do something more...
}

Some of the advantages this mechanism gives us are:

  • The application has a finite set of control points, which is governed by the developers of the application
  • The Application Administrators can create roles for the application and assign Access Points to that role as needed
  • There is no dependency between the code written in the application and the implementation of the roles for the application
  • With this, the Application Administrators can add/update/delete roles as needed without any impact on the application
  • If a single user needs a permission or access to a single element, the Application Administrator can assign that Access Point to the single user

Next steps

If this something that interests you, please follow on to the next part this series which covers:

  • Part 1 – an introduction to the Access Point concept
  • Part 2 – database changes needed to enable Access Points
  • Part 3 – code to enhance the ASP.Net Memberships and Roles
  • Part 4 – some common usage patterns and advantages
  • Part 5 – a simple UI implementation to show use of Access Points
  • Part 6 – an admin console to manage Access Points

Happy Coding!

References

4GuysFromRolla 2005, A look at ASP.Net 2.0’s Provider Modelhttp://www.4guysfromrolla.com/articles/101905-1.aspx

Rob Howard, Provider Model Design Pattern and Specificationhttp://msdn.microsoft.com/en-us/library/ms972319.aspx

Enabling DI/IoC for noobs – Part 1

The powers that be agree that Dependency Injection (DI) & Inversion of Control (IoC) patterns help applications become more component-based, easier to maintain & better designed and are open to unit testing & mocking.

But how does one really use DI/IoC in their application to get the advantages aforementioned?

The following series of article provides a step-by-step guide to structure code for working with DI & then implementing IoC for noob programmers.

This article is the first of this series & provides an introduction to DI.

What is Dependency Injection?

Dependency Injection (DI) is a mechanism to inject dependencies into code such that the piece of code can consume the injected dependency without having knowledge of the construction or lifetime of the injected dependency.
In other words, DI in object-oriented computer programming is a technique for supplying external dependency (ie. a reference) to a software component – that is, indicating to a part of program which other parts it can use (Wikipedia, 2010)

Let us understand the definition by breaking down the definition into smaller parts.

What is a dependency?

Consider the following lines of code:

public class AccountController{

    private readonly IAccountRepository _repository;

    public AccountController (
        IAccountRepository repository ) {

        if(repository == null)
            throw new ArgumentNullException("repository");

        _repository = repository;
    }

    public ActionResult Login( string userName,
        string password ){

        var isLoggedIn = _repository.DoLogin(userName,
                                 password);
        return isLoggedIn
            ? View("AccountInfo")
            : View("Login");

    }
}

In the above sample, we can say that the class AccountController has a dependency on a type implementing the IAccountRepository interface ie. for the AccountController to perform its functionality, it would need a valid instance of IAccounRepository to be passed.

One key aspect to note is that we are not passing the concrete class of IAccountRepository, but instead passing in an interface. The advantage of doing this is the AccountController is not dependent on the concrete class, but only an implementation of IAccountRepository. In other words, the AccountController has a dependency on the IAccountRepository implementation.

What is Injection?

In the code sample above, we now know that the AccountController has a dependency on the IAccountRepository. The manner in which we can provide this dependency is known as injection.

One of the simplest ways to do this is:

var account_controller = new AccountController(
       new WindowsAccountRepository());

We could have a WindowsAccountRepository implemented as:

public class WindowsAccountRepository
    : IAccountRepository
{
    public bool DoLogin(
        string userName,
        string password
    ){
        // some code to do login by checking against the Active Directory
    }
}

But then at a later date, if you decided that you would like to have a custom implementation for account management & want to store the information in a database, all you would need to do is create a concrete class for your repository implementing the IAccountRepository & inject that into the constructor of the AccountController like below:

public class CustomAccountRepository
    : IAccountRepository
{
    public bool DoLogin(
        string userName,
        string password
    ){
      // some code to validate against a database
    }
}

Consuming this new class would look like:

var account_controller =
    new AccountController(
        new CustomerAccountRepository()
    );

This way, the complexity of the implementation of IAccountRepository is abstracted away from AccountController. But, AccountController is able to use the behavior exposed via the interface while the consumer of the AccountController is free to inject a concrete implementation of IAccountRepository.

Wrap up

In this first article, we defined dependency injection & what it means using a simple code sample. We have seen how we can replace the dependency by injecting a concrete implementation at the time of consumption.

In the next article, we will look at writing unit tests on the code we have just written & explore the benefits of DI in the context of unit testing.

Comments & suggestion always welcome.

References:

Wikipedia 2010, Dependency Injection – http://en.wikipedia.org/wiki/Dependency_injection