An Introduction to SVG – Part 1

You remember that kid at school sitting in the back of the classroom whom nobody ever talked to? Everybody knew he was there, most of them knew his name but nobody wanted to be teamed with him when it was time for teamwork because they all wanted to work with their long time friends.

Some of you reading this are probably saying… Dude, that kid was me man!

Then one day, during art class, your best buddy wasn’t there and you had no one else to work with besides this loner sitting in the back. That’s when you finally found out that he was one of the coolest kids at school, with the sharpest collection of crayons. Continue reading “An Introduction to SVG – Part 1”

Tips and tricks with Jukito

After writing an enormous amount of tests for GWTP using Jukito, I ended up beating myself on many issues. Fortunately, many were common enough to have me noting them down.

This post will give you tips and tricks you can use with Jukito to make your life easier when testing things in GWTP. A few of the following tricks are also briefly shown in the previous posts of the series. I’ll try to give a little more detail for each of them. Continue reading “Tips and tricks with Jukito”

Testing client-server communication with REST-Dispatch

A lot of the tests that are written in GWTP applications focus on client-server communication. Fetching and saving data is what most web applications do nowadays.

You can use whatever library to accomplish this work, however, in this post I use REST-Dispatch and Resource Delegates, from gwtp-extensions. They come with nice testing utilities that I’ll show you. Continue reading “Testing client-server communication with REST-Dispatch”

Development on a fast moving Web

Web development is full of passion. It’s a big thing that moves fast, where new technologies, new frameworks and new tools are created on a daily basis by individuals, groups and corporations, all striving to create better things. Web development is also full of debates, because of all of these tools, speed and pride.

As Web developers, it’s hard to stay afloat, to keep pace with all of these new shiny toys. We tend to see the big picture. The Web. Then, everything that gravitates around it. It’s really close to our job, but yet, that’s not exactly it. We create websites and applications. They all live on the mighty Internet, but rather than seeing all of this as a whole, we need to look closer, and see all of these thin layers, all interacting together. Most layers don’t need to be in a constant novelty war. Our job needs to evolve, but not that fast, not on everything, and surely not daily.

I like to think of Web development as three levels of abstraction all tightly living together: Standards, Technologies and Tools. Continue reading “Development on a fast moving Web”

Testing patterns in GWTP

This post is intended to be the next steps towards a TDD approach with GWTP. We’ll try to show you the patterns and workflow of writing a GWTP application in a TDD fashion. Continue reading “Testing patterns in GWTP”

3 Steps to Make your Culture Unique

Three months ago, we published our first blogpost which dealt with our will to define our culture and questioned what initiatives we could set up to help us fulfill our goal. Since then, we took  a further step  in our journey, and this post  is meant to show you the progress we have made so far.

In the last post, we introduced our 9 values. We could have simply stopped with these and tried to put them directly in use or just listed a number of adjectives such as collaborative, innovative or passionate… But at the same time, it does not define who we are and what makes us  unique.

– If you want to be able to find your DNA, you have to dig deeper, you have to go further in defining your culture –

Our first step was to define the values. We knew our journey to define our culture was supposed to go beyond that. The next step was to create the manifesto in itself.

What is the Arcbees’ Culture Manifesto?

The Arcbees Culture Manifesto is a written statement of all Arcbees’ employees regarding our culture and the way they see the organization as a whole.

We went through three steps to define it.

Step 1: Dig deeper, wrap it up and name it

In the previous post, I mentioned how we took the necessary step to obtain everyone’s list of values. With those values came an explanation about what it meant for them.

Make them match: Collecting those explanations and making them work together was the hardest part and the list of values came from the best of each one of us. But then, we needed to find a way to explain each value so that it could resonate in everybody’s mind.

I took each one of those explanations and put them in a single document to try and find the words and ideas which were most common.

Don’t interpret! This step is rather a long process. The objective is to not transform or interpret what a person is saying. One has to take the explanation, try and make it match with the right value and match it with the others.

For the most popular values, we received 7 or 8 explanations coming from the 12 Arcbees’ employees. It means 8 ways to explain it, 8 ways to name it, 8 different lexicons and 8 unique minds behind it.

Take your time and dig deeper: It took me time to wrap up and summarize what people wanted to say, to find the essence in each one. I asked questions to try to understand what they meant behind each sentences.

