Ivan Matas

If you have ever used Ruby on Rails for app development, you’ve surely used some of the many generators that come out of the box, such as the controller generator, migration generator, model generator, etc.

Generators are an essential tool to improve your workflow and in this article I will walk you through the process of creating your very own generator.

We won’t create just any random generator but a Service Generator.

What are service objects and why use them?

All of you are already using service objects, right? If not, you probably should... seriously!

Service objects should be used to extract logic from controllers or models to keep them more readable and as slim as possible. They are great for keeping your code 

 and reusable. I won’t go into much details about them here, there are a lot of good articles on that topic.

Why wouldn’t we speed up our development and have a generator that does the boring job of creating the service skeleton, while we can focus on doing the fun stuff inside?

This is an example of how should a generated service look like:

class TestService
  def initialize
  end
  
  def call
  end
  
  private
  
  def method1
  end

  # .
  # .
  # .
  
  def methodN
  end
end

There are 2 ways to create custom generators: manually and with generators. Both will do the trick, but I will use a generator to generate a generator.

Yes, you read that correctly. Rails generators themselves have a generator. So to create a generator, we could type in the terminal:

$ bin/rails generate generator service
      create lib/generators/service
      create lib/generators/service/service_generator.rb
      create lib/generators/service/USAGE
      create lib/generators/service/templates
      invoke test_unit
      create test/lib/generators/service_generator_test.rb

For Rails to find generator files, without writing extra autoload paths, we should put them in the 

 directory. Because Rails is all about convention over configuration.

The command above will create a basic generator file:

class ServiceGenerator < Rails::Generators::NamedBase
     source_root File.expand_path('templates', __dir__)
end

The generator we are creating will inherit from 

 which basically means that our generator will expect at least the name argument to be sent. There are a lot more tricks and tips on creating generators so feel free to visit the related 

Before getting into the code, here is my thought process. I wanted to create a generator that accepts an optional argument (an array of method names) and an optional option (module name that will namespace the class). The service generator would then generate the correct service file with a basic template that includes the pre-populated empty methods, if given. As we should try to only have one public method, the additional methods will be private. To build the generator I used 

, a powerful toolkit for building command-line interfaces used by all Rails generators.

We use the built-in generator to create our own generator. The 

 file is the main file where we put our logic.

class ServiceGenerator < Rails::Generators::NamedBase
	source_root File.expand_path('../templates', __FILE__)

	argument :methods, type: :array, default: [], banner: "method method"
	class_option :module, type: :string

	def create_service_file
		@module_name = options[:module]

		service_dir_path = "app/services"
		generator_dir_path = service_dir_path + ("/#{@module_name.underscore}" if @module_name.present?).to_s
		generator_path = generator_dir_path + "/#{file_name}.rb"

		Dir.mkdir(service_dir_path) unless File.exist?(service_dir_path)
		Dir.mkdir(generator_dir_path) unless File.exist?(generator_dir_path)

		template "service.erb", generator_path
	end

end

source_root File.expand_path('../templates', __FILE__)

This method points to where our generator templates will be placed, and by default it points to the created directory 

argument :methods, type: :array, default: [], banner: "method method"
class_option :module, type: :string

Before we generate anything, we need to parse the command line arguments and options, if provided. That is done with the two methods provided above that come from 

 is used to parse command-line arguments into the 

 method is used to parse the command-line options and store them into the 

 variable will be used in the template to generate empty methods while the 

 variable will be used to namespace the generator if the 

We store module name, if given, inside the instance variable.

The services directory should, according to the documentation, be placed inside the 

 directory, and that’s why the service directory path is stated as 

service_dir_path = "app/services"
generator_dir_path = service_dir_path + ("/#{@module_name.underscore}" if @module_name.present?).to_s
generator_path = generator_dir_path + "/#{file_name}.rb"

We generate appropriate paths based on the module name, if present. The name of the service we want to generate is available for us to use in the class through the 

 variable that is accessible through the 

 class we inherit from. After all paths are generated, we can create directories if they don’t already exist. The 

 method is used to generate a file based on a template that we created in the path previously generated. More on this in the next step.

<% if @module_name.present? %> module <%= @module_name.camelize %>  <% end %>
class <%= class_name %>

def initialize
end

def call
end

