Planning your SCM strategy

Planning your SCM strategy

  December 18, 2018

We have been frequently asked by companies that are planning or are developing a software product about the common issues found trying to achieve a good production workflow, good teamwork and the security of properly handling the code base.
During our years of expertise we developed a strong vision about the most important tools that you need to use if you want to build software in a controlled way.
These tools encourage the implementation of a Software Configuration Management (SCM) strategy within your organization. In turn, this will have a great positive impact in many aspects, some of them technical, but also in many functional and workflow oriented ones.
Today most of software engineers take these tools for granted. But there are cases where companies with small development teams or organizational debts need some help figuring out these stuff. In that spirit we are writing an overview of this topic.
Most of the important problems that could come up are solved by properly installing, configuring and using this tools.
One key fact is that these tools are important regardless of the language or platform that you're using.

First step: Secure your code

You have invested a lot of resources in building your product and you have a few customers using it. The source code is the most important part of that product, so the first issue you have to consider is how to store your code in a secure manner while helping improve the way your team work together without conflicts.

The solution to this is using a Version Control Software. In the beginning there were many different options to choose from, but these days almost everyone is using Git. It's one of the most advanced tools for handling code for large teams and it's easy to find candidates with experience using it.

Of course there are others: SubVersion, Mercurial, Team Foundation Server, Bazaar, etc.

Second step: What about the packages?

It's almost impossible to find an organization that builds software without a VCS, but the same cannot be said about handling the binaries or artifacts that you create to distribute your software. Most engineers don't even know there are tools that can be used for this. And why should they consider using such a tool?

In order to answer this, first we need to think about what are the steps involved in writing software:

1. We begin by writing the code. You can use a minimal tool for doing this, like a simple notepad application, or you could use a heavy IDE with modern code generation techniques, but you almost always end up in tons of text files.
2. Then, depending on your platform you might need to compile the code into a binary or intermediate format. That is a process that takes a source code as an input, and produces binary files as the output. This step might not be required if you're using an interpreted language as Javascript or PHP. But even in those cases, there are usually a transpilation process that creates new forms of code optimized to run in different browsers, and environments.
3. Next you test the application in your local environment.
4. If everything is ok, and you're ready for the production deployment phase. This involves taking the artifact that you tested locally or in a test environment and placing it in the server that is going to expose your application.

