Back in April I installed IntelliJ on a development machine, only to encounter a show-stopper problem: it would silently crash when I launched it, shutting down without providing a useful error message.

This happened on three different laptops. All were running Ubuntu 16.04 with Trinity Desktop Environment R14.0.5. (The exact versions have changed over time.)

Since IntelliJ is a commercial product, I posted a message in their forum: IntelliJ won’t start up. The issue was not resolved, and the only workaround was to start IntelliJ with sudo. I didn’t consider that an acceptable workaround; in addition to the obvious security risks, applications that create files when run with sudo can set permissions that become a hassle when not using sudo.

So I just didn’t use IntelliJ for a number of months.

Recently I needed to run Android Studio, and found it exhibited the same behavior. I wasn’t that surprised since it’s based on IntelliJ. However I didn’t have an easy substitute.

So I revisited the problem, asking myself what else was different when run with sudo that might cause this? One possibility was environment variables. It didn’t seem that likely, but it was easy to see the differences by comparing the output of ‘env | sort’ with ‘sudo env | sort’. It turns out there were many differences; regular env has at least twice as many environment variables set. So I started unsetting them. There were so many it got tedious and I started doing them in groups. Here I finally caught a break: unsetting the GTK* environment variables allowed Android Studio to start successfully, and there were only 4 of them.

From there it was straightforward to narrow it down to one variable: GTK2_RC_FILES. With this unset, Android Studio starts up.
Here is what mine has:
GTK2_RC_FILES=/home/scorwin/.gtkrc-2.0-kde4:/home/scorwin/.trinity/share/config/gtkrc-2.0

For the record, here are the file contents. I believe the contents are the defaults unchanged from the Trinity installation.

$ cat /home/scorwin/.gtkrc-2.0-kde4
  # This file was written by TDE
  # You can edit it in the Trinity control center, under "GTK Styles and Fonts"

  include "/usr/share/themes/Qt/gtk-2.0/gtkrc"

  style "user-font"
  {
          font_name="Tahoma 10"
  }
  widget_class "*" style "user-font"

  gtk-theme-name="Qt"
  gtk-font-name="Tahoma 10"

$ cat /home/scorwin/.trinity/share/config/gtkrc-2.0
# created by TDE, Thu Oct 18 13:36:41 2018
#
# If you do not want TDE to override your GTK settings, select
# Appearance & Themes -> Colors in the Control Center and disable the checkbox
# "Apply colors to non-TDE applications"
#
#
style "default"
{
bg[NORMAL] = { 0.918, 0.914, 0.910 }
bg[SELECTED] = { 0.663, 0.820, 1.000 }
bg[INSENSITIVE] = { 0.918, 0.914, 0.910 }
bg[ACTIVE] = { 0.765, 0.761, 0.757 }
bg[PRELIGHT] = { 0.918, 0.914, 0.910 }

base[NORMAL] = { 1.000, 1.000, 1.000 }
base[SELECTED] = { 0.663, 0.820, 1.000 }
base[INSENSITIVE] = { 0.918, 0.914, 0.910 }
base[ACTIVE] = { 0.663, 0.820, 1.000 }
base[PRELIGHT] = { 0.663, 0.820, 1.000 }

text[NORMAL] = { 0.000, 0.000, 0.000 }
text[SELECTED] = { 0.012, 0.012, 0.012 }
text[INSENSITIVE] = { 0.765, 0.761, 0.757 }
text[ACTIVE] = { 0.012, 0.012, 0.012 }
text[PRELIGHT] = { 0.012, 0.012, 0.012 }

fg[NORMAL] = { 0.000, 0.000, 0.000 }
fg[SELECTED] = { 0.012, 0.012, 0.012 }
fg[INSENSITIVE] = { 0.765, 0.761, 0.757 }
fg[ACTIVE] = { 0.000, 0.000, 0.000 }
fg[PRELIGHT] = { 0.000, 0.000, 0.000 }
}

class "*" style "default"

gtk-alternative-button-order = 1

