Workpath is the leading enterprise software provider enabling organizations to execute their strategies fast, flexible and effective in an increasingly dynamic and complex world

Workpath

Authors:
(1) Aya Kherrour, Department of Information Engineering and Computer Science University of Trento;
(2) Marco Robol, Department of Information Engineering and Computer Science University of Trento;
(3) Marco Roveri, Department of Information Engineering and Computer Science University of Trento;
(4) Paolo Giorgini,  Department of Information Engineering and Computer Science University of Trento. 2 State of the art and related work Path planning is a relevant problem in autonomous agents, such as, self-driving cars, robots, unmanned aerial vehicles (UAVs), and unmanned ground vehicles (UGVs), in which the host agent deliberates its path by moving from one position to another while avoiding obstacles and respecting some constraints [19]. One of the path planning approaches that have been proposed to control the movement of these agent-based systems is search-based algorithms, with Dijkstra and its extension A* [5, 21], being the most popular and effective ones. Besides these, other search algorithms have been proposed in the literature, specifically to reduce reaction time, broadly classified as real-time or incremental search algorithms. Real-time search algorithms must find a solution in a limited time, while incremental search instead uses the previously obtained searches to speed up the search. Amongst the first class, Real-time A* (RTA*) and Learning real-time A* (LRTA*) [14] were some of the first algorithms to apply real-time heuristic search in path planning problems for moving agents. Both algorithms use heuristics to guide the search toward the goal, with RTA* storing the second-best f-values of the previous state as the best alternative to choose when backtracking from the current state. However, this may mislead the agent. Thereby, LRTA* overcomes this by storing the first best value rather than the second and learning from comparing the heuristic values of the adjacent states, thus preventing the algorithm from misleading the agent. Another optimized version of LRTA* is real-time adaptive A* (RTAA*) [12]. It first determines its local search space and then speeds up the search by updating the heuristics values of states. It was developed for stationary target search problems and it follows trajectories of smaller costs. Anytime repairing A* (ARA*) [15] is a variation of A* that has been designed to find suboptimal solutions fast and then improve them over time, which makes it a good algorithm for problems where finding an optimal solution is not mandatory or too expensive [15]. However, finding suboptimal solutions does not make it find the optimal solution [15]. Moving to incremental search algorithms, D* (Dynamic A*) is an incremental search algorithm used in real-time planning in robotics [20]. It is designed to react quickly to changes in the environment, by updating the nodes affected in the search tree rather than recomputing a new plan from scratch. D* has a main drawback that it requires a lot of memory to perform the search. LPA* (Lifelong Planning A*), an incremental version of A*. This algorithm is used in path planning or robot navigation in unknown terrain. It behaves just like A* in the first run, and then for the rest of subsequent searches it reuses the previous search thus reducing the number of examined nodes, which makes it fast. LPA* differs from D* in its search direction where it finds a path from the initial state to the initial goal state, therefore it does not fit in applications where the starting point may change over time. Another variant of D*, D* Lite, was developed based on LPA*, and is used for goal-directed path planning in unknown environments using the same idea as D*, however, it is a simple version of D* and produces effective results as the one delivered by D* as proven in [11]. While these heuristic search algorithms are numerous and diverse, it is important to emphasize that there are even more algorithms in the literature with new ones being developed, or existing ones being improved such as [2, 13, 7]. This variety of algorithms in the field emphasizes the complexity of the problem. Consequently, this variety of proposed algorithms presents a challenge; the wide number of these algorithms results in disparate performances in tasks such as path planning, making it difficult to select the optimal algorithms for a given task. Given the multitude of algorithms, studies have been done to compare the performance of RTS algorithms in path planning tasks such as [1] where authors have compared the performances of path planning algorithms using agents equipped with a sensor in both stationary and moving target settings to select the most appropriate algorithm. The obtained results were compared using various sensor ranges and angles, and the authors concluded that sensor range is an important parameter in selecting the algorithm, unlike the sensor angle. Therefore the most appropriate algorithm can be selected based on the sensor range and its priorities. However, the authors did not consider varying the environmental characteristics, which may influence the performance of the algorithms. Another study has been presented in [13], in which the authors also compared real-time and incremental heuristic search algorithms using an autonomous agent in a navigation task to know which class of heuristic search approach is better to be used depending on how informed the h-values are, and the search objective such as minimizing the sum of the search and action execution. The comparative analysis done in [1] considers only a static environment, neglecting the possible variations in the algorithm performance under different environmental characteristics. This limitation hampers us from creating a clear understanding of different search algorithms that could perform under different environmental characteristics, precisely in the context of path planning. Similarly, the study conducted in [13] restricts its investigation to only two algorithms each one from a different class i.e., real-time and incremental heuristic search. Even though it provides an insightful comparison, the study does not fully capture the breadth of available algorithms in these classes. Moreover, the study aimed to provide a recommendation on when to use each of the algorithm classes, but also does not investigate algorithm performances in diverse environmental characteristics. Consequently, considering the challenge posed by the presence of a wide range of search algorithms and the lack of a comprehensive comparative analysis under different environment settings, we propose to evaluate and analyze the performance of some search algorithms under different environment characteristics in the context of path planning, But first, we define the characteristics of the environment used, and through our experiments, we aim to provide a comprehensive evaluation of these algorithms followed by proposing our selection algorithm. This paper is available on arxiv under CC 4.0 license. Authors: (1) Aya Kherrour, Department of Information Engineering and Computer Science University of Trento; (2) Marco Robol, Department of Information Engineering and Computer Science University of Trento; (3) Marco Roveri, Department of Information Engineering and Computer Science University of Trento; (4) Paolo Giorgini,  Department of Information Engineering and Computer Science University of Trento. Authors: (1) Aya Kherrour, Department of Information Engineering and Computer Science University of Trento; (2) Marco Robol, Department of Information Engineering and Computer Science University of Trento; (3) Marco Roveri, Department of Information Engineering and Computer Science University of Trento; (4) Paolo Giorgini,  Department of Information Engineering and Computer Science University of Trento. 2 State of the art and related work Path planning is a relevant problem in autonomous agents, such as, self-driving cars, robots, unmanned aerial vehicles (UAVs), and unmanned ground vehicles (UGVs), in which the host agent deliberates its path by moving from one position to another while avoiding obstacles and respecting some constraints [19]. One of the path planning approaches that have been proposed to control the movement of these agent-based systems is search-based algorithms, with Dijkstra and its extension A* [5, 21], being the most popular and effective ones. Besides these, other search algorithms have been proposed in the literature, specifically to reduce reaction time, broadly classified as real-time or incremental search algorithms. Real-time search algorithms must find a solution in a limited time, while incremental search instead uses the previously obtained searches to speed up the search. Amongst the first class, Real-time A* (RTA*) and Learning real-time A* (LRTA*) [14] were some of the first algorithms to apply real-time heuristic search in path planning problems for moving agents. Both algorithms use heuristics to guide the search toward the goal, with RTA* storing the second-best f-values of the previous state as the best alternative to choose when backtracking from the current state. However, this may mislead the agent. Thereby, LRTA* overcomes this by storing the first best value rather than the second and learning from comparing the heuristic values of the adjacent states, thus preventing the algorithm from misleading the agent. Another optimized version of LRTA* is real-time adaptive A* (RTAA*) [12]. It first determines its local search space and then speeds up the search by updating the heuristics values of states. It was developed for stationary target search problems and it follows trajectories of smaller costs. Anytime repairing A* (ARA*) [15] is a variation of A* that has been designed to find suboptimal solutions fast and then improve them over time, which makes it a good algorithm for problems where finding an optimal solution is not mandatory or too expensive [15]. However, finding suboptimal solutions does not make it find the optimal solution [15]. Moving to incremental search algorithms, D* (Dynamic A*) is an incremental search algorithm used in real-time planning in robotics [20]. It is designed to react quickly to changes in the environment, by updating the nodes affected in the search tree rather than recomputing a new plan from scratch. D* has a main drawback that it requires a lot of memory to perform the search. LPA* (Lifelong Planning A*), an incremental version of A*. This algorithm is used in path planning or robot navigation in unknown terrain. It behaves just like A* in the first run, and then for the rest of subsequent searches it reuses the previous search thus reducing the number of examined nodes, which makes it fast. LPA* differs from D* in its search direction where it finds a path from the initial state to the initial goal state, therefore it does not fit in applications where the starting point may change over time. Another variant of D*, D* Lite, was developed based on LPA*, and is used for goal-directed path planning in unknown environments using the same idea as D*, however, it is a simple version of D* and produces effective results as the one delivered by D* as proven in [11]. While these heuristic search algorithms are numerous and diverse, it is important to emphasize that there are even more algorithms in the literature with new ones being developed, or existing ones being improved such as [2, 13, 7]. This variety of algorithms in the field emphasizes the complexity of the problem. Consequently, this variety of proposed algorithms presents a challenge; the wide number of these algorithms results in disparate performances in tasks such as path planning, making it difficult to select the optimal algorithms for a given task. Given the multitude of algorithms, studies have been done to compare the performance of RTS algorithms in path planning tasks such as [1] where authors have compared the performances of path planning algorithms using agents equipped with a sensor in both stationary and moving target settings to select the most appropriate algorithm. The obtained results were compared using various sensor ranges and angles, and the authors concluded that sensor range is an important parameter in selecting the algorithm, unlike the sensor angle. Therefore the most appropriate algorithm can be selected based on the sensor range and its priorities. However, the authors did not consider varying the environmental characteristics, which may influence the performance of the algorithms. Another study has been presented in [13], in which the authors also compared real-time and incremental heuristic search algorithms using an autonomous agent in a navigation task to know which class of heuristic search approach is better to be used depending on how informed the h-values are, and the search objective such as minimizing the sum of the search and action execution. The comparative analysis done in [1] considers only a static environment, neglecting the possible variations in the algorithm performance under different environmental characteristics. This limitation hampers us from creating a clear understanding of different search algorithms that could perform under different environmental characteristics, precisely in the context of path planning. Similarly, the study conducted in [13] restricts its investigation to only two algorithms each one from a different class i.e., real-time and incremental heuristic search. Even though it provides an insightful comparison, the study does not fully capture the breadth of available algorithms in these classes. Moreover, the study aimed to provide a recommendation on when to use each of the algorithm classes, but also does not investigate algorithm performances in diverse environmental characteristics. Consequently, considering the challenge posed by the presence of a wide range of search algorithms and the lack of a comprehensive comparative analysis under different environment settings, we propose to evaluate and analyze the performance of some search algorithms under different environment characteristics in the context of path planning, But first, we define the characteristics of the environment used, and through our experiments, we aim to provide a comprehensive evaluation of these algorithms followed by proposing our selection algorithm. This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

