I think it is the battery which didn’t charge properly any more.
The Forerunner 405, it was my first wearable device, connected with the internet. I also got the Heart Rate Monitor, the Foot Pod and the Speed/Cadence Bike Sensor sensors. Too much fun all these sensors when running.
All these hypes now days around wearable computing sounds a bit strange to me, it was already there five years ago. In what stone age have all these analysts lived these years. For sure they aren’t runners, they would have know better.
It is funny when I think back about a talk I had after I bought this Garmin device about logging my activities the guy was amazed I logged everything, he is now wearing a FitBit.
I had my Garmin for five years and I did run 5.390,06 km with it for 482:47:13 u:m:s. The device did cost about 300 euros (I think, not exactly), a simple math gives us that the device cost 5 cent per km, or 60 cent per hour. I can live with that.
I did two marathons with it:
I did many half marathons as training in the Amsterdamse Bos (my backyard)
I ran in Dubai, slowly due to the heat.
and in Seattle, with a beautiful view on Mnt Rainier
Did some hiking in Norway.. beautiful
Many times ski touring in the Swiss and Italian Mountains
And many many more, finally more than 500 activities have been logged with my 405 the past five years.
I sure want a new one, apps on a mobile device can’t replace it.
But, have to save some money first... I like the Fenix 2
Azure for Teams
Having Team Member IDE’s on Azure provides create benefit for teams in moving fast and staying flexible.
But there are still some items you have to think of when start adopting it, networks being connected is an important one:
You never ever develop or work in isolation. Especially with the heterogenic systems we build now a days. So, being connected with the world from your Azure hosted Visual Studio IDE is a must.
For example, the SQL Server database you are consuming in your App is in the local data center. You need a connection to that datacenter from your Azure environment.
You can create a Site-to-Site VPN, for connecting datacenters to an Azure site or Point-to-Site VPN, when connecting a single machine to an Azure site.
· Configure a Site-to-Site VPN using the Management Portal Wizard http://msdn.microsoft.com/en-us/library/windowsazure/dn133795.aspx
· Configure a Point-to-Site VPN using the Management Portal Wizard http://msdn.microsoft.com/en-us/library/windowsazure/dn133792.aspx
This can be challenging, not from a technical perspective but more form an organizational perspective. From Azure you can setup a Side to Side network connection to the datacenter, but this also requires some changes in the company policy in connecting to Azure. Some IT-departments aren’t ready for that.
A solution can be, put the SQL Database beside the VM’s in the same Virtual Network on Azure.
Azure for Teams
Having a Team Member Desktop brings a team great benefits. Self-provisioning of environments for team members is one of these benefits, give the control to the Team responsible for the realization of the system. Helping to solve the team challenge of delivering fast and flexible new software.
Beside this single scenario which makes the team faster and flexible. There are many more possibilities for teams in using a Team Desktop on Azure, possibilities which bring new opportunities and benefits.
When you can create a Team Member Desktop in the Cloud for a single person, you also could create multiple for a complete team.
The start of a new project is an investment with a risk.
Most often after a few sprints it starts to get clear if the project is viable. The customer (product owner) gets the first drop and gives direction on the development. This direction could be, stop with the development, move to a different platform or some other mature change.
Changes in insight could result in losing the investment of project startup. Minimizing the investment will make it easier to move. Lowering the barrier to start a new project with less investment will give teams more possibilities.
Creating Team Desktops on Azure for a complete team, with multiple disciplines, will solve the team challenges of having Small Budgets and lowers the investment risk.
You could create every IDE in a separate personal MSDN subscription. Beside this is boring work it is also better to have team member connected in the same network and the environments managed via a project Azure subscription in an Azure Enterprise Subscription.
When a project has its own Azure subscription, they can manage their own ‘base’ images used to create the team member development environments, and other environments. Having all the project costs in one place.
This script is a good starting point, it creates four VM’s in an Azure network.
Model driven development and code generation comes in many different forms, and all have the same promise: faster delivery of business value. Not every form has been even successful in realizing this promise. Where some have died silently in their own complexity, and some are standing still in innovation for years, there are other ‘generation’ solutions who are getting the momentum of success.
Learn about the MDD approach and how you can apply it to achieve the maximum business value and reduce the cost of solution development.
Article from 2006 - Implement model-driven development to increase the business value of your IT system- http://www.ibm.com/developerworks/library/ar-mdd1/
Model driven development is about the changing the abstraction level of the used programming languages to realize business value. When you make the language closer to the business solution than C#, C++, Java or any other programming/ machine language it is easier, and more accurate, to describe the solution. When you can run this, more abstract, language (or model) the same way as program languages are executed, than you have a model driven approach. More high level languages, describing the business can be used by the business to describe their own solutions. And, more low level abstraction languages and models can be used by engineers to describe a more technical solution. With these new languages it is easier to communicate about the specific domain, a domain specific language.
In Application Lifecycle Management * languages and models describes the different domains. A specific languages used to describe the business domain are often technology and platform agnostic. While specific languages used to describe the solution are often implementation and platform independent, which gives less re-use.
* Application Lifecycle Management is about the whole spectrum of software development, the processes that are used, the people who use it, make and maintain the applications and about the tools and technology that are used during the complete lifecycle. Application Lifecycle Management is not only about software development and a grown-up development environment but also about business, operations and the connection between these domains.
In both domains, the business and development, domain (often called the problem and solution domain) new possibilities, innovation and business opportunities are insight. But, for both domains making the decision to adopt model driven development need to be taken careful, a well tradeoffs process needs to take place.
With business domain specific languages the promises to gain benefit of fast realization of business value are the biggest.
It is a language used by the business / domain experts to describe the ‘problems’ [needs], the models can be used to generate code or can be executed on a platform.
Vendors who deliver technologies to create and execute Business DSL’s are for example MetaCase (http://www.metacase.com/) and Mendix (http://www.mendix.com), both mature in the solutions they provide. Microsoft has Domain Specific Languages capabilities in its development IDE (http://msdn.microsoft.com/en-us/library/ee943825.aspx), and Eclipse has one of the most used DSL tools addin (http://www.eclipse.org/modeling/ based on the open source project openArchitectureWare). MDA based on UML is another technology for MDD http://www.omg.org/mda/
There are a few adoption challenges with business domain specific languages. One challenge is the clear description (Meta language / the grammar) of the language. Now day’s business are moving and changing faster than the language can evolve. Microsoft changed to a Services and Devices Company, the language used to describe the business needs to change too. And, creating a specific business specific language isn’t that easy.
Another challenge is the execution of the models (languages) on the platforms. The language must be interpreted by the platform to run, or compile to executable code by the platform (see image above). Creating a compiler or an interpreter is very specialized and technical work. Maintaining these will need some effort.
The last challenge has to do with team work. Probably multiple people will work on the business models. Multiple versions of the models will live in different stages of the development process. Maintaining these model versions, work together on one model and find the differences between versions of models is a challenging task. Current available development and modeling environments aren’t mature enough to capture this.
The above mentioned technology vendors target these challenges, and while the innovation of platforms evolves they also need to evolve to execute the models on these new platforms. This will definitely help to lower the maintenance of software systems. Innovation goes slow and only for specific cases promise of faster business value is reached, when you have such a case it definitely pays off to investigate the possibilities.
Technical domain specific languages are used by the team to describe the solution domain. Where business domain languages have the benefit that the subject matter expert can describe the problem. With technical domain specific languages (and models) you loss this benefit. But there are already a lot of specific languages in place for the solution domain, which getting more and more mature.
There are more technical specific languages for one specific domain. For example SQL is a language for working with data. Another specific domain language is WiX for describing installer packages. On the other side there are also languages which are closer to the business. For example Smart User Cases ( http://www.smartusecase.com ), which uses specific User Case stereotypes to describe the business needs and generates with accelerators code, test cases or any other project artifact when there is an accelerator for. Code is generated and executed on the platform, so it is easy when solution is described to generate code for another platform.
Both most technical and business languages models are having the same adoption challenges. Hard to create the language, stay in sync with the platform innovations and use them in teams. But, technical languages are easier to adopt for multiple reasons.
One reason is that the created models and languages can be reused more often, they aren’t business specific, but can be used for multiple business domains. Which makes them more mature, robust and they are probably maintained by a technology vendor or open source group. And, innovation will move faster with more people using them.
For example Visual Studio LightSwitch is an addition to the Microsoft development platform to create business applications for the Desktop and the Cloud. Visual Studio LightSwitch generates the underlying infrastructure. The database, transaction mechanism and helps you craft the screens, which when you choose to build a HTML Client generates a responsive website which runs on all kind of devices.
Not only code generation (or model interpreters) have to be used for domain specific languages also specific frameworks for specific tasks are enablers for faster (and more reliable) realization of business value. Java is a kind of famous for all the different frameworks created for it. Examples are more technical Frameworks like the Spring Framework, but there also have been implementations like an Open Healthcare Framework.
In the same area as Frameworks you can find API’s, Application Programming Interfaces. API’s are the new enablers of fast business value. For almost every business problem there is an API available. The difference with Frameworks is that you don’t have to incorporate them in to your solution, you just use them.
The website ProgrammableWeb.com has a collection of 9920 APIs. With additions every day on all kind of categories, ready for business use with as an interface, a language to help with a specific technical or business domain problem. Use them in your solutions for fast enablers of specific functionality or stich several API’s together with additional business functionality and great a valuable mashup.
On the same technical side as API’s, as fast business value enablers, are Cloud Services. Cloud Services provide specific functionality for systems. The biggest difference with API’s is that Cloud Services provide more the technical infrastructure where API’s provide more business functionality. When your App needs to work with data, authentication or push than cloud service are a fast enabler.
A good example are the Microsoft Azure Mobile services and Media Services. Services that provide configurable functionality with generated code for your systems. It is possible to create it from scratch, but instead of hours it will take days to realize it.
In the area of Cloud Services innovation really moves fast. Services to enable faster business value are added almost on a daily base.
Other Cloud Services where innovation goes fast are services which helps development teams to do their job. Examples are Test and Development Platforms as a Service preconfigured and ready to use environments to quickly start working. Others examples are Load Testing from the Cloud and automated test execution on the Cloud.
Generate systems in the browser
One last innovation which takes off, are the web-based / do it yourself system generation sites. Where cloud services like Media Service from Azure provide generate code which you can incorporate in your code base. These generators are providing ready to use systems from the Web or Apps. A very successful is Windows Phone App Studio. Windows Phone App Studio is a website to generate a full working Windows Phone App in minutes, published to the store.
Another one from Microsoft is Microsoft “Project Siena”.
A very interesting innovation these kind of ready to use generators will available more and more, delivering the promise of code generation. But the generated solutions aren’t business ready, not unique enough, and need defiantly customization afterwards. I actually think it is create for trials, before doing the realy.
Insight on code generation innovation.
Code generation and model driven development are technologies with a promise to realize faster business value, but they are not always as flexible as the business need these days.
Specific to the situation it fulfills this promise. Where the generation from models (domain languages) on the business side are even more specific and should be analyzed careful be for used. But, when the business models are well implemented they will bring the most and fastest business value. Innovations on this area goes slow.
On the technical domain, code generation from models or specific languages (Lightswitch, Entity Framework) are well adopted by teams. The same for API’s, which add easy business knowledge to the systems. Both can benefit from and should use each other. Innovations goes faster in this technical domain, just due to the more frequent use than on the domain modeling side.
Fast innovation takes place in the Cloud Services stack, configurable services with ready to use code in your systems. More and more services will get available in an increasing pace to deliver that business value fast for your business users.
Got some scary moments after the upgrade to OneDrive, all my offline work was gone (which I’ve done during vacation, even worse :-).
When I upgraded a new folder was created named OneDrive and that one was synchronized with my O365 data, which didn’t had my local changes.
Lucky the old one was still there in C:\Users\Clemens, which isn’t a folder I open that often because I jut use the default Windows settings for maps. Copy pasting my offline work to the OneDrive folder did it.
Anyway, got to know.
Now it is still strange why my ‘new’ OneDrive doesn’t have the sync icon, but still is on the ‘old’ SkyDrive folder.
Azure for Teams
When onboarding a developer the time between entering the team room and the first meaningful check-in, is waste.
In the same category the time between a testers enters the team room the first meaningful test specification or test execution is waste.
As everybody knows from Lean, we should aim to identify and eliminate waste in our projects. Mean Time to Valuable Activity is waiting time, time where a team member is idle and is not adding any value to the finished good or service. Creativity is lost, motivation flows away and talent isn’t used, what is another waste type in the 8 waste types defined in Lean.
Onboarding team members is hard. Multiple challenges needs to be handled: understanding the system, knowing the team work ethics, get the necessary tools, get access rights, etcetera.
Team Influence zone.
Most activities are in the teams influence zone. For example, time to understand the system been build can significantly be reduced by lowering the technical complexity. Another good reason to focus on Technical Dept as a team, the same for the methodology used. Activities which are in the hands of the team are adjustable.
Getting the necessary tools, equipment and access rights is often not an activity teams are allowed to handle. For usages rights the internal infrastructure department needs to give approval, for workstations and licenses some / multiple managers needs to sign documents. Sometimes it takes weeks before everything is agreed up on and in the hands of the new team member, ready to start the first meaningful activity.
Team Desktops on Azure
Time the new team member is waiting for equipment is waste, creativity is lost, motivation flows away and talent isn’t used. To remove this waste, is to give control to the team of every activity necessary to onboard a new team member. Technical Dept was already in their hands, getting the necessary tools is the one to get focused on.
With development and test environments in the Cloud (Team desktops on Azure). A team can get much more self-organized. Provisioning new environments for new team members on the fly without any interference of other internal departments, ie people outside the team.
A Team desktops on Azure is nothing more than a Visual Studio or Test Manager environment running on Azure VM’s (IaaS). With the Azure capability of creating your own discs teams can pre-configure the preferred IDE.
When having a MSDN subscription start using Team Desktops on Azure very easily can be done, most often within the boundaries of the subscription benefits.
When getting more mature in using Team Desktops on Azure, an Azure Enterprise Subscription is necessary. A good practice is to create a sub-subscription per project at start of the project. For sure with a team member as co-administrator of that subscription.
When teams can self-service the onboarding of new team members waste is minimized and the new team member is delivering faster more motivated business value to the project. Reducing the time to first meaningful check-in or test specification or test run is a good metric.
We just released to Store the Visual Studio Online Quality Dashboard WIN8 App. An App which helps you being informed how projects are doing.
The start screen loads all projects the user is member of and visualizes the last build run state and date.
In one overview you can see which projects needs your attention. With personalized project images you also can easily navigate to you specific project.
(setting the personalized project image can be done in the project detail screen via the appbar.)
The project detail pages provides three key quality metrics of your project; unsolved bugs, test cases and feedback items.
It can take a few seconds before the data loads, when opening a big project for the first time.
Scrolling to the left, shows graphs and more details for these quality metrics. An important part in the middle are the build definitions.
When scrolling even further to the left shows the tasks board of the project. Which is fully functional.
Drilling in to a build definition gives an overview of last build runs with the change set details and code changes.
Bugs, Test cases and Feedback
The Bug, test cases and feedback work items views for navigating and editing of specific work items.
On the project detail screen the Add TMap Tasks gives the user the capability to add predefined Testing Tasks to a Sprint.
Selecting a task gives some more details about the task.
After selecting TMap testing tasks and a sprint, you can upload them to you project in a single click.
The implementation is based on the TFS OData API https://tfsodata.visualstudio.com/
Read more about it:http://blogs.msdn.com/b/briankel/archive/2013/01/07/odata-service-for-team-foundation-server-v2.aspx
Telerik controls are used for the graphs: http://www.telerik.com/products/windows-8/overview.aspx
Suddenly builds start to fail on a Win8.1 project, with the interesting message “Could not find a part of the path ”.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets (1512): Task 'GenerateAppxSymbolPackage' failed. Could not find a part of the path 'D:\Work\drops\projectName_188.8.131.52_Debug_Test'.
This messages is due to the fact that a team member runs the Package Creation Wizard from Visual Studio, sets the Bundle drop location and put the solution in the source repository.
The build server wants to use the same location as the value set by the developer. it is not saved in the Package mannifest, but in the csproj.
the value is saved in the csproj <AppxPackageDir> key, setting it during the build would be better. Setting it to a drop location known by the Build Server solves the error.
cross post from labs.sogeti.com
Teams need to move fast, every action which results in wait time must be minimized to zero. Teams need to move flexible, context changes must be easy adoptable by the team and the system they realize.
Two very clear, but hard to accomplish aims. One challenges teams face today in reaching these goals are the availability of environments.
Development environments are hard to setup with mostly big hardware requirements. For example setting up a SharePoint 2013 development machine requires a lot of knowledge and time on an very powerful machine.
This will probably slow down the onboarding of a new team member. Requesting the proper hardware, read the book J install, configure and setup the environment.
The same for the environments that are used by testers. Every developer needs his own machine to develop on the solution, also testers need environments to plan, specify and execute tests. This means not only developers environments need to be available also for the tester a separate environment to execute their tests on needs to be available.
For just a normal development team it will work like explained in this video and diagram:
It gets interesting when the team runs sprints of one week and deliver every week a new increment. An increment which needs to be installed on a clean environment. With for this example a clean SharePoint environment, ready for validation. And, let’s say the team releases every four sprints a release for validation by customers an environment, which has the same characteristics as the production environment must be available.
Asking the supporting operations department first every week a new integration and test server and every month a clean ‘production like’ environment will make them crazy. Probably operational rules will even make this an not supported scenario and slows down the team in delivering value.
Two activities; onboarding of team members (Development), and the availability of environments (Test and Acceptance) are slowing down the team. Not only the complexity, but primarily the company dependencies (approval) which come with these activities bring teams value delivery to a full stop.
Dev and Test Platforms as a Service.
Virtualization is getting mainstream, even IaaS (Infrastructure as a Service) is wildly adopted, teams are using them, the benefit can get higher. Ready-to-use platforms easy to spin up for team members. Microsoft already delivers a Platform (Azure VM Template) preinstalled with Visual Studio 2013. http://www.windowsazure.com/en-us/solutions/dev-test/ (see screenshot)
Not only the pre-installed and configured VM’s from Microsoft can be used for this scenario, also the community started to make VM’s http://www.hanselman.com/blog/Over400VirtualMachineImagesOfOpenSourceSoftwareStacksInTheVMDepotAzureGallery.aspx
The other dependencies.
The tools are there, team members are powered with the capabilities they need to have. Now we get to the biggest problem, company policy and restrictions. Who is going to pay the bill?
Probably a complete sign off mechanism starts when a team needs something. A request for a new laptop is formalized in a full workflow with signatures on multiple documents, only getting approved with a proper business case it will probably take a few weeks, two when its fast but when someone is on vacation six till eight weeks. This same request – approval process is used for cloud possibilities. Cloud possibilities which are needed to move teams fast and flexible. This is definitely counterproductive and this dependency need to be solved fast.
Give the power to create environments in the hands of the people who need them. Then teams are ready to get along with the current development (and test) practices to move fast, flexible and deliver business value add a cadence the business needs.
In Visual Studio 2013 RC there is a new template in the SharePoint / Office section, the Cloud Business App. A LightSwitch SharePoint Auto Hosted Solution. With this template you can create Apps with LightSwitch for O365 SharePoint, a powerful combination.
Although LightSwitch development is that quick that it almost can be done by a single developer. But when the business requirements are getting bigger, team development with decent development, test, acceptance and production environments are a must. when this is needed, there are a few things to pay attention to, one is actually due to the nature of development in SharePoint, developers have a Developer Site for debugging. Another one is data, tables/ lists, when you make a table change, data can be removed. And one related to LightSwitch you only can create a package for a specific site.
A Cloud Business App / LightSwitch SharePoint App (O365) development and test environment.
Multiple developers work together on one LightSwitch SharePoint App.
Each developer is connected to Team Foundation Service for agile planning and source repository. Also, each developer will have his/her own SharePoint Developer Site for debugging.
Every day / every hour a ‘get latest’ is done to verify integration with the other developers.
In this way every developer will stay in sync with the rest of the team and will have it’s own environment (and test data) for debugging. Not interfering with other developer debugging actions.
Testers are connected to Team Foundation Service for test planning, test case specification and test execution. Testers have their own ‘Test’ Site n O365 with a ‘stable’ App or more important with stable ‘test data’.
(4) Triggered by testers in the team a new package is created and uploaded to the App Catalog.
When a SharePoint data source is used in the LightSwitch App the connection string needs to be changed before packaging.
Testers are now able to freely test new functionality without disruption from debugging sessions from developers. Packaging and publishing is tested too in this way. A faster way can be to give the testers in the team a developer site too, and let them test from there. They will need to have Visual Studio for publishing.
Testers validate the same functionality in the sprint as the developers realize in that sprint. So, packaging ad republishing is done very often. While SharePoint and LightSwitch are very good in upgrading the data it takes many minutes, this requests a good tradeoff when to validate new functionality.
Connected App Developers
Most often a system doesn’t live on it’s own. WinRT Apps can be connected to SharePoint 2013 Lists very easily. With this development in the team too an additional site needs to be created for them to provide a stable integration endpoint.
Developers building connected apps have a separate site which they connect to. Test data will be isolated for them so they have a stable set to test with/ debug their own apps with.
Again packaging needs to be done from within Visual Studio to set the connection string for this specific site.
Integration Testers can use the same environment or setup.
Acceptance testing is done on a separate O365 environment from a package created and uploaded to the App Catalog.
Publish – connections string
The only ‘not so comfortable’ part is that for every deployment on another site you have to set the connection string of the data source.
This is only needed when you use SharePoint Lists as a data source, and the lists must be unique for that site. A workaround for this is that you make use of the SharePoint App in the Solution and add the needed Lists to it. Then these lists will be created when you deploy the App. Drawbacks from that solution are that the data in the lists are harder for SharePoint Search and that you can’t use them as a data source in your LightSwitch solution. Which result in that you have to access the tables with CSOM because the entity model isn’t available. When done careful setting the connection string every on publish is a good enough.