Software etc.

tldr:  time to market . Recently Keynes' prediction of a 15 hour work week has resurfaced in discussions ranging from automation to basic income. Why exactly do we still work 40+ hours? I've seen many reasons*, but I'd like to focus on something I missed in all the articles and comments: time to market . Companies need their creative employees to deliver at peak performance to achieve the fastest time to market. How can they invent & ship their products as soon as possible? Sticking to a small, stable team that works about 40 hours per week per person. There are two reasons for this: In creative professions the individuals are not easily interchangeable. You can have a different bricklayer continue your part of a wall the next day, getting another programmer to continue your piece of code is much more difficult. The same people have to work on a project for sustained periods of time. In the last century it has been demonstrated that you get most out of employe...

tldr; I propose something like in this image, so browsers put some pressure on ISP's and webhosts to adopt ipv6 For years we have heard that the Internet is about to break because the world is running out of ipv4 addresses. Sad, but not true. In my career as a programmer I've seen dirty hacks grow into extremely elaborate systems, despite the fact that they were originally set up to solve only moderately difficult problems. NATting is certainly a dirty hack, and now that ipv4 addresses are running out we're going to see lots of multi-level NAT gateways, which are certainly elaborate systems if they need to provide high availability. The problem is that these elaborate systems are difficult to maintain, and with each additional change you sink deeper into the quicksand. So even though I believe engineers will be able to work around the problems in ever dirtier ways it would be really good for the Internet if we could throw away the old system and switch to ipv6 en ...

TLDR: jump straight to the TypeScript section About 8 months ago I started a new complex web app in javascript, and it quickly grew out of hand. It had: a server with routes a singleton object with state, logic and helper functions a bunch of similar plugins that extend functionality the singleton object lives both on the server and on the client Very soon I decided that javascript allowed too much patterns. I wanted modules, classes and easy binding on the this keyword. Someone recommended CoffeeScript and I went with it. The codebase expanded to about 4000 LOC in a matter of weeks. So CoffeeScript hm, what about it? These are my experiences after maintaining a non-trivial coffeescript application for a couple of months. Pros: Programming was quicker, stuff you want is already in the language. (classes, inheritance, array comprehension, filters) Less verbose. for k,v in object fat arrow "string interpolation #{yes.please}" Cons: fat arrow is ve...

tl;dr: a better git branching workflow under the bold sentence below. So yesterday I enjoyed some of the Git Koans by Steve Losh ( http://stevelosh.com/blog/2013/04/git-koans/ ). While I believe that the criticism is valid, I think it also misses the point about git. Forget what you know about svn, mercurial or other version control systems when thinking about git. The fact that most people use it to version source code is irrelevant. Today I thought of a way to use git to store/merge and distribute the nginx configurations across our front facing webservers. We use git to version /etc , etc. So the big question here is: when will we see a perfect version control system for source code on top of the git data structure/algorithms? I've been using git for almost two years, but only since reading the Pro Git book 6 months ago did I really understand any of it. The thing about git is: a git repo is a data structure and the git commands are algorithms, and that's it...

A couple of weeks ago I posted about this issue I had with my Google Chrome Developers account. After a minor public outrage (#1 on Hacker News for an hour or two) I thought: this can go two ways, either they fix the problem perfectly right now and send me apologies and a free phone or something, or they keep ignoring it. Either way: I should tell the world how it went. Well, the actual outcome was somewhere in the middle. After three days of silence I got a reply on the Chromium Apps discussion board from Google's Developer Advocate Joe Marini. He apologized, said that the issue had been fixed and so it had. No big deal and certainly no free phone ;) (Bummer, my old HTC Vision just broke down) I published my extension straight away. The status turned to published but it did not show up in search and neither was I able to install it. I waited, after two days hit published again. Now the status turned to pending review. I waited two weeks. I posted this new issue on the ...

tl;dr: Google charged me 5$ for a Chrome Developer's account two months ago and I still can't get into my account, although I've reported the problem right away. Apparently going public is the only way to get their attention. Two months ago I created my first Chrome Extension. I had an itch using a crappy website. With a Chrome Extension you can run your own javascript in other websites which can greatly improve their user experience. That doesn't really matter. What does matter is that I could not publish the extension. I have an Android app for another itch that had to be scratched. When I created that, I had to pay $25 to sign up for a Developers Account. This was for administration purposes and as a measure to prevent fraudulent applications or whatever. Ok, I get that. Besides, $25 is peanuts. So I paid. But now Google wants even more peanuts. I thought having a Google Account meant being able to use it on all Google S...

I have some very nifty devices lying around in my home: A couple of computers A very smart router with the Tomato firmware A Raspberry Pi model B (the only one you can get right now) A Popcorn Hour A200 Besides that, I have full control over a domain name (waleson.com.). The amount of cool things you can do with this is enormous. However, until yesterday morning, these devices were working with most of their default settings (BOOOORING). Here's how I made it awesome in one evening. Part four, proxying to your devices. Part one - Dynamic DNS Part two - nginx on the Raspberry Pi Part three - free HTTPS to the rescue Objective: You want to access the devices inside from outside over the internet, securely So far we used all of the devices above, except for the Popcorn Hour. This device offers, amongst other things, a torrent client over the web. If you go to http://192.168.1.133:8077, or whatever IP your popcorn hour has, you'll get redirected to http://192.1...