Evaluating Path Planning Algorithms: Real-Time vs. Incremental Search

Version control is the backbone of modern software development, and mastering Git config can take your version control game to the next level. Today, I’m sharing a few tips to enable you to streamline your workflow and leverage the best out of our beloved Git, the Swiss Army knife of version control systems, and turn you into a Git guru. Tip 1: Conditional Configuration In Git 2.13 and later, you can conditionally include another Git config file based on your Git directory or branch. This feature is incredibly handy when you need different configurations for various projects. For instance, if you have a work-specific Git configuration, you can create a file and add or override configuration values as needed. Here's an example: .gitconfig.work [user] email = john@personal.com [includeIf "gitdir:~/work/"] path = .gitconfig.work This way, when you're working within the directory or its subdirectories, Git will pick up these specific configurations, making your work-related tasks a breeze. ~/work Tip 2: Set Default Branch To Main By default, when you initialize a new Git repository, the initial branch is named 'master.' However, there's a growing awareness of using more inclusive terminology, such as 'main,' as the default branch name. To make this change globally for all new repositories, you can use the following command: git config --global init.defaultBranch <name> This command updates your global file, aligning Git with the evolving best practices. ~/.gitconfig If you want to leave the default behavior but rename the branch after initialization, you can use the git branch -m <name> Tip 3: Using External Diff and Merge Tools Enhance your Git workflow by integrating external diff and merge tools like Beyond Compare or KDiff3. By configuring them in your gitconfig, you can seamlessly use these tools for resolving conflicts and comparing changes. Here's an example configuration: [diff] tool = bc3 [difftool "bc3"] cmd = "bcomp \"$LOCAL\" \"$REMOTE\"" Now, Git will use Beyond Compare (or your preferred tool) whenever you run commands like or git difftool git mergetool . Tip 4: Use Git Aliases Git aliases are your secret weapon for boosting productivity. They allow you to create shortcuts for frequently used Git commands. For example, you can create an alias called co that executes git checkout with just git co. Aliases are defined in your file, and they can replace one or more Git commands. ~/.gitconfig Here's an example alias configuration: [alias] co = checkout ci = commit st = status br = branch hist = log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short With these aliases in place, running is equivalent to , and provides a custom, more informative git log output. git co git checkout git hist $ git hist *   f790b78 2023-08-27 | feat: add footer #13 [user] |\ | * 11d2d75 2023-08-27 | feat: implement new footer (origin/add-footer, add-footer) [user] | * 091d895 2023-08-27 | feat: add footer component [user] |/ *   e45725d 2023-08-27 | fix: minor style fixes #12 [user] Tip 5: Setting VS Code as Your Default Git Editor If you're a fan of Visual Studio Code (VS Code), you can set it as your default Git editor to leverage its advanced features. To do this globally, you can run the following command: git config --global core.editor "code --wait" This command configures Git to use VS Code as the default editor, enhancing your Git experience when it comes to making commit messages or resolving merge conflicts. Mastering Git config opens up a world of possibilities and efficiency. These five tips are just the beginning. If you're passionate about simplifying configurations and helping fellow developers, consider visiting and contributing to our open-source library of config tips and tricks . Config.Tips was born from the idea that collecting knowledge in one place could help make any type of config easier for developers. Config.tips If you like our project, you can also give a star to our . GitHub repository We are one of the open-source repos listed for Hacktoberfest, so don’t be shy to make config even more accessible for everyone by with your config tip(s). opening a pull-request

