Mar/100
Intel Atom™ Developer Program Million Dollar Development Fund
The netbook has become one of the most popular consumer devices in the market today, but its true potential has been limited by applications that are not optimized for its mobility and smaller screen size.
The Intel Atom Developer Program Million Dollar Development Fund is a fund set up by Intel to address this challenge and to help accelerate innovation in software applications for Intel? Atom™ processor-based products, starting with netbooks, and eventually supporting smartphones, consumer electronics and more devices.
The fund will be available to individual and student developers as well as small, medium and large software companies to support development of groundbreaking applications for the netbook platform. The first three elements of the development fund Fast Track 2010, Dollars for Downloads 2010 and the Intel Atom Developer Challenge are available now with more to be announced over the coming months.
Jan/100
What is Continuous Integration
The practice of continuous integration represents a fundamental shift in the process of building software. It takes integration, commonly an infrequent and painful exercise, and makes it a simple, core part of a developer’s daily activities. Integrating continuously makes integration a part of the natural rhythm of coding, an integral part of the test-code-refactor cycle. Continuous integration is about progressing steadily forward by taking small steps.
Integration should happen continuously, and continuously is more often than you might think. The frequency of integration will vary from project to project, from developer to developer, and from modification to modification. However, as a goal and a good rule of thumb, developers should integrate their changes once every few hours and at least once per day.
Learning how to integrate so frequently requires practice and discipline. Fundamentally, an integration can occur at any point when the code compiles and all the unit tests are passing. The challenge is learning how to write software so that you never stray too far from this point. If you are testing at the right level of granularity and are refactoring regularly, then you should never be more than a few minutes away from this point. This means that you are almost always in a position where you can launch a new integration.
Deciding when to integrate is all about controlling risk. When making modifications in a high traffic area of the code base or when conducting broad refactorings like class renaming or package reorganisation, there is an elevated risk of impacting other developers or of having merge conflicts when committing. The longer that developers go without integrating, the greater the likelihood of conflicts and the larger the effort required to resolve those conflicts. As the effort of integration increases exponentially in proportion to the time between integrations, best practices dictate that when making high-risk changes a developer should start from a clean workspace, focus only on required modifications, proceed with the smallest logical steps, and then commit at the earliest opportunity.
A successful integration is a measure of progress. It provides feedback that the new code runs correctly in the integration environment and successfully interoperates with the rest of the code base. Code sitting unintegrated in a developer’s workspace simply does not exist. It is not part of the code base, it cannot be accessed by other developers or tested by the customer. Only when it has been successfully integrated is the benefit of the new code realised.
References
- This text is snipped from Owen Rogers’ recent article: Scaling Continuous Integration submitted to XP2004
- Martin Fowler and Matt Foemmel’s classic article: Continuous Integration