Collections

[Shemp]

I'm looking for information on what type of collection fits a particular
need. For example, what collection provides the best performance for a
large volume of records? What collection provides the best sorting
performance?

Basically I want to incorporate this into our coding standards.

Thanks!

[Yoyoma_2]

Re: Collections

Shemp wrote:[color=blue]
> I'm looking for information on what type of collection fits a particular
> need. For example, what collection provides the best performance for a
> large volume of records? What collection provides the best sorting
> performance?
>
> Basically I want to incorporate this into our coding standards.
>
> Thanks![/color]

I think that your basic computer science algorithms course will tell you
which collections are better than the other. Sorting performance
depends on the data entered also but
http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of them.

I congradulate you to make cording standards, its a good practice in
managment. But remember someone needs to enforce the standards. And
the WORST way of doing that is having someone go through the code and
bitching about it, that totally destroys team moral.

Once every 2 weeks or so, open a random file that has been edited latley
(by ANYONE on the team, from yourself to your senior programmers to your
coop students) and do constructive critisism on it, remember to say what
is GOOD as well as what is BAD, its not just a mud throwing session.
That really helps motivate the employees.

My 0.02 CAD

[Liz]

Re: Collections


"Yoyoma_2" <Yoyoma_2@[at-]Hotmail.com> wrote in message
news:d4ofc.1230 22$oR5.76604@pd 7tw3no...[color=blue]
> Shemp wrote:[color=green]
> > I'm looking for information on what type of collection fits a particular
> > need. For example, what collection provides the best performance for a
> > large volume of records? What collection provides the best sorting
> > performance?
> >
> > Basically I want to incorporate this into our coding standards.
> >
> > Thanks![/color]
>
> I think that your basic computer science algorithms course will tell you
> which collections are better than the other. Sorting performance
> depends on the data entered also but
> http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of[/color]
them.[color=blue]
>
> I congradulate you to make cording standards, its a good practice in
> managment. But remember someone needs to enforce the standards. And
> the WORST way of doing that is having someone go through the code and
> bitching about it, that totally destroys team moral.[/color]

Isn't this called "code inspection" and isn't it a "best practice"??
[color=blue]
>
> Once every 2 weeks or so, open a random file that has been edited latley
> (by ANYONE on the team, from yourself to your senior programmers to your
> coop students) and do constructive critisism on it, remember to say what
> is GOOD as well as what is BAD, its not just a mud throwing session.
> That really helps motivate the employees.
>
> My 0.02 CAD[/color]

[Glenn]

Re: Collections

Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com> wrote in message news:<d4ofc.123 022$oR5.76604@p d7tw3no>...
[color=blue]
> I congradulate you to make cording standards, its a good practice in
> managment. But remember someone needs to enforce the standards. And
> the WORST way of doing that is having someone go through the code and
> bitching about it, that totally destroys team moral.[/color]

We have also developed coding standards, and we have a separate team
which performs reviews. In our shop, reviews are done when the code
is moved into the acceptance region for customer testing. At first,
we had a problem with coders not being happy with their code being
picked at, but mgmt. emphasized that code does not belong to a
developer - it belongs to the company. Mgmt. also reminded everyone
that the review team is not making personal attacks on people when
problems are found; it is a QA process. It took some time, but all of
our coders accept and embrace the review process now. :-) The reviews
are enforced by mgmt. and by a separate team filled with server admins
who actually migrate the code to the production boxes; they also
receive the review results. If any code hasn't passed review, they
will not migrate it to production.

The review process has yielded fruit in terms of overall quality,
reduced need to implement production fixes, and improved
stability/reliability/speed. :-)

We also push for code designs that encourage reuse; we have a growing
collection of utility objects to promote this reuse.

[Yoyoma_2]

Re: Collections

