Early reports suggested that the Rosyln project would just be a better runtime-accessible compiler and REPL-style interpreter, but it turns out that it is much more ambitious. By opening up the entire compiler pipeline Microsoft hopes that developers will create a wide variety of tools at many levels.
Refactoring is a technique for changing the internal structure of the program without changing its external behavior. On the face of it, refactoring seems to involve a good amount of thinking, however, too much thinking could be detrimental as well.
MaintainJ, a reverse engineering tools that provides runtime sequence and class diagrams for Java codebases, has released version 3.2 with multiple enchancements. MaintainJ is Eclipse-based and works on any IDE that is built on Eclipse platform.
Python Tools for Visual Studio, which has its first production release today, now supports all four major Python interpreters, CPython, IronPython, Jython, and PyPy. It is available with the free Visual Studio Integrated Shell or as a plugin for Visual Studio Professional.
The CompArch Conference is a federated conference that brings together researchers and practitioners interested in Component-Based Software Development and Software Architecture. This year the event is held at the University of Colorado in the United States from June 20th to June 24th. As general chairs Ivica Cnrkovic and Judith Stafford were appointed.
Refactoring by definition means changing the internal structure of a program without modifying its external functional behavior. This is mostly done to improve the non-functional attributes of the program thus leading to improved code quality. However, refactoring on a large scale often gives jitters to even seasoned Agilists. The community discussed a few ways of handling the scale.
How can one explain the importance and value of refactoring to people in management who have never coded? How can one justify the expense of slowing down code delivery?
Refactoring is the process of changing a software system in such a way that is does not alter the external behavior of the code yet improves its internal structure. The idea of improving an already written code is appreciated in most Agile teams. Continuous improvement is is something that these teams strive for. However, improving the already existing code involves time and money. Is it worth it?
Microsoft has decided to continue licensing CodeRush Xpress for free for developers using the non-free editions of Visual Studio 2010. Developer Express has released the beta version of CodeRush 10.1.1, containing features related to code selection, code navigation, class/field/variable declaration and refactoring.
Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt.
The goal of refactoring and rewriting is to improve the sanity of the system by improving the code readability, structure and clarity. A clean code would be easier to maintain and enhance. However, on many occasions Agile teams have a tough time deciding between the two.
Jimmy Bogard, Charlie Poole, Lior Friedman, Charlie Poole and others give their guidelines for more readable and useful unit tests.
Rails 2.3.3 is now available. Among the usual bug fixes, it adds a few new features like ActiveRecord touch functionality and some JSON related API changes. Also: a look at what's up with Rails 3 and Merb 1.1.
Ruby on Rails has been around for about 5 years and in those years developers have created a lot of applications. Many of those applications were created while learning Ruby and Ruby on Rails and may not have used the best practices but yet made it into production web sites. These web applications can be problematical but a new book focused on the solution is available.
When should you refactor? There are times when you simply need to pay down technical debt - you should stop and refactor. No, you should only refactor when one is working on a User Story. Which advice is best? Is there, perhaps, a third option?