Why Web Programming is so Challenging and Different

[Frankie]

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely
no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[KMA]

I think point 3 has to be rammed home good and hard. With emphasis on
connectionless state management techniques. Make it so.
"Frankie" <Ta******@BeanTown.org> wrote in message
news:#X*************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Kevin Spencer]

I believe you've hit on the "biggies" in the list. In particular, it is
important to explain the stateless nature of the HTTP Request/Response
model, and how the ASP.Net IHttpHandler interface and derived classes (exp.
System.Web.UI.Page) are designed to deal with it. I would also explain fully
the object model for System.Web.UI.Control. With a good grasp of these
models, they should have a good head start.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely
no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Damien]

Frankie wrote:

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely
no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

Make sure to include plenty of examples for (2) of where Windows Forms
developers get confused. Plenty of examples in the newsgroups of people
trying to do things to the client when the session times out... Here in
our shop, we had a guy starting a timer, and then expecting to be able
to update some controls when the timer event fired... (At least he'd
found the Timer in the Components rather than from the Windows Forms
tab, so I give him some credit)

It seems (to me) to be the biggest break that people have difficulty
making. Not to say that the others aren't valuable points too.

Damien

[Karl Seguin]

Personally, I think the biggest reason web programming is challenging is
because of the "programmers" themeselves. Until recently, web programming
meant you were without OO or N-Tier. I've seen many classic asp
"programmers" not be able to make the proper switch to ASP.Net. Based on
your description of the programmers you are training, you'll most definetly
need to go over the list of items you have, but you might also need to go
over fundamental OO/mapping/N-Tier practices. These are things well
outside of the scope of the ASP.Net technology, but absolutely necessary to
enterprise ASP.Net development.

karl

--
MY ASP.Net tutorials
http://www.openmymind.net/
"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely
no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[John Timney \(ASP.NET MVP\)]

A good choice of subjects to cover, you missed a really important one in
that you dont specifically focus on IIS or another web server as a topic.
Language aside - many problems in web development come from not
understanding your environment. For example, even if you didn't have
asp.net installed your web server would still render html output but things
like state management become pretty irrelevent....and of course this is a
typical FAQ problem.

I would also make sure I included the pipeline for asp.net which elaborates
the relationship in which events fire during any asp.net web request.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with absolutely
no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Jon Paal]

I would differ with your statement about going over concepts "before jumping into code".

showing concepts will likely only make a connection when illustrated through coding examples.

Every book I've ever read always showed code (preferably working examples) to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff programmers on ASP.NET. These guys have only Mainframe, MS
Access, SQL Server, and VB6 desktop application development experience (with absolutely no HTML or Web application experience).

Before jumping into any code I think it's important to get them to understand the fundamental differences and unique challenges
presented by Web application development (independent of any particular application technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover early on. I'd appreciate your feedback on this list -
please let me know anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Frankie]

Hi Jon,

Check out this book, "Code Complete" by Steve
http://tinyurl.com/d8mgr

Practically no code whatsoever - anywhere. The best programmers I've met all
recommend this book prececely because it talks about the context in which we
write code - independent of any particular language or platform. It will
help you write better code in *any* language or platform without diving into
any code or illustrating very many points with sample code (there are a few
here and there - but very few).

Or this book, "C# and the .NET Platform by Andrew Troelsen (more of a
"hands-on" programmers book focused squarely on .NET and specifically the C#
language).
http://tinyurl.com/c3co3

Chapter 1 title: "The Philosophy of .NET"
Apparently that award winning author prioritizes direction over pace.
Or the book "SQL Queries for Mere Mortals" by Hernandez and Viescas.
http://tinyurl.com/76how
It's a total beginners book on SQL.
The first 3 chapters give background and perspective. The first query comes
in chapter 4.

Hummmmmm...

These are all award winning books - from general programming to specific,
and from advanced to beginner levels. They must be doing something right.

You can certainly learn a lot about a forest by studying the trees first.
But sometimes you can study the forest, itself.
-- All this FWIW...


"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

I would differ with your statement about going over concepts "before
jumping into code".

showing concepts will likely only make a connection when illustrated
through coding examples.

