Setting up Dreamweaver CS6 with SVN + SSH

I have a customer that has website source code (mostly php) in svn. There is a tidy deployment process whereby commits to trunk are automatically deployed to the test server and tags (with a certain prefix) are automatically deployed to production. This is done using post-commit hooks.

Up until this point they have been using Eclipse to edit the website source files and commit/tag to svn. Eclipse is what we programmers are most familiar with and it worked for this website for years. However, the new web manager wanted to use Dreamweaver instead. Eclipse can be foreign and uncomfortable to a non-programmer and Dreamweaver has extra tools that she was used to. She initially started sneakily working in Dreamweaver and copying files back over to the machine where her Eclipse workspace was in order to commit and tag. That won't do at all, so I started doing research and found that Dreamweaver has svn integration built in. Great!

Except it wasn't so great. If you Google around a little you will find more than a little rumbling about the challenges that face anyone who dreams of using this feature. My problem was that despite following the official instructions to the letter, it just wasn't working. The error message, "Server and project are not accessible! (Can't create tunnel: The system cannot find the file specified.)" didn't tell me much. (Which file? Specified where?) To make matters worse, for whatever reason we only had access to CS6 on Windows. That meant working with svn and ssh on windoze, oh no!

Here are the pieces that we had installed on the windows machine:

• TortiseSVN
• PuTTY download
• PuTTYgen download
• Plink download
• Pageant download
• Dreamweaver (from CS6)

FWIW, this machine happens to be running Windows Server edition 2008 R2.

First I wanted to get ssh working, so I tried using PuTTY. I could ssh to our svn server if I provided a password. That's a good start. I already had ssh keys set up on the svn server and so would my customer, so I wanted to figure out how to get the existing key to work on Windows. It turns out that you have to convert the key. To do this:

1. Run PuTTYgen. 
2. Click the "Load" button to lead an existing private key file. Enter your passphrase as needed. 
3. Click "Save private key" to save your key as a PuTTY format private key (I called mine private.ppk)

Then you have to register this key so that you can ssh without a password. To do that, you need to run Pageant. 

1. Run Pageant if it isn't already running. When it is running you will see it in the bottom right tray area. It looks like a little computer wearing a black hat(?) 
2. Right click and select "View Keys".
3. If you don't see your key there (and you won't the first time) then click the "Add Key" button. Navigate to your private.ppk key and add it.

At this point you should be able to ssh via PuTTY without having to enter your password.

At this point we thought that we might be able to connect to svn from Dreamweaver, but all attempts failed. I didn't initially get it from the official instructions that anything else is needed. But,  you need to have a SVN client installed, so we got TortiseSVN. 

One more step: Edit this file

C:\Users\[[Your User Name]]\AppData\Roaming\Subversion\config. 

In the [tunnels] section, specify where ssh client exists. This location depends on where you installed it. Open the file and enter the following within the tunnels section (underneath [tunnels])To use key-based authentication, add -i PathToKey. E.g.

ssh = $SVN_SSH C:/PathToSSHClient/tortoiseplink.exe -i PathToKey

Once you get that installed and you can checkout from svn outside of dreamweaver you are very close.

The final trick was the actual settings in Dreamweaver when setting up version control. This was the magic combination that worked:

Protocol: SVN+SSH

Server address: svn+ssh://[[Your SVN User Name]]@svn.server.domain

Repository Path: /the/path/to/your/project/in/svn/trunk

The piece that I was missing at first was the user name in the server address field. For us, it didn't work without that.

So, there you have it. Now we can checkout, check in from Dreamweaver! No more sneaking files around just to be able to use the right tool for the job.

Best Training Ever: Internal Drupal Hackathon at Goodwin College

I just wrapped up a week-long training with my development team today and this was the best training ever: we eschewed the traditional bring-in-the-expert-to-drone-over-some-powerpoint model and styled our week-long training as a hackathon instead.

There were six developers from my team and two from another department all looking to learn how to use Drupal for different projects. These are real projects with real (internal) customers and we all thought that Drupal might be the right tool for the job, but none of us knew how to use it very well. Some of us had played around with it, but some of us hadn't. For one person it was their first time working with a cms. For me it was my second time getting my hands on a drupal instance.

We didn't know how to develop for it as a platform and we didn't know how to install and configure it so that it would be a reliable and secure content management system for our customers. We didn't know how we would set up our dev, test and production workflows, and we just plain didn't know where to begin wading through the sea of modules to find the right tools for our specific needs. Our boss hired an outside consultant to join us for the week to either teach us or work along side us for the week, whatever we needed. We really lucked out getting Tim Plunkett from Zivtech--this guy is an active contributor to many of the Drupal modules that we ended up needing. He knows his stuff and he was excellent at not only teaching us what we needed to know but also teaching us how to find answers when it comes to Drupal and its many modules.

Why was it so awesome?

I have never, ever, learned so much in such a short period of time. It was so efficient. I felt like I was in flow most of the time. I felt that rare electric feeling like the whole room was in flow, like we have never been as a group.

Learn by doing--it's how I learn best; it's how a lot of us learn best. Even better was that because we were all learning different things at different times I had opportunities not only to learn but to teach what I just learned to someone else. This cemented my learning, in a matter of hours, not weeks. On that note, I am sure, SURE, that what I accomplished on the second day would have taken me at least two weeks on my own. That feels amazing.

Here's how it worked

For the most part it was one (or more) project per person, but I was actually on a team with one other developer because our project has a deadline of April 16th (just over a week after the hackathon--ambitious!).

Here were some of our projects:

• Porting of some static html to CMS with theming (this was mine--with the short deadline), laying groundwork for future massive site migration in to CMS
  
• Porting a wiki-based site to Drupal to take advantage of better add-on functionality
  
• Q&A site for teachers (replacing existing software)
  
• Faceted search/browse prototype for a customer with a ton of diverse but related content
  
• Hardware inventory/maintenance history logging system for sysadmins
  
• Massive open online course platform
  
• Site for alum-teachers to share videos and other resources with each other

Ahead of time

Ahead of time we set up a wiki page to keep track of the projects and all of the Drupal questions we had going in to the week. I set up a rough agenda that basically said on the first day we each talk about what we are going to do during the week, then each day we work and stop in the middle to check in (or show and tell) and then on the last day we have final presentations. That's it. I wanted to keep it simple and informal so that we could get as much done as possible. We got some budget to buy snacks and pizza for the week and I found us a room that we could use each day for a whole week (surprisingly difficult!). My colleagues and I agreed that it was important that we get away from our desks if we were going to be able to really focus on learning and getting deep in to Drupal quickly.

The week before I sketched out a layout for the room, a rectangle of tables, with enough room so that the consultant or other people could hop in between people. We sent out invites to our internal customers, asking them to stop by for a check in or to give us some feedback. The Friday before my colleagues helped to set up the room, with my colleague Amir making sure that we had things like an ethernet switch, lots of ethernet cables and power strips and even laptop locks. We checked on things like spare monitors, mice and keyboards, which were conveniently around the corner in the main IT office if we wanted to borrow them.

We checked in with Tim, our consultant, to pick up some best practices for getting our dev environments ready. He suggested things like setting up a space in source control for each project and having php, drupal and drush installed and in the right versions.

The hackathon week began

