I'm a proponent of teaching C/C++. If you know those, you can learn Python, Java and PHP. Visual Basic is not a consideration nowadays.

Regardless of language, teach proper logic. A good coder in any language will have a better run time than a bad coder in any language.

As a person in a place to teach, I truly urge you to teach logic before syntax. Logic before language. It's very important.

I can see why you, with 20/20 wouldn't consider it a necessary or cost effective benefit.

That's kind of the point here.

Every job I've ever worked for has a vision plan with annual or bi-annual exams and lenses+frames. My current company has VSP.

It's not a dream world. You should probably ask your employer why they don't offer something or check your regular medical to make sure vision isn't covered by some sort of wellness plan.

I own the book, but I have not read it.

I am off to found an MIT startup.

People do realize they are paying for this, right? I mean. I pay you to teach me. I am not required to learn. In fact, I can fail entirely and have absolutely no return on my monetary investment.

I am going through my collegiate rounds as we speak. I hit it a dozen years into the workforce, but I am actually attending Virginia colleges, as it so happens. If my school bans laptops, only the laptop banned will own... wait a minute.

Actually, no, just screw them. Yeah. It's about professors not actually teaching well enough to pass the class. Professors in minor colleges are actually rated by how many people pass. Heard of a sliding, curved, or otherwise skewed grade?

The curve is so bent over now that it resembles a circle, and these professors are still not rating well. They are not teaching or adapting well either.

Let's just blame the laptop. Accuse the paying students and ignore the fact that the entire system is broken. Sounds good.

You've never visited a rural area, have you? Draw a circle even 50 miles around a major population center and I guarantee there are pockets where people live and can't get broadband.

Just because cities are covered, it doesn't mean everyone is. I do admit that it is becoming less of an issue even in small towns, but any time I go back to Willis Texas, I am reminded that "DSL doesn't cover it and the cable company won't go there". Once again, just because you look around and find it to be quite available, it doesn't mean everyone does. We're a really big country.

Have any of you tuned in to over-the-air television recently? Imagine that, but with the internet.

The FCC would be doing it's job properly to open a range in the spectrum to public internet, license it to qualified providers, and then play watch dog over it.

If you're worried about internet wardrobe malfunctions being banned, and you should be, then you should stop with the grumbling and get behind this movement while promoting freedom of speech and expression on the internet as it always has been.

Just because Cable TV has more channels, that doesn't mean it's the only way to tune in. Trust me, I know. I grew up in an area that you couldn't actually get cable. Which also means I couldn't get broadband.

Eventually we will all have to get used to the idea that the internet is a utility in the sense that it drives commerce and carries public concern. It's our modern electricity. It has to be made available to everyone for us to continue as an equal society. The government will become involved. It's up to us to determine whether that's in a fashion like our current electric and telecom monopolies or in a more acceptable manner.

Application Layer is meant to handle business logic and does indeed have a purpose.

Here is a basic example pulled off the top of my head;

Business Requirement:
===
First Name field should be under 51 characters, contain at least one vowel.
Last Name field should be under 51 characters, contain at least one vowel.
Address1 field should be under 251 characters, contain at least one vowel, and not match first or last name.
===

Client side is more about UX than enforceable data validation, so it is intentionally not covered but would go here.

Once submitted by the client you have to write logic to enforce the business logic and move on to proper typing.

Application Layer:
===
firstName is the First Name field, should be a STRING under 51 characters and contain at least one vowel.
lastName is the Last Name field, should be a STRING under 51 characters and contain at least one vowel.
address1 is the Address1 field, should be a STRING under 251 characters, contain at least one vowel and not match first or last name
===

That goes on to the data layer which doesn't necessarily know or care that First Name needs to have a vowel, or that Address1 shouldn't be the same as either name.

Data Layer:
===
String variable firstName is parameter @firstName and must be varchar(50)
String variable lastName is parameter @lastName and must be varchar(50)
String variable address1 is parameter @address1 and must be varchar(250)
===

Your data layer should know something is not right if firstName comes in typed as an int, or is a string over 50 characters. It should gracefully decline the request because that's not what it's there to package and ship out.

This leads to the database.

Database:
===
@firstName is arriving as varchar(50)
@lastName is arriving as varchar(50)
@address1 is arriving as varchar(250)
===

If the above isn't met, the Database will tell the Data Layer which will tell the Application Layer and it will either inform the Client or log it away for later reflection.

If you didn't have the Application Layer validation you'd not know that Address1 can't match First Name which has to have a vowel. If you didn't have the Data Layer, you'd not be able to take the result of that computation and pass it on to the Database. It all works together and is there whether you departmentalize it or not. You just may be skipping a step that you should be doing and not realize that you're intertwining areas that should be kept separate for the reasons stated above.

Client side is irrelevant as you noted (1).

The job of your application, in the case where you retrieve information from an external source that has potential for SQL Injection, is to ensure the information passed to your database (4) is as clean and well typed as possible.

Remember that we are talking about web applications of the sort that there will be user interaction, manipulation of data, and then a hand-off to a database. If you have an application that does not follow this, then you probably aren't in the SQL Injection high threat zone.

Application layer (2) and data layer (3) are concepts, but can be implemented in any language, with level of built-in support dictated by the language or framework itself. They are important in web applications to handle the tasks they are designed for. Application layer or business layer (2) takes care of general logic and application level computation such as ensuring the field "UserID" isn't actually a bunch of Viagra spam. Once your business rules are satisfied, your data layer takes the information passed to it, ensures that "UserID" indeed is a GUID as anticipated and prepares it for the database, which means paramaterizing it as the type of data you want to pass.

The database (4) is then responsible for accepting the paramaterized data and checking type to ensure what was passed is actually the type of data expected for the procedure or execution initiated.

You'll have to keep in mind, once again, that we are talking about web applications. You can remove client side (1) completely for some back-end tasks, but you can not remove the application layer (2). Something is going to be done with that data. It is going to be used in some way. You also can not remove your data layer (3) even if it is so integrated or procedurally coded that there is no separation from the application layer, it exists. You are passing the data to the database in some way. Application layer and data layer are where you have the responsibility and opportunity to scrub the data and validate it before giving it over for execution. That is what I mean when I say you can have a medium level of confidence by relying on Application and Data layers. They are your work horses.

As stated before. You can not choose any one area and consider it good enough. Just because the database (4) recieves a GUID as verified and passed by the data layer (3), it doesn't mean it's the right GUID, as that is the responsibility of the application layer (2) which leaves client side (1) to do some minimal work to help users enter the right data in the first place.

I know I've said it twice before, but we are only talking about web applications, and more specifically, those vulnerable to SQL Injection in the first place. A web service consumed directly by a series of database executions does not count, but even in that case, the general rules apply. Your application, data, and database layers are simply integrated. Just because your application logic is in a DTS and several stored procedures, doesn't mean you don't have any application logic at all.
 

I go through this all of the time. Though I call it laziness, it is actually a combination of ignorance, indignation, and laziness.

Here is a very, very, very simple and very, very, very standard way of keeping SQL injections out. Validate everything at every level. There you go. Done.

1) Client side matters. Check input, validate it and pass it through to the application layer.
2) Application layer matters. Check variable, strictly type it, validate it and pass it through to your data layer.
3) Data layer matters. Check argument against strict type, validate it, paramaterize it, and pass it off to the database.
4) Database matters. Check paramater against strict type, validate it, and run it.

You run into problems when someone only follows any one of the steps above. You could handle it with a medium level of confidence in areas 2 and 3 (and if you're asking why not 1 and 4, go sit in the corner while the grown-ups talk), but good practice for keeping it clean is validate it at every layer. That doesn't mean every time you touch the information you have to recheck the input, but every time it moves from one core area of the platform to another or hits an area it could be compromised, you do.

As I said above, the only reason for not following 1-4 is laziness, ignorance, or indignation. SQL injections aren't hard to keep out.

We're in an age where web development IS enterprise level programming and developers need to treat it as such.

There, I just saved your organization millions of dollars. Go get a raise on my behalf or something.

Not all books, films, or games need to wrap everything up in one installment. Pick up Fellowship of the Ring sometime and let me know how much you would enjoy the series if you stopped right there. Do the same with any other famous trilogy or long running series. The Empire Strikes Back certainly didn't end with everything tidied up in the story-arc department.

Just because we've become used to single, stand-alone, do it once and be done with it video game packages, doesn't mean they all have to be that way, or that entertainment in general is best appreciated in that format.

I personally enjoy when a game remains open-ended. I don't mind cliffhanger endings as long as the experience is rewarding. The key is making the experience rewarding. That's the reason I purchase games like Dragon Age. I want the game to continue. I want the expansions and extended content. It's the same reason I read series like Game of Thrones. I like my characters and established universe to keep going.

That isn't to say you can't have story in there with pivotal points, such as the climax of Dragon Age, or the end of A Song of Fire and Ice, but I know in each case that there will be more to come, and it isn't over. That's a good thing if done properly.

There's room for both sorts of stories. There always has been and there always will be.

Understood. I may not qualify as a certified engineer, after all my parents are married. I couldn't even be a practicing engineer, as they are married to each other.

That aside, there is such a thing as CMMI maturity level for an organization of software engineers. Look into it. You'll see that being a software engineer by trade, and not just random corporate title, is a bit more than printing up some business cards.

I am a software engineer by trade. Note, I do not call myself a programmer, as that has an entirely different tone to it.

I can see where recruiting young engineers would be best. When I was 20, I was a sharp network engineer (again engineer) working on integrating a section of the Exxon and Mobil servers when they merged. At that time I was also studying several translations of the christian bible trying to find meaning in life.

I can see how someone with an analytical mind, logical training, and a sort of philosophical interest could be of use to nearly any cause.

Quite a few years later I am married, have a good life, and gave up the network bit for my hobby (coding). I am back in college, aiming for a degree that matters to me and now am much less prone to theological stints. Wisdom comes with age.

If you catch the young engineer while he's figuring out the world, yeah, he may just sign on for [random cause].

Who says "MSN Email"? For that matter, who says MSN anymore?

No wonder you have issues with open source development. You obviously work for Microsoft.

You can't interchange consumer with supplier. The theater is a supplier. The individuals sitting in the seats are the consumers.

Should Bob, 3rd row, center aisle #24 be responsible for his license in this scenario? No. He's the consumer.

Should Ed, manager of local franchise be responsible for ensuring his theater has the proper rights to display the movie? You bet.

The consumer got screwed by the supplier in this instance.