1: Your job is to see that they have the most efficent service possible for the cost they put out. Remember that your department is an overhead cost and that all right thinking executives hate overhead with a passion.
2: If you have no budget, you are an admin not a manager, whatever your title may say...
3: If number 2 is the case and you would like to change that, think about number 1. Show you're thinking about cost and not just kingdom building. Maybe they will trust you with some cash.
For enterprise applications, VB is no longer a viable language. If you are a MS shop, stick to C# or VB.Net. Otherwise there are many fine web-based scripting languages that can an application up in short order. But there is no longer any room for these evil entities to spawned throughout your organization. Packaging and deployment will be hell for your network group, and face it, as this article attests, VB is still the language of amaturs and wannabes and thats likely what you will get. Beware. Beware...
1.) Use global variables for everything. Make sure you give them funny names like 'beeblebrox' and 'Wookie' that give absolutely no hint of what thier purpose might be. This will give the poor sl.., er, maintainer a good laugh as they tweeze thier way through your code. And yes, please feel free to reassign thier values often for whatever purpose you need in any give place.
2.) Avoid specialized classes and functions like the plague. Place everything in gigantic Sub or void methods, trying to pack as much of your programs functionality as you possibly can into each block.
3.) Thoroughly document your code by scattering non-sequitor comments at random points.
This is a proven tecnique. In fact it works so well that anyone with a brain that gets a look at it will
recommend that your app be shitcanned immediately rather then waste another dime maintaining it.
We always write to specs. Usually implied. Whether it starts as just a few lines on a cocktail napkin or it's an explicit interface definition, it's just a starting point; but a project without any is guaranteed disaster. I know that requirements gathered by comittee rarely translate into live code and I personally find that the best way to gather requirements is to prototype heavily, but you have to start somewhere. Every right-thinking programmer detests documentation; unfortunately there is no substitute for the waterfall. People may think they've just written the most brilliant piece of code ever, but if it's not spec'ed and coded to that, thier grand creation becomes just another pile of steaming spaghetti code to the next poor slob that has to deal with it.
MfT
I just built a new gaming rig (P4 775) and come to the conclusion that liquid cooling is no longer a just a fancy option for over clockers. When the cooler get up to full song it almost impossible to hear anything else. I'm now saving my pennies to retrofit nice quiet liquid cooler. In rig like this it should be standard. (especially with a $5000 price tag...)
TFA is based on the assumption that a fixed power source is equivilant to a mobile one. If the fixed source is sufficently cheap, it's still viable to use an expensive process (power-wise) to produce mobile fuel.
The problem I see is scale. How much of our demand can this really meet? I would say not much. Agro-chem is useful, but can't compete with petro for meeting actual supply. We need another alternative.
The moon is a great laboratory for learning how to exist in deep space. We need to learn deep space survival skills, shelter construction, how to process materials and more before even thinking about attempting a manned Mars mission. At some point we need to start learning to use whatever space resources we can. Both because an emergency may mean astronauts can't count on bringing everything in a can, and also in a larger sense that there is only a finite amount of resources available on our planet and they are only going to diminish.
Also: Rest assured our (us US citizens) govenment is going pour similar money into junk weapons or into some rat hole or another anyway. As it goes, this will actually be a pretty good use of our tax dollars.
Slashdot Mirror
1: Your job is to see that they have the most efficent service possible for the cost they put out. Remember that your department is an overhead cost and that all right thinking executives hate overhead with a passion.
....?
2: If you have no budget, you are an admin not a manager, whatever your title may say...
3: If number 2 is the case and you would like to change that, think about number 1. Show you're thinking about cost and not just kingdom building. Maybe they will trust you with some cash.
4:
5: Stock options and a corner office!
How many of the ebay and PayPal ripoffs do you suppose are the result of people responding to this simple phishing scam?
For enterprise applications, VB is no longer a viable language. If you are a MS shop, stick to C# or VB.Net. Otherwise there are many fine web-based scripting languages that can an application up in short order. But there is no longer any room for these evil entities to spawned throughout your organization. Packaging and deployment will be hell for your network group, and face it, as this article attests, VB is still the language of amaturs and wannabes and thats likely what you will get. Beware. Beware...
1.) Use global variables for everything. Make sure you give them funny names like 'beeblebrox' and 'Wookie' that give absolutely no hint of what thier purpose might be. This will give the poor sl.., er, maintainer a good laugh as they tweeze thier way through your code. And yes, please feel free to reassign thier values often for whatever purpose you need in any give place.
2.) Avoid specialized classes and functions like the plague. Place everything in gigantic Sub or void methods, trying to pack as much of your programs functionality as you possibly can into each block.
3.) Thoroughly document your code by scattering non-sequitor comments at random points.
This is a proven tecnique. In fact it works so well that anyone with a brain that gets a look at it will recommend that your app be shitcanned immediately rather then waste another dime maintaining it.
We always write to specs. Usually implied. Whether it starts as just a few lines on a cocktail napkin or it's an explicit interface definition, it's just a starting point; but a project without any is guaranteed disaster. I know that requirements gathered by comittee rarely translate into live code and I personally find that the best way to gather requirements is to prototype heavily, but you have to start somewhere. Every right-thinking programmer detests documentation; unfortunately there is no substitute for the waterfall. People may think they've just written the most brilliant piece of code ever, but if it's not spec'ed and coded to that, thier grand creation becomes just another pile of steaming spaghetti code to the next poor slob that has to deal with it.
MfT
I just built a new gaming rig (P4 775) and come to the conclusion that liquid cooling is no longer a just a fancy option for over clockers. When the cooler get up to full song it almost impossible to hear anything else. I'm now saving my pennies to retrofit nice quiet liquid cooler. In rig like this it should be standard. (especially with a $5000 price tag...)
Not everyone has or needs a degree, but every good programmer *knows* computer science. If you don't know the basics, you can't be good.
Looked at the HIPPA specs? Plenty of room at th e waterhole there. MfT
TFA is based on the assumption that a fixed power source is equivilant to a mobile one. If the fixed source is sufficently cheap, it's still viable to use an expensive process (power-wise) to produce mobile fuel.
The problem I see is scale. How much of our demand can this really meet? I would say not much. Agro-chem is useful, but can't compete with petro for meeting actual supply. We need another alternative.
The moon is a great laboratory for learning how to exist in deep space. We need to learn deep space survival skills, shelter construction, how to process materials and more before even thinking about attempting a manned Mars mission. At some point we need to start learning to use whatever space resources we can. Both because an emergency may mean astronauts can't count on bringing everything in a can, and also in a larger sense that there is only a finite amount of resources available on our planet and they are only going to diminish. Also: Rest assured our (us US citizens) govenment is going pour similar money into junk weapons or into some rat hole or another anyway. As it goes, this will actually be a pretty good use of our tax dollars.
One thing's for sure: No matter how powerful, it's bound to be at least 1000 miles from me and my ping's still going to be >100...