Git Auth: HTTPS vs SSH

I hold the opinion that you can read into how a developer connects to their git repositories as a litmus test for other aspects of how they do things.

To “steel man” the usage of HTTPS. The obvious reason is that it’s easier to get started. People are familiar with username/password authentication and it translates directly here. The other big reason is port blocking on corporate networks. Port availability may not be within your control, and that could cause a headache.

I am going to assume a few things.
1. You are a developer
2. You aren’t oppressed with overly zealous corporate network security policies
3. You aren’t afraid of the command line

If those things are true, you may agree with me. Just because SSH is a tiny bit more effort to set up, it has many more advantages to authenticating with HTTPS. The biggest – the show stopper – reason is that those credentials unlock your entire account. If they are compromised in any way, you are completely left with your pants down. The number of times you communicate over the internet while developing, whether it be to fetch, pull, push, or anything else, you are risking exposure of those credentials. A compromised SSH key only provides access to the repositories. It can be revoked and a new one created. Do you have a credit card attached to your github account? Why would you risk the keys to your kingdom multiple times a day?

Once you have your SSH keys set up, it’s far easier to use and manage. There’s nothing to remember (unless you put a password on your key – even better security!). Once you are comfortable creating and managing keys, the applications for its use extend far beyond git repos. It immediately lends itself to server management and devops tasks.

The real reason Github recommends HTTPS over SSH is that it’s easier to support the lowest common denominator user. That’s not where I want to place myself, do you?

So what can you assume when you encounter a developer that uses HTTPS authentication?

– They read documentation. Github does
recommend HTTPS in its setup guide.
– They are probably on Windows
– They don’t use the terminal very often
– They don’t do much server administration

While none of this speaks directly to the intelligence or capabilities of the developer, it does say things about experience and how deep they are down the tech rabbit hole. It also telegraphs the kind of experience you will have developing with them.

As a developer, I recommend switching to SSH authentication for your git repositories. You’ll learn a few things worth knowing, you’ll be more secure, and you’ll ascend beyond the mass market instruction set on network communication setup.

Manjaro + Dotnet Core + Rider

I had a bit of trouble getting Rider set up initially to handle my dotnet core projects on Manjaro. Rider wouldn’t open the projects complaining about not being able to find SDKs like razor and web. My first stop was Settings->Build, Execution, Deployment->Toolset and Build. I messed around with those settings to no avail.

Here’s what did work. I added this to ~/.bashrc:

export MSBuildSDKsPath=/opt/dotnet/sdk/$(dotnet --version)/Sdks

I ended up with these settings in Rider:

Pointing to the MSBuild.dll within my dotnet installation seemed to be the kicker, over the one that came with mono. But I also changed my dotnet core executable path to /opt/dotnet/dotnet from /usr/bin/dotnet at the same time. Once I got it working, I didn’t want to mess with it anymore, so here it sits.

JSX + Atom + Emmet

To use Emmet in JSX files in Atom, there’s a bit of a manual step.

Atom v1.5.3
Emmet v2.4.3

To get it to work:

  1. Edit => Open your keymap
  2. Add the below snippet
  3. Restart Atom

'atom-text-editor[data-grammar="source js jsx"]:not([mini])': 'tab': 'emmet:expand-abbreviation-with-tab'

Slack Notifications on Ubuntu 16.04 LTS

Things have been swimming along nicely after upgrading to 16.04 over the weekend. Arriving back in the office on Monday revealed immediately that slack notifications weren’t working right. They were now an alert box that had to be manually closed rather than the growl-type notifications that they used to be. I made sure my slack client was on the latest version, and it was. Googling around revealed that I wasn’t the only one with this problem, and that it seemed to be an Electron issue.

This is what fixed it for me:

– sudo touch /usr/lib/libunity-electron_notification_fix
– restart slack

Using jQuery DataTables with Aurelia

This is assuming you have an Aurelia project set up and just want to add jQuery DataTables.

First, use jspm to grab datatables.

jspm install datatables=npm:datatables

When that’s done, you can start using it on a table in a view/viewmodel.

import $ from 'jquery';
import dataTable from 'datatables';