<% if methods.present? %> private <% end %>
<% for method in methods %>
  def <%= method %>
  end
<% end %>
end
<% if @module_name.present? %> end <% end %>

 method for file creation in our service generator but I’ve used the 

 method because it is more flexible and it allows me to use the embedded Ruby file to dynamically change the file configuration based on user input. The file is a basic 

 file whose use case is to generate a class with 

 methods. If an additional option or argument is sent, then those changes are reflected in the file. Be sure to check the examples at the end.

Lastly, we want to add information to our USAGE file to make it easier for other users. Information added in the USAGE section will be visible when the 

 option is sent alongside the command. You can fill this file based on what type of generator you are creating. For this case, let's add the following information:

class TestService
  def initialize
  end
  
  def call
  end
end

rails g service test_service test_method1 test_method2

class TestService
  def initialize
  end
  
  def call
  end
  
  private
  
  def test_method1
  end
  
  def test_method2
  end
end

rails g service test_service --module test_module

module TestModule
  class TestService
    def initialize
    end

    def call
    end
  end
end

4. SERVICE WITH ADDITIONAL METHODS AND MODULE NAME

rails g service test_service method1 method2 --module test_module

module TestModule
  class TestService
    def initialize
    end

    def call
    end

    private

    def method1
    end

    def method2
    end
  end
end

I’ve created a gem based on this code. You can check it out on 

This is my first blog article and I am open for any questions, suggestions, remarks and anything else, just leave a comment below!

If you wish to get in touch with me, you can reach out to me via 

Generators are an essential tool to improve your workflow. In a few simple steps, we'll walk you through the process of creating your very own generator.

DIY – Create Your Own Rails Generator

Lea Metličić

All the best things come in fours – the leaves on a lucky clover, the Beatles members, and now our Best Employer awards. And just like the clover, they really are lucky! 

For the fourth year in a row, we are one of the best employers in Croatia,

 thanks to the answers from our team in the MojPosao questionnaire.

Out of our team of 60, the majority would recommend Ars Futura to their friends. Also, most of them find fulfillment and happiness in their day-to-day jobs. Specifically, 90% of our employees feel this way!

Here are a few more highlights we’d love to point out in this year’s stats.

Our connections and interpersonal relationships are shining through! 

The highest-scored questions are related to teamwork and friendships among coworkers, the support our team gets from their managers, and overall great working conditions.

Our team respects and trusts the people they’re surrounded by, cherishes collegiality, and thinks their teammates are ready to help. Clearly, the 

 are great and the office atmosphere is thriving. They also love teamwork! In Ars Futura, it really does make the dream work.

The second highlight are the relationships between team members and their managers who they perceive as caring, ready to help, supportive, and willing to grow from feedback.

All in all, it’s clear this award means a lot to us.

 It’s one of our most prized possessions, with a special place on our shelves and in our hearts.

This year, it even surprised us with a new look (as can be seen from our now out-dated illustration).

The results are an honest review from our team and a look back on the past year. The care we put into employee satisfaction is a huge effort, it takes a lot of time and thought.

Every year, we have to up our game, at least a little bit, to keep us growing and our team thriving. Also, every year, the competition gets a bit more fierce – and honestly, we love to see it.

So, it really is quite a joy to see that what we’re doing works, makes our team happy and that the love we give them is given back to us.

And to end on a high, here’s to another year of good luck, may it be the best one yet!

We’re popping the champagne, we’re counting our lucky stars, again!

Ars Futura is One of the Best Employers in 2023 – the Fourth Time in a Row

Luka Drezga

More than just a stream: Innovating the Esports Experience

With this blog, I'll try to spark conversation and imagination by discussing how we can innovate the Esports Experience.

Ars Futura is a digital design and development agency that, amongst other industries, does a lot of Esports work. We're super proud to say that we're an official partner of Activision Blizzard Esports, building everything digital from design to development on their flagship products. We've enjoyed working with other big names, like Halo Championship Series, Vindex, Esports Engine, Belong, etc. 

But we’re not discussing Ars Futura,  we’re here to see how we can innovate the Esports Experience and bring it to the next level. Before we jump to that, let’s talk about the love-and-hate relationship between Esports and sports.

When we're looking at Esports, we still see a lot of sports influence, which is fine. Esports is a sport of sorts. It relies on teams and players, the matches and leagues, and the crowd that follows everything. But, there are a lot of crucial differences that we need to take into account. 

