Integrating Freshbooks API into an Expo App

expo freshbooks oauth react native software

So recently, I've been working on an Internal BiteSite staff application. Besides being useful to our team, it is also a testing ground for us to up our mobile development game.

One of the things we do at BiteSite is track our billable time using Freshbooks and to keep ourselves on track, we have weekly targets that we like to hit. It's not a strict thing - but a good way for us to gauge how we're doing.

With that, I wanted to create a feature in the app where we could easily see how close to our target we are. To achieve this, I had to integrate into the Freshbooks API. Although each piece wasn't too hard - there were a LOT of steps to take care of to make this work.

This article will outline all the steps I took to achieve this. This implementation is for an Expo App using Expo's AppAuth - but I'm sure this can easily be adapted for a bare React Native app using the regular React Native AppAuth.

Alright here we go.

TL;DR

If you just want to see the code, hit up the Gist here.

Before we begin

Before we begin, I want to mention that we will be using a library called expo-app-auth. Expo AppAuth is based on the React Native AppAuth library which itself is based on AppAuth libraries for iOS and Android. In this article, when we talk about AppAuth, we're talking about the Expo version - but a lot I'm sure applies to all of these libraries.

Pre-coding setup

So before you start coding your integration, you need to actually create a Freshbooks app. You can find the full instructions here, but basically, you login to your Freshbooks account and hit up the developer page. Once there you just create an app.

At that point, you should have Client ID and a Client Secret.

