One of my colleagues had hand trouble and the company bought him a FrogPad keyboard. (http://frogpad.com) He said it didn't take too long to get used to it, and he was impressed with how fast he could still type. After his hands got better, he did switch back to a normal keyboard because it was faster. Another coworker tried Dragon Naturally Speaking for several months. It's good for writing letters, but not for writing computer code (because of all the punctuation, function/variable names, etc.).

You can easily build your own for less than $1000. You can usually build a respectable system for around $600 if you're reusing a few old components like your case, DVD drive, monitor, keyboard, mouse, and speakers. * Look at the performance benchmarks for each type of component and plot them against price to get the best price/performance tradeoff. * Factor shipping into the price of every component before comparing the price/performance ratios. Sometimes a slightly better, more expensive component will have free shipping, making the choice a no-brainer. * Don't spend more than $150 on the video card. You can usually get a really good deal if you buy 1 generation behind the curve or buy the second-best card of the current generation. * Don't spend more than $100 on the CPU. The "sweet spot" for price/performance (the point at which your performaince gains begin to shrink with every extra dollar spent) is usually right at the low end for CPUs, around $60-$75. * Don't spend more than $100 on the hard drive. $100 is the sweet spot, and sometimes you can get a good enough deal for $80 or so. * If you have an old copy of Windows that you can legally transfer to the new computer, use that instead of buying a new copy. It will save you at least $120. * If you're running 32-bit Windows, don't buy more than 4 GB of RAM. Windows won't be able to use more than 3 GB (3.5 GB, if you're lucky), anyway. * Buy a reputable-brand power supply, but don't worry about getting an oversized or extra-fancy one if your budget doesn't permit it. ActivePFC 80-Plus-Certified power supplies are now pretty affordable. (Usually $50 on sale is sufficient, and $80 is bordering on overkill.) I've had bad luck with off-brands failing or causing weird glitches and system instability. * Buy a motherboard that has solid capacitors instead of electrolytic capacitors, at least around the top part of the board (around the CPU area). Electrolytic capacitors have gotten a bad rap because a stolen, incomplete formula got into the supply stream. These caps degrade and leak over time, causing your motherboard to eventually fail. You can tell the difference easily by looking at pictures of the motherboard (solid caps are encased all around with silver-colored metal, with some colored areas on the top and down one side. Electrolytic capacitors are wrapped with a colored plastic wrapper and just have a circle of visible metal on the very top. * Heed the reviews, but beware of people who give low ratings just because they don't know how

I've been trying both Ubuntu 8.10 and Windows XP 64-bit as the host OS. I'm thinking about keeping both just in case one somehow hoses itself and I'm too pressed for time to reinstall/reimage the host. I think the only differentiating factor affecting performance is the quality of the driver for your graphics card on the host OS. Originally I was using the onboard Nvidia 8200 graphics to run my dual 19" displays. Performance under Linux was atrocious--I could see the screen repaint from top to bottom just when switching between application windows in the guest OS. Later, when I tried Windows as my host OS, the maximum resolution it would allow in multi-monitor mode was 1024x768x32bpp or 1280x1024x16bpp. My theory is that they artificially disabled 1280x1024x32bpp because they knew the performance sucked. Eventually I concluded that the driver for the onboard Nvidia 8200 graphics chip sucks in both Linux and Windows, and installed the X1550 from my old workstation. I remember running dual monitors at 1280x1024x32 six years ago and having no performance problems whatsoever on a Matrox G550, so you could say I'm pretty annoyed that the onboard Nvidia 8200 graphics can't properly handle dual displays. I haven't tried the Linux host again since installing the discrete graphics card because I ran out of "fun" time, but I would bet that the graphics performance is now up to par. Aside from the slow screen redraws (Linux host) and limited resolution (Windows host) under the old grpahics card, the performance was not noticeably different under a Linux vs. Windows host OS. This isn't the first time I've been burned by a crappy onboard graphics chipset, but I had hope after reading some pretty decent reviews of this chipset and the AMD 780G (I guess I was wrong). I remember years ago running one of our in-house code analysis tools and getting more than a 10x speedup when I happened to minimize a CMD console window which was displaying the logging information real-time. The integrated Intel graphics killed performance because it couldn't keep up with the console output, but when the output didn't have to be displayed by the graphics chip, the analysis sped right along. Rob

I just switched to VMware Server on a 64-bit host with 32-bit and 64-bit Windows XP guests 2 weeks ago. My main reason for switching was that I seem to have 1 or 2 hardware failures a year, and it always takes me a long time to rebuild my workstation just how I like it. With my primary development workstation running in a VM, I can just do a bare OS install on a system, throw VMware on, and I'm ready to go again. I also recently started working on building 64-bit versions of our software, so I need a 64-bit system to test them on. Performance under a VM on the new Athlon 64 X2 5000+ is better than on my previous workstation, a Pentium D 2.8 GHz. As long as you install a 64-bit host OS and at least 4 GB of RAM, you should be able to comfortably host several VMs. So far doing development on a VM is going pretty well for me, but there are a couple of minor gotchas. If you use multiple monitors, you'll have to change your work style a little. The VMware console window will only maximize to a single monitor and has some minor usability issues, so you'll probably want to connect to the VM using Remote Desktop with the -span switch. The taskbar will stretch across both monitors, so you'll lose a little screen real estate. I use WinSplit Revolution to "maximize" windows to one monitor or the other. If you run multiple VMs that are hard drive intensive, you'll want to put their virtual hard drives on separate physical hard drives (or use the raw disks for the VMs' hard drives). You also should settle on a single virtualization package for all the VMs running on one host system. If you have VMware VMs and VirtualPC VMs running on the same machine, for example, they'll both compete for the same resources and you'll see significant performance degradation. (I found out just the other day because I had to create a VirtualPC VM for someone while I was trying to work in my VMware VM...I ended up having to take a break while I waited for the one to finish.) If you just have one virtualization package running, it will be able to allocate system resources more efficiently. Right now I have My Documents and some other data folders stored on a network-shared physical drive on the host OS. My ultimate goal is to set up a 64-bit Solaris VM with a ZFS filesystem over a couple of big disks, and redirect all my VMs to store the home directories on that drive, but we'll see if I actually get around to that. Rob

