Fagdag with Kraftlauget

We had an amazing time at "fagdag" with Kraftlauget which was a great forum for knowledge sharing! Our friends at Kraftlauget held a session on Svelte and also arranged an interactive competition to see which team could best optimize a DevOps pipeline using GitHub actions. Our team members Stein Børre and Eugene contributed to the learning seminar too.

 

Stein Børre Granmar talked about our experience pilot testing Virtuoso, a test automation tool with self-healing capabilities.

Test automation is the practice of automatically reviewing and validating a software product, such as a web application, to make sure it meets predefined quality standards for code style, functionality (business logic), and user experience. At Instech we utilise DevOps where it is best practice to run automated tests as early and as often as possible within the CI/CD (continuous integration and continuous delivery) pipeline. Even though automation tools have existed for over a decade, many require coding skills and often result in flaky, brittle tests that are extremely costly to troubleshoot and maintain at scale.

Some of the benefits to Virtuoso that we discovered:

  • Easy to use, even for non-technical team members

  • Provides real-time quantitative insights

  • Offers satisfactory support through webinars, documentation, etc.

  • Supports cross-platform compatibility testing

  • Can meet custom requirements

  • Can be used for API integration tests and/or include API calls in test cases

  • Can be easily integrated into a CI/CD pipeline

  • Integrates with Slack and TestRail

Some of the downsides to Virtuoso:

  • Live authoring always starts from the beginning of a journey (a series of features tested in an end-to-end flow)

  • Cost per journey execution, which may lead to very large journeys that can be more difficult to maintain than smaller journeys

  • No conditions (e.g. “If button A is not there, click on button B”)

  • Hard to make journeys robust on all platforms

  • No integration with Atlassian’s Jira software

For Instech, the benefits outweighed the downsides. We are pleased with the pilot test and will continue to use Virtuoso.

 

Eugene Rebedailo showcased his multiplayer browser-based card game powered entirely by .NET with the help of Blazor & WebAssembly.

JavaScript has been the most used programming language in the world for 9 consecutive years. Despite JavaScripts’ immense popularity, there are luckily a few alternatives like Web Assembly and Blazor. Web Assembly enables you to run native code written in a language of your choosing in a browser without having to utilise JavaScript; Blazor being the .NET implementation of this technology.

Some identifiable positives:

  • Exciting tech which opens opportunities for back-end developers trying their hand on front-end development

  • Good in scenarios where there is tight integration with back-end as it enables the developer to reuse a great deal of code sitting on the boundaries of the solution

  • Ability to use familiar tooling and development libraries

  • Not having to use the universally loved JavaScript 🙂

A few points where Blazor fell short:

  • The troubleshooting and debugging experience was not optimal due to the relative immaturity of the platform

  • It’s probably not feasible for mobile-first due to the relatively large download size, but could work well with a progressive web app

  • While it promises near native execution speeds, there are many scenarios where JavaScript outperforms Blazor

  • There are still cases where one has to resort to writing plain JavaScript, especially when trying to interact with external libraries

When Eugene demonstrated the final product, he pointed out that the entire game had only 7 lines of JavaScript code (pertaining to authentication). This is quite impressive for a single-page application heavily focused on front-end logic. While probably not viable for most projects, it is possible for a back-end developer to build a front-end application without too much difficulty, although some changes in development mentality would have to be adopted.

Previous
Previous

INS+ User Meeting 2022

Next
Next

MDM Pattern: working with a legacy master database