DEV Community: Twin Sun

How We Saved a Client $100,000 Annually by Optimizing Tests

Twin Sun — Thu, 16 Feb 2023 15:54:34 +0000

What is the purpose of automated testing?

Our team is a strong proponent of automated testing.
Automated tests ensure that our code is working as expected, and that it will continue working even if our app changes over time.

Every application we build has a comprehensive suite of unit tests, integration tests, and end-to-end (E2E) tests.
We run these tests every time we change code or deploy a new version of the app.
Tests ensure we don't break existing functionality when we make changes, and they help us catch bugs before they reach production.
In short, automated tests are a safety net for building excellent apps.

Worsening performance constraints with a growing test suite

Testing is a critical part of our development process with significant benefits, but there are some costs associated with the practice.
As an app matures, the number of tests in a test suite will grow.
Some of our apps have thousands of automated tests.
The more tests you have, the longer it takes to run the test suite.
In some instances, software developers will need to wait on the results of the test suite before moving on to other work.
That wait time can thereby reduce developer productivity.

We found test execution time to be a significant bottleneck for one of our clients.
While working on several web applications for the client, we found ourselves waiting an hour for a Java application's test suite to complete.
This hindered our own productivity and slowed down development work.

The client's team was also frustrated by the long test execution time but had grown accustomed to waiting for the test suite, as they had dealt with this problem for a long time.
Unfortunately, it's not a matter of just waiting for tests to pass.
Sometimes code changes introduce test failures, meaning developers would need to wait an hour to find out if their changes broke anything.
A team of approximately 20 developers was spending hours each day waiting for tests simply so they could do their job!

The costs of slow tests

This time adds up quickly, especially across such a large project team.
While idle time is not inherently bad, it becomes a problem when your project's constraint—your bottleneck—is idle.
Work can only be done as quickly as the constraint allows.
And more often than not, developers are likely the constraint on most software projects.

Financial impact

So what is the cost of waiting for tests to pass?
Let's perform some naive calculations.
If each developer pushes code changes twice a day, and each test run takes an hour, then the team is idle for 200 person-hours each week.
That's 10,400 person-hours per year.
If your total cost (salary, benefits, equipment, office space, etc.) for a developer is $100,000 per year, that idle time would add up to $500,000 in lost opportunity each year!

Now, thankfully, those naive calculations do not represent the lost opportunity cost our client experience.
In reality, developers had adapted to pushing their code less frequently, and only a subset of the team was regularly working on the slowest Java application.
However, a similar back-of-the-napkin calculation demonstrated that the client was leaving nearly $200,000 per year on the table due to slow test suite execution.

Productivity impact

The financial impact of slow tests is significant, but there is also a productivity impact.
When developers are waiting for tests to pass, they are not working on other tasks.
Or, if they do decide to work on another task while they wait, they may not be as productive as they would be if they were focused on a single task.

Consider test failures.
If a developer introduces a code change that causes a test to fail, they will need to wait for the test suite to complete before they can fix the test.
In the meantime, they have moved on to another task and are no longer thinking about the problematic code.
Once they are notified of the test failure, they have to once again switch their focus to the code that caused the failure.
Context switching requires time, so switching back and forth between tasks will reduce the developer's productivity.

How we improved test suite performance

Identifying the problem

We began investigating ways to improve test suite performance.
The first thing we noticed was the amount of integration tests.
Integration tests verify that different parts of the application work together as expected.
However, these tests are often slower than unit tests because they require setting up a database, starting a web server, and other time-consuming tasks.

Integration tests are very valuable for catching problems prior to deployment, and we wanted to maintain the quality of the test suite.
Therefore, removing integration tests was not an option.
Instead, we needed to find a way to run the integration tests faster.
Looking at system metrics during test execution, we quickly identified the performance bottleneck: the CPU.

CPU utilization was consistently at 100% during test execution, but only for one CPU core.
Most processors now have multiple cores, and each core can run its own processes.
The test suite was not set up to take advantage of this capability.

Parallelizing tests to utilize available hardware

We made the single-process discovery on a development machine.
After reviewing the CI server's configuration, we realized it also only executed one test at a time.
This made our next step clear: we would parallelize the test suite.
Instead of running a single test at a time, we would run as many tests as possible at the same time.

It's important to recognize that the test server is doing other work aside from running tests.
Operating system processes still need to utilize CPU time.
Therefore, you generally won't want to dedicate every CPU core to running tests.
Instead, a good rule of thumb is to start your parallel test efforts with (N/2 + 1) processes, where N is the number of CPU cores.
For example, if your test server has an 8-core CPU, you would start with 5 parallel processes.
If you're unsure of whether you can get more out of the system, you can always try increasing the number of parallel processes, but the (N/2 + 1) rule is a sound starting point.

Since the test suite included integration tests, we needed to make sure that the tests would not interfere with each other.
This meant giving each process its own database and web server.
We used Docker to create a separate database for each process, and started a web server bound to a unique port number for each process (e.g., 8080 + N where N represents the process number).
Starting up multiple databases and seeding them with required test data was a slow process, taking up to 60 seconds.
However, since we can reuse the same database for multiple test runs, we only needed to do this once per process.
Over the course of test suite execution, we still realized significant performance improvements.

Parallelizing test suite execution brought test time down from an hour to 20 minutes on existing hardware.
What a drastic improvement!
This still falls short of the general Extreme Programming (XP) guideline of a ten minute build, but was a significant decrease in the time it took this team to receive feedback on their code changes.

At this point, we recalculated the lost opportunity cost of slow tests.
Whereas the client's lost opportunity cost from idle time was previously approaching $200,000 per year, it was now closer to $60,000 per year, amounting to an overall reduction of $140,000 in lost opportunity cost.

Adding more hardware

After parallelizing the test suite, we knew there were more ways to improve performance.
We had already identified the CPU as the bottleneck, and parallel tests fully utilized the client's available hardware.
Once we had exhausted the available CPU cores, we knew additional hardware could further decrease build times.
We provided the client with information about our findings and recommended they add more hardware to execute test even faster.

On large teams, multiple test servers become just as useful as more powerful hardware.
While we had focused on parallelizing the test suite, and the overall execution time was significantly lower, the build server was limited to running only one instance of the test suite at a time.
That meant that if multiple developers pushed code changes at the same time, they'd have to wait for their turn to test their code changes on the build server.
Multiple build servers would alleviate this constraint.

Further improvements

Beyond the aforementioned improvements, there are other ways to improve test suite performance.
Optimizing individual tests, eliminating unnecessary tests, and generally improving application performance are all ways to decrease test suite execution time.
However, those improvements can be a much more significant investment than the relatively simple changes we made to the test suite.
Parallelizing tests and buying more hardware is incredibly cost-effective compared to optimizing individual tests.
Whereas our approach took a few days to implement, optimizing hundreds or thousands of individual tests could take weeks or months.

Life with a faster test suite

The client was thrilled with the results of our work.
Decreased test execution time meant developers could get feedback on their code changes faster.
This allowed them to be more productive, and they were able to push code changes more frequently.

Build quickly with confidence

Automated testing ensures you can deploy new code with confidence.
However, slow test suites can be a major productivity drain.
You can improve test suite performance by parallelizing your tests and adding more hardware, increasing your team's productivity while preserving the benefits of automated testing.

Announcing Harvest Timer and Work Logs for Jira Cloud

Twin Sun — Thu, 16 Feb 2023 15:47:43 +0000

NASHVILLE, January 16, 2023 – Twin Sun is pleased to announce the launch of Harvest Timer and Work Logs for Jira Cloud, a new time-saving app that helps teams sync their Harvest time entries with their Jira work logs.
This app allows users to see up-to-date time tracking estimates within Jira, ensuring that team members know how much time has been spent on each task.