Every book I've ever read always showed code (preferably working examples)
to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with
absolutely no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented by
Web application development (independent of any particular application
technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover
early on. I'd appreciate your feedback on this list - please let me know
anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Jon Paal]

I guess you didn't really want any feedback ....
"Frankie" <Ta******@BeanTown.org> wrote in message news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi Jon,

Check out this book, "Code Complete" by Steve
http://tinyurl.com/d8mgr

Practically no code whatsoever - anywhere. The best programmers I've met all recommend this book prececely because it talks about
the context in which we write code - independent of any particular language or platform. It will help you write better code in
*any* language or platform without diving into any code or illustrating very many points with sample code (there are a few here
and there - but very few).

Or this book, "C# and the .NET Platform by Andrew Troelsen (more of a "hands-on" programmers book focused squarely on .NET and
specifically the C# language).
http://tinyurl.com/c3co3

Chapter 1 title: "The Philosophy of .NET"
Apparently that award winning author prioritizes direction over pace.
Or the book "SQL Queries for Mere Mortals" by Hernandez and Viescas.
http://tinyurl.com/76how
It's a total beginners book on SQL.
The first 3 chapters give background and perspective. The first query comes in chapter 4.

Hummmmmm...

These are all award winning books - from general programming to specific, and from advanced to beginner levels. They must be doing
something right.

You can certainly learn a lot about a forest by studying the trees first. But sometimes you can study the forest, itself.
-- All this FWIW...


"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message news:Oc**************@tk2msftngp13.phx.gbl...

I would differ with your statement about going over concepts "before jumping into code".

showing concepts will likely only make a connection when illustrated through coding examples.

Every book I've ever read always showed code (preferably working examples) to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message news:%2***************@tk2msftngp13.phx.gbl...

I have been hired to go to a former client of mine and train their staff programmers on ASP.NET. These guys have only Mainframe,
MS Access, SQL Server, and VB6 desktop application development experience (with absolutely no HTML or Web application
experience).

Before jumping into any code I think it's important to get them to understand the fundamental differences and unique challenges
presented by Web application development (independent of any particular application technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to cover early on. I'd appreciate your feedback on this list -
please let me know anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Frankie]

Sorry Jon, didn't mean to offend. I understand and agree with your point
that sample code can be very helpful in making connections between concepts
and practice. I was just trying to make the point that sometimes code isn't
the best place to start. Perhaps others reading this thread who are new to
Web programming (and there are a LOT who show up in this group) - might
benefit from seeing a short list of concepts to be grasped and see how
important it is to understand those concepts before "diving into the code."
That's all my response was really all about. So many self-proclaimed
"newbies" get to coding before they understand any concepts and then post
dozens of questions here that, if they took just a couple of hours even to
read up on some fundamentals, might never have to post the questions and
experience the frustration that lead up to the posts.

-F
"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Ow**************@tk2msftngp13.phx.gbl...

I guess you didn't really want any feedback ....
"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi Jon,

Check out this book, "Code Complete" by Steve
http://tinyurl.com/d8mgr

Practically no code whatsoever - anywhere. The best programmers I've met
all recommend this book prececely because it talks about the context in
which we write code - independent of any particular language or platform.
It will help you write better code in *any* language or platform without
diving into any code or illustrating very many points with sample code
(there are a few here and there - but very few).

Or this book, "C# and the .NET Platform by Andrew Troelsen (more of a
"hands-on" programmers book focused squarely on .NET and specifically the
C# language).
http://tinyurl.com/c3co3

Chapter 1 title: "The Philosophy of .NET"
Apparently that award winning author prioritizes direction over pace.
Or the book "SQL Queries for Mere Mortals" by Hernandez and Viescas.
http://tinyurl.com/76how
It's a total beginners book on SQL.
The first 3 chapters give background and perspective. The first query
comes in chapter 4.

Hummmmmm...

These are all award winning books - from general programming to specific,
and from advanced to beginner levels. They must be doing something right.

You can certainly learn a lot about a forest by studying the trees first.
But sometimes you can study the forest, itself.
-- All this FWIW...


"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

I would differ with your statement about going over concepts "before
jumping into code".

showing concepts will likely only make a connection when illustrated
through coding examples.

