When planning the KPA ticketing app, the first big decision was deciding which technology stack to use

Given the complex and highly-interactive design, we needed something that was going to be developer-friendly while letting us build an application that was highly responsive to user interactions. Nothing’s more frustrating than a slow user interface!

VIA has mostly standardized on ReactJS for smaller interactive user experiences as well as single-page web applications so it seemed like a great fit, even though the ticketing app is just a small (but critical!) piece of a much larger site.

The other advantage to developing the ticketing portion of the site as an almost stand-alone app is that development on the rest of the site could continue in parallel. The more simultaneous work happening, the better!

React’s power comes from the way everything is divided into components which are displayed on a page. Once a component is identified, it becomes trivial to use it in multiple places on a page without having to write a bunch of extra code.

For example, we created a component for a single seat in the list of all available seats. This was great because seats that had been added to the user’s cart had a very similar design, albeit with slightly different data. This component-based architecture let us have all the shared code for that seat layout in a single place, even though it was displayed in multiple locations.

An additional benefit of using components is it makes it easier to allow multiple developers to work on the project at the same time.

The ticketing app was, understandably, quite data heavy. We need to store lists of available seats, seat map data, pricing information, promo codes, shopping cart data, venue information, etc. This data was constantly being updated as people selected seats or filtered based on pricing points or seating sections.

Luckily, this is another use-case where React shines. Leveraging an additional tool called, Redux, we can easily store all of the data used by the site in a single data store. Then we can set up our different components to pull data from that store. When data in the store changes, the components using that data automatically update themselves. All of this changing and updating is blindly fast because React is very good at only updating the components that have actually changed. No need to refresh the entire page!

For example, let’s say the user wants to filter seats to a certain price range. We can build a component which lets them select the prices they want. Those selected prices are fed back into the data store. Then React takes care of updating all of the components that depend on that data. This includes things like updating the seat map and ticket list to hide seats that don’t match the selected filter.Tools aren’t a guarantee of success. Just like a fancy hammer doesn’t mean you can easily build a house. The most important part of a project is the people working on it. Given the huge scope of this project and the aggressive timeline, our expert people using the above tools allowed us to deliver a quality product while sticking to the timeline we set out for ourselves.

Want to know more about our work for Kentucky Performing Arts? Read our case studies on 

the new Kentucky Performing Arts branding

how we translated that branding into the new kentuckyperformingarts.org website

While we have wide and varied development expertise and experience the core of our development skill is with PHP, Javascript, Vue and React, allowing us to maintain and develop new features for 80% of all websites on the Internet. That said, we regularly explore new and useful platforms to stay ahead of the ever-changing development curve.

PHP, Javascript & React

If you need to sell online, we’ve got you covered. From simple selling strategies to complex subscription models, we’ve built them all. Our clients with ecommerce process tens of thousands of dollars per month through our systems. From Shopify integrations to WooCommerce workhorses to Magento installations and beyond, we’ve built and managed them all, safely and securely.

Ecommerce

Websites are the cornerstone of marketing in this day and age. Your website is the place where you have ultimate freedom to express your brand and interact with your audience and customers how you’d like. Using agile, user-focused strategies and design, we build highly accessible, highly useful websites that meet your goals.

Websites

Using React and Redux to build the Kentucky Performing Arts ticketing experience

 is the super fast, super customizable CMS that we're using as the backend for the new 

One of the more powerful concepts that Sanity is the 

 which gives you the ability to customize how content is presented in the Sanity admin.

Let's go through the basics of how you start working with the Structure Builder.

When you first start with the Sanity Studio, you'll have a 

 file which has some basic information about your Sanity setup.

Your sanity.json file will have a section called "parts" which looks something like this:

We're going to update it so Sanity knows to look for a structure file for any customizations.

The above structure mimics the default behavior of Sanity. We have a single pane called "Content" which displays a list of all of our document types.

Now that that's in place, we can organize our content in some interesting ways!

One thing we wanted was to be able to exclude certain document type/schemas from the Sanity admin. That can be achieved by updating our structure file like this.

We've defined an array with the ids of document types we don't want to display. Then we take our list of items to display in Sanity and filter it using our exclusion array.

The last bit we'll cover is creating custom items to add to the content sidebar.

In our Sanity setup, we have a document type called "content" which is used for both 

​. Both types have a similar structure in that they each have a header image and then a large block of content entered using a WYSIWIG editor.

However it gets confusing in Sanity having all of those items lumped into a single "Content" item in the sidebar. What we really want is a sidebar item for the Blog Posts and a separate one for Case Studies.

First we get all of the documents with type "content" (this includes both Blog Posts and Case Studies).

Then we build a sidebar menu item that contains just the Blog Posts and another with just the Case Studies.

Finally, we add both of those custom menu items to our list.

HTML, CSS and Javascript form the "presentation layer" of modern web development in your mobile and desktop browser. These things together are considered "Front-end Development". The tools, techniques and standards are changing all of the time - but our development team is always staying abreast of the latest. For our partners, we do the research, experimentation and testing needed to make sure your audience has an accessible, fast, reliable experience.

Frontend Development

Back-end development does all the heavy lifting behind the scenes. From database design and deployment to writing application programming interfaces (APIs) to simply storing and serving your content, we’ve got you covered.

Backend Development

Dive into the Sanity Structure Builder

In our line of work, there are a lot of different ways a development project can happen. Typically, clients rely 100% on our skills, knowledge, expertise and capacity to get their project done - but sometimes, we get the chance to collaborate with another team - an opportunity we love!

Most of the time, a client has a technical need that they wouldn't be able to do themselves. We do research to figure out how to solve their need, then we build something. In that case, it's just the VIA team building the stuff and the client double-checking as we go to ensure they're happy with what we're building.

Sometimes, though, a client has their own team that we get to work with. This is an opportunity that we love. One of our greatest strengths is working with other teams, whatever their capabilities might be and however we might fit in.

Often, especially on smaller sites, a client might have a developer who's building the site and they need help with the hosting side of things. We have a top-notch hosting infrastructure (WP Engine for WordPress sites, Rackspace for everything else) plus loads of experience with other hosting platforms like Netlify, FlyWheel, Cloudways, GoDaddy Hosting, etc etc.

In those cases, we can help make recommendations to ensure that a client site is robustly hosted and within the client's budget. We have also helped automate deployments, troubleshoot hosting issues and so on.

Last year, we got the opportunity to design a 

KPA uses a content-management system called 

As you might expect, an organization like KPA has their own development team for managing Sitefinity and another team for managing ticketing. Given the scope of the redesign project, that meant that we were heavily embedded with their team. That meant giving their developers access to a shared Slack channel for rapid communication, Github for code-sharing and even having their lead developer in our office for collab sessions every week.

Given KPA's expertise on building and managing Sitefinity templates and our expert knowledge of front-end web development, we were able to divide up the work fairly evenly. We developed a build pipeline that let us generate static HTML templates and stylesheets based on the redesigned brand. Each template represented a small chunk which could be easily turned into a Sitefinity component (since Sitefinity pages are built by dragging and dropping components onto a page). KPA's developers could grab those templates, build their Sitefinity components, drop in the CSS and, voila!

For the ticketing portion of the site, we decided to build it as a single-page React application. This let us do the templating and Sitefinity work in parallel with the ticketing development. We handled the React piece while KPA developed the API to let us integrate with Tessitura.

. A tight collaboration yielded a fast, flexible, and beautiful site.

A scenario we're great with is helping an expert team that has too much work.

 (CKD), another fantastic Midwest dev/design agency. They reached out to see if we could help with development on a large PHP + Laravel (our favorite PHP framework) project, a space where we feel right at home.

Their process was extremely well-organized. Everything was in a ticketing system with milestones and lots of details. They had a very active Slack presence, a good codebase, version control, etc. That meant our on-boarding was fairly easy.

We had Slack calls every few days to list out which tickets they wanted us to tackle. Then we worked through those tickets until we were done and ready for more.

I, personally, love these kinds of engagements because we, in addition to being useful to our client, get to learn a ton in the process. While we have loads of PHP & Laravel experience, you can always learn so much from studying someone else's codebase. It's an opportunity to think about how you might have done things differently 

 to pick up ideas about how to organize a project or learn a new way to do something.

We loved working with the CKD team and they appreciated how quickly we were able to ramp up and be productive on their project.

In the end, everything boils down to working with other people. My mission statement on my personal blog includes this:

I firmly believe that the days of a developer working by themself in a room are over. Software Development is all about collaboration. The ability to work with other developers and clients is just as important as the ability to write code. I love to work with awesome, smart people making beautiful and exciting things. I love making things that people will use and enjoy.

That's something that VIA Studio embodies to its core. At the end of the day, like all trends, technologies and design styles come and go.

All that matters is collaboration and relationships.

Custom Dev

Partnership

Works and Plays Well with Others

There is a very well known concept in development circles called 

It describes a developer’s tendency to write something from scratch when there is an existing solution they could use instead. This is definitely something I’ve been guilty of many times in my career and there are lots of reasons for it.

There’s a perception that off-the-shelf solutions are too expensive. A custom solution will be cheaper.

Sometimes, it’s a simple lack of knowledge of what solutions are already available. Other times, it’s a lack of understanding of the problem that needs to be solved.

But there’s another reason for NIH that might be even more common, even if developers don’t want to admit it.

Here are a few cases where custom development 

When you’re going to license the software

We found a niche market of small organizations that needed to manage donations from different companies. We wrote a custom solution that could be themed and customized, then licensed that solution to the different organizations that needed it.

When you have to connect multiple systems

This was the reason for our rebuild of the 

 website a couple of years ago. They needed an easy-to-use CMS but also needed to maintain all of their data in Salesforce.

While there are some existing solutions to connect the two, none of them worked with the level of fidelity that CNPE needed.

When there is a ton of business logic to consider

 is a local organization which provides different grants for religious scholars.

They needed a system for managing applications, documents, users, plus host of additional content pages about their organization. There are plenty of tools that do those sorts of things. But LI has a fairly complicated process involving deadlines, referrals, 3rd party contacts, etc, etc.

In order to give them total control over their process while still automating as much as possible, heavy custom development was definitely the way to go.

Don’t automatically assume you’re wrong when you decide to go the custom route. But make sure you’re doing it for the right reasons!

Pitfalls of Custom Development

 is one of our favorite hosted ecommerce platforms. It does a great job of making it easy to manage products, product variants, coupons, refunds, etc etc etc. It also has a pretty decent theme system so you can customize your online store to match your brand.

It’s a perfect example of “pick one thing and do it really well”. But that also means it’s not a replacement for an entire website.

 website, they already had a large Shopify store. They had several years of sales data they wanted to preserve and they wanted to continue managing all of their product inventory on Shopify.

They wanted lots of content and other functionality on the website-proper so re-theming the existing Shopify store wasn’t an option.

The lazy route would’ve been to build the website and kick users over to Shopify anytime they were doing something product related. However, we at VIA Studio, are not lazy! We want to find the best solutions for our clients and their customers and we want to do it on time and on budget too.

Luckily, Shopify has us covered by offering a great 

. Using that and WordPress, we built an admin system that let Firstbuild pull in available products from Shopify. They could then extend those products in WordPress with additional imagery, copy, videos, etc. Any time they added or updated a product in Shopify, those changes were immediately available in WordPress.

On the end-user side of things, we wanted to have a rich easy-to-use shopping experience. Shopify also makes this super simple with their 

This takes care of all of the complicated stuff like managing a shopping cart, quantities of products, pricing, etc. We could whatever exciting UI we want and easily wire it up to Shopify. Then, when it’s time to pay, we send them to Shopify and they take it from there.

It’s the best of all possible worlds. We get the flexibility of using a tool like WordPress while letting Shopify handle all of the complexity of ecommerce.

One issue we ran into with the Shopify API was trying to marry data from the Admin API vs the Storefront API. The problem is that they use different ID formats!

On the Admin-side, a product might have an ID like 

Z2lkOi8vc2hvcGlmeS9Qcm9kdWN0Lzc0NTIyNTgxNDAzMA==

This lead to loads of initial headaches trying to move data around from the admin to the front-end and still know which product we were dealing with in the code.

After a bit of research, we realized that the Storefront ID has just a Base64-encoded version of the Admin ID!

That lead us to write this handy little function and all of our woes were solved*:


* It’s been a couple of years since we did this so there may be a better way to do it. If anyone knows what it is, 

Need one platform to talk to another? We’ve got that. Automation, synchronization to real-time APIs, we’ve built and managed them all. Ecommerce and Customer relationship management (CRM) integrations are our specialties, but so far there’s not been two systems we couldn’t put in touch with one another.

Platform and CRM Integrations

A custom ecommerce experience with Shopify

We love making things (usually digital but 

); whenever possible, we like to share the things we make (like our 

Over the past year, we’ve been doing a fair amount of 

, and have found that debugging/testing/exploring the Salesforce REST API can be a little tedious by hand.

Once you have a token, you can make API calls, like getting usage limits


Doing things like SOQL queries is a pain because you have to url-encode the query by hand for the command line.


To that end, we’re releasing an Open Source (MIT-licensed) command-line tool for exploring the Salesforce REST API.

Now you can type simple commands at the command prompt to do all sorts of handy things with Salesforce like query objects, run SOQL commands, etc.

You’re welcome to fork our code and make your own additions. If you do something cool with it or think of an interesting new feature to include, 

We Made You an Open Source Salesforce Command-line Tool, You're Welcome

People underestimate the importance of keeping a tidy git history. A clean git log can be an invaluable tool for tracking the state of a project over time.

When I first started using git, I didn’t give much thought to the kind of history I was leaving behind which meant commit logs like this:


My process was “do a bunch of work,” “one giant commit,” “leave a crap log message.” You might say that’s OK if you’re just working by yourself, but I think there’s benefit to staying organized regardless of whether or not you’re solo or on a team. It’s important, even for yourself, to be able to retrace steps to see what was done and why.

That’s why I adopted the strategy of “do a little work,” “commit,” “do a little more,” “commit,” “repeat,” “git rebase to cleanup history.” The basic idea of 

 is that it lets you rewrite history by re-ordering commits or combining multiple commits into a single one.

 if you’re not familiar with git rebase.)

In the above, I created a PHP class called MyClass and added it to git. Then I realized I’d committed an empty file so I went back and added the class definition. Then I realized I didn’t add a class constructor so I did third commit to add it.

There isn’t a lot of value in having those three separate commits because it’s all part of adding the MyClass class. What I really want is a single commit that encompasses all of that work.

And the way to do that is an interactive git rebase (

) which pops up an edit window that looks like this:


(You’ll also notice a bunch of comments showing the available rebase commands. We’re just going to focus on fixup and squash for now.)

If we don’t change anything, save and exit, our commit history will be unchanged since we chose to “pick” each individual commit.

What we really want to do is edit the rebase to look like this:


Each line that starts with fixup will squash that change into the change before it and throw away the log message (squash is the same as fixup but the log message for each commit is preserved and combined).

After the rebase, our history looks like this:


Now we have one commit that contains all three of the changes we made above.

That’s the basics of rewriting history with git rebase, but there’s an even easier way to do in Git 2.7 and it’s called 

Let’s say I’m going to work on a new method for MyClass and I’m going to make a bunch of small commits and clean them up when I’m done.

Now I’m going to make another change but instead of just doing a normal git commit, I’m going to do

do a Fixup Commit – basically the word “fixup!” is prepended to the log message (you can also use 

we’re fixing-up the first commit with a log message that starts with the word “Added” (you can also specify a commit SHA)

After the fixup commit, our log looks like this:


Notice how the fixup command has been automatically added for us? The same would be true of squash! commits.

The autosquash feature works for as many commits you have in the rebase that are tagged with 

 and it will even reorder commits if you have multiple fix-ups happening on different commits in the rebase.

So keep your git history tidy. Your teammates and your future-self will thank you for it.

Mark Biek