The best kittens, technology, and video games blog in the world.

Friday, March 16, 2018

Visual Studio Code first impressions

le petit chat by FranekN from flickr (CC-NC-ND)

This is a first impressions post, so not representative of editor in any serious use. Maybe it gets a lot better, maybe it gets a lot worse.

It's very important to try a lot of technologies, even if in the end, they don't matter at all. For example zsh has about one feature (multiline copy&paste support) which properly configured bash doesn't, so it's not enough to recommend it to anyone, but I kept using it after the trial.

Research stage

I tried searching the internet to figure out what's the difference between VSCode and Atom, and nobody has any good answers. Most of them were of "I already use Atom package for that" variety, or claims about performance. Atom isn't super fast, but it got a lot better since its early days. Or maybe computers got a lot faster.

Getting started

First check - Cmd-D multiple cursor selection works. OK, I might be able to use it. Any editor without it doesn't deserve a serious look. And just in case, some quick editing shortcut check - nothing is too crazy.

Second check - how do I add it to $PATH... I thought it would be in settings, but nope. Settings page wasn't very intuitive, but it actually makes a lot of sense once I got through the unusual interface. Well, this wasn't there.

I had to google that, and there were like a million irrelevant and highly convoluted answers. It turns out that correct answer is to turn on command palette with Shift-Cmd-P, and choose "Install 'code' command in PATH". Someone please tell Stack Overflow about that, it has ridiculous answers from 2015.

By the way, that's a common problem with Stack Overflow - the best answer from a few years back might be a pretty questionable today as yesterday's problems get addressed in new versions - but the answer never gets fixed, and anybody who dares ask again will get it closed as a duplicate and banned from Stack Overflow for life or something.

Maybe there should be a way to "flag as no longer best practice" or whatever.

Switching Tabs

So I opened a toy ruby repo, typed some code, and the level of git integration was pretty sweet. Staging chunks from within editor, that's definitely a nice feature.

Then I opened a second tab, and my first impressions went from 5 stars to 3 stars. Standard tab switching shortcuts like Cmd-1 Ctrl+PageDown etc. just don't work.

All right, checking the annoyingly named Extension "Marketplace", there's "Atom Keymap", that fixed it.

RSpec runner

I normally split the big screen between iTerm2 on the left and Atom on the right, so I don't usually care for in-editor runners. But sometimes I have to code on just unconnected laptop, and then it's a bit awkward.

I've heard some rumors that VSCode is good with in-editor test runner and terminal, so I checked if there's any RSpec runner. After a few tries I found "Rails Run Specs", which works for pure Ruby project, kinda.

When I right click on spec file from the file list on left sidebar, I can run the specs. But when I try to do so from command palette it just gives me "running the contributed command failed" message.

To be fair, I haven't actually checked if Atom does it any better.

So far it seems about the same

For now VSCode looks pretty much like Atom with fewer plugins. I don't actively hate it, the way I quickly hated RubyMine, Android Studio, IntelliJ IDEA, Eclipse, and a lot of such crap which never bothered to get basic usability right and just piled features on top of a really shitty base editor.

The base of VSCode is just fine. I'm just not really seeing what's the big benefit yet, but I could see using it for a bit to maybe find some.

Saturday, March 03, 2018

Volume slider's 100% limit is a massive usability failure

Headphone Kitty by Super Formosa from flickr (CC-SA)

We live in a world where all software sucks. I'm not talking about edge cases of some rarely used functionality, or compromises made for sake of backwards compatibility, or due to greed or other external constraints - we don't even get the basics right when nothing stops us.

This one is especially egregious because it affects almost all software.

Here's the problem - volume slider only going up to whatever the software considers "100%"

100% is a lie

100% means nothing. What's meaningful in audio is relative amplitude of various segments. All those ups and downs thousands of times per second are what makes the sound.

The same sound can be played at any volume you want, and it will sound just fine.

For technical reasons audio files, and that's true for both analog and digital, can be "louder" or "quieter". Does this level mean anything? No at all. The happenstance that a certain file goes from -1000 to +1000 or from -2000 to +2000 means absolutely nothing wrt best loudness to play it at.

What happened is that software decided that 1000 corresponds to some loudness at "100% volume", 2000 corresponds to some different higher loudness, and you can't do anything about it. Oh sure, you can make it quieter, but that's all.

Software doesn't even know how that 1000 translates to in any human units. It just sends some voltages to the speakers, and lets the speakers figure it out.

This usability failure was sort of tolerable back in the desktop era, because most desktop speakers have far more power than you'd normally use, so if you normally listen at 30%, then you can just bump it to 60% if software failure sends something particularly quiet to the speakers.

Unfortunately this is not true for shitty laptop speakers or shitty portable earphones. "100%" volume, very low power, and quiet audio, and it's barely possible to hear anything. Then add a crowded train to the mix...

Hall of Shame

  • Apple - 100% guilty
  • Windows - 100% guilty
  • Android - 100% guilty
  • Youtube - guilty (they at least apply server-side audio normalization for music videos, so they're less affected, but all other content has this problem)
  • VLC - desktop version amazingly goes to 200%, but mobile version (which needs it a lot more) just as guilty anyway

Dynamic range adjustment

For a bonus related failure, there's a problem of dynamic range. Movie tend to have much louder (usually action) and much quieter (usually dialogue) parts - which is perfectly fine when watching in otherwise quiet cinema.

Unfortunately at home your choices are:
  • only watch with headphones, alone
  • adjust volume up and down a lot
  • watch it at high volume so you can actually hear the dialogue, and screw the neighbours
  • watch it at low volume so you your neighbours don't complain during action sections, and use subtitles to not miss anything in the the dialogue
  • have software which flattens dynamic range to more reasonable values
At least in this case the excuse is that this kind of adjustment is not quite as trivial as bumping the volume to 100%.