You are not Superman! I want to warn you already about something. It is not a one man job as you need inspiration from others to find the right words and find the right flow in the sentences. At Arcbees, one of our principal values is collaboration and this manifesto is a collaborative work.

At the end, we wrapped it up and came up with a list of 9 values:


Step 2: Share with the team and gather feedbacks

Once everything is ready with the manifesto and you wrote a 0.8 version, it’s time to start to get feedback from the team.

Feedback process We prepared a presentation for the team and scheduled a meeting to have everyone present at the same time. The point was to have everyone’s reaction in person.

We introduced each value and its explanation. We then gathered the comments we received on things such as titles or the words used on the explanation itself.

Appropriation begins… At this part, you will notice people starting to appropriate the different values. Some of them stay more than others. You will witness strong reactions, which is good!

After the meeting, each person read it again and gave their own comments. Sometimes directly to me, sometimes by using Slack to have a discussion all together on a particular value.

Getting things ready for the final step The final request was for everyone to rank the values by priority for them from 1 to 9. This ranking would help us determine in a collaborative way which value was the most important at Arcbees.

Step 3: Plan to make it alive

Once the final document was made and we obtained the ranking for each value, we able to start our next step. This ranking has created a plan for further work around the manifesto.

– The goal of this exercise is to make your culture unique and your company! –

One word: Focus!!! We decided to focus on one value per month to accomplish step 3. We are going to apply the same recipe as for our other projects: an agile methodology inspired from Scrum. We want to use it to implement our values. By doing sprints lasting one month, we will define more specifically what is the value and actions inherent to it.

Each month will start by a brainstorm session. This session is open to all, and everyone can bring these ideas about the value we are focusing on.

At the end of each month, we will conduct a retrospective of the past month and the work done around the value. These tasks will eventually enrich our manifesto.

We are going to continuously do this work and improve our values ​​and our manifesto.

We will keep our communities updated with our progress. In February, we will focus on the value “We believe in the individual.”

Follow us: Subscribe to our newsletter, or on social media (Facebook, Twitter, Google+) if you want to follow up on the story of our commitment to our culture.

Using GWT 2.8 beta 1

EDIT : An earlier version of this post talked about Java 8 Streams, which are not supported by GWT 2.8 for the moment. My apologies.

A few weeks ago, the GWT Team released on Maven a beta for the new version of GWT: GWT 2.8 beta 1. This new version has been announced for a while and was eagerly awaited by the community.

Other than speed improvement and many cool new enhancements, there are new features we can now use in our GWT application. One big feature of this version, in my opinion, is the support of lambdas, a part of Java 8.


In Java 7, if one wanted to pass a function in parameter, they had to do something like that :

In Java 8 (and also in GWT 2.8), simply do this:

We now have a more elegant way to write exactly the same functionality. It makes for more compact code, with less clutter and cleaner code.


Another thing to note, the interoperability with JavaScript is no more experimental. You can now simply use the annotations (@JsType, @JsProperty, etc.) and directly use a JavaScript library in your GWT code.

As Brendan Donnelson said in his Q&A, you can now imagine – if you have a GWT and JavaScript expertise in your business –  a seamless collaboration between JavaScript developers who do part of the application and GWT developers who use their work in the GWT application.

For example,

This example was taken from the current specification of JSInterop which covers a lot of the possibilities of JsInterop. It is also possible to make content in Java that could be exported and usable in JavaScript. A few of our developers are currently exploring on both sides of this coin. I think it will make for good next articles on this blog.

Concrete example

If you want to see concretely what a migration to GWT 2.8 beta1 is like on a typical GWT 2.7 application, just refer to this pull request. I am currently in the process of moving our BeeStore sample to GWT 2.8. It will give you an idea of how to do so.

We just covered the tip of the iceberg of what is new in GWT 2.8. See the complete release notes for the complete list of features that GWT 2.8 beta 1 brings.

Feel free to tell us what cool web application you did (or plan to do) with GWT 2.8 or JsInterop in the comments!

Live GWT Q&A with David Chandler on GWT 3 and the Sencha GXT roadmap

We are pleased to announce that we are going to hold our February live Q&A with David Chandler on February the 10th..

David Chandler will be our guest for this one and he will be discussing the upcoming changes in GWT 3 and how it fits with the next version of Sencha GXT.

