RE: [U2] Estimating Timelines

[Tony G]

I've been meaning to blog on this for a while, thanks for the opportunity:
removepleaseNebula-RnD.com/blog/general/2008/03/estimates1.html

> From: John Rodgers
> Speaking for myself, ... today's
> applications are so complex that all the dependencies are 
> impossible to forecast.  It is not a question of lying - it
> is a question of trying to anticipate the worst case. The first
> estimate you give is the only one that "management" (your
> customers)  will ever remember.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] blank lines in code / mixed case

[Bill Haskett]

Kevin:
 
I'm sorry to say, on this rare occasion I disagree with your assessment.
 
First, anyone who learned to type has no problem with the [Shift] key being 
used.  In
fact, those who've learned to type often type words instead of letters so there 
is
nothing "efficient" in saving the [Shift] keystroke; to be honest, it's usually 
a
problem not to include the key as part of the overall typing framework.  I often
laugh when I see "C" code because I know it was designed by geeks who couldn't 
type
and are, ultimately, two finger peckers.  :-)
 
To those who say they don't have time to learn how to type I say they have an
"obligation" to learn to use the tools of their trade.  Do accountants not know 
how
to use a 10-Key?  Do doctors not know how to use a stethoscope?  Do carpenters 
not
know how to use a plane?  Of course they know how to use them!
 
With that said, let's look at some of the major aggravations of this case issue.
Most of us, not all but most, have multiple windows open when we work.  We may 
have a
web browser open, or an email client, a word processor, a spreadsheet, or other
applications.  All of these applications, and I mean "all" of them, expect [Caps
Lock] to be off (in fact, so does Unix)!  When we move our focus to a U2 window 
we
have to turn that darned function back on.  When we go back to one of the other
applications we end up typing "cAPS lOCK" all the time.  This is so true that 
even
when we watch demonstrations, where U2 is in the mix, we see the demonstrator 
having
the same problem over, and over, and over (like switching back to U2 from 
another
window to enter a TCL command, then backspacing over the typed in command to 
change
it to upper case).  For those who spend the majority of their time in the U2
environment, [Caps Lock] is probably set to on.  However, for most of the rest 
of us
it's a colossal aggravation, over, and over, and over.
 
U2 (UV much more than UD) has come up with some partial solutions to this casing
issue (because they recognize the error of their ways but it's too much trouble 
to
fix it).  UD is tough at ECL because case makes a big difference in an ECL verb.
Having an ECL shell processor that can upper-case all commands doesn't quite 
work in
UD when one wants to use a lower case ECL verb.  With case sensitivity, it's 
clear
there is a difference between the variable CUSTOMER.REC and Customer.Rec.  I'm 
not at
all convinced those who've thought this through really would create one variable
"CUSTOMER.REC" and another variable "Customer.Rec".  Yet, again, upper-casing
"forces" everyone to work around its serious limitations.  The only place where 
I've
found case to be important, other than in MV, is in command line options in Unix
(here we run into those two finger geeks again).  :-)
 
Upper case is an anachronism and should be treated as such rather than 
defended.  It
is unwieldy for far too many and, in fact, interferes with efficient typing at 
every
turn.  Forcing people to use [Caps Lock] in U2 while all other used applications
require [Caps Lock] to be off is a egalitarian ruse for autocracy.  :-)
 
This is, of course, IMHO...
 
Bill



  _  

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Kevin King
Sent: Saturday, March 08, 2008 9:39 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] blank lines in code / mixed case



I am admittedly a dinosaur of the upper-case bent with U2.  Before I put on
my flame suit, hear me out..

We developers type thousands - possibly even millions - of characters of
code per year   To press the letter "R" with caps lock on or off is only one
keypress - keeping in mind the state of the cApS LocK.  To type READU then
is only 5.  ReadU however, is 7 - an increase of 40%.  Now, assuming that a
typical program is 4000 characters, there's a potential of an additional
1000+ shift keypresses just to maintain case.  Meaningless, you say?
Everything we do takes an investment of time, and even a fraction of a
second can turn into a significant investment when multiplied times millions
of occurrences.

In Java, PHP, etc., mixed case code has been the norm from the beginning.
People don't think about writing these languages in upper case because they
were never designed to be written that way.  BASIC, however has its roots in
upper case, and - here's my big point - not being forced into mixed case
provides a significant opportunity to produce more code in less time simply
because of the reduced number of keystrokes.

Also on the topic of productivity, a variable named ITEM.CUSTOMER has one
presentation, no variants.  Mixing case on this variable produces a number
of variants which may be easily mistyped thus potentially increasing
debugging time.  I will admit, because I don't use mixed case I don't know
if there's a compiler option that will allow ITEM.CUSTOMER and
ItEm.CuStoMerto be the same variable, but even if such a thing exists,
isn't that just
adding confusion to whomever has to compile 

[U2] UD MESSAGE command

[Bill Haskett]

I've tried to use the UD MESSAGE command and it it doesn't seem to send a 
message if
another user is sitting at a BASIC INPUT prompt; which of course all our users 
sit at
in our application.  It works fine if other users are at the ECL prompt.  Is 
this
true?  Is there a work-around, or is the unusefulness of this command limited?
 
UD v7.1.9 on Win 2K3
 
Thanks,

Bill Haskett
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Estimating Timelines {Unclassified}

[HENDERSON MIKE, MR]

And then, you have the "client factor", as in
*   Work out a rough estimate
*   Double it
*   And multiply this result by the "client factor" to give the actual 
estimate

