To me there's a huge difference between cheats and a lower difficulty level. If you really are having problem playing a game, nowadays there's almost always some way of 'lowering' the difficulty level with most decent quality games. I think this is a much better approach than just using cheat codes to whiz through the game.
Take the cheats from just about any game. How often does playing with cheats 'take the fun out of it', and how often does it 'improve the experience'. Given a cheat that lets you go anywhere and do anything in a game, it's been my experience that more likely than not, it ruins the experience (unless the game is obsenely hard, which is relatively rare). That also lends itself to a game balancing issue. The more open-ended you make a game (e.g., Oblivion/Morrowind), the more chances you have for both bugs, and balancing issues. (With enough grinding, it wasn't hard to become a virtual god in Morrowind.)
There was an ex-googler named 'Ron' who had a similar situation, where he would fly from the Los Angeles area to the San Jose/Mountain View area to work. The archived posts start here: http://xooglers.blogspot.com/2005_11_01_xooglers_a rchive.html.
Basically, the commute and stress on his family ended up with him quitting the Google job, and using it for leverage to increase his position in the previous job that he held.
Although a bit tangential, Ogre 3D has a C++ API. In order to create a Java API, the Ogre4j developers have been working on an automatic bridge to create C++ handles for Java programs specifically from Ogre 3D's C++ API, using JNI and some other stuff:
http://www.ogre4j.org/phpBB2/viewtopic.php?t=25
You can use this to package all of your previous code into an API that your new java code references.
Granted, this assumes that the new code you will be developing either doesn't need to change much of the existing code (i.e., it will mostly be enhancements, rather than changing existing, already written code). If you do need to change how some of the previous code works, you could handle it by wrapping some structures with Java classes, but the more you have to do this, the more development time you will lose.
Doing a straight rewrite from C++ to Java will take between 50% to 75% of the time that it took you to write it in the first place, and this is a possible alternative to get it up off the ground with a chance.
After this is done, you can slowly convert sections of the C++ code that do frequently change.
It is possible, it can be done, but it heavily depends on how much rewriting you plan on doing to your already existing C++ code.
Don't they already have a naming convention in place for hurricanes? The World Meteorological Organization has been doing this for years. Given the backing of CERT for vulnerability incident descriptions, details, and classifications, why can't they organize a unique naming convention already used for hurricanes?
Sure, they may run out of names, but they can reuse names as they do for hurricane names, with the exception of widespread popular hurricanes/worms/virii, which can be retired, just like some hurricane names.
Can you imagine if this held how liable companies like Microsoft would be? Forcing them to disclose the content of all Microsoft operating system nuances and 'hidden' features that were not fully disclosed?
On the other hand, I don't know any of the best bosses that aren't at least technical savy enough to understand what their employees are actually doing, to the point that they could do it themselves. Some of the best "bosses" I've had have been professors in graduate school, since they have much more of an inkling on what's going on moreso than I've experienced just about anywhere in industry.
The feature that got the biggest applause was ability to embed graphs and charts into IM messages. That enables a user to discuss a spreadsheet or chart with his or her buddy.
Is this the only instant message client that has this capability? There are several that support slapping in GIFs on the fly to buddies in the chat window, but how about actual charts/graphs that aren't natively in an image format?
Everything has to be scriptable and run from some sort of command line
Most system administrators tend to spend the majority of their time doing semi-repetitive tasks, with relatively little variation in these tasks, which is obviously best geared towards a command line. This makes command line scripts that take arguments (to customize the action) much easier than a GUI.
On the other hand, most software engineers and several other disciplines have to deal with tasks that are vastly different, so that command line use to do these tasks would be a nightmare compared to a well-designed GUI. The bottom line: the repetitiveness of tasks determines the optimal choice of GUI vs. command line use.
Technically, you could have a 7-key keyboard that emulates a 101-key keyboard, since 2^8 = 256, and each key rarely takes on more than one function and almost never more than 2 (except for laptops). Unfortunately, pressing 7 or 8 keys at one instant to represent a single character can probably be difficult at best. On the plus side, keyboards such as these would be great for mobile devices such as phones with just 0-9 keys.
After recently installing SUSE 10.0 (KDE/Konqueror version, vs. Gnome), including the latest available version of Firefox from the 5-disc CD set, installing all the updates (via Yast), and finally installing the Googlebar (directly from toolbar.google.com), only to find out several problems with the toolbar. First, in the options settings, the checkboxes have icons in them, making it difficult to see if a box is checked or not. Secondly and more importantly, the text box where you enter in the text to search for is too short, only showing the top 25% of the text you type, although the dynamically generated Find boxes are displayed fine. I'm uncertain if this is a SUSE problem, a KDE problem, a Firefox problem, or a Google toolbar problem at this time, and I currently haven't tested the good old-fashioned open source googlebar to see if it has the same problems yet.
To me there's a huge difference between cheats and a lower difficulty level. If you really are having problem playing a game, nowadays there's almost always some way of 'lowering' the difficulty level with most decent quality games. I think this is a much better approach than just using cheat codes to whiz through the game.
Take the cheats from just about any game. How often does playing with cheats 'take the fun out of it', and how often does it 'improve the experience'. Given a cheat that lets you go anywhere and do anything in a game, it's been my experience that more likely than not, it ruins the experience (unless the game is obsenely hard, which is relatively rare). That also lends itself to a game balancing issue. The more open-ended you make a game (e.g., Oblivion/Morrowind), the more chances you have for both bugs, and balancing issues. (With enough grinding, it wasn't hard to become a virtual god in Morrowind.)
Basically, the commute and stress on his family ended up with him quitting the Google job, and using it for leverage to increase his position in the previous job that he held.
Although a bit tangential, Ogre 3D has a C++ API. In order to create a Java API, the Ogre4j developers have been working on an automatic bridge to create C++ handles for Java programs specifically from Ogre 3D's C++ API, using JNI and some other stuff: http://www.ogre4j.org/phpBB2/viewtopic.php?t=25 You can use this to package all of your previous code into an API that your new java code references. Granted, this assumes that the new code you will be developing either doesn't need to change much of the existing code (i.e., it will mostly be enhancements, rather than changing existing, already written code). If you do need to change how some of the previous code works, you could handle it by wrapping some structures with Java classes, but the more you have to do this, the more development time you will lose. Doing a straight rewrite from C++ to Java will take between 50% to 75% of the time that it took you to write it in the first place, and this is a possible alternative to get it up off the ground with a chance. After this is done, you can slowly convert sections of the C++ code that do frequently change. It is possible, it can be done, but it heavily depends on how much rewriting you plan on doing to your already existing C++ code.
Sure, they may run out of names, but they can reuse names as they do for hurricane names, with the exception of widespread popular hurricanes/worms/virii, which can be retired, just like some hurricane names.
Can you imagine if this held how liable companies like Microsoft would be? Forcing them to disclose the content of all Microsoft operating system nuances and 'hidden' features that were not fully disclosed?
On the other hand, I don't know any of the best bosses that aren't at least technical savy enough to understand what their employees are actually doing, to the point that they could do it themselves. Some of the best "bosses" I've had have been professors in graduate school, since they have much more of an inkling on what's going on moreso than I've experienced just about anywhere in industry.
Most system administrators tend to spend the majority of their time doing semi-repetitive tasks, with relatively little variation in these tasks, which is obviously best geared towards a command line. This makes command line scripts that take arguments (to customize the action) much easier than a GUI.
On the other hand, most software engineers and several other disciplines have to deal with tasks that are vastly different, so that command line use to do these tasks would be a nightmare compared to a well-designed GUI. The bottom line: the repetitiveness of tasks determines the optimal choice of GUI vs. command line use.
Technically, you could have a 7-key keyboard that emulates a 101-key keyboard, since 2^8 = 256, and each key rarely takes on more than one function and almost never more than 2 (except for laptops). Unfortunately, pressing 7 or 8 keys at one instant to represent a single character can probably be difficult at best. On the plus side, keyboards such as these would be great for mobile devices such as phones with just 0-9 keys.
After recently installing SUSE 10.0 (KDE/Konqueror version, vs. Gnome), including the latest available version of Firefox from the 5-disc CD set, installing all the updates (via Yast), and finally installing the Googlebar (directly from toolbar.google.com), only to find out several problems with the toolbar. First, in the options settings, the checkboxes have icons in them, making it difficult to see if a box is checked or not. Secondly and more importantly, the text box where you enter in the text to search for is too short, only showing the top 25% of the text you type, although the dynamically generated Find boxes are displayed fine. I'm uncertain if this is a SUSE problem, a KDE problem, a Firefox problem, or a Google toolbar problem at this time, and I currently haven't tested the good old-fashioned open source googlebar to see if it has the same problems yet.
Speaking of which, was anyone able to see what the 20 proposed steps were that the panel proposed that the US can do to get out of this problem?