Wednesday, December 9, 2009

Growing Your Craft: CodeRetreat

If you've never heard of CodeRetreat, you're not alone. I first learned of it a few months ago when Patrick Welsh organized one at our workplace.

CodeRetreat is the brainchild of Patrick and Corey Haines. Patrick is an Agile Developer/Coach, follower of strange dietary practices, and all-around great guy. Corey is the hippie* guru of software development in the Midwest, and a top-tier developer.

* I have no idea what Corey's political and religious beliefs are, if any. He just has long hair.

The event was hosted at LeanDog in Cleveland, in their office on a boat. I can't think of a cooler venue or a better bunch of people to learn with and from.

After meeting the team (and the dogs, who are anything but lean) we went out for drinks and discussion. Our host was Jeff "Cheezy" Morgan, who runs the company with a couple of partners who weren't present for the event, but are probably pretty cool as well. Everyone had something interesting to say, especially Paul Nelson (a Windows-hating Mac fanboy, but otherwise excellent pairing and drinking partner).

We used Conway's Game of Life as the focus out our programming work, but made very little progress on solving the game as a problem. Instead, the focus was on learning new (and better) ways to create an emergent design through Test Driven Development. Patrick did a great job of talking us all down from the wall when it came time to delete our code and start over again - something we did every 45 minutes or so.

I had several great conversations while pairing with different people. Some of the things that stuck with me the most came from Corey. Here is a summary of what I wrote down at the time:

The wisdom of Corey:

  • You don't change code under red - you add (& duplicate if necessary), then collapse & clean under green.
  • You don't write Ruby code. You write a DSL to solve the business problems you have, then implement it using Ruby. If your business logic looks like Ruby, you're doing it wrong. Look at Rspec - it's a DSL, not "Ruby Code".
  • "Writers write, always".
    • Not sure if what you want to write will work? Write it.
    • Doesn't work? Delete it.
    • Kinda works? Keep what works, delete the rest.

I'll post more on this as time goes by...

Tuesday, November 24, 2009

Slow and Steady: Undervolting your CPU

The following only applies to Windows machines. There may be something similar for Mac and Linux, but I didn't look into it.

Why: It makes the CPU last longer, extends battery life, and makes the laptop quieter (the fan runs a lot less).

Risks: None - just the time it takes to do it.

Why it works: A standard voltage range is applied to all chips of a given type that a manufacturer makes. Each chip may have a different tolerance where it is stable, but by setting the voltage high, all of the chips in a given run will remain stable. Your chip may only be able to handle the max voltage, or it may be like mine - the min voltage for all clock speeds.

I followed this guide's advice for a while (drop the voltage by 0.025 & test for 45 minutes), then read down a ways the following comment:

I just keep the CPU stress test running and drop the voltage at the maximum multiplier at about 1 step every 15 seconds starting at 1.10V (for Intel Core / Core Duo). This very quickly finds the voltage which is definitely unstable and BSODs (keep a recod of the voltage as you drop it). I then put the voltage back up two steps and run an overnight stress test.

I ended up getting down to the minimum voltage in just a few minutes & ran a test for 45 minutes. It was stable, so I left it there. I'll run an overnight stress test this weekend.

The basics are to run three utilities together:
1) CPU Monitor to tell me the temperature of the cores.
2) A utility to make the CPU max out.
3) A utility to change the CPU voltage for each clock speed.

Keep dropping the voltage until you see the Blue Screen of Death, then kick it up two notches. You change only the max clock speed voltage as you go, then change the others once you have a setting for that (my chip has 6 steps). Once you're happy with it, you set the utility to kick off at startup (it runs once & goes away). You can always boot to safe mode & get factory defaults this way - safer than doing it at the BIOS level.

(Thanks to Uwe Hermann for the photo of a Celeron CPU)

Thursday, November 19, 2009

Detroit Tech: The 1DevDay Event

The 1DevDay event was organized by the Detroit Java User's Group, and held at ePrize in Pleasant Ridge, MI. The event was more like an expanded version of the monthly JUG meetings than something completely new. Since the monthly meetings are both valuable and interesting, this is not a criticism.

Here is a pared-down blow-by-blow of the events that I attended & what I took away from them, straight from what I hammered into OneNote at the time:

9:00 AM - Venkat Subramaniam's Keynote:

  • "Best practices" is often a fallacy.
  • 75% of the features in most systems is used only occasionally. 45% is never used at all. A good argument for Agile?
  • Interesting - Venkat is also making the point that we should pay attention to how we contribute to revenue. (Same as "Passionate Programmer" & other books.) Not sure that I agree that this should be an area of focus - worth some thought to articulate.
  • Don't create a new EJB standard:
    • Innovate first
    • Find real multiple use next
    • Standardize and market last
    • Rails & Spring are two examples.
  • Groovy & Ruby are as strongly typed as Java, they're just not statically typed. You'll get a runtime exception.
  • Check out:
  • Bogged down a bit at the end - talked about Unit testing & a lame story about exercise.

I wasn't interested in either of the sessions that followed, so I played around with RSpec while sitting in the Terracotta room.

10:45 AM – 11:45 AM – Agile Teams (Chet Hendrickson)

  • Chet likes burn-up charts over burn-down charts. I see his point.
  • Chet does not like certifications - certainly not for Agile or Scrum.
  • "Metaphor" is an XP practice meaning, "the common language developers and business people speak- the metaphor for the system".
  • 7 big categories (7 pillars of agile):
    • Business Value
    • Confidence - we can prove that the code works / plans are accurate
    • Product - dev should understand the business & product at least somewhat
    • Collaboration
    • Supportive Culture
    • Technical Excellence
    • Self Improvement
  • Check out:
  • Ditto on the google group:
  • The Agile skills matrix, the 7 categories across the top, vertical axis contains:
    • Learner - I've heard of it
    • Journeyman - I can do it on my own & help others
    • Contributor - has changed our collective understanding of this topic

    Where are your skills in each category?

biz val



supt culture

tech ex

self imp






  • Developers should read a lot of good code. (Identifying what is "good" is a challenge, but a surmountable one.)
  • Pick up a copy of "Software for your head" by Jim McCarthy.
  • "Move to code as soon as possible."

12:45 PM – 2:45 PM - Ajax / DWR

  • The presenter of this one was a bit new at it and/or I was underprepared. It was difficult to follow along, though I did learn a few things about the capabilities of Dojo and DWR.