Every book I've ever read always showed code (preferably working
examples) to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with
absolutely no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented
by Web application development (independent of any particular
application technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to
cover early on. I'd appreciate your feedback on this list - please let
me know anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Kevin Spencer]

>I guess you didn't really want any feedback ....

You guess incorrectly. Frankie wants USEFUL feedback. The problem with your
feedback is that you are advocating "jumping into code" as an initial part
of the process of introducing experienced programmers, with procedural
programming experience, but little or no object-oriented programming
experience, and little or no knowledge of the HTTP web application
environment, to object-oriented and web application-oriented programming.

First, these people already know how to write code. They don't need code
examples to learn. What they lack is an understanding of the principles
involved in OOP and web application programming.

In the case of OOP, they need to re-adjust their thinking along OOP lines,
and that is quite a paradigm shift. It takes the concept of abstraction to a
whole new level. These people are used to thinking of an application as a
sequence of instructions. If they have used VB6, they may have had a small
taste of OOP concepts, such as classes and objects. If they have worked on
MainFrames, they have not. OOP is powerful, but only if you understand it
and can leverage its power. Why would one need a code example to illustrate
the concept of inheritance? I could illustrate it using any real-world
object, and the illustration would be both simpler and more appropriate, as
OOP teaches us to think in abstract, rather then concrete terms. An object
is not a set of instructions; it is a "thing." It is a "tool" which can be
"plugged into" an application, like plugging a speaker into a stereo system.
A swiss army knife inherits knife, in that it has a handle and a blade. But
it also has additional tools added to it, which extend its functionality.
Again, no code would make the concept clearer, only more complex to
understand. And OOP is all about hiding complexity. Which brings us to
encapsulation. Again, I could use a real-world example to illustrate the
concept much better than using code. Think about a car. It has an engine
which makes the car move. The engine is a complex device, full of complex
inner workings. But to use a car, you don't even need to know it HAS an
engine. All you need to know is the interface which the car presents to the
driver, i.e. the gas and brake pedals, and the ignition switch. As
abstraction is the final element in the concept, abstraction is best
illustrated WITH abstraction, such as talking about cars rather than code.

Again, with regards to web applications, the HTTP/HTML environment in which
an ASP.Net app runs, needs to be understood by these people. How would you
illustrate the Request/Response model, or the stateless nature of HTTP to a
group of people by having them write code, which they already know how to
do? I have often illustrated the stateless nature of HTTP as a pair of old
men with Alzheimers sitting on either side of a wall. Neither can remember
that last thing he said to the other, nor the last thing the other said to
him. They are passing notes back and forth to each other. The man on one
side (the "client" side) is requesting something from the man on the other
side (the "server" side). The man on the "server" side fetches it, and
passes it back to the man on the "client" side. Now the man on the client
side knows what he has, but decides he want to embellish it with something.
As the man on the "server" side doesn't remember what the man on the
"client" side requested last, the man on the "client" side must re-iterate
his request to the man on the "server" side, and add the embellishment to
his request. And so on.

In fact, I have often found that the "coding in the beginning" method is
actually more confusing. In the beginning, it is best to talk about
concepts, make sure the audience understands the concepts, and then begin
illustrating with code. Code is more about technique than about concept.
Code is the cart. Concept is the horse. The horse should always come before
the cart.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Ow**************@tk2msftngp13.phx.gbl...

I guess you didn't really want any feedback ....
"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi Jon,

Check out this book, "Code Complete" by Steve
http://tinyurl.com/d8mgr

Practically no code whatsoever - anywhere. The best programmers I've met
all recommend this book prececely because it talks about the context in
which we write code - independent of any particular language or platform.
It will help you write better code in *any* language or platform without
diving into any code or illustrating very many points with sample code
(there are a few here and there - but very few).

Or this book, "C# and the .NET Platform by Andrew Troelsen (more of a
"hands-on" programmers book focused squarely on .NET and specifically the
C# language).
http://tinyurl.com/c3co3

Chapter 1 title: "The Philosophy of .NET"
Apparently that award winning author prioritizes direction over pace.
Or the book "SQL Queries for Mere Mortals" by Hernandez and Viescas.
http://tinyurl.com/76how
It's a total beginners book on SQL.
The first 3 chapters give background and perspective. The first query
comes in chapter 4.

