Thursday, December 10, 2009

Book Review: Citizen Engineer



Disclosure: I received a copy of this book for free from the publisher as part of the PyATL Book Club.

The goal of Citizen Engineer, from Pentice Hall/Pearson Education, is to awaken the socially responsible engineer in each of us. The topics covered range from the environmental impact of product design to the sociopolitical ramifications of intellectual property law. Authors David Douglas (Senior VP of Cloud Computing, Sun), Greg Papadopoulos (CTO and Executive VP of R&D, Sun), and John Boutelle (freelance writer) share their experience in all of these areas to create a thought-provoking introductory guide to the issues of modern engineering practice.

Citizen Engineers are techno-responsible, environmentally responsible, economically responsible, socially responsible participants in the engineering community.


The authors begin by covering the background of what they call the "Citizen Engineer" and why the issues are important. The premise of the book is that it is no longer sufficient for engineers to work in isolation in their labs. We must engage with practitioners of other disciplines to bridge the gap between science and society. This is not a new responsibility, and the role of "citizen engineer" is not new. However, it is expanding as engineers have an ever greater need to understand a broader range of fields to do their job well. Even if the engineer doesn't practice intellectual property law or environmental science, they need to be familiar with the issues involved in order to collaborate effectively.

They start the discussion by listing several external driving forces that are changing the economics of the way good engineering is being done. These include the environment, corporate social responsibility, fraud and security concerns, privacy, digital goods and intellectual property issues, and government regulation in all of those areas. The book touches on each of these areas in turn.

Engineers who were once preoccupied with Moore's Law are now dealing with more laws...


Part 2 of the book is devoted to environmental issues and making the case that the environment is something engineers can, should, and are thinking about. Environmental impact analysis is complicated by many variables and the fact that reducing impact in one area can increase it in others. The authors approach the problem pragmatically. They start by prioritizing changes based on the biggest impact, and ensuring that impact is studied over the full life-cycle of the product. They also point out that sustainability issues need to be considered "at scale" to expose the true impact of small changes. For example, billions of people use consumer products such as light bulbs, meaning even seemingly tiny incremental improvements in efficiency or sustainability can have sweeping global impact in energy consumption, materials used, and natural resources consumed. Even a change to reduce the packaging weight of a product will reduce the amount of fuel needed for shipping and distribution, and depending on the scale that impact can be as big or bigger than a change directly to the product itself.

... IT equipment often consumes less than half the power used in a typical data center.


A little closer to home, the authors refer to research that says less than half of the power used by a typical data center goes into computing. The rest is lost as heat waste in the conversion to different power levels, or is used to keep the computers cool. There is research being done into more efficient cooling techniques, consolidation of systems through virtualization, and alternative power setups with higher voltage. Changing the hardware is not the only path to reducing power consumption, though. More efficient code, and more efficient execution of that code, provides opportunities for using less hardware in the first place. That's food for thought the next time you put off optimization by saying, "cycles are cheap".

Intellectual property laws are crafted to protect inventors and creators and the companies that market their works.


Part 3 is titled "Intellectual Responsibility" and covers the fundamentals of intellectual property law, including copyright, trademark, and patents. I found the definitions of the IP terms such as patent, copyright, and trademark in this section particularly helpful for clarifying the roles each of those tools has in IP generally and software specifically. I also like the way the authors separated the technical background material from their own opinions on the subject. Not everyone will agree with all of their conclusions, but the delineation between fact and opinion avoids clouding the issue.

Chapter 13 digs into the basic types of open source licenses and the decisions a software developer needs to make when deciding how to license their creations. They also talk about forms of open licenses for non-software products, such as Creative Commons. The authors have copyrighted their book under a Creative Commons license (BY-NC-SA 3.0), and have downloadable copies of chapters available online at http://citizenengineer.org/.

The final section of the book, "Bringing it to Life", talks about how to apply some of the ideas from earlier chapters immediately, as well as changes that are being made in engineering training so responsible engineering practices are more central in future work. They talk about cross-discipline training in law and environmental science and the curriculum changes being tested in major universities. The book then wraps up with examples from a selection of success stories from around the world.

I recommend Citizen Engineer for engineers from all fields who want a better understanding of some of the issues that are driving changes in engineering practices. The clear and concise writing style makes the book an easy read, without glossing over any difficult topics. It does not attempt to provide an exhaustive reference manual, but does give plenty of other resources for future research and reading.

Sunday, December 6, 2009

you gotta love backwards compatibility

A friend of mine recently found an old floppy disk created under OS 8 or 9 in the early 1990's. There was a letter on the disk that she wanted copied off, but she doesn't have a Mac any more.

No problem, I figured. I did a little research and found hfsutils, and thought all I would need to do is stick the disk in my Linux box and grab the files. No such luck, since I don't have a floppy drive in any of my systems.

After a little more thought, I remembered the old rawwrite.exe utility for creating bootable floppies under DOS. Sure enough, there's a rawread.exe and I was able to make an image of the floppy disk on a Windows box.

Although the next step was going to be to copy that image file to a Linux system to try to mount it, I decided to try to open it on my Mac (running Leopard) first, just for grins. I renamed the file to end .img, and it mounted right up. All of her files were there and Finder even acknowledged the layout of the icons in the folders.

Of course, the files themselves were created with some version of WordPerfect that no longer exists, so our data recovery efforts only went so far as to get the text of the letter without its formatting. I'm still impressed that a modern Mac that doesn't even have a floppy drive could open the old disk image to begin with.

