sacha chua living an awesome life

Photo (c) 2008 JakesDad – Creative Commons Attribution Licence 2.0

I’m beginning to be a big fan of virtual images for development work, because they save me from having to have the setup above. I already bring two laptops – don’t need more!

By downloading and customizing an image of a system that is already configured for typical development tasks, I can save myself a lot of administrative time – and keep development work more cleanly separated from the other files on my computer.

Both VMWare and Virtualbox have many virtual appliances available, and you can start using them with the appropriate player. Both VMWare and Virtualbox are free for personal, non-commercial use. I’ve taken advantage of a VMWare licensing program at work, installing VMWare Workstation so that I could take snapshots of my development environment if necessary.

I picked the Turnkey Drupal 6 distribution, a 175MB download. Installing Apache, MySQL, and PHP on Ubuntu is easy, but it was good to be able to take advantage of Turnkey’s support for https and other niceties. I may still have to install everything onto the production server manually, but at least we can do the setup easily. I changed the passwords from the defaults, of course.

I didn’t think it would be this easy. I had avoided virtualization for a while because it had felt slow and clunky the last time I tried it years ago. With 3GB of memory, this tablet PC can run both Windows 7 and the development server images just fine. Running Linux inside Microsoft Windows (instead of the other way around) might have helped, too. Setting up networking was a breeze, too. I chose bridged networking, which made the virtual machine seem like a new computer on the network.

The only quibble I’d like to fix is definitely a nerdy one – I’m back to QWERTY in the virtual machine, because it ignores the Dvorak keyboard mapping I’ve chosen on the host operating system. It’s an easy matter to change this on Linux (“loadkeys dvorak” at the command-line), but an even easier (and more responsive) way to work with this is to use ssh to connect to the virtual image.

Full speed ahead!

SCHEDULED: 2010-07-21 Wed 08:00

To paraphrase Edison: I wasn’t failing, I was just figuring out a thousand ways that didn’t work. =)

—-

Summary of troubleshooting lessons learned for Lotus Notes 8.5.2, Expeditor 6.2, and Eclipse 3.4:

org.eclipse.equinox.common problems when installing Expeditor Make sure you have the version of Eclipse that matches your Expeditor’s system requirements (not a newer version, not an older version). For Expeditor 6.2, you’ll need Eclipse 3.4.

Problem occurred reading your Target. Ensure that your Target Platform’s Location is configured correctly. Set it to c:\notes\framework\rcp\eclipse, or wherever your rcp\eclipse directory is. If you still get the error, tinker around a little or wait a while. I don’t remember what I did to solve this.

Bundle com.ibm.jxesupport not found. Ignore that. You’re supposed to be able to correct that issue by right-clicking on the project, selecting Properties > Client Services, and clicking OK, but no luck. It doesn’t stop the system from moving forward, though.

com.ibm.rcp.platform.personality error or java.lang.SecurityException: Unable to locate a login configuration: *Enable all the features and be patient.

—-

I’ve been working on getting a Lotus Notes + Eclipse development environment so that I can make a Lotus Notes plugin for my community tools. There’s a lot of interest in the community metrics tool, for starters.

The challenge with setting up development environments is getting all the versions to line up with the tutorials on the Net. I came across a page that described how to set up Lotus Notes 8.5.1 with the Eclipse Plugin Development Environment (PDE). I was on a newer version of Eclipse, so I needed to figure out a couple of the steps, and I eventually ran into a security exception with login configurations.

Along the way, I came across Lotus Expeditor and decided I wanted to try that. I saw an old article that said Expeditor only works with Eclipse 3.2.2 and not the newer versions, so I installed that, but it had problems trying to find com.ibm.equinox.common. Then I found out that I had a newer version of Expeditor which requires Eclipse 4.0. When I installed that, Expeditor installed fine.

Lesson learned: Look up the version of the toolkit you’re using. Look up the specific software requirements for that version. Match it instead of using newer versions.

Hmm. New error: Problem occurred reading your Target. Ensure that your Target Platform’s Location is configured correctly. I have it set to c:\notes\framework\rcp\eclipse. It won’t accept c:\notes\framework\eclipse . Hmm. It works now. I don’t know what I did, though.

I’m running into the com.ibm.rcp.platform.personality error again. Let’s try reloading those. They show up in the plugin list for the run configuration, though. Ah. Selecting another plugin that depends on that plugin might’ve done the trick.

