The best replies I have seen are from Zurk,& Kohath so let me add to that.

Either develop a market or a product that will fill some segment of a market, first before you do anything.

Now let me suggest that you target a market where the predominant players have become lazy and charge a LOT for their software.

This company Zemax started off when optical design software had a few big players. Their software, on average was selling for $30.000 US per seat. The company founder got a PhD in optical design and while he was still at school started writing his software. What he did was build a PC based optical design system that did 98% of what the big players did. But in that 98% he included what a lot of people term is that last 2% which is the really hard work. He left a lot of the simpler things for later. When he released version 1.0 he sold it for $2500.00 per seat ( with the hardest dongle he could buy at the time ) and after the first month he was moving ~ 10 units a month. In 20 years his price for the basic software has only gone up to $3600.00 a seat.

Make no mistake he worked his ass off to do it, he did it by himself for a long time before he hired his first employe. The company is still privately held and the man stopped having to work for a living many years ago, but he still does it because he loves what he does.

And anthropomorphizing on top of it all.

Look until we can find a way to clearly communicate with bats, or any other species other than other humans, and that is a stretch at times, I ain't drinking this particular glass of cool-aid.

Having been a SONAR technician and having used some of the coolest acoustic toys ever made, I think a more likely conclusion might be:

I find that in a group of bats trying to home in one a single insect they frequently target the same insect and interference patterns are formed causing one or more of the bats acoustic homing to be distorted.

I normally do not respond to AC since 99.9999999% they are trolling, but I will reply since it is actually quite simple.

update_user_pword(uname,curpass,newpass);

and it simply returns true or false, 1 or 0 nothing more, nothing less.

An most importantly use ONE WAY ENCRYPTION when storing a user password! Novel's Netware did this and it was NEVER cracked.

In postgres & oracle you can grant execute to the procedure and or function without giving any rights of any kind to the user to the underlying tables.

In oracle you can write procedures to execute using the schema owner permission, but that permission is never granted to the user so it executes safely. Since procedures and functions only take in parameters and those parameters are never executed then they cannot be injected.

There are many many techniques to have the DB time out the user rather than relying on the middle ware or the browser code.

In the previous example the validation function could return either null or a 512 byte hash that is recorded in an internal table with a timestamp which triggers an inactivity timeout. Whenever the user does anything it must be accompanied by that hash and the DB will only return data if the hash matches, else it returns failure. The timestamp need never be returned to the client, only the hash and that hash can be created from anything, time,user name, count of records in a table, current system load, choose anything that will never repeat. At worst a given hash will be valid for only ( timeout period ) minutes. You can even write the web client so it heartbeats and the system returns a new hash every heartbeat, so even if the client connection is severed the hash is only valid for (heartbeat interval) then its time to live has expired.

Designing in solid security is not hard, it just requires the will to do it and to avoid the common programming patterns that have proven themselves to be very, uhm, shall we say, weak.

cool frameworks and Languages too!

When are programmers going to wake up and smell the coffee!

You are screwing around with peoples money. You cannot just slap the latest cool frameworks together, write 50 lines of connection code and call it a system.

I would be willing to bet that there is a single database credential that has rights to insert/update/delete/select on all the tables in the system and its is stored in some xml file that the web application has access to and if the web application has access to it so do all the people trying to break in.

I cannot begin to count just how many times I have seen the following:

select * from users where id=? and password=?

and that returns everything about the user. Every modern database supports either functions or procedures to do something like:

validate_user(uname,upass);

and it simply returns true or false, 1 or 0 nothing more, nothing less.

Far far to often I hear, lets use [ fill in the blank ] framework because that is what everyone else uses and besides look how much more productive we are! And so it is taken upon nothing more than faith and 90% of the time the people saying vehemently that that is the way to go, understand perhaps 10% of the framework code and don't investigate any further. When you are considering a framework that is 100's of thousands of lines of code that more then likely wouldn't pass the particular languages version of Lint or Bounds or any other validation tool you have already lost the security war.

The people who are actively trying to break into large systems do their homework! They spend weeks or months looking at your generated web code looking for patterns that reveal the underlying frameworks and then comb through that code looking for even the most subtle vulnerabilities and then they make a plan and execute it.

When you are building systems like this if you don't start with security as priority #1, for the entire stack you will lose, it is just a matter of time.

Sorry but this is not what I have in mind when I think of CV. This could be accomplished using hardware alone. All the pencils are very carefully lined up and running at a fixed rate past a sensor. The image is very small and all you have to look for is is the bit pattern representing the specific color then activate the solenoid for the puff of air.

When I have thought of CV, and it comes around often, the biggest problem I see is the randomness of the perspective view of the object. Take bowling ball for and place it anywhere. To the human who knows what a bowling ball is, it really does not matter what the perspective is. We recognize if based upon its general size, pattern of swirls, holes, scuffs on it and other factors in low light, bright light or even "normal" light.