Once we were all there and we got past the initial introductions and started working it was like magic. I was never stuck, wrestling with a bug or a mystery. Either Tim had the answer, or could find the answer or one of my colleagues had it. When enough of us wanted to see something Tim would do a demo for the group and then we would get back to work. People would bounce around the room from time to time, sharing things they had learned and asking questions. We worked like crazy all day and I never had that feeling in the afternoon like I needed a nap--I was actually energized at the end of the day. (I am exhausted now, but it's a great exhaustion, like after an amazing long run.)

We did check-ins each afternoon, except Wednesday we did a mid-week show and tell just to share what we had learned and accomplished so far. This helped us identify people who had already done the things we needed to figure out how to do. I wrote the first module on Tuesday. Well, it was mostly Tim telling me exactly the words to type and what files to create, but it was a very effective tutorial on module building and a first glimpse for me in to some of the APIs and how Drupal works. On Thursday I learned features and had packaged up my work from the first half of the week in to a feature that could be checked in and pushed out to the other development instances.

About mid-week we realized that a lot of our projects were for different parts the same internal customer's (massive) website and so they should actually live in one big Drupal instance. That required a new project, which was the multi-project multi-developer infrastructure and workflow project. Prior to that we had all been playing in our own sandboxes. By the end of the week we had a solution figured out and the development layer set up so that we could develop features and push them out to each other and keep our development instances in sync. Amir even had a prototype of a staging instance and a workflow for deploying up from development with a plan for how that would work for production too.

In the end we covered just about everything that we had hoped to cover and in a lot more depth than I had imagined possible. We made real progress on real projects and we know a lot of how to do what we have left. Plus, we have learned how to figure out the rest.

So what's next?

At the very end of the event I led the team in a retrospective and almost everyone mentioned that we should do this again. There are a few things that we might do differently, like nail down or narrow down our goals to get even deeper and further along on fewer things or set up a better way to organize common questions and answers that have come up so that we can more efficiently share the knowledge we have gained between us. On the whole everyone loved it and we hope we get to do this again and again and again.

My question is why can't every week be like this at work? Is your work like this?

Show all blog posts on multiple static pages in WordPress

I am working on a hybrid blog/website project using Wordpress and I had a special request come in from one of my clients; He wanted his home page to be a static page, which is easy to do, but instead of having another page as the blog posts page he wanted two blog posts pages. The sidebar would be different for these pages, but the posts would be the same. His reason for this made sense, so I went about looking for a good way to implement it. Using the Reading settings you can only set one page as the posts page. Plus, I wanted to be able to specify a different layout (really just the sidebar is different) for each page, so I couldn't use the Reading settings for this.

The way I addressed this was to create two Pages. I created the layouts for each page with my iThemes Builder Style Manager plugin. Then I created a new page template, so that the pages would display posts instead of the page content. I took my theme's single.php code and expanded it so that it would show all of the posts plus the static Page's title at the top. I copied the loop code from my theme's single.php file. Below you can see the part that I changed, which is just the top part of the file:

<?php
/**
 * Template Name: Posts Page
 *
 * A custom page template for DataPoints
 *
 */
function render_content() {
?>

<!-- Display the page title -->

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>
 <div class="post">
  <!-- Display the Title as a link to the Post's permalink. -->
  <h1><?php the_title(); ?></h1>
  <hr/>
 </div>
<?php endwhile; endif; ?>

<!-- Show all of the blog posts -->
<?php query_posts( 'posts_per_page=5' ); ?>
<?php if ( have_posts() ) : ?>
  <div class="loop">
   <?php while ( have_posts() ) : // The Loop ?>
    <div class="loop-content">
     <?php the_post(); ?>
<!-- The rest of this is identical to my theme's single.php file -->
...[SNIP]...

Listing Sub-Pages on your Page in WordPress

I know I'm a WP noob, but this took me about an hour to figure out. Maybe I can save someone else some time.

Most of the code below comes from the WordPress docs, but there was one critical piece missing, $post->ID was returning nothing, even though I was in "the loop". I got around that whole thing once I learned that you can get the page id with get_the_ID().

<?php
// display only this page's children
$my_id = get_the_ID();
$subpages = wp_list_pages("title_li=&echo=0&depth=1&child_of=".$my_id);

if ($subpages) { ?>
<h2>Sub-topics</h2>
<ul>
<?php echo $subpages; ?>
</ul>         
<?php } ?>

I am using WordPress 3.0.1, if that helps anyone.

Product Sashimi is delicious!

On Saturday I participated in a Product Sashimi workshop with J. B. Rainsberger and Bonnie Aumann.

This workshop was all about learning how to "slice a product thinly" so that you can actually ship something of value quickly. We also spent a lot of time working on how to help turn a fuzzy customer product idea into something concrete that you can start to work on. I summarized it to my team like this: You customer comes in and they are usually asking for a whale. At the end of the project what they really wanted was a crab. Your job is to start from their request for a whale and 1) trim the whale down to the meaty parts they really want/need and 2) slice that meaty part thinly so that you can actually start development and deliver value soon.

I happen to work in an academic environment where my customers are colleagues with ideas for software and tools that will help their research or will be used internally for staff. No money actually changes hands for each project, but my team is a scarce resource and we have a lot of projects to handle, more than we can actually deliver. It's not that different from when I was a consultant with paying customers who need the maximum solution at minimum cost and they need it yesterday. You always want to get to delivering value as soon as possible, which means slicing the problem thinly, and you want to make sure that you know you are working on the most valuable things first, which means understanding their business and their needs.

The biggest challenge is understanding what the customer is asking for. Often times they struggle to put it in to words. Sometimes they can describe the solution they are looking for, but it doesn't match the problem they are describing. As knowledgable tech resources we immediately want to get to the meat of what they want, so our first question is "why do you want that?". A great reminder that J.B. and Bonnie kept mentioning is to consider how what you say sounds to the customer. Have you ever had an exchange like this:

Customer: I want an X. Can you make that for me?


Dev: Why do you want X?


Customer: What do you mean, 'why do I want that'?!

Depending on your tone and your relationship with your customer it can sound like you are questioning their own judgement of their needs, when in fact you are really just trying to understand their needs better. J.B. Gave a lot of great examples for what you can say instead. I won't give them all away, but one of my two favorite takeaways from the workshop was the Magic Wand technique.

Customer: I want an X. Can you make that for me?


Dev: Okay, (using imaginary magic wand) TADA! You have an X. Tell me a little about how you are going to use it.


Customer: Well...

This is going to go much better than the example above. It takes a lot of practice to get good at posing those questions.

My second favorite technique is the Lost Luggage Technique. Have you ever been the last one waiting for your bag to arrive on the luggage belt at the airport and then the belt shut off? So you go to the little room and tell them your bag is missing. Usually they will hand you a laminated sheet with pictures of suicases on it and ask you "which one of these does your bag most closely resemble?" followed by "How does your bag differ from the one in the picture?". This is a great technique because it grounds the conversation in something concrete and focuses both of your attention on the ways in which your understandings of the object in question differ.

For example, the customer describes what they want. It sounds a lot like a blog to you. So you say, "What if I give you a WordPress blog? What more do you think you need?"
and then listen to what they say. Oh, and write it down. Maybe they don't know everything a blog is capable of, so you might share that with them and check again. At this point it is all about listening, and keeping the conversation grounded in concrete terms as much as possible.

As you are listening and writing down what you are learning this is when the sashimi slicing begins. First you want to want to figure out the scope of this
You have to identify the simplest most barebones solution that could possibly fit the description of what the customer needs and then build out from there to find a simple solution that you can actually deliver. As J.B. put it succinctly, the goal is to learn what you don't have to do and try not to do it.

Once you have cut down the big fuzzy product description into a smaller fleshy piece now the slicing begins. In the training we went over techniques for identifying the major problem areas (maybe 4-8 of them) and then breaking those down in to features and then generating scenarios for those features.

I just gave my team a recap of some of the things that I learned at the sashimi workshop and it started a great discussion about how we are doing in understanding our customers' needs, how to define what is good enough (if you and your customer are both happy could you still not be done?) and even a quasi-role-playing session with our boss as the customer for a real request that had just come up. I am going to need a lot of practice asking those gently leading questions like "Tell me more about how you'd like to use that" and "I'm curious how you came up with the idea of a X".