There’s a note about Bundle com.ibm.jxesupport not found. com.ibm.jxesupport was removed in Lotus Expeditor 6.2.0. You’re supposed to be able to correct that issue by right-clicking on the project, selecting Properties > Client Services, and clicking OK, but no luck. It doesn’t stop the system from moving forward, though.

… and we’re back at the java.lang.SecurityException: Unable to locate a login configuration which I encountered this morning.

Okay. What do I know about this error?

• Maybe I’ve configured the wrong JVM.
• Maybe the JVM can’t find lib/security/java.security .
• Maybe there isn’t one by default in Notes, so I have to create it.
• Maybe the classes aren’t in the classpath.

Aha! Found someone with the same error message, but in a different language. The person reported that checking all the boxes in the plugin tab helped. Let’s try running it with all the features enabled (oh my). Lots of warnings, but still going… And there’s the Lotus Notes login dialog, and the sample QuickNote plugin. I think we have it!

Useful links:

• Getting started with the Lotus Expeditor Toolkit 6.2.1
• Lotus Expeditor wiki
• Configure Eclipse 3.5 for Notes 8.5.2

One of my coworkers asked me for advice on shifting from a testing role to development. Inside IBM, cross-role experience can often be picked up within a project, on a BizTech opportunity, or by assignment to another role (if the project manager really, really believes in you). Here are some tips if you’re considering the shift yourself:

Although you can build your skill in steady increments, building expertise can be a long and frustrating process. You’ll make a lot of progress in the beginning, but you’ll probably hit a plateau. Don’t be frustrated.

Unless your project manager is okay with taking a risk on you, you probably won’t be able to immediately spend time developing those skills on the job. Here’s how you can free up some time to work on improving your skills:

1. Look for ways you can work more efficiently and effectively, so that you can save time.
2. Document those processes so that you understand them better and so that other people can take over your role when you leave.
3. Automate as much as you can, saving more time and enabling more people to do your work.

You want to be replaceable. You can’t spend time learning something else or move on to another project if that would leave a big gap in your previous team.

How can you learn more about development when you’re testing?

• You can improve your processes, learning more about available tools along the way.
• You can learn how to script while automating tasks.
• You can learn an in-demand skill and get pulled into projects that way.
• You can focus on providing additional value while testing. For example, if your project is okay with it, do whitebox testing in addition to blackbox testing. By reading the source code, you might be able to think of test cases that should be covered. You can try helping with problem identification, using tests to narrow down where the bug might be. Once you get good at that, you can try documenting your problem-identification process and commonly-encountered bugs. When you’ve got a good feel for the structure of the program and how things are generally fixed, you might even tentatively propose fixes.

What other advice would you give to people who want to move from testing to development?

I often talk about leverage and scale: creating as much value as I can for as many people as I can. Now that I’ve been with IBM for a while, I see the personal benefits of that practice in the assignments I get and the help I offer my coworkers. In a way, I build scaffolds to help people to do more.

Photo (c) 2008 Kevin Dooley (Creative Commons Attribution License)

One of the ways I’ve contributed to my team is by integrating a regression-testing framework into our Drupal project.On the team call last Tuesday, the project manager asked if everyone had seen the e-mail he had sent about testing, and if anyone had any comments. I reported that I had built the features that were assigned to me, but I was waiting for someone else to confirm testing. He asked if we could look into automated regression tests, too. I laughed and said we’d had them for months. I had even integrated them into the build and deployment script I’d written, but the other developers said that running the whole regression suite of project-related tests took too much time, so I turned that off. Still, I regularly ran full regression tests on my system, using customized versions of Drush and Simpletest.

I enjoy doing things like that: completing my tasks ahead of schedule and using the rest of the time to think of ways to optimize how people work. =) Kaizen – relentless improvement!

One day I’ll post a generalized version of the Makefile that makes my Drupal life so much easier, but in the meantime, here’s the general structure I use:

1. Lots of configuration settings:

   DB

   Database name for Drupal site

   DB_USER

   Database user for Drupal site

   DB_PASSWORD

   Database user password for Drupal site

   ROOT_DB_PASSWORD

   Root MySQL password, used to drop and recreate the database, and grant permissions

   SVN

   Subversion branch for source code control

   SVN_USER

   Subversion user name

   SVN_PASSWORD

   Subversion password

   SITE_DOMAIN

   Particularly useful when working with sites that use Domain Access, but handy even with other sites because of BASE_PATH

   SRC_DIR

   Location of source code, needed for Drush

   DRUSH

   Drush command line, just in case I want to fiddle with it

   DB_PREFIX

   Database prefix, for make clearcache

   BASE_PATH

   Base URL

   DRUSH_GROUPRE

   Regular expression to match against simpletests using my modified Drush_simpletest that lets me run all groups of tests matching a regular expression