Unlocking Git's Hidden Powers: 5 Configuration Tips for Effortless Version Control

What makes some teams do exceptionally well and others perform poorly? Do they have more talented team members and better resources, or are they simply lucky? Teams that stand out are not more talented, better skilled, or have greater opportunities. What sets them apart are their habits and practices. Empowering work culture, support from leaders in the organization, and clarity of vision and goals are important, but they’re not sufficient to drive excellence and high performance in teams. Building extraordinary workplaces with high-performing teams requires more than hiring the right talent and equipping them with the right opportunities. It requires cultivating the right habits and incorporating them into daily work and life. Here are the five habits of high-performing . teams They use premortem techniques to make better decisions Making good decisions is hard. Choices that look good at the moment often fail in the future. In hindsight, though, the failure seems evident and clear. High-performing teams don’t make perfect decisions or not never fail. What makes them stand out is the practice they adopt to combat cognitive biases and reduce project risk at the outset. They use the premortem approach to evaluate possibilities, understand consequences, anticipate failures, and then find ways to avoid them. Developed by Gary Klein, premortem is a highly effective technique to evaluate risks and proactively identify potential problems and obstacles that might get in the way of success. This is the way it works: Place yourself into the future and look back. Visualize the project, task, or whatever you intend to do has gone horribly wrong. Work backward to identify what mistakes might cause it to fail. Create a plan to solve these issues—address the risks and obstacles, thereby increasing your chances of success. The best way to recover from a false start is to avoid one in the first place. And the best technique for doing that is something called a "premortem". — Daniel Pink Teams that perform well don’t always make the best choices. They just avoid obvious and bad mistakes. Instead of agreeing to disagree, they disagree and commit What separates a healthy team from an unhealthy one is the willingness to openly disagree and yet remain committed to supporting each other. When team members agree to disagree, they adopt a negative mindset. Instead of accepting that it’s not about right vs. wrong, us vs. them, agreeing to disagree makes them adopt dismissive behavior and ignore the decision. They become non-committal, which refrains them from providing the necessary support to others. The “ ” mindset sabotages the purpose of a group to come together and challenge each other while remaining committed to supporting each other. Agree to disagree Disagree and commit, on the other hand, divulges the importance of commitment despite their differences. At its core, it supports unity and maturity to disconnect their identity from their ideas and support others even when they do not agree with their point of view. It doesn’t hide the fact that they disagree nor dismiss the value of their opinion; it simply guides them to know when it’s time to get past their conviction and work with others instead of working against them. Instead of turning differences of opinion into a personal agenda where one side must lose for the other to win, high-performing team members look beyond their own perspective and treat other people’s ideas as worthy of consideration. When a decision doesn’t turn out the way they anticipated, instead of agreeing to disagree, they disagree and commit. Each of us tends to think we see things as they are, that we are objective. But this is not the case. We see the world, not as it is, but as we are—or, as we are conditioned to see it. When we open our mouths to describe what we see, we in effect describe ourselves, our perceptions, our paradigms. When other people disagree with us, we immediately think something is wrong with them. But, as the demonstration shows, sincere, clear headed people see things differently, each looking through the unique lens of experience — Stephen R. Covey To disagree and commit, high-performing team members do this: Separate their identity from their idea. Share their intent. Inquire into the conflict. Evaluate and understand different perspectives. State they disagree yet commit to supporting the decision. Teams that perform well commit wholeheartedly and support conflicting opinions. They practice radical candor to give and get feedback People who don’t get feedback share a common problem—they dump the complete responsibility of giving the right feedback on the feedback giver. Thinking that others are vague, dishonest, or unwilling to share feedback makes them ignore the role they play in the equation as the person on the receiving end of the feedback. Without proper feedback, there’s no way for them to know what they’re doing wrong and what changes will help them learn, improve, and get better. Not experiencing the benefits of timely feedback also prevents them from sharing valuable feedback with others. create an environment that’s conducive to feedback. They not only constantly pull feedback and advice from others, they don’t hesitate to push feedback to others. Sharing feedback with others helps them grow, while seeking the same feedback from others creates a self-perpetuating cycle of learning and growth. High-performing teams Creating pull is about mastering the skills required to drive our own learning; it’s about how to recognize and manage our resistance, how to engage in feedback conversations with confidence and curiosity, and even when the feedback seems wrong, how to find insight that might help us grow. It’s also about how to stand up for who we are and how we see the world, and ask for what we need. It’s about how to learn from feedback—yes, even when it is off base, unfair, poorly delivered, and frankly, you’re not in the mood — Douglas Stone They do this by asking these two questions to themselves and others: How can we work better? How can we improve together? High-performing team members take full responsibility for giving and getting feedback with the belief that they have the power to drive their own growth at work as opposed to blaming someone else for not moving forward. They use a high agency to navigate unknowns and challenges High agency is about finding a way to get what you want without waiting for the conditions to be perfect or otherwise blaming the circumstances. High-agency people either push through in the face of adversity or they manage to reverse it to achieve their goals. They either find a way or they make a way. High Agency is the ability to navigate unknowns and challenging circumstances to carve your own path to success without waiting for the conditions to be perfect. It’s a sense of control over your own behaviors, decisions, and actions in shaping up your life as opposed to relying on external circumstances, conditions, and environment to decide what you can and cannot do. Instead of considering other people’s limits as their own limits and fitting inside a box based on what others deem possible, high-agency people expand their boundaries of influence, push themselves to navigate uncharted territory, and do the work that’s necessary to succeed. Many things can go wrong at work—conflicting priorities, unknown problems, the uncertainty of decisions, misalignment of expectations, communication gaps, unrealistic deadlines, and so on. Adopting a victim mentality in such cases prevents people from thinking clearly, finding solutions, and moving forward. Assuming others are the source of their problem prevents them from taking responsibility and feeling in control of their outcomes. High-performing team members don’t engage in such behavior. They take responsibility not only for their experience but also for their outcomes. They don’t have special talents or knowledge. What differentiates them is their ability to turn adversity into opportunity. What makes them push ahead when many others pull back is their relentless drive to look for solutions instead of complaining about the problems. When they fail or make mistakes, they feel disappointed, much like everyone else, but they don’t let that disappointment get in the way of taking action or making progress. In Jim Dethmer calls this “taking radical responsibility.” He writes, “When we place blame, we locate the cause and control of our lives outside ourselves. When we take responsibility, we locate the cause and control of our lives inside ourselves.” The 15 Commitments of Conscious Leadership, They make learning a priority. Work environments constantly , new responsibilities, and new ways of doing things. demand new skills Sitting inside the comfort zone and doing things that come easy or appear less challenging definitely feels safe. But it also limits growth opportunities. Without experiencing the discomfort that comes with embracing unknowns, without knowing how to navigate complexity, and without building the resilience to deal with uncertainty, career growth is impossible to achieve. High-performing teams understand this very well. They challenge themselves to seek new opportunities, solve problems they’ve never solved before, and do work that requires them to expand their skills. Making learning a priority not only helps them turn obstacles into opportunities but also leads to less stress and anxiety. Just as athletes never quit training, high performers never stop consciously conditioning and strengthening their habits. Real success—holistic, long-term success—doesn’t come from doing what’s natural, certain, convenient, or automatic. Often, the journey to greatness begins the moment our preferences for comfort and certainty are overruled by a greater purpose that requires challenge and contribution. The skills and strengths you have now are probably insufficient to get you to the next level of success, so it’s absurd to think you won’t have to work on your weaknesses, develop new strengths, try new habits, stretch beyond what you think your limits or gifts are. — Brendon Burchard Summary High-performing teams proactively identify potential problems, evaluate risks, and find ways to overcome obstacles that might get in the way of success. They do this by using the premortem technique. They are open to sharing their disagreements, but once a decision has been taken, they show their full support and commitment. To perform at their highest levels, high-performing team members leverage the power of feedback. They use every opportunity to give and get feedback. Instead of blaming others, high-performance teams take complete responsibility for their experience and outcomes. High agency gives them a sense of control to move forward instead of feeling stuck. They consciously step out of their comfort zone by embracing new opportunities and taking risks. Making learning a priority prepares them to better deal with the challenges and demands of work life. Also published . here

