All the time, and I fix the warnings if they come up. It’s greatly reduced the number of null exceptions that get thrown. I’d prefer it though if they were reported as build failures by default.
Eagles may soar, but weasels don't get sucked into jet engines
It's a very common practice for features to be developed in their own branch, often with a single developer working on each feature. This process ensures incomplete code isn't released to production and allows for peer review through the pull request process.
Eagles may soar, but weasels don't get sucked into jet engines
What about an Azure app service, for that much expected traffic they could be on one of the lower pricing tiers.
Eagles may soar, but weasels don't get sucked into jet engines
So TFS of old was terrible, but 2013+ is a completely different story and is one of the best ALM tools out there in my opinion. Just make sure you know how you're going to want to use it and what the licensing implications of that usage pattern will be. As one possible suggestion, rather than looking at TFS on-premise why not also consider Team Services[^] which is the on-line hosted version. It's the same product but receives all the updates first and is managed for you. You still need to think about how your going to set up your teams and projects but at least you don't have to think about software upgrades or server patching etc... It also makes working with external parties a lot easier as you don't have to give them access to your corporate network. If you still need to go with an on-premise solution then the best place to start is the online documentation[^] which is actually pretty good. If you are going to work with external organisations who will need access then consider a multi-server setup where you keep the database internal and setup the application component inside a DMZ (other setups are available). Have fun
Eagles may soar, but weasels don't get sucked into jet engines
We're set up here now with SonarQube hooked into the CI system so if test coverage on new code is below 80% the change is automatically rejected (and it does reject changes). We still get people saying "I don't understand why I need to test", which I hear as "I don't understand why I need to write higher quality code and catch issues earlier when they can be fixed more rapidly and where it's cheaper to do so". I find that if you can set up a system to show unit tests being run, coverage information and actions being taken when issues are found then there tends to be more corporate buy-in. We had a senior manager here who wanted screens up so he could see the information each time he walked by the different teams.
Eagles may soar, but weasels don't get sucked into jet engines
Echoing the sentiment of most others here, but it seems that the approach in general is wrong and I can confirm that by having gone through something similar to this myself. I think there's enough technical content already giving you guidance on how to resolve this with Git, so I'll just add my bit about process. If you're in a slow release cycle approach of working then adopting something like GitFlow[^] could be beneficial but you need to make sure that the branch practices are followed, if you can enforce it with tooling then so much the better. We're using Visual Studio Team Services with Git and have adopted branch policies which prevent changes going on to certain branches unless by pull request with certain conditions met (e.g. reviewed, builds, tests pass etc...), I'm sure there's others way of doing the same with other tools. If you can release much more frequently then you can probably do away with most branches and simplify down to master and feature branches, but you need a rock solid release pipeline to make this work well, convince people that failing forward is a better approach to a rollout/rollback release process and have the organisational structure in place to support frequent and rapid releases. A lot of companies are still on their way to that or just aren't moving at all, so this is typically an aspiration to bring about other changes. It took a while for us to get a good branching strategy working and even now we still run into some issues which just seem insane to me (e.g. "why can't we have multiple people in two teams working on the same code file?"). But if you're willing to review current process and have team/business acceptance change it then you can get yourselves into much better position.
Eagles may soar, but weasels don't get sucked into jet engines
Using Visual Studio Team Services here and it's great, naturally not using TFVC for source control but as VSTS supports Git why would you? Back in the days of TFS 2010 then yeah, that sucked pretty badly. 2013 got much better but Team Services is where it's at for me.
Eagles may soar, but weasels don't get sucked into jet engines
WinSCP .NET Assembly and COM Library :: WinSCP[^] is probably your best bet for doing this. You can get the package down from NuGet Gallery | WinSCP .NET assembly[^]
Eagles may soar, but weasels don't get sucked into jet engines
Oracle in the cloud, who would be that mad! I mean SQL Server in the cloud, Azure SQL
Eagles may soar, but weasels don't get sucked into jet engines
I've worked on a project which used both Oracle and SQL Server, the latter was easy and the former lost me whole weekends trying to get the right DB/Driver combinations. Objectively both have their strong points. Oracle is a very powerful database system whilst SQL Server is more flexible, easier and so _much_ cheaper. If I was to start a new project tomorrow and had to make the decision I'd choose SQL Server, but I'd go to another level of ease and just use Azure SQL because, you know, geo-replication in a few clicks, huge resiliency and easy scale.
Eagles may soar, but weasels don't get sucked into jet engines
Often the biggest problem is being viewed as objective. I find myself often in a position of defending code from people who are upset that they couldn't join in, and pointing out bad code in projects (including my own) to get people to up their game. The thing which I've found works best if to have tooling which can provide an objective view of the code. My two favourites being ReSharper and SonarQube, the first because it provides immediate feedback and helps fix a number of issues and the latter because it provides some great metrics that can be tracked (great if you can make it part of your build process). Building these up to show the team and your manager gives you the ammunition to show that you know what you're talking about and helps the team measure themselves against an objective measure. Of course there may be things like coding styles which people don't agree on (yourself included) but if everyone follows the same rules then things improve and it makes sure that everyone can read the code easily. Once these are in place you can build up some internal guides on coding practice to help new starters and as refreshers for existing people. It can be a long journey, but if you can present it as "it's not me complaining, look here's the proof" then it's an easier pill to swallow.
Eagles may soar, but weasels don't get sucked into jet engines
Yep, using it and loving it. It's great for a lot of things including editing markdown
Eagles may soar, but weasels don't get sucked into jet engines
I do indeed. You need to spend some time ensuring that your entity changes will produce the database design you're expecting (e.g. table-per-class, table-per-hierarchy etc...) and you may want to write some helpers to make adding things like indexes a bit easier but otherwise I've found it to be a very neat way of doing things. One thing to consider though is your initial database creation, for this I'd suggest either having a script to create the database and manage the configuration of it (not my preferred) or create a Database Project and output a DACPAC (much better and has better deployment options if you're using MS SQL Server). The reason for this is that if you use something like EF migrations then you'll get default database settings and sizings when it's created which you may not want, using a DACPAC means you get control over things like collation and recovery modes.
Eagles may soar, but weasels don't get sucked into jet engines
Same as everyone else really. Check your contract to see who resignations should be addressed to as amazingly it's not always your boss, work out when your last date of employment would be and then keep the letter to the minimum even if you really want to say more. Also if it's not your boss who you need to write the letter to it's worth dragging them to one side and informing them what you're about to do (always try to be the bigger person). Then it's just a case of picking your wording, addressing to your boss or "To whom it may concern" if it's a generic HR department. > Dianne > > This is to inform you of my intention to terminate my employment with Wacky Rabbits Corp as per the terms > of my contract with my final date of employment being the 14th February. I wish you and everyone else all the > best for the future. > > Regards > > Krusty Or something similar. Just don't let it get personal though, you may need to come back for a job in the future, or you may find yourself encountering your current boss at a potential new employer.
Eagles may soar, but weasels don't get sucked into jet engines
It depends on what you're wanting to do. I've got an original Raspberry Pi Model B which is now a computer for my 5 y/o which does him fine and runs Minecraft perfectly well. So if you want a low powered computer for hacking around with I'd go for the Raspberry Pi 2 Model B, but if you're looking at doing some IoT stuff, or controllers for robots etc... I'd have a look at the Pi Zero
Eagles may soar, but weasels don't get sucked into jet engines
I work across multiple teams running scrum and kanban, mostly it works well and I quite like it as long as the people working on it are pragmatic and stick to core principles instead of religiously sticking to the text book. We're using Team Foundation Server for backlog management, boards etc...
Eagles may soar, but weasels don't get sucked into jet engines
I would say that poorly formatted code makes it more difficult to maintain (depending on how badly formatted it is exactly), if it's not easy to spot a bug in the slop then it's harder to fix. Of course, if you have something like ReSharper installed then CTRL+E+C :) at which point there's no excuse for sloppy code and the offender deserves a thorough booting!
Eagles may soar, but weasels don't get sucked into jet engines
Absolutely I use a profiler. You're right that looking at code can often provide the answer, but when you're code base is several thousand lines of code split across multiple components using a profiler can at the very least help identify where the problem is. It's also useful to spot things which might not be a problem with your code. Maybe a library you're using is doing something stupid, perhaps it's a little known feature of the .NET framework which is causing you problems. We recently had an issue with an older piece of software which was running into that, looking at the code would not have helped in the slightest but a profiler quickly sorted out where the problem was. A profiler should be a part of any developers toolbox, fair enough that it shouldn't be the only solution to every problem, but it should be a tool that you are comfortable using and comfortable to know when to use.
Eagles may soar, but weasels don't get sucked into jet engines
If you're on a Windows machine then have a look at using the graphical or command line installers for MinGW, really can't get easier http://www.mingw.org/wiki/Getting_Started[^] Well, actually it could get easier if you have chocolatey installed as there's a MinGW package available http://chocolatey.org/packages/mingw[^]
Eagles may soar, but weasels don't get sucked into jet engines
What about setting up your own NuGet feed?
Eagles may soar, but weasels don't get sucked into jet engines