For our Simple In/Out users, you may notice a banner on the top of our product today.

Simply Made Apps is participating in the Internet-Wide Day of Action to Save Net Neutrality to oppose the FCC’s plan to slash Title II, the legal foundation for net neutrality rules that protect online free speech and innovation. Twitter, Reddit, Netflix, Amazon, Kickstarter, Etsy, Vimeo, Mozilla, OK Cupid, Imgur, Medium, and dozens of other major sites are also participating.

Simply Made Apps and other participants are displaying a prominent message to our users and encourage them to take action by contacting Congress and the FCC.

We’ve also submitted our comments to the FCC for ourselves and organized a letter on behalf of several North Dakota technology companies. For us, this is personal.  Simply Made Apps wouldn’t exist without open access to the internet, unfettered by companies charging fees as gatekeepers or extorting money from us to match the speed of our competitors.

See the announcement for the day of action and take action yourself here: https://battleforthenet.com

Net neutrality is making headlines again, as the current administration and specifically FCC Chairman and former Verizon lawyer Ajit Pai intend to roll back protections. We’re announcing that Simply Made Apps will join Amazon, Netflix, Kickstarter, Reddit, Github, and others on July 12 for the internet-wide Day of Action to Save Net Neutrality.

What is Net Neutrality?

Net neutrality at its core is the principle that all internet traffic should be treated equally.  This means that traffic from Netflix should be treated the same as traffic from an upstart competitor, crazy cat pictures, and social media.  ”Title II” of the Communications Act provides the legal foundation for net neutrality and prevents Internet Service Providers like Comcast, Verizon, and AT&T from slowing down and blocking websites, or charging apps and sites extra fees to reach an audience.

This is critical to how the internet works.  If competing companies can simply spend untold amounts of money to speed the delivery of their services over their competitors, what could ensue is a world whereby only those with money can be heard.  That’s the opposite of what has made the internet the greatest tool for the exchange of ideas and free speech in the history of civilization.

This is a personal matter to Simply Made Apps.  We’re a small company, currently with four employees and a Yorkshire terrier marketing intern.  We couldn’t exist as a company if our competition could outspend us to deliver their product faster or slow our product down.

What Are We Doing?

On July 12, 2017, websites, Internet users, and online communities will come together to sound the alarm about the FCC’s attack on net neutrality. Our product Simple In/Out will join the others on the web to highlight this issue and raise awareness.

Learn more and join the action here: https://www.battleforthenet.com/july12

Adding users to your Simple In/Out organization is often the first task you must undertake as an administrator. Some time back, we added the ability to add multiple users at once to speed this process along. That feature works great today, but it still means as an administrator that you need to gather a list of all the email addresses of your users. This is easier than adding all the information yourself, but we can do better.

Simple In/Out now has Invites, an easy way to allow your users to sign themselves up to your Simple In/Out board. Using Invites, an administrator can create a URL that others can use to join their organization. Admins can choose how long this URL is valid (an hour, day, or week) and distribute the URL however they like. Email, Slack, internal wiki… however one communicates with their team.

Once users click on the Invite link sent to them, they are taken to a page to type their name, details, and choose their own password. Afterwards they will be signed in, they appear on the company board, and they can use their account to access any and all apps in the Simple In/Out ecosystem.

We think Invites will make lives easier for a lot of our customers when they are getting started.

We recently discovered an issue with Automatic Status Updates that effects anyone running Android 7.0 and higher.  We have just shipped an update that should solve these problems. If you have an Android device and are using any of our automatic updating features, we strongly recommend grabbing our latest update.

In order to solve the problem, Simple In/Out will now require full background access to use Automatic Status Updates.  If you have received a notification or an alert that has prompted you to give Simple In/Out full background access, you must accept the permission changes in order to continue using Automatic Status Updates.  Selecting ‘No’ will turn your Automatic Status Updates off.

Automatic Status Updates were not working consistently on Android 7.0 because the app did not have full background access.  This caused certain events not to fire when the app was in the background and therefore some Automatic Status Updates were missed.  We no longer allow you to enable Automatic Status Updates without full background access.  If you have a device running Android 6.0 or higher, you will asked to whitelist Simple In/Out so that it can run in the background.  Battery life will only be slightly impacted (no more so than in the past).  We will always take battery life very seriously here at Simple In/Out.

We are sorry for our bug, it was our fault for not requesting this special access sooner.  Do reach out to us if you have any questions or concerns, we’re here to help.

We’re aware of issues with our Simple In/Out app and phones running Android 7 (Nougat). For these devices, you may notice that automatic updates via Geofences, Beacons, and Networks sometimes don’t get sent to Simple In/Out.  We’re actively working on a fix and will have it out just as soon as we can.