style "ToolTip"
{
bg[NORMAL] = { 1.000, 1.000, 0.863 }
base[NORMAL] = { 1.000, 1.000, 0.863 }
text[NORMAL] = { 0.000, 0.000, 0.000 }
fg[NORMAL] = { 0.000, 0.000, 0.000 }
}

widget "gtk-tooltip" style "ToolTip"
widget "gtk-tooltips" style "ToolTip"

style "MenuItem"
{
bg[PRELIGHT] = { 0.663, 0.820, 1.000 }
fg[PRELIGHT] = { 0.012, 0.012, 0.012 }
}

class "*MenuItem" style "MenuItem"

I don’t know why this environment variable causes a problem. The value and the file contents seem safe enough. Hopefully someone more familiar with the Android Studio source code will figure it out.

For now I’ve created simple scripts that let me run both programs.
Workaround script for Android Studio:

$ cat ./myStudio.sh
#!/bin/bash
unset GTK2_RC_FILES
/home/scorwin/apps/android-studio/bin/studio.sh

Workaround script for IntelliJ:

$ cat myIdea.sh
#!/bin/bash
unset GTK2_RC_FILES
/home/scorwin/apps/idea-IU-182.4505.22/bin/idea.sh

Those scripts work from the command line, and after I created menu items for them, they work from the menu too.

LibreOffice is my go-to office suite for when I need to create a document, and more importantly, when someone at work sends me a Microsoft Office file. So not having it functional is a real problem. In this case it would be running and then just suddenly crash, without a warning or a consistent pattern.

This happened on one laptop, and then after I changed jobs and set up a new laptop I found myself facing the same exact problem. There were only two obvious similarities: both times the laptop was running Ubuntu 16.04, and every time there was no useful information after the crash.

Eventually I was able to narrow it down: it only happens when running Ubuntu and using the Trinity desktop. The crashes happen randomly during normal usage, however there are two ways to consistently reproduce them:
1. Start up LibreOffice Calc or LibreOffice Writer or LibreOffice (plain)
2. Go to Tools -> Options -> LibreOffice -> view
Or:
2. Go to Tools -> Customize
Either way, as soon as I click on the menu item, poof! It’s gone. And I could not find any logs or dump files. I tried starting LibreOffice from the command line, so that I could see what it wrote to stderr, but the only message I ever got was “X IO Error”. My google-fu is reasonably good, but with a message that short I never found anything helpful.

Versions of of LibreOffice I tried:

• 5.1.6.2
• 5.4.7.2 (using the AppImage file)
• 6.0.4.2 (using the AppImage file)

Since searching for the error message wasn’t getting me anywhere, I decided to build from source. That way I would be able to enable debug support and hopefully get a more informative error message. The only thing was, after I built from source, LibreOffice no longer crashed.

So I have no fix, but a successful workaround: just build from source. To do the build I just followed the instructions. I’m not sure I even got debugging turned on. This has worked on two different models of Dell laptop, both running Ubuntu 16.04 and Trinity.

The site I’m working on uses React for most of its UI. We experienced a strange problem: if the build was done Linux (or OSX for that matter), when the user clicked on one of their tasks the task wasn’t displayed. Investigation found a JavaScript TypeError “inst.render is not a function” in the browser’s console. However if the build was done on Windows then clicking on a task worked fine. To make it even more puzzling, the site was running on a Linux server.

The build process for the UI deals with React, ES6, JavaScript, gulp, webpack, and babel. But the root cause was not any of these – instead, it was that webpack was configured to use the minor component bundle-loader.
Bundle-loader’s purpose is to split the transpiled and assembled JavaScript into smaller files. In this case it was creating two separate files:

dist/scripts/app.js
dist/0.scripts/app.js

On Windows for some reason this didn’t happen – the build would only produce dist/scripts/app.js.

Now, in order to use the dist/0.scripts/app.js file, you would need some JavaScript to load from that file. We didn’t have any. So the silent failure of the build on Windows compensated for the missing code to load from dist/0.scripts/app.js and it all worked fine. But when we built on a *nix operating system bundle-loader worked correctly, exposing the lack of the loader code. The code for some components was not loaded because it was in the second app.js, which is why there wasn’t a render function.

