New Year, New Look – Technology

Technology – is quite literally our bread & butter.

Our strength is .Net (& associated technologies) & NodeJS (& associated technologies). We work on everything from desktops, web, mobile, hybrid & cloud. We develop for custom line-of-business applications, one-off mobile apps, API’s, Arduino-based robots and everything else that is possible within these technologies. We work with databases like SQL Server, MySQL, Oracle, MongoDB, & CouchDB. We are decent with SSRS, SSIS technologies. We work with Azure, AWS, Heroku & AppFog cloud services. We have worked on various domains like Banking, Insurance, Mortgage, Media & Healthcare.

It is easy to go crazy & get the best-in-breed for what we need as our IT stack (both in-house + client-facing). However, we believe that we need to keep our in-house technology costs to a minimum to free up more capital on other revenue-generating areas like: Client Projects, R&D, Sales, Marketing etc., given that we are self-funded (aka: its coming out of our own pockets!)

So, while we can (& do!) use all of these technologies & tools – we prefer to keep our own internal systems as light as possible by using Open Source Software, where possible. So, Notepad++, Visual Studio Express Editions etc., are more common place than full-blown Premium Editions for anything internal. Thank you OSS & the people who contribute their time/effort to creating them – our small company is totally dependent & grateful to the community. On our future to-do list – we have a goal to contribute back sufficiently to the community & hopefully show our respect to the whole initiative.

On the other hand, client-facing projects & R&D get all the love – best of what we have today, with a healthy does of “is there an OSS option” before we plunge into licensing & installs etc.

To help focus where we really want to spend our limited cash, we came up with a simple criteria as below:

  • Client-facing IT
    • Will do whatever it takes to deliver the best results
    • Costs are offset via pricing of that specific service
  • R&D efforts IT
    • Will take a one-time hit on specific projects
    • Will be OSS, where-ever feasible & if we have alternatives to a specific technology/solution
    • Costs are budgeted for the year & spend is monitored
    • Expected ROI is tracked very closely
  • Internal IT & Website(s)
    • Will be OSS, where-ever feasible
    • Each item given a nominal value of $50/year (or less!)
    • The only spend allowed for items in this bucket are related to security & privacy of data, which might push up the nominal value

The Cost of a Website

With our limited budget of $50.00/year (or less!), here is our technology stack & costing for this website:

Description Cost

NodeJS with Express Webserver. Front-end is built using Bootstrap with Font-awesome & a sprinkling of custom CSS. All code done using NotePad++  as IDE, keeps the overall tool licensing to a minimum!

Source Control & Issue Tracker

BitBucket has been our go-to system for both source control & internal issue tracking. Couple of reasons for this selection: unlimited PRIVATE repositories (a must) which GitHub does not provide! Built-in Issue Tracker (not the greatest), however it can be independently private and/or public to accept bugs. Limits to 5 users – which is effectively more than double our current staff. What else can a SMB ask for?


Mandrill/Mailchimp for email/campaign  solution (12,000 emails/month free rocks!) & we don’t blast out half that. AWS SES is another option, but we wanted a higher-level of functionality (like: Campaigns, Mailing lists etc.) without having to write & so Mailchimp it is.


all images assets (& eventually all static files like: .css, .js, .html etc.) hosted by Cloudinary Free account. 75,000 images in that band & we have uploaded 21 of which 15 background images of the home page & remaining various versions of the Logo, Favicon & touch-enabled versions for iPhone/Andriod/Windows.


AWS Free-tier for 1 year rocks! (& keeps the $ down too). Node-clustered t1.micro Ubuntu instance deployed to US-East data center. We don’t have large traffic (per our Google Analytics Stats). But if we see loads moving up, we will scale. A Load Balancer + 2x t1.small instance would suffice for the next step if/when we get to it.

*AWS Free-tier year 1;
Domain Hosting

GoDaddy (irrespective of their racy ads, which we love in a quirky way!).

*$50.85/5 years (1 year free + 4 years of hosting)

WordPress free edition to host this blog site & all the goodness associated with it! Yes it is not branded site & neither is it subdomain-ed under However we are pulling latest 3 entries from the blog into this site & based on how the traffic goes we will plan for better integration. We do have an up-coming release to have to point to this Wordpress blog

 Total Cost (year 1) $20.17

NOTE 1: we don’t have a SSL Certificate for this site. We will need one eventually, especially one that covers sub-domains like * If anyone has a good (& cheap) option, drop us a note.

NOTE 2: read the above cost breakdown purely from a website running perspective. We have not added the legal documentation costs of running a start-up, into this list as it is a different bucket of expense to the whole IT-side of the business. Perhaps one day, we might put that up into a blog post too.


While keeping the costs lean is ideal, we want to be practical & do what is absolutely needed & cut out the rest. Do you see anything that can be changed and/or needed which is missing from the list above? Leave us a comment.

Read the Series:


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.


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.


One important addition to the UI is the Contact Widget:


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.


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):


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.


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:

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:

I love to Grunt & Gulp

Task Runners – like Grunt & Gulp are such time-savers!

Reason: Automation!!!
Remove the “grunt work” by making tasks repeatable & standardize build/deploy scenarios, win-win!

Now, I am sure many of the savvy techies in you would have already checked out Grunt/Gulp and using them in your own ways. Task Runners have been in the wild for some time now, with excellent tutorials to get you started & so I will not delve into the details of how/what/why of these items.

The point of this article is for an interesting thought I had:

  • Is there any real need for such a framework(s) in your code in the first place?
  • Aren’t we introducing additional components + complexity into our code by having such items?

Is there an alternative to get the automation benefits of Task Runners, without the need for additional complexity and/or bloat of adding such frameworks into your code?

When this thought occurred to me late last night (yes, during a New Year’s Eve Party & yes – I am THAT kind of nerd!), I just could not wait to get started & give it a twirl in the NPM world & see where I get to.

More specifically, I was thinking of code along the lines of:

// code in package.json
scripts: {
"build": "npm build:script && npm build:css && npm:deploy",
"build:script": "browserify src/index.js -o dist/lib.js",
"build:css": "less"

As soon as I started along these lines, a small voice in my head went:
did someone think of such a solution before & if yes, what does that code look like?
Answer: Google says someone already has got there first.

As I tip my hat to the master, I also realize that I have been 2 months 1 day slower in coming up with this thought & 23 days slower in publishing a solution


I would strongly recommend to read through his material before continuing.

My personal opinion is that he is on to something here & I do see all the benefits in the solution.

Question: will I use the proposed solution in my own code-base?
Answer: While I really like the solution, is it worth the cost of readability for someone to “get” what it really stands for? I don’t know.

I will let this one simmer for a while & eventually wean off Grunting/Gulping.

I am too much in habit at this point in time.

Happy 2015!

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...

    // 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)
var has_access_point2 = (this.Page.User as IAccessPointAware)

    // do something...

    // 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!


4GuysFromRolla 2005, A look at ASP.Net 2.0’s Provider Model

Rob Howard, Provider Model Design Pattern and Specification

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,
        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.


Wikipedia 2010, Dependency Injection –