Codesmith vs. Hand coding

[M.Siler]

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?

[Cor Ligthert [MVP]]

Re: Codesmith vs. Hand coding

John,

If it is not there, you should write it yourself.
(Whatever way you do that by making your own classes, controls, components,
jus copying or whatever)

It will never be clever to write forever again and again the same code.
However, I will not say that one solution is the best.

Just my thought about your question.

Cor

"M.Siler" <John.Doe@NoSpa m.comschreef in bericht
news:e06RgPrxGH A.2168@TK2MSFTN GP06.phx.gbl...

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position
is Codesmith is for junior to mid level developer who perfer "wizards" to
write code for them. That these types of code generators produce
substandard developers who don't have real skills. I don't have a position
one way or the other until I have a bit more information, but if I was to
take the other point of view... Is there value in utilizing something like
Codesmith to generate the bases of some code and then to customize it from
there?
>

[Jan Hyde]

Re: Codesmith vs. Hand coding

"M.Siler" <John.Doe@NoSpa m.com>'s wild thoughts were
released on Wed, 23 Aug 2006 08:58:46 -0400 bearing the
following fruit:

>I'm trying to get my head around a conversation I had with a developer the
>other day. We were talking about Codesmith vs. Hand coding. He's position is
>Codesmith is for junior to mid level developer who perfer "wizards" to write
>code for them. That these types of code generators produce substandard
>developers who don't have real skills. I don't have a position one way or
>the other until I have a bit more information, but if I was to take the
>other point of view... Is there value in utilizing something like Codesmith
>to generate the bases of some code and then to customize it from there?
>

Back in VB6 I always used the wizard to produce the base
code for my usercontrols. Every other wizard I'd used
produced code that was rubbish and so with that one
exception I've always coded things myself.

If the wizard saves you time then it's a good thing, but if
you end up rewritting most of it then don't bother.



Jan Hyde (VB MVP)

--
Consummate: To pull the wool over the eyes of a spouse. (Cynthia MacGregor)

[dermot]

Re: Codesmith vs. Hand coding

I think code generation then customisation is good. This is the case
if a lot of your projects are similar.

I wrote my own code generation utility which from a database (SQL
Server) produces:

tableAdapter + data access layer
business objects
windows forms

I then customise these for each application, and find it really speeds
up my delveopment.

Jan Hyde wrote:

"M.Siler" <John.Doe@NoSpa m.com>'s wild thoughts were
released on Wed, 23 Aug 2006 08:58:46 -0400 bearing the
following fruit:
>

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?

>
Back in VB6 I always used the wizard to produce the base
code for my usercontrols. Every other wizard I'd used
produced code that was rubbish and so with that one
exception I've always coded things myself.
>
If the wizard saves you time then it's a good thing, but if
you end up rewritting most of it then don't bother.
>
>
>
Jan Hyde (VB MVP)
>
--
Consummate: To pull the wool over the eyes of a spouse. (Cynthia MacGregor)

[Patrice]

Re: Codesmith vs. Hand coding

AFAIK :
- CodeSmith is a general purpose generator i.e. you can create templates
that will generate the code as YOU wish
- Wizards are creating "standard" code that is generated as is and you
generally can't customize the generation process

I tend myself to not use Wizards and would likely write some code to create
personalized source code rather than using something like CodeSmith.

But I don't think this is an all or nothing approach. Let's use what best
fit (for example I'm using of course the UI designer that after all just
creates some code, would he want to write the UI code by hand rather than
hebing the VS designer doing this for him and if he needs to code over and
over again slight variations of the same code, would he code by hand rather
than automating this code generation by using CodeSmith or his own generator
?)

--
Patrice

"M.Siler" <John.Doe@NoSpa m.coma écrit dans le message de news:
e06RgPrxGHA.216 8@TK2MSFTNGP06. phx.gbl...

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position
is Codesmith is for junior to mid level developer who perfer "wizards" to
write code for them. That these types of code generators produce
substandard developers who don't have real skills. I don't have a position
one way or the other until I have a bit more information, but if I was to
take the other point of view... Is there value in utilizing something like
Codesmith to generate the bases of some code and then to customize it from
there?
>

[UhihaJax]

RE: Codesmith vs. Hand coding

So would this guy manually write strongly typed datasets?
How long would that take?

"M.Siler" wrote:

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
>
>
>

[Mini-Tools Timm]

RE: Codesmith vs. Hand coding

"M.Siler" wrote:

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?