David was formerly the GWT Developer Advocate with Google and is now GXT Product Manager and Developer Advocate with Sencha, Inc

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Return on Kevin’s answers on live Q&A on GWT Material

As you may know, 4 months ago we decided to put in place a new initiative for the GWT community. We wanted to highlight what was happening in the GWT community and start sharing the knowledge.

We held 4 Q&As already, which you can watch here. In preparation of those Hangout on Air events, we prepared a series of questions for our guests.

We know that some of you don’t have the time to watch a 30 min. video, this is why we took notes during the event.
You will have a hint of the live event which you can watch below:

Mark Kevin Baldemor was our guest for this Q&A and he talked about GWT Material. Founder of the Gwt-Material Project,he has been involved in the community for three years now.

Phil: Who are you and what do you do?
Kevin: I am Mark Kevin R. Baldemor, I’m currently staying in the northern part of the Philippines, surrounded by oceans and tall mountains with different species of wild animals. I am now 21 years old and I graduated at Informatics College Philippines with an Advance Diploma on Multimedia Technology in the year of 2013. I have my Internship at BPM Conseil, a french company located in Lyon, France and luckily I did my first job there with the introduction of GWT Technology, HIbernate, OSGI and lots of Google API’s. I do web and mobile development using open source kits like Android SDK and Phonegap. After my work life with BPM, I continued my journey to develop my own open source GWT Ui Framework built Material Design called “GWT-Material”.

Phil: What company are you working for? Can you tell us more about it and your role there?
Kevin: Now, I am working for I3 (Canadian Company) – on the IT Department as a Gwt UI UX Developer and a Project Owner and Contributor of gwt-material open source project.

Phil: Some questions about GWT first: When and why did you start using GWT?
Kevin: I started using GWT on 2013 from version 2.5 to 2.8. I loved the architecture pattern of GWT using RPC to communicate with the Server side components. Then, I tried to make some sort of starter projects using GWT for front-end and Hibernate for the back-end which makes the development process more exciting. As a result, I did more and more projects inside my company and the result was very nice but there was a code duplication when I included the CSS, JS Resources to build a custom widget. That’s when I tried to learn how to build a UI Framework and hosted it on Github with the help of other GWT Contributors to make it more Modular and easy to integrate to other projects.

Phil: Now about GWT Material in itself, you are the founder of this project. When and why did it start?
Kevin: Yes I am the founder of this project. It was founded January of 2015 with an alpha version hosted on Google Code, but later on with the help of other GWT Contributors, we tried to host the project on Github and released a Maven version (1.0) which improved the productivity of the project plus the showcase app. The history of this project started when Google announced their design language called “Material Design” and I discovered Materializecss (a CSS Framework) founded by Mr. Alvin Wang and his team. They wanted to build a website using the design specification of Google. With the whole idea, I finally decided to create an open source Apache 2.0 license GWT Based widgets built in Material Design specifications called “gwt-material” and I added some custom components and called them “gwt-material-addins”, like Autocomplete, Time Picker, PathAnimator, Subheader and etc.

Gilberto Torrezan Filho: Talking about GWT Polymer, doesn’t GWT Material have the same purpose as Vaadin’s project? Will they be competitors to each other in the future?
Kevin: GWT Material is totally different from GWT Vaadin Polymer project, because our project is totally based on GWT widget based systems built on Material Design Specifications and with the help of Materializecss contributed by Avin Wang. GWT Vaadin created their generator api to create paper components using JSInterop, soon on GWT Material we will also implement those features using Elemento and JSInterop to support GWT 3.0.

Zakaria Amine: Is GWT material design library production ready?
Kevin: Yes it is production ready, and honestly we have news coming from the community: they have successfully built a gwt-material design application on Web and also on mobile development using Phonegap. We also provided templates for a guideline on how to develop using gwt-material.

Below are the list of applications built by the community for their personal and company projects:

  1. TripWeGo by Julien Guibert
  2. Healthphere by OrNot (Github username) –
  3. MyMoney by Werner Kok

Here are also the list of the templates we provided :

