A Guide to Working Remotely, as a Team.

How half our team traveled abroad for two weeks and still stayed productive.

We’re no strangers to working remote.

Back in October, I worked from Banff, Alberta because I am passionate about climbing mountains. (Summits are awesome!)

Our Branding Goddess and Design Adventures, Manon, spent 4 months working remotely while traveling the world last year. She wrote all about it in this great guide.


This year, we pushed the concept further. Eight of us moved to Puerto Rico for two weeks and still managed to produce great results. Here is how we did it and what we learned.

Continue reading “A Guide to Working Remotely, as a Team.”

A Non-Technical Guide To Understanding Machine Learning

In last week’s post, we discussed if machine learning was right for your business. As part of that effort, I recently went through the process of learning the ins-and-outs of machine learning and realized most information out there is technical and aimed at developers or data scientists.

I thought an explanation from a non-technical person might be of interest.

Let’s begin.

What exactly is machine learning?

The simplest definition I came across:

Machine learning is “[…] the branch of AI that explores ways to get computers to improve their performance based on experience”. Source: Berkeley

Let’s break that down to set some foundations on which to build our machine learning knowledge.

Continue reading “A Non-Technical Guide To Understanding Machine Learning”

Is Machine Learning Right For Your Business?

Most businesses recognize that machine learning can generate exceptional value but many still wonder how, in what specific areas, and if the time is right to integrate it within their data strategy. Today, we explore what questions you should be asking to know if machine learning is right for your business. Continue reading “Is Machine Learning Right For Your Business?”

Web Developer

Want to join our team? We’re looking for a Web Developer! Send your application to queenbee@arcbees.com.

At Arcbees, you will have to develop web and mobile solutions by utilizing several languages (Java, TypeScript and friends) in an environment where amazing coding skills meet an unmatched sense of humour. To be part of the Arcbees team, you will have to demonstrate your extraordinary potential and your motivation to become a coding god (just like Gohan looking for Old Kai). Continue reading “Web Developer”

How we used GWTP in Ruxit

When we initially considered options for developing Ruxit, we were faced with extremely high expectations from our executive team. We were tasked with creating the coolest, most modern, and responsive Web UI design possible. We were convinced that our goals could only be achieved through a client-side UI approach, so we started out with a vanilla JavaScript approach. However, because the Ruxit UI is so complex in terms of the number of elements, the amount of asynchronous communication between the browser and the backend, and the fact that we had multiple teams in three countries contributing to our UI, we recognized after about six months that our development approach couldn’t really handle the complexity of Ruxit. All was not lost, however…

When looking for a framework to build our codebase on, we came across GWT. Although we didn’t have any prior experience with GWT, we were a team of seasoned Java devs, so it seemed a natural fit for our skillset. Plus it offered the client-side UI building approach we still believed in. Still, a lot of base work was required to build out the basic infrastructure of our application. This is where the GWTP framework came in handy. It made our introduction to GWT much easier and gave us a headstart in development.     Post_GWTP_Story_v2-01

One of the major problems of our vanilla JS solution was that we had to take care of every single piece of application and UI logic ourselves. And, because Ruxit is a single-page application, there was a lot of logic to be tracked. GWTP provides lots of helpful boilerplate functionality like view lifecycles and connecting URLs to corresponding views. GWT is a great technology with a learning curve that’s not too steep. However it does take some time to adjust your mindset to the work approach that’s required for succeeding with GWTP.

As mentioned, GWTP made our start with GWT much easier but at the same time the framework it provides is not restrictive. Yet it covers most of the basics that are needed to successfully get your application up and running. Over the time that we’ve worked with GWTP—which is three years at this point—we’ve never felt that GWTP has constrained us, which is phenomenal. We’re convinced that it’s the balance between structure and freedom that makes GWTP so appealing.


One of our favorite features in GWTP is code-splitting. Sure, code-splitting is included with GWT, but you have to take special care to set the split points right. If you don’t get the split-points right from the beginning, it can be really hard (if not impossible) to introduce them later as the code is usually too tightly bound by then. GWTP’s Model-View-Presenter architecture offers an easy and efficient solution to this problem. By applying MVP, your code automatically comes in the right granularity for code-splitting. Without it, we would likely be in a very bad situation at this point, needing tens of megabytes of UI code to be loaded into the browser right from the start. Instead, when opening a Ruxit view for the first time, only the code required to render the current view is downloaded.

With GWTP your code is typically loosely coupled. The advantage to this becomes apparent once your team and code grow in size. Today we’re about three years into development with GWTP and we’ve grown into six teams spread across three countries with almost 230,000 lines of code checked into our repository. Thanks to GWTP our teams don’t step on each other’s toes; each team only runs the views that are relevant to their work. This makes GWT development much faster and less error-prone.


As we had a considerable amount of backend code running from the vanilla JS version we developed early on, we didn’t want to revise all of it just to match our new GWT frontend. That’s why we decided to stay with JSON for communication between our frontend and backend. With this approach, we were able to re-use nearly 100% of our backend functionality without losing anything. The web really is a great place to be a dev. 🙂

We believe that seeing is believing. So, want to see what can be achieved with GWT and GWTP? Have a look at the screenshots of Ruxit below, or better yet, sign up for a free trial of Ruxit.



We’re very proud of our results with GWTP. Having started several additional projects since then, no one was looking for a new development alternative when a new project came around.

Subscribe to our newsletter to be notified when the next post comes out!