Codesmith--like the Visual Studio IDE--is just another tool to help you work
faster and more efficiently. Your developer friend's belief that you have to
manually write all the code yourself to show that you "have real skills" is
foolish. The users of your software are not going to care what tools you
used. But they will care whether your software meets their needs and was
delivered on time and with quality. Does a carpenter lack real skills
because he chooses to use a power nail driver instead of pounding in each
nail by hand with a hammer?

--
Timm Martin
Mini-Tools
..NET Components and Windows Software

http://www.mini-tools.com

[M.Siler]

Re: Codesmith vs. Hand coding

We use strongly typed datasets and I believe was one of the big reason for
CodeSmith... this guy doesn't like the constraints strongly typed datasets
impose.


"UhihaJax" <UhihaJax@discu ssions.microsof t.comwrote in message
news:E0D997C8-BD0D-416E-A554-5B35B8E386F3@mi crosoft.com...

So would this guy manually write strongly typed datasets?
How long would that take?
>
"M.Siler" wrote:
>

>I'm trying to get my head around a conversation I had with a developer
>the
>other day. We were talking about Codesmith vs. Hand coding. He's position
>is
>Codesmith is for junior to mid level developer who perfer "wizards" to
>write
>code for them. That these types of code generators produce substandard
>developers who don't have real skills. I don't have a position one way or
>the other until I have a bit more information, but if I was to take the
>other point of view... Is there value in utilizing something like
>Codesmith
>to generate the bases of some code and then to customize it from there?
>>
>>
>>

[Kevin Spencer]

Re: Codesmith vs. Hand coding

It seems to me that the argument is invalid. You say that the issue is
CodeSmith vs. Hand Coding. Where is it written that you must use one
exclusive of the other?

The real question is, how much should you use any tool that writes code for
you, and how much should you write by hand?

Tools that write code for you will write boiler-plate code. This is good in
some situations, and not so good in others. Because boiler-plate code is
tailored to fit a variety of needs, it is not as efficient generally in
terms of performance as hand-written code, if the hand-written code is
written well. And there is no arguing that hand-coding, if used by an
experienced developer, will yield more efficient code.

But is efficiency the only consideration? If it were, why would there be any
high-level languages? High-level languages (I'm not going to include
assembler in that category) are basically macros that perform a series of
low-level operations in a single function. So, obviously, an application
written in Assembler is going to run faster than an application written in
C, by a very small margin.

But the reason that such languages and tools exist is purely for the purpose
of increasing productivity. To write an application like Microsoft Word in
assembler would take decades. The most expensive cost factor in software
development is human salaries. And we live in a competitive world. So, you
have to strike a balance between high application performance and rapid
application development.

The argument that tools like CodeSmith produce substandard developers is
ludicrous. Substandard developers produce themselves. Each of us has a
choice to get serious about our work or not. A good, experienced developer,
like an experienced carpenter, will use the tools that enable him/her to
produce a product as quickly as possible. But a good developer will also
know when to hand code, that is, when the cost factor of hand-coding
outweighs the productivity increase that comes with using tools. And a good
developer is not affected by the quality of the tools he/she uses. The
quality of the work will always be good, but productivity may increase with
better tools.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.


"M.Siler" <John.Doe@NoSpa m.comwrote in message
news:e06RgPrxGH A.2168@TK2MSFTN GP06.phx.gbl...

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position
is Codesmith is for junior to mid level developer who perfer "wizards" to
write code for them. That these types of code generators produce
substandard developers who don't have real skills. I don't have a position
one way or the other until I have a bit more information, but if I was to
take the other point of view... Is there value in utilizing something like
Codesmith to generate the bases of some code and then to customize it from
there?
>

[Ben Voigt]

Re: Codesmith vs. Hand coding


"Kevin Spencer" <uce@ftc.govwro te in message
news:%23v4sFmtx GHA.4232@TK2MSF TNGP05.phx.gbl. ..

It seems to me that the argument is invalid. You say that the issue is
CodeSmith vs. Hand Coding. Where is it written that you must use one
exclusive of the other?
>
The real question is, how much should you use any tool that writes code
for you, and how much should you write by hand?
>
Tools that write code for you will write boiler-plate code. This is good
in some situations, and not so good in others. Because boiler-plate code
is tailored to fit a variety of needs, it is not as efficient generally in
terms of performance as hand-written code, if the hand-written code is
written well. And there is no arguing that hand-coding, if used by an
experienced developer, will yield more efficient code.
>
But is efficiency the only consideration? If it were, why would there be
any high-level languages? High-level languages (I'm not going to include
assembler in that category) are basically macros that perform a series of
low-level operations in a single function. So, obviously, an application
written in Assembler is going to run faster than an application written in
C, by a very small margin.
>
But the reason that such languages and tools exist is purely for the
purpose of increasing productivity. To write an application like Microsoft
Word in assembler would take decades. The most expensive cost factor in
software development is human salaries. And we live in a competitive
world. So, you have to strike a balance between high application
performance and rapid application development.
>
The argument that tools like CodeSmith produce substandard developers is
ludicrous. Substandard developers produce themselves. Each of us has a
choice to get serious about our work or not. A good, experienced
developer, like an experienced carpenter, will use the tools that enable
him/her to produce a product as quickly as possible. But a good developer
will also know when to hand code, that is, when the cost factor of
hand-coding outweighs the productivity increase that comes with using
tools. And a good developer is not affected by the quality of the tools
he/she uses. The quality of the work will always be good, but productivity
may increase with better tools.

Exactly right. There are a couple guidelines that I think can be applied
though.

The idea proposed for using automated code generation to start the code
which will be customized by hand is VERY dangerous. Implemented directly,
this produces unmaintainable code.

Just as cut+paste techniques must give way to reusable libraries, so must
customization of automatically generated code be done without editing the
generated code. Use inheritance, use composition, use partial classes, but
never ever edit the generated code. Make sure that when you fix a bug in
the codegen tool, you can rerun the automated tool, not manually patch every
piece of code it created.

>
--
HTH,
>
Kevin Spencer
Microsoft MVP
Chicken Salad Surgery
>
It takes a tough man to make a tender chicken salad.
>
>
"M.Siler" <John.Doe@NoSpa m.comwrote in message
news:e06RgPrxGH A.2168@TK2MSFTN GP06.phx.gbl...

>I'm trying to get my head around a conversation I had with a developer
>the other day. We were talking about Codesmith vs. Hand coding. He's
>position is Codesmith is for junior to mid level developer who perfer
>"wizards" to write code for them. That these types of code generators
>produce substandard developers who don't have real skills. I don't have a
>position one way or the other until I have a bit more information, but if
>I was to take the other point of view... Is there value in utilizing
>something like Codesmith to generate the bases of some code and then to
>customize it from there?
>>

>
>

[Michael]

RE: Codesmith vs. Hand coding


Code Generation versus Hand Coding depends on the quality of the code
produced. Either by hand or by the code generator. I can't speak for
CodeSmith as I have never tried that tool but if it can create quality code
that you can use then it is a plus. Code Generators have been around a long
time with varying degrees of success:

- I know that I would of had a much more difficult time if I could not use
Lex and Yacc in my Compiler Design class many moons ago.
- I know that most of the wizards code I found in earlier IDE's didn't quite
create code the way that I wanted to as such I didn't use them much.
- I know from a recent project that had lots of redundant code that if I had
spent 1/2 a day writing a code generator I would have been able to save a
week on development time.

Software development life cycles get shorter and shorter and the demand to
meet them increases. Good Quality software must be delivered faster and
faster. Code Generation has the benefit of making it so that you only have
to fix code in one place. With Partial Classes in .NET 2.0 that gives you
the ability to generate boilerplate code while keeping your custom code
separate. This is a great enabler of being able to generate code. You must
be able to REgenerate it without losing anything.

Just my thoughts.

Michael

"M.Siler" wrote:

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?
>
>
>

[Simon Tamman]

Re: Codesmith vs. Hand coding

I kind of agree and disagree, but as far as i'm concerned it's a different
argument in that case.
If you ARE going to use DataSets as the data objects in your application
then you should definately use strongly typed datasets, however if you are
still flexible with this approach i'd recommend putting some time aside to
consider using PONOs (Plain old .NET objects).

It depends on the size and scope of the project, if it's short term than
datasets and ADO.NET are probably the quickest and easiest thing to
implement, if it isn't then you will suffer from:

The Shotgun smell
-------------------
Where a change to a dataset creates a large number of changes required in
the source code. This is because if you add an additional column to a
strongly typed dataset then the definition of the "AddXXXRow" changes. A
change to a PONO does not cause this issue.

Relational code
----------------
This again depends on the project you are working on, but if you are a team
that will change in size and bring in different people at different times
then a relational model means that it takes longer to get some developers up
to speed. This is because the data objects represent the database data
better than they do the application data, meaning that the developers will
not fully understand the workings of some of the code unless they understand
the database.