To be completely sure that there are no problems with the generated artifact, the best is to always perform the build in a clean environment (we'll explain this later), and in order to avoid repeating this process unnecessarily, the best is to store it in a safe place. This is when the binary repository shows its strength. This tool will store the artifacts in an organized and reliable way so you can download them when you need to deploy, but also when you need to build another software based on a library, for example.

There are many options available: Nexus, Artifactory, Archiva, etc.

Final step: Continuous Integration

Having the source code and the produced artifacts in place is only the beginning. Automating the construction of the applications and libraries will give you many advantages:

• Having a clean and centralized place where the software is going to be built. Usually in many companies, the senior developer or the technical leader is the one that builds the artifacts that are going to production. But what if he or she forgets some work in progress or experiment, and then some unwanted behavior is accidentally introduced in the production ready artifact?
• The building pipeline can be triggered upon changes on the code. This can help in finding possible issues earlier, thus reducing time spent following up on them when found in production, and of course it finally produces better quality deliverables. 
• The building recipes can be standardized, so no wheels are going to be reinvented in that matter.
• You can control who triggers builds and deployments, and have logs about those actions. That at the end means better control of the changes that have some impact in important environments, such as staging, testing, etc.

There are many alternatives for this kind of software, but one of the most well known is Jenkins CI. This open source project stands out due to its very large and active community, a vast list of plugins and extensions, addressing almost all of the problems that can arise when configuring this important part of the SCM strategy.

But there are other good choices as well: TeamCity, Travis, Bamboo, etc.

Bonus track: Versioning scheme

But that is not all, you also need to define how to version your software and libraries, how to handle the release of your artifacts, how to manage dependencies, etc.

For that there are many tools, depending on the platform. For Java developers, Maven is almost a de facto standard, but you can also count with Gradle and Ivy. For .NET platform, you have NuGet, and for Javascript world, you have NPM, Bower and Yarn. All of them can be configured to be used with the binaries repositories, and the CI servers available.

Given the difficulty that can emerge when defining this process in your company, the best is to have the advice of experts.

We have years of experience in this subject, and helped many customers in defining and implementing their SCM strategy, so feel free to contact us and get more information.

See you all in the next post.

Vaadin Widgetset compiling: Tips & Hints

Vaadin Widgetset compiling: Tips & Hints

  February 09, 2018

Hi everyone!

The purpose of this post is enumerating the most common issues when trying to compile the widgetset in Vaadin. But before digging into this, let's explain a little bit what this compiling thing is about.

In Vaadin version 6, 7 & 8, the visual components have two important parts.

The first one is server side, and it's implemented in classic Java classes that are compiled to JVM bytecode.

The second part, on the other hand, is the client side code, written mostly in Java and then compiled in Javascript using GWT project. GWT is basically a Java to Javascript compiler. All of these components (widgets) belong to a set known as widgetset.

The widgetset compilation process is done by executing the GWT compiler to produce the Javascript code associated to all of the Vaadin components that have server and client side code.

That being said, let's go on with those tips!

Verify that everything is correctly configured

There are a lot of ways to compile the widgetset, in this case we will focus in projects that use maven as the build tool, because is the most commonly tool used for this purpose.

The vaadin-maven-plugin will help you on this process, which is a derivation of the gwt-maven-plugin.

Depending on the Vaadin version used, there a are a lot of different configurations, the best thing to do, is to create a small maven project, based on the simplest vaadin maven archetype (com.vaadin:vaadin-archetype-application)

These are the steps for doing this:

1. Run the command "mvn archetype:generate" from a terminal or command line window
2. Enter "vaadin" to filter the list of the available archetypes
3. Choose 5 (currently that's the number of the com.vaadin:vaadin-archetype-application archetype, it could change in the future)
4. Choose the number before the Vaadin version that you're using (ie: 127 -> 7.7.13, etc.)
5. Complete the parameters that maven will prompt

After that, maven will generate a small project, and if you take a look to the pom.xml file that was generated, you are going to find something like this:

...

 <build>
  <plugins>
...
   <plugin>
    <groupId>com.vaadin</groupId>
    <artifactId>vaadin-maven-plugin</artifactId>
    <version>${vaadin.plugin.version}</version>
    <executions>
     <execution>
      <goals>
       <goal>update-theme</goal>
       <goal>update-widgetset</goal>
       <goal>compile</goal>
       <!-- Comment out compile-theme goal to use on-the-fly theme compilation -->
       <goal>compile-theme</goal>
      </goals>
     </execution>
    </executions>
   </plugin>
...

You can copy the <plugin> definition to your pom.xml file. Take into account that the version is parametrized to use the vaadin.plugin.version maven variable, define it if you don't have it in your pom.xml file.

With this change, whenever you build your project, the vaadin-maven-plugin will try to compile the widgetset if needed.

Check that you have the Java sources of the addons available in your project

One thing that is usually unknown, is that maven needs the sources of the client side code of all of the addons (besides Vaadin itself) that are needed to generate the final widgetset. If you're using an addon (and you add it as a dependency), you have to be sure that the jar contains internally the Java files of the client side classes. If they are not there, the addon will not be included in the widgetset compilation and you are not going to see any error, but you will not be able to use it at runtime.

If you build a custom addon by yourself, to include the sources you have to add this into the <build/> section of your pom.xml file:

...

  <!-- This is needed for the sources required by the client-side compiler to be 
   included in the produced JARs -->
  <resources>
   <resource>
    <directory>src/main/java</directory>
    <excludes>
      <exclude>rebel.xml</exclude>
    </excludes>
   </resource>
   <resource>
    <directory>src/main/resources</directory>
   </resource>
  </resources>

...

Just package your project

If everything is correctly configured up to this point, you should be able to compile your widgetset as a part of the normal compilation phase of your project.

Just run the command mvn install and the compilation will be done correctly.

In the possible scenario that the compilation is not being executed, you could force it by clicking on the compile widgetset button of the Vaadin Eclipse Plugin, that will force it to happen.

Check if your addon was indeed compiled

If the compilation finishes without errors, is not exactly clear if a particular addon was included in the compilation or not. There are two ways of verifying that:

• The first one: analyzing the output of the build process, and trying to find a string similar to this:

...
[INFO] auto discovered modules [com.yourapplication.DemoWidgetSet]
[INFO] Compiling module com.yourapplication.DemoWidgetSet
[INFO]    Computing all possible rebind results for 'com.vaadin.client.metadata.ConnectorBundleLoader'
[INFO]       Rebinding com.vaadin.client.metadata.ConnectorBundleLoader
[INFO]          Invoking generator com.vaadin.server.widgetsetutils.ConnectorBundleLoaderFactory
[INFO]             Populating eager bundle
...
[INFO]                Visiting YourComponentConnector with ConnectorInitVisitor
[INFO]                   YourComponentConnector will be in the eager bundle
...

YourComponentConnector is the name of the Connector of your addon, if it includes one.

• Another possibility, is inspecting the generated widgetset and search for a string representing the name of a client side class that should be generated. That file usually resides in yourapplication\src\main\webapp\VAADIN\widgetsets\com.yourapplication.DemoWidgetSet, given that the name of your widgetset is "com.yourapplication.DemoWidgetSet". The file has a name pattern similar to this: "499F6D1A40C61E05F11FB78D20D50A78.cache.js" and usually is a big file (1 megabyte or so). For instance, you could search for a string with the name of your connector, it should be there, if not, probably there is a configuration problem.

Well, that's it, if you have more tips regarding this, feel free to share them!

Debugging GWT client side code in Vaadin with Eclipse

Debugging GWT client side code in Vaadin with Eclipse

  December 12, 2017

You know, if you're developing a Vaadin application, it is not necessary to understand how to code client side using GWT, unless you're building your own custom component, and you need to add some special client-side code. In that case, you are going to realize that whenever you want to test your component, debugging it can be tricky.

The problem is that client side code is not executed by the JVM, instead that code is going to be executed by the browser, and because of this all of the debugging facilities provided by the Java platform are useless.

Let me tell you what you need to take into account for being able to successfully debug your code.

1 - Modify your .gwt.xml file

The first thing you need to do is to modify the file that contains all of your widgetset information, by adding this line inside the tag <module/>:

    <set-configuration-property name="devModeRedirectEnabled" value="true" />

2 - Run your code server

This is a special process that will provide the browser with the source code of your client side code. There are a lot of ways of running this process, one way is to setup a new Eclipse Run Configuration (Run → Run configurations... → Java Application → New). There you'll have to provide your project's name and use com.google.gwt.dev.codeserver.CodeServer as the main class. As an argument you need to enter the fully qualified name of your widgetset. If your widgetset descriptor has a name "MyWidgetset.gwt.xml" and it's located in the java package: "com.myapplication", then the FQN will be: com.myapplication.MyWidgetset.
Another option would be to use Maven, as explained in the gwt-maven-plugin documentation site.
This process has to be up whenever you want to debug your code, so leave it running in the background.

3 - Optionally: install the Eclipse debugger for GWT SuperDevMode

This step is not necessary, but it will enable you to debug the client side code using Eclipse, which is better suited for that task than Chrome. You have to go to Help → Install New Software ..., and then enter this to the Work with dropdown list: http://sdbg.github.io/p2/
After that choose JavaScript Debugger with Source Mapping Support, and then install it. Probably you're going to need to restart your IDE.
To be completely sure that this step was performed correctly, just go to Run → Run Configurations ... and see if there is a Launch Chrome configuration.

4 - Run your application and enable SuperDevMode

Just run it normally, as you would do to debug server-side code. Just one important thing to take into account: Production Mode has to be disabled to be able to debug client side code. If you want to know a little bit more about this, you can check out the official documentation.
After the application is up-and-running, you have two options:

• Debug it using Chrome: you just need to open your application using that browser, and then use the Chrome Developer Tools
• Use Eclipse for debugging: Go to Run → Debug Configurations ... → Launch Chrome (provided by the Eclipse debugger for GWT SuperDevMode plugin we installed in the previous point), and create a new configuration, specifying the url and the associated project.

In either way, after the browser is showing the screen of your application you'll need to open Vaadin's Debug Window by adding ?debug at the end of your URL (if you're using Navigator, remember that the ?debug goes before the #view).
Then in the Debug Window select the little gear icon on the upper right section and then press on the black dot (enable SuperDevMode). That will launch the widgetset compilation process once again (be patient). One quick way of doing this, is to append ?debug=&superdevmode= instead of just ?debug at the end of your URL.

Client Side Debugging

And that's it! Whichever you're using Eclipse or Chrome, you are going to be able to put a breakpoint on your client-side code, and inspect the variables in there. If you're using Eclipse, just do it in the same way as if you were debugging server-side code; if you're using just Chrome, you'll need to open the Developer tools, and find the sources of your application in the Sources tab. You will find those under a folder with the FQN of your widgetset.

Please leave a comment if you have any trouble with this.

Happy debugging!