It seems odd that I've not seen this question here before, but maybe I missed it (or just don't get it on some deeper level!):
My current project require some libraries (e.g., CSV) that have been altered in 1.9. It's be comforting to know that when the time comes there's some quick way to flag the areas of my code that need attention if they're to run OK in 1.9. Yeah, it's be great if I had a test suite. but honestly, it's all I can do to get the code together in the first place. Tests are high on my todo list, but my need for my current project is higher by far, and I'm close to having a complete function set, so tests aren't on the menu today.
So - is there some 1.8-to-1.9 scanner or whatever?
Thanks,
t.
···
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website) << sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It seems odd that I've not seen this question here before, but maybe I missed it (or just don't get it on some deeper level!):
My current project require some libraries (e.g., CSV) that have been altered in 1.9. It's be comforting to know that when the time comes there's some quick way to flag the areas of my code that need attention if they're to run OK in 1.9. Yeah, it's be great if I had a test suite. but honestly, it's all I can do to get the code together in the first place. Tests are high on my todo list, but my need for my current project is higher by far, and I'm close to having a complete function set, so tests aren't on the menu today.
So - is there some 1.8-to-1.9 scanner or whatever?
Thanks,
t.
I'm puzzled by the underwhelming response to this question. It is a genuine one, for me, as I've not gone through a transition like this before, being new to this programming community.
I'm just curious about how others handle, or will handle, this problem. Surely one doesn't just launch the boat and hope there are no leaks, yes? There has to be a better way. But...for me, it's far from obvious.
Still hoping for some response...
Tom
···
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website) << sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's be comforting to know that when the time comes there's some quick way to flag the areas of my code that need attention if they're to run OK in 1.9. Yeah, it's be great if I had a test suite. but honestly, it's all I can do to get the code together in the first place.
So - is there some 1.8-to-1.9 scanner or whatever?
I'm puzzled by the underwhelming response to this question.
I'm just curious about how others handle, or will handle, this problem.
You appear to have answered your own question before even asking it. I'm not a Ruby whiz, but AIUI, the only way to build robust systems with dynamic languages is to test thoroughly.
Surely one doesn't just launch the boat and hope there are no leaks, yes?
[...] It's be comforting to know that when the time comes there's some quick way to flag the areas of my code that need attention if they're to run OK in 1.9. Yeah, it's be great if I had a test suite. but honestly, it's all I can do to get the code together in the first place. Tests are high on my todo list, but my need for my current project is higher by far, and I'm close to having a complete function set, so tests aren't on the menu today.
[...]
Surely one doesn't just launch the boat and hope there are no leaks, yes? There has to be a better way.
I doubt this is the answer you were hoping for. But deferring
writing tests is not generally a strategy for completing a
working project sooner.
If your need for your current project is high, having a
supporting network of unit tests continually verifying that
your features are still working _as you develop_ new features,
is a way to go faster over time, not slower.
One effective strategy for not falling behind in writing tests,
is to write a small test first (!) to verify a bit of
functionality you are about to implement in code.
For more info, see "Test-Driven Development Cycle", at:
[...] It's be comforting to know that when the time comes there's some quick way to flag the areas of my code that need attention if they're to run OK in 1.9. Yeah, it's be great if I had a test suite. but honestly, it's all I can do to get the code together in the first place. Tests are high on my todo list, but my need for my current project is higher by far, and I'm close to having a complete function set, so tests aren't on the menu today.
[...]
Surely one doesn't just launch the boat and hope there are no leaks, yes? There has to be a better way.
I doubt this is the answer you were hoping for. But deferring
writing tests is not generally a strategy for completing a
working project sooner.
If your need for your current project is high, having a
supporting network of unit tests continually verifying that
your features are still working _as you develop_ new features,
is a way to go faster over time, not slower.
One effective strategy for not falling behind in writing tests,
is to write a small test first (!) to verify a bit of
functionality you are about to implement in code.
For more info, see "Test-Driven Development Cycle", at:
Bill, Jeff - thanks. Your responses are genuinely helpful to me. I'm highly educated in some fields, but not in this one, so I'm often in need of guidance. I've wondered if I might have made a strategic error by deciding to defer testing, especially when I implement a new feature and then have to throw a bunch of ad-hoc tests at the code to make sure I'm still advancing on all fronts. OK, I get the message. Changing strategies, tonight. Sigh. I hope test writing goes faster than generating the core code (which, being Ruby, really has gone rather smoothly).
Thanks again (he says with some chagrin).
t.
···
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website) << sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...] I hope test writing goes faster than generating the core code (which, being Ruby, really has gone
rather smoothly).
Myself, I'd been programming for about 17 years before I first
read about TDD a decade ago. To this day, I often have to
cajole myself a little bit to proceed with writing tests first,
because it's not something i find 'easy', but 'worth it'.
In the past decade I've never yet regretted writing tests
first. A number of times, however, I have come to regret taking shortcuts with something that was supposed to be a
knock-off short-term project, where contrary to my predictions
it had morphed into a longer-term ongoing project where I
began to sorely regret having omitted writing unit tests from
the very beginning.
. . . So again, I don't find TDD easy; but worth-it.
-----Original Message-----
From: Tom Cloyd [mailto:tomcloyd@comcast.net]
Sent: Saturday, February 28, 2009 2:28 PM
To: ruby-talk ML
Subject: Re: conversion aid for 1.8.7 to 1.9.x transition?
Bill Kelly wrote:
>
> From: "Tom Cloyd" <tomcloyd@comcast.net>
>>
>>> [...] It's be comforting to know that when the time comes there's
>>> some quick way to flag the areas of my code that need attention if
>>> they're to run OK in 1.9. Yeah, it's be great if I had a test suite.
>>> but honestly, it's all I can do to get the code together in the
>>> first place. Tests are high on my todo list, but my need for my
>>> current project is higher by far, and I'm close to having a complete
>>> function set, so tests aren't on the menu today.
> [...]
>> Surely one doesn't just launch the boat and hope there are no leaks,
>> yes? There has to be a better way.
>
> I doubt this is the answer you were hoping for. But deferring
> writing tests is not generally a strategy for completing a
> working project sooner.
>
> If your need for your current project is high, having a
> supporting network of unit tests continually verifying that
> your features are still working _as you develop_ new features,
> is a way to go faster over time, not slower.
>
> One effective strategy for not falling behind in writing tests,
> is to write a small test first (!) to verify a bit of
> functionality you are about to implement in code.
>
> For more info, see "Test-Driven Development Cycle", at:
>
> Test-driven development - Wikipedia
>
>
> Regards,
>
> Bill
>
>
>
>
Bill, Jeff - thanks. Your responses are genuinely helpful to me. I'm
highly educated in some fields, but not in this one, so I'm often in
need of guidance. I've wondered if I might have made a strategic error
by deciding to defer testing, especially when I implement a new feature
and then have to throw a bunch of ad-hoc tests at the code to make sure
I'm still advancing on all fronts. OK, I get the message. Changing
strategies, tonight. Sigh. I hope test writing goes faster than
generating the core code (which, being Ruby, really has gone rather
smoothly).
Thanks again (he says with some chagrin).
t.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website)
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...] I hope test writing goes faster than generating the core code (which, being Ruby, really has gone
rather smoothly).
Myself, I'd been programming for about 17 years before I first
read about TDD a decade ago. To this day, I often have to
cajole myself a little bit to proceed with writing tests first,
because it's not something i find 'easy', but 'worth it'.
In the past decade I've never yet regretted writing tests
first. A number of times, however, I have come to regret taking shortcuts with something that was supposed to be a
knock-off short-term project, where contrary to my predictions
it had morphed into a longer-term ongoing project where I
began to sorely regret having omitted writing unit tests from
the very beginning.
. . . So again, I don't find TDD easy; but worth-it.
Regards,
Bill
Thanks Bill. I appreciate reading about your experience. Perhaps I can shortcut my own development a bit, with help from more experienced folks such as you.
t.
···
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: (360) 920-1226
<< tc@tomcloyd.com >> (email)
<< TomCloyd.com >> (website) << sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
