Luis Ibáñez works as Senior Software Engineer at Google Inc in Chicago. Opinions expressed in this site are his own.You can find him in github at: http://www.github.com/luisibanezand in twitter at: http://www.twitter.com/luisibanezHe previously worked as a Technical Leader at Kitware Inc., and Director of Open Source Community Development at the Open Source EHR Agent (OSEHRA). At Kitware he was closely involved in the development of open source software for medical imaging applications, in particular, working with the Insight Toolkit (ITK).Luis is a strong supporter of Open Access, and one of the editors of the Insight Journal, an OA Journal that enforces the verification of reproducibility. In collaboration with other instructors, Luis taught a course on Open Source Software Practices at RPI between 2007 and 2013, and also at the State University of New York at Albany between 2011 and 2014.Luis Ibáñez received a B.S. in Physics from the Universidad Industrial de Santander (Bucaramanga, Colombia) in 1989 and a M.S. in Optics from the same university in 1994. He received a D.E.A and Ph.D. degrees from the Universite de Rennes I (Rennes, France) in 1995 and 2000, respectively. In 1999, Luis Ibáñez joined the Division of Neurosurgery of the University of North Carolina at Chapel Hill and participated as a member of the MIDAG and CADDLab groups. His work at UNC was related to the development of algorithms for 2 and 3D registration applied to image guided surgery. He also participated as developer of the INSIGHT Registration and Segmentation Toolkit sponsored by the National Library of Medicine. Luis Ibáñez joined Kitware, Inc. in February 2002 where he was one of the main developers of the Insight Toolkit (ITK) coordinating its maintenance with other developers and the user community; he is also one of the main developers of the Image Guided Surgery Toolkit (IGSTK) and participated in crafting the operational principles of the Insight Journal. Luis Ibáñez is a strong supporter of Open Access, and the verification of reproducibility in scientific publications and is a regular speaker in ITK training courses, and in events disseminating the principles of Open Source. In August 2014, Luis joined Google Inc as Software Engineer, to work with the corporate engineering team in New York city.
Authored Comments
Thanks for the interesting article !
Very nice to see the emphasis on Unit Testing and Code Coverage.
Wish these concepts were integrated in a regular basis on the education of software engineers. It is a habit that should be developed early on.
Being a C/C++ programmer, I certainly sympathize with the view that it is important to be exposed to the understanding of what happens at the lower levels.
However, both in education and in programming there is value in having the multiple layers of abstraction.
As long as we don't preclude developers from being able to dig deeper in the code as they get more curious, there is no harm in providing a higher conceptual abstraction.
We can move progressively:
from: A web server in a Python module
to: a Web server implemented by three python classes, calling about five functions, all from that previous module.
to: a C implementation, (in the case of nweb) calling three C functions { log(), web(), main() },
to: the examination that nweb functions in turn call eight other C functions { getenv(), chdir(), setpgrp(), signal(), open(), read(), write(), and close() }.
I fully agree that by using the lower level approach, the students will get closer to understanding how things work. Although, for full understanding, they should go further and study processes and inter-process communications (to make sense of signal(), and fork() ), and understanding the file system and pipes ( to make sense of chdir(), open(), close(), read(), write() )... and following this logic, we probably should dive also into the source code implementation of these functions, under the kernel code, to really see how they are working..., then we have to understand drivers,... and probably introduce some bits of assembly code, and have a footing on electronics...
Certainly, this is what the Raspberry Pi was designed for. The question is how to get there progressively, without generating push back.
The instructor challenge is: How to create the conditions for motivating the students to further and dig deeper in the topics ?
One good option is to stay away from lectures, and to trigger the learning of the lower levels through direct interactions of students with programming platforms.
This is one of the reasons that led us to create a HackSpace at SUNY Albany as well. Aiming to create the informal environment in which students could explore deeper, at their own pace, and driven by their own curiosity. This removes the artificial constraints of time, curricular topics and co-location that make so hard to allow students to explore topics progressively as they become ready for them.