Wednesday, December 20, 2017

Quebec Monorail (moteur roue - moh tar rooo)

Philippe Couillard has proposed building a monorail from Montreal to Quebec to deal with traffic issues between the two cities. The proposal is to use Trensquebec's theoretical monorail idea to create a 250km/h overhead style monorail. I'm all for high speed rail links between cities, what puzzles me is how a crackpot idea got enough traction to end up being proposed by the premier of Quebec.

Many people seem to think of convention rail as being very slow. It certainly doesn't help that most of the experiences we have with rail involved waiting at rail crossings in our cars while an incredibly slow freight train passes by. The definition of conventional rails goes up to 200km/h for pre-exisitng track and 240km/h for new track. High speed rail is typically 300km/h. Even VIA rail trains, that aren't known for their speed, are going 150km/h. It's quite humbling when you're passed by a VIA train while driving along the 401.

The biggest problems with going fast on existing rails in North America is the entire system is setup and optimized for freight. The track quality is not great, the signaling is all setup for low speeds, the bends are tight, there's level crossings all over the place and the mile long freight trains inch by at 50km/h. There are so many freight trains that VIA will be unable to provide service in the near future as it will be too crowded to run passenger trains. All this is why VIA trains go at 150km/h instead of 200km/h.

The solution is new track. VIA has proposed a very inexpensive solution they call high frequency rail. The proposal creates a VIA dedicated line so that they can run their trains at 150km/h to +180km/h speeds with no random delays (like today) thanks to freight trains blocking the way. What people have noticed in europe is that the frequency of the trains and sticking to a schedule is more important to ridership than max speed. With VIA's proposal it gets that.

Then there's Trensquebec. The biggest issue with them is there's no technology. It's not a real project. There's not even a prototype train on prototype track. There's also their suspiciously low cost estimates (it should be higher than the high speed rail proposals) as well as their suspiciously high operating speed (I would estimate ~200km/h max if that). At this point I think it's a big con. Quebec should be teaming up with the federal government and private industry to back VIA's proposal.

Wednesday, November 29, 2017

Microsoft Edge

Mozilla has recently release Firefox Quantum. I supposed because it's supposed to be a quantum leap in web browser technology. Does this means that Scott Bakula will show up in your web browser at critical moments to help guide you through your web browsing experience? Nope. Sorry. It just means the Firefox has a brand new web engine that's been redesigned to similar to Chrome but better. If you haven't been taking Firefox seriously for a while now is the time to try it again. My experience has been great so far. Not only have I started to use Firefox again but it's now my web browser of choice.

Recently Windows went through one of those comically long updates and loaded the release notes for the update into Microsoft Edge web browser. Neat! I thought to myself. I haven't tried Microsoft's web browser in a long time and I know they've been working on it. If Firefox can improve so much maybe Edge can as well.

The first thing I noticed in Edge is that the scroll wheel on my mouse doesn't work. It seems to work everywhere else just not in Edge. How did they even do that? Well, I'm not going to debug that. Not now I have a Firefox that doesn't suck. Maybe I'll try Edge again in another 5 years or so. You know, when they've figured out how to get the mouse wheel scrolling work.

New information! It turns out that CatMouse was causing the problem. Windows 10 seems to ahev CatMouse like functionality built into it so removing it was now big deal.

Thursday, November 23, 2017

IPv6 adoption hits 20%

About 2 years ago I noticed that IPv6 adoption was at about 7%. Well now IPv6 adoption is at 20% and still growing quickly. 20% is excellent! One in five people on the internet have an IPv6 address. This is the year of IPv6.

I'm still a little hopeful that this will mean that p2p technology will become viable again, but it's hard to say for sure. Security is much more important than it once was. I've also been burnt by the criminally cavalier approach to security that most companies seem to have. I may trust my router (barely) but not anything else. As a result I haven't turned on IPv6 on my router because I don't trust that everything on my LAN will actually do the right thing in that scenario.