Before we move on, you should add one more thing. Click on 'Edit Application', and add a redirect URI. I used the value 'exp://127.0.0.1:19000/--/auth/redirect'. The URL will have to be a Deep Link (which you can generate using Linking.makeUrl.

Update: So to get the redirect URI to work with standalone apps, you have to do a little bit of manual URI generation. As of the writing of this article, Linking.markUrl will produce a triple slash URI. For example, if you set your scheme in your app.json to bitesite, and you call Linking.markUrl('/auth/redirect'), you'll end up with bitesite:///auth/redirect. So while the above exp:// URI will work when using the Expo Go app, it won't work when you deploy to a standalone app. So you'd think that all you have to do is add the bitesite:/// triple slash URL to the Freshbooks App. Unfortunately, Freshbooks doesn't consider this a valid URL at this point. As such, you'll have to manually code in the redirect URI to be only double-slash and then add bitesite://auth/redirect to the Freshbooks App. See the code below to see how I do it using app.json.

Ok, so your setup is complete - you'll have a Client ID, a Client Secret, and a Redirect URI.

Where to store your Client ID and Client Secret?

This is probably the most annoying part of this article if you're looking to implement something quick. Unfortunately doing something quick will ultimately be insecure.

Alright, so one of the issues with coding Expo apps is your effectively coding a Javascript bundle that can easily be exposed. As such, the authors of AppAuth recommend that you do NOT hard code your Client ID and Client secret into your Javascript. Sure you can test it out this way, but you shouldn't be storing in the code.

As such, we opted to store this in our own Rails app in the Database.

The Expo app that we're coding in this article will talk to 2 servers:

  1. The BiteSite web app
  2. Freshbooks

If you're cooding this for yourself, you will have to find your own way to store the Client ID and Secret (or at minimum the secret) somehwere that's not your code.

Our BiteSite web app's API only allows authorized users to then fetch the Client ID and Client Secret.

Building the Freshbooks API Client Object

When I started working on this, I really wanted to have a Javscript object that handled the complexity of authenticating against the Freshbooks API and making all the calls. When it comes down to it, this object can really be boiled down to a few basic functions

  • Authenticate the user against Freshbooks and store the resulting OAuth Token
  • Check if the user has an OAuth Token
  • Refresh the OAuth Token if necessary
  • Make Freshbooks API Calls using the OAuth Token

So let's create a basic object and add all the imports we'll need:

/* freshbooks_api_client.js */
import axios from 'axios';
import Constants from 'expo-constants';
import * as AppAuth from 'expo-app-auth';
import * as Linking from 'expo-linking';
import * as SecureStore from 'expo-secure-store';
import moment from 'moment';
import apiClient from './api_client';
import appSettings from '../../app.json';

const FRESHBOOKS_AUTH_KEY = 'freshbooks_auth';

const freshbooks_api_client = {
  /* We'll build our code here */
};

export default freshbooks_api_client;

Let's look at each of these in detail.

Log the user in to Freshbooks

So the very first step is we need to get the user to sign in. So to do this, we're going to use the expo-app-auth library which you can see is imported as AppAuth above.

Now, since a LOT of the code to get a new token and to refresh a token is very similar, I created an internal function. For lack of a better name, I called it internalAuthorize.

/* freshbooks_api_clients.js */
...

const FRESHBOOKS_AUTH_KEY = 'freshbooks_auth';

function internalAuthorize(refreshToken) {

  const internalAuthorizePromise = new Promise((resolve, reject) => {
    let authState;

    apiClient.get('/settings')
      .then(({ data: settings }) => {

        let freshbooksApiClientId;
        let freshbooksApiClientSecret;

        settings.forEach((setting) => {
          if(setting.name === 'freshbooks_api_client_id') {
            freshbooksApiClientId = setting.value;
          }

          if(setting.name === 'freshbooks_api_client_secret') {
            freshbooksApiClientSecret = setting.value;
          }
        });

        let redirectUri = Linking.makeUrl('/auth/redirect');

        if(Constants.appOwnership === 'standalone') {
          redirectUri = `${appSettings.expo.scheme}://auth/redirect`;
        }

        const config = {
          serviceConfiguration: {
            authorizationEndpoint: `https://auth.freshbooks.com/service/auth/oauth/authorize?response_type=code`,
            tokenEndpoint: 'https://api.freshbooks.com/auth/oauth/token'
          },
          redirectUrl: redirectUri,
          clientId: freshbooksApiClientId,
          clientSecret: freshbooksApiClientSecret,
          scopes: [],
        };

        if(refreshToken) {
          console.log("Attempt to refresh token...");
          return AppAuth.refreshAsync(config, refreshToken);
        } else {
          return AppAuth.authAsync(config);
        }
      })
      .then((returnedAuthState) => {
        authState = returnedAuthState;
        return SecureStore.setItemAsync(FRESHBOOKS_AUTH_KEY, JSON.stringify(authState));
      })
      .then(() => {
        resolve(authState);
      })
      .catch(() => {
        SecureStore.deleteItemAsync(FRESHBOOKS_AUTH_KEY).then(() => {
          resolve();
        });
      });
  });

  return internalAuthorizePromise;

}

const freshbooks_api_client = {
  ...
};

export default freshbooks_api_client;

This function returns a promise that basically resolves with an authState object if the authorization is successful and with nothing (undefined) if it's not successful.

The first 10 lines or so are just a get request to get the Client ID and Client Secret that is stored on the BiteSite app. apiClient is an axios api client for the BiteSite web app. So this is where your code will differ.

Once you have the Client ID and Client Secret though, you should be good to go.

Because Freshbooks doesn't use standard OAuth Provider data, we have to custom configure the AppAuth.authorize request. This is one of the keys that's hard to find in other places. Take note of the URL, the Client ID, the Client Secret, and the Redirect URI. Again the Redirect URI might not ultimately matter. Particularly the URL - do NOT use the Authentication URL from Freshbooks. AppAuth automatically constructs a URL using the values you pass into the config object so follow the code closely above.

With this configuration, you'll properly hit the Freshbooks Authentication URL.

What's great, is everything that follows is handled by the AppAuth library. All you have to do is call AppAuth.authAsync(config) and AppAuth will properly bring up a Browser window for the user to login into Freshbooks. If the user successfully logs in, the call to AppAuth.authAsync(config) returns a promise that resolves with the authState object which contains all the token information you need to make Freshbooks calls.

So once we have that, we simply store in using SecureStore.setItem.

Now that the token is stored, we are ready to use it to make Freshbooks API calls.

Now this internal function is used both in authorization and refreshing tokens. I just control this with a true/false parameter. So if we want to authorize, we just call internalAuthorize() and if we want to refresh, we call internalAuthorize(true).

To expose the authorization piece to the public, I wrap this call in a function:

/* freshbooks_api_clients.js */
...

function internalAuthorize(refresh) {
  ...
}

const freshbooks_api_client = {
  authorize: function() {

    const authorizePromise = new Promise((resolve, reject) => {

      internalAuthorize().then((authState) => {
        if(authState) {        
          resolve(true);
        } else {
          resolve(false);
        }
      });

    });

    return authorizePromise;
  },
};

export default freshbooks_api_client;

And with that, if somebody wants to authorize, they can just do this:

/* AnotherFile.js */
import freshbooks_api_client from '../path/to/freshbooks_api_client';

freshbooks_api_client.authorize().then((authorized) => {
  if(authorized) {
    console.log("Authorization succeeded!")
  } else {
    console.log("Something went wrong.");
  }
});

Check user's authorization state

Ok now that we logged the user in, throughout the rest of the app, it would probably be nice to check whether or not the user is 'logged into Freshbooks'. Really what that is is just checking whether or not we have a stored token.

What you should know is that the authState that came back when we authenticated is not just a string. It actually contains a lot of information including the token itself, its expiry date, etc. That's why when we originally stored it, we converted it (serialized it) into a string using JSON.stringify:

  ...
  return SecureStore.setItemAsync(FRESHBOOKS_AUTH_KEY, JSON.stringify(authState));
  ...

So if we want to check the if the user is logged in, and use the accessToken, it might be nice to have a little function that extracts out the serialized object, and deserializes it back into an object. So to do that, I created another internal function:

/* freshbooks_api_client.js */
...
function internalAuthorize(refresh) {
  ...
}

function getFreshbooksAuth() {
  const getFreshbooksAuthPromise = new Promise((resolve, reject) => {
    SecureStore.getItemAsync(FRESHBOOKS_AUTH_KEY)
    .then((data) => {
      if(data) {
        const freshbooksAuthObject = JSON.parse(data);
        resolve(freshbooksAuthObject);
      } else {
        reject('Could not find freshbooks auth object');
      }
    })
    .catch((error) => {
      reject(error);
    })
  });

  return getFreshbooksAuthPromise;
};

const freshbooks_api_client = {
  ...
};

export default freshbooks_api_client;

This internal function getFreshbooksAuth simply goes into our SecureStore, grabs the value, parses it into a Javascript object and returns a promise that resolves with the object.

The object that is resolved is basically the original authState object we got when we authenticated against Freshbooks.

Now we just need to this to the outside world. If the token exists, we're considered authorized.

/* freshbooks_api_client */
...
const freshbooks_api_client = {
  ...
  checkAuthorization: function() {
    const checkAuthorizationPromise = new Promise((resolve) => {
      getFreshbooksAuth()
      .then((freshbooksAuthObject) => {
        console.log("Freshbooks token active.");
        resolve(true);
      })
      .catch((error) => {
        resolve(false);
      });
    });

    return checkAuthorizationPromise;
  }
}

Refresh the token

Now that we have a way to check if we're authorized, we should be clear to make any API calls. Not exactly. Above, when I said "If the token exists, we're considered authorized" - that wasn't entirely true.

The think about OAuth tokens is that the expire - and actually - they expire pretty quickly. In some cases within 24 hours. Luckily, it's pretty easy to refresh the token.

So we need to modify our checkAuthorization slightly if we have a stored token but it's expired, we just need to refresh it.

/* freshbooks_api_client */
...
const freshbooks_api_client = {
  ...
  checkAuthorization: function() {
    const checkAuthorizationPromise = new Promise((resolve) => {
      getFreshbooksAuth()
      .then((freshbooksAuthObject) => {

        if(moment().isAfter(freshbooksAuthObject.accessTokenExpirationDate)) {

          internalAuthorize(freshbooksAuthObject.refreshToken).then((authState) => {
            if(authState) {
              console.log("Freshbooks Token refreshed.");
              resolve(true);
            } else {
              console.log("No Freshbooks Token found.");
              resolve(false);
            }
          });

        } else {
          console.log("Freshbooks token active.");
          resolve(true);
        }
      })
      .catch((error) => {
        resolve(false);
      });
    });

    return checkAuthorizationPromise;
  }
}

Notice that we're using our internalAuthorize that we coded before. Again - logging in and refreshing the token uses very similar code. Once the authState comes back from the refresh, we just store it the exact same way we stored the original authState.

So now, when we call checkAuthorization, if we're not logged in, we get a 'false' response, if we're logged in, we get a 'true' response, and if we need a refresh, the refresh happens and we get a 'true' response.

With this in place, any file can now easily check authorization status:

/* AnotherFile.js */
import freshbooks_api_client from '../path/to/freshbooks_api_client';

freshbooks_api_client.checkAuthorization().then((authorized) => {
  if(authorized) {
    console.log("Authorized!")
  } else {
    console.log("Something went wrong.");
  }
});

Make Freshbooks API Calls

Alright, now we're finally ready to make calls to the Freshbooks API. Making calls to the Freshbooks API is actually pretty simple - you just have to pass in a special string as the authorization header for your request.

The string looks like this:

"Bearer YOUR_OAUTH_API_TOKEN"

Since we have the API Token, this is actually pretty simple. Remember that we already have the internal getFreshbooksAuth function to grab the authState object. This object has a property called accessToken that we can use.

So we just set up an Axios instance with the proper header to make the API call. For those that are not familiar with Axios and use things like jQuery, think of Axios as another way to execute something like $.ajax.

So to put this together, I created a get function on our exported object:

/* freshbooks_api_client.js */
...

const freshbooks_api_client = {
  ...
  get: function(url) {

    const getPromise = new Promise((resolve, reject) => {
      getFreshbooksAuth()
      .then((freshbooksAuthObject) => {
        const internalFreshbooksApiClient = axios.create({
          baseURL: `https://api.freshbooks.com/`,
          headers: {
            'Accept': 'application/json',
            'Api-version': 'alpha',
            'Authorization': `Bearer ${freshbooksAuthObject.accessToken}`
          },
        });

        internalFreshbooksApiClient.get(url).then((response) => {
          resolve(response);
        })
        .catch(() => {
          reject();
        });
      });
    });

    return getPromise;


  }

With that final piece, we can now make calls from other files easily:

import freshbooks_api_client from '../path/to/freshbooks_api_client';

freshbooks_api_client.checkAuthorization().then((authorized) => {
  if(authorized) {

    freshbooks_api_client.get('/auth/api/v1/users/me').then((response) => {
      console.log(response.data.response);
    }
  } else {
    console.log("Something went wrong.");
  }
});

Conclusion

So with that, we now have a nicely encapsulated library with a pretty simple API:

freshbooks_api_client.checkAuthorization();
freshbooks_api_client.authorize();
freshbooks_api_client.get('/freshbooks/api/end_point');

I'm sure there is a lot of cleanup that can be done, but for now this is working and I'm pretty happy with it. Hope this helps others as well!

If you want to see the source code for our Mobile App, check it out here.

And as that will always be evolving, you can check out the Gist here.

Casey Li
CEO & Founder, BiteSite

Starting Small with Software

software business software development

You've seen all the success of large software companies such as Facebook, Amazon, Netflix, or anything else and thought, “I should do that”. So you come up with an idea and want to get started right away.

It goes without saying, investing in software is a safe bet for the future but jumping in without thinking is a sure way to overwhelm yourself. Your idea is great but let’s scale it back to a more manageable size. This allows you to not get overwhelmed with complexity and cost right away.

Approaching a company like BiteSite is a perfect way to ensure the project is the right size. At BiteSite we love to work with projects that start small and see where they end up.

What is a small project?

A small project to us is anything with a deadline of 1-3 months, and has a small set of concrete short term goals. At the end of the deadline the client will have a minimum viable product (MVP) that can be used by end users. This MVP will be able to be improved upon in the future once feedback is gathered.

Client

Starting small is advantageous to everyone involved, especially the client. Most of the advantages stem from not locking into a large project.

When a client decides to work with a custom software shop it is important that the company's culture works well with the client’s. This is mainly because the client is part of the development process. A small project does not lock a client into the company for a long period of time. This allows the client to feel out if they want to continue past the initial MVP.

Often in software development, the initial requirements do not turn out to be the final product. This is where it is dangerous to create large scale projects based off of fixed initial requirements. Short term contracts combat this by helping clients not lock into a product they end up not needing. Hence why we advocate for having a small set of concrete short term goals rather than immovable long term requirements. The short term goals can be added upon after users have tested the MVP and feedback is available as to what will be used.

Overall, the client will save time, effort, and money by choosing a small project and developing off of it in the future. The initial large scale idea will eventually be reached just in smaller increments.

BiteSite

Now you know why small projects are advantageous for customers, you might be wondering why BiteSite would ever advocate for a small project. As everyone knows, larger projects mean less uncertainty and more interesting work right?

Most of the time yes, but not always.

Larger projects are eventually what we try to work towards with all our clients but it’s rarely a good idea in software development to start with a large set of requirements and work towards a goal far in the future. Many requirements will not be known until the software evolves into something that can be tested by the end users.

The first reason to have smaller projects with new customers is to feel out what the end users will use. Small starting projects help us understand the clients and end users needs before anything large has been committed. This minimizes the time wasted creating software that is not needed. We can create an MVP to quickly see what features should be expanded upon and what ones will be dropped.

The next reason to start small is to show the client our competence and convince them their time, money, and effort spent on the project will be worth it. Diving into a large project doesn’t create trust as quick as a smaller project does since the finished product is so far in advance.

Larger projects having more interesting work is normally due to the complexity required. With custom software each project is unique so naturally it creates interesting work our developers possibly haven’t seen before. If the client continues the small project the complexity of the project will increase as well.

Hopefully you see how advantageous starting small can be.

Big projects can be intimidating but starting small will reduce the chance of being overwhelmed. The big idea is always there but chunking it off into smaller pieces is a better approach for everyone involved. There is nothing wrong with starting small. Afterall, Rome wasn’t built in a day.

(photo by Engin Akyurt from Pexels)

Chris Francis
Software Developer, BiteSite

How to build your Software Startup Product

custom software software development

So you’ve decided to start a company

Alright. So you’re toying around with the idea of starting a company - specifically a software company. Perhaps you’re looking for a change in your career. Maybe you recently came across a problem that you have a great solution for. Or maybe you’ve had a ton of ideas in your head for years and now is the time to act.

Whatever the reason may be, starting a software company can be an amazing journey. You could end up building something that really changes the world.

But even though you have a great idea, you might be stuck as to how you actually get started. How do you start putting together a team? How do you build your product? How do you sell and market it? There are so many questions you have to deal with when starting a company.

While there is a lot that can be said, in this article, I hope to answer “How do you build your product?” and give your idea some legs.

Build it and they will come? Nope.

Before we get started though - I want to be very clear. Building the product is by no means the most important nor the first step you should necessarily take. It really depends on a lot of factors and each case is different. In some situations, doing market validation and research is more important first. In some cases, putting together your staff is more important.

This article is not saying you should build your product first, but rather, when you decide to proceed with that step, here are some ideas.

Developing Software

If you’re reading this article, you’ve probably got a great idea that software seems suitable for, but you might be completely lost when it comes to actually creating, building, or developing the software. However, if you’re in that state, the term “building software” itself might be confusing. What does building software actually entail? What should you understand about it? Regardless of whether you build it yourself or hire someone to build it, it’s good to understand some high level concepts that go into building software.

Product Management

When you build software, one of the most important aspects is deciding what features your product will have, the details of how they will work, and when they will be developed. This practice is known as Product Management.

Design

After you’ve decided on what features you want in your product, you might have to design your product. This can involve UI and UX design where you’re figuring out what the screens or pages will look like and how they will behave when a user uses them.

Development, Coding, Implementation

Next, you have development or coding. This is where developer (or computer scientist, or software engineer, or coder) will write code (or source code) to execute your vision.

Deployment

Deployment is the act of getting your software into the hands of your users. So for a website, it’s putting code on a server out in the internet for people to access (hosting). For an app, it’s submitting your code to the Apple App Store or Google Play.

Source Control

Source Control is using a system to literally control your source code. When you start to build software, you may have multiple people working on the code together. You’ll want good source control to track all changes, allow for parallel work and collaboration, and revert things in case something goes wrong. Having a good source control system in place will spell out success as your startup grows.

Process

Lastly, you’ll want a process to manage all these aspects of software development.

Now, it’s important to note that not ALL these aspects are necessary to start developing your product, but as you grow, you should be aware of these and more.

What are your options?

So now that you have a general idea of what developing software looks like, how do I actually go about doing it? Well, there are a couple of options.

  • Build it yourself
  • Partner with a developer
  • Hire a software developer
  • Hire a software development firm

Build it yourself

Probably the cheapest and lowest overhead way to build software for your startup is to build it yourself. If this is your startup, you could act as a product manager, designer, developer, all in one. If you happen to have a background in software development, then you’re set. Nothing is stopping you from sitting down at your computer and starting to design or code.

What if you don’t know how to code?

Well luckily, the internet is full of amazing free content to learn. A quick google search of “Website tutorial” or “App tutorial” will get you started. You might think - there’s no way I’ll catch up to seasoned developers, but that’s not quite true. I’ve met founders of startups who learned to code all themselves and build amazing products. If you’re determined, you can really do it.

Pros

  • Lowest overhead
  • Cheapest

Cons

  • Can be the slowest (especially if you have to learn coding)

Partner with a developer

If you don’t want to do the development yourself, you can find a business partner. Ideally in this case, you want to bring on someone who can wear multiple hats - someone who can do some product management, design, development and more. Sound too good to be true? It’s not. I’ve met a LOT of developers who can do all the other tasks to a workable level. Especially enough for a startup.

In these cases, a lot of the time your partner is part of the startup and you’ll have to sort out an ownership or compensation structure.

Pros

  • Best balance of overhead and return

Cons

  • Can be hard to find a good partner
  • You give up some control of your company

Hire a software developer

This is similar to partnering up with a developer, except in this case, rather than having some kind of equity agreement, you simply pay an individual to develop software for you.

Pros

  • You retain control of your company

Cons - Can be hard to find a good developer

Hire a software development firm

The last option is to hire an entire firm. Just so we’re clear, software firms or companies that are capable of software development go by many names:

  • Custom Software firm/shop
  • Digital Agency
  • Web Design and Development firm/shop
  • App Development firm/shop
  • (many more)

This option is the most expensive, but if you have a revenue source or some money that you are ok with spending, this could be fastest and could yield the best quality. When you hire a software firm, you’re getting a lot that may not be obvious. Depending on the software firm, you may get access to:

  • A team full of talented, vetted developers
  • A well-oiled process
  • Years of experience in all development aspects

Yes you’ll get your software product in the end, but you’ll also get all this along the way. The biggest issue here is cost and the high cost can also amplify the negatives if you find a bad firm. For example, BiteSite recommends a $5,000 - $10,000 starting budget to get things going. Most startups don’t have that kind of money and most are hesitant to spend that up front.

That being said, if it’s successful, you could end up with a great product, that’s properly managed, and what’s more, you’ll get exposure to what it’s like to run a successful software team which becomes very useful as you grow.

Pros

  • If you find the right firm, you’ll get a great product and great experience to carry on throughout the life of your company

Cons

  • Expensive
  • A firm by no means guarantees quality and it can be hard to find a good firm

So what should I do?

So with the 4 options, what should you choose? Unfortunately, I can’t answer that. There are honestly merits to each approach and you have to think in your situation what’s the best for you. You’ll have to see your comfort level and weigh it against the benefits you see from each option to make your choice.

Whatever you choose though - you should remember a simple philosophy when it comes to good software development: good software development is iterative.

That means keeping a philosophy of “try something, if it doesn’t work, try something else”.

Software development should never be all or nothing. Software development should be a process of constant feedback and iterating. Everyone who develops good software should believe in this, and as such, they should extend that to your decision on the approach you take.

So whatever you decide, I highly recommend finding a way to try out the approach in some small way, and telling yourself to evaluate and iterate if it’s not working. For example, if you’re building itself, try it for a few weeks and see how far you get. If you’re hiring someone, set a super small milestone to see how it goes.

However it turns out, I congratulate you on pursuing your ideas and I hope I’ve shed some light on how to build your software startup product.

(photo by luis gomes from Pexels)

Casey Li
CEO & Founder, BiteSite

RSpec with Resque

resque rspec ruby on rails software development

So one of the gems we use a lot in our Ruby on Rails applications is Resque. For those who don't know, it's a library that allows you to run background tasks that are separate from the main web thread.

This gets especially useful when your web applications get big enough that they are doing long, complex tasks. There are alternatives like Sidekiq and Delayed Job, but Resque was the first one we came across and it's been serving us well for years.

However, one thing that became really annoying to deal with was automated tests (or specs). We use rspec, and when we would run our tests, a lot of the times our tests would fail because it would run into some code similar to Resque.enqueue which requires that your Redis server be running.

One way to deal with this was to simply start up your Redis server and then run your specs. However, this didn't feel right. With stubs, and mocks, and whatever else you use to fake logic, it seems that it should be easy to stub out any call that Resque makes.

Luckily, there is an easy solution.

It's called resque_spec and its repo can be found here.

It can actually do a bunch of stuff, but the key thing for us, is that it basically stubs out the real Resque calls so it doesn't actually queue up jobs, and doesn't require Redis to be running. What's more, the setup is as simple as including it in your Gemfile. Warning: As they mention, only include this in your test group, as it does override the default Resque functionality

# Gemfile

...
group :test do
  gem 'resque_spec'
end
...

What's more, if you're using Resque Scheduler, it works with that as well (with a little extra configuration).

With resque_spec in place, running specs became a lot simpler. Hope this helps some peeps out!

Casey Li
CEO & Founder, BiteSite

Software developers of the world, thank you.

software business software development

Something dawned on me the other day - something pretty amazing.

So I've been a Software Engineer, Developer - whatever you want to call it, a good chunk of my life. My dad introduced me to coding back in the early 90s, I studied Software Engineering in University, and now I run my own Custom Software shop. So software development has been a big part of my life and I would say I'm pretty proud of where I am.

However, something dawned on me the other day. I've really been standing on the shoulder of giants and what's crazy is - so many of us have.

Let me explain.

If you don't develop software, what you should understand, is that software is built in layers of abstraction. As a developer, you don't need to know how electrons zip back and forth on a computer motherboard because someone built a layer on top of that that abstracts the details away from you. As a developer, you don't need to understand how certain low-level operating system operations work because someone built a layer on top of that.

But it doesn't stop there.

Let's take Ruby on Rails for example. This is my web framework of choice. Because of Ruby on Rails, I don't need to understand when someone types in a URL in their browser, how that sends a request to my code with all the information I need to build a web application. I just use that information and I'm on my way.

But it doesn't stop there.

Many other developers have developed libraries that makes it infinitely easier to send fancy email notifications, create realtime web applications, render fancy charts and more.

And you know what, it doesn't stop there.

This is the thing - as a software developer, you leverage other people's work so much. You use frameworks, libraries, code snippets - you name it. Let's take a closer look.

As an informal, non-scientific experiment, I decided to pick one of BiteSite's biggest projects and I wanted to see how much code was ours and how much wasn't. Remember, this is pretty informal, but it should give you an idea

  • Our code (~4MB)
  • Library & framework code (~527 MB)

(for the technical readers, I took the size of our Ruby on Rails app folder for "Our code" and took the "node_modules" and "gems" folders for "Library and framework code")

That's 0.75% for our code! 99.25% of the code that's being used was written by other developers.

Now this is not super scientific, and granted we're not using every bit of the framework - but it's just a small indication of how much code we're using that we didn't create ourselves. I would also say that this is probably quite typical of most applications.

Aside from the exact percentages, which only represent the code that was written - there's so much research and development that went into creating these libraries and frameworks. Not to mention that a lot of these libraries and frameworks contain the work of some of the best engineers in the world. Think about that.

I can't count the number of times a client has come to me and said "Can you do this?", I say "Probably", Google it and within minutes have an amazing solution because some developer out there coded an amazing library.

And it doesn't stop there.

The benefit goes way beyond making a software developer's life easy or making them look impressive. Because of these libraries and frameworks, the developers using them are able to build incredible apps that are the foundation for amazing businesses and companies that change the world.

And here's the kicker. They do it for free.

That's what really blew my mind as I thought about this more and more. A lot of massive, super successful companies that change the world build their software, their company, their success using free frameworks and libraries.

We have all this amazing technology at our disposal because a huge number of software developers love developing amazing technology, putting it out there, and ask nothing in return.

Don't get me wrong. I know there is sometimes a bigger business motive for some of these libraries and frameworks, but for the most part, I think software developers have developed such an incredible culture of sharing and collaborating for the greater good. I can't think of another industry that does it so well.

I've taken it for granted for so long that so much of what I do and so much of what the tech industry does is based on (and forgive the phrase) the kindness of strangers - the kindness of developers who love their craft and want to share it with the world.

So with that - I think it's time we all thank this incredible group of people who continue to provide answers to our problems, who allow us to build amazing world-changing products and businesses, and who ask for nothing in return.

Thank you to all the incredible software developers out there who have allowed me and so many others to get to where we are.

Casey Li
CEO & Founder, BiteSite