So, you have decided to Develop/Test or run Demos/Training in the Cloud. That’s Great! That is the right choice. While we are all aware of the benefits of the Cloud. You now have to put your trust and data somewhere else. So it’s important that you feel safe there.
You hear it all the time in the real world. Back up your computer. Because the day will come when something catastrophic and out of your control happens.
Face it, if you are a born and raised .NET Client/Server developer like me, you are now old school. I have been aware of this fact for several years now, but not until late 2013 did it start bothering me. Now it’s 2014 and it’s time to refine my skills. This post is on how I quickly learned basic PHP, jQuery, and web dev. And finally a little bit on the concepts of DevOps.
Last week while I was doing a SharePoint 2013 training using my CloudShare environments as the training platform for my students I found several issues when trying to create and deploy workflows in Windows Azure Workflow (WAW). After some investigation I found that the problems were due to a change in the credentials of the user account used to run all the required WAW services. Basically, all services were stopped since the change in the credentials hadn’t been propagated to all services and therefore it was completely impossible to deploy any workflow to WAW. Below I will explain how I found the solution.
If you are a Developer on the Microsoft Stack, you have surely heard the news about the advancements, and renaming of TFS Services to Visual Studio On-Line. Visual Studio On-Line, announced on Nov 13th, comes with a lot of new technology advancements, like build services, Test Management, Load test etc. But it also changes in a big way the license paradigm for developers, where they subscribe to the IDE and the services they use, versus buying licenses. No big surprise given this has been the approach with Office for several years now. But with all that new stuff, there is a gaping problem left to be solved…
The time of the year for predictions has come, and as in previous years, CloudShare is throwing theirs in the pile. But these are not just any old predictions. I’m going to tell you how the life of the developer is going to change in 2014.
This article is the fourth and final article that cover creating, testing and maintaining a SharePoint DR plan. These articles are from a chapter extract from the book: Microsoft SharePoint 2013 Disaster Recovery Guide.
One of the common issues we see a lot of in the Support Cave revolves around ‘performance’. So let’s set the scene a little. When it comes to connecting to a virtual machine, remotely, from one end of the planet to the other, the number of things that can affect performance can be truly mind-boggling.
When trying to troubleshoot this, the first step is to verify what performance. Ask yourself these questions:
Read the rest of this entry »
In this Post, I will explain why and when you measure your ‘TCP Session Quality (Starting with: What is ‘TCP Quality’ anyway?).
How you can analyse it yourself, and I’ll share with you a recent example where I had to use it myself. For your comfort – I will write it down in 3 phases.
In the CloudShare dev group, we occasionally work with an outside consultant or contractor.
One of the most annoying pains when hiring a developer contractor is the need to provide him with a development environment. The consultant usually wants to work on his laptop in his office / home and needs a development environment immediately. Besides, as opposed to an in-house developer, there is no real value in letting him install and configure his own developer station.