Thursday, May 28, 2015

Governments around the world should build home broadband networks at $16,000 per mile

The U.S. government incentivised the creation of the transcontinental railroad by paying the railroad builders $16,000 per mile of finished track.

That's the right way to build home broadband networks too.

For example when an ISP proves that it has installed a broadband connection of a certain speed into a home, then the ISP should be paid $16,000 (substitute this for the appropriate incentive amount).

You get the outcomes you reward.  If governments want fast home broadband then that's what they should pay for.

Monday, May 25, 2015

Why do G-rated movies need to frighten the heck out of children?

My little boy has recently become old enough to enjoy going to the movies. What could be better than taking your kids to the movies on a Saturday afternoon?

But I've found that many, if not most, supposedly G-rated movies almost always contain frankly absolutely terrifying scenes that are often quite extended.  My boy jumps off his seat and hides and doesn't watch.

Many of these scenes are very, very scary. EVERY Pixar G-rated movie includes scenes that are terrifying to children.

But why? Why does Hollywood feel that every movie, even for tiny children, has to include deeply frightening scenes? I don't understand. It seems like the accepted wisdom is that "to frighten is to entertain".  

It's almost like Hollywood feels that movies just won't sell unless it can scare children to the bottom of their little souls.

Thursday, May 21, 2015

Its hard to learn the easy way to develop software.

The irony of modern software development is that it is hard to learn how to do things the easy way. What I mean by that is that the easiest and most powerful ways of doing development often require a significant base level of learning and knowledge to understand. You can take a faster route to getting something up and running but the price is that it will be harder to work with. Someone has thought of an easier way, but first you must understand it.

All of that means that your choices are to get something quick and easy up and running but not really have any valuable long term understanding of the best way to do things. Or you can go through a painful period of "learning the easy way".

I recently did this and invested significant effort in learning react.js for the browser, and Python Falcon server for the back end, with Python Sqlalchemy for database access.

The impedance mismatch between Linux and its software.

I do alot of compiling, installing and generally trying to make things work in Linux.

Generally things don't work.  

Installations almost always fail and then you have to start digging around to work out why.

The most common reason is that software expects certain files to be in certain locations but the expected files are not there.

After many, many failed installations I think its reasonable to say that there is a deep systemic problem with the way Linux software works. There is an impedance mismatch between the operating system and the software that runs on it.

This problem of "file X is not found where expected" is at the core of many problems with making software install and run.  Apparently software just doesn't fit very well within the operating system that houses it.

There must be a better way - for the next great leap in computing somehow we need to be able to make software that knows what it needs and always finds it.

Giant computer companies in race against governments to protect and encrypt.

Governments around the world are addicted to intercepting and spying on everyone's computers. They feel it is their right.

Before too long, governments will be requiring the computer giants to build back doors into their systems to allow the government in.

But this is not in the interests of the computer giants.  Inherently insecure and inherently eavesdropped computers and networks are of much less value to end users.

So the computer giants must hurry up and lock things down in a permanent and irreversible manner before the governments really get their legislative act together.  It's a race.

Wednesday, May 20, 2015

For Linux, your core skill is navigating broken stuff, which is everything.

In the Linux world, as others before have said, "everything is broken".

If you are a developer or sysadmin doing anything of any significance then your ability to reach your goal is defined by how quickly and easily you can recognise and find workarounds for broken stuff.

Actually, not everything is broken, but so much is broken that it feel like everything. It's the broken stuff that will take your time. The stuff that isn't broken will be easy and will happen quickly.

So the faster you can jump through Linux's never ending minefield, hot coals, machine gun nests and shards of glass, the faster you can get productive work done.

Wanna be productive?  Get good at seeing and sidestepping and fixing broken stuff.

Sunday, May 10, 2015

An incredibly brief introduction to JavaScript in 2015 for experienced developers.

Over the years I've done bits and pieces of web and JavaScript development.  For one of my current projects however I need to get some serious stuff done, so I knew I had to come up to speed on the state of the art in browser development. I chose to target react.js as it seems to me to promise the simplest mental model which is what I need because I am time poor.

And things have changed ALOT in JavaScript development since the old days.  It took lots of searching and reading to make sense of the current landscape so I will now save you days of effort and summarise what you need to know:

1: Programming a web browser directly with JavaScript is dead. In the same way that few people now programs CPUs directly with assembly language. When you are writing JavaScript it now gets compiled (actually transpiled) to JavaScript.  Forget writing code directly for execution in a browser, those days are gone, move on.

2: There are a number of JavaScript variant languages for you to choose to program in.  The mainstream choice is now ECMAScript2015, also known as ES6.  
ECMAScript2015 /ES6 turns JavaScript programming into something sane, for lots of reasons but primarily because it implements a module/import system. 

3: Your development workflow involves writing ES6 code then shoving it through a series of very useful tools that carry out transformations of your code. The main transformation is the transpiling (converting your ES6 code to plain old JavaScript e.g tools like 'babel'). Other transformations include minifying (compressing/reducing the size of the output, e.g. 'uglify'), uglifying or mangling (making your code to make it harder for others to make sense of - 'uglify' does this too), bundling (combining multiple JavaScript files into a single file to reduce load times e.g. tools like browserify), translation (if you are using reactjs then you can write JSX which is like including XML style HTML in your JavaScript, this also needs to be translated as part of the transpile process).  There's probably plenty of others but these are the main ones I have encountered.

4: Your development workflow will use some sort of tool to tie together all the transpiling and transformation  tools.  If you know what "make" is then you understand the concept.  If not, well it's just a utility of some form that has a few different configurations of the tools mentioned above, each configuration useful for pushing your code through the various utilities until a final JavaScript file pops out of the end. "gulp" is the tool that people seem to be using alot at the moment for this purpose.  

5: You will need to learn how to drive the Google Chrome debugger or spend a very long time in debugging hell.  Go to YouTube, search for "JavaScript Debugging Chrome" and spend a few hours watching.  Time well spent.  The key thing you need to know is that JavaScript "source maps" will allow you to debug your code in the browser even after shoving it through the various transformation tools.

6: You will want to make use of various JavaScript libraries.  This is done through the npm package management system.  Invest some time in learning the basics of this. The key thing you need to know is that you say "npm install <packagename>" which installs packages under a "node_modules" directory in your current directory, which is where you compile from. In your code you will use "import" and "require" to load in the packages.   

Hopefully that lightning introductions has helped you find your feet.

I'm learning all this.  Have I got it wrong, please let me know.