Switching development contexts with virtualenvwrapper

Optimizing repetitive operations is one of my obsessions. I can't stand following long sequences of steps to make the computer do what I want. The whole point of computers is to have them do more work for us, right?

As a developer with several ongoing projects, I frequently find myself switching contexts as one project becomes blocked (read: I lose interest) and I want to move on another. Typically that means unloading a bunch of files from my editor and loading others. Some IDEs, and even editors such as TextMate, use a "project" file to manage the files that belong to a project. Some go so far as to use the project file as a hint for how to build the library or application.

Using a project file typically involves pre-defining the members of a project, and then managing the project file as another artifact of the project itself. To switch contexts, you simply close one project file and all of its related code files, then open another. A good editor will even remember which files were open when the project was last in use, and restore your workspace to the same state. A great editor will let you automate the steps needed to switch contexts by loading different project files.

emacs desktop-mode



I've been an emacs user for something like 10 years now. I use vi frequently, and TextMate regularly as well, but most of the time I live in emacs for text editing and development tasks. The implementation of project files I use with emacs is desktop-mode. I like desktop-mode because instead of forcing me to pre-declare all of the files in my project, it assumes that all open buffers should be remembered. There are alternatives (there are always alternatives in emacs, right?).

Setup of desktop-mode is straightforward:

1. Run customize-group on the "desktop" group.

2. Turn desktop-save-mode on to enable the minor mode.

3. Optionally change the base name for desktop files in desktop-base-file-name. I like using "emacs.desktop" so the file is not hidden and I know exactly what it contains.

4. Set a default search path for the desktop file in desktop-path. I set my path to include ~/emacs, but this is only the default. We will be saving a separate desktop in each virtualenv.

5. Set desktop-save to "Always save". There are other values that work, but some require interaction with the editor during the context move to confirm file saves, and I want to avoid that.

There are a few other options that may be useful to tweak, depending on the other features of emacs you use. For example, I set desktop-clear-preserve-buffers so clearing the desktop does not delete the *Messages*, *Org Agenda*, or *scratch* buffers since those are related to emacs operation and not limited to any one project.

virtualenvwrapper hooks



The next step is to set up the tool chain so emacs loads a new desktop when you change virtualenvs from the command line.

In addition to making it simpler to manage multiple virtual environments, virtualenvwrapper adds several hook points to trigger changes outside of the virtual environment when various events occur. For example, each time you run workon to change environments, the predeactivate and postactivate hooks are run. The most interesting of these for our purposes is the postactivate hook, called right after the new environment is activated.

I usually add a cd command to the env-specific postactivate script (in $VIRTUAL_ENV/bin/postactivate) to move my shell session to the working directory for that project and change the $PATH, making it easier to run the tests for my project from the shell. For example:

pymotw_root=/Users/dhellmann/Documents/PyMOTW
cd $pymotw_root/src
PATH=$pymotw_root/src/bin:$VIRTUAL_ENV/gettext/bin:$PATH


Changing Desktops



In addition to the virtualenv-specific hook, there is also a global postactivate script, and that's the one I use to switch contexts in emacs. Edit $WORKON_HOME/postactivate to add these lines:

# Change emacs' desktop directory
emacsclient -e "(desktop-change-dir \"$VIRTUAL_ENV\")" >/dev/null


The function desktop-change-dir tells emacs where to save the desktop session file. By changing the directory each time we change environments, we can have a separate desktop file in each environment. Changing the directory automatically saves the old desktop first, of course, so the old project status is preserved until you come back to it.

Now that the hook is configured, the next step is to initialize the desktop for your projects. For each project, run workon to activate it, then open several files from that project. As you workon the next project, the session will be saved in $VIRTUAL_ENV/emacs.desktop (assuming you set your desktop-base-file-name to emacs.desktop). Once you have initialized a few virtualenvs, switch back to the first. Emacs should load the desktop file for that environment and restore the buffers you were editing.

Other Editors



The example above works for emacs, but other editors may need to use the predeactivate hook to save a project file before loading the new one from postactivate. There are global and local versions of both hooks; refer to the virtualenvwrapper documentation for more details.

Saturday, December 5, 2009

Garlic Chili Recipe

Earlier today I mentioned on twitter that I was making chili and several people asked for the recipe. I make a variation of "Gilroy Chili" from The Garlic Lovers' Cookbook, put together by the organizers of the Gilroy Garlic Festival in Gilroy, CA. My wife and I picked up copies of volumes I and II not long after we were married and have several favorite recipes from each.



The original recipe is from David B. Swope, although what I make is a slightly modified version, as follows:


4 cloves of garlic (at least), minced
1 sweet onion, diced
1 can stewed tomatoes
1 can Campbell's condensed beef broth, undiluted
1 tablespoon chili powder
1 tablespoon cumin
1 teaspoon salt
1 lb. ground beef


You can cook the whole thing in a single large skillet, which makes clean-up a breeze.

1. Brown the garlic and onions in olive oil until tender.

2. Add the meat, heat up the skillet and cook until done.

3. Add everything else.

4. Cover the skillet and reduce the heat to simmer.

5. Cook about 45 minutes to reduce, stirring occasionally.

Serve by itself with good bread for sopping, or over rice. We usually get about 4 servings if we're not stretching it with rice. It reheats well, so occasionally I'll double the recipe and put some up in the freezer.