credit: tanakawho
The other day I exchanged a couple emails with two friends (him and him) about development tools. That made me think about those other development tools that end-up being use once every two or three months:
- valgrind suite is composed of some awesome tool, the ones that I use more are memcheck and callgrind,
- ldd is very useful to understand what library you are missing
- xmllint is perfect to do simple XML validations against XSD or DTD
- tidy is useful to beatify that XML contents that after manual edition tend to get misaligned
- vimdiff created a dual-panel diff (similar to tkdiff) in a vim environment
- cut select a range of characters per line (i.e. a column) for a specified file
Some of these and many more where found on a very interesting site (which I use regularly) called Command-line-fu.
You might have already noticed that the number of photos in my own Experiment photoblog. This increase in the number of photos is due to my vacations (sort of!), but also and specially due to the new Python upload “tool”* I’ve developed during the last week!
The all process was quite simple…
1. Design the interface using Glade-3. This step includes creating the window and placing some controls. My “tool” uses labels, text boxes, buttons, menus and even a status bar (which I didn’t get to use for any status display). Also, the required controls should be connected with event listener which will be customized by the developer. The only listeners the “tool” interface defines is the window_kill for the File -> Quit menu option and on_button1_clicked for the ‘Upload’ button.
2. The previous results in the generation of a window.glade file. In order to use this interface definition, the .glade file needs to be converted to a GTK definition file (e.g. window.xml). This conversion is performed using the gtk-builder-convert (simply execute gtk-builder-convert window.glade window.xml).
3. In order to use the Window.xml definition just create a Python class and build the interface in the constructor. Don’t forget to instantiate the handlers you defined for your interface. Here is an example of my gui.py (before customizing the button listener).
Again, I really find easy to make stuff work using Python.
* - The expression tool appears several times between quotes and in italic because the actual application took no more that a couple of hours to build, so calling it a tool is a bit too much. Moreover, it’s highly hardcoded so it’s not much of a tool… it’s more like a “tool”!
According to this article, a software application can easily be developed in a collaborative environment by using a tool that automatically integrates every developer’s effort daily. This is my favorite way to develop software.
Each successful integration is verified by the execution of an automated build of the complete project (including libraries, binaries and tests). In addition, after building the project you can also execute unit tests and/or integration tests. This enables the developing team to increase the degree of assurance on the implemented functionalities and reduce the time spent in the integration process.
Several softwares to support Continuous Integration development, but I only tried to use two of them:
- CruiseControl, a potent tool targeted for enterprise development
- Hudson, an easy to use, simple to configure tool (which I’m currently using with very good results)
The themes presented in this blog are naturally evolving along with my day-by-day experiences. The last days (or should it be months) have been completely occupied with software developments tasks known as implementation, implementation, and more implementation… I must admit that C/C++ has become my second language.
Closely associated with source code production come the fine “art of debugging”. My favorite debugger is GDB (from The GNU Debugger Project).
Learning something new every day is somewhat of a life’s philosophy for me, and it is with big enthusiasm that I learn more about using GDB. The last example of a lesson learned was: how to use backtrace command to display the trace of the execution stack (which was not new to me), and navigate that same stack using the up and down commands and verifying the parameters passed to each function.
More details can be found in the Program Stack section of the GDB Quick Reference.
