This is excellent. I always fail to keep track on my TODOS in files. Very useful.
Use a decent editor.
Auto-expiring TODO notes in Ruby
11–20 of 42 posts
Re: Auto-expiring TODO notes in Ruby
#12Lovely language / solution mismatch. Any compiled language would fit this much better - fail at compile time. Or in interpreted-o-world, at least do it at test time. I guess it's just lovely when deployed, working, test-passing software suddenly starts failing on a server (all servers at once, globally), because someone added a TODO a few weeks ago.
From the README:
"In your production environment, set DISABLE_DO_BY=1 to disable checks."
Re: Auto-expiring TODO notes in Ruby
#13This is excellent. I always fail to keep track on my TODOS in files. Very useful.
My TODO comments show up in nice view in GUI I use (Eclipse). I'm sure other GUIs have similar views somewhere. I'm also sure that plugin to turn old ones into syntax errors could be done in a day or two. That sound like much safer approach then runtime exception.
Re: Auto-expiring TODO notes in Ruby
#14Might it not make sense to invert the parity of the environment variable and require its being set for do_by to be used? I imagine most would rather set an environment variable in their dev environment than ensure it gets set in every possible production instance... :/ As much as 'turning off asserts' is the classical style, that's more to do with the design of older instrumentation than the sanity of it.
Good suggestion! I have noted it: https://github.com/andyw8/do_by/issues/2
Re: Auto-expiring TODO notes in Ruby
#15Why a function? I hoped it would just parse comments.
I think that's a good idea. Perhaps based on a standard format such as '# TODO 2014-01-01 Fix me' ?
Re: Auto-expiring TODO notes in Ruby
#16Lovely language / solution mismatch. Any compiled language would fit this much better - fail at compile time. Or in interpreted-o-world, at least do it at test time. I guess it's just lovely when deployed, working, test-passing software suddenly starts failing on a server (all servers at once, globally), because someone added a TODO a few weeks ago.
From the README: "In your production environment, set DISABLE_DO_BY=1 to disable checks."
Given that we are talking about lazy/overworked on top of lazy/overworked here, why any confidence that this will be done 100% of the time?
Putting time bombs in your code, regardless of a global configuration switch, is just asking for trouble.
Re: Auto-expiring TODO notes in Ruby
#17Wouldn't this be much more suitable to do in an IDE or compiler? Raising exceptions during runtime seems the wrong approach to me. I wouldn't be suprised if this is possible and used in e.g. Mylyn. Another idea would be to automatically create a task/bug/issue for every TODO created (which closes when the TODO is removed)
or an IDE that just scans the code files, picks out the lines of comments containing "TODO" and put them in a list in the gui, so you see it all the time.
Or generate a compile warning instead of a comment. Then it will annoy you constantly, with no risk to production.
Re: Auto-expiring TODO notes in Ruby
#18Re: Auto-expiring TODO notes in Ruby
#19So there may not be much awareness so this, but Ruby Rails (as noted below, the annotations or part of rails/rake) has this feature that you can add special annotations # TODO # FIXME # OPTIMIZE comments to you code, and "$ rake notes" to list them. it also allows you to have a custom annotations comments :
For a full description, see : http://rubyquicktips.com/post/385665023/fixme-todo-and-optim...
Better to make a # DOBY annotation and modify the rake task to shame if the date passed. You could also add this metadata to the existing annotations. If you what to automate the shaming, write a guard gem to watch for these annotations.
Re: Auto-expiring TODO notes in Ruby
#20This is excellent. I always fail to keep track on my TODOS in files. Very useful.
My TODO comments show up in nice view in GUI I use (Eclipse). I'm sure other GUIs have similar views somewhere. I'm also sure that plugin to turn old ones into syntax errors could be done in a day or two. That sound like much safer approach then runtime exception.
A day or two, really? That seems like an awfully long time requirement for what should be a simple change.