If you’re an Android 7 users and you’re experiencing this issue, please reach out to us via email and we’ll notify you personally when a new version of the app is available.

We apologize for this bug and any disruptions this may cause. It’s our fault and we intend to get this resolved as quickly as possible.

Today we’re announcing not one, not two, but three great new features for Simple In/Out.

Reminder Notifications

Since the beginning, we’ve focused on making Simple In/Out the most accurate in/out board ever. Even with automatic status updates, you may still encounter times when a user’s status is out of date. In these cases, having the user make a quick update would be best, and today we’re shipping a much-requested feature to help: Reminders.

With Reminders, Simple In/Out can send a notification to the user’s phone or computer reminding them to update their status.  The organization’s admin users can create reminders, choose the status and time they wish to reminder users, and we’ll do the rest.  Simple In/Out will only send reminder notifications to the users that need reminding.

This is a simple and effective way to nudge your users to keep the Simple In/Out board up to date.

Safety Notifications

For managers, sometimes you need to know at certain time periods if all your users have checked in or out. Have users going out into the field and need to make sure they’ve checked in at the end of the day?  Need to be sure users have checked out at the end of a shift? Want to be aware of who is in late at your office? For these use cases and more, we’re announcing Safety Notifications.

Safety Notifications allow those with sufficient privileges to choose the status and users they’d like to know about and when they’d like to be notified. Simple In/Out will send a notification to a phone or computer if those users are still in or out. Quickly tap/click the notification to see a list of all the users that are still in or out after that time.

Safety Notifications are not a replacement for emergency services and shouldn’t be used in life and death situations, but it’s a solid step towards keeping users informed of potential problems with their staff without having to remember to look at the in/out board.

Website Changes

We’ve made some website changes to accompany these new features. We’ve added pages to highlight many of the best features we offer in Simple In/Out.  These pages address specific use cases better than ever before. We’ve also moved many of our tutorial videos to these pages to make them more visible.

We now also support Spanish on every page within Simple In/Out. While we’ve support Spanish users once they had logged into Simple In/Out, we now cover all the pages so our Spanish users don’t have to speak some English to get logged in.

We know our users will put these great new features to work for their organizations right away.

Simple In/Out is a Rails app running on Heroku with several background jobs that need to be scheduled to run either hourly, daily, or weekly. Being on Heroku means we can easily use Heroku Scheduler to run a job every hour or every day. We could even use a daily job and check for the day of the week to accomplish weekly jobs.

We recently needed to schedule jobs to run more often than every hour, and Heroku Scheduler can no longer do everything we need it to do.

Introducing Simple Scheduler

Simple Scheduler is a scheduling add-on that is designed to be used with Sidekiq and Heroku Scheduler. It gives you the ability to schedule tasks at any interval without adding a clock process. The goal of Simple Scheduler is for it to be delightful to use and for it to ensure your scheduled jobs always run, even if there is server downtime.

Why We Created Simple Scheduler

Why did we need to create yet another job scheduler when there are plenty of options available?

We evaluated every possible option we could find, and every solution seemed to have the same flaw: What happens if your server is down when your job is supposed to run? TL;DR: Your job won’t run.

The existing solutions out there don’t keep track of whether a scheduled job was actually run. This means there is no way for your app to know that a job that was scheduled to run at 1:00 AM didn’t run because the server wasn’t running at 1:00 AM. What if it was a critical job that needed to run??

Another problem with certain solutions is that the job scheduling happens in the web process. This can be a huge problem if you’re on Heroku with multiple web dynos. Each web dyno would have it’s own job queue and every job would be duplicated.

One more thing we didn’t like about most other solutions is the cron format. We’re Rubyist, so we’re used to nice things. Why use such a hard to read format for scheduling your recurring jobs? Would you rather read cron: "0 * * * *" or every: "1.hour"? I’m nitpicking here, but I don’t want to remind myself how the cron format works every time I create or revisit a scheduled job.

How did we solve the problems with the existing solutions we evaluated?

Solution #1: Server Downtime

Simple Scheduler is set up to evaluate your configuration file every 10 minutes via Heorku Scheduler and queue jobs that need to run in the next 6 hours. A minimum of two jobs is always added to the Sidekiq::ScheduledSet. This ensures there is always one job in the queue that can be used to determine the next run time, even if one of the two was executed during the 10 minute scheduler wait time.

If your server is down when a job was scheduled to run, it obviously won’t run at the scheduled time, but the job will still be in the Sidekiq scheduled job queue. When your server comes back online, the job will execute immediately. This brings up another problem: What if my server is down for an hour and a job is scheduled to run every 10 minutes?