5 Habits of High Performing Teams That You Should Consider 

The Go programming language has become quite popular over the past few years. Why? The primary reason is that it has become the language of choice for distributed and highly scalable servers. Go was based on C and brings code efficiency to the table, which generates faster software and apps for businesses. Go includes the disciplined syntax of C, but adds a number of changes that do away with memory leakage. It’s fast, easy to learn, scales incredibly well, is lean, and efficient. Many companies have quickly adopted this language. Some of the more notable businesses that have done so include: Google Apple Facebook Docker The New York Times BBC Chances are your favorite QA testing services are either already up to speed with Go, or in the process of adopting this powerful language. Let's get Go installed on the Linux operating system and start using the language. You'll be surprised at how easy the installation is. Installing Go on Linux I'll be demonstrating on Ubuntu Server 20.04, but Go can be installed on nearly any Linux distribution. Go is also available for macOS and Windows. The only thing you'll need to get it installed is a running instance of Linux. The first thing to be done is the downloading of the necessary file. Change into your Downloads directory with the command: cd ~/Downloads Now you can download the file with the command: curl -O https://storage.googleapis.com/golang/go1.13.5.linux-amd64.tar.gz With that file downloaded, unpack it with the command: tar -xvf go*.tar.gz Next, move the newly-created Go folder with the command: sudo mv go /usr/local The next step is to add the go folder to your user's . For those that don't know what a user's is, it's any directory that is considered global. A global directory means any executable file within that directory can be run from anywhere in the file system. $PATH $PATH To see the current directories in your , issue the command: $PATH echo $PATH You will see that the newly moved Go directory isn’t included. To add that directory to your $PATH, issue the command: nano ~/.profile Scroll to the bottom of that file and add the following lines: GOPATH=$HOME/work PATH=$PATH: local/go/bin:$GOPATH/bin export export /usr/ Save and close that file. Refresh your profile with the command: source ~/.profile You can now check to make sure the Go folder is in your $PATH with the command: go version The above command should print the version number of the installed Go language. And that’s all there is to installing the Go language on Linux. Hello, World! I'm going to use the traditional "Hello, World!" example to demonstrate how Go works. Yes, this is a very simple and basic program, but it's a great way to illustrate how to use a new language. The first step is to create the hello-world.go file. Issue the command: nano hello-world.go In this new file, paste the following contents: package main func main() {
    fmt.Println( )
} import "fmt" "Hello, World!" Save and close the file by using the [Ctrl]+[x] key combination. One of the interesting aspects of Go is that you can run a program without compiling it. To do that, you would issue the command: go run hello-world.go The results of the command would print out: Hello, World! You can also compile a go program, which would create an executable binary. To build the binary file from the hello-world.go file, issue the command: go build hello-world.go The results of the build would produce a new file named hello-world. You could then run that file with the command: ./hello-world You should see the same message printed out as you did when you ran the uncompiled file. Of course, you could always copy that file to a directory in your path, so the new application could be run from anywhere in the directory structure. To do that, issue the command: sudo mv hello-world /usr/local/bin Now, to run the hello-world application, just issue the command: hello-world You should then see the "Hello, World!" message printed out. Conclusion As a developer, you'll wind up having to work with Go at some point. Whether you're joining a project as a new software engineer, joining a web application testing firm, or starting a new job, Go will cross your path. At least now, you can install the necessary tools and have an idea of how to create and build an app with Go on Linux. To find out more go to . BairesDev