Even an object that we have never seen before becomes fairly instantly recognizable if given only it's noun name.

The massive amount of information our brain "collects and stores" that allow us to do this is in its level of complexity so completely beyond anything we have ever done in silicon it might as well be magic.

A match made in hell!

I Invite you to watch this. http://youtu.be/d9r3H4iHFZk

The risk of en-route collision is really, really small.

this risk of collision increases exponentially as all the planes bound for JFK, Newark, LaGuardia, LAX, SFO etc. get closer to the airport. I live in the SF Bay Area, on busy flight night and there is no fog you can see them lined up for landing for miles and miles, two abreast on the approach to 28L/R and that is when you can't have every pilot deciding for themselves what order they go in and how far apart they are.

As for TCAS it is a good thing, but it has limits as to how much information if gives you. 500ft below at 270 relative to you, and in a landing pattern or executing the published missed approach it is just not good enough when 400 peoples lives are on the line.

As far as en-route goes everyone is going to be trying to fly the least cost route from say KLAX to KJFK. With the volume of flights getting larger and larger how long do you give it before the pissing matches start over who gets the route in that time slot?

You can only land so many planes at a given airport in n amount of time. If everyone gets there at around the same time the sequencing for landing is going to be way to hairball.

The PHB's should never, ever, be in charge of something like this.

Well besides being a single point of failure I can't really see what could possibly be wrong with that.

In an airliner you have several screens that can display and particular set of indicators, and as was previously mentioned, as analog guages, in a small plane you are lucky if you have two, but generally speaking you only have one and they are not so very big.

Of all the studies of human factors in operating hi performance equipment in possibly dangerous situations airplane cockpits are probably the most intensely studied, so I think I will take their results coupled with my own experience and stick to analog guages for flying.

I am a pilot and for the most part every guage in the plane points straight up to 12 o'clock when things are normal

With one glance I can tell that everything is running fine, I don't have to think, I just look and in a busy cockpit that can mean the difference between life and death. If I am shooting an IFR approach down to minimums I have a very rapid scan of a very few instruments and every 5th scan or so it is a full panel scan so I know that among other things, the vacuum pump suction level is correct, and it is normally on the other side of the cockpit ( small planes). Everything pointing straight up, yep all is well, back to my limited IFR scan.

That phrase is quickly turning into the newest oxymoron.

Hey I know lets stitch together these 8 completely open and utterly un-certifiable frameworks, have everything talk to each other through XML files, store high value passwords in them so we can just look at the database like a black box. Then lets expose all that to the world of hackers and madmen and then act surprised when we discover its been broken into!

And then that cock sucker Jim Manzi decided if you can't beat them with your software, take the massive cash you have in the bank and suit them into bankruptcy IN Boston with a hand picked Judge all nice and paid for. To this day, if I see him I will hit him square in the nose as hard as I can and dance over him while he bleeds.

Borland eventually won in court but not until after they had been bled of their cash to defend the suit and had sold Quattro of to Novell ( dumbest thing that Uncle Ray ever did perhaps except trusting Microsoft ) where it languished before being sold to Correl .

I think that it is very context dependent. Think of it this way:

You have an instrument monitoring something, it is remote. You poll it every hour. In the first 10 hours you get some values. One of those values is zero (0) and that is a valid value for that particular measurement. In second 10 hours you notice you have some null's. Should I interpret those as zero or should I interpret those as no data acquired ?

I do know that Oracle will not count null values when doing any kind of averaging.

As someone who is a programmer, but had never had an Apple Desktop or Laptop until my wife and son got me one for Christmas this pas year I have to say X-Code needs more polish.

I say this because I was / Am a heavy user of Delphi ( Yup Object Pascal ). You might think OP is a toy but you could not be more wrong, but that is another argument. What I can say definitively is that Borland and now Embarcadero know how to do an IDE better then just about anything I have ever seen.

Apple needs to take a page out of their playbook. In Delphi when you add a component to a form, it adds ALL the code that you need to the unit that is handling the form. A simple double click on the element adds the code shell for that particular action, either from the object browser or from the form. You simply write the code that makes that action do what it needs to do, nothing else.

Now contrast this with X-Code... It will let you drag a component onto a form, in iOS Mavericks or whatever, but after that you have to and start screwing around in .h files, adding this adding that just so that element will be recognized and will compile. Couple that with the syntax of Objective C and you have a program that can only be written by someone who fairly in-depth knowledge of Objective C. I mean not they should not have to have that knowledge but it should not be a requirement to do basic forms and the like.

As it is mentioned, using the "Story Board" concept you can only write very simple apps that don't accomplish a whole lot. So while Apple is getting there they have a lot of ground to cover.