# Monday, 12 April 2010

Episode 81

In this interview, Jennifer Marsman describes some of the new features of Windows 7 and how a developer can use those features to build more powerful applications.

Monday, 12 April 2010 05:27:31 (GMT Daylight Time, UTC+01:00)
# Sunday, 11 April 2010

Yesterday, I attended the second Kalamazoo X conference. This year's event featured a great list of speakers, presenting many thought-provoking topics. Ideas came at me so fast, it was tough to keep up. Here are some highlights of the presentations I saw.

"Treating the community like a pile of crap makes it stronger" by Brian Prince

The title of this talk comes from Brian's experience growing up in rural Maine and shoveling manure in the summer months. Manure works better as a fertilizer if you periodically mix it, moving the bottom to the top. The same can be said for user group leadership.
If you are a community leader, plan for a peaceful transition. Identify others who can take over and groom them to do so. Take some time off from the lead role in order to re-energize before coming back.

"Agile+UX: The Great Convergence of User Centered Design and Iterative Development" by John Hwang

John is a web designer and his company is applying agile methodologies to its project. He discussed the challenges of using Agile to manage User Centered Design (UCD) AND User Experience (UX).  The big challenge is that Agile is geared toward making developers more efficient, yet designers are a key part of any web development project. John avoids responding to amy Request for Proposal (RFP) because an RFP forceS you to estimate many tasks that you don't yet know and that are almost certain to change. He emphasized that development and design should be done in parallel and that the feedback loops and iterations of agile should apply to both. Developers and designers should work cooperatively, rather than in conflict.

"How to Work Effectively with a Designer/ How to Work Effectively with a Developer" by Jeff McWherter and Amelia Marschall

Jeff is a developer and Amelia is a designer and the two recently went into business together. They have worked together in the past and they related some of the challenges and lessons learned from their previous collaborations.

"Communication is the key" was a message they reiterated several times during this talk: Ensure that your partner knows what you are doing; verify that it is consistent with what they are doing and that the technology supports it. Developers and designers should strive to learn about the tools and skills of the others. It will help them figure out what they can accomplish.

Mock-ups are a key means for designers to convey information. Jeff said that he often writes business rules in the margins of Amelia's mock-up drawings.

"Does Your Code Tell a Story?" by Alan Stevens

Alan told us we should not bury the lead, so I will tell you his main point now: Beauty is the ultimate defense against complexity.

Alan took the advice of successful novelists and applied their principles to the art of writing code. "The code in our industry is crap", he asserted; then he explained how to make it better: Take chances; write shitty code in your first draft; refactor it several times; and make it clear, simple and obvious before releasing it.

"Unwritten Rules of Resumes" by Jeff Blankenburg

Jeff's major point was that your resume should stand out and distinguish you from other candidates. He advised ncluding a strong first paragraph in a personal letter, accompanied by a self-addressed, stamped return post card with your resume. This will help to establish you in the minds of the hiring personnel. Establish a strong professional network and avoid the temptation to burn bridges when you leave a company.

"Have you hugged your brand today?" by Clovis Bordeaux

Per Clovis, building a brand begins with a mission statement. A critical part of building your brand is getting every employee involved and on the same page, regarding the message you are sending about your company. 


Kalamazoo X home page

Photos

 

Sunday, 11 April 2010 17:31:03 (GMT Daylight Time, UTC+01:00)
# Tuesday, 06 April 2010

There is a reason why computer languages are called "languages". These languages share many common characteristics with the languages that humans use to communicate.

Humans use languages like English, French, Mandarin Chinese, and Farsi to communicate with one another. Programmers use languages like Java, C# and Visual Basic to communicate with computers.

Human languages contain words and each word has one or more correct spelling and one or more meanings; Computer languages have keywords that have a single correct spelling and one or more correct meanings.

Human languages have a grammar to which writers and speakers are expected to adhere. Deviating from this grammar makes it more difficult to understand the message. Computer languages also have a grammar that we call "syntax". It is not sufficient to throw together correctly-spelled keywords: They must be structured properly. Some languages have stricter grammar rules than others, such as a requirement that we declare each variable before using it.

Writing quality software in a computer language is similar to writing a good book or article in a human language. It is possible to write a poorly-written book in English that has perfect spelling and grammar. Microsoft Word will report no errors when you press F7 when editing such an article, but that tells us nothing about the quality of the writing, which may still be confusing or boring. Similarly, it is possible to write slow, non-scalable, difficult-to-maintain software that violates no rules of spelling or syntax. This software will compile but will not perform well.

The main difference between human languages and computer languages is the precision required by each. We can communicate reasonably well in a human language, even if we use poor grammar and poor spelling. This is because we have other communication mechanisms to use, such as expression, tone, gestures and a shared context with others. Computers are generally not smart enough to understand us unless we are very specific in the words we use and in the way we structure those words. We must be more careful what we type and how we compose our words when communicating with a computer.

This is why I believe that writing software has improved my communication skills in general. By forcing me to choose carefully my words and grammar, I get in the habit of communicating with greater clarity.

Tuesday, 06 April 2010 17:53:25 (GMT Daylight Time, UTC+01:00)
# Monday, 05 April 2010

Episode 80

Monday, 05 April 2010 17:20:24 (GMT Daylight Time, UTC+01:00)
# Thursday, 01 April 2010

The last couple years, I have significantly increased my use of social media.

I don't believe that online social media is a replacement for face-to-face human contact or for a phone call. But it is a good way to stay connected with others between personal visits.

My primary social media sites are LinkedIn, Twitter, Facebook and Flickr. I use each of these channels for a different purpose and to communicate with a different audience: My resume is on LinkedIn; I chat with IT professionals daily on Twitter; I re-connect with old friends on Facebook; and I use Flickr to share photos.

I joined LinkedIn a couple years ago in order to connect with professionals with whom I had worked. I input my resume and built up a network of current and former co-workers. At the time I was building this virtual network, I didn't realize how useful it would be. A few months after joining LinkedIn, I found myself out of work and needing to network. I reached out to my connections and asked people to log in and write their opinions of the quality of my work. The response was overwhelming. Over 30 people wrote recommendations within a few days of my request. Several times, a potential employer mentioned these online praises during a job interview. I ended up finding a job quickly, via networking.

I use Twitter to communicate with like-minded souls in the tech community. As a software developer, I'm drawn to people who share my passion for learning and for technology. Many of the developers I know are also on Twitter. As a general rule, I tend to follow only those people that I've met in person or that I think I might meet soon. I see many of them at conferences a couple times; but our conversations on Twitter help to keep the relationships going between in-person visits.

I'm a pretty passive user of Facebook. I see my kids using the chat feature and I often see long, threaded conversations on the walls of others. About the only thing I do actively and regularly is advertise new blog posts, announce new episode of Technology and Friends, and show off photos I've taken. Despite being passive, I have reconnected with quite a few friends from my past. Many classmates from my high school days sent me friend requests and now I am using Facebook as a communication medium for our upcoming 30-year reunion. Facebook also provides a good way to get a message out to a lot of people in a hurry. Last year, my sister passed away and I was able to widely communicate her funeral arrangements by posting the details on Facebook. A number of people came to pay their respects after reading my Facebook message.

Flickr provides a social media mechanism: You can connect with other users, comment on photos and share ideas; but I don't use its built-in features. Instead I post photos on Flickr and link to them from Twitter or Facebook. Taking photos at a conference or other event and sharing them online is a great way to stay connected with the community. Recently, I have begun to cross-post my photos on SmugMug because this makes it easier for others to buy prints of my photos.

The sites you choose to connect with others online are not nearly as important as the messages are delivering and the connections you are making.

Thursday, 01 April 2010 14:48:21 (GMT Daylight Time, UTC+01:00)
# Monday, 29 March 2010

Episode 79

In this interview, Brian Genisio describes the Prism documentation and library and explains how he uses it to build applications.

Monday, 29 March 2010 12:00:16 (GMT Daylight Time, UTC+01:00)
# Saturday, 27 March 2010