Esports is played in both the live and the digital environment, whereas traditional sports are only live. Esports has a global audience, doesn't care about geographical boundaries, and is more accessible. You don't need cable TV, and you have no channel restrictions. The only thing required is a computer or console.

The second key thing we must understand is the difference between Esports and Traditional Sports fans. 

The average age of an NFL fan is 47; for hockey, it's 50; for baseball, it's 57. At the same time, an average Esports fan is around 26. This is a gap of almost 30 years.

Esports fans are digital natives. They were born in the late 90s and have grown up surrounded by technology. They're tech-savvy and early adopters compared to their boomer sports counterparts.

Esports fans are versatile, following multiple games and genres, leagues, and teams. Their loyalty isn't to a team that's grown in their hometown. They follow and cheer for different players all across the globe, and they usually follow more than one team.

This is where the traditional Esports Experience is lacking. While having a good old regular live stream, VOD, standings, schedule, and others is a must-have, the industry is evolving rapidly, prompting a need for innovation.

We must offer these tech-savvy, hungry beasts something more than just watching.

Beyond Passive Viewing: The Future is Fan Interaction

This is why I believe that with this desire for active participation, immersion, and control, the future of Esports should prioritize increased fan interaction through innovative digital products that foster stronger communities. Now, there are a million different things that we, as Esports builders, can entertain. I'll try to focus on a couple of feasible options that can be accomplished in the foreseeable future.

The Rise of Fantasy - Interactive Fantasy Leagues

One of the first things that jump to mind are Fantasy Leagues and Pick 'em experiences. By providing these digital solutions for fans in pre-, live, and post-match states, we involve them in the game even more. By making predictions and building fantasy teams, you, as an Esports fan, are investing yourself more than before. Doing this live, you witness your imaginary team's and your pick's success parallel to the main event, bridging the gap between the actual game and the fantasy world through an adrenaline-fueled experience. 

Continuing the previous topic about empowering viewers and enhancing the interaction with the game, there is much to be said about the viewer experience. 

As an Esports fan, I sit on my couch and look at this directed live stream on Twitch or YouTube, see what the producers show, and hear what the casters say. Why not take it a step further and allow the viewers to choose player perspectives and switch between streams in real-time, self-direct their viewing experience, and take a first-person look at what their favorite player is doing. Let's take it another step further and let fans tap into the comms of their favorite teams. Let them listen in on team chats, gaining insight into the communication and strategies of a particular team. 

These innovations add a new layer of immersion, proximity to the action, and understanding of the game. Redefining how fans interact with esports content, making it more engaging and informative. Viewer empowerment is at the forefront of esports innovation, offering fans unprecedented control and insight.

Going into GOD MODE - Immersive 3D Perspective

Another layer of viewer empowerment worth mentioning is the 3D space of a map — a feature-rich user interface that enhances immersion. Imagine dropping in Inferno and witnessing the action first-hand from the first-person experience. Being able to jump between all the players on the map and seeing their POV. There are significant advances in this tech done by platforms like Virtex Stadium and Skybox.gg.

Now we've covered a bit about the viewing experience, adding pick 'em and fantasy, allowing fans more control over their content, etc. Let's see how we can engage them even more.

We're all well familiar with Battle Passes, achievements, and challenges. We've seen this all throughout gaming, but this powerful tool has yet to peak in Esports. We can incentivize viewers to interact more with esports content, competitions, and communities through gamification. Give them more opportunities to return and spend time on our websites and apps. One of the cool things we did with CDL and World Series of Warzone is that we've created these interactive components that can be set up with every stream or VOD that would reward users for consuming content on our websites. The more videos you've watched, the better the rewards will become. CDL Pick 'em introduced challenges and rewards to their fans; the more picks you made and the better they'd be, you'd gain achievements and win prizes. The prizes would range from discounts on shops with CDL partners to in-game rewards like skins, double XP days, etc. This type of mechanic significantly boosted the user's engagement on the website. They spent more time there and submitted more picks than in the prior seasons.

Medals of Honor - Exclusive Event Engagement

