[AccessD] A2003:Replacing 'tokens' in a string

Hi Gustav --

Reusability of one-liners is "evil" :)

Work on reusability of general purpose modules/code is (nowadays) also an
"evil" for small software shops developing custom business software - that's
a work for MS and for the companies specializing in developing of software
development tools...

Who will pay for "putting a little bit more efforts"? - been there done that
- did put extremely high additional efforts, which did very rarely pay back
(my bad luck maybe) but I have seen/personally met and worked with others
whose extreme additional efforts resulted in heavy law cases filed against
them by customer - and that happened not here in Russia but in developed
West European country...

And I have seen (many) others who didn't put that much efforts - and many of
them prosper - one of them is MS :)

Well, a kind of kidding/provoking here :) - my point is that a modern
software developer professional should be very experienced in finding a true
balance between "putting a little bit more efforts" and very often getting
burn-out and bankrupt because of that, and waiting for another day to come
to put that more efforts when they will really be needed, and paid for that
additional work...

<<<
you are the expert, you should have expected this or that to happen
>>>
Well, if I'm an expert and "I expect this or that to happen" then I can tell
my customer *now* - would you like to pay *now* for that additional efforts
to prevent possible future issues of your source formats getting changed, or
you can wait for the true business case to highlight the issue, and then
will pay me for fixing it? 

And my customer in most of the cases, the customer I like to work with, and
the customer who likes to work with me, will tell me - yes, please put
additional efforts but as little as possible (zero ideally), and I will pay
you for that (or save money for zero efforts).

And what I will do now will be just "a little bit more efforts" to capture
exceptions, and log them for the future investigation, and fixing later if
really needed, or fixing the sources that caused this exception - the latter
is more probable...

And capturing exceptions in .NET apps is done usually in a very few places
but still having the final product robust and "bullet-proof" as all the real
business use cases/user stories are tested and code is unit tested against
current specs, and possible exceptions are captured. (capturing and logging
exceptions in MS Access VBA applications is a more laborious work but
general approach could be the same - "leave tomorrow for tomorrow"...)

<<<
I find it unprofessional to hide behind "it was not part of the
specification". 
>>>
No, I'm not "hiding behind the specs" - I'm trying to use customers' money
as effective as possible to automate their most urgent business needs, and
to not burn-out myself and my partners...

<<<
That said, you have to find a balance but the ability to find or chose this
comes exactly from experience.
>>>
Yes, we are in a full agreement here I suppose.

Thank you :)

--
Shamil

P.S. True developer's life is not that easy as I have "presented" it above
of course but I'm quite sure the above "true life balancing approach" is
getting mainstream for the nowadays business applications development as
well as for development tools development - just read it here - even MS uses
agile and SCRUM now:

http://port25.technet.com/archive/2010/01/20/part-3-lessons-i-learned-as-a-p
roject-manager-converting-to-agile.aspx 

Is that just a "fashion tribute",  a "PR action" or a true move to the
"agile world"? 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Gustav Brock
Sent: Thursday, January 28, 2010 10:26 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] A2003:Replacing 'tokens' in a string

Hi Shamil

Very good, Shamil, I love one-liners! But, of course, it won't work to look
up date or name.

I think a key element is reusability. By putting a little more effort into a
quick solution you may make it generic, thus much more reusable in other
projects.

Also, if you are trying to act as an experienced programmer, you have a
responsibility to think ahead and write code that can stand foreseeable
errors and changes - at least to some extent. If not, you may get bashed
with "you are the expert, you should have expected this or that to happen".
I find it unprofessional to hide behind "it was not part of the
specification". That said, you have to find a balance but the ability to
find or chose this comes exactly from experience.

/gustav
 

>>> shamil at smsconsulting.spb.ru 28-01-2010 07:56 >>>
Max,

How about that? (To satisfy original request of getting extracted just
AccountNo and InvoiceNo out of the source string.)

Dim s As String
s = "[AccountNo]=1234," + _
    "[InvoiceNo]=1234567," + _
    "[InvoiceDate]=04/01/2010,[Name]=Barry"
    
Debug.Print Val(Mid(s, InStr(s, "[InvoiceNo]") + 12))
Debug.Print Val(Mid(s, InStr(s, "[AccountNo]") + 12))

Yes, it's not "bullet-proof" but if the source string is guaranteed to have
specified format then that simple approach will work well.

Please don't start telling (you will not I expect but others here can I
guess :)) "we all know how "specified formats" can often change" - just
program against the current requirements and wait for the other day and new
requirements to come - that's is the current mainstream trend in agile Test
Driven Development...

We can spend a lot of time discussing what is the probability of the
specified source string format to change, and how to "bullet-proof" the
above lightweight coding(?) approach - should we? - that's not a rhetoric
question, folks - your opinions coming from your experience is wanted and
very welcome...

Thank you :)

--
Shamil



 

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 4812 (20100128) __________

The message was checked by ESET NOD32 Antivirus.

http://www.esetnod32.ru