This is part 2 of a three-part blog series explaining how I wrote some code to control the basic features of a DJI Ryze Tello drone. I set myself this challenge ahead of a hackathon event held at our offices in Swansea, UK. In part 1 I explained how to connect to the drone and send commands to it to enable the drone to do tasks such as take off and land. You can read part 1 here. Below I take things one step forward allowing you to fly the drone in various directions.
Getting the drone to move in a specified direction is a very similar process to what we have already done but with one slight difference. The directional commands “left”, “right”, “forward” and “back” for the drone each allow an integer to be specified after the command, the integer is how many centimetres the drone will move in the specified direction.
First, we need to refactor our handleInput function a little, as we will now be sending a value from 20 to 200 after some of our commands, writing a select to handle each and every possible combination we could send is a bad idea. Instead, we will use the string.startsWith method to check that our line starts with a keyword such as “forward” or “left” and then take the amount from the end of the line using string.split.
Unfortunately, we can’t just add a boolean expression case to our switch due to the way switch works. In short, this is because it uses the strict equality operator (===) to check the value of the argument against whatever is on the right-hand side of the case keyword, this means no functions or boolean expressions will be evaluated.
Our way around this slight blocker is to go back to a good old if statement. First, let’s cater for the functionality that we already have. What I like to do here is to create simple functions that encapsulate the boolean logic that we can re-use, so I created functions like below:
The functions take in the line, and will simply return either true or false depending on how the boolean expression is evaluated.
We can then create a series of if statements using these functions and use them to execute our sendTakeoff and sendLand functions like below:
Once that refactoring is done the handleInput function should look something like this
I’ve declared the isTakeoff and isLand functions within the scope of handleInput just for the sake of keeping everything together.
Now we can create a function to detect when we are sending a forward command to the drone. We can create our sendForward function, this will be very similar to our sendTakeoff and sendLand functions that we created earlier, but this time we will add a distance parameter with a default value of 20. This is so that if a user neglects to send the command with a distance value, we can safely default it to the lowest value possible and still send a valid command to the drone.
Finally, we can add our if statement:
Although it doesn’t look like much is going on here in terms of lines of code, there are two very important things happening. First, we are calling strings split method on our line, this function will split a string up into sections wherever a specified token is present. As we are splitting by a single white-space, and our line should be in the format like below:
The word “forward”, followed by a single white-space and then an integer. For example “forward 20”.
This split function will return us an array with two elements inside like this: [“forward”,”20”].
As you can see from the example, the first element, in the 0 position of the array, will be “forward” and the second element, in the 1st position will be “20”. We are then using array de-structuring here to assign the first element in the array to the variable name and the second element in the array to the variable dist. The rest is simple, we then call our sendForwardfunction with the socket and dist as arguments. The command should then be sent to the drone.
Let’s give it a shot, fire up the application using:
> node ./src/app.js
Once we are up and running, issue the “takeoff” command to the drone. Once the take off sequence is complete we can then instruct the drone to move forward by issuing a command like below:
> forward 20
We should then see the drone move in a forward direction.
To add the other directions we can just repeat the above steps, but instead of sending “forward” we just need to send either “back”, “left” or “right”.
The output you should see in the terminal:
A nice way to expand this would be to create some form of UI that’s not the command line because let’s be fair, typing commands is hardly practical. Perhaps taking the basic concepts I’ve touched on here and wrapping them in some form of Electron or React/Vue/Angular app. Even getting the stream of data that’s available from the drone and creating some sort of visualizations from it would be an interesting coding challenge. I will explore some of these in part 3.
All of the code I’ve written here (and some extras) can be found in my GitHub https://github.com/csscottc/drone-ctrl – Feel free to check it out and use it however you see fit. Part 1 of this blog series can be found here.
In part 3 I will explain how to build a simple UI that will complete the original task of allowing a non-coder the ability to control the drone.
By now, it has become an annual tradition at Gofore to conduct a Project Radar survey at some point of the year to gain better insight into our presently running software projects. The 2018 Gofore Project Radar builds on two previous Project Radar iterations, conducted in fall 2016 (in Finnish only) and spring 2017, containing a set of questions relating to currently employed tech stacks, development practices and projected (or hoped-for) technological changes. Most of the questions from last year’s Project Radar made their way into this year’s Project Radar to allow for year-on-year variation detection. We also added some new questions that were considered important enough to warrant their inclusion in the survey.
So with the 2018 Project Radar results in, what can we tell about our projects’ technological landscape? What can we say has changed in our technological preferences and project realities over the past year?
The Gofore Project Radar survey results for 2018 are in! [Click on the image to enlarge it].
Over the past few years, the frontend development scene has shown intermittent signs of “framework fatigue” as a steady stream of new frameworks, libraries and tools has flooded the scene, challenging developers to work hard to keep pace with the latest developments, current community preferences and best practices. A look at our Project Radar data tells us that at Gofore there has been no significant churn when it comes to primary frontend technologies employed by individual projects. Instead, the results indicate a distinct consolidation around React, Angular and Vue.js, the three major contenders in the JS framework race. All these three have gained ground on older frontend techs (AngularJS, jQuery etc.) and ratcheted up their project adoption percentage, React being the top dog at a near-50% adoption rate among projects represented in the survey. If given a chance to completely rewrite their project’s frontend, most respondents would, however, pick Vue.js for the job.
The fact that there was no major change from last year in preferred frontend frameworks is perfectly in line with developments (or lack thereof) on the frontend scene over the past year. While last year saw major releases of both React and Angular roll out (with Vue.js 3.0 still somewhere on the horizon), there were no new frameworks to come along that would have been able to upset the status quo and catch on big time in the community (regardless of distinct upticks of interest in at least Svelte.js and Preact). This stability comes in stark contrast to the unsettled years in the not-too-distant past when the balance of power between different JS frameworks was constantly shifting as new frameworks and libraries appeared on the scene.
Looking beyond the battle of JS frameworks, a significant trend with regard to frontend development is the ever-increasing share of single-page applications among our projects’ frontends. Around 64% of this year’s Project Radar respondents reported to be working with single-page applications, up from 57% in last year’s Project Radar results.
Node.js on the rise
Moving our focus to the backend, where Java has traditionally held a predominant position among our projects, a somewhat different trend emerges. While the Project Radar data clearly brought out a tendency toward consolidation around the three major frontend frameworks, the picture on the backend side, on the other hand, looks a little more fragmented. Last year’s Gofore Project Radar pegged Java usage at nearly 50% among all projects represented in the survey, trailed by Node.js and C# each with a 15% share of the cake. While Java still came out on top this year, it was reported as the primary backend language in only 32% of the projects, down a whopping 15 points from last year’s results.
This drop was fully matched by an upward surge by Node.js, which more than doubled its share of the overall pie, up 17 points from last year. While C# stood its ground at close to 15%, a crop of new languages, missing from previous years’ results, entered the fray in the from of Kotlin, Clojure and TypeScript. Regardless of there being only a handful of projects where they were reported as being primary backend languages, they contributed to the growing share of minority languages in our backend landscape, a group previously comprised of Scala, Python, Ruby and PHP.
Similarly to how respondents were asked to choose their hoped-for replacement tech for their frontends, we also asked our developers what was their preferred language for rewriting their backends if given the chance to do so. Last year most respondents would take the cautious approach and stick with their previously established backend languages. This year, however, there was considerable interest in rewriting backends in Kotlin, particularly among respondents who reported Java as their primary backend language (55% of all respondents were eager to switch to Kotlin from some other language).
Before drawing any conclusions from these statistics, it should be noted that upwards of 55% of respondents reported to be working with a microservices-type backend stack, suggesting that potentially multiple languages and server-side frameworks might be used within a single project. Still, the appeal of Kotlin, particularly among Java developers, is clearly apparent, as is the shift toward Node.js being the centerpiece of most of our backend stacks.
The popularity of Kotlin, on the other hand, has been picking up ever since Google enshrined it as a fully supported language for Android development. Considering its status as one of the fastest-growing programming languages in the world, its increasing presence in server environments is hardly surprising.
Now where do we run our project infrastructure in the year 2018? According to last year’s Project Radar results, more than two thirds (68%) of all respondents were still running their production code in a data center that was managed either by the client or a third party. This year, that number had come down to 59%. While this isn’t particularly surprising, what is mildly surprising, though, is the fact that IaaS-type infrastructure saw an even greater decline in utilization. Only 47% of all respondents reported to be running their production code in an IaaS (Infrastructure as a Service) environment, as opposed to 60% last year.
As the utilization of both traditional data center environments and IaaS services fell off, PaaS (Platform as a Service) and, especially, serverless (or FaaS, Function as a Service) platforms were reported to take up a fair portion of the overall share of production environments. While still in the minority, PaaS services were reported to be used by 12% of all respondents, tripling their share of 4% from last year, and serverless platforms by 16.5% of all respondents (no reported usage last year as there was no dedicated response option for it).
As our projects’ production code is more and more removed from the actual hardware running it, containerization has also become more commonplace, as evidenced by the fact that Docker is now being used by 76% of all respondents (up from 43% last year). Despite Docker’s increasing adoption rate, there wasn’t much reported use for the most popular heavy-duty container orchestration platforms: Kubernetes, Docker Swarm, Amazon Elastic Container Service and OpenShift Container Platform were only reported to be used by 14% of all respondents.
Since running our code in cloud environments enables shorter deployment intervals, one could think we’d be spending more time flipping that CI switch that kicks off production deployment. And to some extent, we do: we have fewer projects where production deployments occur only once a month or less often (10% as opposed to 20% last year), but, somewhat surprisingly, fewer projects where production deployments are done on a daily basis (10.5% vs 12% last year).
- Key-value databases doubled their reported project adoption (32% vs 16.5% last year)
- Jenkins was the most prevalent CI platform among represented projects, with a 57% adoption rate (its closest competitor, Visual Studio Team Services/Azure DevOps well behind at 17%)
- Close to nine percent of all respondents reported to be using a headless CMS (Content Management System)
- Ansible was being used by 71% of respondents who reported using some configuration management (CM) tool, clear ahead of any other CM tools (Chef was being used by a little shy of eight percent of CM tool users, while Puppet had no reported users)
- Development team sizes were smaller than last year (57% of dev teams had five or more team members last year, whereas this year such team sizes were reported by 52% of respondents)
- The reported number of multi-vendor teams was smaller than last year (41% vs 47% last year)
- Most respondents reported to be working on a project that had been running 1-3 years at the time of responding
- Most project codebases clock in at 10k – 100k in terms of LOC (lines of code)
- Scrum was the most favored project methodology, being employed by nearly 51% of all represented projects. Kanban, on the other hand, saw the most growth of any methodology (22% vs 12% last year)
Some closing thoughts
Once again, the annual Project Radar has told us a great deal about our preferred programming languages, frameworks, tooling and various other aspects of software development at Gofore. While the survey is by no means perfect – and I can easily come up with heaps of improvement ideas for the next iteration – the breakdown of its results enables us to more easily pick up technological trends in our ever-increasing multitude of projects. This year’s key takeaways are mostly reflections of industry trends at large, but there are some curiosities that would be hard, if not impossible, to spot if not for the Project Radar. The usefulness of these findings is debatable, as some of them fall under trivia, but still they come as close to a “look in the mirror”, technology-wise, as one can get at a rapidly growing company of this size.