VS Code Is The Full Stack IDE For IBM i

March 15, 2023 Jeff Tickner

Back in January, we talked a bit about the rise of the VS Code integrated development environment that was open sourced by Microsoft back in 2015 and that has been increasingly adopted by developers on all kinds of platforms, not just Windows Server. This week, we want to talk about the new features we are exposing in VS Code for users of the application development tooling available from ARCAD Software.

First of all, we have brought the cross reference information in our ARCAD Observer tool into VS Code in a way that developers can access the object-level and field-level relationships directly in the code while they have their source code open. We call this a “code lens,” which is a term used in the VS Code tools, and with it they can see the relationships between objects or fields, and many other useful tips such as file declarations, procedure usage, procedure declarations, and more.

ARCAD for DevOps (VS Code interface) – Procedure declaration “code lens”

For example, if I’m using a table in a program, in the code itself from inside the editor I can drill in and see the information about that table and see what else it uses and see what other fields are there. So, I have complete transparency to all of the objects around me. And that’s based on the ARCAD metadata repository.

This repository is at the core of all of our tools, and building on top of this metadata repository is one of the things that makes the ARCAD stack different. It is a very powerful distinction. For instance, we have a new personal build feature that is in VS Code, and when developers are done working on their code and they want to build their changes, the build uses that metadata repository to manage all of the dependencies automatically. And to make that build function as easy to use as possible, we actually create all of the infrastructure behind the scenes automatically. And what that means is, unlike other build tools that are available, where I have to do a lot of configuration for the build to work, when I start a project using ARCAD plus VS Code, I automatically get all of the build infrastructure automatically on the target server.

On the development server, I get a library for the results of the build a unique place that I can use for my personal build. If my code isn’t quite ready for primetime, I’m not bothering anybody else. So it’s a classic use of the sandbox concept from Git. But I don’t have to do any work to set this up – ARCAD is doing that for me, all automatically.

And when I am ready to share my changes to the code – after I have done my unit testing in my personal build library – I can then push my changes or merge my changes forward into a common branch that other people are working on. And then another build happens automatically. And now other folks can see my changes integrated with their changes. So it’s a very efficient way for the developer to work in Git.

We are focused on VS Code in this discussion, but that integration with Git that we provide means that I can have developers working from VS Code working along with developers using other interfaces such as Rational Developer for i (RDi) or even in greenscreen 5250, all on the same project, all working on our own separate branches of the application code. We merge into a common branch and sharing our work there. Developers can work in the interface they are comfortable with, and ARCAD’s Git integration allows for very easy collaboration and integration.

ARCAD started in the greenscreen world more than 30 years ago, and we were a greenscreen company first. And then came Rational Developer for i, and nine years ago we introduced integration with source control. We have been able to support VS Code through the Git management for a while, but now we are exposing our functions into VS Code.

Because of that integration, we have also exposed the structure of the project management system in VS code as well. What that means is that I can see the results of my build, of course, but I can also see what other people are working on. Even if different developers are working in different tools, I can go out and see the results of those projects being coded using other tools. I don’t have to leave VS Code to do that. I can just go down into my navigation view and see what my coworker is working on and what they are changing in the code.

We have been offering concurrent development for IBM i shops for a while. But when we started working with source control almost ten years ago, that’s when we got our hands on better tools for concurrent development. In traditional change management, there’s always been some support for concurrent development. But there’s always the danger of overwriting someone else’s changes. If somebody else is working on this, you should merge your changes in. But it’s never known if you did or not, because it’s not managing down at the line – and Git manages at the line. It knows if you merge those changes in it. So with concurrent development, I’m not going to overwrite someone else’s changes, I’m going to merge the changes in so we get no overwrite. And the way we normally are configured, as soon as I say, I want to integrate my changes with somebody else’s, we’re going to automatically compile that.

The first threshold for all application development after you make changes is: Will this compile? The first thing the ARCAD tools do is to compile code and find out if it works. And because it compiles, the result of the build is automatically shoved into the testing environment. It is always put into a unique build library for that branch. You can use our unit testing tool, which can automatically unit test, or you can go to that build library and do your own unit testing. After that, you can promote into quality assurance and find out if it really works by doing some functional testing.

ARCAD for DevOps toolstack on IBM i

So we have a potential here for very efficient development on the IBM i platform through VS Code and the ARCAD stack. But one of the challenges we run into with our customers is we offer them continuous integration and continuous deployment, which leverages all of this automation. But a lot of them don’t use this automation because they’ve been burned in the past. They’ve had people dump crud into QA and break everybody else’s testing.

The automatic unit testing and automatic peer review from the ARCAD stack is very powerful, and one of the other things that we brought to VS Code is our Code Checker tool. Code Checker is essentially a code parser, where I can apply rules. And so I can go and look for techniques or functions that I don’t want my developers to use. I can look for security problems, like a very open ended use of SQL that is a potential security issue. If the programmers is passing around an SQL command as a parameter, that’s a security problem because I could then call that program with my own SQL string, and have it do things it shouldn’t.

One of the things that we want to mention is that the functionality extension from ARCAD into VS Code is an offshoot of our adding our functionality to Merlin, which is IBM’s cloud-based IDE for IBM i development. We can think of VS Code as kind of a local version of Merlin. As we provide our functionality to IBM for the Merlin tool –when you buy Merlin from IBM, you’re buying the ARCAD build process and the Transformer for RPG, the modernization of RPG, and so on. And so they’re driving us to add more functionality. And when we add it to Merlin, 99 percent of the time that functionality will be ready for VS Code.

VS Code has to be managed locally on the developer’s workstation. The code is local. And that actually has been a sticking point for some customers that don’t want the folks offshore to have all the code locally. They would prefer that it remain on the server. Somebody has to install VS Code and manage it locally, and when I want to work on the code, I pull all the code down to my workstation. And Merlin is purely cloud based. The code doesn’t go anywhere. That’s why people want Merlin: Because they don’t want to manage the workstations of people offshore. Or they want Merlin because they have lots of users – we have customers with literally thousands of developers and it is a real pain to manage an IDE across thousands of workstations.

But for most IBM i shops, these are not the issues. Flexibility is. If I am controlling VS Code locally, I can extend VS Code myself. It already has a Java editor and now I can have a PHP editor and I can extend it out for other languages that VS Code supports. So that’s the beauty of VS Code: People have built all of these extensions, like Code for IBM i, and you can pick and choose as you need to.

As such, VS Code is a tool for a full stack developer. And if part of your stack is on the IBM i platform, now you can work directly in VS Code on that full stack. VS Code is the true full stack tool for IBM i shops.

To find out more, see: [IBM i Webinar] Roundtable Webinar series, Demystifying DevOps on IBM i

Jeff Tickner is chief technology officer for North America at ARCAD Software.

This content is sponsored by ARCAD Software.

This Issue Sponsored By

Table of Contents

Content archive

Recent Posts

Subscribe

Pages

Search