There is this thing called FOMO, and a lot of us are suffering from it. And boy, oh boy, is it a powerful engagement driver. Last year, we developed a feature for the OWL mobile app that is basically a scavenger hunt; you'd have these QR codes spread throughout the Anaheim arena and shown on live streams. Each QR code awarded something different, from fan-designed assets to in-game skins and OWL Tokens. If you collect all rewards, you'll win a golden perk!

The results from just this one event are mind-blowing. The adoption rate for this feature was an astonishing 80%, meaning that 80% of the people who were a part of the OWL 2022 finals updated or installed the app and used this feature. It only took 2 months to design and develop it, and now it's used on events all across the globe.

Creating these one-of-a-kind promotions, unique items, and offers exclusive to specific events contributes to a sense of community and fan loyalty.

Decision Making - Interactive Fan Involvement

Lastly, something we're seeing on the rise just now is empowering fans and viewers to participate in the decision-making on a creator's stream or even with the gameplay. We're seeing more and more people using platforms like Epic Games' Unreal Editor for Fortnite (UEFN) or Roblox, where creators get to shape and build new experiences. I see that opening up APIs for these games and allowing people to participate in the game itself is the next step in this process. Imagine you're playing a Battle Royal game, and fans watching your stream get to decide what will be a part of your next drop. Incredible creator fan immersion. While this might not directly apply to Esports, something similar can be introduced in streams to tailor content per fan's wishes. Imagine watching a stream, but you decide what match gets broadcast or who gets interviewed in the break. It's all about fan empowerment.

In conclusion, the future of innovating the Esports experience is an exciting journey. The Esports industry is distinct from traditional sports in various ways, especially its digital-savvy and diverse fan base. To harness the full potential of this unique audience, we must evolve the Esports experience beyond passive viewing.

By embracing these innovations, we can elevate the Esports experience, making it more engaging, interactive, and tailored to individual fan preferences. This, in turn, promises to further solidify the bond between Esports fans and the games they love. The future of Esports is not just about watching; it's about actively participating, immersing, and empowering fans to be an integral part of the Esports ecosystem. 

Let's innovate and elevate the Esports experience together!

This blog was created from a keynote talk and presentation at ESI 2023, the world’s biggest esports and games festival.

The future of esports engagement.

More Than Just a Stream: Innovating the Esports Experience

Josip Kvaternik

Web and Mobile Automation Inside CI Environments

I’m back with another blog post (please, hold the applause  

 ). This time, I’m writing about the integration process of your mobile and web automation projects with a continuous integration cloud provider, creating a CI environment, and connecting it with Slack. I’ll cover more than just the CI, pipeline automation, cloud provider, or Slack integration, so stay tuned.

This blog is an addition to my first one, where I covered 

the basics of Cucumber BDD with Selenium and Java

. If you still haven’t read it, I strongly advise you to, and not just because I wrote it, but because you’ll understand this one much better. 

I think the quality of my jokes has decreased by 20% since my last blog post, so without further ado, let’s CI what I prepared for this one (get it?).

I’ll start by talking about the meaning and benefits of a Continuous Integration environment. 