Naming Issues
---------------
Different DataSets that support different properties but are similar will
have all sorts of fun names, someone may make a dataset that is identical to
another apart from one column (possible to avoid the shotgun problem) which
can make naming confusing (and naming IS important).
Also strongly typed datasets usually require longer names as the classes are
nested within each other:

E.G: Customers.Custo merRow instead of CustomerRow.

Intellisense going AWOL.
--------------------------
Dont know if they've fixed this in VS2005 but in 2003 the intellisense would
go AWOL on strongly typed datasets quite a lot, this is especially
frustrating and isn't an issues with PONOs.

I personally use PONOs with an ORM Mapper (NHibernate) as I find this helps
keep the object model tidy, clear and more easily understandable to other
developers, I can also encapsulate operations that are based purely on the
data within a given object within a method (which you can't do on generated
code as all mods get lost when re-generating, unless you use .NET 2 and
partial classes).

So I guess I agree with your colleague, although not for his reasons.
Generated code is still a powerful tool and if someone ports over the
generator from Java that creates classes based on a database or NHibernate
mapping files based on classes then i'll definately use them.

HTH



"M.Siler" <John.Doe@NoSpa m.comwrote in message
news:eKLGejsxGH A.3604@TK2MSFTN GP04.phx.gbl...

We use strongly typed datasets and I believe was one of the big reason for
CodeSmith... this guy doesn't like the constraints strongly typed datasets
impose.
>
>
"UhihaJax" <UhihaJax@discu ssions.microsof t.comwrote in message
news:E0D997C8-BD0D-416E-A554-5B35B8E386F3@mi crosoft.com...

So would this guy manually write strongly typed datasets?
How long would that take?

"M.Siler" wrote:

I'm trying to get my head around a conversation I had with a developer
the
other day. We were talking about Codesmith vs. Hand coding. He's

position

is
Codesmith is for junior to mid level developer who perfer "wizards" to
write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way

or

the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like
Codesmith
to generate the bases of some code and then to customize it from there?
>
>
>

>
>

[Frans Bouma [C# MVP]]

Re: Codesmith vs. Hand coding

M.Siler wrote:

I'm trying to get my head around a conversation I had with a
developer the other day. We were talking about Codesmith vs. Hand
coding. He's position is Codesmith is for junior to mid level
developer who perfer "wizards" to write code for them. That these
types of code generators produce substandard developers who don't
have real skills. I don't have a position one way or the other until
I have a bit more information, but if I was to take the other point
of view... Is there value in utilizing something like Codesmith to
generate the bases of some code and then to customize it from there?

Hand written:
- slow
- repetitive and thus boring
- error prone

Code generation:
- fast
- not boring (click a couple of buttons)
- no bugs, as everything is already tested before.

Now, if this developer finds himself so l33t that he needs to write
everything himself or he's no real developer, so what. YOU should use
what gets the job done, not what some short-sighted person tries to
sell you.

If he's so against code generation, how come he's not writing in IL?
After all, the code generation performed by the C# compiler (a compiler
is just a code generator after all) is for juniors, right? ;)

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Barry Kelly]

Re: Codesmith vs. Hand coding

M.Siler wrote:

I'm trying to get my head around a conversation I had with a developer the
other day. We were talking about Codesmith vs. Hand coding. He's position is
Codesmith is for junior to mid level developer who perfer "wizards" to write
code for them. That these types of code generators produce substandard
developers who don't have real skills. I don't have a position one way or
the other until I have a bit more information, but if I was to take the
other point of view... Is there value in utilizing something like Codesmith
to generate the bases of some code and then to customize it from there?

Code generation is a form of abstraction and indirection. You write code
in the source language / arguments to templates / arguments to code
generator / whatever, and it produces target code, which gets processed
by other things.

There are other abstraction and indirection tools available to the
developer: delegates (functional indirection), classes (via dynamic
dispatch), interfaces (even more flexible dynamic dispatch), overloading
(compile-time dynamic dispatch), generics (abstraction and indirection
of types).

