journal.txt

The general process of working in atomic slices has been very nice -- it
prevents the temptation to rush through things, and makes it easier to cope with
stumbling blocks along the way. There is no big checklist to try to clear each
day, and so failures seem more tolerable when they are isolated. If one day goes
poorly, we can switch directions the next day and start fresh in a new area.

The process also makes it easier to learn from failures and difficulties rather
than trying to simply overcome them so that you can move on to the next thing.
If a feature turns out to be harder to implement than expected, you can go back
to the big picture planning and think about whether it should be reduced in
scope, cut, or deferred. (Why is this different than ordinary "multiple changes
per day" work? Hard to verbalize :-/)

--------------------------------------------------------------------------------

Around the point in time where I started working on the reminder mailer, I
started to feel a bit of the ill effects of cowboy coding rather than having a
more structured (i.e. test-driven) flow. But since I was still trying to figure
out the requirements of the project at that time, I was hesitant to formalize my
efforts -- I wanted to focus on the product, not the code.

--------------------------------------------------------------------------------

Working on the timezone support and storage of reminder times reminded me how
much I hate anything to do with temporal logic. After looking around at some
options, I decided to use the ugly Time.zone = ... before_filter which has
global side effects (but those are mitigated because we're not processing
concurrent requests, right?), and to record reminder times as integer offsets
rather than text fields or time fields. All of this feels like ugly hackery. :-/

Also got really hung up with form helpers for time entry, ultimately ended up
just using a text field which I plan to validate later. This is what ate a huge
chunk of my time on this feature though.

--------------------------------------------------------------------------------

Gave up on time zone math temporarily, because I was struggling with figuring
out how to synchronize the scheduler. Instead requiring hourly level of
granularity in UTC only. Could be worth going back and researching how to deal
with time correctly, and then writing an article (or even an eBook) on it.

I should have done this two days ago, rather than trying to solve the hard
problem first. Could have spent two more days on improving other features rather
than trying and failing on this one. ---UNDERSCORE THIS POINT IN ARTICLE ---

Most importantly, this is a matter of a tiny inconvenience, not a fundamental
limitation in functionality. Each user will need to look up their UTC offset at
most twice per year, and this is a side project mostly for my own personal 
use anyway.

-------------------------------------------------------------------------------

Stepped through the workflow of the app a few times and smoothed some of the
rough edges. I was originally going to also add email confirmation, but figured
YAGNI. Also wanted to add a "log out" button, but figured also YAGNI, since the
entire app is behind an auth wall, but this makes it cumbersome to switch
twitter accounts while using it. Not sure how to solve it, aside from a weird
"reset" button. Maybe deal with this when it's out of prototype mode?

At this point, the app has a fairly cohesive (if simplistic) feature set. Adding
any kind of historical view of data may require a bunch of secondary features,
such as content editing (rather than simply "giving up") and goal deletion,
among other things. But we'll treat those all as "problems for later" ;-)

-------------------------------------------------------------------------------

Got www.shipitdaily.com working, but annoyed by this heroku limitation:
https://devcenter.heroku.com/articles/avoiding-naked-domains-dns-arecords