Security on desktop and laptop machines isn't too bad anymore. The Windows 10 and OS X will ask the user if a program wants to open a port. Additionally, modern OSes do try and minimize their attack surfaces by not listening for connections when not required. I just can't remember if I've done something silly like turned on file sharing with guest access and that will be shared on the open internet. It wouldn't be the first time I've made that mistake. One of these days I'll have the time to experiment and see if file sharing restricts itself to LAN addresses. Also, if we get an public IPv6, does the OS also give us a private LAN address as well so we can bind more sensitive services only to that.

Tuesday, November 21, 2017

Typescript is fun

I recently went from programming on Java for almost 20 years to programming exclusively in Typescript and I like it.

Typescript is a super set of Javascript. It is essentially a typing system built on top of Javascript and it works amazingly well. When I first started programming in it I expect it to be a dancing bear, and from one perspective it sort of is, but man does this bear dance.

The way to think about Typescript is it makes Javascript scale. It's not really trying to be its own language as much as a set of tools that allow you to take existing Javascript code and add some typing sanity onto it. What makes it work is a combination of crazy good type inference and a sort of strong duck typing. So if you have something like this:

interface Person {
 String name;
 int age;

interface Monkey {
 String name;
 int age;

you can do this:
Person p = new MonkeyInstance();

or this:

Person p = { name: "Steve", age: 12 };
Monkey m = p;

and it doesn't care. So long as the interfaces are compatible you can assign it and it's all good. Java can't do this because Java is tracking types at the byte code level. A monkey and person are two different types that just happen to have the same properties. For Typescript having the same properties is what defines a type.

(Java does allow this sort of assignment in an around about fashion with functions. For instance, you can pass any method that takes a value and returns a value to a method expecting a Function. But it only works with functions, not objects)

Typescript also implements an idea I've wanted to see implemented for a long time. Nullable as a type!

In Java, we've started to use "Optional" instead of null because it makes the optional nature of the value part of the type. But, what if the language did it for you? Well Typescript does. Basically, you can't do this:

Person p = null;

You have to express that p might be null like this:

Person | null p = null;

Trying to do this using Java syntax gets confusing but the idea is that p might be a Person or it might be a null. Like using Optional, it makes the compiler track that a value might be optional, but unlike optional it's built in. The same multi-type trick works with any types:

Person | Exception p = findPerson();

p might be an Exception type or a Person and you'd need to do some additional work to work out what p is.

You can append however many you want:

Person | Exception | null p = findPerson();

In java you can do this with exception catch blocks, but nowhere else:

try {
} catch (NullPointerException | IOExecption | SqlException ex) {
 // ...

Here's a video of the inventor of Typescript explaining how Typescript deals with null.

Sunday, June 7, 2015

ipv6 is almost here

A few months ago we ran out of new IPv4 block to assign. That basically means we're out of IPv4 addresses. We need more! MOAR!!!! In order to get more (or moar) we need to move to IPv6 which is the next generation internet protocol (IPv5 was skipped because it opened a rift in space time and caused Vint Cerf to lose all his hair so they never deployed it). The trouble with IPv6 is that it's not compatible with IPv4. You can run both IPv6 and IPv6 at the same time but they are fundamentally separate networks. As a result of this incompatibility IPv6 has caught on like a house on fire. That is,  if the the house was made completely out of asbestos and at the bottom of a lake. IPv6 has been around since 1998 and was used by less than 1% of people up until 2013. More people have played Space Smilies.

Adoption is starting to pick up speed now according to google's IPv6 adoption statistics. IPv6 adoption is somewhere between 6% and 7%. It's growing so rapidly I've had to update these numbers since I've been writing this blog post! For comparison, the number of people who use Macintosh computers to access the internet is also somewhere in this range. 6% is also much higher than the number of people who use Linux to access the internet which tends to be in the 2%-3% range.

In Belgium the adoption rate is >30%. In the US it's about 15%. In Canada it's .. Yeah, let's just ignore Canada for now.

The rate of growth is accelerating. IPv6's adoption rate was around 2% at the start of 2014 and ~5% at the end. We're not even half way through 2015 and the IPv6 adoption rate is tickling 7%. Hurray!

But so what?

Well, I don't make enemies lightly, but one of my staunchest foes has been a technology called NAT. I first met this beast of a protocol while working on Myster. Myster is a p2p program I wrote from about 1999 to 2008.

NAT was created because even back in the old days of the 1990s we were running out of IP addressess. People has multiple computers that they wanted to use on one internet connection. Most of the time these tended to be larger organizations that had entire office buildings full of machines that were all networked together and wanted to be on the internet but there was no way to get enough IP addressed for them all.

NAT allows you to to share one internet connection (and one IP address) for a very large number of computers. NAT is all over the place. Odds are very good that you are using NAT right now in your router. Heck, I am using NAT right now and NAT is my mortal enemy. That is to say I hope it's mortal. There's one large problem with NAT: it breaks the internet.

Sure you and I both use the internet with NAT and everything seems ok, but that's a bit of a lie. The portion of the internet you use with a web browser works fine. Things like voice-over-ip and video games have issues. Not to mention the hundreds of programs that never were. You can't miss what you never had.

Each IP address is like a phone number. If you're sharing a single phone number between people then when the phone ring it's not obvious who the call is for. For computers it means that incoming connections tend to get dropped unless you go through the pain of saying which type of connection should be answered by which computer. The same isn't true for outgoing connections which is why surfing the web works fine. (kowabunga dude!)

In practice NAT is so common that most programs work around it. Skype, for example, is one HUGE work around for these kinds of problems. Skype is so crafty in getting around network restrictions that it sometimes acts more like a piece of malware. However, we are still losing out on cool technologies that can't exist because of NAT. Quite a few of these fall under the umbrella of p2p applications.

Peer to peer has gotten a bad reputation for its association with copyright infringement. This is not a completely deserved association. While peer to peer programs like Napster were used to pirate music, peer to peer itself is the fundamental technology that makes the internet so awesome.

Theoretically, every computer on the internet is a peer. Every computer has its own address and can communicate directly to each other without having to go through some intermediary. Given that this is the nature of the internet then why do we have this problem:

NAT is the reason.

IPv6 theoretically solves the NAT problem by making it possible for everyone and their toaster to have their very own IP address. This in turn means that individual devices can directly talk to each other on the internet. This in turn means that for the first time since about 1995 we will have a peer to peer internet. Think of all the new programs we could make!

If anyone is thinking of building a p2p startup company, this is the time to do it. It will still take about 5 years before the internet is close to ready for a new p2p application so best start now. Did I ever tell our about my p2p application Myster? Next time I'll tell you how it works and how I'd like to enhance it to give it new features.

Monday, May 11, 2015

Writing Scalable Code Using Inheritance in Java part 2

In my last post I mentioned a few simple rules on how to write maintainable code using inheritance:
  1. Reduce method and member scope
  2. Use final for methods and members
  3. Make make overridable methods abstract
  4. Don't make deep inheritance hierarchies
Today I want to show you how this affects maintainability.

Let's imagine we see a method like this in a class we know has many subclasses:

public final int getFoo() {...}

Here the presence of the final tells us that that we don't need to worry about anyone over-riding the behavior. Which is nice. 

public abstract int getFoo();

This one tells us sub classes *must* override this method. So we know that every sub class defines what we must do here. If we're in luck we'll be able to refactor this into a composition using the strategy pattern.

public int getFoo() {...}

This is problematic because we don't know whether there is subclass overriding this so we need to check all subclasses before we can modify its implementation. 

If we want to over-ride this method in a subclass we need to check the superclass to make sure that it doesn't have any side effects or being called at an unexpected time. Since it's a getXXX() method, it shouldn't be doing any side effects.

protected final int calculateFoo(...) {...}

This method can be accessed by itself and sub classes but not-over-ridden by sub classes. This method is probably part of an API offered to sub classes for them to call.

protected abstract int calculateFoo(...);

This method can be accessed by itself and sub classes and *must* be overridden by sub-classes. If we're in luck we'll be able to refactor this into a composition using the strategy pattern.

protected int calculateFoo(...) {...}

This is ambiguous. It might be a method that should be used as an API or it might define behavior like in the Strategy pattern. A third alternative is that it is meant to be over-ridden by sub-classes but provides a default implementation. Given the ambiguity I recommend adding a comment like this if it's the third case:

protected int calculateFoo(...) {
    /* Can be overriden by sub classes
     * default implementation: calculates foo using the bar algorythm 

Although, again, using the strategy pattern with a default strategy is often the best way to go.

private something() {..}

It can only be called in this subclass and can't be overriden so we're good.

public int foo;

Don't do that unless it's final, the class is final and your object doesn't have any methods in it. Something like this:

public final class Foo {
  public final int foo;

  public Foo(int foo) { = foo }

This is a standard best practice.

protected final int foo;

Don't do this.

protected int foo;

Don't do this either.. but more so.

Next week: how to brush your teeth!

Sunday, May 10, 2015

Writing Scalable Code Using Inheritance in Java

Everyone should be familiar with the old advice that you should favor composition over inheritance. However, what if you find yourself in a situation where inheritance is the best tool for the job? There are a few things you can do to keep your code maintainable.

Before we get into that I should explain a little about why you should favor composition over inheritance. Imagine you're trying to understand a class called Smilly. This class is detailing the behavior of a computer sprite in the award winning (in my mind) game Space Smilies. You're trying to figure out how this is implemented. The class is many lines long so it's obviously doing something something fancy. You notice that it inherits from a class called EvilThing. EvilThing extends from ComplexComputerSprite. This class extends ComputerSprite which extends AbstractSprite. All member variables are accessible from all subclasses. Where to start?

Making a member variable protected means it's accessible to all sub-classes. Any one of these sub classes can read an write to them. You need to understand how the class and all the parent classes interact to create the desired behavior. Just as making a member as public is bad practice because to understand who is modifying that public variable you need to track down every piece of code that uses it, using protected members in a complex hierarchy is bad for the same reasons.

This also applies to protected, non-final protected and public methods but it worse from the point of view of modifying the parent class. In order to understand if modifying a public or protected method will accomplish the desired behavior you need to understand the entire object hierarchy because there's no telling if one of the sub-classes has over-ridden any one of the public or protected methods and many make assumptions about how the class operate. If you stomp on one of its assumptions you'll cause a bug.

Understanding the entire class hierarchy and how each class works with its parent is labor intensive to say the least.

Because any method can be over-ridden anywhere in the hierarchy and because any state variable can be used by any subclass it means you have to be meticulous about checking every class in the hierarchy for unexpected overrides. With inheritance it's very easy to create a hierarchy that's so interconnected that you need to understand how everything works before you can understand any part of it. You might have an object composed of many classes but the classes over-ride each other's behavior in such a way that it effectively creates one big coupled class out of many.

Composition, on the other hand, makes it easier to create and maintain encapsulation and lower coupling. It's easier to control which members and methods are accessed and there's no invisible over-riding of behavior to trip you up. Methods that are public make up the object's external interface. Simple as that. (Assuming the normal best practice of trying to hide your member variables and implementation inside by making them private).

Composition is not as powerful as inheritance, however, so you might not be able easily do what you want using only composition. Which goes back to our original question, what do you do if inheritance is the right tool for the job? What if you need the power?

Java has a few tools to help you out in the form of the keywords abstract, protected, private and final.

If you find yourself with a sprawling inheritance hierarchy you can help out yourself and any future maintainer by:

  1. Reducing scope: If it can be made private then make it private. If it can't be made private then make it protected.
  2. Adding final: If a method can be made final then make it final. It's one less method that can have sneaky override or one less variable that can be modified.
  3. Make methods that *should* be overridden abstract: In complex objects it's more explicit to have all your overridable methods marked abstract so that's it's clear that subclasses need to implement these.
  4. Don't make deep inheritance hierarchies. The rule I use is a class's true size includes all it's parent classes all the way up to java/lang.Object.

to be continued...