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" <kevin@DIESPAMMERSDIEtakempis.com> wrote in message
news:%23VyDkSqvFHA.2516@TK2MSFTNGP12.phx.gbl...[color=blue][color=green]
> >I guess you didn't really want any feedback ....[/color]
>
> 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:OwKiSMovFHA.3756@tk2msftngp13.phx.gbl...[color=green]
>>I guess you didn't really want any feedback ....
>>
>>
>> "Frankie" <TacoTime@BeanTown.org> wrote in message
>> news:%23H1xb$jvFHA.460@TK2MSFTNGP15.phx.gbl...[color=darkred]
>>> 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$$QijvFHA.2960@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" <TacoTime@BeanTown.org> wrote in message
>>>> news:%23XVZYXbvFHA.908@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
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]