2:45 PM – 4:45 PM - OSGi (Dennis O'Flynn)

  • The Mainifest file is the key to this - it contains everything OSGi needs to determine how things fit together.
  • This session helped me form an opinion: It looks really cool, but I can't think of a problem that I would solve using OSGi. I will ignore it unless/until I actually need it.

4:45 PM– 6:45PM – TDD / Refactoring (Nayan Hajratwala)

  • This was without a doubt my favorite.
  • Characterization tests aren't all that tough - write one where parameters have an empty list, zero or null first, take a guess at the result, then change the test to match the result you actually got for the test & get a green one.
  • Nayan likes to run tests on all 3rd party components that you use. Note that these only apply to the methods/components that you're using - not the entire library. Not sure if I agree with this or not. I haven't been bitten by this problem yet, and I don't like to solve problems I don't have...
  • AssertThat sounds very useful. Ex: assertThat(<expected or actual>, is(0));
  • Hamcrest (an anagram for "matcher", I think) has a bunch of different matchers I can use in assertThat(). They're in org.hamcrest.CoreMatchers.

Tuesday, November 3, 2009

First Impressions of Windows 7

My first impression of the OS is overwhelmingly positive. I have been using it for a full day (just installed it last night), and I haven't seen a glitch or a slowdown yet. After using Vista for a couple of years, it's a welcome change.

I used the machine all day for software development at work. This was something of a pain, since I did a clean install and had to add a lot of my tools back in. The upshot to this is that I installed a pile of software and found that it all worked without a lot of tweaking required.

A few of the things that stood out as positives:
  • The redesigned taskbar. I like the fact that it consists of both running and "favorite" applications. The window management it drives simply rocks (see the link for a more detailed review & comparison to the Mac Dock).
  • Everything has been cleaned up in the interface. From the taskbar to the start button to control panel and all of the little utilities I have tried, everything is easy to grok and use.
  • The Aero UI components are reasonably fast. A very refreshing change from Vista.
  • The themes are visually appealing, and easy to change. The one you see in the screen shot above was downloaded by clicking "get more themes", but the built-in ones are really nice too.
  • Sleep means sleep. The machine didn't wake up in the middle of the night (and kill the battery) for no apparent reason. This is still something to watch, but since I haven't heard the fan running nonstop yet, I suspect that whatever the problem was is gone now. (Yes, I did look for processes running when they shouldn't. No, I never found one.)

The negatives are pretty minor, but here they are:

  • Some browser plugins (like Flash!) simply don't work in the native browser. This is a function of my installing the 64-bit version of Windows 7 - not all of the plugin vendors offer a 64-bit version of their software yet. I got around it by installing Flash inside of the 32-bit Google Chrome browser, but this will probably be annoying in the future.
  • Firefox doesn't have a 64-bit version. I'm using a one-off called "Minefield" right now. It appears to be misnamed, though - works just fine, and noticably faster than the 32-bit version. So far, all of my plugins (except Flash) work just fine.

Although there are no major negatives, so far. There are a few things I'm going to watch for, based on my experiences with Vista:

  • Search service and indexing performance: so far it hasn't been a noticable drag on performance. It sucked in Vista, even after installing Windows Search 4.
  • "Security Essentials". I decided to uninstall the copy of AVG I initially installed and try out Microsoft's free anti-virus and anti-spyware software. The word is, it isn't a drag on system resources and integrates nicely into the OS.

My overall impression is that this comes close to what OS X has been doing for the past few years. I am not a heavy user of Macs, but much of what attracts me to the OS (simplicity, ease-of-use, depth of functionality when you need it) seems to me to be present in Windows 7.

I had been thinking that "come hell or high water, I'm going to buy a MacBook Pro some time in the next year." Now I'm not so sure. A high-end PC laptop with this OS may give me everything I expect from a Mac. Well, I've got some time to compare the two (another member of the household has a Mac) and figure out if my first impression holds up.

Tuesday, October 27, 2009

The Fog of Development: Recreate Dev Workstations Often?

We're looking at using Fog to rebuild our development workstations regularly. It's a clone server that can rebuild a complete machine image across the network. I saw it in action yesterday and I was impressed - it's relatively easy to use and really fast.

So why would a developer care about sticking a new image on his workstation? When I find myself rebuilding one every week or two! It's a major time-sink to get everything working right - local database, application server, portal server, IDE, environment variables & other settings files, etc, etc, etc. I probably burn between 1-3 days each month on the mundane task of getting a base configuration down, just so I (or another team member I'm helping out) can code again.

Opinions differ about how often this should be done, but I have no doubt that it has to be done regularly. We're an agile team, so we routinely install new tools for evaluation or to spike something. We constantly tweak machine configuration to test external dependencies. I can't speak for everyone on the team, but try as I might, I can't remember every little thing that I do over the course of a week to the configuration of the machine I'm working on.

One of my teammates feels so strongly about it, he'd like to see the machines automatically rebuilt every night. I'm not so sure - I'd hate for a pair to lose a day's worth of work because each thought the other person had committed the day's changes. Of course, that would help identify people who are only committing once per day or less often...

(thanks to John Walker for the photo)

Thursday, October 22, 2009

Agile Purity: How Agile Is Agile Enough?

A Tale of Two Projects
I have been fortunate enough to work on two "green field" projects in a row. Both are/were "agile", but the way they're being managed is quite different.

The first project is/was characterized by:
  • The business folks knew at the outset what market they wanted to engage, but not exactly what they wanted the application to do. The direction was "figure it out as you go".
  • Virtually no up-front documentation.
  • Frequent changes to existing features.
  • Considerable 1x1 time between the product owners and developers.
  • We had no BA and one QA specialist was assigned shortly before production release.
  • The product, content and software development people all sat together in one big room.
  • The system is currently in production maintenance mode, with a possible version 2.0 in the future.
The second project is characterized by:
  • We are in "Sprint Zero" - doing technology and design spikes now.
  • We have detailed specifications of many required features.
  • We have several wireframes, scenarios and related documentation available up-front.
  • We have a BA assigned to the team and two QA specialists.
  • The business team is not currently sitting with the development team (though we expect / hope to change that once we start Sprint 1).
Better / Best?
The big question is, "which is better?" I think that depends entirely on which developer you ask. There are certainly advantages to having documentation and someone with a formal BA role. You don't need to have difficult conversations with the product people - that's the BA's job. One of the main disadvantages is that "you don't need to have difficult conversations with the product people" - these are the conversations that drive a better understanding of what the feature/system should do. (Determining if it does it right is another conversation entirely.)

Project 1 did get a bit wearing when we would add a feature, then remove it, then add it back in. It was the most fun I have had on a software project, though, and our velocity was enormous.

We'll have to see how things play out on Project 2. My expectation is that the documentation and specialization of roles will make some things go more smoothly. My fear is that we will find out quite late in the game that some core components of the system aren't quite what the business & customers need, and will be expensive to change.

Expect a detailed side-by-side case study in a few months, and more blog posts on related topics in the interim.

Monday, October 12, 2009

I read "Shannon Paul's Very Official Blog" this afternoon & found an interesting statement about the interaction between developers and other business folks.

What caught my attention was: "developers and engineers see it as their role to identify products or solutions — it’s your job [as a social media / marketing / product owner] to define the problem or list requirements".

I think she's saying the developers she works with see it as their job to create the product/solution based on a problem statement. I don't think this is universally true of software types - many (most) that I have worked with see it as their job to implement someone else's vision of a product. In other words, we build the software, but we don't identify the market need or product as a rule.

Many of the more entrepreneurial types do indeed handle the whole ball of wax, from ideation to development to marketing. Most of my fellow coder-nauts see themselves as "software guys" rather than entrepreneurs, though.

Perhaps a useful communication idea would be to describe how not being responsible for the product concept and marketing phases of a project will make their jobs both easier and more valuable.
"Easier" is simple enough to understand, since it means less work.

"More valuable" is more nebulous, but consider: by not getting tied to a product concept too early, you're avoiding preconceptions about what a product should be or should look like. It may not be intuitive, but in my experience having fewer preconceptions makes for better and more versatile software.

What do you think?

Thursday, October 8, 2009

Rich UI: ZK instead of Flex?

One of the other teams here at the office spiked out the use of ZK and was kind enough to give me a demo. It looks like a wonderful tool for building a rich user interface, and I'm thinking that we'll probably use it on the new application we're building. (Sprint zero starts next week.)

I had begun advocating Flex as a way to build a "real" UI. It seems like a good fit for this organization, since SEO is much less of a concern for us than it would be for someone publishing open-web applications.

Flex does have some drawbacks, though. The main problem is that we don't have expertise in Flex's XML format or ActionScript in-house. There are a lot of very good developers here, but it still takes time to learn a new tool.

The advantage of ZK is that it provides a similar user experience, but lets us write all of our code directly in Java. The downside is that it generates JavaScript from the Java code, and I don't trust generated code very much. The developers on the other project tell me that they have never had to debug the generated JavaScript, but it has only been a few weeks.

Expect to hear more on this as the team takes a deep dive into what ZK can do.

Follow-up, January 2012:
I was out of the loop on using ZK for a long time.  Now that I'm the team stuck with the codebase built on it, I can render a stronger opinion: ZK sucks.  it is nearly impossible to test.

Sunday, April 12, 2009

Heads-Up and Eyes Open: Skills an Agile Developer Needs

The days of the "heads-down coder" who spent all of his time in a cubicle writing code from spec are numbered. Today, developers need a skill set that goes beyond cranking out code and includes such things as actually talking to other people. ("How can you tell someone is an extroverted programmer? He looks at your shoes when he talks to you!")

I like Agile software development. I think that it is the best way to produce working code that your customers actually want. The nuts-and-bolts of how to get this done are certainly up for debate, and there is no shortage of opinions on the subject. More to the point, I don't believe that there is such a thing as an "Agile" skillset, only skillsets that do (or do not) help you successfully create good software. This article is about the skills that I think are most essential to software professionals as we're nearing the end of the first decade of the 21st century.

Agile vs. Traditional Development - A Straw Man
Look around on the various blogs and forums, and you'll see a debate still raging around this subject. Which is better? Agile or traditional development? The answer is simple: development by skilled people who stay current, learn quickly and follow some methodology will be more successful than teams who don't have all of these elements.

Agile is just a methodology, and a fairly simple one at that. Like XP (which is itself considered agile), RUP and their distant ancestor SSADM, Agile is a set of steps to follow and a way to measure progress on a project. In my opinion, it is more useful than it's predecessors, but it certainly isn't a panacea. If you have a group of unproductive developers who don't agree that Agile is the way to go, forcing it on them will probably have a negative effect.

External influences being equal (management support, product management, customer commitment, etc.), a team that follows Agile practices and has skills to support these practices will be more productive than one that does not. These two concepts are not independent. If you have a productive team doing RUP or XP, you should stick with that because they have the skills (and the support) to make it work.

If your team is less productive than they would like to be and wants to move to Agile, what should they focus on?

Agile Skills
The Agile Manifesto describes the guiding principles in three sentences and four bullet points. The Agile Principles are also a very quick read. These statements don't describe a methodology, but instead served as the basis for developing what I and many others call "Agile Methodology", and which has been described in numerous books.

My focus here is on more detailed activities of creating software, and the real-world skills that software professionals need to grow. Time to learn new things is a very scarce and precious commodity, so I'm summarizing what I think is important. I do think that being able to program in more than one language is important, but I left that part out of this post because its pretty obvious and well-covered elsewhere.

This is my list of the most valuable skills a developer can have. Resources for learning more are in the links.

Gathering Requirements: Sharing and Playing Well With Others
Get up and talk to people! Make a connection. This sounds warm & fuzzy and very "Dr. Phil", but it is essential to getting good requirements. The people you must connect with include your customers (internal or otherwise) and your development team.

Building friendly and productive relationships pays off enormously because you no longer have to guess what the customer wants - you can ask. Likewise you don't need to guess if your solution is a good fit or not - air it out in front of other developers and see if it hold up.

If you're an introvert, force yourself to get up and start a conversation. Trust me, even if you don't see the value in terms of better requirements right away, it will make your work environment much better and raise your value in the eyes of your boss and your customers.

So what do you talk about?
  • User stories are easy to create and easy to review - spend a few minutes writing them on 3x5 cards, post-it notes or plain paper.
  • Take notes as you design & write code. Write down questions. Write down assumptions. Translate them into simple statements and questions, then go over them with users.
  • Draw pictures. Even if yours are only worth 200 words, you'll gain insights by showing them to people. Stuff the ones that weren't very useful into a drawer. Take the ones that brought the most insights and pin them on your cube walls or in a team room. Re-draw them if your rough draft is hard to decipher.
  • Do it often - if you dump 40 hours worth of your questions and assumptions on someone, they'll be overwhelmed. Talking for half an hour every day or two is better than four hours every other week.
  • Email doesn't count, and phone is only slightly better than email. Save these conversations for people who aren't in the same building with you.

Adapting to Change: Organizational Skills
A primary thrust of Agile is adapting to changes in requirements. You will always learn more about the problem you're trying to solve as you go, and this will give you insights into better ways of doing things from a user or customer's perspective.

A personal time/task management system that you can quickly adapt (changing to-do lists, sorting through important / unimportant emails, etc.) is key. Keeping track of the torrent of ideas that you and the people you talk to come up with and organizing them tells you where you were, what assumptions you made, and where you are heading. The simple acts of writing things down (or typing them) and prioritizing gives you a level of clarity that eliminates a lot of the stress of any job. Even if you never share your notes, creating and reviewing them will make you an expert on your project.

Some variations on different task-management and note-taking systems:
  • GTD ("Getting Things Done") is an overall framework for managing your time and tasks. I think that every developer should read the book...and then come up with his/her own system from scratch. GTD is, quite frankly, designed for idiots and CEOs - people who either can't remember anything without writing it down, or who have to juggle so many priorities that it is impossible to keep track of "the main thing" at any moment.
  • In 2008 I blogged about using OneNote to take daily notes and keep track of tasks, and this still works well for me.
  • For people who don't use OneNote (which works fine on a Mac using VM software), Evernote is a pretty good alternative.
  • Paper notes have a place in all of this. You can easily capture your scribbles from meetings on paper, then scan or photograph them and add them to your note software as images.

Creating Iterations: Planning and Estimation Skills
Iteration planning is core to Agile, and there are several concepts that all agile developers need to be comfortable with. At base, these include:
If you're not familiar with these (or just want an overview) I recommend Head First Software Development as an excellent introduction. Plenty of pictures, and you can skim your way through the book in an afternoon, or spend 1-2 days on a deeper read. (I really like the "big board" chart described in this book & have co-opted it for my own projects.) For an overview of the different agile methodologies (XP, Scrum, Unified and Evo), I liked Agile and Iterative Development (the link lets you read the critical sections online at Google Books).

There are too many books on specific methodologies to list them all out - search Amazon for Scrum, etc., and read the reviews.

Choosing Optimal Solutions: Study Skills
You can't choose what you don't know about. Being Agile means having a handle on what options are available in languages, frameworks, development and testing tools. Any developer - agile or not, must have good study skills. If you're not reading a technical book of some sort every week, you're falling behind.

This pdf by U of M's Paul Edwards is a good overview of how to read a non-fiction book, but I would add the following caveats:
  • Read what is interesting first. If you have an immediate problem (Ex: "How do I run a nightly job using the Spring scheduler?"), read about that first. You may stop there.
  • If you don't like it, read something else. If you don't like the author's writing style or the subject matter bores you, find a different book on the same subject. If at all possible, I try to preview an e-book first, then buy the one I liked best so I can write in it.
  • Buy a lot of books. This goes along with trying out different authors and topics to find whatever helps you learn best.
  • Read a variety of topics. Frameworks, languanges and methodologies are important to your craft, but it's also good to read some "meta" topics from time to time. I strongly recommend Andy Hunt's "Pragmatic Thinking and Learning" and Neal Ford's "The Productive Programmer" to improve your study skills.
I would really like to hear your thoughts on this subject. What skills do you think are most important to a developer? What books or sites have you found particularly useful?

(face-in-the-computer image by "dumbledad", acrobatic dog image by "thegiantvermin")

Wednesday, March 25, 2009

Confessions of a Lazy Programmer: Maven the Easy Way

I have been brushing up on a few different technologies lately, and all of the tutorials & books I have gone through rely on Maven for building a project skeleton. Since my focus hasn't been on Maven itself (instead it is Spring and Tapestry), I have been blindly following instructions from the command line. For very basic projects, this has worked fine.

Anything more complex, and I see things like this:
Since I wasn't trying to set up any database connectivity, this is thoroughly annoying. I was only trying to validate that I can build a skeleton project so I can move on to installing and configuring the Tapestry plug-ins for Eclipse.

Since I'm not interested in learning the guts of Maven yet, I did what any good (read: "lazy") programmer would do: I installed the Eclipse plugin for Maven and used Eclipse to create my project. Thanks to Borut BolĨina's great walkthrough, this only took a few minutes. (He has a complete series on creating apps with Tapestry on his blog - encountering this problem gave me another resource to speed my learning.)

This was a much simpler task, since I was able to choose the archetype (i.e., type of skeleton I want to create) from a list. That list is populated by other lazy programmers who built and maintain the Nexus Indexer. This component is used by Eclipse (and via a command-line tool I didn't try) to link the repositories together for me. The upshot is that I can create a skeleton in minutes instead of spending hours or days learning Maven well enough to do it "the right way."

I have used the word "lazy" a lot in this post. To me it simply means that I don't spend time working on things that aren't relevant to the task at hand. The helpful and generous people who built the tools and documentation mentioned above fit this definition of "lazy" as well. For the most part, they built tools and wrote walkthroughs because they needed to in order to advance their own projects. They refined their work and made it available to others to improve it further. They stay engaged with people who use it for the same reason most skilled people do - because helping others by being an authority on the subject is one of the biggest rewards for building expertise in the first place.

I still need to learn Maven reasonably well to use it as part of a continuous integration environment. I may find that there is a subtle beauty and creativity-enhancing magic to using it from the command-line. I just don't need to spend hours screwing around with it right now, while I'm working through the basics of Tapestry.

Really. It's on my to-do list. I'm sure I'll get to it...someday...

(Lazy Dog image by Hector Garcia)

Wednesday, March 18, 2009

User Groups: When Nerds of a Feather Flock Together

I left tonight's Detroit Java User Group meeting thinking again how amazingly useful the group is for programmers. No individual can be an expert in all new technologies. Listening to someone else summarize what they find good, bad or ugly about a particular framework or language really helps me decide:
  • What I want to dive into next, just because it's interesting.
  • If there is an easier way to handle a common implementation, testing or deployment problem.
  • What I might need to learn in order to stay current.

Today's talks were on a these open source tools (explanations are based on my understanding from the 15-minute talks - corrections & clarifications welcome):
  • FitNesse - a software testing tool framework. Unlike JUnit which focuses on very specific tests with hard-coded data, FitNesse is intended to handle soup-to-nuts acceptance testing. It uses a Wiki to both describe the tests and hold the test data.
  • DarkStar - A Java-based multiplayer game server. It handles the communication between clients in a multiplayer environment, rather than physics, rendering or authentication.
  • Grails - A web-application framework built using Spring (among other tools). It is intended as a development environment which uses the Groovy language as the "glue" to hold together Java business logic. You can write part of your application in Groovy, part in Java, and then deploy the whole thing as compiled Java bytecode, using a .war file. This last makes is particularly interesting, since deploying a .war gives you a wide selection of servers with no additional server-side configuration needed.
  • Selenium - A testing tool that runs tests through a browser. Instead of using a mock HTTP object to send tests to a server, Selenium is actually a "robot" that controls the browser of your choice, sends information through it, and checks the resulting page. It can use HTML tables or Java code (or C#, Python, and others) to control the 'bot. It does not solve the problem of cross-browser testing directly, but by running the same tests on different virtual machines, you can get around this.
So what did I take away from this? I really need to learn Groovy, review Spring, and install Grails to have the best of both worlds. Big fun!

Thanks to "LuChOeDu" for the "Geek 2.0" graphic.

Wednesday, March 11, 2009

Pandora: Music While You Code

If you're not already using Pandora, you really should check it out. It is a great way to listen to new music that still falls within your normal range of tastes. Just give it some songs or artists that you like as "seeds", and then give a thumbs up or down to songs as they play. You'll end up with a radio station that plays music you like all of the time. The most amazing part about it is that it's free. They have a few audio ads (I haven't heard one in a week or two) and the usual banner ads, which aren't at all intrusive if you keep the browser minimized.

My friend Dave recently posted about an Adobe Air client for Pandora radio, which I just downloaded today & is working fine. The only real advantage to it is that it minimizes to the system tray instead of to the taskbar in Windows. This is helpful if you use multiple virtual desktops (I use VirtualWin) and want to access it from any desktop.

My Pandora station is mostly Indie music. Check it out if you like that sort of thing...

Tuesday, February 17, 2009

Django on Google App Engine: How to Set Up Eclipse for Local Testing

The Django Helper Application

The Google App Engine supports Django, which is a great way to build a UI.  Getting it set up is a bit tricky if you're using a database, though, since Django has some different expectations about how you will interact with a DB.  Fortunately the good people at Google have provided a Django project to help with this.  Their instructions are on  this page.

This post doesn't tell you anything that you can't find elsewhere - I just pulled it from one of my OneNotes pages to share because it is a bit more concise, and it also has a couple of screen caps from Eclipse.


Local Django Configuration in Eclipse

To start your app:

  • Go to the directory where you want to create your app, and run " startproject mysite" where "mysite" is the name of your app.
  • Navigate to the directory where "" lives for your app.
  • Make sure that app-yaml has an app name in it (pretty much anything will work, I think).
  • Fire up the local Django app server with "python runserver".
  • To see your app on the local server, go to: http://localhost:8000/.
  • To see the local admin console, go to: http://localhost:8000/_ah/admin/.


To add a new view / URL in Django (for more details, see the example from the Django tutorial):

1) Add a new function to


 2) Add a regex and the function to