Hummmmmm...

These are all award winning books - from general programming to specific,
and from advanced to beginner levels. They must be doing something right.

You can certainly learn a lot about a forest by studying the trees first.
But sometimes you can study the forest, itself.
-- All this FWIW...


"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

I would differ with your statement about going over concepts "before
jumping into code".

showing concepts will likely only make a connection when illustrated
through coding examples.

Every book I've ever read always showed code (preferably working
examples) to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
I have been hired to go to a former client of mine and train their staff
programmers on ASP.NET. These guys have only Mainframe, MS Access, SQL
Server, and VB6 desktop application development experience (with
absolutely no HTML or Web application experience).

Before jumping into any code I think it's important to get them to
understand the fundamental differences and unique challenges presented
by Web application development (independent of any particular
application technology; asp, php, etc.).

Here are some of the unique challenges (or fundamentals) I plan to
cover early on. I'd appreciate your feedback on this list - please let
me know anything you think should be included that I missed.

1. HTTP (3-way handshake, etc.)
2. The request/response model
3. state management
4. Client-side logic and scripting vs. Server-side.
5. HTML and CSS (content and layout vs. styling)
6. Browser variations and limitations
Thanks!

-F

[Frankie]

Thanks Kevin - on all points. I especially like the Alzheimers analogy; I'll
be using it as a matter of course (pun intended!).

-F

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

I guess you didn't really want any feedback ....

You guess incorrectly. Frankie wants USEFUL feedback. The problem with
your feedback is that you are advocating "jumping into code" as an initial
part of the process of introducing experienced programmers, with
procedural programming experience, but little or no object-oriented
programming experience, and little or no knowledge of the HTTP web
application environment, to object-oriented and web application-oriented
programming.

First, these people already know how to write code. They don't need code
examples to learn. What they lack is an understanding of the principles
involved in OOP and web application programming.

In the case of OOP, they need to re-adjust their thinking along OOP lines,
and that is quite a paradigm shift. It takes the concept of abstraction to
a whole new level. These people are used to thinking of an application as
a sequence of instructions. If they have used VB6, they may have had a
small taste of OOP concepts, such as classes and objects. If they have
worked on MainFrames, they have not. OOP is powerful, but only if you
understand it and can leverage its power. Why would one need a code
example to illustrate the concept of inheritance? I could illustrate it
using any real-world object, and the illustration would be both simpler
and more appropriate, as OOP teaches us to think in abstract, rather then
concrete terms. An object is not a set of instructions; it is a "thing."
It is a "tool" which can be "plugged into" an application, like plugging a
speaker into a stereo system. A swiss army knife inherits knife, in that
it has a handle and a blade. But it also has additional tools added to it,
which extend its functionality. Again, no code would make the concept
clearer, only more complex to understand. And OOP is all about hiding
complexity. Which brings us to encapsulation. Again, I could use a
real-world example to illustrate the concept much better than using code.
Think about a car. It has an engine which makes the car move. The engine
is a complex device, full of complex inner workings. But to use a car, you
don't even need to know it HAS an engine. All you need to know is the
interface which the car presents to the driver, i.e. the gas and brake
pedals, and the ignition switch. As abstraction is the final element in
the concept, abstraction is best illustrated WITH abstraction, such as
talking about cars rather than code.

Again, with regards to web applications, the HTTP/HTML environment in
which an ASP.Net app runs, needs to be understood by these people. How
would you illustrate the Request/Response model, or the stateless nature
of HTTP to a group of people by having them write code, which they already
know how to do? I have often illustrated the stateless nature of HTTP as a
pair of old men with Alzheimers sitting on either side of a wall. Neither
can remember that last thing he said to the other, nor the last thing the
other said to him. They are passing notes back and forth to each other.
The man on one side (the "client" side) is requesting something from the
man on the other side (the "server" side). The man on the "server" side
fetches it, and passes it back to the man on the "client" side. Now the
man on the client side knows what he has, but decides he want to embellish
it with something. As the man on the "server" side doesn't remember what
the man on the "client" side requested last, the man on the "client" side
must re-iterate his request to the man on the "server" side, and add the
embellishment to his request. And so on.

