The legislation has changed in Romania and now it seems every dog owner, when innoculating the dog against rabies, he must also implant the dog with a microchip and record himself in the national dog’s owners registrar.
It’s a good thing, let’s hope it will help a little with our national astray dogs problems.
I had to do the implant last Saturday. I’ve told my coworker about this and his reaction was “ok, now you have an android dog” :-D
Finally, we’re approaching the RTW for our new web site. It’s been a long fight between Eddy’s desire to achieve perfection and our experience telling us “release when it’s good enough, improve only what has to be improved”.
And the unpleasant surprise for me: as I’m practically responsible for the team (sort of a jack of all trades, joggling project management, product management, requirements, lead developer and plain developer) I was the first to check the site on different browsers. Go figure: of course it doesn’t look the same on Safari, although it looks exactly the same in Chrome and Firefox!
So here’s yet another pain point for web development: on desktops, with WPF, you no longer have to worry about resolution, for example: if your design is smart, the UI automatically adapts to different resolutions. Only smoke tests are needed in the beginning to validate the design assumptions (we’ve always tested on the lowest common denominator, which is 1366×768, the smallest screen resolution available on laptops).
On the web, even all our web developers are so enthusiastic about their JS libraries and HTML skills and CSS capabilities, one still has to continuously check on all browsers. No JS library can guarantee exactly the same layout on all major browsers.
We’ve moved our sources in VSO and so far everything is good. After installing Team Explorer 2013 with Update 2 on our Teamcity build agent, we’re able to run automatic builds and the automated tests, as well (ours are XUnit-based and while Teamcity does not support them OOB, the configuration procedure is easy and well documented on many blogs).
Now, here is why I’m writing this post: only the sources for one project are in VSO, there are many other projects I’m responsible for and their repositories are still in the on-premises TFS.
I really like the way VS allows the user to switch between TFS servers. It Just Works! We’ve been working like this for some time now and no problems occurred! You can work with VSO, then switch to another TFS server, open another VS instance and connect to a different TFS server … and it works, no login failures, no poorly synchronized repositories, no bad CI-s.
We’ve moved our sources to VSO. So far, so good, however we’re still not able to run a Teamcity build (still getting TF300036).
So I’ve decided to create a VM with a TF Build server and agent. Installation went smoothly, Hyper-V, Windows 2012 Server Setup and TF Setup are quite stable and helpful.
But … our teamcity build executes a custom PowerShell script, because our build is quite complex: we have to build a set of binaries, obfuscate them, digitally sign them, create a setup, run a tool that edits the msi file (vdproj-based setups are really limited and we’re still allocating all resources to other areas than implementing a nice Wix-based setup), create a SFX, edit the SFX to set an icon and so on.
There’s a nice article on MSDN on customizing a build template at http://msdn.microsoft.com/en-us/library/dd647551.aspx.
I’ve started to run through the steps and I’ve got to the point where I deeply miss the PowerShell script. For every action I have to scan the toolbox pane and it’s really counter productive! For a developer, a normal tool is one that allows him to use drag and drop or directly write some code and obtain exactly the same result! Our toolsets are not there yet.
- Configure an on-premises system with TFS 2013 Update 2. Only install Build Server and connect it to your VSO repository.
- Install the software needed to build (like Winrar, reshack, etc).
- See http://blogs.msdn.com/b/aaronhallberg/archive/2008/07/28/a-minimal-tfsbuild-proj-file.aspx
This allows you to use the existing build scripts.
Use the following links to create a custom build activity: http://msdn.microsoft.com/en-us/library/dd647551.aspx. You can use C#, although the article says you should create a VB project.
All information is extracted from http://azure.microsoft.com/en-us/support/legal/sla/
Web sites SLA is 99.9%, calculated over a monthly billing cycle. That means a web site should not be available in a month for at most 43.8 minutes.
Important note for web sites: to be covered by SLA, the web site must be deployed at least in the Basic web hosting plan mode.
Traffic Manager SLA is 99.99%, calculated over a monthly billing cycle. That means during one month the traffic manager system may not respond for at most 4.32 minutes.
SQL Database SLA is 99.9%, calculated over a monthly billing cycle (maximum downtime 44 minutes).
Cloud Services when deployed with at least two role instances in different fault and upgrade domains, the Internet facing roles will have external connectivity at least 99.95% of the time.
When deploying a web site, use a “web role” instead of a “web site”.
Implement retry logic in the code accessing an SQL Azure database (for example, Entity Framework 6 has this logic built-in, see http://msdn.microsoft.com/en-us/data/dn456835.aspx).