How to Install Go on Linux - Tutorial

Introducing the InfoSec colour wheel — blending developers with red and blue security teams.

Presentamos la rueda de colores de InfoSec — que combina desarrolladores con equipos de seguridad rojos y azules.

Behavior-Driven Development (BDD) is a really powerful tool that helps us build robust, value-based software. You can sometimes hear detractors say that it brings a lot of complexity and leads to long tests difficult to maintain. Let's take stock of what BDD really is, by determining anti-patterns and best practices. "I will write/fix the BDDs" This sentence is the main symptom of a misunderstanding about Behavior-Driven Development. BDD is not a file, a test or a testing activity. It's a development process: . a methodology You cannot write a methodology, you apply it. Most of the people believe that having written tests in a style means that they do BDD. But we cannot blame them when we can find badly named frameworks such as or . And there are two main reasons why the keyword "BDD" is misused in these cases. Given When Then BDDMockito Chai BDD First, it is not because they are labeled BDD that they facilitate or encourage people to work in a BDD fashion. Even worse, they allow them to think they are doing it! Suppose we rename JUnit5 in TDD JUnit, will developers start writing their tests before coding only because of that? How can a framework ensure that a methodology is applied? Secondly, is a convention, a nomenclature in which we have to write scenarios in natural language, also called Gherkin, if you use . This is only a small part of what BDD is. Given When Then Cucumber Back to the basics: the theorical part Behavior-Driven Development, it's all in the name: focus on the behavior of the software and let it drive our development process. The main advantages: business value first and robustness. User Scenarios and Examples The starting point is always a scenario, defining the needs of the user. Without this, you can not create software that matters. This "specification" must be made with the main stakeholder: the user (or at least one person who represents and understands him). Taking the need at the source is always the best way. The user (his representative) is not only a stakeholder, he must participate in the design phase of the application. That's why it's essential to use a natural language to define your needs. As a general rule, an end user can not write or review JUnit tests. It also focuses on the definition and the usage of an ubiquitous language. If the user calls this a "dog", it must be named so in the scenarios. Everyone, from the user to the developer, must speak the same language, it will avoid confusion and facilitate communication, therefore the collaboration, and then speed up the development process. The scenarios are not just the description of business rules. These rules must be "instanciated" on concrete examples and you can then call them scenarios. This way, you will identify what are the acceptance criteria (Then) from some "Given" context and/or inputs "When" a user performs an action => e.g. how your application should behave in that situation. specific kind of : As a cinephile In order to not loose a single minute of a movie I want to know what are the next showings of the movie theater : a cinephile : Looking for the next showings before the start of the last one the last showing is not started yet the user asks for the next showings the returned showings are not started yet the returned showings are not starting in the next 15 minutes Feature Background Given Scenario Given When Then And Every scenario must define: is the main stakeholder of the feature, whose needs we must meet (As a). who , to qualify the need of this stakeholder (In order to). why are the expected results of the feature (I want to). what In the above example written in the Cucumber-Gherkin way, you can see that all the terms belong to the lexical fields of the cinema. Cinephile, Movie, Movie Theatre and Projection define the ubiquitous language. This business language, combined with Gherkin's natural language nomenclature, makes this specification perfectly understandable for our users. The context is clearly identified: before the start of the last showing. The are the expected results of the previous scenario. You may have also noticed that we have here several levels of abstraction. next showings The definition of the feature is really high level. Each scenario is a specialization of the functionality in a given context, and the results of the feature are refined in the "then" directives. As you can see, the concept of is refined in the "then" statement: showings that are not yet started and do not start in the next 15 minutes. next showings Sometimes this refinement does not come from the user himself. You can imagine that the movie theatre - which is also a stakeholder - does not want us to show the user the immediate for some reasons of crowd management. Or maybe, just to avoid the disturbance of someone entering late a room where a movie has already started. Every stakeholders count, this is one of the principles of the methodology. outside-in When a specific kind of user performs an action From one type of user to another, the expectations (acceptance criteria) of an action / feature can be very different. You can not bring value if you do not know who the user is. Not identifying the persona may also lead to writing unusable features. In addition, it also introduces security issues due to a lack of permissions management. BDD is not a security methodology, but it has the very good side effect of encouraging people to think about the type of user that should be able to perform certain actions. In the example above, the identified persona is a cinephile. Let's assume our application is also used by the projectionists of the movie theatre. For this type of users, knowing what the next showings will mean which projections they need to run in order to be synchronized with their work schedule. The virtuous double loop BDD is a development process based on two loops. In the first loop we identify the user needs that are expressed as scenarios with examples as follow: : As a cinephile In order to not loose a single minute of a movie I want to know what are the next showings of the movie theater : a cinephile : Looking for the next showings before the start of the last one the last showing is not started yet the user asks for the next showings the returned showings are not started yet the returned showings are not starting in the next 15 minutes Feature Background Given Scenario Given When Then And For each step of a scenario, we start writing the fixtures - also called step definitions - i.e. implementing the steps from a technical stand point. These fixtures will constrain and therefore define the behavior of the application. { {

        Given( , () -> me = Cinephile( ));
        Given( , 
           () -> lastShowing = Showing(now().plusHours( )));

        When( ,
                () -> nextShowings = searchShowings.searchNextShowingsFor(me));

       Then( , () -> {
            assertThat(allShowings.stream().filter(showing -> !showing.hasStarted()))
               .containsAnyElementsOf(nextShowings);
        });
       
        Then( , () -> {
            assertThat(nextShowings)
               .noneMatch( showing -> showing.startsBefore(now().plusMinutes( )));
        });
    }
} public class StepDefs implements En public StepDefs () "^a cinephile$" new "me" "^the last showing is not started yet$" new 3 "^the user asks for the next showings$" "^the returned showings are not started yet$" "^the returned showings are not starting in the next 15 minutes$" 15 Note that we are not talking about the production code here. The above example is written in a cucumber java8 style. The scenario with its related fixtures represent an acceptance test. Then we start the inner TDD loops by implementing the production code used in the step definitions until the functionality is developed. That's why we call this a "double loop". Behavior-Driven Development is a methodology that has emerged from TDD. It has the same strengths as Test-Driven Development - assures good test coverage and code design - while getting rid of the limitation of the bottom-up approach of TDD. When working with TDD, it can sometimes be very difficult to determine where to start, what may be the appropriate granularity of the method we want to build. Have you ever had this feeling: after performing a major refactoring during the last TDD iteration, you would have converged faster if you had thought of the problem with a top-down approach? This is where BDD helps a little, by forcing you to think first from the consumer's point of view, you can say this methodology is totally complementary to TDD and, more importantly, it drives your TDD iterations. Best Practices: the practical part All user stories and epics must have scenarios This is the basis. BDD offers a real framework for expressing user needs. By integrating a scenario into a user story, you make sure that it has been sufficiently prepared to be developed. Although it is very difficult to find anything in tools such as JIRA, the scenario will ensure the functional documentation of your software which, by design, is automatically checked. Always have a persona in a Given As mentioned earlier, the identification of the persona is the key, so it must be explicitly define inside a Given directive. This will also avoid confusion. Beware that persona are important from a security point of view. It will define the required privileges to trigger a feature. : Persona are not defined by fancy user names, rather use roles, it avoids mental mappings. NOTE Only one “when”! Your scenario must describe a single responsibility for a feature and you must have one scenario per use case. By not following these rules, you will end up with an accidental complexity. Remember that a When clause is describing a feature. If you need multiple Whens in a single scenario, it may mean you have a design problem. Then in the passive voice with no user action Thens are dedicated to the assertions on the outputs of a feature, the user is not a part of it. returned showings are starting next minutes the not in the 15 The subject must be the functional object on which we must check the post-conditions of the feature. The passive voice is best to emphasize the functional objects affected by the execution of the feature. You should never have any user actions here, they are dedicated to Whens directives. Putting a user action in a Then means that you can control what your user will do exactly after running your feature. Think about the unhappy paths first We usually start with the happy path to reassure ourselves, but unfortunately the process ends here. A large number of bugs are due to a lack of analyzis around the errors. Thinking first about the unhappy paths ensures that your functionality is built robustly. Do not forget to fail fast. expected Avoid the tables frenzy Some Gherkin frameworks allow you to use tables, although this can be very convenient and justified when you want to iterate over several input examples, it is totally inadvisable to use it to represent a complex object because you would lose the functional intent. In the folowing example: the showing:
  | | | | | |
  | | | | | | a child tries to buy a ticket for this showing the purchase is forbidden Given name schedule director rating duration Gore Movie 21H00 Jhon Doe NC-17 PT2H5M When Then A showing is built in the Given using the content of the table. Unfortunately we do not know what characteristics of the showing are important for the rest of the scenario, until we read the When and the Then. Here, only the rating is important, the goal being to prevent a child from buying a ticket for a movie rated NC-17. A better approach would be: a NC-17 rated showing a child tries to buy a ticket for this showing the purchase is forbidden Given When Then It is totally fine to hide inside the fixture the initialization of the showing fields as soon as they have no impact on the behavior of the scenario. Do not let an unimplemented step pass Some frameworks such as Cucumber will not fail your scenario by default if one of the steps is not implemented. But what can you say about a passing Scenario in which the only Then directive is not implemented? Never postpone the implementation of a step definition, it goes against the principles of the double loop first and no one will ever implement it later. Usually, we discover that an implementation is missing when we try to debug the given functionality. If you use Cucumber, make sure to turn on the . strict option Step Definitions must be component based Most of the time, users split their step definitions in the same way as their scenarios. Unfortunately, it couples everything together and the steps you made cannot be reused for another scenario. The step definitions should be organised in the same way than your domain concepts and, moreover, named after them. This way your step definitions code will be factorized, easier to find and navigate through, you'll get easier steps to manage and reuse. In other words, the step definitions must be designed with the same processes we use to create our business domain! Do not create a And or But fixture And and But are fine for chaining Givens and Thens in a scenario. However, do not define them as fixtures: And( , ...) "^the returned showings are not starting in the next 15 minutes$" In this case, it is really difficult to understand if this directive can be used as a Given or a Then and you can not usually use the same directive for different purposes. A Given usually initiates the input of a feature while a Then makes assertions on the outputs. Use an ubiquitous language The scenario must be understandable from the point of view of the user. Words must therefore be carefully chosen from the concepts of the business domain. Avoid technical terms! Expose your scenarios as a living documentation The natural language enforced by gherkin with the use of an ubiquituous language provides a powerful functional documentation of your software which is always up-to-date. This makes it easy to integrate new members into the team and helps your product owner / user understand what features your software supports. But do not just keep it in your version control repository, expose it as a static website generated from your CI/CD. You can use tools like for this purpose. Pickles Be Agile: Do not write all your scenarios at the same time Some teams lock up an entire afternoon in a room to produce a dozen scenarios needed for software. We do not live in the dark age of Waterfall, it is not necessary to specify everything in advance. Generally, these teams commit these scenarios directly in their repository. This has the disadvantage of confusing what the application is currently doing. Even adding a tag like to the top of a scenario is counterproductive for two reasons: first, the feature file name is meaningful enough to make someone think that it is really developed; secondly, invariants or simply the understanding of a functionality evolves over time. In some cases, the features are descoped... and your repository is not a backlog ... @wip A scenario must be written just before implementation - just in time - to save time and money. Do not mix the concerns (integration test/functional test) Sometimes you can see a scenario connected to the controller of an application and, as you can imagine, it's a bad practice. The scenarios have a business purpose: connecting it to the application's infrastructure level changes them into integration tests, and this methodology is not intended to meet an integration goal. A scenario is used to describe the use case of a feature. It should not fail because your JSON serializer is not well defined in a controller. If you are already "implementing" BDD and find yourself with hard-to-maintain tests, it's usually because of this lack of separation of concerns. Be aware that even Cucumber discourages this usage: documentation Cucumber is not an API automation tool In , it is generally advisable to connect the scenario directly to the domain modules of your application. hexagonal architecture If you like to write integration tests using a Gherkin style, you should take a look at . A really powerful tool with many predefined step definitions that handles some HTTP operations for you. KarateDSL Here is an example of a KarateDSL feature file: : Profile endpoint : creating a profile path 'profiles' request method post assert responseStatus == 201 match responseHeaders['Location'] contains only (profilesUrl + userId) Feature Scenario Given And """
    { "topics": [{"name": "DDD"},{"name": "Hexagonal Architecture"}],"talksFormats": ["QUICKIE","CONFERENCE"] }
    """ When Then And NOTE: All step definitions are built into KarateDSL, which means that the integration test does not require more than this file. Nutshalling BDD This is a methodology that helps you first define the behavior of a feature using with . It is complementary to the which takes a bottom-up approach while BDD comes from the top. development scenarios examples TDD The ensure the creation of a robust and tested software and the scenarios provide a that facilitates communication with non-technological stakeholders. double loop living documentation Further readings You can also read this really good article which also cover some other best practices in BDD: Cucumber Anti-Patterns Cucumber is a testing tool that allows you to test your assumptions and understanding of the problem before you…www.thinkcode.se and browse this , where you'll find a full implementation of and . repository Cucumber KarateDSL

