Impersonate a Web User from a Different Country

Recently I was in a situation where I needed to be able to test some geo-specific functionality on a website. The visiting web users IP would be recognised as coming from a specific country and a different action would occur (i.e. different view, redirect, etc).

After some Googling I managed to find a handy Chrome extension called GeoProxy. This allows you to set Chrome's proxy from a list of proxies (generated based on country) you choose. Proxies are listed in the order of latency.

GeoProxy:

https://chrome.google.com/webstore/detail/geoproxy/pooljnboifbodgifngpppfklhifechoe?hl=en

Agilaterfall: When Agile becomes Waterfall

Agile when it's adhered to correctly can be very satisfying to a developer due to its productive nature. Constantly delivering working software in small iterations, what's there not to like? However when agile isn't understood and enforced by both the product owner and stakeholders, it can also mean going back to the days of waterfall. To help demonstrate my point lets take a look at the Agile Manifesto (in steps wiki):

• Individuals and interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
• Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
• Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
• Responding to change – agile development is focused on quick responses to change and continuous development.

The first two points, "Individuals and Interactions" and "Working Software" can be controlled and implemented by the product owner and development team. The final two points, "Customer collaboration" and "Responding to change", if not done correctly is where waterfall can creep in. I fully agree that not all requirements can be fully collected at the beginning of a project and not always at the start of the sprint during sprint planning. The acceptance criteria on user stories is not always going to be the complete picture and that's where the responding to changes will cater for this.

However in order to respond to changes you firstly need to know what the changes are, and requires the stakeholder to raise these changes after a sprint. These can then be built into the next sprint and burn down charts recalculated. Giving a more accurate reflection on where the project is in its development life-cycle.

A stakeholder without the understanding of agile and the purpose of using such a software development methodology can be potentially damaging to the project. If these changes are not raised in the first instant and left to the end of the project, then you are essentially adhering to waterfall. You are then in the situation of adding unplanned time to the end of the project due to the stakeholders new requirements.

Conclusion

The two main points to take away from this:

1. Have good user experience (UX) and business analysts to ensure acceptance criteria is as complete as possible.
2. Ensuring the stakeholder fully embraces the nature of agile and reports changes or issues during sprints. Not at the end of the project and therefore reverting to a waterfall approach.

Multiple IIS websites running HTTPS with one Self-Signed Certificate

This is my first post and a little 101 however useful nonetheless. During development there comes a time when you have more than one website running in IIS that requires a Secure Sockets Layer (SSL). This would seem fairly trivial, no? However there's a distinct lack of material out there documenting the steps to achieve the holy grail of HTTPS secureness in a local set-up. You may have come across the following error during attempts to set this up:

"At least one other site is using the same HTTPS binding and the binding is configured with a different certificate. Are you sure you want to reuse this HTTPS binding and and reassign the other site or sites to use the new certificate?"

With help from a fellow work colleague the configuration was found. I thought I would share this to hopefully aid others in their search. Right, down to the goodness!

1. Open up IIS and click the IIS server node and select Server Certificates.
   
   
2. Create Self-Signed Certificate... and name it starting with a wildcard (*) and then followed by the domain name. E.g. *.local
   
   
   
   
3. Now to secure your website. Select your website and select Bindings. Click Add..., select Type as https and choose the newly created wildcard SSL certificate you created above e.g. *.local. Finally enter the Host name of your website which in my case is project1.local.
   
   
   
   
4. Now you only need to repeat step 3 to add more IIS websites that require a SSL. Remember to change the Host name accordingly for each new website.