export class DataTableViewModel { 
  activate() {
      //bind your data here
  attached() {
      $('.js-table').dataTable( {
        "paginate": true,
        "pageLength": 25

There might be a better way to do this, but this works for now. I mostly based this on this excellent post about Toastr and Aurelia

Vaio Pro 13 vs Dell XPS 13 (2014)

Since two ultrabooks are better than one ultrabook, I added a Dell XPS 13 to my toolbox. It is pretty much identical spec-wise with my Vaio, so the real competition is fit and finish. Here’s how they stack up.

2015-02-11 (1)


  1. Screen Tilt

    Winner: Tie

    They both stop at the same point.

  2. Keyboard

    Winner: XPS

    Dell easily wins this battle. The key’s have a better feel and more bounce.


  3. Trackpad

    Winner: XPS

    Another easy win for the Dell. The Vaio’s trackpad is in the way more than it’s helpful. The Vaio needs to be planted on a firm, fat surface, for the clicks to even register. The Dell boasts a confident click even when raised off the desk, even though it does grab and hold on to fingerprints like no other.

  4. Battery Life

    Winner: Tie

    I haven’t noticed any difference in battery life. They both can go a long time between charging.

  5. Weight

    Winner: Vaio

    The Vaio is about a pound lighter. It adds nothing to my backpack and is easy to carry to and from meetings. I’m not sure that the Dell’s extra pound would affect this very much, but the Vaio is king of weighing very little.

  6. Ports

    Winner: Vaio

    While they both have two USB ports, I prefer the Vaio’s full size HDMI port. I haven’t adopted display port at all. This is more personal preference. The Dell might have a leg up by having one USB port on each side of the computer. One issue with the Vaio is that when using a larger USB stick, the neighboring port gets blocked. The thing that clinched this battle for the Vaio is the power cable. Having a bend in the connector makes me far less concerned about the health of the cable and the port. The extra charging USB port on the power brick was a stroke of genius on Sony’s part.


  7. Ability to handle linux

    Winner: XPS

    I know the Vaio Pro can handle linux. I’ve heard that Linus Torvalds has one. I just had a bunch of problems with wifi on linux with the Vaio that aren’t present on the XPS.

    2015-02-11 (2)


After several months, the Dell XPS 13 has been my go to development machine. It feels better and is more comfortable. I’d recommend it over the Vaio Pro 13.

Aurelia/JSPM Command failed: ‘unzip’ is not recognized

Presently, Aurelia’s navigation-skeleton isn’t playing nice on windows. When you get the the part where you run

jspm install -y

I was getting the error

Command failed: "unzip" is not recognized as an internal or external command, operable program or batch file.

This makes sense, because windows doesn’t have a command line ‘unzip’ program.

To solve this, I grabbed unzip.exe from here: I have a “utils” folder that is in my path that I can toss executables in, so I put it there.

The next error that comes up is is similar.

Command failed: "chmod" is not recognized as an internal or external command, operable program or batch file.

This command isn’t necessary for us, so I created “” in my “utils” folder and added the line

echo "noop"

as a Noop executable. JSPM was then happy.

Sony Vaio Pro 13 + Windows 10

I was early to the party with windows 8 on my Vaio Pro 13. There were a few issues with Visual Studio. I think they were graphic driver issues, if I remember correctly. Windows 10 Preview was a lot smoother. There were far fewer issues, and the big ones were just waiting on proprietary drivers. The only functionality I lost that I missed was Cisco VPN, but it’s probably been resolved by now. Visual Studio 2015 installs nicely and gave me no issues.

I am now running Ubuntu 14.10. My plan is to get a bigger SSD and dual boot Windows 10 and Ubuntu.

All Glory to the Hypnotoad!

Show me the glory!


Ok, I get it. Make it stop.

When I saw a really neat one line random color generator in a blog post, I saw it as an opportunity to glorify the hynotoad. This is the magic part:


In that line, ".toString(16)" gives us a hexadecimal value. We need to constrain our random numbers between 0 and ffffff, hexadecimally speaking, or 16777215 when converted to an integer. "1<<24" is a fancy and short way to achieve 16777216 using bitwise operators. The double tilde is a shorthand to lop off the decimal places that the call to "Math.random()" gives us. It could also have been achieved using "parseInt" on our random value.


This works just as well, but isn't nearly as cool looking.

Dropping our random color generator into a setInterval produces pleasing results.

  var toads = document.querySelectorAll('.hypnotoad');
  [], function(toad){ = "#"+(~~(Math.random()*(1&lt;&lt;24))).toString(16);
}, 80);

Apply your hypnotoad class to any element you want to begin glorification.

Here's a link to a codepen, if you like that sort of thing

Receiving Emails in Redmine with GMail on Dreamhost

Setting up Redmine to create issues from emails, the way I did it, mostly involved getting a cron job running to rake redmine:email:receive_imap. The basic steps are:

    1. Create a GMail Account
    2. Add a script to run at intervals (I am running it every 30 – */30 * * * *

I created shell script in it’s own file that reads like this:

/home/xxxx/.gems/bin/rake -f ~/xxxx/Rakefile redmine:email:receive_imap RAILS_ENV="production" ssl=SSL port=993 password=xxxx project=xxx tracker=bug priority=Immediate allow_override=project,tracker,priority --trace

One thing that hung me up was that for ruby gems to be in the path in the cron execution context, you’re crontab needs to look like this:

*/30 * * * * . /etc/profile && /path/to/

Without the “. /etc profile” part, your script won’t know what the hell a “rake” is.

I can’t get the “assigned_to” default to work, but I’m happy with it running properly for the time being.