In fact, I have often found that the "coding in the beginning" method is
actually more confusing. In the beginning, it is best to talk about
concepts, make sure the audience understands the concepts, and then begin
illustrating with code. Code is more about technique than about concept.
Code is the cart. Concept is the horse. The horse should always come
before the cart.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
I'd rather be a hammer than a nail.

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Ow**************@tk2msftngp13.phx.gbl...

I guess you didn't really want any feedback ....
"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@TK2MSFTNGP15.phx.gbl...

Hi Jon,

Check out this book, "Code Complete" by Steve
http://tinyurl.com/d8mgr

Practically no code whatsoever - anywhere. The best programmers I've met
all recommend this book prececely because it talks about the context in
which we write code - independent of any particular language or
platform. It will help you write better code in *any* language or
platform without diving into any code or illustrating very many points
with sample code (there are a few here and there - but very few).

Or this book, "C# and the .NET Platform by Andrew Troelsen (more of a
"hands-on" programmers book focused squarely on .NET and specifically
the C# language).
http://tinyurl.com/c3co3

Chapter 1 title: "The Philosophy of .NET"
Apparently that award winning author prioritizes direction over pace.
Or the book "SQL Queries for Mere Mortals" by Hernandez and Viescas.
http://tinyurl.com/76how
It's a total beginners book on SQL.
The first 3 chapters give background and perspective. The first query
comes in chapter 4.

Hummmmmm...

These are all award winning books - from general programming to
specific, and from advanced to beginner levels. They must be doing
something right.

You can certainly learn a lot about a forest by studying the trees
first. But sometimes you can study the forest, itself.
-- All this FWIW...


"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...
I would differ with your statement about going over concepts "before
jumping into code".

showing concepts will likely only make a connection when illustrated
through coding examples.

Every book I've ever read always showed code (preferably working
examples) to illustrate the concept.

"Frankie" <Ta******@BeanTown.org> wrote in message
news:%2***************@tk2msftngp13.phx.gbl...
>I have been hired to go to a former client of mine and train their
>staff programmers on ASP.NET. These guys have only Mainframe, MS
>Access, SQL Server, and VB6 desktop application development experience
>(with absolutely no HTML or Web application experience).
>
> Before jumping into any code I think it's important to get them to
> understand the fundamental differences and unique challenges presented
> by Web application development (independent of any particular
> application technology; asp, php, etc.).
>
> Here are some of the unique challenges (or fundamentals) I plan to
> cover early on. I'd appreciate your feedback on this list - please let
> me know anything you think should be included that I missed.
>
> 1. HTTP (3-way handshake, etc.)
> 2. The request/response model
> 3. state management
> 4. Client-side logic and scripting vs. Server-side.
> 5. HTML and CSS (content and layout vs. styling)
> 6. Browser variations and limitations
>
>
> Thanks!
>
> -F
>

[Jon Paal]

I see, so it's "useful" only if it agrees or supports what your saying .
================================================== ===============
"The highest courage is to dare to be yourself in the face of adversity.
Choosing right over wrong, ethics over convenience, and truth over
popularity.. These are the choices that measure your life. Travel the path
of integrity without looking back, for there is never a wrong time to do the
right thing."

[Kevin Spencer]

>I see, so it's "useful" only if it agrees or supports what your saying .

No, what you're saying is only "useful" if it is true.

Not everything is a matter of opinion. There are a few facts in this world.
And one of the nicest things about facts is that nobody owns them, unlike
opinions. You own your opinions. Facts belong to nobody, and nobody can take
credit for them, or feel insulted when somebody disagrees with them.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
I'd rather be a hammer than a nail.

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:ez**************@TK2MSFTNGP14.phx.gbl...

I see, so it's "useful" only if it agrees or supports what your saying .
================================================== ===============
"The highest courage is to dare to be yourself in the face of adversity.
Choosing right over wrong, ethics over convenience, and truth over
popularity.. These are the choices that measure your life. Travel the path
of integrity without looking back, for there is never a wrong time to do
the
right thing."

[Frankie]

Jon,
I really liked your quote about being "...yourself in the face of
adversity...."