By default, every job that was scheduled will be run. This means if your server is down for an hour, your every-ten-minutes job will immediately run six times when the server comes back online. This may or may not be desirable, and there are two solutions for handling how these jobs behave.

Expected Run Time vs Actual Run Time

Simple Scheduler passes the expected run time to your job’s perform method if it accepts an argument. Let’s say you want to send a daily digest email to all users at a time they specify. Background jobs are never guaranteed to run at an exact time, so using Time.now to find all users who want to receive the email at 8:00 AM may not work. The job may not run until 8:01 AM, or worse, it may not run until 9:00 AM. Evaluating the expected run time passed to your background job will ensure you don’t send the email to the 9:00 AM users twice and skip the 8:00 AM users.

If you have an hourly job that performs the same task every hour, you may not want it to run twice in a row if your server is down for over an hour. The Simple Scheduler config allows for an expires_after option on a scheduled task. If you specify that a job expires_after: "59.minutes", only the last job will run because earlier jobs will be considered expired and won’t be run.

Solution #2: Multiple Heroku Dynos

Simple Scheduler is a rake task that is run every 10 minutes via Heroku’s Scheduler, so we’re not doing any job queuing in the web process. You can have as many web dynos as you need, and your queued jobs won’t be duplicated. Once queued as a scheduled job in Sidekiq, the rest is handled by your Sidekiq worker dyno(s).

Solution #3: Pretty Configuration File

I remember having the idea of a perfect YAML configuration file in my head before creating Simple Scheduler. I told Brandon, “Let me try some README-first development to solve this.” You can see my initial README here. I presented the README and said, “I don’t know if I can pull it off, but it’s awesome, right?” It is awesome. The Simple Scheduler configuration file is so pretty and easy to understand:

# Global configuration options and their defaults. These can also be set on each task.
queue_ahead: 360 # Number of minutes to queue jobs into the future
tz: nil # The application time zone will be used by default

# Runs once every 2 minutes
simple_task:
  class: "SomeActiveJob"
  every: "2.minutes"

# Runs once every day at 4:00 AM. The job will expire after 23 hours, which means the
# job will not run if 23 hours passes (server downtime) before the job is actually run
overnight_task:
  class: "SomeSidekiqWorker"
  every: "1.day"
  at: "4:00"
  expires_after: "23.hours"

# Runs once every half hour, starting on the 30 min mark
half_hour_task:
  class: "HalfHourTask"
  every: "30.minutes"
  at: "*:30"

# Runs once every week on Saturdays at 12:00 AM
weekly_task:
  class: "WeeklyJob"
  every: "1.week"
  at: "Sat 0:00"
  tz: "America/Chicago"

Start Using Simple Scheduler

I couldn’t be more proud of the work I put into making Simple Scheduler a pleasure to use, easy to understand, and I am so happy to be able to share it with the Rails community! This is some of the best code I’ve ever written, and it solves real problems.

Simple In/Out has been using Simple Scheduler in production since the middle of December 2016, so what are you waiting for?? Check out our GitHub repo to get started.

Dear Phil Schiller,

My name is Brandon Medenwald and I co-founded a small company called Simply Made Apps in Fargo, North Dakota. Our product, Simple In/Out, has embraced your developer platform since 2011. We have 3 native apps for iOS, a tvOS app (making us one of the few business apps in the tvOS Store), and a native app in the Mac App Store. I mention this to bolster my credentials as exactly the kind of developer Apple hopes to foster.

I write you today to share my frustration with the sporadic nature of App Store reviews and to offer what I believe is a great solution. I hope by the end of this letter to convince you of the merits of my idea.

The Problem

The problem is the uneven application of the approval rules, the root cause being that individual App Store reviewers have broad discretion and finite time to check apps for every single one of the mounting guidelines that exist. This is understandable as reviewers are only human. The fact is that an “issue”, an item that has been approved countless times in the past, can stop our development cycle cold.

When we have a new feature to ship, many times we need to go live with all of our apps and related API services at the same time. Recently, one of our apps was rejected for violating Rule 2.3: Performance: Accurate Metadata. Specifically, we had mentioned in our app description that our 45 day free trial was available with “no credit card needed”. For any developer submitting to the App Store, these so-called “metadata” errors are perhaps the most frustrating. They are arbitrary in nature and often at the mercy of the reviewer’s interpretation. This language, for example, has been in our app description for years (plural) and has been approved every single time.

While this example stopped us in our tracks despite not being an issue in prior years, at least we were able to resolve it quickly. Other times we have not been so fortunate, like In-App Purchase demands placed on Software-as-a-Service companies like mine. In these instances, it’s weeks of work before anything else can ship even though we’ve made no changes around these “violations”.