That pretty much does it.  I found that this worked well & gave me really good debugging capabilities (the local Django gives excellent information when debugging is turned on - which is by default).

Wednesday, January 21, 2009

How-to: Setting up Google App Engine for Simple Sites

I wanted to find a simple way to publish a custom website or two for low cost, and settled on Google App Engine as the best current solution. This post focuses on getting an Eclipse environment up and running to debug and publish your Python and other code to Google App Engine.

I initially planned to do the site in Flex, but changed my mind after looking at SEO problems with Flash applications. It does look like there are solutions for getting search engines to index Flash content, but I haven't put in the effort to really explore them yet. My sites are (for the moment) done in plain old HTML with CSS. The only twist is that the Python code strings together several fragments of HTML code to build each page. (I'll talk about that in a later post.)

The Basics
I won't repeat what Nick Berardi already said in his great how-to post. Please check that out for step-by-step instructions on getting your own domain, creating an app engine application, and uploading your content with one command. (You can do this without a domain, but since it's a whopping $10/year there is little reason not to).

Once you have followed these instructions & have an engine application connected to your domain, there are still a couple of steps you need to follow so you can debug the Python portion of the code.

The following is adapted from Google's tutorial here:
  1. Install Python 2.6 if you have not already done so. (There is a newer version, but this is what I used.)

  2. Install pydev eclipse extension for Eclipse through the Eclipse update manager (Help | Software Updates in Eclipse) using this url:

  3. Tell PyDev where to find the interpreter (create a pydev project and Eclipse will prompt you to do this). I just browsed to the default install location of "Program Files/Python26/python.exe".

  4. Install the google app engine SDK if you have not already done so.

  5. Create the "" and "app.yaml" files as described in Google's Tutorial.

  6. Test the dev server. I kicked off my mini program with this command-line:
    • "\Program Files\Google\google_appengine\"
    • This runs the dev app server and kicks off the app.yaml script in
      my PythonTestBed/src directory.

  7. Fire up a browser with http://localhost:8080. It should show "hello world".