Liz wrote:[color=blue]
> "Yoyoma_2" <Yoyoma_2@[at-]Hotmail.com> wrote in message
> news:d4ofc.1230 22$oR5.76604@pd 7tw3no...
>[color=green]
>>Shemp wrote:
>>[color=darkred]
>>>I'm looking for information on what type of collection fits a particular
>>>need. For example, what collection provides the best performance for a
>>>large volume of records? What collection provides the best sorting
>>>performanc e?
>>>
>>>Basically I want to incorporate this into our coding standards.
>>>
>>>Thanks![/color]
>>
>>I think that your basic computer science algorithms course will tell you
>>which collections are better than the other. Sorting performance
>>depends on the data entered also but
>>http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of[/color]
>
> them.
>[color=green]
>>I congradulate you to make cording standards, its a good practice in
>>managment. But remember someone needs to enforce the standards. And
>>the WORST way of doing that is having someone go through the code and
>>bitching about it, that totally destroys team moral.[/color]
>
>
> Isn't this called "code inspection" and isn't it a "best practice"??[/color]

There are better manegerial ways to do thos, like the one mentioned
below. If you do a code inspection and have a "code inspector", it can
seem as if the managment doesn't trust the employees and conflict
situations arise.

Instead of "discussing " a problem or why someone did it this way,
someone will go totally on the defensive because they think that the
inspector is attacking his work (which he/she is in a way). When you
have a meeting and you pick a file at random, its less direct, you can
also bring foward the good points (ALWAISE start with a compliment, then
your thoughts on it, then another compliment.. It makes peopel less
defensive).

For example,
Manager: "Ok let's take randomly a file. umm. How about
MyCoolClass.jav a... Now this is a class that was made in the CoolApp
project we did last month, the project went really well. Now let's look
through the file... What do you guys think. I like his braketting style
here. "

Coop Student: "Why did he use this kind of function instead of doing
the call directly?"

Developer: "Oh i guess it could have been done directly, we can add it
in the todo list on the top of the file."

Manager: "The if statement here is a bit convoluted, can we also change
that so it resembles the standard way?"



This is a good interchange, productive and also puts evryone in the loop
about other projects etc. Since Coop Student now has seen the file, he
knows that this class exists and wouldn't mind re-using it if he/she
ever needed to. Now for the bad way, the direct code audit.

Manager: "Jim, i've been reviewing your file and the if statement is
convoluted, do you think you can change it?"

Jim: "Oh well that was done pretty fast, i'me pretty busy now but i'lle
put that on my todo list"

Manager: "Oh... ok thanks"

Jim to Bob the co-worker: "Man who do they think they are coming in here
and telling me how to do my work when he knows how busy we are with the
new release."

....And it will most likley not get fixed, and be left as it is. And if
you have to press it you add another conflict situation.

I know this is just a theoretical interchange or whatever, and you could
in this theoretical world have Jim freak out and cluck like a chicken in
the meeting, but you see my point. If you make a code review meeting
and have random poeple administer it, then you are verifying standards,
discussing why standards are important and also discussing previous
projects or the innter workings of a project everyone might not be privy
too.

Anyway thats just my 0.02$ and that's why i made that comment.

[color=blue]
>
>[color=green]
>>Once every 2 weeks or so, open a random file that has been edited latley
>>(by ANYONE on the team, from yourself to your senior programmers to your
>>coop students) and do constructive critisism on it, remember to say what
>>is GOOD as well as what is BAD, its not just a mud throwing session.
>>That really helps motivate the employees.
>>
>>My 0.02 CAD[/color]
>
>
>[/color]

[Yoyoma_2]

Re: Collections

Glenn wrote:
[color=blue]
> Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com> wrote in message news:<d4ofc.123 022$oR5.76604@p d7tw3no>...
>
>[color=green]
>>I congradulate you to make cording standards, its a good practice in
>>managment. But remember someone needs to enforce the standards. And
>>the WORST way of doing that is having someone go through the code and
>>bitching about it, that totally destroys team moral.[/color]
>
>
> We have also developed coding standards, and we have a separate team
> which performs reviews. In our shop, reviews are done when the code
> is moved into the acceptance region for customer testing. At first,
> we had a problem with coders not being happy with their code being
> picked at, but mgmt. emphasized that code does not belong to a
> developer - it belongs to the company.[/color]

