- February meetings - 1 Update
- Triple vodka - 1 Update
- TDD considered harmful - 2 Updates
- Let's talk about multiple inheritance and interfaces. - 3 Updates
- Unit testing (Re: Putting project code in many different files) - 11 Updates
- Name for a kind of function - 1 Update
woodbrian77@gmail.com: Feb 01 02:43PM -0800 I've taken info from this page http://meetingcpp.com/index.php/newsreader/items/c-user-group-meetings-in-february-2016.html and come up with this: The Meetings 1st Dublin - C/C++ Meetup 3rd Saint Louis - Resharper C++, Scott Meyers book, group exercise 10th Utah - Getting Started with C++ 10th Washington, DC - Q & A / Info Sharing 10th San Francisco - Reliability and security of today's software platforms 11th Dresden - TBA 15th Austin - Monthly C/C++ Pub Social 15th Zentralschweiz - C++11/14 Idioms 16th Berlin - TBA 16th Hamburg - Monthly meeting 17th Sacramento - Talk C++ 17th Düsseldorf - Building blocks of Metaprogramming 17th Seattle - C++2D Graphics Standardization 18th Berlin (Qt) - Have food/drinks and talk about Qt 21st Ho Chi Minh - HCM C++ User Group Meeting 23rd Macedonia - Emscripten - run your C/C++ code in web browser 24th San Francisco - Workshop and Discussion Group 24th Washington, DC - Q & A / Info Sharing 24th Stuttgart / Ludwigsburg (Qt) - Qt Meetup 25th Bremen - Lisp und ECL 27th Sofia - First Meeting ------------------------------------------------ If others are interested in a C++ meeting in the St. Paul, Minnesota area, please let me know. By the grace of G-d, I'm able to provide a meeting area in a conference room in the office building where Ebenezer Enterprises is, and I would be happy to give a talk or two. Last month https://groups.google.com/forum/#!topic/comp.lang.c++/o8whK7pA_sw someone said that not all of these "meetings" may be taking place. It sounded to me like the ones that have a specific meeting topic are real meetings and the ones that have a generic topic may be false positives. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
Gareth Owen <gwowen@gmail.com>: Feb 01 09:41PM > Is having a triple vodka a thing? Jesus wept, man, of course its a thing. I kind of assumed you had two or three before (re)starting each "... considered harmful" thread. By the way, loved you in Red Dead Redemption. http://reddead.wikia.com/wiki/Leigh_Johnson |
Cholo Lennon <chololennon@hotmail.com>: Feb 01 11:22AM -0300 > amazed that you cannot see this. > TDD is the totally wrong approach to software development. Design > first, implement second and unit test third. I agree with you. The first time I used TDD (don't confuse with writing a unit test, a common mistake) was in a TDD course that my company sent me. It was really weird. The teacher presented the problem to solve: convert decimal numbers to roman numbers. Well, my group designed and implemented the solution in a few minutes, wrong the teacher said! after that, he explained how we should think and solve the problem using TDD: Start with a simple test that fail. After that add the solution for 1 and test. Add the solution for 2 and test, etc. Try to find a pattern. The iteration process was long because the pattern was changing. It was your first time, the teacher said; future problems will be solved more quickly. I don't know, after several years of trying to apply the technic in C++/Java/Python I'am still unconvinded. The teacher explained that TDD avoids "analysis paralysis" (get stuck in a problem due to overthinking it). You have to think the problem on the fly, try, fail, fix... but IMO most of the time thinking in advance, solves the problem more quickly and with a better design. Regards -- Cholo Lennon Bs.As. ARG |
Gareth Owen <gwowen@gmail.com>: Feb 01 09:39PM >> public method which has the effect that some of your public methods MUST >> be unnecessarily large/complex. > TDD and using private methods are orthogonal. QFT. You might as well suggest that "Unit testing means you can't use static linkage". Private members are an implementation detail. You don't individually unit-test implementation details. |
scott@slp53.sl.home (Scott Lurndal): Feb 01 04:53PM >> > usually use smart pointers instead of raw pointers, even if it >> Speak for yourself, kemosabe. >Was "kemosabe" mean here as "trusty scout" or "faithful friend"? Neither, in this case. It's american slang from the era of the lone ranger shorts in the theaters. |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:07PM -0500 On 2/1/2016 11:53 AM, Scott Lurndal wrote: >> Was "kemosabe" mean here as "trusty scout" or "faithful friend"? > Neither, in this case. It's american slang from the era > of the lone ranger shorts in the theaters. Actually, it comes from even before that - the first radio broadcast when the Lone Ranger legend began. Except it was the Lone Ranger who call Tonto "Kemo sabe", not the other way around. I've still got a 78 rpm of the original broadcast. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Vir Campestris <vir.campestris@invalid.invalid>: Feb 01 09:20PM On 01/02/2016 20:07, Jerry Stuckle wrote: > Actually, it comes from even before that - the first radio broadcast > when the Lone Ranger legend began. Except it was the Lone Ranger who > call Tonto "Kemo sabe", not the other way around. Who are you calling tonto? <http://www.spanishdict.com/translate/tonto> (I didn't know that when I was a kid...) Andy |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 02:55PM -0500 On 2/1/2016 11:14 AM, Paavo Helde wrote: > something, then you cannot do code refactoring and code redesign. This > means that given enough time the codebase will turn unmanageable, > regardless of how good the design and specifications. If you do, yes. However, that's more work to correct the error and test again. Wasted time for developers and testers. I'm not saying you don't change or refactor code. I'm saying you shouldn't do it needlessly because you didn't test independent classes before dependent ones. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:01PM -0500 On 2/1/2016 2:44 PM, Ian Collins wrote: >> done is waste time and unnecessarily create bugs because the mock >> classes cannot, by definition, completely follow the specification. > So you've tried it, done it wrong and given up. Too bad. Nope, I've seen it done before, by more than one group. I've even been called in a couple of times to manage a project that was mismanaged that way. Projects that were late and over budget. >> duplicate the behavior of the real class. It can only do some of it. >> And that means potential problems are missed. > I can't? Bugger, what have I been doing all these years? of course I can. And you've been wasting time and money doing it. Or writing crap code. I'm not sure which. Maybe both. >> (unnecessarily). > Can't I? The transformation will be well defined and will be testing in > the real classes tests. Ever heard of a contract? Yes, I've heard of contracts. I've also seen people try your way and fail miserably. And they thought they were doing it "right" also, until they saw otherwise. > Yes, I would simply write something like: > test::FOO_decode::willThrow( std::bad_alloc ); > before calling the code that will call the decoder. But that doesn't emulate the out of memory condition. It just throws an exception. Many other things can go wrong when you truly are out of memory - things you aren't testing for. For instance - what happens if the class you're testing allocates memory while processing the out of memory condition? Since you aren't really out of memory, that allocation will succeed - where in real life it will fail. You have just introduced a bug. >> the file is truncated? Or any of a number of things a proper test suite >> would check? > It will - in the tests for the real object. Which means you will have multiple classes to test to see which one is failing. A waste of tester and developer time. >> Yes, you have. Now if you'd only learn how to do it correctly. > I'm lucky in that I already do. You don't appear to have got beyond > understanding what it is. You seem to be quite willing to spend your employer's or client's money unnecessarily. My job has been to ensure the projects come in on time, within budget and as free of bugs as possible. It looks like we have two different goals. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:02PM -0500 On 2/1/2016 1:03 PM, Geoff wrote: >> developer and a project manager. > That must be why IBM software is so reliable and never needs bug > fixes. :) Any software will have bugs. But IBM's have fewer bugs per K LOC than average. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:03PM -0500 On 2/1/2016 1:53 PM, Öö Tiib wrote: > Somehow when IBM and software are in same sentence then only horror comes > to mind ... Rational Rose, ClearQuest, Lotus Notes, WebSphere ... crazy > stuff done with apparently zero self-awareness whatsoever. And if you follow back, every one of those was a product produced by another company that IBM bought for one reason or another - not necessarily the products you mentioned. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Jerry Stuckle <jstucklex@attglobal.net>: Feb 01 03:05PM -0500 On 2/1/2016 2:45 PM, Ian Collins wrote: >> developer and a project manager. > Ah-ha, that explains it: in this part of the world, we would never let a > project manager anywhere near our code! That's why you fail. Good project managers here understand the code and the job being done. They are not mindless fools. That's how they successfully manage the projects. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
Ian Collins <ian-news@hotmail.com>: Feb 02 08:45AM +1300 Jerry Stuckle wrote: > recalls, either - and are quite stringent in their testing. > Neither are any of the other companies I have consulted for - both as a > developer and a project manager. Ah-ha, that explains it: in this part of the world, we would never let a project manager anywhere near our code! -- Ian Collins |
Ian Collins <ian-news@hotmail.com>: Feb 02 09:41AM +1300 Jerry Stuckle wrote: >> So you claim, but you continue (is is it choose?) to a display a basic >> ignorance of the practice. > Not at all. You appear to find the concept of developers delivering tested code a hard one to grasp. >> Where did I say otherwise? Exact quote please. > You said you wouldn't stress test code on a development system. Look > back and see. Indeed I did, but where did I say anything about not having "a test group and test system(s)"? >> Where did I say otherwise? Exact quote please. > You said you can't test for out of memory on a development system. Look > back and see. I know, but where did I say anything about there not being a test group? >> Please explain how mentioning embedded systems changed the topic. > No one was talking about embedded systems before you brought it up. > Look back and see. I know, but how was mentioning embedded systems as an example changing the topic? Please explain. > of testing. A couple of times I've taken over failing projects because > the developers were doing the testing instead of writing the code. > Projects that were late and over budget. So you are an advocate for developers delivering untested code? >> say it again: "From the perspective of software other than its driver, a >> device is a class other code". There, is that clear now? > Yes, it is perfectly clear you have no idea what you're talking about. Ah good, an insult. I'll take that as a concession. >> that are well defined by the customer. > Nope. But I don't try to mock classes, either. It just leads to more > work and more bugs. Ah good, avoiding the issue by changing the topic. >> yourself.... > Nope. Not at all. But you obviously don't understand the difference > between hardware and software. Response by insult again, good. -- Ian Collins |
Ian Collins <ian-news@hotmail.com>: Feb 02 09:45AM +1300 Jerry Stuckle wrote: >> Ah-ha, that explains it: in this part of the world, we would never let a >> project manager anywhere near our code! > That's why you fail. I'll be sure to let you know when we do. > Good project managers here understand the code and > the job being done. They are not mindless fools. So anyone who doesn't understand code is a mindless fool? You have a very poor view of most of humanity. > That's how they successfully manage the projects. They successfully manage the projects by enabling those doing the development to get on with their jobs.... -- Ian Collins |
Ian Collins <ian-news@hotmail.com>: Feb 02 09:59AM +1300 Jerry Stuckle wrote: > Manufacturers of operating systems and heavily used applications such as > IBM (where I first learned how to develop and test) don't like product > recalls, either - and are quite stringent in their testing. You must have missed this memo when you were there: http://collaboration.csc.ncsu.edu/laurie/Papers/agile07.pdf Care to comment? -- Ian Collins |
scott@slp53.sl.home (Scott Lurndal): Feb 01 09:11PM >Somehow when IBM and software are in same sentence then only horror comes >to mind ... Rational Rose, ClearQuest, Lotus Notes, WebSphere ... crazy >stuff done with apparently zero self-awareness whatsoever. Whereas I think "MVS", still highly regarded and very reliable (as z/OS). |
Paavo Helde <myfirstname@osa.pri.ee>: Feb 01 11:14PM +0200 On 1.02.2016 21:55, Jerry Stuckle wrote: >> regardless of how good the design and specifications. > If you do, yes. However, that's more work to correct the error and test > again. Wasted time for developers and testers. It's not wasted if the codebase turns better - it helps to save the efforts in the future. And there are no testers involved, I'm talking about automated test suite runs triggered either be the developer manually or then automatically by each check-in. > I'm not saying you don't change or refactor code. I'm saying you > shouldn't do it needlessly There is a need to refactor because otherwise the code would slowly turn into a mess. Some TDD/agile people advocate the idea that each time when you touch the code, it should leave the codebase generally cleaner, not dirtier. This means that in addition to adding the concrete feature or bugfix one should also look at the surrounding code and try to make it all work more smoothly together. > because you didn't test independent classes > before dependent ones. Now I am confused. What do you exactly mean by "testing before" and what this has to do with anything? I am talking about refactoring the code base when all tests are already succeeding. You cannot refactor non-working code, it would be pointless. So both the A and B components must be working and pass their unit tests before you can start refactoring. Cheers Paavo |
Victor Bazarov <v.bazarov@comcast.invalid>: Feb 01 09:22AM -0500 On 2/1/2016 6:22 AM, Stefan Ram wrote: > When a function »m« calls another function »f«, we call »m« a > »client« of »f«, but how to we call »f« then? One does not > call a function a »server«, does one? In the latter case I'm more familiar with referring to 'm' as a "caller" (usually inside the 'f' function), and if one has to give 'f' a special name, it's a "called function". However, given that the compiler is free to inline the code (or refrain from generating the code that would call it _at all_ in some cases), no special term is in common use, I believe. I have heard a "callee", but not often enough to make it customary. V -- I do not respond to top-posted replies, please don't ask |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment