Lorenzo Villani

(╯°□°)╯︵ ┻━┻

Quick'n'Dirty Atom Review

Sep 6, 2015

Last month I tried Atom.

I liked it.

Now I’m back to Sublime Text.

The story began a couple of months ago, when a colleague that shall remain nameless convinced me to try Atom, a new text editor from GitHub.

I wasn’t sure I would like it so I promised to use it exclusively for a full month right after its first 1.0 release, whenever that would happen. When it finally came out at the end of June, I knew that I was in for a great deal of radiations.

Bad jokes aside, I was immediately struck by its insane slowness.

For a text editor, it really takes a long time to launch! Almost as long as my fully loaded Emacs setup. To make a comparison: Sublime Text 3 starts in around 0.70 seconds and is immediately usable, with 43 installed plug-ins. Atom, on the other hand, needs around 3.28 seconds with no plug-ins, and this is only after I warmed it up a couple of times already. The first time it took around 6 seconds. The more plug-ins you install, the worse it gets.

This negatively impacts my work-flow. I keep one long-lived editor instance for the project I am working on and then I tend to fire many short-lived windows as I browse around the file system doing some one-off editing tasks. During my trial I simply began using Vim alongside Atom, even though I’d rather avoid the context switch between editors.

Additionally, there is a persistent lag that permeates the entirety of the GUI, something that is barely perceptible and hard to describe. You can compare it to the difference in touch responsiveness between iOS and Android: both are acceptable but you can feel that there’s something slightly amiss with the latter.

Aside from its slowness, and the fact that it eats RAM like an IDE, Atom is really a nice text editor. It looks great by default, has modern keyboard shortcuts clearly inspired by Sublime Text, has a vibrant development community working on its core and, last but not least, a growing set of third party packages.

Since Atom is built on a browser engine it is able to provide, for example, live Markdown previews directly in the editor, something I appreciate very much since I write almost all text documents, including documentation, with it.

Markdown Preview

It is also one of the few editors with a built-in package manager that doesn’t suck. It allows to search, view the most popular packages and its README file directly from the GUI. It can also be used from the command line and it has some nice tricks up its sleeve: since I have an account, I can “star” the packages I use the most and quickly re-install them by running apm stars --install --user lvillani. I can install other user’s packages this way, too.

Package Manager

The settings screen reminds me of Emacs’ “Customize” mode, which shows package configuration knobs in a GUI, so that I don’t have to fiddle with elisp/JSON/whatever configuration files by hand.

Also, it’s open source software. I believe the world sorely needs a strong contender to Sublime Text which isn’t proprietary and developed by a secretive developer that has a tendency to disappear without trace for months, leaving people to question whether their investment in a commercial text editor was worthy of their time and money.

Given the way Sublime Text is being developed, I long for a text editor where community feedback is taken seriously and bugs get fixed.

Atom seems to be what I want Emacs to be 1: an editor that’s extensible, mode-less and actively developed even though it is, sadly, just as heavy.

  1. Sans HTML, CSS and JavaScript. 

Getting started with Podcasting

Aug 5, 2015

Podcasting is all the rage in 2015, with new shows popping up everywhere.

Since I am a newcomer to the podcasting world I have four objectives in mind: have the podcast sound nice, be practical to record, require a minimal amount of editing, and don’t break the bank in the process.

What follows is my current setup. Getting everything will cost you around 200€ in total, excluding the laptop and other ancillary hardware that you might already have anyway. You could certainly achieve the same results by spending less, but I didn’t want to waste too much time finding the ultimate “el cheapo” setup: everything in here is more or less tried and true by people with way more experience than me.

Equipment

To get started, you will only need a decent microphone and a pop filter:

  • The Blue Yeti is a decent condenser microphone with multiple pickup patterns, a gain control, a nice metallic stand, mute button, audio out and volume control. Some of my favorite podcasters have been using it for a long time.
  • A pop filter to soften plosive sounds. These are usually very cheap (around 10€) and you can even build one yourself with used socks.
  • A decent set of monitor headphones that you must wear while recording, you don’t want sound to come out of your speakers. I use a pair of Sennheiser HD202.

On top of that I added a shock mount and a second-hand NEEWER boom arm to physically remove the microphone from the desk and have it float out of the way when not in use. The shock mount prevents the “bumps” that I would get when I move the mic around 1. You can get both of them for around 50€ or less.

Software

I prefer to record over Skype since it has passable sound quality and it allows me to record from home. I simulate double enders with Audio Hijack 3 by setting up a pipeline like this:

Audio Hijack Pipeline

The pipeline above records my voice onto one file, Skype onto another and produces an additional file with both streams combined, with some volume equalization thrown into the mix. This is what I call the “virtual double ender”: it shares some advantages from the “real” double ender such as having both participants on different audio tracks, being able to space out overlapping voices with the added benefit that I immediately have everything needed to begin editing the episode.

A setup like this also greatly lightens the burden on my co-host since he will only be required to have Skype installed. No additional expensive or complicated software needed.

The drawback is that sound quality takes a noticeable hit, especially for the track that is being recorded over Skype, but it’s an acceptable trade-off for the simplicity brought by this setup. We are planning to move to a real double ender as soon as we gain more experience, though.

I use Trello and a document on Google Docs to plan each episode and collect all show notes.

Recording

I begin a recording session by opening our shared document on Google Docs, keeping a spare browser tab open and switching all devices and messaging application to “do not disturb” mode.

I then record between 15 to 30 seconds of background noise to aid with noise removal during the editing phase. I live near a busy road, thus a 30 second clip lets the microphone capture the varied background noise I am subjected to. 2

After that, we start recording, with Audio Hijack taking care of everything.

Editing

After the recording session, I import the clips into Audacity and perform some cleanup by doing the following:

  1. Select the first 30 seconds of background noise, then click Effect -> Noise Reduction -> Get Noise Profile button.
  2. Select the whole track and go back to Effect -> Noise Reduction and click the OK button, accepting the default settings.
  3. Select the whole track and then go to Effect -> Compression and click the OK button, accepting the default settings.
  4. Select the whole track again and apply the generic “Bass Boost” equalization curve.

After the cleanup phase I import the clips into GarageBand to cut and re-arrange the clips, space out overlapping voices, add the jingles and maybe the occasional sound effect.

Conclusion

That’s it, as you can see my setup is quite simple and while it could certainly be improved by throwing some more money at it, I’m quite happy with what I have now. I’m planning to do a full recording and editing session on an Ubuntu box in the future to see if I can use only 100% free software, stay tuned!

Meanwhile, I highly suggest you to read The ultimate guide to podcasting guides.

  1. Unfortunately the Blue Yeti didn’t fit into the NEEWER shock mount, fortunately I don’t happen to move the mic enough to be a problem. 

  2. I will probably switch to a dynamic microphone or make a small sound booth 

Thoughts on the Web Platform

Jul 8, 2015

My feelings towards the Web platform are of disgust and delight at the same time.

The Web is the only way to reach almost everyone in the world, regardless of the operating system they use. If they have a smartphone and a data plan they can get my application. I only have to develop it once, swear for a couple of months on all those Android devices still shipping with a stupidly broken WebKit implementation and then I’m done.

On paper, the Web platform is a marvelous thing.

It comes with a price though: non-native UI, near zero integration with the operating system, abysmal performance. The fact that everything is built on 25 years of technology meant to render text documents is the proverbial icing on the cake.

Yet, armed with our rocks and hammers we keep trying to bang out full blown applications built on few good core ideas drowned in a sea of crummy ones.

The simple fact that every six months we discover a new way to cobble HTML, CSS and JavaScript together to build “applications” is a clear sign that we are trying to coerce browsers to do something they were never designed to do.

The end result is that, while we are all carrying supercomputers in our pockets, most software doesn’t run any better than ten years ago. Instead, most web applications feel slow and bloated and you have to go to great lengths to do reverse that perception. Even big names realized that native applications are still the only way to deliver a great experience, especially on low end devices that don’t have all the resources to cope with the inherent inefficiency of current browsers.

It’s time to stop and rethink how we can improve the web platform for applications without making it worse for everything else.

I have this recurrent thought that maybe we could stop adding new features to HTML5 and instead create a new “rendering mode”, with an entirely different code path triggered by the presence of a special doctype. This could be implemented with a leaner rendering engine that could re-use some essential pieces from the legacy one, discarding all the rest to provide an efficient runtime. Here’s my wish list:

  • I want XHTML back. HTML5 is full of corner cases and while XML is by no means easy to parse it is at least well understood and widely supported and a more predictable markup language.
  • Be strict with errors, failing at the first one instead of chugging along leaving my application in an unusable, broken, state. If the underlying technologies are well documented and standardized I see no reason to accept malformed input.
  • Get rid of the CSS box model. Get rid of flexbox. I want a real layout engine and there’s plenty of native frameworks to get inspiration from. AutoLayout from iOS? QML’s anchors system? Qt’s or Android’s box layouts with springs? I will take anything as long as I, the developer, can extend it with custom logic, just as I can do in any of the aformentioned toolkits.
  • Get rid of JavaScript. The language might be good at its core but is rotten all around, to the point we had to write books to discourage use of its broken parts. Millions of dollars were spent trying to optimize it and the results are not so great. Thankfully, after the false starts represented by asm.js and PNaCl we might be finally reaching consensus with WebAssembly.

I know that asking to break compatibility with the current Web is too much to ask, but the unwillingness to create a new “major revision” of the Web platform brought us here, playing catch-up with features native platforms had ten years ago.