Agreed but that means you just did a conflict situation. Managment
can't overnight remind someone that the code belongs to the company and
think that everything is fine and dandy. Most developers count their
code as "their work" and don't like ot have it sumarily attacked. But
your right the code belongs to the company. That's probably not a great
way of saying it, why not say that the code has to be standardised so
they can make and understand changes quicker, leading to more profits.
That is worth saying. Saying "its not you its mine" will probably make
the developers feel awkward at best.
[color=blue]
> Mgmt. also reminded everyone
> that the review team is not making personal attacks on people when
> problems are found; it is a QA process. It took some time, but all of
> our coders accept and embrace the review process now. :-)[/color]

The problem with that kind of stuff is that it waits until it's too late
to do the code reviews. If you are doing a small project that has
around 10 000 lines of code, you don't want to spend money for
CoopStudent to standardise his 10 000 lines. If you do it
in-development, they will and do before the QA process rejects it. Also
in an extreme time where the project must be rushed, the code audit
would probably bounce.

My question is, why not do both? Do the code audit meetings as a way of
discussing previously made classes, projects and usability. And your QA
process obviously does whitebox testing, then they can comment on the
code too but i think they should not focus too much on standards, they
should focus on testing and stability and security matters.
[color=blue]
>The reviews are enforced by mgmt. and by a separate team filled with[/color]
server admins[color=blue]
> who actually migrate the code to the production boxes; they also
> receive the review results. If any code hasn't passed review, they
> will not migrate it to production.[/color]

Kind of severe, i would be scared for the "gray areas" in your
standards. Sometimes the standards have to be bent because of certain
language constraints or problems arise etc. That depends on the type of
work you do. If you are doing actual Software Engineering (public
liability issues) then this is a great process, i would still add the
review meetings just as a way to share information and make reusability.
The engineer can then certify the code because he/she has seen that
the code has been reviewed (by himself!) and a comitee and is up to spec.

If you are doing a computer-science based code (Web pages, user apps, no
public liability issues) then this can seem extreme to the programmers.
[color=blue]
> The review process has yielded fruit in terms of overall quality,
> reduced need to implement production fixes, and improved
> stability/reliability/speed. :-)[/color]

For sure, its a GREAT process to have and is vital. But remember you
don't want to sacrefice quality for morale. Its just like in a factory,
you could beat the employees 1900's style when they made a mistake on
the factory line. The quality was great but the moral was horrible.
Its a carefull game. Though i'me happy your company is concerned about
quality, but remember that your employees are also a good asset to keep.
Not only it is expensive when an employee leaves to go work at "new
opportunities", that means that the company has to re-hire, re-train,
re-certify someone at some point. It also decreases team morale too
because poeple 1) loose there friends and 2) start thinking "hey maby i
can leave too".
[color=blue]
> We also push for code designs that encourage reuse; we have a growing
> collection of utility objects to promote this reuse.[/color]

GREAT! That's great. Make sure its documented somewhere so the new emps
and the coop students know. Poeple always say that objects can't be
reused, but a good design means that it can almost alwayse be reused.
And that means cost savings, being able to ship faster and better
reliability.

I bet your customer's are happy :) and i bet the board is also happy
with the work.

[Paul Schmidt]

Re: Collections

Yoyoma_2 wrote:[color=blue]
> Shemp wrote:
>[color=green]
>> I'm looking for information on what type of collection fits a particular
>> need. For example, what collection provides the best performance for a
>> large volume of records? What collection provides the best sorting
>> performance?
>>
>> Basically I want to incorporate this into our coding standards.
>>
>> Thanks![/color]
>
>
> I think that your basic computer science algorithms course will tell you
> which collections are better than the other. Sorting performance
> depends on the data entered also but
> http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of them.
>
> I congradulate you to make cording standards, its a good practice in
> managment. But remember someone needs to enforce the standards. And
> the WORST way of doing that is having someone go through the code and
> bitching about it, that totally destroys team moral.
>[/color]

The ideal with coding standards is, the developers need to know the
standards, and how to work with the standards. Every programmer should
have a copy of the standards document sitting on their desk, this should
also include complete documentation on how the formal review process
works, and how code is reviewed.

The ideal is when coders know the standard, write standard acceptable
code, where the coder is reasonably sure that it will pass formal review
without any changes. Coders that are familiar with the review process
can informally review each others code.

The worst is when code is written, tested, then reviewed and rewritten,
then tested again, just at the time they want to put it into production.

