Now after I defeat this robot, I will gain the Robot Chainsaw power.
Rather, they will merge. Once a color e-ink screen with an adequate refresh rate comes out, all previous tablets and e-readers will become horribly obsolete compared to the new, combined version. Until then, e-readers will continue to fill a niche market. They might not be as popular as they once were, but they aren't going to go away.
Or perhaps multi-transit, for when more than two transit at the same time.
This is just a case of people not wanting to admit that they messed up. They don't suddenly start giving the opposite answers they did before, they just justify the answers they thought they gave by mistake, so that they don't look like idiots. It's more a demonstration about people being stubborn than anything else.
And my answer will be, "Where do I sign!?"
This gives a whole new meaning to the term "Mood Lighting."
That's when you have to introduce another tier - "Important but Stupid."
I get-around the "single login" deficit by using the same name/pass across all websites where I don't care if they get hacked (like posting replies on newspapers). I use a 2nd password for personal websites like email. And a 3rd strong password just for the two banking/stock websites. Nothing gets written down so I don't have to worry about somebody finding my "scrawled passwords" laying in plain sight.
I've been advocating this approach for years. I call it "Password Tiers."
OpenGameArt supports other styles and formats as well, just not for this competition. They could definitely use some 3d camels.
I'll second the recommendation for Spring. Spring MVC is really useful, and the dependency injection is very powerful but also pretty simple to use.
My other recommendation is to remember KISS: Keep It Simple Stupid. No matter what you choose to do, keep it as simple as possible, but no simpler.
That's why they do, indeed, build in ways of storing the energy. In fact, they do the same with every other type of power plant, so they can run at only peak efficiency. http://en.wikipedia.org/wiki/Energy_storage
About ten years ago, I was assigned to be the in-house developer overseeing a couple of outsourced projects. One went quite well, but the other was a constant struggle. Since then, I have dealt with several other projects that were outsourced, with varying degrees of success. The simple answer is that it can work, but often doesn't. Here are a few things to keep in mind.
- Don't just go with the cheapest. You can save money by outsourcing, while still getting competent developers. Make sure you meet the developers - or at least the leads - before making your choice of consulting company. In the long run, it will cost you a lot more if you end up having to rewrite everything; and believe me, that definitely can happen. Bear in mind that even if the consulting company agrees not to charge for bug fixes, it still costs you money if the project goes way past the scheduled end date.
- KISS: Keep It Simple Stupid. As always, make certain your design is as simple as possible, but no simpler. The simpler and more straightforward a project is, the less likely that consultants can really screw it up.
- Stay on top of the developers. You don't have to micromanage, but you need to be aware at all times what they are working on. They can very easily start going in the wrong direction. Talk to them every day.
- Be very, very clear in your instructions. Never assume that they understand what you mean, especially if they're from a different culture. Be literal, elaborate, and even pedantic.
- Code review, code review, code review. If anyone consistently turns in unacceptable code, have them removed from the project.
- It's fine to give them access to your libraries, etc. In fact, it's best to have them use your source control system, but they shouldn't be able to delete anything. This way, when they inevitably make a stupid change that breaks something important, you can just roll back.
- Assign the easiest/least important things to the worst developers, moderately difficult/important things to decent developers, and do the most complex and important things yourself. This might seem like common sense, but you'd be surprised how many managers treat all developers like we're the same.
- Keep track of how much each project really costs in terms of both time and money. Once you have done one or two this way, you might be able to determine that some projects should be outsourced and others shouldn't. You'll be a lot more likely to convince your boss if you have actual numbers.
Well, I hope this helps. Good luck!
You can't expect people to agree to a reasonable compromise without completing the fighting and name-calling stages first.
Ditto. I might not count as young anymore, but I have never in my life seen any behavior like they describe.