2. An include statement

   -include *.mk

   This is really useful. This lets you override the variables using a file like local.mk, dropped into your current directory and kept out of your source code control system. I use this to make my Makefile just Do The Right Thing when it’s in different directories or on different servers. Do not forget to tweak your included file (or make sure there is one) if you need different configuration settings.

3. Lots of targets:

   backup

   Uses mysqldump to back up the database.

   restore

   Drops the database and restores it from the backup.

   clean

   Drops the database

   install

   Calls the site’s install.php with the appropriate profile.

   cron

   Calls the site’s cron.php

   mysql

   Starts a MySQL connection to the Drupal database. I don’t have to remember what the database name is or what the connection details are, hooray!

   clearcache

   Clears the {cache}, {cache_menu}, {cache_views}, {cache_content}, {cache_filter}, and {cache_page} tables

   revert

   Hits the panic button and reverts my tree. (because svn revert . -R is too long)

   tags

   Regenerate the TAGS file that lets me find function definitions really quickly

   test

   Use Drush to run all of my simpletest functional tests for this project

Sometimes I’ll have an “rsync” target to deploy files to a server and a “doc” target to regenerate my low-level documentation using doxygen, too.

This Makefile is seriously cool and seriously time-saving because it means that no matter which project, branch, directory, or server I’m working on, I have a consistent set of commands for the most common things I need to do. The less time I spend thinking about fiddly administrative tasks, the more time I can enjoy in the coding zone.

This is also one of the reasons why Drupal development is _so_ much easier on Linux or other Unix-ish systems, or even Microsoft Windows with the Cygwin environment. If you see yourself doing a fair bit of Drupal work, it’s well worth investing the time in setting up a virtual machine or a second partition, learning a new operating system, and re-setting-up your development environment.

make awesome. =)

What’s in your Makefile, or what other tricks do you use to increase your developer happiness?

I joined my current Drupal project two weeks ago after documenting and wrapping up my other Drupal-based project (which I’m happy to report is chugging along quite nicely without me). Since then I’d been quickly going through my task list. I’ve also been poaching other people’s tasks, such as the configurable group home pages and the deployment scripts. As I told my cat, I’m having fun rocking Drupal. ;)

Today, one of my project team members demonstrated the site to members of the other consulting team. He wasn’t sure if the reception would be neutral or even hostile. He walked through the various features we’d built in two weeks of work, a short period of time that included the numerous issues other people encountered and my ramp-up time as a new member of the team.

One consultant from the other team couldn’t help but say, “Wow.” And the rest of the team really liked it, too!

So I guess I can count that as my first “melting a tough client” story. =)

What worked well?

• Even though I was new to the team, my team members gave me plenty of latitude in building tools and reorganizing things. There were a couple of changes that we needed to discuss, but usually, the practices I suggested made things a bit easier and the changes weren’t difficult to get used to.
• I set up my local development environment (my uber-tricked-out Emacs) to make it easy for me to quickly shift between files in different branches of code, look up definitions of functions, and re-build the site.
• As a lazy programmer, it’s in my best interest to automate as much as I can. I kept tweaking the build process until I could get it to work without manual intervention, and I plugged it into the web-based deployment script I’d written for my previous project.
• I reused as much as I could, relying on a combination of grep, var_dump, printf, tags, and asking coworkers what’s responsible for what.
• Also, starting work at 5:15 AM turns out to be pretty good for me. I get almost a full day of work into the morning, I can spend a little time in the afternoon attending to things that require less creative energy, and I can even take a short catnap in the afternoon sun (complete with purring cat!).

I’m looking forward to tidying this site up, and I’m sure I’ll have lots of fun getting the next site off the ground, too!

If you accidentally delete a file and then commit the change, you can retrieve the file along with the rest of the history by using svn copy to copy it into your working directory. svn copy -r revision-number your-full-repository-path-to-the-file file

UPDATE: pgier suggested svn copy http://svn/url/to/file@revision-number file

Common Use-Cases for Merging