[Yoyoma_2]

Re: Collections

Paul Schmidt wrote:[color=blue]
> Yoyoma_2 wrote:
>[color=green]
>> Shemp wrote:
>>[color=darkred]
>>> I'm looking for information on what type of collection fits a particular
>>> need. For example, what collection provides the best performance for a
>>> large volume of records? What collection provides the best sorting
>>> performance?
>>>
>>> Basically I want to incorporate this into our coding standards.
>>>
>>> Thanks![/color]
>>
>>
>>
>> I think that your basic computer science algorithms course will tell
>> you which collections are better than the other. Sorting performance
>> depends on the data entered also but
>> http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of
>> them.
>>
>> I congradulate you to make cording standards, its a good practice in
>> managment. But remember someone needs to enforce the standards. And
>> the WORST way of doing that is having someone go through the code and
>> bitching about it, that totally destroys team moral.
>>[/color]
>
> The ideal with coding standards is, the developers need to know the
> standards, and how to work with the standards. Every programmer should
> have a copy of the standards document sitting on their desk, this should
> also include complete documentation on how the formal review process
> works, and how code is reviewed.[/color]

I whole-heartedly agree. Print the standards document and give them to
everyone that writes code. Also make a PDF version of the standards and
put it in your doc tree.
[color=blue]
> The ideal is when coders know the standard, write standard acceptable
> code, where the coder is reasonably sure that it will pass formal review
> without any changes. Coders that are familiar with the review process
> can informally review each others code.[/color]

I agree.
[color=blue]
> The worst is when code is written, tested, then reviewed and rewritten,
> then tested again, just at the time they want to put it into production.[/color]

Which is why i suggested the in-process code review meeting instead of a
post QA code review (its in another post on this subject).

I'me happy we are in agreement.

[Paul Schmidt]

Re: Collections

Yoyoma_2 wrote:[color=blue]
> Paul Schmidt wrote:
>[color=green]
>> Yoyoma_2 wrote:
>>[color=darkred]
>>> Shemp wrote:
>>>
>>>> I'm looking for information on what type of collection fits a
>>>> particular
>>>> need. For example, what collection provides the best performance for a
>>>> large volume of records? What collection provides the best sorting
>>>> performance?
>>>>
>>>> Basically I want to incorporate this into our coding standards.
>>>>
>>>> Thanks!
>>>
>>>
>>>
>>>
>>> I think that your basic computer science algorithms course will tell
>>> you which collections are better than the other. Sorting performance
>>> depends on the data entered also but
>>> http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview of
>>> them.
>>>
>>> I congradulate you to make cording standards, its a good practice in
>>> managment. But remember someone needs to enforce the standards. And
>>> the WORST way of doing that is having someone go through the code and
>>> bitching about it, that totally destroys team moral.
>>>[/color]
>>
>> The ideal with coding standards is, the developers need to know the
>> standards, and how to work with the standards. Every programmer
>> should have a copy of the standards document sitting on their desk,
>> this should also include complete documentation on how the formal
>> review process works, and how code is reviewed.[/color]
>
> I whole-heartedly agree. Print the standards document and give them to
> everyone that writes code. Also make a PDF version of the standards and
> put it in your doc tree.[/color]

Don't know if it's needed in the Doc tree, most people never refer to
that, unless they are updating it. However a binder on the shelf
labeled corporate coding standards, is more likely to be refered to.

Another issue is that standards should be broken down, so that there are
general standards which cross language barriers, and language specific
standards. It's not helpful if the standard was written in 1958 for
COBOL or ASSEMBLER, and has never been updated for Java.
[color=blue][color=green]
>> The ideal is when coders know the standard, write standard acceptable
>> code, where the coder is reasonably sure that it will pass formal
>> review without any changes. Coders that are familiar with the review
>> process can informally review each others code.[/color]
>
>
> I agree.
>[color=green]
>> The worst is when code is written, tested, then reviewed and
>> rewritten, then tested again, just at the time they want to put it
>> into production.[/color]
>
>
> Which is why i suggested the in-process code review meeting instead of a
> post QA code review (its in another post on this subject).[/color]

