Sprachsteuerung mit dem Google Assistant – Add a new User Interface to your P...inovex GmbH
„Computer, Tee, Earl Grey, heiß“ Jeder Star-Trek-Fan wird dieses Zitat kennen, mit dem Capt. Picard sich regelmäßig sein Lieblingsgetränk replizieren lässt. Die Sprachsteuerung von Computern und Maschinen ist fester Bestandteil vieler Science-Fiction-Szenarien. Daher ist es auch nicht verwunderlich, dass schon mehrere Versuche unternommen wurden, diese Technologie zu etablieren, mit eher durchschnittlichem Erfolg. Allerdings deutet sich aktuell ein großer Fortschritt in der Entwicklung von Sprachsteuerungen an, die sich am deutlichsten in der Inkarnation von Geräten wie Amazon Echo oder Google Home darstellt. In der Session zeigen wir die prinzipielle Funktionsweise einer Sprachsteuerung, die Vergleichbarkeit mit Chatbots, und erweitern einen bestehenden Dienst um ein Voice-User-Interface. Dabei zeigen sich die Besonderheit dieser Benutzerschnittstelle im Vergleich zu grafischen Interfaces und die Herausforderungen, die damit verbunden sind.
Event: MobileTech Conference 2017
Datum: 15.03.2017
Speaker: Dominik Helleberg, inovex GmbH
Weitere Tech-Vorträge unter https://www.inovex.de/de/content-pool/vortraege/
Google has developed the programming language called Go. Go is a freedom-respecting and open source programming language and it is designed by Robert Griesemer, Rob Pike, and Ken Thompson in the year 2007. Go language was released in 2009. The syntax of the Go language resembles the C programming language and Go language is a statically typed programming language which is often called golang. Go language is detailed understood by golang online course.
Sprachsteuerung mit dem Google Assistant – Add a new User Interface to your P...inovex GmbH
„Computer, Tee, Earl Grey, heiß“ Jeder Star-Trek-Fan wird dieses Zitat kennen, mit dem Capt. Picard sich regelmäßig sein Lieblingsgetränk replizieren lässt. Die Sprachsteuerung von Computern und Maschinen ist fester Bestandteil vieler Science-Fiction-Szenarien. Daher ist es auch nicht verwunderlich, dass schon mehrere Versuche unternommen wurden, diese Technologie zu etablieren, mit eher durchschnittlichem Erfolg. Allerdings deutet sich aktuell ein großer Fortschritt in der Entwicklung von Sprachsteuerungen an, die sich am deutlichsten in der Inkarnation von Geräten wie Amazon Echo oder Google Home darstellt. In der Session zeigen wir die prinzipielle Funktionsweise einer Sprachsteuerung, die Vergleichbarkeit mit Chatbots, und erweitern einen bestehenden Dienst um ein Voice-User-Interface. Dabei zeigen sich die Besonderheit dieser Benutzerschnittstelle im Vergleich zu grafischen Interfaces und die Herausforderungen, die damit verbunden sind.
Event: MobileTech Conference 2017
Datum: 15.03.2017
Speaker: Dominik Helleberg, inovex GmbH
Weitere Tech-Vorträge unter https://www.inovex.de/de/content-pool/vortraege/
Google has developed the programming language called Go. Go is a freedom-respecting and open source programming language and it is designed by Robert Griesemer, Rob Pike, and Ken Thompson in the year 2007. Go language was released in 2009. The syntax of the Go language resembles the C programming language and Go language is a statically typed programming language which is often called golang. Go language is detailed understood by golang online course.
We will learn how to create repository, pushing, cloning and creating branches. Additionally we will talk about various workflows that are used by teams while collaborating in a project.
Building A Distributed Build System at Google Scale (StrangeLoop 2016)Aysylu Greenberg
It's hard to imagine a modern developer workflow without a sufficiently advanced build system: Make, Gradle, Maven, Rake, and many others. In this talk, we'll discuss the evolution of build systems that leads to distributed build systems. Then, we'll dive into how we can build a scalable system that is fast and resilient, with examples from Google. We'll conclude with the discussion of general challenges of migrating systems from one architecture to another.
Stuart Fettinger's 6/13/2019 Chicago Microservices Meetup Presentation -
Title: Hurry Up and GO (But Not Too Fast)
Like all programming languages, GoLang can be great in some situations - not so great in others. We weigh GO against other frameworks, focusing on real-world examples to highlight benefits and common challenges. Plus, we explore how to architect and design efficient GO applications from the start, so you can limit your long-term technical debt.
The goal for this presentation is to cover the following:
- When you should and should not use GO
- Pros and cons of the language compared to others
- Efficient architecture and design, focusing on reuse and service patterns
Writing the code is just one part of being a productive dev team.
In this talk, we'll go through what happens after the code is written, ensuring we can version, test, deploy and monitor our software.
Best practices with git - The essentials you should know about git to use if efficiently
Workshop by Otto Kekäläinen at OpenFest 7.11.2015, Sofia, Bulagaria.
This 68 slides beast surely has something new even for seasoned git developers!
FLOW3 spearheaded a move towards Git adoption within the TYPO3 project, and we are more pleased every day with the decision to turn away from Subversion and toward GIt.
In this session I explain the workflow we adopted using Git and the code review system Gerrit. I will show how it makes collaborative development more productive and improves code quality at the same time.
We will learn how to create repository, pushing, cloning and creating branches. Additionally we will talk about various workflows that are used by teams while collaborating in a project.
Building A Distributed Build System at Google Scale (StrangeLoop 2016)Aysylu Greenberg
It's hard to imagine a modern developer workflow without a sufficiently advanced build system: Make, Gradle, Maven, Rake, and many others. In this talk, we'll discuss the evolution of build systems that leads to distributed build systems. Then, we'll dive into how we can build a scalable system that is fast and resilient, with examples from Google. We'll conclude with the discussion of general challenges of migrating systems from one architecture to another.
Stuart Fettinger's 6/13/2019 Chicago Microservices Meetup Presentation -
Title: Hurry Up and GO (But Not Too Fast)
Like all programming languages, GoLang can be great in some situations - not so great in others. We weigh GO against other frameworks, focusing on real-world examples to highlight benefits and common challenges. Plus, we explore how to architect and design efficient GO applications from the start, so you can limit your long-term technical debt.
The goal for this presentation is to cover the following:
- When you should and should not use GO
- Pros and cons of the language compared to others
- Efficient architecture and design, focusing on reuse and service patterns
Writing the code is just one part of being a productive dev team.
In this talk, we'll go through what happens after the code is written, ensuring we can version, test, deploy and monitor our software.
Best practices with git - The essentials you should know about git to use if efficiently
Workshop by Otto Kekäläinen at OpenFest 7.11.2015, Sofia, Bulagaria.
This 68 slides beast surely has something new even for seasoned git developers!
FLOW3 spearheaded a move towards Git adoption within the TYPO3 project, and we are more pleased every day with the decision to turn away from Subversion and toward GIt.
In this session I explain the workflow we adopted using Git and the code review system Gerrit. I will show how it makes collaborative development more productive and improves code quality at the same time.
About go unit test, content contains:
- Why Unit Test
- Basic Knowledge
- Table Testing
- Testing HTTP
- Other Packages
- Other Mock Packages
- Testing with Docker
Slides for a talk I present at SkillsMatter.
http://skillsmatter.com/podcast/agile-testing/acceptance-testing-with-geb
This talk will cover the basics of using Geb http://geb.codehaus.org to automate browser testing.
It will compare Geb with raw WebDriver/Selenium showing Geb's expressive Groovy API.
It will also demonstrate how to integrate Geb with acceptance testing frameworks, namely Cucumber via Cuke4Duke.
We will also cover an experience report on how and why we transitioned from raw WebDriver to Geb and how existing WebDriver projects can be ported across to Geb with minimal initial effort due to its underlying use of WebDriver.
Gopher Labs brings you tutorials that help you get hands-on experience using Golang. Here you will find complete documentation of labs and tutorials that will help you, no matter if you are a beginner, SysAdmin, IT Pro or Developer. Yes, you read it right ! Its $0 learning platform. You don’t need any infrastructure. Most of the tutorials runs on Play with GO Platform. This is a free browser based learning platform for you. Hence, we have everything ready for you to get started with.
Building a private CI/CD pipeline with Java and Docker in the cloud as presen...Baruch Sadogursky
A private Java (Maven or Gradle) repository as a service can be set up in the cloud. A private Docker registry as a service can be easily set up in the cloud. But what if you want to build a holistic CI/CD pipeline on the cloud of your choice?
Baruch Sadogursky walks you through setting up a universal artifact repository, which can serve for both Java and Docker. You’ll learn how to build a CI/CD pipeline with traceable metadata from the Java source files all the way to Docker images. Baruch uses Amazon, Azure, and Google Cloud as examples, although the recipes shown are applicable to other clouds as well.
Introduction to GoLang by Amal Mohan N. This presentation is an introduction to GoLang - it's history, features, syntax, importance etc.
concurrency, go-routines, golang, google, gopher, introduction, programming
Github Copilot vs Amazon CodeWhisperer for Java developers at JCON 2023Vadym Kazulkin
In this talk I will compare 2 services Github Copilot (including Copilot X) and Amazon CodeWhisperer from the perspective of the Java developers in terms of the quality of the given recommendations for simple tasks, complex algorithms, Spring Boot and AWS development, IDE integration and pricing.
Both services are the machine learning-powered services that help improve developer productivity by generating code recommendations based on developers’ comments in natural language and their code. Based on natural language comments, these services also automatically recommend unit test code that matches your implementation code.
Power Up Your Build - Omer van Kloeten @ Wix 2018-04Omer van Kloeten
I was invited to give this talk at the Wix Backend Guild Day, an internal event which was broadcast live internationally, on 2018-04-12
Video: https://youtu.be/cQ7UvUybceA
These days sbt is the de-facto build tool for Scala, but most of us just write the minimum viable build.sbt file, import the libraries we need (and maybe throw in some sbt-assembly) and forget about it.
In this Good Practices session, you will learn about making your build safer and more robust by making the Scala compiler work for you and through using some sbt plugins.
This talk will be quite high-level. There will be no need for prior knowledge of sbt and it should be beneficial for you even if you don’t use sbt.
Getting started with go - Florin Patan - Codemotion Milan 2016Codemotion
This talk focuses on people which are interested the Go programming language and want to learn it. In it I will present the various resources new gophers have to learn Go, what are the usual pitfalls and how to get help when they are stuck.
Similar to Building a Portable Testing Rig with GoConvey and Docker (20)
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
34. A Step Further
Developing golang apps in Docker, if you vendor your dependencies,
can eliminate the need to follow $GOPATH entirely.
35. Caveats
To use BDD style, goconvey needs to be included in your project dependencies
To get goconvey’s enhancements for CLI test runner, it also needs to be included in
your project
Hi! Thank you all for being here today. This is my talk on better and more fun testing in Go with Docker and GoConvey. And, I have to say, I was a little concerned Bryan was going to steal my thunder earlier, but since he only had one slide on GoConvey, he’s forgiven.
But before we get into this, I have a confession to make… I’m not really a Go programmer. I’m a Python and Node.js programmer. In fact, I’m probably the only speaker on stage today who also attended Mark’s awesome “Intro to Go” workshop yesterday. That said, what I hope to bring here is a bit of a Go newbie’s fresh perspective.
Something else I DO have a lot of experience with... is testing.
At 18F, I was co-organizer of our Automated Testing Workgroup, which was a group centered around testing techniques and best practices. I’m sure I’m preaching to the choir here, but testing is important. Testing makes our code smarter. I believe it even makes _us_ smarter developers. When we test, we end up building better interfaces. Our modules become more decoupled. We also avoid regressions, so we can confidently ship software, and… by the way, *hands up* who here enjoys manually testing your software every time you make a change?
Since it’s so important, testing should be easy and FUN. Which means that any testing framework should be, at a MINIMUM: *lightweight, *require minimal changes to our codebase, *include the option to fail fast, meaning the test run stops at the first failure, so we don’t have to wait for the whole suite to finish running; *it should be colorful, so it’s easy to visually scan the test output. Annnd another really great feature to have is autotesting, so our tests watch for code changes, and re-run live, as soon as we make changes.
By the way, since you’re probably wondering, that photo is of a real test rollercoaster, so it’s LITERALLY TESTING FUN. And safety…. (It’s from a company in Italy called Ride Tek, which designs rollercoasters. You can read about it on Wikipedia.)
So… What does all this test evangelism have to do with Go? Well, I recently found myself helping out with a golang project. And of course, the first thing I did, after cloning the repo, was to find out where the tests were located and how to run them. And the first thing I realized was: the standard go testing library is pretty SPARTAN.
No colors
No failfast option
It didn’t support test subsets or tagging
and worst of all, no autotest.
But that’s ok, because that’s what 3rd-party testing frameworks are for, right? So let’s take a look at some of the options.
Looking around at libraries, I found Ginkgo, testify, gocheck, prettytest, go-spec, mao/zen, and more. But I’m not going to cover all of those, because just as I was starting to explore the landscape, my colleague, Jeff Damick, suggested that I check out GoConvey.
And GoConvey had something so unique, in my experience, that I had to try it out. That really unique feature was this:
The GoConvey Web UI. It acts like a local CI/CD server for your Go project. GoConvey runs as a daemon on your local machine, watches your code for changes, and automatically re-runs your tests while you code. This is really awesome for speeding up our development feedback loops, and reducing the barriers to testing. So, let’s take a quick tour of the UI.
Play/Pause, Retry, Test History, and a few others.
That third button, the test history, is really interesting, because it brings up another panel which shows our test histories, and lets us click on any one, to travel back in time, and inspect anything about the test run.
At the left, we have a pane which includes coverage information.
And from there, we can click on a package name to enter the coverage browser. But I’ll go over that more in a little bit.
Test failures are really well highlighted. And if you can see the little icon that looks like an eye, that will toggle to let us ignore any given module if we know we have tests that are going to fail, or for some reason we don’t want to keep rerunning them.
So, this GoConvey UI is really cool, and one of the best parts about it, is that it works with the standard go ‘testing’ module. But if you prefer, it also has a nice BDD syntax that we can use, with some pretty powerful asserts available. I won’t go into those here, but you can find a full list of the asserts on the GoConvey repo in the wiki.
So, at the beginning I promised this talk was going to include something about Docker. And in fact, this whole talk was inspired by the fact that I figured out how to get GoConvey running in a Docker container, and it was so friggin’ cool, I just had to come here and tell you all about it. In this next part, we are going to see how to run GoConvey in its own Docker container, and get many of the benefits of this framework, without ever changing our project’s code. So that’s what this is about. Our portable… testing... Rig. Let’s see how it works!
Here, I drew a little picture for you. How it works, is that you have your project repo on your laptop, and you mirror that directory into a volume on your container. And if you don’t know about volumes in Docker, when you mirror a path on the host, changes continue to be reflected live in the container, even after it’s built. That’s really the crux of how this whole thing works. The project from the host, gets mirrored into the $GOPATH in the container. The cool thing here is that $GOPATH on the host vs $GOPATH on the container are a totally arbitrary relationship. They look the same here, but they don’t have to be the same. If you hold that thought, I’ll have a little bit more to say about that later.
Here, we see the paths to two files we’re going to need to accomplish this setup, Dockerfile.testing and docker-compose.yml. So we have our two files, and this is just showing that the Dockerfile.testing file sets up the basic GoConvey build instructions, while the docker-compose.yml wraps those build instructions and injects the details of the local project into the build via some arguments.
And here is the text of those two files. With two small files, and under 35 lines of code, we get that whole working GoConvey setup, which I’ll demo for you a bit more in a minute. But next, I’ll go through each of these files in more detail, and if you want to pull down these files for yourself, just use the link at the bottom– they’re in a Gist on Github. (And don’t worry, I’m going to move on, but this link will be on a few of the next slides, and at the end, too.)
So, if we go through this file, section by section, first we have the FROM image– we’re just using a standard golang image based on the alpine Linux distro, which makes it really lightweight, and keeps the filesizes really small. Next, we have a couple of arguments– these get populated by the docker-compose file, which we’ll see in a minute– but you can see that we’re specifying a port to run on, and the app_path, which is the path to our repo (relative to the GOPATH/src directory). Then we EXPOSE the port, we RUN commands to install git as well as goconvey, and finally, we have the command which will start up the goconvey daemon. A few things to note there-- host works best as 0.0.0.0 with Docker – by default, it’s localhost, but that and 127.0.0.1 did not work in my testing. Port is self-explanatory, workDir is the path to the project we want to test, and finally, launchBrowser equals false– by default, goconvey tries to open itself in a browser for us, but since that won’t work from within the container, we turn it off to avoid an error.
Here is the docker-compose.yml. This says we’re using version three of the docker-compose syntax. We’re defining just one service, called goconvey… There’s some build info, including the context, which is our local project directory. We specify the dockerfile name, since we’re not using the default name, just to avoid conflicts with any existing Dockerfile you may have. By the way, you might need to do a similar renaming of the docker-compose file if you also have an existing one of those. (One caveat: don’t name your file Dockerfile.goconvey. GoConvey is a little dumb in this respect, and it will throw an error at you, because apparently the file pattern that it watches matches anything with ”.go” in the name ~anywhere~.) Next, we specify the args, our port is 9006, our app_path is the path to our go module. Then we have the volumes mapping, which is basically just mapping $GOPATH/src to $GOPATH/src here. Finally, we map port 9006 on the host to 9006 on the container. And that’s all it takes. Next, let’s watch how to get it running.
First, we’ll do a build.
Ok, now that it’s running, what can we do with it? Let’s see how autotesting works. I’ll fix a test failure and you can see the web interface re-run the tests and update in almost real-time.
END: “There we go. It’s already back to passing. I didn’t even have to reload the page or trigger anything, other than saving my Go file.”
Next, let’s check out that cool test history inspector, that’s kind of like our build history in a CI/CD system.
(Might re-run this one a second time)
This is one of my favorite parts– the coverage browser.
Ok, last demo: that web ui can take up a lot of screen real estate, but it doesn’t have to. The interface is built to be fully responsive, so you can shrink it down and have it display side-by-side with your editor, if you like.
So, to reiterate, you can have a portable testing rig with GoConvey and Docker, everything I showed you above, with just two small files dropped in to your project.
So the really great thing about this is– if you’re just helping out, or just checking out a Github repo, you can use this anytime, to get a more responsive testing experience, without installing a single go package or changing a single line of the code base.
Keeping GoConvey in a separate container from your app follows the principle of one process per container.
And if you already have a docker-compose file, you can just specify them both with the –f flag on the command line, and it should all work.
Use Docker and clone your repos where you will!
This neat trick has its limits, I must admit… [READ SLIDE]
But if you want the feeling of a local CI/CD system as you develop, and you want to be able to use it on any project you touch, you can use this portable testing rig setup!
In fact, you may even be able to build the image once, push it to a docker registry, then bring nothing but the docker-compose file from project to project. I haven’t tried this myself, but it should be possible. In addition, I’m sure there are some improvements that could be made to those Docker files that I posted. And if you find any, get in touch, I’d love to hear about them!
And that’s all. Thank you! Once again, there’s the link to the Gist for the files, I’m arowla on Twitter, and… I wish you happy and fun testing!