Phil: Question # 5 : What can you tell us about the community?
Kevin: About the community, we have now 118 members on Gitter Channel, 116 members on Google Plus and 128 Stargazers on Github which is a good news for the project itself. Many users submitted their Pull Requests for new exciting material design widgets. Some are submitting issues which improves the stability and quality of the project. GWT Material has 9 members, some are part time contributors and others are actively contributors of the project. Thanks to Ben Dol (New Zealand) on the huge code refactoring made on 1.4 release including the modular theming of the project called “gwt-material-themes”. For the Maven releases of the project, Christian Lacerda (Brazil) is our active releaser for the said project. Sometimes we organize online session using Team Viewer to help one another on how we can leverage and discuss about the project.

Phil: Question # 6 : What can you tell us about it and its evolution?
Kevin: GWT Material is a Material Design based widgets with the help of Materializecss as core framework. We release

  • 1.0 for the (Production Release) it includes the core material widgets.
  • 1.2 Integration of Phonegap plugin with gwt-material
  • 1.3 Maven Official Release
  • 1.3.1 Bug fixes for 1.3
  • 1.3.2 gwt-material Themes
  • 1.3.3 Material Design templates
  • 1.4.0 Huge Code Refactoring
  • 1.4.1 Bug Fixes for 1.4 (Upcoming)
  • 1.5.0 gwt-material-addins components (Upcoming)

On each release we are very thankful to the contributors for their support on gwt-material project. I am very happy that until now the project status is still actively maintained.

On 1.5.0 version, we added MaterialPathAnimator to provide meaningful and delightful animations to transform a source widget into target widget. It helps the users to not loose their interaction between two components e.g a Card transforms into an overlay panel or a button transforms into a card. Also we tried our best to implement core animations like fade in/out, slide in/out or even page transitions into the Material Design widgets. We also added a built in Google Icon Fonts hosted internally and we provided a morphing animation using MaterialIconMorph.

Mohammed Al-Hammouri: What about the performance or size of the library?
Kevin: First, I’m not really good on performance optimization about web applications, but for the css or js resource, files of Materializecss can be measured using their jasmine test. Now, I am developing some big applications and the result is great, it is fast. I don’t have any issue on app’s performance including the server side and populating the data into a specific material design view component. On Phonegap, I tried to integrate my web app but it seems to be too slow because of the JQuery animation plugin which kills the performance. What we did is that we separated the modules into different repositories like gwt-material-theme and gwt-material-addins so that the user can choose whether they want to have only the core components or include the addin components.

Gilberto Torrezan Filho: Materialize CSS is the base project for GWT Material, but currently GWT Material have more components than Materialize CSS. How is the relationship between Materialize CSS and GWT project teams? What would happen to GWTM if materialize CSS is discontinued?
Kevin: This is a good question. I talked to Mr. Alvin Wang about the project and he was happy that their project was used by GWT Material. As for me, I am very thankful for their contribution to the world of web development. If Materializecss were to be discontinued, it is likely that we would have already created our Plan B: “gwt-material-addins” – a collection of custom Material Design Widgets plus Community contribution built in pure gwt-material widgets.

Phil: Question # 7 : What is the future of the GWT Material?
Kevin: This is a good question. As for now, we all know that we are waiting for the GWT 3.0. Everything is new as I heard on the GWT community, such as the usage of JSInterop, Java 8, Web Components and other tech behind it. With gwt-material 2.0, we are thinking about implementing all of these inside the project to provide a bullet proof support for the said open source project to make gwt-material a great project and supports GWT 3.0.

Also we are trying to build more Material Design Widgets and trying to refactored it using JSInterop. We are on the Research and Development process to learn how to use it and provide the architecture of GWT Material 2.0 and will be able to release on Maven Central as soon as possible.

Martin Hollerweger: How do you see the future with GWT and js-Interopt? What are the main benefits of GWT compared to other solutions like ionic?
Kevin: The future of GWT and JSInterop is interesting but it has a minor effect. First with the use of UiBInder and widget system: these features will be removed on GWT 3.0, I think. But for gwt-material, we will try our best to support it using JSInteropand Java 8 other features. For the last question, sorry but I don’t have any idea about Ionic.

Martin Hollerweger: Will Gwt-material switch fully to js-interopt?
Kevin: This will depends on the discussion with the community. If they want to switch fully to JSInterop then we will do it for them but in my opinion as a founder, it is good to have backup plans to anticipate the migration such as creating an old branch to backup the previous features that does not support JSInterop. Then, we will create a new branch for the JSInterop migration so that the user will have options if they want to switch their apps into JSInterop support or not.

