john_p_wood

I just finished using these guys for a product I'm launching next week. Great service and great support. Highly recommended.

I thought the same thing. However, it looks like this was cleared up in another thread. It seems as though you are expected to join Living Social at then end of the training. So, it's not really an "offer" after all.

Something tells me that after making it though a program like this, you'll have plenty of job options, with the one from Living Social just being one.

I went to a code retreat back in July. It was a great experience, and I would highly recommend it. You can read about my experience at http://johnpwood.net/2011/07/29/what-i-learned-by-attending-...

The design was done in house at Signal by Drew Myler. That boy can make a pile of horse shit look sexy.

Good suggestion, thanks!

The time zone setting for the task is used to determine when Proby should be expecting a notification from that task. We're still thinking of the best way to display the times on the dashboard. Listing all of the tasks in the same time zone makes them easily sortable based on the last execution time (we could still support this sort order while displaying the tasks in their configured time zone...but it may be more confusing if each time was in a different time zone). We've also thought about listing all of the tasks in the user's time zone. Jury's still out on this.

Representing the cron schedule in some other format is also feedback we have received before. I just haven't found a way to cleanly and concisely display the schedule in a format other than the cron format.

Regarding the downtime...we don't manage that right now. We're running on a single VPS. The goal of the beta is to determine if there is enough interest (and potential financial support) to deploy Proby to a more robust and fault tolerant setup.

Thanks for the feedback!

I'll be expecting that pat on the back when I come in on Friday Doug...

Hello HN.

We were occasionally running into issues where our scheduled tasks would not start when expected. There were many reasons for this (environment changes, lock files not being cleaned up properly, etc). So, we created a simple application to monitor our scheduled tasks, and notify us if they didn't start or finish when expected. Now we're notified immediately (via email or SMS) when a scheduled task isn't kicked off when it is supposed to.

The app also keeps track of the run times for past task executions, which has been useful in tracking down unexpected changes in task run times.

Proby is currently in closed beta, meaning we're letting people in slowly. It is currently running on a VPS with a few other services. We want to see if there is an interest in the app before purchasing better/additional hardware.

Use of the app is currently free. At some point, when it is out of beta, we may begin charging a small fee for the service (although I'd imagine we'd have a free plan of some sort). But, all of that is still up in the air.

What do you think?

I haven't had much experience with database triggers, so it's hard for me to compare the pros/cons of using triggers vs using CouchDB.

Thinking about it, as far as the stats stuff goes, I don't think there is anything we did that can't be done via your suggested approach (triggers, materialized views, archive tables, etc). However, we're just a few developers here. We don't have a DBA. We're much more at home with Javascript than with the MySQL trigger syntax. So, CouchDB was a much more natural fit.

We're also making heavy use of the fact that CouchDB is schema-less. I'm not too familiar with the XML and/or JSON datatypes supported by the different relational databases, but some quick googling seems to indicate that querying the database for the contents of this data can be difficult. In other words, storing and retrieving XML appears to work OK, but (looking at Postgres) I can't seem to find a way to, for example, find all rows where the xml document in the 'xml' column has a <city> tag that is equal to 'Chicago'. Again, I could be very wrong here, I just don't see it after about 10 minutes of looking.

Working with documents is very natural in CouchDB, as that is what is was designed for. Not only can you easily find all documents with a city property equal to 'Chicago', but you can also programatically interact with that data in the map and reduce functions, using Javascript.

Ha, that's funny. I thought I coined the term as well until a Google search smashed my hopes.