modified on Tuesday, December 2, 2008 3:26 PM

> Firstly please specify what your position in your company is and in what industry you work in. I'm the operations manager for a small software company that develops code analysis tools. Right now we mainly service the aerospace and automotive industries, and we've done some work for financial/insurance companies in the past. Currently we have one commercial, shrink-wrapped product which is selling worldwide, but the majority of our work still comes from contracts. > When will you employ someone as a permanent member of staff? Yes, we currently have several full-time staff, as well as some of long-term contract workers for software engineering and translation services. > When will you employ someone under a contract for a period of months? We often employ 1 or 2 interns during the fall and spring semesters, as well as during the summer break. We also have one person who we originally hired under contract for a period of a few months, and we've made his contract more or less permanent since he has continued to be extremely reliable now for several years. > When will you employ someone on a daily or weekly basis? Occasionally if we need someone to do some technical writing and all of our developers are busy on contract work, we'll farm out some of the writing for someone else to do a first draft, then we proof it to make sure the writer had a grasp of the technical terms and concepts. We contract out translation work (usually on a per-word basis) when we need error messages, GUI elements, documentation, or tech support requests translated to/from Japanese or another language. We also have hired interpreters to sit in at meetings when customers visit us, or to accompany one of us when visiting customers in Japan. Sometimes we happen to know an expert in the field of a particular contract that we've taken on. In those cases, we usually subcontract the person at either their normal rate or our normal engineering rate. > What qualities would you look for in the people who applied, and what would you expect to pay for their services? We look for bright, self-motivated graduate or undergrad students from the local university. Everyone who has been hired full-time at the company has been an intern at some point, and we are always looking for interns who we could consider hiring full-time when the opportunity arises. Ever since we gave a simple project to an intern who completely failed to produce anything even remotely like the spec we provided him, we've used that

Yes, I like my dual 19" monitors. I've also used a 26" monitor and that worked just about as well. More screen space is great for debugging. I'd highly recommend using WinSplit Revolution to move your windows around if you want to make the best use of all that display real estate.

Sometimes their superior knowledge makes them blind to a more practical solution. A lot of the time, the concepts they're working on might be far superior in an academic sense, but completely impractical when applied to real-world problems.

As someone else mentioned, if their expertise is not in selling software, you shouldn't even considering entering a partnership with them. There is absolutely nothing in it for you. Give them two options: 1. Do the work as requested from scratch. 2. License or purchase the software from you. Which of these you offer should be your choice, not theirs. If you think this software has wide applicability and think you can "sell" it to other customers, you may wish to go the licensing route. Otherwise, if you don't care to retain ownership of the source code, you can sell it to them for a significantly larger amount (at least make sure you've recovered your development costs).

The performance issues that most people cite with Java are due to poor understanding of the internal implementations of the data structures they are using. For instance, if you use a LinkedList to store data elements, then traverse the list by retrieving items with List.get(), performance will be on the order of n^2. If, on the other hand, you traverse the list by using an Iterator, and/or you use a different type of data structure (such as an ArrayList), your performance will be linear. In addition, if you use a class that has built-in synchronization support (such as a Vector or Stack), but you do not require synchronization, you are wasting your resources and should instead use a data structure that does not have built-in synchronization support (such as a List, which is easy to use in place of both Vectors and Stacks). The JVM will compile Java bytecode down to native code once a method has been executed many times. Or, if you want your program to run faster from the start, you can launch your JVM with the -server option. A couple of years ago, my company used Java to analyze 16 million+ lines of COBOL source code on parallel machines within just a few hours. Although the CPUs were pegged at 100%, we found that the largest bottleneck was disk I/O, and we compensated for this by pooling objects, compacting our output format, and optimizing the read/write strategies used by our processing routines. The amount of labor required to perform these optimizations was far less than the amount of labor expended on parallel efforts to port parts of the logic to native code, and the Java stuff was easier to debug and maintain. Sure, someone who is married to C could say we aren't as seasoned in C and that we're wimps for not wanting to do our own memory management, and they would be right--at least on the "seasoned" part. ;) But the tradeoff is that we were able to develop the application in less time; and it has been easier to debug and maintain, if only because low-cost Java development tools are easier to use for navigating and refactoring existing code. However, we have both computed and measured the execution time of various computation-intensive tasks that we perform, and the performance is very similar between C and Java implementations. I'm sure the magnitude of the performance discrepancy between Java and native C apps is still somewhat application-dependent, but the truth is that an application won't be slow simply because it's written in Java--and even if that were the case, there are ways o