Debugging GAE Python in Eclipse
You can run Python programs in two ways (I tried both & they worked):
  • By selecting "Python run" in Eclipse.
  • By going to the http://localhost:8080 page as above & refreshing it.

I like to view the Python output inside of Eclipse, so I needed to tell PyDev where the api libraries are under Window | Preferences:

The bottom five folders were added with the "New Folder" button. I probably don't need anything other than the appengine, webob and yaml folders for what I'm doing, but I added the others anyway.

I ran into a hitch in calling urlfetch (I needed to parse an RSS stream and feed it into my site as well-behaved HTML. I'll talk about this in a separate post). Because Google uses a proxy to do the actual fetch, it wouldn't run from my local machine until I imported some stubs:

…and then set the stubs up before calling urlfetch in my code…

This will get you up and running. Getting the Python, html, css and javascript pieces uploading and working together will be the subject of a future post.

Thursday, January 8, 2009

Stupid Firefox Tricks

I encountered what I think is a bug in the way Firefox handles Javascript. The fix to the problem was simply not to use any Javascript in the body of the page, and I'd be interested to see if anyone else has encountered this.

The Problem
I found what appears to be a thoroughly annoying bug on Firefox, and I'm wondering if anyone else has seen something similar. I suspect that it may have something to do with my configuration, otherwise I should have seen some other mention of it.

I was trying to embed a Feedburner blog summary in a new website, and this worked fine in IE. If you've never tried it, it involves sticking a chunk of Javascript in the middle of your page. Here is a sample (replace all instances of "[...]" with "<...>"):

[html][body] other html...
[script src=""]

The script tag returns:

document.write('[div class="feedburnerFeedBlock" id="IndependentInDetroit2842309"]');
document.write('[p class="feedTitle"]
[a href=""]Independent in Detroit[/a][/p]');
...(a dozen more lines of javascript-generated html)...

On the left is the IE screenshot. Notice that the site banner is at the top of the page, as expected. On the right is the Firefox screenshot, where you can see that the banner is not visible. It also says "Loading" which continues indefinitely or until you click the stop button.

Viewing the source shows something bizarre - the page contains only the expanded javascript. All of the other HTML (head, body, etc.) has been stripped off. It appears that Firefox interprets "script tag inside the body" to mean "redirect to a blank page containing only the javascript". Very odd.

The Solution
My fix was to do a urlfetch from Python (this site is hosted on the Google App Engine), then strip off the "document.write(' " and " ');" portions of each line, then stuff the HTML directly into the page. Here is a snippet of the (very simple) code. The second-last line is there because one of the steps (probably "theResult.content", which converts the result object to a String) escaped the single quotes in the string, so they came out looking like " \' ".

# Get the feedburner summary, strip out the javascript, then write it.
result =
def stripJavaScript(theResult):
outString = theResult.content.replace("document.write('", "")
outString = outString.replace("');", "")
outString = outString.replace("\\'", "'")
return outString

It worked well, but isn't a very satisfying solution. Has anyone else encountered this? Did I miss something obvious?

Windows 10 Driver Issue with Falcon / Z-77 Keyboard

Windows 10 has an issue with this mechanical keyboard (which works great, BTW).  It's a Chinese-made keyboard (aren't they all?), bu...