Thursday, September 28, 2006

How to share HP deskjet 3650 printer with a Dell laptop

We now have a Dell laptop computer in addition to the HP Pavilion we already had. My wife will be using the laptop. She wanted to be able to print from the laptop to the hp deskjet 3650 using the wireless router.

The laptop is connected to the Internet through a D-Link wireless router which works great. The D-Link included Network Magic which set up the home network. It also set up the printer as a shared device.

So it would seem straightforward to add the HP printer to the Dell and get printing remotely. Well it almost worked. The wizard came up and was able to find the shared printer off the HP PC. However after the dialog about downloading drivers off the HP, there was an error message that it didn't have the right driver version.

Uh Oh. I brought up the printer properties. It had an additional drivers section. That looked promising. But when I clicked to add new drivers it prompted me for a drive letter. There's no CD as all the software on the HP was pre-installed.

I thought to get the drivers from HP. So from hp.com I was able to easily click through a couple of screens to find the download for deskjet 3650 drivers. First I thought to put it on the HP. Then I decided to leave the HP unchanged as it has always worked fine so I didn't want to risk changing it. So I downloaded the drivers to the Dell instead.

When I installed them on the Dell the dialogs came up and then one said to plug in the printer. I just clicked Cancel, hoping it would work. But clicking Cancel aborts the driver install. So I ran the wizard again. This time when it said to plug the printer into the USB port I moved the laptop next to the PC. Then I unplugged the printer from the PC USB port and into the Dell USB port. Then happily the driver install completed and I was able to print a test page from the Dell onto the HP printer.

The last step was to plug the printer back into the PC USB port. Then I went back to the add printer wizard on the Dell. It found the shared printer as usual. This time it was able to add it successfully as it now had all the drivers from my earlier trickery. Then I set the shared printer as the default and deleted the physical printer definition that the driver installed. And that was that.

Thursday, September 21, 2006

Reference update

I didn't hear back anything from my former colleague's first interview. However I did hear from recruiters twice in the past week doing reference checks on him.

The first one was from a large well known tech firm. The second was from a startup company.

The woman from the large firm seemed to be looking for an overall feel for what my colleague was like. She asked me how long I'd known him; how long we worked together on projects; what specific technologies did he work with; what was his biggest strength; what was his biggest weakness; did he get along well with others. We talked for around 15 minutes.

The end of the discussion was interesting. The recruiter started asking me about my skill set. I told here we're a Java shop and I'd been working on basically the same stuff as my former co-worker. She said they are interested in J2EE and Oracle and asked me if I would interested in applying to her company. I told her I'm not presently looking. She suggested she'd e-mail me and I could reply with a resume to get on each others rader screens in case things change in the future. I said sure - Why not? Strangely she hasn't followed up on that e-mail. Oh well she must have forgot after she hung up.


The second company wanted to talk to me during the daytime. I had said when I agreed to give a reference that a phone chat was available in the evening hours. The fellow e-mailed me back and said he'd try to call me that evening.

I haven't heard from him since though. He must have had to go out of town or had some unimaginably high priority thing. After all, in a small startup with a very small programming team, what's more important than getting in great developers. A bad hire could cause the company to fail, and a great hire could be a difference maker. So like Google you'd expect he'd make the effort to do the follow up to get as much data as he could on this potential hire to be sure he was getting someone very good. What's more important to the success of a software startup than hiring outstanding programmers? Not much.

He feels he might get offers from both companies. He may be favoring the startup because it is closer to his house. I reminded him in the chat that the hours can get long at startups, but he's done the startup thing at least twice now so he knows what to expect.

Wednesday, September 20, 2006

Test team

We're a small team, around a dozen developers and a handful of testers. Two or three times a year the developers have to temporarily join the test team to help complete a test cycle for a product release. Myself and around three other programmers have been with the test team the last week or so. Hopefully we'll be finished up by the end of this week.

Testing is an interesting experience. I don't mind doing it once in a while. I always test my own code of course, but testing other people's work is interesting. You get to try to think like a customer.

With testing, my take on it is that the name of the game is automation. I think our test team should work on ways to increase use of automated testing. There's some, but not as much as there could be. I was testing three APIs. One internal API is my own API; and two other APIs developed by others. For my own API, after I tested it out OK, there was a gap between candidate releases. The test team lead said OK to my request to use the time to create an automated test suite for the my own API.

It took me around two days to assemble the individual loose tests for each API function into a one pass driver that calls all of them. I suspect I've already saved in the subsequent baselines close to the amount of time I spent creating the automated test driver.


For the other APIs, we have a GUI driver that will set up and call each API function with data the GUI user enters interactively. This is OK for a programmer to test individual APIs as they are added, modified or debugged. However it doesn't scale well and is labour intensive and isn't well suited to rigorous regression testing.

So after this cycle I'm going to push to get some time to create a driver for the other two APIs as well. That may save me truckloads of weekend time in the future.