Project shared
GWT Material repository –
GWT Material Addins –
GWT Material Themes –
GWT Material Showcase –
GWT Material Phonegap –
Google Plus Page –
Contributing Guide –

4 Rules of Simple UI Components

Too often have I seen simple web applications become a huge pile of intertwined, indecipherable JavaScript code. As features are added, code is added into seemingly random files, event listeners are accidentally duplicated, jQuery selectors stop working because someone moved the DOM around one too many times and sooner or later you start to feel the consequences.

It fails randomly.
It breaks in strange places.
It has regression bugs.
And no one wants to change it (for fear that it will become their code!).

Chaos and pain ensues. From my experience, the code becomes complicated way before the interface becomes complex. I know very few truly complex user interfaces, but the internet I browse is an endless stream of complicated JavaScript code. Sometimes, I look at the source code just to amuse myself. Sometimes, I even do so before applying for a job. Uh oh.

How did the web become a breeding ground for both simple interfaces and complicated code? To make things worse, this complicated code is located in a codebase that changes all the time! It is very hard to get an interface right in a one swift commit. It requires successive refinement based on customer feedback. Although this code changes all the time, it is often the hardest part to maintain.

Maybe it is our infatuation for cool new JavaScript frameworks that led us astray, but we seem to have lost basic software craftsmanship practices.

Corey Haines wrote an awesome book called Understanding the Four Rules of Simple Design based on Kent Beck’s 4 rules of simple design, which I highly recommend. Inspired by this book, I tried to distill UI complexity and found 4 rules of simple UI components that should help us write better, simpler interfaces. This is nothing new, but somehow it seems to have been forgotten along the way.

Rule #1: Break it down into named components

Thou shalt not underestimate the power of good naming

Break it down into named components

This is the simplest, yet most powerful rule of software design. Whether it is to discuss with the client or to understand each other when saying “the thingy” broke, good naming has the virtue of bringing people together. Picking a good name today might even help your colleague better decouple code in 6 months. This is what Corey Haines calls behavior attractors in his book. It is easier to see where your new code should go when things are properly named.

For UI design, this boils down to sitting with the client and figuring out a name for each thing. What is this portion of the page called? This new kind of input, what should we call it? Name small things, agglomerate them, then name bigger things! If you want, you can follow principles from Brad Frost’s atomic design, which is a good starting point. Instead of saying “the blue bar in the viewer thingy is overlapping with the other side”, you could say that “the document toolbar in the patient history viewer is overlapping with the annotation explorer“. Once the vocabulary is agreed upon, this makes your code less prone to bugs and misunderstandings with the customers.

In order to name components, you must break them down to a manageable size. If not, you maybe end up with names that include multiple “and’s” or end with “Util”. Be careful to name components according to their level of abstraction. If you name something “Intervention Plan”, I expect it to be high level and be broken down into smaller components. Maybe an “Intervention Plan” is made up of “Observations” and “Directives”. Maybe “Observations” is made from an “Action Bar” and an “Observations Grid”. Notice how “Observations” and “Observation Grid” differ in their level of abstraction, this is important.

If you need to spark your imagination, I suggest you read this article from J.B. Rainsberger.

Rule #2: Do not assume your context

Thou shalt not care to know who thy DOM parent is

Do not assume your context

Now that you have components of decent sizes and with good names (don’t worry, this takes time to master), you might realize that there are far more opportunities for reusability than you ever envisioned. Read the remainder of this article to be ready for this!

DRY (don’t repeat yourself) is a good principle to adhere to, but components are not reusable by default; they must be made that way. The first thing you must be careful about is to make your components as context-agnostic as possible. After all, how reusable can a component be if it requires a specific context? Picture 40 components requiring 40 different contexts. Are you crying yet? If not, just know that in most cases, those contexts are neither obvious nor documented.

Do not worry, there is a simple way to prevent this! First of all, simply do not make use of your DOM parents or siblings! Imagine your components as having a “root” DOM node. You are not allowed to go upwards in the DOM past this point. Until web components are finalized and included in all major browsers, you may have to use discipline not to cross this boundary, but this can be done!

