davetron5000

Heroku sends them as a normal course of operations. Dynos get cycled daily. Why…not sure, but it happens and is well-documented by them that it happens. It's likely impossible to completely insulate against it, but if you design your jobs to be idempotent and safely retriable, rather than try to trap their signals, your jobs will be a lot more bullet-proof

Even if Heroku is working 100% normally and your code is working 100% normally, your jobs will get killed. The workers get SIGTERM'ed once per day minimum as dynos cycle. The more workers you have in flight on average, the more you will see this. The best thing to do is make your jobs retriable, meaning they are idempotent or otherwise can pick up where they left off. Then use resque-retry to have them automatically retry. That's what we've done, and now the only failed jobs we get are legit issues and not Heroku

The underlying technology doesn't change the fact that Heroku will send SIGTERM to all processes. Resque has good tools for automatic retry, so if you can make your jobs idempotent, configure them for retry and forget about it.

Author here. Apologies that the design of the website has been so distracting. I ultimately decided that I needed to ship, but I can see where those commenters are coming from (and I appreciate that most of you have been constructive). I CAN say you should all be glad to not see the 3-D book I created in Pixelmator. I saved you from SOMETHING, at least :)

Since I've now made real revenue just on the first days' sales, I feel more confident spending actual money on the site design.

I opted NOT to use a template because none of them seemed adaptable to what I wanted to do.

Anyone willing to help me out, or can recommend someone who would?

Author here. There is very little code in the book and it is split between Ruby and Java. The chapter on writing includes a fair bit about how the API documentation burden in statically typed languages is lower, since the types are part of the method signatures.

Author here. Thanks for these comments. They are not harsh and very useful and I can see where you are coming from with all of them. I do want to address these issues, but I also wanted to ship, so hopefully I can evolve the design and other aspects as you've mentioned.

sutterbomb's post is 100% correct. Energy companies are often under strong regulator pressure to reduce consumption or to reduce consumption of specific fuel types (e.g. coal). Compared to wind or solar, a voluntary reduction in use by customers is a much more cost-effective means of meeting such regulations.

This is not really true - I worked for the company that generates these reports. It's true that the default product is snail mail, but this has been shown to be highly effective at driving down consumption and is a net savings for the power company.

Further, the company in question does A/B test various ways of sending the report, including email-only to find the most cost-effective way to drive down consumption.

Finally, the neighbor selection criteria DOES account for empty homes and other demographics, where that information is available.

The report Jeff mentions could not have been made nine years ago as the company that generated Jeff's report (a company hired by PG&E) didn't exist nine years ago.

This has been my approach to internal service design as well. It's far easier to make sure people integrate properly by providing a rich, well-documented API client library than it is to rely solely on the REST-based one. REST APIs are hard to document, and require a lot of orthogonal boilerplate to even make the requests properly.

Making a client library is also a great way to "dogfood" your REST API - you know a developer will write code, not HTTP calls, to interact with your service. The client API allows you to test out that code and make sure your API is well designed.

I found it hard to edit the HTML slides compared to the markdown for showoff, and the font-size is overall really too small (and my attempts to tweak it break a several assumptions in the CSS/transformations). HTML is not a great way to write content. Showoff is much better for browser-based. And it does export to PDF