It appears that you are unhappy because Kevin and I offered some rational
reasons to take a different path than the one you advocate. Kevin went to
some length to explain his view in rational terms - and so did I in my
initial response to you.

You, on the other hand, offered 3 points:
1. That you have a different perspective ("jump into code right away")
2. Illustrating concepts with code facilitates understanding
3. Books you have read always show code to illustrate concepts.

Point #1, by itself, is not at all useful unless you back it up with sound
reasoning. *Sound reasoning* (and not whether it is agreed upon) is what
could make your view useful .
Point #2 it simply a true statement. Nobody here disagrees with it.
Point #3 is assumed to be true (we have no reason to suspect that you would
lie to us about all the books you have read). True as it may be, it does
nothing to support or back up point #1 or #2 UNLESS the books *omit*
introductory information and dive right into the code. I doubt they do that
and you didn't even claim that they do it. All your book reference does for
you - possibly - is support your point #2.

Then you proceed in subsequent threads to support the conclusion that "Jon
Paal must be agreed with, otherwise he will think that the OP isn't really
wanting help".

That's too bad. All you needed to do was back up your Point#1 with some
rational argument or evidence. You didn't do that in your initial post.
Since then, you have still failed to do that; and when confronted with
rational argument (ala Kevin Spencer) and evidence (my book recommendations)
to support a point of view that is contrary to yours, you just got upset and
metaphorically dug your heels in to your emotional point of view by
including that little quote about "the highest courage..."

I will happily agree with your if you can convince me through rational
argument. You didn't offer any. Do you have the courage to come up with some
*rational* discourse?

.... still listening....

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:ez**************@TK2MSFTNGP14.phx.gbl...

I see, so it's "useful" only if it agrees or supports what your saying .
================================================== ===============
"The highest courage is to dare to be yourself in the face of adversity.
Choosing right over wrong, ethics over convenience, and truth over
popularity.. These are the choices that measure your life. Travel the path
of integrity without looking back, for there is never a wrong time to do
the
right thing."

[Jon Paal]

Sounds as if you have your mind made up and now you're trying to rationalize your position with some argument about "facts".

The original request was for some "feedback". Feedback is a response that can be either negative or positive. It is definitely not
constrained to being factual.
=========================================
Faith is easy, no thought required

[Frankie]

Jon,

The original post was specifically... "I'd appreciate your feedback on this
list "

You didn't give feedback on the list. And you still haven't.

-F

"Jon Paal" <Jon nospam Paal @ everywhere dot com> wrote in message
news:Oz**************@TK2MSFTNGP09.phx.gbl...

Sounds as if you have your mind made up and now you're trying to
rationalize your position with some argument about "facts".

The original request was for some "feedback". Feedback is a response that
can be either negative or positive. It is definitely not constrained to
being factual.
=========================================
Faith is easy, no thought required

[Jon Paal]

I'll repeat for you what I told kevin.

The original request was for some "feedback". Feedback is a response that can be either negative or positive. It is definitely not
constrained to being factual.

When you ask for feedback, it's makes no sense to argue with those who are willing to spend the time and make the effort to provide
it. When you ask for feedback and someone makes the effort to provide it, the normal response is "Thank you". Whether or not
you agree with the feedback is irrelevant.
Regarding the "3 points", these are not independent, but related:
================================================== ========

1. That you have a different perspective ("jump into code right away")
---------------------------------------------------------------------------------------------
Believe it or not , it's okay to have a different perspective.
2. Illustrating concepts with code facilitates understanding
--------------------------------------------------------------------------
I believe this to be very true and offered it in support of point 1.
3. Books you have read always show code to illustrate concepts
-----------------------------------------------------------------------------------
Yes this is true. For example, ASP.net Unleashed, chapter 1 includes a simple asp.net web page. No, it's not the first sentence in
the chapter, or the book, but it's there early on to illustrate the concepts being discussed or about to be discussed. I offered
this in support of points 1 and 2.
I think you're over-analyzing my comments and getting bogged down in minutia.

It's feedback.

[Frankie]

Jon,

The original post was specifically... "I'd appreciate your feedback on this
list "

You didn't give feedback on the list. And you still haven't.

-F