Now, this raises the question: how can we update a sibling or parent component? Think about it. It is OK for the parent to know about its immediate children, but a child should not know about its parent, yet it has to send a message to its parent. What pattern comes to mind?

There are a few acceptable solutions here, but one that is childishly easy to implement in JavaScript is an observer pattern. Call it observer or listener, for our purposes it serves the same goal: the child exposes a couple of listening points (say, onError, onNewDirective) and the parent registers a callback for it. Now you get components that do not need to know where they are included in the DOM or where in the DOM is the component they need to update. Awesome!

Rule #3: Give complete privacy to your children

Thou shalt not covet thy children’s DOM

Give complete privacy to your children

So far, we have named components that can be included anywhere in the DOM. Okily dokily! This is all fine and dandy, but chances are you will need components that are made from other lower level components (again, refer to atomic design for inspiration here!). That’s a good thing, but there is one strict rule: do not query your children’s DOM! I mean it. This is where most ripple effects start! You change one thing in that observations grid and somehow you end up breaking something else without noticing it. Or you do notice it and spend the next hour fixing all those places where they used that CSS class you just removed. Ouch!

This is fairly easy to avoid. However, as I said before, until web components are finalized, you may need to do this out of discipline. The reward you get in return is very high.

We now have clear boundaries for what a component can and cannot do. You are not allowed to explore the DOM upwards past your root node and you are not allowed to drill down in the DOM past your children’s root nodes.

This is nothing new. This is what encapsulation is all about! This concept has been around for as long as most of us can remember, yet we sometimes forget the consequences of not respecting encapsulation. Let the action toolbar know whether buttons are arranged with an <li> or a <div>. Instead, just call .addButton(myButton) on it. Do not interfere with the action toolbar’s affairs and let it handle its own buttons: it is its job! Now you have no reason to have duplicated jQuery selectors! All ripple effects from changing the DOM structure should now be contained within the boundaries of the component that manages it.

Oh, one last thing before one of you tries to hack this! Creating a method .getButtonElement() is not the way to go! Remember Tell, Don’t Ask? If you communicate with your parents using events, you communicate with your children using plain old message passing (i.e. method calls).

Rule #4: See the world from what you are given

Thou shalt assuage with what hast been given

See the world from what you are given

This is not a rule specific to UI components, but it is of crucial importance in JavaScript. Mainly this is aimed at all of you still using global variables everywhere, I hope you hit your toe on some piece of furniture!

You could state the rule this way: if a component requires a certain object to complete its work, it should be explicitly given to it. The only exception to this is if it is your responsibility to create said object. Since you have good names, it should now be obvious whether or not it is this component’s job to create the object. Just keep in mind that the factory pattern exists and is easily achieved in JavaScript.

Luckily, this is easily fixed in most codebases. Remember that your goal when refactoring is to work in small increments and keep the tests passing (you have tests, right?). If a component uses a global variable, just turn it into a method or constructor parameter instead. Then, whoever uses that component just passes in the global variable. Now fix those higher level components too. Rinse and repeat until you find the point of origin, then make an educated decision about where the object should reside.

This may seem complicated, but it is not. Now your components have explicit dependencies instead of requiring an implicit context. You improved the readability and reusability of your code, you should be proud! You will thank yourself in six months time.

As an added bonus, you just got rid of global variables which are a nightmare once you add concurrency. So far, JavaScript has been single threaded, but this will change. Better be ready than sorry!

What you should take home from all this

It sounds simple, doesn’t it? It should. Find good names, use events to decouple from your parents, delegate to your children and respect encapsulation, and make dependencies explicit. That’s it! This is not new nor ground breaking, but it should get you started on an happier path. Most of these principles are simply based on known best practices like SOLID principles or atomic design and none of this is web-specific. User interfaces have been around for ages and I think web developers should read more about the accumulated knowledge drawn from these years of experience.

The even better news is that it is fairly easy and fast to go from a humongous entangled to a structure of well defined and well behaved components. It is out of the scope of this article, but I might write about this at a later time. I will also show how to do it at my conference for Agile Québec on January 20th (in French). In the meantime, you can see a working example of this on my github repository. You will find 3 examples: one is a huge JavaScript file, one is a rewrite using React and the last one is a rewrite using only RequireJS.

Oh, also, here is one last bonus for you! You now have components that are trivial to test! Try it out, you might be amazed.