A development machine is always a tricky thing. On one hand you want it to be powerful enough to allow you to do what you want to do (and mostly to be fast and not wait). On another hand you want it to be light and thin. I was debating between Dell XPS 15 15-8949sLV Touchscreen and Macbook Pro 15. Dell was very appealing, have to admit. At $500 (now almost $700) and touch enabled display it was a better candidate. Until I’ve read about overheating issues. That was a show stopper.

This is old news, but still worth sharing. I have shared my architecture with folks from The Azure Podcast for discussion and suggestions. It was a good review and worth listening to.  In case you’re interested, Episode 32 has the discussion from minute 20:30. This architecture is now running 3 of our production sites, with another one on its way for international support with multiple regions.

TLDR: Sitecore on Azure IaaS + Azure Cache (Redis) + Azure Websites / CDN = cost reduction + ease of development + inexpensive migration

An interview process should not end up in a situation of a cat in a bag. A friend of mine is going through an interview process, and I observed his line of thought and decision making. These are my observations along with what I think about technical part of interviewing process in particular.

Job Interview is an art. Interview process puts both sides, interviewed and interviewer, on a spot. Interviewer is trying to find the right person, which might include, but not limitted to personality fit, professionalism, experience, etc. Employer typically has a few things that they are willingly sharing with an interviewed such as working hours, benefits, type of work, and other pieces of information that you migh or might not find out through public channels. Interviewed is looking to find out as much as possible about working conditions, expectations, overall compensation, fit into his/her personal work/life balance, etc. There’s always a technical interview, that frankly I don’t accept anymore in the shape and form it happens these days. More than that, I think that interview and technical question(s) are a good way not only for interviewer to determine if candidate is the right candidate for postition, BUT also for an interviewed help to determined if eployer is the right place to invest time into by taking the position. My friend`s test is a good example for that. He was given a mini project to build, a web application, that is using a framework he’s never dealt with. Initial “business requirements” of half a page of bullet points were given to him. He approached the test and here’s the conversation we had I’ll try to analyze.

In 2010 I had an experience to work for a business that had lots of challenges.

One of those challenges was luck of technical architecture and business value recognition which translated in spending enormous amount of manpower and money on creating C++ solutions for desktop client w/o using .NET to minimize “footprint” (2#) of the client application in deployment environments. This was an awkward experience, considering that C++ custom code was created from scratch to make clients talk to .NET backend while simple having .NET as a dependency would cut time to market by at least 50% (and I’m downplaying the estimate). Regardless, recent Microsoft announcement about .NET vNext has reminded me that experience and how short sighted architecture at that company was. Investment made into making C++ client that cannot be maintained internally by team due to it’s specialization in .NET have created a situation where code to maintain will be more brutal over the time and  number of developers understanding it will be going and shrinking. Not only that. The ability to go cross-platform (#3) and performance achievement gained with native compilation (#1) would be an immediate pay back.

If every future 0.1 update will be like this, I don’t dare to imagine what 1.0 update will be like. So far it was a very pleasant experience. In the past updates where more of a roller-coaster: you expected a lot, got some of that, and eventually found that there’s still a lot that was missing. For the first time that I have windows phone an update contained more than I have expected to see.

For those who were fast to bury it, here’s some update:

If you’re running into a bug like I did, there are good and bad news. Good – Microsoft acknowledged this bug and will fix it, bad – it will happen in the next release (not sure then). In MS favour I have to admit that they turn things really quick, so who knows, it might be already in the release notes of the next release :)

The idea behind this is extremely simple: to run a deployment machine in Azure that will be used to deploy updates to production. In my environment we get everything packaged on build server, but deployment has to happen in a controlled environment and from a manual kick-off. Deployments are not performed at night, hence compute time is wasted. To save 50% (at least) of compute time, VM has to be down.

A year ago I have started looking and evaluating cloud options. AWS and Azure were two options. I have decided to go with Azure for a couple of reasons that are still valid today (even more than a year ago)

1. As an MSDN subscriber, I could leverage MSDN credits that are sufficient to learn
2. PaaS on Azure was very appealing while on AWS it seemed a little foreign and not as friendly as AWSs IaaS offer (a year ago Azures IaaS was very poor, so for infrastructure purposes only I’d probably wouldn’t choose Azure back then)
3. Simplicity, or at least perception I had

As an MSDN subscriber you get a LOT. You get credits on Azure that you can use towards anything you want (PaaS, IaaS, developer services, etc.) You can run production on MSDN subscription, but you can learn. And learning is important. I would strongly recommend to go beyond a single MSDN subscription discount and get a Pay-as-you-Go subscription to test out things. You can read documentation, play with cost calculator, but nothing, I repeat NOTHING, will replace the actual usage where real people are hitting your service, storage and CDN transactions are happening, when you run your minimal viable product with scale out as needed, leveraging developer services. If you try to shave off that cost, you’ll never fully learn. After all, without errors there are no successes. If you try to minimize the risk to none, you better not get on cloud at all.

Early testing is amazing. I am not talking about TDD and developers testing their own creation. I am talking about testing performed by professional QAs with mindset to hack the heck of your system (code, server, deployment, you name it). The value of early testing vs. late testing in SDLC is very easy to show to those that deal with with software on a daily basis and live it everyday. But how do you translate it to the business? Visualize it. One is high level – show one approach vs another and start asking questions.