Just wanted to let you all know that the outgoing number for all text messages from SendRecurring is changing to 213-214-0476. For you global users, that is a United States number, so make sure you add a +1 in front of any filters that you had in place for it or in any address book entries.

Let me know if you have any questions! conrad@sendrecurring.com.

New Feature

This morning I put the final touches on the latest feature for Sendrecurring: a longer than monthly option! Users can now schedule reminders to send any X number of months. However long you want!

You will see the new box when you go to create or edit any reminder:

This is a great feature that a lot of users have suggested. I really wish I could have implemented it sooner but it is a more difficult thing to code than you would initially think, due to every month having a different number of days and leap years, and that Python does not have an “Increment by Month” function in their datetime library.

For those that are curious I will brain dump a little on how I implemented it.

Technical Stuff Beyond This Point

The original system for monthly reminders was pretty simple and foolproof, I would simply add days to the current date until I was at the date that a reminder should be scheduled. This handled both cases of initial creation of a reminder and rescheduling a current reminder really well.

In the new system I could not do that. Reasons include that a new email will need to be sent this month, not X number of months away, and that a reminder past its send date due for rescheduling should be rescheduled X number of months away.

I added some checks.

1. I check if the current time is after the reminder/emails scheduled time (ie already past). If it is then I automatically start looking at future dates for it to be scheduled.

2. I check if the date of the reminder’s LAST scheduled send is before todays date. Brand new reminders will not have this, so that is an indicator that one is brand new. If today’s date is after the last scheduled send then that means it has been scheduled before and any subsequent schedulings will use the X number of months information.

A snippet of source code below (this is rough and untailored for the blog) but could make some sense if you really need to a solve  similar problem. Just ask me if you want clarification :D.

  if localdatetime > localsendtime:
      localsendtime += datetime.timedelta(days = 1)
    try: eml = email.localsendtime
    except: eml = None
    if eml and localdatetime > eml:
      #add months depending on monthpattern
      try: monthpattern = email.monthpattern
      except: monthpattern = 1
      #add months if the monthpattern is 2 or higher
      if monthpattern > 1:
        monthdays = (monthpattern)*30
        localsendtime += datetime.timedelta(days = monthdays)
    #add days until it is the correct date
    while getattr(localsendtime, "day") != email.rpattern:
      localsendtime += datetime.timedelta(days = 1)

A few of you may notice that I use monthpattern * 30 for the “month” increment. This is actually slightly lower than the real days per month average of 30.4. The downside to this is that if someone does a really long monthlypattern, the days could eventually be off. It would need to be off by an entire month for the subsequent datetime.timedelta(days = 1) to no longer “catch”  the desired date so there is some buffer for error.

I will be keeping a watchful eye on what happens with this. Anything over 75 months may be inaccurate, 6.25 years. I wonder if anyone would really want to be reminded about something that far off.

Sendrecurring.com is getting some upgrades!

You may have noticed some minor upgrades over the past weeks such as corrections to wording and description, and better validation on lists of comma separated emails, but BIG changes are on the way.

Around a year ago I posted about how Sendrecurring would do away with logins and instead get by with actions confirmed via email. This led to the currently-in-place system whereby you must click a confirmation link with the creation of each new recurring email. This works, but it has it’s flaws. Chief among them is that it is difficult to manage large numbers of emails as you are constantly bouncing between your inbox and Sendrecurring. Also it can be tedious filling in the same owner email, and timezone information for every email, those things would be better stored long-term… SOOO

Sendrecurring is getting user accounts!

User accounts will begin being rolled out soon. If you read this and would like an account now head on over to the signup page and then proceed to the login page. You will be confronted with a single confirmation email (likely your last one if you make an account) before you can being using it.

What will you find after logging in? A MUCH nicer dashboard for handling all of your emails!

Some improvements to point out:

1. All of your emails are listed out for easy viewing of everything you have running
2. Turn Off and Turn On toggles
3. The Next Send time is clearly visible
4. It’s just so clean!

And the improvements do not stop there, look at how much simpler the email creation form is for you:

 

Improvements here include:

1. No “Owner” email. You are already logged in you don’t need to enter this!
2. No Start Date and End Date or Duration boxes. What? How? Email starting and stopping will be controlled by the Turn Off and Turn On buttons on the manage page, overall much easier to understand and use than all the date selection boxes! New emails will start out Turned On and you can toggle them to your heart’s content from there.
3. A much improved time entry box. There’s still a drop down for time selection if you want it, but the new box also allows you to type out times such as: “3:30 am” “15:00” “12 45” and auto-completes a correct time from there.
4. No limit on specific times. Previously the time dropdown was limited to send only in hourly increments. Well that is gone now. The new type-in time box, coupled with the server improvements allow emails to be sent at any time you want, 5:31 am? Sure. 6:47? Whatever. I expect the majority of emails will still be sent at even or quarterly times, but the option for any time was often requested, so here it is!

These new features will not be replacing the current features… right away. I do plan to phase out the non logged-in email creation with support for updating the emails you do have continuing on for quite some time.

Expect the landing page to have some information about logging in and the new account in the near future.

Also, all this great stuff is still going to be offered for free!

Tell your friends and coworkers!

Thanks,

Conrad Frame

 

There was a 12-hour outage to the mail system of the site today.

Luckily, I was notified by a few users that their emails were no longer going through and that even the confirmation emails were not being sent, in fact, no emails were being sent. I was able to get a hold of Google (who is hosting Sendrecurring) and get the issue resolved

The issue was due to Sendrecurring switching to the high replication datastore recently. The Appengine service gave Sendrecurring the “default” limit of 100 emails per/day after the switch, to be upped back to the regular limit after the first billing cycle (one week). Well, Sendrecurring hit that 100 limit very quickly before users started noticed the problem. The limit is back up to the normal one now.

Sorry for the gap in service.

Send on

Sendrecurring is moving forward after many months on the back-burner! I am excited to be working on it again.

To kick things off I did some changes behind the scenes, sorry, not much to see from outside appearances. I won’t keep it a secret that I am using Google App Engine as the backend for Sendrecurring. A year ago they offered a new feature called the High Replication Datastore, which is a fancy term describing how an app is spread across Google’s servers, which I had not taken the opportunity to upgrade to. I did that this evening! Hooray for security, server safety, and data redundancy!

Secondly, I cleaned up all of the html template files for that front-end of Sendrecurring. I don’t know what I was thinking 1.5 years ago when I hacked them all together, but they were a disorganized mess. Things are more orderly now, and some sense has been established.

Why am I doing these changes to the backend? Well I am preparing for some big changes to the overall application and would like clean plumbing before diving in too deep.

Changes forthcoming, possible features are….. logins, saved contacts, open-rates on emails, attachments and definitely more fine-tuned recurrence options and delivery.

 

Thanks!