
At Olio Apps we understand the challenges organizations adopting cloud for the first time or experimenting with serverless development run into when it comes to designing and deploying scalable and cost effective architecture on AWS.

Seldom does an organization have the time and resources to commit to learning a new tech stack while developing features.

At Olio Apps we regularly support clients who are in need of talent specialized in specific AWS services who can disperse that knowledge throughout the organization.

This is why we support our team members in developing their knowledge of cloud and serverless best practices when it comes to AWS Infrastructure.

Today, we are excited to announce and celebrate Aaron Whitaker’s recent AWS Solutions Architect Certification.

The AWS Solutions Architect Certification validates proficiency in designing and deploying scalable and cost-efficient cloud solutions on AWS. Individuals with this expertise are able to tailor AWS infrastructure to an organization’s needs while optimizing performance and cost-effectiveness. Additionally, those who achieve AWS Certification in general can be assured they are up to date with Amazon’s best practices and innovation standards.

## AWS Solutions Architect Associate Bolsters Technical Abilities

Aaron found that the process of studying and learning for the AWS Solutions Architect Certification exam reinforced his practical knowledge while exposing him to additional best practices:

> Getting the solutions architect certification helped to reinforce the knowledge I’ve gained through practical experience working in AWS for the past two years. It also gave me more insight into best practices and patterns I hadn’t previously known about. It's given me more confidence to design well-architected cloud systems

Aaron is a Fullstack Engineer at Olio Apps who specializes in fullstack and serverless applications. You can learn more about the team at Olio Apps <a href="https://www.olioapps.com/team">here.</a>

Congratulations again Aaron, we are excited to see how this new knowledge from the AWS Solutions Architect Certification encourages your further learning.


At Olio Apps we acknowledge that Amazon Web Services (AWS) is an industry leader when it comes to providing reliable and scalable cloud services for companies across all domains.

Celebrating Aaron Whitaker’s AWS Solutions Architect Certification


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

## Atomic Design
https://bradfrost.com/blog/post/atomic-web-design/

The UI is an aggregation of discrete, composable components. These components are concerned *only* with presentation, eg. styling and content -- not logic.
- Smallest reusable elements are called Atoms
- They are designed to be generally agnostic of their environment

Atomic components have well defined contracts (eg. props). This expands to their containers.

Global atoms are composed into global, reusable molecules. Global atoms and molecules form the basis of feature-specific Molecules and Atoms. Molecules and Atoms are composed into pages

### Why?

- Separation of concerns -- you can focus on a single domain and be maximally effective
- Reuse -- need to "bless" every button in the app with a spinner? Update the basal Atom for it
- Parallelization -- folks can be divided into focusing on the pure presentational UI components, while others work on the "logic" pieces
- You can use storybook. More on this below

## Storybook

https://storybook.js.org/

Storybook is a rapid-development environment for pure presentation components. It is a framework for exercising / displaying all the behavioral variations for components as controlled by their props.

### Why?

- With storybook, you get an immediate feedback on the components as they are developed
- No need to "hack" the live environment that the components are going to be used in
- Sometimes there is NO live environment yet -- but you will not be blocked because you can use storybook to view your components
- Storybook is to UI component development as test-driven unit-test development is to non-ui component development
- Developers can use storybook to interact with the design team, publishing the full range and variation of components in an easy to access way
  - You don't need to seed an environment to show all the permutations of particular components and even whole pages
  - Designers can easily manipulate the storybook to see what things look like by simulating conditions such as size of that page, values of the props

## TypeScript

https://www.typescriptlang.org/

TypeScript is JavaScript 2.0 -- a strongly typed flavor of JavaScript. It can be incrementally added to a pure-JavaScript environment.

### Why?

Compile-time checking of errors. In larger apps, sometimes you will only know that a shape going into a function is incorrect once its in production.

Contract-driven development. Think of types will get developers to start thinking and planning about how pieces interact, first at the function level; next at the module level; finally at the systems level.

Without types, you can only know what the "valid" shape of an object is from its consumers.

- There are infinitely more consumers, and they change all the time
- Without a type or interface, I would have to inspect ALL the consumers of an object to know what its valid attributes are!
- Without types you cannot efficiently describe how a system interacts with itself, or other systems

## Redux

https://redux.js.org/

Redux is global state management for large scale appplications.

### Why?

Larger scale UIs often need to cache server side state. For example:

- Logged in user
- Incoming unread chat notifications
- Synced media

It is useful to cache this state because you don't want to pull it down all the time. If your app is going to work offline sometime, caching the data from disk in memory in redux is often useful. When some region in that state tree is changed, other interested parts of the UI can "listen" and react to those changes.

[Redux toolkit](https://redux-toolkit.js.org/) and Olio's own [Sitka framework](https://github.com/olioapps/sitka) are syntactic sugar built atop redux

## UI Backend Modularization

Just as the pure presentational components are organized into modules of specific Atoms, Molecules, and Pages. The "backend" of the frontend is also separated out into modules by feature/responsibility area. These pieces are NOT concerned with presentational concerns But are instead concerned with:

- Navigation (routing)
- Interaction with the API
- Interaction with the device (local storage, services such as bluetooth, push notifications, etc)

Modules are concerned with the management of their particular subslice of the global state (or have their own private state); and the operations against that state -- and nothing else.

### Why?

Parallelization

- Folks can work on and concentrate on the "backend" of the app while others work on the frontend
- Folks can work on different feature modules within the backend tree

Separation of concerns

- The logical and UI layers can change without breaking each other
- The backend feature modules are less likely to have regressions when they change, as their logic is self contained with the module

Reuse

- The backend modules may reuse each other using well defined contracts
- For instance we can have a module purely concerned with activity tracking
- That can be integrated with the navigation module which can record activity using the aforementioned module

Testability

- The entire functionality of a logical feature / module is easily unit testable because its possible to mock their state without having to mock out the rest of the system

## Sitka

https://github.com/olioapps/sitka

Sitka is an opinionated framework built atop of Redux and Redux Saga. It encapsulates UI backend modules into classes that control both state and operations of those modules.

### Why?

Sitka ticks all the items of the UI Backend Modularization section. You can safely modify module state via callbacks from the UI.

Sitka implements pub-sub mechanism:

- One module does something
- Other modules can "subscribe" and react to those

Sitka implements background "jobs" - recurring polling tasks.

Sitka is very powerful, and has been implemented in 10+ projects across multiple customers. Alternatives include redux toolkit.

## Summary

This collection of tools and techniques forms the basis for fast productive UI development projects at Olio Apps. We continue to iterate and build on our toolset every day.


This is a collection of techniques and tools we use at Olio Apps to make UI application development faster and more efficient!

UI Architecture Powerups - What, and Why


<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/calculator.jpeg" alt="A mobile phone calculator app" style="display: block; max-width: 100%;">

In this article, I discuss seven principles for minimizing the time and money spent building a mobile app. If you're looking to build an app, are pressed for time, and don't have an unlimited budget, keep reading!

## Planning

No plan is perfect, though a healthy amount of planning will help a great deal when it comes to saving money and time.

### Fully Explain

At my software consulting company, [Olio Apps](https://www.olioapps.com/), we are often approached with projects and asked to estimate without much information. Sometimes we're given little more than a sentence or two of a business idea ("Uber for cats! How much?"), or a slide deck with mostly pictures and a few words, and we are left to surmise what that actually means, or how grand the vision is. If you ask someone for a quote but provide little to go on, and you do get an estimate back, be aware it's a wild guess and could be off by orders of magnitude.

To help customers flesh out their product visions, we provide [Discovery and Roadmapping](/services/discovery-roadmapping/) engagements, where we spend a week doing working sessions with them, building up the use cases, user stories, and wireframes, and whatever else is needed to build an informed development plan and cost estimate.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/wireframes.jpeg" alt="Drawing wireframes on paper" style="display: block; max-width: 100%;">

### Mock Up the App

The clearer you make the picture of what you want up front, the less guesswork your engineers will have to do. You want to eliminate guessing. If you leave right vs. wrong up to chance, there is a very good chance it will be partially wrong, which will cost more time and money.

The more you can fully tell the story of how your software should work, and ideally how it should look, the more likely you'll get it right the first time. Mocking things up with pictures and written descriptions has a way of revealing the holes and corner cases not yet considered. It's cheaper and faster to find and flesh out the murky areas before you build.

Conversely, the most beautiful mockup images are just images, and though they may look great, software needs to be touched and used before you truly know if it is a joy to use, or super annoying and difficult. So make mockups of the most critical pieces. Whether you’re sketching the app in [Balsamiq](https://balsamiq.com/wireframes/) or prototyping in [Figma](https://www.figma.com/), emphasize functionality over beauty. Then get to a working prototype that users can try as quickly as possible, so you can learn and refine from working software.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/user-testing.jpeg" alt="Drawing wireframes on paper" style="display: block; max-width: 100%;">

### Get User Feedback Before You Build

Are you part of the target audience of your app? If so, that's a great start. Have you talked to others in the target audience and asked for feedback on your app? You don't have to wait until after you've spent a lot of time and money building the app to start. Before your app is built, you can and should ask for feedback to validate and refine your ideas.

Turns out, there is right way and a wrong way to ask for feedback. Wrong way: saying to family and friends, “I’m going to build an app for X! Will you use it?” The answer will be yes, but that’s not useful. It does not tell you whether real users will use it. Your friends and family are biased towards you. Better: “Do you have any problems with X? How do you deal with X today?” We recommend reading [The Mom Test](http://momtestbook.com/) to guide your approach to getting useful feedback.

If you've done the work to mock up your app, you can even build a clickable prototype using a tool such as [Figma](https://www.figma.com/) or [Invision](https://www.invisionapp.com/) to let users walk through the user interface and see how the app would work, before you spend the time building it. This will obviously save you more time and money.

## Technical Choices

We are a technical consultancy, so here's where I'll make some technology recommendations. There are many ways to build a mobile app. Depending on your choices, you could spend wildly different amounts of time and money to arrive at the same outcome. The common thread here is leveraging existing expertise and re-use.

<img src="/assets/blog/2020-08-12-save-money-building-mobile-apps/tools.jpeg" alt="Lots of tools neatly arranged" style="display: block; max-width: 100%;">

### Use Tools Lots of Developers Know and Like

If you choose technology and tools that lots of people know and like, you can find people happy to build it now, and others willing to maintain it going forward. If you pick something obscure, overly clever, or proprietary, there will be a smaller pool of people who can work on it, which will make it more expensive. If you are non-technical or getting advised on technology choices by others, do a little research, ask around, and see if the terminology being thrown around is familiar and well-received by others.

### Use a Cross-Platform Framework

A cross-platform framework cuts development time and gets your app running on multiple platforms with a single code base. One team can build for both platforms at once. The 80/20 rule applies: 80% of the code is shared, 10-20% is platform specific conditional code, but it all lives together in a single version-controlled code base.

There are many options, such as those listed in this [roundup article from March 2020](https://hackernoon.com/9-popular-cross-platform-tools-for-app-development-in-2019-53765004761b). The top four listed are React Native, Xamarin, Flutter, and Ionic. All of these are decent choices, and the best choice for you should be influenced by the current expertise of your developers (C# developers? Xamarin. React web developers? React Native. Angular web developers? Ionic.) But ongoing maintenance and the hiring of future developers to maintain the project should also be a consideration.

I recommend [React Native](/services/react-native-applications/) because it is well known and supported, and used successfully in many popular apps. It allows front-end developers who already know [React](/services/react-web-applications/) (the most popular frontend web framework as of August 2020) to leverage their existing expertise to build native mobile apps, as well as web apps. If you need something specialized and platform specific, you can drop down to native code and write an extension. These days, existing open source extensions exist to cover most common use cases. It is now possible to build a React Native App that runs on iOS, Android, Windows, Mac, and the Web.

### Use Libraries for Common Features Found in Every App

There are now libraries and components that implement the common things that most apps do. For example, almost all apps require you to sign up and log in. There's nothing new or ground breaking about this part of an app, just potentially time-consuming work, implementing the same thing many people have done before. Instead, make use of the libraries and services that allow you to skip the heavy lifting and get sign up and login functionality working right away. Some examples are [Amplify](https://aws.amazon.com/amplify/), [Cognito](https://aws.amazon.com/cognito/), [Firebase](https://firebase.google.com/), and [Auth0](https://auth0.com/). Unless you have a good reason to roll your own, it makes financial sense to use one of these, so you can spend more time on the actual unique value your app will provide.

## Lean on Experts

If you are not an app developer, or if you have a team of technical people who focus on other things besides mobile app development, consider working with experts who have successfully built multiple apps already. Not only will this help you get your app off the ground faster, it will also help you avoid mistakes and keep you from incurring technical debt that may slow down your project. Plus, an experienced team can work with you to bootstrap a good software development process that you can carry forward within your organization.

Looking for an experienced team to build your mobile app? [Contact us](/contact-us) today to start a conversation about your project.


7 Great Ways to Save Time and Money Building a Mobile App


Pull requests are an essential collaborative tool for modern software development. I wanted to capture the kinds of questions a developer should ask themselves before asking another developer for a peer review.

These are general guidelines, and are not exhaustive of the types of due diligence every software engineer undertake prior to seeking a peer review, with the aim to:

- Reduce the amount of recurrent defects
- Reduce the impact to the other developer’s time and energy spent defects in your code
- Increase the overall autonomy and productivity of individual developers

Developers should ask these types of questions prior to submitting work for review.

## Prior to coding

- Can you articulate what problem you are trying to solve?
- Can you articulate your proposed solution before coding it?
- If the stakeholder is present/available, have you validated your solution with them?

## Learning from previous reviews

Have you had a code review in the area of the code affected by your previous PR? If so, have you double checked your current PR for the existence of similar defects?

Some people may find it useful to maintain a (private) journal or log of previous PRs.

## Code hygiene

- Does the code compile?
- Does the code pass all linting and sanity checks locally? How about the the CI server?
- If you are working on a UI project - does your code conform to the UI coding and naming conventions agreed upon by your organization?
- Have you removed any unused or dead code (such as scaffolding or work product code)? Anything related to debugging?
- Are there any merge conflicts you need to resolve as a result of your PR?

## Code organization and correctness

- If an algorithm is material to your code changes, have you ensured that its as efficient and correct as possible?
- Can a hardened third-party component be used in place of anything you’ve hand coded for your solution?
- Assuming the code compiles, runs and spits out the correct behavior -- have you gone back and optimized the solution with the benefit of hindsight?
- If you are working on a multifactor project (react native + react web for example) - - are you properly separating component logic from the visual components for maximum reuse?
- If you are adding logic as part of your PR -- are you adding it in the right level? Is this logic appropriate, for example, in the component versus the reducers, versus the sagas?

## Documentation

- Are you working on a ticket that is undocumented? Eg. if we are using trello tickets to track sprint activities -- have you added at ticket capturing your effort?
- Are there any external or internal facing documents that need to updated should your PR be accepted?
- Have you made comments in the code you are touching that will be necessary to explain what you did?
- If the change you are effecting originates from a trello ticket, JIRA, or some other bug tracking system -- have you documented there how your changes can be tested?
- In your PR, have you pasted links to the to the originating trello or JIRA item, so the reviewer has context for testing and review?
- If your PR affects the user interface, have you added screenshots of the affected UIs?

## Testing

- Can you describe what functional change your PR is trying to effect? For example, what behaviors are changing as a result of the code you are submitting?
- Assuming your code is runnable, does it actually fulfill the behavioral requirements set forth in the comps, functional requirements spec, trello tickets, etc.?
- Have you manually tested the behavior you are affecting in the PR?
- If there is an automated testing framework in place, have you built tests that cover the code touched by your PR?
- If you are working on a UI project, have you:
  - Considered the cross browser implications? Have you tried testing it in the target browsers?
  - Considered the operating system implications? Have you tried testing it in the target operating systems and the versions thereof?
  - Considered the device implications? Have you tried testing it in the target devices and form factors?

## Resource Bundles

The types of applications that Olio creates will often use resource bundles to describe the text or colors presented to the user.

- If text variabilization is supported (via internationalization or otherwise) -- have you made sure that any text you’ve added or modified isn’t a hard coded string?
- If color variabilization is supported -- have you made sure that any colors you’ve added or modified isn’t a hard coded color or hex string?

## Exiting the current review

- Based on the PR feedback, have you identified new or existing areas of knowledge or ability to work on?
- Have you thanked your peer reviewer, and offered to reciprocate? :)

Do you have any suggestions for check list items or questions to add to our list?


Celebrating Aaron Whitaker’s AWS Solutions Architect Certification

AWS Solutions Architect Associate Bolsters Technical Abilities

Join our newsletter!

Popular Articles