Visual Studio Team Services having some 'performance issues' Microsoft has said it suspects a code change has caused "performance issues" for its cloud-based code repository and dev collaboration platform, Visual Studio Team Services. At 7:21 UTC this morning, Redmond's team members noted on the status page that "a potentially customer impacting alert" was "being investigated" for the …
I wasted an entire weekend trying to install it.
After installing everything, I ended up losing the standard microsoft project types for C++ and C#, and couldn't get them back even after completely uninstalling everything and starting again.
Ended up installing the bare mnimum on another box the following weekend. (The only other alternative would have been to re-install Windows from scratch).
Still doesn't run as a 64-bit IDE - it gets installed as a 32-bit even on Windows x64.
Still doesn't run as a 64-bit IDE - it gets installed as a 32-bit even on Windows x64.
There is no 64 bit version of Visual Studio and the development team have stated that it wouldn't help and might actually make things worse.
I've not personally had any memory issues with 2015 since the second update. If you are seeing them then make sure your version of 2015 is up to date because it absolutely fixes some memory leaks.
Now don't get me wrong. I use it day in and day out and it frequently pisses me off. One day last week I had to swap between two branches several times in one hour so had to sit through the teeth grinding hell of it trying to figure out first how to unload shit then how to reload shit. Sometimes I have to restart VS to get it to correctly rebuild a solution. WTF is that about? Is this the 20th century?
And don't even get me started on why I have to keep the WPF designer hidden. Fair enough there's a lot to be said for working purely in XAML but it shouldn't kill VS just to render my bloody form. And with it hidden after a few hours it will still enter a go slow phase where it keeps pausing for several seconds when I'm typing. Eventually I get so sick of it I have to restart it..and that means another unload/load cycle.
Someone complained that there wasn't a 64 bit version so I provided a link to a blog where a VS developer claimed that it's a deliberate choice because they don't think it's worth the bother. Just for the record at no point have I ever expressed an opinion on the validity of that statement. I merely thought it would be a useful discussion point.
RE: "No problems here"
So with your data and his - that's a 50% failure rate. Appalling!
Actually; He did go on and succeed with a different machine, so that's 33.33333% failure.
When I get round to installing it I should be able to get the failure rate down to 25%. A bit better. At least its free.
It largely depends on the provider. We've had great success with github and Google docs. Of course they do go down, but it's rare and short (better than self-hosting).
Would I trust Microsoft to provide anything? fuck off - especially if they're dog-fooding. I've used their products.
"It's great...when it works"
Provided you gave the warnings before migration, it's also great when it doesn't work. What used to be endless nagging and hovering bosses is now "it's with the provider, I'll let you know when they do, I did warn yo..." "yes yes, fine" and off to get another coffee and watch the traffic drive past.
This post has been deleted by its author
"There is this nifty new idea some are using."
yeah, and some of them set up DEVELOPMENT servers to test things on, before moving them to production. but you'll need TESTERS to evaluate it properly, or maybe make everyone at Micro-shaft use the DEVELOPMENT server to help work out the bugs...
'master' and 'develop' branches on github. do a merge when you know it works, cross your fingers, hold onto your ass, and hope you didn't break something. And do it at zero-dark-thirty when few people are actually using it [so you don't cause massive outages]. And then TEST the damn thing, to make sure you didn't break it.
yeah, "standard operating procedure" for competent IT people, right?
"Facepalm" icon for how dumb MS was for putting this on the production server without testing it properly, first.
TBH regular expressions are great at solving tricky text manipulation issues, but they suffer from (at least) 2 main issues:
1. The expressions *can* quickly become read-only.
2. They can never match custom-crafted (good) code for a specific usage.
In the case of point 2, I have to question whether introducing a regex into a system under such heavy load without testing the performance characteristics at scale was a little foolish and a little more kraftwerk (sic) might be more appropriate.
Note that this is not to say that a regex would not be fine, just that sometimes they aren't and you need to check.
"sometimes they aren't [ok] and you need to check."
on a DEVELOPMENT server. With a mirror of the production database(s). And a good simulation of realistic activity. for at least 2 or 3 days prior to updating the production server(s), with automated test suites or interns or students or dedicated testers who will report problems immediately and even TRY to produce them.
(the choir says "amen" right?)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
