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