When my daughter was born I weighed a little under 190. When she turned 1 I weighed closer to 210. That's a 20lb gain in a year. I know at least some of the increase is muscle mass that I gained just from lugging a car seat all over (I really did notice an improvement there), but mostly it's just extra fat that I don't need. I've never been exactly skinny, but I've never been fat enough that I really had to care about my weight either. At this point it was clear to me I had to do something. I made some changes, and nearly a year later I still weighed close to 210. There was no improvement, but at least I hadn't lost any ground. Since then I've done a few more things, and it's starting to have noticeable results. I regressed a little over the holidays, but I'm back under 200 and still falling. Here's what's working for me:
- Regular Reporting. The key here is to be accurate, consistent, and frequent. I paid about $10 at a warehouse sale for a digital scale from Weight Watchers that reports to within 2/10ths of a pound. I weigh every morning right before getting dressed. This way I get regular accurate feedback about how I'm doing that isn't subject to variables like what I had for dinner or what clothes I'm wearing that day. And the scale wasn't even that expensive. It also helps that my wife is doing this with me, and we keep each other up to date on our progress.
- Easy Exercise. I mean easy. Seriously, I don't even break a sweat. I just go for a leisurely walk for 5-10 minutes after lunch every day that I can. Usually this means 2-4 laps around the outside of the office building where I work. There are two important points here. One is that it comes immediately after I eat. By doing it at this time I change the way my body metabolizes my lunch. I've had some people suggest that it might be even more effective if I did it before I eat. I may try that, but what I'm doing is working pretty well. The other point is that I don't obsess about it. This way, it's something I want to do, rather than something I have to do.
- Subdued Snacking. This works because I set it up so that it's not about will-power. I used a three-pronged attack. First, I keep a 34oz thermos at my desk for water. I make sure to fill and drink it at least once per day. This helps keep my stomach from feeling empty, and has other health benefits as well. Second, I also keep a box of Cheerios at my desk. These don't taste bad, but they're not exactly the most appealing snack in the world. The important thing is that with them available I'm not likely to get something else that's less healthy. I do tend to eat enough to avoid needing to snack later in the day. Finally, I've switched to mostly diet soda. It was a shock at first, but you get used to the diet taste pretty quickly. Now I only notice I'm drinking diet if I've had regular during the same meal. Together these add up to not being as hungry through the day, and I'm therefore less likely to eat a high calorie snack I don't really need or pig out at supper.
- Careful Caffeine Consumption. This one probably won't help most people, but it's working for me at the moment. I've written before about my special hot cocoa. What I didn't mention is that on days when I'm extra tired or drowsy I'd put a lot more coffee in the mix. I noticed that on days when I needed the extra coffee my weight would almost always drop. I want to be careful here. This is the kind of thing that your body will adjust to and build up a tolerance. So as I get more caffeine, I need more caffeine to get the same effect. I'd also prefer to avoid any unnecessary chemicals. But at the moment this is working for me. I think it has more to do with the caffeine helping me stay more alert, and therefore be somewhat more active through the day than any specific direct weight loss effect like a metabolism increase. It may be that it only works when I'm really tired. But I'm not a doctor and haven't researched it at all, either. In the meantime, I'm just 'superstitious' enough to keep at it.
- Recognize Results. I set up milestones every five pounds, and when I reach a milestone I get a reward. The reward should be something relatively cheap and simple, not food-related, yet meaningful. I chose to use music. After each milestone I get 5 songs from iTunes or a competitor. Achieving a milestone is something of a challenge. It's not enough just to come in under the target weight once. I must reach and hold it for 5 days first. This prevents the temptation to use a crash diet or fast to get the short-term gain before regressing back to the previous level, just to get the milestone payoff.
Brand choice
HPs can be very nice machines. So can a Dell, or even Gateway for that matter. The trick with any of the major brands is to avoid the lowest tier systems.
These system are designed to compete on price, and price alone.
Sometimes cuts will be made that shouldn't be made to make it possible
to sell the system for less. As long as you go at least a notch or two
above the basic level, any of the major brands should be okay. You'll
pay a little more, but it's well worth it. If you can manage it, try to buy from the vendor's small business line. These machines are often put together much better.
Operating System
At this point, I don't yet recommend Windows Vista. The set of things
Vista will do that XP won't is not very large, and there are too many
quirks. XP has the benefit of years of incremental improvements to
stability and security that Vista just can't match right out of the
gate. Additionally, I've seen a few reports that development of
Vista's successor is going much more smoothly than it did for Vista,
and we may see it out as early as next year. In light of that, Vista
may never get much traction. And since you're going to run XP, make sure to avoid the 64-bit edition. It will cost a little extra, but get the Pro version if you can afford it. Again- make sure to compare apples to apples. You need to account for it when comparing quotes if one system costs a little more but includes XP Pro instead of XP Home.
Memory
It's beginning to look like 4GB is where we really want to be. Unfortunately, as it stands the OS can't use much more than 3GB, especially if you
get a decent video card. This means there's not a lot of point to buying
the whole 4GB right away. For now get no more than 2GB.
This is the easiest thing in the world to upgrade later if you need it,
and by the time you need the upgrade it won't cost as much any more.
Also, 64-bit support will have improved by the time you upgrade--
perhaps enough to allow you to take full advantage of it. Microsoft is
actually pushing 64-bit pretty hard. All of their big server products
require it now. I wouldn't be surprised to see the next version of Windows only come in a 64-bit version. But since right now you're still running 32-bit, just get 2GB.
Software
Most of the software included with a new computer is just fluff. But if one machine comes
with MS Office and the other doesn't, that could explain $150 price
difference (maybe not justify, but at least explain). If you're a student or casual home user, Open Office is probably enough for now.
The only thing I really make sure to use MS Office for is my resume.
When it comes time to send that out, I want to be sure that my resume
looks right to potential employers and that Open Office doesn't give it
some rendering inconsistency that I'm not seeing. The point here,
though, is to make sure you're comparing apples to apples. If one quote includes some expensive software that you'll need, make sure the others do as well, or that you at least account for the difference.
Warranty
The warranty is a similar issue. I don't recommend an extended warranty for desktop computers.
It's too easy to do hardware work yourself (or get a friend to do it).
I just can't justify the expense for anything beyond one year. However, if you're buying a laptop you'll want to take this into account.
If one laptop costs $250 more but has a three year warranty instead of
just one, that's probably worth it. My wife's laptop had a motherboard
fail after 15 months. Our cost to get it fixed: nothing. We had paid $368
to get a four year warranty, and with the one event the expense
was justified.
To understand what virtualization is, let's start by looking at a server. You can thing of a server just like a regular desktop computer. It has resources like memory, a processor, and a hard drive, with an operating system that runs on top of all that. Now let's twist things up a bit. You take the server hardware and install a special operating system. This operating system provides a new base onto which you can install your regular operating system. Not only that, you could install several operating systems side by side-- all on one set of hardware. You gain an advantage this way because servers tend to be either way underutilized for simple tasks or way overburdened for complex or frequent tasks. You can now easily combine several underutilized servers in one place, freeing up hardware to share the load for the overworked servers.
Additionally, virtualization enables a number of new things that were not possible before, but I won't go into that here. I think the benefits for larger enterprises are pretty well documented. But what about smaller businesses? Here are two scenarios that show how virtualization can improve reliability and help promote growth for even the smallest businesses.
First, let's imagine you run a smallish business. You have between 15 and 50 computer users-- just big enough to need a full-time IT guy, or at least keep him busy enough he's cheaper than paying a consulting firm all the time. You probably have one server that acts as your domain controller, file server, and print server. You have another server running your web site, e-mail, intranet, and perhaps a custom business application. You have a third server running your database. This is a very common set up. Each of these servers is a single point of failure that can stop your business in it's tracks. Unfortunately, you're not big enough to really justify redundancy for all of those machines, but you do have a good UPS and overall they're pretty reliable. In fact, you run for months at a time with no trouble at all. However, when something happens, it happens big.
Enter virtualization. Now you set it up so that each server is a virtual host. Each host runs an instance of what used to run on each server, and they're configured to do load balancing and fail-over with the other two. Part of setting up the hosts is creating a virtual SAN so that the disks are shared in an efficient way. Now if a server goes down it's no big deal. More than that, as your business grows it scales up by just adding new boxes to the cluster- the hard work is already done. About the only thing you'll want to do later is add a real SAN to replace the virtual one.
This also adds flexibility to your setup with regards to deploying new systems. You can add servers for new features or test new OS or software versions in an isolated environment without having to purchase any additional hardware. You can take a system down for maintenance or upgrade during business hours without any loss of service.
Unfortunately, at this point getting the clustering to work is much easier said than done, but that is improving. And while still classified as a small business, the business in this example was still big enough to require a full-time IT staff member. So let's try another example.
Let's say I have a small software business. Since I hope to do that one day, this isn't far off. I have fewer than four users, but because I'm selling software I'm at the very least providing large downloads. I probably also need source control somewhere, and possibly provide a computer intensive service over the web. I also have a need for a testing environment that is guaranteed not to interfere with my production site. In short, I have processing needs that far outstrip what you'd normally need for this size user base.
In the past, to solve these problems I probably kept one server on site that's really more of a glorified workstation. This computer functions as source repository, pint server, and test environment. My web site, e-mail, and important backups are kept on a machine leased in a datacenter somewhere. This machine will automatically take care of backups, have a high quality internet connection, and have a qualified system administrator looking after it. If something goes wrong it the support contract ensures a replacement is up and running fairly quickly. If my needs grow beyond one production server, I can lease another machine
This setup is pretty good, but we can do a little better. I'll start by virtualizing the on-site server. Now I can isolate my test environment in it's own virtual machine. This will allow me to prevent my test system from bringing down my source control and print server. Even if I just do something that tries to claim all the resources I can protect myself by setting a quota. It also allows me to easily re-configure my test environment without interfering with the other system. In that past some people would have even required a second server to accomplish these same goals. Now I know I only need one.
Now let's look at the hosted server. There are two problems with this situation. First, you have to buy computing power a whole machine at a time. Secondly, occasional brief outages are still possible. These days, you don't have to lease a whole server. You lease a virtual server. You'll have to share the physical box with a few other people, but it's okay because you don't know who they are, they don't know who you are, and no one can see anyone's system but their own. You are protected from a peer grabbing all of the resources on the machine because your virtual server is actually running in a cluster on several machines. This also minimizes the danger of outages due to upgrades or individual machine failure. You save money because you pay a base rate for the virtual server, and then only pay for the computing resources you actually use. This could seem to get expensive depending on rates, but if you're using more computing power it's likely because you have more customers or sales leads, and this is a good thing. In fact, virtualized servers start for much less than leased physical servers.
In short, virtualization can save you money, increase reliability, and allow you to do more, no matter what size your business is.
I had the unfortunate experience to witness an absolute debacle this weekend. I hear this great 'choking' sound coming from somewhere near Green Bay. I'm referring, of course, to the recent NFL playoff game in which the Green Bay Packers lost to the New York Giants. I blame the play caller.
Don't get me wrong: there's plenty to criticize here. The defense didn't play the well. Kickoff coverage wasn't as dominant as it has been. The referees where all over: missing easy calls while making tough ones. The offensive line played poorly, resulting in a week run game and hurried throws. The cold was obviously impacting Favre's play. But when it comes down to it, I think coaching was the biggest gap in this game.
Let's review. The defense played poorly, but it still held the Giants to 20 points in regulation. That should have been good enough to win. With the exception of a very ugly Bears game the Packers hadn't scored less than 20 since October, and that includes a couple other cold weather games (including the playoff game vs the Seahawks) as well as the Cowboys game. The officiating was frustrating at times, but it seemed to be at least balanced. You can't blame the loss on them. The offense has a number of problems, but we went in to half time with the lead and scored 10 points in the third quarter.
This leaves coaching. Look at what the Packers have done well this year. We have a 5-receiver package that no one has handled well, even when they know it's coming. The Giants had two injured corners, so it could have worked very well here. I never saw it- not once. There's a crossing route Driver runs that no one has been able to defend well. Last night it was used only rarely. And the running game was never given a real chance, even though we knew passing would be tough. We have a defense that is known for adjusting and getting stronger as the game progresses, but in this game no adjustment was made.
What did we do instead? We saw way too many 2nd and 10 or 3rd and longs in that game because of a bad 1st down screen pass. A screen pass? That hasn't worked for us all year. Why should we expect it to work against a very impressive Giants front seven? I understand the cold weather made a lot of things more difficult. But it made things more difficult for the Giants, too. A lot of our passing plays are specifically designed to be short yardage plays that can be successful even in bad weather. We did do a little of that, unfortunately with some poor execution. That's just another reason to run the ball more. But not screens.
Not that I think we need to replace Mike McCarthy. He's done great things this year. He took that Packers farther than anybody expected, and for that he should be congratulated. But we had a hard time in all of the big games this season. Both Bears games. The Cowboys game. And now the NFC Championship. There were a couple times this season he left points on the board after failed fourth down attempts. I hope he takes a long look at this game (and a few others) in the off-season, and learns a few things about how to call plays in big games.
This is all over the tech news. Here's a link to one of the plethora of stories about the transaction.
This is a pretty big deal to the tech industry, so it's been widely covered. I think it will be a good thing, and I think most of the angles have been discussed elsewhere already, but there are two implications of this sale that I haven't heard anything about yet, and I'll touch on each briefly.
1) What does this mean for Oracle?
Each of the major databases has it's paired language. Maybe it's not official, but if you use the language the odds are pretty good (though definitely not certain) you're using the matching database as well. For example, if you're using anything .Net, MS SQL Server is probably your database of choice. If you use PHP it's a good bet you prefer MySQL. In the past, Java was Oracle's language. Most of the Oracle development samples are in Java, and Oracle seems geared to appeal to Java developers. A large percentage of enterprise Java applications talk to Oracle.
This changes the game a little bit. Now Java and MySQL are under the same roof. I would expect Java's support for MySQL to improve significantly, made possible in part by changes to MySQL to specifically make it more Java friendly. It's just natural. If I were Sun one of the first things I'd do is build a package that makes it exceptionally easy to install the Java runtime, MySQL, and some good GUI management tools onto a Windows server, and then use that server as deployment point for the Java runtime on the local network.
Of course, Oracle isn't just going to disappear any time soon, and the Java developers aren't going to convert overnight en mass. In fact, Oracle today also bought BEA Systems, in a deal worth 8 1/2 times as much as the MySQL deal (the MySQL deal, though, is a lot more interesting). But this does have the potential to diminish Oracle's prospects in the long term. They'll still make money, but maybe not quite as much as they would have. And look for Oracle to do something in the language space to help themselves have a natural language partner again.
2) What about Monopolies?
Whenever two large companies merge this always comes up. This time it's had a bit of a pass. Neither Sun nor MySQL by themselves were big enough to merit such attention, as an open source product there's no way to count MySQL installations and therefore no way to prove market share, and the two businesses are such that this is a no-brainer that there isn't a problem.
All those circumstances change once the merger is completed. We end up with a landscape in which there are two big open source players in Sun and RedHat. Neither of these companies is an any danger of becoming a monopoly by itself. Between Microsoft, IBM, Apple, and Google there's just too much competition for their offerings. But what if at some point Sun wanted to buy RedHat? Or vice versa? Would the feds try to block the merger to avoid forming a monopoly in the Open Source market?
I think that scenario is very unlikely; but it is possible even if remotely, and it's worth mentioning because of some of the issues it raises. For example, how can you be a monopoly if the code for your products is freely available for anyone to sell and compete against you? Often a requirement for mergers of large companies is that a company make certain changes to it's product, to make it harder for it to abuse a potential monopoly. How can you require such a change of a company when the company is dependent on volunteers to implement them? If an open source company grows to the point where it's featured project edges out competition almost completely, could this company be held responsible even though they are neither the creator nor owner of the program in question?
There are more questions, some harder to answer than others. For example, you certainly can get into monopoly trouble if your freely available product drives out competition and you have another complimentary non-free product. It's called predatory pricing.
The Hook
Let's bring these together. What if Oracle bought Sun? That would shore up Oracle's language gap and eliminate a competitor in one go. In fact, Oracle has already tried to buy MySQL in the past. Oracle is certainly big enough to do it, and Sun's may find themselves vulnerable at some point not too far in the future, assuming they'd even fight it. Oracle has been responsible for a lot of developers using Sun products, and both Sun and Oracle have a deep dislike for Microsoft that makes them natural allies. But that might raise some real anti-trust issues, with the potential demise of MySQL at stake.
Imagine you go back in time and find yourself in an era just before electronics or 'the wireless'. Say shortly before 1900. You meet someone there, and he notices your cell phone. You try to explain to him what it does, and how it works. You tell him that in the future nearly everyone will carry the device, and it allows you talk to people over great distances almost as if they were standing next to you. You explain that the device emits an invisible signal, and there will be towers all over that receive the signals and re-send them to whoever you are talking to.
This is where it gets interesting. I think this would cause your historical friend to stop you for a moment. "You mean you can make your voice heard on the other side of a continent as if your were standing there, but it has to stop at some kind of tower first?"
Not that he couldn't understand. You just explain that the signal deteriorates over distance. But in his mind getting that signal into the air in a way that can be retrieved in the first place is the big hurdle. So big as to be almost unimaginable. Once you've accomplished this increasing the distance would seem to him a comparatively small problem.
This kind of problem happens all the time in software. You'll get questions like "Why can't I send this 15 minute video to 40 people via e-mail?" or "What do you mean Excel only supports up to 64,000 rows?" There's a lesson in there somewhere for software developers, but I'm too lazy to spell it out right now. Probably something about how software developers relate to users. Or how to manage user expectations. Or publish limitations. Or something.
I enjoy the occasional game of Minesweeper. It may seem silly, but whenever I get a new computer one of the first things I want to do is a set a score (any score, though if it's really poor I'll go again) for each of the difficulty levels. After college, before I got my first job, I even made my own clone in C++ Builder. I'd like to think I'm pretty good, but a quick google search produces people with some truly amazing scores. Lately I've begun the quest to break the two minute barrier on expert. I just set a new personal best, but I'm still two seconds shy:
Of course, I could easily have faked this, so you'll just have to take my word for it that the shot is real. Since the time is comparatively not that good I'd have no reason to lie. This is only a little exceptional for me: I frequently score in the 130s. A more typical time is closer to 160 seconds.
My recent play has taught me that Minesweeper is as much about memory and pattern recognition as it is about logic. This is especially true when playing for speed. Sure, the logic is there. But most of it you only do a few times before it becomes committed to memory as a pattern you recognize and apply. This gets more obvious as you learn more complex patterns.
One example is a pattern I uncovered recently that improved my speed significantly. I call it the "1,2,1 wall". Whenever you uncover a row of unsolved blocks at least five long with a 1,2,1 next to blocks along the center, I know right away without having to think that there will bombs next to the 1s. I could figure this out again each time, but it's much faster to recognize the situation and apply bombs in order. The pattern is adaptable, and comes up more than you might think. It's helped improve my time considerably. Unfortunately, my pattern library is still pretty small. What's your best time? What are some patterns you use?
Unless you're looking for a really top-end system (read: unlimited budget), overclocking isn't all that cost effective these days. To understand that statement let's think about the life-cycle of a build, from first planning to obsolescence.
When first putting a build together one of your goals is for the system to be upgradable, so that your next purchase doesn't need to involve re-vamping the entire machine. However, you're still on something of a budget. So you go for a top-end motherboard. This way you'll be supporting something closer to current generation technology in a year or two when it's time to add ram, update the graphics card, etc. However, the cost of the nice motherboard forces you to sacrifice something in terms of the CPU and memory you can afford to include. You end up with about the cheapest CPU available for the board. Unfortunately, the cheap CPU probably isn't a very good for over clocking, and if you could afford the cooling system necessary to make it work anyway you would have bought a better CPU. This is okay. It should be a good improvement over what you had before because you're still moving to all new technology. And this is all in the name of future improvements.
Time passes; the system ages. You add ram and update the video card. Perhaps you even replace the hard drive. It's now time to upgrade the processor. What do you do? The key here is that your motherboard only supports a certain type of CPU, and within that type it only supports certain clock settings. Right now your CPU is near the bottom of the supported range and not overclocked very far. There's a lot of room for improvement. By this time your motherboard is at least one generation out of date, so you're no longer looking at state of the art parts. You have a choice. You could get something mid-range for your board that you know will overclock well, probably all the way up to your board's max. Or you could just buy the fastest CPU your motherboard will support.
If you were still looking for top of the line parts it would make sense to try to overclock the system. A faster CPU would cost twice as much or more than a cheaper model and you may not even be able to get a CPU that would max out your board yet. However, the dynamic begins to change now that we're a generation back. The price difference between a CPU that will max out your motherboard out of the box and a mid-range CPU for the board probably isn't very large. By getting the faster, more expensive CPU you can save a lot of the difference on your electric bill, since you won't need to adjust the CPU voltage and won't generate extra heat from overclocking. You also won't have to buy new premium cooling equipment. And that doesn't even take into account the intangibles of system life, stability, and warranty issues. When you sum it up, it's probably better to go ahead and buy the CPU that will max out your board using the factory settings.
At this point your system is about as fast as it will get. You can't add any faster parts to the motherboard, and if you replace the motherboard you're either not getting a significant upgrade or you're making everything else in the system obsolete. This build is officially finished. But hey, you got three or four years out of it and the only part you had a pay a premium for was the motherboard. For an enthusiast system, that's pretty good. During the life of the build you never had a system that was top of the line, but the system was never horribly out of date, either. Remember, I'm talking about 'cost-effectiveness' here, in generic terms that aren't limited to any particular technology. And through the whole process you never did any significant overclocking.
We've already seen a lot of rough driving this winter, and it's barely even January. The very first storm I had a wiper stop working on my way home, and that was no picnic. But I think the worst thing about driving in the winter has to be getting gas. It just chills me to the bone every time.
There's an old saying, "Less is more." This is especially true in the programming world, where size is the enemy. Programmers are brainwashed with the "keep it simple" mantra almost from the first moment we enter the field.
But sometimes things get turned around. For example, how much code does it take to implement quick sort versus a bubble sort? Obviously quick sort is a lot more complicated. This means it's a lot more susceptible to errors in the implementation, it takes more time to build and maintain, and it adds size to your code base making it that much harder for developers to internalize. So keep it simple right? Go bubble sort!
Not so fast. Take away all that and which algorithm would you rather have working behind the scenes in your application? There's no contest: quick sort is significantly faster. Even with the extra complexity it's almost always the right choice.
So how do you know where the balance tips? When to use an elegant algorithm like quick sort and when to go for simple code like bubble sort? Well, as it happens, I've never personally implemented quick sort, and probably never will. But I have written a number of programs that rely on it, because these days quick sort is the underlying algorithm used to sort collections in .Net. So while I don't have to write it, the correct algorithm is done for me. This means I'll never write another bubble sort, either.
The goal should always be to avoid duplicate code. If this is done to a sufficient level, the complexity matters much less. You don't need to understand how quicksort works to call Array.Sort() in .Net, and the code that makes that work doesn't add bloat to your application because it's generic enough to handle just about any array, and it's hidden away in a library that's rigorously tested and hardly ever changes. This makes it possible to have very simple and maintainable code that performs very well.
Of course, you can't insert your own code inside the .Net framework. But if you're working on a project of any significant size you should have libraries for common and important tasks. These libraries should be well named, as generic as possible, very well tested and documented, and change rarely. And they should be full of quick sort code rather than bubble sort code. Once you have a library, don't write code that uses it unless you can explain the code to a six year old, or worse, a sales director.
