[AccessD] Libraries and Frameworks [Was: AccessD Digest, Vol 98, Issue 7]

Jim Lawrence accessd at shaw.ca
Tue Apr 12 16:22:32 CDT 2011


Sorry about the previous post but I was typing too fast and hit the mouse
pad with the heel of my palm and the post was on it way.

The main advantage to a framework, especially if you know it well is the
speed you can get results and the price you have to impose on a client.

As a rule frameworks are the most ugly things ever created if you wish the
tinker or add extra functionality. 

I have been hacking together applications using ASP.Net in VS and then after
it is all roughed in, I go into code and start clear out the
garbage/resource directories and after a day or two there is a pretty good
lean piece of code left. After that I add those little extras, in JQuery and
create some nice graphics and smooth transitions. At one point in time I
will dispense with this 'hack' method but that wouldn't happen until I can
code in the language with my eyes (nearly) closed...in another 5
years...maybe.

Jim



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Kenneth Ismert
Sent: Tuesday, April 12, 2011 1:12 PM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Libraries and Frameworks [Was: AccessD Digest, Vol
98,Issue 7]

All,

> jwcolby:
> ...
> But in general the class functions are only used in the class.  A 
> function can be made to accept args and return a value and never 
> modify anything external to itself.  It would make programming some 
> functionality much more complicated however.  Let's take an example. ...
>

You have a very impressive system with a lot of capability. But frameworks
have their own inertia: for all that they do, they unquestionably limit your
choices and reduce your options for their sheer bulk. I have wrestled with
this in building my own frameworks, and have entirely dismissed third party
frameworks (Symphony comes to mind) for the thunderous overhead they impose.


Part of my interest in functional programming is an emphasis on simplicity
that helps to reduce this bulk, by reducing the scope of routines, and
restricting the kinds of interactions that can happen between code. This
kind of reductionism can actually increase your options, by giving you
flexibility.


> Could I break this down into umpteen other functions that (in the end) 
> every one only does one thing?  Of course, but I ain't gonna!
> ...
> They will never be called from anywhere else (in fact they are private 
> to the class) because no other code anywhere in the world performs 
> that step of address validation processing.
>

This sounds like correct factoring of code to me ... you don't want to
reduce it too small, and you want to organize in part by specialization --
general code is generally accessible, specific code is less accessible, or
not all all to outside code. For general VBA code, nothing is more easily
accessible than a public module function.


> I do not have a test department, I am the test department.  I am 
> actually fascinated with the unit testing concept but I barely have 
> the time to write the code itself, never mind code to test the code which
tests the code...
>

But, for the right client, this can be a valuable part of the deliverables
-- as Jim Dettman describes, a set of tests that validate basic function can
build a lot of confidence in a customer's eyes that they are getting
something that can be shown to work, and that it can be modified by others
with less fear of breakage.


> My question is, why do regression testing if we never regress?  I 
> write these functions and they are done.  They work or they don't.
>

I think the main point is to prove to someone else that your stuff works.
I'm a single programmer shop, so I'm just proving it to myself, and giving
myself some peace of mind that the really critical stuff has some backbone
to it.


> Jim Dettman:
> ...
>  As to your point about bugs and lines of code, unit tests are very 
> simple and limited by nature. ...
>

Yes -- clearly, if you get to the point where you are writing a lot of unit
tests for your unit tests, that's a sign that your test code might be too
complex, and you need to revisit your approach.

Shamil Salakhetdinov:
> ...
> Yes, VBA is not very capable language but the issue IMO isn't that it 
> (VBA) has limited capabilities - the issue is that VBA implementation 
> (within MS
> Office) is "crappy"...
> ...
> That "limited capability by implementation" was the main reason I did 
> mainly quit VBA development ...
>

Yes, I find I run into the COM-imposed 'ragged edge' far too easily in VBA.
I find that 'proper' solutions in VBA usually require more effort in dealing
with limitations than other platforms.


> ...
> Yes, JavaScript is a great programming language - I'm (trying) to get 
> it mastered now  (OO JavaScript) - and I really like it...
> And the paradox is that JavaScript isn't an Object Oriented language 
> but how powerful and flexible it's to simulate all/most of OOP 
> concepts...
>

Javascript is Prototype-based, which is a simpler (but still enormously
useful) object paradigm.

If you haven't run into it yet, I would recommend Douglas Crockford's book
"Javascript: the Good Parts", which very efficiently shows what to do and
what to avoid.

Also, I use Crockford's Javascript Lint, http://www.jslint.com/, which
promises to 'hurt your feelings'. But, it has never hurt mine, mainly
because it has rescued my crappy, non-working Javacript code too many times.


> ...
> I'm not sure how do you use VBA in TDD   - could you please elaborate a
bit
> more on this subject here?
> Do you have your custom VBA TDD framework?
> Or you just develop and use special test VBA modules/functions and 
> call that stuff TDD?
> That's OK with me - I'm just wondering what practice is behind your 
> VBA TDD terminology...
>

Right now, I do the most brutally simple testing possible -- if I have a
library module 'MFoo', I have a test module called 'testMFoo', with 'test'
functions that exercise like-named MFoo functions.
I just run the code by hand. I don't have perfect test coverage, either.
I'm not sure how or if I will automate it, but I suppose I could loop
through all of the 'test*' modules, run each of the 'test*' functions, and
log the results.

-Ken
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list