Working at IBM

Changing the dev environment to Linux

Problem

A lot of time would be spent waiting for

• your server to rebuild (5+ hours)
• Your server to restart (~10 minutes)
• Waiting for your Windows VM to unfreeze

Additionally, during the on-boarding process before I started working, I picked a Mac as my laptop. That meant that I was using a mac to work on my Windows VM. (Our server doesn't run on Mac)

Side note: I mastered switching between Mac and Windows shortcuts. 👨‍💻

Solution

Our software builds and redeploys more than twice as fast on Linux than on Windows. This means less time waiting and higher productivity.

The challenge was not only making it possible but also making the switch easy and obvious. This involved writing easy to follow documentation and automating the setup in dot files.

Automating manual processes with Puppeteer

Problem

We use IBM Web Process Designer. To develop a custom solution, the fastest way to do things involves manual steps. For example, to update your CSS file, you would typically have to

1. Download a zip folder with a specific file structure
2. Update that zip folder with your LESS file
3. Upload the zip folder
4. Refresh the page

Solution

Puppeteer is a great tool for browser automation. It's more reliable than Selenium and when you install it as an NPM package, it installs a version of Chromium that will work.

Anything that our team manually did frequently with WebPD was automated. For example, the command to update the CSS took a dozen seconds and you didn't have to break your train of thought.

One tricky thing when using oclif was being able to install directly from a GitHub URL. Our software is proprietary so I want to ensure that the tools don't leak into the public. To ensure that it worked on both Linux and Windows, I just added the JS to the repository because installing directly from GitHub seemed to have issues installing dependencies.

Human readable diffs

Problem

Our layouts are stored as minified XML files. When we make a change to the layout, we could accidentally override someone else's changes without knowing.

Solution

I created a Node.js and TypeScript CLI (with oclif) that integrated with our version control system (we use RTC instead of Git) to

1. un-minify the XML file
2. Open a tool (VSCode or Meld) to view the diff

The greatest obstacle was definitely learning how RTC worked and integrating the CLI as an external compare tool.

ESLint

Problem

ESLint is a great linter that finds and fixes problems in JavaScript. Our code style across the team wasn't consistent. Additionally, a few of our team members already used ESLint locally.

Solution

I prepared a presentation to help win over my team to use ESLint, a linting tool and added the .eslintrc to the code repository to make our code more consistent. This lead to increased productivity.

Documentation

I've written thousands of words of documentation as I've understood the product better. Our team has a consistent rotation of interns and the documentation will improve the on-boarding experience and time.

Many of the projects above were inspired to simplify the docs as well.