Which one is best depends on the scenario. In particular, it depends on
how close a match the problem domain is to the chosen source language.
If it's a close match for the tools provided by C#, then C# should be
chosen; if it's a close match for templates etc. or another code
generation language tool such as parser generators, then such code
generators should be chosen (if they're flexible enough).

I'd add that if you're modifying the code *by hand* after it's been
generated, it's not as useful as it might otherwise be - code generation
works best when you only work on the source side. You lose an
indirection layer when you work on the generated side, so your
modifications have less "power" as it were, and also the work is at risk
if the source language / arguments need to be changed.

-- Barry

--

http://barrkel.blogspot.com/

[Kevin Spencer]

Re: Codesmith vs. Hand coding

The idea proposed for using automated code generation to start the code

which will be customized by hand is VERY dangerous. Implemented directly,
this produces unmaintainable code.

I agree that the process of customizing generated code by hand is dangerous,
but that doesn't mean it's not useful or recommended. In fact, it is a
technique which I employ successfully from time to time. Because of the
dangers involved, it is necessary to ensure that you understand the
generated code, and how it was generated. It is not something one should do
often, but for people with the skill to do it, it can be a good productivity
tool.

But that just brings me back to my first point. A good developer should be
*able* to write the entire app by hand without any code generating tools.
That is, he/she should understand what the code generator does and be able
to do it without the code generator, before he/she uses a code generator as
a productivity tool. Once one reaches that point, code generators and
similar tools become quite helpful.

The danger lies in the very real possibility that one can write an entire
application with these tools, and know almost nothing about what one has
created. Many people take this shortcut, and find themselves over their
heads in short order.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.


"Ben Voigt" <rbv@nospam.nos pamwrote in message
news:uCveL6txGH A.1304@TK2MSFTN GP05.phx.gbl...

>
"Kevin Spencer" <uce@ftc.govwro te in message
news:%23v4sFmtx GHA.4232@TK2MSF TNGP05.phx.gbl. ..

>It seems to me that the argument is invalid. You say that the issue is
>CodeSmith vs. Hand Coding. Where is it written that you must use one
>exclusive of the other?
>>
>The real question is, how much should you use any tool that writes code
>for you, and how much should you write by hand?
>>
>Tools that write code for you will write boiler-plate code. This is good
>in some situations, and not so good in others. Because boiler-plate code
>is tailored to fit a variety of needs, it is not as efficient generally
>in terms of performance as hand-written code, if the hand-written code is
>written well. And there is no arguing that hand-coding, if used by an
>experienced developer, will yield more efficient code.
>>
>But is efficiency the only consideration? If it were, why would there be
>any high-level languages? High-level languages (I'm not going to include
>assembler in that category) are basically macros that perform a series of
>low-level operations in a single function. So, obviously, an application
>written in Assembler is going to run faster than an application written
>in C, by a very small margin.
>>
>But the reason that such languages and tools exist is purely for the
>purpose of increasing productivity. To write an application like
>Microsoft Word in assembler would take decades. The most expensive cost
>factor in software development is human salaries. And we live in a
>competitive world. So, you have to strike a balance between high
>application performance and rapid application development.
>>
>The argument that tools like CodeSmith produce substandard developers is
>ludicrous. Substandard developers produce themselves. Each of us has a
>choice to get serious about our work or not. A good, experienced
>developer, like an experienced carpenter, will use the tools that enable
>him/her to produce a product as quickly as possible. But a good developer
>will also know when to hand code, that is, when the cost factor of
>hand-coding outweighs the productivity increase that comes with using
>tools. And a good developer is not affected by the quality of the tools
>he/she uses. The quality of the work will always be good, but
>productivity may increase with better tools.

>
Exactly right. There are a couple guidelines that I think can be applied
though.
>
The idea proposed for using automated code generation to start the code
which will be customized by hand is VERY dangerous. Implemented directly,
this produces unmaintainable code.
>
Just as cut+paste techniques must give way to reusable libraries, so must
customization of automatically generated code be done without editing the
generated code. Use inheritance, use composition, use partial classes,
but never ever edit the generated code. Make sure that when you fix a bug
in the codegen tool, you can rerun the automated tool, not manually patch
every piece of code it created.
>

>>
>--
>HTH,
>>
>Kevin Spencer
>Microsoft MVP
>Chicken Salad Surgery
>>
>It takes a tough man to make a tender chicken salad.
>>
>>
>"M.Siler" <John.Doe@NoSpa m.comwrote in message
>news:e06RgPrxG HA.2168@TK2MSFT NGP06.phx.gbl.. .

>>I'm trying to get my head around a conversation I had with a developer
>>the other day. We were talking about Codesmith vs. Hand coding. He's
>>position is Codesmith is for junior to mid level developer who perfer
>>"wizards" to write code for them. That these types of code generators
>>produce substandard developers who don't have real skills. I don't have
>>a position one way or the other until I have a bit more information, but
>>if I was to take the other point of view... Is there value in utilizing
>>something like Codesmith to generate the bases of some code and then to
>>customize it from there?
>>>

>>
>>

>
>