Jim Cowart discusses the four project templates that ship with the Icenium Extension for Visual Studio, and also includes a link to an alternate set of templates that ship with no sample-app boilerplate pre-populated in the templates.
Updated: Fixed a few formatting and badly positioned graphics. No tool can ever possibly meet every team’s needs out of the box. It’s crucial to select tools that are extendable or customizable to handle things specific to you and your team. Test Studio gives you the ability to customize a number of things under the hood. One great feature is tying into events for test lists in order to handle setup or teardown steps. This lets you do things like load baseline datasets, clear out test-generated data, or perform configuration actions. The post below is written by Ivaylo Angelov, a ...
This is the fifth and final part of blog series that walk you through each of Telerik's Cloud Controls and show you how easy you can use them to create an app. This post demonstrates the usage of RadCloudNotificationControl and RadCloudFeedbackControl.
In the last post I showed you how from time to time it is necessary to change our code to enhance readability, make maintenance easier or to optimize the codes performance. This practice is called “Refactoring.” Normally making these kinds of changes can be a nerve-wracking experience for developers as they can’t be certain that their changes aren’t breaking something else. However, having a suite of unit tests the exercise your business code enables you to refactor your code without worry; as long as your tests pass you know that your code still satisfies your business needs. In addition to our code, sometimes our unit tests themselves need some refactoring. This post explains how to refactor your unit tests and demonstrates a few NUnit features that will help us with this endeavor.
As time goes on in any software development project you’ll no doubt find inefficiencies in your code that you would like to remove. Other times you’ll receive new requirements that are going to necessitate large scale changes in your existing code. And you will still occasionally find code that you’ve written in the past that will make you ask “What was I thinking when I did that?!” When these situations arrive, it’s time to look at refactoring your code.
The Q2 2013 release of Kendo UI saw the introduction of the new Scheduler widget - a highly requested, highly customizable widget that allows you to schedule things in a calendar view.
Along with a new widget, of course, there is a lot of new documentation and new resources for getting started and using it. The schedular, with it’s already powerful and flexible feature set (in spite of still being a ‘beta’) is no exception, of course. And one of the best resources I’ve seen for getting started with it, is the Kendo UI Scheduler screencast course at Udemy.com.
JustCode works very hard in the background to make you as productive as possible without getting in your way. In order to do this there is some startup work that must be done, and this can affect the start up time for Visual Studio. Read here to see what's going on behind the scenes.
I’ve previously discussed a bit of the TDD workflow; start with a requirement, derive a test from the requirement, write just enough code to make that test pass, repeat. This is sometimes referred to as “Red, Green, Refactor” which I’ll be coming back to several times over the course of this series. In this post I’ll show you how this approach can be extended to dealing with software defects.