In case you’re wondering, my initial fix was just to remove the use of bundle-loader. Subdividing the JavaScript for all builds will have to wait for another day.

These are some troubleshooting tips based on what I’ve picked up after a couple of rounds of using the API Gateway to create RESTful endpoints for Lambda nanofunctions.

1. Redeploy your API. This probably needs to be done to make changes visible if you’re testing with curl or a browser, and it has resolved some mysterious issues.

2. If you’re seeing permission issues such as “Execution failed due to configuration error: Invalid permissions on Lambda function”, the thread at https://forums.aws.amazon.com/thread.jspa?messageID=800375 has a number of potential fixes to try.

What worked for me was re-selecting my Lambda, so that the permission was set automagically on the second try. To do this go to the API Gateway web UI and click on Integration Request. In the Lambda Function field delete the current value, then choose the same one as before. Be sure to click the little down arrow, or maybe it’s a checkmark, next to the lambda name. When I did this it brought up a popup I had not seen before:

Add Permission to Lambda Function
You are about to give API Gateway permission to invoke your Lambda function:
arn:aws:lambda:us-east-1:723707654321:function:FetchZipCodeLambda

I happily told it to give permission, and the error went away.

3. If you don’t have any error messages, configure logging for the API Gateway, which is off by default. Follow the directions at https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-cloudwatch-logs/ carefully, except always redeploy your API afterwards.

The logs are in AWS CloudWatch. Go the web UI and in Log Groups look for a group where the name starts with “API-Gateway-Execution-Logs”. Then look for Log Streams with a Last Event Time, which should have useful information. If you don’t see any try hitting your endpoint a few times, then check again.

4. When in doubt, redeploy your API and try again.

Normally this blog is focused on software development – sometimes big ideas, sometimes small tips based on things I’ve learned recently. This post is different – it’s about about one of the things that kept me from writing either sort of post.

The Belkin KVM I’ve had for a number of years developed a habit of suddenly going nuts. Without warning it would start changing which monitor was connected, rebooting itself repeatedly, or just turning itself off. Wiggling the power cord didn’t do much but wiggling the power plug did, and the power socket seemed a bit loose. So I decided to open it up to see if there was a questionable solder joint to the power socket.

That’s when the fun began.

The case does not have any visible screws, so I figured it must be held together with snaps. I hate snaps because the sound of a snap opening normally and the sound of a snap breaking off are almost the same.

I pried open both sides but the middle of the case didn’t want to open up. I had previously checked under one of the rubber feet, since screws are often hidden there, and not found any. But then I realized I had checked under a back foot, but what about a front foot? Sure enough, there are screws hidden under both front feet.

With those screws remove the sides were loose but the middle was still holding tight. There’s an area on the bottom that I had thought was a molded feature, but it could be a label that matched the case. So with nothing to lose I started at a corner, and sure enough it was a label. Prying it up revealed 2 more screws on the right-hand end, and by symmetry there were two more near the left-hand end. The middle still held, until prying the label up further revealed another screw in the very middle.

So there are a total of 7 screws and 7 snaps. Why, Belkin, why? It’s not like anyone looks at the bottom of a KVM when it’s sitting on a desk. And the bottom has a serial number sticker and a “QC passed” sticker that aren’t attractive.

Here’s a view of the bottom, showing the label with 3 of the screws underneath it. The other two are in matching locations on the right. This view also shows the screw from under one of the front feet.

This view shows the inside once the bottom cover is finally removed. You can also see one of the plastic snaps at the left end. You would see two, but that snap didn’t survive. Oh well, 6 out of 7 isn’t too bad…

This view shows the inside after removing the bottom circuit board to work on it. This is as far as I went.

I had hoped to install resistors in series with the LEDs so they wouldn’t be so annoyingly bright, but the LEDs are soldered straight to the front circuit board. I didn’t want to get into cutting traces.

After removing the bottom circuit board I heated the connections to the power socket and flowed more solder in. I did the same for the two inductor/choke components next to it. After a week of daily use I’m happy to report no more problems.