I understand that Apple has policies that are subject to change. I also understand that Apple internally emphasizes/changes rule interpretations to clamp down on bad practices. This is all well and good, but the frustration from developers like myself is that these indiscriminate rejections appear out of nowhere and often happen at the worst possible moments. We’ve had multiple instances where bug fixes were thwarted by a seemingly-random cracking of the metadata whip.

You see Phil, I want to be a good App Store citizen and the changes your reviewers demand are not bad or unreasonable. What is unreasonable is that I cannot schedule our programming resources around rejections on existing functionality/metadata that have been approved countless times in the past. This has knock-on effects on our non-Apple developers, our customer commitments, and our marketing efforts.

The Solution

I write to you not just to complain but to offer a solution that I believe will solve this problem in a way that is both fair to developers as well as to Apple. The solution comes from the real world: law enforcement and the Fix It ticket.

Let’s say you are driving down the road and you are pulled over for a broken headlight. The police officer does not issue you a fine, you are not placed in jail, and your planned trip is not measurably disrupted. You are provided with a Fix It ticket which gives you 30 days to have your headlight repaired and you resume driving. Your travel plans remain intact while you have the flexibility to schedule the repair over a month’s time. If you do not repair your headlight within 30 days, then you suffer the consequences the next time you travel.

I believe a similar solution would work wonders within the App Store review process.

If you are found in violation of a non-critical rule and that same violation existed in the previously-approved version of the app, the reviewer would approve the app for sale and would issue a Fix It ticket. This ticket would specify the violation and start the 30 day clock. After the 30 day period, Apple would block all approvals if the violation hasn’t been resolved.

This policy would allow critical bug fixes to go through without the delay caused by rules being interpreted differently from review to review. The 30 day warning would be on the developer’s account, making it easy for your App Store reviewers to see what other reviewers are doing and reject those that haven’t complied. Fix It tickets would reduce animosity towards the review process by creating a system where the only ways to have updates rejected is by creating new violations entirely or ignoring Fix It tickets for longer than 30 days. Apple can change emphasis on the guidelines without placing the hammer to all updates big and small.

Most importantly, this would allow developers like myself to schedule these fixes without arresting our entire development process.

I hope this idea can be implemented in the future for the good of Apple and the developer community. I would welcome a dialog on this matter at any time and my email address is below. Thank you for your time.

Sincerely,

Brandon Medenwald

Co-Founder, Simply Made Apps, Inc.

brandon [at] simplymadeapps [dot] com

With the release of Office Hours yesterday, what may have been lost in the shuffle was a new feature for our macOS app:  Notifications.  Simple In/Out for Mac was the last app in our family of products that didn’t have support for notifications when a user you are following updated their status.

We still have notifications built into the Safari web browser, which our Mac users have had to use to receive notifications in the past.  We plan to remove this feature in the future and rely solely on our native Mac app.  The Mac app allows you to manage the users you are following in one easy to use screen.  The Mac app also works great with Office Hours.

For those Mac users that have used Safari to get these notifications, we recommend giving our Mac app a download from the Mac App Store.  For our existing Mac customers, we hope you like the great new features we’ve added this month.

Simple In/Out’s goal from the very beginning has been to be both accurate and easy, two things that are difficult to achieve at the same time.  To accomplish this, Simple In/Out has been the champion of automatic features to both keep your status up-to-date as well as keep you notified about the happenings within your organization.  These automatic features are what make Simple In/Out the best in/out board in the world.

While these automatic features are wonderful, there are times they can be a bit overwhelming.  Perhaps your work place is in a popular area of town and you end up automatically checking in/out on the weekends while you are running errands.  Maybe you have notifications sent to your phone when others change their status and they are working late in the evening.  During these times, you may want Simple In/Out to halt for a bit and pick up later when you’re actually going to work.

We’re proud to announce a new feature we’ve been working on for the past few months to address these scenarios and more.  We’re calling this new feature Office Hours, and it has turned out really great.

With Office Hours, you can designate windows of time that you wish Simple In/Out to perform its automatic tasks.  When you’re not within those time periods Simple In/Out will stop doing things like sending you notifications and checking you in/out.  When you enter back into a normally-scheduled work time, Simple In/Out will resume its normal behavior.  Office Hours allows unprecedented control over our most popular features.

Want to make sure you’re not checking into job sites on your off day?  No problem.

Want to stop getting notifications from other users when you’re unwinding at the end of the day?  No problem.

Want to surf the web on your work laptop without checking in on a Saturday morning?  No problem.

We know our power users will love Office Hours.  This is only the beginning of what we’re planning for Simple In/Out this winter.  We can’t wait to show you the rest of the amazing new features we’re working on.