Behavior-Driven Development From Scratch [101]

Whether you’re at the office from 9–5 or you’ve embraced a more unconventional work path, it’s critical to take deliberate steps to balance your digital work life with your respective social one. Data from the US Consensus Bureau shows that work from the comfort of their home office at least 50% of the time. In the last 5 years, work from home options . More prevalently, employers offering flexibility through telecommuting options have saved over $44 billion a year combined. 3.7 million Americans increased by 40% While decentralization will continue to be a more sustainable and effective option for employers and employees alike, individuals who opt to pursue the route of telecommuting must prepare for the barriers of entry and potential challenges. One such challenge sited most frequently is isolation. The first reports indicates that . State of Remote Work survey Data of 2018 21% of employees grapple with not only communication and collaboration, but also problems of loneliness And though, I’ve had my fair share of feeling lonely even in the office surrounded by 100+ people, it’s different when you’re sitting at home really alone. The feeling can be grueling, and we’ve all felt it at one point or another. According to researched this problem affects more than half of the American population, it is an issue that will remain dominate in our society with the rise in use of technology. published by UCLA, To help spark ideas to mitigate these effects, I’ve put together a list of tools and deliberate practices that I’ve found personal success with, both on and offline to build relationships that go beyond the surface. I believe by making a conscious effort to test out one or more of these options, you can begin to create meaningful connections in the digital workplace and in your own personal life. 5 Ways to Create Relationships Offline with People In Your Local Community 1. Find a Co-working Space Near You Use sites like to filter by location, reviews and membership options to find your perfect space. Many offices provide a free day pass or in some cases a free week so that you can test out the space and ensure it’s the right fit for you. Coworker has an aggregated list of the top 150 spaces around the world. Use the ⌘command and ‘F’ key to see if your city or country had an exceptional space that made the list. Deskbookers Additionally if you’re looking for a place to create camaraderie and unity and even join events, is a great option. The valued global community of entrepreneurs, leaders and innovators will make you feel right at home. Wework 2. Become a Tourist in Your Own City Who says the only time you can explore is when you’re living in a new city or nomad-ing in a foreign country? Using platforms like , and the more globally renowned can be an effective way to search for coffee shops and aesthetically appealing libraries to change your daily environment and give yourself an opportunity to interact with new faces. Important things to search for are terms like “free wifi”, “study” and don’t forget, “outlets”. Yelp Foursquare TripAdvisor 3. Join Meetups Based on Personal Interests In primary school, you’re limited to befriending individuals within a few yards of where you study, in the office space, your community can be just as limited. provide you with a way to explore and discover groups who can broaden your horizons or join activities you wouldn’t otherwise try alone. Meetups I like to join hiking and board game meetups as they allow you to interact with people in different ways, versus just plain networking which does not encourage development of deep relationships during the event. Source: Running Remote 4. Enroll in Remote Working Conferences Conferences can be a powerful form of networking. Remote workers are the best candidates for long conferences because your work doesn’t have to be put on hold. is running a conference this November in Barcelona, a great prospect for fun while gaining personal growth and learning to optimize productivity. Homebase Global If you’re running a remote team, the in Bali could be for you, providing you with actionable strategies and tactics to use to scale the team. June 2019 Conference by Running Remote On the other hand, if you’re a location independent professional the in January 2019 will bring you together with like minded individuals and deliver powerful inspiration. Nomad Summit 5. Calendar Coffee & Lunch Dates with your New Network After effectively making new connections, it’s all about continuing to cultivate the relationships you’ve built with your newfound friends. As a remote worker your personal calendar might be a bit sporadic, so be sure to schedule time in advance with the people you’ve met as a way of keeping in touch and catching up. 5 Ways to Create Meaningful Relationships Online 1. Join Forums and Subreddits to Match Your Interests As social media and online chatting become common practice, more and more individuals create a virtual presence. In this way, it can become difficult to create meaningful relationships because it’s primarily based on talking at someone rather than speaking to them. Forums like , a discussion forum split into different topics, and a feed of answers to questions organized by interests, can offer ways to join communities based on your interests. Think of these forums like a club you joined in high school, where the community of people involved shared some of your common interests. These types of communities are built on conversation and feedback, so the discussion boards are filled with people who want to collaborate and share information in an impactful, positive manner rather than tear one another down. Reddit Quora Some subreddits I subscribe to are r/ , r/entrepreneur, and r/boardgames. To build better relationships, I find that responding to comments with videos is an excellent way to communicate more interactively. digitalnomad Loom It allows the person receiving the message to see your body language and facial expressions through the recordings, so there aren’t so many miscommunications — especially when it comes to tone. I have connected with many people with a “cold video” using Loom. My reply rates are 2x - 3x compared to just a cold email or DM. People are also impressed that you took time to record a custom video message for them. The whole process just makes you more human and not just a collection of words. Here is a an example of a Loom video I . wrote in response to someone on Reddit View the Loom video here 2. Join Facebook Groups based on your interest, career and location A wonderful way to connect with individuals is through networking services that allow real time interaction. One of the great benefits of Facebook is your ability to join private groups that are based on your location, job description, industry or just personal interests. The best way is to get involved with these groups is to become an admin or mod so you have the opportunity to become exposed to more people. As being a passive member gives limited access to other people in the and isn’t likely to force you to be committed in with people in the community. network building stronger relationships Some great places to start are groups for international remote workers and digital nomads including , helping you to assimilate into the world of decentralized work. Another great organization is , for workers who long to use their skills for the greater good. Remote Work and Jobs for Digital Nomads Remote Mission Organizations like these are great step in meeting like-minded people and creating relationships based on something more than the vicinity to your cubical. 3. Mingle in Social Community Apps & Organizations There are plenty of communities online that also offer in person annual meetups. Organizations like a group of over 15,000 professionals from all over the world, in various professions who are there to connect, support and offer educational resources to one another to thrive in their nomadic lifestyle. The Remote Workers Community Additionally channels like the digital nomad can be a great source for networking with other workers in similar arenas, in a space that’s much smaller than Facebook’s 2 billion users. chat on telegram 4. Look for Discord or Slack Chat Communities Slack communities are centered around common interests, and topics. You can join slack communities to enhance your skill sets, to learn from experts in your field and to make connections with individuals who share your same affinities. provides a detailed list of slack communities you can benefit from based on your field and career pursuits. Communities that revolve around topics ranging from to . And of course there are chats for more lighthearted discussions pertaining to and . Take your pick, you’ll find a community to support any of your interests. also has a great slack community to chat and connect with others. Ometrics SEO Product Development Star Wars Street Workouts Nomad List 5. Participate in Non-Profit Open Source Projects Finally a great way to connect is to contribute your skill set and time to to collaborate with others for a online. good cause This type of collaboration is purposeful and authentic, knowing that the team, individual or group you’re working with shares the same enthusiasm for solving this problem, In this fashion, you’re more likely to have higher quality social conversations. creates a deeper, more meaningful relationship. Here are some places to find online volunteer opportunities: Idealistcareers.org Volunteer Match — Virtual Volunteer Opportunities Did you like the tips and my experiences with remote working? If so please clap away! Agree or disagree with what I said? Comment below I will try to respond to every comment, and maybe with a Loom video!

WORKPATH

workpath.com

-- employees

Since n.d.

COMPANY RANKING

WORKPATH

EVERGREEN INDEX #11361

Representing this company? Click here to claim and customize this page!

Workpath WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

WORKPATH

workpath.com

-- employees

Since n.d.

COMPANY RANKING

WORKPATH

EVERGREEN INDEX #11361

RELATED COMPANIESRANK

STORIES ABOUT WORKPATH

Representing this company? Click here to claim and customize this page!

Workpath WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!