Continuous integration (CI) is a practice that involves software developers making small changes and checks to their code. Due to the scale of requirements and the number of steps involved, this process is automated. This is to ensure that teams can build, test, and package their applications in a reliable and repeatable way. This is what Mr. Google would say if you were to search “What is CI?”. Google is a bit formal so I’ll put it in my own words: “It is what it is” (

Let’s say you have your mobile automation test that tests login functionality for your high-end iOS application. If you were to check your login functionality, you’d have to trigger and set everything up manually (probably every day). If you integrate that project inside a CI environment, you wouldn’t have to worry about that, your tests would trigger, run, and report feedback automatically, as easy as that. When you think about it, even the name says it, Continuous Integration.

There are many continuous integration tools DevOps and people in software development  use today. From 

. In this blog, I’ll cover GitHub Actions. I find it very similar to Gitlab CI, but I’ll cover GitHub since the project from my first blog post is already on GitHub. However, if anybody asks, I prefer Gitlab CI for my test automation.

GitHub Actions is a continuous integration and continuous deployment (delivery) (CI/CD) platform that automates your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to environments. In our case, GitHub Actions will be used to build and run our tests on a predefined schedule. 

GitHub actions provide Linux, Windows, or MacOS machines for workflow runs. We’ll use MacOS. 

Let’s talk about security. GitHub actions provide many security features, such as GitHub secrets. GitHub secrets are encrypted variables you can create in your repository environment. What does it mean? I don’t know (joking). It means you can keep any variable you want private, encrypted, and under a password. That variable can be anything, an environment password or something as simple as a String. A real-life scenario would be to keep your environment access ID and password secret. Here we won’t have that, so I’ll create a GitHub Secret for our Slack webhook, but more about that later.

As bad as the name might be, CI Testing Cloud Providers says it all. The Cloud testing service providers provide an essential testing environment as per application under test requirements. As previously mentioned, the essential environment can be a web browser on a desktop or mobile device. Let’s not forget Android and iOS applications on their respective platforms. That device is usually run on a VM (Virtual Machine) that gets killed after each test which makes the continuous integration tests reliable and less fragile.

This goes without saying, Testing Cloud Providers offer a lot more than just desktop and mobile services. Depending on the provider, some other functionalities are:

These are just some of the many Testing Clouds offers. By now, it’s pretty clear why automated testers use them. 

It’s time to mention some of the most reliable cloud providers currently on the market. I’ll start with SauceLabs and BrowserStack. They’re pretty similar and both offer many functionalities. There’s also SonarCloud, Testsigma, CloudQA and many more. 

In this blog, I’ll cover my favorite and most frequently used cloud provider, SauceLabs.

Okay, let’s talk Sauce. We have sour cream, sweet and sour cream, grilling sauce… No, wait, wrong chat…

Jokes aside, SauceLabs, in my opinion, is the best Testing Cloud provider on the market. It provides all the mentioned functionalities, has great documentation, and works on new integrations and services. SauceLabs service comes at a certain price, but if you’re working on a serious automation project, you should consider it. If you don’t prefer Sauces, perhaps try BrowserStack next.

Additionally, I'll integrate my local project to run on the SauceLabs cloud. What does that mean? Well, it means that once I click run on my local machine, the browser won’t start locally. The browser will start on the SauceLabs cloud on a newly born VM, record video playback, output the console log, run the test, and finally, kill the VM. What more could you ask for! 

Before we start, I’ll cover my project structure and technologies. 

So what does this tell us? Let’s break it down.

We have a local test automation project. In my case, the project is the same as in my first blog post. If you haven’t read it yet, now might be the time. Throughout this blog, we’ll cover everything else seen in the image.

I’ll connect my local project to SauceLabs which means my tests won’t run locally anymore. The tests will run on the SauceLabs cloud, as I explained earlier. SauceLabs cloud will provide live video playback, video reproduction, and console log output. Awesome.

Now let’s talk about GitHub. As can be seen in the image, GitHub does quite a lot of heavy lifting. I’ll create a workflow file that will trigger our tests to run on SauceLabs and put it on a schedule. Also, since I’m using Gradle and cucumber in my local project, GitHub itself will give us Gradle and cucumber console output. Finally, through the GitHub workflow file, I’ll create a connection to Slack so I can see notifications (pass/fail) immediately after the automated tests finish running. As you can see, when this is finished, you can relax and let your tests run for you. 

I believe that’s everything. Let’s start coding! 

So, my local project is Selenium with Cucumber and Java. Once we add the SauceLabs integration, our Driver (Hooks) Java class will look like this:

public class Hooks {
   public static RemoteWebDriver driver;
   public static WebDriverWait wait;
   public Config config;

   @Before
   public void setup(Scenario scenario) throws IOException {

       config = new Config();
       String browserName = config.getBrowser();
       String username = System.getenv("your sauce username");
       String accessKey = System.getenv("your sauce access key");
       String sauceUrl = "https://username:accesskey@ondemand.region.saucelabs.com:443/wd/hub";
       MutableCapabilities capabilities;
       MutableCapabilities sauceOpts = new MutableCapabilities();

       switch (browserName) {

           case "chrome":
               capabilities = new ChromeOptions();
               capabilities.setCapability("browserName", browserName);
               capabilities.setCapability("browserVersion", "latest");
               capabilities.setCapability("platformName", "Windows 10");
               sauceOpts.setCapability("username", username);
               sauceOpts.setCapability("accessKey", accessKey);
               sauceOpts.setCapability("name", "CHROME TEST" + scenario.getName());
               sauceOpts.setCapability("screenResolution" , "1920x1080");
               capabilities.setCapability("sauce:options", sauceOpts);
               URL url = new URL(sauceUrl);
               driver = new RemoteWebDriver(url, capabilities);
               wait = new WebDriverWait(driver, Duration.ofSeconds(70));
               break;


           case "safari":
               capabilities = new SafariOptions();
               capabilities.setCapability("browserName", browserName);
               capabilities.setCapability("browserVersion", "14");
               capabilities.setCapability("platformName", "macOS 11");
               sauceOpts.setCapability("username", username);
               sauceOpts.setCapability("accessKey", accessKey);
               sauceOpts.setCapability("name", "SAFARI TEST: " + scenario.getName());
               sauceOpts.setCapability("screenResolution", "1600x1200");
               capabilities.setCapability("sauce:options", sauceOpts);
               url = new URL(sauceUrl);
               driver = new RemoteWebDriver(url, capabilities);
               wait = new WebDriverWait(driver, Duration.ofSeconds(70));
               break;

           case "chromeMac":
               capabilities = new ChromeOptions();
               capabilities.setCapability("browserName", "chrome");
               capabilities.setCapability("browserVersion", "latest");
               capabilities.setCapability("platformName", "macOS 12");
               sauceOpts.setCapability("username", username);
               sauceOpts.setCapability("accessKey", accessKey);
               sauceOpts.setCapability("name","CHROME MAC TEST: " + scenario.getName());
               sauceOpts.setCapability("screenResolution" , "1600x1200");
               capabilities.setCapability("sauce:options", sauceOpts);
               url = new URL(sauceUrl);
               driver = new RemoteWebDriver(url, capabilities);
               wait = new WebDriverWait(driver, Duration.ofSeconds(70));
               break;

           default:
               capabilities = new ChromeOptions();
               capabilities.setCapability("browserName", browserName);
               capabilities.setCapability("browserVersion", "latest");
               capabilities.setCapability("platformName", "Windows 10");
               sauceOpts.setCapability("username", username);
               sauceOpts.setCapability("accessKey", accessKey);
               sauceOpts.setCapability("name", "CHROME TEST: " + scenario.getName());
               sauceOpts.setCapability("screenResolution" , "1920x1080");
               capabilities.setCapability("sauce:options", sauceOpts);
               url = new URL(sauceUrl);
               driver = new RemoteWebDriver(url, capabilities);
               wait = new WebDriverWait(driver, Duration.ofSeconds(70));
               break;
       }
   }

  @After
   public void teardown (){
       driver.quit();
   }


   @AfterStep
   public void afterStep (Scenario scenario) {

       if(scenario.isFailed()){
           driver.executeScript("sauce:job-result=" + false);
       }
       else driver.executeScript("sauce:job-result=" + true);}

}

Okay, this is a lot of code at once so I’ll break everything down. 

Roughly speaking, my Hooks class is mostly about creating a driver for SauceLabs. The driver will no longer be WebDriver, it will be RemoteWebDriver because we’re connecting to remote (SauceLabs cloud) via URL. The URL consists of your SauceLabs username, access key, and region. In my example, those values are hidden for security reasons. 

I’m using Cucumber’s “Before” and “After” hooks. All the code inside the Before hook will execute before running test scenarios. Finally, the code inside the After hook will execute at the end of running test scenarios. We want our Sauce connection established before running our scenarios, so I put them inside the Before hook. 

After the run of test scenarios, we want to finish the test and kill the driver, so that it’s inside the After hook. 

The AfterStep hook is also provided by Cucumber. This hook is very important. In this hook, we have a simple “if” loop that puts scenario results to pass or fail. This is possible because Cucumber can give us results after each step, so we just add a driver script for SauceLabs, and 

SauceLabs capabilities are pretty self-explanatory, so I won’t go into detail. We set scenario names, browser names, browser versions, platform versions, resolutions, and so on. 

In the beginning, I initialized the Config class. What is it? Config is another Java class I’ve created for navigating between browsers. Why? Well, because when my automated tests run on a schedule, they test all the browsers needed. How did I create this? Well, I did it my way. There are a lot of possibilities, but I’ll show you mine. 

To switch between browsers you have to create a file where you’ll write properties, in our case, the browser name. So, I’ve created a file in the root of my project and named it 

Finally, I’ve created a new Java class called, you guessed it, 

import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;

public class Config{

   public  Properties properties;

   public Config() {
       properties = new Properties();
       try {
           FileInputStream inputStream = new FileInputStream("gradle.properties");
           properties.load(inputStream);
       } catch (IOException e) {
           e.printStackTrace();
       }
   }
   public  String getBrowser() {
       return properties.getProperty("browser");
   }
}

As you can see, this class is simple and effective. I used the FileInputStream method pointed at a previously created 

file. Also, I’ve created a dynamic String method called 

which will get a “browser” value from 

file will remain empty because we don’t want to run our tests locally, therefore, we’ll write browser values using the Gradle task. More on that later on.

As shown in my first blog post (see, you should’ve read it by now), I’m using the Gradle task for running my tests. Why? Well, because it is pretty easy to implement inside a CI/CD environment (I can run tests just by using a single CLI command). Now, let me show you how I write browser properties before running my tests. My Gradle task for running tests on Safari looks something like this:

task runTestsSafari (type: WriteProperties) {
   outputFile = file('gradle.properties')
   property 'browser', 'safari'
   dependsOn assemble, testClasses
   doLast {
       javaexec {
           main = "io.cucumber.core.cli.Main"
           classpath = configurations.cucumberRuntime + sourceSets.main.output + sourceSets.test.output
           args = [
                   '--plugin', 'pretty',
                   '--plugin', 'html:target/cucumber-report.html',
                   '--glue', 'stepMethods',
                   'src/test/resourcesSafari']
       }
   }
}

The task type is set to WriteProperties because, well, you know why. We need to write the property and value of “browser”. So, the first block of code will write “browser=safari” inside our 

file. With that, our Hooks class will enter our switch loop and select “case = safari”. Now, all I have to do is create as many tasks as I want for as many browsers and platforms as needed. 

Let's get to the part we’ve all been waiting for. I’ll show you how to configure the GitHub workflow file. First and foremost, I’ll upload my project to GitHub. Once that’s done, I’ll create a new folder in the root of my project called 

name: Java CI

on:
 schedule:
   - cron: '45 9 * * 1-5'

jobs:
 build:
   runs-on: ubuntu-latest

   steps:
     - uses: actions/checkout@v3
     - name: Set up JDK 17
       uses: actions/setup-java@v3
       with:
         java-version: '17'
         distribution: 'adopt'
     - name: Validate Gradle wrapper
       uses: gradle/wrapper-validation-action@e6e38bacfdf1a337459f332974bb2327a31aaf4b

- name: Build with Gradle
 uses: gradle/gradle-build-action@0d13054264b0bb894ded474f08ebb30921341cee
 with:
   arguments: runTestsSafari

Let’s break it down. In the first line, I just gave my workflow a basic name, Java CI. The following lines show I’ve put this workflow on a cron schedule. For more information about cron syntax, visit 

. My schedule is set every day from Monday till Friday at 9:45 AM. Be careful with time zones because GitHub uses UTC. I give my pipeline a job (build) and set it to run on the latest Ubuntu. Under steps, I’ve put some formal Java technologies and versions for my pipeline to use. After validating the Gradle wrapper, we can finally start building with Gradle and run our task. Set like this, my tests run daily at 9:45 and test Safari. At this point, I can see the Gradle and Cucumber output provided by GitHub, and I can see my test video playback on SauceLabs. Well, that’s not enough for me, I’m lazier than that. Let’s connect everything with Slack so I’m instantly notified if my tests have passed or failed.

To connect your GitHub project with Slack I’ll use a certain runner. I’ve tried many different runners provided by different organizations, but I only liked one. The runner I’m using is provided by rtCamp and can be found 

file, we need to do a couple of things. Firstly, we need to add an incoming Webhook connection to our Slack workspace. You can see more details 

. I can’t provide much information about this step because it’s mostly related to my organization’s Slack. Please check the link, it should be simple. When you’re finished creating your Webhook, copy it.

Next, open GitHub and click on secrets. We need to create a new secret on GitHub. So, we click to create a new secret and name it, in my case, SLACK_WEBHOOK_URL. Paste the copied value of your webhook in the previous step. After saving, GitHub will encrypt our webhook and keep it, you guessed it, a secret. 

- name: Send success
 if: success()
 uses: rtCamp/action-slack-notify@v2
 env:
   SLACK_CHANNEL: automated-tests-notifications
   SLACK_LINK_NAMES: true
   SLACK_COLOR: ${{ job.status }}
   SLACK_ICON: https://github.com/rtCamp.png?size=48
   SLACK_TITLE: Your tests have successfully passed
   SLACK_USERNAME: roBot
   SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL}}