winpty is a simple-to-use utility that can be a lifesaver when you need it.
For example, if you need to run the Heroku CLI in Git Bash on Windows, you’ll get an error when you try to log in:
$ heroku.exe login
[snip]
! Login is currently incompatible with git bash/Cygwin/MinGW
If this happens, just start your command with winpty:

$ winpty heroku.exe login

and it will prompt for a password and allow you to log in.

Another example: I needed to export a PostgreSQL database, but pg_dump would just hang. It never prompted for a password (or did anything else). After starting the command with winpty:

$ winpty pg_dump --schema-only [many other pg_dump options]

It immediately prompted for a password and then completed in less than a minute.

I recently changed jobs, and this caused me to reflect on the motivations for changing companies. For engineers, and I suspect for many people, the easier it is to leave a job, the easier it is to stay. If your skills are staying up to date and marketable, and you’re comfortable that you could find another job if you needed to, then there is little risk staying where you are and seeing how it plays out. Even if there was a layoff with no warning, you could find another job.

If your skills aren’t staying up to date and marketable, then you start to worry about how you would bounce back if something unexpected did happen. This leads to listening to recruiters and looking around for a new position where your skills will stay marketable.

So if companies want to keep good employees around, the answer is somewhat counter-intuitive: you need to invest in actions which will make your people attractive to other companies, so that they don’t feel they have to leave while they still can.

In March I did a presentation for the San Diego Java User’s Group entitled “Blow up the monolith? Serverless computing, nanofunctions, & Amazon Lambda”, built in part upon my Nanofunctions post.

The presentation video is up on YouTube, in two parts: Part 1 Part 2. The slides are here.

It’s pretty cool to be standing there having people ask your opinions on topics related to your presentation.  If only it was easier to get to that point…

Recently I’ve been using the using Azure CLI 1.0, which is written with JavaScript and Node.js. I have to say I had no trouble installing it on Debian 8.

I’ve used it for a variety of tasks, including creating public IPs, network security groups, virtual NICs, VMs, and rules with network security groups. Most frequently for starting VMs since we use the auto-shutdown feature on our development VMs.

When using it I keep getting the following error when I’m on the corporate network and need to use an HTTP proxy to get to servers outside:

  ApplicationInsights:Sender [ { Error: getaddrinfo ENOTFOUND dc.services.visualstudio.com dc.services.visualstudio.com:443
    at errnoException (dns.js:28:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:76:26)
    code: 'ENOTFOUND',
    errno: 'ENOTFOUND',
    syscall: 'getaddrinfo',
    hostname: 'dc.services.visualstudio.com',
    host: 'dc.services.visualstudio.com',
    port: 443 } ]

I’m not sure why this error occurs since I have the proxy config set up and other things are working. But getting it hasn’t stopped me from doing anything I wanted to do, so I now consider it safe to ignore.

There are many vi references and cheat sheets, usually formatted as lists or groupings of keystrokes followed by what each one does.  I created this one for myself because I needed more of a cookbook, where I can scan through it looking for a match for what I need to do and then it shows me the needed the keystroke(s).

If you’re new to vi, remember :q!

Get out of insert mode – Esc

Move left – h
Move right – l
Move up – k
Move down – j

Switch to input mode just after the cursor position – a
Jump to end of line, then switch to input mode – A
Insert a blank line below the current line, then switch to input mode – o

Move to top of file – gg
Move to bottom of file – G
Move to beginning of line – 0 (zero)
Move to end of line – $

Delete character under cursor (delete) – x
Delete character to left of cursor (backspace) – X
Delete all characters to right of cursor, then switch to input mode – C
Join the line below to this line, inserting a space between – J

Delete current line – dd
Copy current line – yy
Paste – p

Search for string – /string
* search commands work like in less

Search and replace – :%s/<pattern>/<replacement>/<flags> where <flags> is blank or “c” for request confirmation

Undo last change – u
Undo all changes to current line – U

Turn on the line at the bottom which shows when you’re in Insert mode – :set showmode

Save changes – :w
Quit, checking for unsaved changes – :q
Get the heck out, leaving the file unchanged/undamaged – :q!

A much more comprehensive vi cheat sheet