You know what I mean, 
*   If you ever find such a beast, a really good client that knows what 
they want and is capable of articulating that, gets a "1" or "1="
*   The average clueless client gets about a "2" or "3"
*   Anyone with 'President' or 'Director' in their job title gets at 
least a "5"
*   And we all have those 'Oh, maybe I forgot to mention ...' clients
that definitely rate a "10"

Yeah, I'm getting cynical in my old age


Regards


Mike

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin King
Sent: Saturday, 8 March 2008 12:28 p.m.
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] Estimating Timelines

I have to weigh in on this in support of everything stated so far.  John is 
right, the first estimate is the one that "sticks" so that estimate has to 
factor in what is known about the problem, solution, and path at the time the 
estimate is requested, which is often before any real discovery has taken 
place.  The less information known before the estimate, the higher the estimate 
will be, if for no other reasons than to make sure everyone is covered with no 
surprises.  And of course, while customers will do their best to give all of 
the information needed at the outset of the task, the reality is that any and 
all information needs to be weighed against some kind of objective review to 
ensure that the information is accurate and complete.  In fact, I believe that 
ensuring that all of the important information is on the table is a real art 
form!  (I mean, hey, that's what discovery and analysis are for, right?) And as 
Jerry said, there can be a lot of time invested in those ta!
 sks.  Asking someone to estimate a complete job - which includes the discovery 
and analysis needed to estimate the remainder of the tasks - without having 
those tasks completed in advance is pretty much asking for an unknown on a 
fixed timeline, which is as close to an impending failure as one can 
intentionally get.

For the past several years I've been taking a multi-stage approach to the 
larger projects.  Certainly on a smaller project I've finally gotten to a point 
where I can spitball an estimate pretty reliably, but on the big ones I'll 
estimate the discovery separate from the analysis separate from the
implementation+testing+installation.  And of course, documentation is 
implementation+testing+also
estimated separately.  Most customers - to date - have been pretty happy to 
give me a small budget for discovery knowing that it pays big dividends in more 
accurate estimates for the rest of the project.  And accurate, on time, and on 
budget makes everyone happy.

-K
http://www.PrecisOnline.com
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
The information contained in this Internet Email message is intended
for the addressee only and may contain privileged information, but not
necessarily the official views or opinions of the New Zealand Defence Force.
If you are not the intended recipient you must not use, disclose, copy or 
distribute this message or the information in it.

If you have received this message in error, please Email or telephone
the sender immediately.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

RE: [U2] Pooled UO.Net Connections [not-secure]

[Mike Randall]

I too would be interested in seeing them compared as I am considering
implementing them.

Mike Randall,  MCP


 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hennessey, Mark F.
Sent: Friday, March 07, 2008 1:42 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Pooled UO.Net Connections [not-secure]

I'd be interested in seeing the stats, and how they were collected.

In your free time, of course! 


Mark Hennessey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Symeon Breen
Sent: Friday, March 07, 2008 11:47 AM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] Pooled UO.Net Connections

Hi Brian , I am using it in some ASP.NET environs and it is highly
performant compared to opening and closing a connection each time - I
have some good stats on live web sites using WAS that I can send on to
you/the list if anyone is interested.



Symeon


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian Leach
Sent: 07 March 2008 15:09
To: u2-users@listserver.u2ug.org
Subject: [U2] Pooled UO.Net Connections

All
 
Being too poor to afford to purchase pooled connection licences just for
testing, I'm interested in hearing from anyone using these with UO.NET
in anger in terms of performance and stability.
 
Thanks
 
Brian
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/

Re: [U2] blank lines in code / mixed case

[Anthony W. Youngman]

In message 
<[EMAIL PROTECTED]>, Kevin 
King <[EMAIL PROTECTED]> writes

And one last point to really fire up some folks: To those who think mixed
case is more readable, I offer this: It's syntax, not literature.  While we
should do everything we can to make the code as human readable as possible,
greater readability gains are available through structural protocol than
changing READU to ReadU.  To put so much energy in all these extra
keystrokes and then to create a 3000 line routine with 1200 GOTOs (oops, I
meant "GoTo"'s) is ... in my opinion... a lot of effort with minimal - if
any - ROI.


I've probably posted about this before, but it's not syntax or 
literature, it's familiarity. I came across some studies about learning 
and dyslexia ages ago, and it gave me some interesting insights into how 
we learn to read. A learner will read letter by letter. An experienced 
reader will read symbol (word) by symbol. And the symbols "THE", "The" 
and "the" are NOT the same. That's why all caps brings emphasis. That's 
why all caps is normally harder to read. It *breaks* the easy flow of 
lower-case symbols with which we are all familiar.


That's why I'm happy coding VB in CamelCase, C in lower case, and 
DATABASIC in UPPER CASE. I'm familiar with those conventions for those 
languages, and would actually find it quite hard to switch.


The code I'm working on at the moment actually gives a very good insight 
into that :-) My predecessor seems to have worked pretty much entirely 
in upper case. So I find it easy to read the code, but harder to read 
the comments! You can tell my comments from his easily - mine are in 
normal case :-)


Cheers,
Wol
--
Anthony W. Youngman <[EMAIL PROTECTED]>
'Yings, yow graley yin! Suz ae rikt dheu,' said the blue man, taking the
thimble. 'What *is* he?' said Magrat. 'They're gnomes,' said Nanny. The man
lowered the thimble. 'Pictsies!' Carpe Jugulum, Terry Pratchett 1998
Visit the MaVerick web-site -  Open Source Pick
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/