How far goes the systems optimization?

One field of computer that gained a lot of strength is the ubiquitous computing, it supports the theory of provide processing capacity to things that we use every day like microwave ovens, smartphones, tablets and other equipaments . Therefore, the industry is producing many devices with low-cost processors called microcontrollers, able to realize tasks even more complex.

Most of these foregoing equipaments works with batteries, because of that,they have a limmited capacity of power supply. Considering this limitation, the scientific community have researched much to optimize the software execution in these devices in order to consume a smaller amount of energy without affect much of their performance. In this post we intend to argue on some techniques to do it.

Some preliminary studies focus on low power consumption by systems, were based on a technique that scaling voltage and frequency during software execution. Furthermore, this technique selects the mode of work of the system as a whole without considering the device status. This technique, called DPM, is based on the principle that CPU power consumption decreases with the cube of voltage while frequencies scale linearly with voltage.

From this initial idea, emerged other frameworks[1][2] that began considering the devices status and workload of them as well as to realize an analysis of the energy consumed by the modules and identifying the points of the system that consume more energy. Therefore the system designer can refactoring the software to use the foregoing parts only when they are really necessary. As an example, we can cite the smartphones that are sold nowadays, they can detect when the remaining charge of the battery is low and in this case reduce the luminosity of the display and the use of network resources.

Another line of studies supports the refactoring and optimization of source code in order to execute all the system in SRAM of the device. This type of memory, as we know, has an extremely fast access to data and consumes less energy than DRAM memories that are usually used in desktop computers.

This text is only one general view about some researches realized to build systems with low power consumption. At the end, writing good code is not just a manner of maintainability, but also power saving that enables ubiquitous computing become a reality, so dive into it.

Developers vs Testers... Fight!!!

This text is a review of the one posted on Bytes Don't Bite.

Should people, who work with software testing, have development skills? The business knowledge is necessary for professionals in the testing area, but understanding about the structure of what is tested, which is primarily a software, is also important.

James Whittaker, who worked at Microsoft on testing and currently works at Google, wrote a book that demonstrates some techniques to "break" a software. The displayed faults are interesting, and likely to be achieved in black-box approach. The book demonstrates failures that can be caused by the user interface or through other software. Whittaker also says that many developers have difficulty to understand the environment in which the software works.

In the experience I had with software testing until now, I had the opportunity to work with several kind of testers that only interact with buttons, or other visual components, which are offered through specifications. Such testers disregarded file system, external components, operating system, network, relationship with other features, etc..

With this post, I want to encourage a fight.

Software testers, you must learn where the developers leave the bugs. Believe me, most of the failures of software are in the code! Consider different ways to find the problems. Understand the operating system, examine the software source code, understand networks, study the shortcomings of the used frameworks, study how to verify the security of the product (do not use the excuse that security is a non-functional requirement), consider all that is valid to ensure software quality.

Developers, will you let the testers break your code? See what these testers can do with the code produced by you! Approach to the thought of the testers, see how they act. Develop a critical thinking. Work hard to not let common flaws happen. Study where the bugs appear, to be able to avoid them!

At the end, this healthy dispute, between preventing and find bugs, is a way to get a software with quality and a team in continuous evolution.