When we got out of the meeting another one of our internal customers came over with a real request and we decided to see if we could use our new skills to help us learn more about what she is asking for. They ended up beating her with imaginary magic wands, but at least they didn't start off with "Why do you want that"!?!

I did successfully apply the lost luggage technique earlier this week. It's such a simple technique. I found myself with another developer and a customer and we were all talking in abstract terms about a report that she wanted. So, I drew a picture and I said "What if this was the report? would that meet your needs?" and the conversation became much more productive after that. A lot of practice is definintly needed, but I feel like I'm already getting value out of these techniques. I really wish this workshop was a month long so that I could soak up and really practice all of the things that Bonnie and J.B. were sharing with us.

Agile Philly Code Kata Night August: Architectural Katas

Thank you to Andre, Bonnie, Adam, Aaron and Sebastian for coming out to Code Kata night at the Math Forum! This was an experimental kata night in that we were trying out architectural katas for the first time.

In the beginning we went through a summary of the basic elements of architecture: communication/distribution, presentation/interaction, state management, processing, resource management and tools. For this we followed the slides that Ted Neward provided especially for this event and exercise. The idea is, roughly, that when you are designing the architecture of a system you have to consider each of these elements. I think we can all agree that one way or another requirements inform your technological choices. Asking questions about the system with regard to each of these elements can make it more likely that you don't miss support for a critical aspect of the system. Here are a few examples:

• Communication/Distribution: In what format does data travel? JSON? XML? Over what medium? http? filesystem?
• Presentation: What sort of perspectives in to the system do you need? do you need an admin console?
• State Management: Does the state need to be persisted across different sessions?
• Processing: Does processing need to be transactional?

Then we made two groups, each randomly selected a kata and spent 25 minutes trying to come up with a suitable architecture to meet the requirements. At the end of the time each group presented their proposal for 3 minutes and fielded 2 minutes of Q and A from me and the other group. I played the role of the customer/game master, answering clarifyng questions about the

I think it is fair to say that these exercises were hard. One of the exercises was to build a MMORPG. None of us had any experience building similar systems, so there were a lot of open questions about what was possible and how it could be done. I was probably not the best customer for this project either, since I have hardly seen a MMORPG before, let alone thought about how I would want one to work. Even if you are familiar with the domain and know about some of the relevant technology, it is still hard to cover all of the architectural bases in 25 minutes.

In the retrospective that followed the question came up, what are these exercises good for? Would this exercise really be valuable to the customer? Andre voiced his skepticism of architecture as a subject because that is not how he would ever work with a customer. As agile-minded folks, we prefer to see the architecture emerge as you are iterating and building the system with your customer. I don't think these exercises are really intended as practice for starting a project with a customer, although I may have set that up by calling myself the customer at the beginning of the exercise and saying that I would decide if I wanted to buy the system at the end. I like these exercises because it is an opportunity to wonder about how things work, and it piques my curiosity to go learn about technology that I haven't had a chance to use at work before (or yet?).

One benefit that we saw of these exercises is that they could get the whole team involved in design. Sebastian told us that his team actually does something similar on a regular basis. Pairs will take a card off the wall, think about how they are going to do it and "pre-sell" the approach to at least on the other pair (more for major changes). When the story is done they can present the result and the rest of the team has a chance to say "hey--that's not what you sold me!" which can help to reveal what the pair learned while they were building it. We also discussed ways of displaying architecture or the state of the system in the team area. One idea was modular printouts on the wall, legos or knex. All of these could be kept up to date as things changed. Sebastian once used the printouts as a progress chart, checking off parts of the system as they were completed.

All in all this was a fun kata night and I look forward to the next one. Many thanks to Ted Neward of Neward & Associates http://tedneward.com for letting us use his slides and architectural katas for our kata night.

Setting up Alfresco 3.3 Community Edition Standalone Deployment Receiver for WCM

I'm trying out the latest edition of the Alfresco content management system community edition. This is a free, open-source content management system that can do both document and web content management (and much more). What my company wants to use it for is web content management (managing html, php, css, images etc. for our many websites).

We like open source software so we are trying to use the completely unsupported, not guaranteed OS version instead of the fully supported and tested enterprise version. Without support or thorough documentation I am on my own (with the help of generous community members) to get this thing installed, configured and up and running and to keep it that way.

One aspect of getting this project off the ground that was especially tricky was getting a Standalone Deployment Receiver working so that I could deploy content (again, html files, css, php) from my Alfresco repository on one machine to a folder on my web server. Here is how I did it:

Before I started I already had a Web Project in alfresco with some dummy content in it (index.html, and a directory with another html file in it).

1. Downloaded Linux Installer for Standalone Deployment Receiver, Alfresco-DeploymentCommunity-3.3-Linux-x86-Install, from http://wiki.alfresco.com/wiki/Community_Edition_file_list_3.3
2. Ran the installer (requires gui environment, expects to be able to pop up a window to walk you through installation)
3. Accepted all defaults, including port numbers
4. Started it up(start.sh)

Then I went to my web project in alfresco, and edited the web project settings and added a deployment receiver.  (My Web Project -> Actions -> Edit Web Project Settings -> Next -> Add Deployment Receiver) I added my remote machine as a test server.

Then I should be able to click My Sandbox -> More Actions -> Deploy, choose my test server and the content as it exists in my sandbox should be copied over to the remote server, but it didn't work.