Meetings are always high cost with low productivity, you have to pay 10
people to sit around, and generally the conversation ends up 5 minutes
about the topic, and 2 hours about hockey. Go Leafs Go......

Paul



[color=blue]
>
> I'me happy we are in agreement.[/color]

[Yoyoma_2]

Re: Collections

Paul Schmidt wrote:[color=blue]
> Yoyoma_2 wrote:
>[color=green]
>> Paul Schmidt wrote:
>>[color=darkred]
>>> Yoyoma_2 wrote:
>>>
>>>> Shemp wrote:
>>>>
>>>>> I'm looking for information on what type of collection fits a
>>>>> particular
>>>>> need. For example, what collection provides the best performance
>>>>> for a
>>>>> large volume of records? What collection provides the best sorting
>>>>> performance?
>>>>>
>>>>> Basically I want to incorporate this into our coding standards.
>>>>>
>>>>> Thanks!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I think that your basic computer science algorithms course will tell
>>>> you which collections are better than the other. Sorting
>>>> performance depends on the data entered also but
>>>> http://en.wikipedia.org/wiki/Sorting_algorithm has a good overview
>>>> of them.
>>>>
>>>> I congradulate you to make cording standards, its a good practice in
>>>> managment. But remember someone needs to enforce the standards.
>>>> And the WORST way of doing that is having someone go through the
>>>> code and bitching about it, that totally destroys team moral.
>>>>
>>>
>>> The ideal with coding standards is, the developers need to know the
>>> standards, and how to work with the standards. Every programmer
>>> should have a copy of the standards document sitting on their desk,
>>> this should also include complete documentation on how the formal
>>> review process works, and how code is reviewed.[/color]
>>
>>
>> I whole-heartedly agree. Print the standards document and give them
>> to everyone that writes code. Also make a PDF version of the
>> standards and put it in your doc tree.[/color]
>
>
> Don't know if it's needed in the Doc tree, most people never refer to
> that, unless they are updating it. However a binder on the shelf
> labeled corporate coding standards, is more likely to be refered to.[/color]

Ah i guess that depends on the type of business you have. We kept
everything in the doc tree because there were many remote workers and
the like. From home they could have access to the documents without us
having to pay too much to fedex for international shipping :) .
[color=blue]
> Another issue is that standards should be broken down, so that there are
> general standards which cross language barriers, and language specific
> standards. It's not helpful if the standard was written in 1958 for
> COBOL or ASSEMBLER, and has never been updated for Java.[/color]

Yep i agree. Standards should be by language and generalized. :) Wow
we tend to agree on many things.
[color=blue][color=green][color=darkred]
>>> The ideal is when coders know the standard, write standard acceptable
>>> code, where the coder is reasonably sure that it will pass formal
>>> review without any changes. Coders that are familiar with the review
>>> process can informally review each others code.[/color]
>>
>>
>>
>> I agree.
>>[color=darkred]
>>> The worst is when code is written, tested, then reviewed and
>>> rewritten, then tested again, just at the time they want to put it
>>> into production.[/color]
>>
>>
>>
>> Which is why i suggested the in-process code review meeting instead of
>> a post QA code review (its in another post on this subject).[/color]
>
>
> Meetings are always high cost with low productivity, you have to pay 10
> people to sit around, and generally the conversation ends up 5 minutes
> about the topic, and 2 hours about hockey. Go Leafs Go......[/color]

Umm btw GO SENS GO! but see thats just because of bad meeting
administration, not because meetings are bad in themselves. That's like
saying banking using a teller is inneficient because you know him/her
and you have long conversations with them. The meeting supervisor
should make sure that the meeting stays on topic (not talking about how
good Lalime is, and by how much the leafs will loose :) ) but more to
keep the pace going.

The supervisor of the meeting should be the most senior person there.
Communication is really important. A 20 min meeting can mean thousands
of $$$ saved and that affects the bottom line directly. But disciplin
is required.

[Glenn]