With Harvest Timer and Work Logs for Jira Cloud, users can start and stop Harvest timers from any Jira issue details screen, and add manual Harvest time entries if necessary.
The app also offers project-specific defaults so team members can quickly log time to the appropriate Harvest task within each Jira project.

Twin Sun uses Harvest for time tracking but wanted to see time logged to Harvest reflected in Jira.
That's why they created this app: to make it easy for teams to sync their Harvest time entries with their Jira work logs, and to see up-to-date time tracking estimates within Jira.

We are thrilled to be able to offer this app to teams everywhere. We know firsthand how frustrating it can be to juggle multiple tools for time tracking and work logging. With Harvest Timer and Work Logs for Jira Cloud, we've created a solution that simplifies the process and helps teams stay organized and on top of their tasks.

Jami Couch, CTO

Find the Harvest Timer and Work Logs for Jira Cloud on the Atlassian Marketplace and streamline your team's time tracking today.

How Generative AI Will Spawn Amazing New App Ideas

Twin Sun — Mon, 23 Jan 2023 17:20:22 +0000

Generative AI, or artificial intelligence able to generate novel content, has the potential to revolutionize mobile and web apps. This new technology is exciting because content is an important part of any app.

With generative AI, you can create content that is more engaging and more relevant to your users. This includes text, images, music, and other types of multimedia. Even entire conversations can be generated by AI. In this article, we'll explore how generative AI can help people spawn amazing new app ideas and bring those ideas to life.

Definition of Generative AI

Generative AI is a type of artificial intelligence that is able to generate new content based on a set of input parameters. This is in contrast to other types of AI. Supervised learning, for example, relies on training data to make predictions. Instead of predicting things or categorizing things, generative AI creates things.

Examples of Generative AI

Generative AI is already being used in a variety of industries and applications. Below are several examples of ways this incredible technology is being used today.

Creating mockups and prototypes of product designs. Generative AI can be used to quickly and easily generate mockups or prototypes of product designs, such as app interfaces or website layouts. This gives designers and developers a sense of how the product will look and function before building it, saving time and resources.
Generating marketing materials. Generative AI can be used to create marketing materials such as promotional videos, social media posts, or advertisements. This helps businesses reach potential customers and generate interest in their products or services.
Writing news articles. Generative AI can be used to write news articles or other types of content. This helps media companies and other organizations produce content more efficiently, or cover topics that would be difficult or time-consuming for human writers to research and write about.
Translating text from one language to another. Generative AI can be used to translate text from one language to another, helping to make information more accessible to a wider audience.
Generating personalized recommendations. Generative AI can be used to personalize recommendations for users, such as generating playlists or meal plans. This improves the user experience and make it easier for people to find content or products that are relevant to their interests.
Providing real-time transcriptions of speech. Generative AI can be used to provide real-time transcriptions of speech, adding captions to videos and transcripts to audio recordings. This makes content more accessible to people who are deaf or hard of hearing.
Generating responses to customer inquiries. Generative AI can be used to generate responses to customer inquiries in a customer service setting. This enables businesses to provide faster and more efficient customer support.

Beyond these examples, there are many other ways that generative AI can be used to create new content. Creating new art, replicating human voices, and generating new music are just a few of the other applications of this technology.

Generative AI's Potential for New Apps

Generative AI has the potential to be a powerful tool for app development in a number of ways. Every step of product development, from ideation to development to marketing, can be expedited or enhanced by generative AI.

Generating New App Ideas

First, it can be used to generate new app ideas and concepts. For example, an AI can generate a list of potential app ideas based on user input, such as a specific problem or need that the app is intended to address. It can also create rough prototypes of app interfaces and features, which can then be refined and developed further by human designers and developers.

Consider the following interaction with OpenAI's ChatGPT, a chat bot powered by GPT-3. I asked the bot for ideas for a new app that can utilize OpenAI's text generation API within the B2B space.

Example of ChatGPT generating new app ideas.

ChatGPT is particularly interesting for text generation as it retains the context of your conversation. This means that followup questions can be asked to get more specific information about the app ideas that were generated.

Example of a followup question and response in a ChatGPT conversation.

Once you have an idea you like, you can ask ChatGPT to produce additional content to pitch your idea to your team.

ChatGPT's draft of a press release for a new product.

You can take the idea even further with ChatGPT, asking it to assist you in obtaining verbal commitments to purchase from your first customers.

Sales script questions generated by ChatGPT.

Improved App Designs and User Experiences

Generative AI can also be used to optimize the design and functionality of an app. New AI tools could be used to create mockups or prototypes of app interfaces, which can help developers see what their app might look like and get a sense of how it might function. It could also be used to generate new app features or functionality, such as by suggesting new features to add to an existing app or coming up with entirely new app concepts.

While the output of these tools is not a replacement for human designers, it can be used to help designers and developers come up with new ideas and improve their designs.

Brainstorming a user sign up flow for the new app idea.

The above example was not particularly innovative or outside of the realm of what a human might devise, but it does show how generative AI can be used to assist designers in their work. Instead of an app designer spending their own time devising a signup flow from scratch, ChatGPT can give our designer a rough idea they can iterate upon (with or without ChatGPT's continued assistance).

Text generation is not the only generative AI tool worth considering for improving your app ideas. Image diffusion models such as DALL-E 2 are capable of producing unique, high quality images of practically anything you can imagine, which can power interesting capabilities within your app. Uizard is a free tool that generates mockups of app interfaces, which can be used to help designers and developers visualize what their app might look like and get a sense of how it might function with less effort than was previously required.

Personalized App Content

App personalization can be taken further than ever with the help of generative AI. The user experience can be tailored to the individual user, with anything in the app catering to the user's needs and preferences. AI services can generate customized recommendations or tailored content based on the user's preferences and history.

Certain user characteristics, behaviors, or actions could be used as inputs to an AI model to generate personalized content. For example, messages encouraging the user to make a purchase could be generated to use a different tone or different vocabulary based on the user's personality. A personalized onboarding experience could be generated based on the user's demographic information: a Millennial might be greeted with a different message than a Baby Boomer. AI could even determine that the user may be interested in certain features more than others and adjust the screen layout to prioritize the features that the user is most likely to use.

Improved Accessibility and Inclusiveness

Generative AI can also be used to generate assistive features within an app, such as automatic captions for videos or audio transcriptions for voice notes. Complex articles can be summarized into more digestible text, aiding comprehension for people with reading difficulties. The text of an app can be automatically translated into other languages, making it more accessible to people who speak different languages. These capabilities could help make apps more accessible and user-friendly for people with disabilities or other needs.

As an example, let's ask ChatGPT to simplify that last paragraph into a more digestible version:

Progressively simplified summarization via ChatGPT.

Challenges and Limitations

While generative AI has the potential to be a powerful tool for app development, there are a few challenges and limitations to consider.

One challenge is the need for high-quality data. Generative AI must be trained on a data set that reflects the type of content you wish to generate. This is not a small task. GPT-3 was trained on 175 billion parameters, or 800 gigabytes of data.

Depending on your desired use case, you may only need to use an existing trained model, eliminating the data problem. However, some applications that use generative AI may require user input to also be of a high level of quality. For example, if you wish to generate professional images of app designs, standard models may need more guidance than a general text-to-image diffusion model provides. An image-to-image model, which depends on the user providing a starting image to improve upon, would require users to provide reasonably drawn designs to begin with. Uizard, for example, requires users to build a wireframe to help their AI generate a high-quality mockup of an app interface.

Another challenge is bias in trained models. AI models will reflect whatever biases were present during training, either due to underrepresented or overrepresented concepts in the training data or some bias introduced in the training method itself. Failing to recognize these biases can lead to unintended consequences.

Beyond training biases, generative AI models can produce incorrect or misleading information. Large language models such as GPT-3 are designed to generate human-like text but are not necessarily knowledgeable on any particular topic. As a result, they may sound authoritative on a topic when in fact they are not designed to actually know the topic and are just writing reasonable sounding but factually incorrect responses that are similar to concepts they learned from their training data. This could lead people to believe or act upon incorrect information because the AI appears to know what it's talking about.

In addition, generative AI used for open-ended responses to end users' questions could provide problematic responses. For example, a customer support chat bot intended to help users troubleshoot common problems with an app may encounter an unsolvable problem. In some cases, the AI may suggest a solution that is not helpful or appropriate, such as suggesting the user try another app. As another example, GPT-3 may give a programmer a code snippet that does not work due to changes made in utilized software libraries since the model was trained.

Finally, there are practical limitations to consider when using generative AI. Some bloggers are using generative text to write blog posts, but most models have a limited amount of text they can generate at once. Therefore, it's currently easy to detect a purely generated post, and a purely AI-generated post is unlikely to rank well in organic search results. Long-form content is also difficult to produce without a human collaborator guiding the AI through multiple rounds of writing prompts.

When incorporating generative AI into your app idea, it's important to test out ways the AI will be used. If you are using a text-to-image model to generate app designs, you should test the quality of the designs it produces. The way you anticipate the model working—or the way users want to use your app—may not reflect how the model actually works.

Generative AI Tools and Platforms

There are a number of generative AI tools and platforms that can be used to power new capabilities in apps. While text generation is perhaps the simplest to understand, there are many other types of generative AI that can be used to power new features in your app.

Generative Text Tools

Generative text tools can create idea lists, suggest names for products, create personalized content, and write documentation for your app idea.

Open AI's GPT-3 is a large language model that can be used to generate text, images, and code. The Open AI API lets you access GPT-3 programmatically, which is perfect for powering new capabilities in your app.

ChatGPT is a chat bot that uses GPT-3 to generate responses to user questions. It's a great way to experiment with GPT-3 and see how it works. ChatGPT is a particularly powerful tool for brainstorming new ideas, as it retains the context of previous questions and answers within "conversations." Simply write messages to ChatGPT to ask questions, to instruct it to write for you, or to ask it to summarize text for you.

Generative Image Tools

Generative image tools can create app designs, offer design inspiration, and generate unique images for your blog posts.

Open AI's DALL-E 2 is a text-to-image model that can generate images based on text descriptions. Similar to GPT-3, DALL-E 2 can be accessed via the Open AI API.

Midjourney is another image diffusion model. It is a web-based service that can generate impressive scenes with relatively simple text prompts.

Stable Diffusion is a freely distributed image diffusion model that can be used to generate images from text prompts. Several web services have launched to make it easy to use the model, or you can run Stable Diffusion on your own computer.

DreamBooth lets you train a generative AI model on images of yourself to generate new images of yourself through text-to-image tools like Stable Diffusion.

Uizard is a free tool that generates mockups of app interfaces, which can be used to help designers and developers visualize what their app might look like and get a sense of how it might function with less effort than was previously required.

Other Generative Tools

There are countless other generative AI tools that can be used to power even more interesting app ideas. Generative AI models exist for all sorts of tasks and creative work. The following represents a small sample of the broad range of tools available.

Topaz Video AI performs video enhancement tasks such as deinterlacing, upscaling, and motion interpolation. This can help you increase the resolution of low-quality videos, restore old footage, or create smooth slow motion effects.

AIVA is a creative music assistant that can help you generate novel music in several different styles and genres.

Murf is a text-to-speech tool that generates realistic voices to read text you provide. This can be used for voiceover work, to create audio books, or to generate audio presentations.

GitHub Copilot is a programming assistant that can suggest entire functions or code snippets based on existing code. Copilot greatly speeds up development of simple features and can be used to guide development of complex features.

Conclusion

Generative AI has the potential to be a powerful tool for app development, helping product managers, designers, and developers come up with new ideas and bring those ideas to life. While there are challenges and limitations to consider, such as the need for high-quality data and the potential for bias or incorrect information, the potential benefits of using generative AI are significant. As this technology continues to advance, we can expect to see even more exciting and innovative app ideas being developed using generative AI.

Default to Deny for More Secure Apps

Twin Sun — Wed, 18 Jan 2023 15:32:18 +0000

Every product we build deals with user authorization.
Users may only access certain features or data based on their permissions within the app.
While we want to ensure users can access everything they should, we also want to ensure they can't access anything they shouldn't.
This is why we default to deny all user privileges when starting a new app.

What is Default to Deny?

Network security practitioners are familiar with a similar concept.
The National Institute of Standards and Technology (NIST) issued security guidance that describes a "deny by default / allow by exception" security control.
The idea is simple: deny all network traffic by default and only allow traffic that is explicitly authorized.
This concept is more broadly known as the principle of least privilege.

"Default to deny" is our application of this principle to mobile and web apps.
When we start a new app, users are initially denied access to all features and data.
We then explicitly grant access to the things the user is permitted to access.

Why is Default to Deny Important?

Defaulting to deny is an important safeguard for user data.
Let's say we have an app that lets users purchase books.
Users save their credit card information in the app so they don't have to re-enter it every time they make a purchase.

If we let every user access everything by default, what might happen?
We could miss all of the ways that credit card data could be accessed.
A malicious user could probably find a way to steal credit card numbers from other user accounts.
We certainly don't want that!
So why don't we start with the complete opposite position?

If we deny all access by default, no one can steal credit card information.
Users also wouldn't be able to access their own credit card details.
That isn't great, but it's much better than letting anyone see all credit card numbers.
And opening up user permissions just a little bit is much easier than trying to find all the ways sensitive data might be accessed.

By defaulting to deny, we can be confident that no one is doing anything unless it is explicitly allowed.
Our users' data is protected from accidental exposure and malicious attacks.

How to Implement Default to Deny

As an example of how to default to deny, consider a Ruby on Rails app (as we tend to do).
The primary way a user interacts with the app is through API endpoints powered by controllers.
We use Pundit, a popular authorization library for Rails, to manage user permissions.

Using a BaseController class, we can define an after_action that ensures an authorization check is performed on all requests by default.

class BaseController < ActionController::Base
  include Pundit::Authorization
  after_action :verify_authorized
end

Then we can define a base Pundit policy that denies all access by default.
Note that we don't need to define any actions in the policy.
Pundit will automatically check for a policy method that matches the controller action.
However, actions are defined in our example to make it clear that we are denying access by default.

class BasePolicy
  def index?
    false
  end

  def show?
    false
  end

  def create?
    false
  end

  def update?
    false
  end

  def destroy?
    false
  end
end

Now, we can have any controller inherit from BaseController and Pundit will deny all access to all actions.
For each model class we define, we can add a new Pundit policy that inherits from BasePolicy.
Then we can explicitly allow access to the actions we want to allow.
Consider the following policy example for a Book model.
All users can use the index or show actions, but only administrators can use the create, update, or destroy actions.

class BookPolicy < BasePolicy
  def index?
    true
  end

  def show?
    true
  end

  def create?
    user.admin?
  end

  def update?
    user.admin?
  end

  def destroy?
    user.admin?
  end
end

Starting With Security

Default to deny is a simple concept that can have a big impact on the security of your app.
By denying all access by default, you can be confident that no one is doing anything unless it is explicitly allowed.
This is especially important for apps that deal with sensitive user data.
Consider defaulting to deny when starting your next app and see how much more confident you feel about your authorization rules.

Building Better Apps with Automated Tests

Twin Sun — Mon, 05 Dec 2022 16:54:44 +0000

Automated testing is an essential software development practice.
Agile practitioners rely on automated tests to ensure that their apps are always in a working state.
Often, developers who are new to automated testing raise concerns about the practice.
However, once you become acclimated to testing, you will find that it is a valuable tool that speeds up development.

What is Automated Testing?

Automated testing is the practice of writing code that tests your code.
Typically, automated tests are run as part of a continuous integration (CI) pipeline.
That means that every time a developer makes a code change, the automated tests ensure that all previously written code still works as expected.

There are several types of automated tests.
The most common type of test is a unit test.
Unit tests are written to test a single "unit" of your code: it tests a small, self-contained piece of functionality.
These tests are quick to write and run, and generally make up the majority of automated tests for an application.

Integration tests test the "integration" (interaction) between two or more units of code.
For example, an integration test might test that a user can log in to your application.
Such a test would require that the user interface, the authentication system, and the database all work together as expected.

End-to-end (E2E) tests test the entire application.
Ideally, E2E tests fully test functionality from the user's perspective.
As an example, an E2E test might test that a user can log in to your application, navigate to a specific page, and see the expected content.

Integration tests are more complex to write and slower to run than unit tests.
E2E tests are even more complex and slower to run.
This is why unit tests make up the majority of automated tests for an application.
Integration and E2E tests are incredibly valuable.
However, due to the trade-offs involved, they are often used to test only the most critical functionality that can not be adequately covered by unit tests.

An Example of an Automated Test

Here's a simple example of an automated unit test in a Ruby on Rails social media app.
This test ensures that a Post model is associated with a user and has a valid body attribute.

RSpec.describe Post, type: :model do
  it { is_expected.to belong_to(:user) }
  it { is_expected.to validate_presence_of(:body) }
  it { is_expected.to validate_length_of(:body).is_at_most(255) }
end

Notice how simple this test is.
You can see that it's a unit test because it only tests a single "unit" of code: a Post model.

The it statements are assertions.
Assertions are statements that test the behavior of your code.
They're a central part of automated testing: the assertions are what ensure that your application's code is working as expected.

The above test is written using the RSpec testing framework.
While RSpec is a popular choice for Ruby on Rails apps, there are plenty of testing frameworks to choose from for most programming languages and frameworks.

Benefits of Automated Testing

When your team adopts automated testing, you will quickly realize several benefits.
A tested code base is unlikely to have regressions.
Regressions are bugs that are introduced in old code when new code is added, typically due to unintended side effects.

Automated tests also help you when you need to change existing code to support new features.
This is known as "refactoring."
If your app is adequately covered by a well-written test suite, refactoring carries little risk.
When you make a breaking code change, your tests catch the problem.

You will write better code with automated tests as well.
When you write a test, you are forced to think about how your code will be used.
That means writing code in a modular way that is easy to understand.
Modular code has benefits beyond testability.
A modular code base is easier to understand, maintain, and extend.

Automated tests also speed up development.
While there is an initial learning curve when you first start writing tests, the time you spend writing tests will quickly pay off.
As you write more tests, you will find that you can make changes to your code with confidence.
You will have clearer ideas about how to structure your code, and you will be able to test your changes more quickly.
Automated tests aren't just reserved for catching problems.
You can also use them to experiment with new ideas and to try out different approaches to solving a problem.
Instead of clicking around in an app, you can write a test case and run it over and over as you program until you get the intended result.

Reservations About Automated Testing

The time investment for automated testing is a common concern.
New developers can not easily see the benefits of automated testing when it initially slows down their work.
However, within a few weeks, most developers begin seeing the benefits of automated testing.
They become faster and more confident in their work.

Another common concern is that automated tests prevent developers from making changes to the code.
This can be true in a sense: tests prevent developers from breaking existing functionality when they make new changes.
That can be frustrating when you're new to automated testing.
Instead of thinking of automated tests as a barrier to change, think of them as a safety net.
They ensure that you can make changes to your code without breaking existing functionality.

Persuading Your Team to Invest in Automated Testing

Management is often hesitant to invest in automated testing.
"There's no time right now" is a common refrain.
Managers and developers alike will say that the team can adopt better practices like automated testing after the next big release.
However, in practice, what you don't start today will rarely happen later.

If you face resistance in adopting automated testing, you can try to convince your team by showing them the benefits.
Start by testing your own code.
When other developers make code contributions, run your tests against their changes to ensure that the tests still pass.
If you find a test failure, inform the team member and let them know how you discovered the problem.

As you gain experience with automated testing, you will be able to build complex features more quickly than before.
Testers will find fewer bugs in your code, and you will be able to fix the bugs they do find more quickly.
The quality and speed of your work will increase, making a clear case for the rest of the team to adopt automated testing.

How to Get Started with Automated Testing

To get started with testing, search for a popular testing framework for your programming language.
PHP has PHPUnit, for example.
Java has JUnit.
Flutter apps use Flutter Driver.
No matter your language or framework, there is a testing framework that will work for your app.

How to Use Developer Checklists to Increase Your Confidence

Twin Sun — Mon, 14 Nov 2022 22:49:53 +0000

Checklists are a step-by-step list of instructions to follow.
They can help you plan for handling complex events or multi-step procedures.
A good checklist increases your confidence in what you are doing.

They're great tools for rare events, complex procedures, and stressful situations.
A friend once told me that checklists help you think while you are not stressed so you don't have to think when you are stressed.

Other industries make extensive use of checklists.
However, outside of larger DevOps teams with extensive playbooks, most software development teams do not routinely use checklists.

The airline industry and healthcare professionals have embraced checklists.
They have found that checklists reduce errors and improve outcomes.
Air travel is so safe in part because of checklists used by pilots and maintenance crews.
Healthcare professionals have found that checklists reduce complications and improve outcomes for their patients.

We have realized similar benefits in software development.
Checklists mitigate the risk of human error and improve the quality of our work.

What is a Developer Checklist?

A developer checklist is a list of steps for performing a software development task.
There are plenty of scenarios in software development where checklists are useful.
Code reviews, server migrations, and release management are just a few examples.

Why Use a Developer Checklist?

As a concrete example, a server migration requires several manual steps to complete.
Rehearsing those steps repeatedly is important.
Rehearsals help you identify and resolve issues before the final migration.
As you perform migration steps during rehearsal, you can write a checklist composed of every step you take.
All subsequent rehearsals can use the checklist.
Then, by the time you're conducting final migration, you have a tested and complete checklist to follow.
The opportunity for human error during this likely stressful event is greatly reduced!

Benefits of Using a Checklist

While checklists may not eliminate your stress during complex procedures, they can reduce stress.
You will feel more confident running through a list of steps than winging it.

As we already mentioned, checklists also mitigate the risk of making errors.
If you are following a well-written checklist, you know which step comes next.
You also know the outcome of each step.
In other words, there are no surprises when you follow a checklist.

Additionally, checklists are reusable.
When you write a checklist for a complex procedure, you can reuse it for similar future procedures.
A server migration checklist is a good example.
While each server migration may be unique, the majority of the work required is similar.
Having a starting point for a checklist will help you recall all required activities for a migration, even if you have to change a few steps here and there.

Examples of Developer Checklists

At Twin Sun, we use developer checklists for any events that are rare or complex.
Here are some examples of developer checklists we have written:

new developer setup checklist
code review checklist
new client project setup checklist
server migration checklists
app deployment checklists
AWS infrastructure setup checklists
postmortem checklist

Getting Started with Developer Checklists

If you're just getting started with checklists, consider starting with a checklist for a simple task.
For example, documenting new developer setup for your team can be a good starting point.
Even if you don't plan on a new developer joining your team, you can follow the checklist the next time you set up a new computer.

As you follow and maintain the checklist over a few attempts, you'll find that new developer setup is completed more quickly and confidently.
Common gotchas go away as you document steps for resolving them.
The time you spend writing a checklist will quickly pay dividends as it speeds up complex procedures.

New Jekyll Plugin for Link Attributes

Twin Sun — Fri, 11 Nov 2022 16:01:21 +0000

Our website uses Jekyll, a static site framework.
I chose Jekyll to help us manage a large amount of content.
Managing all of our site content in a code repository means we can manipulate all sorts of things with a little bit of code.

One thing I've wanted to do is ensure that all of our external links default to having reasonable attributes.
For example, all of our external links have a rel="noopener" attribute to prevent tabnabbing.
I also wanted to add a target="_blank" attribute so external links open in a new tab instead of sending visitors away from our site.

Adding the attributes to every link on the site was cumbersome, and we would miss some links sometimes.
Though my primary goal was to increase consistency across all of our pages, proper link attributes also offer some minor SEO benefits.

I found a Jekyll plugin that would do most of what I wanted, but it was not compatible with the latest Jekyll version.
Instead of settling for a partial solution and trying to make it work with our site, I decided to create a new plugin.

The jekyll-link-attributes plugin automatically adds your desired rel and target attributes to all external links on your site.
This happens during the build process, ensuring we catch every external link every time.

The plugin's default configuration is a good place to start, but it is easy to customize your link attributes.
You can add any rel or target attribute you like and exclude links that you don't want to modify.
If you use Jekyll, give it a try!

Deep Dive: Migrating from a Data Center to AWS

Twin Sun — Thu, 03 Nov 2022 15:47:37 +0000

A long-term client of ours had managed their web applications in a colocation data center for several years.
Their apps ran on snowflake servers: unique, manually configured servers that could not be easily replaced.
Snowflake servers pose a disaster recovery risk, but that concern was secondary to the amount of time the IT department was spending troubleshooting problems on their physical servers.

Diagnosing problems with each application was troublesome: IT administrators were (understandably) unfamiliar with the ins and outs of every web app.
Some of their infrastructure was inherited from a previous team, who left little documentation behind.
Keeping the lights on was becoming a larger and larger burden.
Downtime and degraded performance issues began increasing in frequency and severity.

As their web applications gained popularity, the existing infrastructure failed to keep up.
Response times increased drastically during high-traffic times, with servers sometimes becoming entirely unresponsive.
This led to a frustrating user experience for the majority of users, including internal stakeholders who depended on some of these web apps for their daily work.

Analyzing their infrastructure

The client's IT manager reached out to us to see if we could help migrate 16 of their sites to a cloud hosting provider and improve infrastructure reliability.
We already maintained a few of their web applications, so they knew we would be familiar with what was needed to support a migration.
We also have plenty of experience managing complex services and web apps hosted on Amazon Web Services (AWS).

The IT team's goals for the new cloud-based infrastructure were (1) to reduce the time investment required to maintain their infrastructure, and (2) to minimize downtime.
We began reviewing their existing setup with these goals in mind.
As we dug in deeper, we realized that there were a few issues with the existing setup that needed to be addressed as part of the migration.

First, many of the web applications were making hundreds of database calls for each request.
These apps ran well enough most of the time, but database connections quickly became the constraint during high-traffic times.
This performance bottleneck was exacerbated by the fact that several web apps were hosted on each server: a surge in traffic to one of the sites would bring down several of them.

Extremely high load average on a web server during a high-traffic period

Second, some of the applications were as unique as the servers they were hosted on.
The sites used a mix of older web development frameworks.
This meant we'd need to review each application to uncover any dependencies or constraints that might need to be accounted for in a server migration.
We'd have to take a slightly different approach to configuring and migrating each application.

Third, several of the apps had databases that were in unexpected or corrupted states.
Some databases lacked foreign key integrity checks, and some tables had become corrupt due to the server running out of disk space from time to time.
We'd definitely need to fix the corrupted tables, and decided we'd turn on foreign key integrity checks to hopefully avoid any future data integrity problems.

Preparing a migration plan

We identified steps we needed to take to address these issues and ensure the migrations would be a success.

Map the existing architecture to discover dependencies
Map out the new cloud-based architecture
Make any needed app modifications to support the new infrastructure
Optimize web app performance
Automate deployments to the new AWS infrastructure
Correct issues with the existing database servers
Document the migration plan for each app
Perform several dry runs of the migration plan
Migrate and validate each app

Map the existing architecture

We began by investigating the existing infrastructure for each web app.
Thankfully, most applications were simple and had few dependencies.

Existing architecture for a simple web app

A few applications, however, had more dependencies.

A slightly more complex architecture

Generally these dependencies did not significantly alter our new architecture, but did require additional testing prior to the production migration.

Planning the cloud-based architecture

As our team planned to take over day-to-day management of the new AWS infrastructure, we focused on designing a resilient, scalable, and manageable architecture.
We also wanted to ensure that our client wasn't locked in to using a particular cloud provider.
Therefore, we decide to Dockerize each web app and utilize Elastic Beanstalk's Elastic Container Service (ECS) platform.

Elastic Beanstalk simplifies deployments, environment configuration, and horizontal scaling.
Combined with ECS's containerization support, we could keep all server configuration encapsulated within Docker containers.
Since Docker is so widely supported across cloud providers, we could reasonably move to another provider at our client's discretion with minimal adjustments.

This automated and repeatable configuration approach was in stark contrast to the existing production environments.
The existing infrastructure was manually configured, with many service dependencies residing on the snowflake servers.
Running all services from a single server would not be feasible on Amazon Web Services, requiring us to devise a new architecture.

For example, the existing web app servers sent their own email via sendmail.
This is not permissible in AWS due to their anti-spam policies, so we needed to utilize AWS Simple Email Service (SES).
Since the web apps only sent transactional emails, we decided to keep email services in AWS.
However, other third-party email service providers such as SendGrid or Mailgun would have met our needs just as well.

The new cloud-based architecture

This architecture looks very different from the existing setup.
Our approach to cloud-based hosting is completely different from the snowflake servers we were replacing.
Leveraging everything that cloud-based infrastructure offers requires a change in how you model systems.

Instead of treating each server as special or necessary, our new servers would be treated as cattle, not pets.
That is, we expect we will have hardware failures.
To combat this inevitability, we designed an architecture to treat all resources as replaceable.

Instead of setting up a single server to host each web app, we created repeatable configurations that can be applied to new servers as needed.
For example, if a web server is determined to be "unhealthy" or unresponsive, we can have the load balancer provision a new web server, apply our configuration, and replace the unhealthy one.
Similarly, if a single server is not enough to handle a traffic surge, the load balancer can provision as many servers as needed to handle the load.
That is, we expect the needs of the system to grow as our client's business continues to grow.

That dynamic and responsive approach to infrastructure is a key benefit of cloud-based hosting.
You would have to over-provision hardware in your own data center to reap the same benefits.

Performance analysis

To ensure that we right-sized our new infrastructure, we evaluated resource utilization on the existing infrastructure.
We identified the ten most active endpoints on each web app and focused our performance analysis on those endpoints.
Several of the web apps used Google Analytics, which we used to reveal a list of the most visited pages over the past 12 months.

List of the most popular pages in Google Analytics

Some web apps did not have any sort of analytics or application performance monitoring in place, so we analyzed traffic patterns using Apache server logs.
This involved a bit of shell scripting to count the number of visits for each endpoint:

# count the number of visits to each path, sorted by descending visit count
for file in /var/log/apache2/access.log*; do
    cat $file | grep -E "GET /[^ ]+" | cut -d ' ' -f 6 | sort | uniq -c | sort -nr | head -10
done

We then used platform-specific performance analysis tools to determine which of these endpoints needed the most attention.
The highest-traffic sites we needed to optimize used Laravel, a popular PHP framework.
We used Laravel Debugbar to analyze those web apps.

You can see that we had some work to do:

Debugbar analysis showing 1549 database queries for a single page load

This was the most extreme example, with over 1,500 database calls to load a rather simple page.
However, several popular pages on each site would make hundreds of database calls:

Debugbar analysis showing 786 database queries for a typical page

There were enough of these unoptimized pages that we decided a caching layer would be more cost-effective than individually optimizing each page.

Refactoring to support the new architecture

Naturally, some of these architectural changes would require changing how the web apps interact with other services.
Since we moved supporting services off of the web app servers themselves, we needed to make integrations with those services more configurable.

Most of our refactoring was simple: making hard-coded values configurable, or turning certain features on or off depending on environment.
Sending email through SES meant specifying an SMTP hostname and credentials, and in some cases upgrading email delivery to use TLS for improved security.
We introduced Memcached to cache database query results and server-side rendered views.

Caching rendered views did require adjusting how some components were rendered.
The web apps did not have a built-in mechanism for view caching, so we had to implement our own.
We had a generic caching solution ready for the highest-traffic sites with a few hours of work.

Performance optimization

Our caching solution helped us take pages with hundreds of database calls down to 10-15 database calls for most pages:

Debugbar analysis showing a page reduced from 786 database queries to 15

We analyzed app performance by using the web app as a single user.
This certainly led to needed improvements in the user experience, but the question still remained: how do we ensure that we plan the right capacity for each web app on AWS?

Load testing

We set up staging environments in AWS to test our new infrastructure.
Starting with some relatively modest capacity choices (1-2 t3.small instances per web app), we performed load tests on the most popular pages on each site.
We built some simple load testing scripts that wrapped Apache JMeter commands:

require 'ruby-jmeter'

name = 'example'
environments = {
    aws: {
        base_url: 'https://staging.example.com'
    },
    datacenter: {
        base_url: 'https://production.example.com'
    }
}

thread_counts = [1, 5, 10, 20, 50, 100]
environments.keys.each do |key|
    base_url = environments[key][:base_url]
    thread_counts.each do |thread_count|
        test do
            threads count: thread_count, loops: 100 do
                visit name: 'Home Page', url: "#{base_url}/" do
                    assert contains: '<title>Website Name Goes Here</title>', scope: 'main'
                    assert contains: 'Text rendered from database query results goes here.', scope: 'body'
                end
                # additional pages and actions were performed here.
            end
        end.run(log: "#{name}-#{key}-#{thread_count}-threads.jtl")
    end
end

The above produced several logs, one for each thread count and environment.
We reviewed these logs to compare the performance of our new infrastructure against the existing infrastructure.

Even though we configured Autoscaling in Elastic Beanstalk, we performed load testing in our AWS environments against a single t3.small instance for each web app to make a reasonable comparison to the existing data center's performance.

Average Response Time (milliseconds)

Environment	1 Thread	5 Threads	10 Threads	20 Threads	50 Threads	100 Threads
AWS	216	265	439	883	1939	1973
Data Center	1950	1435	1173	N/A*	N/A*	N/A*

* We discontinued load testing on the Data Center environment, as it began to significantly increase
load average and could have had an adverse impact on production sites hosted on the server.

The AWS environment benefited from our caching solution and other architectural changes, so these improved performance metrics were expected.
With our performance optimizations in place, we found that a single t3.small instance was sufficient for each web app.
In fact, several web apps were able to run on a t3.micro based on their lower memory profiles.

Database improvements

As described earlier, we had several database issues that needed to be cleaned up before we could complete our migrations.
This was relatively straightforward.
We addressed missing foreign key constraints, testing against a local copy of the production database to ensure our new reference checks did not conflict with any existing data.

There were also a few tables that had become corrupted due to disk space issues on the production database servers.
The servers would routinely run out of disk space, requiring someone to manually clean up old files.
Unfortunately, sometimes disk space would run out during a write to a table.
This would cause the table to become corrupted.
MySQL thankfully has built-in tools to fix corrupted database tables, so fixing these tables was as simple as running a command on the affected databases:

REPAIR TABLE example_table_name;

We made our corrections to the existing production environments to minimize downtime during the AWS migration.
Fixing the database issues prior to migration helped us perform several migration dry runs to ensure the final move would go as smoothly as possible.

Writing migration checklists

Once we were confident that our new infrastructure would serve our client's needs, we prepared for the production migrations.
We planned to migrate one site at a time and ensure each one performed well before migrating the next one.
This approach reduced complexity and increased our confidence with each migration.

Since we had 16 web apps to migrate and many of them had very different migration steps, we knew there could be ample opportunity for human error during each migration.
Dockerizing the web apps eliminated concerns about misconfiguring a server.
Though, there were still several manual steps for each migration.
We needed to turn on maintenance pages, sync data to the new database servers, sync storage directories, update DNS, and proxy traffic from the old server to the new environment (to catch any straggling DNS clients).

There were dozens of small steps to take during each migration.
We wrote a checklist to capture each step.
Additionally, we documented all of our validation steps.
These validation tests would give us a clear indication that our migrations were successful.

Further, we planned for contingencies in case something unexpected occurred.
We outlined steps to roll back to the data center environment if needed.
We fully expected our migrations to succeed, given our thorough testing and planning, but wanted to minimize the risk of surprises.
A plan to revert to the data center environment would allow us to quickly restore service to our clients if something unexpected occurred.
While we never needed to execute the rollback plan, it did give us peace of mind during each migration.

Automating migration steps

Our migration checklists were rather long and could contribute to manual errors during each migration.
With so many migrations to perform, we wanted to minimize the opportunities for error as much as possible.
Any one failure could push back our overall schedule and shake our client's confidence.
We decided to automate several manual steps to mitigate potential problems.

While we knew not every step could be reasonably automated, several could.
Loading data from the existing environment and into the new environment required several manual steps.
A combination of mysql, rsync, and scp commands were needed to copy databases and storage directories for each site.
We authored shell scripts to automate these steps.

These scripts were simple.
Most replaced just a few commands.
However, each script reduced opportunities for error and helped speed up the slowest steps (copying data).

#!/usr/bin/env bash

##
# Copy the storage directory for a site environment from the legacy production server for client-hosted sites.
# Usage: client-copystorage [site hostname] [path to the desired storage directory]
##

if [ $# -lt 2 ]
  then
    echo "Must supply an environment name and a path to a storage directory. Example usage:"
    echo "  client-copystorage SITE_HOSTNAME PATH_TO_STORAGE_DIRECTORY"
    exit 1
fi

USERNAME=`whoami`
SERVER_IP="172.10.100.42"
rsync -vaz "$USERNAME@$SERVER_IP:/var/www/html/$1/shared/storage/*" "$2"

By the time we migrated the first site, we had scripts for syncing storage directories, copying databases, loading environment variables, and connecting to AWS RDS databases by their associated Elastic Beanstalk environment name.
As we wrote these scripts for the very first site migration, we realized we could also automate preparation tasks such as Dockerizing each web app.
We automated copying existing server configurations, dependencies, and application configuration files to speed up each site's prep work.

The first few web apps would take us up to a week to prepare for migration.
By the end of it, we were migrating a new web app every 2 days, primarily thanks to our scripts and checklists.

Dry runs and final checks

We established a rule early on for each migration: we must have three consecutive dry runs through the migration checklist before scheduling the production migration.
Repeatedly running through our checklists drastically reduced the chances of something going wrong during the production move.
By the time we scheduled a migration, we knew we had worked out all the kinks and could follow our documented steps.

A friend of mine once told me that checklists allow you to think when you aren't stressed so you don't have to think when you are stressed.
Giving ourselves time to plan for problem scenarios made every production migration feel very predictable.
Rehearsing our steps beforehand gave us a calm confidence during each migration.

Successfully migrating the production web apps

Once we completed dry runs, we'd move the production site.
Our step-by-step migration procedure, automated scripts, and validation checklists made each migration a success.

The benefits were nearly immediate for the client's IT department.
They no longer had to manually reconfigure or troubleshoot servers.
The old servers could be shut down and removed from the colocation data center to reduce costs, decreasing overall monthly spend on infrastructure.

A combination of performance optimizations, more resilient architecture, and AWS CloudWatch alarms has significantly reduced the time investment for managing these web applications.
Health checks ensure that each new deployment is in a healthy state before serving end user traffic.
Autoscaling ensures each web app has the resources allocated to economically handle its current level of traffic.

On the old infrastructure, downtime and service degradation were common.
Months after moving to the new infrastructure, we have maintained a spotless uptime record with virtually no manual intervention.

Why We Use Ruby on Rails for Web Apps

Twin Sun — Mon, 03 Oct 2022 14:46:52 +0000

New clients often ask why we use Ruby on Rails to build web apps. Unless they know a Rails developer, they probably haven't heard of it. And Rails developers usually have very strong opinions about Rails.

Oftentimes clients' questions about Ruby on Rails are thinly veiled concerns: does Rails perform well? Can it scale with my business? Is it easy to use?

The truth is that Ruby on Rails is incredibly similar to many other MVC frameworks in many programming languages. There's plenty of online documentation, community support, and available libraries to simplify common tasks, much like what exists for most web development frameworks.

Could we use something else? Sure! In fact, we do use other languages and frameworks from time to time, typically when helping clients salvage existing projects they started elsewhere. We've even built expertise around other frameworks because it was the best decision for our clients.
When we have the option, though, we reach for Ruby on Rails to build new web apps. Our development team is quickly productive on new projects thanks to its capabilities and our deep experience with Ruby on Rails.

Our Rails experience

I first tried Ruby on Rails in 2012. At the time I was mostly using Java's Spring framework to build web apps, and had previously used a few PHP frameworks. Ruby's syntax felt intuitive. Ruby on Rails, as the framework's website claims, is optimized for programmer happiness. As any Enterprise Java developer will tell you, this is a marked departure from some web development frameworks.

Rails takes a "convention over configuration" approach.
Once a developer learns the conventions, they quickly become productive in Rails. This was certainly the case for me.
Initially, I felt like many things in Rails happened by way of magic. Other frameworks I used had their own conventions, but did not shy from requiring plenty of configuration to get things running.

Within a few weeks, I felt more than comfortable in Ruby on Rails: I wanted to use Rails exclusively. A decade later, I still prefer Ruby on Rails over any other web development framework I've tried (and I've tried a lot).

But all of that is only interesting to developers: who cares about how the sausage is made?

Delivering results for our clients

When we build an app, we prioritize attaining our clients' goals. Our clients want great products, not necessarily technological marvels that programmers fawn over. The Rails development experience lends itself to achieving results.

Rarely do we find ourselves muddling around in Rails, trying to figure out how to make a feature work. With Ruby on Rails, we know how the feature should work. The framework's conventions give us a straightforward roadmap with sane defaults for most features. That means we can focus on features themselves: building a frictionless user experience that helps our clients attain their goals.

Ruby on Rails has immense community support. There are open source libraries (gems) for most popular third-party services, making integration with those services as simple as possible. Community-driven knowledge bases enable developers to accomplish practically any task with Ruby on Rails. This means that we can use Rails to build almost any feature you might envision for your product.

Our experience with Rails translates into product reliability as well. We have used Rails to build dozens of production applications, so we know more about how those applications work than we know about any other app development framework.

In other words, when we use Rails to build your web app, you get the very best of our web development expertise applied to your project.

Web app performance

When Rails was first released in 2003, it was criticized for its performance. Rails apps were noticeably slower than other web apps. Ruby is an interpreted language, which is naturally slower than compiled languages. However, the performance of the Rails framework and Ruby itself have both significantly improved over the past two decades.

In practice, we have seen no meaningful difference in performance when comparing resource utilization between Rails and other non-Ruby frameworks for our real-world applications.
There are also numerous ways to optimize performance when you do hit a performance bottleneck, regardless of language or framework. There has yet to be an application we've built where any modern framework—Rails, Laravel, or otherwise—has hamstrung app performance.

Typically, what developers dismiss as framework-specific performance woes are due to other issues in the app.
For example, excessive database queries, memory consumption, slow disk access, or expensive network requests are much more likely to cause performance issues than your choice of framework. None of those issues are Rails-specific, and all of them have solutions (caching, query optimization, etc.).

Popularity and transferability

A few clients have wondered how building their product in Ruby on Rails might impact hiring efforts for their own in-house team. We know that outsourcing to our team is rarely a permanent solution for smaller organizations, and clients deserve the freedom to take their product in-house or to another agency.

Experienced Rails developer availability is dependent on your local job market. In Nashville, for example, experienced C# developers are more common than Ruby developers due to the prevalence of healthcare companies in the area that rely on C# applications, but it's still possible to hire people with Ruby on Rails experience. Ruby on Rails is also easy for an experienced web developer to pick up within a few weeks. Most modern MVC frameworks (.NET, Spring, Symfony, etc.) share design patterns and concepts that are very similar to those of Ruby on Rails.

Our first-hand experience tells us that newer developers can learn Ruby on Rails, too: it's the first framework we introduce to our developers when they join the team. Twin Sun was the first professional programming job for some of our developers, and those team members learned Rails fundamentals in a matter of weeks.

Our compliance with standard Rails conventions—coupled with other practices of ours such as automated testing, continuous integration, and documentation—make the process of transferring a project to your in-house team very straightforward. If a developer knows Rails, they already know how our projects work.

Our Rails apps give you a head start

When we start a new web app project, we don't use the bare-bones app template provided by the Ruby on Rails maintainers. Instead, we have built our own base application to speed up development of the most common features we see in new apps.

Things like user login, authorization, and email notifications are generally the same across most apps. Those capabilities are baked in to our base app. Things like login screens still need to be designed for your app, but the core functionality is there as soon as we start the project. Our clients benefit from us using these core features that have been tested and proven in dozens of other apps.

Rails works well for us

Do we have to use Ruby on Rails to build a new web app? No, there are plenty of other tools that can get the job done, and we've used many of them.

However, we have invested our time and effort into building our expertise in Rails. You can take advantage of our expertise and build your web app with confidence.

Building a Ruby on Rails App with a Legacy Database

Twin Sun — Mon, 26 Sep 2022 15:51:10 +0000

We recently started a new API project for an existing web application.
The existing app has no API, and our client wants to create a fresh mobile app experience.
Our new API will support the mobile app, and will exist alongside the existing web app.

The existing app is large and complex, and introducing a RESTful API that meets the mobile app's requirements would prove difficult in the existing code base.
We believed that a new project for the API would be the simplest path forward.
However, we need to utilize data from the existing app without impacting the existing user experience.
Therefore, we decided to access the existing database from our new API project.

Our preferred tech stack uses Ruby on Rails, so we wanted to find a way to connect to the legacy database from a Rails app.
Broadly, we knew that we needed to map the existing database schema into our Rails project, capturing the schema in db/schema.rb.
From there, we could generate model classes mapped to the schema, and then use the models to create our desired API endpoints.

Generating Model Classes

This is where the Schema to Scaffold gem came in.
It produces rails scaffold commands that can be used to generate a model and associated controller for a given schema.
This gem rapidly speeds up the process of mapping legacy database schemas to Rails models.

To start, we needed to connect our app to a copy of the legacy database.
We took a backup of our staging environment's legacy database and loaded it in our local development environment.
Then we connected the rails app to the local copy of the database and ran the following command:

bundle exec rake db:schema:dump

This generated a db/schema.rb file that we could use to generate our models.
The schema is used by the Schema to Scaffold gem to print out rails generate scaffold commands for generating our models:

scaffold

We then copied the rails generator command list from the scaffold command's console output to generate our models.
Depending on your use case, generating all scaffolding for each model may be excessive.
You can tweak the commands before running them to only generate the models if so desired by running rails generate model instead of rails generate scaffold.

Within a few moments, this leaves you with dependable ActiveRecord interfaces for accessing your legacy database.
It's that easy!

Mapping Relationships

This wasn't the end of our work, however.
When you're interfacing with a legacy database through a Rails app, you will likely need to make some adjustments to the generated model classes.
Foreign keys or ID columns may not match the Rails naming conventions, requiring you to map the columns to the correct model attributes.
We found several columns in our project that were named using camel casing instead of snake casing.

For example, this app had the concept of many types of records belonging to a Tenant.
The database column used for this foreign key was named tenantId instead of tenant_id (what ActiveRecord would expect).
The Schema to Scaffold gem reasonably does not know what to do with this column, so we updated the has_one relationships with Tenant records to use the correct column name:

class Tenant < ApplicationRecord
  has_many :filters
end

class Filter < ApplicationRecord
  belongs_to :tenant, foreign_key: 'tenantId'
end

Hardcoded Relationships

We also had a special Tenant record: a certain Tenant was a placeholder that translated in code to "all tenants may use this".
In the old application, they'd look for this special record by a hard-coded ID of 9.
This meant that our Rails application could not simply rely on has_many or belongs_to relationships to find all data that should be accessible from another Tenant.
In some places, it made sense to use a scope instead of a has_many relationship:

class Filter
  belongs_to :tenant, foreign_key: 'tenantId'
  scope :for_tenant, -> (tenant) { where('tenantId = 9 OR tenantId = ?', tenant.id) }
end

# example usage: Filter.for_tenant(tenant)

The hardcoded Tenant with an ID of 9 also presented concerns in our test suite: the ID field is an auto-incrementing integer database column, so it's possible we could have a conflict with that ID in our tests.
To circumvent this potential issue, we seeded our test database with a placeholder Tenant record with a hardcoded ID.

Instead of hardcoding the ID to circumvent this issue, we could have performed a database migration to adjust how to designate records as belonging to all tenants.
However, this would have required adjusting behavior in the original application as well, which could have lead to undesirable side effects.
We are talking about a legacy database, after all!

Going Forward

Now we have a complete integration between our legacy database and our Ruby on Rails app.
The existing web application can continue working as-is with no modifications.
Meanwhile, our new API endpoints can take advantage of the niceties of Rails while leveraging the shared database.

Securing Sensitive API Calls with Nginx

Twin Sun — Mon, 29 Aug 2022 17:48:14 +0000

A common web application architecture relies on a client-facing app that interacts with an API server. For example, you may build a React app that interacts with an API. We’ve worked on a number of projects where we interact with a third-party API that we do not control.

In these instances, we sometimes wish to add an extra layer of authorization between end users and the API. This is necessary when the API permits the client to take irreversible action—such as deletion of data—with no way to restrict or grant privileges to specific end users.

There are a few ways to augment the API’s authorization with our own. We typically take one of two approaches. If the API service is one piece of a number of backend services we need to control, we will build a middleware application that adds our own layer of user authentication and authorization. That solution can add a lot of time and complexity when we’re looking to deliver a simple web app. Alternatively, if the API service is the only backend service we use for the application, we can implement a simpler solution. Instead of building middleware to manage privileges, we can configure nginx as a reverse proxy between end users and the API.

The difference between proxies and reverse proxies

A proxy is a service that acts as an intermediary between the client requesting a resource and the service that provides a resource. There are two types of proxies: regular (“forward”) proxies and reverse proxies. A forward proxy typically obscures which client is requesting a resource. In contrast, a reverse proxy will obscure which service is providing a resource.

Typical API interactions

Before we demonstrate how a reverse proxy helps us solve our security concerns, let’s consider a typical API interaction. Imagine we have a React app that needs to retrieve data from a weather API. The interaction diagram for requesting data from the weather API may look something like this:

The React app client requests data from the weather API, which returns data that the client can present to the user.

Reverse proxied API interactions

Continuing with our example, let’s imagine that we are using a paid weather service API. We are charged for every API call we make. For this scenario, let’s pretend we’re okay with our users making as many requests as they like to the API. However, we’d like to prevent third party websites from taking our API authentication token and using it for their own applications. We would not want to get charged for a competing weather site’s API usage.

So let’s introduce a reverse proxy between our client and the weather API. Instead of storing our API authentication token in our React app, we can store the token securely on our reverse proxy server. Our React app will send API requests to the reverse proxy. The reverse proxy, in turn, will add the API authentication token to our request before forwarding the request to the weather API. The weather API responds to the request, returning our weather data to the reverse proxy. The reverse proxy then sends that data back to the client.

By never directly calling the weather API from our React app, we have hidden our API authentication token from our end users. They can’t view the source code in their browser to uncover our API token, because it’s simply not there.

How to authenticate API calls through an nginx reverse proxy

Setting up a reverse proxy may sound daunting at first. However, nginx makes configuring a reverse proxy rather easy.

Let’s imagine that the weather API requires us to send an X-Weather-API-Token header containing our API authentication token with every API request. We can tell our nginx server to forward requests from /weather-api/ to the actual weather service API, and to add the required API token header to the forwarded request:

location /weather-api/ {
    proxy_cache off;
    proxy_set_header X-Weather-API-Token "your-super-secret-api-token";
    proxy_pass https://weather.example.com/api/current-weather.json;
}

Now when our React app sends a request to the /weather-api/ URL hosted by our nginx reverse proxy, nginx will add the X-Weather-API-Token to our request and send the request to the API endpoint located at https://weather.example.com/api/current-weather.json. The API endpoint will return the data we want to the reverse proxy, and then the reverse proxy will send that data back to our React app.

It’s that easy! Of course, this is a simple example. We did not cover how to ensure no third-party sites hit our reverse proxy. However, you have some options: limit requests to certain origins (hostnames or IP addresses) with a Content Security Policy, set up Basic Authentication, or create a custom authentication mechanism for nginx to use.

This approach has helped us add an extra layer of protection for third-party APIs and has helped us limit client access to certain endpoints. Of course, reverse proxies have plenty of other uses beyond securing an endpoint. You can transform data, combine data from multiple resources, load balance requests between multiple servers, cache data, compress data, and even chunk (or “spoon feed”) large requests.

Flutter: Our Platform of Choice

Twin Sun — Mon, 22 Aug 2022 18:58:00 +0000

What is Flutter?

Flutter is a cross platform mobile UI Framework created by Google. Flutter allows developers to create incredible looking apps that work on both Android and iOS devices using a single code base. As of December 2018, Flutter is officially on version 1.0.

Why Flutter?

Generally speaking, Flutter is designed to seriously decrease the time and effort it takes to develop a product on both major mobile platforms (Android and iOS). It makes maintaining a product much easier as well, as the majority (if not all) of the code is shared across both platforms.

For Twin Sun, Flutter allows us to exceed our clients’ goals and expectations. We have all come from a world that avoided hybrid and cross-platform approaches, as it was always more financially beneficial to charge for two separate applications for each platform.

When founding Twin Sun, we all agreed on our goal, to take on software for people who deserve better. Too many companies, specifically start-ups, often times end up paying far too much for their product for a number of reasons. This inflated costs typically starts with the concept of “native applications always work better than hybrid”. This is a line I have said to hundreds of clients before, and I believed it, until now.

Cost

Flutter demolishes this concept with astounding results. We began using Flutter for an internal project in May of 2018, and after seeing the power and potentially cost savings, we have began using Flutter for client projects as well. On products that require both Android and iOS, we have seen an average of a 48% reduction in our pricing compared to building each platform separately.

Functionality

Flutter provides the same level of functionality you would get with native applications. The applications compile into native code, which essentially makes them indistinguishable from a full native application. The community has latched on to Flutter support with companies like Square announcing partnerships. Flutter also easily supports native code as well, for any unique scenarios that require native interoperability.

Timeline

Flutter allows us to move very quickly and deliver astonishing results in the process. By removing the hurdles encountered with a team of native iOS and Android developers, we can move quickly on ideas and collaborate better than ever with a single code base across our entire team.

The Future of Flutter

To say flutter has received support is an understatement. Flutter is being used in many production apps with millions of users, such as Alibaba, Google Ad Words, and many more.

Due to the incredible support and community around Flutter, there are currently projects to:

Build Mac, Windows, and Linux desktop applications
Build full web applications
Even run on Raspberry Pis

This means that in the near future, sharing a single code base can extend to the majority of major platforms beyond mobile.