Defect prediction is a set of techniques used to identify a likely buggy software change (eg. a commit). Various measurements from previous changes are taken into consideration to predict weather a new change is likely to contain a bug or not. Commit messages or bug tracking system entries are usually examined to gather the measurements. Machine learning is often used to classify the buggy/clean changes. We are working now on adding a continuous notion to defect prediction. On one side by building on top the idea of continuous defect prediction in the IDE (Integrated Development Environment). On the other side by perfecting the prediction by using the unambiguous results of continuous integration builds of the software project.
The technique was described in a paper I coauthored under the title “Continuous Defect Prediction: The Idea and a Related Dataset”. I will present the paper at the 14th International Conference on Mining Software Repositories 2017 (MSR) in Buenos Aires, Argentina in May this year. MSR is colocated with 39th International Conference on Software Engineering (ICSE) which I will attend.
I’m a “bits sculptor”! I work with bits to create beautiful software. I have done it myself for years and now I’m running a software development company to create “better software”. But I was always jealous of people creating more tangible items than software. Not that I ever thought about software as a lesser creation then physical objects. Oh, no! Creating good software takes the same amount of effort and talent as creating for example a good car. But still. But you cannot “touch” the software you are creating. So I decided to go a bit into hardware. And what is the better way for .NET software developer than to go programming .NET based electronics?!?!
Yesterday I’ve added a talk about the basics of .NET hardware programming to my repertoire. It’s basically the material I’ve worked on while writing the two articles published by dotnetpro Magazin in Munich, Germany. The first one was about Netduino and it was published in 08/2012 issue and the second one was about Tinkerforge from the 12/2013 issue. I’ve added a bit information and a demo for Raspberry Pi and Mono. I gave a talk at the meeting of .NET Developers Group München (17.12.2013). It went quite well. Despite the technical versatility I had to manage (and believe me the table was crowded with electronics!).
And here are two photos from the talks I gave last week (11.12.2013) at the Opole University of Technology. The topic was: testing mobile software and I showed (among other things) our RoboTouch project.
Last week was quite eventful. I’ve talked about Continuous Integration in .NET and about how do we use it at my company CODEFUSION at the IT Academic Day 2013 at the Opole University of Technology (OUTech). It was an event organized by the .NET Group from the OUTech and Microsoft Poland. The auditorium nearly full! Of course I’ve showed my funny CI gadget "Great Integrator Helmet". It connects wirelessly to the CI server and transfers a feedback about failing build by blinking and hauling. As usual it was very well noticed by the auditorium
And since we are at the topic of tinkering with electronics: I’ve described how to build such a thing using Tinkerforge and .NET and together with Bernhard Kord written an article about it. It went “live” this week in the 11th 2013 issue of dotnetpro Magazin in Munich, Germany. If you are keen in German language (the article is written in German) take a look at http://www.dotnetpro.de/articles/onlinearticle4689.aspx for more details!
I have recently participated in the “ENASE – Evaluation of Novel Approaches to Software Engineering” conference. This year (2013) it was held in Angers, France. I have learned a lot during this conference! I have presented a short-paper I’m coauthoring called “Continuous Test-Driven Development — A Novel Agile Software Development Practice and Supporting Tool”. Presentation wen well – here are the slides.
What is the paper about? Lets read the abstract:
“Continuous testing is a technique in modern software development in which the source code is constantly unit tested in the background and there is no need for the developer to perform the tests manually. We propose an extension to this technique that combines it with well-established software engineering practice called Test-Driven Development (TDD). In our practice, that we called Continuous Test-Driven Development (CTDD), software developer writes the tests ﬁrst and is not forced to perform them manually. We hope to reduce the
time waste resulting from manual test execution in highly test driven development scenario. In this article we describe the CTDD practice and the tool that we intend to use to support and evaluate the CTDD practice in a real world software development project.”
So basically we’ve named a technique that combines Continuous Testing (CT) and Test-Driven Development (TDD) and came with a Continuous Test-Driven Development (CTDD).
2 pictures instead of 2000 word? TDD looks like this:
CTDD looks like this: