Smart speakers are here, and they are not only changing how we interact with technology, but also how we get things done. As everyday users increasingly rely on them and businesses ramp up to use them, Voice Apps are now the new frontier for app design. Have you wondered what it would take to design an app that runs on them?

People use now using their voice and smart speakers for just about everything - from listening to music, catching up on the news, checking the weather, and setting daily reminders. By 2021, forecasts show that the use of smart speakers will top tablets.

You have built a Voice App and it works well. You needed to use voice to expose data that you already had. It took a few iterations, but now users are happy with it. Your next challenge is needing to having your Voice App get data from the user.

If you are using the Violet framework then collecting data from users should not be hard. If you need an intro to Violet, see the article on Building a Voice App in 30 minutes. We will build on top of that article here.

You have mastered building web apps. Maybe even building mobile apps. But what about these smart speakers that are now sitting in people’s living rooms? What about our new found ability to talk to apps on our phones?

Did you find yourself wrestling with native APIs and small platform-specific details when you tried building a skill for Alexa or an action for Google Assistant? This doesn’t have to be the case. Building of Voice App can be simple and we can do it in 30 minutes.

The last year has been a fun ride. Since we open-sourced and started talking about the ideas behind Violet we have been able to learn lessons from the experiences of how some of the best Voice Apps have been built.

Not only have we built these into Violet, but we have also been talking about them at different places.

For the greater part of this last year, I have had the pleasure of building a lot of Voice prototypes. These have included Alexa skills, actions for Google Home, as well as building standalone devices (powered by AVS) with custom wake-words and voices.

When building such Voice Apps/Skills, I quickly noticed the need for programming with a fairly powerful yet low-level platform-specific API’s. It reminded me of the first Web apps that I built, where we needed to program to the different DOM API of Netscape Navigator and Internet Explorer.

The dream behind Architexa started when I was working on my PhD. I realized that as programmers, we often have to look at a lot of code. And, that if we have tools to help experienced programmers get a better view of the code (and in particular its architecture), we could save them a lot of time.

The underlying stats are shocking – coders spend 5x as much time modifying code than writing new code and 3x as much time understanding code than modifying code (more – When Understanding means Rewriting). With that, the work started first as a tool (Relo) to create box-and-arrow diagrams (like class-diagrams) using the code as a guide. It then added another tool (Strata) to guesstimate a layered-architectural-diagram using code dependencies with heuristics for breaking cycles. And, finally with Architexa we added a tool to show run time information in code using sequence diagrams.

Over the past few years I have had the fortune of writing papers, blogging both publicly and internally for the companies I have worked at, teaching, and even presenting at conferences. This blog is an attempt at pulling all that into a single place.

Oh, and part of the agenda is discussing best practices with various emerging technologies, innovation, and some of the open sourcing projects that I care about.

A lot has been written about blogging and working on open source projects to improve your coding skills. They are great ideas. In addition, I like attending user groups.

But there is more. Becoming a great software developer also means making sure you are able to think as the situation demands, as opposed to being biased in the manner that your current project is developed. It means making sure you are comfortable building very different types of projects.

Working on a software project after it has shipped for 1 or 2 years can be fun. But sometimes you feel like you need to do something a little different – to get different ideas, different perspectives, and different types of challenges. I feel like I am in the midst of such a journey, one that has begun to have some results that were unexpected when I started. The big lesson has really been that I need to *talk* to more people about coding.

I am a big fan of open source. I use it every day, and recommend it often. But I do want to have a balanced perspective on it. I recently posted about the pleasures of using open source. This is the other side of the coin, the pains of using it.

My hidden agenda about talking about such problems with open source usage is so that we as a community can come up with solutions to some of these challenges. But first, I really want to hear and write down the main challenges, so that we fix the right problems.