Re: Collections

Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com> wrote in message news:<NRyfc.122 430$Pk3.111700@ pd7tw1no>...[color=blue]
> Glenn wrote:
>[color=green]
> > Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com> wrote in message news:<d4ofc.123 022$oR5.76604@p d7tw3no>...
> >
> > We have also developed coding standards, and we have a separate team
> > which performs reviews. In our shop, reviews are done when the code
> > is moved into the acceptance region for customer testing. At first,
> > we had a problem with coders not being happy with their code being
> > picked at, but mgmt. emphasized that code does not belong to a
> > developer - it belongs to the company.[/color]
>
> Agreed but that means you just did a conflict situation. Managment
> can't overnight remind someone that the code belongs to the company and
> think that everything is fine and dandy. Most developers count their
> code as "their work" and don't like ot have it sumarily attacked.[/color]

We have managed to avoid that problem, for the most part. :-)
[color=blue]
> But your right the code belongs to the company. That's probably not a great
> way of saying it, why not say that the code has to be standardised so
> they can make and understand changes quicker, leading to more profits.[/color]

Which is how we have done it. :-) We have a framework upon which all
of our applications run; it provides a common set of
resources/services for all applications such as page generation,
database access, error logging, common business logic, MQ Series, etc.
It makes the basic code standardized(UI handlers, biz logic, etc.)
between apps so any of our coders can pick up and add/maintain/fix any
application with a minimum of fuss, even if a given app isn't their
primary assignment. We built most of it in-house. It works really
well.
[color=blue]
> If you do it in-development, they will and do before the QA process rejects
> it. Also
> in an extreme time where the project must be rushed, the code audit
> would probably bounce.[/color]

We ran into that problem early on and established a "pre-review" for
developers. They can have the pre-review run against their code
anytime during development and see what needs fixed. We use an
automated tool for the pre-review. In the case of a very short
timeframe, like a midnight production problem, the code is fixed and
put into production and a review is done the next morning; any
problems found are addressed then.
[color=blue]
> My question is, why not do both? Do the code audit meetings as a way of
> discussing previously made classes, projects and usability. And your QA
> process obviously does whitebox testing, then they can comment on the
> code too but i think they should not focus too much on standards, they
> should focus on testing and stability and security matters.[/color]

I agree about stability and security. We've taken steps to address
those issues(security and stability/resource usage are key components
of the review/audit process), and are considering further steps to
enhance them.
[color=blue]
> Sometimes the standards have to be bent because of certain
> language constraints or problems arise etc.[/color]

Very true! Our process allows reviewers to grant waivers if the
developer can justify what he/she did and demonstrate that it is the
best way to address an issue while still addressing security and
stability in a satisfactory manner.
[color=blue]
> If you are doing actual Software Engineering (public
> liability issues) then this is a great process, i would still add the
> review meetings just as a way to share information and make reusability.[/color]

Thanks. :-) We do have public liability issues to consider - a lot of
them.
[color=blue]
> The engineer can then certify the code because he/she has seen that
> the code has been reviewed (by himself!) and a comitee and is up to spec.[/color]

This is our end goal. We're not there yet, though. We hope to be
there by the end of the year.
[color=blue]
> For sure, its a GREAT process to have and is vital. But remember you
> don't want to sacrefice quality for morale. Its just like in a factory,
> you could beat the employees 1900's style when they made a mistake on
> the factory line. The quality was great but the moral was horrible.
> Its a carefull game. Though i'me happy your company is concerned about
> quality, but remember that your employees are also a good asset to keep.[/color]

Fortunately for us, morale isn't a problem. Everyone has accepted the
process and the procedures therein. We're also fortunate that we
don't have a houseful of inflated egos to deal with. :-)
[color=blue]
> GREAT! That's great. Make sure its documented somewhere so the new emps
> and the coop students know. Poeple always say that objects can't be
> reused, but a good design means that it can almost alwayse be reused.
> And that means cost savings, being able to ship faster and better
> reliability.[/color]

It's been my experience that people claim 'objects can't be reused'
because they don't want to put in a little extra effort to make them
reusable. The added effort to make them reusable is usually minimal,
and it avoids re-inventing the wheel time after time. Have you seen
this?
[color=blue]
> I bet your customer's are happy :) and i bet the board is also happy
> with the work.[/color]

They are! :-) They are very happy, thanks. This process and the
framework we use have slashed overtime to almost zero, which has saved
an enormous amount of money. :-)