- name: Send failure
 if: failure()
 uses: rtCamp/action-slack-notify@v2
 env:
   SLACK_CHANNEL: automated-tests-notifications
   SLACK_LINK_NAMES: true
   SLACK_COLOR: ${{ job.status }}
   SLACK_ICON: https://github.com/rtCamp.png?size=48
   SLACK_TITLE: Danger, danger, automated tests have failed
   SLACK_USERNAME: roBot
   SLACK_WEBHOOK: ${{ secrets.SLACK_WEBHOOK_URL}}

This may seem pretty self-explanatory, but I’ve had many issues with the connection between GitHub Actions and Slack. What I’m saying is, try your best to use this as similar as I did, because even the smallest adjustments can break it. 

As you can see, I’ve created two ifs. Both ifs act on the output of our Gradle runner. Now we’re getting to the best part of Gradle. Let’s not forget, our tests are running using the Gradle tasks. So, when the Gradle task finishes running, it creates an output that can also be read by our 

file. It’s simple, but it took me a while to realize just how powerful and helpful that is. Moving on, now our 

file knows which if loop to enter based on our test results. NICE! 

As you can see, SLACK_WEBHOOK is also present here. We can get any encrypted value (secret) from our GitHub secrets using this syntax; ${{secrets.YOUR_SECRET_NAME}} 

