Time throws a kink in programming sometimes.
Time throws a kink in programming sometimes.

Programmers are no stranger to obstacles, but some seem a lot more daunting than others. Time has been my Achilles heel from the beginning–getting time wrong is a major issue for the front end (and the back end too). If a user thinks their Invitation is set for 4:00PM, but they see 9:00PM on their phone, they’ll be wildly confused! So we as developers have to get this right.

In steps JodaTime, a library with the sole intent of making this struggle a little less of a nightmare.  It’s still no walk in the park, but it’s definitely an improvement. One of the biggest use cases for time is converting between time zones. For instance, you should store all times in your application in one time zone (with the understanding that you have users from different time zones), and then that time is converted to the user’s time zone on the front end.  UTC is the standard that is commonly used for storing timestamps on the back end.

To use JodaTime to convert from UTC to the user’s time, do the following:

DateTimeFormatter formatter = DateTimeFormat.forPattern("yyyy-MM-dd HH:mm:ss").withZoneUTC();
DateTime dateTime = formatter.parseDateTime(someStringTime.withZone(DateTimeZone.getDefault();

Of course, there’s more than one way to skin a cat! Head over to JodaTime’s site, and figure out a way that works for you!

Happy coding!
Brandon from The Bunch

Timed Broadcast


We’ve been hard at work to bring you new features to enhance the LunchBunch experience, and one of our recent updates modified the way that broadcasting works.

Before our public launch, a user suggested this feature to make it easier to broadcast accurate information. She said she wanted her broadcast to terminate automatically because she didn’t “want to lose [her] LunchBunch integrity.” We thought this was a great idea because it’s easy to forget to switch back to “not hungry” after you’ve eaten.

Timed broadcasts will keep you hungry for one hour before automatically expiring. (Soon you will be able to change this length.) A few minutes before it’s switched off, you will get a push notification asking if you are still hungry with the option to extend your broadcast. Ignoring the notification will terminate the broadcast at the end of the timed period.

Timed broadcasts make it easier for you to use LunchBunch because you don’t need to remember to set your status to “not hungry” after a meal. This also helps hungry buddies know that you are ready to eat (instead of wondering if you simply forgot to edit your broadcast after your last meal).

What do you think of this new feature? Are there any other features we could add to make broadcasting even easier? Let us know in the comments below!

Ryan from The Bunch

Development and Production Environments

When you’re working on an app that’s live, it’s a good idea to have a development version running that is completely separate from the production version. This way, when things go wrong (and they will), your users are less likely to be affected. Here are three things to consider when separating your production and development environments.


This should go without saying, but the dummy data used in testing shouldn’t be be available in production and vice versa. It shouldn’t even be stored in the same databases. Confining user data to production keeps it safer, and keeping test data out of production makes your live databases cleaner.


Keeping separate hardware is wise depending on the type of application you’re running, how many users you have, etc. It’s likely that the required load on the production server will be much higher than the server your team uses for development, so the hardware needs won’t be the same. By separating the hardware, you’re able to scale up and down independently and with minimal impact, and it also helps to reduce the impact of each environment on the other.


Dev servers can have have different authorization permissions to make sure that the right people have access to your application until it’s secure and ready for public use. Security updates and other patches for your OS, libraries, etc. can be issued on your development server without affecting production. That way you can handle upgrade issues on dev and be more prepared when you need to update production.

Two environments is the minimum you should consider configuring for any application. Depending on the size of your team and the nature of the application you’re working on, it’s usually a good idea to have a staging environment which is treated as the most-recent stable development build which is next in line to be pushed into production. It’s also a good idea to have local environments for each developer to work individually without affecting the rest of the team. So the workflow looks like this:

  1. Developers work on their branches locally.
  2. When the local build is ready, it is pushed to dev for the rest of the team to use.
  3. When the dev build is stable, it is pushed to staging.
  4. Once approved by quality assurance and beta testers, the staged build is pushed to production.

This is a very high-level overview of multiple environments, and each project has different needs, so this is in no way a comprehensive writeup about how your pipeline should operate. However, if you’re getting started on a project, I hope this article has given you some ideas to consider.

What do your environments look like? Anything you would add to this post? Let me know in the comments below!

Happy coding!
Ryan from The Bunch

Use Case: Not on a Campus or in an Office?


I’ve talked about how useful LunchBunch is in college and in the office, but what about the rest of us?

I organized many meals on campus while attending the University of Delaware and also in work settings during various internships over the past few years. But since graduating in May 2014, I’ve been working on LunchBunch from home which means a lot of meals by myself. So how is LunchBunch useful for those of us who aren’t on a college campus or working in an office? Here are a few of the ways I use LunchBunch that might help you, too.


A pizza place in Pittsburgh hosts a trivia night every Tuesday, and one of my friends was the trivia host there for a while. A bunch of us would go most weeks to eat pizza and compete in the trivia, and LunchBunch was a great way to see who was going on a particular night. The time and location were already decided, and seeing everyone’s RSVP helped us to decide if we should go or wait until the next week when more friends could make it. Trivia is a specific use case, but LunchBunch is helpful for planning similar weekly events.

Last-Minute Plans

You just returned home after running errands, and you have some free time. There’s a new restaurant you’ve been wanting to try out, so you hop on LunchBunch to see who wants to join you. You know it’s last-minute, and it’s too much work to message people individually. With LunchBunch, you see who is hungry and available, and in no time, you’re eating at a new place with a friend or two!

Scheduling Plans

Besides giving you the ability to see who’s available right now, LunchBunch can help you to schedule meals in advance. If you schedule lunch or dinner with a group, it’s easy to track who’s going and update the time or location if plans change. Additionally, when you’re getting ready to head out, you can check for hungry buddies who weren’t included in the original invitation so they don’t feel left out.

What are the unique ways that you use LunchBunch? Do you have suggestions for how we could make LunchBunch even better for you? Please let us know in the comments below!

Ryan from The Bunch

Logout Security

After building a login system, there are still a few considerations to take into account. Authorizing each endpoint is a good way to make sure that only logged-in users have access to the web app. Securing logout is also imperative, especially on shared computers.

When a user clicks the logout button, it’s common to redirect them to a publicly-accessible page. However, what happens when he or she (or the next person to use the computer) clicks the browser’s back button? Chances are that the browser has a locally-cached version of content that should no longer be available now that the user has logged out. Fixing this is pretty simple–just add the following headers to the response for each page with authorized data:

response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate"
response.headers["Pragma"] = "no-cache"
response.headers["Expires"] = 0

These headers (for HTTP 1.1, HTTP 1.0, and proxies, respectively) tell the browser (and any proxy) not to cache this response. And that’s it! Now if a user logs out then navigates through the browser history, any authorized page (i.e. any page that was sent with the headers above) will not be displayed. (Ideally, navigation to those pages when logged out would trigger a redirect to the login page.) And for most web applications, there shouldn’t be a noticeable performance hit–if there is, the time-loading tradeoff should be well worth the security benefit.

Have any other security tips for logging in or out of a web application? Let me know in the comments below!

Happy coding!
Ryan from The Bunch

Use Case: LunchBunch at the Office


LunchBunch can be just as useful in the office as it is on a university campus. When it comes to meals, there are a lot of similarities between users in these demographics–both tend to have schedules that change day-to-day, it’s hard to keep track of friends’ availability, and it’s often difficult to organize meals.

Group Emails

Group emails are great for getting information out to many coworkers, but they get disorganized very quickly. Some people might reply to the sender only, others click “reply all”, and they’re hard to search through. It’s difficult to keep track of RSVPs and make sure everyone has the most-recent information when using email to organize a meal. And if you join an email chain late, it takes too long to get caught up. With LunchBunch, everyone is on the same page (pun intended) with easy access to the time, location, and RSVPs for lunch. Sending messages to everyone is easy, and it’s much easier to search through than an email chain. And adding someone to the invitation is a breeze. With just a few taps, any of your Buddies can view the invitation.

Know when Coworkers are Busy

Sometimes it’s tough to know when coworkers are busy and shouldn’t be interrupted. When you’re ready to eat, you don’t need to interrupt anyone’s work to see who’s available. Instead, simply start broadcasting on LunchBunch, and when everyone is at a good stopping point and ready for a lunch break, you can create an invitation. Alternatively, you don’t even need to wait until everyone is hungry–you can create the invitation and add Buddies whenever you’re ready (even if they’re not broadcasting yet).

New People

If your office/building/block is large enough, lunch can be a great way to network with people you otherwise might not meet. You can connect with these people on LunchBunch and organize them into Bunches. You can even schedule times in advance to plan your networking meals at the beginning of each week.

New Places

Whether you’re eating with the same coworkers or networking with new people each day, it’s nice to switch up the location. We’re currently working on a few new features for LunchBunch that will help you find new places nearby, so stay tuned for future updates!

So next time you’re hungry at work and don’t know who’s available, check LunchBunch!

How do you use LunchBunch at work? Do you have suggestions for how we could make LunchBunch even better for your office? Please let us know in the comments below!

Ryan from The Bunch

Authorization Decorators

Last time I wrote about decorators, I explained their usefulness in rate limiting API endpoints. Today, I’m demonstrating another common use: authorization.

If you store the usernames of logged-in users in the session, your endpoint and decorator might look something like this:

@app.route("/get_secret", methods=["GET"])
def secret_info():
    return "The truth is...I am Iron Man."

def login_required(func):
    def login_wrapper(*args, **kwargs):
        if not flask.session.get("username"):
            return "Unauthorized", 401
        return func(*args, **kwargs)
    return login_wrapper

That’s it! Just add @login_required to any endpoint at which you want to restrict access. It’s likely that you’ll want to do something more complex–maybe different users have different roles, or there are other attributes to check–but the concepts will be the same. There are good libraries for integrating HTTP Basic Authentication into your API which is another useful authentication method.

What authentication decorators do you use in your applications? Let me know in the comments below!

Happy coding!
Ryan from The Bunch

Use Case: College Students


YOICO–You’re Only In College Once. I did my best to popularize this phrase at The University of Delaware when YOLO was a big deal. YOICO was a great excuse to get a pizza and watch a movie at 3am instead of studying, and the only downside (obviously there aren’t others…) is that I can’t use it anymore now that I’ve graduated.

College is fun, and having the freedom to manage your own time is great. However, sometimes flexible schedules can make it difficult to meet up with people–especially for meals. If I had LunchBunch in college, I would have used it every day.

Eating Alone

Sometimes you only have 5 minutes to eat before class starts or you just want to eat alone, but usually eating with people is more fun. Schedules change every day, but LunchBunch makes it easy to find hungry friends. Instead of texting all of your friends to see who is available, you can check LunchBunch for the friends who–just like you–are ready to eat.

Regular Groups

LunchBunch is great for finding people right now, but it is also useful for regular meals. Let’s say you and your roommates always get lunch together on Tuesdays. You can create a Roommate bunch in the app, and when you’re ready to eat, you can invite all of them at the same time.


With LunchBunch, you don’t have to worry about messaging people who aren’t available. Sometimes it’s hard to text people before a meal because they might not respond immediately, they may have already eaten, or they’re otherwise not available. When I don’t get an immediate response to a text message, I wonder how long I should wait before asking someone else or going alone. But with LunchBunch, I can see which friends want to eat now, and it’s super easy for me to suggest a place.

So next time you’re hungry, whether you’re getting out of class, you need a study break, or you simply want to see if anyone is available, check LunchBunch!

How do you use LunchBunch in college? Do you have suggestions for how we could make LunchBunch even better for your campus? Please let us know in the comments below!

And remember, you may only be in college once, but YCALB (You Can Always LunchBunch)!

Ryan from The Bunch

Salts and Hashes

For the past few years, “123456” and “password” have been the top two most-common online passwords. Storing passwords securely is very important for any application–not only to protect the users’ accounts from unauthorized access, but also to protect the passwords themselves. Because many people use the same passwords for multiple applications, a security breach on one site could have ramifications for other sites all over the internet. There are many methods used to protect passwords from getting into the wrong hands, and salts and hashes are two of them.

A hash function converts a user’s password to a string of fixed length from which the original text cannot be recovered. That is, if the password “qwerty” (surprise–another common password!) maps to “QmFzZTY0IGlzIG5vdCBhIGhhc2ggZnVuY3Rpb24hIQ==”, there is no way to recover “qwerty” given the hash function output. So by storing the hash instead of the original password, the security of the database is improved substantially, because even if this hash is compromised, whoever has it won’t be able to recover the original password.

Sounds good, right? Yes, but there’s still more to do. If an unauthorized person gets the hash, he or she can use our hash function on random strings and compare that output to this hash. By testing common passwords, there’s a good chance that the unauthorized individual will try “qwerty” and notice that the hashes match. (Note: It’s possible that two different inputs will map to the same hash, but this is very unlikely.) This is where salts come in handy. A salt is data that is added to the input text before it is hashed. So let’s say that the password is “qwerty” and the salt is “c2FsdA==”. Now, the hash function is run on “qwertyc2FsdA==”, which should have an output distinct from the the hash of “qwerty”. An unauthorized person needs to know the salt in order to test common passwords or use rainbow tables.

There are a plethora of hash functions available, but they are not all created equal. I feel that it’s important to note that Base64 is not a hash function. Contrary to hashes, any Base64-encoded string can be decoded to recover the original text. But there also are true hash functions that aren’t secure. Bcrypt is a good place to start.

Happy coding!
Ryan from The Bunch