Got my first commit on a open source project this week:

Zombie callbacks on inputs

Thanks assaf!

I run into this problem with PDFKit middleware where the PDF generation seems to hang indefinitely for no apparent reason on Heroku as well as locally when using Thin.

Wkhtmltopdf will load the HTML and then try to load all assets from it (js, css, images, etc.) On Heroku the asset is first served up by the rails server and when you have a single Dyno it will create a deadlock in the handling of the HTTP request. The user trying to access the pdf document will consume the Dynos and the PDF generator will wait for it. Deadlock.

Two ways around that:

1. Access the static files directly from the web server and not Rails
2. Access the static files locally

The first option requires some setup (cloudfront and such) and some actions at deployment. Overall this requires to much work.

The second option is the one I preferred. I used Rails asset_host to have all assets for a PDF generation fetch locally (file://). Here is the gist of it:

Works as intended! Hope this will save some people the time I spent on this.

(Note: You first have to follow Matt’s instructions on how to install wkhtmltopdf on Heroku )

I just created a new repo on Github called template-fetch. The goal of those 60 lines of code is simple: retrieve an haml template from the server and process it on the client side using HAML (for now). I plan to add other templating engines when I have more time.

It uses jQuery, underscore.js and haml.js to do its magic.

It is mostly inspired from Sammy and was built when I was tinkering with Backbone.js . I think it can be useful to other, you tell me!

Comment are always welcome.

It seems that Sproutcore is gonna get some love - documentation, public API - that will for sure help build a stronger community and make its adoption easier!

On a related note, check out this nice write up on Sproutcore with Node.js .

At Porkepic, we moved our biggest customer to the online SaaS version of C3 last week. New UI, new color, same fonctionalities. Most of the transfert was done without any harm thanks to my partner Jean-Francois. 

We have a feature that allows a user to forward his emails from his mailbox to the software where he can link it to contacts, clients, contracts, projects, etc. We rely on Sendgrid parse API to do so. Basically, it receives the emails for you, parses it, and sends it to your web application as a POST. Pretty simple, yet kind of powerful.

As soon as Monday morning 8h, we were receiving complaints that the forwarded emails did not reach the application. Some of them did go through, but not all of them and in the software world we like it when it is true or false, but not sometimes. It seems some were dropped along the way but the sender was not receiving delivery failure emails. 

We contacted Sendgrid support, which is quick and as helpful as they can be, and they had no clues of what might be happening. To make a long story short, to me it seems that their mx.sendgrid.net server was not responding to all queries from SMTP servers trying to send mail to it. So the SMTP server queued the email for later delivery (as the mx server was reachable) which can happen within 5 min or 5 days. So we modified our DNS records to point to mx1.sendgrid.net, mx2.sendgrid.net and mx3.sendgrid.net and it did the trick!

So if you are experiencing the same problem with the parse API from Sendgrid that might just be your solution!