Things n' Stuff Thoughts about the universe in general

That I’ve seen in a while anyway. If you go to Stack Overflow today, you’d find a helpful rubber duck in the corner that will help you solve all of your (code) problems:

Read the rest of this entry »

With version 8, Java finally jumped on the asynchronous programming bandwagon with its own Promise-Oriented programming model, implemented by the CompletableFuture class and a set of interfaces and implementations it uses. The model is generally useful and not as horribly complicated as we sometimes get in the Java foundation class library¹, and it lends itself to fluent programming much better than the comparable model from fluent API proponent Vert.x project.

The Problem

One thing that most asynchronous computing models suffer from – and Java’s CompletableFuture is no exception – is the loss of typed exception handling. While CompletableFuture.exceptionally() is a good model that does not introduce a lot of boilerplate², you do lose the ability of the try..catch..finally syntax to effortlessly ignore exceptions you are not ready to handle and just letting them propagate up the stack. Read the rest of this entry »

1. especially for things that claim to be “enterprise versions”, aughh [↩]
2. again, compare to Vert.x AsyncResult handlers. Other APIs, such as RX also do a good job in reducing boilerplate around error handling [↩]

In case you’re looking to host a Polymer application, S3 is a great and cheap option. The main problem is with no rewrite rules, you must use hash tag routing.

But with a simple configuration hack and a Cloudfront distribution you can use proper URLs for your S3 hosted polymer application – as detailed by Keita Kobayashi in his blog.

Microsoft recently demoed a Windows Subsystem for Linux¹ feature where they can run commands on a Linux shell under WSL from the Windows CMD shell – which, according to the demo that pipes the output of ipconfig to Linux grep, they need becuase the CMD shell is a 30 year old joke shell that can’t even do grep properly.

1. stupid reverse WINE : its a Linux system call translator for Windows, like WINE does for Linux, but doesn’t handle X or OpenGL and does a piss-poor job of file IO [↩]

If you haven’t noticed, my blog is now secure from the NSA peeking at your comments by the magic of TLS and Lets Encrypt !

But doing this, I forgot to update WordPress’s notion of what URL this blog lives on, and as a result comments posting didn’t actually work.

Sorry about that, and now it should work fine,

Ever needed to create a “secure” password to register to a web site¹ and you couldn’t be bothered to invent a secure password? Just paste this command line to your terminal:

ruby -e 'puts [*"a".."z",*"A".."Z",*"0".."9",
  "!@#$%^&*()_+[]/-=.,".split("")
  ].shuffle[0..(ARGV.shift.to_i)].join' 16

The last argument is the number of characters to put into the password.

1. that probably annoyingly require “at least 1 upper case letter, 1 lower case letter, 1 number and 1 special character” [↩]

Maybe you are a consultant and juggle multiple clients with Amazon Web Services deployments, maybe you just have accounts for all the start-ups you ever worked for, or maybe you just like to use 17 different AWS accounts for the free-tier usage, but eventually your ~/.aws/credentials file looks like an MS-Windows INI file.

At this point, running the AWS CLI is kind of annoying – you need to remember the correct --profile flag to set for each scenario, and bash will not complete these for you…

Bash aliases to the rescue!

Read the rest of this entry »

In the past, I’ve discussed using SSH to circumvent restricted networks with censoring transparent proxies, but that relied on the restricted network allowing free SSH access on port 22 (what we call in the industry – the single network requirement for getting work done).

Unfortunately, there are restricted networks that don’t even allow that – all you get is the transparent censoring HTTP proxy (which has recently became the case with the free Wi-Fi on the Israeil Railways trains).

But fortunately for us, there is still one protocol which they can’t block, they can’t proxy and they can’t man-in-the-middle  – or else they’d break the internet even for people who only read news, search google and watch YouTube – that is HTTPS.

In this article I’ll cover running SSH-over-HTTPS using ProxyTunnel and Apache. The main consideration is that the target web server is also running some other websites that we can’t interrupt. The main content is based on this article by Mark S. Kolich, but since it only covers using plain HTTP and in addition to some simple changes in the example configurations I also wanted to cover getting an SSL certificate, here’s my version of the tutorial:

Read the rest of this entry »

Canonical, makers of the Ubuntu operating system, have just announced that their about to expire “long term support” version is getting a longer “security only” life extension.

Sounds familiar?

Like other vendors who have similarly offered such life extensions in the past, the new support contract will only be offered to corporations who subscribe to the pricey commercial support package (at $250/year per VM and $750/year per physical server).

Read the rest of this entry »

Yesterday night, GitLab’s hosted service (gitlab.com) suffered a database crash and the service went down for a day¹.

I’m not going to discuss the technicalities of the down-time (which is covered extensively in the blog post linked above), except to note that “shit happens” – my main take-aways from that are basically two:

1. Don’t let tired people handle critical system issues, and if you ever find yourself juggling the third production issue at midnight after a full day of work – just say: “no, I’m not going to fix this – some one else must step in or we leave the system down for tomorrow”.
2. The GitLab process for handling the failure was nothing short of amazing, and they deserve all the kudus for that: After figuring out how deep in shit they are, and posting a “sorry we’re down” page on the main web site, they:

• Posted frequent updates on their tweeter status account (to the point of posting restore percentages progress)
• Published the technical root cause analysis Google Document as it was being developed
• Streamed the operations team ongoing restoration work on a live YouTube channel (!!) The operations people even responded live to comments on the chat, commented on the process and their architecture and were generally being awesome.

I think this should be the standard from now on how to handle system crashes on your public facing application – 1000% transparency should be how these things are handled if you have any hope of recovering the trust of the community in your service.

1. at the time of writing, the service is still not up, but its not yet even 24 hours since the crash happened [↩]