I have removed the word "easy" from my business vocabulary. I've come to resent the overuse of this word.

What I do is not easy: If it were easy, anyone could do it.

Customers sometimes refer to a task as "easy" in order to drive down the price; Managers sometimes refer to part of your job as "easy" in order to lower expectations of high performance reviews (a dangerous strategy).

This mindset is generally an offshoot of the belief that the time spent coding is equivalent to the time spent typing. It isn't.  Understanding requirements, planning, designing, clarifying, testing, configuring, troubleshooting, communicating, error handling, logging, deploying, and validating assumptions go into nearly every software task I complete.

I cannot count the number of times I was told "The code is already written. You only need to copy it." In nearly every case, this was a gross misrepresentation of the complexity of the task assigned.

A task can be measured on a scale from Complex to Straightforward. Every task has unknowns that add risk and can make it more difficult than our original estimates.

Developers sometimes fall into this trap, telling customers that something is easy. Many of us overestimate our skill and minimize the risks inherent in every task. I caution against doing this because it creates unrealistic expectations and makes it nearly impossible to exceed those expectations.

When describing a task that isn't complex, I refer to it as "straightforward"; Or I give an estimate of how long I realistically think the task will take.

The only time the word "easy" might be justified in describing a task is after that task is 100% complete. In the past, all uncertainties are eliminated and risk reduces to 0.

Replace the word easy with "straightforward" when dealing with software developers (or any professionals) and your relationship with them will improve.

Saturday, 27 March 2010 14:15:17 (GMT Standard Time, UTC+00:00)
# Tuesday, 23 March 2010

Episode 78

In this interview, Jim Holmes discusses the importance of unit testing in writing high-quality, maintainable code.

Tuesday, 23 March 2010 04:25:14 (GMT Standard Time, UTC+00:00)
# Saturday, 20 March 2010

I have been recording and producing the online TV show Technology and Friends for over a year. After over 70 episodes, I have found things that work well for me. This series is a detailed account of how I put together each episode.

Part 1: Preparation

Part 2: The Interview

Part 3: Equipment

Part 4: Post-Production

Part 5: Sharing with the world

Saturday, 20 March 2010 18:57:11 (GMT Standard Time, UTC+00:00)
# Wednesday, 17 March 2010

In the last article, I explained how to edit a video and export it to a single MPG file. In this article, I will discuss how I share this video with the world.

Export

After I finish editing the video in Adobe Premiere Elements, I export it to a single MPG file. This is done by selecting the "Share" tab in the top right section of the editor. On the Share tab, I use the following settings: Personal Computer |MPG | NTSC DVD Standard. I enter a file name and select a directory and click the [Save] button to create a single MPG file containing my complete show.

Once I have a single MPG file, I can easily share it with others.

Upload

I upload the exported WMA file to a video-sharing site. I use Viddler because it is free and provides reasonably high-quality playback.

Viddler provides the ability to upload a file directly from their web site. I add metadata, such as a name and a description to each video.

Share

I link these videos from both DavidGiard.com and TechnologyAndFriends.com.

Viddler provides a button ("Embed This") that generates the HTML necessary to embed a video into a web page. I copy this HTML and paste it into a post on my two sites. Above the embedded video, I add some text to describe the video and any relevant links, such as the guest’s blog. I release both posts on the same day.

After releasing a new episode, I promote it via Twitter. I also send an e-mail to my guest, telling him or her that the interview is now available. Often my guest will link to the show from a blog or tweet, driving more traffic. If we are discussing someone else in the video, I often will e-mail that person or organization. After interviewing Jamie Wright about 37 Signals last year, I e-mailed 37 Signals to tell them about it. They linked to the video, which drove over 10,000 viewers to watch it.

My goal is to release at least one video every week, so I usually have a backlog of videos recorded, produced and ready to release.

Final Thoughts

On average, it takes me approximately 2 hours to produce a 20-30 minute show. This is in addition to the hour or so it takes to set up, prepare and record a show. So far, I’ve done this almost 80 times.

Wednesday, 17 March 2010 10:42:47 (GMT Standard Time, UTC+00:00)