Knowing that we can use GitHub secrets to hide any sensitive information. I’ll let you try that yourself. 

This was yet another quick explanation of how to connect all our technologies to work together as one big great machine. 

Hopefully, this blog will help you in your daily struggles with web or mobile automation inside continuous integration environments and provide you with some new scalability, experiences and information. In my own experience, setting web/mobile automation inside a continuous integration environment was the pinnacle of many projects I worked on.

As I said, this blog is a bit more advanced than my previous one. I’m going to say it right away, I’ll be back with part three. Then I’ll explain more advanced and specific technologies. Not gonna lie, I did withhold some information in this one, but with a good purpose – I didn’t want to make the blog too long or complicated.

Check out the amazing features the continuous integration environment has to offer.

Roza Zanini Mozara

Ars Futura Redesign

Hello from the same, but different Ars Futura! 

 As you can see, we have some exciting news to share – our brand has had a huge redesign!

After a decade of making our mark, it was time for a refresh. Our old logo served us well, but we wanted to fill in the gaps and tidy up a few things. For instance, we never had a logomark or really defined design principles (until now!), and let’s be honest – our old merch has been looking outdated for quite some time now. 

At the end of 2020, we said “Hey, it’s about time we got ourselves a new look” and since then, it’s been quite a journey! 

To kick it off,  we sought out some help and landed on Studio Size as the perfect choice. So, to set the stage for the redesign, we answered a lot of questions, shared some dos and don'ts, and came up with a few ideas, until the vision started taking shape. After a few rounds of suggestions and feedback, we found the 

 that felt just right, and that you can see today! 

One of the key inspirations that helped shape our new design was the concept of retrofuturism. Think blending the fun from the 70s and 80s with the idea of flying cars, and you’re on the right track! The theme resonates with our visual identity and our new tagline: 

(we hope you’re ready to see it everywhere from now on because you just might 

It’s important to add that through all these changes, one thing remains the same – our core values. Yes, we’ve given them a bit of a re-vamp of their own, but we’re still committed to 

Once we’ve nailed down all the important things: our new logo, logomark, tagline, colors 

(fun fact: we chose purple because it was the first Ars Futura color, going back to the roots and stuff, you get it)

... the real fun began! We were set to design and develop our new website, think of new merch ideas and bring them to life, give our office a bit of a makeover, etc. Now, after months and months of hard work and creative brainstorming, we’re proud and happy to reveal our new brand design to the world. 

We hope you’ll love it as much as we do.

We say a
lot about...
everything

Popular Articles

We say alot about...everything

Popular Articles

We say a
lot about...
everything