Could not connect to remote service [rmi://144.118.94.157:44100/deployment]; nested exception is java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is: java.net.ConnectException: Connection refused

I did some googling around and found several people mention that you need to do two things: add a setting to JAVA_OPTS for your alfresco tomcat and set up /etc/hosts in a certain way. I tried a bunch of different things that were suggested, but here is what I did that actually resulted in a successful deployment:

1. Made sure that my remote server had the 44100 port open
2. Made sure the deployment receiver was running on my remote server
3. Added to catalina.sh (/tomcat/bin/catalina.sh) the following line near the top before the first time JAVA_OPTS is used:

JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=144.118.68.94"

4. Modify /etc/hosts on the alfresco server to include a mapping from its IP address to the domain name like this:

xxx.xxx.xx.xx mydomainname.com

xxx.xxx.xx.xx is not my real IP address, obviously. On the remote server I did the same thing, mapping its IP to its domain name and mapping the alfresco server's IP to the alfresco server domain name, although I'm not sure that was necessary.

5. Restarted alfresco and the remote server (and started the FSR on the remote server again)

Finally! I am able to deploy snapshots from my sandbox to a test server. By repeating the process and setting the second machine as a "Live Server" in the web project settings I am able to deploy snapshots of approved committed content from all users to another remote server. On the remote servers you can do whatever you want, like deploy your web content to a directory that an apache instance serves up and voila! you have a website.

FYI, here are some of the sources I used to piece together this soution:

• http://wiki.alfresco.com/wiki/WCM_Deployment_Features
• http://forums.alfresco.com/en/viewtopic.php?f=8&t=4718
• http://forums.java.net/jive/thread.jspa?threadID=52597 

Influencing Your Way to Agile

I recently presented at the Emerging Technologies for the Enterprise conference in Philadelphia.



It was a fantastic conference, as always with the folks from Chariot Solutions. I had a great crowd even though I was in the last slot of the last day of the conference. For all of you that couldn't make it (and those of you who did and wanted my slides) I thought I'd write up my thoughts on influencing your way to Agile.

I love Philly ETE because of the community and the amazing speakers and all of the focus on new technologies, emerging practices and practical tips and tools—things that are relevant to the work that I do everyday that I can take back with me.

But how often do you really bring those ideas back to your organization and change things?

I'm not saying it doesn't happen—I have brought back some valuable tips and definitely picked up new technologies, but especially the ideas that involve changing the behavior, actions, opinions of others—maybe Uncle Bob sufficiently shamed you into deciding that you and your team needs to actually practice TDD—so many ideas like that fizzle out before they ever have a chance to become reality.

What inspired me to study influence is the patterns that I saw over and over again: You're in a company on a team. You have your job; you depend on some people and some people depend on you. There are some norms for how things get done, for how people interact and communicate. As an individual and an organization you sometimes fail and sometimes succeed at what you do. Love it or hate it but if you care at all about what you do and your organization (or the people in it) you see some room for improvement. So, you come up with an idea.

The goal is usually to take your idea and get to the point where you can give it a try so that you have a shot at turning it in to reality and making a positive change in your world.

But how do you get there? For most non trivial changes you have to get some others on board before you can turn your great idea in to reality. So between the time that you have a great idea and you give it a try you have to go and talk to them, convince them to go along with it.

What really bothers me is all too often you get stuck at these in between points before you even to give it a try. And what happens is that over time when you hear "no" often enough you often start to give up before you even try.

So many ideas, so much energy gets lost (wasted) because we don't know how to communicate our ideas and we don't have the relationships and skills we need in order to be able to successfully influence each other when a great idea does come along.

I know I titled my talk “influencing your way to agile” but I’m not really here to talk about agile. Agile is a mindset--a conscious decision to accept change and adapt the way we work to accommodate constantly changing requirements. In my mind a commitment to agile is also a commitment to discipline and continuous improvement. I’m not strict in my observance of agile practices--Agile techniques are just more tools in my toolbox, but I do buy into the core principles of transparency, collaboration, responsiveness, getting things done. They just seem like good ideas.

Most developers that I meet are either on a team that is trying to "be more agile" because of some pain or frustration with their current way of working or is already "sort of agile" and dealing with the same or new pains and frustrations with the way they work.

Regardless, I don't know if I've ever met anyone that has said "yeah, everything about the way my project/organization/community is perfect--nothing needs to change“

It doesn't matter if you are a developer or a team leader or an executive--I hear the same sort of thing--everyone has frustrations, sees opportunities for improvement, occasionally comes up with new ideas. Everyone is dealing with change and the behavior of others.

Behaviors are very hard to change. One way of looking at it is that there are two ways to do it and they are by influence or by authority.

If you are the CEO of your company (and a totalitarian one at that) then you can use your authority to force people to change their behavior. Most of us don’t have that much authority over others, which means we have to use our influence.

You are going to need to learn how to exercise the influence you have and grow your influence (by building the working trust relationships and trust between you and the people you work with) in order to make change happen.

Some people are really good at influence. The rest of us have to practice.

So I’ve come up with 6 steps to help you practice, or exercise your influence. These are meant to be applicable to exercising influence over your teammates, boss, customers, anyone. These steps are very simple and I can’t provide you with any sort of guarantee, but I have found that when you are just starting to become aware of the positive influence you can have on the people around you and you want to get better at it it helps to have steps to follow.

Step 0: Generate ideas

You can't influence change if you have no idea what you want to see happen. This is step 0 because most of the time you already have an idea before you come to me to talk about how to learn to exercise your positive influence on others.

Step 1: Pick an idea and take time to think about it

It is important that you are sure that the idea you decide to try to introduce into your organization is a good one. Also, you want to be sure that this is an idea that will benefit the whole organization--not just you or your team. If you are just out to make your own life easier you are going to have a harder time finding allies for your cause eventually. If you do believe that this change would benefit your organization as a whole then you also need to spend time practicing explaining that benefit--make sure you can clearly articulate what exactly you propose and how it specifically meets a need or contributes toward a goal for the organization, elevator-pitch style.

Also consider if this is the right time to introduce a new idea and make a big change. I tend to get excited about making improvements and want to start everything right now. The right idea at the wrong time is not the right idea, though, and that can be hard to see, especially if this improvement is one you have been searching and thirsting for for a long time.

Step 2: Find potential allies

Just like with collecting ideas you will need to collect allies. Who can help you make the change you are proposing? Who absolutely has to be involved? In other words, who do you need to influence?

Pick one person to start with.


Step 3: Get to know your potential ally

If you have a good working relationship with someone and you trust one another then it is relatively easy to convince them to help you try out a new idea if you really believe in its value.

If you don’t have a good working relationship with the person you decide you need to influence be ready to sell your idea—think of what they value, what they need—how would this change benefit them and their current situation. Some people can be convinced purely by explaining the benefit to the organization, but I don’t count on that. If the change that you are proposing doesn't benefit them directly sometimes you can offer them something unrelated instead. Is there a project they are working on that you can help with?

Communication styles are extremely important and we are often unconscious of the effects that our differing styles have on our ability to collaborate. Some people are very formal and others are very casual. Some people want all of the facts and they want them in writing, others would be annoyed by that. Some people want to hear an idea only after it has been fully flushed out, others prefer to hear about an idea at the very earliest stage (later is boring). It is important not to ignore the other person's preferred communication style and it often helps to adapt your style to match theirs while you are asking them to do you a favor.

Once you have thought about all of these things you are ready to go ask!

Step 3.5: Assume they are your ally

I caution everyone to skip this step at your own peril. When you don't have a good working relationship with someone (or especially when you have an antagonistic relationship) it is all too easy to walk up to them with your shoulders tensed and eyebrows lowered like you are ready for a fight. You may even have your come backs or defenses prepared ahead of time. If you do this be prepared to fail at influencing them to join your cause.

Push everything out of your mind except that which has to do with how your interests overlap and your future successes can reinforce one another. Picture them as an ally and then walk in to their office.


Step 4: Ask for it

Make your proposal, ask for their help. Show how it benefits them (and the organization). Listen to what they say in response.


Step 5: Rinse and repeat

The more successful exchanges you make the stronger your relationships become and the easier it is to get a yes.

Dealing with "No!"

If you go around asking people to change their behavior you are going to hear a lot of "No"s. It is important to listen to what they say when they say no, and how they said it and then to reflect on what happened. Was there a problem with the idea or with the relationship or the presentation of the idea? Often a combination of factors. It is important to reflect on the many refusals that you will receive to either come up with a better idea, or a better way to present the idea or to find relationships that need more work and ways to improve those relationships.

Here are some questions to ask yourself:

• Did you present the idea in a way that made sense to them and their situation?
• Do you really understand their context?
• Was it a good idea?
• Was it the wrong time?
• Do they trust you?
• Did they really say no?

That last one is interesting because sometimes they don't really say no, but they also don't say exactly what you were hoping. Often times instead of no they want to discuss your idea, criticizing it or questioning some of your assumptions--listen and learn what you can. A good critic can be one of your best allies sometimes.

But sometimes it is the relationship that is the problem and the other person is never going to say yes to your idea, no matter how good or beneficial to them. You might think the other person is just stubborn/incompetent/uncaring/evil. When they say no it feels personal. The resistance/misunderstanding is often a result of the positions that we hold in our organizations. When I start to view someone as hostle and irrational when they reject my ideas I like to ask myself this question: If you swapped jobs/roles how would the dynamic be different? Would you feel the same way they do? Would you act the same? Be honest.

Often if I can get out from under my anger and frustration I can see how the position the other person is in leads them to react to my idea in a certain way and that I would probably do the same in their position.

In my talk I went through some of the common patterns of system-related tensions and how to address them. Rather than go through them again I am going to just say that you need to read Seeing Systems: Unlocking the Mysteries of Organizational Life by Barry Oshry.

If you are having a hard time forming productive relationships across all layers you are going to have a hard time influencing change. Seeing these patterns helps you empathize, so that you can approach your colleague as an ally instead of an enemy. Seeing is not going to solve all of your problems, but it certainly helps.

Let's get practical

Okay, I want to give some practical tips for influencing change. The first three are general things that you muse do to succeed at influencing your organization:

• Care deeply
• Be positive
• Stay focused

If you don't care deeply about the success of your whole organization and all of the people in it you are going to have a hard time mustering the energy to make real change happen.

Be positive to attract followers. Cynicism wears you down eventually and people are already going to be tired from all the work it takes to change our behavior for the better.

Stay focused: it is easy to get distracted at work because there are always a million things to do, fires to put out. Change is very slow and influence is very messy and if you lose focus on what you are trying to accomplish, well, you are not going to succeed. It isn't easy, but I find that it helps to have some key allies in play to help me stay focused. If you set up a regular meeting with an ally or mentor to discuss your progress, for example, it is a little easier stay focused week after week.

Don't be afraid to ask for help like that. Another common urge when you are championing a new idea or big change is to want to hold on to it like it is your baby. The thing about organizational change is that it needs to grow to be successful and that means you need to let it get too big to fit in your hands alone--ask for help. Getting help also means that you will be less likely to burn out and lose focus before you have reached your goal.

One good way to attract followers without having to hunt them down is to make your efforts visible. In Scrum we like to have information radiators in the team space so that anyone, any teammate or stakeholder or anyone, can walk by and see what is going on--what is done, what hasn't been started yet, what has been sitting in the in progress pile for a week (stuck?). This is also a good idea for your change projects. If you try out your new ideas and have a little success and want to try it on a larger scale, make that visible however you can.

Speaking of success, don't forget to celebrate even the smallest of victories. Cookies, a lap around the building, high five, happy dance, however you and your allies prefer to celebrate, take time to do so. And say thank you!

Whew, I have several more practical tips that I covered at ETE, but rather than write them all out here I'm going to say that instead you should go read Fearless Change: Patterns for Introducing New Ideas by Mary Lynn Manns and Linda Rising. This book is chock-full of simple and widely used tactics for introducing change. All of my favorite tools were in there as well as many that I hadn't tried before that I wish I had known of sooner.

Finally, be patient. I can't stress enough how SLOW change is. Some days it feels like we must be moving backwards we are moving so slow, but you have to keep working and stay positive and put on your long-range goggles before you give up and decide that it is hopeless.

And be flexible too, as the momentum for your change grows and you attract followers to your cause and learn about your organization your idea is going to change. Let it change; learn as you go. "Power is the ability to act as if you can make happen whatever it is you want to make happen, knowing that you cannot, and being willing to work with whatever does happen" -Barry Oshry (Seeing Systems)

Thanks for reading so long! Let me know how you are doing. What ideas are you trying to introduce? What are your favorite tools for introducing change?

My First Spring Roo App (two months later)

Getting Started with Spring Roo

When I started working with Roo I think they were on RC 2 and now we are on the full-fledged Release 1.0.0, and I noticed that a lot of the tutorials that got me through those early days are a little outdated since a few common commands and generated output have changed over the past two months. I thought since I borrowed so heavily from the ROOsters before me (thanks BTW, Ben Alex and Stefan Schmidt) I would return the favor and talk about my experience a bit. I haven't gotten around to writing my own step-by step guide, but at least I can tell you more about why I chose Roo and pass along the things I have learned along the way.

I don't remember when I first learned about Spring Roo, but right from the start I was impressed. I cut my Spring teeth working on a few fairly large and complicated Spring webapps for about a year before I met Roo. I did the Springsource training, drank the koolaid; I honestly like working with Spring and I feel at home working in Java, but I did miss the fun and seemingly fast-paced development on the Rails projects from my past. Roo promised to bring back the fun and help to make a lot of the routine work of writing Java code disappear.

I had a little side project that started up in November of 2009; the idea was basically a really simple CRUD app. Three domain objects, some security, done. We all know how requirements do tend to change and multiply (especially when you bring a nice-looking and complete webapp as a demo to the first meeting, thanks to Roo), but this project is under control and I am still using Roo to add functionality (like email sending) and to manage the simple domain objects and their controllers and views.

Gotchas

Oh man, have I fallen into a few holes on my way to getting this app off the ground. Some of them turned out to be ROO bugs (I was working with the release candidates, after all) and others were just boneheaded mistakes on my part. In hopes of helping you avoid the same traps here is my list of gotchas and tips for working in Roo. I'll update these as I get a chance, but here are some of my recent lessons learned:

• If you push in Roo on your domain object so that all of the entity management code is laying around and love to collect all of your imports under something like javax.persistence.* make sure you have an explicit import for javax.persistence.EntityManager. I usually set my minimum pretty low, so that if I optimize imports (ctrl + shift + o in eclipse/STS) then it will use a * instead of listing imports individually if I have more than 10 or so from the same package. That is normally fine, but causes serious problems for your little Roo app. It will yell at you for not returning the right type on your entityManager() method.
• I am using some security on my manager methods and I went to write a test and I wasn't getting the results I expected. It was saying something about "can't parse expression" referring to the Spring EL expression that is used in the PreAuthorize annotation on my manager method. Well, it turns out I was using the wrong kind of authentication token to fake someone being logged in for my tests. Here is the real way to do it:
  
  

  I call this from my test:
  

  private void addResearcherToSecurityContext(Researcher researcher, boolean admin) {
       Collection authorities = researcher.getAuthorities();
       if (admin) {
           authorities.add(new GrantedAuthorityImpl("ROLE_ADMIN"));
       }
       TestingAuthenticationToken authentication = new TestingAuthenticationToken(researcher, researcher.getPassword(), authorities.toArray(new GrantedAuthority[authorities.size()]));
       SecurityContextHolder.getContext().setAuthentication(authentication);
  }
  

  
  and put this in my test application context:
  

  <bean class="org.springframework.security.authentication.TestingAuthenticationProvider" id="testAuthenticationProvider" />
  

  
  and put this in my test application security context:
  

  <authentication-manager alias="authenticationManager">
  <authentication-provider  ref="testAuthenticationProvider" />
  </authentication-manager> 
  

  
  Simple, huh? It really is. You should know that my Researcher object extends UserDetails and that is what I use for authentication. Now I can write methods where I try to update someone else's account or do admin-y things as a non-admin and make sure that I get an access denied exception and all my data is safe.
  
  
• This is more of a spring/hibernate thing than a Roo gotcha, but I'm going to put it here anyway because it just happened to me again... If you have a manager or, in this case, a test, and all of the methods are transactional. Don't annotate each method with @Transactional because inevitably you are going forget one time and then sit there running your test over and over wondering why it is saying "org.hibernate.SessionException: Session is closed!". You can stick the @Transactional on your class and then you are all set, no matter how many methods you add.
• Don't forget: the forums and jira are your friends. There is also a seemingly constantly growing list of Roo links and resources on the forum

Pair Exchange Program

I just finished the first ever pair programming exchange program!

It all started when I was at SDTConf back in October. I don't remember the exact conversation, but the question was generally if software development as a craft takes two programmers pairing together to pass on and practice the craft then how will it ever scale?

Someone jokingly suggested that Corey Haines should get a bigger car--Corey travels all over the place pairing with people and promoting the craft of software development. One idea that I think Corey actually proposed was the idea of a pair exchange.

The idea is simple: we can't all get Corey Haines or another big name in the XP, Agile, Craftsman, etc. communities to come and pair with us, but there are lots of smart people in every town. If you two are both passionate about practicing and improving your skills then why not use each other as a resource? Everyone has a vacation day to spare, take a day and go pair. If your boss will let you, bring your pair partner to work.

I know a lot of developers in Philadelphia and I had no trouble thinking of the perfect programmer to pilot my pair exchange program with. Woody Zenfell III is not only one of the smartest and most professional programmers I have ever worked with, but we make a killer pair. It is like our brains are wired almost exactly oppositely, but we get along really well. I like that he is fun to work with and we get a lot of good work done together. Plus, I know his company already and I know that he is on a team of 1 and is probably missing working with other developers.

When I first brought this idea up to my manager I had reason to be optimistic. My manager sees the value of pairing, even though my team doesn't really practice it much, and he is very supportive of learning and professional growth. I was thrilled when he agreed to the whole thing, both me going to Woody's office for a day and for Woody to come and pair with me and chat with my team. Woody's boss was also game and we were set!

We decided to do one day at each office, back to back. Since this was our first pair exchange we didn't really know what to expect other than that we would show up, work on some stuff and see what value we get out of it. For me, I knew Woody's code base pretty well, having actually worked on it with him back in our consultant days. For Woody, my team culture and our domain and the code base were all new, so a chunk of time in the morning went to talking about those things. Other than that we just paired; it was awesome. At Woody's place we had some tasks that needed to get done and so we did them. At my place we talked about design for a long time and wrote a test that I was having a hard time writing. Lots of great side-conversations happened with my teammate neighbors. It was fun and we got a lot done.

What did we get out of it?

For this first exchange it seemed like we were for the most part exchanging little tips, tricks and techniques that make us more efficient and effective. Woody, for example, showed me how he is creating dependency graphs (actual pictures) for all of the stored procedures and reports in his system, automatically, so that he can more confidently make changes to them. He is also getting those database elements into source control and refining a test and deployment process for them, which is something I hadn't thought of before, but is really smart given how important those reports are to his company. He also showed me captures in EasyMock, which were exactly what I was always dreaming of but never had because we were still using EasyMock 2.3. In return I showed him ctrl+r in cygwin/linux for searching your history. Then he showed me pushd and popd--that's just so handy.

In addition to tips and tricks we had a lot of conversations about how we do things, like how we work with our users and what process we follow for organizing our work and testing and deployment.

At the end of the second day we took several laps and talked about the experience. We agreed that it was definitely valuable and something we want to do again. We imagined that after a while we will run out of tips and tricks to show each other and then we didn't know what would happen then, but maybe that we could use each other as reinforcements for when something really sticky comes up and we need a fresh perspective. We talked about doing it again quarterly or monthly or more randomly. We aren't sure how our bosses viewed the experiment, and of course they would have to feel like they are getting a good deal out of this for them to allow it to continue. A lot of factors went in to making this experience go smoothly: the fact that we have both paired a lot before and with each other before, that our bosses are agreeable, there are no super-high security requirements that would prevent guests from coming over and peering at the code, etc. I am curious how well it would go if I was pairing with someone I didn't know very well.

I would love to hear about more people who are trying this sort of exchange. If you don't have teammates who pair (or teammates at all) you don't have to miss out on the benefits or pair programming--the discipline and the sharing of new ideas.

Url patterns for servlet mapping

I came across a baffling problem with my servlet mapping recently for my java web application. In this project we generally use extension-based url patterns for servlet mapping. For example:

 <servlet-mapping>
  <servlet-name>myServlet</servlet-name>
  <url-pattern>*.html</url-pattern>
 </servlet-mapping>

This means that every request that comes in that ends in ".html" will get passed into my servlet instead of being handled by Tomcat (who would serve it up like a static file). The problem came up when we could not use extension mapping because we had a few .html files that needed to be served up by Tomcat and the rest were dynamically generated by my servlet. But when I tried to use a path-based url pattern it didn't seem to work as I would expect.

Here is the situation: I know that all .html urls that have the word "library" in the path to need to be sent to my servlet and all other .html requests to be handled by Tomcat, so I tried the following:

 <servlet-mapping>
  <servlet-name>myServlet</servlet-name>
  <url-pattern>/library/*</url-pattern>
 </servlet-mapping>

My servlet is expecting requests to come in like "/library/index.html", and it worked with the extension url mapping, but with the path url mapping it didn't. It was like nothing was getting passed into my servlet. I did some searching and I didn't find anything in the Java Servlet Specification or on any blogs or forums that explained why path matching would be so different from extension mapping, until I came across this post where PhilipT in the comments explained how tomcat was stripping out the matched part: "So it seems that the Tomcat default servlet (6.0.16 at least) drops the servlet mapping and will try to find the file by using the remaining path." This made me wonder if that always happens with path matching.

I also learned from that post that you can map urls back to tomcat from your servlets web.xml file. In our case we haven't tweaked tomcats configuration so the default servlet is called "default". I let my servlet handle all .html files and I tell tomcat to handle things that come through with the words "static-content" in the path. Since the order of precedence is exact matches, path matches and then extension matches this works exactly as I want it to.

 <servlet-mapping>
  <servlet-name>myServlet</servlet-name>
  <url-pattern>*.html</url-pattern>
 </servlet-mapping>
 
 <servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/static-content/*</url-pattern>
 </servlet-mapping>

The only catch with this solution is that you have to remember to put /static-content/ in front of the path to the static content that you want served up by tomcat. It is possibly confusing because there is no "static-content" directory on the server. To give an example, the html files that need to be served by Tomcat are for the fckeditor that we use in our web application. When you want to include a fckeditor on a page you have to tell the javascript where to find the fckeditor home directory. For our project it is a directory called fckeditor sitting in the war directory for our application. Previously we would just say that the home directory was /fckeditor/ and Tomcat would know to find it in <war directory>/fckeditor. Now that we are using path matching we have to tell the fckeditor javascript that its home directory is /static-content/fckeditor/, even though it is still physically on the server at <war directory>/fckeditor

Scrummity Scrum

As a software developer I find agile/lean practices in general to be a really awesome way to go about making awesome software. This means that you always shoot for the simplest thing that might possibly work and rapidly produce working software that you can show to your client, get feedback on, and improve. Lots of features that seem like great ideas in the beginning end up getting de-prioritized or thrown out all together and other great ideas are added. In the end the client ends up getting software that meets their needs at minimal cost---plus it's a fun way to work. Just saying "let's go lean" doesn't cut it though; the process of building custom software is complex and keeping the clients ideas and feedback organized and up to date so that work can get done effectively and without confusion is a challenge---especially when working on teams. That is where different agile tools come in. One of which is Scrum.

A little while back I completed my Scrum Master training in NYC. I really love it. Scrum is about making everything visible. At my office we have a Scrum board, onto which we pin user stories in different columns, reflecting whether they are to-do, in-progress or done. There is also space for impediments and tasks that the team needs to take on outside of the usual work of producing code. Each day my team gets together to check-in about which stories we worked on and which we intend to work on before the next check-in. As stories are completed throughout the day we walk up to the board and move the index card with the story written on it to the "done" pile. If at any time you don't know what to do, you can always walk up to the Scrum board and pick a task from the to-do pile and start working on it. At the end of each week the team gets together to reflect upon the previous week and every two weeks (our iteration length) we make a plan for the following iteration. Planning entails committing to complete a number of user stories before the next planning session.

Scrum also calls for a "Scrum Master" who runs interference for the team so that (ideally) nothing distracts them from completing the work for the iteration. The SM may also interface with the client to create and prioritize user stories for the upcoming iterations.

Thoughts: "The Outsourced Brain - New York Times"

The Outsourced Brain - New York Times by David Brooks. Read it here.
From the article: "...the magic of the information age is that it allows us to know less. It provides us with external cognitive servants."

I have been thinking a lot about the information age (vs. industrial age) and how technology is extending our minds (as it used to only extend out bodies). This op-ed really catches the essence of the current mind-extending possibilities of technology. Rest assured this is only the beginning... or is it?

Is it just the continuation of a trend that started when the first humans made the first tools?

McLuhan was the first to introduce me to the idea of extensions of ourselves (not personally, of course, but through his book "Understanding Media: the Extensions of Man") I was intrigued by his ideas (example: telephones are extensions of our voices), but it didn't really see technology extending my mind in my everyday life until I became dependent upon my cell phone and google to remember my friends phone numbers and where to find web pages and information that I want.

In the NYTimes op-ed (link above) Brooks claims that this mind-extension is liberating and blissful, but McLuhan often mentions that with extensions of man come amputations. Brooks can no longer navigate without his GPS and he feels zen about it, but what happens when the satellites go down? I am not comfortable with living in a world where I can't function without my tools. To use a historical example: the technology of guns extended mans ability to destroy people/things from afar but it amputated his ability to use a bow and arrow. What if then all the gunpowder ran out? As a pacifist I say all the better, but if people had a need for weapons they'd be screwed. Living in a time of transition from one technology to another this is the risk we face.

I hate to make this argument though because I hear it so often with regard to technology in education. Teachers say things like "why should we bring technology X into the classroom? Shouldn't we just stick with the old way of doing things?" Here is the rub, if you want to extend your mind you sometimes lose (amputate) an older way of doing things. I am sure there is a delicate balance between rushing headlong into adopting new extensions of ourselves and holding steadfast to tired old ways, but it is hard to know where to draw the line, especially within education when we are not only making the decision for ourselves, but for loads of children.

What I need is a good argument to convince educators that some technologies are more beneficial to students than traditional methods, others are not. Considering my argument against Brooks' GPS dependency, maybe I need to first convince myself.

Review of American Prometheus: The Triumph and Tregedy of J. Robert Oppenheimer by Kai Bird and Martin Sherwin.

From beginning to end I was captivated by the story if this enigmatic man, Robert Oppenheimer. He was sometimes arrogant, sometimes naive, and sometimes full of deep wisdom. He was sharp and charismatic to some, though others found him cold. He had a great gift for seeing the big picture and synthesizing ideas, which made him an especially effective leader of the scientists at Los Alamos working on one of the greatest scientific accomplishments of the century, the harnessing of atomic energy and the creation of the atomic bomb. He had to accept responsibility for the terrible destruction that his creation brought to the world but he didn't regret what he had done. At first I didn't understand why, but now I see his wisdom. The science which led to the making of the bomb was being realized by scientists all over the world and it was inevitable that someone was going to make it. In Oppenheimer's case, he felt it was urgent to beat the Nazis to it if they were indeed on track to produce it, which it turns out they really weren't, but he couldn't have known that at the time.

What left me most troubled after reading Oppenheimer's story was not his role in the creation of the bomb, but the way he was treated in the 1950's when his enemies sough to destroy him politically because they didn't agree with his pacifism. Oppenheimer was against the nuclear arms race and especially the creation of the hydrogen bomb, a much more powerful weapon than the atom bomb. The H-bomb couldn't really serve a military purpose, it wasn't even a city destroyer, it would destroy many cities at a time. In Oppenheimer's mind it would be more worthwhile to produce smaller tactical nuclear weapons for combat use, but the republicans in power felt that it would be wiser to instead focus on having the biggest bomb possible, thereby deterring anyone form ever attacking us for fear of total annihilation.

It is true that Oppenheimer had a past worthy of inspection for someone so close to so many national secrets, but despite the fact that no one managed to find him guilty of any crime other than making some "poor decisions" he was still left completely ruined by these accusations. Although the Atomic energy Commission "inquiry" found him totally loyal to America, they decided he was nonetheless a security risk. Why? Because he disagreed about the direction America was headed in foreign policy.

As I read the tactics used by his accusers I was shaken by the realization that nothing they did then couldn't happen today. While I don't want to believe that full scale McCarthy trials could happen in exactly the same way today I think a great scientist or intellectual like Oppenheimer could be taken down privately, the way Oppenheimer was, without justice and in the name of security. This kind of injustice does little to improve security, and even worse, it diminishes the likelihood that we as a society are going to come up with the solutions we need to face tomorrows security challenges because we have disbarred, alienated, or scared off our greatest minds from speaking up when they recognize a problem.

After finishing this book I sat and reflected upon the story and the potential for similar injustices taking place today and I wept. This story must be known by everyone.There is no black and white right and wrong to it, in the end Oppenheimer is not the golden hero, his enemies shamed, instead we are left to reflect upon our past and present actions, as Oppenheimer did his, and accept responsibility for our part in it, whether for good or for evil. Our ability to avoid future disasters depends on our ability to understand this and learn from it.

American Prometheus: The Triumph and Tragedy of J. Robert Oppenheimer by Kai Bird and Martin J. Sherwin. Vintage Books, New York. 2005

Here is a post I made today for my class on learning technologies:

All of the authors (Engelbart, Schank and Cleary, and Valdez) made a distinction between the role that technology currently plays in teaching and learning and the potential role that technology can play. What seems to be of most interest to the bloggers so far is why the potential usefulness of technology in the classroom has not been reached.

Most would agree that teacher competence/comfort with the technology is a primary requirement for the technology to be useful in the classroom, and as Laura added there are other factors, like administrative and tech support that are important too. I want to add one more requirement to the list before moving on: the software has to be well designed.

Something that resonated with me from Schank and Cleary is that the authors admitted to the shamefully poor design of most educational software out there. Granted they were writing in the 90's, but I think that is still the case today. A lot of software is still written from top to bottom with only a vague idea of who the user is going to be. If a teacher (or any user) can't sit down and immediately figure out how to use the software, then the developer has failed. This is my opinion as a software developer, but it is not an uncommon one. My point is that as much as educators (and all users) need to familiarize themselves with new technologies and approach them with a workable attitude, the technologies have to lend themselves to being easily understood. Unless the creators of educational technologies are working together with educators, no progress can be made towards reaching the potential of technology's use in the classroom.

So what is the potential role of technology in the classroom?

Like textbooks, technology can be a source of information. Like pencil and paper technology can be used for creative purposes. To quote form Valdez, "A reasonable conclusion is that classroom computers and other technology can play many instructional roles, from personal tutor and information source to data organizer and communication tool" (from the overview). I think technology is already being used as an information source (web-based research) and a communication tool (email), and maybe as a data organizer (blackboard, excel), but I don't think classroom technologies have yet to reach their potential as personal tutors.

Each student has unique abilities and interests, but it is exceedingly difficult for one person to attend to the varied needs and interests of 30 young minds in the typical classroom. Technology can help, although it will mean changing the way we think about schooling. Something that I think is the most important point that I took from my reading of Engines for Everybody is the need for more student-directed learning, what Schank and Cleary also called natural learning. To summarize Schank and Cleary about natural learning, students learn best when they are the ones choosing what to learn and when. This doesn't mean that kids should be turned loose in the streets, this can happen in a regular classroom with a regular teacher (check out this biology class example).

I would like to further discuss the ways in which technology is or can be used to personalize each student's education.

Eating in the dark

Last night we went to the "Unsicht-bar", or 'the invisible restaurant' as I like to call it now. It is a gourmet restaurant in complete darkness. You come in and look over the very vague menu (they intentionally don't tell you exactly what you will be served) in the light and then are led by your blind or partially-blind server into the dining room, which is completely dark. I don't know where to begin describing the experience; it was like nothing I could've imagined and was hard even at the time to understand how I felt about it. The first thing we all experienced was a brief moment of panic. Our server shut off the light in the dim anteroom and told us to grab on to each others' shoulders like a conga-line. I think the four of us all have some claustrophobic tendencies, and it was rather warm in there, which only made it worse.

Once we were each led to our chairs, it was easier to relax and start to appreciate the environment. We couldn't tell how big the room was, but I heard at least three other tables of people. The music was a little too loud, but I think it helped people feel more comfortable talking and less isolated in the dark. There was a fan somewhere providing a merciful breeze, but it wasn't always blowing in our direction. We had to reach out for each other to have an idea how we were seated. I could hear our friends' voices, and I knew we were at the table together, but it was important to me to know exactly where they were sitting and to touch them.

Once settled we had to fight the tendency to try to see, despite the impossible darkness. My eyes, on their own, were squinting and opening wide, alternating trying to focus on some invisible person or gather as much of any potential light in the room. I also was seeing washes of color and random shapes and even an imaginary table and people around me, as if my mind was using aural and tactile input to create a corresponding virtual image.

As promised by the "Unsicht-bar" website, dining in darkness sharpens the other senses. We smelled the beer coming when our waiter, Andre, wheeled the drink cart up to the table. The food tasted not only gourmet, but wonderfully exotic. My favorite course was actually the salad appetizer plate, probably because it was my first food in the darkness, but also because it was the most diverse plate. I had actual salad, which is to say lettuce with tomatoes and dressing, but also little finger food: olives, nuts, carrots, mushrooms, something with a dollop of something hummus-like on top, some sort of stuffed pepper and a crunchy thing stuffed with something. The best part was when the plate was first placed before me and I could explore with my hands and nose. The first thing I did with each plate was stick my fingers in it. I ate with my hands half of the time---in the dark you don't have to worry about disgusting fellow diners with poor table manners (no slurping or smacking though). I secretly love eating with my hands. I was glad, though, that I had made a point of washing them thoroughly just before we went in.


Time had no meaning in the darkness. We ate at a leisurely pace, chatting about the experience and about unrelated things: traveling, sensory deprivation, New College. Our waiter, Andre, spoke perfect English, which was great because our friends did not speak much German. Andre struck me as a very insightful person, and I can imagine working in the darkness could give you a lot of time to reflect and see life (forgive me) from a different perspective. He was very calming and sensitive to our feelings; I can imagine some people finding the darkness upsetting or having panic-attacks.

I got rather quiet as the second course came along. The warmth and darkness made me feel too relaxed, like I needed to sleep. I wasn't actually tired, but I felt like curling up and sleeping. I felt like everything was going in slow motion, and my thoughts couldn't keep up with the conversation at times. Andre asked what I was thinking about all that time because he hadn't heard form me for awhile. It felt like a dream, I told him, but I wasn't thinking about anything. My mind was slow and blank. I could really forget that people existed at all and imagined the voices were coming directly from pure beings (pure being!) around me, and we were all floating in nothingness. I have never felt so... abstract. I forgot I even had a body, until this made me uncomfortable and gave me a little indigestion. A little ice water helped with that, and cooled me down in the still sweat-inducing room.

My main course was something like fried eggplant with an exotic curry-tomato sauce on top, served with nutty hush puppies and salty carrots. The fried eggplant was too hot to eat with my fingers, so I had to use a fork, which was funny because it is impossible to make an appropriate mouth-sized bite and you don't know it is too big until you try to put it in your mouth so I got a lot of food on my face. I had it easy compared to our friends, though, who had ordered meat and had to cut it with a knife! From what I heard that was no simple task. Dessert was ice cream with strawberry sauce---yum!

Andre told us that he loves traveling to London when he can (hence the good English) and that he would love to travel to the United States except that he is afraid of being thrown into jail and executed on the electric chair or something. I don't think he was really joking. There is a certain impression that foreigners have about our justice system, that it is baffling and irrational, and perhaps even unjust. On the other side though, he had told us when we were conversing earlier in the meal not to apologize for being Americans. We do have to apologize now when abroad, as if to make amends for our president and our war. Otherwise people say, "oh, you are an American... what the hell are you people thinking! Do you know what you have done?" Andre didn't say that, quite the contrary. He gave us a lot to think about.

It was wonderful to share the experience with good friends. Emerging from the darkness was like being born---my body re-materialized and I checked to see if I had spilled any food on my clothes (I hadn't---go me!). We said a warm goodbye to Andre, who had been our trusted guide and provider through the darkness and culinary delights. The meal lasted at least 3 hours, which Andre said was longer than the average, but I had no sense of how long it was; it felt like an eternity and no time at all.

Here is their website (German only): www.unsicht-bar.de

NASA's first (and last) artist in residence

Thomas and I went to a concert last night here in Cologne--It was so toll! Laurie Anderson was invited in 2003 to be NASA's first (and last) artist in residence, and this piece "The End of the Moon" is her official final project for NASA.

What the heck does NASA need artists in residence for? I am surely not the first person to ask this question. Thomas summed it up best when he said "It is such an awesome idea---that is what makes it seem so wrong!" I just can't imagine how they justify that as good use of tax money when government funding for the arts is being systematically destroyed everywhere else. I could go on, but...

In The End of the Moon, Laurie Anderson touches on the new technologies she was introduced to at NASA, personal stories, and larger issues like 9/11 and the shuttle explosion in 2003. Her poetry is wonderfully rambling and punctuated by mostly electronic music. Thomas and I both thought the music, although very beautiful, could have been used as more than just punctuation for her text. She obviously has a wealth of technologies at her disposal, but the electronic music did little more than set the mood. This may be an aesthetic choice on her part, and to be fair I think what makes her an "experimental" artist is the multi-media-ness and random format of her shows, and not any strictly musical experimentalism on her part. The audience LOVED the show and clapped her back on stage more than five times.

How cool it must be to be such a weirdo and rake in a symphony-hall-full of people at 25 Euros a head. It gives me hope for the future.

Here is a bit from www.laurieanderson.com:

THE END OF THE MOON

Laurie's latest performance The End of the Moon is the second in a trilogy of solo performance works that combines stories and music in an intimate setting. The End of the Moon includes music for violin and electronics creating a duet between the spoken word and Lauries signature sound.

Following the first piece in this series Happiness (2002), The End of the Moon draws upon Lauries recent experiences and research as the first artist-in-residence at NASA in 2003. Part travelogue, part personal theories, history, and dreams The End of the Moon looks at the relationships between war, aesthetics, the space race, spirituality and consumerism. Collectively, Laurie envisions this solo trilogy as an 'epic poem' which aims to paint a large picture of contemporary American culture.

For The End of the Moon, Anderson began examining the question, Who taught you what beauty is? Unable to provide an answer, Anderson set off in search of one. The End of the Moon is her NASA end-of-term report, a performance piece that suggests a fateful symmetry between journeys into outer and inner space.

l'Acousmatique

We went to this electronic music concert on l'Acousmatique, a French word describing a movement in electronic music that has something to do with the audience not being able to see or pinpoint the source of the sound. Apparently Pythagoras used to sit behind a screen when he taught, thereby forcing his young pupils to listen more intently and without distraction from the visual realm. I really dont understand what l'Acousmatique means with regard to electronic music because all electronic music concerts are like Pythagorean lectures, since the rooms are dark and everyone faces a blank wall with speakers all around. The composer, invariably dressed in black, sits in the back at a folding table with a laptop and a bunch of cables, but the sounds don't come from him and so the whole experience is disorienting for the traditional concert goer.

Anyway, the concert was great; it featured music by some visiting French-Canadian composers, my favorites were Ombres, Espaces, Silences by Gilles Gobeil and StrinGDberg by Robert Normandeau. Professor Normandeau had a lovely French accent, is the same age as my parents, and teaches at the University of Montreal. Thomas spoke to him after the concert. Unlike me Thomas has some idea about l'Acousmatique because he spoke about it with Franois Bayle, a French composer widely regarded as the father of the movement. Monsieur Bayle will be in Cologne in June!